From ica2_ts@csv.ica.uni-stuttgart.de Wed Dec  1 07:00:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 07:00:25 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:53578
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224916AbULAHAS>; Wed, 1 Dec 2004 07:00:18 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CZOTJ-0005bu-00; Wed, 01 Dec 2004 08:00:17 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CZOTH-0002wp-00; Wed, 01 Dec 2004 08:00:15 +0100
Date: Wed, 1 Dec 2004 08:00:14 +0100
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
Subject: [PATCH] Improve atomic.h implementation robustness
Message-ID: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6516
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Hello All,

the atomic functions use so far memory references for the inline
assembler to access the semaphore. This can lead to additional
instructions in the ll/sc loop, because newer compilers don't
expand the memory reference any more but leave it to the assembler.

The appended patch uses registers instead, and makes the ll/sc
arguments more explicit. In some cases it will lead also to better
register scheduling because the register isn't bound to an output
any more.


Thiemo


Index: include/asm-mips/atomic.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/atomic.h,v
retrieving revision 1.36
diff -u -p -r1.36 atomic.h
--- include/asm-mips/atomic.h	19 Aug 2004 09:54:23 -0000	1.36
+++ include/asm-mips/atomic.h	1 Dec 2004 06:45:27 -0000
@@ -62,22 +62,24 @@ static __inline__ void atomic_add(int i,
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	ll	%0, %1		# atomic_add		\n"
+		"1:	ll	%0, (%1)	# atomic_add		\n"
 		"	addu	%0, %2					\n"
-		"	sc	%0, %1					\n"
+		"	sc	%0, (%1)				\n"
 		"	beqzl	%0, 1b					\n"
-		: "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter));
+		: "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
+		: "memory");
 	} else if (cpu_has_llsc) {
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	ll	%0, %1		# atomic_add		\n"
+		"1:	ll	%0, (%1)	# atomic_add		\n"
 		"	addu	%0, %2					\n"
-		"	sc	%0, %1					\n"
+		"	sc	%0, (%1)				\n"
 		"	beqz	%0, 1b					\n"
-		: "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter));
+		: "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
+		: "memory");
 	} else {
 		unsigned long flags;
 
@@ -100,22 +102,24 @@ static __inline__ void atomic_sub(int i,
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	ll	%0, %1		# atomic_sub		\n"
+		"1:	ll	%0, (%1)	# atomic_sub		\n"
 		"	subu	%0, %2					\n"
-		"	sc	%0, %1					\n"
+		"	sc	%0, (%1)				\n"
 		"	beqzl	%0, 1b					\n"
-		: "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter));
+		: "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
+		: "memory");
 	} else if (cpu_has_llsc) {
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	ll	%0, %1		# atomic_sub		\n"
+		"1:	ll	%0, (%1)	# atomic_sub		\n"
 		"	subu	%0, %2					\n"
-		"	sc	%0, %1					\n"
+		"	sc	%0, (%1)				\n"
 		"	beqz	%0, 1b					\n"
-		: "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter));
+		: "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
+		: "memory");
 	} else {
 		unsigned long flags;
 
@@ -136,27 +140,27 @@ static __inline__ int atomic_add_return(
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	ll	%1, %2		# atomic_add_return	\n"
+		"1:	ll	%1, (%2)	# atomic_add_return	\n"
 		"	addu	%0, %1, %3				\n"
-		"	sc	%0, %2					\n"
+		"	sc	%0, (%2)				\n"
 		"	beqzl	%0, 1b					\n"
 		"	addu	%0, %1, %3				\n"
 		"	sync						\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else if (cpu_has_llsc) {
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	ll	%1, %2		# atomic_add_return	\n"
+		"1:	ll	%1, (%2)	# atomic_add_return	\n"
 		"	addu	%0, %1, %3				\n"
-		"	sc	%0, %2					\n"
+		"	sc	%0, (%2)				\n"
 		"	beqz	%0, 1b					\n"
 		"	addu	%0, %1, %3				\n"
 		"	sync						\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else {
 		unsigned long flags;
@@ -179,27 +183,27 @@ static __inline__ int atomic_sub_return(
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	ll	%1, %2		# atomic_sub_return	\n"
+		"1:	ll	%1, (%2)	# atomic_sub_return	\n"
 		"	subu	%0, %1, %3				\n"
-		"	sc	%0, %2					\n"
+		"	sc	%0, (%2)				\n"
 		"	beqzl	%0, 1b					\n"
 		"	subu	%0, %1, %3				\n"
 		"	sync						\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else if (cpu_has_llsc) {
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	ll	%1, %2		# atomic_sub_return	\n"
+		"1:	ll	%1, (%2)	# atomic_sub_return	\n"
 		"	subu	%0, %1, %3				\n"
-		"	sc	%0, %2					\n"
+		"	sc	%0, (%2)				\n"
 		"	beqz	%0, 1b					\n"
 		"	subu	%0, %1, %3				\n"
 		"	sync						\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else {
 		unsigned long flags;
@@ -229,29 +233,29 @@ static __inline__ int atomic_sub_if_posi
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	ll	%1, %2		# atomic_sub_if_positive\n"
+		"1:	ll	%1, (%2)	# atomic_sub_if_positive\n"
 		"	subu	%0, %1, %3				\n"
 		"	bltz	%0, 1f					\n"
-		"	sc	%0, %2					\n"
+		"	sc	%0, (%2)				\n"
 		"	beqzl	%0, 1b					\n"
 		"	sync						\n"
 		"1:							\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else if (cpu_has_llsc) {
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	ll	%1, %2		# atomic_sub_if_positive\n"
+		"1:	ll	%1, (%2)	# atomic_sub_if_positive\n"
 		"	subu	%0, %1, %3				\n"
 		"	bltz	%0, 1f					\n"
-		"	sc	%0, %2					\n"
+		"	sc	%0, (%2)				\n"
 		"	beqz	%0, 1b					\n"
 		"	sync						\n"
 		"1:							\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else {
 		unsigned long flags;
@@ -367,22 +371,24 @@ static __inline__ void atomic64_add(long
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	lld	%0, %1		# atomic64_add		\n"
+		"1:	lld	%0, (%1)	# atomic64_add		\n"
 		"	addu	%0, %2					\n"
-		"	scd	%0, %1					\n"
+		"	scd	%0, (%1)				\n"
 		"	beqzl	%0, 1b					\n"
-		: "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter));
+		: "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
+		: "memory");
 	} else if (cpu_has_llsc) {
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	lld	%0, %1		# atomic64_add		\n"
+		"1:	lld	%0, (%1)	# atomic64_add		\n"
 		"	addu	%0, %2					\n"
-		"	scd	%0, %1					\n"
+		"	scd	%0, (%1)				\n"
 		"	beqz	%0, 1b					\n"
-		: "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter));
+		: "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
+		: "memory");
 	} else {
 		unsigned long flags;
 
@@ -405,22 +411,24 @@ static __inline__ void atomic64_sub(long
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	lld	%0, %1		# atomic64_sub		\n"
+		"1:	lld	%0, (%1)	# atomic64_sub		\n"
 		"	subu	%0, %2					\n"
-		"	scd	%0, %1					\n"
+		"	scd	%0, (%1)				\n"
 		"	beqzl	%0, 1b					\n"
-		: "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter));
+		: "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
+		: "memory");
 	} else if (cpu_has_llsc) {
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	lld	%0, %1		# atomic64_sub		\n"
+		"1:	lld	%0, (%1)	# atomic64_sub		\n"
 		"	subu	%0, %2					\n"
-		"	scd	%0, %1					\n"
+		"	scd	%0, (%1)				\n"
 		"	beqz	%0, 1b					\n"
-		: "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter));
+		: "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
+		: "memory");
 	} else {
 		unsigned long flags;
 
@@ -441,27 +449,27 @@ static __inline__ long atomic64_add_retu
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	lld	%1, %2		# atomic64_add_return	\n"
+		"1:	lld	%1, (%2)	# atomic64_add_return	\n"
 		"	addu	%0, %1, %3				\n"
-		"	scd	%0, %2					\n"
+		"	scd	%0, (%2)				\n"
 		"	beqzl	%0, 1b					\n"
 		"	addu	%0, %1, %3				\n"
 		"	sync						\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else if (cpu_has_llsc) {
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	lld	%1, %2		# atomic64_add_return	\n"
+		"1:	lld	%1, (%2)	# atomic64_add_return	\n"
 		"	addu	%0, %1, %3				\n"
-		"	scd	%0, %2					\n"
+		"	scd	%0, (%2)				\n"
 		"	beqz	%0, 1b					\n"
 		"	addu	%0, %1, %3				\n"
 		"	sync						\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else {
 		unsigned long flags;
@@ -484,27 +492,27 @@ static __inline__ long atomic64_sub_retu
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	lld	%1, %2		# atomic64_sub_return	\n"
+		"1:	lld	%1, (%2)	# atomic64_sub_return	\n"
 		"	subu	%0, %1, %3				\n"
-		"	scd	%0, %2					\n"
+		"	scd	%0, (%2)				\n"
 		"	beqzl	%0, 1b					\n"
 		"	subu	%0, %1, %3				\n"
 		"	sync						\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else if (cpu_has_llsc) {
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	lld	%1, %2		# atomic64_sub_return	\n"
+		"1:	lld	%1, (%2)	# atomic64_sub_return	\n"
 		"	subu	%0, %1, %3				\n"
-		"	scd	%0, %2					\n"
+		"	scd	%0, (%2)				\n"
 		"	beqz	%0, 1b					\n"
 		"	subu	%0, %1, %3				\n"
 		"	sync						\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else {
 		unsigned long flags;
@@ -534,29 +542,29 @@ static __inline__ long atomic64_sub_if_p
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	lld	%1, %2		# atomic64_sub_if_positive\n"
+		"1:	lld	%1, (%2)	# atomic64_sub_if_positive\n"
 		"	dsubu	%0, %1, %3				\n"
 		"	bltz	%0, 1f					\n"
-		"	scd	%0, %2					\n"
+		"	scd	%0, (%2)				\n"
 		"	beqzl	%0, 1b					\n"
 		"	sync						\n"
 		"1:							\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else if (cpu_has_llsc) {
 		unsigned long temp;
 
 		__asm__ __volatile__(
-		"1:	lld	%1, %2		# atomic64_sub_if_positive\n"
+		"1:	lld	%1, (%2)	# atomic64_sub_if_positive\n"
 		"	dsubu	%0, %1, %3				\n"
 		"	bltz	%0, 1f					\n"
-		"	scd	%0, %2					\n"
+		"	scd	%0, (%2)				\n"
 		"	beqz	%0, 1b					\n"
 		"	sync						\n"
 		"1:							\n"
-		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
-		: "Ir" (i), "m" (v->counter)
+		: "=&r" (result), "=&r" (temp)
+		: "r" (&v->counter), "Ir" (i)
 		: "memory");
 	} else {
 		unsigned long flags;

From dom@mips.com Wed Dec  1 10:21:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 10:21:18 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:33030 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224947AbULAKVN>;
	Wed, 1 Dec 2004 10:21:13 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1CZRj8-0002Qd-00; Wed, 01 Dec 2004 10:28:50 +0000
Received: from olympia.mips.com ([192.168.192.128] helo=doms-laptop.algor.co.uk)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1CZRar-0006JY-00; Wed, 01 Dec 2004 10:20:18 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16813.39660.948092.328493@doms-laptop.algor.co.uk>
Date: Wed, 1 Dec 2004 10:20:28 +0000
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
cc: Nigel Stephens <nigel@mips.com>, David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
In-Reply-To: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.829, required 4, AWL,
	BAYES_00)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6517
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips


Thiemo writes:

> the atomic functions use so far memory references for the inline
> assembler to access the semaphore. This can lead to additional
> instructions in the ll/sc loop, because newer compilers don't
> expand the memory reference any more but leave it to the assembler.
> 
> The appended patch...

I thought it was an explicit aim of the substantial rewrite of the
MIPS backend for 3.x to get the compiler to generate only "real"
instructions, not macros which expand to multiple instructions inside
the assembler.  So it's disappointing if newer compilers got worse.

Can one of our compiler-knowledgable people follow this up?

--
Dominic Sweetman
MIPS Technologies


From ralf@linux-mips.org Wed Dec  1 12:35:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 12:35:53 +0000 (GMT)
Received: from p508B7F35.dip.t-dialin.net ([IPv6:::ffff:80.139.127.53]:20609
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225210AbULAMft>; Wed, 1 Dec 2004 12:35:49 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB1CXkHv005963;
	Wed, 1 Dec 2004 13:33:46 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB1CXaXu005962;
	Wed, 1 Dec 2004 13:33:36 +0100
Date: Wed, 1 Dec 2004 13:33:36 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Dominic Sweetman <dom@mips.com>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
Message-ID: <20041201123336.GA5612@linux-mips.org>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16813.39660.948092.328493@doms-laptop.algor.co.uk>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6518
X-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, Dec 01, 2004 at 10:20:28AM +0000, Dominic Sweetman wrote:

> > the atomic functions use so far memory references for the inline
> > assembler to access the semaphore. This can lead to additional
> > instructions in the ll/sc loop, because newer compilers don't
> > expand the memory reference any more but leave it to the assembler.
> > 
> > The appended patch...
> 
> I thought it was an explicit aim of the substantial rewrite of the
> MIPS backend for 3.x to get the compiler to generate only "real"
> instructions, not macros which expand to multiple instructions inside
> the assembler.  So it's disappointing if newer compilers got worse.
> 
> Can one of our compiler-knowledgable people follow this up?

Dominik,

this problem here is specific to inline assembler.  The splitlock code for
a reasonable CPU is:

static __inline__ void atomic_add(int i, atomic_t * v)
{
        unsigned long temp;

        __asm__ __volatile__(
        "1:     ll      %0, %1          # atomic_add            \n"
        "       addu    %0, %2                                  \n"
        "       sc      %0, %1                                  \n"
        "       beqz    %0, 1b                                  \n"
        : "=&r" (temp), "=m" (v->counter)
        : "Ir" (i), "m" (v->counter));
}

For the average atomic op generated code is going to look about like:

80100634:       lui     a0,0x802c
80100638:       ll      a0,-24160(a0)
8010063c:       addu    a0,a0,v0
80100640:       lui     at,0x802c
80100644:       addu    at,at,v1
80100648:       sc      a0,-24160(at)
8010064c:       beqz    a0,80100634 <init+0x194>
80100650:       nop

It's significantly worse for 64-bit due to the excessive code sequence
generated for loading a 64-bit address.  One outside CKSEGx that is.

On 32-bit Thiemo's patch would cut that down to something like:

80100630:       lui     t0,0x802c
80100634:       addiu	t0,t0,-24160
80100638:       ll      a0,0(t0)
8010063c:       addu    a0,a0,v0
80100648:       sc      a0,0(to)
8010064c:       beqz    a0,80100638 <init+0x194>
80100650:       nop

On 64-bit the savings would be even more significant.  But what we actually
want would be using the "o" constraint.  Which just at least on the
compilers where I've tried it, didn't produce code any different from "m".
The expected code would be something like:

80100634:       lui     t0,0x802c
80100638:       ll      a0,-24160(t0)
8010063c:       addu    a0,a0,v0
80100648:       sc      a0,-24160(to)
8010064c:       beqz    a0,80100634 <init+0x194>
80100650:       nop

So another instruction less.

  Ralf

From yuasa@hh.iij4u.or.jp Wed Dec  1 14:49:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 14:49:55 +0000 (GMT)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:30960 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225341AbULAOtu>;
	Wed, 1 Dec 2004 14:49:50 +0000
Received: MO(mo01)id iB1EnkSi000947; Wed, 1 Dec 2004 23:49:46 +0900 (JST)
Received: MDO(mdo00) id iB1Enjid016307; Wed, 1 Dec 2004 23:49:45 +0900 (JST)
Received: 4UMRO01 id iB1EniOD004399; Wed, 1 Dec 2004 23:49:44 +0900 (JST)
	from stratos (localhost [127.0.0.1]) (authenticated)
Date: Wed, 1 Dec 2004 23:49:43 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] tlbwr hazard for NEC VR4100
Message-Id: <20041201234943.584d88e8.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.0beta3 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6519
X-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

Hi Ralf,

This patch had added tlbwr hazard for NEC VR4100.
Please apply this patch to 2.6.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/mm/tlbex.c a/arch/mips/mm/tlbex.c
--- a-orig/arch/mips/mm/tlbex.c	Tue Nov 30 20:42:08 2004
+++ a/arch/mips/mm/tlbex.c	Wed Dec  1 23:23:11 2004
@@ -820,6 +820,25 @@
 		i_ssnop(p);
 		break;
 
+	case CPU_VR4111:
+	case CPU_VR4121:
+	case CPU_VR4122:
+	case CPU_VR4181:
+	case CPU_VR4181A:
+		i_nop(p);
+		i_nop(p);
+		i_tlbwr(p);
+		i_nop(p);
+		i_nop(p);
+		break;
+
+	case CPU_VR4131:
+	case CPU_VR4133:
+		i_nop(p);
+		i_nop(p);
+		i_tlbwr(p);
+		break;
+
 	default:
 		panic("No TLB refill handler yet (CPU type: %d)",
 		      current_cpu_data.cputype);

From yuasa@hh.iij4u.or.jp Wed Dec  1 15:05:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 15:05:40 +0000 (GMT)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:52979 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225345AbULAPFf>;
	Wed, 1 Dec 2004 15:05:35 +0000
Received: MO(mo01)id iB1F5WKl003590; Thu, 2 Dec 2004 00:05:32 +0900 (JST)
Received: MDO(mdo00) id iB1F5VeB016563; Thu, 2 Dec 2004 00:05:32 +0900 (JST)
Received: 4UMRO01 id iB1F5VOD006285; Thu, 2 Dec 2004 00:05:31 +0900 (JST)
	from stratos (localhost [127.0.0.1]) (authenticated)
Date: Thu, 2 Dec 2004 00:05:30 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] fix build error about NEC VR4100 series.
Message-Id: <20041202000530.33020293.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.0beta3 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6520
X-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

Hi Ralf,

This patch had fixed build error about NEC VR4100 series.
Please apply this patch to 2.6.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/bcu.c a/arch/mips/vr41xx/common/bcu.c
--- a-orig/arch/mips/vr41xx/common/bcu.c	Thu May 27 02:11:11 2004
+++ a/arch/mips/vr41xx/common/bcu.c	Wed Dec  1 23:50:40 2004
@@ -30,6 +30,7 @@
  */
 #include <linux/init.h>
 #include <linux/ioport.h>
+#include <linux/kernel.h>
 #include <linux/smp.h>
 #include <linux/types.h>
 
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/pmu.c a/arch/mips/vr41xx/common/pmu.c
--- a-orig/arch/mips/vr41xx/common/pmu.c	Thu May 27 02:11:11 2004
+++ a/arch/mips/vr41xx/common/pmu.c	Wed Dec  1 23:50:40 2004
@@ -18,6 +18,7 @@
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 #include <linux/init.h>
+#include <linux/kernel.h>
 #include <linux/smp.h>
 #include <linux/types.h>
 

From yuasa@hh.iij4u.or.jp Wed Dec  1 15:18:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 15:18:32 +0000 (GMT)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:3063 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225345AbULAPS2>;
	Wed, 1 Dec 2004 15:18:28 +0000
Received: MO(mo01)id iB1FIP7U006108; Thu, 2 Dec 2004 00:18:25 +0900 (JST)
Received: MDO(mdo00) id iB1FIOSW016811; Thu, 2 Dec 2004 00:18:25 +0900 (JST)
Received: 4UMRO00 id iB1FINLj012038; Thu, 2 Dec 2004 00:18:24 +0900 (JST)
	from stratos (localhost [127.0.0.1]) (authenticated)
Date: Thu, 2 Dec 2004 00:18:22 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] update TANBAC TB0229 configuration
Message-Id: <20041202001822.5d5b4522.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.0beta3 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6521
X-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

Hi Ralf,

This patch has updated TANBAC TB0229 configuration.
Please apply this patch to 2.6.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/configs/tb0229_defconfig a/arch/mips/configs/tb0229_defconfig
--- a-orig/arch/mips/configs/tb0229_defconfig	Mon Nov 22 15:12:30 2004
+++ a/arch/mips/configs/tb0229_defconfig	Thu Dec  2 00:05:59 2004
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
 # Linux kernel version: 2.6.10-rc2
-# Sun Nov 21 14:12:07 2004
+# Wed Dec  1 14:32:07 2004
 #
 CONFIG_MIPS=y
 # CONFIG_MIPS64 is not set
@@ -65,7 +65,7 @@
 # CONFIG_VICTOR_MPC30X is not set
 # CONFIG_ZAO_CAPCELLA is not set
 CONFIG_PCI_VR41XX=y
-CONFIG_VRC4173=y
+# CONFIG_VRC4173 is not set
 # CONFIG_TOSHIBA_JMR3927 is not set
 # CONFIG_MIPS_COBALT is not set
 # CONFIG_MACH_DECSTATION is not set
@@ -315,7 +315,7 @@
 # Ethernet (10 or 100Mbit)
 #
 CONFIG_NET_ETHERNET=y
-# CONFIG_MII is not set
+CONFIG_MII=y
 # CONFIG_HAPPYMEAL is not set
 # CONFIG_SUNGEM is not set
 # CONFIG_NET_VENDOR_3COM is not set
@@ -325,7 +325,27 @@
 #
 # CONFIG_NET_TULIP is not set
 # CONFIG_HP100 is not set
-# CONFIG_NET_PCI is not set
+CONFIG_NET_PCI=y
+CONFIG_PCNET32=y
+# CONFIG_AMD8111_ETH is not set
+# CONFIG_ADAPTEC_STARFIRE is not set
+# CONFIG_B44 is not set
+# CONFIG_FORCEDETH is not set
+# CONFIG_DGRS is not set
+CONFIG_EEPRO100=y
+# CONFIG_EEPRO100_PIO is not set
+# CONFIG_E100 is not set
+# CONFIG_FEALNX is not set
+# CONFIG_NATSEMI is not set
+# CONFIG_NE2K_PCI is not set
+# CONFIG_8139CP is not set
+# CONFIG_8139TOO is not set
+# CONFIG_SIS900 is not set
+# CONFIG_EPIC100 is not set
+# CONFIG_SUNDANCE is not set
+# CONFIG_TLAN is not set
+# CONFIG_VIA_RHINE is not set
+# CONFIG_LAN_SAA9730 is not set
 
 #
 # Ethernet (1000 Mbit)
@@ -338,6 +358,7 @@
 # CONFIG_YELLOWFIN is not set
 # CONFIG_R8169 is not set
 # CONFIG_SK98LIN is not set
+# CONFIG_VIA_VELOCITY is not set
 # CONFIG_TIGON3 is not set
 
 #
@@ -684,7 +705,7 @@
 #
 # CONFIG_DEBUG_KERNEL is not set
 CONFIG_CROSSCOMPILE=y
-CONFIG_CMDLINE=""
+CONFIG_CMDLINE="mem=64M console=ttyS0,38400 ip=bootp root=/dev/nfs"
 
 #
 # Security options
@@ -702,7 +723,7 @@
 # Library routines
 #
 CONFIG_CRC_CCITT=m
-# CONFIG_CRC32 is not set
+CONFIG_CRC32=y
 # CONFIG_LIBCRC32C is not set
 CONFIG_ZLIB_INFLATE=y
 CONFIG_ZLIB_DEFLATE=m

From ralf@linux-mips.org Wed Dec  1 15:42:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 15:42:56 +0000 (GMT)
Received: from p508B7F35.dip.t-dialin.net ([IPv6:::ffff:80.139.127.53]:42115
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225345AbULAPmw>; Wed, 1 Dec 2004 15:42:52 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB1Fgkld009087;
	Wed, 1 Dec 2004 16:42:47 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB1FgauZ009086;
	Wed, 1 Dec 2004 16:42:37 +0100
Date: Wed, 1 Dec 2004 16:42:36 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] tlbwr hazard for NEC VR4100
Message-ID: <20041201154236.GA6480@linux-mips.org>
References: <20041201234943.584d88e8.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041201234943.584d88e8.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6522
X-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, Dec 01, 2004 at 11:49:43PM +0900, Yoichi Yuasa wrote:

> This patch had added tlbwr hazard for NEC VR4100.
> Please apply this patch to 2.6.

Thanks, applied.

  Ralf

From ralf@linux-mips.org Wed Dec  1 15:44:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 15:44:31 +0000 (GMT)
Received: from p508B7F35.dip.t-dialin.net ([IPv6:::ffff:80.139.127.53]:44163
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225352AbULAPo1>; Wed, 1 Dec 2004 15:44:27 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB1FiNAh009121;
	Wed, 1 Dec 2004 16:44:23 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB1FiNYl009120;
	Wed, 1 Dec 2004 16:44:23 +0100
Date: Wed, 1 Dec 2004 16:44:23 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] fix build error about NEC VR4100 series.
Message-ID: <20041201154423.GB6480@linux-mips.org>
References: <20041202000530.33020293.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041202000530.33020293.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6523
X-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, Dec 02, 2004 at 12:05:30AM +0900, Yoichi Yuasa wrote:

> This patch had fixed build error about NEC VR4100 series.
> Please apply this patch to 2.6.

Applied,

  Ralf

From ralf@linux-mips.org Wed Dec  1 15:45:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 15:45:27 +0000 (GMT)
Received: from p508B7F35.dip.t-dialin.net ([IPv6:::ffff:80.139.127.53]:46211
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225352AbULAPpX>; Wed, 1 Dec 2004 15:45:23 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB1FjJE8009162;
	Wed, 1 Dec 2004 16:45:19 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB1FjJYE009161;
	Wed, 1 Dec 2004 16:45:19 +0100
Date: Wed, 1 Dec 2004 16:45:18 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] update TANBAC TB0229 configuration
Message-ID: <20041201154518.GC6480@linux-mips.org>
References: <20041202001822.5d5b4522.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041202001822.5d5b4522.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6524
X-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, Dec 02, 2004 at 12:18:22AM +0900, Yoichi Yuasa wrote:

> This patch has updated TANBAC TB0229 configuration.
> Please apply this patch to 2.6.

Applied,

  Ralf

From yuasa@hh.iij4u.or.jp Wed Dec  1 15:53:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 15:53:52 +0000 (GMT)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:37886 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225352AbULAPxs>;
	Wed, 1 Dec 2004 15:53:48 +0000
Received: MO(mo01)id iB1Frj3G012051; Thu, 2 Dec 2004 00:53:45 +0900 (JST)
Received: MDO(mdo00) id iB1Friib017402; Thu, 2 Dec 2004 00:53:44 +0900 (JST)
Received: 4UMRO00 id iB1FrhLj016268; Thu, 2 Dec 2004 00:53:44 +0900 (JST)
	from stratos (localhost [127.0.0.1]) (authenticated)
Date: Thu, 2 Dec 2004 00:53:41 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] moved TANBAC_TB0219
Message-Id: <20041202005341.685ab658.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.0beta3 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6525
X-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

Hi Ralf,

TANBAC_TB0219 depends on TANBAC_TB0229 only.
This patch moves TANBAC_TB0219 next to TANBAC_TB0229.
Please apply this patch to 2.6.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/Kconfig a/arch/mips/Kconfig
--- a-orig/arch/mips/Kconfig	Thu Nov 25 15:37:27 2004
+++ a/arch/mips/Kconfig	Thu Dec  2 00:30:26 2004
@@ -103,6 +103,10 @@
 	  The TANBAC TB0229 (VR4131DIMM) is a MIPS-based platform manufactured by TANBAC.
 	  Please refer to <http://www.tanbac.co.jp/> about VR4131DIMM.
 
+config TANBAC_TB0219
+	bool "Added TANBAC TB0219 Base board support"
+	depends on TANBAC_TB0229
+
 config VICTOR_MPC30X
 	bool "Support for Victor MP-C303/304"
 	select DMA_NONCOHERENT
@@ -1106,10 +1110,6 @@
 	bool
 	depends on TOSHIBA_JMR3927 || TOSHIBA_RBTX4927
 	default y
-
-config TANBAC_TB0219
-	bool "Added TANBAC TB0219 Base board support"
-	depends on TANBAC_TB0229
 
 endmenu
 



From ralf@linux-mips.org Wed Dec  1 20:10:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 20:10:48 +0000 (GMT)
Received: from p508B7F35.dip.t-dialin.net ([IPv6:::ffff:80.139.127.53]:39808
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225802AbULAUKn>; Wed, 1 Dec 2004 20:10:43 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB1KAcWr005548;
	Wed, 1 Dec 2004 21:10:38 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB1KAb7C005547;
	Wed, 1 Dec 2004 21:10:37 +0100
Date: Wed, 1 Dec 2004 21:10:37 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] moved TANBAC_TB0219
Message-ID: <20041201201037.GA5442@linux-mips.org>
References: <20041202005341.685ab658.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041202005341.685ab658.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6526
X-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, Dec 02, 2004 at 12:53:41AM +0900, Yoichi Yuasa wrote:

> TANBAC_TB0219 depends on TANBAC_TB0229 only.
> This patch moves TANBAC_TB0219 next to TANBAC_TB0229.
> Please apply this patch to 2.6.

Ok,

  Ralf

From ica2_ts@csv.ica.uni-stuttgart.de Wed Dec  1 20:45:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 20:45:45 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:54871
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225923AbULAUpk>; Wed, 1 Dec 2004 20:45:40 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CZbM1-0005Vb-00; Wed, 01 Dec 2004 21:45:37 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CZbM0-0005Df-00; Wed, 01 Dec 2004 21:45:36 +0100
Date: Wed, 1 Dec 2004 21:45:36 +0100
To: Dominic Sweetman <dom@mips.com>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org,
	Nigel Stephens <nigel@mips.com>, David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
Message-ID: <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16813.39660.948092.328493@doms-laptop.algor.co.uk>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6527
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Dominic Sweetman wrote:
> 
> Thiemo writes:
> 
> > the atomic functions use so far memory references for the inline
> > assembler to access the semaphore. This can lead to additional
> > instructions in the ll/sc loop, because newer compilers don't
> > expand the memory reference any more but leave it to the assembler.
> > 
> > The appended patch...
> 
> I thought it was an explicit aim of the substantial rewrite of the
> MIPS backend for 3.x to get the compiler to generate only "real"
> instructions, not macros which expand to multiple instructions inside
> the assembler.  So it's disappointing if newer compilers got worse.

The compiler was improved with PIC code in mind. The kernel is
non-PIC, and can't allow explicit relocs by the compiler because
of the weird code model used for 64bit kernels. This led to some
degradation and even subtle failures for inline assembly code which
relies on assumptions about earlier compiler's behaviour.


Thiemo

From macro@linux-mips.org Wed Dec  1 21:50:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 21:50:56 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:35849 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225979AbULAVuv>; Wed, 1 Dec 2004 21:50:51 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 2C8ACF59C4; Wed,  1 Dec 2004 22:50:44 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 26042-02; Wed,  1 Dec 2004 22:50:44 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 26DDAF59BB; Wed,  1 Dec 2004 22:50:43 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iB1LovVx003190;
	Wed, 1 Dec 2004 22:50:59 +0100
Date: Wed, 1 Dec 2004 21:50:45 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
In-Reply-To: <20041201123336.GA5612@linux-mips.org>
Message-ID: <Pine.LNX.4.58L.0412012136480.13579@blysk.ds.pg.gda.pl>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
 <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201123336.GA5612@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/605/Wed Nov 24 15:09:47 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6528
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, 1 Dec 2004, Ralf Baechle wrote:

> this problem here is specific to inline assembler.  The splitlock code for
> a reasonable CPU is:
> 
> static __inline__ void atomic_add(int i, atomic_t * v)
> {
>         unsigned long temp;
> 
>         __asm__ __volatile__(
>         "1:     ll      %0, %1          # atomic_add            \n"
>         "       addu    %0, %2                                  \n"
>         "       sc      %0, %1                                  \n"
>         "       beqz    %0, 1b                                  \n"
>         : "=&r" (temp), "=m" (v->counter)
>         : "Ir" (i), "m" (v->counter));
> }
> 
> For the average atomic op generated code is going to look about like:
> 
> 80100634:       lui     a0,0x802c
> 80100638:       ll      a0,-24160(a0)
> 8010063c:       addu    a0,a0,v0
> 80100640:       lui     at,0x802c
> 80100644:       addu    at,at,v1
> 80100648:       sc      a0,-24160(at)
> 8010064c:       beqz    a0,80100634 <init+0x194>
> 80100650:       nop
> 
> It's significantly worse for 64-bit due to the excessive code sequence
> generated for loading a 64-bit address.  One outside CKSEGx that is.

 Only for old compilers.  For current (>= 3.4) ones you can use the "R"  
constraint and get exactly what you need.  Rewriting inline asms to use
"R" for GCC >= 3.4 has actually been on my to-do list for some time;  
predating the current working implementation even.

> On 32-bit Thiemo's patch would cut that down to something like:
> 
> 80100630:       lui     t0,0x802c
> 80100634:       addiu	t0,t0,-24160
> 80100638:       ll      a0,0(t0)
> 8010063c:       addu    a0,a0,v0
> 80100648:       sc      a0,0(to)
> 8010064c:       beqz    a0,80100638 <init+0x194>
> 80100650:       nop

 Plus it clobbers memory requiring a writeback and a refetch of all
unrelated variables that have happened to be cached in registers.

> On 64-bit the savings would be even more significant.  But what we actually
> want would be using the "o" constraint.  Which just at least on the
> compilers where I've tried it, didn't produce code any different from "m".

 No surprise as the "o" constraint doesn't mean anything particular for
MIPS.  All addresses are offsettable -- there is no addressing mode that
would preclude it, so "o" is exactly the same as "m".

> The expected code would be something like:
> 
> 80100634:       lui     t0,0x802c
> 80100638:       ll      a0,-24160(t0)
> 8010063c:       addu    a0,a0,v0
> 80100648:       sc      a0,-24160(to)
> 8010064c:       beqz    a0,80100634 <init+0x194>
> 80100650:       nop
> 
> So another instruction less.

 That's exactly what's emitted with "R".  Should I accelerate my work on
it?  It's nothing that would require a lot of effort -- it's more boring 
than challenging.

  Maciej

From macro@linux-mips.org Wed Dec  1 21:53:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 21:53:41 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:59658 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225984AbULAVxg>; Wed, 1 Dec 2004 21:53:36 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 47C22F59C6; Wed,  1 Dec 2004 22:53:30 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 31859-02; Wed,  1 Dec 2004 22:53:30 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id ACD0BF59BB; Wed,  1 Dec 2004 22:53:28 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iB1LrixQ003396;
	Wed, 1 Dec 2004 22:53:44 +0100
Date: Wed, 1 Dec 2004 21:53:32 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	ralf@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
In-Reply-To: <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
 <16813.39660.948092.328493@doms-laptop.algor.co.uk>
 <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/605/Wed Nov 24 15:09:47 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6529
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, 1 Dec 2004, Thiemo Seufer wrote:

> The compiler was improved with PIC code in mind. The kernel is
> non-PIC, and can't allow explicit relocs by the compiler because
> of the weird code model used for 64bit kernels. This led to some
> degradation and even subtle failures for inline assembly code which
> relies on assumptions about earlier compiler's behaviour.

 What do you mean by "the weird code model" and what failures have you 
observed?  I think the bits are worth being done correctly, so I'd like 
to know what problems to address.

  Maciej

From ica2_ts@csv.ica.uni-stuttgart.de Wed Dec  1 23:03:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 23:03:48 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:39770
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8226049AbULAXDg>; Wed, 1 Dec 2004 23:03:36 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CZdVV-00078r-00; Thu, 02 Dec 2004 00:03:33 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CZdVU-0005mf-00; Thu, 02 Dec 2004 00:03:32 +0100
Date: Thu, 2 Dec 2004 00:03:32 +0100
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	ralf@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
Message-ID: <20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6530
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
> On Wed, 1 Dec 2004, Thiemo Seufer wrote:
> 
> > The compiler was improved with PIC code in mind. The kernel is
> > non-PIC, and can't allow explicit relocs by the compiler because
> > of the weird code model used for 64bit kernels. This led to some
> > degradation and even subtle failures for inline assembly code which
> > relies on assumptions about earlier compiler's behaviour.
> 
>  What do you mean by "the weird code model" and what failures have you 
> observed?  I think the bits are worth being done correctly, so I'd like 
> to know what problems to address.

I had guessed you already know what i mean. :-)

Current 64bit MIPS kernels run in (C)KSEG0, and exploit sign-extension
to optimize symbol loads (2 instead of 6/7 instructions, the same as in
32bit kernels). This optimization relies on an assembler macro
expansion mode which was hacked in gas for exactly this purpose. Gcc
currently doesn't have something similiar, and would try to do a regular
64bit load with explicit relocs.

I discussed this with Richard Sandiford a while ago, and the conclusion
was to implement an explicit --msym32 option for both gcc and gas to
improve register scheduling and get rid of the gas hack. So far, nobody
came around to actually do the work for it.

For the "subtle failures" part, we had some gas failures to handle dla
because of the changed arguments. For userland (PIC) code, I've also
seen additional load/store insn creeping in ll/sc loops. I believe
there's a large amount of inline assembly code (not necessarily in the
kernel) which relies on similiar assumptions.


Thiemo

From ralf@linux-mips.org Wed Dec  1 23:41:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Dec 2004 23:41:47 +0000 (GMT)
Received: from p508B7F35.dip.t-dialin.net ([IPv6:::ffff:80.139.127.53]:19331
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226085AbULAXlm>; Wed, 1 Dec 2004 23:41:42 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB1Ndfpt003120;
	Thu, 2 Dec 2004 00:39:41 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB1Ndf3H003109;
	Thu, 2 Dec 2004 00:39:41 +0100
Date: Thu, 2 Dec 2004 00:39:41 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
Message-ID: <20041201233940.GA15116@linux-mips.org>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201123336.GA5612@linux-mips.org> <Pine.LNX.4.58L.0412012136480.13579@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58L.0412012136480.13579@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6531
X-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, Dec 01, 2004 at 09:50:45PM +0000, Maciej W. Rozycki wrote:

>  No surprise as the "o" constraint doesn't mean anything particular for
> MIPS.  All addresses are offsettable -- there is no addressing mode that
> would preclude it, so "o" is exactly the same as "m".

This is what the gcc docs say:

[...]
`o'
     A memory operand is allowed, but only if the address is
     "offsettable".  This means that adding a small integer (actually,
     the width in bytes of the operand, as determined by its machine
     mode) may be added to the address and the result is also a valid
     memory address.

     For example, an address which is constant is offsettable; so is an
     address that is the sum of a register and a constant (as long as a
     slightly larger constant is also within the range of
     address-offsets supported by the machine); but an autoincrement or
     autodecrement address is not offsettable.  More complicated
     indirect/indexed addresses may or may not be offsettable depending
     on the other addressing modes that the machine supports.
[...]

So it is not the same as "m".

  Ralf

From macro@linux-mips.org Thu Dec  2 00:01:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 00:01:13 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:37905 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226123AbULBABI>; Thu, 2 Dec 2004 00:01:08 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id DD948E1C94; Thu,  2 Dec 2004 01:01:00 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 18304-06; Thu,  2 Dec 2004 01:01:00 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 60660E1C61; Thu,  2 Dec 2004 01:01:00 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iB201Fn4012373;
	Thu, 2 Dec 2004 01:01:18 +0100
Date: Thu, 2 Dec 2004 00:01:02 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
In-Reply-To: <20041201233940.GA15116@linux-mips.org>
Message-ID: <Pine.LNX.4.58L.0412012359190.20966@blysk.ds.pg.gda.pl>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
 <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201123336.GA5612@linux-mips.org>
 <Pine.LNX.4.58L.0412012136480.13579@blysk.ds.pg.gda.pl>
 <20041201233940.GA15116@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/605/Wed Nov 24 15:09:47 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6532
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, 2 Dec 2004, Ralf Baechle wrote:

> >  No surprise as the "o" constraint doesn't mean anything particular for
> > MIPS.  All addresses are offsettable -- there is no addressing mode that
> > would preclude it, so "o" is exactly the same as "m".
> 
> This is what the gcc docs say:
[...]
> So it is not the same as "m".

 It is the same *for* MIPS.  Not in general.

  Maciej

From ica2_ts@csv.ica.uni-stuttgart.de Thu Dec  2 00:07:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 00:07:23 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:59995
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8226132AbULBAHS>; Thu, 2 Dec 2004 00:07:18 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CZeV8-0007u8-00; Thu, 02 Dec 2004 01:07:14 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CZeV7-000612-00; Thu, 02 Dec 2004 01:07:13 +0100
Date: Thu, 2 Dec 2004 01:07:13 +0100
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] tlbwr hazard for NEC VR4100
Message-ID: <20041202000713.GO3225@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041201234943.584d88e8.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041201234943.584d88e8.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6533
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Yoichi Yuasa wrote:
> Hi Ralf,
> 
> This patch had added tlbwr hazard for NEC VR4100.
> Please apply this patch to 2.6.
> 
> Yoichi
> 
> Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
> 
> diff -urN -X dontdiff a-orig/arch/mips/mm/tlbex.c a/arch/mips/mm/tlbex.c
> --- a-orig/arch/mips/mm/tlbex.c	Tue Nov 30 20:42:08 2004
> +++ a/arch/mips/mm/tlbex.c	Wed Dec  1 23:23:11 2004
> @@ -820,6 +820,25 @@
>  		i_ssnop(p);
>  		break;
>  
> +	case CPU_VR4111:
> +	case CPU_VR4121:
> +	case CPU_VR4122:
> +	case CPU_VR4181:
> +	case CPU_VR4181A:
> +		i_nop(p);
> +		i_nop(p);
> +		i_tlbwr(p);
> +		i_nop(p);
> +		i_nop(p);
> +		break;
> +
> +	case CPU_VR4131:
> +	case CPU_VR4133:
> +		i_nop(p);
> +		i_nop(p);
> +		i_tlbwr(p);
> +		break;

If 64bit kernels are ever relevant for VR41xx, you might want to use
the same branch trick as it is used for R4[04]00. IIRC it reduced the
handler size from 34 to 30 instructions, saving another branch.

(If the XTLB refill handler doesn't fit in 32 instructions, it wraps
around to the 32bit TLB handler space and continues there. This costs
1-3 additional instructions.)


Thiemo

From macro@linux-mips.org Thu Dec  2 00:17:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 00:18:09 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:3344 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226148AbULBAR6>; Thu, 2 Dec 2004 00:17:58 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 341A8E1C94; Thu,  2 Dec 2004 01:17:51 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 18455-04; Thu,  2 Dec 2004 01:17:51 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id D3067E1C61; Thu,  2 Dec 2004 01:17:50 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iB20I98N013865;
	Thu, 2 Dec 2004 01:18:09 +0100
Date: Thu, 2 Dec 2004 00:17:56 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	ralf@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
In-Reply-To: <20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.58L.0412020001340.20966@blysk.ds.pg.gda.pl>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
 <16813.39660.948092.328493@doms-laptop.algor.co.uk>
 <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de>
 <Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl>
 <20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/605/Wed Nov 24 15:09:47 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6534
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, 2 Dec 2004, Thiemo Seufer wrote:

> >  What do you mean by "the weird code model" and what failures have you 
> > observed?  I think the bits are worth being done correctly, so I'd like 
> > to know what problems to address.
> 
> I had guessed you already know what i mean. :-)
> 
> Current 64bit MIPS kernels run in (C)KSEG0, and exploit sign-extension
> to optimize symbol loads (2 instead of 6/7 instructions, the same as in
> 32bit kernels). This optimization relies on an assembler macro
> expansion mode which was hacked in gas for exactly this purpose. Gcc
> currently doesn't have something similiar, and would try to do a regular
> 64bit load with explicit relocs.

 Ah *that*.  Well, sorry -- I tend to forget about the hack as I've never
used it.  I think a valid solution is either to use CONFIG_BUILD_ELF64
(now that it is there) or to modify tools to implement it correctly...

> I discussed this with Richard Sandiford a while ago, and the conclusion
> was to implement an explicit --msym32 option for both gcc and gas to
> improve register scheduling and get rid of the gas hack. So far, nobody
> came around to actually do the work for it.

 ... like this, for example.  But if nobody has implemented it yet, then 
perhaps nobody is really interested in it? ;-)

> For the "subtle failures" part, we had some gas failures to handle dla
> because of the changed arguments. For userland (PIC) code, I've also

 I recall this -- I've thought the more or less agreed consensus was to
forbid or at least strongly discourage "dla" and "la" macros expanded
within inline asms and referring to an address operand to be provided by
GCC based on a constraint.

 Otherwise there is still my patch to gas available as an alternative. ;-)

> seen additional load/store insn creeping in ll/sc loops. I believe
> there's a large amount of inline assembly code (not necessarily in the
> kernel) which relies on similiar assumptions.

 With explicit relocs you have no problem with any instructions appearing 
inside inline asms unexpectedly.  That is if you use the "R" constraint -- 
the "m" one never guaranteed that.

  Maciej

From macro@linux-mips.org Thu Dec  2 00:24:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 00:24:40 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:47367 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226154AbULBAYc>; Thu, 2 Dec 2004 00:24:32 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id C51D9E1C94; Thu,  2 Dec 2004 01:24:25 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 01510-01; Thu,  2 Dec 2004 01:24:25 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 5F4DDE1C61; Thu,  2 Dec 2004 01:24:25 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iB20OhlV014221;
	Thu, 2 Dec 2004 01:24:44 +0100
Date: Thu, 2 Dec 2004 00:24:30 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] tlbwr hazard for NEC VR4100
In-Reply-To: <20041202000713.GO3225@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.58L.0412020019050.20966@blysk.ds.pg.gda.pl>
References: <20041201234943.584d88e8.yuasa@hh.iij4u.or.jp>
 <20041202000713.GO3225@rembrandt.csv.ica.uni-stuttgart.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/605/Wed Nov 24 15:09:47 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6535
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, 2 Dec 2004, Thiemo Seufer wrote:

> If 64bit kernels are ever relevant for VR41xx, you might want to use
> the same branch trick as it is used for R4[04]00. IIRC it reduced the
> handler size from 34 to 30 instructions, saving another branch.

 Isn't that based on specific properties of the R4[04]00 pipeline?  It may
still work for the VR41xx, but you can't take it for granted, so it should
be double-checked.  Given the conditions it's probably worth the hassle,
though.

  Maciej

From mlachwani@prometheus.mvista.com Thu Dec  2 00:33:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 00:33:15 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:9711 "EHLO
	prometheus.mvista.com") by linux-mips.org with ESMTP
	id <S8226165AbULBAdK>; Thu, 2 Dec 2004 00:33:10 +0000
Received: from prometheus.mvista.com (localhost.localdomain [127.0.0.1])
	by prometheus.mvista.com (8.12.8/8.12.8) with ESMTP id iB20X8dh013093;
	Wed, 1 Dec 2004 16:33:08 -0800
Received: (from mlachwani@localhost)
	by prometheus.mvista.com (8.12.8/8.12.8/Submit) id iB20X80r013091;
	Wed, 1 Dec 2004 16:33:08 -0800
Date: Wed, 1 Dec 2004 16:33:08 -0800
From: Manish Lachwani <mlachwani@mvista.com>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
Subject: [PATCH] 2.4: Preemption fixes for Broadcom DMA Page operations
Message-ID: <20041202003308.GA13085@prometheus.mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="M9NhX3UHpAaciwkO"
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <mlachwani@prometheus.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: 6536
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips


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

Hello !

The attached patch implements preempt_disable/preempt_enable around the SB1 DMA
page operations. Please review ...

Thanks
Manish Lachwani

--M9NhX3UHpAaciwkO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline; filename=patch-bcm91125-dma

--- arch/mips/mm/pg-sb1.c.orig	2004-12-01 10:59:53.000000000 -0800
+++ arch/mips/mm/pg-sb1.c	2004-12-01 11:08:59.000000000 -0800
@@ -157,7 +157,11 @@
 
 void sb1_dma_init(void)
 {
-	int cpu = smp_processor_id();
+	int cpu;
+
+	preempt_disable();
+
+	cpu = smp_processor_id();
 	uint64_t base_val = PHYSADDR(&page_descr[cpu]) | V_DM_DSCR_BASE_RINGSZ(1);
 
 	out64(base_val,
@@ -166,15 +170,23 @@
 	      IO_SPACE_BASE + A_DM_REGISTER(cpu, R_DM_DSCR_BASE));
 	out64(base_val | M_DM_DSCR_BASE_ENABL,
 	      IO_SPACE_BASE + A_DM_REGISTER(cpu, R_DM_DSCR_BASE));
+
+	preempt_enable();
 }
 
 void sb1_clear_page_dma(void *page)
 {
-	int cpu = smp_processor_id();
+	int cpu;
+
+	preempt_disable();
+
+	cpu = smp_processor_id();
 
 	/* if the page is above Kseg0, use old way */
-	if (KSEGX(page) != K0BASE)
+	if (KSEGX(page) != K0BASE) {
+		preempt_enable();
 		return sb1_clear_page(page);
+	}
 
 	page_descr[cpu].dscr_a = PHYSADDR(page) | M_DM_DSCRA_ZERO_MEM | M_DM_DSCRA_L2C_DEST | M_DM_DSCRA_INTERRUPT;
 	page_descr[cpu].dscr_b = V_DM_DSCRB_SRC_LENGTH(PAGE_SIZE);
@@ -187,17 +199,27 @@
 	while (!(in64(IO_SPACE_BASE + A_DM_REGISTER(cpu, R_DM_DSCR_BASE_DEBUG)) & M_DM_DSCR_BASE_INTERRUPT))
 		;
 	in64(IO_SPACE_BASE + A_DM_REGISTER(cpu, R_DM_DSCR_BASE));
+
+	preempt_enable();
 }
 
 void sb1_copy_page_dma(void *to, void *from)
 {
-	unsigned long from_phys = PHYSADDR(from);
-	unsigned long to_phys = PHYSADDR(to);
-	int cpu = smp_processor_id();
+	unsigned long from_phys;
+	unsigned long to_phys;
+	int cpu;
+
+	preempt_disable();
+
+	from_phys = PHYSADDR(from);
+	to_phys = PHYSADDR(to);
+	cpu = smp_processor_id();
 
 	/* if either page is above Kseg0, use old way */
-	if ((KSEGX(to) != K0BASE) || (KSEGX(from) != K0BASE))
+	if ((KSEGX(to) != K0BASE) || (KSEGX(from) != K0BASE)) {
+		preempt_enable();
 		return sb1_copy_page(to, from);
+	}
 
 	page_descr[cpu].dscr_a = PHYSADDR(to_phys) | M_DM_DSCRA_L2C_DEST | M_DM_DSCRA_INTERRUPT;
 	page_descr[cpu].dscr_b = PHYSADDR(from_phys) | V_DM_DSCRB_SRC_LENGTH(PAGE_SIZE);
@@ -210,6 +232,8 @@
 	while (!(in64(IO_SPACE_BASE + A_DM_REGISTER(cpu, R_DM_DSCR_BASE_DEBUG)) & M_DM_DSCR_BASE_INTERRUPT))
 		;
 	in64(IO_SPACE_BASE + A_DM_REGISTER(cpu, R_DM_DSCR_BASE));
+
+	preempt_enable();
 }
 
 #endif
--- drivers/char/Config.in.orig	2004-12-01 10:33:59.000000000 -0800
+++ drivers/char/Config.in	2004-12-01 10:34:22.000000000 -0800
@@ -178,7 +178,7 @@
          define_bool CONFIG_AU1X00_USB_DEVICE y
          fi
       fi
-      if [ "$CONFIG_SIBYTE_SB1250" = "y" ]; then
+      if [ "$CONFIG_SIBYTE_BOARD" = "y" ]; then
          bool '  Support for sb1250 onchip DUART' CONFIG_SIBYTE_SB1250_DUART
          if [ "$CONFIG_SIBYTE_SB1250_DUART" = "y" ]; then
             bool '  Console on SB1250 DUART' CONFIG_SIBYTE_SB1250_DUART_CONSOLE
--- drivers/net/Config.in.orig	2004-12-01 10:41:37.000000000 -0800
+++ drivers/net/Config.in	2004-12-01 10:41:46.000000000 -0800
@@ -104,7 +104,7 @@
    if [ "$CONFIG_IDT_79EB434" = "y" ]; then
       bool '  IDT RC32434 Ethernet support' CONFIG_IDT_RC32434_ETH
    fi
-   if [ "$CONFIG_SIBYTE_SB1250" = "y" ]; then
+   if [ "$CONFIG_SIBYTE_BOARD" = "y" ]; then
       tristate '  SB1250 Ethernet support' CONFIG_NET_SB1250_MAC
    fi
    if [ "$CONFIG_SGI_IP27" = "y" ]; then

--M9NhX3UHpAaciwkO--

From ralf@linux-mips.org Thu Dec  2 00:49:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 00:49:54 +0000 (GMT)
Received: from p508B7F35.dip.t-dialin.net ([IPv6:::ffff:80.139.127.53]:32900
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226180AbULBAtu>; Thu, 2 Dec 2004 00:49:50 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB20nnqK007171;
	Thu, 2 Dec 2004 01:49:49 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB20niEv007170;
	Thu, 2 Dec 2004 01:49:44 +0100
Date: Thu, 2 Dec 2004 01:49:44 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Manish Lachwani <mlachwani@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] 2.4: Preemption fixes for Broadcom DMA Page operations
Message-ID: <20041202004944.GB5187@linux-mips.org>
References: <20041202003308.GA13085@prometheus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041202003308.GA13085@prometheus.mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6537
X-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, Dec 01, 2004 at 04:33:08PM -0800, Manish Lachwani wrote:

> The attached patch implements preempt_disable/preempt_enable around the SB1 DMA
> page operations. Please review ...

We don't support preemption in 2.4 -> bitbucket.

  Ralf

From macro@linux-mips.org Thu Dec  2 00:52:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 00:52:20 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:27143 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226182AbULBAwP>; Thu, 2 Dec 2004 00:52:15 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 5901BE1C94; Thu,  2 Dec 2004 01:52:08 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 11712-09; Thu,  2 Dec 2004 01:52:08 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id DD581E1C61; Thu,  2 Dec 2004 01:52:07 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iB20qHG1015268;
	Thu, 2 Dec 2004 01:52:18 +0100
Date: Thu, 2 Dec 2004 00:52:04 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Manish Lachwani <mlachwani@mvista.com>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: [PATCH] 2.4: Preemption fixes for Broadcom DMA Page operations
In-Reply-To: <20041202003308.GA13085@prometheus.mvista.com>
Message-ID: <Pine.LNX.4.58L.0412020041420.20966@blysk.ds.pg.gda.pl>
References: <20041202003308.GA13085@prometheus.mvista.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/605/Wed Nov 24 15:09:47 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6538
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, 1 Dec 2004, Manish Lachwani wrote:

> The attached patch implements preempt_disable/preempt_enable around the
> SB1 DMA page operations. Please review ...

 Why is it needed?

 Also I think these:

-   if [ "$CONFIG_SIBYTE_SB1250" = "y" ]; then
+   if [ "$CONFIG_SIBYTE_BOARD" = "y" ]; then

are unrelated and inaccurate.  The devices are internal to the SoCs and 
not strictly board-dependent.  How about:

+   if [ "$CONFIG_SIBYTE_SB1250" = "y" || "$CONFIG_SIBYTE_BCM112X" = "y"]; then

at the very least, or perhaps using reverse dependencies?

 Maciej

From mlachwani@mvista.com Thu Dec  2 00:58:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 00:58:31 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:21495 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8226189AbULBA60>; Thu, 2 Dec 2004 00:58:26 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id 55FB61871B; Wed,  1 Dec 2004 16:58:19 -0800 (PST)
Message-ID: <41AE68AB.8010801@mvista.com>
Date: Wed, 01 Dec 2004 16:58:19 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: [PATCH] 2.4: Preemption fixes for Broadcom DMA Page operations
References: <20041202003308.GA13085@prometheus.mvista.com> <Pine.LNX.4.58L.0412020041420.20966@blysk.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.58L.0412020041420.20966@blysk.ds.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6539
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

Hi Maciej,

Maciej W. Rozycki wrote:
> On Wed, 1 Dec 2004, Manish Lachwani wrote:
> 
> 
>>The attached patch implements preempt_disable/preempt_enable around the
>>SB1 DMA page operations. Please review ...
> 
> 
>  Why is it needed?
> 
>  Also I think these:
> 
> -   if [ "$CONFIG_SIBYTE_SB1250" = "y" ]; then
> +   if [ "$CONFIG_SIBYTE_BOARD" = "y" ]; then
> 
> are unrelated and inaccurate.  The devices are internal to the SoCs and 
> not strictly board-dependent.  How about:
> 
> +   if [ "$CONFIG_SIBYTE_SB1250" = "y" || "$CONFIG_SIBYTE_BCM112X" = "y"]; then

Actually, this makes more sense. I will send a new patch

Thanks
Manish Lachwani

> 
> at the very least, or perhaps using reverse dependencies?
> 
>  Maciej



From ica2_ts@csv.ica.uni-stuttgart.de Thu Dec  2 01:02:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 01:02:35 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:59740
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8226196AbULBBCa>; Thu, 2 Dec 2004 01:02:30 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CZfMc-0008U8-00; Thu, 02 Dec 2004 02:02:30 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CZfMb-0006EA-00; Thu, 02 Dec 2004 02:02:29 +0100
Date: Thu, 2 Dec 2004 02:02:29 +0100
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	ralf@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
Message-ID: <20041202010229.GP3225@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl> <20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.58L.0412020001340.20966@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58L.0412020001340.20966@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6540
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
[snip]
> > I discussed this with Richard Sandiford a while ago, and the conclusion
> > was to implement an explicit --msym32 option for both gcc and gas to
> > improve register scheduling and get rid of the gas hack. So far, nobody
> > came around to actually do the work for it.
> 
>  ... like this, for example.  But if nobody has implemented it yet, then 
> perhaps nobody is really interested in it? ;-)

The old solution works, and kernel developers tend to use old toolchains.

> > seen additional load/store insn creeping in ll/sc loops. I believe
> > there's a large amount of inline assembly code (not necessarily in the
> > kernel) which relies on similiar assumptions.
> 
>  With explicit relocs you have no problem with any instructions appearing 
> inside inline asms unexpectedly.  That is if you use the "R" constraint -- 
> the "m" one never guaranteed that.

But it happened to work, and is in widespread use.


Thiemo

From yuasa@hh.iij4u.or.jp Thu Dec  2 01:56:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 01:56:52 +0000 (GMT)
Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:14801 "EHLO
	mo00.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226232AbULBB4r>;
	Thu, 2 Dec 2004 01:56:47 +0000
Received: MO(mo00)id iB21uC43004052; Thu, 2 Dec 2004 10:56:12 +0900 (JST)
Received: MDO(mdo01) id iB21uB6Z028090; Thu, 2 Dec 2004 10:56:12 +0900 (JST)
Received: 4UMRO01 id iB21uBR8002349; Thu, 2 Dec 2004 10:56:11 +0900 (JST)
	from rally (localhost [127.0.0.1]) (authenticated)
Date: Thu, 2 Dec 2004 10:56:26 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: "Maciej W. Rozycki" <macro@linux-mips.org>,
	ica2_ts@csv.ica.uni-stuttgart.de
Cc: yuasa@hh.iij4u.or.jp, ralf@linux-mips.org,
	linux-mips@linux-mips.org
Subject: Re: [PATCH 2.6] tlbwr hazard for NEC VR4100
Message-Id: <20041202105626.46056a37.yuasa@hh.iij4u.or.jp>
In-Reply-To: <Pine.LNX.4.58L.0412020019050.20966@blysk.ds.pg.gda.pl>
References: <20041201234943.584d88e8.yuasa@hh.iij4u.or.jp>
	<20041202000713.GO3225@rembrandt.csv.ica.uni-stuttgart.de>
	<Pine.LNX.4.58L.0412020019050.20966@blysk.ds.pg.gda.pl>
X-Mailer: Sylpheed version 1.0.0beta3 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6541
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

On Thu, 2 Dec 2004 00:24:30 +0000 (GMT)
"Maciej W. Rozycki" <macro@linux-mips.org> wrote:

> On Thu, 2 Dec 2004, Thiemo Seufer wrote:
> 
> > If 64bit kernels are ever relevant for VR41xx, you might want to use
> > the same branch trick as it is used for R4[04]00. IIRC it reduced the
> > handler size from 34 to 30 instructions, saving another branch.
> 
>  Isn't that based on specific properties of the R4[04]00 pipeline?  It may
> still work for the VR41xx, but you can't take it for granted, so it should
> be double-checked.  Given the conditions it's probably worth the hassle,
> though.

The specification of VR41xx does not have the guarantee to the branch trick.
Furthermore, VR41xx has the NEC original pipeline.

I think that the present method is exact for VR41xx.

Yoichi

From sjhill@realitydiluted.com Thu Dec  2 03:56:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 03:56:56 +0000 (GMT)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:55229 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225348AbULBD4v>; Thu, 2 Dec 2004 03:56:51 +0000
Received: from localhost ([127.0.0.1])
	by real.realitydiluted.com with esmtp (Exim 4.34 #1 (Debian))
	id 1CZi59-0003wh-Lu; Wed, 01 Dec 2004 21:56:42 -0600
Message-ID: <41AE9390.80705@realitydiluted.com>
Date: Wed, 01 Dec 2004 22:01:20 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5
X-Accept-Language: en
MIME-Version: 1.0
To: Manish Lachwani <mlachwani@mvista.com>
CC: linux-mips@linux-mips.org
Subject: Re: [PATCH] Broadcom SWARM IDE in 2.6
References: <20041130230022.GA17202@prometheus.mvista.com>
In-Reply-To: <20041130230022.GA17202@prometheus.mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6542
X-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

Manish Lachwani wrote:
> 
> I had sent an incomplete patch before. Please try out this new patch, attached.
> Let me know if it works
> 
Manish,

This patch worked, however you need to fix a compiler warning before I am
willing to commit it. Please get rid of the warning shown below and submit
a new patch. Thanks!

-Steve

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

CC      drivers/ide/ide-generic.o
In file included from drivers/ide/ide-generic.c:13:
include/linux/ide.h:277:1: warning: "ide_init_default_irq" redefined
In file included from include/asm/ide.h:11,
                  from include/linux/ide.h:271,
                  from drivers/ide/ide-generic.c:13:
include/asm-mips/mach-generic/ide.h:64:1: warning: this is the location of the 
previous definition

From dom@mips.com Thu Dec  2 08:01:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 08:01:54 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:19716 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225072AbULBIBs>;
	Thu, 2 Dec 2004 08:01:48 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1CZm1j-0005uS-00; Thu, 02 Dec 2004 08:09:23 +0000
Received: from olympia.mips.com ([192.168.192.128] helo=doms-laptop.algor.co.uk)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1CZlu7-0001AF-00; Thu, 02 Dec 2004 08:01:32 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16814.52180.502747.597080@doms-laptop.algor.co.uk>
Date: Thu, 2 Dec 2004 08:01:24 +0000
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	ralf@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
In-Reply-To: <20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
	<16813.39660.948092.328493@doms-laptop.algor.co.uk>
	<20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de>
	<Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl>
	<20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de>
X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.831, required 4, AWL,
	BAYES_00)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6543
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips


Thiemo,

> I had guessed you already know what i mean. :-)

Generally a bad guess, of course...

> Current 64bit MIPS kernels run in (C)KSEG0, and exploit sign-extension
> to optimize symbol loads (2 instead of 6/7 instructions, the same as in
> 32bit kernels).

Gross... yet ingenious. I see the problem.  You want to use a
32-bit-pointer "la" for the addresses of static variables in the
kernel build (which works, because the kernel is in the
32-bit-pointer-accessible 'kseg0').

The assembler macro was a very Linux solution, if you don't mind my
saying so...  A more native compiler fix would probably be a good
idea.

What ABI are you using for the 64-bit kernel build (n64? how do you
get it to build non-PIC?)  And what constraints are there on
your choice of gcc version? - it would be easier if 3.4 was OK.

--
Dominic Sweetman
MIPS Technologies


From ica2_ts@csv.ica.uni-stuttgart.de Thu Dec  2 08:39:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 08:39:06 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:25441
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225074AbULBIjB>; Thu, 2 Dec 2004 08:39:01 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CZmUN-0003uj-00; Thu, 02 Dec 2004 09:38:59 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CZmUN-0007ul-00; Thu, 02 Dec 2004 09:38:59 +0100
Date: Thu, 2 Dec 2004 09:38:59 +0100
To: Dominic Sweetman <dom@mips.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	linux-mips@linux-mips.org, ralf@linux-mips.org,
	Nigel Stephens <nigel@mips.com>, David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
Message-ID: <20041202083859.GU3225@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl> <20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de> <16814.52180.502747.597080@doms-laptop.algor.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16814.52180.502747.597080@doms-laptop.algor.co.uk>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6544
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Dominic Sweetman wrote:
> 
> Thiemo,
> 
> > I had guessed you already know what i mean. :-)
> 
> Generally a bad guess, of course...
> 
> > Current 64bit MIPS kernels run in (C)KSEG0, and exploit sign-extension
> > to optimize symbol loads (2 instead of 6/7 instructions, the same as in
> > 32bit kernels).
> 
> Gross... yet ingenious. I see the problem.  You want to use a
> 32-bit-pointer "la" for the addresses of static variables in the
> kernel build (which works, because the kernel is in the
> 32-bit-pointer-accessible 'kseg0').

Except that the compiler emits a "dla", but the assembler expands
it like "la". :-)

> The assembler macro was a very Linux solution, if you don't mind my
> saying so...  A more native compiler fix would probably be a good
> idea.
> 
> What ABI are you using for the 64-bit kernel build (n64? how do you
> get it to build non-PIC?)

The ABIs are generally only defined for PIC code, the 64bit kernel uses
the n64 non-PIC alike. Building as non-PIC is simple, via
-mabi=64 -fno-PIC -mno-abicalls

> And what constraints are there on
> your choice of gcc version? - it would be easier if 3.4 was OK.

3.2/3.3 are known to work. 3.4 fails for yet unknown reason, I guess
either due to inline assembler changes or more agressive dead code
elimination.


Thiemo

From geoman@gentoo.org Thu Dec  2 11:30:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 11:30:58 +0000 (GMT)
Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:44503 "EHLO
	lennier.cc.vt.edu") by linux-mips.org with ESMTP
	id <S8225074AbULBLax>; Thu, 2 Dec 2004 11:30:53 +0000
Received: from vivi.cc.vt.edu (IDENT:mirapoint@evil-vivi.cc.vt.edu [10.1.1.12])
	by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id iB2BSMnq019679;
	Thu, 2 Dec 2004 06:28:23 -0500
Received: from [192.168.1.2] (68-232-97-125.chvlva.adelphia.net [68.232.97.125])
	by vivi.cc.vt.edu (MOS 3.4.8-GR)
	with ESMTP id CCQ04524 (AUTH spbecker);
	Thu, 2 Dec 2004 06:30:42 -0500 (EST)
Message-ID: <41AEFCF8.2020804@gentoo.org>
Date: Thu, 02 Dec 2004 06:31:04 -0500
From: "Stephen P. Becker" <geoman@gentoo.org>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041125)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
CC: Dominic Sweetman <dom@mips.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	linux-mips@linux-mips.org, ralf@linux-mips.org,
	Nigel Stephens <nigel@mips.com>, David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl> <20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de> <16814.52180.502747.597080@doms-laptop.algor.co.uk> <20041202083859.GU3225@rembrandt.csv.ica.uni-stuttgart.de>
In-Reply-To: <20041202083859.GU3225@rembrandt.csv.ica.uni-stuttgart.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <geoman@gentoo.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: 6545
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geoman@gentoo.org
Precedence: bulk
X-list: linux-mips


>>And what constraints are there on
>>your choice of gcc version? - it would be easier if 3.4 was OK.
> 
> 
> 3.2/3.3 are known to work. 3.4 fails for yet unknown reason, I guess
> either due to inline assembler changes or more agressive dead code
> elimination.
> 
> 
> Thiemo

For what it's worth, I'm running 64-bit kernels on my O2 and Indy that 
were compiled with gcc 3.4.3, and I have had no problems.

Steve


From macro@linux-mips.org Thu Dec  2 11:54:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 11:54:37 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:45581 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225200AbULBLyc>; Thu, 2 Dec 2004 11:54:32 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id EB08EF59CE; Thu,  2 Dec 2004 12:54:23 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 30369-03; Thu,  2 Dec 2004 12:54:23 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 7CACFF59CD; Thu,  2 Dec 2004 12:54:23 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iB2BsU02015745;
	Thu, 2 Dec 2004 12:54:30 +0100
Date: Thu, 2 Dec 2004 11:54:24 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: "Stephen P. Becker" <geoman@gentoo.org>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	ralf@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
In-Reply-To: <41AEFCF8.2020804@gentoo.org>
Message-ID: <Pine.LNX.4.58L.0412021151100.11480@blysk.ds.pg.gda.pl>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
 <16813.39660.948092.328493@doms-laptop.algor.co.uk>
 <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de>
 <Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl>
 <20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de>
 <16814.52180.502747.597080@doms-laptop.algor.co.uk>
 <20041202083859.GU3225@rembrandt.csv.ica.uni-stuttgart.de> <41AEFCF8.2020804@gentoo.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/605/Wed Nov 24 15:09:47 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6546
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, 2 Dec 2004, Stephen P. Becker wrote:

> For what it's worth, I'm running 64-bit kernels on my O2 and Indy that 
> were compiled with gcc 3.4.3, and I have had no problems.

 Have you used CONFIG_BUILD_ELF64 or not?  The former obviously works for
me; it's the latter that may cause troubles.

  Maciej

From geoman@gentoo.org Thu Dec  2 11:57:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 11:57:40 +0000 (GMT)
Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:30444 "EHLO
	lennier.cc.vt.edu") by linux-mips.org with ESMTP
	id <S8225200AbULBL5f>; Thu, 2 Dec 2004 11:57:35 +0000
Received: from vivi.cc.vt.edu (IDENT:mirapoint@evil-vivi.cc.vt.edu [10.1.1.12])
	by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id iB2BskRf027683;
	Thu, 2 Dec 2004 06:54:46 -0500
Received: from [192.168.1.2] (68-232-97-125.chvlva.adelphia.net [68.232.97.125])
	by vivi.cc.vt.edu (MOS 3.4.8-GR)
	with ESMTP id CCQ08077 (AUTH spbecker);
	Thu, 2 Dec 2004 06:57:05 -0500 (EST)
Message-ID: <41AF0327.4060303@gentoo.org>
Date: Thu, 02 Dec 2004 06:57:27 -0500
From: "Stephen P. Becker" <geoman@gentoo.org>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041125)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@linux-mips.org>
CC: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	ralf@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl> <20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de> <16814.52180.502747.597080@doms-laptop.algor.co.uk> <20041202083859.GU3225@rembrandt.csv.ica.uni-stuttgart.de> <41AEFCF8.2020804@gentoo.org> <Pine.LNX.4.58L.0412021151100.11480@blysk.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.58L.0412021151100.11480@blysk.ds.pg.gda.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <geoman@gentoo.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: 6547
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geoman@gentoo.org
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
> On Thu, 2 Dec 2004, Stephen P. Becker wrote:
> 
> 
>>For what it's worth, I'm running 64-bit kernels on my O2 and Indy that 
>>were compiled with gcc 3.4.3, and I have had no problems.
> 
> 
>  Have you used CONFIG_BUILD_ELF64 or not?  The former obviously works for
> me; it's the latter that may cause troubles.
> 
>   Maciej

I have used CONFIG_BUILD_ELF64 for an O2 kernel that booted, but 
typically I just use the -mabi=o64 hack.

Steve


From klessard@sunrisetelecom.com Thu Dec  2 15:45:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 15:46:02 +0000 (GMT)
Received: from 67-121-164-6.ded.pacbell.net ([IPv6:::ffff:67.121.164.6]:52205
	"EHLO mailserver.sunrisetelecom.com") by linux-mips.org with ESMTP
	id <S8225370AbULBPpv>; Thu, 2 Dec 2004 15:45:51 +0000
Received: from there ([192.168.50.222]) by mailserver.sunrisetelecom.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 2 Dec 2004 07:45:41 -0800
X-KMail-Redirect-From: Karl Lessard <klessard@sunrisetelecom.com>
Subject: Re: au1100fb.c
From: Karl Lessard <klessard@sunrisetelecom.com> (by way of Karl Lessard
	<klessard@sunrisetelecom.com>)
Date: Thu, 2 Dec 2004 10:43:30 -0500
To: =?iso-8859-1?q?J=F8rg=20Ulrich=20Hansen?= <jh@hansen-telecom.dk>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
  boundary="------------Boundary-00=_ICQ3JWJBDIHX28K5NGD6"
Message-ID: <MAILSERVERmOLSSPwQm000009f4@mailserver.sunrisetelecom.com>
X-OriginalArrivalTime: 02 Dec 2004 15:45:41.0971 (UTC) FILETIME=[FA97AA30:01C4D885]
Return-Path: <klessard@sunrisetelecom.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: 6548
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: klessard@sunrisetelecom.com
Precedence: bulk
X-list: linux-mips


--------------Boundary-00=_ICQ3JWJBDIHX28K5NGD6
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Hi Jørg,

I've modified it a little bit since I've post it on the list, so here's the
.c/.h files I use now, and a patch that should also apply. This should work 
with current linux-mips cvs (actually it do on a 22/11/04 snapshot).

I've never tested it on other boards that the pb1100 though. Also, I use the
same scheme as in Linux 2.4, i.e. panels supported are declared in au1100fb.h.

I hope this will work for you, and don't hesitate to interrupt me if you have
any questions/problems. We personnally decided to work with a different 
graphic chip, so I probably don't need your version of the driver but thanks 
for offering it!

Regards,
Karl



Jørg Ulrich Hansen wrote:

Hi Karl

Sorry to disturb you, but I can see that you have a framebuffer for au1100
for Linux 2.6.
I have also done the same work but I have some problems with nano-X that I
belive is the framebuffers fault.

Your patch that I found on the list I am having problems with to apply.

Do you mind to send me your version of the framebuffer either directly or to
the list.

If you are interrested you can have my version of au1100fb.c/h as well.

Kind regards Jorg

--------------<<<<<<<<<OOOOOOOO>>>>>>>>>--------------
Jorg Hansen               email: jh@hansen-telecom.dk
Hansen Telecom            Tel: +45 7342 0220
Ellegaardvej 36           Fax: +45 7342 0221
6400 Sonderborg           Mob: +45 2819 1969
Denmark                   http://www.hansen-telecom.dk

Modules for rapid design of mechatronic products
       http://www.mechatronicbrick.dk
--------------<<<<<<<<<OOOOOOOO>>>>>>>>>--------------



--------------Boundary-00=_ICQ3JWJBDIHX28K5NGD6
Content-Type: text/x-diff;
  charset="iso-8859-1";
  name="au1100fb.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="au1100fb.patch"

LS0tIGRyaXZlcnMvdmlkZW8vTWFrZWZpbGUJV2VkIERlYyAgMSAxNTowMjozMyAyMDA0CisrKyBk
cml2ZXJzL3ZpZGVvL01ha2VmaWxlLnBhdGNoZWQJV2VkIERlYyAgMSAxNTowMTo1MyAyMDA0CkBA
IC05NCw3ICs5NCw3IEBACiBvYmotJChDT05GSUdfRkJfUE1BR0JfQikJICArPSBwbWFnYi1iLWZi
Lm8gIGNmYmZpbGxyZWN0Lm8gY2ZiY29weWFyZWEubyBjZmJpbWdibHQubwogb2JqLSQoQ09ORklH
X0ZCX01BWElORSkJCSAgKz0gbWF4aW5lZmIubyAgY2ZiZmlsbHJlY3QubyBjZmJjb3B5YXJlYS5v
IGNmYmltZ2JsdC5vCiBvYmotJChDT05GSUdfRkJfVFgzOTEyKQkJICArPSB0eDM5MTJmYi5vICBj
ZmJmaWxscmVjdC5vIGNmYmNvcHlhcmVhLm8gY2ZiaW1nYmx0Lm8KLW9iai0kKENPTkZJR19GQl9B
VTExMDApCQkgICs9IGF1MTEwMGZiLm8gZmJnZW4ubworb2JqLSQoQ09ORklHX0ZCX0FVMTEwMCkJ
CSAgKz0gYXUxMTAwZmIubyBjZmJmaWxscmVjdC5vIGNmYmNvcHlhcmVhLm8gY2ZiaW1nYmx0Lm8K
IAogCiAjIFBsYXRmb3JtIG9yIGZhbGxiYWNrIGRyaXZlcnMgZ28gaGVyZQotLS0gZHJpdmVycy92
aWRlby9LY29uZmlnCVdlZCBEZWMgIDEgMTU6MDI6MzMgMjAwNAorKysgZHJpdmVycy92aWRlby9L
Y29uZmlnLnBhdGNoZWQJV2VkIERlYyAgMSAxNTowMTo1MyAyMDA0CkBAIC05NzAsNiArOTc4LDEw
IEBACiBjb25maWcgUEIxNTAwX1RGVAogCXByb21wdCAiVXNlIFRGVCBQYW5lbCBvbiBQYjExMDAg
IgogCWRlcGVuZHMgb24gRkJfRTEzNTYgJiYgTUlQU19QQjExMDA9eQorCitjb25maWcgRkJfQVUx
MTAwCisJYm9vbCAiQXUxMTAwIExDRCBEcml2ZXIiCisJZGVwZW5kcyBvbiBGQiAmJiBNSVBTICYm
IE1JUFNfUEIxMTAwPXkKIAogY29uZmlnIEZCX1NCVVMKIAlib29sICJTQlVTIGFuZCBVUEEgZnJh
bWVidWZmZXJzIgotLS0gYXJjaC9taXBzL2F1MTAwMC9jb21tb24vcGxhdGZvcm0uYwlXZWQgRGVj
ICAxIDE0OjM1OjE2IDIwMDQKKysrIGFyY2gvbWlwcy9hdTEwMDAvY29tbW9uL3BsYXRmb3JtLmMu
cGF0Y2hlZAlXZWQgRGVjICAxIDE0OjM3OjQ1IDIwMDQKQEAgLTU4LDEwICs1OCwzOSBAQAogCS5y
ZXNvdXJjZQk9IGF1MXh4eF91c2Jfb2hjaV9yZXNvdXJjZXMsCiB9OwogCisvKioqIEFVMTEwMCBM
Q0QgY29udHJvbGxlciAqKiovCisKK3N0YXRpYyBzdHJ1Y3QgcmVzb3VyY2UgYXUxMTAwX2xjZF9y
ZXNvdXJjZXNbXSA9IHsKKwlbMF0gPSB7CisJCS5zdGFydAkJPSBBVTExMDBfTENEX0JBU0UsCisJ
CS5lbmQJCT0gQVUxMTAwX0xDRF9CQVNFICsgQVUxMTAwX0xDRF9MRU4gLSAxLAorCQkuZmxhZ3MJ
CT0gSU9SRVNPVVJDRV9NRU0sCisJfSwKKwlbMV0gPSB7CisJCS5zdGFydAkJPSBBVTExMDBfTENE
X0lOVCwKKwkJLmVuZAkJPSBBVTExMDBfTENEX0lOVCwKKwkJLmZsYWdzCQk9IElPUkVTT1VSQ0Vf
SVJRLAorCX0KK307CisKK3N0YXRpYyB1NjQgYXUxMTAwX2xjZF9kbWFtYXNrID0gfih1MzIpMDsK
Kworc3RhdGljIHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgYXUxMTAwX2xjZF9kZXZpY2UgPSB7CisJ
Lm5hbWUJCT0gImF1MTEwMC1sY2QiLAorCS5pZAkJPSAwLAorCS5kZXYgPSB7CisJCS5kbWFfbWFz
awkJPSAmYXUxMTAwX2xjZF9kbWFtYXNrLAorCQkuY29oZXJlbnRfZG1hX21hc2sJPSAweGZmZmZm
ZmZmLAorCX0sCisJLm51bV9yZXNvdXJjZXMgID0gQVJSQVlfU0laRShhdTExMDBfbGNkX3Jlc291
cmNlcyksCisJLnJlc291cmNlICAgICAgID0gYXUxMTAwX2xjZF9yZXNvdXJjZXMsCit9OworCiAv
Ki0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0qLwogCiBzdGF0aWMgc3RydWN0IHBsYXRmb3JtX2RldmljZSAqYXUx
eHh4X3BsYXRmb3JtX2RldmljZXNbXSBfX2luaXRkYXRhID0gewogCSZhdTF4eHhfdXNiX29oY2lf
ZGV2aWNlLAorCSZhdTExMDBfbGNkX2RldmljZSwKIH07CiAKIGludCBhdTF4eHhfcGxhdGZvcm1f
aW5pdCh2b2lkKQpkaWZmIC11IC1yMS4xMSBhdTEwMDAuaAotLS0gaW5jbHVkZS9hc20tbWlwcy9t
YWNoLWF1MXgwMC9hdTEwMDAuaAkyMyBTZXAgMjAwNCAwNjowNjo1MCAtMDAwMAkxLjExCisrKyBp
bmNsdWRlL2FzbS1taXBzL21hY2gtYXUxeDAwL2F1MTAwMC5oCTI4IE9jdCAyMDA0IDE1OjExOjM3
IC0wMDAwCkBAIC00OTQsNiArNDk0LDkgQEAKICNkZWZpbmUgQVUxMTAwX0VUSDBfQkFTRQkgIDB4
QjA1MDAwMDAKICNkZWZpbmUgQVUxMTAwX01BQzBfRU5BQkxFICAgICAgIDB4QjA1MjAwMDAKICNk
ZWZpbmUgTlVNX0VUSF9JTlRFUkZBQ0VTIDEKKworI2RlZmluZSBBVTExMDBfTENEX0JBU0UgICAg
ICAgICAgIDB4MTUwMDAwMDAKKyNkZWZpbmUgQVUxMTAwX0xDRF9MRU4gICAgICAgICAgICAweDAw
MDAwODAwCiAjZW5kaWYgLy8gQ09ORklHX1NPQ19BVTExMDAKIAogI2lmZGVmIENPTkZJR19TT0Nf
QVUxNTUwCkBAIC0xMjM3LDYgKzEyNDAsMTIgQEAKICAgI2RlZmluZSBTWVNfQ1NfTUkyX01BU0sg
ICAgICAgICAgICgweDc8PFNZU19DU19NSTJfQklUKQogICAjZGVmaW5lIFNZU19DU19ESTIgICAg
ICAgICAgICAgICAgKDE8PDE2KQogICAjZGVmaW5lIFNZU19DU19DSTIgICAgICAgICAgICAgICAg
KDE8PDE1KQorI2lmZGVmIENPTkZJR19TT0NfQVUxMTAwCisgICNkZWZpbmUgU1lTX0NTX01MX0JJ
VCAgICAgICAgICAgICA3CisgICNkZWZpbmUgU1lTX0NTX01MX01BU0sgICAgICAgICAgICAoMHg3
PDxTWVNfQ1NfTUxfQklUKQorICAjZGVmaW5lIFNZU19DU19ETCAgICAgICAgICAgICAgICAgKDE8
PDYpCisgICNkZWZpbmUgU1lTX0NTX0NMICAgICAgICAgICAgICAgICAoMTw8NSkKKyNlbHNlCiAg
ICNkZWZpbmUgU1lTX0NTX01VSF9CSVQgICAgICAgICAgICAxMgogICAjZGVmaW5lIFNZU19DU19N
VUhfTUFTSyAgICAgICAgICAgKDB4Nzw8U1lTX0NTX01VSF9CSVQpCiAgICNkZWZpbmUgU1lTX0NT
X0RVSCAgICAgICAgICAgICAgICAoMTw8MTEpCkBAIC0xMjQ1LDYgKzEyNTQsNyBAQAogICAjZGVm
aW5lIFNZU19DU19NVURfTUFTSyAgICAgICAgICAgKDB4Nzw8U1lTX0NTX01VRF9CSVQpCiAgICNk
ZWZpbmUgU1lTX0NTX0RVRCAgICAgICAgICAgICAgICAoMTw8NikKICAgI2RlZmluZSBTWVNfQ1Nf
Q1VEICAgICAgICAgICAgICAgICgxPDw1KQorI2VuZGlmCiAgICNkZWZpbmUgU1lTX0NTX01JUl9C
SVQgICAgICAgICAgICAyCiAgICNkZWZpbmUgU1lTX0NTX01JUl9NQVNLICAgICAgICAgICAoMHg3
PDxTWVNfQ1NfTUlSX0JJVCkKICAgI2RlZmluZSBTWVNfQ1NfRElSICAgICAgICAgICAgICAgICgx
PDwxKQpJbmRleDogaW5jbHVkZS9hc20vbWFjaC1wYjF4MDAvcGIxMTAwLmgKPT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpS
Q1MgZmlsZTogL2hvbWUvY3ZzL2xpbnV4L2luY2x1ZGUvYXNtLW1pcHMvbWFjaC1wYjF4MDAvcGIx
MTAwLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMQpkaWZmIC11IC1yMS4xIHBiMTEwMC5oCi0t
LSBpbmNsdWRlL2FzbS9tYWNoLXBiMXgwMC9wYjExMDAuaAkxMyBKYW4gMjAwNCAwODowOToyMiAt
MDAwMAkxLjEKKysrIGluY2x1ZGUvYXNtL21hY2gtcGIxeDAwL3BiMTEwMC5oCTIgRGVjIDIwMDQg
MTU6MjI6NTEgLTAwMDAKQEAgLTQ1LDYgKzQ1LDIxIEBACiAgICNkZWZpbmUgUEIxMTAwX1JTMjMy
X0RTUiAgICAgICAgKDE8PDEpCiAgICNkZWZpbmUgUEIxMTAwX1JTMjMyX1JJICAgICAgICAgKDE8
PDApCiAKKyNkZWZpbmUgQkNTUl9TV0lUQ0hFU19SRUcgICAgIDB4QUUwMDAwMDgKKyAgI2RlZmlu
ZSBCQ1NSX1NXSVRDSEVTX0RJUF9CSVQgICAwCisgICNkZWZpbmUgQkNTUl9TV0lUQ0hFU19ESVBf
TUFTSyAgKDB4RkY8PEJDU1JfU1dJVENIRVNfRElQX0JJVCkKKyAgI2RlZmluZSBCQ1NSX1NXSVRD
SEVTX0RJUF8xCSAgKDE8PDcpCisgICNkZWZpbmUgQkNTUl9TV0lUQ0hFU19ESVBfMgkgICgxPDw2
KQorICAjZGVmaW5lIEJDU1JfU1dJVENIRVNfRElQXzMJICAoMTw8NSkKKyAgI2RlZmluZSBCQ1NS
X1NXSVRDSEVTX0RJUF80CSAgKDE8PDQpCisgICNkZWZpbmUgQkNTUl9TV0lUQ0hFU19ESVBfNQkg
ICgxPDwzKQorICAjZGVmaW5lIEJDU1JfU1dJVENIRVNfRElQXzYJICAoMTw8MikKKyAgI2RlZmlu
ZSBCQ1NSX1NXSVRDSEVTX0RJUF83ICAgICAoMTw8MSkKKyAgI2RlZmluZSBCQ1NSX1NXSVRDSEVT
X0RJUF84ICAgICAoMTw8MCkKKyAgI2RlZmluZSBCQ1NSX1NXSVRDSEVTX1JPVEFSWV9CSVQgOAor
ICAjZGVmaW5lIEJDU1JfU1dJVENIRVNfUk9UQVJZX01BU0sgKDB4Rjw8QkNTUl9TV0lUQ0hFU19S
T1RBUllfQklUKQorICAjZGVmaW5lIEJDU1JfU1dJVENIRVNfRE9DX0xPQ0sgICgxPDwxNSkKKwog
I2RlZmluZSBQQjExMDBfSVJEQV9SUzIzMiAgICAgMHhBRTAwMDAwQwogICAjZGVmaW5lIFBCMTEw
MF9JUkRBX0ZVTEwgICAgICAgKDA8PDE0KSAvKiBmdWxsIHBvd2VyICovCiAgICNkZWZpbmUgUEIx
MTAwX0lSREFfU0hVVERPV04gICAoMTw8MTQpCkBAIC02Myw2ICs3OCwxMSBAQAogICAjZGVmaW5l
IFBDX0RSVl9FTiAgICAgICAgICAgICAgICgxPDw0KQogCiAjZGVmaW5lIFBCMTEwMF9HX0NPTlRS
T0wgICAgICAweEFFMDAwMDE0IC8qIGdyYXBoaWNzIGNvbnRyb2wgKi8KKyAgI2RlZmluZSBQQjEx
MDBfR19DT05UUk9MX1JTVAkgICgxPDw3KQorICAjZGVmaW5lIFBCMTEwMF9HX0NPTlRST0xfQkUg
CSAgKDE8PDUpCisgICNkZWZpbmUgUEIxMTAwX0dfQ09OVFJPTF9TTV9QQVNTICgxPDw0KQorICAj
ZGVmaW5lIFBCMTEwMF9HX0NPTlRST0xfQkwJICAoMTw8MikKKyAgI2RlZmluZSBQQjExMDBfR19D
T05UUk9MX1ZERAkgICgxPDwxKQogCiAjZGVmaW5lIFBCMTEwMF9SU1RfVkRESSAgICAgICAweEFF
MDAwMDFDCiAgICNkZWZpbmUgUEIxMTAwX1NPRlRfUkVTRVQgICAgICAoMTw8MTUpIC8qIGNsZWFy
IHRvIHJlc2V0IHRoZSBib2FyZCAqLwo=

--------------Boundary-00=_ICQ3JWJBDIHX28K5NGD6
Content-Type: text/x-c;
  charset="iso-8859-1";
  name="au1100fb.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="au1100fb.c"

LyoKICogQlJJRUYgTU9EVUxFIERFU0NSSVBUSU9OCiAqCUF1MTEwMCBMQ0QgRHJpdmVyLgogKgog
KiBDb3B5cmlnaHQgMjAwMiBNb250YVZpc3RhIFNvZnR3YXJlCiAqIEF1dGhvcjogTW9udGFWaXN0
YSBTb2Z0d2FyZSwgSW5jLgogKgkJcHBvcG92QG12aXN0YS5jb20gb3Igc291cmNlQG12aXN0YS5j
b20KICoKICogQ29weXJpZ2h0IDIwMDIgQWxjaGVteSBTZW1pY29uZHVjdG9yCiAqIEF1dGhvcjog
QWxjaGVteSBTZW1pY29uZHVjdG9yCiAqCiAqIFJld3JpdHRlbiBkdXJpbmcgTGludXggMi42IHBv
cnQKICogIGJ5IEthcmwgTGVzc2FyZCA8a2xlc3NhcmRAc3VucmlzZXRlbGVjb20uY29tPgogKgog
KiBCYXNlZCBvbjoKICogbGludXgvZHJpdmVycy92aWRlby9za2VsZXRvbmZiLmMgLS0gU2tlbGV0
b24gZm9yIGEgZnJhbWUgYnVmZmVyIGRldmljZQogKiAgQ3JlYXRlZCAyOCBEZWMgMTk5NyBieSBH
ZWVydCBVeXR0ZXJob2V2ZW4KICoKICogIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5
b3UgY2FuIHJlZGlzdHJpYnV0ZQkgaXQgYW5kL29yIG1vZGlmeSBpdAogKiAgdW5kZXIgIHRoZSB0
ZXJtcyBvZgkgdGhlIEdOVSBHZW5lcmFsICBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkg
dGhlCiAqICBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247ICBlaXRoZXIgdmVyc2lvbiAyIG9mIHRo
ZQlMaWNlbnNlLCBvciAoYXQgeW91cgogKiAgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KICoK
ICogIFRISVMgIFNPRlRXQVJFICBJUyBQUk9WSURFRAkgIGBgQVMJSVMnJyBBTkQgICBBTlkJRVhQ
UkVTUyBPUiBJTVBMSUVECiAqICBXQVJSQU5USUVTLAkgIElOQ0xVRElORywgQlVUIE5PVCAgTElN
SVRFRCAgVE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YKICogIE1FUkNIQU5UQUJJTElUWSBB
TkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuICBJTgog
KiAgTk8JRVZFTlQgIFNIQUxMICAgVEhFIEFVVEhPUiAgQkUJIExJQUJMRSBGT1IgQU5ZCSAgRElS
RUNULCBJTkRJUkVDVCwKICogIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09O
U0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVAogKiAgTk9UIExJTUlURUQJICBUTywg
UFJPQ1VSRU1FTlQgT0YgIFNVQlNUSVRVVEUgR09PRFMJT1IgU0VSVklDRVM7IExPU1MgT0YKICog
IFVTRSwgREFUQSwJT1IgUFJPRklUUzsgT1IJQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVS
IENBVVNFRCBBTkQgT04KICogIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOCSBD
T05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9SVAogKiAgKElOQ0xVRElORyBORUdMSUdF
TkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GCiAq
ICBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNV
Q0ggREFNQUdFLgogKgogKiAgWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUg
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFsb25nCiAqICB3aXRoIHRoaXMgcHJvZ3JhbTsg
aWYgbm90LCB3cml0ZSAgdG8gdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLiwKICog
IDY3NSBNYXNzIEF2ZSwgQ2FtYnJpZGdlLCBNQSAwMjEzOSwgVVNBLgogKi8KCiNpbmNsdWRlIDxs
aW51eC9tb2R1bGUuaD4KI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgojaW5jbHVkZSA8bGludXgv
ZXJybm8uaD4KI2luY2x1ZGUgPGxpbnV4L3N0cmluZy5oPgojaW5jbHVkZSA8bGludXgvbW0uaD4K
I2luY2x1ZGUgPGxpbnV4L2ZiLmg+CiNpbmNsdWRlIDxsaW51eC9pbml0Lmg+CiNpbmNsdWRlIDxs
aW51eC9pbnRlcnJ1cHQuaD4KI2luY2x1ZGUgPGxpbnV4L2N0eXBlLmg+CiNpbmNsdWRlIDxsaW51
eC9kbWEtbWFwcGluZy5oPgoKI2luY2x1ZGUgPGFzbS9tYWNoLWF1MXgwMC9hdTEwMDAuaD4KCiNk
ZWZpbmUgREVCVUcgMQojZGVmaW5lIFNJTVVMQVRPUiAwCgojaW5jbHVkZSA8dmlkZW8vYXUxMTAw
ZmIuaD4KCi8qIAogKiBTYW5pdHkgY2hlY2suIElmIHRoaXMgaXMgYSBuZXcgQXUxMTAwIGJhc2Vk
IGJvYXJkLCBzZWFyY2ggZm9yCiAqIHRoZSBQQjExMDAgaWZkZWZzIHRvIG1ha2Ugc3VyZSB5b3Ug
bW9kaWZ5IHRoZSBjb2RlIGFjY29yZGluZ2x5LgogKi8KI2lmIGRlZmluZWQoQ09ORklHX01JUFNf
UEIxMTAwKQogICNpbmNsdWRlIDxhc20vbWFjaC1wYjF4MDAvcGIxMTAwLmg+CiNlbGlmIGRlZmlu
ZWQoQ09ORklHX01JUFNfREIxMTAwKQogICNpbmNsdWRlIDxhc20vbWFjaC1kYjF4MDAvZGIxeDAw
Lmg+CiNlbHNlCiAgI2Vycm9yICJVbmtub3duIEF1MTEwMCBib2FyZCwgQXUxMTAwIEZCIGRyaXZl
ciBub3Qgc3VwcG9ydGVkIgojZW5kaWYKCiNkZWZpbmUgRFJJVkVSX05BTUUgImF1MTEwMGZiIgoj
ZGVmaW5lIERSSVZFUl9ERVNDICJMQ0QgY29udHJvbGxlciBkcml2ZXIgZm9yIEFVMTEwMCBwcm9j
ZXNzb3JzIgoKI2RlZmluZSB0b19hdTExMDBmYl9kZXZpY2UoX2luZm8pIFwKCSAgKF9pbmZvID8g
Y29udGFpbmVyX29mKF9pbmZvLCBzdHJ1Y3QgYXUxMTAwZmJfZGV2aWNlLCBmYl9pbmZvKSA6IE5V
TEwpOwoKLyogRHJpdmVyIGdsb2JhbCBkYXRhICovIApzdHJ1Y3QgYXUxMTAwZmJfZHJ2X2luZm8g
CnsKICAgICAgICBpbnQJcGFuZWxfaWR4OwoJY2hhcioJb3B0X21vZGU7Cgp9IGRydl9pbmZvID0g
eyAtMSwgMCB9OwoKLyogQml0ZmllbGRzIGZvcm1hdCBzdXBwb3J0ZWQgYnkgdGhlIGNvbnRyb2xs
ZXIuIE5vdGUgdGhhdCB0aGUgb3JkZXIgb2YgZm9ybWF0cyAKICogU0hPVUxEIGJlIHRoZSBzYW1l
IGFzIGluIHRoZSBMQ0RfQ09OVFJPTF9TQlBQRiBmaWVsZCwgc28gd2UgY2FuIHJldHJpZXZlIHRo
ZQogKiByaWdodCBwaXhlbCBmb3JtYXQgYnkgZG9pbmcgcmdiX2JpdGZpZWxkc1tMQ0RfQ09OVFJP
TF9TQlBQRl9YWFggPj4gTENEX0NPTlRST0xfU0JQUEZdCiAqLwpzdHJ1Y3QgZmJfYml0ZmllbGQg
cmdiX2JpdGZpZWxkc1tdWzRdID0gCnsKICAJLyogICAgIFJlZCwgCSAgIEdyZWVuLCAJIEJsdWUs
IAkgICAgIFRyYW5zcCAgICovCgl7IHsgMTAsIDYsIDAgfSwgeyA1LCA1LCAwIH0sIHsgMCwgNSwg
MCB9LCB7IDAsIDAsIDAgfSB9LAoJeyB7IDExLCA1LCAwIH0sIHsgNSwgNiwgMCB9LCB7IDAsIDUs
IDAgfSwgeyAwLCAwLCAwIH0gfSwKCXsgeyAxMSwgNSwgMCB9LCB7IDYsIDUsIDAgfSwgeyAwLCA2
LCAwIH0sIHsgMCwgMCwgMCB9IH0sCgl7IHsgMTAsIDUsIDAgfSwgeyA1LCA1LCAwIH0sIHsgMCwg
NSwgMCB9LCB7IDE1LCAxLCAwIH0gfSwKCXsgeyAxMSwgNSwgMCB9LCB7IDYsIDUsIDAgfSwgeyAx
LCA1LCAwIH0sIHsgMCwgMSwgMCB9IH0sCgoJLyogVGhlIGxhc3QgaXMgdXNlZCB0byBkZXNjcmli
ZSAxMmJwcCBmb3JtYXQgKi8KCXsgeyA4LCA0LCAwIH0sICB7IDQsIDQsIDAgfSwgeyAwLCA0LCAw
IH0sIHsgMCwgMCwgMCB9IH0sCn07CgovKi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0qLwoKLyogSGVscGVycyAq
LwoKc3RhdGljIHZvaWQgCmF1MTEwMGZiX3VwZGF0ZV9mYmluZm8oc3RydWN0IGZiX2luZm8gKmZi
aSkKewoJc3RydWN0IGF1MTEwMGZiX2RldmljZSAqZmJkZXYgPSB0b19hdTExMDBmYl9kZXZpY2Uo
ZmJpKTsKCQoJLyogVXBkYXRlIHZhci1kZXBlbmRlbnQgRkIgaW5mbyAqLwoJaWYgKHBhbmVsX2lz
X2FjdGl2ZShmYmRldi0+cGFuZWwpIHx8IHBhbmVsX2lzX2NvbG9yKGZiZGV2LT5wYW5lbCkpIHsK
CQlpZiAoZmJpLT52YXIuYml0c19wZXJfcGl4ZWwgPD0gOCkgewoJCQkvKiBwYWxldHRpemVkICov
CgkJCWZiaS0+Zml4LnZpc3VhbCA9IEZCX1ZJU1VBTF9QU0VVRE9DT0xPUjsKCQkJZmJpLT5maXgu
bGluZV9sZW5ndGggPSBmYmktPnZhci54cmVzX3ZpcnR1YWwgLyAKCQkJCQkJCSg4L2ZiaS0+dmFy
LmJpdHNfcGVyX3BpeGVsKTsKCQl9IGVsc2UgewoJCQkvKiBub24tcGFsZXR0aXplZCAqLwoJCQlm
YmktPmZpeC52aXN1YWwgPSBGQl9WSVNVQUxfVFJVRUNPTE9SOwoJCQlmYmktPmZpeC5saW5lX2xl
bmd0aCA9IGZiaS0+dmFyLnhyZXNfdmlydHVhbCA8PCAxOyAvKiBkZXB0aD0xNiAqLwoJCX0KCX0g
ZWxzZSB7CgkJLyogbW9ubyAqLwoJCWZiaS0+Zml4LnZpc3VhbCA9IEZCX1ZJU1VBTF9NT05PMTA7
CgkJZmJpLT5maXgubGluZV9sZW5ndGggPSBmYmktPnZhci54cmVzX3ZpcnR1YWwgLyA4OwoJfQoJ
CglmYmktPnNjcmVlbl9zaXplID0gZmJpLT5maXgubGluZV9sZW5ndGggKiBmYmktPnZhci55cmVz
X3ZpcnR1YWw7Cn0KCnN0YXRpYyBpbnQKYXUxMTAwZmJfbWF0Y2hfcmdiKHN0cnVjdCBmYl92YXJf
c2NyZWVuaW5mbyAqdmFyKQp7CglzaXplX3QgYmZfc2l6ZSA9IHNpemVvZihzdHJ1Y3QgZmJfYml0
ZmllbGQpOwoJaW50IGk7CgoJZm9yIChpID0gMDsgaSA8IEFSUkFZX1NJWkUocmdiX2JpdGZpZWxk
cyk7IGkrKykgewoJCWlmICghbWVtY21wKCZ2YXItPnJlZCwgJnJnYl9iaXRmaWVsZHNbaV1bMF0s
IGJmX3NpemUpICYmCgkJICAgICFtZW1jbXAoJnZhci0+Z3JlZW4sICZyZ2JfYml0ZmllbGRzW2ld
WzFdLCBiZl9zaXplKSAmJgoJCSAgICAhbWVtY21wKCZ2YXItPmJsdWUsICZyZ2JfYml0ZmllbGRz
W2ldWzJdLCBiZl9zaXplKSAmJgoJCSAgICAhbWVtY21wKCZ2YXItPnRyYW5zcCwgJnJnYl9iaXRm
aWVsZHNbaV1bM10sIGJmX3NpemUpKQoJCQlyZXR1cm4gaTsKCX0KCglyZXR1cm4gLTE7Cn0KCiNp
ZiBERUJVRwpzdGF0aWMgaW5saW5lIHZvaWQKYXUxMTAwZmJfZHVtcF9yZWdpc3RlcnMoc3RydWN0
IGF1MTEwMGZiX3JlZ3MgKnJlZ3MpCnsKCWludCBhY3RpdmUgPSByZWdzLT5sY2RfY29udHJvbCAm
IExDRF9DT05UUk9MX1BUOwoJaW50IGNvbG9yID0gcmVncy0+bGNkX2NvbnRyb2wgJiBMQ0RfQ09O
VFJPTF9QQzsKCWludCBmb3JtYXQgPSByZWdzLT5sY2RfY29udHJvbCAmIExDRF9DT05UUk9MX1NC
UFBGX01BU0s7CglpbnQgcGl4Y2xvY2s7CglpbnQgcmVmcmVzaDsKCWludCBicHAgPSAwOwoKCXN3
aXRjaCAocmVncy0+bGNkX2NvbnRyb2wgJiBMQ0RfQ09OVFJPTF9CUFBfTUFTSykgewoJCWNhc2Ug
TENEX0NPTlRST0xfQlBQXzE6IGJwcCA9IDE7IGJyZWFrOwoJCWNhc2UgTENEX0NPTlRST0xfQlBQ
XzI6IGJwcCA9IDI7IGJyZWFrOwoJCWNhc2UgTENEX0NPTlRST0xfQlBQXzQ6IGJwcCA9IDQ7IGJy
ZWFrOwoJCWNhc2UgTENEX0NPTlRST0xfQlBQXzg6IGJwcCA9IDg7IGJyZWFrOwoJCWNhc2UgTENE
X0NPTlRST0xfQlBQXzEyOiBicHAgPSAxMjsgYnJlYWs7CgkJY2FzZSBMQ0RfQ09OVFJPTF9CUFBf
MTY6IGJwcCA9IDE2OyBicmVhazsKCX0KCglwaXhjbG9jayA9ICgyICogKChyZWdzLT5sY2RfY2xr
Y29udHJvbCAmIExDRF9DTEtDT05UUk9MX1BDRF9NQVNLKSArIDEpKTsKCXBpeGNsb2NrID0gQVUx
MTAwX0xDRF9NQVhfQ0xLIC8gcGl4Y2xvY2s7CgoJcmVmcmVzaCA9ICgocmVncy0+bGNkX2hvcnp0
aW1pbmcgJiBMQ0RfSE9SWlRJTUlOR19ITjJfTUFTSykgCgkJCQk+PiBMQ0RfSE9SWlRJTUlOR19I
TjJfQklUKQoJCSArKChyZWdzLT5sY2RfaG9yenRpbWluZyAmIExDRF9IT1JaVElNSU5HX0hOMV9N
QVNLKSAKCQkJCT4+IExDRF9IT1JaVElNSU5HX0hOMV9CSVQpCgkJICsoKHJlZ3MtPmxjZF9ob3J6
dGltaW5nICYgTENEX0hPUlpUSU1JTkdfSFBXX01BU0spIAoJCQkJPj4gTENEX0hPUlpUSU1JTkdf
SFBXX0JJVCkKCQkgKygocmVncy0+bGNkX2hvcnp0aW1pbmcgJiBMQ0RfSE9SWlRJTUlOR19QUExf
TUFTSykgCgkJCQk+PiBMQ0RfSE9SWlRJTUlOR19QUExfQklUKQoJCSArIDQgLyogYWRqdXN0ICov
OwoKCXJlZnJlc2ggKj0gKChyZWdzLT5sY2RfdmVydHRpbWluZyAmIExDRF9WRVJUVElNSU5HX1ZO
Ml9NQVNLKSAKCQkJCT4+IExDRF9WRVJUVElNSU5HX1ZOMl9CSVQpCgkJICsoKHJlZ3MtPmxjZF92
ZXJ0dGltaW5nICYgTENEX1ZFUlRUSU1JTkdfVk4xX01BU0spIAoJCQkJPj4gTENEX1ZFUlRUSU1J
TkdfVk4xX0JJVCkKCQkgKygocmVncy0+bGNkX3ZlcnR0aW1pbmcgJiBMQ0RfVkVSVFRJTUlOR19W
UFdfTUFTSykgCgkJCQk+PiBMQ0RfVkVSVFRJTUlOR19WUFdfQklUKQoJCSArKChyZWdzLT5sY2Rf
dmVydHRpbWluZyAmIExDRF9WRVJUVElNSU5HX0xQUF9NQVNLKSAKCQkJCT4+IExDRF9WRVJUVElN
SU5HX0xQUF9CSVQpCgkJICsgNCAvKiBhZGp1c3QgKi87CgoJcmVmcmVzaCA9IHBpeGNsb2NrIC8g
cmVmcmVzaDsKCglwcmludF9kYmcoIiIpOwoJcHJpbnRfZGJnKCJMQ0QgY29udHJvbGxlciByZWdp
c3RlciBkdW1wOiIpOwoKCXByaW50X2RiZygiIik7CglwcmludF9kYmcoIiAgICAgY29udHJvbDog
ICAgMHglMDh4IiwgcmVncy0+bGNkX2NvbnRyb2wpOwoJcHJpbnRfZGJnKCIgICAgIGludHN0YXR1
czogIDB4JTA4eCIsIHJlZ3MtPmxjZF9pbnRzdGF0dXMpOwoJcHJpbnRfZGJnKCIgICAgIGludGVu
YWJsZTogIDB4JTA4eCIsIHJlZ3MtPmxjZF9pbnRlbmFibGUpOwoJcHJpbnRfZGJnKCIgICAgIGhv
cnp0aW1pbmc6IDB4JTA4eCIsIHJlZ3MtPmxjZF9ob3J6dGltaW5nKTsKCXByaW50X2RiZygiICAg
ICB2ZXJ0dGltaW5nOiAweCUwOHgiLCByZWdzLT5sY2RfdmVydHRpbWluZyk7CglwcmludF9kYmco
IiAgICAgY2xrY29udHJvbDogMHglMDh4IiwgcmVncy0+bGNkX2Nsa2NvbnRyb2wpOwoJcHJpbnRf
ZGJnKCIgICAgIGRtYWFkZHIwOiAgIDB4JTA4eCIsIHJlZ3MtPmxjZF9kbWFhZGRyMCk7Cglwcmlu
dF9kYmcoIiAgICAgZG1hYWRkcjE6ICAgMHglMDh4IiwgcmVncy0+bGNkX2RtYWFkZHIxKTsKCXBy
aW50X2RiZygiICAgICB3b3JkczogICAgICAweCUwOHgiLCByZWdzLT5sY2Rfd29yZHMpOwoJcHJp
bnRfZGJnKCIgICAgIHB3bWRpdjogICAgIDB4JTA4eCIsIHJlZ3MtPmxjZF9wd21kaXYpOwoJcHJp
bnRfZGJnKCIgICAgIHB3bWhpOiAgICAgIDB4JTA4eCIsIHJlZ3MtPmxjZF9wd21oaSk7CgoJcHJp
bnRfZGJnKCIiKTsKCXByaW50X2RiZygiICAgICAlcyAlcyAlcyBwYW5lbCIsCgkJICBhY3RpdmUg
PyAiVEZUIiA6ICJTVE4iLAoJCSAgY29sb3IgPyAiY29sb3IiIDogIm1vbm9jaHJvbWUiLAoJCSAg
YWN0aXZlID8gKHJlZ3MtPmxjZF9jb250cm9sICYgTENEX0NPTlRST0xfREIgPyAiMTIgcGlucyIg
OiAiMTYgcGlucyIpCgkJICAgICAgICAgOiAoY29sb3IgPyAocmVncy0+bGNkX2NvbnRyb2wgJiBM
Q0RfQ09OVFJPTF9EUCA/ICJkdWFsIgoJCQkJIAkJCQkgICAgICAJOiAic2luZ2xlIikKCQkJIAkg
IDogKHJlZ3MtPmxjZF9jb250cm9sICYgTENEX0NPTlRST0xfTVBJID8gIjggYml0IgoJCQkJCQkJ
ICAgICAgICAgICAgICAgICA6ICI0IGJpdCIpCgkJCSAgICkKCQkgKTsKCXByaW50X2RiZygiICAg
ICAlZGJwcCVzICVkeCVkIGRpc3BsYXkgYXQgJWRIeiIsIAoJCSAgYnBwLAoJCSAgKGJwcCA9PSAx
NikgPyAoKGZvcm1hdCA9PSBMQ0RfQ09OVFJPTF9TQlBQRl82NTUpID8gIiA2NTUiIDoKCQkJCSAo
Zm9ybWF0ID09IExDRF9DT05UUk9MX1NCUFBGXzU2NSkgPyAiIDU2NSIgOgoJCQkJIChmb3JtYXQg
PT0gTENEX0NPTlRST0xfU0JQUEZfNTU2KSA/ICIgNTU2IiA6CgkJCQkgKGZvcm1hdCA9PSBMQ0Rf
Q09OVFJPTF9TQlBQRl8xNTU1KSA/ICIgMTU1NSIgOiAiIDU1NTEiCgkJCQkpCgkJIAkgICAgICA6
ICIiLAoJCSAgKHJlZ3MtPmxjZF9ob3J6dGltaW5nICYgTENEX0hPUlpUSU1JTkdfUFBMX01BU0sp
ICsgMSwKCQkgIChyZWdzLT5sY2RfdmVydHRpbWluZyAmIExDRF9WRVJUVElNSU5HX0xQUF9NQVNL
KSArIDEsCgkJICByZWZyZXNoCgkJICk7CglpZiAocmVncy0+bGNkX2NvbnRyb2wgJiBMQ0RfQ09O
VFJPTF9TTV9NQVNLKSB7CgkJdTMyIGFuZ2xlID0gcmVncy0+bGNkX2NvbnRyb2wgJiBMQ0RfQ09O
VFJPTF9TTV9NQVNLOwoJCXByaW50X2RiZygiICAgICBSb3RhdGVkIGF0ICVkIGRlZ3JlZXMiLCAK
CQkJICAoYW5nbGUgPT0gTENEX0NPTlRST0xfU01fOTApID8gOTAgOgoJCQkgIChhbmdsZSA9PSBM
Q0RfQ09OVFJPTF9TTV8xODApID8gMTgwIDogMjcwCgkJCSAgKTsKCX0KCXByaW50X2RiZygiICAg
ICBQaXhlbCBjbG9jazogJWRrSHoiLCBwaXhjbG9jay8xMDAwKTsKCXByaW50X2RiZygiIik7Cn0K
I2VuZGlmCgovKi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0qLwoKLyogQVUxMTAwIGZyYW1lYnVmZmVyIGRyaXZl
ciAqLwoKLyogZmJfb3BlbgogKiBPcGVuIGEgbmV3IGNsaWVudCByZWZlcmVuY2UgZm9yIGEgZGV2
aWNlCiAqLwppbnQgYXUxMTAwZmJfZmJfb3BlbihzdHJ1Y3QgZmJfaW5mbyAqZmJpLCBpbnQgdXNl
cikKewoJcHJpbnRfZGJnKCJmYl9vcGVuICVwICVkIiwgZmJpLCB1c2VyKTsKCXJldHVybiAwOwp9
CgovKiBmYl9yZWxlYXNlCiAqIENsb3NlIGEgY2xpZW50IHJlZmVyZW5jZSB0byBhIGRldmljZQog
Ki8KaW50IGF1MTEwMGZiX2ZiX3JlbGVhc2Uoc3RydWN0IGZiX2luZm8gKmZiaSwgaW50IHVzZXIp
CnsKCXByaW50X2RiZygiZmJfcmVsZWFzZSAlcCAlZCIsIGZiaSwgdXNlcik7CglyZXR1cm4gMDsK
fQoKLyogZmJfY2hlY2tfdmFyCiAqIFZhbGlkYXRlIHZhciBzZXR0aW5ncyB3aXRoIGhhcmR3YXJl
IHJlc3RyaWN0aW9ucyBhbmQgbW9kaWZ5IGl0IGlmIG5lY2Vzc2FyeSAKICovCmludCBhdTExMDBm
Yl9mYl9jaGVja192YXIoc3RydWN0IGZiX3Zhcl9zY3JlZW5pbmZvICp2YXIsIHN0cnVjdCBmYl9p
bmZvICpmYmkpCnsKCXN0cnVjdCBhdTExMDBmYl9kZXZpY2UgKmZiZGV2ID0gdG9fYXUxMTAwZmJf
ZGV2aWNlKGZiaSk7CglzdHJ1Y3QgYXUxMTAwZmJfcGFuZWwgKnBhbmVsOwoJdTMyIHBpeGNsb2Nr
OwoJaW50IHNjcmVlbl9zaXplOwoKCXByaW50X2RiZygiZmJfY2hlY2tfdmFyICVwICVwIiwgdmFy
LCBmYmkpOwoKCWlmICghZmJkZXYpCgkJcmV0dXJuIC1FSU5WQUw7CgoJcGFuZWwgPSBmYmRldi0+
cGFuZWw7CgoJLyogTWFrZSBzdXJlIHRoYXQgdGhlIG1vZGUgcmVzcGVjdCBhbGwgTENEIGNvbnRy
b2xsZXIgYW5kIAoJICogcGFuZWwgcmVzdHJpY3Rpb25zLiAqLwoJdmFyLT54cmVzID0gbWF4KHZh
ci0+eHJlcywgcGFuZWwtPm1pbl94cmVzKTsKCXZhci0+eHJlcyA9IG1pbih2YXItPnhyZXMsIG1p
bihwYW5lbC0+bWF4X3hyZXMsICh1MzIpQVUxMTAwX0xDRF9NQVhfWFJFUykpOwoJdmFyLT55cmVz
ID0gbWF4KHZhci0+eXJlcywgcGFuZWwtPm1pbl95cmVzKTsKCXZhci0+eXJlcyA9IG1pbih2YXIt
PnlyZXMsIG1pbihwYW5lbC0+bWF4X3lyZXMsICh1MzIpQVUxMTAwX0xDRF9NQVhfWVJFUykpOwoJ
CgkvKiBXZSBvbmx5IHN1cHBvcnQgdmlydHVhbCBtb2RlIGluIFkgKG5vIHBpdGNoKSAqLwoJdmFy
LT54cmVzX3ZpcnR1YWwgPSB2YXItPnhyZXM7Cgl2YXItPnlyZXNfdmlydHVhbCA9IG1heCh2YXIt
PnlyZXNfdmlydHVhbCwgdmFyLT55cmVzKTsKCgl2YXItPmJpdHNfcGVyX3BpeGVsID0gbWluKHZh
ci0+Yml0c19wZXJfcGl4ZWwsIHBhbmVsLT5tYXhfYnBwKTsKCglzY3JlZW5fc2l6ZSA9IHZhci0+
eHJlc192aXJ0dWFsICogdmFyLT55cmVzX3ZpcnR1YWw7CglpZiAodmFyLT5iaXRzX3Blcl9waXhl
bCA+IDgpIHNjcmVlbl9zaXplIDw8PSAxOwoJZWxzZSBzY3JlZW5fc2l6ZSAvPSAoOC92YXItPmJp
dHNfcGVyX3BpeGVsKTsKCglpZiAoZmJkZXYtPmZiX2xlbiA8IHNjcmVlbl9zaXplKQoJCXJldHVy
biAtRUlOVkFMOyAvKiBWaXJ0dWFsIHNjcmVlbiBpcyB0byBiaWcsIGFib3J0ICovCgoJaWYgKHZh
ci0+cm90YXRlKSB7CgkJdmFyLT5yb3RhdGUgPSBtaW4odmFyLT5yb3RhdGUsICh1MzIpMjcwKTsK
CQlpZiAodmFyLT5yb3RhdGUgJSA5MCkgewoJCQlpbnQgZGlmZiA9IHZhci0+cm90YXRlICUgOTA7
CgkJCXZhci0+cm90YXRlIC09IGRpZmY7CgkJfQoJCWlmICgodmFyLT5yb3RhdGUgIT0gMTgwKSAm
JiAKCQkgICAgKCh2YXItPnhyZXMgPiAzMjApIHx8ICh2YXItPnlyZXMgPiAyNDApKSkgewoJCQl2
YXItPnJvdGF0ZSA9IDA7IC8qIFJlc29sdXRpb24gdG9vIGhpZ2ggZm9yIHN1Y2ggYW5nbGUgKi8K
CQl9Cgl9CgoJLyogVGhlIG1heCBMQ0QgY2xvY2sgaXMgZml4ZWQgdG8gNDhNSHogKHZhbHVlIG9m
IEFVWF9DTEspLiBUaGUgcGl4ZWwKCSAqIGNsb2NrIGNhbiBvbmx5IGJlIG9idGFpbiBieSBkaXZp
ZGluZyB0aGlzIHZhbHVlIGJ5IGFuIGV2ZW4gaW50ZWdlci4KCSAqIEZhbGxiYWNrIHRvIGEgc2xv
d2VyIHBpeGVsIGNsb2NrIGlmIG5lY2Vzc2FyeS4gKi8KCXBpeGNsb2NrID0gbWF4KCh1MzIpKFBJ
Q09TMktIWih2YXItPnBpeGNsb2NrKSAqIDEwMDApLCBmYmktPm1vbnNwZWNzLmRjbGttaW4pOwoJ
cGl4Y2xvY2sgPSBtaW4ocGl4Y2xvY2ssIG1pbihmYmktPm1vbnNwZWNzLmRjbGttYXgsICh1MzIp
QVUxMTAwX0xDRF9NQVhfQ0xLLzIpKTsKCglpZiAoQVUxMTAwX0xDRF9NQVhfQ0xLICUgcGl4Y2xv
Y2spIHsKCQlpbnQgZGlmZiA9IEFVMTEwMF9MQ0RfTUFYX0NMSyAlIHBpeGNsb2NrOwoJCXBpeGNs
b2NrIC09IGRpZmY7Cgl9CgoJdmFyLT5waXhjbG9jayA9IEtIWjJQSUNPUyhwaXhjbG9jay8xMDAw
KTsKCglpZiAoIXBhbmVsX2lzX2FjdGl2ZShwYW5lbCkpIHsKCQlpbnQgcGNkID0gQVUxMTAwX0xD
RF9NQVhfQ0xLIC8gKHBpeGNsb2NrICogMikgLSAxOwoKCQlpZiAoIXBhbmVsX2lzX2NvbG9yKHBh
bmVsKSAKCQkJJiYgKHBhbmVsLT5jb250cm9sX2Jhc2UgJiBMQ0RfQ09OVFJPTF9NUEkpICYmIChw
Y2QgPCAzKSkgewoJCQkvKiBTVE4gOGJpdCBtb25vIHBhbmVsIHN1cHBvcnQgaXMgdXAgdG8gNk1I
eiBwaXhjbG9jayAqLwoJCQl2YXItPnBpeGNsb2NrID0gS0haMlBJQ09TKDYwMDApOwoJCX0gZWxz
ZSBpZiAoIXBjZCkgewoJCQkvKiBPdGhlciBTVE4gcGFuZWwgc3VwcG9ydCBpcyB1cCB0byAxMk1I
eiAgKi8KCQkJdmFyLT5waXhjbG9jayA9IEtIWjJQSUNPUygxMjAwMCk7CgkJfQoJfQoJCgkvKiBT
ZXQgYml0ZmllbGQgYWNjb3JkaW5nbHkgKi8KCXN3aXRjaCAodmFyLT5iaXRzX3Blcl9waXhlbCkg
ewoKCQljYXNlIDE6CgkJY2FzZSAyOiAKCQljYXNlIDQ6IAoJCWNhc2UgODogCgkJCS8qIFBzZXVk
byBjb2xvci4gU0hPVUxEIGJlIHRoZSBmb2xsb3dpbmcuICovCgkJCXZhci0+cmVkLm9mZnNldCAg
ICA9IDA7CgkJCXZhci0+cmVkLmxlbmd0aCAgICA9IHZhci0+Yml0c19wZXJfcGl4ZWw7CgkJCXZh
ci0+cmVkLm1zYl9yaWdodCA9IDA7CgoJCQl2YXItPmdyZWVuLm9mZnNldCAgPSAwOwoJCQl2YXIt
PmdyZWVuLmxlbmd0aCAgPSB2YXItPmJpdHNfcGVyX3BpeGVsOwoJCQl2YXItPmdyZWVuLm1zYl9y
aWdodCA9IDA7CgoJCQl2YXItPmJsdWUub2Zmc2V0ICAgPSAwOwoJCQl2YXItPmJsdWUubGVuZ3Ro
ICAgPSB2YXItPmJpdHNfcGVyX3BpeGVsOwoJCQl2YXItPmJsdWUubXNiX3JpZ2h0ID0gMDsKCgkJ
CXZhci0+dHJhbnNwLm9mZnNldCA9IDA7CgkJCXZhci0+dHJhbnNwLmxlbmd0aCA9IDA7CgkJCXZh
ci0+dHJhbnNwLm1zYl9yaWdodCA9IDA7CgoJCQlicmVhazsKCQkJCgkJY2FzZSAxMjoKCQl7CgkJ
CS8qIDEyYnBwIFRydWUgY29sb3IuIFVzZSB0aGUgbGFzdCBSR0IgYml0ZmllbGQgKi8KCQkJaW50
IGlkeCA9IEFSUkFZX1NJWkUocmdiX2JpdGZpZWxkcykgLSAxOwoKCQkJdmFyLT5yZWQgICAgPSBy
Z2JfYml0ZmllbGRzW2lkeF1bMF07CgkJCXZhci0+Z3JlZW4gID0gcmdiX2JpdGZpZWxkc1tpZHhd
WzFdOwoJCQl2YXItPmJsdWUgICA9IHJnYl9iaXRmaWVsZHNbaWR4XVsyXTsKCQkJdmFyLT50cmFu
c3AgPSByZ2JfYml0ZmllbGRzW2lkeF1bM107CgoJCQlicmVhazsKCQl9CQoJCWNhc2UgMTY6CgkJ
ewoJCQkvKiAxNmJwcCBUcnVlIGNvbG9yLiBDaGVjayBpZiB3ZSBzdXBwb3J0IGl0LCBvciBmb3Jj
ZSBkZWZhdWx0LiAqLwoJCQlpZiAoYXUxMTAwZmJfbWF0Y2hfcmdiKHZhcikgPCAwKSB7CgoJCQkJ
aW50IGlkeCA9IExDRF9DT05UUk9MX0RFRkFVTFRfU0JQUEYgPj4gTENEX0NPTlRST0xfU0JQUEZf
QklUOwoJCQkJdmFyLT5yZWQgICAgPSByZ2JfYml0ZmllbGRzW2lkeF1bMF07CgkJCQl2YXItPmdy
ZWVuICA9IHJnYl9iaXRmaWVsZHNbaWR4XVsxXTsKCQkJCXZhci0+Ymx1ZSAgID0gcmdiX2JpdGZp
ZWxkc1tpZHhdWzJdOwoJCQkJdmFyLT50cmFuc3AgPSByZ2JfYml0ZmllbGRzW2lkeF1bM107CgkJ
CX0KCQkJYnJlYWs7CgkJfQoKCQlkZWZhdWx0OgoJCQlwcmludF9kYmcoIlVuc3VwcG9ydGVkIGRl
cHRoICVkYnBwIiwgdmFyLT5iaXRzX3Blcl9waXhlbCk7CgkJCXJldHVybiAtRUlOVkFMOwoJfQoK
CXJldHVybiAwOwp9CgovKiBmYl9zZXRfcGFyIAogKiBTZXQgaGFyZHdhcmUgd2l0aCB2YXIgc2V0
dGluZ3MuIFRoaXMgd2lsbCBlbmFibGUgdGhlIGNvbnRyb2xsZXIgd2l0aCBhIHNwZWNpZmljCiAq
IG1vZGUsIG5vcm1hbGx5IHZhbGlkYXRlZCB3aXRoIHRoZSBmYl9jaGVja192YXIgbWV0aG9kCiAq
LwppbnQgYXUxMTAwZmJfZmJfc2V0X3BhcihzdHJ1Y3QgZmJfaW5mbyAqZmJpKQp7CglzdHJ1Y3Qg
YXUxMTAwZmJfZGV2aWNlICpmYmRldiA9IHRvX2F1MTEwMGZiX2RldmljZShmYmkpOwoJc3RydWN0
IGF1MTEwMGZiX3JlZ3MgKnJlZ3M7CglzdHJ1Y3QgZmJfdmFyX3NjcmVlbmluZm8gKnZhcjsKCXUz
MiB3b3JkcywgcGNkOwoKCXByaW50X2RiZygiZmJfc2V0X3BhciAlcCIsIGZiaSk7CgoJaWYgKCFm
YmRldikKCQlyZXR1cm4gLUVJTlZBTDsKCiAJdmFyID0gJmZiaS0+dmFyOwojaWYgU0lNVUxBVE9S
CglyZWdzID0gKHN0cnVjdCBhdTExMDBmYl9yZWdzKilrbWFsbG9jKHNpemVvZihzdHJ1Y3QgYXUx
MTAwZmJfcmVncyksIEdGUF9LRVJORUwpOwojZWxzZQoJcmVncyA9IGZiZGV2LT5yZWdzOwojZW5k
aWYKCWF1MTEwMGZiX3VwZGF0ZV9mYmluZm8oZmJpKTsKCgkvKiBTdG9wIGFuZCByZWNvbmZpZ3Vy
ZSBjb250cm9sbGVyLi4uICovCglhdTExMDBmYl9zdG9wX2NvbnRyb2xsZXIoZmJkZXYsIDEpOwoK
CS8qIERldGVybWluZSBCUFAgbW9kZSBhbmQgZm9ybWF0ICovCglyZWdzLT5sY2RfY29udHJvbCA9
IGZiZGV2LT5wYW5lbC0+Y29udHJvbF9iYXNlIHwKCQkJICAgICgodmFyLT5yb3RhdGUvOTApIDw8
IExDRF9DT05UUk9MX1NNX0JJVCk7CgoJc3dpdGNoICh2YXItPmJpdHNfcGVyX3BpeGVsKSB7CgkJ
Y2FzZSAxOgoJCQlyZWdzLT5sY2RfY29udHJvbCB8PSBMQ0RfQ09OVFJPTF9CUFBfMTsKCQkJYnJl
YWs7CgkJY2FzZSAyOgoJCQlyZWdzLT5sY2RfY29udHJvbCB8PSBMQ0RfQ09OVFJPTF9CUFBfMjsK
CQkJYnJlYWs7CgkJY2FzZSA0OgoJCQlyZWdzLT5sY2RfY29udHJvbCB8PSBMQ0RfQ09OVFJPTF9C
UFBfNDsKCQkJYnJlYWs7CgkJY2FzZSA4OgoJCQlyZWdzLT5sY2RfY29udHJvbCB8PSBMQ0RfQ09O
VFJPTF9CUFBfODsKCQkJYnJlYWs7CgkJY2FzZSAxMjoKCQkJcmVncy0+bGNkX2NvbnRyb2wgfD0g
TENEX0NPTlRST0xfQlBQXzEyOwoJCQlicmVhazsKCQljYXNlIDE2OgoJCQlyZWdzLT5sY2RfY29u
dHJvbCB8PSBMQ0RfQ09OVFJPTF9CUFBfMTY7CgkJCWJyZWFrOwoJfQoKCWlmIChwYW5lbF9pc19h
Y3RpdmUoZmJkZXYtPnBhbmVsKSkgewoKCQlpZiAodmFyLT5iaXRzX3Blcl9waXhlbCA9PSAxNikg
ewoKCQkJLyogRmluZCB0aGUgcmlnaHQgcGl4ZWwgZm9ybWF0IGZvciB0aGlzIG1vZGUgKi8KCQkJ
aW50IGlkeCA9IGF1MTEwMGZiX21hdGNoX3JnYih2YXIpOwoJCQlyZWdzLT5sY2RfY29udHJvbCB8
PSAoaWR4IDw8IExDRF9DT05UUk9MX1NCUFBGX0JJVCk7CgkJCQoJCX0gZWxzZSBpZiAodmFyLT5i
aXRzX3Blcl9waXhlbCA8PSA4KSB7CgoJCQkvKiBGb3IgVEZUIHBhbGxldHRpemVkIG1vZGUsIHVz
ZSA1NjUgUkdCIHBhbGV0dGUgZW50cmllcyAqLwkKCQkJcmVncy0+bGNkX2NvbnRyb2wgfD0gTENE
X0NPTlRST0xfU0JQUEZfNTY1OwoJCX0KCX0KCglyZWdzLT5sY2RfaW50ZW5hYmxlID0gMDsKCXJl
Z3MtPmxjZF9pbnRzdGF0dXMgPSAwOwoKCXJlZ3MtPmxjZF9ob3J6dGltaW5nID0gTENEX0hPUlpU
SU1JTkdfSE4xX04odmFyLT5sZWZ0X21hcmdpbikgfAoJCQkgICAgICAgTENEX0hPUlpUSU1JTkdf
SE4yX04odmFyLT5yaWdodF9tYXJnaW4pIHwKCQkJICAgICAgIExDRF9IT1JaVElNSU5HX0hQV19O
KHZhci0+aHN5bmNfbGVuKSB8CgkJCSAgICAgICBMQ0RfSE9SWlRJTUlOR19QUExfTih2YXItPnhy
ZXMpOwoKCXJlZ3MtPmxjZF92ZXJ0dGltaW5nID0gTENEX1ZFUlRUSU1JTkdfVk4xX04odmFyLT51
cHBlcl9tYXJnaW4pIHwKCQkJICAgICAgIExDRF9WRVJUVElNSU5HX1ZOMl9OKHZhci0+bG93ZXJf
bWFyZ2luKSB8CgkJCSAgICAgICBMQ0RfVkVSVFRJTUlOR19WUFdfTih2YXItPnZzeW5jX2xlbikg
fAoJCQkgICAgICAgTENEX1ZFUlRUSU1JTkdfTFBQX04odmFyLT55cmVzKTsKCgkvKiBzZXR1cCBj
bG9jayB0byBvYnRhaW4gdmFsdWUgaW4gdmFyLT5waXhjbG9jay4gCgkgKiBOb3RlIHRoYXQgTENE
IGNsb2NrIGlzIHNldHVwIHRvIEFVWCBjbG9jaywgd2hpY2ggaXMgYnkgZGVmYXVsdCAKCSAqIChh
bmQgYXNzdW1lZCBhdCkgNDhNSHogKi8KCXBjZCA9IEFVMTEwMF9MQ0RfTUFYX0NMSyAvICgoUElD
T1MyS0haKHZhci0+cGl4Y2xvY2spICogMTAwMCkgKiAyKSAtIDE7CglyZWdzLT5sY2RfY2xrY29u
dHJvbCA9IExDRF9DTEtDT05UUk9MX1BDRF9OKHBjZCkgfCBmYmRldi0+cGFuZWwtPmNsa2NvbnRy
b2xfYmFzZTsKCglyZWdzLT5sY2RfZG1hYWRkcjAgPSBMQ0RfRE1BX1NBX04oZmJkZXYtPmZiX3Bo
eXMpOwoKCWlmIChwYW5lbF9pc19kdWFsKGZiZGV2LT5wYW5lbCkpIHsKCQkvKiBTZWNvbmQgcGFu
ZWwgZGlzcGxheSBzZWNvbmYgaGFsZiBvZiBzY3JlZW4gaWYgcG9zc2libGUsCgkJICogb3RoZXJ3
aXNlIGRpc3BsYXkgdGhlIHNhbWUgYXMgdGhlIGZpcnN0IHBhbmVsICovCgkJaWYgKHZhci0+eXJl
c192aXJ0dWFsID49ICh2YXItPnlyZXMgPDwgMSkpIHsKCQkJcmVncy0+bGNkX2RtYWFkZHIxID0g
TENEX0RNQV9TQV9OKGZiZGV2LT5mYl9waHlzICsKCQkJCQkJCSAgKGZiaS0+Zml4LmxpbmVfbGVu
Z3RoICogCgkJCQkJCSAgICAgICAgICAodmFyLT55cmVzX3ZpcnR1YWwgPj4gMSkpKTsKCQl9IGVs
c2UgewoJCQlyZWdzLT5sY2RfZG1hYWRkcjEgPSBMQ0RfRE1BX1NBX04oZmJkZXYtPmZiX3BoeXMp
OwoJCX0KCX0KCgl3b3JkcyA9IGZiaS0+Zml4LmxpbmVfbGVuZ3RoIC8gc2l6ZW9mKHUzMik7Cglp
ZiAoIXZhci0+cm90YXRlIHx8ICh2YXItPnJvdGF0ZSA9PSAxODApKSB7CgkJd29yZHMgKj0gdmFy
LT55cmVzX3ZpcnR1YWw7CgkJaWYgKHZhci0+cm90YXRlIC8qIDE4MCAqLykgewoJCQl3b3JkcyAt
PSAod29yZHMgJSA4KTsgLyogc2hvdWxkIGJlIGRpdmlzYWJsZSBieSA4ICovCgkJfQoJfQoJcmVn
cy0+bGNkX3dvcmRzID0gTENEX1dSRF9XUkRTX04od29yZHMpOwoKCXJlZ3MtPmxjZF9wd21kaXYg
PSAwOwoJcmVncy0+bGNkX3B3bWhpID0gMDsKCiNpZiBERUJVRwoJYXUxMTAwZmJfZHVtcF9yZWdp
c3RlcnMocmVncyk7CiNlbmRpZgojaWYgU0lNVUxBVE9SCglrZnJlZShyZWdzKTsKI2VuZGlmCgkv
KiBSZXN1bWUgY29udHJvbGxlciAqLwoJYXUxMTAwZmJfc3RhcnRfY29udHJvbGxlcihmYmRldik7
CgoJcmV0dXJuIDA7Cn0KCi8qIGZiX3NldGNvbHJlZwogKiBTZXQgY29sb3IgaW4gTENEIHBhbGV0
dGUuCiAqLwppbnQgYXUxMTAwZmJfZmJfc2V0Y29scmVnKHVuc2lnbmVkIHJlZ25vLCB1bnNpZ25l
ZCByZWQsIHVuc2lnbmVkIGdyZWVuLCB1bnNpZ25lZCBibHVlLCB1bnNpZ25lZCB0cmFuc3AsIHN0
cnVjdCBmYl9pbmZvICpmYmkpCnsKCXN0cnVjdCBhdTExMDBmYl9kZXZpY2UgKmZiZGV2ID0gdG9f
YXUxMTAwZmJfZGV2aWNlKGZiaSk7Cgl1MzIgKnBhbGV0dGUgPSBmYmRldi0+cmVncy0+bGNkX3Bh
bGxldHRlYmFzZTsKCXUzMiB2YWx1ZTsKCglpZiAocmVnbm8gPiAoQVUxMTAwX0xDRF9OQlJfUEFM
RVRURV9FTlRSSUVTIC0gMSkpCgkJcmV0dXJuIC1FSU5WQUw7CgoJaWYgKGZiaS0+dmFyLmdyYXlz
Y2FsZSkgewoJCS8qIENvbnZlcnQgY29sb3IgdG8gZ3JheXNjYWxlICovCgkJcmVkID0gZ3JlZW4g
PSBibHVlID0gCgkJCSgxOTU5NSAqIHJlZCArIDM4NDcwICogZ3JlZW4gKyA3NDcxICogYmx1ZSkg
Pj4gMTY7Cgl9CgoJaWYgKGZiaS0+Zml4LnZpc3VhbCA9PSBGQl9WSVNVQUxfVFJVRUNPTE9SKSB7
CgkJLyogUGxhY2UgY29sb3IgaW4gdGhlIHBzZXVkb3BhbGV0dGUgKi8KCQlpZiAocmVnbm8gPiAx
NikKCQkJcmV0dXJuIC1FSU5WQUw7CgoJCXBhbGV0dGUgPSAodTMyKilmYmktPnBzZXVkb19wYWxl
dHRlOwoKCQlyZWQgICA+Pj0gKDE2IC0gZmJpLT52YXIucmVkLmxlbmd0aCk7CgkJZ3JlZW4gPj49
ICgxNiAtIGZiaS0+dmFyLmdyZWVuLmxlbmd0aCk7CgkJYmx1ZSAgPj49ICgxNiAtIGZiaS0+dmFy
LmJsdWUubGVuZ3RoKTsKCQoJCXZhbHVlID0gKHJlZCAgIDw8IGZiaS0+dmFyLnJlZC5vZmZzZXQp
IAl8CQoJCQkoZ3JlZW4gPDwgZmJpLT52YXIuZ3JlZW4ub2Zmc2V0KXwKCQkJKGJsdWUgIDw8IGZi
aS0+dmFyLmJsdWUub2Zmc2V0KTsKCQl2YWx1ZSAmPSAweEZGRkY7CgoJfSBlbHNlIGlmIChwYW5l
bF9pc19hY3RpdmUoZmJkZXYtPnBhbmVsKSkgewoJCS8qIENPTE9SIFRGVCBQQUxMRVRUSVpFRCAo
dXNlIFJHQiA1NjUpICovCgkJdmFsdWUgPSAocmVkICYgMHhGODAwKXwoKGdyZWVuID4+IDUpICYg
MHgwN0UwKXwoKGJsdWUgPj4gMTEpICYgMHgwMDFGKTsKCQl2YWx1ZSAmPSAweEZGRkY7CgoJfSBl
bHNlIGlmIChwYW5lbF9pc19jb2xvcihmYmRldi0+cGFuZWwpKSB7CgkJLyogQ09MT1IgU1ROIE1P
REUgKi8KCQl2YWx1ZSA9ICgoKHBhbmVsX3N3YXBfcmdiKGZiZGV2LT5wYW5lbCkgPyBibHVlIDog
cmVkKSA+PiAxMikgJiAweDAwMEYpIHwgCgkJCSgoZ3JlZW4gPj4gOCkgJiAweDAwRjApIHwgCgkJ
CSgoKHBhbmVsX3N3YXBfcmdiKGZiZGV2LT5wYW5lbCkgPyByZWQgOiBibHVlKSA+PiA0KSAmIDB4
MEYwMCk7CgkJdmFsdWUgJj0gMHhGRkY7Cgl9IGVsc2UgewoJCS8qIE1PTk9DSFJPTUUgTU9ERSAq
LwoJCXZhbHVlID0gKGdyZWVuID4+IDEyKSAmIDB4MDAwRjsKCQl2YWx1ZSAmPSAweEY7Cgl9CgoJ
cGFsZXR0ZVtyZWdub10gPSB2YWx1ZTsKCQoJcmV0dXJuIDA7Cn0KCi8qIGZiX2JsYW5rCiAqIEJs
YW5rIHRoZSBzY3JlZW4uIERlcGVuZGluZyBvbiB0aGUgbW9kZSwgdGhlIHNjcmVlbiB3aWxsIGJl
CiAqIGFjdGl2YXRlZCB3aXRoIHRoZSBiYWNrbGlnaHQgY29sb3IsIG9yIGRlc2FjdGl2YXRlZAog
Ki8KaW50IGF1MTEwMGZiX2ZiX2JsYW5rKGludCBibGFua19tb2RlLCBzdHJ1Y3QgZmJfaW5mbyAq
ZmJpKQp7CglzdHJ1Y3QgYXUxMTAwZmJfZGV2aWNlICpmYmRldiA9IHRvX2F1MTEwMGZiX2Rldmlj
ZShmYmkpOwoKCXByaW50X2RiZygiZmJfYmxhbmsgJWQgJXAiLCBibGFua19tb2RlLCBmYmkpOwoK
CXN3aXRjaCAoYmxhbmtfbW9kZSkgewoKCQljYXNlIFZFU0FfTk9fQkxBTktJTkc6CgkJCS8qIFR1
cm4gb24gcGFuZWwgKi8KCQkJZmJkZXYtPnJlZ3MtPmxjZF9jb250cm9sIHw9IExDRF9DT05UUk9M
X0dPOwojaWZkZWYgQ09ORklHX01JUFNfUEIxMTAwCgkJCWlmIChkcnZfaW5mby5wYW5lbF9pZHgg
PT0gMSkgewoJCQkJYXVfd3JpdGV3KGF1X3JlYWR3KFBCMTEwMF9HX0NPTlRST0wpIAoJCQkJCSAg
fCAoUEIxMTAwX0dfQ09OVFJPTF9CTCB8IFBCMTEwMF9HX0NPTlRST0xfVkREKSwgCgkJCQkJICBQ
QjExMDBfR19DT05UUk9MKTsKCQkJfQojZW5kaWYKCQkJYXVfc3luYygpOwoJCQlicmVhazsKCgkJ
Y2FzZSBWRVNBX1ZTWU5DX1NVU1BFTkQ6CgkJY2FzZSBWRVNBX0hTWU5DX1NVU1BFTkQ6CgkJY2Fz
ZSBWRVNBX1BPV0VSRE9XTjoKCQkJLyogVHVybiBvZmYgcGFuZWwgKi8KCQkJZmJkZXYtPnJlZ3Mt
PmxjZF9jb250cm9sICY9IH5MQ0RfQ09OVFJPTF9HTzsKI2lmZGVmIENPTkZJR19NSVBTX1BCMTEw
MAoJCQlpZiAoZHJ2X2luZm8ucGFuZWxfaWR4ID09IDEpIHsKCQkJCWF1X3dyaXRldyhhdV9yZWFk
dyhQQjExMDBfR19DT05UUk9MKSAKCQkJCSAgCSAgJiB+KFBCMTEwMF9HX0NPTlRST0xfQkwgfCBQ
QjExMDBfR19DT05UUk9MX1ZERCksCgkJCQkgIAkgIFBCMTEwMF9HX0NPTlRST0wpOwoJCQl9CiNl
bmRpZgoJCQlhdV9zeW5jKCk7CgkJCWJyZWFrOwoKCQlkZWZhdWx0OiAKCQkJYnJlYWs7CgoJfQoJ
cmV0dXJuIDA7Cn0KCi8qIGZiX3Bhbl9kaXNwbGF5CiAqIFBhbiBkaXNwbGF5IGluIHggYW5kL29y
IHkgYXMgc3BlY2lmaWVkCiAqLwppbnQgYXUxMTAwZmJfZmJfcGFuX2Rpc3BsYXkoc3RydWN0IGZi
X3Zhcl9zY3JlZW5pbmZvICp2YXIsIHN0cnVjdCBmYl9pbmZvICpmYmkpCnsKCXN0cnVjdCBhdTEx
MDBmYl9kZXZpY2UgKmZiZGV2ID0gdG9fYXUxMTAwZmJfZGV2aWNlKGZiaSk7CglpbnQgZHk7CgoJ
cHJpbnRfZGJnKCJmYl9wYW5fZGlzcGxheSAlcCAlcCIsIHZhciwgZmJpKTsKCglpZiAoIXZhciB8
fCAhZmJkZXYpIHsKCQlyZXR1cm4gLUVJTlZBTDsKCX0KCglpZiAodmFyLT54b2Zmc2V0IC0gZmJp
LT52YXIueG9mZnNldCkgewoJCS8qIE5vIHN1cHBvcnQgZm9yIFggcGFubmluZyBmb3Igbm93ISAq
LwoJCXJldHVybiAtRUlOVkFMOwoJfQoJCQkKCWR5ID0gdmFyLT55b2Zmc2V0IC0gZmJpLT52YXIu
eW9mZnNldDsKCWlmIChkeSkgewoKCQl1MzIgZG1hYWRkcjsKCgkJcHJpbnRfZGJnKCJQYW5uaW5n
IHNjcmVlbiBvZiAlZCBsaW5lcyIsIGR5KTsKCgkJZG1hYWRkciA9IGZiZGV2LT5yZWdzLT5sY2Rf
ZG1hYWRkcjA7CgkJZG1hYWRkciArPSAoZmJpLT5maXgubGluZV9sZW5ndGggKiBkeSk7CgoJCS8q
IFRPRE86IFdhaXQgZm9yIGN1cnJlbnQgZnJhbWUgdG8gZmluaXNoZWQgKi8KCQlmYmRldi0+cmVn
cy0+bGNkX2RtYWFkZHIwID0gTENEX0RNQV9TQV9OKGRtYWFkZHIpOwoKCQlpZiAocGFuZWxfaXNf
ZHVhbChmYmRldi0+cGFuZWwpKSB7CgkJCWRtYWFkZHIgPSBmYmRldi0+cmVncy0+bGNkX2RtYWFk
ZHIxOwoJCQlkbWFhZGRyICs9IChmYmktPmZpeC5saW5lX2xlbmd0aCAqIGR5KTsKCQkJZmJkZXYt
PnJlZ3MtPmxjZF9kbWFhZGRyMCA9IExDRF9ETUFfU0FfTihkbWFhZGRyKTsKCQl9Cgl9CgoJcmV0
dXJuIDA7Cn0KCi8qIGZiX3JvdGF0ZQogKiBSb3RhdGUgdGhlIGRpc3BsYXkgb2YgdGhpcyBhbmds
ZS4gVGhpcyBkb2Vzbid0IHNlZW1zIHRvIGJlIHVzZWQgYnkgdGhlIGNvcmUsCiAqIGJ1dCBhcyBv
dXIgaGFyZHdhcmUgc3VwcG9ydHMgaXQsIHNvIHdoeSBub3QgaW1wbGVtZW50aW5nIGl0Li4uCiAq
Lwp2b2lkIGF1MTEwMGZiX2ZiX3JvdGF0ZShzdHJ1Y3QgZmJfaW5mbyAqZmJpLCBpbnQgYW5nbGUp
CnsKCXN0cnVjdCBhdTExMDBmYl9kZXZpY2UgKmZiZGV2ID0gdG9fYXUxMTAwZmJfZGV2aWNlKGZi
aSk7CgoJcHJpbnRfZGJnKCJmYl9yb3RhdGUgJXAgJWQiLCBmYmksIGFuZ2xlKTsKCglpZiAoZmJk
ZXYgJiYgKGFuZ2xlID4gMCkgJiYgIShhbmdsZSAlIDkwKSkgewoKCQlhdTExMDBmYl9zdG9wX2Nv
bnRyb2xsZXIoZmJkZXYsIDEpOwoKCQlmYmRldi0+cmVncy0+bGNkX2NvbnRyb2wgJj0gfihMQ0Rf
Q09OVFJPTF9TTV9NQVNLKTsKCQlmYmRldi0+cmVncy0+bGNkX2NvbnRyb2wgfD0gKChhbmdsZS85
MCkgPDwgTENEX0NPTlRST0xfU01fQklUKTsKCgkJYXUxMTAwZmJfc3RhcnRfY29udHJvbGxlcihm
YmRldik7Cgl9Cn0KCi8qIGZiX21tYXAKICogTWFwIHZpZGVvIG1lbW9yeSBpbiB1c2VyIHNwYWNl
LiBXZSBkb24ndCB1c2UgdGhlIGdlbmVyaWMgZmJfbW1hcCBtZXRob2QgbWFpbmx5CiAqIHRvIGFs
bG93IHRoZSB1c2Ugb2YgdGhlIFRMQiBzdHJlYW1pbmcgZmxhZyAoQ0NBPTYpCiAqLwppbnQgYXUx
MTAwZmJfZmJfbW1hcChzdHJ1Y3QgZmJfaW5mbyAqZmJpLCBzdHJ1Y3QgZmlsZSAqZmlsZSwgc3Ry
dWN0IHZtX2FyZWFfc3RydWN0ICp2bWEpCnsKCXN0cnVjdCBhdTExMDBmYl9kZXZpY2UgKmZiZGV2
ID0gdG9fYXUxMTAwZmJfZGV2aWNlKGZiaSk7Cgl1bnNpZ25lZCBpbnQgbGVuOwoJdW5zaWduZWQg
bG9uZyBzdGFydD0wLCBvZmY7CgoJaWYgKHZtYS0+dm1fcGdvZmYgPiAofjBVTCA+PiBQQUdFX1NI
SUZUKSkgewoJCXJldHVybiAtRUlOVkFMOwoJfQogICAgCglzdGFydCA9IGZiZGV2LT5mYl9waHlz
ICYgUEFHRV9NQVNLOwoJbGVuID0gUEFHRV9BTElHTigoc3RhcnQgJiB+UEFHRV9NQVNLKSArIGZi
ZGV2LT5mYl9sZW4pOwoKCW9mZiA9IHZtYS0+dm1fcGdvZmYgPDwgUEFHRV9TSElGVDsKCglpZiAo
KHZtYS0+dm1fZW5kIC0gdm1hLT52bV9zdGFydCArIG9mZikgPiBsZW4pIHsKCQlyZXR1cm4gLUVJ
TlZBTDsKCX0KCglvZmYgKz0gc3RhcnQ7Cgl2bWEtPnZtX3Bnb2ZmID0gb2ZmID4+IFBBR0VfU0hJ
RlQ7CgoJdm1hLT52bV9wYWdlX3Byb3QgPSBwZ3Byb3Rfbm9uY2FjaGVkKHZtYS0+dm1fcGFnZV9w
cm90KTsKCXBncHJvdF92YWwodm1hLT52bV9wYWdlX3Byb3QpIHw9ICg2IDw8IDkpOyAvL0NDQT02
CgoJdm1hLT52bV9mbGFncyB8PSBWTV9JTzsKCglpZiAoaW9fcmVtYXBfcGFnZV9yYW5nZSh2bWEs
IHZtYS0+dm1fc3RhcnQsIG9mZiwKCQkJICAgICAgICB2bWEtPnZtX2VuZCAtIHZtYS0+dm1fc3Rh
cnQsCgkJCSAgICAgICAgdm1hLT52bV9wYWdlX3Byb3QpKSB7CgkJcmV0dXJuIC1FQUdBSU47Cgl9
CgoJcmV0dXJuIDA7Cn0KCnN0YXRpYyBzdHJ1Y3QgZmJfb3BzIGF1MTEwMGZiX2ZiX29wcyA9IAp7
Cgkub3duZXIJCQk9IFRISVNfTU9EVUxFLAoJLmZiX29wZW4JCT0gYXUxMTAwZmJfZmJfb3BlbiwK
CS5mYl9yZWxlYXNlCQk9IGF1MTEwMGZiX2ZiX3JlbGVhc2UsCgkuZmJfY2hlY2tfdmFyCQk9IGF1
MTEwMGZiX2ZiX2NoZWNrX3ZhciwKCS5mYl9zZXRfcGFyCQk9IGF1MTEwMGZiX2ZiX3NldF9wYXIs
CgkuZmJfc2V0Y29scmVnCQk9IGF1MTEwMGZiX2ZiX3NldGNvbHJlZywKCS5mYl9ibGFuawkJPSBh
dTExMDBmYl9mYl9ibGFuaywKCS5mYl9wYW5fZGlzcGxheQkJPSBhdTExMDBmYl9mYl9wYW5fZGlz
cGxheSwKCS5mYl9maWxscmVjdAkJPSBjZmJfZmlsbHJlY3QsCgkuZmJfY29weWFyZWEJCT0gY2Zi
X2NvcHlhcmVhLAoJLmZiX2ltYWdlYmxpdAkJPSBjZmJfaW1hZ2VibGl0LAoJLmZiX2N1cnNvcgkJ
PSBzb2Z0X2N1cnNvciwKCS5mYl9yb3RhdGUJCT0gYXUxMTAwZmJfZmJfcm90YXRlLAoJLmZiX3N5
bmMJCT0gTlVMTCwKCS5mYl9pb2N0bAkJPSBOVUxMLAoJLmZiX21tYXAJCT0gYXUxMTAwZmJfZmJf
bW1hcCwKfTsKCi8qLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSovCgpzdGF0aWMgaXJxcmV0dXJuX3QgYXUxMTAw
ZmJfaGFuZGxlX2lycShpbnQgaXJxLCB2b2lkKiBkZXZfaWQsIHN0cnVjdCBwdF9yZWdzICpyZWdz
KQp7CglzdHJ1Y3QgYXUxMTAwZmJfZGV2aWNlICpmYmRldiA9IAoJCShzdHJ1Y3QgYXUxMTAwZmJf
ZGV2aWNlKikgZGV2X2dldF9kcnZkYXRhKChzdHJ1Y3QgZGV2aWNlKilkZXZfaWQpOwoKCS8qIE5v
dGhpbmcgdG8gZG8gZm9yIG5vdywganVzdCBjbGVhciBhbnkgcGVuZGluZyBpbnRlcnJ1cHQgKi8K
CWZiZGV2LT5yZWdzLT5sY2RfaW50c3RhdHVzID0gfkxDRF9JTlRfU0Q7CgoJcmV0dXJuIElSUV9I
QU5ETEVEOwp9CgovKi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0qLwoKLyogQVUxMTAwIExDRCBkZXZpY2UgcHJv
YmUgaGVscGVycyAqLwoKc3RhdGljIGludCBhdTExMDBmYl9pbml0X21lbShzdHJ1Y3QgZGV2aWNl
KiBkZXYpCnsKCXN0cnVjdCBhdTExMDBmYl9kZXZpY2UgKmZiZGV2ID0gKHN0cnVjdCBhdTExMDBm
Yl9kZXZpY2UqKSBkZXZfZ2V0X2RydmRhdGEoZGV2KTsKCXN0cnVjdCByZXNvdXJjZSAqcmVnc19y
ZXM7Cgl1bnNpZ25lZCBsb25nIHBhZ2U7CgoJaWYgKCFkZXYgfHwgIWZiZGV2IHx8ICFmYmRldi0+
cGFuZWwpCgkJcmV0dXJuIC1FSU5WQUw7CgoJLyogQWxsb2NhdGUgcmVnaW9uIGZvciBvdXIgcmVn
aXN0ZXJzIGFuZCBtYXAgdGhlbSAqLwoJcmVnc19yZXMgPSBwbGF0Zm9ybV9nZXRfcmVzb3VyY2Uo
dG9fcGxhdGZvcm1fZGV2aWNlKGRldiksIElPUkVTT1VSQ0VfTUVNLCAwKTsKCWlmICghcmVnc19y
ZXMpIHsKCQlwcmludF9lcnIoImZhaWwgdG8gcmV0cmlldmUgcmVnaXN0ZXJzIHJlc291cmNlIik7
CgkJcmV0dXJuIC1FRkFVTFQ7Cgl9CgoJZmJkZXYtPnJlZ3NfbGVuID0gcmVnc19yZXMtPmVuZCAt
IHJlZ3NfcmVzLT5zdGFydCArIDE7CglmYmRldi0+cmVnc19waHlzID0gcmVnc19yZXMtPnN0YXJ0
OwoKCWlmICghcmVxdWVzdF9tZW1fcmVnaW9uKGZiZGV2LT5yZWdzX3BoeXMsIGZiZGV2LT5yZWdz
X2xlbiwgRFJJVkVSX05BTUUpKSB7CgkJcHJpbnRfZXJyKCJmYWlsIHRvIGxvY2sgbWVtb3J5IHJl
Z2lvbiBhdCAweCUwOHgiLCBmYmRldi0+cmVnc19waHlzKTsKCQlyZXR1cm4gLUVCVVNZOwoJfQoK
CWZiZGV2LT5yZWdzID0gKHN0cnVjdCBhdTExMDBmYl9yZWdzKilLU0VHMUFERFIoZmJkZXYtPnJl
Z3NfcGh5cyk7CgoJcHJpbnRfZGJnKCJSZWdpc3RlciBtZW1vcnkgbWFwIGF0ICVwIiwgZmJkZXYt
PnJlZ3MpOwoJcHJpbnRfZGJnKCJwaHlzPTB4JTA4eCwgc2l6ZT0lZCIsIGZiZGV2LT5yZWdzX3Bo
eXMsIGZiZGV2LT5yZWdzX2xlbik7CgoJLyogQWxsb2NhdGUgdGhlIGZyYW1lYnVmZmVyIHRvIHRo
ZSBtYXhpbXVtIHNjcmVlbiBzaXplICogbmJyIG9mIHZpZGVvIGJ1ZmZlcnMgKi8KCWZiZGV2LT5m
Yl9sZW4gPSBmYmRldi0+cGFuZWwtPm1heF94cmVzICogZmJkZXYtPnBhbmVsLT5tYXhfeXJlcyAq
CgkJICAJKGZiZGV2LT5wYW5lbC0+bWF4X2JwcCA+PiAzKSAqIEFVMTEwMEZCX05CUl9WSURFT19C
VUZGRVJTOwoKCWZiZGV2LT5mYl9tZW0gPSBkbWFfYWxsb2NfY29oZXJlbnQoZGV2LCBQQUdFX0FM
SUdOKGZiZGV2LT5mYl9sZW4pLCAKCQkJCQkmZmJkZXYtPmZiX3BoeXMsIEdGUF9LRVJORUwpOwoJ
aWYgKCFmYmRldi0+ZmJfbWVtKSB7CgkJcHJpbnRfZXJyKCJmYWlsIHRvIGFsbG9jYXRlIGZyYW1i
dWZmZXIgKHNpemU6ICVkSykpIiwgCgkJCSAgZmJkZXYtPmZiX2xlbiAvIDEwMjQpOwoJCXJldHVy
biAtRU5PTUVNOwoJfQoKCS8qCgkgKiBTZXQgcGFnZSByZXNlcnZlZCBzbyB0aGF0IG1tYXAgd2ls
bCB3b3JrLiBUaGlzIGlzIG5lY2Vzc2FyeQoJICogc2luY2Ugd2UnbGwgYmUgcmVtYXBwaW5nIG5v
cm1hbCBtZW1vcnkuCgkgKi8KCWZvciAocGFnZSA9ICh1bnNpZ25lZCBsb25nKWZiZGV2LT5mYl9t
ZW07CgkgICAgIHBhZ2UgPCBQQUdFX0FMSUdOKCh1bnNpZ25lZCBsb25nKWZiZGV2LT5mYl9tZW0g
KyBmYmRldi0+ZmJfbGVuKTsgCgkgICAgIHBhZ2UgKz0gUEFHRV9TSVpFKSB7CiNpZiBDT05GSUdf
RE1BX05PTkNPSEVSRU5UCgkJU2V0UGFnZVJlc2VydmVkKHZpcnRfdG9fcGFnZShDQUNfQUREUihw
YWdlKSkpOwojZWxzZQoJCVNldFBhZ2VSZXNlcnZlZCh2aXJ0X3RvX3BhZ2UocGFnZSkpOwojZW5k
aWYKCX0KCXByaW50X2RiZygiRnJhbWVidWZmZXIgbWVtb3J5IG1hcCBhdCAlcCIsIGZiZGV2LT5m
Yl9tZW0pOwoJcHJpbnRfZGJnKCJwaHlzPTB4JTA4eCwgc2l6ZT0lZEsiLCBmYmRldi0+ZmJfcGh5
cywgZmJkZXYtPmZiX2xlbiAvIDEwMjQpOwoKCXJldHVybiAwOwp9CgpzdGF0aWMgaW50IGF1MTEw
MGZiX2luaXRfZmJpbmZvKHN0cnVjdCBkZXZpY2UqIGRldikKewoJc3RydWN0IGF1MTEwMGZiX2Rl
dmljZSAqZmJkZXYgPSAoc3RydWN0IGF1MTEwMGZiX2RldmljZSopIGRldl9nZXRfZHJ2ZGF0YShk
ZXYpOwoJc3RydWN0IGZiX2luZm8gKmZiaTsKCQoJaWYgKCFkZXYgfHwgIWZiZGV2IHx8IChkcnZf
aW5mby5wYW5lbF9pZHggPCAwKSkKCQlyZXR1cm4gLUVJTlZBTDsKCglmYmkgPSAmZmJkZXYtPmZi
X2luZm87CgltZW1zZXQoZmJpLCAwLCBzaXplb2Yoc3RydWN0IGZiX2luZm8pKTsKCglmYmktPmZi
b3BzID0gJmF1MTEwMGZiX2ZiX29wczsKCgkvKiBDb3B5IG1vbml0b3Igc3BlY3MgZnJvbSBwYW5l
bCBkYXRhICovCgltZW1jcHkoJmZiaS0+bW9uc3BlY3MsICZmYmRldi0+cGFuZWwtPm1vbnNwZWNz
LCBzaXplb2Yoc3RydWN0IGZiX21vbnNwZWNzKSk7CgoJLyogV2UgZmlyc3QgdHJ5IHRoZSB1c2Vy
IG1vZGUgcGFzc2VkIGluIGFyZ3VtZW50LiBJZiB0aGF0IGZhaWxlZCwgCgkgKiBvciBpZiBubyBv
bmUgaGFzIGJlZW4gc3BlY2lmaWVkLCB3ZSBkZWZhdWx0IHRvIHRoZSBmaXJzdCBtb2RlIG9mIHRo
ZSAKCSAqIHBhbmVsIGxpc3QuIE5vdGUgdGhhdCBhZnRlciB0aGlzIGNhbGwsIHZhciBkYXRhIHdp
bGwgYmUgc2V0ICovCglpZiAoIWZiX2ZpbmRfbW9kZSgmZmJpLT52YXIsIAoJCQkgIGZiaSwgCgkJ
CSAgZHJ2X2luZm8ub3B0X21vZGUsIAoJCQkgIGZiaS0+bW9uc3BlY3MubW9kZWRiLCAKCQkJICBm
YmktPm1vbnNwZWNzLm1vZGVkYl9sZW4sCgkJCSAgZmJpLT5tb25zcGVjcy5tb2RlZGIsIAoJCQkg
IGZiZGV2LT5wYW5lbC0+bWF4X2JwcCkpIHsKCgkJcHJpbnRfZXJyKCJDYW5ub3QgZmluZCB2YWxp
ZCBtb2RlIGZvciBwYW5lbCAlcyIsIGZiZGV2LT5wYW5lbC0+bmFtZSk7CgkJcmV0dXJuIC1FRkFV
TFQ7Cgl9CgoJZmJpLT5wc2V1ZG9fcGFsZXR0ZSA9IGttYWxsb2Moc2l6ZW9mKHUzMikgKiAxNiwg
R0ZQX0tFUk5FTCk7CglpZiAoIWZiaS0+cHNldWRvX3BhbGV0dGUpIHsKCQlyZXR1cm4gLUVOT01F
TTsKCX0KCW1lbXNldChmYmktPnBzZXVkb19wYWxldHRlLCAwLCBzaXplb2YodTMyKSAqIDE2KTsK
CglpZiAoZmJfYWxsb2NfY21hcCgmZmJpLT5jbWFwLCBBVTExMDBfTENEX05CUl9QQUxFVFRFX0VO
VFJJRVMsIDApIDwgMCkgewoJCXByaW50X2VycigiRmFpbCB0byBhbGxvY2F0ZSBjb2xvcm1hcCAo
JWQgZW50cmllcykiLAoJCQkgICBBVTExMDBfTENEX05CUl9QQUxFVFRFX0VOVFJJRVMpOwoJCWtm
cmVlKGZiaS0+cHNldWRvX3BhbGV0dGUpOwoJCXJldHVybiAtRUZBVUxUOwoJfQoKCXN0cm5jcHko
ZmJpLT5maXguaWQsICJBVTExMDAiLCBzaXplb2YoZmJpLT5maXguaWQpKTsKCWZiaS0+Zml4LnNt
ZW1fc3RhcnQgPSBmYmRldi0+ZmJfcGh5czsKCWZiaS0+Zml4LnNtZW1fbGVuID0gZmJkZXYtPmZi
X2xlbjsKCWZiaS0+Zml4LnR5cGUgPSBGQl9UWVBFX1BBQ0tFRF9QSVhFTFM7CglmYmktPmZpeC54
cGFuc3RlcCA9IDE7CglmYmktPmZpeC55cGFuc3RlcCA9IDE7CglmYmktPmZpeC5tbWlvX3N0YXJ0
ID0gMDsKCWZiaS0+Zml4Lm1taW9fbGVuID0gMDsKCWZiaS0+Zml4LmFjY2VsID0gRkJfQUNDRUxf
Tk9ORTsKCglmYmktPnNjcmVlbl9iYXNlID0gZmJkZXYtPmZiX21lbTsKCglhdTExMDBmYl91cGRh
dGVfZmJpbmZvKGZiaSk7CgoJcmV0dXJuIDA7Cn0KCi8qLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSovCgovKiBB
VTExMDAgTENEIGNvbnRyb2xsZXIgZGV2aWNlIGRyaXZlciAqLwoKaW50IGF1MTEwMGZiX2Rydl9w
cm9iZShzdHJ1Y3QgZGV2aWNlICpkZXYpCnsKCXN0cnVjdCBhdTExMDBmYl9kZXZpY2UgKmZiZGV2
ID0gTlVMTDsKCXN0cnVjdCByZXNvdXJjZSAqaXJxX3JlcyA9IE5VTEw7Cgl1MzIgc3lzX2Nsa3Ny
YzsKCWludCByZXQ7CgoJaWYgKCFkZXYpCgkJcmV0dXJuIC1FSU5WQUw7CgoJLyogQWxsb2NhdGUg
bmV3IGRldmljZSBwcml2YXRlICovCglmYmRldiA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBhdTEx
MDBmYl9kZXZpY2UpLCBHRlBfS0VSTkVMKTsKCWlmICghZmJkZXYpIHsKCQlwcmludF9lcnIoImZh
aWwgdG8gYWxsb2NhdGUgZGV2aWNlIHByaXZhdGUgcmVjb3JkIik7CgkJcmV0dXJuIC1FTk9NRU07
Cgl9CgoJbWVtc2V0KCh2b2lkKilmYmRldiwgMCwgc2l6ZW9mKHN0cnVjdCBhdTExMDBmYl9kZXZp
Y2UpKTsKCWZiZGV2LT5wYW5lbCA9ICZrbm93bl9sY2RfcGFuZWxzW2Rydl9pbmZvLnBhbmVsX2lk
eF07CglmYmRldi0+aXJxID0gLTE7CgoJZGV2X3NldF9kcnZkYXRhKGRldiwgKHZvaWQqKWZiZGV2
KTsKCgkvKiBJbml0IElPIGFuZCBmcmFtZWJ1ZmZlciBtZW1vcnkgKi8KCXJldCA9IGF1MTEwMGZi
X2luaXRfbWVtKGRldik7CglpZiAocmV0IDwgMCkgewoJCWdvdG8gZmFpbGVkOwoJfQoKCS8qIFJl
cXVlc3QgdGhlIElSUSBsaW5lICovCglpcnFfcmVzID0gcGxhdGZvcm1fZ2V0X3Jlc291cmNlKHRv
X3BsYXRmb3JtX2RldmljZShkZXYpLCBJT1JFU09VUkNFX0lSUSwgMCk7CglpZiAoIWlycV9yZXMp
IHsKCQlwcmludF9lcnIoImZhaWwgdG8gcmV0cmlldmUgSVJRIHJlc291cmNlIik7CgkJcmV0ID0g
LUVGQVVMVDsKCQlnb3RvIGZhaWxlZDsKCX0KCglyZXQgPSByZXF1ZXN0X2lycShpcnFfcmVzLT5z
dGFydCwgYXUxMTAwZmJfaGFuZGxlX2lycSwgCgkJIAkgIFNBX0lOVEVSUlVQVCwgImxjZCIsICh2
b2lkKilkZXYpOwoJaWYgKHJldCA8IDApIHsKCQlwcmludF9lcnIoImZhaWwgdG8gcmVxdWVzdCBp
bnRlcnJ1cHQgbGluZSAlbGQgKGVycjogJWQpIiwKCQkJICBpcnFfcmVzLT5zdGFydCwgcmV0KTsK
CQlnb3RvIGZhaWxlZDsKCX0KCglmYmRldi0+aXJxID0gaXJxX3Jlcy0+c3RhcnQ7CgoJLyogU2V0
dXAgTENEIGNsb2NrIHRvIEFVWCAoNDggTUh6KSAqLwoJc3lzX2Nsa3NyYyA9IGF1X3JlYWRsKFNZ
U19DTEtTUkMpICYgfihTWVNfQ1NfTUxfTUFTSyB8IFNZU19DU19ETCB8IFNZU19DU19DTCk7Cglh
dV93cml0ZWwoKHN5c19jbGtzcmMgfCAoMSA8PCBTWVNfQ1NfTUxfQklUKSksIFNZU19DTEtTUkMp
OwoKCS8qIEluaXQgRkIgZGF0YSAqLwoJcmV0ID0gYXUxMTAwZmJfaW5pdF9mYmluZm8oZGV2KTsK
CWlmIChyZXQgPCAwKSB7CgkJZ290byBmYWlsZWQ7Cgl9CgoJLyogUmVnaXN0ZXIgbmV3IGZyYW1l
YnVmZmVyICovCglyZXQgPSByZWdpc3Rlcl9mcmFtZWJ1ZmZlcigmZmJkZXYtPmZiX2luZm8pOwoJ
aWYgKHJldCA8IDApIHsKCQlwcmludF9lcnIoImNhbm5vdCByZWdpc3RlciBuZXcgZnJhbWVidWZm
ZXIiKTsKCQlnb3RvIGZhaWxlZDsKCX0KCiNpZiAhZGVmaW5lZChDT05GSUdfRlJBTUVCVUZGRVJf
Q09OU09MRSkgJiYgZGVmaW5lZChDT05GSUdfTE9HTykKCWlmIChmYl9wcmVwYXJlX2xvZ28oJmZi
ZGV2LT5mYl9pbmZvKSkgewoKCQkvKiBTdGFydCBkaXNwbGF5IGFuZCBzaG93IGxvZ28gb24gYm9v
dCAqLwoJCWF1MTEwMGZiX2ZiX3NldF9wYXIoJmZiZGV2LT5mYl9pbmZvKTsKCQlmYl9zZXRfY21h
cCgmZmJkZXYtPmZiX2luZm8uY21hcCwgJmZiZGV2LT5mYl9pbmZvKTsKCgkJZmJfc2hvd19sb2dv
KCZmYmRldi0+ZmJfaW5mbyk7Cgl9CiNlbmRpZgoJcmV0dXJuIDA7CgpmYWlsZWQ6CglpZiAoZmJk
ZXYtPmlycSA+PSAwKSB7CgkJZnJlZV9pcnEoZmJkZXYtPmlycSwgKHZvaWQqKWRldik7Cgl9Cglp
ZiAoZmJkZXYtPnJlZ3MpIHsKCQlyZWxlYXNlX21lbV9yZWdpb24oZmJkZXYtPnJlZ3NfcGh5cywg
ZmJkZXYtPnJlZ3NfbGVuKTsKCX0KCWlmIChmYmRldi0+ZmJfbWVtKSB7CgkJZG1hX2ZyZWVfbm9u
Y29oZXJlbnQoZGV2LCBmYmRldi0+ZmJfbGVuLCBmYmRldi0+ZmJfbWVtLCBmYmRldi0+ZmJfcGh5
cyk7Cgl9CglpZiAoZmJkZXYtPmZiX2luZm8uY21hcC5sZW4gIT0gMCkgewoJCWZiX2RlYWxsb2Nf
Y21hcCgmZmJkZXYtPmZiX2luZm8uY21hcCk7Cgl9CglrZnJlZShmYmRldik7CglkZXZfc2V0X2Ry
dmRhdGEoZGV2LCBOVUxMKTsKCglyZXR1cm4gcmV0Owp9CgppbnQgYXUxMTAwZmJfZHJ2X3JlbW92
ZShzdHJ1Y3QgZGV2aWNlICpkZXYpCnsKCXN0cnVjdCBhdTExMDBmYl9kZXZpY2UgKmZiZGV2ID0g
TlVMTDsKCglpZiAoIWRldikKCQlyZXR1cm4gLUVOT0RFVjsKCglmYmRldiA9IChzdHJ1Y3QgYXUx
MTAwZmJfZGV2aWNlKikgZGV2X2dldF9kcnZkYXRhKGRldik7CgojaWYgIWRlZmluZWQoQ09ORklH
X0ZSQU1FQlVGRkVSX0NPTlNPTEUpICYmIGRlZmluZWQoQ09ORklHX0xPR08pCglhdTExMDBmYl9m
Yl9ibGFuayhWRVNBX1BPV0VSRE9XTiwgJmZiZGV2LT5mYl9pbmZvKTsKI2VuZGlmCglhdTExMDBm
Yl9zdG9wX2NvbnRyb2xsZXIoZmJkZXYsIDApOwoKCS8qIENsZWFuIHVwIGFsbCBwcm9iZSBkYXRh
ICovCgl1bnJlZ2lzdGVyX2ZyYW1lYnVmZmVyKCZmYmRldi0+ZmJfaW5mbyk7CgoJZnJlZV9pcnEo
ZmJkZXYtPmlycSwgKHZvaWQqKWRldik7CglyZWxlYXNlX21lbV9yZWdpb24oZmJkZXYtPnJlZ3Nf
cGh5cywgZmJkZXYtPnJlZ3NfbGVuKTsKCglkbWFfZnJlZV9jb2hlcmVudChkZXYsIFBBR0VfQUxJ
R04oZmJkZXYtPmZiX2xlbiksIGZiZGV2LT5mYl9tZW0sIGZiZGV2LT5mYl9waHlzKTsKCglmYl9k
ZWFsbG9jX2NtYXAoJmZiZGV2LT5mYl9pbmZvLmNtYXApOwoJa2ZyZWUoZmJkZXYtPmZiX2luZm8u
cHNldWRvX3BhbGV0dGUpOwoJa2ZyZWUoKHZvaWQqKWZiZGV2KTsKCglyZXR1cm4gMDsKfQoKaW50
IGF1MTEwMGZiX2Rydl9zdXNwZW5kKHN0cnVjdCBkZXZpY2UgKmRldiwgdTMyIHN0YXRlLCB1MzIg
bGV2ZWwpCnsKCS8qIFRPRE8gKi8KCXJldHVybiAwOwp9CgppbnQgYXUxMTAwZmJfZHJ2X3Jlc3Vt
ZShzdHJ1Y3QgZGV2aWNlICpkZXYsIHUzMiBsZXZlbCkKewoJLyogVE9ETyAqLwoJcmV0dXJuIDA7
Cn0KCnN0YXRpYyBzdHJ1Y3QgZGV2aWNlX2RyaXZlciBhdTExMDBmYl9kcml2ZXIgPSB7CgkubmFt
ZQkJPSAiYXUxMTAwLWxjZCIsCgkuYnVzCQk9ICZwbGF0Zm9ybV9idXNfdHlwZSwKCgkucHJvYmUJ
CT0gYXUxMTAwZmJfZHJ2X3Byb2JlLAogICAgICAgIC5yZW1vdmUJCT0gYXUxMTAwZmJfZHJ2X3Jl
bW92ZSwKCS5zdXNwZW5kCT0gYXUxMTAwZmJfZHJ2X3N1c3BlbmQsCiAgICAgICAgLnJlc3VtZQkJ
PSBhdTExMDBmYl9kcnZfcmVzdW1lLAp9OwoKLyotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKi8KCi8qIEtlcm5l
bCBkcml2ZXIgKi8KCmludCBhdTExMDBmYl9zZXR1cChjaGFyICpvcHRpb25zKQp7CgljaGFyKiB0
aGlzX29wdDsKCWludCBudW1fcGFuZWxzID0gQVJSQVlfU0laRShrbm93bl9sY2RfcGFuZWxzKTsK
CWNoYXIqIG1vZGUgPSBOVUxMOwoJaW50IHBhbmVsX2lkeCA9IC0xOwoKCWlmIChudW1fcGFuZWxz
IDw9IDApIHsKCQlwcmludF9lcnIoIk5vIExDRCBwYW5lbHMgc3VwcG9ydGVkIGJ5IGRyaXZlciEi
KTsKCQlyZXR1cm4gLUVGQVVMVDsKCX0KCglpZiAob3B0aW9ucykgewoJCXdoaWxlICgodGhpc19v
cHQgPSBzdHJzZXAoJm9wdGlvbnMsIiwiKSkgIT0gTlVMTCkgewoJCQkvKiBQYW5lbCBvcHRpb24g
Ki8KCQkJaWYgKCFzdHJuY21wKHRoaXNfb3B0LCAicGFuZWw6IiwgNikpIHsKCQkJCWludCBpOwoJ
CQkJdGhpc19vcHQgKz0gNjsKCQkJCWZvciAoaSA9IDA7IGkgPCBudW1fcGFuZWxzOyBpKyspIHsK
CQkJCQlpZiAoIXN0cm5jbXAodGhpc19vcHQsCgkJCQkJICAgICAgCSAgICAga25vd25fbGNkX3Bh
bmVsc1tpXS5uYW1lLCAKCQkJCQkJICAgICBzdHJsZW4odGhpc19vcHQpKSkgewoJCQkJCQlwYW5l
bF9pZHggPSBpOwoJCQkJCQlicmVhazsKCQkJCQl9CgkJCQl9CgkJCQlpZiAoaSA+PSBudW1fcGFu
ZWxzKSB7CiAJCQkJCXByaW50X3dhcm4oIlBhbmVsICVzIG5vdCBzdXBwb3J0ZWQhIiwgdGhpc19v
cHQpOwoJCQkJfQoJCQl9CgkJCS8qIE1vZGUgb3B0aW9uIChvbmx5IG9wdGlvbiB0aGF0IHN0YXJ0
IHdpdGggZGlnaXQpICovCgkJCWVsc2UgaWYgKGlzZGlnaXQodGhpc19vcHRbMF0pKSB7CgkJCQlt
b2RlID0ga21hbGxvYyhzdHJsZW4odGhpc19vcHQpICsgMSwgR0ZQX0tFUk5FTCk7CgkJCQlzdHJu
Y3B5KG1vZGUsIHRoaXNfb3B0LCBzdHJsZW4odGhpc19vcHQpICsgMSk7CgkJCX0KCQkJLyogVW5z
dXBwb3J0ZWQgb3B0aW9uICovCgkJCWVsc2UgewoJCQkJcHJpbnRfd2FybigiVW5zdXBwb3J0ZWQg
b3B0aW9uIFwiJXNcIiIsIHRoaXNfb3B0KTsKCQkJfQoJCX0KCX0KCglpZiAocGFuZWxfaWR4IDwg
MCkgewojaWYgZGVmaW5lZChDT05GSUdfTUlQU19QQjExMDApIHx8IGRlZmluZWQoQ09ORklHX01J
UFNfREIxMTAwKQoJCS8qIEdldCBwYW5lbCBmcm9tIFMxMCBTd2l0Y2ggKGJvYXJkIHN3aXRjaCkg
Ki8KCQlwYW5lbF9pZHggPSAoKCoodm9sYXRpbGUgaW50ICopQkNTUl9TV0lUQ0hFU19SRUcpICYK
CQkJCUJDU1JfU1dJVENIRVNfUk9UQVJZX01BU0spID4+IEJDU1JfU1dJVENIRVNfUk9UQVJZX0JJ
VDsKCQlpZiAocGFuZWxfaWR4ID49IG51bV9wYW5lbHMpCiNlbmRpZgoJCXBhbmVsX2lkeCA9IDA7
Cgl9CgoJZHJ2X2luZm8ucGFuZWxfaWR4ID0gcGFuZWxfaWR4OwoJZHJ2X2luZm8ub3B0X21vZGUg
PSBtb2RlOwoKCXByaW50X2luZm8oIlBhbmVsPSVzIE1vZGU9JXMiLAoJCQlrbm93bl9sY2RfcGFu
ZWxzW2Rydl9pbmZvLnBhbmVsX2lkeF0ubmFtZSwKCQkgICAgICAJZHJ2X2luZm8ub3B0X21vZGUg
PyBkcnZfaW5mby5vcHRfbW9kZSA6ICJkZWZhdWx0Iik7CgoJcmV0dXJuIDA7Cn0KCmludCBfX2lu
aXQgYXUxMTAwZmJfaW5pdCh2b2lkKQp7CgljaGFyKiBvcHRpb25zOwoJaW50IHJldDsKCQoJcHJp
bnRfaW5mbygiIiBEUklWRVJfREVTQyAiIik7CgkKCW1lbXNldCgmZHJ2X2luZm8sIDAsIHNpemVv
ZihkcnZfaW5mbykpOwoKCWlmIChmYl9nZXRfb3B0aW9ucyhEUklWRVJfTkFNRSwgJm9wdGlvbnMp
KQoJCXJldHVybiAtRU5PREVWOwoKCS8qIFNldHVwIGRyaXZlciB3aXRoIG9wdGlvbnMgKi8KCXJl
dCA9IGF1MTEwMGZiX3NldHVwKG9wdGlvbnMpOwoJaWYgKHJldCA8IDApIHsKCQlwcmludF9lcnIo
IkZhaWwgdG8gc2V0dXAgZHJpdmVyIik7CgkJcmV0dXJuIHJldDsKCX0KCglyZXR1cm4gZHJpdmVy
X3JlZ2lzdGVyKCZhdTExMDBmYl9kcml2ZXIpOwp9Cgp2b2lkIF9fZXhpdCBhdTExMDBmYl9jbGVh
bnVwKHZvaWQpCnsKCWRyaXZlcl91bnJlZ2lzdGVyKCZhdTExMDBmYl9kcml2ZXIpOwoKCWlmIChk
cnZfaW5mby5vcHRfbW9kZSkKCQlrZnJlZShkcnZfaW5mby5vcHRfbW9kZSk7Cn0KCm1vZHVsZV9p
bml0KGF1MTEwMGZiX2luaXQpOwptb2R1bGVfZXhpdChhdTExMDBmYl9jbGVhbnVwKTsKCk1PRFVM
RV9ERVNDUklQVElPTihEUklWRVJfREVTQyk7Ck1PRFVMRV9MSUNFTlNFKCJHUEwiKTsK

--------------Boundary-00=_ICQ3JWJBDIHX28K5NGD6
Content-Type: text/x-c;
  charset="iso-8859-1";
  name="au1100fb.h"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="au1100fb.h"

LyoKICogQlJJRUYgTU9EVUxFIERFU0NSSVBUSU9OCiAqCUhhcmR3YXJlIGRlZmluaXRpb25zIGZv
ciB0aGUgQXUxMTAwIExDRCBjb250cm9sbGVyCiAqCiAqIENvcHlyaWdodCAyMDAyIE1vbnRhVmlz
dGEgU29mdHdhcmUKICogQ29weXJpZ2h0IDIwMDIgQWxjaGVteSBTZW1pY29uZHVjdG9yCiAqIEF1
dGhvcjoJQWxjaGVteSBTZW1pY29uZHVjdG9yLCBNb250YVZpc3RhIFNvZnR3YXJlCiAqCiAqICBU
aGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUJIGl0IGFu
ZC9vciBtb2RpZnkgaXQKICogIHVuZGVyICB0aGUgdGVybXMgb2YJIHRoZSBHTlUgR2VuZXJhbCAg
UHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5IHRoZQogKiAgRnJlZSBTb2Z0d2FyZSBGb3Vu
ZGF0aW9uOyAgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUJTGljZW5zZSwgb3IgKGF0IHlvdXIKICog
IG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCiAqCiAqICBUSElTICBTT0ZUV0FSRSAgSVMgUFJP
VklERUQJICBgYEFTCUlTJycgQU5EICAgQU5ZCUVYUFJFU1MgT1IgSU1QTElFRAogKiAgV0FSUkFO
VElFUywJICBJTkNMVURJTkcsIEJVVCBOT1QgIExJTUlURUQgIFRPLCBUSEUgSU1QTElFRCBXQVJS
QU5USUVTIE9GCiAqICBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB
UiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiAgSU4KICogIE5PCUVWRU5UICBTSEFMTCAgIFRIRSBB
VVRIT1IgIEJFCSBMSUFCTEUgRk9SIEFOWQkgIERJUkVDVCwgSU5ESVJFQ1QsCiAqICBJTkNJREVO
VEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVE
SU5HLCBCVVQKICogIE5PVCBMSU1JVEVECSAgVE8sIFBST0NVUkVNRU5UIE9GICBTVUJTVElUVVRF
IEdPT0RTCU9SIFNFUlZJQ0VTOyBMT1NTIE9GCiAqICBVU0UsIERBVEEsCU9SIFBST0ZJVFM7IE9S
CUJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OCiAqICBBTlkgVEhF
T1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTgkgQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFks
IE9SIFRPUlQKICogIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcg
SU4gQU5ZIFdBWSBPVVQgT0YgVEhFIFVTRSBPRgogKiAgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBB
RFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4KICoKICogIFlvdSBzaG91
bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlICBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZSBhbG9uZwogKiAgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgIHRvIHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4sCiAqICA2NzUgTWFzcyBBdmUsIENhbWJyaWRnZSwg
TUEgMDIxMzksIFVTQS4KICovCgojaWZuZGVmIF9BVTExMDBMQ0RfSAojZGVmaW5lIF9BVTExMDBM
Q0RfSAoKI2luY2x1ZGUgPGFzbS9tYWNoLWF1MXgwMC9hdTEwMDAuaD4KCiNkZWZpbmUgcHJpbnRf
ZXJyKGYsIGFyZy4uLikgcHJpbnRrKEtFUk5fRVJSIERSSVZFUl9OQU1FICI6ICIgZiAiXG4iLCAj
IyBhcmcpCiNkZWZpbmUgcHJpbnRfd2FybihmLCBhcmcuLi4pIHByaW50ayhLRVJOX1dBUk5JTkcg
RFJJVkVSX05BTUUgIjogIiBmICJcbiIsICMjIGFyZykKI2RlZmluZSBwcmludF9pbmZvKGYsIGFy
Zy4uLikgcHJpbnRrKEtFUk5fSU5GTyBEUklWRVJfTkFNRSAiOiAiIGYgIlxuIiwgIyMgYXJnKQoK
I2lmIERFQlVHCiNkZWZpbmUgcHJpbnRfZGJnKGYsIGFyZy4uLikgcHJpbnRrKEtFUk5fREVCVUcg
X19GSUxFX18gIjogIiBmICJcbiIsICMjIGFyZykKI2Vsc2UKI2RlZmluZSBwcmludF9kYmcoZiwg
YXJnLi4uKSBkbyB7fSB3aGlsZSAoMCkKI2VuZGlmCgojaWYgZGVmaW5lZChfX0JJR19FTkRJQU4p
CiNkZWZpbmUgTENEX0NPTlRST0xfREVGQVVMVF9QTyBMQ0RfQ09OVFJPTF9QT18xMQojZWxzZQoj
ZGVmaW5lIExDRF9DT05UUk9MX0RFRkFVTFRfUE8gTENEX0NPTlRST0xfUE9fMDAKI2VuZGlmCiNk
ZWZpbmUgTENEX0NPTlRST0xfREVGQVVMVF9TQlBQRiBMQ0RfQ09OVFJPTF9TQlBQRl81NjUKCi8q
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKi8KCi8qIExDRCBjb250cm9sbGVyIHJlc3RyaWN0aW9ucyAqLwojZGVmaW5lIEFV
MTEwMF9MQ0RfTUFYX1hSRVMJODAwCiNkZWZpbmUgQVUxMTAwX0xDRF9NQVhfWVJFUwk2MDAKI2Rl
ZmluZSBBVTExMDBfTENEX01BWF9CUFAJMTYKI2RlZmluZSBBVTExMDBfTENEX01BWF9DTEsJNDgw
MDAwMDAKI2RlZmluZSBBVTExMDBfTENEX05CUl9QQUxFVFRFX0VOVFJJRVMgMjU2CgovKiBEZWZh
dWx0IG51bWJlciBvZiB2aXNpYmxlIHNjcmVlbiBidWZmZXIgdG8gYWxsb2NhdGUgKi8KI2RlZmlu
ZSBBVTExMDBGQl9OQlJfVklERU9fQlVGRkVSUyA0CgovKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCgpzdHJ1Y3QgYXUx
MTAwZmJfcGFuZWwKewoJY29uc3QgY2hhciBuYW1lWzI1XTsJCS8qIEZ1bGwgbmFtZSA8dmVuZG9y
Pl88bW9kZWw+ICovCgkKCXN0cnVjdCAJZmJfbW9uc3BlY3MgbW9uc3BlY3M7IAkvKiBGQiBtb25p
dG9yIHNwZWNzICovCgoJdTMyICAgCWNvbnRyb2xfYmFzZTsJCS8qIE1vZGUtaW5kZXBlbmRlbnQg
Y29udHJvbCB2YWx1ZXMgKi8KCXUzMgljbGtjb250cm9sX2Jhc2U7CS8qIFBhbmVsIHBpeGNsb2Nr
IHByZWZlcmVuY2VzICovCgoJdTMyCW1pbl94cmVzOwkJLyogTWluaW11bSBob3Jpem9udGFsIHJl
c29sdXRpb24gKi8KCXUzMgltYXhfeHJlczsJCS8qIE1heGltdW0gaG9yaXpvbnRhbCByZXNvbHV0
aW9uICovCgl1MzIgCW1pbl95cmVzOwkJLyogTWluaW11bSB2ZXJ0aWNhbCByZXNvbHV0aW9uICov
Cgl1MzIgCW1heF95cmVzOwkJLyogTWF4aW11bSB2ZXJ0aWNhbCByZXNvbHV0aW9uICovCgl1MzIg
CW1heF9icHA7CQkvKiBNYXhpbXVtIGRlcHRoIHN1cHBvcnRlZCAqLwp9OwoKc3RydWN0IGF1MTEw
MGZiX3JlZ3MgCnsKCXUzMiAgbGNkX2NvbnRyb2w7Cgl1MzIgIGxjZF9pbnRzdGF0dXM7Cgl1MzIg
IGxjZF9pbnRlbmFibGU7Cgl1MzIgIGxjZF9ob3J6dGltaW5nOwoJdTMyICBsY2RfdmVydHRpbWlu
ZzsKCXUzMiAgbGNkX2Nsa2NvbnRyb2w7Cgl1MzIgIGxjZF9kbWFhZGRyMDsKCXUzMiAgbGNkX2Rt
YWFkZHIxOwoJdTMyICBsY2Rfd29yZHM7Cgl1MzIgIGxjZF9wd21kaXY7Cgl1MzIgIGxjZF9wd21o
aTsKCXUzMiAgcmVzZXJ2ZWRbKDB4MDQwMC0weDAwMkMpLzRdOwoJdTMyICBsY2RfcGFsbGV0dGVi
YXNlWzI1Nl07Cn07CgpzdHJ1Y3QgYXUxMTAwZmJfZGV2aWNlIHsKCglzdHJ1Y3QgZmJfaW5mbyBm
Yl9pbmZvOwkJCS8qIEZCIGRyaXZlciBpbmZvIHJlY29yZCAqLwoKCXN0cnVjdCBhdTExMDBmYl9w
YW5lbCAJKnBhbmVsOwkJLyogUGFuZWwgY29ubmVjdGVkIHRvIHRoaXMgZGV2aWNlICovCgoJaW50
IGlycTsJCQkJLyogSVJRIHVzZWQgKi8KCglzdHJ1Y3QgYXUxMTAwZmJfcmVncyogCXJlZ3M7CQkv
KiBSZWdpc3RlcnMgbWVtb3J5IG1hcCAqLwoJc2l6ZV90ICAgICAgIAkJcmVnc19sZW47Cgl1bnNp
Z25lZCBpbnQgCQlyZWdzX3BoeXM7CgoJdW5zaWduZWQgY2hhciogCQlmYl9tZW07CQkvKiBGcmFt
ZUJ1ZmZlciBtZW1vcnkgbWFwICovCglzaXplX3QJICAgICAgCQlmYl9sZW47CglkbWFfYWRkcl90
ICAgIAkJZmJfcGh5czsKfTsKCi8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KCiNkZWZpbmUgTENEX0NPTlRST0wgICAg
ICAgICAgICAgICAgKEFVMTEwMF9MQ0RfQkFTRSArIDB4MCkKICAjZGVmaW5lIExDRF9DT05UUk9M
X1NCQl9CSVQgICAgICAyMQogICNkZWZpbmUgTENEX0NPTlRST0xfU0JCX01BU0sgICAgICgweDMg
PDwgTENEX0NPTlRST0xfU0JCX0JJVCkKICAgICNkZWZpbmUgTENEX0NPTlRST0xfU0JCXzEgICAg
ICAgICgwIDw8IExDRF9DT05UUk9MX1NCQl9CSVQpCiAgICAjZGVmaW5lIExDRF9DT05UUk9MX1NC
Ql8yICAgICAgICAoMSA8PCBMQ0RfQ09OVFJPTF9TQkJfQklUKQogICAgI2RlZmluZSBMQ0RfQ09O
VFJPTF9TQkJfMyAgICAgICAgKDIgPDwgTENEX0NPTlRST0xfU0JCX0JJVCkKICAgICNkZWZpbmUg
TENEX0NPTlRST0xfU0JCXzQgICAgICAgICgzIDw8IExDRF9DT05UUk9MX1NCQl9CSVQpCiAgI2Rl
ZmluZSBMQ0RfQ09OVFJPTF9TQlBQRl9CSVQgICAgMTgKICAjZGVmaW5lIExDRF9DT05UUk9MX1NC
UFBGX01BU0sgICAoMHg3IDw8IExDRF9DT05UUk9MX1NCUFBGX0JJVCkKICAgICNkZWZpbmUgTENE
X0NPTlRST0xfU0JQUEZfNjU1ICAgICgwIDw8IExDRF9DT05UUk9MX1NCUFBGX0JJVCkKICAgICNk
ZWZpbmUgTENEX0NPTlRST0xfU0JQUEZfNTY1ICAgICgxIDw8IExDRF9DT05UUk9MX1NCUFBGX0JJ
VCkKICAgICNkZWZpbmUgTENEX0NPTlRST0xfU0JQUEZfNTU2ICAgICgyIDw8IExDRF9DT05UUk9M
X1NCUFBGX0JJVCkKICAgICNkZWZpbmUgTENEX0NPTlRST0xfU0JQUEZfMTU1NSAgICgzIDw8IExD
RF9DT05UUk9MX1NCUFBGX0JJVCkKICAgICNkZWZpbmUgTENEX0NPTlRST0xfU0JQUEZfNTU1MSAg
ICg0IDw8IExDRF9DT05UUk9MX1NCUFBGX0JJVCkKICAjZGVmaW5lIExDRF9DT05UUk9MX1dQICAg
ICAgICAgICAoMTw8MTcpCiAgI2RlZmluZSBMQ0RfQ09OVFJPTF9XRCAgICAgICAgICAgKDE8PDE2
KQogICNkZWZpbmUgTENEX0NPTlRST0xfQyAgICAgICAgICAgICgxPDwxNSkKICAjZGVmaW5lIExD
RF9DT05UUk9MX1NNX0JJVCAgICAgICAxMwogICNkZWZpbmUgTENEX0NPTlRST0xfU01fTUFTSyAg
ICAgICgweDMgPDwgTENEX0NPTlRST0xfU01fQklUKQogICAgI2RlZmluZSBMQ0RfQ09OVFJPTF9T
TV8wICAgICAgICAgKDAgPDwgTENEX0NPTlRST0xfU01fQklUKQogICAgI2RlZmluZSBMQ0RfQ09O
VFJPTF9TTV85MCAgICAgICAgKDEgPDwgTENEX0NPTlRST0xfU01fQklUKQogICAgI2RlZmluZSBM
Q0RfQ09OVFJPTF9TTV8xODAgICAgICAgKDIgPDwgTENEX0NPTlRST0xfU01fQklUKQogICAgI2Rl
ZmluZSBMQ0RfQ09OVFJPTF9TTV8yNzAgICAgICAgKDMgPDwgTENEX0NPTlRST0xfU01fQklUKQog
ICNkZWZpbmUgTENEX0NPTlRST0xfREIgICAgICAgICAgICgxPDwxMikKICAjZGVmaW5lIExDRF9D
T05UUk9MX0NDTyAgICAgICAgICAoMTw8MTEpCiAgI2RlZmluZSBMQ0RfQ09OVFJPTF9EUCAgICAg
ICAgICAgKDE8PDEwKQogICNkZWZpbmUgTENEX0NPTlRST0xfUE9fQklUICAgICAgIDgKICAjZGVm
aW5lIExDRF9DT05UUk9MX1BPX01BU0sgICAgICAoMHgzIDw8IExDRF9DT05UUk9MX1BPX0JJVCkK
ICAgICNkZWZpbmUgTENEX0NPTlRST0xfUE9fMDAgICAgICAgICgwIDw8IExDRF9DT05UUk9MX1BP
X0JJVCkKICAgICNkZWZpbmUgTENEX0NPTlRST0xfUE9fMDEgICAgICAgICgxIDw8IExDRF9DT05U
Uk9MX1BPX0JJVCkKICAgICNkZWZpbmUgTENEX0NPTlRST0xfUE9fMTAgICAgICAgICgyIDw8IExD
RF9DT05UUk9MX1BPX0JJVCkKICAgICNkZWZpbmUgTENEX0NPTlRST0xfUE9fMTEgICAgICAgICgz
IDw8IExDRF9DT05UUk9MX1BPX0JJVCkKICAjZGVmaW5lIExDRF9DT05UUk9MX01QSSAgICAgICAg
ICAoMTw8NykKICAjZGVmaW5lIExDRF9DT05UUk9MX1BUICAgICAgICAgICAoMTw8NikKICAjZGVm
aW5lIExDRF9DT05UUk9MX1BDICAgICAgICAgICAoMTw8NSkKICAjZGVmaW5lIExDRF9DT05UUk9M
X0JQUF9CSVQgICAgICAxCiAgI2RlZmluZSBMQ0RfQ09OVFJPTF9CUFBfTUFTSyAgICAgKDB4NyA8
PCBMQ0RfQ09OVFJPTF9CUFBfQklUKQogICAgI2RlZmluZSBMQ0RfQ09OVFJPTF9CUFBfMSAgICAg
ICAgKDAgPDwgTENEX0NPTlRST0xfQlBQX0JJVCkKICAgICNkZWZpbmUgTENEX0NPTlRST0xfQlBQ
XzIgICAgICAgICgxIDw8IExDRF9DT05UUk9MX0JQUF9CSVQpCiAgICAjZGVmaW5lIExDRF9DT05U
Uk9MX0JQUF80ICAgICAgICAoMiA8PCBMQ0RfQ09OVFJPTF9CUFBfQklUKQogICAgI2RlZmluZSBM
Q0RfQ09OVFJPTF9CUFBfOCAgICAgICAgKDMgPDwgTENEX0NPTlRST0xfQlBQX0JJVCkKICAgICNk
ZWZpbmUgTENEX0NPTlRST0xfQlBQXzEyICAgICAgICg0IDw8IExDRF9DT05UUk9MX0JQUF9CSVQp
CiAgICAjZGVmaW5lIExDRF9DT05UUk9MX0JQUF8xNiAgICAgICAoNSA8PCBMQ0RfQ09OVFJPTF9C
UFBfQklUKQogICNkZWZpbmUgTENEX0NPTlRST0xfR08gICAgICAgICAgICgxPDwwKQoKI2RlZmlu
ZSBMQ0RfSU5UU1RBVFVTICAgICAgICAgICAgICAoQVUxMTAwX0xDRF9CQVNFICsgMHg0KQojZGVm
aW5lIExDRF9JTlRFTkFCTEUgICAgICAgICAgICAgIChBVTExMDBfTENEX0JBU0UgKyAweDgpCiAg
I2RlZmluZSBMQ0RfSU5UX1NEICAgICAgICAgICAgICAgKDE8PDcpCiAgI2RlZmluZSBMQ0RfSU5U
X09GICAgICAgICAgICAgICAgKDE8PDYpCiAgI2RlZmluZSBMQ0RfSU5UX1VGICAgICAgICAgICAg
ICAgKDE8PDUpCiAgI2RlZmluZSBMQ0RfSU5UX1NBICAgICAgICAgICAgICAgKDE8PDMpCiAgI2Rl
ZmluZSBMQ0RfSU5UX1NTICAgICAgICAgICAgICAgKDE8PDIpCiAgI2RlZmluZSBMQ0RfSU5UX1Mx
ICAgICAgICAgICAgICAgKDE8PDEpCiAgI2RlZmluZSBMQ0RfSU5UX1MwICAgICAgICAgICAgICAg
KDE8PDApCgojZGVmaW5lIExDRF9IT1JaVElNSU5HICAgICAgICAgICAgIChBVTExMDBfTENEX0JB
U0UgKyAweEMpCiAgI2RlZmluZSBMQ0RfSE9SWlRJTUlOR19ITjJfQklUICAgMjQKICAjZGVmaW5l
IExDRF9IT1JaVElNSU5HX0hOMl9NQVNLICAoMHhGRiA8PCBMQ0RfSE9SWlRJTUlOR19ITjJfQklU
KQogICNkZWZpbmUgTENEX0hPUlpUSU1JTkdfSE4yX04oTikgICgoKChOKS0xKSA8PCBMQ0RfSE9S
WlRJTUlOR19ITjJfQklUKSAmIExDRF9IT1JaVElNSU5HX0hOMl9NQVNLKQogICNkZWZpbmUgTENE
X0hPUlpUSU1JTkdfSE4xX0JJVCAgIDE2CiAgI2RlZmluZSBMQ0RfSE9SWlRJTUlOR19ITjFfTUFT
SyAgKDB4RkYgPDwgTENEX0hPUlpUSU1JTkdfSE4xX0JJVCkKICAjZGVmaW5lIExDRF9IT1JaVElN
SU5HX0hOMV9OKE4pICAoKCgoTiktMSkgPDwgTENEX0hPUlpUSU1JTkdfSE4xX0JJVCkgJiBMQ0Rf
SE9SWlRJTUlOR19ITjFfTUFTSykKICAjZGVmaW5lIExDRF9IT1JaVElNSU5HX0hQV19CSVQgICAx
MAogICNkZWZpbmUgTENEX0hPUlpUSU1JTkdfSFBXX01BU0sgICgweDNGIDw8IExDRF9IT1JaVElN
SU5HX0hQV19CSVQpCiAgI2RlZmluZSBMQ0RfSE9SWlRJTUlOR19IUFdfTihOKSAgKCgoKE4pLTEp
IDw8IExDRF9IT1JaVElNSU5HX0hQV19CSVQpICYgTENEX0hPUlpUSU1JTkdfSFBXX01BU0spCiAg
I2RlZmluZSBMQ0RfSE9SWlRJTUlOR19QUExfQklUICAgMAogICNkZWZpbmUgTENEX0hPUlpUSU1J
TkdfUFBMX01BU0sgICgweDNGRiA8PCBMQ0RfSE9SWlRJTUlOR19QUExfQklUKQogICNkZWZpbmUg
TENEX0hPUlpUSU1JTkdfUFBMX04oTikgICgoKChOKS0xKSA8PCBMQ0RfSE9SWlRJTUlOR19QUExf
QklUKSAmIExDRF9IT1JaVElNSU5HX1BQTF9NQVNLKQoKI2RlZmluZSBMQ0RfVkVSVFRJTUlORyAg
ICAgICAgICAgICAoQVUxMTAwX0xDRF9CQVNFICsgMHgxMCkKICAjZGVmaW5lIExDRF9WRVJUVElN
SU5HX1ZOMl9CSVQgICAyNAogICNkZWZpbmUgTENEX1ZFUlRUSU1JTkdfVk4yX01BU0sgICgweEZG
IDw8IExDRF9WRVJUVElNSU5HX1ZOMl9CSVQpCiAgI2RlZmluZSBMQ0RfVkVSVFRJTUlOR19WTjJf
TihOKSAgKCgoKE4pLTEpIDw8IExDRF9WRVJUVElNSU5HX1ZOMl9CSVQpICYgTENEX1ZFUlRUSU1J
TkdfVk4yX01BU0spCiAgI2RlZmluZSBMQ0RfVkVSVFRJTUlOR19WTjFfQklUICAgMTYKICAjZGVm
aW5lIExDRF9WRVJUVElNSU5HX1ZOMV9NQVNLICAoMHhGRiA8PCBMQ0RfVkVSVFRJTUlOR19WTjFf
QklUKQogICNkZWZpbmUgTENEX1ZFUlRUSU1JTkdfVk4xX04oTikgICgoKChOKS0xKSA8PCBMQ0Rf
VkVSVFRJTUlOR19WTjFfQklUKSAmIExDRF9WRVJUVElNSU5HX1ZOMV9NQVNLKQogICNkZWZpbmUg
TENEX1ZFUlRUSU1JTkdfVlBXX0JJVCAgIDEwCiAgI2RlZmluZSBMQ0RfVkVSVFRJTUlOR19WUFdf
TUFTSyAgKDB4M0YgPDwgTENEX1ZFUlRUSU1JTkdfVlBXX0JJVCkKICAjZGVmaW5lIExDRF9WRVJU
VElNSU5HX1ZQV19OKE4pICAoKCgoTiktMSkgPDwgTENEX1ZFUlRUSU1JTkdfVlBXX0JJVCkgJiBM
Q0RfVkVSVFRJTUlOR19WUFdfTUFTSykKICAjZGVmaW5lIExDRF9WRVJUVElNSU5HX0xQUF9CSVQg
ICAwCiAgI2RlZmluZSBMQ0RfVkVSVFRJTUlOR19MUFBfTUFTSyAgKDB4M0ZGIDw8IExDRF9WRVJU
VElNSU5HX0xQUF9CSVQpCiAgI2RlZmluZSBMQ0RfVkVSVFRJTUlOR19MUFBfTihOKSAgKCgoKE4p
LTEpIDw8IExDRF9WRVJUVElNSU5HX0xQUF9CSVQpICYgTENEX1ZFUlRUSU1JTkdfTFBQX01BU0sp
CgojZGVmaW5lIExDRF9DTEtDT05UUk9MICAgICAgICAgICAgIChBVTExMDBfTENEX0JBU0UgKyAw
eDE0KQogICNkZWZpbmUgTENEX0NMS0NPTlRST0xfSUIgICAgICAgICgxPDwxOCkKICAjZGVmaW5l
IExDRF9DTEtDT05UUk9MX0lDICAgICAgICAoMTw8MTcpCiAgI2RlZmluZSBMQ0RfQ0xLQ09OVFJP
TF9JSCAgICAgICAgKDE8PDE2KQogICNkZWZpbmUgTENEX0NMS0NPTlRST0xfSVYgICAgICAgICgx
PDwxNSkKICAjZGVmaW5lIExDRF9DTEtDT05UUk9MX0JGX0JJVCAgICAxMAogICNkZWZpbmUgTENE
X0NMS0NPTlRST0xfQkZfTUFTSyAgICgweDFGIDw8IExDRF9DTEtDT05UUk9MX0JGX0JJVCkKICAj
ZGVmaW5lIExDRF9DTEtDT05UUk9MX0JGX04oTikgICAoKCgoTiktMSkgPDwgTENEX0NMS0NPTlRS
T0xfQkZfQklUKSAmIExDRF9DTEtDT05UUk9MX0JGX01BU0spCiAgI2RlZmluZSBMQ0RfQ0xLQ09O
VFJPTF9QQ0RfQklUICAgMAogICNkZWZpbmUgTENEX0NMS0NPTlRST0xfUENEX01BU0sgICgweDNG
RiA8PCBMQ0RfQ0xLQ09OVFJPTF9QQ0RfQklUKQogICNkZWZpbmUgTENEX0NMS0NPTlRST0xfUENE
X04oTikgICgoKE4pIDw8IExDRF9DTEtDT05UUk9MX1BDRF9CSVQpICYgTENEX0NMS0NPTlRST0xf
UENEX01BU0spCgojZGVmaW5lIExDRF9ETUFBRERSMCAgICAgICAgICAgICAgIChBVTExMDBfTENE
X0JBU0UgKyAweDE4KQojZGVmaW5lIExDRF9ETUFBRERSMSAgICAgICAgICAgICAgIChBVTExMDBf
TENEX0JBU0UgKyAweDFDKQogICNkZWZpbmUgTENEX0RNQV9TQV9CSVQgICAgICAgICAgIDUKICAj
ZGVmaW5lIExDRF9ETUFfU0FfTUFTSyAgICAgICAgICAoMHg3RkZGRkZGIDw8IExDRF9ETUFfU0Ff
QklUKQogICNkZWZpbmUgTENEX0RNQV9TQV9OKE4pICAgICAgICAgICgoTikgJiBMQ0RfRE1BX1NB
X01BU0spCgojZGVmaW5lIExDRF9XT1JEUyAgICAgICAgICAgICAgICAgIChBVTExMDBfTENEX0JB
U0UgKyAweDIwKQogICNkZWZpbmUgTENEX1dSRF9XUkRTX0JJVCAgICAgICAgIDAKICAjZGVmaW5l
IExDRF9XUkRfV1JEU19NQVNLICAgICAgICAoMHhGRkZGRkZGRiA8PCBMQ0RfV1JEX1dSRFNfQklU
KQogICNkZWZpbmUgTENEX1dSRF9XUkRTX04oTikgICAgICAgICgoKChOKS0xKSA8PCBMQ0RfV1JE
X1dSRFNfQklUKSAmIExDRF9XUkRfV1JEU19NQVNLKQoKI2RlZmluZSBMQ0RfUFdNRElWICAgICAg
ICAgICAgICAgICAoQVUxMTAwX0xDRF9CQVNFICsgMHgyNCkKICAjZGVmaW5lIExDRF9QV01ESVZf
RU4gICAgICAgICAgICAoMTw8MTIpCiAgI2RlZmluZSBMQ0RfUFdNRElWX1BXTURJVl9CSVQgICAg
MAogICNkZWZpbmUgTENEX1BXTURJVl9QV01ESVZfTUFTSyAgICgweEZGRiA8PCBMQ0RfUFdNRElW
X1BXTURJVl9CSVQpCiAgI2RlZmluZSBMQ0RfUFdNRElWX1BXTURJVl9OKE4pICAgKCgoKE4pLTEp
IDw8IExDRF9QV01ESVZfUFdNRElWX0JJVCkgJiBMQ0RfUFdNRElWX1BXTURJVl9NQVNLKQoKI2Rl
ZmluZSBMQ0RfUFdNSEkgICAgICAgICAgICAgICAgICAoQVUxMTAwX0xDRF9CQVNFICsgMHgyOCkK
ICAjZGVmaW5lIExDRF9QV01ISV9QV01ISTFfQklUICAgICAxMgogICNkZWZpbmUgTENEX1BXTUhJ
X1BXTUhJMV9NQVNLICAgICgweEZGRiA8PCBMQ0RfUFdNSElfUFdNSEkxX0JJVCkKICAjZGVmaW5l
IExDRF9QV01ISV9QV01ISTFfTihOKSAgICAoKChOKSA8PCBMQ0RfUFdNSElfUFdNSEkxX0JJVCkg
JiBMQ0RfUFdNSElfUFdNSEkxX01BU0spCiAgI2RlZmluZSBMQ0RfUFdNSElfUFdNSEkwX0JJVCAg
ICAgMAogICNkZWZpbmUgTENEX1BXTUhJX1BXTUhJMF9NQVNLICAgICgweEZGRiA8PCBMQ0RfUFdN
SElfUFdNSEkwX0JJVCkKICAjZGVmaW5lIExDRF9QV01ISV9QV01ISTBfTihOKSAgICAoKChOKSA8
PCBMQ0RfUFdNSElfUFdNSEkwX0JJVCkgJiBMQ0RfUFdNSElfUFdNSEkwX01BU0spCgojZGVmaW5l
IExDRF9QQUxMRVRURUJBU0UgICAgICAgICAgICAgICAgKEFVMTEwMF9MQ0RfQkFTRSArIDB4NDAw
KQogICNkZWZpbmUgTENEX1BBTExFVFRFX01PTk9fTUlfQklUICAgICAgMAogICNkZWZpbmUgTENE
X1BBTExFVFRFX01PTk9fTUlfTUFTSyAgICAgKDB4RiA8PCBMQ0RfUEFMTEVUVEVfTU9OT19NSV9C
SVQpCiAgI2RlZmluZSBMQ0RfUEFMTEVUVEVfTU9OT19NSV9OKE4pICAgICAoKChOKTw8IExDRF9Q
QUxMRVRURV9NT05PX01JX0JJVCkgJiBMQ0RfUEFMTEVUVEVfTU9OT19NSV9NQVNLKQoKICAjZGVm
aW5lIExDRF9QQUxMRVRURV9DT0xPUl9SSV9CSVQgICAgIDgKICAjZGVmaW5lIExDRF9QQUxMRVRU
RV9DT0xPUl9SSV9NQVNLICAgICgweEYgPDwgTENEX1BBTExFVFRFX0NPTE9SX1JJX0JJVCkKICAj
ZGVmaW5lIExDRF9QQUxMRVRURV9DT0xPUl9SSV9OKE4pICAgICgoKE4pPDwgTENEX1BBTExFVFRF
X0NPTE9SX1JJX0JJVCkgJiBMQ0RfUEFMTEVUVEVfQ09MT1JfUklfTUFTSykKICAjZGVmaW5lIExD
RF9QQUxMRVRURV9DT0xPUl9HSV9CSVQgICAgIDQKICAjZGVmaW5lIExDRF9QQUxMRVRURV9DT0xP
Ul9HSV9NQVNLICAgICgweEYgPDwgTENEX1BBTExFVFRFX0NPTE9SX0dJX0JJVCkKICAjZGVmaW5l
IExDRF9QQUxMRVRURV9DT0xPUl9HSV9OKE4pICAgICgoKE4pPDwgTENEX1BBTExFVFRFX0NPTE9S
X0dJX0JJVCkgJiBMQ0RfUEFMTEVUVEVfQ09MT1JfR0lfTUFTSykKICAjZGVmaW5lIExDRF9QQUxM
RVRURV9DT0xPUl9CSV9CSVQgICAgIDAKICAjZGVmaW5lIExDRF9QQUxMRVRURV9DT0xPUl9CSV9N
QVNLICAgICgweEYgPDwgTENEX1BBTExFVFRFX0NPTE9SX0JJX0JJVCkKICAjZGVmaW5lIExDRF9Q
QUxMRVRURV9DT0xPUl9CSV9OKE4pICAgICgoKE4pPDwgTENEX1BBTExFVFRFX0NPTE9SX0JJX0JJ
VCkgJiBMQ0RfUEFMTEVUVEVfQ09MT1JfQklfTUFTSykKCiAgI2RlZmluZSBMQ0RfUEFMTEVUVEVf
VEZUX0RDX0JJVCAgICAgICAwCiAgI2RlZmluZSBMQ0RfUEFMTEVUVEVfVEZUX0RDX01BU0sgICAg
ICAoMHhGRkZGIDw8IExDRF9QQUxMRVRURV9URlRfRENfQklUKQogICNkZWZpbmUgTENEX1BBTExF
VFRFX1RGVF9EQ19OKE4pICAgICAgKCgoTik8PCBMQ0RfUEFMTEVUVEVfVEZUX0RDX0JJVCkgJiBM
Q0RfUEFMTEVUVEVfVEZUX0RDX01BU0spCgovKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCgovKiBMaXN0IG9mIGRlZmF1
bHQgbW9kZXMgZm9yIGEgcmVnaXN0ZXJlZCBwYW5lbC4KICogSWYgeW91IHdhbnQgdG8gdXNlIGdl
bmVyaWMgbW9kZXMsIHNldCBwYW5lbCdzIG1vZGVkYiB0byBOVUxMLgogKi8Kc3RhdGljIHN0cnVj
dCBmYl92aWRlb21vZGUgc2hhcnBfbHEwMzhxNWRyMDFfbW9kZXNbXSA9CnsKCXsKCQlOVUxMLCAw
LCAzMjAsIDI0MCwgS0haMlBJQ09TKDYwMDApLCA2MCwgOCwgMTcsIDUsIDEyLCAxLAoJCTAsIEZC
X1ZNT0RFX05PTklOVEVSTEFDRUQsIDAKCX0sCn07CnN0YXRpYyBzdHJ1Y3QgZmJfdmlkZW9tb2Rl
IHNoYXJwX2xxNjRkMzQzX21vZGVzW10gPQp7Cgl7CgkJIlNSVEIiLCAwLCA2NDAsIDQ4MCwgS0ha
MlBJQ09TKDEyMDAwKSwgOCwgMzgsIDI2LCAzNCwgMzYsIDIsCgkJMCwgRkJfVk1PREVfTk9OSU5U
RVJMQUNFRCwgMAoJfSwKfTsKCi8qIExpc3Qgb2YgcGFuZWxzIGtub3duIHRvIHdvcmsgd2l0aCB0
aGUgQVUxMTAwIExDRCBjb250cm9sbGVyLgogKiBUbyBhZGQgYSBuZXcgcGFuZWwsIGVudGVyIHRo
ZSBzYW1lIHNwZWNpZmljYXRpb25zIGFzIHRoZQogKiBHZW5lcmljX1RGVCBvbmUsIGFuZCBNQUtF
IFNVUkUgdGhhdCBpdCBkb2Vzbid0IGNvbmZsaWN0cyAKICogd2l0aCB0aGUgY29udHJvbGxlciBy
ZXN0cmljdGlvbnMuIFJlc3RyaWN0aW9ucyBhcmU6CiAqCiAqIFNUTiBjb2xvciBwYW5lbHM6IG1h
eF9icHAgPD0gMTIKICogU1ROIG1vbm8gcGFuZWxzOiBtYXhfYnBwIDw9IDQKICogVEZUIHBhbmVs
czogbWF4X2JwcCA8PSAxNgogKiBtYXhfeHJlcyA8PSA4MDAKICogbWF4X3lyZXMgPD0gNjAwCiAq
LwpzdGF0aWMgc3RydWN0IGF1MTEwMGZiX3BhbmVsIGtub3duX2xjZF9wYW5lbHNbXSA9CnsKCS8q
KiogR2VuZXJpYyA2NDB4NDgwIDE2YnBwIFRGVCBMQ0QgKioqLwoJWzBdID0gewoJCS5uYW1lID0g
IkdlbmVyaWNfVEZUIiwKCQkubW9uc3BlY3MgPSB7CgkJCS5tb2RlZGIgPSBOVUxMLAoJCQkubW9k
ZWRiX2xlbiA9IDAsCgkJCS5oZm1pbiA9IDI5MDAwLAoJCQkuaGZtYXggPSAzMDAwMCwKCQkJLnZm
bWluID0gNjAsCgkJCS52Zm1heCA9IDYwLAoJCQkuZGNsa21pbiA9IDEyMDAwMDAwLAoJCQkuZGNs
a21heCA9IDEyMDAwMDAwLAoJCQkuaW5wdXQgPSBGQl9ESVNQX1JHQiwKCQl9LAoJCSAKCQkoIExD
RF9DT05UUk9MX0MKCQl8IExDRF9DT05UUk9MX0RFRkFVTFRfUE8KCQl8IExDRF9DT05UUk9MX1BU
CgkJfCBMQ0RfQ09OVFJPTF9QQyApLAoJCSAKCQkwLAoKCQk2NDAsIDY0MCwgCgkJNDgwLCA0ODAs
IAoJCTE2LAoJfSwKCiAgICAgICAgLyoqKiBQYjExMDAgTENEQSBTaGFycCAzMjB4MjQwIFRGVCBw
YW5lbCAqKiovCglbMV0gPSB7CgkJLm5hbWUgPSAiU2hhcnBfTFEwMzhRNURSMDEiLAoJCS5tb25z
cGVjcyA9IHsKCQkJLm1vZGVkYiAgPSBzaGFycF9scTAzOHE1ZHIwMV9tb2RlcywKCQkJLm1vZGVk
Yl9sZW4gPSBBUlJBWV9TSVpFKHNoYXJwX2xxMDM4cTVkcjAxX21vZGVzKSwKCQkJLmhmbWluICAg
PSAxMjUwMCwKCQkJLmhmbWF4CSA9IDIwMDAwLAoJCQkudmZtaW4JID0gMzgsCgkJCS52Zm1heCAg
ID0gODEsCgkJCS5kY2xrbWluID0gNDUwMDAwMCwKCQkJLmRjbGttYXggPSA2ODAwMDAwLAoJCQku
aW5wdXQgPSBGQl9ESVNQX1JHQiwKCQl9LAoKCQkoIExDRF9DT05UUk9MX0MKCQl8IExDRF9DT05U
Uk9MX0RFRkFVTFRfUE8KCQl8IExDRF9DT05UUk9MX1BUCgkJfCBMQ0RfQ09OVFJPTF9QQyApLAoK
CQkwLAoJCQoJCTMyMCwgMzIwLCAKCQkyNDAsIDI0MCwgCgkJMTYsCgl9LAoKICAgICAgICAvKioq
IFNoYXJwIDY0MHg0ODAgVEZUIHBhbmVsICoqKi8KCVsyXSA9IHsKCQkubmFtZSA9ICJTaGFycF9M
UTY0RDM0MyIsCgkJLm1vbnNwZWNzID0gewoJCQkubW9kZWRiICA9IHNoYXJwX2xxNjRkMzQzX21v
ZGVzLAoJCQkubW9kZWRiX2xlbiA9IEFSUkFZX1NJWkUoc2hhcnBfbHE2NGQzNDNfbW9kZXMpLAoJ
CQkuaGZtaW4gICA9IDIyMjIyLAoJCQkuaGZtYXgJID0gMzE0ODEsCgkJCS52Zm1pbgkgPSA0MCwK
CQkJLnZmbWF4ICAgPSA2MSwKCQkJLmRjbGttaW4gPSA2MDAwMDAwLAoJCQkuZGNsa21heCA9IDI4
MDAwMDAwLAoJCQkuaW5wdXQgPSBGQl9ESVNQX1JHQiwKCQl9LAoKCQkoIExDRF9DT05UUk9MX0MK
CQl8IExDRF9DT05UUk9MX0RFRkFVTFRfUE8KCQl8IExDRF9DT05UUk9MX0NDTwoJCXwgTENEX0NP
TlRST0xfUFQKCQl8IExDRF9DT05UUk9MX1BDICksCgoJCTAsCgkJCgkJNjQwLCA2NDAsIAoJCTQ4
MCwgNDgwLCAKCQkxNiwKCX0sCn07CgovKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCgovKiBJbmxpbmUgaGVscGVycyAq
LwoKI2RlZmluZSBwYW5lbF9pc19kdWFsKHBhbmVsKSAgKHBhbmVsLT5jb250cm9sX2Jhc2UgJiBM
Q0RfQ09OVFJPTF9EUCkKI2RlZmluZSBwYW5lbF9pc19hY3RpdmUocGFuZWwpKHBhbmVsLT5jb250
cm9sX2Jhc2UgJiBMQ0RfQ09OVFJPTF9QVCkKI2RlZmluZSBwYW5lbF9pc19jb2xvcihwYW5lbCkg
KHBhbmVsLT5jb250cm9sX2Jhc2UgJiBMQ0RfQ09OVFJPTF9QQykKI2RlZmluZSBwYW5lbF9zd2Fw
X3JnYihwYW5lbCkgKHBhbmVsLT5jb250cm9sX2Jhc2UgJiBMQ0RfQ09OVFJPTF9DQ08pCgpzdGF0
aWMgaW5saW5lIGludAphdTExMDBmYl9zdGFydF9jb250cm9sbGVyKHN0cnVjdCBhdTExMDBmYl9k
ZXZpY2UgKmZiZGV2KQp7CglyZXR1cm4gZmJkZXYtPmZiX2luZm8uZmJvcHMtPmZiX2JsYW5rKFZF
U0FfTk9fQkxBTktJTkcsICZmYmRldi0+ZmJfaW5mbyk7Cn0KCnN0YXRpYyBpbmxpbmUgaW50CmF1
MTEwMGZiX3N0b3BfY29udHJvbGxlcihzdHJ1Y3QgYXUxMTAwZmJfZGV2aWNlICpmYmRldiwgaW50
IHdhaXQpCnsKCWludCByZXQgPSBmYmRldi0+ZmJfaW5mby5mYm9wcy0+ZmJfYmxhbmsoVkVTQV9Q
T1dFUkRPV04sICZmYmRldi0+ZmJfaW5mbyk7CglpZiAod2FpdCkgewoJCS8qIFdhaXQgZm9yIHRo
ZSBTRCBiaXQgKi8KCQl1MzIgaW50c3RhdHVzOwoJCWRvIHsKCQkJKih2b2xhdGlsZSB1MzIqKSgm
ZmJkZXYtPnJlZ3MtPmxjZF9pbnRzdGF0dXMpOwoJCQlpbnRzdGF0dXMgPSAqKHZvbGF0aWxlIHUz
MiopKCZmYmRldi0+cmVncy0+bGNkX2ludHN0YXR1cyk7CgoJCX0gd2hpbGUgKCEoaW50c3RhdHVz
ICYgTENEX0lOVF9TRCkpOwoJfQoJcmV0dXJuIHJldDsKfQoKI2VuZGlmIC8qIF9BVTExMDBMQ0Rf
SCAqLwo=

--------------Boundary-00=_ICQ3JWJBDIHX28K5NGD6--

From macro@mips.com Thu Dec  2 18:04:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 18:04:10 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:47881 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225375AbULBSEE>;
	Thu, 2 Dec 2004 18:04:04 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1CZvQV-00088z-00; Thu, 02 Dec 2004 18:11:35 +0000
Received: from perivale.mips.com ([192.168.192.200])
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1CZvIl-0001qz-00; Thu, 02 Dec 2004 18:03:35 +0000
Received: from macro (helo=localhost)
	by perivale.mips.com with local-esmtp (Exim 3.36 #1 (Debian))
	id 1CZvIl-0004c2-00; Thu, 02 Dec 2004 18:03:35 +0000
Date: Thu, 2 Dec 2004 18:03:35 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@mips.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org,
	"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: [PATCH] Label misplacement on an XTLB refill handler split
Message-ID: <Pine.LNX.4.61.0412021746590.15065@perivale.mips.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-3.277, required 4, AWL,
	BAYES_00, SPAMMYSPELL)
Return-Path: <macro@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: 6549
X-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@mips.com
Precedence: bulk
X-list: linux-mips

Thiemo,

 The XTLB refill handler splitter misplaces labels associated with an
instruction that gets placed in the branch delay slot of the splitting 
branch.  Here's an example:

tlb-handler.img:     file format binary

Disassembly of section .data:

0000000000000000 <.data>:
   0:	001bd83c 	dsll32	k1,k1,0x0
   4:	035bd02f 	dsubu	k0,k0,k1
   8:	3c1b803a 	lui	k1,0x803a
   c:	10000026 	b	0xa8
  10:	677b4000 	daddiu	k1,k1,16384
	...
  80:	403a4000 	dmfc0	k0,c0_badvaddr
  84:	403b5000 	dmfc0	k1,c0_entryhi
  88:	035bd026 	xor	k0,k0,k1
  8c:	001ad37a 	dsrl	k0,k0,0xd
  90:	17400018 	bnez	k0,0xf4
  94:	403a4000 	dmfc0	k0,c0_badvaddr
  98:	07400018 	bltz	k0,0xfc
  9c:	403b2000 	dmfc0	k1,c0_context
  a0:	001bddfb 	dsra	k1,k1,0x17
  a4:	df7b0000 	ld	k1,0(k1)
  a8:	001ad73a 	dsrl	k0,k0,0x1c
  ac:	335a1ff8 	andi	k0,k0,0x1ff8
  b0:	037ad82d 	daddu	k1,k1,k0
  b4:	403a4000 	dmfc0	k0,c0_badvaddr
  b8:	df7b0000 	ld	k1,0(k1)
  bc:	001ad4ba 	dsrl	k0,k0,0x12
  c0:	335a0ff8 	andi	k0,k0,0xff8
  c4:	037ad82d 	daddu	k1,k1,k0
  c8:	403aa000 	dmfc0	k0,c0_xcontext
  cc:	df7b0000 	ld	k1,0(k1)
  d0:	335a0ff0 	andi	k0,k0,0xff0
  d4:	037ad82d 	daddu	k1,k1,k0
  d8:	df7a0000 	ld	k0,0(k1)
  dc:	df7b0008 	ld	k1,8(k1)
  e0:	001ad1ba 	dsrl	k0,k0,0x6
  e4:	409a1000 	mtc0	k0,c0_entrylo0
  e8:	001bd9ba 	dsrl	k1,k1,0x6
  ec:	409b1800 	mtc0	k1,c0_entrylo1
  f0:	42000006 	tlbwr
  f4:	42000018 	eret
  f8:	1000ffc1 	b	0x0
  fc:	3c1bc000 	lui	k1,0xc000

I've fixed it by separating the label mover (and the reloc mover, for 
consistency) and using it to fix up relevant labels.  I'll apply it if 
it's OK with you.

  Maciej

patch-mips-2.6.10-rc2-20041124-mips-tlb-label-0
diff -up --recursive --new-file linux-mips-2.6.10-rc2-20041124.macro/arch/mips/mm/tlbex.c linux-mips-2.6.10-rc2-20041124/arch/mips/mm/tlbex.c
--- linux-mips-2.6.10-rc2-20041124.macro/arch/mips/mm/tlbex.c	2004-11-24 21:37:38.000000000 +0000
+++ linux-mips-2.6.10-rc2-20041124/arch/mips/mm/tlbex.c	2004-12-02 17:41:11.000000000 +0000
@@ -550,22 +550,33 @@ static __init void resolve_relocs(struct
 				__resolve_relocs(rel, l);
 }
 
-static __init void copy_handler(struct reloc *rel, struct label *lab,
-				u32 *first, u32 *end, u32* target)
+static __init void move_relocs(struct reloc *rel, u32 *first, u32 *end,
+			       long off)
 {
-	long off = (long)(target - first);
-
-	memcpy(target, first, (end - first) * sizeof(u32));
-
 	for (; rel->lab != label_invalid; rel++)
 		if (rel->addr >= first && rel->addr < end)
 			rel->addr += off;
+}
 
+static __init void move_labels(struct label *lab, u32 *first, u32 *end,
+			       long off)
+{
 	for (; lab->lab != label_invalid; lab++)
 		if (lab->addr >= first && lab->addr < end)
 			lab->addr += off;
 }
 
+static __init void copy_handler(struct reloc *rel, struct label *lab,
+				u32 *first, u32 *end, u32 *target)
+{
+	long off = (long)(target - first);
+
+	memcpy(target, first, (end - first) * sizeof(u32));
+
+	move_relocs(rel, first, end, off);
+	move_labels(lab, first, end, off);
+}
+
 static __init int __attribute__((unused)) insn_has_bdelay(struct reloc *rel,
 							  u32 *addr)
 {
@@ -1110,6 +1121,7 @@ static void __init build_r4000_tlb_refil
 			i_nop(&f);
 		else {
 			copy_handler(relocs, labels, split, split + 1, f);
+			move_labels(labels, f, f + 1, -1);
 			f++;
 			split++;
 		}

From ica2_ts@csv.ica.uni-stuttgart.de Thu Dec  2 18:49:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 18:49:38 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:62570
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225375AbULBSte>; Thu, 2 Dec 2004 18:49:34 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CZw1D-0001hB-00; Thu, 02 Dec 2004 19:49:31 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CZw1C-0001SR-00; Thu, 02 Dec 2004 19:49:30 +0100
Date: Thu, 2 Dec 2004 19:49:30 +0100
To: "Maciej W. Rozycki" <macro@mips.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Label misplacement on an XTLB refill handler split
Message-ID: <20041202184930.GB3225@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.LNX.4.61.0412021746590.15065@perivale.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0412021746590.15065@perivale.mips.com>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6550
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
> Thiemo,
> 
>  The XTLB refill handler splitter misplaces labels associated with an
> instruction that gets placed in the branch delay slot of the splitting 
> branch.  Here's an example:
[snip]
> I've fixed it by separating the label mover (and the reloc mover, for 
> consistency) and using it to fix up relevant labels.  I'll apply it if 
> it's OK with you.
[snip]
> @@ -1110,6 +1121,7 @@ static void __init build_r4000_tlb_refil
>  			i_nop(&f);
>  		else {
>  			copy_handler(relocs, labels, split, split + 1, f);
> +			move_labels(labels, f, f + 1, -1);
>  			f++;
>  			split++;
>  		}

Thanks for catching this. Please apply.


Thiemo

From mlachwani@mvista.com Thu Dec  2 20:18:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 20:18:43 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:1276 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225388AbULBUSh>; Thu, 2 Dec 2004 20:18:37 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id AC9DC1869C; Thu,  2 Dec 2004 12:18:35 -0800 (PST)
Message-ID: <41AF789B.3030303@mvista.com>
Date: Thu, 02 Dec 2004 12:18:35 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Broadcom SWARM IDE in 2.6
References: <20041130230022.GA17202@prometheus.mvista.com> <41AE9390.80705@realitydiluted.com>
In-Reply-To: <41AE9390.80705@realitydiluted.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6551
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

Hi Steve,

"ide_init_default_irq" is defined in include/linux/ide.h and in
include/asm-mips/mach-generic/ide.h.

include/asm-mips/mach-generic/ide.h and include/asm-i386/ide.h are 
replicas. So, this compiler warning should appear on other platforms as 
well.

I have sent an email out to Jeff Garzik to understand why 
"ide_init_default_irq" is redefined

Thanks
Manish Lachwani

Steven J. Hill wrote:
> Manish Lachwani wrote:
> 
>>
>> I had sent an incomplete patch before. Please try out this new patch, 
>> attached.
>> Let me know if it works
>>
> Manish,
> 
> This patch worked, however you need to fix a compiler warning before I am
> willing to commit it. Please get rid of the warning shown below and submit
> a new patch. Thanks!
> 
> -Steve
> 
> *******************
> 
> CC      drivers/ide/ide-generic.o
> In file included from drivers/ide/ide-generic.c:13:
> include/linux/ide.h:277:1: warning: "ide_init_default_irq" redefined
> In file included from include/asm/ide.h:11,
>                  from include/linux/ide.h:271,
>                  from drivers/ide/ide-generic.c:13:
> include/asm-mips/mach-generic/ide.h:64:1: warning: this is the location 
> of the previous definition



From ralf@linux-mips.org Thu Dec  2 20:32:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 20:32:08 +0000 (GMT)
Received: from p508B7960.dip.t-dialin.net ([IPv6:::ffff:80.139.121.96]:20115
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225388AbULBUcE>; Thu, 2 Dec 2004 20:32:04 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB2KU0rI003973;
	Thu, 2 Dec 2004 21:30:00 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB2KU0h9003972;
	Thu, 2 Dec 2004 21:30:00 +0100
Date: Thu, 2 Dec 2004 21:30:00 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@mips.com>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org,
	"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH] Label misplacement on an XTLB refill handler split
Message-ID: <20041202203000.GB3459@linux-mips.org>
References: <Pine.LNX.4.61.0412021746590.15065@perivale.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0412021746590.15065@perivale.mips.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6552
X-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, Dec 02, 2004 at 06:03:35PM +0000, Maciej W. Rozycki wrote:

>   f4:	42000018 	eret

Not directly related but seeing the eret here reminded me that we're still
not handling the R4000PC/SC v2.2/v3.0 erratum 6 where returning from a
cache error exception handler to the eret instruction of another exception
handler that was just about to return to user mode was not being
treated properly.

In case you care ;-)

  Ralf

From maillist@jg555.com Thu Dec  2 23:04:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Dec 2004 23:04:47 +0000 (GMT)
Received: from dsl-64-30-195-78.lcinet.net ([IPv6:::ffff:64.30.195.78]:64482
	"EHLO jg555.com") by linux-mips.org with ESMTP id <S8225401AbULBXEm>;
	Thu, 2 Dec 2004 23:04:42 +0000
Received: from [172.16.0.150] (softdnserr [::ffff:172.16.0.150])
  (AUTH: PLAIN jim, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
  by jg555.com with esmtp; Thu, 02 Dec 2004 15:02:05 -0800
  id 0002004F.41AF9EED.00006C71
Message-ID: <41AF9F84.6060800@jg555.com>
Date: Thu, 02 Dec 2004 15:04:36 -0800
From: Jim Gifford <maillist@jg555.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: LFS for RaQ2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <maillist@jg555.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: 6553
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maillist@jg555.com
Precedence: bulk
X-list: linux-mips

I have been following information provided on this list for the last few 
weeks. I am one of the editors for Linux From Scratch(LFS)  and I have 
decided to take on getting LFS working on the Cobalt RaQ2 servers. I 
have been sucessful. I would appreciate any feedback from my peers here 
in the MIPS list. I really appreciate what you have done here.

It follows all the normal LFS guidelines, which means yes, you do have 
to have a working distro, before you can create an LFS system. I have 
had luck with both the Debian and Gentoo Cobalt builds to create a 
working LFS system.

Here is the link
http://documents.jg555.com/lfs-raq2/


-- 
----
Jim Gifford
maillist@jg555.com


From brg@dgate.org Fri Dec  3 00:22:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Dec 2004 00:22:15 +0000 (GMT)
Received: from sccimhc92.asp.att.net ([IPv6:::ffff:63.240.76.166]:28103 "EHLO
	sccimhc92.asp.att.net") by linux-mips.org with ESMTP
	id <S8225409AbULCAWK>; Fri, 3 Dec 2004 00:22:10 +0000
Received: from sartre.dgate.org (12-221-104-195.client.insightbb.com[12.221.104.195])
          by sccimhc92.asp.att.net (sccimhc92) with ESMTP
          id <20041203002204i92002blhue>; Fri, 3 Dec 2004 00:22:04 +0000
Received: from brg by sartre.dgate.ORG with local (Exim 3.36 #1 (Debian))
	id 1Ca1D2-00079J-00
	for <linux-mips@linux-mips.org>; Thu, 02 Dec 2004 18:22:04 -0600
Date: Thu, 2 Dec 2004 18:22:04 -0600
From: "Brian R. Gaeke" <brg@dgate.org>
To: linux-mips@linux-mips.org
Subject: drivers/tc patch for DS5000/200
Message-ID: <20041203002203.GB26830@sartre.insightbb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.5i
Return-Path: <brg@dgate.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: 6554
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brg@dgate.org
Precedence: bulk
X-list: linux-mips


Hi linux-mips list,

First, I want to say, Linux/MIPS is great stuff - thanks for all your
hard work, folks!

Now, it is my understanding that, having a pre-REX PROM, the DECstation
5000/200 would not be able to successfully execute the REX calls
(rex_gettcinfo(), rex_slot_address()) in drivers/tc/tc.c.  Therefore,
I have found it necessary to use a patched kernel in my efforts to boot
Linux on VMIPS (http://www.dgate.org/vmips), which has lately gained some
(limited) DECstation 5000/200 emulation capabilities.

If you find this patch useful, you're quite welcome to it.  I'm also
interested in hearing from anyone who has access to a 5000/200 who can
tell me whether I'm right or wrong, as I only have old manuals and
header files to work from.

-Brian Gaeke

-- 
Brian R. Gaeke, brg at dgate.org -- GnuPG encrypted mail gleefully accepted

Index: tc.c
===================================================================
RCS file: /home/cvs/linux/drivers/tc/tc.c,v
retrieving revision 1.7.2.8
diff -u -a -d -p -r1.7.2.8 tc.c
--- tc.c	11 Aug 2003 11:52:38 -0000	1.7.2.8
+++ tc.c	3 Dec 2004 00:14:56 -0000
@@ -32,6 +32,7 @@ MODULE_LICENSE("GPL");
 slot_info tc_bus[MAX_SLOT];
 static int num_tcslots;
 static tcinfo *info;
+static tcinfo ds5000_200_info;
 
 unsigned long system_base;
 
@@ -196,8 +197,18 @@ void __init tc_init(void)
 		tc_bus[i].flags = FREE;
 	}
 
-	info = (tcinfo *) rex_gettcinfo();
-	slot0addr = (unsigned long)KSEG1ADDR(rex_slot_address(0));
+	if (mips_machtype != MACH_DS5000_200) {
+		info = (tcinfo *) rex_gettcinfo();
+		slot0addr = (unsigned long)KSEG1ADDR(rex_slot_address(0));
+	} else {
+		/* Hardcode these, because the old PROM lacks gettcinfo(). */
+		ds5000_200_info.revision = 0;
+		ds5000_200_info.parity = 0;
+		ds5000_200_info.clk_period = 40;
+		ds5000_200_info.slot_size = 4;
+		info = &ds5000_200_info;
+		slot0addr = 0xbe000000;
+	}
 
 	switch (mips_machtype) {
 	case MACH_DS5000_200:

From ddaney@avtrex.com Fri Dec  3 03:14:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Dec 2004 03:14:27 +0000 (GMT)
Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:42811
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8225410AbULCDOV>;
	Fri, 3 Dec 2004 03:14:21 +0000
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 2 Dec 2004 19:14:14 -0800
Message-ID: <41AFDA18.2010906@avtrex.com>
Date: Thu, 02 Dec 2004 19:14:32 -0800
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: [Patch] make 2.4 compile with GCC-3.4.3...
Content-Type: multipart/mixed;
 boundary="------------090103050205020004030400"
X-OriginalArrivalTime: 03 Dec 2004 03:14:14.0239 (UTC) FILETIME=[2A9F7EF0:01C4D8E6]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6555
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

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

I just upgraded to the most recent 2.4.29-pre1 sources from the CVS archive
 with the intent of being able to compile with gcc-3.4.3.

It turns out that the compiler is splitting:

 save_static_function(sys_fork);
 static_unused int _sys_fork(struct pt_regs regs)

The result being an unusable kernel.

I think that this issue has been discussed before, but I couldn't find the
solution in the mail group.  So I applied this small hack.  The
modifications to syscall.c and signal.c may not be necessary, but I
borrowed them from the 2.6 tree in hopes of fixing the problem and then
moved to the Makefile change.

It may be that only the Makefile change is necessary (I suspect so), but I
have not tried it alone.

The CVS versions in the diff are from my local cvs and do not correspond to
the linux-mips.org CVS.

David Daney.

--------------090103050205020004030400
Content-Type: text/plain;
 name="uat.d"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="uat.d"

Index: kernel/Makefile
===================================================================
RCS file: /linux/linux/arch/mips/kernel/Makefile,v
retrieving revision 1.2
diff -c -p -r1.2 Makefile
*** kernel/Makefile	2 Dec 2004 19:50:05 -0000	1.2
--- kernel/Makefile	3 Dec 2004 03:00:44 -0000
*************** obj-y		+= branch.o cpu-probe.o irq.o pro
*** 18,23 ****
--- 18,27 ----
  		   traps.o ptrace.o reset.o semaphore.o setup.o syscall.o \
  		   sysmips.o ipc.o scall_o32.o time.o unaligned.o
  
+ check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
+ 
+ syscall.o signal.o : override CFLAGS += $(call check_gcc, -fno-unit-at-a-time,)
+ 
  obj-$(CONFIG_MODULES)		+= mips_ksyms.o
  
  obj-$(CONFIG_CPU_R3000)		+= r2300_fpu.o r2300_switch.o
Index: kernel/signal.c
===================================================================
RCS file: /linux/linux/arch/mips/kernel/signal.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 signal.c
*** kernel/signal.c	1 Dec 2004 21:50:39 -0000	1.1.1.2
--- kernel/signal.c	3 Dec 2004 03:00:44 -0000
***************
*** 18,23 ****
--- 18,24 ----
  #include <linux/errno.h>
  #include <linux/wait.h>
  #include <linux/unistd.h>
+ #include <linux/compiler.h>
  
  #include <asm/asm.h>
  #include <asm/bitops.h>
*************** int copy_siginfo_to_user(siginfo_t *to, 
*** 76,82 ****
   * Atomically swap in the new signal mask, and wait for a signal.
   */
  save_static_function(sys_sigsuspend);
! static_unused int _sys_sigsuspend(struct pt_regs regs)
  {
  	sigset_t *uset, saveset, newset;
  
--- 77,84 ----
   * Atomically swap in the new signal mask, and wait for a signal.
   */
  save_static_function(sys_sigsuspend);
! __attribute_used__ static int
! _sys_sigsuspend(struct pt_regs regs)
  {
  	sigset_t *uset, saveset, newset;
  
*************** static_unused int _sys_sigsuspend(struct
*** 102,108 ****
  }
  
  save_static_function(sys_rt_sigsuspend);
! static_unused int _sys_rt_sigsuspend(struct pt_regs regs)
  {
  	sigset_t *unewset, saveset, newset;
          size_t sigsetsize;
--- 104,111 ----
  }
  
  save_static_function(sys_rt_sigsuspend);
! __attribute_used__ static int
! _sys_rt_sigsuspend(struct pt_regs regs)
  {
  	sigset_t *unewset, saveset, newset;
          size_t sigsetsize;
Index: kernel/syscall.c
===================================================================
RCS file: /linux/linux/arch/mips/kernel/syscall.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 syscall.c
*** kernel/syscall.c	1 Dec 2004 21:50:39 -0000	1.1.1.2
--- kernel/syscall.c	3 Dec 2004 03:00:44 -0000
***************
*** 25,30 ****
--- 25,31 ----
  #include <linux/slab.h>
  #include <linux/utsname.h>
  #include <linux/unistd.h>
+ #include <linux/compiler.h>
  #include <asm/branch.h>
  #include <asm/offset.h>
  #include <asm/ptrace.h>
*************** sys_mmap2(unsigned long addr, unsigned l
*** 158,164 ****
  }
  
  save_static_function(sys_fork);
! static_unused int _sys_fork(struct pt_regs regs)
  {
  	int res;
  
--- 159,166 ----
  }
  
  save_static_function(sys_fork);
! __attribute_used__ static int
! _sys_fork(struct pt_regs regs)
  {
  	int res;
  
*************** static_unused int _sys_fork(struct pt_re
*** 168,174 ****
  
  
  save_static_function(sys_clone);
! static_unused int _sys_clone(struct pt_regs regs)
  {
  	unsigned long clone_flags;
  	unsigned long newsp;
--- 170,177 ----
  
  
  save_static_function(sys_clone);
! __attribute_used__ static int
! _sys_clone(struct pt_regs regs)
  {
  	unsigned long clone_flags;
  	unsigned long newsp;

--------------090103050205020004030400--


From macro@linux-mips.org Fri Dec  3 03:33:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Dec 2004 03:33:06 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:16393 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225436AbULCDdB>; Fri, 3 Dec 2004 03:33:01 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id A864EF6DA8; Fri,  3 Dec 2004 04:27:00 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 18984-03; Fri,  3 Dec 2004 04:27:00 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 709C0F6108; Fri,  3 Dec 2004 03:46:45 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iB32kOEm017301;
	Fri, 3 Dec 2004 03:46:39 +0100
Date: Fri, 3 Dec 2004 02:46:22 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: "Brian R. Gaeke" <brg@dgate.org>
Cc: linux-mips@linux-mips.org
Subject: Re: drivers/tc patch for DS5000/200
In-Reply-To: <20041203002203.GB26830@sartre.insightbb.com>
Message-ID: <Pine.LNX.4.58L.0412030150400.23692@blysk.ds.pg.gda.pl>
References: <20041203002203.GB26830@sartre.insightbb.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/614/Wed Dec  1 16:44:43 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6556
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, 2 Dec 2004, Brian R. Gaeke wrote:

> Now, it is my understanding that, having a pre-REX PROM, the DECstation
> 5000/200 would not be able to successfully execute the REX calls
> (rex_gettcinfo(), rex_slot_address()) in drivers/tc/tc.c.  Therefore,
> I have found it necessary to use a patched kernel in my efforts to boot
> Linux on VMIPS (http://www.dgate.org/vmips), which has lately gained some
> (limited) DECstation 5000/200 emulation capabilities.

 They've got it wrong.  While there were a few DECstation 5000/200 systems
around 1990 that were shipped with pre-REX firmware, they were soon
updated to REX fimware under service contracts.  I'm inclined to believe
there is no /200 system with pre-REX firmware in existence anymore.  In 
particular there are no entries for these firmware versions on the NetBSD 
PROM list -- the oldest one reported is 5.3c which is already 
REX-compliant.

> If you find this patch useful, you're quite welcome to it.  I'm also
> interested in hearing from anyone who has access to a 5000/200 who can
> tell me whether I'm right or wrong, as I only have old manuals and
> header files to work from.

 Real /200 systems work more or less correctly with Linux 2.4.  A port of
2.6 hasn't really started yet -- some drivers are broken.  The /200 is one
of the best documented DECstations.

  Maciej

From ica2_ts@csv.ica.uni-stuttgart.de Fri Dec  3 04:55:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Dec 2004 04:56:11 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:52338
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224988AbULCEz7>; Fri, 3 Dec 2004 04:55:59 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1Ca5U5-0006xP-00; Fri, 03 Dec 2004 05:55:57 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1Ca5U4-0003GD-00; Fri, 03 Dec 2004 05:55:56 +0100
Date: Fri, 3 Dec 2004 05:55:56 +0100
To: David Daney <ddaney@avtrex.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [Patch] make 2.4 compile with GCC-3.4.3...
Message-ID: <20041203045556.GB8714@rembrandt.csv.ica.uni-stuttgart.de>
References: <41AFDA18.2010906@avtrex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41AFDA18.2010906@avtrex.com>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6557
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

David Daney wrote:
[snip]
> *** kernel/Makefile	2 Dec 2004 19:50:05 -0000	1.2
> --- kernel/Makefile	3 Dec 2004 03:00:44 -0000
> *************** obj-y		+= branch.o cpu-probe.o irq.o pro
> *** 18,23 ****
> --- 18,27 ----
>   		   traps.o ptrace.o reset.o semaphore.o setup.o syscall.o \
>   		   sysmips.o ipc.o scall_o32.o time.o unaligned.o
>   
> + check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
> + 
> + syscall.o signal.o : override CFLAGS += $(call check_gcc, -fno-unit-at-a-time,)

What difference does this cause?

[snip]
> --- 77,84 ----
>    * Atomically swap in the new signal mask, and wait for a signal.
>    */
>   save_static_function(sys_sigsuspend);
> ! __attribute_used__ static int
> ! _sys_sigsuspend(struct pt_regs regs)

These should also use "noinline", like 2.6.


Thiemo

From ddaney@avtrex.com Fri Dec  3 06:20:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Dec 2004 06:20:52 +0000 (GMT)
Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:59492
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8224989AbULCGUn>;
	Fri, 3 Dec 2004 06:20:43 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Subject: RE: [Patch] make 2.4 compile with GCC-3.4.3...
Date: Thu, 2 Dec 2004 22:20:35 -0800
Message-ID: <69397FFCADEFD94F8D5A0FC0FDBCBBDEF4FA@avtrex-server.hq.avtrex.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Patch] make 2.4 compile with GCC-3.4.3...
Thread-Index: AcTY9GF1P2Gkgu4tQBCZOA+wwGQoOwACgaBK
From: "David Daney" <ddaney@avtrex.com>
To: "Thiemo Seufer" <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: <linux-mips@linux-mips.org>
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6558
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

VGhpZW1vIFNldWZlciB3cm90ZToNCj5EYXZpZCBEYW5leSB3cm90ZToNCj5bc25pcF0NCj4+ICoq
KiBrZXJuZWwvTWFrZWZpbGUgICAyIERlYyAyMDA0IDE5OjUwOjA1IC0wMDAwICAgICAgIDEuMg0K
Pj4gLS0tIGtlcm5lbC9NYWtlZmlsZSAgIDMgRGVjIDIwMDQgMDM6MDA6NDQgLTAwMDANCj4+ICoq
KioqKioqKioqKioqKiBvYmoteSAgICAgICAgICs9IGJyYW5jaC5vIGNwdS1wcm9iZS5vIGlycS5v
IHBybw0KPj4gKioqIDE4LDIzICoqKioNCj4+IC0tLSAxOCwyNyAtLS0tDQo+PiAgICAgICAgICAg
ICAgICAgIHRyYXBzLm8gcHRyYWNlLm8gcmVzZXQubyBzZW1hcGhvcmUubyBzZXR1cC5vIHN5c2Nh
bGwubyBcDQo+PiAgICAgICAgICAgICAgICAgIHN5c21pcHMubyBpcGMubyBzY2FsbF9vMzIubyB0
aW1lLm8gdW5hbGlnbmVkLm8NCj4+ICANCj4+ICsgY2hlY2tfZ2NjID0gJChzaGVsbCBpZiAkKEND
KSAkKDEpIC1TIC1vIC9kZXYvbnVsbCAteGMgL2Rldi9udWxsID4gL2Rldi9udWxsIDI+JjE7IHRo
ZW4gZWNobyAiJCgxKSI7IGVsc2UgZWNobyAiJCgyKSI7IGZpKQ0KPj4gKw0KPj4gKyBzeXNjYWxs
Lm8gc2lnbmFsLm8gOiBvdmVycmlkZSBDRkxBR1MgKz0gJChjYWxsIGNoZWNrX2djYywgLWZuby11
bml0LWF0LWEtdGltZSwpDQo+DQo+V2hhdCBkaWZmZXJlbmNlIGRvZXMgdGhpcyBjYXVzZT8NCg0K
SXQgY2F1c2VzIC1mbm8tdW5pdC1hdC1hLXRpbWUgdG8gYmUgYWRkZWQgdG8gQ0ZMQUdTIHdoZW4g
Y29tcGlsaW5nDQpzeXNjYWxsLmMgYW5kIHNpZ25hbC5jLiAgQWxsIG90aGVyIGZpbGVzIGFyZSBj
b21waWxlZCB3aXRoIHRoZSAibm9ybWFsIiBDRkxBR1MuDQogDQotZm5vLXVuaXQtYXQtYS10aW1l
IHByZXZlbnRzIEdDQyBmcm9tIHJlYXJyYW5naW5nIHRoaW5ncyBpbiBpdHMgb3V0cHV0IHRodXMg
cHJldmVudGluZw0KdGhlIHNhdmVfc3RhdGljX2Z1bmN0aW9uKCkgZnJvbSBiZWluZyBzZXBhcmF0
ZWQgZnJvbSBpdHMgY29tcGFuaW9uLiAgQXMgZmFyIGFzIEkgY291bGQgdGVsbA0Kb25seSBzeXNj
YWxsLmMgYW5kIHNpZ25hbC5jIG5lZWQgdGhpcy4NCiANCk9uZSBzbWFsbCBpc3N1ZSBpcyB0aGF0
IHRoZXNlIHR3byBmaWxlcyBub3cgc2VlbSB0byBnZXQgcmVjb21waWxlZCB3aXRoIGVhY2gNCm1h
a2UgaW52b2NhdGlvbi4gIEJ1dCB0aGF0IGlzIGJldHRlciB0aGFuIGJlaW5nIG1pc2NvbXBpbGVk
Lg0KIA0KSSBhbSBub3Qgc3VyZSBpZiBjaGVja19nY2MgaXMgaW5oZXJpdGVkIGZyb20gdGhlIGhp
Z2hlciBsZXZlbCBtYWtlZmlsZSBzbyBJIHB1dCBpdCBpbiB0aGlzIG9uZQ0KYXMgd2VsbC4gIElm
IHlvdSB0aGluayBpdCBpcyBhIGdvb2QgYXBwcm9hY2ggSSB3aWxsIHRyeSB0byBzaW1wbGlmeSB0
aGUgcGF0Y2ggYSBsaXR0bGUuDQoNCj5bc25pcF0NCj4+IC0tLSA3Nyw4NCAtLS0tDQo+PiAgICAq
IEF0b21pY2FsbHkgc3dhcCBpbiB0aGUgbmV3IHNpZ25hbCBtYXNrLCBhbmQgd2FpdCBmb3IgYSBz
aWduYWwuDQo+PiAgICAqLw0KPj4gICBzYXZlX3N0YXRpY19mdW5jdGlvbihzeXNfc2lnc3VzcGVu
ZCk7DQo+PiAhIF9fYXR0cmlidXRlX3VzZWRfXyBzdGF0aWMgaW50DQo+PiAhIF9zeXNfc2lnc3Vz
cGVuZChzdHJ1Y3QgcHRfcmVncyByZWdzKQ0KPg0KPlRoZXNlIHNob3VsZCBhbHNvIHVzZSAibm9p
bmxpbmUiLCBsaWtlIDIuNi4NCg0Kbm9pbmxpbmUgd2FzIG5vdCBkZWZpbmVkIGZvciBtZSA6KCBz
byBJIHJlbW92ZWQgaXQuICBJdCBzZWVtcyB0aGF0IGluIDIuNiBpdCBpcw0KanVzdCAjZGVmaW5l
ZCB0byBiZSBub3RoaW5nLiAgVGhlIGFsdGVybmF0aXZlIGlzIHRvIGFkZDoNCiANCiNpZm5kZWYg
bm9pbmxpbmUNCiNkZWZpbmUgbm9pbmxpbmUNCiNlbmRpZg0KIA0KdG8gY29tcGlsZXIuaCBhcyBp
cyBkb25lIGluIDIuNg0KIA0KRGF2aWQgRGFuZXkuDQo=

From ica2_ts@csv.ica.uni-stuttgart.de Fri Dec  3 06:40:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Dec 2004 06:40:26 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:44403
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225005AbULCGkV>; Fri, 3 Dec 2004 06:40:21 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1Ca775-0007mH-00; Fri, 03 Dec 2004 07:40:19 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1Ca773-0003bx-00; Fri, 03 Dec 2004 07:40:17 +0100
Date: Fri, 3 Dec 2004 07:40:17 +0100
To: David Daney <ddaney@avtrex.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [Patch] make 2.4 compile with GCC-3.4.3...
Message-ID: <20041203064017.GE8714@rembrandt.csv.ica.uni-stuttgart.de>
References: <69397FFCADEFD94F8D5A0FC0FDBCBBDEF4FA@avtrex-server.hq.avtrex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <69397FFCADEFD94F8D5A0FC0FDBCBBDEF4FA@avtrex-server.hq.avtrex.com>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6559
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

David Daney wrote:
[snip]
> -fno-unit-at-a-time prevents GCC from rearranging things in its output thus preventing
> the save_static_function() from being separated from its companion.  As far as I could tell
> only syscall.c and signal.c need this.

Ah, I missed that. It's probably better to use the same way as in 2.6,
that is, to add a jump at the end of save_static_function().

> noinline was not defined for me :( so I removed it.  It seems that in 2.6 it is
> just #defined to be nothing.  The alternative is to add:
>  
> #ifndef noinline
> #define noinline
> #endif
>  
> to compiler.h as is done in 2.6

Yes, that's the better idea. gcc-4.0 ff may need it.


Thiemo

From dom@mips.com Fri Dec  3 09:08:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Dec 2004 09:08:08 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:48133 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225004AbULCJID>;
	Fri, 3 Dec 2004 09:08:03 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1Ca9XM-00069y-00
	for <linux-mips@linux-mips.org>; Fri, 03 Dec 2004 09:15:36 +0000
Received: from olympia.mips.com ([192.168.192.128] helo=boris)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1Ca9PU-00060x-00; Fri, 03 Dec 2004 09:07:28 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16816.11473.973252.505033@mips.com>
Date: Fri, 3 Dec 2004 09:07:29 +0000
To: linux-mips@linux-mips.org
cc: Dominic Sweetman <dom@mips.com>
Subject: Linux/MIPS expertise needed for reviewers
X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.83, required 4, AWL,
	BAYES_00)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6560
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips


Attention Linux/MIPS gurus: The second edition of See MIPS Run,
written by Dominic Sweetman and published by Morgan Kaufmann
Publishers, will cover running MIPs architecture on Linux.  To
ensure accurate and complete coverage, the publisher is interested
in finding technical reviewers with a strong background in both
Linux and MIPs, who can carefully review the draft manuscript and
provide comments so the author can improve and correct the material.
An honorarium will be paid and credit will be given in the
acknowledgements of the book. Interested parties should contact the
editor's assistant, Kim Honjo, by writing k dot Honjo at elsevier
dot com, and include a cv or resume that details relevant
experience.

--
Dominic Sweetman


From macro@linux-mips.org Fri Dec  3 13:51:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Dec 2004 13:51:20 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:55309 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225007AbULCNvL>; Fri, 3 Dec 2004 13:51:11 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 593BBE1C82; Fri,  3 Dec 2004 14:50:56 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 24798-10; Fri,  3 Dec 2004 14:50:56 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 9CA30E1C78; Fri,  3 Dec 2004 14:50:55 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iB3Doqgu018230;
	Fri, 3 Dec 2004 14:50:53 +0100
Date: Fri, 3 Dec 2004 13:50:49 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: David Daney <ddaney@avtrex.com>, linux-mips@linux-mips.org
Subject: Re: [Patch] make 2.4 compile with GCC-3.4.3...
In-Reply-To: <20041203064017.GE8714@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.58L.0412031347190.4078@blysk.ds.pg.gda.pl>
References: <69397FFCADEFD94F8D5A0FC0FDBCBBDEF4FA@avtrex-server.hq.avtrex.com>
 <20041203064017.GE8714@rembrandt.csv.ica.uni-stuttgart.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/614/Wed Dec  1 16:44:43 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6561
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, 3 Dec 2004, Thiemo Seufer wrote:

> > -fno-unit-at-a-time prevents GCC from rearranging things in its output thus preventing
> > the save_static_function() from being separated from its companion.  As far as I could tell
> > only syscall.c and signal.c need this.
> 
> Ah, I missed that. It's probably better to use the same way as in 2.6,
> that is, to add a jump at the end of save_static_function().

 Note, that I've send a patch for this twice already.  Still no approval, 
though, for whatever (unstated) reason.

> > noinline was not defined for me :( so I removed it.  It seems that in 2.6 it is
> > just #defined to be nothing.  The alternative is to add:
> >  
> > #ifndef noinline
> > #define noinline
> > #endif
> >  
> > to compiler.h as is done in 2.6
> 
> Yes, that's the better idea. gcc-4.0 ff may need it.

 I'll update the patch accordingly and resend.

  Maciej

From milang@tal.org Fri Dec  3 17:48:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Dec 2004 17:48:36 +0000 (GMT)
Received: from gw02.mail.saunalahti.fi ([IPv6:::ffff:195.197.172.116]:39874
	"EHLO gw02.mail.saunalahti.fi") by linux-mips.org with ESMTP
	id <S8225196AbULCRsb>; Fri, 3 Dec 2004 17:48:31 +0000
Received: from fairytale.tal.org (cruel.tal.org [195.16.220.85])
	by gw02.mail.saunalahti.fi (Postfix) with ESMTP id A1A8F856BC
	for <linux-mips@linux-mips.org>; Fri,  3 Dec 2004 19:48:26 +0200 (EET)
Received: from amos (unknown [195.16.220.84])
	by fairytale.tal.org (Postfix) with SMTP id 57CA88DC3
	for <linux-mips@linux-mips.org>; Fri,  3 Dec 2004 19:48:38 +0200 (EET)
Message-ID: <001301c4d960$382122c0$54dc10c3@amos>
From: "Kaj-Michael Lang" <milang@tal.org>
To: "linux-mips" <linux-mips@linux-mips.org>
Subject: arcboot initrd+iso9660+shell patch
Date: Fri, 3 Dec 2004 19:47:53 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Return-Path: <milang@tal.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: 6562
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: milang@tal.org
Precedence: bulk
X-list: linux-mips

Hi

The patch is kinda large so I won't send it to the list, unless
it's ok? It is about 73k.

The patch does:
- Add initrd support (arcboot.conf: initrd=/ramdisk.gz)
- Add interactive/shell mode
  - Load kernel
  - Load ramdisk
  - Edit kernel cmdline arguments
  - ls
  - help for list of commands
- Add working iso9660 support
- Unfinished romfs support
- It's probably a mess
- Probably has many bugs here and there
- To start interactive mode boot with -i as parameter:
  "arcboot -i"
- Tested on IP32 only (and patch changes default to IP32 :)

http://home.tal.org/~milang/o2/patches/arcboot_onion_iso_shell_initrd-1.patch

A binary for IP32 is also available:
http://home.tal.org/~milang/o2/patches/arcboot-patched-1.ip32

Enjoy!

-- 
Kaj-Michael Lang , milang@tal.org


From mlachwani@prometheus.mvista.com Fri Dec  3 20:26:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Dec 2004 20:26:39 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:15613 "EHLO
	prometheus.mvista.com") by linux-mips.org with ESMTP
	id <S8225196AbULCU0d>; Fri, 3 Dec 2004 20:26:33 +0000
Received: from prometheus.mvista.com (localhost.localdomain [127.0.0.1])
	by prometheus.mvista.com (8.12.8/8.12.8) with ESMTP id iB3KQVdh019863
	for <linux-mips@linux-mips.org>; Fri, 3 Dec 2004 12:26:31 -0800
Received: (from mlachwani@localhost)
	by prometheus.mvista.com (8.12.8/8.12.8/Submit) id iB3KQVBs019861
	for linux-mips@linux-mips.org; Fri, 3 Dec 2004 12:26:31 -0800
Date: Fri, 3 Dec 2004 12:26:31 -0800
From: Manish Lachwani <mlachwani@mvista.com>
To: linux-mips@linux-mips.org
Subject: [PATCH] Build fixes for Broadcom DMA Pageops in 2.6
Message-ID: <20041203202631.GA19855@prometheus.mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP"
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <mlachwani@prometheus.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: 6563
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips


--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello !

Attached patch incorporates build related fixes to the Broadcom DMA Pageops
in 2.6. Please review ...

Thanks
Manish Lachwani

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline; filename="common_mips_broadcom_dmapageops.patch"

Source: MontaVista Software, Inc. | URL | Manish Lachwani <mlachwani@mvista.com>
Type: Defect Fix
Disposition: Submitted to Linux-MIPS
Description:
	Build fixes for Broadcom DMA Page Ops

Index: linux/arch/mips/mm/pg-sb1.c
===================================================================
--- linux.orig/arch/mips/mm/pg-sb1.c
+++ linux/arch/mips/mm/pg-sb1.c
@@ -162,7 +162,7 @@
 void sb1_dma_init(void)
 {
 	int cpu = smp_processor_id();
-	uint64_t base_val = PHYSADDR(&page_descr[cpu]) | V_DM_DSCR_BASE_RINGSZ(1);
+	uint64_t base_val = CPHYSADDR(&page_descr[cpu]) | V_DM_DSCR_BASE_RINGSZ(1);
 
 	__raw_writeq(base_val,
 		     IOADDR(A_DM_REGISTER(cpu, R_DM_DSCR_BASE)));
@@ -180,7 +180,7 @@
 	if (KSEGX(page) != CAC_BASE)
 		return clear_page_cpu(page);
 
-	page_descr[cpu].dscr_a = PHYSADDR(page) | M_DM_DSCRA_ZERO_MEM | M_DM_DSCRA_L2C_DEST | M_DM_DSCRA_INTERRUPT;
+	page_descr[cpu].dscr_a = CPHYSADDR(page) | M_DM_DSCRA_ZERO_MEM | M_DM_DSCRA_L2C_DEST | M_DM_DSCRA_INTERRUPT;
 	page_descr[cpu].dscr_b = V_DM_DSCRB_SRC_LENGTH(PAGE_SIZE);
 	__raw_writeq(1, IOADDR(A_DM_REGISTER(cpu, R_DM_DSCR_COUNT)));
 
@@ -195,16 +195,16 @@
 
 void copy_page(void *to, void *from)
 {
-	unsigned long from_phys = PHYSADDR(from);
-	unsigned long to_phys = PHYSADDR(to);
+	unsigned long from_phys = CPHYSADDR(from);
+	unsigned long to_phys = CPHYSADDR(to);
 	int cpu = smp_processor_id();
 
 	/* if either page is above Kseg0, use old way */
 	if ((KSEGX(to) != CAC_BASE) || (KSEGX(from) != CAC_BASE))
 		return copy_page_cpu(to, from);
 
-	page_descr[cpu].dscr_a = PHYSADDR(to_phys) | M_DM_DSCRA_L2C_DEST | M_DM_DSCRA_INTERRUPT;
-	page_descr[cpu].dscr_b = PHYSADDR(from_phys) | V_DM_DSCRB_SRC_LENGTH(PAGE_SIZE);
+	page_descr[cpu].dscr_a = CPHYSADDR(to_phys) | M_DM_DSCRA_L2C_DEST | M_DM_DSCRA_INTERRUPT;
+	page_descr[cpu].dscr_b = CPHYSADDR(from_phys) | V_DM_DSCRB_SRC_LENGTH(PAGE_SIZE);
 	__raw_writeq(1, IOADDR(A_DM_REGISTER(cpu, R_DM_DSCR_COUNT)));
 
 	/*

--5mCyUwZo2JvN/JJP--

From ica2_ts@csv.ica.uni-stuttgart.de Sat Dec  4 03:49:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 04 Dec 2004 03:49:40 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:55814
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225435AbULDDte>; Sat, 4 Dec 2004 03:49:34 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CaQvI-0002HQ-00; Sat, 04 Dec 2004 04:49:28 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CaQvG-0006we-00; Sat, 04 Dec 2004 04:49:26 +0100
Date: Sat, 4 Dec 2004 04:49:26 +0100
To: Kaj-Michael Lang <milang@tal.org>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: arcboot initrd+iso9660+shell patch
Message-ID: <20041204034926.GJ8714@rembrandt.csv.ica.uni-stuttgart.de>
References: <001301c4d960$382122c0$54dc10c3@amos>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001301c4d960$382122c0$54dc10c3@amos>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6564
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Kaj-Michael Lang wrote:
> Hi
> 
> The patch is kinda large so I won't send it to the list, unless
> it's ok? It is about 73k.
> 
> The patch does:
> - Add initrd support (arcboot.conf: initrd=/ramdisk.gz)
> - Add interactive/shell mode
>   - Load kernel
>   - Load ramdisk
>   - Edit kernel cmdline arguments
>   - ls
>   - help for list of commands
> - Add working iso9660 support
> - Unfinished romfs support
> - It's probably a mess
> - Probably has many bugs here and there
> - To start interactive mode boot with -i as parameter:
>   "arcboot -i"
> - Tested on IP32 only (and patch changes default to IP32 :)
> 
> http://home.tal.org/~milang/o2/patches/arcboot_onion_iso_shell_initrd-1.patch

Great! A few comments, though:

 - About CFLAGS: Using -g is almost always a good idea, even if you strip
   the binaries afterwards. Using -march=mips3 is a bad idea if we ever
   want to support Indigo1 etc. It also breaks build with older compilers,
   and doesn't provide any relevant performance gain.
 - _PARM_LIMIT was 32 to match the kernel param limit. If you change it to
   allow more for arcboot, make sure it complains if more than 32 params
   are passed to the kernel.
 - ARC_CDROM/ARC_DISK shouldn't have a leading pci(0) for ip22, PROMPT
   should be arcboot@ip22 in that case.
 - Default SUBARCH should remain ip22. Better: Build both unconditionally
   unless overridden by a SUBARCH setting.
 - The tip22 stuff is broken (at least: doesn't match what's in CVS).


Thiemo

From mlachwani@prometheus.mvista.com Mon Dec  6 21:27:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 06 Dec 2004 21:27:30 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:58352 "EHLO
	prometheus.mvista.com") by linux-mips.org with ESMTP
	id <S8224989AbULFV1X>; Mon, 6 Dec 2004 21:27:23 +0000
Received: from prometheus.mvista.com (localhost.localdomain [127.0.0.1])
	by prometheus.mvista.com (8.12.8/8.12.8) with ESMTP id iB6LRLdh011398
	for <linux-mips@linux-mips.org>; Mon, 6 Dec 2004 13:27:21 -0800
Received: (from mlachwani@localhost)
	by prometheus.mvista.com (8.12.8/8.12.8/Submit) id iB6LRKIY011396
	for linux-mips@linux-mips.org; Mon, 6 Dec 2004 13:27:20 -0800
Date: Mon, 6 Dec 2004 13:27:20 -0800
From: Manish Lachwani <mlachwani@mvista.com>
To: linux-mips@linux-mips.org
Subject: [PATCH] Ocelot-3 supports 256 MB memory
Message-ID: <20041206212720.GA11390@prometheus.mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="d6Gm4EdcadzBjdND"
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <mlachwani@prometheus.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: 6565
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips


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

Hi Ralf,

Small patch for Ocelot-3 to support 256 MB memory. Please apply ...

Thanks
Manish Lachwani


--d6Gm4EdcadzBjdND
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline; filename=patch-ocelot3-mem

--- arch/mips/momentum/ocelot_3/setup.c.orig	2004-12-06 13:18:44.000000000 -0800
+++ arch/mips/momentum/ocelot_3/setup.c	2004-12-06 13:18:57.000000000 -0800
@@ -390,8 +390,8 @@
 	printk("  - Boot flash write jumper: %s\n", (tmpword&0x40)?"installed":"absent");
 	printk("  - L3 cache size: %d MB\n", (1<<((tmpword&12) >> 2))&~1);
 
-	/* Support for 128 MB memory */
-	add_memory_region(0x0, 0x08000000, BOOT_MEM_RAM);
+	/* Support for 256 MB memory */
+	add_memory_region(0x0, 0x10000000, BOOT_MEM_RAM);
 
 	return 0;
 }

--d6Gm4EdcadzBjdND--

From ralf@linux-mips.org Mon Dec  6 21:43:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 06 Dec 2004 21:43:57 +0000 (GMT)
Received: from pD956258C.dip.t-dialin.net ([IPv6:::ffff:217.86.37.140]:23211
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224989AbULFVnx>; Mon, 6 Dec 2004 21:43:53 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB6Lhpkt004550;
	Mon, 6 Dec 2004 22:43:51 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB6Lhk57004474;
	Mon, 6 Dec 2004 22:43:46 +0100
Date: Mon, 6 Dec 2004 22:43:46 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Manish Lachwani <mlachwani@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Ocelot-3 supports 256 MB memory
Message-ID: <20041206214346.GA1182@linux-mips.org>
References: <20041206212720.GA11390@prometheus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041206212720.GA11390@prometheus.mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6566
X-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, Dec 06, 2004 at 01:27:20PM -0800, Manish Lachwani wrote:

> Small patch for Ocelot-3 to support 256 MB memory. Please apply ...

Does this board really have a fixed memory configuration?  If not we should
use a safe default, the minimum configuration.  Or probe which obviously
is the right thing to do.

  Ralf

From mlachwani@mvista.com Mon Dec  6 21:52:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 06 Dec 2004 21:53:00 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:53749 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8224989AbULFVwz>; Mon, 6 Dec 2004 21:52:55 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id 40AEE184FF; Mon,  6 Dec 2004 13:52:54 -0800 (PST)
Message-ID: <41B4D4B5.5030104@mvista.com>
Date: Mon, 06 Dec 2004 13:52:53 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Ocelot-3 supports 256 MB memory
References: <20041206212720.GA11390@prometheus.mvista.com> <20041206214346.GA1182@linux-mips.org>
In-Reply-To: <20041206214346.GA1182@linux-mips.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6567
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

Ralf Baechle wrote:
> On Mon, Dec 06, 2004 at 01:27:20PM -0800, Manish Lachwani wrote:
> 
> 
>>Small patch for Ocelot-3 to support 256 MB memory. Please apply ...
> 
> 
> Does this board really have a fixed memory configuration?  If not we should
> use a safe default, the minimum configuration.  Or probe which obviously
> is the right thing to do.
> 
>   Ralf

Probing is a better idea. Let me put that together and send another patch

Thanks
Manish Lachwani



From mlachwani@prometheus.mvista.com Tue Dec  7 00:35:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 00:36:01 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:65267 "EHLO
	prometheus.mvista.com") by linux-mips.org with ESMTP
	id <S8225205AbULGAf4>; Tue, 7 Dec 2004 00:35:56 +0000
Received: from prometheus.mvista.com (localhost.localdomain [127.0.0.1])
	by prometheus.mvista.com (8.12.8/8.12.8) with ESMTP id iB70Zrdh022924;
	Mon, 6 Dec 2004 16:35:53 -0800
Received: (from mlachwani@localhost)
	by prometheus.mvista.com (8.12.8/8.12.8/Submit) id iB70ZrUU022914;
	Mon, 6 Dec 2004 16:35:53 -0800
Date: Mon, 6 Dec 2004 16:35:53 -0800
From: Manish Lachwani <mlachwani@prometheus.mvista.com>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
Subject: [PATCH] Ocelot-3 memory configuration patch
Message-ID: <20041207003553.GA22456@prometheus.mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <mlachwani@prometheus.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: 6568
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@prometheus.mvista.com
Precedence: bulk
X-list: linux-mips


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

Hi Ralf,

Based on your suggestion, I have now modified the Ocelot-3 code
to probe for memory that has been configured by PMON. Please review ...

Thanks
Manish Lachwani


--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline; filename="common_mips_ocelot3_memory.patch"

Index: linux/arch/mips/momentum/ocelot_3/prom.c
===================================================================
--- linux.orig/arch/mips/momentum/ocelot_3/prom.c
+++ linux/arch/mips/momentum/ocelot_3/prom.c
@@ -34,6 +34,7 @@
 struct callvectors* debug_vectors;
 extern unsigned long marvell_base;
 extern unsigned long cpu_clock;
+extern unsigned long memsize;
 
 #ifdef CONFIG_MV643XX_ETH
 extern unsigned char prom_mac_addr_base[6];
@@ -194,6 +195,11 @@
 							NULL, 10);
 			printk("cpu_clock set to %d\n", cpu_clock);
 		}
+		if (strncmp("memsize", ptr, strlen("memsize"))  == 0) {
+			memsize = simple_strtol(ptr + strlen("memsize="),
+							NULL, 10);
+		}
+
 		i++;
 	}
 	printk("arcs_cmdline: %s\n", arcs_cmdline);
@@ -222,6 +228,10 @@
 			cpu_clock = simple_strtol(*env + strlen("cpuclock="),
 							NULL, 10);
 		}
+		if (strncmp("memsize", *env, strlen("memsize")) == 0) {
+			memsize = simple_strtol(*env + strlen("memsize="),
+							NULL, 10);
+		}
 		env++;
 	}
 #endif /* CONFIG_MIPS64 */
Index: linux/arch/mips/momentum/ocelot_3/setup.c
===================================================================
--- linux.orig/arch/mips/momentum/ocelot_3/setup.c
+++ linux/arch/mips/momentum/ocelot_3/setup.c
@@ -77,6 +77,9 @@
 /* CPU clock */
 unsigned long cpu_clock;
 
+/* Memory size */
+unsigned long memsize;
+
 /* RTC/NVRAM */
 unsigned char* rtc_base = (unsigned char*)(signed)0xfc800000;
 
@@ -390,8 +393,8 @@
 	printk("  - Boot flash write jumper: %s\n", (tmpword&0x40)?"installed":"absent");
 	printk("  - L3 cache size: %d MB\n", (1<<((tmpword&12) >> 2))&~1);
 
-	/* Support for 256 MB memory */
-	add_memory_region(0x0, 0x10000000, BOOT_MEM_RAM);
+	/* Support for memory configured by PMON*/
+	add_memory_region(0x0, memsize * 1024 * 1024, BOOT_MEM_RAM);
 
 	return 0;
 }

--wac7ysb48OaltWcw--

From nunoe@co-nss.co.jp Tue Dec  7 01:07:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 01:07:38 +0000 (GMT)
Received: from nssinet2.co-nss.co.jp ([IPv6:::ffff:150.96.0.5]:31904 "EHLO
	nssinet2.co-nss.co.jp") by linux-mips.org with ESMTP
	id <S8224990AbULGBHd>; Tue, 7 Dec 2004 01:07:33 +0000
Received: from nssinet2.co-nss.co.jp (localhost [127.0.0.1])
	by nssinet2.co-nss.co.jp (8.9.3/3.7W) with ESMTP id KAA06155
	for <linux-mips@linux-mips.org>; Tue, 7 Dec 2004 10:03:19 +0900 (JST)
Received: from nssnet.co-nss.co.jp (nssnet.co-nss.co.jp [150.96.64.250])
	by nssinet2.co-nss.co.jp (8.9.3/3.7W) with ESMTP id KAA06151
	for <linux-mips@linux-mips.org>; Tue, 7 Dec 2004 10:03:19 +0900 (JST)
Received: from NUNOE ([150.96.160.60])
	by nssnet.co-nss.co.jp (8.9.3+Sun/3.7W) with SMTP id JAA03088
	for <linux-mips@linux-mips.org>; Tue, 7 Dec 2004 09:54:17 +0900 (JST)
Message-ID: <001101c4dbf9$1da02270$3ca06096@NUNOE>
From: "Hdei Nunoe" <nunoe@co-nss.co.jp>
To: <linux-mips@linux-mips.org>
Subject: HIGHMEM
Date: Tue, 7 Dec 2004 10:07:26 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-2022-jp";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Return-Path: <nunoe@co-nss.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: 6569
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nunoe@co-nss.co.jp
Precedence: bulk
X-list: linux-mips

Hi there,

Has anyone succeeded the HIGHMEM with discontiguous physical memory?
I am using kernel 2.4.18 on TX4937 with two chunks of 256Mbyte memory.
There is 256Mbyte gap in between the physical memory blocks - lower 
memory is 0x00000000 to 0x10000000, upper memory is 0x20000000 to
0x30000000.  System hungs when it create INIT process.

Cheers,
-hdei



From krishnamurthydv@yahoo.com Tue Dec  7 09:03:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 09:04:02 +0000 (GMT)
Received: from web60103.mail.yahoo.com ([IPv6:::ffff:216.109.118.82]:3450 "HELO
	web60103.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224990AbULGJD5>; Tue, 7 Dec 2004 09:03:57 +0000
Received: (qmail 32853 invoked by uid 60001); 7 Dec 2004 09:03:50 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=BaxPSgxidVcwzAvZZJhmG6Ax8/Sxk80K10fUT5/jHeqlywHomlD7ke0dInfDEJadtux2m1ccNnUYTckhIgKkc3JjAZp4ewgKELxS36i8EG2xk11XIsbvniY1CA0k46OPCieRFgImYAzdt/5/F2/ACiwgL4fJkhKMkYwY9aFinls=  ;
Message-ID: <20041207090350.32851.qmail@web60103.mail.yahoo.com>
Received: from [63.111.213.196] by web60103.mail.yahoo.com via HTTP; Tue, 07 Dec 2004 01:03:50 PST
Date: Tue, 7 Dec 2004 01:03:50 -0800 (PST)
From: Krishnamurthy Daulatabad <krishnamurthydv@yahoo.com>
Subject: MIPS - 2.4.20 kernel - wait_on_irq issue
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <krishnamurthydv@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: 6570
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: krishnamurthydv@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi
  Request some clarification on the 2.4.20 MIPS kernel
port.

Specifically refer to function wait_on_irq() in
arch/mips/kernel/irq.c. This function is called from 
get_irqlock() which in turn is called from
__global_cli eventually by cli().     
                                                      
                                                      
                                                   The
wait_on_irq() function does not return until "all the
CPUS" have run the ISRs.  To reach this state
interrupts have to be disabled on all the CPUs and
then wait for the ISRs to complete.  So __cli()
function called from this function is supposed to
disable the interrupts. The __cli() in MIPS will
disable the Interrupts by resetting the coprocessor
register's "Interrupt Enable"  bit which is per CPU. 
So this is going to just disable the interrupts on the
current CPU and not others.                           
                                                      
                                            

So in  a SMP system with N CPUs, can there be a
situation where wait_on_irq() may never return as an
ISR could be running in one CPU or the other as the
interrupts are not being disabled on all the CPUs? The
irq_running() function may always return TRUE for a
large number of CPUs in this case.

So, is there a problem here or am I missing something?

2.6 kernel seems to be handling the cli() call
differently.

Thanks
Krishnamurthy

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From jbglaw@lug-owl.de Tue Dec  7 09:17:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 09:17:50 +0000 (GMT)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:28036 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8224990AbULGJRq>;
	Tue, 7 Dec 2004 09:17:46 +0000
Received: by lug-owl.de (Postfix, from userid 1001)
	id 8ACB9190254; Tue,  7 Dec 2004 10:17:44 +0100 (CET)
Date: Tue, 7 Dec 2004 10:17:44 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Hdei Nunoe <nunoe@co-nss.co.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: HIGHMEM
Message-ID: <20041207091744.GN16958@lug-owl.de>
Mail-Followup-To: Hdei Nunoe <nunoe@co-nss.co.jp>,
	linux-mips@linux-mips.org
References: <001101c4dbf9$1da02270$3ca06096@NUNOE>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="dngyMJhgXGAL5Gb8"
Content-Disposition: inline
In-Reply-To: <001101c4dbf9$1da02270$3ca06096@NUNOE>
X-Operating-System: Linux mail 2.6.10-rc2-bk5lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.6+20040907i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6571
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


--dngyMJhgXGAL5Gb8
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2004-12-07 10:07:26 +0900, Hdei Nunoe <nunoe@co-nss.co.jp>
wrote in message <001101c4dbf9$1da02270$3ca06096@NUNOE>:

> Has anyone succeeded the HIGHMEM with discontiguous physical memory?
> I am using kernel 2.4.18 on TX4937 with two chunks of 256Mbyte memory.

2.4.18 is obsolete...

MfG, JBG

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

--dngyMJhgXGAL5Gb8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFBtXU4Hb1edYOZ4bsRAjoVAJ45cfaKbAOlx3uD1ID7lAS7iFlVEgCZAdMh
APbI1hvnshk8Hj670fv9Fqw=
=+70p
-----END PGP SIGNATURE-----

--dngyMJhgXGAL5Gb8--

From thomas.petazzoni@enix.org Tue Dec  7 09:21:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 09:21:43 +0000 (GMT)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:16107 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8224990AbULGJVj>; Tue, 7 Dec 2004 09:21:39 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by the-doors.enix.org (Postfix) with ESMTP id 2F1BE1ED37
	for <linux-mips@linux-mips.org>; Tue,  7 Dec 2004 10:21:33 +0100 (CET)
Message-ID: <41B5766C.6010801@enix.org>
Date: Tue, 07 Dec 2004 10:22:52 +0100
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040926)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Wiki contents license
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig02923C71794173EB5F6BE9EB"
Return-Path: <thomas.petazzoni@enix.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: 6572
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thomas.petazzoni@enix.org
Precedence: bulk
X-list: linux-mips

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig02923C71794173EB5F6BE9EB
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

I would like to know if the contents of Linux MIPS Wiki are under a 
certain license. I would like to use parts of it for the french 
Wikipedia (after translation).

Is it possible ?

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org
http://thomas.enix.org - Jabber: thomas.petazzoni@jabber.dk
http://kos.enix.org, http://sos.enix.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

--------------enig02923C71794173EB5F6BE9EB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBtXZs9lPLMJjT96cRAu6VAJ4gS2WLgd0sSwlmWtrVtrf5/mbKkgCgm0cB
z2TmneLX63Bbyvn+8EsuOwo=
=ZGOS
-----END PGP SIGNATURE-----

--------------enig02923C71794173EB5F6BE9EB--

From ladis@linux-mips.org Tue Dec  7 09:38:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 09:38:45 +0000 (GMT)
Received: from smtp.seznam.cz ([IPv6:::ffff:212.80.76.43]:60814 "HELO
	smtp.seznam.cz") by linux-mips.org with SMTP id <S8224990AbULGJil>;
	Tue, 7 Dec 2004 09:38:41 +0000
Received: (qmail 22520 invoked from network); 7 Dec 2004 09:38:34 -0000
Received: from unknown (HELO orphique) (Ladislav.Michl@62.77.73.201)
  by smtp.seznam.cz with SMTP; 7 Dec 2004 09:38:34 -0000
Received: from ladis by orphique with local (Exim 3.36 #1 (Debian))
	id 1Cbbnm-0001R2-00; Tue, 07 Dec 2004 10:38:34 +0100
Date: Tue, 7 Dec 2004 10:38:34 +0100
To: Thomas Petazzoni <thomas.petazzoni@enix.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Wiki contents license
Message-ID: <20041207093834.GA5467@simek>
References: <41B5766C.6010801@enix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41B5766C.6010801@enix.org>
User-Agent: Mutt/1.5.6+20040722i
From: Ladislav Michl <ladis@linux-mips.org>
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6573
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Dec 07, 2004 at 10:22:52AM +0100, Thomas Petazzoni wrote:
> I would like to know if the contents of Linux MIPS Wiki are under a 
> certain license. I would like to use parts of it for the french 
> Wikipedia (after translation).

As stated on main page:
"Content is available under GNU General Public License 2."

From ica2_ts@csv.ica.uni-stuttgart.de Tue Dec  7 09:42:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 09:42:19 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:22068
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224990AbULGJmP>; Tue, 7 Dec 2004 09:42:15 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CbbrK-0007xk-00; Tue, 07 Dec 2004 10:42:14 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CbbrC-0002IO-00; Tue, 07 Dec 2004 10:42:06 +0100
Date: Tue, 7 Dec 2004 10:42:06 +0100
To: Thomas Petazzoni <thomas.petazzoni@enix.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Wiki contents license
Message-ID: <20041207094206.GO8714@rembrandt.csv.ica.uni-stuttgart.de>
References: <41B5766C.6010801@enix.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50"
Content-Disposition: inline
In-Reply-To: <41B5766C.6010801@enix.org>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6574
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips


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

Thomas Petazzoni wrote:
> Hello,
>=20
> I would like to know if the contents of Linux MIPS Wiki are under a=20
> certain license.

The page says GPL2.


Thiemo

--hHWLQfXTYDoKhP50
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iEYEARECAAYFAkG1eu0ACgkQXNuq0tFCNaBp/QCfSXzXB6F55ENmAPypbAHbpQPj
eUQAn1D+CJk9mdHbPAbLh8224Qyingz5
=ulXq
-----END PGP SIGNATURE-----

--hHWLQfXTYDoKhP50--

From nunoe@co-nss.co.jp Tue Dec  7 09:56:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 09:56:45 +0000 (GMT)
Received: from nssinet2.co-nss.co.jp ([IPv6:::ffff:150.96.0.5]:38082 "EHLO
	nssinet2.co-nss.co.jp") by linux-mips.org with ESMTP
	id <S8224990AbULGJ4l>; Tue, 7 Dec 2004 09:56:41 +0000
Received: from nssinet2.co-nss.co.jp (localhost [127.0.0.1])
	by nssinet2.co-nss.co.jp (8.9.3/3.7W) with ESMTP id SAA25202
	for <linux-mips@linux-mips.org>; Tue, 7 Dec 2004 18:52:27 +0900 (JST)
Received: from nssnet.co-nss.co.jp (nssnet.co-nss.co.jp [150.96.64.250])
	by nssinet2.co-nss.co.jp (8.9.3/3.7W) with ESMTP id SAA25198;
	Tue, 7 Dec 2004 18:52:27 +0900 (JST)
Received: from NUNOE ([150.96.160.64])
	by nssnet.co-nss.co.jp (8.9.3+Sun/3.7W) with SMTP id SAA28116;
	Tue, 7 Dec 2004 18:43:25 +0900 (JST)
Message-ID: <002101c4dc43$08c4c7d0$3ca06096@NUNOE>
From: "Hdei Nunoe" <nunoe@co-nss.co.jp>
To: "Jan-Benedict Glaw" <jbglaw@lug-owl.de>
Cc: <linux-mips@linux-mips.org>
References: <001101c4dbf9$1da02270$3ca06096@NUNOE> <20041207091744.GN16958@lug-owl.de>
Subject: Re: HIGHMEM
Date: Tue, 7 Dec 2004 18:56:33 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Return-Path: <nunoe@co-nss.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: 6575
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nunoe@co-nss.co.jp
Precedence: bulk
X-list: linux-mips

Hi Jan,

Will it work on the newer version?

Cheers,
-hdei

----- Original Message ----- 
From: "Jan-Benedict Glaw" <jbglaw@lug-owl.de>
To: "Hdei Nunoe" <nunoe@co-nss.co.jp>
Cc: <linux-mips@linux-mips.org>
Sent: Tuesday, December 07, 2004 6:17 PM
Subject: Re: HIGHMEM

> Has anyone succeeded the HIGHMEM with discontiguous physical memory?
> I am using kernel 2.4.18 on TX4937 with two chunks of 256Mbyte memory.

2.4.18 is obsolete...

MfG, JBG

-- 

From ralf@linux-mips.org Tue Dec  7 09:58:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 09:59:00 +0000 (GMT)
Received: from pD9562292.dip.t-dialin.net ([IPv6:::ffff:217.86.34.146]:23240
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224990AbULGJ6z>; Tue, 7 Dec 2004 09:58:55 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB79wdjT012364;
	Tue, 7 Dec 2004 10:58:39 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB79wbZv012329;
	Tue, 7 Dec 2004 10:58:37 +0100
Date: Tue, 7 Dec 2004 10:58:37 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Hdei Nunoe <nunoe@co-nss.co.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: HIGHMEM
Message-ID: <20041207095837.GA13264@linux-mips.org>
References: <001101c4dbf9$1da02270$3ca06096@NUNOE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001101c4dbf9$1da02270$3ca06096@NUNOE>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6576
X-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, Dec 07, 2004 at 10:07:26AM +0900, Hdei Nunoe wrote:

> Has anyone succeeded the HIGHMEM with discontiguous physical memory?
> I am using kernel 2.4.18 on TX4937 with two chunks of 256Mbyte memory.
> There is 256Mbyte gap in between the physical memory blocks - lower 
> memory is 0x00000000 to 0x10000000, upper memory is 0x20000000 to
> 0x30000000.  System hungs when it create INIT process.

In 2.4 the support for CONFIG_DISCONTIG and CONFIG_NUMA are a bit tangled
with each other because IP27 is the only platform to uses these features
and it needs both.  Other than that you can also just setup your system
as 0x0 - 0x10000000 being RAM, 0x10000000 - 0x20000000 being reserved
memory and 0x20000000 - 0x30000000 being highmem.  Which works but is a
bit wasteful.

Issue #2 is that we don't support the combination of CONFIG_DISCONTIG and
CONFIG_HIGHMEM.  And highmem is a lobotomized solution for lobotomized
silicon anyway.  You have a 64-bit processor - use it's capabilities :-)

Issue #3 - As I recall the TX4937's H3 core is suffering from cache
aliases.  Handling those efficiently for highmem is not easily possible
and so we don't even try.  More recent kernels will refuse to enable
highmem on such cache configurations but something like 2.4.18 which by
now is an almost 3 year old antique doesn't know about that and will
happily crash.

I recommend you should go for a 64-bit kernel instead.  And 64-bit support
is certainly better in 2.6 than in 2.4.  Especially the area of 32-bit
binary compatibility has been improved significantly.

  Ralf

From ralf@linux-mips.org Tue Dec  7 10:02:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 10:02:15 +0000 (GMT)
Received: from pD9562292.dip.t-dialin.net ([IPv6:::ffff:217.86.34.146]:59087
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224990AbULGKCL>; Tue, 7 Dec 2004 10:02:11 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB7A26We015550;
	Tue, 7 Dec 2004 11:02:06 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB7A22ej015483;
	Tue, 7 Dec 2004 11:02:02 +0100
Date: Tue, 7 Dec 2004 11:02:02 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Thomas Petazzoni <thomas.petazzoni@enix.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Wiki contents license
Message-ID: <20041207100202.GB13264@linux-mips.org>
References: <41B5766C.6010801@enix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41B5766C.6010801@enix.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6577
X-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, Dec 07, 2004 at 10:22:52AM +0100, Thomas Petazzoni wrote:

> I would like to know if the contents of Linux MIPS Wiki are under a 
> certain license. I would like to use parts of it for the french 
> Wikipedia (after translation).
> 
> Is it possible ?

You can license the parts you wrote yourself under a different license such
as the GNU FDL.  Or ask others to do so.  The Linux/MIPS Wiki contains
significant portions of kernel code in some pages which was licensed under
the GPL anyway.

  Ralf

From jbglaw@lug-owl.de Tue Dec  7 10:02:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 10:02:51 +0000 (GMT)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:22918 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8225220AbULGKCo>;
	Tue, 7 Dec 2004 10:02:44 +0000
Received: by lug-owl.de (Postfix, from userid 1001)
	id 3C29F190258; Tue,  7 Dec 2004 11:02:43 +0100 (CET)
Date: Tue, 7 Dec 2004 11:02:43 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: HIGHMEM
Message-ID: <20041207100243.GP16958@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <001101c4dbf9$1da02270$3ca06096@NUNOE> <20041207091744.GN16958@lug-owl.de> <002101c4dc43$08c4c7d0$3ca06096@NUNOE>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="0WzQiIesntPPsVaS"
Content-Disposition: inline
In-Reply-To: <002101c4dc43$08c4c7d0$3ca06096@NUNOE>
X-Operating-System: Linux mail 2.6.10-rc2-bk5lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.6+20040907i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6578
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


--0WzQiIesntPPsVaS
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2004-12-07 18:56:33 +0900, Hdei Nunoe <nunoe@co-nss.co.jp>
wrote in message <002101c4dc43$08c4c7d0$3ca06096@NUNOE>:

> Will it work on the newer version?

Did you try recent 2.6.x versions?

MfG, JBG

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

--0WzQiIesntPPsVaS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFBtX/DHb1edYOZ4bsRAoa5AJ9YYL4S4Rmzu428yWF+sfbhFG2HGgCeJDcT
EQubHydVSjCkKCBEteyK6JU=
=4mJ2
-----END PGP SIGNATURE-----

--0WzQiIesntPPsVaS--

From michael.stickel@4g-systems.biz Tue Dec  7 10:06:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 10:06:22 +0000 (GMT)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.190]:41408
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8224990AbULGKGR>; Tue, 7 Dec 2004 10:06:17 +0000
Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1CbcEZ-0007XP-00
	for linux-mips@linux-mips.org; Tue, 07 Dec 2004 11:06:15 +0100
Received: from [217.91.102.65] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128)
	(Exim 3.35 #1)
	id 1CbcEZ-0007vg-00
	for linux-mips@linux-mips.org; Tue, 07 Dec 2004 11:06:15 +0100
From: Michael Stickel <michael.stickel@4g-systems.biz>
To: linux-mips@linux-mips.org
Subject: Re: [PATCH] Ocelot-3 memory configuration patch
Date: Tue, 7 Dec 2004 11:06:14 +0100
User-Agent: KMail/1.7
References: <20041207003553.GA22456@prometheus.mvista.com>
In-Reply-To: <20041207003553.GA22456@prometheus.mvista.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200412071106.14064.michael.stickel@4g-systems.biz>
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:f72049c8971f462876d14eb8b3ccbbf1
Return-Path: <michael.stickel@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6579
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michael.stickel@4g-systems.biz
Precedence: bulk
X-list: linux-mips

What if the "memsize" PMON variable is not defined?
Can that happen. Then the memory size is either 0L,
or an undefined value.
Shouldn't it be initialized to 128 by default?

On Tuesday 07 December 2004 01:35, you wrote:
> Hi Ralf,
>
> Based on your suggestion, I have now modified the Ocelot-3 code
> to probe for memory that has been configured by PMON. Please review ...
>
> Thanks
> Manish Lachwani

From jonah@omegav.ntnu.no Tue Dec  7 10:29:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 10:29:11 +0000 (GMT)
Received: from royk.itea.ntnu.no ([IPv6:::ffff:129.241.190.230]:8679 "EHLO
	royk.itea.ntnu.no") by linux-mips.org with ESMTP
	id <S8225224AbULGK3H>; Tue, 7 Dec 2004 10:29:07 +0000
Received: from localhost (localhost [127.0.0.1])
	by royk.itea.ntnu.no (Postfix) with ESMTP id 47B8B67556;
	Tue,  7 Dec 2004 11:29:05 +0100 (CET)
Received: from invalid.ed.ntnu.no (invalid.ed.ntnu.no [129.241.179.15])
	by royk.itea.ntnu.no (Postfix) with ESMTP;
	Tue,  7 Dec 2004 11:29:05 +0100 (CET)
Received: from invalid.ed.ntnu.no (localhost.ed.ntnu.no [127.0.0.1])
	by invalid.ed.ntnu.no (8.12.9p2/8.12.9) with ESMTP id iB7AT418044520
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO);
	Tue, 7 Dec 2004 11:29:05 +0100 (CET)
	(envelope-from jonah@omegav.ntnu.no)
Received: from localhost (jonah@localhost)
	by invalid.ed.ntnu.no (8.12.9p2/8.12.9/Submit) with ESMTP id iB7AT46v044517;
	Tue, 7 Dec 2004 11:29:04 +0100 (CET)
	(envelope-from jonah@omegav.ntnu.no)
X-Authentication-Warning: invalid.ed.ntnu.no: jonah owned process doing -bs
Date: Tue, 7 Dec 2004 11:29:04 +0100 (CET)
From: Jon Anders Haugum <jonah@omegav.ntnu.no>
X-X-Sender: jonah@invalid.ed.ntnu.no
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: HIGHMEM
In-Reply-To: <003801c4dc45$f9212690$2203a8c0@qfree.com>
Message-ID: <20041207112038.X44387@invalid.ed.ntnu.no>
References: <003801c4dc45$f9212690$2203a8c0@qfree.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no.
Return-Path: <jonah@omegav.ntnu.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: 6580
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jonah@omegav.ntnu.no
Precedence: bulk
X-list: linux-mips

> In 2.4 the support for CONFIG_DISCONTIG and CONFIG_NUMA are a bit tangled
> with each other because IP27 is the only platform to uses these features and
> it needs both.  Other than that you can also just setup your system as 0x0 -
> 0x10000000 being RAM, 0x10000000 - 0x20000000 being reserved memory and
> 0x20000000 - 0x30000000 being highmem.  Which works but is a bit wasteful.
>
> Issue #2 is that we don't support the combination of CONFIG_DISCONTIG and
> CONFIG_HIGHMEM.  And highmem is a lobotomized solution for lobotomized
> silicon anyway.  You have a 64-bit processor - use it's capabilities :-)
>
> Issue #3 - As I recall the TX4937's H3 core is suffering from cache aliases.
> Handling those efficiently for highmem is not easily possible and so we
> don't even try.  More recent kernels will refuse to enable highmem on such
> cache configurations but something like 2.4.18 which by now is an almost 3
> year old antique doesn't know about that and will happily crash.
>
> I recommend you should go for a 64-bit kernel instead.  And 64-bit support
> is certainly better in 2.6 than in 2.4.  Especially the area of 32-bit
> binary compatibility has been improved significantly.

What about on a processor like the AMD au1550?

I've tried the latest from 2.4 branch in cvs, and I haven't been 
successful in geting past INIT either...

Can I place all the memory from address 0x20000000 to get more than 
256Meg?


-- 
Jon Anders Haugum


From rsandifo@redhat.com Tue Dec  7 11:57:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 11:57:10 +0000 (GMT)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:29117 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225237AbULGL5E>;
	Tue, 7 Dec 2004 11:57:04 +0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iB7Bux02007467;
	Tue, 7 Dec 2004 06:56:59 -0500
Received: from talisman.cambridge.redhat.com (talisman.cambridge.redhat.com [172.16.18.81])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iB7Buvr16592;
	Tue, 7 Dec 2004 06:56:58 -0500
Received: from talisman.cambridge.redhat.com (localhost.localdomain [127.0.0.1])
	by talisman.cambridge.redhat.com (8.13.1/8.12.10) with ESMTP id iB7BuuaV016939;
	Tue, 7 Dec 2004 11:56:56 GMT
Received: (from rsandifo@localhost)
	by talisman.cambridge.redhat.com (8.13.1/8.12.10/Submit) id iB7BuscA016938;
	Tue, 7 Dec 2004 11:56:54 GMT
X-Authentication-Warning: talisman.cambridge.redhat.com: rsandifo set sender to rsandifo@redhat.com using -f
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Dominic Sweetman <dom@mips.com>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org, Nigel Stephens <nigel@mips.com>,
	David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
	<16813.39660.948092.328493@doms-laptop.algor.co.uk>
	<20041201123336.GA5612@linux-mips.org>
	<Pine.LNX.4.58L.0412012136480.13579@blysk.ds.pg.gda.pl>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Tue, 07 Dec 2004 11:56:54 +0000
In-Reply-To: <Pine.LNX.4.58L.0412012136480.13579@blysk.ds.pg.gda.pl> (Maciej
 W. Rozycki's message of "Wed, 1 Dec 2004 21:50:45 +0000 (GMT)")
Message-ID: <wvn653epbi1.fsf@talisman.cambridge.redhat.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
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: 6581
X-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

I've only been reading this list in batches recently, so this reply
has quotes from several separate messages, sorry.

First some general comments:

  - Explicit relocs for n64 non-PIC weren't implemented before the gcc 3.4
    feature freeze.  gcc 3.4.x therefore still uses symbolic addresses when
    compiling a 64-bit kernel.

  - gcc 4.0 knows how to generate explicit relocs for n64 non-PIC and
    (by default) will use them instead of symbolic addresses.

  - As Thiemo says, there as talk of a -msym32 option (more below), but it
    hasn't been implemented yet.  This means that if you want to the use
    the 2-instruction dla hack, you'll need to use -mno-explicit-relocs
    when compiling with 4.0.  Don't count on that option being around
    forever though!

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Wed, 1 Dec 2004, Ralf Baechle wrote:
>> this problem here is specific to inline assembler.  The splitlock code for
>> a reasonable CPU is:
>> 
>> static __inline__ void atomic_add(int i, atomic_t * v)
>> {
>>         unsigned long temp;
>> 
>>         __asm__ __volatile__(
>>         "1:     ll      %0, %1          # atomic_add            \n"
>>         "       addu    %0, %2                                  \n"
>>         "       sc      %0, %1                                  \n"
>>         "       beqz    %0, 1b                                  \n"
>>         : "=&r" (temp), "=m" (v->counter)
>>         : "Ir" (i), "m" (v->counter));
>> }
>> 
>> For the average atomic op generated code is going to look about like:
>> 
>> 80100634:       lui     a0,0x802c
>> 80100638:       ll      a0,-24160(a0)
>> 8010063c:       addu    a0,a0,v0
>> 80100640:       lui     at,0x802c
>> 80100644:       addu    at,at,v1
>> 80100648:       sc      a0,-24160(at)
>> 8010064c:       beqz    a0,80100634 <init+0x194>
>> 80100650:       nop
>> 
>> It's significantly worse for 64-bit due to the excessive code sequence
>> generated for loading a 64-bit address.  One outside CKSEGx that is.
>
>  Only for old compilers.  For current (>= 3.4) ones you can use the "R"  
> constraint and get exactly what you need.

Right.  IMO, this is exactly the right fix.  It should be backward
compatible with old toolchains too.

FYI, the 'R' constraint has been kept around specifically for inline asms.
gcc itself no longer uses it.

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Wed, 1 Dec 2004, Ralf Baechle wrote:
>> On 64-bit the savings would be even more significant.  But what we actually
>> want would be using the "o" constraint.  Which just at least on the
>> compilers where I've tried it, didn't produce code any different from "m".
>
>  No surprise as the "o" constraint doesn't mean anything particular for
> MIPS.  All addresses are offsettable -- there is no addressing mode that
> would preclude it, so "o" is exactly the same as "m".

Right!

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Current 64bit MIPS kernels run in (C)KSEG0, and exploit sign-extension
> to optimize symbol loads (2 instead of 6/7 instructions, the same as in
> 32bit kernels). This optimization relies on an assembler macro
> expansion mode which was hacked in gas for exactly this purpose. Gcc
> currently doesn't have something similiar, and would try to do a regular
> 64bit load with explicit relocs.
>
> I discussed this with Richard Sandiford a while ago, and the conclusion
> was to implement an explicit --msym32 option for both gcc and gas to
> improve register scheduling and get rid of the gas hack. So far, nobody
> came around to actually do the work for it.

True.  FWIW, it's trivial to add this option to gcc.  As far as I remember,
the stumbling block was whether we should mark the objects in some way,
and whether the linker ought to check for overflow.

Richard

From ica2_ts@csv.ica.uni-stuttgart.de Tue Dec  7 12:57:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 12:57:07 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:37942
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225237AbULGM5C>; Tue, 7 Dec 2004 12:57:02 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1Cbeto-00018z-00; Tue, 07 Dec 2004 13:57:00 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1Cbetn-0002mP-00; Tue, 07 Dec 2004 13:56:59 +0100
Date: Tue, 7 Dec 2004 13:56:59 +0100
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	Nigel Stephens <nigel@mips.com>, David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
Message-ID: <20041207125659.GP8714@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201123336.GA5612@linux-mips.org> <Pine.LNX.4.58L.0412012136480.13579@blysk.ds.pg.gda.pl> <wvn653epbi1.fsf@talisman.cambridge.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <wvn653epbi1.fsf@talisman.cambridge.redhat.com>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6582
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Richard Sandiford wrote:
[snip]
> >  Only for old compilers.  For current (>= 3.4) ones you can use the "R"  
> > constraint and get exactly what you need.
> 
> Right.  IMO, this is exactly the right fix.  It should be backward
> compatible with old toolchains too.
> 
> FYI, the 'R' constraint has been kept around specifically for inline asms.
> gcc itself no longer uses it.

I tried to use "R" in atomic.h but this failed in some (but not all)
cases with

include/asm/atomic.h:64: error: inconsistent operand constraints in an asm'

where the argument happens to be a member of a global struct.
Simple testcases work, however, as well as PIC code.

[snip]
> > I discussed this with Richard Sandiford a while ago, and the conclusion
> > was to implement an explicit --msym32 option for both gcc and gas to
> > improve register scheduling and get rid of the gas hack. So far, nobody
> > came around to actually do the work for it.
> 
> True.  FWIW, it's trivial to add this option to gcc.  As far as I remember,
> the stumbling block was whether we should mark the objects in some way,
> and whether the linker ought to check for overflow.

Both might be nice but isn't exactly reqired. The use of --msym32 will
be limited to ELF64 non-PIC code, which is only used in kernels or
other stand-alone programs with limited exposure to other binaries with
incompatible code models.


Thiemo

From toch@dfpost.ru Tue Dec  7 15:42:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 15:42:46 +0000 (GMT)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:64388 "EHLO
	mail.dfpost.ru") by linux-mips.org with ESMTP id <S8225242AbULGPml>;
	Tue, 7 Dec 2004 15:42:41 +0000
Received: from toch.dfpost.ru (toch.dfpost.ru [192.168.7.60])
	by mail.dfpost.ru (Postfix) with SMTP id 21ECF3E517
	for <linux-mips@linux-mips.org>; Tue,  7 Dec 2004 18:37:05 +0300 (MSK)
Date: Tue, 7 Dec 2004 18:42:58 +0300
From: Dmitriy Tochansky <toch@dfpost.ru>
To: linux-mips@linux-mips.org
Subject: mmap problem
Message-Id: <20041207184258.071bf401.toch@dfpost.ru>
Organization: Special Technology Center
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6583
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

Hi!
I try to write small driver to make access to pci device resource from 
userland using mmap.
Code below didnt work. :(
From I module in debug I make some testes - I can read from device registers
but after mmap from userspace I reading just part of memory. :(
Some cache?

CPU - au1500

.....

static unsigned long *offset;

static int mdrv_mmap(struct file * file, struct vm_area_struct *vma)                                   
{                                                                                                      
                                                                                                       
 int ret;                                                                                              
 struct inode *inode;                                                                                  
 inode = file->f_dentry->d_inode;                                                                      
 
 ret = -EINVAL;                                                                                        
 unsigned long start = vma->vm_start;                                                                  
 unsigned long size = (vma->vm_end-vma->vm_start);                                                     
 
 offset = ioremap(0x40000000,0x40);
 
 printk("0x%p\n",__pa(offset));


  printk("lb 0x%X\n",offset[ 0x3C>>2 ] );

  vma->vm_flags |= VM_LOCKED;

  printk("+++++0x%X 0x%X\n",start,size);

  vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
                                   
  ret = remap_page_range( start, 0x40000000, size, vma->vm_page_prot ); //0x40000000 is first iomem range of pci device

  return ret;                                                               
}

struct file_operations mdrv_fops = {
  .open = mdrv_open,
  .release = mdrv_close,
  .read = mdrv_read,
  .write = mdrv_write,
  .mmap = mdrv_mmap
};

....


Here is userland 
#include "mdrv.h"
#include <sys/mman.h>
#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <linux/kernel.h>
#include <string.h>

int fd,fd2;

int
main ()
{

  fd = open("/dev/mboard0",O_RDWR);
  
  unsigned long *x;
  x = mmap(NULL,64,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);

  printf("mmap return: 0x%X",x);

  if(x == MAP_FAILED)
  {
   printf(" it is very bad! :(\n");
   perror("mmap:");
   return -1;
  }
 
  printf(" its ok!\n");

  int i;
  for(i=0;i<16;i++)
  {
  printf(" %d = 0x%X\n",i,x[i]);
  }
  munmap(x,64);
  
  return 0;
}

From dan@embeddededge.com Tue Dec  7 15:57:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 15:57:29 +0000 (GMT)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:14351 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8225242AbULGP5Z>; Tue, 7 Dec 2004 15:57:25 +0000
Received: from [192.168.253.28] (tibook.embeddededge.com [192.168.253.28])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id iB7FiN9f011188;
	Tue, 7 Dec 2004 10:44:23 -0500
In-Reply-To: <20041207184258.071bf401.toch@dfpost.ru>
References: <20041207184258.071bf401.toch@dfpost.ru>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <AD0D6ED2-4868-11D9-BB64-003065F9B7DC@embeddededge.com>
Content-Transfer-Encoding: 7bit
Cc: linux-mips@linux-mips.org
From: Dan Malek <dan@embeddededge.com>
Subject: Re: mmap problem
Date: Tue, 7 Dec 2004 10:57:20 -0500
To: Dmitriy Tochansky <toch@dfpost.ru>
X-Mailer: Apple Mail (2.619)
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: 6584
X-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


On Dec 7, 2004, at 10:42 AM, Dmitriy Tochansky wrote:

>   ret = remap_page_range( start, 0x40000000, size, vma->vm_page_prot 
> ); //

Use io_remap_page_range, it has the same parameters, and is
designed to work with > 32-bit physical addresses.

Also, you should really use pci_resource_* functions to get
information about the pci address, size, etc.  Don't hardcode this,
even for testing.


	-- Dan


From mlachwani@mvista.com Tue Dec  7 16:55:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 16:55:59 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:12271 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225247AbULGQzz>; Tue, 7 Dec 2004 16:55:55 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id 42D40186D7; Tue,  7 Dec 2004 08:55:53 -0800 (PST)
Message-ID: <41B5E098.3070107@mvista.com>
Date: Tue, 07 Dec 2004 08:55:52 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Stickel <michael.stickel@4g-systems.biz>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Ocelot-3 memory configuration patch
References: <20041207003553.GA22456@prometheus.mvista.com> <200412071106.14064.michael.stickel@4g-systems.biz>
In-Reply-To: <200412071106.14064.michael.stickel@4g-systems.biz>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6585
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

Michael Stickel wrote:
> What if the "memsize" PMON variable is not defined?
> Can that happen. Then the memory size is either 0L,
> or an undefined value.
> Shouldn't it be initialized to 128 by default?
> 
> On Tuesday 07 December 2004 01:35, you wrote:
> 
>>Hi Ralf,
>>
>>Based on your suggestion, I have now modified the Ocelot-3 code
>>to probe for memory that has been configured by PMON. Please review ...
>>
>>Thanks
>>Manish Lachwani
> 
> 
memsize is always defined by PMON

Thanks
Manish Lachwani


From rsandifo@redhat.com Tue Dec  7 19:28:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 19:29:06 +0000 (GMT)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:13696 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225247AbULGT2z>;
	Tue, 7 Dec 2004 19:28:55 +0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iB7JScET021320;
	Tue, 7 Dec 2004 14:28:43 -0500
Received: from localhost (mail@vpn50-84.rdu.redhat.com [172.16.50.84])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iB7JSbr19818;
	Tue, 7 Dec 2004 14:28:37 -0500
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1Cbl0l-00009C-00; Tue, 07 Dec 2004 19:28:35 +0000
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	Nigel Stephens <nigel@mips.com>, David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de>
	<16813.39660.948092.328493@doms-laptop.algor.co.uk>
	<20041201123336.GA5612@linux-mips.org>
	<Pine.LNX.4.58L.0412012136480.13579@blysk.ds.pg.gda.pl>
	<wvn653epbi1.fsf@talisman.cambridge.redhat.com>
	<20041207125659.GP8714@rembrandt.csv.ica.uni-stuttgart.de>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Tue, 07 Dec 2004 19:28:35 +0000
In-Reply-To: <20041207125659.GP8714@rembrandt.csv.ica.uni-stuttgart.de> (Thiemo
 Seufer's message of "Tue, 7 Dec 2004 13:56:59 +0100")
Message-ID: <87is7d3o2k.fsf@redhat.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
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: 6586
X-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

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> I tried to use "R" in atomic.h but this failed in some (but not all)
> cases with
>
> include/asm/atomic.h:64: error: inconsistent operand constraints in an asm'
>
> where the argument happens to be a member of a global struct.

Doh!  Do you have any testcases handy?  Was it failing with >= 3.4,
or with older toolchains?  3.4 and above should know that 'R' is a
memory-type constraint.

Richard

From savl@dev.rtsoft.ru Tue Dec  7 19:48:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 19:48:20 +0000 (GMT)
Received: from RT-soft-2.Moscow.itn.ru ([IPv6:::ffff:80.240.96.70]:154 "HELO
	mail.dev.rtsoft.ru") by linux-mips.org with SMTP
	id <S8225247AbULGTsQ>; Tue, 7 Dec 2004 19:48:16 +0000
Received: (qmail 24609 invoked from network); 7 Dec 2004 19:21:42 -0000
Received: from unknown (HELO dev.rtsoft.ru) (192.168.1.199)
  by mail.dev.rtsoft.ru with SMTP; 7 Dec 2004 19:21:42 -0000
Message-ID: <41B608FD.7070209@dev.rtsoft.ru>
Date: Tue, 07 Dec 2004 22:48:13 +0300
From: Pavel Kiryukhin <savl@dev.rtsoft.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
CC: Pavel Kiryukhin <savl@dev.rtsoft.ru>
Subject: i/o and memory space enable bits in PCI-PCI bridge 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <savl@dev.rtsoft.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6587
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: savl@dev.rtsoft.ru
Precedence: bulk
X-list: linux-mips

Hi!
Can somebody give me a hint:  - what part of 2.6 (mips) code is 
responsible for setting i/o and memory space enable bits in PCI-PCI 
bridge config. space command register?
On my board those bits are not set after bridge is configured.
Currently I'm using the following change in "pcibios_enable_resources" 
to work with devices behind the bridge.
--- arch/mips/pci/pci.c_org    2004-12-06 18:20:50.000000000 +0300
+++ arch/mips/pci/pci.c    2004-12-06 18:21:22.000000000 +0300
@@ -164,7 +164,7 @@

    pci_read_config_word(dev, PCI_COMMAND, &cmd);
    old_cmd = cmd;
-    for(idx=0; idx<6; idx++) {
+    for(idx=0; idx<=PCI_BRIDGE_RESOURCES; idx++) {
        /* Only set up the requested stuff */
        if (!(mask & (1<<idx)))
            continue;

but I think there should be some legal way I missed.
--
Thank you,
Pavel Kiryukhin.




From klessard@sunrisetelecom.com Tue Dec  7 19:52:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 19:52:27 +0000 (GMT)
Received: from 67-121-164-6.ded.pacbell.net ([IPv6:::ffff:67.121.164.6]:9863
	"EHLO mailserver.sunrisetelecom.com") by linux-mips.org with ESMTP
	id <S8225247AbULGTwW>; Tue, 7 Dec 2004 19:52:22 +0000
Received: from there ([192.168.50.222]) by mailserver.sunrisetelecom.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 7 Dec 2004 11:52:11 -0800
Content-Type: text/plain;
  charset="iso-8859-1"
From: Karl Lessard <klessard@sunrisetelecom.com>
To: =?iso-8859-1?q?J=F8rg=20Ulrich=20Hansen?= <jh@hansen-telecom.dk>
Subject: Re: au1100fb.c
Date: Tue, 7 Dec 2004 14:49:37 -0500
X-Mailer: KMail [version 1.3.2]
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAb4ajDk58bkCNi0V1ZTQFHIKAAAAQAAAAqiO8dTCmGkSJ6ESla6aONAEAAAAA@hansen-telecom.dk>
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAb4ajDk58bkCNi0V1ZTQFHIKAAAAQAAAAqiO8dTCmGkSJ6ESla6aONAEAAAAA@hansen-telecom.dk>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <MAILSERVEREI2rV4Zne000005cb@mailserver.sunrisetelecom.com>
X-OriginalArrivalTime: 07 Dec 2004 19:52:11.0437 (UTC) FILETIME=[3DDDD5D0:01C4DC96]
Return-Path: <klessard@sunrisetelecom.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: 6588
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: klessard@sunrisetelecom.com
Precedence: bulk
X-list: linux-mips

On December 7, 2004 03:38 am, you wrote:
> Hi Karl
>
> Thanks for the software. I have now added my tft and mono display to the
> driver.
> It works fine with a few changes.
> For the mono no memory was allocated for the framebuffer because the
> calculation gave 0 bytes:
> 	fbdev->fb_len = fbdev->panel->max_xres * fbdev->panel->max_yres *
> 		  	(fbdev->panel->max_bpp >> 3) *
> AU1100FB_NBR_VIDEO_BUFFERS;

You're right. As I told you, the driver needs to be tested in many 
configuration and for many boards, I have only done simple tests. Thanks for 
your notice!

> It also seems that for the tft to much is allocated.
> I have to look more into that.
> What is AU1100FB_NBR_VIDEO_BUFFERS used for?

It is because in our case (at sunrise), we use back buffers and want  to 
retrieve it by an offset from the front buffer. In the repository, 
AU1100FB_NBR_VIDEO_BUFFERS should be set to 1 (sorry if I forgot to change it 
in the patch), but it allows programmers to allocate one, two, or more back 
buffers by incrementing it.

> For mono the tux logo does not come up, and if I disable the logo then the
> framebuffer will not be initialized.
> Do I then have to do something manually?

The mono logo works well for me though. The driver turns up the monitor at 
bootup only in two cases for now: you are using the framebuffer console, or 
you don't use the fb console but still want the logo to show up.

> I have added au1100fb_ioctl so I can control the contrast/pwm for my mono
> display.
> I also had to change the clock settings. My board came up with a different
> clock rate.
>
> It looks good I think It should be added to the repository. Not just
> because of the small tests I have made but because it is there and it works
> better than what is already there.
> Is it Pete Popov that has to add it?

Pete just send me a mail saying that he is about to test the code and submit 
it.

Thanks,
Karl

>
> Kind regards Jorg
>
> --------------<<<<<<<<<OOOOOOOO>>>>>>>>>--------------
> Jorg Hansen               email: jh@hansen-telecom.dk
> Hansen Telecom            Tel: +45 7342 0220
> Ellegaardvej 36           Fax: +45 7342 0221
> 6400 Sonderborg           Mob: +45 2819 1969
> Denmark                   http://www.hansen-telecom.dk
>
> Modules for rapid design of mechatronic products
>        http://www.mechatronicbrick.dk
> --------------<<<<<<<<<OOOOOOOO>>>>>>>>>--------------
>
>
> -----Original Message-----
> From: Karl Lessard (by way of Karl Lessard <klessard@sunrisetelecom.com>)
> [mailto:klessard@sunrisetelecom.com]
> Sent: 2. december 2004 16:44
> To: Jørg Ulrich Hansen
> Cc: linux-mips@linux-mips.org
> Subject: Re: au1100fb.c
>
>
> Hi Jørg,
>
> I've modified it a little bit since I've post it on the list, so here's the
> .c/.h files I use now, and a patch that should also apply. This should work
> with current linux-mips cvs (actually it do on a 22/11/04 snapshot).
>
> I've never tested it on other boards that the pb1100 though. Also, I use
> the same scheme as in Linux 2.4, i.e. panels supported are declared in
> au1100fb.h.
>
> I hope this will work for you, and don't hesitate to interrupt me if you
> have any questions/problems. We personnally decided to work with a
> different
>
> graphic chip, so I probably don't need your version of the driver but
> thanks
>
> for offering it!
>
> Regards,
> Karl
>
>
>
> Jørg Ulrich Hansen wrote:
>
> Hi Karl
>
> Sorry to disturb you, but I can see that you have a framebuffer for au1100
> for Linux 2.6. I have also done the same work but I have some problems with
> nano-X that I belive is the framebuffers fault.
>
> Your patch that I found on the list I am having problems with to apply.
>
> Do you mind to send me your version of the framebuffer either directly or
> to the list.
>
> If you are interrested you can have my version of au1100fb.c/h as well.
>
> Kind regards Jorg
>
> --------------<<<<<<<<<OOOOOOOO>>>>>>>>>--------------
> Jorg Hansen               email: jh@hansen-telecom.dk
> Hansen Telecom            Tel: +45 7342 0220
> Ellegaardvej 36           Fax: +45 7342 0221
> 6400 Sonderborg           Mob: +45 2819 1969
> Denmark                   http://www.hansen-telecom.dk
>
> Modules for rapid design of mechatronic products
>        http://www.mechatronicbrick.dk
> --------------<<<<<<<<<OOOOOOOO>>>>>>>>>--------------

From ralf@linux-mips.org Tue Dec  7 20:54:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Dec 2004 20:54:25 +0000 (GMT)
Received: from pD9562292.dip.t-dialin.net ([IPv6:::ffff:217.86.34.146]:24497
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225253AbULGUyU>; Tue, 7 Dec 2004 20:54:20 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iB7KsHUW028575;
	Tue, 7 Dec 2004 21:54:17 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iB7KsH8k028573;
	Tue, 7 Dec 2004 21:54:17 +0100
Date: Tue, 7 Dec 2004 21:54:17 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Pavel Kiryukhin <savl@dev.rtsoft.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: i/o and memory space enable bits in PCI-PCI bridge
Message-ID: <20041207205417.GC13264@linux-mips.org>
References: <41B608FD.7070209@dev.rtsoft.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41B608FD.7070209@dev.rtsoft.ru>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6589
X-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, Dec 07, 2004 at 10:48:13PM +0300, Pavel Kiryukhin wrote:

> Can somebody give me a hint:  - what part of 2.6 (mips) code is 
> responsible for setting i/o and memory space enable bits in PCI-PCI 
> bridge config. space command register?
> On my board those bits are not set after bridge is configured.
> Currently I'm using the following change in "pcibios_enable_resources" 
> to work with devices behind the bridge.
> --- arch/mips/pci/pci.c_org    2004-12-06 18:20:50.000000000 +0300
> +++ arch/mips/pci/pci.c    2004-12-06 18:21:22.000000000 +0300
> @@ -164,7 +164,7 @@
> 
>    pci_read_config_word(dev, PCI_COMMAND, &cmd);
>    old_cmd = cmd;
> -    for(idx=0; idx<6; idx++) {
> +    for(idx=0; idx<=PCI_BRIDGE_RESOURCES; idx++) {
>        /* Only set up the requested stuff */
>        if (!(mask & (1<<idx)))
>            continue;
> 
> but I think there should be some legal way I missed.

We had a discussion a while ago where somebody did suggest an afair
identical patch a while ago.  The problem with this patch is it fixes
things for a few platforms and breaks things for a few others.

  Ralf

From ica2_ts@csv.ica.uni-stuttgart.de Wed Dec  8 00:10:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 00:10:07 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:20031
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225261AbULHAKB>; Wed, 8 Dec 2004 00:10:01 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CbpP5-0006tN-00; Wed, 08 Dec 2004 01:09:59 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CbpP4-0004dG-00; Wed, 08 Dec 2004 01:09:58 +0100
Date: Wed, 8 Dec 2004 01:09:58 +0100
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	Nigel Stephens <nigel@mips.com>, David Ung <davidu@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
Message-ID: <20041208000958.GS8714@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201123336.GA5612@linux-mips.org> <Pine.LNX.4.58L.0412012136480.13579@blysk.ds.pg.gda.pl> <wvn653epbi1.fsf@talisman.cambridge.redhat.com> <20041207125659.GP8714@rembrandt.csv.ica.uni-stuttgart.de> <87is7d3o2k.fsf@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87is7d3o2k.fsf@redhat.com>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6590
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Richard Sandiford wrote:
> Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> > I tried to use "R" in atomic.h but this failed in some (but not all)
> > cases with
> >
> > include/asm/atomic.h:64: error: inconsistent operand constraints in an asm'
> >
> > where the argument happens to be a member of a global struct.
> 
> Doh!  Do you have any testcases handy?

So far only the whole kernel, which isn't exactly handy.

> Was it failing with >= 3.4,
> or with older toolchains?  3.4 and above should know that 'R' is a
> memory-type constraint.

I saw the same failure for 3.3 and 3.4, I haven't tried 4.0.


Thiemo

From alexshinkin@hotmail.com Wed Dec  8 07:29:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 07:29:34 +0000 (GMT)
Received: from bay15-f22.bay15.hotmail.com ([IPv6:::ffff:65.54.185.22]:31180
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8224942AbULHH33>; Wed, 8 Dec 2004 07:29:29 +0000
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 7 Dec 2004 23:29:01 -0800
Message-ID: <BAY15-F22AE91D0812E86B5F51579AFB60@phx.gbl>
Received: from 82.200.0.252 by by15fd.bay15.hotmail.msn.com with HTTP;
	Wed, 08 Dec 2004 07:28:30 GMT
X-Originating-IP: [82.200.0.252]
X-Originating-Email: [alexshinkin@hotmail.com]
X-Sender: alexshinkin@hotmail.com
From: "Alexey Shinkin" <alexshinkin@hotmail.com>
To: toch@dfpost.ru
Cc: linux-mips@linux-mips.org
Subject: Re: mmap problem
Date: Wed, 08 Dec 2004 13:28:30 +0600
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 08 Dec 2004 07:29:01.0439 (UTC) FILETIME=[9691D8F0:01C4DCF7]
Return-Path: <alexshinkin@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: 6591
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alexshinkin@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi !

On Au1550 code like yours works

I use ioremap_nocache(PhysAddr,length)  to get access from kernel level.

For access from  userland I don't set any vm_flags in drivers' mmap() ,
  vma->vm_flags is set by kernel to  0x40FB (VM_IO is set and VM_LOCKED 
isn't).

And , as Dan said , pci_resource_* functions used for getting valid PCI 
memory address

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


From toch@dfpost.ru Wed Dec  8 07:35:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 07:35:28 +0000 (GMT)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:34733 "EHLO
	mail.dfpost.ru") by linux-mips.org with ESMTP id <S8224942AbULHHfY>;
	Wed, 8 Dec 2004 07:35:24 +0000
Received: from toch.dfpost.ru (toch.dfpost.ru [192.168.7.60])
	by mail.dfpost.ru (Postfix) with SMTP id 577903E517
	for <linux-mips@linux-mips.org>; Wed,  8 Dec 2004 10:29:45 +0300 (MSK)
Date: Wed, 8 Dec 2004 10:35:42 +0300
From: Dmitriy Tochansky <toch@dfpost.ru>
To: linux-mips@linux-mips.org
Subject: Re: mmap problem
Message-Id: <20041208103542.6964f84f.toch@dfpost.ru>
In-Reply-To: <BAY15-F22AE91D0812E86B5F51579AFB60@phx.gbl>
References: <BAY15-F22AE91D0812E86B5F51579AFB60@phx.gbl>
Organization: Special Technology Center
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6592
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

On Wed, 08 Dec 2004 13:28:30 +0600
"Alexey Shinkin" <alexshinkin@hotmail.com> wrote:

> Hi !
> 
> On Au1550 code like yours works
> 
> I use ioremap_nocache(PhysAddr,length)  to get access from kernel
> level.
  Yes, it works. Even just ioremap()
 
> For access from  userland I don't set any vm_flags in drivers' mmap()
> ,
>   vma->vm_flags is set by kernel to  0x40FB (VM_IO is set and
>   VM_LOCKED isn't).
  I tryed it - same result. :(

> 
> And , as Dan said , pci_resource_* functions used for getting valid
> PCI memory address
  Done! :)

From toch@dfpost.ru Wed Dec  8 07:39:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 07:40:04 +0000 (GMT)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:38318 "EHLO
	mail.dfpost.ru") by linux-mips.org with ESMTP id <S8225230AbULHHj7>;
	Wed, 8 Dec 2004 07:39:59 +0000
Received: from toch.dfpost.ru (toch.dfpost.ru [192.168.7.60])
	by mail.dfpost.ru (Postfix) with SMTP id 14A6D3E517;
	Wed,  8 Dec 2004 10:34:21 +0300 (MSK)
Date: Wed, 8 Dec 2004 10:40:17 +0300
From: Dmitriy Tochansky <toch@dfpost.ru>
To: Dan Malek <dan@embeddededge.com>
Cc: linux-mips@linux-mips.org
Subject: Re: mmap problem
Message-Id: <20041208104017.2f71acc2.toch@dfpost.ru>
In-Reply-To: <AD0D6ED2-4868-11D9-BB64-003065F9B7DC@embeddededge.com>
References: <20041207184258.071bf401.toch@dfpost.ru>
	<AD0D6ED2-4868-11D9-BB64-003065F9B7DC@embeddededge.com>
Organization: Special Technology Center
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6593
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

On Tue, 7 Dec 2004 10:57:20 -0500
Dan Malek <dan@embeddededge.com> wrote:

> >   ret = remap_page_range( start, 0x40000000, size, vma->vm_page_prot
> >   
> > ); //
> 
> Use io_remap_page_range, it has the same parameters, and is
> designed to work with > 32-bit physical addresses.
  Well, I test it. On module load - unresolved symbol remap_page_range_high. I looking for some ifdefs
where this function blocked, but seems like everithing is ok. :(

> 
> Also, you should really use pci_resource_* functions to get
> information about the pci address, size, etc.  Don't hardcode this,
> even for testing.

There is a new variant. If I by hand make io_remap_page_range visible - system hangs. :(
  

#define MAX_DEV 4

struct pci_dev *devs[MAX_DEV];
struct pci_dev *dev = NULL;

...

static unsigned long *offset;

static int mdrv_mmap(struct file * file, struct vm_area_struct *vma)                                   
{                                                                                                      
                                                                                                       
 int ret;                                                                                              
 struct inode *inode;                                                                                  
 inode = file->f_dentry->d_inode;                                                                      
 
 ret = -EINVAL;                                                                                        
 unsigned long start = vma->vm_start;                                                                  
 unsigned long size = (vma->vm_end-vma->vm_start);                                                     
 
 struct pci_dev *curdev = NULL;
 
 int minor = MINOR(inode->i_rdev);
 
 printk("minor = %d\n",minor);
 
 curdev = (devs[minor]);
 
 offset = (unsigned long *)pci_resource_start(curdev,0);
 
 printk("offset = 0x%X\n", offset );

 ret = io_remap_page_range( start, offset, size, vma->vm_page_prot );

 return ret;                                                               
}


From wlacey@goldenhindresearch.com Wed Dec  8 12:14:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 12:14:14 +0000 (GMT)
Received: from server212.com ([IPv6:::ffff:203.194.159.163]:45737 "HELO
	server212.com") by linux-mips.org with SMTP id <S8225271AbULHMOJ>;
	Wed, 8 Dec 2004 12:14:09 +0000
Received: (qmail 31032 invoked by uid 2003); 8 Dec 2004 12:14:22 -0000
Message-ID: <20041208121422.18641.qmail@server212.com>
Reply-To: "wlacey" <wlacey@goldenhindresearch.com>
From: "wlacey" <wlacey@goldenhindresearch.com>
To: linux-mips@linux-mips.org
Subject: 2.6 kernel & ide_ops
Date: Wed, 08 Dec 2004 12:14:22 
MIME-Version: 1.0
X-Mailer: WebMail 2.0
X-Originating-IP: 67.149.145.76
X-Originating-Email: wlacey@goldenhindresearch.com
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Return-Path: <wlacey@goldenhindresearch.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: 6594
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wlacey@goldenhindresearch.com
Precedence: bulk
X-list: linux-mips

Forgive the stupid question but on the 2.6 kernel I cannot find an ide_ops.h header file and obviously the extern ide_ops structure.

How should one go about specifiying an ide device in a 2.6 kernel

Thanks,
W

From alan@lxorguk.ukuu.org.uk Wed Dec  8 13:04:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 13:04:27 +0000 (GMT)
Received: from clock-tower.bc.nu ([IPv6:::ffff:81.2.110.250]:32211 "EHLO
	localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225281AbULHNEW>; Wed, 8 Dec 2004 13:04:22 +0000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.12.11/8.12.11) with ESMTP id iB8C0m8A023916;
	Wed, 8 Dec 2004 12:00:48 GMT
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id iB8C0lx8023915;
	Wed, 8 Dec 2004 12:00:47 GMT
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: 2.6 kernel & ide_ops
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: wlacey <wlacey@goldenhindresearch.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20041208121422.18641.qmail@server212.com>
References: <20041208121422.18641.qmail@server212.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1102507245.23635.12.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Wed, 08 Dec 2004 12:00:46 +0000
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: 6595
X-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 Mer, 2004-12-08 at 12:14, wlacey wrote:
> Forgive the stupid question but on the 2.6 kernel I cannot find an ide_ops.h header file and obviously the extern ide_ops structure.
> 

The ide ops are part of the hwif (hardware interface) object.

> How should one go about specifiying an ide device in a 2.6 kernel

Assuming the device has standard behaviour and is just basic legacy IDE
then

	ide_hwif_t *hwif;
	hw_reg_t hw;

	memset(hw, 0, sizeof(*hw));
	ide_std_init_ports(&hw, IDE_PORT, CTRL__PORT);
	hw.irq = whatever;
	hw.dma = NO_DMA;

	ide_register_hw(&hw, NULL);

For DMA devices you need either to use the PCI layer functions or
register DMA handlers. Take a look at something simple like
drivers/ide/pci/triflex.c


From yuasa@hh.iij4u.or.jp Wed Dec  8 14:37:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 14:38:05 +0000 (GMT)
Received: from mfo06.iij.ad.jp ([IPv6:::ffff:210.130.1.94]:38599 "EHLO
	mfo06.iij.ad.jp") by linux-mips.org with ESMTP id <S8225296AbULHOh7>;
	Wed, 8 Dec 2004 14:37:59 +0000
Received: MFO(mfo06) for <linux-mips@linux-mips.org> id iB8E6xr6021158; Wed, 8 Dec 2004 23:06:59 +0900 (JST)
Received: MO(mo00) for <linux-mips@linux-mips.org> id iB8E6l0T010344; Wed, 8 Dec 2004 23:06:48 +0900 (JST)
Received: MDO(mdo01) id iB8E6lYi027037; Wed, 8 Dec 2004 23:06:47 +0900 (JST)
Received: 4UMRO00 id iB8E6ksM001286; Wed, 8 Dec 2004 23:06:47 +0900 (JST)
	from stratos (localhost [127.0.0.1])
	for <linux-mips@linux-mips.org>; (authenticated)
Date: Wed, 8 Dec 2004 23:06:45 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: linux-mips <linux-mips@linux-mips.org>
Subject: early_initcall
Message-Id: <20041208230645.7f1c33e8.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.0beta3 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6596
X-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

Hi,

Since early_initcall is not defined in generic 2.6.10-rc3,
MIPS has a problem in generic kernel.

I investigated why early_initcall is not defined in generic kernel.
I found a following mail in LKML.

We need to move early_initcall to MIPS-specific header file.
Where do you think is a suitable header file for it?

Yoichi

---- Andrew's comment ----
From: Andrew Morton <akpm@osdl.org>
To: Samium Gromoff <deepfire@sic-elvis.zel.ru>
Cc: linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [2.6.5][MIPS] oneliners somehow not made it into mainline [3/3]
Date: 	Mon, 12 Apr 2004 14:06:28 -0700
Sender: linux-kernel-owner@vger.kernel.org
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu)

Samium Gromoff <deepfire@sic-elvis.zel.ru> wrote:
>
> Without this one it fails to run the earlyinitcall stuff, and hence
> explodes at some point.
> 
> diff -urN -X './#cdiff.pattern' ./linux-2.6.5/include/linux/init.h ./mc-2.6.5/include/linux/init.h
> --- ./linux-2.6.5/include/linux/init.h  2004-04-12 16:07:45.000000000 +0400
> +++ ./mc-2.6.5/include/linux/init.h     2004-04-12 18:05:28.000000000 +0400
> @@ -83,6 +83,7 @@
>         static initcall_t __initcall_##fn __attribute_used__ \
>         __attribute__((__section__(".initcall" level ".init"))) = fn
> 
> +#define early_initcall(fn)             __define_initcall(".early1",fn)
>  #define core_initcall(fn)              __define_initcall("1",fn)
>  #define postcore_initcall(fn)          __define_initcall("2",fn)
>  #define arch_initcall(fn)              __define_initcall("3",fn)

early_initcall() is a mips-specific thing.  If we add this macro to
<linux/init.h> then someone will use it in generic code and all the other
architectures explode.

We need to either make this entirely mips-private, or rework the mips code
to not use it at all, or justify its introduction and then introduce it for
all architectures.


From klessard@sunrisetelecom.com Wed Dec  8 16:09:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 16:09:06 +0000 (GMT)
Received: from 67-121-164-6.ded.pacbell.net ([IPv6:::ffff:67.121.164.6]:7357
	"EHLO mailserver.sunrisetelecom.com") by linux-mips.org with ESMTP
	id <S8225305AbULHQJB>; Wed, 8 Dec 2004 16:09:01 +0000
Received: from there ([192.168.50.222]) by mailserver.sunrisetelecom.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 8 Dec 2004 08:08:51 -0800
Content-Type: text/plain;
  charset="iso-8859-1"
From: Karl Lessard <klessard@sunrisetelecom.com>
To: linux-mips@linux-mips.org
Subject: Epson13806 performances on Pb1100
Date: Wed, 8 Dec 2004 11:06:14 -0500
X-Mailer: KMail [version 1.3.2]
Cc: ppopov@embeddedalley.com
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <MAILSERVERUhrBb0aCQ0000084e@mailserver.sunrisetelecom.com>
X-OriginalArrivalTime: 08 Dec 2004 16:08:51.0386 (UTC) FILETIME=[353A11A0:01C4DD40]
Return-Path: <klessard@sunrisetelecom.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: 6597
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: klessard@sunrisetelecom.com
Precedence: bulk
X-list: linux-mips

Hi all,

I'm currently developping on a Pb1100 alchemy board, and I use the Epson 
13806 graphic controller connected to the Au1100 static bus. I've written a 
driver for it for kernel 2.6.x, and update the Au1100 code so I can access 
0xE 0000 0000 address range.

Everything works fine, but for the speed. It seems that accessing the chip is 
too slow for having high-graphic performances. The LCLK is set at 49500KHz, 
as the memory clock inside the chip. I know it's a bit overclocked, but a 
lower LCLK freezes my system.

I would like to know if anyone have encountered this performance problem in 
the past with this chip.

Thanks in advance,
Karl

From toch@dfpost.ru Wed Dec  8 16:39:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 16:39:57 +0000 (GMT)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:44957 "EHLO
	mail.dfpost.ru") by linux-mips.org with ESMTP id <S8225305AbULHQjv>;
	Wed, 8 Dec 2004 16:39:51 +0000
Received: from toch.dfpost.ru (toch.dfpost.ru [192.168.7.60])
	by mail.dfpost.ru (Postfix) with SMTP id A823A3E517
	for <linux-mips@linux-mips.org>; Wed,  8 Dec 2004 19:34:10 +0300 (MSK)
Date: Wed, 8 Dec 2004 19:40:14 +0300
From: Dmitriy Tochansky <toch@dfpost.ru>
To: linux-mips@linux-mips.org
Subject: mmap problem another :)
Message-Id: <20041208194014.1302df6f.toch@dfpost.ru>
Organization: Special Technology Center
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6598
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

Ok. I did as you say and got that mmap func:

static int
mdrv_mmap (struct file *file, struct vm_area_struct *vma)
{
  unsigned long offset = 0;
  int ret;
  struct inode *inode;
  inode = file->f_dentry->d_inode;

  struct pci_dev *curdev = NULL;

  int minor = MINOR (inode->i_rdev);
  
  printk("minor = 0x%X\n",minor);

  curdev = (devs[minor]);

  unsigned long start = vma->vm_start;
  unsigned long size = (vma->vm_end - vma->vm_start);
  offset = pci_resource_start (curdev, IOMEM0);
  
  printk("offset = 0x%X\n",(unsigned int)offset);

  ret = remap_page_range_high (start, offset, size, vma->vm_page_prot);
  
  return ret;
}

And it works fine but... but when I try to do mmap not /dev/mboard0 but /dev/mboard1 Im again
have the "bad" result. :( Is there something specific to mmap several devices?

From dan@embeddededge.com Wed Dec  8 16:40:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 16:40:48 +0000 (GMT)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:26884 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8225305AbULHQkm>; Wed, 8 Dec 2004 16:40:42 +0000
Received: from [192.168.253.28] (tibook.embeddededge.com [192.168.253.28])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id iB8GRV9f014690;
	Wed, 8 Dec 2004 11:27:31 -0500
In-Reply-To: <MAILSERVERUhrBb0aCQ0000084e@mailserver.sunrisetelecom.com>
References: <MAILSERVERUhrBb0aCQ0000084e@mailserver.sunrisetelecom.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E304EFD0-4937-11D9-81C3-003065F9B7DC@embeddededge.com>
Content-Transfer-Encoding: 7bit
Cc: linux-mips@linux-mips.org, ppopov@embeddedalley.com
From: Dan Malek <dan@embeddededge.com>
Subject: Re: Epson13806 performances on Pb1100
Date: Wed, 8 Dec 2004 11:40:36 -0500
To: Karl Lessard <klessard@sunrisetelecom.com>
X-Mailer: Apple Mail (2.619)
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: 6599
X-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


On Dec 8, 2004, at 11:06 AM, Karl Lessard wrote:

> Everything works fine, but for the speed. It seems that accessing the 
> chip is
> too slow for having high-graphic performances.

A couple of things.  First, the Epson controller is obsolete, I don't
know how much time is worth spending on the software.  If you
don't already have a system in production using it, there isn't
much sense spending time working with it.

Second, with the on-chip controller, I have experimented with
some different cache modes for the frame buffer access.  I
don't know if this applicable to the external 13806, but you
could try.  Alchemy has an application note on this, I believe,
but in any case, here is what I put into the au1100fb.c,
au1100fb_mmap() function:

pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK;
pgprot_val(vma->vm_page_prot) |= _CACHE_CACHABLE_CUW;

A similar kind of update is in the current CVS tree.

Fujitsu has a bunch of nice high performance embedded
graphics controllers for many different applications.


	-- Dan


From dan@embeddededge.com Wed Dec  8 17:27:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 17:27:14 +0000 (GMT)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:37892 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8225305AbULHR1K>; Wed, 8 Dec 2004 17:27:10 +0000
Received: from [192.168.253.28] (tibook.embeddededge.com [192.168.253.28])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id iB8HDv9f014848;
	Wed, 8 Dec 2004 12:13:58 -0500
In-Reply-To: <20041208194014.1302df6f.toch@dfpost.ru>
References: <20041208194014.1302df6f.toch@dfpost.ru>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5FE01AB3-493E-11D9-81C3-003065F9B7DC@embeddededge.com>
Content-Transfer-Encoding: 7bit
Cc: linux-mips@linux-mips.org
From: Dan Malek <dan@embeddededge.com>
Subject: Re: mmap problem another :)
Date: Wed, 8 Dec 2004 12:27:02 -0500
To: Dmitriy Tochansky <toch@dfpost.ru>
X-Mailer: Apple Mail (2.619)
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: 6600
X-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


On Dec 8, 2004, at 11:40 AM, Dmitriy Tochansky wrote:

>   ret = remap_page_range_high (start, offset, size, vma->vm_page_prot);

Hmmm....this is in 2.4?  Did you apply all of the 36-bit IO
patch as Pete Popov has mentioned in past e-mail messages?
Did you make sure you enabled CONFIG_64BIT_PHYS_ADDR?

I know this does work.  In fact, you should just use
io_remap_page_range().  If that doesn't work, something
is wrong with the kernel configuration.

	-- Dan


From gmuruga@gdatech.com Wed Dec  8 17:47:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 17:47:13 +0000 (GMT)
Received: from darwaza.gdatech.com ([IPv6:::ffff:66.237.41.98]:53575 "EHLO
	kings.gdatech.com") by linux-mips.org with ESMTP
	id <S8225305AbULHRrI>; Wed, 8 Dec 2004 17:47:08 +0000
Received: from kings.gdatech.com (localhost.localdomain [127.0.0.1])
	by kings.gdatech.com (Postfix) with ESMTP id C39DA61C0D4
	for <linux-mips@linux-mips.org>; Wed,  8 Dec 2004 09:42:04 -0800 (PST)
X-Propel-Return-Path: <gmuruga@gdatech.com>
Received: from kings.gdatech.com ([192.168.200.118])
	by localhost.localdomain ([127.0.0.1]) (port 7027) (Propel SE relay 0.1.0.1557 $Rev$)
	id r4cH094204-0291-1
	for linux-mips@linux-mips.org; Wed, 08 Dec 2004 09:42:04 -0800
Received: from sierra.gdatech.com (asg_mda [192.168.200.112])
	by kings.gdatech.com (Postfix) with ESMTP id 911B161C0D3
	for <linux-mips@linux-mips.org>; Wed,  8 Dec 2004 09:42:04 -0800 (PST)
Received: (from nobody@localhost)
	by gdatech.com (8.11.6/8.11.6) id iB8Hgpp31261;
	Wed, 8 Dec 2004 09:42:51 -0800
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: gdatech.com
Date: Wed, 8 Dec 2004 09:42:51 -0800
Message-Id: <200412081742.iB8Hgpp31261@gdatech.com>
X-Authentication-Warning: sierra.gdatech.com: nobody set sender to gmuruga@gdatech.com using -f
From: "Muruga Ganapathy" <gmuruga@gdatech.com>
To: linux-mips@linux-mips.org
Subject: Forcing IDE to work in PIO mode
X-Mailer: NeoMail 1.25
X-IPAddress: 63.111.213.196
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Return-Path: <gmuruga@gdatech.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: 6601
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gmuruga@gdatech.com
Precedence: bulk
X-list: linux-mips

Hello, 

How do I force the IDE to work in the PIO mode by including the 
option like "hdb=noprobe" in the setup.c?


My kernel version is 2.6.6

Thanks
G.Muruganandam

From mlachwani@mvista.com Wed Dec  8 17:52:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 17:52:42 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:8176 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225305AbULHRwh>; Wed, 8 Dec 2004 17:52:37 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id 81F9C1865E; Wed,  8 Dec 2004 09:52:34 -0800 (PST)
Message-ID: <41B73F62.40007@mvista.com>
Date: Wed, 08 Dec 2004 09:52:34 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Muruga Ganapathy <gmuruga@gdatech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Forcing IDE to work in PIO mode
References: <200412081742.iB8Hgpp31261@gdatech.com>
In-Reply-To: <200412081742.iB8Hgpp31261@gdatech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6602
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

Muruga Ganapathy wrote:
> Hello, 
> 
> How do I force the IDE to work in the PIO mode by including the 
> option like "hdb=noprobe" in the setup.c?
> 
> 
> My kernel version is 2.6.6
> 
> Thanks
> G.Muruganandam
> 

Hello !

I would have thought "ide=nodma" at the command line would have worked

Thanks
Manish Lachwani


From ppopov@embeddedalley.com Wed Dec  8 18:06:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 18:06:06 +0000 (GMT)
Received: from pimout1-ext.prodigy.net ([IPv6:::ffff:207.115.63.77]:40437 "EHLO
	pimout1-ext.prodigy.net") by linux-mips.org with ESMTP
	id <S8225305AbULHSGA>; Wed, 8 Dec 2004 18:06:00 +0000
Received: from 127.0.0.1 (adsl-68-124-224-225.dsl.snfc21.pacbell.net [68.124.224.225])
	by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id iB8I5s6M184356
	for <linux-mips@linux-mips.org>; Wed, 8 Dec 2004 13:05:54 -0500
Received: from  [63.194.214.47] by 127.0.0.1
  (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.7)); Wed, 8 Dec 2004 10:07:51 -0800
Message-ID: <41B7426A.2040502@embeddedalley.com>
Date: Wed, 08 Dec 2004 10:05:30 -0800
From: Pete Popov <ppopov@embeddedalley.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Karl Lessard <klessard@sunrisetelecom.com>
CC: linux-mips@linux-mips.org
Subject: Re: Epson13806 performances on Pb1100
References: <MAILSERVERUhrBb0aCQ0000084e@mailserver.sunrisetelecom.com>
In-Reply-To: <MAILSERVERUhrBb0aCQ0000084e@mailserver.sunrisetelecom.com>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ArGoMail-Authenticated: ppopov@embeddedalley.com
Return-Path: <ppopov@embeddedalley.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: 6603
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips

Karl Lessard wrote:
> Hi all,
> 
> I'm currently developping on a Pb1100 alchemy board, and I use the Epson 
> 13806 graphic controller connected to the Au1100 static bus. I've written a 
> driver for it for kernel 2.6.x, and update the Au1100 code so I can access 
> 0xE 0000 0000 address range.
> 
> Everything works fine, but for the speed. It seems that accessing the chip is 
> too slow for having high-graphic performances. The LCLK is set at 49500KHz, 
> as the memory clock inside the chip. I know it's a bit overclocked, but a 
> lower LCLK freezes my system.

I've used the chip with the 2.4 kernel/driver to run X and some 
apps. I'm not sure what you mean by high performance -- does X run 
at reasonable speeds?

Pete

> I would like to know if anyone have encountered this performance problem in 
> the past with this chip.
> 
> Thanks in advance,
> Karl
> 
> 



From ppopov@embeddedalley.com Wed Dec  8 18:21:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 18:21:15 +0000 (GMT)
Received: from pimout3-ext.prodigy.net ([IPv6:::ffff:207.115.63.102]:7333 "EHLO
	pimout3-ext.prodigy.net") by linux-mips.org with ESMTP
	id <S8225322AbULHSVK>; Wed, 8 Dec 2004 18:21:10 +0000
Received: from 127.0.0.1 (adsl-68-124-224-225.dsl.snfc21.pacbell.net [68.124.224.225])
	by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id iB8IL8mt305162
	for <linux-mips@linux-mips.org>; Wed, 8 Dec 2004 13:21:08 -0500
Received: from  [63.194.214.47] by 127.0.0.1
  (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.7)); Wed, 8 Dec 2004 10:22:59 -0800
Message-ID: <41B745F6.7010502@embeddedalley.com>
Date: Wed, 08 Dec 2004 10:20:38 -0800
From: Pete Popov <ppopov@embeddedalley.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dan Malek <dan@embeddededge.com>
CC: Dmitriy Tochansky <toch@dfpost.ru>, linux-mips@linux-mips.org
Subject: Re: mmap problem another :)
References: <20041208194014.1302df6f.toch@dfpost.ru> <5FE01AB3-493E-11D9-81C3-003065F9B7DC@embeddededge.com>
In-Reply-To: <5FE01AB3-493E-11D9-81C3-003065F9B7DC@embeddededge.com>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ArGoMail-Authenticated: ppopov@embeddedalley.com
Return-Path: <ppopov@embeddedalley.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: 6604
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips

Dan Malek wrote:
> 
> On Dec 8, 2004, at 11:40 AM, Dmitriy Tochansky wrote:
> 
>>   ret = remap_page_range_high (start, offset, size, vma->vm_page_prot);
> 
> 
> Hmmm....this is in 2.4?  Did you apply all of the 36-bit IO
> patch as Pete Popov has mentioned in past e-mail messages?

The 36 bit patch is integrated in 2.4, and now in 2.6. The above 
code looks like 2.4.

Pete

> Did you make sure you enabled CONFIG_64BIT_PHYS_ADDR?
> 
> I know this does work.  In fact, you should just use
> io_remap_page_range().  If that doesn't work, something
> is wrong with the kernel configuration.
> 
>     -- Dan
> 
> 
> 



From klessard@sunrisetelecom.com Wed Dec  8 19:41:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 19:41:45 +0000 (GMT)
Received: from 67-121-164-6.ded.pacbell.net ([IPv6:::ffff:67.121.164.6]:27082
	"EHLO mailserver.sunrisetelecom.com") by linux-mips.org with ESMTP
	id <S8225325AbULHTlj>; Wed, 8 Dec 2004 19:41:39 +0000
Received: from there ([192.168.50.222]) by mailserver.sunrisetelecom.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 8 Dec 2004 11:41:24 -0800
Content-Type: text/plain;
  charset="iso-8859-1"
From: Karl Lessard <klessard@sunrisetelecom.com>
To: Pete Popov <ppopov@embeddedalley.com>
Subject: Re: Epson13806 performances on Pb1100
Date: Wed, 8 Dec 2004 14:38:47 -0500
X-Mailer: KMail [version 1.3.2]
Cc: linux-mips@linux-mips.org
References: <MAILSERVERUhrBb0aCQ0000084e@mailserver.sunrisetelecom.com> <41B7426A.2040502@embeddedalley.com>
In-Reply-To: <41B7426A.2040502@embeddedalley.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <MAILSERVERt8gsVWDKp0000090f@mailserver.sunrisetelecom.com>
X-OriginalArrivalTime: 08 Dec 2004 19:41:24.0896 (UTC) FILETIME=[E6E94200:01C4DD5D]
Return-Path: <klessard@sunrisetelecom.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: 6605
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: klessard@sunrisetelecom.com
Precedence: bulk
X-list: linux-mips

>
> I've used the chip with the 2.4 kernel/driver to run X and some
> apps. I'm not sure what you mean by high performance -- does X run
> at reasonable speeds?

I'm not running X, I've just runned a little application that writes a number 
of vertical lines (so pixel per pixel) in a backbuffer and then blit its 
content to the screen. Here's an example of one frame:

__u8 *dest = (__u8*)back_buffer;
memset(dest, 0, back_buffer_size); 	/* clear back buffer */

for (i = 0; i < 500; i++) {			/* 500 lines */
	for (j = 0; j >= 100; j--) {		/* of 100 pixel each */
		dest[(j * fb_width) + i] = 0xFF;
	}				
}

memcpy(front_buffer, dest, back_buffer_size);  /* copy back_buffer to front */


Benching with 500 frames, I obtain a rate of 8 fps with the backbuffer
residing in video memory. The framerate increase to 31 fps when the backbuffer
is in system memory! And if I do the same test using the Au1100 lcd 
controller (which has its front and back buffer in system memory), It goes up 
to 66 fps...

I don't know what's going on when I try to access the 13806 controller, but 
it's really too slow. And using the blit engine don't helps much. The static 
controller seems to be set correctly. By the way, the DRAM is refreshing at 
96Hz, and my CRT display is refreshing at 66Hz.

Any Idea? By the way Dan, I've tried the cache trick, but no luck.

Thanks a lot,
Karl


>
> Pete
>
> > I would like to know if anyone have encountered this performance problem
> > in the past with this chip.
> >
> > Thanks in advance,
> > Karl

From charles.eidsness@ieee.org Wed Dec  8 20:31:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 20:31:59 +0000 (GMT)
Received: from smtp104.rog.mail.re2.yahoo.com ([IPv6:::ffff:206.190.36.82]:27818
	"HELO smtp104.rog.mail.re2.yahoo.com") by linux-mips.org with SMTP
	id <S8225260AbULHUbx>; Wed, 8 Dec 2004 20:31:53 +0000
Received: from unknown (HELO ?192.168.1.100?) (charles.eidsness@rogers.com@24.157.59.167 with plain)
  by smtp104.rog.mail.re2.yahoo.com with SMTP; 8 Dec 2004 20:31:41 -0000
Message-ID: <41B764AB.5070201@ieee.org>
Date: Wed, 08 Dec 2004 15:31:39 -0500
From: Charles Eidsness <charles.eidsness@ieee.org>
Reply-To: charles.eidsness@ieee.org
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Au1000 Ethernet Driver using NAPI
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <charles.eidsness@ieee.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: 6606
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: charles.eidsness@ieee.org
Precedence: bulk
X-list: linux-mips

Hi All,

I was having a problem running a streaming audio application on my 
Au1000 processor when the Ethernet port was being bombarded with 
packets. All of the interrupt servicing was hogging my precious 
processing power and there was nothing left for my app. There's a new 
method for writing Ethernet drivers called NAPI which resolves this 
issue (somewhat). I converted the au1000's Ethernet driver to use this 
method. If you're interested you can find a patch that applys my changes 
to the most recent kernel here:

http://members.rogers.com/charles.eidsness/linux-au1000_eth.napi.patch

Cheers,
Charles

From mike@cogcomp.com Wed Dec  8 20:37:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 20:37:36 +0000 (GMT)
Received: from lakecmmtao01.coxmail.com ([IPv6:::ffff:68.99.120.68]:696 "EHLO
	lakecmmtao01.coxmail.com") by linux-mips.org with ESMTP
	id <S8225260AbULHUha>; Wed, 8 Dec 2004 20:37:30 +0000
Received: from mike_desktop.cogcomp.com ([68.15.41.55])
          by lakecmmtao01.coxmail.com
          (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP
          id <20041208203722.EZGO8802.lakecmmtao01.coxmail.com@mike_desktop.cogcomp.com>;
          Wed, 8 Dec 2004 15:37:22 -0500
Message-Id: <6.2.0.14.2.20041208153445.03ed3c70@pop3.cedata.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Wed, 08 Dec 2004 15:37:04 -0500
To: Karl Lessard <klessard@sunrisetelecom.com>
From: Michael Kelly <mike@cogcomp.com>
Subject: Re: Epson13806 performances on Pb1100
Cc: Pete Popov <ppopov@embeddedalley.com>, linux-mips@linux-mips.org
In-Reply-To: <MAILSERVERt8gsVWDKp0000090f@mailserver.sunrisetelecom.com>
References: <MAILSERVERUhrBb0aCQ0000084e@mailserver.sunrisetelecom.com>
 <41B7426A.2040502@embeddedalley.com>
 <MAILSERVERt8gsVWDKp0000090f@mailserver.sunrisetelecom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Return-Path: <mike@cogcomp.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: 6607
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mike@cogcomp.com
Precedence: bulk
X-list: linux-mips

KArl,

There is a bug (they might call it a feature) that causes the Au1100
to perform two accesses when talking to 16-bit peripherals.  The
first access is the real one, while the second access has the byte
enables off.  But, this means every access creates two cycles on
the bus.

I am sure of this bug on the standard peripheral bus, and I am pretty
sure it still exists when talking via the LCD signals, since the same
bus controller is used.

MIchael

At 02:38 PM 12/8/2004, Karl Lessard wrote:
> >
> > I've used the chip with the 2.4 kernel/driver to run X and some
> > apps. I'm not sure what you mean by high performance -- does X run
> > at reasonable speeds?
>
>I'm not running X, I've just runned a little application that writes a number
>of vertical lines (so pixel per pixel) in a backbuffer and then blit its
>content to the screen. Here's an example of one frame:
>
>__u8 *dest = (__u8*)back_buffer;
>memset(dest, 0, back_buffer_size);      /* clear back buffer */
>
>for (i = 0; i < 500; i++) {                     /* 500 lines */
>         for (j = 0; j >= 100; j--) {            /* of 100 pixel each */
>                 dest[(j * fb_width) + i] = 0xFF;
>         }
>}
>
>memcpy(front_buffer, dest, back_buffer_size);  /* copy back_buffer to front */
>
>
>Benching with 500 frames, I obtain a rate of 8 fps with the backbuffer
>residing in video memory. The framerate increase to 31 fps when the backbuffer
>is in system memory! And if I do the same test using the Au1100 lcd
>controller (which has its front and back buffer in system memory), It goes up
>to 66 fps...
>
>I don't know what's going on when I try to access the 13806 controller, but
>it's really too slow. And using the blit engine don't helps much. The static
>controller seems to be set correctly. By the way, the DRAM is refreshing at
>96Hz, and my CRT display is refreshing at 66Hz.
>
>Any Idea? By the way Dan, I've tried the cache trick, but no luck.
>
>Thanks a lot,
>Karl
>
>
> >
> > Pete
> >
> > > I would like to know if anyone have encountered this performance problem
> > > in the past with this chip.
> > >
> > > Thanks in advance,
> > > Karl

Michael J. Kelly
VP Engineering/Marketing
Cogent Computer Systems, Inc.
1130 Ten Rod Road
Suite A-201
North Kingstown, RI 02852
tel:401-295-6505 fax:401-295-6507
www.cogcomp.com
alternate email: mkelly6505@hotmail.com


From klessard@sunrisetelecom.com Wed Dec  8 21:20:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 21:20:47 +0000 (GMT)
Received: from 67-121-164-6.ded.pacbell.net ([IPv6:::ffff:67.121.164.6]:44240
	"EHLO mailserver.sunrisetelecom.com") by linux-mips.org with ESMTP
	id <S8225346AbULHVUn>; Wed, 8 Dec 2004 21:20:43 +0000
Received: from there ([192.168.50.222]) by mailserver.sunrisetelecom.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 8 Dec 2004 13:20:36 -0800
Content-Type: text/plain;
  charset="iso-8859-1"
From: Karl Lessard <klessard@sunrisetelecom.com>
To: Michael Kelly <mike@cogcomp.com>
Subject: Re: Epson13806 performances on Pb1100
Date: Wed, 8 Dec 2004 16:17:59 -0500
X-Mailer: KMail [version 1.3.2]
Cc: Pete Popov <ppopov@embeddedalley.com>, linux-mips@linux-mips.org
References: <MAILSERVERUhrBb0aCQ0000084e@mailserver.sunrisetelecom.com> <MAILSERVERt8gsVWDKp0000090f@mailserver.sunrisetelecom.com> <6.2.0.14.2.20041208153445.03ed3c70@pop3.cedata.com>
In-Reply-To: <6.2.0.14.2.20041208153445.03ed3c70@pop3.cedata.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <MAILSERVER15BOaF2ka0000096e@mailserver.sunrisetelecom.com>
X-OriginalArrivalTime: 08 Dec 2004 21:20:37.0089 (UTC) FILETIME=[C2B1D510:01C4DD6B]
Return-Path: <klessard@sunrisetelecom.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: 6608
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: klessard@sunrisetelecom.com
Precedence: bulk
X-list: linux-mips

On December 8, 2004 03:37 pm, Michael Kelly wrote:
> KArl,
>
> There is a bug (they might call it a feature) that causes the Au1100
> to perform two accesses when talking to 16-bit peripherals.  The
> first access is the real one, while the second access has the byte
> enables off.  But, this means every access creates two cycles on
> the bus.
>
> I am sure of this bug on the standard peripheral bus, and I am pretty
> sure it still exists when talking via the LCD signals, since the same
> bus controller is used.
>
> MIchael

Well, that may cause a problem of course. Do you mean that writing 8-bit or 
16-bits data through a chip select configured for 16-bit data bus will send 
in fact two write signals? 

If it is the case, then I obviously need to send 32-bit data for every 
access, since the second write will be used to send the second word (I 
suppose). Do I understand well?

>
> At 02:38 PM 12/8/2004, Karl Lessard wrote:
> > > I've used the chip with the 2.4 kernel/driver to run X and some
> > > apps. I'm not sure what you mean by high performance -- does X run
> > > at reasonable speeds?
> >
> >I'm not running X, I've just runned a little application that writes a
> > number of vertical lines (so pixel per pixel) in a backbuffer and then
> > blit its content to the screen. Here's an example of one frame:
> >
> >__u8 *dest = (__u8*)back_buffer;
> >memset(dest, 0, back_buffer_size);      /* clear back buffer */
> >
> >for (i = 0; i < 500; i++) {                     /* 500 lines */
> >         for (j = 0; j >= 100; j--) {            /* of 100 pixel each */
> >                 dest[(j * fb_width) + i] = 0xFF;
> >         }
> >}
> >
> >memcpy(front_buffer, dest, back_buffer_size);  /* copy back_buffer to
> > front */
> >
> >
> >Benching with 500 frames, I obtain a rate of 8 fps with the backbuffer
> >residing in video memory. The framerate increase to 31 fps when the
> > backbuffer is in system memory! And if I do the same test using the
> > Au1100 lcd controller (which has its front and back buffer in system
> > memory), It goes up to 66 fps...
> >
> >I don't know what's going on when I try to access the 13806 controller,
> > but it's really too slow. And using the blit engine don't helps much. The
> > static controller seems to be set correctly. By the way, the DRAM is
> > refreshing at 96Hz, and my CRT display is refreshing at 66Hz.
> >
> >Any Idea? By the way Dan, I've tried the cache trick, but no luck.
> >
> >Thanks a lot,
> >Karl
> >
> > > Pete
> > >
> > > > I would like to know if anyone have encountered this performance
> > > > problem in the past with this chip.
> > > >
> > > > Thanks in advance,
> > > > Karl
>
> Michael J. Kelly
> VP Engineering/Marketing
> Cogent Computer Systems, Inc.
> 1130 Ten Rod Road
> Suite A-201
> North Kingstown, RI 02852
> tel:401-295-6505 fax:401-295-6507
> www.cogcomp.com
> alternate email: mkelly6505@hotmail.com

From eric.devolder@amd.com Wed Dec  8 22:35:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 22:35:59 +0000 (GMT)
Received: from amdext4.amd.com ([IPv6:::ffff:163.181.251.6]:24965 "EHLO
	amdext4.amd.com") by linux-mips.org with ESMTP id <S8225346AbULHWfw>;
	Wed, 8 Dec 2004 22:35:52 +0000
Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22])
	by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id iB8MZdgc014666;
	Wed, 8 Dec 2004 16:35:39 -0600
Received: from 163.181.250.1 by SAUSGW01.amd.com with ESMTP (AMD SMTP
 Relay (MMS v5.5.3)); Wed, 08 Dec 2004 16:35:26 -0500
Received: from pcsmail.amd.com (pcsmail.amd.com [163.181.41.233]) by
 amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id iB8MZO8O026659; Wed,
 8 Dec 2004 16:35:24 -0600 (CST)
Received: from amd.com (pb1k77.amd.com [163.181.32.77]) by
 pcsmail.amd.com (8.11.6/8.11.6) with ESMTP id iB8MZNl13156; Wed, 8 Dec
 2004 16:35:23 -0600
Message-ID: <41B781AB.6020001@amd.com>
Date: Wed, 08 Dec 2004 16:35:23 -0600
From: "Eric DeVolder" <eric.devolder@amd.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
 Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Karl Lessard" <klessard@sunrisetelecom.com>
cc: "Michael Kelly" <mike@cogcomp.com>,
	"Pete Popov" <ppopov@embeddedalley.com>, linux-mips@linux-mips.org
Subject: Re: Epson13806 performances on Pb1100
References: <MAILSERVERUhrBb0aCQ0000084e@mailserver.sunrisetelecom.com>
 <MAILSERVERt8gsVWDKp0000090f@mailserver.sunrisetelecom.com>
 <6.2.0.14.2.20041208153445.03ed3c70@pop3.cedata.com>
 <MAILSERVER15BOaF2ka0000096e@mailserver.sunrisetelecom.com>
In-Reply-To: <MAILSERVER15BOaF2ka0000096e@mailserver.sunrisetelecom.com>
X-WSS-ID: 6DA95E24383960-01-01
Content-Type: multipart/alternative;
 boundary=------------090401010206010505010201
Return-Path: <eric.devolder@amd.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: 6609
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eric.devolder@amd.com
Precedence: bulk
X-list: linux-mips

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

The SED13506 device is horribly slow (it stalls the processor an 
enormous amount of time) while it accesses external DRAM for screen 
updates. The SED13806 has integrated SDRAM and performs better than the 
SED13506, but not nearly as well as a PCI graphics card. If you were to 
place a scope on the EWAIT# signal, you'll see it asserted a significant 
amount of time during Au accesses to the SED13806; simply put, this is 
the single largest factor in the poor performace you are observing. Your 
empirical tests verify this.

As for the bug/feature, the controller always performs two beats for 
16-bit chip-selects, so it is best to utilize both beats by performing 
32-bit accesses rather than 8 or 16 (in which case one beat is not 
utilized).

Karl Lessard wrote:

>On December 8, 2004 03:37 pm, Michael Kelly wrote:
>  
>
>>KArl,
>>
>>There is a bug (they might call it a feature) that causes the Au1100
>>to perform two accesses when talking to 16-bit peripherals.  The
>>first access is the real one, while the second access has the byte
>>enables off.  But, this means every access creates two cycles on
>>the bus.
>>
>>I am sure of this bug on the standard peripheral bus, and I am pretty
>>sure it still exists when talking via the LCD signals, since the same
>>bus controller is used.
>>
>>MIchael
>>    
>>
>
>Well, that may cause a problem of course. Do you mean that writing 8-bit or 
>16-bits data through a chip select configured for 16-bit data bus will send 
>in fact two write signals? 
>
>If it is the case, then I obviously need to send 32-bit data for every 
>access, since the second write will be used to send the second word (I 
>suppose). Do I understand well?
>
>  
>
>>At 02:38 PM 12/8/2004, Karl Lessard wrote:
>>    
>>
>>>>I've used the chip with the 2.4 kernel/driver to run X and some
>>>>apps. I'm not sure what you mean by high performance -- does X run
>>>>at reasonable speeds?
>>>>        
>>>>
>>>I'm not running X, I've just runned a little application that writes a
>>>number of vertical lines (so pixel per pixel) in a backbuffer and then
>>>blit its content to the screen. Here's an example of one frame:
>>>
>>>__u8 *dest = (__u8*)back_buffer;
>>>memset(dest, 0, back_buffer_size);      /* clear back buffer */
>>>
>>>for (i = 0; i < 500; i++) {                     /* 500 lines */
>>>        for (j = 0; j >= 100; j--) {            /* of 100 pixel each */
>>>                dest[(j * fb_width) + i] = 0xFF;
>>>        }
>>>}
>>>
>>>memcpy(front_buffer, dest, back_buffer_size);  /* copy back_buffer to
>>>front */
>>>
>>>
>>>Benching with 500 frames, I obtain a rate of 8 fps with the backbuffer
>>>residing in video memory. The framerate increase to 31 fps when the
>>>backbuffer is in system memory! And if I do the same test using the
>>>Au1100 lcd controller (which has its front and back buffer in system
>>>memory), It goes up to 66 fps...
>>>
>>>I don't know what's going on when I try to access the 13806 controller,
>>>but it's really too slow. And using the blit engine don't helps much. The
>>>static controller seems to be set correctly. By the way, the DRAM is
>>>refreshing at 96Hz, and my CRT display is refreshing at 66Hz.
>>>
>>>Any Idea? By the way Dan, I've tried the cache trick, but no luck.
>>>
>>>Thanks a lot,
>>>Karl
>>>
>>>      
>>>
>>>>Pete
>>>>
>>>>        
>>>>
>>>>>I would like to know if anyone have encountered this performance
>>>>>problem in the past with this chip.
>>>>>
>>>>>Thanks in advance,
>>>>>Karl
>>>>>          
>>>>>
>>Michael J. Kelly
>>VP Engineering/Marketing
>>Cogent Computer Systems, Inc.
>>1130 Ten Rod Road
>>Suite A-201
>>North Kingstown, RI 02852
>>tel:401-295-6505 fax:401-295-6507
>>www.cogcomp.com
>>alternate email: mkelly6505@hotmail.com
>>    
>>
>
>
>  
>

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
The SED13506 device is horribly slow (it stalls the processor an
enormous amount of time) while it accesses external DRAM for screen
updates. The SED13806 has integrated SDRAM and performs better than the
SED13506, but not nearly as well as a PCI graphics card. If you were to
place a scope on the EWAIT# signal, you'll see it asserted a
significant amount of time during Au accesses to the SED13806; simply
put, this is the single largest factor in the poor performace you are
observing. Your empirical tests verify this.<br>
<br>
As for the bug/feature, the controller always performs two beats for
16-bit chip-selects, so it is best to utilize both beats by performing
32-bit accesses rather than 8 or 16 (in which case one beat is not
utilized).<br>
<br>
Karl Lessard wrote:<br>
<blockquote type="cite"
 cite="midMAILSERVER15BOaF2ka0000096e@mailserver.sunrisetelecom.com">
  <pre wrap="">On December 8, 2004 03:37 pm, Michael Kelly wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">KArl,

There is a bug (they might call it a feature) that causes the Au1100
to perform two accesses when talking to 16-bit peripherals.  The
first access is the real one, while the second access has the byte
enables off.  But, this means every access creates two cycles on
the bus.

I am sure of this bug on the standard peripheral bus, and I am pretty
sure it still exists when talking via the LCD signals, since the same
bus controller is used.

MIchael
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Well, that may cause a problem of course. Do you mean that writing 8-bit or 
16-bits data through a chip select configured for 16-bit data bus will send 
in fact two write signals? 

If it is the case, then I obviously need to send 32-bit data for every 
access, since the second write will be used to send the second word (I 
suppose). Do I understand well?

  </pre>
  <blockquote type="cite">
    <pre wrap="">At 02:38 PM 12/8/2004, Karl Lessard wrote:
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">I've used the chip with the 2.4 kernel/driver to run X and some
apps. I'm not sure what you mean by high performance -- does X run
at reasonable speeds?
        </pre>
      </blockquote>
      <pre wrap="">I'm not running X, I've just runned a little application that writes a
number of vertical lines (so pixel per pixel) in a backbuffer and then
blit its content to the screen. Here's an example of one frame:

__u8 *dest = (__u8*)back_buffer;
memset(dest, 0, back_buffer_size);      /* clear back buffer */

for (i = 0; i &lt; 500; i++) {                     /* 500 lines */
        for (j = 0; j &gt;= 100; j--) {            /* of 100 pixel each */
                dest[(j * fb_width) + i] = 0xFF;
        }
}

memcpy(front_buffer, dest, back_buffer_size);  /* copy back_buffer to
front */


Benching with 500 frames, I obtain a rate of 8 fps with the backbuffer
residing in video memory. The framerate increase to 31 fps when the
backbuffer is in system memory! And if I do the same test using the
Au1100 lcd controller (which has its front and back buffer in system
memory), It goes up to 66 fps...

I don't know what's going on when I try to access the 13806 controller,
but it's really too slow. And using the blit engine don't helps much. The
static controller seems to be set correctly. By the way, the DRAM is
refreshing at 96Hz, and my CRT display is refreshing at 66Hz.

Any Idea? By the way Dan, I've tried the cache trick, but no luck.

Thanks a lot,
Karl

      </pre>
      <blockquote type="cite">
        <pre wrap="">Pete

        </pre>
        <blockquote type="cite">
          <pre wrap="">I would like to know if anyone have encountered this performance
problem in the past with this chip.

Thanks in advance,
Karl
          </pre>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">Michael J. Kelly
VP Engineering/Marketing
Cogent Computer Systems, Inc.
1130 Ten Rod Road
Suite A-201
North Kingstown, RI 02852
tel:401-295-6505 fax:401-295-6507
<a class="moz-txt-link-abbreviated" href="http://www.cogcomp.com">www.cogcomp.com</a>
alternate email: <a class="moz-txt-link-abbreviated" href="mailto:mkelly6505@hotmail.com">mkelly6505@hotmail.com</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
</body>
</html>

--------------090401010206010505010201--


From ppopov@embeddedalley.com Wed Dec  8 23:35:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Dec 2004 23:35:13 +0000 (GMT)
Received: from pimout3-ext.prodigy.net ([IPv6:::ffff:207.115.63.102]:15025
	"EHLO pimout3-ext.prodigy.net") by linux-mips.org with ESMTP
	id <S8225346AbULHXfG>; Wed, 8 Dec 2004 23:35:06 +0000
Received: from 127.0.0.1 (adsl-68-124-224-225.dsl.snfc21.pacbell.net [68.124.224.225])
	by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id iB8NZ1mu380132
	for <linux-mips@linux-mips.org>; Wed, 8 Dec 2004 18:35:02 -0500
Received: from  [63.194.214.47] by 127.0.0.1
  (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.7)); Wed, 8 Dec 2004 15:36:52 -0800
Message-ID: <41B78F83.9010001@embeddedalley.com>
Date: Wed, 08 Dec 2004 15:34:27 -0800
From: Pete Popov <ppopov@embeddedalley.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: charles.eidsness@ieee.org
CC: linux-mips@linux-mips.org
Subject: Re: Au1000 Ethernet Driver using NAPI
References: <41B764AB.5070201@ieee.org>
In-Reply-To: <41B764AB.5070201@ieee.org>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ArGoMail-Authenticated: ppopov@embeddedalley.com
Return-Path: <ppopov@embeddedalley.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: 6610
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips


Very cool, thanks. Is the patch for 2.4 or 2.6?

Pete

Charles Eidsness wrote:
> Hi All,
> 
> I was having a problem running a streaming audio application on my 
> Au1000 processor when the Ethernet port was being bombarded with 
> packets. All of the interrupt servicing was hogging my precious 
> processing power and there was nothing left for my app. There's a new 
> method for writing Ethernet drivers called NAPI which resolves this 
> issue (somewhat). I converted the au1000's Ethernet driver to use this 
> method. If you're interested you can find a patch that applys my changes 
> to the most recent kernel here:
> 
> http://members.rogers.com/charles.eidsness/linux-au1000_eth.napi.patch
> 
> Cheers,
> Charles
> 
> 




From charles.eidsness@ieee.org Thu Dec  9 01:05:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 01:05:56 +0000 (GMT)
Received: from smtp105.rog.mail.re2.yahoo.com ([IPv6:::ffff:206.190.36.83]:5244
	"HELO smtp105.rog.mail.re2.yahoo.com") by linux-mips.org with SMTP
	id <S8225346AbULIBFu>; Thu, 9 Dec 2004 01:05:50 +0000
Received: from unknown (HELO ?192.168.1.100?) (charles.eidsness@rogers.com@24.157.59.167 with plain)
  by smtp105.rog.mail.re2.yahoo.com with SMTP; 9 Dec 2004 01:05:43 -0000
Message-ID: <41B7A4CF.7090203@ieee.org>
Date: Wed, 08 Dec 2004 20:05:19 -0500
From: Charles Eidsness <charles.eidsness@ieee.org>
Reply-To: charles.eidsness@ieee.org
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ppopov@embeddedalley.com
CC: linux-mips@linux-mips.org
Subject: Re: Au1000 Ethernet Driver using NAPI
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <charles.eidsness@ieee.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: 6611
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: charles.eidsness@ieee.org
Precedence: bulk
X-list: linux-mips

Pete Popov wrote:
 >
 >Very cool, thanks. Is the patch for 2.4 or 2.6?
 >
 >Pete

Hi Pete,

It's for 2.6, I'm not sure if it will work on 2.4.

There are a couple of possible issues with this method that I probably 
should have mentioned in my first email. Since the Au1000 shares an 
interrupt for the TX and RX streams I had to lump the two together and 
as a result there may be an increase in TX latency. Also, the MAC's DMA 
can only queue up a maximum of 4 packets at a time so depending on how 
long the processor spends clearing out the queue there may be some 
buffer overruns. I've experienced neither of these issues but my testing 
so far has been pretty application specific.

Cheers,
Charles

Charles Eidsness wrote:
 > Hi All,
 >
 > I was having a problem running a streaming audio application on my
 > Au1000 processor when the Ethernet port was being bombarded with
 > packets. All of the interrupt servicing was hogging my precious
 > processing power and there was nothing left for my app. There's a new
 > method for writing Ethernet drivers called NAPI which resolves this
 > issue (somewhat). I converted the au1000's Ethernet driver to use
this
 > method. If you're interested you can find a patch that applys my
changes
 > to the most recent kernel here:
 >
 >
http://members.rogers.com/charles.eidsness/linux-au1000_eth.napi.patch
 >
 > Cheers,
 > Charles
 >
 >

From toch@dfpost.ru Thu Dec  9 06:56:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 06:56:47 +0000 (GMT)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:42680 "EHLO
	mail.dfpost.ru") by linux-mips.org with ESMTP id <S8224991AbULIG4i>;
	Thu, 9 Dec 2004 06:56:38 +0000
Received: from toch.dfpost.ru (toch.dfpost.ru [192.168.7.60])
	by mail.dfpost.ru (Postfix) with SMTP id 239C33E517;
	Thu,  9 Dec 2004 09:50:52 +0300 (MSK)
Date: Thu, 9 Dec 2004 09:56:59 +0300
From: Dmitriy Tochansky <toch@dfpost.ru>
To: Dan Malek <dan@embeddededge.com>
Cc: linux-mips@linux-mips.org
Subject: Re: mmap problem another :)
Message-Id: <20041209095659.651b7a1d.toch@dfpost.ru>
In-Reply-To: <5FE01AB3-493E-11D9-81C3-003065F9B7DC@embeddededge.com>
References: <20041208194014.1302df6f.toch@dfpost.ru>
	<5FE01AB3-493E-11D9-81C3-003065F9B7DC@embeddededge.com>
Organization: Special Technology Center
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6612
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

On Wed, 8 Dec 2004 12:27:02 -0500
Dan Malek <dan@embeddededge.com> wrote:

> 
> On Dec 8, 2004, at 11:40 AM, Dmitriy Tochansky wrote:
> 
> >   ret = remap_page_range_high (start, offset, size,
> >   vma->vm_page_prot);
> 
> Hmmm....this is in 2.4?  Did you apply all of the 36-bit IO
> patch as Pete Popov has mentioned in past e-mail messages?
  Could you please direct me where it is exectly? In this maillist? May be on the web?

> Did you make sure you enabled CONFIG_64BIT_PHYS_ADDR?
  Yes. I'm sure.

From demiurg@ti.com Thu Dec  9 12:03:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 12:03:28 +0000 (GMT)
Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:47567 "EHLO
	go4.ext.ti.com") by linux-mips.org with ESMTP id <S8225223AbULIMDX>;
	Thu, 9 Dec 2004 12:03:23 +0000
Received: from dlep91.itg.ti.com ([157.170.152.55])
	by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id iB9C3HaB000171
	for <linux-mips@linux-mips.org>; Thu, 9 Dec 2004 06:03:17 -0600 (CST)
Received: from DILE2K01.ent.ti.com (localhost [127.0.0.1])
	by dlep91.itg.ti.com (8.12.11/8.12.11) with ESMTP id iB9C3Fwx010678
	for <linux-mips@linux-mips.org>; Thu, 9 Dec 2004 06:03:16 -0600 (CST)
Received: from [137.167.5.34] ([137.167.5.34]) by DILE2K01.ent.ti.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 9 Dec 2004 14:03:15 +0200
Message-ID: <41B83F02.1060003@ti.com>
Date: Thu, 09 Dec 2004 14:03:14 +0200
From: Alexander Sirotkin <demiurg@ti.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: o32_ret_from_sys_call
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Dec 2004 12:03:15.0053 (UTC) FILETIME=[1019D9D0:01C4DDE7]
Return-Path: <demiurg@ti.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6613
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: demiurg@ti.com
Precedence: bulk
X-list: linux-mips

I have noticed that somewhere around 2.4.17 sys_sysmips() function from 
sysmips.c
was rewritten and call to o32_ret_from_sys_call disappear. This function 
(o32_ret_from_sys_call)
was responsible for calling do_softirq() after each system call. I'm 
curious, what is the
current mechanism in mips 2.4.x that ensures that do_softirq is called 
after system call ?

10x.

-- 
Alexander Sirotkin
SW Engineer

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


From philippedeswert@scarlet.be Thu Dec  9 12:17:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 12:17:37 +0000 (GMT)
Received: from oola.is.scarlet.be ([IPv6:::ffff:193.74.71.23]:26025 "EHLO
	oola.is.scarlet.be") by linux-mips.org with ESMTP
	id <S8225220AbULIMRc> convert rfc822-to-8bit; Thu, 9 Dec 2004 12:17:32 +0000
Received: from (fuji.is.scarlet.be [193.74.71.41]) 
	by oola.is.scarlet.be  with ESMTP id iB9CHNT15470; 
	Thu, 9 Dec 2004 13:17:23 +0100
Date: Thu,  9 Dec 2004 13:17:23 +0100
Message-Id: <I8GFGZ$181DD12A3DE3065A4DBC5982EAE9EA84@scarlet.be>
Subject: Re:o32_ret_from_sys_call
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
From: "Philippe De Swert" <philippedeswert@scarlet.be>
To: "demiurg" <demiurg@ti.com>
Cc: "linux-mips" <linux-mips@linux-mips.org>
X-XaM3-API-Version: 4.1 (B54)
X-type: 0
X-SenderIP: 195.144.76.35
Return-Path: <philippedeswert@scarlet.be>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Envid: <I8GFGZ$181DD12A3DE3065A4DBC5982EAE9EA84
Envelope-Id: <I8GFGZ$181DD12A3DE3065A4DBC5982EAE9EA84
X-archive-position: 6614
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: philippedeswert@scarlet.be
Precedence: bulk
X-list: linux-mips

Hi Alexander,

Do you happen to work with a clean kernel or a montavista one?
Montavista made a lot of changes which do not necessarely reflect in the
normal kernel code (especially on irq, pre-emptiveness and PCI)

> I have noticed that somewhere around 2.4.17 sys_sysmips() function from 
> sysmips.c
> was rewritten and call to o32_ret_from_sys_call disappear. This function 
> (o32_ret_from_sys_call)
> was responsible for calling do_softirq() after each system call. I'm 
> curious, what is the
> current mechanism in mips 2.4.x that ensures that do_softirq is called 
> after system call ?

regards,

Philippe
 
| Philippe De Swert -GNU/linux - uClinux freak-      
|      
| Stag developer http://stag.mind.be/  
| Emdebian developer: http://www.emdebian.org  
|   
| Please do not send me documents in a closed format. (*.doc,*.xls,*.ppt)    
| Use the open alternatives. (*.pdf,*.ps,*.html,*.txt)    
| Why? http://pallieter.is-a-geek.org:7832/~johan/word/english/    

-------------------------------------------------------
NOTE! My email address is changing to ... @scarlet.be
Please make the necessary changes in your address book. 




From demiurg@ti.com Thu Dec  9 12:41:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 12:41:54 +0000 (GMT)
Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:5347 "EHLO
	go4.ext.ti.com") by linux-mips.org with ESMTP id <S8225220AbULIMlt>;
	Thu, 9 Dec 2004 12:41:49 +0000
Received: from dlep91.itg.ti.com ([157.170.152.55])
	by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id iB9Cfctp007641;
	Thu, 9 Dec 2004 06:41:38 -0600 (CST)
Received: from DILE2K01.ent.ti.com (localhost [127.0.0.1])
	by dlep91.itg.ti.com (8.12.11/8.12.11) with ESMTP id iB9CfajP015756;
	Thu, 9 Dec 2004 06:41:37 -0600 (CST)
Received: from [137.167.5.34] ([137.167.5.34]) by DILE2K01.ent.ti.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 9 Dec 2004 14:41:35 +0200
Message-ID: <41B847FF.5080309@ti.com>
Date: Thu, 09 Dec 2004 14:41:35 +0200
From: Alexander Sirotkin <demiurg@ti.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philippe De Swert <philippedeswert@scarlet.be>
CC: linux-mips <linux-mips@linux-mips.org>
Subject: Re: o32_ret_from_sys_call
References: <I8GFGZ$181DD12A3DE3065A4DBC5982EAE9EA84@scarlet.be>
In-Reply-To: <I8GFGZ$181DD12A3DE3065A4DBC5982EAE9EA84@scarlet.be>
Content-Type: multipart/alternative;
 boundary="------------090202080702090509010500"
X-OriginalArrivalTime: 09 Dec 2004 12:41:35.0976 (UTC) FILETIME=[6B8ED680:01C4DDEC]
Return-Path: <demiurg@ti.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6615
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: demiurg@ti.com
Precedence: bulk
X-list: linux-mips

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

Hi.

I do work with montavista kernel, but regarding this particular change - 
I can see it in all kernels
(montavista, kernel.org and linux-mips). In kernel.org this change 
happened between 2.4.18 and
2.4.19, don't know when exatcly it was introduced into other kernels.

10x.


Philippe De Swert wrote:

>Hi Alexander,
>
>Do you happen to work with a clean kernel or a montavista one?
>Montavista made a lot of changes which do not necessarely reflect in the
>normal kernel code (especially on irq, pre-emptiveness and PCI)
>
>  
>
>>I have noticed that somewhere around 2.4.17 sys_sysmips() function from 
>>sysmips.c
>>was rewritten and call to o32_ret_from_sys_call disappear. This function 
>>(o32_ret_from_sys_call)
>>was responsible for calling do_softirq() after each system call. I'm 
>>curious, what is the
>>current mechanism in mips 2.4.x that ensures that do_softirq is called 
>>after system call ?
>>    
>>
>
>regards,
>
>Philippe
> 
>| Philippe De Swert -GNU/linux - uClinux freak-      
>|      
>| Stag developer http://stag.mind.be/  
>| Emdebian developer: http://www.emdebian.org  
>|   
>| Please do not send me documents in a closed format. (*.doc,*.xls,*.ppt)    
>| Use the open alternatives. (*.pdf,*.ps,*.html,*.txt)    
>| Why? http://pallieter.is-a-geek.org:7832/~johan/word/english/    
>
>-------------------------------------------------------
>NOTE! My email address is changing to ... @scarlet.be
>Please make the necessary changes in your address book. 
>
>
>
>  
>

-- 
Alexander Sirotkin
SW Engineer

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


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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi.<br>
<br>
I do work with montavista kernel, but regarding this particular change
- I can see it in all kernels <br>
(montavista, kernel.org and linux-mips). In kernel.org this change
happened between 2.4.18 and<br>
2.4.19, don't know when exatcly it was introduced into other kernels.<br>
<br>
10x.<br>
<br>
<br>
Philippe De Swert wrote:
<blockquote cite="midI8GFGZ$181DD12A3DE3065A4DBC5982EAE9EA84@scarlet.be"
 type="cite">
  <pre wrap="">Hi Alexander,

Do you happen to work with a clean kernel or a montavista one?
Montavista made a lot of changes which do not necessarely reflect in the
normal kernel code (especially on irq, pre-emptiveness and PCI)

  </pre>
  <blockquote type="cite">
    <pre wrap="">I have noticed that somewhere around 2.4.17 sys_sysmips() function from 
sysmips.c
was rewritten and call to o32_ret_from_sys_call disappear. This function 
(o32_ret_from_sys_call)
was responsible for calling do_softirq() after each system call. I'm 
curious, what is the
current mechanism in mips 2.4.x that ensures that do_softirq is called 
after system call ?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
regards,

Philippe
 
| Philippe De Swert -GNU/linux - uClinux freak-      
|      
| Stag developer <a class="moz-txt-link-freetext" href="http://stag.mind.be/">http://stag.mind.be/</a>  
| Emdebian developer: <a class="moz-txt-link-freetext" href="http://www.emdebian.org">http://www.emdebian.org</a>  
|   
| Please do not send me documents in a closed format. (*.doc,*.xls,*.ppt)    
| Use the open alternatives. (*.pdf,*.ps,*.html,*.txt)    
| Why? <a class="moz-txt-link-freetext" href="http://pallieter.is-a-geek.org:7832/~johan/word/english/">http://pallieter.is-a-geek.org:7832/~johan/word/english/</a>    

-------------------------------------------------------
NOTE! My email address is changing to ... @scarlet.be
Please make the necessary changes in your address book. 



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

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

--------------090202080702090509010500--

From toch@dfpost.ru Thu Dec  9 13:11:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 13:11:46 +0000 (GMT)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:58756 "EHLO
	mail.dfpost.ru") by linux-mips.org with ESMTP id <S8225220AbULINLm>;
	Thu, 9 Dec 2004 13:11:42 +0000
Received: from toch.dfpost.ru (toch.dfpost.ru [192.168.7.60])
	by mail.dfpost.ru (Postfix) with SMTP id 9130C3E517
	for <linux-mips@linux-mips.org>; Thu,  9 Dec 2004 16:05:58 +0300 (MSK)
Date: Thu, 9 Dec 2004 16:12:07 +0300
From: Dmitriy Tochansky <toch@dfpost.ru>
To: linux-mips@linux-mips.org
Subject: mmap problem another :)
Message-Id: <20041209161207.39140f0d.toch@dfpost.ru>
Organization: Special Technology Center
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6616
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

Seems like I found problem.

Look ret = io_remap_page_range(start, offset, size, vma->vm_page_prot); remaps
from "offset" which I got from pci_resource_start (curdev, IOMEM0); its ok
from first board where it eq 0x40000000 but on second it 0x40002040

Then I'm reading from x = mmap (NULL, MMAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); with
shift 0x3C>>2 where I expect board register. But for second board x points to where?
0x40000000 or 0x40002040 or as I think remap_page_range or sonething realign offset to 
PAGE so x points to 0x40002000 or 0x40003000 and reading with shift 0x3C have no sense.

Am I rigth?

From dan@embeddededge.com Thu Dec  9 14:36:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 14:36:21 +0000 (GMT)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:26888 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8225238AbULIOgQ>; Thu, 9 Dec 2004 14:36:16 +0000
Received: from [192.168.253.28] (tibook.embeddededge.com [192.168.253.28])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id iB9EN39f017816;
	Thu, 9 Dec 2004 09:23:03 -0500
In-Reply-To: <20041209161207.39140f0d.toch@dfpost.ru>
References: <20041209161207.39140f0d.toch@dfpost.ru>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <AC350838-49EF-11D9-A745-003065F9B7DC@embeddededge.com>
Content-Transfer-Encoding: 7bit
Cc: linux-mips@linux-mips.org
From: Dan Malek <dan@embeddededge.com>
Subject: Re: mmap problem another :)
Date: Thu, 9 Dec 2004 09:36:11 -0500
To: Dmitriy Tochansky <toch@dfpost.ru>
X-Mailer: Apple Mail (2.619)
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: 6617
X-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


On Dec 9, 2004, at 8:12 AM, Dmitriy Tochansky wrote:

> Look ret = io_remap_page_range(start, offset, size, 
> vma->vm_page_prot); remaps
> from "offset" which I got from pci_resource_start (curdev, IOMEM0); 
> its ok
> from first board where it eq 0x40000000 but on second it 0x40002040

Read the memory mapping docuemntation and understand the APIs.
All of the Linux mapping functions, whether mmap() from an application
or in the kernel are going to align on page boundaries.

The address of 0x40002040 is going to be aligned to a page boundary,
so you have to consider the offset into that page to the base of the
device, plus the register offset.  The kernel mapping functions,
like remap_page_range, are going to force the alignment because
that is what we expect in the kernel.  An mmap() with an unaligned
address will generate an error.


	-- Dan


From ppopov@embeddedalley.com Thu Dec  9 15:26:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 15:26:28 +0000 (GMT)
Received: from pimout3-ext.prodigy.net ([IPv6:::ffff:207.115.63.102]:29573
	"EHLO pimout3-ext.prodigy.net") by linux-mips.org with ESMTP
	id <S8225238AbULIP0X>; Thu, 9 Dec 2004 15:26:23 +0000
Received: from 127.0.0.1 (adsl-68-124-224-225.dsl.snfc21.pacbell.net [68.124.224.225])
	by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id iB9FQFmu428704
	for <linux-mips@linux-mips.org>; Thu, 9 Dec 2004 10:26:21 -0500
Received: from  [63.194.214.47] by 127.0.0.1
  (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.7)); Thu, 9 Dec 2004 07:28:11 -0800
Message-ID: <41B86E7D.3000609@embeddedalley.com>
Date: Thu, 09 Dec 2004 07:25:49 -0800
From: Pete Popov <ppopov@embeddedalley.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: fyi, syscall() somehow broken...
References: <1102602117.28707.49.camel@shswe.inso.tuwien.ac.at>
In-Reply-To: <1102602117.28707.49.camel@shswe.inso.tuwien.ac.at>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ArGoMail-Authenticated: ppopov@embeddedalley.com
Return-Path: <ppopov@embeddedalley.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: 6618
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips


> jfyi, something broke w/ the following commit... most notably 'ls -l'
> doesn't work anymore... reverting to yesterdays cvs state fixes the
> issues... ;-)
> 
> Working file: arch/mips/kernel/scall32-o32.S
> head: 1.18
> revision 1.18
> date: 2004/12/08 14:32:30;  author: ths;  state: Exp;  lines: +85 -102
> Fix indirect syscalls for o32, improve syscall performance a bit,
> and general code cleanup.

Someone reported this problem on the Au1x boards. Anyone else seeing 
the problem on other MIPS32 boards?

Pete



From ica2_ts@csv.ica.uni-stuttgart.de Thu Dec  9 15:44:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 15:44:17 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:6492
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225241AbULIPoM>; Thu, 9 Dec 2004 15:44:12 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CcQSc-0001kH-00; Thu, 09 Dec 2004 16:44:06 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CcQSb-000326-00; Thu, 09 Dec 2004 16:44:05 +0100
Date: Thu, 9 Dec 2004 16:44:05 +0100
To: Pete Popov <ppopov@embeddedalley.com>
Cc: linux-mips@linux-mips.org
Subject: Re: fyi, syscall() somehow broken...
Message-ID: <20041209154405.GB8419@rembrandt.csv.ica.uni-stuttgart.de>
References: <1102602117.28707.49.camel@shswe.inso.tuwien.ac.at> <41B86E7D.3000609@embeddedalley.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41B86E7D.3000609@embeddedalley.com>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6619
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Pete Popov wrote:
> 
> >jfyi, something broke w/ the following commit... most notably 'ls -l'
> >doesn't work anymore... reverting to yesterdays cvs state fixes the
> >issues... ;-)

Confirmed on a SGI Indy with 32bit kernel. sys_quotactl seems to be
broken, while the rest of the system appears to work well.
I'll have a look.

> >Working file: arch/mips/kernel/scall32-o32.S
> >head: 1.18
> >revision 1.18
> >date: 2004/12/08 14:32:30;  author: ths;  state: Exp;  lines: +85 -102
> >Fix indirect syscalls for o32, improve syscall performance a bit,
> >and general code cleanup.
> 
> Someone reported this problem on the Au1x boards. Anyone else seeing 
> the problem on other MIPS32 boards?

The changed code is fairly hardware independent.


Thiemo

From gmuruga@gdatech.com Thu Dec  9 18:18:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 18:18:10 +0000 (GMT)
Received: from darwaza.gdatech.com ([IPv6:::ffff:66.237.41.98]:35398 "EHLO
	kings.gdatech.com") by linux-mips.org with ESMTP
	id <S8225262AbULISSG>; Thu, 9 Dec 2004 18:18:06 +0000
Received: from kings.gdatech.com (localhost.localdomain [127.0.0.1])
	by kings.gdatech.com (Postfix) with ESMTP id 6512161C0E3;
	Thu,  9 Dec 2004 10:13:03 -0800 (PST)
X-Propel-Return-Path: <gmuruga@gdatech.com>
Received: from kings.gdatech.com ([192.168.200.118])
	by localhost.localdomain ([127.0.0.1]) (port 7027) (Propel SE relay 0.1.0.1557 $Rev$)
	id r4cI101303-1083-1
	for linux-mips@linux-mips.org mlachwani@mvista.com; Thu, 09 Dec 2004 10:13:03 -0800
Received: from sierra.gdatech.com (asg_mda [192.168.200.112])
	by kings.gdatech.com (Postfix) with ESMTP id 3238B61C0D2;
	Thu,  9 Dec 2004 10:13:03 -0800 (PST)
Received: (from nobody@localhost)
	by gdatech.com (8.11.6/8.11.6) id iB9IE1U27643;
	Thu, 9 Dec 2004 10:14:01 -0800
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: gdatech.com
Date: Thu, 9 Dec 2004 10:14:01 -0800
Message-Id: <200412091814.iB9IE1U27643@gdatech.com>
X-Authentication-Warning: sierra.gdatech.com: nobody set sender to gmuruga@gdatech.com using -f
From: "Muruga Ganapathy" <gmuruga@gdatech.com>
To: Manish Lachwani <mlachwani@mvista.com>,
	Muruga Ganapathy <gmuruga@gdatech.com>,
	linux-mips@linux-mips.org
Subject: Re: Forcing IDE to work in PIO mode
X-Mailer: NeoMail 1.25
X-IPAddress: 63.111.213.196
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Return-Path: <gmuruga@gdatech.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: 6620
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gmuruga@gdatech.com
Precedence: bulk
X-list: linux-mips

Thanks Manish for the information.  
 
BTW, do you have patch to make the swarm IDE work in 2.6.6-rc3 
 
Regards 
G.Muruganandam 
 
 
> Muruga Ganapathy wrote: 
> > Hello,  
> >  
> > How do I force the IDE to work in the PIO mode by including the  
> > option like "hdb=noprobe" in the setup.c? 
> >  
> >  
> > My kernel version is 2.6.6 
> >  
> > Thanks 
> > G.Muruganandam 
> >  
>  
> Hello ! 
>  
> I would have thought "ide=nodma" at the command line would have 
worked 
>  
> Thanks 
> Manish Lachwani 
>  
>  
 
************************************************************* 
GDA Technologies, Inc.		 
1010 Rincon Circle  
San Jose CA, 95131 
Phone	(408) 432-3090 
Fax	(408) 432-3091 
 
Accelerate Your Innovation	 
************************************************************** 

From mlachwani@mvista.com Thu Dec  9 19:30:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 19:30:54 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:23805 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225272AbULITas>; Thu, 9 Dec 2004 19:30:48 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id E700618550; Thu,  9 Dec 2004 11:30:46 -0800 (PST)
Message-ID: <41B8A7E6.7070002@mvista.com>
Date: Thu, 09 Dec 2004 11:30:46 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Muruga Ganapathy <gmuruga@gdatech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Forcing IDE to work in PIO mode
References: <200412091814.iB9IE1U27643@gdatech.com>
In-Reply-To: <200412091814.iB9IE1U27643@gdatech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6621
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

I had posted a patch to this mailing list a few days back. The patch 
applies cleanly to the current tree and is currently checked in: 
drivers/ide/mips/swarm.c

Using this patch, Broadcom SWARM IDE works well

Thanks
Manish Lachwani

Muruga Ganapathy wrote:
> Thanks Manish for the information.  
>  
> BTW, do you have patch to make the swarm IDE work in 2.6.6-rc3 
>  
> Regards 
> G.Muruganandam 
>  
>  
> 
>>Muruga Ganapathy wrote: 
>>
>>>Hello,  
>>> 
>>>How do I force the IDE to work in the PIO mode by including the  
>>>option like "hdb=noprobe" in the setup.c? 
>>> 
>>> 
>>>My kernel version is 2.6.6 
>>> 
>>>Thanks 
>>>G.Muruganandam 
>>> 
>>
>> 
>>Hello ! 
>> 
>>I would have thought "ide=nodma" at the command line would have 
> 
> worked 
> 
>> 
>>Thanks 
>>Manish Lachwani 
>> 
>> 
> 
>  
> ************************************************************* 
> GDA Technologies, Inc.		 
> 1010 Rincon Circle  
> San Jose CA, 95131 
> Phone	(408) 432-3090 
> Fax	(408) 432-3091 
>  
> Accelerate Your Innovation	 
> ************************************************************** 



From gmuruga@gdatech.com Thu Dec  9 21:06:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 21:06:51 +0000 (GMT)
Received: from darwaza.gdatech.com ([IPv6:::ffff:66.237.41.98]:49990 "EHLO
	kings.gdatech.com") by linux-mips.org with ESMTP
	id <S8225262AbULIVGq>; Thu, 9 Dec 2004 21:06:46 +0000
Received: from kings.gdatech.com (localhost.localdomain [127.0.0.1])
	by kings.gdatech.com (Postfix) with ESMTP id 15B9E61C0E4;
	Thu,  9 Dec 2004 13:01:36 -0800 (PST)
X-Propel-Return-Path: <gmuruga@gdatech.com>
Received: from kings.gdatech.com ([192.168.200.118])
	by localhost.localdomain ([127.0.0.1]) (port 7027) (Propel SE relay 0.1.0.1557 $Rev$)
	id r4cI130136-1230-1
	for linux-mips@linux-mips.org mlachwani@mvista.com; Thu, 09 Dec 2004 13:01:36 -0800
Received: from sierra.gdatech.com (asg_mda [192.168.200.112])
	by kings.gdatech.com (Postfix) with ESMTP id DBCD861C0D2;
	Thu,  9 Dec 2004 13:01:35 -0800 (PST)
Received: (from nobody@localhost)
	by gdatech.com (8.11.6/8.11.6) id iB9L2aQ04660;
	Thu, 9 Dec 2004 13:02:36 -0800
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: gdatech.com
Date: Thu, 9 Dec 2004 13:02:36 -0800
Message-Id: <200412092102.iB9L2aQ04660@gdatech.com>
X-Authentication-Warning: sierra.gdatech.com: nobody set sender to gmuruga@gdatech.com using -f
From: "Muruga Ganapathy" <gmuruga@gdatech.com>
To: Manish Lachwani <mlachwani@mvista.com>,
	Muruga Ganapathy <gmuruga@gdatech.com>,
	linux-mips@linux-mips.org
Subject: Re: Forcing IDE to work in PIO mode
X-Mailer: NeoMail 1.25
X-IPAddress: 63.111.213.196
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Return-Path: <gmuruga@gdatech.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: 6622
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gmuruga@gdatech.com
Precedence: bulk
X-list: linux-mips

Manish, 

Thanks for the pointer.

I am looking for the PCMCIA-IDE driver for the SWARM board in 2.6.x
I did see this driver in 2.4.26/27 but not in 2.6.10.

Do you have any suggestions on porting the PCMCIA-IDE driver from 2.4.27
to 2.6.x?

Regards
G.Muruganandam

> I had posted a patch to this mailing list a few days back. The patch 
> applies cleanly to the current tree and is currently checked in: 
> drivers/ide/mips/swarm.c
> 
> Using this patch, Broadcom SWARM IDE works well
> 
> Thanks
> Manish Lachwani
> 
> Muruga Ganapathy wrote:
> > Thanks Manish for the information.  
> >  
> > BTW, do you have patch to make the swarm IDE work in 2.6.6-rc3 
> >  
> > Regards 
> > G.Muruganandam 
> >  
> >  
> > 
> >>Muruga Ganapathy wrote: 
> >>
> >>>Hello,  
> >>> 
> >>>How do I force the IDE to work in the PIO mode by including the  
> >>>option like "hdb=noprobe" in the setup.c? 
> >>> 
> >>> 
> >>>My kernel version is 2.6.6 
> >>> 
> >>>Thanks 
> >>>G.Muruganandam 
> >>> 
> >>
> >> 
> >>Hello ! 
> >> 
> >>I would have thought "ide=nodma" at the command line would have 
> > 
> > worked 
> > 
> >> 
> >>Thanks 
> >>Manish Lachwani 
> >> 
> >> 
> > 
> >  
> > ************************************************************* 
> > GDA Technologies, Inc.		 
> > 1010 Rincon Circle  
> > San Jose CA, 95131 
> > Phone	(408) 432-3090 
> > Fax	(408) 432-3091 
> >  
> > Accelerate Your Innovation	 
> > ************************************************************** 
> 
> 

*************************************************************
GDA Technologies, Inc.		
1010 Rincon Circle 
San Jose CA, 95131
Phone	(408) 432-3090
Fax	(408) 432-3091

Accelerate Your Innovation	
**************************************************************

From mlachwani@mvista.com Thu Dec  9 21:29:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 21:29:39 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:54511 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225262AbULIV3f>; Thu, 9 Dec 2004 21:29:35 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id 8774518303; Thu,  9 Dec 2004 13:29:33 -0800 (PST)
Message-ID: <41B8C3BD.3080109@mvista.com>
Date: Thu, 09 Dec 2004 13:29:33 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Muruga Ganapathy <gmuruga@gdatech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Forcing IDE to work in PIO mode
References: <200412092102.iB9L2aQ04660@gdatech.com>
In-Reply-To: <200412092102.iB9L2aQ04660@gdatech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6623
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

Please point me to the 2.4.26 or 2.4.27 code that you are referring to

Thanks
Manish Lachwani

Muruga Ganapathy wrote:
> Manish, 
> 
> Thanks for the pointer.
> 
> I am looking for the PCMCIA-IDE driver for the SWARM board in 2.6.x
> I did see this driver in 2.4.26/27 but not in 2.6.10.
> 
> Do you have any suggestions on porting the PCMCIA-IDE driver from 2.4.27
> to 2.6.x?
> 
> Regards
> G.Muruganandam
> 
> 
>>I had posted a patch to this mailing list a few days back. The patch 
>>applies cleanly to the current tree and is currently checked in: 
>>drivers/ide/mips/swarm.c
>>
>>Using this patch, Broadcom SWARM IDE works well
>>
>>Thanks
>>Manish Lachwani
>>
>>Muruga Ganapathy wrote:
>>
>>>Thanks Manish for the information.  
>>> 
>>>BTW, do you have patch to make the swarm IDE work in 2.6.6-rc3 
>>> 
>>>Regards 
>>>G.Muruganandam 
>>> 
>>> 
>>>
>>>
>>>>Muruga Ganapathy wrote: 
>>>>
>>>>
>>>>>Hello,  
>>>>>
>>>>>How do I force the IDE to work in the PIO mode by including the  
>>>>>option like "hdb=noprobe" in the setup.c? 
>>>>>
>>>>>
>>>>>My kernel version is 2.6.6 
>>>>>
>>>>>Thanks 
>>>>>G.Muruganandam 
>>>>>
>>>>
>>>>
>>>>Hello ! 
>>>>
>>>>I would have thought "ide=nodma" at the command line would have 
>>>
>>>worked 
>>>
>>>
>>>>Thanks 
>>>>Manish Lachwani 
>>>>
>>>>
>>>
>>> 
>>>************************************************************* 
>>>GDA Technologies, Inc.		 
>>>1010 Rincon Circle  
>>>San Jose CA, 95131 
>>>Phone	(408) 432-3090 
>>>Fax	(408) 432-3091 
>>> 
>>>Accelerate Your Innovation	 
>>>************************************************************** 
>>
>>
> 
> *************************************************************
> GDA Technologies, Inc.		
> 1010 Rincon Circle 
> San Jose CA, 95131
> Phone	(408) 432-3090
> Fax	(408) 432-3091
> 
> Accelerate Your Innovation	
> **************************************************************



From krishnamurthydv@yahoo.com Thu Dec  9 21:40:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 21:40:39 +0000 (GMT)
Received: from web60108.mail.yahoo.com ([IPv6:::ffff:216.109.118.87]:21867
	"HELO web60108.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225262AbULIVk3>; Thu, 9 Dec 2004 21:40:29 +0000
Received: (qmail 88803 invoked by uid 60001); 9 Dec 2004 21:40:21 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=aJb6GFAvpdyEcym7kdgOgxt5KK0IM7hHzwlCnfWsiKPANFz7l2OznjZPgXLHNiD0fn6uht1B/L1iHvOijRUBAKuLNu6ul2877b9NeCJ7G1uJNFW5xiCfcOdveuOz/byIgpv3rBK0T+IFRO4hB9svaE/fYU7RDD8BaCAcNpFBBrc=  ;
Message-ID: <20041209214021.88801.qmail@web60108.mail.yahoo.com>
Received: from [63.111.213.196] by web60108.mail.yahoo.com via HTTP; Thu, 09 Dec 2004 13:40:20 PST
Date: Thu, 9 Dec 2004 13:40:20 -0800 (PST)
From: Krishnamurthy Daulatabad <krishnamurthydv@yahoo.com>
Subject: Re: MIPS - 2.4.20 kernel - wait_on_irq issue
To: linux-mips@linux-mips.org
In-Reply-To: <20041207090350.32851.qmail@web60103.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <krishnamurthydv@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: 6624
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: krishnamurthydv@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,
Any thoughts on this issue?

Thanks
Krishnamurthy


--- Krishnamurthy Daulatabad
<krishnamurthydv@yahoo.com> wrote:

> Hi
>   Request some clarification on the 2.4.20 MIPS
> kernel
> port.
> 
> Specifically refer to function wait_on_irq() in
> arch/mips/kernel/irq.c. This function is called from
> 
> get_irqlock() which in turn is called from
> __global_cli eventually by cli().     
>                                                     
>  
>                                                     
>  
>                                                   
> The
> wait_on_irq() function does not return until "all
> the
> CPUS" have run the ISRs.  To reach this state
> interrupts have to be disabled on all the CPUs and
> then wait for the ISRs to complete.  So __cli()
> function called from this function is supposed to
> disable the interrupts. The __cli() in MIPS will
> disable the Interrupts by resetting the coprocessor
> register's "Interrupt Enable"  bit which is per CPU.
> 
> So this is going to just disable the interrupts on
> the
> current CPU and not others.                         
>  
>                                                     
>  
>                                             
> 
> So in  a SMP system with N CPUs, can there be a
> situation where wait_on_irq() may never return as an
> ISR could be running in one CPU or the other as the
> interrupts are not being disabled on all the CPUs?
> The
> irq_running() function may always return TRUE for a
> large number of CPUs in this case.
> 
> So, is there a problem here or am I missing
> something?
> 
> 2.6 kernel seems to be handling the cli() call
> differently.
> 
> Thanks
> Krishnamurthy
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
> 
> 



		
__________________________________ 
Do you Yahoo!? 
Jazz up your holiday email with celebrity designs. Learn more. 
http://celebrity.mail.yahoo.com

From mlachwani@mvista.com Thu Dec  9 22:22:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 22:22:20 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:62192 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225262AbULIWWP>; Thu, 9 Dec 2004 22:22:15 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id AB15E18303; Thu,  9 Dec 2004 14:21:28 -0800 (PST)
Message-ID: <41B8CFE8.7070503@mvista.com>
Date: Thu, 09 Dec 2004 14:21:28 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org, Manish Lachwani <mlachwani@mvista.com>,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
References: <20041209220930Z8225298-1751+3401@linux-mips.org>
In-Reply-To: <20041209220930Z8225298-1751+3401@linux-mips.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6625
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

ralf@linux-mips.org wrote:
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	04/12/09 22:09:24
> 
> Modified files:
> 	arch/mips/sibyte/sb1250: irq_handler.S 
> 
> Log message:
> 	And yet another build fix.
> 
> 

Hi Ralf

There is one more build fix needed in drivers/net/sb1250-mac.c



if (sbmac_init(dev, idx)) {
			port = A_MAC_CHANNEL_BASE(idx);
			SBMAC_WRITECSR(KSEG1ADDR(port+R_MAC_ETHERNET_ADDR),
					sbmac_orig_hwaddr[idx] );
			free_netdev(dev);
			continue;
		}

If you wish, I can send a patch

Thanks
Manish Lachwani


From p2@mind.be Thu Dec  9 22:36:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 22:36:11 +0000 (GMT)
Received: from NAT.office.mind.be ([IPv6:::ffff:62.166.230.82]:23970 "EHLO
	nat.office.mind.be") by linux-mips.org with ESMTP
	id <S8225306AbULIWgF>; Thu, 9 Dec 2004 22:36:05 +0000
Received: from p2 by codecarver with local (Exim 3.36 #1 (Debian))
	id 1CcWtH-0005JU-00
	for <linux-mips@linux-mips.org>; Thu, 09 Dec 2004 23:36:03 +0100
Date: Thu, 9 Dec 2004 23:36:03 +0100
To: linux-mips@linux-mips.org
Subject: Call for papers embedded track Fosdem 2005 (26-27 feb, Brussels)
Message-ID: <20041209223603.GA20393@mind.be>
Mail-Followup-To: peter.de.schrijver@mind.be, linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf"
Content-Disposition: inline
X-Answer: 42
X-Operating-system: Debian GNU/Linux
X-Message-Flag: Get yourself a real email client. http://www.mutt.org/
X-mate: Mate, man gewoehnt sich an alles
User-Agent: Mutt/1.5.6+20040907i
From: Peter 'p2' De Schrijver <p2@mind.be>
Return-Path: <p2@mind.be>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6626
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: p2@mind.be
Precedence: bulk
X-list: linux-mips


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

Hello all,

At the start of next year FOSDEM, the most important Belgian Free
Software event will be back again. As on the previous occasions there
will also be an embedded track, for which we are looking for speakers.
All the necessary info can be found in the following call for papers.
Feel free to distribute, and tell other people about it.

3th EMBEDDED SYSTEMS and OPERATING SYSTEMS track at FOSDEM 2005
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
26 - 27 February 2005, Brussels

Call for papers
----------------

The 2005 edition of FOSDEM (Free and Open Source Developers' European
Meeting; http://www.fosdem.org) will take place in Brussels, Belgium=20
on 26 and 27 February 2005. For the third time, a track on Embedded=20
Systems and Operating Systems will be organized. The second edition=20
was quite succesful and attracted up to 150 attendants for certain
topics.

For last year's program see:=20
http://www.embedded-kernel-track.org/2004/papers.html

The use of Free Software in the infrastructure of embedded systems=20
is booming, e.g. by the use of Linux, uClinux, eCos, RedBoot, RTEMS=20
and many other Free Software components. More companies are supporting
embedded Free Software each day because of the reliability and cheap
licensing.

Operating system development has always been a very important topic in
Free Software.=20
As embedded and real-time systems typically have special OS requirements,=
=20
we organise this Free Embedded and OS development track at FOSDEM.

This track provides a remarkable opportunity to present and
discuss the ongoing work in these areas, and we invite developers to=20
present their current projects. Technical topics of the conference=20
include but are not limited to :

* OS Development : kernel architecture and implementation, libraries
  (e.g. Linux, BSD, uClinux, uClibc, newlib, ...)

* Practical experiences in implementing Free Software in embedded systems
  (e.g. reverse engineering, porting  to (and adapting of) commercial devic=
es=20
  (IPAQ, Linksys WRT54G,...), ...)

* Toolchain and build environment=20
  (e.g. crosstool, emdebian, openembedded, PTX dist, packaging, scratchbox,=
=20
   Eclipse, Valgrind,...)

* GUIs for embedded systems
  (Gtk, Qt-(embedded), GPE, Qtopia, UI design with touchscreen, ...)

* Multimedia applications for embedded systems
  (e.g. integer-only decoders, Opieplayer, ... )

* Real-time extensions, nanokernels and hardware virtualization software
  (e.g. RTAI, Adeos, KURT, L4, Qemu, Xen, User Mode Linux, ...)
=20
* Hard real-time OS's
  (eCos, RTEMS, ...)

* Open hardware and softcores
  (e.g opencores.org, OpenRISC, LEON, FPGA's, specific design
   restrictions for free systems...)

* Safety and security certifications applied to Free software
  (e.g. security measures in Embedded systems, SSL libraries, ...)

* Free software licenses and embedded systems

Authors are requested to submit their abstracts online to
embedded@fosdem.org before january 3th 2005. Notification of receipt=20
will be sent within 48 hours. Authors wishing to submit a full
paper (between 6 and 12 A4 pages), can do so in PS or PDF format.

The program committee will evaluate the abstracts and consists of:

* Herman Bruyninckx, Professor at K.U.Leuven, Belgium
* Geert Uytterhoeven, Sony NSCE, Belgium
* Karim Yaghmour, Opersys, Canada
* Peter De Schrijver (p2), Mind, Belgium
* Russell King (RMK), ARM Linux Kernel Engineer, Deep Blue Solutions Ltd

Cheers,

Peter (p2).

--J2SCkAp4GZ/dPZZf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFBuNNSKLKVw/RurbsRAsfJAJ9SW5HPJZ0M2+ZhWHBlnxz8sX+TDQCgmQBx
cWRnl7Zi+5LKIUKWD20iyGQ=
=+4Xo
-----END PGP SIGNATURE-----

--J2SCkAp4GZ/dPZZf--

From mstarzewski@xes-inc.com Thu Dec  9 22:49:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 22:49:55 +0000 (GMT)
Received: from xes-inc.com ([IPv6:::ffff:24.196.136.110]:51330 "EHLO
	xes-inc.com") by linux-mips.org with ESMTP id <S8225308AbULIWts>;
	Thu, 9 Dec 2004 22:49:48 +0000
Received: from matts ([10.52.0.13])
	by xes-inc.com (8.11.6/8.11.6) with SMTP id iB9MnjN11321;
	Thu, 9 Dec 2004 16:49:45 -0600
Message-ID: <062301c4de41$5bf43cb0$0d00340a@matts>
From: "Matthew Starzewski" <mstarzewski@xes-inc.com>
To: <linux-mips@linux-mips.org>
Cc: <Steve.Finney@SpirentCom.COM>
Subject: Using more than 256 MB of memory on SB1250 in 32-bit mode, revisited
Date: Thu, 9 Dec 2004 16:49:35 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0620_01C4DE0F.10321590"
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: <mstarzewski@xes-inc.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6627
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mstarzewski@xes-inc.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------=_NextPart_000_0620_01C4DE0F.10321590
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I've tried to enable HIGHMEM to access all 512MB of
SDRAM on a BCM1125 based board as per this previous
thread:

Using more than 256 MB of memory on SB1250 in 32-bit mode :
http://www.spinics.net/lists/mips/msg14396.html
BCM1125 Board: XPedite3000 PrPMC
http://www.xes-inc.com/Products/XPedite/XPedite3000/XPedite3000.html

In MIPS32 mode, the memory map comes out to the following:

Physical Memory Map:
0x00000000 - 0x0FFFFFFF   256MB
0x80000000 - 0x8FFFFFFF   256MB
Virtual Memory Map:
0x80000000 - 0x8FFFFFFF   256MB
<<<< INACCESSIBLE >>>> 256MB

My goal in enabling HIGHMEM was to get at the upper 256MB
much as described here.  Access to the upper 256MB through
HIGHMEM may incur a performance hit, but it's certainly better
going without.

http://home.earthlink.net/~jknapka/linux-mm/vminit.html#PAGING_INIT

However, what I get is a stall as per the log pasted below.  Enabling
CONFIG_64BIT_PHYS_ADDR does not make a difference.  Results
were cross-verified between CFE and another bootloader.

When I hand the physical memory described above off to =
add_memory_region,
I noticed a few odd things. One thing that looks suspicious is that the =
variable
void *high_memory ends up being set to 0xa0000000, or right at KSEG1,
in mm/init.c.

Also, num_physpages became huge, 0x90000, because the init code in
kernel/setup.c and mm/init.c want a page for every memory location, even
highmem.  Is this appropriate when the memory is not directly accessible
via __va and virt_to_phys? =20

This may be an ancillary effect of what's mentioned above, but when =
num_physpages
grows in size, nr_free_pages doesn't track with it, so in void =
vfs_caches_init(unsigned long
mempages) and the like, you get a horrible underflow condition:

/* code */
        printk("MJS - nr_free_pages():0x%X\n", nr_free_pages());
        printk("MJS - OLD mempages:0x%X\n", mempages);
        reserve =3D (mempages - nr_free_pages()) * 3/2;
        mempages -=3D reserve;
        printk("MJS - NEW reserve:0x%X mempages:0x%X\n",
               reserve, mempages);

/* printout */
MJS - nr_free_pages():0x1E9A0
MJS - OLD mempages:0x90000
MJS - NEW reserve:0xAA190 mempages:0xFFFE5E70


Let me know what you think of this issue.  In anticipation of the
"Why not use MIPS64 build?" question, we'd prefer to and will, but the=20
MIPS64 build has underperformed or had bugs (SATA seek time,
networking signals, etc) that MIPS32 doesn't.  For these issues
or any case where the MIPS64 build isn't there yet, it makes
sense to have the MIPS32 path open.

Regards,
Matt


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Kernel Boot Log =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CFE version 1.0.37 for BCM91125E (64bit,SP,BE)
Build Date: Mon Jun 28 18:33:29 CDT 2004 (mstarzewski@lsys1)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.

Initializing Arena.
Initializing Devices.
BCM91125E board revision 1
Config switch: 0
CPU: 1125H A2
L2 Cache: 256KB
SysCfg: 00800000004A0600 [PLL_DIV: 12, IOB0_DIV: CPUCLK/4, IOB1_DIV: =
CPUCLK/3]
CPU type 0x40103: 600MHz
Total memory: 0x20000000 bytes (512MB)

Total memory used by CFE:  0x8FE8AFC0 - 0x90000000 (1527872)
Initialized Data:          0x8FE8AFC0 - 0x8FE94D40 (40320)
BSS Area:                  0x8FE94D40 - 0x8FE95430 (1776)
Local Heap:                0x8FE95430 - 0x8FF95430 (1048576)
Stack Area:                0x8FF95430 - 0x8FF97430 (8192)
Text (code) segment:       0x8FF97440 - 0x8FFFFFB8 (428920)
Boot area (physical):      0x0FE49000 - 0x0FE89000
Relocation Factor:         I:F0397440 - D:0DF8AFC0

CFE> ifconfig eth0 -addr=3D10.52.33.67 -mask=3D255.255.0.0;boot -elf =
10.52.0.4:/home/mstarzewski/li
nux/kernels/mips26_works_cfe/vmlinux
eth0: Link speed: 100BaseT FDX
Device eth0:  hwaddr 40-00-10-06-40-00, ipaddr 10.52.33.67, mask =
255.255.0.0
        gateway not set, nameserver not set
Loader:elf Filesys:tftp Dev:eth0 =
File:10.52.0.4:/home/mstarzewski/linux/kernels/mips26_works_cf
e/vmlinux Options:(null)
Loading: 0xffffffff80100000/2558312 0xffffffff80370968/146032 Entry at =
0xffffffff8032f018
Variable Name        Value
-------------------- --------------------------------------------------
BOOT_CONSOLE         uart0
CPU_TYPE             1125H
CPU_REVISION         A2
CPU_NUM_CORES        1
CPU_SPEED            600
CFE_VERSION          1.0.37
CFE_BOARDNAME        BCM91125E
CFE_MEMORYSIZE       512
NET_DEVICE           eth0
NET_IPADDR           10.52.33.67
NET_NETMASK          255.255.0.0
NET_GATEWAY          0.0.0.0
NET_NAMESERVER       0.0.0.0
BOOT_DEVICE          eth0
BOOT_FILE            =
10.52.0.4:/home/mstarzewski/linux/kernels/mips26_works_cfe/vmlinux
DELETING BOOT_CONSOLE
DELETING CPU_REVISION
DELETING CPU_SPEED
DELETING CFE_BOARDNAME
DELETING NET_DEVICE
DELETING NET_NETMASK
DELETING NET_NAMESERVER
DELETING BOOT_FILE
Variable Name        Value
-------------------- --------------------------------------------------
Closing network.
Starting program at 0xffffffff8032f018
CFE addr:0x000000000FE8A000 size:0x0000000000000000, type:0
CFE addr:0x0000000010000000 size:0x0000000000000000, type:-2147483648
Broadcom SiByte BCM1125H A2 @ 600 MHz (SB1 rev 3)
Board type: SiByte BCM91250A (SWARM)
Linux version 2.6.6-rc3 (mstarzewski@lsys1) (gcc version 3.2.3 with =
SiByte modifications) #17 S
MP Thu Dec 9 11:08:23 CST 2004
CPU revision is: 00040103
FPU revision is: 000f0103
This kernel optimized for board runs with CFE
Determined physical RAM map:
 memory: 0fe89e00 @ 00000000 (usable)
 memory: 0ffffe00 @ 80000000 (usable)
1791MB HIGHMEM available.
On node 0 totalpages: 589823
  DMA zone: 131072 pages, LIFO batch:16
  Normal zone: 0 pages, LIFO batch:1
  HighMem zone: 458751 pages, LIFO batch:16
Built 1 zonelists
Kernel command line: root=3D/dev/nfs ip=3Dauto rw
PID hash table entries: 4096 (order 12: 32768 bytes)
Memory: 495040k/260644k available (1850k kernel code, 27020k reserved, =
382k data, 264k init, 26
2140k highmem)
Calibrating delay loop... 399.36 BogoMIPS

<< STALL >>

------=_NextPart_000_0620_01C4DE0F.10321590
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I've tried to enable HIGHMEM to access =
all 512MB=20
of</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>SDRAM on a BCM1125 based </FONT><FONT =
face=3DArial=20
size=3D2>board as per this previous</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>thread:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Using more than=20
256 MB of memory on SB1250 in 32-bit mode :</FONT></DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.spinics.net/lists/mips/msg14396.html">http://www.spini=
cs.net/lists/mips/msg14396.html</A></FONT></DIV>
<DIV>BCM1125 Board<FONT face=3DArial size=3D2>: XPedite3000 PrPMC</FONT>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.xes-inc.com/Products/XPedite/XPedite3000/XPedite3000.h=
tml">http://www.xes-inc.com/Products/XPedite/XPedite3000/XPedite3000.html=
</A></FONT></DIV></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In MIPS32 mode, the memory map comes =
out to the=20
following:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Physical Memory Map:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>0x00000000 - 0x0FFFFFFF&nbsp;&nbsp;=20
256MB</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>0x80000000 - 0x8FFFFFFF&nbsp;&nbsp;=20
256MB</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Virtual Memory Map:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>0x80000000 - 0x8FFFFFFF&nbsp;&nbsp;=20
256MB</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&lt;&lt;&lt;&lt; INACCESSIBLE =
&gt;&gt;&gt;&gt;=20
256MB</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My goal in enabling HIGHMEM was to get =
at the upper=20
256MB</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>much as described here.&nbsp; Access to =
the upper=20
256MB through</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>HIGHMEM may incur a performance hit, =
but it's=20
certainly better</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>going without.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://home.earthlink.net/~jknapka/linux-mm/vminit.html#PAGING_IN=
IT">http://home.earthlink.net/~jknapka/linux-mm/vminit.html#PAGING_INIT</=
A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>However, what I get is a stall as per =
the log=20
pasted below.&nbsp; Enabling</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CONFIG_64BIT_PHYS_ADDR does not make a=20
difference.&nbsp; </FONT><FONT face=3DArial =
size=3D2>Results</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>were cross-verified between CFE and =
another=20
bootloader.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>When I hand </FONT><FONT face=3DArial =
size=3D2>the=20
physical memory described above off to add_memory_region,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I noticed a few odd things. One thing =
that looks=20
suspicious is that the <FONT face=3DArial =
size=3D2>variable</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>void =
*high_memory ends up=20
being set to 0xa0000000, or right at KSEG1,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>in mm/init.c.</FONT></DIV></FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Also, num_physpages became huge, =
0x90000, because=20
the </FONT><FONT face=3DArial size=3D2>init code in</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>kernel/setup.c and mm/init.c want a =
page for every=20
memory location, </FONT><FONT face=3DArial size=3D2>even</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>highmem.&nbsp; Is this appropriate when =
the memory=20
is not directly accessible</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>via __va and virt_to_phys?&nbsp; =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This may be an ancillary effect of =
what's mentioned=20
above, but when num_physpages</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>grows in size, nr_free_pages doesn't =
track with it,=20
so in void vfs_caches_init(unsigned long</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>mempages) and the like, you get a =
horrible=20
underflow condition:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>/* code */</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
printk("MJS - nr_free_pages():0x%X\n",=20
nr_free_pages());<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
printk("MJS -=20
OLD mempages:0x%X\n", mempages);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;=20
reserve =3D (mempages - nr_free_pages()) *=20
3/2;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mempages -=3D=20
reserve;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; printk("MJS - NEW =

reserve:0x%X=20
mempages:0x%X\n",<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
reserve, mempages);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR>/* printout */</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>MJS - nr_free_pages():0x1E9A0<BR>MJS - =
OLD=20
mempages:0x90000<BR>MJS - NEW reserve:0xAA190=20
mempages:0xFFFE5E70<BR></FONT><FONT face=3DArial size=3D2></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</DIV></FONT>
<DIV><FONT face=3DArial size=3D2>Let me know what you think of this =
issue.&nbsp; In=20
anticipation of the</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>"Why not use MIPS64 build?" question, =
we'd prefer=20
to and will, but the </FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT>MIPS64 build has =
underperformed or had=20
bugs (SATA seek time,</FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT>networking signals, etc) =
that MIPS32=20
doesn't</FONT></FONT></FONT><FONT face=3DArial size=3D2>.&nbsp; For =
these=20
issues</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>or any case where the MIPS64 build =
isn't there yet,=20
it makes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>sense to have the MIPS32 path =
open.</FONT></DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Matt</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
Kernel Boot Log=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>CFE version 1.0.37 for BCM91125E=20
(64bit,SP,BE)<BR>Build Date: Mon Jun 28 18:33:29 CDT 2004 (</FONT><A=20
href=3D"mailto:mstarzewski@lsys1"><FONT face=3DArial=20
size=3D2>mstarzewski@lsys1</FONT></A><FONT face=3DArial =
size=3D2>)<BR>Copyright (C)=20
2000,2001,2002,2003 Broadcom Corporation.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Initializing Arena.<BR>Initializing=20
Devices.<BR>BCM91125E board revision 1<BR>Config switch: 0<BR>CPU: 1125H =

A2<BR>L2 Cache: 256KB<BR>SysCfg: 00800000004A0600 [PLL_DIV: 12, =
IOB0_DIV:=20
CPUCLK/4, IOB1_DIV: CPUCLK/3]<BR>CPU type 0x40103: 600MHz<BR>Total =
memory:=20
0x20000000 bytes (512MB)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Total memory used by CFE:&nbsp; =
0x8FE8AFC0 -=20
0x90000000 (1527872)<BR>Initialized=20
Data:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x8FE8AFC0 - =

0x8FE94D40 (40320)<BR>BSS=20
Area:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0x8FE94D40 - 0x8FE95430 (1776)<BR>Local=20
Heap:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
0x8FE95430 - 0x8FF95430 (1048576)<BR>Stack=20
Area:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
0x8FF95430 - 0x8FF97430 (8192)<BR>Text (code)=20
segment:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x8FF97440 - 0x8FFFFFB8=20
(428920)<BR>Boot area (physical):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0x0FE49000 -=20
0x0FE89000<BR>Relocation =
Factor:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
I:F0397440 - D:0DF8AFC0</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>CFE&gt; ifconfig eth0 =
-addr=3D10.52.33.67=20
-mask=3D255.255.0.0;boot -elf=20
10.52.0.4:/home/mstarzewski/li<BR>nux/kernels/mips26_works_cfe/vmlinux<BR=
>eth0:=20
Link speed: 100BaseT FDX<BR>Device eth0:&nbsp; hwaddr 40-00-10-06-40-00, =
ipaddr=20
10.52.33.67, mask =
255.255.0.0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
gateway not set, nameserver not set<BR>Loader:elf Filesys:tftp Dev:eth0=20
File:10.52.0.4:/home/mstarzewski/linux/kernels/mips26_works_cf<BR>e/vmlin=
ux=20
Options:(null)<BR>Loading: 0xffffffff80100000/2558312 =
0xffffffff80370968/146032=20
Entry at 0xffffffff8032f018<BR>Variable=20
Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Value<BR>--------------------=20
--------------------------------------------------<BR>BOOT_CONSOLE&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
uart0<BR>CPU_TYPE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
1125H<BR>CPU_REVISION&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
A2<BR>CPU_NUM_CORES&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1<BR>CPU_SPEED&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
600<BR>CFE_VERSION&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

1.0.37<BR>CFE_BOARDNAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
BCM91125E<BR>CFE_MEMORYSIZE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
512<BR>NET_DEVICE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
eth0<BR>NET_IPADDR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
10.52.33.67<BR>NET_NETMASK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
255.255.0.0<BR>NET_GATEWAY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
0.0.0.0<BR>NET_NAMESERVER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0.0.0.0<BR>BOOT_DEVICE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
eth0<BR>BOOT_FILE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
10.52.0.4:/home/mstarzewski/linux/kernels/mips26_works_cfe/vmlinux<BR>DEL=
ETING=20
BOOT_CONSOLE<BR>DELETING CPU_REVISION<BR>DELETING CPU_SPEED<BR>DELETING=20
CFE_BOARDNAME<BR>DELETING NET_DEVICE<BR>DELETING NET_NETMASK<BR>DELETING =

NET_NAMESERVER<BR>DELETING BOOT_FILE<BR>Variable=20
Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Value<BR>--------------------=20
--------------------------------------------------<BR>Closing=20
network.<BR>Starting program at 0xffffffff8032f018<BR>CFE=20
addr:0x000000000FE8A000 size:0x0000000000000000, type:0<BR>CFE=20
addr:0x0000000010000000 size:0x0000000000000000, =
type:-2147483648<BR>Broadcom=20
SiByte BCM1125H A2 @ 600 MHz (SB1 rev 3)<BR>Board type: SiByte BCM91250A =

(SWARM)<BR>Linux version 2.6.6-rc3 (</FONT><A=20
href=3D"mailto:mstarzewski@lsys1"><FONT face=3DArial=20
size=3D2>mstarzewski@lsys1</FONT></A><FONT face=3DArial size=3D2>) (gcc =
version 3.2.3=20
with SiByte modifications) #17 S<BR>MP Thu Dec 9 11:08:23 CST =
2004<BR>CPU=20
revision is: 00040103<BR>FPU revision is: 000f0103<BR>This kernel =
optimized for=20
board runs with CFE<BR>Determined physical RAM map:<BR>&nbsp;memory: =
0fe89e00 @=20
00000000 (usable)<BR>&nbsp;memory: 0ffffe00 @ 80000000 =
(usable)<BR>1791MB=20
HIGHMEM available.<BR>On node 0 totalpages: 589823<BR>&nbsp; DMA zone: =
131072=20
pages, LIFO batch:16<BR>&nbsp; Normal zone: 0 pages, LIFO =
batch:1<BR>&nbsp;=20
HighMem zone: 458751 pages, LIFO batch:16<BR>Built 1 zonelists<BR>Kernel =
command=20
line: root=3D/dev/nfs ip=3Dauto rw<BR>PID hash table entries: 4096 =
(order 12: 32768=20
bytes)<BR>Memory: 495040k/260644k available (1850k kernel code, 27020k =
reserved,=20
382k data, 264k init, 26<BR>2140k highmem)<BR>Calibrating delay loop... =
399.36=20
BogoMIPS</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&lt;&lt; STALL=20
&gt;&gt;</FONT></DIV></DIV></BODY></HTML>

------=_NextPart_000_0620_01C4DE0F.10321590--


From gmuruga@gdatech.com Thu Dec  9 23:26:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 23:26:48 +0000 (GMT)
Received: from darwaza.gdatech.com ([IPv6:::ffff:66.237.41.98]:9543 "EHLO
	kings.gdatech.com") by linux-mips.org with ESMTP
	id <S8225308AbULIX0m>; Thu, 9 Dec 2004 23:26:42 +0000
Received: from kings.gdatech.com (localhost.localdomain [127.0.0.1])
	by kings.gdatech.com (Postfix) with ESMTP id A565F61C0E7;
	Thu,  9 Dec 2004 15:21:33 -0800 (PST)
X-Propel-Return-Path: <gmuruga@gdatech.com>
Received: from kings.gdatech.com ([192.168.200.118])
	by localhost.localdomain ([127.0.0.1]) (port 7027) (Propel SE relay 0.1.0.1557 $Rev$)
	id r4cI152133-1395-1
	for linux-mips@linux-mips.org mlachwani@mvista.com; Thu, 09 Dec 2004 15:21:33 -0800
Received: from sierra.gdatech.com (asg_mda [192.168.200.112])
	by kings.gdatech.com (Postfix) with ESMTP id 64D2861C0E6;
	Thu,  9 Dec 2004 15:21:33 -0800 (PST)
Received: (from nobody@localhost)
	by gdatech.com (8.11.6/8.11.6) id iB9NMcS12782;
	Thu, 9 Dec 2004 15:22:38 -0800
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: gdatech.com
Date: Thu, 9 Dec 2004 15:22:38 -0800
Message-Id: <200412092322.iB9NMcS12782@gdatech.com>
X-Authentication-Warning: sierra.gdatech.com: nobody set sender to gmuruga@gdatech.com using -f
From: "Muruga Ganapathy" <gmuruga@gdatech.com>
To: Manish Lachwani <mlachwani@mvista.com>,
	Muruga Ganapathy <gmuruga@gdatech.com>,
	linux-mips@linux-mips.org
Subject: Re: Forcing IDE to work in PIO mode
X-Mailer: NeoMail 1.25
X-IPAddress: 63.111.213.196
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Return-Path: <gmuruga@gdatech.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: 6628
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gmuruga@gdatech.com
Precedence: bulk
X-list: linux-mips

Manish, 

My previous mail was based on the sources from kernerl.org and the dmesg
below. 

Thanks
G.Muruganandam

=======================================================
Linux version 2.4.27-sb1-swarm-bn (root@hattusa) (gcc version 3.3.4 (Debian

1:34

swarm setup: M41T81 RTC detected.

This kernel optimized for board runs with CFE

Determined physical RAM map:

 memory: 003b0000 @ 00000000 (usable)

 memory: 0f254400 @ 00c36c00 (usable)

 memory: 00886c00 @ 003b0000 (reserved)

hm, page 003b0000 reserved twice.

hm, page 003b1000 reserved twice.

Initial ramdisk at: 0x803b0000 (8940544 bytes)

On node 0 totalpages: 65163

zone(0): 65163 pages.

zone(1): 0 pages.

zone(2): 0 pages.

Kernel command line: root=/dev/ram console=duart0 initrd=886C00@803B0000

Console: colour dummy device 80x25

Calibrating delay loop... 532.48 BogoMIPS

Memory: 245068k/251920k available (2077k kernel code, 6860k reserved, 120k

data)

Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)

Inode cache hash table entries: 16384 (order: 5, 131072 bytes)

Mount cache hash table entries: 512 (order: 0, 4096 bytes)

Buffer cache hash table entries: 16384 (order: 4, 65536 bytes)

Page-cache hash table entries: 65536 (order: 6, 262144 bytes)

Checking for 'wait' instruction...  unavailable.

POSIX conformance testing by UNIFIX

Detected 2 available CPU(s)

Starting CPU 1... Slave cpu booted successfully

Waiting on wait_init_idle (map = 0x2)

All processors have done init_idle

PCI: Skipping PCI probe.  Bus is not initialized.

Linux NET4.0 for Linux 2.4

Based upon Swansea University Computer Society NET3.039

Initializing RT netlink socket

Starting kswapd

VFS: Disk quotas vdquot_6.5.1

Journalled Block Device driver loaded

devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)

devfs: boot_options: 0x0

Dummy keyboard driver installed.

pty: 256 Unix98 ptys configured

Generic MIPS RTC Driver v1.0

RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize

eth0: SiByte Ethernet at 0x10064000, address: 00-02-4C-FE-0D-D6

eth0: enabling TCP rcv checksum

eth1: SiByte Ethernet at 0x10065000, address: 00-02-4C-FE-0D-D7

eth1: enabling TCP rcv checksum

Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4

ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx

SiByte onboard IDE configured as device 0

Linux Kernel Card Services 3.1.22

  options:  [pci] [cardbus]

sibyte-pcmcia: Looking up addr 0x10061130: 0x03ff (IO size)

sibyte-pcmcia: Looking up addr 0x10061230: 0x1100 (IO Base Address)

sibyte-pcmcia: Memory region 0x11000000 of size 0x04000000 requested.

sibyte-pcmcia: Setting up "sb1250pc" procfs entry

SiByte onboard PCMCIA-IDE configured as device 1

mice: PS/2 mouse device common for all mice

Initializing Cryptographic API

NET4: Linux TCP/IP 1.0 for NET4.0

IP: routing cache hash table of 2048 buckets, 16Kbytes

TCP: Hash tables configured (established 16384 bind 16384)





> Please point me to the 2.4.26 or 2.4.27 code that you are referring to
> 
> Thanks
> Manish Lachwani
> 
> Muruga Ganapathy wrote:
> > Manish, 
> > 
> > Thanks for the pointer.
> > 
> > I am looking for the PCMCIA-IDE driver for the SWARM board in 2.6.x
> > I did see this driver in 2.4.26/27 but not in 2.6.10.
> > 
> > Do you have any suggestions on porting the PCMCIA-IDE driver from 2.4.27
> > to 2.6.x?
> > 
> > Regards
> > G.Muruganandam
> > 
> > 
> >>I had posted a patch to this mailing list a few days back. The patch 
> >>applies cleanly to the current tree and is currently checked in: 
> >>drivers/ide/mips/swarm.c
> >>
> >>Using this patch, Broadcom SWARM IDE works well
> >>
> >>Thanks
> >>Manish Lachwani
> >>
> >>Muruga Ganapathy wrote:
> >>
> >>>Thanks Manish for the information.  
> >>> 
> >>>BTW, do you have patch to make the swarm IDE work in 2.6.6-rc3 
> >>> 
> >>>Regards 
> >>>G.Muruganandam 
> >>> 
> >>> 
> >>>
> >>>
> >>>>Muruga Ganapathy wrote: 
> >>>>
> >>>>
> >>>>>Hello,  
> >>>>>
> >>>>>How do I force the IDE to work in the PIO mode by including the  
> >>>>>option like "hdb=noprobe" in the setup.c? 
> >>>>>
> >>>>>
> >>>>>My kernel version is 2.6.6 
> >>>>>
> >>>>>Thanks 
> >>>>>G.Muruganandam 
> >>>>>
> >>>>
> >>>>
> >>>>Hello ! 
> >>>>
> >>>>I would have thought "ide=nodma" at the command line would have 
> >>>
> >>>worked 
> >>>
> >>>
> >>>>Thanks 
> >>>>Manish Lachwani 
> >>>>
> >>>>
> >>>
> >>> 
> >>>************************************************************* 
> >>>GDA Technologies, Inc.		 
> >>>1010 Rincon Circle  
> >>>San Jose CA, 95131 
> >>>Phone	(408) 432-3090 
> >>>Fax	(408) 432-3091 
> >>> 
> >>>Accelerate Your Innovation	 
> >>>************************************************************** 
> >>
**

From mlachwani@mvista.com Thu Dec  9 23:57:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Dec 2004 23:58:05 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:15355 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225308AbULIX57>; Thu, 9 Dec 2004 23:57:59 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id 8CE361854C; Thu,  9 Dec 2004 15:57:57 -0800 (PST)
Message-ID: <41B8E685.6030808@mvista.com>
Date: Thu, 09 Dec 2004 15:57:57 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Muruga Ganapathy <gmuruga@gdatech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Forcing IDE to work in PIO mode
References: <200412092322.iB9NMcS12782@gdatech.com>
In-Reply-To: <200412092322.iB9NMcS12782@gdatech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6629
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

The pcmcia support for the SWARM is provided by 
drivers/pcmcia/sibyte_generic.c in 2.4.26

This file (and may be others it depends on) does not exist in 2.6

Thanks
Manish Lachwani



Muruga Ganapathy wrote:
> Manish, 
> 
> My previous mail was based on the sources from kernerl.org and the dmesg
> below. 
> 
> Thanks
> G.Muruganandam
> 
> =======================================================
> Linux version 2.4.27-sb1-swarm-bn (root@hattusa) (gcc version 3.3.4 (Debian
> 
> 1:34
> 
> swarm setup: M41T81 RTC detected.
> 
> This kernel optimized for board runs with CFE
> 
> Determined physical RAM map:
> 
>  memory: 003b0000 @ 00000000 (usable)
> 
>  memory: 0f254400 @ 00c36c00 (usable)
> 
>  memory: 00886c00 @ 003b0000 (reserved)
> 
> hm, page 003b0000 reserved twice.
> 
> hm, page 003b1000 reserved twice.
> 
> Initial ramdisk at: 0x803b0000 (8940544 bytes)
> 
> On node 0 totalpages: 65163
> 
> zone(0): 65163 pages.
> 
> zone(1): 0 pages.
> 
> zone(2): 0 pages.
> 
> Kernel command line: root=/dev/ram console=duart0 initrd=886C00@803B0000
> 
> Console: colour dummy device 80x25
> 
> Calibrating delay loop... 532.48 BogoMIPS
> 
> Memory: 245068k/251920k available (2077k kernel code, 6860k reserved, 120k
> 
> data)
> 
> Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
> 
> Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
> 
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
> 
> Buffer cache hash table entries: 16384 (order: 4, 65536 bytes)
> 
> Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
> 
> Checking for 'wait' instruction...  unavailable.
> 
> POSIX conformance testing by UNIFIX
> 
> Detected 2 available CPU(s)
> 
> Starting CPU 1... Slave cpu booted successfully
> 
> Waiting on wait_init_idle (map = 0x2)
> 
> All processors have done init_idle
> 
> PCI: Skipping PCI probe.  Bus is not initialized.
> 
> Linux NET4.0 for Linux 2.4
> 
> Based upon Swansea University Computer Society NET3.039
> 
> Initializing RT netlink socket
> 
> Starting kswapd
> 
> VFS: Disk quotas vdquot_6.5.1
> 
> Journalled Block Device driver loaded
> 
> devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
> 
> devfs: boot_options: 0x0
> 
> Dummy keyboard driver installed.
> 
> pty: 256 Unix98 ptys configured
> 
> Generic MIPS RTC Driver v1.0
> 
> RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
> 
> eth0: SiByte Ethernet at 0x10064000, address: 00-02-4C-FE-0D-D6
> 
> eth0: enabling TCP rcv checksum
> 
> eth1: SiByte Ethernet at 0x10065000, address: 00-02-4C-FE-0D-D7
> 
> eth1: enabling TCP rcv checksum
> 
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
> 
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> 
> SiByte onboard IDE configured as device 0
> 
> Linux Kernel Card Services 3.1.22
> 
>   options:  [pci] [cardbus]
> 
> sibyte-pcmcia: Looking up addr 0x10061130: 0x03ff (IO size)
> 
> sibyte-pcmcia: Looking up addr 0x10061230: 0x1100 (IO Base Address)
> 
> sibyte-pcmcia: Memory region 0x11000000 of size 0x04000000 requested.
> 
> sibyte-pcmcia: Setting up "sb1250pc" procfs entry
> 
> SiByte onboard PCMCIA-IDE configured as device 1
> 
> mice: PS/2 mouse device common for all mice
> 
> Initializing Cryptographic API
> 
> NET4: Linux TCP/IP 1.0 for NET4.0
> 
> IP: routing cache hash table of 2048 buckets, 16Kbytes
> 
> TCP: Hash tables configured (established 16384 bind 16384)
> 
> 
> 
> 
> 
> 
>>Please point me to the 2.4.26 or 2.4.27 code that you are referring to
>>
>>Thanks
>>Manish Lachwani
>>
>>Muruga Ganapathy wrote:
>>
>>>Manish, 
>>>
>>>Thanks for the pointer.
>>>
>>>I am looking for the PCMCIA-IDE driver for the SWARM board in 2.6.x
>>>I did see this driver in 2.4.26/27 but not in 2.6.10.
>>>
>>>Do you have any suggestions on porting the PCMCIA-IDE driver from 2.4.27
>>>to 2.6.x?
>>>
>>>Regards
>>>G.Muruganandam
>>>
>>>
>>>
>>>>I had posted a patch to this mailing list a few days back. The patch 
>>>>applies cleanly to the current tree and is currently checked in: 
>>>>drivers/ide/mips/swarm.c
>>>>
>>>>Using this patch, Broadcom SWARM IDE works well
>>>>
>>>>Thanks
>>>>Manish Lachwani
>>>>
>>>>Muruga Ganapathy wrote:
>>>>
>>>>
>>>>>Thanks Manish for the information.  
>>>>>
>>>>>BTW, do you have patch to make the swarm IDE work in 2.6.6-rc3 
>>>>>
>>>>>Regards 
>>>>>G.Muruganandam 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Muruga Ganapathy wrote: 
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hello,  
>>>>>>>
>>>>>>>How do I force the IDE to work in the PIO mode by including the  
>>>>>>>option like "hdb=noprobe" in the setup.c? 
>>>>>>>
>>>>>>>
>>>>>>>My kernel version is 2.6.6 
>>>>>>>
>>>>>>>Thanks 
>>>>>>>G.Muruganandam 
>>>>>>>
>>>>>>
>>>>>>
>>>>>>Hello ! 
>>>>>>
>>>>>>I would have thought "ide=nodma" at the command line would have 
>>>>>
>>>>>worked 
>>>>>
>>>>>
>>>>>
>>>>>>Thanks 
>>>>>>Manish Lachwani 
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>************************************************************* 
>>>>>GDA Technologies, Inc.		 
>>>>>1010 Rincon Circle  
>>>>>San Jose CA, 95131 
>>>>>Phone	(408) 432-3090 
>>>>>Fax	(408) 432-3091 
>>>>>
>>>>>Accelerate Your Innovation	 
>>>>>************************************************************** 
>>>>
> **



From anemo@mba.ocn.ne.jp Fri Dec 10 05:12:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Dec 2004 05:12:37 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:31001
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224770AbULJFMc>; Fri, 10 Dec 2004 05:12:32 +0000
Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 10 Dec 2004 05:12:30 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by newms.toshiba-tops.co.jp (Postfix) with ESMTP
	id 07674239E3D; Fri, 10 Dec 2004 14:12:27 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id iBA5CQdD084428;
	Fri, 10 Dec 2004 14:12:26 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 10 Dec 2004 14:12:26 +0900 (JST)
Message-Id: <20041210.141226.01918307.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
Subject: show_stack, show_trace does not work for other process
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6630
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

On kernel 2.6, SysRq-T (show_task()) can not show correct stack dump
because show_stack() ignores an 'task' argument.  Here is a patch.  I
fixed show_trace too.

--- linux-mips/arch/mips/kernel/traps.c	2004-11-29 11:23:20.000000000 +0900
+++ linux/arch/mips/kernel/traps.c	2004-12-10 14:01:09.078969122 +0900
@@ -82,7 +82,12 @@
 	long stackdata;
 	int i;
 
-	sp = sp ? sp : (unsigned long *) &sp;
+	if (!sp) {
+		if (task && task != current)
+			sp = (unsigned long *) task->thread.reg29;
+		else
+			sp = (unsigned long *) &sp;
+	}
 
 	printk("Stack :");
 	i = 0;
@@ -110,8 +115,12 @@
 	const int field = 2 * sizeof(unsigned long);
 	unsigned long addr;
 
-	if (!stack)
-		stack = (unsigned long*)&stack;
+	if (!stack) {
+		if (task && task != current)
+			stack = (unsigned long *) task->thread.reg29;
+		else
+			stack = (unsigned long *) &stack;
+	}
 
 	printk("Call Trace:");
 #ifdef CONFIG_KALLSYMS

From ica2_ts@csv.ica.uni-stuttgart.de Fri Dec 10 06:25:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Dec 2004 06:25:39 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:42343
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224907AbULJGZa>; Fri, 10 Dec 2004 06:25:30 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CceDU-0000wr-00; Fri, 10 Dec 2004 07:25:24 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CceDT-0005PK-00; Fri, 10 Dec 2004 07:25:23 +0100
Date: Fri, 10 Dec 2004 07:25:23 +0100
To: Pete Popov <ppopov@embeddedalley.com>
Cc: linux-mips@linux-mips.org
Subject: Re: fyi, syscall() somehow broken...
Message-ID: <20041210062523.GE8419@rembrandt.csv.ica.uni-stuttgart.de>
References: <1102602117.28707.49.camel@shswe.inso.tuwien.ac.at> <41B86E7D.3000609@embeddedalley.com> <20041209154405.GB8419@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041209154405.GB8419@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6631
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Thiemo Seufer wrote:
> Pete Popov wrote:
> > 
> > >jfyi, something broke w/ the following commit... most notably 'ls -l'
> > >doesn't work anymore... reverting to yesterdays cvs state fixes the
> > >issues... ;-)
> 
> Confirmed on a SGI Indy with 32bit kernel. sys_quotactl seems to be
> broken, while the rest of the system appears to work well.
> I'll have a look.

I just committed a fix.


Thiemo

From thomas.petazzoni@enix.org Fri Dec 10 08:45:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Dec 2004 08:45:41 +0000 (GMT)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:7652 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8225210AbULJIpg>; Fri, 10 Dec 2004 08:45:36 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by the-doors.enix.org (Postfix) with ESMTP id E28871ED43;
	Fri, 10 Dec 2004 09:44:50 +0100 (CET)
Message-ID: <41B96281.2050806@enix.org>
Date: Fri, 10 Dec 2004 09:46:57 +0100
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040926)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Matthew Starzewski <mstarzewski@xes-inc.com>
Cc: linux-mips@linux-mips.org, Steve.Finney@SpirentCom.COM
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode, revisited
References: <062301c4de41$5bf43cb0$0d00340a@matts>
In-Reply-To: <062301c4de41$5bf43cb0$0d00340a@matts>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig256EBE984477A4D7916A1FA9"
Content-Transfer-Encoding: 8bit
Return-Path: <thomas.petazzoni@enix.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: 6632
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thomas.petazzoni@enix.org
Precedence: bulk
X-list: linux-mips

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig256EBE984477A4D7916A1FA9
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

Matthew Starzewski a écrit :
> I've tried to enable HIGHMEM to access all 512MB of
> SDRAM on a BCM1125 based board as per this previous
> thread:
>  
> Using more than 256 MB of memory on SB1250 in 32-bit mode :
> http://www.spinics.net/lists/mips/msg14396.html
> BCM1125 Board: XPedite3000 PrPMC
> http://www.xes-inc.com/Products/XPedite/XPedite3000/XPedite3000.html

I'm really unsure of what I'll say, but I've seen people on this list 
talking about CONFIG_DISCONTIGMEM, an option for the kernel, which is :

"Say Y to upport efficient handling of discontiguous physical memory,
  for architectures which are either NUMA (Non-Uniform Memory Access)
  or have huge holes in the physical address space for other reasons.
  See <file:Documentation/vm/numa> for more."

Maybe it's what you're looking for, maybe not.

I'm still very surprised that Linux cannot handle strange physical 
memory configuration simply (holes in physical memory, DMA memory at 
higher addresses than normal memory).

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org
http://thomas.enix.org - Jabber: thomas.petazzoni@jabber.dk
http://kos.enix.org, http://sos.enix.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

--------------enig256EBE984477A4D7916A1FA9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBuWKE9lPLMJjT96cRAhepAKCJXMrSWgpCpPzY5te6FaRItuB9MwCfd5v+
wc8HN2ZcddQrQosHBnkMQXs=
=RAZP
-----END PGP SIGNATURE-----

--------------enig256EBE984477A4D7916A1FA9--

From macro@linux-mips.org Fri Dec 10 13:03:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Dec 2004 13:03:16 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:20242 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225210AbULJNDL>; Fri, 10 Dec 2004 13:03:11 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id E3090F5944; Fri, 10 Dec 2004 14:03:02 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 30765-07; Fri, 10 Dec 2004 14:03:02 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id F3281E1CC6; Fri, 10 Dec 2004 14:03:01 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iBAD32lI028340;
	Fri, 10 Dec 2004 14:03:05 +0100
Date: Fri, 10 Dec 2004 13:02:55 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Thomas Petazzoni <thomas.petazzoni@enix.org>
Cc: Matthew Starzewski <mstarzewski@xes-inc.com>,
	linux-mips@linux-mips.org, Steve.Finney@SpirentCom.COM
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode,
 revisited
In-Reply-To: <41B96281.2050806@enix.org>
Message-ID: <Pine.LNX.4.58L.0412101250160.15484@blysk.ds.pg.gda.pl>
References: <062301c4de41$5bf43cb0$0d00340a@matts> <41B96281.2050806@enix.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/617/Sun Dec  5 16:25:39 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6633
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, 10 Dec 2004, Thomas Petazzoni wrote:

> I'm still very surprised that Linux cannot handle strange physical 
> memory configuration simply (holes in physical memory, DMA memory at 
> higher addresses than normal memory).

 That's i386 legacy, later supported by other platforms using a similar
memory model -- starting at 0, mostly contiguous and only two DMA zones
for ISA and 32-bit PCI respectively, both starting at 0.  Remember, most
people working on Linux only have an i386 PC.  If you have something very
different, you need to write code to support it yourself.  If you do it
well enough, it'll be gladly accepted.

  Maciej

From mstarzewski@xes-inc.com Fri Dec 10 14:47:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Dec 2004 14:47:18 +0000 (GMT)
Received: from xes-inc.com ([IPv6:::ffff:24.196.136.110]:3985 "EHLO
	xes-inc.com") by linux-mips.org with ESMTP id <S8225355AbULJOrN>;
	Fri, 10 Dec 2004 14:47:13 +0000
Received: from matts ([10.52.0.13])
	by xes-inc.com (8.11.6/8.11.6) with SMTP id iBAEktN20541;
	Fri, 10 Dec 2004 08:46:59 -0600
Message-ID: <073a01c4dec7$184527a0$0d00340a@matts>
From: "Matthew Starzewski" <mstarzewski@xes-inc.com>
To: "Thomas Petazzoni" <thomas.petazzoni@enix.org>
Cc: <linux-mips@linux-mips.org>
References: <062301c4de41$5bf43cb0$0d00340a@matts> <41B96281.2050806@enix.org>
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode, revisited
Date: Fri, 10 Dec 2004 08:46:52 -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: <mstarzewski@xes-inc.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6634
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mstarzewski@xes-inc.com
Precedence: bulk
X-list: linux-mips


> I'm really unsure of what I'll say, but I've seen people on this list
> talking about CONFIG_DISCONTIGMEM, an option for the kernel, which is :
>
> "Say Y to upport efficient handling of discontiguous physical memory,
>  for architectures which are either NUMA (Non-Uniform Memory Access)
>   or have huge holes in the physical address space for other reasons.
>  See <file:Documentation/vm/numa> for more."

I've tried using DISCONTIGMEM on the MIPS32 build, but it yields the
following build error.  Maybe someone familiar w/ the SGI IP27 (Origin 200
and
2000) code could tell us whether simply turning on DISCONTIGMEM is
a good idea.

include/linux/mmzone.h:364:2: #error NODES_SHIFT > MAX_NODES_SHIFT

Also, even if it compiled with DISCONTIGMEM, a look at
sgi-ip27/ip27-memory.c
shows no sign of HIGHMEM support, what I was depending on to use the upper
256MB of memory as per my original email.  Now this may be OK; depending on
how
flexible the DISCONTIGMEM option is, perhaps I could map a wired TLB or
KSEG3
to the 2nd 256MB.

Thoughts?

Matt


----- Original Message -----
From: "Thomas Petazzoni" <thomas.petazzoni@enix.org>
To: "Matthew Starzewski" <mstarzewski@xes-inc.com>
Cc: <linux-mips@linux-mips.org>; <Steve.Finney@SpirentCom.COM>
Sent: Friday, December 10, 2004 2:46 AM
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode,
revisited




From thomas.petazzoni@enix.org Fri Dec 10 16:09:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Dec 2004 16:09:07 +0000 (GMT)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:9710 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8225355AbULJQJD>; Fri, 10 Dec 2004 16:09:03 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by the-doors.enix.org (Postfix) with ESMTP id 3D4171ED32;
	Fri, 10 Dec 2004 17:08:04 +0100 (CET)
Message-ID: <41B9CA72.7030208@enix.org>
Date: Fri, 10 Dec 2004 17:10:26 +0100
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040926)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Matthew Starzewski <mstarzewski@xes-inc.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode, revisited
References: <062301c4de41$5bf43cb0$0d00340a@matts> <41B96281.2050806@enix.org> <073a01c4dec7$184527a0$0d00340a@matts>
In-Reply-To: <073a01c4dec7$184527a0$0d00340a@matts>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig840F58AE2DDDA9A2355DA08F"
Content-Transfer-Encoding: 8bit
Return-Path: <thomas.petazzoni@enix.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: 6635
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thomas.petazzoni@enix.org
Precedence: bulk
X-list: linux-mips

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig840F58AE2DDDA9A2355DA08F
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

Matthew Starzewski a écrit :

> Thoughts?

Did you look at 
http://www.linux-mips.org/archives/linux-mips/2004-12/msg00053.html and 
more particularly 
http://www.linux-mips.org/archives/linux-mips/2004-12/msg00053.html ?

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org
http://thomas.enix.org - Jabber: thomas.petazzoni@jabber.dk
http://kos.enix.org, http://sos.enix.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

--------------enig840F58AE2DDDA9A2355DA08F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBucpy9lPLMJjT96cRAiYUAJ0VZcfI36hrlcAMBgJK+Re4E1m+bgCffOOs
1XjgkgQk/dbBN76c+pjCwYQ=
=FErr
-----END PGP SIGNATURE-----

--------------enig840F58AE2DDDA9A2355DA08F--

From christian.gan@librestream.com Fri Dec 10 19:59:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Dec 2004 19:59:24 +0000 (GMT)
Received: from 205-200-7-228.static.mts.net ([IPv6:::ffff:205.200.7.228]:37455
	"EHLO librestream.com") by linux-mips.org with ESMTP
	id <S8225426AbULJT7S>; Fri, 10 Dec 2004 19:59:18 +0000
X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
Subject: SM501 PCI Driver
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4DEF2.BAB7CDE3"
Date: Fri, 10 Dec 2004 13:59:16 -0600
Message-ID: <8230E1CC35AF9F43839F3049E930169A0A2766@yang.LibreStream.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SM501 PCI Driver
thread-index: AcTe8rqRrkbzBWQiSa636+H8Q0L9wg==
From: "Christian Gan" <christian.gan@librestream.com>
To: <linux-mips@linux-mips.org>
Return-Path: <christian.gan@librestream.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: 6646
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: christian.gan@librestream.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4DEF2.BAB7CDE3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Quick question,

Does anyone know of any 2.6.X fb drivers for a Silicon Motion SM501 PCI =
driver?  The 2.6 driver listed on their web site seems incomplete (only =
supports 640x480).

Thanks!

Christian

------_=_NextPart_001_01C4DEF2.BAB7CDE3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.6944.0">
<TITLE>SM501 PCI Driver</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Quick question,<BR>
<BR>
Does anyone know of any 2.6.X fb drivers for a Silicon Motion SM501 PCI =
driver?&nbsp; The 2.6 driver listed on their web site seems incomplete =
(only supports 640x480).<BR>
<BR>
Thanks!<BR>
<BR>
Christian</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4DEF2.BAB7CDE3--

From vdeepak79@gmail.com Fri Dec 10 20:07:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Dec 2004 20:07:48 +0000 (GMT)
Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.196]:45161 "EHLO
	rproxy.gmail.com") by linux-mips.org with ESMTP id <S8225426AbULJUHl>;
	Fri, 10 Dec 2004 20:07:41 +0000
Received: by rproxy.gmail.com with SMTP id i8so664161rne
        for <linux-mips@linux-mips.org>; Fri, 10 Dec 2004 12:07:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding;
        b=VRf2dFN3ZZnQ5xxj//8ZUeOHkON+th9hSBkhxiKLQuBUZdi5G3hDl95YUWkiv0FzdUvX6Q4DAvTLEa5y52P1X3idLPgsGWPT50jQfgaN0TE3LrixRZo2NYKAaZHFx/JEmep+XbERm6ZsfrQRBHFy3WTS3O+IPuttSDGMdmmNLSc=
Received: by 10.38.181.65 with SMTP id d65mr512106rnf;
        Fri, 10 Dec 2004 12:07:40 -0800 (PST)
Received: by 10.38.79.62 with HTTP; Fri, 10 Dec 2004 12:07:40 -0800 (PST)
Message-ID: <842f1e5f04121012074f6ddff0@mail.gmail.com>
Date: Sat, 11 Dec 2004 01:37:40 +0530
From: Deepak V <vdeepak79@gmail.com>
Reply-To: Deepak V <vdeepak79@gmail.com>
To: linux-mips@linux-mips.org
Subject: SIGTRAP Trace/Breakpoint Trap
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <vdeepak79@gmail.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: 6647
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vdeepak79@gmail.com
Precedence: bulk
X-list: linux-mips

Hi,

  I am using insure++ to build a multi-threaded application on RED HAT
Linux 3.2.3-37. (Linux insurertx 2.4.21-15.0.3.ELsmp #1 SMP Tue Jun 29
18:04:47 EDT 2004 i686 i686 i386 GNU/Linux)

  When I am running the application in GDB I am getting a SIGTRAP signal.

### Linux/LinuxThreadSpecific.cc:184: assertion failed
### @(#)$RCSfile: LinuxThreadSpecific.cc,v $ $Revision: 32.18 $ $Date:
2003/06/03 23:29:13 $

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread -1232592224 (LWP 30447)]
0xb68d4f01 in kill () from /lib/tls/libc.so.6
(gdb) where
#0  0xb68d4f01 in kill () from /lib/tls/libc.so.6
#1  0xb6bd1ab8 in Insure::Debug::nativeTrap () from
/home/kodiak/ins++/lib.linux2/libinsure.so
#2  0xb6b518d6 in Insure::Debug::trap () from
/home/kodiak/ins++/lib.linux2/libinsure.so
#3  0xb6b94f3a in Insure::Object::assertionFailed () from
/home/kodiak/ins++/lib.linux2/libinsure.so
#4  0xb6bff718 in Insure::PosixThread::setThisThread () from
/home/kodiak/ins++/lib.linux2/libinsure_mt.so
#5  0xb6bfe8e1 in Insure::PosixThread::processWillBecomeMultithreaded
() from /home/kodiak/ins++/lib.linux2/libinsure_mt.so
#6  0xb6bc2cfe in Insure::ThisThread::processWillBecomeMultithreaded
() from /home/kodiak/ins++/lib.linux2/libinsure.so
#7  0xb6bc2caf in Insure::ThisThread::newThread () from
/home/kodiak/ins++/lib.linux2/libinsure.so
#8  0xb6bfeb3b in Insure::PosixThread::willCreateNewThread () from
/home/kodiak/ins++/lib.linux2/libinsure_mt.so
#9  0xb6bc3127 in Insure::ThisThread::willCreateNewThread () from
/home/kodiak/ins++/lib.linux2/libinsure.so
#10 0xb6b9813c in _insure_thread_create () from
/home/kodiak/ins++/lib.linux2/libinsure.so
#11 0xb6c8e76b in pthread_create () from
/home/kodiak/ins++/lib.linux2/libtql_pthread_gcc.so

Can you please suggest what may be going wrong and the possible
solution for this?

  Thanks in advance.

Regards,
Deepak.

From drow@nevyn.them.org Fri Dec 10 20:56:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Dec 2004 20:56:19 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:53418 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225462AbULJU4O>;
	Fri, 10 Dec 2004 20:56:14 +0000
Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian))
	id 1Ccrnt-00053J-UI; Fri, 10 Dec 2004 15:55:54 -0500
Date: Fri, 10 Dec 2004 15:55:53 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Deepak V <vdeepak79@gmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: SIGTRAP Trace/Breakpoint Trap
Message-ID: <20041210205553.GA19358@nevyn.them.org>
References: <842f1e5f04121012074f6ddff0@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <842f1e5f04121012074f6ddff0@mail.gmail.com>
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6648
X-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 Sat, Dec 11, 2004 at 01:37:40AM +0530, Deepak V wrote:
> Hi,
> 
>   I am using insure++ to build a multi-threaded application on RED HAT
> Linux 3.2.3-37. (Linux insurertx 2.4.21-15.0.3.ELsmp #1 SMP Tue Jun 29
> 18:04:47 EDT 2004 i686 i686 i386 GNU/Linux)
> 
>   When I am running the application in GDB I am getting a SIGTRAP signal.

Insure, whatever it is, uses SIGTRAP itself:

> #0  0xb68d4f01 in kill () from /lib/tls/libc.so.6
> #1  0xb6bd1ab8 in Insure::Debug::nativeTrap () from
> /home/kodiak/ins++/lib.linux2/libinsure.so
> #2  0xb6b518d6 in Insure::Debug::trap () from
> /home/kodiak/ins++/lib.linux2/libinsure.so
> #3  0xb6b94f3a in Insure::Object::assertionFailed () from
> /home/kodiak/ins++/lib.linux2/libinsure.so

You will have to manually pass these unexpected SIGTRAPs back to your
application.

-- 
Daniel Jacobowitz

From dan@embeddededge.com Fri Dec 10 21:16:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Dec 2004 21:16:27 +0000 (GMT)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:52749 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8225462AbULJVQX>; Fri, 10 Dec 2004 21:16:23 +0000
Received: from [10.1.100.8] (mail.chipsandsystems.com [64.164.196.27])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id iBAL30gn022256;
	Fri, 10 Dec 2004 16:03:00 -0500
In-Reply-To: <8230E1CC35AF9F43839F3049E930169A0A2766@yang.LibreStream.local>
References: <8230E1CC35AF9F43839F3049E930169A0A2766@yang.LibreStream.local>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BB57E531-4AF0-11D9-A76E-003065F9B7DC@embeddededge.com>
Content-Transfer-Encoding: 7bit
Cc: <linux-mips@linux-mips.org>
From: Dan Malek <dan@embeddededge.com>
Subject: Re: SM501 PCI Driver
Date: Fri, 10 Dec 2004 16:16:17 -0500
To: "Christian Gan" <christian.gan@librestream.com>
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: 6649
X-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


On Dec 10, 2004, at 2:59 PM, Christian Gan wrote:

>  Does anyone know of any 2.6.X fb drivers for a Silicon Motion SM501 
> PCI driver?

It's on my list of things to do and I have been working on it for the 
Alchemy
Db1500 board.  I'm currently traveling, later next week I can provide 
and update.

	-- Dan


From engel@mathematik.uni-marburg.de Sat Dec 11 08:50:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Dec 2004 08:50:56 +0000 (GMT)
Received: from pc12577.Mathematik.Uni-Marburg.DE ([IPv6:::ffff:137.248.123.2]:52906
	"EHLO mailhost.Mathematik.Uni-Marburg.de") by linux-mips.org
	with ESMTP id <S8225074AbULKIuv>; Sat, 11 Dec 2004 08:50:51 +0000
Received: from www.mathematik.uni-marburg.de (durban [137.248.123.2])
	by mailhost.Mathematik.Uni-Marburg.de (8.13.1/8.13.1) with ESMTP id iBB8ojkR031811
	for <linux-mips@linux-mips.org>; Sat, 11 Dec 2004 09:50:45 +0100
Received: from 62.226.168.187
        (SquirrelMail authenticated user engel);
        by www.mathematik.uni-marburg.de with HTTP;
        Sat, 11 Dec 2004 09:50:45 +0100 (CET)
Message-ID: <57004.62.226.168.187.1102755045.squirrel@62.226.168.187>
Date: Sat, 11 Dec 2004 09:50:45 +0100 (CET)
Subject: Recommended gcc/binutils Versions for mips64 target?
From: engel@mathematik.uni-marburg.de
To: linux-mips@linux-mips.org
User-Agent: SquirrelMail/1.4.3a
X-Mailer: SquirrelMail/1.4.3a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Return-Path: <engel@mathematik.uni-marburg.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: 6650
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: engel@mathematik.uni-marburg.de
Precedence: bulk
X-list: linux-mips


Hi,

I'm currently trying to cross-compile a kernel (2.6.10-pre3 from cvs with
the IP30 patch from Stanislaw) for my Octane (IP30) on Linux/amd64.

What versions of gcc and binutils are currently recommended
for crosscompiling? The target should simply be mips64-linux if I read the
Makefile correctly? This has caused problems as my binutils version
2.15.92.0.2 configured with mips64-linux didn't produce a linker that was
capable of using elf64btsmip, mips64-linux-gnu did work.

I'm also a bit confused as to why IP30 support is located in the arch/mips/
hierarchy and not arch/mips64/. IIRC, the Octane definitely needs a 64 bit
kernel to boot?

regards,
    Michael



From ica2_ts@csv.ica.uni-stuttgart.de Sat Dec 11 09:55:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Dec 2004 09:55:38 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:11387
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225074AbULKJzZ>; Sat, 11 Dec 2004 09:55:25 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1Cd3xv-000685-00; Sat, 11 Dec 2004 10:55:03 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1Cd3xb-0001W0-00; Sat, 11 Dec 2004 10:54:43 +0100
Date: Sat, 11 Dec 2004 10:54:43 +0100
To: engel@mathematik.uni-marburg.de
Cc: linux-mips@linux-mips.org
Subject: Re: Recommended gcc/binutils Versions for mips64 target?
Message-ID: <20041211095443.GA26784@rembrandt.csv.ica.uni-stuttgart.de>
References: <57004.62.226.168.187.1102755045.squirrel@62.226.168.187>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57004.62.226.168.187.1102755045.squirrel@62.226.168.187>
User-Agent: Mutt/1.5.6i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6651
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

engel@mathematik.uni-marburg.de wrote:
> 
> Hi,
> 
> I'm currently trying to cross-compile a kernel (2.6.10-pre3 from cvs with
> the IP30 patch from Stanislaw) for my Octane (IP30) on Linux/amd64.
> 
> What versions of gcc and binutils are currently recommended
> for crosscompiling? The target should simply be mips64-linux if I read the
> Makefile correctly? This has caused problems as my binutils version
> 2.15.92.0.2 configured with mips64-linux didn't produce a linker that was
> capable of using elf64btsmip, mips64-linux-gnu did work.

Unless 2.15.92.0.2 deviates significantly from the GNU version, both
mips64-linux and mips64-linux-gnu should have the same capabilities.

> I'm also a bit confused as to why IP30 support is located in the arch/mips/
> hierarchy and not arch/mips64/. IIRC, the Octane definitely needs a 64 bit
> kernel to boot?

arch/mips64 doesn't exist an more for 2.6, the 64bit support was moved
to arch/mips.


Thiemo

From yuasa@hh.iij4u.or.jp Sat Dec 11 13:26:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Dec 2004 13:27:03 +0000 (GMT)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:51147 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8224933AbULKN05>;
	Sat, 11 Dec 2004 13:26:57 +0000
Received: MO(mo01)id iBBDQsem020077; Sat, 11 Dec 2004 22:26:54 +0900 (JST)
Received: MDO(mdo01) id iBBDQrAP004057; Sat, 11 Dec 2004 22:26:53 +0900 (JST)
Received: 4UMRO00 id iBBDQq21005847; Sat, 11 Dec 2004 22:26:52 +0900 (JST)
	from stratos (localhost [127.0.0.1]) (authenticated)
Date: Sat, 11 Dec 2004 22:26:49 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6.10-rc3] fixed pci_ids.h
Message-Id: <20041211222649.13895ef3.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.0beta3 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6652
X-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

Hi Ralf,

Some PCI IDs are defined doubly.
Please apply this patch.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/include/linux/pci_ids.h a/include/linux/pci_ids.h
--- a-orig/include/linux/pci_ids.h	Sun Dec  5 21:25:04 2004
+++ a/include/linux/pci_ids.h	Sat Dec 11 22:11:59 2004
@@ -1452,11 +1452,6 @@
 #define PCI_DEVICE_ID_TOSHIBA_TC35815CF	0x0030
 #define PCI_DEVICE_ID_TOSHIBA_TX4927	0x0180
 
-#define PCI_VENDOR_ID_TOSHIBA_2		0x102f
-#define PCI_DEVICE_ID_TOSHIBA_TX3927	0x000a
-#define PCI_DEVICE_ID_TOSHIBA_TC35815CF	0x0030
-#define PCI_DEVICE_ID_TOSHIBA_TX4927	0x0180
-
 #define PCI_VENDOR_ID_RICOH		0x1180
 #define PCI_DEVICE_ID_RICOH_RL5C465	0x0465
 #define PCI_DEVICE_ID_RICOH_RL5C466	0x0466

From wlacey@goldenhindresearch.com Sat Dec 11 13:42:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Dec 2004 13:42:53 +0000 (GMT)
Received: from server212.com ([IPv6:::ffff:203.194.159.163]:44171 "HELO
	server212.com") by linux-mips.org with SMTP id <S8224933AbULKNmt>;
	Sat, 11 Dec 2004 13:42:49 +0000
Received: (qmail 20026 invoked by uid 2003); 11 Dec 2004 13:43:05 -0000
Message-ID: <20041211134305.22769.qmail@server212.com>
Reply-To: "wlacey" <wlacey@goldenhindresearch.com>
From: "wlacey" <wlacey@goldenhindresearch.com>
To: linux-mips@linux-mips.org
Subject: No PCI_AUTO in 2.6...
Date: Sat, 11 Dec 2004 13:43:05 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="_ba3a001bb191b9756e5715dab9227106c"
X-Mailer: WebMail 2.3
X-Originating-IP: 67.149.145.76
X-Originating-Email: wlacey@goldenhindresearch.com
Return-Path: <wlacey@goldenhindresearch.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: 6653
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wlacey@goldenhindresearch.com
Precedence: bulk
X-list: linux-mips

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

Might someone be willing to share a bit knowledge with me?

I've transitioned to the 2.6.10 kernel and I'm having a difficult time understanding what things I must do different to get my pci slots probed as before in 2.4. At this point I'm well aware the 2.6 is not a drop in replacement for 2.4 but what is the a general approach to getting something like PCI_AUTO capability in 2.6 what steps must I take and is there document describing them.

I call register_pci_controller() but the bus is never scanned becasue pcibios_init() fails out with...
"Skipping PCI bus scan due to resource conflict"

Any hints/clues/breadcrumbs for the starving?

Thanks,
W


--_ba3a001bb191b9756e5715dab9227106c
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Might someone be willing to share a bit knowledge with me?<br>
<br>
I've transitioned to the 2.6.10 kernel and I'm having a difficult time understanding what things I must do different to get my pci slots probed as before in 2.4. At this point I'm well aware the 2.6 is not a drop in replacement for 2.4 but what is the a general approach to getting something like PCI_AUTO capability in 2.6 what steps must I take and is there document describing them.<br>
<br>
I call register_pci_controller() but the bus is never scanned becasue pcibios_init() fails out with...<br>
&quot;Skipping PCI bus scan due to resource conflict&quot;<br>
<br>
Any hints/clues/breadcrumbs for the starving?<br>
<br>
Thanks,<br>
W<br>
<br>


--_ba3a001bb191b9756e5715dab9227106c--

From sebvajda@yahoo.fr Sat Dec 11 20:34:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Dec 2004 20:34:19 +0000 (GMT)
Received: from web25810.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.195]:40299
	"HELO web25810.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8224933AbULKUeN>; Sat, 11 Dec 2004 20:34:13 +0000
Received: (qmail 6023 invoked by uid 60001); 11 Dec 2004 20:34:06 -0000
Message-ID: <20041211203406.6021.qmail@web25810.mail.ukl.yahoo.com>
Received: from [81.241.205.222] by web25810.mail.ukl.yahoo.com via HTTP; Sat, 11 Dec 2004 21:34:06 CET
Date: Sat, 11 Dec 2004 21:34:06 +0100 (CET)
From: =?iso-8859-1?q?S=E9bastien=20Vajda?= <sebvajda@yahoo.fr>
Subject: [PATCH] add iomap functions
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org, yuasa@hh.iij4u.or.jp, cobalt@colonel-panic.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <sebvajda@yahoo.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6654
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sebvajda@yahoo.fr
Precedence: bulk
X-list: linux-mips

Dear all,

I tried compiling CVS from 3~4 days ago for a Cobalt
Qube2. This box has two tulip NIC. The tulip driver
has been changed in the 2.6.10-rcx timeframe. It now
uses iowrite32, ioread32 and assorted functions.

Those are currently not implemented in linux-mips.

In Novemember, Yoichi Yuasa submitted a patch for
iomap functions. On this submission Ralf Baechle asked
why not use the generic iomap implementation instead?

I've tried both. With the generic iomap the kernel
compiles fine, but the tulip driver is not working.
With Yoichi Yuasa's patch everything works as it
should.

As Yoichi's patch is needed for the Qube2 boxen, could
I ask if the patch is going to be applied in CVS. And
if not, what needs to be done?

ps.: I'm not on the list, so please CC me when
replying.

Best regards,
Seb.


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ 
 
Avec Yahoo! faites un don et soutenez le Téléthon en cliquant sur http://www.telethon.fr/030-Don/10-10_Don.asp

From yuasa@hh.iij4u.or.jp Sun Dec 12 14:38:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 12 Dec 2004 14:38:41 +0000 (GMT)
Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:25334 "EHLO
	mo00.iij4u.or.jp") by linux-mips.org with ESMTP id <S8224844AbULLOig>;
	Sun, 12 Dec 2004 14:38:36 +0000
Received: MO(mo00)id iBCEcKQ4026554; Sun, 12 Dec 2004 23:38:20 +0900 (JST)
Received: MDO(mdo00) id iBCEcJjQ023915; Sun, 12 Dec 2004 23:38:20 +0900 (JST)
Received: 4UMRO01 id iBCEcJiH024090; Sun, 12 Dec 2004 23:38:19 +0900 (JST)
	from stratos (localhost [127.0.0.1]) (authenticated)
Date: Sun, 12 Dec 2004 23:38:17 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: linux-mips <linux-mips@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, ralf@linux-mips.org, cobalt@colonel-panic.org
Subject: Re: [PATCH] add iomap functions
Message-Id: <20041212233817.00d6d9fd.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20041211203406.6021.qmail@web25810.mail.ukl.yahoo.com>
References: <20041211203406.6021.qmail@web25810.mail.ukl.yahoo.com>
X-Mailer: Sylpheed version 1.0.0beta3 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6655
X-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

Hi,

On Sat, 11 Dec 2004 21:34:06 +0100 (CET)

> Dear all,
> 
> I tried compiling CVS from 3~4 days ago for a Cobalt
> Qube2. This box has two tulip NIC. The tulip driver
> has been changed in the 2.6.10-rcx timeframe. It now
> uses iowrite32, ioread32 and assorted functions.
> 
> Those are currently not implemented in linux-mips.
> 
> In Novemember, Yoichi Yuasa submitted a patch for
> iomap functions. On this submission Ralf Baechle asked
> why not use the generic iomap implementation instead?

Some MIPS systems are unable to define PIO space by PIO_MASK/PIO_RESERVED.
This is the reason I didn't use the general iomap implementation.

Yoichi

From anemo@mba.ocn.ne.jp Mon Dec 13 05:02:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Dec 2004 05:03:00 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:23583
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224872AbULMFCv>; Mon, 13 Dec 2004 05:02:51 +0000
Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 13 Dec 2004 05:02:49 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by newms.toshiba-tops.co.jp (Postfix) with ESMTP
	id 3D87C239E2C; Mon, 13 Dec 2004 13:34:10 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id iBD4Y9dD096152;
	Mon, 13 Dec 2004 13:34:09 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Mon, 13 Dec 2004 13:34:09 +0900 (JST)
Message-Id: <20041213.133409.11964920.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org
Cc: nunoe@co-nss.co.jp, linux-mips@linux-mips.org
Subject: Re: HIGHMEM
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20041207095837.GA13264@linux-mips.org>
References: <001101c4dbf9$1da02270$3ca06096@NUNOE>
	<20041207095837.GA13264@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6656
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Tue, 7 Dec 2004 10:58:37 +0100, Ralf Baechle <ralf@linux-mips.org> said:
ralf> Issue #3 - As I recall the TX4937's H3 core is suffering from
ralf> cache aliases.  Handling those efficiently for highmem is not
ralf> easily possible and so we don't even try.  More recent kernels
ralf> will refuse to enable highmem on such cache configurations but
ralf> something like 2.4.18 which by now is an almost 3 year old
ralf> antique doesn't know about that and will happily crash.

ralf> I recommend you should go for a 64-bit kernel instead.  And
ralf> 64-bit support is certainly better in 2.6 than in 2.4.
ralf> Especially the area of 32-bit binary compatibility has been
ralf> improved significantly.

And this is a small step to a 64-bit kernel for TX49XX.  Could you
apply?

--- linux-mips/arch/mips/mm/Makefile	2004-12-13 09:39:09.000000000 +0900
+++ linux/arch/mips/mm/Makefile	2004-12-13 09:52:54.000000000 +0900
@@ -49,6 +49,7 @@
 endif
 ifdef CONFIG_MIPS64
 obj-$(CONFIG_CPU_R4300)		+= tlbex64.o
+obj-$(CONFIG_CPU_TX49XX)	+= tlbex64.o
 obj-$(CONFIG_CPU_R4X00)		+= tlbex64.o
 obj-$(CONFIG_CPU_R5000)		+= tlbex64.o
 obj-$(CONFIG_CPU_NEVADA)	+= tlbex64.o

From francis_moreau2000@yahoo.fr Mon Dec 13 18:13:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Dec 2004 18:13:29 +0000 (GMT)
Received: from web25104.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.52]:10076
	"HELO web25104.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8225321AbULMSNY>; Mon, 13 Dec 2004 18:13:24 +0000
Received: (qmail 23076 invoked by uid 60001); 13 Dec 2004 18:12:53 -0000
Message-ID: <20041213181252.23074.qmail@web25104.mail.ukl.yahoo.com>
Received: from [80.14.198.143] by web25104.mail.ukl.yahoo.com via HTTP; Mon, 13 Dec 2004 19:12:52 CET
Date: Mon, 13 Dec 2004 19:12:52 +0100 (CET)
From: moreau francis <francis_moreau2000@yahoo.fr>
Subject: Kernel located in KSEG2 or KSEG3.
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6657
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips

Hi,

Sorry if you find this post stupid, but I'm quite new
in Linux.

To learn on Linux kernel, I've decided to port it on 
particular board with (very) limited resources and
based with a 4KC processor core. As far I see, I need
at least a couple of mega bytes of memory to achieve
my goal. 
Unfortunately the only way to get this amount of mem
is
to execute linux in memory that can only be accessed
through KSEG2 and KSEG3 !

Here is my board's mapping:

Physical Memory Map:

start        size       type
-----------------------------
0x20000000 - 8MB    - SDRAM
0x30000000 - 16MB   - FLASH
0x40000000 - 16MB   - FLASH
0x50000000 - 2MB    - SRAM


I looked into the memory init code and I don't think
that it's possible to run linux in a segment different
from KSEG0. Am I wrong ?

I've noticed a CONFIG_MAPPED_KERNEL macro but it seems
that it's only used to replicate kernel from mapped
memory to KSEG0...

Thanks for your answers.



	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ 
 
Avec Yahoo! faites un don et soutenez le Téléthon en cliquant sur http://www.telethon.fr/030-Don/10-10_Don.asp

From sjhill@realitydiluted.com Mon Dec 13 19:04:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Dec 2004 19:05:12 +0000 (GMT)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:62351 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225397AbULMTE7>; Mon, 13 Dec 2004 19:04:59 +0000
Received: from sjhill by real.realitydiluted.com with local (Exim 4.34 #1 (Debian))
	id 1CdvUh-0002B1-MR; Mon, 13 Dec 2004 13:04:27 -0600
Subject: Re: Kernel located in KSEG2 or KSEG3.
In-Reply-To: <20041213181252.23074.qmail@web25104.mail.ukl.yahoo.com>
To: moreau francis <francis_moreau2000@yahoo.fr>
Date: Mon, 13 Dec 2004 13:04:27 -0600 (CST)
CC: linux-mips@linux-mips.org
X-Mailer: ELM [version 2.4ME+ PL100 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E1CdvUh-0002B1-MR@real.realitydiluted.com>
From: sjhill@realitydiluted.com
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: 6658
X-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

> Here is my board's mapping:
> 
> Physical Memory Map:
> 
> start        size       type
> -----------------------------
> 0x20000000 - 8MB    - SDRAM
> 0x30000000 - 16MB   - FLASH
> 0x40000000 - 16MB   - FLASH
> 0x50000000 - 2MB    - SRAM
> 
Your board manufacturer should be shot and then have
their hands and tongue cut off. All kidding aside,
are you sure there is no device mapped in the physical
address range of 0x1fc00000-0x1fffffff? I highly doubt
your board would boot otherwise, since a MIPS processor
coming out of reset jumps to physical address 0x1fc00000.
Can you check the board's manual? Thanks.

-Steve

From ichinoh@mb.neweb.ne.jp Tue Dec 14 02:36:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Dec 2004 02:36:22 +0000 (GMT)
Received: from imfep02.dion.ne.jp ([IPv6:::ffff:210.174.120.146]:33578 "EHLO
	imfep02.dion.ne.jp") by linux-mips.org with ESMTP
	id <S8225074AbULNCgR>; Tue, 14 Dec 2004 02:36:17 +0000
Received: from webmail.dion.ne.jp ([210.196.2.172]) by imfep02.dion.ne.jp
          (InterMail vM.4.01.03.31 201-229-121-131-20020322) with SMTP
          id <20041214023558.UPTE1125.imfep02.dion.ne.jp@webmail.dion.ne.jp>;
          Tue, 14 Dec 2004 11:35:58 +0900
From: ichinoh@mb.neweb.ne.jp
To: linux-mips@linux-mips.org
Cc: ichinoh@mb.neweb.ne.jp
Date: Tue, 14 Dec 2004 11:35:58 +0900
Message-Id: <1102991758.2865@157.120.127.3.DIONWebMail>
Subject: UART3 of DbAu1100
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
X-Mailer: DION Web mail version 1.03
X-Originating-IP: 157.120.127.3(*)
Return-Path: <ichinoh@mb.neweb.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6659
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ichinoh@mb.neweb.ne.jp
Precedence: bulk
X-list: linux-mips

Hello,

I have a question about UART3 of DbAu1100.

After enabling UART3 then reboot the kernel, I cannot use UART3 port.
Did anyone encounter the same error ?
In addition, UART3 initialization processing is as follows.

static int serial_init (void)
{
	volatile u32 *uart_fifoctl = (volatile u32*)(UART3_ADDR+UART_FCR);
	volatile u32 *uart_enable = (volatile u32*)(UART3_ADDR+UART_ENABLE);
	volatile u32 *uart_mcr = (volatile u32*)(UART3_ADDR+UART_MCR);
	volatile u32 *sys_pinfunc = (volatile u32*)SYS_PINFUNC;

	/* reset UART0 module */
	au_writel(0x00, UART3_ADDR);
	au_sync( );

	/* Enable clocks first */
	*uart_enable = UART_EN_CE;

	/* Then release reset */
	/* Must release reset before setting other regs */
	*uart_enable = UART_EN_CE|UART_EN_E;

	/* Activate fifos, reset tx and rx */
	/* Set tx trigger level to 12 */
	*uart_fifoctl = UART_FCR_ENABLE_FIFO|UART_FCR_CLEAR_RCVR|             
	UART_FCR_CLEAR_XMIT|UART_FCR_T_TRIGGER_12|UART_FCR_R_TRIGGER_14; 

	serial_setbrg( );
	
	/* Set DTR */
	*uart_mcr = UART_MCR_DTR | UART_MCR_RTS;

	return 0;
}

static void serial_setbrg (void)
{
	volatile u32 *uart_clk = (volatile u32*)(UART3_ADDR+UART_CLK);
	volatile u32 *uart_lcr = (volatile u32*)(UART3_ADDR+UART_LCR);

	/* Set baudrate to 9600 */
	*uart_clk = 0x280;

	/* Set parity, stop bits and word length to 8N1 */
	*uart_lcr = UART_LCR_WLEN8;
	return ;
}

Best regards,
Nyauyama.


From nunoe@co-nss.co.jp Tue Dec 14 04:27:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Dec 2004 04:27:18 +0000 (GMT)
Received: from nssinet2.co-nss.co.jp ([IPv6:::ffff:150.96.0.5]:2270 "EHLO
	nssinet2.co-nss.co.jp") by linux-mips.org with ESMTP
	id <S8224909AbULNE1N>; Tue, 14 Dec 2004 04:27:13 +0000
Received: from nssinet2.co-nss.co.jp (localhost [127.0.0.1])
	by nssinet2.co-nss.co.jp (8.9.3/3.7W) with ESMTP id NAA14964;
	Tue, 14 Dec 2004 13:22:40 +0900 (JST)
Received: from nssnet.co-nss.co.jp (nssnet.co-nss.co.jp [150.96.64.250])
	by nssinet2.co-nss.co.jp (8.9.3/3.7W) with ESMTP id NAA14960;
	Tue, 14 Dec 2004 13:22:39 +0900 (JST)
Received: from NUNOE ([150.96.160.64])
	by nssnet.co-nss.co.jp (8.9.3+Sun/3.7W) with SMTP id NAA27719;
	Tue, 14 Dec 2004 13:13:40 +0900 (JST)
Message-ID: <001701c4e195$24d48260$3ca06096@NUNOE>
From: "Hdei Nunoe" <nunoe@co-nss.co.jp>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
References: <001101c4dbf9$1da02270$3ca06096@NUNOE> <20041207095837.GA13264@linux-mips.org>
Subject: Re: HIGHMEM
Date: Tue, 14 Dec 2004 13:26:55 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Return-Path: <nunoe@co-nss.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: 6660
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nunoe@co-nss.co.jp
Precedence: bulk
X-list: linux-mips

Ralf,

Thanks for the info!  I still have a ocuple of question, hope you do not 
mind.

> In 2.4 the support for CONFIG_DISCONTIG and CONFIG_NUMA are a bit tangled
> with each other because IP27 is the only platform to uses these features
> and it needs both.

Is it named "sgi-ip27"?

> Other than that you can also just setup your system
> as 0x0 - 0x10000000 being RAM, 0x10000000 - 0x20000000 being reserved
> memory and 0x20000000 - 0x30000000 being highmem.  Which works but is a
> bit wasteful.

The gap in physical memory is 0x10000000 - 0x20000000, but it is 
0x90000000 -
0xC0000000 in virtual memory because there is K1 segment.  So the macros 
such
as __pa() or __va() does not work, I think.  Started to wonder it might not 
be easy
as just changing the PAGE_OFFSET value.  Do you see?

cheers,
-hdei


From toch@dfpost.ru Tue Dec 14 07:51:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Dec 2004 07:51:39 +0000 (GMT)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:55223 "EHLO
	mail.dfpost.ru") by linux-mips.org with ESMTP id <S8225208AbULNHvd>;
	Tue, 14 Dec 2004 07:51:33 +0000
Received: from toch.dfpost.ru (toch.dfpost.ru [192.168.7.60])
	by mail.dfpost.ru (Postfix) with SMTP id C8B243E4AC
	for <linux-mips@linux-mips.org>; Tue, 14 Dec 2004 10:45:17 +0300 (MSK)
Date: Tue, 14 Dec 2004 10:51:54 +0300
From: Dmitriy Tochansky <toch@dfpost.ru>
To: linux-mips@linux-mips.org
Subject: Re: mmap problem another :)
Message-Id: <20041214105154.2bed14df.toch@dfpost.ru>
In-Reply-To: <AC350838-49EF-11D9-A745-003065F9B7DC@embeddededge.com>
References: <20041209161207.39140f0d.toch@dfpost.ru>
	<AC350838-49EF-11D9-A745-003065F9B7DC@embeddededge.com>
Organization: Special Technology Center
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6661
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

On Thu, 9 Dec 2004 09:36:11 -0500
Dan Malek <dan@embeddededge.com> wrote:

> Read the memory mapping docuemntation and understand the APIs.
> All of the Linux mapping functions, whether mmap() from an application
> or in the kernel are going to align on page boundaries.
> 
> The address of 0x40002040 is going to be aligned to a page boundary,
> so you have to consider the offset into that page to the base of the
> device, plus the register offset.  The kernel mapping functions,
> like remap_page_range, are going to force the alignment because
> that is what we expect in the kernel.  An mmap() with an unaligned
> address will generate an error.
  Ok. I understand. But still havent fun. :(
Yes, Im assume that offset if pagealligned:

static int
mdrv_mmap (struct file *file, struct vm_area_struct *vma)
{
  unsigned long offset = 0;
  int ret;
  struct inode *inode;
  inode = file->f_dentry->d_inode;
  struct pci_dev *curdev = NULL;
  int minor = MINOR (inode->i_rdev);
  printk("minor = 0x%X\n",minor);
  curdev = (devs[minor]);
  unsigned long start = vma->vm_start;
  unsigned long size = (vma->vm_end - vma->vm_start);
  offset = pci_resource_start (curdev, IOMEM0);
  offset &= PAGE_MASK;
  printk("start= 0x%X offset = 0x%X size=0x%X\n",start, (unsigned int)offset, (unsigned int) size);
  ret = remap_page_range_high(start, offset, size, vma->vm_page_prot);
  return ret;
}

 This code, AFAIK will return me a pointer to begin of page where my ioaddr is. ?

 Then in my testcode I compensate shift by adding it to addr:

---

#include "mdrv.h"
#include <sys/mman.h>
#include <stdio.h>
#include <fcntl.h>

#define MMAP_SIZE 0x40

int fd, fd2;

int
main ()
{

  fd = open ("/dev/mboard1", O_RDWR);

  unsigned long *x;

  x = mmap (NULL, MMAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

  printf ("mmap return: 0x%X", x);

  if (x == MAP_FAILED)
    {
      printf (" it is very bad! :(\n");
      perror ("mmap:");
      return -1;
    }

  printf (" its ok!\n");
  
  printf("x = 0x%X\n",x);

#define CONS 0
//0x2040 >> 2
  
  x += CONS;
  
  printf("x = 0x%X\n",x);
  unsigned long m = 0xEF;
  
  printf("m = 0x%X\n",m);
  
  //printf ("%p\n", x[(0x3C)>>2]); //We have to get 0xE6 here
  
  m = x[(0x40>>2)+(0x3C>>2)];
  
  printf("m = 0x%p\n", m);
  
  x -= CONS;  
  
  munmap (x, MMAP_SIZE);
  close(fd);
  
  return 0;
}

---

DEbug output shows that mmap - success. I get pointer and size = 0x1000(one page). Then
I try to read m from board register. BTW, if I just read apps finishing but when I try to output
to console(as in src) "m" programm hangs.

Have no idea what the ... is goin on. Some hints please.

From koseki@shimafuji.co.jp Tue Dec 14 08:51:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Dec 2004 08:51:50 +0000 (GMT)
Received: from s306.secure.ne.jp ([IPv6:::ffff:211.9.215.133]:47628 "HELO
	s306.secure.ne.jp") by linux-mips.org with SMTP id <S8225208AbULNIvo>;
	Tue, 14 Dec 2004 08:51:44 +0000
Received: (qmail 69443 invoked from network); 14 Dec 2004 17:51:22 +0900
Received: from unknown (HELO koseki) (163.139.182.183)
  by 0 with SMTP; 14 Dec 2004 17:51:22 +0900
Message-ID: <009001c4e1ba$54a431f0$2100a8c0@koseki>
From: "Tatsuya Koseki" <koseki@shimafuji.co.jp>
To: "Linux MIPS mailing list" <linux-mips@linux-mips.org>
Subject: kernel 2.6.9 patch
Date: Tue, 14 Dec 2004 17:53:02 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <koseki@shimafuji.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: 6662
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: koseki@shimafuji.co.jp
Precedence: bulk
X-list: linux-mips

Please review 


--- linux/include/asm/stackframe.h.old Tue Dec 14 17:49:38 2004
+++ linux/include/asm/stackframe.h Tue Dec 14 17:50:35 2004
@@ -244,6 +244,10 @@
   nor v1, $0, v1
   and v0, v1
   or v0, a0
+
+  li v1,2
+  or v0,v1
+
   mtc0 v0, CP0_STATUS
   LONG_L v1, PT_EPC(sp)
   MTC0 v1, CP0_EPC





From francis_moreau2000@yahoo.fr Tue Dec 14 10:04:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Dec 2004 10:04:17 +0000 (GMT)
Received: from web25107.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.55]:28505
	"HELO web25107.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8225212AbULNKEN>; Tue, 14 Dec 2004 10:04:13 +0000
Received: (qmail 92684 invoked by uid 60001); 14 Dec 2004 10:03:56 -0000
Message-ID: <20041214100356.92682.qmail@web25107.mail.ukl.yahoo.com>
Received: from [80.14.198.143] by web25107.mail.ukl.yahoo.com via HTTP; Tue, 14 Dec 2004 11:03:56 CET
Date: Tue, 14 Dec 2004 11:03:56 +0100 (CET)
From: moreau francis <francis_moreau2000@yahoo.fr>
Subject: Re: Kernel located in KSEG2 or KSEG3.
To: sjhill@realitydiluted.com
Cc: linux-mips@linux-mips.org
In-Reply-To: <E1CdvUh-0002B1-MR@real.realitydiluted.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6663
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips

 --- sjhill@realitydiluted.com a écrit : 
> > Here is my board's mapping:
> > 
> > Physical Memory Map:
> > 
> > start        size       type
> > -----------------------------
> > 0x20000000 - 8MB    - SDRAM
> > 0x30000000 - 16MB   - FLASH
> > 0x40000000 - 16MB   - FLASH
> > 0x50000000 - 2MB    - SRAM
> > 
> are you sure there is no device mapped in the
> physical
> address range of 0x1fc00000-0x1fffffff? I highly
> doubt
> your board would boot otherwise, since a MIPS
> processor
> coming out of reset jumps to physical address
> 0x1fc00000.
  
only a small piece of ROM...

here is my internal memory mapping:

start        size      type
-----------------------------
0x1fc00000 - 128Ko    - ROM
0x01000000 - 128Ko   - FLASH

At boot time ROM code do some init and then jump
into the internal flash mem.

I think there's no possibilities to run linux except
in KSEG2 and KSEG3...Do you think it's possible ?

By the way why Linux memory management need to care
about physical addresses ?

Francis.




>  


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ 
 
Avec Yahoo! faites un don et soutenez le Téléthon en cliquant sur http://www.telethon.fr/030-Don/10-10_Don.asp

From navaraga@yahoo.com Wed Dec 15 10:29:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 10:29:47 +0000 (GMT)
Received: from web54507.mail.yahoo.com ([IPv6:::ffff:68.142.225.177]:2425 "HELO
	web54507.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225005AbULOK3j>; Wed, 15 Dec 2004 10:29:39 +0000
Received: (qmail 45713 invoked by uid 60001); 15 Dec 2004 10:29:23 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=LQUWUOl8shZsahdu/18fn0FaL2fXWqoKCGjTrWACI1i1hiSdl1qvUjqKgVFp6us8HR/8uceR1OEe1QNLlEd4Gf31XjyfwM3WpljxXzuLVLlt1rZ3J7Pru2VSdJyFAn344Wk9dx1Ap4KWdw/BWNb++UE738c1ZZ4rzWSfOvhWUfY=  ;
Message-ID: <20041215102923.45711.qmail@web54507.mail.yahoo.com>
Received: from [203.101.73.166] by web54507.mail.yahoo.com via HTTP; Wed, 15 Dec 2004 02:29:22 PST
Date: Wed, 15 Dec 2004 02:29:22 -0800 (PST)
From: Srividya Ramanathan <navaraga@yahoo.com>
Subject: unresolved symbol io_remap_page_range
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <navaraga@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: 6664
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: navaraga@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,
  i had written and compiled a PCI device driver which
works well for X86 architecture. The same driver when
compiled for MIPS architecture gives "unresolved
symbol io_remap_page_range". Is this API deprecated or
is there any other alternative API for
io_remap_page_range()

Thanks
R.Srividya


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 


From ralf@linux-mips.org Wed Dec 15 13:13:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 13:13:41 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:57874
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225007AbULONNg>; Wed, 15 Dec 2004 13:13:36 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFDDNUZ028250;
	Wed, 15 Dec 2004 14:13:23 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFDDMYT028249;
	Wed, 15 Dec 2004 14:13:22 +0100
Date: Wed, 15 Dec 2004 14:13:22 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Srividya Ramanathan <navaraga@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: unresolved symbol io_remap_page_range
Message-ID: <20041215131322.GB27935@linux-mips.org>
References: <20041215102923.45711.qmail@web54507.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041215102923.45711.qmail@web54507.mail.yahoo.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6665
X-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, Dec 15, 2004 at 02:29:22AM -0800, Srividya Ramanathan wrote:

>   i had written and compiled a PCI device driver which
> works well for X86 architecture. The same driver when
> compiled for MIPS architecture gives "unresolved
> symbol io_remap_page_range". Is this API deprecated or
> is there any other alternative API for
> io_remap_page_range()

Au contraire.  The API is that new that your kernel doesn't yet have.  It
was introduced in 2.6.10-rc1.

  Ralf

From ralf@linux-mips.org Wed Dec 15 13:18:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 13:18:09 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:62226
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225005AbULONSF>; Wed, 15 Dec 2004 13:18:05 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFDHsEO028336;
	Wed, 15 Dec 2004 14:17:54 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFDHrXe028335;
	Wed, 15 Dec 2004 14:17:53 +0100
Date: Wed, 15 Dec 2004 14:17:53 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Tatsuya Koseki <koseki@shimafuji.co.jp>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: kernel 2.6.9 patch
Message-ID: <20041215131753.GC27935@linux-mips.org>
References: <009001c4e1ba$54a431f0$2100a8c0@koseki>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <009001c4e1ba$54a431f0$2100a8c0@koseki>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6666
X-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, Dec 14, 2004 at 05:53:02PM +0900, Tatsuya Koseki wrote:

> Subject: kernel 2.6.9 patch
> Date: Tue, 14 Dec 2004 17:53:02 +0900
> Content-Type: text/plain;
> 	charset="iso-2022-jp"
> 
> Please review 
> 
> 
> --- linux/include/asm/stackframe.h.old Tue Dec 14 17:49:38 2004
> +++ linux/include/asm/stackframe.h Tue Dec 14 17:50:35 2004
> @@ -244,6 +244,10 @@
>    nor v1, $0, v1
>    and v0, v1
>    or v0, a0
> +
> +  li v1,2
> +  or v0,v1
> +
>    mtc0 v0, CP0_STATUS
>    LONG_L v1, PT_EPC(sp)
>    MTC0 v1, CP0_EPC

 o Your patch got corrupted by using a differnet indentation so couldn't be
   applied anyway
 o When posting a patch, post an explanation.  If the purpose of a patch
   isn't obvious it'll likely be ignroed.
 o This bug was already fixed in CVS.
 o The issue only affected new-born processes, so there is no reason to
   burden the fix on every exception taken.
 o Why using two instruction if one would be sufficient.

  Ralf

From ralf@linux-mips.org Wed Dec 15 13:39:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 13:39:10 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:11027
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225005AbULONjF>; Wed, 15 Dec 2004 13:39:05 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFDcs0K028662;
	Wed, 15 Dec 2004 14:38:54 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFDcpTb028661;
	Wed, 15 Dec 2004 14:38:51 +0100
Date: Wed, 15 Dec 2004 14:38:51 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: moreau francis <francis_moreau2000@yahoo.fr>
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel located in KSEG2 or KSEG3.
Message-ID: <20041215133851.GD27935@linux-mips.org>
References: <20041213181252.23074.qmail@web25104.mail.ukl.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041213181252.23074.qmail@web25104.mail.ukl.yahoo.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6667
X-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, Dec 13, 2004 at 07:12:52PM +0100, moreau francis wrote:

> To learn on Linux kernel, I've decided to port it on 
> particular board with (very) limited resources and
> based with a 4KC processor core. As far I see, I need
> at least a couple of mega bytes of memory to achieve
> my goal. 
> Unfortunately the only way to get this amount of mem
> is
> to execute linux in memory that can only be accessed
> through KSEG2 and KSEG3 !
> 
> Here is my board's mapping:
> 
> Physical Memory Map:
> 
> start        size       type
> -----------------------------
> 0x20000000 - 8MB    - SDRAM
> 0x30000000 - 16MB   - FLASH
> 0x40000000 - 16MB   - FLASH
> 0x50000000 - 2MB    - SRAM
> 
> 
> I looked into the memory init code and I don't think
> that it's possible to run linux in a segment different
> from KSEG0. Am I wrong ?

It's not.  The 4kc processor when running with the BEV bit in the status
register cleared will try to find it's exception vectors at address
KSEG0, so there would have to be *some* code mapped there.  With BEV=1
exception vectors would be located in the firmware as pointed out by
Steve in his answer.  Firmware means something like flashmemory and running
uncached, so will be prohibitivly slow.  I just can't believe a system to
be that missdesigned!

> I've noticed a CONFIG_MAPPED_KERNEL macro but it seems
> that it's only used to replicate kernel from mapped
> memory to KSEG0...

That's correct.  CONFIG_MAPPED_KERNEL was written to support large ccNUMA
systems (large meaning two or three digit numbers of processors) where
preferably each node should run it's own copy of the OS kernel.  It's
a missdesigned, therefore ineffective implementation that was also only
working because of some assumption on the way gcc generates tools.

  Ralf

From ralf@linux-mips.org Wed Dec 15 13:57:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 13:57:21 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:26643
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225005AbULON5R>; Wed, 15 Dec 2004 13:57:17 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFDv1d0028949;
	Wed, 15 Dec 2004 14:57:01 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFDuusG028948;
	Wed, 15 Dec 2004 14:56:56 +0100
Date: Wed, 15 Dec 2004 14:56:56 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: wlacey <wlacey@goldenhindresearch.com>
Cc: linux-mips@linux-mips.org
Subject: Re: No PCI_AUTO in 2.6...
Message-ID: <20041215135656.GA28665@linux-mips.org>
References: <20041211134305.22769.qmail@server212.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041211134305.22769.qmail@server212.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6668
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Dec 11, 2004 at 01:43:05PM +0000, wlacey wrote:

> Might someone be willing to share a bit knowledge with me?
> 
> I've transitioned to the 2.6.10 kernel and I'm having a difficult time understanding what things I must do different to get my pci slots probed as before in 2.4. At this point I'm well aware the 2.6 is not a drop in replacement for 2.4 but what is the a general approach to getting something like PCI_AUTO capability in 2.6 what steps must I take and is there document describing them.

PCI_AUTO was really, really broken code.  It only works for some subset
of systems, won't handle hot plugging (Cardbus!), PCI-PCI bridges and many
other cases.  The world became a better place on the day when it got
removed.

> I call register_pci_controller() but the bus is never scanned becasue pcibios_init() fails out with...
> "Skipping PCI bus scan due to resource conflict"

The new PCI code by default will fully configure a PCI bus hierarchy.  For
this to work it needs to know which memory address range and which I/O
port address range are available for assignment.  This information is
passed in the struct pci_controller argument of register_pci_controller().
Here's a simplified example from arch/mips/sni/setup.c:

static struct resource sni_io_resource = {
        "PCIMT IO MEM", 0x00001000UL, 0x03bfffffUL, IORESOURCE_IO,
};

static struct resource sni_mem_resource = {
        "PCIMT PCI MEM", 0x10000000UL, 0xffffffffUL, IORESOURCE_MEM
};

extern struct pci_ops sni_pci_ops;

static struct pci_controller sni_controller = {
        .pci_ops        = &sni_pci_ops,
        .mem_resource   = &sni_mem_resource,
        .mem_offset     = 0x10000000UL,
        .io_resource    = &sni_io_resource,
        .io_offset      = 0x00000000UL
};

That is PCI memory is in the address range of 0x10000000UL - 0xffffffffUL
and I/O ports in the range 0x00001000UL - 0x03bfffffUL.  The io_offset
rsp. mem_offset values say how much needs to be added rsp. subtracted
when converting a PCI bus address into a physical address.  Often these
values are either the same a the resource's start address or zero.

I hope that explains things a little ...

  Ralf

From ralf@linux-mips.org Wed Dec 15 14:15:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 14:15:32 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:43539
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225011AbULOOP2>; Wed, 15 Dec 2004 14:15:28 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFEFC5u029252;
	Wed, 15 Dec 2004 15:15:12 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFEF8Wj029250;
	Wed, 15 Dec 2004 15:15:08 +0100
Date: Wed, 15 Dec 2004 15:15:08 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Hdei Nunoe <nunoe@co-nss.co.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: HIGHMEM
Message-ID: <20041215141508.GA29222@linux-mips.org>
References: <001101c4dbf9$1da02270$3ca06096@NUNOE> <20041207095837.GA13264@linux-mips.org> <001701c4e195$24d48260$3ca06096@NUNOE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001701c4e195$24d48260$3ca06096@NUNOE>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6669
X-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, Dec 14, 2004 at 01:26:55PM +0900, Hdei Nunoe wrote:

> >In 2.4 the support for CONFIG_DISCONTIG and CONFIG_NUMA are a bit tangled
> >with each other because IP27 is the only platform to uses these features
> >and it needs both.
> 
> Is it named "sgi-ip27"?

Yes, obviously :-)

> >Other than that you can also just setup your system
> >as 0x0 - 0x10000000 being RAM, 0x10000000 - 0x20000000 being reserved
> >memory and 0x20000000 - 0x30000000 being highmem.  Which works but is a
> >bit wasteful.
> 
> The gap in physical memory is 0x10000000 - 0x20000000, but it is 
> 0x90000000 -
> 0xC0000000 in virtual memory because there is K1 segment.  So the macros 
> such
> as __pa() or __va() does not work, I think.  Started to wonder it might not 
> be easy
> as just changing the PAGE_OFFSET value.  Do you see?

PAGE_OFFSET is the difference of a ZONE_NORMAL's virtual address and it's
physical address.  Once there is no more 1:1 mapping between physical and
virtual addresses such as in your suggestion PAGE_OFFSET can no longer be
used, that is you need to rewrite all users of this function.

  Ralf

From ralf@linux-mips.org Wed Dec 15 14:16:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 14:16:46 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:45587
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225011AbULOOQm>; Wed, 15 Dec 2004 14:16:42 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFEGNv0029282;
	Wed, 15 Dec 2004 15:16:23 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFEGEaG029274;
	Wed, 15 Dec 2004 15:16:14 +0100
Date: Wed, 15 Dec 2004 15:16:13 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: nunoe@co-nss.co.jp, linux-mips@linux-mips.org
Subject: Re: HIGHMEM
Message-ID: <20041215141613.GB29222@linux-mips.org>
References: <001101c4dbf9$1da02270$3ca06096@NUNOE> <20041207095837.GA13264@linux-mips.org> <20041213.133409.11964920.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041213.133409.11964920.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6670
X-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, Dec 13, 2004 at 01:34:09PM +0900, Atsushi Nemoto wrote:

> And this is a small step to a 64-bit kernel for TX49XX.  Could you
> apply?

Sure, done.

  Ralf

From ralf@linux-mips.org Wed Dec 15 14:19:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 14:19:05 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:47891
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225011AbULOOTB>; Wed, 15 Dec 2004 14:19:01 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFEIoc0029338;
	Wed, 15 Dec 2004 15:18:50 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFEInBa029337;
	Wed, 15 Dec 2004 15:18:49 +0100
Date: Wed, 15 Dec 2004 15:18:49 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jon Anders Haugum <jonah@omegav.ntnu.no>
Cc: linux-mips@linux-mips.org
Subject: Re: HIGHMEM
Message-ID: <20041215141849.GC29222@linux-mips.org>
References: <003801c4dc45$f9212690$2203a8c0@qfree.com> <20041207112038.X44387@invalid.ed.ntnu.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041207112038.X44387@invalid.ed.ntnu.no>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6671
X-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, Dec 07, 2004 at 11:29:04AM +0100, Jon Anders Haugum wrote:

> What about on a processor like the AMD au1550?
> 
> I've tried the latest from 2.4 branch in cvs, and I haven't been 
> successful in geting past INIT either...
> 
> Can I place all the memory from address 0x20000000 to get more than 
> 256Meg?

Yes, that should just work on Alchemy.

  Ralf

From ralf@linux-mips.org Wed Dec 15 14:21:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 14:21:39 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:51987
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225198AbULOOVf>; Wed, 15 Dec 2004 14:21:35 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFELKln029424;
	Wed, 15 Dec 2004 15:21:20 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFELAT4029405;
	Wed, 15 Dec 2004 15:21:10 +0100
Date: Wed, 15 Dec 2004 15:21:10 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6.10-rc3] fixed pci_ids.h
Message-ID: <20041215142110.GD29222@linux-mips.org>
References: <20041211222649.13895ef3.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041211222649.13895ef3.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6672
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Dec 11, 2004 at 10:26:49PM +0900, Yoichi Yuasa wrote:

> Some PCI IDs are defined doubly.
> Please apply this patch.

Done.

  Ralf

From ralf@linux-mips.org Wed Dec 15 14:28:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 14:28:32 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:60435
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225204AbULOO22>; Wed, 15 Dec 2004 14:28:28 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFESHba029560;
	Wed, 15 Dec 2004 15:28:17 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFESHZB029559;
	Wed, 15 Dec 2004 15:28:17 +0100
Date: Wed, 15 Dec 2004 15:28:17 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: show_stack, show_trace does not work for other process
Message-ID: <20041215142817.GE29222@linux-mips.org>
References: <20041210.141226.01918307.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041210.141226.01918307.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6673
X-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, Dec 10, 2004 at 02:12:26PM +0900, Atsushi Nemoto wrote:

> On kernel 2.6, SysRq-T (show_task()) can not show correct stack dump
> because show_stack() ignores an 'task' argument.  Here is a patch.  I
> fixed show_trace too.

Thanks,  applied.

  Ralf

From ralf@linux-mips.org Wed Dec 15 14:56:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 14:56:47 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:24340
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225272AbULOO4m>; Wed, 15 Dec 2004 14:56:42 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFEuRrL030051;
	Wed, 15 Dec 2004 15:56:27 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFEuH3g030050;
	Wed, 15 Dec 2004 15:56:17 +0100
Date: Wed, 15 Dec 2004 15:56:17 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Matthew Starzewski <mstarzewski@xes-inc.com>
Cc: linux-mips@linux-mips.org, Steve.Finney@SpirentCom.COM
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode, revisited
Message-ID: <20041215145617.GF29222@linux-mips.org>
References: <062301c4de41$5bf43cb0$0d00340a@matts>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <062301c4de41$5bf43cb0$0d00340a@matts>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6674
X-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, Dec 09, 2004 at 04:49:35PM -0600, Matthew Starzewski wrote:

> I've tried to enable HIGHMEM to access all 512MB of
> SDRAM on a BCM1125 based board as per this previous
> thread:
> 
> Using more than 256 MB of memory on SB1250 in 32-bit mode :
> http://www.spinics.net/lists/mips/msg14396.html
> BCM1125 Board: XPedite3000 PrPMC
> http://www.xes-inc.com/Products/XPedite/XPedite3000/XPedite3000.html
> 
> In MIPS32 mode, the memory map comes out to the following:
> 
> Physical Memory Map:
> 0x00000000 - 0x0FFFFFFF   256MB
> 0x80000000 - 0x8FFFFFFF   256MB
> Virtual Memory Map:
> 0x80000000 - 0x8FFFFFFF   256MB
> <<<< INACCESSIBLE >>>> 256MB
> 
> My goal in enabling HIGHMEM was to get at the upper 256MB
> much as described here.  Access to the upper 256MB through
> HIGHMEM may incur a performance hit, but it's certainly better
> going without.
> 
> http://home.earthlink.net/~jknapka/linux-mm/vminit.html#PAGING_INIT
> 
> However, what I get is a stall as per the log pasted below.  Enabling
> CONFIG_64BIT_PHYS_ADDR does not make a difference.  Results
> were cross-verified between CFE and another bootloader.

You need that if you want to address more than 1GB of memory on a BCM1250.

> When I hand the physical memory described above off to add_memory_region,
> I noticed a few odd things. One thing that looks suspicious is that the variable
> void *high_memory ends up being set to 0xa0000000, or right at KSEG1,
> in mm/init.c.
> 
> Also, num_physpages became huge, 0x90000, because the init code in
> kernel/setup.c and mm/init.c want a page for every memory location, even
> highmem.  Is this appropriate when the memory is not directly accessible
> via __va and virt_to_phys?  

You mean a struct page, not a page, I assume.  Yes, that's correct and
means that mem_map[] is a huge memory consumer in particular on systems
such as BCM1250 where RAM was scattered over the address space with a
shotgun.

The critical point would be where mem_map[] fills up the entire low-mem
which at 64 bytes per struct page and 256MB low-mem would happen at
4194304 pages or 16GB total memory at a page size at 4kB page size.
That's a suprenum, so guaranteed to not be exceeded ;-)  In reality
for reasonable performance a 1:4 ratio between lowmem and highmem should
not be exceeded.

What aggrevates the situation without CONFIG_DISCONTIG on the BCM1250 is
the large gap in it's address space from 0x10000000 - 0x8000000, that's
1.75GB which will eat 28MB of lowmem for mem_map - for nothing.  That's
not lethal but certainly deserves optimization.

> Let me know what you think of this issue.  In anticipation of the
> "Why not use MIPS64 build?" question, we'd prefer to and will, but the 
> MIPS64 build has underperformed or had bugs (SATA seek time,

Why would SATA seek times have any relation to the underlying kernel ...

> networking signals, etc) that MIPS32 doesn't.  For these issues
> or any case where the MIPS64 build isn't there yet, it makes
> sense to have the MIPS32 path open.

You could try to map some memory to CKSEG2/3 at the price of reducing the
amount of address space available, see also the current thread with
subject "HIGHMEM".  That approach will only work well upto 1GB RAM on
the BCM1250.  At that point you'll run into the limit of it's 32-bit
PCI bus, so will have to deal with bounce buffers or make use of it's
somewhat limited I/O MMU.

  Ralf

From mstarzewski@xes-inc.com Wed Dec 15 15:03:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 15:03:31 +0000 (GMT)
Received: from xes-inc.com ([IPv6:::ffff:24.196.136.110]:11410 "EHLO
	xes-inc.com") by linux-mips.org with ESMTP id <S8225272AbULOPD0>;
	Wed, 15 Dec 2004 15:03:26 +0000
Received: from matts ([10.52.0.13])
	by xes-inc.com (8.11.6/8.11.6) with SMTP id iBFF2pi13189;
	Wed, 15 Dec 2004 09:02:54 -0600
Message-ID: <064501c4e2b7$2591c820$0d00340a@matts>
From: "Matthew Starzewski" <mstarzewski@xes-inc.com>
To: "Thomas Petazzoni" <thomas.petazzoni@enix.org>
Cc: <linux-mips@linux-mips.org>
References: <062301c4de41$5bf43cb0$0d00340a@matts> <41B96281.2050806@enix.org> <073a01c4dec7$184527a0$0d00340a@matts> <41B9CA72.7030208@enix.org>
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode, revisited
Date: Wed, 15 Dec 2004 09:02:48 -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: <mstarzewski@xes-inc.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6675
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mstarzewski@xes-inc.com
Precedence: bulk
X-list: linux-mips

> This may be an ancillary effect of what's mentioned above, but when
num_physpages
> grows in size, nr_free_pages doesn't track with it, so in void
vfs_caches_init(unsigned long
> mempages) and the like, you get a horrible underflow condition:
>
> /* code */
>        printk("MJS - nr_free_pages():0x%X\n", nr_free_pages());
>        printk("MJS - OLD mempages:0x%X\n", mempages);
>        reserve = (mempages - nr_free_pages()) * 3/2;
>        mempages -= reserve;
>        printk("MJS - NEW reserve:0x%X mempages:0x%X\n",
>               reserve, mempages);
>
> /* printout */
> MJS - nr_free_pages():0x1E9A0
> MJS - OLD mempages:0x90000
> MJS - NEW reserve:0xAA190 mempages:0xFFFE5E70

I thought I'd wrap up this thread, especially with the HIGHMEM thread still
going around:

http://www.linux-mips.org/archives/linux-mips/2004-12/msg00141.html

The above underflow *was* my problem.  I was working in 2.6.6-rc3 before;
with the patch below from 2.6.7-rc1 everything works fine.

#  VFS cache sizing fix for small machines
http://linux.bkbits.net:8080/linux-2.6/diffs/fs/dcache.c@1.81?nav=index.html
|src/|src/fs|hist/fs/dcache.c
# BitKeeper ChangeSet
http://linux.bkbits.net:8080/linux-2.6/cset@1.1717.23.50?nav=index.html|src/
|src/fs|related/fs/dcache.c

In fs/dcache.c, vfs_caches_init():
<  reserve = (mempages - nr_free_pages()) * 3/2;
> reserve = min((mempages - nr_free_pages()) * 3/2, mempages - 1);

Regards,
Matt


----- Original Message -----
From: "Thomas Petazzoni" <thomas.petazzoni@enix.org>
To: "Matthew Starzewski" <mstarzewski@xes-inc.com>
Cc: <linux-mips@linux-mips.org>
Sent: Friday, December 10, 2004 10:10 AM
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode,
revisited




From macro@linux-mips.org Wed Dec 15 15:25:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 15:25:41 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:53515 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225005AbULOPZg>; Wed, 15 Dec 2004 15:25:36 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 0116FE1CBC; Wed, 15 Dec 2004 16:25:13 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 28756-02; Wed, 15 Dec 2004 16:25:12 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id A5DE4E1CB3; Wed, 15 Dec 2004 16:25:12 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iBFFPLSX002443;
	Wed, 15 Dec 2004 16:25:22 +0100
Date: Wed, 15 Dec 2004 15:25:13 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: wlacey <wlacey@goldenhindresearch.com>, linux-mips@linux-mips.org
Subject: Re: No PCI_AUTO in 2.6...
In-Reply-To: <20041215135656.GA28665@linux-mips.org>
Message-ID: <Pine.LNX.4.58L.0412151456050.2706@blysk.ds.pg.gda.pl>
References: <20041211134305.22769.qmail@server212.com> <20041215135656.GA28665@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/617/Sun Dec  5 16:25:39 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6676
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, 15 Dec 2004, Ralf Baechle wrote:

> Here's a simplified example from arch/mips/sni/setup.c:
> 
> static struct resource sni_io_resource = {
>         "PCIMT IO MEM", 0x00001000UL, 0x03bfffffUL, IORESOURCE_IO,
> };
> 
> static struct resource sni_mem_resource = {
>         "PCIMT PCI MEM", 0x10000000UL, 0xffffffffUL, IORESOURCE_MEM
> };

 I think it's more descriptive to call them "<foo> PCI I/O" and "<foo> PCI
MEM", respectively, to make it clearer the former expresses I/O port
addresses (not the associated memory address range for accesses to be
forwarded as PCI I/O cycles) and that both are PCI bus spaces.

 Also for most PCI systems I/O port space should really start at 0 (for
"legacy" devices being decoded by the PCI-ISA bridge if there's one in the
system), but generic code braindamage prevents it currently.  I think
there was only about a single PCI chipset that had a "reversed"
architecture and sort-of bridged PCI over ISA -- the Intel i82420EX for
the i486 processor.  It would need a separate ISA I/O resource for a
correct view of the system.

> That is PCI memory is in the address range of 0x10000000UL - 0xffffffffUL
> and I/O ports in the range 0x00001000UL - 0x03bfffffUL.  The io_offset
> rsp. mem_offset values say how much needs to be added rsp. subtracted
> when converting a PCI bus address into a physical address.  Often these
> values are either the same a the resource's start address or zero.

 Things start being tricky once you have to use such an offset for DMA
transfers as well...

  Maciej

From yuasa@hh.iij4u.or.jp Wed Dec 15 16:21:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 16:21:17 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:31940
	"EHLO pD9562F66.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225005AbULOQVN>; Wed, 15 Dec 2004 16:21:13 +0000
Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:24570 "EHLO
	mo00.iij4u.or.jp") by linux-mips.net with ESMTP id <S868871AbULOQVB>;
	Wed, 15 Dec 2004 17:21:01 +0100
Received: MO(mo00)id iBFGKbZm000953; Thu, 16 Dec 2004 01:20:37 +0900 (JST)
Received: MDO(mdo00) id iBFGKaRO006393; Thu, 16 Dec 2004 01:20:36 +0900 (JST)
Received: 4UMRO01 id iBFGKZ3S001846; Thu, 16 Dec 2004 01:20:36 +0900 (JST)
	from stratos (localhost [127.0.0.1]) (authenticated)
Date: Thu, 16 Dec 2004 01:20:32 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6.10-rc3] remove duplicate extern in <linux/sched.h>
Message-Id: <20041216012032.3af62ce1.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.0beta3 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6677
X-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

Hi Ralf,

This patch remove duplicate extern in <linux/sched.h>.
Please apply this patch to v2.6 CVS tree.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/include/linux/sched.h a/include/linux/sched.h
--- a-orig/include/linux/sched.h	Sun Dec  5 21:25:05 2004
+++ a/include/linux/sched.h	Thu Dec 16 00:55:42 2004
@@ -802,8 +802,6 @@
 extern int in_group_p(gid_t);
 extern int in_egroup_p(gid_t);
 
-extern void release_task(struct task_struct * p);
-
 extern void proc_caches_init(void);
 extern void flush_signals(struct task_struct *);
 extern void flush_signal_handlers(struct task_struct *, int force_default);

From ralf@linux-mips.org Wed Dec 15 16:40:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 16:40:57 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:52501
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225005AbULOQkw>; Wed, 15 Dec 2004 16:40:52 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFGebsd031883;
	Wed, 15 Dec 2004 17:40:37 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFGea8N031882;
	Wed, 15 Dec 2004 17:40:36 +0100
Date: Wed, 15 Dec 2004 17:40:36 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: wlacey <wlacey@goldenhindresearch.com>, linux-mips@linux-mips.org
Subject: Re: No PCI_AUTO in 2.6...
Message-ID: <20041215164036.GC30130@linux-mips.org>
References: <20041211134305.22769.qmail@server212.com> <20041215135656.GA28665@linux-mips.org> <Pine.LNX.4.58L.0412151456050.2706@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58L.0412151456050.2706@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6678
X-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, Dec 15, 2004 at 03:25:13PM +0000, Maciej W. Rozycki wrote:

> > Here's a simplified example from arch/mips/sni/setup.c:
> > 
> > static struct resource sni_io_resource = {
> >         "PCIMT IO MEM", 0x00001000UL, 0x03bfffffUL, IORESOURCE_IO,
> > };
> > 
> > static struct resource sni_mem_resource = {
> >         "PCIMT PCI MEM", 0x10000000UL, 0xffffffffUL, IORESOURCE_MEM
> > };
> 
>  I think it's more descriptive to call them "<foo> PCI I/O" and "<foo> PCI
> MEM", respectively, to make it clearer the former expresses I/O port
> addresses (not the associated memory address range for accesses to be
> forwarded as PCI I/O cycles) and that both are PCI bus spaces.
> 
>  Also for most PCI systems I/O port space should really start at 0 (for
> "legacy" devices being decoded by the PCI-ISA bridge if there's one in the
> system), but generic code braindamage prevents it currently.  I think
> there was only about a single PCI chipset that had a "reversed"
> architecture and sort-of bridged PCI over ISA -- the Intel i82420EX for
> the i486 processor.  It would need a separate ISA I/O resource for a
> correct view of the system.

In the above case, the I/O port resource is starting at 0x1000 because
the range of 0x0 - 0xfff contains a few legacy devices.  The way the SNI
code is initializing sni_io_resource ensures all the legacy devices
are properly listed in the iomem_resource and /proc/ioports and the kernel
will never place any I/O resource for a PCI card in the legacy port range.
As the result we'll get:

[root@tbird root]# cat /proc/ioports
00000000-0000001f : dma1
00000020-0000003f : pic1
00000040-0000005f : timer
00000060-0000006f : keyboard
00000070-00000077 : rtc
00000080-0000008f : dma page reg
000000a0-000000bf : pic2
000000c0-000000df : dma2
000002f8-000002ff : serial
000003c0-000003df : vga+
000003f8-000003ff : serial
00000cfc-00000cff : PCI config data
00001000-03bfffff : PCIMT IO MEM
  00001000-000010ff : 0000:00:01.0
    00001000-000010ff : sym53c8xx
  00001400-0000141f : 0000:00:02.0
    00001400-0000141f : pcnet32_probe_pci
[root@tbird root]#

This makes it look like the legacy ports are not behind the PCI bus
which actually they are but that's a minor nit, it gets the address
space allocation to work right.

> > That is PCI memory is in the address range of 0x10000000UL - 0xffffffffUL
> > and I/O ports in the range 0x00001000UL - 0x03bfffffUL.  The io_offset
> > rsp. mem_offset values say how much needs to be added rsp. subtracted
> > when converting a PCI bus address into a physical address.  Often these
> > values are either the same a the resource's start address or zero.
> 
>  Things start being tricky once you have to use such an offset for DMA
> transfers as well...

True, but that's dealt with elsewhere.  And I never claimed the mess that
PCI used to be in 2.4 has yet been fully cleaned up yet, more work to do.

  Ralf

From macro@linux-mips.org Wed Dec 15 17:17:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 17:17:33 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:52742 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225283AbULORR1>; Wed, 15 Dec 2004 17:17:27 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id E586CF5973; Wed, 15 Dec 2004 18:17:11 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 11083-05; Wed, 15 Dec 2004 18:17:11 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id AB5F6F5970; Wed, 15 Dec 2004 18:17:11 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iBFHHOb2008822;
	Wed, 15 Dec 2004 18:17:24 +0100
Date: Wed, 15 Dec 2004 17:17:14 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: wlacey <wlacey@goldenhindresearch.com>, linux-mips@linux-mips.org
Subject: Re: No PCI_AUTO in 2.6...
In-Reply-To: <20041215164036.GC30130@linux-mips.org>
Message-ID: <Pine.LNX.4.58L.0412151648460.2706@blysk.ds.pg.gda.pl>
References: <20041211134305.22769.qmail@server212.com> <20041215135656.GA28665@linux-mips.org>
 <Pine.LNX.4.58L.0412151456050.2706@blysk.ds.pg.gda.pl>
 <20041215164036.GC30130@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/617/Sun Dec  5 16:25:39 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6679
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, 15 Dec 2004, Ralf Baechle wrote:

> >  Also for most PCI systems I/O port space should really start at 0 (for
> > "legacy" devices being decoded by the PCI-ISA bridge if there's one in the
> > system), but generic code braindamage prevents it currently.  I think
> > there was only about a single PCI chipset that had a "reversed"
> > architecture and sort-of bridged PCI over ISA -- the Intel i82420EX for
> > the i486 processor.  It would need a separate ISA I/O resource for a
> > correct view of the system.
> 
> In the above case, the I/O port resource is starting at 0x1000 because
> the range of 0x0 - 0xfff contains a few legacy devices.  The way the SNI
> code is initializing sni_io_resource ensures all the legacy devices
> are properly listed in the iomem_resource and /proc/ioports and the kernel
> will never place any I/O resource for a PCI card in the legacy port range.

 I know and I consider it a bug.  The correct way would be setting the 
start at 0 and if avoiding the first kB of space was necessary, setting 
PCIBIOS_MIN_IO to 0x1000.

> As the result we'll get:
> 
> [root@tbird root]# cat /proc/ioports
> 00000000-0000001f : dma1
> 00000020-0000003f : pic1
> 00000040-0000005f : timer
> 00000060-0000006f : keyboard
> 00000070-00000077 : rtc
> 00000080-0000008f : dma page reg
> 000000a0-000000bf : pic2
> 000000c0-000000df : dma2
> 000002f8-000002ff : serial
> 000003c0-000003df : vga+
> 000003f8-000003ff : serial
> 00000cfc-00000cff : PCI config data
> 00001000-03bfffff : PCIMT IO MEM
>   00001000-000010ff : 0000:00:01.0
>     00001000-000010ff : sym53c8xx
>   00001400-0000141f : 0000:00:02.0
>     00001400-0000141f : pcnet32_probe_pci
> [root@tbird root]#
> 
> This makes it look like the legacy ports are not behind the PCI bus
> which actually they are but that's a minor nit, it gets the address
> space allocation to work right.

 I think it's going to matter if a PCI-ISA bridge is behind one or more
PCI-PCI bridges.  I have an idea of a fix, but my initial approach haven't
worked particularly well and I've had no time to dig into it further.  
Actually, on systems with PCI I think reserving legacy resources should
happen only after they have been discovered (you don't need any PC/AT or
ISA devices for a PCI configuration space scan), but that may be tough, so
I've thought of an alternative.

 Also the map of legacy resources reserved is actually incomplete -- PIC's
ELCR is missing for example.

> >  Things start being tricky once you have to use such an offset for DMA
> > transfers as well...
> 
> True, but that's dealt with elsewhere.  And I never claimed the mess that
> PCI used to be in 2.4 has yet been fully cleaned up yet, more work to do.

 Sure, I'm more or less happy about the new code.  I'm just warning about 
possible pitfalls.

 There is one more problem with the PCI resource manager -- it messes with
BARs of host bridges without asking for permission (which is often a
no-no, as any messing with host bridges in general).  I have a patch for
it I'm currently trying to push to the PCI maintainer.  See the thread at
"http://www.uwsg.iu.edu/hypermail/linux/kernel/0412.1/0484.html" if
interested.  It's already being done correctly for i386 (some would
probably argue that's what's most important) and ppc which use their own
resource managers instead of the generic one.

  Maciej

From ralf@linux-mips.org Wed Dec 15 18:42:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 18:42:35 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:34583
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225272AbULOSm3>; Wed, 15 Dec 2004 18:42:29 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFIgDFj001469;
	Wed, 15 Dec 2004 19:42:13 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFIgDXx001468;
	Wed, 15 Dec 2004 19:42:13 +0100
Date: Wed, 15 Dec 2004 19:42:13 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: wlacey <wlacey@goldenhindresearch.com>, linux-mips@linux-mips.org
Subject: Re: No PCI_AUTO in 2.6...
Message-ID: <20041215184213.GB32491@linux-mips.org>
References: <20041211134305.22769.qmail@server212.com> <20041215135656.GA28665@linux-mips.org> <Pine.LNX.4.58L.0412151456050.2706@blysk.ds.pg.gda.pl> <20041215164036.GC30130@linux-mips.org> <Pine.LNX.4.58L.0412151648460.2706@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58L.0412151648460.2706@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6680
X-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, Dec 15, 2004 at 05:17:14PM +0000, Maciej W. Rozycki wrote:

>  I know and I consider it a bug.  The correct way would be setting the 
> start at 0 and if avoiding the first kB of space was necessary, setting 
> PCIBIOS_MIN_IO to 0x1000.

PCIBIOS_MIN_IO is the same value for all busses.  That can turn out a bit
kludgy so I'm not much of a friend of it.

> > This makes it look like the legacy ports are not behind the PCI bus
> > which actually they are but that's a minor nit, it gets the address
> > space allocation to work right.
> 
>  I think it's going to matter if a PCI-ISA bridge is behind one or more
> PCI-PCI bridges.  I have an idea of a fix, but my initial approach haven't
> worked particularly well and I've had no time to dig into it further.  
> Actually, on systems with PCI I think reserving legacy resources should
> happen only after they have been discovered (you don't need any PC/AT or
> ISA devices for a PCI configuration space scan), but that may be tough, so
> I've thought of an alternative.

The evil about legacy devices is "they're just there".  That is you have
to know about their existence and in some case can't even do real probing
or the device will react in really nasty ways.

The existence of an ELCR register is not documented for this machine.
Anyway, the approach I've choosen is safe even we it exists.

>  Also the map of legacy resources reserved is actually incomplete -- PIC's
> ELCR is missing for example.
> 
> > >  Things start being tricky once you have to use such an offset for DMA
> > > transfers as well...
> > 
> > True, but that's dealt with elsewhere.  And I never claimed the mess that
> > PCI used to be in 2.4 has yet been fully cleaned up yet, more work to do.
> 
>  Sure, I'm more or less happy about the new code.  I'm just warning about 
> possible pitfalls.
> 
>  There is one more problem with the PCI resource manager -- it messes with
> BARs of host bridges without asking for permission (which is often a
> no-no, as any messing with host bridges in general).  I have a patch for
> it I'm currently trying to push to the PCI maintainer.  See the thread at
> "http://www.uwsg.iu.edu/hypermail/linux/kernel/0412.1/0484.html" if
> interested.  It's already being done correctly for i386 (some would
> probably argue that's what's most important) and ppc which use their own
> resource managers instead of the generic one.

That's a problem on many system controllers such as the GT-64120, all the
other Galileo / Marvell stuff and more.  The hackish solution of doing it
in the pci_ops we're currently isn't a good one.

A comment on your patch.  For most configurations it's ok and certainly
better than hacking the pci_ops.  At least on the GT-64120 it's possible
to configure the device as a memory device and that will make your patch
fail.  Also there is the case where the GT-64120 or similar system
controllers are used on a PCI card.  For the CPU on the card it'll be
the host bridge; for the host system just yet another PCI device.

  Ralf

From macro@linux-mips.org Wed Dec 15 19:29:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 19:30:00 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:6158 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225272AbULOT3v>; Wed, 15 Dec 2004 19:29:51 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id AED26F5985; Wed, 15 Dec 2004 20:29:31 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 31483-07; Wed, 15 Dec 2004 20:29:31 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 6E731F5982; Wed, 15 Dec 2004 20:29:31 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iBFJTj0m016838;
	Wed, 15 Dec 2004 20:29:45 +0100
Date: Wed, 15 Dec 2004 19:29:34 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: No PCI_AUTO in 2.6...
In-Reply-To: <20041215184213.GB32491@linux-mips.org>
Message-ID: <Pine.LNX.4.58L.0412151846190.2706@blysk.ds.pg.gda.pl>
References: <20041211134305.22769.qmail@server212.com> <20041215135656.GA28665@linux-mips.org>
 <Pine.LNX.4.58L.0412151456050.2706@blysk.ds.pg.gda.pl>
 <20041215164036.GC30130@linux-mips.org> <Pine.LNX.4.58L.0412151648460.2706@blysk.ds.pg.gda.pl>
 <20041215184213.GB32491@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/617/Sun Dec  5 16:25:39 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6681
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, 15 Dec 2004, Ralf Baechle wrote:

> >  I know and I consider it a bug.  The correct way would be setting the 
> > start at 0 and if avoiding the first kB of space was necessary, setting 
> > PCIBIOS_MIN_IO to 0x1000.
> 
> PCIBIOS_MIN_IO is the same value for all busses.  That can turn out a bit

 ???  It's a variable and the IP32 port already modifies it.

> kludgy so I'm not much of a friend of it.

 Probably the best way of dealing with an incomplete resource setup.  
There is nothing wrong with setting BARs in the first kB of I/O space, but
this way you may overlay an unregistered ISA-bridge device with another
one.  Of course it's PCI-ISA bridges that should have BARs for their
resources, but I guess it's not going to happen.  Though perhaps they
could be created artificially in our PCI layer...

> >  I think it's going to matter if a PCI-ISA bridge is behind one or more
> > PCI-PCI bridges.  I have an idea of a fix, but my initial approach haven't
> > worked particularly well and I've had no time to dig into it further.  
> > Actually, on systems with PCI I think reserving legacy resources should
> > happen only after they have been discovered (you don't need any PC/AT or
> > ISA devices for a PCI configuration space scan), but that may be tough, so
> > I've thought of an alternative.
> 
> The evil about legacy devices is "they're just there".  That is you have
> to know about their existence and in some case can't even do real probing
> or the device will react in really nasty ways.

 No need to probe.  The PCI-ISA bridge should reserve the entire
motherboard I/O range of 0x00 - 0xff plus any other non-ISA one that it 
knows it uses.  ISA I/O ranges (with bits 8 or 9 non-zero) are already 
excluded implicitly.

> The existence of an ELCR register is not documented for this machine.

 What kind of PCI-ISA bridge is it?  You need ELCR whenever you want to
route PCI interrupts to some of i8259A inputs to set the trigger mode
correctly.  It's an EISA invention -- with the original i8259A you could 
only set up the trigger mode globally per chip (using ICW1).

> Anyway, the approach I've choosen is safe even we it exists.

 Have you tried with a PCI-PCI bridge in the middle?  Or do you have a
theoretical proof our code handles it right? ;-)

> >  There is one more problem with the PCI resource manager -- it messes with
> > BARs of host bridges without asking for permission (which is often a
> > no-no, as any messing with host bridges in general).  I have a patch for
> > it I'm currently trying to push to the PCI maintainer.  See the thread at
> > "http://www.uwsg.iu.edu/hypermail/linux/kernel/0412.1/0484.html" if
> > interested.  It's already being done correctly for i386 (some would
> > probably argue that's what's most important) and ppc which use their own
> > resource managers instead of the generic one.
> 
> That's a problem on many system controllers such as the GT-64120, all the
> other Galileo / Marvell stuff and more.  The hackish solution of doing it
> in the pci_ops we're currently isn't a good one.

 Sure -- I have a couple of reverts for these hacks ready.

> A comment on your patch.  For most configurations it's ok and certainly
> better than hacking the pci_ops.  At least on the GT-64120 it's possible
> to configure the device as a memory device and that will make your patch

 That's intended.  If it's not a host bridge (implying it's an option
device/card) it should not be treated as such.

> fail.  Also there is the case where the GT-64120 or similar system
> controllers are used on a PCI card.  For the CPU on the card it'll be
> the host bridge; for the host system just yet another PCI device.

 Well in case of PCI cards they really should have their class codes set
to something different from a host bridge.  AFAIK PCI is not meant as a
star interconnect between hosts -- it's meant to have a tree topology
rooted at a host bridge (that may be a bit different with the introduction
of HyperTransport and its dual-hosted chains, but it's probably too early
to worry about it).  Of course you may have multiple host bridge devices
in a system with peer host bridges, but then you just have multiple PCI
buses with no path connecting them.

 Anyway if a setup with host bridges as option devices really existed, it
should probably be handled by the CPU and the associated firmware running
behind such bridges and if that was impossible, then by the driver for the
device.  Do you think such a setup is probable?  How about putting such an
option into an i386-based system?  It would skip BARs on host bridges
anyway. ;-)

  Maciej

From ralf@linux-mips.org Wed Dec 15 19:53:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 19:53:49 +0000 (GMT)
Received: from pD9562F66.dip.t-dialin.net ([IPv6:::ffff:217.86.47.102]:61976
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225272AbULOTxp>; Wed, 15 Dec 2004 19:53:45 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBFJrUhl002686;
	Wed, 15 Dec 2004 20:53:30 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBFJrTpa002685;
	Wed, 15 Dec 2004 20:53:29 +0100
Date: Wed, 15 Dec 2004 20:53:29 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6.10-rc3] remove duplicate extern in <linux/sched.h>
Message-ID: <20041215195329.GA2640@linux-mips.org>
References: <20041216012032.3af62ce1.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041216012032.3af62ce1.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6682
X-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, Dec 16, 2004 at 01:20:32AM +0900, Yoichi Yuasa wrote:

> This patch remove duplicate extern in <linux/sched.h>.
> Please apply this patch to v2.6 CVS tree.

Applied,

  Ralf

From macro@mips.com Wed Dec 15 21:14:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 21:14:19 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:64261 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225272AbULOVOK>;
	Wed, 15 Dec 2004 21:14:10 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1Cega3-0002uU-00; Wed, 15 Dec 2004 21:21:07 +0000
Received: from perivale.mips.com ([192.168.192.200])
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1CegSo-0003dk-00; Wed, 15 Dec 2004 21:13:38 +0000
Received: from macro (helo=localhost)
	by perivale.mips.com with local-esmtp (Exim 3.36 #1 (Debian))
	id 1CegSn-00040Q-00; Wed, 15 Dec 2004 21:13:37 +0000
Date: Wed, 15 Dec 2004 21:13:37 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@mips.com>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org,
	"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: [PATCH] I/O helpers rework
Message-ID: <Pine.LNX.4.61.0412151936460.14855@perivale.mips.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.739,
	required 4, AWL, BAYES_00)
Return-Path: <macro@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: 6683
X-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@mips.com
Precedence: bulk
X-list: linux-mips

Hello,

 While trying using an IDE interface driver with big-endian systems, I've 
noticed some of our port/mm I/O accessory functions/macros get endianness 
incorrectly.  In particular a lot of drivers expect single I/O accesses to 
return correct numerical value of data as seen by the CPU while string I/O 
accesses to preserve byte ordering in memory.

 As the whole file seemed a bit messy to me I decided to rewrite these 
functions/macros completely.  To ease long-term maintenance I created 
common templates for all classes of accesses which expand to appropriate 
code for different transfer unit width.  I made all operations to be 
expressed as inline functions to catch dangerous/incorrect uses.  The 
result are the following function classes:

1. in*()/out*()/read*()/write*() perform single operations on data using 
   little-endian ordering.

2. __raw_in*()/__raw_out*()/__raw_read*()/__raw_write*() perform single 
   operations on data using memory ordering.

3. bus_read*()/bus_write*() perform single on data using CPU bus ordering 
   (that is as it appears at the bus, regardless of any address or lane 
   swappers that may modify it on the way between the CPU and a device).

4. __bus_readq()/__bus_writeq() are hacks for 64-bit accesses avoiding 
   interrupt masking when used with a 32-bit kernel and are otherwise the 
   same as bus_readq()/bus_writeq().

5. ins*()/outs*()/reads*()/writes*() perform string operations on data 
   using memory ordering yielding the same result as a corresponding DMA 
   transfer would.

The naming of 1., 2. and perhaps 5. above is a bit unfortunate, but that's 
what much code elsewhere expects.  These variants assume a ISA/EISA/PCI 
bus, little-endian.  They perform minimum of swapping required -- they 
avoid swapping data back and forth to keep good performance.  For 
buses/devices that follow CPU endianness use 3. or perhaps 4. if 
interrupts have already been masked.

 The changes have been verified with a Malta board for port I/O and with a 
SWARM one for memory-mapped I/O (with an updated driver; to be sent 
separately).  Broadcom SiByte systems are the only ones utilizing current 
__raw_*() and ____raw_*() calls.  I have a patch to convert them to 
bus_*() and __bus_*() ones as appropriate ready as well.

 OK to apply?

  Maciej

patch-mips-2.6.10-rc2-20041124-mips-ide-27
diff -up --recursive --new-file linux-mips-2.6.10-rc2-20041124.macro/include/asm-mips/io.h linux-mips-2.6.10-rc2-20041124/include/asm-mips/io.h
--- linux-mips-2.6.10-rc2-20041124.macro/include/asm-mips/io.h	2004-11-22 14:27:59.000000000 +0000
+++ linux-mips-2.6.10-rc2-20041124/include/asm-mips/io.h	2004-12-13 13:05:29.000000000 +0000
@@ -6,21 +6,26 @@
  * Copyright (C) 1994, 1995 Waldorf GmbH
  * Copyright (C) 1994 - 2000 Ralf Baechle
  * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
+ * Copyright (C) 2004  MIPS Technologies, Inc.  All rights reserved.
+ *	Author:	Maciej W. Rozycki <macro@mips.com>
  */
 #ifndef _ASM_IO_H
 #define _ASM_IO_H
 
 #include <linux/config.h>
 #include <linux/compiler.h>
+#include <linux/kernel.h>
 #include <linux/types.h>
 
 #include <asm/addrspace.h>
+#include <asm/bug.h>
+#include <asm/byteorder.h>
 #include <asm/cpu.h>
 #include <asm/cpu-features.h>
 #include <asm/page.h>
 #include <asm/pgtable-bits.h>
 #include <asm/processor.h>
-#include <asm/byteorder.h>
+
 #include <mangle-port.h>
 
 /*
@@ -29,34 +34,52 @@
 #undef CONF_SLOWDOWN_IO
 
 /*
- * Sane hardware offers swapping of I/O space accesses in hardware; less
- * sane hardware forces software to fiddle with this ...
+ * Sane hardware offers swapping of PCI/ISA I/O space accesses in hardware;
+ * less sane hardware forces software to fiddle with this...
  */
-#if defined(CONFIG_SWAP_IO_SPACE) && defined(__MIPSEB__)
+#if defined(CONFIG_SWAP_IO_SPACE)
 
-#define __ioswab8(x) (x)
-
-#ifdef CONFIG_SGI_IP22
+# define ioswabb(x)		(x)
+# define __raw_ioswabb(x)	(x)
+# ifdef CONFIG_SGI_IP22
 /*
  * IP22 seems braindead enough to swap 16bits values in hardware, but
  * not 32bits.  Go figure... Can't tell without documentation.
  */
-#define __ioswab16(x) (x)
-#else
-#define __ioswab16(x) swab16(x)
-#endif
-#define __ioswab32(x) swab32(x)
-#define __ioswab64(x) swab64(x)
+#  define ioswabw(x)		(x)
+#  define __raw_ioswabw(x)	le16_to_cpu(x)
+# else
+#  define ioswabw(x)		le16_to_cpu(x)
+#  define __raw_ioswabw(x)	(x)
+# endif
+# define ioswabl(x)		le32_to_cpu(x)
+# define __raw_ioswabl(x)	(x)
+# define ioswabq(x)		le64_to_cpu(x)
+# define __raw_ioswabq(x)	(x)
 
 #else
 
-#define __ioswab8(x) (x)
-#define __ioswab16(x) (x)
-#define __ioswab32(x) (x)
-#define __ioswab64(x) (x)
+# define ioswabb(x)		(x)
+# define __raw_ioswabb(x)	(x)
+# define ioswabw(x)		(x)
+# define __raw_ioswabw(x)	cpu_to_le16(x)
+# define ioswabl(x)		(x)
+# define __raw_ioswabl(x)	cpu_to_le32(x)
+# define ioswabq(x)		(x)
+# define __raw_ioswabq(x)	cpu_to_le64(x)
 
 #endif
 
+/*
+ * Native bus accesses never swapped.
+ */
+#define bus_ioswabb(x)		(x)
+#define bus_ioswabw(x)		(x)
+#define bus_ioswabl(x)		(x)
+#define bus_ioswabq(x)		(x)
+
+#define __bus_ioswabq		bus_ioswabq
+
 #define IO_SPACE_LIMIT 0xffff
 
 /*
@@ -245,108 +268,202 @@ static inline void iounmap(volatile void
 	__iounmap(addr);
 }
 
-#define __raw_readb(addr)						\
-	(*(volatile unsigned char *) __swizzle_addr_b((unsigned long)(addr)))
-#define __raw_readw(addr)						\
-	(*(volatile unsigned short *) __swizzle_addr_w((unsigned long)(addr)))
-#define __raw_readl(addr)						\
-	(*(volatile unsigned int *) __swizzle_addr_l((unsigned long)(addr)))
-#ifdef CONFIG_MIPS32
-#define ____raw_readq(addr)						\
-({									\
-	u64 __res;							\
-									\
-	__asm__ __volatile__ (						\
-		"	.set	mips3		# ____raw_readq	\n"	\
-		"	ld	%L0, (%1)			\n"	\
-		"	dsra32	%M0, %L0, 0			\n"	\
-		"	sll	%L0, %L0, 0			\n"	\
-		"	.set	mips0				\n"	\
-		: "=r" (__res)						\
-		: "r" (__swizzle_addr_q((unsigned long)(addr))));	\
-	__res;								\
-})
-#define __raw_readq(addr)						\
-({									\
-	unsigned long __flags;						\
-	u64 __res;							\
-									\
-	local_irq_save(__flags);					\
-	__res = ____raw_readq(addr);					\
-	local_irq_restore(__flags);					\
-	__res;								\
-})
-#endif
-#ifdef CONFIG_MIPS64
-#define ____raw_readq(addr)						\
-	(*(volatile unsigned long *)__swizzle_addr_q((unsigned long)(addr)))
-#define __raw_readq(addr)	____raw_readq(addr)
-#endif
 
-#define readb(addr)		__ioswab8(__raw_readb(addr))
-#define readw(addr)		__ioswab16(__raw_readw(addr))
-#define readl(addr)		__ioswab32(__raw_readl(addr))
-#define readq(addr)		__ioswab64(__raw_readq(addr))
-#define readb_relaxed(addr)	readb(addr)
-#define readw_relaxed(addr)	readw(addr)
-#define readl_relaxed(addr)	readl(addr)
-#define readq_relaxed(addr)	readq(addr)
-
-#define __raw_writeb(b,addr)						\
-do {									\
-	((*(volatile unsigned char *)__swizzle_addr_b((unsigned long)(addr))) = (b));	\
-} while (0)
-
-#define __raw_writew(w,addr)						\
-do {									\
-	((*(volatile unsigned short *)__swizzle_addr_w((unsigned long)(addr))) = (w));	\
-} while (0)
-
-#define __raw_writel(l,addr)						\
-do {									\
-	((*(volatile unsigned int *)__swizzle_addr_l((unsigned long)(addr))) = (l));	\
-} while (0)
-
-#ifdef CONFIG_MIPS32
-#define ____raw_writeq(val,addr)					\
-do {									\
-	u64 __tmp;							\
-									\
-	__asm__ __volatile__ (						\
-		"	.set	mips3				\n"	\
-		"	dsll32	%L0, %L0, 0	# ____raw_writeq\n"	\
-		"	dsrl32	%L0, %L0, 0			\n"	\
-		"	dsll32	%M0, %M0, 0			\n"	\
-		"	or	%L0, %L0, %M0			\n"	\
-		"	sd	%L0, (%2)			\n"	\
-		"	.set	mips0				\n"	\
-		: "=r" (__tmp)						\
-		: "0" ((unsigned long long)val),			\
-		  "r" (__swizzle_addr_q((unsigned long)(addr))));	\
-} while (0)
-
-#define __raw_writeq(val,addr)						\
-do {									\
-	unsigned long __flags;						\
-									\
-	local_irq_save(__flags);					\
-	____raw_writeq(val, addr);					\
-	local_irq_restore(__flags);					\
-} while (0)
-#endif
-#ifdef CONFIG_MIPS64
-#define ____raw_writeq(q,addr)						\
-do {									\
-	*(volatile unsigned long *)__swizzle_addr_q((unsigned long)(addr)) = (q);	\
-} while (0)
+#define __BUILD_MEMORY_SINGLE(pfx, bwlq, type, irq)			\
+									\
+static inline void pfx##write##bwlq(type val, void *mem)		\
+{									\
+	volatile type *__mem;						\
+	type __val;							\
+									\
+	__mem = (void *)__swizzle_addr_##bwlq((unsigned long)(mem));	\
+									\
+	__val = pfx##ioswab##bwlq(val);					\
+									\
+	if (sizeof(type) != sizeof(u64) || sizeof(u64) == sizeof(long))	\
+		*__mem = __val;						\
+	else if (cpu_has_64bits) {					\
+		unsigned long __flags;					\
+		type __tmp;						\
+									\
+		if (irq)						\
+			local_irq_save(__flags);			\
+		__asm__ __volatile__(					\
+			".set	mips3"		"\t\t# __writeq""\n\t"	\
+			"dsll32	%L0, %L0, 0"			"\n\t"	\
+			"dsrl32	%L0, %L0, 0"			"\n\t"	\
+			"dsll32	%M0, %M0, 0"			"\n\t"	\
+			"or	%L0, %L0, %M0"			"\n\t"	\
+			"sd	%L0, %2"			"\n\t"	\
+			".set	mips0"				"\n"	\
+			: "=r" (__tmp)					\
+			: "0" (__val), "m" (*__mem));			\
+		if (irq)						\
+			local_irq_restore(__flags);			\
+	} else								\
+		BUG();							\
+}									\
+									\
+static inline type pfx##read##bwlq(void *mem)				\
+{									\
+	volatile type *__mem;						\
+	type __val;							\
+									\
+	__mem = (void *)__swizzle_addr_##bwlq((unsigned long)(mem));	\
+									\
+	if (sizeof(type) != sizeof(u64) || sizeof(u64) == sizeof(long))	\
+		__val = *__mem;						\
+	else if (cpu_has_64bits) {					\
+		unsigned long __flags;					\
+									\
+		local_irq_save(__flags);				\
+		__asm__ __volatile__(					\
+			".set	mips3"		"\t\t# __readq"	"\n\t"	\
+			"ld	%L0, %1"			"\n\t"	\
+			"dsra32	%M0, %L0, 0"			"\n\t"	\
+			"sll	%L0, %L0, 0"			"\n\t"	\
+			".set	mips0"				"\n"	\
+			: "=r" (__val)					\
+			: "m" (*__mem));				\
+		local_irq_restore(__flags);				\
+	} else {							\
+		__val = 0;						\
+		BUG();							\
+	}								\
+									\
+	return pfx##ioswab##bwlq(__val);				\
+}
 
-#define __raw_writeq(q,addr)	____raw_writeq(q, addr)
-#endif
+#define __BUILD_IOPORT_SINGLE(pfx, bwlq, type, p, slow)			\
+									\
+static inline void pfx##out##bwlq##p(type val, unsigned long port)	\
+{									\
+	volatile type *__addr;						\
+	type __val;							\
+									\
+	port = __swizzle_addr_##bwlq(port);				\
+	__addr = (void *)(mips_io_port_base + port);			\
+									\
+	__val = pfx##ioswab##bwlq(val);					\
+									\
+	if (sizeof(type) != sizeof(u64)) {				\
+		*__addr = __val;					\
+		slow;							\
+	} else								\
+		BUILD_BUG();						\
+}									\
+									\
+static inline type pfx##in##bwlq##p(unsigned long port)			\
+{									\
+	volatile type *__addr;						\
+	type __val;							\
+									\
+	port = __swizzle_addr_##bwlq(port);				\
+	__addr = (void *)(mips_io_port_base + port);			\
+									\
+	if (sizeof(type) != sizeof(u64)) {				\
+		__val = *__addr;					\
+		slow;							\
+	} else {							\
+		__val = 0;						\
+		BUILD_BUG();						\
+	}								\
+									\
+	return pfx##ioswab##bwlq(__val);				\
+}
+
+#define __BUILD_MEMORY_PFX(bus, bwlq, type)				\
+									\
+__BUILD_MEMORY_SINGLE(bus, bwlq, type, 1)
+
+#define __BUILD_IOPORT_PFX(bus, bwlq, type)				\
+									\
+__BUILD_IOPORT_SINGLE(bus, bwlq, type, ,)				\
+__BUILD_IOPORT_SINGLE(bus, bwlq, type, _p, SLOW_DOWN_IO)
+
+#define BUILDIO(bwlq, type)						\
+									\
+__BUILD_MEMORY_PFX(, bwlq, type)					\
+__BUILD_MEMORY_PFX(__raw_, bwlq, type)					\
+__BUILD_MEMORY_PFX(bus_, bwlq, type)					\
+__BUILD_IOPORT_PFX(, bwlq, type)					\
+__BUILD_IOPORT_PFX(__raw_, bwlq, type)
+
+#define __BUILDIO(bwlq, type)						\
+									\
+__BUILD_MEMORY_SINGLE(__bus_, bwlq, type, 0)
+
+BUILDIO(b, u8)
+BUILDIO(w, u16)
+BUILDIO(l, u32)
+BUILDIO(q, u64)
+
+__BUILDIO(q, u64)
+
+#define readb_relaxed			readb
+#define readw_relaxed			readw
+#define readl_relaxed			readl
+#define readq_relaxed			readq
+
+
+#define __BUILD_MEMORY_STRING(bwlq, type)				\
+									\
+static inline void writes##bwlq(void *mem, void *addr,			\
+				unsigned int count)			\
+{									\
+	volatile type *__addr = addr;					\
+									\
+	while (count--) {						\
+		__raw_write##bwlq(*__addr, mem);			\
+		__addr++;						\
+	}								\
+}									\
+									\
+static inline void reads##bwlq(void *mem, void *addr,			\
+			       unsigned int count)			\
+{									\
+	volatile type *__addr = addr;					\
+									\
+	while (count--) {						\
+		*__addr = __raw_read##bwlq(mem);			\
+		__addr++;						\
+	}								\
+}
+
+#define __BUILD_IOPORT_STRING(bwlq, type)				\
+									\
+static inline void outs##bwlq(unsigned long port, void *addr,		\
+			      unsigned int count)			\
+{									\
+	volatile type *__addr = addr;					\
+									\
+	while (count--) {						\
+		__raw_out##bwlq(*__addr, port);				\
+		__addr++;						\
+	}								\
+}									\
+									\
+static inline void ins##bwlq(unsigned long port, void *addr,		\
+			     unsigned int count)			\
+{									\
+	volatile type *__addr = addr;					\
+									\
+	while (count--) {						\
+		*__addr = __raw_in##bwlq(port);				\
+		__addr++;						\
+	}								\
+}
+
+#define BUILDSTRING(bwlq, type)						\
+									\
+__BUILD_MEMORY_STRING(bwlq, type)					\
+__BUILD_IOPORT_STRING(bwlq, type)
+
+BUILDSTRING(b, u8)
+BUILDSTRING(w, u16)
+BUILDSTRING(l, u32)
+BUILDSTRING(q, u64)
 
-#define writeb(b,addr)		__raw_writeb(__ioswab8(b),(addr))
-#define writew(w,addr)		__raw_writew(__ioswab16(w),(addr))
-#define writel(l,addr)		__raw_writel(__ioswab32(l),(addr))
-#define writeq(q,addr)		__raw_writeq(__ioswab64(q),(addr))
 
 /* Depends on MIPS II instruction set */
 #define mmiowb() asm volatile ("sync" ::: "memory")
@@ -394,7 +511,7 @@ do {									\
  *     address should have been obtained by ioremap.
  *     Returns 1 on a match.
  */
-static inline int check_signature(unsigned long io_addr,
+static inline int check_signature(char __iomem *io_addr,
 	const unsigned char *signature, int length)
 {
 	int retval = 0;
@@ -424,177 +541,6 @@ out:
  */
 #define isa_check_signature(io, s, l)	check_signature(i,s,l)
 
-static inline void __outb(unsigned char val, unsigned long port)
-{
-	port = __swizzle_addr_b(port);
-
-	*(volatile u8 *)(mips_io_port_base + port) = __ioswab8(val);
-}
-
-static inline void __outw(unsigned short val, unsigned long port)
-{
-	port = __swizzle_addr_w(port);
-
-	*(volatile u16 *)(mips_io_port_base + port) = __ioswab16(val);
-}
-
-static inline void __outl(unsigned int val, unsigned long port)
-{
-	port = __swizzle_addr_l(port);
-
-	*(volatile u32 *)(mips_io_port_base + port) = __ioswab32(val);
-}
-
-static inline void __outb_p(unsigned char val, unsigned long port)
-{
-	port = __swizzle_addr_b(port);
-
-	*(volatile u8 *)(mips_io_port_base + port) = __ioswab8(val);
-	SLOW_DOWN_IO;
-}
-
-static inline void __outw_p(unsigned short val, unsigned long port)
-{
-	port = __swizzle_addr_w(port);
-
-	*(volatile u16 *)(mips_io_port_base + port) = __ioswab16(val);
-	SLOW_DOWN_IO;
-}
-
-static inline void __outl_p(unsigned int val, unsigned long port)
-{
-	port = __swizzle_addr_l(port);
-
-	*(volatile u32 *)(mips_io_port_base + port) = __ioswab32(val);
-	SLOW_DOWN_IO;
-}
-
-#define outb(val, port)		__outb(val, port)
-#define outw(val, port)		__outw(val, port)
-#define outl(val, port)		__outl(val, port)
-#define outb_p(val, port)	__outb_p(val, port)
-#define outw_p(val, port)	__outw_p(val, port)
-#define outl_p(val, port)	__outl_p(val, port)
-
-static inline unsigned char __inb(unsigned long port)
-{
-	port = __swizzle_addr_b(port);
-
-	return __ioswab8(*(volatile u8 *)(mips_io_port_base + port));
-}
-
-static inline unsigned short __inw(unsigned long port)
-{
-	port = __swizzle_addr_w(port);
-
-	return __ioswab16(*(volatile u16 *)(mips_io_port_base + port));
-}
-
-static inline unsigned int __inl(unsigned long port)
-{
-	port = __swizzle_addr_l(port);
-
-	return __ioswab32(*(volatile u32 *)(mips_io_port_base + port));
-}
-
-static inline unsigned char __inb_p(unsigned long port)
-{
-	u8 __val;
-
-	port = __swizzle_addr_b(port);
-
-	__val = *(volatile u8 *)(mips_io_port_base + port);
-	SLOW_DOWN_IO;
-
-	return __ioswab8(__val);
-}
-
-static inline unsigned short __inw_p(unsigned long port)
-{
-	u16 __val;
-
-	port = __swizzle_addr_w(port);
-
-	__val = *(volatile u16 *)(mips_io_port_base + port);
-	SLOW_DOWN_IO;
-
-	return __ioswab16(__val);
-}
-
-static inline unsigned int __inl_p(unsigned long port)
-{
-	u32 __val;
-
-	port = __swizzle_addr_l(port);
-
-	__val = *(volatile u32 *)(mips_io_port_base + port);
-	SLOW_DOWN_IO;
-
-	return __ioswab32(__val);
-}
-
-#define inb(port)	__inb(port)
-#define inw(port)	__inw(port)
-#define inl(port)	__inl(port)
-#define inb_p(port)	__inb_p(port)
-#define inw_p(port)	__inw_p(port)
-#define inl_p(port)	__inl_p(port)
-
-static inline void __outsb(unsigned long port, void *addr, unsigned int count)
-{
-	while (count--) {
-		outb(*(u8 *)addr, port);
-		addr++;
-	}
-}
-
-static inline void __insb(unsigned long port, void *addr, unsigned int count)
-{
-	while (count--) {
-		*(u8 *)addr = inb(port);
-		addr++;
-	}
-}
-
-static inline void __outsw(unsigned long port, void *addr, unsigned int count)
-{
-	while (count--) {
-		outw(*(u16 *)addr, port);
-		addr += 2;
-	}
-}
-
-static inline void __insw(unsigned long port, void *addr, unsigned int count)
-{
-	while (count--) {
-		*(u16 *)addr = inw(port);
-		addr += 2;
-	}
-}
-
-static inline void __outsl(unsigned long port, void *addr, unsigned int count)
-{
-	while (count--) {
-		outl(*(u32 *)addr, port);
-		addr += 4;
-	}
-}
-
-static inline void __insl(unsigned long port, void *addr, unsigned int count)
-{
-	while (count--) {
-		*(u32 *)addr = inl(port);
-		addr += 4;
-	}
-}
-
-#define outsb(port, addr, count)	__outsb(port, addr, count)
-#define insb(port, addr, count)		__insb(port, addr, count)
-#define outsw(port, addr, count)	__outsw(port, addr, count)
-#define insw(port, addr, count)		__insw(port, addr, count)
-#define outsl(port, addr, count)	__outsl(port, addr, count)
-#define insl(port, addr, count)		__insl(port, addr, count)
-
 /*
  * The caches on some architectures aren't dma-coherent and have need to
  * handle this in software.  There are three types of operations that
diff -up --recursive --new-file linux-mips-2.6.10-rc2-20041124.macro/include/asm-mips/mach-generic/ide.h linux-mips-2.6.10-rc2-20041124/include/asm-mips/mach-generic/ide.h
--- linux-mips-2.6.10-rc2-20041124.macro/include/asm-mips/mach-generic/ide.h	2004-11-24 21:37:52.000000000 +0000
+++ linux-mips-2.6.10-rc2-20041124/include/asm-mips/mach-generic/ide.h	2004-12-14 17:25:36.000000000 +0000
@@ -64,7 +64,17 @@ static __inline__ unsigned long ide_defa
 #define ide_init_default_irq(base)	ide_default_irq(base)
 #endif
 
-#include <asm-generic/ide_iops.h>
+/* MIPS port and memory-mapped I/O string operations.  */
+
+#define __ide_insw	insw
+#define __ide_insl	insl
+#define __ide_outsw	outsw
+#define __ide_outsl	outsl
+
+#define __ide_mm_insw	readsw
+#define __ide_mm_insl	readsl
+#define __ide_mm_outsw	writesw
+#define __ide_mm_outsl	writesl
 
 #endif /* __KERNEL__ */
 

From mlachwani@prometheus.mvista.com Wed Dec 15 23:56:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Dec 2004 23:57:00 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:25587 "EHLO
	prometheus.mvista.com") by linux-mips.org with ESMTP
	id <S8225311AbULOX4q>; Wed, 15 Dec 2004 23:56:46 +0000
Received: from prometheus.mvista.com (localhost.localdomain [127.0.0.1])
	by prometheus.mvista.com (8.12.8/8.12.8) with ESMTP id iBFNuXdh012392;
	Wed, 15 Dec 2004 15:56:33 -0800
Received: (from mlachwani@localhost)
	by prometheus.mvista.com (8.12.8/8.12.8/Submit) id iBFNuWju012380;
	Wed, 15 Dec 2004 15:56:32 -0800
Date: Wed, 15 Dec 2004 15:56:32 -0800
From: Manish Lachwani <mlachwani@mvista.com>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org, mlachwani@mvista.com
Subject: [PATCH] Avoid compile warnings on Sibyte using 2.6.10-rc3
Message-ID: <20041215235632.GA11386@prometheus.mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY"
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <mlachwani@prometheus.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: 6684
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips


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

Hi Ralf,

The attached patch is needed to prevent the compilation warnings that
occur when using 2.6.10-rc3 on Sibyte. Please review 

Thanks
Manish Lachwani


--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline; filename=patch-2610rc3-sibyte

--- include/asm-mips/cpu-features.h.orig	2004-12-15 11:18:23.000000000 -0800
+++ include/asm-mips/cpu-features.h	2004-12-15 11:18:43.000000000 -0800
@@ -92,8 +92,10 @@
 #define cpu_icache_snoops_remote_store	(cpu_data[0].icache.flags & MIPS_IC_SNOOPS_REMOTE)
 #endif
 #else
+#ifndef cpu_icache_snoops_remote_store
 #define cpu_icache_snoops_remote_store	1
 #endif
+#endif
 
 /*
  * Certain CPUs may throw bizarre exceptions if not the whole cacheline

--OXfL5xGRrasGEqWY--

From anemo@mba.ocn.ne.jp Thu Dec 16 02:18:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 02:18:08 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:59938
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225321AbULPCSC>; Thu, 16 Dec 2004 02:18:02 +0000
Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 16 Dec 2004 02:18:00 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by newms.toshiba-tops.co.jp (Postfix) with ESMTP
	id D19D9239E3C; Thu, 16 Dec 2004 11:17:46 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id iBG2HkdD009839;
	Thu, 16 Dec 2004 11:17:46 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 16 Dec 2004 11:17:46 +0900 (JST)
Message-Id: <20041216.111746.25908722.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org
Cc: macro@linux-mips.org, wlacey@goldenhindresearch.com,
	linux-mips@linux-mips.org
Subject: Re: No PCI_AUTO in 2.6...
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20041215184213.GB32491@linux-mips.org>
References: <20041215164036.GC30130@linux-mips.org>
	<Pine.LNX.4.58L.0412151648460.2706@blysk.ds.pg.gda.pl>
	<20041215184213.GB32491@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6685
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Wed, 15 Dec 2004 19:42:13 +0100, Ralf Baechle <ralf@linux-mips.org> said:
>> I know and I consider it a bug.  The correct way would be setting
>> the start at 0 and if avoiding the first kB of space was necessary,
>> setting PCIBIOS_MIN_IO to 0x1000.

ralf> PCIBIOS_MIN_IO is the same value for all busses.  That can turn
ralf> out a bit kludgy so I'm not much of a friend of it.

BTW, yenta_socket driver uses PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM, so
these variables should be exported?

--- linux-mips/arch/mips/pci/pci.c	2004-12-13 09:39:09.000000000 +0900
+++ linux/arch/mips/pci/pci.c	2004-12-13 10:02:32.000000000 +0900
@@ -294,6 +294,8 @@
 
 #ifdef CONFIG_HOTPLUG
 EXPORT_SYMBOL(pcibios_resource_to_bus);
+EXPORT_SYMBOL(PCIBIOS_MIN_IO);
+EXPORT_SYMBOL(PCIBIOS_MIN_MEM);
 #endif
 
 char *pcibios_setup(char *str)

---
Atsushi Nemoto

From koseki@shimafuji.co.jp Thu Dec 16 02:52:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 02:52:31 +0000 (GMT)
Received: from s306.secure.ne.jp ([IPv6:::ffff:211.9.215.133]:57097 "HELO
	s306.secure.ne.jp") by linux-mips.org with SMTP id <S8225321AbULPCwZ>;
	Thu, 16 Dec 2004 02:52:25 +0000
Received: (qmail 31622 invoked from network); 16 Dec 2004 11:52:04 +0900
Received: from unknown (HELO koseki) (163.139.182.183)
  by 0 with SMTP; 16 Dec 2004 11:52:04 +0900
Message-ID: <006201c4e31a$79171ff0$2100a8c0@koseki>
From: "Tatsuya Koseki" <koseki@shimafuji.co.jp>
To: "Ralf Baechle" <ralf@linux-mips.org>,
	"Linux MIPS mailing list" <linux-mips@linux-mips.org>
References: <009001c4e1ba$54a431f0$2100a8c0@koseki> <20041215131753.GC27935@linux-mips.org>
Subject: Re: kernel 2.6.9 patch
Date: Thu, 16 Dec 2004 11:53:41 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <koseki@shimafuji.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: 6686
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: koseki@shimafuji.co.jp
Precedence: bulk
X-list: linux-mips

I find this message,
  http://www.linux-mips.org/archives/linux-mips/2004-10/msg00256.html

Thank you  for reply.


> On Tue, Dec 14, 2004 at 05:53:02PM +0900, Tatsuya Koseki wrote:
> 
> > Subject: kernel 2.6.9 patch
> > Date: Tue, 14 Dec 2004 17:53:02 +0900
> > Content-Type: text/plain;
> > charset="iso-2022-jp"
> > 
> > Please review 
> > 
> > 
> > --- linux/include/asm/stackframe.h.old Tue Dec 14 17:49:38 2004
> > +++ linux/include/asm/stackframe.h Tue Dec 14 17:50:35 2004
> > @@ -244,6 +244,10 @@
> >    nor v1, $0, v1
> >    and v0, v1
> >    or v0, a0
> > +
> > +  li v1,2
> > +  or v0,v1
> > +
> >    mtc0 v0, CP0_STATUS
> >    LONG_L v1, PT_EPC(sp)
> >    MTC0 v1, CP0_EPC
> 
>  o Your patch got corrupted by using a differnet indentation so couldn't be
>    applied anyway
>  o When posting a patch, post an explanation.  If the purpose of a patch
>    isn't obvious it'll likely be ignroed.
>  o This bug was already fixed in CVS.
>  o The issue only affected new-born processes, so there is no reason to
>    burden the fix on every exception taken.
>  o Why using two instruction if one would be sufficient.
> 
>   Ralf
> 



From sjhill@realitydiluted.com Thu Dec 16 03:07:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 03:07:26 +0000 (GMT)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:5790 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225361AbULPDHU>; Thu, 16 Dec 2004 03:07:20 +0000
Received: from localhost ([127.0.0.1])
	by real.realitydiluted.com with esmtp (Exim 4.34 #1 (Debian))
	id 1Celyv-000487-KD; Wed, 15 Dec 2004 21:07:09 -0600
Message-ID: <41C0FCFD.9010603@realitydiluted.com>
Date: Wed, 15 Dec 2004 21:11:57 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5
X-Accept-Language: en
MIME-Version: 1.0
To: Manish Lachwani <mlachwani@mvista.com>
CC: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: [PATCH] Avoid compile warnings on Sibyte using 2.6.10-rc3
References: <20041215235632.GA11386@prometheus.mvista.com>
In-Reply-To: <20041215235632.GA11386@prometheus.mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6687
X-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

Manish Lachwani wrote:
> 
> The attached patch is needed to prevent the compilation warnings that
> occur when using 2.6.10-rc3 on Sibyte. Please review 
> 
I don't ever see any warning associated with this. Can you provide a
little more information?

-Steve

From sjhill@realitydiluted.com Thu Dec 16 03:09:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 03:09:09 +0000 (GMT)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:7326 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225361AbULPDJE>; Thu, 16 Dec 2004 03:09:04 +0000
Received: from localhost ([127.0.0.1])
	by real.realitydiluted.com with esmtp (Exim 4.34 #1 (Debian))
	id 1Cem0b-00048C-BQ; Wed, 15 Dec 2004 21:08:53 -0600
Message-ID: <41C0FD66.6060206@realitydiluted.com>
Date: Wed, 15 Dec 2004 21:13:42 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
References: <20041216030425Z8225321-1751+3720@linux-mips.org>
In-Reply-To: <20041216030425Z8225321-1751+3720@linux-mips.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: 6688
X-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

sjhill@linux-mips.org wrote:
> 
> Log message:
> 	Remove obsolete MAX1617 driver code. The 'adm1021' driver handles both
> 	the 1617 and 1617a with a minor modification. This chip now works properly
> 	on SiByte Swarm boards.

Ralf,

A lot of the I2C code, specifically the headers files in 'include/linux' need
to be pushed back to the I2C maintainers. Would you like me to make the patches
and do that, or do you have time?

-Steve

From mlachwani@mvista.com Thu Dec 16 03:28:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 03:28:28 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:12537 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225321AbULPD2Y>; Thu, 16 Dec 2004 03:28:24 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id 42EBF1877B; Wed, 15 Dec 2004 19:28:12 -0800 (PST)
Message-ID: <41C100CB.2070000@mvista.com>
Date: Wed, 15 Dec 2004 19:28:11 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: [PATCH] Avoid compile warnings on Sibyte using 2.6.10-rc3
References: <20041215235632.GA11386@prometheus.mvista.com> <41C0FCFD.9010603@realitydiluted.com>
In-Reply-To: <41C0FCFD.9010603@realitydiluted.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6689
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

Steven J. Hill wrote:

> Manish Lachwani wrote:
>
>>
>> The attached patch is needed to prevent the compilation warnings that
>> occur when using 2.6.10-rc3 on Sibyte. Please review
>
> I don't ever see any warning associated with this. Can you provide a
> little more information?
>
> -Steve
>
Hi Steve,

When did you last sync with CVS?  There was a change introduced : 
http://www.linux-mips.org/cvsweb/linux/include/asm-mips/mach-sibyte/cpu-feature-overrides.h.diff?r1=1.1&r2=1.2

There is another #define in include/asm-mips/

#ifdef CONFIG_SMP
#ifndef cpu_icache_snoops_remote_store
#define cpu_icache_snoops_remote_store  (cpu_data[0].icache.flags & 
MIPS_IC_SNOOPS_REMOTE)
#endif
#else
#define cpu_icache_snoops_remote_store  1
#endif

And if running Sibyte in UP mode, cpu_icache_snoops_remote_store is 
redefined

Thanks
Manish



From sjhill@realitydiluted.com Thu Dec 16 03:44:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 03:44:42 +0000 (GMT)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:17054 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225321AbULPDoh>; Thu, 16 Dec 2004 03:44:37 +0000
Received: from localhost ([127.0.0.1])
	by real.realitydiluted.com with esmtp (Exim 4.34 #1 (Debian))
	id 1CemZ0-00049T-3g; Wed, 15 Dec 2004 21:44:26 -0600
Message-ID: <41C105BB.9020402@realitydiluted.com>
Date: Wed, 15 Dec 2004 21:49:15 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5
X-Accept-Language: en
MIME-Version: 1.0
To: Manish Lachwani <mlachwani@mvista.com>
CC: linux-mips@linux-mips.org
Subject: Re: [PATCH] Avoid compile warnings on Sibyte using 2.6.10-rc3
References: <20041215235632.GA11386@prometheus.mvista.com> <41C0FCFD.9010603@realitydiluted.com> <41C100CB.2070000@mvista.com>
In-Reply-To: <41C100CB.2070000@mvista.com>
Content-Type: multipart/mixed;
 boundary="------------050304050001060503050205"
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: 6690
X-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

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

Manish Lachwani wrote:
> 
> When did you last sync with CVS?  There was a change introduced : 
>
Literally 10 minutes ago and I did a fresh compile.

> And if running Sibyte in UP mode, cpu_icache_snoops_remote_store is 
> redefined
> 
I do not run in UP mode, so that is why I did not see it. I suggest
a different version attached. How does that work for you?

-Steve


--------------050304050001060503050205
Content-Type: text/x-patch;
 name="cpu-feature-warn.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="cpu-feature-warn.patch"

Index: cpu-features.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/cpu-features.h,v
retrieving revision 1.9
diff -u -r1.9 cpu-features.h
--- cpu-features.h	7 Dec 2004 02:08:34 -0000	1.9
+++ cpu-features.h	16 Dec 2004 03:42:03 -0000
@@ -87,13 +87,13 @@
  * that did the store so we can't optimize this into only doing the flush on
  * the local CPU.
  */
-#ifdef CONFIG_SMP
 #ifndef cpu_icache_snoops_remote_store
+#ifdef CONFIG_SMP
 #define cpu_icache_snoops_remote_store	(cpu_data[0].icache.flags & MIPS_IC_SNOOPS_REMOTE)
-#endif
 #else
 #define cpu_icache_snoops_remote_store	1
 #endif
+#endif
 
 /*
  * Certain CPUs may throw bizarre exceptions if not the whole cacheline

--------------050304050001060503050205--

From mlachwani@mvista.com Thu Dec 16 03:50:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 03:50:15 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:61689 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225321AbULPDuJ>; Thu, 16 Dec 2004 03:50:09 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id 321ED1874C; Wed, 15 Dec 2004 19:49:58 -0800 (PST)
Message-ID: <41C105E5.4040006@mvista.com>
Date: Wed, 15 Dec 2004 19:49:57 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Avoid compile warnings on Sibyte using 2.6.10-rc3
References: <20041215235632.GA11386@prometheus.mvista.com> <41C0FCFD.9010603@realitydiluted.com> <41C100CB.2070000@mvista.com> <41C105BB.9020402@realitydiluted.com>
In-Reply-To: <41C105BB.9020402@realitydiluted.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6691
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

Steven J. Hill wrote:

> Manish Lachwani wrote:
>
>>
>> When did you last sync with CVS?  There was a change introduced :
>
> Literally 10 minutes ago and I did a fresh compile.
>
>> And if running Sibyte in UP mode, cpu_icache_snoops_remote_store is 
>> redefined
>>
> I do not run in UP mode, so that is why I did not see it. I suggest
> a different version attached. How does that work for you?
>
> -Steve
>
>------------------------------------------------------------------------
>
>Index: cpu-features.h
>===================================================================
>RCS file: /home/cvs/linux/include/asm-mips/cpu-features.h,v
>retrieving revision 1.9
>diff -u -r1.9 cpu-features.h
>--- cpu-features.h	7 Dec 2004 02:08:34 -0000	1.9
>+++ cpu-features.h	16 Dec 2004 03:42:03 -0000
>@@ -87,13 +87,13 @@
>  * that did the store so we can't optimize this into only doing the flush on
>  * the local CPU.
>  */
>-#ifdef CONFIG_SMP
> #ifndef cpu_icache_snoops_remote_store
>+#ifdef CONFIG_SMP
> #define cpu_icache_snoops_remote_store	(cpu_data[0].icache.flags & MIPS_IC_SNOOPS_REMOTE)
>-#endif
> #else
> #define cpu_icache_snoops_remote_store	1
> #endif
>+#endif
> 
> /*
>  * Certain CPUs may throw bizarre exceptions if not the whole cacheline
>  
>
Looks good to me

Thanks
Manish Lachwani



From macro@linux-mips.org Thu Dec 16 03:52:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 03:52:58 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:58889 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225395AbULPDwx>; Thu, 16 Dec 2004 03:52:53 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id D2506F5995; Thu, 16 Dec 2004 04:52:41 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 14318-08; Thu, 16 Dec 2004 04:52:41 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 96013F5994; Thu, 16 Dec 2004 04:52:41 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iBG3qf9X014509;
	Thu, 16 Dec 2004 04:52:41 +0100
Date: Thu, 16 Dec 2004 03:52:40 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: sjhill@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20041216030425Z8225321-1751+3720@linux-mips.org>
Message-ID: <Pine.LNX.4.58L.0412160345400.26904@blysk.ds.pg.gda.pl>
References: <20041216030425Z8225321-1751+3720@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/617/Sun Dec  5 16:25:39 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6692
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, 16 Dec 2004 sjhill@linux-mips.org wrote:

> Modified files:
> 	drivers/i2c    : Kconfig 
> 	drivers/i2c/chips: adm1021.c 
> Removed files:
> 	drivers/i2c    : i2c-max1617.c 
> 
> Log message:
> 	Remove obsolete MAX1617 driver code. The 'adm1021' driver handles both
> 	the 1617 and 1617a with a minor modification. This chip now works properly
> 	on SiByte Swarm boards.

 The removal is welcome, but the change to adm1021.c is broken.  You
should set I2C_CLASS_HWMON for the SiByte I2C adapter instead.  Please fix
your commit.  Thanks.

  Maciej

From mlachwani@mvista.com Thu Dec 16 03:54:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 03:54:39 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:29686 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225321AbULPDyf>; Thu, 16 Dec 2004 03:54:35 +0000
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id D1E5818772; Wed, 15 Dec 2004 19:54:23 -0800 (PST)
Message-ID: <41C106EF.9080000@mvista.com>
Date: Wed, 15 Dec 2004 19:54:23 -0800
From: Manish Lachwani <mlachwani@mvista.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Avoid compile warnings on Sibyte using 2.6.10-rc3
References: <20041215235632.GA11386@prometheus.mvista.com> <41C0FCFD.9010603@realitydiluted.com> <41C100CB.2070000@mvista.com> <41C105BB.9020402@realitydiluted.com>
In-Reply-To: <41C105BB.9020402@realitydiluted.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mlachwani@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: 6693
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlachwani@mvista.com
Precedence: bulk
X-list: linux-mips

On a side note, I think this problem will appear on other arches as well 
when running in UP mode.

Thanks
Manish Lachwani


Steven J. Hill wrote:

> Manish Lachwani wrote:
>
>>
>> When did you last sync with CVS?  There was a change introduced :
>
> Literally 10 minutes ago and I did a fresh compile.
>
>> And if running Sibyte in UP mode, cpu_icache_snoops_remote_store is 
>> redefined
>>
> I do not run in UP mode, so that is why I did not see it. I suggest
> a different version attached. How does that work for you?
>
> -Steve
>
>------------------------------------------------------------------------
>
>Index: cpu-features.h
>===================================================================
>RCS file: /home/cvs/linux/include/asm-mips/cpu-features.h,v
>retrieving revision 1.9
>diff -u -r1.9 cpu-features.h
>--- cpu-features.h	7 Dec 2004 02:08:34 -0000	1.9
>+++ cpu-features.h	16 Dec 2004 03:42:03 -0000
>@@ -87,13 +87,13 @@
>  * that did the store so we can't optimize this into only doing the flush on
>  * the local CPU.
>  */
>-#ifdef CONFIG_SMP
> #ifndef cpu_icache_snoops_remote_store
>+#ifdef CONFIG_SMP
> #define cpu_icache_snoops_remote_store	(cpu_data[0].icache.flags & MIPS_IC_SNOOPS_REMOTE)
>-#endif
> #else
> #define cpu_icache_snoops_remote_store	1
> #endif
>+#endif
> 
> /*
>  * Certain CPUs may throw bizarre exceptions if not the whole cacheline
>  
>



From macro@linux-mips.org Thu Dec 16 03:57:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 03:58:11 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:32267 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225321AbULPD56>; Thu, 16 Dec 2004 03:57:58 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 25F18F5995; Thu, 16 Dec 2004 04:57:47 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 29221-03; Thu, 16 Dec 2004 04:57:47 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id CF755F5994; Thu, 16 Dec 2004 04:57:46 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iBG3vkLU014618;
	Thu, 16 Dec 2004 04:57:47 +0100
Date: Thu, 16 Dec 2004 03:57:45 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: Manish Lachwani <mlachwani@mvista.com>, linux-mips@linux-mips.org
Subject: Re: [PATCH] Avoid compile warnings on Sibyte using 2.6.10-rc3
In-Reply-To: <41C105BB.9020402@realitydiluted.com>
Message-ID: <Pine.LNX.4.58L.0412160354190.26904@blysk.ds.pg.gda.pl>
References: <20041215235632.GA11386@prometheus.mvista.com>
 <41C0FCFD.9010603@realitydiluted.com> <41C100CB.2070000@mvista.com>
 <41C105BB.9020402@realitydiluted.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/617/Sun Dec  5 16:25:39 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6694
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, 15 Dec 2004, Steven J. Hill wrote:

> I do not run in UP mode, so that is why I did not see it. I suggest
> a different version attached. How does that work for you?

 This begs for indentation. ;-)

  Maciej

From zhanrk@gmail.com Thu Dec 16 08:06:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 08:06:29 +0000 (GMT)
Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.192]:43950 "EHLO
	rproxy.gmail.com") by linux-mips.org with ESMTP id <S8224990AbULPIGY>;
	Thu, 16 Dec 2004 08:06:24 +0000
Received: by rproxy.gmail.com with SMTP id j1so1068074rnf
        for <linux-mips@linux-mips.org>; Thu, 16 Dec 2004 00:06:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding;
        b=UNtRTampy3MNEU+xRTOCvQalhhgsNjPE/8UlO3N49FALIq5WyQHoHOXuuEt6MxoKK8yy7c+vY6t5yo/1Ej1pplSg6XF7wk3BpHh5+YAWLdcF69V7wqtAdFDWH1D8nW8zxYImgRHoUJjypCeqMD6lx/BawcGSKmCq7cr5j1ov16c=
Received: by 10.38.89.5 with SMTP id m5mr2239930rnb;
        Thu, 16 Dec 2004 00:06:12 -0800 (PST)
Received: by 10.38.66.71 with HTTP; Thu, 16 Dec 2004 00:06:12 -0800 (PST)
Message-ID: <73e6204504121600066a2ce0b1@mail.gmail.com>
Date: Thu, 16 Dec 2004 16:06:12 +0800
From: zhan rongkai <zhanrk@gmail.com>
Reply-To: zhan rongkai <zhanrk@gmail.com>
To: linux-mips@linux-mips.org
Subject: About task->used_math and TIF_USEDFPU
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <zhanrk@gmail.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: 6695
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zhanrk@gmail.com
Precedence: bulk
X-list: linux-mips

hi all,

I am a little confused about the task_struct member 'used_math', and
thread_info flag TIF_USEDFPU.

What are their meaning, and what is the difference between them?

thanks.

From anemo@mba.ocn.ne.jp Thu Dec 16 11:06:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 11:06:20 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:49167
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224990AbULPLGL>; Thu, 16 Dec 2004 11:06:11 +0000
Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 16 Dec 2004 11:06:09 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by newms.toshiba-tops.co.jp (Postfix) with ESMTP
	id 2333F239E3B; Thu, 16 Dec 2004 19:38:00 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id iBGAbxdD011927;
	Thu, 16 Dec 2004 19:37:59 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 16 Dec 2004 19:37:58 +0900 (JST)
Message-Id: <20041216.193758.130241219.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
Subject: minor asm-mips/sigcontext.h fix
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6696
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

The asm-mips/sigcontext.h uses '#ifdef __KERNEL__' to not export
sigcontext32 to userland.  It includes linux/types.h but it is needed
just for sigcontext32, so it would be better to hide from userland
too.

Here is a patch.  Could you apply?

--- linux-mips/include/asm-mips/sigcontext.h	2004-08-14 19:56:24.000000000 +0900
+++ linux/include/asm-mips/sigcontext.h	2004-12-16 19:02:43.922237317 +0900
@@ -41,8 +41,6 @@
                                                                                 
 #if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32
 
-#include <linux/types.h>
-
 /*
  * Keep this struct definition in sync with the sigcontext fragment
  * in arch/mips/tools/offset.c
@@ -66,6 +64,8 @@
 };
 
 #ifdef __KERNEL__
+#include <linux/types.h>
+
 struct sigcontext32 {
 	__u32	sc_regmask;		/* Unused */
 	__u32	sc_status;

---
Atsushi Nemoto

From ralf@linux-mips.org Thu Dec 16 12:56:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 12:56:38 +0000 (GMT)
Received: from p3EE2BA30.dip.t-dialin.net ([IPv6:::ffff:62.226.186.48]:40743
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225228AbULPM4e>; Thu, 16 Dec 2004 12:56:34 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBGCuJPD013401;
	Thu, 16 Dec 2004 13:56:19 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBGCuElS013385;
	Thu, 16 Dec 2004 13:56:14 +0100
Date: Thu, 16 Dec 2004 13:56:14 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: macro@linux-mips.org, wlacey@goldenhindresearch.com,
	linux-mips@linux-mips.org
Subject: Re: No PCI_AUTO in 2.6...
Message-ID: <20041216125614.GA13355@linux-mips.org>
References: <20041215164036.GC30130@linux-mips.org> <Pine.LNX.4.58L.0412151648460.2706@blysk.ds.pg.gda.pl> <20041215184213.GB32491@linux-mips.org> <20041216.111746.25908722.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041216.111746.25908722.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6697
X-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, Dec 16, 2004 at 11:17:46AM +0900, Atsushi Nemoto wrote:

> BTW, yenta_socket driver uses PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM, so
> these variables should be exported?

Yes.

  Ralf

From ralf@linux-mips.org Thu Dec 16 13:22:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 13:22:04 +0000 (GMT)
Received: from p3EE2BA30.dip.t-dialin.net ([IPv6:::ffff:62.226.186.48]:57895
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225228AbULPNWA>; Thu, 16 Dec 2004 13:22:00 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBGDLnPr013820;
	Thu, 16 Dec 2004 14:21:49 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBGDLneU013819;
	Thu, 16 Dec 2004 14:21:49 +0100
Date: Thu, 16 Dec 2004 14:21:49 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: minor asm-mips/sigcontext.h fix
Message-ID: <20041216132149.GA13753@linux-mips.org>
References: <20041216.193758.130241219.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041216.193758.130241219.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6698
X-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, Dec 16, 2004 at 07:37:58PM +0900, Atsushi Nemoto wrote:

> The asm-mips/sigcontext.h uses '#ifdef __KERNEL__' to not export
> sigcontext32 to userland.  It includes linux/types.h but it is needed
> just for sigcontext32, so it would be better to hide from userland
> too.
> 
> Here is a patch.  Could you apply?

Applied but changed to include <linux/posix_types.h> only.

  Ralf

From francis_moreau2000@yahoo.fr Thu Dec 16 15:05:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 15:05:57 +0000 (GMT)
Received: from web25102.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.50]:602
	"HELO web25102.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8225225AbULPPFx>; Thu, 16 Dec 2004 15:05:53 +0000
Received: (qmail 83371 invoked by uid 60001); 16 Dec 2004 15:05:36 -0000
Message-ID: <20041216150536.83369.qmail@web25102.mail.ukl.yahoo.com>
Received: from [80.14.198.143] by web25102.mail.ukl.yahoo.com via HTTP; Thu, 16 Dec 2004 16:05:36 CET
Date: Thu, 16 Dec 2004 16:05:36 +0100 (CET)
From: moreau francis <francis_moreau2000@yahoo.fr>
Subject: Re: Kernel located in KSEG2 or KSEG3.
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20041215133851.GD27935@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6699
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips

> It's not.  The 4kc processor when running with the
> BEV bit in the status
> register cleared will try to find it's exception
> vectors at address
> KSEG0, so there would have to be *some* code mapped
> there.  With BEV=1
> exception vectors would be located in the firmware
> as pointed out by
> Steve in his answer.  Firmware means something like
> flashmemory and running
> uncached, so will be prohibitivly slow.  I just
> can't believe a system to
> be that missdesigned!

Well actually I have memories that can be accessed by
KSEG0, but they are very limited:

start        size      type
----------------------------
0x00000000 - 128Ko    - RAM
0x01000000 - 128Ko    - FLASH
0x1fc00000 - 128Ko    - ROM

Therefore I could use this internal RAM to store
exception vectors.

My fears are on running kernel in KSEG2.

I'm thinking of trying this configuration:

I'm going to use 2 TLB entries to map definetively
kernel in KSEG1:
    * 1 entry to map kernel code in FLASH (16Mo), 
    * 1 entry to map kernel data in SDRAM (8Mo).

space    virtual-add    physical-add    size
----------------------------------------------
Code     0xC0000000     0x30000000      16Mo
Data     0xC1000000     0x20000000       8Mo

I will set PAGE_OFFSET to 0xA1000000, therefore all
physicall address convertion will result in SDRAM.
Hopefully, this macro is only used to make translation
between physical and virtual spaces. I grep it and it
seems to be the case.

Do you think that I can dig at this way ?

Thanks,

   Francis



	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

From jsun@junsun.net Thu Dec 16 17:33:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Dec 2004 17:33:32 +0000 (GMT)
Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:47592 "EHLO
	sccrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225225AbULPRd1>; Thu, 16 Dec 2004 17:33:27 +0000
Received: from gw.junsun.net (c-24-6-106-170.client.comcast.net[24.6.106.170])
          by comcast.net (sccrmhc12) with ESMTP
          id <2004121617330801200iipqre>; Thu, 16 Dec 2004 17:33:08 +0000
Received: from gw.junsun.net (gw.junsun.net [127.0.0.1])
	by gw.junsun.net (8.13.1/8.13.1) with ESMTP id iBGHX6Gd003262;
	Thu, 16 Dec 2004 09:33:07 -0800
Received: (from jsun@localhost)
	by gw.junsun.net (8.13.1/8.13.1/Submit) id iBGHX6fV003261;
	Thu, 16 Dec 2004 09:33:06 -0800
Date: Thu, 16 Dec 2004 09:33:06 -0800
From: Jun Sun <jsun@junsun.net>
To: zhan rongkai <zhanrk@gmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: About task->used_math and TIF_USEDFPU
Message-ID: <20041216173306.GA3230@gw.junsun.net>
References: <73e6204504121600066a2ce0b1@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <73e6204504121600066a2ce0b1@mail.gmail.com>
User-Agent: Mutt/1.4.1i
Return-Path: <jsun@junsun.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: 6700
X-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@junsun.net
Precedence: bulk
X-list: linux-mips

On Thu, Dec 16, 2004 at 04:06:12PM +0800, zhan rongkai wrote:
> hi all,
> 
> I am a little confused about the task_struct member 'used_math', and
> thread_info flag TIF_USEDFPU.
> 
> What are their meaning, and what is the difference between them?
> 

used_math is used to indicate whether a process has ever used FPU since
it is created (which typically is true due to the glibc using FPU at the
beginning of each program).

TIF_USEDFPU indicates whether a _running_ process has used FPU since
it is context-switched on.

Jun

From navaraga@yahoo.com Fri Dec 17 04:55:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Dec 2004 04:55:17 +0000 (GMT)
Received: from web54504.mail.yahoo.com ([IPv6:::ffff:68.142.225.174]:49756
	"HELO web54504.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224786AbULQEzL>; Fri, 17 Dec 2004 04:55:11 +0000
Received: (qmail 50912 invoked by uid 60001); 17 Dec 2004 04:54:52 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=jlR90E5rhqzJuYsIeFPpYk7+rpRBgFfMXOICB+sh5LgUurJY1F0/++gfoUK1AEwD5+lXzdkdb+tkNJyJntNTTjtaodjrDr6ZjvKqzal9/yqqQjDaMpyEjVUogq4FuM5UM5S7/HygJBgT1FHb76jDQwVwjJJs5ShH1YPDd9jcWoE=  ;
Message-ID: <20041217045452.50910.qmail@web54504.mail.yahoo.com>
Received: from [203.101.73.166] by web54504.mail.yahoo.com via HTTP; Thu, 16 Dec 2004 20:54:52 PST
Date: Thu, 16 Dec 2004 20:54:52 -0800 (PST)
From: Srividya Ramanathan <navaraga@yahoo.com>
Subject: memory mapping
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <navaraga@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: 6701
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: navaraga@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,
 Thanks a lot. I am facing one more problem. There is
one section of the driver where we map a small portion
of the PCI card's memory into user space. During
driver initialization, a magic number is written into
this space and read back from user space to verify the
driver is set up correctly. This fails.

any other way to locate the problem?

Thanks
R Srividya



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 


From sjhill@realitydiluted.com Sat Dec 18 00:16:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Dec 2004 00:16:25 +0000 (GMT)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:46761 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225192AbULRAQU>; Sat, 18 Dec 2004 00:16:20 +0000
Received: from localhost ([127.0.0.1])
	by real.realitydiluted.com with esmtp (Exim 4.34 #1 (Debian))
	id 1CfSGX-0005hX-0g
	for <linux-mips@linux-mips.org>; Fri, 17 Dec 2004 18:16:09 -0600
Message-ID: <41C377ED.1040502@realitydiluted.com>
Date: Fri, 17 Dec 2004 18:21:01 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Ideas on removing a compiler warning in 'init_task.c' ...
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: 6702
X-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

I am trying to clean up a few compiler warnings. Here is one remaining
one:

   CC      arch/mips/kernel/init_task.o
   arch/mips/kernel/init_task.c:15: warning: initialization makes integer from 
pointer without a cast

which has to do with this line:

   static struct sighand_struct init_sighand = INIT_SIGHAND(init_sighand);

I actually broke out the macro and it is complaining about the initialization
of 'action' member in the 'sighand_struct' defined in 'include/linux/sched.h'.

   struct sighand_struct {
           atomic_t                count;
           struct k_sigaction      action[_NSIG];
           spinlock_t              siglock;
   };

I do not see this when compiling x86 code and the MIPS structure is
not that drastically different IMHO. Anyone have some ideas on this
one?

-Steve

From macro@linux-mips.org Sat Dec 18 01:04:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Dec 2004 01:04:42 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:19716 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225197AbULRBEh>; Sat, 18 Dec 2004 01:04:37 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 3338BE1C7D; Sat, 18 Dec 2004 02:04:15 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 21471-05; Sat, 18 Dec 2004 02:04:15 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 07683E1C7C; Sat, 18 Dec 2004 02:04:15 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iBI14Z4D026794;
	Sat, 18 Dec 2004 02:04:35 +0100
Date: Sat, 18 Dec 2004 01:04:21 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: sjhill@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20041217205625Z8225073-1751+3779@linux-mips.org>
Message-ID: <Pine.LNX.4.58L.0412180101250.31951@blysk.ds.pg.gda.pl>
References: <20041217205625Z8225073-1751+3779@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/617/Sun Dec  5 16:25:39 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6703
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, 17 Dec 2004 sjhill@linux-mips.org wrote:

> Modified files:
> 	arch/mips/kernel: setup.c smp.c 
> 
> Log message:
> 	Clean-up compiler warnings.

 Please follow "CodingStyle" when doing changes.

  Maciej

From jgreen@users.sourceforge.net Sat Dec 18 07:01:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Dec 2004 07:01:21 +0000 (GMT)
Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:36810
	"EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP
	id <S8225204AbULRHBH>; Sat, 18 Dec 2004 07:01:07 +0000
Received: from gren.infostations.net (gren.infostations.net [71.4.40.32])
	by mail-relay.infostations.net (Postfix) with ESMTP id E31E9A2CD0
	for <linux-mips@linux-mips.org>; Sat, 18 Dec 2004 07:00:16 +0000 (Local time zone must be set--see zic manual page)
Received: from host-66-81-129-154.rev.o1.com ([66.81.129.154])
	by gren.infostations.net with esmtp (Exim 4.42 #1 (Gentoo))
	id 1CfYbn-0006ZK-QH
	for <linux-mips@linux-mips.org>; Fri, 17 Dec 2004 23:02:34 -0800
Subject: Build problem with drivers/net/au1000_eth.c
From: Josh Green <jgreen@users.sourceforge.net>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Date: Fri, 17 Dec 2004 23:00:40 -0800
Message-Id: <1103353240.24434.10.camel@SillyPuddy.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 
Content-Transfer-Encoding: 7bit
Return-Path: <jgreen@users.sourceforge.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: 6704
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgreen@users.sourceforge.net
Precedence: bulk
X-list: linux-mips

I'm using latest linux-mips CVS kernel (2.6.10rc3) and GCC 3.4.2 on a
AMD Alchemy DBau1100 development board (mipsel/MIPS32).  I wasn't able
to find any other location to post bugs, so please let me know if there
is a bug system or more appropriate place to post this.  The kernel
build dies with:

  CC      drivers/net/au1000_eth.o
drivers/net/au1000_eth.c: In function `au1000_init_module':
drivers/net/au1000_eth.c:100: sorry, unimplemented: inlining failed in
call to 'str2eaddr': function body not available
drivers/net/au1000_eth.c:1506: sorry, unimplemented: called from here
drivers/net/au1000_eth.c: At top level:
drivers/net/au1000_eth.c:152: warning: 'phy_link' defined but not used
make[2]: *** [drivers/net/au1000_eth.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2


I was able to get things to build with the following patch, although I'm
sure this is not the proper way to do things:
$ cvs diff drivers/net/au1000_eth.c

Index: drivers/net/au1000_eth.c
===================================================================
RCS file: /home/cvs/linux/drivers/net/au1000_eth.c,v
retrieving revision 1.39
diff -r1.39 au1000_eth.c
100c100
< extern inline void str2eaddr(unsigned char *ea, unsigned char *str);
---
> extern void str2eaddr(unsigned char *ea, unsigned char *str);


Best regards,
	Josh Green



From sjhill@realitydiluted.com Sat Dec 18 21:27:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Dec 2004 21:27:44 +0000 (GMT)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:46251 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225215AbULRV1b>; Sat, 18 Dec 2004 21:27:31 +0000
Received: from localhost ([127.0.0.1])
	by real.realitydiluted.com with esmtp (Exim 4.34 #1 (Debian))
	id 1Cfm6i-00065F-MM; Sat, 18 Dec 2004 15:27:20 -0600
Message-ID: <41C4A1DD.2090003@realitydiluted.com>
Date: Sat, 18 Dec 2004 15:32:13 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
CC: linux-cvs@linux-mips.org, macro@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
References: <20041218022359Z8225198-1751+3809@linux-mips.org>
In-Reply-To: <20041218022359Z8225198-1751+3809@linux-mips.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: 6705
X-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

macro@linux-mips.org wrote:
> 
> Modified files:
> 	arch/mips/pci  : Makefile 
> 	include/linux  : pci_ids.h 
> 
> Log message:
> 	Fixup the SiByte PCI-HT bridge lying about being a host bridge.
> 
The file 'arch/mips/pci/fixup-sb1250.c' is missing. Please place into
CVS. Thank you.

-Steve

From jgreen@users.sourceforge.net Sat Dec 18 23:37:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Dec 2004 23:37:24 +0000 (GMT)
Received: from nccn1.nccn.net ([IPv6:::ffff:209.79.220.11]:10387 "EHLO
	nccn1.nccn.net") by linux-mips.org with ESMTP id <S8225215AbULRXhT>;
	Sat, 18 Dec 2004 23:37:19 +0000
Received: from 192.168.0.100 (office.nccn.net [209.79.220.38])
	by nccn1.nccn.net (8.12.8/8.12.8/*SLiM* NO UCE! [V13]) with ESMTP id iBINb5EX031265
	for <linux-mips@linux-mips.org>; Sat, 18 Dec 2004 15:37:06 -0800
Subject: Build problem with drivers/net/au1000_eth.c
From: Josh Green <jgreen@users.sourceforge.net>
To: linux-mips@linux-mips.org
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sxP1ytOyqXfKYedZzYEh"
Date: Sat, 18 Dec 2004 15:36:33 -0800
Message-Id: <1103412993.9129.8.camel@SillyPuddy.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 
X-MailScanner-Information: Please contact the ISP for more information
X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
Return-Path: <jgreen@users.sourceforge.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: 6706
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgreen@users.sourceforge.net
Precedence: bulk
X-list: linux-mips


--=-sxP1ytOyqXfKYedZzYEh
Content-Type: multipart/mixed; boundary="=-f1n7npLtdgN2AUUC2GE4"


--=-f1n7npLtdgN2AUUC2GE4
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

I'm using latest linux-mips CVS kernel (2.6.10rc3) and GCC 3.4.2 on a
AMD Alchemy DBau1100 development board (mipsel/MIPS32).  I wasn't able
to find any other location to post bugs, so please let me know if there
is a bug system or more appropriate place to post this.  The kernel
build dies with:

  CC      drivers/net/au1000_eth.o
drivers/net/au1000_eth.c: In function `au1000_init_module':
drivers/net/au1000_eth.c:100: sorry, unimplemented: inlining failed in
call to 'str2eaddr': function body not available
drivers/net/au1000_eth.c:1506: sorry, unimplemented: called from here
drivers/net/au1000_eth.c: At top level:
drivers/net/au1000_eth.c:152: warning: 'phy_link' defined but not used
make[2]: *** [drivers/net/au1000_eth.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2


I was able to get things to build with the following patch, although I'm
sure this is not the proper way to do things:
$ cvs diff drivers/net/au1000_eth.c

Index: drivers/net/au1000_eth.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/linux/drivers/net/au1000_eth.c,v
retrieving revision 1.39
diff -r1.39 au1000_eth.c
100c100
< extern inline void str2eaddr(unsigned char *ea, unsigned char *str);
---
> extern void str2eaddr(unsigned char *ea, unsigned char *str);



I'm noticing another problem now though (a kernel oops), which could be
related to my little patch above.  I changed the definition of str2eaddr
in arch/mips/au1000/common/prom.c to also not be inline just to make
sure they matched.  I now get this oops which seems to appear/disappear
after enabling/disabling kernel options (although I have not been able
to trace it down to one particular feature).  This leads me to believe
it is some sort of alignment bug, which is what the exception refers to.
I have yet been able to build a ksymoops that will work properly, but
I'm still working on that.  If any one has any tips on how I can resolve
this issue I could use the help.  Raw oops output (not ksymoops yet) is
attached.

Best regards,
	Josh Green


--=-f1n7npLtdgN2AUUC2GE4
Content-Disposition: attachment; filename=au1000_init_oops.txt
Content-Type: text/plain; name=au1000_init_oops.txt; charset=ISO-8859-1
Content-Transfer-Encoding: base64

VW5oYW5kbGVkIGtlcm5lbCB1bmFsaWduZWQgYWNjZXNzIGluIGFyY2gvbWlwcy9rZXJuZWwvdW5h
bGlnbmVkLmM6OmVtdWxhdGVfbG9hZF9zdG9yZV9pbnNuLCBsaW5lIDQ3NVsjMV06DQpDcHUgMA0K
JCAwICAgOiAwMDAwMDAwMCAxMDAwZmMwMCA2ZTJmNzM3MyAwMDAwMDAwMA0KJCA0ICAgOiA4MDMw
MDAwMCA4MTBmMTQwMCAwMDAwMDAwMyBiMDUwMDAxNA0KJCA4ICAgOiAwMDAwNTYxYiA4MTBmMTQw
MCBiMDUwMDAxOCAwMDAwMDAwMA0KJDEyICAgOiA4MDM2ZmNmOCBmZmZmZmZmYSBmZmZmZmZmZiAw
MDAwMDAwYQ0KJDE2ICAgOiAwMDAwMDAyMiAwMDAwMDAwMSAwMDAwMDAyMCA4MTBmMTQwMA0KJDIw
ICAgOiA4MTBmMTYyMCAwMDAwZmZmZiA4MDMyNmNjYyBiMDUwMDAwMA0KJDI0ICAgOiAwMDAwMDAw
MSA4MTBiOWUxYQ0KJDI4ICAgOiA4MTBiODAwMCA4MTBiOWY0MCA4MTBmMTYyMCA4MDM1YTJmOA0K
SGkgICAgOiAwMDAzMDFmZg0KTG8gICAgOiBmYzg1YjAwMA0KZXBjICAgOiA4MDM1YTRkNCBhdTEw
MDBfaW5pdF9tb2R1bGUrMHg0YjgvMHg4YmMgICAgIE5vdCB0YWludGVkDQpyYSAgICA6IDgwMzVh
MmY4IGF1MTAwMF9pbml0X21vZHVsZSsweDJkYy8weDhiYw0KU3RhdHVzOiAxMDAwZmMwMyAgICBL
RVJORUwgRVhMIElFDQpDYXVzZSA6IDAwODAwMDEwDQpCYWRWQSA6IDZlMmY3MzczDQpQcklkICA6
IDAyMDMwMjA0DQpNb2R1bGVzIGxpbmtlZCBpbjoNClByb2Nlc3Mgc3dhcHBlciAocGlkOiAxLCB0
aHJlYWRpbmZvPTgxMGI4MDAwLCB0YXNrPTgxMGFkYjQ4KQ0KU3RhY2sgOiAzNzY4NzQ2NSA4MTBm
MTQwMCBiMDUwMDAwMCAwMDAwMDAxYyAxODFhMDAwMCA4MDM1YzJkNCAwMDAwMDAwMCAwMDAwMDAw
MA0KICAgICAgICAwMDAwMDAxYyA4MDM2ZmNmOCA4MDM2MTU4YyAwMDAwMDAwMCA4MDJmMDAwMCA4
MDJmMDAwMCA4MDM2MDAwMCA4MDM2MTViYw0KICAgICAgICA4MDJmMDAwMCA4MDJmMDAwMCA4MDMw
MDAwMCA4MDEwMDZmYyAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMA0KICAgICAg
ICAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAw
MDAwMDAwMCAwMDAwMDAwMA0KICAgICAgICAwMDAwMDAwMCA4MDEwNGQ1NCAxMDAwZmMwMyAwMDAw
MDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCA4MDEwNGQ0NA0KICAgICAgICAuLi4NCkNh
bGwgVHJhY2U6DQogWzw4MDM1YzJkND5dIGRldmluZXRfaW5pdCsweDI0LzB4NjQNCiBbPDgwMTAw
NmZjPl0gaW5pdCsweGM0LzB4MjU0DQogWzw4MDEwNGQ1ND5dIGtlcm5lbF90aHJlYWRfaGVscGVy
KzB4MTAvMHgxOA0KIFs8ODAxMDRkNDQ+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxOA0K
DQoNCkNvZGU6IDAwMDAwMDAwICA4YzQyMDAwNCAgM2MwNDgwMzAgPDhjNDYwMDAwPiAyNDg0MDhh
MCAgMGMwNDk5MjAgIDAwMDA4ODIxICAwMDAwMTAyMSAgMjY4NTAwMDQNCktlcm5lbCBwYW5pYyAt
IG5vdCBzeW5jaW5nOiBBdHRlbXB0ZWQgdG8ga2lsbCBpbml0IQ0K


--=-f1n7npLtdgN2AUUC2GE4--

--=-sxP1ytOyqXfKYedZzYEh
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD8DBQBBxL8BRoMuWKCcbgQRAifUAJ0bo0mkXYmCVhxKpP2EUMSgXx2aMwCcCsS3
Twv8UwSXqC9AeMTURFJAtrs=
=/L2R
-----END PGP SIGNATURE-----

--=-sxP1ytOyqXfKYedZzYEh--


From macro@linux-mips.org Sun Dec 19 03:40:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 19 Dec 2004 03:41:05 +0000 (GMT)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:44814 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225215AbULSDkv>; Sun, 19 Dec 2004 03:40:51 +0000
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 71E46F5A91; Sun, 19 Dec 2004 01:25:57 +0100 (CET)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 05866-09; Sun, 19 Dec 2004 01:25:57 +0100 (CET)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id DAC76FFBA9; Sat, 18 Dec 2004 23:28:54 +0100 (CET)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id iBIMTBYm009496;
	Sat, 18 Dec 2004 23:29:12 +0100
Date: Sat, 18 Dec 2004 22:28:59 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <41C4A1DD.2090003@realitydiluted.com>
Message-ID: <Pine.LNX.4.58L.0412182221470.27710@blysk.ds.pg.gda.pl>
References: <20041218022359Z8225198-1751+3809@linux-mips.org>
 <41C4A1DD.2090003@realitydiluted.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.80/617/Sun Dec  5 16:25:39 2004
	clamav-milter version 0.80j
	on piorun.ds.pg.gda.pl
X-Virus-Status: Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 6707
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, 18 Dec 2004, Steven J. Hill wrote:

> > Log message:
> > 	Fixup the SiByte PCI-HT bridge lying about being a host bridge.
> > 
> The file 'arch/mips/pci/fixup-sb1250.c' is missing. Please place into
> CVS. Thank you.

 Gosh, thanks for the notice.  I've just fixed it up.

  Maciej

From frederic.temporelli@laposte.net Sun Dec 19 10:24:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 19 Dec 2004 10:24:23 +0000 (GMT)
Received: from mailfe10.tele2.se ([IPv6:::ffff:212.247.155.33]:59078 "EHLO
	mailfe10.swip.net") by linux-mips.org with ESMTP
	id <S8224943AbULSKYS>; Sun, 19 Dec 2004 10:24:18 +0000
X-T2-Posting-ID: g63wq726D5fsXb2UbU6LU0KOXzHnTHjCzHZ35sC2MDs=
Received: from [213.103.212.108] (HELO [192.168.0.32])
  by mailfe10.swip.net (CommuniGate Pro SMTP 4.2.7)
  with ESMTP id 43305559 for linux-mips@linux-mips.org; Sun, 19 Dec 2004 11:23:22 +0100
Message-ID: <41C556C3.401@laposte.net>
Date: Sun, 19 Dec 2004 11:24:03 +0100
From: Frederic TEMPORELLI <frederic.temporelli@laposte.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.7.3) Gecko/20040910
X-Accept-Language: fr, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: SGI O2 - RAM 320MBytes - linux reports 245MBytes  (/proc/meminfo)
References: <20041219023850Z8225215-1340+5@linux-mips.org>
In-Reply-To: <20041219023850Z8225215-1340+5@linux-mips.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <frederic.temporelli@laposte.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: 6708
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: frederic.temporelli@laposte.net
Precedence: bulk
X-list: linux-mips

Hello,

no way to see (use ?) all available RAM (320MB) on SGI O2 with 
2.6.10-rc3 (latest cvs)

Hardware => SGI O2 with 320MBytes in this way:
dimm 1: 32MBytes - dimm2: 32MBytes
dimm 3: 32MBytes - dimm4: 32MBytes
dimm 5: 32MBytes - dimm6: 32MBytes
dimm 7: 64MBytes - dimm8: 64MBytes

Firmware => "hinv" is reporting 320MBytes (OK, match hardware)

Linux Kernel (32 and 64 bits) => /proc/meminfo is reporting a MemTotal 
of 245436KB
"top" command is reporting same wrong value (more than 64MB missing)

where can I look for in sources to report/use all available RAM ?
can you help me ?
 
Regards

--
Frederic TEMPORELLI

From kumba@gentoo.org Sun Dec 19 12:25:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 19 Dec 2004 12:25:52 +0000 (GMT)
Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:24461 "EHLO
	sccrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225203AbULSMZr>; Sun, 19 Dec 2004 12:25:47 +0000
Received: from [192.168.1.4] (pcp05077810pcs.waldrf01.md.comcast.net[68.54.246.193])
          by comcast.net (sccrmhc11) with ESMTP
          id <2004121912253001100atp6me>; Sun, 19 Dec 2004 12:25:30 +0000
Message-ID: <41C57431.8000900@gentoo.org>
Date: Sun, 19 Dec 2004 07:29:37 -0500
From: Kumba <kumba@gentoo.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
CC: Frederic TEMPORELLI <frederic.temporelli@laposte.net>
Subject: Re: SGI O2 - RAM 320MBytes - linux reports 245MBytes  (/proc/meminfo)
References: <20041219023850Z8225215-1340+5@linux-mips.org> <41C556C3.401@laposte.net>
In-Reply-To: <41C556C3.401@laposte.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.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: 6709
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Frederic TEMPORELLI wrote:
> Hello,
> 
> no way to see (use ?) all available RAM (320MB) on SGI O2 with 
> 2.6.10-rc3 (latest cvs)
> 
> Hardware => SGI O2 with 320MBytes in this way:
> dimm 1: 32MBytes - dimm2: 32MBytes
> dimm 3: 32MBytes - dimm4: 32MBytes
> dimm 5: 32MBytes - dimm6: 32MBytes
> dimm 7: 64MBytes - dimm8: 64MBytes
> 
> Firmware => "hinv" is reporting 320MBytes (OK, match hardware)
> 
> Linux Kernel (32 and 64 bits) => /proc/meminfo is reporting a MemTotal 
> of 245436KB
> "top" command is reporting same wrong value (more than 64MB missing)
> 
> where can I look for in sources to report/use all available RAM ?
> can you help me ?

O2, like Indy and I2/R4x00, are limited to 256MB max RAM currently.  To see 
any further, O2 needs HIGHMEM support, which last I checked, doesn't exist.

Patches welcome :)


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: small 
hands do them because they must, while the eyes of the great are elsewhere." 
--Elrond

From jgreen@users.sourceforge.net Mon Dec 20 02:55:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Dec 2004 02:55:35 +0000 (GMT)
Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:32670
	"EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP
	id <S8225229AbULTCz2>; Mon, 20 Dec 2004 02:55:28 +0000
Received: from seriyu.infostations.net (seriyu.infostations.net [71.4.40.35])
	by mail-relay.infostations.net (Postfix) with ESMTP id 631D1F70BC
	for <linux-mips@linux-mips.org>; Mon, 20 Dec 2004 02:54:39 +0000 (Local time zone must be set--see zic manual page)
Received: from host-66-81-138-241.rev.o1.com ([66.81.138.241])
	by seriyu.infostations.net with esmtp (Exim 4.41 #1 (Gentoo))
	id 1CgDhY-0006Qq-UL
	for <linux-mips@linux-mips.org>; Sun, 19 Dec 2004 18:55:14 -0800
Subject: Fixes to drivers/net/au1000_eth.c
From: Josh Green <jgreen@users.sourceforge.net>
To: linux-mips@linux-mips.org
In-Reply-To: <1103412993.9129.8.camel@SillyPuddy.localdomain>
References: <1103412993.9129.8.camel@SillyPuddy.localdomain>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6LjiaEgGP55s2qTToT6/"
Date: Sun, 19 Dec 2004 18:54:28 -0800
Message-Id: <1103511268.15414.15.camel@SillyPuddy.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 
Return-Path: <jgreen@users.sourceforge.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: 6710
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgreen@users.sourceforge.net
Precedence: bulk
X-list: linux-mips


--=-6LjiaEgGP55s2qTToT6/
Content-Type: multipart/mixed; boundary="=-SQvlWiq0lT4r9NBZ6h/n"


--=-SQvlWiq0lT4r9NBZ6h/n
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2004-12-18 at 15:36 -0800, Josh Green wrote:
> I'm using latest linux-mips CVS kernel (2.6.10rc3) and GCC 3.4.2 on a
> AMD Alchemy DBau1100 development board (mipsel/MIPS32).  I wasn't able
> to find any other location to post bugs, so please let me know if there
> is a bug system or more appropriate place to post this.

I'm replying to my own post, since I discovered what was causing the
kernel oops with the au1000_eth.c driver.  The attached patch fixes 3
problems:

- The build problem with extern inline str2eaddr.  I just made it
non-inline, although I'm not sure if this is the best way to resolve the
issue.

- At the end of mii_probe(): aup->mii is checked to indicate whether an
ethernet device was found or not, this variable will actually always be
set, which leads to a crash when aup->mii->chip_info->name is accessed
in code following it (in the case where no device is detected).
aup->mii->chip_info seems like a better test, although I'm not positive
on that one.

- In au1000_probe() 'sizeof(dev->dev_addr)' was being used in memcpy
when copying ethernet MAC addresses.  This size is currently 32 which is
larger than the 6 byte buffers being used in the copies, leading to
kernel oopses.

If I should be sending this to the author of the driver or some other
location, please let me know. Best regards,
	Josh Green


--=-SQvlWiq0lT4r9NBZ6h/n
Content-Disposition: attachment; filename=au1000_eth_fixes.patch
Content-Type: text/x-patch; name=au1000_eth_fixes.patch; charset=ISO-8859-1
Content-Transfer-Encoding: base64

SW5kZXg6IGFyY2gvbWlwcy9hdTEwMDAvY29tbW9uL3Byb20uYw0KPT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZp
bGU6IC9ob21lL2N2cy9saW51eC9hcmNoL21pcHMvYXUxMDAwL2NvbW1vbi9wcm9tLmMsdg0KcmV0
cmlldmluZyByZXZpc2lvbiAxLjEyDQpkaWZmIC1yMS4xMiBwcm9tLmMNCjExNWMxMTUNCjwgaW5s
aW5lIHZvaWQgc3RyMmVhZGRyKHVuc2lnbmVkIGNoYXIgKmVhLCB1bnNpZ25lZCBjaGFyICpzdHIp
DQotLS0NCj4gdm9pZCBzdHIyZWFkZHIodW5zaWduZWQgY2hhciAqZWEsIHVuc2lnbmVkIGNoYXIg
KnN0cikNCkluZGV4OiBkcml2ZXJzL25ldC9hdTEwMDBfZXRoLmMNCj09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBm
aWxlOiAvaG9tZS9jdnMvbGludXgvZHJpdmVycy9uZXQvYXUxMDAwX2V0aC5jLHYNCnJldHJpZXZp
bmcgcmV2aXNpb24gMS4zOQ0KZGlmZiAtcjEuMzkgYXUxMDAwX2V0aC5jDQoxMDAsMTAxYzEwMA0K
PCBleHRlcm4gaW5saW5lIHZvaWQgc3RyMmVhZGRyKHVuc2lnbmVkIGNoYXIgKmVhLCB1bnNpZ25l
ZCBjaGFyICpzdHIpOw0KPCBleHRlcm4gaW5saW5lIHVuc2lnbmVkIGNoYXIgc3RyMmhleG51bSh1
bnNpZ25lZCBjaGFyIGMpOw0KLS0tDQo+IGV4dGVybiB2b2lkIHN0cjJlYWRkcih1bnNpZ25lZCBj
aGFyICplYSwgdW5zaWduZWQgY2hhciAqc3RyKTsNCjEwNDVjMTA0NA0KPCAJaWYgKGF1cC0+bWlp
ID09IE5VTEwpIHsNCi0tLQ0KPiAJaWYgKGF1cC0+bWlpLT5jaGlwX2luZm8gPT0gTlVMTCkgew0K
MTQ5N2MxNDk2DQo8IAkJCW1lbWNweShhdTEwMDBfbWFjX2FkZHIsIGV0aGFkZHIsIHNpemVvZihk
ZXYtPmRldl9hZGRyKSk7DQotLS0NCj4gCQkJbWVtY3B5KGF1MTAwMF9tYWNfYWRkciwgZXRoYWRk
ciwgc2l6ZW9mKGF1MTAwMF9tYWNfYWRkcikpOw0KMTUwOGMxNTA3DQo8IAkJCQkJCXNpemVvZihk
ZXYtPmRldl9hZGRyKSk7DQotLS0NCj4gCQkJCQkJc2l6ZW9mKGF1MTAwMF9tYWNfYWRkcikpOw0K
MTUxM2MxNTEyDQo8IAkJbWVtY3B5KGRldi0+ZGV2X2FkZHIsIGF1MTAwMF9tYWNfYWRkciwgc2l6
ZW9mKGRldi0+ZGV2X2FkZHIpKTsNCi0tLQ0KPiAJCW1lbWNweShkZXYtPmRldl9hZGRyLCBhdTEw
MDBfbWFjX2FkZHIsIHNpemVvZihhdTEwMDBfbWFjX2FkZHIpKTsNCjE1MjNjMTUyMg0KPCAJCW1l
bWNweShkZXYtPmRldl9hZGRyLCBhdTEwMDBfbWFjX2FkZHIsIHNpemVvZihkZXYtPmRldl9hZGRy
KSk7DQotLS0NCj4gCQltZW1jcHkoZGV2LT5kZXZfYWRkciwgYXUxMDAwX21hY19hZGRyLCBzaXpl
b2YoYXUxMDAwX21hY19hZGRyKSk7DQo=


--=-SQvlWiq0lT4r9NBZ6h/n--

--=-6LjiaEgGP55s2qTToT6/
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD8DBQBBxj7jRoMuWKCcbgQRAlmAAJ9HFwYFOXooHpMwByXpE5PoMpc0VwCfRK/K
1ZtCKN+beVQh+iHcVSlCroA=
=xbyA
-----END PGP SIGNATURE-----

--=-6LjiaEgGP55s2qTToT6/--


From wuming@ict.ac.cn Mon Dec 20 03:46:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Dec 2004 03:47:01 +0000 (GMT)
Received: from webmail.ict.ac.cn ([IPv6:::ffff:159.226.39.7]:51111 "HELO
	ict.ac.cn") by linux-mips.org with SMTP id <S8225195AbULTDqy>;
	Mon, 20 Dec 2004 03:46:54 +0000
Received: (qmail 9581 invoked by uid 507); 20 Dec 2004 03:45:35 -0000
Received: from unknown (HELO spark) (wuming@159.226.40.187)
  by ict.ac.cn with SMTP; 20 Dec 2004 03:45:35 -0000
Message-ID: <001501c4e646$7f676c00$6f64a8c0@spark>
From: "wuming" <wuming@ict.ac.cn>
To: <linux-mips@linux-mips.org>
Subject: problem about dma
Date: Mon, 20 Dec 2004 11:46:33 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.0
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Return-Path: <wuming@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6711
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wuming@ict.ac.cn
Precedence: bulk
X-list: linux-mips

SW4gZmlsZSBpbmNsdWRlL2FzbS1taXBzL3BjaS5oDQp0aGVyZSBhcmUgc29tZSBmdW5jdGlvbnMg
Zm9yIGRtYSBpZiB0aGUgSS9PIG1vZGVsIGlzIG5vbi1jb2hlcmVudC4NCmZvciBleGFtcGxlOg0K
ICAgIHBjaV9tYXBfc2cNCiAgICBwY2lfdW5tYXBfc2cNClRoZXNlIHR3byBmdW5jdGlvbnMgZXhp
c3QgZm9yIGlkZSBkbWEuDQpCZWZvcmUgdGhlIGRtYSB0cmFuc2ZlciwgcGNpX21hcF9zZyB3aWxs
IG1hcCB0aGUgbWVtb3J5IHNwYWNlIGNvdmVyZWQgYnkgc2dfdGFibGUsDQphbmQgaXQgd2lsbCBm
bHVzaCBhbmQgaW52YWxpZGF0ZSBjYWNoZSBpbmRleGVkIGJ5IHRoYXQgbWVtb3J5IHNwYWNlLg0K
QWZ0ZXIgdGhlIGRtYSB0cmFuc2ZlciwgcGNpX3VubWFwX3NnIGFsc28gbmVlZHMgdG8gYmUgY2Fs
bGVkIHRvIGZsdXNoIGFuZCBpbnZhbGlkYXRlDQp0aGUgc2FtZSBjYWNoZS4gQnV0IEkgZG8gbm90
IGtub3cgd2h5IHRoZSBzZWNvbmQgZmx1c2ggd2lsbCBiZSBkZW1hbmRlZC4NCkkgdGhpbmsgdGhh
dCBpbiB0aGUgaW50ZXJ2YWwgYmV0d2VlbiB0aGUgdHdvIGZsdXNoLCB0aGVyZSB3b3VsZCBiZSBu
b3RoaW5nIHRvIGFjY2Vzcw0KdGhlIG1lbW9yeSBjb3ZlcmVkIGJ5IHRoZSBkbWEuIEJ1dCBpdCBp
cyBub3QgdGhlIGNhc2UuDQpJIHdhbnQgdG8ga25vdyB3aGF0IGNhbiBhY2Nlc3MgdGhhdCBtZW1v
cnkgYW5kIEkgbmVlZCBzb21lIGhlbHAuDQo=


From raiko@niisi.msk.ru Mon Dec 20 08:46:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Dec 2004 08:46:58 +0000 (GMT)
Received: from [IPv6:::ffff:193.232.173.111] ([IPv6:::ffff:193.232.173.111]:1243
	"EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP
	id <S8225002AbULTIqx>; Mon, 20 Dec 2004 08:46:53 +0000
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.12.11/8.12.11) with ESMTP id iBK8hFfg007114;
	Mon, 20 Dec 2004 11:43:16 +0300
Received: from t06.niisi.ras.ru (localhost.localdomain [127.0.0.1])
	by t06.niisi.ras.ru (8.12.8/8.12.8) with ESMTP id iBK8iJSO011229;
	Mon, 20 Dec 2004 11:44:19 +0300
Received: (from uucp@localhost)
	by t06.niisi.ras.ru (8.12.8/8.12.8/Submit) with UUCP id iBK8iJNA011227;
	Mon, 20 Dec 2004 11:44:19 +0300
Received: from [192.168.173.2] (t34 [193.232.173.34])
	by aa19.niisi.msk.ru (8.12.8/8.12.8) with ESMTP id iBK8RCZI017561;
	Mon, 20 Dec 2004 11:27:12 +0300
Message-ID: <41C690CF.2010306@niisi.msk.ru>
Date: Mon, 20 Dec 2004 11:43:59 +0300
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: wuming <wuming@ict.ac.cn>
CC: linux-mips@linux-mips.org
Subject: Re: problem about dma
References: <001501c4e646$7f676c00$6f64a8c0@spark>
In-Reply-To: <001501c4e646$7f676c00$6f64a8c0@spark>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: milter-spamc/0.13.216 (aa19 [172.16.0.19]); Mon, 20 Dec 2004 11:27:13 +0300
X-Antivirus: Dr.Web (R) for Mail Servers on t111.niisi.ras.ru host
X-Antivirus-Code: 100000
Return-Path: <raiko@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6712
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: raiko@niisi.msk.ru
Precedence: bulk
X-list: linux-mips

wuming wrote:
> Before the dma transfer, pci_map_sg will map the memory space covered by sg_table,
> and it will flush and invalidate cache indexed by that memory space.
> After the dma transfer, pci_unmap_sg also needs to be called to flush and invalidate
> the same cache. But I do not know why the second flush will be demanded.
> I think that in the interval between the two flush, there would be nothing to access
> the memory covered by the dma. But it is not the case.
> I want to know what can access that memory and I need some help.

In 2.4, memcpy's prefetch may (and, in practice, do, no smiles, it cost 
me a lot of time to realize) access that memory. I though it has been 
fixed in 2.6 someday.

Regards,
Gleb.

From wuming@ict.ac.cn Mon Dec 20 09:51:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Dec 2004 09:51:43 +0000 (GMT)
Received: from webmail.ict.ac.cn ([IPv6:::ffff:159.226.39.7]:1482 "HELO
	ict.ac.cn") by linux-mips.org with SMTP id <S8225205AbULTJvi>;
	Mon, 20 Dec 2004 09:51:38 +0000
Received: (qmail 32595 invoked by uid 507); 20 Dec 2004 09:50:14 -0000
Received: from unknown (HELO spark) (wuming@159.226.40.187)
  by ict.ac.cn with SMTP; 20 Dec 2004 09:50:14 -0000
Message-ID: <002101c4e679$72938bc0$6f64a8c0@spark>
From: "wuming" <wuming@ict.ac.cn>
To: <linux-mips@linux-mips.org>
References: <001501c4e646$7f676c00$6f64a8c0@spark> <41C690CF.2010306@niisi.msk.ru>
Subject: Re: problem about dma
Date: Mon, 20 Dec 2004 17:51:16 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="KOI8-R"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.0
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Return-Path: <wuming@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6713
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wuming@ict.ac.cn
Precedence: bulk
X-list: linux-mips

DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkdsZWIgTy4gUmFpa28iIDxy
YWlrb0BuaWlzaS5tc2sucnU+DQpUbzogInd1bWluZyIgPHd1bWluZ0BpY3QuYWMuY24+DQpDYzog
PGxpbnV4LW1pcHNAbGludXgtbWlwcy5vcmc+DQpTZW50OiBNb25kYXksIERlY2VtYmVyIDIwLCAy
MDA0IDQ6NDMgUE0NClN1YmplY3Q6IFJlOiBwcm9ibGVtIGFib3V0IGRtYQ0KDQoNCj4gSW4gMi40
LCBtZW1jcHkncyBwcmVmZXRjaCBtYXkgKGFuZCwgaW4gcHJhY3RpY2UsIGRvLCBubyBzbWlsZXMs
IGl0IGNvc3QgDQo+IG1lIGEgbG90IG9mIHRpbWUgdG8gcmVhbGl6ZSkgYWNjZXNzIHRoYXQgbWVt
b3J5LiBJIHRob3VnaCBpdCBoYXMgYmVlbiANCj4gZml4ZWQgaW4gMi42IHNvbWVkYXkuDQo+IA0K
PiBSZWdhcmRzLA0KPiBHbGViLg0KPiANClRoYW5rIHlvdSEgOikNCkJ1dCBJIHRoaW5rIGl0IGlz
IG5vdCB0aGUgb25seSByZWFzb24sIGJlY2F1c2UgdGhlIENQVSBvbiBteSBwbGF0Zm9ybSBkb2Vz
IG5vdCANCnN1cHBvcnQgdGhlICJwcmVmIiBpbnN0cnVjdGlvbi4gU28sIG1lbWNweSdzIHByZWZl
dGNoIG1heSBoYXZlIG5vIGVmZmVjdCBvbiB0aGF0IA0KYXJyYW5nZSBvZiBtZW1vcnkuDQoNCg==


From jonah@omegav.ntnu.no Mon Dec 20 11:29:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Dec 2004 11:29:10 +0000 (GMT)
Received: from royk.itea.ntnu.no ([IPv6:::ffff:129.241.190.230]:9193 "EHLO
	royk.itea.ntnu.no") by linux-mips.org with ESMTP
	id <S8225205AbULTL3F>; Mon, 20 Dec 2004 11:29:05 +0000
Received: from localhost (localhost [127.0.0.1])
	by royk.itea.ntnu.no (Postfix) with ESMTP id 6D098672C9
	for <linux-mips@linux-mips.org>; Mon, 20 Dec 2004 12:28:52 +0100 (CET)
Received: from invalid.ed.ntnu.no (invalid.ed.ntnu.no [129.241.179.15])
	by royk.itea.ntnu.no (Postfix) with ESMTP
	for <linux-mips@linux-mips.org>; Mon, 20 Dec 2004 12:28:52 +0100 (CET)
Received: from invalid.ed.ntnu.no (localhost.ed.ntnu.no [127.0.0.1])
	by invalid.ed.ntnu.no (8.12.9p2/8.12.9) with ESMTP id iBKBSq18003738
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO)
	for <linux-mips@linux-mips.org>; Mon, 20 Dec 2004 12:28:52 +0100 (CET)
	(envelope-from jonah@omegav.ntnu.no)
Received: from localhost (jonah@localhost)
	by invalid.ed.ntnu.no (8.12.9p2/8.12.9/Submit) with ESMTP id iBKBSpcA003735
	for <linux-mips@linux-mips.org>; Mon, 20 Dec 2004 12:28:52 +0100 (CET)
	(envelope-from jonah@omegav.ntnu.no)
X-Authentication-Warning: invalid.ed.ntnu.no: jonah owned process doing -bs
Date: Mon, 20 Dec 2004 12:28:51 +0100 (CET)
From: Jon Anders Haugum <jonah@omegav.ntnu.no>
X-X-Sender: jonah@invalid.ed.ntnu.no
To: linux-mips@linux-mips.org
Subject: [Patch] Au1550 PSC SPI irq mask fix
Message-ID: <20041220122328.M3626@invalid.ed.ntnu.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no.
Return-Path: <jonah@omegav.ntnu.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: 6714
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jonah@omegav.ntnu.no
Precedence: bulk
X-list: linux-mips

The ALLMASK define for SPI interrupts is missing two bits.

diff -u -r1.1.2.6 au1xxx_psc.h
--- linux/include/asm-mips/au1xxx_psc.h 18 Sep 2004 22:07:37 -0000 
1.1.2.6
+++ linux/include/asm-mips/au1xxx_psc.h 20 Dec 2004 11:18:23 -0000
@@ -359,7 +359,8 @@
  #define PSC_SPIMSK_SD          (1 << 5)
  #define PSC_SPIMSK_MD          (1 << 4)
  #define PSC_SPIMSK_ALLMASK     (PSC_SPIMSK_MM | PSC_SPIMSK_RR | \
-                                PSC_SPIMSK_RO | PSC_SPIMSK_TO | \
+                                PSC_SPIMSK_RO | PSC_SPIMSK_RU | \
+                                PSC_SPIMSK_TR | PSC_SPIMSK_TO | \
                                  PSC_SPIMSK_TU | PSC_SPIMSK_SD | \
                                  PSC_SPIMSK_MD)


From fxzhang@ict.ac.cn Mon Dec 20 13:14:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Dec 2004 13:15:03 +0000 (GMT)
Received: from webmail.ict.ac.cn ([IPv6:::ffff:159.226.39.7]:47833 "HELO
	ict.ac.cn") by linux-mips.org with SMTP id <S8225229AbULTNO6>;
	Mon, 20 Dec 2004 13:14:58 +0000
Received: (qmail 30447 invoked by uid 507); 20 Dec 2004 13:13:36 -0000
Received: from unknown (HELO ict.ac.cn) (fxzhang@159.226.40.187)
  by ict.ac.cn with SMTP; 20 Dec 2004 13:13:36 -0000
Message-ID: <41C6D028.5020004@ict.ac.cn>
Date: Mon, 20 Dec 2004 21:14:16 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: zh-cn, en-us
MIME-Version: 1.0
To: wuming <wuming@ict.ac.cn>
CC: linux-mips@linux-mips.org
Subject: Re: problem about dma
References: <001501c4e646$7f676c00$6f64a8c0@spark> <41C690CF.2010306@niisi.msk.ru> <002101c4e679$72938bc0$6f64a8c0@spark>
In-Reply-To: <002101c4e679$72938bc0$6f64a8c0@spark>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <fxzhang@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6715
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fxzhang@ict.ac.cn
Precedence: bulk
X-list: linux-mips

I think that speculative loads may be the answer.
wuming wrote:

>----- Original Message ----- 
>From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
>To: "wuming" <wuming@ict.ac.cn>
>Cc: <linux-mips@linux-mips.org>
>Sent: Monday, December 20, 2004 4:43 PM
>Subject: Re: problem about dma
>
>
>  
>
>>In 2.4, memcpy's prefetch may (and, in practice, do, no smiles, it cost 
>>me a lot of time to realize) access that memory. I though it has been 
>>fixed in 2.6 someday.
>>
>>Regards,
>>Gleb.
>>
>>    
>>
>Thank you! :)
>But I think it is not the only reason, because the CPU on my platform does not 
>support the "pref" instruction. So, memcpy's prefetch may have no effect on that 
>arrange of memory.
>
>  
>

From pf@net.alphadv.de Mon Dec 20 16:40:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Dec 2004 16:40:57 +0000 (GMT)
Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:50194 "EHLO
	mail.alphastar.de") by linux-mips.org with ESMTP
	id <S8225233AbULTQkv>; Mon, 20 Dec 2004 16:40:51 +0000
Received: from Snailmail (212.144.142.207)
          by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==)
          for <linux-mips@linux-mips.org>; Mon, 20 Dec 2004 17:38:52 +0100
Received: from Opal.Peter (pf@Opal.Peter [192.168.1.1])
	by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id iBKGcvYY000543;
	Mon, 20 Dec 2004 17:38:58 +0100
Received: from localhost (pf@localhost)
	by Opal.Peter (8.9.3/8.9.3/Sendmail/Linux 2.2.5-15) with ESMTP id RAA01203;
	Mon, 20 Dec 2004 17:38:42 +0100
Date: Mon, 20 Dec 2004 17:38:41 +0100 (CET)
From: peter fuerst <pf@net.alphadv.de>
To: linux-mips@linux-mips.org
cc: Ralf Baechle <ralf@linux-mips.org>
Subject: ip22zilog serial console
Message-ID: <Pine.LNX.4.21.0412201728440.1170-100000@Opal.Peter>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: pf@net.alphadv.de
Return-Path: <pf@net.alphadv.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: 6716
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pf@net.alphadv.de
Precedence: bulk
X-list: linux-mips



Hi,

there are two lines, which should be inserted into ip22zilog.c, to make
the serial-console work on IP2[82] as expected:

--- snip ---------------------------------------------------------------

--- ip22zilog.c	Fri Dec  3 06:07:38 2004
+++ ip22zilog.c	Mon Dec 20 02:07:42 2004
@@ -881,6 +881,7 @@
 	up->cflag = termios->c_cflag;
 
 	ip22zilog_maybe_update_regs(up, ZILOG_CHANNEL_FROM_PORT(port));
+	uart_update_timeout(port, termios->c_cflag, baud);
 
 	spin_unlock_irqrestore(&up->port.lock, flags);
 }
@@ -1047,6 +1048,8 @@
 	}
 
 	con->cflag = cflag | CS8;			/* 8N1 */
+
+	uart_update_timeout(&ip22zilog_port_table[con->index].port, cflag, baud);
 }
 
 static int __init ip22zilog_console_setup(struct console *con, char *options)


--- snap ---------------------------------------------------------------

The reason for this can be found in drivers/serial/serial_core.c and
drivers/char/tty_ioctl.c (at least up to 2.6.10-rc2 / Rev. 1.13 and 1.20
respective):

1) serial_core.c: If port->timeout is less than HZ/50, a huge per
   character timeout 'char_time' will be calculated in
   uart_wait_until_sent(struct tty_struct*, int timeout).

2) (64bit only)
   tty_ioctl.c: tty_wait_until_sent(struct tty_struct*, long timeout) will
   call tty->driver->wait_until_sent() (->uart_wait_until_sent()) with a
   long timeout argument. So far, this is not critical, as long as all
   other relevant variables in uart_wait_until_sent() are unsigned...

Whenever port->ops->tx_empty() (ip22zilog_tx_empty()) doesn't succeed in
the first attempt, a msleep_interruptible(jiffies_to_msecs(char_time))
will be done (yes, this case isn't negligibly rare) ...
Two consequences could be observed:

1) 'timeout' is in the positive int range (here 30000) and will override
   the huge 'char_time' value. This leads to (e.g.) some nice 30sec delays
   in init.

2) ioctl(0,TCSETSF,...) makes tty_wait_until_sent() call
   tty->driver->wait_until_sent(tty,MAX_SCHEDULE_TIMEOUT),
   i.e.  uart_wait_until_sent(tty,-1).
   Now the huge 'char_time' takes effect, sending login to sleep, until
   it receives a SIGALRM, thus making a console-login impossible.

Since the majority of the serial drivers do not uart_update_timeout(), it
might be preferable to make uart_wait_until_sent() fool-proof (only a couple
of additional statements), instead of changing ip22zilog.c (alone), but i'm
in doubt, whether these changes would find their way.


with kind regards

pf


PS: in general, 2.6.10-rc2 + current linux-mips.org/arch/mips seems to be
far less hostile to IP28, than 2.6-version(s), i toiled with before :-)


From ppopov@embeddedalley.com Mon Dec 20 17:07:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Dec 2004 17:07:11 +0000 (GMT)
Received: from smtp804.mail.sc5.yahoo.com ([IPv6:::ffff:66.163.168.183]:48029
	"HELO smtp804.mail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8225233AbULTRHF>; Mon, 20 Dec 2004 17:07:05 +0000
Received: from unknown (HELO ?10.2.2.62?) (pvpopov@pacbell.net@63.194.214.47 with plain)
  by smtp804.mail.sc5.yahoo.com with SMTP; 20 Dec 2004 17:06:52 -0000
Message-ID: <41C70686.2090806@embeddedalley.com>
Date: Mon, 20 Dec 2004 09:06:14 -0800
From: Pete Popov <ppopov@embeddedalley.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Josh Green <jgreen@users.sourceforge.net>
CC: linux-mips@linux-mips.org
Subject: Re: Fixes to drivers/net/au1000_eth.c
References: <1103412993.9129.8.camel@SillyPuddy.localdomain> <1103511268.15414.15.camel@SillyPuddy.localdomain>
In-Reply-To: <1103511268.15414.15.camel@SillyPuddy.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.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: 6717
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips

Thanks, I'll take care of the patches.

Pete

Josh Green wrote:
> On Sat, 2004-12-18 at 15:36 -0800, Josh Green wrote:
> 
>>I'm using latest linux-mips CVS kernel (2.6.10rc3) and GCC 3.4.2 on a
>>AMD Alchemy DBau1100 development board (mipsel/MIPS32).  I wasn't able
>>to find any other location to post bugs, so please let me know if there
>>is a bug system or more appropriate place to post this.
> 
> 
> I'm replying to my own post, since I discovered what was causing the
> kernel oops with the au1000_eth.c driver.  The attached patch fixes 3
> problems:
> 
> - The build problem with extern inline str2eaddr.  I just made it
> non-inline, although I'm not sure if this is the best way to resolve the
> issue.
> 
> - At the end of mii_probe(): aup->mii is checked to indicate whether an
> ethernet device was found or not, this variable will actually always be
> set, which leads to a crash when aup->mii->chip_info->name is accessed
> in code following it (in the case where no device is detected).
> aup->mii->chip_info seems like a better test, although I'm not positive
> on that one.
> 
> - In au1000_probe() 'sizeof(dev->dev_addr)' was being used in memcpy
> when copying ethernet MAC addresses.  This size is currently 32 which is
> larger than the 6 byte buffers being used in the copies, leading to
> kernel oopses.
> 
> If I should be sending this to the author of the driver or some other
> location, please let me know. Best regards,
> 	Josh Green
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: arch/mips/au1000/common/prom.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/common/prom.c,v
> retrieving revision 1.12
> diff -r1.12 prom.c
> 115c115
> < inline void str2eaddr(unsigned char *ea, unsigned char *str)
> ---
> 
>>void str2eaddr(unsigned char *ea, unsigned char *str)
> 
> Index: drivers/net/au1000_eth.c
> ===================================================================
> RCS file: /home/cvs/linux/drivers/net/au1000_eth.c,v
> retrieving revision 1.39
> diff -r1.39 au1000_eth.c
> 100,101c100
> < extern inline void str2eaddr(unsigned char *ea, unsigned char *str);
> < extern inline unsigned char str2hexnum(unsigned char c);
> ---
> 
>>extern void str2eaddr(unsigned char *ea, unsigned char *str);
> 
> 1045c1044
> < 	if (aup->mii == NULL) {
> ---
> 
>>	if (aup->mii->chip_info == NULL) {
> 
> 1497c1496
> < 			memcpy(au1000_mac_addr, ethaddr, sizeof(dev->dev_addr));
> ---
> 
>>			memcpy(au1000_mac_addr, ethaddr, sizeof(au1000_mac_addr));
> 
> 1508c1507
> < 						sizeof(dev->dev_addr));
> ---
> 
>>						sizeof(au1000_mac_addr));
> 
> 1513c1512
> < 		memcpy(dev->dev_addr, au1000_mac_addr, sizeof(dev->dev_addr));
> ---
> 
>>		memcpy(dev->dev_addr, au1000_mac_addr, sizeof(au1000_mac_addr));
> 
> 1523c1522
> < 		memcpy(dev->dev_addr, au1000_mac_addr, sizeof(dev->dev_addr));
> ---
> 
>>		memcpy(dev->dev_addr, au1000_mac_addr, sizeof(au1000_mac_addr));


From hjl@lucon.org Mon Dec 20 20:59:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Dec 2004 20:59:52 +0000 (GMT)
Received: from rwcrmhc11.comcast.net ([IPv6:::ffff:204.127.198.35]:56475 "EHLO
	rwcrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225233AbULTU7o>; Mon, 20 Dec 2004 20:59:44 +0000
Received: from lucon.org ([24.6.212.230]) by comcast.net (rwcrmhc11) with ESMTP
          id <2004122020592401300g08fne>; Mon, 20 Dec 2004 20:59:24 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id BC12363DD3; Mon, 20 Dec 2004 12:59:23 -0800 (PST)
Date: Mon, 20 Dec 2004 12:59:23 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: linux-gcc@vger.kernel.org
Cc: gcc@gcc.gnu.org, GNU C Library <libc-alpha@sources.redhat.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>
Subject: The Linux binutils 2.15.94.0.2 is released
Message-ID: <20041220205923.GA23648@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <hjl@lucon.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6718
X-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.15.94.0.2 for Linux, which is
based on binutils 2004 1220 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.

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

and

http://www.sourceware.org/bugzilla/

If you don't use

# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2

to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches if there are any.

Changes from binutils 2.15.94.0.1:

1. Update from binutils 2004 1220.
2. Fix strip for TLS symbol references.

Changes from binutils 2.15.92.0.2:

1. Update from binutils 2004 1121.
2. Put ia64 .ctors/.dtors sections next to small data section for
Intel ia64 compiler.
3. Fix -Bdynamic/-Bstatic handling for linker script.
4. Provide more information on relocation overflow.
5. Add --sort-section to linker.
6. Support icc 8.1 unwind info in readelf.
7. Fix the infinite loop bug on bad input in the ia64 assembler.
8. Fix ia64 SECREL relocation in linker.
9. Fix a section group memory leak in readelf.

Changes from binutils 2.15.91.0.2:

1. Update from binutils 2004 0927.
2. Work around a section header bug in Intel ia64 compiler.
3. Fix an unwind directive bug in the ia64 assembler.
4. Fix various PPC bugs.
5. Update ARM support.
6. Fix an x86-64 linker warning while building Linux kernel.

Changes from binutils 2.15.91.0.1:

1. Update from binutils 2004 0727.
2. Fix the x86_64 linker to prevent non-PIC code in shared library.
3. Fix the ia64 linker to warn the relotable files which can't be
relaxed.
4. Fix the comdat group support. Allow mix single-member comdat group
with linkonce section.
5. Added --add-needed/--no-add-needed options to linker.
6. Fix the SHF_LINK_ORDER support.
7. Fix the ia64 assembler for multiple sections with the same name and
SHT_IA_64_UNWIND sections.
8. Fix the ia64 assembler for merge section and relaxation.

Changes from binutils 2.15.90.0.3:

1. Update from binutils 2004 0527.
2. Fix -x auto option in the ia64 assembler.
3. Add the AR check in the ia64 assembler.
4. Fix the section group support.
5. Add a new -z relro linker option.
6. Fix an exception section placement bug in linker.
7. Add .serialize.data and .serialize.instruction to the ia64
assembler.

Changes from binutils 2.15.90.0.2:

1. Update from binutils 2004 0415.
2. Fix the linker for weak undefined symbol handling.
3. Fix the ELF/Sparc and ELF/Sparc64 linker for statically linking PIC
code.

Changes from binutils 2.15.90.0.1.1:

1. Update from binutils 2004 0412.
2. Add --as-needed/--no-as-needed to linker.
3. Fix -z defs in linker.
4. Always reserve the memory for ia64 dynamic linker.
5. Fix a race condition in ia64 lazy binding.

Changes from binutils 2.15.90.0.1:

1. Fixed an ia64 assembler bug.
2. Install the assembler man page.

Changes from binutils 2.14.90.0.8:

1. Update from binutils 2004 0303.
2. Fixed linker for undefined symbols with non-default visibility.
3. Sped up linker weakdef symbol handling.
4. Fixed mixing ELF32 and ELF64 object files in archive.
5. Added ia64 linker brl optimization.
6. Fixed ia64 linker to disallow invalid dynamic relocations.
7. Fixed DT_TEXTREL handling in ia64 linker.
8. Fixed alignment handling in ia64 assembler.
9. Improved ia64 assembler unwind table handling. 

Changes from binutils 2.14.90.0.7:

1. Update from binutils 2004 0114.
2. Fixed an ia64 assembler unwind table bug. 
3. Better handle IPF linker relaxation overflow.
4. Fixed misc PPC bugs.

Changes from binutils 2.14.90.0.6:

1. Update from binutils 2003 1029.
2. Allow type changes for undefined symbols.
3. Fix EH frame optimization.
4. Fix the check for undefined versioned symbol with wildcard.
5. Support generating code for Itanium.
6. Detect and warn bad symbol index.
7. Update IPF assemebler DV check.

Changes from binutils 2.14.90.0.5:

1. Update from binutils 2003 0820.
2. No longer use section names for ELF section types nor flags.
3. Fix some ELF/IA64 linker bugs.
4. Fix some ELF/ppc bugs.
5. Add archive support to readelf.

Changes from binutils 2.14.90.0.4.1:

1. Update from binutils 2003 0722.
2. Fix an ELF/mips linker bug.
3. Fix an ELF/hpppa linker bug.
4. Fix an ELF/ia64 assembler bug.
5. Fix a linkonce support with C++ debug.
6. A new working C++ demangler.
7. Various alpha, mips, ia64, ... bug fixes.
8. Support for the current gcc and glibc.

Changes from binutils 2.14.90.0.4:
 
1. Fix an ia64 assembler hint@pause bug.
2. Support Intel Prescott New Instructions.

Changes from binutils 2.14.90.0.3:

1. Work around the brain dead libtool.

Changes from binutils 2.14.90.0.2:

1. Update from binutils 2003 0523.
2. Fix 2 ELF visibility bugs.
3. Fix ELF/ppc linker bugs.

Changes from binutils 2.14.90.0.1:

1. Update from binutils 2003 0515.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Add more IAS compatibilities to ia64 assembler.

Changes from binutils 2.13.90.0.20:

1. Update from binutils 2003 0505.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Fix some ia64 assembler bugs.
5. Add some IAS compatibilities to ia64 assembler.
6. Fix ELF common symbol alignment.
7. Fix ELF weak symbol handling.

Changes from binutils 2.13.90.0.18:

1. Update from binutils 2003 0319.
2. Fix an ia64 linker brl relaxation bug.
3. Fix some ELF/ppc linker bugs.

Changes from binutils 2.13.90.0.16:

1. Update from binutils 2003 0121.
2. Fix an ia64 gas bug.
3. Fix some TLS bugs.
4. Fix some ELF/ppc bugs.
5. Fix an ELF/m68k bug.

2. Include /usr/bin/c++filt.
Changes from binutils 2.13.90.0.14:

1. Update from binutils 2002 1126.
2. Include /usr/bin/c++filt.
3. Fix "ld -r" with execption handling.

Changes from binutils 2.13.90.0.10:

1. Update from binutils 2002 1114.
2. Fix ELF/alpha bugs.
3. Fix an ELF/i386 assembler bug.

Changes from binutils 2.13.90.0.4:

1. Update from binutils 2002 1010.
2. More ELF/PPC linker bug fixes.
3. Fix an ELF/alpha linker bug.
4. Fix an ELF/sparc linker bug to support Solaris.
5. More TLS updates.

Changes from binutils 2.13.90.0.3:

1. Update from binutils 2002 0814.
2. Fix symbol versioning bugs for gcc 3.2.
3. Fix mips gas.

Changes from binutils 2.13.90.0.2:

1. Update from binutils 2002 0809.
2. Fix a mips gas compatibility bug.
3. Fix an x86 TLS bfd bug.
4. Fix an x86 PIC gas bug.
5. Improve symbol versioning support.

The file list:

1. binutils-2.15.94.0.2.tar.bz2. Source code.
2. binutils-2.15.94.0.1-2.15.94.0.2.diff.bz2. Patch against the
   previous beta source code.
3. binutils-2.15.94.0.2-1.i386.rpm. IA-32 binary RPM for RedHat EL 3.
4. binutils-2.15.94.0.2-1.ia64.rpm. IA-64 binary RPM for RedHat EL 3.
5. binutils-2.15.94.0.2-1.x86_64.rpm. X64_64 binary RPM for RedHat EL 3.

There is no separate source rpm. You can do

# rpmbuild -ta binutils-2.15.94.0.2.tar.bz2

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
12/20/2004

From ralf@linux-mips.org Tue Dec 21 00:25:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 00:25:23 +0000 (GMT)
Received: from p508B7A83.dip.t-dialin.net ([IPv6:::ffff:80.139.122.131]:56185
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225241AbULUAZS>; Tue, 21 Dec 2004 00:25:18 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBL0P7Uw020785;
	Tue, 21 Dec 2004 01:25:07 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBL0P6Ol020784;
	Tue, 21 Dec 2004 01:25:06 +0100
Date: Tue, 21 Dec 2004 01:25:06 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Ideas on removing a compiler warning in 'init_task.c' ...
Message-ID: <20041221002506.GA6538@linux-mips.org>
References: <41C377ED.1040502@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41C377ED.1040502@realitydiluted.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6719
X-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, Dec 17, 2004 at 06:21:01PM -0600, Steven J. Hill wrote:

> I actually broke out the macro and it is complaining about the 
> initialization
> of 'action' member in the 'sighand_struct' defined in 
> 'include/linux/sched.h'.
> 
>   struct sighand_struct {
>           atomic_t                count;
>           struct k_sigaction      action[_NSIG];
>           spinlock_t              siglock;
>   };
> 
> I do not see this when compiling x86 code and the MIPS structure is
> not that drastically different IMHO. Anyone have some ideas on this
> one?

The members of struct sigaction are ordered differently on MIPS.

  Ralf

From sjhill@realitydiluted.com Tue Dec 21 04:27:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 04:27:25 +0000 (GMT)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:25780 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8224771AbULUE1U>; Tue, 21 Dec 2004 04:27:20 +0000
Received: from localhost ([127.0.0.1])
	by real.realitydiluted.com with esmtp (Exim 4.34 #1 (Debian))
	id 1Cgbbz-0007Xq-SW; Mon, 20 Dec 2004 22:27:04 -0600
Message-ID: <41C7A73A.2000800@realitydiluted.com>
Date: Mon, 20 Dec 2004 22:31:54 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5
X-Accept-Language: en
MIME-Version: 1.0
To: Jon Anders Haugum <jonah@omegav.ntnu.no>
CC: linux-mips@linux-mips.org
Subject: Re: [Patch] Au1550 PSC SPI irq mask fix
References: <20041220122328.M3626@invalid.ed.ntnu.no>
In-Reply-To: <20041220122328.M3626@invalid.ed.ntnu.no>
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: 6720
X-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

Jon Anders Haugum wrote:
> The ALLMASK define for SPI interrupts is missing two bits.
> 
REFUSED. Your patch is out of date. Please update to latest
CVS and try again. Next time, please also denote what kernel
version you are applying against. Thanks.

-Steve

From jonah@omegav.ntnu.no Tue Dec 21 07:16:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 07:16:28 +0000 (GMT)
Received: from fri.itea.ntnu.no ([IPv6:::ffff:129.241.7.60]:5028 "EHLO
	fri.itea.ntnu.no") by linux-mips.org with ESMTP id <S8224774AbULUHQX>;
	Tue, 21 Dec 2004 07:16:23 +0000
Received: from localhost (localhost [127.0.0.1])
	by fri.itea.ntnu.no (Postfix) with ESMTP id D407981BB;
	Tue, 21 Dec 2004 08:16:07 +0100 (CET)
Received: from invalid.ed.ntnu.no (invalid.ed.ntnu.no [129.241.179.15])
	by fri.itea.ntnu.no (Postfix) with ESMTP;
	Tue, 21 Dec 2004 08:16:07 +0100 (CET)
Received: from invalid.ed.ntnu.no (localhost.ed.ntnu.no [127.0.0.1])
	by invalid.ed.ntnu.no (8.12.9p2/8.12.9) with ESMTP id iBL7G718012458
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO);
	Tue, 21 Dec 2004 08:16:07 +0100 (CET)
	(envelope-from jonah@omegav.ntnu.no)
Received: from localhost (jonah@localhost)
	by invalid.ed.ntnu.no (8.12.9p2/8.12.9/Submit) with ESMTP id iBL7G7Ax012455;
	Tue, 21 Dec 2004 08:16:07 +0100 (CET)
	(envelope-from jonah@omegav.ntnu.no)
X-Authentication-Warning: invalid.ed.ntnu.no: jonah owned process doing -bs
Date: Tue, 21 Dec 2004 08:16:07 +0100 (CET)
From: Jon Anders Haugum <jonah@omegav.ntnu.no>
X-X-Sender: jonah@invalid.ed.ntnu.no
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [Patch] Au1550 PSC SPI irq mask fix
In-Reply-To: <41C7A73A.2000800@realitydiluted.com>
Message-ID: <20041221080552.O12280@invalid.ed.ntnu.no>
References: <20041220122328.M3626@invalid.ed.ntnu.no> <41C7A73A.2000800@realitydiluted.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no.
Return-Path: <jonah@omegav.ntnu.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: 6721
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jonah@omegav.ntnu.no
Precedence: bulk
X-list: linux-mips

On Mon, 20 Dec 2004, Steven J. Hill wrote:
> REFUSED. Your patch is out of date. Please update to latest
> CVS and try again. Next time, please also denote what kernel
> version you are applying against. Thanks.

Sorry, it's intended for the latest on linux_2_4 branch (2.4.29-pre1). 
Since 2.6/HEAD is currently outdated on this and is missing these SPI 
defines completely.


-- 
Jon Anders Haugum

From francis_moreau2000@yahoo.fr Tue Dec 21 08:53:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 08:53:29 +0000 (GMT)
Received: from web25107.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.55]:53646
	"HELO web25107.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8224774AbULUIxX>; Tue, 21 Dec 2004 08:53:23 +0000
Received: (qmail 3011 invoked by uid 60001); 21 Dec 2004 08:53:07 -0000
Message-ID: <20041221085307.3009.qmail@web25107.mail.ukl.yahoo.com>
Received: from [80.14.198.143] by web25107.mail.ukl.yahoo.com via HTTP; Tue, 21 Dec 2004 09:53:07 CET
Date: Tue, 21 Dec 2004 09:53:07 +0100 (CET)
From: moreau francis <francis_moreau2000@yahoo.fr>
Subject: port on exotic board.
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6722
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips

Hi,

Well, I'm still trying to port Linux on my "exotic"
board...
I hope you don't mind if I ask a couple of questions,
which may be stupid for you but usefull at my level. 
If you think that linux-mips mailing list is not 
intended for these kind of questions, tell me !

So here I am:

I've mapped kernel code and kernel data in different
memories in order to save precious SDRAM memory.

Code    0xC0000000    0x30000000     16Mo    FLASH
Data    0xC1000000    0x20000000      8Mo    SDRAM

When running the kernel at the very begining, I
encounter different issues:

In "tlb_init" function, cp0 WIRED register is set to
zero, therefore the call to "local_flush_tlb_all" 
flush all TLB entries which were mapping my kernel
in the 3 first entries. Why is this necessary ?  

In different part of the kernel it is assumed that the
kernel start at physical addr 0. For instance in
"init_bootmem" fonction, argument start is set to 0.
Or the way to calculate a page frame index in mem_map
array. Why this assumption ?

Why does "mem_map" need to store page frames for
kernel
code ? Are these pages going be used when the Linux is
running ?

I noticed CPHYSADDR macro. This macro only works if
PAGE_OFFSET is equal to 0x80000000. Why does this 
macro exist ? Why not using __pa macro ?


Thanks for your answers.

   Francis.


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

From jgreen@users.sourceforge.net Tue Dec 21 11:31:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 11:31:42 +0000 (GMT)
Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:15586
	"EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP
	id <S8224925AbULULbh>; Tue, 21 Dec 2004 11:31:37 +0000
Received: from suzaku.infostations.net (suzaku.infostations.net [71.4.40.34])
	by mail-relay.infostations.net (Postfix) with ESMTP id C6B64F81AC
	for <linux-mips@linux-mips.org>; Tue, 21 Dec 2004 11:30:51 +0000 (Local time zone must be set--see zic manual page)
Received: from host-69-19-168-8.rev.o1.com ([69.19.168.8])
	by suzaku.infostations.net with esmtp (Exim 4.41 #1 (Gentoo))
	id 1CgiEd-0000rr-C2
	for <linux-mips@linux-mips.org>; Tue, 21 Dec 2004 03:31:24 -0800
Subject: Problems with PCMCIA on AMD dbau1100
From: Josh Green <jgreen@users.sourceforge.net>
To: linux-mips@linux-mips.org
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NylfyEJFMqIMzwn8U/kg"
Date: Tue, 21 Dec 2004 03:31:05 -0800
Message-Id: <1103628665.22113.16.camel@SillyPuddy.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 
Return-Path: <jgreen@users.sourceforge.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: 6723
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgreen@users.sourceforge.net
Precedence: bulk
X-list: linux-mips


--=-NylfyEJFMqIMzwn8U/kg
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

I'm having trouble getting PCMCIA to work properly on my dbau1100 MIPS
board with latest CVS (2.6.10rc3).  Any help would be very appreciated.
Here is lsmod output:

# lsmod
Module                  Size  Used by    Not tainted
au1x00_ss 12160 0 - Live 0xc0005000
pcmcia_core 60848 1 au1x00_ss, Live 0xc0015000


I get this output when modprobing au1x00_ss:

Linux Kernel Card Services
  options:  none


At this point 'pcmcia' is not listed in /proc/devices though, so I'm
assuming another module needs to be inserted?  On my x86 laptop I see
there is a ds module.  This appears to have been compiled into an object
for my MIPS build, but there is no stand alone ds module.  If I insert
the 'pcmcia' module I get pcmcia support (I'm assuming this is the 16
bit PCMCIA module, it doesn't appear dependent on au1x00_ss), but no
cards are detected:

# cardctl ident
Socket 0:
  no product info available
Socket 1:
  no product info available

# cardctl status
Socket 0:
  no card
Socket 1:
  no card


One thing to note is that I get a few warnings during the PCMCIA build:

  CC [M]  drivers/pcmcia/au1000_generic.o
drivers/pcmcia/au1000_generic.c: In function
`au1x00_pcmcia_socket_probe':
drivers/pcmcia/au1000_generic.c:425: warning: integer constant is too
large for "long" type
drivers/pcmcia/au1000_generic.c:433: warning: integer constant is too
large for "long" type

The first warning is related to the following code (second is similar
but for socket 1):

	skt->virt_io =3D (void *)
		((u32)ioremap((ioaddr_t)AU1X_SOCK0_IO, 0x1000) -
		(u32)mips_io_port_base);


AU1X_SOCK0_IO is defined as 0xF00000000 which is a 36 bit number, not
sure if that will cause a problem or not (since ioremap is using phys_t
which is 32 bit).  Perhaps this truncation is intentional though.

Thanks in advance for any helpful pointers. Best regards,
	Josh Green


--=-NylfyEJFMqIMzwn8U/kg
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD8DBQBByAl4RoMuWKCcbgQRAuW2AJ0afdt4P0ZDcVmEVRVbCzPqKikH6QCeK9/a
p+B18REMNUWWyNt2zg6StP0=
=hJoV
-----END PGP SIGNATURE-----

--=-NylfyEJFMqIMzwn8U/kg--


From anemo@mba.ocn.ne.jp Tue Dec 21 14:02:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 14:02:38 +0000 (GMT)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:32207 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8224934AbULUOCb>; Tue, 21 Dec 2004 14:02:31 +0000
Received: from localhost (p7164-ipad25funabasi.chiba.ocn.ne.jp [220.104.85.164])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 4D42283CE; Tue, 21 Dec 2004 23:02:14 +0900 (JST)
Date: Tue, 21 Dec 2004 23:07:40 +0900 (JST)
Message-Id: <20041221.230740.74756890.anemo@mba.ocn.ne.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: initrd_header for mips64 kernel
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030502.220517.74756988.anemo@mba.ocn.ne.jp>
References: <20030502.220517.74756988.anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6724
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Fri, 02 May 2003 22:05:17 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:

anemo> I found that initrd_header in mips64 cvs kernel is broken.  The
anemo> initrd_header should be consist of two 32bit words while 32bit
anemo> addinitrd is used for 64bit kernel too.

This is not still fixed.  Here is a revised patch for 2.6 tree.
Could you apply?

diff -u linux-mips/arch/mips/kernel/setup.c linux/arch/mips/kernel/
--- linux-mips/arch/mips/kernel/setup.c	Sat Dec 18 22:11:28 2004
+++ linux/arch/mips/kernel/setup.c	Sat Dec 18 21:20:59 2004
@@ -281,12 +281,12 @@
 		initrd_reserve_bootmem = 1;
 	} else {
 		unsigned long tmp;
-		unsigned long *initrd_header;
+		u32 *initrd_header;
 
-		tmp = ((reserved_end + PAGE_SIZE-1) & PAGE_MASK) - 8;
+		tmp = ((reserved_end + PAGE_SIZE-1) & PAGE_MASK) - sizeof(u32) * 2;
 		if (tmp < reserved_end)
 			tmp += PAGE_SIZE;
-		initrd_header = (unsigned long *)tmp;
+		initrd_header = (u32 *)tmp;
 		if (initrd_header[0] == 0x494E5244) {
 			initrd_start = (unsigned long)&initrd_header[2];
 			initrd_end = initrd_start + initrd_header[1];

---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Tue Dec 21 14:28:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 14:28:15 +0000 (GMT)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:31450 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8224947AbULUO2L>; Tue, 21 Dec 2004 14:28:11 +0000
Received: from localhost (p7164-ipad25funabasi.chiba.ocn.ne.jp [220.104.85.164])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 2E57382A2; Tue, 21 Dec 2004 23:27:58 +0900 (JST)
Date: Tue, 21 Dec 2004 23:33:24 +0900 (JST)
Message-Id: <20041221.233324.41626824.anemo@mba.ocn.ne.jp>
To: ralf@linux-mips.org
Cc: nunoe@co-nss.co.jp, linux-mips@linux-mips.org
Subject: Re: HIGHMEM
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20041215141613.GB29222@linux-mips.org>
References: <20041207095837.GA13264@linux-mips.org>
	<20041213.133409.11964920.nemoto@toshiba-tops.co.jp>
	<20041215141613.GB29222@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6725
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Wed, 15 Dec 2004 15:16:13 +0100, Ralf Baechle <ralf@linux-mips.org> said:

>> And this is a small step to a 64-bit kernel for TX49XX.  Could you
>> apply?

ralf> Sure, done.

Thanks.  And this is next step.  Could you apply too?

diff -u linux-mips/include/asm-mips/addrspace.h linux/include/asm-mips/addrspace.h 
--- linux-mips/include/asm-mips/addrspace.h	Sun Sep 26 21:31:45 2004
+++ linux/include/asm-mips/addrspace.h	Sat Dec 18 21:21:01 2004
@@ -126,6 +126,7 @@
     || defined (CONFIG_CPU_R4X00)					\
     || defined (CONFIG_CPU_R5000)					\
     || defined (CONFIG_CPU_NEVADA)					\
+    || defined (CONFIG_CPU_TX49XX)					\
     || defined (CONFIG_CPU_MIPS64)
 #define	KUSIZE			0x0000010000000000	/* 2^^40 */
 #define	KUSIZE_64		0x0000010000000000	/* 2^^40 */


From anemo@mba.ocn.ne.jp Tue Dec 21 15:23:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 15:23:45 +0000 (GMT)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:714 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8224947AbULUPXk>; Tue, 21 Dec 2004 15:23:40 +0000
Received: from localhost (p7164-ipad25funabasi.chiba.ocn.ne.jp [220.104.85.164])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 7A537321D; Wed, 22 Dec 2004 00:23:27 +0900 (JST)
Date: Wed, 22 Dec 2004 00:28:53 +0900 (JST)
Message-Id: <20041222.002853.55515442.anemo@mba.ocn.ne.jp>
To: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: fix FIXADDR_TOP for TX39/TX49
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030517.214555.74756802.anemo@mba.ocn.ne.jp>
References: <20030517.214555.74756802.anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6726
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Sat, 17 May 2003 21:45:55 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:

anemo> On TX39/TX49, high 16MB in virtual address space
anemo> (0xff000000-0xffffffff) are reserved and can not be used as
anemo> normal mapped/cached segment.

anemo> This patch fixes FIXADDR_TOP for TX39/TX49.  FIXADDR_TOP is
anemo> used not only if CONFIG_HIGHMEM is enabled.  It is also used
anemo> for high limit address for vmalloc.

anemo> This patch can be applied to both 2.4 and 2.5.  I'm not sure
anemo> whether subtracting 0x2000 is necessary or not but doing it is
anemo> a safe bet.  Please apply.

This patch can still be applied to 2.6.  Could you apply?

--- linux-mips/include/asm-mips/fixmap.h	Sat Nov 27 00:39:25 2004
+++ linux/include/asm-mips/fixmap.h	Sat Dec 18 21:21:01 2004
@@ -70,7 +70,11 @@
  * the start of the fixmap, and leave one page empty
  * at the top of mem..
  */
+#if defined(CONFIG_CPU_TX39XX) || defined(CONFIG_CPU_TX49XX)
+#define FIXADDR_TOP	(0xff000000UL - 0x2000)
+#else
 #define FIXADDR_TOP	(0xffffe000UL)
+#endif
 #define FIXADDR_SIZE	(__end_of_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START	(FIXADDR_TOP - FIXADDR_SIZE)
 
---
Atsushi Nemoto

From ica2_ts@csv.ica.uni-stuttgart.de Tue Dec 21 15:41:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 15:41:27 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:45112
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224939AbULUPlX>; Tue, 21 Dec 2004 15:41:23 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1Cgm8N-0002Gl-00; Tue, 21 Dec 2004 16:41:11 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1Cgm8M-0008E1-00; Tue, 21 Dec 2004 16:41:10 +0100
Date: Tue, 21 Dec 2004 16:41:10 +0100
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: fix FIXADDR_TOP for TX39/TX49
Message-ID: <20041221154110.GT3539@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030517.214555.74756802.anemo@mba.ocn.ne.jp> <20041222.002853.55515442.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041222.002853.55515442.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.5.6+20040907i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6727
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Atsushi Nemoto wrote:
> >>>>> On Sat, 17 May 2003 21:45:55 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
> 
> anemo> On TX39/TX49, high 16MB in virtual address space
> anemo> (0xff000000-0xffffffff) are reserved and can not be used as
> anemo> normal mapped/cached segment.
> 
> anemo> This patch fixes FIXADDR_TOP for TX39/TX49.  FIXADDR_TOP is
> anemo> used not only if CONFIG_HIGHMEM is enabled.  It is also used
> anemo> for high limit address for vmalloc.
> 
> anemo> This patch can be applied to both 2.4 and 2.5.  I'm not sure
> anemo> whether subtracting 0x2000 is necessary or not but doing it is
> anemo> a safe bet.  Please apply.
> 
> This patch can still be applied to 2.6.  Could you apply?
> 
> --- linux-mips/include/asm-mips/fixmap.h	Sat Nov 27 00:39:25 2004
> +++ linux/include/asm-mips/fixmap.h	Sat Dec 18 21:21:01 2004
> @@ -70,7 +70,11 @@
>   * the start of the fixmap, and leave one page empty
>   * at the top of mem..
>   */
> +#if defined(CONFIG_CPU_TX39XX) || defined(CONFIG_CPU_TX49XX)
> +#define FIXADDR_TOP	(0xff000000UL - 0x2000)
> +#else
>  #define FIXADDR_TOP	(0xffffe000UL)

I figure it's PAGE_SIZE which should be subtracted here. (Or is it
2 * PAGE_SIZE for paired r4k-style TLBs?)


Thiemo

From ppopov@embeddedalley.com Tue Dec 21 16:47:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 16:47:21 +0000 (GMT)
Received: from pimout1-ext.prodigy.net ([IPv6:::ffff:207.115.63.77]:11256 "EHLO
	pimout1-ext.prodigy.net") by linux-mips.org with ESMTP
	id <S8224922AbULUQrP>; Tue, 21 Dec 2004 16:47:15 +0000
Received: from 127.0.0.1 (adsl-68-124-224-225.dsl.snfc21.pacbell.net [68.124.224.225])
	by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id iBLGkke3134608
	for <linux-mips@linux-mips.org>; Tue, 21 Dec 2004 11:46:59 -0500
Received: from  [63.194.214.47] by 127.0.0.1
  (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.7)); Tue, 21 Dec 2004 08:46:44 -0800
Message-ID: <41C8536E.5060507@embeddedalley.com>
Date: Tue, 21 Dec 2004 08:46:38 -0800
From: Pete Popov <ppopov@embeddedalley.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Josh Green <jgreen@users.sourceforge.net>
CC: linux-mips@linux-mips.org
Subject: Re: Problems with PCMCIA on AMD dbau1100
References: <1103628665.22113.16.camel@SillyPuddy.localdomain>
In-Reply-To: <1103628665.22113.16.camel@SillyPuddy.localdomain>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ArGoMail-Authenticated: ppopov@embeddedalley.com
Return-Path: <ppopov@embeddedalley.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: 6728
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips

Josh Green wrote:
> I'm having trouble getting PCMCIA to work properly on my dbau1100 MIPS
> board with latest CVS (2.6.10rc3).  Any help would be very appreciated.
> Here is lsmod output:
> 
> # lsmod
> Module                  Size  Used by    Not tainted
> au1x00_ss 12160 0 - Live 0xc0005000
> pcmcia_core 60848 1 au1x00_ss, Live 0xc0015000
> 
> 
> I get this output when modprobing au1x00_ss:
> 
> Linux Kernel Card Services
>   options:  none
> 
> 
> At this point 'pcmcia' is not listed in /proc/devices though, so I'm
> assuming another module needs to be inserted?  On my x86 laptop I see
> there is a ds module.  This appears to have been compiled into an object
> for my MIPS build, but there is no stand alone ds module.  If I insert
> the 'pcmcia' module I get pcmcia support (I'm assuming this is the 16
> bit PCMCIA module, it doesn't appear dependent on au1x00_ss), but no
> cards are detected:
> 
> # cardctl ident
> Socket 0:
>   no product info available
> Socket 1:
>   no product info available
> 
> # cardctl status
> Socket 0:
>   no card
> Socket 1:
>   no card

If all the config files are setup properly, you should start pcmcia 
with /etc/rc.d/init.d/pcmcia start. That will also run the cardmgr. 
Without the cardmgr, nothing will happen. If you're loading the 
modules manuall, modprobe au1x00_ss, then ds.o, the execute cardmgr 
and at that point the card should be detected.

> One thing to note is that I get a few warnings during the PCMCIA build:
> 
>   CC [M]  drivers/pcmcia/au1000_generic.o
> drivers/pcmcia/au1000_generic.c: In function
> `au1x00_pcmcia_socket_probe':
> drivers/pcmcia/au1000_generic.c:425: warning: integer constant is too
> large for "long" type
> drivers/pcmcia/au1000_generic.c:433: warning: integer constant is too
> large for "long" type
> 
> The first warning is related to the following code (second is similar
> but for socket 1):
> 
> 	skt->virt_io = (void *)
> 		((u32)ioremap((ioaddr_t)AU1X_SOCK0_IO, 0x1000) -
> 		(u32)mips_io_port_base);
> 
> 
> AU1X_SOCK0_IO is defined as 0xF00000000 which is a 36 bit number, not
> sure if that will cause a problem or not (since ioremap is using phys_t
> which is 32 bit). 

phys_t is 64 bit if 64BIT is enabled. Make sure you have the 36bit 
I/O support enabled. CONFIG_64BIT_PHYS_ADDR has to be defined.

> Perhaps this truncation is intentional though.
> 
> Thanks in advance for any helpful pointers. Best regards,
> 	Josh Green

I tested pcmcia a couple of months ago when I updated the driver. 
I'll retest it in the next few days and send you additional 
instructions.

Pete



From sebastient@otii.com Tue Dec 21 17:56:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 17:56:28 +0000 (GMT)
Received: from [IPv6:::ffff:68.145.108.97] ([IPv6:::ffff:68.145.108.97]:58124
	"EHLO mail.otii.com") by linux-mips.org with ESMTP
	id <S8224923AbULUR4W>; Tue, 21 Dec 2004 17:56:22 +0000
Received: from [192.168.7.50] (unknown [68.145.108.98])
	by mail.otii.com (Postfix) with ESMTP id ECA35B03A
	for <linux-mips@linux-mips.org>; Tue, 21 Dec 2004 11:09:08 -0700 (MST)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <9040F8C6-5379-11D9-944D-000393DBC6BE@otii.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: linux-mips@linux-mips.org
From: =?ISO-8859-1?Q?S=E9bastien_Taylor?= <sebastient@otii.com>
Subject: Problem registering interrupt
Date: Tue, 21 Dec 2004 10:55:56 -0700
X-Mailer: Apple Mail (2.619)
Return-Path: <sebastient@otii.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: 6729
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sebastient@otii.com
Precedence: bulk
X-list: linux-mips

Hello,

I am porting my driver from 2.4 to 2.6 and am having an issue with 
interrupts, I've updated my interrupt handler to return irqreturn_t 
instead of void and it looks like it should be ok, but on init, when I 
call request_irq it blows up in my face (trace bellow).

Now, if I request_irq with SA_SHIRQ it does boot up fine, but when I 
try to use the driver it blows up again. Now, I'm guessing that means 
something else is requesting my irq number first which is why it works 
with SA_SHIRQ but why would that cause a crash?  Should it not just 
return an error message?

Wasn't sure what code would be relevant so hopefully that explaination 
helps,
Any help would be greatly appreciated.


CPU 0 Unable to handle kernel paging request at virtual address 
00000004, epc =4
Oops in arch/mips/mm/fault.c::do_page_fault, line 166[#1]:
Cpu 0
$ 0   : 00000000 1000fc00 00000000 803382d8
$ 4   : 803382d8 80340000 00000001 804e92a8
$ 8   : 80340000 00000a35 80510000 80510000
$12   : 80510000 8113f074 8113f07c 0000ffff
$16   : 80367620 80367628 1000fc01 00000031
$20   : 805bef28 00000000 00000000 00000000
$24   : 00000000 00000078
$28   : 80570000 80571f20 00000000 801430c4
Hi    : 000000a1
Lo    : 47ad5a00
epc   : 801430c8 setup_irq+0x148/0x224     Not tainted
ra    : 801430c4 setup_irq+0x144/0x224
Status: 1000fc02    KERNEL EXL
Cause : 00808008
BadVA : 000000e1
PrId  : 03030200
Process swapper (pid: 1, threadinfo=80570000, task=80554b48)
Stack : 805bef28 80340000 00000001 804e92a8 805bef28 80217188 00000000 
00000000
         00000031 803250e8 801433b4 80143368 00000000 80340000 00000001 
804e92a8
         00000000 80320000 80380000 00000000 00000000 00000000 8037a958 
8037a56c
         00000000 00000001 80808081 00000000 00000000 00000000 80382fec 
00000000
         80380000 80100518 00000000 00000000 00000000 00000000 00000000 
00000000
         ...
Call Trace:
  [<80217188>] mc2interrupt+0x0/0x368
  [<801433b4>] request_irq+0xd0/0x12c
  [<80143368>] request_irq+0x84/0x12c
  [<80380000>] init+0x38/0xe0
  [<8037a958>] mc2init+0x80/0x1d4
  [<8037a56c>] tty_init+0x160/0x184
  [<80380000>] init+0x38/0xe0
  [<80100518>] init+0xbc/0x1f8
  [<80104de0>] kernel_thread_helper+0x10/0x18
  [<80104dd0>] kernel_thread_helper+0x0/0x18


Code: 0c049dad  ae00000c  8e020004 <8c420004> 1040000a  00000000  
3c048032  0c0
Kernel panic - not syncing: Attempted to kill init! 
                             


From jgreen@users.sourceforge.net Tue Dec 21 19:39:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 19:39:32 +0000 (GMT)
Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:41346
	"EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP
	id <S8224932AbULUTj0>; Tue, 21 Dec 2004 19:39:26 +0000
Received: from kei.infostations.net (kei.infostations.net [71.4.40.33])
	by mail-relay.infostations.net (Postfix) with ESMTP id 8B2FBF7D1E;
	Tue, 21 Dec 2004 19:38:42 +0000 (Local time zone must be set--see zic manual page)
Received: from host-69-19-171-25.rev.o1.com ([69.19.171.25])
	by kei.infostations.net with esmtp (Exim 4.42 #1 (Gentoo))
	id 1CgprA-00025A-0Q; Tue, 21 Dec 2004 11:39:41 -0800
Subject: Re: Problems with PCMCIA on AMD dbau1100
From: Josh Green <jgreen@users.sourceforge.net>
To: Pete Popov <ppopov@embeddedalley.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <41C8536E.5060507@embeddedalley.com>
References: <1103628665.22113.16.camel@SillyPuddy.localdomain>
	 <41C8536E.5060507@embeddedalley.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qPk91WBxOCDOPIJcnU7a"
Date: Tue, 21 Dec 2004 11:38:52 -0800
Message-Id: <1103657932.12558.7.camel@SillyPuddy.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 
Return-Path: <jgreen@users.sourceforge.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: 6730
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgreen@users.sourceforge.net
Precedence: bulk
X-list: linux-mips


--=-qPk91WBxOCDOPIJcnU7a
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2004-12-21 at 08:46 -0800, Pete Popov wrote:
> If all the config files are setup properly, you should start pcmcia=20
> with /etc/rc.d/init.d/pcmcia start. That will also run the cardmgr.=20
> Without the cardmgr, nothing will happen. If you're loading the=20
> modules manuall, modprobe au1x00_ss, then ds.o, the execute cardmgr=20
> and at that point the card should be detected.
>=20

Ok, so there should be a ds.ko compiled then, which I'm not getting
(there is a ds.o in the build tree, but it doesn't get installed as a
module).  I'm still trying to figure out why this is.

> > One thing to note is that I get a few warnings during the PCMCIA build:
> >=20
> >   CC [M]  drivers/pcmcia/au1000_generic.o
> > drivers/pcmcia/au1000_generic.c: In function
> > `au1x00_pcmcia_socket_probe':
> > drivers/pcmcia/au1000_generic.c:425: warning: integer constant is too
> > large for "long" type
> > drivers/pcmcia/au1000_generic.c:433: warning: integer constant is too
> > large for "long" type
> >=20
> > The first warning is related to the following code (second is similar
> > but for socket 1):
> >=20
> > 	skt->virt_io =3D (void *)
> > 		((u32)ioremap((ioaddr_t)AU1X_SOCK0_IO, 0x1000) -
> > 		(u32)mips_io_port_base);
> >=20
> >=20
> > AU1X_SOCK0_IO is defined as 0xF00000000 which is a 36 bit number, not
> > sure if that will cause a problem or not (since ioremap is using phys_t
> > which is 32 bit).=20
>=20
> phys_t is 64 bit if 64BIT is enabled. Make sure you have the 36bit=20
> I/O support enabled. CONFIG_64BIT_PHYS_ADDR has to be defined.
>=20

I made sure that was enabled (it isn't very evident that it has to be, I
found that out from the code), but still got the same warnings.  I don't
suppose there is the possibility that 'unsigned long long' isn't 64 bit
on MIPS?  I changed the #ifdef CONFIG_64BIT_PHYS_ADDR to '#if 1' in
include/asm/types.h (for the typedef phys_t) just to make sure, and got
the same result (those warnings).

> > Perhaps this truncation is intentional though.
> >=20
> > Thanks in advance for any helpful pointers. Best regards,
> > 	Josh Green
>=20
> I tested pcmcia a couple of months ago when I updated the driver.=20
> I'll retest it in the next few days and send you additional=20
> instructions.
>=20
> Pete
>=20

Thank you very much for the info, it gives me a better idea of what I
should be seeing.  I'll keep probing to see if I can figure out whats
going on.  Best regards,
	Josh Green


--=-qPk91WBxOCDOPIJcnU7a
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD8DBQBByHvMRoMuWKCcbgQRAmV5AJ43GvLiWHqDCHAX5ZrfTLKpt/0srgCePRPQ
ziNvPZiWKbXLDJCR+Hs/nUU=
=VTwo
-----END PGP SIGNATURE-----

--=-qPk91WBxOCDOPIJcnU7a--


From jgreen@users.sourceforge.net Tue Dec 21 23:23:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 23:23:33 +0000 (GMT)
Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:28347
	"EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP
	id <S8224932AbULUXX1>; Tue, 21 Dec 2004 23:23:27 +0000
Received: from gren.infostations.net (gren.infostations.net [71.4.40.32])
	by mail-relay.infostations.net (Postfix) with ESMTP id 09E9DF7B59;
	Tue, 21 Dec 2004 23:22:44 +0000 (Local time zone must be set--see zic manual page)
Received: from host-69-19-171-140.rev.o1.com ([69.19.171.140])
	by gren.infostations.net with esmtp (Exim 4.42 #1 (Gentoo))
	id 1CgtNH-0006tp-GD; Tue, 21 Dec 2004 15:25:05 -0800
Subject: Re: Problems with PCMCIA on AMD dbau1100
From: Josh Green <jgreen@users.sourceforge.net>
To: Pete Popov <ppopov@embeddedalley.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <41C8536E.5060507@embeddedalley.com>
References: <1103628665.22113.16.camel@SillyPuddy.localdomain>
	 <41C8536E.5060507@embeddedalley.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oJqPpFKp113nVerD2HD+"
Date: Tue, 21 Dec 2004 15:22:50 -0800
Message-Id: <1103671370.30276.8.camel@SillyPuddy.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 
Return-Path: <jgreen@users.sourceforge.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: 6731
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgreen@users.sourceforge.net
Precedence: bulk
X-list: linux-mips


--=-oJqPpFKp113nVerD2HD+
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Some additional info..

On Tue, 2004-12-21 at 08:46 -0800, Pete Popov wrote:
> If all the config files are setup properly, you should start pcmcia=20
> with /etc/rc.d/init.d/pcmcia start. That will also run the cardmgr.=20
> Without the cardmgr, nothing will happen. If you're loading the=20
> modules manuall, modprobe au1x00_ss, then ds.o, the execute cardmgr=20
> and at that point the card should be detected.
>=20

Looks like pcmcia.ko is probably what should be used instead of ds.o,
although I'm not sure why this policy is different than from before.
Here is the output after loading these 3 modules and running the pcmcia
init script:

# insmod pcmcia_core.ko
# insmod au1x00_ss.ko
# insmod pcmcia.ko

# /etc/init.d/pcmcia start
Starting PCMCIA services: cardmgr[836]: watching 2 sockets
done.

# lsmod
Module                  Size  Used by    Not tainted
pcmcia 24208 4 - Live 0xc0025000
au1x00_ss 12192 0 - Live 0xc0005000
pcmcia_core 60912 2 pcmcia,au1x00_ss, Live 0xc0015000

# cardctl status
Socket 0:
  no card
Socket 1:
  no card


There is a card in the second slot (Netgear 32 bit CardBus WG511
wireless card which uses prism54 driver).  I don't have the driver
compiled for it but I was expecting it to at least be identified.

>=20
> > One thing to note is that I get a few warnings during the PCMCIA build:
> >=20
> >   CC [M]  drivers/pcmcia/au1000_generic.o
> > drivers/pcmcia/au1000_generic.c: In function
> > `au1x00_pcmcia_socket_probe':
> > drivers/pcmcia/au1000_generic.c:425: warning: integer constant is too
> > large for "long" type
> > drivers/pcmcia/au1000_generic.c:433: warning: integer constant is too
> > large for "long" type
> >=20
> > The first warning is related to the following code (second is similar
> > but for socket 1):
> >=20
> > 	skt->virt_io =3D (void *)
> > 		((u32)ioremap((ioaddr_t)AU1X_SOCK0_IO, 0x1000) -
> > 		(u32)mips_io_port_base);
> >=20
> >=20
> > AU1X_SOCK0_IO is defined as 0xF00000000 which is a 36 bit number, not
> > sure if that will cause a problem or not (since ioremap is using phys_t
> > which is 32 bit).=20
>=20
> phys_t is 64 bit if 64BIT is enabled. Make sure you have the 36bit=20
> I/O support enabled. CONFIG_64BIT_PHYS_ADDR has to be defined.
>=20

I discovered that those warnings are generated due to the constants
themselves being truncated (they should be followed by LL, like
0xF00000000LL).  Still no luck though with detecting my card.  Cheers.
	Josh Green


--=-oJqPpFKp113nVerD2HD+
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD8DBQBByLBJRoMuWKCcbgQRAqp0AKCUm+ellnrWakBAVTYsMQwNXarTgQCdHRd9
0pBsa5kDfcfyNnLEf9TAMU4=
=DIZW
-----END PGP SIGNATURE-----

--=-oJqPpFKp113nVerD2HD+--


From nunoe@co-nss.co.jp Tue Dec 21 23:52:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Dec 2004 23:52:22 +0000 (GMT)
Received: from nssinet2.co-nss.co.jp ([IPv6:::ffff:150.96.0.5]:3519 "EHLO
	nssinet2.co-nss.co.jp") by linux-mips.org with ESMTP
	id <S8224932AbULUXwR>; Tue, 21 Dec 2004 23:52:17 +0000
Received: from nssinet2.co-nss.co.jp (localhost [127.0.0.1])
	by nssinet2.co-nss.co.jp (8.9.3/3.7W) with ESMTP id IAA26541;
	Wed, 22 Dec 2004 08:47:35 +0900 (JST)
Received: from nssnet.co-nss.co.jp (nssnet.co-nss.co.jp [150.96.64.250])
	by nssinet2.co-nss.co.jp (8.9.3/3.7W) with ESMTP id IAA26534;
	Wed, 22 Dec 2004 08:47:35 +0900 (JST)
Received: from NUNOE ([150.96.160.60])
	by nssnet.co-nss.co.jp (8.9.3+Sun/3.7W) with SMTP id IAA10149;
	Wed, 22 Dec 2004 08:38:38 +0900 (JST)
Message-ID: <000601c4e7b8$0f043830$3ca06096@NUNOE>
From: "Hdei Nunoe" <nunoe@co-nss.co.jp>
To: <linux-mips@linux-mips.org>
Cc: <ralf@linux-mips.org>, "Atsushi Nemoto" <anemo@mba.ocn.ne.jp>
References: <20041207095837.GA13264@linux-mips.org><20041213.133409.11964920.nemoto@toshiba-tops.co.jp><20041215141613.GB29222@linux-mips.org> <20041221.233324.41626824.anemo@mba.ocn.ne.jp>
Subject: MIPS32 -> MIPS64
Date: Wed, 22 Dec 2004 08:51:58 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Return-Path: <nunoe@co-nss.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: 6732
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nunoe@co-nss.co.jp
Precedence: bulk
X-list: linux-mips

Hello,

Could anyone tell how significant the migration from MIPS32 to MIPS64 is?
Is it just re-building with the MIPS64 toolchain? 
Or is it like another architecture porting?

Regards,
-hdei


From jsun@junsun.net Wed Dec 22 01:27:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 01:27:52 +0000 (GMT)
Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:37320 "EHLO
	rwcrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8224947AbULVB1q>; Wed, 22 Dec 2004 01:27:46 +0000
Received: from gw.junsun.net (c-24-6-106-170.client.comcast.net[24.6.106.170])
          by comcast.net (rwcrmhc13) with ESMTP
          id <2004122201272901500rf7jle>; Wed, 22 Dec 2004 01:27:29 +0000
Received: from gw.junsun.net (gw.junsun.net [127.0.0.1])
	by gw.junsun.net (8.13.1/8.13.1) with ESMTP id iBM1RF72013861;
	Tue, 21 Dec 2004 17:27:27 -0800
Received: (from jsun@localhost)
	by gw.junsun.net (8.13.1/8.13.1/Submit) id iBM1RFj2013860;
	Tue, 21 Dec 2004 17:27:15 -0800
Date: Tue, 21 Dec 2004 17:27:15 -0800
From: Jun Sun <jsun@junsun.net>
To: moreau francis <francis_moreau2000@yahoo.fr>
Cc: linux-mips@linux-mips.org
Subject: Re: port on exotic board.
Message-ID: <20041222012715.GA13782@gw.junsun.net>
References: <20041221085307.3009.qmail@web25107.mail.ukl.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041221085307.3009.qmail@web25107.mail.ukl.yahoo.com>
User-Agent: Mutt/1.4.1i
Return-Path: <jsun@junsun.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: 6733
X-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@junsun.net
Precedence: bulk
X-list: linux-mips


Since nobody else is replying I am giving it a shot.  Hope it helps.

On Tue, Dec 21, 2004 at 09:53:07AM +0100, moreau francis wrote:
> Hi,
> 
> Well, I'm still trying to port Linux on my "exotic"
> board...
> I hope you don't mind if I ask a couple of questions,
> which may be stupid for you but usefull at my level. 
> If you think that linux-mips mailing list is not 
> intended for these kind of questions, tell me !
> 
> So here I am:
> 
> I've mapped kernel code and kernel data in different
> memories in order to save precious SDRAM memory.
> 
> Code    0xC0000000    0x30000000     16Mo    FLASH
> Data    0xC1000000    0x20000000      8Mo    SDRAM
> 
> When running the kernel at the very begining, I
> encounter different issues:
> 
> In "tlb_init" function, cp0 WIRED register is set to
> zero, therefore the call to "local_flush_tlb_all" 
> flush all TLB entries which were mapping my kernel
> in the 3 first entries. Why is this necessary ?  

Setting WIRED to zero is just part of kernel start-up initialization.

In 2.4 it is done before board setup routine, which allows board
to setup certain wired mapping.

In 2.6 it is done after board setup routine.  You are screwed. :) I think
this needs to be fixed.  A couple of boards should be broken because of this.

> In different part of the kernel it is assumed that the
> kernel start at physical addr 0. For instance in
> "init_bootmem" fonction, argument start is set to 0.
> Or the way to calculate a page frame index in mem_map
> array. Why this assumption ?
> 

Because all other boards have phys memory starting from 0?  It
simplies code for sure.

> Why does "mem_map" need to store page frames for
> kernel
> code ? 

mem_map holds kernel page table.  Kernel code is mapped there because
we start from 0 and we need to use the free memory _after_ kernel code
segment.  (I don't think it is very useful for MIPS though, since MIPS uses
a flat 512MB block mapping for kernel virtual address.)

> Are these pages going be used when the Linux is
> running ?

Not much in MIPS case I suppose.

> I noticed CPHYSADDR macro. This macro only works if
> PAGE_OFFSET is equal to 0x80000000. Why does this 
> macro exist ? Why not using __pa macro ?

Don't know much about this one.

BTW, once there was a board whose memory starts from 0x90000000.  It had
similar problems as yours, but I think it ran in the end.  Try to search
the mailing list.

Jun

From ilya@total-knowledge.com Wed Dec 22 02:08:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 02:08:11 +0000 (GMT)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:9113
	"EHLO alpha.total-knowledge.com") by linux-mips.org with ESMTP
	id <S8224947AbULVCIG>; Wed, 22 Dec 2004 02:08:06 +0000
Received: (qmail 7644 invoked from network); 21 Dec 2004 09:13:37 -0800
Received: from c-24-6-216-150.client.comcast.net (HELO ?192.168.0.238?) (24.6.216.150)
  by alpha.total-knowledge.com with SMTP; 21 Dec 2004 09:13:37 -0800
Message-ID: <41C8D6F5.2080007@total-knowledge.com>
Date: Tue, 21 Dec 2004 18:07:49 -0800
From: "Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>
Organization: Total Knowledge
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040918
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: moreau francis <francis_moreau2000@yahoo.fr>
CC: linux-mips@linux-mips.org
Subject: Re: port on exotic board.
References: <20041221085307.3009.qmail@web25107.mail.ukl.yahoo.com> <20041222012715.GA13782@gw.junsun.net>
In-Reply-To: <20041222012715.GA13782@gw.junsun.net>
X-Enigmail-Version: 0.86.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ilya@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: 6734
X-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@total-knowledge.com
Precedence: bulk
X-list: linux-mips

CPHYSADDR gives you physical address from an address that lies in
one of compatibility "unmapped" spaces. "compatibility" in this case refers
to 32bit MIPS view of memory space.

As such, CPHYSADDR macro generally should not be used.

Jun Sun wrote:

>>I noticed CPHYSADDR macro. This macro only works if
>>PAGE_OFFSET is equal to 0x80000000. Why does this 
>>macro exist ? Why not using __pa macro ?
>>    
>>
>
>Don't know much about this one.
>
>BTW, once there was a board whose memory starts from 0x90000000.  It had
>similar problems as yours, but I think it ran in the end.  Try to search
>the mailing list.
>
>Jun
>
>  
>


From jgreen@users.sourceforge.net Wed Dec 22 03:54:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 03:54:27 +0000 (GMT)
Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:25484
	"EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP
	id <S8224947AbULVDyU>; Wed, 22 Dec 2004 03:54:20 +0000
Received: from gren.infostations.net (gren.infostations.net [71.4.40.32])
	by mail-relay.infostations.net (Postfix) with ESMTP id AA8E0F83D5;
	Wed, 22 Dec 2004 03:53:37 +0000 (Local time zone must be set--see zic manual page)
Received: from host-69-19-151-19.rev.o1.com ([69.19.151.19])
	by gren.infostations.net with esmtp (Exim 4.42 #1 (Gentoo))
	id 1CgxbQ-0005C0-Qw; Tue, 21 Dec 2004 19:55:59 -0800
Subject: Re: Problems with PCMCIA on AMD dbau1100
From: Josh Green <jgreen@users.sourceforge.net>
To: Eric DeVolder <eric.devolder@amd.com>
Cc: Pete Popov <ppopov@embeddedalley.com>, linux-mips@linux-mips.org
In-Reply-To: <41C8B1B3.9080201@amd.com>
References: <1103628665.22113.16.camel@SillyPuddy.localdomain>
	 <41C8536E.5060507@embeddedalley.com>
	 <1103671370.30276.8.camel@SillyPuddy.localdomain>
	 <41C8B1B3.9080201@amd.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-F9doOXMwJAsq4pZAtmIC"
Date: Tue, 21 Dec 2004 19:53:47 -0800
Message-Id: <1103687627.12558.11.camel@SillyPuddy.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 
Return-Path: <jgreen@users.sourceforge.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: 6735
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgreen@users.sourceforge.net
Precedence: bulk
X-list: linux-mips


--=-F9doOXMwJAsq4pZAtmIC
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2004-12-21 at 17:28 -0600, Eric DeVolder wrote:
> cardbus isn't supported....and i'm not sure if the pcmcia slots are
> even electrically compatible (meaning i hope your card/db1100 isn't
> damaged).
>=20

Ahh, thanks for that bit of insight.  I wasn't aware that 32 bit cardbus
was not supported.  I have a compact flash to PCMCIA adapter which I
have a 128MB compact flash card installed in, it was detected fine (no
damage seems to have occurred with either the card or au1100 PCMCIA
slots).  That solves that problem.

At first I was rather disappointed when I read this reply, but then I
looked up the wireless card I want to use (Senao NL-2511 Plus EXT2, a
Prism 2.5 based card) and it is PCMCIA Type II 16-bit which I suppose
should work using the hostap driver.

Thanks again for pointing this out!  Cheers.
	Josh Green


--=-F9doOXMwJAsq4pZAtmIC
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD4DBQBByO/KRoMuWKCcbgQRAowsAKCdIt2Gl42U7DD1rrP/uiica6+SmwCXZ1NU
82JPc46+FbpKwTvceLZnVw==
=v8Qj
-----END PGP SIGNATURE-----

--=-F9doOXMwJAsq4pZAtmIC--


From ppopov@embeddedalley.com Wed Dec 22 04:39:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 04:39:28 +0000 (GMT)
Received: from pimout2-ext.prodigy.net ([IPv6:::ffff:207.115.63.101]:13036
	"EHLO pimout2-ext.prodigy.net") by linux-mips.org with ESMTP
	id <S8224802AbULVEjX>; Wed, 22 Dec 2004 04:39:23 +0000
Received: from 127.0.0.1 (adsl-68-124-224-225.dsl.snfc21.pacbell.net [68.124.224.225])
	by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id iBM4dAGs168866
	for <linux-mips@linux-mips.org>; Tue, 21 Dec 2004 23:39:11 -0500
Received: from  [63.194.214.47] by 127.0.0.1
  (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.7)); Tue, 21 Dec 2004 20:39:06 -0800
Message-ID: <41C8FA5E.2030104@embeddedalley.com>
Date: Tue, 21 Dec 2004 20:38:54 -0800
From: Pete Popov <ppopov@embeddedalley.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Josh Green <jgreen@users.sourceforge.net>
CC: Eric DeVolder <eric.devolder@amd.com>, linux-mips@linux-mips.org
Subject: Re: Problems with PCMCIA on AMD dbau1100
References: <1103628665.22113.16.camel@SillyPuddy.localdomain>	 <41C8536E.5060507@embeddedalley.com>	 <1103671370.30276.8.camel@SillyPuddy.localdomain>	 <41C8B1B3.9080201@amd.com> <1103687627.12558.11.camel@SillyPuddy.localdomain>
In-Reply-To: <1103687627.12558.11.camel@SillyPuddy.localdomain>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ArGoMail-Authenticated: ppopov@embeddedalley.com
Return-Path: <ppopov@embeddedalley.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: 6736
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips

Josh Green wrote:
> On Tue, 2004-12-21 at 17:28 -0600, Eric DeVolder wrote:
> 
>>cardbus isn't supported....and i'm not sure if the pcmcia slots are
>>even electrically compatible (meaning i hope your card/db1100 isn't
>>damaged).
>>
> 
> 
> Ahh, thanks for that bit of insight.  I wasn't aware that 32 bit cardbus
> was not supported.  I have a compact flash to PCMCIA adapter which I
> have a 128MB compact flash card installed in, it was detected fine (no
> damage seems to have occurred with either the card or au1100 PCMCIA
> slots).  That solves that problem.
> 
> At first I was rather disappointed when I read this reply, but then I
> looked up the wireless card I want to use (Senao NL-2511 Plus EXT2, a
> Prism 2.5 based card) and it is PCMCIA Type II 16-bit which I suppose
> should work using the hostap driver.

I've used the hostap driver on 2.4 with a Db1x board. It should work 
fine with 2.6 as well.

Pete



From m_lachwani@yahoo.com Wed Dec 22 05:37:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 05:37:14 +0000 (GMT)
Received: from web52805.mail.yahoo.com ([IPv6:::ffff:206.190.39.169]:17060
	"HELO web52805.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224802AbULVFhI>; Wed, 22 Dec 2004 05:37:08 +0000
Received: (qmail 1248 invoked by uid 60001); 22 Dec 2004 05:36:51 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=YB76wbq2/HW9oAQEUZVDGzMslgAU80fTJjl99rMMXTUxADhFSIGaIlps+DDL4YuGes6DulJ1xlRcp2vkscTq5nj3VogEcKVOiDjSwdmbS6n9SnYrr6bYhP58mUkay7VHAlWSWnfj3GA255UUkaeR64PS2RyYDLB2IrL7pQhHcQI=  ;
Message-ID: <20041222053651.1246.qmail@web52805.mail.yahoo.com>
Received: from [61.95.246.135] by web52805.mail.yahoo.com via HTTP; Tue, 21 Dec 2004 21:36:51 PST
Date: Tue, 21 Dec 2004 21:36:51 -0800 (PST)
From: Manish Lachwani <m_lachwani@yahoo.com>
Subject: Re: port on exotic board.
To: Jun Sun <jsun@junsun.net>,
	moreau francis <francis_moreau2000@yahoo.fr>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20041222012715.GA13782@gw.junsun.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <m_lachwani@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: 6737
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: m_lachwani@yahoo.com
Precedence: bulk
X-list: linux-mips

Hello !
> > In "tlb_init" function, cp0 WIRED register is set
> to
> > zero, therefore the call to "local_flush_tlb_all" 
> > flush all TLB entries which were mapping my kernel
> > in the 3 first entries. Why is this necessary ?  
> 
> Setting WIRED to zero is just part of kernel
> start-up initialization.
> 
> In 2.4 it is done before board setup routine, which
> allows board
> to setup certain wired mapping.
> 
> In 2.6 it is done after board setup routine.  You
> are screwed. :) I think
> this needs to be fixed.  A couple of boards should
> be broken because of this.
> 

Well, you can again setup the wired tlb entries later.
For example, in case of Ocelot3 board (setup.c code),
the wired tlb entries are again created in the
time_init function.


void momenco_time_init(void)
{
	setup_wired_tlb_entries();

....

And it is set for the first time in the board setup
function:

static int __init momenco_ocelot_3_setup(void)
{
	unsigned int tmpword;

	board_time_init = momenco_time_init;

	_machine_restart = momenco_ocelot_restart;
	_machine_halt = momenco_ocelot_halt;
	_machine_power_off = momenco_ocelot_power_off;

	/* Wired TLB entries */
	setup_wired_tlb_entries();

....

Maybe you can do the same for this board as well

Thanks
Manish Lachwani



=====
http://www.koffee-break.com

From francis_moreau2000@yahoo.fr Wed Dec 22 09:55:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 09:55:35 +0000 (GMT)
Received: from web25101.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.49]:38275
	"HELO web25101.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8224802AbULVJza>; Wed, 22 Dec 2004 09:55:30 +0000
Received: (qmail 41876 invoked by uid 60001); 22 Dec 2004 09:55:14 -0000
Message-ID: <20041222095514.41874.qmail@web25101.mail.ukl.yahoo.com>
Received: from [80.14.198.143] by web25101.mail.ukl.yahoo.com via HTTP; Wed, 22 Dec 2004 10:55:14 CET
Date: Wed, 22 Dec 2004 10:55:14 +0100 (CET)
From: moreau francis <francis_moreau2000@yahoo.fr>
Subject: Re: port on exotic board.
To: Jun Sun <jsun@junsun.net>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20041222012715.GA13782@gw.junsun.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6738
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips


> Since nobody else is replying I am giving it a shot.
>  Hope it helps.

yes it helps, thanks for replying !

> Setting WIRED to zero is just part of kernel
> start-up initialization.
> I think
> this needs to be fixed.  A couple of boards should
> be broken because of this.

yes and anyway the default value for WIRED is zero
after a reset.

> > Why this assumption ?
> > 
> 
> Because all other boards have phys memory starting
> from 0?  It simplies code for sure.

Well, a part of the kernel seems to support this
feature but not all, specially mips specific code...
That make me think that it would not so hard to change
it...
I look at arm-arch code, and at the definition of
"page_to_pfn" and it does what I need:
      (((page) - mem_map) + PHYS_PFN_OFFSET)
I can't believe that I'm the first one on mips 
architecture who is trying to run kernel code located
at a physicall address different from 0 !

> > Are these pages going be used when the Linux is
> > running ?
> 
> Not much in MIPS case I suppose.

If these pages are not used during kernel life, it
could save space to not map kernel code in "mem_map".
PFN 0 could be the first page that map kernel data.

This is specialy true if code starts at 0x20000000.

> 
> > I noticed CPHYSADDR macro. This macro only works
> if
> > PAGE_OFFSET is equal to 0x80000000. Why does this 
> > macro exist ? Why not using __pa macro ?
> 
> Don't know much about this one.
> 

It is a typically mips specific code that prevents
kernel code to start at address different from 0.


> BTW, once there was a board whose memory starts from
> 0x90000000.  It had
> similar problems as yours, but I think it ran in the
> end.  Try to search
> the mailing list.

I can't find it in mailing list archive :(

   Francis


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

From francis_moreau2000@yahoo.fr Wed Dec 22 10:00:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 10:00:28 +0000 (GMT)
Received: from web25101.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.49]:54404
	"HELO web25101.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8224802AbULVKAY>; Wed, 22 Dec 2004 10:00:24 +0000
Received: (qmail 42979 invoked by uid 60001); 22 Dec 2004 10:00:06 -0000
Message-ID: <20041222100006.42977.qmail@web25101.mail.ukl.yahoo.com>
Received: from [80.14.198.143] by web25101.mail.ukl.yahoo.com via HTTP; Wed, 22 Dec 2004 11:00:06 CET
Date: Wed, 22 Dec 2004 11:00:06 +0100 (CET)
From: moreau francis <francis_moreau2000@yahoo.fr>
Subject: Re: port on exotic board.
To: "Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <41C8D6F5.2080007@total-knowledge.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6739
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips

> CPHYSADDR gives you physical address from an address
> that lies in
> one of compatibility "unmapped" spaces.
> "compatibility" in this case refers
> to 32bit MIPS view of memory space.
> 
> As such, CPHYSADDR macro generally should not be
> used.

Well I still don't understand, why it has been
created...
Why does it should replaced "__pa" in particular time
?

Thanks

   Francis


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

From francis_moreau2000@yahoo.fr Wed Dec 22 10:04:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 10:04:46 +0000 (GMT)
Received: from web25103.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.51]:11379
	"HELO web25103.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8224948AbULVKEm>; Wed, 22 Dec 2004 10:04:42 +0000
Received: (qmail 33170 invoked by uid 60001); 22 Dec 2004 10:04:23 -0000
Message-ID: <20041222100423.33168.qmail@web25103.mail.ukl.yahoo.com>
Received: from [80.14.198.143] by web25103.mail.ukl.yahoo.com via HTTP; Wed, 22 Dec 2004 11:04:23 CET
Date: Wed, 22 Dec 2004 11:04:23 +0100 (CET)
From: moreau francis <francis_moreau2000@yahoo.fr>
Subject: Re: port on exotic board.
To: Manish Lachwani <m_lachwani@yahoo.com>, Jun Sun <jsun@junsun.net>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20041222053651.1246.qmail@web52805.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6740
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips

> ....
> 
> Maybe you can do the same for this board as well
> 

I don't think so, because at the boot time, before
running the very first lines of linux code, the kernel
must be mapped through the TLB. Used TLB entries
should
never be modified, because linux uses them to run
itself, even at boot time !

   Francis


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

From francis_moreau2000@yahoo.fr Wed Dec 22 10:19:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 10:19:26 +0000 (GMT)
Received: from web25109.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.57]:57518
	"HELO web25109.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8224948AbULVKTV>; Wed, 22 Dec 2004 10:19:21 +0000
Received: (qmail 27139 invoked by uid 60001); 22 Dec 2004 10:19:06 -0000
Message-ID: <20041222101906.27137.qmail@web25109.mail.ukl.yahoo.com>
Received: from [80.14.198.143] by web25109.mail.ukl.yahoo.com via HTTP; Wed, 22 Dec 2004 11:19:06 CET
Date: Wed, 22 Dec 2004 11:19:06 +0100 (CET)
From: moreau francis <francis_moreau2000@yahoo.fr>
Subject: Re: Problem registering interrupt
To: linux-mips@linux-mips.org, sebastient@otii.com
In-Reply-To: <41C947CC.20709@innova-card.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6741
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips


> CPU 0 Unable to handle kernel paging request at
> virtual address 00000004, epc =4

Well it suggests me that your driver is trying to 
access a really nasty pointer: 0x00000004...
How did you get this address ? From user space ?

   Francis


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

From jbglaw@lug-owl.de Wed Dec 22 10:45:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 10:45:13 +0000 (GMT)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:40129 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8224920AbULVKpI>;
	Wed, 22 Dec 2004 10:45:08 +0000
Received: by lug-owl.de (Postfix, from userid 1001)
	id 5F40B1901FB; Wed, 22 Dec 2004 11:44:57 +0100 (CET)
Date: Wed, 22 Dec 2004 11:44:57 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: Problem registering interrupt
Message-ID: <20041222104457.GR2460@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <41C947CC.20709@innova-card.com> <20041222101906.27137.qmail@web25109.mail.ukl.yahoo.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="1GSL5ZULXUIqbbH1"
Content-Disposition: inline
In-Reply-To: <20041222101906.27137.qmail@web25109.mail.ukl.yahoo.com>
X-Operating-System: Linux mail 2.6.10-rc2-bk5lug-owl
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.6+20040907i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6742
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


--1GSL5ZULXUIqbbH1
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, 2004-12-22 11:19:06 +0100, moreau francis <francis_moreau2000@yahoo=
=2Efr>
wrote in message <20041222101906.27137.qmail@web25109.mail.ukl.yahoo.com>:
>=20
> > CPU 0 Unable to handle kernel paging request at
> > virtual address 00000004, epc =3D4
>=20
> Well it suggests me that your driver is trying to=20
> access a really nasty pointer: 0x00000004...
> How did you get this address ? From user space ?

Accesses to nearly NULL are normally structure accesses where a pointer
to a given struct was supplied as a NULL pointer.

So an access to 0x00000004 is most probably an access to the second
element of a struct, given/expected that all fields are usually 4-byte
aligned.

>From looking at ./kernel/irq/manage.c:setup_irq(), I guess that you
supply NULL as the "struct irqaction *", which is the 2nd argument of
setup_irq(). It's 2nd structure element is "flags" then... This is the
first thing accessed by the "new" pointer in setup_irq().

MfG, JBG

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

--1GSL5ZULXUIqbbH1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFByVApHb1edYOZ4bsRAnPQAJkBqac21e+DHjv+ubDV2Lt2CDl65QCcDL0j
qZgPbkeXlXZw5n05nOSnbpU=
=rVaL
-----END PGP SIGNATURE-----

--1GSL5ZULXUIqbbH1--

From sskowron@ET.PUT.Poznan.PL Wed Dec 22 11:24:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 11:24:47 +0000 (GMT)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:16852
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8224920AbULVLYn>; Wed, 22 Dec 2004 11:24:43 +0000
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id iBMBOSM19525
	for <linux-mips@linux-mips.org>; Wed, 22 Dec 2004 12:24:28 +0100 (MET)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Wed, 22 Dec 2004 11:35:44 +0100 (MET)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id iBMAZhm08470
	for <linux-mips@linux-mips.org>; Wed, 22 Dec 2004 11:35:43 +0100 (MET)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Wed, 22 Dec 2004 11:35:43 +0100 (MET)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Re: port on exotic board.
In-Reply-To: <20041222095514.41874.qmail@web25101.mail.ukl.yahoo.com>
Message-ID: <Pine.GSO.4.10.10412221132240.8260-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 6743
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

> yes and anyway the default value for WIRED is zero
> after a reset.

PROMs *do* have interesting ideas sometimes.

> I can't believe that I'm the first one on mips 
> architecture who is trying to run kernel code located
> at a physicall address different from 0 !

Sure you aren't. If you have a 64-bit machine, it's relatively easy in
fact. If your code and data is above 512 MB, you are a little more
screwed, but it still can be done (as evidenced by me), and CPHYSADDR does
not, enter the discussion at all. All you have to do is create a correct
memory map at start.

I don't know about running mapped kernels in 32-bit mode, though. It is a
different thing whatsoever.

Stanislaw Skowronek



From francis_moreau2000@yahoo.fr Wed Dec 22 18:28:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 18:28:55 +0000 (GMT)
Received: from web25105.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.53]:39529
	"HELO web25105.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8225074AbULVS2u>; Wed, 22 Dec 2004 18:28:50 +0000
Received: (qmail 33845 invoked by uid 60001); 22 Dec 2004 18:28:34 -0000
Message-ID: <20041222182834.33843.qmail@web25105.mail.ukl.yahoo.com>
Received: from [80.14.198.143] by web25105.mail.ukl.yahoo.com via HTTP; Wed, 22 Dec 2004 19:28:34 CET
Date: Wed, 22 Dec 2004 19:28:34 +0100 (CET)
From: moreau francis <francis_moreau2000@yahoo.fr>
Subject: Re: [Fwd: Re: port on exotic board.]
To: linux-mips@linux-mips.org, sskowron@ET.PUT.Poznan.PL
In-Reply-To: <41C9B67A.7070304@innova-card.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6744
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips

> I don't know about running mapped kernels in 32-bit
> mode, though. It is a
> different thing whatsoever.

Actually this is my problem...
Well I started to modify code, I will report you any
issue I will encounter if you want.

   Francis.


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

From ica2_ts@csv.ica.uni-stuttgart.de Wed Dec 22 21:55:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 21:55:51 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:31822
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225235AbULVVzi>; Wed, 22 Dec 2004 21:55:38 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1ChES5-0000L8-00
	for <linux-mips@linux-mips.org>; Wed, 22 Dec 2004 22:55:25 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1ChES4-0004of-00
	for <linux-mips@linux-mips.org>; Wed, 22 Dec 2004 22:55:24 +0100
Date: Wed, 22 Dec 2004 22:55:24 +0100
To: linux-mips@linux-mips.org
Subject: [PATCH] Further TLB handler optimizations
Message-ID: <20041222215524.GB3539@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040907i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6745
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Hallo All,

this patch adds some optimizations to the TLB load/store/modify
exception handlers. Most notably, the TLB_OPTIMIZE stuff from the
32bit kernel works now as well for 64bit kernels. This improved the
lmbench number for fork+exit by ~15%.

The fastpath for these handlers is now also synthesized at runtime,
this allows a single implementation with some more optimizations.

The TLB_OPTIMIZE case for 32bit SMP was not safe for mutithreading,
this is also fixed.

The patch was tested on an O200 SMP system with 2 x R12000. Other
machines are untested. Please test if it still works for you,
especially if your system has r3000 style TLBs, or if it is a
MIPS32 CPU which uses CONFIG_64BIT_PHYS_ADDR.


Thiemo


Index: arch/mips/kernel/traps.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/traps.c,v
retrieving revision 1.205
diff -u -p -r1.205 traps.c
--- arch/mips/kernel/traps.c	16 Dec 2004 19:52:54 -0000	1.205
+++ arch/mips/kernel/traps.c	22 Dec 2004 21:23:45 -0000
@@ -38,12 +38,9 @@
 #include <asm/watch.h>
 #include <asm/types.h>
 
-extern asmlinkage void handle_mod(void);
+extern asmlinkage void handle_tlbm(void);
 extern asmlinkage void handle_tlbl(void);
 extern asmlinkage void handle_tlbs(void);
-extern asmlinkage void __xtlb_mod(void);
-extern asmlinkage void __xtlb_tlbl(void);
-extern asmlinkage void __xtlb_tlbs(void);
 extern asmlinkage void handle_adel(void);
 extern asmlinkage void handle_ades(void);
 extern asmlinkage void handle_ibe(void);
@@ -1010,16 +1007,10 @@ void __init trap_init(void)
 	if (board_be_init)
 		board_be_init();
 
-#ifdef CONFIG_MIPS32
-	set_except_vector(1, handle_mod);
+	set_except_vector(1, handle_tlbm);
 	set_except_vector(2, handle_tlbl);
 	set_except_vector(3, handle_tlbs);
-#endif
-#ifdef CONFIG_MIPS64
-	set_except_vector(1, __xtlb_mod);
-	set_except_vector(2, __xtlb_tlbl);
-	set_except_vector(3, __xtlb_tlbs);
-#endif
+
 	set_except_vector(4, handle_adel);
 	set_except_vector(5, handle_ades);
 
Index: arch/mips/mm/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/Makefile,v
retrieving revision 1.73
diff -u -p -r1.73 Makefile
--- arch/mips/mm/Makefile	16 Dec 2004 16:48:28 -0000	1.73
+++ arch/mips/mm/Makefile	22 Dec 2004 21:23:45 -0000
@@ -3,7 +3,7 @@
 #
 
 obj-y				+= cache.o extable.o fault.o init.o pgtable.o \
-				   tlbex.o
+				   tlbex.o tlbex-fault.o
 
 obj-$(CONFIG_MIPS32)		+= ioremap.o pgtable-32.o
 obj-$(CONFIG_MIPS64)		+= pgtable-64.o
@@ -27,41 +27,6 @@ obj-$(CONFIG_CPU_TX39XX)	+= c-tx39.o pg-
 obj-$(CONFIG_CPU_TX49XX)	+= c-r4k.o cex-gen.o pg-r4k.o tlb-r4k.o
 obj-$(CONFIG_CPU_VR41XX)	+= c-r4k.o cex-gen.o pg-r4k.o tlb-r4k.o
 
-#
-# TLB exception handling code differs between 32-bit and 64-bit kernels.
-#
-ifdef CONFIG_MIPS32
-obj-$(CONFIG_CPU_R3000)		+= tlbex32-r3k.o
-obj-$(CONFIG_CPU_TX49XX)	+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_R4300)		+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_R4X00)		+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_VR41XX)	+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_R5000)		+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_NEVADA)	+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_R5432)		+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_RM7000)	+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_RM9000)	+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_R10000)	+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_MIPS32)	+= tlbex32-mips32.o
-obj-$(CONFIG_CPU_MIPS64)	+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_SB1)		+= tlbex32-r4k.o
-obj-$(CONFIG_CPU_TX39XX)	+= tlbex32-r3k.o
-endif
-ifdef CONFIG_MIPS64
-obj-$(CONFIG_CPU_R4300)		+= tlbex64.o
-obj-$(CONFIG_CPU_TX49XX)	+= tlbex64.o
-obj-$(CONFIG_CPU_R4X00)		+= tlbex64.o
-obj-$(CONFIG_CPU_R5000)		+= tlbex64.o
-obj-$(CONFIG_CPU_NEVADA)	+= tlbex64.o
-obj-$(CONFIG_CPU_R5432)		+= tlbex64.o
-obj-$(CONFIG_CPU_RM7000)	+= tlbex64.o
-obj-$(CONFIG_CPU_RM9000)	+= tlbex64.o
-obj-$(CONFIG_CPU_R10000)	+= tlbex64.o
-obj-$(CONFIG_CPU_SB1)		+= tlbex64.o
-obj-$(CONFIG_CPU_MIPS64)	+= tlbex64.o
-endif
-
-
 obj-$(CONFIG_IP22_CPU_SCACHE)	+= sc-ip22.o
 obj-$(CONFIG_R5000_CPU_SCACHE)  += sc-r5k.o
 obj-$(CONFIG_RM7000_CPU_SCACHE)	+= sc-rm7k.o
Index: arch/mips/mm/tlbex-fault.S
===================================================================
RCS file: arch/mips/mm/tlbex-fault.S
diff -N arch/mips/mm/tlbex-fault.S
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ arch/mips/mm/tlbex-fault.S	22 Dec 2004 21:23:47 -0000
@@ -0,0 +1,28 @@
+/*
+ * 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) 1999 Ralf Baechle
+ * Copyright (C) 1999 Silicon Graphics, Inc.
+ */
+#include <asm/mipsregs.h>
+#include <asm/page.h>
+#include <asm/regdef.h>
+#include <asm/stackframe.h>
+
+	.macro tlb_do_fault_nopage, write
+	NESTED(tlb_do_fault_nopage_\write, PT_SIZE, sp)
+	SAVE_ALL
+	MFC0	a2, CP0_BADVADDR
+	KMODE
+	move	a0, sp
+	REG_S	a2, PT_BVADDR(sp)
+	li	a1, \write
+	jal	do_page_fault
+	j	ret_from_exception
+	END(tlb_do_fault_nopage_\write)
+	.endm
+
+	tlb_do_fault_nopage 0
+	tlb_do_fault_nopage 1
Index: arch/mips/mm/tlbex.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/tlbex.c,v
retrieving revision 1.12
diff -u -p -r1.12 tlbex.c
--- arch/mips/mm/tlbex.c	21 Dec 2004 01:16:35 -0000	1.12
+++ arch/mips/mm/tlbex.c	22 Dec 2004 21:23:47 -0000
@@ -85,12 +85,13 @@ enum opcode {
 	insn_invalid,
 	insn_addu, insn_addiu, insn_and, insn_andi, insn_beq,
 	insn_bgez, insn_bgezl, insn_bltz, insn_bltzl, insn_bne,
-	insn_daddu, insn_daddiu, insn_dmfc0, insn_dmtc0,
-	insn_dsll, insn_dsll32, insn_dsra, insn_dsrl, insn_dsrl32,
-	insn_dsubu, insn_eret, insn_j, insn_jal, insn_jr, insn_ld,
-	insn_lui, insn_lw, insn_mfc0, insn_mtc0, insn_ori, insn_rfe,
-	insn_sd, insn_sll, insn_sra, insn_srl, insn_subu, insn_sw,
-	insn_tlbp, insn_tlbwi, insn_tlbwr, insn_xor, insn_xori
+	insn_daddu, insn_daddiu, insn_dmfc0, insn_dmtc0, insn_dsll,
+	insn_dsll32, insn_dsra, insn_dsrl, insn_dsrl32, insn_dsubu,
+	insn_eret, insn_j, insn_jal, insn_jr, insn_ld, insn_ll,
+	insn_lld, insn_lui, insn_lw, insn_mfc0, insn_mtc0, insn_ori,
+	insn_rfe, insn_sc, insn_scd, insn_sd, insn_sll,	insn_sra,
+	insn_srl, insn_subu, insn_sw, insn_tlbp, insn_tlbwi,
+	insn_tlbwr, insn_xor, insn_xori
 };
 
 struct insn {
@@ -134,12 +135,16 @@ static __initdata struct insn insn_table
 	{ insn_jal, M(jal_op,0,0,0,0,0), JIMM },
 	{ insn_jr, M(spec_op,0,0,0,0,jr_op), RS },
 	{ insn_ld, M(ld_op,0,0,0,0,0), RS | RT | SIMM },
+	{ insn_ll, M(ll_op,0,0,0,0,0), RS | RT | SIMM },
+	{ insn_lld, M(lld_op,0,0,0,0,0), RS | RT | SIMM },
 	{ insn_lui, M(lui_op,0,0,0,0,0), RT | SIMM },
 	{ insn_lw, M(lw_op,0,0,0,0,0), RS | RT | SIMM },
 	{ insn_mfc0, M(cop0_op,mfc_op,0,0,0,0), RT | RD },
 	{ insn_mtc0, M(cop0_op,mtc_op,0,0,0,0), RT | RD },
 	{ insn_ori, M(ori_op,0,0,0,0,0), RS | RT | UIMM },
 	{ insn_rfe, M(cop0_op,cop_op,0,0,0,rfe_op), 0 },
+	{ insn_sc, M(sc_op,0,0,0,0,0), RS | RT | SIMM },
+	{ insn_scd, M(scd_op,0,0,0,0,0), RS | RT | SIMM },
 	{ insn_sd, M(sd_op,0,0,0,0,0), RS | RT | SIMM },
 	{ insn_sll, M(spec_op,0,0,0,0,sll_op), RT | RD | RE },
 	{ insn_sra, M(spec_op,0,0,0,0,sra_op), RT | RD | RE },
@@ -361,12 +366,16 @@ I_u1(_j);
 I_u1(_jal);
 I_u1(_jr);
 I_u2s3u1(_ld);
+I_u2s3u1(_ll);
+I_u2s3u1(_lld);
 I_u1s2(_lui);
 I_u2s3u1(_lw);
 I_u1u2(_mfc0);
 I_u1u2(_mtc0);
 I_u2u1u3(_ori);
 I_0(_rfe);
+I_u2s3u1(_sc);
+I_u2s3u1(_scd);
 I_u2s3u1(_sd);
 I_u2u1u3(_sll);
 I_u2u1u3(_sra);
@@ -389,8 +398,14 @@ enum label_id {
 	label_leave,
 	label_vmalloc,
 	label_vmalloc_done,
-	label_tlbwr_hazard,
-	label_split
+	label_tlbw_hazard,
+	label_split,
+	label_nopage_tlbl,
+	label_nopage_tlbs,
+	label_nopage_tlbm,
+	label_smp_pgtable_change,
+	label_r3000_write_probe_fail,
+	label_r3000_write_probe_ok
 };
 
 struct label {
@@ -416,8 +431,14 @@ L_LA(_second_part)
 L_LA(_leave)
 L_LA(_vmalloc)
 L_LA(_vmalloc_done)
-L_LA(_tlbwr_hazard)
+L_LA(_tlbw_hazard)
 L_LA(_split)
+L_LA(_nopage_tlbl)
+L_LA(_nopage_tlbs)
+L_LA(_nopage_tlbm)
+L_LA(_smp_pgtable_change)
+L_LA(_r3000_write_probe_fail)
+L_LA(_r3000_write_probe_ok)
 
 /* convenience macros for instructions */
 #ifdef CONFIG_MIPS64
@@ -431,6 +452,8 @@ L_LA(_split)
 # define i_ADDIU(buf, rs, rt, val) i_daddiu(buf, rs, rt, val)
 # define i_ADDU(buf, rs, rt, rd) i_daddu(buf, rs, rt, rd)
 # define i_SUBU(buf, rs, rt, rd) i_dsubu(buf, rs, rt, rd)
+# define i_LL(buf, rs, rt, off) i_lld(buf, rs, rt, off)
+# define i_SC(buf, rs, rt, off) i_scd(buf, rs, rt, off)
 #else
 # define i_LW(buf, rs, rt, off) i_lw(buf, rs, rt, off)
 # define i_SW(buf, rs, rt, off) i_sw(buf, rs, rt, off)
@@ -442,9 +465,12 @@ L_LA(_split)
 # define i_ADDIU(buf, rs, rt, val) i_addiu(buf, rs, rt, val)
 # define i_ADDU(buf, rs, rt, rd) i_addu(buf, rs, rt, rd)
 # define i_SUBU(buf, rs, rt, rd) i_subu(buf, rs, rt, rd)
+# define i_LL(buf, rs, rt, off) i_ll(buf, rs, rt, off)
+# define i_SC(buf, rs, rt, off) i_sc(buf, rs, rt, off)
 #endif
 
 #define i_b(buf, off) i_beq(buf, 0, 0, off)
+#define i_beqz(buf, rs, off) i_beq(buf, rs, 0, off)
 #define i_bnez(buf, rs, off) i_bne(buf, rs, 0, off)
 #define i_move(buf, a, b) i_ADDU(buf, a, 0, b)
 #define i_nop(buf) i_sll(buf, 0, 0, 0)
@@ -605,6 +631,13 @@ static void __attribute__((unused)) il_b
 	i_b(p, 0);
 }
 
+static void il_beqz(u32 **p, struct reloc **r, unsigned int reg,
+		    enum label_id l)
+{
+	r_mips_pc16(r, *p, l);
+	i_beqz(p, reg, 0);
+}
+
 static void il_bnez(u32 **p, struct reloc **r, unsigned int reg,
 		    enum label_id l)
 {
@@ -619,7 +652,7 @@ static void il_bgezl(u32 **p, struct rel
 	i_bgezl(p, reg, 0);
 }
 
-/* The only registers allowed in TLB handlers. */
+/* The only general purpose registers allowed in TLB handlers. */
 #define K0		26
 #define K1		27
 
@@ -653,7 +686,6 @@ static __initdata u32 tlb_handler[128];
 static __initdata struct label labels[128];
 static __initdata struct reloc relocs[128];
 
-#ifdef CONFIG_MIPS32
 /*
  * The R3000 TLB handler is simple.
  */
@@ -687,10 +719,11 @@ static void __init build_r3000_tlb_refil
 		panic("TLB refill handler space exceeded");
 
 	printk("Synthesized TLB handler (%u instructions).\n",
-	       p - tlb_handler);
+	       (unsigned int)(p - tlb_handler));
 #ifdef DEBUG_TLB
 	{
 		int i;
+
 		for (i = 0; i < (p - tlb_handler); i++)
 			printk("%08x\n", tlb_handler[i]);
 	}
@@ -699,7 +732,6 @@ static void __init build_r3000_tlb_refil
 	memcpy((void *)CAC_BASE, tlb_handler, 0x80);
 	flush_icache_range(CAC_BASE, CAC_BASE + 0x80);
 }
-#endif /* CONFIG_MIPS32 */
 
 /*
  * The R4000 TLB handler is much more complicated. We have two
@@ -749,12 +781,22 @@ static __init void __attribute__((unused
 }
 
 /*
- * Write random TLB entry, and care about the hazards from the
- * preceeding mtc0 and for the following eret.
+ * Write random or indexed TLB entry, and care about the hazards from
+ * the preceeding mtc0 and for the following eret.
  */
-static __init void build_tlb_write_random_entry(u32 **p, struct label **l,
-						struct reloc **r)
+enum tlb_write_entry { tlb_random, tlb_indexed };
+
+static __init void build_tlb_write_entry(u32 **p, struct label **l,
+					 struct reloc **r,
+					 enum tlb_write_entry wmode)
 {
+	void(*tlbw)(u32 **) = NULL;
+
+	switch (wmode) {
+	case tlb_random: tlbw = i_tlbwr; break;
+	case tlb_indexed: tlbw = i_tlbwi; break;
+	}
+
 	switch (current_cpu_data.cputype) {
 	case CPU_R4000PC:
 	case CPU_R4000SC:
@@ -764,11 +806,11 @@ static __init void build_tlb_write_rando
 	case CPU_R4400MC:
 		/*
 		 * This branch uses up a mtc0 hazard nop slot and saves
-		 * two nops after the tlbwr.
+		 * two nops after the tlbw instruction.
 		 */
-		il_bgezl(p, r, 0, label_tlbwr_hazard);
-		i_tlbwr(p);
-		l_tlbwr_hazard(l, *p);
+		il_bgezl(p, r, 0, label_tlbw_hazard);
+		tlbw(p);
+		l_tlbw_hazard(l, *p);
 		i_nop(p);
 		break;
 
@@ -783,7 +825,7 @@ static __init void build_tlb_write_rando
 	case CPU_AU1500:
 	case CPU_AU1550:
 		i_nop(p);
-		i_tlbwr(p);
+		tlbw(p);
 		break;
 
 	case CPU_R10000:
@@ -793,18 +835,18 @@ static __init void build_tlb_write_rando
 	case CPU_4KSC:
 	case CPU_20KC:
 	case CPU_25KF:
-		i_tlbwr(p);
+		tlbw(p);
 		break;
 
 	case CPU_NEVADA:
 		i_nop(p); /* QED specifies 2 nops hazard */
 		/*
 		 * This branch uses up a mtc0 hazard nop slot and saves
-		 * a nop after the tlbwr.
+		 * a nop after the tlbw instruction.
 		 */
-		il_bgezl(p, r, 0, label_tlbwr_hazard);
-		i_tlbwr(p);
-		l_tlbwr_hazard(l, *p);
+		il_bgezl(p, r, 0, label_tlbw_hazard);
+		tlbw(p);
+		l_tlbw_hazard(l, *p);
 		break;
 
 	case CPU_RM7000:
@@ -812,13 +854,13 @@ static __init void build_tlb_write_rando
 		i_nop(p);
 		i_nop(p);
 		i_nop(p);
-		i_tlbwr(p);
+		tlbw(p);
 		break;
 
 	case CPU_4KEC:
 	case CPU_24K:
 		i_ehb(p);
-		i_tlbwr(p);
+		tlbw(p);
 		break;
 
 	case CPU_RM9000:
@@ -832,7 +874,7 @@ static __init void build_tlb_write_rando
 		i_ssnop(p);
 		i_ssnop(p);
 		i_ssnop(p);
-		i_tlbwr(p);
+		tlbw(p);
 		i_ssnop(p);
 		i_ssnop(p);
 		i_ssnop(p);
@@ -846,7 +888,7 @@ static __init void build_tlb_write_rando
 	case CPU_VR4181A:
 		i_nop(p);
 		i_nop(p);
-		i_tlbwr(p);
+		tlbw(p);
 		i_nop(p);
 		i_nop(p);
 		break;
@@ -855,7 +897,7 @@ static __init void build_tlb_write_rando
 	case CPU_VR4133:
 		i_nop(p);
 		i_nop(p);
-		i_tlbwr(p);
+		tlbw(p);
 		break;
 
 	default:
@@ -883,7 +925,7 @@ build_get_pmde64(u32 **p, struct label *
 	il_bltz(p, r, tmp, label_vmalloc);
 	/* No i_nop needed here, since the next insn doesn't touch TMP. */
 
-# ifdef CONFIG_SMP
+#ifdef CONFIG_SMP
 	/*
 	 * 64 bit SMP has the lower part of &pgd_current[smp_processor_id()]
 	 * stored in CONTEXT.
@@ -901,10 +943,10 @@ build_get_pmde64(u32 **p, struct label *
 		i_dmfc0(p, tmp, C0_BADVADDR);
 	}
 	i_ld(p, ptr, 0, ptr);
-# else
+#else
 	i_LA_mostly(p, ptr, pgdc);
 	i_ld(p, ptr, rel_lo(pgdc), ptr);
-# endif
+#endif
 
 	l_vmalloc_done(l, *p);
 	i_dsrl(p, tmp, tmp, PGDIR_SHIFT-3); /* get pgd offset in bytes */
@@ -1094,14 +1136,14 @@ static void __init build_r4000_tlb_refil
 	}
 
 #ifdef CONFIG_MIPS64
-	build_get_pmde64(&p, &l, &r, K0, K1); /* get pmd ptr in K1 */
+	build_get_pmde64(&p, &l, &r, K0, K1); /* get pmd in K1 */
 #else
-	build_get_pgde32(&p, K0, K1); /* get pgd ptr in K1 */
+	build_get_pgde32(&p, K0, K1); /* get pgd in K1 */
 #endif
 
 	build_get_ptep(&p, K0, K1);
 	build_update_entries(&p, K0, K1);
-	build_tlb_write_random_entry(&p, &l, &r);
+	build_tlb_write_entry(&p, &l, &r, tlb_random);
 	l_leave(&l, p);
 	i_eret(&p); /* return from trap */
 
@@ -1172,7 +1214,8 @@ static void __init build_r4000_tlb_refil
 #endif /* CONFIG_MIPS64 */
 
 	resolve_relocs(relocs, labels);
-	printk("Synthesized TLB handler (%u instructions).\n", final_len);
+	printk("Synthesized TLB refill handler (%u instructions).\n",
+	       final_len);
 
 #ifdef DEBUG_TLB
 	{
@@ -1187,10 +1230,522 @@ static void __init build_r4000_tlb_refil
 	flush_icache_range(CAC_BASE, CAC_BASE + 0x100);
 }
 
+/*
+ * TLB load/store/modify handlers.
+ * 
+ * Only the fastpath gets synthesized at runtime, the slowpath for
+ * do_page_fault remains normal asm.
+ */
+extern void tlb_do_fault_nopage_0(void);
+extern void tlb_do_fault_nopage_1(void);
+
+#define __tlb_handler_align \
+	__attribute__((__aligned__(1 << CONFIG_MIPS_L1_CACHE_SHIFT)))
+
+/*
+ * 128 instructions for the fastpath handler is generous and should
+ * never be exceeded.
+ */
+#define FASTPATH_SIZE 128
+
+u32 __tlb_handler_align handle_tlbl[FASTPATH_SIZE];
+u32 __tlb_handler_align handle_tlbs[FASTPATH_SIZE];
+u32 __tlb_handler_align handle_tlbm[FASTPATH_SIZE];
+
+static void __init
+iPTE_LW(u32 **p, struct label **l, unsigned int pte, int offset,
+	unsigned int ptr)
+{
+#ifdef CONFIG_SMP
+	l_smp_pgtable_change(l, *p);
+# ifdef CONFIG_64BIT_PHYS_ADDR
+	if (cpu_has_64bit_gp_regs)
+		i_lld(p, pte, offset, ptr);
+	else
+# endif
+		i_LL(p, pte, offset, ptr);
+#else
+# ifdef CONFIG_64BIT_PHYS_ADDR
+	if (cpu_has_64bit_gp_regs)
+		i_ld(p, pte, offset, ptr);
+	else
+# endif
+		i_LW(p, pte, offset, ptr);
+#endif
+}
+
+static void __init
+iPTE_SW(u32 **p, struct reloc **r, unsigned int pte, int offset,
+	unsigned int ptr)
+{
+#ifdef CONFIG_SMP
+# ifdef CONFIG_64BIT_PHYS_ADDR
+	if (cpu_has_64bit_gp_regs)
+		i_scd(p, pte, offset, ptr);
+	else
+# endif
+		i_SC(p, pte, offset, ptr);
+
+	il_beqz(p, r, pte, label_smp_pgtable_change);
+	/* no i_nop needed */
+
+# ifdef CONFIG_64BIT_PHYS_ADDR
+	if (!cpu_has_64bit_gp_regs) {
+		i_ll(p, pte, sizeof(pte_t) / 2, ptr);
+		i_ori(p, pte, pte, _PAGE_VALID);
+		i_sc(p, pte, sizeof(pte_t) / 2, ptr);
+		il_beqz(p, r, pte, label_smp_pgtable_change);
+		/* no i_nop needed */
+		i_lw(p, pte, 0, ptr);
+	}
+# endif
+#else
+# ifdef CONFIG_64BIT_PHYS_ADDR
+	if (cpu_has_64bit_gp_regs)
+		i_sd(p, pte, offset, ptr);
+	else
+# endif
+		i_SW(p, pte, offset, ptr);
+
+# ifdef CONFIG_64BIT_PHYS_ADDR
+	if (!cpu_has_64bit_gp_regs) {
+		i_lw(p, pte, sizeof(pte_t) / 2, ptr);
+		i_ori(p, pte, pte, _PAGE_VALID);
+		i_sw(p, pte, sizeof(pte_t) / 2, ptr);
+		i_lw(p, pte, 0, ptr);
+	}
+# endif
+#endif
+}
+
+/*
+ * Check if PTE is present, if not then jump to LABEL. PTR points to
+ * the page table where this PTE is located, PTE will be re-loaded
+ * with it's original value.
+ */
+static void __init
+build_pte_present(u32 **p, struct label **l, struct reloc **r,
+		  unsigned int pte, unsigned int ptr, enum label_id lid)
+{
+	i_andi(p, pte, pte, _PAGE_PRESENT | _PAGE_READ);
+	i_xori(p, pte, pte, _PAGE_PRESENT | _PAGE_READ);
+	il_bnez(p, r, pte, lid);
+	iPTE_LW(p, l, pte, 0, ptr);
+}
+
+/* Make PTE valid, store result in PTR. */
+static void __init
+build_make_valid(u32 **p, struct reloc **r, unsigned int pte,
+		 unsigned int ptr)
+{
+	i_ori(p, pte, pte, _PAGE_VALID | _PAGE_ACCESSED);
+	iPTE_SW(p, r, pte, 0, ptr);
+}
+
+/*
+ * Check if PTE can be written to, if not branch to LABEL. Regardless
+ * restore PTE with value from PTR when done.
+ */
+static void __init
+build_pte_writable(u32 **p, struct label **l, struct reloc **r,
+		   unsigned int pte, unsigned int ptr, enum label_id lid)
+{
+	i_andi(p, pte, pte, _PAGE_PRESENT | _PAGE_WRITE);
+	i_xori(p, pte, pte, _PAGE_PRESENT | _PAGE_WRITE);
+	il_bnez(p, r, pte, lid);
+	iPTE_LW(p, l, pte, 0, ptr);
+}
+
+/* Make PTE writable, update software status bits as well, then store
+ * at PTR.
+ */
+static void __init
+build_make_write(u32 **p, struct reloc **r, unsigned int pte,
+		 unsigned int ptr)
+{
+	i_ori(p, pte, pte,
+	      _PAGE_ACCESSED | _PAGE_MODIFIED | _PAGE_VALID | _PAGE_DIRTY);
+	iPTE_SW(p, r, pte, 0, ptr);
+}
+
+/*
+ * Check if PTE can be modified, if not branch to LABEL. Regardless
+ * restore PTE with value from PTR when done.
+ */
+static void __init
+build_pte_modifiable(u32 **p, struct label **l, struct reloc **r,
+		     unsigned int pte, unsigned int ptr, enum label_id lid)
+{
+	i_andi(p, pte, pte, _PAGE_WRITE);
+	il_beqz(p, r, pte, lid);
+	iPTE_LW(p, l, pte, 0, ptr);
+}
+
+/*
+ * R3000 style TLB load/store/modify handlers.
+ */
+
+/* This places the pte in the page table at PTR into ENTRYLO0. */
+static void __init
+build_r3000_pte_reload(u32 **p, unsigned int ptr)
+{
+	i_lw(p, ptr, 0, ptr);
+	i_nop(p); /* load delay */
+	i_mtc0(p, ptr, C0_ENTRYLO0);
+	i_nop(p); /* cp0 delay */
+}
+
+/*
+ * The index register may have the probe fail bit set,
+ * because we would trap on access kseg2, i.e. without refill.
+ */
+static void __init
+build_r3000_tlb_write(u32 **p, struct label **l, struct reloc **r,
+		      unsigned int tmp)
+{
+	i_mfc0(p, tmp, C0_INDEX);
+	i_nop(p); /* cp0 delay */
+	il_bltz(p, r, tmp, label_r3000_write_probe_fail);
+	i_nop(p); /* branch delay */
+	i_tlbwi(p);
+	il_b(p, r, label_r3000_write_probe_ok);
+	i_nop(p); /* branch delay */
+	l_r3000_write_probe_fail(l, *p);
+	i_tlbwr(p);
+	l_r3000_write_probe_ok(l, *p);
+}
+
+static void __init
+build_r3000_tlbchange_handler_head(u32 **p, unsigned int pte,
+				   unsigned int ptr)
+{
+	long pgdc = (long)pgd_current;
+
+	i_mfc0(p, pte, C0_BADVADDR);
+	i_lui(p, ptr, rel_hi(pgdc)); /* cp0 delay */
+	i_lw(p, ptr, rel_lo(pgdc), ptr);
+	i_srl(p, pte, pte, 22); /* load delay */
+	i_sll(p, pte, pte, 2);
+	i_addu(p, ptr, ptr, pte);
+	i_mfc0(p, pte, C0_CONTEXT);
+	i_lw(p, ptr, 0, ptr); /* cp0 delay */
+	i_andi(p, pte, pte, 0xffc); /* load delay */
+	i_addu(p, ptr, ptr, pte);
+	i_lw(p, pte, 0, ptr);
+	i_nop(p); /* load delay */
+	i_tlbp(p);
+}
+
+static void __init
+build_r3000_tlbchange_handler_tail(u32 **p, unsigned int tmp)
+{
+	i_mfc0(p, tmp, C0_EPC);
+	i_nop(p); /* cp0 delay */
+	i_jr(p, tmp);
+	i_rfe(p); /* branch delay */
+}
+
+static void __init build_r3000_tlb_load_handler(void)
+{
+	u32 *p = handle_tlbl;
+	struct label *l = labels;
+	struct reloc *r = relocs;
+
+	memset(handle_tlbl, 0, sizeof(handle_tlbl));
+	memset(labels, 0, sizeof(labels));
+	memset(relocs, 0, sizeof(relocs));
+
+	build_r3000_tlbchange_handler_head(&p, K0, K1);
+	build_pte_present(&p, &l, &r, K0, K1, label_nopage_tlbl);
+	build_make_valid(&p, &r, K0, K1);
+	build_r3000_pte_reload(&p, K1);
+	build_r3000_tlb_write(&p, &l, &r, K0);
+	build_r3000_tlbchange_handler_tail(&p, K0);
+
+	l_nopage_tlbl(&l, p);
+	i_j(&p, (unsigned long)tlb_do_fault_nopage_0 & 0x0fffffff);
+	i_nop(&p);
+
+	if ((p - handle_tlbl) > FASTPATH_SIZE)
+		panic("TLB load handler fastpath space exceeded");
+
+	resolve_relocs(relocs, labels);
+	printk("Synthesized TLB load handler fastpath (%u instructions).\n",
+	       (unsigned int)(p - handle_tlbl));
+
+#ifdef DEBUG_TLB
+	{
+		int i;
+
+		for (i = 0; i < FASTPATH_SIZE; i++)
+			printk("%08x\n", handle_tlbl[i]);
+	}
+#endif
+
+	flush_icache_range((unsigned long)handle_tlbl,
+			   (unsigned long)handle_tlbl + FASTPATH_SIZE * sizeof(u32));
+}
+
+static void __init build_r3000_tlb_store_handler(void)
+{
+	u32 *p = handle_tlbs;
+	struct label *l = labels;
+	struct reloc *r = relocs;
+
+	memset(handle_tlbs, 0, sizeof(handle_tlbs));
+	memset(labels, 0, sizeof(labels));
+	memset(relocs, 0, sizeof(relocs));
+
+	build_r3000_tlbchange_handler_head(&p, K0, K1);
+	build_pte_writable(&p, &l, &r, K0, K1, label_nopage_tlbs);
+	build_make_write(&p, &r, K0, K1);
+	build_r3000_pte_reload(&p, K1);
+	build_r3000_tlb_write(&p, &l, &r, K0);
+	build_r3000_tlbchange_handler_tail(&p, K0);
+
+	l_nopage_tlbs(&l, p);
+	i_j(&p, (unsigned long)tlb_do_fault_nopage_1 & 0x0fffffff);
+	i_nop(&p);
+
+	if ((p - handle_tlbs) > FASTPATH_SIZE)
+		panic("TLB store handler fastpath space exceeded");
+
+	resolve_relocs(relocs, labels);
+	printk("Synthesized TLB store handler fastpath (%u instructions).\n",
+	       (unsigned int)(p - handle_tlbs));
+
+#ifdef DEBUG_TLB
+	{
+		int i;
+
+		for (i = 0; i < FASTPATH_SIZE; i++)
+			printk("%08x\n", handle_tlbs[i]);
+	}
+#endif
+
+	flush_icache_range((unsigned long)handle_tlbs,
+			   (unsigned long)handle_tlbs + FASTPATH_SIZE * sizeof(u32));
+}
+
+static void __init build_r3000_tlb_modify_handler(void)
+{
+	u32 *p = handle_tlbm;
+	struct label *l = labels;
+	struct reloc *r = relocs;
+
+	memset(handle_tlbm, 0, sizeof(handle_tlbm));
+	memset(labels, 0, sizeof(labels));
+	memset(relocs, 0, sizeof(relocs));
+
+	build_r3000_tlbchange_handler_head(&p, K0, K1);
+	build_pte_modifiable(&p, &l, &r, K0, K1, label_nopage_tlbm);
+	build_make_write(&p, &r, K0, K1);
+	build_r3000_pte_reload(&p, K1);
+	i_tlbwi(&p);
+	build_r3000_tlbchange_handler_tail(&p, K0);
+
+	l_nopage_tlbm(&l, p);
+	i_j(&p, (unsigned long)tlb_do_fault_nopage_1 & 0x0fffffff);
+	i_nop(&p);
+
+	if ((p - handle_tlbm) > FASTPATH_SIZE)
+		panic("TLB modify handler fastpath space exceeded");
+
+	resolve_relocs(relocs, labels);
+	printk("Synthesized TLB modify handler fastpath (%u instructions).\n",
+	       (unsigned int)(p - handle_tlbm));
+
+#ifdef DEBUG_TLB
+	{
+		int i;
+
+		for (i = 0; i < FASTPATH_SIZE; i++)
+			printk("%08x\n", handle_tlbm[i]);
+	}
+#endif
+
+	flush_icache_range((unsigned long)handle_tlbm,
+			   (unsigned long)handle_tlbm + FASTPATH_SIZE * sizeof(u32));
+}
+
+/*
+ * R4000 style TLB load/store/modify handlers.
+ */
+static void __init
+build_r4000_tlbchange_handler_head(u32 **p, struct label **l,
+				   struct reloc **r, unsigned int tmp,
+				   unsigned int ptr)
+{
+#ifdef CONFIG_MIPS64
+	build_get_pmde64(p, l, r, tmp, ptr); /* get pmd in ptr */
+#else
+	build_get_pgde32(p, tmp, ptr); /* get pgd in ptr */
+#endif
+
+	i_MFC0(p, tmp, C0_BADVADDR);
+	i_LW(p, ptr, 0, ptr);
+	i_SRL(p, tmp, tmp, PAGE_SHIFT - PTE_T_LOG2);
+	i_andi(p, tmp, tmp, (PTRS_PER_PTE - 1) << PTE_T_LOG2);
+	i_ADDU(p, ptr, ptr, tmp);
+
+	iPTE_LW(p, l, tmp, 0, ptr); /* get even pte */
+	build_tlb_probe_entry(p);
+}
+
+static void __init
+build_r4000_tlbchange_handler_tail(u32 **p, struct label **l,
+				   struct reloc **r, unsigned int tmp,
+				   unsigned int ptr)
+{
+	i_ori(p, ptr, ptr, sizeof(pte_t));
+	i_xori(p, ptr, ptr, sizeof(pte_t));
+	build_update_entries(p, tmp, ptr);
+	build_tlb_write_entry(p, l, r, tlb_indexed);
+	l_leave(l, *p);
+	i_eret(p); /* return from trap */
+
+#ifdef CONFIG_MIPS64
+	build_get_pgd_vmalloc64(p, l, r, tmp, ptr);
+#endif
+}
+
+static void __init build_r4000_tlb_load_handler(void)
+{
+	u32 *p = handle_tlbl;
+	struct label *l = labels;
+	struct reloc *r = relocs;
+
+	memset(handle_tlbl, 0, sizeof(handle_tlbl));
+	memset(labels, 0, sizeof(labels));
+	memset(relocs, 0, sizeof(relocs));
+
+	if (bcm1250_m3_war()) {
+		i_MFC0(&p, K0, C0_BADVADDR);
+		i_MFC0(&p, K1, C0_ENTRYHI);
+		i_xor(&p, K0, K0, K1);
+		i_SRL(&p, K0, K0, PAGE_SHIFT+1);
+		il_bnez(&p, &r, K0, label_leave);
+		/* No need for i_nop */
+	}
+
+	build_r4000_tlbchange_handler_head(&p, &l, &r, K0, K1);
+	build_pte_present(&p, &l, &r, K0, K1, label_nopage_tlbl);
+	build_make_valid(&p, &r, K0, K1);
+	build_r4000_tlbchange_handler_tail(&p, &l, &r, K0, K1);
+
+	l_nopage_tlbl(&l, p);
+	i_j(&p, (unsigned long)tlb_do_fault_nopage_0 & 0x0fffffff);
+	i_nop(&p);
+
+	if ((p - handle_tlbl) > FASTPATH_SIZE)
+		panic("TLB load handler fastpath space exceeded");
+
+	resolve_relocs(relocs, labels);
+	printk("Synthesized TLB load handler fastpath (%u instructions).\n",
+	       (unsigned int)(p - handle_tlbl));
+
+#ifdef DEBUG_TLB
+	{
+		int i;
+
+		for (i = 0; i < FASTPATH_SIZE; i++)
+			printk("%08x\n", handle_tlbl[i]);
+	}
+#endif
+
+	flush_icache_range((unsigned long)handle_tlbl,
+			   (unsigned long)handle_tlbl + FASTPATH_SIZE * sizeof(u32));
+}
+
+static void __init build_r4000_tlb_store_handler(void)
+{
+	u32 *p = handle_tlbs;
+	struct label *l = labels;
+	struct reloc *r = relocs;
+
+	memset(handle_tlbs, 0, sizeof(handle_tlbs));
+	memset(labels, 0, sizeof(labels));
+	memset(relocs, 0, sizeof(relocs));
+
+	build_r4000_tlbchange_handler_head(&p, &l, &r, K0, K1);
+	build_pte_writable(&p, &l, &r, K0, K1, label_nopage_tlbs);
+	build_make_write(&p, &r, K0, K1);
+	build_r4000_tlbchange_handler_tail(&p, &l, &r, K0, K1);
+
+	l_nopage_tlbs(&l, p);
+	i_j(&p, (unsigned long)tlb_do_fault_nopage_1 & 0x0fffffff);
+	i_nop(&p);
+
+	if ((p - handle_tlbs) > FASTPATH_SIZE)
+		panic("TLB store handler fastpath space exceeded");
+
+	resolve_relocs(relocs, labels);
+	printk("Synthesized TLB store handler fastpath (%u instructions).\n",
+	       (unsigned int)(p - handle_tlbs));
+
+#ifdef DEBUG_TLB
+	{
+		int i;
+
+		for (i = 0; i < FASTPATH_SIZE; i++)
+			printk("%08x\n", handle_tlbs[i]);
+	}
+#endif
+
+	flush_icache_range((unsigned long)handle_tlbs,
+			   (unsigned long)handle_tlbs + FASTPATH_SIZE * sizeof(u32));
+}
+
+static void __init build_r4000_tlb_modify_handler(void)
+{
+	u32 *p = handle_tlbm;
+	struct label *l = labels;
+	struct reloc *r = relocs;
+
+	memset(handle_tlbm, 0, sizeof(handle_tlbm));
+	memset(labels, 0, sizeof(labels));
+	memset(relocs, 0, sizeof(relocs));
+
+	build_r4000_tlbchange_handler_head(&p, &l, &r, K0, K1);
+	build_pte_modifiable(&p, &l, &r, K0, K1, label_nopage_tlbm);
+	/* Present and writable bits set, set accessed and dirty bits. */
+	build_make_write(&p, &r, K0, K1);
+	build_r4000_tlbchange_handler_tail(&p, &l, &r, K0, K1);
+
+	l_nopage_tlbm(&l, p);
+	i_j(&p, (unsigned long)tlb_do_fault_nopage_1 & 0x0fffffff);
+	i_nop(&p);
+
+	if ((p - handle_tlbm) > FASTPATH_SIZE)
+		panic("TLB modify handler fastpath space exceeded");
+
+	resolve_relocs(relocs, labels);
+	printk("Synthesized TLB modify handler fastpath (%u instructions).\n",
+	       (unsigned int)(p - handle_tlbm));
+
+#ifdef DEBUG_TLB
+	{
+		int i;
+
+		for (i = 0; i < FASTPATH_SIZE; i++)
+			printk("%08x\n", handle_tlbm[i]);
+	}
+#endif
+
+	flush_icache_range((unsigned long)handle_tlbm,
+			   (unsigned long)handle_tlbm + FASTPATH_SIZE * sizeof(u32));
+}
+
 void __init build_tlb_refill_handler(void)
 {
+	/*
+	 * The refill handler is generated per-CPU, multi-node systems
+	 * may have local storage for it. The other handlers are only
+	 * needed once.
+	 */
+	static int run_once = 0;
+
 	switch (current_cpu_data.cputype) {
-#ifdef CONFIG_MIPS32
 	case CPU_R2000:
 	case CPU_R3000:
 	case CPU_R3000A:
@@ -1199,13 +1754,18 @@ void __init build_tlb_refill_handler(voi
 	case CPU_TX3922:
 	case CPU_TX3927:
 		build_r3000_tlb_refill_handler();
+		if (!run_once) {
+			build_r3000_tlb_load_handler();
+			build_r3000_tlb_store_handler();
+			build_r3000_tlb_modify_handler();
+			run_once++;
+		}
 		break;
 
 	case CPU_R6000:
 	case CPU_R6000A:
 		panic("No R6000 TLB refill handler yet");
 		break;
-#endif
 
 	case CPU_R8000:
 		panic("No R8000 TLB refill handler yet");
@@ -1213,5 +1773,11 @@ void __init build_tlb_refill_handler(voi
 
 	default:
 		build_r4000_tlb_refill_handler();
+		if (!run_once) {
+			build_r4000_tlb_load_handler();
+			build_r4000_tlb_store_handler();
+			build_r4000_tlb_modify_handler();
+			run_once++;
+		}
 	}
 }
Index: arch/mips/mm/tlbex32-mips32.S
===================================================================
RCS file: arch/mips/mm/tlbex32-mips32.S
diff -N arch/mips/mm/tlbex32-mips32.S
--- arch/mips/mm/tlbex32-mips32.S	9 Dec 2004 15:16:52 -0000	1.4
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,250 +0,0 @@
-/*
- * TLB exception handling code for MIPS32 CPUs.
- *
- * Copyright (C) 1994, 1995, 1996 by Ralf Baechle and Andreas Busse
- *
- * Multi-cpu abstraction and reworking:
- * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com)
- *
- * Carsten Langgaard, carstenl@mips.com
- * Copyright (C) 2000 MIPS Technologies, Inc.  All rights reserved.
- *
- * Pete Popov, ppopov@pacbell.net
- * Added 36 bit phys address support.
- * Copyright (C) 2002 MontaVista Software, Inc.
- */
-#include <linux/init.h>
-#include <asm/asm.h>
-#include <asm/cachectl.h>
-#include <asm/fpregdef.h>
-#include <asm/mipsregs.h>
-#include <asm/page.h>
-#include <asm/pgtable-bits.h>
-#include <asm/regdef.h>
-#include <asm/stackframe.h>
-
-#define TLB_OPTIMIZE /* If you are paranoid, disable this. */
-
-#ifdef CONFIG_64BIT_PHYS_ADDR
-
-/* We really only support 36 bit physical addresses on MIPS32 */
-#define PTE_L		lw
-#define PTE_S		sw
-#define PTE_SRL		srl
-#define P_MTC0		mtc0
-#define PTE_HALF        4 /* pte_high contains pre-shifted, ready to go entry */
-#define PTE_SIZE        8
-#define PTEP_INDX_MSK	0xff0
-#define PTE_INDX_MSK	0xff8
-#define PTE_INDX_SHIFT 9
-#define CONVERT_PTE(pte)
-#define PTE_MAKEWRITE_HIGH(pte, ptr) \
-	lw	pte, PTE_HALF(ptr); \
-	ori	pte, (_PAGE_VALID | _PAGE_DIRTY); \
-	sw	pte, PTE_HALF(ptr); \
-	lw	pte, 0(ptr);
-
-#define PTE_MAKEVALID_HIGH(pte, ptr) \
-	lw	pte, PTE_HALF(ptr); \
-	ori	pte, pte, _PAGE_VALID; \
-	sw	pte, PTE_HALF(ptr); \
-	lw	pte, 0(ptr);
-
-#else
-
-#define PTE_L		lw
-#define PTE_S		sw
-#define PTE_SRL		srl
-#define P_MTC0		mtc0
-#define PTE_HALF        0
-#define PTE_SIZE	4
-#define PTEP_INDX_MSK	0xff8
-#define PTE_INDX_MSK	0xffc
-#define PTE_INDX_SHIFT	10
-#define CONVERT_PTE(pte) srl pte, pte, 6
-#define PTE_MAKEWRITE_HIGH(pte, ptr)
-#define PTE_MAKEVALID_HIGH(pte, ptr)
-
-#endif  /* CONFIG_64BIT_PHYS_ADDR */
-
-#ifdef CONFIG_64BIT_PHYS_ADDR
-#define GET_PTE_OFF(reg)
-#else
-#define GET_PTE_OFF(reg)	srl	reg, reg, 1
-#endif
-
-/*
- * ABUSE of CPP macros 101.
- *
- * After this macro runs, the pte faulted on is
- * in register PTE, a ptr into the table in which
- * the pte belongs is in PTR.
- */
-
-#ifdef CONFIG_SMP
-#define GET_PGD(scratch, ptr)        \
-	mfc0    ptr, CP0_CONTEXT;    \
-	la      scratch, pgd_current;\
-	srl     ptr, 23;             \
-	sll     ptr, 2;              \
-	addu    ptr, scratch, ptr;   \
-	lw      ptr, (ptr);
-#else
-#define GET_PGD(scratch, ptr)    \
-	lw	ptr, pgd_current;
-#endif
-
-#define LOAD_PTE(pte, ptr) \
-	GET_PGD(pte, ptr)          \
-	mfc0	pte, CP0_BADVADDR; \
-	srl	pte, pte, _PGDIR_SHIFT; \
-	sll	pte, pte, 2; \
-	addu	ptr, ptr, pte; \
-	mfc0	pte, CP0_BADVADDR; \
-	lw	ptr, (ptr); \
-	srl	pte, pte, PTE_INDX_SHIFT; \
-	and	pte, pte, PTE_INDX_MSK; \
-	addu	ptr, ptr, pte; \
-	PTE_L	pte, (ptr);
-
-	/* This places the even/odd pte pair in the page
-	 * table at PTR into ENTRYLO0 and ENTRYLO1 using
-	 * TMP as a scratch register.
-	 */
-#define PTE_RELOAD(ptr, tmp) \
-	ori	ptr, ptr, PTE_SIZE; \
-	xori	ptr, ptr, PTE_SIZE; \
-	PTE_L	tmp, (PTE_HALF+PTE_SIZE)(ptr); \
-	CONVERT_PTE(tmp); \
-	P_MTC0	tmp, CP0_ENTRYLO1; \
-	PTE_L	ptr, PTE_HALF(ptr); \
-	CONVERT_PTE(ptr); \
-	P_MTC0	ptr, CP0_ENTRYLO0;
-
-#define DO_FAULT(write) \
-	SAVE_ALL; \
-	mfc0	a2, CP0_BADVADDR; \
-	KMODE; \
-	move	a0, sp; \
-	sw	a2, PT_BVADDR(sp); \
-	jal	do_page_fault; \
-	 li	a1, write; \
-	j	ret_from_exception; \
-	 nop;
-
-	/* Check is PTE is present, if not then jump to LABEL.
-	 * PTR points to the page table where this PTE is located,
-	 * when the macro is done executing PTE will be restored
-	 * with it's original value.
-	 */
-#define PTE_PRESENT(pte, ptr, label) \
-	andi	pte, pte, (_PAGE_PRESENT | _PAGE_READ); \
-	xori	pte, pte, (_PAGE_PRESENT | _PAGE_READ); \
-	bnez	pte, label; \
-	PTE_L	pte, (ptr);
-
-	/* Make PTE valid, store result in PTR. */
-#define PTE_MAKEVALID(pte, ptr) \
-	ori	pte, pte, (_PAGE_VALID | _PAGE_ACCESSED); \
-	PTE_S	pte, (ptr);
-
-	/* Check if PTE can be written to, if not branch to LABEL.
-	 * Regardless restore PTE with value from PTR when done.
-	 */
-#define PTE_WRITABLE(pte, ptr, label) \
-	andi	pte, pte, (_PAGE_PRESENT | _PAGE_WRITE); \
-	xori	pte, pte, (_PAGE_PRESENT | _PAGE_WRITE); \
-	bnez	pte, label; \
-	PTE_L	pte, (ptr);
-
-	/* Make PTE writable, update software status bits as well,
-	 * then store at PTR.
-	 */
-#define PTE_MAKEWRITE(pte, ptr) \
-	ori	pte, pte, (_PAGE_ACCESSED | _PAGE_MODIFIED | \
-			   _PAGE_VALID | _PAGE_DIRTY); \
-	PTE_S	pte, (ptr);
-
-	.set	noreorder
-	.set	noat
-
-	.align	5
-	NESTED(handle_tlbl, PT_SIZE, sp)
-
-#ifdef TLB_OPTIMIZE
-	/* Test present bit in entry. */
-	LOAD_PTE(k0, k1)
-	tlbp
-	PTE_PRESENT(k0, k1, nopage_tlbl)
-	PTE_MAKEVALID_HIGH(k0, k1)
-	PTE_MAKEVALID(k0, k1)
-	PTE_RELOAD(k1, k0)
-	nop
-	b	1f
-	 tlbwi
-1:
-	nop
-	.set	mips3
-	eret
-	.set	mips0
-nopage_tlbl:
-#endif
-
-	DO_FAULT(0)
-	END(handle_tlbl)
-
-	.align	5
-	NESTED(handle_tlbs, PT_SIZE, sp)
-
-#ifdef TLB_OPTIMIZE
-	.set	mips3
-	LOAD_PTE(k0, k1)
-	tlbp				# find faulting entry
-	PTE_WRITABLE(k0, k1, nopage_tlbs)
-	PTE_MAKEWRITE(k0, k1)
-	PTE_MAKEWRITE_HIGH(k0, k1)
-	PTE_RELOAD(k1, k0)
-	nop
-	b	1f
-	 tlbwi
-1:
-	nop
-	.set	mips3
-	eret
-	.set	mips0
-nopage_tlbs:
-#endif
-
-	DO_FAULT(1)
-	END(handle_tlbs)
-
-	.align	5
-	NESTED(handle_mod, PT_SIZE, sp)
-
-#ifdef TLB_OPTIMIZE
-	.set	mips3
-	LOAD_PTE(k0, k1)
-	tlbp					# find faulting entry
-	andi	k0, k0, _PAGE_WRITE
-	beqz	k0, nowrite_mod
-	PTE_L	k0, (k1)
-
-	/* Present and writable bits set, set accessed and dirty bits. */
-	PTE_MAKEWRITE(k0, k1)
-	PTE_MAKEWRITE_HIGH(k0, k1)
-	/* Now reload the entry into the tlb. */
-	PTE_RELOAD(k1, k0)
-	nop
-	b	1f
-	 tlbwi
-1:
-	nop
-	.set	mips3
-	eret
-	.set	mips0
-nowrite_mod:
-#endif
-
-	DO_FAULT(1)
-	END(handle_mod)
-
Index: arch/mips/mm/tlbex32-r3k.S
===================================================================
RCS file: arch/mips/mm/tlbex32-r3k.S
diff -N arch/mips/mm/tlbex32-r3k.S
--- arch/mips/mm/tlbex32-r3k.S	9 Dec 2004 15:16:52 -0000	1.5
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,187 +0,0 @@
-/*
- * TLB exception handling code for R2000/R3000.
- *
- * Copyright (C) 1994, 1995, 1996 by Ralf Baechle and Andreas Busse
- *
- * Multi-CPU abstraction reworking:
- * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com)
- *
- * Further modifications to make this work:
- * Copyright (c) 1998 Harald Koerfgen
- * Copyright (c) 1998, 1999 Gleb Raiko & Vladimir Roganov
- * Copyright (c) 2001 Ralf Baechle
- * Copyright (c) 2001 MIPS Technologies, Inc.
- */
-#include <linux/init.h>
-#include <asm/asm.h>
-#include <asm/cachectl.h>
-#include <asm/fpregdef.h>
-#include <asm/mipsregs.h>
-#include <asm/page.h>
-#include <asm/pgtable-bits.h>
-#include <asm/regdef.h>
-#include <asm/stackframe.h>
-
-#define TLB_OPTIMIZE /* If you are paranoid, disable this. */
-
-	/* ABUSE of CPP macros 101. */
-
-	/* After this macro runs, the pte faulted on is
-	 * in register PTE, a ptr into the table in which
-	 * the pte belongs is in PTR.
-	 */
-#define LOAD_PTE(pte, ptr) \
-	mfc0	pte, CP0_BADVADDR; \
-	lw	ptr, pgd_current; \
-	srl	pte, pte, 22; \
-	sll	pte, pte, 2; \
-	addu	ptr, ptr, pte; \
-	mfc0	pte, CP0_CONTEXT; \
-	lw	ptr, (ptr); \
-	andi	pte, pte, 0xffc; \
-	addu	ptr, ptr, pte; \
-	lw	pte, (ptr); \
-	nop;
-
-	/* This places the pte in the page table at PTR into ENTRYLO0. */
-#define PTE_RELOAD(ptr) \
-	lw	ptr, (ptr)	; \
-	nop			; \
-	mtc0	ptr, CP0_ENTRYLO0; \
-	nop;
-
-#define DO_FAULT(write) \
-	SAVE_ALL; \
-	mfc0	a2, CP0_BADVADDR; \
-	KMODE; \
-	move	a0, sp; \
-	sw	a2, PT_BVADDR(sp); \
-	jal	do_page_fault; \
-	 li	a1, write; \
-	j	ret_from_exception; \
-	 nop;
-
-	/* Check is PTE is present, if not then jump to LABEL.
-	 * PTR points to the page table where this PTE is located,
-	 * when the macro is done executing PTE will be restored
-	 * with it's original value.
-	 */
-#define PTE_PRESENT(pte, ptr, label) \
-	andi	pte, pte, (_PAGE_PRESENT | _PAGE_READ); \
-	xori	pte, pte, (_PAGE_PRESENT | _PAGE_READ); \
-	bnez	pte, label; \
-	.set	push;       \
-	.set	reorder;    \
-	 lw	pte, (ptr); \
-	.set	pop;
-
-	/* Make PTE valid, store result in PTR. */
-#define PTE_MAKEVALID(pte, ptr) \
-	ori	pte, pte, (_PAGE_VALID | _PAGE_ACCESSED); \
-	sw	pte, (ptr);
-
-	/* Check if PTE can be written to, if not branch to LABEL.
-	 * Regardless restore PTE with value from PTR when done.
-	 */
-#define PTE_WRITABLE(pte, ptr, label) \
-	andi	pte, pte, (_PAGE_PRESENT | _PAGE_WRITE); \
-	xori	pte, pte, (_PAGE_PRESENT | _PAGE_WRITE); \
-	bnez	pte, label; \
-	.set    push;       \
-	.set    reorder;    \
-	lw      pte, (ptr); \
-	.set    pop;
-
-
-	/* Make PTE writable, update software status bits as well,
-	 * then store at PTR.
-	 */
-#define PTE_MAKEWRITE(pte, ptr) \
-	ori	pte, pte, (_PAGE_ACCESSED | _PAGE_MODIFIED | \
-			   _PAGE_VALID | _PAGE_DIRTY); \
-	sw	pte, (ptr);
-
-/*
- * The index register may have the probe fail bit set,
- * because we would trap on access kseg2, i.e. without refill.
- */
-#define TLB_WRITE(reg) \
-	mfc0	reg, CP0_INDEX; \
-	nop; \
-	bltz    reg, 1f; \
-	 nop; \
-	tlbwi; \
-	j	2f; \
-	 nop; \
-1:	tlbwr; \
-2:
-
-#define RET(reg) \
-	mfc0	reg, CP0_EPC; \
-	nop; \
-	jr	reg; \
-	 rfe
-
-	.set	noreorder
-	.set	noat
-
-	.align	5
-NESTED(handle_tlbl, PT_SIZE, sp)
-
-#ifdef TLB_OPTIMIZE
-	/* Test present bit in entry. */
-	LOAD_PTE(k0, k1)
-        tlbp
-        PTE_PRESENT(k0, k1, nopage_tlbl)
-        PTE_MAKEVALID(k0, k1)
-        PTE_RELOAD(k1)
-	TLB_WRITE(k0)
-	RET(k0)
-nopage_tlbl:
-#endif
-
-	DO_FAULT(0)
-END(handle_tlbl)
-
-	.align	5
-NESTED(handle_tlbs, PT_SIZE, sp)
-
-#ifdef TLB_OPTIMIZE
-	LOAD_PTE(k0, k1)
-	tlbp                            # find faulting entry
-	PTE_WRITABLE(k0, k1, nopage_tlbs)
-	PTE_MAKEWRITE(k0, k1)
-	PTE_RELOAD(k1)
-	TLB_WRITE(k0)
-	RET(k0)
-nopage_tlbs:
-#endif
-
-	DO_FAULT(1)
-END(handle_tlbs)
-
-	.align	5
-NESTED(handle_mod, PT_SIZE, sp)
-
-#ifdef TLB_OPTIMIZE
-	LOAD_PTE(k0, k1)
-	tlbp					# find faulting entry
-	andi	k0, k0, _PAGE_WRITE
-	beqz	k0, nowrite_mod
-	.set	push
-	.set    reorder
-	lw	k0, (k1)
-	.set    pop
-
-	/* Present and writable bits set, set accessed and dirty bits. */
-	PTE_MAKEWRITE(k0, k1)
-
-	/* Now reload the entry into the tlb. */
-	PTE_RELOAD(k1)
-	tlbwi
-	RET(k0)
-nowrite_mod:
-#endif
-
-	DO_FAULT(1)
-END(handle_mod)
Index: arch/mips/mm/tlbex32-r4k.S
===================================================================
RCS file: arch/mips/mm/tlbex32-r4k.S
diff -N arch/mips/mm/tlbex32-r4k.S
--- arch/mips/mm/tlbex32-r4k.S	9 Dec 2004 15:16:52 -0000	1.5
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,256 +0,0 @@
-/*
- * TLB exception handling code for r4k.
- *
- * Copyright (C) 1994, 1995, 1996 by Ralf Baechle and Andreas Busse
- *
- * Multi-cpu abstraction and reworking:
- * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com)
- *
- * Carsten Langgaard, carstenl@mips.com
- * Copyright (C) 2000 MIPS Technologies, Inc.  All rights reserved.
- */
-#include <linux/init.h>
-#include <linux/config.h>
-
-#include <asm/asm.h>
-#include <asm/offset.h>
-#include <asm/cachectl.h>
-#include <asm/fpregdef.h>
-#include <asm/mipsregs.h>
-#include <asm/page.h>
-#include <asm/pgtable-bits.h>
-#include <asm/regdef.h>
-#include <asm/stackframe.h>
-#include <asm/war.h>
-
-#define TLB_OPTIMIZE /* If you are paranoid, disable this. */
-
-#ifdef CONFIG_64BIT_PHYS_ADDR
-#define PTE_L		ld
-#define PTE_S		sd
-#define PTE_SRL		dsrl
-#define P_MTC0		dmtc0
-#define PTE_SIZE	8
-#define PTEP_INDX_MSK	0xff0
-#define PTE_INDX_MSK	0xff8
-#define PTE_INDX_SHIFT	9
-#else
-#define PTE_L		lw
-#define PTE_S		sw
-#define PTE_SRL		srl
-#define P_MTC0		mtc0
-#define PTE_SIZE	4
-#define PTEP_INDX_MSK	0xff8
-#define PTE_INDX_MSK	0xffc
-#define PTE_INDX_SHIFT	10
-#endif
-
-/*
- * ABUSE of CPP macros 101.
- *
- * After this macro runs, the pte faulted on is
- * in register PTE, a ptr into the table in which
- * the pte belongs is in PTR.
- */
-
-#ifdef CONFIG_SMP
-#define GET_PGD(scratch, ptr)        \
-	mfc0    ptr, CP0_CONTEXT;    \
-	la      scratch, pgd_current;\
-	srl     ptr, 23;             \
-	sll     ptr, 2;              \
-	addu    ptr, scratch, ptr;   \
-	lw      ptr, (ptr);
-#else
-#define GET_PGD(scratch, ptr)    \
-	lw	ptr, pgd_current;
-#endif
-
-#define LOAD_PTE(pte, ptr) \
-	GET_PGD(pte, ptr)          \
-	mfc0	pte, CP0_BADVADDR; \
-	srl	pte, pte, _PGDIR_SHIFT; \
-	sll	pte, pte, 2; \
-	addu	ptr, ptr, pte; \
-	mfc0	pte, CP0_BADVADDR; \
-	lw	ptr, (ptr); \
-	srl	pte, pte, PTE_INDX_SHIFT; \
-	and	pte, pte, PTE_INDX_MSK; \
-	addu	ptr, ptr, pte; \
-	PTE_L	pte, (ptr);
-
-	/* This places the even/odd pte pair in the page
-	 * table at PTR into ENTRYLO0 and ENTRYLO1 using
-	 * TMP as a scratch register.
-	 */
-#define PTE_RELOAD(ptr, tmp) \
-	ori	ptr, ptr, PTE_SIZE; \
-	xori	ptr, ptr, PTE_SIZE; \
-	PTE_L	tmp, PTE_SIZE(ptr); \
-	PTE_L	ptr, 0(ptr); \
-	PTE_SRL	tmp, tmp, 6; \
-	P_MTC0	tmp, CP0_ENTRYLO1; \
-	PTE_SRL	ptr, ptr, 6; \
-	P_MTC0	ptr, CP0_ENTRYLO0;
-
-#define DO_FAULT(write) \
-	SAVE_ALL; \
-	mfc0	a2, CP0_BADVADDR; \
-	KMODE; \
-	move	a0, sp; \
-	sw	a2, PT_BVADDR(sp); \
-	jal	do_page_fault; \
-	 li	a1, write; \
-	j	ret_from_exception; \
-	 nop;
-
-	/* Check if PTE is present, if not then jump to LABEL.
-	 * PTR points to the page table where this PTE is located,
-	 * when the macro is done executing PTE will be restored
-	 * with it's original value.
-	 */
-#define PTE_PRESENT(pte, ptr, label) \
-	andi	pte, pte, (_PAGE_PRESENT | _PAGE_READ); \
-	xori	pte, pte, (_PAGE_PRESENT | _PAGE_READ); \
-	bnez	pte, label; \
-	 PTE_L	pte, (ptr);
-
-	/* Make PTE valid, store result in PTR. */
-#define PTE_MAKEVALID(pte, ptr) \
-	ori	pte, pte, (_PAGE_VALID | _PAGE_ACCESSED); \
-	PTE_S	pte, (ptr);
-
-	/* Check if PTE can be written to, if not branch to LABEL.
-	 * Regardless restore PTE with value from PTR when done.
-	 */
-#define PTE_WRITABLE(pte, ptr, label) \
-	andi	pte, pte, (_PAGE_PRESENT | _PAGE_WRITE); \
-	xori	pte, pte, (_PAGE_PRESENT | _PAGE_WRITE); \
-	bnez	pte, label; \
-	 PTE_L	pte, (ptr);
-
-	/* Make PTE writable, update software status bits as well,
-	 * then store at PTR.
-	 */
-#define PTE_MAKEWRITE(pte, ptr) \
-	ori	pte, pte, (_PAGE_ACCESSED | _PAGE_MODIFIED | \
-			   _PAGE_VALID | _PAGE_DIRTY); \
-	PTE_S	pte, (ptr);
-
-
-	.set	noreorder
-	.set	noat
-
-/*
- * From the IDT errata for the QED RM5230 (Nevada), processor revision 1.0:
- * 2. A timing hazard exists for the TLBP instruction.
- *
- *      stalling_instruction
- *      TLBP
- *
- * The JTLB is being read for the TLBP throughout the stall generated by the
- * previous instruction. This is not really correct as the stalling instruction
- * can modify the address used to access the JTLB.  The failure symptom is that
- * the TLBP instruction will use an address created for the stalling instruction
- * and not the address held in C0_ENHI and thus report the wrong results.
- *
- * The software work-around is to not allow the instruction preceding the TLBP
- * to stall - make it an NOP or some other instruction guaranteed not to stall.
- *
- * Errata 2 will not be fixed.  This errata is also on the R5000.
- *
- * As if we MIPS hackers wouldn't know how to nop pipelines happy ...
- */
-#define R5K_HAZARD nop
-
-	/*
-	 * Note for many R4k variants tlb probes cannot be executed out
-	 * of the instruction cache else you get bogus results.
-	 */
-	.align	5
-	NESTED(handle_tlbl, PT_SIZE, sp)
-#if BCM1250_M3_WAR
-	mfc0	k0, CP0_BADVADDR
-	mfc0	k1, CP0_ENTRYHI
-	xor	k0, k1
-	srl	k0, k0, PAGE_SHIFT+1
-	beqz	k0, 1f
-	 nop
-	.set	mips3
-	eret
-	.set	mips0
-1:
-#endif
-#ifdef TLB_OPTIMIZE
-	.set	mips3
-	/* Test present bit in entry. */
-	LOAD_PTE(k0, k1)
-	R5K_HAZARD
-	tlbp
-	PTE_PRESENT(k0, k1, nopage_tlbl)
-	PTE_MAKEVALID(k0, k1)
-	PTE_RELOAD(k1, k0)
-	mtc0_tlbw_hazard
-	tlbwi
-	nop
-	tlbw_eret_hazard
-	.set	mips3
-	eret
-	.set	mips0
-#endif
-
-nopage_tlbl:
-	DO_FAULT(0)
-	END(handle_tlbl)
-
-	.align	5
-	NESTED(handle_tlbs, PT_SIZE, sp)
-#ifdef TLB_OPTIMIZE
-	.set	mips3
-	LOAD_PTE(k0, k1)
-	R5K_HAZARD
-	tlbp				# find faulting entry
-	PTE_WRITABLE(k0, k1, nopage_tlbs)
-	PTE_MAKEWRITE(k0, k1)
-	PTE_RELOAD(k1, k0)
-	mtc0_tlbw_hazard
-	tlbwi
-	nop
-	tlbw_eret_hazard
-	.set	mips3
-	eret
-	.set	mips0
-#endif
-
-nopage_tlbs:
-	DO_FAULT(1)
-	END(handle_tlbs)
-
-	.align	5
-	NESTED(handle_mod, PT_SIZE, sp)
-#ifdef TLB_OPTIMIZE
-	.set	mips3
-	LOAD_PTE(k0, k1)
-	R5K_HAZARD
-	tlbp					# find faulting entry
-	andi	k0, k0, _PAGE_WRITE
-	beqz	k0, nowrite_mod
-	 PTE_L	k0, (k1)
-
-	/* Present and writable bits set, set accessed and dirty bits. */
-	PTE_MAKEWRITE(k0, k1)
-
-	/* Now reload the entry into the tlb. */
-	PTE_RELOAD(k1, k0)
-	mtc0_tlbw_hazard
-	tlbwi
-	nop
-	tlbw_eret_hazard
-	.set	mips3
-	eret
-	.set	mips0
-#endif
-
-nowrite_mod:
-	DO_FAULT(1)
-	END(handle_mod)
Index: arch/mips/mm/tlbex64.S
===================================================================
RCS file: arch/mips/mm/tlbex64.S
diff -N arch/mips/mm/tlbex64.S
--- arch/mips/mm/tlbex64.S	9 Dec 2004 15:13:45 -0000	1.1
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,41 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 1999 Ralf Baechle
- * Copyright (C) 1999 Silicon Graphics, Inc.
- */
-#include <linux/init.h>
-#include <asm/mipsregs.h>
-#include <asm/page.h>
-#include <asm/regdef.h>
-#include <asm/stackframe.h>
-#include <asm/war.h>
-
-	.macro	tlb_handler name writebit
-	NESTED(__\name, PT_SIZE, sp)
-#if BCM1250_M3_WAR
-	dmfc0	k0, CP0_BADVADDR
-	dmfc0	k1, CP0_ENTRYHI
-	xor	k0, k1
-	dsrl	k0, k0, PAGE_SHIFT + 1
-	bnez	k0, 1f
-#endif
-	SAVE_ALL
-	dmfc0	a2, CP0_BADVADDR
-	KMODE
-	li	a1, \writebit
-	sd	a2, PT_BVADDR(sp)
-	move	a0, sp
-	jal	do_page_fault
-#if BCM1250_M3_WAR
-1:
-#endif
-	j	ret_from_exception
-	END(__\name)
-	.endm
-
-	tlb_handler	xtlb_mod 1
-	tlb_handler	xtlb_tlbl 0
-	tlb_handler	xtlb_tlbs 1

From usha@hellosoft.com Wed Dec 22 23:10:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Dec 2004 23:10:50 +0000 (GMT)
Received: from xmail.fiasj.net ([IPv6:::ffff:208.232.76.23]:27909 "EHLO
	xmail.fiasj.net") by linux-mips.org with ESMTP id <S8225248AbULVXKq>;
	Wed, 22 Dec 2004 23:10:46 +0000
Received: from USHANEW [66.237.41.195] by xmail.fiasj.net with ESMTP
  (SMTPD32-8.14) id AE849690084; Wed, 22 Dec 2004 15:08:52 -0800
From: "usha" <usha@hellosoft.com>
To: <earlm@mips.com>, <ddaney@avtrex.com>, <linux-mips@linux-mips.org>
Cc: <chris@mips.com>
Subject: MIPS linux kernel for Malta board
Date: Fri, 22 Oct 2004 15:10:43 -0700
Message-ID: <000001c4b883$f99c67a0$7d01a8c0@hellosoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C4B849.4D3D8FA0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Return-Path: <usha@hellosoft.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: 6746
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: usha@hellosoft.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C4B849.4D3D8FA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

   I am looking for the right Cross-compiler and Binutility tools to =
build a
kernel image for MIPS Malta board. The kernel source version is
linux-2.4.18. Also please provide the configuration file.

Thank you,

 Usha Davuluri.


------=_NextPart_000_0001_01C4B849.4D3D8FA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi all,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; I am looking for the right =
Cross-compiler and Binutility
tools to build a kernel image for MIPS Malta board. The kernel source =
version
is linux-2.4.18. Also please provide the configuration =
file.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thank you,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;Usha Davuluri.</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C4B849.4D3D8FA0--



From ppopov@embeddedalley.com Thu Dec 23 00:24:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Dec 2004 00:24:43 +0000 (GMT)
Received: from pimout3-ext.prodigy.net ([IPv6:::ffff:207.115.63.102]:15313
	"EHLO pimout3-ext.prodigy.net") by linux-mips.org with ESMTP
	id <S8225249AbULWAYh> convert rfc822-to-8bit; Thu, 23 Dec 2004 00:24:37 +0000
Received: from 127.0.0.1 (adsl-68-124-224-225.dsl.snfc21.pacbell.net [68.124.224.225])
	by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id iBN0ONLN340268
	for <linux-mips@linux-mips.org>; Wed, 22 Dec 2004 19:24:25 -0500
Received: from  [64.163.129.139] by 127.0.0.1
  (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.7)); Wed, 22 Dec 2004 16:24:01 -0800
From: Pete Popov <ppopov@embeddedalley.com>
To: usha <usha@hellosoft.com>
CC: <earlm@mips.com>, <ddaney@avtrex.com>, <linux-mips@linux-mips.org>
Subject: RE: MIPS linux kernel for Malta board
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Message-ID: <kh2c0foho7bmc2c.221220041624@127.0.0.1>
Date: Wed, 22 Dec 2004 16:24:01 -0800
X-ArGoMail-Authenticated: ppopov@embeddedalley.com
Return-Path: <ppopov@embeddedalley.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: 6747
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips


Start with www.linux-mips.org for information on getting the kernel and tools. There's no sense in someone sending you a config file when that file is already in the tree. 

There are also commercial distros that support that board.

Pete

Original Message -----------------------
Hi all,

   I am looking for the right Cross-compiler and Binutility tools to build a
kernel image for MIPS Malta board. The kernel source version is
linux-2.4.18. Also please provide the configuration file.

Thank you,

 Usha Davuluri.



From nsekhar@ti.com Thu Dec 23 11:28:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Dec 2004 11:28:31 +0000 (GMT)
Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:54213 "EHLO
	go4.ext.ti.com") by linux-mips.org with ESMTP id <S8225208AbULWL2X> convert rfc822-to-8bit;
	Thu, 23 Dec 2004 11:28:23 +0000
Received: from dlep91.itg.ti.com ([157.170.152.55])
	by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id iBNBS6Pw016109
	for <linux-mips@linux-mips.org>; Thu, 23 Dec 2004 05:28:07 -0600 (CST)
Received: from dbde2k01.ent.ti.com (localhost [127.0.0.1])
	by dlep91.itg.ti.com (8.12.11/8.12.11) with ESMTP id iBNBS4Zh025014
	for <linux-mips@linux-mips.org>; Thu, 23 Dec 2004 05:28:05 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Subject: do_ri exception in Linux (MIPS 4kec)
Date: Thu, 23 Dec 2004 16:58:03 +0530
Message-ID: <F6B01C6242515443BB6E5DDD63AE935F60FFFF@dbde2k01.itg.ti.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: do_ri exception in Linux (MIPS 4kec)
Thread-Index: AcTo4ndcVQfXylhOSkKELqeOO9LJEg==
From: "Nori, Soma Sekhar" <nsekhar@ti.com>
To: <linux-mips@linux-mips.org>
Cc: "Iyer, Suraj" <ssiyer@ti.com>
Return-Path: <nsekhar@ti.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6748
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nsekhar@ti.com
Precedence: bulk
X-list: linux-mips


Hi all, 

We are facing "Reserved Instruction" exception whenever there is any activity on serial console (typing any command) while there is traffic on network. We do not suspect the network/serial driver as the same software has been working on other mips boards. Here is the dump I obtained by calling show_registers(regs) in do_ri. (the original do_ri implementation did not make a register dump but just printed "kernel BUG at traps.c:627!" ).

If there is no activity on serial console, the network works just fine. Console activity without any activity on the network also works fine.

We are using montavista Linux version 2.4.17, gcc version 2.95.3 running on MIPS 4kec.

Here is the dump:
$0 : 00000000 0044def4 000001ac 0000006b 00000000 7fff7c08 00000001 00000000
$8 : 0000fc00 00000001 00000000 941524d0 00004700 00000000 97fc3ea0 7fff7c08
$16: 100048a4 100029d8 100029d8 10003020 00000000 7fff7dc8 10003b60 2d8e2163
$24: 00000001 2ab7bc30                   10008e70 7fff7bf0 04000000 00439e50
Hi : 00000000
Lo : 00000001
epc  : 00439e84    Not tainted
Status: 0000fc13
Cause : 10800028
Process sh (pid: 18, stackpage=97fc2000)
Stack: 00000001 00000000 2abd0ff0 7fff7c28 10008e70 00000000 10008e6c 00000000
       100049a0 0042f188 00000000 100029d8 00000001 00000001 7fff7f04 10008e70
       00427fe4 00427f00 00000000 00000000 10002764 10008e70 10008e70 00000000
       00000000 00000000 10008e70 00422734 00000001 00000001 7fff7f04 10008e70
       10008e70 00000003 10008e70 004315cc 00000001 00000000 10002764 00000000
       10008e70 ...
Call Trace:
Code: 00000000  2421dd48  00220821 <8c220000> 00000000  005c1021  00400008  0000
0000  8f99802c

The epc is not in kernel space and ksymoops did not provide any info. The epc keeps changing to different locations in user space over multiple runs.

I used copy_from_user in do_ri to get the memory contents at and around the memory pointed to by epc and the memory was intact (all valid instructions) at all times.

Any idea on why I am getting do_ri only on console activity + network activity?

Any help in debugging this is greatly appreciated.

Thanks,
Sekhar Nori

From tbm@cyrius.com Thu Dec 23 20:26:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Dec 2004 20:26:09 +0000 (GMT)
Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:32263 "EHLO
	sorrow.cyrius.com") by linux-mips.org with ESMTP
	id <S8225242AbULWU0E>; Thu, 23 Dec 2004 20:26:04 +0000
Received: by sorrow.cyrius.com (Postfix, from userid 10)
	id 4ECE564D40; Thu, 23 Dec 2004 20:25:51 +0000 (UTC)
Received: by deprecation.cyrius.com (Postfix, from userid 1000)
	id 26F844FA17; Thu, 23 Dec 2004 20:25:27 +0000 (GMT)
Date: Thu, 23 Dec 2004 20:25:26 +0000
From: Martin Michlmayr <tbm@cyrius.com>
To: linux-mips@linux-mips.org
Subject: Re: [PATCH] Further TLB handler optimizations
Message-ID: <20041223202526.GA2254@deprecation.cyrius.com>
References: <20041222215524.GB3539@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041222215524.GB3539@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.6+20040907i
Return-Path: <tbm@cyrius.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: 6749
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tbm@cyrius.com
Precedence: bulk
X-list: linux-mips

* Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> [2004-12-22 22:55]:
> The patch was tested on an O200 SMP system with 2 x R12000. Other
> machines are untested. Please test if it still works for you,

It breaks SB1 SWARM.
-- 
Martin Michlmayr
http://www.cyrius.com/

From tbm@cyrius.com Thu Dec 23 21:04:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Dec 2004 21:04:58 +0000 (GMT)
Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:52231 "EHLO
	sorrow.cyrius.com") by linux-mips.org with ESMTP
	id <S8225250AbULWVEx>; Thu, 23 Dec 2004 21:04:53 +0000
Received: by sorrow.cyrius.com (Postfix, from userid 10)
	id E046E64D40; Thu, 23 Dec 2004 21:04:39 +0000 (UTC)
Received: by deprecation.cyrius.com (Postfix, from userid 1000)
	id 35A614FA17; Thu, 23 Dec 2004 21:03:41 +0000 (GMT)
Date: Thu, 23 Dec 2004 21:03:40 +0000
From: Martin Michlmayr <tbm@cyrius.com>
To: linux-mips@linux-mips.org
Subject: 2.6.10rc3: swarm only configures eth0, not eth1
Message-ID: <20041223210340.GA27255@deprecation.cyrius.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040907i
Return-Path: <tbm@cyrius.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: 6750
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tbm@cyrius.com
Precedence: bulk
X-list: linux-mips

I just booted a 2.6.10rc3 kernel on my SWARM and noticed that only
eth0 is configured, but eth1 isn't (even though I booted via eth1):

sbmac: configuring MAC at 10064000
eth0: enabling TCP rcv checksum
eth0: SiByte Ethernet at 0x10064000, address: 00:02:4C:FE:0D:08
sbmac: not configuring MAC at 10066000

On a 2.4.x kernel, both network interfaces are configured and I get:

eth0: SiByte Ethernet at 0x10064000, address: 00-02-4C-FE-0D-08
eth0: enabling TCP rcv checksum
eth1: SiByte Ethernet at 0x10065000, address: 00-02-4C-FE-0D-09
eth1: enabling TCP rcv checksum

Note the difference for eth1 between 10066000 (2.6) and 10065000 (2.4).

Thiemo suggested that this might be because the 2.4 kernel is 32 bit
while the 2.6 kernel is 64 bit and that 2.6 might get the address
wrong.
-- 
Martin Michlmayr
http://www.cyrius.com/

From m_lachwani@yahoo.com Fri Dec 24 04:01:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Dec 2004 04:01:23 +0000 (GMT)
Received: from web52806.mail.yahoo.com ([IPv6:::ffff:206.190.39.170]:59730
	"HELO web52806.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225255AbULXEBI>; Fri, 24 Dec 2004 04:01:08 +0000
Received: (qmail 93589 invoked by uid 60001); 24 Dec 2004 04:00:51 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=GSUAie02IlxekLIAVxYYn1aDqCXQAfkBkkY1OWbqcnjHtLgxKyhvEV4X/wJmB1Q1RIVp/P3StjsQRs4sRzgHSLyticT2bTd3Raqi+w7K57c5212A2q3fdbyKkXGjyiOzg65PIXHY9AbgyyYnZlimevVWd3I3ll6RIne6wzxs600=  ;
Message-ID: <20041224040051.93587.qmail@web52806.mail.yahoo.com>
Received: from [203.145.153.244] by web52806.mail.yahoo.com via HTTP; Thu, 23 Dec 2004 20:00:51 PST
Date: Thu, 23 Dec 2004 20:00:51 -0800 (PST)
From: Manish Lachwani <m_lachwani@yahoo.com>
Subject: Re: [PATCH] Further TLB handler optimizations
To: Martin Michlmayr <tbm@cyrius.com>, linux-mips@linux-mips.org
In-Reply-To: <20041223202526.GA2254@deprecation.cyrius.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <m_lachwani@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: 6751
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: m_lachwani@yahoo.com
Precedence: bulk
X-list: linux-mips

Hello !

In what way does it break? Can you please provide more
details. Also, does it break on UP or SMP?

Thanks
Manish Lachwani

--- Martin Michlmayr <tbm@cyrius.com> wrote:

> * Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
> [2004-12-22 22:55]:
> > The patch was tested on an O200 SMP system with 2
> x R12000. Other
> > machines are untested. Please test if it still
> works for you,
> 
> It breaks SB1 SWARM.
> -- 
> Martin Michlmayr
> http://www.cyrius.com/
> 
> 


=====
http://www.koffee-break.com

From anemo@mba.ocn.ne.jp Fri Dec 24 07:34:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Dec 2004 07:34:11 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:49445
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224914AbULXHeF>; Fri, 24 Dec 2004 07:34:05 +0000
Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 24 Dec 2004 07:34:04 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by newms.toshiba-tops.co.jp (Postfix) with ESMTP
	id 7674B239E3C; Fri, 24 Dec 2004 16:33:50 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id iBO7XoMc029105;
	Fri, 24 Dec 2004 16:33:50 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 24 Dec 2004 16:33:48 +0900 (JST)
Message-Id: <20041224.163348.69212321.nemoto@toshiba-tops.co.jp>
To: nunoe@co-nss.co.jp
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: MIPS32 -> MIPS64
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <000601c4e7b8$0f043830$3ca06096@NUNOE>
References: <20041215141613.GB29222@linux-mips.org>
	<20041221.233324.41626824.anemo@mba.ocn.ne.jp>
	<000601c4e7b8$0f043830$3ca06096@NUNOE>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6752
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Wed, 22 Dec 2004 08:51:58 +0900, "Hdei Nunoe" <nunoe@co-nss.co.jp> said:
nunoe> Could anyone tell how significant the migration from MIPS32 to
nunoe> MIPS64 is?  Is it just re-building with the MIPS64 toolchain?
nunoe> Or is it like another architecture porting?

Just rebuilding will not be enough, but the migration will not be so
hard.

Most of you have to do is using correct integer data types ('long' is
64bit and 'int' is 32bit in mips64 kernel).

---
Atsushi Nemoto

From ica2_ts@csv.ica.uni-stuttgart.de Fri Dec 24 08:57:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Dec 2004 08:57:11 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:1893
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224914AbULXI5G>; Fri, 24 Dec 2004 08:57:06 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1ChlFe-0007uF-00; Fri, 24 Dec 2004 09:56:46 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1ChlFd-0002Hh-00; Fri, 24 Dec 2004 09:56:45 +0100
Date: Fri, 24 Dec 2004 09:56:45 +0100
To: Manish Lachwani <m_lachwani@yahoo.com>
Cc: Martin Michlmayr <tbm@cyrius.com>, linux-mips@linux-mips.org
Subject: Re: [PATCH] Further TLB handler optimizations
Message-ID: <20041224085645.GJ3539@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041223202526.GA2254@deprecation.cyrius.com> <20041224040051.93587.qmail@web52806.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041224040051.93587.qmail@web52806.mail.yahoo.com>
User-Agent: Mutt/1.5.6+20040907i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6753
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Manish Lachwani wrote:
> Hello !
> 
> In what way does it break? Can you please provide more
> details. Also, does it break on UP or SMP?

Userland starts to fail for simple tasks like 'ls -la'. The test was
done with 64bit SMP on a board which needs the m3 workaround. The
current CVS version works.

I guess the failure is caused by some missing bits for the m3
workaround which only show up for the optimized handlers in 64bit mode.

I have tested my patch on a SGI O2 R5000 in the meanwhile, also with
good results.


Thiemo

From domen@coderock.org Sat Dec 25 17:24:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Dec 2004 17:25:01 +0000 (GMT)
Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:62172 "EHLO
	trashy.coderock.org") by linux-mips.org with ESMTP
	id <S8225244AbULYRY4>; Sat, 25 Dec 2004 17:24:56 +0000
Received: by trashy.coderock.org (Postfix, from userid 780)
	id 6F9011EA0F; Sat, 25 Dec 2004 18:24:43 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 7AA171ED41;
	Sat, 25 Dec 2004 18:24:42 +0100 (CET)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 370061EA0F;
	Sat, 25 Dec 2004 18:24:40 +0100 (CET)
Subject: [patch 1/9] delete unused file
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, domen@coderock.org
From: domen@coderock.org
Date: Sat, 25 Dec 2004 18:24:50 +0100
Message-Id: <20041225172440.370061EA0F@trashy.coderock.org>
Return-Path: <domen@coderock.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: 6754
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: domen@coderock.org
Precedence: bulk
X-list: linux-mips


Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Signed-off-by: Domen Puncer <domen@coderock.org>
---


 kj/arch/mips/arc/salone.c |   24 ------------------------
 1 files changed, 24 deletions(-)

diff -L arch/mips/arc/salone.c -puN arch/mips/arc/salone.c~remove_file-arch_mips_arc_salone.c /dev/null
--- kj/arch/mips/arc/salone.c
+++ /dev/null	2004-12-24 01:21:08.000000000 +0100
@@ -1,24 +0,0 @@
-/*
- * Routines to load into memory and execute stand-along program images using
- * ARCS PROM firmware.
- *
- * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com)
- */
-#include <linux/init.h>
-#include <asm/sgialib.h>
-
-LONG __init ArcLoad(CHAR *Path, ULONG TopAddr, ULONG *ExecAddr, ULONG *LowAddr)
-{
-	return ARC_CALL4(load, Path, TopAddr, ExecAddr, LowAddr);
-}
-
-LONG __init ArcInvoke(ULONG ExecAddr, ULONG StackAddr, ULONG Argc, CHAR *Argv[],
-	CHAR *Envp[])
-{
-	return ARC_CALL5(invoke, ExecAddr, StackAddr, Argc, Argv, Envp);
-}
-
-LONG __init ArcExecute(CHAR *Path, LONG Argc, CHAR *Argv[], CHAR *Envp[])
-{
-	return ARC_CALL4(exec, Path, Argc, Argv, Envp);
-}
_

From domen@coderock.org Sat Dec 25 17:25:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Dec 2004 17:25:34 +0000 (GMT)
Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:63196 "EHLO
	trashy.coderock.org") by linux-mips.org with ESMTP
	id <S8225246AbULYRY6>; Sat, 25 Dec 2004 17:24:58 +0000
Received: by trashy.coderock.org (Postfix, from userid 780)
	id 979791F126; Sat, 25 Dec 2004 18:24:47 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 94AED1F124;
	Sat, 25 Dec 2004 18:24:46 +0100 (CET)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 3056B1F123;
	Sat, 25 Dec 2004 18:24:43 +0100 (CET)
Subject: [patch 2/9] delete unused file
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, domen@coderock.org
From: domen@coderock.org
Date: Sat, 25 Dec 2004 18:24:53 +0100
Message-Id: <20041225172443.3056B1F123@trashy.coderock.org>
Return-Path: <domen@coderock.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: 6755
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: domen@coderock.org
Precedence: bulk
X-list: linux-mips


Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Signed-off-by: Domen Puncer <domen@coderock.org>
---


 kj/arch/mips/pmc-sierra/yosemite/ht-irq.c |   53 ------------------------------
 1 files changed, 53 deletions(-)

diff -L arch/mips/pmc-sierra/yosemite/ht-irq.c -puN arch/mips/pmc-sierra/yosemite/ht-irq.c~remove_file-arch_mips_pmc_sierra_yosemite_ht_irq.c /dev/null
--- kj/arch/mips/pmc-sierra/yosemite/ht-irq.c
+++ /dev/null	2004-12-24 01:21:08.000000000 +0100
@@ -1,53 +0,0 @@
-/*
- * Copyright 2003 PMC-Sierra
- * Author: Manish Lachwani (lachwani@pmc-sierra.com)
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * 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/types.h>
-#include <linux/pci.h>
-#include <linux/kernel.h>
-#include <linux/version.h>
-#include <linux/init.h>
-#include <asm/pci.h>
-
-/*
- * HT Bus fixup for the Titan
- * XXX IRQ values need to change based on the board layout
- */
-void __init titan_ht_pcibios_fixup_bus(struct pci_bus *bus)
-{
-        struct pci_bus *current_bus = bus;
-        struct pci_dev *devices;
-        struct list_head *devices_link;
-
-	list_for_each(devices_link, &(current_bus->devices)) {
-                devices = pci_dev_b(devices_link);
-                if (devices == NULL)
-                        continue;
-	}
-
-	/*
-	 * PLX and SPKT related changes go here
-	 */
-
-}
_

From domen@coderock.org Sat Dec 25 17:25:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Dec 2004 17:26:10 +0000 (GMT)
Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:65500 "EHLO
	trashy.coderock.org") by linux-mips.org with ESMTP
	id <S8225262AbULYRZH>; Sat, 25 Dec 2004 17:25:07 +0000
Received: by trashy.coderock.org (Postfix, from userid 780)
	id D68B01F127; Sat, 25 Dec 2004 18:24:51 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id D71DA1F124;
	Sat, 25 Dec 2004 18:24:50 +0100 (CET)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 3330D1ED41;
	Sat, 25 Dec 2004 18:24:46 +0100 (CET)
Subject: [patch 3/9] delete unused file
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, domen@coderock.org
From: domen@coderock.org
Date: Sat, 25 Dec 2004 18:24:56 +0100
Message-Id: <20041225172446.3330D1ED41@trashy.coderock.org>
Return-Path: <domen@coderock.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: 6756
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: domen@coderock.org
Precedence: bulk
X-list: linux-mips


Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Signed-off-by: Domen Puncer <domen@coderock.org>
---


 kj/include/asm-mips/gfx.h |   55 ----------------------------------------------
 1 files changed, 55 deletions(-)

diff -L include/asm-mips/gfx.h -puN include/asm-mips/gfx.h~remove_file-include_asm_mips_gfx.h /dev/null
--- kj/include/asm-mips/gfx.h
+++ /dev/null	2004-12-24 01:21:08.000000000 +0100
@@ -1,55 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * This is the user-visible SGI GFX interface.
- *
- * This must be used verbatim into the GNU libc.  It does not include
- * any kernel-only bits on it.
- *
- * miguel@nuclecu.unam.mx
- */
-#ifndef _ASM_GFX_H
-#define _ASM_GFX_H
-
-/* The iocls, yes, they do not make sense, but such is life */
-#define GFX_BASE             100
-#define GFX_GETNUM_BOARDS    (GFX_BASE + 1)
-#define GFX_GETBOARD_INFO    (GFX_BASE + 2)
-#define GFX_ATTACH_BOARD     (GFX_BASE + 3)
-#define GFX_DETACH_BOARD     (GFX_BASE + 4)
-#define GFX_IS_MANAGED       (GFX_BASE + 5)
-
-#define GFX_MAPALL           (GFX_BASE + 10)
-#define GFX_LABEL            (GFX_BASE + 11)
-
-#define GFX_INFO_NAME_SIZE  16
-#define GFX_INFO_LABEL_SIZE 16
-
-struct gfx_info {
-	char name  [GFX_INFO_NAME_SIZE];  /* board name */
-	char label [GFX_INFO_LABEL_SIZE]; /* label name */
-	unsigned short int xpmax, ypmax;  /* screen resolution */
-	unsigned int lenght;	          /* size of a complete gfx_info for this board */
-};
-
-struct gfx_getboardinfo_args {
-	unsigned int board;     /* board number.  starting from zero */
-	void *buf;              /* pointer to gfx_info */
-	unsigned int len;       /* buffer size of buf */
-};
-
-struct gfx_attach_board_args {
-	unsigned int board;	/* board number, starting from zero */
-	void        *vaddr;	/* address where the board registers should be mapped */
-};
-
-#ifdef __KERNEL__
-/* umap.c */
-extern void remove_mapping (struct vm_area_struct *vma, struct task_struct *, unsigned long, unsigned long);
-extern void *vmalloc_uncached (unsigned long size);
-extern int vmap_page_range (struct vm_area_struct *vma, unsigned long from, unsigned long size, unsigned long vaddr);
-#endif
-
-#endif /* _ASM_GFX_H */
_

From domen@coderock.org Sat Dec 25 17:26:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Dec 2004 17:26:45 +0000 (GMT)
Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:221 "EHLO
	trashy.coderock.org") by linux-mips.org with ESMTP
	id <S8225263AbULYRZH>; Sat, 25 Dec 2004 17:25:07 +0000
Received: by trashy.coderock.org (Postfix, from userid 780)
	id 907971F12A; Sat, 25 Dec 2004 18:24:55 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 6BA861F124;
	Sat, 25 Dec 2004 18:24:54 +0100 (CET)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 1063A1F123;
	Sat, 25 Dec 2004 18:24:49 +0100 (CET)
Subject: [patch 4/9] delete unused file
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, domen@coderock.org
From: domen@coderock.org
Date: Sat, 25 Dec 2004 18:24:59 +0100
Message-Id: <20041225172449.1063A1F123@trashy.coderock.org>
Return-Path: <domen@coderock.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: 6757
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: domen@coderock.org
Precedence: bulk
X-list: linux-mips


Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Signed-off-by: Domen Puncer <domen@coderock.org>
---


 kj/include/asm-mips/it8172/it8172_lpc.h |   29 -----------------------------
 1 files changed, 29 deletions(-)

diff -L include/asm-mips/it8172/it8172_lpc.h -puN include/asm-mips/it8172/it8172_lpc.h~remove_file-include_asm_mips_it8172_it8172_lpc.h /dev/null
--- kj/include/asm-mips/it8172/it8172_lpc.h
+++ /dev/null	2004-12-24 01:21:08.000000000 +0100
@@ -1,29 +0,0 @@
-/*
- *
- * BRIEF MODULE DESCRIPTION
- *	IT8172 system controller defines.
- *
- * Copyright 2000 MontaVista Software Inc.
- * Author: MontaVista Software, Inc.
- *         	ppopov@mvista.com or source@mvista.com
- *
- *  This program is free software; you can redistribute  it and/or modify it
- *  under  the terms of  the GNU General  Public License as published by the
- *  Free Software Foundation;  either version 2 of the  License, or (at your
- *  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.
- */
_

From domen@coderock.org Sat Dec 25 17:27:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Dec 2004 17:27:19 +0000 (GMT)
Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:2013 "EHLO
	trashy.coderock.org") by linux-mips.org with ESMTP
	id <S8225264AbULYRZQ>; Sat, 25 Dec 2004 17:25:16 +0000
Received: by trashy.coderock.org (Postfix, from userid 780)
	id C57A71F129; Sat, 25 Dec 2004 18:25:04 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id D41AC1F124;
	Sat, 25 Dec 2004 18:25:02 +0100 (CET)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 2CFE31F125;
	Sat, 25 Dec 2004 18:24:55 +0100 (CET)
Subject: [patch 6/9] delete unused file
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, domen@coderock.org
From: domen@coderock.org
Date: Sat, 25 Dec 2004 18:25:05 +0100
Message-Id: <20041225172455.2CFE31F125@trashy.coderock.org>
Return-Path: <domen@coderock.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: 6758
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: domen@coderock.org
Precedence: bulk
X-list: linux-mips


Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Signed-off-by: Domen Puncer <domen@coderock.org>
---


 kj/include/asm-mips/mipsprom.h |   74 -----------------------------------------
 1 files changed, 74 deletions(-)

diff -L include/asm-mips/mipsprom.h -puN include/asm-mips/mipsprom.h~remove_file-include_asm_mips_mipsprom.h /dev/null
--- kj/include/asm-mips/mipsprom.h
+++ /dev/null	2004-12-24 01:21:08.000000000 +0100
@@ -1,74 +0,0 @@
-#ifndef __ASM_MIPS_PROM_H
-#define __ASM_MIPS_PROM_H
-
-#define PROM_RESET		0
-#define PROM_EXEC		1
-#define PROM_RESTART		2
-#define PROM_REINIT		3
-#define PROM_REBOOT		4
-#define PROM_AUTOBOOT		5
-#define PROM_OPEN		6
-#define PROM_READ		7
-#define PROM_WRITE		8
-#define PROM_IOCTL		9
-#define PROM_CLOSE		10
-#define PROM_GETCHAR		11
-#define PROM_PUTCHAR		12
-#define PROM_SHOWCHAR		13	/* XXX */
-#define PROM_GETS		14	/* XXX */
-#define PROM_PUTS		15	/* XXX */
-#define PROM_PRINTF		16	/* XXX */
-
-/* What are these for? */
-#define PROM_INITPROTO		17	/* XXX */
-#define PROM_PROTOENABLE	18	/* XXX */
-#define PROM_PROTODISABLE	19	/* XXX */
-#define PROM_GETPKT		20	/* XXX */
-#define PROM_PUTPKT		21	/* XXX */
-
-/* More PROM shit.  Probably has to do with VME RMW cycles??? */
-#define PROM_ORW_RMW		22	/* XXX */
-#define PROM_ORH_RMW		23	/* XXX */
-#define PROM_ORB_RMW		24	/* XXX */
-#define PROM_ANDW_RMW		25	/* XXX */
-#define PROM_ANDH_RMW		26	/* XXX */
-#define PROM_ANDB_RMW		27	/* XXX */
-
-/* Cache handling stuff */
-#define PROM_FLUSHCACHE		28	/* XXX */
-#define PROM_CLEARCACHE		29	/* XXX */
-
-/* Libc alike stuff */
-#define PROM_SETJMP		30	/* XXX */
-#define PROM_LONGJMP		31	/* XXX */
-#define PROM_BEVUTLB		32	/* XXX */
-#define PROM_GETENV		33	/* XXX */
-#define PROM_SETENV		34	/* XXX */
-#define PROM_ATOB		35	/* XXX */
-#define PROM_STRCMP		36	/* XXX */
-#define PROM_STRLEN		37	/* XXX */
-#define PROM_STRCPY		38	/* XXX */
-#define PROM_STRCAT		39	/* XXX */
-
-/* Misc stuff */
-#define PROM_PARSER		40	/* XXX */
-#define PROM_RANGE		41	/* XXX */
-#define PROM_ARGVIZE		42	/* XXX */
-#define PROM_HELP		43	/* XXX */
-
-/* Entry points for some PROM commands */
-#define PROM_DUMPCMD		44	/* XXX */
-#define PROM_SETENVCMD		45	/* XXX */
-#define PROM_UNSETENVCMD	46	/* XXX */
-#define PROM_PRINTENVCMD	47	/* XXX */
-#define PROM_BEVEXCEPT		48	/* XXX */
-#define PROM_ENABLECMD		49	/* XXX */
-#define PROM_DISABLECMD		50	/* XXX */
-
-#define PROM_CLEARNOFAULT	51	/* XXX */
-#define PROM_NOTIMPLEMENT	52	/* XXX */
-
-#define PROM_NV_GET		53	/* XXX */
-#define PROM_NV_SET		54	/* XXX */
-
-#endif /* __ASM_MIPS_PROM_H */
_

From domen@coderock.org Sat Dec 25 17:27:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Dec 2004 17:27:56 +0000 (GMT)
Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:3037 "EHLO
	trashy.coderock.org") by linux-mips.org with ESMTP
	id <S8225265AbULYRZU>; Sat, 25 Dec 2004 17:25:20 +0000
Received: by trashy.coderock.org (Postfix, from userid 780)
	id A683D1F12A; Sat, 25 Dec 2004 18:25:08 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 498601F125;
	Sat, 25 Dec 2004 18:25:06 +0100 (CET)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 0F3151ED41;
	Sat, 25 Dec 2004 18:24:52 +0100 (CET)
Subject: [patch 5/9] delete unused file
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, domen@coderock.org
From: domen@coderock.org
Date: Sat, 25 Dec 2004 18:25:02 +0100
Message-Id: <20041225172452.0F3151ED41@trashy.coderock.org>
Return-Path: <domen@coderock.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: 6759
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: domen@coderock.org
Precedence: bulk
X-list: linux-mips


Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Signed-off-by: Domen Puncer <domen@coderock.org>
---


 kj/include/asm-mips/mach-au1x00/au1100_mmc.h |  205 ---------------------------
 1 files changed, 205 deletions(-)

diff -L include/asm-mips/mach-au1x00/au1100_mmc.h -puN include/asm-mips/mach-au1x00/au1100_mmc.h~remove_file-include_asm_mips_mach_au1x00_au1100_mmc.h /dev/null
--- kj/include/asm-mips/mach-au1x00/au1100_mmc.h
+++ /dev/null	2004-12-24 01:21:08.000000000 +0100
@@ -1,205 +0,0 @@
-/*
- * BRIEF MODULE DESCRIPTION
- *	Defines for using the MMC/SD controllers on the
- *      Alchemy Au1100 mips processor.
- *
- * Copyright (c) 2003 Embedded Edge, LLC.
- * Author: Embedded Edge, LLC.
- *         	dan@embeddededge.com or tim@embeddededge.com
- *
- *  This program is free software; you can redistribute  it and/or modify it
- *  under  the terms of  the GNU General  Public License as published by the
- *  Free Software Foundation;  either version 2 of the  License, or (at your
- *  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.
- *
- */
-/*
- * AU1100 MMC/SD definitions.
- *
- * From "AMD Alchemy Solutions Au1100 Processor Data Book - Preliminary"
- *    June, 2003
- */
-
-#ifndef __ASM_AU1100_MMC_H
-#define __ASM_AU1100_MMC_H
-
-
-#define NUM_AU1100_MMC_CONTROLLERS	2
-
-
-#define AU1100_SD_IRQ	2
-
-
-#define SD0_BASE	0xB0600000
-#define SD1_BASE	0xB0680000
-
-
-/*
- *  Register offsets.
- */
-#define SD_TXPORT	(0x0000)
-#define SD_RXPORT	(0x0004)
-#define SD_CONFIG	(0x0008)
-#define SD_ENABLE	(0x000C)
-#define SD_CONFIG2	(0x0010)
-#define SD_BLKSIZE	(0x0014)
-#define SD_STATUS	(0x0018)
-#define SD_DEBUG	(0x001C)
-#define SD_CMD		(0x0020)
-#define SD_CMDARG	(0x0024)
-#define SD_RESP3	(0x0028)
-#define SD_RESP2	(0x002C)
-#define SD_RESP1	(0x0030)
-#define SD_RESP0	(0x0034)
-#define SD_TIMEOUT	(0x0038)
-
-
-/*
- *  SD_TXPORT bit definitions.
- */
-#define SD_TXPORT_TXD	(0x000000ff)
-
-
-/*
- *  SD_RXPORT bit definitions.
- */
-#define SD_RXPORT_RXD	(0x000000ff)
-
-
-/*
- *  SD_CONFIG bit definitions.
- */
-#define SD_CONFIG_DIV	(0x000001ff)
-#define SD_CONFIG_DE	(0x00000200)
-#define SD_CONFIG_NE	(0x00000400)
-#define SD_CONFIG_TU	(0x00000800)
-#define SD_CONFIG_TO	(0x00001000)
-#define SD_CONFIG_RU	(0x00002000)
-#define SD_CONFIG_RO	(0x00004000)
-#define SD_CONFIG_I	(0x00008000)
-#define SD_CONFIG_CR	(0x00010000)
-#define SD_CONFIG_RAT	(0x00020000)
-#define SD_CONFIG_DD	(0x00040000)
-#define SD_CONFIG_DT	(0x00080000)
-#define SD_CONFIG_SC	(0x00100000)
-#define SD_CONFIG_RC	(0x00200000)
-#define SD_CONFIG_WC	(0x00400000)
-#define SD_CONFIG_xxx	(0x00800000)
-#define SD_CONFIG_TH	(0x01000000)
-#define SD_CONFIG_TE	(0x02000000)
-#define SD_CONFIG_TA	(0x04000000)
-#define SD_CONFIG_RH	(0x08000000)
-#define SD_CONFIG_RA	(0x10000000)
-#define SD_CONFIG_RF	(0x20000000)
-#define SD_CONFIG_CD	(0x40000000)
-#define SD_CONFIG_SI	(0x80000000)
-
-
-/*
- *  SD_ENABLE bit definitions.
- */
-#define SD_ENABLE_CE	(0x00000001)
-#define SD_ENABLE_R	(0x00000002)
-
-
-/*
- *  SD_CONFIG2 bit definitions.
- */
-#define SD_CONFIG2_EN	(0x00000001)
-#define SD_CONFIG2_FF	(0x00000002)
-#define SD_CONFIG2_xx1	(0x00000004)
-#define SD_CONFIG2_DF	(0x00000008)
-#define SD_CONFIG2_DC	(0x00000010)
-#define SD_CONFIG2_xx2	(0x000000e0)
-#define SD_CONFIG2_WB	(0x00000100)
-#define SD_CONFIG2_RW	(0x00000200)
-
-
-/*
- *  SD_BLKSIZE bit definitions.
- */
-#define SD_BLKSIZE_BS	(0x000007ff)
-#define SD_BLKSIZE_BS_SHIFT	 (0)
-#define SD_BLKSIZE_BC	(0x01ff0000)
-#define SD_BLKSIZE_BC_SHIFT	(16)
-
-
-/*
- *  SD_STATUS bit definitions.
- */
-#define SD_STATUS_DCRCW	(0x00000007)
-#define SD_STATUS_xx1	(0x00000008)
-#define SD_STATUS_CB	(0x00000010)
-#define SD_STATUS_DB	(0x00000020)
-#define SD_STATUS_CF	(0x00000040)
-#define SD_STATUS_D3	(0x00000080)
-#define SD_STATUS_xx2	(0x00000300)
-#define SD_STATUS_NE	(0x00000400)
-#define SD_STATUS_TU	(0x00000800)
-#define SD_STATUS_TO	(0x00001000)
-#define SD_STATUS_RU	(0x00002000)
-#define SD_STATUS_RO	(0x00004000)
-#define SD_STATUS_I	(0x00008000)
-#define SD_STATUS_CR	(0x00010000)
-#define SD_STATUS_RAT	(0x00020000)
-#define SD_STATUS_DD	(0x00040000)
-#define SD_STATUS_DT	(0x00080000)
-#define SD_STATUS_SC	(0x00100000)
-#define SD_STATUS_RC	(0x00200000)
-#define SD_STATUS_WC	(0x00400000)
-#define SD_STATUS_xx3	(0x00800000)
-#define SD_STATUS_TH	(0x01000000)
-#define SD_STATUS_TE	(0x02000000)
-#define SD_STATUS_TA	(0x04000000)
-#define SD_STATUS_RH	(0x08000000)
-#define SD_STATUS_RA	(0x10000000)
-#define SD_STATUS_RF	(0x20000000)
-#define SD_STATUS_CD	(0x40000000)
-#define SD_STATUS_SI	(0x80000000)
-
-
-/*
- *  SD_CMD bit definitions.
- */
-#define SD_CMD_GO	(0x00000001)
-#define SD_CMD_RY	(0x00000002)
-#define SD_CMD_xx1	(0x0000000c)
-#define SD_CMD_CT_MASK	(0x000000f0)
-#define SD_CMD_CT_0	(0x00000000)
-#define SD_CMD_CT_1	(0x00000010)
-#define SD_CMD_CT_2	(0x00000020)
-#define SD_CMD_CT_3	(0x00000030)
-#define SD_CMD_CT_4	(0x00000040)
-#define SD_CMD_CT_5	(0x00000050)
-#define SD_CMD_CT_6	(0x00000060)
-#define SD_CMD_CT_7	(0x00000070)
-#define SD_CMD_CI	(0x0000ff00)
-#define SD_CMD_CI_SHIFT		(8)
-#define SD_CMD_RT_MASK	(0x00ff0000)
-#define SD_CMD_RT_0	(0x00000000)
-#define SD_CMD_RT_1	(0x00010000)
-#define SD_CMD_RT_2	(0x00020000)
-#define SD_CMD_RT_3	(0x00030000)
-#define SD_CMD_RT_4	(0x00040000)
-#define SD_CMD_RT_5	(0x00050000)
-#define SD_CMD_RT_6	(0x00060000)
-#define SD_CMD_RT_1B	(0x00810000)
-
-
-#endif /* __ASM_AU1100_MMC_H */
-
_

From domen@coderock.org Sat Dec 25 17:28:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Dec 2004 17:28:30 +0000 (GMT)
Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:3293 "EHLO
	trashy.coderock.org") by linux-mips.org with ESMTP
	id <S8225266AbULYRZU>; Sat, 25 Dec 2004 17:25:20 +0000
Received: by trashy.coderock.org (Postfix, from userid 780)
	id 5ADE71F126; Sat, 25 Dec 2004 18:25:09 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 200711ED41;
	Sat, 25 Dec 2004 18:25:07 +0100 (CET)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 1B1FB1EA0F;
	Sat, 25 Dec 2004 18:24:58 +0100 (CET)
Subject: [patch 7/9] delete unused file
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, domen@coderock.org
From: domen@coderock.org
Date: Sat, 25 Dec 2004 18:25:08 +0100
Message-Id: <20041225172458.1B1FB1EA0F@trashy.coderock.org>
Return-Path: <domen@coderock.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: 6760
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: domen@coderock.org
Precedence: bulk
X-list: linux-mips


Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Signed-off-by: Domen Puncer <domen@coderock.org>
---


 kj/include/asm-mips/ng1.h |   55 ----------------------------------------------
 1 files changed, 55 deletions(-)

diff -L include/asm-mips/ng1.h -puN include/asm-mips/ng1.h~remove_file-include_asm_mips_ng1.h /dev/null
--- kj/include/asm-mips/ng1.h
+++ /dev/null	2004-12-24 01:21:08.000000000 +0100
@@ -1,55 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * SGI/Newport video card ioctl definitions
- */
-#ifndef _ASM_NG1_H
-#define _ASM_NG1_H
-
-typedef struct {
-        int flags;
-        __u16 w, h;
-        __u16 fields_sec;
-} ng1_vof_info_t;
-
-struct ng1_info {
-	struct gfx_info gfx_info;
-	__u8 boardrev;
-        __u8 rex3rev;
-        __u8 vc2rev;
-        __u8 monitortype;
-        __u8 videoinstalled;
-        __u8 mcrev;
-        __u8 bitplanes;
-        __u8 xmap9rev;
-        __u8 cmaprev;
-        ng1_vof_info_t ng1_vof_info;
-        __u8 bt445rev;
-        __u8 paneltype;
-};
-
-#define GFX_NAME_NEWPORT "NG1"
-
-/* ioctls */
-#define NG1_SET_CURSOR_HOTSPOT 21001
-struct ng1_set_cursor_hotspot {
-	unsigned short xhot;
-        unsigned short yhot;
-};
-
-#define NG1_SETDISPLAYMODE     21006
-struct ng1_setdisplaymode_args {
-        int wid;
-        unsigned int mode;
-};
-
-#define NG1_SETGAMMARAMP0      21007
-struct ng1_setgammaramp_args {
-        unsigned char red   [256];
-        unsigned char green [256];
-        unsigned char blue  [256];
-};
-
-#endif /* _ASM_NG1_H */
_

From domen@coderock.org Sat Dec 25 17:28:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Dec 2004 17:29:06 +0000 (GMT)
Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:3805 "EHLO
	trashy.coderock.org") by linux-mips.org with ESMTP
	id <S8225244AbULYRZ3>; Sat, 25 Dec 2004 17:25:29 +0000
Received: by trashy.coderock.org (Postfix, from userid 780)
	id 33B501F125; Sat, 25 Dec 2004 18:25:17 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 18A441EA0F;
	Sat, 25 Dec 2004 18:25:16 +0100 (CET)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 97E251F123;
	Sat, 25 Dec 2004 18:25:01 +0100 (CET)
Subject: [patch 8/9] delete unused file
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, domen@coderock.org
From: domen@coderock.org
Date: Sat, 25 Dec 2004 18:25:11 +0100
Message-Id: <20041225172501.97E251F123@trashy.coderock.org>
Return-Path: <domen@coderock.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: 6761
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: domen@coderock.org
Precedence: bulk
X-list: linux-mips


Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Signed-off-by: Domen Puncer <domen@coderock.org>
---


 kj/include/asm-mips/ng1hw.h |  219 --------------------------------------------
 1 files changed, 219 deletions(-)

diff -L include/asm-mips/ng1hw.h -puN include/asm-mips/ng1hw.h~remove_file-include_asm_mips_ng1hw.h /dev/null
--- kj/include/asm-mips/ng1hw.h
+++ /dev/null	2004-12-24 01:21:08.000000000 +0100
@@ -1,219 +0,0 @@
-/*
- * ng1hw.h: Tweaks the newport.h structures and definitions to be compatible
- * 	    with IRIX.  Quite ugly, but it works.
- *
- * Copyright (C) 1999 Ulf Carlsson (ulfc@thepuffingroup.com)
- */
-#ifndef _SGI_NG1HW_H
-#define _SGI_NG1HW_H
-
-#include <video/newport.h>
-
-#define rex3regs	newport_rexregs
-#define configregs	newport_cregs
-#define float_long	npfreg_t
-
-typedef struct newport_rexregs Rex3regs;
-typedef struct newport_cregs Configregs;
-typedef union np_dcb DCB_reg;
-
-
-/* It looks like I can't do a simple tweak with this structure because the IRIX
- * version is just *too* stupid.  Ok, here's a new version of it..
- */
-
-struct rex3chip {
-	struct newport_rexregs set;
-	unsigned long _unused0[0x16e];
-	struct newport_rexregs go;
-	unsigned long _unused1[0x22e];
-	struct {
-		struct newport_cregs set;
-		unsigned long _unused2[0x1ef];
-		struct newport_cregs go;
-	} p1;
-};
-
-typedef struct rex3chip rex3Chip;
-typedef struct rex3chip Rex3chip;
-
-/* Tweak the defines .. */
-
-#define DM0_OPCODE		NPORT_DMODE0_OPMASK
-#define DM0_NOP			NPORT_DMODE0_NOP
-#define DM0_READ		NPORT_DMODE0_RD
-#define DM0_DRAW		NPORT_DMODE0_DRAW
-#define DM0_SCR2SCR		NPORT_DMODE0_S2S
-
-#define DM0_ADRMODE_SHIFT	2
-#define DM0_ADRMODE		NPORT_DMODE0_AMMASK
-#define DM0_SPAN		NPORT_DMODE0_SPAN
-#define DM0_BLOCK		NPORT_DMODE0_BLOCK
-#define DM0_ILINE		NPORT_DMODE0_ILINE
-#define DM0_FLINE		NPORT_DMODE0_FLINE
-#define DM0_ALINE		NPORT_DMODE0_ALINE
-#define DM0_TLINE		NPORT_DMODE0_TLINE
-#define DM0_BLINE               NPORT_DMODE0_BLINE
-
-#define DM0_DOSETUP		NPORT_DMODE0_DOSETUP
-#define DM0_COLORHOST		NPORT_DMODE0_CHOST
-#define DM0_ALPHAHOST		NPORT_DMODE0_AHOST
-#define DM0_STOPONX		NPORT_DMODE0_STOPX
-#define DM0_STOPONY		NPORT_DMODE0_STOPY
-#define DM0_STOPONXY		(NPORT_DMODE0_STOPX | NPORT_DMODE0_STOPY)
-#define DM0_SKIPFIRST		NPORT_DMODE0_SK1ST
-#define DM0_SKIPLAST		NPORT_DMODE0_SKLST
-#define DM0_ENZPATTERN		NPORT_DMODE0_ZPENAB
-#define DM0_ENLSPATTERN		NPORT_DMODE0_LISPENAB
-#define DM0_LSADVLAST		NPORT_DMODE0_LISLST
-#define DM0_LENGTH32		NPORT_DMODE0_L32
-#define DM0_ZOPAQUE		NPORT_DMODE0_ZOPQ
-#define DM0_LSOPAQUE		NPORT_DMODE0_LISOPQ
-#define DM0_SHADE		NPORT_DMODE0_SHADE
-#define DM0_LRONLY		NPORT_DMODE0_LRONLY
-#define DM0_XYOFFSET		NPORT_DMODE0_XYOFF
-#define DM0_CICLAMP		NPORT_DMODE0_CLAMP
-#define DM0_ENDPTFILTER		NPORT_DMODE0_ENDPF
-#define	DM0_YSTRIDE		NPORT_DMODE0_YSTR
-
-#define DM1_PLANES_SHIFT	0
-/* The rest of the DM1 planes defines are in newport.h */
-
-#define DM1_DRAWDEPTH_SHIFT	3
-#define DM1_DRAWDEPTH_MASK	NPORT_DMODE1_DDMASK
-#define DM1_DRAWDEPTH		NPORT_DMODE1_DD24 /* An alias? */
-#define DM1_DRAWDEPTH4		NPORT_DMODE1_DD4
-#define DM1_DRAWDEPTH8		NPORT_DMODE1_DD8
-#define DM1_DRAWDEPTH12		NPORT_DMODE1_DD12
-#define DM1_DRAWDEPTH24		NPORT_DMODE1_DD24
-
-#define DM1_DBLSRC		NPORT_DMODE1_DSRC
-#define DM1_YFLIP		NPORT_DMODE1_YFLIP
-#define DM1_RWPACKED		NPORT_DMODE1_RWPCKD
-
-#define DM1_HOSTDEPTH_SHIFT 	8
-#define DM1_HOSTDEPTH_MASK	NPORT_DMODE1_HDMASK
-#define DM1_HOSTDEPTH		NPORT_DMODE1_HD32 /* An alias? */
-#define DM1_HOSTDEPTH4		NPORT_DMODE1_HD4
-#define DM1_HOSTDEPTH8		NPORT_DMODE1_HD8
-#define DM1_HOSTDEPTH12		NPORT_DMODE1_HD12
-#define DM1_HOSTDEPTH32		NPORT_DMODE1_HD32
-
-#define DM1_RWDOUBLE		NPORT_DMODE1_RWDBL
-#define DM1_SWAPENDIAN		NPORT_DMODE1_ESWAP
-
-#define DM1_COLORCOMPARE_SHIFT	12
-#define DM1_COLORCOMPARE_MASK	NPORT_DMODE1_CCMASK
-#define DM1_COLORCOMPARE	NPORT_DMODE1_CCMASK
-#define DM1_COLORCOMPLT		NPORT_DMODE1_CCLT
-#define DM1_COLORCOMPEQ		NPORT_DMODE1_CCEQ
-#define DM1_COLORCOMPGT		NPORT_DMODE1_CCGT
-
-#define DM1_RGBMODE		NPORT_DMODE1_RGBMD
-#define DM1_ENDITHER		NPORT_DMODE1_DENAB
-#define DM1_FASTCLEAR		NPORT_DMODE1_FCLR
-#define DM1_ENBLEND		NPORT_DMODE1_BENAB
-
-#define DM1_SF_SHIFT		19
-#define DM1_SF_MASK   		NPORT_DMODE1_SFMASK
-#define DM1_SF			NPORT_DMODE1_SFMASK
-#define DM1_SF_ZERO		NPORT_DMODE1_SF0
-#define DM1_SF_ONE		NPORT_DMODE1_SF1
-#define DM1_SF_DC		NPORT_DMODE1_SFDC
-#define DM1_SF_MDC		NPORT_DMODE1_SFMDC
-#define DM1_SF_SA		NPORT_DMODE1_SFSA
-#define DM1_SF_MSA		NPORT_DMODE1_SFMSA
-
-#define DM1_DF_SHIFT		22	/* dfactor(2:0)	*/
-#define DM1_DF_MASK		NPORT_DMODE1_DFMASK
-#define DM1_DF			NPORT_DMODE1_DFMASK
-#define DM1_DF_ZERO		NPORT_DMODE1_DF0
-#define DM1_DF_ONE		NPORT_DMODE1_DF1
-#define DM1_DF_SC		NPORT_DMODE1_DFSC
-#define DM1_DF_MSC		NPORT_DMODE1_DFMSC
-#define DM1_DF_SA		NPORT_DMODE1_DFSA
-#define DM1_DF_MSA		NPORT_DMODE1_DFMSA
-
-#define DM1_ENBACKBLEND		NPORT_DMODE1_BBENAB
-#define DM1_ENPREFETCH		NPORT_DMODE1_PFENAB
-#define DM1_BLENDALPHA		NPORT_DMODE1_ABLEND
-
-#define DM1_LO_SHIFT		28
-#define DM1_LO			NPORT_DMODE1_LOMASK
-#define DM1_LO_MASK      	NPORT_DMODE1_LOMASK
-#define DM1_LO_ZERO		NPORT_DMODE1_LOZERO
-#define DM1_LO_AND		NPORT_DMODE1_LOAND
-#define DM1_LO_ANDR		NPORT_DMODE1_LOANDR
-#define DM1_LO_SRC		NPORT_DMODE1_LOSRC
-#define DM1_LO_ANDI		NPORT_DMODE1_LOANDI
-#define DM1_LO_DST		NPORT_DMODE1_LODST
-#define DM1_LO_XOR		NPORT_DMODE1_LOXOR
-#define DM1_LO_OR		NPORT_DMODE1_LOOR
-#define DM1_LO_NOR		NPORT_DMODE1_LONOR
-#define DM1_LO_XNOR		NPORT_DMODE1_LOXNOR
-#define DM1_LO_NDST		NPORT_DMODE1_LONDST
-#define DM1_LO_ORR		NPORT_DMODE1_LOORR
-#define DM1_LO_NSRC		NPORT_DMODE1_LONSRC
-#define DM1_LO_ORI		NPORT_DMODE1_LOORI
-#define DM1_LO_NAND		NPORT_DMODE1_LONAND
-#define DM1_LO_ONE		NPORT_DMODE1_LOONE
-
-#define SMASK0			NPORT_CMODE_SM0
-#define SMASK1			NPORT_CMODE_SM1
-#define SMASK2			NPORT_CMODE_SM2
-#define SMASK3			NPORT_CMODE_SM3
-#define SMASK4			NPORT_CMODE_SM4
-#define ALL_SMASKS		0x1f
-
-#define CM_CIDMATCH_SHIFT       9
-#define CM_CIDMATCH_MASK        NPORT_CMODE_CMSK
-
-#define REX3VERSION_MASK	NPORT_STAT_VERS
-#define GFXBUSY        		NPORT_STAT_GBUSY
-#define BACKBUSY        	NPORT_STAT_BBUSY
-#define VRINT           	NPORT_STAT_VRINT
-#define VIDEOINT        	NPORT_STAT_VIDINT
-#define GFIFO_LEVEL_SHIFT       7
-#define GFIFO_LEVEL_MASK        NPORT_STAT_GLMSK
-#define BFIFO_LEVEL_SHIFT       13
-#define BFIFO_LEVEL_MASK        NPORT_STAT_BLMSK
-#define BFIFO_INT        	NPORT_STAT_BFIRQ
-#define GFIFO_INT        	NPORT_STAT_GFIRQ
-
-#define GIO32MODE		NPORT_CFG_G32MD
-#define BUSWIDTH		NPORT_CFG_BWIDTH
-#define EXTREGXCVR		NPORT_CFG_ERCVR
-#define BFIFODEPTH_SHIFT	3
-#define BFIFODEPTH_MASK		NPORT_CFG_BDMSK
-#define BFIFOABOVEINT		NPORT_CFG_BFAINT
-#define GFIFODEPTH_SHIFT        8
-#define GFIFODEPTH_MASK		NPORT_CFG_GDMSK
-#define GFIFOABOVEINT		NPORT_CFG_GFAINT
-#define TIMEOUT_SHIFT		14
-#define TIMEOUT_MASK		NPORT_CFG_TOMSK
-#define VREFRESH_SHIFT		17
-#define VREFRESH_MASK		NPORT_CFG_VRMSK
-#define FB_TYPE			NPORT_CFG_FBTYP
-
-#define DCB_DATAWIDTH_MASK	(0x3)
-
-#define DCB_CRS_MASK		(0x7 << DCB_CRS_SHIFT)
-#define DCB_ADDR_MASK		(0xf << DCB_ADDR_SHIFT)
-#define DCB_CSWIDTH_MASK	(0x1f << DCB_CSWIDTH_SHIFT)
-#define DCB_CSHOLD_MASK		(0x1f << DCB_CSHOLD_SHIFT)
-#define DCB_CSSETUP_MASK	(0x1f << DCB_CSSETUP_SHIFT)
-
-#define DCB_SWAPENDIAN		(1 << 28)
-
-#define REX3WAIT(rex3)  while ((rex3)->p1.set.status & GFXBUSY)
-#define BFIFOWAIT(rex3)  while ((rex3)->p1.set.status & BACKBUSY)
-
-#define REX3_GIO_ADDR_0         0x1f0f0000
-#define REX3_GIO_ADDR_1         0x1f4f0000
-#define REX3_GIO_ADDR_2         0x1f8f0000
-#define REX3_GIO_ADDR_3         0x1fcf0000
-
-#define NG1_XSIZE		1280
-#define NG1_YSIZE		1024
-
-#endif
_

From domen@coderock.org Sat Dec 25 17:29:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Dec 2004 17:29:47 +0000 (GMT)
Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:4317 "EHLO
	trashy.coderock.org") by linux-mips.org with ESMTP
	id <S8225271AbULYRZs>; Sat, 25 Dec 2004 17:25:48 +0000
Received: by trashy.coderock.org (Postfix, from userid 780)
	id 331BC1F124; Sat, 25 Dec 2004 18:25:35 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id 693141EA0F;
	Sat, 25 Dec 2004 18:25:33 +0100 (CET)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by trashy.coderock.org (Postfix) with ESMTP id EE52A1F124;
	Sat, 25 Dec 2004 18:25:04 +0100 (CET)
Subject: [patch 9/9] delete unused file
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, domen@coderock.org
From: domen@coderock.org
Date: Sat, 25 Dec 2004 18:25:15 +0100
Message-Id: <20041225172504.EE52A1F124@trashy.coderock.org>
Return-Path: <domen@coderock.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: 6762
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: domen@coderock.org
Precedence: bulk
X-list: linux-mips


Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Signed-off-by: Domen Puncer <domen@coderock.org>
---


 kj/include/asm-mips/riscos-syscall.h |  979 -----------------------------------
 1 files changed, 979 deletions(-)

diff -L include/asm-mips/riscos-syscall.h -puN include/asm-mips/riscos-syscall.h~remove_file-include_asm_mips_riscos_syscall.h /dev/null
--- kj/include/asm-mips/riscos-syscall.h
+++ /dev/null	2004-12-24 01:21:08.000000000 +0100
@@ -1,979 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 1995, 96, 97, 98, 99, 2000 by Ralf Baechle
- */
-#ifndef _ASM_RISCOS_SYSCALL_H
-#define _ASM_RISCOS_SYSCALL_H
-
-/*
- * The syscalls 0 - 3999 are reserved for a down to the root syscall
- * compatibility with RISC/os and IRIX.  We'll see how to deal with the
- * various "real" BSD variants like Ultrix, NetBSD ...
- */
-
-/*
- * SVR4 syscalls are in the range from 1 to 999
- */
-#define __NR_SVR4			0
-#define __NR_SVR4_syscall		(__NR_SVR4 +   0)
-#define __NR_SVR4_exit			(__NR_SVR4 +   1)
-#define __NR_SVR4_fork			(__NR_SVR4 +   2)
-#define __NR_SVR4_read			(__NR_SVR4 +   3)
-#define __NR_SVR4_write			(__NR_SVR4 +   4)
-#define __NR_SVR4_open			(__NR_SVR4 +   5)
-#define __NR_SVR4_close			(__NR_SVR4 +   6)
-#define __NR_SVR4_wait			(__NR_SVR4 +   7)
-#define __NR_SVR4_creat			(__NR_SVR4 +   8)
-#define __NR_SVR4_link			(__NR_SVR4 +   9)
-#define __NR_SVR4_unlink		(__NR_SVR4 +  10)
-#define __NR_SVR4_exec			(__NR_SVR4 +  11)
-#define __NR_SVR4_chdir			(__NR_SVR4 +  12)
-#define __NR_SVR4_gtime			(__NR_SVR4 +  13)
-#define __NR_SVR4_mknod			(__NR_SVR4 +  14)
-#define __NR_SVR4_chmod			(__NR_SVR4 +  15)
-#define __NR_SVR4_chown			(__NR_SVR4 +  16)
-#define __NR_SVR4_sbreak		(__NR_SVR4 +  17)
-#define __NR_SVR4_stat			(__NR_SVR4 +  18)
-#define __NR_SVR4_lseek			(__NR_SVR4 +  19)
-#define __NR_SVR4_getpid		(__NR_SVR4 +  20)
-#define __NR_SVR4_mount			(__NR_SVR4 +  21)
-#define __NR_SVR4_umount		(__NR_SVR4 +  22)
-#define __NR_SVR4_setuid		(__NR_SVR4 +  23)
-#define __NR_SVR4_getuid		(__NR_SVR4 +  24)
-#define __NR_SVR4_stime			(__NR_SVR4 +  25)
-#define __NR_SVR4_ptrace		(__NR_SVR4 +  26)
-#define __NR_SVR4_alarm			(__NR_SVR4 +  27)
-#define __NR_SVR4_fstat			(__NR_SVR4 +  28)
-#define __NR_SVR4_pause			(__NR_SVR4 +  29)
-#define __NR_SVR4_utime			(__NR_SVR4 +  30)
-#define __NR_SVR4_stty			(__NR_SVR4 +  31)
-#define __NR_SVR4_gtty			(__NR_SVR4 +  32)
-#define __NR_SVR4_access		(__NR_SVR4 +  33)
-#define __NR_SVR4_nice			(__NR_SVR4 +  34)
-#define __NR_SVR4_statfs		(__NR_SVR4 +  35)
-#define __NR_SVR4_sync			(__NR_SVR4 +  36)
-#define __NR_SVR4_kill			(__NR_SVR4 +  37)
-#define __NR_SVR4_fstatfs		(__NR_SVR4 +  38)
-#define __NR_SVR4_setpgrp		(__NR_SVR4 +  39)
-#define __NR_SVR4_cxenix		(__NR_SVR4 +  40)
-#define __NR_SVR4_dup			(__NR_SVR4 +  41)
-#define __NR_SVR4_pipe			(__NR_SVR4 +  42)
-#define __NR_SVR4_times			(__NR_SVR4 +  43)
-#define __NR_SVR4_profil		(__NR_SVR4 +  44)
-#define __NR_SVR4_plock			(__NR_SVR4 +  45)
-#define __NR_SVR4_setgid		(__NR_SVR4 +  46)
-#define __NR_SVR4_getgid		(__NR_SVR4 +  47)
-#define __NR_SVR4_sig			(__NR_SVR4 +  48)
-#define __NR_SVR4_msgsys		(__NR_SVR4 +  49)
-#define __NR_SVR4_sysmips		(__NR_SVR4 +  50)
-#define __NR_SVR4_sysacct		(__NR_SVR4 +  51)
-#define __NR_SVR4_shmsys		(__NR_SVR4 +  52)
-#define __NR_SVR4_semsys		(__NR_SVR4 +  53)
-#define __NR_SVR4_ioctl			(__NR_SVR4 +  54)
-#define __NR_SVR4_uadmin		(__NR_SVR4 +  55)
-#define __NR_SVR4_exch 			(__NR_SVR4 +  56)
-#define __NR_SVR4_utssys		(__NR_SVR4 +  57)
-#define __NR_SVR4_fsync			(__NR_SVR4 +  58)
-#define __NR_SVR4_exece			(__NR_SVR4 +  59)
-#define __NR_SVR4_umask			(__NR_SVR4 +  60)
-#define __NR_SVR4_chroot		(__NR_SVR4 +  61)
-#define __NR_SVR4_fcntl			(__NR_SVR4 +  62)
-#define __NR_SVR4_ulimit		(__NR_SVR4 +  63)
-#define __NR_SVR4_reserved1		(__NR_SVR4 +  64)
-#define __NR_SVR4_reserved2		(__NR_SVR4 +  65)
-#define __NR_SVR4_reserved3		(__NR_SVR4 +  66)
-#define __NR_SVR4_reserved4		(__NR_SVR4 +  67)
-#define __NR_SVR4_reserved5		(__NR_SVR4 +  68)
-#define __NR_SVR4_reserved6		(__NR_SVR4 +  69)
-#define __NR_SVR4_advfs			(__NR_SVR4 +  70)
-#define __NR_SVR4_unadvfs		(__NR_SVR4 +  71)
-#define __NR_SVR4_unused1		(__NR_SVR4 +  72)
-#define __NR_SVR4_unused2		(__NR_SVR4 +  73)
-#define __NR_SVR4_rfstart		(__NR_SVR4 +  74)
-#define __NR_SVR4_unused3		(__NR_SVR4 +  75)
-#define __NR_SVR4_rdebug		(__NR_SVR4 +  76)
-#define __NR_SVR4_rfstop		(__NR_SVR4 +  77)
-#define __NR_SVR4_rfsys			(__NR_SVR4 +  78)
-#define __NR_SVR4_rmdir			(__NR_SVR4 +  79)
-#define __NR_SVR4_mkdir			(__NR_SVR4 +  80)
-#define __NR_SVR4_getdents		(__NR_SVR4 +  81)
-#define __NR_SVR4_libattach		(__NR_SVR4 +  82)
-#define __NR_SVR4_libdetach		(__NR_SVR4 +  83)
-#define __NR_SVR4_sysfs			(__NR_SVR4 +  84)
-#define __NR_SVR4_getmsg		(__NR_SVR4 +  85)
-#define __NR_SVR4_putmsg		(__NR_SVR4 +  86)
-#define __NR_SVR4_poll			(__NR_SVR4 +  87)
-#define __NR_SVR4_lstat			(__NR_SVR4 +  88)
-#define __NR_SVR4_symlink		(__NR_SVR4 +  89)
-#define __NR_SVR4_readlink		(__NR_SVR4 +  90)
-#define __NR_SVR4_setgroups		(__NR_SVR4 +  91)
-#define __NR_SVR4_getgroups		(__NR_SVR4 +  92)
-#define __NR_SVR4_fchmod		(__NR_SVR4 +  93)
-#define __NR_SVR4_fchown		(__NR_SVR4 +  94)
-#define __NR_SVR4_sigprocmask		(__NR_SVR4 +  95)
-#define __NR_SVR4_sigsuspend		(__NR_SVR4 +  96)
-#define __NR_SVR4_sigaltstack		(__NR_SVR4 +  97)
-#define __NR_SVR4_sigaction		(__NR_SVR4 +  98)
-#define __NR_SVR4_sigpending		(__NR_SVR4 +  99)
-#define __NR_SVR4_setcontext		(__NR_SVR4 + 100)
-#define __NR_SVR4_evsys			(__NR_SVR4 + 101)
-#define __NR_SVR4_evtrapret		(__NR_SVR4 + 102)
-#define __NR_SVR4_statvfs		(__NR_SVR4 + 103)
-#define __NR_SVR4_fstatvfs		(__NR_SVR4 + 104)
-#define __NR_SVR4_reserved7		(__NR_SVR4 + 105)
-#define __NR_SVR4_nfssys		(__NR_SVR4 + 106)
-#define __NR_SVR4_waitid		(__NR_SVR4 + 107)
-#define __NR_SVR4_sigsendset		(__NR_SVR4 + 108)
-#define __NR_SVR4_hrtsys		(__NR_SVR4 + 109)
-#define __NR_SVR4_acancel		(__NR_SVR4 + 110)
-#define __NR_SVR4_async			(__NR_SVR4 + 111)
-#define __NR_SVR4_priocntlset		(__NR_SVR4 + 112)
-#define __NR_SVR4_pathconf		(__NR_SVR4 + 113)
-#define __NR_SVR4_mincore		(__NR_SVR4 + 114)
-#define __NR_SVR4_mmap			(__NR_SVR4 + 115)
-#define __NR_SVR4_mprotect		(__NR_SVR4 + 116)
-#define __NR_SVR4_munmap		(__NR_SVR4 + 117)
-#define __NR_SVR4_fpathconf		(__NR_SVR4 + 118)
-#define __NR_SVR4_vfork			(__NR_SVR4 + 119)
-#define __NR_SVR4_fchdir		(__NR_SVR4 + 120)
-#define __NR_SVR4_readv			(__NR_SVR4 + 121)
-#define __NR_SVR4_writev		(__NR_SVR4 + 122)
-#define __NR_SVR4_xstat			(__NR_SVR4 + 123)
-#define __NR_SVR4_lxstat		(__NR_SVR4 + 124)
-#define __NR_SVR4_fxstat		(__NR_SVR4 + 125)
-#define __NR_SVR4_xmknod		(__NR_SVR4 + 126)
-#define __NR_SVR4_clocal		(__NR_SVR4 + 127)
-#define __NR_SVR4_setrlimit		(__NR_SVR4 + 128)
-#define __NR_SVR4_getrlimit		(__NR_SVR4 + 129)
-#define __NR_SVR4_lchown		(__NR_SVR4 + 130)
-#define __NR_SVR4_memcntl		(__NR_SVR4 + 131)
-#define __NR_SVR4_getpmsg		(__NR_SVR4 + 132)
-#define __NR_SVR4_putpmsg		(__NR_SVR4 + 133)
-#define __NR_SVR4_rename		(__NR_SVR4 + 134)
-#define __NR_SVR4_nuname		(__NR_SVR4 + 135)
-#define __NR_SVR4_setegid		(__NR_SVR4 + 136)
-#define __NR_SVR4_sysconf		(__NR_SVR4 + 137)
-#define __NR_SVR4_adjtime		(__NR_SVR4 + 138)
-#define __NR_SVR4_sysinfo		(__NR_SVR4 + 139)
-#define __NR_SVR4_reserved8		(__NR_SVR4 + 140)
-#define __NR_SVR4_seteuid		(__NR_SVR4 + 141)
-#define __NR_SVR4_PYRAMID_statis	(__NR_SVR4 + 142)
-#define __NR_SVR4_PYRAMID_tuning	(__NR_SVR4 + 143)
-#define __NR_SVR4_PYRAMID_forcerr	(__NR_SVR4 + 144)
-#define __NR_SVR4_PYRAMID_mpcntl	(__NR_SVR4 + 145)
-#define __NR_SVR4_reserved9		(__NR_SVR4 + 146)
-#define __NR_SVR4_reserved10		(__NR_SVR4 + 147)
-#define __NR_SVR4_reserved11		(__NR_SVR4 + 148)
-#define __NR_SVR4_reserved12		(__NR_SVR4 + 149)
-#define __NR_SVR4_reserved13		(__NR_SVR4 + 150)
-#define __NR_SVR4_reserved14		(__NR_SVR4 + 151)
-#define __NR_SVR4_reserved15		(__NR_SVR4 + 152)
-#define __NR_SVR4_reserved16		(__NR_SVR4 + 153)
-#define __NR_SVR4_reserved17		(__NR_SVR4 + 154)
-#define __NR_SVR4_reserved18		(__NR_SVR4 + 155)
-#define __NR_SVR4_reserved19		(__NR_SVR4 + 156)
-#define __NR_SVR4_reserved20		(__NR_SVR4 + 157)
-#define __NR_SVR4_reserved21		(__NR_SVR4 + 158)
-#define __NR_SVR4_reserved22		(__NR_SVR4 + 159)
-#define __NR_SVR4_reserved23		(__NR_SVR4 + 160)
-#define __NR_SVR4_reserved24		(__NR_SVR4 + 161)
-#define __NR_SVR4_reserved25		(__NR_SVR4 + 162)
-#define __NR_SVR4_reserved26		(__NR_SVR4 + 163)
-#define __NR_SVR4_reserved27		(__NR_SVR4 + 164)
-#define __NR_SVR4_reserved28		(__NR_SVR4 + 165)
-#define __NR_SVR4_reserved29		(__NR_SVR4 + 166)
-#define __NR_SVR4_reserved30		(__NR_SVR4 + 167)
-#define __NR_SVR4_reserved31		(__NR_SVR4 + 168)
-#define __NR_SVR4_reserved32		(__NR_SVR4 + 169)
-#define __NR_SVR4_reserved33		(__NR_SVR4 + 170)
-#define __NR_SVR4_reserved34		(__NR_SVR4 + 171)
-#define __NR_SVR4_reserved35		(__NR_SVR4 + 172)
-#define __NR_SVR4_reserved36		(__NR_SVR4 + 173)
-#define __NR_SVR4_reserved37		(__NR_SVR4 + 174)
-#define __NR_SVR4_reserved38		(__NR_SVR4 + 175)
-#define __NR_SVR4_reserved39		(__NR_SVR4 + 176)
-#define __NR_SVR4_reserved40		(__NR_SVR4 + 177)
-#define __NR_SVR4_reserved41		(__NR_SVR4 + 178)
-#define __NR_SVR4_reserved42		(__NR_SVR4 + 179)
-#define __NR_SVR4_reserved43		(__NR_SVR4 + 180)
-#define __NR_SVR4_reserved44		(__NR_SVR4 + 181)
-#define __NR_SVR4_reserved45		(__NR_SVR4 + 182)
-#define __NR_SVR4_reserved46		(__NR_SVR4 + 183)
-#define __NR_SVR4_reserved47		(__NR_SVR4 + 184)
-#define __NR_SVR4_reserved48		(__NR_SVR4 + 185)
-#define __NR_SVR4_reserved49		(__NR_SVR4 + 186)
-#define __NR_SVR4_reserved50		(__NR_SVR4 + 187)
-#define __NR_SVR4_reserved51		(__NR_SVR4 + 188)
-#define __NR_SVR4_reserved52		(__NR_SVR4 + 189)
-#define __NR_SVR4_reserved53		(__NR_SVR4 + 190)
-#define __NR_SVR4_reserved54		(__NR_SVR4 + 191)
-#define __NR_SVR4_reserved55		(__NR_SVR4 + 192)
-#define __NR_SVR4_reserved56		(__NR_SVR4 + 193)
-#define __NR_SVR4_reserved57		(__NR_SVR4 + 194)
-#define __NR_SVR4_reserved58		(__NR_SVR4 + 195)
-#define __NR_SVR4_reserved59		(__NR_SVR4 + 196)
-#define __NR_SVR4_reserved60		(__NR_SVR4 + 197)
-#define __NR_SVR4_reserved61		(__NR_SVR4 + 198)
-#define __NR_SVR4_reserved62		(__NR_SVR4 + 199)
-#define __NR_SVR4_reserved63		(__NR_SVR4 + 200)
-#define __NR_SVR4_aread			(__NR_SVR4 + 201)
-#define __NR_SVR4_awrite		(__NR_SVR4 + 202)
-#define __NR_SVR4_listio		(__NR_SVR4 + 203)
-#define __NR_SVR4_mips_acancel		(__NR_SVR4 + 204)
-#define __NR_SVR4_astatus		(__NR_SVR4 + 205)
-#define __NR_SVR4_await			(__NR_SVR4 + 206)
-#define __NR_SVR4_areadv		(__NR_SVR4 + 207)
-#define __NR_SVR4_awritev		(__NR_SVR4 + 208)
-#define __NR_SVR4_MIPS_reserved1	(__NR_SVR4 + 209)
-#define __NR_SVR4_MIPS_reserved2	(__NR_SVR4 + 210)
-#define __NR_SVR4_MIPS_reserved3	(__NR_SVR4 + 211)
-#define __NR_SVR4_MIPS_reserved4	(__NR_SVR4 + 212)
-#define __NR_SVR4_MIPS_reserved5	(__NR_SVR4 + 213)
-#define __NR_SVR4_MIPS_reserved6	(__NR_SVR4 + 214)
-#define __NR_SVR4_MIPS_reserved7	(__NR_SVR4 + 215)
-#define __NR_SVR4_MIPS_reserved8	(__NR_SVR4 + 216)
-#define __NR_SVR4_MIPS_reserved9	(__NR_SVR4 + 217)
-#define __NR_SVR4_MIPS_reserved10	(__NR_SVR4 + 218)
-#define __NR_SVR4_MIPS_reserved11	(__NR_SVR4 + 219)
-#define __NR_SVR4_MIPS_reserved12	(__NR_SVR4 + 220)
-#define __NR_SVR4_CDC_reserved1		(__NR_SVR4 + 221)
-#define __NR_SVR4_CDC_reserved2		(__NR_SVR4 + 222)
-#define __NR_SVR4_CDC_reserved3		(__NR_SVR4 + 223)
-#define __NR_SVR4_CDC_reserved4		(__NR_SVR4 + 224)
-#define __NR_SVR4_CDC_reserved5		(__NR_SVR4 + 225)
-#define __NR_SVR4_CDC_reserved6		(__NR_SVR4 + 226)
-#define __NR_SVR4_CDC_reserved7		(__NR_SVR4 + 227)
-#define __NR_SVR4_CDC_reserved8		(__NR_SVR4 + 228)
-#define __NR_SVR4_CDC_reserved9		(__NR_SVR4 + 229)
-#define __NR_SVR4_CDC_reserved10	(__NR_SVR4 + 230)
-#define __NR_SVR4_CDC_reserved11	(__NR_SVR4 + 231)
-#define __NR_SVR4_CDC_reserved12	(__NR_SVR4 + 232)
-#define __NR_SVR4_CDC_reserved13	(__NR_SVR4 + 233)
-#define __NR_SVR4_CDC_reserved14	(__NR_SVR4 + 234)
-#define __NR_SVR4_CDC_reserved15	(__NR_SVR4 + 235)
-#define __NR_SVR4_CDC_reserved16	(__NR_SVR4 + 236)
-#define __NR_SVR4_CDC_reserved17	(__NR_SVR4 + 237)
-#define __NR_SVR4_CDC_reserved18	(__NR_SVR4 + 238)
-#define __NR_SVR4_CDC_reserved19	(__NR_SVR4 + 239)
-#define __NR_SVR4_CDC_reserved20	(__NR_SVR4 + 240)
-
-/*
- * SYS V syscalls are in the range from 1000 to 1999
- */
-#define __NR_SYSV			1000
-#define __NR_SYSV_syscall		(__NR_SYSV +   0)
-#define __NR_SYSV_exit			(__NR_SYSV +   1)
-#define __NR_SYSV_fork			(__NR_SYSV +   2)
-#define __NR_SYSV_read			(__NR_SYSV +   3)
-#define __NR_SYSV_write			(__NR_SYSV +   4)
-#define __NR_SYSV_open			(__NR_SYSV +   5)
-#define __NR_SYSV_close			(__NR_SYSV +   6)
-#define __NR_SYSV_wait			(__NR_SYSV +   7)
-#define __NR_SYSV_creat			(__NR_SYSV +   8)
-#define __NR_SYSV_link			(__NR_SYSV +   9)
-#define __NR_SYSV_unlink		(__NR_SYSV +  10)
-#define __NR_SYSV_execv			(__NR_SYSV +  11)
-#define __NR_SYSV_chdir			(__NR_SYSV +  12)
-#define __NR_SYSV_time			(__NR_SYSV +  13)
-#define __NR_SYSV_mknod			(__NR_SYSV +  14)
-#define __NR_SYSV_chmod			(__NR_SYSV +  15)
-#define __NR_SYSV_chown			(__NR_SYSV +  16)
-#define __NR_SYSV_brk			(__NR_SYSV +  17)
-#define __NR_SYSV_stat			(__NR_SYSV +  18)
-#define __NR_SYSV_lseek			(__NR_SYSV +  19)
-#define __NR_SYSV_getpid		(__NR_SYSV +  20)
-#define __NR_SYSV_mount			(__NR_SYSV +  21)
-#define __NR_SYSV_umount		(__NR_SYSV +  22)
-#define __NR_SYSV_setuid		(__NR_SYSV +  23)
-#define __NR_SYSV_getuid		(__NR_SYSV +  24)
-#define __NR_SYSV_stime			(__NR_SYSV +  25)
-#define __NR_SYSV_ptrace		(__NR_SYSV +  26)
-#define __NR_SYSV_alarm			(__NR_SYSV +  27)
-#define __NR_SYSV_fstat			(__NR_SYSV +  28)
-#define __NR_SYSV_pause			(__NR_SYSV +  29)
-#define __NR_SYSV_utime			(__NR_SYSV +  30)
-#define __NR_SYSV_stty			(__NR_SYSV +  31)
-#define __NR_SYSV_gtty			(__NR_SYSV +  32)
-#define __NR_SYSV_access		(__NR_SYSV +  33)
-#define __NR_SYSV_nice			(__NR_SYSV +  34)
-#define __NR_SYSV_statfs		(__NR_SYSV +  35)
-#define __NR_SYSV_sync			(__NR_SYSV +  36)
-#define __NR_SYSV_kill			(__NR_SYSV +  37)
-#define __NR_SYSV_fstatfs		(__NR_SYSV +  38)
-#define __NR_SYSV_setpgrp		(__NR_SYSV +  39)
-#define __NR_SYSV_syssgi		(__NR_SYSV +  40)
-#define __NR_SYSV_dup			(__NR_SYSV +  41)
-#define __NR_SYSV_pipe			(__NR_SYSV +  42)
-#define __NR_SYSV_times			(__NR_SYSV +  43)
-#define __NR_SYSV_profil		(__NR_SYSV +  44)
-#define __NR_SYSV_plock			(__NR_SYSV +  45)
-#define __NR_SYSV_setgid		(__NR_SYSV +  46)
-#define __NR_SYSV_getgid		(__NR_SYSV +  47)
-#define __NR_SYSV_sig			(__NR_SYSV +  48)
-#define __NR_SYSV_msgsys		(__NR_SYSV +  49)
-#define __NR_SYSV_sysmips		(__NR_SYSV +  50)
-#define __NR_SYSV_acct			(__NR_SYSV +  51)
-#define __NR_SYSV_shmsys		(__NR_SYSV +  52)
-#define __NR_SYSV_semsys		(__NR_SYSV +  53)
-#define __NR_SYSV_ioctl			(__NR_SYSV +  54)
-#define __NR_SYSV_uadmin		(__NR_SYSV +  55)
-#define __NR_SYSV_sysmp			(__NR_SYSV +  56)
-#define __NR_SYSV_utssys		(__NR_SYSV +  57)
-#define __NR_SYSV_USG_reserved1		(__NR_SYSV +  58)
-#define __NR_SYSV_execve		(__NR_SYSV +  59)
-#define __NR_SYSV_umask			(__NR_SYSV +  60)
-#define __NR_SYSV_chroot		(__NR_SYSV +  61)
-#define __NR_SYSV_fcntl			(__NR_SYSV +  62)
-#define __NR_SYSV_ulimit		(__NR_SYSV +  63)
-#define __NR_SYSV_SAFARI4_reserved1	(__NR_SYSV +  64)
-#define __NR_SYSV_SAFARI4_reserved2	(__NR_SYSV +  65)
-#define __NR_SYSV_SAFARI4_reserved3	(__NR_SYSV +  66)
-#define __NR_SYSV_SAFARI4_reserved4	(__NR_SYSV +  67)
-#define __NR_SYSV_SAFARI4_reserved5	(__NR_SYSV +  68)
-#define __NR_SYSV_SAFARI4_reserved6	(__NR_SYSV +  69)
-#define __NR_SYSV_advfs			(__NR_SYSV +  70)
-#define __NR_SYSV_unadvfs		(__NR_SYSV +  71)
-#define __NR_SYSV_rmount		(__NR_SYSV +  72)
-#define __NR_SYSV_rumount		(__NR_SYSV +  73)
-#define __NR_SYSV_rfstart		(__NR_SYSV +  74)
-#define __NR_SYSV_getrlimit64		(__NR_SYSV +  75)
-#define __NR_SYSV_setrlimit64		(__NR_SYSV +  76)
-#define __NR_SYSV_nanosleep		(__NR_SYSV +  77)
-#define __NR_SYSV_lseek64		(__NR_SYSV +  78)
-#define __NR_SYSV_rmdir			(__NR_SYSV +  79)
-#define __NR_SYSV_mkdir			(__NR_SYSV +  80)
-#define __NR_SYSV_getdents		(__NR_SYSV +  81)
-#define __NR_SYSV_sginap		(__NR_SYSV +  82)
-#define __NR_SYSV_sgikopt		(__NR_SYSV +  83)
-#define __NR_SYSV_sysfs			(__NR_SYSV +  84)
-#define __NR_SYSV_getmsg		(__NR_SYSV +  85)
-#define __NR_SYSV_putmsg		(__NR_SYSV +  86)
-#define __NR_SYSV_poll			(__NR_SYSV +  87)
-#define __NR_SYSV_sigreturn		(__NR_SYSV +  88)
-#define __NR_SYSV_accept		(__NR_SYSV +  89)
-#define __NR_SYSV_bind			(__NR_SYSV +  90)
-#define __NR_SYSV_connect		(__NR_SYSV +  91)
-#define __NR_SYSV_gethostid		(__NR_SYSV +  92)
-#define __NR_SYSV_getpeername		(__NR_SYSV +  93)
-#define __NR_SYSV_getsockname		(__NR_SYSV +  94)
-#define __NR_SYSV_getsockopt		(__NR_SYSV +  95)
-#define __NR_SYSV_listen		(__NR_SYSV +  96)
-#define __NR_SYSV_recv			(__NR_SYSV +  97)
-#define __NR_SYSV_recvfrom		(__NR_SYSV +  98)
-#define __NR_SYSV_recvmsg		(__NR_SYSV +  99)
-#define __NR_SYSV_select		(__NR_SYSV + 100)
-#define __NR_SYSV_send			(__NR_SYSV + 101)
-#define __NR_SYSV_sendmsg		(__NR_SYSV + 102)
-#define __NR_SYSV_sendto		(__NR_SYSV + 103)
-#define __NR_SYSV_sethostid		(__NR_SYSV + 104)
-#define __NR_SYSV_setsockopt		(__NR_SYSV + 105)
-#define __NR_SYSV_shutdown		(__NR_SYSV + 106)
-#define __NR_SYSV_socket		(__NR_SYSV + 107)
-#define __NR_SYSV_gethostname		(__NR_SYSV + 108)
-#define __NR_SYSV_sethostname		(__NR_SYSV + 109)
-#define __NR_SYSV_getdomainname		(__NR_SYSV + 110)
-#define __NR_SYSV_setdomainname		(__NR_SYSV + 111)
-#define __NR_SYSV_truncate		(__NR_SYSV + 112)
-#define __NR_SYSV_ftruncate		(__NR_SYSV + 113)
-#define __NR_SYSV_rename		(__NR_SYSV + 114)
-#define __NR_SYSV_symlink		(__NR_SYSV + 115)
-#define __NR_SYSV_readlink		(__NR_SYSV + 116)
-#define __NR_SYSV_lstat			(__NR_SYSV + 117)
-#define __NR_SYSV_nfsmount		(__NR_SYSV + 118)
-#define __NR_SYSV_nfssvc		(__NR_SYSV + 119)
-#define __NR_SYSV_getfh			(__NR_SYSV + 120)
-#define __NR_SYSV_async_daemon		(__NR_SYSV + 121)
-#define __NR_SYSV_exportfs		(__NR_SYSV + 122)
-#define __NR_SYSV_setregid		(__NR_SYSV + 123)
-#define __NR_SYSV_setreuid		(__NR_SYSV + 124)
-#define __NR_SYSV_getitimer		(__NR_SYSV + 125)
-#define __NR_SYSV_setitimer		(__NR_SYSV + 126)
-#define __NR_SYSV_adjtime		(__NR_SYSV + 127)
-#define __NR_SYSV_BSD_getime		(__NR_SYSV + 128)
-#define __NR_SYSV_sproc			(__NR_SYSV + 129)
-#define __NR_SYSV_prctl			(__NR_SYSV + 130)
-#define __NR_SYSV_procblk		(__NR_SYSV + 131)
-#define __NR_SYSV_sprocsp		(__NR_SYSV + 132)
-#define __NR_SYSV_sgigsc		(__NR_SYSV + 133)
-#define __NR_SYSV_mmap			(__NR_SYSV + 134)
-#define __NR_SYSV_munmap		(__NR_SYSV + 135)
-#define __NR_SYSV_mprotect		(__NR_SYSV + 136)
-#define __NR_SYSV_msync			(__NR_SYSV + 137)
-#define __NR_SYSV_madvise		(__NR_SYSV + 138)
-#define __NR_SYSV_pagelock		(__NR_SYSV + 139)
-#define __NR_SYSV_getpagesize		(__NR_SYSV + 140)
-#define __NR_SYSV_quotactl		(__NR_SYSV + 141)
-#define __NR_SYSV_libdetach		(__NR_SYSV + 142)
-#define __NR_SYSV_BSDgetpgrp		(__NR_SYSV + 143)
-#define __NR_SYSV_BSDsetpgrp		(__NR_SYSV + 144)
-#define __NR_SYSV_vhangup		(__NR_SYSV + 145)
-#define __NR_SYSV_fsync			(__NR_SYSV + 146)
-#define __NR_SYSV_fchdir		(__NR_SYSV + 147)
-#define __NR_SYSV_getrlimit		(__NR_SYSV + 148)
-#define __NR_SYSV_setrlimit		(__NR_SYSV + 149)
-#define __NR_SYSV_cacheflush		(__NR_SYSV + 150)
-#define __NR_SYSV_cachectl		(__NR_SYSV + 151)
-#define __NR_SYSV_fchown		(__NR_SYSV + 152)
-#define __NR_SYSV_fchmod		(__NR_SYSV + 153)
-#define __NR_SYSV_wait3			(__NR_SYSV + 154)
-#define __NR_SYSV_socketpair		(__NR_SYSV + 155)
-#define __NR_SYSV_sysinfo		(__NR_SYSV + 156)
-#define __NR_SYSV_nuname		(__NR_SYSV + 157)
-#define __NR_SYSV_xstat			(__NR_SYSV + 158)
-#define __NR_SYSV_lxstat		(__NR_SYSV + 159)
-#define __NR_SYSV_fxstat		(__NR_SYSV + 160)
-#define __NR_SYSV_xmknod		(__NR_SYSV + 161)
-#define __NR_SYSV_ksigaction		(__NR_SYSV + 162)
-#define __NR_SYSV_sigpending		(__NR_SYSV + 163)
-#define __NR_SYSV_sigprocmask		(__NR_SYSV + 164)
-#define __NR_SYSV_sigsuspend		(__NR_SYSV + 165)
-#define __NR_SYSV_sigpoll		(__NR_SYSV + 166)
-#define __NR_SYSV_swapctl		(__NR_SYSV + 167)
-#define __NR_SYSV_getcontext		(__NR_SYSV + 168)
-#define __NR_SYSV_setcontext		(__NR_SYSV + 169)
-#define __NR_SYSV_waitsys		(__NR_SYSV + 170)
-#define __NR_SYSV_sigstack		(__NR_SYSV + 171)
-#define __NR_SYSV_sigaltstack		(__NR_SYSV + 172)
-#define __NR_SYSV_sigsendset		(__NR_SYSV + 173)
-#define __NR_SYSV_statvfs		(__NR_SYSV + 174)
-#define __NR_SYSV_fstatvfs		(__NR_SYSV + 175)
-#define __NR_SYSV_getpmsg		(__NR_SYSV + 176)
-#define __NR_SYSV_putpmsg		(__NR_SYSV + 177)
-#define __NR_SYSV_lchown		(__NR_SYSV + 178)
-#define __NR_SYSV_priocntl		(__NR_SYSV + 179)
-#define __NR_SYSV_ksigqueue		(__NR_SYSV + 180)
-#define __NR_SYSV_readv			(__NR_SYSV + 181)
-#define __NR_SYSV_writev		(__NR_SYSV + 182)
-#define __NR_SYSV_truncate64		(__NR_SYSV + 183)
-#define __NR_SYSV_ftruncate64		(__NR_SYSV + 184)
-#define __NR_SYSV_mmap64		(__NR_SYSV + 185)
-#define __NR_SYSV_dmi			(__NR_SYSV + 186)
-#define __NR_SYSV_pread			(__NR_SYSV + 187)
-#define __NR_SYSV_pwrite		(__NR_SYSV + 188)
-
-/*
- * BSD 4.3 syscalls are in the range from 2000 to 2999
- */
-#define __NR_BSD43			2000
-#define __NR_BSD43_syscall		(__NR_BSD43 +   0)
-#define __NR_BSD43_exit			(__NR_BSD43 +   1)
-#define __NR_BSD43_fork			(__NR_BSD43 +   2)
-#define __NR_BSD43_read			(__NR_BSD43 +   3)
-#define __NR_BSD43_write		(__NR_BSD43 +   4)
-#define __NR_BSD43_open			(__NR_BSD43 +   5)
-#define __NR_BSD43_close		(__NR_BSD43 +   6)
-#define __NR_BSD43_wait			(__NR_BSD43 +   7)
-#define __NR_BSD43_creat		(__NR_BSD43 +   8)
-#define __NR_BSD43_link			(__NR_BSD43 +   9)
-#define __NR_BSD43_unlink		(__NR_BSD43 +  10)
-#define __NR_BSD43_exec			(__NR_BSD43 +  11)
-#define __NR_BSD43_chdir		(__NR_BSD43 +  12)
-#define __NR_BSD43_time			(__NR_BSD43 +  13)
-#define __NR_BSD43_mknod		(__NR_BSD43 +  14)
-#define __NR_BSD43_chmod		(__NR_BSD43 +  15)
-#define __NR_BSD43_chown		(__NR_BSD43 +  16)
-#define __NR_BSD43_sbreak		(__NR_BSD43 +  17)
-#define __NR_BSD43_oldstat		(__NR_BSD43 +  18)
-#define __NR_BSD43_lseek		(__NR_BSD43 +  19)
-#define __NR_BSD43_getpid		(__NR_BSD43 +  20)
-#define __NR_BSD43_oldmount		(__NR_BSD43 +  21)
-#define __NR_BSD43_umount		(__NR_BSD43 +  22)
-#define __NR_BSD43_setuid		(__NR_BSD43 +  23)
-#define __NR_BSD43_getuid		(__NR_BSD43 +  24)
-#define __NR_BSD43_stime		(__NR_BSD43 +  25)
-#define __NR_BSD43_ptrace		(__NR_BSD43 +  26)
-#define __NR_BSD43_alarm		(__NR_BSD43 +  27)
-#define __NR_BSD43_oldfstat		(__NR_BSD43 +  28)
-#define __NR_BSD43_pause		(__NR_BSD43 +  29)
-#define __NR_BSD43_utime		(__NR_BSD43 +  30)
-#define __NR_BSD43_stty			(__NR_BSD43 +  31)
-#define __NR_BSD43_gtty			(__NR_BSD43 +  32)
-#define __NR_BSD43_access		(__NR_BSD43 +  33)
-#define __NR_BSD43_nice			(__NR_BSD43 +  34)
-#define __NR_BSD43_ftime		(__NR_BSD43 +  35)
-#define __NR_BSD43_sync			(__NR_BSD43 +  36)
-#define __NR_BSD43_kill			(__NR_BSD43 +  37)
-#define __NR_BSD43_stat			(__NR_BSD43 +  38)
-#define __NR_BSD43_oldsetpgrp		(__NR_BSD43 +  39)
-#define __NR_BSD43_lstat		(__NR_BSD43 +  40)
-#define __NR_BSD43_dup			(__NR_BSD43 +  41)
-#define __NR_BSD43_pipe			(__NR_BSD43 +  42)
-#define __NR_BSD43_times		(__NR_BSD43 +  43)
-#define __NR_BSD43_profil		(__NR_BSD43 +  44)
-#define __NR_BSD43_msgsys		(__NR_BSD43 +  45)
-#define __NR_BSD43_setgid		(__NR_BSD43 +  46)
-#define __NR_BSD43_getgid		(__NR_BSD43 +  47)
-#define __NR_BSD43_ssig			(__NR_BSD43 +  48)
-#define __NR_BSD43_reserved1		(__NR_BSD43 +  49)
-#define __NR_BSD43_reserved2		(__NR_BSD43 +  50)
-#define __NR_BSD43_sysacct		(__NR_BSD43 +  51)
-#define __NR_BSD43_phys			(__NR_BSD43 +  52)
-#define __NR_BSD43_lock			(__NR_BSD43 +  53)
-#define __NR_BSD43_ioctl		(__NR_BSD43 +  54)
-#define __NR_BSD43_reboot		(__NR_BSD43 +  55)
-#define __NR_BSD43_mpxchan		(__NR_BSD43 +  56)
-#define __NR_BSD43_symlink		(__NR_BSD43 +  57)
-#define __NR_BSD43_readlink		(__NR_BSD43 +  58)
-#define __NR_BSD43_execve		(__NR_BSD43 +  59)
-#define __NR_BSD43_umask		(__NR_BSD43 +  60)
-#define __NR_BSD43_chroot		(__NR_BSD43 +  61)
-#define __NR_BSD43_fstat		(__NR_BSD43 +  62)
-#define __NR_BSD43_reserved3		(__NR_BSD43 +  63)
-#define __NR_BSD43_getpagesize		(__NR_BSD43 +  64)
-#define __NR_BSD43_mremap		(__NR_BSD43 +  65)
-#define __NR_BSD43_vfork		(__NR_BSD43 +  66)
-#define __NR_BSD43_vread		(__NR_BSD43 +  67)
-#define __NR_BSD43_vwrite		(__NR_BSD43 +  68)
-#define __NR_BSD43_sbrk			(__NR_BSD43 +  69)
-#define __NR_BSD43_sstk			(__NR_BSD43 +  70)
-#define __NR_BSD43_mmap			(__NR_BSD43 +  71)
-#define __NR_BSD43_vadvise		(__NR_BSD43 +  72)
-#define __NR_BSD43_munmap		(__NR_BSD43 +  73)
-#define __NR_BSD43_mprotect		(__NR_BSD43 +  74)
-#define __NR_BSD43_madvise		(__NR_BSD43 +  75)
-#define __NR_BSD43_vhangup		(__NR_BSD43 +  76)
-#define __NR_BSD43_vlimit		(__NR_BSD43 +  77)
-#define __NR_BSD43_mincore		(__NR_BSD43 +  78)
-#define __NR_BSD43_getgroups		(__NR_BSD43 +  79)
-#define __NR_BSD43_setgroups		(__NR_BSD43 +  80)
-#define __NR_BSD43_getpgrp		(__NR_BSD43 +  81)
-#define __NR_BSD43_setpgrp		(__NR_BSD43 +  82)
-#define __NR_BSD43_setitimer		(__NR_BSD43 +  83)
-#define __NR_BSD43_wait3		(__NR_BSD43 +  84)
-#define __NR_BSD43_swapon		(__NR_BSD43 +  85)
-#define __NR_BSD43_getitimer		(__NR_BSD43 +  86)
-#define __NR_BSD43_gethostname		(__NR_BSD43 +  87)
-#define __NR_BSD43_sethostname		(__NR_BSD43 +  88)
-#define __NR_BSD43_getdtablesize	(__NR_BSD43 +  89)
-#define __NR_BSD43_dup2			(__NR_BSD43 +  90)
-#define __NR_BSD43_getdopt		(__NR_BSD43 +  91)
-#define __NR_BSD43_fcntl		(__NR_BSD43 +  92)
-#define __NR_BSD43_select		(__NR_BSD43 +  93)
-#define __NR_BSD43_setdopt		(__NR_BSD43 +  94)
-#define __NR_BSD43_fsync		(__NR_BSD43 +  95)
-#define __NR_BSD43_setpriority		(__NR_BSD43 +  96)
-#define __NR_BSD43_socket		(__NR_BSD43 +  97)
-#define __NR_BSD43_connect		(__NR_BSD43 +  98)
-#define __NR_BSD43_oldaccept		(__NR_BSD43 +  99)
-#define __NR_BSD43_getpriority		(__NR_BSD43 + 100)
-#define __NR_BSD43_send			(__NR_BSD43 + 101)
-#define __NR_BSD43_recv			(__NR_BSD43 + 102)
-#define __NR_BSD43_sigreturn		(__NR_BSD43 + 103)
-#define __NR_BSD43_bind			(__NR_BSD43 + 104)
-#define __NR_BSD43_setsockopt		(__NR_BSD43 + 105)
-#define __NR_BSD43_listen		(__NR_BSD43 + 106)
-#define __NR_BSD43_vtimes		(__NR_BSD43 + 107)
-#define __NR_BSD43_sigvec		(__NR_BSD43 + 108)
-#define __NR_BSD43_sigblock		(__NR_BSD43 + 109)
-#define __NR_BSD43_sigsetmask		(__NR_BSD43 + 110)
-#define __NR_BSD43_sigpause		(__NR_BSD43 + 111)
-#define __NR_BSD43_sigstack		(__NR_BSD43 + 112)
-#define __NR_BSD43_oldrecvmsg		(__NR_BSD43 + 113)
-#define __NR_BSD43_oldsendmsg		(__NR_BSD43 + 114)
-#define __NR_BSD43_vtrace		(__NR_BSD43 + 115)
-#define __NR_BSD43_gettimeofday		(__NR_BSD43 + 116)
-#define __NR_BSD43_getrusage		(__NR_BSD43 + 117)
-#define __NR_BSD43_getsockopt		(__NR_BSD43 + 118)
-#define __NR_BSD43_reserved4		(__NR_BSD43 + 119)
-#define __NR_BSD43_readv		(__NR_BSD43 + 120)
-#define __NR_BSD43_writev		(__NR_BSD43 + 121)
-#define __NR_BSD43_settimeofday		(__NR_BSD43 + 122)
-#define __NR_BSD43_fchown		(__NR_BSD43 + 123)
-#define __NR_BSD43_fchmod		(__NR_BSD43 + 124)
-#define __NR_BSD43_oldrecvfrom		(__NR_BSD43 + 125)
-#define __NR_BSD43_setreuid		(__NR_BSD43 + 126)
-#define __NR_BSD43_setregid		(__NR_BSD43 + 127)
-#define __NR_BSD43_rename		(__NR_BSD43 + 128)
-#define __NR_BSD43_truncate		(__NR_BSD43 + 129)
-#define __NR_BSD43_ftruncate		(__NR_BSD43 + 130)
-#define __NR_BSD43_flock		(__NR_BSD43 + 131)
-#define __NR_BSD43_semsys		(__NR_BSD43 + 132)
-#define __NR_BSD43_sendto		(__NR_BSD43 + 133)
-#define __NR_BSD43_shutdown		(__NR_BSD43 + 134)
-#define __NR_BSD43_socketpair		(__NR_BSD43 + 135)
-#define __NR_BSD43_mkdir		(__NR_BSD43 + 136)
-#define __NR_BSD43_rmdir		(__NR_BSD43 + 137)
-#define __NR_BSD43_utimes		(__NR_BSD43 + 138)
-#define __NR_BSD43_sigcleanup		(__NR_BSD43 + 139)
-#define __NR_BSD43_adjtime		(__NR_BSD43 + 140)
-#define __NR_BSD43_oldgetpeername	(__NR_BSD43 + 141)
-#define __NR_BSD43_gethostid		(__NR_BSD43 + 142)
-#define __NR_BSD43_sethostid		(__NR_BSD43 + 143)
-#define __NR_BSD43_getrlimit		(__NR_BSD43 + 144)
-#define __NR_BSD43_setrlimit		(__NR_BSD43 + 145)
-#define __NR_BSD43_killpg		(__NR_BSD43 + 146)
-#define __NR_BSD43_shmsys		(__NR_BSD43 + 147)
-#define __NR_BSD43_quota		(__NR_BSD43 + 148)
-#define __NR_BSD43_qquota		(__NR_BSD43 + 149)
-#define __NR_BSD43_oldgetsockname	(__NR_BSD43 + 150)
-#define __NR_BSD43_sysmips		(__NR_BSD43 + 151)
-#define __NR_BSD43_cacheflush		(__NR_BSD43 + 152)
-#define __NR_BSD43_cachectl		(__NR_BSD43 + 153)
-#define __NR_BSD43_debug		(__NR_BSD43 + 154)
-#define __NR_BSD43_reserved5		(__NR_BSD43 + 155)
-#define __NR_BSD43_reserved6		(__NR_BSD43 + 156)
-#define __NR_BSD43_nfs_mount		(__NR_BSD43 + 157)
-#define __NR_BSD43_nfs_svc		(__NR_BSD43 + 158)
-#define __NR_BSD43_getdirentries	(__NR_BSD43 + 159)
-#define __NR_BSD43_statfs		(__NR_BSD43 + 160)
-#define __NR_BSD43_fstatfs		(__NR_BSD43 + 161)
-#define __NR_BSD43_unmount		(__NR_BSD43 + 162)
-#define __NR_BSD43_async_daemon		(__NR_BSD43 + 163)
-#define __NR_BSD43_nfs_getfh		(__NR_BSD43 + 164)
-#define __NR_BSD43_getdomainname	(__NR_BSD43 + 165)
-#define __NR_BSD43_setdomainname	(__NR_BSD43 + 166)
-#define __NR_BSD43_pcfs_mount		(__NR_BSD43 + 167)
-#define __NR_BSD43_quotactl		(__NR_BSD43 + 168)
-#define __NR_BSD43_oldexportfs		(__NR_BSD43 + 169)
-#define __NR_BSD43_smount		(__NR_BSD43 + 170)
-#define __NR_BSD43_mipshwconf		(__NR_BSD43 + 171)
-#define __NR_BSD43_exportfs		(__NR_BSD43 + 172)
-#define __NR_BSD43_nfsfh_open		(__NR_BSD43 + 173)
-#define __NR_BSD43_libattach		(__NR_BSD43 + 174)
-#define __NR_BSD43_libdetach		(__NR_BSD43 + 175)
-#define __NR_BSD43_accept		(__NR_BSD43 + 176)
-#define __NR_BSD43_reserved7		(__NR_BSD43 + 177)
-#define __NR_BSD43_reserved8		(__NR_BSD43 + 178)
-#define __NR_BSD43_recvmsg		(__NR_BSD43 + 179)
-#define __NR_BSD43_recvfrom		(__NR_BSD43 + 180)
-#define __NR_BSD43_sendmsg		(__NR_BSD43 + 181)
-#define __NR_BSD43_getpeername		(__NR_BSD43 + 182)
-#define __NR_BSD43_getsockname		(__NR_BSD43 + 183)
-#define __NR_BSD43_aread		(__NR_BSD43 + 184)
-#define __NR_BSD43_awrite		(__NR_BSD43 + 185)
-#define __NR_BSD43_listio		(__NR_BSD43 + 186)
-#define __NR_BSD43_acancel		(__NR_BSD43 + 187)
-#define __NR_BSD43_astatus		(__NR_BSD43 + 188)
-#define __NR_BSD43_await		(__NR_BSD43 + 189)
-#define __NR_BSD43_areadv		(__NR_BSD43 + 190)
-#define __NR_BSD43_awritev		(__NR_BSD43 + 191)
-
-/*
- * POSIX syscalls are in the range from 3000 to 3999
- */
-#define __NR_POSIX			3000
-#define __NR_POSIX_syscall		(__NR_POSIX +   0)
-#define __NR_POSIX_exit			(__NR_POSIX +   1)
-#define __NR_POSIX_fork			(__NR_POSIX +   2)
-#define __NR_POSIX_read			(__NR_POSIX +   3)
-#define __NR_POSIX_write		(__NR_POSIX +   4)
-#define __NR_POSIX_open			(__NR_POSIX +   5)
-#define __NR_POSIX_close		(__NR_POSIX +   6)
-#define __NR_POSIX_wait			(__NR_POSIX +   7)
-#define __NR_POSIX_creat		(__NR_POSIX +   8)
-#define __NR_POSIX_link			(__NR_POSIX +   9)
-#define __NR_POSIX_unlink		(__NR_POSIX +  10)
-#define __NR_POSIX_exec			(__NR_POSIX +  11)
-#define __NR_POSIX_chdir		(__NR_POSIX +  12)
-#define __NR_POSIX_gtime		(__NR_POSIX +  13)
-#define __NR_POSIX_mknod		(__NR_POSIX +  14)
-#define __NR_POSIX_chmod		(__NR_POSIX +  15)
-#define __NR_POSIX_chown		(__NR_POSIX +  16)
-#define __NR_POSIX_sbreak		(__NR_POSIX +  17)
-#define __NR_POSIX_stat			(__NR_POSIX +  18)
-#define __NR_POSIX_lseek		(__NR_POSIX +  19)
-#define __NR_POSIX_getpid		(__NR_POSIX +  20)
-#define __NR_POSIX_mount		(__NR_POSIX +  21)
-#define __NR_POSIX_umount		(__NR_POSIX +  22)
-#define __NR_POSIX_setuid		(__NR_POSIX +  23)
-#define __NR_POSIX_getuid		(__NR_POSIX +  24)
-#define __NR_POSIX_stime		(__NR_POSIX +  25)
-#define __NR_POSIX_ptrace		(__NR_POSIX +  26)
-#define __NR_POSIX_alarm		(__NR_POSIX +  27)
-#define __NR_POSIX_fstat		(__NR_POSIX +  28)
-#define __NR_POSIX_pause		(__NR_POSIX +  29)
-#define __NR_POSIX_utime		(__NR_POSIX +  30)
-#define __NR_POSIX_stty			(__NR_POSIX +  31)
-#define __NR_POSIX_gtty			(__NR_POSIX +  32)
-#define __NR_POSIX_access		(__NR_POSIX +  33)
-#define __NR_POSIX_nice			(__NR_POSIX +  34)
-#define __NR_POSIX_statfs		(__NR_POSIX +  35)
-#define __NR_POSIX_sync			(__NR_POSIX +  36)
-#define __NR_POSIX_kill			(__NR_POSIX +  37)
-#define __NR_POSIX_fstatfs		(__NR_POSIX +  38)
-#define __NR_POSIX_getpgrp		(__NR_POSIX +  39)
-#define __NR_POSIX_syssgi		(__NR_POSIX +  40)
-#define __NR_POSIX_dup			(__NR_POSIX +  41)
-#define __NR_POSIX_pipe			(__NR_POSIX +  42)
-#define __NR_POSIX_times		(__NR_POSIX +  43)
-#define __NR_POSIX_profil		(__NR_POSIX +  44)
-#define __NR_POSIX_lock			(__NR_POSIX +  45)
-#define __NR_POSIX_setgid		(__NR_POSIX +  46)
-#define __NR_POSIX_getgid		(__NR_POSIX +  47)
-#define __NR_POSIX_sig			(__NR_POSIX +  48)
-#define __NR_POSIX_msgsys		(__NR_POSIX +  49)
-#define __NR_POSIX_sysmips		(__NR_POSIX +  50)
-#define __NR_POSIX_sysacct		(__NR_POSIX +  51)
-#define __NR_POSIX_shmsys		(__NR_POSIX +  52)
-#define __NR_POSIX_semsys		(__NR_POSIX +  53)
-#define __NR_POSIX_ioctl		(__NR_POSIX +  54)
-#define __NR_POSIX_uadmin		(__NR_POSIX +  55)
-#define __NR_POSIX_exch			(__NR_POSIX +  56)
-#define __NR_POSIX_utssys		(__NR_POSIX +  57)
-#define __NR_POSIX_USG_reserved1	(__NR_POSIX +  58)
-#define __NR_POSIX_exece		(__NR_POSIX +  59)
-#define __NR_POSIX_umask		(__NR_POSIX +  60)
-#define __NR_POSIX_chroot		(__NR_POSIX +  61)
-#define __NR_POSIX_fcntl		(__NR_POSIX +  62)
-#define __NR_POSIX_ulimit		(__NR_POSIX +  63)
-#define __NR_POSIX_SAFARI4_reserved1	(__NR_POSIX +  64)
-#define __NR_POSIX_SAFARI4_reserved2	(__NR_POSIX +  65)
-#define __NR_POSIX_SAFARI4_reserved3	(__NR_POSIX +  66)
-#define __NR_POSIX_SAFARI4_reserved4	(__NR_POSIX +  67)
-#define __NR_POSIX_SAFARI4_reserved5	(__NR_POSIX +  68)
-#define __NR_POSIX_SAFARI4_reserved6	(__NR_POSIX +  69)
-#define __NR_POSIX_advfs		(__NR_POSIX +  70)
-#define __NR_POSIX_unadvfs		(__NR_POSIX +  71)
-#define __NR_POSIX_rmount		(__NR_POSIX +  72)
-#define __NR_POSIX_rumount		(__NR_POSIX +  73)
-#define __NR_POSIX_rfstart		(__NR_POSIX +  74)
-#define __NR_POSIX_reserved1		(__NR_POSIX +  75)
-#define __NR_POSIX_rdebug		(__NR_POSIX +  76)
-#define __NR_POSIX_rfstop		(__NR_POSIX +  77)
-#define __NR_POSIX_rfsys		(__NR_POSIX +  78)
-#define __NR_POSIX_rmdir		(__NR_POSIX +  79)
-#define __NR_POSIX_mkdir		(__NR_POSIX +  80)
-#define __NR_POSIX_getdents		(__NR_POSIX +  81)
-#define __NR_POSIX_sginap		(__NR_POSIX +  82)
-#define __NR_POSIX_sgikopt		(__NR_POSIX +  83)
-#define __NR_POSIX_sysfs		(__NR_POSIX +  84)
-#define __NR_POSIX_getmsg		(__NR_POSIX +  85)
-#define __NR_POSIX_putmsg		(__NR_POSIX +  86)
-#define __NR_POSIX_poll			(__NR_POSIX +  87)
-#define __NR_POSIX_sigreturn		(__NR_POSIX +  88)
-#define __NR_POSIX_accept		(__NR_POSIX +  89)
-#define __NR_POSIX_bind			(__NR_POSIX +  90)
-#define __NR_POSIX_connect		(__NR_POSIX +  91)
-#define __NR_POSIX_gethostid		(__NR_POSIX +  92)
-#define __NR_POSIX_getpeername		(__NR_POSIX +  93)
-#define __NR_POSIX_getsockname		(__NR_POSIX +  94)
-#define __NR_POSIX_getsockopt		(__NR_POSIX +  95)
-#define __NR_POSIX_listen		(__NR_POSIX +  96)
-#define __NR_POSIX_recv			(__NR_POSIX +  97)
-#define __NR_POSIX_recvfrom		(__NR_POSIX +  98)
-#define __NR_POSIX_recvmsg		(__NR_POSIX +  99)
-#define __NR_POSIX_select		(__NR_POSIX + 100)
-#define __NR_POSIX_send			(__NR_POSIX + 101)
-#define __NR_POSIX_sendmsg		(__NR_POSIX + 102)
-#define __NR_POSIX_sendto		(__NR_POSIX + 103)
-#define __NR_POSIX_sethostid		(__NR_POSIX + 104)
-#define __NR_POSIX_setsockopt		(__NR_POSIX + 105)
-#define __NR_POSIX_shutdown		(__NR_POSIX + 106)
-#define __NR_POSIX_socket		(__NR_POSIX + 107)
-#define __NR_POSIX_gethostname		(__NR_POSIX + 108)
-#define __NR_POSIX_sethostname		(__NR_POSIX + 109)
-#define __NR_POSIX_getdomainname	(__NR_POSIX + 110)
-#define __NR_POSIX_setdomainname	(__NR_POSIX + 111)
-#define __NR_POSIX_truncate		(__NR_POSIX + 112)
-#define __NR_POSIX_ftruncate		(__NR_POSIX + 113)
-#define __NR_POSIX_rename		(__NR_POSIX + 114)
-#define __NR_POSIX_symlink		(__NR_POSIX + 115)
-#define __NR_POSIX_readlink		(__NR_POSIX + 116)
-#define __NR_POSIX_lstat		(__NR_POSIX + 117)
-#define __NR_POSIX_nfs_mount		(__NR_POSIX + 118)
-#define __NR_POSIX_nfs_svc		(__NR_POSIX + 119)
-#define __NR_POSIX_nfs_getfh		(__NR_POSIX + 120)
-#define __NR_POSIX_async_daemon		(__NR_POSIX + 121)
-#define __NR_POSIX_exportfs		(__NR_POSIX + 122)
-#define __NR_POSIX_SGI_setregid		(__NR_POSIX + 123)
-#define __NR_POSIX_SGI_setreuid		(__NR_POSIX + 124)
-#define __NR_POSIX_getitimer		(__NR_POSIX + 125)
-#define __NR_POSIX_setitimer		(__NR_POSIX + 126)
-#define __NR_POSIX_adjtime		(__NR_POSIX + 127)
-#define __NR_POSIX_SGI_bsdgettime	(__NR_POSIX + 128)
-#define __NR_POSIX_SGI_sproc		(__NR_POSIX + 129)
-#define __NR_POSIX_SGI_prctl		(__NR_POSIX + 130)
-#define __NR_POSIX_SGI_blkproc		(__NR_POSIX + 131)
-#define __NR_POSIX_SGI_reserved1	(__NR_POSIX + 132)
-#define __NR_POSIX_SGI_sgigsc		(__NR_POSIX + 133)
-#define __NR_POSIX_SGI_mmap		(__NR_POSIX + 134)
-#define __NR_POSIX_SGI_munmap		(__NR_POSIX + 135)
-#define __NR_POSIX_SGI_mprotect		(__NR_POSIX + 136)
-#define __NR_POSIX_SGI_msync		(__NR_POSIX + 137)
-#define __NR_POSIX_SGI_madvise		(__NR_POSIX + 138)
-#define __NR_POSIX_SGI_mpin		(__NR_POSIX + 139)
-#define __NR_POSIX_SGI_getpagesize	(__NR_POSIX + 140)
-#define __NR_POSIX_SGI_libattach	(__NR_POSIX + 141)
-#define __NR_POSIX_SGI_libdetach	(__NR_POSIX + 142)
-#define __NR_POSIX_SGI_getpgrp		(__NR_POSIX + 143)
-#define __NR_POSIX_SGI_setpgrp		(__NR_POSIX + 144)
-#define __NR_POSIX_SGI_reserved2	(__NR_POSIX + 145)
-#define __NR_POSIX_SGI_reserved3	(__NR_POSIX + 146)
-#define __NR_POSIX_SGI_reserved4	(__NR_POSIX + 147)
-#define __NR_POSIX_SGI_reserved5	(__NR_POSIX + 148)
-#define __NR_POSIX_SGI_reserved6	(__NR_POSIX + 149)
-#define __NR_POSIX_cacheflush		(__NR_POSIX + 150)
-#define __NR_POSIX_cachectl		(__NR_POSIX + 151)
-#define __NR_POSIX_fchown		(__NR_POSIX + 152)
-#define __NR_POSIX_fchmod		(__NR_POSIX + 153)
-#define __NR_POSIX_wait3		(__NR_POSIX + 154)
-#define __NR_POSIX_mmap			(__NR_POSIX + 155)
-#define __NR_POSIX_munmap		(__NR_POSIX + 156)
-#define __NR_POSIX_madvise		(__NR_POSIX + 157)
-#define __NR_POSIX_BSD_getpagesize	(__NR_POSIX + 158)
-#define __NR_POSIX_setreuid		(__NR_POSIX + 159)
-#define __NR_POSIX_setregid		(__NR_POSIX + 160)
-#define __NR_POSIX_setpgid		(__NR_POSIX + 161)
-#define __NR_POSIX_getgroups		(__NR_POSIX + 162)
-#define __NR_POSIX_setgroups		(__NR_POSIX + 163)
-#define __NR_POSIX_gettimeofday		(__NR_POSIX + 164)
-#define __NR_POSIX_getrusage		(__NR_POSIX + 165)
-#define __NR_POSIX_getrlimit		(__NR_POSIX + 166)
-#define __NR_POSIX_setrlimit		(__NR_POSIX + 167)
-#define __NR_POSIX_waitpid		(__NR_POSIX + 168)
-#define __NR_POSIX_dup2			(__NR_POSIX + 169)
-#define __NR_POSIX_reserved2		(__NR_POSIX + 170)
-#define __NR_POSIX_reserved3		(__NR_POSIX + 171)
-#define __NR_POSIX_reserved4		(__NR_POSIX + 172)
-#define __NR_POSIX_reserved5		(__NR_POSIX + 173)
-#define __NR_POSIX_reserved6		(__NR_POSIX + 174)
-#define __NR_POSIX_reserved7		(__NR_POSIX + 175)
-#define __NR_POSIX_reserved8		(__NR_POSIX + 176)
-#define __NR_POSIX_reserved9		(__NR_POSIX + 177)
-#define __NR_POSIX_reserved10		(__NR_POSIX + 178)
-#define __NR_POSIX_reserved11		(__NR_POSIX + 179)
-#define __NR_POSIX_reserved12		(__NR_POSIX + 180)
-#define __NR_POSIX_reserved13		(__NR_POSIX + 181)
-#define __NR_POSIX_reserved14		(__NR_POSIX + 182)
-#define __NR_POSIX_reserved15		(__NR_POSIX + 183)
-#define __NR_POSIX_reserved16		(__NR_POSIX + 184)
-#define __NR_POSIX_reserved17		(__NR_POSIX + 185)
-#define __NR_POSIX_reserved18		(__NR_POSIX + 186)
-#define __NR_POSIX_reserved19		(__NR_POSIX + 187)
-#define __NR_POSIX_reserved20		(__NR_POSIX + 188)
-#define __NR_POSIX_reserved21		(__NR_POSIX + 189)
-#define __NR_POSIX_reserved22		(__NR_POSIX + 190)
-#define __NR_POSIX_reserved23		(__NR_POSIX + 191)
-#define __NR_POSIX_reserved24		(__NR_POSIX + 192)
-#define __NR_POSIX_reserved25		(__NR_POSIX + 193)
-#define __NR_POSIX_reserved26		(__NR_POSIX + 194)
-#define __NR_POSIX_reserved27		(__NR_POSIX + 195)
-#define __NR_POSIX_reserved28		(__NR_POSIX + 196)
-#define __NR_POSIX_reserved29		(__NR_POSIX + 197)
-#define __NR_POSIX_reserved30		(__NR_POSIX + 198)
-#define __NR_POSIX_reserved31		(__NR_POSIX + 199)
-#define __NR_POSIX_reserved32		(__NR_POSIX + 200)
-#define __NR_POSIX_reserved33		(__NR_POSIX + 201)
-#define __NR_POSIX_reserved34		(__NR_POSIX + 202)
-#define __NR_POSIX_reserved35		(__NR_POSIX + 203)
-#define __NR_POSIX_reserved36		(__NR_POSIX + 204)
-#define __NR_POSIX_reserved37		(__NR_POSIX + 205)
-#define __NR_POSIX_reserved38		(__NR_POSIX + 206)
-#define __NR_POSIX_reserved39		(__NR_POSIX + 207)
-#define __NR_POSIX_reserved40		(__NR_POSIX + 208)
-#define __NR_POSIX_reserved41		(__NR_POSIX + 209)
-#define __NR_POSIX_reserved42		(__NR_POSIX + 210)
-#define __NR_POSIX_reserved43		(__NR_POSIX + 211)
-#define __NR_POSIX_reserved44		(__NR_POSIX + 212)
-#define __NR_POSIX_reserved45		(__NR_POSIX + 213)
-#define __NR_POSIX_reserved46		(__NR_POSIX + 214)
-#define __NR_POSIX_reserved47		(__NR_POSIX + 215)
-#define __NR_POSIX_reserved48		(__NR_POSIX + 216)
-#define __NR_POSIX_reserved49		(__NR_POSIX + 217)
-#define __NR_POSIX_reserved50		(__NR_POSIX + 218)
-#define __NR_POSIX_reserved51		(__NR_POSIX + 219)
-#define __NR_POSIX_reserved52		(__NR_POSIX + 220)
-#define __NR_POSIX_reserved53		(__NR_POSIX + 221)
-#define __NR_POSIX_reserved54		(__NR_POSIX + 222)
-#define __NR_POSIX_reserved55		(__NR_POSIX + 223)
-#define __NR_POSIX_reserved56		(__NR_POSIX + 224)
-#define __NR_POSIX_reserved57		(__NR_POSIX + 225)
-#define __NR_POSIX_reserved58		(__NR_POSIX + 226)
-#define __NR_POSIX_reserved59		(__NR_POSIX + 227)
-#define __NR_POSIX_reserved60		(__NR_POSIX + 228)
-#define __NR_POSIX_reserved61		(__NR_POSIX + 229)
-#define __NR_POSIX_reserved62		(__NR_POSIX + 230)
-#define __NR_POSIX_reserved63		(__NR_POSIX + 231)
-#define __NR_POSIX_reserved64		(__NR_POSIX + 232)
-#define __NR_POSIX_reserved65		(__NR_POSIX + 233)
-#define __NR_POSIX_reserved66		(__NR_POSIX + 234)
-#define __NR_POSIX_reserved67		(__NR_POSIX + 235)
-#define __NR_POSIX_reserved68		(__NR_POSIX + 236)
-#define __NR_POSIX_reserved69		(__NR_POSIX + 237)
-#define __NR_POSIX_reserved70		(__NR_POSIX + 238)
-#define __NR_POSIX_reserved71		(__NR_POSIX + 239)
-#define __NR_POSIX_reserved72		(__NR_POSIX + 240)
-#define __NR_POSIX_reserved73		(__NR_POSIX + 241)
-#define __NR_POSIX_reserved74		(__NR_POSIX + 242)
-#define __NR_POSIX_reserved75		(__NR_POSIX + 243)
-#define __NR_POSIX_reserved76		(__NR_POSIX + 244)
-#define __NR_POSIX_reserved77		(__NR_POSIX + 245)
-#define __NR_POSIX_reserved78		(__NR_POSIX + 246)
-#define __NR_POSIX_reserved79		(__NR_POSIX + 247)
-#define __NR_POSIX_reserved80		(__NR_POSIX + 248)
-#define __NR_POSIX_reserved81		(__NR_POSIX + 249)
-#define __NR_POSIX_reserved82		(__NR_POSIX + 250)
-#define __NR_POSIX_reserved83		(__NR_POSIX + 251)
-#define __NR_POSIX_reserved84		(__NR_POSIX + 252)
-#define __NR_POSIX_reserved85		(__NR_POSIX + 253)
-#define __NR_POSIX_reserved86		(__NR_POSIX + 254)
-#define __NR_POSIX_reserved87		(__NR_POSIX + 255)
-#define __NR_POSIX_reserved88		(__NR_POSIX + 256)
-#define __NR_POSIX_reserved89		(__NR_POSIX + 257)
-#define __NR_POSIX_reserved90		(__NR_POSIX + 258)
-#define __NR_POSIX_reserved91		(__NR_POSIX + 259)
-#define __NR_POSIX_netboot		(__NR_POSIX + 260)
-#define __NR_POSIX_netunboot		(__NR_POSIX + 261)
-#define __NR_POSIX_rdump		(__NR_POSIX + 262)
-#define __NR_POSIX_setsid		(__NR_POSIX + 263)
-#define __NR_POSIX_getmaxsig		(__NR_POSIX + 264)
-#define __NR_POSIX_sigpending		(__NR_POSIX + 265)
-#define __NR_POSIX_sigprocmask		(__NR_POSIX + 266)
-#define __NR_POSIX_sigsuspend		(__NR_POSIX + 267)
-#define __NR_POSIX_sigaction		(__NR_POSIX + 268)
-#define __NR_POSIX_MIPS_reserved1	(__NR_POSIX + 269)
-#define __NR_POSIX_MIPS_reserved2	(__NR_POSIX + 270)
-#define __NR_POSIX_MIPS_reserved3	(__NR_POSIX + 271)
-#define __NR_POSIX_MIPS_reserved4	(__NR_POSIX + 272)
-#define __NR_POSIX_MIPS_reserved5	(__NR_POSIX + 273)
-#define __NR_POSIX_MIPS_reserved6	(__NR_POSIX + 274)
-#define __NR_POSIX_MIPS_reserved7	(__NR_POSIX + 275)
-#define __NR_POSIX_MIPS_reserved8	(__NR_POSIX + 276)
-#define __NR_POSIX_MIPS_reserved9	(__NR_POSIX + 277)
-#define __NR_POSIX_MIPS_reserved10	(__NR_POSIX + 278)
-#define __NR_POSIX_MIPS_reserved11	(__NR_POSIX + 279)
-#define __NR_POSIX_TANDEM_reserved1	(__NR_POSIX + 280)
-#define __NR_POSIX_TANDEM_reserved2	(__NR_POSIX + 281)
-#define __NR_POSIX_TANDEM_reserved3	(__NR_POSIX + 282)
-#define __NR_POSIX_TANDEM_reserved4	(__NR_POSIX + 283)
-#define __NR_POSIX_TANDEM_reserved5	(__NR_POSIX + 284)
-#define __NR_POSIX_TANDEM_reserved6	(__NR_POSIX + 285)
-#define __NR_POSIX_TANDEM_reserved7	(__NR_POSIX + 286)
-#define __NR_POSIX_TANDEM_reserved8	(__NR_POSIX + 287)
-#define __NR_POSIX_TANDEM_reserved9	(__NR_POSIX + 288)
-#define __NR_POSIX_TANDEM_reserved10	(__NR_POSIX + 289)
-#define __NR_POSIX_TANDEM_reserved11	(__NR_POSIX + 290)
-#define __NR_POSIX_TANDEM_reserved12	(__NR_POSIX + 291)
-#define __NR_POSIX_TANDEM_reserved13	(__NR_POSIX + 292)
-#define __NR_POSIX_TANDEM_reserved14	(__NR_POSIX + 293)
-#define __NR_POSIX_TANDEM_reserved15	(__NR_POSIX + 294)
-#define __NR_POSIX_TANDEM_reserved16	(__NR_POSIX + 295)
-#define __NR_POSIX_TANDEM_reserved17	(__NR_POSIX + 296)
-#define __NR_POSIX_TANDEM_reserved18	(__NR_POSIX + 297)
-#define __NR_POSIX_TANDEM_reserved19	(__NR_POSIX + 298)
-#define __NR_POSIX_TANDEM_reserved20	(__NR_POSIX + 299)
-#define __NR_POSIX_SGI_reserved7	(__NR_POSIX + 300)
-#define __NR_POSIX_SGI_reserved8	(__NR_POSIX + 301)
-#define __NR_POSIX_SGI_reserved9	(__NR_POSIX + 302)
-#define __NR_POSIX_SGI_reserved10	(__NR_POSIX + 303)
-#define __NR_POSIX_SGI_reserved11	(__NR_POSIX + 304)
-#define __NR_POSIX_SGI_reserved12	(__NR_POSIX + 305)
-#define __NR_POSIX_SGI_reserved13	(__NR_POSIX + 306)
-#define __NR_POSIX_SGI_reserved14	(__NR_POSIX + 307)
-#define __NR_POSIX_SGI_reserved15	(__NR_POSIX + 308)
-#define __NR_POSIX_SGI_reserved16	(__NR_POSIX + 309)
-#define __NR_POSIX_SGI_reserved17	(__NR_POSIX + 310)
-#define __NR_POSIX_SGI_reserved18	(__NR_POSIX + 311)
-#define __NR_POSIX_SGI_reserved19	(__NR_POSIX + 312)
-#define __NR_POSIX_SGI_reserved20	(__NR_POSIX + 313)
-#define __NR_POSIX_SGI_reserved21	(__NR_POSIX + 314)
-#define __NR_POSIX_SGI_reserved22	(__NR_POSIX + 315)
-#define __NR_POSIX_SGI_reserved23	(__NR_POSIX + 316)
-#define __NR_POSIX_SGI_reserved24	(__NR_POSIX + 317)
-#define __NR_POSIX_SGI_reserved25	(__NR_POSIX + 318)
-#define __NR_POSIX_SGI_reserved26	(__NR_POSIX + 319)
-
-#endif /* _ASM_RISCOS_SYSCALL_H */
_

From nemoto@toshiba-tops.co.jp Mon Dec 27 05:48:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 05:48:25 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:60198
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225202AbUL0FsU>; Mon, 27 Dec 2004 05:48:20 +0000
Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 27 Dec 2004 05:48:18 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by newms.toshiba-tops.co.jp (Postfix) with ESMTP
	id 83CBD239E1A; Mon, 27 Dec 2004 14:48:05 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id iBR5m4Mc040580;
	Mon, 27 Dec 2004 14:48:05 +0900 (JST)
	(envelope-from nemoto@toshiba-tops.co.jp)
Date: Mon, 27 Dec 2004 14:48:04 +0900 (JST)
Message-Id: <20041227.144804.30188040.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
Subject: please export probe_irq_mask
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 3.3 on Emacs 21.3 / 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: 6763
X-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

Now probe_irq_mask is in kernel/irq/autoprobe.c, but it is not
exported.  Please export it as past.

Here is a patch (or kernel/irq/autoprobe.c should be fixed?)

Thank you.

--- linux-mips/arch/mips/kernel/mips_ksyms.c	2004-09-22 13:27:59.000000000 +0900
+++ linux/arch/mips/kernel/mips_ksyms.c	2004-12-27 14:37:12.524814712 +0900
@@ -60,3 +60,5 @@
 EXPORT_SYMBOL(csum_partial);
 
 EXPORT_SYMBOL(invalid_pte_table);
+extern unsigned int probe_irq_mask(unsigned long val);
+EXPORT_SYMBOL(probe_irq_mask);

---
Atsushi Nemoto

From gilad@romat.com Mon Dec 27 11:33:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 11:33:50 +0000 (GMT)
Received: from support.romat.com ([IPv6:::ffff:212.143.245.3]:2833 "EHLO
	mail.romat.com") by linux-mips.org with ESMTP id <S8225211AbUL0Ldp>;
	Mon, 27 Dec 2004 11:33:45 +0000
Received: from localhost (localhost.lan [127.0.0.1])
	by mail.romat.com (Postfix) with ESMTP id 203E5EB2CA
	for <linux-mips@linux-mips.org>; Mon, 27 Dec 2004 13:33:29 +0200 (IST)
Received: from mail.romat.com ([127.0.0.1])
 by localhost (mail.romat.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 86539-04 for <linux-mips@linux-mips.org>;
 Mon, 27 Dec 2004 13:33:22 +0200 (IST)
Received: from gilad (unknown [192.168.1.167])
	by mail.romat.com (Postfix) with ESMTP id CFCF9EB307
	for <linux-mips@linux-mips.org>; Mon, 27 Dec 2004 13:33:21 +0200 (IST)
From: "Gilad Rom" <gilad@romat.com>
To: <linux-mips@linux-mips.org>
Subject: Off Topic: JTAG
Date: Mon, 27 Dec 2004 13:33:11 +0200
Organization: Romat Telecom
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTsB9hEZOsNDYsLSceesMxhC15EBA==
Message-Id: <20041227113321.CFCF9EB307@mail.romat.com>
X-Virus-Scanned: by amavisd-new at romat.com
Return-Path: <gilad@romat.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: 6764
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gilad@romat.com
Precedence: bulk
X-list: linux-mips

Hello List,

I know this is a little off topic, but I'd really
Appreciate it if anyone could give me a little pointer
In the right direction...

I am looking for a device which will allow me to burn
FLASH chips connected to the Alchemy through its JTAG port.

I am not looking for a complete JTAG function, I am just
Interested in re-flashing already soldered FLASH chips.


Thanks a lot,
Gilad.


From ralf@linux-mips.org Mon Dec 27 12:04:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 12:04:09 +0000 (GMT)
Received: from p508B6A65.dip.t-dialin.net ([IPv6:::ffff:80.139.106.101]:25636
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225249AbUL0MEF>; Mon, 27 Dec 2004 12:04:05 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBRC3ruo025534;
	Mon, 27 Dec 2004 13:03:53 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBRC3iiL025533;
	Mon, 27 Dec 2004 13:03:44 +0100
Date: Mon, 27 Dec 2004 13:03:44 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: please export probe_irq_mask
Message-ID: <20041227120344.GA25442@linux-mips.org>
References: <20041227.144804.30188040.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041227.144804.30188040.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6765
X-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, Dec 27, 2004 at 02:48:04PM +0900, Atsushi Nemoto wrote:

> Now probe_irq_mask is in kernel/irq/autoprobe.c, but it is not
> exported.  Please export it as past.
> 
> Here is a patch (or kernel/irq/autoprobe.c should be fixed?)

I think so but for the time being each arch is exporting the thing itself.

You're using probe_irq_mask for ISA, I assume?

  Ralf

From ralf@linux-mips.org Mon Dec 27 12:30:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 12:30:29 +0000 (GMT)
Received: from p508B6A65.dip.t-dialin.net ([IPv6:::ffff:80.139.106.101]:48420
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225211AbUL0MaZ>; Mon, 27 Dec 2004 12:30:25 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBRCUDxm025961;
	Mon, 27 Dec 2004 13:30:13 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBRCU9Y9025960;
	Mon, 27 Dec 2004 13:30:09 +0100
Date: Mon, 27 Dec 2004 13:30:09 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Nori, Soma Sekhar" <nsekhar@ti.com>
Cc: linux-mips@linux-mips.org, "Iyer, Suraj" <ssiyer@ti.com>
Subject: Re: do_ri exception in Linux (MIPS 4kec)
Message-ID: <20041227123009.GB25442@linux-mips.org>
References: <F6B01C6242515443BB6E5DDD63AE935F60FFFF@dbde2k01.itg.ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F6B01C6242515443BB6E5DDD63AE935F60FFFF@dbde2k01.itg.ti.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6766
X-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, Dec 23, 2004 at 04:58:03PM +0530, Nori, Soma Sekhar wrote:

> We are using montavista Linux version 2.4.17, gcc version 2.95.3 running on MIPS 4kec.
> 
> Here is the dump:
> $0 : 00000000 0044def4 000001ac 0000006b 00000000 7fff7c08 00000001 00000000
> $8 : 0000fc00 00000001 00000000 941524d0 00004700 00000000 97fc3ea0 7fff7c08
> $16: 100048a4 100029d8 100029d8 10003020 00000000 7fff7dc8 10003b60 2d8e2163
> $24: 00000001 2ab7bc30                   10008e70 7fff7bf0 04000000 00439e50
> Hi : 00000000
> Lo : 00000001
> epc  : 00439e84    Not tainted
> Status: 0000fc13
> Cause : 10800028
> Process sh (pid: 18, stackpage=97fc2000)
> Stack: 00000001 00000000 2abd0ff0 7fff7c28 10008e70 00000000 10008e6c 00000000
>        100049a0 0042f188 00000000 100029d8 00000001 00000001 7fff7f04 10008e70
>        00427fe4 00427f00 00000000 00000000 10002764 10008e70 10008e70 00000000
>        00000000 00000000 10008e70 00422734 00000001 00000001 7fff7f04 10008e70
>        10008e70 00000003 10008e70 004315cc 00000001 00000000 10002764 00000000
>        10008e70 ...
> Call Trace:
> Code: 00000000  2421dd48  00220821 <8c220000> 00000000  005c1021  00400008  0000
> 0000  8f99802c
> 
> The epc is not in kernel space and ksymoops did not provide any info. The epc keeps changing to different locations in user space over multiple runs.

In a case like this you're likely dealing with double exceptions.  Your
code is taking an exception and the exception handler while running with
c0_status set is taking another exception.  If the first exception handler
is still running with the c0_status.exl bit set the CPU when taking the
second exception it will not record the PC of the second exception and
you will have a seemingly unexplainable exception.

A few processors have the nasty habit of throwing RI receptions or do
similarly weird things when executing code that is mapped through multiple
TLB pages but the 4kEC shouldn't.

  Ralf

From ralf@linux-mips.org Mon Dec 27 12:40:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 12:40:14 +0000 (GMT)
Received: from p508B6A65.dip.t-dialin.net ([IPv6:::ffff:80.139.106.101]:59172
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225213AbUL0MkK>; Mon, 27 Dec 2004 12:40:10 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBRCdvke026146;
	Mon, 27 Dec 2004 13:39:57 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBRCdv0G026145;
	Mon, 27 Dec 2004 13:39:57 +0100
Date: Mon, 27 Dec 2004 13:39:57 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: domen@coderock.org
Cc: linux-mips@linux-mips.org
Subject: Re: [patch 8/9] delete unused file
Message-ID: <20041227123957.GA26100@linux-mips.org>
References: <20041225172501.97E251F123@trashy.coderock.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041225172501.97E251F123@trashy.coderock.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6767
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Dec 25, 2004 at 06:25:11PM +0100, domen@coderock.org wrote:

> Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Applied,

  Ralf

From ralf@linux-mips.org Mon Dec 27 12:41:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 12:41:08 +0000 (GMT)
Received: from p508B6A65.dip.t-dialin.net ([IPv6:::ffff:80.139.106.101]:61220
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225213AbUL0MlD>; Mon, 27 Dec 2004 12:41:03 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBRCep34026179;
	Mon, 27 Dec 2004 13:40:51 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBRCepdo026178;
	Mon, 27 Dec 2004 13:40:51 +0100
Date: Mon, 27 Dec 2004 13:40:51 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: domen@coderock.org
Cc: linux-mips@linux-mips.org
Subject: Re: [patch 7/9] delete unused file
Message-ID: <20041227124051.GB26100@linux-mips.org>
References: <20041225172458.1B1FB1EA0F@trashy.coderock.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041225172458.1B1FB1EA0F@trashy.coderock.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6768
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Dec 25, 2004 at 06:25:08PM +0100, domen@coderock.org wrote:

> Remove nowhere referenced file. (egrep "filename\." didn't find anything)

Applied,

  Ralf

From ralf@linux-mips.org Mon Dec 27 12:44:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 12:44:52 +0000 (GMT)
Received: from p508B6A65.dip.t-dialin.net ([IPv6:::ffff:80.139.106.101]:293
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225267AbUL0Mor>; Mon, 27 Dec 2004 12:44:47 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBRCiZBq026271;
	Mon, 27 Dec 2004 13:44:35 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBRCiZvp026270;
	Mon, 27 Dec 2004 13:44:35 +0100
Date: Mon, 27 Dec 2004 13:44:35 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: domen@coderock.org
Cc: linux-mips@linux-mips.org
Subject: Re: [patch 4/9] delete unused file
Message-ID: <20041227124435.GC26100@linux-mips.org>
References: <20041225172449.1063A1F123@trashy.coderock.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041225172449.1063A1F123@trashy.coderock.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6769
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Dec 25, 2004 at 06:24:59PM +0100, domen@coderock.org wrote:

> Remove nowhere referenced file. (egrep "filename\." didn't find anything)
> 
> Signed-off-by: Domen Puncer <domen@coderock.org>
> ---
> 
> 
>  kj/include/asm-mips/it8172/it8172_lpc.h |   29 -----------------------------

Applied,

  Ralf

From anemo@mba.sphere.ne.jp Mon Dec 27 14:36:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 14:36:29 +0000 (GMT)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:7655 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225243AbUL0OgW>; Mon, 27 Dec 2004 14:36:22 +0000
Received: from localhost (p1021-ipad11funabasi.chiba.ocn.ne.jp [219.162.36.21])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 7F0044BDC; Mon, 27 Dec 2004 23:36:08 +0900 (JST)
Date: Mon, 27 Dec 2004 23:41:55 +0900 (JST)
Message-Id: <20041227.234155.59462250.anemo@mba.ocn.ne.jp>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: please export probe_irq_mask
From: anemo@mba.sphere.ne.jp
In-Reply-To: <20041227120344.GA25442@linux-mips.org>
References: <20041227.144804.30188040.nemoto@toshiba-tops.co.jp>
	<20041227120344.GA25442@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.sphere.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6770
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.sphere.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Mon, 27 Dec 2004 13:03:44 +0100, Ralf Baechle <ralf@linux-mips.org> said:
ralf> I think so but for the time being each arch is exporting the
ralf> thing itself.  You're using probe_irq_mask for ISA, I assume?

Thank you.  I'm using it for CardBus (yenta_socket).

Also, it seems something wrong with yenta_allocate_resources() on
mips.  Nullifying the yenta_allocate_resources() works well but I'm not
sure why.  Does anyone know what is a problem?  

---
Atsushi Nemoto

From thomas.petazzoni@enix.org Mon Dec 27 16:32:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 16:32:52 +0000 (GMT)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:13021 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8225272AbUL0Qcr>; Mon, 27 Dec 2004 16:32:47 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by the-doors.enix.org (Postfix) with ESMTP id 68380400D3
	for <linux-mips@linux-mips.org>; Mon, 27 Dec 2004 17:32:51 +0100 (CET)
Message-ID: <41D039BB.3030202@enix.org>
Date: Mon, 27 Dec 2004 17:35:07 +0100
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040926)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Some cache questions
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig9003D6FB7C21635BAA229BB4"
Return-Path: <thomas.petazzoni@enix.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: 6771
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thomas.petazzoni@enix.org
Precedence: bulk
X-list: linux-mips

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9003D6FB7C21635BAA229BB4
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

I'm using an RM9000 dual-core processor, buggy revisions (the one that 
doesn't support the "Shared" cache state if I understood correctly).

When going through the CVS logs, I saw that Ralf quite recently changed 
the cache mode from 4 to 5 in pgtable-bits.h. Is that change involved in 
the use of the "Shared" cache state with newer RM9000 revisions that 
don't have the bug ?

Currently, the KSEG0 cache coherency mode (2 lower bits of the CONFIG 
register) is set to 3 during PMON (start.S file). When I write something 
to the memory through KSEG0 with the first core, it doesn't appear to be 
read by the second core. This indicates, in my opinion, that the cache 
line of the first core hasn't been written to memory so that the second 
core could use it. Am I right ?

If I want to correctly use both cores using KSEG0, should I set the mode 
in the CONFIG register to 4 (so that I can work with buggy processors) ?

Thanks,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org
http://thomas.enix.org - Jabber: thomas.petazzoni@jabber.dk
http://kos.enix.org, http://sos.enix.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

--------------enig9003D6FB7C21635BAA229BB4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB0Dm79lPLMJjT96cRAvoKAJ0dVfqFyrGPQVXy/KNd2h/paJ/xegCgo38W
ajSIAS77TEUdgdQhjPLpOF8=
=LuPp
-----END PGP SIGNATURE-----

--------------enig9003D6FB7C21635BAA229BB4--

From Brad_Larson@pmc-sierra.com Mon Dec 27 22:11:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 22:11:47 +0000 (GMT)
Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:22525 "HELO
	mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8225273AbUL0WLl>; Mon, 27 Dec 2004 22:11:41 +0000
Received: (qmail 9089 invoked by uid 101); 27 Dec 2004 22:11:22 -0000
Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59)
  by mother.pmc-sierra.com with SMTP; 27 Dec 2004 22:11:22 -0000
Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogmios.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id iBRMBGJv029866;
	Mon, 27 Dec 2004 14:11:21 -0800
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <YS6FFDQ9>; Mon, 27 Dec 2004 14:11:15 -0800
Message-ID: <04781D450CFF604A9628C8107A62FCCF013DDAE4@sjc1exm01.pmc_nt.nt.pmc-sierra.bc.ca>
From: Brad Larson <Brad_Larson@pmc-sierra.com>
To: "'Thomas Petazzoni'" <thomas.petazzoni@enix.org>,
	linux-mips@linux-mips.org
Subject: RE: Some cache questions
Date: Mon, 27 Dec 2004 14:11:15 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Brad_Larson@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6772
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Brad_Larson@pmc-sierra.com
Precedence: bulk
X-list: linux-mips

You haven't mentioned which board.  If its Yosemite then you may have one of the few not upgraded to 1.2 silicon.  If so it won't work with the changes committed by Ralf which requires the shared state for SMP boot.  For further discussion contact the apps@pmc-sierra.com

--Brad

-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Thomas Petazzoni
Sent: Monday, December 27, 2004 8:35 AM
To: linux-mips@linux-mips.org
Subject: Some cache questions


Hello,

I'm using an RM9000 dual-core processor, buggy revisions (the one that 
doesn't support the "Shared" cache state if I understood correctly).

When going through the CVS logs, I saw that Ralf quite recently changed 
the cache mode from 4 to 5 in pgtable-bits.h. Is that change involved in 
the use of the "Shared" cache state with newer RM9000 revisions that 
don't have the bug ?

Currently, the KSEG0 cache coherency mode (2 lower bits of the CONFIG 
register) is set to 3 during PMON (start.S file). When I write something 
to the memory through KSEG0 with the first core, it doesn't appear to be 
read by the second core. This indicates, in my opinion, that the cache 
line of the first core hasn't been written to memory so that the second 
core could use it. Am I right ?

If I want to correctly use both cores using KSEG0, should I set the mode 
in the CONFIG register to 4 (so that I can work with buggy processors) ?

Thanks,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org
http://thomas.enix.org - Jabber: thomas.petazzoni@jabber.dk
http://kos.enix.org, http://sos.enix.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

From macgyver@tos.net Mon Dec 27 23:14:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 23:14:14 +0000 (GMT)
Received: from [IPv6:::ffff:67.109.220.20] ([IPv6:::ffff:67.109.220.20]:52410
	"EHLO starbase.tos.net") by linux-mips.org with ESMTP
	id <S8225273AbUL0XOJ>; Mon, 27 Dec 2004 23:14:09 +0000
Received: from intrepid (c-67-175-6-30.client.comcast.net [67.175.6.30])
	(authenticated bits=0)
	by starbase.tos.net (8.13.1/8.13.1) with ESMTP id iBRNDgc6013040
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <linux-mips@linux-mips.org>; Mon, 27 Dec 2004 17:13:42 -0600
Message-Id: <200412272313.iBRNDgc6013040@starbase.tos.net>
From: "Habeeb J. Dihu" <macgyver@tos.net>
To: <linux-mips@linux-mips.org>
Subject: 2.6.9 Cobalt Tulip lockups.
Date: Mon, 27 Dec 2004 17:12:50 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
thread-index: AcTsaZXvzQx36tlZSW6UHgkY7xP3eg==
X-Virus-Scanned: ClamAV 0.80/618/Sun Dec  5 17:09:24 2004
	clamav-milter version 0.80j
	on starbase.tos.net
X-Virus-Status: Clean
Return-Path: <macgyver@tos.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: 6773
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macgyver@tos.net
Precedence: bulk
X-list: linux-mips

Firstly...hope everyone enjoyed (or is still enjoying) their holidays.

Just joined the mailing list.  Apologies on the longish post, but I wanted
to provide as much information as possible.

I've got a couple of Cobalt boxes (a RaQ2 and a Qube2) that are successfully
running Debian (as well as Gentoo) running the 2.6.9 branch of CVS plus
Peter Horton's patches.  The machines are quite stable and I really haven't
run into any issues until I start stress-testing networking.

Under high network loads when connected at 100TX FDX, I can always get the
Cobalts to lock up.  Under anything slower -- 100TX HDX, 10TX FDX, 10TX HDX
-- everything works fine.  This problem is specific to:

1.  Lots of data transfer to/from the Cobalt.
2.  Running at 100TX FDX.

The test scenario is:

Cobalt running 2.6.9CVS + PH's patches.  Cobalt is running an NFS server.
From another machine on the network (also running at 100TX FDX), mount the
NFS export and copy something huge (in my case a directory that has about
2GB worth of files in it).

It'll usually get anywhere from 300MB to 800MB of data before the Cobalt
just locks up -- no kernel panic, just a hard lockup that necessitates
cycling power manually.

At first I thought it might be NFS, so I tried something way less kernel
dependent like FTP and still had the same problems.  I also recompiled the
kernel with:

CONFIG_TULIP_MWI=n
CONFIG_TULIP_MMIO=n
CONFIG_TULIP_NAPI=n
CONFIG_TULIP_NAPI_HW_MITIGATION=n

as well as set to yes to no avail.

As a last resort I turned on lots of debugging output (I set tulip_debug to
99) and finally I got something usable from the kernel:

eth0: MII status 782d, Link partner report 45e1.
eth0: 21143 negotiation status 000000c6, MII.
Badness in local_bh_enable at kernel/softirq.c:141
Call Trace: [<800b32c8>]  [<80084e28>]  [<80397ee8>]  [<80397f08>]
[<80398af4>]  [<8029a374>]  [<800b87ac>]  [<800ad20c>]  [<8029ccbc>]
[<802bc8b0>]  [<802bc918>]  [<802bcba8>]  [<802575bc>]  [<8027b370>]
[<800abe34>]  [<800abe34>]  [<800b3168>]  [<800abebc>]  [<800abf80>]
[<800ac6b8>]  [<8022e900>]  [<800ac34c>]  [<8022e900>]  [<800ac278>]
[<800ac174>]  [<80279dec>]  [<80279980>]  [<800b8954>]  [<802b9458>]
[<800b3168>]  [<80084808>]  [<800b3208>]  [<80084e18>]  [<80082908>]
[<802dc1bc>]  [<80083180>]  [<802d89d8>]  [<8030ffdc>]  [<80303260>]
[<802da298>]  [<80084e28>]  [<8029afb0>]  [<8029b330>]  [<80138718>]
[<802dad80>]  [<80134538>]  [<800a4198>]  [<802d07c0>]  [<803031ec>]
[<8030ffdc>]  [<80214364>]  [<80295864>]  [<800a7440>]  [<8030ffdc>]
[<80214364>]  [<80295894>]  [<80295864>]  [<8029b7b4>]  [<80303ab8>]
[<80303aa0>]  [<8020e0d4>]  [<800a7440>]  [<802120f4>]  [<800a40c8>]
[<80310070>]  [<80398698>]  [<80398840>]  [<8029ca50>]  [<801d6f8c>]
[<8029cd50>]  [<8039918c>]  [<801cab18>]  [<8039b554>]  [<8039c8a4>]
[<801d8068>]  [<80397740>]  [<800bdbe8>]  [<801c7398>]  [<801c7274>]
[<801c70cc>]  [<80086070>]  [<80086060>] 

I'd already deduced that it was probably a problem related to interrupts
(seems we have a lot of those issues on our lovely blue boxes).  Looking at
the relevant line in kernel/softirq.c yields:

void local_bh_enable(void)
{
        __local_bh_enable();
        WARN_ON(irqs_disabled());
        if (unlikely(!in_interrupt() &&
                     local_softirq_pending()))
                invoke_softirq();
        preempt_check_resched();
}
EXPORT_SYMBOL(local_bh_enable);

So it's clear that something's calling local_bh_enable while interrupts are
disabled, which they shouldn't be.  I can recreate this problem at will --
so it's definitely replicable.  I've really taken this as far as I can in
terms of debugging the problem on my own.  I'd appreciate any/all
assistance/direction in how to track down the culprit here and fix the
problem.

Thanks,

Habeeb.


From ralf@linux-mips.org Mon Dec 27 23:31:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Dec 2004 23:31:46 +0000 (GMT)
Received: from p508B6A65.dip.t-dialin.net ([IPv6:::ffff:80.139.106.101]:814
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225280AbUL0Xbm>; Mon, 27 Dec 2004 23:31:42 +0000
Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1])
	by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id iBRNVVT0020251;
	Tue, 28 Dec 2004 00:31:31 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id iBRNVQMP020250;
	Tue, 28 Dec 2004 00:31:26 +0100
Date: Tue, 28 Dec 2004 00:31:26 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Habeeb J. Dihu" <macgyver@tos.net>
Cc: linux-mips@linux-mips.org
Subject: Re: 2.6.9 Cobalt Tulip lockups.
Message-ID: <20041227233126.GA6680@linux-mips.org>
References: <200412272313.iBRNDgc6013040@starbase.tos.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200412272313.iBRNDgc6013040@starbase.tos.net>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6774
X-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, Dec 27, 2004 at 05:12:50PM -0600, Habeeb J. Dihu wrote:

> eth0: MII status 782d, Link partner report 45e1.
> eth0: 21143 negotiation status 000000c6, MII.
> Badness in local_bh_enable at kernel/softirq.c:141
> Call Trace: [<800b32c8>]  [<80084e28>]  [<80397ee8>]  [<80397f08>]
> [<80398af4>]  [<8029a374>]  [<800b87ac>]  [<800ad20c>]  [<8029ccbc>]
> [<802bc8b0>]  [<802bc918>]  [<802bcba8>]  [<802575bc>]  [<8027b370>]
> [<800abe34>]  [<800abe34>]  [<800b3168>]  [<800abebc>]  [<800abf80>]
> [<800ac6b8>]  [<8022e900>]  [<800ac34c>]  [<8022e900>]  [<800ac278>]
> [<800ac174>]  [<80279dec>]  [<80279980>]  [<800b8954>]  [<802b9458>]
> [<800b3168>]  [<80084808>]  [<800b3208>]  [<80084e18>]  [<80082908>]
> [<802dc1bc>]  [<80083180>]  [<802d89d8>]  [<8030ffdc>]  [<80303260>]
> [<802da298>]  [<80084e28>]  [<8029afb0>]  [<8029b330>]  [<80138718>]
> [<802dad80>]  [<80134538>]  [<800a4198>]  [<802d07c0>]  [<803031ec>]
> [<8030ffdc>]  [<80214364>]  [<80295864>]  [<800a7440>]  [<8030ffdc>]
> [<80214364>]  [<80295894>]  [<80295864>]  [<8029b7b4>]  [<80303ab8>]
> [<80303aa0>]  [<8020e0d4>]  [<800a7440>]  [<802120f4>]  [<800a40c8>]
> [<80310070>]  [<80398698>]  [<80398840>]  [<8029ca50>]  [<801d6f8c>]
> [<8029cd50>]  [<8039918c>]  [<801cab18>]  [<8039b554>]  [<8039c8a4>]
> [<801d8068>]  [<80397740>]  [<800bdbe8>]  [<801c7398>]  [<801c7274>]
> [<801c70cc>]  [<80086070>]  [<80086060>] 

Can you decode this dump?  Undecoded it's useless, decoded likely to
be useful ...

  Ralf

From macgyver@tos.net Tue Dec 28 00:39:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Dec 2004 00:39:48 +0000 (GMT)
Received: from [IPv6:::ffff:67.109.220.20] ([IPv6:::ffff:67.109.220.20]:46523
	"EHLO starbase.tos.net") by linux-mips.org with ESMTP
	id <S8225274AbUL1Ajn>; Tue, 28 Dec 2004 00:39:43 +0000
Received: from intrepid (c-67-175-6-30.client.comcast.net [67.175.6.30])
	(authenticated bits=0)
	by starbase.tos.net (8.13.1/8.13.1) with ESMTP id iBS0dFXA014161
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <linux-mips@linux-mips.org>; Mon, 27 Dec 2004 18:39:16 -0600
Message-Id: <200412280039.iBS0dFXA014161@starbase.tos.net>
From: "Habeeb J. Dihu" <macgyver@tos.net>
To: <linux-mips@linux-mips.org>
Subject: RE: 2.6.9 Cobalt Tulip lockups.
Date: Mon, 27 Dec 2004 18:38:23 -0600
Keywords: Mailing List, linux-mips
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <20041227233126.GA6680@linux-mips.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
thread-index: AcTsbGbjJgAekQEpQbqsruLYRcFWTAABDepw
X-Virus-Scanned: ClamAV 0.80/618/Sun Dec  5 17:09:24 2004
	clamav-milter version 0.80j
	on starbase.tos.net
X-Virus-Status: Clean
Return-Path: <macgyver@tos.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: 6775
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macgyver@tos.net
Precedence: bulk
X-list: linux-mips

Grrr...thought I did and ended up pasting the wrong output. :)  Here's the
decoded output:

Trace; 800b32c8 <local_bh_enable+b8/c0>
Trace; 80084e28 <do_IRQ+1d8/208>
Trace; 80397ee8 <svc_sock_enqueue+248/4d0>
Trace; 80397f08 <svc_sock_enqueue+268/4d0>
Trace; 80398af4 <svc_write_space+44/b0>
Trace; 8029a374 <sock_wfree+140/1d4>
Trace; 800b87ac <update_process_times+2c/54>
Trace; 800ad20c <profile_tick+40/48>
Trace; 8029ccbc <__kfree_skb+d0/430>
Trace; 802bc8b0 <zap_completion_queue+8c/d8>
Trace; 802bc918 <find_skb+1c/140>
Trace; 802bcba8 <netpoll_send_udp+3c/30c>
Trace; 802575bc <serial8250_console_write+a4/354>
Trace; 8027b370 <write_msg+70/b8>
Trace; 800abe34 <__call_console_drivers+8c/94>
Trace; 800abe34 <__call_console_drivers+8c/94>
Trace; 800b3168 <__do_softirq+108/11c>
Trace; 800abebc <_call_console_drivers+80/90>
Trace; 800abf80 <call_console_drivers+b4/170>
Trace; 800ac6b8 <release_console_sem+c8/288>
Trace; 8022e900 <vscnprintf+14/30>
Trace; 800ac34c <vprintk+1cc/32c>
Trace; 8022e900 <vscnprintf+14/30>
Trace; 800ac278 <vprintk+f8/32c>
Trace; 800ac174 <printk+1c/28>
Trace; 80279dec <t21142_timer+46c/474>
Trace; 80279980 <t21142_timer+0/474>
Trace; 800b8954 <run_timer_softirq+14c/2a8>
Trace; 802b9458 <nf_iterate+d4/118>
Trace; 800b3168 <__do_softirq+108/11c>
Trace; 80084808 <handle_IRQ_event+6c/f0>
Trace; 800b3208 <do_softirq+8c/94>
Trace; 80084e18 <do_IRQ+1c8/208>
Trace; 80082908 <cobalt_irq+68/180>
Trace; 802dc1bc <ip_finish_output2+0/5b4>
Trace; 80083180 <ret_from_exception+0/0>
Trace; 802d89d8 <ip_output+78/94>
Trace; 8030ffdc <inet_sendmsg+60/84>
Trace; 80303260 <udp_sendmsg+374/a74>
Trace; 802da298 <ip_generic_getfrag+0/bc>
Trace; 80084e28 <do_IRQ+1d8/208>
Trace; 8029afb0 <sock_alloc_send_pskb+208/56c>
Trace; 8029b330 <sock_alloc_send_skb+1c/28>
Trace; 80138718 <iput+4c/a8>
Trace; 802dad80 <ip_append_data+a2c/b1c>
Trace; 80134538 <d_alloc_anon+30/1a4>
Trace; 800a4198 <try_to_wake_up+140/1b0>
Trace; 802d07c0 <ip_route_output_flow+88/ac>
Trace; 803031ec <udp_sendmsg+300/a74>
Trace; 8030ffdc <inet_sendmsg+60/84>
Trace; 80214364 <selinux_socket_sendmsg+1c/28>
Trace; 80295864 <sock_sendmsg+10c/114>
Trace; 800a7440 <autoremove_wake_function+0/44>
Trace; 8030ffdc <inet_sendmsg+60/84>
Trace; 80214364 <selinux_socket_sendmsg+1c/28>
Trace; 80295894 <kernel_sendmsg+28/3c>
Trace; 80295864 <sock_sendmsg+10c/114>
Trace; 8029b7b4 <sock_no_sendpage+68/74>
Trace; 80303ab8 <udp_sendpage+158/194>
Trace; 80303aa0 <udp_sendpage+140/194>
Trace; 8020e0d4 <file_alloc_security+2c/a0>
Trace; 800a7440 <autoremove_wake_function+0/44>
Trace; 802120f4 <selinux_inode_getattr+70/7c>
Trace; 800a40c8 <try_to_wake_up+70/1b0>
Trace; 80310070 <inet_sendpage+70/d0>
Trace; 80398698 <svc_sendto+8c/244>
Trace; 80398840 <svc_sendto+234/244>
Trace; 8029ca50 <skb_release_data+118/280>
Trace; 801d6f8c <nfssvc_encode_attrstat+37c/5a0>
Trace; 8029cd50 <__kfree_skb+164/430>
Trace; 8039918c <svc_udp_sendto+20/5c>
Trace; 801cab18 <fh_put+18c/288>
Trace; 8039b554 <svc_send+210/2ec>
Trace; 8039c8a4 <svc_authorise+30/170>
Trace; 801d8068 <nfssvc_release_fhandle+10/28>
Trace; 80397740 <svc_process+334/894>
Trace; 800bdbe8 <sigprocmask+98/1ec>
Trace; 801c7398 <nfsd+2cc/6b8>
Trace; 801c7274 <nfsd+1a8/6b8>
Trace; 801c70cc <nfsd+0/6b8>
Trace; 80086070 <kernel_thread_helper+10/18>
Trace; 80086060 <kernel_thread_helper+0/18>
 

-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Ralf Baechle
Sent: Monday, December 27, 2004 5:31 PM
To: Habeeb J. Dihu
Cc: linux-mips@linux-mips.org
Subject: Re: 2.6.9 Cobalt Tulip lockups.

On Mon, Dec 27, 2004 at 05:12:50PM -0600, Habeeb J. Dihu wrote:

> eth0: MII status 782d, Link partner report 45e1.
> eth0: 21143 negotiation status 000000c6, MII.
> Badness in local_bh_enable at kernel/softirq.c:141
> Call Trace: [<800b32c8>]  [<80084e28>]  [<80397ee8>]  [<80397f08>]
> [<80398af4>]  [<8029a374>]  [<800b87ac>]  [<800ad20c>]  [<8029ccbc>]
> [<802bc8b0>]  [<802bc918>]  [<802bcba8>]  [<802575bc>]  [<8027b370>]
> [<800abe34>]  [<800abe34>]  [<800b3168>]  [<800abebc>]  [<800abf80>]
> [<800ac6b8>]  [<8022e900>]  [<800ac34c>]  [<8022e900>]  [<800ac278>]
> [<800ac174>]  [<80279dec>]  [<80279980>]  [<800b8954>]  [<802b9458>]
> [<800b3168>]  [<80084808>]  [<800b3208>]  [<80084e18>]  [<80082908>]
> [<802dc1bc>]  [<80083180>]  [<802d89d8>]  [<8030ffdc>]  [<80303260>]
> [<802da298>]  [<80084e28>]  [<8029afb0>]  [<8029b330>]  [<80138718>]
> [<802dad80>]  [<80134538>]  [<800a4198>]  [<802d07c0>]  [<803031ec>]
> [<8030ffdc>]  [<80214364>]  [<80295864>]  [<800a7440>]  [<8030ffdc>]
> [<80214364>]  [<80295894>]  [<80295864>]  [<8029b7b4>]  [<80303ab8>]
> [<80303aa0>]  [<8020e0d4>]  [<800a7440>]  [<802120f4>]  [<800a40c8>]
> [<80310070>]  [<80398698>]  [<80398840>]  [<8029ca50>]  [<801d6f8c>]
> [<8029cd50>]  [<8039918c>]  [<801cab18>]  [<8039b554>]  [<8039c8a4>]
> [<801d8068>]  [<80397740>]  [<800bdbe8>]  [<801c7398>]  [<801c7274>]
> [<801c70cc>]  [<80086070>]  [<80086060>] 

Can you decode this dump?  Undecoded it's useless, decoded likely to
be useful ...

  Ralf


From m_lachwani@yahoo.com Tue Dec 28 04:02:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Dec 2004 04:03:05 +0000 (GMT)
Received: from web52804.mail.yahoo.com ([IPv6:::ffff:206.190.39.168]:39799
	"HELO web52804.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225281AbUL1EC5>; Tue, 28 Dec 2004 04:02:57 +0000
Received: (qmail 34539 invoked by uid 60001); 28 Dec 2004 04:02:40 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=I1gaHzf2ZiCDizaqb7JlJwCH/rIWdikP/KDBAqRpsEKI8GSEyY4AfO+bJdc0WrBVo+U3z8sC2cUSX7Q8KyDV7QnSAMnwzNyw68n75srOZkI7x7DFRcNoTKffo2tuwHqi1d3xZnMStxr6HQCEiueI/eEN8O4pcDra+pQoaGk8HYw=  ;
Message-ID: <20041228040240.34537.qmail@web52804.mail.yahoo.com>
Received: from [203.145.153.155] by web52804.mail.yahoo.com via HTTP; Mon, 27 Dec 2004 20:02:40 PST
Date: Mon, 27 Dec 2004 20:02:40 -0800 (PST)
From: Manish Lachwani <m_lachwani@yahoo.com>
Subject: RE: Some cache questions
To: Brad Larson <Brad_Larson@pmc-sierra.com>,
	'Thomas Petazzoni' <thomas.petazzoni@enix.org>,
	linux-mips@linux-mips.org
In-Reply-To: <04781D450CFF604A9628C8107A62FCCF013DDAE4@sjc1exm01.pmc_nt.nt.pmc-sierra.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <m_lachwani@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: 6776
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: m_lachwani@yahoo.com
Precedence: bulk
X-list: linux-mips

Hello !

For chip revisions 1.0 and 1.1, there are some changes
to the memory management subsystem for the kernel to
work on the board (dual core). As already known, these
versions dont support Shared state.

I had made those changes to the 2.4.21 kernel. Maybe
you can take a look at those changes and port them to
2.6 appropriately. However, there is more sanity in
1.2 version

Thanks
Manish Lachwani


--- Brad Larson <Brad_Larson@pmc-sierra.com> wrote:

> You haven't mentioned which board.  If its Yosemite
> then you may have one of the few not upgraded to 1.2
> silicon.  If so it won't work with the changes
> committed by Ralf which requires the shared state
> for SMP boot.  For further discussion contact the
> apps@pmc-sierra.com
> 
> --Brad
> 
> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf
> Of Thomas Petazzoni
> Sent: Monday, December 27, 2004 8:35 AM
> To: linux-mips@linux-mips.org
> Subject: Some cache questions
> 
> 
> Hello,
> 
> I'm using an RM9000 dual-core processor, buggy
> revisions (the one that 
> doesn't support the "Shared" cache state if I
> understood correctly).
> 
> When going through the CVS logs, I saw that Ralf
> quite recently changed 
> the cache mode from 4 to 5 in pgtable-bits.h. Is
> that change involved in 
> the use of the "Shared" cache state with newer
> RM9000 revisions that 
> don't have the bug ?
> 
> Currently, the KSEG0 cache coherency mode (2 lower
> bits of the CONFIG 
> register) is set to 3 during PMON (start.S file).
> When I write something 
> to the memory through KSEG0 with the first core, it
> doesn't appear to be 
> read by the second core. This indicates, in my
> opinion, that the cache 
> line of the first core hasn't been written to memory
> so that the second 
> core could use it. Am I right ?
> 
> If I want to correctly use both cores using KSEG0,
> should I set the mode 
> in the CONFIG register to 4 (so that I can work with
> buggy processors) ?
> 
> Thanks,
> 
> Thomas
> -- 
> PETAZZONI Thomas - thomas.petazzoni@enix.org
> http://thomas.enix.org - Jabber:
> thomas.petazzoni@jabber.dk
> http://kos.enix.org, http://sos.enix.org
> Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653
> CB30 98D3 F7A7
> 
> 


From thomas.petazzoni@enix.org Tue Dec 28 08:19:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Dec 2004 08:19:23 +0000 (GMT)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:27114 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8224908AbUL1ITS>; Tue, 28 Dec 2004 08:19:18 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by the-doors.enix.org (Postfix) with ESMTP id 53B7F400F9
	for <linux-mips@linux-mips.org>; Tue, 28 Dec 2004 09:19:24 +0100 (CET)
Message-ID: <41D1178B.3090404@enix.org>
Date: Tue, 28 Dec 2004 09:21:31 +0100
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040926)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Some cache questions
References: <20041228040240.34537.qmail@web52804.mail.yahoo.com>
In-Reply-To: <20041228040240.34537.qmail@web52804.mail.yahoo.com>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig9C8E60CF4B668B8B792CAFFA"
Content-Transfer-Encoding: 8bit
Return-Path: <thomas.petazzoni@enix.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: 6777
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thomas.petazzoni@enix.org
Precedence: bulk
X-list: linux-mips

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9C8E60CF4B668B8B792CAFFA
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

Manish Lachwani a écrit :

> For chip revisions 1.0 and 1.1, there are some changes
> to the memory management subsystem for the kernel to
> work on the board (dual core). As already known, these
> versions dont support Shared state.
> 
> I had made those changes to the 2.4.21 kernel. Maybe
> you can take a look at those changes and port them to
> 2.6 appropriately. However, there is more sanity in
> 1.2 version

Actually, my question was not really Linux-specific. On the second core, 
I will not use the MMU, because this core will not run Linux, but a 
custom code. Both cores will share informations through KSEG0, so I need 
to maintain coherency between caches. What should I do in order to do 
that ? Is it enough to set cache mode for KSEG0 to 4 (in the CONFIG 
register) ?

I have only 1.0 and 1.1 cores, on home-made boards, so there's no way to 
switch to 1.2.

BTW, do you have pointers, papers, information about a system running 
Linux on a core, and some custom code on a second core, in order to have 
real-time on the second core with very low latency ?

Thanks,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org
http://thomas.enix.org - Jabber: thomas.petazzoni@jabber.dk
http://kos.enix.org, http://sos.enix.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

--------------enig9C8E60CF4B668B8B792CAFFA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB0ReV9lPLMJjT96cRAtS8AKCbxhX+xvSYU3CudmEjDe6OV5TU4ACdHpR4
8eopaSZSDBllSLMAxNAXQnQ=
=vFkD
-----END PGP SIGNATURE-----

--------------enig9C8E60CF4B668B8B792CAFFA--

From nsekhar@ti.com Tue Dec 28 14:41:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Dec 2004 14:41:50 +0000 (GMT)
Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:63671 "EHLO
	go4.ext.ti.com") by linux-mips.org with ESMTP id <S8225192AbUL1Olm> convert rfc822-to-8bit;
	Tue, 28 Dec 2004 14:41:42 +0000
Received: from dlep91.itg.ti.com ([157.170.152.55])
	by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id iBSEfL0e021320;
	Tue, 28 Dec 2004 08:41:23 -0600 (CST)
Received: from dbde2k01.ent.ti.com (localhost [127.0.0.1])
	by dlep91.itg.ti.com (8.12.11/8.12.11) with ESMTP id iBSEfIcb014471;
	Tue, 28 Dec 2004 08:41:19 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Subject: RE: do_ri exception in Linux (MIPS 4kec)
Date: Tue, 28 Dec 2004 20:11:16 +0530
Message-ID: <F6B01C6242515443BB6E5DDD63AE935F046804@dbde2k01.itg.ti.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: do_ri exception in Linux (MIPS 4kec)
Thread-Index: AcTsD9yVrj6PGEd/T5iWluYb3MjpcwA1eNlg
From: "Nori, Soma Sekhar" <nsekhar@ti.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>, "Iyer, Suraj" <ssiyer@ti.com>
Return-Path: <nsekhar@ti.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6778
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nsekhar@ti.com
Precedence: bulk
X-list: linux-mips

Ralf,

Thanks for the input.

To understand what exceptions I was getting (apart from RI), I implemented a counter for each exception.
In "except_vec3_generic" (entry.S), I included some code to increment a counter for each exception received.

<code>
	NESTED(except_vec3_generic, 0, sp)

#if defined(CONFIG_CPU_R5432)
	/* [jsun] work around a nasty bug in R5432  */
	mfc0	k0, CP0_INDEX
#endif 
	mfc0	k1, CP0_CAUSE
      la    k0, exception_counter
	andi	k1, k1, 0x7c                
	addu	k0, k0, k1
      lw    k1, (k0)
      addi  k1, k1, 1
      sw    k1, (k0)

	... (original code follows)

</code>

exception_counter is an array of 32 integers. On printing out the array in do_ri exception handler, I found that only TLB Mod(Code 1), TLBL (Code 2), TLBS (Code 3), syscall (code 8) and RI (code 10) exceptions were received (had count >= 1). With this, will it be safe to assume that RI is the only unwanted exception?

To get hold of exact EPC at which RI is occuring, I tried to clear the EXL bit of status register by adding some more code above the exception counting code in the except_vec3_generic routine.

<code>
	NESTED(except_vec3_generic, 0, sp)

#if defined(CONFIG_CPU_R5432)
	/* [jsun] work around a nasty bug in R5432  */
	mfc0	k0, CP0_INDEX
#endif 
      mfc0    k0, CP0_STATUS
      nop
      ori     k0, k0, 0x2
      xori    k0, k0, 0x2
      mtc0    k0, CP0_STATUS
      nop
	
	... (Exception counting code follows)

</code>

Surprisingly, the processor does not seem to alow me to clear the EXL bit. I get AdEL (code 4) exception as I complete the "mtc0    k0, CP0_STATUS" instruction. The processor goes into an infinite loop of exceptions and boot-up hangs after printing "Freeing unused kernel memory: 48k freed". Is it not possible for software to clear the EXL bit after it has been set by the hardware? If not, what else can I do to get hold of the correct EPC value where RI is occuring?

Thanks,
Sekhar
        

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Monday, December 27, 2004 6:00 PM
To: Nori, Soma Sekhar
Cc: linux-mips@linux-mips.org; Iyer, Suraj
Subject: Re: do_ri exception in Linux (MIPS 4kec)


On Thu, Dec 23, 2004 at 04:58:03PM +0530, Nori, Soma Sekhar wrote:

> We are using montavista Linux version 2.4.17, gcc version 2.95.3 running on MIPS 4kec.
> 
> Here is the dump:
> $0 : 00000000 0044def4 000001ac 0000006b 00000000 7fff7c08 00000001 00000000
> $8 : 0000fc00 00000001 00000000 941524d0 00004700 00000000 97fc3ea0 7fff7c08
> $16: 100048a4 100029d8 100029d8 10003020 00000000 7fff7dc8 10003b60 2d8e2163
> $24: 00000001 2ab7bc30                   10008e70 7fff7bf0 04000000 00439e50
> Hi : 00000000
> Lo : 00000001
> epc  : 00439e84    Not tainted
> Status: 0000fc13
> Cause : 10800028
> Process sh (pid: 18, stackpage=97fc2000)
> Stack: 00000001 00000000 2abd0ff0 7fff7c28 10008e70 00000000 10008e6c 00000000
>        100049a0 0042f188 00000000 100029d8 00000001 00000001 7fff7f04 10008e70
>        00427fe4 00427f00 00000000 00000000 10002764 10008e70 10008e70 00000000
>        00000000 00000000 10008e70 00422734 00000001 00000001 7fff7f04 10008e70
>        10008e70 00000003 10008e70 004315cc 00000001 00000000 10002764 00000000
>        10008e70 ...
> Call Trace:
> Code: 00000000  2421dd48  00220821 <8c220000> 00000000  005c1021  00400008  0000
> 0000  8f99802c
> 
> The epc is not in kernel space and ksymoops did not provide any info. The epc keeps changing to different locations in user space over multiple runs.

In a case like this you're likely dealing with double exceptions.  Your
code is taking an exception and the exception handler while running with
c0_status set is taking another exception.  If the first exception handler
is still running with the c0_status.exl bit set the CPU when taking the
second exception it will not record the PC of the second exception and
you will have a seemingly unexplainable exception.

A few processors have the nasty habit of throwing RI receptions or do
similarly weird things when executing code that is mapped through multiple
TLB pages but the 4kEC shouldn't.

  Ralf

From vprashant@echelon.com Tue Dec 28 20:24:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Dec 2004 20:24:34 +0000 (GMT)
Received: from ntfw.echelon.com ([IPv6:::ffff:205.229.50.10]:1556 "EHLO
	[205.229.50.10]") by linux-mips.org with ESMTP id <S8225227AbUL1UY2>;
	Tue, 28 Dec 2004 20:24:28 +0000
Received: from miles.echelon.com by [205.229.50.10]
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with ESMTP; Tue, 28 Dec 2004 12:24:28 -0800
Received: by miles.echelon.com with Internet Mail Service (5.5.2653.19)
	id <ZK16SX9S>; Tue, 28 Dec 2004 12:24:16 -0800
Message-ID: <5375D9FB1CC3994D9DCBC47C344EEB59016543D9@miles.echelon.com>
From: Prashant Viswanathan <vprashant@echelon.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: defconfig for dbAu1550 (Cabarnet) and problems booting kernel
Date: Tue, 28 Dec 2004 12:24:03 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Return-Path: <vprashant@echelon.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: 6779
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vprashant@echelon.com
Precedence: bulk
X-list: linux-mips


Hi All,

I am trying to get Linux up and running on the DbAu1550 (Cabarnet) using the
latest code from linux-mips.org.  I was wondering if somebody would have a
default config file for building the kernel.

Also, when I try to boot the kernel from Yamon, I don't see anything
happening. Any ideas on what could be wrong?
YAMON> go . console=ttyS0,115200
<< nothing happens after this >>

Thanks for any pointers/help.

Prashant 

From ppopov@embeddedalley.com Tue Dec 28 20:33:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Dec 2004 20:33:13 +0000 (GMT)
Received: from web201.biz.mail.re2.yahoo.com ([IPv6:::ffff:68.142.224.163]:58813
	"HELO web201.biz.mail.re2.yahoo.com") by linux-mips.org with SMTP
	id <S8225227AbUL1UdI>; Tue, 28 Dec 2004 20:33:08 +0000
Message-ID: <20041228203251.7298.qmail@web201.biz.mail.re2.yahoo.com>
Received: from [63.194.140.131] by web201.biz.mail.re2.yahoo.com via HTTP; Tue, 28 Dec 2004 12:32:51 PST
Date: Tue, 28 Dec 2004 12:32:51 -0800 (PST)
From: Peter Popov <ppopov@embeddedalley.com>
Subject: Re: defconfig for dbAu1550 (Cabarnet) and problems booting kernel
To: Prashant Viswanathan <vprashant@echelon.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <5375D9FB1CC3994D9DCBC47C344EEB59016543D9@miles.echelon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <ppopov@embeddedalley.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: 6780
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips


> I am trying to get Linux up and running on the
> DbAu1550 (Cabarnet) using the
> latest code from linux-mips.org.  I was wondering if
> somebody would have a default config file 
> for building the kernel.

The DbAu1550 should just work with the default config
that's in arch/mips/defconfigs. There have been a
number of patches that went into the tree since I was
built a kernel for that board, but assuming the
patches did not break anything, the kernel should
boot.

> Also, when I try to boot the kernel from Yamon, I
> don't see anything
> happening. Any ideas on what could be wrong?
> YAMON> go . console=ttyS0,115200
> << nothing happens after this >>

If you are using the arch/mips/de
--- Prashant Viswanathan <vprashant@echelon.com>
wrote:

> 
> Hi All,
> 
fconfigs/ 1550 config file, it will expect to mount an
nfs root fs. The proper way to boot it is:
go . ip=any root=/dev/nfs

However, the fact that you don't see anything on the
console is really suspicious. I'll pull the latest
bits tonight and see if something broke.

Pete

From vprashant@echelon.com Tue Dec 28 20:53:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Dec 2004 20:53:55 +0000 (GMT)
Received: from ntfw.echelon.com ([IPv6:::ffff:205.229.50.10]:50479 "EHLO
	[205.229.50.10]") by linux-mips.org with ESMTP id <S8225227AbUL1Uxu>;
	Tue, 28 Dec 2004 20:53:50 +0000
Received: from miles.echelon.com by [205.229.50.10]
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with ESMTP; Tue, 28 Dec 2004 12:53:50 -0800
Received: by miles.echelon.com with Internet Mail Service (5.5.2653.19)
	id <ZK16SYJG>; Tue, 28 Dec 2004 12:53:37 -0800
Message-ID: <5375D9FB1CC3994D9DCBC47C344EEB59016543DA@miles.echelon.com>
From: Prashant Viswanathan <vprashant@echelon.com>
To: 'Peter Popov' <ppopov@embeddedalley.com>,
	Prashant Viswanathan <vprashant@echelon.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: RE: defconfig for dbAu1550 (Cabarnet) and problems booting kernel
Date: Tue, 28 Dec 2004 12:53:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Return-Path: <vprashant@echelon.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: 6781
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vprashant@echelon.com
Precedence: bulk
X-list: linux-mips


>> I am trying to get Linux up and running on the
>> DbAu1550 (Cabarnet) using the
>> latest code from linux-mips.org.  I was wondering if
>> somebody would have a default config file 
>> for building the kernel.

> The DbAu1550 should just work with the default config
> that's in arch/mips/defconfigs. There have been a
> number of patches that went into the tree since I was
> built a kernel for that board, but assuming the
> patches did not break anything, the kernel should
> boot.

When I pull the sources from linux-mips.org, I don't get anything in the
arch/mips/defconfigs directory. I see a lot of files in the "Attic", but not
one for the DbAu1550.

Thanks
Prashant

From ppopov@embeddedalley.com Tue Dec 28 20:58:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Dec 2004 20:58:17 +0000 (GMT)
Received: from web201.biz.mail.re2.yahoo.com ([IPv6:::ffff:68.142.224.163]:7517
	"HELO web201.biz.mail.re2.yahoo.com") by linux-mips.org with SMTP
	id <S8225227AbUL1U6N>; Tue, 28 Dec 2004 20:58:13 +0000
Message-ID: <20041228205757.11695.qmail@web201.biz.mail.re2.yahoo.com>
Received: from [63.194.140.131] by web201.biz.mail.re2.yahoo.com via HTTP; Tue, 28 Dec 2004 12:57:57 PST
Date: Tue, 28 Dec 2004 12:57:57 -0800 (PST)
From: Peter Popov <ppopov@embeddedalley.com>
Subject: RE: defconfig for dbAu1550 (Cabarnet) and problems booting kernel
To: Prashant Viswanathan <vprashant@echelon.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <5375D9FB1CC3994D9DCBC47C344EEB59016543DA@miles.echelon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <ppopov@embeddedalley.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: 6782
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips


> When I pull the sources from linux-mips.org, I don't
> get anything in the
> arch/mips/defconfigs directory. I see a lot of files
> in the "Attic", but not one for the DbAu1550.

Sorry, I meant arch/mips/configs. There is a
db1550_defconfig there.

Pete

From goldfinger@member.fsf.org Tue Dec 28 21:41:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Dec 2004 21:41:33 +0000 (GMT)
Received: from host125-164.pool80181.interbusiness.it ([IPv6:::ffff:80.181.164.125]:26094
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225285AbUL1Vl2>; Tue, 28 Dec 2004 21:41:28 +0000
Received: by localhost.localdomain (Postfix, from userid 501)
	id D4026110DF1; Tue, 28 Dec 2004 23:40:02 +0100 (CET)
Subject: origin-2100
From: Michele Carla` <goldfinger@member.fsf.org>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Tue, 28 Dec 2004 23:40:02 +0100
Message-Id: <1104273602.2980.18.camel@trogo>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 
Return-Path: <goldfinger@member.fsf.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: 6783
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: goldfinger@member.fsf.org
Precedence: bulk
X-list: linux-mips

Hello I'm new to this list ...I hope this is the right place to ask for
(if not sorry)...

At the HackLab of firenze we are going to buy an origin 2100, we would
like to install Linux on it (and use it probably as a server)...
I would like to know if it is well supported by Linux-kernel (scsi,
ethernet, pci... ecc ecc)

sorry for bad english !

Cheers !

Michele Carla`

From vprashant@echelon.com Wed Dec 29 00:43:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Dec 2004 00:43:10 +0000 (GMT)
Received: from ntfw.echelon.com ([IPv6:::ffff:205.229.50.10]:11015 "EHLO
	[205.229.50.10]") by linux-mips.org with ESMTP id <S8225285AbUL2AnF>;
	Wed, 29 Dec 2004 00:43:05 +0000
Received: from miles.echelon.com by [205.229.50.10]
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with ESMTP; Tue, 28 Dec 2004 16:43:04 -0800
Received: by miles.echelon.com with Internet Mail Service (5.5.2653.19)
	id <ZK16S64D>; Tue, 28 Dec 2004 16:42:52 -0800
Message-ID: <5375D9FB1CC3994D9DCBC47C344EEB59016543DF@miles.echelon.com>
From: Prashant Viswanathan <vprashant@echelon.com>
To: 'Peter Popov' <ppopov@embeddedalley.com>,
	Prashant Viswanathan <vprashant@echelon.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: RE: dbAu1550 (Cabarnet) - problems booting kernel - hangs at "Sen
	ding BOOTP" and root file system for MIPS (BE)
Date: Tue, 28 Dec 2004 16:42:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Return-Path: <vprashant@echelon.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: 6784
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vprashant@echelon.com
Precedence: bulk
X-list: linux-mips


>> When I pull the sources from linux-mips.org, I don't
>> get anything in the
>> arch/mips/defconfigs directory. I see a lot of files
>> in the "Attic", but not one for the DbAu1550.

> Sorry, I meant arch/mips/configs. There is a
> db1550_defconfig there.

I was able to build and load the kernel using this file. Thanks to Pete for
that. 

The only change I had to make was to drivers/mtd/maps/db1550-flash.c which
was referencing asm/au1000.h. This file has moved to
asm/mach-au1x00/au1000.h. I also changed the config file to indicate Big
Endian instead of Little Endian default. The tool chain was BE and the board
was configured to boot in BE too.

However, the kernel seems to hang in "Sending BOOTP Requests"
<snip>
Sending BOOTP requests .<6>eth0: link up
eth1: link up
..... timed out!
IP-Config: Reopening network devices...
Sending BOOTP requests ....
</snip>

The same happens whether I use "go . ip=any" or "go . ip=10.2.11.185" from
yamon. All the other nodes on this network also use DHCP to get their
addresses and they have no problems. The board itself boots using tftp so
the network connectivity must be good.

My next step would be to specify a root file system. Where can I find a root
file system (or/and compiled package) for MIPS (BE)? I saw this thread (link
below) on the mailing list, but none of these links work now. 
http://www.linux-mips.org/archives/linux-mips/2001-03/threads.html#00008


Thanks
Prashant

From jgreen@users.sourceforge.net Wed Dec 29 00:56:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Dec 2004 00:56:43 +0000 (GMT)
Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:4046
	"EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP
	id <S8225285AbUL2A4i>; Wed, 29 Dec 2004 00:56:38 +0000
Received: from iria.infostations.net (iria.infostations.net [71.4.40.31])
	by mail-relay.infostations.net (Postfix) with ESMTP id DDA9AA1421;
	Wed, 29 Dec 2004 00:56:14 +0000 (Local time zone must be set--see zic manual page)
Received: from host-69-19-171-18.rev.o1.com ([69.19.171.18])
	by iria.infostations.net with esmtp (Exim 4.41 #1 (Gentoo))
	id 1CjSAF-0006PM-7e; Tue, 28 Dec 2004 16:58:13 -0800
Subject: RE: dbAu1550 (Cabarnet) - problems booting kernel - hangs at "Sen
	ding BOOTP" and root file system for MIPS (BE)
From: Josh Green <jgreen@users.sourceforge.net>
To: Prashant Viswanathan <vprashant@echelon.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <5375D9FB1CC3994D9DCBC47C344EEB59016543DF@miles.echelon.com>
References: <5375D9FB1CC3994D9DCBC47C344EEB59016543DF@miles.echelon.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lNfSlEGaqSuO1iYwzP3b"
Date: Tue, 28 Dec 2004 16:55:55 -0800
Message-Id: <1104281755.14675.13.camel@SillyPuddy.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 
Return-Path: <jgreen@users.sourceforge.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: 6785
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgreen@users.sourceforge.net
Precedence: bulk
X-list: linux-mips


--=-lNfSlEGaqSuO1iYwzP3b
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2004-12-28 at 16:42 -0800, Prashant Viswanathan wrote:
> However, the kernel seems to hang in "Sending BOOTP Requests"
> <snip>
> Sending BOOTP requests .<6>eth0: link up
> eth1: link up
> ..... timed out!
> IP-Config: Reopening network devices...
> Sending BOOTP requests ....
> </snip>
>=20

Perhaps you don't have a bootp service on your network.  I usually put
ip=3Ddhcp (go to Device Drivers->Networking support->Networking options
and enable IP: DHCP support).

> The same happens whether I use "go . ip=3Dany" or "go . ip=3D10.2.11.185"=
 from
> yamon. All the other nodes on this network also use DHCP to get their
> addresses and they have no problems. The board itself boots using tftp so
> the network connectivity must be good.
>=20
> My next step would be to specify a root file system. Where can I find a r=
oot
> file system (or/and compiled package) for MIPS (BE)? I saw this thread (l=
ink
> below) on the mailing list, but none of these links work now.=20
> http://www.linux-mips.org/archives/linux-mips/2001-03/threads.html#00008
>=20

You could build your own tool chain and root file system, which is what
I did (I have a dbAu1100 board).  I used the buildroot package which is
part of the uclibc project:
http://www.uclibc.org/

You can download the buildroot CVS tarball here (just look for the
"Download tarball" link at the bottom:
http://www.uclibc.org/cgi-bin/cvsweb/buildroot/

It has a "make menuconfig" style configuration system and will build
busybox and other programs and create an ext2 file system, etc.  I opted
to build busybox and the mips kernel separately though (so I could more
easily configure them).  I now have a cross compiler and tool chain for
my x86 laptop.

>=20
> Thanks
> Prashant
>=20

Cheers.
	Josh Green


--=-lNfSlEGaqSuO1iYwzP3b
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD8DBQBB0gCaRoMuWKCcbgQRAlifAKCYaTeSjiuFwOATtedE3gOEoDWiiwCdGKLq
9iUgryadeXfUktVUxCc3E7M=
=J3UI
-----END PGP SIGNATURE-----

--=-lNfSlEGaqSuO1iYwzP3b--


From vprashant@echelon.com Wed Dec 29 01:24:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Dec 2004 01:24:09 +0000 (GMT)
Received: from ntfw.echelon.com ([IPv6:::ffff:205.229.50.10]:21535 "EHLO
	[205.229.50.10]") by linux-mips.org with ESMTP id <S8225285AbUL2BYF>;
	Wed, 29 Dec 2004 01:24:05 +0000
Received: from miles.echelon.com by [205.229.50.10]
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with ESMTP; Tue, 28 Dec 2004 17:24:05 -0800
Received: by miles.echelon.com with Internet Mail Service (5.5.2653.19)
	id <ZK16S71Y>; Tue, 28 Dec 2004 17:23:54 -0800
Message-ID: <5375D9FB1CC3994D9DCBC47C344EEB59016543E2@miles.echelon.com>
From: Prashant Viswanathan <vprashant@echelon.com>
To: 'Josh Green' <jgreen@users.sourceforge.net>,
	Prashant Viswanathan <vprashant@echelon.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: RE: dbAu1550 (Cabarnet) - problems booting kernel - hangs at "Sen
	ding BOOTP" and root file system for MIPS (BE)
Date: Tue, 28 Dec 2004 17:23:54 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Return-Path: <vprashant@echelon.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: 6786
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vprashant@echelon.com
Precedence: bulk
X-list: linux-mips

> > However, the kernel seems to hang in "Sending BOOTP Requests"
> > <snip>
> > Sending BOOTP requests .<6>eth0: link up
> > eth1: link up
> > ..... timed out!
> > IP-Config: Reopening network devices...
> > Sending BOOTP requests ....
> > </snip>
> >
> 
> Perhaps you don't have a bootp service on your network.  I usually put
> ip=dhcp (go to Device Drivers->Networking support->Networking options
> and enable IP: DHCP support).

With DHCP support enabled it works.

> You could build your own tool chain and root file system, which is what
> I did (I have a dbAu1100 board).  I used the buildroot package which is
> part of the uclibc project:
> http://www.uclibc.org/
> 
> You can download the buildroot CVS tarball here (just look for the
> "Download tarball" link at the bottom:
> http://www.uclibc.org/cgi-bin/cvsweb/buildroot/
> 
> It has a "make menuconfig" style configuration system and will build
> busybox and other programs and create an ext2 file system, etc.  I opted
> to build busybox and the mips kernel separately though (so I could more
> easily configure them).  I now have a cross compiler and tool chain for
> my x86 laptop.

I used the toolchain from mips.com to build the kernel. I guess I will have
to do what you suggest to get a root file system. I was under the impression
that several pre-built root file systems existed for MIPS.

Thanks a lot!
Prashant


From priya@procsys.com Wed Dec 29 05:01:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Dec 2004 05:01:27 +0000 (GMT)
Received: from dsl-KK-049.206.95.61.touchtelindia.net ([IPv6:::ffff:61.95.206.49]:33719
	"EHLO trishul.procsys.com") by linux-mips.org with ESMTP
	id <S8224900AbUL2FBW>; Wed, 29 Dec 2004 05:01:22 +0000
Received: from procsys.com ([192.168.1.128])
	by trishul.procsys.com (8.12.10/8.12.10) with ESMTP id iBT4mvXb012270
	for <linux-mips@linux-mips.org>; Wed, 29 Dec 2004 10:19:08 +0530
Message-ID: <41D23806.BC19A3C9@procsys.com>
Date: Wed, 29 Dec 2004 10:22:22 +0530
From: priya <priya@procsys.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Problem when the CPU cache is turned on
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ProcSys-Com-Anti-Virus-Mail-Filter-Virus-Found: no
Return-Path: <priya@procsys.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: 6787
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: priya@procsys.com
Precedence: bulk
X-list: linux-mips

Hi,
Iam trying to bring up a custom board
with RM5231A MIPS processor and IT8172
companion chip. Right now i have an
issue related to running Linux 2.4.25 on
MIPS with cache enabled.

When i run the kernel with CPU Cache
enabled, i get the following error
messages.
A. "Unhandled kernel unaligned access or
invalid instruction in
unaligned.c::emulate_load_store_insn,
line 493:"
B. "Reserved instruction in kernel code
in traps.c::do_ri, line 663:"
C. "Unable to handle kernel paging
request at virtual address 00000000

These errors happen when i run fsck, vi
or a simple du command.

When i trun on the "Run uncached"
option  these errors disapper.

I do not know where to start debugging.
Can any one tell me what could be the
problem when the cache is turned on.

regards
priya




From ppopov@embeddedalley.com Wed Dec 29 07:25:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Dec 2004 07:25:20 +0000 (GMT)
Received: from web209.biz.mail.re2.yahoo.com ([IPv6:::ffff:68.142.224.171]:45467
	"HELO web209.biz.mail.re2.yahoo.com") by linux-mips.org with SMTP
	id <S8224905AbUL2HZL>; Wed, 29 Dec 2004 07:25:11 +0000
Message-ID: <20041229072454.30862.qmail@web209.biz.mail.re2.yahoo.com>
Received: from [63.194.214.47] by web209.biz.mail.re2.yahoo.com via HTTP; Tue, 28 Dec 2004 23:24:54 PST
Date: Tue, 28 Dec 2004 23:24:54 -0800 (PST)
From: Peter Popov <ppopov@embeddedalley.com>
Subject: Re: Problem when the CPU cache is turned on
To: priya <priya@procsys.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <41D23806.BC19A3C9@procsys.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <ppopov@embeddedalley.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: 6788
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips


> Iam trying to bring up a custom board
> with RM5231A MIPS processor and IT8172
> companion chip. Right now i have an
> issue related to running Linux 2.4.25 on
> MIPS with cache enabled.
 
> When i run the kernel with CPU Cache
> enabled, i get the following error
> messages.
> A. "Unhandled kernel unaligned access or
> invalid instruction in
> unaligned.c::emulate_load_store_insn,
> line 493:"
> B. "Reserved instruction in kernel code
> in traps.c::do_ri, line 663:"
> C. "Unable to handle kernel paging
> request at virtual address 00000000
> 
> These errors happen when i run fsck, vi
> or a simple du command.
 
> When i trun on the "Run uncached"
> option  these errors disapper.
> 
> I do not know where to start debugging.
> Can any one tell me what could be the
> problem when the cache is turned on.

That CPU and coprocessor are/were supported in 2.4 so
in general, the kernel "should" run. If you have
access to an off the shelf reference board with that
CPU and system processor, start there and see if the
kernel runs on that board. If it does not, you may be
looking at a kernel issue. If the kernel runs on the
reference board, then your issue is most likely a
hardware problem with your board. If you don't have
access to a reference board, then you'll be trying to
figure out if this is a hardware or kernel problem.
I'm guessing it's hardware but hopefully not. Hook in
kgdb and try to reproduce the problem with the most
simple test you can find that causes the crash.
Examine the point of failure and try to make sense of
it to figure out if it's kernel or hardware related.
Of course I assume you've already ran at least basic
memory tests on the board and that much passes. If
not, then start there.

Pete

From jh@hansen-telecom.dk Wed Dec 29 09:29:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Dec 2004 09:29:55 +0000 (GMT)
Received: from mailfe10.tele2.se ([IPv6:::ffff:212.247.155.33]:44489 "EHLO
	mailfe10.swip.net") by linux-mips.org with ESMTP
	id <S8224905AbUL2J3u>; Wed, 29 Dec 2004 09:29:50 +0000
X-T2-Posting-ID: mMjmbctcQvUxfg/nCOwd8A==
Received: from [83.72.98.85] (HELO ANNEMETTE)
  by mailfe10.swip.net (CommuniGate Pro SMTP 4.2.7)
  with ESMTP id 51742562 for linux-mips@linux-mips.org; Wed, 29 Dec 2004 10:28:47 +0100
From: =?iso-8859-1?Q?J=F8rg_Ulrich_Hansen?= <jh@hansen-telecom.dk>
To: <linux-mips@linux-mips.org>
Subject: Request for new machtype
Date: Wed, 29 Dec 2004 10:29:46 +0100
Message-ID: <000201c4ed88$efdc64b0$040ba8c0@ANNEMETTE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Return-Path: <jh@hansen-telecom.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: 6789
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jh@hansen-telecom.dk
Precedence: bulk
X-list: linux-mips

Hi

We are the manufacture of a cpu module based on ADMs Alchemy au1100 and
would like a machtype as defined in bootinfo.h

I have included a patch that defines MACH_MB1100 as 9 but would like to
have it confirm so we are not running into conflicts in the future.

Index: linux267/include/asm-mips/bootinfo.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/bootinfo.h,v
retrieving revision 1.74
diff -u -p -r1.74 bootinfo.h
--- linux267/include/asm-mips/bootinfo.h	13 Apr 2004 22:07:45
-0000	1.74
+++ linux267/include/asm-mips/bootinfo.h	27 Nov 2004 16:20:31
-0000
@@ -174,6 +174,7 @@
 #define  MACH_XXS1500		6       /* Au1500-based eval board */
 #define  MACH_MTX1		7       /* 4G MTX-1 Au1500-based board
*/
 #define  MACH_PB1550		8       /* Au1550-based eval board */
+#define  MACH_MB1100		9   /* Mechatronic Brick mb1100 module
*/
 
 /*
  * Valid machtype for group NEC_VR41XX 

Kind regards Jorg Hansen

This is not advertising but more information about the module as well as
crosstool based on buildroot and patches can be found at:
http://www.mechatronicbrick.dk/uk/mb1100.html


 


From ppopov@embeddedalley.com Fri Dec 31 00:04:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Dec 2004 00:04:16 +0000 (GMT)
Received: from web201.biz.mail.re2.yahoo.com ([IPv6:::ffff:68.142.224.163]:54938
	"HELO web201.biz.mail.re2.yahoo.com") by linux-mips.org with SMTP
	id <S8225230AbULaAEK>; Fri, 31 Dec 2004 00:04:10 +0000
Message-ID: <20041231000354.53760.qmail@web201.biz.mail.re2.yahoo.com>
Received: from [64.164.196.27] by web201.biz.mail.re2.yahoo.com via HTTP; Thu, 30 Dec 2004 16:03:54 PST
Date: Thu, 30 Dec 2004 16:03:54 -0800 (PST)
From: Peter Popov <ppopov@embeddedalley.com>
Subject: Re: Request for new machtype
To: =?ISO-8859-1?Q?"J=F8rg"?= Ulrich Hansen <jh@hansen-telecom.dk>,
	linux-mips@linux-mips.org
In-Reply-To: <000201c4ed88$efdc64b0$040ba8c0@ANNEMETTE>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <ppopov@embeddedalley.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: 6790
X-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@embeddedalley.com
Precedence: bulk
X-list: linux-mips


I'll take care of it.

Pete

--- Jørg Ulrich Hansen <jh@hansen-telecom.dk> wrote:

> Hi
> 
> We are the manufacture of a cpu module based on ADMs
> Alchemy au1100 and
> would like a machtype as defined in bootinfo.h
> 
> I have included a patch that defines MACH_MB1100 as
> 9 but would like to
> have it confirm so we are not running into conflicts
> in the future.
> 
> Index: linux267/include/asm-mips/bootinfo.h
>
===================================================================
> RCS file:
> /home/cvs/linux/include/asm-mips/bootinfo.h,v
> retrieving revision 1.74
> diff -u -p -r1.74 bootinfo.h
> --- linux267/include/asm-mips/bootinfo.h	13 Apr 2004
> 22:07:45
> -0000	1.74
> +++ linux267/include/asm-mips/bootinfo.h	27 Nov 2004
> 16:20:31
> -0000
> @@ -174,6 +174,7 @@
>  #define  MACH_XXS1500		6       /* Au1500-based eval
> board */
>  #define  MACH_MTX1		7       /* 4G MTX-1
> Au1500-based board
> */
>  #define  MACH_PB1550		8       /* Au1550-based eval
> board */
> +#define  MACH_MB1100		9   /* Mechatronic Brick
> mb1100 module
> */
>  
>  /*
>   * Valid machtype for group NEC_VR41XX 
> 
> Kind regards Jorg Hansen
> 
> This is not advertising but more information about
> the module as well as
> crosstool based on buildroot and patches can be
> found at:
> http://www.mechatronicbrick.dk/uk/mb1100.html
> 
> 
>  
> 
> 
> 


From pf@net.alphadv.de Fri Dec 31 01:11:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Dec 2004 01:11:59 +0000 (GMT)
Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:31492 "EHLO
	mail.alphastar.de") by linux-mips.org with ESMTP
	id <S8225230AbULaBLy>; Fri, 31 Dec 2004 01:11:54 +0000
Received: from SNaIlmail.Peter (217.249.217.132)
          by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==)
          for <linux-mips@linux-mips.org>; Fri, 31 Dec 2004 02:09:52 +0100
Received: from Indigo2.Peter (Indigo2.Peter [192.168.1.28])
	by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id iBV18ZGQ000482
	for <linux-mips@linux-mips.org>; Fri, 31 Dec 2004 02:08:35 +0100
Received: from pf (helo=localhost)
	by Indigo2.Peter with local-esmtp (Exim 3.35 #1 (Debian))
	id 1CkBFq-00007R-00
	for <linux-mips@linux-mips.org>; Fri, 31 Dec 2004 02:06:58 +0100
Date: Fri, 31 Dec 2004 02:06:02 +0100 (CET)
From: Peter Fuerst <pf@Indigo2.Peter>
To: linux-mips@linux-mips.org
Subject: Confused assembler
In-Reply-To: <20041227124435.GC26100@linux-mips.org>
Message-ID: <Pine.LNX.4.58.0412310201350.455@Indigo2.Peter>
References: <20041225172449.1063A1F123@trashy.coderock.org>
 <20041227124435.GC26100@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: pf@net.alphadv.de
Return-Path: <pf@net.alphadv.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: 6791
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pf@Indigo2.Peter
Precedence: bulk
X-list: linux-mips



Hello !


When building 2.6.10, the assembler (2.13.2.1) gets confused by a "b target2"
(compiler generated) immediately following a "beqzl target1" (inline assembly
macro), and reorders these instructions (with wrong address calculation too)
to an infinite loop.
(Well, not really infinite - after about ten minutes some timer interrupt
makes an end to it by a null-pointer dereference in __queue_work()  ;-)
This bug is rather unreliable though, going away with minimal, unintentional
code changes, unexpectedly reappearing after some later rebuild...

Was this behaviour already observed elsewhere ?  Is it fixed in some newer
assembler version ?  Or should i just be content with it and work around
with appropriate "nop"s in the concerned inline-assembly macros ? ... ?



as -EB -G 0 -mips4 -O2 -g0 -64 -mcpu=r8000 -v -64 -non_shared -64 -march=r8000 -mips4 --trap -o kernel/.tmp_fork.o
GNU assembler version 2.13.2.1 (mips64-ip28-linux-gnu) using BFD version 2.13.2.1
GNU assembler version 2.13.2.1 (mips64-linux) using BFD version 2.13.2.1

Here are examples of what the assembler receives from the compiler,
and what it produces:

a80000002003a6c0 <copy_process>:
...

	.set	macro
	.set	reorder
	cache 0x14,0($sp)	# Cache Barrier
 #APP
	1:	lld	$3, 256($4)	# atomic64_add
	addu	$3, $2
	scd	$3, 256($4)
	beqzl	$3, 1b
 #NO_APP
	b	$L5881
$L5887:
	 # Cache Barrier omitted.
	move	$5,$0
$L5881:
	...
a80000002003a944:	bfb40000 	cache	0x14,0(sp)
a80000002003a948:	d0830100 	lld	v1,256(a0)
a80000002003a94c:	00621821 	addu	v1,v1,v0
a80000002003a950:	f0830100 	scd	v1,256(a0)
a80000002003a954 <!>:	1000ffff 	b	a80000002003a954 <$L6939+0xe4>
a80000002003a958:	00000000 	nop
a80000002003a95c:	50600000 	beqzl	v1,a80000002003a960 <$L5887>
a80000002003a960 <$L5887>:
a80000002003a960:	0000282d 	move	a1,zero
a80000002003a964 <$L5881>:
...

 #APP
	1:	ll	$5, 0($2)	# atomic_add
	addu	$5, $3
	sc	$5, 0($2)
	beqzl	$5, 1b
 #NO_APP
	b	$L6092
$L6057:
	...
$L6092:
	...
a80000002003abe4:	c0450000 	ll	a1,0(v0)
a80000002003abe8 <!>:	00a32821 	addu	a1,a1,v1
a80000002003abec:	e0450000 	sc	a1,0(v0)
a80000002003abf0:	1000fffd 	b	a80000002003abe8 <$L6045+0x70>
a80000002003abf4:	00000000 	nop
a80000002003abf8:	50a00000 	beqzl	a1,a80000002003abfc <$L6057>
a80000002003abfc <$L6057>:
...

 #APP
	1:	ll	$5, 4($2)	# atomic_add
	addu	$5, $3
	sc	$5, 4($2)
	beqzl	$5, 1b
 #NO_APP
	b	$L6480
$L6411:
	...
$L6480:
	...
a80000002003aedc:	c0450004 	ll	a1,4(v0)
a80000002003aee0:	00a32821 	addu	a1,a1,v1
a80000002003aee4 <!>:	e0450004 	sc	a1,4(v0)
a80000002003aee8:	1000fffe 	b	a80000002003aee4 <$L6401+0x54>
a80000002003aeec:	00000000 	nop
a80000002003aef0:	50a00000 	beqzl	a1,a80000002003aef4 <$L6411>
a80000002003aef4 <$L6411>:
...


with kind regards

pf

From hvr@inso.tuwien.ac.at Fri Dec 31 11:13:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Dec 2004 11:13:57 +0000 (GMT)
Received: from dhcp-1285-65.blizz.at ([IPv6:::ffff:213.143.126.4]:31388 "EHLO
	cervus.intra") by linux-mips.org with ESMTP id <S8225011AbULaLNu>;
	Fri, 31 Dec 2004 11:13:50 +0000
Received: from xterm.intra ([10.49.1.10])
	by cervus.intra with esmtp (Exim 4.34)
	id 1CkKit-0000wa-UH; Fri, 31 Dec 2004 12:13:35 +0100
Subject: [PATCH] au1000_eth fixes/improvemetns for 2.6.x
From: Herbert Valerio Riedel <hvr@inso.tuwien.ac.at>
To: Pete Popov <ppopov@embeddedalley.com>
Cc: linux-mips@linux-mips.org
Content-Type: multipart/mixed; boundary="=-SbjMchTOA+UP6PYTb4TX"
Organization: Research Group for Industrial Software @ Vienna University of
	Technology
Date: Fri, 31 Dec 2004 12:13:33 +0100
Message-Id: <1104491614.9902.11.camel@xterm.intra>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 
Return-Path: <hvr@inso.tuwien.ac.at>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6792
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hvr@inso.tuwien.ac.at
Precedence: bulk
X-list: linux-mips


--=-SbjMchTOA+UP6PYTb4TX
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

the following patch 

*) removes 'inline' for 'extern' declarations

*) fixes some nasty buffer overflow due to 
 sizeof (dev->dev_addr) > sizeof(au1000_mac_addr)' at least in 2.6.x

*) removes some unused symbols

*) generates random "local assigned" mac addresses instead of using the
hardcoded one

*) prints out the finally selected mac address on initialization

*) marks a few structs 'const'

*) doesn't segfault when no MII is detected...

regards,
-- 
Herbert Valerio Riedel <hvr@inso.tuwien.ac.at>
Research Group for Industrial Software @ Vienna University of Technology

--=-SbjMchTOA+UP6PYTb4TX
Content-Disposition: attachment; filename=au1000_eth.patch
Content-Type: text/x-patch; name=au1000_eth.patch; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Index: au1000_eth.c
===================================================================
RCS file: /home/cvs/linux/drivers/net/au1000_eth.c,v
retrieving revision 1.39
diff -u -u -r1.39 au1000_eth.c
--- au1000_eth.c	26 Nov 2004 08:45:17 -0000	1.39
+++ au1000_eth.c	31 Dec 2004 11:12:00 -0000
@@ -95,11 +95,9 @@
 static void dump_mii(struct net_device *dev, int phy_id);
 
 // externs
-extern  void ack_rise_edge_irq(unsigned int);
 extern int get_ethernet_addr(char *ethernet_addr);
-extern inline void str2eaddr(unsigned char *ea, unsigned char *str);
-extern inline unsigned char str2hexnum(unsigned char c);
-extern char * __init prom_getcmdline(void);
+extern void str2eaddr(unsigned char *ea, unsigned char *str);
+extern char *__init prom_getcmdline(void);
 
 /*
  * Theory of operation
@@ -120,7 +118,7 @@
  * the mac address is, and the mac address is not passed on the
  * command line.
  */
-static unsigned char au1000_mac_addr[6] __devinitdata = { 
+static unsigned char au1000_mac_addr[ETH_ALEN] __devinitdata = { 
 	0x00, 0x50, 0xc2, 0x0c, 0x30, 0x00
 };
 
@@ -131,7 +129,7 @@
 #define cpu_to_dma32 cpu_to_be32
 #define dma32_to_cpu be32_to_cpu
 
-struct au1000_private *au_macs[NUM_ETH_INTERFACES];
+static struct au1000_private *au_macs[NUM_ETH_INTERFACES];
 
 /* FIXME 
  * All of the PHY code really should be detached from the MAC 
@@ -149,13 +147,6 @@
 	SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | \
 	SUPPORTED_Autoneg
 
-static char *phy_link[] = 
-{	"unknown", 
-	"10Base2", "10BaseT", 
-	"AUI",
-	"100BaseT", "100BaseTX", "100BaseFX"
-};
-
 int bcm_5201_init(struct net_device *dev, int phy_addr)
 {
 	s16 data;
@@ -723,61 +714,61 @@
 }
 #endif
 
-struct phy_ops bcm_5201_ops = {
+const struct phy_ops bcm_5201_ops = {
 	bcm_5201_init,
 	bcm_5201_reset,
 	bcm_5201_status,
 };
 
-struct phy_ops am79c874_ops = {
+const struct phy_ops am79c874_ops = {
 	am79c874_init,
 	am79c874_reset,
 	am79c874_status,
 };
 
-struct phy_ops am79c901_ops = {
+const struct phy_ops am79c901_ops = {
 	am79c901_init,
 	am79c901_reset,
 	am79c901_status,
 };
 
-struct phy_ops lsi_80227_ops = { 
+const struct phy_ops lsi_80227_ops = { 
 	lsi_80227_init,
 	lsi_80227_reset,
 	lsi_80227_status,
 };
 
-struct phy_ops lxt971a_ops = { 
+const struct phy_ops lxt971a_ops = { 
 	lxt971a_init,
 	lxt971a_reset,
 	lxt971a_status,
 };
 
-struct phy_ops ks8995m_ops = {
+const struct phy_ops ks8995m_ops = {
 	ks8995m_init,
 	ks8995m_reset,
 	ks8995m_status,
 };
 
-struct phy_ops smsc_83C185_ops = {
+const struct phy_ops smsc_83C185_ops = {
 	smsc_83C185_init,
 	smsc_83C185_reset,
 	smsc_83C185_status,
 };
 
 #ifdef CONFIG_MIPS_BOSPORUS
-struct phy_ops stub_ops = {
+const struct phy_ops stub_ops = {
 	stub_init,
 	stub_reset,
 	stub_status,
 };
 #endif
 
-static struct mii_chip_info {
+const static struct mii_chip_info {
 	const char * name;
 	u16 phy_id0;
 	u16 phy_id1;
-	struct phy_ops *phy_ops;	
+	const struct phy_ops *phy_ops;	
 	int dual_phy;
 } mii_chip_table[] = {
 	{"Broadcom BCM5201 10/100 BaseT PHY",0x0040,0x6212, &bcm_5201_ops,0},
@@ -983,6 +974,10 @@
 			}
 		}
 	}
+
+	/* PHY not found */
+	printk(KERN_ERR "%s: Au1x No MII transceivers found!\n", dev->name);
+	return -1;
 found:
 
 #ifdef CONFIG_MIPS_BOSPORUS
@@ -1448,7 +1443,6 @@
 	struct net_device *dev = NULL;
 	db_dest_t *pDB, *pDBfree;
 	char *pmac, *argptr;
-	char ethaddr[6];
 	int i, err;
 
 	if (!request_mem_region(CPHYSADDR(ioaddr), MAC_IOSIZE, "Au1x00 ENET"))
@@ -1470,8 +1464,7 @@
 		return NULL;
 	}
 
-	printk("%s: Au1x Ethernet found at 0x%x, irq %d\n", 
-			dev->name, ioaddr, irq);
+	printk("%s: Au1x Ethernet found at 0x%x, irq %d\n", dev->name, ioaddr, irq);
 
 	aup = dev->priv;
 
@@ -1492,25 +1485,25 @@
 	/* Setup some variables for quick register address access */
 	if (ioaddr == iflist[0].base_addr)
 	{
+		char ethaddr[ETH_ALEN];
+
 		/* check env variables first */
 		if (!get_ethernet_addr(ethaddr)) { 
-			memcpy(au1000_mac_addr, ethaddr, sizeof(dev->dev_addr));
+			memcpy(au1000_mac_addr, ethaddr, ETH_ALEN);
 		} else {
 			/* Check command line */
 			argptr = prom_getcmdline();
 			if ((pmac = strstr(argptr, "ethaddr=")) == NULL) {
-				printk(KERN_INFO "%s: No mac address found\n", 
-						dev->name);
-				/* use the hard coded mac addresses */
+				printk(KERN_INFO "%s: No mac address found, generating random local assigned address\n", 
+				       dev->name);
+				random_ether_addr (au1000_mac_addr);
 			} else {
 				str2eaddr(ethaddr, pmac + strlen("ethaddr="));
-				memcpy(au1000_mac_addr, ethaddr, 
-						sizeof(dev->dev_addr));
+				memcpy(au1000_mac_addr, ethaddr, ETH_ALEN);
 			}
 		}
-			aup->enable = (volatile u32 *) 
-				((unsigned long)iflist[0].macen_addr);
-		memcpy(dev->dev_addr, au1000_mac_addr, sizeof(dev->dev_addr));
+		aup->enable = (volatile u32 *)((unsigned long)iflist[0].macen_addr);
+		memcpy(dev->dev_addr, au1000_mac_addr, ETH_ALEN);
 		setup_hw_rings(aup, MAC0_RX_DMA_ADDR, MAC0_TX_DMA_ADDR);
 		aup->mac_id = 0;
 		au_macs[0] = aup;
@@ -1518,10 +1511,9 @@
 		else
 	if (ioaddr == iflist[1].base_addr)
 	{
-			aup->enable = (volatile u32 *) 
-				((unsigned long)iflist[1].macen_addr);
-		memcpy(dev->dev_addr, au1000_mac_addr, sizeof(dev->dev_addr));
-		dev->dev_addr[4] += 0x10;
+		aup->enable = (volatile u32 *)((unsigned long)iflist[1].macen_addr);
+		memcpy(dev->dev_addr, au1000_mac_addr, ETH_ALEN);
+		dev->dev_addr[5] += 0x01;
 		setup_hw_rings(aup, MAC1_RX_DMA_ADDR, MAC1_TX_DMA_ADDR);
 		aup->mac_id = 1;
 		au_macs[1] = aup;
@@ -1531,6 +1523,11 @@
 		printk(KERN_ERR "%s: bad ioaddr\n", dev->name);
 	}
 
+	printk (KERN_INFO "%s: Using mac address ", dev->name);
+	for (i = 0; i < 5; i++)
+		printk("%2.2x:", dev->dev_addr[i]);
+	printk ("%2.2x\n", dev->dev_addr[i]);
+
 	/* bring the device out of reset, otherwise probing the mii
 	 * will hang */
 	*aup->enable = MAC_EN_CLOCK_ENABLE;
Index: au1000_eth.h
===================================================================
RCS file: /home/cvs/linux/drivers/net/au1000_eth.h,v
retrieving revision 1.10
diff -u -u -r1.10 au1000_eth.h
--- au1000_eth.h	18 Sep 2004 23:16:01 -0000	1.10
+++ au1000_eth.h	31 Dec 2004 11:12:00 -0000
@@ -142,7 +142,7 @@
 
 typedef struct mii_phy {
 	struct mii_phy * next;
-	struct mii_chip_info * chip_info;
+	const struct mii_chip_info * chip_info;
 	u16 status;
 	u32 *mii_control_reg;
 	u32 *mii_data_reg;
@@ -200,7 +200,6 @@
 
 
 struct au1000_private {
-	
 	db_dest_t *pDBfree;
 	db_dest_t db[NUM_RX_BUFFS+NUM_TX_BUFFS];
 	volatile rx_dma_t *rx_dma_ring[NUM_RX_DMA];
@@ -214,7 +213,7 @@
 
 	int mac_id;
 	mii_phy_t *mii;
-	struct phy_ops *phy_ops;
+	const struct phy_ops *phy_ops;
 	
 	/* These variables are just for quick access to certain regs addresses. */
 	volatile mac_reg_t *mac;  /* mac registers                      */   

--=-SbjMchTOA+UP6PYTb4TX--


From mudeem@Quartics.com Fri Dec 31 11:42:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Dec 2004 11:42:36 +0000 (GMT)
Received: from host181-209-dsl.dols.net.pk ([IPv6:::ffff:202.147.181.209]:34698
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225011AbULaLmb>; Fri, 31 Dec 2004 11:42:31 +0000
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2448.0)
	id <ZYJ9722X>; Fri, 31 Dec 2004 16:32:45 +0500
Message-ID: <1B701004057AF74FAFF851560087B161064698@1aurora.enabtech>
From: Mudeem Iqbal <mudeem@Quartics.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: cross compiling gcc for mips
Date: Fri, 31 Dec 2004 16:32:44 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <mudeem@Quartics.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: 6793
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mudeem@Quartics.com
Precedence: bulk
X-list: linux-mips

Hi,

I am building a toolchain for mips platform. I am using

binutils-2.15
gcc-3.4.3
glibc-2.3.3
linux-2.6.9	(from linux-mips.org)

First I built binutils and now I was setting up the bootstrap compiler.
However when I do "make all-gcc" I get the following errors.


In file included from ./gthr-default.h:1,
                 from ../../gcc-3.4.3/gcc/gthr.h:96,
                 from ../../gcc-3.4.3/gcc/unwind-dw2.c:42:
../../gcc-3.4.3/gcc/gthr-posix.h:43:21: pthread.h: No such file or directory
../../gcc-3.4.3/gcc/gthr-posix.h:44:20: unistd.h: No such file or directory
In file included from ./gthr-default.h:1,
                 from ../../gcc-3.4.3/gcc/gthr.h:96,
                 from ../../gcc-3.4.3/gcc/unwind-dw2.c:42:
../../gcc-3.4.3/gcc/gthr-posix.h:46: error: parse error before
"__gthread_key_t"
../../gcc-3.4.3/gcc/gthr-posix.h:46: warning: type defaults to `int' in
declaration of `__gthread_key_t'
../../gcc-3.4.3/gcc/gthr-posix.h:46: warning: data definition has no type or
storage class
../../gcc-3.4.3/gcc/gthr-posix.h:47: error: parse error before
"__gthread_once_t"
../../gcc-3.4.3/gcc/gthr-posix.h:47: warning: type defaults to `int' in
declaration of `__gthread_once_t'
../../gcc-3.4.3/gcc/gthr-posix.h:47: warning: data definition has no type or
storage class
../../gcc-3.4.3/gcc/gthr-posix.h:48: error: parse error before
"__gthread_mutex_t"
../../gcc-3.4.3/gcc/gthr-posix.h:48: warning: type defaults to `int' in
declaration of `__gthread_mutex_t'
../../gcc-3.4.3/gcc/gthr-posix.h:48: warning: data definition has no type or
storage class
../../gcc-3.4.3/gcc/gthr-posix.h: In function `__gthread_active_p':
../../gcc-3.4.3/gcc/gthr-posix.h:96: error: `pthread_create' undeclared
(first use in this function)
../../gcc-3.4.3/gcc/gthr-posix.h:96: error: (Each undeclared identifier is
reported only once
../../gcc-3.4.3/gcc/gthr-posix.h:96: error: for each function it appears
in.)
../../gcc-3.4.3/gcc/gthr-posix.h: At top level:
../../gcc-3.4.3/gcc/gthr-posix.h:456: error: parse error before '*' token
../../gcc-3.4.3/gcc/gthr-posix.h:456: error: parse error before ')' token
../../gcc-3.4.3/gcc/gthr-posix.h:465: error: parse error before '*' token
../../gcc-3.4.3/gcc/gthr-posix.h:465: error: parse error before ')' token
../../gcc-3.4.3/gcc/gthr-posix.h:471: error: parse error before "key"
../../gcc-3.4.3/gcc/gthr-posix.h:472: warning: function declaration isn't a
prototype
../../gcc-3.4.3/gcc/gthr-posix.h: In function `__gthread_key_delete':
../../gcc-3.4.3/gcc/gthr-posix.h:472: warning: old-style parameter
declaration
../../gcc-3.4.3/gcc/gthr-posix.h:473: warning: implicit declaration of
function `pthread_key_delete'
../../gcc-3.4.3/gcc/gthr-posix.h:473: error: `key' undeclared (first use in
this function)
../../gcc-3.4.3/gcc/gthr-posix.h: At top level:
../../gcc-3.4.3/gcc/gthr-posix.h:477: error: parse error before "key"
../../gcc-3.4.3/gcc/gthr-posix.h:478: warning: function declaration isn't a
prototype
../../gcc-3.4.3/gcc/gthr-posix.h: In function `__gthread_getspecific':
../../gcc-3.4.3/gcc/gthr-posix.h:478: warning: old-style parameter
declaration
../../gcc-3.4.3/gcc/gthr-posix.h:479: warning: implicit declaration of
function `pthread_getspecific'
../../gcc-3.4.3/gcc/gthr-posix.h:479: error: `key' undeclared (first use in
this function)
../../gcc-3.4.3/gcc/gthr-posix.h:479: warning: return makes pointer from
integer without a cast
../../gcc-3.4.3/gcc/gthr-posix.h: At top level:
../../gcc-3.4.3/gcc/gthr-posix.h:483: error: parse error before "key"
../../gcc-3.4.3/gcc/gthr-posix.h:484: warning: function declaration isn't a
prototype
../../gcc-3.4.3/gcc/gthr-posix.h: In function `__gthread_setspecific':
../../gcc-3.4.3/gcc/gthr-posix.h:484: warning: old-style parameter
declaration
../../gcc-3.4.3/gcc/gthr-posix.h:485: warning: implicit declaration of
function `pthread_setspecific'
../../gcc-3.4.3/gcc/gthr-posix.h:485: error: `key' undeclared (first use in
this function)
../../gcc-3.4.3/gcc/gthr-posix.h:485: error: `ptr' undeclared (first use in
this function)
../../gcc-3.4.3/gcc/gthr-posix.h: At top level:
../../gcc-3.4.3/gcc/gthr-posix.h:489: error: parse error before '*' token
../../gcc-3.4.3/gcc/gthr-posix.h:490: warning: function declaration isn't a
prototype
../../gcc-3.4.3/gcc/gthr-posix.h: In function `__gthread_mutex_lock':
../../gcc-3.4.3/gcc/gthr-posix.h:490: warning: old-style parameter
declaration
../../gcc-3.4.3/gcc/gthr-posix.h:492: warning: implicit declaration of
function `pthread_mutex_lock'
../../gcc-3.4.3/gcc/gthr-posix.h:492: error: `mutex' undeclared (first use
in this function)
../../gcc-3.4.3/gcc/gthr-posix.h: At top level:
../../gcc-3.4.3/gcc/gthr-posix.h:498: error: parse error before '*' token
../../gcc-3.4.3/gcc/gthr-posix.h:499: warning: function declaration isn't a
prototype
../../gcc-3.4.3/gcc/gthr-posix.h: In function `__gthread_mutex_trylock':
../../gcc-3.4.3/gcc/gthr-posix.h:499: warning: old-style parameter
declaration
../../gcc-3.4.3/gcc/gthr-posix.h:501: warning: implicit declaration of
function `pthread_mutex_trylock'
../../gcc-3.4.3/gcc/gthr-posix.h:501: error: `mutex' undeclared (first use
in this function)
../../gcc-3.4.3/gcc/gthr-posix.h: At top level:
../../gcc-3.4.3/gcc/gthr-posix.h:507: error: parse error before '*' token
../../gcc-3.4.3/gcc/gthr-posix.h:508: warning: function declaration isn't a
prototype
../../gcc-3.4.3/gcc/gthr-posix.h: In function `__gthread_mutex_unlock':
../../gcc-3.4.3/gcc/gthr-posix.h:508: warning: old-style parameter
declaration
../../gcc-3.4.3/gcc/gthr-posix.h:510: warning: implicit declaration of
function `pthread_mutex_unlock'
../../gcc-3.4.3/gcc/gthr-posix.h:510: error: `mutex' undeclared (first use
in this function)
../../gcc-3.4.3/gcc/unwind-dw2.c: In function `uw_frame_state_for':
../../gcc-3.4.3/gcc/unwind-dw2.c:1013: warning: implicit declaration of
function `memset'
../../gcc-3.4.3/gcc/unwind-dw2.c: In function `uw_init_context_1':
../../gcc-3.4.3/gcc/unwind-dw2.c:1291: error: syntax error before
"once_regsizes"
../../gcc-3.4.3/gcc/unwind-dw2.c:1292: warning: implicit declaration of
function `__gthread_once'
../../gcc-3.4.3/gcc/unwind-dw2.c:1292: error: `once_regsizes' undeclared
(first use in this function)
../../gcc-3.4.3/gcc/unwind-dw2.c: In function `uw_install_context_1':
../../gcc-3.4.3/gcc/unwind-dw2.c:1341: warning: implicit declaration of
function `memcpy'
make[2]: *** [libgcc/./unwind-dw2.o] Error 1
make[2]: Leaving directory
`/home/mudeem/ashwaria_rai/build-tools/build-boot-gcc/gcc'
make[1]: *** [libgcc.a] Error 2
make[1]: Leaving directory
`/home/mudeem/ashwaria_rai/build-tools/build-boot-gcc/gcc'
make: *** [all-gcc] Error 2


Thanx in advance.

Regards

Mudeem


From ica2_ts@csv.ica.uni-stuttgart.de Fri Dec 31 16:30:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Dec 2004 16:30:29 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:46418
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225296AbULaQaW>; Fri, 31 Dec 2004 16:30:22 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1CkPfG-0005MQ-00; Fri, 31 Dec 2004 17:30:10 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1CkPfF-0001tX-00; Fri, 31 Dec 2004 17:30:09 +0100
Date: Fri, 31 Dec 2004 17:30:09 +0100
To: pf@net.alphadv.de
Cc: linux-mips@linux-mips.org
Subject: Re: Confused assembler
Message-ID: <20041231163009.GB6495@rembrandt.csv.ica.uni-stuttgart.de>
References: <20041225172449.1063A1F123@trashy.coderock.org> <20041227124435.GC26100@linux-mips.org> <Pine.LNX.4.58.0412310201350.455@Indigo2.Peter>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58.0412310201350.455@Indigo2.Peter>
User-Agent: Mutt/1.5.6+20040907i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 6794
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Peter Fuerst wrote:
> 
> 
> Hello !
> 
> 
> When building 2.6.10, the assembler (2.13.2.1) gets confused by a "b target2"
> (compiler generated) immediately following a "beqzl target1" (inline assembly
> macro), and reorders these instructions (with wrong address calculation too)
> to an infinite loop.
[snip]
> Was this behaviour already observed elsewhere ?  Is it fixed in some newer
> assembler version ?

Fixed in current binutils CVS, IIRC both 2.15 branch and trunk. The
older binutils tarball at linux-mips.org was also fixed.

> Or should i just be content with it and work around
> with appropriate "nop"s in the concerned inline-assembly macros ? ... ?

You should upgrade to something newer than 2.13. :-)

> as -EB -G 0 -mips4 -O2 -g0 -64 -mcpu=r8000 -v -64 -non_shared -64 -march=r8000 -mips4 --trap -o kernel/.tmp_fork.o

Note that those arguments are partially contradicting each other.

-mips4 -64 -mcpu=r8000 -64 -64 -march=r8000 -mips4

is (with 2.15 gas) better expressed as

-mabi=64 -march=mips4

or, more suitable for r10000, with

-mabi=64 -march=r10000


Thiemo