From jbglaw@dvmwest.gt.owl.de Sun Jun  1 15:25:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Jun 2003 15:25:58 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:10258 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8224827AbTFAOZ4>; Sun, 1 Jun 2003 15:25:56 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id B0A554ABBC; Sun,  1 Jun 2003 16:25:53 +0200 (CEST)
Date: Sun, 1 Jun 2003 16:25:53 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030601142553.GA6935@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030601120750Z8225197-1272+2136@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="E8vXRijW3SOTujIP"
Content-Disposition: inline
In-Reply-To: <20030601120750Z8225197-1272+2136@linux-mips.org>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
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: 2485
X-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


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

On Sun, 2003-06-01 13:07:46 +0100, ralf@linux-mips.org <ralf@linux-mips.org>
wrote in message <20030601120750Z8225197-1272+2136@linux-mips.org>:

> Log message:
> 	Merge with Linux 2.5.50.

Today's hero: Bacchus!

MfG, JBG
PS: Thinking about feeding arch with Linus' tree, the parisc one and
l-m.org's CVS tree just to evaluate if the holy merge can be done at all
(cf. http://www.lug-owl.de/~jbglaw/linux-ports/ ).

Currently, I'm thinking about a 2.5.<x>-port<n> tree which I basically
plan to feed by CVS/bk/... log mails. While at it, I'm asking for a list
which gets complete log incl. patch sent to.

Bacchus?

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

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

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

iD8DBQE+2gzxHb1edYOZ4bsRAh6FAJ0Z7OQgnkqpO3WPR3UD6VVKC0WScgCbBzxd
Atl1YlAd55bKpWHnVGziGOQ=
=FpGS
-----END PGP SIGNATURE-----

--E8vXRijW3SOTujIP--

From ralf@linux-mips.org Sun Jun  1 16:56:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Jun 2003 16:56:37 +0100 (BST)
Received: from p508B658A.dip.t-dialin.net ([IPv6:::ffff:80.139.101.138]:23208
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224827AbTFAP4f>; Sun, 1 Jun 2003 16:56:35 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h51FuWbY027793
	for <linux-mips@linux-mips.org>; Sun, 1 Jun 2003 08:56:32 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h51FuTI2027792
	for linux-mips@linux-mips.org; Sun, 1 Jun 2003 17:56:29 +0200
Date: Sun, 1 Jun 2003 17:56:29 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030601155629.GA26900@linux-mips.org>
References: <20030601120750Z8225197-1272+2136@linux-mips.org> <20030601142553.GA6935@lug-owl.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030601142553.GA6935@lug-owl.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: 2486
X-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 Sun, Jun 01, 2003 at 04:25:53PM +0200, Jan-Benedict Glaw wrote:

> MfG, JBG
> PS: Thinking about feeding arch with Linus' tree, the parisc one and
> l-m.org's CVS tree just to evaluate if the holy merge can be done at all
> (cf. http://www.lug-owl.de/~jbglaw/linux-ports/ ).

Please don't feed anything that's maintained on linux-mips.org to Linus.
Having to sort out what of all the patches flowing forward and backward
is bogus and not would become a huge pain for me.

> Currently, I'm thinking about a 2.5.<x>-port<n> tree which I basically
> plan to feed by CVS/bk/... log mails. While at it, I'm asking for a list
> which gets complete log incl. patch sent to.

An item on my to do list since a long time ...

  Ralf

From jbglaw@dvmwest.gt.owl.de Sun Jun  1 17:10:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Jun 2003 17:10:10 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:3845 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8224827AbTFAQKI>; Sun, 1 Jun 2003 17:10:08 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id BCD6E4ABAB; Sun,  1 Jun 2003 18:10:06 +0200 (CEST)
Date: Sun, 1 Jun 2003 18:10:06 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030601161006.GB6935@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030601120750Z8225197-1272+2136@linux-mips.org> <20030601142553.GA6935@lug-owl.de> <20030601155629.GA26900@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="EZN6irWB3fS+DSGO"
Content-Disposition: inline
In-Reply-To: <20030601155629.GA26900@linux-mips.org>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
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: 2487
X-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


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

On Sun, 2003-06-01 17:56:29 +0200, Ralf Baechle <ralf@linux-mips.org>
wrote in message <20030601155629.GA26900@linux-mips.org>:
> On Sun, Jun 01, 2003 at 04:25:53PM +0200, Jan-Benedict Glaw wrote:
>=20
> > MfG, JBG
> > PS: Thinking about feeding arch with Linus' tree, the parisc one and
> > l-m.org's CVS tree just to evaluate if the holy merge can be done at all
> > (cf. http://www.lug-owl.de/~jbglaw/linux-ports/ ).
>=20
> Please don't feed anything that's maintained on linux-mips.org to Linus.
> Having to sort out what of all the patches flowing forward and backward
> is bogus and not would become a huge pain for me.

I do know that and I'm for sure far away from pushing patches upwards.
_But_ I want to pull things. This way, I can *early* unhide problems
some archs imply to common code and thus I can ask their maintainers to
not let major (upcoming) problems out of their eyes...

> > Currently, I'm thinking about a 2.5.<x>-port<n> tree which I basically
> > plan to feed by CVS/bk/... log mails. While at it, I'm asking for a list
> > which gets complete log incl. patch sent to.
>=20
> An item on my to do list since a long time ...

Here's even some requestor! That'd help me a lot, I think.

Ralf, you've been a fire fighter, right? I'm near over-heating just
right now...

MfG, JBG

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

--EZN6irWB3fS+DSGO
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+2iVeHb1edYOZ4bsRAsw4AJ9PiswzkpaeVwCeJhZzZ8BgkPi4WQCcC31d
hPS2EPjY2Q3lZIFrRe0IR+8=
=Qa89
-----END PGP SIGNATURE-----

--EZN6irWB3fS+DSGO--

From ilya@gateway.total-knowledge.com Sun Jun  1 18:58:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Jun 2003 18:58:47 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:37764
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8224827AbTFAR6p>; Sun, 1 Jun 2003 18:58:45 +0100
Received: (qmail 18627 invoked by uid 502); 1 Jun 2003 17:58:39 -0000
Date: Sun, 1 Jun 2003 10:58:39 -0700
From: ilya@theIlya.com
To: linux-mips@linux-mips.org
Subject: Simple compile fix
Message-ID: <20030601175839.GA3035@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2488
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

ip32-berr.c misses #include <linux/sched.h>

Index: arch/mips/sgi-ip32/ip32-berr.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip32/ip32-berr.c,v
retrieving revision 1.4
diff -u -r1.4 ip32-berr.c
--- arch/mips/sgi-ip32/ip32-berr.c      14 Apr 2003 16:33:24 -0000      1.4
+++ arch/mips/sgi-ip32/ip32-berr.c      1 Jun 2003 17:56:58 -0000
@@ -9,6 +9,7 @@
  */
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/sched.h>
 #include <asm/traps.h>
 #include <asm/uaccess.h>
 #include <asm/addrspace.h>


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

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

iD4DBQE+2j7O7sVBmHZT8w8RAtg+AKCGh8bxCixWJ3oG5KocSGG+bPbXMQCXc524
R5QgG2wgiNTLzMSLSq9Uxw==
=JTka
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--

From ilya@gateway.total-knowledge.com Sun Jun  1 20:31:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Jun 2003 20:31:59 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:45700
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225204AbTFATb5>; Sun, 1 Jun 2003 20:31:57 +0100
Received: (qmail 25496 invoked by uid 502); 1 Jun 2003 19:31:55 -0000
Date: Sun, 1 Jun 2003 12:31:55 -0700
From: ilya@theIlya.com
To: linux-mips@linux-mips.org
Subject: Another small compile fix
Message-ID: <20030601193154.GC3035@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="wxDdMuZNg1r63Hyj"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2489
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

I wonder if they ever compile FB drivers with arches where BITS_PER_LONG !=
=3D32...

Index: include/linux/fb.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/cvs/linux/include/linux/fb.h,v
retrieving revision 1.30
diff -u -r1.30 fb.h
--- include/linux/fb.h  1 Jun 2003 12:07:45 -0000       1.30
+++ include/linux/fb.h  1 Jun 2003 19:28:32 -0000
@@ -432,9 +432,11 @@
 #define fb_readb(addr) (*(volatile u8 *) (addr))
 #define fb_readw(addr) (*(volatile u16 *) (addr))
 #define fb_readl(addr) (*(volatile u32 *) (addr))
+#define fb_readq(addr) (*(volatile u64 *) (addr))
 #define fb_writeb(b,addr) (*(volatile u8 *) (addr) =3D (b))
 #define fb_writew(b,addr) (*(volatile u16 *) (addr) =3D (b))
 #define fb_writel(b,addr) (*(volatile u32 *) (addr) =3D (b))
+#define fb_writeq(b,addr) (*(volatile u64 *) (addr) =3D (b))
 #define fb_memset memset
=20
 #endif

Index: drivers/video/cfbcopyarea.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/linux/drivers/video/cfbcopyarea.c,v
retrieving revision 1.4
diff -u -r1.4 cfbcopyarea.c
--- drivers/video/cfbcopyarea.c 1 Jun 2003 12:07:43 -0000       1.4
+++ drivers/video/cfbcopyarea.c 1 Jun 2003 19:30:55 -0000
@@ -38,7 +38,7 @@
 #define BYTES_PER_LONG 4
 #else
 #define FB_WRITEL fb_writeq
-#define FB_READL  fb_readq(x)
+#define FB_READL  fb_readq
 #define SHIFT_PER_LONG 6
 #define BYTES_PER_LONG 8
 #endif


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

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

iD8DBQE+2lSq7sVBmHZT8w8RAmvfAJ0bWHm6qSprVxLR7Qn8yxQrnjpq4QCgtfj1
tIY+lTUbzgayosd+FVtDqcE=
=zeW1
-----END PGP SIGNATURE-----

--wxDdMuZNg1r63Hyj--

From ilya@gateway.total-knowledge.com Mon Jun  2 05:14:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 05:14:29 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:20613
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225206AbTFBEO1>; Mon, 2 Jun 2003 05:14:27 +0100
Received: (qmail 21658 invoked by uid 502); 2 Jun 2003 04:14:24 -0000
Date: Sun, 1 Jun 2003 21:14:24 -0700
From: ilya@theIlya.com
To: wesolows@foobazco.org
Cc: linux-mips@linux-mips.org
Subject: Yet another fix
Message-ID: <20030602041424.GG3035@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="Cgrdyab2wu3Akvjd"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2490
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

I am not sure this is correct solution to a problem. Or rather, I'm pretty
sure it is incorrect one.. There is a reference to module_map somewhere, ho=
wever
it is not inculded if modules are disabled. Here is sorta fix

Index: include/asm-mips64/module.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/cvs/linux/include/asm-mips64/module.h,v
retrieving revision 1.5
diff -u -r1.5 module.h
--- include/asm-mips64/module.h 1 Jun 2003 00:39:15 -0000       1.5
+++ include/asm-mips64/module.h 2 Jun 2003 03:59:23 -0000
@@ -11,4 +11,8 @@
 #define Elf_Sym Elf32_Sym
 #define Elf_Ehdr Elf32_Ehdr
=20
+#ifndef CONFIG_MODULES
+#define module_map(x) vmalloc(x)
+#endif
+
 #endif /* _ASM_MODULE_H */


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

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

iD8DBQE+2s8f7sVBmHZT8w8RAmu8AKCG5kHyIx57QuAmgWu8tacj0k5ZNQCgrY8e
p+5y0ft3qvM6DZsX1Awauqg=
=+mNz
-----END PGP SIGNATURE-----

--Cgrdyab2wu3Akvjd--

From ilya@gateway.total-knowledge.com Mon Jun  2 05:18:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 05:18:19 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:21381
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225206AbTFBESR>; Mon, 2 Jun 2003 05:18:17 +0100
Received: (qmail 21792 invoked by uid 502); 2 Jun 2003 04:18:15 -0000
Date: Sun, 1 Jun 2003 21:18:15 -0700
From: ilya@theIlya.com
To: linux-mips@linux-mips.org
Subject: Lost patch?
Message-ID: <20030602041815.GH3035@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="EemXnrF2ob+xzFeB"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2491
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

This seems like an error to me:

Index: include/asm-mips64/pgtable.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/cvs/linux/include/asm-mips64/pgtable.h,v
retrieving revision 1.80
diff -u -r1.80 pgtable.h
--- include/asm-mips64/pgtable.h        1 Jun 2003 08:24:04 -0000       1.80
+++ include/asm-mips64/pgtable.h        2 Jun 2003 03:59:24 -0000
@@ -255,9 +255,8 @@
 #define pfn_pte(pfn, prot)     __pte(((pfn) << PAGE_SHIFT) | pgprot_val(pr=
ot))
 #else
=20
-#define pte_page(x) ( NODE_MEM_MAP(PHYSADDR_TO_NID(pte_val(x))) +
+#define pte_page(x) ( NODE_MEM_MAP(PHYSADDR_TO_NID(pte_val(x))) + \
        PLAT_NODE_DATA_LOCALNR(pte_val(x), PHYSADDR_TO_NID(pte_val(x))) )
-                                =20
 #endif
=20
 /*


--EemXnrF2ob+xzFeB
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+2tAH7sVBmHZT8w8RAg0QAJ48KVK7ZpXRQ9ExwdgcfS4KLr+1OgCgud00
13HV5p4TFzudANt9pWhMMdU=
=i47B
-----END PGP SIGNATURE-----

--EemXnrF2ob+xzFeB--

From kaos@sgi.com Mon Jun  2 09:11:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 09:11:49 +0100 (BST)
Received: from p508B6D44.dip.t-dialin.net ([IPv6:::ffff:80.139.109.68]:47001
	"EHLO p508B6D44.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225206AbTFBILr>; Mon, 2 Jun 2003 09:11:47 +0100
Received: from [IPv6:::ffff:204.94.215.101] ([IPv6:::ffff:204.94.215.101]:20109
	"EHLO zok.sgi.com") by linux-mips.net with ESMTP id <S868871AbTFBEuW>;
	Mon, 2 Jun 2003 06:50:22 +0200
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130])
	by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h523pTtm029876;
	Sun, 1 Jun 2003 20:51:29 -0700
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13174; Mon, 2 Jun 2003 14:49:30 +1000
Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331)
	id D9F1AD8F46; Mon,  2 Jun 2003 14:49:29 +1000 (EST)
Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1])
	by kao2.melbourne.sgi.com (Postfix) with ESMTP
	id D728D91336; Mon,  2 Jun 2003 14:49:29 +1000 (EST)
X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4
From: Keith Owens <kaos@sgi.com>
To: ilya@theIlya.com
Cc: wesolows@foobazco.org, linux-mips@linux-mips.org
Subject: Re: Yet another fix 
In-reply-to: Your message of "Sun, 01 Jun 2003 21:14:24 MST."
             <20030602041424.GG3035@gateway.total-knowledge.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 02 Jun 2003 14:49:24 +1000
Message-ID: <13249.1054529364@kao2.melbourne.sgi.com>
Return-Path: <kaos@sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2492
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@sgi.com
Precedence: bulk
X-list: linux-mips

On Sun, 1 Jun 2003 21:14:24 -0700, 
ilya@theIlya.com wrote:
>I am not sure this is correct solution to a problem. Or rather, I'm pretty
>sure it is incorrect one.. There is a reference to module_map somewhere, however
>it is not inculded if modules are disabled. Here is sorta fix
>
>Index: include/asm-mips64/module.h
>===================================================================
>RCS file: /home/cvs/linux/include/asm-mips64/module.h,v
>retrieving revision 1.5
>diff -u -r1.5 module.h
>--- include/asm-mips64/module.h 1 Jun 2003 00:39:15 -0000       1.5
>+++ include/asm-mips64/module.h 2 Jun 2003 03:59:23 -0000
>@@ -11,4 +11,8 @@
> #define Elf_Sym Elf32_Sym
> #define Elf_Ehdr Elf32_Ehdr
> 
>+#ifndef CONFIG_MODULES
>+#define module_map(x) vmalloc(x)
>+#endif
>+
> #endif /* _ASM_MODULE_H */

That fix is incorrect.  There should be no references to module_map
when CONFIG_MODULES=n.  Please find out where module_map is being
incorrectly used and fix that code.


From ilya@gateway.total-knowledge.com Mon Jun  2 09:12:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 09:12:11 +0100 (BST)
Received: from p508B6D44.dip.t-dialin.net ([IPv6:::ffff:80.139.109.68]:47001
	"EHLO p508B6D44.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225211AbTFBILs>; Mon, 2 Jun 2003 09:11:48 +0100
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:30341
	"HELO gateway.total-knowledge.com") by linux-mips.net with SMTP
	id <S868881AbTFBE6G>; Mon, 2 Jun 2003 06:58:06 +0200
Received: (qmail 16324 invoked by uid 502); 2 Jun 2003 04:57:00 -0000
Date: Sun, 1 Jun 2003 21:57:00 -0700
From: ilya@theIlya.com
To: linux-mips@linux-mips.org
Subject: Re: Yet another fix
Message-ID: <20030602045700.GI3035@gateway.total-knowledge.com>
References: <20030602041424.GG3035@gateway.total-knowledge.com> <13249.1054529364@kao2.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="v2/QI0iRXglpx0hK"
Content-Disposition: inline
In-Reply-To: <13249.1054529364@kao2.melbourne.sgi.com>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2493
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

module_map is referenced in register_ioctl32_conversion in arch/mips64/ioct=
l32.c
As far as I can see, it should simply be possible to replace module_map
with vmalloc in there, but I am not sure, as I don't know how exactly
ioctl translations work...

On Mon, Jun 02, 2003 at 02:49:24PM +1000, Keith Owens wrote:
> On Sun, 1 Jun 2003 21:14:24 -0700,=20
> ilya@theIlya.com wrote:
> >I am not sure this is correct solution to a problem. Or rather, I'm pret=
ty
> >sure it is incorrect one.. There is a reference to module_map somewhere,=
 however
> >it is not inculded if modules are disabled. Here is sorta fix
> >
> >Index: include/asm-mips64/module.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/cvs/linux/include/asm-mips64/module.h,v
> >retrieving revision 1.5
> >diff -u -r1.5 module.h
> >--- include/asm-mips64/module.h 1 Jun 2003 00:39:15 -0000       1.5
> >+++ include/asm-mips64/module.h 2 Jun 2003 03:59:23 -0000
> >@@ -11,4 +11,8 @@
> > #define Elf_Sym Elf32_Sym
> > #define Elf_Ehdr Elf32_Ehdr
> >=20
> >+#ifndef CONFIG_MODULES
> >+#define module_map(x) vmalloc(x)
> >+#endif
> >+
> > #endif /* _ASM_MODULE_H */
>=20
> That fix is incorrect.  There should be no references to module_map
> when CONFIG_MODULES=3Dn.  Please find out where module_map is being
> incorrectly used and fix that code.
>=20

--v2/QI0iRXglpx0hK
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+2tkc7sVBmHZT8w8RArEMAJ9Om3f1EdOliQH3/y5rlMWMHtCxdgCfQlFK
pLyc/tfO0TxNVBHaL4H2nug=
=84+t
-----END PGP SIGNATURE-----

--v2/QI0iRXglpx0hK--

From ilya@gateway.total-knowledge.com Mon Jun  2 09:12:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 09:12:32 +0100 (BST)
Received: from p508B6D44.dip.t-dialin.net ([IPv6:::ffff:80.139.109.68]:47001
	"EHLO p508B6D44.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225214AbTFBILs>; Mon, 2 Jun 2003 09:11:48 +0100
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:31621
	"HELO gateway.total-knowledge.com") by linux-mips.net with SMTP
	id <S868897AbTFBFEo>; Mon, 2 Jun 2003 07:04:44 +0200
Received: (qmail 16539 invoked by uid 502); 2 Jun 2003 05:03:41 -0000
Date: Sun, 1 Jun 2003 22:03:41 -0700
From: ilya@theIlya.com
To: linux-mips@linux-mips.org
Subject: Another lost patch
Message-ID: <20030602050341.GJ3035@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="JsihDCElWRmQcbOr"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2494
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

 I think this is still needed as well...

Index: arch/mips64/mm/tlb-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/tlb-r4k.c,v
retrieving revision 1.18
diff -u -r1.18 tlb-r4k.c
--- arch/mips64/mm/tlb-r4k.c    28 May 2003 07:32:46 -0000      1.18
+++ arch/mips64/mm/tlb-r4k.c    2 Jun 2003 03:58:44 -0000
@@ -253,8 +253,9 @@
        tlb_probe();
        BARRIER;
        pmdp = pmd_offset(pgdp, address);
+
        idx = read_c0_index();
-       ptep = pte_offset(pmdp, address);
+       ptep = pte_offset_map(pmdp, address);
        BARRIER;
        write_c0_entrylo0(pte_val(*ptep++) >> 6);
        write_c0_entrylo1(pte_val(*ptep) >> 6);


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

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

iD8DBQE+2tqs7sVBmHZT8w8RArMSAJ0Vlm2GgizkYX/aVDixmCFQvUUYWQCfe75s
ycFdKGBTlvYFmYXSZhMrgM4=
=PsY3
-----END PGP SIGNATURE-----

--JsihDCElWRmQcbOr--

From bhs@pvv.ntnu.no Mon Jun  2 09:38:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 09:38:13 +0100 (BST)
Received: from verden.pvv.ntnu.no ([IPv6:::ffff:129.241.210.224]:16146 "HELO
	verden.pvv.ntnu.no") by linux-mips.org with SMTP
	id <S8225214AbTFBIiL>; Mon, 2 Jun 2003 09:38:11 +0100
Received: (qmail 72864 invoked by uid 23199); 2 Jun 2003 08:38:08 -0000
Date: Mon, 2 Jun 2003 10:38:08 +0200 (CEST)
From: Bjorn Hanch Sollie <bhs@pvv.org>
X-X-Sender: bhs@verden.pvv.ntnu.no
To: linux-mips@linux-mips.org
Subject: MIPSPro + GCC
Message-ID: <Pine.BSF.4.52.0306021029350.72800@verden.pvv.ntnu.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <bhs@pvv.ntnu.no>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2495
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bhs@pvv.org
Precedence: bulk
X-list: linux-mips

Hi all,

Does anyone here have an idea about what it takes to link my MIPSPro
compiled program (MIPSPro 7.4) to a gcc built library (GCC 3.2.2)?  I
will be very thankful for suggestions on how to resolve the FATAL 52
below.  I suspect this might be a compiler/linker bug, since I at no
point specify the -fini option, and I'm not attempting to build a
driver or resident module (just a regular dso). (In case anyone is
wondering, the library I'm linking against is the ITK segmentation and
registration toolkit, http://www.itk.org/.)

Thanks in advance for any help!

-Beorn

bjorns@octane:~/Surge/Segmentation/demo:$ make
        ld -o seg InputOutput.o  Levelset.o  Lumen3DSegment.o  Thrombus2DSegment.o  Thrombus3DSegment.o  Segment.o  main.o -L/usr/lib32/mips3  -L/usr/lib32  -L/lib32  -L/lib  -L/oslo/people/bjorns/src/Surge/lib  -L/oslo/people/bjorns/Surge/lib/ITK -lITKAlgorithms  -lITKBasicFilters  -lITKCommon  -lITKFEM  -lITKIO  -lITKMetaIO  -lITKNumerics  -lITKStatistics  -lVXLNumerics  -litkpng  -litkzlib -cxx -n32 -nostdlib -abi
ld32: WARNING 84 : /oslo/people/bjorns/Surge/lib/ITK/libITKAlgorithms.so is not used for resolving any symbol.
ld32: WARNING 84 : /oslo/people/bjorns/Surge/lib/ITK/libITKBasicFilters.so is not used for resolving any symbol.
ld32: WARNING 84 : /oslo/people/bjorns/Surge/lib/ITK/libITKFEM.so is not used for resolving any symbol.
ld32: WARNING 84 : /oslo/people/bjorns/Surge/lib/ITK/libITKNumerics.so is not used for resolving any symbol.
ld32: WARNING 84 : /oslo/people/bjorns/Surge/lib/ITK/libITKStatistics.so is not used for resolving any symbol.
ld32: FATAL   52 : _fini specified for -fini is not defined in the current object.
*** Error code 4 (bu21)
bjorns@octane:~/Surge/Segmentation/demo:$ ld -V
ld32: INFO    153: Version 7.4.
ld32: INFO    46 : No objects linked.
bjorns@octane:~/Surge/Segmentation/demo:$ g++ --version
g++ (GCC) 3.2.2
Copyright (C) 2002 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.

bjorns@octane:~/Surge/Segmentation/demo:$ CC -version
MIPSpro Compilers: Version 7.4
bjorns@octane:~/Surge/Segmentation/demo:$

-Beorn
-- 
Truth is often just a widely held opinion.


-- 
Truth is often just a widely held opinion.

From Geert.Uytterhoeven@sonycom.com Mon Jun  2 10:04:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 10:04:20 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:7664 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225214AbTFBJES>;
	Mon, 2 Jun 2003 10:04:18 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h52949LT008010;
	Mon, 2 Jun 2003 11:04:09 +0200 (MEST)
Date: Mon, 2 Jun 2003 11:04:10 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Bjorn Hanch Sollie <bhs@pvv.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: MIPSPro + GCC
In-Reply-To: <Pine.BSF.4.52.0306021029350.72800@verden.pvv.ntnu.no>
Message-ID: <Pine.GSO.4.21.0306021102300.149-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2496
X-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, 2 Jun 2003, Bjorn Hanch Sollie wrote:
> Does anyone here have an idea about what it takes to link my MIPSPro
> compiled program (MIPSPro 7.4) to a gcc built library (GCC 3.2.2)?  I

> bjorns@octane:~/Surge/Segmentation/demo:$ g++ --version
> g++ (GCC) 3.2.2
> Copyright (C) 2002 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.
> 
> bjorns@octane:~/Surge/Segmentation/demo:$ CC -version
> MIPSpro Compilers: Version 7.4
> bjorns@octane:~/Surge/Segmentation/demo:$

C++ object files are not compatible across different compilers. Either fall
back to plain C, or compile everything with the same C++ compiler.

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 anemo@mba.ocn.ne.jp Mon Jun  2 12:14:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 12:14:29 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:20516
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225214AbTFBLO1>; Mon, 2 Jun 2003 12:14:27 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 2 Jun 2003 11:14:25 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h52BEFjf022570;
	Mon, 2 Jun 2003 20:14:16 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Mon, 02 Jun 2003 20:14:53 +0900 (JST)
Message-Id: <20030602.201453.48536826.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: mips64 LOAD_KPTE2 fix
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2497
X-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

If a TLB exception occured on very high address (such as
0xffffffffffffffff), invalid_vmalloc_address should be called but
currently not.

I think it is because LOAD_KPTE2 in arch/mips64/mm/tlbex-r4k.S does
not check overflow of (kptbl + offset).  Here is a patch (both 2.4 and
2.5).


diff -u linux-mips-cvs/arch/mips64/mm/tlbex-r4k.S linux.new/arch/mips64/mm/tlbex-r4k.S
--- linux-mips-cvs/arch/mips64/mm/tlbex-r4k.S	Mon Apr 28 09:44:54 2003
+++ linux.new/arch/mips64/mm/tlbex-r4k.S	Mon Jun  2 19:44:57 2003
@@ -72,6 +72,8 @@
 	/*
 	 * Determine that fault address is within vmalloc range.
 	 */
+	bgez	\ptr, \not_vmalloc		# check overflow
+	nop
 	dla	\tmp, ekptbl
 	sltu	\tmp, \ptr, \tmp
 	beqz	\tmp, \not_vmalloc		# not vmalloc
---
Atsushi Nemoto

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

>>>>> On Mon, 02 Jun 2003 20:14:53 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> If a TLB exception occured on very high address (such as
anemo> 0xffffffffffffffff), invalid_vmalloc_address should be called
anemo> but currently not.

anemo> I think it is because LOAD_KPTE2 in arch/mips64/mm/tlbex-r4k.S
anemo> does not check overflow of (kptbl + offset).  Here is a patch
anemo> (both 2.4 and 2.5).

Please ignore it.  I missed an another fix.  The beqz lacks delay
slot.  Here is a new patch.

diff -u linux-mips-cvs/arch/mips64/mm/tlbex-r4k.S linux.new/arch/mips64/mm/tlbex-r4k.S
--- linux-mips-cvs/arch/mips64/mm/tlbex-r4k.S	Mon Apr 28 09:44:54 2003
+++ linux.new/arch/mips64/mm/tlbex-r4k.S	Mon Jun  2 20:16:41 2003
@@ -72,9 +72,12 @@
 	/*
 	 * Determine that fault address is within vmalloc range.
 	 */
+	bgez	\ptr, \not_vmalloc		# check overflow
+	nop
 	dla	\tmp, ekptbl
 	sltu	\tmp, \ptr, \tmp
 	beqz	\tmp, \not_vmalloc		# not vmalloc
+	nop
 	.endm
 
 
---
Atsushi Nemoto

From kaos@sgi.com Mon Jun  2 14:28:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 14:28:09 +0100 (BST)
Received: from mail.ocs.com.au ([IPv6:::ffff:203.34.97.2]:31507 "HELO
	mail.ocs.com.au") by linux-mips.org with SMTP id <S8225214AbTFBN2H>;
	Mon, 2 Jun 2003 14:28:07 +0100
Received: (qmail 8304 invoked from network); 2 Jun 2003 13:27:56 -0000
Received: from ocs3.intra.ocs.com.au (192.168.255.3)
  by mail.ocs.com.au with SMTP; 2 Jun 2003 13:27:56 -0000
Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331)
	id A989FD8F46; Mon,  2 Jun 2003 23:27:51 +1000 (EST)
Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1])
	by ocs3.intra.ocs.com.au (Postfix) with ESMTP
	id A6DB591336; Mon,  2 Jun 2003 23:27:51 +1000 (EST)
X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4
From: Keith Owens <kaos@sgi.com>
To: ilya@theIlya.com
Cc: linux-mips@linux-mips.org
Subject: Re: Yet another fix 
In-reply-to: Your message of "Sun, 01 Jun 2003 21:57:00 MST."
             <20030602045700.GI3035@gateway.total-knowledge.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 02 Jun 2003 23:27:46 +1000
Message-ID: <5368.1054560466@ocs3.intra.ocs.com.au>
Return-Path: <kaos@sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2499
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@sgi.com
Precedence: bulk
X-list: linux-mips

On Sun, 1 Jun 2003 21:57:00 -0700, 
ilya@theIlya.com wrote:
>module_map is referenced in register_ioctl32_conversion in arch/mips64/ioctl32.c
>As far as I can see, it should simply be possible to replace module_map
>with vmalloc in there, but I am not sure, as I don't know how exactly
>ioctl translations work...

Not in 2.4.20 nor 2.4.21-rc6 from Marcelo, must be a mips local change.
I strongly suggest that you get rid of it, there is no good reason to
emulate the 32 bit module syscalls on a 64 bit machine.  modutils is
pure Linux and there is absolutely no justification for emulating 32
bit versions of modutils when the user can install the 64 bit version
of modutils instead.  32 bit emulation is a crutch to let binary only
programs work when you do not have the source to rebuild to 64 bit, by
definition we have the source to modutils.

IA64 and x86_64 make no attempt to emulate 32 bit modutils.  sparc64,
ppc64 and s390x all pass the data straight to the 64 bit kernel code,
they require the user space modutils to supply 64 bit data.  Emulation
is a waste of time.


From ralf@linux-mips.org Mon Jun  2 15:12:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 15:12:30 +0100 (BST)
Received: from p508B6D44.dip.t-dialin.net ([IPv6:::ffff:80.139.109.68]:49382
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225227AbTFBOM2>; Mon, 2 Jun 2003 15:12:28 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h52ECObY028498;
	Mon, 2 Jun 2003 07:12:25 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h52ECMLA027859;
	Mon, 2 Jun 2003 16:12:22 +0200
Date: Mon, 2 Jun 2003 16:12:22 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Keith Owens <kaos@sgi.com>
Cc: ilya@theIlya.com, linux-mips@linux-mips.org
Subject: Re: Yet another fix
Message-ID: <20030602141222.GA25568@linux-mips.org>
References: <20030602045700.GI3035@gateway.total-knowledge.com> <5368.1054560466@ocs3.intra.ocs.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5368.1054560466@ocs3.intra.ocs.com.au>
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: 2500
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Jun 02, 2003 at 11:27:46PM +1000, Keith Owens wrote:

> Not in 2.4.20 nor 2.4.21-rc6 from Marcelo, must be a mips local change.
> I strongly suggest that you get rid of it, there is no good reason to
> emulate the 32 bit module syscalls on a 64 bit machine.  modutils is
> pure Linux and there is absolutely no justification for emulating 32
> bit versions of modutils when the user can install the 64 bit version
> of modutils instead.  32 bit emulation is a crutch to let binary only
> programs work when you do not have the source to rebuild to 64 bit, by
> definition we have the source to modutils.

Until very recently there was no 64-bit userland.

> IA64 and x86_64 make no attempt to emulate 32 bit modutils.  sparc64,
> ppc64 and s390x all pass the data straight to the 64 bit kernel code,
> they require the user space modutils to supply 64 bit data.  Emulation
> is a waste of time.

The code simply does the sparc64 thing.  Heck, it is the sparc64 code
with minor changes.

  Ralf

From ilya@gateway.total-knowledge.com Mon Jun  2 15:30:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 15:30:30 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:18310
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225214AbTFBOa1>; Mon, 2 Jun 2003 15:30:27 +0100
Received: (qmail 1397 invoked by uid 502); 2 Jun 2003 14:30:23 -0000
Date: Mon, 2 Jun 2003 07:30:23 -0700
From: ilya@theIlya.com
To: Keith Owens <kaos@sgi.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Yet another fix
Message-ID: <20030602143022.GK3035@gateway.total-knowledge.com>
References: <20030602045700.GI3035@gateway.total-knowledge.com> <5368.1054560466@ocs3.intra.ocs.com.au>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="5mZBmBd1ZkdwT1ny"
Content-Disposition: inline
In-Reply-To: <5368.1054560466@ocs3.intra.ocs.com.au>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2501
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

For starters, I'm talking about 2.5.51 here.
Secondly, what does register_ioctl32_conversion have to do with
emulating 32bit modutils? Code in quesion is this:
int register_ioctl32_conversion(unsigned int cmd, int (*handler)(unsigned i=
nt, unsigned int, unsigned long, ...))
{
	int i;
	if (!additional_ioctls) {
		additional_ioctls =3D module_map(PAGE_SIZE);
		if (!additional_ioctls)
			return -ENOMEM;
		memset(additional_ioctls, 0, PAGE_SIZE);
	}
=2E....

As far as I can tell, There is nothing that prevents us from
replacing module_map with vmalloc, or even get_free_pages,
but I am not sure. There must be some reason, why it is there :)
Ralf, it's question for you.

	Ilya.


On Mon, Jun 02, 2003 at 11:27:46PM +1000, Keith Owens wrote:
> On Sun, 1 Jun 2003 21:57:00 -0700,=20
> ilya@theIlya.com wrote:
> >module_map is referenced in register_ioctl32_conversion in arch/mips64/i=
octl32.c
> >As far as I can see, it should simply be possible to replace module_map
> >with vmalloc in there, but I am not sure, as I don't know how exactly
> >ioctl translations work...
>=20
> Not in 2.4.20 nor 2.4.21-rc6 from Marcelo, must be a mips local change.
> I strongly suggest that you get rid of it, there is no good reason to
> emulate the 32 bit module syscalls on a 64 bit machine.  modutils is
> pure Linux and there is absolutely no justification for emulating 32
> bit versions of modutils when the user can install the 64 bit version
> of modutils instead.  32 bit emulation is a crutch to let binary only
> programs work when you do not have the source to rebuild to 64 bit, by
> definition we have the source to modutils.
>=20
> IA64 and x86_64 make no attempt to emulate 32 bit modutils.  sparc64,
> ppc64 and s390x all pass the data straight to the 64 bit kernel code,
> they require the user space modutils to supply 64 bit data.  Emulation
> is a waste of time.
>=20

--5mZBmBd1ZkdwT1ny
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+219+7sVBmHZT8w8RAtElAKC8GqtzSuqCwi5aZ86+I7UtsX+ovgCghp64
dis1DUvLaTjnBLJDUaFEWwk=
=RIxu
-----END PGP SIGNATURE-----

--5mZBmBd1ZkdwT1ny--

From Amit.Lubovsky@infineon.com Mon Jun  2 17:41:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jun 2003 17:41:27 +0100 (BST)
Received: from smtp1.infineon.com ([IPv6:::ffff:194.175.117.76]:28299 "EHLO
	smtp1.infineon.com") by linux-mips.org with ESMTP
	id <S8225229AbTFBQlZ>; Mon, 2 Jun 2003 17:41:25 +0100
Received: from mucse011.eu.infineon.com (mucse011.ifx-mail1.com [172.29.27.228])
	by smtp1.infineon.com (8.12.9/8.12.9) with ESMTP id h52GexxZ013448
	for <linux-mips@linux-mips.org>; Mon, 2 Jun 2003 18:40:59 +0200 (MEST)
Received: by mucse011.eu.infineon.com with Internet Mail Service (5.5.2653.19)
	id <M1DMQS23>; Mon, 2 Jun 2003 18:41:18 +0200
Message-ID: <AD2F581BD7340A4C908AF1AFB066EA3B0E45F0@ntah901e.savan.com>
From: Amit.Lubovsky@infineon.com
To: linux-mips@linux-mips.org
Subject: gdb-5.3
Date: Mon, 2 Jun 2003 19:39:47 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Return-Path: <Amit.Lubovsky@infineon.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2502
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Amit.Lubovsky@infineon.com
Precedence: bulk
X-list: linux-mips

Hi,

I have compiled gdb-5.3 for a custom board running mips:

target gdbserver: 
	gdb-5.3/gdb/gdbserver/configure mips-eb-linux-gnu

host gdb: 
	gdb-5.3/gdb/configure --target mipseb-linux-elf


while running gdb on the host I got:
[test@dragun usr]$ ~test/gdb/bin/host/gdb demo
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=mipseb-linux-elf"...
(gdb) target remote 192.168.1.90:4444
Remote debugging using 192.168.1.90:4444
0x6000e182 in ?? ()
(gdb) b printf
Breakpoint 1 at 0x8048370
(gdb) n   
Cannot find bounds of current function
(gdb) p
The history is empty.
(gdb) cont
Continuing.

and on the target I got
/usr> ./gdbserver 192.168.1.1:4444 demo

Process demo created; pid = 27

Remote debugging from host 192.168.1.1

hello - #0

hello - #1

hello - #2

hello - #3

hello - #4

hello - #5 

the program demo.c
#include <stdio.h>

int main()
{
        int i=0;
        while(1){
                sleep(1);
                printf("hello - #%d\n", i);
                return 0;
        }
}

The problem is that I can't controll the gdbserver, it looks as if it
doesn't respond to commands (breakpoints,)
from the host gdb.

Thanks,
Amit.

From kaos@sgi.com Tue Jun  3 00:50:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Jun 2003 00:50:43 +0100 (BST)
Received: from mail.ocs.com.au ([IPv6:::ffff:203.34.97.2]:31749 "HELO
	mail.ocs.com.au") by linux-mips.org with SMTP id <S8225229AbTFBXul>;
	Tue, 3 Jun 2003 00:50:41 +0100
Received: (qmail 445 invoked from network); 2 Jun 2003 23:50:32 -0000
Received: from ocs3.intra.ocs.com.au (192.168.255.3)
  by mail.ocs.com.au with SMTP; 2 Jun 2003 23:50:32 -0000
Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331)
	id 2833CD8F46; Tue,  3 Jun 2003 09:50:31 +1000 (EST)
Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1])
	by ocs3.intra.ocs.com.au (Postfix) with ESMTP
	id 257F391336; Tue,  3 Jun 2003 09:50:31 +1000 (EST)
X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4
From: Keith Owens <kaos@sgi.com>
To: ilya@theIlya.com
Cc: linux-mips@linux-mips.org
Subject: Re: Yet another fix 
In-reply-to: Your message of "Mon, 02 Jun 2003 07:30:23 MST."
             <20030602143022.GK3035@gateway.total-knowledge.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 03 Jun 2003 09:50:26 +1000
Message-ID: <11027.1054597826@ocs3.intra.ocs.com.au>
Return-Path: <kaos@sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2503
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@sgi.com
Precedence: bulk
X-list: linux-mips

On Mon, 2 Jun 2003 07:30:23 -0700, 
ilya@theIlya.com wrote:
>For starters, I'm talking about 2.5.51 here.

Sorry,  thought you were talking about 2.4 kernels.

>Secondly, what does register_ioctl32_conversion have to do with
>emulating 32bit modutils?

See above, I thought this was 2.4.

>Code in quesion is this:
>int register_ioctl32_conversion(unsigned int cmd, int (*handler)(unsigned i=
>nt, unsigned int, unsigned long, ...))
>{
>	int i;
>	if (!additional_ioctls) {
>		additional_ioctls =3D module_map(PAGE_SIZE);
>		if (!additional_ioctls)
>			return -ENOMEM;
>		memset(additional_ioctls, 0, PAGE_SIZE);
>	}

I cannot find register_ioctl32_conversion in 2.5.51.

>As far as I can tell, There is nothing that prevents us from
>replacing module_map with vmalloc, or even get_free_pages,
>but I am not sure. There must be some reason, why it is there :)
>Ralf, it's question for you.

Without seeing the code that uses register_ioctl32_conversion (it is
not in Linus's kernel), I would be guessing.  But I suspect that you
are right, it should use vmalloc.


From dan@embeddededge.com Tue Jun  3 05:53:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Jun 2003 05:53:42 +0100 (BST)
Received: from [IPv6:::ffff:63.161.110.249] ([IPv6:::ffff:63.161.110.249]:56054
	"EHLO tibook.netx4.com") by linux-mips.org with ESMTP
	id <S8225072AbTFCExj>; Tue, 3 Jun 2003 05:53:39 +0100
Received: from embeddededge.com (IDENT:dan@localhost.localdomain [127.0.0.1])
	by tibook.netx4.com (8.11.1/8.11.1) with ESMTP id h534rVq05662;
	Tue, 3 Jun 2003 00:53:32 -0400
Message-ID: <3EDC29CB.1010409@embeddededge.com>
Date: Tue, 03 Jun 2003 00:53:31 -0400
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: baitisj@evolution.com
CC: n_gale@ok.ru, linux-mips@linux-mips.org
Subject: Re: DBAu1500 board flash downloading
References: <web-13584424@backend4.aha.ru> <20030530144535.T29389@luca.pas.lab>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dan@embeddededge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2504
X-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

Jeff Baitis wrote:

> Rather than building an EJTAG interface, I recommend the Raven EJTAG interface.
> It plugs into your LPT port, and will plug into the EJTAG interface on your
> DBAu1500 board.

I can recommend the Abatron BDI-2000 (www.abatron.ch).  It's a powerful,
flexible tool that will work in a variety of development environments.
In addition to providing debugging features, it also has built-in flash
programming algorithms.  You can erase/program flash with simple console
or script commands from various file formats transferred over the network
using tftp.


	-- Dan


From lyle@zevion.com Tue Jun  3 06:40:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Jun 2003 06:40:50 +0100 (BST)
Received: from rrcs-central-24-123-115-43.biz.rr.com ([IPv6:::ffff:24.123.115.43]:38404
	"EHLO Radium.intranet") by linux-mips.org with ESMTP
	id <S8225072AbTFCFks>; Tue, 3 Jun 2003 06:40:48 +0100
Received: from radium ([192.168.1.22])
	by Radium.intranet (8.9.3/8.9.3) with ESMTP id AAA31966;
	Tue, 3 Jun 2003 00:40:02 -0500
From: "Lyle Bainbridge" <lyle@zevion.com>
To: "'Dan Malek'" <dan@embeddededge.com>, <baitisj@evolution.com>
Cc: <n_gale@ok.ru>, <linux-mips@linux-mips.org>
Subject: RE: DBAu1500 board flash downloading
Date: Tue, 3 Jun 2003 00:40:36 -0500
Message-ID: <000201c32992$a844efc0$1601a8c0@radium>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <3EDC29CB.1010409@embeddededge.com>
Return-Path: <lyle@zevion.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2505
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lyle@zevion.com
Precedence: bulk
X-list: linux-mips

Yeh, I second that.  The BDI-2000 has been a very valuable tool
for me, both for debugging and flash writing.  However, it runs
about $2500 for one architecture (ie, MIPS).  By the time you
purchase the Raven and the various software packages it's almost
as expensive, but isn't as good.  If money isn't a problem, the
BDI-2000 is the way to go.

Lyle


> 
> 
> Jeff Baitis wrote:
> 
> > Rather than building an EJTAG interface, I recommend the 
> Raven EJTAG 
> > interface. It plugs into your LPT port, and will plug into 
> the EJTAG 
> > interface on your DBAu1500 board.
> 
> I can recommend the Abatron BDI-2000 (www.abatron.ch).  It's 
> a powerful, flexible tool that will work in a variety of 
> development environments. In addition to providing debugging 
> features, it also has built-in flash programming algorithms.  
> You can erase/program flash with simple console or script 
> commands from various file formats transferred over the 
> network using tftp.
> 
> 
> 	-- Dan
> 


From julian@jusst.de Tue Jun  3 13:27:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Jun 2003 13:27:49 +0100 (BST)
Received: from [IPv6:::ffff:212.12.33.223] ([IPv6:::ffff:212.12.33.223]:64395
	"EHLO jusst.de") by linux-mips.org with ESMTP id <S8225072AbTFCM1o> convert rfc822-to-8bit;
	Tue, 3 Jun 2003 13:27:44 +0100
Received: from pd9e31a22.dip.t-dialin.net ([217.227.26.34] helo=juli.scheel.lan)
	by jusst.de with asmtp (Exim 4.05)
	id 19NAlZ-0008Vb-00
	for linux-mips@linux-mips.org; Tue, 03 Jun 2003 14:19:49 +0200
From: Julian Scheel <julian@jusst.de>
To: linux-mips@linux-mips.org
Subject: rootfs for vr4181a
Date: Tue, 3 Jun 2003 14:28:48 +0200
User-Agent: KMail/1.5.2
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Message-Id: <200306031428.48675.julian@jusst.de>
Return-Path: <julian@jusst.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: 2506
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: julian@jusst.de
Precedence: bulk
X-list: linux-mips

Hey all,

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

-- 
Grüße,
Julian


From agx@sigxcpu.org Tue Jun  3 13:55:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Jun 2003 13:55:50 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:57785
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225235AbTFCMzq>; Tue, 3 Jun 2003 13:55:46 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id EC82D2BC36
	for <linux-mips@linux-mips.org>; Tue,  3 Jun 2003 14:55:43 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 12483-10
 for <linux-mips@linux-mips.org>; Tue,  3 Jun 2003 14:55:43 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id EC5352BC34
	for <linux-mips@linux-mips.org>; Tue,  3 Jun 2003 14:55:42 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 58EDD17762; Tue,  3 Jun 2003 14:55:36 +0200 (CEST)
Date: Tue, 3 Jun 2003 14:55:36 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: rootfs for vr4181a
Message-ID: <20030603125536.GB19435@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <200306031428.48675.julian@jusst.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200306031428.48675.julian@jusst.de>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2507
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Tue, Jun 03, 2003 at 02:28:48PM +0200, Julian Scheel wrote:
> I am searching for a rootfs which can be used with a NEC VR4181A and can be 
> mounted over NFS (shouldn't need any special things, should it?)
> Has someone such a rootfs - or can give me a link where to find it - or a link 
> to a description how to do it myself?
You can try for mips:
http://debian.physik.uni-konstanz.de/debian/dists/woody/main/disks-mips/3.0.23-2002-05-21/root.tar.gz
or for mipsel:
http://debian.physik.uni-konstanz.de/debian/dists/woody/main/disks-mipsel/3.0.23-2002-05-21/root.tar.gz
(or any other debian mirror) for a rather minimal rootfs. You can build
a more complete nfs-root by following the steps in the installer.
Regards,
 -- Guido

From macro@ds2.pg.gda.pl Tue Jun  3 13:58:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Jun 2003 13:58:21 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:1228 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225072AbTFCM6T>; Tue, 3 Jun 2003 13:58:19 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA00804;
	Tue, 3 Jun 2003 14:58:45 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 3 Jun 2003 14:58:44 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
cc: anemo@mba.ocn.ne.jp, linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: mips64 LOAD_KPTE2 fix
In-Reply-To: <20030602.202345.08315331.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.GSO.3.96.1030603141712.29576C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2508
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 2 Jun 2003, Atsushi Nemoto wrote:

> Please ignore it.  I missed an another fix.  The beqz lacks delay
> slot.  Here is a new patch.
> 
> diff -u linux-mips-cvs/arch/mips64/mm/tlbex-r4k.S linux.new/arch/mips64/mm/tlbex-r4k.S
> --- linux-mips-cvs/arch/mips64/mm/tlbex-r4k.S	Mon Apr 28 09:44:54 2003
> +++ linux.new/arch/mips64/mm/tlbex-r4k.S	Mon Jun  2 20:16:41 2003
> @@ -72,9 +72,12 @@
>  	/*
>  	 * Determine that fault address is within vmalloc range.
>  	 */
> +	bgez	\ptr, \not_vmalloc		# check overflow
> +	nop
>  	dla	\tmp, ekptbl
>  	sltu	\tmp, \ptr, \tmp
>  	beqz	\tmp, \not_vmalloc		# not vmalloc
> +	nop
>  	.endm

 The missing delay slot filler might be called a feature, but LOAD_KPTE2
is so far always used near such code it cannot be avoided.  So the "nop"
is correct.  Please pay attention to proper indentation of instructions in
branch delay slots -- this helps avoiding such errors.

 I don't think a separate overflow check is needed, even I see how the
code can fail for large offsets into XKSEG.  How about this patch?  Does
it work for you?  It would not incur unnecessary overhead.

  Maciej

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

patch-mips-2.4.21-pre4-20030505-load_kpte2-0
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030505.macro/arch/mips64/mm/tlbex-r4k.S linux-mips-2.4.21-pre4-20030505/arch/mips64/mm/tlbex-r4k.S
--- linux-mips-2.4.21-pre4-20030505.macro/arch/mips64/mm/tlbex-r4k.S	2003-04-27 02:56:39.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030505/arch/mips64/mm/tlbex-r4k.S	2003-06-03 12:54:41.000000000 +0000
@@ -73,8 +73,9 @@
 	 * Determine that fault address is within vmalloc range.
 	 */
 	dla	\tmp, ekptbl
-	sltu	\tmp, \ptr, \tmp
+	slt	\tmp, \ptr, \tmp
 	beqz	\tmp, \not_vmalloc		# not vmalloc
+	 nop
 	.endm
 
 


From anemo@mba.ocn.ne.jp Wed Jun  4 02:01:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 02:01:45 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:4623
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225239AbTFDBBl>; Wed, 4 Jun 2003 02:01:41 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 4 Jun 2003 01:01:39 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h5411Ojf026565;
	Wed, 4 Jun 2003 10:01:24 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Wed, 04 Jun 2003 10:02:04 +0900 (JST)
Message-Id: <20030604.100204.74756139.nemoto@toshiba-tops.co.jp>
To: macro@ds2.pg.gda.pl
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: mips64 LOAD_KPTE2 fix
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.GSO.3.96.1030603141712.29576C-100000@delta.ds2.pg.gda.pl>
References: <20030602.202345.08315331.nemoto@toshiba-tops.co.jp>
	<Pine.GSO.3.96.1030603141712.29576C-100000@delta.ds2.pg.gda.pl>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2509
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Tue, 3 Jun 2003 14:58:44 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:
macro>  I don't think a separate overflow check is needed, even I see
macro> how the code can fail for large offsets into XKSEG.  How about
macro> this patch?  Does it work for you?  It would not incur
macro> unnecessary overhead.

macro> diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030505.macro/arch/mips64/mm/tlbex-r4k.S linux-mips-2.4.21-pre4-20030505/arch/mips64/mm/tlbex-r4k.S
macro> --- linux-mips-2.4.21-pre4-20030505.macro/arch/mips64/mm/tlbex-r4k.S	2003-04-27 02:56:39.000000000 +0000
macro> +++ linux-mips-2.4.21-pre4-20030505/arch/mips64/mm/tlbex-r4k.S	2003-06-03 12:54:41.000000000 +0000
macro> @@ -73,8 +73,9 @@
macro>  	 * Determine that fault address is within vmalloc range.
macro>  	 */
macro>  	dla	\tmp, ekptbl
macro> -	sltu	\tmp, \ptr, \tmp
macro> +	slt	\tmp, \ptr, \tmp
macro>  	beqz	\tmp, \not_vmalloc		# not vmalloc
macro> +	 nop
macro>  	.endm


Thank you for pointing out this.  I did not think very much.  But you
mean "slt \tmp, \tmp, \ptr", don't you?

diff -u linux-mips-cvs/arch/mips64/mm/tlbex-r4k.S linux.new/arch/mips64/mm/tlbex-r4k.S
--- linux-mips-cvs/arch/mips64/mm/tlbex-r4k.S	Mon Apr 28 09:44:54 2003
+++ linux.new/arch/mips64/mm/tlbex-r4k.S	Wed Jun  4 09:45:48 2003
@@ -73,8 +73,9 @@
 	 * Determine that fault address is within vmalloc range.
 	 */
 	dla	\tmp, ekptbl
-	sltu	\tmp, \ptr, \tmp
+	slt	\tmp, \tmp, \ptr
 	beqz	\tmp, \not_vmalloc		# not vmalloc
+	 nop
 	.endm
 
 
---
Atsushi Nemoto

From krishnakumar@naturesoft.net Wed Jun  4 04:49:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 04:49:56 +0100 (BST)
Received: from [IPv6:::ffff:203.145.184.221] ([IPv6:::ffff:203.145.184.221]:30482
	"EHLO naturesoft.net") by linux-mips.org with ESMTP
	id <S8225192AbTFDDty> convert rfc822-to-8bit; Wed, 4 Jun 2003 04:49:54 +0100
Received: from [192.168.0.15] (helo=cork.royalchallenge.com)
	by naturesoft.net with esmtp (Exim 3.35 #1)
	id 19NPDN-0002Xr-00; Wed, 04 Jun 2003 09:15:29 +0530
Content-Type: text/plain;
  charset="us-ascii"
From: "Krishnakumar. R" <krishnakumar@naturesoft.net>
To: Ralf Baechle <ralf@linux-mips.org>
Subject: Single stepping in mips
Date: Wed, 4 Jun 2003 09:18:01 +0530
User-Agent: KMail/1.4.1
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Message-Id: <200306040918.01943.krishnakumar@naturesoft.net>
Return-Path: <krishnakumar@naturesoft.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2510
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: krishnakumar@naturesoft.net
Precedence: bulk
X-list: linux-mips

Hi,

How can we single step through an instruction 
in mips architecture. 

In intel 386 architecture if we set TF flag
of the EFLAGS register a trap will be generated
after every instruction. Is there a way in 
mips to do the same. 

Regards and Thanks
KK



From ilya@gateway.total-knowledge.com Wed Jun  4 05:20:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 05:20:44 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:36489
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225244AbTFDEUm>; Wed, 4 Jun 2003 05:20:42 +0100
Received: (qmail 15856 invoked by uid 502); 4 Jun 2003 04:20:38 -0000
Date: Tue, 3 Jun 2003 21:20:38 -0700
From: ilya@theIlya.com
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: [PATCH] vmlinux.lds.S
Message-ID: <20030604042037.GD7624@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2511
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips

Without this generated image is weired, and cannot be loaded.

Index: arch/mips64/vmlinux.lds.S
===================================================================
RCS file: /home/cvs/linux/arch/mips64/vmlinux.lds.S,v
retrieving revision 1.11
diff -u -r1.11 vmlinux.lds.S
--- arch/mips64/vmlinux.lds.S   3 Jun 2003 17:04:11 -0000       1.11
+++ arch/mips64/vmlinux.lds.S   4 Jun 2003 04:18:05 -0000
@@ -46,6 +46,7 @@
   __kallsyms : { *(__kallsyms) }
   __stop___kallsyms = .;
 
+  RODATA
   . = ALIGN(64);
 
   /* writeable */


From fpga_dsp@yahoo.com.au Wed Jun  4 06:12:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 06:12:26 +0100 (BST)
Received: from web41205.mail.yahoo.com ([IPv6:::ffff:66.218.93.38]:28777 "HELO
	web41205.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225244AbTFDFMW>; Wed, 4 Jun 2003 06:12:22 +0100
Message-ID: <20030604051214.7695.qmail@web41205.mail.yahoo.com>
Received: from [64.132.226.151] by web41205.mail.yahoo.com via HTTP; Wed, 04 Jun 2003 15:12:14 EST
Date: Wed, 4 Jun 2003 15:12:14 +1000 (EST)
From: =?iso-8859-1?q?fpga=20dsp?= <fpga_dsp@yahoo.com.au>
Subject: toolchains compiling, issue with i_am_not_a_leaf reference
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <fpga_dsp@yahoo.com.au>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2512
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fpga_dsp@yahoo.com.au
Precedence: bulk
X-list: linux-mips


Hi all,

I got trouble with compiling mipsel gnu toolchains.
Basicly, i downloaded all the required source code to
build a cross compiling toolchains for MIPS

binutils-2.13.90.0.10.tar.gz
gcc-3.2.tar.gz
glibc-2.2.5.tar.gz
glibc-linuxthreads-2.2.5.tar.gz
glibc-2.2.5-mips-build-gmon.diff

the building process went fine, i can compile kernel
and sereral packages, However, when I compile zlib
package with the toolchain, it complaint that can not
reference to i_am_not_a_leaf. Do a search on runtime
library, there is no such thing but clearly, this
external variable is declared in glibc csu/initfini.c.
The mipsel-linux-gcc remove this dummy variable
somehow. Now, i compile glibc using sdelinux-mipsel
from MIPS site. This compiler keeps the variable
reference in the object file. So end up I have to use
glibc compiled by sdelinux and gnu-gcc from gnu, a
problem with this is mipsel-linux-strip can't strip
library linked by sdelinux linkder. 

Anyone got any ideas why?

Many thanks!



http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

From ralf@linux-mips.org Wed Jun  4 06:18:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 06:18:28 +0100 (BST)
Received: from p508B7EE4.dip.t-dialin.net ([IPv6:::ffff:80.139.126.228]:32408
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225244AbTFDFS0>; Wed, 4 Jun 2003 06:18:26 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h545IMbY008420;
	Tue, 3 Jun 2003 22:18:22 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h545IJHJ008419;
	Wed, 4 Jun 2003 07:18:19 +0200
Date: Wed, 4 Jun 2003 07:18:18 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Krishnakumar. R" <krishnakumar@naturesoft.net>
Cc: linux-mips@linux-mips.org
Subject: Re: Single stepping in mips
Message-ID: <20030604051818.GA2365@linux-mips.org>
References: <200306040918.01943.krishnakumar@naturesoft.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200306040918.01943.krishnakumar@naturesoft.net>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2513
X-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, Jun 04, 2003 at 09:18:01AM +0530, Krishnakumar. R wrote:

> How can we single step through an instruction 
> in mips architecture. 
> 
> In intel 386 architecture if we set TF flag
> of the EFLAGS register a trap will be generated
> after every instruction. Is there a way in 
> mips to do the same. 

On most MIPS processors there is no singlestepping feature.  You have to
manual insert a breakpoint into the instruction stream and deal with the
exception.

  Ralf

From krishnakumar@naturesoft.net Wed Jun  4 06:39:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 06:39:40 +0100 (BST)
Received: from [IPv6:::ffff:203.145.184.221] ([IPv6:::ffff:203.145.184.221]:51461
	"EHLO naturesoft.net") by linux-mips.org with ESMTP
	id <S8225244AbTFDFjh> convert rfc822-to-8bit; Wed, 4 Jun 2003 06:39:37 +0100
Received: from [192.168.0.15] (helo=cork.royalchallenge.com)
	by naturesoft.net with esmtp (Exim 3.35 #1)
	id 19NQvi-0004PA-00; Wed, 04 Jun 2003 11:05:22 +0530
Content-Type: text/plain;
  charset="iso-8859-1"
From: "Krishnakumar. R" <krishnakumar@naturesoft.net>
To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Single stepping in mips
Date: Wed, 4 Jun 2003 11:07:55 +0530
User-Agent: KMail/1.4.1
References: <200306040918.01943.krishnakumar@naturesoft.net> <20030604051818.GA2365@linux-mips.org>
In-Reply-To: <20030604051818.GA2365@linux-mips.org>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Message-Id: <200306041107.55492.krishnakumar@naturesoft.net>
Return-Path: <krishnakumar@naturesoft.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2514
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: krishnakumar@naturesoft.net
Precedence: bulk
X-list: linux-mips

Hi,

> On most MIPS processors there is no singlestepping feature.  You have to
> manual insert a breakpoint into the instruction stream and deal with the
> exception.
>
>   Ralf

But if we insert a Break point into the instruction stream the exception
will be generated before the execution of the real instruction.
That means.
If we have the following set of instructions

addr1: instr1
addr2: instr2
addr3: instr3


if we replace instr1 by break.

addr1: break
addr2: instr2
addr3: instr3

we will get a break point exception as soon as the break
in addr1 is executed (correct me if I have wrongly understood !! )

But the need is to raise an exception after instr1 (at addr1) is executed.
One solution is using a break at instr2 (at addr2).
But suppose instr1 is a jmp then there is no point
in keeping a break at addr2.
(inorder to raise an exception after instr1 is executed).

So is there some other clean way for this ?


Regards and Thanks
KK












From ralf@linux-mips.org Wed Jun  4 06:53:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 06:53:22 +0100 (BST)
Received: from p508B7EE4.dip.t-dialin.net ([IPv6:::ffff:80.139.126.228]:35994
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225244AbTFDFxU>; Wed, 4 Jun 2003 06:53:20 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h545rJbY009154;
	Tue, 3 Jun 2003 22:53:19 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h545rJ7Y009153;
	Wed, 4 Jun 2003 07:53:19 +0200
Date: Wed, 4 Jun 2003 07:53:19 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Krishnakumar. R" <krishnakumar@naturesoft.net>
Cc: linux-mips@linux-mips.org
Subject: Re: Single stepping in mips
Message-ID: <20030604055319.GB8778@linux-mips.org>
References: <200306040918.01943.krishnakumar@naturesoft.net> <20030604051818.GA2365@linux-mips.org> <200306041107.55492.krishnakumar@naturesoft.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200306041107.55492.krishnakumar@naturesoft.net>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2515
X-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, Jun 04, 2003 at 11:07:55AM +0530, Krishnakumar. R wrote:

> we will get a break point exception as soon as the break
> in addr1 is executed (correct me if I have wrongly understood !! )
> 
> But the need is to raise an exception after instr1 (at addr1) is executed.
> One solution is using a break at instr2 (at addr2).
> But suppose instr1 is a jmp then there is no point
> in keeping a break at addr2.
> (inorder to raise an exception after instr1 is executed).

You understood correctly.  Now jumps and even more so the conditional
branches are sort of the ugly part of the whole thing.  The easiest
method is probably inserting a branch at the jump's destination address
or in case of a branch at the branch target and the instruction following
it's delay slot.  So that's a lot of inserting and removing of
breakpoints ...

  Ralf

From jbglaw@dvmwest.gt.owl.de Wed Jun  4 07:52:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 07:52:23 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:65029 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225244AbTFDGwU>; Wed, 4 Jun 2003 07:52:20 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 9064E4AB9E; Wed,  4 Jun 2003 08:52:17 +0200 (CEST)
Date: Wed, 4 Jun 2003 08:52:16 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: [PATCH] vmlinux.lds.S
Message-ID: <20030604065216.GN30457@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030604042037.GD7624@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="GEn4szYucjS2InE7"
Content-Disposition: inline
In-Reply-To: <20030604042037.GD7624@gateway.total-knowledge.com>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
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: 2516
X-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


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

On Tue, 2003-06-03 21:20:38 -0700, ilya@theIlya.com <ilya@theIlya.com>
wrote in message <20030604042037.GD7624@gateway.total-knowledge.com>:
> Without this generated image is weired, and cannot be loaded.
>=20
> Index: arch/mips64/vmlinux.lds.S
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /home/cvs/linux/arch/mips64/vmlinux.lds.S,v
> retrieving revision 1.11
> diff -u -r1.11 vmlinux.lds.S
> --- arch/mips64/vmlinux.lds.S   3 Jun 2003 17:04:11 -0000       1.11
> +++ arch/mips64/vmlinux.lds.S   4 Jun 2003 04:18:05 -0000
> @@ -46,6 +46,7 @@
>    __kallsyms : { *(__kallsyms) }
>    __stop___kallsyms =3D .;
> =20
> +  RODATA
>    . =3D ALIGN(64);
> =20
>    /* writeable */


This is for 2.5.x? Maybe that's even what prevents my Indy to boot
(using a 32bit kernel). I'll test that tonight;)

MfG, JBG

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

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

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

iD8DBQE+3ZcgHb1edYOZ4bsRAtWCAJ0d2R1X5hmrHhfm26eekjg9pDT5DQCeOIwD
+XsLYozv7PrHgEbp2j522SE=
=z/tK
-----END PGP SIGNATURE-----

--GEn4szYucjS2InE7--

From macro@ds2.pg.gda.pl Wed Jun  4 15:08:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 15:08:29 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:9617 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225253AbTFDOI1>; Wed, 4 Jun 2003 15:08:27 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA20159;
	Wed, 4 Jun 2003 16:09:11 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 4 Jun 2003 16:09:10 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: mips64 LOAD_KPTE2 fix
In-Reply-To: <20030604.100204.74756139.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.GSO.3.96.1030604160418.18707B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2517
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 4 Jun 2003, Atsushi Nemoto wrote:

> macro> diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030505.macro/arch/mips64/mm/tlbex-r4k.S linux-mips-2.4.21-pre4-20030505/arch/mips64/mm/tlbex-r4k.S
> macro> --- linux-mips-2.4.21-pre4-20030505.macro/arch/mips64/mm/tlbex-r4k.S	2003-04-27 02:56:39.000000000 +0000
> macro> +++ linux-mips-2.4.21-pre4-20030505/arch/mips64/mm/tlbex-r4k.S	2003-06-03 12:54:41.000000000 +0000
> macro> @@ -73,8 +73,9 @@
> macro>  	 * Determine that fault address is within vmalloc range.
> macro>  	 */
> macro>  	dla	\tmp, ekptbl
> macro> -	sltu	\tmp, \ptr, \tmp
> macro> +	slt	\tmp, \ptr, \tmp
> macro>  	beqz	\tmp, \not_vmalloc		# not vmalloc
> macro> +	 nop
> macro>  	.endm
> 
> 
> Thank you for pointing out this.  I did not think very much.  But you
> mean "slt \tmp, \tmp, \ptr", don't you?

 Not at all.  Why would I want to reverse the comparison? 

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


From macro@ds2.pg.gda.pl Wed Jun  4 15:15:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 15:15:56 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:33169 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225255AbTFDOPy>; Wed, 4 Jun 2003 15:15:54 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA20290;
	Wed, 4 Jun 2003 16:16:48 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 4 Jun 2003 16:16:48 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: "Krishnakumar. R" <krishnakumar@naturesoft.net>,
	linux-mips@linux-mips.org
Subject: Re: Single stepping in mips
In-Reply-To: <20030604055319.GB8778@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030604161038.18707C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2518
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 4 Jun 2003, Ralf Baechle wrote:

> > But the need is to raise an exception after instr1 (at addr1) is executed.
> > One solution is using a break at instr2 (at addr2).
> > But suppose instr1 is a jmp then there is no point
> > in keeping a break at addr2.
> > (inorder to raise an exception after instr1 is executed).
> 
> You understood correctly.  Now jumps and even more so the conditional
> branches are sort of the ugly part of the whole thing.  The easiest
> method is probably inserting a branch at the jump's destination address
> or in case of a branch at the branch target and the instruction following
> it's delay slot.  So that's a lot of inserting and removing of
> breakpoints ...

 In a more finegrained but also more complicated example, you probably
want to insert a breakpoint in the delay slot first and at the second step
evaluate the branch's condition and put a breakpoint at the next
instruction to be executed.  I'm not sure if the current version of gdb
does the first step, but it inserts a single breakpoint in the second one
only.  For branch likely instructions adjust the two steps as necessary. 

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


From drow@false.org Wed Jun  4 15:26:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 15:26:05 +0100 (BST)
Received: from crack.them.org ([IPv6:::ffff:146.82.138.56]:49605 "EHLO
	crack.them.org") by linux-mips.org with ESMTP id <S8225255AbTFDO0C>;
	Wed, 4 Jun 2003 15:26:02 +0100
Received: from dsl093-172-017.pit1.dsl.speakeasy.net
	([66.93.172.17] helo=nevyn.them.org ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 19NZDj-0002Up-00; Wed, 04 Jun 2003 09:26:31 -0500
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 19NZD2-00051t-00; Wed, 04 Jun 2003 10:25:48 -0400
Date: Wed, 4 Jun 2003 10:25:48 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	"Krishnakumar. R" <krishnakumar@naturesoft.net>,
	linux-mips@linux-mips.org
Subject: Re: Single stepping in mips
Message-ID: <20030604142548.GA19282@nevyn.them.org>
References: <20030604055319.GB8778@linux-mips.org> <Pine.GSO.3.96.1030604161038.18707C-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030604161038.18707C-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@false.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2519
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Wed, Jun 04, 2003 at 04:16:48PM +0200, Maciej W. Rozycki wrote:
> On Wed, 4 Jun 2003, Ralf Baechle wrote:
> 
> > > But the need is to raise an exception after instr1 (at addr1) is executed.
> > > One solution is using a break at instr2 (at addr2).
> > > But suppose instr1 is a jmp then there is no point
> > > in keeping a break at addr2.
> > > (inorder to raise an exception after instr1 is executed).
> > 
> > You understood correctly.  Now jumps and even more so the conditional
> > branches are sort of the ugly part of the whole thing.  The easiest
> > method is probably inserting a branch at the jump's destination address
> > or in case of a branch at the branch target and the instruction following
> > it's delay slot.  So that's a lot of inserting and removing of
> > breakpoints ...
> 
>  In a more finegrained but also more complicated example, you probably
> want to insert a breakpoint in the delay slot first and at the second step
> evaluate the branch's condition and put a breakpoint at the next
> instruction to be executed.  I'm not sure if the current version of gdb
> does the first step, but it inserts a single breakpoint in the second one
> only.  For branch likely instructions adjust the two steps as necessary. 

Does that actually work reliably across MIPS processors?  I don't
believe that it will.  I suppose you could re-execute the branch to get
the delay slot executed...

GDB simply executes the branch and its delay slot as a unit.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ralf@linux-mips.org Wed Jun  4 15:32:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 15:32:43 +0100 (BST)
Received: from p508B7EE4.dip.t-dialin.net ([IPv6:::ffff:80.139.126.228]:49083
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225252AbTFDOcl>; Wed, 4 Jun 2003 15:32:41 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h54EWXbY007586;
	Wed, 4 Jun 2003 07:32:34 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h54EWWwH007561;
	Wed, 4 Jun 2003 16:32:32 +0200
Date: Wed, 4 Jun 2003 16:32:32 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	"Krishnakumar. R" <krishnakumar@naturesoft.net>,
	linux-mips@linux-mips.org
Subject: Re: Single stepping in mips
Message-ID: <20030604143232.GF25456@linux-mips.org>
References: <20030604055319.GB8778@linux-mips.org> <Pine.GSO.3.96.1030604161038.18707C-100000@delta.ds2.pg.gda.pl> <20030604142548.GA19282@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030604142548.GA19282@nevyn.them.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2520
X-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, Jun 04, 2003 at 10:25:48AM -0400, Daniel Jacobowitz wrote:

> >  In a more finegrained but also more complicated example, you probably
> > want to insert a breakpoint in the delay slot first and at the second step
> > evaluate the branch's condition and put a breakpoint at the next
> > instruction to be executed.  I'm not sure if the current version of gdb
> > does the first step, but it inserts a single breakpoint in the second one
> > only.  For branch likely instructions adjust the two steps as necessary. 
> 
> Does that actually work reliably across MIPS processors?  I don't
> believe that it will.  I suppose you could re-execute the branch to get
> the delay slot executed...

It should.

  Ralf

From ilya@gateway.total-knowledge.com Wed Jun  4 16:00:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 16:00:40 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:39050
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225252AbTFDPAf>; Wed, 4 Jun 2003 16:00:35 +0100
Received: (qmail 22379 invoked by uid 502); 4 Jun 2003 15:00:26 -0000
Date: Wed, 4 Jun 2003 08:00:25 -0700
From: ilya@theIlya.com
To: linux-mips@linux-mips.org
Subject: Re: [PATCH] vmlinux.lds.S
Message-ID: <20030604150025.GE7624@gateway.total-knowledge.com>
References: <20030604042037.GD7624@gateway.total-knowledge.com> <20030604065216.GN30457@lug-owl.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="t0UkRYy7tHLRMCai"
Content-Disposition: inline
In-Reply-To: <20030604065216.GN30457@lug-owl.de>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2521
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

Yeap, this is for 2.5.59
Not anything earlier.
Without this patch PROM will tell you there is not enough memory to load th=
e image.
On Wed, Jun 04, 2003 at 08:52:16AM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2003-06-03 21:20:38 -0700, ilya@theIlya.com <ilya@theIlya.com>
> wrote in message <20030604042037.GD7624@gateway.total-knowledge.com>:
> > Without this generated image is weired, and cannot be loaded.
> >=20
> > Index: arch/mips64/vmlinux.lds.S
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > RCS file: /home/cvs/linux/arch/mips64/vmlinux.lds.S,v
> > retrieving revision 1.11
> > diff -u -r1.11 vmlinux.lds.S
> > --- arch/mips64/vmlinux.lds.S   3 Jun 2003 17:04:11 -0000       1.11
> > +++ arch/mips64/vmlinux.lds.S   4 Jun 2003 04:18:05 -0000
> > @@ -46,6 +46,7 @@
> >    __kallsyms : { *(__kallsyms) }
> >    __stop___kallsyms =3D .;
> > =20
> > +  RODATA
> >    . =3D ALIGN(64);
> > =20
> >    /* writeable */
>=20
>=20
> This is for 2.5.x? Maybe that's even what prevents my Indy to boot
> (using a 32bit kernel). I'll test that tonight;)
>=20
> MfG, JBG
>=20
> --=20
>    Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
>    "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Kr=
ieg
>     fuer einen Freien Staat voll Freier B?rger" | im Internet! |   im Ira=
k!
>       ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA=
));



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

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

iD8DBQE+3gmJ7sVBmHZT8w8RAv0aAKCpPMTnoVjIBcT6+KYLd3Aps6FS7gCeMKG2
AIpDE60kWEWBYYuaC6cVCqM=
=Uf8M
-----END PGP SIGNATURE-----

--t0UkRYy7tHLRMCai--

From jbglaw@dvmwest.gt.owl.de Wed Jun  4 21:33:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 21:33:15 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:37648 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225252AbTFDUdN>; Wed, 4 Jun 2003 21:33:13 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 9A4124AB90; Wed,  4 Jun 2003 22:33:10 +0200 (CEST)
Date: Wed, 4 Jun 2003 22:33:10 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: [PATCH] vmlinux.lds.S
Message-ID: <20030604203310.GS30457@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030604042037.GD7624@gateway.total-knowledge.com> <20030604065216.GN30457@lug-owl.de> <20030604150025.GE7624@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="uNvczuo8OWfsyO2w"
Content-Disposition: inline
In-Reply-To: <20030604150025.GE7624@gateway.total-knowledge.com>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
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: 2522
X-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


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

On Wed, 2003-06-04 08:00:25 -0700, ilya@theIlya.com <ilya@theIlya.com>
wrote in message <20030604150025.GE7624@gateway.total-knowledge.com>:
> Yeap, this is for 2.5.59
> Not anything earlier.
> Without this patch PROM will tell you there is not enough memory to load =
the image.

My machine simply freezed. Looking at a tcpdump, I saw an error code
wich evaluates to "ELF allocation exceeded" - sounds pretty much like
your error...

MfG, JBG

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

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

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

iD4DBQE+3leGHb1edYOZ4bsRArJRAJiXGeaUKGYDG0csN0dnmlb5sbgtAJ9C2vrP
Jwk5bW89/L50nWqK/9r4bA==
=1cE9
-----END PGP SIGNATURE-----

--uNvczuo8OWfsyO2w--

From jsun@mvista.com Wed Jun  4 23:39:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 23:39:35 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:30197 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225252AbTFDWjc>;
	Wed, 4 Jun 2003 23:39:32 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h54MdUV20207;
	Wed, 4 Jun 2003 15:39:30 -0700
Date: Wed, 4 Jun 2003 15:39:30 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [RFC] synchronized CPU count registers on SMP machines
Message-ID: <20030604153930.H19122@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2523
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


There are many benefits of having perfectly synchronized CPU
count registers on SMP machines.

I wonder if this is something which have been done before,
and if this is feasible.

Apparently, this scheme won't work if any of the following
conditions are true:

1) clocks on different CPUs don't have the same frequency
2) clocks on different CPUs drift to each other
2) some fancy power saving feature such as frequency scaling

But I think for a foreseeable future most MIPS SMP machines
don't have the above issues (true?).  And it is probably worthwile
to synchronize count registers for them.

I think some pseudo code like the below could get the 
job done:

CPU 0:
	send interrupt to all other CPUs and ask them to sync count
	wait for all other CPUs to gather at rendevous point
	flip a flag
	set count to 0

other CPUs:
	trapped by IPI
	reach the rendevous point (busy spin locking)
	wait for the flip of the flag
	set count to 0

I wonder after the above code how synchronized are the count regsiters.
Are they perfectly synchronized or still differ by a few counts?

Any comments?

Jun

From uhler@mips.com Wed Jun  4 23:53:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jun 2003 23:53:09 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:45018 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225252AbTFDWxI>;
	Wed, 4 Jun 2003 23:53:08 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h54MquUe027562;
	Wed, 4 Jun 2003 15:52:56 -0700 (PDT)
Received: from laptopuhler ([192.168.1.142])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id PAA27894;
	Wed, 4 Jun 2003 15:52:53 -0700 (PDT)
From: "Michael Uhler" <uhler@mips.com>
To: "'Jun Sun'" <jsun@mvista.com>, <linux-mips@linux-mips.org>
Subject: RE: [RFC] synchronized CPU count registers on SMP machines
Date: Wed, 4 Jun 2003 15:51:49 -0700
Organization: MIPS Technologies, Inc
Message-ID: <002701c32aeb$e4743cd0$08c0a8c0@MIPS.COM>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <20030604153930.H19122@mvista.com>
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2524
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips

See interspersed comments.

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Jun Sun
> Sent: Wednesday, June 04, 2003 3:40 PM
> To: linux-mips@linux-mips.org
> Cc: jsun@mvista.com
> Subject: [RFC] synchronized CPU count registers on SMP machines
> 
> 
> 
> There are many benefits of having perfectly synchronized CPU 
> count registers on SMP machines.
> 
> I wonder if this is something which have been done before,
> and if this is feasible.

I remember doing something like this about 20 years ago on a much
different operating system in which the goal was to move the count
registers apart by a predictable amount such that a clock interrupt
didn't occur on all the CPUs at once.  But even in that case, we weren't
looking for precise matching.
> 
> Apparently, this scheme won't work if any of the following 
> conditions are true:
> 
> 1) clocks on different CPUs don't have the same frequency
> 2) clocks on different CPUs drift to each other

Depending on the precise system configuration (including whether the
CPUs are on different SOCs, different boards, where the PLLs are, and
what the ultimate clock source is), I'd guess that drift is pretty
likely on almost all systems unless the clocks are intentionally driven
by some sort of synchronize source.

> 2) some fancy power saving feature such as frequency scaling
> 
> But I think for a foreseeable future most MIPS SMP machines 
> don't have the above issues (true?).  And it is probably 
> worthwile to synchronize count registers for them.
> 
> I think some pseudo code like the below could get the 
> job done:
> 
> CPU 0:
> 	send interrupt to all other CPUs and ask them to sync count
> 	wait for all other CPUs to gather at rendevous point
> 	flip a flag
> 	set count to 0
> 
> other CPUs:
> 	trapped by IPI
> 	reach the rendevous point (busy spin locking)
> 	wait for the flip of the flag
> 	set count to 0

The biggest problem here is latency on the spinlocks and observation of
the flag state changing.  Depending on the memory architecture, the
point at which each CPU will see the change could be very different
(consider a NUMA mesh architecture in which the data movement can take
different paths).  As such, you could see on order of memory latency
different in the clocks.

You could run a counter adjustment periodically, or try to calibrate the
adjustment to make this closer, but I'm not sure that you can get
perfect synchronization.

> 
> I wonder after the above code how synchronized are the count 
> regsiters. Are they perfectly synchronized or still differ by 
> a few counts?
> 
> Any comments?
> 
> Jun
> 
> 



From ralf@linux-mips.org Thu Jun  5 00:15:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 00:15:54 +0100 (BST)
Received: from p508B7EE4.dip.t-dialin.net ([IPv6:::ffff:80.139.126.228]:21723
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225252AbTFDXPw>; Thu, 5 Jun 2003 00:15:52 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h54NFnbY029013;
	Wed, 4 Jun 2003 16:15:49 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h54NFmww029012;
	Thu, 5 Jun 2003 01:15:48 +0200
Date: Thu, 5 Jun 2003 01:15:47 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Message-ID: <20030604231547.GA22410@linux-mips.org>
References: <20030604153930.H19122@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030604153930.H19122@mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2525
X-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, Jun 04, 2003 at 03:39:30PM -0700, Jun Sun wrote:

> 1) clocks on different CPUs don't have the same frequency
> 2) clocks on different CPUs drift to each other
> 2) some fancy power saving feature such as frequency scaling
> 
> But I think for a foreseeable future most MIPS SMP machines
> don't have the above issues (true?).  And it is probably worthwile
> to synchronize count registers for them.

1) and 2) affect most SGI systems.

  Ralf

From jsun@mvista.com Thu Jun  5 00:44:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 00:44:35 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:20726 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225263AbTFDXoX>;
	Thu, 5 Jun 2003 00:44:23 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h54NiLc24415;
	Wed, 4 Jun 2003 16:44:21 -0700
Date: Wed, 4 Jun 2003 16:44:20 -0700
From: Jun Sun <jsun@mvista.com>
To: Michael Uhler <uhler@mips.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Message-ID: <20030604164420.I19122@mvista.com>
References: <20030604153930.H19122@mvista.com> <002701c32aeb$e4743cd0$08c0a8c0@MIPS.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <002701c32aeb$e4743cd0$08c0a8c0@MIPS.COM>; from uhler@mips.com on Wed, Jun 04, 2003 at 03:51:49PM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2526
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, Jun 04, 2003 at 03:51:49PM -0700, Michael Uhler wrote:
<snip>
> > 
> > Apparently, this scheme won't work if any of the following 
> > conditions are true:
> > 
> > 1) clocks on different CPUs don't have the same frequency
> > 2) clocks on different CPUs drift to each other
> 
> Depending on the precise system configuration (including whether the
> CPUs are on different SOCs, different boards, where the PLLs are, and
> what the ultimate clock source is), I'd guess that drift is pretty
> likely on almost all systems unless the clocks are intentionally driven
> by some sort of synchronize source.
>

Yes, if there are physically multiple boards, it is likely to have
drifting clocks.

I don't suppose the count synchronization code will work for
all SMP systems.  I hope to get an idea whether it is worth the effort
for the systems that it does work.

For example, it will work on Broadcom's BCM91250 chip and probably a
couple of coming ones.

To give an idea of my original motivation on this RFC, I found out
it is pretty _hard_ just to get a micro-second resolution gettimeofday()
on a SMP system.  And apparently this is an issue on other arches
as well.  I think i386 uses synchronized TSCs, which is the same
idea as what we are talking about here.

> The biggest problem here is latency on the spinlocks and observation of
> the flag state changing.  Depending on the memory architecture, the
> point at which each CPU will see the change could be very different
> (consider a NUMA mesh architecture in which the data movement can take
> different paths).  As such, you could see on order of memory latency
> different in the clocks.
>

If it is a few clocks in difference, it should be acceptable.

Basically, imagine a spin lock protected read_count routine:

unsigned read_count() 
{
	spin_lock(&count_lock);
	count = read_c0_count();
	spin_unlock(&count_lock);
	return count;
}

and imagine there are randomly calls to this function by different
CPUs, the calls are serialized due to the spinlock.  As long as
the return values are monotonically increasing, we are fine.

Thanks for the reply.  And congrads on your new post. :)

Jun

From jsun@mvista.com Thu Jun  5 00:46:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 00:46:55 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:47094 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225241AbTFDXqx>;
	Thu, 5 Jun 2003 00:46:53 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h54Nkqm24427;
	Wed, 4 Jun 2003 16:46:52 -0700
Date: Wed, 4 Jun 2003 16:46:52 -0700
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Message-ID: <20030604164652.J19122@mvista.com>
References: <20030604153930.H19122@mvista.com> <20030604231547.GA22410@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030604231547.GA22410@linux-mips.org>; from ralf@linux-mips.org on Thu, Jun 05, 2003 at 01:15:47AM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2527
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Jun 05, 2003 at 01:15:47AM +0200, Ralf Baechle wrote:
> On Wed, Jun 04, 2003 at 03:39:30PM -0700, Jun Sun wrote:
> 
> > 1) clocks on different CPUs don't have the same frequency
> > 2) clocks on different CPUs drift to each other
> > 2) some fancy power saving feature such as frequency scaling
> > 
> > But I think for a foreseeable future most MIPS SMP machines
> > don't have the above issues (true?).  And it is probably worthwile
> > to synchronize count registers for them.
> 
> 1) and 2) affect most SGI systems.
>

Assuming SGI systems represent the past of MIPS, we are still ok
future-wise. :)

Jun

From ralf@linux-mips.org Thu Jun  5 01:12:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 01:12:36 +0100 (BST)
Received: from p508B7EE4.dip.t-dialin.net ([IPv6:::ffff:80.139.126.228]:50654
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225241AbTFEAMe>; Thu, 5 Jun 2003 01:12:34 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h550CXbY006014;
	Wed, 4 Jun 2003 17:12:33 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h550CW2O006013;
	Thu, 5 Jun 2003 02:12:33 +0200
Date: Thu, 5 Jun 2003 02:12:32 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Message-ID: <20030605001232.GA5626@linux-mips.org>
References: <20030604153930.H19122@mvista.com> <20030604231547.GA22410@linux-mips.org> <20030604164652.J19122@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030604164652.J19122@mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2528
X-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, Jun 04, 2003 at 04:46:52PM -0700, Jun Sun wrote:

> Assuming SGI systems represent the past of MIPS, we are still ok
> future-wise. :)

You loose.  The reasons why SGI did construct their systems that way are
still valid.  It can be quite tricky to distribute the clock in large
systems - even for a moderate definition of large.  And for ccNUMAs which
are going to show up on the embedded market sooner or later it's easy
for the lazy designer to use several clock sources anyway.  Note our
current time code for will not work properly if clocks diverge on the
slightest bit - among other things the standards mandate time to
monotonically increase.

  Ralf

From kaos@sgi.com Thu Jun  5 01:18:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 01:18:47 +0100 (BST)
Received: from mail.ocs.com.au ([IPv6:::ffff:203.34.97.2]:22788 "HELO
	mail.ocs.com.au") by linux-mips.org with SMTP id <S8225271AbTFEASp>;
	Thu, 5 Jun 2003 01:18:45 +0100
Received: (qmail 31381 invoked from network); 5 Jun 2003 00:18:35 -0000
Received: from ocs3.intra.ocs.com.au (192.168.255.3)
  by mail.ocs.com.au with SMTP; 5 Jun 2003 00:18:35 -0000
Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331)
	id D2B9FD8F46; Thu,  5 Jun 2003 10:18:33 +1000 (EST)
Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1])
	by ocs3.intra.ocs.com.au (Postfix) with ESMTP id D012791336
	for <linux-mips@linux-mips.org>; Thu,  5 Jun 2003 10:18:33 +1000 (EST)
X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4
From: Keith Owens <kaos@sgi.com>
To: linux-mips@linux-mips.org
Subject: Re: [RFC] synchronized CPU count registers on SMP machines 
In-reply-to: Your message of "Wed, 04 Jun 2003 15:39:30 MST."
             <20030604153930.H19122@mvista.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 05 Jun 2003 10:18:28 +1000
Message-ID: <9636.1054772308@ocs3.intra.ocs.com.au>
Return-Path: <kaos@sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2529
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@sgi.com
Precedence: bulk
X-list: linux-mips

On Wed, 4 Jun 2003 15:39:30 -0700, 
Jun Sun <jsun@mvista.com> wrote:
>There are many benefits of having perfectly synchronized CPU
>count registers on SMP machines.
>
>I wonder if this is something which have been done before,
>and if this is feasible.

IA64 has to do this, arch/ia64/kernel/smpboot.c:ia64_sync_itc.  That
function is only called at boot time, but there have been discussions
about calling it regularly to resync the itc values, like NTP.  Of
course, it has no chance of working if you install cpus with different
itc frequencies.


From anemo@mba.ocn.ne.jp Thu Jun  5 01:57:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 01:57:39 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:273 "HELO
	topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225241AbTFEA5g>; Thu, 5 Jun 2003 01:57:36 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 5 Jun 2003 00:57:34 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h550vKjf028992;
	Thu, 5 Jun 2003 09:57:20 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 05 Jun 2003 09:58:02 +0900 (JST)
Message-Id: <20030605.095802.59461340.nemoto@toshiba-tops.co.jp>
To: macro@ds2.pg.gda.pl
Cc: anemo@mba.ocn.ne.jp, linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: mips64 LOAD_KPTE2 fix
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.GSO.3.96.1030604160418.18707B-100000@delta.ds2.pg.gda.pl>
References: <20030604.100204.74756139.nemoto@toshiba-tops.co.jp>
	<Pine.GSO.3.96.1030604160418.18707B-100000@delta.ds2.pg.gda.pl>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2530
X-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, 4 Jun 2003 16:09:10 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:
>> Thank you for pointing out this.  I did not think very much.  But
>> you mean "slt \tmp, \tmp, \ptr", don't you?

macro>  Not at all.  Why would I want to reverse the comparison?

Sorry, I garbled.  Please ignore my last patch.  Your patch works
fine.  Thank you again.

---
Atsushi Nemoto

From jsun@mvista.com Thu Jun  5 02:38:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 02:38:39 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27389 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225241AbTFEBih>;
	Thu, 5 Jun 2003 02:38:37 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h551caE00805;
	Wed, 4 Jun 2003 18:38:36 -0700
Date: Wed, 4 Jun 2003 18:38:36 -0700
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Message-ID: <20030604183836.B25414@mvista.com>
References: <20030604153930.H19122@mvista.com> <20030604231547.GA22410@linux-mips.org> <20030604164652.J19122@mvista.com> <20030605001232.GA5626@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030605001232.GA5626@linux-mips.org>; from ralf@linux-mips.org on Thu, Jun 05, 2003 at 02:12:32AM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2531
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Jun 05, 2003 at 02:12:32AM +0200, Ralf Baechle wrote:
> On Wed, Jun 04, 2003 at 04:46:52PM -0700, Jun Sun wrote:
> 
> > Assuming SGI systems represent the past of MIPS, we are still ok
> > future-wise. :)
> 
> You loose.  The reasons why SGI did construct their systems that way are
> still valid.  It can be quite tricky to distribute the clock in large
> systems - even for a moderate definition of large.  And for ccNUMAs which
> are going to show up on the embedded market sooner or later it's easy
> for the lazy designer to use several clock sources anyway.  Note our
> current time code for will not work properly if clocks diverge on the
> slightest bit - among other things the standards mandate time to
> monotonically increase.
>

Aside from aficionado of SGI legacy, do you see any value in
implementing this just for the applicable SMP systems?

Here is my take:

To implement an efficient and correct time management in SMP
is a hard problem.  I don't think there is a generic solution
here.  (Convince me if I am wrong.)

Therefore for a set of "conforming" SMP systems which don't
have the listed 3 issues, we provide a feasible solution.
I don't see how we can avoid this - unless we don't care about
getting time right.

Jun

From dom@mips.com Thu Jun  5 09:09:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 09:09:51 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:40717 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225241AbTFEIJs>;
	Thu, 5 Jun 2003 09:09: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 19Nprv-0000hj-00; Thu, 05 Jun 2003 09:13:07 +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 19Npo1-0006vT-00; Thu, 05 Jun 2003 09:09:05 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16094.64161.12926.645512@doms-laptop.algor.co.uk>
Date: Thu, 5 Jun 2003 09:09:05 +0100
To: Jun Sun <jsun@mvista.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
In-Reply-To: <20030604183836.B25414@mvista.com>
References: <20030604153930.H19122@mvista.com>
	<20030604231547.GA22410@linux-mips.org>
	<20030604164652.J19122@mvista.com>
	<20030605001232.GA5626@linux-mips.org>
	<20030604183836.B25414@mvista.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=-17.4, required 4, AWL,
	BAYES_01, QUOTED_EMAIL_TEXT, REFERENCES)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2532
X-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



> Therefore for a set of "conforming" SMP systems which don't
> have the listed 3 issues, we provide a feasible solution.
> I don't see how we can avoid this - unless we don't care about
> getting time right.

Interesting.  I guess you only need to get time "right enough" -
there's an unavoidable fuzziness about the synchronisation of events
on different CPUs (corresponding to the uncertainties of the timing of
any rendezvous between them).

A naive network synchronisation protocol - analogous to your first
proposal - would leave clocks differing by a network round-trip time
or so: but NTP does a lot better.  So in principle you should be able
to scale NTP to create a clock synchronised within some fraction of
the time taken by a CPU-to-CPU communication... but compressing the
essence of the NTP protocol into something which runs fast enough
might be interesting!

My 5-minutes-over-breakfast feeling is that you should be able to
figure out a way to get time right enough; try reading up how NTP
works and see whether it can be made to work?

--
Dominic


From kevink@mips.com Thu Jun  5 09:46:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 09:46:20 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:2692 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225241AbTFEIqR>;
	Thu, 5 Jun 2003 09:46:17 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h558k6Ue002824;
	Thu, 5 Jun 2003 01:46:06 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA28683;
	Thu, 5 Jun 2003 01:46:05 -0700 (PDT)
Message-ID: <019201c32b40$2d54cf60$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Jun Sun" <jsun@mvista.com>, "Ralf Baechle" <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>, <jsun@mvista.com>
References: <20030604153930.H19122@mvista.com> <20030604231547.GA22410@linux-mips.org> <20030604164652.J19122@mvista.com>
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Date: Thu, 5 Jun 2003 10:55:10 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2533
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips

----- Original Message ----- 
From: "Jun Sun" <jsun@mvista.com>
> On Thu, Jun 05, 2003 at 01:15:47AM +0200, Ralf Baechle wrote:
> > On Wed, Jun 04, 2003 at 03:39:30PM -0700, Jun Sun wrote:
> > 
> > > 1) clocks on different CPUs don't have the same frequency
> > > 2) clocks on different CPUs drift to each other
> > > 2) some fancy power saving feature such as frequency scaling
> > > 
> > > But I think for a foreseeable future most MIPS SMP machines
> > > don't have the above issues (true?).  And it is probably worthwile
> > > to synchronize count registers for them.
> > 
> > 1) and 2) affect most SGI systems.
> >
> 
> Assuming SGI systems represent the past of MIPS, we are still ok
> future-wise. :)

I personally think it would be foolish to assume that future MIPS 
MP systems will not be subject to one or more such constraint.

            Kevin K.

From ralf@linux-mips.org Thu Jun  5 09:48:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 09:48:57 +0100 (BST)
Received: from p508B4F3A.dip.t-dialin.net ([IPv6:::ffff:80.139.79.58]:41615
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225241AbTFEIsz>; Thu, 5 Jun 2003 09:48:55 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h558mrbY032697;
	Thu, 5 Jun 2003 01:48:53 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h558mqEj032696;
	Thu, 5 Jun 2003 10:48:52 +0200
Date: Thu, 5 Jun 2003 10:48:52 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Dominic Sweetman <dom@mips.com>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Message-ID: <20030605084852.GA25712@linux-mips.org>
References: <20030604153930.H19122@mvista.com> <20030604231547.GA22410@linux-mips.org> <20030604164652.J19122@mvista.com> <20030605001232.GA5626@linux-mips.org> <20030604183836.B25414@mvista.com> <16094.64161.12926.645512@doms-laptop.algor.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16094.64161.12926.645512@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: 2534
X-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, Jun 05, 2003 at 09:09:05AM +0100, Dominic Sweetman wrote:

> A naive network synchronisation protocol - analogous to your first
> proposal - would leave clocks differing by a network round-trip time
> or so: but NTP does a lot better.  So in principle you should be able
> to scale NTP to create a clock synchronised within some fraction of
> the time taken by a CPU-to-CPU communication... but compressing the
> essence of the NTP protocol into something which runs fast enough
> might be interesting!
> 
> My 5-minutes-over-breakfast feeling is that you should be able to
> figure out a way to get time right enough; try reading up how NTP
> works and see whether it can be made to work?

Yes, already been thinking about that.  The essence of NTP is a software
implementation of a phase locked loop.  The full NTP protocol is way to
heavy of course but the subset we're talking about would be rather
lightweight.  I'd expect the phase noise to be in the low ppb range,
little problems with unlocking.  And it'll be usable for arbitrary
combinations of clock frequencies.  So an approach to try.

Enjoy your breakfast :-)

  Ralf

From ralf@linux-mips.org Thu Jun  5 09:51:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 09:51:25 +0100 (BST)
Received: from p508B4F3A.dip.t-dialin.net ([IPv6:::ffff:80.139.79.58]:51855
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225241AbTFEIvX>; Thu, 5 Jun 2003 09:51:23 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h558pMbY032746;
	Thu, 5 Jun 2003 01:51:22 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h558pMtF032745;
	Thu, 5 Jun 2003 10:51:22 +0200
Date: Thu, 5 Jun 2003 10:51:22 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Message-ID: <20030605085122.GB25712@linux-mips.org>
References: <20030604153930.H19122@mvista.com> <20030604231547.GA22410@linux-mips.org> <20030604164652.J19122@mvista.com> <019201c32b40$2d54cf60$10eca8c0@grendel>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <019201c32b40$2d54cf60$10eca8c0@grendel>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2535
X-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, Jun 05, 2003 at 10:55:10AM +0200, Kevin D. Kissell wrote:

> I personally think it would be foolish to assume that future MIPS 
> MP systems will not be subject to one or more such constraint.

I'm expecting something like hypertransport-based ccNUMAs to bring up
that problem again.

  Ralf

From tor@spacetec.no Thu Jun  5 10:23:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 10:23:09 +0100 (BST)
Received: from firewall.spacetec.no ([IPv6:::ffff:192.51.5.5]:27611 "EHLO
	pallas.spacetec.no") by linux-mips.org with ESMTP
	id <S8225274AbTFEJXH>; Thu, 5 Jun 2003 10:23:07 +0100
Received: from pallas.spacetec.no (localhost [127.0.0.1])
	by pallas.spacetec.no (8.12.3/8.12.3) with ESMTP id h559N4QA009224
	for <linux-mips@linux-mips.org>; Thu, 5 Jun 2003 11:23:04 +0200
Received: (from tor@localhost)
	by pallas.spacetec.no (8.12.3/8.12.3/Debian-6.3) id h559N3dE009222
	for linux-mips@linux-mips.org; Thu, 5 Jun 2003 11:23:03 +0200
Message-Id: <200306050923.h559N3dE009222@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Thu, 5 Jun 2003 11:23:02 +0200
In-Reply-To: Ralf Baechle <ralf@linux-mips.org>
       "Re: [RFC] synchronized CPU count registers on SMP machines" (Jun  5,  0:27)
X-Mailer: Mail User's Shell (7.2.6 beta(4) 03/19/98)
To: linux-mips@linux-mips.org
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Return-Path: <tor@spacetec.no>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2536
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tor@spacetec.no
Precedence: bulk
X-list: linux-mips

On Jun 5,  0:27, Ralf Baechle wrote:
>On Wed, Jun 04, 2003 at 03:39:30PM -0700, Jun Sun wrote:
>
>> 1) clocks on different CPUs don't have the same frequency
>> 2) clocks on different CPUs drift to each other
>> 2) some fancy power saving feature such as frequency scaling
>> 
>> But I think for a foreseeable future most MIPS SMP machines
>> don't have the above issues (true?).  And it is probably worthwile
>> to synchronize count registers for them.
>
>1) and 2) affect most SGI systems.
>
>  Ralf

1) sometimes to the extreme, on SGI Challenge systems:
 
>hinv -c processor
Processor 0: 150 MHZ IP19 
CPU: MIPS R4400 Processor Chip Revision: 5.0
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
Processor 1: 150 MHZ IP19 
CPU: MIPS R4400 Processor Chip Revision: 5.0
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
Processor 2: 200 MHZ IP19 
CPU: MIPS R4400 Processor Chip Revision: 6.0
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
Processor 3: 200 MHZ IP19 
CPU: MIPS R4400 Processor Chip Revision: 6.0
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0

(and the secondary cache sizes are 1MB and 4MB respectively as well)

-Tor

From ashish.anand@inspiretech.com Thu Jun  5 11:01:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 11:01:09 +0100 (BST)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:9354
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8225241AbTFEKBH>; Thu, 5 Jun 2003 11:01:07 +0100
Received: from mail.inspiretech.com (mail.inspiretech.com [192.168.42.3])
	by smtp.inspirtek.com (8.12.5/8.12.5) with ESMTP id h55ARnI9031919
	for <linux-mips@linux-mips.org>; Thu, 5 Jun 2003 15:57:56 +0530
Message-Id: <200306051027.h55ARnI9031919@smtp.inspirtek.com>
Received: from WorldClient [192.168.42.3] by inspiretech.com [192.168.42.3]
	with SMTP (MDaemon.v3.5.7.R)
	for <linux-mips@linux-mips.org>; Thu, 05 Jun 2003 15:16:43 +0530
Date: Thu, 05 Jun 2003 15:16:41 +0530
From: "Ashish anand" <ashish.anand@inspiretech.com>
To: linux-mips@linux-mips.org
Subject: low ram as source of good parity data..?
X-Mailer: WorldClient Standard 3.5.0e
X-MDRemoteIP: 192.168.42.3
X-Return-Path: ashish.anand@inspiretech.com
X-MDaemon-Deliver-To: linux-mips@linux-mips.org
Return-Path: <ashish.anand@inspiretech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2537
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish.anand@inspiretech.com
Precedence: bulk
X-list: linux-mips

Hello,

I have seen it a common practice to assume low RAM as source 
of good parity data and use it to fill the caches with good parity 
data in firmware during elementary hardware initialisation process.

why it is always safe to assume that low RAM contains good parity data .?
Is it always true..?
this question came in picture after I got cacheparity error sometimes.

Best Regards,
Ashish Anand



From alan@lxorguk.ukuu.org.uk Thu Jun  5 11:47:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 11:47:33 +0100 (BST)
Received: from pc2-cwma1-4-cust86.swan.cable.ntl.com ([IPv6:::ffff:213.105.254.86]:50310
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8225241AbTFEKra>; Thu, 5 Jun 2003 11:47:30 +0100
Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.8/8.12.5) with ESMTP id h55Aj6RQ015388;
	Thu, 5 Jun 2003 11:45:07 +0100
Received: (from alan@localhost)
	by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h55Aj4bE015386;
	Thu, 5 Jun 2003 11:45:04 +0100
X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
In-Reply-To: <20030605001232.GA5626@linux-mips.org>
References: <20030604153930.H19122@mvista.com>
	 <20030604231547.GA22410@linux-mips.org> <20030604164652.J19122@mvista.com>
	 <20030605001232.GA5626@linux-mips.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1054809902.15275.11.camel@dhcp22.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 05 Jun 2003 11:45:03 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2538
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Iau, 2003-06-05 at 01:12, Ralf Baechle wrote:
> You loose.  The reasons why SGI did construct their systems that way are
> still valid.  It can be quite tricky to distribute the clock in large
> systems - even for a moderate definition of large.  And for ccNUMAs which
> are going to show up on the embedded market sooner or later it's easy
> for the lazy designer to use several clock sources anyway.  Note our
> current time code for will not work properly if clocks diverge on the
> slightest bit - among other things the standards mandate time to
> monotonically increase.

Actually the standards are suprisingly lax. I had the same assumptions
but people who went and read the spec in detail found Posix is a lot
more relaxed (except about CLOCK_MONOTONIC).

What seems to be happening in the PC and Sparc worlds is vendors are
running a seperate lower accuracy global clock source (eg the HPET on
AMD64)


From macro@ds2.pg.gda.pl Thu Jun  5 12:07:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 12:07:39 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:33996 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225241AbTFELHh>; Thu, 5 Jun 2003 12:07:37 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA06283;
	Thu, 5 Jun 2003 13:08:20 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 5 Jun 2003 13:08:19 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Kevin D. Kissell" <kevink@mips.com>
cc: Jun Sun <jsun@mvista.com>, Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
In-Reply-To: <019201c32b40$2d54cf60$10eca8c0@grendel>
Message-ID: <Pine.GSO.3.96.1030605124326.5828D-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2539
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 5 Jun 2003, Kevin D. Kissell wrote:

> > > > 1) clocks on different CPUs don't have the same frequency
> > > > 2) clocks on different CPUs drift to each other
> > > > 2) some fancy power saving feature such as frequency scaling
> > > > 
> > > > But I think for a foreseeable future most MIPS SMP machines
> > > > don't have the above issues (true?).  And it is probably worthwile
> > > > to synchronize count registers for them.
> > > 
> > > 1) and 2) affect most SGI systems.
> > >
> > 
> > Assuming SGI systems represent the past of MIPS, we are still ok
> > future-wise. :)
> 
> I personally think it would be foolish to assume that future MIPS 
> MP systems will not be subject to one or more such constraint.

 Depending on the system in use it may be easier to get a suitable
external clock reference, e.g. a chipset timer.  If an access to it would
be slow, it could be cached on timer interrupts and extended with
processors' timers.

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


From ralf@linux-mips.org Thu Jun  5 12:27:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 12:27:34 +0100 (BST)
Received: from p508B4F3A.dip.t-dialin.net ([IPv6:::ffff:80.139.79.58]:60825
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225277AbTFEL1c>; Thu, 5 Jun 2003 12:27:32 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h55BRRbY009150;
	Thu, 5 Jun 2003 04:27:28 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h55BRMMM009149;
	Thu, 5 Jun 2003 13:27:22 +0200
Date: Thu, 5 Jun 2003 13:27:22 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Ashish anand <ashish.anand@inspiretech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: low ram as source of good parity data..?
Message-ID: <20030605112722.GA9001@linux-mips.org>
References: <200306051027.h55ARnI9031919@smtp.inspirtek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200306051027.h55ARnI9031919@smtp.inspirtek.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: 2540
X-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, Jun 05, 2003 at 03:16:41PM +0530, Ashish anand wrote:

> I have seen it a common practice to assume low RAM as source 
> of good parity data and use it to fill the caches with good parity 
> data in firmware during elementary hardware initialisation process.
> 
> why it is always safe to assume that low RAM contains good parity data .?
> Is it always true..?
> this question came in picture after I got cacheparity error sometimes.

For the general case it's not safe.  Some systems need memory to be
initialized by writing to it first because before the parity or ECC
bits may have an undefined state.

The safe way to initalize the caches is using the Index_Store_Tag_D etc.
cacheops but of course that requires knowledge about the particular
processor's exactly cache architecture.

  Ralf

From macro@ds2.pg.gda.pl Thu Jun  5 13:15:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 13:15:05 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:22736 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225294AbTFEMPD>; Thu, 5 Jun 2003 13:15:03 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA07062;
	Thu, 5 Jun 2003 14:15:53 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 5 Jun 2003 14:15:52 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>,
	Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: mips64 LOAD_KPTE2 fix
In-Reply-To: <20030605.095802.59461340.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.GSO.3.96.1030605130933.5828E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2541
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 5 Jun 2003, Atsushi Nemoto wrote:

> >>>>> On Wed, 4 Jun 2003 16:09:10 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:
> >> Thank you for pointing out this.  I did not think very much.  But
> >> you mean "slt \tmp, \tmp, \ptr", don't you?
> 
> macro>  Not at all.  Why would I want to reverse the comparison?
> 
> Sorry, I garbled.  Please ignore my last patch.  Your patch works
> fine.  Thank you again.

 Ralf, OK to apply then?

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

patch-mips-2.4.21-pre4-20030505-load_kpte2-0
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030505.macro/arch/mips64/mm/tlbex-r4k.S linux-mips-2.4.21-pre4-20030505/arch/mips64/mm/tlbex-r4k.S
--- linux-mips-2.4.21-pre4-20030505.macro/arch/mips64/mm/tlbex-r4k.S	2003-04-27 02:56:39.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030505/arch/mips64/mm/tlbex-r4k.S	2003-06-03 12:54:41.000000000 +0000
@@ -73,8 +73,9 @@
 	 * Determine that fault address is within vmalloc range.
 	 */
 	dla	\tmp, ekptbl
-	sltu	\tmp, \ptr, \tmp
+	slt	\tmp, \ptr, \tmp
 	beqz	\tmp, \not_vmalloc		# not vmalloc
+	 nop
 	.endm
 
 


From ralf@linux-mips.org Thu Jun  5 13:20:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 13:20:25 +0100 (BST)
Received: from p508B4F3A.dip.t-dialin.net ([IPv6:::ffff:80.139.79.58]:7837
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225294AbTFEMUX>; Thu, 5 Jun 2003 13:20:23 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h55CKAbY031548;
	Thu, 5 Jun 2003 05:20:11 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h55CJx2r031547;
	Thu, 5 Jun 2003 14:19:59 +0200
Date: Thu, 5 Jun 2003 14:19:59 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
Subject: Re: mips64 LOAD_KPTE2 fix
Message-ID: <20030605121959.GA31523@linux-mips.org>
References: <20030605.095802.59461340.nemoto@toshiba-tops.co.jp> <Pine.GSO.3.96.1030605130933.5828E-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030605130933.5828E-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2542
X-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, Jun 05, 2003 at 02:15:52PM +0200, Maciej W. Rozycki wrote:

> > Sorry, I garbled.  Please ignore my last patch.  Your patch works
> > fine.  Thank you again.
> 
>  Ralf, OK to apply then?

Yes, please.

  Ralf

From dkesselr@mmc.atmel.com Thu Jun  5 15:39:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 15:39:26 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:8819
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8224821AbTFEOjX>; Thu, 5 Jun 2003 15:39:23 +0100
Received: from pluto.mmc.atmel.com (pluto.mmc.atmel.com [10.127.240.51])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA28154
	for <linux-mips@linux-mips.org>; Thu, 5 Jun 2003 10:39:16 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by pluto.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA26604
	for <linux-mips@linux-mips.org>; Thu, 5 Jun 2003 10:39:15 -0400 (EDT)
X-Authentication-Warning: pluto.mmc.atmel.com: dkesselr owned process doing -bs
Date: Thu, 5 Jun 2003 10:39:15 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: 64bit gcc
Message-ID: <Pine.GSO.4.44.0306051033370.26007-100000@pluto.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2543
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

I'm trying to build gcc from "Marco's" gcc source and patches for 2.9xxxx.
I have also changed t-elf and elf64.h based on notes from
www.cse.unsw.edu.au/~s2174381/notes/gcc.html. But during the make I get
the following error. It looks like it's building 16bit code that I don't
need. Any comments are appreciated.
BTW, my target is a Mips 5kf core, little endian.

///////////////////////////////////////
rm -f tmplibgcc1.a libgcc1.S
cp ./config/mips/mips16.S libgcc1.S
for name in _m16addsf3 _m16subsf3 _m16mulsf3 _m16divsf3 _m16eqsf2
_m16nesf2 _m16gtsf2 _m16gesf2 _m16lesf2 _m16ltsf2 _m16fltsisf _m16fixsfsi
_m16adddf3 _m16subdf3 _m16muldf3 _m16divdf3 _m16extsfdf2 _m16trdfsf2
_m16eqdf2 _m16nedf2 _m16gtdf2 _m16gedf2 _m16ledf2 _m16ltdf2 _m16fltsidf
_m16fixdfsi _m16retsf _m16retdf _m16stub1 _m16stub2 _m16stub5 _m16stub6
_m16stub9 _m16stub10 _m16stubsf0 _m16stubsf1 _m16stubsf2 _m16stubsf5
_m16stubsf6 _m16stubsf9 _m16stubsf10 _m16stubdf0 _m16stubdf1 _m16stubdf2
_m16stubdf5 _m16stubdf6 _m16stubdf9 _m16stubdf10; \
do \
  echo ${name}; \
  /usr/src/redhat/SOURCES/gcc/gcc/xgcc -B/usr/src/redhat/SOURCES/gcc/gcc/
-B/usr/local/mips64el/bin/ -I/usr/local/mips64el/include -O2
-DCROSS_COMPILE -DIN_GCC    -g -O2   -I./include  -G 0 -g1  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I./config -I./../include
-c -DL${name} libgcc1.S;
\
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  mv libgcc1.o ${name}.o; \
  mips64el-ar rc tmplibgcc1.a ${name}.o; \
  rm -f ${name}.o; \
done
_m16addsf3
as: unrecognized option `-EL'
make[1]: *** [libgcc1-asm.a] Error 1
make[1]: Leaving directory `/usr/src/redhat/SOURCES/gcc/gcc'
make: *** [all-gcc] Error 2
////////////////////////////////////////////////

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


From jsun@mvista.com Thu Jun  5 17:53:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 17:53:53 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:16370 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225289AbTFEQxv>;
	Thu, 5 Jun 2003 17:53:51 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h55GrmR02398;
	Thu, 5 Jun 2003 09:53:48 -0700
Date: Thu, 5 Jun 2003 09:53:48 -0700
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Message-ID: <20030605095348.C25414@mvista.com>
References: <20030604153930.H19122@mvista.com> <20030604231547.GA22410@linux-mips.org> <20030604164652.J19122@mvista.com> <20030605001232.GA5626@linux-mips.org> <20030604183836.B25414@mvista.com> <16094.64161.12926.645512@doms-laptop.algor.co.uk> <20030605084852.GA25712@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030605084852.GA25712@linux-mips.org>; from ralf@linux-mips.org on Thu, Jun 05, 2003 at 10:48:52AM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2544
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Jun 05, 2003 at 10:48:52AM +0200, Ralf Baechle wrote:
> On Thu, Jun 05, 2003 at 09:09:05AM +0100, Dominic Sweetman wrote:
> 
> > A naive network synchronisation protocol - analogous to your first
> > proposal - would leave clocks differing by a network round-trip time
> > or so: but NTP does a lot better.  So in principle you should be able
> > to scale NTP to create a clock synchronised within some fraction of
> > the time taken by a CPU-to-CPU communication... but compressing the
> > essence of the NTP protocol into something which runs fast enough
> > might be interesting!
> > 
> > My 5-minutes-over-breakfast feeling is that you should be able to
> > figure out a way to get time right enough; try reading up how NTP
> > works and see whether it can be made to work?
> 
> Yes, already been thinking about that.  The essence of NTP is a software
> implementation of a phase locked loop.  The full NTP protocol is way to
> heavy of course but the subset we're talking about would be rather
> lightweight.  I'd expect the phase noise to be in the low ppb range,
> little problems with unlocking.  And it'll be usable for arbitrary
> combinations of clock frequencies.  So an approach to try.
>

OK, I think you all convinced me that it is probably not a good
idea to do the synchronized CPU count registers, at least not until
we take a look of some alternatives.
 
> Enjoy your breakfast :-)
>

What are you eating?  I probably should have that when I was thinking
about this RFC. :)

In response to some other replies:

1) yes, it is always possible to use some external system-wide
timer source, if available, to solve this problem.  However, that could
get tricky too, and I wanted to do something generic which is hopefully 
applicable to more systems.

2) at least from my perspective, I see increasing demand for high
resolution timers that has monotonicity in both kernel space and user space.

Jun

From agx@sigxcpu.org Thu Jun  5 19:42:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 19:42:46 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:30683
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8224821AbTFESmo> convert rfc822-to-8bit; Thu, 5 Jun 2003 19:42:44 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id E0FD02BC38
	for <linux-mips@linux-mips.org>; Thu,  5 Jun 2003 20:42:38 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 01518-01
 for <linux-mips@linux-mips.org>; Thu,  5 Jun 2003 20:42:34 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id F03E92BC36
	for <linux-mips@linux-mips.org>; Thu,  5 Jun 2003 20:42:33 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id E3BBE17775; Thu,  5 Jun 2003 20:42:23 +0200 (CEST)
Date: Thu, 5 Jun 2003 20:42:23 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030605184223.GB29450@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <20030605182419Z8224802-1272+2270@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
In-Reply-To: <20030605182419Z8224802-1272+2270@linux-mips.org>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2545
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Thu, Jun 05, 2003 at 07:24:15PM +0100, ralf@linux-mips.org wrote:
> 	Merge with Linux 2.5.70.
Ralf - Merge-o-mat - Bächle, you make my day!
 -- Guido

From jbglaw@dvmwest.gt.owl.de Thu Jun  5 20:45:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 20:45:21 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:48145 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8224802AbTFETpT>; Thu, 5 Jun 2003 20:45:19 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 983644AB90; Thu,  5 Jun 2003 21:45:16 +0200 (CEST)
Date: Thu, 5 Jun 2003 21:45:16 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030605194516.GW30457@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030605182419Z8224802-1272+2270@linux-mips.org> <20030605184223.GB29450@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="TcuvTDpCAASXpu1W"
Content-Disposition: inline
In-Reply-To: <20030605184223.GB29450@bogon.ms20.nix>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
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: 2546
X-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


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

On Thu, 2003-06-05 20:42:23 +0200, Guido Guenther <agx@sigxcpu.org>
wrote in message <20030605184223.GB29450@bogon.ms20.nix>:
> On Thu, Jun 05, 2003 at 07:24:15PM +0100, ralf@linux-mips.org wrote:
> > 	Merge with Linux 2.5.70.
> Ralf - Merge-o-mat - B=E4chle, you make my day!

Seconding that:)

While talking to a coworker today, I called that harakiri merging. You
did a great job, Ralf! Do you want to get inter-BKxx patches from me or
do you prefer to only import evenly versioned Linus patches?

MfG, JBG

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

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

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

iD8DBQE+353LHb1edYOZ4bsRAnlFAJ919n/u/UGQ/aa2GuO+w6wJMEdWFgCeNhbe
eoVBauUngddYOrXiCNxRNOo=
=SBqN
-----END PGP SIGNATURE-----

--TcuvTDpCAASXpu1W--

From lindahl@keyresearch.com Thu Jun  5 21:04:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 21:05:00 +0100 (BST)
Received: from 66-122-194-201.ded.pacbell.net ([IPv6:::ffff:66.122.194.201]:18049
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8224802AbTFEUE6>; Thu, 5 Jun 2003 21:04:58 +0100
Received: from localhost.localdomain (greglaptop [127.0.0.1])
	by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h55K6WOW001670
	for <linux-mips@linux-mips.org>; Thu, 5 Jun 2003 13:06:32 -0700
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id h55K6W9m001668
	for linux-mips@linux-mips.org; Thu, 5 Jun 2003 13:06:32 -0700
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 5 Jun 2003 13:06:32 -0700
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Message-ID: <20030605200632.GA1513@greglaptop.internal.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030604153930.H19122@mvista.com> <20030604231547.GA22410@linux-mips.org> <20030604164652.J19122@mvista.com> <20030605001232.GA5626@linux-mips.org> <20030604183836.B25414@mvista.com> <16094.64161.12926.645512@doms-laptop.algor.co.uk> <20030605084852.GA25712@linux-mips.org> <20030605095348.C25414@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030605095348.C25414@mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2547
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Thu, Jun 05, 2003 at 09:53:48AM -0700, Jun Sun wrote:

> 1) yes, it is always possible to use some external system-wide
> timer source, if available, to solve this problem.  However, that could
> get tricky too, and I wanted to do something generic which is hopefully 
> applicable to more systems.

Such sources are generally both much lower resolution, and they take a
long time to read. But a _consistent_ but higher overhead, lower
resolution number is better than an inconsistent number.

greg

From ralf@linux-mips.org Thu Jun  5 21:12:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jun 2003 21:12:46 +0100 (BST)
Received: from p508B4F3A.dip.t-dialin.net ([IPv6:::ffff:80.139.79.58]:59066
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224802AbTFEUMo>; Thu, 5 Jun 2003 21:12:44 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h55KCgbY027999
	for <linux-mips@linux-mips.org>; Thu, 5 Jun 2003 13:12:42 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h55KCg7e027998
	for linux-mips@linux-mips.org; Thu, 5 Jun 2003 22:12:42 +0200
Date: Thu, 5 Jun 2003 22:12:41 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030605201241.GA27522@linux-mips.org>
References: <20030605182419Z8224802-1272+2270@linux-mips.org> <20030605184223.GB29450@bogon.ms20.nix> <20030605194516.GW30457@lug-owl.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030605194516.GW30457@lug-owl.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: 2548
X-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, Jun 05, 2003 at 09:45:16PM +0200, Jan-Benedict Glaw wrote:

> While talking to a coworker today, I called that harakiri merging. You
> did a great job, Ralf! Do you want to get inter-BKxx patches from me or
> do you prefer to only import evenly versioned Linus patches?

In general I try to keep the merging overhead low by not following all
the -bk releases.

  Ralf

From jp@q-networks.com Fri Jun  6 15:00:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jun 2003 15:00:37 +0100 (BST)
Received: from pfepb.post.tele.dk ([IPv6:::ffff:193.162.153.3]:1664 "EHLO
	pfepb.post.tele.dk") by linux-mips.org with ESMTP
	id <S8225334AbTFFOAc>; Fri, 6 Jun 2003 15:00:32 +0100
Received: from 0x50c49fa4.adsl-fixed.tele.dk (0x50c49fa4.adsl-fixed.tele.dk [80.196.159.164])
	by pfepb.post.tele.dk (Postfix) with ESMTP id AB1DF5EE130
	for <linux-mips@linux-mips.org>; Fri,  6 Jun 2003 16:00:15 +0200 (CEST)
Subject: pcmcia problem on pb1500
From: Jan Pedersen <jp@q-networks.com>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) 
Date: 06 Jun 2003 15:59:23 +0200
Message-Id: <1054907964.14600.172.camel@jp>
Mime-Version: 1.0
Return-Path: <jp@q-networks.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2549
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jp@q-networks.com
Precedence: bulk
X-list: linux-mips

Hi

I am having problems getting a pci-pcmcia card up and running with
kernel 2.4.19 on my pb1500 board.

A am executing:
insmod pcmcia_core.o cis_speed=10
insmod yenta_socket.o
insmod ds.o
cardmgr -v

output:
Linux Kernel Card Services 3.1.22
  options:  [pci] [cardbus]
Yenta IRQ list 0000, PCI irq4
Socket status: 30000046
Yenta IRQ list 0000, PCI irq4
Socket status: 30000011
cardmgr[148]: watching 2 sockets
cardmgr[149]: starting, version is 3.2.4
Done.
cardmgr[cs: memory probe 0x80000000-0x80ffffff:149]: initializing socket
1
 excluding 0x80000000-0x800fffff 0x80400000-0x80bfffff
cardmgr[149]: socket 1: 350 Series Wireless LAN Adapter
cardmgr[149]:   product info: "Cisco Systems", "350 Series Wireless LAN
Adapter"
cardmgr[149]:   manfid: 0x015f, 0x000a  function: 6 (network)
cardmgr[149]: module airo_cs.o not available
cardmgr[149]: executing: 'modprobe airo_cs'
airo:  Probing for PCI adapters
airo:  Finished probing for PCI adapters
airo_cs: GetNextTuple: No more items
cardmgr[149]: get dev info on socket 1 failed: Resource temporarily
unavailable



It seems like it has something to do with the io area. When digging into
the airo_cs.c, it fails in the folowing line.
CFG_CHECK(RequestIO, link->handle, &link->io);

When compiled for x86 everything works fine.

lspci -v shows:
00:0d.0 Class 0607: 104c:ac55 (rev 01)
        Flags: bus master, medium devsel, latency 168, IRQ 4
        Memory at 80000000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=01, subordinate=04, sec-latency=176
        Memory window 0: 80001000-80002000 (prefetchable)
        Memory window 1: 80400000-807ff000
        I/O window 0: 00000000-00000fff
        I/O window 1: 00000000-00000003
        16-bit legacy interface ports at 0001

00:0d.1 Class 0607: 104c:ac55 (rev 01)
        Flags: bus master, medium devsel, latency 168, IRQ 4
        Memory at 80004000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=05, subordinate=08, sec-latency=176
        Memory window 0: 80005000-80006000 (prefetchable)
        Memory window 1: 80800000-80bff000
        I/O window 0: 00000000-00000003
        I/O window 1: 00001000-00001fff
        16-bit legacy interface ports at 0001


/etc/pcmcia/config.opts:
include port 0x100-0x4ff, port 0xc00-0xcff
include memory 0x80000000-0x80ffffff

THEN, i saw in the linux-mips archives, that Jeff Baitis has succeeded
in getting it working on 2.4. He had applied two patches: 
Pete's 36bit_addr_2.4.21-pre4.patch
Pete's 64bit_pcmcia.patch

I've found and patched theese into my kernel, but now, nothing works!

output is now:
Linux Kernel Card Services 3.1.22
  options:  [pci] [cardbus]
Yenta IRQ list 0000, PCI irq4
Socket status: 30000046
Yenta IRQ list 0000, PCI irq4
Socket status: 30000011
cardmgr[153]: watching 2 sockets
cardmgr[153]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
argument
cardmgr[153]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
argument
cardmgr[153]: could not adjust resource: memory 0x80000000-0x80ffffff:
Invalid argument
cardmgr[154]: starting, version is 3.2.4
Done.
cardmgr[154]: initiacs: unable to map card memory!
lics: unable to map card memory!
zing socket 1
cardmgr[154]: socket 1: Anonymous Memory
cardmgr[154]: module memory_cs.o not available
cardmgr[154]: executing: 'modprobe memory_cs'
cardmgr[154]: get dev info on socket 1 failed: Resource temporarily
unavailable

I am really stock here. Any help would be greatful.

Thanks
Jan



From dkesselr@mmc.atmel.com Fri Jun  6 17:55:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jun 2003 17:55:23 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:31594
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225347AbTFFQzV>; Fri, 6 Jun 2003 17:55:21 +0100
Received: from hydra.mmc.atmel.com (hydra.mmc.atmel.com [10.127.240.58])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id MAA12340
	for <linux-mips@linux-mips.org>; Fri, 6 Jun 2003 12:55:13 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by hydra.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id MAA04073
	for <linux-mips@linux-mips.org>; Fri, 6 Jun 2003 12:55:13 -0400 (EDT)
X-Authentication-Warning: hydra.mmc.atmel.com: dkesselr owned process doing -bs
Date: Fri, 6 Jun 2003 12:55:13 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: state of 64 bit support
Message-ID: <Pine.GSO.4.44.0306061234410.4045-100000@hydra.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2550
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

I've been trying to get a 64 bit compiler working for a 5kc/5kf core,
searching the net for info, and following this list for the last couple of
weeks. I have not been able to get some basic questions answered and I
hope that some of you can help me.
First what is the current status of mips 5k 64bit little-endian support
for gcc? Do I have to use 2.95/2.96? I don't think there is a linux binary
but if you know of one I'd love the link. I have been unsuccessful getting
this built.
On the web, there is a howto to build a mipsel gcc 3.2. Does 3.2 support
64 bit mips? Has anyone gotten it to work?

Also linux. From my understanding, kernel 2.4.20 has the latest patches
for mips32 and mips64. Is that a valid codebase?
It seems that some info in the howto regarding building a compiler with
egcs on linux-mips.org is somewhat dated, is that true?

I really appreciate any guidance. I've been trying to follow the
instructions that are out there but I keep running into problems.
For example, as I try to build gcc 3.2 for mips64el, I can't come up with
a correct include directory. Does anyone have one?

Very, very appreciatively yours,

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


From ppopov@mvista.com Fri Jun  6 18:08:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jun 2003 18:08:33 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:9470 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225349AbTFFRIb>;
	Fri, 6 Jun 2003 18:08:31 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA16796;
	Fri, 6 Jun 2003 10:07:26 -0700
Subject: Re: pcmcia problem on pb1500
From: Pete Popov <ppopov@mvista.com>
To: Jan Pedersen <jp@q-networks.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <1054907964.14600.172.camel@jp>
References: <1054907964.14600.172.camel@jp>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1054919329.18838.184.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 06 Jun 2003 10:08:50 -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: 2551
X-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


Hi Jan,

> /etc/pcmcia/config.opts:
> include port 0x100-0x4ff, port 0xc00-0xcff
> include memory 0x80000000-0x80ffffff

I think you need something like that for mips as well.

> THEN, i saw in the linux-mips archives, that Jeff Baitis has succeeded
> in getting it working on 2.4. He had applied two patches: 
> Pete's 36bit_addr_2.4.21-pre4.patch
> Pete's 64bit_pcmcia.patch

> I've found and patched theese into my kernel, but now, nothing works!

Not surprising :)  The 36bit_add_xxxx patch was applied to the tree so
it's not integrated in the source tree. So this begs the question --
what version of linux-mips are you using? If you're using the latest cvs
bits, applying the above 36bit patch should have failed miserably. You
do need the 64bit_pcmcia.patch though.

Take a look at the archives again and see how Jeff setup config.opts on
the target board. That was the key.  The cardmgr is recognizing your
card so it's reading the attribute memory successfully. You're almost
there ;)

Pete



From ppopov@mvista.com Fri Jun  6 18:12:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jun 2003 18:12:06 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27631 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225352AbTFFRME>;
	Fri, 6 Jun 2003 18:12:04 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA17016;
	Fri, 6 Jun 2003 10:11:01 -0700
Subject: Re: pcmcia problem on pb1500
From: Pete Popov <ppopov@mvista.com>
To: Jan Pedersen <jp@q-networks.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <1054919329.18838.184.camel@zeus.mvista.com>
References: <1054907964.14600.172.camel@jp>
	 <1054919329.18838.184.camel@zeus.mvista.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1054919545.18864.186.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 06 Jun 2003 10:12:25 -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: 2552
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, 2003-06-06 at 10:08, Pete Popov wrote:
> Hi Jan,
> 
> > /etc/pcmcia/config.opts:
> > include port 0x100-0x4ff, port 0xc00-0xcff
> > include memory 0x80000000-0x80ffffff
> 
> I think you need something like that for mips as well.
> 
> > THEN, i saw in the linux-mips archives, that Jeff Baitis has succeeded
> > in getting it working on 2.4. He had applied two patches: 
> > Pete's 36bit_addr_2.4.21-pre4.patch
> > Pete's 64bit_pcmcia.patch
> 
> > I've found and patched theese into my kernel, but now, nothing works!
> 
> Not surprising :)  The 36bit_add_xxxx patch was applied to the tree so
> it's not integrated in the source tree. So this begs the question --

Sorry, this should read "...it's now integrated in the source..."

Pete

> what version of linux-mips are you using? If you're using the latest cvs
> bits, applying the above 36bit patch should have failed miserably. You
> do need the 64bit_pcmcia.patch though.
> 
> Take a look at the archives again and see how Jeff setup config.opts on
> the target board. That was the key.  The cardmgr is recognizing your
> card so it's reading the attribute memory successfully. You're almost
> there ;)
> 
> Pete
> 
> 
> 
> 


From henri@broadbandnetdevices.com Fri Jun  6 18:56:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jun 2003 18:56:36 +0100 (BST)
Received: from tomts10.bellnexxia.net ([IPv6:::ffff:209.226.175.54]:32138 "EHLO
	tomts10-srv.bellnexxia.net") by linux-mips.org with ESMTP
	id <S8225352AbTFFR4d>; Fri, 6 Jun 2003 18:56:33 +0100
Received: from ecs ([65.92.128.188]) by tomts10-srv.bellnexxia.net
          (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with SMTP
          id <20030606175628.BNXK9695.tomts10-srv.bellnexxia.net@ecs>
          for <linux-mips@linux-mips.org>; Fri, 6 Jun 2003 13:56:28 -0400
Message-ID: <002701c32c55$14305520$0500a8c0@sympatico.ca>
Reply-To: "HG" <henri@broadbandnetdevices.com>
From: "HG" <henri@broadbandnetdevices.com>
To: <linux-mips@linux-mips.org>
Subject: how to get older version instead of bleeding edge 
Date: Fri, 6 Jun 2003 13:57:21 -0400
Organization: Bnd
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Return-Path: <henri@broadbandnetdevices.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2553
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: henri@broadbandnetdevices.com
Precedence: bulk
X-list: linux-mips

Hi all

How I get the older version of the linux for mips kernel , in particular I
would like the 2.4.20

after downloading successfully the latest cvs with the web example
i tried to upgrade with : $ cvs
cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs  update -r2.4.20 linux
a long list of ..../filename is no longer in the repository was obtained

any hints of the command line necessary

thanks

Henri


From joeg@clearcore.com Fri Jun  6 19:01:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jun 2003 19:01:11 +0100 (BST)
Received: from www.clearcore.com ([IPv6:::ffff:69.20.152.109]:62108 "HELO
	clearcore.com") by linux-mips.org with SMTP id <S8225352AbTFFSBH>;
	Fri, 6 Jun 2003 19:01:07 +0100
Received: (qmail 17900 invoked by uid 501); 6 Jun 2003 18:01:02 -0000
Date: 6 Jun 2003 18:01:02 -0000
Message-ID: <20030606180102.17899.qmail@clearcore.com>
From: Joe George <joeg@clearcore.com>
To: ppopov@mvista.com
CC: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: [RFC] Au1x00 Ethernet driver
Reply-to: joeg@clearcore.com
Return-Path: <joeg@clearcore.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2554
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joeg@clearcore.com
Precedence: bulk
X-list: linux-mips


The Au1x00 SOCs allow the highest number ethernet interface
to be disabled and some of the signals to be used as GPIOs.

The patch below detects if the interface is enabled and
ignores it if it is disabled.  It is part of what I need.

Our boards do not contain the phy for either ethernet
channel and may be used with 0, 1, or 2 ethernet interfaces.
The phys are on separate boards.

If I do not install a phy on an interface I get an oops, so
it doesn't look like everything that was setup in anticipation
of finding the phy gets taken back down correctly.


<4>eth0: Au1xxx ethernet found at 0xb0500000, irq 28
<3>eth0: No MII transceivers found!
<3>eth0: au1000_probe1 failed.  Returns 0
<4>eth0: Au1xxx ethernet found at 0xb0510000, irq 29
<6>eth0: Broadcom BCM5221 10/100 BaseT PHY at phy address 0
<6>eth0: Using Broadcom BCM5221 10/100 BaseT PHY as default
.
.
.
<1>Unable to handle kernel paging request at virtual address 00000002, epc == 8024e140, ra == 8024ea34
<4>Oops in fault.c::do_page_fault, line 206:
.
.
.

I would like to use the same kernel for all cases and use phy
detection to configure the interfaces.  So I'm really asking if
phy detection is acceptable for inclusion in the kernel?  If so,
I'll try to come up with acceptable patches.

More generally, I'm wondering whether using autodetection for
configuration is desirable as there are a number of other areas
where I'd like to see it used.

Joe


--- linux-mips-cvs24/drivers/net/au1000_eth.c	Mon Jun  2 21:35:28 2003
+++ tst_mips24/drivers/net/au1000_eth.c	Wed Jun  4 17:51:46 2003
@@ -54,6 +54,7 @@
 #include <asm/io.h>
 
 #include <asm/au1000.h>
+#include <asm/cpu.h>
 #include "au1000_eth.h"
 
 #ifdef AU1000_ETH_DEBUG
@@ -109,27 +110,6 @@ extern char * __init prom_getcmdline(voi
  */
 
 
-/*
- * Base address and interupt of the Au1xxx ethernet macs
- */
-static struct au1if {
-	unsigned int port;
-	int irq;
-} au1x00_iflist[] = {
-#if defined(CONFIG_SOC_AU1000)
-		{AU1000_ETH0_BASE, AU1000_ETH0_IRQ}, 
-		{AU1000_ETH1_BASE, AU1000_ETH1_IRQ}
-#elif defined(CONFIG_SOC_AU1500)
-		{AU1500_ETH0_BASE, AU1000_ETH0_IRQ}, 
-		{AU1500_ETH1_BASE, AU1000_ETH1_IRQ}
-#elif defined(CONFIG_SOC_AU1100)
-		{AU1000_ETH0_BASE, AU1000_ETH0_IRQ}, 
-#else
-#error "Unsupported Au1x00 CPU"
-#endif
-	};
-#define NUM_INTERFACES (sizeof(au1x00_iflist) / sizeof(struct au1if))
-
 static char version[] __devinitdata =
     "au1000eth.c:1.1 ppopov@mvista.com\n";
 
@@ -1003,17 +983,40 @@ setup_hw_rings(struct au1000_private *au
 	}
 }
 
+/*
+ * Setup the base address and interupt of the Au1xxx ethernet macs
+ * based on cpu type and whether the interface is enabled in sys_pinfunc
+ * register. The last interface is enabled if SYS_PF_NI2 (bit 4) is 0.
+ */
 static int __init au1000_init_module(void)
 {
-	int i;
-	int base_addr, irq;
-
-	for (i=0; i<NUM_INTERFACES; i++) {
-		base_addr = au1x00_iflist[i].port;
-		irq = au1x00_iflist[i].irq;
-		if (au1000_probe1(NULL, base_addr, irq, i) != 0) {
+	struct cpuinfo_mips *c = &current_cpu_data;
+	int base_addr[2], irq[2], num_ifs, i;
+	int ni = (int)((au_readl(SYS_PINFUNC) & (u32)(SYS_PF_NI2)) >> 4);
+
+	irq[0] = AU1000_ETH0_IRQ;
+	irq[1] = AU1000_ETH1_IRQ;
+	switch (c->cputype) {
+	case CPU_AU1000:
+		num_ifs = 2 - ni;
+		base_addr[0] = AU1000_ETH0_BASE;
+		base_addr[1] = AU1000_ETH1_BASE;
+		break;
+	case CPU_AU1100:
+		num_ifs = 1 - ni;
+		base_addr[0] = AU1000_ETH0_BASE;
+		break;
+	case CPU_AU1500:
+		num_ifs = 2 - ni;
+		base_addr[0] = AU1500_ETH0_BASE;
+		base_addr[1] = AU1500_ETH1_BASE;
+		break;
+	default:
+		num_ifs = 0;
+	}
+	for(i = 0; i < num_ifs; i++) {
+		if (au1000_probe1(NULL, base_addr[i], irq[i], i) != 0)
 			return -ENODEV;
-		}
 	}
 	return 0;
 }

From ilya@gateway.total-knowledge.com Fri Jun  6 19:11:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jun 2003 19:11:55 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:4752
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225199AbTFFSLx>; Fri, 6 Jun 2003 19:11:53 +0100
Received: (qmail 9454 invoked by uid 502); 6 Jun 2003 18:11:48 -0000
Date: Fri, 6 Jun 2003 11:11:48 -0700
From: ilya@theIlya.com
To: HG <henri@broadbandnetdevices.com>
Cc: linux-mips@linux-mips.org
Subject: Re: how to get older version instead of bleeding edge
Message-ID: <20030606181148.GF4803@gateway.total-knowledge.com>
References: <002701c32c55$14305520$0500a8c0@sympatico.ca>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gdTfX7fkYsEEjebm"
Content-Disposition: inline
In-Reply-To: <002701c32c55$14305520$0500a8c0@sympatico.ca>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2555
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

Primary command that you need to know is
info cvs

OTOH, it would probably be beneficial, if we had something like
"
To check out earlier releases of kernel from cvs (i.e. 2.4) use
cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -rlinux_2_4
"

On Fri, Jun 06, 2003 at 01:57:21PM -0400, HG wrote:
> Hi all
>=20
> How I get the older version of the linux for mips kernel , in particular I
> would like the 2.4.20
>=20
> after downloading successfully the latest cvs with the web example
> i tried to upgrade with : $ cvs
> cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs  update -r2.4.20 linux
> a long list of ..../filename is no longer in the repository was obtained
>=20
> any hints of the command line necessary
>=20
> thanks
>=20
> Henri
>=20
>=20

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

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

iD8DBQE+4Nlj7sVBmHZT8w8RAkyVAKCpOI35vvzyb7JXOAJKiWPsri0lCQCgyoin
jnOn05hW8XvlBr1l8I9dA6U=
=kmH0
-----END PGP SIGNATURE-----

--gdTfX7fkYsEEjebm--

From jsun@mvista.com Fri Jun  6 19:13:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jun 2003 19:13:19 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:25838 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225199AbTFFSNQ>;
	Fri, 6 Jun 2003 19:13:16 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h56IDF303045;
	Fri, 6 Jun 2003 11:13:15 -0700
Date: Fri, 6 Jun 2003 11:13:15 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH] kgdb smp support
Message-ID: <20030606111315.N25414@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="G4iJoqBmSsgzjUCe"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2556
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


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


This patch adds some essential part for kgdb support on a
SMP machine.

Much of the patch is contributed by Kip Walker.

I have tested it well on UP machines just to make sure
UP does not break.

Comments? Objections?

Jun 

--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="030606.a-partial-smp-kgdb.patch"

diff -Nru link/arch/mips/kernel/smp.c.orig link/arch/mips/kernel/smp.c
--- link/arch/mips/kernel/smp.c.orig	Wed Apr 23 16:00:13 2003
+++ link/arch/mips/kernel/smp.c	Fri Jun  6 10:25:11 2003
@@ -133,7 +133,7 @@
 	core_send_ipi(cpu, SMP_RESCHEDULE_YOURSELF);
 }
 
-static spinlock_t call_lock = SPIN_LOCK_UNLOCKED;
+spinlock_t smp_call_lock = SPIN_LOCK_UNLOCKED;
 
 struct call_data_struct *call_data;
 
@@ -165,7 +165,7 @@
 	if (wait)
 		atomic_set(&data.finished, 0);
 
-	spin_lock(&call_lock);
+	spin_lock(&smp_call_lock);
 	call_data = &data;
 
 	/* Send a message to all other CPUs and wait for them to respond */
@@ -181,7 +181,7 @@
 	if (wait)
 		while (atomic_read(&data.finished) != cpus)
 			barrier();
-	spin_unlock(&call_lock);
+	spin_unlock(&smp_call_lock);
 
 	return 0;
 }
diff -Nru link/arch/mips/kernel/gdb-stub.c.orig link/arch/mips/kernel/gdb-stub.c
--- link/arch/mips/kernel/gdb-stub.c.orig	Wed Feb 26 17:06:27 2003
+++ link/arch/mips/kernel/gdb-stub.c	Fri Jun  6 10:24:09 2003
@@ -127,6 +127,8 @@
 #include <linux/mm.h>
 #include <linux/console.h>
 #include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/spinlock.h>
 #include <linux/slab.h>
 #include <linux/reboot.h>
 
@@ -137,6 +139,8 @@
 #include <asm/gdb-stub.h>
 #include <asm/inst.h>
 
+#include <asm/debug.h>
+
 /*
  * external low-level support routines
  */
@@ -150,6 +154,8 @@
  */
 extern void breakpoint(void);
 extern void breakinst(void);
+extern void async_breakpoint(void);
+extern void async_breakinst(void);
 extern void adel(void);
 
 /*
@@ -165,6 +171,12 @@
 void handle_exception(struct gdb_regs *regs);
 
 /*
+ * spin locks for smp case
+ */
+static spinlock_t kgdb_lock = SPIN_LOCK_UNLOCKED;
+static spinlock_t kgdb_cpulock[NR_CPUS] = { [0 ... NR_CPUS-1] = SPIN_LOCK_UNLOCKED};
+
+/*
  * BUFMAX defines the maximum number of characters in inbound/outbound buffers
  * at least NUMREGBYTES*2 are needed for register packets
  */
@@ -173,6 +185,7 @@
 static char input_buffer[BUFMAX];
 static char output_buffer[BUFMAX];
 static int initialized;	/* !0 means we've been initialized */
+static int kgdb_started;
 static const char hexchars[]="0123456789abcdef";
 
 /* Used to prevent crashes in memory access.  Note that they'll crash anyway if
@@ -396,6 +409,17 @@
 	restore_flags(flags);
 }
 
+void restore_debug_traps(void)
+{
+	struct hard_trap_info *ht;
+	unsigned long flags;
+
+	save_and_cli(flags);
+	for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
+		set_except_vector(ht->tt, saved_vectors[ht->tt]);
+	restore_flags(flags);
+}
+
 /*
  * Convert the MIPS hardware trap type code to a Unix signal number.
  */
@@ -574,12 +598,39 @@
  */
 static struct gdb_bp_save async_bp;
 
-void set_async_breakpoint(unsigned int epc)
+/*
+ * Swap the interrupted EPC with our asynchronous breakpoint routine.
+ * This is safer than stuffing the breakpoint in-place, since no cache
+ * flushes (or resulting smp_call_functions) are required.  The
+ * assumption is that only one CPU will be handling asynchronous bp's,
+ * and only one can be active at a time.
+ */
+extern spinlock_t smp_call_lock;
+void set_async_breakpoint(unsigned long *epc)
 {
-	async_bp.addr = epc;
-	async_bp.val  = *(unsigned *)epc;
-	*(unsigned *)epc = BP;
-	__flush_cache_all();
+	/* skip breaking into userland */
+	if ((*epc & 0x80000000) == 0)
+		return;
+
+	/* avoid deadlock if someone is make IPC */
+	if (spin_is_locked(&smp_call_lock))
+		return;
+
+	async_bp.addr = *epc;
+	*epc = (unsigned long)async_breakpoint;
+}
+
+void kgdb_wait(void *arg)
+{
+	unsigned flags;
+	int cpu = smp_processor_id();
+
+	local_irq_save(flags);
+
+	spin_lock(&kgdb_cpulock[cpu]);
+	spin_unlock(&kgdb_cpulock[cpu]);
+
+	local_irq_restore(flags);
 }
 
 
@@ -596,6 +647,40 @@
 	int length;
 	char *ptr;
 	unsigned long *stack;
+	int i;
+
+	kgdb_started = 1;
+
+	/*
+	 * acquire the big kgdb spinlock
+	 */
+	if (!spin_trylock(&kgdb_lock)) {
+		/* 
+		 * some other CPU has the lock, we should go back to 
+		 * receive the gdb_wait IPC
+		 */
+		return;
+	}
+
+	/*
+	 * If we're in async_breakpoint(), restore the real EPC from
+	 * the breakpoint.
+	 */
+	if (regs->cp0_epc == (unsigned long)async_breakinst) {
+		regs->cp0_epc = async_bp.addr;
+		async_bp.addr = 0;
+	}
+
+	/* 
+	 * acquire the CPU spinlocks
+	 */
+	for (i=0; i< smp_num_cpus; i++) 
+		db_verify(spin_trylock(&kgdb_cpulock[i]), != 0);
+
+	/*
+	 * force other cpus to enter kgdb
+	 */
+	smp_call_function(kgdb_wait, NULL, 0, 0);
 
 	/*
 	 * If we're in breakpoint() increment the PC
@@ -618,16 +703,6 @@
 		}
 	}
 
-	/*
-	 * If we were interrupted asynchronously by gdb, then a
-	 * breakpoint was set at the EPC of the interrupt so
-	 * that we'd wind up here with an interesting stack frame.
-	 */
-	if (async_bp.addr) {
-		*(unsigned *)async_bp.addr = async_bp.val;
-		async_bp.addr = 0;
-	}
-
 	stack = (long *)regs->reg29;			/* stack ptr */
 	sigval = computeSignal(trap);
 
@@ -689,10 +764,13 @@
 			output_buffer[3] = 0;
 			break;
 
+		/*
+		 * Detach debugger; let CPU run
+		 */
 		case 'D':
-			/* detach; let CPU run */
 			putpacket(output_buffer);
-			return;
+			goto finish_kgdb;
+			break;
 
 		case 'd':
 			/* toggle debug flag */
@@ -776,22 +854,10 @@
 			ptr = &input_buffer[1];
 			if (hexToInt(&ptr, &addr))
 				regs->cp0_epc = addr;
-
-			/*
-			 * Need to flush the instruction cache here, as we may
-			 * have deposited a breakpoint, and the icache probably
-			 * has no way of knowing that a data ref to some location
-			 * may have changed something that is in the instruction
-			 * cache.
-			 * NB: We flush both caches, just to be sure...
-			 */
-
-			__flush_cache_all();
-			return;
-			/* NOTREACHED */
+	  
+			goto exit_kgdb_exception;
 			break;
 
-
 		/*
 		 * kill the program; let us try to restart the machine
 		 * Reset the whole machine.
@@ -810,9 +876,9 @@
 			 * use breakpoints and continue, instead.
 			 */
 			single_step(regs);
-			__flush_cache_all();
-			return;
+			goto exit_kgdb_exception;
 			/* NOTREACHED */
+			break;
 
 		/*
 		 * Set baud rate (bBB)
@@ -867,6 +933,20 @@
 		putpacket(output_buffer);
 
 	} /* while */
+
+	return;
+
+finish_kgdb:
+	restore_debug_traps();
+
+exit_kgdb_exception:
+	/* release locks so other CPUs can go */
+	for (i=0; i < smp_num_cpus; i++) 
+		spin_unlock(&kgdb_cpulock[i]);
+	spin_unlock(&kgdb_lock);
+
+	__flush_cache_all();
+	return;
 }
 
 /*
@@ -890,6 +970,19 @@
 			);
 }
 
+/* Nothing but the break; don't pollute any registers */
+void async_breakpoint(void)
+{
+	__asm__ __volatile__(
+			".globl	async_breakinst\n\t" 
+			".set\tnoreorder\n\t"
+			"nop\n\t"
+			"async_breakinst:\tbreak\n\t"
+			"nop\n\t"
+			".set\treorder"
+			);
+}
+
 void adel(void)
 {
 	__asm__ __volatile__(
@@ -919,6 +1012,9 @@
 {
 	char outbuf[18];
 
+	if (!kgdb_started)
+		return;
+
 	outbuf[0]='O';
 
 	while(l) {
diff -Nru link/arch/mips/sibyte/sb1250/irq.c.orig link/arch/mips/sibyte/sb1250/irq.c
--- link/arch/mips/sibyte/sb1250/irq.c.orig	Thu Mar 27 10:54:19 2003
+++ link/arch/mips/sibyte/sb1250/irq.c	Fri Jun  6 10:24:09 2003
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2000, 2001 Broadcom Corporation
+ * Copyright (C) 2000, 2001, 2002, 2003 Broadcom Corporation
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -23,6 +23,7 @@
 #include <linux/spinlock.h>
 #include <linux/mm.h>
 #include <linux/slab.h>
+#include <linux/kernel_stat.h>
 
 #include <asm/errno.h>
 #include <asm/signal.h>
@@ -61,12 +62,14 @@
 #ifdef CONFIG_KGDB
 extern void breakpoint(void);
 extern void set_debug_traps(void);
+static int kgdb_irq;
 
 /* kgdb is on when configured.  Pass "nokgdb" kernel arg to turn it off */
 static int kgdb_flag = 1;
 static int __init nokgdb(char *str)
 {
 	kgdb_flag = 0;
+	return 1;
 }
 __setup("nokgdb", nokgdb);
 #endif
@@ -377,15 +380,19 @@
 
 #ifdef CONFIG_KGDB
 	if (kgdb_flag) {
+		kgdb_irq = K_INT_UART_1;
+
 		/* Setup uart 1 settings, mapper */
 		out64(M_DUART_IMR_BRK, KSEG1 + A_DUART + R_DUART_IMR_B);
 
+		sb1250_steal_irq(kgdb_irq);
 		out64(IMR_IP6_VAL,
-			KSEG1 + A_IMR_REGISTER(0, R_IMR_INTERRUPT_MAP_BASE) + (K_INT_UART_1<<3));
+			KSEG1 + A_IMR_REGISTER(0, R_IMR_INTERRUPT_MAP_BASE) + (kgdb_irq<<3));
 		tmp = in64(KSEG1 + A_IMR_REGISTER(0, R_IMR_INTERRUPT_MASK));
-		tmp &= ~(1<<K_INT_UART_1);
+		tmp &= ~(1LL<<kgdb_irq);
 		out64(tmp, KSEG1 + A_IMR_REGISTER(0, R_IMR_INTERRUPT_MASK));
 
+		prom_printf("Waiting for GDB on UART port 1\n");
 		set_debug_traps();
 		breakpoint();
 	}
@@ -396,10 +403,10 @@
 
 #include <linux/delay.h>
 
-extern void set_async_breakpoint(unsigned int epc);
+extern void set_async_breakpoint(unsigned long *epc);
 
-#define duart_out(reg, val)     out64(val, KSEG1 + A_DUART_CHANREG(1,reg))
-#define duart_in(reg)           in64(KSEG1 + A_DUART_CHANREG(1,reg))
+#define duart_out(reg, val)     csr_out32(val, KSEG1 + A_DUART_CHANREG(1,reg))
+#define duart_in(reg)           csr_in32(KSEG1 + A_DUART_CHANREG(1,reg))
 
 void sb1250_kgdb_interrupt(struct pt_regs *regs)
 {
@@ -408,10 +415,11 @@
 	 * host to stop the break, since we would see another
 	 * interrupt on the end-of-break too)
 	 */
+	kstat.irqs[smp_processor_id()][K_INT_UART_1]++;
 	mdelay(500);
 	duart_out(R_DUART_CMD, V_DUART_MISC_CMD_RESET_BREAK_INT |
 				M_DUART_RX_EN | M_DUART_TX_EN);
-	if (!user_mode(regs))
-		set_async_breakpoint(regs->cp0_epc);
+	set_async_breakpoint(&regs->cp0_epc);
 }
+
 #endif 	/* CONFIG_KGDB */
diff -Nru link/arch/mips/sibyte/swarm/dbg_io.c.orig link/arch/mips/sibyte/swarm/dbg_io.c
--- link/arch/mips/sibyte/swarm/dbg_io.c.orig	Thu Apr 11 15:10:54 2002
+++ link/arch/mips/sibyte/swarm/dbg_io.c	Fri Jun  6 10:24:09 2003
@@ -37,8 +37,8 @@
 /* -------------------- END OF CONFIG --------------------- */
 
 
-#define	duart_out(reg, val)	out64(val, KSEG1 + A_DUART_CHANREG(1,reg))
-#define duart_in(reg)		in64(KSEG1 + A_DUART_CHANREG(1,reg))
+#define	duart_out(reg, val)	csr_out32(val, KSEG1 + A_DUART_CHANREG(1,reg))
+#define duart_in(reg)		csr_in32(KSEG1 + A_DUART_CHANREG(1,reg))
 
 extern void set_async_breakpoint(unsigned int epc);
 
diff -Nru link/arch/mips/Makefile.orig link/arch/mips/Makefile
--- link/arch/mips/Makefile.orig	Fri Jun  6 10:22:24 2003
+++ link/arch/mips/Makefile	Fri Jun  6 10:30:17 2003
@@ -19,7 +19,7 @@
 ifdef CONFIG_CPU_LITTLE_ENDIAN
 tool-prefix	= mipsel-linux-
 else
-tool-prefix	= mips-linux-
+tool-prefix	= /opt/mvl-installs/mvl3.0.0/hardhat/devkit/mips/fp_be/bin/mips_fp_be-
 endif
 
 ifdef CONFIG_CROSSCOMPILE

--G4iJoqBmSsgzjUCe--

From earlm@mips.com Fri Jun  6 19:14:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jun 2003 19:14:18 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:63405 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225199AbTFFSOQ>;
	Fri, 6 Jun 2003 19:14:16 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h56IDaUe024565;
	Fri, 6 Jun 2003 11:13:36 -0700 (PDT)
Received: from xchange.mips.com (xchange [192.168.20.31])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA00793;
	Fri, 6 Jun 2003 11:13:40 -0700 (PDT)
Received: by xchange.mips.com with Internet Mail Service (5.5.2653.19)
	id <LJWWNP3X>; Fri, 6 Jun 2003 11:13:24 -0700
Message-ID: <0C5F4C7A1E3ED51194E200508B2CE32A022649CF@xchange.mips.com>
From: "Mitchell, Earl" <earlm@mips.com>
To: "'HG'" <henri@broadbandnetdevices.com>, linux-mips@linux-mips.org
Subject: RE: how to get older version instead of bleeding edge 
Date: Fri, 6 Jun 2003 11:13:23 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <earlm@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2557
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlm@mips.com
Precedence: bulk
X-list: linux-mips

Setup env and login ...

export CVSROOT=:pserver:cvs@ftp.linux-mips.org:/home/cvs
cvs login    # password=cvs

To get list of tags available ...

cvs history -r -T linux

Latest stable version is 2_4_21-pre3, to download ..

mkdir ./linux_2_4_21-pre3
cd ./linux_2_4_21-pre3
cvs checkout -r linux_2_4_21-pre3 linux

-earlm


>-----Original Message-----
>From: HG [mailto:henri@broadbandnetdevices.com]
>Sent: Friday, June 06, 2003 10:57 AM
>To: linux-mips@linux-mips.org
>Subject: how to get older version instead of bleeding edge
>
>Hi all
>
>How I get the older version of the linux for mips kernel , in particular I
>would like the 2.4.20
>
>after downloading successfully the latest cvs with the web example
>i tried to upgrade with : $ cvs
>cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs  update -r2.4.20 linux
>a long list of ..../filename is no longer in the repository was obtained
>
>any hints of the command line necessary
>
>thanks
>
>Henri


From ilya@gateway.total-knowledge.com Fri Jun  6 19:20:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jun 2003 19:20:13 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:7312
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225199AbTFFSUK>; Fri, 6 Jun 2003 19:20:10 +0100
Received: (qmail 9738 invoked by uid 502); 6 Jun 2003 18:20:08 -0000
Date: Fri, 6 Jun 2003 11:20:08 -0700
From: ilya@theIlya.com
To: "Mitchell, Earl" <earlm@mips.com>
Cc: 'HG' <henri@broadbandnetdevices.com>, linux-mips@linux-mips.org
Subject: Re: how to get older version instead of bleeding edge
Message-ID: <20030606182008.GG4803@gateway.total-knowledge.com>
References: <0C5F4C7A1E3ED51194E200508B2CE32A022649CF@xchange.mips.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gm5TwAJMO0F2iVRz"
Content-Disposition: inline
In-Reply-To: <0C5F4C7A1E3ED51194E200508B2CE32A022649CF@xchange.mips.com>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2558
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

latest available version is linux_2_4, which happens to be always a tip of
2.4 branch of linux-mips cvs

On Fri, Jun 06, 2003 at 11:13:23AM -0700, Mitchell, Earl wrote:
> Setup env and login ...
>=20
> export CVSROOT=3D:pserver:cvs@ftp.linux-mips.org:/home/cvs
> cvs login    # password=3Dcvs
>=20
> To get list of tags available ...
>=20
> cvs history -r -T linux
>=20
> Latest stable version is 2_4_21-pre3, to download ..
>=20
> mkdir ./linux_2_4_21-pre3
> cd ./linux_2_4_21-pre3
> cvs checkout -r linux_2_4_21-pre3 linux
>=20
> -earlm
>=20
>=20
> >-----Original Message-----
> >From: HG [mailto:henri@broadbandnetdevices.com]
> >Sent: Friday, June 06, 2003 10:57 AM
> >To: linux-mips@linux-mips.org
> >Subject: how to get older version instead of bleeding edge
> >
> >Hi all
> >
> >How I get the older version of the linux for mips kernel , in particular=
 I
> >would like the 2.4.20
> >
> >after downloading successfully the latest cvs with the web example
> >i tried to upgrade with : $ cvs
> >cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs  update -r2.4.20 linux
> >a long list of ..../filename is no longer in the repository was obtained
> >
> >any hints of the command line necessary
> >
> >thanks
> >
> >Henri
>=20
>=20

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

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

iD8DBQE+4NtX7sVBmHZT8w8RAsFHAKC7rzmNA5tdNe2/dAbviuIL2weaegCfTshF
IO/esKVL1SDXosBJp0tG8Wo=
=BWA/
-----END PGP SIGNATURE-----

--gm5TwAJMO0F2iVRz--

From DennisCastleman@oaktech.com Fri Jun  6 19:08:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Jun 2003 01:00:13 +0100 (BST)
Received: from localhost [127.0.0.1] by ftp.linux-mips.org
	with SpamAssassin (2.55 1.174.2.19-2003-05-19-exp);
	Fri, 06 Jun 2003 19:08:30 +0100
From: Dennis Castleman <DennisCastleman@oaktech.com>
To: linux-mips@linux-mips.org
Subject: MIPS CACHE TESTS
Date: Fri, 6 Jun 2003 11:00:23 -0700 
Message-Id: <56BEF0DBC8B9D611BFDB00508B5E2634102FAC@tlexposeidon.teralogic-inc.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_3EE0D89E.2FD31CBE"
X-archive-position: 2559
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: DennisCastleman@oaktech.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------------=_3EE0D89E.2FD31CBE
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

This mail is probably spam.  The original message has been attached
along with this report, so you can recognize or block similar unwanted
mail in future.  See http://spamassassin.org/tag/ for more details.

Content preview:  This message is in MIME format. Since your mail reader
  does not understand this format, some or all of this message may not be
  legible. Hi ALL I trying to find a way of test both the instruction and
  data caches for a MIPS 5KC core. Does any body have any ideas? Data
  cache is easy instruction cache is not so easy. The Magnum pc-50 use to
  have a monitor called Rx4230 MIPS Monitor. This monitor dumped the
  following on power up [...] 

Content analysis details:   (8.10 points, 5 required)
HTML_70_80         (4.0 points)  BODY: Message is 70% to 80% HTML
HTML_MESSAGE       (3.0 points)  BODY: HTML included in message
SUBJ_ALL_CAPS      (1.1 points)  Subject is all capitals

The original message did not contain plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.


------------=_3EE0D89E.2FD31CBE
Content-Type: message/rfc822; x-spam-type=original
Content-Description: original message before SpamAssassin
Content-Disposition: attachment
Content-Transfer-Encoding: 8bit

Received: from mx1.teralogic.tv ([IPv6:::ffff:207.16.148.27]:6624 "EHLO
	mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8225199AbTFFSI2>; Fri, 6 Jun 2003 19:08:28 +0100
Received: from tlexmail.teralogic.tv (uugate-2.oaktech.com [207.16.148.1])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id h56I4Tt02407
	for <linux-mips@linux-mips.org>; Fri, 6 Jun 2003 11:04:29 -0700 (PDT)
Received: by tlexposeidon.teralogic-inc.com with Internet Mail Service (5.5.2653.19)
	id <L92RWCZ2>; Fri, 6 Jun 2003 11:00:29 -0700
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E2634102FAC@tlexposeidon.teralogic-inc.com>
From:	Dennis Castleman <DennisCastleman@oaktech.com>
To:	linux-mips@linux-mips.org
Subject: MIPS CACHE TESTS
Date:	Fri, 6 Jun 2003 11:00:23 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C32C55.807E0290"
Return-Path: <DennisCastleman@oaktech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org

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

------_=_NextPart_001_01C32C55.807E0290
Content-Type: text/plain

Hi ALL
 
I trying to find a way of test both the instruction and data caches for a
MIPS 5KC core.
Does any body have any ideas?  Data cache is easy instruction cache is not
so easy.
The Magnum pc-50 use to have a monitor called Rx4230 MIPS Monitor.
This monitor dumped the following on power up
 
Memory Test 256kb - 5mb...Passed
I/O Cache Test...Passed
NVRAM Test ...Passed
Parallel Test...Passed
Floppy Chip Test...Passed
Primary Data Cache Test...Passed
Primary Instruction Cache Test...Passed
Primary DCache TAG Test...Passed
Primary ICache TAG Test...Passed
Secondary Cache Test...Skipped
Secondary Cache TAG Test...Skipped
Read Merge Write Test...Passed
High Memory Test 5mb -> end...Passed
FP Test...Passed
Keyboard Selftest...Passed
Keyboard Basic Assurance...Passed
Video board Test...Skipped
SCSI Register Test...Passed
Audio Chip Test...Passed
Sonic Reset Test...Passed
Sonic Register Test...Passed
 
PONs Complete...
PON Diagnostics Version 5.05 MIPS OPT Fri May 29 14:22:07 
 
YOMAN doesn't have any thing like this.  If any one knows of power on tests
for a 5KC it would be of great interest to me.
 
 
Dennis Castleman
Oak Technology.
 
 
 
 
 

------_=_NextPart_001_01C32C55.807E0290
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C32C1B.AADDAF20">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"time"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";
	color:black;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi ALL<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I trying to find a way of test both the instruction =
and data
caches for a MIPS 5KC core.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Does any body have any ideas?<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Data cache is easy instruction =
cache is
not so easy.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The Magnum pc-50 use to have a monitor called =
</span></font>Rx4230
MIPS Monitor.<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>This monitor dumped the following on power =
up<o:p></o:p></span></font></p>

<pre><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fo=
nt
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Memory Test 256kb - =
5mb...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>I/O Cache =
Test...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>NVRAM Test =
...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Parallel =
Test...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Floppy Chip =
Test...Passed<o:p></o:p></span></font></pre><pre><b
style=3D'mso-bidi-font-weight:normal'><font size=3D2 color=3Dblack =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-weight:bold;mso-bidi-font-weight:normal'>=
Primary Data Cache =
Test...Passed<o:p></o:p></span></font></b></pre><pre><b
style=3D'mso-bidi-font-weight:normal'><font size=3D2 color=3Dblack =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-weight:bold;mso-bidi-font-weight:normal'>=
Primary Instruction Cache =
Test...Passed<o:p></o:p></span></font></b></pre><pre><b
style=3D'mso-bidi-font-weight:normal'><font size=3D2 color=3Dblack =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-weight:bold;mso-bidi-font-weight:normal'>=
Primary <span
class=3DSpellE>DCache</span> TAG =
Test...Passed<o:p></o:p></span></font></b></pre><pre><b
style=3D'mso-bidi-font-weight:normal'><font size=3D2 color=3Dblack =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-weight:bold;mso-bidi-font-weight:normal'>=
Primary <span
class=3DSpellE>ICache</span> TAG =
Test...Passed<o:p></o:p></span></font></b></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Secondary Cache =
Test...Skipped<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Secondary Cache TAG =
Test...Skipped<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Read Merge Write =
Test...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>High Memory Test 5mb -&gt; =
end...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>FP =
Test...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Keyboard <span
class=3DSpellE>Selftest</span>...Passed<o:p></o:p></span></font></pre><p=
re><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Keyboard Basic =
Assurance...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Video board =
Test...Skipped<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>SCSI Register =
Test...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Audio Chip =
Test...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Sonic Reset =
Test...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Sonic Register =
Test...Passed<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'> <o:p></o:p></span></font></pre><pre><span
class=3DSpellE><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>PONs</span></font></span> =
Complete...<o:p></o:p></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>PON Diagnostics Version 5.05 MIPS OPT Fri =
May 29 </span></font><st1:time
Hour=3D"14" Minute=3D"22">14:22:07</st1:time> =
<o:p></o:p></pre><pre><font size=3D2
color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fo=
nt
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>YOMAN doesn't have any thing like this.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>If any one knows of power on =
tests for a 5KC it would be of great interest to =
me.<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fo=
nt
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><st=
1:PersonName><font
 size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Dennis =
Castleman</span></font></st1:PersonName><o:p></o:p></pre><pre><span
class=3DGramE><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Oak Technology.</span></font></span><o:p></o:p></pre><pre><font =
size=3D2
color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt'> =
<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><span =
style=3D'mso-spacerun:yes'>&nbsp;</span></span></font><font size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span =
style=3D'mso-spacerun:yes'>&nbsp;</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C32C55.807E0290--

------------=_3EE0D89E.2FD31CBE--


From jp@q-networks.com Sat Jun  7 20:20:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Jun 2003 20:20:17 +0100 (BST)
Received: from pfepc.post.tele.dk ([IPv6:::ffff:193.162.153.4]:5165 "EHLO
	pfepc.post.tele.dk") by linux-mips.org with ESMTP
	id <S8224861AbTFGTUD>; Sat, 7 Jun 2003 20:20:03 +0100
Received: from 0x50c49fa4.adsl-fixed.tele.dk (0x50c49fa4.adsl-fixed.tele.dk [80.196.159.164])
	by pfepc.post.tele.dk (Postfix) with ESMTP
	id 0F0C926293B; Sat,  7 Jun 2003 21:19:34 +0200 (CEST)
Subject: Re: pcmcia problem on pb1500
From: Jan Pedersen <jp@q-networks.com>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <1054919329.18838.184.camel@zeus.mvista.com>
References: <1054907964.14600.172.camel@jp> 
	<1054919329.18838.184.camel@zeus.mvista.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) 
Date: 07 Jun 2003 21:18:36 +0200
Message-Id: <1055013539.10775.46.camel@jp>
Mime-Version: 1.0
Return-Path: <jp@q-networks.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2560
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jp@q-networks.com
Precedence: bulk
X-list: linux-mips

> Not surprising :)  The 36bit_add_xxxx patch was applied to the tree so
> it's not integrated in the source tree. So this begs the question --
> what version of linux-mips are you using? If you're using the latest cvs
> bits, applying the above 36bit patch should have failed miserably. You
> do need the 64bit_pcmcia.patch though.

I am not using linux-mips. I am using 2.4.19 directly from kernel.org.
Some files are patched from mips-linux (non-pcmcia stuff).

Tried latest cvs version from linux-mips.org this weekend. By some
reason I can't get any output on the serial port. If this kernel should
work, maybe getting the serial-port to work on this is an easier task
:-)

On the other hand, everything else I need is currently working on 2.4.19
(including pci)

Tried to do the 64bit_pcmcia.patch alone. Same result:

Linux Kernel Card Services 3.1.22
  options:  [pci] [cardbus]
Yenta IRQ list 0000, PCI irq4
Socket status: 30000046
Yenta IRQ list 0000, PCI irq4
Socket status: 30000011
cardmgr[148]: watching 2 sockets
cardmgr[148]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
argument
cardmgr[148]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
argument
cardmgr[148]: could not adjust resource: memory 0x80000000-0x80ffffff:
Invalid argument
cardmgr[149]: starting, version is 3.2.4
Done.
cardmgr[cs: unable to map card memory!
14cs: unable to map card memory!
9]: initializing socket 1
cardmgr[149]: socket 1: Anonymous Memory
cardmgr[149]: module memory_cs.o not available
cardmgr[149]: executing: 'modprobe memory_cs'
cardmgr[149]: get dev info on socket 1 failed: Resource temporarily
unavailable

Best result is with no patches, where it finds my cisco card.

> 
> Take a look at the archives again and see how Jeff setup config.opts on
> the target board. That was the key.  The cardmgr is recognizing your
> card so it's reading the attribute memory successfully. You're almost
> there ;)
My configuration is based on his.
yes, it seems like it can access the attribute memory, but not the io
memory.

I was vondering about the io addresses shown with lspci -v. Are they
valid?
00:0d.0 Class 0607: 104c:ac55 (rev 01)
   I/O window 0: 00000000-00000fff
   I/O window 1: 00000000-00000003
00:0d.1 Class 0607: 104c:ac55 (rev 01)
   I/O window 0: 00000000-00000003
   I/O window 1: 00001000-00001fff

anyway, thanks a lot for helping
Jan




From ppopov@mvista.com Sun Jun  8 23:12:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Jun 2003 23:12:37 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27896 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225193AbTFHWMf>;
	Sun, 8 Jun 2003 23:12:35 +0100
Received: from [10.2.2.20] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA32078;
	Sun, 8 Jun 2003 15:11:25 -0700
Subject: Re: pcmcia problem on pb1500
From: Pete Popov <ppopov@mvista.com>
To: Jan Pedersen <jp@q-networks.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <1055013539.10775.46.camel@jp>
References: <1054907964.14600.172.camel@jp>
	 <1054919329.18838.184.camel@zeus.mvista.com> <1055013539.10775.46.camel@jp>
Content-Type: text/plain
Organization: 
Message-Id: <1055110501.11039.2.camel@adsl.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 08 Jun 2003 15:15:01 -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: 2561
X-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


> I am not using linux-mips. I am using 2.4.19 directly from kernel.org.
> Some files are patched from mips-linux (non-pcmcia stuff).

> Tried latest cvs version from linux-mips.org this weekend. By some
> reason I can't get any output on the serial port. If this kernel should
> work, maybe getting the serial-port to work on this is an easier task
> :-)

Take a look at the toplevel Makefile. I bet you got the head of
linux-mips which is 2.5 and, yes, it's quite borked right now :) I've
made some progress on the Pb1500 but until I get that board fully
functioning, I won't update the rest.  To get 2.4, do a "cvs update
-rlinux_2_4".

> On the other hand, everything else I need is currently working on 2.4.19
> (including pci)
> 
> Tried to do the 64bit_pcmcia.patch alone. Same result:
> 
> Linux Kernel Card Services 3.1.22
>   options:  [pci] [cardbus]
> Yenta IRQ list 0000, PCI irq4
> Socket status: 30000046
> Yenta IRQ list 0000, PCI irq4
> Socket status: 30000011
> cardmgr[148]: watching 2 sockets
> cardmgr[148]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
> argument
> cardmgr[148]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
> argument
> cardmgr[148]: could not adjust resource: memory 0x80000000-0x80ffffff:
> Invalid argument
> cardmgr[149]: starting, version is 3.2.4
> Done.
> cardmgr[cs: unable to map card memory!
> 14cs: unable to map card memory!
> 9]: initializing socket 1
> cardmgr[149]: socket 1: Anonymous Memory
> cardmgr[149]: module memory_cs.o not available
> cardmgr[149]: executing: 'modprobe memory_cs'
> cardmgr[149]: get dev info on socket 1 failed: Resource temporarily
> unavailable
> 
> Best result is with no patches, where it finds my cisco card.
> 
> > 
> > Take a look at the archives again and see how Jeff setup config.opts on
> > the target board. That was the key.  The cardmgr is recognizing your
> > card so it's reading the attribute memory successfully. You're almost
> > there ;)
> My configuration is based on his.
> yes, it seems like it can access the attribute memory, but not the io
> memory.
> 
> I was vondering about the io addresses shown with lspci -v. Are they
> valid?

I think so, yes.

Pete

> 00:0d.0 Class 0607: 104c:ac55 (rev 01)
>    I/O window 0: 00000000-00000fff
>    I/O window 1: 00000000-00000003
> 00:0d.1 Class 0607: 104c:ac55 (rev 01)
>    I/O window 0: 00000000-00000003
>    I/O window 1: 00001000-00001fff
> 
> anyway, thanks a lot for helping
> Jan
> 
> 
> 
> 


From jp@q-networks.com Mon Jun  9 08:29:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 08:29:35 +0100 (BST)
Received: from pfepc.post.tele.dk ([IPv6:::ffff:193.162.153.4]:52271 "EHLO
	pfepc.post.tele.dk") by linux-mips.org with ESMTP
	id <S8225201AbTFIH3b>; Mon, 9 Jun 2003 08:29:31 +0100
Received: from 0x50c49fa4.adsl-fixed.tele.dk (0x50c49fa4.adsl-fixed.tele.dk [80.196.159.164])
	by pfepc.post.tele.dk (Postfix) with ESMTP
	id A0BB726299C; Mon,  9 Jun 2003 09:29:21 +0200 (CEST)
Subject: Re: pcmcia problem on pb1500
From: Jan Pedersen <jp@q-networks.com>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <1055110501.11039.2.camel@adsl.pacbell.net>
References: <1054907964.14600.172.camel@jp>
	<1054919329.18838.184.camel@zeus.mvista.com> <1055013539.10775.46.camel@jp>
	 <1055110501.11039.2.camel@adsl.pacbell.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) 
Date: 09 Jun 2003 09:28:18 +0200
Message-Id: <1055143704.17835.16.camel@jp>
Mime-Version: 1.0
Return-Path: <jp@q-networks.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2562
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jp@q-networks.com
Precedence: bulk
X-list: linux-mips

> Take a look at the toplevel Makefile. I bet you got the head of
> linux-mips which is 2.5 and, yes, it's quite borked right now :) I've
> made some progress on the Pb1500 but until I get that board fully
> functioning, I won't update the rest.  To get 2.4, do a "cvs update
> -rlinux_2_4".

No luck :-(

Tried 2.4.21-pre3 from linux-mips.org with both patches. This should be
the configuration Jeff got to work.
<cardmgr[159]: watching 2 sockets
<cardmgr[159]: could not adjust resource: IO ports 0-0x1fff: Invalid
argument
<cardmgr[159]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
argument
<cardmgr[159]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
argument
<cardmgr[159]: could not adjust resource: memory 0x40000000-0x41ffffff:
Invalid argument
<cardmgr[160]: starting, version is 3.2.4
<Done.
<cardmgr[1cs: unable to map card memory!
<60cs: unable to map card memory!

tried 2.4 from linux-mips.org
<Linux Kernel Card Services 3.1.22
<  options:  [pci] [cardbus]
<yenta 00:0d.1: Preassigned resource 0 busy, reconfiguring...
<yenta 00:0d.1: Preassigned resource 1 busy, reconfiguring...
<yenta 00:0d.1: Preassigned resource 2 busy, reconfiguring...
<Yenta IRQ list 0000, PCI irq1
<Socket status: 30000046
<Yenta IRQ list 0000, PCI irq1
<Socket status: 30000011
<cardmgr[159]: watching 2 sockets
<cardmgr[159]: could not adjust resource: IO ports 0-0x1fff: Invalid
argument
<cardmgr[159]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
argument
<cardmgr[159]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
argument
<cardmgr[159]: could not adjust resource: memory 0x40000000-0x41ffffff:
<Invalid argument
<cardmgr[160]: starting, version is 3.2.4
<Done.
<cardmgrcs: unable to map card memory!
<[1cs: unable to map card memory!

tried same with 64bit_pcmcia.patch
same result. I guess that the 36bit patch is included in this kernel?

Tried 2.4.21 & 2.4.21-pre7 from kernel.org
They die when initializing pci.

Are there different versions of the 36bit-patch? Mine is named
36bit_addr_121302.patch

regards
Jan

> 
> > On the other hand, everything else I need is currently working on 2.4.19
> > (including pci)
> > 
> > Tried to do the 64bit_pcmcia.patch alone. Same result:
> > 
> > Linux Kernel Card Services 3.1.22
> >   options:  [pci] [cardbus]
> > Yenta IRQ list 0000, PCI irq4
> > Socket status: 30000046
> > Yenta IRQ list 0000, PCI irq4
> > Socket status: 30000011
> > cardmgr[148]: watching 2 sockets
> > cardmgr[148]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
> > argument
> > cardmgr[148]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
> > argument
> > cardmgr[148]: could not adjust resource: memory 0x80000000-0x80ffffff:
> > Invalid argument
> > cardmgr[149]: starting, version is 3.2.4
> > Done.
> > cardmgr[cs: unable to map card memory!
> > 14cs: unable to map card memory!
> > 9]: initializing socket 1
> > cardmgr[149]: socket 1: Anonymous Memory
> > cardmgr[149]: module memory_cs.o not available
> > cardmgr[149]: executing: 'modprobe memory_cs'
> > cardmgr[149]: get dev info on socket 1 failed: Resource temporarily
> > unavailable
> > 
> > Best result is with no patches, where it finds my cisco card.
> > 
> > > 
> > > Take a look at the archives again and see how Jeff setup config.opts on
> > > the target board. That was the key.  The cardmgr is recognizing your
> > > card so it's reading the attribute memory successfully. You're almost
> > > there ;)
> > My configuration is based on his.
> > yes, it seems like it can access the attribute memory, but not the io
> > memory.
> > 
> > I was vondering about the io addresses shown with lspci -v. Are they
> > valid?
> 
> I think so, yes.
> 
> Pete
> 
> > 00:0d.0 Class 0607: 104c:ac55 (rev 01)
> >    I/O window 0: 00000000-00000fff
> >    I/O window 1: 00000000-00000003
> > 00:0d.1 Class 0607: 104c:ac55 (rev 01)
> >    I/O window 0: 00000000-00000003
> >    I/O window 1: 00001000-00001fff
> > 
> > anyway, thanks a lot for helping
> > Jan
> > 
> > 
> > 
> > 
> 



From jp@q-networks.com Mon Jun  9 09:03:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 09:03:17 +0100 (BST)
Received: from pfepb.post.tele.dk ([IPv6:::ffff:193.162.153.3]:7780 "EHLO
	pfepb.post.tele.dk") by linux-mips.org with ESMTP
	id <S8225201AbTFIIDM>; Mon, 9 Jun 2003 09:03:12 +0100
Received: from 0x50c49fa4.adsl-fixed.tele.dk (0x50c49fa4.adsl-fixed.tele.dk [80.196.159.164])
	by pfepb.post.tele.dk (Postfix) with ESMTP
	id 99CB05EE363; Mon,  9 Jun 2003 10:02:59 +0200 (CEST)
Subject: RE: pcmcia problem on pb1500
From: Jan Pedersen <jp@q-networks.com>
To: JinuM <jinum@esntechnologies.co.in>
Cc: linux-mips@linux-mips.org
In-Reply-To: <AF572D578398634881E52418B2892567123350@mail.esn.activedirectory>
References: <AF572D578398634881E52418B2892567123350@mail.esn.activedirectory>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) 
Date: 09 Jun 2003 10:01:56 +0200
Message-Id: <1055145727.17834.24.camel@jp>
Mime-Version: 1.0
Return-Path: <jp@q-networks.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2563
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jp@q-networks.com
Precedence: bulk
X-list: linux-mips

I have tried a pci-card with a TI PCI1520PDV chip
and a card with a TI PCI1225PDV chip

with same result.

--
Jan

On Mon, 2003-06-09 at 09:30, JinuM wrote:
> Which Version of TI UltraMedia Card are you using?
> 
> -Jinu
> 
> -----Original Message-----
> From: Jan Pedersen [mailto:jp@q-networks.com]
> Sent: Monday, June 09, 2003 12:58 PM
> To: Pete Popov
> Cc: linux-mips@linux-mips.org
> Subject: Re: pcmcia problem on pb1500
> 
> 
> > Take a look at the toplevel Makefile. I bet you got the head of
> > linux-mips which is 2.5 and, yes, it's quite borked right now :) I've
> > made some progress on the Pb1500 but until I get that board fully
> > functioning, I won't update the rest.  To get 2.4, do a "cvs update
> > -rlinux_2_4".
> 
> No luck :-(
> 
> Tried 2.4.21-pre3 from linux-mips.org with both patches. This should be
> the configuration Jeff got to work.
> <cardmgr[159]: watching 2 sockets
> <cardmgr[159]: could not adjust resource: IO ports 0-0x1fff: Invalid
> argument
> <cardmgr[159]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
> argument
> <cardmgr[159]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
> argument
> <cardmgr[159]: could not adjust resource: memory 0x40000000-0x41ffffff:
> Invalid argument
> <cardmgr[160]: starting, version is 3.2.4
> <Done.
> <cardmgr[1cs: unable to map card memory!
> <60cs: unable to map card memory!
> 
> tried 2.4 from linux-mips.org
> <Linux Kernel Card Services 3.1.22
> <  options:  [pci] [cardbus]
> <yenta 00:0d.1: Preassigned resource 0 busy, reconfiguring...
> <yenta 00:0d.1: Preassigned resource 1 busy, reconfiguring...
> <yenta 00:0d.1: Preassigned resource 2 busy, reconfiguring...
> <Yenta IRQ list 0000, PCI irq1
> <Socket status: 30000046
> <Yenta IRQ list 0000, PCI irq1
> <Socket status: 30000011
> <cardmgr[159]: watching 2 sockets
> <cardmgr[159]: could not adjust resource: IO ports 0-0x1fff: Invalid
> argument
> <cardmgr[159]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
> argument
> <cardmgr[159]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
> argument
> <cardmgr[159]: could not adjust resource: memory 0x40000000-0x41ffffff:
> <Invalid argument
> <cardmgr[160]: starting, version is 3.2.4
> <Done.
> <cardmgrcs: unable to map card memory!
> <[1cs: unable to map card memory!
> 
> tried same with 64bit_pcmcia.patch
> same result. I guess that the 36bit patch is included in this kernel?
> 
> Tried 2.4.21 & 2.4.21-pre7 from kernel.org
> They die when initializing pci.
> 
> Are there different versions of the 36bit-patch? Mine is named
> 36bit_addr_121302.patch
> 
> regards
> Jan
> 
> > 
> > > On the other hand, everything else I need is currently working on 2.4.19
> > > (including pci)
> > > 
> > > Tried to do the 64bit_pcmcia.patch alone. Same result:
> > > 
> > > Linux Kernel Card Services 3.1.22
> > >   options:  [pci] [cardbus]
> > > Yenta IRQ list 0000, PCI irq4
> > > Socket status: 30000046
> > > Yenta IRQ list 0000, PCI irq4
> > > Socket status: 30000011
> > > cardmgr[148]: watching 2 sockets
> > > cardmgr[148]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
> > > argument
> > > cardmgr[148]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
> > > argument
> > > cardmgr[148]: could not adjust resource: memory 0x80000000-0x80ffffff:
> > > Invalid argument
> > > cardmgr[149]: starting, version is 3.2.4
> > > Done.
> > > cardmgr[cs: unable to map card memory!
> > > 14cs: unable to map card memory!
> > > 9]: initializing socket 1
> > > cardmgr[149]: socket 1: Anonymous Memory
> > > cardmgr[149]: module memory_cs.o not available
> > > cardmgr[149]: executing: 'modprobe memory_cs'
> > > cardmgr[149]: get dev info on socket 1 failed: Resource temporarily
> > > unavailable
> > > 
> > > Best result is with no patches, where it finds my cisco card.
> > > 
> > > > 
> > > > Take a look at the archives again and see how Jeff setup config.opts
> on
> > > > the target board. That was the key.  The cardmgr is recognizing your
> > > > card so it's reading the attribute memory successfully. You're almost
> > > > there ;)
> > > My configuration is based on his.
> > > yes, it seems like it can access the attribute memory, but not the io
> > > memory.
> > > 
> > > I was vondering about the io addresses shown with lspci -v. Are they
> > > valid?
> > 
> > I think so, yes.
> > 
> > Pete
> > 
> > > 00:0d.0 Class 0607: 104c:ac55 (rev 01)
> > >    I/O window 0: 00000000-00000fff
> > >    I/O window 1: 00000000-00000003
> > > 00:0d.1 Class 0607: 104c:ac55 (rev 01)
> > >    I/O window 0: 00000000-00000003
> > >    I/O window 1: 00001000-00001fff
> > > 
> > > anyway, thanks a lot for helping
> > > Jan
> > > 
> > > 
> > > 
> > > 
> > 
> 
> 



From macro@ds2.pg.gda.pl Mon Jun  9 12:13:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 12:13:14 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:4249 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225201AbTFILNK>; Mon, 9 Jun 2003 12:13:10 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA02730;
	Mon, 9 Jun 2003 13:12:34 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 9 Jun 2003 13:12:34 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: ralf@linux-mips.org
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20030605182419Z8224802-1272+2270@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030609130817.2686A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2564
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 5 Jun 2003 ralf@linux-mips.org wrote:

> Log message:
> 	Merge with Linux 2.5.70.

 Others have been faster, but anyway: congratulations and thanks a lot for
your hard work. 

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


From Geert.Uytterhoeven@sonycom.com Mon Jun  9 12:49:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 12:49:44 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:45746 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225201AbTFILtm>;
	Mon, 9 Jun 2003 12:49:42 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h59BkrpI007899;
	Mon, 9 Jun 2003 13:46:53 +0200 (MEST)
Date: Mon, 9 Jun 2003 13:46:53 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <Pine.GSO.3.96.1030609130817.2686A-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0306091346060.1347-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2565
X-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, 9 Jun 2003, Maciej W. Rozycki wrote:
> On Thu, 5 Jun 2003 ralf@linux-mips.org wrote:
> > Log message:
> > 	Merge with Linux 2.5.70.
> 
>  Others have been faster, but anyway: congratulations and thanks a lot for

Indeed, congratulations!

> your hard work. 

And now comes an even harder part: feeding back upstream... ;-)

Gr{oetje,eeting}s,

						Geert

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

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


From macro@ds2.pg.gda.pl Mon Jun  9 16:27:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 16:27:36 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:26024 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225211AbTFIP1e>; Mon, 9 Jun 2003 16:27:34 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA05464;
	Mon, 9 Jun 2003 17:28:18 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 9 Jun 2003 17:28:18 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: David Kesselring <dkesselr@mmc.atmel.com>
cc: linux-mips@linux-mips.org
Subject: Re: state of 64 bit support
In-Reply-To: <Pine.GSO.4.44.0306061234410.4045-100000@hydra.mmc.atmel.com>
Message-ID: <Pine.GSO.3.96.1030609164009.2806n-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2566
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 6 Jun 2003, David Kesselring wrote:

> I've been trying to get a 64 bit compiler working for a 5kc/5kf core,
> searching the net for info, and following this list for the last couple of
> weeks. I have not been able to get some basic questions answered and I
> hope that some of you can help me.

 With the above statement I assume you want to have a compiler suitable
for a kernel build only (which is easier to get running) and you do not
need to do 64-bit userland builds (which is tougher).  And that you want a
cross-compiler.

> First what is the current status of mips 5k 64bit little-endian support
> for gcc? Do I have to use 2.95/2.96? I don't think there is a linux binary
> but if you know of one I'd love the link. I have been unsuccessful getting
> this built.

 There are a few gcc 2.95.x i386/Linux LE binary RPM packages available at
my site, but they have preliminary R4k workarounds applied which have
disadvantageous side effects for later processors.  Your best bet is to
get an RPM source package, disable R4k patches and rebuild. 

> On the web, there is a howto to build a mipsel gcc 3.2. Does 3.2 support
> 64 bit mips? Has anyone gotten it to work?

 If going for version 3.x, you probably want to get 3.3.  I can't say if
it supports MIPS64/Linux without patching -- probably yes.

> Also linux. From my understanding, kernel 2.4.20 has the latest patches
> for mips32 and mips64. Is that a valid codebase?

 Up till now most development was done based on 2.4.x, but Ralf has just
finished updating 2.5.x, so you can select the version that suits you
best.

> It seems that some info in the howto regarding building a compiler with
> egcs on linux-mips.org is somewhat dated, is that true?

 The rules on building a compiler haven't changed much if at all for a
long time.  You should be able to verify it with documentation coming with
gcc.

> I really appreciate any guidance. I've been trying to follow the
> instructions that are out there but I keep running into problems.
> For example, as I try to build gcc 3.2 for mips64el, I can't come up with
> a correct include directory. Does anyone have one?

 You need to get installed headers from a C library.  Glibc is the usual
choice, although there are alternatives.  I have a set of suitable headers
available at my site.  It's a bit dated as it's from glibc 2.2.5, but for
kernel builds it doesn't really matter.

 HTH,

  Maciej

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


From drow@false.org Mon Jun  9 16:44:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 16:44:40 +0100 (BST)
Received: from crack.them.org ([IPv6:::ffff:146.82.138.56]:57323 "EHLO
	crack.them.org") by linux-mips.org with ESMTP id <S8225211AbTFIPog>;
	Mon, 9 Jun 2003 16:44:36 +0100
Received: from dsl093-172-017.pit1.dsl.speakeasy.net
	([66.93.172.17] helo=nevyn.them.org ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 19POpP-0000D8-00; Mon, 09 Jun 2003 10:44:59 -0500
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 19POob-0000TU-00; Mon, 09 Jun 2003 11:44:09 -0400
Date: Mon, 9 Jun 2003 11:44:08 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: David Kesselring <dkesselr@mmc.atmel.com>,
	linux-mips@linux-mips.org
Subject: Re: state of 64 bit support
Message-ID: <20030609154408.GA1781@nevyn.them.org>
References: <Pine.GSO.4.44.0306061234410.4045-100000@hydra.mmc.atmel.com> <Pine.GSO.3.96.1030609164009.2806n-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030609164009.2806n-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@false.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2567
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Mon, Jun 09, 2003 at 05:28:18PM +0200, Maciej W. Rozycki wrote:
> On Fri, 6 Jun 2003, David Kesselring wrote:
> 
> > I've been trying to get a 64 bit compiler working for a 5kc/5kf core,
> > searching the net for info, and following this list for the last couple of
> > weeks. I have not been able to get some basic questions answered and I
> > hope that some of you can help me.
> 
>  With the above statement I assume you want to have a compiler suitable
> for a kernel build only (which is easier to get running) and you do not
> need to do 64-bit userland builds (which is tougher).  And that you want a
> cross-compiler.
> 
> > First what is the current status of mips 5k 64bit little-endian support
> > for gcc? Do I have to use 2.95/2.96? I don't think there is a linux binary
> > but if you know of one I'd love the link. I have been unsuccessful getting
> > this built.
> 
>  There are a few gcc 2.95.x i386/Linux LE binary RPM packages available at
> my site, but they have preliminary R4k workarounds applied which have
> disadvantageous side effects for later processors.  Your best bet is to
> get an RPM source package, disable R4k patches and rebuild. 
> 
> > On the web, there is a howto to build a mipsel gcc 3.2. Does 3.2 support
> > 64 bit mips? Has anyone gotten it to work?
> 
>  If going for version 3.x, you probably want to get 3.3.  I can't say if
> it supports MIPS64/Linux without patching -- probably yes.

More or less yes (kernel space).  Userspace went in to 3.4.

> 
> > Also linux. From my understanding, kernel 2.4.20 has the latest patches
> > for mips32 and mips64. Is that a valid codebase?
> 
>  Up till now most development was done based on 2.4.x, but Ralf has just
> finished updating 2.5.x, so you can select the version that suits you
> best.

... But you have to get it from the linux-mips.org CVS, not from
kernel.org!  Just clarifying.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From bchaikin@galileo.co.il Mon Jun  9 17:36:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 17:36:09 +0100 (BST)
Received: from pop3.galileo.co.il ([IPv6:::ffff:199.203.130.130]:11470 "EHLO
	galileo5.galileo.co.il") by linux-mips.org with ESMTP
	id <S8225211AbTFIQgH>; Mon, 9 Jun 2003 17:36:07 +0100
Received: from galileo.co.il ([10.2.2.45])
	by galileo5.galileo.co.il (8.12.6/8.12.6) with ESMTP id h59HY559020309;
	Mon, 9 Jun 2003 19:34:05 +0200 (GMT-2)
Message-ID: <3EE4C5CF.3050607@galileo.co.il>
Date: Mon, 09 Jun 2003 19:37:19 +0200
From: Baruch Chaikin <bchaikin@il.marvell.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>,
	Baruch Chaikin <bchaikin@galileo.co.il>
Subject: Building a stand-alone FS on a very limited flash (newbie  question)
References: <Pine.GSO.4.44.0306061234410.4045-100000@hydra.mmc.atmel.com> <Pine.GSO.3.96.1030609164009.2806n-100000@delta.ds2.pg.gda.pl> <20030609154408.GA1781@nevyn.them.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
To: unlisted-recipients:; (no To-header on input)
Return-Path: <bchaikin@galileo.co.il>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2568
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bchaikin@il.marvell.com
Precedence: bulk
X-list: linux-mips

Hi all,

I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
machine. This works fine, but is unsuitable for system deployment. Do 
you have hints for me where to start, in order to put the file system on 
flash? The platform I'm using is very limited - only one MTD block of 
2.5 MB is available for the file system, out of a 4 MB flash:
    0.5 MB is allocated for the firmware code
    1.0 MB for the compressed kernel image
    2.5 MB for the (compressed?) file system

For example, I've noticed LibC itself is ~5 MB !

Thanks for any tip,
-    Baruch.



From ppopov@mvista.com Mon Jun  9 17:37:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 17:37:29 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:45306 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225211AbTFIQh1>;
	Mon, 9 Jun 2003 17:37:27 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA03196;
	Mon, 9 Jun 2003 09:36:23 -0700
Subject: Re: pcmcia problem on pb1500
From: Pete Popov <ppopov@mvista.com>
To: Jan Pedersen <jp@q-networks.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <1055143704.17835.16.camel@jp>
References: <1054907964.14600.172.camel@jp>
	 <1054919329.18838.184.camel@zeus.mvista.com> <1055013539.10775.46.camel@jp>
	 <1055110501.11039.2.camel@adsl.pacbell.net>  <1055143704.17835.16.camel@jp>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1055176618.9976.1.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 09 Jun 2003 09:36:59 -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: 2569
X-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


> tried same with 64bit_pcmcia.patch
> same result. I guess that the 36bit patch is included in this kernel?

I think so. I don't remember the date when Ralf applied the patch.

> Tried 2.4.21 & 2.4.21-pre7 from kernel.org
> They die when initializing pci.
> 
> Are there different versions of the 36bit-patch? Mine is named
> 36bit_addr_121302.patch

Well, I kept updating the patch and always put the latest one in my
directory. But the updates were always minor -- just so the patch would
apply cleanly. After Ralf checked it in, I removed it from my directory.

Pete




From ppopov@mvista.com Mon Jun  9 17:39:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 17:39:05 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:55290 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225211AbTFIQjD>;
	Mon, 9 Jun 2003 17:39:03 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA03258;
	Mon, 9 Jun 2003 09:37:59 -0700
Subject: Re: pcmcia problem on pb1500
From: Pete Popov <ppopov@mvista.com>
To: Jan Pedersen <jp@q-networks.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <1055152798.17834.28.camel@jp>
References: <1054907964.14600.172.camel@jp>
	 <1054919329.18838.184.camel@zeus.mvista.com> <1055013539.10775.46.camel@jp>
	 <1055110501.11039.2.camel@adsl.pacbell.net>  <1055152798.17834.28.camel@jp>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1055176714.9969.4.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 09 Jun 2003 09:38:34 -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: 2570
X-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 Mon, 2003-06-09 at 02:59, Jan Pedersen wrote:
> found it!
> 
> the cardmgr has local cs_types.h & ss.h. Theese has to be patched as
> well...

Argh, I forgot about that.  One of more of the ioctls sent to the driver
are based on the actual data type. So after you apply the 64 bit pcmcia
patch (which you do need), you also need to patch the cardmgr. Thanks
for the reminder :)  I have to update the README.

Pete

> thanks for the help :-)

> On Mon, 2003-06-09 at 00:15, Pete Popov wrote:
> > 
> > > I am not using linux-mips. I am using 2.4.19 directly from kernel.org.
> > > Some files are patched from mips-linux (non-pcmcia stuff).
> > 
> > > Tried latest cvs version from linux-mips.org this weekend. By some
> > > reason I can't get any output on the serial port. If this kernel should
> > > work, maybe getting the serial-port to work on this is an easier task
> > > :-)
> > 
> > Take a look at the toplevel Makefile. I bet you got the head of
> > linux-mips which is 2.5 and, yes, it's quite borked right now :) I've
> > made some progress on the Pb1500 but until I get that board fully
> > functioning, I won't update the rest.  To get 2.4, do a "cvs update
> > -rlinux_2_4".
> > 
> > > On the other hand, everything else I need is currently working on 2.4.19
> > > (including pci)
> > > 
> > > Tried to do the 64bit_pcmcia.patch alone. Same result:
> > > 
> > > Linux Kernel Card Services 3.1.22
> > >   options:  [pci] [cardbus]
> > > Yenta IRQ list 0000, PCI irq4
> > > Socket status: 30000046
> > > Yenta IRQ list 0000, PCI irq4
> > > Socket status: 30000011
> > > cardmgr[148]: watching 2 sockets
> > > cardmgr[148]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
> > > argument
> > > cardmgr[148]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
> > > argument
> > > cardmgr[148]: could not adjust resource: memory 0x80000000-0x80ffffff:
> > > Invalid argument
> > > cardmgr[149]: starting, version is 3.2.4
> > > Done.
> > > cardmgr[cs: unable to map card memory!
> > > 14cs: unable to map card memory!
> > > 9]: initializing socket 1
> > > cardmgr[149]: socket 1: Anonymous Memory
> > > cardmgr[149]: module memory_cs.o not available
> > > cardmgr[149]: executing: 'modprobe memory_cs'
> > > cardmgr[149]: get dev info on socket 1 failed: Resource temporarily
> > > unavailable
> > > 
> > > Best result is with no patches, where it finds my cisco card.
> > > 
> > > > 
> > > > Take a look at the archives again and see how Jeff setup config.opts on
> > > > the target board. That was the key.  The cardmgr is recognizing your
> > > > card so it's reading the attribute memory successfully. You're almost
> > > > there ;)
> > > My configuration is based on his.
> > > yes, it seems like it can access the attribute memory, but not the io
> > > memory.
> > > 
> > > I was vondering about the io addresses shown with lspci -v. Are they
> > > valid?
> > 
> > I think so, yes.
> > 
> > Pete
> > 
> > > 00:0d.0 Class 0607: 104c:ac55 (rev 01)
> > >    I/O window 0: 00000000-00000fff
> > >    I/O window 1: 00000000-00000003
> > > 00:0d.1 Class 0607: 104c:ac55 (rev 01)
> > >    I/O window 0: 00000000-00000003
> > >    I/O window 1: 00001000-00001fff
> > > 
> > > anyway, thanks a lot for helping
> > > Jan
> > > 
> > > 
> > > 
> > > 
> > 
> 
> 
> 


From ica2_ts@csv.ica.uni-stuttgart.de Mon Jun  9 17:56:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 17:56:21 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:39465
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225211AbTFIQ4T>; Mon, 9 Jun 2003 17:56:19 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19PPwL-00010P-00; Mon, 09 Jun 2003 18:56:13 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19PPwL-0006Jd-00; Mon, 09 Jun 2003 18:56:13 +0200
Date: Mon, 9 Jun 2003 18:56:12 +0200
To: Baruch Chaikin <bchaikin@il.marvell.com>
Cc: linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>
Subject: Re: Building a stand-alone FS on a very limited flash (newbie  question)
Message-ID: <20030609165612.GE32450@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.GSO.4.44.0306061234410.4045-100000@hydra.mmc.atmel.com> <Pine.GSO.3.96.1030609164009.2806n-100000@delta.ds2.pg.gda.pl> <20030609154408.GA1781@nevyn.them.org> <3EE4C5CF.3050607@galileo.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EE4C5CF.3050607@galileo.co.il>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2571
X-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

Baruch Chaikin wrote:
> Hi all,
> 
> I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
> machine. This works fine, but is unsuitable for system deployment. Do 
> you have hints for me where to start, in order to put the file system on 
> flash? The platform I'm using is very limited - only one MTD block of 
> 2.5 MB is available for the file system, out of a 4 MB flash:
>    0.5 MB is allocated for the firmware code
>    1.0 MB for the compressed kernel image
>    2.5 MB for the (compressed?) file system
> 
> For example, I've noticed LibC itself is ~5 MB !

You'll need a smaller libc, dietlibc comes to mind.
http://www.dietlibc.org/


Thiemo

From ppopov@mvista.com Mon Jun  9 18:20:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 18:20:20 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:10231 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225211AbTFIRUS>;
	Mon, 9 Jun 2003 18:20:18 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA05398;
	Mon, 9 Jun 2003 10:20:15 -0700
Subject: Re: [RFC] Au1x00 Ethernet driver
From: Pete Popov <ppopov@mvista.com>
To: joeg@clearcore.com
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030606180102.17899.qmail@clearcore.com>
References: <20030606180102.17899.qmail@clearcore.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1055179250.9976.24.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 09 Jun 2003 10:20:50 -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: 2572
X-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

Joe,


> The patch below detects if the interface is enabled and
> ignores it if it is disabled.  It is part of what I need.

Seems reasonable, thanks. I'll test it later and apply it.

> I would like to use the same kernel for all cases and use phy
> detection to configure the interfaces.  So I'm really asking if
> phy detection is acceptable for inclusion in the kernel?  If so,
> I'll try to come up with acceptable patches.
> 
> More generally, I'm wondering whether using autodetection for
> configuration is desirable as there are a number of other areas
> where I'd like to see it used.

The autodetection is nice, I think, as long as there's not too many
exception cases in how you do the detection.  I recently added support
for a BCM dual phy and that code really didn't fit well in the current
scheme of things. If we start running into more and more of these cases,
we'll have to revisit the autodectection strategy.

It would also be nice to completely separate the phy layer from the MAC
so other drivers can use the same phy support routines.

Pete

> Joe
> 
> 
> --- linux-mips-cvs24/drivers/net/au1000_eth.c	Mon Jun  2 21:35:28 2003
> +++ tst_mips24/drivers/net/au1000_eth.c	Wed Jun  4 17:51:46 2003
> @@ -54,6 +54,7 @@
>  #include <asm/io.h>
>  
>  #include <asm/au1000.h>
> +#include <asm/cpu.h>
>  #include "au1000_eth.h"
>  
>  #ifdef AU1000_ETH_DEBUG
> @@ -109,27 +110,6 @@ extern char * __init prom_getcmdline(voi
>   */
>  
> 
> -/*
> - * Base address and interupt of the Au1xxx ethernet macs
> - */
> -static struct au1if {
> -	unsigned int port;
> -	int irq;
> -} au1x00_iflist[] = {
> -#if defined(CONFIG_SOC_AU1000)
> -		{AU1000_ETH0_BASE, AU1000_ETH0_IRQ}, 
> -		{AU1000_ETH1_BASE, AU1000_ETH1_IRQ}
> -#elif defined(CONFIG_SOC_AU1500)
> -		{AU1500_ETH0_BASE, AU1000_ETH0_IRQ}, 
> -		{AU1500_ETH1_BASE, AU1000_ETH1_IRQ}
> -#elif defined(CONFIG_SOC_AU1100)
> -		{AU1000_ETH0_BASE, AU1000_ETH0_IRQ}, 
> -#else
> -#error "Unsupported Au1x00 CPU"
> -#endif
> -	};
> -#define NUM_INTERFACES (sizeof(au1x00_iflist) / sizeof(struct au1if))
> -
>  static char version[] __devinitdata =
>      "au1000eth.c:1.1 ppopov@mvista.com\n";
>  
> @@ -1003,17 +983,40 @@ setup_hw_rings(struct au1000_private *au
>  	}
>  }
>  
> +/*
> + * Setup the base address and interupt of the Au1xxx ethernet macs
> + * based on cpu type and whether the interface is enabled in sys_pinfunc
> + * register. The last interface is enabled if SYS_PF_NI2 (bit 4) is 0.
> + */
>  static int __init au1000_init_module(void)
>  {
> -	int i;
> -	int base_addr, irq;
> -
> -	for (i=0; i<NUM_INTERFACES; i++) {
> -		base_addr = au1x00_iflist[i].port;
> -		irq = au1x00_iflist[i].irq;
> -		if (au1000_probe1(NULL, base_addr, irq, i) != 0) {
> +	struct cpuinfo_mips *c = &current_cpu_data;
> +	int base_addr[2], irq[2], num_ifs, i;
> +	int ni = (int)((au_readl(SYS_PINFUNC) & (u32)(SYS_PF_NI2)) >> 4);
> +
> +	irq[0] = AU1000_ETH0_IRQ;
> +	irq[1] = AU1000_ETH1_IRQ;
> +	switch (c->cputype) {
> +	case CPU_AU1000:
> +		num_ifs = 2 - ni;
> +		base_addr[0] = AU1000_ETH0_BASE;
> +		base_addr[1] = AU1000_ETH1_BASE;
> +		break;
> +	case CPU_AU1100:
> +		num_ifs = 1 - ni;
> +		base_addr[0] = AU1000_ETH0_BASE;
> +		break;
> +	case CPU_AU1500:
> +		num_ifs = 2 - ni;
> +		base_addr[0] = AU1500_ETH0_BASE;
> +		base_addr[1] = AU1500_ETH1_BASE;
> +		break;
> +	default:
> +		num_ifs = 0;
> +	}
> +	for(i = 0; i < num_ifs; i++) {
> +		if (au1000_probe1(NULL, base_addr[i], irq[i], i) != 0)
>  			return -ENODEV;
> -		}
>  	}
>  	return 0;
>  }
> 
> 


From baitisj@idealab.com Mon Jun  9 19:37:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 19:38:00 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:51658 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225211AbTFISh5>;
	Mon, 9 Jun 2003 19:37:57 +0100
Received: (qmail 18118 invoked by uid 6180); 9 Jun 2003 18:37:53 -0000
Date: Mon, 9 Jun 2003 11:37:53 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: Pete Popov <ppopov@mvista.com>
Cc: Jan Pedersen <jp@q-networks.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: pcmcia problem on pb1500
Message-ID: <20030609113753.N29389@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <1054907964.14600.172.camel@jp> <1054919329.18838.184.camel@zeus.mvista.com> <1055013539.10775.46.camel@jp> <1055110501.11039.2.camel@adsl.pacbell.net> <1055152798.17834.28.camel@jp> <1055176714.9969.4.camel@zeus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <1055176714.9969.4.camel@zeus.mvista.com>; from ppopov@mvista.com on Mon, Jun 09, 2003 at 09:38:34AM -0700
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2573
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

You also should be careful about the way that your kernel is configured.  For
some reason, I remember that I was running into trouble with kernel
configuration at some point.

I remember that the defconfig-pb1500 has some specific CPU options set that are
required. I can't remember the dependency exactly, but it had something with
MIPS32 CPU type, support for 64-bit phy addrs, and not overriding CPU
instructions...  anyway, here's what I have set in my 'CPU selection' section:

CONFIG_CPU_MIPS32=y
CONFIG_CPU_HAS_PREFETCH=y
CONFIG_64BIT_PHYS_ADDR=y
CONFIG_CPU_HAS_LLSC=y
CONFIG_CPU_HAS_SYNC=y

I don't know if this helps.

Good luck,

-Jeff



On Mon, Jun 09, 2003 at 09:38:34AM -0700, Pete Popov wrote:
> On Mon, 2003-06-09 at 02:59, Jan Pedersen wrote:
> > found it!
> > 
> > the cardmgr has local cs_types.h & ss.h. Theese has to be patched as
> > well...
> 
> Argh, I forgot about that.  One of more of the ioctls sent to the driver
> are based on the actual data type. So after you apply the 64 bit pcmcia
> patch (which you do need), you also need to patch the cardmgr. Thanks
> for the reminder :)  I have to update the README.
> 
> Pete
> 
> > thanks for the help :-)
> 
> > On Mon, 2003-06-09 at 00:15, Pete Popov wrote:
> > > 
> > > > I am not using linux-mips. I am using 2.4.19 directly from kernel.org.
> > > > Some files are patched from mips-linux (non-pcmcia stuff).
> > > 
> > > > Tried latest cvs version from linux-mips.org this weekend. By some
> > > > reason I can't get any output on the serial port. If this kernel should
> > > > work, maybe getting the serial-port to work on this is an easier task
> > > > :-)
> > > 
> > > Take a look at the toplevel Makefile. I bet you got the head of
> > > linux-mips which is 2.5 and, yes, it's quite borked right now :) I've
> > > made some progress on the Pb1500 but until I get that board fully
> > > functioning, I won't update the rest.  To get 2.4, do a "cvs update
> > > -rlinux_2_4".
> > > 
> > > > On the other hand, everything else I need is currently working on 2.4.19
> > > > (including pci)
> > > > 
> > > > Tried to do the 64bit_pcmcia.patch alone. Same result:
> > > > 
> > > > Linux Kernel Card Services 3.1.22
> > > >   options:  [pci] [cardbus]
> > > > Yenta IRQ list 0000, PCI irq4
> > > > Socket status: 30000046
> > > > Yenta IRQ list 0000, PCI irq4
> > > > Socket status: 30000011
> > > > cardmgr[148]: watching 2 sockets
> > > > cardmgr[148]: could not adjust resource: IO ports 0xc00-0xcff: Invalid
> > > > argument
> > > > cardmgr[148]: could not adjust resource: IO ports 0x100-0x4ff: Invalid
> > > > argument
> > > > cardmgr[148]: could not adjust resource: memory 0x80000000-0x80ffffff:
> > > > Invalid argument
> > > > cardmgr[149]: starting, version is 3.2.4
> > > > Done.
> > > > cardmgr[cs: unable to map card memory!
> > > > 14cs: unable to map card memory!
> > > > 9]: initializing socket 1
> > > > cardmgr[149]: socket 1: Anonymous Memory
> > > > cardmgr[149]: module memory_cs.o not available
> > > > cardmgr[149]: executing: 'modprobe memory_cs'
> > > > cardmgr[149]: get dev info on socket 1 failed: Resource temporarily
> > > > unavailable
> > > > 
> > > > Best result is with no patches, where it finds my cisco card.
> > > > 
> > > > > 
> > > > > Take a look at the archives again and see how Jeff setup config.opts on
> > > > > the target board. That was the key.  The cardmgr is recognizing your
> > > > > card so it's reading the attribute memory successfully. You're almost
> > > > > there ;)
> > > > My configuration is based on his.
> > > > yes, it seems like it can access the attribute memory, but not the io
> > > > memory.
> > > > 
> > > > I was vondering about the io addresses shown with lspci -v. Are they
> > > > valid?
> > > 
> > > I think so, yes.
> > > 
> > > Pete
> > > 
> > > > 00:0d.0 Class 0607: 104c:ac55 (rev 01)
> > > >    I/O window 0: 00000000-00000fff
> > > >    I/O window 1: 00000000-00000003
> > > > 00:0d.1 Class 0607: 104c:ac55 (rev 01)
> > > >    I/O window 0: 00000000-00000003
> > > >    I/O window 1: 00001000-00001fff
> > > > 
> > > > anyway, thanks a lot for helping
> > > > Jan
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > 
> > 
> > 
> 
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From baitisj@idealab.com Mon Jun  9 19:49:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 19:49:55 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:53706 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225211AbTFIStx>;
	Mon, 9 Jun 2003 19:49:53 +0100
Received: (qmail 18187 invoked by uid 6180); 9 Jun 2003 18:49:51 -0000
Date: Mon, 9 Jun 2003 11:49:51 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: Baruch Chaikin <bchaikin@il.marvell.com>
Cc: linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>,
	Baruch Chaikin <bchaikin@galileo.co.il>
Subject: Re: Building a stand-alone FS on a very limited flash (newbie  question)
Message-ID: <20030609114951.O29389@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <Pine.GSO.4.44.0306061234410.4045-100000@hydra.mmc.atmel.com> <Pine.GSO.3.96.1030609164009.2806n-100000@delta.ds2.pg.gda.pl> <20030609154408.GA1781@nevyn.them.org> <3EE4C5CF.3050607@galileo.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3EE4C5CF.3050607@galileo.co.il>; from bchaikin@il.marvell.com on Mon, Jun 09, 2003 at 07:37:19PM +0200
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2574
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

I highly recommend looking at the UClibC project. Erik's code is a pleasure to
work with.  http://www.uclibc.org/

It is even possible to build libstdc++ with UClibC, if you are so inclined...
And, a number of commercial projects use UClibC , such as Linksys:
http://lkml.org/archive/2003/6/7/164/index.html

and Belkin:

http://lkml.org/archive/2003/6/8/31/index.html

<shameless YRO plug>

-Jeff



On Mon, Jun 09, 2003 at 07:37:19PM +0200, Baruch Chaikin wrote:
> Hi all,
> 
> I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
> machine. This works fine, but is unsuitable for system deployment. Do 
> you have hints for me where to start, in order to put the file system on 
> flash? The platform I'm using is very limited - only one MTD block of 
> 2.5 MB is available for the file system, out of a 4 MB flash:
>     0.5 MB is allocated for the firmware code
>     1.0 MB for the compressed kernel image
>     2.5 MB for the (compressed?) file system
> 
> For example, I've noticed LibC itself is ~5 MB !
> 
> Thanks for any tip,
> -    Baruch.
> 
> 
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From baitisj@idealab.com Mon Jun  9 20:02:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2003 20:02:02 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:58058 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225211AbTFITCA>;
	Mon, 9 Jun 2003 20:02:00 +0100
Received: (qmail 18285 invoked by uid 6180); 9 Jun 2003 19:01:58 -0000
Date: Mon, 9 Jun 2003 12:01:58 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: Baruch Chaikin <bchaikin@il.marvell.com>
Cc: linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>,
	Baruch Chaikin <bchaikin@galileo.co.il>
Subject: Re: Building a stand-alone FS on a very limited flash (newbie  question)
Message-ID: <20030609120158.Q29389@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <Pine.GSO.4.44.0306061234410.4045-100000@hydra.mmc.atmel.com> <Pine.GSO.3.96.1030609164009.2806n-100000@delta.ds2.pg.gda.pl> <20030609154408.GA1781@nevyn.them.org> <3EE4C5CF.3050607@galileo.co.il> <20030609114951.O29389@luca.pas.lab>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030609114951.O29389@luca.pas.lab>; from baitisj@evolution.com on Mon, Jun 09, 2003 at 11:49:51AM -0700
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2575
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

I made a mistake. I'm sorry, these projects use *busybox*. Don't know
if they use UClibC or not. Some wires in my brain got crossed.

Sorry about that.


But, I do recommend UClibC.

-Jeff

On Mon, Jun 09, 2003 at 11:49:51AM -0700, Jeff Baitis wrote:
> I highly recommend looking at the UClibC project. Erik's code is a pleasure to
> work with.  http://www.uclibc.org/
> 
> It is even possible to build libstdc++ with UClibC, if you are so inclined...
> And, a number of commercial projects use UClibC , such as Linksys:
> http://lkml.org/archive/2003/6/7/164/index.html
> 
> and Belkin:
> 
> http://lkml.org/archive/2003/6/8/31/index.html
> 
> <shameless YRO plug>
> 
> -Jeff
> 
> 
> 
> On Mon, Jun 09, 2003 at 07:37:19PM +0200, Baruch Chaikin wrote:
> > Hi all,
> > 
> > I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
> > machine. This works fine, but is unsuitable for system deployment. Do 
> > you have hints for me where to start, in order to put the file system on 
> > flash? The platform I'm using is very limited - only one MTD block of 
> > 2.5 MB is available for the file system, out of a 4 MB flash:
> >     0.5 MB is allocated for the firmware code
> >     1.0 MB for the compressed kernel image
> >     2.5 MB for the (compressed?) file system
> > 
> > For example, I've noticed LibC itself is ~5 MB !
> > 
> > Thanks for any tip,
> > -    Baruch.
> > 
> > 
> > 
> 
> -- 
>          Jeffrey Baitis - Associate Software Engineer
> 
>                     Evolution Robotics, Inc.
>                      130 West Union Street
>                        Pasadena CA 91103
> 
>  tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 
> 
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From jsun@mvista.com Tue Jun 10 03:18:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 03:18:41 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:34557 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225228AbTFJCSj>;
	Tue, 10 Jun 2003 03:18:39 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h5A2IVv30567;
	Mon, 9 Jun 2003 19:18:31 -0700
Date: Mon, 9 Jun 2003 19:18:31 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH] get time right for SMP machines
Message-ID: <20030609191831.H26703@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="uAKRQypu60I7Lcqm"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2576
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


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


Fixes a couple of things:

1) extend xtime_lock protection to cover do_timer() call (the same
   as in i386 arch).  This enables other CPUs to use jiffie in a sane way.

2) It was not quite right to deliver ll_timer_interrupt() and
   ll_local_timer_interrupt() as two separate interrupts, because
   it may cause bottom half to execute ahead of the second interrupt.

3) for bcm1250, we now use zb bus counter for intra-jiffie offset.
   No more time running backward problem. 

(TODO, I think I probably need to check the chip revision to make
sure zb bus counter is there.  Otherwise we can use null_gettimeoffset())

The patch should apply to 64bit and 2.5 as well.  Comments?

Jun 

--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="030609.a-smp-gettimeoffset-fix.patch"

diff -Nru linux/arch/mips/kernel/time.c.orig linux/arch/mips/kernel/time.c
--- linux/arch/mips/kernel/time.c.orig	Fri Jun  6 12:44:08 2003
+++ linux/arch/mips/kernel/time.c	Fri Jun  6 12:45:19 2003
@@ -17,6 +17,7 @@
 #include <linux/sched.h>
 #include <linux/param.h>
 #include <linux/time.h>
+#include <linux/timer.h>
 #include <linux/smp.h>
 #include <linux/kernel_stat.h>
 #include <linux/spinlock.h>
@@ -79,7 +80,7 @@
 	 * is nonzero if the timer bottom half hasnt executed yet.
 	 */
 	if (jiffies - wall_jiffies)
-		tv->tv_usec += USECS_PER_JIFFY;
+		tv->tv_usec += USECS_PER_JIFFY * (jiffies - wall_jiffies);
 
 	read_unlock_irqrestore (&xtime_lock, flags);
 
@@ -344,7 +345,7 @@
 		count = read_c0_count();
 
 		/* check to see if we have missed any timer interrupts */
-		if ((count - expirelo) < 0x7fffffff) {
+		if (time_after(count, expirelo)) {
 			/* missed_timer_count ++; */
 			expirelo = count + cycles_per_jiffy;
 			write_c0_compare(expirelo);
@@ -355,6 +356,8 @@
 		timerlo = count;
 	}
 
+	write_lock (&xtime_lock);
+
 	/*
 	 * call the generic timer interrupt handling
 	 */
@@ -365,7 +368,6 @@
 	 * CMOS clock accordingly every ~11 minutes. rtc_set_time() has to be
 	 * called as close as possible to 500 ms before the new second starts.
 	 */
-	read_lock (&xtime_lock);
 	if ((time_status & STA_UNSYNC) == 0 &&
 	    xtime.tv_sec > last_rtc_update + 660 &&
 	    xtime.tv_usec >= 500000 - ((unsigned) tick) / 2 &&
@@ -377,7 +379,6 @@
 			/* do it again in 60 s */
 		}
 	}
-	read_unlock (&xtime_lock);
 
 	/*
 	 * If jiffies has overflowed in this timer_interrupt we must
@@ -388,26 +389,20 @@
 		timerhi = timerlo = 0;
 	}
 
-#if !defined(CONFIG_SMP)
+	write_unlock (&xtime_lock);
+
 	/*
-	 * In UP mode, we call local_timer_interrupt() to do profiling
-	 * and process accouting.
-	 *
-	 * In SMP mode, local_timer_interrupt() is invoked by appropriate
-	 * low-level local timer interrupt handler.
+	 * We call local_timer_interrupt() to do profiling and 
+	 * process accouting.
 	 */
 	local_timer_interrupt(0, NULL, regs);
 
-#else	/* CONFIG_SMP */
-
+#if defined(CONFIG_SMP)
 	if (emulate_local_timer_interrupt) {
 		/*
 		 * this is the place where we send out inter-process
 		 * interrupts and let each CPU do its own profiling
 		 * and process accouting.
-		 *
-		 * Obviously we need to call local_timer_interrupt() for
-		 * the current CPU too.
 		 */
 		panic("Not implemented yet!!!");
 	}
diff -Nru linux/arch/mips/sibyte/sb1250/time.c.orig linux/arch/mips/sibyte/sb1250/time.c
--- linux/arch/mips/sibyte/sb1250/time.c.orig	Fri Jun  6 12:44:08 2003
+++ linux/arch/mips/sibyte/sb1250/time.c	Mon Jun  9 19:01:43 2003
@@ -30,11 +30,13 @@
 #include <linux/sched.h>
 #include <linux/spinlock.h>
 #include <linux/kernel_stat.h>
+#include <linux/time.h>
 
 #include <asm/irq.h>
 #include <asm/ptrace.h>
 #include <asm/addrspace.h>
 #include <asm/time.h>
+#include <asm/div64.h>
 
 #include <asm/sibyte/sb1250.h>
 #include <asm/sibyte/sb1250_regs.h>
@@ -47,13 +49,42 @@
 #define IMR_IP3_VAL	K_INT_MAP_I1
 #define IMR_IP4_VAL	K_INT_MAP_I2
 
+extern rwlock_t xtime_lock;
+
 extern int sb1250_steal_irq(int irq);
 
+#define	zbcycle2msec_shift	32
+#define USECS_PER_JIFFY 	(1000000/HZ)
+
+static unsigned zbbus_freq;
+static unsigned scaled_usec_per_zbcycle;
+
+/*
+ * return (u32)( ((u64)x * (u64)y) >> shift ), where shift <= 32
+ */
+static inline unsigned 
+scaled_mult(unsigned x, unsigned y, int shift)
+{
+	unsigned hi, lo;
+
+	__asm__("multu\t%2,%3\n\t"
+		"mfhi\t%0\n\t"
+		"mflo\t%1"
+		:"=r" (hi), "=r" (lo)
+		:"r" (x), "r" (y));
+	if (shift == 32) {
+		return hi;
+	} else {
+		return (hi << (32 - shift)) | (lo >> shift);
+	}
+}
+
 void sb1250_time_init(void)
 {
 	int cpu = smp_processor_id();
 	int irq = K_INT_TIMER_0+cpu;
-
+	u64 temp;
+	
 	/* Only have 4 general purpose timers */
 	if (cpu > 3) {
 		BUG();
@@ -95,6 +126,23 @@
 	 * called directly from irq_handler.S when IP[4] is set during an
 	 * interrupt
 	 */
+
+        temp = G_SYS_PLL_DIV(in64(IO_SPACE_BASE | A_SCD_SYSTEM_CFG));
+        temp = ((temp >> 1) * 50) + ((temp & 1) * 25);
+        zbbus_freq = temp * 1000000;
+
+	temp = 1000000ULL << zbcycle2msec_shift;
+	do_div(temp, zbbus_freq);
+	scaled_usec_per_zbcycle = temp;
+}
+
+static unsigned last_jiffie;
+static u64 last_zbcount;
+
+static inline u64
+read_zbcount(void)
+{
+	return in64(KSEG1 + A_SCD_ZBBUS_CYCLE_COUNT);
 }
 
 void sb1250_timer_interrupt(struct pt_regs *regs)
@@ -102,7 +150,6 @@
 	int cpu = smp_processor_id();
 	int irq = K_INT_TIMER_0+cpu;
 
-	kstat.irqs[cpu][irq]++;
 	/* Reset the timer */
 	out64(M_SCD_TIMER_ENABLE|M_SCD_TIMER_MODE_CONTINUOUS,
 	      KSEG1 + A_SCD_TIMER_REGISTER(cpu, R_SCD_TIMER_CFG));
@@ -111,25 +158,45 @@
 	 * CPU 0 handles the global timer interrupt job
 	 */
 	if (cpu == 0) {
+		write_lock(&xtime_lock);
+		last_jiffie = jiffies;
+		last_zbcount = read_zbcount();
+		write_unlock(&xtime_lock);
 		ll_timer_interrupt(irq, regs);
-	}
-
-	/*
-	 * every CPU should do profiling and process accouting
-	 */
-	ll_local_timer_interrupt(irq, regs);
+	} else 
+		ll_local_timer_interrupt(irq, regs);
 }
 
 /*
  * We use our own do_gettimeoffset() instead of the generic one,
  * because the generic one does not work for SMP case.
- * In addition, since we use general timer 0 for system time,
- * we can get accurate intra-jiffy offset without calibration.
+ *
+ * It turns out to be very hard to get monotonically increasing time offset.
+ * We have to resort to zb bus counter.
  */
 unsigned long sb1250_gettimeoffset(void)
 {
-	unsigned long count =
-		in64(KSEG1 + A_SCD_TIMER_REGISTER(0, R_SCD_TIMER_CNT));
+	u64 count;
+	unsigned ret;
+	unsigned count_diff;
+
+	/* we have xtime lock, irq disabled */
+	count = read_zbcount();
+	count_diff = count - last_zbcount;
+	ret = scaled_mult(count_diff,
+			scaled_usec_per_zbcycle, 
+			zbcycle2msec_shift);
+
+	if (jiffies == last_jiffie) {
+		// we are in a narrow window where timer interrupt
+		// has happened but jiffies has not been increased yet
+		// The offset should be about 1 jiffie.  We just return
+		// the maximum intra-jiffie offset here.
+		ret = USECS_PER_JIFFY-1;
+	}
 
-	return 1000000/HZ - count;
- }
+	if (ret >= USECS_PER_JIFFY)
+		ret = USECS_PER_JIFFY-1;
+
+	return ret;
+}

--uAKRQypu60I7Lcqm--

From tor@spacetec.no Tue Jun 10 11:13:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 11:13:45 +0100 (BST)
Received: from firewall.spacetec.no ([IPv6:::ffff:192.51.5.5]:62729 "EHLO
	spacetec.no") by linux-mips.org with ESMTP id <S8224827AbTFJKNn>;
	Tue, 10 Jun 2003 11:13:43 +0100
Message-Id: <200306101013.h5AADRA9002456@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Tue, 10 Jun 2003 12:13:25 +0200
In-Reply-To: Jeff Baitis <baitisj@evolution.com>
       "Re: Building a stand-alone FS on a very limited flash (newbie  question)" (Jun  9, 20:08)
To: baitisj@evolution.com, Baruch Chaikin <bchaikin@il.marvell.com>
Subject: Re: Building a stand-alone FS on a very limited flash (newbie  question)
Cc: linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>
Return-Path: <tor@spacetec.no>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2577
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tor@spacetec.no
Precedence: bulk
X-list: linux-mips

On Jun 9, 20:08, Jeff Baitis wrote:
>I made a mistake. I'm sorry, these projects use *busybox*. Don't know
>if they use UClibC or not. Some wires in my brain got crossed.
[...]

You can combine busybox and UClibC to create a very small Unix file system holding 
most of the tools you would want.  I made myself a single-floppy feature-full rescue
root disk for my x86 system using busybox and UClibC.  Looks like one good way
to solve the space problem described below.

-Tor

>> On Mon, Jun 09, 2003 at 07:37:19PM +0200, Baruch Chaikin wrote:
>> > Hi all,
>> > 
>> > I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
>> > machine. This works fine, but is unsuitable for system deployment. Do 
>> > you have hints for me where to start, in order to put the file system on 
>> > flash? The platform I'm using is very limited - only one MTD block of 
>> > 2.5 MB is available for the file system, out of a 4 MB flash:
>> >     0.5 MB is allocated for the firmware code
>> >     1.0 MB for the compressed kernel image
>> >     2.5 MB for the (compressed?) file system
[...]

From js@convergence.de Tue Jun 10 13:26:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 13:26:17 +0100 (BST)
Received: from mail.convergence.de ([IPv6:::ffff:212.84.236.4]:16270 "EHLO
	mail.convergence.de") by linux-mips.org with ESMTP
	id <S8224827AbTFJM0P>; Tue, 10 Jun 2003 13:26:15 +0100
Received: from [10.1.1.146] (helo=heck)
	by mail.convergence.de with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.14)
	id 19PiCb-0000cL-PP
	for linux-mips@linux-mips.org; Tue, 10 Jun 2003 14:26:13 +0200
Received: from js by heck with local (Exim 3.35 #1 (Debian))
	id 19PiCX-0000JC-00
	for <linux-mips@linux-mips.org>; Tue, 10 Jun 2003 14:26:09 +0200
Date: Tue, 10 Jun 2003 14:26:09 +0200
From: Johannes Stezenbach <js@convergence.de>
To: linux-mips@linux-mips.org
Subject: Re: Building a stand-alone FS on a very limited flash (newbie  question)
Message-ID: <20030610122609.GC544@convergence.de>
Mail-Followup-To: Johannes Stezenbach <js@convergence.de>,
	linux-mips@linux-mips.org
References: <Pine.GSO.4.44.0306061234410.4045-100000@hydra.mmc.atmel.com> <Pine.GSO.3.96.1030609164009.2806n-100000@delta.ds2.pg.gda.pl> <20030609154408.GA1781@nevyn.them.org> <3EE4C5CF.3050607@galileo.co.il> <20030609165612.GE32450@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030609165612.GE32450@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.4i
Return-Path: <js@convergence.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2578
X-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

Thiemo Seufer wrote:
> Baruch Chaikin wrote:
> > 
> > I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
> > machine. This works fine, but is unsuitable for system deployment. Do 
> > you have hints for me where to start, in order to put the file system on 
> > flash? The platform I'm using is very limited - only one MTD block of 
> > 2.5 MB is available for the file system, out of a 4 MB flash:
> >    0.5 MB is allocated for the firmware code
> >    1.0 MB for the compressed kernel image
> >    2.5 MB for the (compressed?) file system
> > 
> > For example, I've noticed LibC itself is ~5 MB !
> 
> You'll need a smaller libc, dietlibc comes to mind.
> http://www.dietlibc.org/

The diet libc is the first choice when you want it lean and mean.
Best used in combination with Busybox (patch necessary because the
Busybox uses GNU extensions and BSD cruft which the diet libc maintainer
refuses to implement) or embutils (http://fefe.de/).

OTOH, if you want shared library support, stable/working threads or iconv()
you must look elsewhere...


Johannes

From wd@denx.de Tue Jun 10 13:39:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 13:39:27 +0100 (BST)
Received: from mailout02.sul.t-online.com ([IPv6:::ffff:194.25.134.17]:32643
	"EHLO mailout02.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8224827AbTFJMjY>; Tue, 10 Jun 2003 13:39:24 +0100
Received: from fwd01.aul.t-online.de 
	by mailout02.sul.t-online.com with smtp 
	id 19PiP8-0004Vy-09; Tue, 10 Jun 2003 14:39:10 +0200
Received: from denx.de (rw9RGuZfwepaNAtzXq7Hp01P1Wxj+fOl8f3f1IoA5By5jN5uwpc1gJ@[217.235.217.122]) by fmrl01.sul.t-online.com
	with esmtp id 19PiOm-1kvqDI0; Tue, 10 Jun 2003 14:38:48 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 3948E429AA; Tue, 10 Jun 2003 14:38:46 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id CDE2EC5FD7; Tue, 10 Jun 2003 14:38:43 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id C9ABFC5492; Tue, 10 Jun 2003 14:38:43 +0200 (MEST)
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Baruch Chaikin <bchaikin@il.marvell.com>,
	linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>
From: Wolfgang Denk <wd@denx.de>
Subject: Re: Building a stand-alone FS on a very limited flash (newbie question) 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Mon, 09 Jun 2003 18:56:12 +0200."
             <20030609165612.GE32450@rembrandt.csv.ica.uni-stuttgart.de> 
Date: Tue, 10 Jun 2003 14:38:38 +0200
Message-Id: <20030610123843.CDE2EC5FD7@atlas.denx.de>
X-Seen: false
X-ID: rw9RGuZfwepaNAtzXq7Hp01P1Wxj+fOl8f3f1IoA5By5jN5uwpc1gJ@t-dialin.net
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2579
X-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 <20030609165612.GE32450@rembrandt.csv.ica.uni-stuttgart.de> you wrote:
> Baruch Chaikin wrote:
> > Hi all,
> > 
> > I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
> > machine. This works fine, but is unsuitable for system deployment. Do 
> > you have hints for me where to start, in order to put the file system on 
> > flash? The platform I'm using is very limited - only one MTD block of 
> > 2.5 MB is available for the file system, out of a 4 MB flash:
> >    0.5 MB is allocated for the firmware code
> >    1.0 MB for the compressed kernel image
> >    2.5 MB for the (compressed?) file system
> > 
> > For example, I've noticed LibC itself is ~5 MB !
> 
> You'll need a smaller libc, dietlibc comes to mind.
> http://www.dietlibc.org/

I don't really understand what all this discussion is about.

2.5 MB is plenty of space for a compressed ramdisk  image  using  the
standard  C  library. The ramdisk image included with our ELDK is 1.3
MB:

	-> ls -l /opt/eldk/mips_4KC/images/ramdisk_image.gz
	-rw-r--r--    1 root     root      1370532 Mar 18 18:09 /opt/eldk/mips_4KC/images/ram

It is based on Busybox, but also includes  standard  login  with  PAM
support, xinetd plus telnet and FTP.


Yes, libc _is_ big. But 5 MB is wrong. Remember that  you  can  strip
the library for the starget system. In our ramdisk image we get:

# ls -l lib | grep -v '^[ld]'
total 2433
-rwxr-xr-x    1 root     root        97308 Jan  1  1970 ld-2.2.5.so
-rwxr-xr-x    1 root     root      1448336 Jan  1  1970 libc-2.2.5.so
-rwxr-xr-x    1 root     root        28544 Jan  1  1970 libcrypt-2.2.5.so
-rwxr-xr-x    1 root     root        14204 Jan  1  1970 libdl-2.2.5.so
-rwxr-xr-x    1 root     root       515740 Jan  1  1970 libm-2.2.5.so
-rwxr-xr-x    1 root     root        99156 Jan  1  1970 libnsl-2.2.5.so
-rwxr-xr-x    1 root     root        62132 Jan  1  1970 libnss_compat-2.2.5.so
-rwxr-xr-x    1 root     root        56376 Jan  1  1970 libnss_files-2.2.5.so
-rwxr-xr-x    1 root     root        40897 Jan  1  1970 libpam.so.0.75
-rwxr-xr-x    1 root     root        13886 Jan  1  1970 libpam_misc.so.0.75
-rwxr-xr-x    1 root     root        75068 Jan  1  1970 libresolv-2.2.5.so
-rwxr-xr-x    1 root     root        12788 Jan  1  1970 libutil-2.2.5.so



So just use the standard libraries - it will fit easily.


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
Hindsight is an exact science.

From ica2_ts@csv.ica.uni-stuttgart.de Tue Jun 10 13:56:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 13:56:31 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:3374
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224827AbTFJM43>; Tue, 10 Jun 2003 13:56:29 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19Pifn-0008GS-00; Tue, 10 Jun 2003 14:56:23 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19Pifn-0003Pa-00; Tue, 10 Jun 2003 14:56:23 +0200
Date: Tue, 10 Jun 2003 14:56:23 +0200
To: Wolfgang Denk <wd@denx.de>
Cc: Baruch Chaikin <bchaikin@il.marvell.com>,
	linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>
Subject: Re: Building a stand-alone FS on a very limited flash (newbie question)
Message-ID: <20030610125623.GC30175@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030609165612.GE32450@rembrandt.csv.ica.uni-stuttgart.de> <20030610123843.CDE2EC5FD7@atlas.denx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030610123843.CDE2EC5FD7@atlas.denx.de>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2580
X-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

Wolfgang Denk wrote:
[snip]
> > > The platform I'm using is very limited - only one MTD block of 
> > > 2.5 MB is available for the file system, out of a 4 MB flash:
> > >    0.5 MB is allocated for the firmware code
> > >    1.0 MB for the compressed kernel image
> > >    2.5 MB for the (compressed?) file system
> > > 
> > > For example, I've noticed LibC itself is ~5 MB !
> > 
> > You'll need a smaller libc, dietlibc comes to mind.
> > http://www.dietlibc.org/
> 
> I don't really understand what all this discussion is about.
> 
> 2.5 MB is plenty of space for a compressed ramdisk  image  using  the
> standard  C  library. The ramdisk image included with our ELDK is 1.3
> MB:
[snip]
> # ls -l lib | grep -v '^[ld]'
> total 2433

I conclude ELDK consists of little more than the basic networking utilities,
and the libc-related parts eat up most of the space. A more feature-rich
system probably can't afford to waste that much.


Thiemo

From wd@denx.de Tue Jun 10 14:16:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 14:16:03 +0100 (BST)
Received: from mailout04.sul.t-online.com ([IPv6:::ffff:194.25.134.18]:46533
	"EHLO mailout04.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8224827AbTFJNQB>; Tue, 10 Jun 2003 14:16:01 +0100
Received: from fwd08.aul.t-online.de 
	by mailout04.sul.t-online.com with smtp 
	id 19PiyX-0002LC-04; Tue, 10 Jun 2003 15:15:45 +0200
Received: from denx.de (ZZIfO8ZUgeNpqlPAuRjz8oBbZb4o3ZQueY3d-VE9R7T8JRWrCJkjEX@[217.235.217.122]) by fmrl08.sul.t-online.com
	with esmtp id 19PiyG-05DeYy0; Tue, 10 Jun 2003 15:15:28 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 6F7D3429AA; Tue, 10 Jun 2003 15:15:27 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 47A8BC5FD7; Tue, 10 Jun 2003 15:15:19 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 417D8C5492; Tue, 10 Jun 2003 15:15:19 +0200 (MEST)
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Baruch Chaikin <bchaikin@il.marvell.com>,
	linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>
From: Wolfgang Denk <wd@denx.de>
Subject: Re: Building a stand-alone FS on a very limited flash (newbie question) 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Tue, 10 Jun 2003 14:56:23 +0200."
             <20030610125623.GC30175@rembrandt.csv.ica.uni-stuttgart.de> 
Date: Tue, 10 Jun 2003 15:15:14 +0200
Message-Id: <20030610131519.47A8BC5FD7@atlas.denx.de>
X-Seen: false
X-ID: ZZIfO8ZUgeNpqlPAuRjz8oBbZb4o3ZQueY3d-VE9R7T8JRWrCJkjEX@t-dialin.net
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2581
X-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 <20030610125623.GC30175@rembrandt.csv.ica.uni-stuttgart.de> you wrote:
>
> > # ls -l lib | grep -v '^[ld]'
> > total 2433
> 
> I conclude ELDK consists of little more than the basic networking utilities,

The ELDK (Embedded Linux Development Kit) consists of MUCH more (more
than 400 MB if you install everything).

I was just talking about the  ramdisk  image.  You  are  right,  this
contains busybox plus basic networking utilities. For this framework,
the compressed image size is about 1.3 MB.

> and the libc-related parts eat up most of the space. A more feature-rich
> system probably can't afford to waste that much.

The oriiginal poster mentioned that he has 2.5 MB available, so if he
uses something like the framework I mentioned he  still  has  1.2  MB
compressed size available. This is a _lot_.


If memroy really gets tight, there are other  places  where  you  can
save space, for example the O.P. wrote:

>   0.5 MB is allocated for the firmware code
>   1.0 MB for the compressed kernel image
>   2.5 MB for the (compressed?) file system

The reservation for both the firmware and for  the  kernel  image  is
more  than generous; 256 kB + 768 kB should be sufficient, too. Which
gives another 0.5 MB for application stuff.


Please understand me right: I do not want  to  deny  that  uClibc  or
dietlibc  are  fine  methods  to  optimize  the memory footprint of a
system. But for a starter it is probably much easier to use  standard
libraries as long as there is memory available.

For the current thread the keyword was "strip". 


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
"What the scientists have in their briefcases is terrifying."
- Nikita Khrushchev

From mleopold@tiscali.dk Tue Jun 10 18:52:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 18:52:57 +0100 (BST)
Received: from smtp220.tiscali.dk ([IPv6:::ffff:62.79.79.114]:6889 "EHLO
	smtp220.tiscali.dk") by linux-mips.org with ESMTP
	id <S8224827AbTFJRwx> convert rfc822-to-8bit; Tue, 10 Jun 2003 18:52:53 +0100
Received: from cpmail4.dk.tiscali.com (mail.tiscali.dk [212.54.64.159])
	by smtp220.tiscali.dk (8.12.6p2/8.12.6) with ESMTP id h5AHqgBQ054821
	for <linux-mips@linux-mips.org>; Tue, 10 Jun 2003 19:52:51 +0200 (CEST)
	(envelope-from mleopold@tiscali.dk)
Received: from [130.225.96.2] by cpmail4.dk.tiscali.com with HTTP; Tue, 10 Jun 2003 19:52:31 +0200
Date: Tue, 10 Jun 2003 19:52:31 +0200
Message-ID: <3EDD28A400000B96@cpfe4.be.tisc.dk>
From: mleopold@tiscali.dk
Subject: Linux on Indigo2 (IP28) - R10000
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 8BIT
Return-Path: <mleopold@tiscali.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2582
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mleopold@tiscali.dk
Precedence: bulk
X-list: linux-mips

Hi All.
I just got my hands on an old SGI Indigo2 and I would like to install Linux
on it (preferably Debian). I've searched a few places and I get contradicting
signals on whether this might work or not. The machine is an Indigo2 (IP28)
175MHz R10000.

I've tried booting over the net using bootp and tftp following the instructionsin
the debian-howto.. The machine gets an IP and immediately writes "execute
format error" (using the r4k-ip22/tftpboot.img image). I'm guessing that
this is and 32/64 bit problem, but I really haven't got a clue. I found
an other image looking like it might be a 64 bit image (from Kumba, the
Gentoo guy), it downloads and then freezes the machine.

Can anybody give me some hints here: what I'm I suppose to do? Will this
ever work? I don't really care about installation method (network, cd, etc).
There was some talk in Febuary on a guy got Linux up and running on an Origin
200 - and some bootable cd's. That sounded prety interesting =]

Btw: I also got my hands on an Octane (IP30) with an R10000 (195 Mhz) -
I haven't tried to install on this one, but that might be interesting too..

--
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen




From ica2_ts@csv.ica.uni-stuttgart.de Tue Jun 10 19:11:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 19:11:07 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:38959
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224827AbTFJSLF>; Tue, 10 Jun 2003 19:11:05 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19PnaG-0001v9-00; Tue, 10 Jun 2003 20:11:00 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19PnaG-0002dg-00; Tue, 10 Jun 2003 20:11:00 +0200
Date: Tue, 10 Jun 2003 20:11:00 +0200
To: mleopold@tiscali.dk
Cc: linux-mips@linux-mips.org
Subject: Re: Linux on Indigo2 (IP28) - R10000
Message-ID: <20030610181100.GB529@rembrandt.csv.ica.uni-stuttgart.de>
References: <3EDD28A400000B96@cpfe4.be.tisc.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EDD28A400000B96@cpfe4.be.tisc.dk>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2583
X-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

mleopold@tiscali.dk wrote:
> Hi All.
> I just got my hands on an old SGI Indigo2 and I would like to install Linux
> on it (preferably Debian). I've searched a few places and I get contradicting
> signals on whether this might work or not. The machine is an Indigo2 (IP28)
> 175MHz R10000.

I have such a machine, too. Short summary: It won't work yet.

> I've tried booting over the net using bootp and tftp following the instructionsin
> the debian-howto.. The machine gets an IP and immediately writes "execute
> format error" (using the r4k-ip22/tftpboot.img image). I'm guessing that
> this is and 32/64 bit problem, but I really haven't got a clue.

That's because the R10000 Firmware wnats only ELF64 objects.

> I found
> an other image looking like it might be a 64 bit image (from Kumba, the
> Gentoo guy), it downloads and then freezes the machine.
> 
> Can anybody give me some hints here: what I'm I suppose to do? Will this
> ever work? I don't really care about installation method (network, cd, etc).

Some SGI uniprocessor R10000 machines are non-I/O-coherent, specifically
the IP28 ans the IP32. The R10000 has a bug/performance feature which
leads to erraneously marked dirty cachelines, which wreaks havoc on those
machines for DMA transfers.

The solution is to use a special kernel with compiled in cache barriers
(needs a not-yet written compiler patch) and careful managing of page
table accesses from userspace (needs rmap, and thus 2.5 Kernel).

I'm working slowly on it, but I get constantly distracted by toolchain
issues. :-)

> There was some talk in Febuary on a guy got Linux up and running on an Origin
> 200 - and some bootable cd's. That sounded prety interesting =]

The Origin is easier to support, it has coherent I/O.

> Btw: I also got my hands on an Octane (IP30) with an R10000 (195 Mhz) -
> I haven't tried to install on this one, but that might be interesting too..

This one is also I/O coherent, so chances are much better than for IP28.


Thiemo

From mleopold@tiscali.dk Tue Jun 10 19:38:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 19:38:25 +0100 (BST)
Received: from smtp110.tiscali.dk ([IPv6:::ffff:62.79.79.110]:33248 "EHLO
	smtp110.tiscali.dk") by linux-mips.org with ESMTP
	id <S8224827AbTFJSiX> convert rfc822-to-8bit; Tue, 10 Jun 2003 19:38:23 +0100
Received: from cpmail4.dk.tiscali.com (mail.tiscali.dk [212.54.64.159])
	by smtp110.tiscali.dk (8.12.6p2/8.12.6) with ESMTP id h5AIcM56032710;
	Tue, 10 Jun 2003 20:38:22 +0200 (CEST)
	(envelope-from mleopold@tiscali.dk)
Received: from [130.225.96.2] by cpmail4.dk.tiscali.com with HTTP; Tue, 10 Jun 2003 20:38:19 +0200
Date: Tue, 10 Jun 2003 20:38:19 +0200
Message-ID: <3EDD28A400000BAC@cpfe4.be.tisc.dk>
In-Reply-To: <20030610181100.GB529@rembrandt.csv.ica.uni-stuttgart.de>
From: mleopold@tiscali.dk
Subject: Re: Linux on Indigo2 (IP28) - R10000
To: linux-mips@linux-mips.org
Cc: "Thiemo Seufer" <ica2_ts@csv.ica.uni-stuttgart.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 8BIT
Return-Path: <mleopold@tiscali.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2584
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mleopold@tiscali.dk
Precedence: bulk
X-list: linux-mips

Hi Thiemo.
> The solution is to use a special kernel with compiled in cache barriers
> (needs a not-yet written compiler patch) and careful managing of page
> table accesses from userspace (needs rmap, and thus 2.5 Kernel).

I noticed this guy talking about O2 and having some patches and precompiled
kernels. Are these in anyway related to what you are talking about?

http://www.linux-mips.org/~glaurung/

> I'm working sowly on it, but I get constantly distracted by toolchain
> issues. :-)

I looked arround your website and saw "mips64-linux-ip28-2002-06-28.tar.gz"
whoo.. Sounds exiting =]

> > There was some talk in Febuary on a guy got Linux up and running on
an 
> > Origin 200 - and some bootable cd's. That sounded prety interesting
=]
> The Origin is easier to suppot, it has coherent I/O.

And you are probably going to tell me that this is the same reson that the
O2 is working, right?

> > Btw: I also got my hands on an Octane (IP30) with an R10000 (195 Mhz)
-
> > I haven't tried to install on this one, but that might be interesting
too..
> This one is also I/O coherent, so chances are much better than for IP28.

Are you saying I might get this one working with the Debian boot-images
that I already tried, or?

--
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen






From ilya@gateway.total-knowledge.com Tue Jun 10 19:56:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 19:56:34 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:39317
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225235AbTFJS4c>; Tue, 10 Jun 2003 19:56:32 +0100
Received: (qmail 7087 invoked by uid 502); 10 Jun 2003 18:56:27 -0000
Date: Tue, 10 Jun 2003 11:56:27 -0700
From: ilya@theIlya.com
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: mleopold@tiscali.dk, linux-mips@linux-mips.org
Subject: Re: Linux on Indigo2 (IP28) - R10000
Message-ID: <20030610185627.GB7024@gateway.total-knowledge.com>
References: <3EDD28A400000B96@cpfe4.be.tisc.dk> <20030610181100.GB529@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H"
Content-Disposition: inline
In-Reply-To: <20030610181100.GB529@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2585
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

On Tue, Jun 10, 2003 at 08:11:00PM +0200, Thiemo Seufer wrote:
> mleopold@tiscali.dk wrote:
> > Btw: I also got my hands on an Octane (IP30) with an R10000 (195 Mhz) -
> > I haven't tried to install on this one, but that might be interesting t=
oo..
>=20
> This one is also I/O coherent, so chances are much better than for IP28.
And Keith Wesolowsky is even working on it. Only problem is complete absence
of documentation.

>=20
>=20
> Thiemo
>=20

--4SFOXa2GPu3tIq4H
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+5inb7sVBmHZT8w8RAsEzAKCtQ5FTzUdLaYy++j7kFCazbneplACgqsPF
aH1oMwqx18eUiQ/I62JlWeo=
=8Z1I
-----END PGP SIGNATURE-----

--4SFOXa2GPu3tIq4H--

From ica2_ts@csv.ica.uni-stuttgart.de Tue Jun 10 19:59:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 19:59:31 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:53295
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224827AbTFJS72>; Tue, 10 Jun 2003 19:59:28 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19PoL9-0002Dh-00; Tue, 10 Jun 2003 20:59:27 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19PoL9-0004UF-00; Tue, 10 Jun 2003 20:59:27 +0200
Date: Tue, 10 Jun 2003 20:59:27 +0200
To: mleopold@tiscali.dk
Cc: linux-mips@linux-mips.org
Subject: Re: Linux on Indigo2 (IP28) - R10000
Message-ID: <20030610185927.GC529@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030610181100.GB529@rembrandt.csv.ica.uni-stuttgart.de> <3EDD28A400000BAC@cpfe4.be.tisc.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EDD28A400000BAC@cpfe4.be.tisc.dk>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2586
X-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

mleopold@tiscali.dk wrote:
> Hi Thiemo.
> > The solution is to use a special kernel with compiled in cache barriers
> > (needs a not-yet written compiler patch) and careful managing of page
> > table accesses from userspace (needs rmap, and thus 2.5 Kernel).
> 
> I noticed this guy talking about O2 and having some patches and precompiled
> kernels. Are these in anyway related to what you are talking about?
> 
> http://www.linux-mips.org/~glaurung/

Partially yes, the O2 as a ELF32 machine allows a different (and more
performant) solution for the speculative store problem.

> > I'm working sowly on it, but I get constantly distracted by toolchain
> > issues. :-)
> 
> I looked arround your website and saw "mips64-linux-ip28-2002-06-28.tar.gz"
> whoo.. Sounds exiting =]

I know it's somewhat outdated. :-)

> > > There was some talk in Febuary on a guy got Linux up and running on an
> > > Origin 200 - and some bootable cd's. That sounded prety interesting =]
> > The Origin is easier to suppot, it has coherent I/O.
> 
> And you are probably going to tell me that this is the same reson that the
> O2 is working, right?

Only the R5000 O2 is working. The R10000 O2 is the problematic one.

> > > Btw: I also got my hands on an Octane (IP30) with an R10000 (195 Mhz) -
> > > I haven't tried to install on this one, but that might be interesting too..
> > This one is also I/O coherent, so chances are much better than for IP28.
> 
> Are you saying I might get this one working with the Debian boot-images
> that I already tried, or?

It might work, but I know way to little about the Octane to say something
definitive.


Thiemo

From ralf@linux-mips.org Tue Jun 10 20:14:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 20:14:24 +0100 (BST)
Received: from p508B5A54.dip.t-dialin.net ([IPv6:::ffff:80.139.90.84]:43170
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224827AbTFJTOV>; Tue, 10 Jun 2003 20:14:21 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5AJEJbY006997;
	Tue, 10 Jun 2003 12:14:19 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5AJE9fA006996;
	Tue, 10 Jun 2003 21:14:09 +0200
Date: Tue, 10 Jun 2003 21:14:08 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: mleopold@tiscali.dk, linux-mips@linux-mips.org
Subject: Re: Linux on Indigo2 (IP28) - R10000
Message-ID: <20030610191408.GA6310@linux-mips.org>
References: <20030610181100.GB529@rembrandt.csv.ica.uni-stuttgart.de> <3EDD28A400000BAC@cpfe4.be.tisc.dk> <20030610185927.GC529@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030610185927.GC529@rembrandt.csv.ica.uni-stuttgart.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: 2587
X-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, Jun 10, 2003 at 08:59:27PM +0200, Thiemo Seufer wrote:

> > Are you saying I might get this one working with the Debian boot-images
> > that I already tried, or?
> 
> It might work, but I know way to little about the Octane to say something
> definitive.

The Octane is yet unsupported but apprently architecturally very similar
to a single-node Origin 200 so supporting it shouldn't be too hard.  That
excludes the Octane's graphics subsystem about which I know nothing at all.

  Ralf

From erik@greendragon.org Tue Jun 10 20:37:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 20:37:28 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:46792 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8224827AbTFJTh0>;
	Tue, 10 Jun 2003 20:37:26 +0100
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP
	id D69B436FB; Tue, 10 Jun 2003 14:37:28 -0500 (CDT)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id h5AJbGwK081188;
	Tue, 10 Jun 2003 14:37:16 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id h5AJbE75081187;
	Tue, 10 Jun 2003 19:37:14 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to erik@greendragon.org using -f
Received: from stpns.guidant.com (stpns.guidant.com [132.189.76.10]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Tue, 10 Jun 2003 19:37:14 +0000
Message-ID: <1055273834.3ee6336a57461@my.visi.com>
Date: Tue, 10 Jun 2003 19:37:14 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Subject: Re: Linux on Indigo2 (IP28) - R10000
References: <3EDD28A400000BAC@cpfe4.be.tisc.dk>
In-Reply-To: <3EDD28A400000BAC@cpfe4.be.tisc.dk>
MIME-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP: 132.189.76.10
Return-Path: <erik@greendragon.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2588
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting "mleopold@tiscali.dk" <mleopold@tiscali.dk>:

> > > Btw: I also got my hands on an Octane (IP30) with an R10000 (195 Mhz)
> -
> > > I haven't tried to install on this one, but that might be interesting
> too..
> > This one is also I/O coherent, so chances are much better than for IP28.
> 
> Are you saying I might get this one working with the Debian boot-images
> that I already tried, or?

That's pretty unlikely.  I am currently working on the Octane in what little
spare time I can wrest away from work.  On the good side, the octane peripherals
seem generally the same as the Origin, so I'm finding a lot of similarities in
the hardware for console and network (IOC3 chip), for instance.  The memory map
is different though, which means that barring some kernel hacking you won't get
a kernel to boot on it from any existing boot image.  I haven't gotten to the
point of trying to make the video hardware work, although I do have a PCI
shoebox I might try a Radeon PCI card in eventually.

Feel free to join in hacking on it, you might be better at it than I am =)


Erik



-- 
Erik J. Green
erik@greendragon.org

From ralf@linux-mips.org Tue Jun 10 20:48:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 20:48:19 +0100 (BST)
Received: from p508B5A54.dip.t-dialin.net ([IPv6:::ffff:80.139.90.84]:45220
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224827AbTFJTsQ>; Tue, 10 Jun 2003 20:48:16 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5AJmEbY007899;
	Tue, 10 Jun 2003 12:48:14 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5AJmDxg007898;
	Tue, 10 Jun 2003 21:48:13 +0200
Date: Tue, 10 Jun 2003 21:48:13 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: MIPS CACHE TESTS
Message-ID: <20030610194813.GB6310@linux-mips.org>
References: <56BEF0DBC8B9D611BFDB00508B5E2634102FAC@tlexposeidon.teralogic-inc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56BEF0DBC8B9D611BFDB00508B5E2634102FAC@tlexposeidon.teralogic-inc.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2589
X-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, Jun 06, 2003 at 11:00:23AM -0700, Dennis Castleman wrote:

(Well, not Dennis but Spamassassin ...)

> This mail is probably spam.  The original message has been attached
> along with this report, so you can recognize or block similar unwanted
> mail in future.  See http://spamassassin.org/tag/ for more details.

Of course it's not been spam, sorry for that faux pas.  This has been the
first false hit since I'm running Spamassassin for the linux-mips.org
mailing lists and so turned out a little bug in the scripts.

In any case, sending HTML to any of the linux-mips.org lists is an almost
certai way to get caught by the spam filter - HTML email on Linux mailing
lists is an almost certain indicator of SPAM ...

Back to the real business ...

> Subject: MIPS CACHE TESTS

> I trying to find a way of test both the instruction and data caches for a
> MIPS 5KC core.
> Does any body have any ideas?  Data cache is easy instruction cache is not
> so easy.

The trick is to run uncached.

> The Magnum pc-50 use to have a monitor called Rx4230 MIPS Monitor.
> This monitor dumped the following on power up

You're the first one to post about using Magnums in quite a while ...

> PONs Complete...
> PON Diagnostics Version 5.05 MIPS OPT Fri May 29 14:22:07 
>  
> YOMAN doesn't have any thing like this.  If any one knows of power on tests
> for a 5KC it would be of great interest to me.

I don't know of any readily available code.  The general strategy is to
run the cache tests in uncached mode and use the Index_Load_Tag_I etc.
commands to manipulate the cache content directly.  The general
strategy is to first verify that there are no dead bits in the cache,
the initialize all cache indices such that the ECC are set correctly to
avoid a later cache error exception.  For some set-way associative caches
the LRU bits may also have to be initialized.

Linux expects all this to already have been done by the firmware before
it's started.

  Ralf

From wesolows@foobazco.org Tue Jun 10 21:21:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Jun 2003 21:21:19 +0100 (BST)
Received: from janus.foobazco.org ([IPv6:::ffff:198.144.194.226]:25984 "EHLO
	mail.foobazco.org") by linux-mips.org with ESMTP
	id <S8224821AbTFJUVR>; Tue, 10 Jun 2003 21:21:17 +0100
Received: by mail.foobazco.org (Postfix, from userid 1014)
	id 3C259FABB; Tue, 10 Jun 2003 13:21:14 -0700 (PDT)
Date: Tue, 10 Jun 2003 13:21:14 -0700
From: Keith M Wesolowski <wesolows@foobazco.org>
To: ilya@theIlya.com
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	mleopold@tiscali.dk, linux-mips@linux-mips.org
Subject: Re: Linux on Indigo2 (IP28) - R10000
Message-ID: <20030610202114.GA3588@foobazco.org>
References: <3EDD28A400000B96@cpfe4.be.tisc.dk> <20030610181100.GB529@rembrandt.csv.ica.uni-stuttgart.de> <20030610185627.GB7024@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030610185627.GB7024@gateway.total-knowledge.com>
User-Agent: Mutt/1.5.4i
Return-Path: <wesolows@foobazco.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2590
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wesolows@foobazco.org
Precedence: bulk
X-list: linux-mips

On Tue, Jun 10, 2003 at 11:56:27AM -0700, ilya@theIlya.com wrote:

> And Keith Wesolowsky is even working on it. Only problem is complete absence
> of documentation.

Well, for values of "working" that involve reading headers and
pondering, yeah.  We have the memory map from the irix headers;
otherwise as Ralf points out it should have been called Origin 100.
Getting a serial-only port going should not be terribly hard.  The
problem, as always, is finding time to work on these things.  Any of
you who are students will probably get to this long before we working
stiffs do, so have at it...

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

From anemo@mba.ocn.ne.jp Wed Jun 11 02:10:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Jun 2003 02:10:43 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:6406
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224821AbTFKBKk>; Wed, 11 Jun 2003 02:10:40 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 11 Jun 2003 01:10:39 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h5B1ATiY005172;
	Wed, 11 Jun 2003 10:10:30 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Wed, 11 Jun 2003 10:11:20 +0900 (JST)
Message-Id: <20030611.101120.74755822.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Deleting kbd-no.c (Re: CVS Update@-mips.org: linux)
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030610124313Z8224827-1272+2433@linux-mips.org>
References: <20030610124313Z8224827-1272+2433@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2591
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Tue, 10 Jun 2003 13:43:09 +0100, ralf@linux-mips.org said:
ralf> Removed files:
ralf> 	arch/mips/lib  : kbd-no.c kbd-std.c 
ralf> 	arch/mips64/lib: kbd-no.c kbd-std.c 

ralf> Log message:
ralf> 	Delete unused source files.

If we implement kbd_controller_present() macro, kbd-no.c is not needed
in 2.4 kernel too.


Here is a patch.  I posted same patch three month ago but new one
includes mips64 changes.

diff -ur linux-mips-cvs/arch/mips/kernel/setup.c linux.new/arch/mips/kernel/setup.c
--- linux-mips-cvs/arch/mips/kernel/setup.c	Thu May  8 10:28:23 2003
+++ linux.new/arch/mips/kernel/setup.c	Wed Jun 11 09:46:59 2003
@@ -68,7 +68,6 @@
 struct rtc_ops *rtc_ops;
 
 #ifdef CONFIG_PC_KEYB
-extern struct kbd_ops no_kbd_ops;
 struct kbd_ops *kbd_ops;
 #endif
 
@@ -505,10 +504,6 @@
 	ide_ops = &no_ide_ops;
 #endif
 
-#ifdef CONFIG_PC_KEYB
-	kbd_ops = &no_kbd_ops;
-#endif
-
 	rtc_ops = &no_rtc_ops;
 
 	switch(mips_machgroup)
diff -ur linux-mips-cvs/arch/mips/lib/Makefile linux.new/arch/mips/lib/Makefile
--- linux-mips-cvs/arch/mips/lib/Makefile	Fri Feb 14 09:41:21 2003
+++ linux.new/arch/mips/lib/Makefile	Wed Jun 11 09:47:35 2003
@@ -19,6 +19,6 @@
 
 obj-$(CONFIG_BLK_DEV_FD)	+= floppy-no.o floppy-std.o
 obj-$(subst m,y,$(CONFIG_IDE))	+= ide-std.o ide-no.o	# needed for ide module
-obj-$(CONFIG_PC_KEYB)		+= kbd-std.o kbd-no.o
+obj-$(CONFIG_PC_KEYB)		+= kbd-std.o
 
 include $(TOPDIR)/Rules.make
diff -ur linux-mips-cvs/arch/mips64/kernel/setup.c linux.new/arch/mips64/kernel/setup.c
--- linux-mips-cvs/arch/mips64/kernel/setup.c	Thu May  8 10:28:23 2003
+++ linux.new/arch/mips64/kernel/setup.c	Wed Jun 11 09:46:23 2003
@@ -68,7 +68,6 @@
 extern struct rtc_ops no_rtc_ops;
 struct rtc_ops *rtc_ops;
 
-extern struct kbd_ops no_kbd_ops;
 struct kbd_ops *kbd_ops;
 
 /*
diff -ur linux-mips-cvs/arch/mips64/lib/Makefile linux.new/arch/mips64/lib/Makefile
--- linux-mips-cvs/arch/mips64/lib/Makefile	Fri Feb 14 09:41:26 2003
+++ linux.new/arch/mips64/lib/Makefile	Wed Jun 11 09:48:17 2003
@@ -12,6 +12,6 @@
 
 obj-$(CONFIG_BLK_DEV_FD)	+= floppy-no.o floppy-std.o
 obj-$(subst m,y,$(CONFIG_IDE))	+= ide-std.o ide-no.o	# needed for ide module
-obj-$(CONFIG_PC_KEYB)		+= kbd-std.o kbd-no.o
+obj-$(CONFIG_PC_KEYB)		+= kbd-std.o
 
 include $(TOPDIR)/Rules.make
diff -ur linux-mips-cvs/include/asm-mips/keyboard.h linux.new/include/asm-mips/keyboard.h
--- linux-mips-cvs/include/asm-mips/keyboard.h	Fri Jan  4 07:54:52 2002
+++ linux.new/include/asm-mips/keyboard.h	Wed Jun 11 09:43:13 2003
@@ -62,6 +62,7 @@
 };
 
 extern struct kbd_ops *kbd_ops;
+#define kbd_controller_present() (kbd_ops != 0)
 
 /* Do the actual calls via kbd_ops vector  */
 #define kbd_request_region() kbd_ops->kbd_request_region()
diff -ur linux-mips-cvs/include/asm-mips64/keyboard.h linux.new/include/asm-mips64/keyboard.h
--- linux-mips-cvs/include/asm-mips64/keyboard.h	Fri Jan  4 07:54:52 2002
+++ linux.new/include/asm-mips64/keyboard.h	Wed Jun 11 09:43:29 2003
@@ -62,6 +62,7 @@
 };
 
 extern struct kbd_ops *kbd_ops;
+#define kbd_controller_present() (kbd_ops != 0)
 
 /* Do the actual calls via kbd_ops vector  */
 #define kbd_request_region() kbd_ops->kbd_request_region()
---
Atsushi Nemoto

From Geert.Uytterhoeven@sonycom.com Wed Jun 11 16:47:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Jun 2003 16:47:04 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:6374 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225246AbTFKPrC>;
	Wed, 11 Jun 2003 16:47:02 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h5BFkspI005098
	for <linux-mips@linux-mips.org>; Wed, 11 Jun 2003 17:46:55 +0200 (MEST)
Date: Wed, 11 Jun 2003 17:46:53 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Corruption in 2.4.x
Message-ID: <Pine.GSO.4.21.0306111738200.6450-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2592
X-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

	Hi,

Recently we started seeing slight file corruption and random segmentation
faults with the 2.4.x MIPS kernel from CVS. The problems appeared after
upgrading from 2.4.20 (CVS 2003-01-13) to 2.4.21-pre4 (CVS 2003-05-06), which
introduced the new cache/tlb optimizations.

Most prominent indication of the file corruption is the corruption of
/etc/motd, of which the non-first lines are rewritten by the startup scripts on
every boot up.

The CPU contains a VR4120A core, running in big endian mode. It should be very
similar to the core in the VR4131, with the following exceptions:
  - both the instruction and data cache are direct mapped instead of 2-way
    associative
  - the data cache is only 8 KiB instead of 16 KiB

Perhaps this rings a bell?

Our cross-toolchain consists of gcc 3.2.2 and binutils 2.13.2.1. Userland is
Debian (mostly woody).

Relevant part of dmesg:

| CPU revision is: 00000c72
| Primary instruction cache 16kB, physically tagged, direct mapped, linesize 16 bytes.
| Primary data cache 8kB direct mapped, linesize 16 bytes.

Relevant part of /proc/cpuinfo:

| cpu model               : NEC VR4122 V7.2
| BogoMIPS                : 165.88
| wait instruction        : no
| microsecond timers      : yes
| tlb_entries             : 32
| extra interrupt vector  : no
| hardware watchpoint     : no
| VCED exceptions         : not available
| VCEI exceptions         : not available

Thanks!

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.Uytterhoeven@sonycom.com Wed Jun 11 17:09:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Jun 2003 17:10:01 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:13698 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225246AbTFKQJ6>;
	Wed, 11 Jun 2003 17:09:58 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h5BG9jpI007826
	for <linux-mips@linux-mips.org>; Wed, 11 Jun 2003 18:09:45 +0200 (MEST)
Date: Wed, 11 Jun 2003 18:09:44 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: 2.4.17 kernel for PlayStation 2
Message-ID: <Pine.GSO.4.21.0306111802270.6450-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2593
X-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


Apparently Sony released a 2.4.17 kernel for the PlayStation 2 on their Linux
webpage (http://www.sony.net/Products/Linux/). The kernel sources can be
downloaded from this direct link:

    http://www.sony.net/Products/Linux/Download/PlayStation_BB_Navigator.html

As I don't have a PlayStation 2, I cannot comment on the
code/performance/usability. I also don't know how much work it will be to
integrate this in the Linux/MIPS CVS tree. The code seems to be based on a
stripped-down kernel source tree from Monta Vista.

Have fun ;-)

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 mleopold@tiscali.dk Wed Jun 11 21:32:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Jun 2003 21:32:50 +0100 (BST)
Received: from smtp010.tiscali.dk ([IPv6:::ffff:212.54.64.103]:1985 "EHLO
	smtp010.tiscali.dk") by linux-mips.org with ESMTP
	id <S8225227AbTFKUcq>; Wed, 11 Jun 2003 21:32:46 +0100
Received: from asterix (213.237.126.42.adsl.soeb.worldonline.dk [213.237.126.42])
	by smtp010.tiscali.dk (8.12.5/8.12.5) with ESMTP id h5BKWfiZ011854;
	Wed, 11 Jun 2003 22:32:42 +0200 (MEST)
Date: Wed, 11 Jun 2003 22:35:18 +0200
From: Martin Leopold <mleopold@tiscali.dk>
To: linux-mips@linux-mips.org
Cc: mleopold@tiscali.dk
Subject: Re: Linux on Indigo2 (IP28) - R10000
Message-ID: <20030611203518.GA4986@asterix.cartoonnet>
References: <20030610181100.GB529@rembrandt.csv.ica.uni-stuttgart.de> <3EDD28A400000BAC@cpfe4.be.tisc.dk> <20030610185927.GC529@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20030610185927.GC529@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Tue, Jun 10, 2003 at 20:59:27 +0200
X-Mailer: Balsa 1.4.4
Lines: 17
Return-Path: <mleopold@tiscali.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2594
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mleopold@tiscali.dk
Precedence: bulk
X-list: linux-mips


On 2003.06.10 20:59 Thiemo Seufer wrote:
> > I looked arround your website and saw
> > "mips64-linux-ip28-2002-06-28.tar.gz"
> > whoo.. Sounds exiting =]
> I know it's somewhat outdated. :-)

Hehe.. I tried it, and it booted. Whopee.. However the kernel-level-IP 
configuration (BOOTP) fails!? I'm not really sure why - the DHCP server 
just gave the IP and kernel-image a moment ago. This make me wonder: 
how far could I get with this kernel? Is it possible that I could 
actually boot an entire system with this kernel, or is that pushing it 
a bit?

-- 
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen

From ica2_ts@csv.ica.uni-stuttgart.de Wed Jun 11 21:41:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Jun 2003 21:41:25 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:65077
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225227AbTFKUlX>; Wed, 11 Jun 2003 21:41:23 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19QCPF-0003Lm-00; Wed, 11 Jun 2003 22:41:17 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19QCPF-0001d5-00; Wed, 11 Jun 2003 22:41:17 +0200
Date: Wed, 11 Jun 2003 22:41:17 +0200
To: Martin Leopold <mleopold@tiscali.dk>
Cc: linux-mips@linux-mips.org
Subject: Re: Linux on Indigo2 (IP28) - R10000
Message-ID: <20030611204117.GO29687@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030610181100.GB529@rembrandt.csv.ica.uni-stuttgart.de> <3EDD28A400000BAC@cpfe4.be.tisc.dk> <20030610185927.GC529@rembrandt.csv.ica.uni-stuttgart.de> <20030611203518.GA4986@asterix.cartoonnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030611203518.GA4986@asterix.cartoonnet>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2595
X-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

Martin Leopold wrote:
> 
> On 2003.06.10 20:59 Thiemo Seufer wrote:
> > > I looked arround your website and saw
> > > "mips64-linux-ip28-2002-06-28.tar.gz"
> > > whoo.. Sounds exiting =]
> > I know it's somewhat outdated. :-)
> 
> Hehe.. I tried it, and it booted. Whopee.. However the kernel-level-IP 
> configuration (BOOTP) fails!? I'm not really sure why - the DHCP server 
> just gave the IP and kernel-image a moment ago. This make me wonder: 
> how far could I get with this kernel? Is it possible that I could 
> actually boot an entire system with this kernel, or is that pushing it 
> a bit?

It happens to work by accident, because the cachelines destoyed
due to the speculative stores don't hit anything important. The
2.5 kernel fails much earlier.


Thiemo

From tcernius@correlant.com Wed Jun 11 23:12:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Jun 2003 23:13:00 +0100 (BST)
Received: from turbonet-2.nethere.net ([IPv6:::ffff:66.63.144.170]:54431 "HELO
	mail.correlant.com") by linux-mips.org with SMTP
	id <S8225227AbTFKWM6>; Wed, 11 Jun 2003 23:12:58 +0100
Received: from tcernius (212.82.218.209.transedge.com [209.218.82.212])
	by mail.correlant.com (Postfix) with SMTP
	id 3A5FDBC118; Wed, 11 Jun 2003 15:12:58 -0700 (PDT)
From: "Tom Cernius" <tcernius@correlant.com>
To: <ppopov@mvista.com>
Cc: <linux-mips@linux-mips.org>
Subject: FW: Db1500 PCI Auto Scan Question
Date: Wed, 11 Jun 2003 15:12:18 -0700
Message-ID: <000201c33066$8623dac0$d452dad1@correlant.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <tcernius@correlant.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2596
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tcernius@correlant.com
Precedence: bulk
X-list: linux-mips

Hello,

   I am porting my first PCI driver for a PCI card hosted by the AMD Db1500
"Zinfandel" development board.
   This driver had been previously working on another host, where
CONFIG_PCI_AUTO was not enabled.

    My PCI card REQUIRES 0xFF000000 and 0x90000000 be programmed into BAR0
and BAR1 respectively.
    My PCI card has nothing programmed into BAR0 and BAR1 at power-up.
    My host Linux kernel was built with CONFIG_PCI, CONFIG_NEW_PCI, and
CONFIG_PCI_AUTO turned on in the .config file.

     I noticed that during boot, the kernel tickles my devices BAR's and
then writes these BARs with addresses in the range of
     4000 0000 thru 43FF FFFF

     I have tried everything and although I am able to write the proper
(0xFF00 0000 and 0x9000 0000) addresses into the BAR's,
     I have been unable to successfully read anything from my PCI cards CPU
Register/Sdram space.

     I suspect that it is NOT possible to use hardcoded PCI BAR addresses
with the MIPS processor AND CONFIG_PCI_AUTO turned on,
     as the kernel expects (and configures the PCI BARS of) PCI devices to
reside in the address space 0x4000 0000 thru 0x43FF FFFF ??

     I tried disabling the device, updating my BARS, reenabling in the
driver code (a loadable module).
     I tried writing the BARS just prior to tickling in the
linux/arch/mips/kernel/pci_auto.c code.
     I tried writing the BARS as soon as my device/vendor id are detected
also in the linux/arch/mips/kernel/pci_auto.c code.

Thanks,
Tom


From mleopold@tiscali.dk Wed Jun 11 23:20:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Jun 2003 23:20:35 +0100 (BST)
Received: from smtp210.tiscali.dk ([IPv6:::ffff:62.79.79.113]:49088 "EHLO
	smtp210.tiscali.dk") by linux-mips.org with ESMTP
	id <S8225227AbTFKWUd>; Wed, 11 Jun 2003 23:20:33 +0100
Received: from asterix (213.237.126.42.adsl.soeb.worldonline.dk [213.237.126.42])
	by smtp210.tiscali.dk (8.12.6p2/8.12.6) with ESMTP id h5BMJAFS020517;
	Thu, 12 Jun 2003 00:19:11 +0200 (CEST)
	(envelope-from mleopold@tiscali.dk)
Date: Thu, 12 Jun 2003 00:21:46 +0200
From: Martin Leopold <mleopold@tiscali.dk>
To: linux-mips@linux-mips.org
Cc: Keith M Wesolowski <wesolows@foobazco.org>
Subject: Linux on Octane IP30 (was Re: Linux on Indigo2 (IP28) - R10000)
Message-ID: <20030611222146.GE5140@asterix.cartoonnet>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Mailer: Balsa 1.4.4
Lines: 33
Return-Path: <mleopold@tiscali.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2597
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mleopold@tiscali.dk
Precedence: bulk
X-list: linux-mips


On 2003.06.10 22:21 Keith M Wesolowski wrote:
> > And Keith Wesolowsky is even working on it. Only problem is complete
> > absence of documentation.
> Well, for values of "working" that involve reading headers and
> pondering, yeah.  We have the memory map from the irix headers;
> otherwise as Ralf points out it should have been called Origin 100.

Which only contributes to my confusion, I have no clue how these 
machines compare.

> Getting a serial-only port going should not be terribly hard.  The
> problem, as always, is finding time to work on these things.  Any of
> you who are students will probably get to this long before we working
> stiffs do, so have at it...

Not that I'm claiming in any way to have the skills nor the time: what 
are the issues involved?

I stumbled uppun some documentation on Andrew Clausen working on 
supporting Origin 200 earlier this year. He wrote a small howto on some 
of the quirks involved in shoving a Linux kernel onto one of those 
beasts.

http://members.optusnet.com.au/clausen/sgi/LINUX-IP27-HOWTO

He has some utils and some info on getting it running, what is your 
take? Will this get my anywhere near having a running Linux on my 
Ocane? Or do I have to start kernel-hacking before that will happen =]?

-- 
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen

From ppopov@mvista.com Thu Jun 12 00:22:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 00:22:07 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:26361 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225255AbTFKXWE>;
	Thu, 12 Jun 2003 00:22:04 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA26636;
	Wed, 11 Jun 2003 16:22:00 -0700
Subject: Re: FW: Db1500 PCI Auto Scan Question
From: Pete Popov <ppopov@mvista.com>
To: Tom Cernius <tcernius@correlant.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <000201c33066$8623dac0$d452dad1@correlant.com>
References: <000201c33066$8623dac0$d452dad1@correlant.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1055373721.9976.690.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 11 Jun 2003 16:22:01 -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: 2598
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, 2003-06-11 at 15:12, Tom Cernius wrote:
> Hello,
> 
>    I am porting my first PCI driver for a PCI card hosted by the AMD Db1500
> "Zinfandel" development board.
>    This driver had been previously working on another host, where
> CONFIG_PCI_AUTO was not enabled.
> 
>     My PCI card REQUIRES 0xFF000000 and 0x90000000 be programmed into BAR0
> and BAR1 respectively.
>     My PCI card has nothing programmed into BAR0 and BAR1 at power-up.
>     My host Linux kernel was built with CONFIG_PCI, CONFIG_NEW_PCI, and
> CONFIG_PCI_AUTO turned on in the .config file.

Why the 0xFF000000 and, in general, the hardcoded addresses?

Which kernel are you using?

>      I noticed that during boot, the kernel tickles my devices BAR's and
> then writes these BARs with addresses in the range of
>      4000 0000 thru 43FF FFFF

Right.

>      I have tried everything and although I am able to write the proper
> (0xFF00 0000 and 0x9000 0000) addresses into the BAR's,
>      I have been unable to successfully read anything from my PCI cards CPU
> Register/Sdram space.

No, that's not going to work. I'll elaborate below.

>      I suspect that it is NOT possible to use hardcoded PCI BAR addresses
> with the MIPS processor AND CONFIG_PCI_AUTO turned on,
>      as the kernel expects (and configures the PCI BARS of) PCI devices to
> reside in the address space 0x4000 0000 thru 0x43FF FFFF ??

Just to be clear, there's nothing MIPS generic about these addresses.
They are Au1500 specific with a doze of arbitrary chose on my part. The
addresses can be changed, carefully :)

>      I tried disabling the device, updating my BARS, reenabling in the
> driver code (a loadable module).
>      I tried writing the BARS just prior to tickling in the
> linux/arch/mips/kernel/pci_auto.c code.
>      I tried writing the BARS as soon as my device/vendor id are detected
> also in the linux/arch/mips/kernel/pci_auto.c code.

OK, none of that will work the way you're doing it. Here's the problem:

The PCI space on the Au1500 SOC is addresses with 36bit physical
addresses. The PCI noncachable memory space available for PCI devices is
0x4 0000 0000 to 0x5 0000 0000.  But, you can't write those addresses in
a BAR and device drivers read the address and try to do an ioremap on
it.  What I did was this:

- set pci memory start address to 0x4 4000 0000 
- set pci memory end address to   0x4 43FF FFFF

These variables are in include/asm-mips/au1000.h. If you take a look at
arch/mips/au1000/common/pci_ops.c, you'll see that in the
pci_mem_resource structure these addresses are truncated to 32 bit:
- 0x4000 0000 and 0x43FF FFFF. These are the addresses that the pci auto
code sees and programs in the BARs. 

When a device driver reads the resource value, 0x4000 0000 for example,
and calls ioremap on that address, the "fixup_bigphys_addr()" function
will get called in __ioremap() in arch/mips/mm/ioremap.c. That function
will detect that 0x4000 0000 falls within the pci memory window, and
"fix it up" to the proper 36 bit physical address. In other words, it
will return 0x4 4000 0000 so that 0x 4 4000 0000 can be remapped instead
of 0x4000 0000 so you can access the pci memory window.  The actual
physical pci address the SOC will put on the bus will be 0x4000 0000 and
since that's what's programmed in the BAR, the device will respond to
it.

The way you're approaching the problem is bypassing the entire
"fixup_bigphys_addr()" (the function is in setup.c) mechanism and it has
no chance or working.

In theory I think you should be able to do what you need. Suppose you
bypassed pci_auto altogether, for example, and you hardcoded the BARs in
setup.c.  One of your bars will be 0xFF000000 the other 0x90000000 (are
both of these supposed to be pci memory addresses?). You need to fixup
those addresses so that when ioremap is called with such an address, the
32 bit address will be fixed up to a 36 bit address and it's that
address that will get remapped. For example, if a device driver calls
ioremap with 0x9000 0000, you have to detect that address in the
fixup_bigphys_addr() function, and return 0x4 9000 0000. Then when you
use the returned virtual address to access the memory window, the CPU
will understand this virtual address to translate to a PCI mem address
and in turn it will put 0x9000 0000 on the bus. That should give you
access to your device.

Pete



From baitisj@idealab.com Thu Jun 12 02:04:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 02:04:14 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:32210 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225255AbTFLBEM>;
	Thu, 12 Jun 2003 02:04:12 +0100
Received: (qmail 5600 invoked by uid 6180); 12 Jun 2003 01:04:06 -0000
Date: Wed, 11 Jun 2003 18:04:06 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: mtd utils version / source?
Message-ID: <20030611180406.J29389@luca.pas.lab>
Reply-To: baitisj@evolution.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2599
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

Hey all:

What version of the mtd utils is currently recommended for the linux_2_4
branch?

Do I get the utils from infradead.org?

I've been banging my head against infradead.org's CVS server to no avail.

Thanks !

-Jeff


From fpga_dsp@yahoo.com.au Thu Jun 12 03:15:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 03:15:29 +0100 (BST)
Received: from web41202.mail.yahoo.com ([IPv6:::ffff:66.218.93.35]:24508 "HELO
	web41202.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225260AbTFLCP0>; Thu, 12 Jun 2003 03:15:26 +0100
Message-ID: <20030612021517.42227.qmail@web41202.mail.yahoo.com>
Received: from [64.132.226.151] by web41202.mail.yahoo.com via HTTP; Thu, 12 Jun 2003 12:15:17 EST
Date: Thu, 12 Jun 2003 12:15:17 +1000 (EST)
From: =?iso-8859-1?q?fpga=20dsp?= <fpga_dsp@yahoo.com.au>
Subject: Re: FW: Db1500 PCI Auto Scan Question, bus master operation
To: Pete Popov <ppopov@mvista.com>,
	Tom Cernius <tcernius@correlant.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <1055373721.9976.690.camel@zeus.mvista.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <fpga_dsp@yahoo.com.au>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2600
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fpga_dsp@yahoo.com.au
Precedence: bulk
X-list: linux-mips


Hi,

I am using kernel 2.4.20-pre6 version on db1500 and
having problem with PCI card as bus master. Basicly,
the kernel can recognize the card and assign into
0x40000000 address region, irq is 1. Now that is
really strange, stty1 using irq 1 as well. Are they
the same or different. However ,the problem is that
after setup the device and trigger it, it should go
and fetch the descriptor and will fetch the content
pointed by that descriptor afterward but it only fetch
the descriptor and quiet. I am even try to trigger it
again by write into it register mapped on PCI memory
region but after the first trigger, the second trigger
doesn't appear on pci bus analyzer at all. 

Another issues, it when I look at au1000_eth.c device
driver , dma_alloc() function allocate a DMAable
buffer in KSEG0 region but pci_alloc_consistent return
in KSEG1 region. So which one is right?

Many thanks

 --- Pete Popov <ppopov@mvista.com> wrote: > On Wed,
2003-06-11 at 15:12, Tom Cernius wrote:
> > Hello,
> > 
> >    I am porting my first PCI driver for a PCI card
> hosted by the AMD Db1500
> > "Zinfandel" development board.
> >    This driver had been previously working on
> another host, where
> > CONFIG_PCI_AUTO was not enabled.
> > 
> >     My PCI card REQUIRES 0xFF000000 and 0x90000000
> be programmed into BAR0
> > and BAR1 respectively.
> >     My PCI card has nothing programmed into BAR0
> and BAR1 at power-up.
> >     My host Linux kernel was built with
> CONFIG_PCI, CONFIG_NEW_PCI, and
> > CONFIG_PCI_AUTO turned on in the .config file.
> 
> Why the 0xFF000000 and, in general, the hardcoded
> addresses?
> 
> Which kernel are you using?
> 
> >      I noticed that during boot, the kernel
> tickles my devices BAR's and
> > then writes these BARs with addresses in the range
> of
> >      4000 0000 thru 43FF FFFF
> 
> Right.
> 
> >      I have tried everything and although I am
> able to write the proper
> > (0xFF00 0000 and 0x9000 0000) addresses into the
> BAR's,
> >      I have been unable to successfully read
> anything from my PCI cards CPU
> > Register/Sdram space.
> 
> No, that's not going to work. I'll elaborate below.
> 
> >      I suspect that it is NOT possible to use
> hardcoded PCI BAR addresses
> > with the MIPS processor AND CONFIG_PCI_AUTO turned
> on,
> >      as the kernel expects (and configures the PCI
> BARS of) PCI devices to
> > reside in the address space 0x4000 0000 thru
> 0x43FF FFFF ??
> 
> Just to be clear, there's nothing MIPS generic about
> these addresses.
> They are Au1500 specific with a doze of arbitrary
> chose on my part. The
> addresses can be changed, carefully :)
> 
> >      I tried disabling the device, updating my
> BARS, reenabling in the
> > driver code (a loadable module).
> >      I tried writing the BARS just prior to
> tickling in the
> > linux/arch/mips/kernel/pci_auto.c code.
> >      I tried writing the BARS as soon as my
> device/vendor id are detected
> > also in the linux/arch/mips/kernel/pci_auto.c
> code.
> 
> OK, none of that will work the way you're doing it.
> Here's the problem:
> 
> The PCI space on the Au1500 SOC is addresses with
> 36bit physical
> addresses. The PCI noncachable memory space
> available for PCI devices is
> 0x4 0000 0000 to 0x5 0000 0000.  But, you can't
> write those addresses in
> a BAR and device drivers read the address and try to
> do an ioremap on
> it.  What I did was this:
> 
> - set pci memory start address to 0x4 4000 0000 
> - set pci memory end address to   0x4 43FF FFFF
> 
> These variables are in include/asm-mips/au1000.h. If
> you take a look at
> arch/mips/au1000/common/pci_ops.c, you'll see that
> in the
> pci_mem_resource structure these addresses are
> truncated to 32 bit:
> - 0x4000 0000 and 0x43FF FFFF. These are the
> addresses that the pci auto
> code sees and programs in the BARs. 
> 
> When a device driver reads the resource value,
> 0x4000 0000 for example,
> and calls ioremap on that address, the
> "fixup_bigphys_addr()" function
> will get called in __ioremap() in
> arch/mips/mm/ioremap.c. That function
> will detect that 0x4000 0000 falls within the pci
> memory window, and
> "fix it up" to the proper 36 bit physical address.
> In other words, it
> will return 0x4 4000 0000 so that 0x 4 4000 0000 can
> be remapped instead
> of 0x4000 0000 so you can access the pci memory
> window.  The actual
> physical pci address the SOC will put on the bus
> will be 0x4000 0000 and
> since that's what's programmed in the BAR, the
> device will respond to
> it.
> 
> The way you're approaching the problem is bypassing
> the entire
> "fixup_bigphys_addr()" (the function is in setup.c)
> mechanism and it has
> no chance or working.
> 
> In theory I think you should be able to do what you
> need. Suppose you
> bypassed pci_auto altogether, for example, and you
> hardcoded the BARs in
> setup.c.  One of your bars will be 0xFF000000 the
> other 0x90000000 (are
> both of these supposed to be pci memory addresses?).
> You need to fixup
> those addresses so that when ioremap is called with
> such an address, the
> 32 bit address will be fixed up to a 36 bit address
> and it's that
> address that will get remapped. For example, if a
> device driver calls
> ioremap with 0x9000 0000, you have to detect that
> address in the
> fixup_bigphys_addr() function, and return 0x4 9000
> 0000. Then when you
> use the returned virtual address to access the
> memory window, the CPU
> will understand this virtual address to translate to
> a PCI mem address
> and in turn it will put 0x9000 0000 on the bus. That
> should give you
> access to your device.
> 
> Pete
> 
> 
>  

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

From fpga_dsp@yahoo.com.au Thu Jun 12 05:22:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 05:22:24 +0100 (BST)
Received: from web41210.mail.yahoo.com ([IPv6:::ffff:66.218.93.43]:58458 "HELO
	web41210.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225072AbTFLEWV>; Thu, 12 Jun 2003 05:22:21 +0100
Message-ID: <20030612042213.23032.qmail@web41210.mail.yahoo.com>
Received: from [64.132.226.151] by web41210.mail.yahoo.com via HTTP; Thu, 12 Jun 2003 14:22:13 EST
Date: Thu, 12 Jun 2003 14:22:13 +1000 (EST)
From: =?iso-8859-1?q?fpga=20dsp?= <fpga_dsp@yahoo.com.au>
Subject: Re: FW: Db1500 PCI Auto Scan Question, bus master operation
To: fpga dsp <fpga_dsp@yahoo.com.au>, Pete Popov <ppopov@mvista.com>,
	Tom Cernius <tcernius@correlant.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030612021517.42227.qmail@web41202.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <fpga_dsp@yahoo.com.au>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2601
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fpga_dsp@yahoo.com.au
Precedence: bulk
X-list: linux-mips


Hi again,

I think I found the problem, it is the virt_to_bus()
function mapping virtual memory to DMA address and it
return 0x2xxxxxxx, and it could be the reason the PCI
bus master refuse to read those address. Is there
another replacement function call for virt_to_bus()
since I don't want to use pci_alloc_consistent()

Many thanks

 --- fpga dsp <fpga_dsp@yahoo.com.au> wrote: > 
> Hi,
> 
> I am using kernel 2.4.20-pre6 version on db1500 and
> having problem with PCI card as bus master. Basicly,
> the kernel can recognize the card and assign into
> 0x40000000 address region, irq is 1. Now that is
> really strange, stty1 using irq 1 as well. Are they
> the same or different. However ,the problem is that
> after setup the device and trigger it, it should go
> and fetch the descriptor and will fetch the content
> pointed by that descriptor afterward but it only
> fetch
> the descriptor and quiet. I am even try to trigger
> it
> again by write into it register mapped on PCI memory
> region but after the first trigger, the second
> trigger
> doesn't appear on pci bus analyzer at all. 
> 
> Another issues, it when I look at au1000_eth.c
> device
> driver , dma_alloc() function allocate a DMAable
> buffer in KSEG0 region but pci_alloc_consistent
> return
> in KSEG1 region. So which one is right?
> 
> Many thanks
> 
>  --- Pete Popov <ppopov@mvista.com> wrote: > On Wed,
> 2003-06-11 at 15:12, Tom Cernius wrote:
> > > Hello,
> > > 
> > >    I am porting my first PCI driver for a PCI
> card
> > hosted by the AMD Db1500
> > > "Zinfandel" development board.
> > >    This driver had been previously working on
> > another host, where
> > > CONFIG_PCI_AUTO was not enabled.
> > > 
> > >     My PCI card REQUIRES 0xFF000000 and
> 0x90000000
> > be programmed into BAR0
> > > and BAR1 respectively.
> > >     My PCI card has nothing programmed into BAR0
> > and BAR1 at power-up.
> > >     My host Linux kernel was built with
> > CONFIG_PCI, CONFIG_NEW_PCI, and
> > > CONFIG_PCI_AUTO turned on in the .config file.
> > 
> > Why the 0xFF000000 and, in general, the hardcoded
> > addresses?
> > 
> > Which kernel are you using?
> > 
> > >      I noticed that during boot, the kernel
> > tickles my devices BAR's and
> > > then writes these BARs with addresses in the
> range
> > of
> > >      4000 0000 thru 43FF FFFF
> > 
> > Right.
> > 
> > >      I have tried everything and although I am
> > able to write the proper
> > > (0xFF00 0000 and 0x9000 0000) addresses into the
> > BAR's,
> > >      I have been unable to successfully read
> > anything from my PCI cards CPU
> > > Register/Sdram space.
> > 
> > No, that's not going to work. I'll elaborate
> below.
> > 
> > >      I suspect that it is NOT possible to use
> > hardcoded PCI BAR addresses
> > > with the MIPS processor AND CONFIG_PCI_AUTO
> turned
> > on,
> > >      as the kernel expects (and configures the
> PCI
> > BARS of) PCI devices to
> > > reside in the address space 0x4000 0000 thru
> > 0x43FF FFFF ??
> > 
> > Just to be clear, there's nothing MIPS generic
> about
> > these addresses.
> > They are Au1500 specific with a doze of arbitrary
> > chose on my part. The
> > addresses can be changed, carefully :)
> > 
> > >      I tried disabling the device, updating my
> > BARS, reenabling in the
> > > driver code (a loadable module).
> > >      I tried writing the BARS just prior to
> > tickling in the
> > > linux/arch/mips/kernel/pci_auto.c code.
> > >      I tried writing the BARS as soon as my
> > device/vendor id are detected
> > > also in the linux/arch/mips/kernel/pci_auto.c
> > code.
> > 
> > OK, none of that will work the way you're doing
> it.
> > Here's the problem:
> > 
> > The PCI space on the Au1500 SOC is addresses with
> > 36bit physical
> > addresses. The PCI noncachable memory space
> > available for PCI devices is
> > 0x4 0000 0000 to 0x5 0000 0000.  But, you can't
> > write those addresses in
> > a BAR and device drivers read the address and try
> to
> > do an ioremap on
> > it.  What I did was this:
> > 
> > - set pci memory start address to 0x4 4000 0000 
> > - set pci memory end address to   0x4 43FF FFFF
> > 
> > These variables are in include/asm-mips/au1000.h.
> If
> > you take a look at
> > arch/mips/au1000/common/pci_ops.c, you'll see that
> > in the
> > pci_mem_resource structure these addresses are
> > truncated to 32 bit:
> > - 0x4000 0000 and 0x43FF FFFF. These are the
> > addresses that the pci auto
> > code sees and programs in the BARs. 
> > 
> > When a device driver reads the resource value,
> > 0x4000 0000 for example,
> > and calls ioremap on that address, the
> > "fixup_bigphys_addr()" function
> > will get called in __ioremap() in
> > arch/mips/mm/ioremap.c. That function
> > will detect that 0x4000 0000 falls within the pci
> > memory window, and
> > "fix it up" to the proper 36 bit physical address.
> > In other words, it
> > will return 0x4 4000 0000 so that 0x 4 4000 0000
> can
> > be remapped instead
> > of 0x4000 0000 so you can access the pci memory
> > window.  The actual
> > physical pci address the SOC will put on the bus
> > will be 0x4000 0000 and
> > since that's what's programmed in the BAR, the
> > device will respond to
> > it.
> > 
> > The way you're approaching the problem is
> bypassing
> > the entire
> > "fixup_bigphys_addr()" (the function is in
> setup.c)
> > mechanism and it has
> > no chance or working.
> > 
> > In theory I think you should be able to do what
> you
> > need. Suppose you
> > bypassed pci_auto altogether, for example, and you
> > hardcoded the BARs in
> > setup.c.  One of your bars will be 0xFF000000 the
> > other 0x90000000 (are
> > both of these supposed to be pci memory
> addresses?).
> > You need to fixup
> > those addresses so that when ioremap is called
> with
> > such an address, the
> > 32 bit address will be fixed up to a 36 bit
> address
> > and it's that
> > address that will get remapped. For example, if a
> > device driver calls
> > ioremap with 0x9000 0000, you have to detect that
> > address in the
> > fixup_bigphys_addr() function, and return 0x4 9000
> > 0000. Then when you
> > use the returned virtual address to access the
> > memory window, the CPU
> > will understand this virtual address to translate
> to
> > a PCI mem address
> > and in turn it will put 0x9000 0000 on the bus.
> That
> > should give you
> > access to your device.
> > 
> > Pete
> > 
> > 
> >  
> 
> http://mobile.yahoo.com.au - Yahoo! Mobile
> 
=== message truncated === 

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

From mips081@vtnet.ca Thu Jun 12 11:59:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 11:59:33 +0100 (BST)
Received: from H42.C233.tor.velocet.net ([IPv6:::ffff:216.138.233.42]:55459
	"EHLO copper.vtnet.vjbtlw") by linux-mips.org with ESMTP
	id <S8225240AbTFLK7b>; Thu, 12 Jun 2003 11:59:31 +0100
Received: from silicon.vtint.vjbtlw (silicon.vtint.vjbtlw [192.168.141.14])
	by copper.vtnet.vjbtlw (Postfix) with ESMTP id A419939AFE
	for <linux-mips@linux-mips.org>; Thu, 12 Jun 2003 06:59:26 -0400 (EDT)
Content-Type: text/plain;
  charset="us-ascii"
From: Trevor Woerner <mips081@vtnet.ca>
Reply-To: mips081@vtnet.ca
To: linux-mips@linux-mips.org
Subject: 64-bit sysinfo
Date: Thu, 12 Jun 2003 06:59:26 -0400
User-Agent: KMail/1.4.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200306120659.26501.mips081@vtnet.ca>
Return-Path: <mips081@vtnet.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: 2602
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mips081@vtnet.ca
Precedence: bulk
X-list: linux-mips

Hi everyone,

(good to see some familiar and friendly faces from the PPC list! :-)

I ran into a problem yesterday and I just don't know how I'm going to 
approach solving it.

I compiled a 64-bit MIPS kernel, then built a busybox-based ramdisk. At 
first I couldn't get busybox's 'init' to work but later solved it by 
disabling the 'check_memory()' call.

Further investigation into why the 'check_memory()' call was failing 
revealed a problem with the 'sysinfo()' system call. The kernel is 
64-bit, therefore when it fills in the 'struct sysinfo' (as it does 
when 'sys_meminfo()' is called) unsigned int's are 64 bits. But back in 
userspace, the 'struct sysinfo' that gets allocated thinks that 
unsigned int's are 32 bits.

This causes a crash if the 'struct sysinfo' is allocated on the stack 
back in userspace, and causes seg faults if it's allocated in the .data 
section (globally).

I'm crossing my fingers and hoping that my solution is to build all 
user-space apps with some switch that will set the sizes of data types 
to be the same between user space and kernel space. Does some such 
option exist?

	Trevor

From macro@ds2.pg.gda.pl Thu Jun 12 12:06:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 12:06:22 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:411 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225240AbTFLLGU>; Thu, 12 Jun 2003 12:06:20 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA26307;
	Thu, 12 Jun 2003 13:06:52 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 12 Jun 2003 13:06:51 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: Martin Leopold <mleopold@tiscali.dk>, linux-mips@linux-mips.org
Subject: Re: Linux on Indigo2 (IP28) - R10000
In-Reply-To: <20030611204117.GO29687@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030612130044.25948C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2603
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 11 Jun 2003, Thiemo Seufer wrote:

> > > > I looked arround your website and saw
> > > > "mips64-linux-ip28-2002-06-28.tar.gz"
> > > > whoo.. Sounds exiting =]
> > > I know it's somewhat outdated. :-)
> > 
> > Hehe.. I tried it, and it booted. Whopee.. However the kernel-level-IP 
> > configuration (BOOTP) fails!? I'm not really sure why - the DHCP server 
> > just gave the IP and kernel-image a moment ago. This make me wonder: 
> > how far could I get with this kernel? Is it possible that I could 
> > actually boot an entire system with this kernel, or is that pushing it 
> > a bit?
> 
> It happens to work by accident, because the cachelines destoyed
> due to the speculative stores don't hit anything important. The
> 2.5 kernel fails much earlier.

 I recall fixing an IP checksum calculation bug in the 64-bit kernel last
year -- this may possibly be another reason of BOOTP failing (well, it
used to fail for me because of this problem back then).

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


From tor@spacetec.no Thu Jun 12 12:19:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 12:19:41 +0100 (BST)
Received: from firewall.spacetec.no ([IPv6:::ffff:192.51.5.5]:16163 "EHLO
	spacetec.no") by linux-mips.org with ESMTP id <S8225240AbTFLLTj>;
	Thu, 12 Jun 2003 12:19:39 +0100
Message-Id: <200306121119.h5CBJWqC027855@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Thu, 12 Jun 2003 13:19:29 +0200
In-Reply-To: Trevor Woerner <mips081@vtnet.ca>
       "64-bit sysinfo" (Jun 12, 12:05)
To: mips081@vtnet.ca, linux-mips@linux-mips.org
Subject: Re: 64-bit sysinfo
Return-Path: <tor@spacetec.no>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2604
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tor@spacetec.no
Precedence: bulk
X-list: linux-mips

On Jun 12, 12:05, Trevor Woerner wrote:
[...]
>I compiled a 64-bit MIPS kernel, then built a busybox-based ramdisk. At 
>first I couldn't get busybox's 'init' to work but later solved it by 
>disabling the 'check_memory()' call.
>
>Further investigation into why the 'check_memory()' call was failing 
>revealed a problem with the 'sysinfo()' system call. The kernel is 
>64-bit, therefore when it fills in the 'struct sysinfo' (as it does 
>when 'sys_meminfo()' is called) unsigned int's are 64 bits. But back in 
>userspace, the 'struct sysinfo' that gets allocated thinks that 
>unsigned int's are 32 bits.
[...]

Hm, that sounds wrong to me. 'int' is supposed to be 32 bits also on
64-bit systems, only 'long' should be 64 bits.

-Tor

From clausen@gnu.org Thu Jun 12 12:33:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 12:33:22 +0100 (BST)
Received: from mail011.syd.optusnet.com.au ([IPv6:::ffff:210.49.20.139]:53127
	"EHLO mail011.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8225240AbTFLLdU>; Thu, 12 Jun 2003 12:33:20 +0100
Received: from localhost.karma (c17997.eburwd3.vic.optusnet.com.au [210.49.198.98])
	by mail011.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id h5CBXBX13016;
	Thu, 12 Jun 2003 21:33:12 +1000
Received: from satisfactory (satisfactory [192.168.0.1])
	by localhost.karma (Postfix) with ESMTP
	id D3B4C1C; Thu, 12 Jun 2003 21:33:09 +1000 (EST)
Received: by satisfactory (Postfix, from userid 500)
	id 1514247606; Thu, 12 Jun 2003 21:36:26 +0000 (UTC)
Date: Thu, 12 Jun 2003 21:36:25 +0000
From: Andrew Clausen <clausen@gnu.org>
To: Trevor Woerner <mips081@vtnet.ca>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: 64-bit sysinfo
Message-ID: <20030612213625.GF480@gnu.org>
References: <200306120659.26501.mips081@vtnet.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200306120659.26501.mips081@vtnet.ca>
X-Accept-Language: en,pt
User-Agent: Mutt/1.5.4i
Return-Path: <clausen@gnu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2605
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: clausen@gnu.org
Precedence: bulk
X-list: linux-mips

On Thu, Jun 12, 2003 at 06:59:26AM -0400, Trevor Woerner wrote:
> I'm crossing my fingers and hoping that my solution is to build all 
> user-space apps with some switch that will set the sizes of data types 
> to be the same between user space and kernel space. Does some such 
> option exist?

No, the kernel should provide 32 bit values.  This is a bug.

I *thought* I sent a patch for this a while ago... I'm not sure now.

Cheers,
Andrew


From ralf@linux-mips.org Thu Jun 12 12:35:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 12:35:27 +0100 (BST)
Received: from p508B67B0.dip.t-dialin.net ([IPv6:::ffff:80.139.103.176]:32708
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225240AbTFLLfZ>; Thu, 12 Jun 2003 12:35:25 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5CBZMbY008644;
	Thu, 12 Jun 2003 04:35:23 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5CBZLv2008642;
	Thu, 12 Jun 2003 13:35:21 +0200
Date: Thu, 12 Jun 2003 13:35:20 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Trevor Woerner <mips081@vtnet.ca>
Cc: linux-mips@linux-mips.org
Subject: Re: 64-bit sysinfo
Message-ID: <20030612113520.GA8390@linux-mips.org>
References: <200306120659.26501.mips081@vtnet.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200306120659.26501.mips081@vtnet.ca>
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: 2606
X-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, Jun 12, 2003 at 06:59:26AM -0400, Trevor Woerner wrote:

> (good to see some familiar and friendly faces from the PPC list! :-)
> 
> I ran into a problem yesterday and I just don't know how I'm going to 
> approach solving it.
> 
> I compiled a 64-bit MIPS kernel, then built a busybox-based ramdisk. At 
> first I couldn't get busybox's 'init' to work but later solved it by 
> disabling the 'check_memory()' call.
> 
> Further investigation into why the 'check_memory()' call was failing 
> revealed a problem with the 'sysinfo()' system call. The kernel is 
> 64-bit, therefore when it fills in the 'struct sysinfo' (as it does 
> when 'sys_meminfo()' is called) unsigned int's are 64 bits. But back in 
> userspace, the 'struct sysinfo' that gets allocated thinks that 
> unsigned int's are 32 bits.
> 
> This causes a crash if the 'struct sysinfo' is allocated on the stack 
> back in userspace, and causes seg faults if it's allocated in the .data 
> section (globally).
> 
> I'm crossing my fingers and hoping that my solution is to build all 
> user-space apps with some switch that will set the sizes of data types 
> to be the same between user space and kernel space. Does some such 
> option exist?

Userspace really shouldn't need to know what kind of kernel it's running
on ...

The kernel has a wrapper for 32-bit code (see sys32_sysinfo) and that one
seems to look correct to me.

Can you check that your program is actually using the right syscall,
that is syscall number 4116?  If it's using 5097 it's using the native
64-bit syscall which obviously would explain your observation.

Any piece of usercode that's directly using <asm/unistd.h> is likely
to do something like this.  In short, using <asm/unistd.h> from userspace
is a really bad idea ...

  Ralf

From ralf@linux-mips.org Thu Jun 12 12:45:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 12:45:10 +0100 (BST)
Received: from p508B67B0.dip.t-dialin.net ([IPv6:::ffff:80.139.103.176]:6853
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225240AbTFLLpI>; Thu, 12 Jun 2003 12:45:08 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5CBj0bY008833;
	Thu, 12 Jun 2003 04:45:01 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5CBiv0v008832;
	Thu, 12 Jun 2003 13:44:57 +0200
Date: Thu, 12 Jun 2003 13:44:57 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Andrew Clausen <clausen@gnu.org>
Cc: Trevor Woerner <mips081@vtnet.ca>, linux-mips@linux-mips.org
Subject: Re: 64-bit sysinfo
Message-ID: <20030612114457.GB8390@linux-mips.org>
References: <200306120659.26501.mips081@vtnet.ca> <20030612213625.GF480@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030612213625.GF480@gnu.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: 2607
X-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, Jun 12, 2003 at 09:36:25PM +0000, Andrew Clausen wrote:

> On Thu, Jun 12, 2003 at 06:59:26AM -0400, Trevor Woerner wrote:
> > I'm crossing my fingers and hoping that my solution is to build all 
> > user-space apps with some switch that will set the sizes of data types 
> > to be the same between user space and kernel space. Does some such 
> > option exist?
> 
> No, the kernel should provide 32 bit values.  This is a bug.
> 
> I *thought* I sent a patch for this a while ago... I'm not sure now.

You sent it and I applied your patch on February 21.  Old mail appended
below again for Trevor's reference.  It doesn't explain why he sees
64-bit values though.  Trevor, what kernel exactly are you running?

  Ralf

Date:	Thu, 20 Feb 2003 11:26:55 +1100
From:	Andrew Clausen <clausen@melbourne.sgi.com>
To:	Linux-MIPS <linux-mips@linux-mips.org>
Cc:	ralf@linux-mips.org, linux-ia64@linuxia64.org
Subject: [patch] sys32_sysinfo broken on mips64 and ia64
Message-ID: <20030220002655.GE915@pureza.melbourne.sgi.com>

Hi all,

The sys32_sysinfo() calls are currently using an old version of
"struct sysinfo32", in both the mips64 and ia64 ports.

busybox's init can't cope with the bogus output on my Origin 200,
so this bug prevents the Debian installer from bootstrapping.

This is the mips64 version of the patch.  A very similar patch
could be constructed for ia64... it's very obvious what to do,
so I'll leave it to you ia64 people :)

Cheers,
Andrew


diff -u -r1.42.2.23 linux32.c
--- arch/mips64/kernel/linux32.c	23 Jan 2003 02:12:59 -0000	1.42.2.23
+++ arch/mips64/kernel/linux32.c	20 Feb 2003 00:05:41 -0000
@@ -672,8 +672,11 @@
         u32 bufferram;
         u32 totalswap;
         u32 freeswap;
-        unsigned short procs;
-        char _f[22];
+        u16 procs;
+	u32 totalhigh;
+	u32 freehigh;
+	u32 mem_unit;
+	char _f[8];
 };
 
 extern asmlinkage int sys_sysinfo(struct sysinfo *info);
@@ -698,6 +701,9 @@
 	err |= __put_user (s.totalswap, &info->totalswap);
 	err |= __put_user (s.freeswap, &info->freeswap);
 	err |= __put_user (s.procs, &info->procs);
+	err |= __put_user (s.totalhigh, &info->totalhigh);
+	err |= __put_user (s.freehigh, &info->freehigh);
+	err |= __put_user (s.mem_unit, &info->mem_unit);
 	if (err)
 		return -EFAULT;
 	return ret;



From mips081@vtnet.ca Thu Jun 12 13:02:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 13:03:02 +0100 (BST)
Received: from H42.C233.tor.velocet.net ([IPv6:::ffff:216.138.233.42]:59043
	"EHLO copper.vtnet.vjbtlw") by linux-mips.org with ESMTP
	id <S8225240AbTFLMC7>; Thu, 12 Jun 2003 13:02:59 +0100
Received: from silicon.vtint.vjbtlw (silicon.vtint.vjbtlw [192.168.141.14])
	by copper.vtnet.vjbtlw (Postfix) with ESMTP
	id ED8E139AFE; Thu, 12 Jun 2003 08:02:57 -0400 (EDT)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Trevor Woerner <mips081@vtnet.ca>
Reply-To: mips081@vtnet.ca
To: Ralf Baechle <ralf@linux-mips.org>,
	Andrew Clausen <clausen@gnu.org>
Subject: Re: 64-bit sysinfo
Date: Thu, 12 Jun 2003 08:02:57 -0400
User-Agent: KMail/1.4.3
Cc: linux-mips@linux-mips.org
References: <200306120659.26501.mips081@vtnet.ca> <20030612213625.GF480@gnu.org> <20030612114457.GB8390@linux-mips.org>
In-Reply-To: <20030612114457.GB8390@linux-mips.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200306120802.57703.mips081@vtnet.ca>
Return-Path: <mips081@vtnet.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: 2608
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mips081@vtnet.ca
Precedence: bulk
X-list: linux-mips

On June 12, 2003 07:44 am, Ralf Baechle wrote:
> Trevor, what kernel exactly are you
> running?

I'm running Broadcom's SWARM board (sb1, 1250), so I'm running the most 
recent Broadcom kernel that comes with it (2.4.20-rc6 with patches).

From mips081@vtnet.ca Thu Jun 12 13:04:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 13:04:51 +0100 (BST)
Received: from H42.C233.tor.velocet.net ([IPv6:::ffff:216.138.233.42]:59555
	"EHLO copper.vtnet.vjbtlw") by linux-mips.org with ESMTP
	id <S8225240AbTFLMEt>; Thu, 12 Jun 2003 13:04:49 +0100
Received: from silicon.vtint.vjbtlw (silicon.vtint.vjbtlw [192.168.141.14])
	by copper.vtnet.vjbtlw (Postfix) with ESMTP
	id 0B31A39AFE; Thu, 12 Jun 2003 08:04:48 -0400 (EDT)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Trevor Woerner <mips081@vtnet.ca>
Reply-To: mips081@vtnet.ca
To: tor@spacetec.no (Tor Arntsen), linux-mips@linux-mips.org
Subject: Re: 64-bit sysinfo
Date: Thu, 12 Jun 2003 08:04:47 -0400
User-Agent: KMail/1.4.3
References: <200306121119.h5CBJWqC027855@pallas.spacetec.no>
In-Reply-To: <200306121119.h5CBJWqC027855@pallas.spacetec.no>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200306120804.47827.mips081@vtnet.ca>
Return-Path: <mips081@vtnet.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: 2609
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mips081@vtnet.ca
Precedence: bulk
X-list: linux-mips

On June 12, 2003 07:19 am, Tor Arntsen wrote:
> Hm, that sounds wrong to me. 'int' is supposed to be 32 bits also on
> 64-bit systems, only 'long' should be 64 bits.

Right, sorry. That was suppsed to read long. In any case, I put 'printk' 
where the calls are being made as printed out the sizeof() of the 
values and discovered that in user space they're 32 bits and in the 
kernel they're 64 bits.

	Trevor

From mips081@vtnet.ca Thu Jun 12 13:08:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 13:08:04 +0100 (BST)
Received: from H42.C233.tor.velocet.net ([IPv6:::ffff:216.138.233.42]:59811
	"EHLO copper.vtnet.vjbtlw") by linux-mips.org with ESMTP
	id <S8225240AbTFLMIC>; Thu, 12 Jun 2003 13:08:02 +0100
Received: from silicon.vtint.vjbtlw (silicon.vtint.vjbtlw [192.168.141.14])
	by copper.vtnet.vjbtlw (Postfix) with ESMTP
	id 895D639AFE; Thu, 12 Jun 2003 08:07:59 -0400 (EDT)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Trevor Woerner <mips081@vtnet.ca>
Reply-To: mips081@vtnet.ca
To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: 64-bit sysinfo
Date: Thu, 12 Jun 2003 08:07:59 -0400
User-Agent: KMail/1.4.3
Cc: linux-mips@linux-mips.org
References: <200306120659.26501.mips081@vtnet.ca> <20030612113520.GA8390@linux-mips.org>
In-Reply-To: <20030612113520.GA8390@linux-mips.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200306120807.59346.mips081@vtnet.ca>
Return-Path: <mips081@vtnet.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: 2610
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mips081@vtnet.ca
Precedence: bulk
X-list: linux-mips

On June 12, 2003 07:35 am, Ralf Baechle wrote:
> The kernel has a wrapper for 32-bit code (see sys32_sysinfo) and that
> one seems to look correct to me.
>
> Can you check that your program is actually using the right syscall,
> that is syscall number 4116?  If it's using 5097 it's using the
> native 64-bit syscall which obviously would explain your observation.

Thanks for your (and everyone's suggestions) I'll have a look at this 
today. I put a printk in kernel/proc.c:sys_sysinfo() so that's the one 
being called. I also put another printk in 
arch/mips64/mm/init.c:si_meminfo() (??? i think...) and it was being 
called from 'sys_info()'. I don't remember seeing sys32_sysinfo() but 
I'll look again.

	Trevor

From ralf@linux-mips.org Thu Jun 12 13:27:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 13:27:53 +0100 (BST)
Received: from p508B67B0.dip.t-dialin.net ([IPv6:::ffff:80.139.103.176]:47047
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225272AbTFLM1v>; Thu, 12 Jun 2003 13:27:51 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5CCRobY011317;
	Thu, 12 Jun 2003 05:27:50 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5CCRo76011316;
	Thu, 12 Jun 2003 14:27:50 +0200
Date: Thu, 12 Jun 2003 14:27:50 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Trevor Woerner <mips081@vtnet.ca>
Cc: linux-mips@linux-mips.org
Subject: Re: 64-bit sysinfo
Message-ID: <20030612122750.GB14965@linux-mips.org>
References: <200306120659.26501.mips081@vtnet.ca> <20030612113520.GA8390@linux-mips.org> <200306120807.59346.mips081@vtnet.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200306120807.59346.mips081@vtnet.ca>
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: 2611
X-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, Jun 12, 2003 at 08:07:59AM -0400, Trevor Woerner wrote:

> Thanks for your (and everyone's suggestions) I'll have a look at this 
> today. I put a printk in kernel/proc.c:sys_sysinfo() so that's the one 
> being called. I also put another printk in 
> arch/mips64/mm/init.c:si_meminfo() (??? i think...) and it was being 
> called from 'sys_info()'. I don't remember seeing sys32_sysinfo() but 
> I'll look again.

sys32_sysinfo calls sys_sysinfo.  So if you see a direct call to
sys_sysinfo this might proof something is using the wrong syscall.
Strace is your friend ...  Oh, and verify that your kernel has Andrew's
patch from my previous mail applied.

  Ralf

From erik@greendragon.org Thu Jun 12 14:56:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 14:56:23 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:46060 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225240AbTFLN4U>;
	Thu, 12 Jun 2003 14:56:20 +0100
Received: from mahes.visi.com (mahes.visi.com [209.98.98.96])
	by mail-out.visi.com (Postfix) with ESMTP
	id C64DA36CD; Thu, 12 Jun 2003 08:56:28 -0500 (CDT)
Received: from mahes.visi.com (localhost [127.0.0.1])
	by mahes.visi.com (8.12.9/8.12.5) with ESMTP id h5CDuGKe041389;
	Thu, 12 Jun 2003 08:56:16 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mahes.visi.com (8.12.9/8.12.5/Submit) id h5CDuA2t041388;
	Thu, 12 Jun 2003 13:56:10 GMT
X-Authentication-Warning: mahes.visi.com: www set sender to erik@greendragon.org using -f
Received: from stpns.guidant.com (stpns.guidant.com [132.189.76.10]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Thu, 12 Jun 2003 13:56:10 +0000
Message-ID: <1055426170.3ee8867abc934@my.visi.com>
Date: Thu, 12 Jun 2003 13:56:10 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: Martin Leopold <mleopold@tiscali.dk>
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	Keith M Wesolowski <wesolows@foobazco.org>
Subject: Re: Linux on Octane IP30 (was Re: Linux on Indigo2 (IP28) - R10000)
References: <20030611222146.GE5140@asterix.cartoonnet>
In-Reply-To: <20030611222146.GE5140@asterix.cartoonnet>
MIME-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP: 132.189.76.10
Return-Path: <erik@greendragon.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2612
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting Martin Leopold <mleopold@tiscali.dk>:

> He has some utils and some info on getting it running, what is your
> take? Will this get my anywhere near having a running Linux on my
> Ocane? Or do I have to start kernel-hacking before that will happen =]?
> 
> --
> Regards Martin Leopold.
> Dept. of Computer Science, University of Copenhagen

You have to hack at least minimally.  The Origin and Octane are quite similar in
a lot of ways, but they're not close enough to just boot the Origin code.

Erik



-- 
Erik J. Green
erik@greendragon.org

From ralf@linux-mips.org Thu Jun 12 16:34:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 16:34:44 +0100 (BST)
Received: from p508B67B0.dip.t-dialin.net ([IPv6:::ffff:80.139.103.176]:2515
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225276AbTFLPem>; Thu, 12 Jun 2003 16:34:42 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5CFYcbY004638
	for <linux-mips@linux-mips.org>; Thu, 12 Jun 2003 08:34:39 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5CFYc4k004627
	for linux-mips@linux-mips.org; Thu, 12 Jun 2003 17:34:38 +0200
Date: Thu, 12 Jun 2003 17:34:36 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: EV64120
Message-ID: <20030612153436.GA3293@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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: 2613
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

Does anybody still care about the EV64120?  The code is evil, can't be
feed to Linus as it is and I've not received any feedback in quite a
while.  If nobody wants to take care of it it's my top candidate for
removal from 2.5 and maybe from 2.4 also.

  Ralf

From ppopov@mvista.com Thu Jun 12 18:11:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 18:11:59 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:34545 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225275AbTFLRL5>;
	Thu, 12 Jun 2003 18:11:57 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA07950;
	Thu, 12 Jun 2003 10:11:51 -0700
Subject: Re: FW: Db1500 PCI Auto Scan Question, bus master operation
From: Pete Popov <ppopov@mvista.com>
To: fpga dsp <fpga_dsp@yahoo.com.au>
Cc: Tom Cernius <tcernius@correlant.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030612021517.42227.qmail@web41202.mail.yahoo.com>
References: <20030612021517.42227.qmail@web41202.mail.yahoo.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1055437921.9969.729.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 12 Jun 2003 10:12:01 -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: 2614
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, 2003-06-11 at 19:15, fpga dsp wrote:
> Hi,
> 
> I am using kernel 2.4.20-pre6 version on db1500 and
> having problem with PCI card as bus master. Basicly,
> the kernel can recognize the card and assign into
> 0x40000000 address region, irq is 1. Now that is
> really strange, stty1 using irq 1 as well. Are they
> the same or different. 

There's no UART1 on the Au1500 so you don't have to worry about that
interrupt, even though it's defined in the .h file for the Au1000.


> However ,the problem is that
> after setup the device and trigger it, it should go
> and fetch the descriptor and will fetch the content
> pointed by that descriptor afterward but it only fetch
> the descriptor and quiet. I am even try to trigger it
> again by write into it register mapped on PCI memory
> region but after the first trigger, the second trigger
> doesn't appear on pci bus analyzer at all. 

> Another issues, it when I look at au1000_eth.c device
> driver , dma_alloc() function allocate a DMAable
> buffer in KSEG0 region but pci_alloc_consistent return
> in KSEG1 region. So which one is right?

Right for what? KSEG0 works because the cache is coherent. But due to a
pci coherency bug, I think for a new device driver that's a pci bus
master you need to use kseg1 for now.

Pete


From henri@broadbandnetdevices.com Thu Jun 12 20:11:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 20:11:14 +0100 (BST)
Received: from tomts13.bellnexxia.net ([IPv6:::ffff:209.226.175.34]:12690 "EHLO
	tomts13-srv.bellnexxia.net") by linux-mips.org with ESMTP
	id <S8225274AbTFLTLL>; Thu, 12 Jun 2003 20:11:11 +0100
Received: from amdk62400 ([206.172.132.43]) by tomts13-srv.bellnexxia.net
          (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with SMTP
          id <20030612191059.YYUS1194.tomts13-srv.bellnexxia.net@amdk62400>
          for <linux-mips@linux-mips.org>; Thu, 12 Jun 2003 15:10:59 -0400
Message-ID: <000501c33116$3e90e2b0$0400a8c0@amdk62400>
Reply-To: "HG" <henri@broadbandnetdevices.com>
From: "HG" <henri@broadbandnetdevices.com>
To: <linux-mips@linux-mips.org>
Subject: ramdisk on mips question 
Date: Thu, 12 Jun 2003 15:10:08 -0400
Organization: BND
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Return-Path: <henri@broadbandnetdevices.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2615
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: henri@broadbandnetdevices.com
Precedence: bulk
X-list: linux-mips

Hi all,

while compiling a kernel for our board based on the idt 79rc332 , i am
getting the error below.
The target board is big endian. The files that where gziped where created
with a crossassembler that produces big endian files
the kernel is the 2.4.21-pre3. the ramdisk.gz file was created on a pc based
linux with some test files(big endian)
and copied in the location .../linux/arch/mips/ramdisk

1-    am i reading it right that the linker wont accept the ramdisk.gz
because it was created on a little endian system (the pc linux)
command to create the file : cat file1 file2 ... | gzip -c > ramdisk.gz

2-    anyone know a workaround for this problem(other than changing the
target ,and its monitor to little endian ) .



many thanks for all help

Henri



from make .....
 make[1]: Entering directory
`/home/henri/idt/linux_2p4p21/linux/arch/mips/ramdisk'
echo "O_FORMAT:  " elf32-bigmips
O_FORMAT:   elf32-bigmips
mips-linux-ld -T ld.script -b binary --oformat elf32-bigmips -o ramdisk.o
"ramdisk.gz"
mips-linux-ld: ramdisk.gz: compiled for a little endian system and target is
big endian
File in wrong format: failed to merge target specific data of file
ramdisk.gz
make[1]: *** [ramdisk.o] Error 1
make[1]: Leaving directory
`/home/henri/idt/linux_2p4p21/linux/arch/mips/ramdisk'
make: *** [_dir_arch/mips/ramdisk] Error 2



From ranjanp@efi.com Thu Jun 12 21:17:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 21:17:02 +0100 (BST)
Received: from mail3.efi.com ([IPv6:::ffff:192.68.228.90]:34061 "HELO
	fcexgw03.efi.internal") by linux-mips.org with SMTP
	id <S8225195AbTFLURA> convert rfc822-to-8bit; Thu, 12 Jun 2003 21:17:00 +0100
Received: from 10.3.12.12 by fcexgw03.efi.internal (InterScan E-Mail VirusWall NT); Thu, 12 Jun 2003 13:16:53 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: do_IRQ query
Date: Thu, 12 Jun 2003 13:16:51 -0700
Message-ID: <D9F6B9DABA4CAE4B92850252C52383AB07968330@ex-eng-corp.efi.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: do_IRQ query
Thread-Index: AcMxH49Edll4GTSjQ4mW6Nj3aEzQTQ==
From: "Ranjan Parthasarathy" <ranjanp@efi.com>
To: <linux-mips@linux-mips.org>
Return-Path: <ranjanp@efi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2616
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ranjanp@efi.com
Precedence: bulk
X-list: linux-mips

Is it safe to call do_IRQ directly inside interrupt handlers without doing a irq_enter. I have seen ksoftirqd_CPUX crashes when I call the do_IRQ routines directly instead of the following sequence.

irq_enter()
do_IRQ
irq_exit()

Some code use it while some do not. The timer code in arch/mips/kernel/time.c uses it in ll_timer_interrupt. Some ports call this function directly in their interrupt handlers.

Any information would be greatly appreciated.

Thank you

Ranjan

From jsun@mvista.com Thu Jun 12 22:12:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 22:12:46 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:8952 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225195AbTFLVMo>;
	Thu, 12 Jun 2003 22:12:44 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h5CLCfj07787;
	Thu, 12 Jun 2003 14:12:41 -0700
Date: Thu, 12 Jun 2003 14:12:41 -0700
From: Jun Sun <jsun@mvista.com>
To: Ranjan Parthasarathy <ranjanp@efi.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: do_IRQ query
Message-ID: <20030612141241.D7321@mvista.com>
References: <D9F6B9DABA4CAE4B92850252C52383AB07968330@ex-eng-corp.efi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <D9F6B9DABA4CAE4B92850252C52383AB07968330@ex-eng-corp.efi.com>; from ranjanp@efi.com on Thu, Jun 12, 2003 at 01:16:51PM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2617
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Jun 12, 2003 at 01:16:51PM -0700, Ranjan Parthasarathy wrote:
> Is it safe to call do_IRQ directly inside interrupt handlers without doing a irq_enter. I have seen ksoftirqd_CPUX crashes when I call the do_IRQ routines directly instead of the following sequence.
> 
> irq_enter()
> do_IRQ
> irq_exit()
>

This is not right.  irq_enter()/irq_exit() is already called in 
handle_IRQ_event(), which in turn is called by do_IRQ().  YOu 
don't need this yourself.  

The rest of do_IRQ() code is protected by closing interrupts.

Something must be wrong in your system.  If you show the crash message,
we might be able to tell more.

> Some code use it while some do not. The timer code in arch/mips/kernel/time.c uses it in ll_timer_interrupt. Some ports call this function directly in their interrupt handlers.

Those ll_timer_xxx functions are alternative routes (fast ones) to
do_IRQ(), and therefore it needs to protect itself by calling
irq_enter()/irq_exit().

Jun

From ranjanp@efi.com Thu Jun 12 23:15:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Jun 2003 23:15:16 +0100 (BST)
Received: from mail3.efi.com ([IPv6:::ffff:192.68.228.90]:60427 "HELO
	fcexgw03.efi.internal") by linux-mips.org with SMTP
	id <S8225281AbTFLWPO> convert rfc822-to-8bit; Thu, 12 Jun 2003 23:15:14 +0100
Received: from 10.3.12.12 by fcexgw03.efi.internal (InterScan E-Mail VirusWall NT); Thu, 12 Jun 2003 15:15:05 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: do_IRQ query
Date: Thu, 12 Jun 2003 15:15:04 -0700
Message-ID: <D9F6B9DABA4CAE4B92850252C52383AB07968331@ex-eng-corp.efi.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: do_IRQ query
Thread-Index: AcMxJ1yASl7Sbv40TMiDOcJxiE590QACCOnA
From: "Ranjan Parthasarathy" <ranjanp@efi.com>
To: "Jun Sun" <jsun@mvista.com>,
	"Ranjan Parthasarathy" <ranjanp@efi.com>
Cc: <linux-mips@linux-mips.org>
Return-Path: <ranjanp@efi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2618
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ranjanp@efi.com
Precedence: bulk
X-list: linux-mips

Thank you for the information. I do not have a crash log at this minute. I will send something when I see the crashes again.

Ranjan

-----Original Message-----
From: Jun Sun [mailto:jsun@mvista.com]
Sent: Thursday, June 12, 2003 2:13 PM
To: Ranjan Parthasarathy
Cc: linux-mips@linux-mips.org; jsun@mvista.com
Subject: Re: do_IRQ query


On Thu, Jun 12, 2003 at 01:16:51PM -0700, Ranjan Parthasarathy wrote:
> Is it safe to call do_IRQ directly inside interrupt handlers without doing a irq_enter. I have seen ksoftirqd_CPUX crashes when I call the do_IRQ routines directly instead of the following sequence.
> 
> irq_enter()
> do_IRQ
> irq_exit()
>

This is not right.  irq_enter()/irq_exit() is already called in 
handle_IRQ_event(), which in turn is called by do_IRQ().  YOu 
don't need this yourself.  

The rest of do_IRQ() code is protected by closing interrupts.

Something must be wrong in your system.  If you show the crash message,
we might be able to tell more.

> Some code use it while some do not. The timer code in arch/mips/kernel/time.c uses it in ll_timer_interrupt. Some ports call this function directly in their interrupt handlers.

Those ll_timer_xxx functions are alternative routes (fast ones) to
do_IRQ(), and therefore it needs to protect itself by calling
irq_enter()/irq_exit().

Jun

From Geert.Uytterhoeven@sonycom.com Fri Jun 13 11:15:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Jun 2003 11:15:09 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:16604 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225210AbTFMKPG>;
	Fri, 13 Jun 2003 11:15:06 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h5DAEtpI019303
	for <linux-mips@linux-mips.org>; Fri, 13 Jun 2003 12:14:57 +0200 (MEST)
Date: Fri, 13 Jun 2003 12:14:55 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Corruption in 2.4.x
In-Reply-To: <Pine.GSO.4.21.0306111738200.6450-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.4.21.0306131209200.11546-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2619
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Wed, 11 Jun 2003, Geert Uytterhoeven wrote:
> Recently we started seeing slight file corruption and random segmentation
> faults with the 2.4.x MIPS kernel from CVS. The problems appeared after
> upgrading from 2.4.20 (CVS 2003-01-13) to 2.4.21-pre4 (CVS 2003-05-06), which
> introduced the new cache/tlb optimizations.
> 
> Most prominent indication of the file corruption is the corruption of
> /etc/motd, of which the non-first lines are rewritten by the startup scripts on
> every boot up.

Just to keep you informed...

Apparently this problem was not caused by Linux, but by the hardware. A few
hours after I sent the previous mail, my IDE disk started showing unrecoverable
read errors on some blocks.  According to the e2fsck badblocks test, /etc/motd
was on a bad block. So most probably the disk started returning wrong data
about one month ago, without detecting there was a read error (lousy ECC and
bad block remapping?).

Now the bad blocks are no longer in active use, everything works fine! Sorry
for the noise.

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.Uytterhoeven@sonycom.com Fri Jun 13 15:19:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Jun 2003 15:19:58 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:52964 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225210AbTFMOTz>;
	Fri, 13 Jun 2003 15:19:55 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h5DEJkpI014325;
	Fri, 13 Jun 2003 16:19:46 +0200 (MEST)
Date: Fri, 13 Jun 2003 16:19:46 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20030613135835Z8225250-1272+2544@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0306131617210.13821-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2620
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Fri, 13 Jun 2003 ralf@linux-mips.org wrote:
> 	Consolidate all the MIPS PCI code in arch/mips/pci.

Is this really a good idea? You moved board-specific code (`everything related
to one board in a single dir') into one directory? So for a new port, you now
have to add a arch/mips/<board>/ directory, and add files to arch/mips/pci/.

I agree that extracting common parts and cleaning up the code is a good idea,
though.

Gr{oetje,eeting}s,

						Geert

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

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


From ralf@linux-mips.org Fri Jun 13 15:30:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Jun 2003 15:30:57 +0100 (BST)
Received: from p508B7C8B.dip.t-dialin.net ([IPv6:::ffff:80.139.124.139]:32693
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225210AbTFMOay>; Fri, 13 Jun 2003 15:30:54 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5DEUobY027588;
	Fri, 13 Jun 2003 07:30:50 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5DEUnPq027587;
	Fri, 13 Jun 2003 16:30:49 +0200
Date: Fri, 13 Jun 2003 16:30:49 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030613143049.GA27401@linux-mips.org>
References: <20030613135835Z8225250-1272+2544@linux-mips.org> <Pine.GSO.4.21.0306131617210.13821-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0306131617210.13821-100000@vervain.sonytel.be>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2621
X-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, Jun 13, 2003 at 04:19:46PM +0200, Geert Uytterhoeven wrote:

> Is this really a good idea? You moved board-specific code (`everything related
> to one board in a single dir') into one directory? So for a new port, you now
> have to add a arch/mips/<board>/ directory, and add files to arch/mips/pci/.
> 
> I agree that extracting common parts and cleaning up the code is a good idea,
> though.

It's just toooo much to do in one step, expect forther moving of code
to get everything to it's final place.  The amount of code that was
being duplicated was just insane and trying to sort boards by chipset
was part of the evil.  So MIPS's boards may come with one of several
PCI chipsets and the Lasat systems may have either a NEC Nile4 or a
Galileo 64120 chipset.  Result?  Each was duplicating the code to support
both chipsets into it's arch/mips/foo/ code.  Similar things with code
to support various firmware such as PMON etc.

Anyway, suggestions welcome,

  Ralf

From jsun@mvista.com Fri Jun 13 18:33:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Jun 2003 18:33:47 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:37358 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225262AbTFMRdn>;
	Fri, 13 Jun 2003 18:33:43 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h5DHXep10071;
	Fri, 13 Jun 2003 10:33:40 -0700
Date: Fri, 13 Jun 2003 10:33:40 -0700
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030613103340.D9837@mvista.com>
References: <20030613135835Z8225250-1272+2544@linux-mips.org> <Pine.GSO.4.21.0306131617210.13821-100000@vervain.sonytel.be> <20030613143049.GA27401@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030613143049.GA27401@linux-mips.org>; from ralf@linux-mips.org on Fri, Jun 13, 2003 at 04:30:49PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2622
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Jun 13, 2003 at 04:30:49PM +0200, Ralf Baechle wrote:
> On Fri, Jun 13, 2003 at 04:19:46PM +0200, Geert Uytterhoeven wrote:
> 
> > Is this really a good idea? You moved board-specific code (`everything related
> > to one board in a single dir') into one directory? So for a new port, you now
> > have to add a arch/mips/<board>/ directory, and add files to arch/mips/pci/.
> > 
> > I agree that extracting common parts and cleaning up the code is a good idea,
> > though.
> 
> It's just toooo much to do in one step, expect forther moving of code
> to get everything to it's final place.  The amount of code that was
> being duplicated was just insane and trying to sort boards by chipset
> was part of the evil.  So MIPS's boards may come with one of several
> PCI chipsets and the Lasat systems may have either a NEC Nile4 or a
> Galileo 64120 chipset.  Result?  Each was duplicating the code to support
> both chipsets into it's arch/mips/foo/ code.  Similar things with code
> to support various firmware such as PMON etc.
> 
> Anyway, suggestions welcome,
>

Ralf and I chatted a little before the change.  I think this _may_ be
a good thing.  It does not hurt to give it whirl first.

I was trying to promote chipset based grouping, like gt64120/ or ddb5xxx/, 
but apparently not everybody likes that.  People are still going with 
company or machine based grouping, which makes chipset code sharing impossible.

I also realize that chipset based grouping (and sharing) requires more
design and synchronization between developers, and thus probably harder
to do.  So in that sense, arch/mips/pci, as a less restrictive mechnism
for sharing, might work better.

So I like to view arch/mips/pci as some PCI library routines for 
chipsets instead of another place for board-specific code to live.

Jun


From Geert.Uytterhoeven@sonycom.com Fri Jun 13 19:56:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Jun 2003 19:57:01 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:61390 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225262AbTFMS47>;
	Fri, 13 Jun 2003 19:56:59 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h5DIunpI006151;
	Fri, 13 Jun 2003 20:56:49 +0200 (MEST)
Date: Fri, 13 Jun 2003 20:56:48 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030613103340.D9837@mvista.com>
Message-ID: <Pine.GSO.4.21.0306132052290.14094-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2623
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Fri, 13 Jun 2003, Jun Sun wrote:
> On Fri, Jun 13, 2003 at 04:30:49PM +0200, Ralf Baechle wrote:
> > On Fri, Jun 13, 2003 at 04:19:46PM +0200, Geert Uytterhoeven wrote:
> > > Is this really a good idea? You moved board-specific code (`everything related
> > > to one board in a single dir') into one directory? So for a new port, you now
> > > have to add a arch/mips/<board>/ directory, and add files to arch/mips/pci/.
> > > 
> > > I agree that extracting common parts and cleaning up the code is a good idea,
> > > though.
> > 
> > It's just toooo much to do in one step, expect forther moving of code
> > to get everything to it's final place.  The amount of code that was
> > being duplicated was just insane and trying to sort boards by chipset
> > was part of the evil.  So MIPS's boards may come with one of several
> > PCI chipsets and the Lasat systems may have either a NEC Nile4 or a
> > Galileo 64120 chipset.  Result?  Each was duplicating the code to support
> > both chipsets into it's arch/mips/foo/ code.  Similar things with code
> > to support various firmware such as PMON etc.
> > 
> > Anyway, suggestions welcome,
> 
> Ralf and I chatted a little before the change.  I think this _may_ be
> a good thing.  It does not hurt to give it whirl first.
> 
> I was trying to promote chipset based grouping, like gt64120/ or ddb5xxx/, 
> but apparently not everybody likes that.  People are still going with 
> company or machine based grouping, which makes chipset code sharing impossible.
> 
> I also realize that chipset based grouping (and sharing) requires more
> design and synchronization between developers, and thus probably harder
> to do.  So in that sense, arch/mips/pci, as a less restrictive mechnism
> for sharing, might work better.
> 
> So I like to view arch/mips/pci as some PCI library routines for 
> chipsets instead of another place for board-specific code to live.

That's fine!  I just didn't realize there was that much chipset sharing between
the different boards. E.g. for Vr41xx, all board code is already in subdirs
within the vr41xx directory.

So in the future we may see something like this:

  arch/mips/chipset1/...
           /chipset2/...
	   /...
	   /board1/...
	   /board2/...

where the board* directories contain the glue code for the specific boards?

Gr{oetje,eeting}s,

						Geert

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

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


From macro@ds2.pg.gda.pl Fri Jun 13 21:27:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Jun 2003 21:27:22 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:43421 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225287AbTFMU1U>; Fri, 13 Jun 2003 21:27:20 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA21706;
	Fri, 13 Jun 2003 22:28:04 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 13 Jun 2003 22:28:03 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Jun Sun <jsun@mvista.com>, Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <Pine.GSO.4.21.0306132052290.14094-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1030613221736.20506C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2624
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 13 Jun 2003, Geert Uytterhoeven wrote:

> So in the future we may see something like this:
> 
>   arch/mips/chipset1/...
>            /chipset2/...
> 	   /...
> 	   /board1/...
> 	   /board2/...
> 
> where the board* directories contain the glue code for the specific boards?

 It looks as a good idea, although possibly an intermediate directory
would be desireable not to clutter arch/mips too much.  E.g:

  arch/mips/platforms/platform1/...
                     /platform2/...
            ...
  arch/mips/chipset/chipset1/...
                   /chipset2/...

I assume by "chipset" you mean the lone system controller or host bridge. 

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


From dan@embeddededge.com Fri Jun 13 22:00:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Jun 2003 22:00:13 +0100 (BST)
Received: from 157-84-51-66.reonbroadband.com ([IPv6:::ffff:66.51.84.157]:38653
	"EHLO tibook.netx4.com") by linux-mips.org with ESMTP
	id <S8225262AbTFMVAL>; Fri, 13 Jun 2003 22:00:11 +0100
Received: from embeddededge.com (IDENT:dan@localhost.localdomain [127.0.0.1])
	by tibook.netx4.com (8.11.1/8.11.1) with ESMTP id h5DL0Ei00739;
	Fri, 13 Jun 2003 17:00:14 -0400
Message-ID: <3EEA3B5C.2000201@embeddededge.com>
Date: Fri, 13 Jun 2003 17:00:12 -0400
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC: Geert Uytterhoeven <geert@linux-m68k.org>,
	Jun Sun <jsun@mvista.com>, Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
References: <Pine.GSO.3.96.1030613221736.20506C-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dan@embeddededge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2625
X-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

Maciej W. Rozycki wrote:

>  It looks as a good idea, although possibly an intermediate directory
> would be desireable not to clutter arch/mips too much.  E.g:
> 
>   arch/mips/platforms/platform1/...
>                      /platform2/...

 From my experience with other architectures, fewer intermediate
directories are often useful, for example:

	arch/mips/platforms/board_and_chip_files

allows a maximum amount of code sharing and minimal duplication.
When you have lots of lower level directories, you often have
many identical files in them that should be shared, but are not,
causing support/update challenges.  For example:

	arch/mips/platforms/mfg_board_common.[ch]
	arch/mips/platforms/mfg_board_type1.[ch]
	arch/mips/platforms/mfg_board_type2.[ch]

keeps all manufacturer shared code in one place, and the board
files could be quite small.  I have the specific case right now
with a board vendor that has about six similar boards, all in
separate directories like this:

	arch/mips/au1000/board1/file.c
	arch/mips/au1000/board2/file.c
	arch/mips/au1000/board3/file.c

where the code is all identical in those files.  My first move is
going to be consolidation of all of the "board" directories into a
single "manufacturer" directory just to eliminate the overhead of
keeping all of these files consistent on updates.  Then, I'm just
going to prefix the board type to the unique file names.  I find
this much easier to maintain and to share code.  Common sense
file names using a standard manufacturer/board name prefix makes
the files just as easy to identify as separate directories.

It would be nice to see the defconfig files in their own directory,
that would be the single most useful way to eliminate some clutter :-)

Thanks.


	-- Dan


From jsun@mvista.com Fri Jun 13 22:44:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Jun 2003 22:44:37 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:44276 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225289AbTFMVof>;
	Fri, 13 Jun 2003 22:44:35 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h5DLiPQ14847;
	Fri, 13 Jun 2003 14:44:25 -0700
Date: Fri, 13 Jun 2003 14:44:25 -0700
From: Jun Sun <jsun@mvista.com>
To: Dan Malek <dan@embeddededge.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030613144425.E14458@mvista.com>
References: <Pine.GSO.3.96.1030613221736.20506C-100000@delta.ds2.pg.gda.pl> <3EEA3B5C.2000201@embeddededge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3EEA3B5C.2000201@embeddededge.com>; from dan@embeddededge.com on Fri, Jun 13, 2003 at 05:00:12PM -0400
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2626
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Jun 13, 2003 at 05:00:12PM -0400, Dan Malek wrote:
> Maciej W. Rozycki wrote:
> 
> >  It looks as a good idea, although possibly an intermediate directory
> > would be desireable not to clutter arch/mips too much.  E.g:
> > 
> >   arch/mips/platforms/platform1/...
> >                      /platform2/...
> 
>  From my experience with other architectures, fewer intermediate
> directories are often useful, for example:
> 
> 	arch/mips/platforms/board_and_chip_files
> 
> allows a maximum amount of code sharing and minimal duplication.
> When you have lots of lower level directories, you often have
> many identical files in them that should be shared, but are not,
> causing support/update challenges.  For example:
> 
> 	arch/mips/platforms/mfg_board_common.[ch]
> 	arch/mips/platforms/mfg_board_type1.[ch]
> 	arch/mips/platforms/mfg_board_type2.[ch]
>

Congradualtions!  You will have roughly about 950 files under that
directory.

Even with good effort to combine files and promote sharing, I think
you will still have quite some.

I think having another directory layer under arch/mips/platforms
shouldn't be too bad, (although I like arch/mips/machines better).  

We can use some scheme like Geert was proposing, i.e., named after
boards and chipsets.  Hack, I think even naming after board vendor
is acceptable.


> It would be nice to see the defconfig files in their own directory,
> that would be the single most useful way to eliminate some clutter :-)
>

I second on this.

Jun

From jsun@mvista.com Fri Jun 13 22:45:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Jun 2003 22:45:53 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:48629 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225289AbTFMVpv>;
	Fri, 13 Jun 2003 22:45:51 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h5DLjkm14861;
	Fri, 13 Jun 2003 14:45:46 -0700
Date: Fri, 13 Jun 2003 14:45:46 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030613144546.F14458@mvista.com>
References: <Pine.GSO.4.21.0306132052290.14094-100000@vervain.sonytel.be> <Pine.GSO.3.96.1030613221736.20506C-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1030613221736.20506C-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Jun 13, 2003 at 10:28:03PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2627
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Jun 13, 2003 at 10:28:03PM +0200, Maciej W. Rozycki wrote:
> On Fri, 13 Jun 2003, Geert Uytterhoeven wrote:
> 
> > So in the future we may see something like this:
> > 
> >   arch/mips/chipset1/...
> >            /chipset2/...
> > 	   /...
> > 	   /board1/...
> > 	   /board2/...
> > 
> > where the board* directories contain the glue code for the specific boards?
> 
>  It looks as a good idea, although possibly an intermediate directory
> would be desireable not to clutter arch/mips too much.  E.g:
> 
>   arch/mips/platforms/platform1/...
>                      /platform2/...
>             ...
>   arch/mips/chipset/chipset1/...
>                    /chipset2/...
> 
> I assume by "chipset" you mean the lone system controller or host bridge. 
>

I agree.

Jun

From ralf@linux-mips.org Sat Jun 14 00:23:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Jun 2003 00:23:32 +0100 (BST)
Received: from p508B7C8B.dip.t-dialin.net ([IPv6:::ffff:80.139.124.139]:50133
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225196AbTFMXX3>; Sat, 14 Jun 2003 00:23:29 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5DNNHbY023835;
	Fri, 13 Jun 2003 16:23:17 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5DNNFnE023834;
	Sat, 14 Jun 2003 01:23:15 +0200
Date: Sat, 14 Jun 2003 01:23:15 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: Dan Malek <dan@embeddededge.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030613232315.GB22949@linux-mips.org>
References: <Pine.GSO.3.96.1030613221736.20506C-100000@delta.ds2.pg.gda.pl> <3EEA3B5C.2000201@embeddededge.com> <20030613144425.E14458@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030613144425.E14458@mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2628
X-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, Jun 13, 2003 at 02:44:25PM -0700, Jun Sun wrote:

> Congradualtions!  You will have roughly about 950 files under that
> directory.
> 
> Even with good effort to combine files and promote sharing, I think
> you will still have quite some.
> 
> I think having another directory layer under arch/mips/platforms
> shouldn't be too bad, (although I like arch/mips/machines better).  
> 
> We can use some scheme like Geert was proposing, i.e., named after
> boards and chipsets.  Hack, I think even naming after board vendor
> is acceptable.

Chipsets are a too coarse granularity to structure things these days.
Modern chipsets integrate a large number of logically independant
functionality.  Frequently such chipsets are ASICs which consist of
various logically independant functions licensed from several sources
and possibly multiple chipset / ASICs are being used in a single
system.  The world just isn't that simple ...

  Ralf

From ppopov@mvista.com Sat Jun 14 01:36:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Jun 2003 01:36:22 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:8442 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225294AbTFNAgU>;
	Sat, 14 Jun 2003 01:36:20 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA11187;
	Fri, 13 Jun 2003 17:36:16 -0700
Subject: Re: [RFC] Au1x00 Ethernet driver
From: Pete Popov <ppopov@mvista.com>
To: joeg@clearcore.com
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030606180102.17899.qmail@clearcore.com>
References: <20030606180102.17899.qmail@clearcore.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1055551001.6221.190.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 13 Jun 2003 17:36:42 -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: 2629
X-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

Joe,

OK, I ran a quick test and applied it. I should probably put in a config
option to allow you to disable the highest ethernet port and use the
gpios instead.

Pete

On Fri, 2003-06-06 at 11:01, Joe George wrote:
> The Au1x00 SOCs allow the highest number ethernet interface
> to be disabled and some of the signals to be used as GPIOs.
> 
> The patch below detects if the interface is enabled and
> ignores it if it is disabled.  It is part of what I need.
> 
> Our boards do not contain the phy for either ethernet
> channel and may be used with 0, 1, or 2 ethernet interfaces.
> The phys are on separate boards.
> 
> If I do not install a phy on an interface I get an oops, so
> it doesn't look like everything that was setup in anticipation
> of finding the phy gets taken back down correctly.
> 
> 
> <4>eth0: Au1xxx ethernet found at 0xb0500000, irq 28
> <3>eth0: No MII transceivers found!
> <3>eth0: au1000_probe1 failed.  Returns 0
> <4>eth0: Au1xxx ethernet found at 0xb0510000, irq 29
> <6>eth0: Broadcom BCM5221 10/100 BaseT PHY at phy address 0
> <6>eth0: Using Broadcom BCM5221 10/100 BaseT PHY as default
> .
> .
> .
> <1>Unable to handle kernel paging request at virtual address 00000002, epc == 8024e140, ra == 8024ea34
> <4>Oops in fault.c::do_page_fault, line 206:
> .
> .
> .
> 
> I would like to use the same kernel for all cases and use phy
> detection to configure the interfaces.  So I'm really asking if
> phy detection is acceptable for inclusion in the kernel?  If so,
> I'll try to come up with acceptable patches.
> 
> More generally, I'm wondering whether using autodetection for
> configuration is desirable as there are a number of other areas
> where I'd like to see it used.
> 
> Joe
> 
> 
> --- linux-mips-cvs24/drivers/net/au1000_eth.c	Mon Jun  2 21:35:28 2003
> +++ tst_mips24/drivers/net/au1000_eth.c	Wed Jun  4 17:51:46 2003
> @@ -54,6 +54,7 @@
>  #include <asm/io.h>
>  
>  #include <asm/au1000.h>
> +#include <asm/cpu.h>
>  #include "au1000_eth.h"
>  
>  #ifdef AU1000_ETH_DEBUG
> @@ -109,27 +110,6 @@ extern char * __init prom_getcmdline(voi
>   */
>  
> 
> -/*
> - * Base address and interupt of the Au1xxx ethernet macs
> - */
> -static struct au1if {
> -	unsigned int port;
> -	int irq;
> -} au1x00_iflist[] = {
> -#if defined(CONFIG_SOC_AU1000)
> -		{AU1000_ETH0_BASE, AU1000_ETH0_IRQ}, 
> -		{AU1000_ETH1_BASE, AU1000_ETH1_IRQ}
> -#elif defined(CONFIG_SOC_AU1500)
> -		{AU1500_ETH0_BASE, AU1000_ETH0_IRQ}, 
> -		{AU1500_ETH1_BASE, AU1000_ETH1_IRQ}
> -#elif defined(CONFIG_SOC_AU1100)
> -		{AU1000_ETH0_BASE, AU1000_ETH0_IRQ}, 
> -#else
> -#error "Unsupported Au1x00 CPU"
> -#endif
> -	};
> -#define NUM_INTERFACES (sizeof(au1x00_iflist) / sizeof(struct au1if))
> -
>  static char version[] __devinitdata =
>      "au1000eth.c:1.1 ppopov@mvista.com\n";
>  
> @@ -1003,17 +983,40 @@ setup_hw_rings(struct au1000_private *au
>  	}
>  }
>  
> +/*
> + * Setup the base address and interupt of the Au1xxx ethernet macs
> + * based on cpu type and whether the interface is enabled in sys_pinfunc
> + * register. The last interface is enabled if SYS_PF_NI2 (bit 4) is 0.
> + */
>  static int __init au1000_init_module(void)
>  {
> -	int i;
> -	int base_addr, irq;
> -
> -	for (i=0; i<NUM_INTERFACES; i++) {
> -		base_addr = au1x00_iflist[i].port;
> -		irq = au1x00_iflist[i].irq;
> -		if (au1000_probe1(NULL, base_addr, irq, i) != 0) {
> +	struct cpuinfo_mips *c = &current_cpu_data;
> +	int base_addr[2], irq[2], num_ifs, i;
> +	int ni = (int)((au_readl(SYS_PINFUNC) & (u32)(SYS_PF_NI2)) >> 4);
> +
> +	irq[0] = AU1000_ETH0_IRQ;
> +	irq[1] = AU1000_ETH1_IRQ;
> +	switch (c->cputype) {
> +	case CPU_AU1000:
> +		num_ifs = 2 - ni;
> +		base_addr[0] = AU1000_ETH0_BASE;
> +		base_addr[1] = AU1000_ETH1_BASE;
> +		break;
> +	case CPU_AU1100:
> +		num_ifs = 1 - ni;
> +		base_addr[0] = AU1000_ETH0_BASE;
> +		break;
> +	case CPU_AU1500:
> +		num_ifs = 2 - ni;
> +		base_addr[0] = AU1500_ETH0_BASE;
> +		base_addr[1] = AU1500_ETH1_BASE;
> +		break;
> +	default:
> +		num_ifs = 0;
> +	}
> +	for(i = 0; i < num_ifs; i++) {
> +		if (au1000_probe1(NULL, base_addr[i], irq[i], i) != 0)
>  			return -ENODEV;
> -		}
>  	}
>  	return 0;
>  }
> 
> 


From joeg@clearcore.com Sat Jun 14 06:26:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Jun 2003 06:27:00 +0100 (BST)
Received: from www.clearcore.com ([IPv6:::ffff:69.20.152.109]:20938 "HELO
	clearcore.com") by linux-mips.org with SMTP id <S8225073AbTFNF06>;
	Sat, 14 Jun 2003 06:26:58 +0100
Received: (qmail 8162 invoked by uid 501); 14 Jun 2003 05:26:52 -0000
Date: 14 Jun 2003 05:26:52 -0000
Message-ID: <20030614052652.8161.qmail@clearcore.com>
From: Joe George <joeg@clearcore.com>
To: ppopov@mvista.com
CC: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: [PATCH] au1000_eth.c - Dave Jones
Reply-to: joeg@clearcore.com
Return-Path: <joeg@clearcore.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2630
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joeg@clearcore.com
Precedence: bulk
X-list: linux-mips

This patch was submitted on lkml by Dave Jones and reviewed
by Jeff Garzik.  Description:

- Missing release region
- Unneeded initialization of private struct
  (already done in init_etherdev)
- Remove unneeded freeing of dev-priv
  (auto-free'd by kfree(dev)
- actually kfree(dev), plugging leak.

Joe


diff -upN linux-mips-cvs24/drivers/net/au1000_eth.c tst_mips24/drivers/net/au1000_eth.c
--- linux-mips-cvs24/drivers/net/au1000_eth.c	Fri Jun 13 20:15:18 2003
+++ tst_mips24/drivers/net/au1000_eth.c	Fri Jun 13 22:19:09 2003
@@ -1110,38 +1110,21 @@ au1000_probe1(struct net_device *dev, lo
 	char *pmac, *argptr;
 	char ethaddr[6];
 
-	if (!request_region(PHYSADDR(ioaddr), MAC_IOSIZE, "Au1x00 ENET")) {
+	if (!request_region(PHYSADDR(ioaddr), MAC_IOSIZE, "Au1x00 ENET"))
 		 return -ENODEV;
-	}
 
 	if (version_printed++ == 0) printk(version);
 
 	if (!dev) {
-		dev = init_etherdev(0, sizeof(struct au1000_private));
-	}
-	if (!dev) {
-		 printk (KERN_ERR "au1000 eth: init_etherdev failed\n");  
-		 return -ENODEV;
+		dev = init_etherdev(NULL, sizeof(struct au1000_private));
+		printk (KERN_ERR "au1000 eth: init_etherdev failed\n");  
+		release_region(ioaddr, MAC_IOSIZE);
+		return -ENODEV;
 	}
 
 	printk("%s: Au1xxx ethernet found at 0x%lx, irq %d\n", 
 			dev->name, ioaddr, irq);
 
-	/* Initialize our private structure */
-	if (dev->priv == NULL) {
-		aup = (struct au1000_private *) 
-			kmalloc(sizeof(*aup), GFP_KERNEL);
-		if (aup == NULL) {
-			retval = -ENOMEM;
-			goto free_region;
-		}
-		dev->priv = aup;
-	}
-
-	aup = dev->priv;
-	memset(aup, 0, sizeof(*aup));
-
-
 	/* Allocate the data buffers */
 	aup->vaddr = (u32)dma_alloc(MAX_BUF_SIZE * 
 			(NUM_TX_BUFFS+NUM_RX_BUFFS), &aup->dma_addr);
@@ -1280,8 +1263,6 @@ free_region:
 	if (aup->vaddr) 
 		dma_free((void *)aup->vaddr, 
 				MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS));
-	if (dev->priv != NULL)
-		kfree(dev->priv);
 	kfree(aup->mii);
 	kfree(dev);
 	printk(KERN_ERR "%s: au1000_probe1 failed.  Returns %d\n",
@@ -1450,15 +1431,15 @@ static int au1000_close(struct net_devic
 	spin_lock_irqsave(&aup->lock, flags);
 	
 	/* stop the device */
-	if (netif_device_present(dev)) {
+	if (netif_device_present(dev))
 		netif_stop_queue(dev);
-	}
 
 	/* disable the interrupt */
 	free_irq(dev->irq, dev);
 	spin_unlock_irqrestore(&aup->lock, flags);
 
 	reset_mac(dev);
+	kfree(dev);
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

From skottilingal@kinetowireless.com Sat Jun 14 06:29:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Jun 2003 06:29:57 +0100 (BST)
Received: from 66-126-253-28.ded.pacbell.net ([IPv6:::ffff:66.126.253.28]:33927
	"EHLO blunote.bluzona.com") by linux-mips.org with ESMTP
	id <S8225073AbTFNF34> convert rfc822-to-8bit; Sat, 14 Jun 2003 06:29:56 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 8BIT
Subject: Open SSL port on MIPS
Date: Fri, 13 Jun 2003 22:29:46 -0700
Message-ID: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E11780A8@blunote.bluzona.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Open SSL port on MIPS
Thread-Index: AcMyNa8dPeUBprxNRnq4E/fdLVdubQAAAe/w
From: "Sudeep Kottilingal" <skottilingal@kinetowireless.com>
To: <joeg@clearcore.com>, <ppopov@mvista.com>
Cc: <linux-mips@linux-mips.org>, <ralf@linux-mips.org>
Return-Path: <skottilingal@kinetowireless.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2631
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: skottilingal@kinetowireless.com
Precedence: bulk
X-list: linux-mips

Hi all,
I am looking for a MIPS port of openSSL project.
Does anyone has worked on it. If so where is it available.

Sudeep
Kineto Wireless Inc.

From Geert.Uytterhoeven@sonycom.com Sat Jun 14 09:56:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Jun 2003 09:56:47 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:11236 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225073AbTFNI4p>;
	Sat, 14 Jun 2003 09:56:45 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h5E8u5pI005711;
	Sat, 14 Jun 2003 10:56:05 +0200 (MEST)
Date: Sat, 14 Jun 2003 10:56:04 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Sudeep Kottilingal <skottilingal@kinetowireless.com>
cc: joeg@clearcore.com, ppopov@mvista.com,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Open SSL port on MIPS
In-Reply-To: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E11780A8@blunote.bluzona.com>
Message-ID: <Pine.GSO.4.21.0306141055360.14234-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2632
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Fri, 13 Jun 2003, Sudeep Kottilingal wrote:
> I am looking for a MIPS port of openSSL project.
> Does anyone has worked on it. If so where is it available.

It's already there, check out www.debian.org.

Gr{oetje,eeting}s,

						Geert

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

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


From ralf@linux-mips.org Sat Jun 14 12:00:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Jun 2003 12:01:01 +0100 (BST)
Received: from p508B60ED.dip.t-dialin.net ([IPv6:::ffff:80.139.96.237]:50321
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225073AbTFNLA6>; Sat, 14 Jun 2003 12:00:58 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5EB0mbY005263;
	Sat, 14 Jun 2003 04:00:48 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5EB0lw5005262;
	Sat, 14 Jun 2003 13:00:47 +0200
Date: Sat, 14 Jun 2003 13:00:47 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Sudeep Kottilingal <skottilingal@kinetowireless.com>
Cc: joeg@clearcore.com, ppopov@mvista.com, linux-mips@linux-mips.org
Subject: Re: Open SSL port on MIPS
Message-ID: <20030614110046.GA4578@linux-mips.org>
References: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E11780A8@blunote.bluzona.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E11780A8@blunote.bluzona.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: 2633
X-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, Jun 13, 2003 at 10:29:46PM -0700, Sudeep Kottilingal wrote:

> I am looking for a MIPS port of openSSL project.
> Does anyone has worked on it. If so where is it available.

Works out of the box for me - openssl is based on it.

  Ralf

From macro@ds2.pg.gda.pl Sat Jun 14 19:47:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Jun 2003 19:47:51 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:40066 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225209AbTFNSrt>; Sat, 14 Jun 2003 19:47:49 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA06138;
	Sat, 14 Jun 2003 20:48:22 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Sat, 14 Jun 2003 20:48:22 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dan Malek <dan@embeddededge.com>
cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Jun Sun <jsun@mvista.com>, Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <3EEA3B5C.2000201@embeddededge.com>
Message-ID: <Pine.GSO.3.96.1030614203554.1934E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2634
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 13 Jun 2003, Dan Malek wrote:

> >   arch/mips/platforms/platform1/...
> >                      /platform2/...
> 
>  From my experience with other architectures, fewer intermediate
> directories are often useful, for example:
> 
> 	arch/mips/platforms/board_and_chip_files
> 
> allows a maximum amount of code sharing and minimal duplication.

 What prevents one from sharing code from different directories?

> When you have lots of lower level directories, you often have
> many identical files in them that should be shared, but are not,
> causing support/update challenges.  For example:
> 
> 	arch/mips/platforms/mfg_board_common.[ch]
> 	arch/mips/platforms/mfg_board_type1.[ch]
> 	arch/mips/platforms/mfg_board_type2.[ch]
> 
> keeps all manufacturer shared code in one place, and the board
> files could be quite small.  I have the specific case right now
> with a board vendor that has about six similar boards, all in
> separate directories like this:
> 
> 	arch/mips/au1000/board1/file.c
> 	arch/mips/au1000/board2/file.c
> 	arch/mips/au1000/board3/file.c
> 
> where the code is all identical in those files.  My first move is

 IMO file.c should me moved up one level or to arch/mips/au1000/lib.

> going to be consolidation of all of the "board" directories into a
> single "manufacturer" directory just to eliminate the overhead of
> keeping all of these files consistent on updates.  Then, I'm just
> going to prefix the board type to the unique file names.  I find
> this much easier to maintain and to share code.  Common sense
> file names using a standard manufacturer/board name prefix makes
> the files just as easy to identify as separate directories.

 Identification is not a problem.  Logical separation is.  Directories
were invented for a reason.

> It would be nice to see the defconfig files in their own directory,
> that would be the single most useful way to eliminate some clutter :-)

 It sounds reasonable.  The generic defconfig of course has to be left
where it is now.

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


From macro@ds2.pg.gda.pl Sat Jun 14 19:54:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Jun 2003 19:54:51 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:14211 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225209AbTFNSyt>; Sat, 14 Jun 2003 19:54:49 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA06240;
	Sat, 14 Jun 2003 20:55:46 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Sat, 14 Jun 2003 20:55:45 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Jun Sun <jsun@mvista.com>, Dan Malek <dan@embeddededge.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030613232315.GB22949@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030614204954.1934F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2635
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Sat, 14 Jun 2003, Ralf Baechle wrote:

> > We can use some scheme like Geert was proposing, i.e., named after
> > boards and chipsets.  Hack, I think even naming after board vendor
> > is acceptable.
> 
> Chipsets are a too coarse granularity to structure things these days.
> Modern chipsets integrate a large number of logically independant
> functionality.  Frequently such chipsets are ASICs which consist of
> various logically independant functions licensed from several sources
> and possibly multiple chipset / ASICs are being used in a single
> system.  The world just isn't that simple ...

 What's the deal?  E.g. for a PCI chip we can have a separate file for
each function.  And anything that is not related to a system's core, i.e. 
a peripheral device, belongs to drivers/whatever anyway.

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


From wesolows@foobazco.org Sat Jun 14 20:39:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Jun 2003 20:39:19 +0100 (BST)
Received: from janus.foobazco.org ([IPv6:::ffff:198.144.194.226]:61825 "EHLO
	mail.foobazco.org") by linux-mips.org with ESMTP
	id <S8225073AbTFNTjR>; Sat, 14 Jun 2003 20:39:17 +0100
Received: from fallout.sjc.foobazco.org (fallout.sjc.foobazco.org [192.168.21.20])
	by mail.foobazco.org (Postfix) with ESMTP
	id AEBBCFACE; Sat, 14 Jun 2003 12:39:13 -0700 (PDT)
Received: by fallout.sjc.foobazco.org (Postfix, from userid 1014)
	id 6290224; Sat, 14 Jun 2003 12:39:13 -0700 (PDT)
Date: Sat, 14 Jun 2003 12:39:13 -0700
From: Keith M Wesolowski <wesolows@foobazco.org>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: PATCH: ip32 pci update
Message-ID: <20030614193913.GA25863@foobazco.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <wesolows@foobazco.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2636
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wesolows@foobazco.org
Precedence: bulk
X-list: linux-mips

Since we're chainsawing PCI anyway, here's an update to the IP32 code.

diff -urN -x CVS 2.5-mips/arch/mips/sgi-ip32/ip32-pci.c 2.5-mips-moosehead/arch/mips/sgi-ip32/ip32-pci.c
--- 2.5-mips/arch/mips/sgi-ip32/ip32-pci.c	2003-06-04 17:04:31.000000000 -0700
+++ 2.5-mips-moosehead/arch/mips/sgi-ip32/ip32-pci.c	2003-06-14 12:33:19.952495096 -0700
@@ -135,9 +135,6 @@
 	mace_write_32 (MACEPCI_ERROR_ADDR, 0);
 	mace_write_32 (MACEPCI_ERROR_FLAGS, 0);
 	mace_write_32 (MACEPCI_CONTROL, 0xff008500);
-	crime_write_64 (CRIME_HARD_INT, 0UL);
-	crime_write_64 (CRIME_SOFT_INT, 0UL);
-	crime_write_64 (CRIME_INT_STAT, 0x000000000000ff00UL);
 
 	if (request_irq (MACE_PCI_BRIDGE_IRQ, macepci_error, 0,
 			 "MACE PCI error", NULL))
@@ -214,26 +211,6 @@
 		pci_write_config_word (dev, PCI_COMMAND, cmd);
 		pci_set_master (dev);
 	}
-        /*
-         * Fixup O2 PCI slot. Bad hack.
-         */
-/*        devtag = pci_make_tag(0, 0, 3, 0);
-
-        slot = macepci_conf_read(0, devtag, PCI_COMMAND_STATUS_REG);
-        slot |= PCI_COMMAND_IO_ENABLE | PCI_COMMAND_MEM_ENABLE;
-        macepci_conf_write(0, devtag, PCI_COMMAND_STATUS_REG, slot);
-
-        slot = macepci_conf_read(0, devtag, PCI_MAPREG_START);
-        if (slot == 0xffffffe1)
-                macepci_conf_write(0, devtag, PCI_MAPREG_START, 0x00001000);
-
-        slot = macepci_conf_read(0, devtag, PCI_MAPREG_START + (2 << 2));
-        if ((slot & 0xffff0000) == 0) {
-                slot += 0x00010000;
-                macepci_conf_write(0, devtag, PCI_MAPREG_START + (2 << 2),
-                    0x00000000);
-        }
- */
 #ifdef DEBUG_MACE_PCI
 	printk ("Triggering PCI bridge interrupt...\n");
 	mace_write_32 (MACEPCI_ERROR_FLAGS, MACEPCI_ERROR_INTERRUPT_TEST);


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

From bchaikin@galileo.co.il Sun Jun 15 15:46:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 15 Jun 2003 15:46:19 +0100 (BST)
Received: from pop3.galileo.co.il ([IPv6:::ffff:199.203.130.130]:15801 "EHLO
	galileo5.galileo.co.il") by linux-mips.org with ESMTP
	id <S8225202AbTFOOqQ>; Sun, 15 Jun 2003 15:46:16 +0100
Received: from galileo.co.il ([10.2.2.45])
	by galileo5.galileo.co.il (8.12.6/8.12.6) with ESMTP id h5FFiBlH028763;
	Sun, 15 Jun 2003 17:44:12 +0200 (GMT-2)
Message-ID: <3EEC9513.80905@galileo.co.il>
Date: Sun, 15 Jun 2003 17:47:31 +0200
From: Baruch Chaikin <bchaikin@il.marvell.com>
Organization: Marvell Israel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>
Subject: Re: Building a stand-alone FS on a very limited flash (newbie question)
References: <20030610131519.47A8BC5FD7@atlas.denx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
To: unlisted-recipients:; (no To-header on input)
Return-Path: <bchaikin@galileo.co.il>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2637
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bchaikin@il.marvell.com
Precedence: bulk
X-list: linux-mips

All,

To conclude, the recommendation here is to:
o	Compile with uClibC or dietlibc
o	Use busybox
o	Gain extra 0.5 MB space

Another question is the file system itself.  What is the recommendation 
here - JFFS, CRAMFS, anything else?...

Thanks for your answers!
-	Baruch.


Wolfgang Denk wrote:
> In message <20030610125623.GC30175@rembrandt.csv.ica.uni-stuttgart.de> you wrote:
> 
>>># ls -l lib | grep -v '^[ld]'
>>>total 2433
>>
>>I conclude ELDK consists of little more than the basic networking utilities,
> 
> 
> The ELDK (Embedded Linux Development Kit) consists of MUCH more (more
> than 400 MB if you install everything).
> 
> I was just talking about the  ramdisk  image.  You  are  right,  this
> contains busybox plus basic networking utilities. For this framework,
> the compressed image size is about 1.3 MB.
> 
> 
>>and the libc-related parts eat up most of the space. A more feature-rich
>>system probably can't afford to waste that much.
> 
> 
> The oriiginal poster mentioned that he has 2.5 MB available, so if he
> uses something like the framework I mentioned he  still  has  1.2  MB
> compressed size available. This is a _lot_.
> 
> 
> If memroy really gets tight, there are other  places  where  you  can
> save space, for example the O.P. wrote:
> 
> 
>>  0.5 MB is allocated for the firmware code
>>  1.0 MB for the compressed kernel image
>>  2.5 MB for the (compressed?) file system
> 
> 
> The reservation for both the firmware and for  the  kernel  image  is
> more  than generous; 256 kB + 768 kB should be sufficient, too. Which
> gives another 0.5 MB for application stuff.
> 
> 
> Please understand me right: I do not want  to  deny  that  uClibc  or
> dietlibc  are  fine  methods  to  optimize  the memory footprint of a
> system. But for a starter it is probably much easier to use  standard
> libraries as long as there is memory available.
> 
> For the current thread the keyword was "strip". 
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 


-- 
This message may contain confidential, proprietary or legally privileged 
information. The information is intended only for the use of the 
individual or entity named above. If the reader of this message is not 
the intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. If 
you have received this communication in error, please notify us 
immediately by telephone, or by e-mail and delete the message from your 
computer.


From ilya@gateway.total-knowledge.com Sun Jun 15 16:18:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 15 Jun 2003 16:18:36 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:61606
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225202AbTFOPSc>; Sun, 15 Jun 2003 16:18:32 +0100
Received: (qmail 7344 invoked by uid 502); 15 Jun 2003 15:18:26 -0000
Date: Sun, 15 Jun 2003 08:18:26 -0700
From: ilya@theIlya.com
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030615151826.GB32449@gateway.total-knowledge.com>
References: <20030615135712Z8225205-1272+2604@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R"
Content-Disposition: inline
In-Reply-To: <20030615135712Z8225205-1272+2604@linux-mips.org>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2638
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

I think in 2.5 serial drivers should leave in drivers/serial
	Ilya.

On Sun, Jun 15, 2003 at 02:57:08PM +0100, ralf@linux-mips.org wrote:
>=20
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	03/06/15 14:57:08
>=20
> Modified files:
> 	drivers/char   : Makefile=20
> 	arch/mips/au1000/common: Makefile=20
> Added files:
> 	drivers/char   : au1x00-serial.c=20
> Removed files:
> 	arch/mips/au1000/common: serial.c=20
>=20
> Log message:
> 	Drivers have some place where they're supposed to life damn...
>=20
>=20

--kXdP64Ggrk/fb43R
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+7I5C7sVBmHZT8w8RAieBAKCiUfgYCbLmZPaQmUtgnOjLoGDXJQCdF4+q
dTrWF4xizL32CJoH0AF6xls=
=vjLS
-----END PGP SIGNATURE-----

--kXdP64Ggrk/fb43R--

From wesolows@foobazco.org Sun Jun 15 19:04:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 15 Jun 2003 19:04:35 +0100 (BST)
Received: from janus.foobazco.org ([IPv6:::ffff:198.144.194.226]:14210 "EHLO
	mail.foobazco.org") by linux-mips.org with ESMTP
	id <S8225202AbTFOSEc>; Sun, 15 Jun 2003 19:04:32 +0100
Received: from fallout.sjc.foobazco.org (fallout.sjc.foobazco.org [192.168.21.20])
	by mail.foobazco.org (Postfix) with ESMTP id 08264FABB
	for <linux-mips@linux-mips.org>; Sun, 15 Jun 2003 11:04:26 -0700 (PDT)
Received: by fallout.sjc.foobazco.org (Postfix, from userid 1014)
	id B91E624; Sun, 15 Jun 2003 11:04:26 -0700 (PDT)
Date: Sun, 15 Jun 2003 11:04:26 -0700
From: Keith M Wesolowski <wesolows@foobazco.org>
To: linux-mips@linux-mips.org
Subject: PATCH: 64-bit IO for 32bit kernels
Message-ID: <20030615180426.GA21094@foobazco.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <wesolows@foobazco.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2639
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wesolows@foobazco.org
Precedence: bulk
X-list: linux-mips

This makes 64-bit I/O functions like sibyte uses generic, because IP32
at least needs them.  I'm told it compiles.

Comments?

diff -urN -x CVS 2.5-mips/include/asm-mips/io64.h 2.5-mips-io64/include/asm-mips/io64.h
--- 2.5-mips/include/asm-mips/io64.h	1969-12-31 16:00:00.000000000 -0800
+++ 2.5-mips-io64/include/asm-mips/io64.h	2003-06-15 10:22:37.423123555 -0700
@@ -0,0 +1,99 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2000, 2001 Broadcom Corporation
+ * Copyright (C) 2002 Ralf Baechle
+ * Copyright (C) 2003 Keith M Wesolowski
+ */
+
+#ifndef __ASM_IO64_H
+#define __ASM_IO64_H
+
+#include <linux/types.h>
+
+/* Generic 64-bit I/O register reads and writes.  This does no byte-swapping
+ * as it makes little sense and no platform that needs this is insane enough
+ * to require it.
+ */
+
+#ifndef __ASSEMBLY__
+#if _MIPS_SZLONG >= 64
+static inline u64 __in64(unsigned long addr)
+{
+	return *(volatile u64 *)addr;
+}
+
+static inline void __out64(u64 val, unsigned long addr)
+{
+	*(volatile u64 *)addr = val;
+}
+
+#define in64(a)		__in64(a)
+#define out64(v,a)	__out64(v,a)
+
+#else /* _MIPS_SZLONG < 64 */
+
+#include <asm/system.h>
+
+static inline u64 __in64(unsigned long addr)
+{
+	u64 res;
+
+	asm volatile (
+		"	.set	mips3				\n"
+		"	ld	%L0, (%1)	# __in64	\n"
+		"	dsra	%M0, %L0, 32			\n"
+		"	sll	%L0, 0				\n"
+		"	.set	mips0				\n"
+		: "=r" (res)
+		: "r" (addr)
+	);
+
+	return res;
+}
+
+static inline u64 in64(unsigned long addr)
+{
+	unsigned long flags;
+	u64 res;
+
+	local_irq_save(flags);
+	res = __in64(addr);
+	local_irq_restore(flags);
+
+	return res;
+}
+
+static inline void __out64(u64 val, unsigned long addr)
+{
+	u64 tmp;
+
+	asm volatile (
+		"	.set	mips3				\n"
+		"	dsll	%L0, 32		# __out64	\n"
+		"	dsll	%M0, 32				\n"
+		"	dsrl	%L0, 32				\n"
+		"	or	%L0, %M0			\n"
+		"	sd	%L0, (%2)			\n"
+		"	.set	mips0				\n"
+		: "=&r" (tmp)
+		: "0" (val), "r" (addr)
+		: "memory"
+	);
+}
+
+static inline void out64(u64 val, unsigned long addr)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+	__out64(val, addr);
+	local_irq_restore(flags);
+}
+#endif /* _MIPS_SZLONG */
+#endif /* !__ASSEMBLY__ */
+
+
+#endif /* __ASM_IO64_H */
diff -urN -x CVS 2.5-mips/include/asm-mips/sibyte/64bit.h 2.5-mips-io64/include/asm-mips/sibyte/64bit.h
--- 2.5-mips/include/asm-mips/sibyte/64bit.h	2003-06-15 10:01:41.819344267 -0700
+++ 2.5-mips-io64/include/asm-mips/sibyte/64bit.h	2003-06-15 09:50:28.740647757 -0700
@@ -20,94 +20,9 @@
 #ifndef __ASM_SIBYTE_64BIT_H
 #define __ASM_SIBYTE_64BIT_H
 
-#include <linux/config.h>
+#include <asm/io64.h>
 #include <linux/types.h>
 
-#ifdef CONFIG_MIPS32
-
-#include <asm/system.h>
-
-/*
- * This is annoying...we can't actually write the 64-bit IO register properly
- * without having access to 64-bit registers...  which doesn't work by default
- * in o32 format...grrr...
- */
-static inline void __out64(u64 val, unsigned long addr)
-{
-	u64 tmp;
-
-	__asm__ __volatile__ (
-		"	.set	mips3				\n"
-		"	dsll32	%L0, %L0, 0	# __out64	\n"
-		"	dsrl32	%L0, %L0, 0			\n"
-		"	dsll32	%M0, %M0, 0			\n"
-		"	or	%L0, %L0, %M0			\n"
-		"	sd	%L0, (%2)			\n"
-		"	.set	mips0				\n"
-		: "=r" (tmp)
-		: "0" (val), "r" (addr));
-}
-
-static inline void out64(u64 val, unsigned long addr)
-{
-	unsigned long flags;
-
-	local_irq_save(flags);
-	__out64(val, addr);
-	local_irq_restore(flags);
-}
-
-static inline u64 __in64(unsigned long addr)
-{
-	u64 res;
-
-	__asm__ __volatile__ (
-		"	.set	mips3		# __in64	\n"
-		"	ld	%L0, (%1)			\n"
-		"	dsra32	%M0, %L0, 0			\n"
-		"	sll	%L0, %L0, 0			\n"
-		"	.set	mips0				\n"
-		: "=r" (res)
-		: "r" (addr));
-
-	return res;
-}
-
-static inline u64 in64(unsigned long addr)
-{
-	unsigned long flags;
-	u64 res;
-
-	local_irq_save(flags);
-	res = __in64(addr);
-	local_irq_restore(flags);
-
-	return res;
-}
-
-#endif /* CONFIG_MIPS32 */
-
-#ifdef CONFIG_MIPS64
-
-/*
- * These are provided so as to be able to use common
- * driver code for the 32-bit and 64-bit trees
- */
-extern inline void out64(u64 val, unsigned long addr)
-{
-	*(volatile unsigned long *)addr = val;
-}
-
-extern inline u64 in64(unsigned long addr)
-{
-	return *(volatile unsigned long *)addr;
-}
-
-#define __in64(a)	in64(a)
-#define __out64(v,a)	out64(v,a)
-
-#endif /* CONFIG_MIPS64 */
-
 /*
  * Avoid interrupt mucking, just adjust the address for 4-byte access.
  * Assume the addresses are 8-byte aligned.
diff -urN -x CVS 2.5-mips/include/asm-mips64/io64.h 2.5-mips-io64/include/asm-mips64/io64.h
--- 2.5-mips/include/asm-mips64/io64.h	1969-12-31 16:00:00.000000000 -0800
+++ 2.5-mips-io64/include/asm-mips64/io64.h	2003-06-15 10:22:48.300649235 -0700
@@ -0,0 +1,99 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2000, 2001 Broadcom Corporation
+ * Copyright (C) 2002 Ralf Baechle
+ * Copyright (C) 2003 Keith M Wesolowski
+ */
+
+#ifndef __ASM_IO64_H
+#define __ASM_IO64_H
+
+#include <linux/types.h>
+
+/* Generic 64-bit I/O register reads and writes.  This does no byte-swapping
+ * as it makes little sense and no platform that needs this is insane enough
+ * to require it.
+ */
+
+#ifndef __ASSEMBLY__
+#if _MIPS_SZLONG >= 64
+static inline u64 __in64(unsigned long addr)
+{
+	return *(volatile u64 *)addr;
+}
+
+static inline void __out64(u64 val, unsigned long addr)
+{
+	*(volatile u64 *)addr = val;
+}
+
+#define in64(a)		__in64(a)
+#define out64(v,a)	__out64(v,a)
+
+#else /* _MIPS_SZLONG < 64 */
+
+#include <asm/system.h>
+
+static inline u64 __in64(unsigned long addr)
+{
+	u64 res;
+
+	asm volatile (
+		"	.set	mips3				\n"
+		"	ld	%L0, (%1)	# __in64	\n"
+		"	dsra	%M0, %L0, 32			\n"
+		"	sll	%L0, 0				\n"
+		"	.set	mips0				\n"
+		: "=r" (res)
+		: "r" (addr)
+	);
+
+	return res;
+}
+
+static inline u64 in64(unsigned long addr)
+{
+	unsigned long flags;
+	u64 res;
+
+	local_irq_save(flags);
+	res = __in64(addr);
+	local_irq_restore(flags);
+
+	return res;
+}
+
+static inline void __out64(u64 val, unsigned long addr)
+{
+	u64 tmp;
+
+	asm volatile (
+		"	.set	mips3				\n"
+		"	dsll	%L0, 32		# __out64	\n"
+		"	dsll	%M0, 32				\n"
+		"	dsrl	%L0, 32				\n"
+		"	or	%L0, %M0			\n"
+		"	sd	%L0, (%2)			\n"
+		"	.set	mips0				\n"
+		: "=&r" (tmp)
+		: "0" (val), "r" (addr)
+		: "memory"
+	);
+}
+
+static inline void out64(u64 val, unsigned long addr)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+	__out64(val, addr);
+	local_irq_restore(flags);
+}
+#endif /* _MIPS_SZLONG */
+#endif /* !__ASSEMBLY__ */
+
+
+#endif /* __ASM_IO64_H */
diff -urN -x CVS 2.5-mips/include/asm-mips64/ip32/crime.h 2.5-mips-io64/include/asm-mips64/ip32/crime.h
--- 2.5-mips/include/asm-mips64/ip32/crime.h	2003-06-15 10:07:13.904324165 -0700
+++ 2.5-mips-io64/include/asm-mips64/ip32/crime.h	2003-06-15 10:05:50.892572980 -0700
@@ -11,6 +11,7 @@
 #ifndef __ASM_CRIME_H__
 #define __ASM_CRIME_H__
 
+#include <asm/io64.h>
 #include <asm/addrspace.h>
 
 /*
@@ -23,12 +24,8 @@
 #endif
 
 #ifndef __ASSEMBLY__
-static inline u64 crime_read_64 (unsigned long __offset) {
-        return *((volatile u64 *) (CRIME_BASE + __offset));
-}
-static inline void crime_write_64 (unsigned long __offset, u64 __val) {
-        *((volatile u64 *) (CRIME_BASE + __offset)) = __val;
-}
+#define crime_read_64(__offset)		__in64(CRIME_BASE+(__offset))
+#define crime_write_64(__offset,__val)	__out64(__val,CRIME_BASE+(__offset))
 #endif
 
 #undef BIT
diff -urN -x CVS 2.5-mips/include/asm-mips64/ip32/mace.h 2.5-mips-io64/include/asm-mips64/ip32/mace.h
--- 2.5-mips/include/asm-mips64/ip32/mace.h	2003-06-15 10:07:14.097297946 -0700
+++ 2.5-mips-io64/include/asm-mips64/ip32/mace.h	2003-06-15 10:57:56.605873141 -0700
@@ -11,6 +11,7 @@
 #ifndef __ASM_MACE_H__
 #define __ASM_MACE_H__
 
+#include <asm/io64.h>
 #include <asm/addrspace.h>
 
 /*
@@ -220,7 +221,7 @@
 
 static inline u64 mace_read_64 (unsigned long __offset)
 {
-	return *((volatile u64 *) (MACE_BASE + __offset));
+	return __in64 (MACE_BASE + __offset);
 }
 
 static inline void mace_write_8 (unsigned long __offset, u8 __val)
@@ -240,7 +241,7 @@
 
 static inline void mace_write_64 (unsigned long __offset, u64 __val)
 {
-	*((volatile u64 *) (MACE_BASE + __offset)) = __val;
+	__out64 (__val, MACE_BASE + __offset);
 }
 
 /* Call it whenever device needs to read data from main memory coherently */
diff -urN -x CVS 2.5-mips/include/asm-mips64/sibyte/64bit.h 2.5-mips-io64/include/asm-mips64/sibyte/64bit.h
--- 2.5-mips/include/asm-mips64/sibyte/64bit.h	2003-02-19 13:07:27.000000000 -0800
+++ 2.5-mips-io64/include/asm-mips64/sibyte/64bit.h	2003-06-15 10:00:59.031149508 -0700
@@ -20,94 +20,9 @@
 #ifndef __ASM_SIBYTE_64BIT_H
 #define __ASM_SIBYTE_64BIT_H
 
-#include <linux/config.h>
+#include <asm/io64.h>
 #include <linux/types.h>
 
-#ifdef CONFIG_MIPS32
-
-#include <asm/system.h>
-
-/*
- * This is annoying...we can't actually write the 64-bit IO register properly
- * without having access to 64-bit registers...  which doesn't work by default
- * in o32 format...grrr...
- */
-static inline void __out64(u64 val, unsigned long addr)
-{
-	u64 tmp;
-
-	__asm__ __volatile__ (
-		"	.set	mips3				\n"
-		"	dsll32	%L0, %L0, 0	# __out64	\n"
-		"	dsrl32	%L0, %L0, 0			\n"
-		"	dsll32	%M0, %M0, 0			\n"
-		"	or	%L0, %L0, %M0			\n"
-		"	sd	%L0, (%2)			\n"
-		"	.set	mips0				\n"
-		: "=r" (tmp)
-		: "0" (val), "r" (addr));
-}
-
-static inline void out64(u64 val, unsigned long addr)
-{
-	unsigned long flags;
-
-	local_irq_save(flags);
-	__out64(val, addr);
-	local_irq_restore(flags);
-}
-
-static inline u64 __in64(unsigned long addr)
-{
-	u64 res;
-
-	__asm__ __volatile__ (
-		"	.set	mips3		# __in64	\n"
-		"	ld	%L0, (%1)			\n"
-		"	dsra32	%M0, %L0, 0			\n"
-		"	sll	%L0, %L0, 0			\n"
-		"	.set	mips0				\n"
-		: "=r" (res)
-		: "r" (addr));
-
-	return res;
-}
-
-static inline u64 in64(unsigned long addr)
-{
-	unsigned long flags;
-	u64 res;
-
-	local_irq_save(flags);
-	res = __in64(addr);
-	local_irq_restore(flags);
-
-	return res;
-}
-
-#endif /* CONFIG_MIPS32 */
-
-#ifdef CONFIG_MIPS64
-
-/*
- * These are provided so as to be able to use common
- * driver code for the 32-bit and 64-bit trees
- */
-extern inline void out64(u64 val, unsigned long addr)
-{
-	*(volatile unsigned long *)addr = val;
-}
-
-extern inline u64 in64(unsigned long addr)
-{
-	return *(volatile unsigned long *)addr;
-}
-
-#define __in64(a)	in64(a)
-#define __out64(v,a)	out64(v,a)
-
-#endif /* CONFIG_MIPS64 */
-
 /*
  * Avoid interrupt mucking, just adjust the address for 4-byte access.
  * Assume the addresses are 8-byte aligned.


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

From nemoto@toshiba-tops.co.jp Mon Jun 16 02:18:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Jun 2003 02:18:30 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:44566
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225205AbTFPBS1>; Mon, 16 Jun 2003 02:18:27 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for [62.254.210.162]) with SMTP; 16 Jun 2003 01:18:25 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h5G1IDiY019426;
	Mon, 16 Jun 2003 10:18:14 +0900 (JST)
	(envelope-from nemoto@toshiba-tops.co.jp)
Date: Mon, 16 Jun 2003 10:19:11 +0900 (JST)
Message-Id: <20030616.101911.07647456.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
In-Reply-To: <20030615004718Z8225220-1272+2582@linux-mips.org>
References: <20030615004718Z8225220-1272+2582@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <nemoto@toshiba-tops.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2640
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nemoto@toshiba-tops.co.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Sun, 15 Jun 2003 01:47:13 +0100, ralf@linux-mips.org said:
> Modified files:
> 	arch/mips64    : Tag: linux_2_4 Makefile 
> 	include/asm-mips64: Tag: linux_2_4 processor.h r4kcache.h 

> Log message:
> 	Support GT64120 boards with 64-bit kernels also.

This corrupts mips64/mm/c-r4k.c.  Please apply this patch also.


diff -u linux-mips-cvs/arch/mips64/mm/c-r4k.c linux.new/arch/mips64/mm/c-r4k.c
--- linux-mips-cvs/arch/mips64/mm/c-r4k.c	Mon Apr 28 09:44:53 2003
+++ linux.new/arch/mips64/mm/c-r4k.c	Mon Jun 16 09:59:38 2003
@@ -26,7 +26,6 @@
 
 /* Primary cache parameters. */
 static unsigned long icache_size, dcache_size, scache_size;
-unsigned long icache_way_size, dcache_way_size, scache_way_size;
 static unsigned long scache_size;
 
 #include <asm/cacheops.h>
@@ -848,8 +847,8 @@
 		panic("Improper R4000SC processor configuration detected");
 
 	/* compute a couple of other cache variables */
-	icache_way_size = icache_size / c->icache.ways;
-	dcache_way_size = dcache_size / c->dcache.ways;
+	c->icache.waysize = icache_size / c->icache.ways;
+	c->dcache.waysize = dcache_size / c->dcache.ways;
 
 	c->icache.sets = icache_size / (c->icache.linesz * c->icache.ways);
 	c->dcache.sets = dcache_size / (c->dcache.linesz * c->dcache.ways);
@@ -862,7 +861,7 @@
 	 */
 	if (current_cpu_data.cputype != CPU_R10000 &&
 	    current_cpu_data.cputype != CPU_R12000)
-		if (dcache_way_size > PAGE_SIZE)
+		if (c->dcache.waysize > PAGE_SIZE)
 		        c->dcache.flags |= MIPS_CACHE_ALIASES;
 
 	if (config & 0x8)		/* VI bit */
diff -u linux-mips-cvs/arch/mips64/mm/sc-rm7k.c linux.new/arch/mips64/mm/sc-rm7k.c
--- linux-mips-cvs/arch/mips64/mm/sc-rm7k.c	Fri Apr 18 10:23:12 2003
+++ linux.new/arch/mips64/mm/sc-rm7k.c	Mon Jun 16 09:59:59 2003
@@ -20,8 +20,6 @@
 /* Secondary cache parameters. */
 #define scache_size	(256*1024)	/* Fixed to 256KiB on RM7000 */
 
-extern unsigned long icache_way_size, dcache_way_size;
-
 #include <asm/r4kcache.h>
 
 int rm7k_tcache_enabled;
---
Atsushi Nemoto

From nemoto@toshiba-tops.co.jp Mon Jun 16 02:41:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Jun 2003 02:41:39 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:51477
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225205AbTFPBlg>; Mon, 16 Jun 2003 02:41:36 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for [62.254.210.162]) with SMTP; 16 Jun 2003 01:41:34 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h5G1fQiY019490;
	Mon, 16 Jun 2003 10:41:27 +0900 (JST)
	(envelope-from nemoto@toshiba-tops.co.jp)
Date: Mon, 16 Jun 2003 10:42:24 +0900 (JST)
Message-Id: <20030616.104224.92590182.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
In-Reply-To: <20030616.101911.07647456.nemoto@toshiba-tops.co.jp>
References: <20030615004718Z8225220-1272+2582@linux-mips.org>
	<20030616.101911.07647456.nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <nemoto@toshiba-tops.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2641
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nemoto@toshiba-tops.co.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Mon, 16 Jun 2003 10:19:11 +0900 (JST), Atsushi Nemoto <nemoto@toshiba-tops.co.jp> said:
>>>>> On Sun, 15 Jun 2003 01:47:13 +0100, ralf@linux-mips.org said:
>> Modified files:
>> arch/mips64    : Tag: linux_2_4 Makefile 
>> include/asm-mips64: Tag: linux_2_4 processor.h r4kcache.h 

>> Log message:
>> Support GT64120 boards with 64-bit kernels also.

nemoto> This corrupts mips64/mm/c-r4k.c.  Please apply this patch also.

And I doubt that 'unsigned short' is enough for the 'waysize'
(especially for scache).  How about this?

diff -u linux-mips-cvs/include/asm-mips64/processor.h linux.new/include/asm-mips64/processor.h
--- linux-mips-cvs/include/asm-mips64/processor.h	Mon Jun 16 09:33:42 2003
+++ linux.new/include/asm-mips64/processor.h	Mon Jun 16 10:40:19 2003
@@ -50,8 +50,8 @@
 	unsigned short linesz;	/* Size of line in bytes */
 	unsigned short ways;	/* Number of ways */
 	unsigned short sets;	/* Number of lines per set */
-	unsigned short waysize;	/* Bytes per way */
-	unsigned int waybit;	/* Bits to select in a cache set */
+	unsigned short waybit;	/* Bits to select in a cache set */
+	unsigned int waysize;	/* Bytes per way */
 	unsigned int flags;	/* Flags describing cache properties */
 };
 
---
Atsushi Nemoto

From nemoto@toshiba-tops.co.jp Mon Jun 16 02:57:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Jun 2003 02:57:57 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:20745
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225205AbTFPB5z>; Mon, 16 Jun 2003 02:57:55 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for [62.254.210.162]) with SMTP; 16 Jun 2003 01:57:53 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h5G1vfiY019512;
	Mon, 16 Jun 2003 10:57:41 +0900 (JST)
	(envelope-from nemoto@toshiba-tops.co.jp)
Date: Mon, 16 Jun 2003 10:58:39 +0900 (JST)
Message-Id: <20030616.105839.71082782.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
In-Reply-To: <20030616.104224.92590182.nemoto@toshiba-tops.co.jp>
References: <20030615004718Z8225220-1272+2582@linux-mips.org>
	<20030616.101911.07647456.nemoto@toshiba-tops.co.jp>
	<20030616.104224.92590182.nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <nemoto@toshiba-tops.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2642
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nemoto@toshiba-tops.co.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Mon, 16 Jun 2003 10:42:24 +0900 (JST), Atsushi Nemoto <nemoto@toshiba-tops.co.jp> said:
>>>>> On Mon, 16 Jun 2003 10:19:11 +0900 (JST), Atsushi Nemoto <nemoto@toshiba-tops.co.jp> said:
>>>>> On Sun, 15 Jun 2003 01:47:13 +0100, ralf@linux-mips.org said:
>>> Modified files:
>>> arch/mips64    : Tag: linux_2_4 Makefile 
>>> include/asm-mips64: Tag: linux_2_4 processor.h r4kcache.h 

>>> Log message:
>>> Support GT64120 boards with 64-bit kernels also.

nemoto> This corrupts mips64/mm/c-r4k.c.  Please apply this patch also.

nemoto> And I doubt that 'unsigned short' is enough for the 'waysize'
nemoto> (especially for scache).  How about this?

Then this is a patch to sync 32-bit version.

diff -ur linux-mips-cvs/arch/mips/mm/c-r4k.c linux.new/arch/mips/mm/c-r4k.c
--- linux-mips-cvs/arch/mips/mm/c-r4k.c	Mon Apr 28 09:44:52 2003
+++ linux.new/arch/mips/mm/c-r4k.c	Mon Jun 16 10:43:21 2003
@@ -26,7 +26,6 @@
 
 /* Primary cache parameters. */
 static unsigned long icache_size, dcache_size, scache_size;
-unsigned long icache_way_size, dcache_way_size, scache_way_size;
 static unsigned long scache_size;
 
 #include <asm/cacheops.h>
@@ -848,8 +847,8 @@
 		panic("Improper R4000SC processor configuration detected");
 
 	/* compute a couple of other cache variables */
-	icache_way_size = icache_size / c->icache.ways;
-	dcache_way_size = dcache_size / c->dcache.ways;
+	c->icache.waysize = icache_size / c->icache.ways;
+	c->dcache.waysize = dcache_size / c->dcache.ways;
 
 	c->icache.sets = icache_size / (c->icache.linesz * c->icache.ways);
 	c->dcache.sets = dcache_size / (c->dcache.linesz * c->dcache.ways);
@@ -862,7 +861,7 @@
 	 */
 	if (current_cpu_data.cputype != CPU_R10000 &&
 	    current_cpu_data.cputype != CPU_R12000)
-		if (dcache_way_size > PAGE_SIZE)
+		if (c->dcache.waysize > PAGE_SIZE)
 		        c->dcache.flags |= MIPS_CACHE_ALIASES;
 
 	if (config & 0x8)		/* VI bit */
diff -ur linux-mips-cvs/arch/mips/mm/c-tx39.c linux.new/arch/mips/mm/c-tx39.c
--- linux-mips-cvs/arch/mips/mm/c-tx39.c	Tue May  6 09:40:58 2003
+++ linux.new/arch/mips/mm/c-tx39.c	Mon Jun 16 10:46:54 2003
@@ -25,9 +25,7 @@
 
 /* For R3000 cores with R4000 style caches */
 static unsigned long icache_size, dcache_size;		/* Size in bytes */
-static unsigned long icache_way_size, dcache_way_size;	/* Size divided by ways */
 #define scache_size 0
-#define scache_way_size 0
 
 #include <asm/r4kcache.h>
 
@@ -473,15 +471,15 @@
 		break;
 	}
 
-	icache_way_size = icache_size / current_cpu_data.icache.ways;
-	dcache_way_size = dcache_size / current_cpu_data.dcache.ways;
+	current_cpu_data.icache.waysize = icache_size / current_cpu_data.icache.ways;
+	current_cpu_data.dcache.waysize = dcache_size / current_cpu_data.dcache.ways;
 
 	current_cpu_data.icache.sets =
-		icache_way_size / current_cpu_data.icache.linesz;
+		current_cpu_data.icache.waysize / current_cpu_data.icache.linesz;
 	current_cpu_data.dcache.sets =
-		dcache_way_size / current_cpu_data.dcache.linesz;
+		current_cpu_data.dcache.waysize / current_cpu_data.dcache.linesz;
 
-	if (dcache_way_size > PAGE_SIZE)
+	if (current_cpu_data.dcache.waysize > PAGE_SIZE)
 		current_cpu_data.dcache.flags |= MIPS_CACHE_ALIASES;
 
 	current_cpu_data.icache.waybit = 0;
diff -ur linux-mips-cvs/arch/mips/mm/sc-rm7k.c linux.new/arch/mips/mm/sc-rm7k.c
--- linux-mips-cvs/arch/mips/mm/sc-rm7k.c	Fri Apr 18 10:23:03 2003
+++ linux.new/arch/mips/mm/sc-rm7k.c	Mon Jun 16 10:44:02 2003
@@ -20,8 +20,6 @@
 /* Secondary cache parameters. */
 #define scache_size	(256*1024)	/* Fixed to 256KiB on RM7000 */
 
-extern unsigned long icache_way_size, dcache_way_size;
-
 #include <asm/r4kcache.h>
 
 int rm7k_tcache_enabled;
diff -ur linux-mips-cvs/include/asm-mips/processor.h linux.new/include/asm-mips/processor.h
--- linux-mips-cvs/include/asm-mips/processor.h	Thu May  8 10:28:23 2003
+++ linux.new/include/asm-mips/processor.h	Mon Jun 16 10:43:04 2003
@@ -34,11 +34,12 @@
  * Descriptor for a cache
  */
 struct cache_desc {
-	unsigned short linesz;
-	unsigned short ways;
-	unsigned int sets;
-	unsigned int waybit;	/* Bits to select in a cache set */
-	unsigned int flags;	/* Flags describingcache properties */
+	unsigned short linesz;	/* Size of line in bytes */
+	unsigned short ways;	/* Number of ways */
+	unsigned short sets;	/* Number of lines per set */
+	unsigned short waybit;	/* Bits to select in a cache set */
+	unsigned int waysize;	/* Bytes per way */
+	unsigned int flags;	/* Flags describing cache properties */
 };
 
 /*
diff -ur linux-mips-cvs/include/asm-mips/r4kcache.h linux.new/include/asm-mips/r4kcache.h
--- linux-mips-cvs/include/asm-mips/r4kcache.h	Mon Apr 28 09:44:57 2003
+++ linux.new/include/asm-mips/r4kcache.h	Mon Jun 16 10:42:51 2003
@@ -140,7 +140,7 @@
 static inline void blast_dcache16(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + dcache_way_size;
+	unsigned long end = start + current_cpu_data.dcache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.dcache.waybit;
 	unsigned long ws_end = current_cpu_data.dcache.ways << 
 	                       current_cpu_data.dcache.waybit;
@@ -179,7 +179,7 @@
 static inline void blast_icache16(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + icache_way_size;
+	unsigned long end = start + current_cpu_data.icache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit;
 	unsigned long ws_end = current_cpu_data.icache.ways <<
 	                       current_cpu_data.icache.waybit;
@@ -218,7 +218,7 @@
 static inline void blast_scache16(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + scache_way_size;
+	unsigned long end = start + current_cpu_data.scache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.scache.waybit;
 	unsigned long ws_end = current_cpu_data.scache.ways << 
 	                       current_cpu_data.scache.waybit;
@@ -283,7 +283,7 @@
 static inline void blast_dcache32(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + dcache_way_size;
+	unsigned long end = start + current_cpu_data.dcache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.dcache.waybit;
 	unsigned long ws_end = current_cpu_data.dcache.ways <<
 	                       current_cpu_data.dcache.waybit;
@@ -322,7 +322,7 @@
 static inline void blast_icache32(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + icache_way_size;
+	unsigned long end = start + current_cpu_data.icache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit;
 	unsigned long ws_end = current_cpu_data.icache.ways <<
 	                       current_cpu_data.icache.waybit;
@@ -361,7 +361,7 @@
 static inline void blast_scache32(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + scache_way_size;
+	unsigned long end = start + current_cpu_data.scache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.scache.waybit;
 	unsigned long ws_end = current_cpu_data.scache.ways << 
 	                       current_cpu_data.scache.waybit;
@@ -426,7 +426,7 @@
 static inline void blast_icache64(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + icache_way_size;
+	unsigned long end = start + current_cpu_data.icache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit;
 	unsigned long ws_end = current_cpu_data.icache.ways <<
 	                       current_cpu_data.icache.waybit;
@@ -465,7 +465,7 @@
 static inline void blast_scache64(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + scache_way_size;
+	unsigned long end = start + current_cpu_data.scache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.scache.waybit;
 	unsigned long ws_end = current_cpu_data.scache.ways << 
 	                       current_cpu_data.scache.waybit;
@@ -530,7 +530,7 @@
 static inline void blast_scache128(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + scache_way_size;
+	unsigned long end = start + current_cpu_data.scache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.scache.waybit;
 	unsigned long ws_end = current_cpu_data.scache.ways << 
 	                       current_cpu_data.scache.waybit;
---
Atsushi Nemoto

From thesistarball@yahoo.com.cn Mon Jun 16 10:32:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Jun 2003 10:32:18 +0100 (BST)
Received: from smtp011.mail.yahoo.com ([IPv6:::ffff:216.136.173.31]:10507 "HELO
	smtp011.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225220AbTFPJcP>; Mon, 16 Jun 2003 10:32:15 +0100
Received: from unknown (HELO Warrior) (thesistarball@61.149.3.88 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Jun 2003 09:32:10 -0000
Date: Mon, 16 Jun 2003 17:32:40 +0800
From: "He Jin" <thesistarball@yahoo.com.cn>
To: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: bootloader problem
X-mailer: Foxmail 4.1 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20030616093215Z8225220-1272+2626@linux-mips.org>
Return-Path: <thesistarball@yahoo.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2643
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thesistarball@yahoo.com.cn
Precedence: bulk
X-list: linux-mips

Hi, everybody,

I met a problem when debuging a bootloader in IT8172G+RM5231A platform, it's like this:

the bootloader had 2 parts, the first part executes in ROM (0xbfc00000-0xbfc0xxxx) and
it move another part from ROM into SDRAM, then jump to the SDRAM entry point to continue.

In the ROM resident code, if I initialized&flushed the cache, it can jump to SDRAM entry
continue normally. However,if I comment out those cache related code and make cache disabled, 
it seems can not jump to SDRAM entry. 

Who can tell me why I must initialize&flush when cache disabled ? 

Thanks a lot!

He Jin	




From kevink@mips.com Mon Jun 16 12:11:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Jun 2003 12:11:24 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:57493 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225230AbTFPLLU>;
	Mon, 16 Jun 2003 12:11:20 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h5GBB6Ue025101;
	Mon, 16 Jun 2003 04:11:07 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA23960;
	Mon, 16 Jun 2003 04:11:04 -0700 (PDT)
Message-ID: <00da01c333f9$498b11f0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "He Jin" <thesistarball@yahoo.com.cn>, <linux-mips@linux-mips.org>
References: <20030616093215Z8225220-1272+2626@linux-mips.org>
Subject: Re: bootloader problem
Date: Mon, 16 Jun 2003 13:20:02 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="GB2312"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2644
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips


> I met a problem when debuging a bootloader in IT8172G+RM5231A platform, it's like this:
> 
> the bootloader had 2 parts, the first part executes in ROM (0xbfc00000-0xbfc0xxxx) and
> it move another part from ROM into SDRAM, then jump to the SDRAM entry point to continue.
> 
> In the ROM resident code, if I initialized&flushed the cache, it can jump to SDRAM entry
> continue normally. However,if I comment out those cache related code and make cache disabled, 
> it seems can not jump to SDRAM entry. 
> 
> Who can tell me why I must initialize&flush when cache disabled ? 

Precisely what do you mean by "cache disabled",
and what is the address of the SDRAM entry?

            Kevin K.

From Michael_Gruetzner@gmx.de Mon Jun 16 15:13:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Jun 2003 15:13:24 +0100 (BST)
Received: from imap.gmx.net ([IPv6:::ffff:213.165.64.20]:29920 "HELO
	mail.gmx.net") by linux-mips.org with SMTP id <S8225233AbTFPONW>;
	Mon, 16 Jun 2003 15:13:22 +0100
Received: (qmail 8479 invoked by uid 65534); 16 Jun 2003 14:13:15 -0000
Received: from pD9EE7482.dip.t-dialin.net (EHLO gmx.de) (217.238.116.130)
  by mail.gmx.net (mp021) with SMTP; 16 Jun 2003 16:13:15 +0200
Message-ID: <3EEDCFC1.8030305@gmx.de>
Date: Mon, 16 Jun 2003 16:10:09 +0200
From: Michael Gruetzner <Michael_Gruetzner@gmx.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030612
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Unable to compile kernel
X-Enigmail-Version: 0.74.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <Michael_Gruetzner@gmx.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: 2645
X-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_Gruetzner@gmx.de
Precedence: bulk
X-list: linux-mips

Hello,

I just downloaded kernel 2.3 from ftp-linux-mips.org. When I try to 
compile it with my cross-compiler I get the following error:

{standard input} error: symbol 'open' is already defined as "*COM*"/4

How can I fix this.

Thanks in advance.

Michael
-- 
#ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT
         2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c


From ladis@linux-mips.org Mon Jun 16 15:14:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Jun 2003 15:14:11 +0100 (BST)
Received: from ftp.ckdenergo.cz ([IPv6:::ffff:80.95.97.155]:17358 "EHLO simek")
	by linux-mips.org with ESMTP id <S8225233AbTFPOOI>;
	Mon, 16 Jun 2003 15:14:08 +0100
Received: from ladis by simek with local (Exim 3.36 #1 (Debian))
	id 19RujV-0004Lz-00
	for <linux-mips@linux-mips.org>; Mon, 16 Jun 2003 16:13:17 +0200
Date: Mon, 16 Jun 2003 16:13:07 +0200
To: linux-mips@linux-mips.org
Subject: [PATCH] cpu-probe compile fix
Message-ID: <20030616141307.GA16721@simek>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
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: 2646
X-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

I was told that Ralf is off till Friday, so I'm sending this to the list
to allow someone fix the problem. patch applies against 2.4 and 2.5
branch. once there I did also some indentation changes.


Index: arch/mips/kernel/cpu-probe.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/cpu-probe.c,v
retrieving revision 1.1.2.21
diff -u -r1.1.2.21 cpu-probe.c
--- arch/mips/kernel/cpu-probe.c	15 Jun 2003 23:35:54 -0000	1.1.2.21
+++ arch/mips/kernel/cpu-probe.c	16 Jun 2003 11:18:49 -0000
@@ -161,8 +161,8 @@
         if (config0 & (1 << 31)) {
 		/* MIPS32 or MIPS64 compliant CPU. Read Config 1 register. */
 		c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
-			MIPS_CPU_4KTLB | MIPS_CPU_COUNTER | MIPS_CPU_DIVEC |
-			MIPS_CPU_LLSC;
+			     MIPS_CPU_4KTLB | MIPS_CPU_COUNTER |
+			     MIPS_CPU_DIVEC | MIPS_CPU_LLSC;
 		config1 = read_c0_config1();
 		if (config1 & (1 << 3))
 			c->options |= MIPS_CPU_WATCH;
@@ -186,9 +186,8 @@
 		case PRID_IMP_R2000:
 			c->cputype = CPU_R2000;
 			c->isa_level = MIPS_CPU_ISA_I;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_NOFPUEX |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB |MIPS_CPU_NOFPUEX |
+				     MIPS_CPU_LLSC;
 			if (__cpu_has_fpu())
 				c->options |= MIPS_CPU_FPU;
 			c->tlbsize = 64;
@@ -202,9 +201,8 @@
 			else
 				c->cputype = CPU_R3000;
 			c->isa_level = MIPS_CPU_ISA_I;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_NOFPUEX |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX |
+				     MIPS_CPU_LLSC;
 			if (__cpu_has_fpu())
 				c->options |= MIPS_CPU_FPU;
 			c->tlbsize = 64;
@@ -216,8 +214,8 @@
 				c->cputype = CPU_R4000SC;
 			c->isa_level = MIPS_CPU_ISA_III;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                   MIPS_CPU_32FPR | MIPS_CPU_WATCH |
-			                   MIPS_CPU_VCE | MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_WATCH |
+				     MIPS_CPU_VCE | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
                 case PRID_IMP_VR41XX:
@@ -256,14 +254,13 @@
 			c->cputype = CPU_R4300;
 			c->isa_level = MIPS_CPU_ISA_III;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-					   MIPS_CPU_32FPR | MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_LLSC;
 			c->tlbsize = 32;
 			break;
 		case PRID_IMP_R4600:
 			c->cputype = CPU_R4600;
 			c->isa_level = MIPS_CPU_ISA_III;
-			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_LLSC;
+			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		#if 0
@@ -276,8 +273,7 @@
 			 */
 	 		c->cputype = CPU_R4650;
 		 	c->isa_level = MIPS_CPU_ISA_III;
-			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_LLSC;
+			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_LLSC;
 		        c->tlbsize = 48;
 			break;
 		#endif
@@ -309,75 +305,63 @@
 			c->cputype = CPU_R4700;
 			c->isa_level = MIPS_CPU_ISA_III;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_TX49:
 			c->cputype = CPU_TX49XX;
 			c->isa_level = MIPS_CPU_ISA_III;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_R5000:
 			c->cputype = CPU_R5000;
 			c->isa_level = MIPS_CPU_ISA_IV;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_R5432:
 			c->cputype = CPU_R5432;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_WATCH |
-			                           MIPS_CPU_LLSC;
+			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_WATCH | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_R5500:
 			c->cputype = CPU_R5500;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_WATCH |
-			                           MIPS_CPU_LLSC;
+			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_WATCH | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_NEVADA:
 			c->cputype = CPU_NEVADA;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_DIVEC |
-			                           MIPS_CPU_LLSC;
+			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_DIVEC | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_R6000:
 			c->cputype = CPU_R6000;
 			c->isa_level = MIPS_CPU_ISA_II;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_FPU |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_FPU |
+				     MIPS_CPU_LLSC;
 			c->tlbsize = 32;
 			break;
 		case PRID_IMP_R6000A:
 			c->cputype = CPU_R6000A;
 			c->isa_level = MIPS_CPU_ISA_II;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_FPU |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_FPU |
+				     MIPS_CPU_LLSC;
 			c->tlbsize = 32;
 			break;
 		case PRID_IMP_RM7000:
 			c->cputype = CPU_RM7000;
 			c->isa_level = MIPS_CPU_ISA_IV;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_LLSC;
 			/*
 			 * Undocumented RM7000:  Bit 29 in the info register of
 			 * the RM7000 v2.0 indicates if the TLB has 48 or 64
@@ -391,35 +375,27 @@
 		case PRID_IMP_R8000:
 			c->cputype = CPU_R8000;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_4KEX |
-				                   MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+				     MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_LLSC;
 			c->tlbsize = 384;      /* has weird TLB: 3-way x 128 */
 			break;
 		case PRID_IMP_R10000:
 			c->cputype = CPU_R10000;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_4KEX |
-				                   MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-				                   MIPS_CPU_COUNTER |
-			                           MIPS_CPU_WATCH |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+				     MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_COUNTER | MIPS_CPU_WATCH |
+				     MIPS_CPU_LLSC;
 			c->tlbsize = 64;
 			break;
 		case PRID_IMP_R12000:
 			c->cputype = CPU_R12000;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_4KEX |
-				                   MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-				                   MIPS_CPU_COUNTER |
-			                           MIPS_CPU_WATCH |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+				     MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_COUNTER | MIPS_CPU_WATCH |
+				     MIPS_CPU_LLSC;
 			c->tlbsize = 64;
 			break;
 		default:
@@ -484,35 +460,31 @@
 		case PRID_IMP_SB1:
 			c->cputype = CPU_SB1;
 			c->isa_level = MIPS_CPU_ISA_M64;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_4KEX |
-			                           MIPS_CPU_COUNTER |
-			                           MIPS_CPU_DIVEC |
-			                           MIPS_CPU_MCHECK |
-			                           MIPS_CPU_EJTAG |
-			                           MIPS_CPU_WATCH |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+				     MIPS_CPU_COUNTER | MIPS_CPU_DIVEC |
+				     MIPS_CPU_MCHECK | MIPS_CPU_EJTAG |
+				     MIPS_CPU_WATCH | MIPS_CPU_LLSC;
 #ifndef CONFIG_SB1_PASS_1_WORKAROUNDS
 			/* FPU in pass1 is known to have issues. */
 			c->options |= MIPS_CPU_FPU | MIPS_CPU_32FPR;
 #endif
 			break;
 		default:
-			mips_cpu.cputype = CPU_UNKNOWN;
+			c->cputype = CPU_UNKNOWN;
 			break;
 		}
 		break;
 
 	case PRID_COMP_SANDCRAFT:
-		switch (mips_cpu.processor_id & 0xff00) {
+		switch (c->processor_id & 0xff00) {
 		case PRID_IMP_SR71000:
-			mips_cpu.cputype = CPU_SR71000;
-			mips_cpu.isa_level = MIPS_CPU_ISA_M64;
-			mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
-                                           MIPS_CPU_4KTLB | MIPS_CPU_FPU |
-			                   MIPS_CPU_COUNTER | MIPS_CPU_MCHECK;
-			mips_cpu.scache.ways = 8;
-			mips_cpu.tlbsize = 64;
+			c->cputype = CPU_SR71000;
+			c->isa_level = MIPS_CPU_ISA_M64;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+				     MIPS_CPU_4KTLB | MIPS_CPU_FPU |
+				     MIPS_CPU_COUNTER | MIPS_CPU_MCHECK;
+			c->scache.ways = 8;
+			c->tlbsize = 64;
 			break;
 		default:
 			c->cputype = CPU_UNKNOWN;
@@ -531,7 +503,7 @@
 {
 	struct cpuinfo_mips *c = &current_cpu_data;
 
-	printk("CPU revision is: %08x\n", c->processor_id);
+	printk(KERN_INFO "CPU revision is: %08x\n", c->processor_id);
 	if (c->options & MIPS_CPU_FPU)
-		printk("FPU revision is: %08x\n", c->fpu_id);
+		printk(KERN_INFO "FPU revision is: %08x\n", c->fpu_id);
 }
Index: arch/mips64/kernel/cpu-probe.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/cpu-probe.c,v
retrieving revision 1.1.2.25
diff -u -r1.1.2.25 cpu-probe.c
--- arch/mips64/kernel/cpu-probe.c	15 Jun 2003 23:35:54 -0000	1.1.2.25
+++ arch/mips64/kernel/cpu-probe.c	16 Jun 2003 11:18:49 -0000
@@ -398,8 +398,8 @@
         if (config0 & (1 << 31)) {
 		/* MIPS32 or MIPS64 compliant CPU. Read Config 1 register. */
 		c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
-			MIPS_CPU_4KTLB | MIPS_CPU_COUNTER | MIPS_CPU_DIVEC |
-			MIPS_CPU_LLSC;
+			     MIPS_CPU_4KTLB | MIPS_CPU_COUNTER |
+			     MIPS_CPU_DIVEC | MIPS_CPU_LLSC;
 		config1 = read_c0_config1();
 		if (config1 & (1 << 3))
 			c->options |= MIPS_CPU_WATCH;
@@ -423,9 +423,8 @@
 		case PRID_IMP_R2000:
 			c->cputype = CPU_R2000;
 			c->isa_level = MIPS_CPU_ISA_I;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_NOFPUEX |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB |MIPS_CPU_NOFPUEX |
+				     MIPS_CPU_LLSC;
 			if (__cpu_has_fpu())
 				c->options |= MIPS_CPU_FPU;
 			c->tlbsize = 64;
@@ -439,9 +438,8 @@
 			else
 				c->cputype = CPU_R3000;
 			c->isa_level = MIPS_CPU_ISA_I;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_NOFPUEX |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX |
+				     MIPS_CPU_LLSC;
 			if (__cpu_has_fpu())
 				c->options |= MIPS_CPU_FPU;
 			c->tlbsize = 64;
@@ -453,8 +451,8 @@
 				c->cputype = CPU_R4000SC;
 			c->isa_level = MIPS_CPU_ISA_III;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                   MIPS_CPU_32FPR | MIPS_CPU_WATCH |
-			                   MIPS_CPU_VCE | MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_WATCH |
+				     MIPS_CPU_VCE | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
                 case PRID_IMP_VR41XX:
@@ -493,14 +491,13 @@
 			c->cputype = CPU_R4300;
 			c->isa_level = MIPS_CPU_ISA_III;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-					   MIPS_CPU_32FPR | MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_LLSC;
 			c->tlbsize = 32;
 			break;
 		case PRID_IMP_R4600:
 			c->cputype = CPU_R4600;
 			c->isa_level = MIPS_CPU_ISA_III;
-			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_LLSC;
+			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		#if 0
@@ -513,8 +510,7 @@
 			 */
 	 		c->cputype = CPU_R4650;
 		 	c->isa_level = MIPS_CPU_ISA_III;
-			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_LLSC;
+			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_LLSC;
 		        c->tlbsize = 48;
 			break;
 		#endif
@@ -546,75 +542,63 @@
 			c->cputype = CPU_R4700;
 			c->isa_level = MIPS_CPU_ISA_III;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_TX49:
 			c->cputype = CPU_TX49XX;
 			c->isa_level = MIPS_CPU_ISA_III;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_R5000:
 			c->cputype = CPU_R5000;
 			c->isa_level = MIPS_CPU_ISA_IV;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_R5432:
 			c->cputype = CPU_R5432;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_WATCH |
-			                           MIPS_CPU_LLSC;
+			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_WATCH | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_R5500:
 			c->cputype = CPU_R5500;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_WATCH |
-			                           MIPS_CPU_LLSC;
+			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_WATCH | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_NEVADA:
 			c->cputype = CPU_NEVADA;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_DIVEC |
-			                           MIPS_CPU_LLSC;
+			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_DIVEC | MIPS_CPU_LLSC;
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_R6000:
 			c->cputype = CPU_R6000;
 			c->isa_level = MIPS_CPU_ISA_II;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_FPU |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_FPU |
+				     MIPS_CPU_LLSC;
 			c->tlbsize = 32;
 			break;
 		case PRID_IMP_R6000A:
 			c->cputype = CPU_R6000A;
 			c->isa_level = MIPS_CPU_ISA_II;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_FPU |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_FPU |
+				     MIPS_CPU_LLSC;
 			c->tlbsize = 32;
 			break;
 		case PRID_IMP_RM7000:
 			c->cputype = CPU_RM7000;
 			c->isa_level = MIPS_CPU_ISA_IV;
 			c->options = R4K_OPTS | MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_LLSC;
+				     MIPS_CPU_32FPR | MIPS_CPU_LLSC;
 			/*
 			 * Undocumented RM7000:  Bit 29 in the info register of
 			 * the RM7000 v2.0 indicates if the TLB has 48 or 64
@@ -628,35 +612,27 @@
 		case PRID_IMP_R8000:
 			c->cputype = CPU_R8000;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_4KEX |
-				                   MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+				     MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_LLSC;
 			c->tlbsize = 384;      /* has weird TLB: 3-way x 128 */
 			break;
 		case PRID_IMP_R10000:
 			c->cputype = CPU_R10000;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_4KEX |
-				                   MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-				                   MIPS_CPU_COUNTER |
-			                           MIPS_CPU_WATCH |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+				     MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_COUNTER | MIPS_CPU_WATCH |
+				     MIPS_CPU_LLSC;
 			c->tlbsize = 64;
 			break;
 		case PRID_IMP_R12000:
 			c->cputype = CPU_R12000;
 			c->isa_level = MIPS_CPU_ISA_IV;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_4KEX |
-				                   MIPS_CPU_FPU |
-			                           MIPS_CPU_32FPR |
-				                   MIPS_CPU_COUNTER |
-			                           MIPS_CPU_WATCH |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+				     MIPS_CPU_FPU | MIPS_CPU_32FPR |
+				     MIPS_CPU_COUNTER | MIPS_CPU_WATCH |
+				     MIPS_CPU_LLSC;
 			c->tlbsize = 64;
 			break;
 		default:
@@ -721,35 +697,31 @@
 		case PRID_IMP_SB1:
 			c->cputype = CPU_SB1;
 			c->isa_level = MIPS_CPU_ISA_M64;
-			c->options = MIPS_CPU_TLB |
-			                           MIPS_CPU_4KEX |
-			                           MIPS_CPU_COUNTER |
-			                           MIPS_CPU_DIVEC |
-			                           MIPS_CPU_MCHECK |
-			                           MIPS_CPU_EJTAG |
-			                           MIPS_CPU_WATCH |
-			                           MIPS_CPU_LLSC;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+				     MIPS_CPU_COUNTER | MIPS_CPU_DIVEC |
+				     MIPS_CPU_MCHECK | MIPS_CPU_EJTAG |
+				     MIPS_CPU_WATCH | MIPS_CPU_LLSC;
 #ifndef CONFIG_SB1_PASS_1_WORKAROUNDS
 			/* FPU in pass1 is known to have issues. */
 			c->options |= MIPS_CPU_FPU | MIPS_CPU_32FPR;
 #endif
 			break;
 		default:
-			mips_cpu.cputype = CPU_UNKNOWN;
+			c->cputype = CPU_UNKNOWN;
 			break;
 		}
 		break;
 
 	case PRID_COMP_SANDCRAFT:
-		switch (mips_cpu.processor_id & 0xff00) {
+		switch (c->processor_id & 0xff00) {
 		case PRID_IMP_SR71000:
-			mips_cpu.cputype = CPU_SR71000;
-			mips_cpu.isa_level = MIPS_CPU_ISA_M64;
-			mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
-                                           MIPS_CPU_4KTLB | MIPS_CPU_FPU |
-			                   MIPS_CPU_COUNTER | MIPS_CPU_MCHECK;
-			mips_cpu.scache.ways = 8;
-			mips_cpu.tlbsize = 64;
+			c->cputype = CPU_SR71000;
+			c->isa_level = MIPS_CPU_ISA_M64;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+				     MIPS_CPU_4KTLB | MIPS_CPU_FPU |
+				     MIPS_CPU_COUNTER | MIPS_CPU_MCHECK;
+			c->scache.ways = 8;
+			c->tlbsize = 64;
 			break;
 		default:
 			c->cputype = CPU_UNKNOWN;
@@ -768,7 +740,7 @@
 {
 	struct cpuinfo_mips *c = &current_cpu_data;
 
-	printk("CPU revision is: %08x\n", c->processor_id);
+	printk(KERN_INFO "CPU revision is: %08x\n", c->processor_id);
 	if (c->options & MIPS_CPU_FPU)
-		printk("FPU revision is: %08x\n", c->fpu_id);
+		printk(KERN_INFO "FPU revision is: %08x\n", c->fpu_id);
 }

From ladis@linux-mips.org Mon Jun 16 15:34:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Jun 2003 15:34:05 +0100 (BST)
Received: from ftp.ckdenergo.cz ([IPv6:::ffff:80.95.97.155]:2021 "EHLO simek")
	by linux-mips.org with ESMTP id <S8225233AbTFPOeD>;
	Mon, 16 Jun 2003 15:34:03 +0100
Received: from ladis by simek with local (Exim 3.36 #1 (Debian))
	id 19Rv2n-0004mS-00
	for <linux-mips@linux-mips.org>; Mon, 16 Jun 2003 16:33:13 +0200
Date: Mon, 16 Jun 2003 16:33:03 +0200
To: linux-mips@linux-mips.org
Subject: [PATCH] kill prom_printf
Message-ID: <20030616143303.GA18363@simek>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
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: 2647
X-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

Hi,

I was told by many people that prom_printf and friends should die and
early_printk should be used instead. this patch (against 2.5) does first
part of job. compiles and works on IP22 (SNI RM200 and IP32 don't
compile anyway). Feedback appreciated, as always.


Index: arch/mips/Kconfig-shared
===================================================================
RCS file: /home/cvs/linux/arch/mips/Kconfig-shared,v
retrieving revision 1.50
diff -u -r1.50 Kconfig-shared
--- arch/mips/Kconfig-shared	16 Jun 2003 13:54:54 -0000	1.50
+++ arch/mips/Kconfig-shared	16 Jun 2003 14:26:37 -0000
@@ -679,11 +679,6 @@
 	depends on SNI_RM200_PCI || SGI_IP32
 	default y
 
-config ARC_PROMLIB
-	bool
-	depends on SNI_RM200_PCI || SGI_IP32 || SGI_IP22
-	default y
-
 config BOARD_SCACHE
 	bool
 	depends on MIPS_EV96100 || MOMENCO_OCELOT || SGI_IP22
Index: arch/mips/arc/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/arc/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- arch/mips/arc/Makefile	2 Jan 2003 14:18:47 -0000	1.9
+++ arch/mips/arc/Makefile	16 Jun 2003 14:26:37 -0000
@@ -8,5 +8,4 @@
 				   misc.o time.o tree.o
 
 obj-$(CONFIG_ARC_MEMORY)	+= memory.o
-obj-$(CONFIG_ARC_CONSOLE)	+= arc_con.o
-obj-$(CONFIG_ARC_PROMLIB)	+= promlib.o
+obj-$(CONFIG_ARC_CONSOLE)	+= console.o
Index: arch/mips/arc/arc_con.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/arc/arc_con.c,v
retrieving revision 1.10
diff -u -r1.10 arc_con.c
--- arch/mips/arc/arc_con.c	6 Jun 2003 00:15:18 -0000	1.10
+++ arch/mips/arc/arc_con.c	16 Jun 2003 14:26:37 -0000
@@ -1,50 +0,0 @@
-/*
- * Wrap-around code for a console using the
- * ARC io-routines.
- *
- * Copyright (c) 1998 Harald Koerfgen
- * Copyright (c) 2001 Ralf Baechle
- * Copyright (c) 2002 Thiemo Seufer
- */
-#include <linux/tty.h>
-#include <linux/major.h>
-#include <linux/init.h>
-#include <linux/console.h>
-#include <linux/fs.h>
-#include <asm/sgialib.h>
-
-static void prom_console_write(struct console *co, const char *s,
-			       unsigned count)
-{
-	/* Do each character */
-	while (count--) {
-		if (*s == '\n')
-			prom_putchar('\r');
-		prom_putchar(*s++);
-	}
-}
-
-static int __init prom_console_setup(struct console *co, char *options)
-{
-	return !(prom_flags & PROM_FLAG_USE_AS_CONSOLE);
-}
-
-static struct console arc_cons = {
-	.name		= "arc",
-	.write		= prom_console_write,
-	.setup		= prom_console_setup,
-	.flags		= CON_PRINTBUFFER,
-	.index		= -1,
-};
-
-/*
- *    Register console.
- */
-
-static int __init arc_console_init(void)
-{
-	register_console(&arc_cons);
-
-	return 0;
-}
-console_initcall(arc_console_init);
Index: arch/mips/arc/console.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/arc/console.c,v
retrieving revision 1.12
diff -u -r1.12 console.c
--- arch/mips/arc/console.c	2 Jul 2002 13:13:54 -0000	1.12
+++ arch/mips/arc/console.c	16 Jun 2003 14:26:37 -0000
@@ -6,7 +6,11 @@
  * Copyright (C) 1996 David S. Miller (dm@sgi.com)
  * Compability with board caches, Ulf Carlsson
  */
+
+#include <linux/console.h>
 #include <linux/kernel.h>
+#include <linux/init.h>
+
 #include <asm/sgialib.h>
 #include <asm/bcache.h>
 
@@ -20,44 +24,26 @@
  * in some way. You should be careful with them.
  */
 
-void prom_putchar(char c)
+static void arc_console_write(struct console *co, const char *s,
+			      unsigned count)
 {
-	ULONG cnt;
-	CHAR it = c;
-
-	bc_disable();
-	ArcWrite(1, &it, 1, &cnt);
-	bc_enable();
-}
+	CHAR buf[512];
+	ULONG cnt = 0;
 
-char prom_getchar(void)
-{
-	ULONG cnt;
-	CHAR c;
+	while (count--) {
+		if (*s == '\n')
+			buf[cnt++] = '\r';
+		buf[cnt++] = *s++;
+	}
 
 	bc_disable();
-	ArcRead(0, &c, 1, &cnt);
+	ArcWrite(1, &buf, cnt, &cnt);
 	bc_enable();
-
-	return c;
 }
 
-void prom_printf(char *fmt, ...)
-{
-	va_list args;
-	char ppbuf[1024];
-	char *bptr;
-
-	va_start(args, fmt);
-	vsprintf(ppbuf, fmt, args);
-
-	bptr = ppbuf;
-
-	while (*bptr != 0) {
-		if (*bptr == '\n')
-			prom_putchar('\r');
-
-		prom_putchar(*bptr++);
-	}
-	va_end(args);
-}
+struct console arc_console = {
+	.name		= "arc",
+	.write		= arc_console_write,
+	.flags		= CON_PRINTBUFFER,
+	.index		= -1,
+};
Index: arch/mips/arc/init.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/arc/init.c,v
retrieving revision 1.13
diff -u -r1.13 init.c
--- arch/mips/arc/init.c	1 Aug 2002 22:25:22 -0000	1.13
+++ arch/mips/arc/init.c	16 Jun 2003 14:26:37 -0000
@@ -12,8 +12,6 @@
 
 #include <asm/sgialib.h>
 
-#undef DEBUG_PROM_INIT
-
 /* Master romvec interface. */
 struct linux_romvec *romvec;
 int prom_argc;
@@ -28,9 +26,9 @@
 	_prom_envp = (LONG *) envp;
 
 	if (pb->magic != 0x53435241) {
-		prom_printf("Aieee, bad prom vector magic %08lx\n", pb->magic);
-		while(1)
-			;
+		printk(KERN_EMERG "Aieee, bad prom vector magic %08lx\n",
+			pb->magic);
+		while(1) ;
 	}
 
 	prom_init_cmdline();
@@ -38,10 +36,4 @@
 	printk(KERN_INFO "PROMLIB: ARC firmware Version %d Revision %d\n",
 	       pb->ver, pb->rev);
 	prom_meminit();
-
-#ifdef DEBUG_PROM_INIT
-	prom_printf("Press a key to reboot\n");
-	prom_getchar();
-	ArcEnterInteractiveMode();
-#endif
 }
Index: arch/mips/arc/memory.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/arc/memory.c,v
retrieving revision 1.24
diff -u -r1.24 memory.c
--- arch/mips/arc/memory.c	1 Aug 2002 22:25:22 -0000	1.24
+++ arch/mips/arc/memory.c	16 Jun 2003 14:26:37 -0000
@@ -112,11 +112,11 @@
 #ifdef DEBUG
 	int i = 0;
 
-	prom_printf("ARCS MEMORY DESCRIPTOR dump:\n");
+	printk(KERN_DEBUG "ARCS MEMORY DESCRIPTOR dump:\n");
 	p = ArcGetMemoryDescriptor(PROM_NULL_MDESC);
 	while(p) {
-		prom_printf("[%d,%p]: base<%08lx> pages<%08lx> type<%s>\n",
-			    i, p, p->base, p->pages, mtypes(p->type));
+		printk("[%d,%p]: base<%08lx> pages<%08lx> type<%s>\n",
+			i, p, p->base, p->pages, mtypes(p->type));
 		p = ArcGetMemoryDescriptor(p);
 		i++;
 	}
Index: arch/mips/arc/promlib.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/arc/promlib.c,v
retrieving revision 1.2
diff -u -r1.2 promlib.c
--- arch/mips/arc/promlib.c	29 Sep 2002 01:43:16 -0000	1.2
+++ arch/mips/arc/promlib.c	16 Jun 2003 14:26:37 -0000
@@ -1,43 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 1996 David S. Miller (dm@sgi.com)
- * Compability with board caches, Ulf Carlsson
- */
-#include <linux/kernel.h>
-#include <asm/sgialib.h>
-#include <asm/bcache.h>
-
-/*
- * IP22 boardcache is not compatible with board caches.  Thus we disable it
- * during romvec action.  Since r4xx0.c is always compiled and linked with your
- * kernel, this shouldn't cause any harm regardless what MIPS processor you
- * have.
- *
- * The ARC write and read functions seem to interfere with the serial lines
- * in some way. You should be careful with them.
- */
-
-void prom_putchar(char c)
-{
-	ULONG cnt;
-	CHAR it = c;
-
-	bc_disable();
-	ArcWrite(1, &it, 1, &cnt);
-	bc_enable();
-}
-
-char prom_getchar(void)
-{
-	ULONG cnt;
-	CHAR c;
-
-	bc_disable();
-	ArcRead(0, &c, 1, &cnt);
-	bc_enable();
-
-	return c;
-}
Index: arch/mips/arc/tree.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/arc/tree.c,v
retrieving revision 1.4
diff -u -r1.4 tree.c
--- arch/mips/arc/tree.c	26 Dec 2001 23:03:06 -0000	1.4
+++ arch/mips/arc/tree.c	16 Jun 2003 14:26:37 -0000
@@ -93,11 +93,11 @@
 static void __init
 dump_component(pcomponent *p)
 {
-	prom_printf("[%p]:class<%s>type<%s>flags<%s>ver<%d>rev<%d>",
-		    p, classes[p->class], types[p->type],
-		    iflags[p->iflags], p->vers, p->rev);
-	prom_printf("key<%08lx>\n\tamask<%08lx>cdsize<%d>ilen<%d>iname<%s>\n",
-		    p->key, p->amask, (int)p->cdsize, (int)p->ilen, p->iname);
+	printk(KERN_DEBUG "[%p]:class<%s>type<%s>flags<%s>ver<%d>rev<%d>",
+		p, classes[p->class], types[p->type],
+		iflags[p->iflags], p->vers, p->rev);
+	printk("key<%08lx>\n\tamask<%08lx>cdsize<%d>ilen<%d>iname<%s>\n",
+		p->key, p->amask, (int)p->cdsize, (int)p->ilen, p->iname);
 }
 
 static void __init

From macro@ds2.pg.gda.pl Mon Jun 16 16:18:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Jun 2003 16:18:54 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:14021 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225225AbTFPPSv>; Mon, 16 Jun 2003 16:18:51 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA05168;
	Mon, 16 Jun 2003 17:19:46 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 16 Jun 2003 17:19:45 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ladislav Michl <ladis@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <20030616143303.GA18363@simek>
Message-ID: <Pine.GSO.3.96.1030616165248.2112D-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2648
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 16 Jun 2003, Ladislav Michl wrote:

> I was told by many people that prom_printf and friends should die and
> early_printk should be used instead. this patch (against 2.5) does first
> part of job. compiles and works on IP22 (SNI RM200 and IP32 don't
> compile anyway). Feedback appreciated, as always.

 Hmm, strange idea -- I guess that originates from systems that have no
suitable firmware to perform such an operation at the console.  Currently
only x86_64 implements early_printk() -- if we have an implementation for
MIPS, we may consider removing the alternative.  Also prom_printf() comes
almost for free and works very early and as I see in the x86_64 version
early_printk() requires initialization of a console driver, which may be
unfortunate if debugging a problem within the driver. 

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


From quintela@trasno.org Tue Jun 17 00:31:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 00:31:33 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:63100 "EHLO
	mail.trasno.org") by linux-mips.org with ESMTP id <S8225217AbTFPXba>;
	Tue, 17 Jun 2003 00:31:30 +0100
Received: by mail.trasno.org (Postfix, from userid 1001)
	id A28677D0; Tue, 17 Jun 2003 01:31:02 +0200 (CEST)
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ladislav Michl <ladis@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@trasno.org>
In-Reply-To: <Pine.GSO.3.96.1030616165248.2112D-100000@delta.ds2.pg.gda.pl> (Maciej
 W. Rozycki's message of "Mon, 16 Jun 2003 17:19:45 +0200 (MET DST)")
References: <Pine.GSO.3.96.1030616165248.2112D-100000@delta.ds2.pg.gda.pl>
Date: Tue, 17 Jun 2003 01:31:02 +0200
Message-ID: <867k7lsiq1.fsf@trasno.mitica>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@trasno.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2649
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@trasno.org
Precedence: bulk
X-list: linux-mips

>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:

maciej> On Mon, 16 Jun 2003, Ladislav Michl wrote:
>> I was told by many people that prom_printf and friends should die and
>> early_printk should be used instead. this patch (against 2.5) does first
>> part of job. compiles and works on IP22 (SNI RM200 and IP32 don't
>> compile anyway). Feedback appreciated, as always.

maciej> Hmm, strange idea -- I guess that originates from systems that have no
maciej> suitable firmware to perform such an operation at the console.  Currently
maciej> only x86_64 implements early_printk() -- if we have an implementation for
maciej> MIPS, we may consider removing the alternative.  Also prom_printf() comes
maciej> almost for free and works very early and as I see in the x86_64 version
maciej> early_printk() requires initialization of a console driver, which may be
maciej> unfortunate if debugging a problem within the driver. 

There is at least one implementation for x86 that uses the VGA
directly (as the BIOS left it), getting it very soon.

But you are right, PC's speciality is not to have a nice console.
Anyways, you can use early_printk() in MIPS.  You only need to put the
setup of the early console sooner, as for you the setup is basically a NOP.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From joseph@omnilux.net Tue Jun 17 00:46:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 00:46:22 +0100 (BST)
Received: from mx2.idealab.com ([IPv6:::ffff:64.208.8.4]:17396 "EHLO
	butch.idealab.com") by linux-mips.org with ESMTP
	id <S8225217AbTFPXqU>; Tue, 17 Jun 2003 00:46:20 +0100
Received: (qmail 41096 invoked by uid 72); 16 Jun 2003 23:46:10 -0000
Received: from joseph@omnilux.net by butch.idealab.com with qmail-scanner-1.03 (sweep: 2.6/3.49. . Clean. Processed in 2.260541 secs); 16 Jun 2003 23:46:10 -0000
X-Qmail-Scanner-Mail-From: joseph@omnilux.net via butch.idealab.com
X-Qmail-Scanner: 1.03 (Clean. Processed in 2.260541 secs)
Received: from unknown (HELO c002079) (10.1.2.63)
  by 0 with SMTP; 16 Jun 2003 23:46:07 -0000
From: "Joseph Chiu" <joseph@omnilux.net>
To: <linux-mips@linux-mips.org>
Subject: Wired TLB entry?
Date: Mon, 16 Jun 2003 16:49:29 -0700
Message-ID: <BPEELMGAINDCONKDGDNCCEFBDMAA.joseph@omnilux.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="GB2312"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <20030616093215Z8225220-1272+2626@linux-mips.org>
Return-Path: <joseph@omnilux.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: 2650
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joseph@omnilux.net
Precedence: bulk
X-list: linux-mips

Hi,
Is there a (proper) way to add a page entry in the TLB it's always valid?
Specifically, accesses to memory-mapped hardware (PCMCIA) causes the kernel
to oops under heavy interrupt loading.
It seems to me that the page entry in the TLB is getting flushed out under
the activity; and when the ioremap'd memory region is accesses, the
exception handling for the missing translation does not run.

I'm afraid my two days of googling hasn't turned up the right information.
I think I just don't know the right terminology and I hope someone can at
least point me in the right direction.
Thanks.
Joseph
(I am running 2.4.18)


From joseph@omnilux.net Tue Jun 17 01:33:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 01:33:49 +0100 (BST)
Received: from mx2.idealab.com ([IPv6:::ffff:64.208.8.4]:203 "EHLO
	butch.idealab.com") by linux-mips.org with ESMTP
	id <S8225217AbTFQAdq>; Tue, 17 Jun 2003 01:33:46 +0100
Received: (qmail 70372 invoked by uid 72); 17 Jun 2003 00:33:39 -0000
Received: from joseph@omnilux.net by butch.idealab.com with qmail-scanner-1.03 (sweep: 2.6/3.49. . Clean. Processed in 3.303008 secs); 17 Jun 2003 00:33:39 -0000
X-Qmail-Scanner-Mail-From: joseph@omnilux.net via butch.idealab.com
X-Qmail-Scanner: 1.03 (Clean. Processed in 3.303008 secs)
Received: from unknown (HELO c002079) (10.1.2.63)
  by 0 with SMTP; 17 Jun 2003 00:33:36 -0000
From: "Joseph Chiu" <joseph@omnilux.net>
To: "Linux-MIPS" <linux-mips@linux-mips.org>
Subject: wired tlb entry?
Date: Mon, 16 Jun 2003 17:36:58 -0700
Message-ID: <BPEELMGAINDCONKDGDNCOEFBDMAA.joseph@omnilux.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Return-Path: <joseph@omnilux.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: 2651
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joseph@omnilux.net
Precedence: bulk
X-list: linux-mips

Hi,
Is there a (proper) way to add a page entry in the TLB it's always valid?
Specifically, accesses to memory-mapped hardware (PCMCIA) causes the kernel
to oops under heavy interrupt loading.
It seems to me that the page entry in the TLB is getting flushed out under
the activity; and when the ioremap'd memory region is accesses, the
exception handling for the missing translation does not run.

I'm afraid my two days of googling hasn't turned up the right information.
I think I just don't know the right terminology and I hope someone can at
least point me in the right direction.
Thanks.
Joseph
(I am running 2.4.18-mips)



--
Joseph Chiu, Senior Engineer, Omnilux, Inc.
joseph@omnilux.net  (626) 535-2819
The sun will come up tomorrow.  Bet your bottom dollar that tomorrow,
things'll be back.


From michael_e_guo@hotmail.com Tue Jun 17 04:53:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 04:53:17 +0100 (BST)
Received: from bay8-f73.bay8.hotmail.com ([IPv6:::ffff:64.4.27.73]:65295 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8224861AbTFQDxO>;
	Tue, 17 Jun 2003 04:53:14 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 16 Jun 2003 20:28:20 -0700
Received: from 159.226.39.179 by by8fd.bay8.hotmail.msn.com with HTTP;
	Tue, 17 Jun 2003 03:28:20 GMT
X-Originating-IP: [159.226.39.179]
X-Originating-Email: [michael_e_guo@hotmail.com]
From: "Guo Michael" <michael_e_guo@hotmail.com>
To: joseph@omnilux.net
Cc: linux-mips@linux-mips.org
Subject: Re: wired tlb entry?
Date: Tue, 17 Jun 2003 11:28:20 +0800
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: <BAY8-F73IhTrBoe2U8Q000490cf@hotmail.com>
X-OriginalArrivalTime: 17 Jun 2003 03:28:20.0830 (UTC) FILETIME=[803AC7E0:01C33480]
Return-Path: <michael_e_guo@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: 2652
X-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_e_guo@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi! You can use add_wired_entry(unsigned long entrylo0, unsigned long 
entrylo1, unsigned long entryhi, unsigned long pagemask);

for more information you can check include/asm-mips/pgtable.h


-Michael

>From: "Joseph Chiu" <joseph@omnilux.net>
>To: "Linux-MIPS" <linux-mips@linux-mips.org>
>Subject: wired tlb entry?
>Date: Mon, 16 Jun 2003 17:36:58 -0700
>
>Hi,
>Is there a (proper) way to add a page entry in the TLB it's always valid?
>Specifically, accesses to memory-mapped hardware (PCMCIA) causes the 
kernel
>to oops under heavy interrupt loading.
>It seems to me that the page entry in the TLB is getting flushed out under
>the activity; and when the ioremap'd memory region is accesses, the
>exception handling for the missing translation does not run.
>
>I'm afraid my two days of googling hasn't turned up the right information.
>I think I just don't know the right terminology and I hope someone can at
>least point me in the right direction.
>Thanks.
>Joseph
>(I am running 2.4.18-mips)
>
>
>
>--
>Joseph Chiu, Senior Engineer, Omnilux, Inc.
>joseph@omnilux.net  (626) 535-2819
>The sun will come up tomorrow.  Bet your bottom dollar that tomorrow,
>things'll be back.
>
>

_________________________________________________________________
ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.com  


From ladis@linux-mips.org Tue Jun 17 08:53:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 08:53:48 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@sirjeppe-pt.tunnel.tserv1.fmt.ipv6.he.net)) by linux-mips.org
	id <S8224861AbTFQHxq>; Tue, 17 Jun 2003 08:53:46 +0100
Date: Tue, 17 Jun 2003 08:53:46 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: Juan Quintela <quintela@trasno.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
Message-ID: <20030617085346.A27590@ftp.linux-mips.org>
References: <Pine.GSO.3.96.1030616165248.2112D-100000@delta.ds2.pg.gda.pl> <867k7lsiq1.fsf@trasno.mitica>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <867k7lsiq1.fsf@trasno.mitica>; from quintela@trasno.org on Tue, Jun 17, 2003 at 01:31:02AM +0200
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2653
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jun 17, 2003 at 01:31:02AM +0200, Juan Quintela wrote:
> >>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:
[snip]
> maciej> Hmm, strange idea -- I guess that originates from systems that have no
> maciej> suitable firmware to perform such an operation at the console.  Currently
> maciej> only x86_64 implements early_printk() -- if we have an implementation for
> maciej> MIPS, we may consider removing the alternative.  Also prom_printf() comes
> maciej> almost for free and works very early and as I see in the x86_64 version
> maciej> early_printk() requires initialization of a console driver, which may be
> maciej> unfortunate if debugging a problem within the driver. 
> 
> There is at least one implementation for x86 that uses the VGA
> directly (as the BIOS left it), getting it very soon.
> 
> But you are right, PC's speciality is not to have a nice console.
> Anyways, you can use early_printk() in MIPS.  You only need to put the
> setup of the early console sooner, as for you the setup is basically a NOP.

(I'm only implementing it and I don't care how good idea it is :-) Anyway
I still think that firmware should be used directly to print message before
kernel halts in situations like arch/mips/arc/init.c at line 30)

Maciej, i'll try to make some conclusion from what I was told (and Juan is
welcome to correct me if I missunderstood something)

Idea is to have only one way for printing kernel messages. In case of Indy,
O2 and SNI RM200 "arc" console will do it. Here you can find where should
be early console initialized:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105519188505235&w=2
As Juan pointed out setup for such console is actually a nop and one is
supposed to enable this feature only when debugging kernel. DEC prom console
however needs some setup to determine REX entry points. early console is
currently used on sh, alpha, x86_64 and ia64 architectures. Btw, see comment
at the top of arch/sparc/prom/printf.c

Regards, ladis

From macro@ds2.pg.gda.pl Tue Jun 17 12:46:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 12:46:38 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:24486 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTFQLqe>; Tue, 17 Jun 2003 12:46:34 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA22474;
	Tue, 17 Jun 2003 13:47:09 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 17 Jun 2003 13:47:08 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Juan Quintela <quintela@trasno.org>
cc: Ladislav Michl <ladis@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <867k7lsiq1.fsf@trasno.mitica>
Message-ID: <Pine.GSO.3.96.1030617134319.22214A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2654
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Juan Quintela wrote:

> Anyways, you can use early_printk() in MIPS.  You only need to put the
> setup of the early console sooner, as for you the setup is basically a NOP.

 Well, I would see early_printk() as advantageous if it was also capable
to leave messages in the kernel ring buffer for dmesg or klogd to fetch. 

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


From ladis@linux-mips.org Tue Jun 17 12:52:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 12:52:18 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8224861AbTFQLwQ>; Tue, 17 Jun 2003 12:52:16 +0100
Date: Tue, 17 Jun 2003 12:52:16 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Juan Quintela <quintela@trasno.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
Message-ID: <20030617125216.E27590@ftp.linux-mips.org>
References: <867k7lsiq1.fsf@trasno.mitica> <Pine.GSO.3.96.1030617134319.22214A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.3.96.1030617134319.22214A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Jun 17, 2003 at 01:47:08PM +0200
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2655
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jun 17, 2003 at 01:47:08PM +0200, Maciej W. Rozycki wrote:
> On Tue, 17 Jun 2003, Juan Quintela wrote:
> 
> > Anyways, you can use early_printk() in MIPS.  You only need to put the
> > setup of the early console sooner, as for you the setup is basically a NOP.
> 
>  Well, I would see early_printk() as advantageous if it was also capable
> to leave messages in the kernel ring buffer for dmesg or klogd to fetch. 

Ah, we probably don't understand each other. I should type EARLY_PRINTK
instead of early_printk (sorry for my lazyness, I'm usually typing in
lowercase). CONFIG_EARLY_PRINTK enables early console, you are supposed to
use printk everywhere and that way you achieve such functionality.

	ladis

From macro@ds2.pg.gda.pl Tue Jun 17 13:13:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 13:14:00 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:54696 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTFQMN6>; Tue, 17 Jun 2003 13:13:58 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA22851;
	Tue, 17 Jun 2003 14:14:56 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 17 Jun 2003 14:14:55 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ladislav Michl <ladis@linux-mips.org>
cc: Juan Quintela <quintela@trasno.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <20030617085346.A27590@ftp.linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030617134735.22214B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2656
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Ladislav Michl wrote:

> Idea is to have only one way for printing kernel messages. In case of Indy,
> O2 and SNI RM200 "arc" console will do it. Here you can find where should
> be early console initialized:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=105519188505235&w=2
> As Juan pointed out setup for such console is actually a nop and one is
> supposed to enable this feature only when debugging kernel. DEC prom console

 That's a valid point, as long as enabling it does not require a
reconfiguration.

> however needs some setup to determine REX entry points. early console is
> currently used on sh, alpha, x86_64 and ia64 architectures. Btw, see comment
> at the top of arch/sparc/prom/printf.c

 The DEC's entry points are a part of the problem only -- to support a
generic kernel, we need to move early_printk setup after setup_arch(), as
the level of variation is huge then.. 

 There is also that minor implementation problem -- how to pass varargs
from printk() to ROM's printf()?  At least the firmware of the DECstation
implements a full-featured printf() as in the C library. 

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


From macro@ds2.pg.gda.pl Tue Jun 17 13:15:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 13:15:16 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:63400 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTFQMPO>; Tue, 17 Jun 2003 13:15:14 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA22870;
	Tue, 17 Jun 2003 14:16:13 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 17 Jun 2003 14:16:12 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ladislav Michl <ladis@linux-mips.org>
cc: Juan Quintela <quintela@trasno.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <20030617125216.E27590@ftp.linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030617141524.22214C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2657
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Ladislav Michl wrote:

> >  Well, I would see early_printk() as advantageous if it was also capable
> > to leave messages in the kernel ring buffer for dmesg or klogd to fetch. 
> 
> Ah, we probably don't understand each other. I should type EARLY_PRINTK
> instead of early_printk (sorry for my lazyness, I'm usually typing in
> lowercase). CONFIG_EARLY_PRINTK enables early console, you are supposed to
> use printk everywhere and that way you achieve such functionality.

 So you need to explicitly configure it?  That's very bad.

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


From js@convergence.de Tue Jun 17 13:16:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 13:16:27 +0100 (BST)
Received: from mail.convergence.de ([IPv6:::ffff:212.84.236.4]:37343 "EHLO
	mail.convergence.de") by linux-mips.org with ESMTP
	id <S8224861AbTFQMQZ>; Tue, 17 Jun 2003 13:16:25 +0100
Received: from [10.1.1.146] (helo=heck)
	by mail.convergence.de with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.14)
	id 19SFNv-0002hS-Gm
	for linux-mips@linux-mips.org; Tue, 17 Jun 2003 14:16:23 +0200
Received: from js by heck with local (Exim 3.35 #1 (Debian))
	id 19SFNu-0000xT-00
	for <linux-mips@linux-mips.org>; Tue, 17 Jun 2003 14:16:22 +0200
Date: Tue, 17 Jun 2003 14:16:22 +0200
From: Johannes Stezenbach <js@convergence.de>
To: linux-mips@linux-mips.org
Subject: Re: Building a stand-alone FS on a very limited flash (newbie question)
Message-ID: <20030617121622.GH1215@convergence.de>
Mail-Followup-To: Johannes Stezenbach <js@convergence.de>,
	linux-mips@linux-mips.org
References: <20030610131519.47A8BC5FD7@atlas.denx.de> <3EEC9513.80905@galileo.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EEC9513.80905@galileo.co.il>
User-Agent: Mutt/1.5.4i
Return-Path: <js@convergence.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2658
X-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

Baruch Chaikin wrote:
> 
> Another question is the file system itself.  What is the recommendation 
> here - JFFS, CRAMFS, anything else?...

jffs if you need read/write, cramfs or squashfs for read-only.

stock cramfs has endianness problems (mkcramfs must run on same
endianness as kernel), but patches exist.

http://sourceforge.net/projects/squashfs/
http://sourceforge.net/projects/cramfs/

Johannes

From ladis@linux-mips.org Tue Jun 17 13:18:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 13:19:01 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8224861AbTFQMS7>; Tue, 17 Jun 2003 13:18:59 +0100
Date: Tue, 17 Jun 2003 13:18:59 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Juan Quintela <quintela@trasno.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
Message-ID: <20030617131859.A32079@ftp.linux-mips.org>
References: <20030617125216.E27590@ftp.linux-mips.org> <Pine.GSO.3.96.1030617141524.22214C-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.3.96.1030617141524.22214C-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Jun 17, 2003 at 02:16:12PM +0200
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2659
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jun 17, 2003 at 02:16:12PM +0200, Maciej W. Rozycki wrote:
> On Tue, 17 Jun 2003, Ladislav Michl wrote:
> 
> > >  Well, I would see early_printk() as advantageous if it was also capable
> > > to leave messages in the kernel ring buffer for dmesg or klogd to fetch. 
> > 
> > Ah, we probably don't understand each other. I should type EARLY_PRINTK
> > instead of early_printk (sorry for my lazyness, I'm usually typing in
> > lowercase). CONFIG_EARLY_PRINTK enables early console, you are supposed to
> > use printk everywhere and that way you achieve such functionality.
> 
>  So you need to explicitly configure it?  That's very bad.

I think we can leave it enabled by default, since it doesn't hurt too much.
Kernel cmdline argument could control usage of early console.

	ladis

From quintela@trasno.org Tue Jun 17 13:25:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 13:25:11 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:60960 "EHLO
	mail.trasno.org") by linux-mips.org with ESMTP id <S8225233AbTFQMZJ>;
	Tue, 17 Jun 2003 13:25:09 +0100
Received: by mail.trasno.org (Postfix, from userid 1001)
	id 8E9087FA; Tue, 17 Jun 2003 14:24:41 +0200 (CEST)
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ladislav Michl <ladis@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@trasno.org>
In-Reply-To: <Pine.GSO.3.96.1030617141524.22214C-100000@delta.ds2.pg.gda.pl> (Maciej
 W. Rozycki's message of "Tue, 17 Jun 2003 14:16:12 +0200 (MET DST)")
References: <Pine.GSO.3.96.1030617141524.22214C-100000@delta.ds2.pg.gda.pl>
Date: Tue, 17 Jun 2003 14:24:41 +0200
Message-ID: <86d6hcriwm.fsf@trasno.mitica>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@trasno.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2660
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@trasno.org
Precedence: bulk
X-list: linux-mips

>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:

maciej> On Tue, 17 Jun 2003, Ladislav Michl wrote:
>> >  Well, I would see early_printk() as advantageous if it was also capable
>> > to leave messages in the kernel ring buffer for dmesg or klogd to fetch. 
>> 
>> Ah, we probably don't understand each other. I should type EARLY_PRINTK
>> instead of early_printk (sorry for my lazyness, I'm usually typing in
>> lowercase). CONFIG_EARLY_PRINTK enables early console, you are supposed to
>> use printk everywhere and that way you achieve such functionality.

maciej> So you need to explicitly configure it?  That's very bad.

You bet:
- you force everybody to use early_printk (you only want it for
  debugging).
- you configure early_printk for everybody (never have to configure
  it).

You can't have the cake and eat it :(

Why do you ever will want not to use early_printk?

when you are using a console that is not the prom console (why do you
want to do that on MIPS is a misterios to me), but for other
archs/machines it make sense:

think on a machine that you now it boots to use a network console.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From jbglaw@dvmwest.gt.owl.de Tue Jun 17 13:32:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 13:32:22 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:10509 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8224861AbTFQMcU>; Tue, 17 Jun 2003 13:32:20 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 5D0654AA22; Tue, 17 Jun 2003 14:32:13 +0200 (CEST)
Date: Tue, 17 Jun 2003 14:32:13 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
Message-ID: <20030617123212.GE6353@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030617125216.E27590@ftp.linux-mips.org> <Pine.GSO.3.96.1030617141524.22214C-100000@delta.ds2.pg.gda.pl> <20030617131859.A32079@ftp.linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="KlAEzMkarCnErv5Q"
Content-Disposition: inline
In-Reply-To: <20030617131859.A32079@ftp.linux-mips.org>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
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: 2661
X-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


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

On Tue, 2003-06-17 13:18:59 +0100, Ladislav Michl <ladis@linux-mips.org>
wrote in message <20030617131859.A32079@ftp.linux-mips.org>:
> On Tue, Jun 17, 2003 at 02:16:12PM +0200, Maciej W. Rozycki wrote:
> > On Tue, 17 Jun 2003, Ladislav Michl wrote:
> >=20
> > > >  Well, I would see early_printk() as advantageous if it was also ca=
pable
> > > > to leave messages in the kernel ring buffer for dmesg or klogd to f=
etch.=20
> > >=20
> > > Ah, we probably don't understand each other. I should type EARLY_PRIN=
TK
> > > instead of early_printk (sorry for my lazyness, I'm usually typing in
> > > lowercase). CONFIG_EARLY_PRINTK enables early console, you are suppos=
ed to
> > > use printk everywhere and that way you achieve such functionality.
> >=20
> >  So you need to explicitly configure it?  That's very bad.
>=20
> I think we can leave it enabled by default, since it doesn't hurt too muc=
h.
> Kernel cmdline argument could control usage of early console.

If we constantly add (new) kernel arguments, we may at some time face
the problem that the calling PROM/firmware/whatever cannot handle a
command line which is *that* long. IIRC DECstations have a quite limited
prompt length. This hurts for "3/tftp():vmecoff root=3D/dev/ram
nfsroot=3D/nfsroot/decxxxx ip=3Dbootp console=3DttyS2 console=3Dtty0
early_printk=3Darc"

I'm just thinking about numerizing all __setup() calls so that you maybe
can use something C99 style like: .15=3D/dev/ttyS0 (where .15 is the
fiveteenth variable which is "console".

All that needs to be done are some lines at command line parsing and a
small tool/script to extract correct values and their corresponding
__setup() "name".

MfG, JBG

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

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

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

iD8DBQE+7wpMHb1edYOZ4bsRAnKdAJ420pTEHavtLT0dZJH5iN1KpGfDPQCcD4Kq
1XA9pqG7qzOyJxiBolqiAZw=
=iJI3
-----END PGP SIGNATURE-----

--KlAEzMkarCnErv5Q--

From jbglaw@dvmwest.gt.owl.de Tue Jun 17 13:43:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 13:43:19 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:15117 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8224861AbTFQMnR>; Tue, 17 Jun 2003 13:43:17 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id C32F94AA20; Tue, 17 Jun 2003 14:43:15 +0200 (CEST)
Date: Tue, 17 Jun 2003 14:43:15 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
Message-ID: <20030617124314.GF6353@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030617125216.E27590@ftp.linux-mips.org> <Pine.GSO.3.96.1030617141524.22214C-100000@delta.ds2.pg.gda.pl> <20030617131859.A32079@ftp.linux-mips.org> <20030617123212.GE6353@lug-owl.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="udcq9yAoWb9A4FsZ"
Content-Disposition: inline
In-Reply-To: <20030617123212.GE6353@lug-owl.de>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
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: 2662
X-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


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

On Tue, 2003-06-17 14:32:13 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
wrote in message <20030617123212.GE6353@lug-owl.de>:
> On Tue, 2003-06-17 13:18:59 +0100, Ladislav Michl <ladis@linux-mips.org>
> wrote in message <20030617131859.A32079@ftp.linux-mips.org>:
> > On Tue, Jun 17, 2003 at 02:16:12PM +0200, Maciej W. Rozycki wrote:
> > > On Tue, 17 Jun 2003, Ladislav Michl wrote:
> > > > >  Well, I would see early_printk() as advantageous if it was also =
capable
> > > > > to leave messages in the kernel ring buffer for dmesg or klogd to=
 fetch.=20
> >=20
> > I think we can leave it enabled by default, since it doesn't hurt too m=
uch.
> > Kernel cmdline argument could control usage of early console.
>=20
> If we constantly add (new) kernel arguments, we may at some time face
> the problem that the calling PROM/firmware/whatever cannot handle a
> command line which is *that* long. IIRC DECstations have a quite limited
> prompt length. This hurts for "3/tftp():vmecoff root=3D/dev/ram
> nfsroot=3D/nfsroot/decxxxx ip=3Dbootp console=3DttyS2 console=3Dtty0
> early_printk=3Darc"
>=20
> I'm just thinking about numerizing all __setup() calls so that you maybe
> can use something C99 style like: .15=3D/dev/ttyS0 (where .15 is the
> fiveteenth variable which is "console".

Hmmm. That's almose trivial:) ./kernel/params.c:parse_one() needs to be
tweaked a bit. The rest is a small script to tell us what's between
__start___param and __stop___param.

MfG, JBG

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

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

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

iD8DBQE+7wziHb1edYOZ4bsRAkeFAJsE+H4zSpEBo4cOUfLPJwmgUdaGUACfb5bO
pT1hGhiQPjUGrFY8wNpCy28=
=NFw2
-----END PGP SIGNATURE-----

--udcq9yAoWb9A4FsZ--

From ladis@linux-mips.org Tue Jun 17 13:45:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 13:45:12 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8224861AbTFQMpK>; Tue, 17 Jun 2003 13:45:10 +0100
Date: Tue, 17 Jun 2003 13:45:10 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Juan Quintela <quintela@trasno.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
Message-ID: <20030617134510.B32079@ftp.linux-mips.org>
References: <20030617085346.A27590@ftp.linux-mips.org> <Pine.GSO.3.96.1030617134735.22214B-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.3.96.1030617134735.22214B-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Jun 17, 2003 at 02:14:55PM +0200
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2663
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jun 17, 2003 at 02:14:55PM +0200, Maciej W. Rozycki wrote:
> On Tue, 17 Jun 2003, Ladislav Michl wrote:
> 
> > Idea is to have only one way for printing kernel messages. In case of Indy,
> > O2 and SNI RM200 "arc" console will do it. Here you can find where should
> > be early console initialized:
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=105519188505235&w=2
> > As Juan pointed out setup for such console is actually a nop and one is
> > supposed to enable this feature only when debugging kernel. DEC prom console
> 
>  That's a valid point, as long as enabling it does not require a
> reconfiguration.
> 
> > however needs some setup to determine REX entry points. early console is
> > currently used on sh, alpha, x86_64 and ia64 architectures. Btw, see comment
> > at the top of arch/sparc/prom/printf.c
> 
>  The DEC's entry points are a part of the problem only -- to support a
> generic kernel, we need to move early_printk setup after setup_arch(), as
> the level of variation is huge then.. 

yes, you'll have to do basic setup in your setup_console function...

>  There is also that minor implementation problem -- how to pass varargs
> from printk() to ROM's printf()?  At least the firmware of the DECstation
> implements a full-featured printf() as in the C library.

you are implementing early console not printf (sorry again for confusion),
so there is no need to pass varargs anywhere. btw, early_printk() as known
from other archs is supposed to die in future. printk() should be used
everywhere.

better to show patch...
(note that setup_early_printk() will be probably called before init_arch.
how to choose right early console is still open question, but as we have
not generic kernel yet, we can use same way as we are using for choosing
proper prom_printf function. this patch was included in hope that it can
show principle nothing more...)


Index: arch/mips/kernel/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/Makefile,v
retrieving revision 1.69
diff -u -r1.69 Makefile
--- arch/mips/kernel/Makefile	13 Jun 2003 13:58:30 -0000	1.69
+++ arch/mips/kernel/Makefile	17 Jun 2003 12:33:14 -0000
@@ -43,4 +43,6 @@
 
 obj-$(CONFIG_MODULES)		+= module.o
 
+obj-$(CONFIG_EARLY_PRINTK)	+= earlyprintk.o
+
 EXTRA_AFLAGS := $(CFLAGS)
Index: arch/mips/kernel/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/setup.c,v
retrieving revision 1.147
diff -u -r1.147 setup.c
--- arch/mips/kernel/setup.c	15 Jun 2003 23:42:07 -0000	1.147
+++ arch/mips/kernel/setup.c	17 Jun 2003 12:33:15 -0000
@@ -113,6 +113,8 @@
 asmlinkage void __init
 init_arch(int argc, char **argv, char **envp, int *prom_vec)
 {
+	setup_early_printk();
+
 	/* Determine which MIPS variant we are running on. */
 	cpu_probe();
 
--- /dev/null	2003-01-06 08:25:00.000000000 +0100
+++ arch/mips/kernel/earlyprintk.c	2003-06-16 09:06:12.000000000 +0200
@@ -0,0 +1,35 @@
+#include <linux/console.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/string.h>
+#include <linux/config.h>
+
+struct console *early_console = NULL;
+
+int __init setup_early_printk(void)
+{  
+#ifdef CONFIG_ARC_CONSOLE
+	{
+		extern struct console arc_console;
+		early_console = &arc_console;
+	}
+#endif
+#ifdef CONFIG_PROM_CONSOLE
+	{
+		extern struct console prom_console;
+		early_console = &prom_console;
+	}
+#endif
+
+	register_console(early_console);
+	return 0;
+}
+
+void __init disable_early_printk(void)
+{ 
+	if (!early_console)
+		return;
+
+	printk(KERN_INFO "Disabling early console...\n");
+	unregister_console(early_console);
+} 

From macro@ds2.pg.gda.pl Tue Jun 17 14:41:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 14:41:08 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:49839 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTFQNlG>; Tue, 17 Jun 2003 14:41:06 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23911;
	Tue, 17 Jun 2003 15:42:03 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 17 Jun 2003 15:42:03 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ladislav Michl <ladis@linux-mips.org>
cc: Juan Quintela <quintela@trasno.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <20030617131859.A32079@ftp.linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030617153617.22214E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2664
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Ladislav Michl wrote:

> >  So you need to explicitly configure it?  That's very bad.
> 
> I think we can leave it enabled by default, since it doesn't hurt too much.

 That's not the point -- someone will sooner or later disable it and
someone else will use that kernel and report bugs stating there is nothing
output and the kernel hangs.  And he might be unable to rebuild the kernel
for whatever reason or the rebuilt kernel will "magically" work. 

> Kernel cmdline argument could control usage of early console.

 No problem -- it's like the "debug" option today, that I can ask someone
to add to get a more detailed report (my systems use it by default). 

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


From macro@ds2.pg.gda.pl Tue Jun 17 14:43:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 14:43:45 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:62639 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTFQNnn>; Tue, 17 Jun 2003 14:43:43 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23969;
	Tue, 17 Jun 2003 15:44:32 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 17 Jun 2003 15:44:32 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Juan Quintela <quintela@trasno.org>
cc: Ladislav Michl <ladis@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <86d6hcriwm.fsf@trasno.mitica>
Message-ID: <Pine.GSO.3.96.1030617154243.22214F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2665
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Juan Quintela wrote:

> maciej> So you need to explicitly configure it?  That's very bad.
> 
> You bet:
> - you force everybody to use early_printk (you only want it for
>   debugging).
> - you configure early_printk for everybody (never have to configure
>   it).
> 
> You can't have the cake and eat it :(

 I'm not sure what you mean.  Please elaborate.

> Why do you ever will want not to use early_printk?

 I won't, but someone else certainly will.

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


From macro@ds2.pg.gda.pl Tue Jun 17 14:56:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 14:56:17 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:60336 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTFQN4P>; Tue, 17 Jun 2003 14:56:15 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA24162;
	Tue, 17 Jun 2003 15:57:13 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 17 Jun 2003 15:57:13 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <20030617123212.GE6353@lug-owl.de>
Message-ID: <Pine.GSO.3.96.1030617154535.22214H-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2666
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Jan-Benedict Glaw wrote:

> If we constantly add (new) kernel arguments, we may at some time face
> the problem that the calling PROM/firmware/whatever cannot handle a
> command line which is *that* long. IIRC DECstations have a quite limited
> prompt length. This hurts for "3/tftp():vmecoff root=/dev/ram
> nfsroot=/nfsroot/decxxxx ip=bootp console=ttyS2 console=tty0
> early_printk=arc"

 That has already been trained by the Alpha people.  I think we simply
need a bootloader capable of handling network boots -- with the REX
firmware it shouldn't be that difficult.  For disk loads I suppose it's
already handled by delo (I haven't checked).  We don't have a tape loader,
do we?

 BTW, you may omit "nfsroot=" above if you send a root path in a BOOTP
reply and also "ip=bootp" shouldn't be necessary if the causing bug was
fixed (I have a temporary patch).  The limit is 37 characters for the
"boot" variable (due to the limitation of the BBU RAM) and a bit higher
for an explicitly typed in command line (I think it's 80 characters, but I
can't remember for sure). 

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


From macro@ds2.pg.gda.pl Tue Jun 17 15:16:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 15:16:44 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:29874 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTFQOQl>; Tue, 17 Jun 2003 15:16:41 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA24437;
	Tue, 17 Jun 2003 16:17:36 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 17 Jun 2003 16:17:35 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ladislav Michl <ladis@linux-mips.org>
cc: Juan Quintela <quintela@trasno.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <20030617134510.B32079@ftp.linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030617155734.22214I-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2667
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Ladislav Michl wrote:

> >  There is also that minor implementation problem -- how to pass varargs
> > from printk() to ROM's printf()?  At least the firmware of the DECstation
> > implements a full-featured printf() as in the C library.
> 
> you are implementing early console not printf (sorry again for confusion),
> so there is no need to pass varargs anywhere. btw, early_printk() as known
> from other archs is supposed to die in future. printk() should be used
> everywhere.

 Hmm, calling the firmware for each character separately will certainly be
terribly slow, though it may be negligible as normally few messages will
be output this way.  And since the call to prom_printf() is so cheap for
the DECstation, I'm going to retain the function for real low-level
debugging, whether otherwise used or not. 

 BTW,I just realized console output via the firmware is mandatory for the
DECstation -- we have cases where the kernel is not going to be started
far enough to have any console set up because of a misconfiguration.  With
current prom_printf() implementation the reason is output to the console
and a user has a chance to know why.  With an optional early printk, he'll
just see the kernel return to the firmware for no apparent reason without
any output.

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


From Geert.Uytterhoeven@sonycom.com Tue Jun 17 15:38:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 15:39:01 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:61107 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTFQOi6>;
	Tue, 17 Jun 2003 15:38:58 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h5HEcepI023224;
	Tue, 17 Jun 2003 16:38:40 +0200 (MEST)
Date: Tue, 17 Jun 2003 16:38:39 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ladislav Michl <ladis@linux-mips.org>,
	Juan Quintela <quintela@trasno.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <Pine.GSO.3.96.1030617155734.22214I-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0306171637390.17930-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2668
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Maciej W. Rozycki wrote:
> On Tue, 17 Jun 2003, Ladislav Michl wrote:
> > >  There is also that minor implementation problem -- how to pass varargs
> > > from printk() to ROM's printf()?  At least the firmware of the DECstation
> > > implements a full-featured printf() as in the C library.
> > 
> > you are implementing early console not printf (sorry again for confusion),
> > so there is no need to pass varargs anywhere. btw, early_printk() as known
> > from other archs is supposed to die in future. printk() should be used
> > everywhere.
> 
>  Hmm, calling the firmware for each character separately will certainly be
> terribly slow, though it may be negligible as normally few messages will
> be output this way.  And since the call to prom_printf() is so cheap for
> the DECstation, I'm going to retain the function for real low-level
> debugging, whether otherwise used or not. 

kernel/printk.c doesn't call the low-level output routine for each character
separately, but passes complete strings of characters.

Gr{oetje,eeting}s,

						Geert

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

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


From macro@ds2.pg.gda.pl Tue Jun 17 15:48:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 15:48:28 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:38580 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTFQOs0>; Tue, 17 Jun 2003 15:48:26 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA24794;
	Tue, 17 Jun 2003 16:49:17 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 17 Jun 2003 16:49:17 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ladislav Michl <ladis@linux-mips.org>,
	Juan Quintela <quintela@trasno.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <Pine.GSO.4.21.0306171637390.17930-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1030617164642.22214J-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2669
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Geert Uytterhoeven wrote:

> >  Hmm, calling the firmware for each character separately will certainly be
> > terribly slow, though it may be negligible as normally few messages will
> > be output this way.  And since the call to prom_printf() is so cheap for
> > the DECstation, I'm going to retain the function for real low-level
> > debugging, whether otherwise used or not. 
> 
> kernel/printk.c doesn't call the low-level output routine for each character
> separately, but passes complete strings of characters.

 So I can just call prom_printf("%s", string), right?  This would solve
this shortcoming. 

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


From quintela@trasno.org Tue Jun 17 16:03:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 16:03:53 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:23049 "EHLO
	mail.trasno.org") by linux-mips.org with ESMTP id <S8224861AbTFQPDv>;
	Tue, 17 Jun 2003 16:03:51 +0100
Received: by mail.trasno.org (Postfix, from userid 1001)
	id BF3047D0; Tue, 17 Jun 2003 17:03:24 +0200 (CEST)
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ladislav Michl <ladis@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] kill prom_printf
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@trasno.org>
In-Reply-To: <Pine.GSO.3.96.1030617154243.22214F-100000@delta.ds2.pg.gda.pl> (Maciej
 W. Rozycki's message of "Tue, 17 Jun 2003 15:44:32 +0200 (MET DST)")
References: <Pine.GSO.3.96.1030617154243.22214F-100000@delta.ds2.pg.gda.pl>
Date: Tue, 17 Jun 2003 17:03:24 +0200
Message-ID: <86of0wiw5f.fsf@trasno.mitica>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@trasno.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2670
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@trasno.org
Precedence: bulk
X-list: linux-mips

>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:

maciej> On Tue, 17 Jun 2003, Juan Quintela wrote:
maciej> So you need to explicitly configure it?  That's very bad.
>> 
>> You bet:
>> - you force everybody to use early_printk (you only want it for
>> debugging).
>> - you configure early_printk for everybody (never have to configure
>> it).
>> 
>> You can't have the cake and eat it :(

maciej> I'm not sure what you mean.  Please elaborate.

As it is used in the other platforms:

- you setup your console (there is a console by default).
- until that console is initilized, messages are buffered.

that is clearly bad if your system stops before initializing the
console: i.e. zero output.

- early_printk to the rescue, as soon as you can print, you initialize
  the console, and begin printing.

- so far so god.

- now it is time to initialize the real console (reading
  console=<blah> ....)
- output from now one goes to the real console.

Problems:
a - you want all your messages in your console, and your console is not
  the console used by early_printk.  Some meassages dissapear, why?
  because early_printk is the default -> you don't want early_printk
  by default.uu

b - you want at least some output if the kernel hangs early -> you want
  early_printk by default.

I am not able to make happy people in the a) group or people in the b)
group, but not both at the same time with the default early_console.


I hope that now explanation is better (for sure that it is larger).

>> Why do you ever will want not to use early_printk?

maciej> I won't, but someone else certainly will.

I meaned here somebody in general, not you in particular :p

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From geert@linux-m68k.org Tue Jun 17 16:12:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 16:12:24 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:18127 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTFQPMW>;
	Tue, 17 Jun 2003 16:12:22 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h5HFC6pI026491;
	Tue, 17 Jun 2003 17:12:06 +0200 (MEST)
Date: Tue, 17 Jun 2003 17:12:06 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ladislav Michl <ladis@linux-mips.org>,
	Juan Quintela <quintela@trasno.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <Pine.GSO.3.96.1030617164642.22214J-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0306171704010.17930-100000@vervain.sonytel.be>
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: 2671
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Maciej W. Rozycki wrote:
> On Tue, 17 Jun 2003, Geert Uytterhoeven wrote:
> > >  Hmm, calling the firmware for each character separately will certainly be
> > > terribly slow, though it may be negligible as normally few messages will
> > > be output this way.  And since the call to prom_printf() is so cheap for
> > > the DECstation, I'm going to retain the function for real low-level
> > > debugging, whether otherwise used or not. 
> > 
> > kernel/printk.c doesn't call the low-level output routine for each character
> > separately, but passes complete strings of characters.
> 
>  So I can just call prom_printf("%s", string), right?  This would solve
> this shortcoming. 

More or less. The caveat is that console->write() is not called with a
NULL-terminated string, but with a pointer and a length.

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.Uytterhoeven@sonycom.com Tue Jun 17 16:13:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 16:13:47 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:62672 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTFQPNp>;
	Tue, 17 Jun 2003 16:13:45 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h5HFDbpI026698;
	Tue, 17 Jun 2003 17:13:38 +0200 (MEST)
Date: Tue, 17 Jun 2003 17:13:37 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Juan Quintela <quintela@trasno.org>
cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Ladislav Michl <ladis@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <86of0wiw5f.fsf@trasno.mitica>
Message-ID: <Pine.GSO.4.21.0306171712100.17930-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2672
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Juan Quintela wrote:
> Problems:
> a - you want all your messages in your console, and your console is not
>   the console used by early_printk.  Some meassages dissapear, why?
>   because early_printk is the default -> you don't want early_printk
>   by default.uu

No, if the `real' console has the CON_PRINTBUFFER flag set, all old buffered
messages will be sent again to that console upon registration.

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 quintela@trasno.org Tue Jun 17 16:26:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 16:26:35 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:30474 "EHLO
	mail.trasno.org") by linux-mips.org with ESMTP id <S8224861AbTFQP0d>;
	Tue, 17 Jun 2003 16:26:33 +0100
Received: by mail.trasno.org (Postfix, from userid 1001)
	id 2BF077D0; Tue, 17 Jun 2003 17:26:06 +0200 (CEST)
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Ladislav Michl <ladis@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] kill prom_printf
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@trasno.org>
In-Reply-To: <Pine.GSO.4.21.0306171712100.17930-100000@vervain.sonytel.be> (Geert
 Uytterhoeven's message of "Tue, 17 Jun 2003 17:13:37 +0200 (MEST)")
References: <Pine.GSO.4.21.0306171712100.17930-100000@vervain.sonytel.be>
Date: Tue, 17 Jun 2003 17:26:06 +0200
Message-ID: <86brwwiv3l.fsf@trasno.mitica>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@trasno.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2673
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@trasno.org
Precedence: bulk
X-list: linux-mips

>>>>> "geert" == Geert Uytterhoeven <geert@linux-m68k.org> writes:

geert> On Tue, 17 Jun 2003, Juan Quintela wrote:
>> Problems:
>> a - you want all your messages in your console, and your console is not
>> the console used by early_printk.  Some meassages dissapear, why?
>> because early_printk is the default -> you don't want early_printk
>> by default.uu

geert> No, if the `real' console has the CON_PRINTBUFFER flag set, all old buffered
geert> messages will be sent again to that console upon registration.

Didn't knew that.
Then it could be enabled by default without any adverse effect.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From macro@ds2.pg.gda.pl Tue Jun 17 17:05:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 17:05:10 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:29114 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTFQQFI>; Tue, 17 Jun 2003 17:05:08 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA25719;
	Tue, 17 Jun 2003 18:05:57 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 17 Jun 2003 18:05:57 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ladislav Michl <ladis@linux-mips.org>,
	Juan Quintela <quintela@trasno.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <Pine.GSO.4.21.0306171704010.17930-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1030617175552.22214K-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2674
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Geert Uytterhoeven wrote:

> >  So I can just call prom_printf("%s", string), right?  This would solve
> > this shortcoming. 
> 
> More or less. The caveat is that console->write() is not called with a
> NULL-terminated string, but with a pointer and a length.

 Well, I can't remember if the DEC's printf() supports "%<width>s", but
even if it doesn't, we can use a helper local buffer.

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


From ppopov@mvista.com Tue Jun 17 18:17:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 18:17:53 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:20462 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224861AbTFQRRu>;
	Tue, 17 Jun 2003 18:17:50 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA22567;
	Tue, 17 Jun 2003 10:17:44 -0700
Subject: Re: wired tlb entry?
From: Pete Popov <ppopov@mvista.com>
To: Joseph Chiu <joseph@omnilux.net>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <BPEELMGAINDCONKDGDNCOEFBDMAA.joseph@omnilux.net>
References: <BPEELMGAINDCONKDGDNCOEFBDMAA.joseph@omnilux.net>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1055870334.4383.198.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 17 Jun 2003 10:18:54 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2675
X-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 Mon, 2003-06-16 at 17:36, Joseph Chiu wrote:
> Hi,
> Is there a (proper) way to add a page entry in the TLB it's always valid?
> Specifically, accesses to memory-mapped hardware (PCMCIA) causes the kernel
> to oops under heavy interrupt loading.
> It seems to me that the page entry in the TLB is getting flushed out under
> the activity; and when the ioremap'd memory region is accesses, the
> exception handling for the missing translation does not run.
> 
> I'm afraid my two days of googling hasn't turned up the right information.
> I think I just don't know the right terminology and I hope someone can at
> least point me in the right direction.
> Thanks.
> Joseph
> (I am running 2.4.18-mips)

So is this a kernel from linux-mips.org?  Are you using the 36 bit I/O
patch in that kernel, or the pseudo-address translation hack that I
removed later? What pcmcia I/O card are you using and what tests are you
running?

Pete


From joseph@omnilux.net Tue Jun 17 19:09:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 19:09:25 +0100 (BST)
Received: from mx2.idealab.com ([IPv6:::ffff:64.208.8.4]:49846 "EHLO
	butch.idealab.com") by linux-mips.org with ESMTP
	id <S8224861AbTFQSJX>; Tue, 17 Jun 2003 19:09:23 +0100
Received: (qmail 34165 invoked by uid 72); 17 Jun 2003 18:09:15 -0000
Received: from joseph@omnilux.net by butch.idealab.com with qmail-scanner-1.03 (sweep: 2.6/3.49. . Clean. Processed in 1.551178 secs); 17 Jun 2003 18:09:15 -0000
X-Qmail-Scanner-Mail-From: joseph@omnilux.net via butch.idealab.com
X-Qmail-Scanner: 1.03 (Clean. Processed in 1.551178 secs)
Received: from unknown (HELO c002079) (10.1.2.63)
  by 0 with SMTP; 17 Jun 2003 18:09:13 -0000
From: "Joseph Chiu" <joseph@omnilux.net>
To: "Pete Popov" <ppopov@mvista.com>
Cc: "Linux MIPS mailing list" <linux-mips@linux-mips.org>
Subject: RE: wired tlb entry?
Date: Tue, 17 Jun 2003 11:12:36 -0700
Message-ID: <BPEELMGAINDCONKDGDNCCEFPDMAA.joseph@omnilux.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <1055870334.4383.198.camel@zeus.mvista.com>
Return-Path: <joseph@omnilux.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: 2676
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joseph@omnilux.net
Precedence: bulk
X-list: linux-mips

(Sorry for the double-send of the original inquiry to the list -- I actually
got bounce notices from my mailer...)

This is the kernel from almost a year ago with the changes you made to
support the 36-bit phys addr. access on the Au1xxx.
The Au1x00 PCMCIA (CS release 3.1.22) initialization maps phys_mem f80000000
to virt_io c0000000.

I am running HostAP (0.0.3) on top of this PCMCIA support, using a
Prism3-based WiFi card.

During transmit/receive activity, the hardware interrupt invokes the
prism2_interrupt() in hostap_cs.o which, in turn reads and writes from
registers using the virtual i/o address of c0000000.

Under light and moderate loading, there are no problems.  After heavy
traffic loads, the system eventually dies with accesses to address c000xxxx
(one address gets hit 95% of the time - and there were other addresses a few
other times, but always in the c000xxxx address range).

Thanks,
Joseph

-----Original Message-----
From: Pete Popov [mailto:ppopov@mvista.com]
Sent: Tuesday, June 17, 2003 10:19 AM
To: Joseph Chiu
Cc: Linux MIPS mailing list
Subject: Re: wired tlb entry?


On Mon, 2003-06-16 at 17:36, Joseph Chiu wrote:
> Hi,
> Is there a (proper) way to add a page entry in the TLB it's always valid?
> Specifically, accesses to memory-mapped hardware (PCMCIA) causes the
kernel
> to oops under heavy interrupt loading.
> It seems to me that the page entry in the TLB is getting flushed out under
> the activity; and when the ioremap'd memory region is accesses, the
> exception handling for the missing translation does not run.
>
> I'm afraid my two days of googling hasn't turned up the right information.
> I think I just don't know the right terminology and I hope someone can at
> least point me in the right direction.
> Thanks.
> Joseph
> (I am running 2.4.18-mips)

So is this a kernel from linux-mips.org?  Are you using the 36 bit I/O
patch in that kernel, or the pseudo-address translation hack that I
removed later? What pcmcia I/O card are you using and what tests are you
running?

Pete



From ppopov@mvista.com Tue Jun 17 19:15:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 19:15:37 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:51190 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224861AbTFQSPf>;
	Tue, 17 Jun 2003 19:15:35 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA25718;
	Tue, 17 Jun 2003 11:15:29 -0700
Subject: RE: wired tlb entry?
From: Pete Popov <ppopov@mvista.com>
To: Joseph Chiu <joseph@omnilux.net>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <BPEELMGAINDCONKDGDNCCEFPDMAA.joseph@omnilux.net>
References: <BPEELMGAINDCONKDGDNCCEFPDMAA.joseph@omnilux.net>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1055873800.4383.220.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 17 Jun 2003 11:16:40 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2677
X-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


Any chance you can try 2.4.21-pre4 (latest linux-mips) before we go any
further?

Pete

On Tue, 2003-06-17 at 11:12, Joseph Chiu wrote:
> (Sorry for the double-send of the original inquiry to the list -- I actually
> got bounce notices from my mailer...)
> 
> This is the kernel from almost a year ago with the changes you made to
> support the 36-bit phys addr. access on the Au1xxx.
> The Au1x00 PCMCIA (CS release 3.1.22) initialization maps phys_mem f80000000
> to virt_io c0000000.
> 
> I am running HostAP (0.0.3) on top of this PCMCIA support, using a
> Prism3-based WiFi card.
> 
> During transmit/receive activity, the hardware interrupt invokes the
> prism2_interrupt() in hostap_cs.o which, in turn reads and writes from
> registers using the virtual i/o address of c0000000.
> 
> Under light and moderate loading, there are no problems.  After heavy
> traffic loads, the system eventually dies with accesses to address c000xxxx
> (one address gets hit 95% of the time - and there were other addresses a few
> other times, but always in the c000xxxx address range).
> 
> Thanks,
> Joseph
> 
> -----Original Message-----
> From: Pete Popov [mailto:ppopov@mvista.com]
> Sent: Tuesday, June 17, 2003 10:19 AM
> To: Joseph Chiu
> Cc: Linux MIPS mailing list
> Subject: Re: wired tlb entry?
> 
> 
> On Mon, 2003-06-16 at 17:36, Joseph Chiu wrote:
> > Hi,
> > Is there a (proper) way to add a page entry in the TLB it's always valid?
> > Specifically, accesses to memory-mapped hardware (PCMCIA) causes the
> kernel
> > to oops under heavy interrupt loading.
> > It seems to me that the page entry in the TLB is getting flushed out under
> > the activity; and when the ioremap'd memory region is accesses, the
> > exception handling for the missing translation does not run.
> >
> > I'm afraid my two days of googling hasn't turned up the right information.
> > I think I just don't know the right terminology and I hope someone can at
> > least point me in the right direction.
> > Thanks.
> > Joseph
> > (I am running 2.4.18-mips)
> 
> So is this a kernel from linux-mips.org?  Are you using the 36 bit I/O
> patch in that kernel, or the pseudo-address translation hack that I
> removed later? What pcmcia I/O card are you using and what tests are you
> running?
> 
> Pete
> 
> 
> 


From joseph@omnilux.net Tue Jun 17 19:48:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Jun 2003 19:48:03 +0100 (BST)
Received: from mx2.idealab.com ([IPv6:::ffff:64.208.8.4]:19934 "EHLO
	butch.idealab.com") by linux-mips.org with ESMTP
	id <S8224861AbTFQSsA>; Tue, 17 Jun 2003 19:48:00 +0100
Received: (qmail 63686 invoked by uid 72); 17 Jun 2003 18:47:53 -0000
Received: from joseph@omnilux.net by butch.idealab.com with qmail-scanner-1.03 (sweep: 2.6/3.49. . Clean. Processed in 2.973729 secs); 17 Jun 2003 18:47:53 -0000
X-Qmail-Scanner-Mail-From: joseph@omnilux.net via butch.idealab.com
X-Qmail-Scanner: 1.03 (Clean. Processed in 2.973729 secs)
Received: from unknown (HELO c002079) (10.1.2.63)
  by 0 with SMTP; 17 Jun 2003 18:47:50 -0000
From: "Joseph Chiu" <joseph@omnilux.net>
To: "Pete Popov" <ppopov@mvista.com>
Cc: "Linux MIPS mailing list" <linux-mips@linux-mips.org>
Subject: RE: wired tlb entry?
Date: Tue, 17 Jun 2003 11:51:13 -0700
Message-ID: <BPEELMGAINDCONKDGDNCMEGADMAA.joseph@omnilux.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <1055873800.4383.220.camel@zeus.mvista.com>
Return-Path: <joseph@omnilux.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: 2678
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joseph@omnilux.net
Precedence: bulk
X-list: linux-mips

Michael Guo suggested add_wired_entry -- I'm giving that a try now.  I'm
trying to stick to "the kernel that we trust" (from the perspective here)
because I'm worried about what I end up breaking trying to take a new
kernel.

I am behind the time, though, so I'll try to test out 2.4.21-pre4 when I get
back (I'm not available to run the tests during the rest of this week).

Thanks,
Joseph

-----Original Message-----
From: Pete Popov [mailto:ppopov@mvista.com]
Sent: Tuesday, June 17, 2003 11:17 AM
To: Joseph Chiu
Cc: Linux MIPS mailing list
Subject: RE: wired tlb entry?



Any chance you can try 2.4.21-pre4 (latest linux-mips) before we go any
further?

Pete

On Tue, 2003-06-17 at 11:12, Joseph Chiu wrote:
> (Sorry for the double-send of the original inquiry to the list -- I
actually
> got bounce notices from my mailer...)
>
> This is the kernel from almost a year ago with the changes you made to
> support the 36-bit phys addr. access on the Au1xxx.
> The Au1x00 PCMCIA (CS release 3.1.22) initialization maps phys_mem
f80000000
> to virt_io c0000000.
>
> I am running HostAP (0.0.3) on top of this PCMCIA support, using a
> Prism3-based WiFi card.
>
> During transmit/receive activity, the hardware interrupt invokes the
> prism2_interrupt() in hostap_cs.o which, in turn reads and writes from
> registers using the virtual i/o address of c0000000.
>
> Under light and moderate loading, there are no problems.  After heavy
> traffic loads, the system eventually dies with accesses to address
c000xxxx
> (one address gets hit 95% of the time - and there were other addresses a
few
> other times, but always in the c000xxxx address range).
>
> Thanks,
> Joseph
>
> -----Original Message-----
> From: Pete Popov [mailto:ppopov@mvista.com]
> Sent: Tuesday, June 17, 2003 10:19 AM
> To: Joseph Chiu
> Cc: Linux MIPS mailing list
> Subject: Re: wired tlb entry?
>
>
> On Mon, 2003-06-16 at 17:36, Joseph Chiu wrote:
> > Hi,
> > Is there a (proper) way to add a page entry in the TLB it's always
valid?
> > Specifically, accesses to memory-mapped hardware (PCMCIA) causes the
> kernel
> > to oops under heavy interrupt loading.
> > It seems to me that the page entry in the TLB is getting flushed out
under
> > the activity; and when the ioremap'd memory region is accesses, the
> > exception handling for the missing translation does not run.
> >
> > I'm afraid my two days of googling hasn't turned up the right
information.
> > I think I just don't know the right terminology and I hope someone can
at
> > least point me in the right direction.
> > Thanks.
> > Joseph
> > (I am running 2.4.18-mips)
>
> So is this a kernel from linux-mips.org?  Are you using the 36 bit I/O
> patch in that kernel, or the pseudo-address translation hack that I
> removed later? What pcmcia I/O card are you using and what tests are you
> running?
>
> Pete
>
>
>



From macro@ds2.pg.gda.pl Wed Jun 18 12:51:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Jun 2003 12:51:28 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:53908 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225197AbTFRLvZ>; Wed, 18 Jun 2003 12:51:25 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA11490;
	Wed, 18 Jun 2003 13:52:19 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 18 Jun 2003 13:52:19 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ladislav Michl <ladis@linux-mips.org>,
	Juan Quintela <quintela@trasno.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] kill prom_printf
In-Reply-To: <Pine.GSO.3.96.1030617175552.22214K-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.3.96.1030618134958.10426A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2679
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 17 Jun 2003, Maciej W. Rozycki wrote:

> > More or less. The caveat is that console->write() is not called with a
> > NULL-terminated string, but with a pointer and a length.
> 
>  Well, I can't remember if the DEC's printf() supports "%<width>s", but
> even if it doesn't, we can use a helper local buffer.

 FYI, by the spec it does support the width modifier, but I can't verify
it at the run time right now.

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


From dkesselr@mmc.atmel.com Thu Jun 19 14:51:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Jun 2003 14:51:58 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:10244
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8224802AbTFSNv4>; Thu, 19 Jun 2003 14:51:56 +0100
Received: from hydra.mmc.atmel.com (hydra.mmc.atmel.com [10.127.240.58])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA29758
	for <linux-mips@linux-mips.org>; Thu, 19 Jun 2003 09:51:45 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by hydra.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA03907
	for <linux-mips@linux-mips.org>; Thu, 19 Jun 2003 09:51:44 -0400 (EDT)
X-Authentication-Warning: hydra.mmc.atmel.com: dkesselr owned process doing -bs
Date: Thu, 19 Jun 2003 09:51:44 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Message-ID: <Pine.GSO.4.44.0306190938180.3867-100000@hydra.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2680
Subject: (no subject)
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

I'm still trying to compile gcc and glibc for mips64el but am running into
significant problems. Basically, I haven't been able to completely build
anything.
My current problem is when I build glibc-2.2.5. The first error I got was
that gcc couldn't find an asm or linux header directory. So I added
links(asm,linux) to gcc-2.2.5/include that point to linux files
(linux-2.4.20.mips-linux-cvs/include/asm-mips64 and ..include/linux). Next
run I got the following. It looks obscure to me since during the configure
I didn't specify any particular processor options.
The mips64el-linux-gcc that I'm using is the binary from Majick's
website.(Sorry if I misspelled.)
 If you can help, I'd greatly appreciate it.

And if you have any idea why, when building gcc, I get an error saying
that -EL is not a valid option for as, please let me know. I searched the
code for options being passed to the assembler or something pointing to a
mips as instead of the host 386 as, but have been unsuccessful.

Thanks,
David Kesselring

 ----------------------------------------------------------
mips64el-linux-gcc ../sysdeps/unix/sysv/linux/mips/sysdep.S -c
-I../include -I. -I/home/dkesselr/MIPS/gcc-src/mips64el-glibc/csu -I..
-I../libio  -I/home/dkesselr/MIPS/gcc-src/mips64el-glibc
-I../sysdeps/mips/elf -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
-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 -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/mips/mips64 -I../sysdeps/wordsize-64
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64
-I../sysdeps/mips/fpu -I../sysdeps/mips -I../sysdeps/wordsize-32
-I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic
-D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC
-DHAVE_INITFINI -DASSEMBLER
-I/home/dkesselr/MIPS/gcc-src/mips64el-glibc/csu/.  -o
/home/dkesselr/MIPS/gcc-src/mips64el-glibc/csu/sysdep.o
../sysdeps/unix/mips/sysdep.S: Assembler messages:
../sysdeps/unix/mips/sysdep.S:55: Error: Macro needs a temporary register
due to `nodaddi' while $at is already in use
make[2]: *** [/home/dkesselr/MIPS/gcc-src/mips64el-glibc/csu/sysdep.o]
Error 1
make[2]: Leaving directory `/home/dkesselr/MIPS/gcc-src/glibc-2.2.5/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory `/home/dkesselr/MIPS/gcc-src/glibc-2.2.5'
make: *** [all] Error 2
-----------------------------------------------------------------



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


From nicholse@sdf.lonestar.org Thu Jun 19 09:09:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Jun 2003 09:04:37 +0100 (BST)
Received: from ol.freeshell.org ([IPv6:::ffff:192.94.73.20]:503 "EHLO
	sdf.lonestar.org") by linux-mips.org with ESMTP id <S8224802AbTFSIJO>;
	Thu, 19 Jun 2003 09:09:14 +0100
Received: from webmail.freeshell.org (IDENT:nobody@norge.freeshell.org [192.94.73.3])
	by sdf.lonestar.org (8.12.9/8.12.8) with SMTP id h5J88r64008379
	for <linux-mips@linux-mips.org>; Thu, 19 Jun 2003 08:08:53 GMT
Received: from ac8e253e.ipt.aol.com ([172.142.37.62])
        (SquirrelMail authenticated user nicholse)
        by webmail.freeshell.org with HTTP;
        Thu, 19 Jun 2003 01:08:53 -0700 (PDT)
Message-ID: <33747.172.142.37.62.1056010133.squirrel@webmail.freeshell.org>
Date: Thu, 19 Jun 2003 01:08:53 -0700 (PDT)
Subject: Sony WebTV Nevada rm5230-167q
From: nicholse@sdf.lonestar.org
To: linux-mips@linux-mips.org
Reply-To: nicholse@sdf.lonestar.org
User-Agent: SquirrelMail/1.4.0
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
X-Priority: 3
Importance: Normal
Return-Path: <nicholse@sdf.lonestar.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2681
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: nicholse@sdf.lonestar.org
Precedence: bulk
X-list: linux-mips

linux-mips@linux-mips.org
Sony WebTV Nevada rm5230-167q
What kind of work would it require to bootstrap the kernel from Sony WebTV
Pro Model INT-W200, 167MHz, the modem is a 56K flex, 8megs of RAM, a IDE
Seagate 1.1 GB hardrive and there is a cable/TV tuner. This unit has a
WebTV Port (SCSI?). The drives partitions are not recognized by fdisk. The
keyboard is IRDA, no external ps2 port but solder connections to put one
in. Should I try to read the bootsector hexdata? Could we burn a new ROM?
How would I do a ROM dump? QED Quantum website inst avaliable, are there
docs and specs?
This should be fun...
Eric

From nicholse@sdf.lonestar.org Thu Jun 19 10:23:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Jun 2003 09:05:50 +0100 (BST)
Received: from ol.freeshell.org ([IPv6:::ffff:192.94.73.20]:63725 "EHLO
	sdf.lonestar.org") by linux-mips.org with ESMTP id <S8224802AbTFSJXr>;
	Thu, 19 Jun 2003 10:23:47 +0100
Received: from webmail.freeshell.org (IDENT:nobody@norge.freeshell.org [192.94.73.3])
	by sdf.lonestar.org (8.12.9/8.12.8) with SMTP id h5J9NR8O018283
	for <linux-mips@linux-mips.org>; Thu, 19 Jun 2003 09:23:27 GMT
Received: from ac8e253e.ipt.aol.com ([172.142.37.62])
        (SquirrelMail authenticated user nicholse)
        by webmail.freeshell.org with HTTP;
        Thu, 19 Jun 2003 02:23:27 -0700 (PDT)
Message-ID: <33820.172.142.37.62.1056014607.squirrel@webmail.freeshell.org>
Date: Thu, 19 Jun 2003 02:23:27 -0700 (PDT)
Subject: Sony WebTV Nevada rm5230-167q
From: nicholse@sdf.lonestar.org
To: linux-mips@linux-mips.org
Reply-To: nicholse@sdf.lonestar.org
User-Agent: SquirrelMail/1.4.0
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
X-Priority: 3
Importance: Normal
Return-Path: <nicholse@sdf.lonestar.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2682
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: nicholse@sdf.lonestar.org
Precedence: bulk
X-list: linux-mips

Spelling/Grammer
If your serious, here is some feedback on spelling grammer.
http://linux.junsun.net/porting-howto/
do a grep diff on these lines
--
You can find much help on this if you are not very comfortable.
Most of the stuff is being moved
may leave bugs there for quite a long time
 and the machine used to
Kgdb can be enormously helpful for your development. Definitely recommended.
--
I can start at chapter two tomorrow if you really want the practice.

My needs:
linux-mips@linux-mips.org
Sony WebTV Nevada rm5230-167q
What kind of work would it require to bootstrap the kernel from Sony WebTV
Pro Model INT-W200, 167MHz, the modem is a 56K flex, 8megs of RAM, a IDE
Seagate 1.1 GB hardrive and there is a cable/TV tuner. This unit has a
WebTV Port (SCSI?). The drives partitions are not recognized by fdisk. The
keyboard is IRDA, no external ps2 port but solder connections to put one
in. Should I try to read the bootsector hexdata? Could we burn a new ROM?
How would I do a ROM dump? QED Quantum website inst avaliable, are there
docs and specs?
This should be fun...
Eric



From adeelm@enabtech.com Fri Jun 20 10:08:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Jun 2003 10:08:03 +0100 (BST)
Received: from 168-215-210-130.gen.twtelecom.net ([IPv6:::ffff:168.215.210.130]:32137
	"EHLO avaznet.com") by linux-mips.org with ESMTP
	id <S8224802AbTFTJIB>; Fri, 20 Jun 2003 10:08:01 +0100
Received: from adeel ([172.16.1.196])
	by avaznet.com (8.9.3/8.9.3) with SMTP id CAA03784
	for <linux-mips@linux-mips.org>; Fri, 20 Jun 2003 02:14:42 -0700 (PDT)
Reply-To: <adeelm@avaznet.com>
From: "Adeel Malik" <adeelm@avaznet.com>
To: <linux-mips@linux-mips.org>
Subject: Getting Started Information required
Date: Fri, 20 Jun 2003 14:03:00 +0500
Message-ID: <001d01c3370a$c0dcead0$620aa8c0@enabtech>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01C33734.A9B2F2D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Return-Path: <adeelm@enabtech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2683
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: adeelm@avaznet.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

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

Hi All,
         I am new to this list. I have done the embedded development work
for MIPS32 processors on Windows Platform using the toolchain from Green
Hills Inc. Now I have to undertake the Embedded Linux Development work using
SDE Tool from Alorithmics Ltd. I have also got reference design board from
Quick Logic Inc. Can some one give me the information regarding the basics
of Embedded Linux Development ( what are the tools and steps required to
build the kernel and download on the board, via Linux Environment).

Regards,
ADEEL MALIK
DESIGN ENGINEER,
COMMUNICATIONS ENABLING TECHNOLOGIES



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

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


<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY style=3D"COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=3D385535308-20062003><FONT size=3D2>Hi =
All,</FONT></SPAN></DIV>
<DIV><SPAN class=3D385535308-20062003><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am new to =
this list. I=20
have done the embedded development work&nbsp;for MIPS32 processors on =
Windows=20
Platform using the toolchain from Green Hills Inc. Now I have to =
undertake the=20
Embedded Linux Development work using SDE Tool from Alorithmics Ltd. I =
have also=20
got reference design board from Quick Logic Inc. Can some one&nbsp;give =
me the=20
information regarding the basics of Embedded Linux Development ( what =
are the=20
tools and steps required to build the kernel and download on the board, =
via=20
Linux Environment).</FONT></SPAN></DIV>
<DIV><SPAN class=3D385535308-20062003><FONT =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D385535308-20062003><FONT =
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV class=3DSection1>
<P><SPAN><FONT face=3DGeorgia color=3D#0000ff size=3D2><EM>ADEEL MALIK =
<BR>DESIGN=20
ENGINEER, <BR>COMMUNICATIONS ENABLING =
TECHNOLOGIES</EM></FONT></SPAN></P></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001E_01C33734.A9B2F2D0--


From chenio@libero.it Fri Jun 20 12:20:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Jun 2003 12:20:18 +0100 (BST)
Received: from smtp2.libero.it ([IPv6:::ffff:193.70.192.52]:9869 "EHLO
	smtp2.libero.it") by linux-mips.org with ESMTP id <S8224802AbTFTLUQ>;
	Fri, 20 Jun 2003 12:20:16 +0100
Received: from keniowins (151.24.217.171) by smtp2.libero.it (7.0.012)
        id 3E9BEBC3016C3BA8 for linux-mips@linux-mips.org; Fri, 20 Jun 2003 13:20:08 +0200
From: "kenio" <chenio@libero.it>
To: <linux-mips@linux-mips.org>
Subject: info...
Date: Fri, 20 Jun 2003 13:21:36 +0200
Message-ID: <BAEMJAJODKAHABOIHOBKIEOLCBAA.chenio@libero.it>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Return-Path: <chenio@libero.it>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2684
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chenio@libero.it
Precedence: bulk
X-list: linux-mips

Hello

I would like to install a linux operating system on my RM600E (Siemens).

I downloaded a linux debian distribution for mips processor, but I have some
problems to start the installation from CDROM, I can't put from CDROM
because i get the following error.

this is the command

boot2: bot -f cd(0,0,10)path_for_image_file

the system cannot start the CDROM.

Can you help me?

thanks


From brm@murphy.dk Fri Jun 20 18:02:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Jun 2003 18:02:47 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:44843
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8224802AbTFTRCp>; Fri, 20 Jun 2003 18:02:45 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 19TPHY-0002ih-00; Fri, 20 Jun 2003 19:02:36 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.4] cpu-probe.c error
Cc: linux-mips@linux-mips.org
Message-Id: <E19TPHY-0002ih-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Fri, 20 Jun 2003 19:02:36 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2685
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi Ralf,
	the latest change to cpu-probe.c requires a mips_cpu
variable which no longer exists. I presume you meant the following.

/Brian

Index: arch/mips/kernel/cpu-probe.c
===================================================================
RCS file: /cvs/linux/arch/mips/kernel/cpu-probe.c,v
retrieving revision 1.1.2.21
diff -u -r1.1.2.21 cpu-probe.c
--- arch/mips/kernel/cpu-probe.c	15 Jun 2003 23:35:54 -0000	1.1.2.21
+++ arch/mips/kernel/cpu-probe.c	20 Jun 2003 16:59:16 -0000
@@ -498,21 +498,21 @@
 #endif
 			break;
 		default:
-			mips_cpu.cputype = CPU_UNKNOWN;
+			c->cputype = CPU_UNKNOWN;
 			break;
 		}
 		break;
 
 	case PRID_COMP_SANDCRAFT:
-		switch (mips_cpu.processor_id & 0xff00) {
+		switch (c->processor_id & 0xff00) {
 		case PRID_IMP_SR71000:
-			mips_cpu.cputype = CPU_SR71000;
-			mips_cpu.isa_level = MIPS_CPU_ISA_M64;
-			mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
+			c->cputype = CPU_SR71000;
+			c->isa_level = MIPS_CPU_ISA_M64;
+			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
                                            MIPS_CPU_4KTLB | MIPS_CPU_FPU |
 			                   MIPS_CPU_COUNTER | MIPS_CPU_MCHECK;
-			mips_cpu.scache.ways = 8;
-			mips_cpu.tlbsize = 64;
+			c->scache.ways = 8;
+			c->tlbsize = 64;
 			break;
 		default:
 			c->cputype = CPU_UNKNOWN;

From ppopov@mvista.com Fri Jun 20 18:08:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Jun 2003 18:08:15 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:57585 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224802AbTFTRIN>;
	Fri, 20 Jun 2003 18:08:13 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA09362;
	Fri, 20 Jun 2003 10:08:01 -0700
Subject: Re: [PATCH 2.4] cpu-probe.c error
From: Pete Popov <ppopov@mvista.com>
To: Brian Murphy <brm@murphy.dk>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <E19TPHY-0002ih-00@brian.localnet>
References: <E19TPHY-0002ih-00@brian.localnet>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1056128905.10307.4.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 20 Jun 2003 10:08:25 -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: 2686
X-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


FYI, I had tried the same patch and it works fine on my boards. I think
mips64 may be broken as well, if I remember correctly.

Pete

On Fri, 2003-06-20 at 10:02, Brian Murphy wrote:
> Hi Ralf,
> 	the latest change to cpu-probe.c requires a mips_cpu
> variable which no longer exists. I presume you meant the following.
> 
> /Brian
> 
> Index: arch/mips/kernel/cpu-probe.c
> ===================================================================
> RCS file: /cvs/linux/arch/mips/kernel/cpu-probe.c,v
> retrieving revision 1.1.2.21
> diff -u -r1.1.2.21 cpu-probe.c
> --- arch/mips/kernel/cpu-probe.c	15 Jun 2003 23:35:54 -0000	1.1.2.21
> +++ arch/mips/kernel/cpu-probe.c	20 Jun 2003 16:59:16 -0000
> @@ -498,21 +498,21 @@
>  #endif
>  			break;
>  		default:
> -			mips_cpu.cputype = CPU_UNKNOWN;
> +			c->cputype = CPU_UNKNOWN;
>  			break;
>  		}
>  		break;
>  
>  	case PRID_COMP_SANDCRAFT:
> -		switch (mips_cpu.processor_id & 0xff00) {
> +		switch (c->processor_id & 0xff00) {
>  		case PRID_IMP_SR71000:
> -			mips_cpu.cputype = CPU_SR71000;
> -			mips_cpu.isa_level = MIPS_CPU_ISA_M64;
> -			mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
> +			c->cputype = CPU_SR71000;
> +			c->isa_level = MIPS_CPU_ISA_M64;
> +			c->options = MIPS_CPU_TLB | MIPS_CPU_4KEX |
>                                             MIPS_CPU_4KTLB | MIPS_CPU_FPU |
>  			                   MIPS_CPU_COUNTER | MIPS_CPU_MCHECK;
> -			mips_cpu.scache.ways = 8;
> -			mips_cpu.tlbsize = 64;
> +			c->scache.ways = 8;
> +			c->tlbsize = 64;
>  			break;
>  		default:
>  			c->cputype = CPU_UNKNOWN;
> 
> 


From brm@murphy.dk Fri Jun 20 22:04:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Jun 2003 22:04:39 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:64555
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8224802AbTFTVEh>; Fri, 20 Jun 2003 22:04:37 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 19TT3b-00074n-00; Fri, 20 Jun 2003 23:04:27 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.5] lasat updates
Cc: linux-mips@linux-mips.org
Message-Id: <E19TT3b-00074n-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Fri, 20 Jun 2003 23:04:27 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2687
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi Ralf,
This patch fixes up the Lasat code so it works as well as 
before the latest chain of updates (which is not quite).
The patch to the PCI code is necessary because I stupidly
copied the code from the mips-boards code which also has the
same problem (writes of full 32 bit words are ignored). 
The people who made pci-sb1250.c seem to have 
made the same error too...

/Brian

Index: arch/mips/lasat/Makefile
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- arch/mips/lasat/Makefile	2 Jun 2003 10:48:37 -0000	1.7
+++ arch/mips/lasat/Makefile	20 Jun 2003 17:04:45 -0000
@@ -12,7 +12,5 @@
 obj-$(CONFIG_PICVUE) += picvue.o
 obj-$(CONFIG_PICVUE_PROC) += picvue_proc.o
 
-obj-$(CONFIG_PCI) += pci.o
-
 clean:
 	make -C image clean
Index: arch/mips/lasat/lasat_board.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/lasat_board.c,v
retrieving revision 1.3
diff -u -r1.3 lasat_board.c
--- arch/mips/lasat/lasat_board.c	25 Feb 2003 22:39:02 -0000	1.3
+++ arch/mips/lasat/lasat_board.c	20 Jun 2003 19:04:15 -0000
@@ -24,6 +24,7 @@
  * Routines specific to the LASAT boards
  */
 #include <linux/types.h>
+#include <linux/crc32.h>
 #include <asm/lasat/lasat.h>
 #include <linux/kernel.h>
 #include <linux/string.h>
@@ -33,9 +34,11 @@
 #include "at93c.h"
 /* New model description table */
 #include "lasat_models.h"
+
+#define EEPROM_CRC(data, len) (~0 ^ crc32(~0, data, len))
+
 struct lasat_info lasat_board_info;
 
-unsigned long crc32(unsigned long, unsigned char *, int);
 void update_bcastaddr(void);
 
 int EEPROMRead(unsigned int pos, unsigned char *data, int len)
@@ -109,7 +112,7 @@
 		   sizeof(struct lasat_eeprom_struct));
 
 	/* Check the CRC */
-	crc = crc32(0x0, (unsigned char *)(&lasat_board_info.li_eeprom_info),
+	crc = EEPROM_CRC((unsigned char *)(&lasat_board_info.li_eeprom_info),
 		    sizeof(struct lasat_eeprom_struct) - 4);
 
 	if (crc != lasat_board_info.li_eeprom_info.crc32) {
@@ -268,7 +271,7 @@
 	unsigned long crc;
 
 	/* Generate the CRC */
-	crc = crc32(0x0, (unsigned char *)(&lasat_board_info.li_eeprom_info),
+	crc = EEPROM_CRC((unsigned char *)(&lasat_board_info.li_eeprom_info),
 		    sizeof(struct lasat_eeprom_struct) - 4);
 	lasat_board_info.li_eeprom_info.crc32 = crc;
 
Index: arch/mips/lasat/image/Makefile
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/image/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- arch/mips/lasat/image/Makefile	25 Feb 2003 22:39:02 -0000	1.5
+++ arch/mips/lasat/image/Makefile	20 Jun 2003 20:55:59 -0000
@@ -27,15 +27,17 @@
 
 obj-y = head.o kImage.o
 
-rom.sw:	rom.bin
+rom.sw:	$(obj)/rom.sw
+
+$(obj)/rom.sw:	$(obj)/rom.bin
 	$(MKLASATIMG) -o $@ -k $^ -m $(MKLASATIMG_ARCH)
 
-rom.bin: $(obj)/rom
-	$(OBJCOPY) -O binary -S rom rom.bin
+$(obj)/rom.bin: $(obj)/rom
+	$(OBJCOPY) -O binary -S $^ $@
 
 # Rule to make the bootloader
 $(obj)/rom: $(addprefix $(obj)/,$(obj-y))
-	$(LD) $(LDFLAGS) $(LDSCRIPT) -o rom $^
+	$(LD) $(LDFLAGS) $(LDSCRIPT) -o $@ $^
 
 $(obj)/%.o: $(obj)/%.gz
 	$(LD) -r -o $@ -b binary $<
Index: arch/mips/pci/pci-lasat.c
===================================================================
RCS file: /cvs/linux/arch/mips/pci/pci-lasat.c,v
retrieving revision 1.2
diff -u -r1.2 pci-lasat.c
--- arch/mips/pci/pci-lasat.c	13 Jun 2003 14:19:56 -0000	1.2
+++ arch/mips/pci/pci-lasat.c	20 Jun 2003 20:50:36 -0000
@@ -152,7 +152,7 @@
 		/* Error occured */
 #ifdef DEBUG_PCI
 		printk("\terror %x at adr %x\n", err,
-		       vrc_pciregs[LO(PCIERR)]);
+		       vrc_pciregs[LO(NILE4_PCIERR)]);
 #endif
 		return -1;
 	}
@@ -204,6 +204,8 @@
 	else if (size == 2)
 		data = (data & ~(0xffff << ((where & 3) << 3))) |
 		    (val << ((where & 3) << 3));
+	else
+		data = val;
 
 	if (lasat_pcibios_config_access
 	    (PCI_ACCESS_WRITE, bus, devfn, where, &data))
Index: arch/mips/defconfig-lasat200
===================================================================
RCS file: /cvs/linux/arch/mips/defconfig-lasat200,v
retrieving revision 1.51
diff -u -r1.51 defconfig-lasat200
--- arch/mips/defconfig-lasat200	16 Jun 2003 01:04:44 -0000	1.51
+++ arch/mips/defconfig-lasat200	20 Jun 2003 21:02:33 -0000
@@ -117,7 +117,7 @@
 #
 CONFIG_PCI=y
 CONFIG_PCI_LEGACY_PROC=y
-CONFIG_PCI_NAMES=y
+# CONFIG_PCI_NAMES is not set
 CONFIG_MMU=y
 # CONFIG_HOTPLUG is not set
 
@@ -142,8 +142,7 @@
 # User Modules And Translation Layers
 #
 CONFIG_MTD_CHAR=y
-# CONFIG_MTD_BLOCK is not set
-CONFIG_MTD_BLOCK_RO=y
+CONFIG_MTD_BLOCK=y
 # CONFIG_FTL is not set
 # CONFIG_NFTL is not set
 
@@ -227,7 +226,7 @@
 #
 # CONFIG_BLK_DEV_HD is not set
 CONFIG_BLK_DEV_IDEDISK=y
-# CONFIG_IDEDISK_MULTI_MODE is not set
+CONFIG_IDEDISK_MULTI_MODE=y
 # CONFIG_IDEDISK_STROKE is not set
 # CONFIG_BLK_DEV_IDECD is not set
 # CONFIG_BLK_DEV_IDEFLOPPY is not set
@@ -236,7 +235,41 @@
 #
 # IDE chipset support/bugfixes
 #
-# CONFIG_BLK_DEV_IDEPCI is not set
+CONFIG_BLK_DEV_IDEPCI=y
+CONFIG_BLK_DEV_GENERIC=y
+# CONFIG_IDEPCI_SHARE_IRQ is not set
+CONFIG_BLK_DEV_IDEDMA_PCI=y
+# CONFIG_BLK_DEV_IDE_TCQ is not set
+# CONFIG_BLK_DEV_OFFBOARD is not set
+# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
+CONFIG_IDEDMA_PCI_AUTO=y
+# CONFIG_IDEDMA_ONLYDISK is not set
+CONFIG_BLK_DEV_IDEDMA=y
+# CONFIG_IDEDMA_PCI_WIP is not set
+CONFIG_BLK_DEV_ADMA=y
+# CONFIG_BLK_DEV_AEC62XX is not set
+# CONFIG_BLK_DEV_ALI15X3 is not set
+# CONFIG_BLK_DEV_AMD74XX is not set
+CONFIG_BLK_DEV_CMD64X=y
+# CONFIG_BLK_DEV_TRIFLEX is not set
+# CONFIG_BLK_DEV_CY82C693 is not set
+# CONFIG_BLK_DEV_CS5520 is not set
+# CONFIG_BLK_DEV_HPT34X is not set
+# CONFIG_BLK_DEV_HPT366 is not set
+# CONFIG_BLK_DEV_SC1200 is not set
+# CONFIG_BLK_DEV_PIIX is not set
+# CONFIG_BLK_DEV_NS87415 is not set
+# CONFIG_BLK_DEV_OPTI621 is not set
+# CONFIG_BLK_DEV_PDC202XX_OLD is not set
+# CONFIG_BLK_DEV_PDC202XX_NEW is not set
+# CONFIG_BLK_DEV_SVWKS is not set
+# CONFIG_BLK_DEV_SIIMAGE is not set
+# CONFIG_BLK_DEV_SLC90E66 is not set
+# CONFIG_BLK_DEV_TRM290 is not set
+# CONFIG_BLK_DEV_VIA82CXXX is not set
+CONFIG_IDEDMA_AUTO=y
+# CONFIG_IDEDMA_IVB is not set
+CONFIG_BLK_DEV_IDE_MODES=y
 
 #
 # SCSI device support
@@ -546,9 +579,7 @@
 # Pseudo filesystems
 #
 CONFIG_PROC_FS=y
-CONFIG_DEVFS_FS=y
-# CONFIG_DEVFS_MOUNT is not set
-# CONFIG_DEVFS_DEBUG is not set
+# CONFIG_DEVFS_FS is not set
 CONFIG_DEVPTS_FS=y
 CONFIG_DEVPTS_FS_XATTR=y
 CONFIG_DEVPTS_FS_SECURITY=y

From brm@murphy.dk Fri Jun 20 22:40:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Jun 2003 22:40:44 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:2092
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225213AbTFTVkm>; Fri, 20 Jun 2003 22:40:42 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 19TTca-0007WN-00; Fri, 20 Jun 2003 23:40:36 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.5] ide.h fix(es)
Cc: linux-mips@linux-mips.org
Message-Id: <E19TTca-0007WN-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Fri, 20 Jun 2003 23:40:36 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2688
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi Ralf,
this fixes some problems with undefined symbols in IDE and also
seems to work (as far as my limited testing can go at the moment).
Sorry if I was out of order in removing the big endian stuff, 
I just couldn't see the point.

/Brian

Index: include/asm-mips/ide.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/ide.h,v
retrieving revision 1.21
diff -u -r1.21 ide.h
--- include/asm-mips/ide.h	3 Nov 2002 22:02:29 -0000	1.21
+++ include/asm-mips/ide.h	20 Jun 2003 21:36:59 -0000
@@ -64,28 +64,10 @@
 #endif
 }
 
-#ifdef __BIG_ENDIAN
-
-/* get rid of defs from io.h - ide has its private and conflicting versions */
-#ifdef insw
-#undef insw
-#endif
-#ifdef outsw
-#undef outsw
-#endif
-#ifdef insl
-#undef insl
-#endif
-#ifdef outsl
-#undef outsl
-#endif
-
-#define insw(port, addr, count) ide_insw(port, addr, count)
-#define insl(port, addr, count) ide_insl(port, addr, count)
-#define outsw(port, addr, count) ide_outsw(port, addr, count)
-#define outsl(port, addr, count) ide_outsl(port, addr, count)
-
-#endif /* __BIG_ENDIAN */
+#define __ide_mm_insw   ide_insw
+#define __ide_mm_insl   ide_insl
+#define __ide_mm_outsw  ide_outsw
+#define __ide_mm_outsl  ide_outsl
 
 #endif /* __KERNEL__ */
 

From ladis@linux-mips.org Sat Jun 21 10:06:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 21 Jun 2003 10:06:32 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8224821AbTFUJG2>; Sat, 21 Jun 2003 10:06:28 +0100
Date: Sat, 21 Jun 2003 10:06:28 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: Pete Popov <ppopov@mvista.com>
Cc: Brian Murphy <brm@murphy.dk>, Ralf Baechle <ralf@linux-mips.org>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.4] cpu-probe.c error
Message-ID: <20030621100628.A31107@ftp.linux-mips.org>
References: <E19TPHY-0002ih-00@brian.localnet> <1056128905.10307.4.camel@zeus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <1056128905.10307.4.camel@zeus.mvista.com>; from ppopov@mvista.com on Fri, Jun 20, 2003 at 10:08:25AM -0700
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: 2689
X-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 Fri, Jun 20, 2003 at 10:08:25AM -0700, Pete Popov wrote:
> 
> FYI, I had tried the same patch and it works fine on my boards. I think
> mips64 may be broken as well, if I remember correctly.

FYI, I sent patch which fixes mips/mips64; 2.4/2.5 at Mon, 16 Jun 2003
16:13:07 +0200 with subject "[PATCH] cpu-probe compile fix" and
Message-ID: <20030616141307.GA16721@simek>
Ralf could you please apply that one?

	ladis

From ralf@linux-mips.org Sat Jun 21 15:12:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 21 Jun 2003 15:12:02 +0100 (BST)
Received: from p508B6123.dip.t-dialin.net ([IPv6:::ffff:80.139.97.35]:11496
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225072AbTFUOMA>; Sat, 21 Jun 2003 15:12:00 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5LEBvbv008504;
	Sat, 21 Jun 2003 16:11:57 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5LEBupx008503;
	Sat, 21 Jun 2003 16:11:56 +0200
Date: Sat, 21 Jun 2003 16:11:55 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brm@murphy.dk>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.5] ide.h fix(es)
Message-ID: <20030621141155.GA8315@linux-mips.org>
References: <E19TTca-0007WN-00@brian.localnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E19TTca-0007WN-00@brian.localnet>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2690
X-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, Jun 20, 2003 at 11:40:36PM +0200, Brian Murphy wrote:

> this fixes some problems with undefined symbols in IDE and also
> seems to work (as far as my limited testing can go at the moment).
> Sorry if I was out of order in removing the big endian stuff, 

The big endian stuff was just old code, so from the point you were right
with removing it.  It's not an entirely correct solution though, on some
MIPS IDE systems the OS has to do endianess conversion, on some the
hardware takes care of it.  IDE as a big endian thing that was made
popular through the little endian PC platform has funny endianess issues
at times ...

  Ralf

From ralf@linux-mips.org Sun Jun 22 03:22:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Jun 2003 03:22:30 +0100 (BST)
Received: from p508B6123.dip.t-dialin.net ([IPv6:::ffff:80.139.97.35]:27043
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224821AbTFVCW2>; Sun, 22 Jun 2003 03:22:28 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5M2MLbv024355;
	Sun, 22 Jun 2003 04:22:22 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5M2MKRS024295;
	Sun, 22 Jun 2003 04:22:20 +0200
Date: Sun, 22 Jun 2003 04:22:19 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brm@murphy.dk>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.5] lasat updates
Message-ID: <20030622022219.GA23358@linux-mips.org>
References: <E19TT3b-00074n-00@brian.localnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E19TT3b-00074n-00@brian.localnet>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2691
X-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, Jun 20, 2003 at 11:04:27PM +0200, Brian Murphy wrote:

> This patch fixes up the Lasat code so it works as well as 
> before the latest chain of updates (which is not quite).
> The patch to the PCI code is necessary because I stupidly
> copied the code from the mips-boards code which also has the
> same problem (writes of full 32 bit words are ignored). 
> The people who made pci-sb1250.c seem to have 
> made the same error too...

Yep, too much code copying.  Guess why I'm doing this no-prisoners taken
cleanup of the PCI code ...

  Ralf

From ranjanp@efi.com Mon Jun 23 18:59:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Jun 2003 18:59:04 +0100 (BST)
Received: from mail3.efi.com ([IPv6:::ffff:192.68.228.90]:35087 "HELO
	fcexgw03.efi.internal") by linux-mips.org with SMTP
	id <S8225222AbTFWR7C> convert rfc822-to-8bit; Mon, 23 Jun 2003 18:59:02 +0100
Received: from 10.3.12.12 by fcexgw03.efi.internal (InterScan E-Mail VirusWall NT); Mon, 23 Jun 2003 10:58:47 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: ASID query : 2.4.20
Date: Mon, 23 Jun 2003 10:58:41 -0700
Message-ID: <D9F6B9DABA4CAE4B92850252C52383AB0796834F@ex-eng-corp.efi.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ASID query : 2.4.20
Thread-Index: AcM5sRTLV3ntFN3KScCMq6cmkv1eXw==
From: "Ranjan Parthasarathy" <ranjanp@efi.com>
To: <linux-mips@linux-mips.org>
Return-Path: <ranjanp@efi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2692
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ranjanp@efi.com
Precedence: bulk
X-list: linux-mips

I am seeing an issue with the way the current ASID circulation is implemented. The processor I am working on has the global bit implemented in the entryhi instead of the lo0 and lo1 registers.

Entry hi

31:13 : VPN2
12:7   : Reserved
6       : Global Bit
5:0    :  ASID

The ASID_MASK is 0x3f and ASID_FIRST_VERSION becomes 0x40 which seems to be written to the entryhi if we use the current code. On most processors the bits after the ASID upto the VPN/VPN2 bits seem to be reserved,RO, writes are ignored and so things do not break. In our case this does not work as ASID_FIRST_VERSION would enable the global bit when we launch the first process.

The code in asm-mips/mmu_context.h should use

write_c0_entryhi(cpu_asid(cpu,next));
instead of 
write_c0_entryhi(cpu_context(cpu,next));

in functions switch_mm,activate_mm,drop_mmu_context.

Any comments, feedback is most welcome.

Thanks

Ranjan

From ralf@linux-mips.org Tue Jun 24 10:32:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Jun 2003 10:32:03 +0100 (BST)
Received: from p508B58EB.dip.t-dialin.net ([IPv6:::ffff:80.139.88.235]:20355
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225204AbTFXJcB>; Tue, 24 Jun 2003 10:32:01 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5O9VwML004217
	for <linux-mips@linux-mips.org>; Tue, 24 Jun 2003 11:31:58 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5O9Vvpl004216
	for linux-mips@linux-mips.org; Tue, 24 Jun 2003 11:31:58 +0200
Date: Tue, 24 Jun 2003 11:31:57 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030624093157.GA25367@linux-mips.org>
References: <20030624033916Z8224827-1272+2821@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030624033916Z8224827-1272+2821@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: 2693
X-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, Jun 24, 2003 at 04:39:11AM +0100, ppopov@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ppopov@ftp.linux-mips.org	03/06/24 04:39:11
> 
> Modified files:
> 	drivers/char   : Tag: linux_2_4 Makefile 
> 
> Log message:
> 	Added au1x00-serial.o to the exports list.

There doesn't seem to be a good reason to.  Only the register_serial and
unregister_serial are exported and they don't seem to be called from
anywhere outside.

  Ralf

From ik@grex.cyberspace.org Tue Jun 24 11:01:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Jun 2003 11:01:20 +0100 (BST)
Received: from grex.cyberspace.org ([IPv6:::ffff:216.93.104.34]:18440 "HELO
	grex.cyberspace.org") by linux-mips.org with SMTP
	id <S8225204AbTFXKBS>; Tue, 24 Jun 2003 11:01:18 +0100
Received: from localhost (ik@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id GAA06619; Tue, 24 Jun 2003 06:00:17 -0400
Date: Tue, 24 Jun 2003 06:00:16 -0400 (EDT)
From: <ik@cyberspace.org>
To: <kernelnewbies@nl.linux.org>, <linux-mips@linux-mips.org>
Subject: is there any docs/manuals for linker scripts symbols
Message-ID: <Pine.SUN.3.96.1030624055005.4605A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <ik@grex.cyberspace.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2694
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ik@cyberspace.org
Precedence: bulk
X-list: linux-mips

Hi All,

Is there any documentation for the symbols in the ld.script linker
scripts for the linux kernel. 

I'm porting Linux kernel to a mips board for which I need to understand
the various symbols used in the kernel.

For example what is the use of the following symbols
`__init_begin'
`__init_end'
`__initcall_start
`__initcall_end'
`_ftext'
`__setup_start'
`__setup_end'

I'm not good in these linker scripts... any help pointers would be of
great help to me ! (I'm referrring gnu ld  manual pages ... still have a
long way to go :(

Thanks in advance !
Indu


From ralf@linux-mips.org Tue Jun 24 13:00:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Jun 2003 13:00:30 +0100 (BST)
Received: from p508B58EB.dip.t-dialin.net ([IPv6:::ffff:80.139.88.235]:39308
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225232AbTFXMA1>; Tue, 24 Jun 2003 13:00:27 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5OC0JML007253;
	Tue, 24 Jun 2003 14:00:19 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5OC0I9P007252;
	Tue, 24 Jun 2003 14:00:18 +0200
Date: Tue, 24 Jun 2003 14:00:18 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: ik@cyberspace.org
Cc: kernelnewbies@nl.linux.org, linux-mips@linux-mips.org
Subject: Re: is there any docs/manuals for linker scripts symbols
Message-ID: <20030624120017.GE4423@linux-mips.org>
References: <Pine.SUN.3.96.1030624055005.4605A-100000@grex.cyberspace.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.SUN.3.96.1030624055005.4605A-100000@grex.cyberspace.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: 2695
X-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, Jun 24, 2003 at 06:00:16AM -0400, ik@cyberspace.org wrote:

> I'm porting Linux kernel to a mips board for which I need to understand
> the various symbols used in the kernel.
> 
> For example what is the use of the following symbols
> `__init_begin'
> `__init_end'
> `__initcall_start
> `__initcall_end'
> `_ftext'
> `__setup_start'
> `__setup_end'
> 
> I'm not good in these linker scripts... any help pointers would be of
> great help to me ! (I'm referrring gnu ld  manual pages ... still have a
> long way to go :(

You'll find more information in the GNU info pages than in the man page
which is sort of an option summary only.  Of course both only cover ld,
not the way it's actually being used in Linux.

_ftext is the start of the executable kernel code.  __init_begin and
__init_end wrap the kernel's initialization code which will be freed after
full initialization.  See arch/mips/mm/init.c:__init_begin() and
arch/mips/mm/init.c:free_initmem() for how it's used.

__initcall_start and __initcall_end are used for the initcalls in
init/main.c.  See how those symbols are used in init/main.c:do_initcalls().
__setup_start and __setup_end are used in similarly obscure way to mark
start and end of the .setup.init section; see init/main.c:checksetup()
and <linux/init.h> for it's use.

  Ralf

From ppopov@mvista.com Tue Jun 24 18:49:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Jun 2003 18:49:59 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:62964 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225234AbTFXRt4>;
	Tue, 24 Jun 2003 18:49:56 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA28001;
	Tue, 24 Jun 2003 10:49:53 -0700
Subject: Re: CVS Update@-mips.org: linux
From: Pete Popov <ppopov@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030624093157.GA25367@linux-mips.org>
References: <20030624033916Z8224827-1272+2821@linux-mips.org>
	 <20030624093157.GA25367@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1056477065.10455.225.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 24 Jun 2003 10:51:05 -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: 2696
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, 2003-06-24 at 02:31, Ralf Baechle wrote:
> On Tue, Jun 24, 2003 at 04:39:11AM +0100, ppopov@linux-mips.org wrote:
> 
> > CVSROOT:	/home/cvs
> > Module name:	linux
> > Changes by:	ppopov@ftp.linux-mips.org	03/06/24 04:39:11
> > 
> > Modified files:
> > 	drivers/char   : Tag: linux_2_4 Makefile 
> > 
> > Log message:
> > 	Added au1x00-serial.o to the exports list.
> 
> There doesn't seem to be a good reason to.  Only the register_serial and
> unregister_serial are exported and they don't seem to be called from
> anywhere outside.

Strange, the kernel wouldn't compile without this. I'll try locally to
build it again and see what the problem is and if we can fix it without
modifying the Makefile.

Pete


From ralf@linux-mips.org Tue Jun 24 22:10:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Jun 2003 22:10:46 +0100 (BST)
Received: from p508B58EB.dip.t-dialin.net ([IPv6:::ffff:80.139.88.235]:45997
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225234AbTFXVKn>; Tue, 24 Jun 2003 22:10:43 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5OLAfML019165;
	Tue, 24 Jun 2003 23:10:41 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5OLAeOt019164;
	Tue, 24 Jun 2003 23:10:40 +0200
Date: Tue, 24 Jun 2003 23:10:40 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030624211040.GA19034@linux-mips.org>
References: <20030624033916Z8224827-1272+2821@linux-mips.org> <20030624093157.GA25367@linux-mips.org> <1056477065.10455.225.camel@zeus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1056477065.10455.225.camel@zeus.mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2697
X-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, Jun 24, 2003 at 10:51:05AM -0700, Pete Popov wrote:

> > > CVSROOT:	/home/cvs
> > > Module name:	linux
> > > Changes by:	ppopov@ftp.linux-mips.org	03/06/24 04:39:11
> > > 
> > > Modified files:
> > > 	drivers/char   : Tag: linux_2_4 Makefile 
> > > 
> > > Log message:
> > > 	Added au1x00-serial.o to the exports list.
> > 
> > There doesn't seem to be a good reason to.  Only the register_serial and
> > unregister_serial are exported and they don't seem to be called from
> > anywhere outside.
> 
> Strange, the kernel wouldn't compile without this. I'll try locally to
> build it again and see what the problem is and if we can fix it without
> modifying the Makefile.

Of course it'll build once you remove the unnecessary symbol exports :-)

  Ralf

From hjl@lucon.org Wed Jun 25 00:24:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Jun 2003 00:24:11 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.115]:20760 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225239AbTFXXYG>; Wed, 25 Jun 2003 00:24:06 +0100
Received: from lucon.org (12-234-88-5.client.attbi.com [12.234.88.5])
 by mtaout02.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTP id <0HH00005LE9FSP@mtaout02.icomcast.net>; Tue,
 24 Jun 2003 19:22:47 -0400 (EDT)
Received: by lucon.org (Postfix, from userid 1000)	id 9E2732C4E6; Tue,
 24 Jun 2003 23:22:27 +0000 (UTC)
Date: Tue, 24 Jun 2003 16:22:27 -0700
From: "H. J. Lu" <hjl@lucon.org>
Subject: The Linux binutils 2.14.90.0.4.1 is released
To: linux-gcc@vger.kernel.org
Cc: gcc@gcc.gnu.org, GNU C Library <libc-alpha@sources.redhat.com>,
	Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	"Steven J. Hill" <sjhill@cotw.com>
Message-id: <20030624232227.GA4484@lucon.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
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: 2698
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hjl@lucon.org
Precedence: bulk
X-list: linux-mips

This is the beta release of binutils 2.14.90.0.4.1 for Linux, which is
based on binutils 2003 0523 in CVS on sourecs.redhat.com plus various
changes. It is purely for Linux.

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

If you don't use

# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.gz

to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches.

Changes from binutils 2.14.90.0.4:

1. Fix an ia64 assembler hint@pause bug.
2. Support Intel Precott New Instructions.

Changes from binutils 2.14.90.0.3:

1. Work around the brain dead libtool.

Changes from binutils 2.14.90.0.2:

1. Update from binutils 2003 0523.
2. Fix 2 ELF visibility bugs.
3. Fix ELF/ppc linker bugs.

Changes from binutils 2.14.90.0.1:

1. Update from binutils 2003 0515.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Add more IAS compatibilities to ia64 assembler.

Changes from binutils 2.13.90.0.20:

1. Update from binutils 2003 0505.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Fix some ia64 assembler bugs.
5. Add some IAS compatibilities to ia64 assembler.
6. Fix ELF common symbol alignment.
7. Fix ELF weak symbol handling.

Changes from binutils 2.13.90.0.18:

1. Update from binutils 2003 0319.
2. Fix an ia64 linker brl relaxation bug.
3. Fix some ELF/ppc linker bugs.

Changes from binutils 2.13.90.0.16:

1. Update from binutils 2003 0121.
2. Fix an ia64 gas bug.
3. Fix some TLS bugs.
4. Fix some ELF/ppc bugs.
5. Fix an ELF/m68k bug.

2. Include /usr/bin/c++filt.
Changes from binutils 2.13.90.0.14:

1. Update from binutils 2002 1126.
2. Include /usr/bin/c++filt.
3. Fix "ld -r" with execption handling.

Changes from binutils 2.13.90.0.10:

1. Update from binutils 2002 1114.
2. Fix ELF/alpha bugs.
3. Fix an ELF/i386 assembler bug.

Changes from binutils 2.13.90.0.4:

1. Update from binutils 2002 1010.
2. More ELF/PPC linker bug fixes.
3. Fix an ELF/alpha linker bug.
4. Fix an ELF/sparc linker bug to support Solaris.
5. More TLS updates.

Changes from binutils 2.13.90.0.3:

1. Update from binutils 2002 0814.
2. Fix symbol versioning bugs for gcc 3.2.
3. Fix mips gas.

Changes from binutils 2.13.90.0.2:

1. Update from binutils 2002 0809.
2. Fix a mips gas compatibility bug.
3. Fix an x86 TLS bfd bug.
4. Fix an x86 PIC gas bug.
5. Improve symbol versioning support.

The file list:

1. binutils-2.14.90.0.4.1.tar.gz. Source code.
2. binutils-2.14.90.0.4-2.14.90.0.4.1.diff.gz. Patch against the
   previous beta source code.
3. binutils-2.14.90.0.4.1-1.i386.rpm. IA-32 binary RPM for RedHat 9.
4. binutils-2.14.90.0.4.1-1.ia64.rpm. IA-64 binary RPM for RedHat AS 2.1.

There is no separate source rpm. You can do

# rpm -ta binutils-2.14.90.0.4.1.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
06/24/2003

From ppopov@mvista.com Wed Jun 25 01:23:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Jun 2003 01:23:05 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:48884 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225239AbTFYAXD>;
	Wed, 25 Jun 2003 01:23:03 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA15222;
	Tue, 24 Jun 2003 17:22:57 -0700
Subject: Re: [PATCH] au1000_eth.c - Dave Jones
From: Pete Popov <ppopov@mvista.com>
To: joeg@clearcore.com
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>
In-Reply-To: <20030614052652.8161.qmail@clearcore.com>
References: <20030614052652.8161.qmail@clearcore.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1056500652.10455.312.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 24 Jun 2003 17:24:13 -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: 2699
X-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


I'm behind a few patches. I'll take care of it.

Pete

On Fri, 2003-06-13 at 22:26, Joe George wrote:
> This patch was submitted on lkml by Dave Jones and reviewed
> by Jeff Garzik.  Description:
> 
> - Missing release region
> - Unneeded initialization of private struct
>   (already done in init_etherdev)
> - Remove unneeded freeing of dev-priv
>   (auto-free'd by kfree(dev)
> - actually kfree(dev), plugging leak.
> 
> Joe
> 
> 
> diff -upN linux-mips-cvs24/drivers/net/au1000_eth.c tst_mips24/drivers/net/au1000_eth.c
> --- linux-mips-cvs24/drivers/net/au1000_eth.c	Fri Jun 13 20:15:18 2003
> +++ tst_mips24/drivers/net/au1000_eth.c	Fri Jun 13 22:19:09 2003
> @@ -1110,38 +1110,21 @@ au1000_probe1(struct net_device *dev, lo
>  	char *pmac, *argptr;
>  	char ethaddr[6];
>  
> -	if (!request_region(PHYSADDR(ioaddr), MAC_IOSIZE, "Au1x00 ENET")) {
> +	if (!request_region(PHYSADDR(ioaddr), MAC_IOSIZE, "Au1x00 ENET"))
>  		 return -ENODEV;
> -	}
>  
>  	if (version_printed++ == 0) printk(version);
>  
>  	if (!dev) {
> -		dev = init_etherdev(0, sizeof(struct au1000_private));
> -	}
> -	if (!dev) {
> -		 printk (KERN_ERR "au1000 eth: init_etherdev failed\n");  
> -		 return -ENODEV;
> +		dev = init_etherdev(NULL, sizeof(struct au1000_private));
> +		printk (KERN_ERR "au1000 eth: init_etherdev failed\n");  
> +		release_region(ioaddr, MAC_IOSIZE);
> +		return -ENODEV;
>  	}
>  
>  	printk("%s: Au1xxx ethernet found at 0x%lx, irq %d\n", 
>  			dev->name, ioaddr, irq);
>  
> -	/* Initialize our private structure */
> -	if (dev->priv == NULL) {
> -		aup = (struct au1000_private *) 
> -			kmalloc(sizeof(*aup), GFP_KERNEL);
> -		if (aup == NULL) {
> -			retval = -ENOMEM;
> -			goto free_region;
> -		}
> -		dev->priv = aup;
> -	}
> -
> -	aup = dev->priv;
> -	memset(aup, 0, sizeof(*aup));
> -
> -
>  	/* Allocate the data buffers */
>  	aup->vaddr = (u32)dma_alloc(MAX_BUF_SIZE * 
>  			(NUM_TX_BUFFS+NUM_RX_BUFFS), &aup->dma_addr);
> @@ -1280,8 +1263,6 @@ free_region:
>  	if (aup->vaddr) 
>  		dma_free((void *)aup->vaddr, 
>  				MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS));
> -	if (dev->priv != NULL)
> -		kfree(dev->priv);
>  	kfree(aup->mii);
>  	kfree(dev);
>  	printk(KERN_ERR "%s: au1000_probe1 failed.  Returns %d\n",
> @@ -1450,15 +1431,15 @@ static int au1000_close(struct net_devic
>  	spin_lock_irqsave(&aup->lock, flags);
>  	
>  	/* stop the device */
> -	if (netif_device_present(dev)) {
> +	if (netif_device_present(dev))
>  		netif_stop_queue(dev);
> -	}
>  
>  	/* disable the interrupt */
>  	free_irq(dev->irq, dev);
>  	spin_unlock_irqrestore(&aup->lock, flags);
>  
>  	reset_mac(dev);
> +	kfree(dev);
>  	MOD_DEC_USE_COUNT;
>  	return 0;
>  }
> 
> 


From fxzhang@ict.ac.cn Wed Jun 25 03:02:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Jun 2003 03:02:03 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:28070
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225239AbTFYCCB>; Wed, 25 Jun 2003 03:02:01 +0100
Received: (qmail 15178 invoked from network); 25 Jun 2003 01:26:43 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 25 Jun 2003 01:26:43 -0000
Message-ID: <3EF90275.2050903@ict.ac.cn>
Date: Wed, 25 Jun 2003 10:01:25 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: ik@cyberspace.org
CC: kernelnewbies@nl.linux.org, linux-mips@linux-mips.org
Subject: Re: is there any docs/manuals for linker scripts symbols
References: <Pine.SUN.3.96.1030624055005.4605A-100000@grex.cyberspace.org>
In-Reply-To: <Pine.SUN.3.96.1030624055005.4605A-100000@grex.cyberspace.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <fxzhang@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2700
X-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

info ld give much more information than man ld.

for those symbols,you need to learn something about ELF file format
(its concept of sections)

ik@cyberspace.org wrote:

>Hi All,
>
>Is there any documentation for the symbols in the ld.script linker
>scripts for the linux kernel. 
>
>I'm porting Linux kernel to a mips board for which I need to understand
>the various symbols used in the kernel.
>
>For example what is the use of the following symbols
>`__init_begin'
>`__init_end'
>`__initcall_start
>`__initcall_end'
>`_ftext'
>`__setup_start'
>`__setup_end'
>
>I'm not good in these linker scripts... any help pointers would be of
>great help to me ! (I'm referrring gnu ld  manual pages ... still have a
>long way to go :(
>
>Thanks in advance !
>Indu
>
>
>
>
>  
>


From ralf@linux-mips.org Wed Jun 25 05:59:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Jun 2003 05:59:22 +0100 (BST)
Received: from p508B6A7B.dip.t-dialin.net ([IPv6:::ffff:80.139.106.123]:25802
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225205AbTFYE7U>; Wed, 25 Jun 2003 05:59:20 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5P4xIML029426;
	Wed, 25 Jun 2003 06:59:19 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5P4xG4Y029425;
	Wed, 25 Jun 2003 06:59:16 +0200
Date: Wed, 25 Jun 2003 06:59:16 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Joseph Chiu <joseph@omnilux.net>
Cc: Pete Popov <ppopov@mvista.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: wired tlb entry?
Message-ID: <20030625045916.GA28556@linux-mips.org>
References: <1055873800.4383.220.camel@zeus.mvista.com> <BPEELMGAINDCONKDGDNCMEGADMAA.joseph@omnilux.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BPEELMGAINDCONKDGDNCMEGADMAA.joseph@omnilux.net>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2701
X-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, Jun 17, 2003 at 11:51:13AM -0700, Joseph Chiu wrote:

> Michael Guo suggested add_wired_entry -- I'm giving that a try now.  I'm
> trying to stick to "the kernel that we trust" (from the perspective here)
> because I'm worried about what I end up breaking trying to take a new
> kernel.
> 
> I am behind the time, though, so I'll try to test out 2.4.21-pre4 when I get
> back (I'm not available to run the tests during the rest of this week).

Usual warning - wired entries are almost always a bad idea.  TLB entries
are a scarce resource and wiring will reduce the number available for
random replacement even further raising the amount of CPU burned in the
TLB reload handler.

  Ralf

From ik@grex.cyberspace.org Wed Jun 25 13:01:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Jun 2003 13:01:37 +0100 (BST)
Received: from grex.cyberspace.org ([IPv6:::ffff:216.93.104.34]:25098 "HELO
	grex.cyberspace.org") by linux-mips.org with SMTP
	id <S8225220AbTFYMBf>; Wed, 25 Jun 2003 13:01:35 +0100
Received: from localhost (ik@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id IAA27228; Wed, 25 Jun 2003 08:01:25 -0400
Date: Wed, 25 Jun 2003 08:01:24 -0400 (EDT)
From: <ik@cyberspace.org>
To: <ralf@linux-mips.org>
cc: <linux-mips@linux-mips.org>
Subject: Re: is there any docs/manuals for linker scripts symbols
In-Reply-To: <20030624120017.GE4423@linux-mips.org>
Message-ID: <Pine.SUN.3.96.1030625073721.22435A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <ik@grex.cyberspace.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2702
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ik@cyberspace.org
Precedence: bulk
X-list: linux-mips

Thanks Ralf for your insights !

My board has a boot loader (rom) that enforce/restricts the sections in
the elf header, hence I cannot use the default linker script that comes
wit the kernel(arch/mips/). 

I'm refereing the ld manual at
http://www.gnu.org/manual/ld-2.9.1/html_mono/ld.html

I think your reply could be put as a howto/faqs in
http://www.linux-mips.org (for the global symbols
used in linux kernel).

Thanks,
Indu

On Tue, 24 Jun 2003 ralf@linux-mips.org wrote:

> On Tue, Jun 24, 2003 at 06:00:16AM -0400, ik@cyberspace.org wrote:
> 
> > I'm porting Linux kernel to a mips board for which I need to understand
> > the various symbols used in the kernel.
> > 
> > For example what is the use of the following symbols
> > `__init_begin'
> > `__init_end'
> > `__initcall_start
> > `__initcall_end'
> > `_ftext'
> > `__setup_start'
> > `__setup_end'
> > 
> > I'm not good in these linker scripts... any help pointers would be of
> > great help to me ! (I'm referrring gnu ld  manual pages ... still have a
> > long way to go :(
> 
> You'll find more information in the GNU info pages than in the man page
> which is sort of an option summary only.  Of course both only cover ld,
> not the way it's actually being used in Linux.
> 
> _ftext is the start of the executable kernel code.  __init_begin and
> __init_end wrap the kernel's initialization code which will be freed after
> full initialization.  See arch/mips/mm/init.c:__init_begin() and
> arch/mips/mm/init.c:free_initmem() for how it's used.
> 
> __initcall_start and __initcall_end are used for the initcalls in
> init/main.c.  See how those symbols are used in init/main.c:do_initcalls().
> __setup_start and __setup_end are used in similarly obscure way to mark
> start and end of the .setup.init section; see init/main.c:checksetup()
> and <linux/init.h> for it's use.
> 
>   Ralf
> 


From ralf@linux-mips.org Wed Jun 25 13:18:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Jun 2003 13:18:11 +0100 (BST)
Received: from p508B6A7B.dip.t-dialin.net ([IPv6:::ffff:80.139.106.123]:21220
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225239AbTFYMSJ>; Wed, 25 Jun 2003 13:18:09 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5PCI2DB012476;
	Wed, 25 Jun 2003 14:18:02 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5PCI1hn012469;
	Wed, 25 Jun 2003 14:18:01 +0200
Date: Wed, 25 Jun 2003 14:18:01 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: ik@cyberspace.org
Cc: linux-mips@linux-mips.org
Subject: Re: is there any docs/manuals for linker scripts symbols
Message-ID: <20030625121801.GA11496@linux-mips.org>
References: <20030624120017.GE4423@linux-mips.org> <Pine.SUN.3.96.1030625073721.22435A-100000@grex.cyberspace.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.SUN.3.96.1030625073721.22435A-100000@grex.cyberspace.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: 2703
X-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, Jun 25, 2003 at 08:01:24AM -0400, ik@cyberspace.org wrote:

> My board has a boot loader (rom) that enforce/restricts the sections in
> the elf header, hence I cannot use the default linker script that comes
> wit the kernel(arch/mips/). 

Are you sure the loader actually looks at the sections?  That seems plain
wrong.  Normally a loader should only look at all the PT_LOAD entries in
the ELF program header table for loading.

> I think your reply could be put as a howto/faqs in
> http://www.linux-mips.org (for the global symbols
> used in linux kernel).

So many things that deserve some well written documentation - yet so little
exists ...

  Ralf

From joseph@omnilux.net Wed Jun 25 19:02:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Jun 2003 19:02:32 +0100 (BST)
Received: from mx2.idealab.com ([IPv6:::ffff:64.208.8.4]:22453 "EHLO
	butch.idealab.com") by linux-mips.org with ESMTP
	id <S8225244AbTFYSC2>; Wed, 25 Jun 2003 19:02:28 +0100
Received: (qmail 65338 invoked by uid 72); 25 Jun 2003 18:02:15 -0000
Received: from joseph@omnilux.net by butch.idealab.com with qmail-scanner-1.03 (sweep: 2.6/3.49. . Clean. Processed in 1.904417 secs); 25 Jun 2003 18:02:15 -0000
X-Qmail-Scanner-Mail-From: joseph@omnilux.net via butch.idealab.com
X-Qmail-Scanner: 1.03 (Clean. Processed in 1.904417 secs)
Received: from unknown (HELO c002079) (10.1.2.63)
  by 0 with SMTP; 25 Jun 2003 18:02:13 -0000
From: "Joseph Chiu" <joseph@omnilux.net>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: "Pete Popov" <ppopov@mvista.com>,
	"Linux MIPS mailing list" <linux-mips@linux-mips.org>
Subject: RE: wired tlb entry?
Date: Wed, 25 Jun 2003 11:05:49 -0700
Message-ID: <BPEELMGAINDCONKDGDNCIEMGDMAA.joseph@omnilux.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <20030625045916.GA28556@linux-mips.org>
Return-Path: <joseph@omnilux.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: 2704
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joseph@omnilux.net
Precedence: bulk
X-list: linux-mips

On Tuesday, June 24, 2003 9:59 PM Ralf Baechle wrote:

> Usual warning - wired entries are almost always a bad idea.  TLB entries
> are a scarce resource and wiring will reduce the number available for
> random replacement even further raising the amount of CPU burned in the
> TLB reload handler.

Thanks Ralf.  It is "just one" wired global TLB entry (admiteddly, out of a
paltry 32).   Using the wired entry has fixed the immediate problem at hand,
so I decided it's worth it for now.

Joseph


From Michael_Gruetzner@gmx.de Wed Jun 25 23:43:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Jun 2003 23:43:17 +0100 (BST)
Received: from mail.gmx.net ([IPv6:::ffff:213.165.64.20]:55976 "HELO
	mail.gmx.net") by linux-mips.org with SMTP id <S8225290AbTFYWnP>;
	Wed, 25 Jun 2003 23:43:15 +0100
Received: (qmail 27646 invoked by uid 65534); 25 Jun 2003 22:43:11 -0000
Received: from pD9EE6FA9.dip.t-dialin.net (EHLO gmx.de) (217.238.111.169)
  by mail.gmx.net (mp006) with SMTP; 26 Jun 2003 00:43:11 +0200
Message-ID: <3EFA24C9.7010901@gmx.de>
Date: Thu, 26 Jun 2003 00:40:09 +0200
From: Michael Gruetzner <Michael_Gruetzner@gmx.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030612
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Booting Kernel on RM200
X-Enigmail-Version: 0.74.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <Michael_Gruetzner@gmx.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: 2705
X-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_Gruetzner@gmx.de
Precedence: bulk
X-list: linux-mips

Hello,

I've still got some trouble booting the kernel on my RM200. This is what 
i did:
I've downloaded milo and the precompiled kernel image from 
ftp.linux-mips.org. Then I burned milo and vmlinux on a cdr. When I 
start milo on the RM200 everything looks fine but milo doesn't load the 
image from cd. So I copied vmlinux onto a floppy. Now milo is able to 
find the image an it seems to load the kernel. After a few minutes(yes 
it takes that long) milo says: "Booting the kernel..." but nothing 
happens. I also tried a kernel that I've crosscompiled on my box but 
then milo says "Not a mips kernel" (because it was compiled as 
mipsel-linux - what seems to be the right because with ARC firmware the 
RM200 is little endian).
So could you please give me some advice how I can boot a linux kernel on 
such a box.

Thank you very much in advance.

Michael

-- 
printk("CPU[%d]: Sending penguins to jail...",smp_processor_id());
  [... 20 lines ...]
printk("CPU[%d]: Giving pardon to imprisoned penguins\n", 
smp_processor_id());
         2.4.8 arch/sparc64/kernel/smp.c


From bruno.randolf@4g-systems.de Thu Jun 26 18:43:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Jun 2003 18:43:17 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.183]:4073 "EHLO
	moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225299AbTFZRnN> convert rfc822-to-8bit; Thu, 26 Jun 2003 18:43:13 +0100
Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 19Vam7-00056I-00
	for linux-mips@linux-mips.org; Thu, 26 Jun 2003 19:43:11 +0200
Received: from [62.109.119.233] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 19Vam6-00078r-00
	for linux-mips@linux-mips.org; Thu, 26 Jun 2003 19:43:11 +0200
From: Bruno Randolf <bruno.randolf@4g-systems.de>
Organization: 4G Mobile Systeme
Subject: au1500 usb device
Date: Thu, 26 Jun 2003 19:43:10 +0200
User-Agent: KMail/1.5.2
MIME-Version: 1.0
Content-Description: clearsigned data
Content-Disposition: inline
To: linux-mips@linux-mips.org
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Message-Id: <200306261943.10057.bruno.randolf@4g-systems.de>
Return-Path: <bruno.randolf@4g-systems.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: 2706
X-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.de
Precedence: bulk
X-list: linux-mips

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

hello!

i have an au1500 based board named "mtx-1" and i want to test the usb device 
functionality. i have enabled "Au1x00 USB TTY Device support", set 
SYS_PINFUNC to USB device in my setup.c, enabled VDEBUG in 
au1000/common/usbdevice.c and followed the instructions from steve's previous 
mail.

when i attach the USB cable, i get the following output

usbdev.c: receive_packet_complete: ep0, NAK pkt=811dd520, size=8
usbdev.c: SU bit is set in setup stage
usbdev.c: received NAK SETUP
usbdev.c: do_setup: req 0 GET_STATUS
usbdev.c: endpoint_stall
usbdev.c: receive_packet_complete: ep0, NAK pkt=811b44e0, size=0
usbdev.c: SU bit is set in setup stage
usbdev.c: process_ep0_receive: wrong size SETUP received
usbdev.c: receive_packet_complete: ep0, NAK pkt=811dd520, size=0
usbdev.c: SU bit is set in setup stage
usbdev.c: process_ep0_receive: wrong size SETUP received
usbdev.c: receive_packet_complete: ep0, NAK pkt=811b44e0, size=0
usbdev.c: SU bit is set in setup stage
usbdev.c: process_ep0_receive: wrong size SETUP received
usbdev.c: receive_packet_complete: ep0, NAK pkt=811dd520, size=0
usbdev.c: SU bit is set in setup stage
usbdev.c: process_ep0_receive: wrong size SETUP received

it seems like the device does not react to the GET_STATUS request from the 
host (the code to do so is missing) and then stalls. has anyone got this to 
work with another board? anything that i might be doing wrong?

thanks,
bruno



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

iD8DBQE++zCufg2jtUL97G4RAkK0AKCfHwdRiCCZsRadsaz9vJlKhljZ3wCfd7ZG
Jd7l3n5+vc59vdwHWy0sXKs=
=Fl4x
-----END PGP SIGNATURE-----


From sjhill@realitydiluted.com Fri Jun 27 02:03:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Jun 2003 02:03:56 +0100 (BST)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:40410
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225305AbTF0BDy>; Fri, 27 Jun 2003 02:03:54 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 19VheR-00013M-00; Thu, 26 Jun 2003 20:03:44 -0500
Message-ID: <3EFB9796.5070701@realitydiluted.com>
Date: Thu, 26 Jun 2003 21:02:14 -0400
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030618 Debian/1.3.1-3
X-Accept-Language: en
MIME-Version: 1.0
To: Joseph Chiu <joseph@omnilux.net>
CC: Ralf Baechle <ralf@linux-mips.org>, Pete Popov <ppopov@mvista.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: wired tlb entry?
References: <BPEELMGAINDCONKDGDNCIEMGDMAA.joseph@omnilux.net>
In-Reply-To: <BPEELMGAINDCONKDGDNCIEMGDMAA.joseph@omnilux.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2707
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips

Joseph Chiu wrote:
> 
> Thanks Ralf.  It is "just one" wired global TLB entry (admiteddly, out of a
> paltry 32).   Using the wired entry has fixed the immediate problem at hand,
> so I decided it's worth it for now.
> 
If you can, which board is this on?

-Steve


From ashish.anand@inspiretech.com Fri Jun 27 07:36:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Jun 2003 07:36:38 +0100 (BST)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:52130
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8225305AbTF0Ggf>; Fri, 27 Jun 2003 07:36:35 +0100
Received: from mail.inspiretech.com (mail.inspiretech.com [192.168.42.3])
	by smtp.inspirtek.com (8.12.5/8.12.5) with ESMTP id h5R7Cvvo008528
	for <linux-mips@linux-mips.org>; Fri, 27 Jun 2003 12:43:02 +0530
Message-Id: <200306270713.h5R7Cvvo008528@smtp.inspirtek.com>
Received: from WorldClient [192.168.42.3] by inspiretech.com [192.168.42.3]
	with SMTP (MDaemon.v3.5.7.R)
	for <linux-mips@linux-mips.org>; Fri, 27 Jun 2003 11:58:21 +0530
Date: Fri, 27 Jun 2003 11:58:19 +0530
From: "Ashish anand" <ashish.anand@inspiretech.com>
To: linux-mips@linux-mips.org
Subject: migrating from vxworks to linux...
X-Mailer: WorldClient Standard 3.5.0e
X-MDRemoteIP: 192.168.42.3
X-Return-Path: ashish.anand@inspiretech.com
X-MDaemon-Deliver-To: linux-mips@linux-mips.org
Return-Path: <ashish.anand@inspiretech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2708
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish.anand@inspiretech.com
Precedence: bulk
X-list: linux-mips

Hello,

After my firmware+bsp for linux on mips based L2/L3/L4 switch is over , I
have the requirements for porting huge swithching software in linux.

we have decided to go for switching implementation inside kernel space
using kernel_threads .
for this I though of porting application from vxworks to linux without
changing the architect and core design of application.

my linux version is 2.3.99-pre8.
I realised these application are using posix IPC facilities in vxworks
while I can't use any of them inside linux kernel space using kernel
threads.
examplesake i can use raw semaphore opeartions (up/down) but not like 
SEM_Q_FIFO / SEM_Q_PRIORITY without cosiderable kernel code change.

does this situation demands that my application design has to be changed..
or should I go ahead with writing wrappers for everything seems
unimplemented at kernel level..?


Best Regards,
Ashsih Anand



From joseph@omnilux.net Fri Jun 27 18:35:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Jun 2003 18:35:13 +0100 (BST)
Received: from mx2.idealab.com ([IPv6:::ffff:64.208.8.4]:990 "EHLO
	butch.idealab.com") by linux-mips.org with ESMTP
	id <S8225311AbTF0RfJ>; Fri, 27 Jun 2003 18:35:09 +0100
Received: (qmail 46154 invoked by uid 72); 27 Jun 2003 17:35:01 -0000
Received: from joseph@omnilux.net by butch.idealab.com with qmail-scanner-1.03 (sweep: 2.6/3.49. . Clean. Processed in 3.265369 secs); 27 Jun 2003 17:35:01 -0000
X-Qmail-Scanner-Mail-From: joseph@omnilux.net via butch.idealab.com
X-Qmail-Scanner: 1.03 (Clean. Processed in 3.265369 secs)
Received: from unknown (HELO c002079) (10.1.2.63)
  by 0 with SMTP; 27 Jun 2003 17:34:57 -0000
From: "Joseph Chiu" <joseph@omnilux.net>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: "Ralf Baechle" <ralf@linux-mips.org>,
	"Pete Popov" <ppopov@mvista.com>,
	"Linux MIPS mailing list" <linux-mips@linux-mips.org>
Subject: RE: wired tlb entry?
Date: Fri, 27 Jun 2003 10:38:36 -0700
Message-ID: <BPEELMGAINDCONKDGDNCIEOHDMAA.joseph@omnilux.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <3EFB9796.5070701@realitydiluted.com>
Return-Path: <joseph@omnilux.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: 2709
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joseph@omnilux.net
Precedence: bulk
X-list: linux-mips

This is on our own board.  We're developing a optical wireless transceiver
system (see www.omnilux.net) and we use the Au1000 as the central
controller.

It's a pretty simple board -- the au1000 static bus interfaces connects to
FLASH, and two external peripheral devices; one of them being a PCMCIA card.
(We put the card directly on the bus -- no "end user proofing" buffers or
any such things).

The non-PCMCIA peripheral sits within the directly accessible low memory
range.  In fact, outside of user pages, the only thing that needs TLB is the
small windows pointing to the PCMCIA card.

Joseph
-----Original Message-----
From: Steven J. Hill [mailto:sjhill@realitydiluted.com]
Sent: Thursday, June 26, 2003 6:02 PM
To: Joseph Chiu
Cc: Ralf Baechle; Pete Popov; Linux MIPS mailing list
Subject: Re: wired tlb entry?


Joseph Chiu wrote:
>
> Thanks Ralf.  It is "just one" wired global TLB entry (admiteddly, out of
a
> paltry 32).   Using the wired entry has fixed the immediate problem at
hand,
> so I decided it's worth it for now.
>
If you can, which board is this on?

-Steve



From macro@ds2.pg.gda.pl Fri Jun 27 20:45:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Jun 2003 20:45:08 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:52955 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225215AbTF0TpG>; Fri, 27 Jun 2003 20:45:06 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA01905;
	Fri, 27 Jun 2003 21:46:05 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 27 Jun 2003 21:46:05 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: kwalker@linux-mips.org
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20030627191204Z8225311-1272+2885@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030627214156.27044M-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2710
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 27 Jun 2003 kwalker@linux-mips.org wrote:

> Modified files:
> 	arch/mips/lib  : memcpy.S 
> 	arch/mips64/lib: memcpy.S 
> 
> Log message:
> 	fix bug in getting the thread's BUADDR in l_exc case

 There's still missing a load delay slot filler there.  I'm checking in an
obvious fix immediately.

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


From kwalker@broadcom.com Fri Jun 27 21:33:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Jun 2003 21:33:04 +0100 (BST)
Received: from mms3.broadcom.com ([IPv6:::ffff:63.70.210.38]:7949 "EHLO
	mms3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225215AbTF0UdC>; Fri, 27 Jun 2003 21:33:02 +0100
Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.5.2)); Fri, 27 Jun 2003 13:32:50 -0700
Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com
 [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id NAA04108; Fri, 27 Jun 2003 13:32:19 -0700 (PDT)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id
 h5RKWeov001611; Fri, 27 Jun 2003 13:32:41 -0700 (PDT)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id NAA26397; Fri,
 27 Jun 2003 13:32:40 -0700
Message-ID: <3EFCA9E8.D08AAA3A@broadcom.com>
Date: Fri, 27 Jun 2003 13:32:40 -0700
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
References: <Pine.GSO.3.96.1030627214156.27044M-100000@delta.ds2.pg.gda.pl>
X-WSS-ID: 12E2767896805-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <kwalker@broadcom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2711
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kwalker@broadcom.com
Precedence: bulk
X-list: linux-mips

"Maciej W. Rozycki" wrote:
> 
> On Fri, 27 Jun 2003 kwalker@linux-mips.org wrote:
> 
> > Modified files:
> >       arch/mips/lib  : memcpy.S
> >       arch/mips64/lib: memcpy.S
> >
> > Log message:
> >       fix bug in getting the thread's BUADDR in l_exc case
> 
>  There's still missing a load delay slot filler there.  I'm checking in an
> obvious fix immediately.

What about the other back-to-back loads in that file (9 lines above)? 
My CPU doesn't care about the load delay slot, so I didn't think to add
the nop.  At least my patch didn't introduce the problem ;-)

Kip


From macro@ds2.pg.gda.pl Fri Jun 27 21:47:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Jun 2003 21:47:15 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:5602 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225215AbTF0UrN>; Fri, 27 Jun 2003 21:47:13 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA02723;
	Fri, 27 Jun 2003 22:48:12 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 27 Jun 2003 22:48:12 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Kip Walker <kwalker@broadcom.com>
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <3EFCA9E8.D08AAA3A@broadcom.com>
Message-ID: <Pine.GSO.3.96.1030627223600.27044Q-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2712
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 27 Jun 2003, Kip Walker wrote:

> >  There's still missing a load delay slot filler there.  I'm checking in an
> > obvious fix immediately.
> 
> What about the other back-to-back loads in that file (9 lines above)? 

 Oops -- I've missed that one even though I've browsed through the file. 
Thanks for pointing it out. 

> My CPU doesn't care about the load delay slot, so I didn't think to add

 I hope you haven't realized of the problem rather than ignored it.  I
think the nops should eventually be replaced with macros that would
conditionally expand to nothing.  But correctness first and performance
later. 

> the nop.  At least my patch didn't introduce the problem ;-)

 But it let me notice it.  Better late than never. 

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


From patrick.hilt@pioneer-pdt.com Fri Jun 27 22:12:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Jun 2003 22:12:05 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:55528
	"EHLO ns.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225248AbTF0VMD>; Fri, 27 Jun 2003 22:12:03 +0100
Received: from philt.mrp.pioneer-pdt.com ([172.30.2.110])
          by ns.pioneer-pdt.com (Post.Office MTA v3.5.3 release 223
          ID# 0-68491U100L2S100V35) with ESMTP id com
          for <linux-mips@linux-mips.org>; Fri, 27 Jun 2003 14:14:19 -0700
From: patrick.hilt@pioneer-pdt.com (Patrick Hilt)
Organization: Pioneer
To: linux-mips@linux-mips.org
Subject: KGDB problem
Date: Fri, 27 Jun 2003 14:11:18 -0400
User-Agent: KMail/1.5
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200306271411.18555.philt@pioneer-pdt.com>
Return-Path: <patrick.hilt@pioneer-pdt.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2713
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: patrick.hilt@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips

Hello!
I just recently started working on Broadcom MIPS32 architecture (7115 chipset 
based STB, Broadcom modified 2.4.18 kernel) and have been trying to get kgdb 
setup to do some kernel source level debugging... with little success I might 
add ;-|. I compiled remote debug support in to the kernel, added kernel 
command line parameters and tried a dozen different configurations... but 
never got a "Wait for gdb client connection..." message at boot time. The box 
happily continues to boot on. On the other hand, there seems to be support 
for debugging in the kernel source since there is a .../dbg_io.c 
implementation.

I guess I am not really sure what to do with it at this point... I read 
documentation and mailing list archives... no joy!

If anyone on this list would have some pointers and/or suggestions I'd greatly 
appreciate that :-)!!!

Thanks a lot,

Patrick


From jsun@mvista.com Fri Jun 27 22:19:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Jun 2003 22:19:50 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:20729 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225250AbTF0VTs>;
	Fri, 27 Jun 2003 22:19:48 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h5RLJjD20993;
	Fri, 27 Jun 2003 14:19:45 -0700
Date: Fri, 27 Jun 2003 14:19:45 -0700
From: Jun Sun <jsun@mvista.com>
To: Patrick Hilt <patrick.hilt@pioneer-pdt.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: KGDB problem
Message-ID: <20030627141945.S31851@mvista.com>
References: <200306271411.18555.philt@pioneer-pdt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200306271411.18555.philt@pioneer-pdt.com>; from patrick.hilt@pioneer-pdt.com on Fri, Jun 27, 2003 at 02:11:18PM -0400
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2714
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Jun 27, 2003 at 02:11:18PM -0400, Patrick Hilt wrote:
> Hello!
> I just recently started working on Broadcom MIPS32 architecture (7115 chipset 
> based STB, Broadcom modified 2.4.18 kernel) and have been trying to get kgdb 
> setup to do some kernel source level debugging... with little success I might 
> add ;-|. I compiled remote debug support in to the kernel, added kernel 
> command line parameters and tried a dozen different configurations... but 
> never got a "Wait for gdb client connection..." message at boot time.  The box 
> happily continues to boot on. On the other hand, there seems to be support 
> for debugging in the kernel source since there is a .../dbg_io.c 
> implementation.
>

Kgdb support is board dependent.  Some boards, such as Malta, decide to
skip kgdb _even when_ you configure it.  To activate kgdb, you need to
pass command line args, such as "kgdb=ttyS1", to kernel.  What a smart idea. :)

Check the source for your board.

What I like to see is kgdb should be activated when it is configured.
However, "nokgdb" argument can be passed to kernel to skip it even when
kgdb is configured.

Jun

From patrick.hilt@pioneer-pdt.com Fri Jun 27 23:19:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Jun 2003 23:19:29 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:57810
	"EHLO ns.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225250AbTF0WT1>; Fri, 27 Jun 2003 23:19:27 +0100
Received: from philt.mrp.pioneer-pdt.com ([172.30.2.110])
          by ns.pioneer-pdt.com (Post.Office MTA v3.5.3 release 223
          ID# 0-68491U100L2S100V35) with ESMTP id com;
          Fri, 27 Jun 2003 15:21:32 -0700
From: patrick.hilt@pioneer-pdt.com (Patrick Hilt)
Organization: Pioneer
To: Jun Sun <jsun@mvista.com>
Subject: Re: KGDB problem
Date: Fri, 27 Jun 2003 15:18:32 -0400
User-Agent: KMail/1.5
References: <200306271411.18555.philt@pioneer-pdt.com> <20030627141945.S31851@mvista.com>
In-Reply-To: <20030627141945.S31851@mvista.com>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200306271518.32093.philt@pioneer-pdt.com>
Return-Path: <patrick.hilt@pioneer-pdt.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2715
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: patrick.hilt@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips

Hi Jun!
Thank you very much for your reply! I very much appreciate it! I think I am 
getting a little confused now... I read your "Linux MIPS porting howto" (very 
informative, thanks a lot :-) and consulted some other documents about this 
and there it says to have a kernel command line such as "... gdb gdbttys=1 
gdbbaud=115200". Now, should I just try to add "kgdb=ttys1" to that or 
replace the previous command with it. Sorry if I am asking a stupid question 
but this process is not very well documented... somehow...

Again, thanks a lot for your help!!

Patrick


On Friday 27 June 2003 05:19 pm, Jun Sun wrote:
> On Fri, Jun 27, 2003 at 02:11:18PM -0400, Patrick Hilt wrote:
> > Hello!
> > I just recently started working on Broadcom MIPS32 architecture (7115
> > chipset based STB, Broadcom modified 2.4.18 kernel) and have been trying
> > to get kgdb setup to do some kernel source level debugging... with little
> > success I might add ;-|. I compiled remote debug support in to the
> > kernel, added kernel command line parameters and tried a dozen different
> > configurations... but never got a "Wait for gdb client connection..."
> > message at boot time.  The box happily continues to boot on. On the other
> > hand, there seems to be support for debugging in the kernel source since
> > there is a .../dbg_io.c implementation.
>
> Kgdb support is board dependent.  Some boards, such as Malta, decide to
> skip kgdb _even when_ you configure it.  To activate kgdb, you need to
> pass command line args, such as "kgdb=ttyS1", to kernel.  What a smart
> idea. :)
>
> Check the source for your board.
>
> What I like to see is kgdb should be activated when it is configured.
> However, "nokgdb" argument can be passed to kernel to skip it even when
> kgdb is configured.
>
> Jun


From jsun@mvista.com Fri Jun 27 23:45:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Jun 2003 23:45:51 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:10998 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225250AbTF0Wpt>;
	Fri, 27 Jun 2003 23:45:49 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h5RMjl721405;
	Fri, 27 Jun 2003 15:45:47 -0700
Date: Fri, 27 Jun 2003 15:45:47 -0700
From: Jun Sun <jsun@mvista.com>
To: Patrick Hilt <patrick.hilt@pioneer-pdt.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: KGDB problem
Message-ID: <20030627154547.T31851@mvista.com>
References: <200306271411.18555.philt@pioneer-pdt.com> <20030627141945.S31851@mvista.com> <200306271518.32093.philt@pioneer-pdt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200306271518.32093.philt@pioneer-pdt.com>; from patrick.hilt@pioneer-pdt.com on Fri, Jun 27, 2003 at 03:18:32PM -0400
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2716
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Jun 27, 2003 at 03:18:32PM -0400, Patrick Hilt wrote:
> Hi Jun!
> Thank you very much for your reply! I very much appreciate it! I think I am 
> getting a little confused now... I read your "Linux MIPS porting howto" (very 
> informative, thanks a lot :-) and consulted some other documents about this 
> and there it says to have a kernel command line such as "... gdb gdbttys=1 
> gdbbaud=115200". Now, should I just try to add "kgdb=ttys1" to that or 
> replace the previous command with it. Sorry if I am asking a stupid question 
> but this process is not very well documented... somehow...
>

The exact command can only be found in the kernel tree for that board.
Since we don't have the source code for your board, you have
to figure it out yourself.

For example, the way to figure what command Malta wants for kgdb
is to look at arch/mips/mips-boards/malta/malta_setup.c.

Jun

From fpga_dsp@yahoo.com.au Sat Jun 28 03:57:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Jun 2003 03:58:00 +0100 (BST)
Received: from web41205.mail.yahoo.com ([IPv6:::ffff:66.218.93.38]:20902 "HELO
	web41205.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224821AbTF1C56>; Sat, 28 Jun 2003 03:57:58 +0100
Message-ID: <20030628025749.40346.qmail@web41205.mail.yahoo.com>
Received: from [64.132.226.151] by web41205.mail.yahoo.com via HTTP; Sat, 28 Jun 2003 12:57:49 EST
Date: Sat, 28 Jun 2003 12:57:49 +1000 (EST)
From: =?iso-8859-1?q?fpga=20dsp?= <fpga_dsp@yahoo.com.au>
Subject: schedule() and mipsel processor
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2024463263-1056769069=:39713"
Content-Transfer-Encoding: 8bit
Return-Path: <fpga_dsp@yahoo.com.au>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2717
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fpga_dsp@yahoo.com.au
Precedence: bulk
X-list: linux-mips

--0-2024463263-1056769069=:39713
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi all,
 
I may ask a stupid question here but I have problem of calling any functions such as interruptible_sleep_on_timeout, sleep_on ... in a timer handler, the kernel just crash straight away in the function schedule(). Now I go and do a diff between kern/sched.c on i686 source and mipsel source. clearly , they are different. So the question is from kernel programming point of view, the bottom-half of interrupt handler is still considered interrupt handler? I don't see any platform dependent code in the scheduler at all. So why a mips scheduler is different from intel scheduler ?
 
Many thanks
 
Duy Do



---------------------------------
Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
--0-2024463263-1056769069=:39713
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Hi all,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I may ask a stupid question here but I have problem of calling any functions such as interruptible_sleep_on_timeout, sleep_on ... in a timer handler, the kernel just crash straight away in the function schedule(). Now I go and do a diff between kern/sched.c on i686 source and mipsel source. clearly , they are different. So the question is from kernel programming point of view, the bottom-half of interrupt handler is still considered interrupt handler? I don't see any platform dependent code in the scheduler at all. So why a mips scheduler is different from intel scheduler ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Many thanks</DIV>
<DIV>&nbsp;</DIV>
<DIV>Duy Do</DIV><p><br><hr size=1>
<a href="http://au.rd.yahoo.com/mail/tagline/?http://au.mobile.yahoo.com/sms/mail/index.html" target=_blank><b>Yahoo! Mobile</b></a><br>
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
--0-2024463263-1056769069=:39713--

From ppopov@mvista.com Sun Jun 29 02:58:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 Jun 2003 02:58:59 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:10997 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225197AbTF2B65>;
	Sun, 29 Jun 2003 02:58:57 +0100
Received: from [10.2.2.20] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA18672;
	Sat, 28 Jun 2003 18:58:47 -0700
Subject: Re: [PATCH] au1000_eth.c - Dave Jones
From: Pete Popov <ppopov@mvista.com>
To: joeg@clearcore.com
Cc: linux-mips@linux-mips.org
In-Reply-To: <20030614052652.8161.qmail@clearcore.com>
References: <20030614052652.8161.qmail@clearcore.com>
Content-Type: text/plain
Organization: 
Message-Id: <1056852170.1808.9.camel@adsl.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 28 Jun 2003 19:02:50 -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: 2718
X-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

Joe,

On Fri, 2003-06-13 at 22:26, Joe George wrote:
> This patch was submitted on lkml by Dave Jones and reviewed
> by Jeff Garzik.  Description:

In its exact form, the patch breaks the driver pretty badly.

> - Missing release region

OK.

> - Unneeded initialization of private struct
>   (already done in init_etherdev)

OK. But the "aup = dev->priv" was removed incorrectly. The pointer is
later used in the routine.

> - Remove unneeded freeing of dev-priv
>   (auto-free'd by kfree(dev)
> - actually kfree(dev), plugging leak.

No, the kfree(dev) can't be done there.  It probably should be done in
the cleanup_module routine but I haven't tested this driver as a module
in a very long time, so there may be other problems that need to get
fixed up.

The _probe1 routine allocs the dev structure and probe1 never gets
called again after the initialization. The eth0 and eth1 are both
brought up, but then eth1 is brought down because it's not in use. If
you do kfree(dev) in the _close routine, the next time you do "ifconfig
eth1 <ipaddress>" the driver will crash.  If eth1 is never used, then
the space allocated by "dev" is wasted ... but given that the dual macs
are probably some of the most widely used peripherals on that chip, I
doubt that that's a big problem.

I made these changes and applied the patch.

Pete

> Joe
> 
> 
> diff -upN linux-mips-cvs24/drivers/net/au1000_eth.c tst_mips24/drivers/net/au1000_eth.c
> --- linux-mips-cvs24/drivers/net/au1000_eth.c	Fri Jun 13 20:15:18 2003
> +++ tst_mips24/drivers/net/au1000_eth.c	Fri Jun 13 22:19:09 2003
> @@ -1110,38 +1110,21 @@ au1000_probe1(struct net_device *dev, lo
>  	char *pmac, *argptr;
>  	char ethaddr[6];
>  
> -	if (!request_region(PHYSADDR(ioaddr), MAC_IOSIZE, "Au1x00 ENET")) {
> +	if (!request_region(PHYSADDR(ioaddr), MAC_IOSIZE, "Au1x00 ENET"))
>  		 return -ENODEV;
> -	}
>  
>  	if (version_printed++ == 0) printk(version);
>  
>  	if (!dev) {
> -		dev = init_etherdev(0, sizeof(struct au1000_private));
> -	}
> -	if (!dev) {
> -		 printk (KERN_ERR "au1000 eth: init_etherdev failed\n");  
> -		 return -ENODEV;
> +		dev = init_etherdev(NULL, sizeof(struct au1000_private));
> +		printk (KERN_ERR "au1000 eth: init_etherdev failed\n");  
> +		release_region(ioaddr, MAC_IOSIZE);
> +		return -ENODEV;
>  	}
>  
>  	printk("%s: Au1xxx ethernet found at 0x%lx, irq %d\n", 
>  			dev->name, ioaddr, irq);
>  
> -	/* Initialize our private structure */
> -	if (dev->priv == NULL) {
> -		aup = (struct au1000_private *) 
> -			kmalloc(sizeof(*aup), GFP_KERNEL);
> -		if (aup == NULL) {
> -			retval = -ENOMEM;
> -			goto free_region;
> -		}
> -		dev->priv = aup;
> -	}
> -
> -	aup = dev->priv;
> -	memset(aup, 0, sizeof(*aup));
> -
> -
>  	/* Allocate the data buffers */
>  	aup->vaddr = (u32)dma_alloc(MAX_BUF_SIZE * 
>  			(NUM_TX_BUFFS+NUM_RX_BUFFS), &aup->dma_addr);
> @@ -1280,8 +1263,6 @@ free_region:
>  	if (aup->vaddr) 
>  		dma_free((void *)aup->vaddr, 
>  				MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS));
> -	if (dev->priv != NULL)
> -		kfree(dev->priv);
>  	kfree(aup->mii);
>  	kfree(dev);
>  	printk(KERN_ERR "%s: au1000_probe1 failed.  Returns %d\n",
> @@ -1450,15 +1431,15 @@ static int au1000_close(struct net_devic
>  	spin_lock_irqsave(&aup->lock, flags);
>  	
>  	/* stop the device */
> -	if (netif_device_present(dev)) {
> +	if (netif_device_present(dev))
>  		netif_stop_queue(dev);
> -	}
>  
>  	/* disable the interrupt */
>  	free_irq(dev->irq, dev);
>  	spin_unlock_irqrestore(&aup->lock, flags);
>  
>  	reset_mac(dev);
> +	kfree(dev);
>  	MOD_DEC_USE_COUNT;
>  	return 0;
>  }
> 
> 


From Geert.Uytterhoeven@sonycom.com Sun Jun 29 12:26:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 Jun 2003 12:26:39 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:50612 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224802AbTF2L0h>;
	Sun, 29 Jun 2003 12:26:37 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h5TBPwpI014085;
	Sun, 29 Jun 2003 13:25:58 +0200 (MEST)
Date: Sun, 29 Jun 2003 13:25:58 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: James Simmons <jsimmons@infradead.org>,
	Ralf Baechle <ralf@linux-mips.org>
cc: Linux Frame Buffer Device Development 
	<linux-fbdev-devel@lists.sourceforge.net>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: [PATCH] MIPS DEC/SGI Linux logo
Message-ID: <Pine.GSO.4.21.0306291324380.14478-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2719
X-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


MIPS: Show the correct logo on DEC and SGI machines.

--- linux-2.5.x/drivers/video/logo/logo.c.orig	Tue May 27 19:03:30 2003
+++ linux-2.5.x/drivers/video/logo/logo.c	Sat Jun 28 14:54:12 2003
@@ -66,7 +66,7 @@
 #endif
 #ifdef CONFIG_LOGO_DEC_CLUT224
 		/* DEC Linux logo on MIPS/MIPS64 */
-		if (mips_machgroup == MACH_GROUP_SGI)
+		if (mips_machgroup == MACH_GROUP_DEC)
 			logo = &logo_dec_clut224;
 #endif
 #ifdef CONFIG_LOGO_MAC_CLUT224

Gr{oetje,eeting}s,

						Geert

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

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


From ralf@linux-mips.org Sun Jun 29 13:00:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 Jun 2003 13:00:10 +0100 (BST)
Received: from p508B5A53.dip.t-dialin.net ([IPv6:::ffff:80.139.90.83]:12001
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224827AbTF2MAI>; Sun, 29 Jun 2003 13:00:08 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5TC01DB005130;
	Sun, 29 Jun 2003 14:00:01 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5TBxwTJ005122;
	Sun, 29 Jun 2003 13:59:58 +0200
Date: Sun, 29 Jun 2003 13:59:58 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: James Simmons <jsimmons@infradead.org>,
	Linux Frame Buffer Device Development 
	<linux-fbdev-devel@lists.sourceforge.net>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] MIPS DEC/SGI Linux logo
Message-ID: <20030629115958.GA5081@linux-mips.org>
References: <Pine.GSO.4.21.0306291324380.14478-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0306291324380.14478-100000@vervain.sonytel.be>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2720
X-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 Sun, Jun 29, 2003 at 01:25:58PM +0200, Geert Uytterhoeven wrote:

> MIPS: Show the correct logo on DEC and SGI machines.

Applied,

  Ralf

From ralf@linux-mips.org Sun Jun 29 18:35:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 Jun 2003 18:35:30 +0100 (BST)
Received: from p508B5A53.dip.t-dialin.net ([IPv6:::ffff:80.139.90.83]:32646
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224802AbTF2Rf0>; Sun, 29 Jun 2003 18:35:26 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h5THZODB012106;
	Sun, 29 Jun 2003 19:35:24 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h5THZN5O012103;
	Sun, 29 Jun 2003 19:35:23 +0200
Date: Sun, 29 Jun 2003 19:35:23 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: fpga dsp <fpga_dsp@yahoo.com.au>
Cc: linux-mips@linux-mips.org
Subject: Re: schedule() and mipsel processor
Message-ID: <20030629173522.GC9469@linux-mips.org>
References: <20030628025749.40346.qmail@web41205.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030628025749.40346.qmail@web41205.mail.yahoo.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2721
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Jun 28, 2003 at 12:57:49PM +1000, fpga dsp wrote:

> I may ask a stupid question here but I have problem of calling any functions such as interruptible_sleep_on_timeout, sleep_on ... in a timer handler, the kernel just crash straight away in the function schedule(). Now I go and do a diff between kern/sched.c on i686 source and mipsel source. clearly , they are different. So the question is from kernel programming point of view, the bottom-half of interrupt handler is still considered interrupt handler? I don't see any platform dependent code in the scheduler at all. So why a mips scheduler is different from intel scheduler ?

Bs.  There was no need to change kernel/sched.c at all so you're probably
simply diffing the wrong versions.

  Ralf

From achim.hensel@ruhr-uni-bochum.de Sun Jun 29 20:07:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 Jun 2003 20:07:42 +0100 (BST)
Received: from mout1.freenet.de ([IPv6:::ffff:194.97.50.132]:49049 "EHLO
	mout1.freenet.de") by linux-mips.org with ESMTP id <S8224802AbTF2THk>;
	Sun, 29 Jun 2003 20:07:40 +0100
Received: from [194.97.50.136] (helo=mx3.freenet.de)
	by mout1.freenet.de with asmtp (Exim 4.20)
	id 19WhWR-0004S7-AH
	for linux-mips@linux-mips.org; Sun, 29 Jun 2003 21:07:35 +0200
Received: from p508f70f0.dip.t-dialin.net ([80.143.112.240] helo=server.private.priv)
	by mx3.freenet.de with asmtp (ID aspam@freenet.de) (Exim 4.20 #1)
	id 19WhWQ-00074O-U4
	for linux-mips@linux-mips.org; Sun, 29 Jun 2003 21:07:35 +0200
Received: from physik.private.priv (physik.private.priv [192.168.1.10])
	by server.private.priv (8.12.6/8.12.6) with SMTP id h5TJ7Vlk021904
	for <linux-mips@linux-mips.org>; Sun, 29 Jun 2003 21:07:32 +0200 (CEST)
Date: Sun, 29 Jun 2003 21:11:36 +0200
From: Achim Hensel <achim.hensel@ruhr-uni-bochum.de>
To: Linux-mips Mailing-Liste <linux-mips@linux-mips.org>
Subject: Which toolchain? Trouble at kernel-starting
Message-Id: <20030629211136.23809a06.achim.hensel@ruhr-uni-bochum.de>
X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-portbld-freebsd4.7)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <achim.hensel@ruhr-uni-bochum.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: 2722
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: achim.hensel@ruhr-uni-bochum.de
Precedence: bulk
X-list: linux-mips

Hello, 

I want to start some work for the Indigo1 (IP20). So, I need a working
kernel.

At first I tried the tftpboot.img from the debian indy install. After
the tftpload, it stopped with a message "Yeee, could not determine
architecture type <SGI-IP20>" as expected.

Later I compiled a kernel with no changes, just as a starting point for
work. After some experience, I got it compiled, converted to ecoff and
loaded, but after the kernel load, the machine dies silently - no
messages, nothing. 

I used the sdelinux toolchain mentioned at the linux-mips homepage,
and the latest CVS 2.4-kernel from linux-mips, and some other toolchains
and kernels.

Does anybody have some idea, which toolchain/kernel source was used for
the debian tftp boot installer image?
 
(Or what might cause these symptoms?)

Thank you,
	Achim Hensel

From ilya@gateway.total-knowledge.com Sun Jun 29 23:57:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 Jun 2003 23:57:26 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:49537
	"HELO alpha.total-knowledge.com") by linux-mips.org with SMTP
	id <S8224802AbTF2W5X>; Sun, 29 Jun 2003 23:57:23 +0100
Received: (qmail 26180 invoked from network); 29 Jun 2003 15:51:58 -0000
Received: from unknown (HELO gateway.total-knowledge.com) (12.234.207.60)
  by alpha.total-knowledge.com with SMTP; 29 Jun 2003 15:51:58 -0000
Received: (qmail 30250 invoked by uid 502); 29 Jun 2003 22:57:19 -0000
Date: Sun, 29 Jun 2003 15:57:19 -0700
From: ilya@theIlya.com
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: meth.c
Message-ID: <20030629225719.GH13617@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="w/VI3ydZO+RcZ3Ux"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2723
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


--w/VI3ydZO+RcZ3Ux
Content-Type: multipart/mixed; boundary="QXO0/MSS4VvK6f+D"
Content-Disposition: inline


--QXO0/MSS4VvK6f+D
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Here is what I currently have for my O2 ethernet driver.
It still shows some weired behaviour sometimes, but works well enough to boot
and run O2 over NFS.


--QXO0/MSS4VvK6f+D
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="meth.diff"
Content-Transfer-Encoding: quoted-printable

Index: drivers/net/meth.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/linux/drivers/net/meth.c,v
retrieving revision 1.4
diff -u -r1.4 meth.c
--- drivers/net/meth.c	1 Jul 2002 20:01:25 -0000	1.4
+++ drivers/net/meth.c	29 Jun 2003 22:55:44 -0000
@@ -55,10 +55,6 @@
 MODULE_AUTHOR("Ilya Volynets");
 MODULE_DESCRIPTION("SGI O2 Builtin Fast Ethernet driver");
=20
-/* This is a load-time options */
-/*static int eth =3D 0;
-MODULE_PARM(eth, "i");*/
-
 #define HAVE_TX_TIMEOUT
 /* The maximum time waited (in jiffies) before assuming a Tx failed. (400m=
s) */
 #define TX_TIMEOUT (400*HZ/1000)
@@ -68,15 +64,13 @@
 MODULE_PARM(timeout, "i");
 #endif
=20
-int meth_eth;
-
 /*
  * This structure is private to each device. It is used to pass
  * packets in and out, so there is place for a packet
  */
=20
 typedef struct meth_private {
-    struct net_device_stats stats;
+	struct net_device_stats stats;
 	volatile struct meth_regs *regs;
 	u64 mode; /* in-memory copy of MAC control register */
 	int  phy_addr; /* address of phy, used by mdio_* functions, initialized i=
n mdio_probe*/
@@ -92,12 +86,12 @@
 	dma_addr_t rx_ring_dmas[RX_RING_ENTRIES];
 	int rx_write;
=20
-    spinlock_t meth_lock;
+	spinlock_t meth_lock;
 } meth_private;
=20
 extern struct net_device meth_devs[];
 void meth_tx_timeout (struct net_device *dev);
-void meth_interrupt(int irq, void *dev_id, struct pt_regs *pregs);
+irqreturn_t meth_interrupt(int irq, void *dev_id, struct pt_regs *pregs);
        =20
 /* global, initialized in ip32-setup.c */
 char o2meth_eaddr[8]=3D{0,0,0,0,0,0,0,0};
@@ -109,14 +103,9 @@
 	DPRINTK("Loading MAC Address: %02x:%02x:%02x:%02x:%02x:%02x\n",
 		(int)o2meth_eaddr[0]&0xFF,(int)o2meth_eaddr[1]&0xFF,(int)o2meth_eaddr[2]=
&0xFF,
 		(int)o2meth_eaddr[3]&0xFF,(int)o2meth_eaddr[4]&0xFF,(int)o2meth_eaddr[5]=
&0xFF);
-	//memcpy(dev->dev_addr,o2meth_eaddr+2,6);
 	for (i=3D0; i<6; i++)
 		dev->dev_addr[i]=3Do2meth_eaddr[i];
-	regs->mac_addr=3D //dev->dev_addr[0]|(dev->dev_addr[1]<<8)|
-					//dev->dev_addr[2]<<16|(dev->dev_addr[3]<<24)|
-					//dev->dev_addr[4]<<32|(dev->dev_addr[5]<<40);
-	(*(u64*)o2meth_eaddr)>>16;
-	DPRINTK("MAC, finally is %0lx\n",regs->mac_addr);
+	regs->mac_addr=3D(*(u64*)o2meth_eaddr)>>16;
 }
=20
 /*
@@ -124,19 +113,19 @@
  */
 #define WAIT_FOR_PHY(___regs, ___rval)			\
 	while((___rval=3D___regs->phy_data)&MDIO_BUSY){	\
-		udelay(25);								\
+		udelay(25);				\
 	}
 /*read phy register, return value read */
 static int mdio_read(meth_private *priv,int phyreg)
 {
 	volatile meth_regs* regs=3Dpriv->regs;
 	volatile u32 rval;
-	WAIT_FOR_PHY(regs,rval)
+	WAIT_FOR_PHY(regs,rval);
 	regs->phy_registers=3D(priv->phy_addr<<5)|(phyreg&0x1f);
 	udelay(25);
 	regs->phy_trans_go=3D1;
 	udelay(25);
-	WAIT_FOR_PHY(regs,rval)
+	WAIT_FOR_PHY(regs,rval);
 	return rval&MDIO_DATA_MASK;
 }
=20
@@ -145,14 +134,13 @@
 {
 	volatile meth_regs* regs=3Dpriv->regs;
 	int rval;
-///	DPRINTK("Trying to write value %i to reguster %i\n",val, pfyreg);
-	spin_lock_irq(&priv->meth_lock);
-	WAIT_FOR_PHY(regs,rval)
+	spin_lock(&priv->meth_lock);
+	WAIT_FOR_PHY(regs,rval);
 	regs->phy_registers=3D(priv->phy_addr<<5)|(pfyreg&0x1f);
 	regs->phy_data=3Dval;
 	udelay(25);
-	WAIT_FOR_PHY(regs,rval)
-	spin_unlock_irq(&priv->meth_lock);
+	WAIT_FOR_PHY(regs,rval);
+	spin_unlock(&priv->meth_lock);
 }
=20
 /* Modify phy register using given mask and value */
@@ -165,11 +153,6 @@
 	mdio_write(priv,phyreg,rval);
 }
=20
-/* handle errata data on MDIO bus */
-//static void mdio_errata(meth_private *priv)
-//{
-	/* Hmmm... what the hell is phyerrata? does it come from sys init paramet=
ers in IRIX */
-//}
 static int mdio_probe(meth_private *priv)
 {
 	int i, p2, p3;
@@ -177,25 +160,25 @@
 	/* check if phy is detected already */
 	if(priv->phy_addr>=3D0&&priv->phy_addr<32)
 		return 0;
-	spin_lock_irq(&priv->meth_lock);
+	spin_lock(&priv->meth_lock);
 	for (i=3D0;i<32;++i){
 		priv->phy_addr=3D(char)i;
 		p2=3Dmdio_read(priv,2);
 #ifdef MFE_DEBUG
 		p3=3Dmdio_read(priv,3);
 		switch ((p2<<12)|(p3>>4)){
-			case PHY_QS6612X:
-				DPRINTK("PHY is QS6612X\n");
-				break;
-			case PHY_ICS1889:
-				DPRINTK("PHY is ICS1889\n");
-				break;
-			case PHY_ICS1890:
-				DPRINTK("PHY is ICS1890\n");
-				break;
-			case PHY_DP83840:
-				DPRINTK("PHY is DP83840\n");
-				break;
+		case PHY_QS6612X:
+			DPRINTK("PHY is QS6612X\n");
+			break;
+		case PHY_ICS1889:
+			DPRINTK("PHY is ICS1889\n");
+			break;
+		case PHY_ICS1890:
+			DPRINTK("PHY is ICS1890\n");
+			break;
+		case PHY_DP83840:
+			DPRINTK("PHY is DP83840\n");
+			break;
 		}
 #endif
 		if(p2!=3D0xffff&&p2!=3D0x0000){
@@ -203,7 +186,7 @@
 			break;
 		}
 	}
-	spin_unlock_irq(&priv->meth_lock);
+	spin_unlock(&priv->meth_lock);
 	if(priv->phy_addr<32) {
 		return 0;
 	}
@@ -269,15 +252,9 @@
 static int meth_init_rx_ring(meth_private *priv)
 {
 	int i;
-	DPRINTK("Initializing RX ring\n");
 	for(i=3D0;i<RX_RING_ENTRIES;i++){
-		DPRINTK("\t1:\t%i\t",i);
-		/*if(!(priv->rx_ring[i]=3Dget_free_page(GFP_KERNEL)))
-			return -ENOMEM;
-		DPRINTK("\t2:\t%i\n",i);*/
 		priv->rx_ring[i]=3D(rx_packet*)pci_alloc_consistent(NULL,METH_RX_BUFF_SI=
ZE,&(priv->rx_ring_dmas[i]));
 		/* I'll need to re-sync it after each RX */
-		DPRINTK("\t%p\n",priv->rx_ring[i]);
 		priv->regs->rx_fifo=3Dpriv->rx_ring_dmas[i];
 	}
 	priv->rx_write =3D 0;
@@ -290,8 +267,8 @@
=20
 	/* Remove any pending skb */
 	for (i =3D 0; i < TX_RING_ENTRIES; i++) {
-	  if (priv->tx_skbs[i])
-		dev_kfree_skb(priv->tx_skbs[i]);
+		if (priv->tx_skbs[i])
+			dev_kfree_skb(priv->tx_skbs[i]);
 		priv->tx_skbs[i] =3D NULL;
 	}
 	pci_free_consistent(NULL,
@@ -318,7 +295,6 @@
 	priv->regs->mac_ctrl =3D SGI_MAC_RESET;
 	priv->regs->mac_ctrl =3D 0;
 	udelay(25);
-	DPRINTK("MAC control after reset: %016lx\n", priv->regs->mac_ctrl);
=20
 	/* Load ethernet address */
 	load_eaddr(dev, priv->regs);
@@ -341,7 +317,7 @@
=20
 	/* Now set dma control, but don't enable DMA, yet */
 	priv->regs->dma_ctrl=3D (4 << METH_RX_OFFSET_SHIFT) |
-		              (RX_RING_ENTRIES << METH_RX_DEPTH_SHIFT);
+		(RX_RING_ENTRIES << METH_RX_DEPTH_SHIFT);
=20
 	return(0);
 }
@@ -356,9 +332,20 @@
 {
 	meth_private *priv=3Ddev->priv;
 	volatile meth_regs *regs=3Dpriv->regs;
+	int ret;
=20
-	MOD_INC_USE_COUNT;
+	/* Initialize the hardware */
+	if((ret=3Dmeth_reset(dev)) < 0)
+	        return ret;
+
+	/* Allocate the ring buffers */
+	if((ret=3Dmeth_init_tx_ring(priv))<0||(ret=3Dmeth_init_rx_ring(priv))<0){
+		meth_free_tx_ring(priv);
+		meth_free_rx_ring(priv);
+		return ret;
+	}
=20
+	DPRINTK("Will set dma_ctl now\n");
 	/* Start DMA */
 	regs->dma_ctrl|=3D
 	        METH_DMA_TX_EN|/*METH_DMA_TX_INT_EN|*/
@@ -368,6 +355,7 @@
 		printk(KERN_ERR "%s: Can't get irq %d\n", dev->name, dev->irq);
 		return -EAGAIN;
 	}
+	DPRINTK("About to start queue\n");
 	netif_start_queue(dev);
 	DPRINTK("Opened... DMA control=3D0x%08lx\n", regs->dma_ctrl);
 	return 0;
@@ -375,14 +363,16 @@
=20
 int meth_release(struct net_device *dev)
 {
-    netif_stop_queue(dev); /* can't transmit any more */
+	meth_private *priv=3Ddev->priv;
+	netif_stop_queue(dev); /* can't transmit any more */
 	/* shut down dma */
 	((meth_private*)(dev->priv))->regs->dma_ctrl&=3D
 		~(METH_DMA_TX_EN|METH_DMA_TX_INT_EN|
-		METH_DMA_RX_EN|METH_DMA_RX_INT_EN);
+		  METH_DMA_RX_EN|METH_DMA_RX_INT_EN);
 	free_irq(dev->irq, dev);
-    MOD_DEC_USE_COUNT;
-    return 0;
+	meth_free_tx_ring(priv);
+	meth_free_rx_ring(priv);
+	return 0;
 }
=20
 /*
@@ -390,24 +380,24 @@
  */
 int meth_config(struct net_device *dev, struct ifmap *map)
 {
-    if (dev->flags & IFF_UP) /* can't act on a running interface */
-        return -EBUSY;
+	if (dev->flags & IFF_UP) /* can't act on a running interface */
+		return -EBUSY;
=20
-    /* Don't allow changing the I/O address */
-    if (map->base_addr !=3D dev->base_addr) {
-        printk(KERN_WARNING "meth: Can't change I/O address\n");
-        return -EOPNOTSUPP;
-    }
-
-    /* Allow changing the IRQ */
-    if (map->irq !=3D dev->irq) {
-        printk(KERN_WARNING "meth: Can't change IRQ\n");
-        return -EOPNOTSUPP;
-    }
+	/* Don't allow changing the I/O address */
+	if (map->base_addr !=3D dev->base_addr) {
+		printk(KERN_WARNING "meth: Can't change I/O address\n");
+		return -EOPNOTSUPP;
+	}
+
+	/* Don't allow changing the IRQ */
+	if (map->irq !=3D dev->irq) {
+		printk(KERN_WARNING "meth: Can't change IRQ\n");
+		return -EOPNOTSUPP;
+	}
 	DPRINTK("Configured\n");
=20
-    /* ignore other fields */
-    return 0;
+	/* ignore other fields */
+	return 0;
 }
=20
 /*
@@ -415,49 +405,62 @@
  */
 void meth_rx(struct net_device* dev)
 {
-    struct sk_buff *skb;
-    struct meth_private *priv =3D (struct meth_private *) dev->priv;
+	struct sk_buff *skb;
+	struct meth_private *priv =3D (struct meth_private *) dev->priv;
 	rx_packet *rxb;
-	DPRINTK("RX...\n");
-	// TEMP	while((rxb=3Dpriv->rx_ring[priv->rx_write])->status.raw&0x8000000=
000000000){
-	while((rxb=3Dpriv->rx_ring[priv->rx_write])->status.raw&0x800000000000000=
0){
-	        int len=3Drxb->status.parsed.rx_len - 4; /* omit CRC */
-		DPRINTK("(%i)\n",priv->rx_write);
+	int twptr=3Dpriv->rx_write;
+	u64 status;
+	spin_lock(&(priv->meth_lock));
+	while ((status=3D(rxb=3Dpriv->rx_ring[priv->rx_write])->status.raw)&0x800=
0000000000000)
+	{
+		int len=3D(status&0xFFFF) - 4; /* omit CRC */
 		/* length sanity check */
 		if(len < 60 || len > 1518) {
-		  printk(KERN_DEBUG "%s: bogus packet size: %d, status=3D%#2x.\n",
-			 dev->name, priv->rx_write, rxb->status.raw);
-		  priv->stats.rx_errors++;
-		  priv->stats.rx_length_errors++;
+			printk(KERN_DEBUG "%s: bogus packet size: %d, status=3D%#2lx.\n",
+			       dev->name, priv->rx_write, rxb->status.raw);
+			priv->stats.rx_errors++;
+			priv->stats.rx_length_errors++;
 		}
-		if(!(rxb->status.raw&METH_RX_STATUS_ERRORS)){
+		if(!(status&METH_RX_STATUS_ERRORS)){
 			skb=3Dalloc_skb(len+2,GFP_ATOMIC);/* Should be atomic -- we are in inte=
rrupt */
 			if(!skb){
 				/* Ouch! No memory! Drop packet on the floor */
-				DPRINTK("!!!>>>Ouch! Not enough Memory for RX buffer!\n");
 				priv->stats.rx_dropped++;
 			} else {
 				skb_reserve(skb, 2); /* align IP on 16B boundary */ =20
-    			memcpy(skb_put(skb, len), rxb->buf, len);
-			    /* Write metadata, and then pass to the receive level */
-			    skb->dev =3D dev;
-			    skb->protocol =3D eth_type_trans(skb, dev);
-				//skb->ip_summed =3D CHECKSUM_UNNECESSARY; /* don't check it */
-			  =20
-				DPRINTK("passing packet\n");
-				DPRINTK("len =3D %d rxb->status =3D %x\n",
-					len, rxb->status.raw);
-				netif_rx(skb);
+				memcpy(skb_put(skb, len), rxb->buf, len);
+				/* Write metadata, and then pass to the receive level */
+				skb->dev =3D dev;
+				skb->protocol =3D eth_type_trans(skb, dev);
+			=09
 				dev->last_rx =3D jiffies;
 				priv->stats.rx_packets++;
 				priv->stats.rx_bytes+=3Dlen;
-				DPRINTK("There we go... Whew...\n");
+				netif_rx(skb);
 			}
+		} else {
+			printk(KERN_WARNING "meth: RX error: status=3D0x%016lx\n",status);
+			if(status&METH_RX_ST_RCV_CODE_VIOLATION)
+				printk(KERN_WARNING "Receive Code Violation\n");
+			if(status&METH_RX_ST_CRC_ERR)
+				printk(KERN_WARNING "CRC error\n");
+			if(status&METH_RX_ST_INV_PREAMBLE_CTX)
+				printk(KERN_WARNING "Invalid Preamble Context\n");
+			if(status&METH_RX_ST_LONG_EVT_SEEN)
+				printk(KERN_WARNING "Long Event Seen...\n");
+			if(status&METH_RX_ST_BAD_PACKET)
+				printk(KERN_WARNING "Bad Packet\n");
+			if(status&METH_RX_ST_CARRIER_EVT_SEEN)
+				printk(KERN_WARNING "Carrier Event Seen\n");
 		}
+		rxb->status.raw=3D0;
 		priv->regs->rx_fifo=3Dpriv->rx_ring_dmas[priv->rx_write];
-		rxb->status.raw=3D0;	=09
 		priv->rx_write=3D(priv->rx_write+1)&(RX_RING_ENTRIES-1);
+		if(priv->rx_write=3D=3Dtwptr) {
+			DPRINTK("going rounds\n");
+		}
 	}
+	spin_unlock(&(priv->meth_lock));
 }
=20
 static int meth_tx_full(struct net_device *dev)
@@ -505,20 +508,10 @@
 /*
  * The typical interrupt entry point
  */
-void meth_interrupt(int irq, void *dev_id, struct pt_regs *pregs)
+irqreturn_t meth_interrupt(int irq, void *dev_id, struct pt_regs *pregs)
 {
 	struct meth_private *priv;
-	union {
-		u32	reg; /*Whole status register */
-		struct {
-			u32			:	2,
-				rx_seq	:	5,
-				tx_read	:	9,
-			=09
-				rx_read	:	8,
-				int_mask:	8;
-		} parsed;
-	} status;
+	u32 status;
 	/*
 	 * As usual, check the "device" pointer for shared handlers.
 	 * Then assign "struct device *dev"
@@ -526,33 +519,44 @@
 	struct net_device *dev =3D (struct net_device *)dev_id;
 	/* ... and check with hw if it's really ours */
=20
-	if (!dev /*paranoid*/ ) return;
+	if (!dev /*paranoid*/ ) return IRQ_HANDLED;
=20
-	/* Lock the device */
 	priv =3D (struct meth_private *) dev->priv;
=20
-	status.reg =3D priv->regs->int_flags;
+	status =3D priv->regs->int_flags;
    =20
-	DPRINTK("Interrupt, status %08x...\n",status.reg);
-	if (status.parsed.int_mask & METH_INT_RX_THRESHOLD) {
+	if (status & METH_INT_RX_THRESHOLD) {
 		/* send it to meth_rx for handling */
 		meth_rx(dev);
 	}
=20
-	if (status.parsed.int_mask & (METH_INT_TX_EMPTY|METH_INT_TX_PKT)) {
+	if (status & (METH_INT_TX_EMPTY|METH_INT_TX_PKT)) {
 		/* a transmission is over: free the skb */
-		meth_tx_cleanup(dev, status.parsed.tx_read);
+		meth_tx_cleanup(dev, (priv->regs->tx_info&TX_INFO_RPTR)>>16);
 	}
 	/* check for errors too... */
-	if (status.parsed.int_mask & (METH_INT_TX_LINK_FAIL))
+	if (status & (METH_INT_TX_LINK_FAIL))
 		printk(KERN_WARNING "meth: link failure\n");
-	if (status.parsed.int_mask & (METH_INT_MEM_ERROR))
+	if (status & (METH_INT_MEM_ERROR))
 		printk(KERN_WARNING "meth: memory error\n");
-	if (status.parsed.int_mask & (METH_INT_TX_ABORT))
+	if (status & (METH_INT_TX_ABORT))
 		printk(KERN_WARNING "meth: aborted\n");
-	DPRINTK("Interrupt handling done...\n");
-=09
-	priv->regs->int_flags=3Dstatus.reg&0xff; /* clear interrupts */
+	if (status & (METH_INT_RX_OVERFLOW))
+		printk(KERN_WARNING "meth: RX overflow\n");
+	if (status & (METH_INT_RX_UNDERFLOW))
+		printk(KERN_WARNING "meth: RX underflow\n");
+
+#define METH_INT_ERROR	(METH_INT_TX_LINK_FAIL| \
+			METH_INT_MEM_ERROR| \
+			METH_INT_TX_ABORT| \
+			METH_INT_RX_OVERFLOW| \
+			METH_INT_RX_UNDERFLOW)
+	if( status & METH_INT_ERROR) {
+		printk(KERN_WARNING "meth: error status: 0x%08x\n",status);
+		netif_wake_queue(dev);
+	}
+	priv->regs->int_flags=3Dstatus&0xff; /* clear interrupts */
+	return IRQ_HANDLED;
 }
=20
 /*
@@ -563,13 +567,11 @@
 	tx_packet *desc=3D&priv->tx_ring[priv->tx_write];
 	int len =3D (skb->len<ETH_ZLEN)?ETH_ZLEN:skb->len;
=20
-	DPRINTK("preparing short packet\n");
 	/* maybe I should set whole thing to 0 first... */
 	memcpy(desc->data.dt+(120-len),skb->data,skb->len);
 	if(skb->len < len)
 		memset(desc->data.dt+120-len+skb->len,0,len-skb->len);
 	desc->header.raw=3DMETH_TX_CMD_INT_EN|(len-1)|((128-len)<<16);
-	DPRINTK("desc=3D%016lx\n",desc->header.raw);
 }
 #define TX_CATBUF1 BIT(25)
 static void meth_tx_1page_prepare(meth_private* priv, struct sk_buff* skb)
@@ -580,13 +582,6 @@
 	int buffer_len =3D skb->len - unaligned_len;
 	dma_addr_t catbuf;
=20
-	DPRINTK("preparing 1 page...\n");
-	DPRINTK("length=3D%d data=3D%p\n", skb->len, skb->data);
-	DPRINTK("unaligned_len=3D%d\n", unaligned_len);
-	DPRINTK("buffer_data=3D%p buffer_len=3D%d\n",
-	       buffer_data,
-	       buffer_len);
-
 	desc->header.raw=3DMETH_TX_CMD_INT_EN|TX_CATBUF1|(skb->len-1);
=20
 	/* unaligned part */
@@ -601,11 +596,8 @@
 				buffer_data,
 				buffer_len,
 				PCI_DMA_TODEVICE);
-	DPRINTK("catbuf=3D%x\n", catbuf);
 	desc->data.cat_buf[0].form.start_addr =3D catbuf >> 3;
 	desc->data.cat_buf[0].form.len =3D buffer_len-1;
-	DPRINTK("desc=3D%016lx\n",desc->header.raw);
-	DPRINTK("cat_buf[0].raw=3D%016lx\n",desc->data.cat_buf[0].raw);
 }
 #define TX_CATBUF2 BIT(26)
 static void meth_tx_2page_prepare(meth_private* priv, struct sk_buff* skb)
@@ -618,16 +610,6 @@
 	int buffer2_len =3D skb->len - buffer1_len - unaligned_len;
 	dma_addr_t catbuf1, catbuf2;
=20
-	DPRINTK("preparing 2 pages... \n");
-	DPRINTK("length=3D%d data=3D%p\n", skb->len, skb->data);
-	DPRINTK("unaligned_len=3D%d\n", unaligned_len);
-	DPRINTK("buffer1_data=3D%p buffer1_len=3D%d\n",
-	       buffer1_data,
-	       buffer1_len);
-	DPRINTK("buffer2_data=3D%p buffer2_len=3D%d\n",
-	       buffer2_data,
-	       buffer2_len);
-
 	desc->header.raw=3DMETH_TX_CMD_INT_EN|TX_CATBUF1|TX_CATBUF2|(skb->len-1);
 	/* unaligned part */
 	if(unaligned_len){
@@ -641,7 +623,6 @@
 				 buffer1_data,
 				 buffer1_len,
 				 PCI_DMA_TODEVICE);
-	DPRINTK("catbuf1=3D%x\n", catbuf1);
 	desc->data.cat_buf[0].form.start_addr =3D catbuf1 >> 3;
 	desc->data.cat_buf[0].form.len =3D buffer1_len-1;
 	/* second page */
@@ -649,18 +630,12 @@
 				 buffer2_data,
 				 buffer2_len,
 				 PCI_DMA_TODEVICE);
-	DPRINTK("catbuf2=3D%x\n", catbuf2);
 	desc->data.cat_buf[1].form.start_addr =3D catbuf2 >> 3;
 	desc->data.cat_buf[1].form.len =3D buffer2_len-1;
-	DPRINTK("desc=3D%016lx\n",desc->header.raw);
-	DPRINTK("cat_buf[0].raw=3D%016lx\n",desc->data.cat_buf[0].raw);
-	DPRINTK("cat_buf[1].raw=3D%016lx\n",desc->data.cat_buf[1].raw);
 }
=20
-
 void meth_add_to_tx_ring(meth_private *priv, struct sk_buff* skb)
 {
-	DPRINTK("Transmitting data...\n");
 	if(skb->len <=3D 120) {
 		/* Whole packet fits into descriptor */
 		meth_tx_short_prepare(priv,skb);
@@ -676,7 +651,7 @@
 	/* Remember the skb, so we can free it at interrupt time */
 	priv->tx_skbs[priv->tx_write] =3D skb;
 	priv->tx_write =3D (priv->tx_write+1) & (TX_RING_ENTRIES-1);
-	priv->regs->tx_info.wptr =3D priv->tx_write;
+	priv->regs->tx_info =3D priv->tx_write;
 	priv->tx_count ++;
 	/* Enable DMA transfer */
 	priv->regs->dma_ctrl |=3D METH_DMA_TX_INT_EN;
@@ -689,18 +664,18 @@
 {
 	struct meth_private *priv =3D (struct meth_private *) dev->priv;
=20
-	spin_lock_irq(&priv->meth_lock);
+	spin_lock(&priv->meth_lock);
=20
 	meth_add_to_tx_ring(priv, skb);
 	dev->trans_start =3D jiffies; /* save the timestamp */
=20
 	/* If TX ring is full, tell the upper layer to stop sending packets */
 	if (meth_tx_full(dev)) {
-	        DPRINTK("TX full: stopping\n");
+	        printk("TX full: stopping\n");
 		netif_stop_queue(dev);
 	}
=20
-	spin_unlock_irq(&priv->meth_lock);
+	spin_unlock(&priv->meth_lock);
=20
 	return 0;
 }
@@ -716,9 +691,9 @@
 	printk(KERN_WARNING "%s: transmit timed out\n", dev->name);
=20
 	/* Protect against concurrent rx interrupts */
-	spin_lock_irq(&priv->meth_lock);
+	spin_lock(&priv->meth_lock);
=20
-	/* Try to reset the adaptor. */
+	/* Try to reset the interface. */
 	meth_reset(dev);
=20
 	priv->stats.tx_errors++;
@@ -733,7 +708,7 @@
 	priv->regs->dma_ctrl|=3DMETH_DMA_TX_EN|METH_DMA_RX_EN|METH_DMA_RX_INT_EN;
=20
 	/* Enable interrupt */
-	spin_unlock_irq(&priv->meth_lock);
+	spin_unlock(&priv->meth_lock);
=20
 	dev->trans_start =3D jiffies;
 	netif_wake_queue(dev);
@@ -747,8 +722,8 @@
 int meth_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 {
 =20
-    DPRINTK("ioctl\n");
-    return 0;
+	DPRINTK("ioctl\n");
+	return 0;
 }
=20
 /*
@@ -756,8 +731,8 @@
  */
 struct net_device_stats *meth_stats(struct net_device *dev)
 {
-    struct meth_private *priv =3D (struct meth_private *) dev->priv;
-    return &priv->stats;
+	struct meth_private *priv =3D (struct meth_private *) dev->priv;
+	return &priv->stats;
 }
=20
 /*
@@ -767,7 +742,6 @@
 int meth_init(struct net_device *dev)
 {
 	meth_private *priv;
-	int ret;
 	/*=20
 	 * Then, assign other fields in dev, using ether_setup() and some
 	 * hand assignments
@@ -806,20 +780,9 @@
 	dev->base_addr=3DSGI_MFE;
 	priv->phy_addr =3D -1; /* No phy is known yet... */
=20
-	/* Initialize the hardware */
-	if((ret=3Dmeth_reset(dev)) < 0)
-	        return ret;
-
-	/* Allocate the ring buffers */
-	if((ret=3Dmeth_init_tx_ring(priv))<0||(ret=3Dmeth_init_rx_ring(priv))<0){
-		meth_free_tx_ring(priv);
-		meth_free_rx_ring(priv);
-		return ret;
-	}
-
 	printk("SGI O2 Fast Ethernet rev. %ld\n", priv->regs->mac_ctrl >> 29);
=20
-    return 0;
+	return 0;
 }
=20
 /*
@@ -827,7 +790,7 @@
  */
=20
 struct net_device meth_devs[1] =3D {
-    { init: meth_init, }  /* init, nothing more */
+	{ init: meth_init, }  /* init, nothing more */
 };
=20
 /*
@@ -844,18 +807,15 @@
 		printk("meth: error %i registering device \"%s\"\n",
 		       result, meth_devs->name);
 	else device_present++;
-#ifndef METH_DEBUG
-	EXPORT_NO_SYMBOLS;
-#endif
 =09
 	return device_present ? 0 : -ENODEV;
 }
=20
 void meth_cleanup(void)
 {
-    kfree(meth_devs->priv);
-    unregister_netdev(meth_devs);
-    return;
+	kfree(meth_devs->priv);
+	unregister_netdev(meth_devs);
+	return;
 }
=20
 module_init(meth_init_module);
Index: drivers/net/meth.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/cvs/linux/drivers/net/meth.h,v
retrieving revision 1.2
diff -u -r1.2 meth.h
--- drivers/net/meth.h	1 Jul 2002 20:01:25 -0000	1.2
+++ drivers/net/meth.h	29 Jun 2003 22:55:45 -0000
@@ -85,7 +85,7 @@
 } tx_packet;
=20
 typedef union rx_status_vector {
-	struct {
+	volatile struct {
 		u64		pad1:1;/*fill it with ones*/
 		u64		pad2:15;/*fill with 0*/
 		u64		ip_chk_sum:16;
@@ -103,7 +103,7 @@
 		u64		rx_code_violation:1;
 		u64		rx_len:16;
 	} parsed;
-	u64 raw;
+	volatile u64 raw;
 } rx_status_vector;
=20
 typedef struct rx_packet {
@@ -113,6 +113,8 @@
 	char buf[METH_RX_BUFF_SIZE-sizeof(rx_status_vector)-3*sizeof(u64)-sizeof(=
u16)];/* data */
 } rx_packet;
=20
+#define TX_INFO_RPTR    0x00FF0000
+#define TX_INFO_WPTR    0x000000FF
 typedef struct meth_regs {
 	u64		mac_ctrl;		/*0x00,rw,31:0*/
 	u64		int_flags;		/*0x08,rw,30:0*/
@@ -120,10 +122,7 @@
 	u64		timer;			/*0x18,rw,5:0*/
 	u64		int_tx;			/*0x20,wo,0:0*/
 	u64		int_rx;			/*0x28,wo,9:4*/
-	struct {
-		u32 tx_info_pad;
-		u32 rptr:16,wptr:16;
-	}		tx_info;		/*0x30,rw,31:0*/
+	u64             tx_info;		/*0x30,rw,31:0*/
 	u64		tx_info_al;		/*0x38,rw,31:0*/
 	struct {
 		u32	rx_buff_pad1;

--QXO0/MSS4VvK6f+D--

--w/VI3ydZO+RcZ3Ux
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+/27P7sVBmHZT8w8RAm7iAKCa84SHcecXKPO1jmIK8K873S/1FwCgxwVH
Vc+5o32DkFi4GJkCH/Z+jFI=
=IUrM
-----END PGP SIGNATURE-----

--w/VI3ydZO+RcZ3Ux--

From agx@sigxcpu.org Mon Jun 30 00:06:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Jun 2003 00:06:35 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:14219
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8224802AbTF2XGc>; Mon, 30 Jun 2003 00:06:32 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 2B9512BC41; Mon, 30 Jun 2003 01:06:30 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 05228-03;
 Mon, 30 Jun 2003 01:06:27 +0200 (CEST)
Received: from bogon.sigxcpu.org (kons-d9bb55c2.pool.mediaWays.net [217.187.85.194])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 43ED92BC36; Mon, 30 Jun 2003 01:06:27 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 9F95F1737D; Mon, 30 Jun 2003 01:05:46 +0200 (CEST)
Date: Mon, 30 Jun 2003 01:05:46 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: Achim Hensel <achim.hensel@ruhr-uni-bochum.de>
Cc: linux-mips@linux-mips.org
Subject: Re: Which toolchain? Trouble at kernel-starting
Message-ID: <20030629230546.GA10792@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	Achim Hensel <achim.hensel@ruhr-uni-bochum.de>,
	linux-mips@linux-mips.org
References: <20030629211136.23809a06.achim.hensel@ruhr-uni-bochum.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv"
Content-Disposition: inline
In-Reply-To: <20030629211136.23809a06.achim.hensel@ruhr-uni-bochum.de>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20021227-p2 (Debian)
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2724
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips


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

On Sun, Jun 29, 2003 at 09:11:36PM +0200, Achim Hensel wrote:
> I want to start some work for the Indigo1 (IP20). So, I need a working
> kernel.
Several people worked on IP20 already. Maybe it's easier to start from
their work.

> Does anybody have some idea, which toolchain/kernel source was used for
> the debian tftp boot installer image?
apt-get source kernel-patch-2.4.19-mips
with Debian's GCC 2.95.4 and binutils about 2.12.90.0.1.
 -- Guido

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

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

iD8DBQE+/3DKn88szT8+ZCYRAiR+AJ9/fpV06ah4NLEVOUSeDqaTajWQqACfQ8HB
JFWksbpFHUF6pw+HHuDxsvw=
=2jeM
-----END PGP SIGNATURE-----

--ZGiS0Q5IWpPtfppv--

From ilya@gateway.total-knowledge.com Mon Jun 30 01:36:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Jun 2003 01:36:44 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:53889
	"HELO alpha.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225209AbTF3Agl>; Mon, 30 Jun 2003 01:36:41 +0100
Received: (qmail 17309 invoked from network); 29 Jun 2003 17:31:08 -0000
Received: from unknown (HELO gateway.total-knowledge.com) (12.234.207.60)
  by alpha.total-knowledge.com with SMTP; 29 Jun 2003 17:31:08 -0000
Received: (qmail 6242 invoked by uid 502); 30 Jun 2003 00:36:36 -0000
Date: Sun, 29 Jun 2003 17:36:36 -0700
From: ilya@theIlya.com
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
Subject: ip32 specific stuff
Message-ID: <20030630003636.GI13617@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="mGCtrYeZ202LI9ZG"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2725
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

This is the patch that includes most of things that I have in IP32-specific
parts of my tree.
1. IRQ handling rewrite by me and Vivien.
2. Propper memory detection pathc by Keith.
3. Some other minor fixlets.


--mGCtrYeZ202LI9ZG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ip32.diff"
Content-Transfer-Encoding: quoted-printable

Index: arch/mips/sgi-ip32/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/cvs/linux/arch/mips/sgi-ip32/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- arch/mips/sgi-ip32/Makefile	13 Jun 2003 13:58:31 -0000	1.7
+++ arch/mips/sgi-ip32/Makefile	30 Jun 2003 00:25:00 -0000
@@ -4,6 +4,6 @@
 #
=20
 obj-y	+=3D ip32-berr.o ip32-rtc.o ip32-setup.o ip32-irq.o ip32-irq-glue.o \
-	   ip32-timer.o crime.o ip32-reset.o
+	   ip32-timer.o crime.o ip32-reset.o ip32-memory.o
=20
 EXTRA_AFLAGS :=3D $(CFLAGS)
Index: arch/mips/sgi-ip32/crime.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/linux/arch/mips/sgi-ip32/crime.c,v
retrieving revision 1.2
diff -u -r1.2 crime.c
--- arch/mips/sgi-ip32/crime.c	6 Aug 2002 00:08:57 -0000	1.2
+++ arch/mips/sgi-ip32/crime.c	30 Jun 2003 00:25:00 -0000
@@ -3,13 +3,17 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
- * Copyright (C) 2001 Keith M Wesolowski
+ * Copyright (C) 2001, 2003 Keith M Wesolowski
  */
+#include <asm/ip32/crime.h>
+#include <asm/ptrace.h>
+#include <asm/bootinfo.h>
+#include <asm/page.h>
+#include <asm/mipsregs.h>
 #include <linux/types.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
-#include <asm/ip32/crime.h>
-#include <asm/ptrace.h>
+#include <linux/interrupt.h>
=20
 void __init crime_init (void)
 {
@@ -18,32 +22,75 @@
=20
 	id =3D (id & CRIME_ID_IDBITS) >> 4;
=20
-	printk ("CRIME id %1lx rev %ld detected at %016lx\n", id, rev,
+	printk ("CRIME id %1lx rev %ld detected at 0x%016lx\n", id, rev,
 		(unsigned long) CRIME_BASE);
 }
=20
-/* XXX Like on Sun, these give us various useful information to printk. */
-void crime_memerr_intr (unsigned int irq, void *dev_id, struct pt_regs *re=
gs)
+irqreturn_t crime_memerr_intr (unsigned int irq, void *dev_id, struct pt_r=
egs *regs)
 {
 	u64 memerr =3D crime_read_64 (CRIME_MEM_ERROR_STAT);
 	u64 addr =3D crime_read_64 (CRIME_MEM_ERROR_ADDR);
+	int fatal =3D 0;
+
 	memerr &=3D CRIME_MEM_ERROR_STAT_MASK;
+	addr &=3D CRIME_MEM_ERROR_ADDR_MASK;
+
+	printk("CRIME memory error at 0x%08lx ST 0x%08lx<", addr, memerr);
=20
-	printk ("CRIME memory error at physaddr 0x%08lx status %08lx\n",
-		addr << 2, memerr);
+	if (memerr & CRIME_MEM_ERROR_INV)
+		printk("INV,");
+	if (memerr & CRIME_MEM_ERROR_ECC) {
+		u64 ecc_syn =3D crime_read_64(CRIME_MEM_ERROR_ECC_SYN);
+		u64 ecc_gen =3D crime_read_64(CRIME_MEM_ERROR_ECC_CHK);
+
+		ecc_syn &=3D CRIME_MEM_ERROR_ECC_SYN_MASK;
+		ecc_gen &=3D CRIME_MEM_ERROR_ECC_CHK_MASK;
+
+		printk("ECC,SYN=3D0x%08lx,GEN=3D0x%08lx,", ecc_syn, ecc_gen);
+	}
+	if (memerr & CRIME_MEM_ERROR_MULTIPLE) {
+		fatal =3D 1;
+		printk("MULTIPLE,");
+	}
+	if (memerr & CRIME_MEM_ERROR_HARD_ERR) {
+		fatal =3D 1;
+		printk("HARD,");
+	}
+	if (memerr & CRIME_MEM_ERROR_SOFT_ERR)
+		printk("SOFT,");
+	if (memerr & CRIME_MEM_ERROR_CPU_ACCESS)
+		printk("CPU,");
+	if (memerr & CRIME_MEM_ERROR_VICE_ACCESS)
+		printk("VICE,");
+	if (memerr & CRIME_MEM_ERROR_GBE_ACCESS)
+		printk("GBE,");
+	if (memerr & CRIME_MEM_ERROR_RE_ACCESS)
+		printk("RE,REID=3D0x%02lx,", (memerr & CRIME_MEM_ERROR_RE_ID)>>8);
+	if (memerr & CRIME_MEM_ERROR_MACE_ACCESS)
+		printk("MACE,MACEID=3D0x%02lx,", memerr & CRIME_MEM_ERROR_MACE_ID);
=20
 	crime_write_64 (CRIME_MEM_ERROR_STAT, 0);
+
+	if (fatal) {
+		printk("FATAL>\n");
+		panic("Fatal memory error detected, halting\n");
+	} else {
+		printk("NONFATAL>\n");
+	}
+
+	return IRQ_HANDLED;
 }
=20
-void crime_cpuerr_intr (unsigned int irq, void *dev_id, struct pt_regs *re=
gs)
+irqreturn_t crime_cpuerr_intr (unsigned int irq, void *dev_id, struct pt_r=
egs *regs)
 {
 	u64 cpuerr =3D crime_read_64 (CRIME_CPU_ERROR_STAT);
 	u64 addr =3D crime_read_64 (CRIME_CPU_ERROR_ADDR);
 	cpuerr &=3D CRIME_CPU_ERROR_MASK;
 	addr <<=3D 2UL;
=20
-	printk ("CRIME CPU interface error detected at %09lx status %08lx\n",
+	printk ("CRIME CPU error detected at 0x%09lx status 0x%08lx\n",
 		addr, cpuerr);
=20
 	crime_write_64 (CRIME_CPU_ERROR_STAT, 0);
+	return IRQ_HANDLED;
 }
Index: arch/mips/sgi-ip32/ip32-berr.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/linux/arch/mips/sgi-ip32/ip32-berr.c,v
retrieving revision 1.4
diff -u -r1.4 ip32-berr.c
--- arch/mips/sgi-ip32/ip32-berr.c	14 Apr 2003 16:33:24 -0000	1.4
+++ arch/mips/sgi-ip32/ip32-berr.c	30 Jun 2003 00:25:00 -0000
@@ -9,6 +9,7 @@
  */
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/sched.h>
 #include <asm/traps.h>
 #include <asm/uaccess.h>
 #include <asm/addrspace.h>
Index: arch/mips/sgi-ip32/ip32-irq.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/linux/arch/mips/sgi-ip32/ip32-irq.c,v
retrieving revision 1.5
diff -u -r1.5 ip32-irq.c
--- arch/mips/sgi-ip32/ip32-irq.c	16 Apr 2003 13:02:43 -0000	1.5
+++ arch/mips/sgi-ip32/ip32-irq.c	30 Jun 2003 00:25:00 -0000
@@ -28,6 +28,10 @@
 #include <asm/ip32/mace.h>
 #include <asm/signal.h>
=20
+/* issue a PIO read to make sure no PIO writes are pending */
+#define flush_crime_bus() crime_read_64(CRIME_CONTROL);
+#define flush_mace_bus() mace_read_64(MACEISA_FLASH_NIC_REG);
+
 #undef DEBUG_IRQ
 #ifdef DEBUG_IRQ
 #define DBG(x...) printk(x)
@@ -103,9 +107,9 @@
  */
=20
 /* Some initial interrupts to set up */
-extern void crime_memerr_intr (unsigned int irq, void *dev_id,
+extern irqreturn_t crime_memerr_intr (int irq, void *dev_id,
 			       struct pt_regs *regs);
-extern void crime_cpuerr_intr (unsigned int irq, void *dev_id,
+extern irqreturn_t crime_cpuerr_intr (int irq, void *dev_id,
 			       struct pt_regs *regs);
=20
 struct irqaction memerr_irq =3D { crime_memerr_intr, SA_INTERRUPT,
@@ -163,13 +167,13 @@
  * We get to split the register in half and do faster lookups.
  */
=20
+static u64 crime_mask=3D0;
+
 static void enable_crime_irq(unsigned int irq)
 {
-	u64 crime_mask;
 	unsigned long flags;
=20
 	local_irq_save(flags);
-	crime_mask =3D crime_read_64(CRIME_INT_MASK);
 	crime_mask |=3D 1 << (irq - 1);
 	crime_write_64(CRIME_INT_MASK, crime_mask);
 	local_irq_restore(flags);
@@ -177,35 +181,35 @@
=20
 static unsigned int startup_crime_irq(unsigned int irq)
 {
+        crime_mask =3D crime_read_64(CRIME_INT_MASK);
 	enable_crime_irq(irq);
 	return 0; /* This is probably not right; we could have pending irqs */
 }
=20
 static void disable_crime_irq(unsigned int irq)
 {
-	u64 crime_mask;
 	unsigned long flags;
=20
 	local_irq_save(flags);
-	crime_mask =3D crime_read_64(CRIME_INT_MASK);
 	crime_mask &=3D ~(1 << (irq - 1));
 	crime_write_64(CRIME_INT_MASK, crime_mask);
+	flush_crime_bus();
 	local_irq_restore(flags);
 }
=20
 static void mask_and_ack_crime_irq (unsigned int irq)
 {
-	u64 crime_mask;
 	unsigned long flags;
=20
 	/* Edge triggered interrupts must be cleared. */
 	if ((irq >=3D CRIME_GBE0_IRQ && irq <=3D CRIME_GBE3_IRQ)
 	    || (irq >=3D CRIME_RE_EMPTY_E_IRQ && irq <=3D CRIME_RE_IDLE_E_IRQ)
 	    || (irq >=3D CRIME_SOFT0_IRQ && irq <=3D CRIME_SOFT2_IRQ)) {
+	        u64 crime_int;
 		local_irq_save(flags);
-		crime_mask =3D crime_read_64(CRIME_HARD_INT);
-		crime_mask &=3D ~(1 << (irq - 1));
-		crime_write_64(CRIME_HARD_INT, crime_mask);
+		crime_int =3D crime_read_64(CRIME_HARD_INT);
+		crime_int &=3D ~(1 << (irq - 1));
+		crime_write_64(CRIME_HARD_INT, crime_int);
 		local_irq_restore(flags);
 	}
 	disable_crime_irq(irq);
@@ -236,42 +240,39 @@
  * next chunk of the CRIME register in one piece.
  */
=20
+static u32 macepci_mask;
+
 static void enable_macepci_irq(unsigned int irq)
 {
-	u32 mace_mask;
-	u64 crime_mask;
 	unsigned long flags;
=20
 	local_irq_save(flags);
-	mace_mask =3D mace_read_32(MACEPCI_CONTROL);
-	mace_mask |=3D MACEPCI_CONTROL_INT(irq - 9);
-	mace_write_32(MACEPCI_CONTROL, mace_mask);
-	/*
-	 * In case the CRIME interrupt isn't enabled, we must enable it;
-	 * however, we never disable interrupts at that level.
-	 */
-	crime_mask =3D crime_read_64(CRIME_INT_MASK);
-	crime_mask |=3D 1 << (irq - 1);
-	crime_write_64(CRIME_INT_MASK, crime_mask);
+	macepci_mask |=3D MACEPCI_CONTROL_INT(irq - 9);
+	mace_write_32(MACEPCI_CONTROL, macepci_mask);
+        crime_mask |=3D 1 << (irq - 1);
+        crime_write_64(CRIME_INT_MASK, crime_mask);
 	local_irq_restore(flags);
 }
=20
 static unsigned int startup_macepci_irq(unsigned int irq)
 {
-	enable_macepci_irq (irq);
-
-	return 0; /* XXX */
+	crime_mask =3D crime_read_64 (CRIME_INT_MASK);
+	macepci_mask =3D mace_read_32(MACEPCI_CONTROL);
+  	enable_macepci_irq (irq);
+	return 0;
 }
=20
 static void disable_macepci_irq(unsigned int irq)
 {
-	u32 mace_mask;
 	unsigned long flags;
=20
 	local_irq_save(flags);
-	mace_mask =3D mace_read_32(MACEPCI_CONTROL);
-	mace_mask &=3D ~MACEPCI_CONTROL_INT(irq - 9);
-	mace_write_32(MACEPCI_CONTROL, mace_mask);
+	crime_mask &=3D ~(1 << (irq - 1));
+	crime_write_64(CRIME_INT_MASK, crime_mask);
+	flush_crime_bus();
+	macepci_mask &=3D ~MACEPCI_CONTROL_INT(irq - 9);
+	mace_write_32(MACEPCI_CONTROL, macepci_mask);
+	flush_mace_bus();
 	local_irq_restore(flags);
 }
=20
@@ -299,10 +300,10 @@
  * CRIME register.
  */
=20
+u32 maceisa_mask =3D 0;
+
 static void enable_maceisa_irq (unsigned int irq)
 {
-	u64 crime_mask;
-	u32 mace_mask;
 	unsigned int crime_int =3D 0;
 	unsigned long flags;
=20
@@ -321,46 +322,56 @@
 	}
 	DBG ("crime_int %016lx enabled\n", crime_int);
 	local_irq_save(flags);
-	crime_mask =3D crime_read_64(CRIME_INT_MASK);
 	crime_mask |=3D crime_int;
 	crime_write_64(CRIME_INT_MASK, crime_mask);
-	mace_mask =3D mace_read_32(MACEISA_INT_MASK);
-	mace_mask |=3D 1 << (irq - 33);
-	mace_write_32(MACEISA_INT_MASK, mace_mask);
+	maceisa_mask |=3D 1 << (irq - 33);
+	mace_write_32(MACEISA_INT_MASK, maceisa_mask);
 	local_irq_restore(flags);
 }
=20
 static unsigned int startup_maceisa_irq (unsigned int irq)
 {
+	crime_mask =3D crime_read_64 (CRIME_INT_MASK);
+	maceisa_mask =3D mace_read_32(MACEISA_INT_MASK);
 	enable_maceisa_irq(irq);
 	return 0;
 }
=20
 static void disable_maceisa_irq(unsigned int irq)
 {
-	u32 mace_mask;
+	unsigned int crime_int =3D 0;
 	unsigned long flags;
=20
 	local_irq_save(flags);
-	mace_mask =3D mace_read_32(MACEISA_INT_MASK);
-	mace_mask &=3D ~(1 << (irq - 33));
-	mace_write_32(MACEISA_INT_MASK, mace_mask);
+	maceisa_mask &=3D ~(1 << (irq - 33));
+        if(!(maceisa_mask & MACEISA_AUDIO_INT))
+		crime_int |=3D MACE_AUDIO_INT;
+        if(!(maceisa_mask & MACEISA_MISC_INT))
+		crime_int |=3D MACE_MISC_INT;
+        if(!(maceisa_mask & MACEISA_SUPERIO_INT))
+		crime_int |=3D MACE_SUPERIO_INT;
+	crime_mask &=3D ~crime_int;
+	crime_write_64(CRIME_INT_MASK, crime_mask);
+	flush_crime_bus();
+	mace_write_32(MACEISA_INT_MASK, maceisa_mask);
+	flush_mace_bus();
 	local_irq_restore(flags);
 }
=20
 static void mask_and_ack_maceisa_irq(unsigned int irq)
 {
-	u32 mace_mask;
+	u32 mace_int;
 	unsigned long flags;
=20
 	switch (irq) {
 	case MACEISA_PARALLEL_IRQ:
 	case MACEISA_SERIAL1_TDMAPR_IRQ:
 	case MACEISA_SERIAL2_TDMAPR_IRQ:
+		/* edge triggered */
 		local_irq_save(flags);
-		mace_mask =3D mace_read_32(MACEISA_INT_STAT);
-		mace_mask &=3D ~(1 << (irq - 33));
-		mace_write_32(MACEISA_INT_STAT, mace_mask);
+		mace_int =3D mace_read_32(MACEISA_INT_STAT);
+		mace_int &=3D ~(1 << (irq - 33));
+		mace_write_32(MACEISA_INT_STAT, mace_int);
 		local_irq_restore(flags);
 		break;
 	}
@@ -392,11 +403,9 @@
=20
 static void enable_mace_irq(unsigned int irq)
 {
-	u64 crime_mask;
 	unsigned long flags;
=20
 	local_irq_save(flags);
-	crime_mask =3D crime_read_64 (CRIME_INT_MASK);
 	crime_mask |=3D 1 << (irq - 1);
 	crime_write_64 (CRIME_INT_MASK, crime_mask);
 	local_irq_restore (flags);
@@ -404,19 +413,19 @@
=20
 static unsigned int startup_mace_irq(unsigned int irq)
 {
+        crime_mask =3D crime_read_64 (CRIME_INT_MASK);
 	enable_mace_irq(irq);
 	return 0;
 }
=20
 static void disable_mace_irq(unsigned int irq)
 {
-	u64 crime_mask;
 	unsigned long flags;
=20
 	local_irq_save(flags);
-	crime_mask =3D crime_read_64 (CRIME_INT_MASK);
 	crime_mask &=3D ~(1 << (irq - 1));
 	crime_write_64 (CRIME_INT_MASK, crime_mask);
+	flush_crime_bus();
 	local_irq_restore(flags);
 }
=20
@@ -446,9 +455,12 @@
 	u32 mace;
=20
 	printk ("Unknown interrupt occurred!\n");
-	printk ("cp0_status: %08x\tcp0_cause: %08x\n",
-		read_c0_status(),
-		read_c0_cause());
+	printk ("cp0_status: %08x\n",
+		read_c0_status ());
+	printk ("cp0_cause: %08x\n",
+		read_c0_cause ());
+//	printk ("badvaddr: %08x\n",
+//		read_32bit_cp0_register (CP0_BADVADDR));
 	crime =3D crime_read_64 (CRIME_INT_MASK);
 	printk ("CRIME interrupt mask: %016lx\n", crime);
 	crime =3D crime_read_64 (CRIME_INT_STAT);
@@ -465,7 +477,7 @@
 	printk("Register dump:\n");
 	show_regs(regs);
=20
-	printk("Please mail this report to linux-mips@oss.sgi.com\n");
+	printk("Please mail this report to linux-mips@linux-mips.org\n");
 	printk("Spinning...");
 	while(1) ;
 }
@@ -474,43 +486,18 @@
 void ip32_irq0(struct pt_regs *regs)
 {
 	u64 crime_int;
-	u64 crime_mask;
 	int irq =3D 0;
-	unsigned long flags;
=20
-	local_irq_save(flags);
-	/* disable crime interrupts */
-	crime_mask =3D crime_read_64(CRIME_INT_MASK);
-	crime_write_64(CRIME_INT_MASK, 0);
-
-	crime_int =3D crime_read_64(CRIME_INT_STAT);
-
-	if (crime_int & CRIME_MACE_INT_MASK) {
-		crime_int &=3D CRIME_MACE_INT_MASK;
-		irq =3D ffs (crime_int);
-	} else if (crime_int & CRIME_MACEISA_INT_MASK) {
-		u32 mace_int;
-		mace_int =3D mace_read_32 (MACEISA_INT_STAT);
-		if (mace_int =3D=3D 0)
-			irq =3D 0;
-		else
-			irq =3D ffs (mace_int) + 32;
-	} else if (crime_int & CRIME_MACEPCI_INT_MASK) {
-		crime_int &=3D CRIME_MACEPCI_INT_MASK;
-		crime_int >>=3D 8;
-		irq =3D ffs (crime_int) + 8;
-	} else if (crime_int & 0xffff0000) {
-		crime_int >>=3D 16;
-		irq =3D ffs (crime_int) + 16;
+	crime_int =3D crime_read_64(CRIME_INT_STAT) & crime_mask;
+        irq =3D ffs(crime_int);
+        crime_int =3D 1ULL << (irq - 1);
+
+	if (crime_int & CRIME_MACEISA_INT_MASK) {
+		u32 mace_int =3D mace_read_32 (MACEISA_INT_STAT) & maceisa_mask;
+                irq =3D ffs (mace_int) + 32;
 	}
-	if (irq =3D=3D 0)
-		ip32_unknown_interrupt(regs);
 	DBG("*irq %u*\n", irq);
 	do_IRQ(irq, regs);
-
-	/* enable crime interrupts */
-	crime_write_64(CRIME_INT_MASK, crime_mask);
-	local_irq_restore (flags);
 }
=20
 void ip32_irq1(struct pt_regs *regs)
Index: arch/mips/sgi-ip32/ip32-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/cvs/linux/arch/mips/sgi-ip32/ip32-setup.c,v
retrieving revision 1.4
diff -u -r1.4 ip32-setup.c
--- arch/mips/sgi-ip32/ip32-setup.c	14 Apr 2003 16:33:24 -0000	1.4
+++ arch/mips/sgi-ip32/ip32-setup.c	30 Jun 2003 00:25:00 -0000
@@ -13,6 +13,8 @@
 #include <linux/mc146818rtc.h>
 #include <linux/param.h>
 #include <linux/init.h>
+#include <linux/console.h>
+#include <linux/bootmem.h>
=20
 #include <asm/time.h>
 #include <asm/mipsregs.h>
@@ -28,7 +30,6 @@
 extern u32 cc_interval;
=20
 #ifdef CONFIG_SGI_O2MACE_ETH
-
 /*
  * This is taken care of in here 'cause they say using Arc later on is
  * problematic
@@ -59,19 +60,41 @@
 }
 #endif
=20
+#ifdef CONFIG_FB_SGIO2
+#include "../../../drivers/video/sgio2fb.h"
+void *sgio2fb_mem;
+#endif
+
+void __init ip32_devsetup(void)
+{
+#ifdef CONFIG_FB_SGIO2
+	sgio2fb_mem=3D__alloc_bootmem(TILE_PTR_SIZE<<TILE_SHIFT, TILE_SIZE,__pa(M=
AX_DMA_ADDRESS));
+#endif
+#ifdef CONFIG_SGI_O2MACE_ETH
+	{
+		char *mac=3DArcGetEnvironmentVariable("eaddr");
+		str2eaddr(o2meth_eaddr, mac);
+	}
+#endif
+}
+
 extern void ip32_time_init(void);
-extern void ip32_reboot_setup(void);
+extern void ip32_be_init(void);
=20
 void __init ip32_setup(void)
 {
-#ifdef CONFIG_SERIAL_CONSOLE
+#if defined(CONFIG_SERIAL_CONSOLE) || defined(CONFIG_SERIAL_MACE_SGIO2)
 	char *ctype;
 #endif
 	TLBMISS_HANDLER_SETUP ();
=20
 	mips_io_port_base =3D UNCACHEDADDR(MACEPCI_HI_IO);;
=20
-#ifdef CONFIG_SERIAL_CONSOLE
+#ifdef CONFIG_SERIAL_MACE_SGIO2
+#warning O2MACECONSOLE compiled in
+	o2serial_console_init();
+#endif
+#if defined(CONFIG_SERIAL_CONSOLE) || defined(CONFIG_SERIAL_MACE_SGIO2)
 	ctype =3D ArcGetEnvironmentVariable("console");
 	if (*ctype =3D=3D 'd') {
 		if (ctype[1] =3D=3D '2')
@@ -80,26 +103,16 @@
 			console_setup ("ttyS0");
 	}
 #endif
-#ifdef CONFIG_SGI_O2MACE_ETH
-	{
-		char *mac=3DArcGetEnvironmentVariable("eaddr");
-		str2eaddr(o2meth_eaddr, mac);
-	}
-#endif
-
+	ip32_devsetup();
 #ifdef CONFIG_VT
+# ifdef CONFIG_DUMMY_CONSOLE
 	conswitchp =3D &dummy_con;
+# endif
 #endif
-
 	rtc_ops =3D &ip32_rtc_ops;
 	board_be_init =3D ip32_be_init;
 	board_time_init =3D ip32_time_init;
+	board_timer_setup =3D NULL;
=20
 	crime_init ();
-}
-
-int __init page_is_ram (unsigned long pagenr)
-{
-	/* XXX: to do? */
-	return 1;
 }
Index: include/asm-mips64/ip32/crime.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/cvs/linux/include/asm-mips64/ip32/crime.h,v
retrieving revision 1.3
diff -u -r1.3 crime.h
--- include/asm-mips64/ip32/crime.h	27 Jun 2002 14:27:11 -0000	1.3
+++ include/asm-mips64/ip32/crime.h	30 Jun 2003 00:25:06 -0000
@@ -11,7 +11,9 @@
 #ifndef __ASM_CRIME_H__
 #define __ASM_CRIME_H__
=20
+#include <asm/types.h>
 #include <asm/addrspace.h>
+#include <asm/io64.h>
=20
 /*
  * Address map
@@ -23,12 +25,8 @@
 #endif
=20
 #ifndef __ASSEMBLY__
-static inline u64 crime_read_64 (unsigned long __offset) {
-        return *((volatile u64 *) (CRIME_BASE + __offset));
-}
-static inline void crime_write_64 (unsigned long __offset, u64 __val) {
-        *((volatile u64 *) (CRIME_BASE + __offset)) =3D __val;
-}
+#define crime_read_64(__offset)		__in64(CRIME_BASE+(__offset))
+#define crime_write_64(__offset,__val)	__out64(__val,CRIME_BASE+(__offset))
 #endif
=20
 #undef BIT
@@ -179,11 +177,9 @@
  * macros for CRIME memory bank control registers.
  */
 #define CRIME_MEM_BANK_CONTROL(__bank)		(0x00000208 + ((__bank) << 3))
-#define CRIME_MEM_BANK_CONTROL_MSK		0x11f /* 9 bits 7:5 reserved */
+#define CRIME_MEM_BANK_CONTROL_MASK		0x11f /* 9 bits 7:5 reserved */
 #define CRIME_MEM_BANK_CONTROL_ADDR		0x01f
 #define CRIME_MEM_BANK_CONTROL_SDRAM_SIZE	0x100
-#define CRIME_MEM_BANK_CONTROL_BANK_TO_ADDR(__bank) \
-	(((__bank) & CRIME_MEM_BANK_CONTROL_ADDR) << 25)
=20
 #define CRIME_MEM_REFRESH_COUNTER	(0x00000248)
 #define CRIME_MEM_REFRESH_COUNTER_MASK	0x7ff	/* 11-bit register */
@@ -206,8 +202,10 @@
 #define CRIME_MEM_ERROR_SOFT_ERR	0x00100000
 #define CRIME_MEM_ERROR_HARD_ERR	0x00200000
 #define CRIME_MEM_ERROR_MULTIPLE	0x00400000
+#define CRIME_MEM_ERROR_ECC		0x01800000
 #define CRIME_MEM_ERROR_MEM_ECC_RD	0x00800000
 #define CRIME_MEM_ERROR_MEM_ECC_RMW	0x01000000
+#define CRIME_MEM_ERROR_INV		0x0e000000
 #define CRIME_MEM_ERROR_INV_MEM_ADDR_RD	0x02000000
 #define CRIME_MEM_ERROR_INV_MEM_ADDR_WR	0x04000000
 #define CRIME_MEM_ERROR_INV_MEM_ADDR_RMW	0x08000000
Index: include/asm-mips64/ip32/mace.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/cvs/linux/include/asm-mips64/ip32/mace.h,v
retrieving revision 1.6
diff -u -r1.6 mace.h
--- include/asm-mips64/ip32/mace.h	7 Apr 2003 02:28:45 -0000	1.6
+++ include/asm-mips64/ip32/mace.h	30 Jun 2003 00:25:06 -0000
@@ -12,7 +12,8 @@
 #define __ASM_MACE_H__
=20
 #include <asm/addrspace.h>
-
+#include <asm/system.h>
+#include <asm/io64.h>
 /*
  * Address map
  */
@@ -50,8 +51,7 @@
 #define MACEPCI_SWAPPED_VIEW		0
 #define MACEPCI_NATIVE_VIEW		0x40000000
 #define MACEPCI_IO			0x80000000
-/*#define MACEPCI_HI_MEMORY		0x0000000280000000UL * This mipght be just 0x=
0000000200000000UL 2G more :) (or maybe it is different between 1.1 & 1.5 */
-#define MACEPCI_HI_MEMORY		0x0000000200000000UL /* This mipght be just 0x0=
000000200000000UL 2G more :) (or maybe it is different between 1.1 & 1.5 */
+#define MACEPCI_HI_MEMORY		0x0000000200000000UL
 #define MACEPCI_HI_IO			0x0000000100000000UL
=20
 /*
@@ -130,7 +130,9 @@
 #define MACEISA_EPP_BASE   	(MACE_ISA_EXT		  )
 #define MACEISA_ECP_BASE   	(MACE_ISA_EXT + 0x00008000)
 #define MACEISA_SER1_BASE	(MACE_ISA_EXT + 0x00010000)
+#define MACEISA_SER1_REGS       (MACE_ISA_BASE + 0x00020000)
 #define MACEISA_SER2_BASE	(MACE_ISA_EXT + 0x00018000)
+#define MACEISA_SER2_REGS       (MACE_ISA_BASE + 0x00030000)
 #define MACEISA_RTC_BASE	(MACE_ISA_EXT + 0x00020000)
 #define MACEISA_GAME_BASE	(MACE_ISA_EXT + 0x00030000)
=20
@@ -138,6 +140,8 @@
  * Ringbase address and reset register - 64 bits
  */
 #define MACEISA_RINGBASE	MACE_ISA_BASE
+/* Ring buffers occupy 8 4K buffers */
+#define MACEISA_RINGBUFFERS_SIZE 8*4*1024
=20
 /*
  * Flash-ROM/LED/DP-RAM/NIC Controller Register - 64 bits (?)
@@ -197,6 +201,61 @@
 #define MACEISA_SERIAL2_RDMAT_INT	BIT (30)
 #define MACEISA_SERIAL2_RDMAOR_INT	BIT (31)
=20
+#define MACEI2C_CONFIG	MACE_I2C_BASE
+#define MACEI2C_CONTROL	(MACE_I2C_BASE|0x10)
+#define MACEI2C_DATA	(MACE_I2C_BASE|0x18)
+
+/* Bits for I2C_CONFIG */
+#define MACEI2C_RESET           BIT(0)
+#define MACEI2C_FAST            BIT(1)
+#define MACEI2C_DATA_OVERRIDE   BIT(2)
+#define MACEI2C_CLOCK_OVERRIDE  BIT(3)
+#define MACEI2C_DATA_STATUS     BIT(4)
+#define MACEI2C_CLOCK_STATUS    BIT(5)
+
+/* Bits for I2C_CONTROL */
+#define MACEI2C_NOT_IDLE        BIT(0)	/* write: 0=3Dforce idle
+				         * read: 0=3Didle 1=3Dnot idle */
+#define MACEI2C_DIR		BIT(1)	/* 0=3Dwrite 1=3Dread */
+#define MACEI2C_MORE_BYTES	BIT(2)	/* 0=3Dlast byte 1=3Dmore bytes */
+#define MACEI2C_TRANS_BUSY	BIT(4)	/* 0=3Dtrans done 1=3Dtrans busy */
+#define MACEI2C_NACK	        BIT(5)	/* 0=3Dack received 1=3Dack not */
+#define MACEI2C_BUS_ERROR	BIT(7)	/* 0=3Dno bus err 1=3Dbus err */
+
+
+#define MACEISA_AUDIO_INT (MACEISA_AUDIO_SW_INT |               \
+                           MACEISA_AUDIO_SC_INT |               \
+                           MACEISA_AUDIO1_DMAT_INT |            \
+                           MACEISA_AUDIO1_OF_INT |              \
+                           MACEISA_AUDIO2_DMAT_INT |            \
+                           MACEISA_AUDIO2_MERR_INT |            \
+                           MACEISA_AUDIO3_DMAT_INT |            \
+                           MACEISA_AUDIO3_MERR_INT)
+#define MACEISA_MISC_INT (MACEISA_RTC_INT |                     \
+                          MACEISA_KEYB_INT |                    \
+                          MACEISA_KEYB_POLL_INT |               \
+                          MACEISA_MOUSE_INT |                   \
+                          MACEISA_MOUSE_POLL_INT |              \
+                          MACEISA_TIMER0_INT |                  \
+                          MACEISA_TIMER1_INT |                  \
+                          MACEISA_TIMER2_INT)
+#define MACEISA_SUPERIO_INT (MACEISA_PARALLEL_INT |             \
+                             MACEISA_PAR_CTXA_INT |             \
+                             MACEISA_PAR_CTXB_INT |             \
+                             MACEISA_PAR_MERR_INT |             \
+                             MACEISA_SERIAL1_INT |              \
+                             MACEISA_SERIAL1_TDMAT_INT |        \
+                             MACEISA_SERIAL1_TDMAPR_INT |       \
+                             MACEISA_SERIAL1_TDMAME_INT |       \
+                             MACEISA_SERIAL1_RDMAT_INT |        \
+                             MACEISA_SERIAL1_RDMAOR_INT |       \
+                             MACEISA_SERIAL2_INT |              \
+                             MACEISA_SERIAL2_TDMAT_INT |        \
+                             MACEISA_SERIAL2_TDMAPR_INT |       \
+                             MACEISA_SERIAL2_TDMAME_INT |       \
+                             MACEISA_SERIAL2_RDMAT_INT |        \
+                             MACEISA_SERIAL2_RDMAOR_INT)
+
 #ifndef __ASSEMBLY__
 #include <asm/types.h>
=20
@@ -220,7 +279,7 @@
=20
 static inline u64 mace_read_64 (unsigned long __offset)
 {
-	return *((volatile u64 *) (MACE_BASE + __offset));
+	return __in64 (MACE_BASE + __offset);
 }
=20
 static inline void mace_write_8 (unsigned long __offset, u8 __val)
@@ -240,7 +299,7 @@
=20
 static inline void mace_write_64 (unsigned long __offset, u64 __val)
 {
-	*((volatile u64 *) (MACE_BASE + __offset)) =3D __val;
+	__out64 (__val, MACE_BASE + __offset);
 }
=20
 /* Call it whenever device needs to read data from main memory coherently =
*/
@@ -248,6 +307,17 @@
 {
 /*	mace_write_32(MACEPCI_WFLUSH,0xffffffff);*/
 }
+
+/* MACE ISA ring buffers access */
+void maceisa_init(void);
+void* maceisa_audio_input_ring(void);
+/* num - audio channel number: 0 or 1 */
+void* maceisa_audio_output_ring(int num);
+void* maceisa_scratch_ring(void);
+/* num - number of serial port: 0 or 1 */
+void* maceisa_serial_tx_ring(int num);
+void* maceisa_serial_rx_ring(int num);
+
 #endif /* !__ASSEMBLY__ */
=20
=20
--- /dev/null	Sun Jul 17 16:46:18 1994
+++ include/asm-mips64/io64.h	Sun Jun 15 10:35:18 2003
@@ -0,0 +1,99 @@
+/*
+ * 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) 2000, 2001 Broadcom Corporation
+ * Copyright (C) 2002 Ralf Baechle
+ * Copyright (C) 2003 Keith M Wesolowski
+ */
+
+#ifndef __ASM_IO64_H
+#define __ASM_IO64_H
+
+#include <linux/types.h>
+
+/* Generic 64-bit I/O register reads and writes.  This does no byte-swappi=
ng
+ * as it makes little sense and no platform that needs this is insane enou=
gh
+ * to require it.
+ */
+
+#ifndef __ASSEMBLY__
+#if _MIPS_SZLONG >=3D 64
+static inline u64 __in64(unsigned long addr)
+{
+	return *(volatile u64 *)addr;
+}
+
+static inline void __out64(u64 val, unsigned long addr)
+{
+	*(volatile u64 *)addr =3D val;
+}
+
+#define in64(a)		__in64(a)
+#define out64(v,a)	__out64(v,a)
+
+#else /* _MIPS_SZLONG < 64 */
+
+#include <asm/system.h>
+
+static inline u64 __in64(unsigned long addr)
+{
+	u64 res;
+
+	asm volatile (
+		"	.set	mips3				\n"
+		"	ld	%L0, (%1)	# __in64	\n"
+		"	dsra	%M0, %L0, 32			\n"
+		"	sll	%L0, 0				\n"
+		"	.set	mips0				\n"
+		: "=3Dr" (res)
+		: "r" (addr)
+	);
+
+	return res;
+}
+
+static inline u64 in64(unsigned long addr)
+{
+	unsigned long flags;
+	u64 res;
+
+	local_irq_save(flags);
+	res =3D __in64(addr);
+	local_irq_restore(flags);
+
+	return res;
+}
+
+static inline void __out64(u64 val, unsigned long addr)
+{
+	u64 tmp;
+
+	asm volatile (
+		"	.set	mips3				\n"
+		"	dsll	%L0, 32		# __out64	\n"
+		"	dsll	%M0, 32				\n"
+		"	dsrl	%L0, 32				\n"
+		"	or	%L0, %M0			\n"
+		"	sd	%L0, (%2)			\n"
+		"	.set	mips0				\n"
+		: "=3D&r" (tmp)
+		: "0" (val), "r" (addr)
+		: "memory"
+	);
+}
+
+static inline void out64(u64 val, unsigned long addr)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+	__out64(val, addr);
+	local_irq_restore(flags);
+}
+#endif /* _MIPS_SZLONG */
+#endif /* !__ASSEMBLY__ */
+
+
+#endif /* __ASM_IO64_H */
--- /dev/null	Sun Jul 17 16:46:18 1994
+++ include/asm-mips/io64.h	Sun Jun 15 10:35:18 2003
@@ -0,0 +1,99 @@
+/*
+ * 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) 2000, 2001 Broadcom Corporation
+ * Copyright (C) 2002 Ralf Baechle
+ * Copyright (C) 2003 Keith M Wesolowski
+ */
+
+#ifndef __ASM_IO64_H
+#define __ASM_IO64_H
+
+#include <linux/types.h>
+
+/* Generic 64-bit I/O register reads and writes.  This does no byte-swappi=
ng
+ * as it makes little sense and no platform that needs this is insane enou=
gh
+ * to require it.
+ */
+
+#ifndef __ASSEMBLY__
+#if _MIPS_SZLONG >=3D 64
+static inline u64 __in64(unsigned long addr)
+{
+	return *(volatile u64 *)addr;
+}
+
+static inline void __out64(u64 val, unsigned long addr)
+{
+	*(volatile u64 *)addr =3D val;
+}
+
+#define in64(a)		__in64(a)
+#define out64(v,a)	__out64(v,a)
+
+#else /* _MIPS_SZLONG < 64 */
+
+#include <asm/system.h>
+
+static inline u64 __in64(unsigned long addr)
+{
+	u64 res;
+
+	asm volatile (
+		"	.set	mips3				\n"
+		"	ld	%L0, (%1)	# __in64	\n"
+		"	dsra	%M0, %L0, 32			\n"
+		"	sll	%L0, 0				\n"
+		"	.set	mips0				\n"
+		: "=3Dr" (res)
+		: "r" (addr)
+	);
+
+	return res;
+}
+
+static inline u64 in64(unsigned long addr)
+{
+	unsigned long flags;
+	u64 res;
+
+	local_irq_save(flags);
+	res =3D __in64(addr);
+	local_irq_restore(flags);
+
+	return res;
+}
+
+static inline void __out64(u64 val, unsigned long addr)
+{
+	u64 tmp;
+
+	asm volatile (
+		"	.set	mips3				\n"
+		"	dsll	%L0, 32		# __out64	\n"
+		"	dsll	%M0, 32				\n"
+		"	dsrl	%L0, 32				\n"
+		"	or	%L0, %M0			\n"
+		"	sd	%L0, (%2)			\n"
+		"	.set	mips0				\n"
+		: "=3D&r" (tmp)
+		: "0" (val), "r" (addr)
+		: "memory"
+	);
+}
+
+static inline void out64(u64 val, unsigned long addr)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+	__out64(val, addr);
+	local_irq_restore(flags);
+}
+#endif /* _MIPS_SZLONG */
+#endif /* !__ASSEMBLY__ */
+
+
+#endif /* __ASM_IO64_H */
--- /dev/null	Sun Jul 17 16:46:18 1994
+++ arch/mips/sgi-ip32/ip32-memory.c	Sun Jun  1 18:55:04 2003
@@ -0,0 +1,37 @@
+/*
+ * 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) 2003 Keith M Wesolowski
+ */
+#include <asm/ip32/crime.h>
+#include <asm/bootinfo.h>
+#include <asm/page.h>
+#include <asm/pgtable.h>
+#include <asm/pgalloc.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+
+void __init prom_meminit (void)
+{
+	u64 base, size;
+	int bank;
+
+	for (bank=3D0; bank < CRIME_MAXBANKS; bank++) {
+		u64 bankctl =3D crime_read_64(CRIME_MEM_BANK_CONTROL(bank));
+		base =3D (bankctl & CRIME_MEM_BANK_CONTROL_ADDR) << 25;
+		if (bank !=3D 0 && base =3D=3D 0)
+			continue;
+		size =3D (bankctl & CRIME_MEM_BANK_CONTROL_SDRAM_SIZE) ? 128 : 32;
+		printk("CRIME MC: bank %d base 0x%016lx size %luMB\n",
+			bank, base, size);
+		size <<=3D 20;
+		if (base + size > (256 << 20))
+			continue;
+		add_memory_region (base, size, BOOT_MEM_RAM);
+	}
+}
+
+void __init prom_free_prom_memory (void) { }

--mGCtrYeZ202LI9ZG--

From ilya@gateway.total-knowledge.com Mon Jun 30 04:13:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Jun 2003 04:13:43 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:57985
	"HELO alpha.total-knowledge.com") by linux-mips.org with SMTP
	id <S8224802AbTF3DNl>; Mon, 30 Jun 2003 04:13:41 +0100
Received: (qmail 19180 invoked from network); 29 Jun 2003 20:07:58 -0000
Received: from unknown (HELO gateway.total-knowledge.com) (12.234.207.60)
  by alpha.total-knowledge.com with SMTP; 29 Jun 2003 20:07:58 -0000
Received: (qmail 24800 invoked by uid 502); 30 Jun 2003 03:13:38 -0000
Date: Sun, 29 Jun 2003 20:13:38 -0700
From: ilya@theIlya.com
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: ip32 timer setup fix
Message-ID: <20030630031338.GK13617@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="C01fF7hLGvN0zd9s"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2726
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

Attached is patch to fix timer setup on IP32.


--C01fF7hLGvN0zd9s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ip32-timer.diff"

Index: arch/mips/sgi-ip32/ip32-timer.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip32/ip32-timer.c,v
retrieving revision 1.12
diff -u -r1.12 ip32-timer.c
--- arch/mips/sgi-ip32/ip32-timer.c	29 Jun 2003 21:59:13 -0000	1.12
+++ arch/mips/sgi-ip32/ip32-timer.c	30 Jun 2003 03:07:47 -0000
@@ -45,11 +45,17 @@
 #define USECS_PER_JIFFY (1000000/HZ)
 
 
+static irqreturn_t cc_timer_interrupt(int irq, void *dev_id, struct pt_regs * regs);
+
 void __init ip32_timer_setup (struct irqaction *irq)
 {
 	u64 crime_time;
 	u32 cc_tick;
 
+
+	write_c0_count(0);
+	irq->handler = cc_timer_interrupt;
+
 	printk("Calibrating system timer... ");
 
 	crime_time = crime_read_64(CRIME_TIME) & CRIME_TIME_MASK;
@@ -70,12 +76,14 @@
 	printk("%d MHz CPU detected\n", (int) (cc_interval / PER_MHZ));
 
 	setup_irq (CLOCK_IRQ, irq);
+#define ALLINTS (IE_IRQ0 | IE_IRQ1 | IE_IRQ2 | IE_IRQ3 | IE_IRQ4 | IE_IRQ5)
+	/* Set ourselves up for future interrupts */
+	write_c0_compare(read_c0_count() + cc_interval);
+        change_c0_status(ST0_IM, ALLINTS);
+	local_irq_enable();
 }
 
-struct irqaction irq0  = { NULL, SA_INTERRUPT, 0,
-			   "timer", NULL, NULL};
-
-irqreturn_t cc_timer_interrupt(int irq, void *dev_id, struct pt_regs * regs)
+static irqreturn_t cc_timer_interrupt(int irq, void *dev_id, struct pt_regs * regs)
 {
 	u32 count;
 
@@ -150,15 +158,4 @@
 	xtime.tv_sec = mktime(year, mon, day, hour, min, sec);
 	xtime.tv_nsec = 0;
 	write_sequnlock_irq(&xtime_lock);
-
-	write_c0_count(0);
-	irq0.handler = cc_timer_interrupt;
-
-	ip32_timer_setup (&irq0);
-
-#define ALLINTS (IE_IRQ0 | IE_IRQ1 | IE_IRQ2 | IE_IRQ3 | IE_IRQ4 | IE_IRQ5)
-	/* Set ourselves up for future interrupts */
-	write_c0_compare(read_c0_count() + cc_interval);
-        change_c0_status(ST0_IM, ALLINTS);
-	local_irq_enable();
 }
Index: arch/mips/sgi-ip32/ip32-setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip32/ip32-setup.c,v
retrieving revision 1.4
diff -u -r1.4 ip32-setup.c
--- arch/mips/sgi-ip32/ip32-setup.c	14 Apr 2003 16:33:24 -0000	1.4
+++ arch/mips/sgi-ip32/ip32-setup.c	30 Jun 2003 03:11:05 -0000
@@ -94,6 +94,7 @@
 	rtc_ops = &ip32_rtc_ops;
 	board_be_init = ip32_be_init;
 	board_time_init = ip32_time_init;
+	board_timer_setup = ip32_timer_setup();
 
 	crime_init ();
 }

--C01fF7hLGvN0zd9s--

From clausen@gnu.org Mon Jun 30 04:23:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Jun 2003 04:23:25 +0100 (BST)
Received: from mail019.syd.optusnet.com.au ([IPv6:::ffff:210.49.20.160]:45213
	"EHLO mail019.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8224802AbTF3DXT>; Mon, 30 Jun 2003 04:23:19 +0100
Received: from localhost.karma (c17997.eburwd3.vic.optusnet.com.au [210.49.198.98])
	by mail019.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id h5U3N9J23716;
	Mon, 30 Jun 2003 13:23:09 +1000
Received: from satisfactory (satisfactory [192.168.0.1])
	by localhost.karma (Postfix) with ESMTP
	id 134C71C; Mon, 30 Jun 2003 13:23:00 +1000 (EST)
Received: by satisfactory (Postfix, from userid 500)
	id 3752D47A7F; Mon, 30 Jun 2003 13:28:41 +0000 (UTC)
Date: Mon, 30 Jun 2003 13:28:41 +0000
From: Andrew Clausen <clausen@gnu.org>
To: ilya@theIlya.com
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: ip32 timer setup fix
Message-ID: <20030630132841.GD480@gnu.org>
References: <20030630031338.GK13617@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030630031338.GK13617@gateway.total-knowledge.com>
X-Accept-Language: en,pt
User-Agent: Mutt/1.5.4i
Return-Path: <clausen@gnu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2727
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: clausen@gnu.org
Precedence: bulk
X-list: linux-mips

On Sun, Jun 29, 2003 at 08:13:38PM -0700, ilya@theIlya.com wrote:
> diff -u -r1.4 ip32-setup.c
> --- arch/mips/sgi-ip32/ip32-setup.c	14 Apr 2003 16:33:24 -0000	1.4
> +++ arch/mips/sgi-ip32/ip32-setup.c	30 Jun 2003 03:11:05 -0000
> @@ -94,6 +94,7 @@
>  	rtc_ops = &ip32_rtc_ops;
>  	board_be_init = ip32_be_init;
>  	board_time_init = ip32_time_init;
> +	board_timer_setup = ip32_timer_setup();
>  
>  	crime_init ();
>  }

Without even looking at the code... it looks like those () are wrong.
(Is board_timer_setup a function pointer?)  I could be talking
rubbish of course.

Cheers,
Andrew


From ilya@gateway.total-knowledge.com Mon Jun 30 04:27:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Jun 2003 04:27:30 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:62081
	"HELO alpha.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225209AbTF3D12>; Mon, 30 Jun 2003 04:27:28 +0100
Received: (qmail 22509 invoked from network); 29 Jun 2003 20:21:44 -0000
Received: from unknown (HELO gateway.total-knowledge.com) (12.234.207.60)
  by alpha.total-knowledge.com with SMTP; 29 Jun 2003 20:21:44 -0000
Received: (qmail 24965 invoked by uid 502); 30 Jun 2003 03:27:25 -0000
Date: Sun, 29 Jun 2003 20:27:25 -0700
From: ilya@theIlya.com
To: Andrew Clausen <clausen@gnu.org>
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: ip32 timer setup fix
Message-ID: <20030630032725.GL13617@gateway.total-knowledge.com>
References: <20030630031338.GK13617@gateway.total-knowledge.com> <20030630132841.GD480@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030630132841.GD480@gnu.org>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2728
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips

Oops! You are right, of course.
it should be

Index: arch/mips/sgi-ip32/ip32-setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip32/ip32-setup.c,v
retrieving revision 1.4
diff -u -r1.4 ip32-setup.c
--- arch/mips/sgi-ip32/ip32-setup.c     14 Apr 2003 16:33:24 -0000      1.4
+++ arch/mips/sgi-ip32/ip32-setup.c     30 Jun 2003 03:11:05 -0000
@@ -94,6 +94,7 @@
        rtc_ops = &ip32_rtc_ops;
        board_be_init = ip32_be_init;
        board_time_init = ip32_time_init;
+       board_timer_setup = ip32_timer_setup;
 
        crime_init ();
 }


On Mon, Jun 30, 2003 at 01:28:41PM +0000, Andrew Clausen wrote:
> On Sun, Jun 29, 2003 at 08:13:38PM -0700, ilya@theIlya.com wrote:
> > diff -u -r1.4 ip32-setup.c
> > --- arch/mips/sgi-ip32/ip32-setup.c	14 Apr 2003 16:33:24 -0000	1.4
> > +++ arch/mips/sgi-ip32/ip32-setup.c	30 Jun 2003 03:11:05 -0000
> > @@ -94,6 +94,7 @@
> >  	rtc_ops = &ip32_rtc_ops;
> >  	board_be_init = ip32_be_init;
> >  	board_time_init = ip32_time_init;
> > +	board_timer_setup = ip32_timer_setup();
> >  
> >  	crime_init ();
> >  }
> 
> Without even looking at the code... it looks like those () are wrong.
> (Is board_timer_setup a function pointer?)  I could be talking
> rubbish of course.
> 
> Cheers,
> Andrew
> 

From wesolows@foobazco.org Mon Jun 30 08:39:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Jun 2003 08:39:33 +0100 (BST)
Received: from janus.foobazco.org ([IPv6:::ffff:198.144.194.226]:32640 "EHLO
	mail.foobazco.org") by linux-mips.org with ESMTP
	id <S8225209AbTF3Hja>; Mon, 30 Jun 2003 08:39:30 +0100
Received: from fallout.sjc.foobazco.org (fallout.sjc.foobazco.org [192.168.21.20])
	by mail.foobazco.org (Postfix) with ESMTP
	id DA8E0FACE; Mon, 30 Jun 2003 00:39:28 -0700 (PDT)
Received: by fallout.sjc.foobazco.org (Postfix, from userid 1014)
	id 9BF4624; Mon, 30 Jun 2003 00:39:28 -0700 (PDT)
Date: Mon, 30 Jun 2003 00:39:28 -0700
From: Keith M Wesolowski <wesolows@foobazco.org>
To: ilya@theIlya.com
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: ip32 specific stuff
Message-ID: <20030630073928.GA31773@foobazco.org>
References: <20030630003636.GI13617@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030630003636.GI13617@gateway.total-knowledge.com>
User-Agent: Mutt/1.5.4i
Return-Path: <wesolows@foobazco.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2729
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wesolows@foobazco.org
Precedence: bulk
X-list: linux-mips

On Sun, Jun 29, 2003 at 05:36:36PM -0700, ilya@theIlya.com wrote:

> This is the patch that includes most of things that I have in IP32-specific
> parts of my tree.

> 2. Propper memory detection pathc by Keith.

Please don't apply this.  It's a mostly nice piece of code with one
horrible hack, and we're better off for now staying with
CONFIG_ARC_MEMORY until we decide how to best support >256MB of
memory.

The CRIME error handling part is golden however.

> 3. Some other minor fixlets.

>  void ip32_irq1(struct pt_regs *regs)
> Index: arch/mips/sgi-ip32/ip32-setup.c
>  
> +#ifdef CONFIG_FB_SGIO2
> +#include "../../../drivers/video/sgio2fb.h"
> +void *sgio2fb_mem;
> +#endif

You can't reference this because that driver doesn't exist yet.  And
including that here is kind of ugly anyway.

> -#ifdef CONFIG_SERIAL_CONSOLE
> +#ifdef CONFIG_SERIAL_MACE_SGIO2
> +#warning O2MACECONSOLE compiled in
> +	o2serial_console_init();
> +#endif

Debugging snippet leaked in.

> -}
> -
> -int __init page_is_ram (unsigned long pagenr)
> -{
> -	/* XXX: to do? */
> -	return 1;
>  }

Yes, this appears to be unused.

> Index: include/asm-mips64/ip32/crime.h
> ===================================================================
> RCS file: /home/cvs/linux/include/asm-mips64/ip32/crime.h,v
...
> -static inline u64 crime_read_64 (unsigned long __offset) {
> -        return *((volatile u64 *) (CRIME_BASE + __offset));
> -}
> -static inline void crime_write_64 (unsigned long __offset, u64 __val) {
> -        *((volatile u64 *) (CRIME_BASE + __offset)) = __val;
> -}
> +#define crime_read_64(__offset)		__in64(CRIME_BASE+(__offset))
> +#define crime_write_64(__offset,__val)	__out64(__val,CRIME_BASE+(__offset))

You can't do this yet because I just sent Ralf the patch to add those
functions, and they're going to be named __raw_readq and __raw_writeq
as well.  I'll take care of this as soon as that patch is approved.

> --- /dev/null	Sun Jul 17 16:46:18 1994
> +++ include/asm-mips/io64.h	Sun Jun 15 10:35:18 2003

There will be no io64.h.

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

From jsun@mvista.com Mon Jun 30 18:00:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Jun 2003 18:00:19 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:1020 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225205AbTF3RAP>;
	Mon, 30 Jun 2003 18:00:15 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h5UH0DH08737;
	Mon, 30 Jun 2003 10:00:13 -0700
Date: Mon, 30 Jun 2003 10:00:13 -0700
From: Jun Sun <jsun@mvista.com>
To: fpga dsp <fpga_dsp@yahoo.com.au>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: schedule() and mipsel processor
Message-ID: <20030630100013.D8542@mvista.com>
References: <20030628025749.40346.qmail@web41205.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030628025749.40346.qmail@web41205.mail.yahoo.com>; from fpga_dsp@yahoo.com.au on Sat, Jun 28, 2003 at 12:57:49PM +1000
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2731
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Sat, Jun 28, 2003 at 12:57:49PM +1000, fpga dsp wrote:
> Hi all,
>  
> I may ask a stupid question here but I have problem of calling any functions such as interruptible_sleep_on_timeout, sleep_on ... in a timer handler, the kernel just crash straight away in the function schedule(). Now I go and do a diff between kern/sched.c on i686 source and mipsel source. clearly , they are different. So the question is from kernel programming point of view, the bottom-half of interrupt handler is still considered interrupt handler? 

Correct.  You can't call those sleep functions from timer function.

Jun

From jsun@mvista.com Mon Jun 30 18:07:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Jun 2003 18:07:04 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:16894 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225205AbTF3RHC>;
	Mon, 30 Jun 2003 18:07:02 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h5UH6vY08795;
	Mon, 30 Jun 2003 10:06:57 -0700
Date: Mon, 30 Jun 2003 10:06:57 -0700
From: Jun Sun <jsun@mvista.com>
To: ilya@theIlya.com
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: ip32 timer setup fix
Message-ID: <20030630100657.E8542@mvista.com>
References: <20030630031338.GK13617@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030630031338.GK13617@gateway.total-knowledge.com>; from ilya@theIlya.com on Sun, Jun 29, 2003 at 08:13:38PM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2732
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


It appears that if you set mips_counter_frequency to 
cc_interval, then you are all set and timer should work just fine.
In other words, 
	a) you don't  have to use your timer interrupt routine
	b) you don't have to clear count register
	c) you don't have to set the first compare register

What a deal! :)

Jun


On Sun, Jun 29, 2003 at 08:13:38PM -0700, ilya@theIlya.com wrote:
> Attached is patch to fix timer setup on IP32.
> 

> Index: arch/mips/sgi-ip32/ip32-timer.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/sgi-ip32/ip32-timer.c,v
> retrieving revision 1.12
> diff -u -r1.12 ip32-timer.c
> --- arch/mips/sgi-ip32/ip32-timer.c	29 Jun 2003 21:59:13 -0000	1.12
> +++ arch/mips/sgi-ip32/ip32-timer.c	30 Jun 2003 03:07:47 -0000
> @@ -45,11 +45,17 @@
>  #define USECS_PER_JIFFY (1000000/HZ)
>  
>  
> +static irqreturn_t cc_timer_interrupt(int irq, void *dev_id, struct pt_regs * regs);
> +
>  void __init ip32_timer_setup (struct irqaction *irq)
>  {
>  	u64 crime_time;
>  	u32 cc_tick;
>  
> +
> +	write_c0_count(0);
> +	irq->handler = cc_timer_interrupt;
> +
>  	printk("Calibrating system timer... ");
>  
>  	crime_time = crime_read_64(CRIME_TIME) & CRIME_TIME_MASK;
> @@ -70,12 +76,14 @@
>  	printk("%d MHz CPU detected\n", (int) (cc_interval / PER_MHZ));
>  
>  	setup_irq (CLOCK_IRQ, irq);
> +#define ALLINTS (IE_IRQ0 | IE_IRQ1 | IE_IRQ2 | IE_IRQ3 | IE_IRQ4 | IE_IRQ5)
> +	/* Set ourselves up for future interrupts */
> +	write_c0_compare(read_c0_count() + cc_interval);
> +        change_c0_status(ST0_IM, ALLINTS);
> +	local_irq_enable();
>  }
>  
> -struct irqaction irq0  = { NULL, SA_INTERRUPT, 0,
> -			   "timer", NULL, NULL};
> -
> -irqreturn_t cc_timer_interrupt(int irq, void *dev_id, struct pt_regs * regs)
> +static irqreturn_t cc_timer_interrupt(int irq, void *dev_id, struct pt_regs * regs)
>  {
>  	u32 count;
>  
> @@ -150,15 +158,4 @@
>  	xtime.tv_sec = mktime(year, mon, day, hour, min, sec);
>  	xtime.tv_nsec = 0;
>  	write_sequnlock_irq(&xtime_lock);
> -
> -	write_c0_count(0);
> -	irq0.handler = cc_timer_interrupt;
> -
> -	ip32_timer_setup (&irq0);
> -
> -#define ALLINTS (IE_IRQ0 | IE_IRQ1 | IE_IRQ2 | IE_IRQ3 | IE_IRQ4 | IE_IRQ5)
> -	/* Set ourselves up for future interrupts */
> -	write_c0_compare(read_c0_count() + cc_interval);
> -        change_c0_status(ST0_IM, ALLINTS);
> -	local_irq_enable();
>  }
> Index: arch/mips/sgi-ip32/ip32-setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/sgi-ip32/ip32-setup.c,v
> retrieving revision 1.4
> diff -u -r1.4 ip32-setup.c
> --- arch/mips/sgi-ip32/ip32-setup.c	14 Apr 2003 16:33:24 -0000	1.4
> +++ arch/mips/sgi-ip32/ip32-setup.c	30 Jun 2003 03:11:05 -0000
> @@ -94,6 +94,7 @@
>  	rtc_ops = &ip32_rtc_ops;
>  	board_be_init = ip32_be_init;
>  	board_time_init = ip32_time_init;
> +	board_timer_setup = ip32_timer_setup();
>  
>  	crime_init ();
>  }


From vince_bridgers@yahoo.com Mon Jun 30 22:46:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Jun 2003 22:46:54 +0100 (BST)
Received: from web41412.mail.yahoo.com ([IPv6:::ffff:66.218.93.78]:42904 "HELO
	web41412.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225212AbTF3Vqt>; Mon, 30 Jun 2003 22:46:49 +0100
Message-ID: <20030630214641.36770.qmail@web41412.mail.yahoo.com>
Received: from [64.132.226.151] by web41412.mail.yahoo.com via HTTP; Mon, 30 Jun 2003 14:46:41 PDT
Date: Mon, 30 Jun 2003 14:46:41 -0700 (PDT)
From: Vince Bridgers <vince_bridgers@yahoo.com>
Subject: Au1500 Event and Performance Counters
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <vince_bridgers@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: 2733
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vince_bridgers@yahoo.com
Precedence: bulk
X-list: linux-mips

Has anyone used the Au1x00 performance event counter
register in CP0 (Register 25 - where it says AMD will
provide a list of the valid units and events when you
ask them) ? 

Are they the same as some other MIPS processor that
defines the events in their databook?

Thanks


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

From ilya@gateway.total-knowledge.com Mon Jun 30 23:45:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Jun 2003 23:45:04 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:29570
	"HELO alpha.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225212AbTF3WpC>; Mon, 30 Jun 2003 23:45:02 +0100
Received: (qmail 18200 invoked from network); 30 Jun 2003 15:37:48 -0000
Received: from unknown (HELO gateway.total-knowledge.com) (12.234.207.60)
  by alpha.total-knowledge.com with SMTP; 30 Jun 2003 15:37:48 -0000
Received: (qmail 14547 invoked by uid 502); 30 Jun 2003 22:44:57 -0000
Date: Mon, 30 Jun 2003 15:44:57 -0700
From: ilya@theIlya.com
To: Keith M Wesolowski <wesolows@foobazco.org>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: ip32 specific stuff
Message-ID: <20030630224457.GQ13617@gateway.total-knowledge.com>
References: <20030630003636.GI13617@gateway.total-knowledge.com> <20030630073928.GA31773@foobazco.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="AwNVUpjOmSj7UnwZ"
Content-Disposition: inline
In-Reply-To: <20030630073928.GA31773@foobazco.org>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2734
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

Thanks for comments. I am stopping being lazy right now :)


On Mon, Jun 30, 2003 at 12:39:28AM -0700, Keith M Wesolowski wrote:
> On Sun, Jun 29, 2003 at 05:36:36PM -0700, ilya@theIlya.com wrote:
>=20
> > This is the patch that includes most of things that I have in IP32-spec=
ific
> > parts of my tree.
>=20
> > 2. Propper memory detection pathc by Keith.
>=20
> Please don't apply this.  It's a mostly nice piece of code with one
> horrible hack, and we're better off for now staying with
> CONFIG_ARC_MEMORY until we decide how to best support >256MB of
> memory.
>=20
> The CRIME error handling part is golden however.
>=20
> > 3. Some other minor fixlets.
>=20
> >  void ip32_irq1(struct pt_regs *regs)
> > Index: arch/mips/sgi-ip32/ip32-setup.c
> > =20
> > +#ifdef CONFIG_FB_SGIO2
> > +#include "../../../drivers/video/sgio2fb.h"
> > +void *sgio2fb_mem;
> > +#endif
>=20
> You can't reference this because that driver doesn't exist yet.  And
> including that here is kind of ugly anyway.
>=20
> > -#ifdef CONFIG_SERIAL_CONSOLE
> > +#ifdef CONFIG_SERIAL_MACE_SGIO2
> > +#warning O2MACECONSOLE compiled in
> > +	o2serial_console_init();
> > +#endif
>=20
> Debugging snippet leaked in.
>=20
> > -}
> > -
> > -int __init page_is_ram (unsigned long pagenr)
> > -{
> > -	/* XXX: to do? */
> > -	return 1;
> >  }
>=20
> Yes, this appears to be unused.
>=20
> > Index: include/asm-mips64/ip32/crime.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/cvs/linux/include/asm-mips64/ip32/crime.h,v
> ...
> > -static inline u64 crime_read_64 (unsigned long __offset) {
> > -        return *((volatile u64 *) (CRIME_BASE + __offset));
> > -}
> > -static inline void crime_write_64 (unsigned long __offset, u64 __val) {
> > -        *((volatile u64 *) (CRIME_BASE + __offset)) =3D __val;
> > -}
> > +#define crime_read_64(__offset)		__in64(CRIME_BASE+(__offset))
> > +#define crime_write_64(__offset,__val)	__out64(__val,CRIME_BASE+(__off=
set))
>=20
> You can't do this yet because I just sent Ralf the patch to add those
> functions, and they're going to be named __raw_readq and __raw_writeq
> as well.  I'll take care of this as soon as that patch is approved.
>=20
> > --- /dev/null	Sun Jul 17 16:46:18 1994
> > +++ include/asm-mips/io64.h	Sun Jun 15 10:35:18 2003
>=20
> There will be no io64.h.
>=20
> --=20
> Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
> ------(( Project Foobazco Coordinator and Network Administrator ))------
> 	"May Buddha bless all stubborn people!"
> 				-- Uliassutai Karakorum Blake
>=20

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

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

iD8DBQE/AL1p7sVBmHZT8w8RAnrKAJ9EMsuKrMrrt+6qF5LBoPLX8Un2LwCgn0np
zqU/ruYN+JDjo6y/kaHTkUM=
=HHcC
-----END PGP SIGNATURE-----

--AwNVUpjOmSj7UnwZ--