From rsandifo@redhat.com Wed Sep  1 09:51:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Sep 2004 09:51:54 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:26817 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224845AbUIAIvt>;
	Wed, 1 Sep 2004 09:51:49 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i818pgS0011466;
	Wed, 1 Sep 2004 04:51:47 -0400
Received: from localhost (mail@vpn50-67.rdu.redhat.com [172.16.50.67])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i818pP318234;
	Wed, 1 Sep 2004 04:51:27 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1C2Qpo-0001Bk-00; Wed, 01 Sep 2004 09:51:16 +0100
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: gcc 3.3.4/3.4.1 and get_user
References: <20040901.012223.59462025.anemo@mba.ocn.ne.jp>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Wed, 01 Sep 2004 09:51:16 +0100
In-Reply-To: <20040901.012223.59462025.anemo@mba.ocn.ne.jp> (Atsushi
 Nemoto's message of "Wed, 01 Sep 2004 01:22:23 +0900 (JST)")
Message-ID: <87656yqsmz.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: 5755
X-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

Atsushi Nemoto <anemo@mba.ocn.ne.jp> writes:
> Is this a get_user's problem or gcc's?

The latter.  gcc is putting the empty asm:

	__asm__ ("":"=r" (__gu_val));

into the delay slot of the call.

Part of the problem is that gcc estimates the length of an asm to be the
number of instruction separators + 1.  This means that it estimates the
asm above to be one instruction long, which is perhaps a little silly
for an empty string.

But the real problem is that gcc should never trust this estimate anyway,
since each "instruction" could obviously be a multi-instruction macro.
gcc should certainly never put asms into delay slots.

FWIW, I don't think the bug is specific to 3.3 or 3.4.  It could
probably trigger for other gcc versions too.  It is highly dependent
on scheduling though.

The attached 3.4.x patch fixes the problem there, but if you want to work
around it for old versions, just avoid using empty asms if you can,
or make them volatile if you can't.

Of course, the problem isn't confined to empty asms.  If you have an asm
with a single, multi-instruction macro, gcc might try putting that in a
delay slot too.  You should at least get an assembler warning in that case.

Richard


Index: config/mips/mips.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/mips/mips.md,v
retrieving revision 1.211.4.7
diff -u -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.211.4.7 mips.md
--- config/mips/mips.md	25 Jun 2004 07:35:30 -0000	1.211.4.7
+++ config/mips/mips.md	1 Sep 2004 08:26:02 -0000
@@ -251,7 +251,7 @@ (define_attr "single_insn" "no,yes"
 
 ;; Can the instruction be put into a delay slot?
 (define_attr "can_delay" "no,yes"
-  (if_then_else (and (eq_attr "type" "!branch,call,jump")
+  (if_then_else (and (eq_attr "type" "!branch,call,jump,multi")
 		     (and (eq_attr "hazard" "none")
 			  (eq_attr "single_insn" "yes")))
 		(const_string "yes")

From rsandifo@redhat.com Wed Sep  1 10:18:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Sep 2004 10:18:11 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:64720 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224845AbUIAJSG>;
	Wed, 1 Sep 2004 10:18:06 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i819I0S0019766;
	Wed, 1 Sep 2004 05:18:05 -0400
Received: from localhost (mail@vpn50-67.rdu.redhat.com [172.16.50.67])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i819Hr329256;
	Wed, 1 Sep 2004 05:17:55 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1C2RFQ-0001CU-00; Wed, 01 Sep 2004 10:17:44 +0100
To: Dominic Sweetman <dom@mips.com>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
References: <20040804152936.D6269@mvista.com>
	<16676.46694.564448.344602@arsenal.mips.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Wed, 01 Sep 2004 10:17:44 +0100
In-Reply-To: <16676.46694.564448.344602@arsenal.mips.com> (Dominic
 Sweetman's message of "Thu, 19 Aug 2004 15:17:10 +0100")
Message-ID: <87zn4apcuf.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: 5756
X-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

Dominic Sweetman <dom@mips.com> writes:
> In many ways it's easier to get away from the ingenious but
> troublesome stack-structure-based calling convention.  The "stack
> structure" trick was invented so that o32 could work without function
> prototypes - but function prototypes are now required, and something
> with fixed-size arguments is simpler.  Something like the old
> Cygnus/WRS EABI proposal, in fact...

Indeed, all of this:

> So we're proposing:
> [...]
> o Calling convention: register-, not slot-based. Each argument is
>   represented by a register value. Arguments 0-7 travel in registers
>   a0-7 (or fa0-7 as required for floating point types). If there are
>   more than eight arguments, further ones are formed as if put in a
>   register and then saved on the stack into a 64-bit slot (more than 8
>   arguments is rare enough that we can afford to standardise on the
>   big slots).
>   
> o Use floating point registers for double and float arguments, and
>   integer registers for all integer/pointer values which will
>   fit. Larger or structured data items are implicitly passed by
>   reference: to maintain pass-by-value semantics, the compiler uses a
>   copy-on-write trick if software writes a by-reference argument (or
>   takes its address).  I'm told gcc is happy enough to do that.
>
> o The return value comes back in two registers, with the second
>   return-register used only when the return value consists of two
>   scalars (ie a complex or double-precision number). [Folklore insists
>   this is essential for Fortran support of complex numbers, and I
>   don't want to fight folklore].
>
>   All other non-scalar return values are returned via a pointer
>   specified by the caller as an implicit first argument.
>
> o Reserved registers: all the traditional ones. But now:
>
>   - gp will be the GOT pointer in Linux, and should be defined as
>     saved (ie a function must preserve values in this registers, which
>     means it will need to save-and-restore the register if it is
>     written locally).

...are pretty much what we already do for EABI.  There's some fuzziness
in what EABI considers to be "double and float arguments": things like
"struct { float f; }" are passed in the same way as scalar floats, for
example.  Complex integers are also returned by invisible reference
rather than in two GPRs.  But these are very much corner cases.

Rather than define new, slightly different, conventions, have you thought
about defining this new ABI as an extension of EABI?  I.e. taking EABI,
adding n32/n64-style PIC, and the all-important:

>   - we'll define some other register as a per-thread data pointer.

Richard

From p2@mind.be Wed Sep  1 10:40:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Sep 2004 10:40:11 +0100 (BST)
Received: from NAT.office.mind.be ([IPv6:::ffff:62.166.230.82]:14507 "EHLO
	nat.office.mind.be") by linux-mips.org with ESMTP
	id <S8224845AbUIAJkH>; Wed, 1 Sep 2004 10:40:07 +0100
Received: from p2 by codecarver with local (Exim 3.36 #1 (Debian))
	id 1C2Rb4-00047d-00
	for <linux-mips@linux-mips.org>; Wed, 01 Sep 2004 11:40:06 +0200
Date: Wed, 1 Sep 2004 11:40:06 +0200
To: linux-mips@linux-mips.org
Subject: gadget driver for Au1500
Message-ID: <20040901094005.GX2305@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="4YaMMRm3dfitt/ta"
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+20040803i
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: 5757
X-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


--4YaMMRm3dfitt/ta
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

Is there a USB gadget driver for the AMD Au1500 or is someone working on
it ?

Thanks,

Peter (p2).

--4YaMMRm3dfitt/ta
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)

iD8DBQFBNZj1KLKVw/RurbsRArp9AJ45F7r/wxgw/zmwwIXr5zuVFETxZQCgjWe2
+oQvHz4cFga4u/uRmxvXUPM=
=8nb3
-----END PGP SIGNATURE-----

--4YaMMRm3dfitt/ta--

From em@realmagic.fr Wed Sep  1 11:07:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Sep 2004 11:07:15 +0100 (BST)
Received: from cachan-9-82-229-218-57.fbx.proxad.net ([IPv6:::ffff:82.229.218.57]:25510
	"EHLO nikita.france.sdesigns.com") by linux-mips.org with ESMTP
	id <S8224845AbUIAKHL>; Wed, 1 Sep 2004 11:07:11 +0100
Received: from nikita.france.sdesigns.com (localhost.localdomain [127.0.0.1])
	by nikita.france.sdesigns.com (8.12.11/8.12.11) with ESMTP id i81A75wR026769
	for <linux-mips@linux-mips.org>; Wed, 1 Sep 2004 12:07:05 +0200
Received: (from michon@localhost)
	by nikita.france.sdesigns.com (8.12.11/8.12.11/Submit) id i81A740O026768
	for linux-mips@linux-mips.org; Wed, 1 Sep 2004 12:07:04 +0200
X-Authentication-Warning: nikita.france.sdesigns.com: michon set sender to em@realmagic.fr using -f
Subject: TLB dimensioning
From: Emmanuel Michon <em@realmagic.fr>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: REALmagic France SAS
Message-Id: <1094033224.20643.1402.camel@nikita.france.sdesigns.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Wed, 01 Sep 2004 12:07:04 +0200
Return-Path: <em@realmagic.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: 5758
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: em@realmagic.fr
Precedence: bulk
X-list: linux-mips

Hi,

regarding the hardware implementation of a 4KE (r4k style mmu
if I remember) I'm wondering about the performance difference
when the TLB has 16 pairs of entries (covering 128KBytes of
data) or 32 pairs (covering 256KBytes).

Does someone have a useful advise regarding the `nice spot'
for TLB size?

Sincerely yours,

E.M.


From xuhaoz@neonetech.com Wed Sep  1 11:08:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Sep 2004 11:08:44 +0100 (BST)
Received: from [IPv6:::ffff:211.155.249.251] ([IPv6:::ffff:211.155.249.251]:2059
	"EHLO nnt.neonetech.com") by linux-mips.org with ESMTP
	id <S8224845AbUIAKIi>; Wed, 1 Sep 2004 11:08:38 +0100
Received: from wbar1 ([221.216.152.245]) by nnt.neonetech.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 1 Sep 2004 18:12:15 +0800
Date: Wed, 1 Sep 2004 18:08:27 +0800
From: "xuhaoz" <xuhaoz@neonetech.com>
To: "linux-mips" <linux-mips@linux-mips.org>
Subject: bug in slab.c and .config
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64
Message-ID: <NNTACkWHZqYW8BYXifW000001b0@nnt.neonetech.com>
X-OriginalArrivalTime: 01 Sep 2004 10:12:15.0203 (UTC) FILETIME=[27A02330:01C4900C]
Return-Path: <xuhaoz@neonetech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5759
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: xuhaoz@neonetech.com
Precedence: bulk
X-list: linux-mips

ICBoaSBhbGw6DQoNCglyZWNlbnRseSwgaSBtZXQgYSBvZGQgcHJvYmxlbSBhbmQgaSBuZWVkIHlv
dXIgaGVscCAuDQoNCgl3aGVuIGkgcnVuICJtYWtlIG1lbnVjb25maWciICwgdGhlIHN5c3RlbSBv
dXRwdXQgYSAuY29uZmlnIGZvciBtZSAsIGl0J3MgaW1hZ2UgaXMgb2sgdG8gdXNlLiB0aGUgLmNv
bmZpZyBpcyBsaWtlIHRoaXM6IA0KDQojDQojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGJ5IG1h
a2UgbWVudWNvbmZpZzogZG9uJ3QgZWRpdA0KIw0KQ09ORklHX01JUFM9eQ0KQ09ORklHX01JUFMz
Mj15DQpDT05GSUdfVUNMSU5VWD15DQoNCiMNCiMgQ29kZSBtYXR1cml0eSBsZXZlbCBvcHRpb25z
DQojDQpDT05GSUdfRVhQRVJJTUVOVEFMPXkNCg0KIw0KIyBMb2FkYWJsZSBtb2R1bGUgc3VwcG9y
dA0KIw0KIyBDT05GSUdfTU9EVUxFUyBpcyBub3Qgc2V0DQoNCiMNCiMgTWFjaGluZSBzZWxlY3Rp
b24NCiMNCiMgQ09ORklHX1NJTVVMQVRPUiBpcyBub3Qgc2V0DQojIENPTkZJR19BQ0VSX1BJQ0Ff
NjEgaXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19QQjEwMDAgaXMgbm90IHNldA0KIyBDT05GSUdf
TUlQU19QQjE1MDAgaXMgbm90IHNldA0KIyBDT05GSUdfQUxHT1JfUDQwMzIgaXMgbm90IHNldA0K
IyBDT05GSUdfQkFHRVRfTUlQUyBpcyBub3Qgc2V0DQojIENPTkZJR19NSVBTX0NPQkFMVCBpcyBu
b3Qgc2V0DQojIENPTkZJR19ERUNTVEFUSU9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfRVY2
NDEyMCBpcyBub3Qgc2V0DQojIENPTkZJR19NSVBTX0VWOTYxMDAgaXMgbm90IHNldA0KIyBDT05G
SUdfTUlQU19JVlIgaXMgbm90IHNldA0KIyBDT05GSUdfSFBfTEFTRVJKRVQgaXMgbm90IHNldA0K
IyBDT05GSUdfTUlQU19JVEU4MTcyIGlzIG5vdCBzZXQNCkNPTkZJR19PTU5JX0JPQVJEPXkNCkNP
TkZJR19PTU5JX1RZUEUwMT15DQojIENPTkZJR19NSVBTX0FUTEFTIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01JUFNfTUFHTlVNXzQwMDAgaXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19NQUxUQSBpcyBu
b3Qgc2V0DQojIENPTkZJR19NT01FTkNPX09DRUxPVCBpcyBub3Qgc2V0DQojIENPTkZJR19EREI1
MDc0IGlzIG5vdCBzZXQNCiMgQ09ORklHX0REQjU0NzYgaXMgbm90IHNldA0KIyBDT05GSUdfRERC
NTQ3NyBpcyBub3Qgc2V0DQojIENPTkZJR19ORUNfT1NQUkVZIGlzIG5vdCBzZXQNCiMgQ09ORklH
X09MSVZFVFRJX003MDAgaXMgbm90IHNldA0KIyBDT05GSUdfTklOTyBpcyBub3Qgc2V0DQojIENP
TkZJR19TR0lfSVAyMiBpcyBub3Qgc2V0DQojIENPTkZJR19TSUJZVEVfU0IxMjUwIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NOSV9STTIwMF9QQ0kgaXMgbm90IHNldA0KIyBDT05GSUdfVE9TSElCQV9K
TVIzOTI3IGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJR0hNRU0gaXMgbm90IHNldA0KQ09ORklHX1JX
U0VNX0dFTkVSSUNfU1BJTkxPQ0s9eQ0KIyBDT05GSUdfUldTRU1fWENIR0FERF9BTEdPUklUSE0g
aXMgbm90IHNldA0KQ09ORklHX05FV19JUlE9eQ0KQ09ORklHX05FV19USU1FX0M9eQ0KIyBDT05G
SUdfTUlQU19BVTEwMDAgaXMgbm90IHNldA0KDQojDQojIENQVSBzZWxlY3Rpb24NCiMNCkNPTkZJ
R19DUFVfUjMwMDA9eQ0KIyBDT05GSUdfQ1BVX1RYMzlYWCBpcyBub3Qgc2V0DQojIENPTkZJR19D
UFVfUjYwMDAgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1ZSNDFYWCBpcyBub3Qgc2V0DQojIENP
TkZJR19DUFVfUjQzMDAgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1I0WDAwIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0NQVV9UWDQ5WFggaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1I1MDAwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0NQVV9SNTQzMiBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfUk03MDAw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9ORVZBREEgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BV
X1IxMDAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfU0IxIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0NQVV9NSVBTMzIgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX01JUFM2NCBpcyBub3Qgc2V0DQoj
IENPTkZJR19DUFVfQURWQU5DRUQgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX0hBU19MTFNDIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0NQVV9IQVNfTExEU0NEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQ
VV9IQVNfV0IgaXMgbm90IHNldA0KDQojDQojIEdlbmVyYWwgc2V0dXANCiMNCkNPTkZJR19DUFVf
TElUVExFX0VORElBTj15DQojIENPTkZJR19ORVQgaXMgbm90IHNldA0KIyBDT05GSUdfUENJIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0lTQSBpcyBub3Qgc2V0DQojIENPTkZJR19FSVNBIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1RDIGlzIG5vdCBzZXQNCiMgQ09ORklHX01DQSBpcyBub3Qgc2V0DQojIENP
TkZJR19TQlVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hPVFBMVUcgaXMgbm90IHNldA0KIyBDT05G
SUdfUENNQ0lBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hPVFBMVUdfUENJIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NZU1ZJUEMgaXMgbm90IHNldA0KIyBDT05GSUdfQlNEX1BST0NFU1NfQUNDVCBpcyBu
b3Qgc2V0DQojIENPTkZJR19TWVNDVEwgaXMgbm90IHNldA0KQ09ORklHX0tDT1JFX0VMRj15DQoj
IENPTkZJR19LQ09SRV9BT1VUIGlzIG5vdCBzZXQNCkNPTkZJR19CSU5GTVRfRkxBVD15DQojIENP
TkZJR19CSU5GTVRfWkZMQVQgaXMgbm90IHNldA0KIyBDT05GSUdfQklORk1UX0VMRiBpcyBub3Qg
c2V0DQojIENPTkZJR19CSU5GTVRfTUlTQyBpcyBub3Qgc2V0DQojIENPTkZJR19QTSBpcyBub3Qg
c2V0DQoNCiMNCiMgTWVtb3J5IFRlY2hub2xvZ3kgRGV2aWNlcyAoTVREKQ0KIw0KIyBDT05GSUdf
TVREIGlzIG5vdCBzZXQNCg0KIw0KIyBQYXJhbGxlbCBwb3J0IHN1cHBvcnQNCiMNCiMgQ09ORklH
X1BBUlBPUlQgaXMgbm90IHNldA0KDQojDQojIFBsdWcgYW5kIFBsYXkgY29uZmlndXJhdGlvbg0K
Iw0KIyBDT05GSUdfUE5QIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lTQVBOUCBpcyBub3Qgc2V0DQoN
CiMNCiMgQmxvY2sgZGV2aWNlcw0KIw0KIyBDT05GSUdfQkxLX0RFVl9GRCBpcyBub3Qgc2V0DQoj
IENPTkZJR19CTEtfREVWX1hEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BBUklERSBpcyBub3Qgc2V0
DQojIENPTkZJR19CTEtfQ1BRX0RBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19DUFFfQ0lTU19E
QSBpcyBub3Qgc2V0DQojIENPTkZJR19DSVNTX1NDU0lfVEFQRSBpcyBub3Qgc2V0DQojIENPTkZJ
R19CTEtfREVWX0RBQzk2MCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1VNRU0gaXMgbm90
IHNldA0KIyBDT05GSUdfQkxLX0RFVl9MT09QIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf
TkJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfUkFNIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0JMS19ERVZfSU5JVFJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfUkFNRElTS19EQVRB
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQkxLTUVNIGlzIG5vdCBzZXQNCg0KIw0KIyBN
dWx0aS1kZXZpY2Ugc3VwcG9ydCAoUkFJRCBhbmQgTFZNKQ0KIw0KIyBDT05GSUdfTUQgaXMgbm90
IHNldA0KIyBDT05GSUdfQkxLX0RFVl9NRCBpcyBub3Qgc2V0DQojIENPTkZJR19NRF9MSU5FQVIg
aXMgbm90IHNldA0KIyBDT05GSUdfTURfUkFJRDAgaXMgbm90IHNldA0KIyBDT05GSUdfTURfUkFJ
RDEgaXMgbm90IHNldA0KIyBDT05GSUdfTURfUkFJRDUgaXMgbm90IHNldA0KIyBDT05GSUdfTURf
TVVMVElQQVRIIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfTFZNIGlzIG5vdCBzZXQNCg0K
Iw0KIyBUZWxlcGhvbnkgU3VwcG9ydA0KIw0KIyBDT05GSUdfUEhPTkUgaXMgbm90IHNldA0KIyBD
T05GSUdfUEhPTkVfSVhKIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BIT05FX0lYSl9QQ01DSUEgaXMg
bm90IHNldA0KDQojDQojIFNDU0kgc3VwcG9ydA0KIw0KIyBDT05GSUdfU0NTSSBpcyBub3Qgc2V0
DQoNCiMNCiMgQW1hdGV1ciBSYWRpbyBzdXBwb3J0DQojDQojIENPTkZJR19IQU1SQURJTyBpcyBu
b3Qgc2V0DQoNCiMNCiMgQ2hhcmFjdGVyIGRldmljZXMNCiMNCiMgQ09ORklHX0xFRE1BTiBpcyBu
b3Qgc2V0DQojIENPTkZJR19WVCBpcyBub3Qgc2V0DQpDT05GSUdfU0VSSUFMPXkNCkNPTkZJR19T
RVJJQUxfQ09OU09MRT15DQojIENPTkZJR19TRVJJQUxfRVhURU5ERUQgaXMgbm90IHNldA0KIyBD
T05GSUdfU0VSSUFMX05PTlNUQU5EQVJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VOSVg5OF9QVFlT
IGlzIG5vdCBzZXQNCg0KIw0KIyBJMkMgc3VwcG9ydA0KIw0KIyBDT05GSUdfSTJDIGlzIG5vdCBz
ZXQNCg0KIw0KIyBNaWNlDQojDQojIENPTkZJR19CVVNNT1VTRSBpcyBub3Qgc2V0DQojIENPTkZJ
R19NT1VTRSBpcyBub3Qgc2V0DQoNCiMNCiMgSm95c3RpY2tzDQojDQojIENPTkZJR19JTlBVVF9H
QU1FUE9SVCBpcyBub3Qgc2V0DQojIENPTkZJR19RSUMwMl9UQVBFIGlzIG5vdCBzZXQNCg0KIw0K
IyBXYXRjaGRvZyBDYXJkcw0KIw0KQ09ORklHX1dBVENIRE9HPXkNCiMgQ09ORklHX1dBVENIRE9H
X05PV0FZT1VUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FDUVVJUkVfV0RUIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0FEVkFOVEVDSF9XRFQgaXMgbm90IHNldA0KIyBDT05GSUdfQUxJTTcxMDFfV0RUIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1NDNTIwX1dEVCBpcyBub3Qgc2V0DQojIENPTkZJR19QQ1dBVENI
RE9HIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VVUk9URUNIX1dEVCBpcyBub3Qgc2V0DQojIENPTkZJ
R19JQjcwMF9XRFQgaXMgbm90IHNldA0KIyBDT05GSUdfV0FGRVJfV0RUIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0k4MTBfVENPIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JWENPTVdEIGlzIG5vdCBzZXQN
CiMgQ09ORklHXzYwWFhfV0RUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDMTIwMF9XRFQgaXMgbm90
IHNldA0KIyBDT05GSUdfU09GVF9XQVRDSERPRyBpcyBub3Qgc2V0DQojIENPTkZJR19XODM4NzdG
X1dEVCBpcyBub3Qgc2V0DQojIENPTkZJR19XRFQgaXMgbm90IHNldA0KIyBDT05GSUdfV0RUUENJ
IGlzIG5vdCBzZXQNCiMgQ09ORklHX01BQ0haX1dEVCBpcyBub3Qgc2V0DQojIENPTkZJR19OVlJB
TSBpcyBub3Qgc2V0DQpDT05GSUdfUlRDPXkNCiMgQ09ORklHX0RUTEsgaXMgbm90IHNldA0KIyBD
T05GSUdfUjM5NjQgaXMgbm90IHNldA0KIyBDT05GSUdfQVBQTElDT00gaXMgbm90IHNldA0KDQoj
DQojIEZ0YXBlLCB0aGUgZmxvcHB5IHRhcGUgZGV2aWNlIGRyaXZlcg0KIw0KIyBDT05GSUdfRlRB
UEUgaXMgbm90IHNldA0KIyBDT05GSUdfQUdQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTSBpcyBu
b3Qgc2V0DQoNCiMNCiMgTXVsdGltZWRpYSBkZXZpY2VzDQojDQojIENPTkZJR19WSURFT19ERVYg
aXMgbm90IHNldA0KDQojDQojIEZpbGUgc3lzdGVtcw0KIw0KIyBDT05GSUdfUVVPVEEgaXMgbm90
IHNldA0KIyBDT05GSUdfQVVUT0ZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FVVE9GUzRfRlMg
aXMgbm90IHNldA0KIyBDT05GSUdfUkVJU0VSRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfUkVJ
U0VSRlNfQ0hFQ0sgaXMgbm90IHNldA0KIyBDT05GSUdfUkVJU0VSRlNfUFJPQ19JTkZPIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0FERlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQURGU19GU19SVyBp
cyBub3Qgc2V0DQojIENPTkZJR19BRkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hGU19GUyBp
cyBub3Qgc2V0DQojIENPTkZJR19CRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfRVhUM19GUyBp
cyBub3Qgc2V0DQojIENPTkZJR19KQkQgaXMgbm90IHNldA0KIyBDT05GSUdfSkJEX0RFQlVHIGlz
IG5vdCBzZXQNCkNPTkZJR19GQVRfRlM9eQ0KQ09ORklHX01TRE9TX0ZTPXkNCiMgQ09ORklHX1VN
U0RPU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19WRkFUX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0VGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19KRkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0pGRlMyX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSQU1GUyBpcyBub3Qgc2V0DQojIENPTkZJ
R19UTVBGUyBpcyBub3Qgc2V0DQpDT05GSUdfUkFNRlM9eQ0KIyBDT05GSUdfSVNPOTY2MF9GUyBp
cyBub3Qgc2V0DQojIENPTkZJR19KT0xJRVQgaXMgbm90IHNldA0KIyBDT05GSUdfWklTT0ZTIGlz
IG5vdCBzZXQNCkNPTkZJR19NSU5JWF9GUz15DQojIENPTkZJR19WWEZTX0ZTIGlzIG5vdCBzZXQN
CkNPTkZJR19OVEZTX0ZTPXkNCkNPTkZJR19OVEZTX1JXPXkNCiMgQ09ORklHX0hQRlNfRlMgaXMg
bm90IHNldA0KQ09ORklHX1BST0NfRlM9eQ0KQ09ORklHX0RFVkZTX0ZTPXkNCkNPTkZJR19ERVZG
U19NT1VOVD15DQojIENPTkZJR19ERVZGU19ERUJVRyBpcyBub3Qgc2V0DQojIENPTkZJR19ERVZQ
VFNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfUU5YNEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1FOWDRGU19SVyBpcyBub3Qgc2V0DQpDT05GSUdfUk9NRlNfRlM9eQ0KIyBDT05GSUdfRVhUMl9G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19TWVNWX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VERl9G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19VREZfUlcgaXMgbm90IHNldA0KIyBDT05GSUdfVUZTX0ZT
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VGU19GU19XUklURSBpcyBub3Qgc2V0DQojIENPTkZJR19O
Q1BGU19OTFMgaXMgbm90IHNldA0KIyBDT05GSUdfU01CX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1pJU09GU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19aTElCX0ZTX0lORkxBVEUgaXMgbm90IHNl
dA0KDQojDQojIFBhcnRpdGlvbiBUeXBlcw0KIw0KIyBDT05GSUdfUEFSVElUSU9OX0FEVkFOQ0VE
IGlzIG5vdCBzZXQNCkNPTkZJR19NU0RPU19QQVJUSVRJT049eQ0KIyBDT05GSUdfU01CX05MUyBp
cyBub3Qgc2V0DQpDT05GSUdfTkxTPXkNCg0KIw0KIyBOYXRpdmUgTGFuZ3VhZ2UgU3VwcG9ydA0K
Iw0KQ09ORklHX05MU19ERUZBVUxUPSJuIg0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzQzNyBpcyBu
b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfNzM3IGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
U19DT0RFUEFHRV83NzUgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1MCBpcyBu
b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODUyIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
U19DT0RFUEFHRV84NTUgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NyBpcyBu
b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
U19DT0RFUEFHRV84NjEgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MiBpcyBu
b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODYzIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
U19DT0RFUEFHRV84NjQgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NSBpcyBu
b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODY2IGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
U19DT0RFUEFHRV84NjkgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzkzNiBpcyBu
b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfOTUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
U19DT0RFUEFHRV85MzIgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzk0OSBpcyBu
b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODc0IGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
U19JU084ODU5XzggaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTAgaXMgbm90
IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTEgaXMgbm90IHNldA0KIyBDT05GSUdfTkxT
X0lTTzg4NTlfMSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV8yIGlzIG5vdCBzZXQN
CiMgQ09ORklHX05MU19JU084ODU5XzMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlf
NCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV81IGlzIG5vdCBzZXQNCiMgQ09ORklH
X05MU19JU084ODU5XzYgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfNyBpcyBub3Qg
c2V0DQojIENPTkZJR19OTFNfSVNPODg1OV85IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084
ODU5XzEzIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzE0IGlzIG5vdCBzZXQNCiMg
Q09ORklHX05MU19JU084ODU5XzE1IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19LT0k4X1IgaXMg
bm90IHNldA0KIyBDT05GSUdfTkxTX0tPSThfVSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfVVRG
OCBpcyBub3Qgc2V0DQoNCiMNCiMgU291bmQNCiMNCiMgQ09ORklHX1NPVU5EIGlzIG5vdCBzZXQN
Cg0KIw0KIyBVU0Igc3VwcG9ydA0KIw0KIyBDT05GSUdfVVNCIGlzIG5vdCBzZXQNCg0KIw0KIyBJ
bnB1dCBjb3JlIHN1cHBvcnQNCiMNCiMgQ09ORklHX0lOUFVUIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0lOUFVUX0tFWUJERVYgaXMgbm90IHNldA0KIyBDT05GSUdfSU5QVVRfTU9VU0VERVYgaXMgbm90
IHNldA0KIyBDT05GSUdfSU5QVVRfSk9ZREVWIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX0VW
REVWIGlzIG5vdCBzZXQNCg0KIw0KIyBLZXJuZWwgaGFja2luZw0KIw0KQ09ORklHX0NST1NTQ09N
UElMRT15DQojIENPTkZJR19SRU1PVEVfREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfR0RCX0NP
TlNPTEUgaXMgbm90IHNldA0KIyBDT05GSUdfREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfTUFH
SUNfU1lTUlEgaXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19VTkNBQ0hFRCBpcyBub3Qgc2V0DQoj
IENPTkZJR19DT05USUdVT1VTX1BBR0VfQUxMT0MgaXMgbm90IHNldA0KDQogICAgdGhlbiAgaSBt
b2RpZmllZCB0aGUgY29uZmlnIGJ5IGFnYWluIHJ1bm5pbmcgIm1ha2UgbWVudWNvbmZpZyIsIHRo
ZSBzeXN0ZW0gb3V0cHV0IC5jb25maWcgZm9yIG1lIGFnYWluLCBidXQgdGhpcyB0aW1lIHRoZSAN
CglpbWFnZSBjYW4ndCBydW4gLCBpdCByZXBvcnQgYSBCVUcgaW4gc2xhYi5jIGluIGttZW1fY2Fj
aGVfY3JlYXQgZnVuY3Rpb24gLGV4YWN0bHkgbGl2ZSBhdCB0aGlzOg0KCQkJCQkJDQoJCQkJZG93
bigmY2FjaGVfY2hhaW5fc2VtKQ0KCQkJCXsNCgkJCQkJc3RydWN0IGxpc3RfaGVhZCAqcDsNCgkJ
CQkJbGlzdF9mb3JfZWFjaChwLCZjYWNoZV9jaGFpbil7DQoJCQkJCQlrbWVtX2NhY2hlX3QgKnBj
ID0gbGlzdF9lbnRyeShwLGttZW1fY2FjaGVfdCxuZXh0KTsNCgkJCQkJCWlmKCFzdHJjbXAocGMt
Pm5hbWUsbmFtZSkpDQoJCQkJCQkJQlVHKCk7DQoJCQkJCX0NCgkJCQl9DQoNCglpIGRvbid0IGtu
b3cgd2h5LCBhbmQgd29uZGVyIHdoYXQncyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28g
LmNvbmZpZyB0aGF0IGFmZmVjdCB0aGUgaW1hZ2U/IA0KDQoJdGhlIG1vZGlmaWVkIC5jb25maWcg
aXMgbGlrZSB0aGlzIDoNCg0KICAgICAgICAgICAgICAgICAjDQojIEF1dG9tYXRpY2FsbHkgZ2Vu
ZXJhdGVkIGJ5IG1ha2UgbWVudWNvbmZpZzogZG9uJ3QgZWRpdA0KIw0KQ09ORklHX01JUFM9eQ0K
Q09ORklHX01JUFMzMj15DQpDT05GSUdfVUNMSU5VWD15DQoNCiMNCiMgQ29kZSBtYXR1cml0eSBs
ZXZlbCBvcHRpb25zDQojDQpDT05GSUdfRVhQRVJJTUVOVEFMPXkNCg0KIw0KIyBMb2FkYWJsZSBt
b2R1bGUgc3VwcG9ydA0KIw0KIyBDT05GSUdfTU9EVUxFUyBpcyBub3Qgc2V0DQoNCiMNCiMgTWFj
aGluZSBzZWxlY3Rpb24NCiMNCiMgQ09ORklHX1NJTVVMQVRPUiBpcyBub3Qgc2V0DQojIENPTkZJ
R19BQ0VSX1BJQ0FfNjEgaXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19QQjEwMDAgaXMgbm90IHNl
dA0KIyBDT05GSUdfTUlQU19QQjE1MDAgaXMgbm90IHNldA0KIyBDT05GSUdfQUxHT1JfUDQwMzIg
aXMgbm90IHNldA0KIyBDT05GSUdfQkFHRVRfTUlQUyBpcyBub3Qgc2V0DQojIENPTkZJR19NSVBT
X0NPQkFMVCBpcyBub3Qgc2V0DQojIENPTkZJR19ERUNTVEFUSU9OIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01JUFNfRVY2NDEyMCBpcyBub3Qgc2V0DQojIENPTkZJR19NSVBTX0VWOTYxMDAgaXMgbm90
IHNldA0KIyBDT05GSUdfTUlQU19JVlIgaXMgbm90IHNldA0KIyBDT05GSUdfSFBfTEFTRVJKRVQg
aXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19JVEU4MTcyIGlzIG5vdCBzZXQNCkNPTkZJR19PTU5J
X0JPQVJEPXkNCkNPTkZJR19PTU5JX1RZUEUwMT15DQojIENPTkZJR19NSVBTX0FUTEFTIGlzIG5v
dCBzZXQNCiMgQ09ORklHX01JUFNfTUFHTlVNXzQwMDAgaXMgbm90IHNldA0KIyBDT05GSUdfTUlQ
U19NQUxUQSBpcyBub3Qgc2V0DQojIENPTkZJR19NT01FTkNPX09DRUxPVCBpcyBub3Qgc2V0DQoj
IENPTkZJR19EREI1MDc0IGlzIG5vdCBzZXQNCiMgQ09ORklHX0REQjU0NzYgaXMgbm90IHNldA0K
IyBDT05GSUdfRERCNTQ3NyBpcyBub3Qgc2V0DQojIENPTkZJR19ORUNfT1NQUkVZIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX09MSVZFVFRJX003MDAgaXMgbm90IHNldA0KIyBDT05GSUdfTklOTyBpcyBu
b3Qgc2V0DQojIENPTkZJR19TR0lfSVAyMiBpcyBub3Qgc2V0DQojIENPTkZJR19TSUJZVEVfU0Ix
MjUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NOSV9STTIwMF9QQ0kgaXMgbm90IHNldA0KIyBDT05G
SUdfVE9TSElCQV9KTVIzOTI3IGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJR0hNRU0gaXMgbm90IHNl
dA0KQ09ORklHX1JXU0VNX0dFTkVSSUNfU1BJTkxPQ0s9eQ0KIyBDT05GSUdfUldTRU1fWENIR0FE
RF9BTEdPUklUSE0gaXMgbm90IHNldA0KQ09ORklHX05FV19JUlE9eQ0KQ09ORklHX05FV19USU1F
X0M9eQ0KIyBDT05GSUdfTUlQU19BVTEwMDAgaXMgbm90IHNldA0KDQojDQojIENQVSBzZWxlY3Rp
b24NCiMNCkNPTkZJR19DUFVfUjMwMDA9eQ0KIyBDT05GSUdfQ1BVX1RYMzlYWCBpcyBub3Qgc2V0
DQojIENPTkZJR19DUFVfUjYwMDAgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1ZSNDFYWCBpcyBu
b3Qgc2V0DQojIENPTkZJR19DUFVfUjQzMDAgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1I0WDAw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9UWDQ5WFggaXMgbm90IHNldA0KIyBDT05GSUdfQ1BV
X1I1MDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9SNTQzMiBpcyBub3Qgc2V0DQojIENPTkZJ
R19DUFVfUk03MDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9ORVZBREEgaXMgbm90IHNldA0K
IyBDT05GSUdfQ1BVX1IxMDAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfU0IxIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0NQVV9NSVBTMzIgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX01JUFM2NCBp
cyBub3Qgc2V0DQojIENPTkZJR19DUFVfQURWQU5DRUQgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BV
X0hBU19MTFNDIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9IQVNfTExEU0NEIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0NQVV9IQVNfV0IgaXMgbm90IHNldA0KDQojDQojIEdlbmVyYWwgc2V0dXANCiMN
CkNPTkZJR19DUFVfTElUVExFX0VORElBTj15DQojIENPTkZJR19ORVQgaXMgbm90IHNldA0KIyBD
T05GSUdfUENJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lTQSBpcyBub3Qgc2V0DQojIENPTkZJR19F
SVNBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RDIGlzIG5vdCBzZXQNCiMgQ09ORklHX01DQSBpcyBu
b3Qgc2V0DQojIENPTkZJR19TQlVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hPVFBMVUcgaXMgbm90
IHNldA0KIyBDT05GSUdfUENNQ0lBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hPVFBMVUdfUENJIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1NZU1ZJUEMgaXMgbm90IHNldA0KIyBDT05GSUdfQlNEX1BST0NF
U1NfQUNDVCBpcyBub3Qgc2V0DQojIENPTkZJR19TWVNDVEwgaXMgbm90IHNldA0KQ09ORklHX0tD
T1JFX0VMRj15DQojIENPTkZJR19LQ09SRV9BT1VUIGlzIG5vdCBzZXQNCkNPTkZJR19CSU5GTVRf
RkxBVD15DQojIENPTkZJR19CSU5GTVRfWkZMQVQgaXMgbm90IHNldA0KIyBDT05GSUdfQklORk1U
X0VMRiBpcyBub3Qgc2V0DQojIENPTkZJR19CSU5GTVRfTUlTQyBpcyBub3Qgc2V0DQojIENPTkZJ
R19QTSBpcyBub3Qgc2V0DQoNCiMNCiMgTWVtb3J5IFRlY2hub2xvZ3kgRGV2aWNlcyAoTVREKQ0K
Iw0KIyBDT05GSUdfTVREIGlzIG5vdCBzZXQNCg0KIw0KIyBQYXJhbGxlbCBwb3J0IHN1cHBvcnQN
CiMNCiMgQ09ORklHX1BBUlBPUlQgaXMgbm90IHNldA0KDQojDQojIFBsdWcgYW5kIFBsYXkgY29u
ZmlndXJhdGlvbg0KIw0KIyBDT05GSUdfUE5QIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lTQVBOUCBp
cyBub3Qgc2V0DQoNCiMNCiMgQmxvY2sgZGV2aWNlcw0KIw0KIyBDT05GSUdfQkxLX0RFVl9GRCBp
cyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1hEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BBUklE
RSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfQ1BRX0RBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM
S19DUFFfQ0lTU19EQSBpcyBub3Qgc2V0DQojIENPTkZJR19DSVNTX1NDU0lfVEFQRSBpcyBub3Qg
c2V0DQojIENPTkZJR19CTEtfREVWX0RBQzk2MCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW
X1VNRU0gaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9MT09QIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0JMS19ERVZfTkJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfUkFNIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0JMS19ERVZfSU5JVFJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf
UkFNRElTS19EQVRBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQkxLTUVNIGlzIG5vdCBz
ZXQNCg0KIw0KIyBNdWx0aS1kZXZpY2Ugc3VwcG9ydCAoUkFJRCBhbmQgTFZNKQ0KIw0KIyBDT05G
SUdfTUQgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9NRCBpcyBub3Qgc2V0DQojIENPTkZJ
R19NRF9MSU5FQVIgaXMgbm90IHNldA0KIyBDT05GSUdfTURfUkFJRDAgaXMgbm90IHNldA0KIyBD
T05GSUdfTURfUkFJRDEgaXMgbm90IHNldA0KIyBDT05GSUdfTURfUkFJRDUgaXMgbm90IHNldA0K
IyBDT05GSUdfTURfTVVMVElQQVRIIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfTFZNIGlz
IG5vdCBzZXQNCg0KIw0KIyBUZWxlcGhvbnkgU3VwcG9ydA0KIw0KIyBDT05GSUdfUEhPTkUgaXMg
bm90IHNldA0KIyBDT05GSUdfUEhPTkVfSVhKIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BIT05FX0lY
Sl9QQ01DSUEgaXMgbm90IHNldA0KDQojDQojIFNDU0kgc3VwcG9ydA0KIw0KIyBDT05GSUdfU0NT
SSBpcyBub3Qgc2V0DQoNCiMNCiMgQW1hdGV1ciBSYWRpbyBzdXBwb3J0DQojDQojIENPTkZJR19I
QU1SQURJTyBpcyBub3Qgc2V0DQoNCiMNCiMgQ2hhcmFjdGVyIGRldmljZXMNCiMNCiMgQ09ORklH
X0xFRE1BTiBpcyBub3Qgc2V0DQojIENPTkZJR19WVCBpcyBub3Qgc2V0DQpDT05GSUdfU0VSSUFM
PXkNCkNPTkZJR19TRVJJQUxfQ09OU09MRT15DQojIENPTkZJR19TRVJJQUxfRVhURU5ERUQgaXMg
bm90IHNldA0KIyBDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJEIGlzIG5vdCBzZXQNCkNPTkZJR19V
TklYOThfUFRZUz15DQpDT05GSUdfVU5JWDk4X1BUWV9DT1VOVD0yNTYNCg0KIw0KIyBJMkMgc3Vw
cG9ydA0KIw0KIyBDT05GSUdfSTJDIGlzIG5vdCBzZXQNCg0KIw0KIyBNaWNlDQojDQojIENPTkZJ
R19CVVNNT1VTRSBpcyBub3Qgc2V0DQojIENPTkZJR19NT1VTRSBpcyBub3Qgc2V0DQoNCiMNCiMg
Sm95c3RpY2tzDQojDQojIENPTkZJR19JTlBVVF9HQU1FUE9SVCBpcyBub3Qgc2V0DQojIENPTkZJ
R19RSUMwMl9UQVBFIGlzIG5vdCBzZXQNCg0KIw0KIyBXYXRjaGRvZyBDYXJkcw0KIw0KIyBDT05G
SUdfV0FUQ0hET0cgaXMgbm90IHNldA0KIyBDT05GSUdfTlZSQU0gaXMgbm90IHNldA0KIyBDT05G
SUdfUlRDIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RUTEsgaXMgbm90IHNldA0KIyBDT05GSUdfUjM5
NjQgaXMgbm90IHNldA0KIyBDT05GSUdfQVBQTElDT00gaXMgbm90IHNldA0KDQojDQojIEZ0YXBl
LCB0aGUgZmxvcHB5IHRhcGUgZGV2aWNlIGRyaXZlcg0KIw0KIyBDT05GSUdfRlRBUEUgaXMgbm90
IHNldA0KIyBDT05GSUdfQUdQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTSBpcyBub3Qgc2V0DQoN
CiMNCiMgTXVsdGltZWRpYSBkZXZpY2VzDQojDQojIENPTkZJR19WSURFT19ERVYgaXMgbm90IHNl
dA0KDQojDQojIEZpbGUgc3lzdGVtcw0KIw0KIyBDT05GSUdfUVVPVEEgaXMgbm90IHNldA0KIyBD
T05GSUdfQVVUT0ZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FVVE9GUzRfRlMgaXMgbm90IHNl
dA0KIyBDT05GSUdfUkVJU0VSRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfUkVJU0VSRlNfQ0hF
Q0sgaXMgbm90IHNldA0KIyBDT05GSUdfUkVJU0VSRlNfUFJPQ19JTkZPIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0FERlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQURGU19GU19SVyBpcyBub3Qgc2V0
DQojIENPTkZJR19BRkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hGU19GUyBpcyBub3Qgc2V0
DQojIENPTkZJR19CRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfRVhUM19GUyBpcyBub3Qgc2V0
DQojIENPTkZJR19KQkQgaXMgbm90IHNldA0KIyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0ZBVF9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19NU0RPU19GUyBpcyBub3Qgc2V0
DQojIENPTkZJR19VTVNET1NfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfVkZBVF9GUyBpcyBub3Qg
c2V0DQojIENPTkZJR19FRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfSkZGU19GUyBpcyBub3Qg
c2V0DQojIENPTkZJR19KRkZTMl9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19DUkFNRlMgaXMgbm90
IHNldA0KIyBDT05GSUdfVE1QRlMgaXMgbm90IHNldA0KQ09ORklHX1JBTUZTPXkNCiMgQ09ORklH
X0lTTzk2NjBfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfSk9MSUVUIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1pJU09GUyBpcyBub3Qgc2V0DQpDT05GSUdfTUlOSVhfRlM9eQ0KIyBDT05GSUdfVlhGU19G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19OVEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX05URlNf
UlcgaXMgbm90IHNldA0KIyBDT05GSUdfSFBGU19GUyBpcyBub3Qgc2V0DQpDT05GSUdfUFJPQ19G
Uz15DQpDT05GSUdfREVWRlNfRlM9eQ0KQ09ORklHX0RFVkZTX01PVU5UPXkNCiMgQ09ORklHX0RF
VkZTX0RFQlVHIGlzIG5vdCBzZXQNCkNPTkZJR19ERVZQVFNfRlM9eQ0KIyBDT05GSUdfUU5YNEZT
X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1FOWDRGU19SVyBpcyBub3Qgc2V0DQpDT05GSUdfUk9N
RlNfRlM9eQ0KQ09ORklHX0VYVDJfRlM9eQ0KIyBDT05GSUdfU1lTVl9GUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19VREZfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfVURGX1JXIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1VGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19VRlNfRlNfV1JJVEUgaXMgbm90IHNl
dA0KIyBDT05GSUdfTkNQRlNfTkxTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NNQl9GUyBpcyBub3Qg
c2V0DQojIENPTkZJR19aSVNPRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfWkxJQl9GU19JTkZM
QVRFIGlzIG5vdCBzZXQNCg0KIw0KIyBQYXJ0aXRpb24gVHlwZXMNCiMNCiMgQ09ORklHX1BBUlRJ
VElPTl9BRFZBTkNFRCBpcyBub3Qgc2V0DQpDT05GSUdfTVNET1NfUEFSVElUSU9OPXkNCiMgQ09O
RklHX1NNQl9OTFMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTIGlzIG5vdCBzZXQNCg0KIw0KIyBT
b3VuZA0KIw0KIyBDT05GSUdfU09VTkQgaXMgbm90IHNldA0KDQojDQojIFVTQiBzdXBwb3J0DQoj
DQojIENPTkZJR19VU0IgaXMgbm90IHNldA0KDQojDQojIElucHV0IGNvcmUgc3VwcG9ydA0KIw0K
IyBDT05GSUdfSU5QVVQgaXMgbm90IHNldA0KIyBDT05GSUdfSU5QVVRfS0VZQkRFViBpcyBub3Qg
c2V0DQojIENPTkZJR19JTlBVVF9NT1VTRURFViBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9K
T1lERVYgaXMgbm90IHNldA0KIyBDT05GSUdfSU5QVVRfRVZERVYgaXMgbm90IHNldA0KDQojDQoj
IEtlcm5lbCBoYWNraW5nDQojDQpDT05GSUdfQ1JPU1NDT01QSUxFPXkNCiMgQ09ORklHX1JFTU9U
RV9ERUJVRyBpcyBub3Qgc2V0DQojIENPTkZJR19HREJfQ09OU09MRSBpcyBub3Qgc2V0DQojIENP
TkZJR19ERUJVRyBpcyBub3Qgc2V0DQojIENPTkZJR19NQUdJQ19TWVNSUSBpcyBub3Qgc2V0DQoj
IENPTkZJR19NSVBTX1VOQ0FDSEVEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NPTlRJR1VPVVNfUEFH
RV9BTExPQyBpcyBub3Qgc2V0DQoNCgkgDQoNCgkNCg0KoaGhoaGhoaGhoaGhoaGhoXh1aGFveg0K
oaGhoaGhoaGhoaGhoaGhoXh1aGFvekBuZW9uZXRlY2guY29tDQqhoaGhoaGhoaGhoaGhoaGhoaGh
oTIwMDQtMDktMDENCg==


From ppopov@mvista.com Wed Sep  1 12:19:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Sep 2004 12:19:11 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27638 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225220AbUIALTH>;
	Wed, 1 Sep 2004 12:19:07 +0100
Received: from [10.2.2.63] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id EAA05728;
	Wed, 1 Sep 2004 04:19:02 -0700
Subject: Re: gadget driver for Au1500
From: Pete Popov <ppopov@mvista.com>
To: "Peter 'p2' De Schrijver" <p2@mind.be>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040901094005.GX2305@mind.be>
References: <20040901094005.GX2305@mind.be>
Content-Type: text/plain
Organization: 
Message-Id: <1094037536.2502.7.camel@thinkpad.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 01 Sep 2004 04:18:56 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5760
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, 2004-09-01 at 02:40, Peter 'p2' De Schrijver wrote:
> Hi,
> 
> Is there a USB gadget driver for the AMD Au1500 or is someone working on
> it ?

I have a patch for it but it doesn't work yet. The driver starts the
negotiation with the host but fails in the end. It was hard to debug the
problem without a USB analyzer, and I ran out of time, so it's on hold
at the moment. Someone else will take a look at it at some point. Are 
you willing to debug it :)?

Pete


From dom@mips.com Wed Sep  1 14:29:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Sep 2004 14:29:07 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:26632 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224925AbUIAN3B>;
	Wed, 1 Sep 2004 14:29:01 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1C2VL3-0005Dc-00; Wed, 01 Sep 2004 14:39:49 +0100
Received: from olympia.mips.com ([192.168.192.128] helo=doms-laptop.algor.co.uk)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1C2VA2-0008Vl-00; Wed, 01 Sep 2004 14:28:26 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16693.52862.859233.198626@doms-laptop.algor.co.uk>
Date: Wed, 1 Sep 2004 14:28:30 +0100
To: Emmanuel Michon <em@realmagic.fr>
Cc: linux-mips@linux-mips.org
Subject: Re: TLB dimensioning
In-Reply-To: <1094033224.20643.1402.camel@nikita.france.sdesigns.com>
References: <1094033224.20643.1402.camel@nikita.france.sdesigns.com>
X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.849, 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: 5761
X-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


Emmanuel,

> regarding the hardware implementation of a 4KE (r4k style mmu
> if I remember) I'm wondering about the performance difference
> when the TLB has 16 pairs of entries (covering 128KBytes of
> data) or 32 pairs (covering 256KBytes).
> 
> Does someone have a useful advise regarding the `nice spot'
> for TLB size?

As you expected, there is no really simple answer.  The TLB is a
relatively large piece of logic, so it often isn't a trivial decision.

Applications - particularly embedded applications, which I suspect is
what you mean - vary a lot in the size of the mapped, user-space
working set.  Some Linux-powered embedded devices do nearly all their
work in the kernel...

However, the measurements we've done at MIPS suggest that for
moderate-size workloads where the user-space programs are working
hard, a 16-entry TLB can thrash quite badly, making a significant dent
in performance.

So the advice I'd give is that if:

1. Your application has a non-trivial user space of any size;

2. The performance of userland code is significant;

then you should pick a 32-entry TLB, until and unless you have
measurements of your own application to show you don't need it.

-- 
Dominic Sweetman
MIPS Technologies


From anemo@mba.ocn.ne.jp Wed Sep  1 16:06:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Sep 2004 16:06:09 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:33480 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8224988AbUIAPGE>; Wed, 1 Sep 2004 16:06:04 +0100
Received: from localhost (p6055-ipad204funabasi.chiba.ocn.ne.jp [222.146.93.55])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 94FAD70C7; Thu,  2 Sep 2004 00:06:00 +0900 (JST)
Date: Thu, 02 Sep 2004 00:14:33 +0900 (JST)
Message-Id: <20040902.001433.59461413.anemo@mba.ocn.ne.jp>
To: rsandifo@redhat.com
Cc: linux-mips@linux-mips.org
Subject: Re: gcc 3.3.4/3.4.1 and get_user
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <87656yqsmz.fsf@redhat.com>
References: <20040901.012223.59462025.anemo@mba.ocn.ne.jp>
	<87656yqsmz.fsf@redhat.com>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 5762
X-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, 01 Sep 2004 09:51:16 +0100, Richard Sandiford <rsandifo@redhat.com> said:
>> Is this a get_user's problem or gcc's?
rsandifo> The latter.  gcc is putting the empty asm:

rsandifo> 	__asm__ ("":"=r" (__gu_val));

rsandifo> into the delay slot of the call.

Thank you for the detailed explanation.

rsandifo> FWIW, I don't think the bug is specific to 3.3 or 3.4.  It
rsandifo> could probably trigger for other gcc versions too.  It is
rsandifo> highly dependent on scheduling though.

Yes, this problem was originally found on gcc 3.2.

rsandifo> The attached 3.4.x patch fixes the problem there, but if you
rsandifo> want to work around it for old versions, just avoid using
rsandifo> empty asms if you can, or make them volatile if you can't.

Thank you.  I create a patch for kernel with this workaround.

# This patch assumes gcc 3.5 will be free from this problem :-)

Could you apply, Ralf?

diff -u linux-mips-cvs/include/asm-mips/paccess.h linux-mips/include/asm-mips/paccess.h
--- linux-mips-cvs/include/asm-mips/paccess.h	Mon Nov 24 20:22:01 2003
+++ linux-mips/include/asm-mips/paccess.h	Wed Sep  1 22:49:30 2004
@@ -15,6 +15,7 @@
 
 #include <linux/config.h>
 #include <linux/errno.h>
+#include <asm/war.h>
 
 #ifdef CONFIG_MIPS32
 #define __PA_ADDR	".word"
@@ -37,7 +38,7 @@
 	long __gu_err;							\
 	__typeof(*(ptr)) __gu_val;					\
 	unsigned long __gu_addr;					\
-	__asm__("":"=r" (__gu_val));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_val));		\
 	__gu_addr = (unsigned long) (ptr);				\
 	__asm__("":"=r" (__gu_err));					\
 	switch (size) {							\
@@ -78,7 +79,7 @@
 	long __pu_addr;							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__pu_err));		\
 	switch (size) {							\
 	case 1: __put_dbe_asm("sb"); break;				\
 	case 2: __put_dbe_asm("sh"); break;				\
diff -u linux-mips-cvs/include/asm-mips/uaccess.h linux-mips/include/asm-mips/uaccess.h
--- linux-mips-cvs/include/asm-mips/uaccess.h	Wed Mar 31 20:21:59 2004
+++ linux-mips/include/asm-mips/uaccess.h	Wed Sep  1 23:24:15 2004
@@ -13,6 +13,7 @@
 #include <linux/compiler.h>
 #include <linux/errno.h>
 #include <linux/thread_info.h>
+#include <asm/war.h>
 
 /*
  * The fs value determines whether argument validity checking should be
@@ -235,9 +236,9 @@
 	__typeof(*(ptr)) __gu_val;				\
 	long __gu_addr;						\
 	might_sleep();						\
-	__asm__("":"=r" (__gu_val));				\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_val));	\
 	__gu_addr = (long) (ptr);				\
-	__asm__("":"=r" (__gu_err));				\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_err));	\
 	switch (size) {						\
 	case 1: __get_user_asm("lb"); break;			\
 	case 2: __get_user_asm("lh"); break;			\
@@ -253,9 +254,9 @@
 	__typeof__(*(ptr)) __gu_val;					\
 	long __gu_addr;							\
 	might_sleep();							\
-	__asm__("":"=r" (__gu_val));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_val));		\
 	__gu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__gu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_err));		\
 	if (access_ok(VERIFY_READ,__gu_addr,size)) {			\
 		switch (size) {						\
 		case 1: __get_user_asm("lb"); break;			\
@@ -329,7 +330,7 @@
 	might_sleep();							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__pu_err));		\
 	switch (size) {							\
 	case 1: __put_user_asm("sb"); break;				\
 	case 2: __put_user_asm("sh"); break;				\
@@ -348,7 +349,7 @@
 	might_sleep();							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__pu_err));		\
 	if (access_ok(VERIFY_WRITE, __pu_addr, size)) {			\
 		switch (size) {						\
 		case 1: __put_user_asm("sb"); break;			\
diff -u linux-mips-cvs/include/asm-mips/war.h linux-mips/include/asm-mips/war.h
--- linux-mips-cvs/include/asm-mips/war.h	Sat Aug 21 00:34:12 2004
+++ linux-mips/include/asm-mips/war.h	Wed Sep  1 23:22:29 2004
@@ -221,4 +221,10 @@
 #define R10000_LLSC_WAR			0
 #endif
 
+#if (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 4))
+#define GCC_ASM_PROTECT_DSLOT
+#else
+#define GCC_ASM_PROTECT_DSLOT	__volatile__
+#endif
+
 #endif /* _ASM_WAR_H */

From anemo@mba.ocn.ne.jp Wed Sep  1 16:08:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Sep 2004 16:08:11 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:48369 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225198AbUIAPIH>; Wed, 1 Sep 2004 16:08:07 +0100
Received: from localhost (p6055-ipad204funabasi.chiba.ocn.ne.jp [222.146.93.55])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 03E4A74F3; Thu,  2 Sep 2004 00:08:03 +0900 (JST)
Date: Thu, 02 Sep 2004 00:16:35 +0900 (JST)
Message-Id: <20040902.001635.92589944.anemo@mba.ocn.ne.jp>
To: rsandifo@redhat.com
Cc: linux-mips@linux-mips.org
Subject: Re: gcc 3.3.4/3.4.1 and get_user
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20040902.001433.59461413.anemo@mba.ocn.ne.jp>
References: <20040901.012223.59462025.anemo@mba.ocn.ne.jp>
	<87656yqsmz.fsf@redhat.com>
	<20040902.001433.59461413.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: 5763
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Thu, 02 Sep 2004 00:14:33 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:

anemo> Thank you.  I create a patch for kernel with this workaround.
anemo> # This patch assumes gcc 3.5 will be free from this problem :-)

anemo> Could you apply, Ralf?

And this is for 2.4 tree.

diff -u linux-mips-2.4-cvs/include/asm-mips/paccess.h linux-mips-2.4/include/asm-mips/paccess.h
--- linux-mips-2.4-cvs/include/asm-mips/paccess.h	Tue Nov 11 21:49:34 2003
+++ linux-mips-2.4/include/asm-mips/paccess.h	Wed Sep  1 23:21:41 2004
@@ -14,6 +14,7 @@
 #define _ASM_PACCESS_H
 
 #include <linux/errno.h>
+#include <asm/war.h>
 
 #define put_dbe(x,ptr) __put_dbe((x),(ptr),sizeof(*(ptr)))
 #define get_dbe(x,ptr) __get_dbe((x),(ptr),sizeof(*(ptr)))
@@ -25,7 +26,7 @@
 int __gu_err; \
 __typeof(*(ptr)) __gu_val; \
 unsigned long __gu_addr; \
-__asm__("":"=r" (__gu_val)); \
+__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_val)); \
 __gu_addr = (unsigned long) (ptr); \
 __asm__("":"=r" (__gu_err)); \
 switch (size) { \
@@ -64,7 +65,7 @@
 unsigned long __pu_addr; \
 __pu_val = (x); \
 __pu_addr = (unsigned long) (ptr); \
-__asm__("":"=r" (__pu_err)); \
+__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__pu_err)); \
 switch (size) { \
 case 1: __put_dbe_asm("sb"); break; \
 case 2: __put_dbe_asm("sh"); break; \
diff -u linux-mips-2.4-cvs/include/asm-mips/uaccess.h linux-mips-2.4/include/asm-mips/uaccess.h
--- linux-mips-2.4-cvs/include/asm-mips/uaccess.h	Mon Sep 15 10:28:51 2003
+++ linux-mips-2.4/include/asm-mips/uaccess.h	Wed Sep  1 23:24:00 2004
@@ -12,6 +12,7 @@
 #include <linux/compiler.h>
 #include <linux/errno.h>
 #include <linux/sched.h>
+#include <asm/war.h>
 
 #define STR(x)  __STR(x)
 #define __STR(x)  #x
@@ -200,9 +201,9 @@
 	long __gu_err;							\
 	__typeof(*(ptr)) __gu_val;					\
 	long __gu_addr;							\
-	__asm__("":"=r" (__gu_val));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_val));		\
 	__gu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__gu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_err));		\
 	switch (size) {							\
 		case 1: __get_user_asm("lb"); break;			\
 		case 2: __get_user_asm("lh"); break;			\
@@ -218,9 +219,9 @@
 	long __gu_err;							\
 	__typeof__(*(ptr)) __gu_val;					\
 	long __gu_addr;							\
-	__asm__("":"=r" (__gu_val));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_val));		\
 	__gu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__gu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_err));		\
 	if (access_ok(VERIFY_READ, __gu_addr, size)) {			\
 		switch (size) {						\
 		case 1: __get_user_asm("lb"); break;			\
@@ -294,7 +295,7 @@
 	long __pu_addr;							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__pu_err));		\
 	switch (size) {							\
 		case 1: __put_user_asm("sb"); break;			\
 		case 2: __put_user_asm("sh"); break;			\
@@ -312,7 +313,7 @@
 	long __pu_addr;							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__pu_err));		\
 	if (access_ok(VERIFY_WRITE, __pu_addr, size)) {			\
 		switch (size) {						\
 		case 1: __put_user_asm("sb"); break;			\
diff -u linux-mips-2.4-cvs/include/asm-mips/war.h linux-mips-2.4/include/asm-mips/war.h
--- linux-mips-2.4-cvs/include/asm-mips/war.h	Mon Mar  8 20:21:39 2004
+++ linux-mips-2.4/include/asm-mips/war.h	Wed Sep  1 23:23:04 2004
@@ -210,4 +210,10 @@
 #define RM9000_CDEX_SMP_WAR		0
 #endif
 
+#if (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 4))
+#define GCC_ASM_PROTECT_DSLOT
+#else
+#define GCC_ASM_PROTECT_DSLOT	__volatile__
+#endif
+
 #endif /* _ASM_WAR_H */
diff -u linux-mips-2.4-cvs/include/asm-mips64/paccess.h linux-mips-2.4/include/asm-mips64/paccess.h
--- linux-mips-2.4-cvs/include/asm-mips64/paccess.h	Mon Jul  9 09:25:38 2001
+++ linux-mips-2.4/include/asm-mips64/paccess.h	Wed Sep  1 23:21:41 2004
@@ -14,6 +14,7 @@
 #define _ASM_PACCESS_H
 
 #include <linux/errno.h>
+#include <asm/war.h>
 
 #define put_dbe(x,ptr) __put_dbe((x),(ptr),sizeof(*(ptr)))
 #define get_dbe(x,ptr) __get_dbe((x),(ptr),sizeof(*(ptr)))
@@ -25,7 +26,7 @@
 long __gu_err; \
 __typeof(*(ptr)) __gu_val; \
 long __gu_addr; \
-__asm__("":"=r" (__gu_val)); \
+__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_val)); \
 __gu_addr = (long) (ptr); \
 __asm__("":"=r" (__gu_err)); \
 switch (size) { \
@@ -61,7 +62,7 @@
 long __pu_addr; \
 __pu_val = (x); \
 __pu_addr = (long) (ptr); \
-__asm__("":"=r" (__pu_err)); \
+__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__pu_err)); \
 switch (size) { \
 case 1: __put_dbe_asm("sb"); break; \
 case 2: __put_dbe_asm("sh"); break; \
diff -u linux-mips-2.4-cvs/include/asm-mips64/uaccess.h linux-mips-2.4/include/asm-mips64/uaccess.h
--- linux-mips-2.4-cvs/include/asm-mips64/uaccess.h	Wed Sep 17 23:22:35 2003
+++ linux-mips-2.4/include/asm-mips64/uaccess.h	Wed Sep  1 23:23:35 2004
@@ -12,6 +12,7 @@
 #include <linux/compiler.h>
 #include <linux/errno.h>
 #include <linux/sched.h>
+#include <asm/war.h>
 
 #define STR(x)  __STR(x)
 #define __STR(x)  #x
@@ -190,9 +191,9 @@
 	long __gu_err;							\
 	__typeof(*(ptr)) __gu_val;					\
 	long __gu_addr;							\
-	__asm__("":"=r" (__gu_val));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_val));		\
 	__gu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__gu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_err));		\
 	switch (size) {							\
 		case 1: __get_user_asm("lb"); break;			\
 		case 2: __get_user_asm("lh"); break;			\
@@ -208,9 +209,9 @@
 	long __gu_err;							\
 	__typeof__(*(ptr)) __gu_val;					\
 	long __gu_addr;							\
-	__asm__("":"=r" (__gu_val));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_val));		\
 	__gu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__gu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__gu_err));		\
 	if (access_ok(VERIFY_READ, __gu_addr, size)) {			\
 		switch (size) {						\
 		case 1: __get_user_asm("lb"); break;			\
@@ -250,7 +251,7 @@
 	long __pu_addr;							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__pu_err));		\
 	switch (size) {							\
 		case 1: __put_user_asm("sb"); break;			\
 		case 2: __put_user_asm("sh"); break;			\
@@ -268,7 +269,7 @@
 	long __pu_addr;							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
+	__asm__ GCC_ASM_PROTECT_DSLOT ("":"=r" (__pu_err));		\
 	if (access_ok(VERIFY_WRITE, __pu_addr, size)) {			\
 		switch (size) {						\
 		case 1: __put_user_asm("sb"); break;			\
diff -u linux-mips-2.4-cvs/include/asm-mips64/war.h linux-mips-2.4/include/asm-mips64/war.h
--- linux-mips-2.4-cvs/include/asm-mips64/war.h	Mon Mar  8 20:21:39 2004
+++ linux-mips-2.4/include/asm-mips64/war.h	Wed Sep  1 23:23:12 2004
@@ -210,4 +210,10 @@
 #define RM9000_CDEX_SMP_WAR		0
 #endif
 
+#if (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 4))
+#define GCC_ASM_PROTECT_DSLOT
+#else
+#define GCC_ASM_PROTECT_DSLOT	__volatile__
+#endif
+
 #endif /* _ASM_WAR_H */

From ralf@linux-mips.org Wed Sep  1 23:28:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Sep 2004 23:31:41 +0100 (BST)
Received: from p508B68F0.dip.t-dialin.net ([IPv6:::ffff:80.139.104.240]:49456
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225220AbUIAW2l>; Wed, 1 Sep 2004 23:28:41 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i81MSe2V005809
	for <linux-mips@linux-mips.org>; Thu, 2 Sep 2004 00:28:40 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i81MSe3t005808
	for linux-mips@linux-mips.org; Thu, 2 Sep 2004 00:28:40 +0200
Resent-Message-Id: <200409012228.i81MSe3t005808@fluff.linux-mips.net>
Received: from baikonur.stro.at ([IPv6:::ffff:213.239.196.228]:51910 "EHLO
	baikonur.stro.at") by linux-mips.org with ESMTP id <S8225211AbUIAV2T>;
	Wed, 1 Sep 2004 22:28:19 +0100
Received: from localhost (localhost [127.0.0.1])
	by baikonur.stro.at (Postfix) with ESMTP id 98B635C065;
	Wed,  1 Sep 2004 23:28:15 +0200 (CEST)
Received: from baikonur.stro.at ([127.0.0.1])
	by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 09433-01; Wed, 1 Sep 2004 23:28:15 +0200 (CEST)
Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181])
	by baikonur.stro.at (Postfix) with ESMTP id 17AC55C008;
	Wed,  1 Sep 2004 23:28:15 +0200 (CEST)
Received: from localhost ([127.0.0.1] helo=localhost.localdomain)
	by sputnik with esmtp (Exim 4.34)
	id 1C2ceP-0000Me-GX; Wed, 01 Sep 2004 23:28:17 +0200
Subject: [patch 1/1]  minmax-removal 	arch/mips/au1000/common/usbdev.c
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org, janitor@sternwelten.at
From: janitor@sternwelten.at
Date: Wed, 01 Sep 2004 23:28:17 +0200
Message-ID: <E1C2ceP-0000Me-GX@sputnik>
X-Virus-Scanned: by Amavis (ClamAV) at stro.at
Resent-From: ralf@linux-mips.org
Resent-Date: Thu, 2 Sep 2004 00:28:40 +0200
Resent-To: linux-mips@linux-mips.org
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: 5764
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips




Patch (against 2.6.8.1) removes unnecessary min/max macros and changes
calls to use kernel.h macros instead.

Since I dont have the hardware those patches are not tested.

Best regards
Veeck

Signed-off-by: Michael Veeck <michael.veeck@gmx.net>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>



---

 linux-2.6.9-rc1-bk7-max/arch/mips/au1000/common/usbdev.c |    2 --
 1 files changed, 2 deletions(-)

diff -puN arch/mips/au1000/common/usbdev.c~min-max-arch_mips_au1000_common_usbdev arch/mips/au1000/common/usbdev.c
--- linux-2.6.9-rc1-bk7/arch/mips/au1000/common/usbdev.c~min-max-arch_mips_au1000_common_usbdev	2004-09-01 19:38:23.000000000 +0200
+++ linux-2.6.9-rc1-bk7-max/arch/mips/au1000/common/usbdev.c	2004-09-01 19:38:23.000000000 +0200
@@ -61,8 +61,6 @@
 #define vdbg(fmt, arg...) do {} while (0)
 #endif
 
-#define MAX(a,b)	(((a)>(b))?(a):(b))
-
 #define ALLOC_FLAGS (in_interrupt () ? GFP_ATOMIC : GFP_KERNEL)
 
 #define EP_FIFO_DEPTH 8

_

From ralf@linux-mips.org Thu Sep  2 00:35:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Sep 2004 00:35:56 +0100 (BST)
Received: from p508B68F0.dip.t-dialin.net ([IPv6:::ffff:80.139.104.240]:42033
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225218AbUIAXfw>; Thu, 2 Sep 2004 00:35:52 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i81NZpe1007215;
	Thu, 2 Sep 2004 01:35:51 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i81NZour007214;
	Thu, 2 Sep 2004 01:35:50 +0200
Date: Thu, 2 Sep 2004 01:35:50 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Dominic Sweetman <dom@mips.com>
Cc: Emmanuel Michon <em@realmagic.fr>, linux-mips@linux-mips.org
Subject: Re: TLB dimensioning
Message-ID: <20040901233550.GA5721@linux-mips.org>
References: <1094033224.20643.1402.camel@nikita.france.sdesigns.com> <16693.52862.859233.198626@doms-laptop.algor.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16693.52862.859233.198626@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: 5765
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Sep 01, 2004 at 02:28:30PM +0100, Dominic Sweetman wrote:

> 1. Your application has a non-trivial user space of any size;
> 
> 2. The performance of userland code is significant;

The kernel's performance also relies on TLB performance.

The wired register is making it easy to test performance of kernel and
application with a reduced size TLB; maybe I should make that a kernel
feature.

  Ralf

From pf@net.alphadv.de Thu Sep  2 01:15:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Sep 2004 01:15:39 +0100 (BST)
Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:58126 "EHLO
	mail.alphastar.de") by linux-mips.org with ESMTP
	id <S8225222AbUIBAPf>; Thu, 2 Sep 2004 01:15:35 +0100
Received: from SNaIlmail.Peter (212.144.142.117)
          by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==)
          for <linux-mips@linux-mips.org>; Thu, 2 Sep 2004 02:14:10 +0200
Received: from Opal.Peter (root@Opal.Peter [192.168.1.1])
	by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id i8209nWf000939
	for <linux-mips@linux-mips.org>; Thu, 2 Sep 2004 02:09:50 +0200
Received: from indigo2.Peter (Indigo2.Peter [192.168.1.28])
	by Opal.Peter (8.9.3/8.9.3/Sendmail/Linux 2.2.5-15) with ESMTP id CAA05841
	for <linux-mips@linux-mips.org>; Thu, 2 Sep 2004 02:09:50 +0200
Received: from localhost (pf@localhost)
	by indigo2.Peter (8.8.7/8.8.7/Linux 2.4.22 IP28) with SMTP id EAA14051
	for <linux-mips@linux-mips.org>; Thu, 2 Sep 2004 04:11:25 +0200
Date: Thu, 2 Sep 2004 04:11:25 +0200 (CEST)
From: Peter Fuerst <pf@net.alphadv.de>
Reply-To: Peter Fuerst <pf@net.alphadv.de>
To: linux-mips@linux-mips.org
Subject: gcc 2.95 patch for IP28
Message-ID: <Pine.LNX.3.96.1040902040502.14047A-100000@indigo2.Peter>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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: 5766
X-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



Hello !

A patch to gcc 2.95.4 to make it insert the necessary cache barriers
in (kernel-)code for SGI Indigo2 R10k (IP28) is available at
http://home.alphastar.de/fuerst/download.html


with kind regards...



From js@convergence.de Thu Sep  2 11:19:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Sep 2004 11:19:22 +0100 (BST)
Received: from pD9E729B1.dip.t-dialin.net ([IPv6:::ffff:217.231.41.177]:9869
	"EHLO abc.local") by linux-mips.org with ESMTP id <S8225229AbUIBKTS>;
	Thu, 2 Sep 2004 11:19:18 +0100
Received: from js by abc.local with local (Exim 3.35 #1 (Debian))
	id 1C2ohB-00021J-00; Thu, 02 Sep 2004 12:19:57 +0200
Date: Thu, 2 Sep 2004 12:19:57 +0200
From: Johannes Stezenbach <js@convergence.de>
To: Dominic Sweetman <dom@mips.com>
Cc: Emmanuel Michon <em@realmagic.fr>, linux-mips@linux-mips.org
Subject: Re: TLB dimensioning
Message-ID: <20040902101957.GA7728@convergence.de>
Mail-Followup-To: Johannes Stezenbach <js@convergence.de>,
	Dominic Sweetman <dom@mips.com>, Emmanuel Michon <em@realmagic.fr>,
	linux-mips@linux-mips.org
References: <1094033224.20643.1402.camel@nikita.france.sdesigns.com> <16693.52862.859233.198626@doms-laptop.algor.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16693.52862.859233.198626@doms-laptop.algor.co.uk>
User-Agent: Mutt/1.5.6+20040818i
Return-Path: <js@convergence.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5767
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: js@convergence.de
Precedence: bulk
X-list: linux-mips

Dominic Sweetman wrote:
> 
> Emmanuel,
> 
> > regarding the hardware implementation of a 4KE (r4k style mmu
> > if I remember) I'm wondering about the performance difference
> > when the TLB has 16 pairs of entries (covering 128KBytes of
> > data) or 32 pairs (covering 256KBytes).
> > 
> > Does someone have a useful advise regarding the `nice spot'
> > for TLB size?
...
> However, the measurements we've done at MIPS suggest that for
> moderate-size workloads where the user-space programs are working
> hard, a 16-entry TLB can thrash quite badly, making a significant dent
> in performance.
> 
> So the advice I'd give is that if:
> 
> 1. Your application has a non-trivial user space of any size;
> 
> 2. The performance of userland code is significant;
> 
> then you should pick a 32-entry TLB, until and unless you have
> measurements of your own application to show you don't need it.

Hm, the MIPS32 4K Processor Core Family Software User's Manual says:

"...the 4Kc core contains a 3-entry instruction TLB (ITLB), a 3-entry
data TLB(DTLB), and a 16 dual-entry joint TLB (JTLB) with variable page
sizes."

What exactly does that mean, and how does it rate performancewise?
I'm just curious ;-)

Johannes

From janitor@sternwelten.at  Wed Sep  1 22:28:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Sep 2004 11:24:40 +0100 (BST)
Received: from baikonur.stro.at ([IPv6:::ffff:213.239.196.228]:51910 "EHLO
	baikonur.stro.at") by linux-mips.org with ESMTP id <S8225211AbUIAV2T>;
	Wed, 1 Sep 2004 22:28:19 +0100
Received: from localhost (localhost [127.0.0.1])
	by baikonur.stro.at (Postfix) with ESMTP id 98B635C065;
	Wed,  1 Sep 2004 23:28:15 +0200 (CEST)
Received: from baikonur.stro.at ([127.0.0.1])
	by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 09433-01; Wed, 1 Sep 2004 23:28:15 +0200 (CEST)
Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181])
	by baikonur.stro.at (Postfix) with ESMTP id 17AC55C008;
	Wed,  1 Sep 2004 23:28:15 +0200 (CEST)
Received: from localhost ([127.0.0.1] helo=localhost.localdomain)
	by sputnik with esmtp (Exim 4.34)
	id 1C2ceP-0000Me-GX; Wed, 01 Sep 2004 23:28:17 +0200
Subject: [patch 1/1]  minmax-removal 	arch/mips/au1000/common/usbdev.c
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org, janitor@sternwelten.at
From: janitor@sternwelten.at
Date: Wed, 01 Sep 2004 23:28:17 +0200
Message-ID: <E1C2ceP-0000Me-GX@sputnik>
X-Virus-Scanned: by Amavis (ClamAV) at stro.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: 5768
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: janitor@sternwelten.at
Precedence: bulk
X-list: linux-mips




Patch (against 2.6.8.1) removes unnecessary min/max macros and changes
calls to use kernel.h macros instead.

Since I dont have the hardware those patches are not tested.

Best regards
Veeck

Signed-off-by: Michael Veeck <michael.veeck@gmx.net>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>



---

 linux-2.6.9-rc1-bk7-max/arch/mips/au1000/common/usbdev.c |    2 --
 1 files changed, 2 deletions(-)

diff -puN arch/mips/au1000/common/usbdev.c~min-max-arch_mips_au1000_common_usbdev arch/mips/au1000/common/usbdev.c
--- linux-2.6.9-rc1-bk7/arch/mips/au1000/common/usbdev.c~min-max-arch_mips_au1000_common_usbdev	2004-09-01 19:38:23.000000000 +0200
+++ linux-2.6.9-rc1-bk7-max/arch/mips/au1000/common/usbdev.c	2004-09-01 19:38:23.000000000 +0200
@@ -61,8 +61,6 @@
 #define vdbg(fmt, arg...) do {} while (0)
 #endif
 
-#define MAX(a,b)	(((a)>(b))?(a):(b))
-
 #define ALLOC_FLAGS (in_interrupt () ? GFP_ATOMIC : GFP_KERNEL)
 
 #define EP_FIFO_DEPTH 8

_

From ralf@linux-mips.org Thu Sep  2 11:31:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Sep 2004 11:31:59 +0100 (BST)
Received: from p508B696D.dip.t-dialin.net ([IPv6:::ffff:80.139.105.109]:26936
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225229AbUIBKbz>; Thu, 2 Sep 2004 11:31:55 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i82AVqXI020478;
	Thu, 2 Sep 2004 12:31:52 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i82AVbpx020477;
	Thu, 2 Sep 2004 12:31:37 +0200
Date: Thu, 2 Sep 2004 12:31:37 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Johannes Stezenbach <js@convergence.de>,
	Dominic Sweetman <dom@mips.com>,
	Emmanuel Michon <em@realmagic.fr>, linux-mips@linux-mips.org
Subject: Re: TLB dimensioning
Message-ID: <20040902103137.GB19884@linux-mips.org>
References: <1094033224.20643.1402.camel@nikita.france.sdesigns.com> <16693.52862.859233.198626@doms-laptop.algor.co.uk> <20040902101957.GA7728@convergence.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040902101957.GA7728@convergence.de>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5769
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Sep 02, 2004 at 12:19:57PM +0200, Johannes Stezenbach wrote:

> Hm, the MIPS32 4K Processor Core Family Software User's Manual says:
> 
> "...the 4Kc core contains a 3-entry instruction TLB (ITLB), a 3-entry
> data TLB(DTLB), and a 16 dual-entry joint TLB (JTLB) with variable page
> sizes."
> 
> What exactly does that mean, and how does it rate performancewise?
> I'm just curious ;-)

The idea behind ITLB and DTLB is to enable parallel TLB lookups for
instruction and data translations in ITLB and DTLB yet not having to make
dual or even more ported JTLB.  ITLB and DTLB are entirely managed in
hardware and therefore not visible [1] to the OS software and as such
not part of the architecture; only the JTLB is and it's what's usually
meant when documentation or we on this list are speaking of the TLB.
Probably most MIPS implementations since at least the R4600 had ITLB and
DTLB.

  Ralf

[1] Except possibly during hazards but your supposed to avoid them :-)

From dom@mips.com Thu Sep  2 12:55:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Sep 2004 12:55:18 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:27401 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225237AbUIBLzN>;
	Thu, 2 Sep 2004 12:55:13 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1C2qLg-00012j-00; Thu, 02 Sep 2004 13:05:52 +0100
Received: from olympia.mips.com ([192.168.192.128] helo=boris)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1C2qAg-0000xL-00; Thu, 02 Sep 2004 12:54:31 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16695.2505.44705.24637@mips.com>
Date: Thu, 2 Sep 2004 12:53:45 +0100
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Johannes Stezenbach <js@convergence.de>,
	Dominic Sweetman <dom@mips.com>,
	Emmanuel Michon <em@realmagic.fr>, linux-mips@linux-mips.org
Subject: Re: TLB dimensioning
In-Reply-To: <20040902103137.GB19884@linux-mips.org>
References: <1094033224.20643.1402.camel@nikita.france.sdesigns.com>
	<16693.52862.859233.198626@doms-laptop.algor.co.uk>
	<20040902101957.GA7728@convergence.de>
	<20040902103137.GB19884@linux-mips.org>
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.849, 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: 5770
X-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


Johannes asked

> > "...the 4Kc core contains a 3-entry instruction TLB (ITLB), a 3-entry
> > data TLB(DTLB), and a 16 dual-entry joint TLB (JTLB) with variable page
> > sizes."
> > 
> > What exactly does that mean, and how does it rate performancewise?
> > I'm just curious ;-)

I'd like to believe that if the manual mentions the ITLB and DTLB it
also says, somewhere, what they do...

But as Ralf says they're tiny caches of translation entries,
automatically refilled from the main TLB when required.  They work
faster than the main TLB (being smaller) and prevent translations for
loads/stores getting in the way of translations for instruction
fetches.  Usually there's a mysterious 1-clock extra delay when the
translation you need isn't in the ITLB/DTLB, but it's only one clock
and doesn't happen very often, so the performance effect is usually
somewhere between unmeasurable and tiny.

> Probably most MIPS implementations since at least the R4600 had ITLB
> and DTLB.

Even the very first MIPS architecture chip (R2000) had an I-side
"uTLB".  It had just one entry, but then instructions tend to be
sequential...

--
Dominic Sweetman
MIPS Technologies


From dom@mips.com Thu Sep  2 13:26:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Sep 2004 13:26:52 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:55052 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225237AbUIBM0s>;
	Thu, 2 Sep 2004 13:26:48 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1C2qqL-0001pr-00; Thu, 02 Sep 2004 13:37:33 +0100
Received: from olympia.mips.com ([192.168.192.128] helo=boris)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1C2qfi-0001L1-00; Thu, 02 Sep 2004 13:26:34 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16695.4428.432876.304398@mips.com>
Date: Thu, 2 Sep 2004 13:25:48 +0100
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>, Emmanuel Michon <em@realmagic.fr>,
	linux-mips@linux-mips.org
Subject: Re: TLB dimensioning
In-Reply-To: <20040901233550.GA5721@linux-mips.org>
References: <1094033224.20643.1402.camel@nikita.france.sdesigns.com>
	<16693.52862.859233.198626@doms-laptop.algor.co.uk>
	<20040901233550.GA5721@linux-mips.org>
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.849, 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: 5771
X-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


Ralf Baechle (ralf@linux-mips.org) writes:

> The kernel's performance also relies on TLB performance.
> 
> The wired register is making it easy to test performance of kernel and
> application with a reduced size TLB; maybe I should make that a kernel
> feature.

An excellent suggestion.


From ichinoh@mb.neweb.ne.jp Thu Sep  2 14:17:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Sep 2004 14:17:21 +0100 (BST)
Received: from imfep01.dion.ne.jp ([IPv6:::ffff:210.174.120.145]:20639 "EHLO
	imfep01.dion.ne.jp") by linux-mips.org with ESMTP
	id <S8224834AbUIBNRO>; Thu, 2 Sep 2004 14:17:14 +0100
Received: from mb.neweb.ne.jp ([211.126.90.1]) by imfep01.dion.ne.jp
          (InterMail vM.4.01.03.31 201-229-121-131-20020322) with ESMTP
          id <20040902131709.NBFA1125.imfep01.dion.ne.jp@mb.neweb.ne.jp>
          for <linux-mips@linux-mips.org>; Thu, 2 Sep 2004 22:17:09 +0900
Date: Thu, 2 Sep 2004 22:17:08 +0900
Subject: Re: Reset of USB
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: ichinoh@mb.neweb.ne.jp
To: linux-mips@linux-mips.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <4134F061.5080502@mvista.com>
Message-Id: <649795CC-FCE2-11D8-BFE9-000A956B2316@mb.neweb.ne.jp>
X-Mailer: Apple Mail (2.553)
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: 5772
X-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

Thank you for advice.

I solved by setting up Frequency Control 0 register (FE2, FS2)
and setting 100 to a Clock Source Control register (MIR).

However, in U-BOOT and YAMON,
behavior of a kernel differs about USB-KEYBOARD.

A kernel is started using U-BOOT:
   USB-KEYBOARD is not recognized.

A kernel is started using YAMON:
   USB-KEYBOARD is recognized.

I am investigating this phenomenon now.


---------------- U-BOOT dmesg ---------------------
memsize=67108864
initrd_start=0xa0000000
initrd_size=0
CPU revision is: 02030204
Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 
bytes.
Primary data cache 16kB 4-way, linesize 32 bytes.
Linux version 2.4.21-p4b1 (root@localhost.localdomain) (gcc version 
3.2.3) #1 Wed Sep 1 18:31:23 JST
  2004
AMD Alchemy Au1100/Db1100 Board
Determined physical RAM map:
User-defined physical RAM map:
  memory: 04000000 @ 00000000 (usable)
Initial ramdisk at: 0x802fb000 (819200 bytes)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda2 video=au1100fb:panel:s10,nohwcurs  
mem=67108864 au1000_audio=vra
  usb_ohci=base:0x10100000,len:0x100000,irq:26
au1100fb: Panel 9 800x600_16
calculating r4koff... 003c6de5(3960293)
CPU frequency 396.03 MHz
Console: colour dummy device 80x25
Calibrating delay loop... 395.67 BogoMIPS
Memory: 59976k/65536k available (1809k kernel code, 5560k reserved, 
916k data, 80k init, 0k highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
Console: switching to colour frame buffer device 100x37
fb0: Au1100 LCD frame buffer device
initialize_kbd: Keyboard failed self test
pty: 256 Unix98 ptys configured
keyboard: Timeout - AT keyboard not present?(ed)
keyboard: Timeout - AT keyboard not present?(f4)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
au1000eth.c:1.1 ppopov@mvista.com
eth0: Au1xxx ethernet found at 0xb0500000, irq 28
eth0: No mac address found
eth0: AMD 79C874 10/100 BaseT PHY at phy address 31
eth0: Using AMD 79C874 10/100 BaseT PHY as default
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 50MHz system bus speed for PIO modes; override with 
idebus=xx
ide0: ports already in use, skipping probe
ide1: ports already in use, skipping probe
ide2: ports already in use, skipping probe
ide3: ports already in use, skipping probe
ide4: ports already in use, skipping probe
ide5: ports already in use, skipping probe
Au1000 audio: stevel@mvista.com, built 18:34:06 on Sep  1 2004
Au1000 audio: DAC: DMA0/IRQ6, ADC: DMA1/IRQ7
ac97_codec: AC97 Audio codec, id: 0x8384:0x7652 (SigmaTel STAC9752/53)
Au1000 audio: AC'97 Base/Extended ID = 6a90/0a05
Db1xxx flash: probing 32-bit flash bus
  Amd/Fujitsu Extended Query Table v1.3 at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
Creating 2 MTD partitions on "Db1x00 flash":
0x00000000-0x00e00000 : "User FS"
0x00e00000-0x01000000 : "raw kernel"
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci.c: USB OHCI at membase 0xb0100000, IRQ 26
usb-ohci.c: usb-builtin, non-PCI OHCI
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Serial driver version 1.01 (2001-02-08) with no serial options enabled
ttyS00 at 0xb1100000 (irq = 0) is a 16550
ttyS01 at 0xb1200000 (irq = 1) is a 16550
ttyS02 at 0xb1300000 (irq = 2) is a 16550
ttyS03 at 0xb1400000 (irq = 3) is a 16550
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 800k freed
VFS: Mounted root (ext2 filesystem).
Algorithmics/MIPS FPU Emulator v1.5
hub.c: new USB device builtin-2, assigned address 2
usb.c: USB device not accepting new address=2 (error=-145)
Linux Kernel Card Services 3.1.22
   options:  [pci]

Au1x00 PCMCIA (CS release 3.1.22)
hub.c: new USB device builtin-2, assigned address 3
usb.c: USB device not accepting new address=3 (error=-145)
eth0: link up
eth0: going to full duplex
Trying to free nonexistent resource <c0010000-c001000f>
hda: HMS360404D5CF00, CFA DISK drive
ide1: ports already in use, skipping probe
ide2: ports already in use, skipping probe
ide3: ports already in use, skipping probe
ide4: ports already in use, skipping probe
ide5: ports already in use, skipping probe
ide0 at 0xc0010000-0xc0010007,0xc001000e on irq 34
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
hda: 7999488 sectors (4096 MB) w/128KiB Cache, CHS=7936/16/63
Partition check:
  hda:<6> [PTBL] [992/128/63] hda1 hda2 hda3
ide_cs: hda: Vcc = 3.3, Vpp = 0.0
  hda: hda1 hda2 hda3
  hda: hda1 hda2 hda3
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Trying to move old root to /initrd ... okay
Freeing unused kernel memory: 80k freed
EXT3-fs warning: maximal mount count reached, running e2fsck is 
recommended
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal

----------------- YAMON dmesg ---------------------
CPU revision is: 02030204
Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 
bytes.
Primary data cache 16kB 4-way, linesize 32 bytes.
Linux version 2.4.21-p4b1 (root@localhost.localdomain) (gcc version 
3.2.3) #1 Fri Aug 27 22:45:11 JS
T 2004
AMD Alchemy Au1100/Db1100 Board
Determined physical RAM map:
  memory: 04000000 @ 00000000 (usable)
Initial ramdisk at: 0x802fb000 (819200 bytes)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda2 video=au1100fb:panel:s10,nohwcurs 
au1000_audio=vra usb_ohci=base
:0x10100000,len:0x100000,irq:26
au1100fb: Panel 6 NEON_640x480_16
calculating r4koff... 003c6de6(3960294)
CPU frequency 396.03 MHz
Console: colour dummy device 80x25
Calibrating delay loop... 395.67 BogoMIPS
Memory: 59976k/65536k available (1809k kernel code, 5560k reserved, 
916k data, 80k init, 0k highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
Console: switching to colour frame buffer device 100x37
fb0: Au1100 LCD frame buffer device
initialize_kbd: Keyboard failed self test
pty: 256 Unix98 ptys configured
keyboard: Timeout - AT keyboard not present?(ed)
keyboard: Timeout - AT keyboard not present?(f4)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
au1000eth.c:1.1 ppopov@mvista.com
eth0: Au1xxx ethernet found at 0xb0500000, irq 28
eth0: AMD 79C874 10/100 BaseT PHY at phy address 31
eth0: Using AMD 79C874 10/100 BaseT PHY as default
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 50MHz system bus speed for PIO modes; override with 
idebus=xx
ide0: ports already in use, skipping probe
ide1: ports already in use, skipping probe
ide2: ports already in use, skipping probe
ide3: ports already in use, skipping probe
ide4: ports already in use, skipping probe
ide5: ports already in use, skipping probe
Au1000 audio: stevel@mvista.com, built 22:47:51 on Aug 27 2004
Au1000 audio: DAC: DMA0/IRQ6, ADC: DMA1/IRQ7
ac97_codec: AC97 Audio codec, id: 0x8384:0x7652 (SigmaTel STAC9752/53)
Au1000 audio: AC'97 Base/Extended ID = 6a90/0a05
Db1xxx flash: probing 32-bit flash bus
  Amd/Fujitsu Extended Query Table v1.3 at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
Creating 2 MTD partitions on "Db1x00 flash":
0x00000000-0x00e00000 : "User FS"
0x00e00000-0x01000000 : "raw kernel"
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci.c: USB OHCI at membase 0xb0100000, IRQ 26
usb-ohci.c: usb-builtin, non-PCI OHCI
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Serial driver version 1.01 (2001-02-08) with no serial options enabled
ttyS00 at 0xb1100000 (irq = 0) is a 16550
ttyS01 at 0xb1200000 (irq = 1) is a 16550
ttyS02 at 0xb1300000 (irq = 2) is a 16550
ttyS03 at 0xb1400000 (irq = 3) is a 16550
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 800k freed
VFS: Mounted root (ext2 filesystem).
Algorithmics/MIPS FPU Emulator v1.5
hub.c: new USB device builtin-2, assigned address 2
input0: USB HID v1.00 Keyboard [  USB Multimedia Keyboard ] on usb1:2.0
input1: USB HID v1.00 Pointer [  USB Multimedia Keyboard ] on usb1:2.1
Linux Kernel Card Services 3.1.22
   options:  [pci]

Au1x00 PCMCIA (CS release 3.1.22)
eth0: link up
eth0: going to full duplex
Trying to free nonexistent resource <c0010000-c001000f>
hda: HMS360404D5CF00, CFA DISK drive
ide1: ports already in use, skipping probe
ide2: ports already in use, skipping probe
ide3: ports already in use, skipping probe
ide4: ports already in use, skipping probe
ide5: ports already in use, skipping probe
ide0 at 0xc0010000-0xc0010007,0xc001000e on irq 34
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
hda: 7999488 sectors (4096 MB) w/128KiB Cache, CHS=7936/16/63
Partition check:
  hda:<6> [PTBL] [992/128/63] hda1 hda2 hda3
ide_cs: hda: Vcc = 3.3, Vpp = 0.0
  hda: hda1 hda2 hda3
  hda: hda1 hda2 hda3
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Trying to move old root to /initrd ... okay
Freeing unused kernel memory: 80k freed
EXT3-fs warning: maximal mount count reached, running e2fsck is 
recommended
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal

Nyauyama

On 2004.9.1, at 06:40  AM, Pete Popov wrote:

> ichinoh@mb.neweb.ne.jp wrote:
>
>> Hello ,
>>
>> I invoked the Linux kernel on ALCHEMY DBAU1100 by U-BOOT.
>>
>> The processing which resets USB-OHCI of the head of a kernel is not 
>> completed. (refer to *)
>>
>> Au1100 does not indicate "reset is completed."
>> Is this phenomenon experienced?
>>
>> In addition,
>> this phenomenon is not encountered when starting a kernel by YAMON.
>
> Yamon initializes the CPU and then Linux doesn't have to touch too 
> many registers. I'm guessing u-boot doesn't setup the clocking 
> correctly, or at all, and that might be your problem. The Yamon code 
> for these boards is available and it's easy to read the initialization 
> code.  Take a look at it and that should solve your problem.
>
> Pete
>
>>
>>
>> *:
>> arch/mips/au1000/common/setup.c
>>
>> #ifdef CONFIG_USB_OHCI
>>     // enable host controller and wait for reset done
>>     au_writel(0x08, USB_HOST_CONFIG);
>>     udelay(1000);
>>     au_writel(0x0E, USB_HOST_CONFIG);
>>     udelay(1000);
>>     au_readl(USB_HOST_CONFIG); // throw away first read
>>     while (!(au_readl(USB_HOST_CONFIG) & 0x10))
>>         au_readl(USB_HOST_CONFIG);
>> #endif
>>
>> Best regards,
>> Nyauyama
>>
>>
>


From ppopov@mvista.com Thu Sep  2 18:49:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Sep 2004 18:49:56 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:10484 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225253AbUIBRtu>;
	Thu, 2 Sep 2004 18:49:50 +0100
Received: from [10.0.10.221] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA18755;
	Thu, 2 Sep 2004 10:49:38 -0700
Message-ID: <41375D32.2050808@mvista.com>
Date: Thu, 02 Sep 2004 10:49:38 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ichinoh@mb.neweb.ne.jp
CC: linux-mips@linux-mips.org
Subject: Re: Reset of USB
References: <649795CC-FCE2-11D8-BFE9-000A956B2316@mb.neweb.ne.jp>
In-Reply-To: <649795CC-FCE2-11D8-BFE9-000A956B2316@mb.neweb.ne.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5773
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

ichinoh@mb.neweb.ne.jp wrote:

> Thank you for advice.
>
> I solved by setting up Frequency Control 0 register (FE2, FS2)
> and setting 100 to a Clock Source Control register (MIR).
>
> However, in U-BOOT and YAMON,
> behavior of a kernel differs about USB-KEYBOARD.
>
> A kernel is started using U-BOOT:
>   USB-KEYBOARD is not recognized.
>
> A kernel is started using YAMON:
>   USB-KEYBOARD is recognized.
>
> I am investigating this phenomenon now.

I can't tell without the manual in front of me what it means to write 
100 to the clock source control reg, so I can't tell if you're setting 
the right frequency. If I remember correctly, you need the clock to be 
48MHz. Use the values that yamon is using that should do it. Also, there 
are multi-use pins that need to be set appropriately. I don't remember 
if everything was set in Linux or if we allowed yamon to do it. Finally, 
if you get all the software right and it's still not working, check the 
hardware design as well :)

Pete


>
>
> ---------------- U-BOOT dmesg ---------------------
> memsize=67108864
> initrd_start=0xa0000000
> initrd_size=0
> CPU revision is: 02030204
> Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 
> bytes.
> Primary data cache 16kB 4-way, linesize 32 bytes.
> Linux version 2.4.21-p4b1 (root@localhost.localdomain) (gcc version 
> 3.2.3) #1 Wed Sep 1 18:31:23 JST
>  2004
> AMD Alchemy Au1100/Db1100 Board
> Determined physical RAM map:
> User-defined physical RAM map:
>  memory: 04000000 @ 00000000 (usable)
> Initial ramdisk at: 0x802fb000 (819200 bytes)
> On node 0 totalpages: 16384
> zone(0): 16384 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: root=/dev/hda2 video=au1100fb:panel:s10,nohwcurs  
> mem=67108864 au1000_audio=vra
>  usb_ohci=base:0x10100000,len:0x100000,irq:26
> au1100fb: Panel 9 800x600_16
> calculating r4koff... 003c6de5(3960293)
> CPU frequency 396.03 MHz
> Console: colour dummy device 80x25
> Calibrating delay loop... 395.67 BogoMIPS
> Memory: 59976k/65536k available (1809k kernel code, 5560k reserved, 
> 916k data, 80k init, 0k highmem)
> Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
> Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
> Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Checking for 'wait' instruction...  available.
> POSIX conformance testing by UNIFIX
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Starting kswapd
> Journalled Block Device driver loaded
> Console: switching to colour frame buffer device 100x37
> fb0: Au1100 LCD frame buffer device
> initialize_kbd: Keyboard failed self test
> pty: 256 Unix98 ptys configured
> keyboard: Timeout - AT keyboard not present?(ed)
> keyboard: Timeout - AT keyboard not present?(f4)
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> au1000eth.c:1.1 ppopov@mvista.com
> eth0: Au1xxx ethernet found at 0xb0500000, irq 28
> eth0: No mac address found
> eth0: AMD 79C874 10/100 BaseT PHY at phy address 31
> eth0: Using AMD 79C874 10/100 BaseT PHY as default
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
> ide: Assuming 50MHz system bus speed for PIO modes; override with 
> idebus=xx
> ide0: ports already in use, skipping probe
> ide1: ports already in use, skipping probe
> ide2: ports already in use, skipping probe
> ide3: ports already in use, skipping probe
> ide4: ports already in use, skipping probe
> ide5: ports already in use, skipping probe
> Au1000 audio: stevel@mvista.com, built 18:34:06 on Sep  1 2004
> Au1000 audio: DAC: DMA0/IRQ6, ADC: DMA1/IRQ7
> ac97_codec: AC97 Audio codec, id: 0x8384:0x7652 (SigmaTel STAC9752/53)
> Au1000 audio: AC'97 Base/Extended ID = 6a90/0a05
> Db1xxx flash: probing 32-bit flash bus
>  Amd/Fujitsu Extended Query Table v1.3 at 0x0040
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling fast programming due to code brokenness.
> Creating 2 MTD partitions on "Db1x00 flash":
> 0x00000000-0x00e00000 : "User FS"
> 0x00e00000-0x01000000 : "raw kernel"
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> usb-ohci.c: USB OHCI at membase 0xb0100000, IRQ 26
> usb-ohci.c: usb-builtin, non-PCI OHCI
> usb.c: new USB bus registered, assigned bus number 1
> hub.c: USB hub found
> hub.c: 2 ports detected
> usb.c: registered new driver hid
> hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
> hid-core.c: USB HID support drivers
> mice: PS/2 mouse device common for all mice
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 4096 bind 8192)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Serial driver version 1.01 (2001-02-08) with no serial options enabled
> ttyS00 at 0xb1100000 (irq = 0) is a 16550
> ttyS01 at 0xb1200000 (irq = 1) is a 16550
> ttyS02 at 0xb1300000 (irq = 2) is a 16550
> ttyS03 at 0xb1400000 (irq = 3) is a 16550
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 800k freed
> VFS: Mounted root (ext2 filesystem).
> Algorithmics/MIPS FPU Emulator v1.5
> hub.c: new USB device builtin-2, assigned address 2
> usb.c: USB device not accepting new address=2 (error=-145)
> Linux Kernel Card Services 3.1.22
>   options:  [pci]
>
> Au1x00 PCMCIA (CS release 3.1.22)
> hub.c: new USB device builtin-2, assigned address 3
> usb.c: USB device not accepting new address=3 (error=-145)
> eth0: link up
> eth0: going to full duplex
> Trying to free nonexistent resource <c0010000-c001000f>
> hda: HMS360404D5CF00, CFA DISK drive
> ide1: ports already in use, skipping probe
> ide2: ports already in use, skipping probe
> ide3: ports already in use, skipping probe
> ide4: ports already in use, skipping probe
> ide5: ports already in use, skipping probe
> ide0 at 0xc0010000-0xc0010007,0xc001000e on irq 34
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: 7999488 sectors (4096 MB) w/128KiB Cache, CHS=7936/16/63
> Partition check:
>  hda:<6> [PTBL] [992/128/63] hda1 hda2 hda3
> ide_cs: hda: Vcc = 3.3, Vpp = 0.0
>  hda: hda1 hda2 hda3
>  hda: hda1 hda2 hda3
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem) readonly.
> Trying to move old root to /initrd ... okay
> Freeing unused kernel memory: 80k freed
> EXT3-fs warning: maximal mount count reached, running e2fsck is 
> recommended
> EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal
>
> ----------------- YAMON dmesg ---------------------
> CPU revision is: 02030204
> Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 
> bytes.
> Primary data cache 16kB 4-way, linesize 32 bytes.
> Linux version 2.4.21-p4b1 (root@localhost.localdomain) (gcc version 
> 3.2.3) #1 Fri Aug 27 22:45:11 JS
> T 2004
> AMD Alchemy Au1100/Db1100 Board
> Determined physical RAM map:
>  memory: 04000000 @ 00000000 (usable)
> Initial ramdisk at: 0x802fb000 (819200 bytes)
> On node 0 totalpages: 16384
> zone(0): 16384 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: root=/dev/hda2 video=au1100fb:panel:s10,nohwcurs 
> au1000_audio=vra usb_ohci=base
> :0x10100000,len:0x100000,irq:26
> au1100fb: Panel 6 NEON_640x480_16
> calculating r4koff... 003c6de6(3960294)
> CPU frequency 396.03 MHz
> Console: colour dummy device 80x25
> Calibrating delay loop... 395.67 BogoMIPS
> Memory: 59976k/65536k available (1809k kernel code, 5560k reserved, 
> 916k data, 80k init, 0k highmem)
> Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
> Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
> Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Checking for 'wait' instruction...  available.
> POSIX conformance testing by UNIFIX
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Starting kswapd
> Journalled Block Device driver loaded
> Console: switching to colour frame buffer device 100x37
> fb0: Au1100 LCD frame buffer device
> initialize_kbd: Keyboard failed self test
> pty: 256 Unix98 ptys configured
> keyboard: Timeout - AT keyboard not present?(ed)
> keyboard: Timeout - AT keyboard not present?(f4)
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> au1000eth.c:1.1 ppopov@mvista.com
> eth0: Au1xxx ethernet found at 0xb0500000, irq 28
> eth0: AMD 79C874 10/100 BaseT PHY at phy address 31
> eth0: Using AMD 79C874 10/100 BaseT PHY as default
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
> ide: Assuming 50MHz system bus speed for PIO modes; override with 
> idebus=xx
> ide0: ports already in use, skipping probe
> ide1: ports already in use, skipping probe
> ide2: ports already in use, skipping probe
> ide3: ports already in use, skipping probe
> ide4: ports already in use, skipping probe
> ide5: ports already in use, skipping probe
> Au1000 audio: stevel@mvista.com, built 22:47:51 on Aug 27 2004
> Au1000 audio: DAC: DMA0/IRQ6, ADC: DMA1/IRQ7
> ac97_codec: AC97 Audio codec, id: 0x8384:0x7652 (SigmaTel STAC9752/53)
> Au1000 audio: AC'97 Base/Extended ID = 6a90/0a05
> Db1xxx flash: probing 32-bit flash bus
>  Amd/Fujitsu Extended Query Table v1.3 at 0x0040
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling fast programming due to code brokenness.
> Creating 2 MTD partitions on "Db1x00 flash":
> 0x00000000-0x00e00000 : "User FS"
> 0x00e00000-0x01000000 : "raw kernel"
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> usb-ohci.c: USB OHCI at membase 0xb0100000, IRQ 26
> usb-ohci.c: usb-builtin, non-PCI OHCI
> usb.c: new USB bus registered, assigned bus number 1
> hub.c: USB hub found
> hub.c: 2 ports detected
> usb.c: registered new driver hid
> hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
> hid-core.c: USB HID support drivers
> mice: PS/2 mouse device common for all mice
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 4096 bind 8192)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Serial driver version 1.01 (2001-02-08) with no serial options enabled
> ttyS00 at 0xb1100000 (irq = 0) is a 16550
> ttyS01 at 0xb1200000 (irq = 1) is a 16550
> ttyS02 at 0xb1300000 (irq = 2) is a 16550
> ttyS03 at 0xb1400000 (irq = 3) is a 16550
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 800k freed
> VFS: Mounted root (ext2 filesystem).
> Algorithmics/MIPS FPU Emulator v1.5
> hub.c: new USB device builtin-2, assigned address 2
> input0: USB HID v1.00 Keyboard [  USB Multimedia Keyboard ] on usb1:2.0
> input1: USB HID v1.00 Pointer [  USB Multimedia Keyboard ] on usb1:2.1
> Linux Kernel Card Services 3.1.22
>   options:  [pci]
>
> Au1x00 PCMCIA (CS release 3.1.22)
> eth0: link up
> eth0: going to full duplex
> Trying to free nonexistent resource <c0010000-c001000f>
> hda: HMS360404D5CF00, CFA DISK drive
> ide1: ports already in use, skipping probe
> ide2: ports already in use, skipping probe
> ide3: ports already in use, skipping probe
> ide4: ports already in use, skipping probe
> ide5: ports already in use, skipping probe
> ide0 at 0xc0010000-0xc0010007,0xc001000e on irq 34
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: 7999488 sectors (4096 MB) w/128KiB Cache, CHS=7936/16/63
> Partition check:
>  hda:<6> [PTBL] [992/128/63] hda1 hda2 hda3
> ide_cs: hda: Vcc = 3.3, Vpp = 0.0
>  hda: hda1 hda2 hda3
>  hda: hda1 hda2 hda3
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem) readonly.
> Trying to move old root to /initrd ... okay
> Freeing unused kernel memory: 80k freed
> EXT3-fs warning: maximal mount count reached, running e2fsck is 
> recommended
> EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal
>
> Nyauyama
>
> On 2004.9.1, at 06:40  AM, Pete Popov wrote:
>
>> ichinoh@mb.neweb.ne.jp wrote:
>>
>>> Hello ,
>>>
>>> I invoked the Linux kernel on ALCHEMY DBAU1100 by U-BOOT.
>>>
>>> The processing which resets USB-OHCI of the head of a kernel is not 
>>> completed. (refer to *)
>>>
>>> Au1100 does not indicate "reset is completed."
>>> Is this phenomenon experienced?
>>>
>>> In addition,
>>> this phenomenon is not encountered when starting a kernel by YAMON.
>>
>>
>> Yamon initializes the CPU and then Linux doesn't have to touch too 
>> many registers. I'm guessing u-boot doesn't setup the clocking 
>> correctly, or at all, and that might be your problem. The Yamon code 
>> for these boards is available and it's easy to read the 
>> initialization code.  Take a look at it and that should solve your 
>> problem.
>>
>> Pete
>>
>>>
>>>
>>> *:
>>> arch/mips/au1000/common/setup.c
>>>
>>> #ifdef CONFIG_USB_OHCI
>>>     // enable host controller and wait for reset done
>>>     au_writel(0x08, USB_HOST_CONFIG);
>>>     udelay(1000);
>>>     au_writel(0x0E, USB_HOST_CONFIG);
>>>     udelay(1000);
>>>     au_readl(USB_HOST_CONFIG); // throw away first read
>>>     while (!(au_readl(USB_HOST_CONFIG) & 0x10))
>>>         au_readl(USB_HOST_CONFIG);
>>> #endif
>>>
>>> Best regards,
>>> Nyauyama
>>>
>>>
>>
>
>


From max@stro.at Thu Sep  2 20:27:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Sep 2004 20:27:44 +0100 (BST)
Received: from baikonur.stro.at ([IPv6:::ffff:213.239.196.228]:30086 "EHLO
	baikonur.stro.at") by linux-mips.org with ESMTP id <S8225253AbUIBT1b>;
	Thu, 2 Sep 2004 20:27:31 +0100
Received: from localhost (localhost [127.0.0.1])
	by baikonur.stro.at (Postfix) with ESMTP id 717865C065;
	Thu,  2 Sep 2004 21:27:28 +0200 (CEST)
Received: from baikonur.stro.at ([127.0.0.1])
	by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 32735-09; Thu, 2 Sep 2004 21:27:27 +0200 (CEST)
Received: from sputnik (M802P011.adsl.highway.telekom.at [62.47.132.43])
	by baikonur.stro.at (Postfix) with ESMTP id C79AD5C008;
	Thu,  2 Sep 2004 21:27:27 +0200 (CEST)
Received: from max by sputnik with local (Exim 4.34)
	id 1C2xF3-0003OO-5x; Thu, 02 Sep 2004 21:27:29 +0200
Date: Thu, 2 Sep 2004 21:27:29 +0200
From: maximilian attems <janitor@sternwelten.at>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch 1/1]  minmax-removal 	arch/mips/au1000/common/usbdev.c
Message-ID: <20040902192729.GF1894@stro.at>
References: <E1C2ceP-0000Me-GX@sputnik> <20040902103407.GC19884@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040902103407.GC19884@linux-mips.org>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by Amavis (ClamAV) at stro.at
Return-Path: <max@stro.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: 5774
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: janitor@sternwelten.at
Precedence: bulk
X-list: linux-mips

On Thu, 02 Sep 2004, Ralf Baechle wrote:

> On Wed, Sep 01, 2004 at 11:28:17PM +0200, janitor@sternwelten.at wrote:
> 
> > Patch (against 2.6.8.1) removes unnecessary min/max macros and changes
> > calls to use kernel.h macros instead.
> 
> The patch description isn't really right here; the MAX macro in
> arch/mips/au1000/common/usbdev.c was unused so removing it was a
> nobrainer.

you are right,
sorry it was one of a bigger list of MIN/MAX conversions.
that's no excuse, i'll better double check next time.
 
> > Since I dont have the hardware those patches are not tested.
> 
> I guess that's excusable in this case ;-)

thanks.

--
maks
kernel janitor  	http://janitor.kernelnewbies.org/


From rth@redhat.com Fri Sep  3 07:53:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 07:53:45 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:3226 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8224901AbUICGxk>;
	Fri, 3 Sep 2004 07:53:40 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i836rFl3006377;
	Fri, 3 Sep 2004 02:53:16 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i836rX728520;
	Fri, 3 Sep 2004 02:53:33 -0400
Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i836rWV03391;
	Thu, 2 Sep 2004 23:53:32 -0700
Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1])
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i836rWOo022398;
	Thu, 2 Sep 2004 23:53:32 -0700
Received: (from rth@localhost)
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i836rVio022344;
	Thu, 2 Sep 2004 23:53:31 -0700
X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f
Date: Thu, 2 Sep 2004 23:53:31 -0700
From: Richard Henderson <rth@redhat.com>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
Message-ID: <20040903065331.GG20559@redhat.com>
Mail-Followup-To: Richard Henderson <rth@redhat.com>,
	Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
References: <87acxcbxfl.fsf@redhat.com> <410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com> <410F60DF.9020400@mips.com> <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl> <87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com> <87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com> <87eklnw0g7.fsf@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87eklnw0g7.fsf@redhat.com>
User-Agent: Mutt/1.4.1i
Return-Path: <rth@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: 5775
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rth@redhat.com
Precedence: bulk
X-list: linux-mips

On Tue, Aug 31, 2004 at 08:51:20PM +0100, Richard Sandiford wrote:
> int TARGET_SHIFT_TRUNCATION_MASK (enum machine_mode MODE)
...
>      Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does
>      _not_ apply to general shift rtxes; it applies only to instructions
>      that are generated by the named shift patterns.

I'm not particularly thrilled about this notion.  I'd much prefer a
target hook that could replace SHIFT_COUNT_TRUNCATED.  How often are
the named patterns going to differ from the rtxes anyway?


r~

From rsandifo@redhat.com Fri Sep  3 08:05:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 08:05:31 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:43991 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224931AbUICHF0>;
	Fri, 3 Sep 2004 08:05:26 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i8375NS0019534;
	Fri, 3 Sep 2004 03:05:23 -0400
Received: from localhost (mail@vpnuser5.surrey.redhat.com [172.16.9.5])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8375G323045;
	Fri, 3 Sep 2004 03:05:16 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1C388J-0000EU-00; Fri, 03 Sep 2004 08:05:15 +0100
To: Richard Henderson <rth@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <87acxcbxfl.fsf@redhat.com> <410F5964.3010109@mips.com>
	<876580bm2e.fsf@redhat.com> <410F60DF.9020400@mips.com>
	<Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
	<87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com>
	<87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com>
	<87eklnw0g7.fsf@redhat.com> <20040903065331.GG20559@redhat.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Fri, 03 Sep 2004 08:05:15 +0100
In-Reply-To: <20040903065331.GG20559@redhat.com> (Richard Henderson's
 message of "Thu, 2 Sep 2004 23:53:31 -0700")
Message-ID: <87sm9zg7dg.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: 5776
X-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

Richard Henderson <rth@redhat.com> writes:
> On Tue, Aug 31, 2004 at 08:51:20PM +0100, Richard Sandiford wrote:
>> int TARGET_SHIFT_TRUNCATION_MASK (enum machine_mode MODE)
> ...
>>      Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does
>>      _not_ apply to general shift rtxes; it applies only to instructions
>>      that are generated by the named shift patterns.
>
> I'm not particularly thrilled about this notion.  I'd much prefer a
> target hook that could replace SHIFT_COUNT_TRUNCATED.  How often are
> the named patterns going to differ from the rtxes anyway?

Well, the problem is that SHIFT_COUNT_TRUNCATED applies to all shift
rtxes, including those synthesised by things like combine.c:expand_
compound_operation().  I assume that's why SHIFT_COUNT_TRUNCATED is
documented as follows:

     A C expression that is nonzero if on this machine the number of bits
     actually used for the count of a shift operation is equal to the number
     of bits needed to represent the size of the object being shifted.  When
     this macro is nonzero, the compiler will assume that it is safe to omit
     a sign-extend, zero-extend, and certain bitwise `and' instructions that
     truncates the count of a shift operation.  On machines that have
     instructions that act on bit-fields at variable positions, which may
     include `bit test' instructions, a nonzero @code{SHIFT_COUNT_TRUNCATED}
     also enables deletion of truncations of the values that serve as
     arguments to bit-field instructions.

     If both types of instructions truncate the count (for shifts) and
     position (for bit-field operations), or if no variable-position bit-field
     instructions exist, you should define this macro.

     However, on some machines, such as the 80386 and the 680x0, truncation
     only applies to shift operations and not the (real or pretended)
     bit-field operations.  Define @code{SHIFT_COUNT_TRUNCATED} to be zero on
     such machines.  Instead, add patterns to the @file{md} file that include
     the implied truncation of the shift instructions.

I was deliberately trying to avoid this fuzziness with the new target hook.

E.g., if it ever becomes useful to know that ashlsi3 truncates on x86,
then it will be possible to use the new hook there too, even though the
requirements of S_C_T aren't met.

Richard

From rth@redhat.com Fri Sep  3 08:09:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 08:09:11 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:38299 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8224931AbUICHJH>;
	Fri, 3 Sep 2004 08:09:07 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i8378gl3007429;
	Fri, 3 Sep 2004 03:08:43 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i83790728863;
	Fri, 3 Sep 2004 03:09:00 -0400
Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i8378xV04025;
	Fri, 3 Sep 2004 00:08:59 -0700
Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1])
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i8378xOo001458;
	Fri, 3 Sep 2004 00:08:59 -0700
Received: (from rth@localhost)
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i8378xDM001443;
	Fri, 3 Sep 2004 00:08:59 -0700
X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f
Date: Fri, 3 Sep 2004 00:08:58 -0700
From: Richard Henderson <rth@redhat.com>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
Message-ID: <20040903070858.GA24082@redhat.com>
Mail-Followup-To: Richard Henderson <rth@redhat.com>,
	Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
References: <876580bm2e.fsf@redhat.com> <410F60DF.9020400@mips.com> <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl> <87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com> <87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com> <87eklnw0g7.fsf@redhat.com> <20040903065331.GG20559@redhat.com> <87sm9zg7dg.fsf@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87sm9zg7dg.fsf@redhat.com>
User-Agent: Mutt/1.4.1i
Return-Path: <rth@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: 5777
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rth@redhat.com
Precedence: bulk
X-list: linux-mips

On Fri, Sep 03, 2004 at 08:05:15AM +0100, Richard Sandiford wrote:
>      However, on some machines, such as the 80386 and the 680x0, truncation
>      only applies to shift operations and not the (real or pretended)
>      bit-field operations.  Define @code{SHIFT_COUNT_TRUNCATED} to be zero on
>      such machines.  Instead, add patterns to the @file{md} file that include
>      the implied truncation of the shift instructions.
> 
> I was deliberately trying to avoid this fuzziness with the new target hook.

Hmm.  I suppose we could pass the shift operation in there; 
ASHIFT, LSHIFT, ZERO_EXTRACT, SIGN_EXTRACT.


r~

From rsandifo@redhat.com Fri Sep  3 08:11:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 08:12:01 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:21210 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224931AbUICHL5>;
	Fri, 3 Sep 2004 08:11:57 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i837BuS0021027;
	Fri, 3 Sep 2004 03:11:56 -0400
Received: from localhost (mail@vpnuser5.surrey.redhat.com [172.16.9.5])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i837Bm324951;
	Fri, 3 Sep 2004 03:11:48 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1C38Ed-0000Eh-00; Fri, 03 Sep 2004 08:11:47 +0100
To: Richard Henderson <rth@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <876580bm2e.fsf@redhat.com> <410F60DF.9020400@mips.com>
	<Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
	<87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com>
	<87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com>
	<87eklnw0g7.fsf@redhat.com> <20040903065331.GG20559@redhat.com>
	<87sm9zg7dg.fsf@redhat.com> <20040903070858.GA24082@redhat.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Fri, 03 Sep 2004 08:11:47 +0100
In-Reply-To: <20040903070858.GA24082@redhat.com> (Richard Henderson's
 message of "Fri, 3 Sep 2004 00:08:58 -0700")
Message-ID: <87oekng72k.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: 5778
X-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

Richard Henderson <rth@redhat.com> writes:
> On Fri, Sep 03, 2004 at 08:05:15AM +0100, Richard Sandiford wrote:
>>      However, on some machines, such as the 80386 and the 680x0, truncation
>>      only applies to shift operations and not the (real or pretended)
>>      bit-field operations.  Define @code{SHIFT_COUNT_TRUNCATED} to be zero on
>>      such machines.  Instead, add patterns to the @file{md} file that include
>>      the implied truncation of the shift instructions.
>> 
>> I was deliberately trying to avoid this fuzziness with the new target hook.
>
> Hmm.  I suppose we could pass the shift operation in there; 
> ASHIFT, LSHIFT, ZERO_EXTRACT, SIGN_EXTRACT.

But the point as I understand it is that the generic optimisers
(e.g. simplify-rtx.c) can't tell the difference between an ASHIFT
that came from an (ashift ...) in the instruction stream or from
something that was generated artificially by expand_compound_operation.

Richard

From rth@redhat.com Fri Sep  3 08:20:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 08:20:22 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:63644 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8224931AbUICHUS>;
	Fri, 3 Sep 2004 08:20:18 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i837Jrl3008339;
	Fri, 3 Sep 2004 03:19:53 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i837KB729192;
	Fri, 3 Sep 2004 03:20:11 -0400
Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i837KAV04404;
	Fri, 3 Sep 2004 00:20:10 -0700
Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1])
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i837KAOo032191;
	Fri, 3 Sep 2004 00:20:10 -0700
Received: (from rth@localhost)
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i837KA2i032188;
	Fri, 3 Sep 2004 00:20:10 -0700
X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f
Date: Fri, 3 Sep 2004 00:20:10 -0700
From: Richard Henderson <rth@redhat.com>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
Message-ID: <20040903072010.GD24082@redhat.com>
Mail-Followup-To: Richard Henderson <rth@redhat.com>,
	Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
References: <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl> <87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com> <87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com> <87eklnw0g7.fsf@redhat.com> <20040903065331.GG20559@redhat.com> <87sm9zg7dg.fsf@redhat.com> <20040903070858.GA24082@redhat.com> <87oekng72k.fsf@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87oekng72k.fsf@redhat.com>
User-Agent: Mutt/1.4.1i
Return-Path: <rth@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: 5779
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rth@redhat.com
Precedence: bulk
X-list: linux-mips

On Fri, Sep 03, 2004 at 08:11:47AM +0100, Richard Sandiford wrote:
> But the point as I understand it is that the generic optimisers
> (e.g. simplify-rtx.c) can't tell the difference between an ASHIFT
> that came from an (ashift ...) in the instruction stream or from
> something that was generated artificially by expand_compound_operation.

That would be a bug in expand_compound_operation, I would think.

The alternative is to not add your new hook and do what you can
with the existing SHIFT_COUNT_TRUNCATED macro.  Which I recommend
that you do; I don't think you really want to have the shift bits
dependent on a cleanup / infrastructure change of this scale.



r~

From rsandifo@redhat.com Fri Sep  3 08:29:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 08:29:49 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:32225 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224952AbUICH3o>;
	Fri, 3 Sep 2004 08:29:44 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i837ThS0024900;
	Fri, 3 Sep 2004 03:29:43 -0400
Received: from localhost (mail@vpnuser5.surrey.redhat.com [172.16.9.5])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i837Tf327840;
	Fri, 3 Sep 2004 03:29:41 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1C38Vv-0000H9-00; Fri, 03 Sep 2004 08:29:39 +0100
To: Richard Henderson <rth@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
	<87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com>
	<87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com>
	<87eklnw0g7.fsf@redhat.com> <20040903065331.GG20559@redhat.com>
	<87sm9zg7dg.fsf@redhat.com> <20040903070858.GA24082@redhat.com>
	<87oekng72k.fsf@redhat.com> <20040903072010.GD24082@redhat.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Fri, 03 Sep 2004 08:29:39 +0100
In-Reply-To: <20040903072010.GD24082@redhat.com> (Richard Henderson's
 message of "Fri, 3 Sep 2004 00:20:10 -0700")
Message-ID: <87k6vbg68s.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: 5780
X-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

Richard Henderson <rth@redhat.com> writes:
> On Fri, Sep 03, 2004 at 08:11:47AM +0100, Richard Sandiford wrote:
>> But the point as I understand it is that the generic optimisers
>> (e.g. simplify-rtx.c) can't tell the difference between an ASHIFT
>> that came from an (ashift ...) in the instruction stream or from
>> something that was generated artificially by expand_compound_operation.
>
> That would be a bug in expand_compound_operation, I would think.
>
> The alternative is to not add your new hook and do what you can
> with the existing SHIFT_COUNT_TRUNCATED macro.  Which I recommend
> that you do; I don't think you really want to have the shift bits
> dependent on a cleanup / infrastructure change of this scale.

FWIW, that's what my original patch did:

    http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00461.html   

The patch I posted this week was in response to the request for
wider-ranging target support:

    http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00606.html

But because it depended on S_C_T, the original patch produced much
worse code for ARM than the new one does.

Is the new target hook really that invasive?  It doesn't affect any
other code as such.

The only change not directly related to the optabs expansion was the
simplify-rtx.c thing, and like I said in my covering message, I think
that code's bogus anyway:

    This seems pretty dubious anyway.  What if a define_expand in the backend
    uses shifts to implement a complex named pattern?  I'd have thought the
    backend would be free to use target-specific knowledge about what that
    shift does with out-of-range values.  And if we are later able to
    constant-fold the result, the code above might not do what the
    target machine would do.

To be honest, I'd still like to apply that hunk even if we go back to S_C_T.

Richard

From xuhaoz@neonetech.com Fri Sep  3 09:57:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 09:57:22 +0100 (BST)
Received: from [IPv6:::ffff:211.155.249.251] ([IPv6:::ffff:211.155.249.251]:62225
	"EHLO nnt.neonetech.com") by linux-mips.org with ESMTP
	id <S8225005AbUICI5S>; Fri, 3 Sep 2004 09:57:18 +0100
Received: from wbar1 ([221.219.28.147]) by nnt.neonetech.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 3 Sep 2004 17:01:02 +0800
Date: Fri, 3 Sep 2004 16:57:16 +0800
From: "xuhaoz" <xuhaoz@neonetech.com>
To: "linux-mips" <linux-mips@linux-mips.org>
Subject: 
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit
Message-ID: <NNT0kkZIhTrBoe2U8QV00000033@nnt.neonetech.com>
X-OriginalArrivalTime: 03 Sep 2004 09:01:02.0375 (UTC) FILETIME=[89A5D370:01C49194]
Return-Path: <xuhaoz@neonetech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5781
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: xuhaoz@neonetech.com
Precedence: bulk
X-list: linux-mips

hi:

	does somebody meet a problem like this?

	static void __init init_mount_tree(void)
	{
		mnt=do_kern_mount("rootfs",0,"rootfs",NULL);
		if(IS_ERR(mnt))
			panic("can't creat rootfs");
	}

	when uclinux run here, it report panic, and i wonder which cause this problem?
	would you please give a hint? any suggestion will appreciated!! 
	thank you !!


From fxzhang@ict.ac.cn Fri Sep  3 10:47:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 10:47:17 +0100 (BST)
Received: from webmail.ict.ac.cn ([IPv6:::ffff:159.226.39.7]:39106 "HELO
	ict.ac.cn") by linux-mips.org with SMTP id <S8225005AbUICJrN>;
	Fri, 3 Sep 2004 10:47:13 +0100
Received: (qmail 25349 invoked by uid 507); 3 Sep 2004 09:33:47 -0000
Received: from unknown (HELO ict.ac.cn) (fxzhang@159.226.40.187)
  by ict.ac.cn with SMTP; 3 Sep 2004 09:33:47 -0000
Message-ID: <4138E684.2020403@ict.ac.cn>
Date: Sat, 04 Sep 2004 05:47:48 +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: xuhaoz <xuhaoz@neonetech.com>
CC: linux-mips <linux-mips@linux-mips.org>
Subject: Re: 
References: <NNT0kkZIhTrBoe2U8QV00000033@nnt.neonetech.com>
In-Reply-To: <NNT0kkZIhTrBoe2U8QV00000033@nnt.neonetech.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Return-Path: <fxzhang@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5782
X-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

This is probably nothing to do with mips thus not so suitable to appear
here:)

xuhaoz wrote:

>hi:
>
>	does somebody meet a problem like this?
>
>	static void __init init_mount_tree(void)
>	{
>		mnt=do_kern_mount("rootfs",0,"rootfs",NULL);
>		if(IS_ERR(mnt))
>			panic("can't creat rootfs");
>  
>
>	}
>  
>

And I think you should really do a little more before ask for such questions
(I will attach you a copy of the famous "How To Ask Questions The Smart Way"
,hope that helps:)

You can use ctags or some other code reading tools(e.g. source insight) to
dig in the code, it is not hard to find out where are the possible
failing reasons
then you can insert printks to test your thoughts.

Maybe you can use remote debug to trace the code too.

>	when uclinux run here, it report panic, and i wonder which cause this problem?
>	would you please give a hint? any suggestion will appreciated!! 
>	thank you !!
>
>
>
>
>  
>

From michael.stickel@4g-systems.biz Fri Sep  3 10:54:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 10:54:25 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.189]:27133
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225005AbUICJyV>; Fri, 3 Sep 2004 10:54:21 +0100
Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1C3Alw-0001jx-00
	for linux-mips@linux-mips.org; Fri, 03 Sep 2004 11:54:20 +0200
Received: from [80.129.138.56] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128)
	(Exim 3.35 #1)
	id 1C3Alu-0004GL-00
	for linux-mips@linux-mips.org; Fri, 03 Sep 2004 11:54:18 +0200
From: Michael Stickel <michael.stickel@4g-systems.biz>
To: linux-mips@linux-mips.org
Subject: USB Mass-storage and Au1500
Date: Thu, 2 Sep 2004 15:37:37 +0200
User-Agent: KMail/1.7
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200409021537.37595.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: 5783
X-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

Hi.

Does anyone have USB massstorage working with the Au1500.
What Kernel version and what Hardware.

Michael

From ichinoh@mb.neweb.ne.jp Fri Sep  3 17:12:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 17:12:57 +0100 (BST)
Received: from imfep05.dion.ne.jp ([IPv6:::ffff:210.174.120.154]:61709 "EHLO
	imfep05.dion.ne.jp") by linux-mips.org with ESMTP
	id <S8225242AbUICQMv>; Fri, 3 Sep 2004 17:12:51 +0100
Received: from mb.neweb.ne.jp ([211.126.90.1]) by imfep05.dion.ne.jp
          (InterMail vM.4.01.03.31 201-229-121-131-20020322) with ESMTP
          id <20040903161239.LSRI29557.imfep05.dion.ne.jp@mb.neweb.ne.jp>
          for <linux-mips@linux-mips.org>; Sat, 4 Sep 2004 01:12:39 +0900
Date: Sat, 4 Sep 2004 01:12:38 +0900
Subject: Re: Reset of USB
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: ichinoh@mb.neweb.ne.jp
To: linux-mips@linux-mips.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <41375D32.2050808@mvista.com>
Message-Id: <1344E951-FDC4-11D8-B0F8-000A956B2316@mb.neweb.ne.jp>
X-Mailer: Apple Mail (2.553)
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: 5784
X-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

The problem which I was investigating was solved.

USB of Au1100 uses AUX_PLL as a clock source.

The setting value of AUX PLL Control Register was mistaken.

When I corrected it, USB-KEYBOARD worked.

Eric, Pete,
I appreciate to you.

Nyauyama

Pete Popov wrote:

> ichinoh@mb.neweb.ne.jp wrote:
>
>> Thank you for advice.
>>
>> I solved by setting up Frequency Control 0 register (FE2, FS2)
>> and setting 100 to a Clock Source Control register (MIR).
>>
>> However, in U-BOOT and YAMON,
>> behavior of a kernel differs about USB-KEYBOARD.
>>
>> A kernel is started using U-BOOT:
>>   USB-KEYBOARD is not recognized.
>>
>> A kernel is started using YAMON:
>>   USB-KEYBOARD is recognized.
>>
>> I am investigating this phenomenon now.
>
> I can't tell without the manual in front of me what it means to write 
> 100 to the clock source control reg, so I can't tell if you're setting 
> the right frequency. If I remember correctly, you need the clock to be 
> 48MHz. Use the values that yamon is using that should do it. Also, 
> there are multi-use pins that need to be set appropriately. I don't 
> remember if everything was set in Linux or if we allowed yamon to do 
> it. Finally, if you get all the software right and it's still not 
> working, check the hardware design as well :)
>
> Pete
>
>
>>
>>
>> ---------------- U-BOOT dmesg ---------------------
>> memsize=67108864
>> initrd_start=0xa0000000
>> initrd_size=0
>> CPU revision is: 02030204
>> Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 
>> bytes.
>> Primary data cache 16kB 4-way, linesize 32 bytes.
>> Linux version 2.4.21-p4b1 (root@localhost.localdomain) (gcc version 
>> 3.2.3) #1 Wed Sep 1 18:31:23 JST
>>  2004
>> AMD Alchemy Au1100/Db1100 Board
>> Determined physical RAM map:
>> User-defined physical RAM map:
>>  memory: 04000000 @ 00000000 (usable)
>> Initial ramdisk at: 0x802fb000 (819200 bytes)
>> On node 0 totalpages: 16384
>> zone(0): 16384 pages.
>> zone(1): 0 pages.
>> zone(2): 0 pages.
>> Kernel command line: root=/dev/hda2 video=au1100fb:panel:s10,nohwcurs 
>>  mem=67108864 au1000_audio=vra
>>  usb_ohci=base:0x10100000,len:0x100000,irq:26
>> au1100fb: Panel 9 800x600_16
>> calculating r4koff... 003c6de5(3960293)
>> CPU frequency 396.03 MHz
>> Console: colour dummy device 80x25
>> Calibrating delay loop... 395.67 BogoMIPS
>> Memory: 59976k/65536k available (1809k kernel code, 5560k reserved, 
>> 916k data, 80k init, 0k highmem)
>> Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
>> Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
>> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
>> Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
>> Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
>> Checking for 'wait' instruction...  available.
>> POSIX conformance testing by UNIFIX
>> Linux NET4.0 for Linux 2.4
>> Based upon Swansea University Computer Society NET3.039
>> Initializing RT netlink socket
>> Starting kswapd
>> Journalled Block Device driver loaded
>> Console: switching to colour frame buffer device 100x37
>> fb0: Au1100 LCD frame buffer device
>> initialize_kbd: Keyboard failed self test
>> pty: 256 Unix98 ptys configured
>> keyboard: Timeout - AT keyboard not present?(ed)
>> keyboard: Timeout - AT keyboard not present?(f4)
>> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
>> loop: loaded (max 8 devices)
>> au1000eth.c:1.1 ppopov@mvista.com
>> eth0: Au1xxx ethernet found at 0xb0500000, irq 28
>> eth0: No mac address found
>> eth0: AMD 79C874 10/100 BaseT PHY at phy address 31
>> eth0: Using AMD 79C874 10/100 BaseT PHY as default
>> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
>> ide: Assuming 50MHz system bus speed for PIO modes; override with 
>> idebus=xx
>> ide0: ports already in use, skipping probe
>> ide1: ports already in use, skipping probe
>> ide2: ports already in use, skipping probe
>> ide3: ports already in use, skipping probe
>> ide4: ports already in use, skipping probe
>> ide5: ports already in use, skipping probe
>> Au1000 audio: stevel@mvista.com, built 18:34:06 on Sep  1 2004
>> Au1000 audio: DAC: DMA0/IRQ6, ADC: DMA1/IRQ7
>> ac97_codec: AC97 Audio codec, id: 0x8384:0x7652 (SigmaTel STAC9752/53)
>> Au1000 audio: AC'97 Base/Extended ID = 6a90/0a05
>> Db1xxx flash: probing 32-bit flash bus
>>  Amd/Fujitsu Extended Query Table v1.3 at 0x0040
>> number of CFI chips: 1
>> cfi_cmdset_0002: Disabling fast programming due to code brokenness.
>> Creating 2 MTD partitions on "Db1x00 flash":
>> 0x00000000-0x00e00000 : "User FS"
>> 0x00e00000-0x01000000 : "raw kernel"
>> usb.c: registered new driver usbdevfs
>> usb.c: registered new driver hub
>> usb-ohci.c: USB OHCI at membase 0xb0100000, IRQ 26
>> usb-ohci.c: usb-builtin, non-PCI OHCI
>> usb.c: new USB bus registered, assigned bus number 1
>> hub.c: USB hub found
>> hub.c: 2 ports detected
>> usb.c: registered new driver hid
>> hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
>> hid-core.c: USB HID support drivers
>> mice: PS/2 mouse device common for all mice
>> NET4: Linux TCP/IP 1.0 for NET4.0
>> IP Protocols: ICMP, UDP, TCP, IGMP
>> IP: routing cache hash table of 512 buckets, 4Kbytes
>> TCP: Hash tables configured (established 4096 bind 8192)
>> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
>> Serial driver version 1.01 (2001-02-08) with no serial options enabled
>> ttyS00 at 0xb1100000 (irq = 0) is a 16550
>> ttyS01 at 0xb1200000 (irq = 1) is a 16550
>> ttyS02 at 0xb1300000 (irq = 2) is a 16550
>> ttyS03 at 0xb1400000 (irq = 3) is a 16550
>> RAMDISK: Compressed image found at block 0
>> Freeing initrd memory: 800k freed
>> VFS: Mounted root (ext2 filesystem).
>> Algorithmics/MIPS FPU Emulator v1.5
>> hub.c: new USB device builtin-2, assigned address 2
>> usb.c: USB device not accepting new address=2 (error=-145)
>> Linux Kernel Card Services 3.1.22
>>   options:  [pci]
>>
>> Au1x00 PCMCIA (CS release 3.1.22)
>> hub.c: new USB device builtin-2, assigned address 3
>> usb.c: USB device not accepting new address=3 (error=-145)
>> eth0: link up
>> eth0: going to full duplex
>> Trying to free nonexistent resource <c0010000-c001000f>
>> hda: HMS360404D5CF00, CFA DISK drive
>> ide1: ports already in use, skipping probe
>> ide2: ports already in use, skipping probe
>> ide3: ports already in use, skipping probe
>> ide4: ports already in use, skipping probe
>> ide5: ports already in use, skipping probe
>> ide0 at 0xc0010000-0xc0010007,0xc001000e on irq 34
>> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
>> hda: task_no_data_intr: error=0x04 { DriveStatusError }
>> hda: 7999488 sectors (4096 MB) w/128KiB Cache, CHS=7936/16/63
>> Partition check:
>>  hda:<6> [PTBL] [992/128/63] hda1 hda2 hda3
>> ide_cs: hda: Vcc = 3.3, Vpp = 0.0
>>  hda: hda1 hda2 hda3
>>  hda: hda1 hda2 hda3
>> kjournald starting.  Commit interval 5 seconds
>> EXT3-fs: mounted filesystem with ordered data mode.
>> VFS: Mounted root (ext3 filesystem) readonly.
>> Trying to move old root to /initrd ... okay
>> Freeing unused kernel memory: 80k freed
>> EXT3-fs warning: maximal mount count reached, running e2fsck is 
>> recommended
>> EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal
>>
>> ----------------- YAMON dmesg ---------------------
>> CPU revision is: 02030204
>> Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 
>> bytes.
>> Primary data cache 16kB 4-way, linesize 32 bytes.
>> Linux version 2.4.21-p4b1 (root@localhost.localdomain) (gcc version 
>> 3.2.3) #1 Fri Aug 27 22:45:11 JS
>> T 2004
>> AMD Alchemy Au1100/Db1100 Board
>> Determined physical RAM map:
>>  memory: 04000000 @ 00000000 (usable)
>> Initial ramdisk at: 0x802fb000 (819200 bytes)
>> On node 0 totalpages: 16384
>> zone(0): 16384 pages.
>> zone(1): 0 pages.
>> zone(2): 0 pages.
>> Kernel command line: root=/dev/hda2 video=au1100fb:panel:s10,nohwcurs 
>> au1000_audio=vra usb_ohci=base
>> :0x10100000,len:0x100000,irq:26
>> au1100fb: Panel 6 NEON_640x480_16
>> calculating r4koff... 003c6de6(3960294)
>> CPU frequency 396.03 MHz
>> Console: colour dummy device 80x25
>> Calibrating delay loop... 395.67 BogoMIPS
>> Memory: 59976k/65536k available (1809k kernel code, 5560k reserved, 
>> 916k data, 80k init, 0k highmem)
>> Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
>> Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
>> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
>> Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
>> Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
>> Checking for 'wait' instruction...  available.
>> POSIX conformance testing by UNIFIX
>> Linux NET4.0 for Linux 2.4
>> Based upon Swansea University Computer Society NET3.039
>> Initializing RT netlink socket
>> Starting kswapd
>> Journalled Block Device driver loaded
>> Console: switching to colour frame buffer device 100x37
>> fb0: Au1100 LCD frame buffer device
>> initialize_kbd: Keyboard failed self test
>> pty: 256 Unix98 ptys configured
>> keyboard: Timeout - AT keyboard not present?(ed)
>> keyboard: Timeout - AT keyboard not present?(f4)
>> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
>> loop: loaded (max 8 devices)
>> au1000eth.c:1.1 ppopov@mvista.com
>> eth0: Au1xxx ethernet found at 0xb0500000, irq 28
>> eth0: AMD 79C874 10/100 BaseT PHY at phy address 31
>> eth0: Using AMD 79C874 10/100 BaseT PHY as default
>> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
>> ide: Assuming 50MHz system bus speed for PIO modes; override with 
>> idebus=xx
>> ide0: ports already in use, skipping probe
>> ide1: ports already in use, skipping probe
>> ide2: ports already in use, skipping probe
>> ide3: ports already in use, skipping probe
>> ide4: ports already in use, skipping probe
>> ide5: ports already in use, skipping probe
>> Au1000 audio: stevel@mvista.com, built 22:47:51 on Aug 27 2004
>> Au1000 audio: DAC: DMA0/IRQ6, ADC: DMA1/IRQ7
>> ac97_codec: AC97 Audio codec, id: 0x8384:0x7652 (SigmaTel STAC9752/53)
>> Au1000 audio: AC'97 Base/Extended ID = 6a90/0a05
>> Db1xxx flash: probing 32-bit flash bus
>>  Amd/Fujitsu Extended Query Table v1.3 at 0x0040
>> number of CFI chips: 1
>> cfi_cmdset_0002: Disabling fast programming due to code brokenness.
>> Creating 2 MTD partitions on "Db1x00 flash":
>> 0x00000000-0x00e00000 : "User FS"
>> 0x00e00000-0x01000000 : "raw kernel"
>> usb.c: registered new driver usbdevfs
>> usb.c: registered new driver hub
>> usb-ohci.c: USB OHCI at membase 0xb0100000, IRQ 26
>> usb-ohci.c: usb-builtin, non-PCI OHCI
>> usb.c: new USB bus registered, assigned bus number 1
>> hub.c: USB hub found
>> hub.c: 2 ports detected
>> usb.c: registered new driver hid
>> hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
>> hid-core.c: USB HID support drivers
>> mice: PS/2 mouse device common for all mice
>> NET4: Linux TCP/IP 1.0 for NET4.0
>> IP Protocols: ICMP, UDP, TCP, IGMP
>> IP: routing cache hash table of 512 buckets, 4Kbytes
>> TCP: Hash tables configured (established 4096 bind 8192)
>> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
>> Serial driver version 1.01 (2001-02-08) with no serial options enabled
>> ttyS00 at 0xb1100000 (irq = 0) is a 16550
>> ttyS01 at 0xb1200000 (irq = 1) is a 16550
>> ttyS02 at 0xb1300000 (irq = 2) is a 16550
>> ttyS03 at 0xb1400000 (irq = 3) is a 16550
>> RAMDISK: Compressed image found at block 0
>> Freeing initrd memory: 800k freed
>> VFS: Mounted root (ext2 filesystem).
>> Algorithmics/MIPS FPU Emulator v1.5
>> hub.c: new USB device builtin-2, assigned address 2
>> input0: USB HID v1.00 Keyboard [  USB Multimedia Keyboard ] on 
>> usb1:2.0
>> input1: USB HID v1.00 Pointer [  USB Multimedia Keyboard ] on usb1:2.1
>> Linux Kernel Card Services 3.1.22
>>   options:  [pci]
>>
>> Au1x00 PCMCIA (CS release 3.1.22)
>> eth0: link up
>> eth0: going to full duplex
>> Trying to free nonexistent resource <c0010000-c001000f>
>> hda: HMS360404D5CF00, CFA DISK drive
>> ide1: ports already in use, skipping probe
>> ide2: ports already in use, skipping probe
>> ide3: ports already in use, skipping probe
>> ide4: ports already in use, skipping probe
>> ide5: ports already in use, skipping probe
>> ide0 at 0xc0010000-0xc0010007,0xc001000e on irq 34
>> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
>> hda: task_no_data_intr: error=0x04 { DriveStatusError }
>> hda: 7999488 sectors (4096 MB) w/128KiB Cache, CHS=7936/16/63
>> Partition check:
>>  hda:<6> [PTBL] [992/128/63] hda1 hda2 hda3
>> ide_cs: hda: Vcc = 3.3, Vpp = 0.0
>>  hda: hda1 hda2 hda3
>>  hda: hda1 hda2 hda3
>> kjournald starting.  Commit interval 5 seconds
>> EXT3-fs: mounted filesystem with ordered data mode.
>> VFS: Mounted root (ext3 filesystem) readonly.
>> Trying to move old root to /initrd ... okay
>> Freeing unused kernel memory: 80k freed
>> EXT3-fs warning: maximal mount count reached, running e2fsck is 
>> recommended
>> EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal
>>
>> Nyauyama
>>
>> On 2004.9.1, at 06:40  AM, Pete Popov wrote:
>>
>>> ichinoh@mb.neweb.ne.jp wrote:
>>>
>>>> Hello ,
>>>>
>>>> I invoked the Linux kernel on ALCHEMY DBAU1100 by U-BOOT.
>>>>
>>>> The processing which resets USB-OHCI of the head of a kernel is not 
>>>> completed. (refer to *)
>>>>
>>>> Au1100 does not indicate "reset is completed."
>>>> Is this phenomenon experienced?
>>>>
>>>> In addition,
>>>> this phenomenon is not encountered when starting a kernel by YAMON.
>>>
>>>
>>> Yamon initializes the CPU and then Linux doesn't have to touch too 
>>> many registers. I'm guessing u-boot doesn't setup the clocking 
>>> correctly, or at all, and that might be your problem. The Yamon code 
>>> for these boards is available and it's easy to read the 
>>> initialization code.  Take a look at it and that should solve your 
>>> problem.
>>>
>>> Pete
>>>
>>>>
>>>>
>>>> *:
>>>> arch/mips/au1000/common/setup.c
>>>>
>>>> #ifdef CONFIG_USB_OHCI
>>>>     // enable host controller and wait for reset done
>>>>     au_writel(0x08, USB_HOST_CONFIG);
>>>>     udelay(1000);
>>>>     au_writel(0x0E, USB_HOST_CONFIG);
>>>>     udelay(1000);
>>>>     au_readl(USB_HOST_CONFIG); // throw away first read
>>>>     while (!(au_readl(USB_HOST_CONFIG) & 0x10))
>>>>         au_readl(USB_HOST_CONFIG);
>>>> #endif
>>>>
>>>> Best regards,
>>>> Nyauyama
>>>>
>>>>
>>>
>>
>>
>


From ppopov@mvista.com Fri Sep  3 20:16:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 20:16:14 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:28654 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225244AbUICTQK>;
	Fri, 3 Sep 2004 20:16:10 +0100
Received: from [10.0.10.3] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA18251;
	Fri, 3 Sep 2004 12:16:03 -0700
Message-ID: <4138C2F6.6020209@mvista.com>
Date: Fri, 03 Sep 2004 12:16:06 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
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: USB Mass-storage and Au1500
References: <200409021537.37595.michael.stickel@4g-systems.biz>
In-Reply-To: <200409021537.37595.michael.stickel@4g-systems.biz>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5785
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

Michael Stickel wrote:

>Hi.
>
>Does anyone have USB massstorage working with the Au1500.
>What Kernel version and what Hardware.
>  
>
2.4 should work fine, though I haven't tried any usb sticks myself.

Pete

From rth@redhat.com Fri Sep  3 21:15:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Sep 2004 21:15:20 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:62855 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225246AbUICUPP>;
	Fri, 3 Sep 2004 21:15:15 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i83KErl3004408;
	Fri, 3 Sep 2004 16:14:53 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i83KFB716491;
	Fri, 3 Sep 2004 16:15:11 -0400
Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i83KFBV04250;
	Fri, 3 Sep 2004 13:15:11 -0700
Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1])
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i83KFBOo013425;
	Fri, 3 Sep 2004 13:15:11 -0700
Received: (from rth@localhost)
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i83KFANx013423;
	Fri, 3 Sep 2004 13:15:10 -0700
X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f
Date: Fri, 3 Sep 2004 13:15:10 -0700
From: Richard Henderson <rth@redhat.com>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
Message-ID: <20040903201510.GB13228@redhat.com>
Mail-Followup-To: Richard Henderson <rth@redhat.com>,
	Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
References: <20040809220838.GE16493@redhat.com> <87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com> <87eklnw0g7.fsf@redhat.com> <20040903065331.GG20559@redhat.com> <87sm9zg7dg.fsf@redhat.com> <20040903070858.GA24082@redhat.com> <87oekng72k.fsf@redhat.com> <20040903072010.GD24082@redhat.com> <87k6vbg68s.fsf@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87k6vbg68s.fsf@redhat.com>
User-Agent: Mutt/1.4.1i
Return-Path: <rth@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: 5786
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rth@redhat.com
Precedence: bulk
X-list: linux-mips

On Fri, Sep 03, 2004 at 08:29:39AM +0100, Richard Sandiford wrote:
> The patch I posted this week was in response to the request for
> wider-ranging target support:
> 
>     http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00606.html

Ah.  I wasn't actually asking for wider target support.  I was 
commenting that if we wanted something better, we'd have to add
new target support.  Sorry for the confusion.

> Is the new target hook really that invasive?  It doesn't affect any
> other code as such.

No... I guess not.  And it is a start if we ever do decide to
expand its meaning to replace S_C_T.

> The only change not directly related to the optabs expansion was the
> simplify-rtx.c thing, and like I said in my covering message, I think
> that code's bogus anyway ...

Agreed.

Ok, revised patch approved.


r~

From lishishan@utstar.com Sat Sep  4 06:06:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 04 Sep 2004 06:06:44 +0100 (BST)
Received: from [IPv6:::ffff:218.108.42.27] ([IPv6:::ffff:218.108.42.27]:51943
	"EHLO hzvscan2.utstar.com.cn") by linux-mips.org with ESMTP
	id <S8224793AbUIDFGk>; Sat, 4 Sep 2004 06:06:40 +0100
Received: from cnmail01.cn.utstarcom.com (localhost [127.0.0.1])
	by hzvscan2.utstar.com.cn (8.11.6/8.11.6) with SMTP id i8452Mj21518
	for <linux-mips@linux-mips.org>; Sat, 4 Sep 2004 13:02:28 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4923C.F6E5C2D0"
Subject: Why the program complied by mips-linux-g++  cann't run on the target machine
Date: Sat, 4 Sep 2004 13:06:39 +0800
Message-ID: <BA3B937FD9473E41998E125463A3914301C68183@cnmail01.cn.utstarcom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why the program complied by mips-linux-g++  cann't run on the target machine
Thread-Index: AcSSPPYnv/+Wr/hoSVWlrfJDHvGxVg==
From: "Li Shishan" <lishishan@utstar.com>
To: <linux-mips@linux-mips.org>
Return-Path: <lishishan@utstar.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5787
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lishishan@utstar.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4923C.F6E5C2D0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable


    Hi, all:

               I  use the   mips-linux-g++  complie a program.  and I =
excuted it on the target machine , but cann't, what's wrong?
    =20
              For example:

               For PC, I use g++  -c -o ccgame.o ccgame.cpp
		                    g++  -o ccgame ./ccgame.o
		execute it will give: Hello, world!

		For the target board, I use mips-linux-g++  -c -o ccgame.o ccgame.cpp=20
		                             mips-linux-g++  -o ccgame ./ccgame.o
		excute it will give " /bin/sh: ./ccgame: not found".=20

		Is there something wrong?=20

		the mips-linux-gcc work is well!!!

		looking forward for anybody send me the question answer,very thanks!!!

		your sincerely liss

		2004.09.04  13:06


        =20
            =20

------_=_NextPart_001_01C4923C.F6E5C2D0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dgb2312">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.6980.72">
<TITLE>Why the program complied by mips-linux-g++  cann't run on the =
target machine</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Hi, all:</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; I&nbsp; use the&nbsp;&nbsp; =
mips-linux-g++&nbsp; complie a program.&nbsp; and I excuted it on the =
target machine , but cann't, what's wrong?</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; For example:</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"zh-cn"></SPAN><SPAN LANG=3D"zh-cn"></SPAN><SPAN LANG=3D"zh-cn"> =
<FONT SIZE=3D2 FACE=3D"Simsun">For PC, I use<B> g++</B></FONT><B><FONT =
SIZE=3D2 FACE=3D"Courier New"></FONT>&nbsp;<FONT SIZE=3D2 =
FACE=3D"Simsun"> -c -o ccgame.o ccgame.cpp</FONT></B></SPAN></P>
<UL DIR=3DLTR><UL DIR=3DLTR>
<P DIR=3DLTR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;</FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Simsun"></FONT> =
<FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;</FONT>&nbsp;<FONT =
SIZE=3D2 FACE=3D"Simsun"></FONT> <FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;</FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Simsun"></FONT> =
<FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;</FONT>&nbsp;<FONT =
SIZE=3D2 FACE=3D"Simsun"></FONT> <FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;</FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Simsun"></FONT><B> =
<FONT SIZE=3D2 FACE=3D"Simsun">g++</FONT><FONT SIZE=3D2 FACE=3D"Courier =
New"></FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Simsun"> -o</FONT><FONT =
SIZE=3D2 FACE=3D"Courier New"></FONT> <FONT SIZE=3D2 =
FACE=3D"Simsun">ccgame ./ccgame.o</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Simsun">execute =
it will give: Hello, world!</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Simsun">For =
the</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT =
SIZE=3D2 FACE=3D"Courier New">target</FONT></SPAN><SPAN =
LANG=3D"zh-cn"></SPAN><SPAN LANG=3D"zh-cn"> <FONT SIZE=3D2 =
FACE=3D"Simsun">board, I use</FONT></SPAN><SPAN LANG=3D"zh-cn"><B> <FONT =
SIZE=3D2 FACE=3D"Simsun">mips-linux-g++</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New"></FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Simsun"> -c -o =
ccgame.o ccgame.cpp</FONT></B><FONT SIZE=3D2 FACE=3D"Simsun"></FONT> =
</SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><B> <FONT SIZE=3D2 =
FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT =
SIZE=3D2 FACE=3D"Simsun">mips-linux-g++</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New"></FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Simsun"> =
-o</FONT><FONT SIZE=3D2 FACE=3D"Courier New"></FONT> <FONT SIZE=3D2 =
FACE=3D"Simsun">ccgame ./ccgame.o</FONT></B></SPAN></P>

<P DIR=3DLTR><B><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">excute it</FONT></SPAN><SPAN LANG=3D"zh-cn"></SPAN></B><SPAN =
LANG=3D"zh-cn"></SPAN><SPAN LANG=3D"zh-cn"> <FONT SIZE=3D2 =
FACE=3D"Simsun">will give</FONT><B> <FONT SIZE=3D2 =
FACE=3D"Simsun">&quot; /bin/sh: ./ccgame: not =
found&quot;</FONT></B><FONT SIZE=3D2 FACE=3D"Simsun">.</FONT><FONT =
FACE=3D"Simsun"> </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Simsun">Is =
there something wrong?</FONT> </SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Simsun">the =
mips-linux-gcc work is well!!!</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Simsun">looking forward =
for anybody send me the question answer,very thanks!!!</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Simsun">your sincerely =
liss</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Simsun">2004.09.04&nbsp; =
13:06</FONT></SPAN><SPAN LANG=3D"zh-cn"></SPAN><SPAN =
LANG=3D"zh-cn"></SPAN></P>
<BR>
</UL></UL>
<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"zh-cn"></SPAN><SPAN =
LANG=3D"zh-cn"> </SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C4923C.F6E5C2D0--

From rsandifo@redhat.com Sat Sep  4 09:53:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 04 Sep 2004 09:53:38 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:9922 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224922AbUIDIxe>;
	Sat, 4 Sep 2004 09:53:34 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i848rWS0010600;
	Sat, 4 Sep 2004 04:53:32 -0400
Received: from localhost (mail@vpnuser1.surrey.redhat.com [172.16.9.1])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i848rT325150;
	Sat, 4 Sep 2004 04:53:30 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1C3WIb-0005nd-00; Sat, 04 Sep 2004 09:53:29 +0100
To: Richard Henderson <rth@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <20040809220838.GE16493@redhat.com> <87zn5336h7.fsf@redhat.com>
	<20040810232020.GA21922@redhat.com> <87eklnw0g7.fsf@redhat.com>
	<20040903065331.GG20559@redhat.com> <87sm9zg7dg.fsf@redhat.com>
	<20040903070858.GA24082@redhat.com> <87oekng72k.fsf@redhat.com>
	<20040903072010.GD24082@redhat.com> <87k6vbg68s.fsf@redhat.com>
	<20040903201510.GB13228@redhat.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Sat, 04 Sep 2004 09:53:28 +0100
In-Reply-To: <20040903201510.GB13228@redhat.com> (Richard Henderson's
 message of "Fri, 3 Sep 2004 13:15:10 -0700")
Message-ID: <873c1ytnxz.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: 5788
X-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

Richard Henderson <rth@redhat.com> writes:
> On Fri, Sep 03, 2004 at 08:29:39AM +0100, Richard Sandiford wrote:
>> The patch I posted this week was in response to the request for
>> wider-ranging target support:
>> 
>>     http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00606.html
>
> Ah.  I wasn't actually asking for wider target support.  I was 
> commenting that if we wanted something better, we'd have to add
> new target support.

Ooops!  I misunderstood, sorry.

>> Is the new target hook really that invasive?  It doesn't affect any
>> other code as such.
>
> No... I guess not.  And it is a start if we ever do decide to
> expand its meaning to replace S_C_T.
[...]
> Ok, revised patch approved.

Thanks, applied.

Looking back, I see I didn't do a very good job of explaining why
I think S_C_T and this target hook are doing two different things.
A bit more explanation (mostly for the record, since I doubt I'm
saying anything surprising here):

I can only see two optimisations guarded by !S_C_T, both of them in
combine.c.  They only disallow S_C_T because we might have already
optimised the construct in a different way.  All other uses of S_C_T
are used for shifts.

So the important point is that: although S_C_T requires a particular
behaviour for things like ZERO_EXTRACT, it is never actually used in
a positive context for ZERO_EXTRACT rtxes.  S_C_T is only ever used
in a positive context for shift rtxes.

As I understand it, the reason that S_C_T has those extra requirements
is that we have no way of tracking where a particular shift came from.
Sometimes it might come from an insn's PATTERN, sometimes it might be
the result of some temporary rewrites, such as that performed by combine.c
for "compound" operations.  The definition of S_C_T says that these
rewrites must be valid.


It sounds like you're saying that the target hook should eventually
be extended to cover shift rtxes rather than shift optabs, and that
anything which generates a shift rtx should make sure the rtx behaves
correctly wrt these hooks.  So, for example, the onus for verifying the
ZERO_EXTRACT rewrites should be with combine rather than the backend.
Is that right?  If so, I'll try to look at that in the 3.6 timeframe.

Richard

From lishishan@utstar.com Sat Sep  4 10:07:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 04 Sep 2004 10:07:26 +0100 (BST)
Received: from [IPv6:::ffff:218.108.42.27] ([IPv6:::ffff:218.108.42.27]:56773
	"EHLO hzvscan2.utstar.com.cn") by linux-mips.org with ESMTP
	id <S8224922AbUIDJHV>; Sat, 4 Sep 2004 10:07:21 +0100
Received: from cnmail01.cn.utstarcom.com (localhost [127.0.0.1])
	by hzvscan2.utstar.com.cn (8.11.6/8.11.6) with SMTP id i8493DR17682
	for <linux-mips@linux-mips.org>; Sat, 4 Sep 2004 17:03:13 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4925E.9C852458"
Subject: How to compile the  binutils-2.13.2.1.tar.gz  build for mips
Date: Sat, 4 Sep 2004 17:07:30 +0800
Message-ID: <BA3B937FD9473E41998E125463A3914301C682CD@cnmail01.cn.utstarcom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: How to compile the  binutils-2.13.2.1.tar.gz  build for mips
Thread-Index: AcSSXpumnKR+FzoRTCCOYhpP1FROog==
From: "Li Shishan" <lishishan@utstar.com>
To: <linux-mips@linux-mips.org>
Return-Path: <lishishan@utstar.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5789
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lishishan@utstar.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4925E.9C852458
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable




 Hi All:

           I try to build toolchain for big-endian mips , But the first =
step , When I building the binutils , some troubles happened. Can each =
of all help me resolve it.
The step I followed like below:

       gzip -cd binutils-<version>.tar.gz | tar xf -
    cd binutils-<version>
    patch -p1 < ../binutils-<version>-mips.patch
    ./configure --prefix=3D<prefix> --target=3D<target>
    make CFLAGS=3D-O2

 But ,I make it not success, there some comple error:

  gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -o =
objdump objdump.o      budemang.o prdbg.o rddbg.o debug.o stabs.o ieee.o =
rdcoff.o bucomm.o version.o filemode.o  ../opcodes/.libs/libopcodes.a =
../bfd/.libs/libbfd.a ../libiberty/libiberty.a
bucomm.o(.text+0x3f6): In function `make_tempname':
/home/liss/bmips/binutils-2.13.2.1/binutils/bucomm.c:238: warning: the =
use of `mktemp' is dangerous, better use `mkstemp'
../libiberty/libiberty.a(cp-demangle.o)(.text+0xd64): In function =
`demangle_identifier':
/home/liss/bmips/binutils-2.13.2.1/libiberty/cp-demangle.c:1486: =
undefined reference to `__ctype_b'
collect2: ld returned 1 exit status
make[3]: *** [objdump] Error 1
make[3]: Leaving directory `/home/liss/bmips/binutils-2.13.2.1/binutils'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/liss/bmips/binutils-2.13.2.1/binutils'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/home/liss/bmips/binutils-2.13.2.1/binutils'
make: *** [all-binutils] Error 2

  I think the source code is some error,but when I download the =
binutils2.14 ,binutils2.15 ,the error all exit.  So I cann't know what's =
wrong with it,the source is wrong ? or my operation isn't right.
 =20
   Hoping for anybody reply to me ,very thanks.  =20


your sincerely liss
2004.09.04  17:07
 =20


  =20


------_=_NextPart_001_01C4925E.9C852458
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dgb2312">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.6980.72">
<TITLE>How to compile the  binutils-2.13.2.1.tar.gz  build for =
mips</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>
<BR>
<BR>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial"><B></B></FONT><B>&nbsp;<FONT SIZE=3D4 FACE=3D"Arial">Hi =
All:</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D4 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </FONT><FONT COLOR=3D"#0000FF" SIZE=3D4 FACE=3D"Arial">I try to build =
toolchain for big-</FONT><FONT COLOR=3D"#0000FF" SIZE=3D5 =
FACE=3D"Arial">endian mips ,</FONT></B> <FONT COLOR=3D"#0000FF" SIZE=3D5 =
FACE=3D"Arial">But the first step , When I building the binutils , some =
troubles happened. Can each of all help me resolve it.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#0000FF" SIZE=3D5 =
FACE=3D"Arial">The step I followed like below:</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT SIZE=3D5 =
FACE=3D"Simsun">&nbsp; gzip -cd binutils-&lt;version&gt;.tar.gz | tar xf =
-<BR>
&nbsp;&nbsp;&nbsp; cd binutils-&lt;version&gt;<BR>
&nbsp;&nbsp;&nbsp; patch -p1 &lt; =
../binutils-&lt;version&gt;-mips.patch<BR>
&nbsp;&nbsp;&nbsp; ./configure --prefix=3D&lt;prefix&gt; =
--target=3D&lt;target&gt;<BR>
&nbsp;&nbsp;&nbsp; make CFLAGS=3D-O2</FONT></B></SPAN></P>
<BR>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT COLOR=3D"#0000FF" SIZE=3D5 =
FACE=3D"Simsun">&nbsp;But ,I make it not success, there some comple =
error:</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">&nbsp; gcc -W -Wall -Wstrict-prototypes =
-Wmissing-prototypes -g -O2 -o objdump =
objdump.o&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; budemang.o prdbg.o rddbg.o =
debug.o stabs.o ieee.o rdcoff.o bucomm.o version.o filemode.o&nbsp; =
../opcodes/.libs/libopcodes.a ../bfd/.libs/libbfd.a =
../libiberty/libiberty.a</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">bucomm.o(.text+0x3f6): In function =
`make_tempname':</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">/home/liss/bmips/binutils-2.13.2.1/binutils/bucomm.c:238:=
 warning: the use of `mktemp' is dangerous, better use =
`mkstemp'</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">../libiberty/libiberty.a(cp-demangle.o)(.text+0xd64): In =
function `demangle_identifier':</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">/home/liss/bmips/binutils-2.13.2.1/libiberty/cp-demangle.=
c:1486: undefined reference to `__ctype_b'</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">collect2: ld returned 1 exit =
status</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">make[3]: *** [objdump] Error 1</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">make[3]: Leaving directory =
`/home/liss/bmips/binutils-2.13.2.1/binutils'</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">make[2]: *** [all-recursive] Error =
1</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">make[2]: Leaving directory =
`/home/liss/bmips/binutils-2.13.2.1/binutils'</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">make[1]: *** [all-recursive-am] Error =
2</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">make[1]: Leaving directory =
`/home/liss/bmips/binutils-2.13.2.1/binutils'</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">make: *** [all-binutils] Error 2</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT COLOR=3D"#0000FF" SIZE=3D5 =
FACE=3D"Simsun">&nbsp; I think the source code is some error,but when I =
download the binutils2.14 ,binutils2.15 ,the error all exit.&nbsp; So I =
cann't know what's wrong with it,the source is wrong ? or my operation =
isn't right.</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">&nbsp; </FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">&nbsp;&nbsp; Hoping for anybody reply to me ,very =
thanks.&nbsp;&nbsp; </FONT></B></SPAN></P>
<BR>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 FACE=3D"Simsun">your =
sincerely liss</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">2004.09.04&nbsp; 17:07</FONT></B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><B><FONT SIZE=3D5 =
FACE=3D"Simsun">&nbsp; </FONT></B></SPAN></P>
<BR>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Simsun">&nbsp;&nbsp; </FONT></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C4925E.9C852458--

From geert@linux-m68k.org Sat Sep  4 21:43:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 04 Sep 2004 21:44:03 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:15593 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224954AbUIDUn6>;
	Sat, 4 Sep 2004 21:43:58 +0100
Received: from waterleaf.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i84KhsMp027869;
	Sat, 4 Sep 2004 22:43:56 +0200 (MEST)
Date: Sat, 4 Sep 2004 22:43:54 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Li Shishan <lishishan@utstar.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Why the program complied by mips-linux-g++ cann't run on the
 target machine
In-Reply-To: <BA3B937FD9473E41998E125463A3914301C68183@cnmail01.cn.utstarcom.com>
Message-ID: <Pine.GSO.4.58.0409042243081.3434@waterleaf.sonytel.be>
References: <BA3B937FD9473E41998E125463A3914301C68183@cnmail01.cn.utstarcom.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5790
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Sat, 4 Sep 2004, Li Shishan wrote:
>                I  use the   mips-linux-g++  complie a program.  and I excuted it on the target machine , but cann't, what's wrong?
>
>               For example:
>
>                For PC, I use g++  -c -o ccgame.o ccgame.cpp
> 		                    g++  -o ccgame ./ccgame.o
> 		execute it will give: Hello, world!
>
> 		For the target board, I use mips-linux-g++  -c -o ccgame.o ccgame.cpp
> 		                             mips-linux-g++  -o ccgame ./ccgame.o
> 		excute it will give " /bin/sh: ./ccgame: not found".
>
> 		Is there something wrong?

Look like you didn't install the C++ runtime libraries on the target.
What does `ldd ./ccgame' say?

Gr{oetje,eeting}s,

						Geert

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

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

From rth@redhat.com Sun Sep  5 01:03:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 05 Sep 2004 01:03:37 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:15027 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225074AbUIEADd>;
	Sun, 5 Sep 2004 01:03:33 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i85037l3018299;
	Sat, 4 Sep 2004 20:03:08 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8503T725943;
	Sat, 4 Sep 2004 20:03:29 -0400
Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i8503SV13692;
	Sat, 4 Sep 2004 17:03:28 -0700
Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1])
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i8503SOo016834;
	Sat, 4 Sep 2004 17:03:28 -0700
Received: (from rth@localhost)
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i8503SYf016832;
	Sat, 4 Sep 2004 17:03:28 -0700
X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f
Date: Sat, 4 Sep 2004 17:03:28 -0700
From: Richard Henderson <rth@redhat.com>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
Message-ID: <20040905000328.GA16819@redhat.com>
Mail-Followup-To: Richard Henderson <rth@redhat.com>,
	Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
References: <20040810232020.GA21922@redhat.com> <87eklnw0g7.fsf@redhat.com> <20040903065331.GG20559@redhat.com> <87sm9zg7dg.fsf@redhat.com> <20040903070858.GA24082@redhat.com> <87oekng72k.fsf@redhat.com> <20040903072010.GD24082@redhat.com> <87k6vbg68s.fsf@redhat.com> <20040903201510.GB13228@redhat.com> <873c1ytnxz.fsf@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <873c1ytnxz.fsf@redhat.com>
User-Agent: Mutt/1.4.1i
Return-Path: <rth@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: 5791
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rth@redhat.com
Precedence: bulk
X-list: linux-mips

On Sat, Sep 04, 2004 at 09:53:28AM +0100, Richard Sandiford wrote:
> So, for example, the onus for verifying the ZERO_EXTRACT rewrites
> should be with combine rather than the backend.  Is that right?

Yes.


r~

From geert@sonycom.com Sun Sep  5 08:58:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 05 Sep 2004 08:58:25 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:33466 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224914AbUIEH6T>;
	Sun, 5 Sep 2004 08:58:19 +0100
Received: from waterleaf.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i857wGMp000634
	for <linux-mips@linux-mips.org>; Sun, 5 Sep 2004 09:58:16 +0200 (MEST)
X-Received: from dolphin.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i854cuMo019060
	for <Geert.Uytterhoeven@sonycom.com>;
	Sun, 5 Sep 2004 06:38:56 +0200 (MEST)
X-Received: from ns1.nerdnet.nl ([217.170.15.1] helo=nerdnet.nl ident=root)
	by dolphin.sonytel.be with esmtp (Exim 4.41) id 1C3ono-0004jB-Ga
	for Geert.Uytterhoeven@sonycom.com; Sun, 05 Sep 2004 06:38:56 +0200
X-Received: from hzvscan2.utstar.com.cn ([218.108.42.27])
	by nerdnet.nl (8.13.1/8.13.1/Debian-11) with ESMTP id i854crss015193
	for <geert@linux-m68k.org>; Sun, 5 Sep 2004 06:38:55 +0200
X-Received: from cnmail01.cn.utstarcom.com (localhost [127.0.0.1])
	by hzvscan2.utstar.com.cn (8.11.6/8.11.6) with SMTP id i854Ymn15719
	for <geert@linux-m68k.org>; Sun, 5 Sep 2004 12:34:48 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Subject: RE: Why the program complied by mips-linux-g++ cann't run on the
	target machine
Date: Sun, 5 Sep 2004 12:39:09 +0800
Message-ID: <BA3B937FD9473E41998E125463A3914301C68473@cnmail01.cn.utstarcom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why the program complied by mips-linux-g++ cann't run on the
	target machine
Thread-Index: AcSSwALHqU97jn0tTjOzJ6GCeF/nagAOZQEw
From: "Li Shishan" <lishishan@utstar.com>
To: "Geert Uytterhoeven" <geert@linux-m68k.org>
X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c
	on nerdcentral
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by witte.sonytel.be id
	i854cuMo019060
X-Spambayes-Classification: ham; 0.00
ReSent-Date: Sun, 5 Sep 2004 09:58:04 +0200 (MEST)
ReSent-From: Geert Uytterhoeven <geert@sonycom.com>
ReSent-To: Linux/MIPS Development <linux-mips@linux-mips.org>
ReSent-Subject: RE: Why the program complied by mips-linux-g++ cann't run on
 the target machine
ReSent-Message-ID: <Pine.GSO.4.58.0409050958040.28961@waterleaf.sonytel.be>
Return-Path: <geert@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5792
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@sonycom.com
Precedence: bulk
X-list: linux-mips


   Hi  Geert:
        I am very appreciated to your reply,   thank you very  much   !!!

       When I  excute  the command : ldd ./ccgame,  give result : ./ldd: not found .   what can I do for that ?

        If as you say ,require the c++ runtime libraries on the target .   firstly , my  test program  is coded by  C ,not C++ , if it also require c++ libraries?

 secondly, my target flash is very limited,  the C++ runtime libraries  is very large .
       

-----Original Message-----
From: geert@sonycom.com [mailto:geert@sonycom.com]On Behalf Of Geert
Uytterhoeven
Sent: 2004Äê9ÔÂ5ÈÕ 4:44
To: Li Shishan
Cc: Linux/MIPS Development
Subject: Re: Why the program complied by mips-linux-g++ cann't run on
the target machine


On Sat, 4 Sep 2004, Li Shishan wrote:
>                I  use the   mips-linux-g++  complie a program.  and I excuted it on the target machine , but cann't, what's wrong?
>
>               For example:
>
>                For PC, I use g++  -c -o ccgame.o ccgame.cpp
> 		                    g++  -o ccgame ./ccgame.o
> 		execute it will give: Hello, world!
>
> 		For the target board, I use mips-linux-g++  -c -o ccgame.o ccgame.cpp
> 		                             mips-linux-g++  -o ccgame ./ccgame.o
> 		excute it will give " /bin/sh: ./ccgame: not found".
>
> 		Is there something wrong?

Look like you didn't install the C++ runtime libraries on the target.
What does `ldd ./ccgame' say?

Gr{oetje,eeting}s,

						Geert

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

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

From geert@linux-m68k.org Sun Sep  5 09:02:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 05 Sep 2004 09:02:51 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:42171 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224914AbUIEICr>;
	Sun, 5 Sep 2004 09:02:47 +0100
Received: from waterleaf.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i8582kMp000799;
	Sun, 5 Sep 2004 10:02:46 +0200 (MEST)
Date: Sun, 5 Sep 2004 10:02:46 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Li Shishan <lishishan@utstar.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: RE: Why the program complied by mips-linux-g++ cann't run on the
 target machine
In-Reply-To: <BA3B937FD9473E41998E125463A3914301C68473@cnmail01.cn.utstarcom.com>
Message-ID: <Pine.GSO.4.58.0409050958440.28961@waterleaf.sonytel.be>
References: <BA3B937FD9473E41998E125463A3914301C68473@cnmail01.cn.utstarcom.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5793
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Sun, 5 Sep 2004, Li Shishan wrote:
>         I am very appreciated to your reply,   thank you very  much   !!!
>
>        When I  excute  the command : ldd ./ccgame,  give result : ./ldd: not found .   what can I do for that ?

Install ldd to find out?

>         If as you say ,require the c++ runtime libraries on the target .   firstly , my  test program  is coded by  C ,not C++ , if it also require c++ libraries?

If you compile it with g++, it will need the C++ runtime library, even if the
program source is plain C:

| anakin$ cat hello.c
| #include <stdio.h>
| #include <stdlib.h>
|
| int main(int argc, char *argv[])
| {
|     printf("Hello, world! [C]\n");
|     exit(0);
| }
|
| anakin$ gcc hello.c
| anakin$ ldd a.out
|                 libc.so.6 => /lib/tls/libc.so.6 (0x41019000)
|         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x41000000)
| anakin$ mv hello.c hello.C
| anakin$ g++ hello.C
| anakin$ ldd a.out
|                 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40016000)
|         libm.so.6 => /lib/tls/libm.so.6 (0x41156000)
|         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4131a000)
|         libc.so.6 => /lib/tls/libc.so.6 (0x41019000)
|         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x41000000)
| anakin$

>  secondly, my target flash is very limited,  the C++ runtime libraries  is very large .

If it's C, why not compile it with the C compiler instead of the C++ compiler?

> -----Original Message-----
> From: geert@linux-m68k.org Geert Uytterhoeven
> Sent: 2004Äê9ÔÂ5ÈÕ 4:44
> To: Li Shishan
> Cc: Linux/MIPS Development
> Subject: Re: Why the program complied by mips-linux-g++ cann't run on
> the target machine
>
>
> On Sat, 4 Sep 2004, Li Shishan wrote:
> >                I  use the   mips-linux-g++  complie a program.  and I excuted it on the target machine , but cann't, what's wrong?
> >
> >               For example:
> >
> >                For PC, I use g++  -c -o ccgame.o ccgame.cpp
> > 		                    g++  -o ccgame ./ccgame.o
> > 		execute it will give: Hello, world!
> >
> > 		For the target board, I use mips-linux-g++  -c -o ccgame.o ccgame.cpp
> > 		                             mips-linux-g++  -o ccgame ./ccgame.o
> > 		excute it will give " /bin/sh: ./ccgame: not found".
> >
> > 		Is there something wrong?
>
> Look like you didn't install the C++ runtime libraries on the target.
> What does `ldd ./ccgame' say?

Gr{oetje,eeting}s,

						Geert

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

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

From geert@linux-m68k.org Mon Sep  6 10:25:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 06 Sep 2004 10:25:10 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:12679 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224924AbUIFJZG>;
	Mon, 6 Sep 2004 10:25:06 +0100
Received: from waterleaf.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i869P4Mp010476;
	Mon, 6 Sep 2004 11:25:04 +0200 (MEST)
Date: Mon, 6 Sep 2004 11:25:04 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Li Shishan <lishishan@utstar.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: R E: Why the program complied by mips-linux-g++ cann't run on
 the target machine
In-Reply-To: <BA3B937FD9473E41998E125463A3914301CA5774@cnmail01.cn.utstarcom.com>
Message-ID: <Pine.GSO.4.58.0409061123590.15075@waterleaf.sonytel.be>
References: <BA3B937FD9473E41998E125463A3914301CA5774@cnmail01.cn.utstarcom.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5794
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Mon, 6 Sep 2004, Li Shishan wrote:
>         My  test program is coded by C, but my normal project was  coded by C++;
>
>      If  actually   there requrie the C++ runtime library ,   Can you have any other method for it .
>
>     because the C++  runtime library very huge, my  flash is limited.

That's the disadvantage of using C++: it needs a large runtime.

You can work around it by building your own stripped libstdc++, that includes
only the stuff you really need.

Gr{oetje,eeting}s,

						Geert

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

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

From geert@sonycom.com Mon Sep  6 10:25:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 06 Sep 2004 10:25:42 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:13703 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224930AbUIFJZI>;
	Mon, 6 Sep 2004 10:25:08 +0100
Received: from waterleaf.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i869P7Mp010480
	for <linux-mips@linux-mips.org>; Mon, 6 Sep 2004 11:25:07 +0200 (MEST)
X-Received: from dolphin.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i866KjMo028945
	for <Geert.Uytterhoeven@sonycom.com>;
	Mon, 6 Sep 2004 08:20:46 +0200 (MEST)
X-Received: from ns1.nerdnet.nl ([217.170.15.1] helo=nerdnet.nl ident=root)
	by dolphin.sonytel.be with esmtp (Exim 4.41) id 1C4Crt-0007TI-MS
	for Geert.Uytterhoeven@sonycom.com; Mon, 06 Sep 2004 08:20:45 +0200
X-Received: from hzvscan2.utstar.com.cn ([218.108.42.27])
	by nerdnet.nl (8.13.1/8.13.1/Debian-11) with ESMTP id i866KfQm026039
	for <geert@linux-m68k.org>; Mon, 6 Sep 2004 08:20:44 +0200
X-Received: from cnmail01.cn.utstarcom.com (localhost [127.0.0.1])
	by hzvscan2.utstar.com.cn (8.11.6/8.11.6) with SMTP id i866GQj25496
	for <geert@linux-m68k.org>; Mon, 6 Sep 2004 14:16:34 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Subject: R E: Why the program complied by mips-linux-g++ cann't run on the
	target machine
Date: Mon, 6 Sep 2004 14:20:46 +0800
Message-ID: <BA3B937FD9473E41998E125463A3914301CA5774@cnmail01.cn.utstarcom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why the program complied by mips-linux-g++ cann't run on the
	target machine
Thread-Index: AcSTHtq6essUq055Q1S8O5F3vWD+HgAuezAA
From: "Li Shishan" <lishishan@utstar.com>
To: "Geert Uytterhoeven" <geert@linux-m68k.org>
X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c
	on nerdcentral
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by witte.sonytel.be id i866KjMo028945
X-Spambayes-Classification: ham; 0.00
ReSent-Date: Mon, 6 Sep 2004 11:25:06 +0200 (MEST)
ReSent-From: Geert Uytterhoeven <geert@sonycom.com>
ReSent-To: Linux/MIPS Development <linux-mips@linux-mips.org>
ReSent-Subject: R E: Why the program complied by mips-linux-g++ cann't run
 on the target machine
ReSent-Message-ID: <Pine.GSO.4.58.0409061125060.15075@waterleaf.sonytel.be>
Return-Path: <geert@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5795
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@sonycom.com
Precedence: bulk
X-list: linux-mips



  Hi:
        My  test program is coded by C, but my normal project was  coded by C++;

     If  actually   there requrie the C++ runtime library ,   Can you have any other method for it .
 
    because the C++  runtime library very huge, my  flash is limited.

    Thank you very much for reply!!!  

-----Original Message-----
From: geert@sonycom.com [mailto:geert@sonycom.com]On Behalf Of Geert Uytterhoeven
Sent: 2004年9月5日 16:03
To: Li Shishan
Cc: Linux/MIPS Development
Subject: RE: Why the program complied by mips-linux-g++ cann't run on the target machine


On Sun, 5 Sep 2004, Li Shishan wrote:
>         I am very appreciated to your reply,   thank you very  much   !!!
>
>        When I  excute  the command : ldd ./ccgame,  give result : ./ldd: not found .   what can I do for that ?

Install ldd to find out?

>         If as you say ,require the c++ runtime libraries on the target .   firstly , my  test program  is coded by  C ,not C++ , if it also require c++ libraries?

If you compile it with g++, it will need the C++ runtime library, even if the
program source is plain C:

| anakin$ cat hello.c
| #include <stdio.h>
| #include <stdlib.h>
|
| int main(int argc, char *argv[])
| {
|     printf("Hello, world! [C]\n");
|     exit(0);
| }
|
| anakin$ gcc hello.c
| anakin$ ldd a.out
|                 libc.so.6 => /lib/tls/libc.so.6 (0x41019000)
|         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x41000000)
| anakin$ mv hello.c hello.C
| anakin$ g++ hello.C
| anakin$ ldd a.out
|                 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40016000)
|         libm.so.6 => /lib/tls/libm.so.6 (0x41156000)
|         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4131a000)
|         libc.so.6 => /lib/tls/libc.so.6 (0x41019000)
|         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x41000000)
| anakin$

>  secondly, my target flash is very limited,  the C++ runtime libraries  is very large .

If it's C, why not compile it with the C compiler instead of the C++ compiler?

> -----Original Message-----
> From: geert@linux-m68k.org Geert Uytterhoeven
> Sent: 2004Äê9ÔÂ5èÕ 4:44
> To: Li Shishan
> Cc: Linux/MIPS Development
> Subject: Re: Why the program complied by mips-linux-g++ cann't run on
> the target machine
>
>
> On Sat, 4 Sep 2004, Li Shishan wrote:
> >                I  use the   mips-linux-g++  complie a program.  and I excuted it on the target machine , but cann't, what's wrong?
> >
> >               For example:
> >
> >                For PC, I use g++  -c -o ccgame.o ccgame.cpp
> > 		                    g++  -o ccgame ./ccgame.o
> > 		execute it will give: Hello, world!
> >
> > 		For the target board, I use mips-linux-g++  -c -o ccgame.o ccgame.cpp
> > 		                             mips-linux-g++  -o ccgame ./ccgame.o
> > 		excute it will give " /bin/sh: ./ccgame: not found".
> >
> > 		Is there something wrong?
>
> Look like you didn't install the C++ runtime libraries on the target.
> What does `ldd ./ccgame' say?

Gr{oetje,eeting}s,

						Geert

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

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

From ichinoh@mb.neweb.ne.jp Mon Sep  6 11:16:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 06 Sep 2004 11:16:17 +0100 (BST)
Received: from imfep03.dion.ne.jp ([IPv6:::ffff:210.174.120.149]:46555 "EHLO
	imfep03.dion.ne.jp") by linux-mips.org with ESMTP
	id <S8224941AbUIFKQN>; Mon, 6 Sep 2004 11:16:13 +0100
Received: from webmail.dion.ne.jp ([210.196.2.172]) by imfep03.dion.ne.jp
          (InterMail vM.4.01.03.31 201-229-121-131-20020322) with SMTP
          id <20040906101609.URKQ30319.imfep03.dion.ne.jp@webmail.dion.ne.jp>;
          Mon, 6 Sep 2004 19:16:09 +0900
From: ichinoh@mb.neweb.ne.jp
To: linux-mips@linux-mips.org
Date: Mon, 06 Sep 2004 19:16:09 +0900
Message-Id: <1094465769.18729@157.120.127.3.DIONWebMail>
Subject: Construction of QTOPIA
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: 5796
X-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 tried to build about QT-E and QTOPIA of Trolltech.

Please let me know the optimal version of binutil for building these, and gcc and glibc.

The version of QT is shown below.
QT-Embededd-2.3.7
qtopia-free-1.7.0

In addition, CPU is AU1100.

Regards,
Nyauyama.


From thomas@the-doors.enix.org Tue Sep  7 17:49:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Sep 2004 17:49:17 +0100 (BST)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:32645 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8225002AbUIGQtN>; Tue, 7 Sep 2004 17:49:13 +0100
Received: by the-doors.enix.org (Postfix, from userid 1105)
	id 082871EFF8; Tue,  7 Sep 2004 18:49:03 +0200 (CEST)
Date: Tue, 7 Sep 2004 18:49:03 +0200
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
To: linux-mips@linux-mips.org
Subject: Missing include/asm-mips/reg.h ?
Message-ID: <20040907164903.GB32393@enix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <thomas@the-doors.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: 5797
X-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

Hello,

While trying to compile uClibc, I get an error concerning Linux kernel
headers. The file include/asm-mips/user.h includes the file asm/reg.h,
but the file include/asm-mips/reg.h doesn't exist. So the EF_SIZE symbol
required by the definition of the user structure is not declared.

I checked the linux-mips CVS but couldn't find this file.

How should I proceed ?

Thanks,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org 
http://thomas.enix.org - Jabber: kos_tom@sourcecode.de
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

From ica2_ts@csv.ica.uni-stuttgart.de Tue Sep  7 20:00:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Sep 2004 20:00:49 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:57349
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225003AbUIGTAp>; Tue, 7 Sep 2004 20:00:45 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail)
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1C4lCu-00033G-00; Tue, 07 Sep 2004 21:00:44 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1C4lCs-0007mm-00; Tue, 07 Sep 2004 21:00:42 +0200
Date: Tue, 7 Sep 2004 21:00:42 +0200
To: Thomas Petazzoni <thomas.petazzoni@enix.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Missing include/asm-mips/reg.h ?
Message-ID: <20040907190042.GB31790@rembrandt.csv.ica.uni-stuttgart.de>
References: <20040907164903.GB32393@enix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040907164903.GB32393@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: 5798
X-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

Thomas Petazzoni wrote:
> Hello,
> 
> While trying to compile uClibc, I get an error concerning Linux kernel
> headers. The file include/asm-mips/user.h includes the file asm/reg.h,
> but the file include/asm-mips/reg.h doesn't exist. So the EF_SIZE symbol
> required by the definition of the user structure is not declared.
> 
> I checked the linux-mips CVS but couldn't find this file.
> 
> How should I proceed ?

Use configured headers. reg.h starts with:

#ifndef _ASM_REG_H
#define _ASM_REG_H
/*
 * DO NOT MODIFY.
 *
 * This file was generated by arch/mips/Makefile
 *
 */


Thiemo

From glennrbarry@optusnet.com.au Wed Sep  8 05:12:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Sep 2004 05:12:12 +0100 (BST)
Received: from mail04.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.185]:2432
	"EHLO mail04.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8224907AbUIHEMH>; Wed, 8 Sep 2004 05:12:07 +0100
Received: from [10.1.1.3] (d211-31-77-55.dsl.nsw.optusnet.com.au [211.31.77.55] (may be forged))
	(authenticated bits=0)
	by mail04.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id i884BwrX005988
	for <linux-mips@linux-mips.org>; Wed, 8 Sep 2004 14:11:58 +1000
Message-ID: <413E84E2.4060401@optusnet.com.au>
Date: Wed, 08 Sep 2004 14:04:50 +1000
From: Glenn Barry <glennrbarry@optusnet.com.au>
Reply-To: glennrbarry@optusnet.com.au
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: SGI O2 Prom modification
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <glennrbarry@optusnet.com.au>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5799
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: glennrbarry@optusnet.com.au
Precedence: bulk
X-list: linux-mips

Hi There,

I have two questions related to MIPS which someone may be able to help 
with. Sorry for the long post.

Firstly I don't know if you've heard about the upgrading of the RM5200 
300MHz CPU modules in SGI O2's with RM7000C 600MHz chips.

You can read about it at www.nekochan.net.

My question is about the possibility of someone helping out with 
modifying the O2's PROM to recognise the RM7900 CPU from PMC-Sierra.

Currently the RM7000C running at 600Mhz is a working modification. The 
RM7900 runs at up to 900Mhz and would breathe new life into the little O2's.

Details from a post on nekochan.net as to what needs to be done:

http://forums.nekochan.net/viewtopic.php?t=3314

This guy was the one who has pioneered all of the CPU upgrades currently 
going on with SGI machines.

"For the O2, when you start the computer the CPU board reads the data 
from the boot-mode PROM chip (the Xilinx chip) into specific registers 
on the CPU chip and does a Power On Self Test (POST). If the POST 
passes, the ip32PROM then reads that data from the specific CPU chip 
registers and checks that the CPU module is returning data values the 
ip32PROM recognizes and passes those data values on to IRIX for the 
system. The problem is that the data is in different registers and has 
different values for the RM7900 series of chips than the RM7000 series 
of chips. The RM7000 chips and the RM5270 chips use the same data 
registers so the ip32PROM sees the RM7000 chips just fine, not so with 
the RM7900 chips. When ip32PROM does not see a data value it recognizes 
(for whatever reason), it halts the system at that point.
So at least three things need to be done to get this project back on track:
1.) a way needs to be found to tell the ip32PROM the correct registers 
to look in for the data on the RM7900 CPU chip
2.) new values need to be added to the ip32PROM's list of possibe data 
values for a couple of items
3.) the setup for the L2 cache in the ip32PROM needs to be changed as 
the RM7900 chips start the cache memory at a different memory location 
than the RM7000 chips
If there is someone out there who understands the ip32PROM and how to 
modify the bin file, I will help them any way I can but the software 
part of this is beyond my understanding."

If anyone can help out with this, or know someone who can help, it would 
be much apreciated.

Secondly.

Not having played with Linux on my O2, I don't know the details, but are 
you able to run dual monitors with a second video card in the PCI slot?

If so does anyone think it would be possible to port a video card driver 
to Irix to be able run a second screen. Unfortunately the dualhead 
monitor adaptor isn't really an option as they are very difficult to 
find and expensive.

Thanks

Glenn

From kumba@gentoo.org Wed Sep  8 06:27:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Sep 2004 06:27:16 +0100 (BST)
Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:7909 "EHLO
	sccrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8224828AbUIHF1H>; Wed, 8 Sep 2004 06:27:07 +0100
Received: from [192.168.1.4] (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (sccrmhc11) with ESMTP
          id <20040908052658011001mg5ue>
          (Authid: kumba12345);
          Wed, 8 Sep 2004 05:26:58 +0000
Message-ID: <413E9931.8060605@gentoo.org>
Date: Wed, 08 Sep 2004 01:31:29 -0400
From: Kumba <kumba@gentoo.org>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: glennrbarry@optusnet.com.au
CC: linux-mips@linux-mips.org
Subject: Re: SGI O2 Prom modification
References: <413E84E2.4060401@optusnet.com.au>
In-Reply-To: <413E84E2.4060401@optusnet.com.au>
Content-Type: text/plain; charset=us-ascii; 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: 5800
X-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

Glenn Barry wrote:

> Hi There,
> 
> I have two questions related to MIPS which someone may be able to help 
> with. Sorry for the long post.
> 
> Firstly I don't know if you've heard about the upgrading of the RM5200 
> 300MHz CPU modules in SGI O2's with RM7000C 600MHz chips.
> 
> You can read about it at www.nekochan.net.

AFAIK, this ability isn't too supported anymore.  The guy doing this has 
apparently decided to quit.  While I'm sure this doesn't make such 
modifications impossible, it likely makes them more difficult and more expensive.

RM7000 has issues in Linux anyways.  L3 cache is disabled (atleast on the 
official SGI RM7000.  Not sure if the 600MHz R7000 has an L3 cache as well), 
and the scsi system isn't working in this system yet.  There's possibly 
others, but so few people have access to these kinds of machines that it makes 
testing diffcult.


> My question is about the possibility of someone helping out with 
> modifying the O2's PROM to recognise the RM7900 CPU from PMC-Sierra.

This would quite likely require direct access to the source code of the IP32 
PROM.  I think only IRIX developers have this access, and there are likely 
license issues that would get in the way of modifying such code to allow for 
detection of the RM7900

Modifying the binary is most assuredly way more difficult than gaining access 
to ip32PROM source and modifying it directly (and solving license issues). 
The level of change to the binary needed to make the ip32PROM detect a new CPU 
would require extremely detailed knowledge of the binary format the ip32PROM 
is in, SGI O2 systems, and how the PROM even functions.  I'd wager a guess 
that a super-skilled SGI engineer might possibly pull this off, given enough 
caffeine.


> Not having played with Linux on my O2, I don't know the details, but are 
> you able to run dual monitors with a second video card in the PCI slot?

Very unlikely in the current state, most video cards require initialization 
from an x86 bios to function.  There are ways around that, but then there's 
the problem of the O2 PCI slot not operating at 100%.


> If so does anyone think it would be possible to port a video card driver 
> to Irix to be able run a second screen. Unfortunately the dualhead 
> monitor adaptor isn't really an option as they are very difficult to 
> find and expensive.

About the only guy who can pull something like that off currently is Stan, the 
guy who did the Octane port, since he reverse-engineered the Impact card on 
Octanes.  Short of that, not without documentation, and alot of time.  And 
you'll need more weight than that in the core of a neutron star to get SGI to 
dig up those docs (since they're probably lost in a black hole anyways).


--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 cgs@ldsys.net Wed Sep  8 06:28:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Sep 2004 06:28:22 +0100 (BST)
Received: from one.ldsys.net ([IPv6:::ffff:208.176.63.109]:31244 "EHLO
	one.chi.ldsys.net") by linux-mips.org with ESMTP
	id <S8225074AbUIHF2L>; Wed, 8 Sep 2004 06:28:11 +0100
Received: from sex-machine.chi.ldsys.net (sex-machine.chi.ldsys.net [10.0.1.4])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(Client did not present a certificate)
	by one.chi.ldsys.net (Postfix) with ESMTP id 8A6B834566
	for <linux-mips@linux-mips.org>; Wed,  8 Sep 2004 00:28:08 -0500 (CDT)
Subject: [PATCH] statfs64/fstatfs64 compat syscall and header fix
From: "Christopher G. Stach II" <cgs@ldsys.net>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Message-Id: <1094621285.8282.18.camel@sex-machine.chi.ldsys.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Wed, 08 Sep 2004 00:28:06 -0500
Content-Transfer-Encoding: 7bit
Return-Path: <cgs@ldsys.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: 5801
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: cgs@ldsys.net
Precedence: bulk
X-list: linux-mips

    This patch fixes the n32 and o32 syscall tables for compat statfs64
and fstatfs64.  This indirectly fixes statvfs in glibc, etc.

    The statfs.h reorganization (to align it with all of the other
arches and include/linux/statfs.h) isn't as important as the structure
size, which makes the syscalls bomb immediately.

    Also, for anyone interested, the accompanying glibc patch to update
for the updated structure order and size, as well as fix some other
problems for fstatfs64/statfs64, is at:

http://www.ldsys.net/~cgs/linux-mips/patches-20040827/usr/local/portage/sys-libs/glibc/files/2.3.4/glibc-2.3.4.20040808-mips-compat.patch

Index: arch/mips/kernel/scall64-n32.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/scall64-n32.S,v
retrieving revision 1.12
diff -u -b -B -r1.12 scall64-n32.S
--- arch/mips/kernel/scall64-n32.S      8 Jun 2004 23:54:47 -0000      
1.12
+++ arch/mips/kernel/scall64-n32.S      8 Sep 2004 05:12:37 -0000
@@ -334,8 +334,8 @@
        PTR     sys_restart_syscall
        PTR     sys_semtimedop                  /* 6215 */
        PTR     sys_fadvise64_64
-       PTR     sys_statfs64
-       PTR     sys_fstatfs64
+       PTR     compat_statfs64
+       PTR     compat_fstatfs64
        PTR     sys_sendfile64
        PTR     sys_timer_create                /* 6220 */
        PTR     sys_timer_settime
Index: arch/mips/kernel/scall64-o32.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/scall64-o32.S,v
retrieving revision 1.13
diff -u -b -B -r1.13 scall64-o32.S
--- arch/mips/kernel/scall64-o32.S      25 Aug 2004 15:08:23 -0000     
1.13
+++ arch/mips/kernel/scall64-o32.S      8 Sep 2004 05:12:37 -0000
@@ -496,8 +496,8 @@
        PTR     sys_set_tid_address
        PTR     sys_restart_syscall
        PTR     sys_fadvise64_64
-       PTR     sys_statfs64                    /* 4255 */
-       PTR     sys_fstatfs64
+       PTR     compat_statfs64                 /* 4255 */
+       PTR     compat_fstatfs64
        PTR     sys_timer_create
        PTR     sys_timer_settime
        PTR     sys_timer_gettime
Index: include/asm-mips/statfs.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/statfs.h,v
retrieving revision 1.5
diff -u -b -B -r1.5 statfs.h
--- include/asm-mips/statfs.h   10 Jan 2004 04:59:56 -0000      1.5
+++ include/asm-mips/statfs.h   8 Sep 2004 05:12:45 -0000
@@ -23,17 +23,17 @@
        long            f_type;
 #define f_fstyp f_type
        long            f_bsize;
-       long            f_frsize;       /* Fragment size - unsupported
*/
        long            f_blocks;
        long            f_bfree;
+       long            f_bavail;
        long            f_files;
        long            f_ffree;

        /* Linux specials */
-       long    f_bavail;
        __kernel_fsid_t f_fsid;
        long            f_namelen;
-       long            f_spare[6];
+       long            f_frsize;       /* Fragment size - unsupported
*/
+       long            f_spare[5];
 };

 #if (_MIPS_SIM == _MIPS_SIM_ABI32) || (_MIPS_SIM == _MIPS_SIM_NABI32)
@@ -62,17 +62,17 @@
 struct statfs64 {                      /* Same as struct statfs */
        long            f_type;
        long            f_bsize;
-       long            f_frsize;       /* Fragment size - unsupported
*/
        long            f_blocks;
        long            f_bfree;
+       long            f_bavail;
        long            f_files;
        long            f_ffree;

        /* Linux specials */
-       long    f_bavail;
        __kernel_fsid_t f_fsid;
        long            f_namelen;
-       long            f_spare[6];
+       long            f_frsize;       /* Fragment size - unsupported
*/
+       long            f_spare[5];
 };

 struct compat_statfs64 {



From glennrbarry@optusnet.com.au Wed Sep  8 06:53:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Sep 2004 06:53:46 +0100 (BST)
Received: from mail14.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.195]:56229
	"EHLO mail14.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8224829AbUIHFxl>; Wed, 8 Sep 2004 06:53:41 +0100
Received: from [10.1.1.3] (d211-31-77-55.dsl.nsw.optusnet.com.au [211.31.77.55] (may be forged))
	(authenticated bits=0)
	by mail14.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id i885rWnL022239;
	Wed, 8 Sep 2004 15:53:32 +1000
Message-ID: <413E9CB0.9020703@optusnet.com.au>
Date: Wed, 08 Sep 2004 15:46:24 +1000
From: Glenn Barry <glennrbarry@optusnet.com.au>
Reply-To: glennrbarry@optusnet.com.au
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kumba <kumba@gentoo.org>
CC: linux-mips@linux-mips.org
Subject: Re: SGI O2 Prom modification
References: <413E84E2.4060401@optusnet.com.au> <413E9931.8060605@gentoo.org>
In-Reply-To: <413E9931.8060605@gentoo.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <glennrbarry@optusnet.com.au>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5802
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: glennrbarry@optusnet.com.au
Precedence: bulk
X-list: linux-mips

Hi Kumba,

read below

Kumba wrote:

> Glenn Barry wrote:
>
>> Hi There,
>>
>> I have two questions related to MIPS which someone may be able to 
>> help with. Sorry for the long post.
>>
>> Firstly I don't know if you've heard about the upgrading of the 
>> RM5200 300MHz CPU modules in SGI O2's with RM7000C 600MHz chips.
>>
>> You can read about it at www.nekochan.net.
>
>
> AFAIK, this ability isn't too supported anymore.  The guy doing this 
> has apparently decided to quit.  While I'm sure this doesn't make such 
> modifications impossible, it likely makes them more difficult and more 
> expensive.


This modification is currently being done with RM5200 boards and 
replacing the CPU. You can read more about it at 
http://forums.nekochan.net/viewtopic.php?t=1071

The RM7000C @ 600MHx chip currently works fine in IRIX, sorry I should 
have specified that this isn't specifically related to Linux, I just 
thought that you people would have the best knnowledge of the SGI's 
outside SGI themselves, given that you've been able to port Linux to 
some of their machines.

>
> RM7000 has issues in Linux anyways.  L3 cache is disabled (atleast on 
> the official SGI RM7000.  Not sure if the 600MHz R7000 has an L3 cache 
> as well), and the scsi system isn't working in this system yet.  

The RM7000 @ 600MHz works perfectly under IRIX, I was just hoping to get 
the RM7900 @ 900MHz working under IRIX

> There's possibly others, but so few people have access to these kinds 
> of machines that it makes testing diffcult.
>
>
>> My question is about the possibility of someone helping out with 
>> modifying the O2's PROM to recognise the RM7900 CPU from PMC-Sierra.
>
>
> This would quite likely require direct access to the source code of 
> the IP32 PROM.  I think only IRIX developers have this access, and 
> there are likely license issues that would get in the way of modifying 
> such code to allow for detection of the RM7900

Hmmm...given that the O2 line is discontinued I wonder if SGI would 
really object to having the code modified.

>
> Modifying the binary is most assuredly way more difficult than gaining 
> access to ip32PROM source and modifying it directly (and solving 
> license issues). The level of change to the binary needed to make the 
> ip32PROM detect a new CPU would require extremely detailed knowledge 
> of the binary format the ip32PROM is in, SGI O2 systems, and how the 
> PROM even functions.  I'd wager a guess that a super-skilled SGI 
> engineer might possibly pull this off, given enough caffeine.

Yes that is where know how is in shortage, Chicage Joe got the hardware 
side of things sorted for the upgrade to the RM70000C @ 600MHz and there 
was no issue with the PROM as the CPU specs were identical to the RM5200 
and RM700A @300MHz..

>
>
>> Not having played with Linux on my O2, I don't know the details, but 
>> are you able to run dual monitors with a second video card in the PCI 
>> slot?
>
>
> Very unlikely in the current state, most video cards require 
> initialization from an x86 bios to function.  There are ways around 
> that, but then there's the problem of the O2 PCI slot not operating at 
> 100%.


There is a secondary video card available for the O2's (apparently) but 
with very low specs 8MB ram and something like a $2000 price tag.

So I was wondering if using an available XFree driver and possibly 
either running a second X server or proting the Xfree driver to XSGI.

>
>
>> If so does anyone think it would be possible to port a video card 
>> driver to Irix to be able run a second screen. Unfortunately the 
>> dualhead monitor adaptor isn't really an option as they are very 
>> difficult to find and expensive.
>
>
> About the only guy who can pull something like that off currently is 
> Stan, the guy who did the Octane port, since he reverse-engineered the 
> Impact card on Octanes.  Short of that, not without documentation, and 
> alot of time.  And you'll need more weight than that in the core of a 
> neutron star to get SGI to dig up those docs (since they're probably 
> lost in a black hole anyways).

This sounds familiar, it;'s a shame SGI doesn't give more 
help/documentation to people working with thier older machines, though I 
can understand it not being financially feasible.

Glenn

>
>
> --Kumba
>


From thomas@the-doors.enix.org Wed Sep  8 08:04:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Sep 2004 08:04:58 +0100 (BST)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:37789 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8224829AbUIHHEy>; Wed, 8 Sep 2004 08:04:54 +0100
Received: by the-doors.enix.org (Postfix, from userid 1105)
	id 936711EF6D; Wed,  8 Sep 2004 09:04:48 +0200 (CEST)
Date: Wed, 8 Sep 2004 09:04:48 +0200
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
To: linux-mips@linux-mips.org
Cc: dank@kegel.com
Subject: Re: Missing include/asm-mips/reg.h ?
Message-ID: <20040908070448.GS32393@enix.org>
References: <20040907164903.GB32393@enix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040907164903.GB32393@enix.org>
User-Agent: Mutt/1.5.4i
Return-Path: <thomas@the-doors.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: 5803
X-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

Hello,

On Tue, Sep 07, 2004 at 06:49:03PM +0200, Thomas Petazzoni wrote :
> While trying to compile uClibc, I get an error concerning Linux kernel
> headers. The file include/asm-mips/user.h includes the file asm/reg.h,
> but the file include/asm-mips/reg.h doesn't exist. So the EF_SIZE symbol
> required by the definition of the user structure is not declared.
> 
> I checked the linux-mips CVS but couldn't find this file.

I exchanged a couple of mails with Thiemo Seufer who tried to help solve
this problem. It appears that include/asm-mips/reg.h is automatically
generated at compile time, by the arch/mips/Makefile (prepare target).
(I use a 2.6.x kernel).

In fact, I'm trying to generate a cross-compilation chain for MIPS
(using Dan Kegel's crosstools). So, I need the kernel headers, but I'm
not able to compile the kernel since I'm generating the cross-compiler
itself.

When I try to generate the 'prepare' target in the main directory of
the kernel source tree, it starts compiling files in scripts/ using the
MIPS compiler (which isn't available at this time).

How can I generate this include/asm-mips/reg.h file (and possibly other
automatically generated includes) without starting kernel compilation ?
Of course, I provide a .config file to the kernel.

Thanks,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org 
http://thomas.enix.org - Jabber: kos_tom@sourcecode.de
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

From jbglaw@dvmwest.gt.owl.de Wed Sep  8 13:13:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Sep 2004 13:13:39 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:60103 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8224926AbUIHMNf>; Wed, 8 Sep 2004 13:13:35 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 2496F4B35D; Wed,  8 Sep 2004 14:13:33 +0200 (CEST)
Date: Wed, 8 Sep 2004 14:13:33 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: SGI O2 Prom modification
Message-ID: <20040908121333.GA6985@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <413E84E2.4060401@optusnet.com.au> <413E9931.8060605@gentoo.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="hVUY+LYn0LT07sdA"
Content-Disposition: inline
In-Reply-To: <413E9931.8060605@gentoo.org>
X-Operating-System: Linux mail 2.6.8-rc4 
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.6i
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5804
X-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


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

On Wed, 2004-09-08 01:31:29 -0400, Kumba <kumba@gentoo.org>
wrote in message <413E9931.8060605@gentoo.org>:
> Glenn Barry wrote:
> >My question is about the possibility of someone helping out with=20
> >modifying the O2's PROM to recognise the RM7900 CPU from PMC-Sierra.
>=20
> Modifying the binary is most assuredly way more difficult than gaining=20
> access to ip32PROM source and modifying it directly (and solving license=
=20
> issues). The level of change to the binary needed to make the ip32PROM=20

I'd not bet my a** on that. Modifying the binary firmware has got a=20
long, but rare, history. I remeber hacked PROM images for VAXen to
support larger SCSI disks. As long as you don't require a detailled CPU
detection, that should be possible. Hardcoding some values isn't all
thaaat hard. Making it correctly (preserving the formerly running
detection code for other CPUs) is a bit harder, of course :-)

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=FCrger" | im Internet! |   im Irak! =
  O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--hVUY+LYn0LT07sdA
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)

iD8DBQFBPvdsHb1edYOZ4bsRAiNFAJ0c0gaaXpLQNRDexg96xJGfCHzxLACbByRK
jaLTn+870/irCBtBg2c2aaU=
=lDqL
-----END PGP SIGNATURE-----

--hVUY+LYn0LT07sdA--

From robbat2@orbis-terrarum.net Wed Sep  8 22:21:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Sep 2004 22:21:14 +0100 (BST)
Received: from shawidc-mo1.cg.shawcable.net ([IPv6:::ffff:24.71.223.10]:18141
	"EHLO pd3mo1so.prod.shaw.ca") by linux-mips.org with ESMTP
	id <S8225004AbUIHVVK>; Wed, 8 Sep 2004 22:21:10 +0100
Received: from pd2mr4so.prod.shaw.ca
 (pd2mr4so-qfe3.prod.shaw.ca [10.0.141.107]) by l-daemon
 (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004))
 with ESMTP id <0I3Q00A1MR54NO30@l-daemon> for linux-mips@linux-mips.org; Wed,
 08 Sep 2004 15:17:28 -0600 (MDT)
Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145])
 by pd2mr4so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar
 15 2004)) with ESMTP id <0I3Q00ISRR54CRC0@pd2mr4so.prod.shaw.ca> for
 linux-mips@linux-mips.org; Wed, 08 Sep 2004 15:17:28 -0600 (MDT)
Received: from curie.orbis-terrarum.net
 (S01060050da688d47.vc.shawcable.net [24.80.109.92])
 by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003))
 with ESMTP id <0I3Q00C2XR54DS@l-daemon> for linux-mips@linux-mips.org; Wed,
 08 Sep 2004 15:17:28 -0600 (MDT)
Received: (qmail 14694 invoked by uid 10000); Wed, 08 Sep 2004 14:17:28 -0700
Date: Wed, 08 Sep 2004 14:17:28 -0700
From: "Robin H. Johnson" <robbat2@gentoo.org>
Subject: Re: SGI O2 Prom modification
In-reply-to: <413E9CB0.9020703@optusnet.com.au>
To: Glenn Barry <glennrbarry@optusnet.com.au>
Cc: linux-mips@linux-mips.org
Mail-followup-to: Glenn Barry <glennrbarry@optusnet.com.au>,
 linux-mips@linux-mips.org
Message-id: <20040908211728.GB3955@curie-int.orbis-terrarum.net>
MIME-version: 1.0
Content-type: multipart/signed; boundary=JWEK1jqKZ6MHAcjA;
 protocol="application/pgp-signature"; micalg=pgp-sha1
Content-disposition: inline
References: <413E84E2.4060401@optusnet.com.au> <413E9931.8060605@gentoo.org>
 <413E9CB0.9020703@optusnet.com.au>
User-Agent: Mutt/1.5.6i
Return-Path: <robbat2@orbis-terrarum.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: 5805
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: robbat2@gentoo.org
Precedence: bulk
X-list: linux-mips


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

On Wed, Sep 08, 2004 at 03:46:24PM +1000, Glenn Barry wrote:
> >AFAIK, this ability isn't too supported anymore.  The guy doing this=20
> >has apparently decided to quit.  While I'm sure this doesn't make such=
=20
> >modifications impossible, it likely makes them more difficult and more=
=20
> >expensive.
> This modification is currently being done with RM5200 boards and=20
> replacing the CPU. You can read more about it at=20
> http://forums.nekochan.net/viewtopic.php?t=3D1071
>=20
> The RM7000C @ 600MHx chip currently works fine in IRIX, sorry I should=20
> have specified that this isn't specifically related to Linux, I just=20
> thought that you people would have the best knnowledge of the SGI's=20
> outside SGI themselves, given that you've been able to port Linux to=20
> some of their machines.
Kumba and I do know all about the RM7000C work, as we are frequent
visitors to nekochan.

What Kumba was referring to what the mid-August post by ChicagoJoe (on
page 14) stating that the company that had been doing the BGA chip
replacement is not taking on any more work.

> >This would quite likely require direct access to the source code of=20
> >the IP32 PROM.  I think only IRIX developers have this access, and=20
> >there are likely license issues that would get in the way of modifying=
=20
> >such code to allow for detection of the RM7900
> Hmmm...given that the O2 line is discontinued I wonder if SGI would=20
> really object to having the code modified.
To get the PROM source, you'd really have to be in bed with SGI, as many
other folk from here have asked for a lot less and had no success.

--=20
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=3Dpeople.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Robbat2 @ Orbis-Terrarum Networks

iD8DBQFBP3boPpIsIjIzwiwRAjs9AJ4lp+k4D6BGVFC6KjtNBqiUQPCKmwCgoFty
gCwQCkhrbcOKRPIW01HVEtM=
=vmLt
-----END PGP SIGNATURE-----

--JWEK1jqKZ6MHAcjA--

From glennrbarry@optusnet.com.au Wed Sep  8 22:43:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Sep 2004 22:43:35 +0100 (BST)
Received: from mail19.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.200]:40922
	"EHLO mail19.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8225004AbUIHVna>; Wed, 8 Sep 2004 22:43:30 +0100
Received: from [10.1.1.3] (d211-31-77-55.dsl.nsw.optusnet.com.au [211.31.77.55])
	(authenticated bits=0)
	by mail19.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id i88LhIqP003312;
	Thu, 9 Sep 2004 07:43:24 +1000
Message-ID: <413F7B4A.8090108@optusnet.com.au>
Date: Thu, 09 Sep 2004 07:36:10 +1000
From: Glenn Barry <glennrbarry@optusnet.com.au>
Reply-To: glennrbarry@optusnet.com.au
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Robin H. Johnson" <robbat2@gentoo.org>
CC: linux-mips@linux-mips.org
Subject: Re: SGI O2 Prom modification
References: <413E84E2.4060401@optusnet.com.au> <413E9931.8060605@gentoo.org> <413E9CB0.9020703@optusnet.com.au> <20040908211728.GB3955@curie-int.orbis-terrarum.net>
In-Reply-To: <20040908211728.GB3955@curie-int.orbis-terrarum.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <glennrbarry@optusnet.com.au>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5806
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: glennrbarry@optusnet.com.au
Precedence: bulk
X-list: linux-mips

Hi Robin,

O.K. I misunderstood when I thought that Kumba misunderstood. D'OH.

I think that our biggest hope is to find someone that maybe worked on 
the O2 development, one of the engineers maybe, that would like to see 
the O2 evolve to its ultimate potential. It might not involve getting 
the source code if they did the mod for us, but knowing who in 
particular to ask in the first place is the real challenge..

Glenn

Robin H. Johnson wrote:

>On Wed, Sep 08, 2004 at 03:46:24PM +1000, Glenn Barry wrote:
>  
>
>>>AFAIK, this ability isn't too supported anymore.  The guy doing this 
>>>has apparently decided to quit.  While I'm sure this doesn't make such 
>>>modifications impossible, it likely makes them more difficult and more 
>>>expensive.
>>>      
>>>
>>This modification is currently being done with RM5200 boards and 
>>replacing the CPU. You can read more about it at 
>>http://forums.nekochan.net/viewtopic.php?t=1071
>>
>>The RM7000C @ 600MHx chip currently works fine in IRIX, sorry I should 
>>have specified that this isn't specifically related to Linux, I just 
>>thought that you people would have the best knnowledge of the SGI's 
>>outside SGI themselves, given that you've been able to port Linux to 
>>some of their machines.
>>    
>>
>Kumba and I do know all about the RM7000C work, as we are frequent
>visitors to nekochan.
>
>What Kumba was referring to what the mid-August post by ChicagoJoe (on
>page 14) stating that the company that had been doing the BGA chip
>replacement is not taking on any more work.
>
>  
>
>>>This would quite likely require direct access to the source code of 
>>>the IP32 PROM.  I think only IRIX developers have this access, and 
>>>there are likely license issues that would get in the way of modifying 
>>>such code to allow for detection of the RM7900
>>>      
>>>
>>Hmmm...given that the O2 line is discontinued I wonder if SGI would 
>>really object to having the code modified.
>>    
>>
>To get the PROM source, you'd really have to be in bed with SGI, as many
>other folk from here have asked for a lot less and had no success.
>
>  
>


From charles.eidsness@ieee.org Thu Sep  9 20:09:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Sep 2004 20:09:30 +0100 (BST)
Received: from smtp105.rog.mail.re2.yahoo.com ([IPv6:::ffff:206.190.36.83]:5470
	"HELO smtp105.rog.mail.re2.yahoo.com") by linux-mips.org with SMTP
	id <S8225072AbUIITJX>; Thu, 9 Sep 2004 20:09:23 +0100
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 Sep 2004 19:09:14 -0000
Message-ID: <4140AA56.2050903@ieee.org>
Date: Thu, 09 Sep 2004 15:09:10 -0400
From: Charles Eidsness <charles.eidsness@ieee.org>
Reply-To: charles.eidsness@ieee.org
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pete Popov <pete_popov@yahoo.com>
CC: linux-mips@linux-mips.org
Subject: Re: Au1000 AC97 ALSA Driver
References: <40CB2FAF.3050807@ieee.org> <1087103071.1432.3.camel@thinkpad>
In-Reply-To: <1087103071.1432.3.camel@thinkpad>
Content-Type: text/plain; charset=us-ascii; 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: 5807
X-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

I've been testing this driver for a while now and I think I've worked 
out most of the bugs.

If any one's interested they can find the source code here:
http://members.rogers.com/charles.eidsness/au1000.c

A patch that adds the code plus edits the KConfig Makefiles here:
http://members.rogers.com/charles.eidsness/au1000_alsa.patch

To compile it as a module you'll probably need this little patch to the 
au1000's dma.c.
http://members.rogers.com/charles.eidsness/au1000_dma_module.patch

In order for this driver to work you'll of course need the ALSA drivers 
as well so it will only work on kernel 2.6+, unless you add them to 
pre-2.6. I also recommend updating the ALSA drivers that come with the 
kernel from 1.0.4 to the latest, all of my testing was performed using 
ALSA drivers 1.0.5a, but it will probably run fine on 1.0.4.

In order to use most of the ALSA applications out there you will also 
need an alsa.conf somewhere. You'll need to "export 
ALSA_CONFIG_PATH=/....../alsa.conf" sometime too so all your apps know 
where to find your alsa.conf file, like during boot (in .profile for 
example). Here's the alsa.conf file I've been using.
http://members.rogers.com/charles.eidsness/alsa.conf

Cheers,
Charles


Pete Popov wrote:

> On Sat, 2004-06-12 at 09:30, Charles Eidsness wrote:
> 
>>I've been working on an ALSA driver for the Au1000 processor AC'97 port. 
>>Specifically for the DBAu1000 Merlot eval card. It seems to be working 
>>in OSS emulation mode, I'm having a few problems setting up my system to 
>>work in ALSA native mode, and it contains only a minimum of features. 
>>i.e. it's still a work in progress, but I thought there may be someone 
>>else out there interested in it.
>>
>>I've posted a patch that should add a mips sub-directory in the sound 
>>directory of the 2.6.6 kernel and add an au1000 sound option to the 
>>kernel configuration menu here: 
>>http://members.rogers.com/charles.eidsness/au1000_alsa.patch
>>
>>Alternately you can find just the source code here:
>>http://members.rogers.com/charles.eidsness/au1000.c
> 
> 
> Great -- let me know when the driver is ready to be checked in :)
> 
> Pete
> 
> 
> 

From ppopov@mvista.com Thu Sep  9 21:16:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Sep 2004 21:16:13 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:22523 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225196AbUIIUQJ>;
	Thu, 9 Sep 2004 21:16:09 +0100
Received: from [10.0.10.221] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id NAA01297;
	Thu, 9 Sep 2004 13:16:01 -0700
Message-ID: <4140BA01.4050607@mvista.com>
Date: Thu, 09 Sep 2004 13:16:01 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: charles.eidsness@ieee.org
CC: ppopov@embeddedalley.com, linux-mips@linux-mips.org
Subject: Re: Au1000 AC97 ALSA Driver
References: <40CB2FAF.3050807@ieee.org> <1087103071.1432.3.camel@thinkpad> <4140AA56.2050903@ieee.org>
In-Reply-To: <4140AA56.2050903@ieee.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5808
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

Charles,

Awesome, thanks -- I'll take a look at it later. I was going to do this 
work soon so ... thanks :)

Pete

Charles Eidsness wrote:

> I've been testing this driver for a while now and I think I've worked 
> out most of the bugs.
>
> If any one's interested they can find the source code here:
> http://members.rogers.com/charles.eidsness/au1000.c
>
> A patch that adds the code plus edits the KConfig Makefiles here:
> http://members.rogers.com/charles.eidsness/au1000_alsa.patch
>
> To compile it as a module you'll probably need this little patch to 
> the au1000's dma.c.
> http://members.rogers.com/charles.eidsness/au1000_dma_module.patch
>
> In order for this driver to work you'll of course need the ALSA 
> drivers as well so it will only work on kernel 2.6+, unless you add 
> them to pre-2.6. I also recommend updating the ALSA drivers that come 
> with the kernel from 1.0.4 to the latest, all of my testing was 
> performed using ALSA drivers 1.0.5a, but it will probably run fine on 
> 1.0.4.
>
> In order to use most of the ALSA applications out there you will also 
> need an alsa.conf somewhere. You'll need to "export 
> ALSA_CONFIG_PATH=/....../alsa.conf" sometime too so all your apps know 
> where to find your alsa.conf file, like during boot (in .profile for 
> example). Here's the alsa.conf file I've been using.
> http://members.rogers.com/charles.eidsness/alsa.conf
>
> Cheers,
> Charles
>
>
> Pete Popov wrote:
>
>> On Sat, 2004-06-12 at 09:30, Charles Eidsness wrote:
>>
>>> I've been working on an ALSA driver for the Au1000 processor AC'97 
>>> port. Specifically for the DBAu1000 Merlot eval card. It seems to be 
>>> working in OSS emulation mode, I'm having a few problems setting up 
>>> my system to work in ALSA native mode, and it contains only a 
>>> minimum of features. i.e. it's still a work in progress, but I 
>>> thought there may be someone else out there interested in it.
>>>
>>> I've posted a patch that should add a mips sub-directory in the 
>>> sound directory of the 2.6.6 kernel and add an au1000 sound option 
>>> to the kernel configuration menu here: 
>>> http://members.rogers.com/charles.eidsness/au1000_alsa.patch
>>>
>>> Alternately you can find just the source code here:
>>> http://members.rogers.com/charles.eidsness/au1000.c
>>
>>
>>
>> Great -- let me know when the driver is ready to be checked in :)
>>
>> Pete
>>
>>
>>
>


From peter@pantasys.com Thu Sep  9 21:50:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Sep 2004 21:50:32 +0100 (BST)
Received: from 64-60-250-34.cust.telepacific.net ([IPv6:::ffff:64.60.250.34]:11072
	"EHLO panta-1.pantasys.com") by linux-mips.org with ESMTP
	id <S8225196AbUIIUu2>; Thu, 9 Sep 2004 21:50:28 +0100
Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 9 Sep 2004 13:43:33 -0700
Message-ID: <4140C205.7020405@pantasys.com>
Date: Thu, 09 Sep 2004 13:50:13 -0700
From: Peter Buckingham <peter@pantasys.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Subject: [PATCH 2.6] make the bcm1250 work
Content-Type: multipart/mixed;
 boundary="------------070608060601050109010704"
X-OriginalArrivalTime: 09 Sep 2004 20:43:33.0500 (UTC) FILETIME=[AC2793C0:01C496AD]
Return-Path: <peter@pantasys.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5809
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: peter@pantasys.com
Precedence: bulk
X-list: linux-mips

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

Hi Ralf,

I have been playing with a bcm1250 from broadcom. These are patches I 
needed to get things to compile correctly. After applying the to patches 
above I can build fine.

thanks,

peter

Signed-off-by: Peter Buckingham <peter@pantasys.com>

--------------070608060601050109010704
Content-Type: text/plain;
 name="p"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="p"

Index: arch/mips/sibyte/sb1250/prom.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sibyte/sb1250/prom.c,v
retrieving revision 1.9
diff -p -u -r1.9 prom.c
--- arch/mips/sibyte/sb1250/prom.c	28 Jan 2004 22:16:39 -0000	1.9
+++ arch/mips/sibyte/sb1250/prom.c	9 Sep 2004 18:42:13 -0000
@@ -29,6 +29,7 @@
 
 #ifdef CONFIG_EMBEDDED_RAMDISK
 /* These are symbols defined by the ramdisk linker script */
+extern unsigned long initrd_start, initrd_end;
 extern unsigned char __rd_start;
 extern unsigned char __rd_end;
 #endif
Index: arch/mips/sibyte/swarm/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sibyte/swarm/setup.c,v
retrieving revision 1.31
diff -p -u -r1.31 setup.c
--- arch/mips/sibyte/swarm/setup.c	26 Aug 2004 20:18:00 -0000	1.31
+++ arch/mips/sibyte/swarm/setup.c	9 Sep 2004 18:42:13 -0000
@@ -27,6 +27,7 @@
 #include <linux/bootmem.h>
 #include <linux/blkdev.h>
 #include <linux/init.h>
+#include <linux/tty.h>
 
 #include <asm/irq.h>
 #include <asm/io.h>
@@ -50,6 +51,11 @@ extern int m41t81_probe(void);
 extern int m41t81_set_time(unsigned long);
 extern unsigned long m41t81_get_time(void);
 
+#ifdef CONFIG_BLK_DEV_INITRD
+extern unsigned long initrd_start, initrd_end;
+extern void * __rd_start, * __rd_end;
+#endif
+
 const char *get_system_type(void)
 {
 	return "SiByte " SIBYTE_BOARD_NAME;

--------------070608060601050109010704
Content-Type: text/plain;
 name="p1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="p1"

Index: arch/mips/pci/pci-sb1250.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/pci/pci-sb1250.c,v
retrieving revision 1.9
diff -p -u -r1.9 pci-sb1250.c
--- arch/mips/pci/pci-sb1250.c	26 Aug 2004 20:18:00 -0000	1.9
+++ arch/mips/pci/pci-sb1250.c	9 Sep 2004 18:45:11 -0000
@@ -37,6 +37,7 @@
 #include <linux/init.h>
 #include <linux/mm.h>
 #include <linux/console.h>
+#include <linux/tty.h> //pmb 20040824
 
 #include <asm/io.h>
 

--------------070608060601050109010704--

From peter@pantasys.com Thu Sep  9 21:54:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Sep 2004 21:54:15 +0100 (BST)
Received: from 64-60-250-34.cust.telepacific.net ([IPv6:::ffff:64.60.250.34]:19008
	"EHLO panta-1.pantasys.com") by linux-mips.org with ESMTP
	id <S8225196AbUIIUyL>; Thu, 9 Sep 2004 21:54:11 +0100
Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 9 Sep 2004 13:47:17 -0700
Message-ID: <4140C2E5.6050006@pantasys.com>
Date: Thu, 09 Sep 2004 13:53:57 -0700
From: Peter Buckingham <peter@pantasys.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Subject: [PATCH 2.6] make nfsroot compile
Content-Type: multipart/mixed;
 boundary="------------020201010202050109090506"
X-OriginalArrivalTime: 09 Sep 2004 20:47:17.0359 (UTC) FILETIME=[3195BFF0:01C496AE]
Return-Path: <peter@pantasys.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5810
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: peter@pantasys.com
Precedence: bulk
X-list: linux-mips

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

Hi Ralf,

I needed to merge this fix in from Linus's tree to make things work with 
a NFS root. Now I can boot up broadcom's 1250 :-D

peter

Signed-off-by: Peter Buckingham <peter@pantasys.com>

--------------020201010202050109090506
Content-Type: text/plain;
 name="p"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="p"

Index: fs/nfs/nfsroot.c
===================================================================
RCS file: /home/cvs/linux/fs/nfs/nfsroot.c,v
retrieving revision 1.30
diff -u -r1.30 nfsroot.c
--- fs/nfs/nfsroot.c	24 Aug 2004 15:10:14 -0000	1.30
+++ fs/nfs/nfsroot.c	9 Sep 2004 20:53:56 -0000
@@ -495,8 +495,10 @@
 	if (status < 0)
 		printk(KERN_ERR "Root-NFS: Server returned error %d "
 				"while mounting %s\n", status, nfs_path);
-	else
-		nfs_copy_fh(nfs_data.root, fh);
+	else {
+		nfs_data.root.size=fh.size;
+		memcpy(nfs_data.root.data, fh.data, fh.size);
+	}
 
 	return status;
 }

--------------020201010202050109090506--

From peter@pantasys.com Thu Sep  9 21:57:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Sep 2004 21:57:14 +0100 (BST)
Received: from 64-60-250-34.cust.telepacific.net ([IPv6:::ffff:64.60.250.34]:25920
	"EHLO panta-1.pantasys.com") by linux-mips.org with ESMTP
	id <S8225203AbUIIU5J>; Thu, 9 Sep 2004 21:57:09 +0100
Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 9 Sep 2004 13:50:15 -0700
Message-ID: <4140C398.5070307@pantasys.com>
Date: Thu, 09 Sep 2004 13:56:56 -0700
From: Peter Buckingham <peter@pantasys.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Buckingham <peter@pantasys.com>
CC: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH 2.6] make the bcm1250 work
References: <4140C205.7020405@pantasys.com>
In-Reply-To: <4140C205.7020405@pantasys.com>
Content-Type: multipart/mixed;
 boundary="------------010800030904020308090704"
X-OriginalArrivalTime: 09 Sep 2004 20:50:15.0578 (UTC) FILETIME=[9BCFCFA0:01C496AE]
Return-Path: <peter@pantasys.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5811
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: peter@pantasys.com
Precedence: bulk
X-list: linux-mips

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

Hi Ralf,

the second patch has some cruft in it. could you apply the
following instead.

thanks,

peter

Signed-off-by: Peter Buckingham <peter@pantasys.com>


--------------010800030904020308090704
Content-Type: text/plain;
 name="p1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="p1"

Index: arch/mips/pci/pci-sb1250.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/pci/pci-sb1250.c,v
retrieving revision 1.9
diff -p -u -r1.9 pci-sb1250.c
--- arch/mips/pci/pci-sb1250.c	26 Aug 2004 20:18:00 -0000	1.9
+++ arch/mips/pci/pci-sb1250.c	9 Sep 2004 20:55:20 -0000
@@ -37,6 +37,7 @@
 #include <linux/init.h>
 #include <linux/mm.h>
 #include <linux/console.h>
+#include <linux/tty.h>
 
 #include <asm/io.h>
 

--------------010800030904020308090704--

From hch@lst.de Fri Sep 10 08:56:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Sep 2004 08:56:51 +0100 (BST)
Received: from verein.lst.de ([IPv6:::ffff:213.95.11.210]:19679 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8224953AbUIJH4r>;
	Fri, 10 Sep 2004 08:56:47 +0100
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i8A7uj95027633
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 10 Sep 2004 09:56:45 +0200
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i8A7uiEV027631;
	Fri, 10 Sep 2004 09:56:44 +0200
Date: Fri, 10 Sep 2004 09:56:44 +0200
From: Christoph Hellwig <hch@lst.de>
To: Peter Buckingham <peter@pantasys.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH 2.6] make the bcm1250 work
Message-ID: <20040910075644.GA27574@lst.de>
References: <4140C205.7020405@pantasys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4140C205.7020405@pantasys.com>
User-Agent: Mutt/1.3.28i
X-Spam-Score: -4.901 () BAYES_00
X-Scanned-By: MIMEDefang 2.39
Return-Path: <hch@lst.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: 5812
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@lst.de
Precedence: bulk
X-list: linux-mips

>  #ifdef CONFIG_EMBEDDED_RAMDISK
>  /* These are symbols defined by the ramdisk linker script */
> +extern unsigned long initrd_start, initrd_end;
>  extern unsigned char __rd_start;
>  extern unsigned char __rd_end;

Please use the appropinquate header for these.

> +#ifdef CONFIG_BLK_DEV_INITRD
> +extern unsigned long initrd_start, initrd_end;
> +extern void * __rd_start, * __rd_end;
> +#endif

dito.


From em@realmagic.fr Fri Sep 10 11:16:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Sep 2004 11:16:08 +0100 (BST)
Received: from c2ce9fba.adsl.oleane.fr ([IPv6:::ffff:194.206.159.186]:7079
	"EHLO nikita.france.sdesigns.com") by linux-mips.org with ESMTP
	id <S8224953AbUIJKQE>; Fri, 10 Sep 2004 11:16:04 +0100
Received: from nikita.france.sdesigns.com (localhost.localdomain [127.0.0.1])
	by nikita.france.sdesigns.com (8.12.11/8.12.11) with ESMTP id i8AAFxKp018478;
	Fri, 10 Sep 2004 12:15:59 +0200
Received: (from michon@localhost)
	by nikita.france.sdesigns.com (8.12.11/8.12.11/Submit) id i8AAFwet018477;
	Fri, 10 Sep 2004 12:15:58 +0200
X-Authentication-Warning: nikita.france.sdesigns.com: michon set sender to em@realmagic.fr using -f
Subject: ...cache dimensioning ;-)
From: Emmanuel Michon <em@realmagic.fr>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: REALmagic France SAS
Message-Id: <1094811358.29872.8745.camel@nikita.france.sdesigns.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Fri, 10 Sep 2004 12:15:58 +0200
Return-Path: <em@realmagic.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: 5813
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: em@realmagic.fr
Precedence: bulk
X-list: linux-mips

Hi,

I'm still in the process of choosing the best configurable parameters of
a hardware design based on 4KEc

As far as I understand, excepted alpha platforms, 4KByte pages are the
de facto standard [I assume linux developers are reasonable so changing
the page size to 8KB is not going to be a nightmare...]

Since the mips cache is virtually indexed but physically tagged, I see
two problems when the size of a cache way exceeds the size of a page:

- virtual aliasing. Can only happen on R/W pages (data cache) and only
when two different virtual addresses map the same physical page. An
example of this is: two processes sharing a memory area; should I
consider this is taken into account by linux already?

- I was told the software exception handlers for tlb are much less
efficient when cacheway > pagesize, forcing to flush too often. Is this
true? What is, in practice, the ratio of instruction pages and data
pages in a tlb?

If I consider a platform like Toshiba TX39 which has d-cache four ways
with total 32KBytes, it must already have the problems above. I'd like
to get some more clues though...

Thanks a lot,

Sincerely yours,

E.M.

From ralf@linux-mips.org Fri Sep 10 12:43:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Sep 2004 12:43:54 +0100 (BST)
Received: from p508B7024.dip.t-dialin.net ([IPv6:::ffff:80.139.112.36]:35409
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224953AbUIJLnu>; Fri, 10 Sep 2004 12:43:50 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i8ABhnsm011903;
	Fri, 10 Sep 2004 13:43:49 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i8ABhiBx011902;
	Fri, 10 Sep 2004 13:43:44 +0200
Date: Fri, 10 Sep 2004 13:43:43 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Emmanuel Michon <em@realmagic.fr>
Cc: linux-mips@linux-mips.org
Subject: Re: ...cache dimensioning ;-)
Message-ID: <20040910114343.GA10064@linux-mips.org>
References: <1094811358.29872.8745.camel@nikita.france.sdesigns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1094811358.29872.8745.camel@nikita.france.sdesigns.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: 5814
X-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, Sep 10, 2004 at 12:15:58PM +0200, Emmanuel Michon wrote:

> I'm still in the process of choosing the best configurable parameters of
> a hardware design based on 4KEc

Simply answer:

Linux is most happy if size_per_cache =< PAGE_SIZE * number_of_ways.

> As far as I understand, excepted alpha platforms, 4KByte pages are the
> de facto standard [I assume linux developers are reasonable so changing
> the page size to 8KB is not going to be a nightmare...]

4k may be the predominant size but by no means it's the defacto standard.

Some older ARM chips use 16k or 32k; Cris uses 8k; some 68k Suns using
the non-Motorola MMU use 8k also; sun4 and sparc64 both use 8k; IA-64 is
configurable to 4k (bad idea), 16k (prefered) and 64k.

On MIPS going for 4k was my choice in '95 ago because that's the pagesize
of the R3000 - and the i386 which eleminated a whole class of bugs in
porting.

It's now ten years later; everything is growing according to Moore's law
and some embedded systems that are considered small by today's standards
exceed what was a powerful workstation back then or even a full blown
supermini in '85 when the R2000 was created so increasig the page size
is overdue for most systems, MIPS and other.

> Since the mips cache is virtually indexed but physically tagged, I see
> two problems when the size of a cache way exceeds the size of a page:

Not all of them; it's just the most common cache policy.  There are also
PIPT caches and even VIVT I-caches.  I'll personally poke needles into
a doll of whoever should design VIVT D-caches ;-)

> - virtual aliasing. Can only happen on R/W pages (data cache) and only
> when two different virtual addresses map the same physical page. An
> example of this is: two processes sharing a memory area; should I
> consider this is taken into account by linux already?
> 
> - I was told the software exception handlers for tlb are much less
> efficient when cacheway > pagesize, forcing to flush too often. Is this
> true? What is, in practice, the ratio of instruction pages and data
> pages in a tlb?

The affected parts of memory managment are not part of the TLB exception
handlers in a strict sense but yes, on caches suffering from aliases in
situations where we can't use hit cacheops we need to flush nuber of ways
pages from the cache, so for a 4-way 32k cache that means half the cache.

Going to 16k pagesize would eleminate most such flushes entirely and as
a nice side effect also guarantee the correctness of a fairly complex
to get right piece of code by simple eleminating the need for it.

> If I consider a platform like Toshiba TX39 which has d-cache four ways
> with total 32KBytes, it must already have the problems above. I'd like
> to get some more clues though...

My paper says different numbers ...

  Ralf

From peter@pantasys.com Fri Sep 10 17:48:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Sep 2004 17:48:42 +0100 (BST)
Received: from 64-60-250-34.cust.telepacific.net ([IPv6:::ffff:64.60.250.34]:56172
	"EHLO panta-1.pantasys.com") by linux-mips.org with ESMTP
	id <S8225210AbUIJQsi>; Fri, 10 Sep 2004 17:48:38 +0100
Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 10 Sep 2004 09:41:40 -0700
Message-ID: <4141DAD6.8000802@pantasys.com>
Date: Fri, 10 Sep 2004 09:48:22 -0700
From: Peter Buckingham <peter@pantasys.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
X-Accept-Language: en
MIME-Version: 1.0
To: Christoph Hellwig <hch@lst.de>
CC: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH 2.6] make the bcm1250 work
References: <4140C205.7020405@pantasys.com> <20040910075644.GA27574@lst.de>
In-Reply-To: <20040910075644.GA27574@lst.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2004 16:41:40.0984 (UTC) FILETIME=[0C6F1F80:01C49755]
Return-Path: <peter@pantasys.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5815
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: peter@pantasys.com
Precedence: bulk
X-list: linux-mips

Hi Christoph,

Christoph Hellwig wrote:
>> #ifdef CONFIG_EMBEDDED_RAMDISK
>> /* These are symbols defined by the ramdisk linker script */
>>+extern unsigned long initrd_start, initrd_end;
>> extern unsigned char __rd_start;
>> extern unsigned char __rd_end;
> 
> 
> Please use the appropinquate header for these.

I'd love to use the appropriate header for these, but can't find one. 
cscope doesn't seem to show that these are defined usefully in a header 
file.

Can you point me to where these are defined?

thanks,

peter

From ralf@linux-mips.org Fri Sep 10 18:52:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Sep 2004 18:52:20 +0100 (BST)
Received: from p508B7024.dip.t-dialin.net ([IPv6:::ffff:80.139.112.36]:41063
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225210AbUIJRwQ>; Fri, 10 Sep 2004 18:52:16 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i8AHqF91009926;
	Fri, 10 Sep 2004 19:52:15 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i8AHqD0B009925;
	Fri, 10 Sep 2004 19:52:13 +0200
Date: Fri, 10 Sep 2004 19:52:13 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Peter Buckingham <peter@pantasys.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-mips@linux-mips.org
Subject: Re: [PATCH 2.6] make the bcm1250 work
Message-ID: <20040910175213.GA9910@linux-mips.org>
References: <4140C205.7020405@pantasys.com> <20040910075644.GA27574@lst.de> <4141DAD6.8000802@pantasys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4141DAD6.8000802@pantasys.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: 5816
X-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, Sep 10, 2004 at 09:48:22AM -0700, Peter Buckingham wrote:

> >>/* These are symbols defined by the ramdisk linker script */
> >>+extern unsigned long initrd_start, initrd_end;
> >>extern unsigned char __rd_start;
> >>extern unsigned char __rd_end;
> >
> >
> >Please use the appropinquate header for these.
> 
> I'd love to use the appropriate header for these, but can't find one. 
> cscope doesn't seem to show that these are defined usefully in a header 
> file.

Winners use grep(1) ;-)

> Can you point me to where these are defined?

Include/linux/initrd.h.

  Ralf

From peter@pantasys.com Fri Sep 10 19:04:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Sep 2004 19:04:58 +0100 (BST)
Received: from 64-60-250-34.cust.telepacific.net ([IPv6:::ffff:64.60.250.34]:45679
	"EHLO panta-1.pantasys.com") by linux-mips.org with ESMTP
	id <S8225210AbUIJSEp>; Fri, 10 Sep 2004 19:04:45 +0100
Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 10 Sep 2004 10:57:47 -0700
Message-ID: <4141ECAC.8070806@pantasys.com>
Date: Fri, 10 Sep 2004 11:04:28 -0700
From: Peter Buckingham <peter@pantasys.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: Christoph Hellwig <hch@lst.de>, linux-mips@linux-mips.org
Subject: Re: [PATCH 2.6] make the bcm1250 work
References: <4140C205.7020405@pantasys.com> <20040910075644.GA27574@lst.de> <4141DAD6.8000802@pantasys.com> <20040910175213.GA9910@linux-mips.org>
In-Reply-To: <20040910175213.GA9910@linux-mips.org>
Content-Type: multipart/mixed;
 boundary="------------010900010700090209070200"
X-OriginalArrivalTime: 10 Sep 2004 17:57:47.0718 (UTC) FILETIME=[AE6B6E60:01C4975F]
Return-Path: <peter@pantasys.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5817
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: peter@pantasys.com
Precedence: bulk
X-list: linux-mips

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

Ralf Baechle wrote:
> Winners use grep(1) ;-)

guess the old tools still work the best ;-)

> Include/linux/initrd.h.

okay, i've attached a new version of the patch. just a few questions. 
would it make sense to lift __rd_start, __rd_end into initrd.h? also 
would it make sense to add:

#ifdef __INITRD_H

etc stuff to the initrd.h?

peter

--------------010900010700090209070200
Content-Type: text/plain;
 name="p"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="p"

Index: arch/mips/pci/pci-sb1250.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/pci/pci-sb1250.c,v
retrieving revision 1.9
diff -u -r1.9 pci-sb1250.c
--- arch/mips/pci/pci-sb1250.c	26 Aug 2004 20:18:00 -0000	1.9
+++ arch/mips/pci/pci-sb1250.c	10 Sep 2004 18:01:29 -0000
@@ -37,6 +37,7 @@
 #include <linux/init.h>
 #include <linux/mm.h>
 #include <linux/console.h>
+#include <linux/tty.h>
 
 #include <asm/io.h>
 
Index: arch/mips/sibyte/sb1250/prom.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sibyte/sb1250/prom.c,v
retrieving revision 1.9
diff -u -r1.9 prom.c
--- arch/mips/sibyte/sb1250/prom.c	28 Jan 2004 22:16:39 -0000	1.9
+++ arch/mips/sibyte/sb1250/prom.c	10 Sep 2004 18:01:29 -0000
@@ -23,6 +23,7 @@
 #include <linux/blkdev.h>
 #include <linux/bootmem.h>
 #include <linux/smp.h>
+#include <linux/initrd.h>
 
 #include <asm/bootinfo.h>
 #include <asm/reboot.h>
Index: arch/mips/sibyte/swarm/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sibyte/swarm/setup.c,v
retrieving revision 1.31
diff -u -r1.31 setup.c
--- arch/mips/sibyte/swarm/setup.c	26 Aug 2004 20:18:00 -0000	1.31
+++ arch/mips/sibyte/swarm/setup.c	10 Sep 2004 18:01:29 -0000
@@ -27,6 +27,8 @@
 #include <linux/bootmem.h>
 #include <linux/blkdev.h>
 #include <linux/init.h>
+#include <linux/tty.h>
+#include <linux/initrd.h>
 
 #include <asm/irq.h>
 #include <asm/io.h>
@@ -50,6 +52,10 @@
 extern int m41t81_set_time(unsigned long);
 extern unsigned long m41t81_get_time(void);
 
+#ifdef CONFIG_BLK_DEV_INITRD
+extern void * __rd_start, * __rd_end;
+#endif
+
 const char *get_system_type(void)
 {
 	return "SiByte " SIBYTE_BOARD_NAME;

--------------010900010700090209070200--

From ddaney@avtrex.com Fri Sep 10 19:15:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Sep 2004 19:15:33 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:50891 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225210AbUIJSP2>;
	Fri, 10 Sep 2004 19:15:28 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 10 Sep 2004 11:15:22 -0700
Message-ID: <4141EF51.9050306@avtrex.com>
Date: Fri, 10 Sep 2004 11:15:45 -0700
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: Peter Buckingham <peter@pantasys.com>
CC: Ralf Baechle <ralf@linux-mips.org>, Christoph Hellwig <hch@lst.de>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH 2.6] make the bcm1250 work
References: <4140C205.7020405@pantasys.com> <20040910075644.GA27574@lst.de> <4141DAD6.8000802@pantasys.com> <20040910175213.GA9910@linux-mips.org> <4141ECAC.8070806@pantasys.com>
In-Reply-To: <4141ECAC.8070806@pantasys.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2004 18:15:22.0696 (UTC) FILETIME=[233C4C80:01C49762]
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: 5818
X-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

Peter Buckingham wrote:
> Ralf Baechle wrote:
> 
>>Winners use grep(1) ;-)
> 
> 
> guess the old tools still work the best ;-)
> 
> 
>>Include/linux/initrd.h.
> 
> 
> okay, i've attached a new version of the patch. just a few questions. 
> would it make sense to lift __rd_start, __rd_end into initrd.h? also 
> would it make sense to add:
> 
Those are architecture dependent, and must be coordinated with the
linker script.  They probably should not be in linux/initrd.h.

David Daney.


From adrian.hulse@lantronix.com Fri Sep 10 19:41:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Sep 2004 19:41:27 +0100 (BST)
Received: from ltrxmail.lantronix.com ([IPv6:::ffff:65.204.143.86]:51212 "EHLO
	double-bogey.int.lantronix.com") by linux-mips.org with ESMTP
	id <S8225215AbUIJSlX> convert rfc822-to-8bit; Fri, 10 Sep 2004 19:41:23 +0100
Received: from 3putt.int.lantronix.com ([172.16.1.16]) by double-bogey.int.lantronix.com with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 10 Sep 2004 11:41:13 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: ...cache dimensioning ;-)
Date: Fri, 10 Sep 2004 11:41:12 -0700
Message-ID: <2F0FC2A92C0B154BB406D5E74CB3E6930B7EAC@3putt.int.lantronix.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ...cache dimensioning ;-)
Thread-Index: AcSXH00BrWq+afm6TKCskpGI20ie5wARhLYQ
From: "Adrian Hulse" <adrian.hulse@lantronix.com>
To: "Emmanuel Michon" <em@realmagic.fr>, <linux-mips@linux-mips.org>
X-OriginalArrivalTime: 10 Sep 2004 18:41:14.0029 (UTC) FILETIME=[BFE6EDD0:01C49765]
X-NAIMIME-Disclaimer: 1
X-NAIMIME-Modified: 1
Return-Path: <adrian.hulse@lantronix.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5819
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: adrian.hulse@lantronix.com
Precedence: bulk
X-list: linux-mips


>If I consider a platform like Toshiba TX39 which has d-cache four ways
>with total 32KBytes, it must already have the problems above. I'd like
>to get some more clues though...

You probably meant to say Tx49 no ? The Tx39 has 16/8 k Instruction
Cache, 8/4 k Data cache.



**********************************************************************
This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. 

From wsonguci@yahoo.com Sat Sep 11 00:17:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Sep 2004 00:17:40 +0100 (BST)
Received: from web40004.mail.yahoo.com ([IPv6:::ffff:66.218.78.22]:61035 "HELO
	web40004.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225220AbUIJXRf>; Sat, 11 Sep 2004 00:17:35 +0100
Message-ID: <20040910231728.62214.qmail@web40004.mail.yahoo.com>
Received: from [63.87.1.243] by web40004.mail.yahoo.com via HTTP; Fri, 10 Sep 2004 16:17:28 PDT
Date: Fri, 10 Sep 2004 16:17:28 -0700 (PDT)
From: Song Wang <wsonguci@yahoo.com>
Subject: Routing Performance Comparison between 2.4 and 2.6 kernel
To: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <wsonguci@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: 5820
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wsonguci@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,

I'm looking for the network packet routing
performance comparison between the latest 2.4
and 2.6 kernel.

I did some initial testing on my mips-based router.
2.6 kernel performed way below 2.4 kernel. It sucks.
Turning on preemption on 2.6 kernel even makes
routing performance worse.

Anybody did a comprehensive study on the routing
performance for 2.6 and 2.4 kernel?

Thanks.



		
_______________________________
Do you Yahoo!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool

From davem@davemloft.net Sat Sep 11 00:36:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Sep 2004 00:36:28 +0100 (BST)
Received: from adsl-63-197-226-105.dsl.snfc21.pacbell.net ([IPv6:::ffff:63.197.226.105]:10643
	"EHLO cheetah.davemloft.net") by linux-mips.org with ESMTP
	id <S8225220AbUIJXgY>; Sat, 11 Sep 2004 00:36:24 +0100
Received: from localhost
	([127.0.0.1] helo=cheetah.davemloft.net ident=davem)
	by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian))
	id 1C5uvZ-0006Kq-00; Fri, 10 Sep 2004 16:35:37 -0700
Date: Fri, 10 Sep 2004 16:35:36 -0700
From: "David S. Miller" <davem@davemloft.net>
To: Song Wang <wsonguci@yahoo.com>
Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org
Subject: Re: Routing Performance Comparison between 2.4 and 2.6 kernel
Message-Id: <20040910163536.053c1bac.davem@davemloft.net>
In-Reply-To: <20040910231728.62214.qmail@web40004.mail.yahoo.com>
References: <20040910231728.62214.qmail@web40004.mail.yahoo.com>
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu)
X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <davem@davemloft.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: 5821
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: davem@davemloft.net
Precedence: bulk
X-list: linux-mips


You might reach a more knowledgable and interested
audience at netdev@oss.sgi.com which is where the
networking developers are subscribed.

From ppopov@embeddedalley.com Sat Sep 11 03:19:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Sep 2004 03:19:43 +0100 (BST)
Received: from adsl-68-124-224-226.dsl.snfc21.pacbell.net ([IPv6:::ffff:68.124.224.226]:48390
	"EHLO goobz.com") by linux-mips.org with ESMTP id <S8225224AbUIKCTi>;
	Sat, 11 Sep 2004 03:19:38 +0100
Received: from [10.2.2.70] (adsl-63-194-214-47.dsl.snfc21.pacbell.net [63.194.214.47])
	by goobz.com (8.10.1/8.10.1) with ESMTP id i8B2JaH10882
	for <linux-mips@linux-mips.org>; Fri, 10 Sep 2004 19:19:36 -0700
Message-ID: <41426031.5080003@embeddedalley.com>
Date: Fri, 10 Sep 2004 19:17:21 -0700
From: Pete Popov <ppopov@embeddedalley.com>
User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: new contact info
Content-Type: text/plain; charset=ISO-8859-1; 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: 5822
X-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've decided to move on and start a small consulting company.  My last 
day at MV was today. For those trying to get in touch with me, here is 
my new contact info:

Pete Popov
Embedded Alley Solutions, Inc
ppopov@embeddedalley.com


Pete

From em@realmagic.fr Sat Sep 11 15:58:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Sep 2004 15:58:37 +0100 (BST)
Received: from c2ce9fba.adsl.oleane.fr ([IPv6:::ffff:194.206.159.186]:54966
	"EHLO nikita.france.sdesigns.com") by linux-mips.org with ESMTP
	id <S8224933AbUIKO62>; Sat, 11 Sep 2004 15:58:28 +0100
Received: from nikita.france.sdesigns.com (localhost.localdomain [127.0.0.1])
	by nikita.france.sdesigns.com (8.12.11/8.12.11) with ESMTP id i8BEwIpW004146;
	Sat, 11 Sep 2004 16:58:18 +0200
Received: (from michon@localhost)
	by nikita.france.sdesigns.com (8.12.11/8.12.11/Submit) id i8BEwHdc004145;
	Sat, 11 Sep 2004 16:58:17 +0200
X-Authentication-Warning: nikita.france.sdesigns.com: michon set sender to em@realmagic.fr using -f
Subject: RE: ...cache dimensioning ;-)
From: Emmanuel Michon <em@realmagic.fr>
To: Adrian Hulse <adrian.hulse@lantronix.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <2F0FC2A92C0B154BB406D5E74CB3E6930B7EAC@3putt.int.lantronix.com>
References: <2F0FC2A92C0B154BB406D5E74CB3E6930B7EAC@3putt.int.lantronix.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: REALmagic France SAS
Message-Id: <1094914697.29872.8811.camel@nikita.france.sdesigns.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Sat, 11 Sep 2004 16:58:17 +0200
Return-Path: <em@realmagic.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: 5823
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: em@realmagic.fr
Precedence: bulk
X-list: linux-mips

On Fri, 2004-09-10 at 20:41, Adrian Hulse wrote:
> >If I consider a platform like Toshiba TX39 which has d-cache four ways
> >with total 32KBytes, it must already have the problems above. I'd like
> >to get some more clues though...
> 
> You probably meant to say Tx49 no ? The Tx39 has 16/8 k Instruction
> Cache, 8/4 k Data cache.

Sorry, yes, TX4938 (so far I could not boot linux from linux-mips cvs
tag 2_4_26 on this (I chose TX49[23]7 platform))

> 
> 
> 
> **********************************************************************
> This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. 
> 

From paozhaokeats@hotmail.com Sun Sep 12 08:49:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 12 Sep 2004 08:49:07 +0100 (BST)
Received: from bay19-f29.bay19.hotmail.com ([IPv6:::ffff:64.4.53.79]:34310
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8224988AbUILHtC>; Sun, 12 Sep 2004 08:49:02 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 12 Sep 2004 00:48:55 -0700
Received: from 218.75.247.251 by by19fd.bay19.hotmail.msn.com with HTTP;
	Sun, 12 Sep 2004 07:48:54 GMT
X-Originating-IP: [218.75.247.251]
X-Originating-Email: [paozhaokeats@hotmail.com]
X-Sender: paozhaokeats@hotmail.com
From: "Bao zhao" <paozhaokeats@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Cannot find the source code of handle_tlbl
Date: Sun, 12 Sep 2004 15:48:54 +0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY19-F29WOApQF88Un00011c0a@hotmail.com>
X-OriginalArrivalTime: 12 Sep 2004 07:48:55.0376 (UTC) FILETIME=[F445ED00:01C4989C]
Return-Path: <paozhaokeats@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: 5824
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: paozhaokeats@hotmail.com
Precedence: bulk
X-list: linux-mips

   hi, I am a newbie to learn mips kernel.  As I know,there is no hardware 
support for pagetable,only has support for tlb miss. Following is my 
question:
   (1) In entry.S.   I found the following exception's handlers:
                 BUILD_HANDLER(adel,ade,ade,silent)		/* #4  */
	BUILD_HANDLER(ades,ade,ade,silent)		/* #5  */
	BUILD_HANDLER(ibe,ibe,cli,verbose)		/* #6  */
	BUILD_HANDLER(dbe,dbe,cli,silent)		/* #7  */
	BUILD_HANDLER(bp,bp,sti,silent)			/* #9  */
	BUILD_HANDLER(ri,ri,sti,silent)			/* #10 */
	...
         but not all of exception's handlers are there.I cannot find 
handlers such as  handle_mod, handle_tlb,handle_tlbs;

  (2)do_page_fault should be called by tlb miss handler, but I cannot find 
which function called it.

btw, Is there any documentations about mips-kernel's implementaion?

Any help would be greatly appreciated.

                                                       Keats

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus


From peter@pantasys.com Mon Sep 13 23:33:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Sep 2004 23:33:37 +0100 (BST)
Received: from 64-60-250-34.cust.telepacific.net ([IPv6:::ffff:64.60.250.34]:30504
	"EHLO panta-1.pantasys.com") by linux-mips.org with ESMTP
	id <S8225011AbUIMWdc>; Mon, 13 Sep 2004 23:33:32 +0100
Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 13 Sep 2004 15:26:25 -0700
Message-ID: <41462025.9070607@pantasys.com>
Date: Mon, 13 Sep 2004 15:33:09 -0700
From: Peter Buckingham <peter@pantasys.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Subject: [PATCH 2.6] fix mips atomic_lock declaration
Content-Type: multipart/mixed;
 boundary="------------090704080203070902000007"
X-OriginalArrivalTime: 13 Sep 2004 22:26:25.0718 (UTC) FILETIME=[B4BC4D60:01C499E0]
Return-Path: <peter@pantasys.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5826
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: peter@pantasys.com
Precedence: bulk
X-list: linux-mips

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

Hi Ralf,

I modified the declaration of atomic_lock to be static. This means that 
I can now build and run SMP on the 1250. See attached patch.

peter

Signed-off-by: Peter Buckingham <peter@pantasys.com>

--------------090704080203070902000007
Content-Type: text/plain;
 name="p"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="p"

? include/asm-mips/.atomic.h.swp
? include/asm-mips/agp.h
Index: include/asm-mips/atomic.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/atomic.h,v
retrieving revision 1.36
diff -u -r1.36 atomic.h
--- include/asm-mips/atomic.h	19 Aug 2004 09:54:23 -0000	1.36
+++ include/asm-mips/atomic.h	13 Sep 2004 21:51:56 -0000
@@ -26,7 +26,7 @@
 #include <asm/cpu-features.h>
 #include <asm/war.h>
 
-extern spinlock_t atomic_lock;
+static spinlock_t atomic_lock;
 
 typedef struct { volatile int counter; } atomic_t;
 

--------------090704080203070902000007--

From ralf@linux-mips.org Tue Sep 14 01:22:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Sep 2004 01:22:43 +0100 (BST)
Received: from p508B659A.dip.t-dialin.net ([IPv6:::ffff:80.139.101.154]:20790
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225236AbUINAWj>; Tue, 14 Sep 2004 01:22:39 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i8E0Mbcw021806;
	Tue, 14 Sep 2004 02:22:37 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i8E0MbtK021805;
	Tue, 14 Sep 2004 02:22:37 +0200
Date: Tue, 14 Sep 2004 02:22:37 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Peter Buckingham <peter@pantasys.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.6] fix mips atomic_lock declaration
Message-ID: <20040914002237.GA21739@linux-mips.org>
References: <41462025.9070607@pantasys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41462025.9070607@pantasys.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: 5827
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Sep 13, 2004 at 03:33:09PM -0700, Peter Buckingham wrote:

> diff -u -r1.36 atomic.h
> --- include/asm-mips/atomic.h	19 Aug 2004 09:54:23 -0000	1.36
> +++ include/asm-mips/atomic.h	13 Sep 2004 21:51:56 -0000
> @@ -26,7 +26,7 @@
>  #include <asm/cpu-features.h>
>  #include <asm/war.h>
>  
> -extern spinlock_t atomic_lock;
> +static spinlock_t atomic_lock;
>  
>  typedef struct { volatile int counter; } atomic_t;


No.  atomic_lock is intentionally undefined, so this patch seems very
broken.

  Ralf

From peter@pantasys.com Tue Sep 14 01:25:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Sep 2004 01:25:19 +0100 (BST)
Received: from 64-60-250-34.cust.telepacific.net ([IPv6:::ffff:64.60.250.34]:38956
	"EHLO panta-1.pantasys.com") by linux-mips.org with ESMTP
	id <S8225236AbUINAZO>; Tue, 14 Sep 2004 01:25:14 +0100
Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 13 Sep 2004 17:18:08 -0700
Message-ID: <41463A54.1030401@pantasys.com>
Date: Mon, 13 Sep 2004 17:24:52 -0700
From: Peter Buckingham <peter@pantasys.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.6] fix mips atomic_lock declaration
References: <41462025.9070607@pantasys.com> <20040914002237.GA21739@linux-mips.org>
In-Reply-To: <20040914002237.GA21739@linux-mips.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Sep 2004 00:18:08.0890 (UTC) FILETIME=[50232DA0:01C499F0]
Return-Path: <peter@pantasys.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5828
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: peter@pantasys.com
Precedence: bulk
X-list: linux-mips

Ralf Baechle wrote:
> No.  atomic_lock is intentionally undefined, so this patch seems very
> broken.

if i don't change it to static it won't compile correctly. so obviously 
i don't get something.

it seems that the bcm1250 needs atomic_lock to be defined for the fall 
through case for smp. either that or i need to figure out how to write 
the assemble code for the SB1 case...

what do you think needs to be done?

peter

From glchen@ict.ac.cn Tue Sep 14 10:29:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Sep 2004 12:10:46 +0100 (BST)
Received: from webmail.ict.ac.cn ([IPv6:::ffff:159.226.39.7]:12431 "HELO
	ict.ac.cn") by linux-mips.org with SMTP id <S8224931AbUINJ3l>;
	Tue, 14 Sep 2004 10:29:41 +0100
Received: (qmail 12085 invoked by uid 507); 14 Sep 2004 09:13:41 -0000
Received: from unknown (HELO glame) (glchen@159.226.40.172)
  by ict.ac.cn with SMTP; 14 Sep 2004 09:13:41 -0000
Date: Tue, 14 Sep 2004 17:29:59 +0800
From: "glame" <glchen@ict.ac.cn>
To: "linux-mips" <linux-mips@linux-mips.org>
Subject: why gcc 2.95.3  generate different result with option -mips2 and -mips3 for the same code
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64
Message-Id: <20040914092941Z8224931-1530+9945@linux-mips.org>
Return-Path: <glchen@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: 5829
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: glchen@ict.ac.cn
Precedence: bulk
X-list: linux-mips

aGksDQp3aGVuIGkgZGlzYXNzZW1ibGUgdGhlIGNvZGUsIHRoZSByZXN1bHQgaXMgYXMgdGhlIGZv
bGxvd2luZw0KDQotZmZmZmZmZmY4MDAxMGI4YzogIDAxMDAxMDIxICAgIG1vdmUgICAgJHYwLCR0
MCAgKC1taXBzMikNCitmZmZmZmZmZjgwMDEwYjhjOiAgMDEwMDEwMmQgICAgbW92ZSAgICAkdjAs
JHQwICAoLW1pcHMzKQ0KDQp3aHk/IA0KDQoNCmJlc3QgcmVnYXJkcw0KoaGhoaGhoaGhoaGhoaGh
oWdsYW1lDQqhoaGhoaGhoaGhoaGhoaGhDQo=



From ica2_ts@csv.ica.uni-stuttgart.de Tue Sep 14 13:06:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Sep 2004 13:06:54 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:1332
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225241AbUINMGs>; Tue, 14 Sep 2004 13:06:48 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail)
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1C7C53-00022F-00; Tue, 14 Sep 2004 14:06:41 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1C7C52-0003jl-00; Tue, 14 Sep 2004 14:06:40 +0200
Date: Tue, 14 Sep 2004 14:06:40 +0200
To: glame <glchen@ict.ac.cn>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: why gcc 2.95.3  generate different result with option -mips2 and -mips3 for the same code
Message-ID: <20040914120640.GF12969@rembrandt.csv.ica.uni-stuttgart.de>
References: <20040914092941Z8224931-1530+9945@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040914092941Z8224931-1530+9945@linux-mips.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: 5830
X-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

glame wrote:
> hi,
> when i disassemble the code, the result is as the following
> 
> -ffffffff80010b8c:  01001021    move    $v0,$t0  (-mips2)
> +ffffffff80010b8c:  0100102d    move    $v0,$t0  (-mips3)
> 
> why? 

Because you told it to do so. :-)
The 32bit move is "addu v0, $0, t0", the 64bit move "daddu ...".


Thiemo

From flo@rfc822.org Tue Sep 14 13:20:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Sep 2004 13:20:19 +0100 (BST)
Received: from hydra.gt.owl.de ([IPv6:::ffff:195.71.99.218]:36578 "EHLO
	hydra.gt.owl.de") by linux-mips.org with ESMTP id <S8225241AbUINMUP>;
	Tue, 14 Sep 2004 13:20:15 +0100
Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hydra.gt.owl.de (Postfix) with ESMTP id 8E652199066;
	Tue, 14 Sep 2004 14:20:12 +0200 (CEST)
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 1859925DA9; Tue, 14 Sep 2004 14:20:12 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id B9291138065; Tue, 14 Sep 2004 14:03:47 +0200 (CEST)
Date: Tue, 14 Sep 2004 14:03:47 +0200
From: Florian Lohoff <flo@rfc822.org>
To: Peter Fuerst <pf@net.alphadv.de>
Cc: linux-mips@linux-mips.org
Subject: Re: gcc 2.95 patch for IP28
Message-ID: <20040914120347.GA12570@paradigm.rfc822.org>
References: <Pine.LNX.3.96.1040902040502.14047A-100000@indigo2.Peter>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.3.96.1040902040502.14047A-100000@indigo2.Peter>
Organization: rfc822 - pure communication
User-Agent: Mutt/1.5.4i
Return-Path: <flo@rfc822.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5831
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips


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


Hi Peter,

On Thu, Sep 02, 2004 at 04:11:25AM +0200, Peter Fuerst wrote:
> Hello !
> A patch to gcc 2.95.4 to make it insert the necessary cache barriers
> in (kernel-)code for SGI Indigo2 R10k (IP28) is available at
> http://home.alphastar.de/fuerst/download.html

I could build all the stuff.

I see the mentioned problem about 2.6 grinding to a halt too. Also i
have problems getting output on the serial console. its compiled in and
i see all kernel messages. Once into userspace i only see error messages
like this:

[...]
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 16Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 195.71.97.193, my address is 195.71.97.214
IP-Config: Complete:
      device=3Deth0, addr=3D195.71.97.214, mask=3D255.255.255.224, gw=3D195=
=2E71.97.193,
     host=3D195.71.97.214, domain=3Dhome.rfc822.org, nis-domain=3D(none),
     bootserver=3D195.71.97.193, rootserver=3D195.71.97.193, rootpath=3D/da=
ta/nfsroot/mips
Looking up port of RPC 100003/2 on 195.71.97.193
Looking up port of RPC 100005/1 on 195.71.97.193
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 148k freed
Ivemount: wrong fs type, bad option, bad superblock on tmpfs,
       or

the I looks like "INIT:". I cant explain the "ve" which comes some seconds

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

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

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

iD8DBQFBRt4jUaz2rXW+gJcRAikYAKCcQte0H9SOQ6cM+phXwgf3gaW22ACg5/gb
yOAAmlUW8O6/9KWP8j+OFMY=
=ur3A
-----END PGP SIGNATURE-----

--tKW2IUtsqtDRztdT--

From dennis@pcde.inka.de Tue Sep 14 18:12:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Sep 2004 18:13:01 +0100 (BST)
Received: from quechua.inka.de ([IPv6:::ffff:193.197.184.2]:63435 "EHLO
	mail.inka.de") by linux-mips.org with ESMTP id <S8224793AbUINRM5>;
	Tue, 14 Sep 2004 18:12:57 +0100
Received: from pcde.inka.de (uucp@[127.0.0.1])
	by mail.inka.de with uucp (rmailwrap 0.5) 
	id 1C7GrP-00039T-00; Tue, 14 Sep 2004 19:12:55 +0200
Received: by aton.pcde.inka.de (Postfix, from userid 1001)
	id E9DE81E5C7; Tue, 14 Sep 2004 19:11:24 +0200 (CEST)
Date: Tue, 14 Sep 2004 19:11:24 +0200
From: Dennis Grevenstein <dennis@pcde.inka.de>
To: linux-mips@linux-mips.org
Subject: MIPS Magnum ARCsystem
Message-ID: <20040914171124.GA8200@aton.pcde.inka.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <dennis@pcde.inka.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: 5832
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dennis@pcde.inka.de
Precedence: bulk
X-list: linux-mips

Hi,

I just got some parts for an old MIPS system.
I still have to find out if all of this really works,
because I don't have a power supply for it.
However, I guess the parts are basically a Magnum 4000.
It's an R4000SC on a mainboard with a few EISA slot.
Now I'm trying to find out what kind of operating
system I could use. Can anybody comment on current
Linux support?

Please add a CC: to me if you reply as I'm not on
the list.

mfg
Dennis

-- 
There is certainly no purpose in remaining in the dark
except long enough to clear from the mind
the illusion of ever having been in the light.
                                        T.S. Eliot

From a.voropay@vmb-service.ru Tue Sep 14 18:39:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Sep 2004 18:40:04 +0100 (BST)
Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:20952 "EHLO
	smtp.vmb-service.ru") by linux-mips.org with ESMTP
	id <S8224793AbUINRj7>; Tue, 14 Sep 2004 18:39:59 +0100
Received: from office.vmb-service.ru ([80.73.192.47]:24325 "EHLO alec")
	by Altair with ESMTP id <S1169653AbUINRjs>;
	Tue, 14 Sep 2004 21:39:48 +0400
Reply-To: <a.voropay@vmb-service.ru>
From: "Alec Voropay" <a.voropay@vmb-service.ru>
To: "'Dennis Grevenstein'" <dennis@pcde.inka.de>,
	<linux-mips@linux-mips.org>
Subject: RE: MIPS Magnum ARCsystem
Date: Tue, 14 Sep 2004 21:41:13 +0400
Organization: VMB-Service
Message-ID: <021a01c49a82$0778cdc0$1701a8c0@alec>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <20040914171124.GA8200@aton.pcde.inka.de>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400
Importance: Normal
Return-Path: <a.voropay@vmb-service.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: 5833
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: a.voropay@vmb-service.ru
Precedence: bulk
X-list: linux-mips

Hi!

> However, I guess the parts are basically a Magnum 4000.

 Great. I have a ACER PICA-61 (MIPS Magnum clone).
http://www.sensi.org/~alec/mips/acer_pica.html

>Now I'm trying to find out what kind of operating system I could use

 Unfortunately, I can't run ANY OS on this machine.
- Linux for this architecture was broken since early 2.2 kernel...
- The OpenBSD/arc port has been discontinued after the 2.3 release.
- To build a NetBSD/arc I need to install a full NetBSD cross
development on the i386 host.


--
-=AV=-


From dennis@pcde.inka.de Tue Sep 14 19:19:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Sep 2004 19:19:43 +0100 (BST)
Received: from quechua.inka.de ([IPv6:::ffff:193.197.184.2]:46542 "EHLO
	mail.inka.de") by linux-mips.org with ESMTP id <S8224793AbUINSTj>;
	Tue, 14 Sep 2004 19:19:39 +0100
Received: from pcde.inka.de (uucp@[127.0.0.1])
	by mail.inka.de with uucp (rmailwrap 0.5) 
	id 1C7Htx-0000Jm-00; Tue, 14 Sep 2004 20:19:37 +0200
Received: by aton.pcde.inka.de (Postfix, from userid 1001)
	id 2C9291E5C7; Tue, 14 Sep 2004 20:18:06 +0200 (CEST)
Date: Tue, 14 Sep 2004 20:18:06 +0200
From: Dennis Grevenstein <dennis@pcde.inka.de>
To: Alec Voropay <a.voropay@vmb-service.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: MIPS Magnum ARCsystem
Message-ID: <20040914181806.GA9323@aton.pcde.inka.de>
References: <20040914171124.GA8200@aton.pcde.inka.de> <021a01c49a82$0778cdc0$1701a8c0@alec>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <021a01c49a82$0778cdc0$1701a8c0@alec>
User-Agent: Mutt/1.4.1i
Return-Path: <dennis@pcde.inka.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: 5834
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dennis@pcde.inka.de
Precedence: bulk
X-list: linux-mips

On Tue, Sep 14, 2004 at 09:41:13PM +0400, Alec Voropay wrote:
> 
>  Great. I have a ACER PICA-61 (MIPS Magnum clone).
> http://www.sensi.org/~alec/mips/acer_pica.html

I have now tried using a normal AT power supply.
There is something moving, but I only see "F"
on the small LCD. Can you tell me more about this
little LCD? F seems rather early, but when I remove
the CPU I get "0".
 
>  Unfortunately, I can't run ANY OS on this machine.
> - Linux for this architecture was broken since early 2.2 kernel...
> - The OpenBSD/arc port has been discontinued after the 2.3 release.
> - To build a NetBSD/arc I need to install a full NetBSD cross
> development on the i386 host.
 
Cross compiling NetBSD  doesn't sound like a huge
problem. I would even cope with RISC/os if necessary.

mfg
Dennis

-- 
There is certainly no purpose in remaining in the dark
except long enough to clear from the mind
the illusion of ever having been in the light.
                                        T.S. Eliot

From dennis@pcde.inka.de Tue Sep 14 23:01:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Sep 2004 23:01:38 +0100 (BST)
Received: from quechua.inka.de ([IPv6:::ffff:193.197.184.2]:57046 "EHLO
	mail.inka.de") by linux-mips.org with ESMTP id <S8225196AbUINWBd>;
	Tue, 14 Sep 2004 23:01:33 +0100
Received: from pcde.inka.de (uucp@[127.0.0.1])
	by mail.inka.de with uucp (rmailwrap 0.5) 
	id 1C7LMi-0001bp-00; Wed, 15 Sep 2004 00:01:32 +0200
Received: by aton.pcde.inka.de (Postfix, from userid 1001)
	id 3F6AD1E5C7; Tue, 14 Sep 2004 23:49:44 +0200 (CEST)
Date: Tue, 14 Sep 2004 23:49:44 +0200
From: Dennis Grevenstein <dennis@pcde.inka.de>
To: Alec Voropay <a.voropay@vmb-service.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: MIPS Magnum ARCsystem
Message-ID: <20040914214944.GA12847@aton.pcde.inka.de>
References: <20040914171124.GA8200@aton.pcde.inka.de> <021a01c49a82$0778cdc0$1701a8c0@alec>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <021a01c49a82$0778cdc0$1701a8c0@alec>
User-Agent: Mutt/1.4.1i
Return-Path: <dennis@pcde.inka.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: 5835
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dennis@pcde.inka.de
Precedence: bulk
X-list: linux-mips

Hi,

Don't bother answering. I just found out that the CPU
socket itself is broken.
RIP :-(
It would have such a nice machine...

mfg
Dennis

-- 
There is certainly no purpose in remaining in the dark
except long enough to clear from the mind
the illusion of ever having been in the light.
                                        T.S. Eliot

From rajeshbv@intoto.com Wed Sep 15 05:55:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Sep 2004 05:55:23 +0100 (BST)
Received: from ip-66-80-10-146.dsl.sca.megapath.net ([IPv6:::ffff:66.80.10.146]:52843
	"EHLO brahma.intotoind.com") by linux-mips.org with ESMTP
	id <S8224827AbUIOEzT>; Wed, 15 Sep 2004 05:55:19 +0100
Received: from rajeshbv.intoto.com (3mc130.intotoind.com [172.16.3.130])
	by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8F4t58F027015;
	Wed, 15 Sep 2004 10:25:07 +0530
Message-Id: <5.1.0.14.0.20040915103551.03b2ec90@172.16.1.10>
X-Sender: rajeshbv@172.16.1.10
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Sep 2004 10:45:06 +0530
To: linux-mips@linux-mips.org
From: "Rajesh B. V." <rajeshbv@intoto.com>
Subject: Problem with ARP response
Cc: rajeshbv@intoto.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.41
Return-Path: <rajeshbv@intoto.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5836
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rajeshbv@intoto.com
Precedence: bulk
X-list: linux-mips

Hi All,

I have a network setup where both the LAN interface (eth0) and WAN 
interface (eth1) of a Router running Linux will be put into same Switch.
The setup is :
LAN network is : 192.168.1.0/24  ( Router LAN interface IP is 
192.168.1.1/24 with xx:01 as MAC)
Router WAN interface IP is a static public IP with xx:02 as MAC.

Now when a PC from the LAN networks tries to reach (ping) LAN interface 
(eth0) of Router i observe vague ARP entry in the PC for the IP.
I see some times WAN interface (eth1) MAC as the ARP entry in PC and some 
times LAN interface (eth0) MAC as the ARP entry in the PC.
For every ARP request i see two responses one with WAN interface MAC and 
one with LAN interface MAC.

I observed this is happening because, both the interfaces are receiving the 
ARP broadcast request from the PC and sending up the stack to ARP module 
and which responds with the corresponding interface MAC upon which it 
received the packet.

My requirement is to make ARP module not to respond for the packet received 
on WAN interface (eth1) with requested IP as LAN interface (eth0) IP.

Will the arp_filter () in net/ipv4/arp.c can do this ?
Also is there any draw back by doing so ?

Regards,
--Rajesh


From thomas@the-doors.enix.org Wed Sep 15 08:23:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Sep 2004 08:23:48 +0100 (BST)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:34521 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8224941AbUIOHXn>; Wed, 15 Sep 2004 08:23:43 +0100
Received: by the-doors.enix.org (Postfix, from userid 1105)
	id 269991F041; Wed, 15 Sep 2004 09:23:37 +0200 (CEST)
Date: Wed, 15 Sep 2004 09:23:37 +0200
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
To: linux-mips@linux-mips.org
Cc: mentre@tcl.ite.mee.com
Subject: Questions regarding MIPS platforms boot process
Message-ID: <20040915072337.GX6242@enix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <thomas@the-doors.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: 5837
X-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

Hello,

I'm currently trying to port Linux 2.6 to a MIPS platform which is very
similar to the Jaguar ATX platform, so I started from this code. I have
a few questions concerning this code.

1) Wired TLB entries and ioremap()

In the file arch/mips/momentum/jaguar_atx/setup.c, the
momenco_jaguar_atx_setup() function calls the wire_stupidity_into_tlb()
function to hard-wire entries into the TLB. These entries allows to
access the Marvell registers space (at 0xf4000000). So, this is done in
the early stages of the initialization.

Then, later, the per_cpu_mappings() function is called, through the
arch_initcall mecanism. This function calls ioremap() to map in virtual
memory the Marvell registers space.

At the beginning, I did not understand why both (hard-wired TLB entry
+ mapping in virtual space through ioremap()) were needed, but after
reflexion and discussion with collegues, we found out a possible
explanation. I just wanted to know if it was true or not.

At the very first stages of the initialization (during the
momenco_jaguar_atx_setup() function for example), paging is not
initialized, so we cannot use ioremap(). But we still want to be able to
talk with the Marvell, so the only solution is to wire an entry in the
TLB.

Then, later on, once everything has been set up (including paging), we
do not need anymore this wired entry, which is deleted in the
per_cpu_mappings() function through the call of the
local_flush_tlb_all() function. The Marvell registers space is then
ioremap'ed in the address, and so is still accessible (because paging is
now enabled).

Is it the right explanation ?

2) Mips_hpt_frequency

I'm not sure whether my board_time_init() function should set
mips_hpt_frequency or not. In arch/mips/kernel/time.c, it is said that :

 *      b) (optional) calibrate and set the mips_hpt_frequency
 *	    (only needed if you intended to use fixed_rate_gettimeoffset
 *	     or use cpu counter as timer interrupt source)

So it doesn't seem to be mandatory, but actually I do not understand
clearly the two cases for which setting mips_hpt_frequency is mandatory.
I don't think I want to use fixed_rate_gettimeoffset, but I'm not sure
with the second usage.

When I read the code of arch/mips/kernel/time.c, function time_init()
around line 701, I can see that if no value has been set to
mips_hpt_frequency, then it is computed by the calibrate_hpt(). So, when
is it needed to set it ?

FYI, the platform I'm working on doesn't have any external timer source.

What's the exact use of the mips_hpt_frequency ? Should I set it or not
?

Thanks,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org 
http://thomas.enix.org - Jabber: kos_tom@sourcecode.de
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

From pf@net.alphadv.de Wed Sep 15 13:48:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Sep 2004 13:48:06 +0100 (BST)
Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:38155 "EHLO
	mail.alphastar.de") by linux-mips.org with ESMTP
	id <S8224986AbUIOMsB>; Wed, 15 Sep 2004 13:48:01 +0100
Received: from SNaIlmail.Peter (217.249.213.74)
          by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==)
          for <linux-mips@linux-mips.org>; Wed, 15 Sep 2004 14:45:42 +0200
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 i8FCjDEK000569;
	Wed, 15 Sep 2004 14:45:15 +0200
Received: from localhost (pf@localhost)
	by indigo2.Peter (8.8.7/8.8.7/Linux 2.4.22 IP28) with SMTP id OAA00340;
	Wed, 15 Sep 2004 14:37:18 GMT
Date: Wed, 15 Sep 2004 14:37:18 +0000 (GMT)
From: Peter Fuerst <pf@net.alphadv.de>
To: Florian Lohoff <flo@rfc822.org>
cc: linux-mips@linux-mips.org
Subject: Re: gcc 2.95 patch for IP28
In-Reply-To: <20040914120347.GA12570@paradigm.rfc822.org>
Message-ID: <Pine.LNX.3.96.1040915143518.335A-100000@indigo2.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: 5838
X-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 !

> I could build all the stuff.

Hopefully with the updated gcc-patch from Sep 8th, which takes .reorder/
.noreorder settings into account, and seems to do the right thing:
meanwhile i build the kernels only on the I2 itself, and the 2.4-kernel
works flawlessly (as far as i can see).

> the I looks like "INIT:". I cant explain the "ve" which ...

This is most probably "INIT: version..." (Saw "Ive" last in June ;-)

> I see the mentioned problem about 2.6 grinding to a halt too...

Recently i traced this a bit further: from /sbin/init over sys32_execve,
open_exec,... finally an infinite loop in __d_lookup (dcache.c) showed up.
After changing the `hlist_for_each..' macros and local changes it looks like
we get over this place now.  Now, the last output i see, says that a syscall
4085 (__NR_readlink) is started (not the first 4085), some `execve's and
`open's later.
When the frustration has faded, i shall go on tracing.
The strange thing about the halt is, that it happens at an architecture-
independent place and not yet happened on other machines.


with kind regards

pf


On Tue, 14 Sep 2004, Florian Lohoff wrote:

> Date: Tue, 14 Sep 2004 14:03:47 +0200
> From: Florian Lohoff <flo@rfc822.org>
> To: Peter Fuerst <pf@net.alphadv.de>
> Cc: linux-mips@linux-mips.org
> Subject: Re: gcc 2.95 patch for IP28
> 
> 
> Hi Peter,
> 
> On Thu, Sep 02, 2004 at 04:11:25AM +0200, Peter Fuerst wrote:
> > Hello !
> > A patch to gcc 2.95.4 to make it insert the necessary cache barriers
> > in (kernel-)code for SGI Indigo2 R10k (IP28) is available at
> > http://home.alphastar.de/fuerst/download.html
> 
> I could build all the stuff.
> 
> I see the mentioned problem about 2.6 grinding to a halt too. Also i
> have problems getting output on the serial console. its compiled in and
> i see all kernel messages. Once into userspace i only see error messages
> like this:
> 
> [...]
> NET: Registered protocol family 2
> IP: routing cache hash table of 1024 buckets, 16Kbytes
> TCP: Hash tables configured (established 8192 bind 8192)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> Sending BOOTP requests . OK
> IP-Config: Got BOOTP answer from 195.71.97.193, my address is 195.71.97.214
> IP-Config: Complete:
>       device=eth0, addr=195.71.97.214, mask=255.255.255.224, gw=195.71.97.193,
>      host=195.71.97.214, domain=home.rfc822.org, nis-domain=(none),
>      bootserver=195.71.97.193, rootserver=195.71.97.193, rootpath=/data/nfsroot/mips
> Looking up port of RPC 100003/2 on 195.71.97.193
> Looking up port of RPC 100005/1 on 195.71.97.193
> VFS: Mounted root (nfs filesystem) readonly.
> Freeing unused kernel memory: 148k freed
> Ivemount: wrong fs type, bad option, bad superblock on tmpfs,
>        or
> 
> the I looks like "INIT:". I cant explain the "ve" which comes some seconds
> 
> Flo
> -- 
> Florian Lohoff                  flo@rfc822.org             +49-171-2280134
>                         Heisenberg may have been here.
> 


From bkemp@ucentric.com Wed Sep 15 15:45:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Sep 2004 15:45:24 +0100 (BST)
Received: from messageii.ucentric.com ([IPv6:::ffff:216.140.202.124]:19979
	"EHLO messageii.ucentric.com") by linux-mips.org with ESMTP
	id <S8225198AbUIOOpT>; Wed, 15 Sep 2004 15:45:19 +0100
Received: from [192.168.11.23] by messageii.ucentric.com with HTTP; Wed, 15 Sep 2004 10:45:15 -0400
Date: Wed, 15 Sep 2004 10:45:15 -0400
Message-ID: <4139C8B50000007D@messageii.ucentric.com>
In-Reply-To: <5.1.0.14.0.20040915103551.03b2ec90@172.16.1.10>
From: "Brad Kemp" <bkemp@ucentric.com>
Subject: RE: Problem with ARP response
To: "Rajesh B. V." <rajeshbv@intoto.com>, linux-mips@linux-mips.org
Cc: rajeshbv@intoto.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Return-Path: <bkemp@ucentric.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5839
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bkemp@ucentric.com
Precedence: bulk
X-list: linux-mips


>-- Original Message --
>Date:	Wed, 15 Sep 2004 10:45:06 +0530
>To:	linux-mips@linux-mips.org
>From:	"Rajesh B. V." <rajeshbv@intoto.com>
>Subject: Problem with ARP response
>Cc:	rajeshbv@intoto.com
>
>
>Hi All,
>
>I have a network setup where both the LAN interface (eth0) and WAN 
>interface (eth1) of a Router running Linux will be put into same Switch.
>The setup is :
>LAN network is : 192.168.1.0/24  ( Router LAN interface IP is 
>192.168.1.1/24 with xx:01 as MAC)
>Router WAN interface IP is a static public IP with xx:02 as MAC.
>
>Now when a PC from the LAN networks tries to reach (ping) LAN interface

>(eth0) of Router i observe vague ARP entry in the PC for the IP.
>I see some times WAN interface (eth1) MAC as the ARP entry in PC and some
>
>times LAN interface (eth0) MAC as the ARP entry in the PC.
>For every ARP request i see two responses one with WAN interface MAC and
>
>one with LAN interface MAC.
>
>I observed this is happening because, both the interfaces are receiving
the
>
>ARP broadcast request from the PC and sending up the stack to ARP module
>
>and which responds with the corresponding interface MAC upon which it 
>received the packet.
>
>My requirement is to make ARP module not to respond for the packet received
>
>on WAN interface (eth1) with requested IP as LAN interface (eth0) IP.
>
>Will the arp_filter () in net/ipv4/arp.c can do this ?
>Also is there any draw back by doing so ?
>
>Regards,
>--Rajesh
>
>

If you disable the arp response from eth1, no traffic will go to it. Is this
really what you want to do? 
You might want to look in to 802.1q VLAN tagging if you want to run to logical
networks on one physical network
Brad




From peter@pantasys.com Thu Sep 16 01:19:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 01:19:41 +0100 (BST)
Received: from 64-60-250-34.cust.telepacific.net ([IPv6:::ffff:64.60.250.34]:33183
	"EHLO panta-1.pantasys.com") by linux-mips.org with ESMTP
	id <S8225213AbUIPATg>; Thu, 16 Sep 2004 01:19:36 +0100
Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 15 Sep 2004 17:12:24 -0700
Message-ID: <4148DBFE.4020600@pantasys.com>
Date: Wed, 15 Sep 2004 17:19:10 -0700
From: Peter Buckingham <peter@pantasys.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: [PATCH 2.6] fix duart locking
Content-Type: multipart/mixed;
 boundary="------------050604060904010404070500"
X-OriginalArrivalTime: 16 Sep 2004 00:12:24.0687 (UTC) FILETIME=[D7CD77F0:01C49B81]
Return-Path: <peter@pantasys.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5840
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: peter@pantasys.com
Precedence: bulk
X-list: linux-mips

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

Hi Ralf,

the duart code tries to hold a spin lock across a call to 
copy_from_user(). This patch releases the spin lock before the call and 
reacquires it afterwards.

peter

Signed-off-by: Peter Buckingham <peter@pantasys.com>

--------------050604060904010404070500
Content-Type: text/plain;
 name="p"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="p"

? drivers/i2c/algos/.built-in.o.cmd
? drivers/i2c/algos/.i2c-algo-bit.o.cmd
? drivers/i2c/busses/.built-in.o.cmd
? drivers/i2c/chips/.built-in.o.cmd
? drivers/input/misc/.built-in.o.cmd
? drivers/input/misc/.pcspkr.o.cmd
? drivers/input/misc/.uinput.o.cmd
Index: drivers/char/sb1250_duart.c
===================================================================
RCS file: /home/cvs/linux/drivers/char/sb1250_duart.c,v
retrieving revision 1.23
diff -u -r1.23 sb1250_duart.c
--- drivers/char/sb1250_duart.c	15 Oct 2003 16:19:12 -0000	1.23
+++ drivers/char/sb1250_duart.c	16 Sep 2004 00:10:31 -0000
@@ -326,10 +326,11 @@
 		if (c <= 0) break;
 
 		if (from_user) {
+			spin_unlock_irqrestore(&us->outp_lock, flags);
 			if (copy_from_user(us->outp_buf + us->outp_tail, buf, c)) {
-				spin_unlock_irqrestore(&us->outp_lock, flags);
 				return -EFAULT;
 			}
+			spin_lock_irqsave(&us->outp_lock, flags);
 		} else {
 			memcpy(us->outp_buf + us->outp_tail, buf, c);
 		}

--------------050604060904010404070500--

From rajeshbv@intoto.com Thu Sep 16 02:35:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 02:35:55 +0100 (BST)
Received: from ip-66-80-10-146.dsl.sca.megapath.net ([IPv6:::ffff:66.80.10.146]:53942
	"EHLO brahma.intotoind.com") by linux-mips.org with ESMTP
	id <S8225222AbUIPBfu>; Thu, 16 Sep 2004 02:35:50 +0100
Received: from rajeshbv.intoto.com (3mc130.intotoind.com [172.16.3.130])
	by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8FFxGWi004224;
	Wed, 15 Sep 2004 21:29:16 +0530
Message-Id: <5.1.0.14.0.20040915214647.03970e60@172.16.1.10>
X-Sender: rajeshbv@172.16.1.10
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Sep 2004 21:49:18 +0530
To: "Brad Kemp" <bkemp@ucentric.com>, linux-mips@linux-mips.org
From: "Rajesh B. V." <rajeshbv@intoto.com>
Subject: RE: Problem with ARP response
In-Reply-To: <4139C8B50000007D@messageii.ucentric.com>
References: <5.1.0.14.0.20040915103551.03b2ec90@172.16.1.10>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.41
Return-Path: <rajeshbv@intoto.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5841
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rajeshbv@intoto.com
Precedence: bulk
X-list: linux-mips

At 10:45 AM 9/15/2004 -0400, Brad Kemp wrote:

> >-- Original Message --
> >Date:  Wed, 15 Sep 2004 10:45:06 +0530
> >To:    linux-mips@linux-mips.org
> >From:  "Rajesh B. V." <rajeshbv@intoto.com>
> >Subject: Problem with ARP response
> >Cc:    rajeshbv@intoto.com
> >
> >
> >Hi All,
> >
> >I have a network setup where both the LAN interface (eth0) and WAN
> >interface (eth1) of a Router running Linux will be put into same Switch.
> >The setup is :
> >LAN network is : 192.168.1.0/24  ( Router LAN interface IP is
> >192.168.1.1/24 with xx:01 as MAC)
> >Router WAN interface IP is a static public IP with xx:02 as MAC.
> >
> >Now when a PC from the LAN networks tries to reach (ping) LAN interface
>
> >(eth0) of Router i observe vague ARP entry in the PC for the IP.
> >I see some times WAN interface (eth1) MAC as the ARP entry in PC and some
> >
> >times LAN interface (eth0) MAC as the ARP entry in the PC.
> >For every ARP request i see two responses one with WAN interface MAC and
> >
> >one with LAN interface MAC.
> >
> >I observed this is happening because, both the interfaces are receiving
>the
> >
> >ARP broadcast request from the PC and sending up the stack to ARP module
> >
> >and which responds with the corresponding interface MAC upon which it
> >received the packet.
> >
> >My requirement is to make ARP module not to respond for the packet received
> >
> >on WAN interface (eth1) with requested IP as LAN interface (eth0) IP.
> >
> >Will the arp_filter () in net/ipv4/arp.c can do this ?
> >Also is there any draw back by doing so ?
> >
> >Regards,
> >--Rajesh
> >
> >
>
>If you disable the arp response from eth1, no traffic will go to it. Is this
>really what you want to do?
>You might want to look in to 802.1q VLAN tagging if you want to run to logical
>networks on one physical network
>Brad

Hi Brad,

Thanks for the response.
I got the issue resolved. ARP is handling this kinda scenarios by doing 
arp_filter ().
But to use arp_filter the flag arp_filter should be enabled i.e. keep 1 in 
proc/sys/net/ipv4/conf/<interface name>/arp_filter on all the interfaces 
that are put in same switch/hub.

Regards,
--Rajesh


From alexshinkin@hotmail.com Thu Sep 16 08:32:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 08:32:25 +0100 (BST)
Received: from bay15-f40.bay15.hotmail.com ([IPv6:::ffff:65.54.185.40]:6672
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8224989AbUIPHcU>; Thu, 16 Sep 2004 08:32:20 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 15 Sep 2004 22:59:38 -0700
Received: from 82.200.0.252 by by15fd.bay15.hotmail.msn.com with HTTP;
	Thu, 16 Sep 2004 05:55:11 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: linux-mips@linux-mips.org
Subject: Au1550 -  Problem access Shared memory from PCI card 
Date: Thu, 16 Sep 2004 12:55:11 +0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY15-F40hAOylhgnFZ0009083e@hotmail.com>
X-OriginalArrivalTime: 16 Sep 2004 05:59:38.0256 (UTC) FILETIME=[5993D100:01C49BB2]
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: 5842
X-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 All !

Could anybody help me with the following problem:

I have AMD Au1550 MIPS board, running MontaVista Linux 2.4.20-mvl31.1550.
I have also a PCI card , Linux driver for the card and some user-level 
application.
All work fine on x86 platform.

After I recompiled the driver and the application for MIPS platform I got 
the following:
1. The driver on the MIPS board (host) finds the PCI card (target)
2. I download an executable code into target and start target application 
(application starts, debug info is written to target memory).
3. Target starts to communicate with host using shared memory,allocated on 
host, (target accesses the memory through PCI).

After that I get the following problem:

4. Target writes some values into Host's shared memory and generates 
interrupt on Host.
5. Host catches the interrupt and in interrupt handler reads the values, 
written by target.
6. Host writes some replay to the shared memory, generates PCI interrupt on 
Target.
7. Target gets interrupt but can not see the latest values, written by Host. 
Reading the shared memory several times doesn' t help.

Looks like target reads values that are cached somewhere . I tried to insert 
au_sync(), au_sync_delay(), flush_cache_all() on Host side after writting 
values - nothing helps.

On x86 this approach works fine.

What could be the reason? Could this be hardware problem or can be fixed by 
fine-tuning of caching parameters or PCI controller ?

Thank you in advance!

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail


From ppopov@embeddedalley.com Thu Sep 16 08:50:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 08:50:45 +0100 (BST)
Received: from adsl-68-124-224-226.dsl.snfc21.pacbell.net ([IPv6:::ffff:68.124.224.226]:48140
	"EHLO goobz.com") by linux-mips.org with ESMTP id <S8224989AbUIPHuk>;
	Thu, 16 Sep 2004 08:50:40 +0100
Received: from [10.2.2.70] (adsl-63-194-214-47.dsl.snfc21.pacbell.net [63.194.214.47])
	by goobz.com (8.10.1/8.10.1) with ESMTP id i8G7obH32616;
	Thu, 16 Sep 2004 00:50:37 -0700
Message-ID: <414945BE.8010306@embeddedalley.com>
Date: Thu, 16 Sep 2004 00:50:22 -0700
From: Pete Popov <ppopov@embeddedalley.com>
Organization: Embedded Alley Solutions, Inc
User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alexey Shinkin <alexshinkin@hotmail.com>
CC: linux-mips@linux-mips.org
Subject: Re: Au1550 -  Problem access Shared memory from PCI card
References: <BAY15-F40hAOylhgnFZ0009083e@hotmail.com>
In-Reply-To: <BAY15-F40hAOylhgnFZ0009083e@hotmail.com>
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: 5843
X-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


>
> After I recompiled the driver and the application for MIPS platform I 
> got the following:
> 1. The driver on the MIPS board (host) finds the PCI card (target)
> 2. I download an executable code into target and start target 
> application (application starts, debug info is written to target memory).
> 3. Target starts to communicate with host using shared 
> memory,allocated on host, (target accesses the memory through PCI).
>
> After that I get the following problem:
>
> 4. Target writes some values into Host's shared memory and generates 
> interrupt on Host.
> 5. Host catches the interrupt and in interrupt handler reads the 
> values, written by target.

So the host at this point reads the correct values written by the target?

> 6. Host writes some replay to the shared memory, generates PCI 
> interrupt on Target.

When you say "host", is this the user application that is writing to the 
shared memory after remmaping it, or is the host driver itself writing 
to the shared memory from kernel space?

> 7. Target gets interrupt but can not see the latest values, written by 
> Host. Reading the shared memory several times doesn' t help.
>
> Looks like target reads values that are cached somewhere . I tried to 
> insert au_sync(), au_sync_delay(), flush_cache_all() on Host side 
> after writting values - nothing helps.

>
> On x86 this approach works fine.
>
> What could be the reason? Could this be hardware problem or can be 
> fixed by fine-tuning 

> of caching parameters or PCI controller ?

There's no reason why this shouldn't work and it doesn't smell like a 
hardware problem.

Pete

From Filip@Linux4.Be Thu Sep 16 12:39:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 12:39:34 +0100 (BST)
Received: from 178.69-56-134.reverse.theplanet.com ([IPv6:::ffff:69.56.134.178]:28311
	"EHLO texas.onkelinx.com") by linux-mips.org with ESMTP
	id <S8225007AbUIPLj3>; Thu, 16 Sep 2004 12:39:29 +0100
Received: from [127.0.0.1] (Office [193.190.11.247])
	(authenticated bits=0)
	by texas.onkelinx.com (8.12.8/8.12.8) with ESMTP id i8GBdQtn016676
	for <linux-mips@linux-mips.org>; Thu, 16 Sep 2004 06:39:28 -0500
Message-ID: <41497B5B.8000402@Linux4.Be>
Date: Thu, 16 Sep 2004 13:39:07 +0200
From: Filip Onkelinx <Filip@Linux4.Be>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: vr4131 : cache/linesize
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <Filip@Linux4.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: 5844
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Filip@Linux4.Be
Precedence: bulk
X-list: linux-mips

Hi all,

I'm currently trying to get kernel 2.6.8 running on a Casio BE-300, a 
NEC VR4131 (rev1.2) based PDA.

I noticed a (for me) strange result when comparing 2.4 with 2.6,  please 
have a look at the linesize below:
kernel 2.4.18:
   CPU revision is: 00000c80
   Primary instruction cache 16kb, linesize 32 bytes.
   Primary data cache 16kb, linesize 16 bytes.
kernel 2.6.8:
   Primary instruction cache 16kB, physically tagged, 2-way, linesize 16 
bytes.
   Primary data cache 16kB 2-way, linesize 16 bytes.

Any idea why the reported icache linesize is different between2.4 and 
2.6 ? Which one should I trust ?

and from the original botloader it looks like at boot config is set to:
# [4    ] DB: 0= data cache refill size=4 words
# [5    ] IB: 1=instruction cache refill size=8 words
# [6-8  ] DC: 100= data cache size, 16K
# [9-11 ] IC: 101= instruction cache size, 16K.

Is it common to have different dcache/icache  refill sizes ?

Thanks for your time,

Filip.



-- 
----

Do not follow where the path may lead. Go instead where there is no path and leave a trail  - Ralph Waldo Emerson

----

Filip Onkelinx
Heidebloemstraat 20, B-3500 Hasselt, BELGIUM
fax: +32 11 65 65 97, mobile: +32 475 69 47 63
filip@onkelinx.com



From ica2_ts@csv.ica.uni-stuttgart.de Thu Sep 16 12:55:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 12:55:12 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:41316
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225007AbUIPLzI>; Thu, 16 Sep 2004 12:55:08 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail)
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1C7uqw-0001Jd-00; Thu, 16 Sep 2004 13:55:06 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1C7uqv-0004QS-00; Thu, 16 Sep 2004 13:55:05 +0200
Date: Thu, 16 Sep 2004 13:55:05 +0200
To: Filip Onkelinx <Filip@Linux4.Be>
Cc: linux-mips@linux-mips.org
Subject: Re: vr4131 : cache/linesize
Message-ID: <20040916115505.GF21351@rembrandt.csv.ica.uni-stuttgart.de>
References: <41497B5B.8000402@Linux4.Be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41497B5B.8000402@Linux4.Be>
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: 5845
X-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

Filip Onkelinx wrote:
[snip]
> Any idea why the reported icache linesize is different between2.4 and 
> 2.6 ? Which one should I trust ?

Because the old 2.4 reporting was broken. 2.4.27 should report the same
as 2.6.8.


Thiemo

From alexshinkin@hotmail.com Thu Sep 16 13:12:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 13:12:11 +0100 (BST)
Received: from bay15-f19.bay15.hotmail.com ([IPv6:::ffff:65.54.185.19]:46091
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225221AbUIPMMG>; Thu, 16 Sep 2004 13:12:06 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 16 Sep 2004 04:38:23 -0700
Received: from 82.200.0.252 by by15fd.bay15.hotmail.msn.com with HTTP;
	Thu, 16 Sep 2004 11:38:23 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: linux-mips@linux-mips.org
Subject: Re: Au1550 - Problem access Shared memory from PCI card
Date: Thu, 16 Sep 2004 18:38:23 +0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY15-F19LS73JsNgMI0005f044@hotmail.com>
X-OriginalArrivalTime: 16 Sep 2004 11:38:23.0797 (UTC) FILETIME=[AC8B3E50:01C49BE1]
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: 5846
X-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


>There's no reason why this shouldn't work and it doesn't smell like a 
>hardware problem.
>


The problem is solved !

The reason was that shared memory on host have been allocated using
__get_free_pages(GFP_KERNEL, get_order(NumberOfBytes))

it returned addresses like 0x8xxxxxxx (KSEG0, cacheable)

I was adviced to use pci_alloc_consistent() instead , this function uses 
__get_free_pages
but sets some GFP flags and returns addresses like 0xAxxxxxxx (KSEG1).
With this function all works fine !

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail


From cpanel@host73.ipowerweb.com Thu Sep 16 15:33:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 15:33:35 +0100 (BST)
Received: from host73.ipowerweb.com ([IPv6:::ffff:66.235.218.254]:1146 "EHLO
	host73.ipowerweb.com") by linux-mips.org with ESMTP
	id <S8224990AbUIPOda>; Thu, 16 Sep 2004 15:33:30 +0100
Received: from cpanel by host73.ipowerweb.com with local (Exim 3.36 #1)
	id 1C7xI7-00032H-00
	for linux-mips@linux-mips.org; Thu, 16 Sep 2004 07:31:19 -0700
Received: from 61.11.17.87 ( [61.11.17.87])
	as user gautam@koperasw.com@localhost by koperasw.com with HTTP;
	Thu, 16 Sep 2004 07:31:19 -0700
Message-ID: <1095345079.4149a3b74bd1c@koperasw.com>
Date: Thu, 16 Sep 2004 07:31:19 -0700
From: gautam@koperasw.com
To: linux-mips@linux-mips.org
Subject: Problem with yamon (2.06) and TLB on Malta
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.1
X-Originating-IP: 61.11.17.87
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host73.ipowerweb.com
X-AntiAbuse: Original Domain - linux-mips.org
X-AntiAbuse: Originator/Caller UID/GID - [32001 32001] / [32001 32001]
X-AntiAbuse: Sender Address Domain - host73.ipowerweb.com
Return-Path: <cpanel@host73.ipowerweb.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5847
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gautam@koperasw.com
Precedence: bulk
X-list: linux-mips

Hi,
I am trying to write the kernel image to flash / IDE using yamon's disk write,
load,cp commands . I have a recurring error message that says "Mapped entry not
found in TLB" (something to that effect,just in case these are not the exact words).
For e.g. I get the error evenn when I do a memory erase at the flash address
sucessfully and later use the same starting address for cp .
Does the TLB need to be edited in any specific way or can I direct these
commands to execute without them needing to refer to the TLB?
I know the answer must be pretty apparent, but have already scoured through
google in vain searching for exact/relevant documentation.(and am pretty
desperate now!)
Thanks,
Gautam 



From keath@keathmilligan.net Thu Sep 16 16:54:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 16:54:18 +0100 (BST)
Received: from smtp.omnis.com ([IPv6:::ffff:216.239.128.26]:18702 "EHLO
	smtp.omnis.com") by linux-mips.org with ESMTP id <S8224935AbUIPPyM>;
	Thu, 16 Sep 2004 16:54:12 +0100
Received: from [172.26.48.101] (unknown [216.54.148.81])
	by smtp-relay.omnis.com (Postfix) with ESMTP id E5BC71407812
	for <linux-mips@linux-mips.org>; Thu, 16 Sep 2004 08:54:05 -0700 (PDT)
Message-ID: <4149B71C.7020705@keathmilligan.net>
Date: Thu, 16 Sep 2004 10:54:04 -0500
From: Keath Milligan <keath@keathmilligan.net>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Linux MIPS <linux-mips@linux-mips.org>
Subject: PCI VGA card info
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <keath@keathmilligan.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: 5848
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: keath@keathmilligan.net
Precedence: bulk
X-list: linux-mips

Does anyone have (recent) links or info on getting standard VGA cards to 
work with Linux/MIPS?

I'm working with an Alchemy DBAu1550 eval board and I'd like to get VGA 
going on it somehow. The only 3.3V PCI card I have been able to find is 
an old NVidia Riva. As I understand it, some VGA cards rely on the PC 
BIOS to be initialized, but there was some work being done to emulate 
that. All of the links I've found so far on this list and other places 
no longer work.

Thanks

-- 
Keath Milligan
Austin, Texas
http://keathmilligan.net - News, Tech, Politics, Software


From chris@mips.com Thu Sep 16 17:14:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 17:15:02 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:63245 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224935AbUIPQO5>;
	Thu, 16 Sep 2004 17:14:57 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1C7z4H-0001hx-00; Thu, 16 Sep 2004 17:25:09 +0100
Received: from holborn.mips.com ([192.168.192.237] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1C7yu8-0000uy-00; Thu, 16 Sep 2004 17:14:40 +0100
Message-ID: <4149BBEF.1020800@mips.com>
Date: Thu, 16 Sep 2004 17:14:39 +0100
From: Chris Dearman <chris@mips.com>
Organization: MIPS Technologies (UK)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: gautam@koperasw.com
CC: linux-mips@linux-mips.org
Subject: Re: Problem with yamon (2.06) and TLB on Malta
References: <1095345079.4149a3b74bd1c@koperasw.com>
In-Reply-To: <1095345079.4149a3b74bd1c@koperasw.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.012, required 4, AWL,
	BAYES_00, USER_AGENT_MOZILLA_UA)
Return-Path: <chris@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5849
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chris@mips.com
Precedence: bulk
X-list: linux-mips

gautam@koperasw.com wrote:
> Hi,
> I am trying to write the kernel image to flash / IDE using yamon's disk write,
> load,cp commands . I have a recurring error message that says "Mapped entry not
> found in TLB" (something to that effect,just in case these are not the exact words).
> For e.g. I get the error evenn when I do a memory erase at the flash address
> sucessfully and later use the same starting address for cp .
> Does the TLB need to be edited in any specific way or can I direct these
> commands to execute without them needing to refer to the TLB?
> I know the answer must be pretty apparent, but have already scoured through
> google in vain searching for exact/relevant documentation.(and am pretty
> desperate now!)

   Are you trying to use the physical addresses when accessing the 
FLASH/memory?  You need to use KSEG0/KSEG1 addresses:

YAMON> erase be100000 2e0000  		# Erase the FLASH "user" area
The following area will be erased:
Start address = 0x1e100000
Size          = 0x002e0000
Confirm ? (y/n) y
Erasing...Done
YAMON>
YAMON> dump be100000 20			# Check that it's erased

BE100000: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
BE100010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................

YAMON> fill 80100000 20 55		# Set up some data in RAM
Filling from 0x80100000 to 0x8010001f with byte data 0x55.
YAMON> copy 80100000 be100000 20	# copy data to FLASH
Copying...Done
YAMON> dump be100000 20			# Check that FLASH contains data

BE100000: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55  UUUUUUUUUUUUUUUU
BE100010: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55  UUUUUUUUUUUUUUUU


	Chris

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

From dan@embeddededge.com Thu Sep 16 17:22:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 17:22:23 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:9479 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8225251AbUIPQWR>; Thu, 16 Sep 2004 17:22:17 +0100
Received: from [192.168.2.27] (x1000-57.tellink.net [63.161.110.249])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id i8GGIeai013187;
	Thu, 16 Sep 2004 12:18:41 -0400
In-Reply-To: <4149B71C.7020705@keathmilligan.net>
References: <4149B71C.7020705@keathmilligan.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D9320BAE-07FC-11D9-BA3D-003065F9B7DC@embeddededge.com>
Content-Transfer-Encoding: 7bit
Cc: Linux MIPS <linux-mips@linux-mips.org>
From: Dan Malek <dan@embeddededge.com>
Subject: Re: PCI VGA card info
Date: Thu, 16 Sep 2004 12:24:14 -0400
To: Keath Milligan <keath@keathmilligan.net>
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: 5850
X-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 Sep 16, 2004, at 11:54 AM, Keath Milligan wrote:

> Does anyone have (recent) links or info on getting standard VGA cards 
> to work with Linux/MIPS?

The AMD/Alchemy folks have a Silicon Motion video adapter that will
work in that board.  I've done the framebuffer, X-Windows runs on it.
The standard video cards are nearly impossible to use in any kind of
embedded environment.  Nothing PCI is available anymore, and even
if you are able to find a way to initialize the controllers, they are 
obsolete
before you get any product ready for manufacturing.


	-- Dan


From keath@keathmilligan.net Thu Sep 16 17:37:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 17:37:34 +0100 (BST)
Received: from smtp.omnis.com ([IPv6:::ffff:216.239.128.26]:51460 "EHLO
	smtp.omnis.com") by linux-mips.org with ESMTP id <S8224935AbUIPQh3>;
	Thu, 16 Sep 2004 17:37:29 +0100
Received: from [172.26.48.101] (unknown [216.54.148.81])
	by smtp-relay.omnis.com (Postfix) with ESMTP id 456B51004A8
	for <linux-mips@linux-mips.org>; Thu, 16 Sep 2004 09:37:22 -0700 (PDT)
Message-ID: <4149C140.2070605@keathmilligan.net>
Date: Thu, 16 Sep 2004 11:37:20 -0500
From: Keath Milligan <keath@keathmilligan.net>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Linux MIPS <linux-mips@linux-mips.org>
Subject: Re: PCI VGA card info
References: <4149B71C.7020705@keathmilligan.net> <D9320BAE-07FC-11D9-BA3D-003065F9B7DC@embeddededge.com>
In-Reply-To: <D9320BAE-07FC-11D9-BA3D-003065F9B7DC@embeddededge.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <keath@keathmilligan.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: 5851
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: keath@keathmilligan.net
Precedence: bulk
X-list: linux-mips

Dan Malek wrote:

> The AMD/Alchemy folks have a Silicon Motion video adapter that will
> work in that board.  I've done the framebuffer, X-Windows runs on it.
> The standard video cards are nearly impossible to use in any kind of
> embedded environment.  Nothing PCI is available anymore, and even
> if you are able to find a way to initialize the controllers, they are 
> obsolete
> before you get any product ready for manufacturing.

I have this card but it doesn't seem to work with a 2.6 kernel. I'm 
trying to just get a console visible on it at this point, but the card 
doesn't seem to be getting turned on.

-- 
Keath Milligan
Austin, Texas
http://keathmilligan.net - News, Tech, Politics, Software


From ppopov@embeddedalley.com Thu Sep 16 17:45:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 17:45:27 +0100 (BST)
Received: from web81407.mail.yahoo.com ([IPv6:::ffff:206.190.37.96]:59266 "HELO
	web81407.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224935AbUIPQpX>; Thu, 16 Sep 2004 17:45:23 +0100
Message-ID: <20040916164516.18061.qmail@web81407.mail.yahoo.com>
Received: from [216.98.102.225] by web81407.mail.yahoo.com via HTTP; Thu, 16 Sep 2004 09:45:16 PDT
X-RocketYMMF: pete_popov
Date: Thu, 16 Sep 2004 09:45:16 -0700 (PDT)
From: Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
Subject: Re: PCI VGA card info
To: Keath Milligan <keath@keathmilligan.net>,
	Linux MIPS <linux-mips@linux-mips.org>
In-Reply-To: <4149C140.2070605@keathmilligan.net>
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: 5852
X-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 have this card but it doesn't seem to work with a
> 2.6 kernel. I'm trying to just get a console visible

> on it at this point, but the card doesn't seem to 
> be getting turned on.

Did you apply the 36 bit patch from my directory? 2.6
does not yet have the 36bit address support integrated
in the tree. However, the patch in my directory is not
complete yet so ioremap would work, but
io_remap_page_range which is what the vga driver would
call would not work. I have a complete patch that
we're reviewing some more before I send it to Ralf.
Note that without the 36 bit support, none of the pci
cards will work.

Pete

From ralf.roesch@rw-gmbh.de Thu Sep 16 17:53:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 17:53:33 +0100 (BST)
Received: from fw01.bwg.de ([IPv6:::ffff:213.69.156.2]:34183 "EHLO fw01.bwg.de")
	by linux-mips.org with ESMTP id <S8225254AbUIPQx3>;
	Thu, 16 Sep 2004 17:53:29 +0100
Received: by fw01.bwg.de (8.11.6p2G/8.11.6) id i8GGrSX00630
	for linux-mips@linux-mips.org; Thu, 16 Sep 2004 18:53:28 +0200 (CEST)
Received: (from localhost) by fw01.bwg.de (MSCAN) id 3/fw01.bwg.de/smtp-gw/mscan; Thu Sep 16 18:53:28 2004
From: =?us-ascii?Q?Ralf_Rosch?= <ralf.roesch@rw-gmbh.de>
To: "Dan Malek" <dan@embeddededge.com>,
	"Keath Milligan" <keath@keathmilligan.net>
Cc: "Linux MIPS" <linux-mips@linux-mips.org>
Subject: AW: PCI VGA card info
Date: Thu, 16 Sep 2004 18:53:20 +0200
Message-ID: <NHBBLBCCGMJFJIKAMKLHGEDJCCAA.ralf.roesch@rw-gmbh.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <D9320BAE-07FC-11D9-BA3D-003065F9B7DC@embeddededge.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <ralf.roesch@rw-gmbh.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: 5853
X-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.roesch@rw-gmbh.de
Precedence: bulk
X-list: linux-mips

I have running an Millennium G450 with an TX4937 processor.
This PCI card is running frame buffer and X-Windows.
Currently I use the card with Debian (unstable).
The card I have purchased for ?99,-- and can be obtained from
several distributors, for example: www.alternate.de


  --
  Ralf

> On Sep 16, 2004, at 11:54 AM, Keath Milligan wrote:
> 
> > Does anyone have (recent) links or info on getting standard VGA cards 
> > to work with Linux/MIPS?
> 
> The AMD/Alchemy folks have a Silicon Motion video adapter that will
> work in that board.  I've done the framebuffer, X-Windows runs on it.
> The standard video cards are nearly impossible to use in any kind of
> embedded environment.  Nothing PCI is available anymore, and even
> if you are able to find a way to initialize the controllers, they are 
> obsolete
> before you get any product ready for manufacturing.
> 
> 
> 	-- Dan
> 
> 
> 

From dan@embeddededge.com Thu Sep 16 17:58:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Sep 2004 17:58:15 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:23303 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8225254AbUIPQ6L>; Thu, 16 Sep 2004 17:58:11 +0100
Received: from [192.168.2.27] (x1000-57.tellink.net [63.161.110.249])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id i8GGsYai013288;
	Thu, 16 Sep 2004 12:54:35 -0400
In-Reply-To: <4149C140.2070605@keathmilligan.net>
References: <4149B71C.7020705@keathmilligan.net> <D9320BAE-07FC-11D9-BA3D-003065F9B7DC@embeddededge.com> <4149C140.2070605@keathmilligan.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <DCDEF4D2-0801-11D9-BA3D-003065F9B7DC@embeddededge.com>
Content-Transfer-Encoding: 7bit
Cc: Linux MIPS <linux-mips@linux-mips.org>
From: Dan Malek <dan@embeddededge.com>
Subject: Re: PCI VGA card info
Date: Thu, 16 Sep 2004 13:00:07 -0400
To: Keath Milligan <keath@keathmilligan.net>
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: 5854
X-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 Sep 16, 2004, at 12:37 PM, Keath Milligan wrote:

> I have this card but it doesn't seem to work with a 2.6 kernel. I'm 
> trying to just get a console visible on it at this point, but the card 
> doesn't seem to be getting turned on.

Well, I've been told I'm good at turning things on :-)
Yes, it's on my list of things to update for 2.6, just haven't gotten
there yet.

	-- Dan


From wd@denx.de Fri Sep 17 00:22:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Sep 2004 00:22:52 +0100 (BST)
Received: from mail-out.m-online.net ([IPv6:::ffff:212.18.0.9]:49323 "EHLO
	mail-out.m-online.net") by linux-mips.org with ESMTP
	id <S8225280AbUIPXWs>; Fri, 17 Sep 2004 00:22:48 +0100
Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144])
	by svr8.m-online.net (Postfix) with ESMTP id 5A5266A109;
	Fri, 17 Sep 2004 01:22:46 +0200 (CEST)
Received: from denx.de (host-82-135-33-74.customer.m-online.net [82.135.33.74])
	by mail.m-online.net (Postfix) with ESMTP id 4EC8F128854;
	Fri, 17 Sep 2004 01:22:46 +0200 (CEST)
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id DAC3B42A69; Fri, 17 Sep 2004 01:22:45 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 42058C1430; Fri, 17 Sep 2004 01:22:45 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 40DAE13D6D2; Fri, 17 Sep 2004 01:22:45 +0200 (MEST)
To: Dan Malek <dan@embeddededge.com>
Cc: Keath Milligan <keath@keathmilligan.net>,
	Linux MIPS <linux-mips@linux-mips.org>
From: Wolfgang Denk <wd@denx.de>
Subject: Re: PCI VGA card info 
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Thu, 16 Sep 2004 12:24:14 EDT."
             <D9320BAE-07FC-11D9-BA3D-003065F9B7DC@embeddededge.com> 
Date: Fri, 17 Sep 2004 01:22:40 +0200
Message-Id: <20040916232245.42058C1430@atlas.denx.de>
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5855
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips

In message <D9320BAE-07FC-11D9-BA3D-003065F9B7DC@embeddededge.com> you wrote:
> 
> The AMD/Alchemy folks have a Silicon Motion video adapter that will
> work in that board.  I've done the framebuffer, X-Windows runs on it.
> The standard video cards are nearly impossible to use in any kind of
> embedded environment.  Nothing PCI is available anymore, and even
> if you are able to find a way to initialize the controllers, they are 
> obsolete

The Fujitsu Coral-P is running fine on MIPS systems, for  example  on
the XXS3HC Device, see
http://www.mycable.de/productsshow.php?content=products&lang=en&topic=xxs3hc


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)
        O, throw away the worser part of it,
        And live the purer with the other half.

From ppopov@embeddedalley.com Fri Sep 17 01:44:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Sep 2004 01:44:10 +0100 (BST)
Received: from web81401.mail.yahoo.com ([IPv6:::ffff:206.190.37.90]:15205 "HELO
	web81401.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225275AbUIQAoE>; Fri, 17 Sep 2004 01:44:04 +0100
Message-ID: <20040917004357.17706.qmail@web81401.mail.yahoo.com>
Received: from [64.163.129.140] by web81401.mail.yahoo.com via HTTP; Thu, 16 Sep 2004 17:43:57 PDT
X-RocketYMMF: pete_popov
Date: Thu, 16 Sep 2004 17:43:57 -0700 (PDT)
From: Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
Subject: Re: PCI VGA card info 
To: Wolfgang Denk <wd@denx.de>, Dan Malek <dan@embeddededge.com>
Cc: Keath Milligan <keath@keathmilligan.net>,
	Linux MIPS <linux-mips@linux-mips.org>
In-Reply-To: <20040916232245.42058C1430@atlas.denx.de>
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: 5856
X-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



> The Fujitsu Coral-P is running fine on MIPS systems,
> for  example  on the XXS3HC Device, see


>http://www.mycable.de/productsshow.php?content=products&lang=en&topic=xxs3hc

V2.4 kernel though, I'm pretty sure. 

Pete

From wd@denx.de Fri Sep 17 08:07:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Sep 2004 08:07:36 +0100 (BST)
Received: from mail-out.m-online.net ([IPv6:::ffff:212.18.0.9]:39400 "EHLO
	mail-out.m-online.net") by linux-mips.org with ESMTP
	id <S8224830AbUIQHHb>; Fri, 17 Sep 2004 08:07:31 +0100
Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144])
	by svr8.m-online.net (Postfix) with ESMTP id 1EE2B69016;
	Fri, 17 Sep 2004 09:05:50 +0200 (CEST)
Received: from denx.de (host-82-135-33-74.customer.m-online.net [82.135.33.74])
	by mail.m-online.net (Postfix) with ESMTP id 03E9712882E;
	Fri, 17 Sep 2004 09:05:50 +0200 (CEST)
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 150F842847; Fri, 17 Sep 2004 09:05:49 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 53305C1430; Fri, 17 Sep 2004 09:05:32 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 5010113D6D2; Fri, 17 Sep 2004 09:05:32 +0200 (MEST)
To: ppopov@embeddedalley.com
Cc: Dan Malek <dan@embeddededge.com>,
	Keath Milligan <keath@keathmilligan.net>,
	Linux MIPS <linux-mips@linux-mips.org>
From: Wolfgang Denk <wd@denx.de>
Subject: Re: PCI VGA card info 
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Thu, 16 Sep 2004 17:43:57 PDT."
             <20040917004357.17706.qmail@web81401.mail.yahoo.com> 
Date: Fri, 17 Sep 2004 09:05:27 +0200
Message-Id: <20040917070532.53305C1430@atlas.denx.de>
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5857
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips

In message <20040917004357.17706.qmail@web81401.mail.yahoo.com> you wrote:
> 
> > The Fujitsu Coral-P is running fine on MIPS systems,
> > for  example  on the XXS3HC Device, see
> >http://www.mycable.de/productsshow.php?content=products&lang=en&topic=xxs3hc
> 
> V2.4 kernel though, I'm pretty sure. 

Indeed.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Love your country but never trust its government."
- from a hand-painted road sign in central Pennsylvania

From mlachwani@mvista.com Fri Sep 17 20:18:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Sep 2004 20:18:46 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:15091 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8224930AbUIQTSl>; Fri, 17 Sep 2004 20:18:41 +0100
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP id EA4171836D
	for <linux-mips@linux-mips.org>; Fri, 17 Sep 2004 12:18:37 -0700 (PDT)
Message-ID: <414B388D.8060705@mvista.com>
Date: Fri, 17 Sep 2004 12:18:37 -0700
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
Subject: IDE woos in BE mode 2.6 kernel
Content-Type: multipart/mixed;
 boundary="------------050903050607020903060201"
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: 5858
X-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

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

Hello !

In response to Jun Suns mail sent on 06/24/2004

Anybody has tried IDE disks in big endian mode with 2.6 kernel?
I seem to have troubles with Malta board.

Current malta board has CONFIG_SWAP_IO_SPACE defined and therefore
all inw, inl and their friends are byte-swapped in BE mode.  As a
results all IDE IO ops (such as ide_inw, etc) do swapping too.

A quick experiement shows those IDE IO ops should not do swapping.
Anybody knows why?

Apparently fixing the above is not enough.  I either encountered
failure to read partition table or having DMA error.  Any clues
here?

I suppose this problem really should exist for other arches
with BE support.  Anybody knows how other arches deal with this?

Thanks.

Jun

---

The following patch gets the Malta to work well. However, this patch introduces board specific changes in the IDE subsystem.
This is not a final patch but maybe there can be a better approach to this issue

Thanks
Manish



--------------050903050607020903060201
Content-Type: text/plain;
 name="patch-26-ide-malta"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch-26-ide-malta"

--- drivers/ide/ide-iops.c.orig	2004-09-16 19:20:52.000000000 -0700
+++ drivers/ide/ide-iops.c	2004-09-16 18:55:37.000000000 -0700
@@ -95,13 +95,23 @@
 	hwif->OUTBSYNC	= ide_outbsync;
 	hwif->OUTW	= ide_outw;
 	hwif->OUTL	= ide_outl;
+#if defined(CONFIG_MIPS_MALTA) && !defined(CONFIG_CPU_LITTLE_ENDIAN)
+	hwif->OUTSW	= malta_ide_outsw;
+	hwif->OUTSL	= malta_ide_outsl;
+#else
 	hwif->OUTSW	= ide_outsw;
 	hwif->OUTSL	= ide_outsl;
+#endif
 	hwif->INB	= ide_inb;
 	hwif->INW	= ide_inw;
 	hwif->INL	= ide_inl;
+#if defined(CONFIG_MIPS_MALTA) && !defined(CONFIG_CPU_LITTLE_ENDIAN)
+	hwif->INSW	= malta_ide_insw;
+	hwif->INSL	= malta_ide_insl;
+#else
 	hwif->INSW	= ide_insw;
 	hwif->INSL	= ide_insl;
+#endif
 }
 
 EXPORT_SYMBOL(default_hwif_iops);
--- include/asm-mips/ide.h.orig	2004-09-16 15:41:00.000000000 -0700
+++ include/asm-mips/ide.h	2004-09-16 18:12:26.000000000 -0700
@@ -20,6 +20,42 @@
 #define __ide_mm_outsw  ide_outsw
 #define __ide_mm_outsl  ide_outsl
 
+#if defined(CONFIG_MIPS_MALTA) && !defined(CONFIG_CPU_LITTLE_ENDIAN)
+extern const unsigned long mips_io_port_base;
+
+static inline void malta_ide_insw(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(u16 *)addr = *(volatile u16 *)(mips_io_port_base + port);
+		addr += 2;
+	}
+}
+
+static inline void malta_ide_outsw(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(volatile u16 *)(mips_io_port_base + (port)) = *(u16 *)addr;
+		addr += 2;
+	}
+}
+
+static inline void malta_ide_insl(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(u32 *)addr = *(volatile u32 *)(mips_io_port_base + port);
+		addr += 4;
+	}
+}
+
+static inline void malta_ide_outsl(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(volatile u32 *)(mips_io_port_base + (port)) = *(u32 *)addr;
+		addr += 4;
+	}
+}
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif /* __ASM_IDE_H */

--------------050903050607020903060201--


From anemo@mba.ocn.ne.jp Sat Sep 18 15:10:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Sep 2004 15:10:25 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:16115 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8224945AbUIROKU>; Sat, 18 Sep 2004 15:10:20 +0100
Received: from localhost (p3019-ipad28funabasi.chiba.ocn.ne.jp [220.107.202.19])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 3C0267C3C; Sat, 18 Sep 2004 23:10:16 +0900 (JST)
Date: Sat, 18 Sep 2004 23:19:47 +0900 (JST)
Message-Id: <20040918.231947.74754644.anemo@mba.ocn.ne.jp>
To: mlachwani@mvista.com
Cc: linux-mips@linux-mips.org
Subject: Re: IDE woos in BE mode 2.6 kernel
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <414B388D.8060705@mvista.com>
References: <414B388D.8060705@mvista.com>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 5859
X-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, 17 Sep 2004 12:18:37 -0700, Manish Lachwani <mlachwani@mvista.com> said:

mlachwani> In response to Jun Suns mail sent on 06/24/2004

jsun> Anybody has tried IDE disks in big endian mode with 2.6
jsun> kernel?  I seem to have troubles with Malta board.
...
mlachwani> The following patch gets the Malta to work well. However,
mlachwani> this patch introduces board specific changes in the IDE
mlachwani> subsystem.  This is not a final patch but maybe there can
mlachwani> be a better approach to this issue

FYI, here is my approach.  Not so beautiful but less intrusive...

1. copy include/asm-mips/mach-generic/ide.h to my mach-xxx directory.
2. add following lines to include/asm-mips/mach-xxx/ide.h
--- begin ---
/* get rid of defs from io.h - ide has its private and conflicting versions */
#ifdef insb
#undef insb
#endif
#ifdef outsb
#undef outsb
#endif
#ifdef insw
#undef insw
#endif
#ifdef outsw
#undef outsw
#endif
#ifdef insl
#undef insl
#endif
#ifdef outsl
#undef outsl
#endif

#define insb(port, addr, count) ___ide_insb(port, addr, count)
#define insw(port, addr, count) ___ide_insw(port, addr, count)
#define insl(port, addr, count) ___ide_insl(port, addr, count)
#define outsb(port, addr, count) ___ide_outsb(port, addr, count)
#define outsw(port, addr, count) ___ide_outsw(port, addr, count)
#define outsl(port, addr, count) ___ide_outsl(port, addr, count)

static inline void ___ide_insb(unsigned long port, void *addr, unsigned int count)
{
	unsigned long start = (unsigned long)addr;
	unsigned long size = (unsigned long)count;
	while (count--) {
		*(u16 *)addr = *(volatile u8 *)(mips_io_port_base + port);
		addr++;
	}
	if (cpu_has_dc_aliases)
		dma_cache_wback((unsigned long)start, size);
}

static inline void ___ide_outsb(unsigned long port, void *addr, unsigned int count)
{
	while (count--) {
		*(volatile u8 *)(mips_io_port_base + port) = *(u8 *)addr;
		addr++;
	}
}

static inline void ___ide_insw(unsigned long port, void *addr, unsigned int count)
{
	unsigned long start = (unsigned long)addr;
	unsigned long size = (unsigned long)count * 2;
	while (count--) {
		*(u16 *)addr = *(volatile u16 *)(mips_io_port_base + port);
		addr += 2;
	}
	if (cpu_has_dc_aliases)
		dma_cache_wback((unsigned long)start, size);
}

static inline void ___ide_outsw(unsigned long port, void *addr, unsigned int count)
{
	while (count--) {
		*(volatile u16 *)(mips_io_port_base + port) = *(u16 *)addr;
		addr += 2;
	}
}

static inline void ___ide_insl(unsigned long port, void *addr, unsigned int count)
{
	unsigned long start = (unsigned long)addr;
	unsigned long size = (unsigned long)count * 4;
	while (count--) {
		*(u32 *)addr = *(volatile u32 *)(mips_io_port_base + port);
		addr += 4;
	}
	if (cpu_has_dc_aliases)
		dma_cache_wback((unsigned long)start, size);
}

static inline void ___ide_outsl(unsigned long port, void *addr, unsigned int count)
{
	while (count--) {
		*(volatile u32 *)(mips_io_port_base + port) = *(u32 *)addr;
		addr += 4;
	}
}
--- end ---

Note that above codes include workarounds for PIO IDE cache problem
(dma_cache_wback) though I'm not sure this workaround still needed.
Please refer this ML thread for the workaround.
<http://www.linux-mips.org/archives/linux-mips/2004-03/msg00185.html>


And as I wrote before, I think this IDE endian problem still exists in
current 2.4 tree too.  Please refer my 02/26 mail for this topic.
<http://www.linux-mips.org/archives/linux-mips/2004-02/msg00219.html>

Thank you.

---
Atsushi Nemoto

From rsandifo@redhat.com Mon Sep 20 09:59:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Sep 2004 09:59:37 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:18385 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224920AbUITI7d>;
	Mon, 20 Sep 2004 09:59:33 +0100
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.10) with ESMTP id i8K8xVgm006123;
	Mon, 20 Sep 2004 04:59:31 -0400
Received: from localhost (mail@vpn50-7.rdu.redhat.com [172.16.50.7])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8K8xTr30012;
	Mon, 20 Sep 2004 04:59:30 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1C9K1A-0000El-00; Mon, 20 Sep 2004 09:59:28 +0100
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: gcc 3.3.4/3.4.1 and get_user
References: <20040901.012223.59462025.anemo@mba.ocn.ne.jp>
	<87656yqsmz.fsf@redhat.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Mon, 20 Sep 2004 09:59:28 +0100
In-Reply-To: <87656yqsmz.fsf@redhat.com> (Richard Sandiford's message of
 "Wed, 01 Sep 2004 09:51:16 +0100")
Message-ID: <87y8j5fh8v.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: 5860
X-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

Richard Sandiford <rsandifo@redhat.com> writes:
> Atsushi Nemoto <anemo@mba.ocn.ne.jp> writes:
>> Is this a get_user's problem or gcc's?
>
> The latter.  gcc is putting the empty asm:
>
> 	__asm__ ("":"=r" (__gu_val));
>
> into the delay slot of the call.

FYI, this is now being tracked as gcc bugzilla PR 17565:

    http://gcc.gnu.org/PR17565

The fix has so far been applied to 4.0.

Richard

From anemo@mba.ocn.ne.jp Mon Sep 20 15:09:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Sep 2004 15:09:25 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:4809 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8224937AbUITOJV>; Mon, 20 Sep 2004 15:09:21 +0100
Received: from localhost (p7184-ipad201funabasi.chiba.ocn.ne.jp [222.146.70.184])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 49B1D8672; Mon, 20 Sep 2004 23:09:18 +0900 (JST)
Date: Mon, 20 Sep 2004 23:18:56 +0900 (JST)
Message-Id: <20040920.231856.41626966.anemo@mba.ocn.ne.jp>
To: rsandifo@redhat.com
Cc: linux-mips@linux-mips.org
Subject: Re: gcc 3.3.4/3.4.1 and get_user
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <87y8j5fh8v.fsf@redhat.com>
References: <20040901.012223.59462025.anemo@mba.ocn.ne.jp>
	<87656yqsmz.fsf@redhat.com>
	<87y8j5fh8v.fsf@redhat.com>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 5861
X-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 Mon, 20 Sep 2004 09:59:28 +0100, Richard Sandiford <rsandifo@redhat.com> said:

rsandifo> FYI, this is now being tracked as gcc bugzilla PR 17565:
rsandifo> http://gcc.gnu.org/PR17565

rsandifo> The fix has so far been applied to 4.0.

Thank you.  I tried the fix on gcc 3.3.4 and it works fine.

---
Atsushi Nemoto

From ralf@linux-mips.org Mon Sep 20 16:40:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Sep 2004 16:40:49 +0100 (BST)
Received: from p508B7085.dip.t-dialin.net ([IPv6:::ffff:80.139.112.133]:9318
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224937AbUITPko>; Mon, 20 Sep 2004 16:40:44 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i8KFehA0014934;
	Mon, 20 Sep 2004 17:40:43 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i8KFegZL014933;
	Mon, 20 Sep 2004 17:40:42 +0200
Date: Mon, 20 Sep 2004 17:40:42 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
Subject: Re: gcc 3.3.4/3.4.1 and get_user
Message-ID: <20040920154042.GB5150@linux-mips.org>
References: <20040901.012223.59462025.anemo@mba.ocn.ne.jp> <87656yqsmz.fsf@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87656yqsmz.fsf@redhat.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5862
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Sep 01, 2004 at 09:51:16AM +0100, Richard Sandiford wrote:

> The latter.  gcc is putting the empty asm:
> 
> 	__asm__ ("":"=r" (__gu_val));
> 
> into the delay slot of the call.

The purpose of this was to avoid a warning about __gu_val possibly being
used uninitialized without inflating the code.  I've got a better solution
that'll actually shrinks the code size of my defconfig build by 5448
bytes.  Untested patch below.

  Ralf

Index: include/asm-mips/uaccess.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/uaccess.h,v
retrieving revision 1.35
diff -u -r1.35 uaccess.h
--- include/asm-mips/uaccess.h	19 Sep 2004 12:30:20 -0000	1.35
+++ include/asm-mips/uaccess.h	20 Sep 2004 12:33:27 -0000
@@ -225,88 +225,86 @@
  * for 32 bit mode and old iron.
  */
 #ifdef __mips64
-#define __GET_USER_DW __get_user_asm("ld")
+#define __GET_USER_DW(__gu_err) __get_user_asm("ld", __gu_err)
 #else
-#define __GET_USER_DW __get_user_asm_ll32
+#define __GET_USER_DW(__gu_err) __get_user_asm_ll32(__gu_err)
 #endif
 
-#define __get_user_nocheck(x,ptr,size)				\
-({								\
-	long __gu_err;						\
-	__typeof(*(ptr)) __gu_val;				\
-	long __gu_addr;						\
-	might_sleep();						\
-	__asm__("":"=r" (__gu_val));				\
-	__gu_addr = (long) (ptr);				\
-	__asm__("":"=r" (__gu_err));				\
-	switch (size) {						\
-	case 1: __get_user_asm("lb"); break;			\
-	case 2: __get_user_asm("lh"); break;			\
-	case 4: __get_user_asm("lw"); break;			\
-	case 8: __GET_USER_DW; break;				\
-	default: __get_user_unknown(); break;			\
-	} x = (__typeof__(*(ptr))) __gu_val; __gu_err;		\
+#define __get_user_nocheck(x,ptr,size)					\
+({									\
+	long __gu_err = 0;						\
+	__typeof(*(ptr)) __gu_val = 0;					\
+	long __gu_addr;							\
+	might_sleep();							\
+	__gu_addr = (long) (ptr);					\
+	switch (size) {							\
+	case 1: __get_user_asm("lb", __gu_err); break;			\
+	case 2: __get_user_asm("lh", __gu_err); break;			\
+	case 4: __get_user_asm("lw", __gu_err); break;			\
+	case 8: __GET_USER_DW(__gu_err); break;				\
+	default: __get_user_unknown(); break;				\
+	}								\
+	 x = (__typeof__(*(ptr))) __gu_val;				\
+	__gu_err;							\
 })
 
 #define __get_user_check(x,ptr,size)					\
 ({									\
-	long __gu_err;							\
-	__typeof__(*(ptr)) __gu_val;					\
+	long __gu_err = 0;						\
+	__typeof__(*(ptr)) __gu_val = 0;				\
 	long __gu_addr;							\
 	might_sleep();							\
-	__asm__("":"=r" (__gu_val));					\
 	__gu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__gu_err));					\
 	if (access_ok(VERIFY_READ,__gu_addr,size)) {			\
 		switch (size) {						\
-		case 1: __get_user_asm("lb"); break;			\
-		case 2: __get_user_asm("lh"); break;			\
-		case 4: __get_user_asm("lw"); break;			\
-		case 8: __GET_USER_DW; break;				\
+		case 1: __get_user_asm("lb", __gu_err); break;		\
+		case 2: __get_user_asm("lh", __gu_err); break;		\
+		case 4: __get_user_asm("lw", __gu_err); break;		\
+		case 8: __GET_USER_DW(__gu_err); break;			\
 		default: __get_user_unknown(); break;			\
 		}							\
-	} x = (__typeof__(*(ptr))) __gu_val; __gu_err;			\
+	}								\
+	x = (__typeof__(*(ptr))) __gu_val;				\
+	 __gu_err;							\
 })
 
-#define __get_user_asm(insn)						\
+#define __get_user_asm(insn,__gu_err)					\
 ({									\
 	__asm__ __volatile__(						\
-	"1:\t" insn "\t%1,%2\n\t"					\
-	"move\t%0,$0\n"							\
-	"2:\n\t"							\
-	".section\t.fixup,\"ax\"\n"					\
-	"3:\tli\t%0,%3\n\t"						\
-	"move\t%1,$0\n\t"						\
-	"j\t2b\n\t"							\
-	".previous\n\t"							\
-	".section\t__ex_table,\"a\"\n\t"				\
-	__UA_ADDR "\t1b,3b\n\t"						\
-	".previous"							\
-	:"=r" (__gu_err), "=r" (__gu_val)				\
-	:"o" (__m(__gu_addr)), "i" (-EFAULT));				\
+	"1:	" insn "	%1, %3				\n"	\
+	"2:							\n"	\
+	"	.section .fixup,\"ax\"				\n"	\
+	"3:	li	%0, %4					\n"	\
+	"	j	2b					\n"	\
+	"	.previous					\n"	\
+	"	.section __ex_table,\"a\"			\n"	\
+	"	"__UA_ADDR "\t1b, 3b				\n"	\
+	"	.previous					\n"	\
+	: "=r" (__gu_err), "=r" (__gu_val)				\
+	: "0" (__gu_err), "o" (__m(__gu_addr)), "i" (-EFAULT));		\
 })
 
 /*
  * Get a long long 64 using 32 bit registers.
  */
-#define __get_user_asm_ll32						\
+#define __get_user_asm_ll32(__gu_err)					\
 ({									\
 	__asm__ __volatile__(						\
-	"1:\tlw\t%1,%2\n"						\
-	"2:\tlw\t%D1,%3\n\t"						\
-	"move\t%0,$0\n"							\
-	"3:\t.section\t.fixup,\"ax\"\n"					\
-	"4:\tli\t%0,%4\n\t"						\
-	"move\t%1,$0\n\t"						\
-	"move\t%D1,$0\n\t"						\
-	"j\t3b\n\t"							\
-	".previous\n\t"							\
-	".section\t__ex_table,\"a\"\n\t"				\
-	__UA_ADDR "\t1b,4b\n\t"						\
-	__UA_ADDR "\t2b,4b\n\t"						\
-	".previous"							\
-	:"=r" (__gu_err), "=&r" (__gu_val)				\
-	:"o" (__m(__gu_addr)), "o" (__m(__gu_addr + 4)),		\
+	"1:	lw	%1,%2					\n"	\
+	"2:	lw	%D1,%3					\n"	\
+	"	move	%0,$0					\n"	\
+	"3:	.section	.fixup,\"ax\"			\n"	\
+	"4:	li	%0,%4					\n"	\
+	"	move	%1,$0					\n"	\
+	"	move	%D1,$0					\n"	\
+	"	j	3b					\n"	\
+	"	.previous					\n"	\
+	"	.section	__ex_table,\"a\"		\n"	\
+	"	" __UA_ADDR "	1b,4b				\n"	\
+	"	" __UA_ADDR "	2b,4b				\n"	\
+	"	.previous					\n"	\
+	: "=r" (__gu_err), "=&r" (__gu_val)				\
+	: "o" (__m(__gu_addr)), "o" (__m(__gu_addr + 4)),		\
 	 "i" (-EFAULT));						\
 })
 
@@ -317,25 +315,24 @@
  * for 32 bit mode and old iron.
  */
 #ifdef __mips64
-#define __PUT_USER_DW __put_user_asm("sd")
+#define __PUT_USER_DW(__pu_val) __put_user_asm("sd", __pu_val)
 #else
-#define __PUT_USER_DW __put_user_asm_ll32
+#define __PUT_USER_DW(__pu_val) __put_user_asm_ll32(__pu_val)
 #endif
 
 #define __put_user_nocheck(x,ptr,size)					\
 ({									\
-	long __pu_err;							\
+	long __pu_err = 0;						\
 	__typeof__(*(ptr)) __pu_val;					\
 	long __pu_addr;							\
 	might_sleep();							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
 	switch (size) {							\
-	case 1: __put_user_asm("sb"); break;				\
-	case 2: __put_user_asm("sh"); break;				\
-	case 4: __put_user_asm("sw"); break;				\
-	case 8: __PUT_USER_DW; break;					\
+	case 1: __put_user_asm("sb", __pu_val); break;			\
+	case 2: __put_user_asm("sh", __pu_val); break;			\
+	case 4: __put_user_asm("sw", __pu_val); break;			\
+	case 8: __PUT_USER_DW(__pu_val); break;				\
 	default: __put_user_unknown(); break;				\
 	}								\
 	__pu_err;							\
@@ -343,57 +340,55 @@
 
 #define __put_user_check(x,ptr,size)					\
 ({									\
-	long __pu_err;							\
+	long __pu_err = 0;						\
 	__typeof__(*(ptr)) __pu_val;					\
 	long __pu_addr;							\
 	might_sleep();							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
 	if (access_ok(VERIFY_WRITE, __pu_addr, size)) {			\
 		switch (size) {						\
-		case 1: __put_user_asm("sb"); break;			\
-		case 2: __put_user_asm("sh"); break;			\
-		case 4: __put_user_asm("sw"); break;			\
-		case 8: __PUT_USER_DW; break;				\
+		case 1: __put_user_asm("sb", __pu_val); break;		\
+		case 2: __put_user_asm("sh", __pu_val); break;		\
+		case 4: __put_user_asm("sw", __pu_val); break;		\
+		case 8: __PUT_USER_DW(__pu_val); break;			\
 		default: __put_user_unknown(); break;			\
 		}							\
 	}								\
 	__pu_err;							\
 })
 
-#define __put_user_asm(insn)						\
+#define __put_user_asm(insn, __pu_val)					\
 ({									\
 	__asm__ __volatile__(						\
-	"1:\t" insn "\t%z1, %2\t\t\t# __put_user_asm\n\t"		\
-	"move\t%0, $0\n"						\
-	"2:\n\t"							\
-	".section\t.fixup,\"ax\"\n"					\
-	"3:\tli\t%0,%3\n\t"						\
-	"j\t2b\n\t"							\
-	".previous\n\t"							\
-	".section\t__ex_table,\"a\"\n\t"				\
-	__UA_ADDR "\t1b,3b\n\t"						\
-	".previous"							\
+	"1:	" insn "	%z1, %2		# __put_user_asm\n"	\
+	"2:							\n"	\
+	"	.section	.fixup,\"ax\"			\n"	\
+	"3:	li	%0,%3					\n"	\
+	"	j	2b					\n"	\
+	"	.previous					\n"	\
+	"	.section	__ex_table,\"a\"		\n"	\
+	"	" __UA_ADDR "	1b, 3b				\n"	\
+	"	.previous					\n"	\
 	:"=r" (__pu_err)						\
 	:"Jr" (__pu_val), "o" (__m(__pu_addr)), "i" (-EFAULT));		\
 })
 
-#define __put_user_asm_ll32						\
+#define __put_user_asm_ll32(__pu_val)					\
 ({									\
 	__asm__ __volatile__(						\
-	"1:\tsw\t%1, %2\t\t\t# __put_user_asm_ll32\n\t"			\
-	"2:\tsw\t%D1, %3\n"						\
-	"move\t%0, $0\n"						\
-	"3:\n\t"							\
-	".section\t.fixup,\"ax\"\n"					\
-	"4:\tli\t%0,%4\n\t"						\
-	"j\t3b\n\t"							\
-	".previous\n\t"							\
-	".section\t__ex_table,\"a\"\n\t"				\
-	__UA_ADDR "\t1b,4b\n\t"						\
-	__UA_ADDR "\t2b,4b\n\t"						\
-	".previous"							\
+	"1:	sw	%1, %2		# __put_user_asm_ll32	\n"	\
+	"2:	sw	%D1, %3					\n"	\
+	"	move	%0, $0					\n"	\
+	"3:							\n"	\
+	"	.section	.fixup,\"ax\"			\n"	\
+	"4:	li	%0, %4					\n"	\
+	"	j	3b					\n"	\
+	"	.previous					\n"	\
+	"	.section	__ex_table,\"a\"		\n"	\
+	"	" __UA_ADDR "	1b, 4b				\n"	\
+	"	" __UA_ADDR "	2b, 4b				\n"	\
+	"	.previous"						\
 	:"=r" (__pu_err)						\
 	:"r" (__pu_val), "o" (__m(__pu_addr)),				\
 	 "o" (__m(__pu_addr + 4)), "i" (-EFAULT));			\

From ralf@linux-mips.org Mon Sep 20 18:10:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Sep 2004 18:10:39 +0100 (BST)
Received: from p508B7085.dip.t-dialin.net ([IPv6:::ffff:80.139.112.133]:49003
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224937AbUITRKY>; Mon, 20 Sep 2004 18:10:24 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i8KHALYR025878;
	Mon, 20 Sep 2004 19:10:21 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i8KHALlk025877;
	Mon, 20 Sep 2004 19:10:21 +0200
Date: Mon, 20 Sep 2004 19:10:21 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
Subject: Re: gcc 3.3.4/3.4.1 and get_user
Message-ID: <20040920171021.GA25371@linux-mips.org>
References: <20040901.012223.59462025.anemo@mba.ocn.ne.jp> <87656yqsmz.fsf@redhat.com> <20040920154042.GB5150@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040920154042.GB5150@linux-mips.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5863
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Sep 20, 2004 at 05:40:42PM +0200, Ralf Baechle wrote:

> The purpose of this was to avoid a warning about __gu_val possibly being
> used uninitialized without inflating the code.  I've got a better solution
> that'll actually shrinks the code size of my defconfig build by 5448
> bytes.  Untested patch below.

And here the same for 2.4.  Actually this is a straight backport of the
2.6 uaccess.h to 2.4 so with this patch include/asm-mips/uaccess.h and
include/asm-mips64/uaccess.h are going to be identical.

  Ralf

Index: include/asm-mips/uaccess.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/uaccess.h,v
retrieving revision 1.19.2.2
diff -u -r1.19.2.2 uaccess.h
--- include/asm-mips/uaccess.h	14 Sep 2003 20:55:20 -0000	1.19.2.2
+++ include/asm-mips/uaccess.h	20 Sep 2004 17:04:42 -0000
@@ -3,19 +3,17 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
- * Copyright (C) 1996, 1997, 1998, 1999, 2000, 03 by Ralf Baechle
+ * Copyright (C) 1996, 1997, 1998, 1999, 2000, 03, 04 by Ralf Baechle
  * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
  */
 #ifndef _ASM_UACCESS_H
 #define _ASM_UACCESS_H
 
+#include <linux/config.h>
 #include <linux/compiler.h>
 #include <linux/errno.h>
 #include <linux/sched.h>
 
-#define STR(x)  __STR(x)
-#define __STR(x)  #x
-
 /*
  * The fs value determines whether argument validity checking should be
  * performed or not.  If get_fs() == USER_DS, checking is performed, with
@@ -23,15 +21,47 @@
  *
  * For historical reasons, these macros are grossly misnamed.
  */
-#define KERNEL_DS	((mm_segment_t) { (unsigned long) 0L })
-#define USER_DS		((mm_segment_t) { (unsigned long) -1L })
+#ifdef CONFIG_MIPS32
+
+#define __UA_LIMIT	0x80000000UL
+
+#define __UA_ADDR	".word"
+#define __UA_LA		"la"
+#define __UA_ADDU	"addu"
+#define __UA_t0		"$8"
+#define __UA_t1		"$9"
+
+#endif /* CONFIG_MIPS32 */
+
+#ifdef CONFIG_MIPS64
+
+#define __UA_LIMIT	(- TASK_SIZE)
+
+#define __UA_ADDR	".dword"
+#define __UA_LA		"dla"
+#define __UA_ADDU	"daddu"
+#define __UA_t0		"$12"
+#define __UA_t1		"$13"
+
+#endif /* CONFIG_MIPS64 */
+
+/*
+ * USER_DS is a bitmask that has the bits set that may not be set in a valid
+ * userspace address.  Note that we limit 32-bit userspace to 0x7fff8000 but
+ * the arithmetic we're doing only works if the limit is a power of two, so
+ * we use 0x80000000 here on 32-bit kernels.  If a process passes an invalid
+ * address in this range it's the process's problem, not ours :-)
+ */
+
+#define KERNEL_DS	((mm_segment_t) { 0UL })
+#define USER_DS		((mm_segment_t) { __UA_LIMIT })
 
 #define VERIFY_READ    0
 #define VERIFY_WRITE   1
 
-#define get_fs()        (current->thread.current_ds)
 #define get_ds()	(KERNEL_DS)
-#define set_fs(x)       (current->thread.current_ds=(x))
+#define get_fs()	(current->thread.current_ds)
+#define set_fs(x)	(current->thread.current_ds = (x))
 
 #define segment_eq(a,b)	((a).seg == (b).seg)
 
@@ -45,14 +75,12 @@
  *  - AND "size" doesn't have any high-bits set
  *  - AND "addr+size" doesn't have any high-bits set
  *  - OR we are in kernel mode.
+ *
+ * __ua_size() is a trick to avoid runtime checking of positive constant
+ * sizes; for those we already know at compile time that the size is ok.
  */
 #define __ua_size(size)							\
-	(__builtin_constant_p(size) && (signed long) (size) > 0 ? 0 : (size))
-
-#define __access_ok(addr,size,mask)                                     \
-	(((signed long)((mask)&(addr | (addr + size) | __ua_size(size)))) >= 0)
-
-#define __access_mask ((long)(get_fs().seg))
+	((__builtin_constant_p(size) && (signed long) (size) > 0) ? 0 : (size))
 
 /*
  * access_ok: - Checks if a user space pointer is valid
@@ -73,8 +101,14 @@
  * checks that the pointer is in the user space range - after calling
  * this function, memory access functions may still return -EFAULT.
  */
+
+#define __access_mask get_fs().seg
+
+#define __access_ok(addr, size, mask)					\
+	(((signed long)((mask) & ((addr) | ((addr) + (size)) | __ua_size(size)))) == 0)
+
 #define access_ok(type, addr, size)					\
-	likely(__access_ok((unsigned long)(addr), (size), __access_mask))
+	likely(__access_ok((unsigned long)(addr), (size),__access_mask))
 
 /*
  * verify_area: - Obsolete, use access_ok()
@@ -190,88 +224,84 @@
  * for 32 bit mode and old iron.
  */
 #ifdef __mips64
-#define __GET_USER_DW __get_user_asm("ld")
+#define __GET_USER_DW(__gu_err) __get_user_asm("ld", __gu_err)
 #else
-#define __GET_USER_DW __get_user_asm_ll32
+#define __GET_USER_DW(__gu_err) __get_user_asm_ll32(__gu_err)
 #endif
 
 #define __get_user_nocheck(x,ptr,size)					\
 ({									\
-	long __gu_err;							\
-	__typeof(*(ptr)) __gu_val;					\
+	long __gu_err = 0;						\
+	__typeof(*(ptr)) __gu_val = 0;					\
 	long __gu_addr;							\
-	__asm__("":"=r" (__gu_val));					\
 	__gu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__gu_err));					\
 	switch (size) {							\
-		case 1: __get_user_asm("lb"); break;			\
-		case 2: __get_user_asm("lh"); break;			\
-		case 4: __get_user_asm("lw"); break;			\
-		case 8: __GET_USER_DW; break;				\
-		default: __get_user_unknown(); break;			\
-	} x = (__typeof__(*(ptr))) __gu_val;				\
+	case 1: __get_user_asm("lb", __gu_err); break;			\
+	case 2: __get_user_asm("lh", __gu_err); break;			\
+	case 4: __get_user_asm("lw", __gu_err); break;			\
+	case 8: __GET_USER_DW(__gu_err); break;				\
+	default: __get_user_unknown(); break;				\
+	}								\
+	 x = (__typeof__(*(ptr))) __gu_val;				\
 	__gu_err;							\
 })
 
 #define __get_user_check(x,ptr,size)					\
 ({									\
-	long __gu_err;							\
-	__typeof__(*(ptr)) __gu_val;					\
+	long __gu_err = 0;						\
+	__typeof__(*(ptr)) __gu_val = 0;				\
 	long __gu_addr;							\
-	__asm__("":"=r" (__gu_val));					\
 	__gu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__gu_err));					\
-	if (access_ok(VERIFY_READ, __gu_addr, size)) {			\
+	if (access_ok(VERIFY_READ,__gu_addr,size)) {			\
 		switch (size) {						\
-		case 1: __get_user_asm("lb"); break;			\
-		case 2: __get_user_asm("lh"); break;			\
-		case 4: __get_user_asm("lw"); break;			\
-		case 8: __GET_USER_DW; break;				\
+		case 1: __get_user_asm("lb", __gu_err); break;		\
+		case 2: __get_user_asm("lh", __gu_err); break;		\
+		case 4: __get_user_asm("lw", __gu_err); break;		\
+		case 8: __GET_USER_DW(__gu_err); break;			\
 		default: __get_user_unknown(); break;			\
 		}							\
-	} x = (__typeof__(*(ptr))) __gu_val;				\
-	__gu_err;							\
+	}								\
+	x = (__typeof__(*(ptr))) __gu_val;				\
+	 __gu_err;							\
 })
 
-#define __get_user_asm(insn)						\
+#define __get_user_asm(insn,__gu_err)					\
 ({									\
 	__asm__ __volatile__(						\
-	"1:\t" insn "\t%1,%2\n\t"					\
-	"move\t%0,$0\n"							\
-	"2:\n\t"							\
-	".section\t.fixup,\"ax\"\n"					\
-	"3:\tli\t%0,%3\n\t"						\
-	"move\t%1,$0\n\t"						\
-	"j\t2b\n\t"							\
-	".previous\n\t"							\
-	".section\t__ex_table,\"a\"\n\t"				\
-	".word\t1b,3b\n\t"						\
-	".previous"							\
-	:"=r" (__gu_err), "=r" (__gu_val)				\
-	:"o" (__m(__gu_addr)), "i" (-EFAULT));				\
+	"1:	" insn "	%1, %3				\n"	\
+	"2:							\n"	\
+	"	.section .fixup,\"ax\"				\n"	\
+	"3:	li	%0, %4					\n"	\
+	"	j	2b					\n"	\
+	"	.previous					\n"	\
+	"	.section __ex_table,\"a\"			\n"	\
+	"	"__UA_ADDR "\t1b, 3b				\n"	\
+	"	.previous					\n"	\
+	: "=r" (__gu_err), "=r" (__gu_val)				\
+	: "0" (__gu_err), "o" (__m(__gu_addr)), "i" (-EFAULT));		\
 })
 
 /*
  * Get a long long 64 using 32 bit registers.
  */
-#define __get_user_asm_ll32						\
+#define __get_user_asm_ll32(__gu_err)					\
 ({									\
-__asm__ __volatile__(							\
-	"1:\tlw\t%1,%2\n"						\
-	"2:\tlw\t%D1,%3\n\t"						\
-	"move\t%0,$0\n"							\
-	"3:\t.section\t.fixup,\"ax\"\n"					\
-	"4:\tli\t%0,%4\n\t"						\
-	"move\t%1,$0\n\t"						\
-	"move\t%D1,$0\n\t"						\
-	"j\t3b\n\t"							\
-	".previous\n\t"							\
-	".section\t__ex_table,\"a\"\n\t"				\
-	".word\t1b,4b\n\t"						\
-	".word\t2b,4b\n\t"						\
-	".previous"							\
-	:"=r" (__gu_err), "=&r" (__gu_val)				\
-	:"o" (__m(__gu_addr)), "o" (__m(__gu_addr + 4)),		\
+	__asm__ __volatile__(						\
+	"1:	lw	%1,%2					\n"	\
+	"2:	lw	%D1,%3					\n"	\
+	"	move	%0,$0					\n"	\
+	"3:	.section	.fixup,\"ax\"			\n"	\
+	"4:	li	%0,%4					\n"	\
+	"	move	%1,$0					\n"	\
+	"	move	%D1,$0					\n"	\
+	"	j	3b					\n"	\
+	"	.previous					\n"	\
+	"	.section	__ex_table,\"a\"		\n"	\
+	"	" __UA_ADDR "	1b,4b				\n"	\
+	"	" __UA_ADDR "	2b,4b				\n"	\
+	"	.previous					\n"	\
+	: "=r" (__gu_err), "=&r" (__gu_val)				\
+	: "o" (__m(__gu_addr)), "o" (__m(__gu_addr + 4)),		\
 	 "i" (-EFAULT));						\
 })
 
@@ -282,84 +312,81 @@
  * for 32 bit mode and old iron.
  */
 #ifdef __mips64
-#define __PUT_USER_DW __put_user_asm("sd")
+#define __PUT_USER_DW(__pu_val) __put_user_asm("sd", __pu_val)
 #else
-#define __PUT_USER_DW __put_user_asm_ll32
+#define __PUT_USER_DW(__pu_val) __put_user_asm_ll32(__pu_val)
 #endif
 
 #define __put_user_nocheck(x,ptr,size)					\
 ({									\
-	long __pu_err;							\
+	long __pu_err = 0;						\
 	__typeof__(*(ptr)) __pu_val;					\
 	long __pu_addr;							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
 	switch (size) {							\
-		case 1: __put_user_asm("sb"); break;			\
-		case 2: __put_user_asm("sh"); break;			\
-		case 4: __put_user_asm("sw"); break;			\
-		case 8: __PUT_USER_DW; break;				\
-		default: __put_user_unknown(); break;			\
+	case 1: __put_user_asm("sb", __pu_val); break;			\
+	case 2: __put_user_asm("sh", __pu_val); break;			\
+	case 4: __put_user_asm("sw", __pu_val); break;			\
+	case 8: __PUT_USER_DW(__pu_val); break;				\
+	default: __put_user_unknown(); break;				\
 	}								\
 	__pu_err;							\
 })
 
 #define __put_user_check(x,ptr,size)					\
 ({									\
-	long __pu_err;							\
+	long __pu_err = 0;						\
 	__typeof__(*(ptr)) __pu_val;					\
 	long __pu_addr;							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
 	if (access_ok(VERIFY_WRITE, __pu_addr, size)) {			\
 		switch (size) {						\
-		case 1: __put_user_asm("sb"); break;			\
-		case 2: __put_user_asm("sh"); break;			\
-		case 4: __put_user_asm("sw"); break;			\
-		case 8: __PUT_USER_DW; break;				\
+		case 1: __put_user_asm("sb", __pu_val); break;		\
+		case 2: __put_user_asm("sh", __pu_val); break;		\
+		case 4: __put_user_asm("sw", __pu_val); break;		\
+		case 8: __PUT_USER_DW(__pu_val); break;			\
 		default: __put_user_unknown(); break;			\
 		}							\
 	}								\
 	__pu_err;							\
 })
 
-#define __put_user_asm(insn)						\
+#define __put_user_asm(insn, __pu_val)					\
 ({									\
 	__asm__ __volatile__(						\
-	"1:\t" insn "\t%z1, %2\t\t\t# __put_user_asm\n\t"		\
-	"move\t%0, $0\n"						\
-	"2:\n\t"							\
-	".section\t.fixup,\"ax\"\n"					\
-	"3:\tli\t%0, %3\n\t"						\
-	"j\t2b\n\t"							\
-	".previous\n\t"							\
-	".section\t__ex_table,\"a\"\n\t"				\
-	".word\t1b, 3b\n\t"						\
-	".previous"							\
+	"1:	" insn "	%z1, %2		# __put_user_asm\n"	\
+	"2:							\n"	\
+	"	.section	.fixup,\"ax\"			\n"	\
+	"3:	li	%0,%3					\n"	\
+	"	j	2b					\n"	\
+	"	.previous					\n"	\
+	"	.section	__ex_table,\"a\"		\n"	\
+	"	" __UA_ADDR "	1b, 3b				\n"	\
+	"	.previous					\n"	\
 	:"=r" (__pu_err)						\
 	:"Jr" (__pu_val), "o" (__m(__pu_addr)), "i" (-EFAULT));		\
 })
 
-#define __put_user_asm_ll32						\
+#define __put_user_asm_ll32(__pu_val)					\
 ({									\
-__asm__ __volatile__(							\
-	"1:\tsw\t%1, %2\t\t\t# __put_user_asm_ll32\n\t"			\
-	"2:\tsw\t%D1, %3\n"						\
-	"move\t%0, $0\n"						\
-	"3:\n\t"							\
-	".section\t.fixup,\"ax\"\n"					\
-	"4:\tli\t%0, %4\n\t"						\
-	"j\t3b\n\t"							\
-	".previous\n\t"							\
-	".section\t__ex_table,\"a\"\n\t"				\
-	".word\t1b,4b\n\t"						\
-	".word\t2b,4b\n\t"						\
-	".previous"							\
+	__asm__ __volatile__(						\
+	"1:	sw	%1, %2		# __put_user_asm_ll32	\n"	\
+	"2:	sw	%D1, %3					\n"	\
+	"	move	%0, $0					\n"	\
+	"3:							\n"	\
+	"	.section	.fixup,\"ax\"			\n"	\
+	"4:	li	%0, %4					\n"	\
+	"	j	3b					\n"	\
+	"	.previous					\n"	\
+	"	.section	__ex_table,\"a\"		\n"	\
+	"	" __UA_ADDR "	1b, 4b				\n"	\
+	"	" __UA_ADDR "	2b, 4b				\n"	\
+	"	.previous"						\
 	:"=r" (__pu_err)						\
-	:"r" (__pu_val), "o" (__m(__pu_addr)), "o" (__m(__pu_addr + 4)),\
-	 "i" (-EFAULT));						\
+	:"r" (__pu_val), "o" (__m(__pu_addr)),				\
+	 "o" (__m(__pu_addr + 4)), "i" (-EFAULT));			\
 })
 
 extern void __put_user_unknown(void);
@@ -371,7 +398,7 @@
 #ifdef MODULE
 #define __MODULE_JAL(destination)					\
 	".set\tnoat\n\t"						\
-	"la\t$1, " #destination "\n\t"					\
+	__UA_LA "\t$1, " #destination "\n\t" 				\
 	"jalr\t$1\n\t"							\
 	".set\tat\n\t"
 #else
@@ -426,6 +453,9 @@
 	__cu_len;							\
 })
 
+#define __copy_to_user_inatomic __copy_to_user
+#define __copy_from_user_inatomic __copy_from_user
+
 /*
  * copy_to_user: - Copy a block of data into user space.
  * @to:   Destination address, in user space.
@@ -467,9 +497,10 @@
 	".set\tnoreorder\n\t"						\
 	__MODULE_JAL(__copy_user)					\
 	".set\tnoat\n\t"						\
-	"addu\t$1, %1, %2\n\t"						\
+	__UA_ADDU "\t$1, %1, %2\n\t"					\
 	".set\tat\n\t"							\
 	".set\treorder\n\t"						\
+	"move\t%0, $6"		/* XXX */				\
 	: "+r" (__cu_to_r), "+r" (__cu_from_r), "+r" (__cu_len_r)	\
 	:								\
 	: "$8", "$9", "$10", "$11", "$12", "$15", "$24", "$31",		\
@@ -538,6 +569,24 @@
 	__cu_len;							\
 })
 
+#define __copy_in_user(to, from, n)	__copy_from_user(to, from, n)
+
+#define copy_in_user(to,from,n)						\
+({									\
+	void *__cu_to;							\
+	const void *__cu_from;						\
+	long __cu_len;							\
+									\
+	__cu_to = (to);							\
+	__cu_from = (from);						\
+	__cu_len = (n);							\
+	if (likely(access_ok(VERIFY_READ, __cu_from, __cu_len) &&	\
+	           access_ok(VERIFY_WRITE, __cu_to, __cu_len)))		\
+		__cu_len = __invoke_copy_from_user(__cu_to, __cu_from,	\
+		                                   __cu_len);		\
+	__cu_len;							\
+})
+
 /*
  * __clear_user: - Zero a block of memory in user space, with less checking.
  * @to:   Destination address, in user space.
@@ -562,7 +611,7 @@
 		"move\t%0, $6"
 		: "=r" (res)
 		: "r" (addr), "r" (size)
-		: "$4", "$5", "$6", "$8", "$9", "$31");
+		: "$4", "$5", "$6", __UA_t0, __UA_t1, "$31");
 
 	return res;
 }
@@ -610,7 +659,7 @@
 		"move\t%0, $2"
 		: "=r" (res)
 		: "r" (__to), "r" (__from), "r" (__len)
-		: "$2", "$3", "$4", "$5", "$6", "$8", "$31", "memory");
+		: "$2", "$3", "$4", "$5", "$6", __UA_t0, "$31", "memory");
 
 	return res;
 }
@@ -646,7 +695,7 @@
 		"move\t%0, $2"
 		: "=r" (res)
 		: "r" (__to), "r" (__from), "r" (__len)
-		: "$2", "$3", "$4", "$5", "$6", "$8", "$31", "memory");
+		: "$2", "$3", "$4", "$5", "$6", __UA_t0, "$31", "memory");
 
 	return res;
 }
@@ -662,7 +711,7 @@
 		"move\t%0, $2"
 		: "=r" (res)
 		: "r" (s)
-		: "$2", "$4", "$8", "$31");
+		: "$2", "$4", __UA_t0, "$31");
 
 	return res;
 }
@@ -691,7 +740,24 @@
 		"move\t%0, $2"
 		: "=r" (res)
 		: "r" (s)
-		: "$2", "$4", "$8", "$31");
+		: "$2", "$4", __UA_t0, "$31");
+
+	return res;
+}
+
+/* Returns: 0 if bad, string length+1 (memory size) of string if ok */
+static inline long __strnlen_user(const char *s, long n)
+{
+	long res;
+
+	__asm__ __volatile__(
+		"move\t$4, %1\n\t"
+		"move\t$5, %2\n\t"
+		__MODULE_JAL(__strnlen_user_nocheck_asm)
+		"move\t%0, $2"
+		: "=r" (res)
+		: "r" (s), "r" (n)
+		: "$2", "$4", "$5", __UA_t0, "$31");
 
 	return res;
 }
@@ -699,13 +765,16 @@
 /*
  * strlen_user: - Get the size of a string in user space.
  * @str: The string to measure.
- * @n:   The maximum valid length
+ *
+ * Context: User context only.  This function may sleep.
  *
  * Get the size of a NUL-terminated string in user space.
  *
  * Returns the size of the string INCLUDING the terminating NUL.
  * On exception, returns 0.
- * If the string is too long, returns a value greater than @n.
+ *
+ * If there is a limit on the length of a valid string, you may wish to
+ * consider using strnlen_user() instead.
  */
 static inline long strnlen_user(const char *s, long n)
 {
@@ -718,7 +787,7 @@
 		"move\t%0, $2"
 		: "=r" (res)
 		: "r" (s), "r" (n)
-		: "$2", "$4", "$5", "$8", "$31");
+		: "$2", "$4", "$5", __UA_t0, "$31");
 
 	return res;
 }
Index: include/asm-mips64/uaccess.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/Attic/uaccess.h,v
retrieving revision 1.13.2.4
diff -u -r1.13.2.4 uaccess.h
--- include/asm-mips64/uaccess.h	14 Sep 2003 20:55:20 -0000	1.13.2.4
+++ include/asm-mips64/uaccess.h	20 Sep 2004 17:04:42 -0000
@@ -3,19 +3,17 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
- * Copyright (C) 1996, 1997, 1998, 1999, 2000, 03 by Ralf Baechle
+ * Copyright (C) 1996, 1997, 1998, 1999, 2000, 03, 04 by Ralf Baechle
  * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
  */
 #ifndef _ASM_UACCESS_H
 #define _ASM_UACCESS_H
 
+#include <linux/config.h>
 #include <linux/compiler.h>
 #include <linux/errno.h>
 #include <linux/sched.h>
 
-#define STR(x)  __STR(x)
-#define __STR(x)  #x
-
 /*
  * The fs value determines whether argument validity checking should be
  * performed or not.  If get_fs() == USER_DS, checking is performed, with
@@ -23,15 +21,47 @@
  *
  * For historical reasons, these macros are grossly misnamed.
  */
+#ifdef CONFIG_MIPS32
+
+#define __UA_LIMIT	0x80000000UL
+
+#define __UA_ADDR	".word"
+#define __UA_LA		"la"
+#define __UA_ADDU	"addu"
+#define __UA_t0		"$8"
+#define __UA_t1		"$9"
+
+#endif /* CONFIG_MIPS32 */
+
+#ifdef CONFIG_MIPS64
+
+#define __UA_LIMIT	(- TASK_SIZE)
+
+#define __UA_ADDR	".dword"
+#define __UA_LA		"dla"
+#define __UA_ADDU	"daddu"
+#define __UA_t0		"$12"
+#define __UA_t1		"$13"
+
+#endif /* CONFIG_MIPS64 */
+
+/*
+ * USER_DS is a bitmask that has the bits set that may not be set in a valid
+ * userspace address.  Note that we limit 32-bit userspace to 0x7fff8000 but
+ * the arithmetic we're doing only works if the limit is a power of two, so
+ * we use 0x80000000 here on 32-bit kernels.  If a process passes an invalid
+ * address in this range it's the process's problem, not ours :-)
+ */
+
 #define KERNEL_DS	((mm_segment_t) { 0UL })
-#define USER_DS		((mm_segment_t) { -TASK_SIZE })
+#define USER_DS		((mm_segment_t) { __UA_LIMIT })
 
 #define VERIFY_READ    0
 #define VERIFY_WRITE   1
 
-#define get_fs()        (current->thread.current_ds)
 #define get_ds()	(KERNEL_DS)
-#define set_fs(x)       (current->thread.current_ds=(x))
+#define get_fs()	(current->thread.current_ds)
+#define set_fs(x)	(current->thread.current_ds = (x))
 
 #define segment_eq(a,b)	((a).seg == (b).seg)
 
@@ -45,14 +75,12 @@
  *  - AND "size" doesn't have any high-bits set
  *  - AND "addr+size" doesn't have any high-bits set
  *  - OR we are in kernel mode.
+ *
+ * __ua_size() is a trick to avoid runtime checking of positive constant
+ * sizes; for those we already know at compile time that the size is ok.
  */
 #define __ua_size(size)							\
-	((__builtin_constant_p(size) && (size)) > 0 ? 0 : (size))
-
-#define __access_ok(addr, size, mask)					\
-	(((mask) & ((addr) | ((addr) + (size)) | __ua_size(size))) == 0)
-
-#define __access_mask get_fs().seg
+	((__builtin_constant_p(size) && (signed long) (size) > 0) ? 0 : (size))
 
 /*
  * access_ok: - Checks if a user space pointer is valid
@@ -73,8 +101,14 @@
  * checks that the pointer is in the user space range - after calling
  * this function, memory access functions may still return -EFAULT.
  */
+
+#define __access_mask get_fs().seg
+
+#define __access_ok(addr, size, mask)					\
+	(((signed long)((mask) & ((addr) | ((addr) + (size)) | __ua_size(size)))) == 0)
+
 #define access_ok(type, addr, size)					\
-	likely(__access_ok((unsigned long)(addr), (size), __access_mask))
+	likely(__access_ok((unsigned long)(addr), (size),__access_mask))
 
 /*
  * verify_area: - Obsolete, use access_ok()
@@ -185,119 +219,176 @@
 struct __large_struct { unsigned long buf[100]; };
 #define __m(x) (*(struct __large_struct *)(x))
 
+/*
+ * Yuck.  We need two variants, one for 64bit operation and one
+ * for 32 bit mode and old iron.
+ */
+#ifdef __mips64
+#define __GET_USER_DW(__gu_err) __get_user_asm("ld", __gu_err)
+#else
+#define __GET_USER_DW(__gu_err) __get_user_asm_ll32(__gu_err)
+#endif
+
 #define __get_user_nocheck(x,ptr,size)					\
 ({									\
-	long __gu_err;							\
-	__typeof(*(ptr)) __gu_val;					\
+	long __gu_err = 0;						\
+	__typeof(*(ptr)) __gu_val = 0;					\
 	long __gu_addr;							\
-	__asm__("":"=r" (__gu_val));					\
 	__gu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__gu_err));					\
 	switch (size) {							\
-		case 1: __get_user_asm("lb"); break;			\
-		case 2: __get_user_asm("lh"); break;			\
-		case 4: __get_user_asm("lw"); break;			\
-		case 8: __get_user_asm("ld"); break;			\
-		default: __get_user_unknown(); break;			\
-	} x = (__typeof__(*(ptr))) __gu_val;				\
+	case 1: __get_user_asm("lb", __gu_err); break;			\
+	case 2: __get_user_asm("lh", __gu_err); break;			\
+	case 4: __get_user_asm("lw", __gu_err); break;			\
+	case 8: __GET_USER_DW(__gu_err); break;				\
+	default: __get_user_unknown(); break;				\
+	}								\
+	 x = (__typeof__(*(ptr))) __gu_val;				\
 	__gu_err;							\
 })
 
 #define __get_user_check(x,ptr,size)					\
 ({									\
-	long __gu_err;							\
-	__typeof__(*(ptr)) __gu_val;					\
+	long __gu_err = 0;						\
+	__typeof__(*(ptr)) __gu_val = 0;				\
 	long __gu_addr;							\
-	__asm__("":"=r" (__gu_val));					\
 	__gu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__gu_err));					\
-	if (access_ok(VERIFY_READ, __gu_addr, size)) {			\
+	if (access_ok(VERIFY_READ,__gu_addr,size)) {			\
 		switch (size) {						\
-		case 1: __get_user_asm("lb"); break;			\
-		case 2: __get_user_asm("lh"); break;			\
-		case 4: __get_user_asm("lw"); break;			\
-		case 8: __get_user_asm("ld"); break;			\
+		case 1: __get_user_asm("lb", __gu_err); break;		\
+		case 2: __get_user_asm("lh", __gu_err); break;		\
+		case 4: __get_user_asm("lw", __gu_err); break;		\
+		case 8: __GET_USER_DW(__gu_err); break;			\
 		default: __get_user_unknown(); break;			\
 		}							\
-	} x = (__typeof__(*(ptr))) __gu_val;				\
-	__gu_err;							\
+	}								\
+	x = (__typeof__(*(ptr))) __gu_val;				\
+	 __gu_err;							\
 })
 
-#define __get_user_asm(insn)						\
+#define __get_user_asm(insn,__gu_err)					\
 ({									\
 	__asm__ __volatile__(						\
-	"1:\t" insn "\t%1,%2\n\t"					\
-	"move\t%0,$0\n"							\
-	"2:\n\t"							\
-	".section\t.fixup,\"ax\"\n"					\
-	"3:\tli\t%0,%3\n\t"						\
-	"move\t%1,$0\n\t"						\
-	"j\t2b\n\t"							\
-	".previous\n\t"							\
-	".section\t__ex_table,\"a\"\n\t"				\
-	".dword\t1b,3b\n\t"						\
-	".previous"							\
-	:"=r" (__gu_err), "=r" (__gu_val)				\
-	:"o" (__m(__gu_addr)), "i" (-EFAULT));				\
+	"1:	" insn "	%1, %3				\n"	\
+	"2:							\n"	\
+	"	.section .fixup,\"ax\"				\n"	\
+	"3:	li	%0, %4					\n"	\
+	"	j	2b					\n"	\
+	"	.previous					\n"	\
+	"	.section __ex_table,\"a\"			\n"	\
+	"	"__UA_ADDR "\t1b, 3b				\n"	\
+	"	.previous					\n"	\
+	: "=r" (__gu_err), "=r" (__gu_val)				\
+	: "0" (__gu_err), "o" (__m(__gu_addr)), "i" (-EFAULT));		\
+})
+
+/*
+ * Get a long long 64 using 32 bit registers.
+ */
+#define __get_user_asm_ll32(__gu_err)					\
+({									\
+	__asm__ __volatile__(						\
+	"1:	lw	%1,%2					\n"	\
+	"2:	lw	%D1,%3					\n"	\
+	"	move	%0,$0					\n"	\
+	"3:	.section	.fixup,\"ax\"			\n"	\
+	"4:	li	%0,%4					\n"	\
+	"	move	%1,$0					\n"	\
+	"	move	%D1,$0					\n"	\
+	"	j	3b					\n"	\
+	"	.previous					\n"	\
+	"	.section	__ex_table,\"a\"		\n"	\
+	"	" __UA_ADDR "	1b,4b				\n"	\
+	"	" __UA_ADDR "	2b,4b				\n"	\
+	"	.previous					\n"	\
+	: "=r" (__gu_err), "=&r" (__gu_val)				\
+	: "o" (__m(__gu_addr)), "o" (__m(__gu_addr + 4)),		\
+	 "i" (-EFAULT));						\
 })
 
 extern void __get_user_unknown(void);
 
+/*
+ * Yuck.  We need two variants, one for 64bit operation and one
+ * for 32 bit mode and old iron.
+ */
+#ifdef __mips64
+#define __PUT_USER_DW(__pu_val) __put_user_asm("sd", __pu_val)
+#else
+#define __PUT_USER_DW(__pu_val) __put_user_asm_ll32(__pu_val)
+#endif
+
 #define __put_user_nocheck(x,ptr,size)					\
 ({									\
-	long __pu_err;							\
+	long __pu_err = 0;						\
 	__typeof__(*(ptr)) __pu_val;					\
 	long __pu_addr;							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
 	switch (size) {							\
-		case 1: __put_user_asm("sb"); break;			\
-		case 2: __put_user_asm("sh"); break;			\
-		case 4: __put_user_asm("sw"); break;			\
-		case 8: __put_user_asm("sd"); break;			\
-		default: __put_user_unknown(); break;			\
+	case 1: __put_user_asm("sb", __pu_val); break;			\
+	case 2: __put_user_asm("sh", __pu_val); break;			\
+	case 4: __put_user_asm("sw", __pu_val); break;			\
+	case 8: __PUT_USER_DW(__pu_val); break;				\
+	default: __put_user_unknown(); break;				\
 	}								\
 	__pu_err;							\
 })
 
 #define __put_user_check(x,ptr,size)					\
 ({									\
-	long __pu_err;							\
+	long __pu_err = 0;						\
 	__typeof__(*(ptr)) __pu_val;					\
 	long __pu_addr;							\
 	__pu_val = (x);							\
 	__pu_addr = (long) (ptr);					\
-	__asm__("":"=r" (__pu_err));					\
 	if (access_ok(VERIFY_WRITE, __pu_addr, size)) {			\
 		switch (size) {						\
-		case 1: __put_user_asm("sb"); break;			\
-		case 2: __put_user_asm("sh"); break;			\
-		case 4: __put_user_asm("sw"); break;			\
-		case 8: __put_user_asm("sd"); break;			\
+		case 1: __put_user_asm("sb", __pu_val); break;		\
+		case 2: __put_user_asm("sh", __pu_val); break;		\
+		case 4: __put_user_asm("sw", __pu_val); break;		\
+		case 8: __PUT_USER_DW(__pu_val); break;			\
 		default: __put_user_unknown(); break;			\
 		}							\
 	}								\
 	__pu_err;							\
 })
 
-#define __put_user_asm(insn)						\
+#define __put_user_asm(insn, __pu_val)					\
 ({									\
 	__asm__ __volatile__(						\
-	"1:\t" insn "\t%z1, %2\t\t\t# __put_user_asm\n\t"		\
-	"move\t%0, $0\n"						\
-	"2:\n\t"							\
-	".section\t.fixup,\"ax\"\n"					\
-	"3:\tli\t%0, %3\n\t"						\
-	"j\t2b\n\t"							\
-	".previous\n\t"							\
-	".section\t__ex_table,\"a\"\n\t"				\
-	".dword\t1b, 3b\n\t"						\
-	".previous"							\
+	"1:	" insn "	%z1, %2		# __put_user_asm\n"	\
+	"2:							\n"	\
+	"	.section	.fixup,\"ax\"			\n"	\
+	"3:	li	%0,%3					\n"	\
+	"	j	2b					\n"	\
+	"	.previous					\n"	\
+	"	.section	__ex_table,\"a\"		\n"	\
+	"	" __UA_ADDR "	1b, 3b				\n"	\
+	"	.previous					\n"	\
 	:"=r" (__pu_err)						\
 	:"Jr" (__pu_val), "o" (__m(__pu_addr)), "i" (-EFAULT));		\
 })
 
+#define __put_user_asm_ll32(__pu_val)					\
+({									\
+	__asm__ __volatile__(						\
+	"1:	sw	%1, %2		# __put_user_asm_ll32	\n"	\
+	"2:	sw	%D1, %3					\n"	\
+	"	move	%0, $0					\n"	\
+	"3:							\n"	\
+	"	.section	.fixup,\"ax\"			\n"	\
+	"4:	li	%0, %4					\n"	\
+	"	j	3b					\n"	\
+	"	.previous					\n"	\
+	"	.section	__ex_table,\"a\"		\n"	\
+	"	" __UA_ADDR "	1b, 4b				\n"	\
+	"	" __UA_ADDR "	2b, 4b				\n"	\
+	"	.previous"						\
+	:"=r" (__pu_err)						\
+	:"r" (__pu_val), "o" (__m(__pu_addr)),				\
+	 "o" (__m(__pu_addr + 4)), "i" (-EFAULT));			\
+})
+
 extern void __put_user_unknown(void);
 
 /*
@@ -307,7 +398,7 @@
 #ifdef MODULE
 #define __MODULE_JAL(destination)					\
 	".set\tnoat\n\t"						\
-	"dla\t$1, " #destination "\n\t"					 \
+	__UA_LA "\t$1, " #destination "\n\t" 				\
 	"jalr\t$1\n\t"							\
 	".set\tat\n\t"
 #else
@@ -362,6 +453,9 @@
 	__cu_len;							\
 })
 
+#define __copy_to_user_inatomic __copy_to_user
+#define __copy_from_user_inatomic __copy_from_user
+
 /*
  * copy_to_user: - Copy a block of data into user space.
  * @to:   Destination address, in user space.
@@ -403,10 +497,10 @@
 	".set\tnoreorder\n\t"						\
 	__MODULE_JAL(__copy_user)					\
 	".set\tnoat\n\t"						\
-	"daddu\t$1, %1, %2\n\t"						\
+	__UA_ADDU "\t$1, %1, %2\n\t"					\
 	".set\tat\n\t"							\
 	".set\treorder\n\t"						\
-	"move\t%0, $6"							\
+	"move\t%0, $6"		/* XXX */				\
 	: "+r" (__cu_to_r), "+r" (__cu_from_r), "+r" (__cu_len_r)	\
 	:								\
 	: "$8", "$9", "$10", "$11", "$12", "$15", "$24", "$31",		\
@@ -475,6 +569,24 @@
 	__cu_len;							\
 })
 
+#define __copy_in_user(to, from, n)	__copy_from_user(to, from, n)
+
+#define copy_in_user(to,from,n)						\
+({									\
+	void *__cu_to;							\
+	const void *__cu_from;						\
+	long __cu_len;							\
+									\
+	__cu_to = (to);							\
+	__cu_from = (from);						\
+	__cu_len = (n);							\
+	if (likely(access_ok(VERIFY_READ, __cu_from, __cu_len) &&	\
+	           access_ok(VERIFY_WRITE, __cu_to, __cu_len)))		\
+		__cu_len = __invoke_copy_from_user(__cu_to, __cu_from,	\
+		                                   __cu_len);		\
+	__cu_len;							\
+})
+
 /*
  * __clear_user: - Zero a block of memory in user space, with less checking.
  * @to:   Destination address, in user space.
@@ -499,7 +611,7 @@
 		"move\t%0, $6"
 		: "=r" (res)
 		: "r" (addr), "r" (size)
-		: "$4", "$5", "$6", "$8", "$9", "$31");
+		: "$4", "$5", "$6", __UA_t0, __UA_t1, "$31");
 
 	return res;
 }
@@ -547,7 +659,7 @@
 		"move\t%0, $2"
 		: "=r" (res)
 		: "r" (__to), "r" (__from), "r" (__len)
-		: "$2", "$3", "$4", "$5", "$6", "$8", "$31", "memory");
+		: "$2", "$3", "$4", "$5", "$6", __UA_t0, "$31", "memory");
 
 	return res;
 }
@@ -583,7 +695,7 @@
 		"move\t%0, $2"
 		: "=r" (res)
 		: "r" (__to), "r" (__from), "r" (__len)
-		: "$2", "$3", "$4", "$5", "$6", "$8", "$31", "memory");
+		: "$2", "$3", "$4", "$5", "$6", __UA_t0, "$31", "memory");
 
 	return res;
 }
@@ -599,7 +711,7 @@
 		"move\t%0, $2"
 		: "=r" (res)
 		: "r" (s)
-		: "$2", "$4", "$8", "$31");
+		: "$2", "$4", __UA_t0, "$31");
 
 	return res;
 }
@@ -628,7 +740,24 @@
 		"move\t%0, $2"
 		: "=r" (res)
 		: "r" (s)
-		: "$2", "$4", "$8", "$31");
+		: "$2", "$4", __UA_t0, "$31");
+
+	return res;
+}
+
+/* Returns: 0 if bad, string length+1 (memory size) of string if ok */
+static inline long __strnlen_user(const char *s, long n)
+{
+	long res;
+
+	__asm__ __volatile__(
+		"move\t$4, %1\n\t"
+		"move\t$5, %2\n\t"
+		__MODULE_JAL(__strnlen_user_nocheck_asm)
+		"move\t%0, $2"
+		: "=r" (res)
+		: "r" (s), "r" (n)
+		: "$2", "$4", "$5", __UA_t0, "$31");
 
 	return res;
 }
@@ -636,13 +765,16 @@
 /*
  * strlen_user: - Get the size of a string in user space.
  * @str: The string to measure.
- * @n:   The maximum valid length
+ *
+ * Context: User context only.  This function may sleep.
  *
  * Get the size of a NUL-terminated string in user space.
  *
  * Returns the size of the string INCLUDING the terminating NUL.
  * On exception, returns 0.
- * If the string is too long, returns a value greater than @n.
+ *
+ * If there is a limit on the length of a valid string, you may wish to
+ * consider using strnlen_user() instead.
  */
 static inline long strnlen_user(const char *s, long n)
 {
@@ -655,7 +787,7 @@
 		"move\t%0, $2"
 		: "=r" (res)
 		: "r" (s), "r" (n)
-		: "$2", "$4", "$5", "$8", "$31");
+		: "$2", "$4", "$5", __UA_t0, "$31");
 
 	return res;
 }

From thomas.koeller@baslerweb.com Wed Sep 22 15:48:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Sep 2004 15:48:06 +0100 (BST)
Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:29191
	"EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP
	id <S8224987AbUIVOsC>; Wed, 22 Sep 2004 15:48:02 +0100
Received: from comm1.baslerweb.com (proxy.baslerweb.com [172.16.13.2])
          by proxy.baslerweb.com (Post.Office MTA v3.5.3 release 223
          ID# 0-0U10L2S100V35) with ESMTP id com;
          Wed, 22 Sep 2004 16:47:10 +0200
Received: from vclinux-1.basler.corp (localhost [172.16.13.253]) by comm1.baslerweb.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id RPG5XQNL; Wed, 22 Sep 2004 16:47:58 +0200
From: Thomas Koeller <thomas.koeller@baslerweb.com>
Organization: Basler AG
To: "Linux/MIPS Development" <linux-mips@linux-mips.org>,
	Manish Lachwani <mlachwani@mvista.com>
Subject: pmc-sierra yosemite platform
Date: Wed, 22 Sep 2004 16:51:12 +0200
User-Agent: KMail/1.6.2
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200409221651.12521.thomas.koeller@baslerweb.com>
Return-Path: <thomas.koeller@baslerweb.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5864
X-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.koeller@baslerweb.com
Precedence: bulk
X-list: linux-mips

Hi,

some six weeks ago I submitted a patch that fixes
a couple of issues with the yosemite port. This did
not excite any reaction at all, and so I feel I must
be doing something wrong to be completly ignored.

Manish, since you obviously left PMC-Sierra, are you
still interested in maintaining the yosemite port?
If so, should I pass any patches to you? If not,
what else can I do to get anyone to at least look
at my patches? Or should I just create a private
fork and refrain from trying to contribute anything
back?

tk

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

Thomas Koeller, Software Development
Basler Vision Technologies

thomas dot koeller at baslerweb dot com
http://www.baslerweb.com

==============================

From mlachwani@mvista.com Wed Sep 22 17:43:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Sep 2004 17:43:09 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:28413 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8224987AbUIVQnF>; Wed, 22 Sep 2004 17:43:05 +0100
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id C87BA183D4; Wed, 22 Sep 2004 09:43:02 -0700 (PDT)
Message-ID: <4151AB96.4090704@mvista.com>
Date: Wed, 22 Sep 2004 09:43:02 -0700
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: Thomas Koeller <thomas.koeller@baslerweb.com>
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: pmc-sierra yosemite platform
References: <200409221651.12521.thomas.koeller@baslerweb.com>
In-Reply-To: <200409221651.12521.thomas.koeller@baslerweb.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: 5865
X-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

Thomas Koeller wrote:

>Hi,
>
>some six weeks ago I submitted a patch that fixes
>a couple of issues with the yosemite port. This did
>not excite any reaction at all, and so I feel I must
>be doing something wrong to be completly ignored.
>
>Manish, since you obviously left PMC-Sierra, are you
>still interested in maintaining the yosemite port?
>If so, should I pass any patches to you? If not,
>what else can I do to get anyone to at least look
>at my patches? Or should I just create a private
>fork and refrain from trying to contribute anything
>back?
>
>tk
>
>  
>
Hello Thomas

Sure, please send the patches over to me so that I can take a look at it.

thanks
Manish


From flo@rfc822.org Thu Sep 23 00:14:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Sep 2004 00:14:06 +0100 (BST)
Received: from hydra.gt.owl.de ([IPv6:::ffff:195.71.99.218]:61887 "EHLO
	hydra.gt.owl.de") by linux-mips.org with ESMTP id <S8225003AbUIVXOB>;
	Thu, 23 Sep 2004 00:14:01 +0100
Received: by hydra.gt.owl.de (Postfix, from userid 104)
	id DD469199498; Thu, 23 Sep 2004 01:13:58 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 94A6E138065; Thu, 23 Sep 2004 01:09:38 +0200 (CEST)
Date: Thu, 23 Sep 2004 01:09:38 +0200
From: Florian Lohoff <flo@rfc822.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: cvs head ip22/64 spaces.h
Message-ID: <20040922230938.GB17250@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc"
Content-Disposition: inline
Organization: rfc822 - pure communication
User-Agent: Mutt/1.5.4i
Return-Path: <flo@rfc822.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5866
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips


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


Hi,
it seems cvs head needs something like this. if not provided kernel
crashes early in free_bootmem_core on the last BUG

Flo

--- linux-20040922-2.6-mips64-ip22/include/asm-mips/mach-ip22/spaces.h	2004=
-09-21 12:59:52.000000000 +0200
+++ linux-20040922-2.6-mips64-ip22/include/asm-mips/mach-ip22/spaces.h	2004=
-09-22 19:22:40.000000000 +0200
@@ -0,0 +1,55 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Pub=
lic
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1994 - 1999, 2000, 03, 04 Ralf Baechle
+ * Copyright (C) 2000, 2002  Maciej W. Rozycki
+ * Copyright (C) 1990, 1999, 2000 Silicon Graphics, Inc.
+ */
+#ifndef _ASM_MACH_SPACES_H
+#define _ASM_MACH_SPACES_H
+
+#include <linux/config.h>
+
+#ifdef CONFIG_MIPS32
+
+#define CAC_BASE		0x80000000
+#define IO_BASE			0xa0000000
+#define UNCAC_BASE		0xa0000000
+#define MAP_BASE		0xc0000000
+
+/*
+ * This handles the memory map.
+ * We handle pages at KSEG0 for kernels with 32 bit address space.
+ */
+#define PAGE_OFFSET		0x80000000UL
+
+/*
+ * Memory above this physical address will be considered highmem.
+ */
+#ifndef HIGHMEM_START
+#define HIGHMEM_START		0x20000000UL
+#endif
+
+#endif /* CONFIG_MIPS32 */
+
+#ifdef CONFIG_MIPS64
+#define PAGE_OFFSET	0xffffffff80000000UL
+
+#ifndef HIGHMEM_START
+#define HIGHMEM_START		(1UL << 59UL)
+#endif
+
+#define CAC_BASE		0xffffffff80000000
+#define IO_BASE			0xffffffffa0000000
+#define UNCAC_BASE		0xffffffffa0000000
+#define MAP_BASE		0xffffffffc0000000
+
+#define TO_PHYS(x)		(             ((x) & TO_PHYS_MASK))
+#define TO_CAC(x)		(CAC_BASE   | ((x) & TO_PHYS_MASK))
+#define TO_UNCAC(x)		(UNCAC_BASE | ((x) & TO_PHYS_MASK))
+
+#endif /* CONFIG_MIPS64 */
+
+#endif /* __ASM_MACH_GENERIC_SPACES_H */
--=20
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

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

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

iD8DBQFBUgYyUaz2rXW+gJcRAq1SAJ9C6k+RL9QqdisuouIKzj1Luj4IQACg4LC1
fP3Wxesq4nGWKkWK915Ytsg=
=//nZ
-----END PGP SIGNATURE-----

--pvezYHf7grwyp3Bc--

From paul@clubi.ie Thu Sep 23 13:03:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Sep 2004 13:03:52 +0100 (BST)
Received: from hibernia.jakma.org ([IPv6:::ffff:212.17.55.49]:34453 "EHLO
	hibernia.jakma.org") by linux-mips.org with ESMTP
	id <S8224919AbUIWMDs>; Thu, 23 Sep 2004 13:03:48 +0100
Received: from hibernia.jakma.org (IDENT:paul@hibernia.jakma.org [192.168.0.3])
	by hibernia.jakma.org (8.12.11/8.12.11) with ESMTP id i8NC3jVr001154
	for <linux-mips@linux-mips.org>; Thu, 23 Sep 2004 13:03:45 +0100
Date: Thu, 23 Sep 2004 13:03:45 +0100 (IST)
From: Paul Jakma <paul@clubi.ie>
X-X-Sender: paul@hibernia.jakma.org
To: Linux MIPS <linux-mips@linux-mips.org>
Subject: O2/IP32 R10k status / gbefb and LCD
Message-ID: <Pine.LNX.4.61.0409231251580.21165@hibernia.jakma.org>
X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Return-Path: <paul@clubi.ie>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5867
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: paul@clubi.ie
Precedence: bulk
X-list: linux-mips

Hi,

Does anyone know the status of current CVS for IP32 R10k? Many parts 
of the O2 patches seem now to have been merged to CVS (gbefb), some 
parts I cant figure out though. Eg MACE audio? The "glaurung" patch 
adds a new file for mace audio driver support, which isnt in CVS, yet 
the definition for struct mace_audio in CVS is now filled out.

Does anyone know?

Also, R10k cache coherence, what's the status of that?

Also, does anyone have a known-working reasonably current IP32 kernel 
image? I've compiled my own from recent CVS, but it doesnt appear to 
work - no modechange once PROM loads it. If anyone would have a known 
good recent build of an IP32 kernel (with gbefb obviously), I'd be 
very grateful.. i dont quite yet have anything to serial console it 
to, and i'm trying to figure out if the apparent LCD support in 
gbefb is working (gbefb=monitor:lcd).

Thanks in advance from someone who'd desperately prefer to be running 
Linux to IRIX.. ;)

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Q:	Why is it that Mexico isn't sending anyone to the '84 summer games?
A:	Anyone in Mexico who can run, swim or jump is already in LA.

From thomas.koeller@baslerweb.com Thu Sep 23 14:08:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Sep 2004 14:08:38 +0100 (BST)
Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:8466
	"EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP
	id <S8224931AbUIWNIc>; Thu, 23 Sep 2004 14:08:32 +0100
Received: from comm1.baslerweb.com (proxy.baslerweb.com [172.16.13.2])
          by proxy.baslerweb.com (Post.Office MTA v3.5.3 release 223
          ID# 0-0U10L2S100V35) with ESMTP id com;
          Thu, 23 Sep 2004 15:07:41 +0200
Received: from vclinux-1.basler.corp (localhost [172.16.13.253]) by comm1.baslerweb.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id TPGPBX2L; Thu, 23 Sep 2004 15:08:30 +0200
From: Thomas Koeller <thomas.koeller@baslerweb.com>
Organization: Basler AG
To: Manish Lachwani <mlachwani@mvista.com>
Subject: [PATCH] pmc-sierra yosemite serial i/o support
Date: Thu, 23 Sep 2004 15:11:06 +0200
User-Agent: KMail/1.6.2
References: <200409221651.12521.thomas.koeller@baslerweb.com> <4151AB96.4090704@mvista.com>
In-Reply-To: <4151AB96.4090704@mvista.com>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200409231511.06274.thomas.koeller@baslerweb.com>
Return-Path: <thomas.koeller@baslerweb.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5868
X-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.koeller@baslerweb.com
Precedence: bulk
X-list: linux-mips

On Wednesday 22 September 2004 18:43, Manish Lachwani wrote:
>
> Hello Thomas
>
> Sure, please send the patches over to me so that I can take a look at it.
>
> thanks
> Manish

Hi Manish,

here's the patch again, as a diff against current cvs head. It addresses the
following issues:

- avoids autodetection of the uart chip type. The chip was always detected as
  a fifo-less 16540. Autodetection really isn't required here, since we know
  exactly what we're dealing with.

- enables interrupt sharing for both ports. Since the two uart interrupt lines
  are physically ORed together, this makes the second port fully usable.

- use 'arch_initcall' instead of the 'late_time_init' hook, as is appropriate.

thomas



Signed-off-by: Thomas Koeller  <thomas.koeller@baslerweb.com>

diff -ru linux-mips-cvs/arch/mips/pmc-sierra/yosemite/dbg_io.c linux-mips-work/arch/mips/pmc-sierra/yosemite/dbg_io.c
--- linux-mips-cvs/arch/mips/pmc-sierra/yosemite/dbg_io.c	2004-08-20 12:30:47.000000000 +0200
+++ linux-mips-work/arch/mips/pmc-sierra/yosemite/dbg_io.c	2004-09-23 14:04:12.002692920 +0200
@@ -23,18 +23,22 @@
  *  675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
-/*
- * Support for KGDB for the Yosemite board. We make use of single serial
- * port to be used for KGDB as well as console. The second serial port
- * seems to be having a problem. Single IRQ is allocated for both the
- * ports. Hence, the interrupt routing code needs to figure out whether
- * the interrupt came from channel A or B.
- */
-
 #include <linux/config.h>
 
+#include <asm/io.h>
+
+#include "setup.h"
+  
 #ifdef CONFIG_KGDB
-#include <asm/serial.h>
+
+#if defined(CONFIG_SERIAL_8250) && CONFIG_SERIAL_8250_NR_UARTS > 1
+#error Debug port used by serial driver
+#endif
+
+#define TITAN_UART_CLK		3686400
+#define TITAN_SERIAL_BASE_BAUD	(TITAN_UART_CLK / 16)
+#define TITAN_SERIAL_BASE_0	0xfd000008UL
+#define TITAN_SERIAL_BASE_1	0xfd000000UL
 
 /*
  * Baud rate, Parity, Data and Stop bit settings for the
@@ -71,6 +75,7 @@
 #define	SERIAL_SEND_BUFFER	0x0
 #define	SERIAL_INTR_ENABLE	(1 * SERIAL_REG_OFS)
 #define	SERIAL_INTR_ID		(2 * SERIAL_REG_OFS)
+#define	SERIAL_FIFO_CONTROL	SERIAL_INTR_ID
 #define	SERIAL_DATA_FORMAT	(3 * SERIAL_REG_OFS)
 #define	SERIAL_LINE_CONTROL	(3 * SERIAL_REG_OFS)
 #define	SERIAL_MODEM_CONTROL	(4 * SERIAL_REG_OFS)
@@ -84,59 +89,28 @@
 #define	SERIAL_DIVISOR_MSB	(1 * SERIAL_REG_OFS)
 
 /*
- * Functions to READ and WRITE to serial port 0
+ * Functions to READ and WRITE to serial port
  */
 #define	SERIAL_READ(ofs)		(*((volatile unsigned char*)	\
-					(TITAN_SERIAL_BASE + ofs)))
-
+					(serbase + ofs)))
 #define	SERIAL_WRITE(ofs, val)		((*((volatile unsigned char*)	\
-					(TITAN_SERIAL_BASE + ofs))) = val)
-
-/*
- * Functions to READ and WRITE to serial port 1
- */
-#define	SERIAL_READ_1(ofs)		(*((volatile unsigned char*)	\
-					(TITAN_SERIAL_BASE_1 + ofs)
-
-#define	SERIAL_WRITE_1(ofs, val)	((*((volatile unsigned char*)	\
-					(TITAN_SERIAL_BASE_1 + ofs))) = val)
-
-/*
- * Second serial port initialization
- */
-void init_second_port(void)
-{
-	/* Disable Interrupts */
-	SERIAL_WRITE_1(SERIAL_LINE_CONTROL, 0x0);
-	SERIAL_WRITE_1(SERIAL_INTR_ENABLE, 0x0);
+					(serbase + ofs))) = val)
 
-	{
-		unsigned int divisor;
-
-		SERIAL_WRITE_1(SERIAL_LINE_CONTROL, 0x80);
-		divisor = TITAN_SERIAL_BASE_BAUD / YOSEMITE_BAUD_115200;
-		SERIAL_WRITE_1(SERIAL_DIVISOR_LSB, divisor & 0xff);
-
-		SERIAL_WRITE_1(SERIAL_DIVISOR_MSB,
-			       (divisor & 0xff00) >> 8);
-		SERIAL_WRITE_1(SERIAL_LINE_CONTROL, 0x0);
-	}
-
-	SERIAL_WRITE_1(SERIAL_DATA_FORMAT, YOSEMITE_DATA_8BIT |
-		       YOSEMITE_PARITY_NONE | YOSEMITE_STOP_1BIT);
-
-	/* Enable Interrupts */
-	SERIAL_WRITE_1(SERIAL_INTR_ENABLE, 0xf);
-}
+static int initialized = 0;
 
 /* Initialize the serial port for KGDB debugging */
 void debugInit(unsigned int baud, unsigned char data, unsigned char parity,
-	       unsigned char stop)
+	unsigned char stop)
 {
+	initialized = 1;
+	
 	/* Disable Interrupts */
 	SERIAL_WRITE(SERIAL_LINE_CONTROL, 0x0);
 	SERIAL_WRITE(SERIAL_INTR_ENABLE, 0x0);
 
+	/* Disable FIFOs */
+	SERIAL_WRITE(SERIAL_FIFO_CONTROL, 0x00);
+
 	{
 		unsigned int divisor;
 
@@ -152,15 +126,11 @@
 	SERIAL_WRITE(SERIAL_DATA_FORMAT, data | parity | stop);
 }
 
-static int remoteDebugInitialized = 0;
-
 unsigned char getDebugChar(void)
 {
-	if (!remoteDebugInitialized) {
-		remoteDebugInitialized = 1;
+	if (!initialized) {
 		debugInit(YOSEMITE_BAUD_115200,
-			  YOSEMITE_DATA_8BIT,
-			  YOSEMITE_PARITY_NONE, YOSEMITE_STOP_1BIT);
+			  YOSEMITE_DATA_8BIT, YOSEMITE_PARITY_NONE, YOSEMITE_STOP_1BIT);
 	}
 
 	while ((SERIAL_READ(SERIAL_LINE_STATUS) & 0x1) == 0);
@@ -169,11 +139,9 @@
 
 int putDebugChar(unsigned char byte)
 {
-	if (!remoteDebugInitialized) {
-		remoteDebugInitialized = 1;
+	if (!initialized) {
 		debugInit(YOSEMITE_BAUD_115200,
-			  YOSEMITE_DATA_8BIT,
-			  YOSEMITE_PARITY_NONE, YOSEMITE_STOP_1BIT);
+			  YOSEMITE_DATA_8BIT, YOSEMITE_PARITY_NONE, YOSEMITE_STOP_1BIT);
 	}
 
 	while ((SERIAL_READ(SERIAL_LINE_STATUS) & 0x20) == 0);
diff -ru linux-mips-cvs/arch/mips/pmc-sierra/yosemite/irq.c linux-mips-work/arch/mips/pmc-sierra/yosemite/irq.c
--- linux-mips-cvs/arch/mips/pmc-sierra/yosemite/irq.c	2004-08-20 12:30:47.000000000 +0200
+++ linux-mips-work/arch/mips/pmc-sierra/yosemite/irq.c	2004-09-21 13:22:13.000000000 +0200
@@ -109,10 +109,6 @@
 	do_IRQ(irq, regs);
 }
 
-#ifdef CONFIG_KGDB
-extern void init_second_port(void);
-#endif
-
 /*
  * Initialize the next level interrupt handler
  */
@@ -123,15 +119,6 @@
 	set_except_vector(0, titan_handle_int);
 	mips_cpu_irq_init(0);
 	rm7k_cpu_irq_init(8);
-
-#ifdef CONFIG_KGDB
-	/* At this point, initialize the second serial port */
-	init_second_port();
-#endif
-
-#ifdef CONFIG_GDB_CONSOLE
-	register_gdb_console();
-#endif
 }
 
 #ifdef CONFIG_KGDB
diff -ru linux-mips-cvs/arch/mips/pmc-sierra/yosemite/setup.c linux-mips-work/arch/mips/pmc-sierra/yosemite/setup.c
--- linux-mips-cvs/arch/mips/pmc-sierra/yosemite/setup.c	2004-09-21 13:08:14.000000000 +0200
+++ linux-mips-work/arch/mips/pmc-sierra/yosemite/setup.c	2004-09-23 11:37:18.106608792 +0200
@@ -24,6 +24,7 @@
  *  with this program; if not, write  to the Free Software Foundation, Inc.,
  *  675 Mass Ave, Cambridge, MA 02139, USA.
  */
+#include <linux/config.h>
 #include <linux/bcd.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
@@ -45,6 +46,7 @@
 #include <asm/ptrace.h>
 #include <asm/reboot.h>
 #include <asm/serial.h>
+#include <asm/gdb-stub.h>
 #include <linux/termios.h>
 #include <linux/tty.h>
 #include <linux/serial.h>
@@ -143,12 +145,10 @@
 
 unsigned long uart_base = 0xfd000000L;
 
-/* No other usable initialization hook than this ...  */
-extern void (*late_time_init)(void);
-
 unsigned long ocd_base;
-
 EXPORT_SYMBOL(ocd_base);
+unsigned long serbase;
+EXPORT_SYMBOL(serbase);
 
 /*
  * Common setup before any secondaries are started
@@ -157,11 +157,13 @@
 #define TITAN_UART_CLK		3686400
 #define TITAN_SERIAL_BASE_BAUD	(TITAN_UART_CLK / 16)
 #define TITAN_SERIAL_IRQ	4
-#define TITAN_SERIAL_BASE	0xfd000008UL
+#define TITAN_SERIAL_BASE	0xfd000000UL
+#define TITAN_SERIAL_REG_SIZE	8
 
-static void __init py_map_ocd(void)
+static int __init py_map_ocd(void)
 {
-        struct uart_port up;
+	static const char serr[] = KERN_ERR "Serial port #%u setup failed\n";
+	struct uart_port up;
 
 	/*
 	 * Not specifically interrupt stuff but in case of SMP core_send_ipi
@@ -171,21 +173,46 @@
 	if (!ocd_base)
 		panic("Mapping OCD failed - game over.  Your score is 0.");
 
+	/* Map uart registers */
+	serbase = (unsigned long) ioremap(TITAN_SERIAL_BASE, TITAN_SERIAL_REG_SIZE * 2);
+	if (!serbase)
+		panic("Failed to map UART registers");
+
+#if defined(CONFIG_SERIAL_8250)
 	/*
-	 * Register to interrupt zero because we share the interrupt with
-	 * the serial driver which we don't properly support yet.
+	 * Set up serial port #0. Do not use autodetection; the result is
+	 * not what we want.
 	 */
 	memset(&up, 0, sizeof(up));
-	up.membase      = (unsigned char *) ioremap(TITAN_SERIAL_BASE, 8);
+	up.membase      = (char *) (serbase + TITAN_SERIAL_REG_SIZE);
 	up.irq          = TITAN_SERIAL_IRQ;
 	up.uartclk      = TITAN_UART_CLK;
 	up.regshift     = 0;
 	up.iotype       = UPIO_MEM;
-	up.flags        = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
+	up.type         = PORT_16550A;
+	up.flags        = UPF_SHARE_IRQ;
 	up.line         = 0;
+	if (early_serial_setup(&up))
+		printk(serr, up.line);
 
+#if CONFIG_SERIAL_8250_NR_UARTS > 1
+	/* And now for port #1. */
+	up.membase      = (char *) serbase;
+	up.line         = 1;
 	if (early_serial_setup(&up))
-		printk(KERN_ERR "Early serial init of port 0 failed\n");
+		printk(serr, up.line);
+#endif /* CONFIG_SERIAL_8250_NR_UARTS > 1 */
+#endif  /* defined(CONFIG_SERIAL_8250) */
+
+#ifdef CONFIG_KGDB
+	printk(KERN_INFO "Start kgdb ... \n");
+#ifdef CONFIG_GDB_CONSOLE
+	register_gdb_console();
+#endif
+	set_debug_traps();
+	breakpoint();
+#endif
+	return 0;
 }
 
 static int __init pmc_yosemite_setup(void)
@@ -193,21 +220,12 @@
 	extern void pmon_smp_bootstrap(void);
 
 	board_time_init = yosemite_time_init;
-	late_time_init = py_map_ocd;
 
 	/* Add memory regions */
 	add_memory_region(0x00000000, 0x10000000, BOOT_MEM_RAM);
 
-#if 0 /* XXX Crash ...  */
-	OCD_WRITE(RM9000x2_OCD_HTSC,
-	          OCD_READ(RM9000x2_OCD_HTSC) | HYPERTRANSPORT_ENABLE);
-
-	/* Set the BAR. Shifted mode */
-	OCD_WRITE(RM9000x2_OCD_HTBAR0, HYPERTRANSPORT_BAR0_ADDR);
-	OCD_WRITE(RM9000x2_OCD_HTMASK0, HYPERTRANSPORT_SIZE0);
-#endif
-
 	return 0;
 }
 
 early_initcall(pmc_yosemite_setup);
+arch_initcall(py_map_ocd);
diff -ru linux-mips-cvs/arch/mips/pmc-sierra/yosemite/setup.h linux-mips-work/arch/mips/pmc-sierra/yosemite/setup.h
--- linux-mips-cvs/arch/mips/pmc-sierra/yosemite/setup.h	2004-05-24 12:32:42.000000000 +0200
+++ linux-mips-work/arch/mips/pmc-sierra/yosemite/setup.h	2004-09-21 13:22:13.000000000 +0200
@@ -28,4 +28,7 @@
 #define	TITAN_ATMEL_24C32_SIZE		32768
 #define	TITAN_ATMEL_24C64_SIZE		65536
 
+/* UART base */
+extern unsigned long serbase;
+
 #endif /* __SETUP_H__ */


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

Thomas Koeller, Software Development
Basler Vision Technologies

thomas dot koeller at baslerweb dot com
http://www.baslerweb.com

==============================

From stuartl@longlandclan.hopto.org Thu Sep 23 14:54:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Sep 2004 14:54:37 +0100 (BST)
Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:22055
	"EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP
	id <S8224931AbUIWNyb>; Thu, 23 Sep 2004 14:54:31 +0100
Received: (qmail 29159 invoked from network); 23 Sep 2004 23:54:20 +1000
Received: from unknown (HELO ?10.0.0.251?) (10.0.0.251)
  by 192.168.5.1 with SMTP; 23 Sep 2004 23:54:20 +1000
Message-ID: <4152D58B.608@longlandclan.hopto.org>
Date: Thu, 23 Sep 2004 23:54:19 +1000
From: Stuart Longland <stuartl@longlandclan.hopto.org>
User-Agent: Mozilla Thunderbird 0.7 (X11/20040615)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Kernel 2.6 for R4600 Indy
X-Enigmail-Version: 0.84.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/mixed;
 boundary="------------070400090104030606090106"
Return-Path: <stuartl@longlandclan.hopto.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: 5869
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: stuartl@longlandclan.hopto.org
Precedence: bulk
X-list: linux-mips

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

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

Hi All,
	I've been trying to get Linux 2.6 going on my Indy for some time now.
However, I've had little success.  The machine works just fine under
Linux 2.4.26.

	The kernel config is attached.  Basically I've tried both booting a
MIPS32 kernel as well as a MIPS64 kernel.  In all cases, I've used the
same kernel parameters.  (root=/dev/hda3, and sometimes I put
init=/bin/sh or single there too.)

	Using a MIPS32 config, the kernel boots, mounts the / filesystem, but
then dies claiming it can't find /sbin/init.

	Using a MIPS64 config (built using gas-abi=o32 as suggested by Kumba),
it doesn't even get that far:

- From arcboot/SGI PROM:
(Arcboot version 0.3.8.2)
- -------------------------------8<--------------------------------------
Loading program segment 2 at 0x88002000, offset=0x0, size= 0x0 328085
Zeroing memory at 0x0032a085, size = 0x1bba3

Exception: <vector=Normal>
Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x8010<CE=0,IP8,EXC=RADE>
Exception PC: 0x830f018, Exception RA: 0x88804514
Read address error exception, bad address: 0x830f018
Local I/O interrupt register 1: 0x80 <VR/GIO2>
  Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
  arg: a8740000 88002000 88001fe0 18
  tmp: a8740000 3 8880e0b4 830f018 8880e0b0 887fe8ec 887fe5e4 4
  sve: a8740000 3 400000 800000 16 3f80 0 10000000
  t8 a8740000 t9 ffffffff at ffffffff v0 ffffffff v1 ffffffff k1 830f018
  gp a8740000 f0 ffffffff sp ffffffff ra ffffffff

PANIC: Unexpected exception

[Press reset or ENTER to restart.]
- ------------------------------->8--------------------------------------

	Now, according to the Linux-MIPS website:
- -------------------------------8<--------------------------------------
*Self-compiled kernels crash when booting.*

When I build my own kernel, it crashes. On an Indy the crash message
looks like the following (the same problem hits other machines as well
but may look completely different):

 Exception: <vector=UTLB Miss>
 Status register: 0x300004803<CU1,CU0,IM4,IPL=???,MODE=KERNEL,EXL,IE>
 Cause register: 0x8008<CE=0,IP8,EXC=RMISS>
 Exception PC: 0x881385cc, Exception RA: 0x88002614
 exception, bad address: 0x47c4
 Local I/O interrupt register 1: 0x80 <VR/GIO2>
 Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
   arg: 7 8bfff938 8bfffc4d 880025dc
   tmp: 8818c14c 8818c14c 10 881510c4 14 8bfad9e0 0 48
   sve: 8bfdf3e8 8bfffc40 8bfb2720 8bfff938 a8747420 9fc56394 0 9fc56394
   t8 48 t9 8bfffee66 at 1 v0 0 v1 8bfff890 k1 bad11bad
   gp 881dfd90 fp 9fc4be88 sp 8bfff8b8 ra 88002614

 PANIC: Unexpected exception

This problem is caused by a still unfixed bug in Binutils newer than
version 2.7. As a workaround, change the following line in
arch/mips/Makefile from:

       LINKFLAGS       = -static -N
to:
       LINKFLAGS       = -static
- ------------------------------->8--------------------------------------

	This looks scaringly similar to what I've already struck.  Certainly
the Status Register is almost identical.  I've also had it come up UTLB
Miss as well.

	It seems though, the fix is more illusive.  Looking at
arch/mips/Makefile, there's no LINKFLAGS line.  The closest thing I see
is LDFLAGS_vmlinux:

LDFLAGS_vmlinux                 += -G 0 -static -n

The binutils/gcc versions I'm using are cross compillers generated using
crossdev:

MIPS32 binutils:
GNU assembler 2.14.90.0.8 20040114
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `mips-unknown-linux-gnu'.

MIPS64 binutils:
GNU assembler 2.14.90.0.8 20040114
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `mips64-unknown-linux-gnu'.

MIPS32 gcc:
mips-unknown-linux-gnu-gcc (GCC) 3.3.3 20040217 (Gentoo Linux 3.3.3,
propolice-3.3-7)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

MIPS64 gcc:
mips64-unknown-linux-gnu-gcc (GCC) 3.3.3 20040217 (Gentoo Linux 3.3.3,
propolice-3.3-7)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

	Has this bug actually been fixed?  It seems the documentation here is a
little lacking as to what to change.

The machine's specs:
CPU: R4600 SC 133MHz [1]
RAM: 256MB 72pin EDO
HDD: 9.1GB IBM
OS:  Gentoo Linux/MIPS 1.4

	Apologies if this has been answered before... but I'm a bit of a newbie
when it comes to Linux/MIPS.[2]  Is there anything I missed when setting
this all up?

Reguards,
- --
+-------------------------------------------------------------+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project     -oOo-    http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-------------------------------------------------------------+
Footnotes:
1. A brief look at the MIPS Technologies website had me thinking that
only R5k and above are 64-bit, the R4k were 32-bit.  But it seems that
these too are 64-bit capable.
2. I'll admit though... I've learned more about the innards of a
computer playing with the Indy and Qube I own then I have from the last
two years of university study.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUtWLuarJ1mMmSrkRAvIZAJ0QuwKzWGg3rRk9nzEU17bLfc38MgCfarfQ
+XK9eCVUaC88I5KtBh8fXjE=
=SIHi
-----END PGP SIGNATURE-----

--------------070400090104030606090106
Content-Type: application/x-gzip;
 name="config.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="config.gz"

H4sIABDKUkECA40b25LauPJ9v8KVfThJ1WYzXAe2Kg+yLEBBvsSSGSYvLgLOjE8YzOGSzfz9
adl4LNuyoWo3ibtbLXWr1TeJP//400DnU/KyOsXr1Xb7ajxFu+iwOkUb42X1MzLWye5H/PSP
sUl2/zkZ0SY+wQgW786/jZ/RYRdtjV/R4Rgnu3+M7t/Dv8cfD+vux5d4f1z/On7s3t3178bd
HgwRz2eDR3uj24P//rkb/NO9MyT6jz//wK4zodPQph7//Aqkyvewb8RHY5ecjGN0KlDDvkmF
ilGG9LrABLgCcbKJQIjT+RCfXo1t9AsWm+xPsNZjMStZesSnNnEEYjDwAsWMICfEru1RRgqw
6btz4oSuE3Lby6eZpgrbynWc9wVj5mLEFsTn1HU+v3uXg/kD8gqG/JEvqIcLgOdyugztrwEJ
iKoMk1uh57uYcB4ijHXCAy8sFBlQYFFRfDIXuASTkM/oRHzu9AveM1d4LJhqWNJ59o+CSw5J
F1OAiW0SyyJWAZkjxvijXdrRHAZKFz4KPcS5ZtJJIMhSYe25TJGKuhzPiBU6ruvVoYjXYRZB
FqMOqWPw5Ku6PIxD1xPUpt9IOHH9kMM/dHqe2cRWxwnqPGZQlTq1DZasNqvvWzDDZHOGv47n
/T45nBSjd62AkbLdp6AwcJiLLM38rsldRgSRhB7y7crYi8npNDsHdG619mr9HO9gRdE2Wssz
kR2ZCxuEZ+EX9O2b9vSZaEpEeta06HTwwu93lkstXrhggiYKv9h+b9y91/MA5nD8TMRE8xwW
wVwgAcI28yCLYb8DrqaFYDzs3LUQ0IWvRTLEkWgZJsioc99tJkACODSjbRAdNaM5KduGYgHg
y7AbgqtgrriBJJzeQoRbib6gaYB8EEm/456Nw0eXExuUoiWwLHNwd99vxPXvhy04vQk5BI4z
93zyqDvDUxpSr9tVzw53MfjMzrLBGDg1H+HQcbPz+/dvSayncmjo2xDYQg/TVvP3TbHsV+z/
QuI/gK7CKXEgMuGQexRcAZ4X/muGFkRaf1gGI1/xyJaNwEfC5syID8Gt5Oe8IGRUCHAyxLEo
cnSe3/8q6ZRIBXELHCesBmE1IrpgHIRN0qirGijrhBgOKbnEm4GyyF5J7RNTMz1QwfF3pKMr
ySfDjs2o+RbivUDvwaSMWTag3YQc3ZBfSLTfu2uwBIkVy964wb9JdIv7S3n3e2XeJRxYYHW7
pKm08Ru0rdUf9FvU4A/bxjpkgSzUPHjUOjE41ja0fd+OHreh4SBqNOhBbEoDd9ifm6oWC8Ro
buq91BtFZ3iVZNif6+zWdJFvhTy1fCXfAE+TrTlHlDPZ0Js9QkCwLL9RWmQtkIOJ1WA0MwQn
jnHl/BdQi2OrDuePDi7pxyfE9kQtgzHPxzxpNt6DT/vL8LCNKfrLIJTDn+kfAn9QD5/E6LJz
O8jPLfkdrc+nNDP6Ecs/kgMk6kpablJnYqeeRfE1GcymIOdLDoREEhROpw5ivEZKfbrMp7Si
X/E6MqxDLAsWABXJe7y+gA23Wh5AguFYiLlq+giqWoBLDSfUtx+QTyCtpqxIrKKX5PBqiGj9
vEu2ydPrZWZQny2skp7gu6ZvbwW1xBYqFZknKvmiYoO+5/r1jfK25ydjtdvAP1avysBsF7fJ
+qexyRaicjPZHCLJIpzoLCtHMplrv1Sh2H/0hKvHOaZVB/rI1gLTE/UZCsWhkl2ZddUggT7B
/x79ZE/sTz5jOvVQi9QGcszpRfh6Bi6RSpiDr7S2CSc839F0+GWccXrdR8b7TXz8+ZdxWu2j
vwxsfYSg9EGx3YtoXD12Mz+DiUIFOczlKvRttA+w2j5xPwTbs9wGT5HPMq3rIHmJVEWAOUZ/
P/0Nqzf+e/4ZfU9+f3iT8eW8PcV7OJYscErWkmrHDpigIaB0eZUkkIEbjo0oVTUpBmrQKXWm
+g0Sh9XumM6PTqdD/P18io7lbZKpECSZwueqalLMBGcIPett8u/HrP7fvB3/IhN8sMa93AzK
XCHD18e+FGsRM6jLYkvlfSxbm/HeR9RKTydb2GUfULfzyVn2UwzpjWtGmxJQQojR6Y37xvtJ
fIge4P8PNZqu2zDaiU7/Joef8e6pfhgcInKrV8hqTRPIAedE6S1k3+Dg1d4G8IKyOzXbAhg4
dFkiCefksTB+6qhsqZcZG0a8lMACPI+Hoe8Ggvi6DNYLPccrMYPv0JrhOlBmsV5lBgn3wdc2
FBcQXDzahpz6+lpHCpUuWouFCfV1HcRrOFjunBJdZS/1FqJZWZEh4V4FQj3Z06oAReA4hClA
bzFUVbQYgkekC4QfFSgMHNZmHNanHGrnHGonLYCqLieU6Xd4OUmbH8pXGHAi3ebl5AvPwGn7
8nxYSQs23qvdvtIxhF1J6bV7Imx9H8Sn1lS/jQuGnHB01+181detBINgGpEYU1Ib+OiquqDe
smF9iM21mGV30NC78MxG07Xogvj6zgGBv4ke9QAC189iifHsIZww9wEgwndZze19Tbj0kJ+S
g/FjFR+M/52jcwTuR90mySbt3TVOghkPa8dLdWgGhJWThq03F1BxN/GVTcjGOSUyvIjFGhQw
QzZkqtTV+wS/ocYydUYCU4JPpbjcNrQC237UM3Ghynf0bR7yNUAM0i/9okWgVwgRMzAR5NV0
TE7P8lIAAl7nzoCNhALQ/h6fPpQiTDa85OltSgu7h5DMCfn6VisoPKEezPlpcBWkSH5GO8OX
EazIfFOMjJjb6Hg04Jga73fJ7uPz6uWw2sTJh6pZ1DYtY7DaGfHuFB1+rCoJ9YO2neJ5igOE
jyyuyfBYqsEA0ejtJBKlVVuJkYSEQjyWoRaZMCRIGWhyq+yJAegqNJxRr5RYwXd6B+ITzhuO
XErDbdTgMFK07Vok/Ze+icdnyGv2GpcuUG0HKLccyF++H1+Pp+il5MolpkouYL/3z8nu1eCa
kmoGbq0+w25/PjWWDdTxgrdcKThGh63M7vQ2kdKCGiA6wcHVe4CU5Iv72E4geDueLK7hdSlr
Jin95Crp8dvAKbJJteB865gGjvVGoBRREGPdymdIR3f9bhUIf2qGhliMuvi+c5eH8myBtQq+
JBrkkWn3RbmCukAgQM5Nq3QRlWN44MxNvWW/0bD5VZKluErikAfhajuthXEo/lB+hh7vli93
JFBqCLGGdrwkWPDlcolQu5lxyKrnbYbmBnjGsU8aQuJl1ZTjmjXh59VhtYZzoHjdPC1Sdnoh
6h1eyBAKWOEgUollNzvrxvj1kolHh3i11ZnvZfCoO7irZwTg+FPEMRteabmUOaRNvG8UStiy
tZZQdZEuJNj19cD6CFkijUehJx6VhhYjU8i/G4HAJXDE5+5geDkwnk3L6a1NIQVxrEp6cglm
p/XzJnky8OqwUXbrAQk8s1J5lfCWwWA3HtAj5FnN3GrHVblpmYg3Tg3mZT024XzRcPUyhZKc
d7ojfZiB5K5xqCUaEmi/Ny5fEWQFetb4gdzD+LFN9vvXtBOUh4rMCFV50VRfWFi+vrDw0QPg
ZBped9VdrIlFXSUpgI8Qz+CQQNn9UgxC26fkEJ+eX46lcSFiU9ekojxeAj08KRUfb2BdazfH
yk1QZ52BRf27OkRpG1nXrZPjbOt+oN+zC3rU6XQa8ZVecwl36ZWGjE5n2gCGf8urOoTNqqgg
ZpVzuu43gXi0OyaHI3i7eN8kGSdwtPWZTYaSTX+7A2XiDTSD6zS9K3y42XTTnZPA+RleWc1E
1l/tQk3ZoDPidisNFaP7VgJm3w+uEVzlMLpCMLq7RtC7RnBtkeP2KWy07Aw741YabnPcv7fb
9+Vh1LsfdaxrNOx+NBD8GtWwez+b1IzfldVWeq6brD5nQYi8qG2dBfzLaNBw51+iGbfLDT59
NGi4x5WHMO3SpqH2Con0X1dIzIBfm2dG61WxtdpuV8f/HI3Ox3+h8jS+n8slY6feRI6P62rR
mjaWX6JNvNIkVtQibqi4/EW8iRJjAiV4+lYv55GB0Wa1P5VS6Gw89ihSHWEG5QgNuv2hzu2r
BGPlTi5wiB/27nrDOjd3gZGt1ZIv6291bUo8hBocTgrhwq/X4lb8FJ8ge8tkMw/JarNepS2e
/OZN5WUtzBqH6WG1f47Xx2qnHCfg47cQ0ePjXl6qZZFdZ/eLKQo1laqSmUD+n4aiWrqX9m3q
4InriHD0uzPMa0yWPCWX15iXdqa6AMg9Xc2dz3m3URJZWa7l7NDm12q3jjaXt5wpqYEO6+f4
FK1P50NUOtZOPeV299HuMozXavCsMvRkq7U2MOBmVdESNF1tnqKTrjwHLBSZ1pTUk82JvDzO
WgClN52im93fFR2rDBQu5S2RZosA38uGlAHZgDo4e6eJMKujOMGBT4XSLP9Srj7hs353lG87
RASz9krAJxRKhokMvpoxX1JEcfy+VNZXTAyI2sQlbPqeTtaGXL82jdjLbHZlGglp6AdJ1NfA
FUjbztfpbqmf1aZQJWVSF1py7ZqK3pBNs6JAuLkEJVBfuQHOrng/WQsrtbiawVHujofDu/Iu
uIyqLc5vQKTOkn1XRAisSUWAzMW5/NMEiU+OqMxflP4caJpkX8DYJpwjajrLnhMco/MmSV9n
1MQt7sdVwLxS4z5ylQRiU0XNGcROC1e1j52Cm80U8J7gbWdZ2F7ZIGcB+A5mps93dM/tkF1s
tYy8EYTrXZRAyfJDr21kNRsamjTjZq0ojwWNaJM0DzWbUS2jcCq23l6WLev0Ws6Ys+w3Y+Vb
9yZcoDfC/MomdfO8aoZOxaDk96KnbnwK0aeGEmVRn2BRbu8XaKvE2aqztlp4W6HAns7W5HtJ
R121fMNpVT6BsRpXZOKgDuGB43ul11vwCa4znHIezn1TX5IoNNyb2z1domKbFYckIQ6T53GC
gobH2Jhqw5KDvQozgEhvnj0WkG+2mm6lMkLqYsFShbTTyaywlUDutcNbCFzebSfgNmIMPGzb
JKwNm/7iQacl7FqooqYLKHSZFSKPNngZvddeHU5xetUtXvdR6cWGL6h8Kv/2ckI1HwSu2ylo
tDO6fHKFAtl0iq7RCOTTKzQ2wnqKUqx7o6j+TMaifM6QSRp65GniwAOzfQ2QjMNCIcaMhldW
K9u16SvA9nmZZbcKJWsErUhw6nxY8ZXlBte2j0wa1J45WigofkUGW+2ezqunSMnCcytWX1cq
DuHzu/iYjKBI/9h5p6LBhkn6Wrbfuy+5ABV332t4ul8iamgDlYhGg7tbiLq3EN003Q0LHw1v
WdOwcwvRLQsf9m4h6t9CdIsKhsNbiMbXica9GziNb9ngce8GPY37N6xpdN+sJ8jbpcGHI13M
U5l0uoO7oh6oojrVY4E4prSBZz5nbVCO6F5dbu8qxXWRB1cphlcp7q9SjK9SdK4L07kuTadZ
nLlLR6Hfjg4a9ioQk1HehptnP5F9Xq1/Vp4cZe3CuXwHw3Rpge9yXvv9KbazXzK+e5dfe66z
H7cWLzSV/mhWStfvZw+v+1PylPW86m87s2fdypzpdziDqFwDOgFTnvBdgLbV18AGtcF8hjo1
QgB2B0MdeNApPYa7IB5m1Gee6+p1mJJYhNf4mcx9mFA+qyHEg6uFy4cK8mdUVTjSMJfPVQda
6FAjgSCoee3Ix33NmPkMfdP+NvRN5Pz5T3WkTfEMESb/bqgKs8XKX2m1UgjC6+04Fn8/rA6v
xiE5n+JdVLIqHGJMRUmD8pdgyhIZNevz5t0SQIbUqbxqSqGFsP8HueuUuM0+AAA=
--------------070400090104030606090106--

From geoman@gentoo.org Thu Sep 23 16:00:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Sep 2004 16:00:31 +0100 (BST)
Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:53266 "EHLO
	lennier.cc.vt.edu") by linux-mips.org with ESMTP
	id <S8224931AbUIWPA1>; Thu, 23 Sep 2004 16:00:27 +0100
Received: from dagger.cc.vt.edu (IDENT:mirapoint@evil-dagger [10.1.1.11])
	by lennier.cc.vt.edu (8.12.8/8.12.8) with ESMTP id i8NF0Pol261709;
	Thu, 23 Sep 2004 11:00:25 -0400 (EDT)
Received: from [128.173.184.75] (gs75.geol.vt.edu [128.173.184.75])
	by dagger.cc.vt.edu (MOS 3.4.8-GR)
	with ESMTP id BQW64953;
	Thu, 23 Sep 2004 11:00:21 -0400 (EDT)
Message-ID: <4152E4FC.8000408@gentoo.org>
Date: Thu, 23 Sep 2004 11:00:12 -0400
From: "Stephen P. Becker" <geoman@gentoo.org>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040916)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stuart Longland <stuartl@longlandclan.hopto.org>
CC: linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
References: <4152D58B.608@longlandclan.hopto.org>
In-Reply-To: <4152D58B.608@longlandclan.hopto.org>
X-Enigmail-Version: 0.86.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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: 5870
X-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

> 	Using a MIPS64 config (built using gas-abi=o32 as suggested by Kumba),
> it doesn't even get that far:

This is certainly wrong.  What you really want is gas-abi=o64.  Take a 
look at the O2 minimum patchset at http://www.total-knowledge.com, as 
the arch/mips/Makefile changes are what you need.  Using a 64-bit kernel 
on your indy is pointless unless you want to run n32 userland anyhow.

As of this moment (may change in the future), 2.4 kernels are much 
better for ip22 anyhow.  Serial console, indycam, and sound all work 
properly in 2.4.  In 2.6, serial console is broken, there is no indycam 
support, and I'm running into some issues with sound where the cpu usage 
runs way up.

Steve



From savl@dev.rtsoft.ru Thu Sep 23 16:24:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Sep 2004 16:24:53 +0100 (BST)
Received: from RT-soft-2.Moscow.itn.ru ([IPv6:::ffff:80.240.96.70]:64697 "HELO
	mail.dev.rtsoft.ru") by linux-mips.org with SMTP
	id <S8224931AbUIWPYt>; Thu, 23 Sep 2004 16:24:49 +0100
Received: (qmail 6355 invoked from network); 23 Sep 2004 15:08:50 -0000
Received: from unknown (HELO dev.rtsoft.ru) (192.168.1.199)
  by mail.dev.rtsoft.ru with SMTP; 23 Sep 2004 15:08:50 -0000
Message-ID: <4152EABF.1020007@dev.rtsoft.ru>
Date: Thu, 23 Sep 2004 19:24:47 +0400
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: __stq_u parameter
Content-Type: multipart/mixed;
 boundary="------------070607060309060102000009"
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: 5871
X-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

This is a multi-part message in MIME format.
--------------070607060309060102000009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sorry,
 does this make sense for 2.4.x kernels?
----
Regards,
Pavel Kiryukhin

--------------070607060309060102000009
Content-Type: text/plain;
 name="unaligned.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="unaligned.diff"

--- linux/include/asm-mips/unaligned.h_org	2004-09-23 15:54:37.000000000 +0400
+++ linux/include/asm-mips/unaligned.h	2004-09-23 18:32:48.000000000 +0400
@@ -61,7 +61,7 @@
 /*
  * Store doubleword ununaligned.
  */
-static inline void __stq_u(unsigned long __val, unsigned long long * __addr)
+static inline void __stq_u(unsigned long long __val, unsigned long long * __addr)
 {
 	__asm__("usw\t%1, %0\n\t"
 		"usw\t%D1, 4+%0"

--------------070607060309060102000009--


From flo@rfc822.org Thu Sep 23 16:49:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Sep 2004 16:49:30 +0100 (BST)
Received: from hydra.gt.owl.de ([IPv6:::ffff:195.71.99.218]:12494 "EHLO
	hydra.gt.owl.de") by linux-mips.org with ESMTP id <S8224931AbUIWPt0>;
	Thu, 23 Sep 2004 16:49:26 +0100
Received: by hydra.gt.owl.de (Postfix, from userid 104)
	id 91ED21994E0; Thu, 23 Sep 2004 17:49:24 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 8C522138065; Thu, 23 Sep 2004 17:48:55 +0200 (CEST)
Date: Thu, 23 Sep 2004 17:48:55 +0200
From: Florian Lohoff <flo@rfc822.org>
To: Stuart Longland <stuartl@longlandclan.hopto.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
Message-ID: <20040923154855.GA2550@paradigm.rfc822.org>
References: <4152D58B.608@longlandclan.hopto.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="Sr1nOIr3CvdE5hEN"
Content-Disposition: inline
In-Reply-To: <4152D58B.608@longlandclan.hopto.org>
Organization: rfc822 - pure communication
User-Agent: Mutt/1.5.4i
Return-Path: <flo@rfc822.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5872
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips


--Sr1nOIr3CvdE5hEN
Content-Type: multipart/mixed; boundary="aM3YZ0Iwxop3KEKx"
Content-Disposition: inline


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

On Thu, Sep 23, 2004 at 11:54:19PM +1000, Stuart Longland wrote:
> 	Using a MIPS64 config (built using gas-abi=3Do32 as suggested by Kumba),
> it doesn't even get that far:

There is still a lot left broken - The attached patch fixes some obvious
stuff with address space and mibs abi.

Missing is a fix for ip22zilog.c which seems to be broken.=20

With this fix the machines goes userspace (reverse engineered by sound
of hard disk) but seems to die somewhere. Probably the same bug as seen
on other archs - die on first fork.

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

--aM3YZ0Iwxop3KEKx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="cvs-20040923-ip22-64-2.6.diff"
Content-Transfer-Encoding: quoted-printable

Index: arch/mips/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/flo/linux-mips-cvs/linux/arch/mips/Makefile,v
retrieving revision 1.176
diff -u -r1.176 Makefile
--- arch/mips/Makefile	19 Sep 2004 00:15:05 -0000	1.176
+++ arch/mips/Makefile	22 Sep 2004 23:54:24 -0000
@@ -35,7 +35,7 @@
 endif
 ifdef CONFIG_MIPS64
 gcc-abi			=3D 64
-gas-abi			=3D 32
+gas-abi			=3D o64
 tool-prefix		=3D $(64bit-tool-prefix)
 UTS_MACHINE		:=3D mips64
 endif
@@ -107,7 +107,7 @@
 	break; \
 done; \
 if test "$(gcc-abi)" !=3D "$(gas-abi)"; then \
-	gas_abi=3D"-Wa,-$(gas-abi) -Wa,-mgp$(gcc-abi)"; \
+	gas_abi=3D"-Wa,-mabi=3D$(gas-abi) -Wa,-mgp$(gcc-abi)"; \
 fi; \
 if test "$$gcc_opt" =3D -march=3D && test -n "$$gcc_abi"; then \
 	$(CC) $$gcc_abi $$gcc_opt$$gcc_cpu -S -o /dev/null \
Index: arch/mips/lib-64/dump_tlb.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/flo/linux-mips-cvs/linux/arch/mips/lib-64/dump_tlb.c,v
retrieving revision 1.2
diff -u -r1.2 dump_tlb.c
--- arch/mips/lib-64/dump_tlb.c	11 Feb 2004 15:05:44 -0000	1.2
+++ arch/mips/lib-64/dump_tlb.c	23 Sep 2004 01:19:10 -0000
@@ -190,7 +190,7 @@
 	pgd =3D pgd_offset(current->mm, addr);
 	pmd =3D pmd_offset(pgd, addr);
 	pte =3D pte_offset(pmd, addr);
-	paddr =3D (KSEG1 | (unsigned int) pte_val(*pte)) & PAGE_MASK;
+	paddr =3D (CKSEG1 | (unsigned int) pte_val(*pte)) & PAGE_MASK;
 	paddr |=3D (addr & ~PAGE_MASK);
=20
 	return paddr;
Index: arch/mips/mm/c-r4k.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/flo/linux-mips-cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.89
diff -u -r1.89 c-r4k.c
--- arch/mips/mm/c-r4k.c	24 Aug 2004 16:02:25 -0000	1.89
+++ arch/mips/mm/c-r4k.c	23 Sep 2004 01:11:27 -0000
@@ -49,7 +49,7 @@
 #define R4600_HIT_CACHEOP_WAR_IMPL					\
 do {									\
 	if (R4600_V2_HIT_CACHEOP_WAR && cpu_is_r4600_v2_x())		\
-		*(volatile unsigned long *)KSEG1;			\
+		*(volatile unsigned long *)CKSEG1;			\
 	if (R4600_V1_HIT_CACHEOP_WAR)					\
 		__asm__ __volatile__("nop;nop;nop;nop");		\
 } while (0)
@@ -983,7 +983,7 @@
 	case CPU_R4000MC:
 	case CPU_R4400SC:
 	case CPU_R4400MC:
-		probe_scache_kseg1 =3D (probe_func_t) (KSEG1ADDR(&probe_scache));
+		probe_scache_kseg1 =3D (probe_func_t) (CKSEG1ADDR(&probe_scache));
 		sc_present =3D probe_scache_kseg1(config);
 		if (sc_present)
 			c->options |=3D MIPS_CPU_CACHE_CDEX_S;
Index: arch/mips/sgi-ip22/ip22-setup.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/flo/linux-mips-cvs/linux/arch/mips/sgi-ip22/ip22-setup.c,v
retrieving revision 1.39
diff -u -r1.39 ip22-setup.c
--- arch/mips/sgi-ip22/ip22-setup.c	20 Aug 2004 10:03:22 -0000	1.39
+++ arch/mips/sgi-ip22/ip22-setup.c	23 Sep 2004 00:56:44 -0000
@@ -76,7 +76,7 @@
 #endif
=20
 	/* Set EISA IO port base for Indigo2 */
-	set_io_port_base(KSEG1ADDR(0x00080000));
+	set_io_port_base(CKSEG1ADDR(0x00080000));
=20
 	/* ARCS console environment variable is set to "g?" for
 	 * graphics console, it is set to "d" for the first serial
Index: drivers/net/sgiseeq.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/flo/linux-mips-cvs/linux/drivers/net/sgiseeq.c,v
retrieving revision 1.61
diff -u -r1.61 sgiseeq.c
--- drivers/net/sgiseeq.c	31 Jul 2004 01:47:50 -0000	1.61
+++ drivers/net/sgiseeq.c	23 Sep 2004 01:02:06 -0000
@@ -169,7 +169,7 @@
 			buffer =3D (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL);
 			if (!buffer)
 				return -ENOMEM;
-			sp->tx_desc[i].buf_vaddr =3D KSEG1ADDR(buffer);
+			sp->tx_desc[i].buf_vaddr =3D CKSEG1ADDR(buffer);
 			sp->tx_desc[i].tdma.pbuf =3D CPHYSADDR(buffer);
 		}
 		sp->tx_desc[i].tdma.cntinfo =3D TCNTINFO_INIT;
@@ -183,7 +183,7 @@
 			buffer =3D (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL);
 			if (!buffer)
 				return -ENOMEM;
-			sp->rx_desc[i].buf_vaddr =3D KSEG1ADDR(buffer);
+			sp->rx_desc[i].buf_vaddr =3D CKSEG1ADDR(buffer);
 			sp->rx_desc[i].rdma.pbuf =3D CPHYSADDR(buffer);
 		}
 		sp->rx_desc[i].rdma.cntinfo =3D RCNTINFO_INIT;
@@ -374,7 +374,7 @@
 	 */
 	while ((td->tdma.cntinfo & (HPCDMA_XIU | HPCDMA_ETXD)) =3D=3D
 	      (HPCDMA_XIU | HPCDMA_ETXD))
-		td =3D (struct sgiseeq_tx_desc *)(long) KSEG1ADDR(td->tdma.pnext);
+		td =3D (struct sgiseeq_tx_desc *)(long) CKSEG1ADDR(td->tdma.pnext);
 	if (td->tdma.cntinfo & HPCDMA_XIU) {
 		hregs->tx_ndptr =3D CPHYSADDR(td);
 		hregs->tx_ctrl =3D HPC3_ETXCTRL_ACTIVE;
@@ -671,11 +671,11 @@
 	sp->mode =3D SEEQ_RCMD_RBCAST;
=20
 	sp->rx_desc =3D (struct sgiseeq_rx_desc *)
-	              KSEG1ADDR(ALIGNED(&sp->srings->rxvector[0]));
+	              CKSEG1ADDR(ALIGNED(&sp->srings->rxvector[0]));
 	dma_cache_wback_inv((unsigned long)&sp->srings->rxvector,
 	                    sizeof(sp->srings->rxvector));
 	sp->tx_desc =3D (struct sgiseeq_tx_desc *)
-	              KSEG1ADDR(ALIGNED(&sp->srings->txvector[0]));
+	              CKSEG1ADDR(ALIGNED(&sp->srings->txvector[0]));
 	dma_cache_wback_inv((unsigned long)&sp->srings->txvector,
 	                    sizeof(sp->srings->txvector));
=20
Index: drivers/video/console/newport_con.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/flo/linux-mips-cvs/linux/drivers/video/console/newport_con.=
c,v
retrieving revision 1.9
diff -u -r1.9 newport_con.c
--- drivers/video/console/newport_con.c	6 Aug 2004 00:33:29 -0000	1.9
+++ drivers/video/console/newport_con.c	23 Sep 2004 01:21:54 -0000
@@ -290,7 +290,7 @@
=20
 	if (!sgi_gfxaddr)
 		return NULL;
-	npregs =3D (struct newport_regs *) (KSEG1 + sgi_gfxaddr);
+	npregs =3D (struct newport_regs *) (CKSEG1ADDR(sgi_gfxaddr));
 	npregs->cset.config =3D NPORT_CFG_GD0;
=20
 	if (newport_wait()) {
Index: include/asm-mips/addrspace.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/flo/linux-mips-cvs/linux/include/asm-mips/addrspace.h,v
retrieving revision 1.13
diff -u -r1.13 addrspace.h
--- include/asm-mips/addrspace.h	30 Nov 2003 01:52:25 -0000	1.13
+++ include/asm-mips/addrspace.h	23 Sep 2004 01:08:48 -0000
@@ -38,16 +38,6 @@
 #endif
=20
 /*
- * Memory segments (32bit kernel mode addresses)
- * These are the traditional names used in the 32-bit universe.
- */
-#define KUSEG			0x00000000
-#define KSEG0			0x80000000
-#define KSEG1			0xa0000000
-#define KSEG2			0xc0000000
-#define KSEG3			0xe0000000
-
-/*
  * Returns the kernel segment base of a given address
  */
 #define KSEGX(a)		((_ACAST32_ (a)) & 0xe0000000)
@@ -58,18 +48,7 @@
 #define CPHYSADDR(a)		((_ACAST32_ (a)) & 0x1fffffff)
 #define XPHYSADDR(a)            ((_ACAST64_ (a)) & 0x000000ffffffffff)
=20
-/*
- * Map an address to a certain kernel segment
- */
-#define KSEG0ADDR(a)		(CPHYSADDR(a) | KSEG0)
-#define KSEG1ADDR(a)		(CPHYSADDR(a) | KSEG1)
-#define KSEG2ADDR(a)		(CPHYSADDR(a) | KSEG2)
-#define KSEG3ADDR(a)		(CPHYSADDR(a) | KSEG3)
-
-#define CKSEG0ADDR(a)		(CPHYSADDR(a) | CKSEG0)
-#define CKSEG1ADDR(a)		(CPHYSADDR(a) | CKSEG1)
-#define CKSEG2ADDR(a)		(CPHYSADDR(a) | CKSEG2)
-#define CKSEG3ADDR(a)		(CPHYSADDR(a) | CKSEG3)
+#ifdef CONFIG_MIPS64
=20
 /*
  * Memory segments (64bit kernel mode addresses)
@@ -85,6 +64,44 @@
 #define CKSSEG			0xffffffffc0000000
 #define CKSEG3			0xffffffffe0000000
=20
+#define CKSEG0ADDR(a)		(CPHYSADDR(a) | CKSEG0)
+#define CKSEG1ADDR(a)		(CPHYSADDR(a) | CKSEG1)
+#define CKSEG2ADDR(a)		(CPHYSADDR(a) | CKSEG2)
+#define CKSEG3ADDR(a)		(CPHYSADDR(a) | CKSEG3)
+
+#else
+
+#define CKSEG0ADDR(a)		(CPHYSADDR(a) | KSEG0)
+#define CKSEG1ADDR(a)		(CPHYSADDR(a) | KSEG1)
+#define CKSEG2ADDR(a)		(CPHYSADDR(a) | KSEG2)
+#define CKSEG3ADDR(a)		(CPHYSADDR(a) | KSEG3)
+
+/*
+ * Map an address to a certain kernel segment
+ */
+#define KSEG0ADDR(a)		(CPHYSADDR(a) | KSEG0)
+#define KSEG1ADDR(a)		(CPHYSADDR(a) | KSEG1)
+#define KSEG2ADDR(a)		(CPHYSADDR(a) | KSEG2)
+#define KSEG3ADDR(a)		(CPHYSADDR(a) | KSEG3)
+
+/*
+ * Memory segments (32bit kernel mode addresses)
+ * These are the traditional names used in the 32-bit universe.
+ */
+#define KUSEG			0x00000000
+#define KSEG0			0x80000000
+#define KSEG1			0xa0000000
+#define KSEG2			0xc0000000
+#define KSEG3			0xe0000000
+
+#define CKUSEG			0x00000000
+#define CKSEG0			0x80000000
+#define CKSEG1			0xa0000000
+#define CKSEG2			0xc0000000
+#define CKSEG3			0xe0000000
+
+#endif
+
 /*
  * Cache modes for XKPHYS address conversion macros
  */
Index: include/asm-mips/r4kcache.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/flo/linux-mips-cvs/linux/include/asm-mips/r4kcache.h,v
retrieving revision 1.22
diff -u -r1.22 r4kcache.h
--- include/asm-mips/r4kcache.h	5 Jan 2004 01:56:01 -0000	1.22
+++ include/asm-mips/r4kcache.h	23 Sep 2004 01:09:47 -0000
@@ -26,7 +26,7 @@
  *  - We need a properly sign extended address for 64-bit code.  To get aw=
ay
  *    without ifdefs we let the compiler do it by a type cast.
  */
-#define INDEX_BASE	((int) KSEG0)
+#define INDEX_BASE	CKSEG0
=20
 #define cache_op(op,addr)						\
 	__asm__ __volatile__(						\
--- include/asm-mips/mach-ip22/spaces.h	2004-09-21 12:59:52.000000000 +0200
+++ include/asm-mips/mach-ip22/spaces.h	2004-09-23 01:52:01.000000000 +0200
@@ -0,0 +1,55 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Pub=
lic
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1994 - 1999, 2000, 03, 04 Ralf Baechle
+ * Copyright (C) 2000, 2002  Maciej W. Rozycki
+ * Copyright (C) 1990, 1999, 2000 Silicon Graphics, Inc.
+ */
+#ifndef _ASM_MACH_SPACES_H
+#define _ASM_MACH_SPACES_H
+
+#include <linux/config.h>
+
+#ifdef CONFIG_MIPS32
+
+#define CAC_BASE		0x80000000
+#define IO_BASE			0xa0000000
+#define UNCAC_BASE		0xa0000000
+#define MAP_BASE		0xc0000000
+
+/*
+ * This handles the memory map.
+ * We handle pages at KSEG0 for kernels with 32 bit address space.
+ */
+#define PAGE_OFFSET		0x80000000UL
+
+/*
+ * Memory above this physical address will be considered highmem.
+ */
+#ifndef HIGHMEM_START
+#define HIGHMEM_START		0x20000000UL
+#endif
+
+#endif /* CONFIG_MIPS32 */
+
+#ifdef CONFIG_MIPS64
+#define PAGE_OFFSET	0xffffffff80000000UL
+
+#ifndef HIGHMEM_START
+#define HIGHMEM_START		(1UL << 59UL)
+#endif
+
+#define CAC_BASE		0xffffffff80000000
+#define IO_BASE			0xffffffffa0000000
+#define UNCAC_BASE		0xffffffffa0000000
+#define MAP_BASE		0xffffffffc0000000
+
+#define TO_PHYS(x)		(             ((x) & TO_PHYS_MASK))
+#define TO_CAC(x)		(CAC_BASE   | ((x) & TO_PHYS_MASK))
+#define TO_UNCAC(x)		(UNCAC_BASE | ((x) & TO_PHYS_MASK))
+
+#endif /* CONFIG_MIPS64 */
+
+#endif /* __ASM_MACH_GENERIC_SPACES_H */

--aM3YZ0Iwxop3KEKx--

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

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

iD8DBQFBUvBnUaz2rXW+gJcRAsbqAKCdSVO7+Xhu+YJAPtWDwRfpZG/xDQCgy1yA
aPA7HpAa1LEGmfWMrHPgh34=
=GkfN
-----END PGP SIGNATURE-----

--Sr1nOIr3CvdE5hEN--

From brodo@dominikbrodowski.de Thu Sep 23 20:49:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Sep 2004 20:50:03 +0100 (BST)
Received: from natnoddy.rzone.de ([IPv6:::ffff:81.169.145.166]:5312 "EHLO
	natnoddy.rzone.de") by linux-mips.org with ESMTP
	id <S8225235AbUIWTt7>; Thu, 23 Sep 2004 20:49:59 +0100
Received: from mondschein.dominikbrodowski.de (pD9F8CB6E.dip.t-dialin.net [217.248.203.110])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i8NJnuNK022200;
	Thu, 23 Sep 2004 21:49:56 +0200 (MEST)
Received: by mondschein.dominikbrodowski.de (Postfix, from userid 1111)
	id B90BA30E0A; Thu, 23 Sep 2004 21:48:29 +0200 (CEST)
Date: Thu, 23 Sep 2004 21:48:29 +0200
From: Dominik Brodowski <linux@dominikbrodowski.de>
To: ralf@linux-mips.org, linux-mips@linux-mips.org
Cc: cpufreq@www.linux.org.uk
Subject: CPU frequency scaling on MIPS (au1000/common/power.c)
Message-ID: <20040923194829.GA32270@dominikbrodowski.de>
Mail-Followup-To: ralf@linux-mips.org, linux-mips@linux-mips.org,
	cpufreq@www.linux.org.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
Return-Path: <brodo@dominikbrodowski.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: 5873
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: linux@dominikbrodowski.de
Precedence: bulk
X-list: linux-mips

Hi,

While grepping for CPU_FREQ in the kernel sources I found some CPU frequency
scaling code in
arch/mips/au1000/common/power.c

As a common cross-architecture CPU frequency scaling infrastructure exists
in 2.6. kernels, and it offers a few interesting tidbits:

- support for dynamic frequency scaling if the hardware allows for it (low
	latencies caused by switching, and many switchings in a second are
	possible)
- handling of loops_per_jiffy updates, i.e. no need to do a lengthy
	calibrate_delay() 
- unified user interface, i.e. developers/users switching from ARM to MIPS
	will find the CPU frequency interface at the same place in sysfs
- informs "notifiers" of frequency switches. While the baud rate update
	in au1000/common/power.c seems to be a good candidate for such a
	notifier, it might be necessary to update the baud rate so fast
	that it needs to be done inside the are locked by pm_lock, and
	without a few function calls' overhead in between. Or isn't this
	a problem?

Therefore, I'd suggest that we update arch/mips/au1000/common/power.c to
use the cpufreq infrastructure. It is located at drivers/cpufreq/, besides
cpufreq.c one or more governors (currently [2.6.9-rc2] four exist,
powersave, performance, userspace and ondemand) are needed. Keeping the
old ctl_table interface around as a wrapper for the cpufreq interfaces looks
to be possible[*]; I'd like to #ifdef CONFIG_... and deprecate it, though.

As I don't have MIPS hardware [well, I do, inside a WRT54G router, but
that's besides the point], don't have and don't want to have a
cross-compiling infrastructure here, I can neither compile-test nor
real-life-test any patches I submit. Nonetheless I'd be willing to write
a "suggestion" on how to update arch/mips/au1000/common/power.c, and
somebody with compiler and hardware could test it then.

Are there other MIPS CPUs which support CPU frequency scaling? If so, it'd
be great if the maintainers for these specific platforms are aware of the
CPUfreq infrastructure, evaluate whether it's good enough for their needs,
and possibly add cpufreq drivers for these CPUs. 

For any questions, comments or patches regarding the cpufreq core or cpufreq 
drivers, there's a mailing list at cpufreq AT www DOT linux DOT org DOT uk, 
which is also CC'ed on this message. Maintainer of cpufreq is Dave Jones.

Thanks for listening,
	Dominik

[*] we already keep a few such old interfaces around, but they'll be removed
soon after 2005 begins. They'll not become available on MIPS in the
meantime, of course.

From ppopov@embeddedalley.com Thu Sep 23 21:19:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Sep 2004 21:19:28 +0100 (BST)
Received: from web81408.mail.yahoo.com ([IPv6:::ffff:206.190.37.97]:36030 "HELO
	web81408.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225239AbUIWUTX>; Thu, 23 Sep 2004 21:19:23 +0100
Message-ID: <20040923201916.38891.qmail@web81408.mail.yahoo.com>
Received: from [216.98.102.225] by web81408.mail.yahoo.com via HTTP; Thu, 23 Sep 2004 13:19:16 PDT
X-RocketYMMF: pete_popov
Date: Thu, 23 Sep 2004 13:19:16 -0700 (PDT)
From: Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
Subject: Re: CPU frequency scaling on MIPS (au1000/common/power.c)
To: Dominik Brodowski <linux@dominikbrodowski.de>, ralf@linux-mips.org,
	linux-mips@linux-mips.org
Cc: cpufreq@www.linux.org.uk
In-Reply-To: <20040923194829.GA32270@dominikbrodowski.de>
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: 5874
X-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


<snip>

> Therefore, I'd suggest that we update
> arch/mips/au1000/common/power.c to
> use the cpufreq infrastructure. 


The current interface was written a few years ago for
2.4, when I couldn't find a general PM interface to
start with.


> Nonetheless I'd be willing to write
> a "suggestion" on how to update
> arch/mips/au1000/common/power.c, and
> somebody with compiler and hardware could test it
> then.

That would help, though I'm not sure when I would get
to it personally. I'm working on 2.6 updates at the
moment with some other developers, but PM is not on
our list for now. If you're dying to work on it and
hardware is the only issue, I might be able to help :)

> Are there other MIPS CPUs which support CPU
> frequency scaling? 

Not that I know of, and not the way the Au1x supports
it.


Pete

From ralf@linux-mips.org Thu Sep 23 21:59:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Sep 2004 21:59:56 +0100 (BST)
Received: from p508B60DA.dip.t-dialin.net ([IPv6:::ffff:80.139.96.218]:12581
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225241AbUIWU7w>; Thu, 23 Sep 2004 21:59:52 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i8NKxlaU000556;
	Thu, 23 Sep 2004 22:59:47 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i8NKxknN000555;
	Thu, 23 Sep 2004 22:59:46 +0200
Date: Thu, 23 Sep 2004 22:59:46 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Pavel Kiryukhin <savl@dev.rtsoft.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: __stq_u parameter
Message-ID: <20040923205946.GA375@linux-mips.org>
References: <4152EABF.1020007@dev.rtsoft.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4152EABF.1020007@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: 5875
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Sep 23, 2004 at 07:24:47PM +0400, Pavel Kiryukhin wrote:

> Sorry,
> does this make sense for 2.4.x kernels?

Once uppon a time it made ...

The file has been rewritten completly since then.

Thanks anyway,

  Ralf

From stuartl@longlandclan.hopto.org Fri Sep 24 01:16:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 01:16:52 +0100 (BST)
Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:54318
	"EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP
	id <S8225243AbUIXAQr>; Fri, 24 Sep 2004 01:16:47 +0100
Received: (qmail 7112 invoked from network); 24 Sep 2004 10:16:38 +1000
Received: from unknown (HELO ?10.0.0.251?) (10.0.0.251)
  by 192.168.5.1 with SMTP; 24 Sep 2004 10:16:38 +1000
Message-ID: <41536765.9000304@longlandclan.hopto.org>
Date: Fri, 24 Sep 2004 10:16:37 +1000
From: Stuart Longland <stuartl@longlandclan.hopto.org>
User-Agent: Mozilla Thunderbird 0.7 (X11/20040615)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Stephen P. Becker" <geoman@gentoo.org>
CC: linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
References: <4152D58B.608@longlandclan.hopto.org> <4152E4FC.8000408@gentoo.org>
In-Reply-To: <4152E4FC.8000408@gentoo.org>
X-Enigmail-Version: 0.84.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <stuartl@longlandclan.hopto.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: 5876
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: stuartl@longlandclan.hopto.org
Precedence: bulk
X-list: linux-mips

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

Stephen P. Becker wrote:
>>     Using a MIPS64 config (built using gas-abi=o32 as suggested by
>> Kumba),
>> it doesn't even get that far:
>
> This is certainly wrong.  What you really want is gas-abi=o64.  Take a
> look at the O2 minimum patchset at http://www.total-knowledge.com, as
> the arch/mips/Makefile changes are what you need.  Using a 64-bit kernel
> on your indy is pointless unless you want to run n32 userland anyhow.

Ahh yes... sorry, it was after midnight (GMT+10) and my mind must've
been elsewhere -- I meant o64.  I was planning on moving to either n32
or n64 userland eventually, but I won't do that unless I can get a
64-bit kernel going.

> As of this moment (may change in the future), 2.4 kernels are much
> better for ip22 anyhow.  Serial console, indycam, and sound all work
> properly in 2.4.  In 2.6, serial console is broken, there is no indycam
> support, and I'm running into some issues with sound where the cpu usage
> runs way up.

Right.  Luckily I've got a framebuffer that Linux can talk to and I
haven't got an indycam.  But the sound issue may be a problem, I was
thinking at one point to use this box as a jukebox, but at the moment
I'm experimenting with mips64 to see what it can do.

I'll have a look at those patches & the O2 documentation, that should
give me some leads into sorting out the issue.  It would be nice to see
if I can squeeze better performance out of the aging beast.
- --
+-------------------------------------------------------------+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project     -oOo-    http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFBU2dluarJ1mMmSrkRAvLAAJiGRTLJlg3stJyjA3bRYmM2a/aLAJ0TmcsJ
mpAfZVjU/2YHo1OoZp8D7Q==
=mUN8
-----END PGP SIGNATURE-----

From anemo@mba.ocn.ne.jp Fri Sep 24 04:19:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 04:20:12 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:46101
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224859AbUIXDT6>; Fri, 24 Sep 2004 04:19:58 +0100
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 Sep 2004 03:19:57 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 BDAA0239E1D; Fri, 24 Sep 2004 12:22:29 +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 i8O3Jm8G072798;
	Fri, 24 Sep 2004 12:19:48 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 24 Sep 2004 12:18:48 +0900 (JST)
Message-Id: <20040924.121848.39150090.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org
Cc: rsandifo@redhat.com, linux-mips@linux-mips.org
Subject: Re: gcc 3.3.4/3.4.1 and get_user
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20040920154042.GB5150@linux-mips.org>
References: <20040901.012223.59462025.anemo@mba.ocn.ne.jp>
	<87656yqsmz.fsf@redhat.com>
	<20040920154042.GB5150@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.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5877
X-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 Mon, 20 Sep 2004 17:40:42 +0200, Ralf Baechle <ralf@linux-mips.org> said:
ralf> The purpose of this was to avoid a warning about __gu_val
ralf> possibly being used uninitialized without inflating the code.
ralf> I've got a better solution that'll actually shrinks the code
ralf> size of my defconfig build by 5448 bytes.  Untested patch below.

Thank you.  This patch (and following commit to CVS :-)) works fine.
Please change paccess.h also?

---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Fri Sep 24 08:40:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 08:40:38 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:9508
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224841AbUIXHkd>; Fri, 24 Sep 2004 08:40:33 +0100
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 Sep 2004 07:40:31 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 25763239E1D; Fri, 24 Sep 2004 16:43: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 i8O7eN8G073799;
	Fri, 24 Sep 2004 16:40:24 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 24 Sep 2004 16:39:23 +0900 (JST)
Message-Id: <20040924.163923.98854911.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: gcc 3.3.4/3.4.1 and get_user
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20040920171021.GA25371@linux-mips.org>
References: <87656yqsmz.fsf@redhat.com>
	<20040920154042.GB5150@linux-mips.org>
	<20040920171021.GA25371@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.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5878
X-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 Mon, 20 Sep 2004 19:10:21 +0200, Ralf Baechle <ralf@linux-mips.org> said:
ralf> And here the same for 2.4.  Actually this is a straight backport
ralf> of the 2.6 uaccess.h to 2.4 so with this patch
ralf> include/asm-mips/uaccess.h and include/asm-mips64/uaccess.h are
ralf> going to be identical.

This also fixes long standing bug in 2.4 mips64 __ua_size macro.  Thank you.

There is still an another problem in 64-bit __access_ok (both 2.4 and
2.6).

The __access_ok for 64-bit kernel returns 0 if 'addr' + 'size' ==
TASK_SIZE (which should be OK).

#define __access_ok(addr, size, mask)					\
	(((signed long)((mask) & ((addr) | ((addr) + (size)) | __ua_size(size)))) == 0)

I think this should be:

#define __access_ok(addr, size, mask)					\
	(((signed long)((mask) & ((addr) | ((addr) + (size) - 1) | __ua_size(size)))) == 0)

This fix is needed for 64-bit native mount syscall (which try to read
variable length string parameters from user stack.  See
fs/namespace.c:copy_mount_options).

This fix also makes __access_ok(0, 0, __access_mask) return 0, but
pointer 0 is invalid anyway.

---
Atsushi Nemoto

From bruno.randolf@4g-systems.biz Fri Sep 24 09:21:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 09:21:42 +0100 (BST)
Received: from grey.subnet.at ([IPv6:::ffff:193.170.141.20]:18448 "EHLO
	grey.subnet.at") by linux-mips.org with ESMTP id <S8224841AbUIXIVi>;
	Fri, 24 Sep 2004 09:21:38 +0100
Received: from ip6-localhost ([193.170.141.4]) by grey.subnet.at ; Fri, 24 Sep 2004 10:21:23 +0200
From: Bruno Randolf <bruno.randolf@4g-systems.biz>
To: Dominik Brodowski <linux@dominikbrodowski.de>
Subject: Re: CPU frequency scaling on MIPS (au1000/common/power.c)
Date: Fri, 24 Sep 2004 10:15:57 +0200
User-Agent: KMail/1.7
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org,
	cpufreq@www.linux.org.uk
References: <20040923194829.GA32270@dominikbrodowski.de>
In-Reply-To: <20040923194829.GA32270@dominikbrodowski.de>
Organization: 4G Systems
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart5505897.fSDApoSRUS";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200409241016.05381.bruno.randolf@4g-systems.biz>
Return-Path: <bruno.randolf@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5879
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.biz
Precedence: bulk
X-list: linux-mips

--nextPart5505897.fSDApoSRUS
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 23 September 2004 21:48, Dominik Brodowski wrote:

> As I don't have MIPS hardware [well, I do, inside a WRT54G router, but
> that's besides the point], don't have and don't want to have a
> cross-compiling infrastructure here, I can neither compile-test nor
> real-life-test any patches I submit. Nonetheless I'd be willing to write
> a "suggestion" on how to update arch/mips/au1000/common/power.c, and
> somebody with compiler and hardware could test it then.

i would be happy to cross-compile & test them on a meshcube (mtx-1), but i'=
m=20
afraid i cant help too much with coding.

bruno

--nextPart5505897.fSDApoSRUS
Content-Type: application/pgp-signature

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

iD8DBQBBU9fFfg2jtUL97G4RAsduAJ9NVhGINZaEdlt+JeB2xuI9i6y9ugCePfBN
kWxQkGJesskpU44MuZgqllk=
=WmWE
-----END PGP SIGNATURE-----

--nextPart5505897.fSDApoSRUS--

From thomas@the-doors.enix.org Fri Sep 24 09:52:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 09:52:50 +0100 (BST)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:55961 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8224841AbUIXIwq>; Fri, 24 Sep 2004 09:52:46 +0100
Received: by the-doors.enix.org (Postfix, from userid 1105)
	id 3D1291EFB0; Fri, 24 Sep 2004 10:52:40 +0200 (CEST)
Date: Fri, 24 Sep 2004 10:52:40 +0200
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
To: linux-mips@linux-mips.org
Cc: mentre@tcl.ite.mee.com
Subject: "Can't analyze prologue code ..." at boot time
Message-ID: <20040924085240.GP24730@enix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <thomas@the-doors.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: 5880
X-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

Hello,

In arch/mips/kernel/process.c, the function frame_info_init() called
at boot time, calls the get_frame_info() to a analyze the prologue of
a few functions (I don't know why, does anyone know ?).

At boot time, I have the following message on the console :

Can't analyze prologue code at 80315308

At 80315308 is the beginning of the schedule_timeout() function which
is one of the functions analyzed by the frame_info_init().

The get_frame_info() seems to search a sw or sd instruction, but here
is the beginning of the schedule_timeout() function :

80315308 <schedule_timeout>:
80315308:       3c027fff        lui     v0,0x7fff
8031530c:       27bdffc0        addiu   sp,sp,-64
80315310:       3442ffff        ori     v0,v0,0xffff
80315314:       afb10034        sw      s1,52(sp)
80315318:       afbf003c        sw      ra,60(sp)
8031531c:       afb20038        sw      s2,56(sp)
80315320:       afb00030        sw      s0,48(sp)
80315324:       1082002c        beq     a0,v0,803153d8 <schedule_timeout+0xd0>
80315328:       00808821        move    s1,a0

This error isn't fatal, the kernel perfectly boots, and I can use my
shell perfectly. I just wanted to know why it is reporting a problem,
why the kernel needs to analyze the prologues of a couple of
functions, and maybe report a possible problem ?

I'm using a quite outdated linux-mips CVS (from the beginning of the
month, a 2.6.9-rc1). I compiled using gcc 3.3.4, for an RM9000
processor.

Don't hesitate to ask for details,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org 
http://thomas.enix.org - Jabber: kos_tom@sourcecode.de
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

From flo@rfc822.org Fri Sep 24 10:40:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 10:40:10 +0100 (BST)
Received: from hydra.gt.owl.de ([IPv6:::ffff:195.71.99.218]:47071 "EHLO
	hydra.gt.owl.de") by linux-mips.org with ESMTP id <S8224944AbUIXJkF>;
	Fri, 24 Sep 2004 10:40:05 +0100
Received: by hydra.gt.owl.de (Postfix, from userid 104)
	id 4DC811995B3; Fri, 24 Sep 2004 11:40:04 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 9237B138065; Fri, 24 Sep 2004 11:07:03 +0200 (CEST)
Date: Fri, 24 Sep 2004 11:07:03 +0200
From: Florian Lohoff <flo@rfc822.org>
To: Stuart Longland <stuartl@longlandclan.hopto.org>
Cc: "Stephen P. Becker" <geoman@gentoo.org>, linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
Message-ID: <20040924090703.GA13468@paradigm.rfc822.org>
References: <4152D58B.608@longlandclan.hopto.org> <4152E4FC.8000408@gentoo.org> <41536765.9000304@longlandclan.hopto.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp"
Content-Disposition: inline
In-Reply-To: <41536765.9000304@longlandclan.hopto.org>
Organization: rfc822 - pure communication
User-Agent: Mutt/1.5.4i
Return-Path: <flo@rfc822.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5881
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips


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

On Fri, Sep 24, 2004 at 10:16:37AM +1000, Stuart Longland wrote:
> Ahh yes... sorry, it was after midnight (GMT+10) and my mind must've
> been elsewhere -- I meant o64.  I was planning on moving to either n32
> or n64 userland eventually, but I won't do that unless I can get a
> 64-bit kernel going.

The 64 bit kernel should work so far - With the ip22zilog.c fixes
tsbogend just committed the console begins to work again.

Includeing the patch i sent earlier my R5k Indy boots fine a 64bit
current cvs head and goes into userspace.=20

Using the "soo to be" rtc and statfs64 fixes everything seems to be
fine for o32 userspace.

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

--17pEHd4RhPHOinZp
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBU+O3Uaz2rXW+gJcRArAvAJ0ZciX9Ai+hOXdwMJVDVNf3arqx2gCcCJIM
9c2PaWIa6LJUuz1P2pAXfF0=
=J+yq
-----END PGP SIGNATURE-----

--17pEHd4RhPHOinZp--

From anemo@mba.ocn.ne.jp Fri Sep 24 11:07:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 11:07:55 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:51488
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224944AbUIXKHt>; Fri, 24 Sep 2004 11:07:49 +0100
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 Sep 2004 10:07:47 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 23C8D239E1D; Fri, 24 Sep 2004 19:10:22 +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 i8OA7e8G074458;
	Fri, 24 Sep 2004 19:07:40 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 24 Sep 2004 19:06:40 +0900 (JST)
Message-Id: <20040924.190640.09669815.nemoto@toshiba-tops.co.jp>
To: thomas.petazzoni@enix.org
Cc: linux-mips@linux-mips.org, mentre@tcl.ite.mee.com
Subject: Re: "Can't analyze prologue code ..." at boot time
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20040924085240.GP24730@enix.org>
References: <20040924085240.GP24730@enix.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.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5882
X-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, 24 Sep 2004 10:52:40 +0200, Thomas Petazzoni <thomas.petazzoni@enix.org> said:
thomas> In arch/mips/kernel/process.c, the function frame_info_init()
thomas> called at boot time, calls the get_frame_info() to a analyze
thomas> the prologue of a few functions (I don't know why, does anyone
thomas> know ?).

Because thread_saved_pc(), get_wchan() needs those information.

The information of 'schedule' function is required, others are
optional ("ps -l" shows better output with those informations).

thomas> The get_frame_info() seems to search a sw or sd instruction,
thomas> but here is the beginning of the schedule_timeout() function :

This is because now schedule_timeout is in kernel/timer.c (not
kernel/sched.c) which is compiled without -fno-omit-frame-pointer
option.

I rewrote get_wchan() to handle this problem.  Please try this patch.

Note that this patch still depends on order of address of sched
functions, so not gcc-3.4 proof.  Sorting minfo[] array will make it
more robust.  If anyone interested in, I will implement it.

diff -u linux-mips/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c
--- linux-mips/arch/mips/kernel/process.c	Wed Sep 22 13:27:59 2004
+++ linux/arch/mips/kernel/process.c	Wed Sep 22 17:03:10 2004
@@ -177,21 +177,41 @@
 }
 
 struct mips_frame_info {
+	void *func;
+	int omit_fp;	/* compiled without fno-omit-frame-pointer */
 	int frame_offset;
 	int pc_offset;
+} mfinfo [] = {
+	/* must be in address order */
+	{ __down_interruptible, 1 },
+	{ schedule, 0 },
+#define schedule_frame 1
+#ifdef CONFIG_PREEMPT
+	{ preempt_schedule, 0 },
+#endif
+	{ wait_for_completion, 0 },
+	{ interruptible_sleep_on, 0 },
+	{ interruptible_sleep_on_timeout, 0 },
+	{ sleep_on, 0 },
+	{ sleep_on_timeout, 0 },
+	{ __cond_resched, 0 },
+	{ yield, 0 },
+	{ io_schedule, 0 },
+	{ io_schedule_timeout, 0 },
+	{ schedule_timeout, 1 },
+/*	{ nanosleep_restart, 1 }, */
+	{ __down_read, 1 },
+	{ __down_write, 1 },
 };
-static struct mips_frame_info schedule_frame;
-static struct mips_frame_info schedule_timeout_frame;
-static struct mips_frame_info sleep_on_frame;
-static struct mips_frame_info sleep_on_timeout_frame;
-static struct mips_frame_info wait_for_completion_frame;
+
 static int mips_frame_info_initialized;
-static int __init get_frame_info(struct mips_frame_info *info, void *func)
+static int __init get_frame_info(struct mips_frame_info *info)
 {
 	int i;
+	void *func = info->func;
 	union mips_instruction *ip = (union mips_instruction *)func;
 	info->pc_offset = -1;
-	info->frame_offset = -1;
+	info->frame_offset = info->omit_fp ? 0 : -1;
 	for (i = 0; i < 128; i++, ip++) {
 		/* if jal, jalr, jr, stop. */
 		if (ip->j_format.opcode == jal_op ||
@@ -237,13 +257,11 @@
 
 static int __init frame_info_init(void)
 {
-	mips_frame_info_initialized =
-		!get_frame_info(&schedule_frame, schedule) &&
-		!get_frame_info(&schedule_timeout_frame, schedule_timeout) &&
-		!get_frame_info(&sleep_on_frame, sleep_on) &&
-		!get_frame_info(&sleep_on_timeout_frame, sleep_on_timeout) &&
-		!get_frame_info(&wait_for_completion_frame, wait_for_completion);
-
+	int i;
+	for (i = 0; i < ARRAY_SIZE(mfinfo); i++)
+		if (get_frame_info(&mfinfo[i]))
+			return -1;
+	mips_frame_info_initialized = 1;
 	return 0;
 }
 
@@ -261,9 +279,9 @@
 	if (t->reg31 == (unsigned long) ret_from_fork)
 		return t->reg31;
 
-	if (schedule_frame.pc_offset < 0)
+	if (mfinfo[schedule_frame].pc_offset < 0)
 		return 0;
-	return ((unsigned long *)t->reg29)[schedule_frame.pc_offset];
+	return ((unsigned long *)t->reg29)[mfinfo[schedule_frame].pc_offset];
 }
 
 /* get_wchan - a maintenance nightmare^W^Wpain in the ass ...  */
@@ -277,48 +295,27 @@
 	if (!mips_frame_info_initialized)
 		return 0;
 	pc = thread_saved_pc(p);
+
 	if (!in_sched_functions(pc))
 		goto out;
 
-	if (pc >= (unsigned long) sleep_on_timeout)
-		goto schedule_timeout_caller;
-	if (pc >= (unsigned long) sleep_on)
-		goto schedule_caller;
-	if (pc >= (unsigned long) interruptible_sleep_on_timeout)
-		goto schedule_timeout_caller;
-	if (pc >= (unsigned long)interruptible_sleep_on)
-		goto schedule_caller;
-	if (pc >= (unsigned long)wait_for_completion)
-		goto schedule_caller;
-	goto schedule_timeout_caller;
-
-schedule_caller:
-	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
-	if (pc >= (unsigned long) sleep_on)
-		pc = ((unsigned long *)frame)[sleep_on_frame.pc_offset];
-	else
-		pc = ((unsigned long *)frame)[wait_for_completion_frame.pc_offset];
-	goto out;
-
-schedule_timeout_caller:
-	/*
-	 * The schedule_timeout frame
-	 */
-	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
-
-	/*
-	 * frame now points to sleep_on_timeout's frame
-	 */
-	pc    = ((unsigned long *)frame)[schedule_timeout_frame.pc_offset];
-
-	if (in_sched_functions(pc)) {
-		/* schedule_timeout called by [interruptible_]sleep_on_timeout */
-		frame = ((unsigned long *)frame)[schedule_timeout_frame.frame_offset];
-		pc    = ((unsigned long *)frame)[sleep_on_timeout_frame.pc_offset];
-	}
+	frame = ((unsigned long *)p->thread.reg30)[mfinfo[schedule_frame].frame_offset];
+	do {
+		int i;
+		for (i = ARRAY_SIZE(mfinfo) - 1; i >= 0; i--) {
+			if (pc >= (unsigned long) mfinfo[i].func)
+				break;
+		}
+		if (i < 0)
+			break;
 
-out:
+		if (mfinfo[i].omit_fp)
+			break;
+		pc = ((unsigned long *)frame)[mfinfo[i].pc_offset];
+		frame = ((unsigned long *)frame)[mfinfo[i].frame_offset];
+	} while (in_sched_functions(pc));
 
+out:
 #ifdef CONFIG_MIPS64
 	if (current->thread.mflags & MF_32BIT_REGS) /* Kludge for 32-bit ps  */
 		pc &= 0xffffffffUL;


---
Atsushi Nemoto

From thomas@the-doors.enix.org Fri Sep 24 13:11:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 13:11:19 +0100 (BST)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:44446 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8224944AbUIXMLN>; Fri, 24 Sep 2004 13:11:13 +0100
Received: by the-doors.enix.org (Postfix, from userid 1105)
	id 4D0B61F02E; Fri, 24 Sep 2004 14:11:07 +0200 (CEST)
Date: Fri, 24 Sep 2004 14:11:07 +0200
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org, mentre@tcl.ite.mee.com
Subject: Re: "Can't analyze prologue code ..." at boot time
Message-ID: <20040924121107.GB24730@enix.org>
References: <20040924085240.GP24730@enix.org> <20040924.190640.09669815.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040924.190640.09669815.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.5.4i
Return-Path: <thomas@the-doors.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: 5883
X-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

Hello,

On Fri, Sep 24, 2004 at 07:06:40PM +0900, Atsushi Nemoto wrote :

> I rewrote get_wchan() to handle this problem.  Please try this patch.

This patch works for me. At least, the "Couldn't analyze prologue code
at ..." message doesn't appear anymore.

Thanks,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org 
http://thomas.enix.org - Jabber: kos_tom@sourcecode.de
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

From geoman@gentoo.org Fri Sep 24 14:04:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 14:04:49 +0100 (BST)
Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:51977 "EHLO
	lennier.cc.vt.edu") by linux-mips.org with ESMTP
	id <S8225205AbUIXNEp>; Fri, 24 Sep 2004 14:04:45 +0100
Received: from vivi.cc.vt.edu (IDENT:mirapoint@evil-vivi [10.1.1.12])
	by lennier.cc.vt.edu (8.12.8/8.12.8) with ESMTP id i8OD4hol257027;
	Fri, 24 Sep 2004 09:04:43 -0400 (EDT)
Received: from [127.0.0.1] (68-232-97-125.chvlva.adelphia.net [68.232.97.125])
	by vivi.cc.vt.edu (MOS 3.4.8-GR)
	with ESMTP id BQP13914 (AUTH spbecker);
	Fri, 24 Sep 2004 09:04:42 -0400 (EDT)
Message-ID: <41541B8D.3060500@gentoo.org>
Date: Fri, 24 Sep 2004 09:05:17 -0400
From: "Stephen P. Becker" <geoman@gentoo.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stuart Longland <stuartl@longlandclan.hopto.org>
CC: linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
References: <4152D58B.608@longlandclan.hopto.org> <4152E4FC.8000408@gentoo.org> <41536765.9000304@longlandclan.hopto.org>
In-Reply-To: <41536765.9000304@longlandclan.hopto.org>
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: 5884
X-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

> Ahh yes... sorry, it was after midnight (GMT+10) and my mind must've
> been elsewhere -- I meant o64.  I was planning on moving to either n32
> or n64 userland eventually, but I won't do that unless I can get a
> 64-bit kernel going.
> 

Heh...I hope you are prepared for a significant slowdown if you end up 
trying to run n64 userland on such a machine.

Steve


From rjh@cita.utoronto.ca Fri Sep 24 14:18:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 14:18:41 +0100 (BST)
Received: from quail.cita.utoronto.ca ([IPv6:::ffff:128.100.76.6]:24290 "EHLO
	localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225205AbUIXNSh>; Fri, 24 Sep 2004 14:18:37 +0100
Received: from cita.utoronto.ca (lemming.cita.utoronto.ca [128.100.76.53])
	by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8ODHYhu002276
	for <linux-mips@linux-mips.org>; Fri, 24 Sep 2004 09:17:34 -0400
Received: from lemming.cita.utoronto.ca (localhost [127.0.0.1])
	by cita.utoronto.ca (8.12.11/8.12.8) with ESMTP id i8ODHY6U027674
	for <linux-mips@linux-mips.org>; Fri, 24 Sep 2004 09:17:34 -0400
Received: (from rjh@localhost)
	by lemming.cita.utoronto.ca (8.12.11/8.12.11/Submit) id i8ODHY0V027673
	for linux-mips@linux-mips.org; Fri, 24 Sep 2004 09:17:34 -0400
Date: Fri, 24 Sep 2004 09:17:34 -0400
From: Robin Humble <rjh@cita.utoronto.ca>
To: linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
Message-ID: <20040924131734.GC26710@lemming.cita.utoronto.ca>
References: <4152D58B.608@longlandclan.hopto.org> <4152E4FC.8000408@gentoo.org> <41536765.9000304@longlandclan.hopto.org> <41541B8D.3060500@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41541B8D.3060500@gentoo.org>
User-Agent: Mutt/1.4.1i
Return-Path: <rjh@cita.utoronto.ca>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5885
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rjh@cita.utoronto.ca
Precedence: bulk
X-list: linux-mips

On Fri, Sep 24, 2004 at 09:05:17AM -0400, Stephen P. Becker wrote:
>Heh...I hope you are prepared for a significant slowdown if you end up 
>trying to run n64 userland on such a machine.

why's that?

cheers,
robin

From geoman@gentoo.org Fri Sep 24 14:27:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 14:27:13 +0100 (BST)
Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:51976 "EHLO
	lennier.cc.vt.edu") by linux-mips.org with ESMTP
	id <S8225205AbUIXN1J>; Fri, 24 Sep 2004 14:27:09 +0100
Received: from steiner.cc.vt.edu (IDENT:mirapoint@evil-steiner [10.1.1.14])
	by lennier.cc.vt.edu (8.12.8/8.12.8) with ESMTP id i8ODR6ol269672;
	Fri, 24 Sep 2004 09:27:06 -0400 (EDT)
Received: from [127.0.0.1] (68-232-97-125.chvlva.adelphia.net [68.232.97.125])
	by steiner.cc.vt.edu (MOS 3.4.8-GR)
	with ESMTP id BPS19718 (AUTH spbecker);
	Fri, 24 Sep 2004 09:27:04 -0400 (EDT)
Message-ID: <415420D0.60102@gentoo.org>
Date: Fri, 24 Sep 2004 09:27:44 -0400
From: "Stephen P. Becker" <geoman@gentoo.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robin Humble <rjh@cita.utoronto.ca>
CC: linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
References: <4152D58B.608@longlandclan.hopto.org> <4152E4FC.8000408@gentoo.org> <41536765.9000304@longlandclan.hopto.org> <41541B8D.3060500@gentoo.org> <20040924131734.GC26710@lemming.cita.utoronto.ca>
In-Reply-To: <20040924131734.GC26710@lemming.cita.utoronto.ca>
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: 5886
X-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

Robin Humble wrote:
> On Fri, Sep 24, 2004 at 09:05:17AM -0400, Stephen P. Becker wrote:
> 
>>Heh...I hope you are prepared for a significant slowdown if you end up 
>>trying to run n64 userland on such a machine.
> 
> 
> why's that?
> 

Mostly, 64-bit binaries are much larger than 32-bit.  Consider that the 
scsi controller in an Indy gets about 2mb/sec throughput MAX (on a good 
day).  Also, Indys don't support a large enough memory configuration 
that 64-bit would be worth it anyhow.

What you would *really* want on such a machine would be n32 userland. 
You get full 64-bit instructions, but the binaries aren't huge.


Steve



From rjh@cita.utoronto.ca Fri Sep 24 14:44:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 14:44:41 +0100 (BST)
Received: from quail.cita.utoronto.ca ([IPv6:::ffff:128.100.76.6]:28134 "EHLO
	localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225216AbUIXNog>; Fri, 24 Sep 2004 14:44:36 +0100
Received: from cita.utoronto.ca (lemming.cita.utoronto.ca [128.100.76.53])
	by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8ODhYMb004377
	for <linux-mips@linux-mips.org>; Fri, 24 Sep 2004 09:43:34 -0400
Received: from lemming.cita.utoronto.ca (localhost [127.0.0.1])
	by cita.utoronto.ca (8.12.11/8.12.8) with ESMTP id i8ODhYHb029826
	for <linux-mips@linux-mips.org>; Fri, 24 Sep 2004 09:43:34 -0400
Received: (from rjh@localhost)
	by lemming.cita.utoronto.ca (8.12.11/8.12.11/Submit) id i8ODhYG3029825
	for linux-mips@linux-mips.org; Fri, 24 Sep 2004 09:43:34 -0400
Date: Fri, 24 Sep 2004 09:43:34 -0400
From: Robin Humble <rjh@cita.utoronto.ca>
To: linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
Message-ID: <20040924134334.GB27739@lemming.cita.utoronto.ca>
References: <4152D58B.608@longlandclan.hopto.org> <4152E4FC.8000408@gentoo.org> <41536765.9000304@longlandclan.hopto.org> <41541B8D.3060500@gentoo.org> <20040924131734.GC26710@lemming.cita.utoronto.ca> <415420D0.60102@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <415420D0.60102@gentoo.org>
User-Agent: Mutt/1.4.1i
Return-Path: <rjh@cita.utoronto.ca>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5887
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rjh@cita.utoronto.ca
Precedence: bulk
X-list: linux-mips

On Fri, Sep 24, 2004 at 09:27:44AM -0400, Stephen P. Becker wrote:
>Mostly, 64-bit binaries are much larger than 32-bit.  Consider that the 
>scsi controller in an Indy gets about 2mb/sec throughput MAX (on a good 

/usr/bin/e* on i386 vs x86_64 is 17432 vs 12440 kB => about 40% bigger.
so indeed that's a fair bit larger :-)

I didn't think it was quite as bad as 2MB/s though, maybe 4. I'll dig my
Indys out of storage and give them a whirl.

>day).  Also, Indys don't support a large enough memory configuration 
>that 64-bit would be worth it anyhow.

indeed they don't.
do you get access to more registers or more efficient instruction sets
like you do on x86_64?

>What you would *really* want on such a machine would be n32 userland. 
>You get full 64-bit instructions, but the binaries aren't huge.

fair enough.

cheers,
robin

From savl@dev.rtsoft.ru Fri Sep 24 15:19:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 15:20:01 +0100 (BST)
Received: from RT-soft-2.Moscow.itn.ru ([IPv6:::ffff:80.240.96.70]:61154 "HELO
	mail.dev.rtsoft.ru") by linux-mips.org with SMTP
	id <S8225205AbUIXOT5>; Fri, 24 Sep 2004 15:19:57 +0100
Received: (qmail 17087 invoked from network); 24 Sep 2004 14:03:45 -0000
Received: from unknown (HELO dev.rtsoft.ru) (192.168.1.199)
  by mail.dev.rtsoft.ru with SMTP; 24 Sep 2004 14:03:45 -0000
Message-ID: <41542D07.8070608@dev.rtsoft.ru>
Date: Fri, 24 Sep 2004 18:19:51 +0400
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: Ralf Baechle <ralf@linux-mips.org>,
	Pavel Kiryukhin <savl@dev.rtsoft.ru>
Subject: Re: __stq_u parameter (and related XFS filesystem 1.3 & 1.3.1 problems
 on 2.4.x)
References: <4152EABF.1020007@dev.rtsoft.ru> <20040923205946.GA375@linux-mips.org>
In-Reply-To: <20040923205946.GA375@linux-mips.org>
Content-Type: multipart/alternative;
 boundary="------------010103060104080103060509"
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: 5888
X-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

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

Just in case it may help somebody..
This patch  is necessary for normal 1.3 and 1.3.1 XFS filesystem  
operations on  mips targets (LE especially) with  old (2.4) kernels.
----
Pavel

Ralf Baechle wrote:

>On Thu, Sep 23, 2004 at 07:24:47PM +0400, Pavel Kiryukhin wrote:
>
>  
>
>>Sorry,
>>does this make sense for 2.4.x kernels?
>>    
>>
>
>Once uppon a time it made ...
>
>The file has been rewritten completly since then.
>
>Thanks anyway,
>
>  Ralf
>
>  
>


--------------010103060104080103060509
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">
Just in case it may help somebody..<br>
This patch&nbsp; is necessary for normal 1.3 and 1.3.1 XFS filesystem&nbsp;
operations on&nbsp; mips targets (LE especially) with&nbsp; old (2.4) kernels.<br>
----<br>
Pavel<br>
<br>
Ralf Baechle wrote:<br>
<blockquote type="cite" cite="mid20040923205946.GA375@linux-mips.org">
  <pre wrap="">On Thu, Sep 23, 2004 at 07:24:47PM +0400, Pavel Kiryukhin wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Sorry,
does this make sense for 2.4.x kernels?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Once uppon a time it made ...

The file has been rewritten completly since then.

Thanks anyway,

  Ralf

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

--------------010103060104080103060509--


From geoman@gentoo.org Fri Sep 24 16:13:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 16:13:34 +0100 (BST)
Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:50183 "EHLO
	lennier.cc.vt.edu") by linux-mips.org with ESMTP
	id <S8225216AbUIXPNa>; Fri, 24 Sep 2004 16:13:30 +0100
Received: from zidane.cc.vt.edu (IDENT:mirapoint@evil-zidane [10.1.1.13])
	by lennier.cc.vt.edu (8.12.8/8.12.8) with ESMTP id i8OFDTol317448;
	Fri, 24 Sep 2004 11:13:29 -0400 (EDT)
Received: from [128.173.184.75] (gs75.geol.vt.edu [128.173.184.75])
	by zidane.cc.vt.edu (MOS 3.4.8-GR)
	with ESMTP id BQB50375;
	Fri, 24 Sep 2004 11:13:27 -0400 (EDT)
Message-ID: <4154398E.3070806@gentoo.org>
Date: Fri, 24 Sep 2004 11:13:18 -0400
From: "Stephen P. Becker" <geoman@gentoo.org>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040916)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robin Humble <rjh@cita.utoronto.ca>
CC: linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
References: <4152D58B.608@longlandclan.hopto.org> <4152E4FC.8000408@gentoo.org> <41536765.9000304@longlandclan.hopto.org> <41541B8D.3060500@gentoo.org> <20040924131734.GC26710@lemming.cita.utoronto.ca> <415420D0.60102@gentoo.org> <20040924134334.GB27739@lemming.cita.utoronto.ca>
In-Reply-To: <20040924134334.GB27739@lemming.cita.utoronto.ca>
X-Enigmail-Version: 0.86.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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: 5889
X-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

>>day).  Also, Indys don't support a large enough memory configuration 
>>that 64-bit would be worth it anyhow.
> 
> 
> indeed they don't.
> do you get access to more registers or more efficient instruction sets
> like you do on x86_64?
> 
> 
>>What you would *really* want on such a machine would be n32 userland. 
>>You get full 64-bit instructions, but the binaries aren't huge.
> 

Yeah, that is what n32 is for.  You get more registers, but pointers are 
still 32-bit.  You still need a mips64 CHOST to build n32 binaries, however.

Steve


From stuartl@longlandclan.hopto.org Fri Sep 24 16:43:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 16:43:07 +0100 (BST)
Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:19520
	"EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP
	id <S8225205AbUIXPnB>; Fri, 24 Sep 2004 16:43:01 +0100
Received: (qmail 22303 invoked from network); 25 Sep 2004 01:42:50 +1000
Received: from unknown (HELO ?10.0.0.251?) (10.0.0.251)
  by 192.168.5.1 with SMTP; 25 Sep 2004 01:42:50 +1000
Message-ID: <4154407A.4050204@longlandclan.hopto.org>
Date: Sat, 25 Sep 2004 01:42:50 +1000
From: Stuart Longland <stuartl@longlandclan.hopto.org>
User-Agent: Mozilla Thunderbird 0.7 (X11/20040615)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Florian Lohoff <flo@rfc822.org>
CC: "Stephen P. Becker" <geoman@gentoo.org>, linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
References: <4152D58B.608@longlandclan.hopto.org> <4152E4FC.8000408@gentoo.org> <41536765.9000304@longlandclan.hopto.org> <20040924090703.GA13468@paradigm.rfc822.org>
In-Reply-To: <20040924090703.GA13468@paradigm.rfc822.org>
X-Enigmail-Version: 0.84.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <stuartl@longlandclan.hopto.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: 5890
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: stuartl@longlandclan.hopto.org
Precedence: bulk
X-list: linux-mips

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

Florian Lohoff wrote:
> On Fri, Sep 24, 2004 at 10:16:37AM +1000, Stuart Longland wrote:
>
>>Ahh yes... sorry, it was after midnight (GMT+10) and my mind must've
>>been elsewhere -- I meant o64.  I was planning on moving to either n32
>>or n64 userland eventually, but I won't do that unless I can get a
>>64-bit kernel going.
>
> The 64 bit kernel should work so far - With the ip22zilog.c fixes
> tsbogend just committed the console begins to work again.
>
> Includeing the patch i sent earlier my R5k Indy boots fine a 64bit
> current cvs head and goes into userspace.
>
> Using the "soo to be" rtc and statfs64 fixes everything seems to be
> fine for o32 userspace.

Tried the patch, for some reason 'patch' couldn't find some of the
files, and was expecting me to enter the paths in by hand... but once I
did that, it applied cleanly[1].

I still get much the same message from the PROM though:
- -------------------------------8<--------------------------------------
arcsboot: ARCS Linux ext2fs loader 0.3.8.2

Loading new from scsi(0)disk(1)rdisk(0)partition(0)
Allocated 0xe0 bytes for segments
Loading 64-bit executable
Loading program segment 2 at 0x88004000, offset=0x0 4000, size = 0x0 35b140
Loading program segment 3 at 0x88360020, offset=0x0 360020, size= 0x0 1c065
Zeroing memory at 0x8837c085 size = 0x21feb

Exception: <vector=Normal>
Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x8010<CE=0,IP8,EXC=RADE>
Exception PC: 0x830f018, Exception RA: 0x88804514
Read address error exception, bad address: 0x830f018
Local I/O interrupt register 1: 0x80 <VR/GIO2>
  Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
  arg: a8740000 88002000 88001fe0 18
  tmp: a8740000 2 8880e0b4 8360020 8880e0b0 887fe53c 887fe234 9fc55064
  sve: a8740000 3 400000 8000000 16 3f80 0 10000000
  t8 a8740000 t9 ffffffff at ffffffff v0 ffffffff v1 ffffffff k1 8360020
  gp a8740000 f0 ffffffff sp ffffffff ra ffffffff

PANIC: Unexpected exception

[Press reset or ENTER to restart.]
- ------------------------------->8--------------------------------------

Bypassing arcboot, I get:
- -------------------------------8<--------------------------------------
>> boot -f newlinux root=/dev/sda3

Exception: <vector=UTLB Miss>

Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x8008<CE=0,IP8,EXC=RMISS>
Exception PC: 0x9fc31644, Exception RA: 0x9fc3161c
exception, bad address: 0x8
Local I/O interrupt register 1: 0x80 <VR/GIO2>
  Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
  arg: a8740000 0 0 887fe878
  tmp: a8740000 0 887fec2c 2d 887fe8d8 887fec20 a8746d10 9fc55064
  sve: a8740000 3 400000 8000000 16 3f80 0 10000000
  t8 a8740000 t9 ffffffff at ffffffff v0 ffffffff v1 ffffffff k1 0
  gp a8740000 f0 ffffffff sp ffffffff ra ffffffff

PANIC: Unexpected exception

[Press reset or ENTER to restart.]
- ------------------------------->8--------------------------------------

The latter one is very much like the one mentioned on the website I
quoted earlier... but as I mentioned then, the fix doesn't seem to apply
to the latest code.

I can't rule out it being something with my config though.  Has someone
got a working config for mips64 on this class of machine?  (even a
binary)  Seeing as it works on R5k, could we be dealing with an R4x00
bug here?
- --
+-------------------------------------------------------------+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project     -oOo-    http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-------------------------------------------------------------+
1. except the Makefile and spaces.h files... it for some reason tried
patching linux/{Makefile,spaces.h} not linux/arch/... etc...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBVEB6uarJ1mMmSrkRAh6DAKCBBbry3yjtMkfZ9lFgGyfguSsPnwCeKRAz
UQOls5vmXNIkDNICUj77e80=
=+PVx
-----END PGP SIGNATURE-----

From flo@rfc822.org Fri Sep 24 17:45:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 17:45:09 +0100 (BST)
Received: from hydra.gt.owl.de ([IPv6:::ffff:195.71.99.218]:17127 "EHLO
	hydra.gt.owl.de") by linux-mips.org with ESMTP id <S8225252AbUIXQpF>;
	Fri, 24 Sep 2004 17:45:05 +0100
Received: by hydra.gt.owl.de (Postfix, from userid 104)
	id ACE9A199607; Fri, 24 Sep 2004 18:45:02 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id AD222138065; Fri, 24 Sep 2004 18:44:30 +0200 (CEST)
Date: Fri, 24 Sep 2004 18:44:30 +0200
From: Florian Lohoff <flo@rfc822.org>
To: Stuart Longland <stuartl@longlandclan.hopto.org>
Cc: "Stephen P. Becker" <geoman@gentoo.org>, linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
Message-ID: <20040924164430.GA29683@paradigm.rfc822.org>
References: <4152D58B.608@longlandclan.hopto.org> <4152E4FC.8000408@gentoo.org> <41536765.9000304@longlandclan.hopto.org> <20040924090703.GA13468@paradigm.rfc822.org> <4154407A.4050204@longlandclan.hopto.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr"
Content-Disposition: inline
In-Reply-To: <4154407A.4050204@longlandclan.hopto.org>
Organization: rfc822 - pure communication
User-Agent: Mutt/1.5.4i
Return-Path: <flo@rfc822.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5891
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips


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

On Sat, Sep 25, 2004 at 01:42:50AM +1000, Stuart Longland wrote:
> >
> > The 64 bit kernel should work so far - With the ip22zilog.c fixes
> > tsbogend just committed the console begins to work again.
> >
> > Includeing the patch i sent earlier my R5k Indy boots fine a 64bit
> > current cvs head and goes into userspace.
> >
> > Using the "soo to be" rtc and statfs64 fixes everything seems to be
> > fine for o32 userspace.
>=20
> Tried the patch, for some reason 'patch' couldn't find some of the
> files, and was expecting me to enter the paths in by hand... but once I
> did that, it applied cleanly[1].

The last file has a bogus path (Hand crafted patch) and needs the first=20
path element removed IIRC.

> Exception: <vector=3DNormal>
> Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=3D???,MODE=3DKERNEL,EXL,I=
E>
> Cause register: 0x8010<CE=3D0,IP8,EXC=3DRADE>
> Exception PC: 0x830f018, Exception RA: 0x88804514
> Read address error exception, bad address: 0x830f018
>Local I/O interrupt register 1: 0x80 <VR/GIO2>
>   Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
>   arg: a8740000 88002000 88001fe0 18
>   tmp: a8740000 2 8880e0b4 8360020 8880e0b0 887fe53c 887fe234 9fc55064
>   sve: a8740000 3 400000 8000000 16 3f80 0 10000000
>   t8 a8740000 t9 ffffffff at ffffffff v0 ffffffff v1 ffffffff k1 8360020
>   gp a8740000 f0 ffffffff sp ffffffff ra ffffffff
>=20
> PANIC: Unexpected exception

This should be a crash in free_bootmem_core because of the non correct
spaces.h

> I can't rule out it being something with my config though.  Has someone
> got a working config for mips64 on this class of machine?  (even a
> binary)  Seeing as it works on R5k, could we be dealing with an R4x00
> bug here?

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

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

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

iD8DBQFBVE7uUaz2rXW+gJcRAmQMAJ0fgz/GEM2DvOUtELNsgPWGoqGQGACbBUNt
ynfqv3d8WbZrt/pLjFv+E1U=
=a9fu
-----END PGP SIGNATURE-----

--liOOAslEiF7prFVr--

From raiko@niisi.msk.ru Fri Sep 24 18:31:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 18:31:16 +0100 (BST)
Received: from [IPv6:::ffff:193.232.173.111] ([IPv6:::ffff:193.232.173.111]:48101
	"EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP
	id <S8225252AbUIXRbM>; Fri, 24 Sep 2004 18:31:12 +0100
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 i8OHSIdB017767
	for <linux-mips@linux-mips.org>; Fri, 24 Sep 2004 21:28:18 +0400
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 i8OHVfGr028848
	for <linux-mips@linux-mips.org>; Fri, 24 Sep 2004 21:31:41 +0400
Received: (from uucp@localhost)
	by t06.niisi.ras.ru (8.12.8/8.12.8/Submit) with UUCP id i8OHVfr6028846
	for linux-mips@linux-mips.org; Fri, 24 Sep 2004 21:31:41 +0400
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 i8OHOnga025697
	for <linux-mips@linux-mips.org>; Fri, 24 Sep 2004 21:24:49 +0400
Message-ID: <4154597C.3080405@niisi.msk.ru>
Date: Fri, 24 Sep 2004 21:29:32 +0400
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: redhat/7.3/NIISI updated
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]); Fri, 24 Sep 2004 21:24:49 +0400
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: 5892
X-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

Hello,

I've uploaded new NIISI packages in 
ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.3/NIISI/

The NIISI packages are updated version of H.J. Lu's mini-port of RedHat 7.3.

Most important change in this update is all packages from mini-port and 
previous NIISI updates were recompiled due to a bug in the C/C++ 
compiler from the original toolchain package. Of course, the bug itself 
is fixed in toolchain.

Other changes include RH/FL security fixes and a lot of new stuff.

Finally, a (not-so-)minimal root fs package  is provided in tools.

Regards,
Gleb.



From D.Mierzejewski@icm.edu.pl Fri Sep 24 18:43:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 18:43:20 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:904 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225252AbUIXRnQ>;
	Fri, 24 Sep 2004 18:43:16 +0100
Received: from burza.icm.edu.pl (burza.icm.edu.pl [192.168.1.198])
	by atol.icm.edu.pl (8.12.3/8.12.6/rzm-4.6/icm) with ESMTP id i8OHhDJI009579
	for <linux-mips@linux-mips.org>; Fri, 24 Sep 2004 19:43:14 +0200
Received: from liandra.icm.edu.pl (liandra.icm.edu.pl [192.168.1.116])
	by burza.icm.edu.pl (8.12.9/8.12.9/rzm-2.9.3/icm) with ESMTP id i8OHhFn8029576
	for <linux-mips@linux-mips.org>; Fri, 24 Sep 2004 19:43:15 +0200 (CEST)
Received: by liandra.icm.edu.pl (Postfix, from userid 5242)
	id 782773F2E; Fri, 24 Sep 2004 19:43:14 +0200 (CEST)
Date: Fri, 24 Sep 2004 19:43:14 +0200
From: "Dominik 'Rathann' Mierzejewski" <D.Mierzejewski@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: redhat/7.3/NIISI updated
Message-ID: <20040924174313.GB6050@liandra.icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <4154597C.3080405@niisi.msk.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4154597C.3080405@niisi.msk.ru>
User-Agent: Mutt/1.5.6i
Return-Path: <D.Mierzejewski@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5893
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: D.Mierzejewski@icm.edu.pl
Precedence: bulk
X-list: linux-mips

On Fri, Sep 24, 2004 at 09:29:32PM +0400, Gleb O. Raiko wrote:
> Hello,
> 
> I've uploaded new NIISI packages in 
> ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.3/NIISI/
> 
> The NIISI packages are updated version of H.J. Lu's mini-port of RedHat 7.3.
> 
> Most important change in this update is all packages from mini-port and 
> previous NIISI updates were recompiled due to a bug in the C/C++ 
> compiler from the original toolchain package. Of course, the bug itself 
> is fixed in toolchain.
> 
> Other changes include RH/FL security fixes and a lot of new stuff.
> 
> Finally, a (not-so-)minimal root fs package  is provided in tools.

Is there a HOWTO available specifically for cross-building RH7.3 for MIPS
on another (x86) RedHat/Fedora box?

-- 
Dominik 'Rathann' Mierzejewski <rathann*at*icm.edu.pl>
Interdisciplinary Centre for Mathematical and Computational Modelling
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810

From ppopov@embeddedalley.com Fri Sep 24 19:33:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 19:34:03 +0100 (BST)
Received: from web81407.mail.yahoo.com ([IPv6:::ffff:206.190.37.96]:43104 "HELO
	web81407.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225262AbUIXSd7>; Fri, 24 Sep 2004 19:33:59 +0100
Message-ID: <20040924183352.31414.qmail@web81407.mail.yahoo.com>
Received: from [216.98.102.225] by web81407.mail.yahoo.com via HTTP; Fri, 24 Sep 2004 11:33:52 PDT
X-RocketYMMF: pete_popov
Date: Fri, 24 Sep 2004 11:33:52 -0700 (PDT)
From: Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
Subject: Re: CPU frequency scaling on MIPS (au1000/common/power.c)
To: Dominik Brodowski <linux@dominikbrodowski.de>, ralf@linux-mips.org,
	linux-mips@linux-mips.org
Cc: cpufreq@www.linux.org.uk
In-Reply-To: <20040923201916.38891.qmail@web81408.mail.yahoo.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: 5894
X-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


AMD notified me that the frequency scaling will not be
supported moving forward and will not be guaranteed to
work. Therefore, I'll have to remove that code from
the kernel so that it's not misleading.

Pete

--- Pete Popov <ppopov@embeddedalley.com> wrote:

> 
> <snip>
> 
> > Therefore, I'd suggest that we update
> > arch/mips/au1000/common/power.c to
> > use the cpufreq infrastructure. 
> 
> 
> The current interface was written a few years ago
> for
> 2.4, when I couldn't find a general PM interface to
> start with.
> 
> 
> > Nonetheless I'd be willing to write
> > a "suggestion" on how to update
> > arch/mips/au1000/common/power.c, and
> > somebody with compiler and hardware could test it
> > then.
> 
> That would help, though I'm not sure when I would
> get
> to it personally. I'm working on 2.6 updates at the
> moment with some other developers, but PM is not on
> our list for now. If you're dying to work on it and
> hardware is the only issue, I might be able to help
> :)
> 
> > Are there other MIPS CPUs which support CPU
> > frequency scaling? 
> 
> Not that I know of, and not the way the Au1x
> supports
> it.
> 
> 
> Pete
> 
> 


From brodo@dominikbrodowski.de Fri Sep 24 21:12:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 21:12:37 +0100 (BST)
Received: from natsmtp00.rzone.de ([IPv6:::ffff:81.169.145.165]:57268 "EHLO
	natsmtp00.rzone.de") by linux-mips.org with ESMTP
	id <S8225262AbUIXUMc>; Fri, 24 Sep 2004 21:12:32 +0100
Received: from mondschein.dominikbrodowski.de (pD9F8C86E.dip.t-dialin.net [217.248.200.110])
	by post.webmailer.de (8.13.1/8.13.1) with ESMTP id i8OKCCsM018771;
	Fri, 24 Sep 2004 22:12:12 +0200 (MEST)
Received: by mondschein.dominikbrodowski.de (Postfix, from userid 1111)
	id 5854930DFF; Fri, 24 Sep 2004 22:05:46 +0200 (CEST)
Date: Fri, 24 Sep 2004 22:05:46 +0200
From: Dominik Brodowski <linux@dominikbrodowski.de>
To: Pete Popov <ppopov@embeddedalley.com>
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org,
	cpufreq@www.linux.org.uk
Subject: Re: CPU frequency scaling on MIPS (au1000/common/power.c)
Message-ID: <20040924200546.GA8033@dominikbrodowski.de>
Mail-Followup-To: Pete Popov <ppopov@embeddedalley.com>,
	ralf@linux-mips.org, linux-mips@linux-mips.org,
	cpufreq@www.linux.org.uk
References: <20040923201916.38891.qmail@web81408.mail.yahoo.com> <20040924183352.31414.qmail@web81407.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040924183352.31414.qmail@web81407.mail.yahoo.com>
User-Agent: Mutt/1.5.6i
Return-Path: <brodo@dominikbrodowski.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: 5895
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: linux@dominikbrodowski.de
Precedence: bulk
X-list: linux-mips

On Fri, Sep 24, 2004 at 11:33:52AM -0700, Pete Popov wrote:
> 
> AMD notified me that the frequency scaling will not be
> supported moving forward and will not be guaranteed to
> work.

... bad for them. Would have been a great feature. But they do have
excellent implementations in other chips...

	Dominik

From Filip@Linux4.Be Fri Sep 24 23:15:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Sep 2004 23:15:53 +0100 (BST)
Received: from 178.69-56-134.reverse.theplanet.com ([IPv6:::ffff:69.56.134.178]:33685
	"EHLO texas.onkelinx.com") by linux-mips.org with ESMTP
	id <S8225287AbUIXWPt>; Fri, 24 Sep 2004 23:15:49 +0100
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1])
	(authenticated bits=0)
	by texas.onkelinx.com (8.12.8/8.12.8) with ESMTP id i8OMFmtl030342;
	Fri, 24 Sep 2004 17:15:49 -0500
Message-ID: <41549C74.3090309@Linux4.Be>
Date: Sat, 25 Sep 2004 00:15:16 +0200
From: Filip Onkelinx <Filip@Linux4.Be>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
CC: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: "Can't analyze prologue code ..." at boot time
References: <20040924085240.GP24730@enix.org> <20040924.190640.09669815.nemoto@toshiba-tops.co.jp> <20040924121107.GB24730@enix.org>
In-Reply-To: <20040924121107.GB24730@enix.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <Filip@Linux4.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: 5896
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Filip@Linux4.Be
Precedence: bulk
X-list: linux-mips

Hi Atsushi,

I just applied your patch to our current 2.6.9-rc2 kernel for the BE300 
project (Casio BE300/BE500 PDA with NEC vr4131 rev1.2), and the
"Couldn't analyze prologue code .." message is gone as well.

Before, the kernel was very unreliable, but I also sync'ed with the 
latest from CVS and switched gcc version , so I'm not sure if it is your 
patch that's responsible for the stabiltity or one of the other changes.

thanks,

Filip.

 Thomas Petazzoni wrote:

>Hello,
>
>On Fri, Sep 24, 2004 at 07:06:40PM +0900, Atsushi Nemoto wrote :
>
>  
>
>>I rewrote get_wchan() to handle this problem.  Please try this patch.
>>    
>>
>
>This patch works for me. At least, the "Couldn't analyze prologue code
>at ..." message doesn't appear anymore.
>
>Thanks,
>
>Thomas
>  
>


-- 
----

Do not follow where the path may lead. Go instead where there is no path and leave a trail  - Ralph Waldo Emerson

----

Filip Onkelinx
Heidebloemstraat 20, B-3500 Hasselt, BELGIUM
fax: +32 11 65 65 97, mobile: +32 475 69 47 63
filip@onkelinx.com


From mlachwani@mvista.com Sat Sep 25 00:40:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Sep 2004 00:40:32 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:25839 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225287AbUIXXk2>; Sat, 25 Sep 2004 00:40:28 +0100
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP
	id BC8DF1848F; Fri, 24 Sep 2004 16:40:25 -0700 (PDT)
Message-ID: <4154B069.8010708@mvista.com>
Date: Fri, 24 Sep 2004 16:40:25 -0700
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: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: IDE woos in BE mode 2.6 kernel
References: <414B388D.8060705@mvista.com> <20040918.231947.74754644.anemo@mba.ocn.ne.jp>
In-Reply-To: <20040918.231947.74754644.anemo@mba.ocn.ne.jp>
Content-Type: multipart/mixed;
 boundary="------------000805080008060208050202"
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: 5897
X-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

This is a multi-part message in MIME format.
--------------000805080008060208050202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello !

These changes below work and attached is the patch based on your 
suggestion. However, I have made changes to include/asm-mips/ide.h since 
I think there may be problems with other MIPS boards to in BE mode. 
And,  I have not included the  (dma_cache_wback) in the patch.

Thanks
Manish


Atsushi Nemoto wrote:

>>>>>>On Fri, 17 Sep 2004 12:18:37 -0700, Manish Lachwani <mlachwani@mvista.com> said:
>>>>>>            
>>>>>>
>
>mlachwani> In response to Jun Suns mail sent on 06/24/2004
>
>jsun> Anybody has tried IDE disks in big endian mode with 2.6
>jsun> kernel?  I seem to have troubles with Malta board.
>...
>mlachwani> The following patch gets the Malta to work well. However,
>mlachwani> this patch introduces board specific changes in the IDE
>mlachwani> subsystem.  This is not a final patch but maybe there can
>mlachwani> be a better approach to this issue
>
>FYI, here is my approach.  Not so beautiful but less intrusive...
>
>1. copy include/asm-mips/mach-generic/ide.h to my mach-xxx directory.
>2. add following lines to include/asm-mips/mach-xxx/ide.h
>--- begin ---
>/* get rid of defs from io.h - ide has its private and conflicting versions */
>#ifdef insb
>#undef insb
>#endif
>#ifdef outsb
>#undef outsb
>#endif
>#ifdef insw
>#undef insw
>#endif
>#ifdef outsw
>#undef outsw
>#endif
>#ifdef insl
>#undef insl
>#endif
>#ifdef outsl
>#undef outsl
>#endif
>
>#define insb(port, addr, count) ___ide_insb(port, addr, count)
>#define insw(port, addr, count) ___ide_insw(port, addr, count)
>#define insl(port, addr, count) ___ide_insl(port, addr, count)
>#define outsb(port, addr, count) ___ide_outsb(port, addr, count)
>#define outsw(port, addr, count) ___ide_outsw(port, addr, count)
>#define outsl(port, addr, count) ___ide_outsl(port, addr, count)
>
>static inline void ___ide_insb(unsigned long port, void *addr, unsigned int count)
>{
>	unsigned long start = (unsigned long)addr;
>	unsigned long size = (unsigned long)count;
>	while (count--) {
>		*(u16 *)addr = *(volatile u8 *)(mips_io_port_base + port);
>		addr++;
>	}
>	if (cpu_has_dc_aliases)
>		dma_cache_wback((unsigned long)start, size);
>}
>
>static inline void ___ide_outsb(unsigned long port, void *addr, unsigned int count)
>{
>	while (count--) {
>		*(volatile u8 *)(mips_io_port_base + port) = *(u8 *)addr;
>		addr++;
>	}
>}
>
>static inline void ___ide_insw(unsigned long port, void *addr, unsigned int count)
>{
>	unsigned long start = (unsigned long)addr;
>	unsigned long size = (unsigned long)count * 2;
>	while (count--) {
>		*(u16 *)addr = *(volatile u16 *)(mips_io_port_base + port);
>		addr += 2;
>	}
>	if (cpu_has_dc_aliases)
>		dma_cache_wback((unsigned long)start, size);
>}
>
>static inline void ___ide_outsw(unsigned long port, void *addr, unsigned int count)
>{
>	while (count--) {
>		*(volatile u16 *)(mips_io_port_base + port) = *(u16 *)addr;
>		addr += 2;
>	}
>}
>
>static inline void ___ide_insl(unsigned long port, void *addr, unsigned int count)
>{
>	unsigned long start = (unsigned long)addr;
>	unsigned long size = (unsigned long)count * 4;
>	while (count--) {
>		*(u32 *)addr = *(volatile u32 *)(mips_io_port_base + port);
>		addr += 4;
>	}
>	if (cpu_has_dc_aliases)
>		dma_cache_wback((unsigned long)start, size);
>}
>
>static inline void ___ide_outsl(unsigned long port, void *addr, unsigned int count)
>{
>	while (count--) {
>		*(volatile u32 *)(mips_io_port_base + port) = *(u32 *)addr;
>		addr += 4;
>	}
>}
>--- end ---
>
>Note that above codes include workarounds for PIO IDE cache problem
>(dma_cache_wback) though I'm not sure this workaround still needed.
>Please refer this ML thread for the workaround.
><http://www.linux-mips.org/archives/linux-mips/2004-03/msg00185.html>
>
>
>And as I wrote before, I think this IDE endian problem still exists in
>current 2.4 tree too.  Please refer my 02/26 mail for this topic.
><http://www.linux-mips.org/archives/linux-mips/2004-02/msg00219.html>
>
>Thank you.
>
>---
>Atsushi Nemoto
>  
>


--------------000805080008060208050202
Content-Type: text/plain;
 name="patch-26-ide-malta"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch-26-ide-malta"

--- include/asm-mips/ide.h.orig	2004-09-16 15:41:00.000000000 -0700
+++ include/asm-mips/ide.h	2004-09-20 09:45:14.000000000 -0700
@@ -20,6 +20,91 @@
 #define __ide_mm_outsw  ide_outsw
 #define __ide_mm_outsl  ide_outsl
 
+#ifndef CONFIG_CPU_LITTLE_ENDIAN
+/*
+ * Only for the Big Endian systems, do not do the swapping.
+ * We cannot turn off the CONFIG_SWAP_IO_SPACE since the
+ * other subsystems need it. Hence we need this approach for
+ * IDE only - Manish Lachwani (mlachwani@mvista.com)
+ */
+extern const unsigned long mips_io_port_base;
+
+#ifdef insb
+#undef insb
+#endif
+#ifdef outsb
+#undef outsb
+#endif
+#ifdef insw
+#undef insw
+#endif
+#ifdef outsw
+#undef outsw
+#endif
+#ifdef insl
+#undef insl
+#endif
+#ifdef outsl
+#undef outsl
+#endif
+
+#define insb(port, addr, count)		___ide_insb(port, addr, count)
+#define insw(port, addr, count)		___ide_insw(port, addr, count)
+#define insl(port, addr, count)		___ide_insl(port, addr, count)
+#define outsb(port, addr, count)	___ide_outsb(port, addr, count)
+#define outsw(port, addr, count)	___ide_outsw(port, addr, count)
+#define outsl(port, addr, count)	___ide_outsl(port, addr, count)
+
+static inline void ___ide_insb(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(u16 *)addr = *(volatile u8 *)(mips_io_port_base + port);
+		addr++;
+	}
+}
+
+static inline void ___ide_outsb(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(volatile u8 *)(mips_io_port_base + port) = *(u8 *)addr;
+		addr++;
+	}
+}
+
+static inline void ___ide_insw(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(u16 *)addr = *(volatile u16 *)(mips_io_port_base + port);
+		addr += 2;
+	}
+}
+
+static inline void ___ide_outsw(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(volatile u16 *)(mips_io_port_base + port) = *(u16 *)addr;
+		addr += 2;
+	}
+}
+
+static inline void ___ide_insl(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(u32 *)addr = *(volatile u32 *)(mips_io_port_base + port);
+		addr += 4;
+	}
+}
+
+static inline void ___ide_outsl(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(volatile u32 *)(mips_io_port_base + port) = *(u32 *)addr;
+		addr += 4;
+	}
+}
+
+#endif /* CONFIG_LITTLE_ENDIAN */
+
 #endif /* __KERNEL__ */
 
 #endif /* __ASM_IDE_H */

--------------000805080008060208050202--


From anemo@mba.ocn.ne.jp Sat Sep 25 14:53:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Sep 2004 14:53:52 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:63428 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225254AbUIYNxs>; Sat, 25 Sep 2004 14:53:48 +0100
Received: from localhost (p8149-ipad01funabasi.chiba.ocn.ne.jp [61.207.82.149])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id C322D7F01; Sat, 25 Sep 2004 22:53:44 +0900 (JST)
Date: Sat, 25 Sep 2004 23:03:41 +0900 (JST)
Message-Id: <20040925.230341.74756845.anemo@mba.ocn.ne.jp>
To: Filip@Linux4.Be
Cc: linux-mips@linux-mips.org
Subject: Re: "Can't analyze prologue code ..." at boot time
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <41549C74.3090309@Linux4.Be>
References: <20040924.190640.09669815.nemoto@toshiba-tops.co.jp>
	<20040924121107.GB24730@enix.org>
	<41549C74.3090309@Linux4.Be>
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: 5898
X-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, 25 Sep 2004 00:15:16 +0200, Filip Onkelinx <Filip@Linux4.Be> said:

Filip> I just applied your patch to our current 2.6.9-rc2 kernel for
Filip> the BE300 project (Casio BE300/BE500 PDA with NEC vr4131
Filip> rev1.2), and the "Couldn't analyze prologue code .." message is
Filip> gone as well.

Good to hear that.

Filip> Before, the kernel was very unreliable, but I also sync'ed with
Filip> the latest from CVS and switched gcc version , so I'm not sure
Filip> if it is your patch that's responsible for the stabiltity or
Filip> one of the other changes.

I'm pretty sure it is not my patch.  The problem fixed by my patch
should not be a so fatal.  Congratulation anyway.

---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Sat Sep 25 15:31:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Sep 2004 15:31:23 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:27106 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225254AbUIYObT>; Sat, 25 Sep 2004 15:31:19 +0100
Received: from localhost (p8149-ipad01funabasi.chiba.ocn.ne.jp [61.207.82.149])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id E44CE7F5D; Sat, 25 Sep 2004 23:31:15 +0900 (JST)
Date: Sat, 25 Sep 2004 23:41:12 +0900 (JST)
Message-Id: <20040925.234112.41626050.anemo@mba.ocn.ne.jp>
To: mlachwani@mvista.com
Cc: linux-mips@linux-mips.org
Subject: Re: IDE woos in BE mode 2.6 kernel
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <4154B069.8010708@mvista.com>
References: <414B388D.8060705@mvista.com>
	<20040918.231947.74754644.anemo@mba.ocn.ne.jp>
	<4154B069.8010708@mvista.com>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 5899
X-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, 24 Sep 2004 16:40:25 -0700, Manish Lachwani <mlachwani@mvista.com> said:

mlachwani> These changes below work and attached is the patch based on
mlachwani> your suggestion. However, I have made changes to
mlachwani> include/asm-mips/ide.h since I think there may be problems
mlachwani> with other MIPS boards to in BE mode.  And, I have not
mlachwani> included the (dma_cache_wback) in the patch.

Hmm, I think declaration of mips_io_port_base is not needed since
asm/io.h must be included before asm/ide.h.  If asm/io.h was not
included first, ide.h can not override these functions anyway.

Also, moving the fixup block before "#include <ide.h>" will give a
chance to override these functions again in mach-dependent ide.h. (for
more weired hardware)

---
Atsushi Nemoto

From paul@clubi.ie Sat Sep 25 17:56:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Sep 2004 17:56:40 +0100 (BST)
Received: from hibernia.jakma.org ([IPv6:::ffff:212.17.55.49]:10884 "EHLO
	hibernia.jakma.org") by linux-mips.org with ESMTP
	id <S8225215AbUIYQ4g>; Sat, 25 Sep 2004 17:56:36 +0100
Received: from hibernia.jakma.org (IDENT:paul@hibernia.jakma.org [192.168.0.3])
	by hibernia.jakma.org (8.12.11/8.12.11) with ESMTP id i8PGuTxO029761
	for <linux-mips@linux-mips.org>; Sat, 25 Sep 2004 17:56:30 +0100
Date: Sat, 25 Sep 2004 17:56:29 +0100 (IST)
From: Paul Jakma <paul@clubi.ie>
X-X-Sender: paul@hibernia.jakma.org
To: Linux MIPS <linux-mips@linux-mips.org>
Subject: Re: O2/IP32 R10k status / gbefb and LCD
In-Reply-To: <Pine.LNX.4.61.0409231251580.21165@hibernia.jakma.org>
Message-ID: <Pine.LNX.4.61.0409251748040.29420@hibernia.jakma.org>
References: <Pine.LNX.4.61.0409231251580.21165@hibernia.jakma.org>
X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Return-Path: <paul@clubi.ie>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5900
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: paul@clubi.ie
Precedence: bulk
X-list: linux-mips

On Thu, 23 Sep 2004, Paul Jakma wrote:

> yet have anything to serial console it to, and i'm trying to figure out if 
> the apparent LCD support in gbefb is working (gbefb=monitor:lcd).

Which it doesnt appear to.

Very recent CVS kernel, 8M framebuffer compiled in, it boots 
(keyboard leds work), but no display (screen is left as is from 
PROM).

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Everything I like is either illegal, immoral or fattening.
 		-- Alexander Woollcott

From raiko@niisi.msk.ru Mon Sep 27 08:59:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Sep 2004 09:00:01 +0100 (BST)
Received: from [IPv6:::ffff:193.232.173.111] ([IPv6:::ffff:193.232.173.111]:11471
	"EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP
	id <S8224924AbUI0H75>; Mon, 27 Sep 2004 08:59:57 +0100
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 i8R7u7Xx004456;
	Mon, 27 Sep 2004 11:56:08 +0400
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 i8R7xXGr023726;
	Mon, 27 Sep 2004 11:59:33 +0400
Received: (from uucp@localhost)
	by t06.niisi.ras.ru (8.12.8/8.12.8/Submit) with UUCP id i8R7xX3N023724;
	Mon, 27 Sep 2004 11:59:33 +0400
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 i8R7rqga002212;
	Mon, 27 Sep 2004 11:53:52 +0400
Message-ID: <4157C84F.1050308@niisi.msk.ru>
Date: Mon, 27 Sep 2004 11:59:11 +0400
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Dominik 'Rathann' Mierzejewski" <D.Mierzejewski@icm.edu.pl>
CC: linux-mips@linux-mips.org
Subject: Re: redhat/7.3/NIISI updated
References: <4154597C.3080405@niisi.msk.ru> <20040924174313.GB6050@liandra.icm.edu.pl>
In-Reply-To: <20040924174313.GB6050@liandra.icm.edu.pl>
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, 27 Sep 2004 11:53:53 +0400
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: 5901
X-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

hello!

Dominik 'Rathann' Mierzejewski wrote:
> Is there a HOWTO available specifically for cross-building RH7.3 for MIPS
> on another (x86) RedHat/Fedora box?

We used RH 7.3/i386. As I said every package in redhat/7.3/NIISI was 
cross-compiled on i386 for the MIPS I BE arch.

nano-HOWTO:

1. Install rpm and toolchain from RPMS/devel on RH 7.3/i386
2. Rebuild packages. Use rpmrc, rpmmacro, and 
find-requires-mips-linux-full during rebuild
3. Use scripts/spec-gen to get mips-linux- packages

That's all.

Regards,
Gleb.


From robbat2@orbis-terrarum.net Mon Sep 27 09:55:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Sep 2004 09:55:21 +0100 (BST)
Received: from shawidc-mo1.cg.shawcable.net ([IPv6:::ffff:24.71.223.10]:56636
	"EHLO pd3mo1so.prod.shaw.ca") by linux-mips.org with ESMTP
	id <S8224924AbUI0IzO>; Mon, 27 Sep 2004 09:55:14 +0100
Received: from pd4mr2so.prod.shaw.ca
 (pd4mr2so-qfe3.prod.shaw.ca [10.0.141.213]) by l-daemon
 (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004))
 with ESMTP id <0I4O008HWZFZ5LB0@l-daemon> for linux-mips@linux-mips.org; Mon,
 27 Sep 2004 02:55:11 -0600 (MDT)
Received: from pn2ml9so.prod.shaw.ca ([10.0.121.7])
 by pd4mr2so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar
 15 2004)) with ESMTP id <0I4O005F4ZFZ8V00@pd4mr2so.prod.shaw.ca> for
 linux-mips@linux-mips.org; Mon, 27 Sep 2004 02:55:11 -0600 (MDT)
Received: from curie.orbis-terrarum.net
 (S01060050da688d47.vc.shawcable.net [24.80.109.92])
 by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003))
 with ESMTP id <0I4O00E9QZFYOK@l-daemon> for linux-mips@linux-mips.org; Mon,
 27 Sep 2004 02:55:11 -0600 (MDT)
Received: (qmail 17900 invoked by uid 10000); Mon, 27 Sep 2004 01:55:10 -0700
Date: Mon, 27 Sep 2004 01:55:10 -0700
From: "Robin H. Johnson" <robbat2@gentoo.org>
Subject: 2.6 kernel work for XXS1500
To: linux-mips@linux-mips.org
Mail-followup-to: linux-mips@linux-mips.org
Message-id: <20040927085510.GD10739@curie-int.orbis-terrarum.net>
MIME-version: 1.0
Content-type: multipart/signed; boundary=oJ71EGRlYNjSvfq7;
 protocol="application/pgp-signature"; micalg=pgp-sha1
Content-disposition: inline
User-Agent: Mutt/1.5.6i
Return-Path: <robbat2@orbis-terrarum.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: 5902
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: robbat2@gentoo.org
Precedence: bulk
X-list: linux-mips


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

This is a general announcement of some work being done to update XXS1500
support to a 2.6 kernel level. Testers welcome.

This isn't ready for CVS inclusion yet, still needs more testing and
validation, but to stop the hordes of people emailing me about it (Hi
Marcel), here it is being publicly announced:
http://dev.gentoo.org/~robbat2/xxs1500/linux-xxs1500-20040927.patch-dangero=
us.gz
Applies against latest CVS.

Contains:
- Kconfig stuff for the BCM5222 Dual PHY.
- XXS1500 PCI IRQ stuff
- MTD access to the onboard flash (Pete's code)
- Kconfig stuff for MTD flash
- drivers/pcmcia/au1000_generic.c: cleanup debug code
- drivers/pcmcia/au1000_xxs1500.c: port to 2.6
- Move include/asm-mips/xxs1500.h to include/asm-mips/mach-xxs1500/xxs1500.h

No warranty on it, I don't trust my PCMCIA code entirely yet.

=46rom the original codebase:
a) au_writel((au_readl(GPIO2_PINSTATE) & ~(1<<14))|(1<<30), GPIO2_OUTPUT);
b) au_writel((au_readl(GPIO2_PINSTATE) | (1<<14))|(1<<30), GPIO2_OUTPUT);

The 1<<14 indicates a specific location to set, and the 1<<30 says to
enable output on that location.
In arch/mips/au1000/xxs1500/board_setup.c, snippet a is commented as
'turn off power'.
In drivers/pcmcia/au1000_xxs1500.c, snippet a is commented as 'turn on
power', and snippet b is commented as 'turn off power'.

Your guess is as good as mine as to which does what.

I've replaced them with two macros:
XXS1500_GPIO2_PCMCIA_POWER_ON
XXS1500_GPIO2_PCMCIA_POWER_OFF

Due to the number of times they occur.

--=20
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
Home Page  : http://www.orbis-terrarum.net/?l=3Dpeople.robbat2
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Robbat2 @ Orbis-Terrarum Networks

iD8DBQFBV9VuPpIsIjIzwiwRAsRXAJ4yH+A5Y+0eI3WOtn0GwJF7EcqcEgCfWwcE
a/A0S1RbZB9TfOR48i2pM5A=
=w81n
-----END PGP SIGNATURE-----

--oJ71EGRlYNjSvfq7--

From ladis@linux-mips.org Mon Sep 27 12:39:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Sep 2004 12:39:17 +0100 (BST)
Received: from smtp.seznam.cz ([IPv6:::ffff:212.80.76.43]:18914 "HELO
	smtp.seznam.cz") by linux-mips.org with SMTP id <S8224990AbUI0LjM>;
	Mon, 27 Sep 2004 12:39:12 +0100
Received: (qmail 13165 invoked from network); 27 Sep 2004 11:39:01 -0000
Received: from unknown (HELO umax645sx) (Ladislav.Michl@160.218.40.3)
  by smtp.seznam.cz with SMTP; 27 Sep 2004 11:39:01 -0000
Received: from ladis by umax645sx with local (Exim 3.36 #1 (Debian))
	id 1CAUw8-0004cZ-00; Thu, 23 Sep 2004 16:51:08 +0200
Date: Thu, 23 Sep 2004 16:51:08 +0200
To: Stuart Longland <stuartl@longlandclan.hopto.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
Message-ID: <20040923145108.GA17740@umax645sx>
References: <4152D58B.608@longlandclan.hopto.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4152D58B.608@longlandclan.hopto.org>
User-Agent: Mutt/1.5.6+20040818i
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: 5903
X-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 Thu, Sep 23, 2004 at 11:54:19PM +1000, Stuart Longland wrote:
> Hi All,
> 	I've been trying to get Linux 2.6 going on my Indy for some time now.
> However, I've had little success.  The machine works just fine under
> Linux 2.4.26.
> 
> 	The kernel config is attached.  Basically I've tried both booting a
> MIPS32 kernel as well as a MIPS64 kernel.  In all cases, I've used the
> same kernel parameters.  (root=/dev/hda3, and sometimes I put
> init=/bin/sh or single there too.)
> 
> 	Using a MIPS32 config, the kernel boots, mounts the / filesystem, but
> then dies claiming it can't find /sbin/init.
> 
> 	Using a MIPS64 config (built using gas-abi=o32 as suggested by Kumba),
> it doesn't even get that far:
> 
> - From arcboot/SGI PROM:
> (Arcboot version 0.3.8.2)
> - -------------------------------8<--------------------------------------
> Loading program segment 2 at 0x88002000, offset=0x0, size= 0x0 328085
> Zeroing memory at 0x0032a085, size = 0x1bba3
> 
> Exception: <vector=Normal>
> Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE>
> Cause register: 0x8010<CE=0,IP8,EXC=RADE>
> Exception PC: 0x830f018, Exception RA: 0x88804514
> Read address error exception, bad address: 0x830f018
> Local I/O interrupt register 1: 0x80 <VR/GIO2>
>   Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
>   arg: a8740000 88002000 88001fe0 18
>   tmp: a8740000 3 8880e0b4 830f018 8880e0b0 887fe8ec 887fe5e4 4
>   sve: a8740000 3 400000 800000 16 3f80 0 10000000
>   t8 a8740000 t9 ffffffff at ffffffff v0 ffffffff v1 ffffffff k1 830f018
>   gp a8740000 f0 ffffffff sp ffffffff ra ffffffff
> 
> PANIC: Unexpected exception

If that's more than two hours old CVS kernel then it's my fault, already fixed.
[snip]

> 	Apologies if this has been answered before... but I'm a bit of a newbie
> when it comes to Linux/MIPS.[2]  Is there anything I missed when setting
> this all up?

We have both Indy and O2 running there, but you'll have to wait a bit
until patches appear in CVS.

Regards,
	ladis

From ppopov@embeddedalley.com Mon Sep 27 15:03:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Sep 2004 15:03:05 +0100 (BST)
Received: from adsl-68-124-224-226.dsl.snfc21.pacbell.net ([IPv6:::ffff:68.124.224.226]:19725
	"EHLO goobz.com") by linux-mips.org with ESMTP id <S8224934AbUI0ODB>;
	Mon, 27 Sep 2004 15:03:01 +0100
Received: from [10.2.2.70] (adsl-63-194-214-47.dsl.snfc21.pacbell.net [63.194.214.47])
	by goobz.com (8.10.1/8.10.1) with ESMTP id i8RE2tH20112;
	Mon, 27 Sep 2004 07:02:56 -0700
Message-ID: <41581D75.3090706@embeddedalley.com>
Date: Mon, 27 Sep 2004 07:02:29 -0700
From: Pete Popov <ppopov@embeddedalley.com>
User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Robin H. Johnson" <robbat2@gentoo.org>
CC: linux-mips@linux-mips.org
Subject: Re: 2.6 kernel work for XXS1500
References: <20040927085510.GD10739@curie-int.orbis-terrarum.net>
In-Reply-To: <20040927085510.GD10739@curie-int.orbis-terrarum.net>
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: 5904
X-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

Hi Robin,

Robin H. Johnson wrote:

>This is a general announcement of some work being done to update XXS1500
>support to a 2.6 kernel level. Testers welcome.
>
>This isn't ready for CVS inclusion yet, still needs more testing and
>validation, but to stop the hordes of people emailing me about it (Hi
>Marcel), here it is being publicly announced:
>http://dev.gentoo.org/~robbat2/xxs1500/linux-xxs1500-20040927.patch-dangerous.gz
>Applies against latest CVS.
>
>Contains:
>- Kconfig stuff for the BCM5222 Dual PHY.
>- XXS1500 PCI IRQ stuff
>- MTD access to the onboard flash (Pete's code)
>- Kconfig stuff for MTD flash
>- drivers/pcmcia/au1000_generic.c: cleanup debug code
>  
>
I've updated the pcmcia driver but haven't pushed the patch in yet. I 
cleaned up the debug code but I'll take a look at what you've done too.

The rest of the core 2.6 update is on its way, including the 36bit 
support, zImage, all the drivers, etc.

Pete

>- drivers/pcmcia/au1000_xxs1500.c: port to 2.6
>- Move include/asm-mips/xxs1500.h to include/asm-mips/mach-xxs1500/xxs1500.h
>
>No warranty on it, I don't trust my PCMCIA code entirely yet.
>
>From the original codebase:
>a) au_writel((au_readl(GPIO2_PINSTATE) & ~(1<<14))|(1<<30), GPIO2_OUTPUT);
>b) au_writel((au_readl(GPIO2_PINSTATE) | (1<<14))|(1<<30), GPIO2_OUTPUT);
>
>The 1<<14 indicates a specific location to set, and the 1<<30 says to
>enable output on that location.
>In arch/mips/au1000/xxs1500/board_setup.c, snippet a is commented as
>'turn off power'.
>In drivers/pcmcia/au1000_xxs1500.c, snippet a is commented as 'turn on
>power', and snippet b is commented as 'turn off power'.
>
>Your guess is as good as mine as to which does what.
>
>I've replaced them with two macros:
>XXS1500_GPIO2_PCMCIA_POWER_ON
>XXS1500_GPIO2_PCMCIA_POWER_OFF
>
>Due to the number of times they occur.
>
>  
>


From klessard@sunrisetelecom.com Mon Sep 27 21:37:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Sep 2004 21:37:07 +0100 (BST)
Received: from 67-121-164-6.ded.pacbell.net ([IPv6:::ffff:67.121.164.6]:43849
	"EHLO mailserver.sunrisetelecom.com") by linux-mips.org with ESMTP
	id <S8224935AbUI0UhD>; Mon, 27 Sep 2004 21:37:03 +0100
Received: from sunrisetelecom.com ([192.168.50.222]) by mailserver.sunrisetelecom.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 27 Sep 2004 13:36:57 -0700
Message-ID: <415879BF.3060802@sunrisetelecom.com>
Date: Mon, 27 Sep 2004 16:36:15 -0400
From: Karl Lessard <klessard@sunrisetelecom.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: 2.6 status for pb1100?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Sep 2004 20:36:57.0433 (UTC) FILETIME=[BB840C90:01C4A4D1]
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: 5905
X-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,

I'm working with a PB1100 board, and I try to run a linux 2.6 kernel. 
I've both try the kernel.org releases (2.6.8.1)and linux-mips CVS head.
While both fail due to many reasons, I've observed that some drivers 
have not been implemented or updated for kernel 2.6 series (for example
the au1100 framebuffer driver still use some kernel 2.4 headers).

My question is: Do PB1100 boards are officially supported by  2.6.x kernels?

Thanks,
Karl


From ppopov@embeddedalley.com Mon Sep 27 21:41:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Sep 2004 21:42:02 +0100 (BST)
Received: from web81008.mail.yahoo.com ([IPv6:::ffff:206.190.37.153]:46736
	"HELO web81008.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224935AbUI0Ul5>; Mon, 27 Sep 2004 21:41:57 +0100
Message-ID: <20040927204150.79545.qmail@web81008.mail.yahoo.com>
Received: from [216.98.102.225] by web81008.mail.yahoo.com via HTTP; Mon, 27 Sep 2004 13:41:50 PDT
X-RocketYMMF: pvpopov@pacbell.net
Date: Mon, 27 Sep 2004 13:41:50 -0700 (PDT)
From: Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
Subject: Re: 2.6 status for pb1100?
To: Karl Lessard <klessard@sunrisetelecom.com>,
	linux-mips@linux-mips.org
In-Reply-To: <415879BF.3060802@sunrisetelecom.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: 5906
X-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'm working with a PB1100 board, and I try to run a
> linux 2.6 kernel.  I've both try the 
> kernel.org releases (2.6.8.1)and linux-mips CVS 
> head. While both fail due to many reasons, 
> I've observed that some drivers have not 
> been implemented or updated for kernel 2.6
> series (for example the au1100 framebuffer 
> driver still use some kernel 2.4 headers).
> 
> My question is: Do PB1100 boards are officially
> supported by  2.6.x kernels?

Not yet, but we're working on it. Our target is the
Db1x boards, however, updating the Pb1x will be
trivial once the Pb1x are working. I have a bunch of
patches in my queue but won't be able to push them
until I get back from vacation. The FB driver is not
one of them though -- that comes later.

Pete

From hjl@lucon.org Mon Sep 27 23:17:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Sep 2004 23:17:57 +0100 (BST)
Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:56475 "EHLO
	rwcrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8224991AbUI0WRv>; Mon, 27 Sep 2004 23:17:51 +0100
Received: from lucon.org ([24.6.212.230]) by comcast.net (rwcrmhc13) with ESMTP
          id <20040927221743015008ul6de>; Mon, 27 Sep 2004 22:17:44 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 6ACFF63F8F; Mon, 27 Sep 2004 15:17:43 -0700 (PDT)
Date: Mon, 27 Sep 2004 15:17:43 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: linux-gcc@vger.kernel.org,
	GNU C Library <libc-alpha@sources.redhat.com>,
	gcc@gcc.gnu.org, 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.92.0.2 is released
Message-ID: <20040927221743.GA15346@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: 5907
X-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.92.0.2 for Linux, which is
based on binutils 2004 0927 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.

Please report any bugs related to binutils 2.15.92.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.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.92.0.2.tar.bz2. Source code.
2. binutils-2.15.91.0.2-2.15.92.0.2.diff.bz2. Patch against the
   previous beta source code.
3. binutils-2.15.92.0.2-1.i386.rpm. IA-32 binary RPM for RedHat EL 3.
4. binutils-2.15.92.0.2-1.ia64.rpm. IA-64 binary RPM for RedHat EL 3.
5. binutils-2.15.92.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.92.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
09/27/2004

From smm@futarque.com Tue Sep 28 10:11:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Sep 2004 10:11:53 +0100 (BST)
Received: from futarque.com ([IPv6:::ffff:212.242.80.58]:60563 "HELO
	mail.futarque.com") by linux-mips.org with SMTP id <S8224918AbUI1JLs>;
	Tue, 28 Sep 2004 10:11:48 +0100
Received: (qmail 883 invoked by uid 64014); 28 Sep 2004 09:11:40 -0000
Received: from smm@futarque.com by mail by uid 64011 with qmail-scanner-1.16 
 (uvscan: v4.1.60/v4278. spamassassin: 2.63.   Clear:. 
 Processed in 0.23807 secs); 28 Sep 2004 09:11:40 -0000
Received: from excalibur.futarque.com (192.168.2.15)
  by mail.futarque.com with SMTP; 28 Sep 2004 09:11:40 -0000
Subject: Problem debugging multi-threaded app
From: Steffen Malmgaard Mortensen <smm@futarque.com>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Message-Id: <1096362700.5227.19.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Tue, 28 Sep 2004 11:11:40 +0200
Content-Transfer-Encoding: 7bit
Return-Path: <smm@futarque.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5908
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: smm@futarque.com
Precedence: bulk
X-list: linux-mips

Hi all,

I'm trying to debug a multi-threaded app using gdbserver/gdb. I see the
same problems as described in
http://www.linux-mips.org/archives/linux-mips/2002-09/msg00155.html -
the program receives SIG32, but gdb doesn't associate that with thread
creation. The solution back in 2002 was to upgrade the tool-chain, but
I'm not sure what versions I should use today (and what patches). I'm
currently using:

CPU: Ati X225 (mips4kc - little endian)
kernel: linux 2.4.18 + vendor patches

glibc: 2.3.2
gcc: 3.3.2
binutils: 2.14
(the three above from crosstool 0.27)

gdb/gdbserver: 6.2

According to strace gdbserver loads libthread_db as it should, but gdb
on my host doesn't load libthread_db.

Any help/suggestions will be greatly appriciated...

Best regards,
Steffen



From thomas@the-doors.enix.org Tue Sep 28 11:08:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Sep 2004 11:08:42 +0100 (BST)
Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:54428 "EHLO
	the-doors.enix.org") by linux-mips.org with ESMTP
	id <S8224921AbUI1KIh>; Tue, 28 Sep 2004 11:08:37 +0100
Received: by the-doors.enix.org (Postfix, from userid 1105)
	id E6A501EFE4; Tue, 28 Sep 2004 12:08:31 +0200 (CEST)
Date: Tue, 28 Sep 2004 12:08:31 +0200
From: Thomas Petazzoni <thomas.petazzoni@enix.org>
To: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org, mentre@tcl.ite.mee.com
Subject: How to handle a specific DMA configuration ?
Message-ID: <20040928100831.GI27756@enix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <thomas@the-doors.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: 5909
X-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

Hello,

[As I'm not subscribed the list, please include me in Cc: for answers]

I am currently porting 2.6 to a home-made MIPS-based platform using
the MIPS RM9000 processor and the Marvell memory/uart/ethernet
controller.

My physical memory mapping is a bit special : I have 384 MB of
memory. The first 256MB are directly connected to the RM9000, while
the last 128MB are connected to the Marvell controller. _Only_ the
last 128MB are usable for DMA (especially for network traffic). For
the moment, Linux only takes care of the first 256MB, but I can change
it to take care of the complete physical memory space (384 MB).

My problem is the allocation of skbuff. They are allocated using
alloc_skb() in net/core/skbuff.c, and uses the "normal" kmalloc()
allocator. kmalloc() will allocate memory somewhere in the physical
memory space : even if a I allow Linux to allocate memory between
256MB and 384MB, I cannot be sure that it will use memory in this
space to allocate skbuff. If skbuff are not allocated in this space,
then I can't use DMA to transfer the buffers.

As I understand the ZONE_DMA thing, it allows to tell Linux that a
physical memory region located between 0 and some value (16 MB on PCs
for old ISA cards compatibility) is the only area usable for DMA. How
could I declare my 256MB-384MB physical memory reagion to be the only
area usable for DMA ? How can I tell the skbuff functions to allocate
_only_ DMA-able memory ? Moreover, can I make assumptions on the
alignement of final data at the bottom of the network stack (my DMA
controller doesn't like the 2 byte-aligned things).

At the moment, I see only three solutions. The two first aren't not
very satisfying, the third might be a solution, but not perfect
neither (and not sure it would work).

 1) Implement a home-made memory allocator dedicated to the allocation
    of DMA buffers inside the 256MB-384MB space. Then modify the
    net/core/skbuff.c functions to use this allocator to allocate/free
    the contents (skb->data) of the skbuffs. I'm not sure that it will
    work, but at least, it involves the modification of
    architecture-independent code for an architecture-dependent
    reason. 

 2) Modify the Marvell Ethernet driver (drivers/net/mv64340_eth.c) to
    change the calls to pci_map_single() and
    pci_unmap_single(). The pci_map_single() would allocate (through a
    dedicated home-made allocator) a DMA buffer, and copy the contents
    of the skbuf to the DMA buffer. The pci_unmap_single() would copy
    the contents of the DMA buffer back to the skb->data buffer. I'm
    quite sure this would work (this is how the 2.4 port that I have
    for this platform work), but it involves the modification of the
    Ethernet driver, and above all, a performance hit.

 3) Modify net/core/skbuf.c to make sure all kmalloc()'ed areas (for
    skbuff contents) are allocated with the GFP_DMA flag. Then, modify
    the arch/mips/mm/init.c file to make sure the first 256MB physical
    pages don't have the DMA bit, and that the next 128MB will have it
    (not sure on how complex it is).

Are there any other solutions available ? If not, which of the
proposed solutions is the best ?

If my problem is unclear, don't hesitate to ask for further details,

Thanks,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org 
http://thomas.enix.org - Jabber: kos_tom@sourcecode.de
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

From macro@linux-mips.org Tue Sep 28 21:57:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Sep 2004 21:57:16 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:57604 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225073AbUI1U5L>; Tue, 28 Sep 2004 21:57:11 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id CD410F5A69; Tue, 28 Sep 2004 22:57:01 +0200 (CEST)
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 07233-04; Tue, 28 Sep 2004 22:57:01 +0200 (CEST)
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 7DA6BE1C7D; Tue, 28 Sep 2004 22:57:01 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.12.11/8.12.11) with ESMTP id i8SKvGLX032064;
	Tue, 28 Sep 2004 22:57:18 +0200
Date: Tue, 28 Sep 2004 21:57:04 +0100 (BST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Thomas Petazzoni <thomas.petazzoni@enix.org>
Cc: linux-mips@linux-mips.org, mentre@tcl.ite.mee.com
Subject: Re: Questions regarding MIPS platforms boot process
In-Reply-To: <20040915072337.GX6242@enix.org>
Message-ID: <Pine.LNX.4.58L.0409281640200.32231@blysk.ds.pg.gda.pl>
References: <20040915072337.GX6242@enix.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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: 5910
X-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 Sep 2004, Thomas Petazzoni wrote:

> 2) Mips_hpt_frequency
> 
> I'm not sure whether my board_time_init() function should set
> mips_hpt_frequency or not. In arch/mips/kernel/time.c, it is said that :
> 
>  *      b) (optional) calibrate and set the mips_hpt_frequency
>  *	    (only needed if you intended to use fixed_rate_gettimeoffset
>  *	     or use cpu counter as timer interrupt source)
> 
> So it doesn't seem to be mandatory, but actually I do not understand
> clearly the two cases for which setting mips_hpt_frequency is mandatory.
> I don't think I want to use fixed_rate_gettimeoffset, but I'm not sure
> with the second usage.

 If you want to use a HPT at all, then you do want to use
fixed_rate_gettimeoffset().  The calibrate_div32_gettimeoffset() and
calibrate_div64_gettimeoffset() backends are considered obsolete and will
be removed.  That's the first case.

 The other is when you use the CP0's internal timer as a source of timer 
interrupts.

> When I read the code of arch/mips/kernel/time.c, function time_init()
> around line 701, I can see that if no value has been set to
> mips_hpt_frequency, then it is computed by the calibrate_hpt(). So, when
> is it needed to set it ?

 You only need to set mips_hpt_frequency manually if there's no way do
determine the timer's frequency automatically.  This is usually the case,
when there is no reference timer in the system, e.g. you only have the
CP0's internal timer, but you know the timer's frequency.  But you are
free do that even if you have a reference timer, but using the generic 
calibration code would be too complicated to set up.

 Otherwise, you need to set the mips_timer_state function pointer to make
the code set up mips_hpt_frequency automagically.  The function has to
report a the state of the timer in such a way, that there are HZ 0 to 1
transitions per second with equal intervals.  Typically it would just read 
the state of an interrupt output from the device providing timer 
interrupts, but actually it's up to you how you implement it.

> FYI, the platform I'm working on doesn't have any external timer source.

 You need to set mips_hpt_frequency somehow, then.  If your CPU's clock is
fixed for all devices, then you can simply hardcode the frequency.  If the
clock varies and there's absolutely no way to determine it, you may ask
the user to enter the value valid for his system during kernel
configuration.

> What's the exact use of the mips_hpt_frequency ? Should I set it or not
> ?

 If you use the CP0's internal timer, then mips_hpt_frequency is used to
setup the timer's interval.  The resulting interval is expected to be 1/HZ
and it is the base of the system time, both for scheduling and for
timekeeping.

 If you don't use the CP0's internal timer, and you have an external timer
device (such as an RTC chip), then mips_hpt_frequency is optional,
although still recommended.  It's used to provide a finer granularity for 
timekeeping (gettimeofday() and friends).

  Maciej

From smm@futarque.com Wed Sep 29 07:14:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Sep 2004 07:15:03 +0100 (BST)
Received: from futarque.com ([IPv6:::ffff:212.242.80.58]:41631 "HELO
	mail.futarque.com") by linux-mips.org with SMTP id <S8224838AbUI2GO6>;
	Wed, 29 Sep 2004 07:14:58 +0100
Received: (qmail 8986 invoked by uid 64014); 29 Sep 2004 06:14:50 -0000
Received: from smm@futarque.com by mail by uid 64011 with qmail-scanner-1.16 
 (uvscan: v4.1.60/v4278. spamassassin: 2.63.   Clear:. 
 Processed in 0.245475 secs); 29 Sep 2004 06:14:50 -0000
Received: from excalibur.futarque.com (192.168.2.15)
  by mail.futarque.com with SMTP; 29 Sep 2004 06:14:50 -0000
Subject: Re: Problem debugging multi-threaded app
From: Steffen Malmgaard Mortensen <smm@futarque.com>
To: linux-mips@linux-mips.org
In-Reply-To: <1096362700.5227.19.camel@localhost>
References: <1096362700.5227.19.camel@localhost>
Content-Type: multipart/alternative; boundary="=-gh6R7eefsOFBcBFX4ZAh"
Message-Id: <1096438490.5227.24.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Wed, 29 Sep 2004 08:14:50 +0200
Return-Path: <smm@futarque.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5911
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: smm@futarque.com
Precedence: bulk
X-list: linux-mips


--=-gh6R7eefsOFBcBFX4ZAh
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi again,
Sorry - I know I shouldn't even be allowed to ask questions...... It was
another old, known bug - I was running with stripped libpthread......
/Steffen


On Tue, 2004-09-28 at 11:11, Steffen Malmgaard Mortensen wrote:

> Hi all,
> 
> I'm trying to debug a multi-threaded app using gdbserver/gdb. I see the
> same problems as described in
> http://www.linux-mips.org/archives/linux-mips/2002-09/msg00155.html -
> the program receives SIG32, but gdb doesn't associate that with thread
> creation. The solution back in 2002 was to upgrade the tool-chain, but
> I'm not sure what versions I should use today (and what patches). I'm
> currently using:
> 
> CPU: Ati X225 (mips4kc - little endian)
> kernel: linux 2.4.18 + vendor patches
> 
> glibc: 2.3.2
> gcc: 3.3.2
> binutils: 2.14
> (the three above from crosstool 0.27)
> 
> gdb/gdbserver: 6.2
> 
> According to strace gdbserver loads libthread_db as it should, but gdb
> on my host doesn't load libthread_db.
> 
> Any help/suggestions will be greatly appriciated...
> 
> Best regards,
> Steffen
> 
> 
> 

--=-gh6R7eefsOFBcBFX4ZAh
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.0.10">
</HEAD>
<BODY>
Hi again,<BR>
Sorry - I know I shouldn't even be allowed to ask questions...... It was another old, known bug - I was running with stripped libpthread......<BR>
/Steffen<BR>
<BR>
<BR>
On Tue, 2004-09-28 at 11:11, Steffen Malmgaard Mortensen wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>Hi all,

I'm trying to debug a multi-threaded app using gdbserver/gdb. I see the
same problems as described in</FONT>
<A HREF="http://www.linux-mips.org/archives/linux-mips/2002-09/msg00155.html"><U>http://www.linux-mips.org/archives/linux-mips/2002-09/msg00155.html</U></A><FONT COLOR="#737373"> -
the program receives SIG32, but gdb doesn't associate that with thread
creation. The solution back in 2002 was to upgrade the tool-chain, but
I'm not sure what versions I should use today (and what patches). I'm
currently using:

CPU: Ati X225 (mips4kc - little endian)
kernel: linux 2.4.18 + vendor patches

glibc: 2.3.2
gcc: 3.3.2
binutils: 2.14
(the three above from crosstool 0.27)

gdb/gdbserver: 6.2

According to strace gdbserver loads libthread_db as it should, but gdb
on my host doesn't load libthread_db.

Any help/suggestions will be greatly appriciated...

Best regards,
Steffen


</I></FONT></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-gh6R7eefsOFBcBFX4ZAh--


From sagogate@yahoo.com Wed Sep 29 09:05:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Sep 2004 09:05:50 +0100 (BST)
Received: from web60707.mail.yahoo.com ([IPv6:::ffff:216.109.117.230]:33129
	"HELO web60707.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224920AbUI2IFn>; Wed, 29 Sep 2004 09:05:43 +0100
Message-ID: <20040929080531.85660.qmail@web60707.mail.yahoo.com>
Received: from [61.11.17.69] by web60707.mail.yahoo.com via HTTP; Wed, 29 Sep 2004 01:05:31 PDT
Date: Wed, 29 Sep 2004 01:05:31 -0700 (PDT)
From: Shantanu Gogate <sagogate@yahoo.com>
Subject: MIPS kernel emulator issues
To: baitisj@evolution.org, jdl@vivato.net
Cc: uclibc@uclibc.org, linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <sagogate@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: 5912
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sagogate@yahoo.com
Precedence: bulk
X-list: linux-mips

Guys,

Any pointers which will lead to explaining why I am getting segmentation fault and kernel
stacktraces on floating point instructions being generated through uClibc would be appreciated.

I found this thread involving Jeff and Jon a bit relevant to my problem. Hence mailing them
directly.
http://www.uclibc.org/lists/uclibc/2003-June/006379.html

This thread started by Jon is almost exactly my problem, but I dont see any replies to that post.
http://www.uclibc.org/lists/uclibc/2003-May/006182.html
Both these posts are over an year old.

The situation here is as follows:

I have 2 boards based on a 4Kc MIPS core. One on which we have
successfully ported everything from booloader to applications. The other
is almost similar to this one (the Processor core is the same), just the
things around like RAM,Flash chip, ENET PHY are different. We are using
cross compiler gcc (version 3.3.4) along with uClibc, kernel 2.4.25. Everything is working fine on
platform #1. The kernel as well as the userland applications are all compiled with the same gcc
cross compiler (version 3.3.4)

a) on platform #2 when I run any program which calls any function from
uClibc which uses floating point numbers you get a kernel stack trace
saying "Reserved instruction in kernel code in traps.c::do_ri, line 663"
and a lengthy stack trace follows.

b) the same static binary which just does z = x *y, where x,y,z are floats and prints two floating
point numbers runs fine on platform #1.

c) If I remove the "printf" and just write the floating point arithmetic
instructions ( i.e something like z = x*y ). I dont get the stack trace on platform #2 or #1

d) If I statically link this small program with glibc instead, it works
fine on platform #2 _and_ #1.

e) If I load the platform #2 with a kernel image over tftp from a remote machine
where the rootfs is embedded inside the kernel image itself, then the
dummy program linked with uClibc or glibc works fine ..no stacktrace !!!

If "e)" was not happening i.e the embedded ramdisk rootfs was also giving same
problems then one could have said that it was something to do with
incorrect compilation of uClibc itself, which is why it was working with
glibc but not with uClibc. However programs linked with the same uClibc
are working when the embedded rootfs kernel is loaded. How ?!? Why ?!! 

uClibc configuration is to have floating point support and "HAS_FPU=y". If I change "HAS_FPU=n"
then it does compile with "-msoft-float", however the printf output from the dummy program is just
"nan".


Regards,
Shantanu




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

From sara@procsys.com Thu Sep 30 06:47:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Sep 2004 06:48:00 +0100 (BST)
Received: from [IPv6:::ffff:202.9.170.7] ([IPv6:::ffff:202.9.170.7]:930 "EHLO
	trishul.procsys.com") by linux-mips.org with ESMTP
	id <S8224916AbUI3Fry>; Thu, 30 Sep 2004 06:47:54 +0100
Received: from [192.168.1.36] ([192.168.1.36])
	by trishul.procsys.com (8.12.10/8.12.10) with ESMTP id i8U5iSGG006671
	for <linux-mips@linux-mips.org>; Thu, 30 Sep 2004 11:14:32 +0530
Message-ID: <415B9CD2.3070607@procsys.com>
Date: Thu, 30 Sep 2004 11:12:42 +0530
From: "T. P. Saravanan" <sara@procsys.com>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: mips linux glibc-2.3.3 build - opcode not supported problem
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ProcSys-Com-Anti-Virus-Mail-Filter-Virus-Found: no
Return-Path: <sara@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: 5913
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sara@procsys.com
Precedence: bulk
X-list: linux-mips

Hi,

I hope it is OK to post linux mips glibc build problems here.  If not, 
please let me
know an appropriate forum.

---

Host type: mipsel-unknown-linux-gnu
System: Linux eyeore 2.4.25 #20 Wed Sep 29 09:01:29 IST 2004 mips unknown
Architecture: mips

Addons: linuxthreads
Build CFLAGS: -g -O2
Build CC: gcc
Compiler version: 3.4.2
Kernel headers: 2.4.25
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: yes
Build profile: yes
Build omitfp: no
Build bounded: no
Build static-nss: no

sara@eyeore:~/tmp$ cat /proc/cpuinfo
system type             : ITE QED-4N-S01B
processor               : 0
cpu model               : Nevada V3.1  FPU V3.0
BogoMIPS                : 299.00
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 48
extra interrupt vector  : yes
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available
sara@eyeore:~/tmp$

This is how the build dies:
.
.
.
gcc -mabi=32 ../sysdeps/unix/sysv/linux/mips/_test_and_set.c -c 
-std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings 
-g      -I../include -I. -I/home/sara/build/glibc/objdir/misc -I.. 
-I../libio  -I/home/sara/build/glibc/objdir -I../sysdeps/mips/elf 
-I../linuxthreads/sysdeps/unix/sysv/linux/mips 
-I../linuxthreads/sysdeps/unix/sysv/linux 
-I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread 
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix 
-I../linuxthreads/sysdeps/mips -I../sysdeps/unix/sysv/linux/mips/mips32 
-I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/linux 
-I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman 
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv 
-I../sysdeps/unix/mips/mips32 -I../sysdeps/unix/mips -I../sysdeps/unix 
-I../sysdeps/posix -I../sysdeps/mips/mips32 -I../sysdeps/mips 
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 
-I../sysdeps/wordsize-32 -I../sysdeps/mips/fpu -I../sysdeps/ieee754 
-I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem 
/home/sara/usr/local/lib/gcc/mipsel-unknown-linux-gnu/3.4.2/include 
-isystem /home/sara/build/linux/linux-2.4.25mips/include 
-D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC     -o 
/home/sara/build/glibc/objdir/misc/_test_and_set.o -MD -MP -MF 
/home/sara/build/glibc/objdir/misc/_test_and_set.o.dt

/tmp/ccDGPHmY.s: Assembler messages:
/tmp/ccDGPHmY.s:28: Error: opcode not supported on this processor: mips1 
(mips1) `ll $2,0($4)'
/tmp/ccDGPHmY.s:31: Error: opcode not supported on this processor: mips1 
(mips1) `sc $3,0($4)'
make[2]: *** [/home/sara/build/glibc/objdir/misc/_test_and_set.o] Error 1
make[2]: Leaving directory `/home/sara/build/glibc/glibc-2.3.3/misc'
make[1]: *** [misc/subdir_lib] Error 2
make[1]: Leaving directory `/home/sara/build/glibc/glibc-2.3.3'
make: *** [all] Error 2

sara@eyeore:~/build/glibc/objdir$



The problem seems to go away if I put CFLAGS="-mips4 -O2 -g".  Is it OK 
to do this?
Why did gcc/gas fail to use -mips4 opcodes by default?

-Saravanan



From mlachwani@mvista.com Thu Sep 30 17:56:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Sep 2004 17:56:34 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:8181 "EHLO
	hermes.mvista.com") by linux-mips.org with ESMTP
	id <S8225248AbUI3Q43>; Thu, 30 Sep 2004 17:56:29 +0100
Received: from mvista.com (prometheus.mvista.com [10.0.0.139])
	by hermes.mvista.com (Postfix) with ESMTP id 00C47184FD
	for <linux-mips@linux-mips.org>; Thu, 30 Sep 2004 09:56:27 -0700 (PDT)
Message-ID: <415C3ABA.6080601@mvista.com>
Date: Thu, 30 Sep 2004 09:56:26 -0700
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
Subject: [PATCH] 64-bit on Broadcom SWARM
Content-Type: multipart/mixed;
 boundary="------------070803090608090509040003"
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: 5914
X-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

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

Hello !

Attached patch gets the 64-bit to work on the Broadcom SWARM.

Thanks
Manish

--------------070803090608090509040003
Content-Type: text/plain;
 name="patch-swarm"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch-swarm"

--- arch/mips/Makefile.orig	2004-09-30 09:49:45.000000000 -0700
+++ arch/mips/Makefile	2004-09-30 09:50:27.000000000 -0700
@@ -35,7 +35,7 @@
 endif
 ifdef CONFIG_MIPS64
 gcc-abi			= 64
-gas-abi			= 32
+gas-abi			= 64
 tool-prefix		= $(64bit-tool-prefix)
 UTS_MACHINE		:= mips64
 endif
@@ -580,7 +580,11 @@
 libs-$(CONFIG_SIBYTE_SENTOSA)	+= arch/mips/sibyte/swarm/
 load-$(CONFIG_SIBYTE_SENTOSA)	:= 0x80100000
 libs-$(CONFIG_SIBYTE_SWARM)	+= arch/mips/sibyte/swarm/
+ifdef CONFIG_MIPS64
+load-$(CONFIG_SIBYTE_SWARM)	:= 0xffffffff80100000
+else
 load-$(CONFIG_SIBYTE_SWARM)	:= 0x80100000
+endif
 
 #
 # SNI RM200 PCI
@@ -651,7 +655,11 @@
 AFLAGS		+= $(cflags-y)
 CFLAGS		+= $(cflags-y)
 
+ifdef CONFIG_MIPS64
+LDFLAGS			+= --oformat $(64bit-bfd)
+else
 LDFLAGS			+= --oformat $(32bit-bfd)
+endif
 
 head-y := arch/mips/kernel/head.o arch/mips/kernel/init_task.o
 
--- arch/mips/Kconfig.orig	2004-09-30 09:49:51.000000000 -0700
+++ arch/mips/Kconfig	2004-09-30 09:50:34.000000000 -0700
@@ -1076,7 +1076,7 @@
 
 config BOOT_ELF64
 	bool
-	depends on SGI_IP27
+	depends on SGI_IP27 || SIBYTE_SB1xxx_SOC
 	default y
 
 #config MAPPED_PCI_IO y
--- arch/mips/sibyte/sb1250/irq_handler.S.orig	2004-09-30 09:50:03.000000000 -0700
+++ arch/mips/sibyte/sb1250/irq_handler.S	2004-09-30 09:50:58.000000000 -0700
@@ -123,7 +123,11 @@
 	 * check the 1250 interrupt registers to figure out what to do
 	 * Need to detect which CPU we're on, now that smp_affinity is supported.
 	 */
+#ifdef CONFIG_MIPS64
+	PTR_LA	v0, CKSEG1 + A_IMR_CPU0_BASE
+#else
 	PTR_LA	v0, KSEG1 + A_IMR_CPU0_BASE
+#endif
 #ifdef CONFIG_SMP
 	lw	t1, TI_CPU($28)
 	sll	t1, IMR_REGISTER_SPACING_SHIFT
--- arch/mips/mm/c-sb1.c.orig	2004-09-30 09:50:15.000000000 -0700
+++ arch/mips/mm/c-sb1.c	2004-09-30 09:50:43.000000000 -0700
@@ -488,7 +488,11 @@
 	/* Special cache error handler for SB1 */
 	memcpy((void *)(CAC_BASE   + 0x100), &except_vec2_sb1, 0x80);
 	memcpy((void *)(UNCAC_BASE + 0x100), &except_vec2_sb1, 0x80);
+#ifdef CONFIG_MIPS64
+	memcpy((void *)CKSEG1ADDR(&handle_vec2_sb1), &handle_vec2_sb1, 0x80);
+#else
 	memcpy((void *)KSEG1ADDR(&handle_vec2_sb1), &handle_vec2_sb1, 0x80);
+#endif
 
 	probe_cache_sizes();
 

--------------070803090608090509040003--


From macro@linux-mips.org Thu Sep 30 18:36:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Sep 2004 18:36:55 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:14094 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225248AbUI3Rgv>; Thu, 30 Sep 2004 18:36:51 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 91551F5DC1; Thu, 30 Sep 2004 19:36:44 +0200 (CEST)
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 02933-04; Thu, 30 Sep 2004 19:36:44 +0200 (CEST)
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 2EB47F5DB7; Thu, 30 Sep 2004 19:36:44 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.12.11/8.12.11) with ESMTP id i8UHavl6020798;
	Thu, 30 Sep 2004 19:36:58 +0200
Date: Thu, 30 Sep 2004 18:36:47 +0100 (BST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Manish Lachwani <mlachwani@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] 64-bit on Broadcom SWARM
In-Reply-To: <415C3ABA.6080601@mvista.com>
Message-ID: <Pine.LNX.4.58L.0409301823290.25286@blysk.ds.pg.gda.pl>
References: <415C3ABA.6080601@mvista.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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: 5915
X-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, 30 Sep 2004, Manish Lachwani wrote:

> Attached patch gets the 64-bit to work on the Broadcom SWARM.

 Inline, please!

> --- arch/mips/Makefile.orig	2004-09-30 09:49:45.000000000 -0700
> +++ arch/mips/Makefile	2004-09-30 09:50:27.000000000 -0700
> @@ -35,7 +35,7 @@
>  endif
>  ifdef CONFIG_MIPS64
>  gcc-abi			= 64
> -gas-abi			= 32
> +gas-abi			= 64
>  tool-prefix		= $(64bit-tool-prefix)
>  UTS_MACHINE		:= mips64
>  endif

 I won't particularly mind having this change in, but there are apparently
people who want to have the current setting preserved.  So I doubt this
part is going to be accepted.  Please use `make "gas-abi=64" <whatever>'
instead.

 Alternatively, please let me check if I can get some time to implement 
one of my to-do list goals, that is having it configurable.

> @@ -580,7 +580,11 @@
>  libs-$(CONFIG_SIBYTE_SENTOSA)	+= arch/mips/sibyte/swarm/
>  load-$(CONFIG_SIBYTE_SENTOSA)	:= 0x80100000
>  libs-$(CONFIG_SIBYTE_SWARM)	+= arch/mips/sibyte/swarm/
> +ifdef CONFIG_MIPS64
> +load-$(CONFIG_SIBYTE_SWARM)	:= 0xffffffff80100000
> +else
>  load-$(CONFIG_SIBYTE_SWARM)	:= 0x80100000
> +endif
>  
>  #
>  # SNI RM200 PCI

 I think 32-bit tools may be able to cope with 0xffffffff80100000, so you 
wouldn't need this conditional.  Actually some 32-bit can't really cope 
with something like 0x80100000, grr...  Cf. objdump.

> @@ -651,7 +655,11 @@
>  AFLAGS		+= $(cflags-y)
>  CFLAGS		+= $(cflags-y)
>  
> +ifdef CONFIG_MIPS64
> +LDFLAGS			+= --oformat $(64bit-bfd)
> +else
>  LDFLAGS			+= --oformat $(32bit-bfd)
> +endif
>  
>  head-y := arch/mips/kernel/head.o arch/mips/kernel/init_task.o
>  

 See the comment about gas-abi -- you can override 32bit-bfd. ;-)

> --- arch/mips/Kconfig.orig	2004-09-30 09:49:51.000000000 -0700
> +++ arch/mips/Kconfig	2004-09-30 09:50:34.000000000 -0700
> @@ -1076,7 +1076,7 @@
>  
>  config BOOT_ELF64
>  	bool
> -	depends on SGI_IP27
> +	depends on SGI_IP27 || SIBYTE_SB1xxx_SOC
>  	default y
>  

 And this is another part to be configurable in general.  E.g. I use
64-bit ELF for 64-bit DECstations, too, but others may prefer 32-bit
binaries.

  Maciej

From ralf@linux-mips.org Thu Sep 30 20:59:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Sep 2004 20:59:14 +0100 (BST)
Received: from p508B778C.dip.t-dialin.net ([IPv6:::ffff:80.139.119.140]:40978
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225254AbUI3T7J>; Thu, 30 Sep 2004 20:59:09 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i8UJx5MC013148;
	Thu, 30 Sep 2004 21:59:05 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i8UJx32g013147;
	Thu, 30 Sep 2004 21:59:03 +0200
Date: Thu, 30 Sep 2004 21:59:03 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Thomas Petazzoni <thomas.petazzoni@enix.org>
Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org,
	mentre@tcl.ite.mee.com
Subject: Re: How to handle a specific DMA configuration ?
Message-ID: <20040930195903.GB4368@linux-mips.org>
References: <20040928100831.GI27756@enix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040928100831.GI27756@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: 5916
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Sep 28, 2004 at 12:08:31PM +0200, Thomas Petazzoni wrote:

> My physical memory mapping is a bit special : I have 384 MB of
> memory. The first 256MB are directly connected to the RM9000, while
> the last 128MB are connected to the Marvell controller. _Only_ the
> last 128MB are usable for DMA (especially for network traffic). For
> the moment, Linux only takes care of the first 256MB, but I can change
> it to take care of the complete physical memory space (384 MB).
> 
> My problem is the allocation of skbuff. They are allocated using
> alloc_skb() in net/core/skbuff.c, and uses the "normal" kmalloc()
> allocator. kmalloc() will allocate memory somewhere in the physical
> memory space : even if a I allow Linux to allocate memory between
> 256MB and 384MB, I cannot be sure that it will use memory in this
> space to allocate skbuff. If skbuff are not allocated in this space,
> then I can't use DMA to transfer the buffers.
> 
> As I understand the ZONE_DMA thing, it allows to tell Linux that a
> physical memory region located between 0 and some value (16 MB on PCs
> for old ISA cards compatibility) is the only area usable for DMA. How
> could I declare my 256MB-384MB physical memory reagion to be the only
> area usable for DMA ? How can I tell the skbuff functions to allocate
> _only_ DMA-able memory ?

ZONE_DMA has a system specific meaning.  On a PCI system ISA could always
be exist through a PCI-to-ISA bridge, so you can't just go and give it
a system specific meaning.  It's also needed for PCI devices with a
less than 32-bit DMA limit; those exist in a rich variety.

> Moreover, can I make assumptions on the
> alignement of final data at the bottom of the network stack (my DMA
> controller doesn't like the 2 byte-aligned things).

Well, if you put packets on an aligned address you'll later take a bunch
of missalignment exceptions which are going to severly impact networking
performance ...

> At the moment, I see only three solutions. The two first aren't not
> very satisfying, the third might be a solution, but not perfect
> neither (and not sure it would work).

Change the configuration of the board to put the MV memory at the bottom.
Leave ZONE_DMA what it used to be, < 16MB.  Set the ZONE_NORMAL limit to
128MB.  Anything above that is non-dmable will go into ZONE_HIGHMEM.
See also CONFIG_LIMITED_DMA in 2.6.  It works, it has little compatibility
problems but it's a solution for platform that simply doesn't reflect the
Linux hw architecture very much ...

  Ralf