From baitisj@idealab.com Sat Mar  1 03:48:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Mar 2003 03:48:28 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:62126 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225215AbTCADs2>;
	Sat, 1 Mar 2003 03:48:28 +0000
Received: (qmail 21075 invoked by uid 6180); 1 Mar 2003 03:48:20 -0000
Date: Fri, 28 Feb 2003 19:48:20 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: CardBus on DBAu1500
Message-ID: <20030228194820.Z20129@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: 1590
X-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 Pete and others!

I'm finally working on CardBus support on the DBAu1500. Just got acquainted
with PCI today. :)

I decided that the first step is to plug in a PCI->PCI bridge, and try to see
if it would work, which it did not. After winding around inside of the kernel,
I finally arrived in arch/mips/au1000/db1x00/pci_ops.c:

Inside of config_access(unsigned char access_type, struct pci_dev *dev,
unsigned char where, u32 * data), on line 97, a little surprise:

    if (bus != 0) {
        *data = 0xffffffff;
        return -1;
    }

At this point, I concluded that I cannot traverse a PCI-PCI or CardBus bridge,
since any devices behind the bridge will require Type 1 Configuration Cycles,
and it seems that only Type 0 is currently supported.

I assume that I should add code to handle the case where I need to generate
Type 1 Configuration Cycles inside of config_access. Pete, since you authored
this code, I thought I'd quickly run this by you to make sure that I'm on
track.

Thanks for your suggestions!

-Jeff


On Tue, Feb 25, 2003 at 02:05:43PM -0800, Pete Popov wrote:
> On Tue, 2003-02-25 at 13:54, Jeff Baitis wrote:
> > Yes, the DBAu1500 board does not have CardBus support. We want to support
> > 802.11A/G, so at the moment I have a 3.3V PCI card with a Texas Instruments
> > 1510 CardBus bridge. A lot of modern wireless cards are CardBus-only, so that's
> > why we have decided to incorporate the TI bridge into our boards.
> 
> Ah, yes, that's true.  Just FYI, I had to debug a cardbus problem months
> ago on a different architecture, so I did it on the Pb1500 instead. It
> was a pci-cardbus adapter and I did get it to work,eventually, with a
> cardbus wireless card. Unfortunately I didn't have time to clean it up
> and submit it anywhere, internally or externally, and the bits died at
> some point. 
> 
> So what you're trying to do is not hopeless but it will require some
> debugging :)
> 
> Pete
> 
> > If someone out there has some notes or tips concerning getting PCMCIA working
> > under this architecture, I would greatly appreciate the information.
> > 
> > Take care, and thanks again!
> > 
> > -Jeff
> > 
> > 

-- 
         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 ppopov@mvista.com Sat Mar  1 06:12:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Mar 2003 06:12:37 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:55539 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225194AbTCAGMg>;
	Sat, 1 Mar 2003 06:12:36 +0000
Received: from localhost (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id WAA26641;
	Fri, 28 Feb 2003 22:12:29 -0800
Subject: Re: CardBus on DBAu1500
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com
Cc: linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <20030228194820.Z20129@luca.pas.lab>
References: <20030228194820.Z20129@luca.pas.lab>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1046499358.12356.2.camel@adsl.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 28 Feb 2003 22:15:58 -0800
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: 1591
X-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-02-28 at 19:48, Jeff Baitis wrote:
> Hey Pete and others!
> 
> I'm finally working on CardBus support on the DBAu1500. Just got acquainted
> with PCI today. :)
> 
> I decided that the first step is to plug in a PCI->PCI bridge, and try to see
> if it would work, which it did not. After winding around inside of the kernel,
> I finally arrived in arch/mips/au1000/db1x00/pci_ops.c:
> 
> Inside of config_access(unsigned char access_type, struct pci_dev *dev,
> unsigned char where, u32 * data), on line 97, a little surprise:
> 
>     if (bus != 0) {
>         *data = 0xffffffff;
>         return -1;
>     }
> 
> At this point, I concluded that I cannot traverse a PCI-PCI or CardBus bridge,
> since any devices behind the bridge will require Type 1 Configuration Cycles,
> and it seems that only Type 0 is currently supported.
> 
> I assume that I should add code to handle the case where I need to generate
> Type 1 Configuration Cycles inside of config_access. Pete, since you authored
> this code, I thought I'd quickly run this by you to make sure that I'm on
> track.
> 
> Thanks for your suggestions!

Take a look at arch/mips/au1000/pb1500/pci_ops.c for type 1 config
access. The patch was courtesy of David Gathright and apparently I
missed adding it in the db1500. Actually, we need to combine that code
because it's the same. Let me get through my eternal struggle of getting
the 36 bit patch applied (with Ralf's help I think a modified patch
should be ready this weekend) and then I'll worry about clean ups :)

Pete


From yaelgilad@myrealbox.com Sun Mar  2 09:07:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Mar 2003 09:07:35 +0000 (GMT)
Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:45145
	"EHLO smtp-send.myrealbox.com") by linux-mips.org with ESMTP
	id <S8225201AbTCBJHf> convert rfc822-to-8bit; Sun, 2 Mar 2003 09:07:35 +0000
Received: from yaelgilad [81.218.92.190] by myrealbox.com
	with NetMail ModWeb Module; Sun, 02 Mar 2003 09:07:28 +0000
Subject: Static variables and "gp"
From: "Gilad Benjamini" <yaelgilad@myrealbox.com>
To: linux-mips@linux-mips.org
Date: Sun, 02 Mar 2003 09:07:28 +0000
X-Mailer: NetMail ModWeb Module
X-Sender: yaelgilad
MIME-Version: 1.0
Message-ID: <1046596048.d43b0c00yaelgilad@myrealbox.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Return-Path: <yaelgilad@myrealbox.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1592
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yaelgilad@myrealbox.com
Precedence: bulk
X-list: linux-mips

Hi,
How can I force a specific static variable to be used by the "gp" register
rather than by a two-step load ?
Compiling a mips-linux using gcc.

I was poking around for information and stumbled across the "-G" flag,
the "__attribute__ ((section (".sdata")))" (or sbss), the "-msdata" but to no avail.
I only got more confused.

Any help will be appreciated


From ralf@linux-mips.org Sun Mar  2 11:18:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Mar 2003 11:18:29 +0000 (GMT)
Received: from p508B53C9.dip.t-dialin.net ([IPv6:::ffff:80.139.83.201]:5762
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225201AbTCBLS2>; Sun, 2 Mar 2003 11:18:28 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h22BILf30854;
	Sun, 2 Mar 2003 12:18:21 +0100
Date: Sun, 2 Mar 2003 12:18:20 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Gilad Benjamini <yaelgilad@myrealbox.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Static variables and "gp"
Message-ID: <20030302121820.A30790@linux-mips.org>
References: <1046596048.d43b0c00yaelgilad@myrealbox.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: <1046596048.d43b0c00yaelgilad@myrealbox.com>; from yaelgilad@myrealbox.com on Sun, Mar 02, 2003 at 09:07:28AM +0000
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1593
X-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, Mar 02, 2003 at 09:07:28AM +0000, Gilad Benjamini wrote:

> How can I force a specific static variable to be used by the "gp" register
> rather than by a two-step load ?
> Compiling a mips-linux using gcc.

That feature doesn't work in gcc for userspace code ...

  Ralf

From yaelgilad@myrealbox.com Sun Mar  2 11:46:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Mar 2003 11:46:05 +0000 (GMT)
Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:61450
	"EHLO smtp-send.myrealbox.com") by linux-mips.org with ESMTP
	id <S8225201AbTCBLqF> convert rfc822-to-8bit; Sun, 2 Mar 2003 11:46:05 +0000
Received: from yaelgilad [81.218.92.190] by myrealbox.com
	with NetMail ModWeb Module; Sun, 02 Mar 2003 11:46:07 +0000
Subject: RE: Static variables and "gp"
From: "Gilad Benjamini" <yaelgilad@myrealbox.com>
To: linux-mips@linux-mips.org
Date: Sun, 02 Mar 2003 11:46:07 +0000
X-Mailer: NetMail ModWeb Module
X-Sender: yaelgilad
MIME-Version: 1.0
Message-ID: <1046605567.d43b0840yaelgilad@myrealbox.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Return-Path: <yaelgilad@myrealbox.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1594
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yaelgilad@myrealbox.com
Precedence: bulk
X-list: linux-mips

Who said user-code ?
Strictly kernel

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Sunday, March 02, 2003 1:18 PM
To: Gilad Benjamini
Cc: linux-mips@linux-mips.org
Subject: Re: Static variables and "gp"


On Sun, Mar 02, 2003 at 09:07:28AM +0000, Gilad Benjamini wrote:

> How can I force a specific static variable to be used by the "gp" register
> rather than by a two-step load ?
> Compiling a mips-linux using gcc.

That feature doesn't work in gcc for userspace code ...

  Ralf



From ralf@linux-mips.org Sun Mar  2 14:12:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Mar 2003 14:12:57 +0000 (GMT)
Received: from p508B53C9.dip.t-dialin.net ([IPv6:::ffff:80.139.83.201]:63619
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225223AbTCBOM4>; Sun, 2 Mar 2003 14:12:56 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h22ECoq01423;
	Sun, 2 Mar 2003 15:12:50 +0100
Date: Sun, 2 Mar 2003 15:12:50 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Gilad Benjamini <yaelgilad@myrealbox.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Static variables and "gp"
Message-ID: <20030302151250.A1224@linux-mips.org>
References: <1046605567.d43b0840yaelgilad@myrealbox.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: <1046605567.d43b0840yaelgilad@myrealbox.com>; from yaelgilad@myrealbox.com on Sun, Mar 02, 2003 at 11:46:07AM +0000
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1595
X-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, Mar 02, 2003 at 11:46:07AM +0000, Gilad Benjamini wrote:

> Who said user-code ?
> Strictly kernel

Well ...  Register $28 is already used for the current pointer.  You'd
have to get rid of the $28 optimization first before GP optimization could
work.

  Ralf

From yoichi_yuasa@montavista.co.jp Mon Mar  3 10:21:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 10:21:46 +0000 (GMT)
Received: from sonicwall.montavista.co.jp ([IPv6:::ffff:202.232.97.131]:22548
	"EHLO yuubin.montavista.co.jp") by linux-mips.org with ESMTP
	id <S8225227AbTCCKVp>; Mon, 3 Mar 2003 10:21:45 +0000
Received: from pudding.montavista.co.jp ([10.200.0.40])
	by yuubin.montavista.co.jp (8.12.5/8.12.5) with SMTP id h23ATX44006663;
	Mon, 3 Mar 2003 19:29:35 +0900
Date: Mon, 3 Mar 2003 19:21:37 +0900
From: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
To: ralf@linux-mips.org
Cc: yoichi_yuasa@montavista.co.jp, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: [patch] simulate_ll and simulate_sc(resend)
Message-Id: <20030303192137.34d21352.yoichi_yuasa@montavista.co.jp>
Organization: MontaVista Software Japan, Inc.
X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Mon__3_Mar_2003_19:21:37_+0900_08290030"
Return-Path: <yoichi_yuasa@montavista.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1596
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yoichi_yuasa@montavista.co.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Multipart_Mon__3_Mar_2003_19:21:37_+0900_08290030
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Ralf,

I found a bug in simulate_ll and simulate_sc.
The board that uses ll/sc emulation is not started.

When send_sig in these, in order not to operate the value of EPC correctly,
simulate_* happens continuously.

The previous patches were not perfect, I changed more.
Please apply these patches to CVS tree.

Thanks,

Yoichi

--Multipart_Mon__3_Mar_2003_19:21:37_+0900_08290030
Content-Type: text/plain;
 name="llsc-v24-0303.diff"
Content-Disposition: attachment;
 filename="llsc-v24-0303.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c
--- linux.orig/arch/mips/kernel/traps.c	Tue Feb 11 07:50:48 2003
+++ linux/arch/mips/kernel/traps.c	Mon Mar  3 17:52:16 2003
@@ -140,6 +140,7 @@
 	return;
 
 sig:
+	compute_return_epc(regs);
 	send_sig(signal, current, 1);
 }
 
@@ -172,18 +173,19 @@
 	}
 	if (ll_bit == 0 || ll_task != current) {
 		regs->regs[reg] = 0;
-		goto sig;
 	}
 
-	if (put_user(regs->regs[reg], vaddr))
+	if (put_user(regs->regs[reg], vaddr)) {
 		signal = SIGSEGV;
-	else
+		goto sig;
+	} else
 		regs->regs[reg] = 1;
 
 	compute_return_epc(regs);
 	return;
 
 sig:
+	compute_return_epc(regs);
 	send_sig(signal, current, 1);
 }
 

--Multipart_Mon__3_Mar_2003_19:21:37_+0900_08290030
Content-Type: text/plain;
 name="llsc-v25-0303.diff"
Content-Disposition: attachment;
 filename="llsc-v25-0303.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c
--- linux.orig/arch/mips/kernel/traps.c	Wed Feb 12 13:26:43 2003
+++ linux/arch/mips/kernel/traps.c	Mon Mar  3 17:48:11 2003
@@ -135,6 +135,7 @@
 	return;
 
 sig:
+	compute_return_epc(regs);
 	send_sig(signal, current, 1);
 }
 
@@ -167,18 +168,19 @@
 	}
 	if (ll_bit == 0 || ll_task != current) {
 		regs->regs[reg] = 0;
-		goto sig;
 	}
 
-	if (put_user(regs->regs[reg], vaddr))
+	if (put_user(regs->regs[reg], vaddr)) {
 		signal = SIGSEGV;
-	else
+		goto sig;
+	} else
 		regs->regs[reg] = 1;
 
 	compute_return_epc(regs);
 	return;
 
 sig:
+	compute_return_epc(regs);
 	send_sig(signal, current, 1);
 }
 

--Multipart_Mon__3_Mar_2003_19:21:37_+0900_08290030--

From avinash.s@inspiretech.com Mon Mar  3 11:54:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 11:54:58 +0000 (GMT)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:24458
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8225227AbTCCLy5>; Mon, 3 Mar 2003 11:54:57 +0000
Received: from mail.inspiretech.com (mail.inspiretech.com [150.1.1.1])
	by smtp.inspirtek.com (8.12.5/8.12.5) with ESMTP id h23C3XcY014663
	for <linux-mips@linux-mips.org>; Mon, 3 Mar 2003 17:33:39 +0530
Message-Id: <200303031203.h23C3XcY014663@smtp.inspirtek.com>
Received: from WorldClient [150.1.1.1] by inspiretech.com [150.1.1.1]
	with SMTP (MDaemon.v3.5.7.R)
	for <linux-mips@linux-mips.org>; Mon, 03 Mar 2003 17:21:49 +0530
Date: Mon, 03 Mar 2003 17:21:47 +0530
From: "Avinash S." <avinash.s@inspiretech.com>
To: linux-mips@linux-mips.org
Subject: Re: Ecartis command results: No commands found
X-Mailer: WorldClient Standard 3.5.0e
In-Reply-To: <ecartis-03032003113240.835.1@ftp.linux-mips.org>
X-MDRemoteIP: 150.1.1.1
X-Return-Path: avinash.s@inspiretech.com
X-MDaemon-Deliver-To: linux-mips@linux-mips.org
Return-Path: <avinash.s@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: 1598
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: avinash.s@inspiretech.com
Precedence: bulk
X-list: linux-mips
Content-Length: 300
Lines: 11

hi ,
could some try and explain the booting process for a mips based kernel. 
eg for a i386 the first thing that gets loaded is the bootsect.s
and then setup.s and so on and so forth. I would like to know the entry
point in a mips based kernel. im a newbie, and new to the kernel!

thanks

Avinash



From andreev@niisi.msk.ru Mon Mar  3 12:41:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 12:41:42 +0000 (GMT)
Received: from t111.niisi.ras.ru ([IPv6:::ffff:193.232.173.111]:51295 "EHLO
	t111.niisi.ras.ru") by linux-mips.org with ESMTP
	id <S8225227AbTCCMll>; Mon, 3 Mar 2003 12:41:41 +0000
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA11729
	for <linux-mips@linux-mips.org>; Mon, 3 Mar 2003 15:41:42 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA32236 for linux-mips@linux-mips.org; Mon, 3 Mar 2003 15:54:37 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34])
	by niisi.msk.ru (8.12.5/8.12.5) with ESMTP id h23C2Iuj006018
	for <linux-mips@linux-mips.org>; Mon, 3 Mar 2003 15:02:19 +0300 (MSK)
Message-ID: <3E6370F1.3030603@niisi.msk.ru>
Date: Mon, 03 Mar 2003 15:12:49 +0000
From: Alexandr Andreev <andreev@niisi.msk.ru>
Organization: niisi
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
X-Accept-Language: ru, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: HIGMEM and boot ROM
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <andreev@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1599
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: andreev@niisi.msk.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 423
Lines: 10

Hi.
As i understand, MIPS Linux does not support DISCONTIGMEM yet.
But what I have to do, if my MIPS32 station has more than 512 Mb of
physical ram. I can set HIGMEM for my station, but how can I
avoid boot ROM region, which is at 0x1FC00000. I can avoid these
4Mbytes of memory in memory allocation routines, but I suppose that
there are some better solutions in MIPS linux. How do other MIPSes work?

Thanks in advance.


From js@convergence.de Mon Mar  3 12:54:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 12:54:20 +0000 (GMT)
Received: from buserror-extern.convergence.de ([IPv6:::ffff:212.84.236.66]:18183
	"EHLO hell") by linux-mips.org with ESMTP id <S8225235AbTCCMyT>;
	Mon, 3 Mar 2003 12:54:19 +0000
Received: from js by hell with local (Exim 3.35 #1 (Debian))
	id 18ppST-0006BH-00; Mon, 03 Mar 2003 13:54:17 +0100
Date: Mon, 3 Mar 2003 13:54:17 +0100
From: Johannes Stezenbach <js@convergence.de>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org
Subject: Re: Static variables and "gp"
Message-ID: <20030303125417.GB23612@convergence.de>
Mail-Followup-To: Johannes Stezenbach <js@convergence.de>,
	Ralf Baechle <ralf@linux-mips.org>,
	Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org
References: <1046596048.d43b0c00yaelgilad@myrealbox.com> <20030302121820.A30790@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030302121820.A30790@linux-mips.org>
User-Agent: Mutt/1.5.3i
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: 1600
X-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
Content-Length: 521
Lines: 15

On Sun, Mar 02, 2003 at 12:18:20PM +0100, Ralf Baechle wrote:
> On Sun, Mar 02, 2003 at 09:07:28AM +0000, Gilad Benjamini wrote:
> 
> > How can I force a specific static variable to be used by the "gp" register
> > rather than by a two-step load ?
> > Compiling a mips-linux using gcc.
> 
> That feature doesn't work in gcc for userspace code ...

It works with diet libc (http://dietlibc.org/).
You need a static, non-PIC libgcc.a which supports it, though,
which means a bit of gcc config hackery...

Regards,
Johannes

From kwalker@broadcom.com Mon Mar  3 19:43:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 19:43:14 +0000 (GMT)
Received: from mms2.broadcom.com ([IPv6:::ffff:63.70.210.59]:20999 "EHLO
	mms2.broadcom.com") by linux-mips.org with ESMTP
	id <S8225243AbTCCTnN>; Mon, 3 Mar 2003 19:43:13 +0000
Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.0)); Mon, 03 Mar 2003 11:40:10 -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 LAA14390; Mon, 3 Mar 2003 11:42:52 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h23Jh3ER024461; Mon, 3 Mar 2003 11:43:03 -0800 (PST)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id LAA04052; Mon, 3
 Mar 2003 11:43:03 -0800
Message-ID: <3E63B047.D3BA2A2C@broadcom.com>
Date: Mon, 03 Mar 2003 11:43:03 -0800
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
cc: "Ralf Baechle" <ralf@linux-mips.org>
Subject: [PATCH] add CONFIG_DEBUG_INFO
References: <20030220113404.E7466@mvista.com>
X-WSS-ID: 127D70102448190-01-01
Content-Type: multipart/mixed;
 boundary=------------0FF0CCC3E4562DFE2023AC10
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: 1601
X-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
Content-Length: 3196
Lines: 93

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

Jun Sun wrote:
> 
> This patch make the following changes
> 
>         1) CONFIG_REMOTE_DEBUG -> CONFIG_KGDB
>         2) CONFIG_DEBUG -> CONFIG_RUNTIME_DEBUG
> 
> MIPS is pretty much the only one (other than the pitiful s390 :0)
> using REMOTE_DEBUG instead of KGDB.  So it is a good thing to change
> it.
> 
> As Keith pointed out, CONFIG_DEBUG is too general (which has
> already caused confusion, BTW).  RUNTIME_DEBUG is more appropriate.

I'd like to propose a further change here, which is to decouple the
inclusion of debugging symbols from building with KGDB support.  I use a
JTAG debugger all the time, and don't need/want KGDB built in (by
default it forces the remote GDB to attach and continue, and it steals
one of the serial ports on my platform).

How about adding "CONFIG_DEBUG_INFO" which simply adds '-g' to the
CFLAGS?  REMOTE_KGDB can be left independent of this option by allowing
either option to enable '-g'.  Patch for 2.4 attached.

Comments?

Kip
--------------0FF0CCC3E4562DFE2023AC10
Content-Type: text/plain;
 charset=us-ascii;
 name=debug.diff
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename=debug.diff

Index: arch/mips/config-shared.in
===================================================================
RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v
retrieving revision 1.1.2.48
diff -u -r1.1.2.48 config-shared.in
--- arch/mips/config-shared.in	26 Feb 2003 21:14:23 -0000	1.1.2.48
+++ arch/mips/config-shared.in	3 Mar 2003 19:41:11 -0000
@@ -976,6 +976,7 @@
 
 bool 'Are you using a crosscompiler' CONFIG_CROSSCOMPILE
 bool 'Enable run-time debugging' CONFIG_RUNTIME_DEBUG
+bool 'Debugging symbols' CONFIG_DEBUG_INFO
 bool 'Remote GDB kernel debugging' CONFIG_KGDB
 dep_bool '  Console output to GDB' CONFIG_GDB_CONSOLE $CONFIG_KGDB
 if [ "$CONFIG_SIBYTE_SB1xxx_SOC" = "y" ]; then
Index: arch/mips/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/Makefile,v
retrieving revision 1.78.2.23
diff -u -r1.78.2.23 Makefile
--- arch/mips/Makefile	26 Feb 2003 21:14:23 -0000	1.78.2.23
+++ arch/mips/Makefile	3 Mar 2003 19:41:11 -0000
@@ -41,8 +41,8 @@
 LINKFLAGS	+= -G 0 -static # -N
 MODFLAGS	+= -mlong-calls
 
-ifdef CONFIG_KGDB
-GCCFLAGS	+= -g
+ifneq ($(CONFIG_DEBUG_INFO)$(CONFIG_KGDB),)
+GCCFLAGS	+= -gstabs+
 ifdef CONFIG_SB1XXX_CORELIS
 GCCFLAGS	+= -mno-sched-prolog -fno-omit-frame-pointer
 endif
Index: arch/mips64/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips64/Makefile,v
retrieving revision 1.22.2.27
diff -u -r1.22.2.27 Makefile
--- arch/mips64/Makefile	26 Feb 2003 21:14:24 -0000	1.22.2.27
+++ arch/mips64/Makefile	3 Mar 2003 19:41:11 -0000
@@ -39,7 +39,7 @@
 LINKFLAGS	+= -G 0 -static # -N
 MODFLAGS	+= -mlong-calls
 
-ifdef CONFIG_KGDB
+ifneq ($(CONFIG_DEBUG_INFO)$(CONFIG_KGDB),)
 GCCFLAGS	+= -g
 ifdef CONFIG_SB1XXX_CORELIS
 GCCFLAGS	+= -mno-sched-prolog -fno-omit-frame-pointer

--------------0FF0CCC3E4562DFE2023AC10--


From kwalker@broadcom.com Mon Mar  3 19:45:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 19:45:53 +0000 (GMT)
Received: from mms3.broadcom.com ([IPv6:::ffff:63.70.210.38]:43782 "EHLO
	mms3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225243AbTCCTpw>; Mon, 3 Mar 2003 19:45:52 +0000
Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.0)); Mon, 03 Mar 2003 11:45:48 -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 LAA15076; Mon, 3 Mar 2003 11:45:30 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h23JjfER024540; Mon, 3 Mar 2003 11:45:41 -0800 (PST)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id LAA04061; Mon, 3
 Mar 2003 11:45:42 -0800
Message-ID: <3E63B0E6.F7A85746@broadcom.com>
Date: Mon, 03 Mar 2003 11:45:42 -0800
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org, "Ralf Baechle" <ralf@linux-mips.org>
Subject: Re: [PATCH] add CONFIG_DEBUG_INFO
References: <20030220113404.E7466@mvista.com>
 <3E63B047.D3BA2A2C@broadcom.com>
X-WSS-ID: 127D6F662251472-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: 1602
X-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
Content-Length: 437
Lines: 13

Kip Walker wrote:
> 
> How about adding "CONFIG_DEBUG_INFO" which simply adds '-g' to the
> CFLAGS?  REMOTE_KGDB can be left independent of this option by allowing
> either option to enable '-g'.  Patch for 2.4 attached.

My, just noticed that this patch included my local hack of using
'-gstabs+' instead of '-g' in the 32-bit Makefile, because my GDB
doesn't like DWARF2 so much yet.  I wasn't intending to advocate this
change.

Kip


From quintela@mandrakesoft.com Mon Mar  3 19:50:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 19:50:57 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:33332 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225243AbTCCTu4>;
	Mon, 3 Mar 2003 19:50:56 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 36F7C7BA; Mon,  3 Mar 2003 20:50:28 +0100 (CET)
To: "Kip Walker" <kwalker@broadcom.com>
Cc: linux-mips@linux-mips.org, "Ralf Baechle" <ralf@linux-mips.org>
Subject: Re: [PATCH] add CONFIG_DEBUG_INFO
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <3E63B047.D3BA2A2C@broadcom.com> ("Kip Walker"'s message of
 "Mon, 03 Mar 2003 11:43:03 -0800")
References: <20030220113404.E7466@mvista.com> <3E63B047.D3BA2A2C@broadcom.com>
Date: Mon, 03 Mar 2003 20:50:28 +0100
Message-ID: <86d6l8fcvv.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1603
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1191
Lines: 36

>>>>> "kip" == Kip Walker <kwalker@broadcom.com> writes:

Hi

kip> KipIndex: arch/mips/config-shared.in
kip> ===================================================================
kip> RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v
kip> retrieving revision 1.1.2.48
kip> diff -u -r1.1.2.48 config-shared.in
kip> --- arch/mips/config-shared.in	26 Feb 2003 21:14:23 -0000	1.1.2.48
kip> +++ arch/mips/config-shared.in	3 Mar 2003 19:41:11 -0000
kip> @@ -976,6 +976,7 @@
 
kip> bool 'Are you using a crosscompiler' CONFIG_CROSSCOMPILE
kip> bool 'Enable run-time debugging' CONFIG_RUNTIME_DEBUG
kip> +bool 'Debugging symbols' CONFIG_DEBUG_INFO
kip> bool 'Remote GDB kernel debugging' CONFIG_KGDB
kip> dep_bool '  Console output to GDB' CONFIG_GDB_CONSOLE $CONFIG_KGDB
kip> if [ "$CONFIG_SIBYTE_SB1xxx_SOC" = "y" ]; then

Once there, doing something like:

bool 'Remote GDB kernel debugging' CONFIG_KGDB
if [ "$CONFIG_KGDB" = "y" ]; then
   define_bool CONFIG_DEBUG_INFO n
else
   bool 'Debugging symbols' CONFIG_DEBUG_INFO
fi

And you can use single ifdefs in Makefiles?

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From sjhill@realitydiluted.com Mon Mar  3 19:57:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 19:57:25 +0000 (GMT)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:24291
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225243AbTCCT5Y>; Mon, 3 Mar 2003 19:57:24 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 18pw3u-0000QT-00
	for <linux-mips@linux-mips.org>; Mon, 03 Mar 2003 13:57:22 -0600
Message-ID: <3E63B17C.8000403@realitydiluted.com>
Date: Mon, 03 Mar 2003 13:48:12 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Improper handling of unaligned user address access?
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: 1604
X-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
Content-Length: 1777
Lines: 47

Greetings.

I am having some issues using 'copy_from_user' in a driver. The issue
is that instead of returning a EFAULT for a bad address, it throws a
kernel panic and then proceeds to segfault the application. I am doing
a test on the module where I pass in an invalid user source address:

    copy_from_user(&dst, src, sizeof(dst));

where 'src' is equal to '0xa'. Now for the interesting part. When it
goes to do the copy, in 'arch/mips/lib/memcpy.S' it correctly jumps
to 'src_unaligned_dst_aligned' and then to 'cleanup_src_unaligned'
and we have the following code:

    8025f004 <cleanup_src_unaligned>:
    8025f004:       10c00017        beqz    a2,8025f064 <done>
    8025f008:       30d80003        andi    t8,a2,0x3
    8025f00c:       13060009        beq     t8,a2,8025f034 <copy_bytes>
    8025f010:       88a80000        lwl     t0,0(a1)

The instruction at 8025f00c is the offending instruction, however, the
kernel oops that kills the process shows:

    Unable to handle kernel paging request at virtual address 0000000a,
    epc == 8025f00c, ra == 8011c3c8
    Oops in fault.c:do_page_fault, line 199:
    $0 : 00000000 00000012 0000001a 0000001a 87887f10 0000000a 00000008 
00000001
    $8 : 00000000 00000000 00000000 00001116 802ec2f0 fffffffe ffffffff 
00000010
    $16: 0000000a 7fff7d68 87887f10 00000000 004009b4 00000000 00000000 
00000000
    $24: 00000000 87887e18                   87886000 87887f00 7fff7d30 
8011c3c8
    Hi : 00000000
    Lo : 00000000
    epc  : 8025f00c    Not tainted
    Status: 3000fc03
    Cause : 90000008

I am using the last version of the 2.4.18 Linux/MIPS kernel. It looks
like there was a possible fix for this in 'arch/mips/kernel/unaligned.c'
by Ralf, but it did not seem to work. Any thoughts on this?

-Steve



From Geert.Uytterhoeven@sonycom.com Mon Mar  3 21:23:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 21:23:07 +0000 (GMT)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:50641 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225243AbTCCVXG>;
	Mon, 3 Mar 2003 21:23:06 +0000
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id WAA18717;
	Mon, 3 Mar 2003 22:22:26 +0100 (MET)
Date: Mon, 3 Mar 2003 22:22:31 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Improper handling of unaligned user address access?
In-Reply-To: <3E63B17C.8000403@realitydiluted.com>
Message-ID: <Pine.GSO.4.21.0303032219100.12650-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: 1605
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2484
Lines: 64

On Mon, 3 Mar 2003, Steven J. Hill wrote:
> I am having some issues using 'copy_from_user' in a driver. The issue
> is that instead of returning a EFAULT for a bad address, it throws a
> kernel panic and then proceeds to segfault the application. I am doing
> a test on the module where I pass in an invalid user source address:
> 
>     copy_from_user(&dst, src, sizeof(dst));
> 
> where 'src' is equal to '0xa'. Now for the interesting part. When it
> goes to do the copy, in 'arch/mips/lib/memcpy.S' it correctly jumps
> to 'src_unaligned_dst_aligned' and then to 'cleanup_src_unaligned'
> and we have the following code:
> 
>     8025f004 <cleanup_src_unaligned>:
>     8025f004:       10c00017        beqz    a2,8025f064 <done>
>     8025f008:       30d80003        andi    t8,a2,0x3
>     8025f00c:       13060009        beq     t8,a2,8025f034 <copy_bytes>
>     8025f010:       88a80000        lwl     t0,0(a1)
> 
> The instruction at 8025f00c is the offending instruction, however, the
                     ^^^^^^^^
Don't you mean 8025f010?

> kernel oops that kills the process shows:
> 
>     Unable to handle kernel paging request at virtual address 0000000a,
>     epc == 8025f00c, ra == 8011c3c8
>     Oops in fault.c:do_page_fault, line 199:
>     $0 : 00000000 00000012 0000001a 0000001a 87887f10 0000000a 00000008 
> 00000001
>     $8 : 00000000 00000000 00000000 00001116 802ec2f0 fffffffe ffffffff 
> 00000010
>     $16: 0000000a 7fff7d68 87887f10 00000000 004009b4 00000000 00000000 
> 00000000
>     $24: 00000000 87887e18                   87886000 87887f00 7fff7d30 
> 8011c3c8
>     Hi : 00000000
>     Lo : 00000000
>     epc  : 8025f00c    Not tainted
>     Status: 3000fc03
>     Cause : 90000008
> 
> I am using the last version of the 2.4.18 Linux/MIPS kernel. It looks
> like there was a possible fix for this in 'arch/mips/kernel/unaligned.c'
> by Ralf, but it did not seem to work. Any thoughts on this?

This looks like the unaligned access in a branch delay slot problem I
experienced a while ago, where the CPU doesn't set the BD flag if the branch is
not taken. Can you please try the patch I posted?

BTW, what kind of CPU is this? A VR41xx?

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 uhler@mips.com Mon Mar  3 21:38:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 21:38:38 +0000 (GMT)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:26512 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225243AbTCCVih>;
	Mon, 3 Mar 2003 21:38:37 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h23LcAUe013071;
	Mon, 3 Mar 2003 13:38:16 -0800 (PST)
Received: from uhler-linux.mips.com (uhler-linux [192.168.11.222])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id NAA00735;
	Mon, 3 Mar 2003 13:38:12 -0800 (PST)
Received: from uhler-linux.mips.com (uhler@localhost)
	by uhler-linux.mips.com (8.11.2/8.9.3) with ESMTP id h23LcCF25903;
	Mon, 3 Mar 2003 13:38:12 -0800
Message-Id: <200303032138.h23LcCF25903@uhler-linux.mips.com>
X-Authentication-Warning: uhler-linux.mips.com: uhler owned process doing -bs
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: "Steven J. Hill" <sjhill@realitydiluted.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
cc: uhler@mips.com
Reply-To: uhler@mips.com
Subject: Re: Improper handling of unaligned user address access? 
In-reply-to: Your message of "Mon, 03 Mar 2003 22:22:31 +0100."
             <Pine.GSO.4.21.0303032219100.12650-100000@vervain.sonytel.be> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 03 Mar 2003 13:38:12 -0800
From: "Mike Uhler" <uhler@mips.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: 1606
X-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
Content-Length: 1975
Lines: 52


<snip>

> > 
> >     8025f004 <cleanup_src_unaligned>:
> >     8025f004:       10c00017        beqz    a2,8025f064 <done>
> >     8025f008:       30d80003        andi    t8,a2,0x3
> >     8025f00c:       13060009        beq     t8,a2,8025f034 <copy_bytes>
> >     8025f010:       88a80000        lwl     t0,0(a1)
> > 
> > The instruction at 8025f00c is the offending instruction, however, the
>                      ^^^^^^^^
> Don't you mean 8025f010?
> 

<snip>

> >     epc == 8025f00c, ra == 8011c3c8
> >     epc  : 8025f00c    Not tainted
> >     Status: 3000fc03
> >     Cause : 90000008
> > 
> > I am using the last version of the 2.4.18 Linux/MIPS kernel. It looks
> > like there was a possible fix for this in 'arch/mips/kernel/unaligned.c'
> > by Ralf, but it did not seem to work. Any thoughts on this?
> 
> This looks like the unaligned access in a branch delay slot problem I
> experienced a while ago, where the CPU doesn't set the BD flag if the branch is
> not taken. Can you please try the patch I posted?

In this particular case, it would appear that it's not the delay slot problem.
According to the Cause value above, BD is set, and EPC has been rolled
back to point at the branch.  That all looks consistent to me.

Note that the lwl will not take an unaligned exception, and the Cause code
value indicates a TLB miss.  I don't have the full context of the problem,
but is 0xA (i.e., virtual page zero) actually a valid address?  If not,
that's the cause of the problem.

By the way, having the oops message put out the BadVAddr and PRId CP0 registers
would be very helpful.

/gmu
-- 

  =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Michael Uhler, VP, Systems, Architecture, and Software Products 
  MIPS Technologies, Inc.   Email: uhler@mips.com   Pager: uhler_p@mips.com
  1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
  Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085



From sjhill@realitydiluted.com Mon Mar  3 22:26:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Mar 2003 22:26:02 +0000 (GMT)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:18404
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225243AbTCCW0C>; Mon, 3 Mar 2003 22:26:02 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 18pyNY-0000bz-00; Mon, 03 Mar 2003 16:25:48 -0600
Message-ID: <3E63D43A.2080705@realitydiluted.com>
Date: Mon, 03 Mar 2003 16:16:26 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9
X-Accept-Language: en
MIME-Version: 1.0
To: uhler@mips.com
CC: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Improper handling of unaligned user address access?
References: <200303032138.h23LcCF25903@uhler-linux.mips.com>
In-Reply-To: <200303032138.h23LcCF25903@uhler-linux.mips.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1607
X-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
Content-Length: 1843
Lines: 49

Mike Uhler wrote:
>>
>>This looks like the unaligned access in a branch delay slot problem I
>>experienced a while ago, where the CPU doesn't set the BD flag if the branch is
>>not taken. Can you please try the patch I posted?
> 
> 
> In this particular case, it would appear that it's not the delay slot problem.
> According to the Cause value above, BD is set, and EPC has been rolled
> back to point at the branch.  That all looks consistent to me.
> 
> Note that the lwl will not take an unaligned exception, and the Cause code
> value indicates a TLB miss.  I don't have the full context of the problem,
> but is 0xA (i.e., virtual page zero) actually a valid address?  If not,
> that's the cause of the problem.
> 
You are correct. 0xA is NOT actually a valid address which is the
problem. I believe the kernel should handle things more gracefully
and return EFAULT instead of killing the process. This code of mine
worked fine in an older 2.4.7 kernel. Why was 'verify_area' taken
out of 'traps.c' by the way?

> By the way, having the oops message put out the BadVAddr and PRId CP0 registers
> would be very helpful.
> 
Here it is:

    <1>Unable to handle kernel paging request at virtual address 000000a,
      epc == 8025f00c, ra == 8011c3d4
    <1>BADVADDR = 00000000, CP0_PRID = 00002d22
    Oops in fault.c:do_page_fault, line 201:
    $0 : 00000000 00000012 0000001a 0000001a 8789ff18 0000000a 00000008
      7fff7d58
    $8 : 00000000 00000000 00000000 00000000 71236429 2aaa8000 7fff77f8
      2aaa83f8
    $16: 8789ff18 7fff7d58 00000000 00000001 004009b4 00000000 00000000
      00000000
    $24: 00000000 00401638                   8789e000 8789ff08 7fff7d20
      8011c3d4
    Hi : 00000007
    Lo : 00000000
    epc  : 8025f00c    Tainted: P
    Status: 3000fc03
    Cause : 90000008

The processor is a TX4927.

-Steve


From sjhill@realitydiluted.com Tue Mar  4 00:23:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 00:23:32 +0000 (GMT)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:40932
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225253AbTCDAXb>; Tue, 4 Mar 2003 00:23:31 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 18q0DS-0000gE-00; Mon, 03 Mar 2003 18:23:30 -0600
Message-ID: <3E63EFDC.6090605@realitydiluted.com>
Date: Mon, 03 Mar 2003 18:14:20 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9
X-Accept-Language: en
MIME-Version: 1.0
To: "Steven J. Hill" <sjhill@realitydiluted.com>
CC: linux-mips@linux-mips.org
Subject: Re: Improper handling of unaligned user address access?
References: <3E63B17C.8000403@realitydiluted.com>
In-Reply-To: <3E63B17C.8000403@realitydiluted.com>
Content-Type: multipart/mixed;
 boundary="------------080509080807080001030003"
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: 1608
X-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
Content-Length: 2111
Lines: 70

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

The first thing I tried to fix this issue was to use the
'memcpy.S' file from 2.4.7 and that actually worked, but
that was a step backwards. It was much simpler to just
add a 'nop' after the offending branch instruction. It
fixes all of my problems with 'copy_from_user'. I have
already checked these into both the 2.4 and 2.5 trees.

I do have one further question. In 'arch/mips/mm/fault.c'
when we need to do a fixup:

    fixup = search_exception_table(regs->cp0_epc);

Why do we not check to see if the EPC is a branch insn
before looking in the exception table?

-Steve

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

Index: memcpy.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/lib/memcpy.S,v
retrieving revision 1.6.2.4
diff -u -r1.6.2.4 memcpy.S
--- memcpy.S	19 Sep 2002 14:01:24 -0000	1.6.2.4
+++ memcpy.S	4 Mar 2003 00:09:52 -0000
@@ -357,6 +357,7 @@
 	beqz	len, done
 	 and	rem, len, NBYTES-1  # rem = len % NBYTES
 	beq	rem, len, copy_bytes
+	nop
 1:
 EXC(	 LDFIRST t0, FIRST(0)(src),	l_exc)
 EXC(	LDREST	t0, REST(0)(src),	l_exc_copy)

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

Index: memcpy.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/lib/memcpy.S,v
retrieving revision 1.11
diff -u -r1.11 memcpy.S
--- memcpy.S	19 Sep 2002 14:01:28 -0000	1.11
+++ memcpy.S	4 Mar 2003 00:10:58 -0000
@@ -357,6 +357,7 @@
 	beqz	len, done
 	 and	rem, len, NBYTES-1  # rem = len % NBYTES
 	beq	rem, len, copy_bytes
+	nop
 1:
 EXC(	 LDFIRST t0, FIRST(0)(src),	l_exc)
 EXC(	LDREST	t0, REST(0)(src),	l_exc_copy)

--------------080509080807080001030003--


From rpalani2@yahoo.com Tue Mar  4 01:15:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 01:15:03 +0000 (GMT)
Received: from web13302.mail.yahoo.com ([IPv6:::ffff:216.136.175.38]:37806
	"HELO web13302.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225253AbTCDBPC>; Tue, 4 Mar 2003 01:15:02 +0000
Message-ID: <20030304011459.457.qmail@web13302.mail.yahoo.com>
Received: from [206.31.31.3] by web13302.mail.yahoo.com via HTTP; Mon, 03 Mar 2003 17:14:59 PST
Date: Mon, 3 Mar 2003 17:14:59 -0800 (PST)
From: Rajesh Palani <rpalani2@yahoo.com>
Subject: JVM under Linux on MIPS
To: linux-mips@linux-mips.org
In-Reply-To: <20030302121820.A30790@linux-mips.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1248714191-1046740499=:98873"
Return-Path: <rpalani2@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: 1609
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rpalani2@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 861
Lines: 23

--0-1248714191-1046740499=:98873
Content-Type: text/plain; charset=us-ascii


Hi,
   Has anyone had any success running any open source JVMs (other than Cobalt machines running Transvirtual's Kaffe) under Linux/MIPS.
   Thanks and regards,
   Rajesh



---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more
--0-1248714191-1046740499=:98873
Content-Type: text/html; charset=us-ascii

<P>Hi,
<P>&nbsp;&nbsp; Has anyone had any success running any open source JVMs (other than Cobalt machines running Transvirtual's Kaffe) under Linux/MIPS.
<P>&nbsp;&nbsp;&nbsp;Thanks and regards,
<P>&nbsp;&nbsp; Rajesh</P><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/">Yahoo! Tax Center</a> - forms, calculators, tips, and more
--0-1248714191-1046740499=:98873--

From jsun@orion.mvista.com Tue Mar  4 01:42:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 01:42:02 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:35056 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225251AbTCDBmB>;
	Tue, 4 Mar 2003 01:42:01 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h241fr419627;
	Mon, 3 Mar 2003 17:41:53 -0800
Date: Mon, 3 Mar 2003 17:41:53 -0800
From: Jun Sun <jsun@mvista.com>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Improper handling of unaligned user address access?
Message-ID: <20030303174153.B19572@mvista.com>
References: <3E63B17C.8000403@realitydiluted.com> <3E63EFDC.6090605@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3E63EFDC.6090605@realitydiluted.com>; from sjhill@realitydiluted.com on Mon, Mar 03, 2003 at 06:14:20PM -0600
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1610
X-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
Content-Length: 772
Lines: 24

On Mon, Mar 03, 2003 at 06:14:20PM -0600, Steven J. Hill wrote:
> The first thing I tried to fix this issue was to use the
> 'memcpy.S' file from 2.4.7 and that actually worked, but
> that was a step backwards. It was much simpler to just
> add a 'nop' after the offending branch instruction. It
> fixes all of my problems with 'copy_from_user'. 

Adding 'nop' seems to be right.

> I do have one further question. In 'arch/mips/mm/fault.c'
> when we need to do a fixup:
> 
>     fixup = search_exception_table(regs->cp0_epc);
>
> Why do we not check to see if the EPC is a branch insn
> before looking in the exception table?
>

You must be looking at a different tree.  We do check epc
for branch instruction:

	fixup = search_exception_table(exception_epc(regs));

Jun

From baitisj@idealab.com Tue Mar  4 02:14:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 02:14:27 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:31926 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225251AbTCDCOZ>;
	Tue, 4 Mar 2003 02:14:25 +0000
Received: (qmail 6562 invoked by uid 6180); 4 Mar 2003 02:14:21 -0000
Date: Mon, 3 Mar 2003 18:14:21 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: CardBus on DBAu1500
Message-ID: <20030303181421.C20129@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030228194820.Z20129@luca.pas.lab> <1046499358.12356.2.camel@adsl.pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <1046499358.12356.2.camel@adsl.pacbell.net>; from ppopov@mvista.com on Fri, Feb 28, 2003 at 10:15:58PM -0800
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: 1611
X-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
Content-Length: 15247
Lines: 383

Pete and others:

Thanks! I can access CardBus-enabled cards... but only if I plug the CardBus
card into a PCI bridge device. 

For those who might be interested in hearing, here's my current status:

I tested the PCI->PCI bridge code by copying pb1500/pci_ops.c into
db1x00/pci_ops.c. It seemed to work. Great!

After noticing that yenta_socket driver still locked up, I plugged a PCI-PCI
bridge board in between the Au1500 dev board and the CardBus bridge. CardBus
didn't work quite right, so I checked the PCI configuration registers on all
devices on my PCI bus.

I noticed the PCI bridge device's SUBORDINATE_BUS value was set to 01, which
is completely incorrect. It should have been at *least* 11, given that
the CardBus bridge's SECONDARY_BUS register was set to 10. 

So, I used setpci to change the PCI bridge's SUBORDINATE_BUS to 1f. I started
the CardBus services, and it seems that everything worked with CardBus cards.
Eject, insert, and status all good -- and I can look at all the PCI
configuration registers on the CardBus card.

***

It seems like the issue with plugging in the CardBus bridge directly into
PCI bus 0 (no PCI-PCI bridge) has to do with 16-bit CardBus support.
I enabled debugging on yenta_socket, and here's some results. First, I present
information *without* the PCI bridge, and then *with* PCI bridge.


Without PCI bridge:

dmesg gives:

  Autoconfig PCI channel 0x8029fc38°°
    Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
    00:0c.0 Class 0104: 1103:0007 (rev 01)°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°                                                                
            I/O at 0x00000300 [size=0x8]°°                         
            I/O at 0x00000308 [size=0x4]
            I/O at 0x00000310 [size=0x8]
            I/O at 0x00000318 [size=0x4]
            I/O at 0x00000400 [size=0x100]
    00:0d.0 Class 0607: 104c:ac56°°°°°°°°°                         
            Mem at 0x40000000 [size=0x1000]                        
            Mem unavailable -- skipping°°°°                        
            I/O at 0x00000500 [size=0x4]                           
            Mem at 0x40001000 [size=0x1000]                        
            Mem at 0x40002000 [size=0x1000]                        
            Mem at 0x40003000 [size=0x1000]                        
  
lspci -v gives:
  
  00:0c.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0007
  (rev 01)
          Subsystem: Triones Technologies, Inc.: Unknown device 0001
          Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 1
          I/O ports at 0300 [size=8]
          I/O ports at 0308 [size=4]
          I/O ports at 0310 [size=8]
          I/O ports at 0318 [size=4]
          I/O ports at 0400 [size=256]
          Expansion ROM at <unassigned> [disabled] [size=128K]   
          Capabilities: [60] Power Management version 2          
  
  00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56 
          Subsystem: Unknown device 5678:1234                    
          Flags: bus master, medium devsel, latency 128, IRQ 1   
          Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
          Bus: primary=00, secondary=05, subordinate=00, sec-latency=0      
          Memory window 0: 40001000-40002000 (prefetchable)      
          I/O window 0: 00000000-00000003                        
          I/O window 1: 00000000-00000003                        
          16-bit legacy interface ports at 0001                  


root@10.1.1.154:~# modprobe yenta_socket                       

  Linux Kernel Card Services 3.1.22
    options:  [pci] [cardbus]°°°°°°
  config_writel: c0112bd0 0044 00000000
  config_writel: c0112bd0 0010 40000000
  config_writew: c0112bd0 0004 0087°°°°
  config_writeb: c0112bd0 000c 08°°
  config_writeb: c0112bd0 000d a8
  config_writel: c0112bd0 0018 b0000500
  config_readw: c0112bd0 003e 0340°°°°°
  config_writew: c0112bd0 003e 0580
  exca_writeb: c0112bd0 001e 00°°°°
  exca_writeb: c0112bd0 0016 00
  cb_writel: c0112bd0 000c 00004000
  cb_writel: c0112bd0 0004 00000000
  config_readl: c0112bd0 001c 40001000
  config_readl: c0112bd0 0020 40002000
  config_readl: c0112bd0 0024 40003000
  config_readl: c0112bd0 0028 00000000
  config_writel: c0112bd0 0024 40400000
  config_writel: c0112bd0 0028 407fffff
  config_readl: c0112bd0 002c 00000000°
  config_readl: c0112bd0 0030 00000000
  config_writel: c0112bd0 002c 00004000
  config_writel: c0112bd0 0030 000040ff
  config_readl: c0112bd0 0034 00000000°
  config_readl: c0112bd0 0038 00000000
  config_writel: c0112bd0 0034 00004400
  config_writel: c0112bd0 0038 000044ff
  cb_readl: c0112bd0 0000 00000006°°°°°
  cb_writel: c0112bd0 0000 00000006
  exca_readb: c0112bd0 0004 00°°°°°
  exca_readb: c0112bd0 0003 00
  cb_readl: c0112bd0 0000 00000000
  cb_writel: c0112bd0 0000 00000000
  exca_readb: c0112bd0 0004 00°°°°°
  exca_readb: c0112bd0 0003 00
  cb_readl: c0112bd0 0000 00000000
  cb_writel: c0112bd0 0000 00000000
  exca_readb: c0112bd0 0004 00°°°°°
  exca_readb: c0112bd0 0003 00
  cb_readl: c0112bd0 0000 00000000
  cb_writel: c0112bd0 0000 00000000
  exca_readb: c0112bd0 0004 00°°°°°
  exca_readb: c0112bd0 0003 00
  cb_readl: c0112bd0 0000 00000000
  cb_writel: c0112bd0 0000 00000000
  exca_readb: c0112bd0 0004 00°°°°°
  exca_readb: c0112bd0 0003 00
  cb_readl: c0112bd0 0000 00000000
  cb_writel: c0112bd0 0000 00000000
  exca_readb: c0112bd0 0004 00°°°°°
  exca_readb: c0112bd0 0003 00
    ** following portion loops indefinitely **
  cb_readl: c0112bd0 0000 00000000
  cb_writel: c0112bd0 0000 00000000
  exca_readb: c0112bd0 0004 00°°°°°
  exca_readb: c0112bd0 0003 00

With PCI bridge:

  Autoconfig PCI channel 0x8029fc38°°
  Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
  00:0c.0 Class 0104: 1103:0007 (rev 01)°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
          I/O at 0x00000300 [size=0x8]°°
          I/O at 0x00000308 [size=0x4]
          I/O at 0x00000310 [size=0x8]
          I/O at 0x00000318 [size=0x4]
          I/O at 0x00000400 [size=0x100]
  00:0d.0 Class 0604: 1011:0022 (rev 02)
          Bridge: primary=00, secondary=01
  Scanning sub bus 01, I/O 0x00001000, Mem 0x40000000
  01:07.0 Class 0607: 104c:ac56°°°°°°°°°°°°°°°°°°°°°°
          Mem at 0x40000000 [size=0x1000]
          Mem unavailable -- skipping°°°°
          I/O at 0x00001000 [size=0x4]
          Mem at 0x40001000 [size=0x1000]
          Mem at 0x40002000 [size=0x1000]
          Mem at 0x40003000 [size=0x1000]
  Back to bus 00°°°°°°°°°°°°°°°°°°°°°°°°°

lspci -v gives:
  
  00:0c.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0007
  (rev 01)
          Subsystem: Triones Technologies, Inc.: Unknown device 0001
          Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 1
          I/O ports at 0300 [size=8]
          I/O ports at 0308 [size=4]
          I/O ports at 0310 [size=8]
          I/O ports at 0318 [size=4]
          I/O ports at 0400 [size=256]
          Expansion ROM at <unassigned> [disabled] [size=128K]
          Capabilities: [60] Power Management version 2
  
  00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 02)
  (prog-if 00 [Normal decode])
          Flags: bus master, medium devsel, latency 0
          Bus: primary=00, secondary=01, subordinate=1f, sec-latency=0
          I/O behind bridge: 00001000-00001fff     
          Memory behind bridge: 40000000-400fffff  
          Prefetchable memory behind bridge: 0000000000000000-0000000000000000
  
  01:07.0 CardBus bridge: Texas Instruments: Unknown device ac56
          Subsystem: Unknown device 5678:1234      
          Flags: bus master, medium devsel, latency 128, IRQ 255
          Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
          Bus: primary=00, secondary=10, subordinate=00, sec-latency=0
          Memory window 0: 40001000-40002000 (prefetchable)
          I/O window 0: 00000000-00000003
          I/O window 1: 00000000-00000003
          16-bit legacy interface ports at 0001    

root@10.1.1.154:~# modprobe yenta_socket                       

  Linux Kernel Card Services 3.1.22
    options:  [pci] [cardbus]°°°°°°
  config_writel: c0112bd0 0044 00000000
  config_writel: c0112bd0 0010 40000000
  config_writew: c0112bd0 0004 0087°°°°
  config_writeb: c0112bd0 000c 08°°
  config_writeb: c0112bd0 000d a8
  config_writel: c0112bd0 0018 b0001000
  config_readw: c0112bd0 003e 0340°°°°°
  config_writew: c0112bd0 003e 0580
  exca_writeb: c0112bd0 001e 00°°°°
  exca_writeb: c0112bd0 0016 00
  cb_writel: c0112bd0 000c 00004000
  cb_writel: c0112bd0 0004 00000000
  config_readl: c0112bd0 001c 40001000
  config_readl: c0112bd0 0020 40002000
  config_readl: c0112bd0 0024 40003000
  config_readl: c0112bd0 0028 00000000
  config_writel: c0112bd0 0024 10000000
  config_writel: c0112bd0 0028 103fffff
  config_readl: c0112bd0 002c 00000000°
  config_readl: c0112bd0 0030 00000000
  config_writel: c0112bd0 002c 00004000
  config_writel: c0112bd0 0030 000040ff
  config_readl: c0112bd0 0034 00000000°
  config_readl: c0112bd0 0038 00000000
  config_writel: c0112bd0 0034 00004400
  config_writel: c0112bd0 0038 000044ff
  config_readw: c0112bd0 003e 05c0°°°°°
  cb_writel: c0112bd0 0000 ffffffff
  cb_writel: c0112bd0 0004 00000001
  exca_writeb: c0112bd0 0005 00°°°°
  warning: end_irq 60 did not enable (6)
  warning: end_irq 59 did not enable (6)
  warning: end_irq 58 did not enable (6)
  warning: end_irq 57 did not enable (6)
  warning: end_irq 55 did not enable (6)
  warning: end_irq 52 did not enable (6)
  warning: end_irq 48 did not enable (6)
  warning: end_irq 46 did not enable (6)
  warning: end_irq 45 did not enable (6)
  warning: end_irq 44 did not enable (6)
  warning: end_irq 43 did not enable (6)
  warning: end_irq 42 did not enable (6)
  warning: end_irq 41 did not enable (6)
  warning: end_irq 40 did not enable (6)
  warning: end_irq 39 did not enable (6)
  warning: end_irq 38 did not enable (6)
  warning: end_irq 31 did not enable (6)
  warning: end_irq 27 did not enable (6)
  warning: end_irq 18 did not enable (6)
  warning: end_irq 14 did not enable (6)
  warning: end_irq 5 did not enable (6)°
  warning: end_irq 4 did not enable (6)
  warning: end_irq 2 did not enable (6)
  warning: end_irq 1 did not enable (6)
  warning: end_irq 60 did not enable (16)
  warning: end_irq 59 did not enable (16)
  warning: end_irq 58 did not enable (16)
  warning: end_irq 57 did not enable (16)
  warning: end_irq 55 did not enable (16)
  warning: end_irq 52 did not enable (16)
  warning: end_irq 48 did not enable (16)
  warning: end_irq 46 did not enable (16)
  warning: end_irq 45 did not enable (16)
  warning: end_irq 44 did not enable (16)
  warning: end_irq 43 did not enable (16)
  warning: end_irq 42 did not enable (16)
  warning: end_irq 41 did not enable (16)
  warning: end_irq 40 did not enable (16)
  warning: end_irq 39 did not enable (16)
  warning: end_irq 38 did not enable (16)
  warning: end_irq 27 did not enable (16)
  warning: end_irq 18 did not enable (16)
  warning: end_irq 5 did not enable (16)°
  warning: end_irq 4 did not enable (16)
  warning: end_irq 2 did not enable (16)
  warning: end_irq 1 did not enable (16)
  exca_writeb: c0112bd0 0005 31°°°°°°°°°
  cb_writel: c0112bd0 000c 00000001
  cb_writel: c0112bd0 0000 ffffffff
  exca_writeb: c0112bd0 0005 91°°°°
  cb_writel: c0112bd0 000c 00000001
  cb_writel: c0112bd0 0000 ffffffff
  exca_writeb: c0112bd0 0005 a1°°°°
  cb_writel: c0112bd0 000c 00000001
  cb_writel: c0112bd0 0000 ffffffff
  exca_writeb: c0112bd0 0005 b1°°°°
  cb_writel: c0112bd0 000c 00000001
  cb_writel: c0112bd0 0000 ffffffff
  cb_writel: c0112bd0 0004 00000000
  exca_writeb: c0112bd0 0005 00°°°°
  config_writew: c0112bd0 003e 0540
  Yenta IRQ list 0000, PCI irq0°°°°
  cb_readl: c0112bd0 0008 30000020
  Socket status: 30000020°°°°°°°°°
  config_writel: c0112bd0 0044 00000000
  config_writel: c0112bd0 0010 40000000
  config_writew: c0112bd0 0004 0087°°°°
  config_writeb: c0112bd0 000c 08°°
  config_writeb: c0112bd0 000d a8
  config_writel: c0112bd0 0018 b0001000
  config_readw: c0112bd0 003e 0540°°°°°
  config_writew: c0112bd0 003e 0580
  exca_writeb: c0112bd0 001e 00°°°°
  exca_writeb: c0112bd0 0016 00
  cb_writel: c0112bd0 000c 00004000
  cb_readl: c0112bd0 0010 00000400°
  cb_writel: c0112bd0 0010 00000000
  config_readw: c0112bd0 003e 05c0°
  cb_readl: c0112bd0 0008 30000820
  exca_readb: c0112bd0 0003 00°°°°
  exca_writeb: c0112bd0 0003 00
  config_writew: c0112bd0 003e 0580
  cb_writel: c0112bd0 0000 ffffffff
  cb_writel: c0112bd0 0004 00000006
  exca_readb: c0112bd0 0006 00°°°°°
  exca_writew: c0112bd0 0008 0000
  exca_writew: c0112bd0 000a 0001
  exca_readb: c0112bd0 0007 00°°°
  exca_writeb: c0112bd0 0007 00
  exca_readb: c0112bd0 0006 00°
  exca_writew: c0112bd0 000c 0000
  exca_writew: c0112bd0 000e 0001
  exca_readb: c0112bd0 0007 00°°°
  exca_writeb: c0112bd0 0007 00
  exca_readb: c0112bd0 0006 00°
  exca_writeb: c0112bd0 0040 00
  exca_writew: c0112bd0 0010 0000
  exca_writew: c0112bd0 0012 0000
  exca_writew: c0112bd0 0014 0000
  ..... etc etc 
  
Thanks, all, for the information. I hope someone finds this useful!
I'm gonna get remote kgdb goin' here, so I can hopefully fix the obnoxious
infinite loop...

-Jeff


On Fri, Feb 28, 2003 at 10:15:58PM -0800, Pete Popov wrote:
> On Fri, 2003-02-28 at 19:48, Jeff Baitis wrote:
> > Hey Pete and others!
> > 
> > I'm finally working on CardBus support on the DBAu1500. Just got acquainted
> > with PCI today. :)
> > 
> > I decided that the first step is to plug in a PCI->PCI bridge, and try to see
> > if it would work, which it did not. After winding around inside of the kernel,
> > I finally arrived in arch/mips/au1000/db1x00/pci_ops.c:
> > 
> > Inside of config_access(unsigned char access_type, struct pci_dev *dev,
> > unsigned char where, u32 * data), on line 97, a little surprise:
> > 
> >     if (bus != 0) {
> >         *data = 0xffffffff;
> >         return -1;
> >     }
> > 
> > At this point, I concluded that I cannot traverse a PCI-PCI or CardBus bridge,
> > since any devices behind the bridge will require Type 1 Configuration Cycles,
> > and it seems that only Type 0 is currently supported.
> > 
> > I assume that I should add code to handle the case where I need to generate
> > Type 1 Configuration Cycles inside of config_access. Pete, since you authored
> > this code, I thought I'd quickly run this by you to make sure that I'm on
> > track.
> > 
> > Thanks for your suggestions!
> 
> Take a look at arch/mips/au1000/pb1500/pci_ops.c for type 1 config
> access. The patch was courtesy of David Gathright and apparently I
> missed adding it in the db1500. Actually, we need to combine that code
> because it's the same. Let me get through my eternal struggle of getting
> the 36 bit patch applied (with Ralf's help I think a modified patch
> should be ready this weekend) and then I'll worry about clean ups :)
> 
> Pete
> 
> 

-- 
         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 ppopov@mvista.com Tue Mar  4 02:24:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 02:24:03 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:30969 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225251AbTCDCYC>;
	Tue, 4 Mar 2003 02:24:02 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA17451;
	Mon, 3 Mar 2003 18:23:55 -0800
Subject: Re: CardBus on DBAu1500
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com
Cc: linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <20030303181421.C20129@luca.pas.lab>
References: <20030228194820.Z20129@luca.pas.lab>
	 <1046499358.12356.2.camel@adsl.pacbell.net>
	 <20030303181421.C20129@luca.pas.lab>
Content-Type: text/plain; charset=ISO-8859-1
Organization: MontaVista Software
Message-Id: <1046744700.29357.54.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 03 Mar 2003 18:25:01 -0800
Content-Transfer-Encoding: 8bit
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: 1612
X-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
Content-Length: 15634
Lines: 373


> I tested the PCI->PCI bridge code by copying pb1500/pci_ops.c into
> db1x00/pci_ops.c. It seemed to work. Great!

I'll fix that. Actually, the code is the same for the Pb1500 and Db1500,
so I'll merge it into a common file.

Pete

> After noticing that yenta_socket driver still locked up, I plugged a PCI-PCI
> bridge board in between the Au1500 dev board and the CardBus bridge. CardBus
> didn't work quite right, so I checked the PCI configuration registers on all
> devices on my PCI bus.
> 
> I noticed the PCI bridge device's SUBORDINATE_BUS value was set to 01, which
> is completely incorrect. It should have been at *least* 11, given that
> the CardBus bridge's SECONDARY_BUS register was set to 10. 

> So, I used setpci to change the PCI bridge's SUBORDINATE_BUS to 1f. I started
> the CardBus services, and it seems that everything worked with CardBus cards.
> Eject, insert, and status all good -- and I can look at all the PCI
> configuration registers on the CardBus card.
> 
> ***
> 
> It seems like the issue with plugging in the CardBus bridge directly into
> PCI bus 0 (no PCI-PCI bridge) has to do with 16-bit CardBus support.
> I enabled debugging on yenta_socket, and here's some results. First, I present
> information *without* the PCI bridge, and then *with* PCI bridge.
> 
> 
> Without PCI bridge:
> 
> dmesg gives:
> 
>   Autoconfig PCI channel 0x8029fc38°°
>     Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
>     00:0c.0 Class 0104: 1103:0007 (rev 01)°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°                                                                
>             I/O at 0x00000300 [size=0x8]°°                         
>             I/O at 0x00000308 [size=0x4]
>             I/O at 0x00000310 [size=0x8]
>             I/O at 0x00000318 [size=0x4]
>             I/O at 0x00000400 [size=0x100]
>     00:0d.0 Class 0607: 104c:ac56°°°°°°°°°                         
>             Mem at 0x40000000 [size=0x1000]                        
>             Mem unavailable -- skipping°°°°                        
>             I/O at 0x00000500 [size=0x4]                           
>             Mem at 0x40001000 [size=0x1000]                        
>             Mem at 0x40002000 [size=0x1000]                        
>             Mem at 0x40003000 [size=0x1000]                        
>   
> lspci -v gives:
>   
>   00:0c.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0007
>   (rev 01)
>           Subsystem: Triones Technologies, Inc.: Unknown device 0001
>           Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 1
>           I/O ports at 0300 [size=8]
>           I/O ports at 0308 [size=4]
>           I/O ports at 0310 [size=8]
>           I/O ports at 0318 [size=4]
>           I/O ports at 0400 [size=256]
>           Expansion ROM at <unassigned> [disabled] [size=128K]   
>           Capabilities: [60] Power Management version 2          
>   
>   00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56 
>           Subsystem: Unknown device 5678:1234                    
>           Flags: bus master, medium devsel, latency 128, IRQ 1   
>           Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
>           Bus: primary=00, secondary=05, subordinate=00, sec-latency=0      
>           Memory window 0: 40001000-40002000 (prefetchable)      
>           I/O window 0: 00000000-00000003                        
>           I/O window 1: 00000000-00000003                        
>           16-bit legacy interface ports at 0001                  
> 
> 
> root@10.1.1.154:~# modprobe yenta_socket                       
> 
>   Linux Kernel Card Services 3.1.22
>     options:  [pci] [cardbus]°°°°°°
>   config_writel: c0112bd0 0044 00000000
>   config_writel: c0112bd0 0010 40000000
>   config_writew: c0112bd0 0004 0087°°°°
>   config_writeb: c0112bd0 000c 08°°
>   config_writeb: c0112bd0 000d a8
>   config_writel: c0112bd0 0018 b0000500
>   config_readw: c0112bd0 003e 0340°°°°°
>   config_writew: c0112bd0 003e 0580
>   exca_writeb: c0112bd0 001e 00°°°°
>   exca_writeb: c0112bd0 0016 00
>   cb_writel: c0112bd0 000c 00004000
>   cb_writel: c0112bd0 0004 00000000
>   config_readl: c0112bd0 001c 40001000
>   config_readl: c0112bd0 0020 40002000
>   config_readl: c0112bd0 0024 40003000
>   config_readl: c0112bd0 0028 00000000
>   config_writel: c0112bd0 0024 40400000
>   config_writel: c0112bd0 0028 407fffff
>   config_readl: c0112bd0 002c 00000000°
>   config_readl: c0112bd0 0030 00000000
>   config_writel: c0112bd0 002c 00004000
>   config_writel: c0112bd0 0030 000040ff
>   config_readl: c0112bd0 0034 00000000°
>   config_readl: c0112bd0 0038 00000000
>   config_writel: c0112bd0 0034 00004400
>   config_writel: c0112bd0 0038 000044ff
>   cb_readl: c0112bd0 0000 00000006°°°°°
>   cb_writel: c0112bd0 0000 00000006
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>     ** following portion loops indefinitely **
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
> 
> With PCI bridge:
> 
>   Autoconfig PCI channel 0x8029fc38°°
>   Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
>   00:0c.0 Class 0104: 1103:0007 (rev 01)°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
>           I/O at 0x00000300 [size=0x8]°°
>           I/O at 0x00000308 [size=0x4]
>           I/O at 0x00000310 [size=0x8]
>           I/O at 0x00000318 [size=0x4]
>           I/O at 0x00000400 [size=0x100]
>   00:0d.0 Class 0604: 1011:0022 (rev 02)
>           Bridge: primary=00, secondary=01
>   Scanning sub bus 01, I/O 0x00001000, Mem 0x40000000
>   01:07.0 Class 0607: 104c:ac56°°°°°°°°°°°°°°°°°°°°°°
>           Mem at 0x40000000 [size=0x1000]
>           Mem unavailable -- skipping°°°°
>           I/O at 0x00001000 [size=0x4]
>           Mem at 0x40001000 [size=0x1000]
>           Mem at 0x40002000 [size=0x1000]
>           Mem at 0x40003000 [size=0x1000]
>   Back to bus 00°°°°°°°°°°°°°°°°°°°°°°°°°
> 
> lspci -v gives:
>   
>   00:0c.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0007
>   (rev 01)
>           Subsystem: Triones Technologies, Inc.: Unknown device 0001
>           Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 1
>           I/O ports at 0300 [size=8]
>           I/O ports at 0308 [size=4]
>           I/O ports at 0310 [size=8]
>           I/O ports at 0318 [size=4]
>           I/O ports at 0400 [size=256]
>           Expansion ROM at <unassigned> [disabled] [size=128K]
>           Capabilities: [60] Power Management version 2
>   
>   00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 02)
>   (prog-if 00 [Normal decode])
>           Flags: bus master, medium devsel, latency 0
>           Bus: primary=00, secondary=01, subordinate=1f, sec-latency=0
>           I/O behind bridge: 00001000-00001fff     
>           Memory behind bridge: 40000000-400fffff  
>           Prefetchable memory behind bridge: 0000000000000000-0000000000000000
>   
>   01:07.0 CardBus bridge: Texas Instruments: Unknown device ac56
>           Subsystem: Unknown device 5678:1234      
>           Flags: bus master, medium devsel, latency 128, IRQ 255
>           Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
>           Bus: primary=00, secondary=10, subordinate=00, sec-latency=0
>           Memory window 0: 40001000-40002000 (prefetchable)
>           I/O window 0: 00000000-00000003
>           I/O window 1: 00000000-00000003
>           16-bit legacy interface ports at 0001    
> 
> root@10.1.1.154:~# modprobe yenta_socket                       
> 
>   Linux Kernel Card Services 3.1.22
>     options:  [pci] [cardbus]°°°°°°
>   config_writel: c0112bd0 0044 00000000
>   config_writel: c0112bd0 0010 40000000
>   config_writew: c0112bd0 0004 0087°°°°
>   config_writeb: c0112bd0 000c 08°°
>   config_writeb: c0112bd0 000d a8
>   config_writel: c0112bd0 0018 b0001000
>   config_readw: c0112bd0 003e 0340°°°°°
>   config_writew: c0112bd0 003e 0580
>   exca_writeb: c0112bd0 001e 00°°°°
>   exca_writeb: c0112bd0 0016 00
>   cb_writel: c0112bd0 000c 00004000
>   cb_writel: c0112bd0 0004 00000000
>   config_readl: c0112bd0 001c 40001000
>   config_readl: c0112bd0 0020 40002000
>   config_readl: c0112bd0 0024 40003000
>   config_readl: c0112bd0 0028 00000000
>   config_writel: c0112bd0 0024 10000000
>   config_writel: c0112bd0 0028 103fffff
>   config_readl: c0112bd0 002c 00000000°
>   config_readl: c0112bd0 0030 00000000
>   config_writel: c0112bd0 002c 00004000
>   config_writel: c0112bd0 0030 000040ff
>   config_readl: c0112bd0 0034 00000000°
>   config_readl: c0112bd0 0038 00000000
>   config_writel: c0112bd0 0034 00004400
>   config_writel: c0112bd0 0038 000044ff
>   config_readw: c0112bd0 003e 05c0°°°°°
>   cb_writel: c0112bd0 0000 ffffffff
>   cb_writel: c0112bd0 0004 00000001
>   exca_writeb: c0112bd0 0005 00°°°°
>   warning: end_irq 60 did not enable (6)
>   warning: end_irq 59 did not enable (6)
>   warning: end_irq 58 did not enable (6)
>   warning: end_irq 57 did not enable (6)
>   warning: end_irq 55 did not enable (6)
>   warning: end_irq 52 did not enable (6)
>   warning: end_irq 48 did not enable (6)
>   warning: end_irq 46 did not enable (6)
>   warning: end_irq 45 did not enable (6)
>   warning: end_irq 44 did not enable (6)
>   warning: end_irq 43 did not enable (6)
>   warning: end_irq 42 did not enable (6)
>   warning: end_irq 41 did not enable (6)
>   warning: end_irq 40 did not enable (6)
>   warning: end_irq 39 did not enable (6)
>   warning: end_irq 38 did not enable (6)
>   warning: end_irq 31 did not enable (6)
>   warning: end_irq 27 did not enable (6)
>   warning: end_irq 18 did not enable (6)
>   warning: end_irq 14 did not enable (6)
>   warning: end_irq 5 did not enable (6)°
>   warning: end_irq 4 did not enable (6)
>   warning: end_irq 2 did not enable (6)
>   warning: end_irq 1 did not enable (6)
>   warning: end_irq 60 did not enable (16)
>   warning: end_irq 59 did not enable (16)
>   warning: end_irq 58 did not enable (16)
>   warning: end_irq 57 did not enable (16)
>   warning: end_irq 55 did not enable (16)
>   warning: end_irq 52 did not enable (16)
>   warning: end_irq 48 did not enable (16)
>   warning: end_irq 46 did not enable (16)
>   warning: end_irq 45 did not enable (16)
>   warning: end_irq 44 did not enable (16)
>   warning: end_irq 43 did not enable (16)
>   warning: end_irq 42 did not enable (16)
>   warning: end_irq 41 did not enable (16)
>   warning: end_irq 40 did not enable (16)
>   warning: end_irq 39 did not enable (16)
>   warning: end_irq 38 did not enable (16)
>   warning: end_irq 27 did not enable (16)
>   warning: end_irq 18 did not enable (16)
>   warning: end_irq 5 did not enable (16)°
>   warning: end_irq 4 did not enable (16)
>   warning: end_irq 2 did not enable (16)
>   warning: end_irq 1 did not enable (16)
>   exca_writeb: c0112bd0 0005 31°°°°°°°°°
>   cb_writel: c0112bd0 000c 00000001
>   cb_writel: c0112bd0 0000 ffffffff
>   exca_writeb: c0112bd0 0005 91°°°°
>   cb_writel: c0112bd0 000c 00000001
>   cb_writel: c0112bd0 0000 ffffffff
>   exca_writeb: c0112bd0 0005 a1°°°°
>   cb_writel: c0112bd0 000c 00000001
>   cb_writel: c0112bd0 0000 ffffffff
>   exca_writeb: c0112bd0 0005 b1°°°°
>   cb_writel: c0112bd0 000c 00000001
>   cb_writel: c0112bd0 0000 ffffffff
>   cb_writel: c0112bd0 0004 00000000
>   exca_writeb: c0112bd0 0005 00°°°°
>   config_writew: c0112bd0 003e 0540
>   Yenta IRQ list 0000, PCI irq0°°°°
>   cb_readl: c0112bd0 0008 30000020
>   Socket status: 30000020°°°°°°°°°
>   config_writel: c0112bd0 0044 00000000
>   config_writel: c0112bd0 0010 40000000
>   config_writew: c0112bd0 0004 0087°°°°
>   config_writeb: c0112bd0 000c 08°°
>   config_writeb: c0112bd0 000d a8
>   config_writel: c0112bd0 0018 b0001000
>   config_readw: c0112bd0 003e 0540°°°°°
>   config_writew: c0112bd0 003e 0580
>   exca_writeb: c0112bd0 001e 00°°°°
>   exca_writeb: c0112bd0 0016 00
>   cb_writel: c0112bd0 000c 00004000
>   cb_readl: c0112bd0 0010 00000400°
>   cb_writel: c0112bd0 0010 00000000
>   config_readw: c0112bd0 003e 05c0°
>   cb_readl: c0112bd0 0008 30000820
>   exca_readb: c0112bd0 0003 00°°°°
>   exca_writeb: c0112bd0 0003 00
>   config_writew: c0112bd0 003e 0580
>   cb_writel: c0112bd0 0000 ffffffff
>   cb_writel: c0112bd0 0004 00000006
>   exca_readb: c0112bd0 0006 00°°°°°
>   exca_writew: c0112bd0 0008 0000
>   exca_writew: c0112bd0 000a 0001
>   exca_readb: c0112bd0 0007 00°°°
>   exca_writeb: c0112bd0 0007 00
>   exca_readb: c0112bd0 0006 00°
>   exca_writew: c0112bd0 000c 0000
>   exca_writew: c0112bd0 000e 0001
>   exca_readb: c0112bd0 0007 00°°°
>   exca_writeb: c0112bd0 0007 00
>   exca_readb: c0112bd0 0006 00°
>   exca_writeb: c0112bd0 0040 00
>   exca_writew: c0112bd0 0010 0000
>   exca_writew: c0112bd0 0012 0000
>   exca_writew: c0112bd0 0014 0000
>   ..... etc etc 
>   
> Thanks, all, for the information. I hope someone finds this useful!
> I'm gonna get remote kgdb goin' here, so I can hopefully fix the obnoxious
> infinite loop...
> 
> -Jeff
> 
> 
> On Fri, Feb 28, 2003 at 10:15:58PM -0800, Pete Popov wrote:
> > On Fri, 2003-02-28 at 19:48, Jeff Baitis wrote:
> > > Hey Pete and others!
> > > 
> > > I'm finally working on CardBus support on the DBAu1500. Just got acquainted
> > > with PCI today. :)
> > > 
> > > I decided that the first step is to plug in a PCI->PCI bridge, and try to see
> > > if it would work, which it did not. After winding around inside of the kernel,
> > > I finally arrived in arch/mips/au1000/db1x00/pci_ops.c:
> > > 
> > > Inside of config_access(unsigned char access_type, struct pci_dev *dev,
> > > unsigned char where, u32 * data), on line 97, a little surprise:
> > > 
> > >     if (bus != 0) {
> > >         *data = 0xffffffff;
> > >         return -1;
> > >     }
> > > 
> > > At this point, I concluded that I cannot traverse a PCI-PCI or CardBus bridge,
> > > since any devices behind the bridge will require Type 1 Configuration Cycles,
> > > and it seems that only Type 0 is currently supported.
> > > 
> > > I assume that I should add code to handle the case where I need to generate
> > > Type 1 Configuration Cycles inside of config_access. Pete, since you authored
> > > this code, I thought I'd quickly run this by you to make sure that I'm on
> > > track.
> > > 
> > > Thanks for your suggestions!
> > 
> > Take a look at arch/mips/au1000/pb1500/pci_ops.c for type 1 config
> > access. The patch was courtesy of David Gathright and apparently I
> > missed adding it in the db1500. Actually, we need to combine that code
> > because it's the same. Let me get through my eternal struggle of getting
> > the 36 bit patch applied (with Ralf's help I think a modified patch
> > should be ready this weekend) and then I'll worry about clean ups :)
> > 
> > Pete
> > 
> > 


From kevink@mips.com Tue Mar  4 07:48:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 07:48:45 +0000 (GMT)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:36524 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225251AbTCDHso>;
	Tue, 4 Mar 2003 07:48:44 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h247mSUe015802;
	Mon, 3 Mar 2003 23:48:28 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id XAA02292;
	Mon, 3 Mar 2003 23:48:28 -0800 (PST)
Message-ID: <004d01c2e223$5e9d8730$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Rajesh Palani" <rpalani2@yahoo.com>, <linux-mips@linux-mips.org>
References: <20030304011459.457.qmail@web13302.mail.yahoo.com>
Subject: Re: JVM under Linux on MIPS
Date: Tue, 4 Mar 2003 08:54:56 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0048_01C2E22B.BADDE2D0"
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: 1613
X-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
Content-Length: 5429
Lines: 148

This is a multi-part message in MIME format.

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

I developed a patch to post-Transvirtual Kaffe 1.0.7 that allows it to =
pass=20
all its internal regression tests and run the Spec JVM98 benchmarks
on MIPS/Linux on a MIPS Malta/5Kc system (little endian)
using H.K.'s "Red Hat" distribution (with an update to the X11
stuff).  The necessary code has been integrated into the Kaffe
CVS repository if you check out the current sources, or you
can apply the patch at
ftp://ftp.paralogos.com/pub/kaffe/mips/kaffe-1.0.7.patch_kevink_021001=20
to the 1.0.7 source release on the kaffe.org site.

Note that I did *not* get the JIT functioning fully.  It will run some
programs (including Caffeinemark) but contains the same bugs in=20
argument passing that I fixed for the interpreter linkage to native=20
methods, but the same fix doesn't quite work there, and I ran out of =
time=20
to look at it.  You therefore need to run configure with =
--with-engine=3Dintrp
and to not expect miraculous performance.

  ----- Original Message -----=20
  From: Rajesh Palani=20
  To: linux-mips@linux-mips.org=20
  Sent: Tuesday, March 04, 2003 2:14 AM
  Subject: JVM under Linux on MIPS


  Hi,=20

     Has anyone had any success running any open source JVMs (other than =
Cobalt machines running Transvirtual's Kaffe) under Linux/MIPS.=20

     Thanks and regards,=20

     Rajesh





-------------------------------------------------------------------------=
-----
  Do you Yahoo!?
  Yahoo! Tax Center - forms, calculators, tips, and more
------=_NextPart_000_0048_01C2E22B.BADDE2D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4919.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I developed a patch to =
post-Transvirtual Kaffe=20
1.0.7 that allows it to pass </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>all </FONT><FONT face=3DArial =
size=3D2>its internal=20
regression tests and run the Spec JVM98 benchmarks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>on MIPS/Linux on a MIPS Malta/5Kc =
system (little=20
endian)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>using H.K.'s "Red Hat" distribution =
(with an update=20
to the X11</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>stuff).&nbsp; The necessary code has =
been=20
integrated into the Kaffe</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CVS repository if you check out the =
current=20
sources, or you</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>can apply the patch at</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"ftp://ftp.paralogos.com/pub/kaffe/mips/kaffe-1.0.7.patch_kevink_0=
21001">ftp://ftp.paralogos.com/pub/kaffe/mips/kaffe-1.0.7.patch_kevink_02=
1001</A>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>to the 1.0.7 source release on the =
kaffe.org=20
site.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Note that I did *not* get the JIT =
functioning=20
fully.&nbsp; It will run some</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>programs (including Caffeinemark) but =
contains=20
</FONT><FONT face=3DArial size=3D2>the same bugs in </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>argument passing that I fixed for the =
interpreter=20
</FONT><FONT face=3DArial size=3D2>linkage to native </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>methods, but the same fix doesn't quite =
work there,=20
</FONT><FONT face=3DArial size=3D2>and I ran out of time </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>to look at it.&nbsp; You therefore need =
to run=20
</FONT><FONT face=3DArial size=3D2>configure with =
--with-engine=3Dintrp</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>and to not expect miraculous=20
performance.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Drpalani2@yahoo.com =
href=3D"mailto:rpalani2@yahoo.com">Rajesh Palani</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dlinux-mips@linux-mips.org=20
  =
href=3D"mailto:linux-mips@linux-mips.org">linux-mips@linux-mips.org</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, March 04, 2003 =
2:14=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> JVM under Linux on =
MIPS</DIV>
  <DIV><BR></DIV>
  <P>Hi,=20
  <P>&nbsp;&nbsp; Has anyone had any success running any open source =
JVMs (other=20
  than Cobalt machines running Transvirtual's Kaffe) under Linux/MIPS.=20
  <P>&nbsp;&nbsp;&nbsp;Thanks and regards,=20
  <P>&nbsp;&nbsp; Rajesh</P>
  <P><BR>
  <HR SIZE=3D1>
  Do you Yahoo!?<BR><A=20
  =
href=3D"http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/"=
>Yahoo!=20
  Tax Center</A> - forms, calculators, tips, and =
more</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0048_01C2E22B.BADDE2D0--


From takano@os-omicron.org Tue Mar  4 08:14:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 08:14:25 +0000 (GMT)
Received: from [IPv6:::ffff:133.36.48.43] ([IPv6:::ffff:133.36.48.43]:64936
	"EHLO cat.os-omicron.org") by linux-mips.org with ESMTP
	id <S8225251AbTCDIOY>; Tue, 4 Mar 2003 08:14:24 +0000
Received: from wl04.sys.cs.tuat.ac.jp (pisces.sys.cs.tuat.ac.jp [165.93.162.82])
	by cat.os-omicron.org (Postfix) with SMTP id EBDECA4E7
	for <linux-mips@linux-mips.org>; Tue,  4 Mar 2003 17:16:16 +0900 (JST)
Date: Tue, 4 Mar 2003 17:13:40 +0900
From: TAKANO Ryousei <takano@os-omicron.org>
To: linux-mips@linux-mips.org
Subject: Re: JVM under Linux on MIPS
Message-Id: <20030304171340.1a9af44d.takano@os-omicron.org>
In-Reply-To: <20030304011459.457.qmail@web13302.mail.yahoo.com>
References: <20030302121820.A30790@linux-mips.org>
	<20030304011459.457.qmail@web13302.mail.yahoo.com>
Organization: OS/omicron Project
X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i386-vine-linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <takano@os-omicron.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1614
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: takano@os-omicron.org
Precedence: bulk
X-list: linux-mips
Content-Length: 516
Lines: 15

Hi,

On Mon, 3 Mar 2003 17:14:59 -0800 (PST)
Rajesh Palani <rpalani2@yahoo.com> wrote:
>    Has anyone had any success running any open source JVMs (other than Cobalt machines running Transvirtual's Kaffe) under Linux/MIPS.
>

I have succeeded in running Kaffe 1.0.7 with --with-engine=jit3
on a TANBAC TB0193 board (VR4181/66MHz).
However, it was very poor performance. A hello world execution,
for example, takes about 30 seconds.
I think that a JIT initialization has taken a lot of time.

Thanks,
TAKANO Ryousei

From kevink@mips.com Tue Mar  4 08:53:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 08:53:19 +0000 (GMT)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:60078 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225251AbTCDIxS>;
	Tue, 4 Mar 2003 08:53:18 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h248r6Ue016114;
	Tue, 4 Mar 2003 00:53:06 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id AAA05620;
	Tue, 4 Mar 2003 00:53:07 -0800 (PST)
Message-ID: <007701c2e22c$66e30e70$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "TAKANO Ryousei" <takano@os-omicron.org>,
	<linux-mips@linux-mips.org>
References: <20030302121820.A30790@linux-mips.org><20030304011459.457.qmail@web13302.mail.yahoo.com> <20030304171340.1a9af44d.takano@os-omicron.org>
Subject: Re: JVM under Linux on MIPS
Date: Tue, 4 Mar 2003 09:59:34 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1615
X-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
Content-Length: 1939
Lines: 40

> On Mon, 3 Mar 2003 17:14:59 -0800 (PST)
> Rajesh Palani <rpalani2@yahoo.com> wrote:
> >    Has anyone had any success running any open source JVMs (other than Cobalt machines running Transvirtual's Kaffe) under
Linux/MIPS.
> >
>
> I have succeeded in running Kaffe 1.0.7 with --with-engine=jit3
> on a TANBAC TB0193 board (VR4181/66MHz).
> However, it was very poor performance. A hello world execution,
> for example, takes about 30 seconds.
> I think that a JIT initialization has taken a lot of time.

I'm very pleased to hear that you got it running on a Vr41xx,
but I'm curious about the JIT behavior you saw.  I can believe
that it could run "hello world", but does it really pass all the
internal regression tests ("make check")?  Are you running
a "normal" MIPS/Linux distribution which assumes a
hardware FPU and does kernel emulation where necessary,
or are you using a purely soft-float environment?  I ask
this because most of the problems I have with the JIT are
in areas where mixed integer/floating arguments are being
passed, and those might not be an issue with soft-float.

As for the performance you observed, how much memory
did you have on the board, and what kind of secondary storage
(disk?) hardware was used?  66MHz isn't fast, but the combined
compile-and-run time for Caffeinemark for the patched
kaffe 1.0.7 on a MIPS 5Kc core at 160MHz was in fact
pretty good, better than 3 Embedded Caffeienmarks
per megahertz, which isn't as fast as commercial dynmic
compilers, but which is still several times faster than most
commercial interpretive JVMs.  Running fully interpretive,
kaffe's performance is mediocre but reasonable, I certainly
wasn't seeing delays of 10 seconds to run "hello world",
which is roughly what one would expect scaling your reported
run time by the frequency.  I really think that you are far more
likely to have been I/O bound, either from paging or from file I/O.

            Kevin K.


From takano@os-omicron.org Tue Mar  4 10:09:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 10:09:47 +0000 (GMT)
Received: from [IPv6:::ffff:133.36.48.43] ([IPv6:::ffff:133.36.48.43]:2217
	"EHLO cat.os-omicron.org") by linux-mips.org with ESMTP
	id <S8225251AbTCDKJq>; Tue, 4 Mar 2003 10:09:46 +0000
Received: from wl04.sys.cs.tuat.ac.jp (pisces.sys.cs.tuat.ac.jp [165.93.162.82])
	by cat.os-omicron.org (Postfix) with SMTP id 934AFA4E7
	for <linux-mips@linux-mips.org>; Tue,  4 Mar 2003 19:11:39 +0900 (JST)
Date: Tue, 4 Mar 2003 19:09:02 +0900
From: TAKANO Ryousei <takano@os-omicron.org>
To: linux-mips@linux-mips.org
Subject: Re: JVM under Linux on MIPS
Message-Id: <20030304190902.68ffd5bb.takano@os-omicron.org>
In-Reply-To: <007701c2e22c$66e30e70$10eca8c0@grendel>
References: <20030302121820.A30790@linux-mips.org>
	<20030304011459.457.qmail@web13302.mail.yahoo.com>
	<20030304171340.1a9af44d.takano@os-omicron.org>
	<007701c2e22c$66e30e70$10eca8c0@grendel>
Organization: OS/omicron Project
X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i386-vine-linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <takano@os-omicron.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1616
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: takano@os-omicron.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1877
Lines: 41

Hi Kevin,

> I'm very pleased to hear that you got it running on a Vr41xx,
> but I'm curious about the JIT behavior you saw.  I can believe
> that it could run "hello world", but does it really pass all the
> internal regression tests ("make check")?  Are you running
> a "normal" MIPS/Linux distribution which assumes a
> hardware FPU and does kernel emulation where necessary,
> or are you using a purely soft-float environment?  I ask
> this because most of the problems I have with the JIT are
> in areas where mixed integer/floating arguments are being
> passed, and those might not be an issue with soft-float.
> 
I have cross-compiled Kaffe, so it did not pass "make check".
I tried it under a Linux-VR kernel(kernel-2.4.0-test9) which is
enabled with a kernel FPU emulation.
I have not tried under a Linux/MIPS kernel.

> As for the performance you observed, how much memory
> did you have on the board, and what kind of secondary storage
> (disk?) hardware was used?  66MHz isn't fast, but the combined
> compile-and-run time for Caffeinemark for the patched
> kaffe 1.0.7 on a MIPS 5Kc core at 160MHz was in fact
> pretty good, better than 3 Embedded Caffeienmarks
> per megahertz, which isn't as fast as commercial dynmic
> compilers, but which is still several times faster than most
> commercial interpretive JVMs.  Running fully interpretive,
> kaffe's performance is mediocre but reasonable, I certainly
> wasn't seeing delays of 10 seconds to run "hello world",
> which is roughly what one would expect scaling your reported
> run time by the frequency.  I really think that you are far more
> likely to have been I/O bound, either from paging or from file I/O.
> 
TANBAC TB0193 has 16MB SDRAM, and it is using Compact Flash
as a secondary storage.

I try to make jar files compact (strips unused packages) 
for a faster initialization.

Thanks,
TAKANO Ryousei

From ralf@linux-mips.net Tue Mar  4 12:16:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 12:16:35 +0000 (GMT)
Received: from p508B7DCA.dip.t-dialin.net ([IPv6:::ffff:80.139.125.202]:37811
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225261AbTCDMQe>; Tue, 4 Mar 2003 12:16:34 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h24CGVS08332
	for linux-mips@linux-mips.org; Tue, 4 Mar 2003 13:16:31 +0100
Resent-Message-Id: <200303041216.h24CGVS08332@dea.linux-mips.net>
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h24C7ml08053;
	Tue, 4 Mar 2003 13:07:48 +0100
Date: Tue, 4 Mar 2003 13:07:48 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [patch] simulate_ll and simulate_sc(resend)
Message-ID: <20030304130748.B18143@linux-mips.org>
References: <20030303192137.34d21352.yoichi_yuasa@montavista.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030303192137.34d21352.yoichi_yuasa@montavista.co.jp>; from yoichi_yuasa@montavista.co.jp on Mon, Mar 03, 2003 at 07:21:37PM +0900
Resent-From: ralf@linux-mips.org
Resent-Date: Tue, 4 Mar 2003 13:16:31 +0100
Resent-To: linux-mips@linux-mips.org
Return-Path: <ralf@linux-mips.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: 1617
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 276
Lines: 12

On Mon, Mar 03, 2003 at 07:21:37PM +0900, Yoichi Yuasa wrote:

>  sig:
> +	compute_return_epc(regs);
>  	send_sig(signal, current, 1);

In the error case you can't advance the epc ..

It's an old bug already but the signal should be sent with force_sig,
not send_sig.

  Ralf

From ZhouY.external@infineon.com Tue Mar  4 12:43:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 12:43:32 +0000 (GMT)
Received: from smtp1.infineon.com ([IPv6:::ffff:194.175.117.76]:8076 "EHLO
	smtp1.infineon.com") by linux-mips.org with ESMTP
	id <S8225261AbTCDMnb>; Tue, 4 Mar 2003 12:43:31 +0000
Received: from mucse011.eu.infineon.com (mucse011.ifx-mail1.com [172.29.27.228])
	by smtp1.infineon.com (8.12.2/8.12.2) with ESMTP id h24CYuKq002220
	for <linux-mips@linux-mips.org>; Tue, 4 Mar 2003 13:34:56 +0100 (MET)
Received: by mucse011.eu.infineon.com with Internet Mail Service (5.5.2653.19)
	id <G2XXNXDF>; Tue, 4 Mar 2003 13:43:23 +0100
Message-ID: <3A5A80BF651115469CA99C8928706CB603D7B308@mucse004.eu.infineon.com>
From: ZhouY.external@infineon.com
To: linux-mips@linux-mips.org
Subject: MIPS Linux NFS installation
Date: Tue, 4 Mar 2003 13:43:21 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <ZhouY.external@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: 1618
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ZhouY.external@infineon.com
Precedence: bulk
X-list: linux-mips
Content-Length: 772
Lines: 28

Hi everyone,
  I downloaded the RedHat 7.3 installation tar ball  from MIPS ftp server
and tried to install it from NFS server to a Malta board with an IDE hard
disk, but the kernel executed to the following place, it stopped.

YAMON> go

LINUX started...
..................................................  
Welcome to the MIPS installation of RedHat RPMS.

Install method (CD-ROM, NFS) [CD-ROM] NFS

IP-address of target system: [192.168.201.68] 192.168.149.116

IP-address of NFS server: [192.168.201.198] 192.168.149.5
Specify full path to RedHat-directory: [/export/RedHat]
/sbin/init: ./install.script: No such file or directory Kernel panic:
Attempted to kill init!



  Do you know the reason of this problem? 
  Thanks in advance!

  Best regards,

  Yidan Zhou 

From jsun@mvista.com Tue Mar  4 18:06:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 18:06:50 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:29180 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225196AbTCDSGt>;
	Tue, 4 Mar 2003 18:06:49 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h24I6i425984;
	Tue, 4 Mar 2003 10:06:44 -0800
Date: Tue, 4 Mar 2003 10:06:44 -0800
From: Jun Sun <jsun@mvista.com>
To: TAKANO Ryousei <takano@os-omicron.org>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: JVM under Linux on MIPS
Message-ID: <20030304100644.B25862@mvista.com>
References: <20030302121820.A30790@linux-mips.org> <20030304011459.457.qmail@web13302.mail.yahoo.com> <20030304171340.1a9af44d.takano@os-omicron.org> <007701c2e22c$66e30e70$10eca8c0@grendel> <20030304190902.68ffd5bb.takano@os-omicron.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030304190902.68ffd5bb.takano@os-omicron.org>; from takano@os-omicron.org on Tue, Mar 04, 2003 at 07:09:02PM +0900
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: 1619
X-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
Content-Length: 1059
Lines: 24

On Tue, Mar 04, 2003 at 07:09:02PM +0900, TAKANO Ryousei wrote:
> Hi Kevin,
> 
> > I'm very pleased to hear that you got it running on a Vr41xx,
> > but I'm curious about the JIT behavior you saw.  I can believe
> > that it could run "hello world", but does it really pass all the
> > internal regression tests ("make check")?  Are you running
> > a "normal" MIPS/Linux distribution which assumes a
> > hardware FPU and does kernel emulation where necessary,
> > or are you using a purely soft-float environment?  I ask
> > this because most of the problems I have with the JIT are
> > in areas where mixed integer/floating arguments are being
> > passed, and those might not be an issue with soft-float.
> > 
> I have cross-compiled Kaffe, so it did not pass "make check".
> I tried it under a Linux-VR kernel(kernel-2.4.0-test9) which is
> enabled with a kernel FPU emulation.
> I have not tried under a Linux/MIPS kernel.
>

Java VM typically uses massive threading.  Emulating ll/sc instructions
for vr4181a might one of the biggest causes of delay.

Jun

From ZhouY.external@infineon.com Tue Mar  4 18:46:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 18:46:21 +0000 (GMT)
Received: from smtp2.infineon.com ([IPv6:::ffff:194.175.117.77]:64211 "EHLO
	smtp2.infineon.com") by linux-mips.org with ESMTP
	id <S8225196AbTCDSqU>; Tue, 4 Mar 2003 18:46:20 +0000
Received: from mucse011.eu.infineon.com (mucse011.ifx-mail1.com [172.29.27.228])
	by smtp2.infineon.com (8.12.2/8.12.2) with ESMTP id h24Ihx5N017861
	for <linux-mips@linux-mips.org>; Tue, 4 Mar 2003 19:43:59 +0100 (MET)
Received: by mucse011.eu.infineon.com with Internet Mail Service (5.5.2653.19)
	id <G2XX33PS>; Tue, 4 Mar 2003 19:46:12 +0100
Message-ID: <3A5A80BF651115469CA99C8928706CB603D7B30A@mucse004.eu.infineon.com>
From: ZhouY.external@infineon.com
To: linux-mips@linux-mips.org
Subject: How to make a C program running for MIPS Linux?
Date: Tue, 4 Mar 2003 19:46:12 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <ZhouY.external@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: 1620
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ZhouY.external@infineon.com
Precedence: bulk
X-list: linux-mips
Content-Length: 357
Lines: 11

Hi experts,
  I already have a SDE cross compiler for MIPS and MIPS embedded Linux
running. How can I cross-compile a C program running on the MIPS Linux box?
what kind of libraries should I link?
   My Linux kernel is version 2.4.18-MIPS-01.01 and the version of the
cross-compiler version is gcc version 2.96-sdemips-030211.
  
  Best regards,

  Yidan 


From ralf@linux-mips.net Tue Mar  4 20:36:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 20:36:13 +0000 (GMT)
Received: from p508B7DCA.dip.t-dialin.net ([IPv6:::ffff:80.139.125.202]:11195
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225211AbTCDUgM>; Tue, 4 Mar 2003 20:36:12 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h24Ka5U17927;
	Tue, 4 Mar 2003 21:36:05 +0100
Date: Tue, 4 Mar 2003 21:36:05 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [patch] simulate_ll and simulate_sc(resend)
Message-ID: <20030304213605.A17855@linux-mips.org>
References: <20030303192137.34d21352.yoichi_yuasa@montavista.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030303192137.34d21352.yoichi_yuasa@montavista.co.jp>; from yoichi_yuasa@montavista.co.jp on Mon, Mar 03, 2003 at 07:21:37PM +0900
Return-Path: <ralf@linux-mips.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: 1621
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1625
Lines: 67

On Mon, Mar 03, 2003 at 07:21:37PM +0900, Yoichi Yuasa wrote:

> I found a bug in simulate_ll and simulate_sc.
> The board that uses ll/sc emulation is not started.
> 
> When send_sig in these, in order not to operate the value of EPC correctly,
> simulate_* happens continuously.
> 
> The previous patches were not perfect, I changed more.
> Please apply these patches to CVS tree.

As previously mentioned there were some problems with your fix, so I
wrote an alternative fix which is attached below.  It's untested because
I don't have any ll/sc-less test platform.

  Ralf

Index: arch/mips/kernel/traps.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/traps.c,v
retrieving revision 1.99.2.41
diff -u -r1.99.2.41 traps.c
--- arch/mips/kernel/traps.c	10 Feb 2003 22:50:48 -0000	1.99.2.41
+++ arch/mips/kernel/traps.c	4 Mar 2003 20:32:10 -0000
@@ -134,13 +134,14 @@
 		ll_bit = 0;
 	}
 	ll_task = current;
+
 	regs->regs[(opcode & RT) >> 16] = value;
 
 	compute_return_epc(regs);
 	return;
 
 sig:
-	send_sig(signal, current, 1);
+	force_sig(signal, current);
 }
 
 static inline void simulate_sc(struct pt_regs *regs, unsigned int opcode)
@@ -172,19 +173,21 @@
 	}
 	if (ll_bit == 0 || ll_task != current) {
 		regs->regs[reg] = 0;
-		goto sig;
+		return;
 	}
 
-	if (put_user(regs->regs[reg], vaddr))
+	if (put_user(regs->regs[reg], vaddr)) {
 		signal = SIGSEGV;
-	else
-		regs->regs[reg] = 1;
+		goto sig;
+	}
+
+	regs->regs[reg] = 1;
 
 	compute_return_epc(regs);
 	return;
 
 sig:
-	send_sig(signal, current, 1);
+	force_sig(signal, current);
 }
 
 /*

From yogesh.chaudhary@amd.com Tue Mar  4 21:16:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 21:16:34 +0000 (GMT)
Received: from amdext2.amd.com ([IPv6:::ffff:163.181.251.1]:27861 "EHLO
	amdext2.amd.com") by linux-mips.org with ESMTP id <S8225196AbTCDVQd>;
	Tue, 4 Mar 2003 21:16:33 +0000
Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22])
	by amdext2.amd.com (8.9.3/8.9.3/AMD) with ESMTP id PAA04541
	for <linux-mips@linux-mips.org>; Tue, 4 Mar 2003 15:16:22 -0600 (CST)
Received: from 163.181.250.1SAUSGW02.amd.com with ESMTP (AMD SMTP Relay
 (MMS v5.0)); Tue, 04 Mar 2003 15:16:16 -0600
X-Server-Uuid: BB5E7757-34FD-4146-B9CC-0950D472AE87
Received: from pcsmail.amd.com (pcsmail.amd.com [163.181.41.222]) by
 amdint2.amd.com (8.9.3/8.9.3/AMD) with ESMTP id PAA23911 for
 <linux-mips@linux-mips.org>; Tue, 4 Mar 2003 15:16:14 -0600 (CST)
Received: from ardgw29.amd.com (ardgw29.amd.com [163.181.41.29]) by
 pcsmail.amd.com (8.11.6/8.11.6) with ESMTP id h24LGEa21737; Tue, 4 Mar
 2003 15:16:14 -0600
Date: Tue, 4 Mar 2003 15:08:27 -0600 (CST)
From: "Yogesh Chaudhary" <yogesh.chaudhary@amd.com>
X-X-Sender: yogesh@ardgw29.amd.com
To: linux-mips@linux-mips.org
cc: "Yogesh Chaudhary" <yogesh.chaudhary@amd.com>
Subject: convert into MIPS
Message-ID: <Pine.GSO.4.51.0303041505390.3806@ardgw29.amd.com>
MIME-Version: 1.0
X-WSS-ID: 127BC82A2120175-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <yogesh.chaudhary@amd.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1622
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yogesh.chaudhary@amd.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1071
Lines: 38


Hi All,

can anyone help me converting this little piece of x86 code to MIPS.

here it is...

#define fixfixmul(a,b) \
   ( { long __result = (a), __arg = (b); \
       asm("imul %2;" \
           "shrd %3,%2,%0;" \
          : "=a" (__result) \
          : "0"  (__result), "d"  (__arg) , "I" (FX_PRECIS) ); \
       assert( \
             ((fix2float(__result) - fix2float(a)*fix2float(b) > -0.2) \
               && \
              (fix2float(__result) - fix2float(a)*fix2float(b) <  0.2)) \
              || \
              (printf("fixfixmul %f %f = %f, should be %f\n", \
                      fix2float(a),fix2float(b),fix2float(__result), \
                      fix2float(a)*fix2float(b)) \
              && 0) \
             ); \
       __result; \
      } \
   )


thanks, Yogesh


--------------------------------------------------------------------------
Yogesh Chaudhary
Advanced Micro Devices,Inc ( PCS )
9500 Arboretum Blvd., Suite 400                       Phone:  512.602.5422
Austin, TX 78759                                       Fax: 512.602.5051



From kwalker@broadcom.com Tue Mar  4 21:50:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 21:50:59 +0000 (GMT)
Received: from mms3.broadcom.com ([IPv6:::ffff:63.70.210.38]:43012 "EHLO
	mms3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225198AbTCDVu6>; Tue, 4 Mar 2003 21:50:58 +0000
Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.0)); Tue, 04 Mar 2003 13:50:53 -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 NAA04019; Tue, 4 Mar 2003 13:50:37 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h24LolER016849; Tue, 4 Mar 2003 13:50:47 -0800 (PST)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id NAA06377; Tue, 4
 Mar 2003 13:50:47 -0800
Message-ID: <3E651FB7.A38AFD3B@broadcom.com>
Date: Tue, 04 Mar 2003 13:50:47 -0800
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
cc: "Ralf Baechle" <ralf@linux-mips.org>
Subject: [PATCH] kernelsp on 64-bit kernel
X-WSS-ID: 127BC0372364117-01-01
Content-Type: multipart/mixed;
 boundary=------------8D168CE492746438F5FDD556
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: 1623
X-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
Content-Length: 5038
Lines: 170

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


Is anyone else interested in having the 64-bit kernel *not* use the CP0
watchpoint registers for storing the kernel stack pointer for the CPU's
current process?

I have a couple problems with this:
 - there are read-only bits in watchhi (according to the MIPS64 spec) so
hoping to save and restore all high 32 bits (as currently coded) seems
unjustified.
 - somebody might want to actually *use* watchpoints (a JTAG debugger,
in my case)

I put together something that works, based on the 32-bit kernel which
has an array of kernelsp's instead of keeping it in CP0.  Some notes
about this solution are:
 - processor id isn't as easy to get in the 64-bit kernel since
CP0_CONTEXT has (&pgd_current[cpu] << 23) instead of (cpu << 23) so in
this patch I use ((&pgd_current[cpu] - &pgd_current[0]) + &kernelsp)
which seems expensive.
 - smp_bootstrap tries to stash the kernelsp away, but won't work
because CP0_CONTEXT on secondary CPUs isn't set up yet.  However, I
don't think this really needs to happen at this time; the first context
switch on the CPU will save the kernelsp without any damage being done
(I think).  So in the patch, I axed this use of set_saved_sp.
 - set_saved_sp implemented using the pointer math needs two temporaries
instead of one (or am I missing a trick?)

2.4 kernel patch included.

Kip
--------------8D168CE492746438F5FDD556
Content-Type: text/plain;
 charset=us-ascii;
 name=kernelsp.diff
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename=kernelsp.diff

Index: include/asm-mips64/stackframe.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/stackframe.h,v
retrieving revision 1.7.2.4
diff -u -r1.7.2.4 stackframe.h
--- include/asm-mips64/stackframe.h	28 Jan 2003 14:31:33 -0000	1.7.2.4
+++ include/asm-mips64/stackframe.h	4 Mar 2003 21:49:47 -0000
@@ -11,6 +11,7 @@
 #define _ASM_STACKFRAME_H
 
 #include <linux/config.h>
+#include <linux/threads.h>
 
 #include <asm/asm.h>
 #include <asm/offset.h>
@@ -76,33 +77,23 @@
 		.endm
 
 #ifdef CONFIG_SMP
-		.macro	get_saved_sp	/* R10000 variation */
-#ifdef CONFIG_CPU_SB1
-		dmfc0	k1, CP0_WATCHLO
-#else
-		mfc0	k0, CP0_WATCHLO
-		mfc0	k1, CP0_WATCHHI
-		dsll32	k0, k0, 0	/* Get rid of sign extension */
-		dsrl32	k0, k0, 0	/* Get rid of sign extension */
-		dsll32	k1, k1, 0
-		or	k1, k1, k0
-		li	k0, K0BASE
-		or	k1, k1, k0
-#endif
-		.endm
-
-		.macro	set_saved_sp	stackp temp
-#ifdef CONFIG_CPU_SB1
-		dmtc0	\stackp, CP0_WATCHLO
-#else
-		mtc0	\stackp, CP0_WATCHLO
-		dsrl32	\temp, \stackp, 0
-		mtc0	\temp, CP0_WATCHHI
-#endif
+		.macro	get_saved_sp	/* SMP variation */
+		dmfc0	k1, CP0_CONTEXT
+		dsra	k1, 23
+		lui	k0, %hi(pgd_current)
+		daddiu	k0, %lo(pgd_current)
+		dsubu	k1, k0
+		lui	k0, %hi(kernelsp)
+		daddu	k1, k0
+		ld	k1, %lo(kernelsp)(k1)
 		.endm
 
-		.macro	declare_saved_sp
-		# empty, stackpointer stored in a register
+		.macro	set_saved_sp	stackp temp temp2
+		lw	\temp, TASK_PROCESSOR(gp)
+		dsll	\temp, 3
+		lui	\temp2, %hi(kernelsp)
+		daddu	\temp, \temp2
+		sd	\stackp, %lo(kernelsp)(\temp)
 		.endm
 #else
 		.macro	get_saved_sp	/* Uniprocessor variation */
@@ -110,14 +101,13 @@
 		ld	k1, %lo(kernelsp)(k1)
 		.endm
 
-		.macro	set_saved_sp	stackp temp
+		.macro	set_saved_sp	stackp temp temp2
 		sd	\stackp, kernelsp
 		.endm
-
+#endif
 		.macro	declare_saved_sp
-		.comm	kernelsp, 8, 8			# current stackpointer
+		.comm	kernelsp, NR_CPUS * 8, 8
 		.endm
-#endif
 
 		.macro	SAVE_SOME
 		.set	push
Index: arch/mips64/kernel/head.S
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/head.S,v
retrieving revision 1.34.2.10
diff -u -r1.34.2.10 head.S
--- arch/mips64/kernel/head.S	29 Nov 2002 04:02:31 -0000	1.34.2.10
+++ arch/mips64/kernel/head.S	4 Mar 2003 21:49:47 -0000
@@ -107,7 +107,7 @@
 
 	PTR_LA	$28, init_task_union		# init current pointer
 	daddiu	sp, $28, KERNEL_STACK_SIZE-32
-	set_saved_sp	sp, t0
+	set_saved_sp	sp, t0, t1
 
 	/* The firmware/bootloader passes argc/argp/envp
 	 * to us as arguments.  But clear bss first because
@@ -156,8 +156,6 @@
         mfc0	t0, CP0_STATUS
         or	t0, ST0_KX
 	mtc0	t0, CP0_STATUS
-
-	set_saved_sp	sp, t0
 
 	jal	start_secondary			# XXX: IP27: cboot
 
Index: arch/mips64/kernel/r4k_switch.S
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/r4k_switch.S,v
retrieving revision 1.5.2.10
diff -u -r1.5.2.10 r4k_switch.S
--- arch/mips64/kernel/r4k_switch.S	4 Nov 2002 19:39:56 -0000	1.5.2.10
+++ arch/mips64/kernel/r4k_switch.S	4 Mar 2003 21:49:47 -0000
@@ -87,7 +87,7 @@
 	cpu_restore_nonscratch $28
 
 	daddiu	a1, $28, KERNEL_STACK_SIZE-32
-	set_saved_sp	a1 t0
+	set_saved_sp	a1, t0, t1
 
 	mfc0	t1, CP0_STATUS		/* Do we really need this? */
 	li	a3, 0xff00

--------------8D168CE492746438F5FDD556--


From kevink@mips.com Tue Mar  4 23:02:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 23:02:05 +0000 (GMT)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:30677 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225203AbTCDXCE>;
	Tue, 4 Mar 2003 23:02:04 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h24N1hUe020455;
	Tue, 4 Mar 2003 15:01:51 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id PAA24363;
	Tue, 4 Mar 2003 15:01:41 -0800 (PST)
Message-ID: <01e401c2e2a2$f1866010$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Kip Walker" <kwalker@broadcom.com>, <linux-mips@linux-mips.org>
Cc: "Ralf Baechle" <ralf@linux-mips.org>
References: <3E651FB7.A38AFD3B@broadcom.com>
Subject: Re: [PATCH] kernelsp on 64-bit kernel
Date: Wed, 5 Mar 2003 00:08:03 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1624
X-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
Content-Length: 910
Lines: 21

> Is anyone else interested in having the 64-bit kernel *not* use the CP0
> watchpoint registers for storing the kernel stack pointer for the CPU's
> current process?
> 
> I have a couple problems with this:
>  - there are read-only bits in watchhi (according to the MIPS64 spec) so
> hoping to save and restore all high 32 bits (as currently coded) seems
> unjustified.
>  - somebody might want to actually *use* watchpoints (a JTAG debugger,
> in my case)

For whatever it's worth, I've always maintained that stealing the Watchpoint
registers in this way was a pretty questionable hack to be avoided.  Watchpoint
registers are *optional* in MIPS64 and may not even exist.  And yes, someone
might want to use them for their intended purpose some day.  However, please
note that the EJTAG breakpoint registers are completely orthogonal to the
watchpoint registers.

            Regards,

            Kevin K.

From jsun@mvista.com Tue Mar  4 23:14:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 23:14:28 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:63225 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225203AbTCDXO1>;
	Tue, 4 Mar 2003 23:14:27 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h24NEOZ19096;
	Tue, 4 Mar 2003 15:14:24 -0800
Date: Tue, 4 Mar 2003 15:14:24 -0800
From: Jun Sun <jsun@mvista.com>
To: Kip Walker <kwalker@broadcom.com>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
	jsun@mvista.com
Subject: Re: [PATCH] kernelsp on 64-bit kernel
Message-ID: <20030304151424.B18978@mvista.com>
References: <3E651FB7.A38AFD3B@broadcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3E651FB7.A38AFD3B@broadcom.com>; from kwalker@broadcom.com on Tue, Mar 04, 2003 at 01:50:47PM -0800
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: 1625
X-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
Content-Length: 1054
Lines: 28

On Tue, Mar 04, 2003 at 01:50:47PM -0800, Kip Walker wrote:
> 
> Is anyone else interested in having the 64-bit kernel *not* use the CP0
> watchpoint registers for storing the kernel stack pointer for the CPU's
> current process?
> 
> I have a couple problems with this:
>  - there are read-only bits in watchhi (according to the MIPS64 spec) so
> hoping to save and restore all high 32 bits (as currently coded) seems
> unjustified.
>  - somebody might want to actually *use* watchpoints (a JTAG debugger,
> in my case)
>

I agree.  This is a good thing to do.
 
> I put together something that works, based on the 32-bit kernel which
> has an array of kernelsp's instead of keeping it in CP0.  Some notes
> about this solution are:
>  - processor id isn't as easy to get in the 64-bit kernel since
> CP0_CONTEXT has (&pgd_current[cpu] << 23) instead of (cpu << 23) so in
> this patch I use ((&pgd_current[cpu] - &pgd_current[0]) + &kernelsp)
> which seems expensive.

I can't think of any better way than this.  Anybody knows how IRIX
does this? 

Jun

From kwalker@broadcom.com Tue Mar  4 23:16:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Mar 2003 23:16:55 +0000 (GMT)
Received: from mms1.broadcom.com ([IPv6:::ffff:63.70.210.58]:21775 "EHLO
	mms1.broadcom.com") by linux-mips.org with ESMTP
	id <S8225203AbTCDXQy>; Tue, 4 Mar 2003 23:16:54 +0000
Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.0)); Tue, 04 Mar 2003 15:16:30 -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 PAA21401; Tue, 4 Mar 2003 15:16:35 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h24NGiER018738; Tue, 4 Mar 2003 15:16:44 -0800 (PST)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id PAA08482; Tue, 4
 Mar 2003 15:16:45 -0800
Message-ID: <3E6533DD.B72D6F10@broadcom.com>
Date: Tue, 04 Mar 2003 15:16:45 -0800
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kevin D. Kissell" <kevink@mips.com>
cc: linux-mips@linux-mips.org, "Ralf Baechle" <ralf@linux-mips.org>
Subject: Re: [PATCH] kernelsp on 64-bit kernel
References: <3E651FB7.A38AFD3B@broadcom.com>
 <01e401c2e2a2$f1866010$10eca8c0@grendel>
X-WSS-ID: 127BEC44964128-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: 1626
X-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
Content-Length: 755
Lines: 15

> For whatever it's worth, I've always maintained that stealing the Watchpoint
> registers in this way was a pretty questionable hack to be avoided.  Watchpoint
> registers are *optional* in MIPS64 and may not even exist.  And yes, someone
> might want to use them for their intended purpose some day.  However, please
> note that the EJTAG breakpoint registers are completely orthogonal to the
> watchpoint registers.

That is true, but in SB1, watchpoint registers can be used by the JTAG
debugger, and I do it all the time.  It doesn't have the EJTAG
breakpoint registers, but rather overloads (I know, I know) use of the
watchpoint registers and has a mode bit for causing a debug exception
instead of a general exception when they are tripped.

Kip


From jsun@mvista.com Wed Mar  5 00:10:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Mar 2003 00:10:57 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:6387 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225197AbTCEAK5>;
	Wed, 5 Mar 2003 00:10:57 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h250AtB19303;
	Tue, 4 Mar 2003 16:10:55 -0800
Date: Tue, 4 Mar 2003 16:10:55 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com, rml@mvista.com
Subject: preemptible kernel support for mips32
Message-ID: <20030304161055.C18978@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: 1627
X-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
Content-Length: 361
Lines: 14


You can find the fresh baked MIPS preemptible kernel patch at 

http://linux.junsun.net/patches/oss.sgi.com/experimental/

You will need two patches there to make it work

030304-a.rml-preempt-2.4.21.no-arch.patch
030304-b.preempt-mips.patch

Robert, please incorporate the latest MIPS preemption support from the
second patch in your next patch release.

Jun

From yogishpatila@rediffmail.com Wed Mar  5 07:39:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Mar 2003 07:39:05 +0000 (GMT)
Received: from webmail32.rediffmail.com ([IPv6:::ffff:203.199.83.32]:29606
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225197AbTCEHjE>; Wed, 5 Mar 2003 07:39:04 +0000
Received: (qmail 10029 invoked by uid 510); 5 Mar 2003 07:38:55 -0000
Date: 5 Mar 2003 07:38:55 -0000
Message-ID: <20030305073855.10028.qmail@webmail32.rediffmail.com>
Received: from unknown (203.196.179.98) by rediffmail.com via HTTP; 05 mar 2003 07:38:55 -0000
MIME-Version: 1.0
From: "Yogish  Patil" <yogishpatila@rediffmail.com>
Reply-To: "Yogish  Patil" <yogishpatila@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: glibc-2.2.1 problems for mips-linux
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <yogishpatila@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1628
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yogishpatila@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 287
Lines: 13

Hello,

Can anybody point me to get pre-compiled glibc for mips-linux?
I am not specific to any version. At the same time I was trying to 
build
glibc-2.2.1 but facing problems....has somebody successfully build 
?

I would really appreciate if someone guide me.

with regards,
-yogish


From ipv6_san@rediffmail.com Wed Mar  5 09:44:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Mar 2003 09:44:37 +0000 (GMT)
Received: from webmail17.rediffmail.com ([IPv6:::ffff:203.199.83.27]:19592
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225197AbTCEJog>; Wed, 5 Mar 2003 09:44:36 +0000
Received: (qmail 6798 invoked by uid 510); 5 Mar 2003 09:42:46 -0000
Date: 5 Mar 2003 09:42:46 -0000
Message-ID: <20030305094246.6797.qmail@webmail17.rediffmail.com>
Received: from unknown (203.126.245.198) by rediffmail.com via HTTP; 05 mar 2003 09:42:46 -0000
MIME-Version: 1.0
From: "Santosh " <ipv6_san@rediffmail.com>
Reply-To: "Santosh " <ipv6_san@rediffmail.com>
To: "Yogish  Patil" <yogishpatila@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: glibc-2.2.1 problems for mips-linux
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <ipv6_san@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1629
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ipv6_san@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 415
Lines: 22


Try this link ftp://ftp.linux-mips.org/pub/linux/mips/glibc/

-San

On Wed, 05 Mar 2003 Yogish  Patil wrote :
>Hello,
>
>Can anybody point me to get pre-compiled glibc for mips-linux?
>I am not specific to any version. At the same time I was trying 
>to build
>glibc-2.2.1 but facing problems....has somebody successfully 
>build ?
>
>I would really appreciate if someone guide me.
>
>with regards,
>-yogish
>
>



From ralf@linux-mips.net Wed Mar  5 15:41:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Mar 2003 15:41:11 +0000 (GMT)
Received: from p508B7A20.dip.t-dialin.net ([IPv6:::ffff:80.139.122.32]:24013
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225202AbTCEPlK>; Wed, 5 Mar 2003 15:41:10 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h25Feae12170;
	Wed, 5 Mar 2003 16:40:36 +0100
Date: Wed, 5 Mar 2003 16:40:36 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Santosh <ipv6_san@rediffmail.com>
Cc: Yogish Patil <yogishpatila@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: glibc-2.2.1 problems for mips-linux
Message-ID: <20030305164036.A10407@linux-mips.org>
References: <20030305094246.6797.qmail@webmail17.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030305094246.6797.qmail@webmail17.rediffmail.com>; from ipv6_san@rediffmail.com on Wed, Mar 05, 2003 at 09:42:46AM -0000
Return-Path: <ralf@linux-mips.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: 1630
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 393
Lines: 10

On Wed, Mar 05, 2003 at 09:42:46AM -0000, Santosh  wrote:

> Try this link ftp://ftp.linux-mips.org/pub/linux/mips/glibc/

Don't.  That's over two year old stuff and almost implies a guarantee to
make you unhappy.  Recompiling libc requires fairly complex setup in
particular when crosscompiling so the strong recommendation is to use
the binaries of your favorite Linux distribution.

  Ralf

From wd@denx.de Wed Mar  5 19:09:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Mar 2003 19:09:17 +0000 (GMT)
Received: from mailout11.sul.t-online.com ([IPv6:::ffff:194.25.134.85]:14282
	"EHLO mailout11.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225258AbTCETJR>; Wed, 5 Mar 2003 19:09:17 +0000
Received: from fwd03.sul.t-online.de 
	by mailout11.sul.t-online.com with smtp 
	id 18qbEx-0002ep-00; Wed, 05 Mar 2003 16:55:31 +0100
Received: from denx.de (320026445996-0001@[217.235.233.157]) by fmrl03.sul.t-online.com
	with esmtp id 18qbEr-0WxwWmC; Wed, 5 Mar 2003 16:55:25 +0100
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 14670427FF; Wed,  5 Mar 2003 16:55:24 +0100 (MET)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 7F3B8C6E0C; Wed,  5 Mar 2003 10:55:23 -0500 (EST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 1E4DEC5F63; Wed,  5 Mar 2003 16:55:23 +0100 (MET)
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: glibc-2.2.1 problems for mips-linux 
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 "Wed, 05 Mar 2003 16:40:36 +0100."
             <20030305164036.A10407@linux-mips.org> 
Date: Wed, 05 Mar 2003 16:55:18 +0100
Message-Id: <20030305155523.7F3B8C6E0C@atlas.denx.de>
X-Sender: 320026445996-0001@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: 1631
X-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
Content-Length: 814
Lines: 22

In message <20030305164036.A10407@linux-mips.org> you wrote:
> 
> Don't.  That's over two year old stuff and almost implies a guarantee to
> make you unhappy.  Recompiling libc requires fairly complex setup in
> particular when crosscompiling so the strong recommendation is to use
> the binaries of your favorite Linux distribution.

We are in the process of preparing a MIPS version of our free ELDK
(Embedded Linux Development Kit - see http://www.denx.de/re/ELDK.html)

However, I'm running into storage problems on our FTP server.
Anybody interested in mirroring this stuff?


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
Computers are not intelligent.  They only think they are.

From sjhill@realitydiluted.com Thu Mar  6 00:33:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Mar 2003 00:33:17 +0000 (GMT)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:6124
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225206AbTCFAdQ>; Thu, 6 Mar 2003 00:33:16 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 18qjJu-0002Y7-00; Wed, 05 Mar 2003 18:33:10 -0600
Message-ID: <3E66951E.6030300@realitydiluted.com>
Date: Wed, 05 Mar 2003 18:23:58 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9
X-Accept-Language: en
MIME-Version: 1.0
To: Wolfgang Denk <wd@denx.de>
CC: linux-mips@linux-mips.org
Subject: Re: glibc-2.2.1 problems for mips-linux
References: <20030305155523.7F3B8C6E0C@atlas.denx.de>
In-Reply-To: <20030305155523.7F3B8C6E0C@atlas.denx.de>
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: 1632
X-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
Content-Length: 377
Lines: 13

Wolfgang Denk wrote:
> 
> We are in the process of preparing a MIPS version of our free ELDK
> (Embedded Linux Development Kit - see http://www.denx.de/re/ELDK.html)
> 
> However, I'm running into storage problems on our FTP server.
> Anybody interested in mirroring this stuff?
> 
If Ralf doesn't want it on the main 'linux-mips.org' server, I can
mirror it for you.

-Steve


From tingashilo@yahoo.com Thu Mar  6 07:30:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Mar 2003 07:30:26 +0000 (GMT)
Received: from web41509.mail.yahoo.com ([IPv6:::ffff:66.218.93.92]:6548 "HELO
	web41509.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224847AbTCFHaZ>; Thu, 6 Mar 2003 07:30:25 +0000
Message-ID: <20030306073017.65521.qmail@web41509.mail.yahoo.com>
Received: from [81.218.92.190] by web41509.mail.yahoo.com via HTTP; Wed, 05 Mar 2003 23:30:17 PST
Date: Wed, 5 Mar 2003 23:30:17 -0800 (PST)
From: Tinga Shilo <tingashilo@yahoo.com>
Subject: static variables access and gp
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <tingashilo@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: 1633
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tingashilo@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 684
Lines: 23

Hi,
I am implementing a kernel mechanism which is 
very performance oriented. Along my long critical
path,
there is a static variable that needs to be accessed
quite a few times. This variable is a structure which
is approximately 60 bytes big.
In there any way I can "convince" my kernel (compiled
with gcc) to access this variable using gp ?
Is gp usually used for this purpose in mips-linux ?
Can it be ?

A while ago I saw a small discussion here about usage
of gp for static variables, but it didn't provide
any definite answers.
TIA
T


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

From yoichi_yuasa@montavista.co.jp Thu Mar  6 07:53:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Mar 2003 07:53:59 +0000 (GMT)
Received: from sonicwall.montavista.co.jp ([IPv6:::ffff:202.232.97.131]:45651
	"EHLO yuubin.montavista.co.jp") by linux-mips.org with ESMTP
	id <S8224847AbTCFHx6>; Thu, 6 Mar 2003 07:53:58 +0000
Received: from pudding.montavista.co.jp ([10.200.0.40])
	by yuubin.montavista.co.jp (8.12.5/8.12.5) with SMTP id h2682e44027035;
	Thu, 6 Mar 2003 17:02:41 +0900
Date: Thu, 6 Mar 2003 16:53:51 +0900
From: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yoichi_yuasa@montavista.co.jp, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [patch] simulate_ll and simulate_sc(resend)
Message-Id: <20030306165351.35ffbaa7.yoichi_yuasa@montavista.co.jp>
In-Reply-To: <20030304213605.A17855@linux-mips.org>
References: <20030303192137.34d21352.yoichi_yuasa@montavista.co.jp>
	<20030304213605.A17855@linux-mips.org>
Organization: MontaVista Software Japan, Inc.
X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yoichi_yuasa@montavista.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1634
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yoichi_yuasa@montavista.co.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 2538
Lines: 103

Hi Ralf,

On Tue, 4 Mar 2003 21:36:05 +0100
Ralf Baechle <ralf@linux-mips.org> wrote:

> On Mon, Mar 03, 2003 at 07:21:37PM +0900, Yoichi Yuasa wrote:
> 
> > I found a bug in simulate_ll and simulate_sc.
> > The board that uses ll/sc emulation is not started.
> > 
> > When send_sig in these, in order not to operate the value of EPC correctly,
> > simulate_* happens continuously.
> > 
> > The previous patches were not perfect, I changed more.
> > Please apply these patches to CVS tree.
> 
> As previously mentioned there were some problems with your fix, so I
> wrote an alternative fix which is attached below.  It's untested because
> I don't have any ll/sc-less test platform.

I tested ll/sc simulate.
Furthermore, the following patch is also needed.

Thanks,

Yoichi

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c
--- linux.orig/arch/mips/kernel/traps.c Wed Mar  5 12:05:00 2003
+++ linux/arch/mips/kernel/traps.c      Thu Mar  6 16:37:40 2003
@@ -173,6 +173,7 @@
        }
        if (ll_bit == 0 || ll_task != current) {
                regs->regs[reg] = 0;
+               compute_return_epc(regs);
                return;
        }



> 
>   Ralf
> 
> Index: arch/mips/kernel/traps.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/kernel/traps.c,v
> retrieving revision 1.99.2.41
> diff -u -r1.99.2.41 traps.c
> --- arch/mips/kernel/traps.c	10 Feb 2003 22:50:48 -0000	1.99.2.41
> +++ arch/mips/kernel/traps.c	4 Mar 2003 20:32:10 -0000
> @@ -134,13 +134,14 @@
>  		ll_bit = 0;
>  	}
>  	ll_task = current;
> +
>  	regs->regs[(opcode & RT) >> 16] = value;
>  
>  	compute_return_epc(regs);
>  	return;
>  
>  sig:
> -	send_sig(signal, current, 1);
> +	force_sig(signal, current);
>  }
>  
>  static inline void simulate_sc(struct pt_regs *regs, unsigned int opcode)
> @@ -172,19 +173,21 @@
>  	}
>  	if (ll_bit == 0 || ll_task != current) {
>  		regs->regs[reg] = 0;
> -		goto sig;
> +		return;
>  	}
>  
> -	if (put_user(regs->regs[reg], vaddr))
> +	if (put_user(regs->regs[reg], vaddr)) {
>  		signal = SIGSEGV;
> -	else
> -		regs->regs[reg] = 1;
> +		goto sig;
> +	}
> +
> +	regs->regs[reg] = 1;
>  
>  	compute_return_epc(regs);
>  	return;
>  
>  sig:
> -	send_sig(signal, current, 1);
> +	force_sig(signal, current);
>  }
>  
>  /*
> 
> 


-- 
Yoichi Yuasa
Montavista Software Japan, Inc.
e-mail: yoichi_yuasa@montavista.co.jp
http://www.montavista.co.jp
PHONE: 03-5469-8840 FAX: 03-5469-8841

From jackson@realtek.com.tw Thu Mar  6 09:32:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Mar 2003 09:32:26 +0000 (GMT)
Received: from ip-227-82-56-61.rev.dyxnet.com ([IPv6:::ffff:61.56.82.227]:27402
	"EHLO mf2.realtek.com.tw") by linux-mips.org with ESMTP
	id <S8224847AbTCFJcZ>; Thu, 6 Mar 2003 09:32:25 +0000
Received: from msx.realtek.com.tw (unverified [203.69.112.4]) by mf2.realtek.com.tw
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T60d094adc4cb45701f374@mf2.realtek.com.tw> for <linux-mips@linux-mips.org>;
 Thu, 6 Mar 2003 16:31:05 +0800
Received: from jackson ([172.19.31.122])
          by msx.realtek.com.tw (Lotus Domino Release 5.0.8)
          with ESMTP id 2003030616322149:42751 ;
          Thu, 6 Mar 2003 16:32:21 +0800 
Message-ID: <001a01c2e3ba$dd490e90$7405a8c0@realtek.com.tw>
From: "jackson" <jackson@realtek.com.tw>
To: <linux-mips@linux-mips.org>
Subject: gnu tool-chain support for mips16?
Date: Thu, 6 Mar 2003 16:32:02 +0800
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-MIMETrack: Itemize by SMTP Server on msx/Realtek(Release 5.0.8 |June 18, 2001) at 03/06/2003
 04:32:21 PM,
	Serialize by Router on msx/Realtek(Release 5.0.8 |June 18, 2001) at 03/06/2003
 04:32:23 PM,
	Serialize complete at 03/06/2003 04:32:23 PM
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0017_01C2E3FD.EAFC4EB0"
Return-Path: <jackson@realtek.com.tw>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1635
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jackson@realtek.com.tw
Precedence: bulk
X-list: linux-mips
Content-Length: 5579
Lines: 150

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C2E3FD.EAFC4EB0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="big5"



Dear all:

I follow rules on http://www.ltc.com/~brad/mips/mips-cross-toolchain/
to build gnu tool-cahin.=20
It works pefect for me to build linux/glibc/ulibc, and perform excellent =
on my Demo Board.

However, it report some bug messags as following when I compile a test.c =

like:
int test()
{
    return 0;
}

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
mips-linux-gcc -c -mips16 -o test test.c
/tmp/ccjnCwV7.s: Assembler messages:
/tmp/ccjnCwV7.s:14: Internal error!
Assertion failure in macro_build_lui at ../../gas/config/tc-mips.c line =
3107.
Please report this bug.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
my mips-linux-gcc info:
Reading specs from /usr/local/lib/gcc-lib/mips-linux/3.0.3/specs
Configured with: ../configure --target=3Dmips-linux =
--enable-languages=3Dc --disable-shared =
--with-headers=3D/usr/local/include --with-newlib
Thread model: single
gcc version 3.0.3
 /usr/local/lib/gcc-lib/mips-linux/3.0.3/cpp0 -lang-c -v -D__GNUC__=3D3 =
-D__GNUC_MINOR__=3D0 -D__GNUC_PATCHLEVEL__=3D3 -DMIPSEB -D_MIPSEB -Dunix =
-Dmips -D_mips -DR3000 -D_R3000 -Dlinux -D__ELF__ -D__PIC__ -D__pic__ =
-D__MIPSEB__ -D_MIPSEB -D__unix__ -D__mips__ -D__mips__ -D__R3000__ =
-D_R3000 -D__linux__ -D__ELF__ -D__PIC__ -D__pic__ -D__MIPSEB -D__unix =
-D__mips -D__mips -D__R3000 -D__linux -Asystem=3Dposix -Acpu=3Dmips =
-Amachine=3Dmips -D__NO_INLINE__ -D__STDC_HOSTED__=3D1 -D__LANGUAGE_C =
-D_LANGUAGE_C -DLANGUAGE_C -D__SIZE_TYPE__=3Dunsigned int =
-D__PTRDIFF_TYPE__=3Dint -D_MIPS_FPSET=3D32 =
-D_MIPS_ISA=3D_MIPS_ISA_MIPS1 -D_MIPS_SIM=3D_MIPS_SIM_ABI32 =
-D_MIPS_SZINT=3D32 -D_MIPS_SZLONG=3D32 -D_MIPS_SZPTR=3D32 -U__mips =
-D__mips -U__mips64 -
GNU CPP version 3.0.3 (cpplib) (MIPS GNU/Linux with ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc-lib/mips-linux/3.0.3/include
 /usr/local/mips-linux/sys-include
 /usr/local/mips-linux/include
End of search list.


Can you kindly give me some help in this?=20
Thank you very much.
=20

------=_NextPart_000_0017_01C2E3FD.EAFC4EB0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset="big5"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Dear all:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>I follow rules on <A=20
href=3D"http://www.ltc.com/~brad/mips/mips-cross-toolchain/">http://www.l=
tc.com/~brad/mips/mips-cross-toolchain/</A></FONT></DIV>
<DIV><FONT size=3D2>to build gnu tool-cahin. </FONT></DIV>
<DIV><FONT size=3D2>It works pefect for me to build linux/glibc/ulibc, =
and perform=20
excellent on my Demo Board.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>However, it report some bug messags as following =
when I=20
compile a test.c </FONT></DIV>
<DIV><FONT size=3D2>like:</FONT></DIV>
<DIV><FONT size=3D2>int test()</FONT></DIV>
<DIV><FONT size=3D2>{</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; return 0;</FONT></DIV>
<DIV><FONT size=3D2>}</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>=
</DIV>
<DIV><FONT size=3D2>mips-linux-gcc -c -mips16 -o test =
test.c<BR>/tmp/ccjnCwV7.s:=20
Assembler messages:<BR>/tmp/ccjnCwV7.s:14: Internal error!<BR>Assertion =
failure=20
in macro_build_lui at ../../gas/config/tc-mips.c line 3107.<BR>Please =
report=20
this =
bug.<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</=
FONT></DIV>
<DIV><FONT size=3D2>my mips-linux-gcc info:</FONT></DIV>
<DIV><FONT size=3D2>Reading specs from=20
/usr/local/lib/gcc-lib/mips-linux/3.0.3/specs<BR>Configured with: =
../configure=20
--target=3Dmips-linux --enable-languages=3Dc --disable-shared=20
--with-headers=3D/usr/local/include --with-newlib<BR>Thread model: =
single<BR>gcc=20
version 3.0.3<BR>&nbsp;/usr/local/lib/gcc-lib/mips-linux/3.0.3/cpp0 =
-lang-c -v=20
-D__GNUC__=3D3 -D__GNUC_MINOR__=3D0 -D__GNUC_PATCHLEVEL__=3D3 -DMIPSEB =
-D_MIPSEB=20
-Dunix -Dmips -D_mips -DR3000 -D_R3000 -Dlinux -D__ELF__ -D__PIC__ =
-D__pic__=20
-D__MIPSEB__ -D_MIPSEB -D__unix__ -D__mips__ -D__mips__ -D__R3000__ =
-D_R3000=20
-D__linux__ -D__ELF__ -D__PIC__ -D__pic__ -D__MIPSEB -D__unix -D__mips =
-D__mips=20
-D__R3000 -D__linux -Asystem=3Dposix -Acpu=3Dmips -Amachine=3Dmips =
-D__NO_INLINE__=20
-D__STDC_HOSTED__=3D1 -D__LANGUAGE_C -D_LANGUAGE_C -DLANGUAGE_C=20
-D__SIZE_TYPE__=3Dunsigned int -D__PTRDIFF_TYPE__=3Dint =
-D_MIPS_FPSET=3D32=20
-D_MIPS_ISA=3D_MIPS_ISA_MIPS1 -D_MIPS_SIM=3D_MIPS_SIM_ABI32 =
-D_MIPS_SZINT=3D32=20
-D_MIPS_SZLONG=3D32 -D_MIPS_SZPTR=3D32 -U__mips -D__mips -U__mips64 =
-<BR>GNU CPP=20
version 3.0.3 (cpplib) (MIPS GNU/Linux with ELF)<BR>#include "..." =
search starts=20
here:<BR>#include &lt;...&gt; search starts=20
here:<BR>&nbsp;/usr/local/lib/gcc-lib/mips-linux/3.0.3/include<BR>&nbsp;/=
usr/local/mips-linux/sys-include<BR>&nbsp;/usr/local/mips-linux/include<B=
R>End=20
of search list.<BR></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Can you kindly give me some help&nbsp;in=20
this?&nbsp;</FONT></DIV>
<DIV><FONT size=3D2>Thank you very much.</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0017_01C2E3FD.EAFC4EB0--


From ralf@linux-mips.net Thu Mar  6 12:22:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Mar 2003 12:22:44 +0000 (GMT)
Received: from p508B7C1E.dip.t-dialin.net ([IPv6:::ffff:80.139.124.30]:26081
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224847AbTCFMWn>; Thu, 6 Mar 2003 12:22:43 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h26CMV815985;
	Thu, 6 Mar 2003 13:22:31 +0100
Date: Thu, 6 Mar 2003 13:22:31 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: jackson <jackson@realtek.com.tw>
Cc: linux-mips@linux-mips.org
Subject: Re: gnu tool-chain support for mips16?
Message-ID: <20030306132231.A15899@linux-mips.org>
References: <001a01c2e3ba$dd490e90$7405a8c0@realtek.com.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <001a01c2e3ba$dd490e90$7405a8c0@realtek.com.tw>; from jackson@realtek.com.tw on Thu, Mar 06, 2003 at 04:32:02PM +0800
Return-Path: <ralf@linux-mips.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: 1636
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 836
Lines: 26

On Thu, Mar 06, 2003 at 04:32:02PM +0800, jackson wrote:

> I follow rules on http://www.ltc.com/~brad/mips/mips-cross-toolchain/
> to build gnu tool-cahin. 
> It works pefect for me to build linux/glibc/ulibc, and perform excellent
> on my Demo Board.
> 
> However, it report some bug messags as following when I compile a test.c 
> like:
> int test()
> {
>     return 0;
> }
> 
> ===================
> mips-linux-gcc -c -mips16 -o test test.c
> /tmp/ccjnCwV7.s: Assembler messages:
> /tmp/ccjnCwV7.s:14: Internal error!
> Assertion failure in macro_build_lui at ../../gas/config/tc-mips.c line 3107.
> Please report this bug.

All userspace with glibc, the standard userspace library environment for
Linux, must be PIC code and therefore the Linux compiler defaults to PIC
It's not possible to combine PIC code and MIPS16 ...

  Ralf

From kwalker@broadcom.com Thu Mar  6 16:47:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Mar 2003 16:47:26 +0000 (GMT)
Received: from mms3.broadcom.com ([IPv6:::ffff:63.70.210.38]:43524 "EHLO
	mms3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225204AbTCFQrZ>; Thu, 6 Mar 2003 16:47:25 +0000
Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.0)); Thu, 06 Mar 2003 08:47:22 -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 IAA07273; Thu, 6 Mar 2003 08:47:05 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h26GlGER017178; Thu, 6 Mar 2003 08:47:16 -0800 (PST)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id IAA11769; Thu, 6
 Mar 2003 08:47:16 -0800
Message-ID: <3E677B94.AE22C65D@broadcom.com>
Date: Thu, 06 Mar 2003 08:47:16 -0800
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
cc: "Ralf Baechle" <ralf@linux-mips.org>
Subject: Re: [PATCH] add CONFIG_DEBUG_INFO
References: <20030220113404.E7466@mvista.com>
 <3E63B047.D3BA2A2C@broadcom.com> <86d6l8fcvv.fsf@trasno.mitica>
X-WSS-ID: 1279A41047361-01-01
Content-Type: multipart/mixed;
 boundary=------------DD1721530DCE298F1BC44E84
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: 1638
X-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
Content-Length: 2898
Lines: 86

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


Any more comments on this topic?  Here's a patch that incorporates
Juan's suggestion.  I'm content to do away with the multiple-dependence
syntax in the Makefiles...  having KGDB on defines "CONFIG_DEBUG_INFO",
otherwise you can explicitly turn it on.  If no one objects, I'll do the
same for 2.5.

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

Index: arch/mips/config-shared.in
===================================================================
RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v
retrieving revision 1.1.2.48
diff -u -r1.1.2.48 config-shared.in
--- arch/mips/config-shared.in	26 Feb 2003 21:14:23 -0000	1.1.2.48
+++ arch/mips/config-shared.in	6 Mar 2003 16:43:59 -0000
@@ -977,6 +977,11 @@
 bool 'Are you using a crosscompiler' CONFIG_CROSSCOMPILE
 bool 'Enable run-time debugging' CONFIG_RUNTIME_DEBUG
 bool 'Remote GDB kernel debugging' CONFIG_KGDB
+if [ "$CONFIG_KGDB" = "y" ]; then
+   define_bool CONFIG_DEBUG_INFO y
+else
+   bool 'Debugging symbols' CONFIG_DEBUG_INFO
+fi
 dep_bool '  Console output to GDB' CONFIG_GDB_CONSOLE $CONFIG_KGDB
 if [ "$CONFIG_SIBYTE_SB1xxx_SOC" = "y" ]; then
    bool 'Compile for Corelis Debugger' CONFIG_SB1XXX_CORELIS
Index: arch/mips/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/Makefile,v
retrieving revision 1.78.2.23
diff -u -r1.78.2.23 Makefile
--- arch/mips/Makefile	26 Feb 2003 21:14:23 -0000	1.78.2.23
+++ arch/mips/Makefile	6 Mar 2003 16:43:59 -0000
@@ -41,11 +41,11 @@
 LINKFLAGS	+= -G 0 -static # -N
 MODFLAGS	+= -mlong-calls
 
-ifdef CONFIG_KGDB
+ifdef CONFIG_DEBUG_INFO
 GCCFLAGS	+= -g
+endif
 ifdef CONFIG_SB1XXX_CORELIS
 GCCFLAGS	+= -mno-sched-prolog -fno-omit-frame-pointer
-endif
 endif
 
 check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
Index: arch/mips64/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips64/Makefile,v
retrieving revision 1.22.2.27
diff -u -r1.22.2.27 Makefile
--- arch/mips64/Makefile	26 Feb 2003 21:14:24 -0000	1.22.2.27
+++ arch/mips64/Makefile	6 Mar 2003 16:43:59 -0000
@@ -39,11 +39,11 @@
 LINKFLAGS	+= -G 0 -static # -N
 MODFLAGS	+= -mlong-calls
 
-ifdef CONFIG_KGDB
+ifdef CONFIG_DEBUG_INFO
 GCCFLAGS	+= -g
+endif
 ifdef CONFIG_SB1XXX_CORELIS
 GCCFLAGS	+= -mno-sched-prolog -fno-omit-frame-pointer
-endif
 endif
 
 check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)

--------------DD1721530DCE298F1BC44E84--


From jsun@mvista.com Thu Mar  6 17:40:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Mar 2003 17:40:40 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:44029 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225204AbTCFRkj>;
	Thu, 6 Mar 2003 17:40:39 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h26HeYL26116;
	Thu, 6 Mar 2003 09:40:34 -0800
Date: Thu, 6 Mar 2003 09:40:34 -0800
From: Jun Sun <jsun@mvista.com>
To: Tinga Shilo <tingashilo@yahoo.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: static variables access and gp
Message-ID: <20030306094034.A26071@mvista.com>
References: <20030306073017.65521.qmail@web41509.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: <20030306073017.65521.qmail@web41509.mail.yahoo.com>; from tingashilo@yahoo.com on Wed, Mar 05, 2003 at 11:30:17PM -0800
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: 1639
X-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
Content-Length: 654
Lines: 19

On Wed, Mar 05, 2003 at 11:30:17PM -0800, Tinga Shilo wrote:
> Hi,
> I am implementing a kernel mechanism which is 
> very performance oriented. Along my long critical
> path,
> there is a static variable that needs to be accessed
> quite a few times. This variable is a structure which
> is approximately 60 bytes big.
> In there any way I can "convince" my kernel (compiled
> with gcc) to access this variable using gp ?
> Is gp usually used for this purpose in mips-linux ?
> Can it be ?
>

No.  gp is used by kernel to hold current process in 2.4
and current thread in 2.5.  Don't mess with it unless
you are absolutely sure what you are doing.

Jun

From kwalker@broadcom.com Fri Mar  7 01:01:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 01:01:34 +0000 (GMT)
Received: from mms2.broadcom.com ([IPv6:::ffff:63.70.210.59]:32775 "EHLO
	mms2.broadcom.com") by linux-mips.org with ESMTP
	id <S8225211AbTCGBBe>; Fri, 7 Mar 2003 01:01:34 +0000
Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.0)); Thu, 06 Mar 2003 16:58:30 -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 RAA19846 for <linux-mips@linux-mips.org>; Thu, 6 Mar 2003 17:01:13
 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h2711OER027596 for <linux-mips@linux-mips.org>; Thu, 6 Mar 2003 17:01:
 24 -0800 (PST)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id RAA15332 for
 <linux-mips@linux-mips.org>; Thu, 6 Mar 2003 17:01:24 -0800
Message-ID: <3E67EF64.152CFC6C@broadcom.com>
Date: Thu, 06 Mar 2003 17:01:24 -0800
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: [pathch] kernel/sched.c bogon?
X-WSS-ID: 1279313C2779821-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: 1640
X-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
Content-Length: 1067
Lines: 33


The comparisons of oldest_idle below trigger compiler warnings and
should probably be safely type-cast:

Kip

Index: kernel/sched.c
===================================================================
RCS file: /home/cvs/linux/kernel/sched.c,v
retrieving revision 1.64.2.6
diff -u -r1.64.2.6 sched.c
--- kernel/sched.c      25 Feb 2003 22:03:13 -0000      1.64.2.6
+++ kernel/sched.c      7 Mar 2003 00:57:35 -0000
@@ -282,7 +282,7 @@
                                target_tsk = tsk;
                        }
                } else {
-                       if (oldest_idle == -1ULL) {
+                       if (oldest_idle == (cycles_t) -1) {
                                int prio = preemption_goodness(tsk, p,
cpu);
 
                                if (prio > max_prio) {
@@ -294,7 +294,7 @@
        }
        tsk = target_tsk;
        if (tsk) {
-               if (oldest_idle != -1ULL) {
+               if (oldest_idle != (cycles_t) -1) {
                        best_cpu = tsk->processor;
                        goto send_now_idle;
                }


From jsun@mvista.com Fri Mar  7 01:40:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 01:40:06 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:61435 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225217AbTCGBkF>;
	Fri, 7 Mar 2003 01:40:05 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h271e2S16032;
	Thu, 6 Mar 2003 17:40:02 -0800
Date: Thu, 6 Mar 2003 17:40:01 -0800
From: Jun Sun <jsun@mvista.com>
To: Kip Walker <kwalker@broadcom.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [pathch] kernel/sched.c bogon?
Message-ID: <20030306174001.K26071@mvista.com>
References: <3E67EF64.152CFC6C@broadcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3E67EF64.152CFC6C@broadcom.com>; from kwalker@broadcom.com on Thu, Mar 06, 2003 at 05:01:24PM -0800
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: 1641
X-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
Content-Length: 1522
Lines: 46


I reported this bug last May.  Apparently it is still not
taken up-stream.   Ralf, why don't we fix it here and push
it up from you?

BTW, this bug actually has effect on real-time performance under
preemptible kernel.  It can delay the execution of the highest
priority real-time process from execution up to 1 jiffy.

Jun

On Thu, Mar 06, 2003 at 05:01:24PM -0800, Kip Walker wrote:
> 
> The comparisons of oldest_idle below trigger compiler warnings and
> should probably be safely type-cast:
> 
> Kip
> 
> Index: kernel/sched.c
> ===================================================================
> RCS file: /home/cvs/linux/kernel/sched.c,v
> retrieving revision 1.64.2.6
> diff -u -r1.64.2.6 sched.c
> --- kernel/sched.c      25 Feb 2003 22:03:13 -0000      1.64.2.6
> +++ kernel/sched.c      7 Mar 2003 00:57:35 -0000
> @@ -282,7 +282,7 @@
>                                 target_tsk = tsk;
>                         }
>                 } else {
> -                       if (oldest_idle == -1ULL) {
> +                       if (oldest_idle == (cycles_t) -1) {
>                                 int prio = preemption_goodness(tsk, p,
> cpu);
>  
>                                 if (prio > max_prio) {
> @@ -294,7 +294,7 @@
>         }
>         tsk = target_tsk;
>         if (tsk) {
> -               if (oldest_idle != -1ULL) {
> +               if (oldest_idle != (cycles_t) -1) {
>                         best_cpu = tsk->processor;
>                         goto send_now_idle;
>                 }
> 
> 

From baitisj@idealab.com Fri Mar  7 02:53:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 02:53:50 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:5058 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225204AbTCGCxt>;
	Fri, 7 Mar 2003 02:53:49 +0000
Received: (qmail 31558 invoked by uid 6180); 7 Mar 2003 02:53:45 -0000
Date: Thu, 6 Mar 2003 18:53:45 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: linux-mips@linux-mips.org
Subject: Kernel Debugging on the DBAu1500
Message-ID: <20030306185345.W20129@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: 1642
X-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
Content-Length: 1008
Lines: 40

Hi all:

I've been trying to get a kernel debugger running on my AMD DBAu1500.  It boots
up over a serial console. I enable "Remote GDB kernel debugging," and "Console
output to GDB."

Here's what I tell YAMON to do:

    go . gdb gdbttyS=0 gdbbaud=115200

And on my x86 machine, I:

    stty ispeed 115200 ospeed 115200 < /dev/ttyS1

    /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
    (gdb) target remote /dev/ttyS1 

GDB seems not to communicate. Here's what it says:

    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Couldn't establish connection to remote target
    Malformed response to offset query, timeout

Suggestions?

Thanks in advance!

-Jeff

-- 
         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 avinash.s@inspiretech.com Fri Mar  7 11:18:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 11:19:00 +0000 (GMT)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:3212
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8225204AbTCGLS7>; Fri, 7 Mar 2003 11:18:59 +0000
Received: from mail.inspiretech.com (mail.inspiretech.com [150.1.1.1])
	by smtp.inspirtek.com (8.12.5/8.12.5) with ESMTP id h27BTCcY005632
	for <linux-mips@linux-mips.org>; Fri, 7 Mar 2003 16:59:18 +0530
Message-Id: <200303071129.h27BTCcY005632@smtp.inspirtek.com>
Received: from WorldClient [150.1.1.1] by inspiretech.com [150.1.1.1]
	with SMTP (MDaemon.v3.5.7.R)
	for <linux-mips@linux-mips.org>; Fri, 07 Mar 2003 16:40:10 +0530
Date: Fri, 07 Mar 2003 16:40:08 +0530
From: "Avinash S." <avinash.s@inspiretech.com>
To: "linux" <linux-mips@linux-mips.org>
Subject: kernel download???
X-Mailer: WorldClient Standard 3.5.0e
X-MDRemoteIP: 150.1.1.1
X-Return-Path: avinash.s@inspiretech.com
X-MDaemon-Deliver-To: linux-mips@linux-mips.org
Return-Path: <avinash.s@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: 1643
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: avinash.s@inspiretech.com
Precedence: bulk
X-list: linux-mips
Content-Length: 116
Lines: 9

Can anyone tell me where i can get a kernel that supports the IDT S332 
processor ??

thanks in advance


Avinash



From quintela@mandrakesoft.com Fri Mar  7 12:03:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 12:03:16 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:19980 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225204AbTCGMDP>;
	Fri, 7 Mar 2003 12:03:15 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 8A69A7BC; Fri,  7 Mar 2003 13:02:52 +0100 (CET)
To: baitisj@evolution.com
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel Debugging on the DBAu1500
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030306185345.W20129@luca.pas.lab> (Jeff Baitis's message of
 "Thu, 6 Mar 2003 18:53:45 -0800")
References: <20030306185345.W20129@luca.pas.lab>
Date: Fri, 07 Mar 2003 13:02:52 +0100
Message-ID: <86y93rpeoj.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1644
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1230
Lines: 45

>>>>> "jeff" == Jeff Baitis <baitisj@evolution.com> writes:

Hi
        perhaps don't help, but try using 57600 bauds.  Some
        chipsets don't like 115200 bauds.

I have never used gdb on MIPS, but at least on intel, you need run a
program in your MIPS board (in intel it is gdbstart called).

Later, Juan.

jeff> Hi all:
jeff> I've been trying to get a kernel debugger running on my AMD DBAu1500.  It boots
jeff> up over a serial console. I enable "Remote GDB kernel debugging," and "Console
jeff> output to GDB."

jeff> Here's what I tell YAMON to do:

jeff> go . gdb gdbttyS=0 gdbbaud=115200

jeff> And on my x86 machine, I:

jeff> stty ispeed 115200 ospeed 115200 < /dev/ttyS1

jeff> /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
jeff> (gdb) target remote /dev/ttyS1 

jeff> GDB seems not to communicate. Here's what it says:

jeff> Ignoring packet error, continuing...
jeff> Ignoring packet error, continuing...
jeff> Ignoring packet error, continuing...
jeff> Couldn't establish connection to remote target
jeff> Malformed response to offset query, timeout

jeff> Suggestions?

jeff> Thanks in advance!




-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From dhananjayd@kpit.com Fri Mar  7 12:10:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 12:10:46 +0000 (GMT)
Received: from [IPv6:::ffff:203.129.230.82] ([IPv6:::ffff:203.129.230.82]:51752
	"EHLO sohm.kpit.com") by linux-mips.org with ESMTP
	id <S8225204AbTCGMKp> convert rfc822-to-8bit; Fri, 7 Mar 2003 12:10:45 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Subject: RE: Kernel Debugging on the DBAu1500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Fri, 7 Mar 2003 17:41:28 +0530
Message-ID: <69595093233BB547BB70CF5E492B63F2E5246E@sohm.kpit.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Kernel Debugging on the DBAu1500
Thread-Index: AcLkocnQZAfi5bPeQte8Hzut0Vbn2wAAK+XQ
From: "Dhananjay R. Deshpande" <dhananjayd@kpit.com>
To: "Juan Quintela" <quintela@mandrakesoft.com>,
	<baitisj@evolution.com>
Cc: <linux-mips@linux-mips.org>
Return-Path: <dhananjayd@kpit.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1645
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dhananjayd@kpit.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1666
Lines: 69

Hi,

Try 
(gdb) set remotebaud 115200

before 

(gdb) target remote /dev/ttyS1 


- Dhananjay

> -----Original Message-----
> From: Juan Quintela [mailto:quintela@mandrakesoft.com]
> Sent: Friday, March 07, 2003 5:33 PM
> To: baitisj@evolution.com
> Cc: linux-mips@linux-mips.org
> Subject: Re: Kernel Debugging on the DBAu1500
> 
> 
> >>>>> "jeff" == Jeff Baitis <baitisj@evolution.com> writes:
> 
> Hi
>         perhaps don't help, but try using 57600 bauds.  Some
>         chipsets don't like 115200 bauds.
> 
> I have never used gdb on MIPS, but at least on intel, you need run a
> program in your MIPS board (in intel it is gdbstart called).
> 
> Later, Juan.
> 
> jeff> Hi all:
> jeff> I've been trying to get a kernel debugger running on my 
> AMD DBAu1500.  It boots
> jeff> up over a serial console. I enable "Remote GDB kernel 
> debugging," and "Console
> jeff> output to GDB."
> 
> jeff> Here's what I tell YAMON to do:
> 
> jeff> go . gdb gdbttyS=0 gdbbaud=115200
> 
> jeff> And on my x86 machine, I:
> 
> jeff> stty ispeed 115200 ospeed 115200 < /dev/ttyS1
> 
> jeff> /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
> jeff> (gdb) target remote /dev/ttyS1 
> 
> jeff> GDB seems not to communicate. Here's what it says:
> 
> jeff> Ignoring packet error, continuing...
> jeff> Ignoring packet error, continuing...
> jeff> Ignoring packet error, continuing...
> jeff> Couldn't establish connection to remote target
> jeff> Malformed response to offset query, timeout
> 
> jeff> Suggestions?
> 
> jeff> Thanks in advance!
> 
> 
> 
> 
> -- 
> In theory, practice and theory are the same, but in practice they 
> are different -- Larry McVoy
> 
> 

From s_popov@prosyst.bg Fri Mar  7 12:30:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 12:30:43 +0000 (GMT)
Received: from ns.prosyst.bg ([IPv6:::ffff:212.95.166.35]:64520 "HELO
	ns.prosyst.bg") by linux-mips.org with SMTP id <S8225204AbTCGMan>;
	Fri, 7 Mar 2003 12:30:43 +0000
Received: (qmail 26441 invoked from network); 7 Mar 2003 12:30:36 -0000
Received: from gw.prosyst.bg (HELO prosyst.bg) (212.95.166.50)
  by ns.prosyst.bg with SMTP; 7 Mar 2003 12:30:36 -0000
Message-ID: <3E689267.3070509@prosyst.bg>
Date: Fri, 07 Mar 2003 14:36:55 +0200
From: Alexander Popov <s_popov@prosyst.bg>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Mycable XXS board
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <s_popov@prosyst.bg>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1646
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: s_popov@prosyst.bg
Precedence: bulk
X-list: linux-mips
Content-Length: 274
Lines: 10

Hi all,

Has anyone used the kernel on a Mycable XXS board ( it has Alchemy au1500 )...
What CPU type should I choose for the au1500? R5000? Sorry for the lame question but I haven't used 
MIPS-based boards and I know nothing baout the CPU...

Regards,
-- 
Alexander Popov


From ppopov@mvista.com Fri Mar  7 12:36:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 12:36:08 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:41979 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225204AbTCGMgH>;
	Fri, 7 Mar 2003 12:36:07 +0000
Received: from [10.2.2.20] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id EAA05164;
	Fri, 7 Mar 2003 04:35:58 -0800
Subject: Re: Mycable XXS board
From: Pete Popov <ppopov@mvista.com>
To: Alexander Popov <s_popov@prosyst.bg>
Cc: linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <3E689267.3070509@prosyst.bg>
References: <3E689267.3070509@prosyst.bg>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047040846.10649.10.camel@adsl.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 07 Mar 2003 04:40:46 -0800
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: 1647
X-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
Content-Length: 618
Lines: 16

On Fri, 2003-03-07 at 04:36, Alexander Popov wrote:
> Hi all,
> 
> Has anyone used the kernel on a Mycable XXS board ( it has Alchemy au1500 )...
> What CPU type should I choose for the au1500? R5000? Sorry for the lame question but I haven't used 
> MIPS-based boards and I know nothing baout the CPU...

Given that the board has an Alchemy Au1500 CPU, I would say you should
chose the Au1500 :)  Start with the Pb1500 board port that's in
linux-mips.org. Maybe, just maybe, a Pb1500 kernel will boot fine on
your board. And if it doesn't, creating a port for the above mentioned
board should be fairly easy.

Pete



From ppopov@mvista.com Fri Mar  7 13:22:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 13:22:06 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:15600 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225204AbTCGNWF>;
	Fri, 7 Mar 2003 13:22:05 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id FAA06034;
	Fri, 7 Mar 2003 05:22:00 -0800
Subject: Re: Kernel Debugging on the DBAu1500
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com
Cc: linux-mips@linux-mips.org
In-Reply-To: <20030306185345.W20129@luca.pas.lab>
References: <20030306185345.W20129@luca.pas.lab>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047043427.30914.432.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 07 Mar 2003 05:23:48 -0800
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: 1648
X-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
Content-Length: 1235
Lines: 46

Jeff,

Take a look at the board and remind me if the second serial port is
actually uart2, where the first is uart0. I think it might be. If that's
the case, arch/mips/au1000/common/dbg_io.c has this define if kgdb is
defined:

#define DEBUG_BASE  UART2_ADDR

That needs to get fixed. It would be better to parse the command line
for something like "kgdb=ttyS2,115200".

Pete

On Thu, 2003-03-06 at 18:53, Jeff Baitis wrote:
> Hi all:
> 
> I've been trying to get a kernel debugger running on my AMD DBAu1500.  It boots
> up over a serial console. I enable "Remote GDB kernel debugging," and "Console
> output to GDB."
> 
> Here's what I tell YAMON to do:
> 
>     go . gdb gdbttyS=0 gdbbaud=115200
> 
> And on my x86 machine, I:
> 
>     stty ispeed 115200 ospeed 115200 < /dev/ttyS1
> 
>     /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
>     (gdb) target remote /dev/ttyS1 
> 
> GDB seems not to communicate. Here's what it says:
> 
>     Ignoring packet error, continuing...
>     Ignoring packet error, continuing...
>     Ignoring packet error, continuing...
>     Couldn't establish connection to remote target
>     Malformed response to offset query, timeout
> 
> Suggestions?
> 
> Thanks in advance!
> 
> -Jeff


From ppopov@mvista.com Fri Mar  7 13:26:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 13:26:14 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:41712 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225204AbTCGN0O>;
	Fri, 7 Mar 2003 13:26:14 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id FAA06116;
	Fri, 7 Mar 2003 05:26:10 -0800
Subject: Re: Kernel Debugging on the DBAu1500
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com
Cc: linux-mips@linux-mips.org
In-Reply-To: <1047043427.30914.432.camel@zeus.mvista.com>
References: <20030306185345.W20129@luca.pas.lab>
	 <1047043427.30914.432.camel@zeus.mvista.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047043677.6389.436.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 07 Mar 2003 05:27:58 -0800
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: 1649
X-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
Content-Length: 1485
Lines: 57

On Fri, 2003-03-07 at 05:23, Pete Popov wrote:
> Jeff,
> 
> Take a look at the board and remind me if the second serial port is
> actually uart2, where the first is uart0. 

Sorry, I meant uart3, which would be a reason why the UART2_ADDR define
below wouldn't work.

Pete

> I think it might be. If that's
> the case, arch/mips/au1000/common/dbg_io.c has this define if kgdb is
> defined:
> 
> #define DEBUG_BASE  UART2_ADDR
> 
> That needs to get fixed. It would be better to parse the command line
> for something like "kgdb=ttyS2,115200".
> 
> Pete
> 
> On Thu, 2003-03-06 at 18:53, Jeff Baitis wrote:
> > Hi all:
> > 
> > I've been trying to get a kernel debugger running on my AMD DBAu1500.  It boots
> > up over a serial console. I enable "Remote GDB kernel debugging," and "Console
> > output to GDB."
> > 
> > Here's what I tell YAMON to do:
> > 
> >     go . gdb gdbttyS=0 gdbbaud=115200
> > 
> > And on my x86 machine, I:
> > 
> >     stty ispeed 115200 ospeed 115200 < /dev/ttyS1
> > 
> >     /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
> >     (gdb) target remote /dev/ttyS1 
> > 
> > GDB seems not to communicate. Here's what it says:
> > 
> >     Ignoring packet error, continuing...
> >     Ignoring packet error, continuing...
> >     Ignoring packet error, continuing...
> >     Couldn't establish connection to remote target
> >     Malformed response to offset query, timeout
> > 
> > Suggestions?
> > 
> > Thanks in advance!
> > 
> > -Jeff
> 
> 
> 


From quintela@mandrakesoft.com Fri Mar  7 13:49:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 13:49:18 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:64015 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225234AbTCGNtR>;
	Fri, 7 Mar 2003 13:49:17 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 17BCD7BC; Fri,  7 Mar 2003 14:48:56 +0100 (CET)
To: "Kip Walker" <kwalker@broadcom.com>
Cc: linux-mips@linux-mips.org, "Ralf Baechle" <ralf@linux-mips.org>
Subject: Re: [PATCH] add CONFIG_DEBUG_INFO
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <3E677B94.AE22C65D@broadcom.com> ("Kip Walker"'s message of
 "Thu, 06 Mar 2003 08:47:16 -0800")
References: <20030220113404.E7466@mvista.com> <3E63B047.D3BA2A2C@broadcom.com>
	<86d6l8fcvv.fsf@trasno.mitica> <3E677B94.AE22C65D@broadcom.com>
Date: Fri, 07 Mar 2003 14:48:56 +0100
Message-ID: <86u1efp9rr.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1650
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 793
Lines: 28

>>>>> "kip" == Kip Walker <kwalker@broadcom.com> writes:

Hi again

kip> diff -u -r1.78.2.23 Makefile
kip> --- arch/mips/Makefile	26 Feb 2003 21:14:23 -0000	1.78.2.23
kip> +++ arch/mips/Makefile	6 Mar 2003 16:43:59 -0000
kip> @@ -41,11 +41,11 @@
kip> LINKFLAGS	+= -G 0 -static # -N
kip> MODFLAGS	+= -mlong-calls
 
kip> -ifdef CONFIG_KGDB
kip> +ifdef CONFIG_DEBUG_INFO
kip> GCCFLAGS	+= -g
kip> +endif
kip> ifdef CONFIG_SB1XXX_CORELIS
kip> GCCFLAGS	+= -mno-sched-prolog -fno-omit-frame-pointer
kip> -endif
kip> endif
 
I have no idea what the Corelis debugger is, but I assume that putting
it configuration out of the CONFIG_KGDB is intentional?  It doesn't
require the -g option?

Later, Juan.
-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From ralf@linux-mips.net Fri Mar  7 15:21:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 15:21:32 +0000 (GMT)
Received: from p508B7C79.dip.t-dialin.net ([IPv6:::ffff:80.139.124.121]:9129
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225203AbTCGPVb>; Fri, 7 Mar 2003 15:21:31 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h27FLEg27044;
	Fri, 7 Mar 2003 16:21:14 +0100
Date: Fri, 7 Mar 2003 16:21:14 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Juan Quintela <quintela@mandrakesoft.com>
Cc: Kip Walker <kwalker@broadcom.com>, linux-mips@linux-mips.org
Subject: Re: [PATCH] add CONFIG_DEBUG_INFO
Message-ID: <20030307162114.A26545@linux-mips.org>
References: <20030220113404.E7466@mvista.com> <3E63B047.D3BA2A2C@broadcom.com> <86d6l8fcvv.fsf@trasno.mitica> <3E677B94.AE22C65D@broadcom.com> <86u1efp9rr.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: <86u1efp9rr.fsf@trasno.mitica>; from quintela@mandrakesoft.com on Fri, Mar 07, 2003 at 02:48:56PM +0100
Return-Path: <ralf@linux-mips.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: 1651
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 263
Lines: 9

On Fri, Mar 07, 2003 at 02:48:56PM +0100, Juan Quintela wrote:

> I have no idea what the Corelis debugger is, but I assume that putting
> it configuration out of the CONFIG_KGDB is intentional?  It doesn't
> require the -g option?

It's a JTAG debugger.

  Ralf

From kwalker@broadcom.com Fri Mar  7 15:28:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 15:28:02 +0000 (GMT)
Received: from mms1.broadcom.com ([IPv6:::ffff:63.70.210.58]:48395 "EHLO
	mms1.broadcom.com") by linux-mips.org with ESMTP
	id <S8225203AbTCGP2B>; Fri, 7 Mar 2003 15:28:01 +0000
Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 07:27:35 -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 HAA18732; Fri, 7 Mar 2003 07:27:39 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h27FRoER004876; Fri, 7 Mar 2003 07:27:50 -0800 (PST)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id HAA15923; Fri, 7
 Mar 2003 07:27:50 -0800
Message-ID: <3E68BA76.2A54D7CF@broadcom.com>
Date: Fri, 07 Mar 2003 07:27:50 -0800
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Juan Quintela" <quintela@mandrakesoft.com>
cc: linux-mips@linux-mips.org, "Ralf Baechle" <ralf@linux-mips.org>
Subject: Re: [PATCH] add CONFIG_DEBUG_INFO
References: <20030220113404.E7466@mvista.com>
 <3E63B047.D3BA2A2C@broadcom.com> <86d6l8fcvv.fsf@trasno.mitica>
 <3E677B94.AE22C65D@broadcom.com> <86u1efp9rr.fsf@trasno.mitica>
X-WSS-ID: 127665ED1214491-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: 1652
X-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
Content-Length: 374
Lines: 8

> I have no idea what the Corelis debugger is, but I assume that putting
> it configuration out of the CONFIG_KGDB is intentional?  It doesn't
> require the -g option?

Yes -- the patch didn't include it, but the Corelis option will depend
on DEBUG_INFO.  I just thought removing the nested ifdef was more
attractive, and have the configure magic deal with the dependence.


From br1@4g-systems.de Fri Mar  7 15:47:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 15:47:21 +0000 (GMT)
Received: from moutvdom.kundenserver.de ([IPv6:::ffff:212.227.126.252]:12242
	"EHLO moutvdom.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225203AbTCGPrU>; Fri, 7 Mar 2003 15:47:20 +0000
Received: from [212.227.126.222] (helo=mrvdomng.kundenserver.de)
	by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1)
	id 18rK46-0003kf-00; Fri, 07 Mar 2003 16:47:18 +0100
Received: from [62.109.119.183] (helo=192.168.202.41)
	by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 18rK45-0008QZ-00; Fri, 07 Mar 2003 16:47:17 +0100
From: Bruno Randolf <br1@4g-systems.de>
Organization: 4G Mobile Systeme
To: Alexander Popov <s_popov@prosyst.bg>
Subject: Re: Mycable XXS board
Date: Fri, 7 Mar 2003 16:47:13 +0100
User-Agent: KMail/1.5
References: <3E689267.3070509@prosyst.bg> <1047040846.10649.10.camel@adsl.pacbell.net>
In-Reply-To: <1047040846.10649.10.camel@adsl.pacbell.net>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_B8La+X0aPWUZE5k"
Message-Id: <200303071647.13275.br1@4g-systems.de>
Return-Path: <br1@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: 1653
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: br1@4g-systems.de
Precedence: bulk
X-list: linux-mips
Content-Length: 4054
Lines: 135


--Boundary-00=_B8La+X0aPWUZE5k
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

hello!

we are also working with this board and it it supported thru the Pb1500 board 
configuration of the linux-mips.org kernel. we use the 2_4 branch and some 
patches of pete (ftp://ftp.linux-mips.org/pub/linux/mips/people/ppopov). with 
these patches i can already see my pci cards (but i dont yet have a driver 
for them). usb does not yet work - it complains that it cannot assign new 
numbers to the devices. the flash chip (AM29LV641DL) is also not recognized 
yet.

if you dont use YAMON, you have to add a patch to deal with the nonexistent 
command line parameters. i attached it for you, but its an ugly hack.

and to enable one of the ethernet ports you can use the second patch. it's 
also quite a hack, cause it does not yet deal with the second port... 

bruno


On Friday 07 March 2003 13:40, you wrote:
> On Fri, 2003-03-07 at 04:36, Alexander Popov wrote:
> > Hi all,
> >
> > Has anyone used the kernel on a Mycable XXS board ( it has Alchemy au1500
> > )... What CPU type should I choose for the au1500? R5000? Sorry for the
> > lame question but I haven't used MIPS-based boards and I know nothing
> > baout the CPU...
>
> Given that the board has an Alchemy Au1500 CPU, I would say you should
> chose the Au1500 :)  Start with the Pb1500 board port that's in
> linux-mips.org. Maybe, just maybe, a Pb1500 kernel will boot fine on
> your board. And if it doesn't, creating a port for the above mentioned
> board should be fairly easy.
>
> Pete

--Boundary-00=_B8La+X0aPWUZE5k
Content-Type: text/x-diff;
  charset="iso-8859-1";
  name="cfc_startup.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cfc_startup.diff"

--- arch/mips/au1000/common/prom.c	Wed Dec 12 19:30:52 2001
+++ arch/mips/au1000/common/prom.c	Tue Feb  4 00:41:08 2003
@@ -62,21 +62,21 @@
 
 void  prom_init_cmdline(void)
 {
-	char *cp;
-	int actr;
+//	char *cp;
+//	int actr;
 
-	actr = 1; /* Always ignore argv[0] */
+//	actr = 1; /* Always ignore argv[0] */
 
-	cp = &(arcs_cmdline[0]);
-	while(actr < prom_argc) {
-	        strcpy(cp, prom_argv[actr]);
-		cp += strlen(prom_argv[actr]);
-		*cp++ = ' ';
-		actr++;
-	}
-	if (cp != &(arcs_cmdline[0])) /* get rid of trailing space */
-		--cp;
-	*cp = '\0';
+//	cp = &(arcs_cmdline[0]);
+//	while(actr < prom_argc) {
+//	        strcpy(cp, prom_argv[actr]);
+//		cp += strlen(prom_argv[actr]);
+//		*cp++ = ' ';
+//		actr++;
+//	}
+//	if (cp != &(arcs_cmdline[0])) /* get rid of trailing space */
+//		--cp;
+//	*cp = '\0';
 
 }
 
@@ -88,17 +88,17 @@
 	 * Environment variables are stored in the form of "memsize=64".
 	 */
 
-	t_env_var *env = (t_env_var *)prom_envp;
-	int i;
+//	t_env_var *env = (t_env_var *)prom_envp;
+//	int i;
 
-	i = strlen(envname);
+//	i = strlen(envname);
 
-	while(env->name) {
-		if(strncmp(envname, env->name, i) == 0) {
-			return(env->name + strlen(envname) + 1);
-		}
-		env++;
-	}
+//	while(env->name) {
+//		if(strncmp(envname, env->name, i) == 0) {
+//			return(env->name + strlen(envname) + 1);
+//		}
+//		env++;
+//	}
 	return(NULL);
 }
 

--Boundary-00=_B8La+X0aPWUZE5k
Content-Type: text/x-diff;
  charset="iso-8859-1";
  name="au1000_eth_BCM5222_hack.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="au1000_eth_BCM5222_hack.diff"

--- ../linux-mips-2_4-cvs-clean/drivers/net/au1000_eth.c	Wed Dec 11 07:12:30 2002
+++ drivers/net/au1000_eth.c	Fri Feb  7 14:37:49 2003
@@ -471,6 +471,7 @@
 } mii_chip_table[] = {
 	{"Broadcom BCM5201 10/100 BaseT PHY",  0x0040, 0x6212, &bcm_5201_ops },
 	{"Broadcom BCM5221 10/100 BaseT PHY",  0x0040, 0x61e4, &bcm_5201_ops },
+	{"Broadcom BCM5222 10/100 BaseT PHY",  0x0040, 0x6322, &bcm_5201_ops },
 	{"AMD 79C901 HomePNA PHY",  0x0000, 0x35c8, &am79c901_ops },
 	{"AMD 79C874 10/100 BaseT PHY",  0x0022, 0x561b, &am79c874_ops },
 	{"LSI 80227 10/100 BaseT PHY", 0x0016, 0xf840, &lsi_80227_ops },

--Boundary-00=_B8La+X0aPWUZE5k--


From henri@broadbandnetdevices.com Fri Mar  7 16:27:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 16:27:42 +0000 (GMT)
Received: from p508B7C79.dip.t-dialin.net ([IPv6:::ffff:80.139.124.121]:32905
	"EHLO p508B7C79.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225203AbTCGQ1l>; Fri, 7 Mar 2003 16:27:41 +0000
Received: from tomts8.bellnexxia.net ([IPv6:::ffff:209.226.175.52]:16854 "EHLO
	tomts8-srv.bellnexxia.net") by ralf.linux-mips.org with ESMTP
	id <S869085AbTCGQ1i>; Fri, 7 Mar 2003 17:27:38 +0100
Received: from amdk62400 ([209.226.97.64]) by tomts8-srv.bellnexxia.net
          (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP
          id <20030307162727.FSVU3032.tomts8-srv.bellnexxia.net@amdk62400>
          for <linux-mips@linux-mips.org>; Fri, 7 Mar 2003 11:27:27 -0500
Message-ID: <000f01c2e4c6$65818600$0400a8c0@amdk62400>
Reply-To: "HG" <henri@broadbandnetdevices.com>
From: "HG" <henri@broadbandnetdevices.com>
To: <linux-mips@linux-mips.org>
Subject: mips-linux-ld related question
Date: Fri, 7 Mar 2003 11:25:14 -0500
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: 1654
X-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
Content-Length: 428
Lines: 15

Hi All

I installed the binutils-mips-linux-2.13.1.i386.rpm and
egcs-mips-linux-1.1.2-4.i386.rpm from the linux-mips ftp site on a caldera
distribution 3.11 linux box to crosscompile a 2.4 kernel.
no error message while compiling , i get the following error while linking :
 mips-linux-ld: target elf32-bigmips not found

is there some env variable or path that I missed that needs to be set ????

thanks for any help.

Henri



From jsun@mvista.com Fri Mar  7 18:14:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 18:14:02 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:51696 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225203AbTCGSOC>;
	Fri, 7 Mar 2003 18:14:02 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h27IDsX17772;
	Fri, 7 Mar 2003 10:13:54 -0800
Date: Fri, 7 Mar 2003 10:13:54 -0800
From: Jun Sun <jsun@mvista.com>
To: Bruno Randolf <br1@4g-systems.de>
Cc: Alexander Popov <s_popov@prosyst.bg>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: Mycable XXS board
Message-ID: <20030307101354.N26071@mvista.com>
References: <3E689267.3070509@prosyst.bg> <1047040846.10649.10.camel@adsl.pacbell.net> <200303071647.13275.br1@4g-systems.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200303071647.13275.br1@4g-systems.de>; from br1@4g-systems.de on Fri, Mar 07, 2003 at 04:47:13PM +0100
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1655
X-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
Content-Length: 603
Lines: 14

On Fri, Mar 07, 2003 at 04:47:13PM +0100, Bruno Randolf wrote:
> hello!
> 
> we are also working with this board and it it supported thru the Pb1500 board 
> configuration of the linux-mips.org kernel. we use the 2_4 branch and some 
> patches of pete (ftp://ftp.linux-mips.org/pub/linux/mips/people/ppopov). with 
> these patches i can already see my pci cards (but i dont yet have a driver 
> for them). usb does not yet work - it complains that it cannot assign new 
> numbers to the devices. 

More than likely this is due to the interrupt routing for USB controller
not being setup correctly.

Jun

From drow@false.org Fri Mar  7 18:17:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 18:17:27 +0000 (GMT)
Received: from crack.them.org ([IPv6:::ffff:65.125.64.184]:38886 "EHLO
	crack.them.org") by linux-mips.org with ESMTP id <S8225203AbTCGSR1>;
	Fri, 7 Mar 2003 18:17:27 +0000
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 18rOIe-0008RM-00; Fri, 07 Mar 2003 14:18:37 -0600
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 18rMPI-0001WF-00; Fri, 07 Mar 2003 13:17:20 -0500
Date: Fri, 7 Mar 2003 13:17:20 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: HG <henri@broadbandnetdevices.com>
Cc: linux-mips@linux-mips.org
Subject: Re: mips-linux-ld related question
Message-ID: <20030307181720.GA5795@nevyn.them.org>
References: <000f01c2e4c6$65818600$0400a8c0@amdk62400>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000f01c2e4c6$65818600$0400a8c0@amdk62400>
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: 1656
X-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
Content-Length: 677
Lines: 17

On Fri, Mar 07, 2003 at 11:25:14AM -0500, HG wrote:
> Hi All
> 
> I installed the binutils-mips-linux-2.13.1.i386.rpm and
> egcs-mips-linux-1.1.2-4.i386.rpm from the linux-mips ftp site on a caldera
> distribution 3.11 linux box to crosscompile a 2.4 kernel.
> no error message while compiling , i get the following error while linking :
>  mips-linux-ld: target elf32-bigmips not found
> 
> is there some env variable or path that I missed that needs to be set ????

Fix the kernel; if it references elf32-bigmips your source is too old. 
It should be tradbigmips with those tools.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From kwalker@broadcom.com Fri Mar  7 19:38:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 19:38:56 +0000 (GMT)
Received: from mms3.broadcom.com ([IPv6:::ffff:63.70.210.38]:36102 "EHLO
	mms3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225247AbTCGTiz>; Fri, 7 Mar 2003 19:38:55 +0000
Received: from 10.10.64.123 by mms3.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 11:27:51 -0700
Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com
 [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id LAA01613; Fri, 7 Mar 2003 11:27:33 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h27JRiER009234; Fri, 7 Mar 2003 11:27:44 -0800 (PST)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id LAA16600; Fri, 7
 Mar 2003 11:27:45 -0800
Message-ID: <3E68F2B1.3413093D@broadcom.com>
Date: Fri, 07 Mar 2003 11:27:45 -0800
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ralf Baechle" <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: mips64 scall_o32.S fixes?
X-WSS-ID: 12762D3D154913-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: 1657
X-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
Content-Length: 1126
Lines: 36


I assume sys32_syscall should only allow o32 syscalls?  So the #defines
being used were wrong.  And MAX_SYSCALL_NO, although unused, seems to
have the wrong thing in it.

Any disagreement?

Kip

Index: arch/mips64/kernel/scall_o32.S
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/scall_o32.S,v
retrieving revision 1.48.2.26
diff -u -r1.48.2.26 scall_o32.S
--- arch/mips64/kernel/scall_o32.S      7 Mar 2003 01:22:48 -0000      
1.48.2.26
+++ arch/mips64/kernel/scall_o32.S      7 Mar 2003 19:26:36 -0000
@@ -23,7 +23,7 @@
 #include <asm/sysmips.h>
 
 /* Highest syscall used of any syscall flavour */
-#define MAX_SYSCALL_NO __NR_Linux32 + __NR_Linux32_syscalls
+#define MAX_SYSCALL_NO __NR_N32_Linux + __NR_N32_Linux_syscalls
 
        .align  5
 NESTED(handle_sys, PT_SIZE, sp)
@@ -263,7 +263,7 @@
 LEAF(sys32_syscall)
        ld      t0, PT_R29(sp)          # user sp
 
-       sltu    v0, a0, __NR_Linux + __NR_Linux_syscalls + 1
+       sltu    v0, a0, __NR_O32_Linux + __NR_O32_Linux_syscalls + 1
        beqz    v0, enosys
 
        dsll    v0, a0, 3


From kwalker@broadcom.com Fri Mar  7 19:39:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 19:39:43 +0000 (GMT)
Received: from mms3.broadcom.com ([IPv6:::ffff:63.70.210.38]:51466 "EHLO
	mms3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225247AbTCGTjm>; Fri, 7 Mar 2003 19:39:42 +0000
Received: from 10.10.64.123 by mms3.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 11:33:28 -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 LAA02597; Fri, 7 Mar 2003 11:33:10 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h27JXLER009344; Fri, 7 Mar 2003 11:33:22 -0800 (PST)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id LAA16615; Fri, 7
 Mar 2003 11:33:22 -0800
Message-ID: <3E68F402.E1DE44C6@broadcom.com>
Date: Fri, 07 Mar 2003 11:33:22 -0800
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ralf Baechle" <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: scall_64.S #ifdef fix
X-WSS-ID: 12762B82155170-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: 1658
X-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
Content-Length: 873
Lines: 29


I think CONFIG_BINFMT_ELF32 would be a better choice since it implies
that O32 or N32 is included, whereas CONFIG_MIPS32_COMPAT doesn't
necessarily imply it.

Kip

Index: arch/mips64/kernel/scall_64.S
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/scall_64.S,v
retrieving revision 1.20.2.14
diff -u -r1.20.2.14 scall_64.S
--- arch/mips64/kernel/scall_64.S       7 Mar 2003 01:22:48 -0000      
1.20.2.14
+++ arch/mips64/kernel/scall_64.S       7 Mar 2003 19:28:45 -0000
@@ -24,8 +24,8 @@
 
        .align  5
 NESTED(handle_sys64, PT_SIZE, sp)
-/* When 32-bit compatibility is configured scall_o32.S already did
this.  */
-#ifndef CONFIG_MIPS32_COMPAT
+/* When 32-bit binaries are handled scall_[on]32.S already did this. 
*/
+#ifndef CONFIG_BINFMT_ELF32
        .set    noat
        SAVE_SOME
        STI


From kwalker@broadcom.com Fri Mar  7 19:42:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 19:42:16 +0000 (GMT)
Received: from mms1.broadcom.com ([IPv6:::ffff:63.70.210.58]:10504 "EHLO
	mms1.broadcom.com") by linux-mips.org with ESMTP
	id <S8225247AbTCGTmP>; Fri, 7 Mar 2003 19:42:15 +0000
Received: from 10.10.64.123 by mms1.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 11:29:19 -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 LAA01988; Fri, 7 Mar 2003 11:29:23 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h27JTYER009278; Fri, 7 Mar 2003 11:29:34 -0800 (PST)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id LAA16607; Fri, 7
 Mar 2003 11:29:34 -0800
Message-ID: <3E68F31E.76604C00@broadcom.com>
Date: Fri, 07 Mar 2003 11:29:34 -0800
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ralf Baechle" <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: scall_n32.S register saves
X-WSS-ID: 12762C851233393-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: 1659
X-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
Content-Length: 759
Lines: 27


If O32 is enabled, handle_sysn32 shouldn't have to SAVE_SOME and STI...

Kip

Index: arch/mips64/kernel/scall_n32.S
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/scall_n32.S,v
retrieving revision 1.2.2.8
diff -u -r1.2.2.8 scall_n32.S
--- arch/mips64/kernel/scall_n32.S      7 Mar 2003 01:22:48 -0000      
1.2.2.8
+++ arch/mips64/kernel/scall_n32.S      7 Mar 2003 19:27:50 -0000
@@ -29,6 +29,12 @@
 
        .align  5
 NESTED(handle_sysn32, PT_SIZE, sp)
+#ifndef CONFIG_MIPS32_O32
+       .set    noat
+       SAVE_SOME
+       STI
+       .set    at
+#endif
        ld      t1, PT_EPC(sp)          # skip syscall on return
 
        subu    t0, v0, __NR_N32_Linux  # check syscall number


From dan@embeddededge.com Fri Mar  7 20:13:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 20:13:03 +0000 (GMT)
Received: from [IPv6:::ffff:63.161.110.249] ([IPv6:::ffff:63.161.110.249]:59376
	"EHLO tibook.netx4.com") by linux-mips.org with ESMTP
	id <S8225253AbTCGUNC>; Fri, 7 Mar 2003 20:13:02 +0000
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 h27KCIf00870;
	Fri, 7 Mar 2003 15:12:22 -0500
Message-ID: <3E68FD21.5050402@embeddededge.com>
Date: Fri, 07 Mar 2003 15:12:17 -0500
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jun Sun <jsun@mvista.com>
CC: Bruno Randolf <br1@4g-systems.de>,
	Alexander Popov <s_popov@prosyst.bg>, linux-mips@linux-mips.org
Subject: Re: Mycable XXS board
References: <3E689267.3070509@prosyst.bg> <1047040846.10649.10.camel@adsl.pacbell.net> <200303071647.13275.br1@4g-systems.de> <20030307101354.N26071@mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dan@embeddededge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1660
X-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
Content-Length: 555
Lines: 18

Jun Sun wrote:

> More than likely this is due to the interrupt routing for USB controller
> not being setup correctly.

How did you come to this conclusion?  Is this a PCI USB controller or the
on-chip peripheral?  I have Au1xxx boards were on-chip usb is
required and is working fine.  There aren't any options to configuring
on-chip USB interrupts on Au1xxx.  It could just as likely be a Linux kernel
configuration problem.  We know there is something amiss with Au1xxx USB
in big endian mode, but all LE boards should work fine.

Thanks.


	-- Dan



From baitisj@idealab.com Fri Mar  7 20:36:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 20:36:41 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:59077 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225253AbTCGUgk>;
	Fri, 7 Mar 2003 20:36:40 +0000
Received: (qmail 11800 invoked by uid 6180); 7 Mar 2003 20:36:37 -0000
Date: Fri, 7 Mar 2003 12:36:37 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel Debugging on the DBAu1500
Message-ID: <20030307123637.Y20129@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030306185345.W20129@luca.pas.lab> <1047043427.30914.432.camel@zeus.mvista.com> <1047043677.6389.436.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: <1047043677.6389.436.camel@zeus.mvista.com>; from ppopov@mvista.com on Fri, Mar 07, 2003 at 05:27:58AM -0800
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: 1661
X-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
Content-Length: 946
Lines: 37

Pete wrote wrote:
> > Take a look at the board and remind me if the second serial port is
> > actually uart2, where the first is uart0. 
Pete wrote:
> Sorry, I meant uart3, which would be a reason why the UART2_ADDR define
> below wouldn't work.

Hrm. The DBAu1500 seems to lock up when I execute:
    echo "please, no freeze" > /dev/ttyS2
I can't even get SysRq to work after that command.

/dev/ttyS3 works fine, though.

> > I think it might be. If that's
> > the case, arch/mips/au1000/common/dbg_io.c has this define if kgdb is
> > defined:
> > 
> > #define DEBUG_BASE  UART2_ADDR

I changed it to:
#define  DEBUG_BASE  UART3_ADDR

Debugging seems to work great now! Thanks!


-JB


-- 
         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 ppopov@mvista.com Fri Mar  7 20:39:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 20:39:24 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:21245 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225253AbTCGUjX>;
	Fri, 7 Mar 2003 20:39:23 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA23343;
	Fri, 7 Mar 2003 12:39:19 -0800
Subject: Re: Kernel Debugging on the DBAu1500
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com
Cc: linux-mips@linux-mips.org
In-Reply-To: <20030307123637.Y20129@luca.pas.lab>
References: <20030306185345.W20129@luca.pas.lab>
	 <1047043427.30914.432.camel@zeus.mvista.com>
	 <1047043677.6389.436.camel@zeus.mvista.com>
	 <20030307123637.Y20129@luca.pas.lab>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047069561.6389.505.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 07 Mar 2003 12:39:22 -0800
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: 1662
X-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
Content-Length: 890
Lines: 32

On Fri, 2003-03-07 at 12:36, Jeff Baitis wrote:
> Pete wrote wrote:
> > > Take a look at the board and remind me if the second serial port is
> > > actually uart2, where the first is uart0. 
> Pete wrote:
> > Sorry, I meant uart3, which would be a reason why the UART2_ADDR define
> > below wouldn't work.
> 
> Hrm. The DBAu1500 seems to lock up when I execute:
>     echo "please, no freeze" > /dev/ttyS2
> I can't even get SysRq to work after that command.

You're just a troublemaker ;) I'll take a look and fix it. I suspect I
know what the problem is.

> /dev/ttyS3 works fine, though.
> 
> > > I think it might be. If that's
> > > the case, arch/mips/au1000/common/dbg_io.c has this define if kgdb is
> > > defined:
> > > 
> > > #define DEBUG_BASE  UART2_ADDR
> 
> I changed it to:
> #define  DEBUG_BASE  UART3_ADDR
> 
> Debugging seems to work great now! Thanks!

No problem.

Pete


From jsun@mvista.com Fri Mar  7 21:39:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 21:39:31 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:64239 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225253AbTCGVjb>;
	Fri, 7 Mar 2003 21:39:31 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h27LdKc24090;
	Fri, 7 Mar 2003 13:39:20 -0800
Date: Fri, 7 Mar 2003 13:39:19 -0800
From: Jun Sun <jsun@mvista.com>
To: Dan Malek <dan@embeddededge.com>
Cc: Bruno Randolf <br1@4g-systems.de>,
	Alexander Popov <s_popov@prosyst.bg>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Mycable XXS board
Message-ID: <20030307133919.P26071@mvista.com>
References: <3E689267.3070509@prosyst.bg> <1047040846.10649.10.camel@adsl.pacbell.net> <200303071647.13275.br1@4g-systems.de> <20030307101354.N26071@mvista.com> <3E68FD21.5050402@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: <3E68FD21.5050402@embeddededge.com>; from dan@embeddededge.com on Fri, Mar 07, 2003 at 03:12:17PM -0500
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: 1663
X-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
Content-Length: 1061
Lines: 25

On Fri, Mar 07, 2003 at 03:12:17PM -0500, Dan Malek wrote:
> Jun Sun wrote:
> 
> > More than likely this is due to the interrupt routing for USB controller
> > not being setup correctly.
> 
> How did you come to this conclusion?  Is this a PCI USB controller or the
> on-chip peripheral?  I have Au1xxx boards were on-chip usb is
> required and is working fine.  There aren't any options to configuring
> on-chip USB interrupts on Au1xxx.  It could just as likely be a Linux kernel
> configuration problem.  We know there is something amiss with Au1xxx USB
> in big endian mode, but all LE boards should work fine.
>

I have seen USB working under BE mode in many instances.  (Acutally
that I have two that work.).  I don't think endianess is the issue.

I have seen "number assign failures" a couple of times before, and it
is all because interrupt not routed correctedly.  That is where "more than
likely" comes from.

Of course, I have only dealt with PCI USB controllers.  On-chip ones may
have another set of additional issues that I am not aware of.

Jun

From dan@embeddededge.com Fri Mar  7 21:55:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Mar 2003 21:55:23 +0000 (GMT)
Received: from [IPv6:::ffff:63.161.110.249] ([IPv6:::ffff:63.161.110.249]:62448
	"EHLO tibook.netx4.com") by linux-mips.org with ESMTP
	id <S8225253AbTCGVzW>; Fri, 7 Mar 2003 21:55:22 +0000
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 h27LsSf06478;
	Fri, 7 Mar 2003 16:54:28 -0500
Message-ID: <3E691514.7000907@embeddededge.com>
Date: Fri, 07 Mar 2003 16:54:28 -0500
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jun Sun <jsun@mvista.com>
CC: Bruno Randolf <br1@4g-systems.de>,
	Alexander Popov <s_popov@prosyst.bg>, linux-mips@linux-mips.org
Subject: Re: Mycable XXS board
References: <3E689267.3070509@prosyst.bg> <1047040846.10649.10.camel@adsl.pacbell.net> <200303071647.13275.br1@4g-systems.de> <20030307101354.N26071@mvista.com> <3E68FD21.5050402@embeddededge.com> <20030307133919.P26071@mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dan@embeddededge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1664
X-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
Content-Length: 749
Lines: 21

Jun Sun wrote:

> I have seen USB working under BE mode in many instances.  (Acutally
> that I have two that work.).  I don't think endianess is the issue.

Guess I wasn't clear :-)  That comment was directed toward the on-chip
peripheral version of the USB controller.

> Of course, I have only dealt with PCI USB controllers.  On-chip ones may
> have another set of additional issues that I am not aware of.

That's what I wanted to clarify.  Are we discussing one of the on-chip
peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
that was plugged into the Au1500.  In the case of the on-chip controller,
there aren't any interrupt routing problems, it's identical (and the same
code) on all Au1xxx boards.

Thanks.

	-- Dan


From baitisj@idealab.com Sat Mar  8 00:27:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Mar 2003 00:27:37 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:36294 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225206AbTCHA1g>;
	Sat, 8 Mar 2003 00:27:36 +0000
Received: (qmail 14755 invoked by uid 6180); 8 Mar 2003 00:27:33 -0000
Date: Fri, 7 Mar 2003 16:27:33 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: linux-mips@linux-mips.org
Subject: Re: Kernel Debugging on the DBAu1500
Message-ID: <20030307162733.Z20129@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030306185345.W20129@luca.pas.lab> <1047043427.30914.432.camel@zeus.mvista.com> <1047043677.6389.436.camel@zeus.mvista.com> <20030307123637.Y20129@luca.pas.lab> <1047069561.6389.505.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: <1047069561.6389.505.camel@zeus.mvista.com>; from ppopov@mvista.com on Fri, Mar 07, 2003 at 12:39:22PM -0800
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: 1665
X-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
Content-Length: 788
Lines: 29

Earlier I wrote:

> > Debugging seems to work great now! Thanks!

Well, not quite great. I've abandoned the old Monta Vista gdb-5.0 debugger
since it's been segfaulting.

I've tried building cross-debuggers from the current gdb release (5.3) and
from the March 3 CVS snapshot. Both lock up as soon as I 's'tep, just after
the GDB stub. (./configure --target=mipsel).

Perhaps someone could suggest a version of GDB that I should be using?

I also tried to disable CPU caching, but my kernel wouldn't boot.

Thanks again!

-Jeff


-- 
         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 Sat Mar  8 02:08:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Mar 2003 02:08:08 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:56774 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225206AbTCHCIH>;
	Sat, 8 Mar 2003 02:08:07 +0000
Received: (qmail 16216 invoked by uid 6180); 8 Mar 2003 02:08:04 -0000
Date: Fri, 7 Mar 2003 18:08:04 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: linux-mips <linux-mips@linux-mips.org>
Subject: Re: CardBus on DBAu1500 -- IRQ storm?
Message-ID: <20030307180804.A20129@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030228194820.Z20129@luca.pas.lab> <1046499358.12356.2.camel@adsl.pacbell.net> <20030303181421.C20129@luca.pas.lab>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030303181421.C20129@luca.pas.lab>; from baitisj@evolution.com on Mon, Mar 03, 2003 at 06:14:21PM -0800
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: 1666
X-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
Content-Length: 17746
Lines: 436

I belive I've made some progress tracking down this problem. The yenta_socket
driver launches the yenta_open_bh thread. Earlier, all CardBus and EXCA
interrupts were masked out.  Near line 650, yenta_open_bh tries to allocate an
interrupt line:

    if (!(socket->cb_irq) || request_irq(socket->cb_irq, yenta_interrupt,
                             SA_SHIRQ, socket->dev->name, socket)) {

request_irq, from linux/arch/mips/kernel/irq.c, enters a critical
section around line 873. startup() is invoked on the IRQ descriptor,
and then the critical section is exited with a call to 
spin_unlock_irqrestore(&desc->lock,flags);

As soon as this call is made, the kernel calls yenta_interrupt over and over.
Pardon my inexperience, but is this called an 'IRQ storm?'

yenta_interrupt: Entering    
yenta_events: Entering   
cb_readl: c0113eb0 0000 00000000
cb_writel: c0113eb0 0000 00000000
exca_readb: c0113eb0 0004 00     
exca_readb: c0113eb0 0003 00
yenta_events: Exiting (retval is 0)
yenta_interrupt: Exiting           
yenta_interrupt: Entering

etc etc

I've verified using our PCI analyzer that no interrupt events are transmitted
by the CardBus bridge, so this seems to be a software problem.

I'm going to continue to hunt this down, on the assumption that the kernel's
interrupt table is getting incorrect / corrupt data.  Suggestions are always
appreciated.

May all your CardBuses be happy!

-Jeff



On Mon, Mar 03, 2003 at 06:14:21PM -0800, Jeff Baitis wrote:
> Pete and others:
> 
> Thanks! I can access CardBus-enabled cards... but only if I plug the CardBus
> card into a PCI bridge device. 
> 
> For those who might be interested in hearing, here's my current status:
> 
> I tested the PCI->PCI bridge code by copying pb1500/pci_ops.c into
> db1x00/pci_ops.c. It seemed to work. Great!
> 
> After noticing that yenta_socket driver still locked up, I plugged a PCI-PCI
> bridge board in between the Au1500 dev board and the CardBus bridge. CardBus
> didn't work quite right, so I checked the PCI configuration registers on all
> devices on my PCI bus.
> 
> I noticed the PCI bridge device's SUBORDINATE_BUS value was set to 01, which
> is completely incorrect. It should have been at *least* 11, given that
> the CardBus bridge's SECONDARY_BUS register was set to 10. 
> 
> So, I used setpci to change the PCI bridge's SUBORDINATE_BUS to 1f. I started
> the CardBus services, and it seems that everything worked with CardBus cards.
> Eject, insert, and status all good -- and I can look at all the PCI
> configuration registers on the CardBus card.
> 
> ***
> 
> It seems like the issue with plugging in the CardBus bridge directly into
> PCI bus 0 (no PCI-PCI bridge) has to do with 16-bit CardBus support.
> I enabled debugging on yenta_socket, and here's some results. First, I present
> information *without* the PCI bridge, and then *with* PCI bridge.
> 
> 
> Without PCI bridge:
> 
> dmesg gives:
> 
>   Autoconfig PCI channel 0x8029fc38°°
>     Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
>     00:0c.0 Class 0104: 1103:0007 (rev 01)°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°                                                                
>             I/O at 0x00000300 [size=0x8]°°                         
>             I/O at 0x00000308 [size=0x4]
>             I/O at 0x00000310 [size=0x8]
>             I/O at 0x00000318 [size=0x4]
>             I/O at 0x00000400 [size=0x100]
>     00:0d.0 Class 0607: 104c:ac56°°°°°°°°°                         
>             Mem at 0x40000000 [size=0x1000]                        
>             Mem unavailable -- skipping°°°°                        
>             I/O at 0x00000500 [size=0x4]                           
>             Mem at 0x40001000 [size=0x1000]                        
>             Mem at 0x40002000 [size=0x1000]                        
>             Mem at 0x40003000 [size=0x1000]                        
>   
> lspci -v gives:
>   
>   00:0c.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0007
>   (rev 01)
>           Subsystem: Triones Technologies, Inc.: Unknown device 0001
>           Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 1
>           I/O ports at 0300 [size=8]
>           I/O ports at 0308 [size=4]
>           I/O ports at 0310 [size=8]
>           I/O ports at 0318 [size=4]
>           I/O ports at 0400 [size=256]
>           Expansion ROM at <unassigned> [disabled] [size=128K]   
>           Capabilities: [60] Power Management version 2          
>   
>   00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56 
>           Subsystem: Unknown device 5678:1234                    
>           Flags: bus master, medium devsel, latency 128, IRQ 1   
>           Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
>           Bus: primary=00, secondary=05, subordinate=00, sec-latency=0      
>           Memory window 0: 40001000-40002000 (prefetchable)      
>           I/O window 0: 00000000-00000003                        
>           I/O window 1: 00000000-00000003                        
>           16-bit legacy interface ports at 0001                  
> 
> 
> root@10.1.1.154:~# modprobe yenta_socket                       
> 
>   Linux Kernel Card Services 3.1.22
>     options:  [pci] [cardbus]°°°°°°
>   config_writel: c0112bd0 0044 00000000
>   config_writel: c0112bd0 0010 40000000
>   config_writew: c0112bd0 0004 0087°°°°
>   config_writeb: c0112bd0 000c 08°°
>   config_writeb: c0112bd0 000d a8
>   config_writel: c0112bd0 0018 b0000500
>   config_readw: c0112bd0 003e 0340°°°°°
>   config_writew: c0112bd0 003e 0580
>   exca_writeb: c0112bd0 001e 00°°°°
>   exca_writeb: c0112bd0 0016 00
>   cb_writel: c0112bd0 000c 00004000
>   cb_writel: c0112bd0 0004 00000000
>   config_readl: c0112bd0 001c 40001000
>   config_readl: c0112bd0 0020 40002000
>   config_readl: c0112bd0 0024 40003000
>   config_readl: c0112bd0 0028 00000000
>   config_writel: c0112bd0 0024 40400000
>   config_writel: c0112bd0 0028 407fffff
>   config_readl: c0112bd0 002c 00000000°
>   config_readl: c0112bd0 0030 00000000
>   config_writel: c0112bd0 002c 00004000
>   config_writel: c0112bd0 0030 000040ff
>   config_readl: c0112bd0 0034 00000000°
>   config_readl: c0112bd0 0038 00000000
>   config_writel: c0112bd0 0034 00004400
>   config_writel: c0112bd0 0038 000044ff
>   cb_readl: c0112bd0 0000 00000006°°°°°
>   cb_writel: c0112bd0 0000 00000006
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
>     ** following portion loops indefinitely **
>   cb_readl: c0112bd0 0000 00000000
>   cb_writel: c0112bd0 0000 00000000
>   exca_readb: c0112bd0 0004 00°°°°°
>   exca_readb: c0112bd0 0003 00
> 
> With PCI bridge:
> 
>   Autoconfig PCI channel 0x8029fc38°°
>   Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
>   00:0c.0 Class 0104: 1103:0007 (rev 01)°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
>           I/O at 0x00000300 [size=0x8]°°
>           I/O at 0x00000308 [size=0x4]
>           I/O at 0x00000310 [size=0x8]
>           I/O at 0x00000318 [size=0x4]
>           I/O at 0x00000400 [size=0x100]
>   00:0d.0 Class 0604: 1011:0022 (rev 02)
>           Bridge: primary=00, secondary=01
>   Scanning sub bus 01, I/O 0x00001000, Mem 0x40000000
>   01:07.0 Class 0607: 104c:ac56°°°°°°°°°°°°°°°°°°°°°°
>           Mem at 0x40000000 [size=0x1000]
>           Mem unavailable -- skipping°°°°
>           I/O at 0x00001000 [size=0x4]
>           Mem at 0x40001000 [size=0x1000]
>           Mem at 0x40002000 [size=0x1000]
>           Mem at 0x40003000 [size=0x1000]
>   Back to bus 00°°°°°°°°°°°°°°°°°°°°°°°°°
> 
> lspci -v gives:
>   
>   00:0c.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0007
>   (rev 01)
>           Subsystem: Triones Technologies, Inc.: Unknown device 0001
>           Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 1
>           I/O ports at 0300 [size=8]
>           I/O ports at 0308 [size=4]
>           I/O ports at 0310 [size=8]
>           I/O ports at 0318 [size=4]
>           I/O ports at 0400 [size=256]
>           Expansion ROM at <unassigned> [disabled] [size=128K]
>           Capabilities: [60] Power Management version 2
>   
>   00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 02)
>   (prog-if 00 [Normal decode])
>           Flags: bus master, medium devsel, latency 0
>           Bus: primary=00, secondary=01, subordinate=1f, sec-latency=0
>           I/O behind bridge: 00001000-00001fff     
>           Memory behind bridge: 40000000-400fffff  
>           Prefetchable memory behind bridge: 0000000000000000-0000000000000000
>   
>   01:07.0 CardBus bridge: Texas Instruments: Unknown device ac56
>           Subsystem: Unknown device 5678:1234      
>           Flags: bus master, medium devsel, latency 128, IRQ 255
>           Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
>           Bus: primary=00, secondary=10, subordinate=00, sec-latency=0
>           Memory window 0: 40001000-40002000 (prefetchable)
>           I/O window 0: 00000000-00000003
>           I/O window 1: 00000000-00000003
>           16-bit legacy interface ports at 0001    
> 
> root@10.1.1.154:~# modprobe yenta_socket                       
> 
>   Linux Kernel Card Services 3.1.22
>     options:  [pci] [cardbus]°°°°°°
>   config_writel: c0112bd0 0044 00000000
>   config_writel: c0112bd0 0010 40000000
>   config_writew: c0112bd0 0004 0087°°°°
>   config_writeb: c0112bd0 000c 08°°
>   config_writeb: c0112bd0 000d a8
>   config_writel: c0112bd0 0018 b0001000
>   config_readw: c0112bd0 003e 0340°°°°°
>   config_writew: c0112bd0 003e 0580
>   exca_writeb: c0112bd0 001e 00°°°°
>   exca_writeb: c0112bd0 0016 00
>   cb_writel: c0112bd0 000c 00004000
>   cb_writel: c0112bd0 0004 00000000
>   config_readl: c0112bd0 001c 40001000
>   config_readl: c0112bd0 0020 40002000
>   config_readl: c0112bd0 0024 40003000
>   config_readl: c0112bd0 0028 00000000
>   config_writel: c0112bd0 0024 10000000
>   config_writel: c0112bd0 0028 103fffff
>   config_readl: c0112bd0 002c 00000000°
>   config_readl: c0112bd0 0030 00000000
>   config_writel: c0112bd0 002c 00004000
>   config_writel: c0112bd0 0030 000040ff
>   config_readl: c0112bd0 0034 00000000°
>   config_readl: c0112bd0 0038 00000000
>   config_writel: c0112bd0 0034 00004400
>   config_writel: c0112bd0 0038 000044ff
>   config_readw: c0112bd0 003e 05c0°°°°°
>   cb_writel: c0112bd0 0000 ffffffff
>   cb_writel: c0112bd0 0004 00000001
>   exca_writeb: c0112bd0 0005 00°°°°
>   warning: end_irq 60 did not enable (6)
>   warning: end_irq 59 did not enable (6)
>   warning: end_irq 58 did not enable (6)
>   warning: end_irq 57 did not enable (6)
>   warning: end_irq 55 did not enable (6)
>   warning: end_irq 52 did not enable (6)
>   warning: end_irq 48 did not enable (6)
>   warning: end_irq 46 did not enable (6)
>   warning: end_irq 45 did not enable (6)
>   warning: end_irq 44 did not enable (6)
>   warning: end_irq 43 did not enable (6)
>   warning: end_irq 42 did not enable (6)
>   warning: end_irq 41 did not enable (6)
>   warning: end_irq 40 did not enable (6)
>   warning: end_irq 39 did not enable (6)
>   warning: end_irq 38 did not enable (6)
>   warning: end_irq 31 did not enable (6)
>   warning: end_irq 27 did not enable (6)
>   warning: end_irq 18 did not enable (6)
>   warning: end_irq 14 did not enable (6)
>   warning: end_irq 5 did not enable (6)°
>   warning: end_irq 4 did not enable (6)
>   warning: end_irq 2 did not enable (6)
>   warning: end_irq 1 did not enable (6)
>   warning: end_irq 60 did not enable (16)
>   warning: end_irq 59 did not enable (16)
>   warning: end_irq 58 did not enable (16)
>   warning: end_irq 57 did not enable (16)
>   warning: end_irq 55 did not enable (16)
>   warning: end_irq 52 did not enable (16)
>   warning: end_irq 48 did not enable (16)
>   warning: end_irq 46 did not enable (16)
>   warning: end_irq 45 did not enable (16)
>   warning: end_irq 44 did not enable (16)
>   warning: end_irq 43 did not enable (16)
>   warning: end_irq 42 did not enable (16)
>   warning: end_irq 41 did not enable (16)
>   warning: end_irq 40 did not enable (16)
>   warning: end_irq 39 did not enable (16)
>   warning: end_irq 38 did not enable (16)
>   warning: end_irq 27 did not enable (16)
>   warning: end_irq 18 did not enable (16)
>   warning: end_irq 5 did not enable (16)°
>   warning: end_irq 4 did not enable (16)
>   warning: end_irq 2 did not enable (16)
>   warning: end_irq 1 did not enable (16)
>   exca_writeb: c0112bd0 0005 31°°°°°°°°°
>   cb_writel: c0112bd0 000c 00000001
>   cb_writel: c0112bd0 0000 ffffffff
>   exca_writeb: c0112bd0 0005 91°°°°
>   cb_writel: c0112bd0 000c 00000001
>   cb_writel: c0112bd0 0000 ffffffff
>   exca_writeb: c0112bd0 0005 a1°°°°
>   cb_writel: c0112bd0 000c 00000001
>   cb_writel: c0112bd0 0000 ffffffff
>   exca_writeb: c0112bd0 0005 b1°°°°
>   cb_writel: c0112bd0 000c 00000001
>   cb_writel: c0112bd0 0000 ffffffff
>   cb_writel: c0112bd0 0004 00000000
>   exca_writeb: c0112bd0 0005 00°°°°
>   config_writew: c0112bd0 003e 0540
>   Yenta IRQ list 0000, PCI irq0°°°°
>   cb_readl: c0112bd0 0008 30000020
>   Socket status: 30000020°°°°°°°°°
>   config_writel: c0112bd0 0044 00000000
>   config_writel: c0112bd0 0010 40000000
>   config_writew: c0112bd0 0004 0087°°°°
>   config_writeb: c0112bd0 000c 08°°
>   config_writeb: c0112bd0 000d a8
>   config_writel: c0112bd0 0018 b0001000
>   config_readw: c0112bd0 003e 0540°°°°°
>   config_writew: c0112bd0 003e 0580
>   exca_writeb: c0112bd0 001e 00°°°°
>   exca_writeb: c0112bd0 0016 00
>   cb_writel: c0112bd0 000c 00004000
>   cb_readl: c0112bd0 0010 00000400°
>   cb_writel: c0112bd0 0010 00000000
>   config_readw: c0112bd0 003e 05c0°
>   cb_readl: c0112bd0 0008 30000820
>   exca_readb: c0112bd0 0003 00°°°°
>   exca_writeb: c0112bd0 0003 00
>   config_writew: c0112bd0 003e 0580
>   cb_writel: c0112bd0 0000 ffffffff
>   cb_writel: c0112bd0 0004 00000006
>   exca_readb: c0112bd0 0006 00°°°°°
>   exca_writew: c0112bd0 0008 0000
>   exca_writew: c0112bd0 000a 0001
>   exca_readb: c0112bd0 0007 00°°°
>   exca_writeb: c0112bd0 0007 00
>   exca_readb: c0112bd0 0006 00°
>   exca_writew: c0112bd0 000c 0000
>   exca_writew: c0112bd0 000e 0001
>   exca_readb: c0112bd0 0007 00°°°
>   exca_writeb: c0112bd0 0007 00
>   exca_readb: c0112bd0 0006 00°
>   exca_writeb: c0112bd0 0040 00
>   exca_writew: c0112bd0 0010 0000
>   exca_writew: c0112bd0 0012 0000
>   exca_writew: c0112bd0 0014 0000
>   ..... etc etc 
>   
> Thanks, all, for the information. I hope someone finds this useful!
> I'm gonna get remote kgdb goin' here, so I can hopefully fix the obnoxious
> infinite loop...
> 
> -Jeff
> 
> 
> On Fri, Feb 28, 2003 at 10:15:58PM -0800, Pete Popov wrote:
> > On Fri, 2003-02-28 at 19:48, Jeff Baitis wrote:
> > > Hey Pete and others!
> > > 
> > > I'm finally working on CardBus support on the DBAu1500. Just got acquainted
> > > with PCI today. :)
> > > 
> > > I decided that the first step is to plug in a PCI->PCI bridge, and try to see
> > > if it would work, which it did not. After winding around inside of the kernel,
> > > I finally arrived in arch/mips/au1000/db1x00/pci_ops.c:
> > > 
> > > Inside of config_access(unsigned char access_type, struct pci_dev *dev,
> > > unsigned char where, u32 * data), on line 97, a little surprise:
> > > 
> > >     if (bus != 0) {
> > >         *data = 0xffffffff;
> > >         return -1;
> > >     }
> > > 
> > > At this point, I concluded that I cannot traverse a PCI-PCI or CardBus bridge,
> > > since any devices behind the bridge will require Type 1 Configuration Cycles,
> > > and it seems that only Type 0 is currently supported.
> > > 
> > > I assume that I should add code to handle the case where I need to generate
> > > Type 1 Configuration Cycles inside of config_access. Pete, since you authored
> > > this code, I thought I'd quickly run this by you to make sure that I'm on
> > > track.
> > > 
> > > Thanks for your suggestions!
> > 
> > Take a look at arch/mips/au1000/pb1500/pci_ops.c for type 1 config
> > access. The patch was courtesy of David Gathright and apparently I
> > missed adding it in the db1500. Actually, we need to combine that code
> > because it's the same. Let me get through my eternal struggle of getting
> > the 36 bit patch applied (with Ralf's help I think a modified patch
> > should be ready this weekend) and then I'll worry about clean ups :)
> > 
> > Pete
> > 
> > 
> 
> -- 
>          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 ppopov@mvista.com Sat Mar  8 02:11:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Mar 2003 02:11:55 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:45813 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225206AbTCHCLy>;
	Sat, 8 Mar 2003 02:11:54 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA02298;
	Fri, 7 Mar 2003 18:11:48 -0800
Subject: Re: CardBus on DBAu1500 -- IRQ storm?
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com
Cc: linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <20030307180804.A20129@luca.pas.lab>
References: <20030228194820.Z20129@luca.pas.lab>
	 <1046499358.12356.2.camel@adsl.pacbell.net>
	 <20030303181421.C20129@luca.pas.lab>  <20030307180804.A20129@luca.pas.lab>
Content-Type: text/plain; charset=ISO-8859-1
Organization: MontaVista Software
Message-Id: <1047089512.30919.587.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 07 Mar 2003 18:11:53 -0800
Content-Transfer-Encoding: 8bit
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: 1667
X-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
Content-Length: 18472
Lines: 433

On Fri, 2003-03-07 at 18:08, Jeff Baitis wrote:
> I belive I've made some progress tracking down this problem. The yenta_socket
> driver launches the yenta_open_bh thread. Earlier, all CardBus and EXCA
> interrupts were masked out.  Near line 650, yenta_open_bh tries to allocate an
> interrupt line:
> 
>     if (!(socket->cb_irq) || request_irq(socket->cb_irq, yenta_interrupt,
>                              SA_SHIRQ, socket->dev->name, socket)) {
> 
> request_irq, from linux/arch/mips/kernel/irq.c, enters a critical
> section around line 873. startup() is invoked on the IRQ descriptor,
> and then the critical section is exited with a call to 
> spin_unlock_irqrestore(&desc->lock,flags);
> 
> As soon as this call is made, the kernel calls yenta_interrupt over and over.
> Pardon my inexperience, but is this called an 'IRQ storm?'

Check to see what yenta_interrupt is doing. Is it acknowledging the
interrupt?

Pete

> yenta_interrupt: Entering    
> yenta_events: Entering   
> cb_readl: c0113eb0 0000 00000000
> cb_writel: c0113eb0 0000 00000000
> exca_readb: c0113eb0 0004 00     
> exca_readb: c0113eb0 0003 00
> yenta_events: Exiting (retval is 0)
> yenta_interrupt: Exiting           
> yenta_interrupt: Entering
> 
> etc etc
> 
> I've verified using our PCI analyzer that no interrupt events are transmitted
> by the CardBus bridge, so this seems to be a software problem.
> 
> I'm going to continue to hunt this down, on the assumption that the kernel's
> interrupt table is getting incorrect / corrupt data.  Suggestions are always
> appreciated.
> 
> May all your CardBuses be happy!
> 
> -Jeff
> 
> 
> 
> On Mon, Mar 03, 2003 at 06:14:21PM -0800, Jeff Baitis wrote:
> > Pete and others:
> > 
> > Thanks! I can access CardBus-enabled cards... but only if I plug the CardBus
> > card into a PCI bridge device. 
> > 
> > For those who might be interested in hearing, here's my current status:
> > 
> > I tested the PCI->PCI bridge code by copying pb1500/pci_ops.c into
> > db1x00/pci_ops.c. It seemed to work. Great!
> > 
> > After noticing that yenta_socket driver still locked up, I plugged a PCI-PCI
> > bridge board in between the Au1500 dev board and the CardBus bridge. CardBus
> > didn't work quite right, so I checked the PCI configuration registers on all
> > devices on my PCI bus.
> > 
> > I noticed the PCI bridge device's SUBORDINATE_BUS value was set to 01, which
> > is completely incorrect. It should have been at *least* 11, given that
> > the CardBus bridge's SECONDARY_BUS register was set to 10. 
> > 
> > So, I used setpci to change the PCI bridge's SUBORDINATE_BUS to 1f. I started
> > the CardBus services, and it seems that everything worked with CardBus cards.
> > Eject, insert, and status all good -- and I can look at all the PCI
> > configuration registers on the CardBus card.
> > 
> > ***
> > 
> > It seems like the issue with plugging in the CardBus bridge directly into
> > PCI bus 0 (no PCI-PCI bridge) has to do with 16-bit CardBus support.
> > I enabled debugging on yenta_socket, and here's some results. First, I present
> > information *without* the PCI bridge, and then *with* PCI bridge.
> > 
> > 
> > Without PCI bridge:
> > 
> > dmesg gives:
> > 
> >   Autoconfig PCI channel 0x8029fc38°°
> >     Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
> >     00:0c.0 Class 0104: 1103:0007 (rev 01)°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°                                                                
> >             I/O at 0x00000300 [size=0x8]°°                         
> >             I/O at 0x00000308 [size=0x4]
> >             I/O at 0x00000310 [size=0x8]
> >             I/O at 0x00000318 [size=0x4]
> >             I/O at 0x00000400 [size=0x100]
> >     00:0d.0 Class 0607: 104c:ac56°°°°°°°°°                         
> >             Mem at 0x40000000 [size=0x1000]                        
> >             Mem unavailable -- skipping°°°°                        
> >             I/O at 0x00000500 [size=0x4]                           
> >             Mem at 0x40001000 [size=0x1000]                        
> >             Mem at 0x40002000 [size=0x1000]                        
> >             Mem at 0x40003000 [size=0x1000]                        
> >   
> > lspci -v gives:
> >   
> >   00:0c.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0007
> >   (rev 01)
> >           Subsystem: Triones Technologies, Inc.: Unknown device 0001
> >           Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 1
> >           I/O ports at 0300 [size=8]
> >           I/O ports at 0308 [size=4]
> >           I/O ports at 0310 [size=8]
> >           I/O ports at 0318 [size=4]
> >           I/O ports at 0400 [size=256]
> >           Expansion ROM at <unassigned> [disabled] [size=128K]   
> >           Capabilities: [60] Power Management version 2          
> >   
> >   00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56 
> >           Subsystem: Unknown device 5678:1234                    
> >           Flags: bus master, medium devsel, latency 128, IRQ 1   
> >           Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
> >           Bus: primary=00, secondary=05, subordinate=00, sec-latency=0      
> >           Memory window 0: 40001000-40002000 (prefetchable)      
> >           I/O window 0: 00000000-00000003                        
> >           I/O window 1: 00000000-00000003                        
> >           16-bit legacy interface ports at 0001                  
> > 
> > 
> > root@10.1.1.154:~# modprobe yenta_socket                       
> > 
> >   Linux Kernel Card Services 3.1.22
> >     options:  [pci] [cardbus]°°°°°°
> >   config_writel: c0112bd0 0044 00000000
> >   config_writel: c0112bd0 0010 40000000
> >   config_writew: c0112bd0 0004 0087°°°°
> >   config_writeb: c0112bd0 000c 08°°
> >   config_writeb: c0112bd0 000d a8
> >   config_writel: c0112bd0 0018 b0000500
> >   config_readw: c0112bd0 003e 0340°°°°°
> >   config_writew: c0112bd0 003e 0580
> >   exca_writeb: c0112bd0 001e 00°°°°
> >   exca_writeb: c0112bd0 0016 00
> >   cb_writel: c0112bd0 000c 00004000
> >   cb_writel: c0112bd0 0004 00000000
> >   config_readl: c0112bd0 001c 40001000
> >   config_readl: c0112bd0 0020 40002000
> >   config_readl: c0112bd0 0024 40003000
> >   config_readl: c0112bd0 0028 00000000
> >   config_writel: c0112bd0 0024 40400000
> >   config_writel: c0112bd0 0028 407fffff
> >   config_readl: c0112bd0 002c 00000000°
> >   config_readl: c0112bd0 0030 00000000
> >   config_writel: c0112bd0 002c 00004000
> >   config_writel: c0112bd0 0030 000040ff
> >   config_readl: c0112bd0 0034 00000000°
> >   config_readl: c0112bd0 0038 00000000
> >   config_writel: c0112bd0 0034 00004400
> >   config_writel: c0112bd0 0038 000044ff
> >   cb_readl: c0112bd0 0000 00000006°°°°°
> >   cb_writel: c0112bd0 0000 00000006
> >   exca_readb: c0112bd0 0004 00°°°°°
> >   exca_readb: c0112bd0 0003 00
> >   cb_readl: c0112bd0 0000 00000000
> >   cb_writel: c0112bd0 0000 00000000
> >   exca_readb: c0112bd0 0004 00°°°°°
> >   exca_readb: c0112bd0 0003 00
> >   cb_readl: c0112bd0 0000 00000000
> >   cb_writel: c0112bd0 0000 00000000
> >   exca_readb: c0112bd0 0004 00°°°°°
> >   exca_readb: c0112bd0 0003 00
> >   cb_readl: c0112bd0 0000 00000000
> >   cb_writel: c0112bd0 0000 00000000
> >   exca_readb: c0112bd0 0004 00°°°°°
> >   exca_readb: c0112bd0 0003 00
> >   cb_readl: c0112bd0 0000 00000000
> >   cb_writel: c0112bd0 0000 00000000
> >   exca_readb: c0112bd0 0004 00°°°°°
> >   exca_readb: c0112bd0 0003 00
> >   cb_readl: c0112bd0 0000 00000000
> >   cb_writel: c0112bd0 0000 00000000
> >   exca_readb: c0112bd0 0004 00°°°°°
> >   exca_readb: c0112bd0 0003 00
> >     ** following portion loops indefinitely **
> >   cb_readl: c0112bd0 0000 00000000
> >   cb_writel: c0112bd0 0000 00000000
> >   exca_readb: c0112bd0 0004 00°°°°°
> >   exca_readb: c0112bd0 0003 00
> > 
> > With PCI bridge:
> > 
> >   Autoconfig PCI channel 0x8029fc38°°
> >   Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
> >   00:0c.0 Class 0104: 1103:0007 (rev 01)°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
> >           I/O at 0x00000300 [size=0x8]°°
> >           I/O at 0x00000308 [size=0x4]
> >           I/O at 0x00000310 [size=0x8]
> >           I/O at 0x00000318 [size=0x4]
> >           I/O at 0x00000400 [size=0x100]
> >   00:0d.0 Class 0604: 1011:0022 (rev 02)
> >           Bridge: primary=00, secondary=01
> >   Scanning sub bus 01, I/O 0x00001000, Mem 0x40000000
> >   01:07.0 Class 0607: 104c:ac56°°°°°°°°°°°°°°°°°°°°°°
> >           Mem at 0x40000000 [size=0x1000]
> >           Mem unavailable -- skipping°°°°
> >           I/O at 0x00001000 [size=0x4]
> >           Mem at 0x40001000 [size=0x1000]
> >           Mem at 0x40002000 [size=0x1000]
> >           Mem at 0x40003000 [size=0x1000]
> >   Back to bus 00°°°°°°°°°°°°°°°°°°°°°°°°°
> > 
> > lspci -v gives:
> >   
> >   00:0c.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0007
> >   (rev 01)
> >           Subsystem: Triones Technologies, Inc.: Unknown device 0001
> >           Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 1
> >           I/O ports at 0300 [size=8]
> >           I/O ports at 0308 [size=4]
> >           I/O ports at 0310 [size=8]
> >           I/O ports at 0318 [size=4]
> >           I/O ports at 0400 [size=256]
> >           Expansion ROM at <unassigned> [disabled] [size=128K]
> >           Capabilities: [60] Power Management version 2
> >   
> >   00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 02)
> >   (prog-if 00 [Normal decode])
> >           Flags: bus master, medium devsel, latency 0
> >           Bus: primary=00, secondary=01, subordinate=1f, sec-latency=0
> >           I/O behind bridge: 00001000-00001fff     
> >           Memory behind bridge: 40000000-400fffff  
> >           Prefetchable memory behind bridge: 0000000000000000-0000000000000000
> >   
> >   01:07.0 CardBus bridge: Texas Instruments: Unknown device ac56
> >           Subsystem: Unknown device 5678:1234      
> >           Flags: bus master, medium devsel, latency 128, IRQ 255
> >           Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
> >           Bus: primary=00, secondary=10, subordinate=00, sec-latency=0
> >           Memory window 0: 40001000-40002000 (prefetchable)
> >           I/O window 0: 00000000-00000003
> >           I/O window 1: 00000000-00000003
> >           16-bit legacy interface ports at 0001    
> > 
> > root@10.1.1.154:~# modprobe yenta_socket                       
> > 
> >   Linux Kernel Card Services 3.1.22
> >     options:  [pci] [cardbus]°°°°°°
> >   config_writel: c0112bd0 0044 00000000
> >   config_writel: c0112bd0 0010 40000000
> >   config_writew: c0112bd0 0004 0087°°°°
> >   config_writeb: c0112bd0 000c 08°°
> >   config_writeb: c0112bd0 000d a8
> >   config_writel: c0112bd0 0018 b0001000
> >   config_readw: c0112bd0 003e 0340°°°°°
> >   config_writew: c0112bd0 003e 0580
> >   exca_writeb: c0112bd0 001e 00°°°°
> >   exca_writeb: c0112bd0 0016 00
> >   cb_writel: c0112bd0 000c 00004000
> >   cb_writel: c0112bd0 0004 00000000
> >   config_readl: c0112bd0 001c 40001000
> >   config_readl: c0112bd0 0020 40002000
> >   config_readl: c0112bd0 0024 40003000
> >   config_readl: c0112bd0 0028 00000000
> >   config_writel: c0112bd0 0024 10000000
> >   config_writel: c0112bd0 0028 103fffff
> >   config_readl: c0112bd0 002c 00000000°
> >   config_readl: c0112bd0 0030 00000000
> >   config_writel: c0112bd0 002c 00004000
> >   config_writel: c0112bd0 0030 000040ff
> >   config_readl: c0112bd0 0034 00000000°
> >   config_readl: c0112bd0 0038 00000000
> >   config_writel: c0112bd0 0034 00004400
> >   config_writel: c0112bd0 0038 000044ff
> >   config_readw: c0112bd0 003e 05c0°°°°°
> >   cb_writel: c0112bd0 0000 ffffffff
> >   cb_writel: c0112bd0 0004 00000001
> >   exca_writeb: c0112bd0 0005 00°°°°
> >   warning: end_irq 60 did not enable (6)
> >   warning: end_irq 59 did not enable (6)
> >   warning: end_irq 58 did not enable (6)
> >   warning: end_irq 57 did not enable (6)
> >   warning: end_irq 55 did not enable (6)
> >   warning: end_irq 52 did not enable (6)
> >   warning: end_irq 48 did not enable (6)
> >   warning: end_irq 46 did not enable (6)
> >   warning: end_irq 45 did not enable (6)
> >   warning: end_irq 44 did not enable (6)
> >   warning: end_irq 43 did not enable (6)
> >   warning: end_irq 42 did not enable (6)
> >   warning: end_irq 41 did not enable (6)
> >   warning: end_irq 40 did not enable (6)
> >   warning: end_irq 39 did not enable (6)
> >   warning: end_irq 38 did not enable (6)
> >   warning: end_irq 31 did not enable (6)
> >   warning: end_irq 27 did not enable (6)
> >   warning: end_irq 18 did not enable (6)
> >   warning: end_irq 14 did not enable (6)
> >   warning: end_irq 5 did not enable (6)°
> >   warning: end_irq 4 did not enable (6)
> >   warning: end_irq 2 did not enable (6)
> >   warning: end_irq 1 did not enable (6)
> >   warning: end_irq 60 did not enable (16)
> >   warning: end_irq 59 did not enable (16)
> >   warning: end_irq 58 did not enable (16)
> >   warning: end_irq 57 did not enable (16)
> >   warning: end_irq 55 did not enable (16)
> >   warning: end_irq 52 did not enable (16)
> >   warning: end_irq 48 did not enable (16)
> >   warning: end_irq 46 did not enable (16)
> >   warning: end_irq 45 did not enable (16)
> >   warning: end_irq 44 did not enable (16)
> >   warning: end_irq 43 did not enable (16)
> >   warning: end_irq 42 did not enable (16)
> >   warning: end_irq 41 did not enable (16)
> >   warning: end_irq 40 did not enable (16)
> >   warning: end_irq 39 did not enable (16)
> >   warning: end_irq 38 did not enable (16)
> >   warning: end_irq 27 did not enable (16)
> >   warning: end_irq 18 did not enable (16)
> >   warning: end_irq 5 did not enable (16)°
> >   warning: end_irq 4 did not enable (16)
> >   warning: end_irq 2 did not enable (16)
> >   warning: end_irq 1 did not enable (16)
> >   exca_writeb: c0112bd0 0005 31°°°°°°°°°
> >   cb_writel: c0112bd0 000c 00000001
> >   cb_writel: c0112bd0 0000 ffffffff
> >   exca_writeb: c0112bd0 0005 91°°°°
> >   cb_writel: c0112bd0 000c 00000001
> >   cb_writel: c0112bd0 0000 ffffffff
> >   exca_writeb: c0112bd0 0005 a1°°°°
> >   cb_writel: c0112bd0 000c 00000001
> >   cb_writel: c0112bd0 0000 ffffffff
> >   exca_writeb: c0112bd0 0005 b1°°°°
> >   cb_writel: c0112bd0 000c 00000001
> >   cb_writel: c0112bd0 0000 ffffffff
> >   cb_writel: c0112bd0 0004 00000000
> >   exca_writeb: c0112bd0 0005 00°°°°
> >   config_writew: c0112bd0 003e 0540
> >   Yenta IRQ list 0000, PCI irq0°°°°
> >   cb_readl: c0112bd0 0008 30000020
> >   Socket status: 30000020°°°°°°°°°
> >   config_writel: c0112bd0 0044 00000000
> >   config_writel: c0112bd0 0010 40000000
> >   config_writew: c0112bd0 0004 0087°°°°
> >   config_writeb: c0112bd0 000c 08°°
> >   config_writeb: c0112bd0 000d a8
> >   config_writel: c0112bd0 0018 b0001000
> >   config_readw: c0112bd0 003e 0540°°°°°
> >   config_writew: c0112bd0 003e 0580
> >   exca_writeb: c0112bd0 001e 00°°°°
> >   exca_writeb: c0112bd0 0016 00
> >   cb_writel: c0112bd0 000c 00004000
> >   cb_readl: c0112bd0 0010 00000400°
> >   cb_writel: c0112bd0 0010 00000000
> >   config_readw: c0112bd0 003e 05c0°
> >   cb_readl: c0112bd0 0008 30000820
> >   exca_readb: c0112bd0 0003 00°°°°
> >   exca_writeb: c0112bd0 0003 00
> >   config_writew: c0112bd0 003e 0580
> >   cb_writel: c0112bd0 0000 ffffffff
> >   cb_writel: c0112bd0 0004 00000006
> >   exca_readb: c0112bd0 0006 00°°°°°
> >   exca_writew: c0112bd0 0008 0000
> >   exca_writew: c0112bd0 000a 0001
> >   exca_readb: c0112bd0 0007 00°°°
> >   exca_writeb: c0112bd0 0007 00
> >   exca_readb: c0112bd0 0006 00°
> >   exca_writew: c0112bd0 000c 0000
> >   exca_writew: c0112bd0 000e 0001
> >   exca_readb: c0112bd0 0007 00°°°
> >   exca_writeb: c0112bd0 0007 00
> >   exca_readb: c0112bd0 0006 00°
> >   exca_writeb: c0112bd0 0040 00
> >   exca_writew: c0112bd0 0010 0000
> >   exca_writew: c0112bd0 0012 0000
> >   exca_writew: c0112bd0 0014 0000
> >   ..... etc etc 
> >   
> > Thanks, all, for the information. I hope someone finds this useful!
> > I'm gonna get remote kgdb goin' here, so I can hopefully fix the obnoxious
> > infinite loop...
> > 
> > -Jeff
> > 
> > 
> > On Fri, Feb 28, 2003 at 10:15:58PM -0800, Pete Popov wrote:
> > > On Fri, 2003-02-28 at 19:48, Jeff Baitis wrote:
> > > > Hey Pete and others!
> > > > 
> > > > I'm finally working on CardBus support on the DBAu1500. Just got acquainted
> > > > with PCI today. :)
> > > > 
> > > > I decided that the first step is to plug in a PCI->PCI bridge, and try to see
> > > > if it would work, which it did not. After winding around inside of the kernel,
> > > > I finally arrived in arch/mips/au1000/db1x00/pci_ops.c:
> > > > 
> > > > Inside of config_access(unsigned char access_type, struct pci_dev *dev,
> > > > unsigned char where, u32 * data), on line 97, a little surprise:
> > > > 
> > > >     if (bus != 0) {
> > > >         *data = 0xffffffff;
> > > >         return -1;
> > > >     }
> > > > 
> > > > At this point, I concluded that I cannot traverse a PCI-PCI or CardBus bridge,
> > > > since any devices behind the bridge will require Type 1 Configuration Cycles,
> > > > and it seems that only Type 0 is currently supported.
> > > > 
> > > > I assume that I should add code to handle the case where I need to generate
> > > > Type 1 Configuration Cycles inside of config_access. Pete, since you authored
> > > > this code, I thought I'd quickly run this by you to make sure that I'm on
> > > > track.
> > > > 
> > > > Thanks for your suggestions!
> > > 
> > > Take a look at arch/mips/au1000/pb1500/pci_ops.c for type 1 config
> > > access. The patch was courtesy of David Gathright and apparently I
> > > missed adding it in the db1500. Actually, we need to combine that code
> > > because it's the same. Let me get through my eternal struggle of getting
> > > the 36 bit patch applied (with Ralf's help I think a modified patch
> > > should be ready this weekend) and then I'll worry about clean ups :)
> > > 
> > > Pete
> > > 
> > > 
> > 
> > -- 
> >          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 drow@false.org Sat Mar  8 04:43:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Mar 2003 04:43:47 +0000 (GMT)
Received: from crack.them.org ([IPv6:::ffff:65.125.64.184]:61673 "EHLO
	crack.them.org") by linux-mips.org with ESMTP id <S8225200AbTCHEnr>;
	Sat, 8 Mar 2003 04:43:47 +0000
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 18rY4m-0000vZ-00; Sat, 08 Mar 2003 00:44:56 -0600
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 18rWBQ-0001Dr-00; Fri, 07 Mar 2003 23:43:40 -0500
Date: Fri, 7 Mar 2003 23:43:40 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Jeff Baitis <baitisj@evolution.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel Debugging on the DBAu1500
Message-ID: <20030308044340.GA4675@nevyn.them.org>
References: <20030306185345.W20129@luca.pas.lab> <1047043427.30914.432.camel@zeus.mvista.com> <1047043677.6389.436.camel@zeus.mvista.com> <20030307123637.Y20129@luca.pas.lab> <1047069561.6389.505.camel@zeus.mvista.com> <20030307162733.Z20129@luca.pas.lab>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030307162733.Z20129@luca.pas.lab>
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: 1668
X-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
Content-Length: 839
Lines: 23

On Fri, Mar 07, 2003 at 04:27:33PM -0800, Jeff Baitis wrote:
> Earlier I wrote:
> 
> > > Debugging seems to work great now! Thanks!
> 
> Well, not quite great. I've abandoned the old Monta Vista gdb-5.0 debugger
> since it's been segfaulting.

Wow, that's from a pretty old product...

> I've tried building cross-debuggers from the current gdb release (5.3) and
> from the March 3 CVS snapshot. Both lock up as soon as I 's'tep, just after
> the GDB stub. (./configure --target=mipsel).
> 
> Perhaps someone could suggest a version of GDB that I should be using?

Those should both work correctly; they do here.  Try configuring it for
the right target (mipsel-linux) and seeing if that helps?  I'd be
surprised if it made a difference though.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ralf@linux-mips.net Sat Mar  8 12:49:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Mar 2003 12:50:00 +0000 (GMT)
Received: from p508B4DD5.dip.t-dialin.net ([IPv6:::ffff:80.139.77.213]:37569
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225200AbTCHMt7>; Sat, 8 Mar 2003 12:49:59 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h28CntR23246
	for linux-mips@linux-mips.org; Sat, 8 Mar 2003 13:49:55 +0100
Date: Sat, 8 Mar 2003 13:49:55 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Struct sigaction cleanup
Message-ID: <20030308134955.A22922@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
Return-Path: <ralf@linux-mips.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: 1669
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 10618
Lines: 319

I'm working on overhauling the signal code.  Part 1 is just some cleanup.
As historic garbage we've got two unused fields in struct sigaction:

struct sigaction {
        unsigned int    sa_flags;
        __sighandler_t  sa_handler;
        sigset_t        sa_mask;
        void            (*sa_restorer)(void);
        int             sa_resv[1];     /* reserved */
};

Actually the size of sa_mask is supposed to be variable and therefore
sa_mask has to be the last member of struct sigaction.  Further no known
libc implementation making use of sa_restorer.  So here's a patch to
remove the two fields.  This little change btw. delivers 3% speedup of
signal delivery.

Note there is no binary compatibility issue.  Glibc's contains it's own
definitions of struct sigaction and the kernel's struct sigaction.  That
means existing glibc binaries will simply pass a too large kernel struct
sigaction to the kernel which will just ignore the extra fields.

Comments?

  Ralf

Index: arch/mips/kernel/irixsig.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/irixsig.c,v
retrieving revision 1.20.2.1
diff -u -r1.20.2.1 irixsig.c
--- arch/mips/kernel/irixsig.c	5 Aug 2002 23:53:33 -0000	1.20.2.1
+++ arch/mips/kernel/irixsig.c	8 Mar 2003 12:17:51 -0000
@@ -116,7 +116,8 @@
 	regs->regs[5] = 0; /* XXX sigcode XXX */
 	regs->regs[6] = regs->regs[29] = sp;
 	regs->regs[7] = (unsigned long) ka->sa.sa_handler;
-	regs->regs[25] = regs->cp0_epc = (unsigned long) ka->sa.sa_restorer;
+	regs->regs[25] = regs->cp0_epc = (unsigned long) ka->sa_restorer;
+
 	return;
 
 segv_and_exit:
@@ -407,7 +408,7 @@
 		 * value for all invocations of sigaction.  Will have to
 		 * investigate.  POSIX POSIX, die die die...
 		 */
-		new_ka.sa.sa_restorer = trampoline;
+		new_ka.sa_restorer = trampoline;
 	}
 
 /* XXX Implement SIG_SETMASK32 for IRIX compatibility */
Index: arch/mips/kernel/signal.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/signal.c,v
retrieving revision 1.39.2.10
diff -u -r1.39.2.10 signal.c
--- arch/mips/kernel/signal.c	4 Nov 2002 19:39:56 -0000	1.39.2.10
+++ arch/mips/kernel/signal.c	8 Mar 2003 12:17:52 -0000
@@ -148,7 +148,6 @@
 		err |= __get_user(new_ka.sa.sa_handler, &act->sa_handler);
 		err |= __get_user(new_ka.sa.sa_flags, &act->sa_flags);
 		err |= __get_user(mask, &act->sa_mask.sig[0]);
-		err |= __get_user(new_ka.sa.sa_restorer, &act->sa_restorer);
 		if (err)
 			return -EFAULT;
 
@@ -166,7 +165,6 @@
                 err |= __put_user(0, &oact->sa_mask.sig[1]);
                 err |= __put_user(0, &oact->sa_mask.sig[2]);
                 err |= __put_user(0, &oact->sa_mask.sig[3]);
-		err |= __put_user(old_ka.sa.sa_restorer, &oact->sa_restorer);
                 if (err)
 			return -EFAULT;
 	}
@@ -400,23 +398,15 @@
 	if (!access_ok(VERIFY_WRITE, frame, sizeof (*frame)))
 		goto give_sigsegv;
 
-	/* Set up to return from userspace.  If provided, use a stub already
-	   in userspace.  */
-	if (ka->sa.sa_flags & SA_RESTORER)
-		regs->regs[31] = (unsigned long) ka->sa.sa_restorer;
-	else {
-		/*
-		 * Set up the return code ...
-		 *
-		 *         li      v0, __NR_sigreturn
-		 *         syscall
-		 */
-		err |= __put_user(0x24020000 + __NR_sigreturn,
-		                  frame->sf_code + 0);
-		err |= __put_user(0x0000000c                 ,
-		                  frame->sf_code + 1);
-		flush_cache_sigtramp((unsigned long) frame->sf_code);
-	}
+	/*
+	 * Set up the return code ...
+	 *
+	 *         li      v0, __NR_sigreturn
+	 *         syscall
+	 */
+	err |= __put_user(0x24020000 + __NR_sigreturn, frame->sf_code + 0);
+	err |= __put_user(0x0000000c                 , frame->sf_code + 1);
+	flush_cache_sigtramp((unsigned long) frame->sf_code);
 
 	err |= setup_sigcontext(regs, &frame->sf_sc);
 	err |= __copy_to_user(&frame->sf_mask, set, sizeof(*set));
@@ -463,23 +453,15 @@
 	if (!access_ok(VERIFY_WRITE, frame, sizeof (*frame)))
 		goto give_sigsegv;
 
-	/* Set up to return from userspace.  If provided, use a stub already
-	   in userspace.  */
-	if (ka->sa.sa_flags & SA_RESTORER)
-		regs->regs[31] = (unsigned long) ka->sa.sa_restorer;
-	else {
-		/*
-		 * Set up the return code ...
-		 *
-		 *         li      v0, __NR_rt_sigreturn
-		 *         syscall
-		 */
-		err |= __put_user(0x24020000 + __NR_rt_sigreturn,
-		                  frame->rs_code + 0);
-		err |= __put_user(0x0000000c                 ,
-		                  frame->rs_code + 1);
-		flush_cache_sigtramp((unsigned long) frame->rs_code);
-	}
+	/*
+	 * Set up the return code ...
+	 *
+	 *         li      v0, __NR_rt_sigreturn
+	 *         syscall
+	 */
+	err |= __put_user(0x24020000 + __NR_rt_sigreturn, frame->rs_code + 0);
+	err |= __put_user(0x0000000c                    , frame->rs_code + 1);
+	flush_cache_sigtramp((unsigned long) frame->rs_code);
 
 	/* Create siginfo.  */
 	err |= copy_siginfo_to_user(&frame->rs_info, info);
Index: arch/mips64/kernel/signal32.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/signal32.c,v
retrieving revision 1.20.2.11
diff -u -r1.20.2.11 signal32.c
--- arch/mips64/kernel/signal32.c	4 Nov 2002 19:39:56 -0000	1.20.2.11
+++ arch/mips64/kernel/signal32.c	8 Mar 2003 12:17:57 -0000
@@ -51,8 +51,6 @@
 	unsigned int		sa_flags;
 	__sighandler32_t	sa_handler;
 	sigset32_t		sa_mask;
-	unsigned int		sa_restorer;
-	int			sa_resv[1];     /* reserved */
 };
 
 /* IRIX compatible stack_t  */
@@ -189,8 +187,6 @@
 		                  &act->sa_handler);
 		err |= __get_user(new_ka.sa.sa_flags, &act->sa_flags);
 		err |= __get_user(mask, &act->sa_mask.sig[0]);
-		err |= __get_user((u32)(u64)new_ka.sa.sa_restorer,
-		                   &act->sa_restorer);
 		if (err)
 			return -EFAULT;
 
@@ -209,8 +205,6 @@
                 err |= __put_user(0, &oact->sa_mask.sig[1]);
                 err |= __put_user(0, &oact->sa_mask.sig[2]);
                 err |= __put_user(0, &oact->sa_mask.sig[3]);
-		err |= __put_user((u32)(u64)old_ka.sa.sa_restorer,
-		                  &oact->sa_restorer);
                 if (err)
 			return -EFAULT;
 	}
@@ -509,23 +503,15 @@
 	if (!access_ok(VERIFY_WRITE, frame, sizeof (*frame)))
 		goto give_sigsegv;
 
-	/* Set up to return from userspace.  If provided, use a stub already
-	   in userspace.  */
-	if (ka->sa.sa_flags & SA_RESTORER)
-		regs->regs[31] = (unsigned long) ka->sa.sa_restorer;
-	else {
-		/*
-		 * Set up the return code ...
-		 *
-		 *         li      v0, __NR_O32_sigreturn
-		 *         syscall
-		 */
-		err |= __put_user(0x24020000 + __NR_O32_sigreturn,
-		                  frame->sf_code + 0);
-		err |= __put_user(0x0000000c                 ,
-		                  frame->sf_code + 1);
-		flush_cache_sigtramp((unsigned long) frame->sf_code);
-	}
+	/*
+	 * Set up the return code ...
+	 *
+	 *         li      v0, __NR_O32_sigreturn
+	 *         syscall
+	 */
+	err |= __put_user(0x24020000 + __NR_O32_sigreturn, frame->sf_code + 0);
+	err |= __put_user(0x0000000c                     , frame->sf_code + 1);
+	flush_cache_sigtramp((unsigned long) frame->sf_code);
 
 	err |= setup_sigcontext(regs, &frame->sf_sc);
 	err |= __copy_to_user(&frame->sf_mask, set, sizeof(*set));
@@ -575,21 +561,15 @@
 
 	/* Set up to return from userspace.  If provided, use a stub already
 	   in userspace.  */
-	if (ka->sa.sa_flags & SA_RESTORER)
-		regs->regs[31] = (unsigned long) ka->sa.sa_restorer;
-	else {
-		/*
-		 * Set up the return code ...
-		 *
-		 *         li      v0, __NR_O32_rt_sigreturn
-		 *         syscall
-		 */
-		err |= __put_user(0x24020000 + __NR_O32_rt_sigreturn,
-		                  frame->rs_code + 0);
-		err |= __put_user(0x0000000c                 ,
-		                  frame->rs_code + 1);
-		flush_cache_sigtramp((unsigned long) frame->rs_code);
-	}
+	/*
+	 * Set up the return code ...
+	 *
+	 *         li      v0, __NR_O32_rt_sigreturn
+	 *         syscall
+	 */
+	err |= __put_user(0x24020000 + __NR_O32_rt_sigreturn, frame->rs_code + 0);
+	err |= __put_user(0x0000000c                      , frame->rs_code + 1);
+	flush_cache_sigtramp((unsigned long) frame->rs_code);
 
 	/* Convert (siginfo_t -> siginfo_t32) and copy to user. */
 	err |= copy_siginfo_to_user32(&frame->rs_info, info);
@@ -812,11 +792,14 @@
 
 	if (set && get_user (s, set))
 		return -EFAULT;
+
 	set_fs (KERNEL_DS);
 	ret = sys_sigprocmask(how, set ? &s : NULL, oset ? &s : NULL);
 	set_fs (old_fs);
+
 	if (!ret && oset && put_user (s, oset))
 		return -EFAULT;
+
 	return ret;
 }
 
@@ -857,8 +840,6 @@
 		err |= __get_user((u32)(u64)new_sa.sa.sa_handler,
 		                  &act->sa_handler);
 		err |= __get_user(new_sa.sa.sa_flags, &act->sa_flags);
-		err |= __get_user((u32)(u64)new_sa.sa.sa_restorer,
-		                  &act->sa_restorer);
 		err |= get_sigset(&new_sa.sa.sa_mask, &act->sa_mask);
 		if (err)
 			return -EFAULT;
@@ -875,8 +856,6 @@
 		err |= __put_user((u32)(u64)old_sa.sa.sa_handler,
 		                   &oact->sa_handler);
 		err |= __put_user(old_sa.sa.sa_flags, &oact->sa_flags);
-		err |= __put_user((u32)(u64)old_sa.sa.sa_restorer,
-		                  &oact->sa_restorer);
 		err |= put_sigset(&old_sa.sa.sa_mask, &oact->sa_mask);
 		if (err)
 			return -EFAULT;
Index: include/asm-mips/signal.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/signal.h,v
retrieving revision 1.9.2.1
diff -u -r1.9.2.1 signal.h
--- include/asm-mips/signal.h	5 Aug 2002 23:53:37 -0000	1.9.2.1
+++ include/asm-mips/signal.h	8 Mar 2003 12:18:40 -0000
@@ -9,6 +9,7 @@
 #ifndef _ASM_SIGNAL_H
 #define _ASM_SIGNAL_H
 
+#include <linux/config.h>
 #include <linux/types.h>
 
 #define _NSIG		128
@@ -130,12 +131,13 @@
 	unsigned int	sa_flags;
 	__sighandler_t	sa_handler;
 	sigset_t	sa_mask;
-	void		(*sa_restorer)(void);
-	int		sa_resv[1];	/* reserved */
 };
 
 struct k_sigaction {
 	struct sigaction sa;
+#ifdef CONFIG_BINFMT_IRIX
+	void		(*sa_restorer)(void);
+#endif
 };
 
 /* IRIX compatible stack_t  */
Index: include/asm-mips64/signal.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/signal.h,v
retrieving revision 1.4.2.4
diff -u -r1.4.2.4 signal.h
--- include/asm-mips64/signal.h	27 Jan 2003 19:19:13 -0000	1.4.2.4
+++ include/asm-mips64/signal.h	8 Mar 2003 12:18:45 -0000
@@ -139,8 +139,6 @@
 	unsigned int	sa_flags;
 	__sighandler_t	sa_handler;
 	sigset_t	sa_mask;
-	void		(*sa_restorer)(void);
-	int		sa_resv[1];	/* reserved */
 };
 
 struct k_sigaction {

From tingashilo@yahoo.com Sun Mar  9 07:24:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Mar 2003 07:24:43 +0000 (GMT)
Received: from web41511.mail.yahoo.com ([IPv6:::ffff:66.218.93.94]:44394 "HELO
	web41511.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225073AbTCIHYm>; Sun, 9 Mar 2003 07:24:42 +0000
Message-ID: <20030309072432.19644.qmail@web41511.mail.yahoo.com>
Received: from [81.218.92.190] by web41511.mail.yahoo.com via HTTP; Sat, 08 Mar 2003 23:24:32 PST
Date: Sat, 8 Mar 2003 23:24:32 -0800 (PST)
From: Tinga Shilo <tingashilo@yahoo.com>
Subject: Re: static variables access and gp
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
In-Reply-To: <20030306094034.A26071@mvista.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <tingashilo@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: 1670
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tingashilo@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1048
Lines: 38

Thx. Got it.
Any other solution to speed up the access to this
variable ? It's location never changes from kernel
init to shutdown if I haven't made that clear.

--- Jun Sun <jsun@mvista.com> wrote:
> On Wed, Mar 05, 2003 at 11:30:17PM -0800, Tinga
> Shilo wrote:
> > Hi,
> > I am implementing a kernel mechanism which is 
> > very performance oriented. Along my long critical
> > path,
> > there is a static variable that needs to be
> accessed
> > quite a few times. This variable is a structure
> which
> > is approximately 60 bytes big.
> > In there any way I can "convince" my kernel
> (compiled
> > with gcc) to access this variable using gp ?
> > Is gp usually used for this purpose in mips-linux
> ?
> > Can it be ?
> >
> 
> No.  gp is used by kernel to hold current process in
> 2.4
> and current thread in 2.5.  Don't mess with it
> unless
> you are absolutely sure what you are doing.
> 
> Jun


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

From ralf@linux-mips.net Sun Mar  9 13:46:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Mar 2003 13:46:45 +0000 (GMT)
Received: from p508B4B98.dip.t-dialin.net ([IPv6:::ffff:80.139.75.152]:33756
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225073AbTCINqo>; Sun, 9 Mar 2003 13:46:44 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h29DkQ627754;
	Sun, 9 Mar 2003 14:46:26 +0100
Date: Sun, 9 Mar 2003 14:46:26 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Tinga Shilo <tingashilo@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: static variables access and gp
Message-ID: <20030309144625.A27651@linux-mips.org>
References: <20030306073017.65521.qmail@web41509.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030306073017.65521.qmail@web41509.mail.yahoo.com>; from tingashilo@yahoo.com on Wed, Mar 05, 2003 at 11:30:17PM -0800
Return-Path: <ralf@linux-mips.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: 1671
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 915
Lines: 25

On Wed, Mar 05, 2003 at 11:30:17PM -0800, Tinga Shilo wrote:

> I am implementing a kernel mechanism which is 
> very performance oriented. Along my long critical
> path,
> there is a static variable that needs to be accessed
> quite a few times. This variable is a structure which
> is approximately 60 bytes big.
> In there any way I can "convince" my kernel (compiled
> with gcc) to access this variable using gp ?
> Is gp usually used for this purpose in mips-linux ?
> Can it be ?
> 
> A while ago I saw a small discussion here about usage
> of gp for static variables, but it didn't provide
> any definite answers.

Use a pointer to the that structure.  Gcc will keep this pointer in a
registers wherever it considers that sensible.  Any reference to members
of the structure can then be made with just a single instruction.

$28 is used for the current pointer so only suitable for per-process
data.

  Ralf

From ralf@linux-mips.net Sun Mar  9 13:59:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Mar 2003 13:59:57 +0000 (GMT)
Received: from p508B4B98.dip.t-dialin.net ([IPv6:::ffff:80.139.75.152]:49884
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225213AbTCIN74>; Sun, 9 Mar 2003 13:59:56 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h29DxjH28095;
	Sun, 9 Mar 2003 14:59:45 +0100
Date: Sun, 9 Mar 2003 14:59:45 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: HG <henri@broadbandnetdevices.com>, linux-mips@linux-mips.org
Subject: Re: mips-linux-ld related question
Message-ID: <20030309145945.B27651@linux-mips.org>
References: <000f01c2e4c6$65818600$0400a8c0@amdk62400> <20030307181720.GA5795@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030307181720.GA5795@nevyn.them.org>; from dan@debian.org on Fri, Mar 07, 2003 at 01:17:20PM -0500
Return-Path: <ralf@linux-mips.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: 1672
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 845
Lines: 19

On Fri, Mar 07, 2003 at 01:17:20PM -0500, Daniel Jacobowitz wrote:

> > I installed the binutils-mips-linux-2.13.1.i386.rpm and
> > egcs-mips-linux-1.1.2-4.i386.rpm from the linux-mips ftp site on a caldera
> > distribution 3.11 linux box to crosscompile a 2.4 kernel.
> > no error message while compiling , i get the following error while linking :
> >  mips-linux-ld: target elf32-bigmips not found
> > 
> > is there some env variable or path that I missed that needs to be set ????
> 
> Fix the kernel; if it references elf32-bigmips your source is too old. 
> It should be tradbigmips with those tools.

True - almost.  We still have two systems, the Baget and the EV64120
explicitly referencing elf32-bigmips, so I guess he was using one of these
two systems.  I just fixed that in CVS - IRIX ELF really should be dead
since years.

  Ralf

From anemo@mba.ocn.ne.jp Mon Mar 10 03:19:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 03:19:43 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:46882
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225229AbTCJDTn>; Mon, 10 Mar 2003 03:19:43 +0000
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 10 Mar 2003 03:19:41 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP
	id 00F62B46B; Mon, 10 Mar 2003 12:19:33 +0900 (JST)
Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP
	id MAA62084; Mon, 10 Mar 2003 12:19:33 +0900 (JST)
Date: Mon, 10 Mar 2003 12:24:45 +0900 (JST)
Message-Id: <20030310.122445.112283172.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
Subject: [PATCH] kbd_controller_present (remove kbd-no.c)
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: 1674
X-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
Content-Length: 2047
Lines: 63

I found that "kbd_controller_present" macro was introduced in 2.4.20
pc_keyb.c.  How about this patch?  kbd-no.c is not needed anymore.


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	Fri Feb 14 09:41:21 2003
+++ linux.new/arch/mips/kernel/setup.c	Mon Mar 10 12:04:34 2003
@@ -70,7 +70,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	Mon Mar 10 12:03:26 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/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	Mon Mar 10 12:03:44 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()
---

There are another good side effects.  With this patch, following error
messages (and some delay in boot sequence) go away.

> initialize_kbd: Keyboard failed self test
> keyboard: Timeout - AT keyboard not present?(ed)
> keyboard: Timeout - AT keyboard not present?(f4)

Currently these messages are displayed when CONFIG_PC_KEYB is enabled
and kbd_ops is no_kbd_ops.

---
Atsushi Nemoto
The old PGP key (ID B6D728B1) has been revoked.  New key ID is 2874D52F.

From yoichi_yuasa@montavista.co.jp Mon Mar 10 03:41:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 03:41:57 +0000 (GMT)
Received: from sonicwall.montavista.co.jp ([IPv6:::ffff:202.232.97.131]:22568
	"EHLO yuubin.montavista.co.jp") by linux-mips.org with ESMTP
	id <S8225229AbTCJDl4>; Mon, 10 Mar 2003 03:41:56 +0000
Received: from pudding.montavista.co.jp ([10.200.0.40])
	by yuubin.montavista.co.jp (8.12.5/8.12.5) with SMTP id h2A3pl44024847;
	Mon, 10 Mar 2003 12:51:49 +0900
Date: Mon, 10 Mar 2003 12:41:45 +0900
From: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
To: ralf@linux-mips.org
Cc: yoichi_yuasa@montavista.co.jp, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [patch] simulate_ll and simulate_sc(resend)
Message-Id: <20030310124145.0e290228.yoichi_yuasa@montavista.co.jp>
In-Reply-To: <20030306165351.35ffbaa7.yoichi_yuasa@montavista.co.jp>
References: <20030303192137.34d21352.yoichi_yuasa@montavista.co.jp>
	<20030304213605.A17855@linux-mips.org>
	<20030306165351.35ffbaa7.yoichi_yuasa@montavista.co.jp>
Organization: MontaVista Software Japan, Inc.
X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Mon__10_Mar_2003_12:41:45_+0900_0829c610"
Return-Path: <yoichi_yuasa@montavista.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1675
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yoichi_yuasa@montavista.co.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 3997
Lines: 154

This is a multi-part message in MIME format.

--Multipart_Mon__10_Mar_2003_12:41:45_+0900_0829c610
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Ralf,

In addition to your change, this patch is still more required.
I tested simulate_ll/sc operation with this patch, it doesn't have a problem.

Please apply this patch.

Thanks,

Yoichi

On Thu, 6 Mar 2003 16:53:51 +0900
Yoichi Yuasa <yoichi_yuasa@montavista.co.jp> wrote:

> Hi Ralf,
> 
> On Tue, 4 Mar 2003 21:36:05 +0100
> Ralf Baechle <ralf@linux-mips.org> wrote:
> 
> > On Mon, Mar 03, 2003 at 07:21:37PM +0900, Yoichi Yuasa wrote:
> > 
> > > I found a bug in simulate_ll and simulate_sc.
> > > The board that uses ll/sc emulation is not started.
> > > 
> > > When send_sig in these, in order not to operate the value of EPC correctly,
> > > simulate_* happens continuously.
> > > 
> > > The previous patches were not perfect, I changed more.
> > > Please apply these patches to CVS tree.
> > 
> > As previously mentioned there were some problems with your fix, so I
> > wrote an alternative fix which is attached below.  It's untested because
> > I don't have any ll/sc-less test platform.
> 
> I tested ll/sc simulate.
> Furthermore, the following patch is also needed.
> 
> Thanks,
> 
> Yoichi
> 
> diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c
> --- linux.orig/arch/mips/kernel/traps.c Wed Mar  5 12:05:00 2003
> +++ linux/arch/mips/kernel/traps.c      Thu Mar  6 16:37:40 2003
> @@ -173,6 +173,7 @@
>         }
>         if (ll_bit == 0 || ll_task != current) {
>                 regs->regs[reg] = 0;
> +               compute_return_epc(regs);
>                 return;
>         }
> 
> 
> 
> > 
> >   Ralf
> > 
> > Index: arch/mips/kernel/traps.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/kernel/traps.c,v
> > retrieving revision 1.99.2.41
> > diff -u -r1.99.2.41 traps.c
> > --- arch/mips/kernel/traps.c	10 Feb 2003 22:50:48 -0000	1.99.2.41
> > +++ arch/mips/kernel/traps.c	4 Mar 2003 20:32:10 -0000
> > @@ -134,13 +134,14 @@
> >  		ll_bit = 0;
> >  	}
> >  	ll_task = current;
> > +
> >  	regs->regs[(opcode & RT) >> 16] = value;
> >  
> >  	compute_return_epc(regs);
> >  	return;
> >  
> >  sig:
> > -	send_sig(signal, current, 1);
> > +	force_sig(signal, current);
> >  }
> >  
> >  static inline void simulate_sc(struct pt_regs *regs, unsigned int opcode)
> > @@ -172,19 +173,21 @@
> >  	}
> >  	if (ll_bit == 0 || ll_task != current) {
> >  		regs->regs[reg] = 0;
> > -		goto sig;
> > +		return;
> >  	}
> >  
> > -	if (put_user(regs->regs[reg], vaddr))
> > +	if (put_user(regs->regs[reg], vaddr)) {
> >  		signal = SIGSEGV;
> > -	else
> > -		regs->regs[reg] = 1;
> > +		goto sig;
> > +	}
> > +
> > +	regs->regs[reg] = 1;
> >  
> >  	compute_return_epc(regs);
> >  	return;
> >  
> >  sig:
> > -	send_sig(signal, current, 1);
> > +	force_sig(signal, current);
> >  }
> >  
> >  /*
> > 
> > 
> 
> 
> -- 
> Yoichi Yuasa
> Montavista Software Japan, Inc.
> e-mail: yoichi_yuasa@montavista.co.jp
> http://www.montavista.co.jp
> PHONE: 03-5469-8840 FAX: 03-5469-8841
> 
> 


-- 
Yoichi Yuasa
Montavista Software Japan, Inc.
e-mail: yoichi_yuasa@montavista.co.jp
http://www.montavista.co.jp
PHONE: 03-5469-8840 FAX: 03-5469-8841

--Multipart_Mon__10_Mar_2003_12:41:45_+0900_0829c610
Content-Type: text/plain;
 name="simulate_llsc.diff"
Content-Disposition: attachment;
 filename="simulate_llsc.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c
--- linux.orig/arch/mips/kernel/traps.c	Wed Mar  5 12:05:00 2003
+++ linux/arch/mips/kernel/traps.c	Thu Mar  6 16:37:40 2003
@@ -173,6 +173,7 @@
 	}
 	if (ll_bit == 0 || ll_task != current) {
 		regs->regs[reg] = 0;
+		compute_return_epc(regs);
 		return;
 	}
 

--Multipart_Mon__10_Mar_2003_12:41:45_+0900_0829c610--

From tk@mycable.de Mon Mar 10 08:24:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 08:24:48 +0000 (GMT)
Received: from [IPv6:::ffff:62.116.167.108] ([IPv6:::ffff:62.116.167.108]:49557
	"EHLO oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8225194AbTCJIYr>; Mon, 10 Mar 2003 08:24:47 +0000
Received: from mycable.de (pD9527A5A.dip.t-dialin.net [217.82.122.90])
	(authenticated bits=0)
	by oricom4.internetx.de (8.12.8/8.12.8) with ESMTP id h2A8Lcbm015430;
	Mon, 10 Mar 2003 09:21:39 +0100
Message-ID: <3E6C4C69.10904@mycable.de>
Date: Mon, 10 Mar 2003 09:27:21 +0100
From: Tiemo Krueger - mycable GmbH <tk@mycable.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
CC: s_popov@prosyst.bg
Subject: Re: Mycable XXS board
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <tk@mycable.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1676
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tk@mycable.de
Precedence: bulk
X-list: linux-mips
Content-Length: 829
Lines: 33

Hi Alexander,

next to the things written by Bruno and the rest I wanted to add:

The processor-architecture is MIPS32, this is what you can choose in the 
config.
The Pb1500 or Db1500 is a good point to start with.

Tiemo

 >Hi all,
 >
 >Has anyone used the kernel on a Mycable XXS board ( it has Alchemy 
au1500 )...
 >What CPU type should I choose for the au1500? R5000? Sorry for the 
lame question but I haven't used MIPS-based boards and I know nothing 
baout the CPU...
 >
 >Regards,
>-- 
 >Alexander Popov

-- 
-------------------------------------------------------
Tiemo Krueger       Tel:  +49 48 73 90 19 86
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: tk@mycable.de

Public Kryptographic Key is available on request
-------------------------------------------------------



From tk@mycable.de Mon Mar 10 08:31:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 08:31:19 +0000 (GMT)
Received: from [IPv6:::ffff:62.116.167.108] ([IPv6:::ffff:62.116.167.108]:14742
	"EHLO oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8225194AbTCJIbS>; Mon, 10 Mar 2003 08:31:18 +0000
Received: from mycable.de (pD9527A5A.dip.t-dialin.net [217.82.122.90])
	(authenticated bits=0)
	by oricom4.internetx.de (8.12.8/8.12.8) with ESMTP id h2A8SAbm015724;
	Mon, 10 Mar 2003 09:28:10 +0100
Message-ID: <3E6C4DF1.3020304@mycable.de>
Date: Mon, 10 Mar 2003 09:33:53 +0100
From: Tiemo Krueger - mycable GmbH <tk@mycable.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
CC: s_popov@prosyst.bg
Subject: Re: Mycable XXS board
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <tk@mycable.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1677
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tk@mycable.de
Precedence: bulk
X-list: linux-mips
Content-Length: 833
Lines: 34

Hi Alexander,

next to the things written by Bruno and the rest I wanted to add:

The processor-architecture is MIPS32, this is what you can choose in the
config.
The Pb1500 or Db1500 is a good point to start with.

Tiemo

  >Hi all,
  >
  >Has anyone used the kernel on a Mycable XXS board ( it has Alchemy
au1500 )...
  >What CPU type should I choose for the au1500? R5000? Sorry for the
lame question but I haven't used MIPS-based boards and I know nothing
baout the CPU...
  >
  >Regards,
 >--
  >Alexander Popov

-- 
-------------------------------------------------------
Tiemo Krueger       Tel:  +49 48 73 90 19 86
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: tk@mycable.de

Public Kryptographic Key is available on request
-------------------------------------------------------




From avinash.s@inspiretech.com Mon Mar 10 08:53:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 08:53:11 +0000 (GMT)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:40076
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8225194AbTCJIxK>; Mon, 10 Mar 2003 08:53:10 +0000
Received: from mail.inspiretech.com (mail.inspiretech.com [150.1.1.1])
	by smtp.inspirtek.com (8.12.5/8.12.5) with ESMTP id h2A94icY031512
	for <linux-mips@linux-mips.org>; Mon, 10 Mar 2003 14:34:48 +0530
Message-Id: <200303100904.h2A94icY031512@smtp.inspirtek.com>
Received: from WorldClient [150.1.1.1] by inspiretech.com [150.1.1.1]
	with SMTP (MDaemon.v3.5.7.R)
	for <linux-mips@linux-mips.org>; Mon, 10 Mar 2003 14:17:52 +0530
Date: Mon, 10 Mar 2003 14:17:51 +0530
From: "Avinash S." <avinash.s@inspiretech.com>
To: "linux" <linux-mips@linux-mips.org>
Subject: what to choose in kernel config
X-Mailer: WorldClient Standard 3.5.0e
X-MDRemoteIP: 150.1.1.1
X-Return-Path: avinash.s@inspiretech.com
X-MDaemon-Deliver-To: linux-mips@linux-mips.org
Return-Path: <avinash.s@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: 1678
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: avinash.s@inspiretech.com
Precedence: bulk
X-list: linux-mips
Content-Length: 219
Lines: 9

I have an eval board of the IDT 332 processor. Id like to know what CPU 
and machine selection are closest to this processor or where can i get a 
kernel that will support this processor.

thanks in advance 

Avinash



From s_popov@prosyst.bg Mon Mar 10 09:35:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 09:35:54 +0000 (GMT)
Received: from ns.prosyst.bg ([IPv6:::ffff:212.95.166.35]:57103 "HELO
	ns.prosyst.bg") by linux-mips.org with SMTP id <S8225194AbTCJJfx>;
	Mon, 10 Mar 2003 09:35:53 +0000
Received: (qmail 18975 invoked from network); 10 Mar 2003 09:35:49 -0000
Received: from gw.prosyst.bg (HELO prosyst.bg) (212.95.166.50)
  by ns.prosyst.bg with SMTP; 10 Mar 2003 09:35:49 -0000
Message-ID: <3E6C5DE2.6090403@prosyst.bg>
Date: Mon, 10 Mar 2003 11:41:54 +0200
From: Alexander Popov <s_popov@prosyst.bg>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: linux-mips@linux-mips.org
Subject: Re: Mycable XXS board
References: <3E6C4DF1.3020304@mycable.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
To: unlisted-recipients:; (no To-header on input)
Return-Path: <s_popov@prosyst.bg>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1679
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: s_popov@prosyst.bg
Precedence: bulk
X-list: linux-mips
Content-Length: 431
Lines: 18

Thanks to all that helped me up with that...

I managed to compile the kernel (2.4.21). There were some problems with unresolved symbols, but when 
I fixed the support to only pb1500 and removed the MTD CFI support , the framebuffer and a few other 
things it worked.

Thanks againg guys.

Best Regards,

-- 
Alexander Popov
RTOS&JVM Team Leader
Prosyst Bulgaria, Inc.
email: s_popov@prosyst.bg
mobile: +35987663193
icq: 29207350


From ralf@linux-mips.net Mon Mar 10 13:07:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 13:07:36 +0000 (GMT)
Received: from p508B7812.dip.t-dialin.net ([IPv6:::ffff:80.139.120.18]:40092
	"EHLO p508B7812.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225247AbTCJNHf>; Mon, 10 Mar 2003 13:07:35 +0000
Received: from onda.linux-mips.net ([IPv6:::ffff:192.168.169.2]:19847 "EHLO
	dea.linux-mips.net") by ralf.linux-mips.org with ESMTP
	id <S869610AbTCJNCH>; Mon, 10 Mar 2003 14:02:07 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2ACtVL26908;
	Mon, 10 Mar 2003 13:55:31 +0100
Date: Mon, 10 Mar 2003 13:55:31 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: Kip Walker <kwalker@broadcom.com>, linux-mips@linux-mips.org
Subject: Re: [pathch] kernel/sched.c bogon?
Message-ID: <20030310135531.B2206@linux-mips.org>
References: <3E67EF64.152CFC6C@broadcom.com> <20030306174001.K26071@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: <20030306174001.K26071@mvista.com>; from jsun@mvista.com on Thu, Mar 06, 2003 at 05:40:01PM -0800
Return-Path: <ralf@linux-mips.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: 1680
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 590
Lines: 18

On Thu, Mar 06, 2003 at 05:40:01PM -0800, Jun Sun wrote:

> I reported this bug last May.  Apparently it is still not
> taken up-stream.   Ralf, why don't we fix it here and push
> it up from you?
> 
> BTW, this bug actually has effect on real-time performance under
> preemptible kernel.

< = 2.4.x preemptible kernel is OPP.

>  It can delay the execution of the highest
> priority real-time process from execution up to 1 jiffy.

Quite a number of users get_cycles() in the kernel assume it to return a
64-bit number.  I guess we'll have to fake a 64-bit counter in software ...

  Ralf

From Jon_Burgess@eur.3com.com Mon Mar 10 13:42:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 13:42:58 +0000 (GMT)
Received: from ip-161-71-171-238.corp-eur.3com.com ([IPv6:::ffff:161.71.171.238]:19617
	"EHLO columba.www.eur.3com.com") by linux-mips.org with ESMTP
	id <S8225206AbTCJNm5>; Mon, 10 Mar 2003 13:42:57 +0000
Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50])
	by columba.www.eur.3com.com  with ESMTP id h2ADiT4J025494;
	Mon, 10 Mar 2003 13:44:30 GMT
Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206])
	by toucana.eur.3com.com  with SMTP id h2ADiXw01314;
	Mon, 10 Mar 2003 13:44:33 GMT
Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 80256CE5.003944AF ; Mon, 10 Mar 2003 10:25:31 +0000
X-Lotus-FromDomain: 3COM
From: "Jon Burgess" <Jon_Burgess@eur.3com.com>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Message-ID: <80256CE5.00390ADA.00@notesmta.eur.3com.com>
Date: Mon, 10 Mar 2003 10:22:56 +0000
Subject: Re: Struct sigaction cleanup
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Return-Path: <Jon_Burgess@eur.3com.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1681
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Jon_Burgess@eur.3com.com
Precedence: bulk
X-list: linux-mips
Content-Length: 751
Lines: 25



Ralf Wrote:
> Further no known libc implementation making use of sa_restorer.

I don't know if this is relevant, but Linus recently tried
changing the sa_restorer behaviour in the linux-2.5 kernel and
later had to back out the change. The following lines are from
recent changelogs:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0301.1/0344.html
Linux-2.5.55:
Move x86 signal handler return stub to the vsyscall page, and stop
    honoring the SA_RESTORER information.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0301.1/1884.html
Linux-2.5.57:
Re-instate the SA_RESTORER functionality, since it seems that some
    programs still depend on it and in fact do install a different
    signal restorer than the standard kernel version.


     Jon



From ralf@linux-mips.net Mon Mar 10 14:09:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 14:09:10 +0000 (GMT)
Received: from p508B7812.dip.t-dialin.net ([IPv6:::ffff:80.139.120.18]:18824
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225206AbTCJOJJ>; Mon, 10 Mar 2003 14:09:09 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2AE93228176;
	Mon, 10 Mar 2003 15:09:03 +0100
Date: Mon, 10 Mar 2003 15:09:03 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jon Burgess <Jon_Burgess@eur.3com.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Struct sigaction cleanup
Message-ID: <20030310150903.A28104@linux-mips.org>
References: <80256CE5.00390ADA.00@notesmta.eur.3com.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: <80256CE5.00390ADA.00@notesmta.eur.3com.com>; from Jon_Burgess@eur.3com.com on Mon, Mar 10, 2003 at 10:22:56AM +0000
Return-Path: <ralf@linux-mips.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: 1682
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1041
Lines: 25

On Mon, Mar 10, 2003 at 10:22:56AM +0000, Jon Burgess wrote:

> > Further no known libc implementation making use of sa_restorer.
> 
> I don't know if this is relevant, but Linus recently tried
> changing the sa_restorer behaviour in the linux-2.5 kernel and
> later had to back out the change. The following lines are from
> recent changelogs:
> 
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0301.1/0344.html
> Linux-2.5.55:
> Move x86 signal handler return stub to the vsyscall page, and stop
>     honoring the SA_RESTORER information.
> 
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0301.1/1884.html
> Linux-2.5.57:
> Re-instate the SA_RESTORER functionality, since it seems that some
>     programs still depend on it and in fact do install a different
>     signal restorer than the standard kernel version.

Doesn't look relevant to us because installing requires custom assembler
code for each architecture or other non-portable constructs.  It seems
nothing on MIPS was ever actually using sa_restorer or SA_RESTORER.

  Ralf

From jsun@mvista.com Mon Mar 10 17:59:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 17:59:39 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:15100 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225211AbTCJR7j>;
	Mon, 10 Mar 2003 17:59:39 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h2AHx7P10368;
	Mon, 10 Mar 2003 09:59:07 -0800
Date: Mon, 10 Mar 2003 09:59:07 -0800
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Kip Walker <kwalker@broadcom.com>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [pathch] kernel/sched.c bogon?
Message-ID: <20030310095907.U26071@mvista.com>
References: <3E67EF64.152CFC6C@broadcom.com> <20030306174001.K26071@mvista.com> <20030310135531.B2206@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: <20030310135531.B2206@linux-mips.org>; from ralf@linux-mips.org on Mon, Mar 10, 2003 at 01:55:31PM +0100
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1683
X-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
Content-Length: 980
Lines: 27

On Mon, Mar 10, 2003 at 01:55:31PM +0100, Ralf Baechle wrote:
> On Thu, Mar 06, 2003 at 05:40:01PM -0800, Jun Sun wrote:
> 
> > I reported this bug last May.  Apparently it is still not
> > taken up-stream.   Ralf, why don't we fix it here and push
> > it up from you?
> > 
> > BTW, this bug actually has effect on real-time performance under
> > preemptible kernel.
> 
> < = 2.4.x preemptible kernel is OPP.
> 
> >  It can delay the execution of the highest
> > priority real-time process from execution up to 1 jiffy.
> 
> Quite a number of users get_cycles() in the kernel assume it to return a
> 64-bit number.  I guess we'll have to fake a 64-bit counter in software ...
>

Whether we fake 64-bit or not, oldest_idle is declared as cycles_t.  
So comparing it with (cycles_t)-1 should be always be correct.  And it
actually makes a correct C program. :-)

I don't see any possible reason for rejecting the change.  My previous
report is probably just lost in the noise.

Jun

From ranjanp@efi.com Mon Mar 10 21:09:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Mar 2003 21:09:20 +0000 (GMT)
Received: from mail2.efi.com ([IPv6:::ffff:192.68.228.89]:57102 "HELO
	fcexgw02.efi.internal") by linux-mips.org with SMTP
	id <S8225073AbTCJVJU>; Mon, 10 Mar 2003 21:09:20 +0000
Received: from 10.3.12.13 by fcexgw02.efi.internal (InterScan E-Mail VirusWall NT); Mon, 10 Mar 2003 13:09:12 -0800
Received: by fcexbh02.efi.com with Internet Mail Service (5.5.2656.59)
	id <DRDG30L1>; Mon, 10 Mar 2003 13:09:12 -0800
Message-ID: <D9F6B9DABA4CAE4B92850252C52383AB07968235@ex-eng-corp.efi.com>
From: Ranjan Parthasarathy <ranjanp@efi.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: syscal handler query
Date: Mon, 10 Mar 2003 13:09:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
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: 1684
X-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
Content-Length: 807
Lines: 29

The syscall handler code does an STI at the very begining in handle_sys. Can
someone explain why that is needed. I am trying to debug a problem in my
mips kernel with compressed ramdisks and I was using something like

cli();
gunzip();
sti();

in the compressed ramdisk code and I could still see the timer interrupts
being raised while gunzip was uncompressing. I suspected the STI in the
syscall handler code. Removing the STI fixes the problem. The
RESTORE_SP_AND_RET will reset the interrupts so I do not see why the STI is
needed, but I am wary of any potential disastrous side effects of removing
the STI.

The code is as follows - from arch/mips/kernel/scall_o32.S

NESTED(handle_sys,PT_SIZE,sp)
	.set 	noat
	SAVE_SOME
	STI
            *
            *

Any help would be appreciated.

Thanks

Ranjan

From yoichi_yuasa@montavista.co.jp Tue Mar 11 07:18:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Mar 2003 07:18:22 +0000 (GMT)
Received: from sonicwall.montavista.co.jp ([IPv6:::ffff:202.232.97.131]:60089
	"EHLO yuubin.montavista.co.jp") by linux-mips.org with ESMTP
	id <S8225199AbTCKHSV>; Tue, 11 Mar 2003 07:18:21 +0000
Received: from pudding.montavista.co.jp ([10.200.0.40])
	by yuubin.montavista.co.jp (8.12.5/8.12.5) with SMTP id h2B7SYIH003670;
	Tue, 11 Mar 2003 16:28:35 +0900
Date: Tue, 11 Mar 2003 16:18:10 +0900
From: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yoichi_yuasa@montavista.co.jp, linux-mips@linux-mips.org
Subject: [patch] Clean up the IRQ number in VR41xx
Message-Id: <20030311161810.6819792f.yoichi_yuasa@montavista.co.jp>
Organization: MontaVista Software Japan, Inc.
X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Tue__11_Mar_2003_16:18:10_+0900_08238278"
Return-Path: <yoichi_yuasa@montavista.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1685
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yoichi_yuasa@montavista.co.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 12559
Lines: 378

This is a multi-part message in MIME format.

--Multipart_Tue__11_Mar_2003_16:18:10_+0900_08238278
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Ralf,

I cleaned up the IRQ numbers in VR4100 series.

The IRQ number of VR4100 series were defined by various places.
This change defined the IRQ number in common(header file).

Please apply this patch.

Thanks,

Yoichi

--Multipart_Tue__11_Mar_2003_16:18:10_+0900_08238278
Content-Type: text/plain;
 name="vr41xx-irq-v24.diff"
Content-Disposition: attachment;
 filename="vr41xx-irq-v24.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux.orig/arch/mips/vr41xx/common/giu.c	Mon Feb 24 11:00:04 2003
+++ linux/arch/mips/vr41xx/common/giu.c	Tue Mar 11 12:36:39 2003
@@ -167,7 +167,6 @@
 	vr41xx_clear_giuint(pin);
 }
 
-#define GIUINT_CASCADE_IRQ	16
 #define GIUINT_NR_IRQS		32
 
 enum {
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux.orig/arch/mips/vr41xx/common/icu.c	Thu Feb 27 11:39:22 2003
+++ linux/arch/mips/vr41xx/common/icu.c	Tue Mar 11 12:36:39 2003
@@ -54,16 +54,6 @@
 #include <asm/mipsregs.h>
 #include <asm/vr41xx/vr41xx.h>
 
-#define MIPS_CPU_IRQ_BASE	0
-#define SYSINT1_IRQ_BASE	8
-#define SYSINT1_IRQ_LAST	23
-#define SYSINT2_IRQ_BASE	24
-#define SYSINT2_IRQ_LAST	39
-#define GIUINT_IRQ_BASE		GIU_IRQ(0)
-#define GIUINT_IRQ_LAST		GIU_IRQ(31)
-
-#define ICU_CASCADE_IRQ		(MIPS_CPU_IRQ_BASE + 2)
-
 extern asmlinkage void vr41xx_handle_interrupt(void);
 
 extern void __init init_generic_irq(void);
@@ -228,7 +218,7 @@
 {
 	int pin;
 
-	pin = irq - GIUINT_IRQ_BASE;
+	pin = irq - GIU_IRQ_BASE;
 	if (pin < 16)
 		set_icu1(MGIUINTLREG, (u16)1 << pin);
 	else
@@ -241,7 +231,7 @@
 {
 	int pin;
 
-	pin = irq - GIUINT_IRQ_BASE;
+	pin = irq - GIU_IRQ_BASE;
 	vr41xx_disable_giuint(pin);
 
 	if (pin < 16)
@@ -252,7 +242,7 @@
 
 static unsigned int startup_giuint_irq(unsigned int irq)
 {
-	vr41xx_clear_giuint(irq - GIUINT_IRQ_BASE);
+	vr41xx_clear_giuint(irq - GIU_IRQ_BASE);
 
 	enable_giuint_irq(irq);
 
@@ -265,7 +255,7 @@
 {
 	disable_giuint_irq(irq);
 
-	vr41xx_clear_giuint(irq - GIUINT_IRQ_BASE);
+	vr41xx_clear_giuint(irq - GIU_IRQ_BASE);
 }
 
 static void end_giuint_irq(unsigned int irq)
@@ -315,12 +305,12 @@
 	write_icu2(0, MSYSINT2REG);
 	write_icu2(0, MGIUINTHREG);
 
-	for (i = SYSINT1_IRQ_BASE; i <= GIUINT_IRQ_LAST; i++) {
+	for (i = SYSINT1_IRQ_BASE; i <= GIU_IRQ_LAST; i++) {
 		if (i >= SYSINT1_IRQ_BASE && i <= SYSINT1_IRQ_LAST)
 			irq_desc[i].handler = &sysint1_irq_type;
 		else if (i >= SYSINT2_IRQ_BASE && i <= SYSINT2_IRQ_LAST)
 			irq_desc[i].handler = &sysint2_irq_type;
-		else if (i >= GIUINT_IRQ_BASE && i <= GIUINT_IRQ_LAST)
+		else if (i >= GIU_IRQ_BASE && i <= GIU_IRQ_LAST)
 			irq_desc[i].handler = &giuint_irq_type;
 	}
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux.orig/arch/mips/vr41xx/common/serial.c	Mon Jul 15 09:02:56 2002
+++ linux/arch/mips/vr41xx/common/serial.c	Tue Mar 11 12:36:39 2003
@@ -67,7 +67,6 @@
 
 #define SIU_BASE_BAUD		1152000
 #define SIU_CLOCK		0x0102
-#define SIU_IRQ			17
 
 /* VR4122 and VR4131 DSIU Registers */
 #define DSIURB			KSEG1ADDR(0x0f000820)
@@ -77,7 +76,6 @@
 
 #define DSIU_BASE_BAUD		1152000
 #define DSIU_CLOCK		0x0802
-#define DSIU_IRQ		29
 
 int vr41xx_serial_ports = 0;
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/time.c linux/arch/mips/vr41xx/common/time.c
--- linux.orig/arch/mips/vr41xx/common/time.c	Mon Dec  2 09:24:52 2002
+++ linux/arch/mips/vr41xx/common/time.c	Tue Mar 11 12:36:39 2003
@@ -48,8 +48,7 @@
 #include <asm/mipsregs.h>
 #include <asm/param.h>
 #include <asm/time.h>
-
-#define MIPS_COUNTER_TIMER_IRQ	7
+#include <asm/vr41xx/vr41xx.h>
 
 #define VR4111_ETIMELREG	KSEG1ADDR(0x0b0000c0)
 #define VR4122_ETIMELREG	KSEG1ADDR(0x0f000100)
@@ -87,7 +86,7 @@
 {
 	u32 count;
 
-	setup_irq(MIPS_COUNTER_TIMER_IRQ, irq);
+	setup_irq(MIPS_COUNTER_IRQ, irq);
 
 	count = read_c0_count();
 	write_c0_compare(count + (mips_counter_frequency / HZ));
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/capcella.h linux/include/asm-mips/vr41xx/capcella.h
--- linux.orig/include/asm-mips/vr41xx/capcella.h	Mon Jul 15 09:02:57 2002
+++ linux/include/asm-mips/vr41xx/capcella.h	Tue Mar 11 15:44:51 2003
@@ -5,7 +5,7 @@
  * BRIEF MODULE DESCRIPTION
  *	Include file for ZAO Networks Capcella.
  *
- * Copyright 2002 Yoichi Yuasa
+ * Copyright 2002,2003 Yoichi Yuasa
  *                yuasa@hh.iij4u.or.jp
  *
  *  This program is free software; you can redistribute it and/or modify it
@@ -49,13 +49,21 @@
 #define IO_MEM2_RESOURCE_END		(VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE)
 
 /*
+ * General-Purpose I/O Pin Number
+ */
+#define PC104PLUS_INTA_PIN		2
+#define PC104PLUS_INTB_PIN		3
+#define PC104PLUS_INTC_PIN		4
+#define PC104PLUS_INTD_PIN		5
+
+/*
  * Interrupt Number
  */
-#define RTL8139_1_IRQ			GIU_IRQ(4)
-#define RTL8139_2_IRQ			GIU_IRQ(5)
-#define PC104PLUS_INTA_IRQ		GIU_IRQ(2)
-#define PC104PLUS_INTB_IRQ		GIU_IRQ(3)
-#define PC104PLUS_INTC_IRQ		GIU_IRQ(4)
-#define PC104PLUS_INTD_IRQ		GIU_IRQ(5)
+#define RTL8139_1_IRQ			GIU_IRQ(PC104PLUS_INTC_PIN)
+#define RTL8139_2_IRQ			GIU_IRQ(PC104PLUS_INTD_PIN)
+#define PC104PLUS_INTA_IRQ		GIU_IRQ(PC104PLUS_INTA_PIN)
+#define PC104PLUS_INTB_IRQ		GIU_IRQ(PC104PLUS_INTB_PIN)
+#define PC104PLUS_INTC_IRQ		GIU_IRQ(PC104PLUS_INTC_PIN)
+#define PC104PLUS_INTD_IRQ		GIU_IRQ(PC104PLUS_INTD_PIN)
 
 #endif /* __ZAO_CAPCELLA_H */
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/eagle.h linux/include/asm-mips/vr41xx/eagle.h
--- linux.orig/include/asm-mips/vr41xx/eagle.h	Fri Oct  4 01:58:02 2002
+++ linux/include/asm-mips/vr41xx/eagle.h	Tue Mar 11 15:45:11 2003
@@ -8,7 +8,7 @@
  * Author: MontaVista Software, Inc.
  *         yyuasa@mvista.com or source@mvista.com
  *
- * Copyright 2001,2002 MontaVista Software Inc.
+ * Copyright 2001-2003 MontaVista Software Inc.
  *
  *  This program is free software; you can redistribute it and/or modify it
  *  under the terms of the GNU General Public License as published by the
@@ -82,19 +82,22 @@
 #define DCD_IRQ				GIU_IRQ(DCD_PIN)
 
 #define SDBINT_IRQ_BASE			88
-#define DEG_IRQ				(SDBINT_IRQ_BASE + 1)
-#define ENUM_IRQ			(SDBINT_IRQ_BASE + 2)
-#define SIO1INT_IRQ			(SDBINT_IRQ_BASE + 3)
-#define SIO2INT_IRQ			(SDBINT_IRQ_BASE + 4)
-#define PARINT_IRQ			(SDBINT_IRQ_BASE + 5)
+#define SDBINT_IRQ(x)			(SDBINT_IRQ_BASE + (x))
+/* RFU */
+#define DEG_IRQ				SDBINT_IRQ(1)
+#define ENUM_IRQ			SDBINT_IRQ(2)
+#define SIO1INT_IRQ			SDBINT_IRQ(3)
+#define SIO2INT_IRQ			SDBINT_IRQ(4)
+#define PARINT_IRQ			SDBINT_IRQ(5)
 #define SDBINT_IRQ_LAST			PARINT_IRQ
 
 #define PCIINT_IRQ_BASE			96
-#define CP_INTA_IRQ			(PCIINT_IRQ_BASE + 0)
-#define CP_INTB_IRQ			(PCIINT_IRQ_BASE + 1)
-#define CP_INTC_IRQ			(PCIINT_IRQ_BASE + 2)
-#define CP_INTD_IRQ			(PCIINT_IRQ_BASE + 3)
-#define LANINTA_IRQ			(PCIINT_IRQ_BASE + 4)
+#define PCIINT_IRQ(x)			(PCIINT_IRQ_BASE + (x))
+#define CP_INTA_IRQ			PCIINT_IRQ(0)
+#define CP_INTB_IRQ			PCIINT_IRQ(1)
+#define CP_INTC_IRQ			PCIINT_IRQ(2)
+#define CP_INTD_IRQ			PCIINT_IRQ(3)
+#define LANINTA_IRQ			PCIINT_IRQ(4)
 #define PCIINT_IRQ_LAST			LANINTA_IRQ
 
 /*
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/mpc30x.h linux/include/asm-mips/vr41xx/mpc30x.h
--- linux.orig/include/asm-mips/vr41xx/mpc30x.h	Fri Oct  4 01:58:02 2002
+++ linux/include/asm-mips/vr41xx/mpc30x.h	Tue Mar 11 15:45:20 2003
@@ -5,7 +5,7 @@
  * BRIEF MODULE DESCRIPTION
  *	Include file for Victor MP-C303/304.
  *
- * Copyright 2002 Yoichi Yuasa
+ * Copyright 2002,2003 Yoichi Yuasa
  *                yuasa@hh.iij4u.or.jp
  *
  *  This program is free software; you can redistribute it and/or modify it
@@ -51,21 +51,15 @@
 #define IO_MEM2_RESOURCE_END		(VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE)
 
 /*
- * Interrupt Number
+ * General-Purpose I/O Pin Number
  */
-#define VRC4173_CASCADE_IRQ		GIU_IRQ(1)
-#define MQ200_IRQ			GIU_IRQ(4)
-
-#ifdef CONFIG_VRC4173
-
-#define VRC4173_IRQ_BASE		72
-#define USB_IRQ				(VRC4173_IRQ_BASE + 0)
-#define PCMCIA2_IRQ			(VRC4173_IRQ_BASE + 1)
-#define PCMCIA1_IRQ			(VRC4173_IRQ_BASE + 2)
-#define PIU_IRQ				(VRC4173_IRQ_BASE + 5)
-#define KIU_IRQ				(VRC4173_IRQ_BASE + 7)
-#define AC97_IRQ			(VRC4173_IRQ_BASE + 9)
+#define VRC4173_PIN			1
+#define MQ200_PIN			4
 
-#endif	/* CONFIG_VRC4173 */
+/*
+ * Interrupt Number
+ */
+#define VRC4173_CASCADE_IRQ		GIU_IRQ(VRC4173_PIN)
+#define MQ200_IRQ			GIU_IRQ(MQ200_PIN)
 
 #endif /* __VICTOR_MPC30X_H */
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	Fri Oct  4 01:58:02 2002
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Tue Mar 11 15:34:23 2003
@@ -53,9 +53,50 @@
 /*
  * Interrupt Control Unit
  */
+/* CPU core Interrupt Numbers */
+#define MIPS_CPU_IRQ_BASE	0
+#define MIPS_CPU_IRQ(x)		(MIPS_CPU_IRQ_BASE + (x))
+#define MIPS_SOFTINT0_IRQ	MIPS_CPU_IRQ(0)
+#define MIPS_SOFTINT1_IRQ	MIPS_CPU_IRQ(1)
+#define ICU_CASCADE_IRQ		MIPS_CPU_IRQ(2)
+#define RTC_LONG1_IRQ		MIPS_CPU_IRQ(3)
+#define RTC_LONG2_IRQ		MIPS_CPU_IRQ(4)
+/* RFU */
+#define BATTERY_IRQ		MIPS_CPU_IRQ(6)
+#define MIPS_COUNTER_IRQ	MIPS_CPU_IRQ(7)
+
+/* SYINT1 Interrupt Numbers */
+#define SYSINT1_IRQ_BASE	8
+#define SYSINT1_IRQ(x)		(SYSINT1_IRQ_BASE + (x))
+/* RFU */
+#define POWER_IRQ		SYSINT1_IRQ(1)
+/* RFU */
+#define GIUINT_CASCADE_IRQ	SYSINT1_IRQ(8)
+#define SIU_IRQ			SYSINT1_IRQ(9)
+/* RFU */
+#define SOFTINT_IRQ		SYSINT1_IRQ(11)
+#define CLKRUN_IRQ		SYSINT1_IRQ(12)
+#define SYSINT1_IRQ_LAST	CLKRUN_IRQ
+
+/* SYSINT2 Interrupt Numbers */
+#define SYSINT2_IRQ_BASE	24
+#define SYSINT2_IRQ(x)		(SYSINT2_IRQ_BASE + (x))
+/* RFU */
+#define LED_IRQ			SYSINT2_IRQ(1)
+/* RFU */
+#define VTCLOCK_IRQ		SYSINT2_IRQ(3)
+#define FIR_IRQ			SYSINT2_IRQ(4)
+#define DSIU_IRQ		SYSINT2_IRQ(5)
+#define PCI_IRQ			SYSINT2_IRQ(6)
+#define SCU_IRQ			SYSINT2_IRQ(7)
+#define CSI_IRQ			SYSINT2_IRQ(8)
+#define BCU_IRQ			SYSINT2_IRQ(9)
+#define SYSINT2_IRQ_LAST	BCU_IRQ
 
 /* GIU Interrupt Numbers */
-#define GIU_IRQ(x)	(40 + (x))
+#define GIU_IRQ_BASE		40
+#define GIU_IRQ(x)		(GIU_IRQ_BASE + (x))	/* IRQ 40-71 */
+#define GIU_IRQ_LAST		GIU_IRQ(31)
 
 extern void (*board_irq_init)(void);
 extern int vr41xx_cascade_irq(unsigned int irq, int (*get_irq_number)(int irq));
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vrc4173.h linux/include/asm-mips/vr41xx/vrc4173.h
--- linux.orig/include/asm-mips/vr41xx/vrc4173.h	Thu Dec 12 10:10:10 2002
+++ linux/include/asm-mips/vr41xx/vrc4173.h	Tue Mar 11 15:45:45 2003
@@ -11,7 +11,7 @@
  *
  * Copyright (C) 2000 by Michael R. McDonald
  *
- * Copyright 2001,2002 Montavista Software Inc.
+ * Copyright 2001-2003 Montavista Software Inc.
  * Author: Yoichi Yuasa
  *         yyuasa@mvista.com or source@mvista.com
  */
@@ -24,18 +24,20 @@
  * Interrupt Number
  */
 #define VRC4173_IRQ_BASE	72
-#define VRC4173_USB_IRQ		(VRC4173_IRQ_BASE + 0)
-#define VRC4173_PCMCIA2_IRQ	(VRC4173_IRQ_BASE + 1)
-#define VRC4173_PCMCIA1_IRQ	(VRC4173_IRQ_BASE + 2)
-#define VRC4173_PS2CH2_IRQ	(VRC4173_IRQ_BASE + 3)
-#define VRC4173_PS2CH1_IRQ	(VRC4173_IRQ_BASE + 4)
-#define VRC4173_PIU_IRQ		(VRC4173_IRQ_BASE + 5)
-#define VRC4173_AIU_IRQ		(VRC4173_IRQ_BASE + 6)
-#define VRC4173_KIU_IRQ		(VRC4173_IRQ_BASE + 7)
-#define VRC4173_GIU_IRQ		(VRC4173_IRQ_BASE + 8)
-#define VRC4173_AC97_IRQ	(VRC4173_IRQ_BASE + 9)
-#define VRC4173_AC97INT1_IRQ	(VRC4173_IRQ_BASE + 10)
-#define VRC4173_DOZEPIU_IRQ	(VRC4173_IRQ_BASE + 13)
+#define VRC4173_IRQ(x)		(VRC4173_IRQ_BASE + (x))
+#define VRC4173_USB_IRQ		VRC4173_IRQ(0)
+#define VRC4173_PCMCIA2_IRQ	VRC4173_IRQ(1)
+#define VRC4173_PCMCIA1_IRQ	VRC4173_IRQ(2)
+#define VRC4173_PS2CH2_IRQ	VRC4173_IRQ(3)
+#define VRC4173_PS2CH1_IRQ	VRC4173_IRQ(4)
+#define VRC4173_PIU_IRQ		VRC4173_IRQ(5)
+#define VRC4173_AIU_IRQ		VRC4173_IRQ(6)
+#define VRC4173_KIU_IRQ		VRC4173_IRQ(7)
+#define VRC4173_GIU_IRQ		VRC4173_IRQ(8)
+#define VRC4173_AC97_IRQ	VRC4173_IRQ(9)
+#define VRC4173_AC97INT1_IRQ	VRC4173_IRQ(10)
+/* RFU */
+#define VRC4173_DOZEPIU_IRQ	VRC4173_IRQ(13)
 #define VRC4173_IRQ_LAST	VRC4173_DOZEPIU_IRQ
 
 /*

--Multipart_Tue__11_Mar_2003_16:18:10_+0900_08238278--

From br1@4g-systems.de Tue Mar 11 10:31:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Mar 2003 10:31:06 +0000 (GMT)
Received: from moutvdom.kundenserver.de ([IPv6:::ffff:212.227.126.252]:5848
	"EHLO moutvdom.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225199AbTCKKbF>; Tue, 11 Mar 2003 10:31:05 +0000
Received: from [212.227.126.220] (helo=mrvdomng.kundenserver.de)
	by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1)
	id 18sh2C-0002uX-00; Tue, 11 Mar 2003 11:31:00 +0100
Received: from [62.109.119.183] (helo=192.168.202.41)
	by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 18sh2B-0004J2-00; Tue, 11 Mar 2003 11:30:59 +0100
From: Bruno Randolf <br1@4g-systems.de>
Organization: 4G Mobile Systeme
To: Dan Malek <dan@embeddededge.com>, Jun Sun <jsun@mvista.com>
Subject: Re: Mycable XXS board
Date: Tue, 11 Mar 2003 11:30:57 +0100
User-Agent: KMail/1.5
Cc: linux-mips@linux-mips.org
References: <3E689267.3070509@prosyst.bg> <20030307133919.P26071@mvista.com> <3E691514.7000907@embeddededge.com>
In-Reply-To: <3E691514.7000907@embeddededge.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200303111130.57387.br1@4g-systems.de>
Return-Path: <br1@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: 1686
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: br1@4g-systems.de
Precedence: bulk
X-list: linux-mips
Content-Length: 557
Lines: 15

On Friday 07 March 2003 22:54, Dan Malek wrote:

> That's what I wanted to clarify.  Are we discussing one of the on-chip
> peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
> that was plugged into the Au1500.  In the case of the on-chip controller,
> there aren't any interrupt routing problems, it's identical (and the same
> code) on all Au1xxx boards.

we are discussing the on-chip USB controller for the mycable board. and its 
little endian...

any ideas where the assignment errors could come from in this case?

thanks,
bruno

From ppopov@mvista.com Tue Mar 11 15:16:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Mar 2003 15:16:55 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27377 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225193AbTCKPQz>;
	Tue, 11 Mar 2003 15:16:55 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id HAA20341;
	Tue, 11 Mar 2003 07:16:48 -0800
Subject: Re: Mycable XXS board
From: Pete Popov <ppopov@mvista.com>
To: Bruno Randolf <br1@4g-systems.de>
Cc: linux-mips@linux-mips.org
In-Reply-To: <200303111130.57387.br1@4g-systems.de>
References: <3E689267.3070509@prosyst.bg> <20030307133919.P26071@mvista.com>
	 <3E691514.7000907@embeddededge.com>  <200303111130.57387.br1@4g-systems.de>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047395856.5198.127.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 11 Mar 2003 07:17:36 -0800
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: 1687
X-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
Content-Length: 957
Lines: 24

On Tue, 2003-03-11 at 02:30, Bruno Randolf wrote:
> On Friday 07 March 2003 22:54, Dan Malek wrote:
> 
> > That's what I wanted to clarify.  Are we discussing one of the on-chip
> > peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
> > that was plugged into the Au1500.  In the case of the on-chip controller,
> > there aren't any interrupt routing problems, it's identical (and the same
> > code) on all Au1xxx boards.
> 
> we are discussing the on-chip USB controller for the mycable board. and its 
> little endian...
> 
> any ideas where the assignment errors could come from in this case?

There wouldn't be any. So the problem is not irq assignment related.

I'm not what to suggest here but it feels like it might be a hardware
issue.  Try adding some printks (the abatron bdi jtag debugger works
great if you have one) and narrow down what's going on. Do you have any
jumpers on the board that are not setup correctly?


Pete


From tk@mycable.de Tue Mar 11 15:56:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Mar 2003 15:56:52 +0000 (GMT)
Received: from [IPv6:::ffff:62.116.167.108] ([IPv6:::ffff:62.116.167.108]:55261
	"EHLO oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8225193AbTCKP4v>; Tue, 11 Mar 2003 15:56:51 +0000
Received: from mycable.de (pD9E3CF88.dip.t-dialin.net [217.227.207.136])
	(authenticated bits=0)
	by oricom4.internetx.de (8.12.8/8.12.8) with ESMTP id h2BFrV9h029391;
	Tue, 11 Mar 2003 16:53:32 +0100
Message-ID: <3E6E07D5.60306@mycable.de>
Date: Tue, 11 Mar 2003 16:59:17 +0100
From: Tiemo Krueger - mycable GmbH <tk@mycable.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bruno randolf <br1@4g-systems.biz>
CC: linux-mips@linux-mips.org
Subject: Re: Mycable XXS board
References: <3E689267.3070509@prosyst.bg> <20030307133919.P26071@mvista.com>	 <3E691514.7000907@embeddededge.com>  <200303111130.57387.br1@4g-systems.de> <1047395856.5198.127.camel@zeus.mvista.com>
In-Reply-To: <3E689267.3070509@prosyst.bg>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <tk@mycable.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1688
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tk@mycable.de
Precedence: bulk
X-list: linux-mips
Content-Length: 4776
Lines: 158

Hi Bruno, Hi group!

There is a separate power switch on the mycable XXS1500 Board:

1. GPIO1  switch on UART3
2.  Enable UART3
3.  Set DTR from UART3 to low-level

The voltage switch for USB is controlled by the unused DTR line of the 
Au1500.

below the code we use with QNX for this procedure:

/*-------------------------------------------------------------------------*/
/*                                                                         
*/
/*  
main                                                                   */
/*                                                                         
*/
/*  action: enable and start AU1500 onchip USB 
controller                  */
/*                                                                         
*/
/*  passing param.  : 
-none-                                               */
/*  global  param.  : 
-none-                                               */
/*  return  param.  : 
-none-                                               */
/*                                                                         
*/
/*  programmer      : 
JR                                                   */
/*                                                                         
*/
/*  04.03.03  JR    : build this 
function                                  */
/*                                                                         
*/
/*-------------------------------------------------------------------------*/

int main(int argc, char *argv[]) {
   
    volatile uint32_t *sysctrlptr;
    volatile uint32_t *uart3_mdmptr;
    volatile uint32_t *usb_baseptr;
   
   
    printf("Prepare AU1500 onchip USB host controller\n");
    printf("  map memory\n");
    sysctrlptr = mmap_device_memory(NULL, 1000, 
PROT_READ|PROT_WRITE|PROT_NOCACHE, 0, 0x011900000);
    if ( sysctrlptr == MAP_FAILED ) {
        perror( "couldn't map sysctrl mem.\n" );
        exit( EXIT_FAILURE );
    }
    uart3_mdmptr = mmap_device_memory(NULL, 1000, 
PROT_READ|PROT_WRITE|PROT_NOCACHE, 0, 0x011400000);
    if ( uart3_mdmptr == MAP_FAILED ) {
        perror( "couldn't map uart3 mem.\n" );
        exit( EXIT_FAILURE );
    }
    usb_baseptr = mmap_device_memory(NULL, 0x80000, 
PROT_READ|PROT_WRITE|PROT_NOCACHE, 0, 0x010100000);
    if ( usb_baseptr == MAP_FAILED ) {
        perror( "couldn't map usb mem.\n" );
        exit( EXIT_FAILURE );
    }

    // configure some multiple use pins for UART3
    sysctrlptr[0x2c/4] |= (1 << 7);  // sys_pinctrl
   
    printf("  power on\n");
    uart3_mdmptr[0x100/4] |= 0x01;    // CE
    delay(10);
    uart3_mdmptr[0x100/4] |= 0x03;    // CE | EN
    delay(10);
    uart3_mdmptr[0x18/4]  |= 0x01;    // power on
   
    // enable usb OCHI controller
    usb_baseptr[0x7fffc/4] = 0x08;    // CE
    delay(10);
    usb_baseptr[0x7fffc/4] = 0x0c ;    // CE | EN
    delay(10);
    // clear HCFS bits in HcControl
    usb_baseptr[0x0004/4] = 0x00; 
   
    while ((usb_baseptr[0x7fffc/4] & 0x10) == 0); // wait for reset done
   
    printf("  USB OHCI ver. 0x%x\n", usb_baseptr[0]);
   
    return EXIT_SUCCESS;
}

Tiemo

-- 
-------------------------------------------------------
Tiemo Krueger       Tel:  +49 48 73 90 19 86
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: tk@mycable.de

Public Kryptographic Key is available on request
-------------------------------------------------------


Pete Popov wrote:

>On Tue, 2003-03-11 at 02:30, Bruno Randolf wrote:
>  
>
>>On Friday 07 March 2003 22:54, Dan Malek wrote:
>>
>>    
>>
>>>That's what I wanted to clarify.  Are we discussing one of the on-chip
>>>peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
>>>that was plugged into the Au1500.  In the case of the on-chip controller,
>>>there aren't any interrupt routing problems, it's identical (and the same
>>>code) on all Au1xxx boards.
>>>      
>>>
>>we are discussing the on-chip USB controller for the mycable board. and its 
>>little endian...
>>
>>any ideas where the assignment errors could come from in this case?
>>    
>>
>
>There wouldn't be any. So the problem is not irq assignment related.
>
>I'm not what to suggest here but it feels like it might be a hardware
>issue.  Try adding some printks (the abatron bdi jtag debugger works
>great if you have one) and narrow down what's going on. Do you have any
>jumpers on the board that are not setup correctly?
>
>
>Pete
>
>
>
>  
>


-- 
-------------------------------------------------------
Tiemo Krueger       Tel:  +49 48 73 90 19 86
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: tk@mycable.de

Public Kryptographic Key is available on request
-------------------------------------------------------



From erik@greendragon.org Tue Mar 11 19:01:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Mar 2003 19:01:47 +0000 (GMT)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:40136 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225193AbTCKTBq>;
	Tue, 11 Mar 2003 19:01:46 +0000
Received: from mahes.visi.com (mahes.visi.com [209.98.98.96])
	by mail-out.visi.com (Postfix) with ESMTP id 28DA439D3
	for <linux-mips@linux-mips.org>; Tue, 11 Mar 2003 13:01:39 -0600 (CST)
Received: from mahes.visi.com (localhost [127.0.0.1])
	by mahes.visi.com (8.12.5/8.12.5) with ESMTP id h2BJ1c2k071260
	for <linux-mips@linux-mips.org>; Tue, 11 Mar 2003 13:01:38 -0600 (CST)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mahes.visi.com (8.12.5/8.12.5/Submit) id h2BJ1b7L071259
	for linux-mips@linux-mips.org; Tue, 11 Mar 2003 19:01:37 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>; Tue, 11 Mar 2003 19:01:37 +0000
Message-ID: <1047409297.3e6e3291472c1@my.visi.com>
Date: Tue, 11 Mar 2003 19:01:37 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: linux-mips@linux-mips.org
Subject: SGI contact info needed
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: 1689
X-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
Content-Length: 2161
Lines: 53


Hello all;

I'm about to make a serious attempt at getting Linux running on the Octane
(IP30) and I'm currently gathering information on the hardware while my Octane
is being shipped to me.

I realize that this may be (probably is) a futile effort, but I'm trying to
locate a contact at SGI who can discuss the "Heart" ASIC or provide
documentation for same.  This is the memory controller in the Octane systems,
and as I understand things it's the major difference between Origin and Octane
systems.  I also would love a set of docs on the XIO bus and SE graphics, but
the Heart is the show stopper at this point.

I would deeply appreciate either information on the appropriate person at SGI to
contact if anyone knows this, or else contact from someone @sgi in the know.

My last resort is reverse engineering, which seems silly to have to do given the
dependence of SGI on Linux at the moment.

Erik


PS:


<vent>

I've so far sent about 20-ish e-mails to various folks at SGI, trying to get any
information or even pointers to the right people, and gotten only one actual
reply (thanks Dave) saying "I dunno".

I realize SGI has had a lot of employee turn-over in the last few years, but I'm
seeing an amazingly schizoid company in bits and pieces.  They have released a
new flagship product, the Altix, but they don't seem to have a contact person
listed anywhere to deal with the Linux community in general, even for that product.

In my previous effort to get information on the Impact graphics boards, I
finally got ahold of a single engineer who informed me that only partial docs
existed, probably for the wrong board, and which he might be willing to copy if
I paid for copies.  Shortly after this offer, I no longer received responses
from him.  I can only conclude that he was abducted by Microsoft customer service.

Contrast this with the PS docs for the Indy on the linux-mips ftp site.  I'm
starting to think the Indy was designed and properly documented by Interns, and
the Indigo2 by old timers who retired and took their knowledge with them,
leaving only cryptic notes and binary drivers.

</vent>

-- 
Erik J. Green
erik@greendragon.org

From eric.devolder@amd.com Tue Mar 11 21:44:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Mar 2003 21:44:04 +0000 (GMT)
Received: from amdext2.amd.com ([IPv6:::ffff:163.181.251.1]:13292 "EHLO
	amdext2.amd.com") by linux-mips.org with ESMTP id <S8225193AbTCKVoD>;
	Tue, 11 Mar 2003 21:44:03 +0000
Received: from SAUSGW01.amd.com (sausgw01.amd.com [163.181.250.21])
	by amdext2.amd.com (8.9.3/8.9.3/AMD) with ESMTP id PAA19552;
	Tue, 11 Mar 2003 15:43:50 -0600 (CST)
Received: from 163.181.250.1SAUSGW01.amd.com with ESMTP (AMD SMTP Relay
 (MMS v5.0)); Tue, 11 Mar 2003 15:43:43 -0600
X-Server-Uuid: 262C4BA7-64EE-471D-8B02-117625D613AB
Received: from pcsmail.amd.com (pcsmail.amd.com [163.181.41.222]) by
 amdint2.amd.com (8.9.3/8.9.3/AMD) with ESMTP id PAA18627; Tue, 11 Mar
 2003 15:43:40 -0600 (CST)
Received: from amd.com (PC-DEVOLDER.amd.com [163.181.60.19]) by
 pcsmail.amd.com (8.11.6/8.11.6) with ESMTP id h2BLhca07906; Tue, 11 Mar
 2003 15:43:38 -0600
Message-ID: <3E6E588A.1090702@amd.com>
Date: Tue, 11 Mar 2003 15:43:38 -0600
From: "Eric DeVolder" <eric.devolder@amd.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1)
 Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Pete Popov" <ppopov@mvista.com>
cc: "Bruno Randolf" <br1@4g-systems.de>, linux-mips@linux-mips.org
Subject: Re: Mycable XXS board
References: <3E689267.3070509@prosyst.bg>
 <20030307133919.P26071@mvista.com> <3E691514.7000907@embeddededge.com>
 <200303111130.57387.br1@4g-systems.de>
 <1047395856.5198.127.camel@zeus.mvista.com>
X-WSS-ID: 127087053189381-01-01
Content-Type: multipart/alternative;
 boundary=------------030008000503030902060102
Return-Path: <eric.devolder@amd.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1690
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eric.devolder@amd.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3340
Lines: 116


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

Check linux/arch/mips/au1000/common/irq.c, in function init_IRQ().
Currently all the interrupt assignment are conditionalized per-board,
rather than per-cpu where appropriate. Unless you've changed this
file, I suspect many IRQ setups may be wrong.

Eric

Pete Popov wrote:

>On Tue, 2003-03-11 at 02:30, Bruno Randolf wrote:
>  
>
>>On Friday 07 March 2003 22:54, Dan Malek wrote:
>>
>>    
>>
>>>That's what I wanted to clarify.  Are we discussing one of the on-chip
>>>peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
>>>that was plugged into the Au1500.  In the case of the on-chip controller,
>>>there aren't any interrupt routing problems, it's identical (and the same
>>>code) on all Au1xxx boards.
>>>      
>>>
>>we are discussing the on-chip USB controller for the mycable board. and its 
>>little endian...
>>
>>any ideas where the assignment errors could come from in this case?
>>    
>>
>
>There wouldn't be any. So the problem is not irq assignment related.
>
>I'm not what to suggest here but it feels like it might be a hardware
>issue.  Try adding some printks (the abatron bdi jtag debugger works
>great if you have one) and narrow down what's going on. Do you have any
>jumpers on the board that are not setup correctly?
>
>
>Pete
>
>
>
>  
>


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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Check linux/arch/mips/au1000/common/irq.c, in function init_IRQ().<br>
Currently all the interrupt assignment are conditionalized per-board,<br>
rather than per-cpu where appropriate. Unless you've changed this<br>
file, I suspect many IRQ setups may be wrong.<br>
<br>
Eric<br>
<br>
Pete Popov wrote:<br>
<blockquote type="cite"
 cite="mid1047395856.5198.127.camel@zeus.mvista.com">
  <pre wrap="">On Tue, 2003-03-11 at 02:30, Bruno Randolf wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">On Friday 07 March 2003 22:54, Dan Malek wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">That's what I wanted to clarify.  Are we discussing one of the on-chip
peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
that was plugged into the Au1500.  In the case of the on-chip controller,
there aren't any interrupt routing problems, it's identical (and the same
code) on all Au1xxx boards.
      </pre>
    </blockquote>
    <pre wrap="">we are discussing the on-chip USB controller for the mycable board. and its 
little endian...

any ideas where the assignment errors could come from in this case?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
There wouldn't be any. So the problem is not irq assignment related.

I'm not what to suggest here but it feels like it might be a hardware
issue.  Try adding some printks (the abatron bdi jtag debugger works
great if you have one) and narrow down what's going on. Do you have any
jumpers on the board that are not setup correctly?


Pete



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

--------------030008000503030902060102--


From dan@embeddededge.com Tue Mar 11 21:58:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Mar 2003 21:58:01 +0000 (GMT)
Received: from 154-84-51-66.reonbroadband.com ([IPv6:::ffff:66.51.84.154]:18304
	"EHLO tibook.netx4.com") by linux-mips.org with ESMTP
	id <S8225193AbTCKV6A>; Tue, 11 Mar 2003 21:58:00 +0000
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 h2BLvqw01448;
	Tue, 11 Mar 2003 16:57:52 -0500
Message-ID: <3E6E5BE0.4000203@embeddededge.com>
Date: Tue, 11 Mar 2003 16:57:52 -0500
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric DeVolder <eric.devolder@amd.com>
CC: Pete Popov <ppopov@mvista.com>, Bruno Randolf <br1@4g-systems.de>,
	linux-mips@linux-mips.org
Subject: Re: Mycable XXS board
References: <3E689267.3070509@prosyst.bg> <20030307133919.P26071@mvista.com> <3E691514.7000907@embeddededge.com> <200303111130.57387.br1@4g-systems.de> <1047395856.5198.127.camel@zeus.mvista.com> <3E6E588A.1090702@amd.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dan@embeddededge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1691
X-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
Content-Length: 644
Lines: 22

Eric DeVolder wrote:

> Check linux/arch/mips/au1000/common/irq.c, in function init_IRQ().
> Currently all the interrupt assignment are conditionalized per-board,

Well, only some of them, in particular the custom GPIO configurations.
In the case of USB and other on-chip peripherals, these are always
configured on all boards.

> ... I suspect many IRQ setups may be wrong.

I don't really think so.  I've done several different Au1xxx boards and
never touch this configuration for USB.  I would like to hear the
results of the message posted earlier today about the proper power up
of the USB interface on this board :-)


Thanks.


	-- Dan


From Teresat@tridentmicro.com Wed Mar 12 02:09:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 02:09:09 +0000 (GMT)
Received: from [IPv6:::ffff:66.121.16.190] ([IPv6:::ffff:66.121.16.190]:12465
	"EHLO trid-mail1.tridentmicro.com") by linux-mips.org with ESMTP
	id <S8225193AbTCLCJI> convert rfc822-to-8bit; Wed, 12 Mar 2003 02:09:08 +0000
content-class: urn:content-classes:message
Subject: specify the user mode program's physical address
Date: Tue, 11 Mar 2003 18:05:11 -0800
Message-ID: <61F6477DE6BED311B69F009027C3F5840213109C@Exchange.tridentmicro.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: specify the user mode program's physical address
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcLoPEpyyq1yZGmLSk6kmam+uEI7Ew==
From: "Teresa Tao" <Teresat@tridentmicro.com>
To: <linux-mips@linux-mips.org>
Return-Path: <Teresat@tridentmicro.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1692
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Teresat@tridentmicro.com
Precedence: bulk
X-list: linux-mips
Content-Length: 176
Lines: 7

Hi, 

Is there a way for linux to specify the physical address for a user mode program? So my program will load into the specified physical memory.

Thanks in advance!

Teresa

From baitisj@idealab.com Wed Mar 12 02:15:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 02:15:25 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:17619 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225193AbTCLCPY>;
	Wed, 12 Mar 2003 02:15:24 +0000
Received: (qmail 21349 invoked by uid 6180); 12 Mar 2003 02:15:17 -0000
Date: Tue, 11 Mar 2003 18:15:17 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: CardBus on DBAu1500 -- IRQ storm?
Message-ID: <20030311181517.M20129@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030228194820.Z20129@luca.pas.lab> <1046499358.12356.2.camel@adsl.pacbell.net> <20030303181421.C20129@luca.pas.lab> <20030307180804.A20129@luca.pas.lab> <1047089512.30919.587.camel@zeus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <1047089512.30919.587.camel@zeus.mvista.com>; from ppopov@mvista.com on Fri, Mar 07, 2003 at 06:11:53PM -0800
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: 1693
X-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
Content-Length: 21919
Lines: 506

On Fri, Mar 07, 2003 at 06:11:53PM -0800, Pete Popov wrote:
> Check to see what yenta_interrupt is doing. Is it acknowledging the
> interrupt?
> 
> Pete

Pardon my delayed response -- I've got a lot of irons in a lot of different
fires over here ;)

To try to answer your question, Pete:

yenta_interrupt() is calling yenta_events(), which reads the CardBus socket
event register, and then writes the returned value back to the CardBus socket
event register. Presumably this tells the CardBus controller to clear those
bits in the event register. (I checked up on this in the PCI1510 data manual.)

Seemingly related: Today I discovered that my PCI->PCI bridge is rerouting INTA
to INTD. To help discover the culprit, our hardware dept temporarily rerouted
INTA to INTD on the CardBus bridge PCI card. This interrupt rerouting had *no*
effect -- the card still 'IRQ storms' when plugged in without the PCI->PCI
bridge.

Given this information, I added some debugging output to
arch/mips/kernel/irq.c. I discovered in the 'IRQ Storm' configuration,
the yenta_socket driver requests an IRQ which eventually ends up in
irq.c:setup_irq() being called, with an IRQ of '1'.  This IRQ is associated
with INTA.

Here's the pertinent part of the debugging output:

    ...
    yenta_open: Launched yenta_open_bh thread
    yenta_open: Exiting at end of fcn        
    yenta_open_bh: Entering          
    cb_writel: c0113eb0 0004 00000000
    yenta_open_bh: Attempted to disable all CardBus events
    exca_writeb: c0113eb0 0005 00                         
    yenta_open_bh: Attempted to disable all EXCA events
    cb_readl: c0113eb0 0004 00000000                   
    exca_readb: c0113eb0 0005 00    
    request_irq:544: entering             
    request_irq:583: About to run setup_irq
    setup_irq:851: entering. setting up irq number 1
    setup_irq:873: about to spinlock                
    setup_irq:898: adding new IRQ   
    yenta_interrupt: Entering    
    yenta_events: Entering   
    cb_readl: c0113eb0 0000 00000000
    cb_writel: c0113eb0 0000 00000000
    exca_readb: c0113eb0 0004 00     
    exca_readb: c0113eb0 0003 00
    yenta_events: Exiting (retval is 0)
    yenta_interrupt: Exiting           
    yenta_interrupt: Entering
    yenta_events: Entering   
    ... ( IRQ storm ensues ) ...

In the PCI->PCI bridge configuration, setup_irq was never called:

    ...
    yenta_open: Launched yenta_open_bh thread
    yenta_open: Exiting at end of fcn        
    yenta_open_bh: Entering          
    cb_writel: c0113eb0 0004 00000000
    yenta_open_bh: Attempted to disable all CardBus events
    exca_writeb: c0113eb0 0005 00                         
    yenta_open_bh: Attempted to disable all EXCA events
    cb_readl: c0113eb0 0004 00000000                   
    exca_readb: c0113eb0 0005 00    
    request_irq:544: entering             
    request_irq:561: Exiting 
    yenta_open_bh: exited testyenta_open_bh: totally exited testyenta_get_socket_capabilities: Entering
    yenta_probe_irq: Entering                                                                          
    config_readw: c0113eb0 003e 05c0
    cb_writel: c0113eb0 0000 ffffffff
    cb_writel: c0113eb0 0004 00000001
    ... happy ...

Any ideas?

Thanks so much for looking at this!

-Jeff


> > yenta_interrupt: Entering    
> > yenta_events: Entering   
> > cb_readl: c0113eb0 0000 00000000
> > cb_writel: c0113eb0 0000 00000000
> > exca_readb: c0113eb0 0004 00     
> > exca_readb: c0113eb0 0003 00
> > yenta_events: Exiting (retval is 0)
> > yenta_interrupt: Exiting           
> > yenta_interrupt: Entering
> > 
> > etc etc
> > 
> > I've verified using our PCI analyzer that no interrupt events are transmitted
> > by the CardBus bridge, so this seems to be a software problem.
> > 
> > I'm going to continue to hunt this down, on the assumption that the kernel's
> > interrupt table is getting incorrect / corrupt data.  Suggestions are always
> > appreciated.
> > 
> > May all your CardBuses be happy!
> > 
> > -Jeff
> > 
> > 
> > 
> > On Mon, Mar 03, 2003 at 06:14:21PM -0800, Jeff Baitis wrote:
> > > Pete and others:
> > > 
> > > Thanks! I can access CardBus-enabled cards... but only if I plug the CardBus
> > > card into a PCI bridge device. 
> > > 
> > > For those who might be interested in hearing, here's my current status:
> > > 
> > > I tested the PCI->PCI bridge code by copying pb1500/pci_ops.c into
> > > db1x00/pci_ops.c. It seemed to work. Great!
> > > 
> > > After noticing that yenta_socket driver still locked up, I plugged a PCI-PCI
> > > bridge board in between the Au1500 dev board and the CardBus bridge. CardBus
> > > didn't work quite right, so I checked the PCI configuration registers on all
> > > devices on my PCI bus.
> > > 
> > > I noticed the PCI bridge device's SUBORDINATE_BUS value was set to 01, which
> > > is completely incorrect. It should have been at *least* 11, given that
> > > the CardBus bridge's SECONDARY_BUS register was set to 10. 
> > > 
> > > So, I used setpci to change the PCI bridge's SUBORDINATE_BUS to 1f. I started
> > > the CardBus services, and it seems that everything worked with CardBus cards.
> > > Eject, insert, and status all good -- and I can look at all the PCI
> > > configuration registers on the CardBus card.
> > > 
> > > ***
> > > 
> > > It seems like the issue with plugging in the CardBus bridge directly into
> > > PCI bus 0 (no PCI-PCI bridge) has to do with 16-bit CardBus support.
> > > I enabled debugging on yenta_socket, and here's some results. First, I present
> > > information *without* the PCI bridge, and then *with* PCI bridge.
> > > 
> > > 
> > > Without PCI bridge:
> > > 
> > > dmesg gives:
> > > 
> > >   Autoconfig PCI channel 0x8029fc38°°
> > >     Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
> > >     00:0c.0 Class 0104: 1103:0007 (rev 01)°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°                                                                
> > >             I/O at 0x00000300 [size=0x8]°°                         
> > >             I/O at 0x00000308 [size=0x4]
> > >             I/O at 0x00000310 [size=0x8]
> > >             I/O at 0x00000318 [size=0x4]
> > >             I/O at 0x00000400 [size=0x100]
> > >     00:0d.0 Class 0607: 104c:ac56°°°°°°°°°                         
> > >             Mem at 0x40000000 [size=0x1000]                        
> > >             Mem unavailable -- skipping°°°°                        
> > >             I/O at 0x00000500 [size=0x4]                           
> > >             Mem at 0x40001000 [size=0x1000]                        
> > >             Mem at 0x40002000 [size=0x1000]                        
> > >             Mem at 0x40003000 [size=0x1000]                        
> > >   
> > > lspci -v gives:
> > >   
> > >   00:0c.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0007
> > >   (rev 01)
> > >           Subsystem: Triones Technologies, Inc.: Unknown device 0001
> > >           Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 1
> > >           I/O ports at 0300 [size=8]
> > >           I/O ports at 0308 [size=4]
> > >           I/O ports at 0310 [size=8]
> > >           I/O ports at 0318 [size=4]
> > >           I/O ports at 0400 [size=256]
> > >           Expansion ROM at <unassigned> [disabled] [size=128K]   
> > >           Capabilities: [60] Power Management version 2          
> > >   
> > >   00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56 
> > >           Subsystem: Unknown device 5678:1234                    
> > >           Flags: bus master, medium devsel, latency 128, IRQ 1   
> > >           Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
> > >           Bus: primary=00, secondary=05, subordinate=00, sec-latency=0      
> > >           Memory window 0: 40001000-40002000 (prefetchable)      
> > >           I/O window 0: 00000000-00000003                        
> > >           I/O window 1: 00000000-00000003                        
> > >           16-bit legacy interface ports at 0001                  
> > > 
> > > 
> > > root@10.1.1.154:~# modprobe yenta_socket                       
> > > 
> > >   Linux Kernel Card Services 3.1.22
> > >     options:  [pci] [cardbus]°°°°°°
> > >   config_writel: c0112bd0 0044 00000000
> > >   config_writel: c0112bd0 0010 40000000
> > >   config_writew: c0112bd0 0004 0087°°°°
> > >   config_writeb: c0112bd0 000c 08°°
> > >   config_writeb: c0112bd0 000d a8
> > >   config_writel: c0112bd0 0018 b0000500
> > >   config_readw: c0112bd0 003e 0340°°°°°
> > >   config_writew: c0112bd0 003e 0580
> > >   exca_writeb: c0112bd0 001e 00°°°°
> > >   exca_writeb: c0112bd0 0016 00
> > >   cb_writel: c0112bd0 000c 00004000
> > >   cb_writel: c0112bd0 0004 00000000
> > >   config_readl: c0112bd0 001c 40001000
> > >   config_readl: c0112bd0 0020 40002000
> > >   config_readl: c0112bd0 0024 40003000
> > >   config_readl: c0112bd0 0028 00000000
> > >   config_writel: c0112bd0 0024 40400000
> > >   config_writel: c0112bd0 0028 407fffff
> > >   config_readl: c0112bd0 002c 00000000°
> > >   config_readl: c0112bd0 0030 00000000
> > >   config_writel: c0112bd0 002c 00004000
> > >   config_writel: c0112bd0 0030 000040ff
> > >   config_readl: c0112bd0 0034 00000000°
> > >   config_readl: c0112bd0 0038 00000000
> > >   config_writel: c0112bd0 0034 00004400
> > >   config_writel: c0112bd0 0038 000044ff
> > >   cb_readl: c0112bd0 0000 00000006°°°°°
> > >   cb_writel: c0112bd0 0000 00000006
> > >   exca_readb: c0112bd0 0004 00°°°°°
> > >   exca_readb: c0112bd0 0003 00
> > >   cb_readl: c0112bd0 0000 00000000
> > >   cb_writel: c0112bd0 0000 00000000
> > >   exca_readb: c0112bd0 0004 00°°°°°
> > >   exca_readb: c0112bd0 0003 00
> > >   cb_readl: c0112bd0 0000 00000000
> > >   cb_writel: c0112bd0 0000 00000000
> > >   exca_readb: c0112bd0 0004 00°°°°°
> > >   exca_readb: c0112bd0 0003 00
> > >   cb_readl: c0112bd0 0000 00000000
> > >   cb_writel: c0112bd0 0000 00000000
> > >   exca_readb: c0112bd0 0004 00°°°°°
> > >   exca_readb: c0112bd0 0003 00
> > >   cb_readl: c0112bd0 0000 00000000
> > >   cb_writel: c0112bd0 0000 00000000
> > >   exca_readb: c0112bd0 0004 00°°°°°
> > >   exca_readb: c0112bd0 0003 00
> > >   cb_readl: c0112bd0 0000 00000000
> > >   cb_writel: c0112bd0 0000 00000000
> > >   exca_readb: c0112bd0 0004 00°°°°°
> > >   exca_readb: c0112bd0 0003 00
> > >     ** following portion loops indefinitely **
> > >   cb_readl: c0112bd0 0000 00000000
> > >   cb_writel: c0112bd0 0000 00000000
> > >   exca_readb: c0112bd0 0004 00°°°°°
> > >   exca_readb: c0112bd0 0003 00
> > > 
> > > With PCI bridge:
> > > 
> > >   Autoconfig PCI channel 0x8029fc38°°
> > >   Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
> > >   00:0c.0 Class 0104: 1103:0007 (rev 01)°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
> > >           I/O at 0x00000300 [size=0x8]°°
> > >           I/O at 0x00000308 [size=0x4]
> > >           I/O at 0x00000310 [size=0x8]
> > >           I/O at 0x00000318 [size=0x4]
> > >           I/O at 0x00000400 [size=0x100]
> > >   00:0d.0 Class 0604: 1011:0022 (rev 02)
> > >           Bridge: primary=00, secondary=01
> > >   Scanning sub bus 01, I/O 0x00001000, Mem 0x40000000
> > >   01:07.0 Class 0607: 104c:ac56°°°°°°°°°°°°°°°°°°°°°°
> > >           Mem at 0x40000000 [size=0x1000]
> > >           Mem unavailable -- skipping°°°°
> > >           I/O at 0x00001000 [size=0x4]
> > >           Mem at 0x40001000 [size=0x1000]
> > >           Mem at 0x40002000 [size=0x1000]
> > >           Mem at 0x40003000 [size=0x1000]
> > >   Back to bus 00°°°°°°°°°°°°°°°°°°°°°°°°°
> > > 
> > > lspci -v gives:
> > >   
> > >   00:0c.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0007
> > >   (rev 01)
> > >           Subsystem: Triones Technologies, Inc.: Unknown device 0001
> > >           Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 1
> > >           I/O ports at 0300 [size=8]
> > >           I/O ports at 0308 [size=4]
> > >           I/O ports at 0310 [size=8]
> > >           I/O ports at 0318 [size=4]
> > >           I/O ports at 0400 [size=256]
> > >           Expansion ROM at <unassigned> [disabled] [size=128K]
> > >           Capabilities: [60] Power Management version 2
> > >   
> > >   00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 02)
> > >   (prog-if 00 [Normal decode])
> > >           Flags: bus master, medium devsel, latency 0
> > >           Bus: primary=00, secondary=01, subordinate=1f, sec-latency=0
> > >           I/O behind bridge: 00001000-00001fff     
> > >           Memory behind bridge: 40000000-400fffff  
> > >           Prefetchable memory behind bridge: 0000000000000000-0000000000000000
> > >   
> > >   01:07.0 CardBus bridge: Texas Instruments: Unknown device ac56
> > >           Subsystem: Unknown device 5678:1234      
> > >           Flags: bus master, medium devsel, latency 128, IRQ 255
> > >           Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
> > >           Bus: primary=00, secondary=10, subordinate=00, sec-latency=0
> > >           Memory window 0: 40001000-40002000 (prefetchable)
> > >           I/O window 0: 00000000-00000003
> > >           I/O window 1: 00000000-00000003
> > >           16-bit legacy interface ports at 0001    
> > > 
> > > root@10.1.1.154:~# modprobe yenta_socket                       
> > > 
> > >   Linux Kernel Card Services 3.1.22
> > >     options:  [pci] [cardbus]°°°°°°
> > >   config_writel: c0112bd0 0044 00000000
> > >   config_writel: c0112bd0 0010 40000000
> > >   config_writew: c0112bd0 0004 0087°°°°
> > >   config_writeb: c0112bd0 000c 08°°
> > >   config_writeb: c0112bd0 000d a8
> > >   config_writel: c0112bd0 0018 b0001000
> > >   config_readw: c0112bd0 003e 0340°°°°°
> > >   config_writew: c0112bd0 003e 0580
> > >   exca_writeb: c0112bd0 001e 00°°°°
> > >   exca_writeb: c0112bd0 0016 00
> > >   cb_writel: c0112bd0 000c 00004000
> > >   cb_writel: c0112bd0 0004 00000000
> > >   config_readl: c0112bd0 001c 40001000
> > >   config_readl: c0112bd0 0020 40002000
> > >   config_readl: c0112bd0 0024 40003000
> > >   config_readl: c0112bd0 0028 00000000
> > >   config_writel: c0112bd0 0024 10000000
> > >   config_writel: c0112bd0 0028 103fffff
> > >   config_readl: c0112bd0 002c 00000000°
> > >   config_readl: c0112bd0 0030 00000000
> > >   config_writel: c0112bd0 002c 00004000
> > >   config_writel: c0112bd0 0030 000040ff
> > >   config_readl: c0112bd0 0034 00000000°
> > >   config_readl: c0112bd0 0038 00000000
> > >   config_writel: c0112bd0 0034 00004400
> > >   config_writel: c0112bd0 0038 000044ff
> > >   config_readw: c0112bd0 003e 05c0°°°°°
> > >   cb_writel: c0112bd0 0000 ffffffff
> > >   cb_writel: c0112bd0 0004 00000001
> > >   exca_writeb: c0112bd0 0005 00°°°°
> > >   warning: end_irq 60 did not enable (6)
> > >   warning: end_irq 59 did not enable (6)
> > >   warning: end_irq 58 did not enable (6)
> > >   warning: end_irq 57 did not enable (6)
> > >   warning: end_irq 55 did not enable (6)
> > >   warning: end_irq 52 did not enable (6)
> > >   warning: end_irq 48 did not enable (6)
> > >   warning: end_irq 46 did not enable (6)
> > >   warning: end_irq 45 did not enable (6)
> > >   warning: end_irq 44 did not enable (6)
> > >   warning: end_irq 43 did not enable (6)
> > >   warning: end_irq 42 did not enable (6)
> > >   warning: end_irq 41 did not enable (6)
> > >   warning: end_irq 40 did not enable (6)
> > >   warning: end_irq 39 did not enable (6)
> > >   warning: end_irq 38 did not enable (6)
> > >   warning: end_irq 31 did not enable (6)
> > >   warning: end_irq 27 did not enable (6)
> > >   warning: end_irq 18 did not enable (6)
> > >   warning: end_irq 14 did not enable (6)
> > >   warning: end_irq 5 did not enable (6)°
> > >   warning: end_irq 4 did not enable (6)
> > >   warning: end_irq 2 did not enable (6)
> > >   warning: end_irq 1 did not enable (6)
> > >   warning: end_irq 60 did not enable (16)
> > >   warning: end_irq 59 did not enable (16)
> > >   warning: end_irq 58 did not enable (16)
> > >   warning: end_irq 57 did not enable (16)
> > >   warning: end_irq 55 did not enable (16)
> > >   warning: end_irq 52 did not enable (16)
> > >   warning: end_irq 48 did not enable (16)
> > >   warning: end_irq 46 did not enable (16)
> > >   warning: end_irq 45 did not enable (16)
> > >   warning: end_irq 44 did not enable (16)
> > >   warning: end_irq 43 did not enable (16)
> > >   warning: end_irq 42 did not enable (16)
> > >   warning: end_irq 41 did not enable (16)
> > >   warning: end_irq 40 did not enable (16)
> > >   warning: end_irq 39 did not enable (16)
> > >   warning: end_irq 38 did not enable (16)
> > >   warning: end_irq 27 did not enable (16)
> > >   warning: end_irq 18 did not enable (16)
> > >   warning: end_irq 5 did not enable (16)°
> > >   warning: end_irq 4 did not enable (16)
> > >   warning: end_irq 2 did not enable (16)
> > >   warning: end_irq 1 did not enable (16)
> > >   exca_writeb: c0112bd0 0005 31°°°°°°°°°
> > >   cb_writel: c0112bd0 000c 00000001
> > >   cb_writel: c0112bd0 0000 ffffffff
> > >   exca_writeb: c0112bd0 0005 91°°°°
> > >   cb_writel: c0112bd0 000c 00000001
> > >   cb_writel: c0112bd0 0000 ffffffff
> > >   exca_writeb: c0112bd0 0005 a1°°°°
> > >   cb_writel: c0112bd0 000c 00000001
> > >   cb_writel: c0112bd0 0000 ffffffff
> > >   exca_writeb: c0112bd0 0005 b1°°°°
> > >   cb_writel: c0112bd0 000c 00000001
> > >   cb_writel: c0112bd0 0000 ffffffff
> > >   cb_writel: c0112bd0 0004 00000000
> > >   exca_writeb: c0112bd0 0005 00°°°°
> > >   config_writew: c0112bd0 003e 0540
> > >   Yenta IRQ list 0000, PCI irq0°°°°
> > >   cb_readl: c0112bd0 0008 30000020
> > >   Socket status: 30000020°°°°°°°°°
> > >   config_writel: c0112bd0 0044 00000000
> > >   config_writel: c0112bd0 0010 40000000
> > >   config_writew: c0112bd0 0004 0087°°°°
> > >   config_writeb: c0112bd0 000c 08°°
> > >   config_writeb: c0112bd0 000d a8
> > >   config_writel: c0112bd0 0018 b0001000
> > >   config_readw: c0112bd0 003e 0540°°°°°
> > >   config_writew: c0112bd0 003e 0580
> > >   exca_writeb: c0112bd0 001e 00°°°°
> > >   exca_writeb: c0112bd0 0016 00
> > >   cb_writel: c0112bd0 000c 00004000
> > >   cb_readl: c0112bd0 0010 00000400°
> > >   cb_writel: c0112bd0 0010 00000000
> > >   config_readw: c0112bd0 003e 05c0°
> > >   cb_readl: c0112bd0 0008 30000820
> > >   exca_readb: c0112bd0 0003 00°°°°
> > >   exca_writeb: c0112bd0 0003 00
> > >   config_writew: c0112bd0 003e 0580
> > >   cb_writel: c0112bd0 0000 ffffffff
> > >   cb_writel: c0112bd0 0004 00000006
> > >   exca_readb: c0112bd0 0006 00°°°°°
> > >   exca_writew: c0112bd0 0008 0000
> > >   exca_writew: c0112bd0 000a 0001
> > >   exca_readb: c0112bd0 0007 00°°°
> > >   exca_writeb: c0112bd0 0007 00
> > >   exca_readb: c0112bd0 0006 00°
> > >   exca_writew: c0112bd0 000c 0000
> > >   exca_writew: c0112bd0 000e 0001
> > >   exca_readb: c0112bd0 0007 00°°°
> > >   exca_writeb: c0112bd0 0007 00
> > >   exca_readb: c0112bd0 0006 00°
> > >   exca_writeb: c0112bd0 0040 00
> > >   exca_writew: c0112bd0 0010 0000
> > >   exca_writew: c0112bd0 0012 0000
> > >   exca_writew: c0112bd0 0014 0000
> > >   ..... etc etc 
> > >   
> > > Thanks, all, for the information. I hope someone finds this useful!
> > > I'm gonna get remote kgdb goin' here, so I can hopefully fix the obnoxious
> > > infinite loop...
> > > 
> > > -Jeff
> > > 
> > > 
> > > On Fri, Feb 28, 2003 at 10:15:58PM -0800, Pete Popov wrote:
> > > > On Fri, 2003-02-28 at 19:48, Jeff Baitis wrote:
> > > > > Hey Pete and others!
> > > > > 
> > > > > I'm finally working on CardBus support on the DBAu1500. Just got acquainted
> > > > > with PCI today. :)
> > > > > 
> > > > > I decided that the first step is to plug in a PCI->PCI bridge, and try to see
> > > > > if it would work, which it did not. After winding around inside of the kernel,
> > > > > I finally arrived in arch/mips/au1000/db1x00/pci_ops.c:
> > > > > 
> > > > > Inside of config_access(unsigned char access_type, struct pci_dev *dev,
> > > > > unsigned char where, u32 * data), on line 97, a little surprise:
> > > > > 
> > > > >     if (bus != 0) {
> > > > >         *data = 0xffffffff;
> > > > >         return -1;
> > > > >     }
> > > > > 
> > > > > At this point, I concluded that I cannot traverse a PCI-PCI or CardBus bridge,
> > > > > since any devices behind the bridge will require Type 1 Configuration Cycles,
> > > > > and it seems that only Type 0 is currently supported.
> > > > > 
> > > > > I assume that I should add code to handle the case where I need to generate
> > > > > Type 1 Configuration Cycles inside of config_access. Pete, since you authored
> > > > > this code, I thought I'd quickly run this by you to make sure that I'm on
> > > > > track.
> > > > > 
> > > > > Thanks for your suggestions!
> > > > 
> > > > Take a look at arch/mips/au1000/pb1500/pci_ops.c for type 1 config
> > > > access. The patch was courtesy of David Gathright and apparently I
> > > > missed adding it in the db1500. Actually, we need to combine that code
> > > > because it's the same. Let me get through my eternal struggle of getting
> > > > the 36 bit patch applied (with Ralf's help I think a modified patch
> > > > should be ready this weekend) and then I'll worry about clean ups :)
> > > > 
> > > > Pete
> > > > 
> > > > 
> > > 
> > > -- 
> > >          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 ralf@linux-mips.net Wed Mar 12 05:12:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 05:12:07 +0000 (GMT)
Received: from p508B6845.dip.t-dialin.net ([IPv6:::ffff:80.139.104.69]:29104
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225193AbTCLFMG>; Wed, 12 Mar 2003 05:12:06 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2C5BtT29109;
	Wed, 12 Mar 2003 06:11:55 +0100
Date: Wed, 12 Mar 2003 06:11:55 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Teresa Tao <Teresat@tridentmicro.com>
Cc: linux-mips@linux-mips.org
Subject: Re: specify the user mode program's physical address
Message-ID: <20030312061155.A406@linux-mips.org>
References: <61F6477DE6BED311B69F009027C3F5840213109C@Exchange.tridentmicro.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: <61F6477DE6BED311B69F009027C3F5840213109C@Exchange.tridentmicro.com>; from Teresat@tridentmicro.com on Tue, Mar 11, 2003 at 06:05:11PM -0800
Return-Path: <ralf@linux-mips.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: 1694
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 263
Lines: 9

On Tue, Mar 11, 2003 at 06:05:11PM -0800, Teresa Tao wrote:

> Is there a way for linux to specify the physical address for a user mode program? So my program will load into the specified physical memory.

No.

What is the problem you're trying to solve?

  Ralf

From ipv6_san@rediffmail.com Wed Mar 12 07:09:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 07:09:07 +0000 (GMT)
Received: from webmail29.rediffmail.com ([IPv6:::ffff:203.199.83.39]:42184
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225193AbTCLHJH>; Wed, 12 Mar 2003 07:09:07 +0000
Received: (qmail 21026 invoked by uid 510); 12 Mar 2003 07:08:17 -0000
Date: 12 Mar 2003 07:08:17 -0000
Message-ID: <20030312070817.21025.qmail@webmail29.rediffmail.com>
Received: from unknown (194.175.117.86) by rediffmail.com via HTTP; 12 mar 2003 07:08:17 -0000
MIME-Version: 1.0
From: "Santosh " <ipv6_san@rediffmail.com>
Reply-To: "Santosh " <ipv6_san@rediffmail.com>
To: usagi-users@linux-ipv6.org
Cc: linux-mips@linux-mips.org
Subject: Usagi kernel for MIPS target
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <ipv6_san@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1695
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ipv6_san@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 543
Lines: 25

Hello All,

I'm interested in compiling Usagi kernel for a MIPS 32-bit 
board.
I have a set of MIPS cross-compiler tools, ex: mipsel-linux-gcc, 
etc and gcc version 2.95.3.

Can someone tell me what changes i have to make to compile the 
sources successfully for MIPS target ???

As anyone tested Usagi for MIPS target ?? Hints pls.

Thanks

-Santosh
-----------------------------------------





__________________________________________________________
Great Travel Deals, Airfares, Hotels on
http://www.journeymart.com/rediff/travel.asp


From kunitake@linux-ipv6.org Wed Mar 12 08:02:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 08:02:16 +0000 (GMT)
Received: from [IPv6:::ffff:211.16.123.115] ([IPv6:::ffff:211.16.123.115]:61682
	"EHLO stardust") by linux-mips.org with ESMTP id <S8225193AbTCLICQ>;
	Wed, 12 Mar 2003 08:02:16 +0000
Received: from stardust ([127.0.0.1])
	by stardust with smtp (Exim 3.36 #1 (Debian))
	id 18t1BG-0001nE-00; Wed, 12 Mar 2003 17:01:42 +0900
Date: Wed, 12 Mar 2003 17:01:41 +0900
From: KUNITAKE Koichi <kunitake@linux-ipv6.org>
To: usagi-users@linux-ipv6.org
Cc: linux-mips@linux-mips.org
Subject: Re: (usagi-users 02263) Usagi kernel for MIPS target
In-Reply-To: <20030312070817.21025.qmail@webmail29.rediffmail.com>
References: <20030312070817.21025.qmail@webmail29.rediffmail.com>
X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-debian-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <E18t1BG-0001nE-00@stardust>
Return-Path: <kunitake@linux-ipv6.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1696
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kunitake@linux-ipv6.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1093
Lines: 38

  Hello,

On 12 Mar 2003 07:08:17 -0000
"Santosh " <ipv6_san@rediffmail.com> wrote:

>Can someone tell me what changes i have to make to compile the 
>sources successfully for MIPS target ???

  I have never compiled USAGI for MIPS target, but I think you
should edit linux24/Makefile as following.


--- Makefile.orig       2003-03-12 16:55:06.000000000 +0900
+++ Makefile    2003-03-12 16:55:32.000000000 +0900
@@ -5,7 +5,8 @@
 
 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
 
-ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
+#ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
+ARCH := mips
 KERNELPATH=kernel-$(shell echo $(KERNELRELEASE) | sed -e "s/-//g")
 
 CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
@@ -19,7 +20,7 @@
 HOSTCC         = gcc
 HOSTCFLAGS     = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
 
-CROSS_COMPILE  =
+CROSS_COMPILE  = mips-linux-
 
 #
 # Include the make variables (CC, etc...)


  Did this fail?

Best regards,

From ipv6_san@rediffmail.com Wed Mar 12 08:50:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 08:50:34 +0000 (GMT)
Received: from webmail27.rediffmail.com ([IPv6:::ffff:203.199.83.37]:6313 "HELO
	rediffmail.com") by linux-mips.org with SMTP id <S8225193AbTCLIud>;
	Wed, 12 Mar 2003 08:50:33 +0000
Received: (qmail 7399 invoked by uid 510); 12 Mar 2003 08:49:46 -0000
Date: 12 Mar 2003 08:49:46 -0000
Message-ID: <20030312084946.7398.qmail@webmail27.rediffmail.com>
Received: from unknown (194.175.117.86) by rediffmail.com via HTTP; 12 mar 2003 08:49:46 -0000
MIME-Version: 1.0
From: "Santosh " <ipv6_san@rediffmail.com>
Reply-To: "Santosh " <ipv6_san@rediffmail.com>
To: "KUNITAKE Koichi" <kunitake@linux-ipv6.org>
Cc: linux-mips@linux-mips.org, usagi-users@linux-ipv6.org
Subject: Re: Re: (usagi-users 02263) Usagi kernel for MIPS target
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <ipv6_san@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1697
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ipv6_san@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2237
Lines: 86

i tried compiling this way

# make ARCH=mips xconfig
i get
ERROR - Attempting to write value for unconfigured variable 
(CONFIG_VTAG_ICACHE)
ERROR - Attempting to write value for unconfigured variable 
(CONFIG_BINFMT_ELF32)
ERROR - Attempting to write value for unconfigured variable 
(CONFIG_SERIAL)
ERROR - Attempting to write value for unconfigured variable 
(CONFIG_RTC)

Don't know what's wrong.
I have configured for MIPS Malta (Experimental) board

then i did # make ARCH=mips dep

finally # make ARCH=mips CROSS_COMPILE=mipsel-linux-

Now i get
binfmt_elf.c: In function 'load_elf_interp':
binfmt_elf.c:278: 'EF_MIPS_ABI2' undeclared
binfmt_elf.c:278: 'EF_MIPS_ABI' undeclared
make[2]:Leaving directory '/home/user/usagi/kernel/linux24/fs'
make:***[_dir_fs]Error 2

Is Usagi stable on MIPS Malta board ??
Pls tell me what's wrong.

-Santosh
------------------------------------------


On Wed, 12 Mar 2003 KUNITAKE Koichi wrote :
>   Hello,
>
>On 12 Mar 2003 07:08:17 -0000
>"Santosh " <ipv6_san@rediffmail.com> wrote:
>
> >Can someone tell me what changes i have to make to compile 
>the
> >sources successfully for MIPS target ???
>
>   I have never compiled USAGI for MIPS target, but I think you
>should edit linux24/Makefile as following.
>
>
>--- Makefile.orig       2003-03-12 16:55:06.000000000 +0900
>+++ Makefile    2003-03-12 16:55:32.000000000 +0900
>@@ -5,7 +5,8 @@
>
>  
>KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
>
>-ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e 
>s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
>+#ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e 
>s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
>+ARCH := mips
>  KERNELPATH=kernel-$(shell echo $(KERNELRELEASE) | sed -e 
>"s/-//g")
>
>  CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; 
>\
>@@ -19,7 +20,7 @@
>  HOSTCC         = gcc
>  HOSTCFLAGS     = -Wall -Wstrict-prototypes -O2 
>-fomit-frame-pointer
>
>-CROSS_COMPILE  =
>+CROSS_COMPILE  = mips-linux-
>
>  #
>  # Include the make variables (CC, etc...)
>
>
>   Did this fail?
>
>Best regards,
>

__________________________________________________________
Great Travel Deals, Airfares, Hotels on
http://www.journeymart.com/rediff/travel.asp


From tk@mycable.de Wed Mar 12 09:04:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 09:04:01 +0000 (GMT)
Received: from [IPv6:::ffff:62.116.167.108] ([IPv6:::ffff:62.116.167.108]:18853
	"EHLO oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8225193AbTCLJEA>; Wed, 12 Mar 2003 09:04:00 +0000
Received: from mycable.de (p5086B0E2.dip.t-dialin.net [80.134.176.226])
	(authenticated bits=0)
	by oricom4.internetx.de (8.12.8/8.12.8) with ESMTP id h2C90kH7012453;
	Wed, 12 Mar 2003 10:00:46 +0100
Message-ID: <3E6EF89A.6050207@mycable.de>
Date: Wed, 12 Mar 2003 10:06:34 +0100
From: Tiemo Krueger - mycable GmbH <tk@mycable.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Santosh <ipv6_san@rediffmail.com>
CC: linux-mips@linux-mips.org
Subject: Re: (usagi-users 02263) Usagi kernel for MIPS target
References: <20030312084946.7398.qmail@webmail27.rediffmail.com>
In-Reply-To: <20030312084946.7398.qmail@webmail27.rediffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <tk@mycable.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1698
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tk@mycable.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2926
Lines: 106

I had some time ago some trouble with xconfig, it seems that some
dependencies between configuration topics are not setup properly for MIPS
try the normal 'config' instead.
I remember that RTC was one of the appearing problems

Tiemo

Santosh wrote:

> i tried compiling this way
>
> # make ARCH=mips xconfig
> i get
> ERROR - Attempting to write value for unconfigured variable 
> (CONFIG_VTAG_ICACHE)
> ERROR - Attempting to write value for unconfigured variable 
> (CONFIG_BINFMT_ELF32)
> ERROR - Attempting to write value for unconfigured variable 
> (CONFIG_SERIAL)
> ERROR - Attempting to write value for unconfigured variable (CONFIG_RTC)
>
> Don't know what's wrong.
> I have configured for MIPS Malta (Experimental) board
>
> then i did # make ARCH=mips dep
>
> finally # make ARCH=mips CROSS_COMPILE=mipsel-linux-
>
> Now i get
> binfmt_elf.c: In function 'load_elf_interp':
> binfmt_elf.c:278: 'EF_MIPS_ABI2' undeclared
> binfmt_elf.c:278: 'EF_MIPS_ABI' undeclared
> make[2]:Leaving directory '/home/user/usagi/kernel/linux24/fs'
> make:***[_dir_fs]Error 2
>
> Is Usagi stable on MIPS Malta board ??
> Pls tell me what's wrong.
>
> -Santosh
> ------------------------------------------
>
>
> On Wed, 12 Mar 2003 KUNITAKE Koichi wrote :
>
>>   Hello,
>>
>> On 12 Mar 2003 07:08:17 -0000
>> "Santosh " <ipv6_san@rediffmail.com> wrote:
>>
>> >Can someone tell me what changes i have to make to compile the
>> >sources successfully for MIPS target ???
>>
>>   I have never compiled USAGI for MIPS target, but I think you
>> should edit linux24/Makefile as following.
>>
>>
>> --- Makefile.orig       2003-03-12 16:55:06.000000000 +0900
>> +++ Makefile    2003-03-12 16:55:32.000000000 +0900
>> @@ -5,7 +5,8 @@
>>
>>  
>> KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
>>
>> -ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ 
>> -e s/arm.*/arm/ -e s/sa110/arm/)
>> +#ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ 
>> -e s/arm.*/arm/ -e s/sa110/arm/)
>> +ARCH := mips
>>  KERNELPATH=kernel-$(shell echo $(KERNELRELEASE) | sed -e "s/-//g")
>>
>>  CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
>> @@ -19,7 +20,7 @@
>>  HOSTCC         = gcc
>>  HOSTCFLAGS     = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
>>
>> -CROSS_COMPILE  =
>> +CROSS_COMPILE  = mips-linux-
>>
>>  #
>>  # Include the make variables (CC, etc...)
>>
>>
>>   Did this fail?
>>
>> Best regards,
>>
>
> __________________________________________________________
> Great Travel Deals, Airfares, Hotels on
> http://www.journeymart.com/rediff/travel.asp
>
>
>


-- 
-------------------------------------------------------
Tiemo Krueger       Tel:  +49 48 73 90 19 86
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: tk@mycable.de

Public Kryptographic Key is available on request
-------------------------------------------------------



From kunitake@linux-ipv6.org Wed Mar 12 10:21:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 10:21:15 +0000 (GMT)
Received: from [IPv6:::ffff:211.16.123.115] ([IPv6:::ffff:211.16.123.115]:62198
	"EHLO stardust") by linux-mips.org with ESMTP id <S8225199AbTCLKVP>;
	Wed, 12 Mar 2003 10:21:15 +0000
Received: from stardust ([127.0.0.1])
	by stardust with smtp (Exim 3.36 #1 (Debian))
	id 18t3LT-0002It-00; Wed, 12 Mar 2003 19:20:23 +0900
Date: Wed, 12 Mar 2003 19:20:22 +0900
From: KUNITAKE Koichi <kunitake@linux-ipv6.org>
To: usagi-users@linux-ipv6.org
Cc: linux-mips@linux-mips.org
Subject: Re: (usagi-users 02267) Re: Usagi kernel for MIPS target
In-Reply-To: <20030312084946.7398.qmail@webmail27.rediffmail.com>
References: <20030312084946.7398.qmail@webmail27.rediffmail.com>
X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-debian-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <E18t3LT-0002It-00@stardust>
Return-Path: <kunitake@linux-ipv6.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1699
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kunitake@linux-ipv6.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1159
Lines: 41

  I think you cant use "xconfig" on Cross-compiling env, please edit
linux24/Makefile and use "make config". After all, please exec following
commands.

$ make config
$ make dep; make clean; make zImage

On 12 Mar 2003 08:49:46 -0000
"Santosh " <ipv6_san@rediffmail.com> wrote:

>i tried compiling this way
>
># make ARCH=mips xconfig
>i get
>ERROR - Attempting to write value for unconfigured variable 
>(CONFIG_VTAG_ICACHE)
>ERROR - Attempting to write value for unconfigured variable 
>(CONFIG_BINFMT_ELF32)
>ERROR - Attempting to write value for unconfigured variable 
>(CONFIG_SERIAL)
>ERROR - Attempting to write value for unconfigured variable 
>(CONFIG_RTC)
>
>Don't know what's wrong.
>I have configured for MIPS Malta (Experimental) board
>
>then i did # make ARCH=mips dep
>
>finally # make ARCH=mips CROSS_COMPILE=mipsel-linux-
>
>Now i get
>binfmt_elf.c: In function 'load_elf_interp':
>binfmt_elf.c:278: 'EF_MIPS_ABI2' undeclared
>binfmt_elf.c:278: 'EF_MIPS_ABI' undeclared
>make[2]:Leaving directory '/home/user/usagi/kernel/linux24/fs'
>make:***[_dir_fs]Error 2
>
>Is Usagi stable on MIPS Malta board ??
>Pls tell me what's wrong.
>
>-Santosh

From quintela@mandrakesoft.com Wed Mar 12 11:08:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 11:09:00 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:53776 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225199AbTCLLI7>;
	Wed, 12 Mar 2003 11:08:59 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 49CC26EC; Wed, 12 Mar 2003 12:08:58 +0100 (CET)
To: KUNITAKE Koichi <kunitake@linux-ipv6.org>
Cc: usagi-users@linux-ipv6.org, linux-mips@linux-mips.org
Subject: Re: (usagi-users 02267) Re: Usagi kernel for MIPS target
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <E18t3LT-0002It-00@stardust> (KUNITAKE Koichi's message of
 "Wed, 12 Mar 2003 19:20:22 +0900")
References: <20030312084946.7398.qmail@webmail27.rediffmail.com>
	<E18t3LT-0002It-00@stardust>
Date: Wed, 12 Mar 2003 12:08:58 +0100
Message-ID: <86y93kalkl.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1700
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 578
Lines: 21

>>>>> "kunitake" == KUNITAKE Koichi <kunitake@linux-ipv6.org> writes:

kunitake> I think you cant use "xconfig" on Cross-compiling env, please edit
kunitake> linux24/Makefile and use "make config". After all, please exec following
kunitake> commands.

kunitake> $ make config
kunitake> $ make dep; make clean; make zImage

I bet that a make vmlinux or make vmlinux.ecoff is better than zImage
on mips :p

Go to source.

My mips tree don't have a zImage at all :p

Later, juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From hilik@netvision.net.il Wed Mar 12 11:28:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 11:28:10 +0000 (GMT)
Received: from msg2p.netvision.net.il ([IPv6:::ffff:194.90.9.4]:59789 "EHLO
	msg2p.netvision.net.il") by linux-mips.org with ESMTP
	id <S8225199AbTCLL2J>; Wed, 12 Mar 2003 11:28:09 +0000
Received: from netvision.net.il ([194.90.9.5]) by msg2s.netvision.net.il
 (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002))
 with ESMTP id <0HBM00DQMVUQ79@msg2s.netvision.net.il> for
 linux-mips@linux-mips.org; Wed, 12 Mar 2003 13:28:02 +0200 (IST)
Received: from [194.90.9.13] by msg2s.netvision.net.il (mshttpd); Wed,
 12 Mar 2003 13:28:02 +0200
Date: Wed, 12 Mar 2003 13:28:02 +0200
From: Hilik Stein <hilik@netvision.net.il>
Subject: allocating a large memory area
To: linux-mips@linux-mips.org
Message-id: <438113fe62.3fe6243811@netvision.net.il>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002)
Content-type: text/plain; charset=us-ascii
Content-language: he
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: he
Priority: normal
Return-Path: <hilik@netvision.net.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: 1701
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hilik@netvision.net.il
Precedence: bulk
X-list: linux-mips
Content-Length: 744
Lines: 17

Hi All 
i am building a kernel based fast packet handler which runs on kernel 
2.4.20. 
my code resides inside the kernel, which is running on sb1 core. 
i need to allocate a large memory region for my data (32MB), which is far 
beyond what kmalloc can provide for me. 
i do not want to use vmalloc, since it will allocate the memory out of 
KSEG2, which is too slow and will generate too many exceptions when i 
have to access my data randomly. 
i was thinking of limiting the linux from accessing the highest physical 
32MB by using "mem=224M" kernel command line parameter. this was i 
can access my data using 0x8e000000 through KSEG1. 
is this safe ? anything i need to consider before moving forward with that 
approach ? 
thanks 
Hilik


From ipv6_san@rediffmail.com Wed Mar 12 11:43:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 11:43:56 +0000 (GMT)
Received: from webmail15.rediffmail.com ([IPv6:::ffff:203.199.83.25]:12521
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225199AbTCLLnz>; Wed, 12 Mar 2003 11:43:55 +0000
Received: (qmail 15052 invoked by uid 510); 12 Mar 2003 11:43:09 -0000
Date: 12 Mar 2003 11:43:09 -0000
Message-ID: <20030312114309.15051.qmail@webmail15.rediffmail.com>
Received: from unknown (194.175.117.86) by rediffmail.com via HTTP; 12 mar 2003 11:43:09 -0000
MIME-Version: 1.0
From: "Santosh " <ipv6_san@rediffmail.com>
Reply-To: "Santosh " <ipv6_san@rediffmail.com>
To: usagi-users@linux-ipv6.org
Cc: "KUNITAKE Koichi" <kunitake@linux-ipv6.org>,
	linux-mips@linux-mips.org
Subject: Re: (usagi-users 02268) Re: Usagi kernel for MIPS target
Content-type: multipart/mixed;
	boundary="Next_1047469389---0-203.199.83.25-15017"
Return-Path: <ipv6_san@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1702
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ipv6_san@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 52096
Lines: 768

 This is a multipart mime message


--Next_1047469389---0-203.199.83.25-15017
Content-type: text/plain;
	format=flowed
Content-Disposition: inline

thanks.
i followed the give steps.

When it comes to mips specific code, i get a string of errors.
pls go through the file attached.

TIA.

-Santosh
---------------------------------

On Wed, 12 Mar 2003 KUNITAKE Koichi wrote :
>   I think you cant use "xconfig" on Cross-compiling env, please 
>edit
>linux24/Makefile and use "make config". After all, please exec 
>following
>commands.
>
>$ make config
>$ make dep; make clean; make zImage
>
>On 12 Mar 2003 08:49:46 -0000
>"Santosh " <ipv6_san@rediffmail.com> wrote:
>
> >i tried compiling this way
> >
> ># make ARCH=mips xconfig
> >i get
> >ERROR - Attempting to write value for unconfigured variable
> >(CONFIG_VTAG_ICACHE)
> >ERROR - Attempting to write value for unconfigured variable
> >(CONFIG_BINFMT_ELF32)
> >ERROR - Attempting to write value for unconfigured variable
> >(CONFIG_SERIAL)
> >ERROR - Attempting to write value for unconfigured variable
> >(CONFIG_RTC)
> >
> >Don't know what's wrong.
> >I have configured for MIPS Malta (Experimental) board
> >
> >then i did # make ARCH=mips dep
> >
> >finally # make ARCH=mips CROSS_COMPILE=mipsel-linux-
> >
> >Now i get
> >binfmt_elf.c: In function 'load_elf_interp':
> >binfmt_elf.c:278: 'EF_MIPS_ABI2' undeclared
> >binfmt_elf.c:278: 'EF_MIPS_ABI' undeclared
> >make[2]:Leaving directory 
>'/home/user/usagi/kernel/linux24/fs'
> >make:***[_dir_fs]Error 2
> >
> >Is Usagi stable on MIPS Malta board ??
> >Pls tell me what's wrong.
> >
> >-Santosh
>
>

__________________________________________________________
Great Travel Deals, Airfares, Hotels on
http://r.rediff.com/r?www.journeymart.com/rediff/travel.asp&&sign&&jmart

--Next_1047469389---0-203.199.83.25-15017
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="errors"

Ci9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVk
ZS9saW51eC9ieXRlb3JkZXIvc3dhYi5oOjE4NzogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25v
cmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgfScuCi9ob21lL3NhbnRvc2gvVXNh
Z2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9ieXRlb3JkZXIv
c3dhYi5oOjE4NzogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVk
IGNoYXJhY3RlciBpcyBgfScuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2Vy
bmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9ieXRlb3JkZXIvc3dhYi5oOjE4ODogRXJyb3I6
IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgfScu
Ci9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVk
ZS9saW51eC9ieXRlb3JkZXIvc3dhYi5oOjE4OTogRXJyb3I6IHVucmVjb2duaXplZCBvcGNv
ZGUgYHN0YXRpYyBfX2lubGluZV9fIF9fdTMyIF9fc3dhYjMycChfX3UzMip4KScKL2hvbWUv
c2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4
L2J5dGVvcmRlci9zd2FiLmg6MTkwOiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZp
cnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGB7Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5l
bC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2J5dGVvcmRlci9zd2FiLmg6
MTkxOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgcmV0dXJuICh7X191MzIgX190bXA9
KCooeCkpJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvbGludXgvYnl0ZW9yZGVyL3N3YWIuaDoxOTE6IEVycm9yOiBSZXN0IG9mIGxp
bmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYCgnLgovaG9tZS9zYW50
b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgvYnl0
ZW9yZGVyL3N3YWIuaDoxOTE6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3Qg
aWdub3JlZCBjaGFyYWN0ZXIgaXMgYCgnLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3Vz
YWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgvYnl0ZW9yZGVyL3N3YWIuaDoxOTE6
IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIg
aXMgYH0nLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvbGludXgvYnl0ZW9yZGVyL3N3YWIuaDoxOTE6IEVycm9yOiBSZXN0IG9mIGxp
bmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYH0nLgovaG9tZS9zYW50
b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgvYnl0
ZW9yZGVyL3N3YWIuaDoxOTI6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3Qg
aWdub3JlZCBjaGFyYWN0ZXIgaXMgYH0nLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3Vz
YWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgvYnl0ZW9yZGVyL3N3YWIuaDoxOTM6
IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBzdGF0aWMgX19pbmxpbmVfXyB2b2lkIF9f
c3dhYjMycyhfX3UzMiphZGRyKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9r
ZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2J5dGVvcmRlci9zd2FiLmg6MTk0OiBFcnJv
cjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGB7
Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNs
dWRlL2xpbnV4L2J5dGVvcmRlci9zd2FiLmg6MTk1OiBFcnJvcjogdW5yZWNvZ25pemVkIG9w
Y29kZSBgZG8geyooYWRkcik9KHtfX3UzMiBfX3RtcD0oKigoYWRkcikpKScKL2hvbWUvc2Fu
dG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2J5
dGVvcmRlci9zd2FiLmg6MTk1OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0
IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGAoJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91
c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2J5dGVvcmRlci9zd2FiLmg6MTk1
OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVy
IGlzIGAoJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgy
NC9pbmNsdWRlL2xpbnV4L2J5dGVvcmRlci9zd2FiLmg6MTk1OiBFcnJvcjogUmVzdCBvZiBs
aW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGB9Jy4KL2hvbWUvc2Fu
dG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2J5
dGVvcmRlci9zd2FiLmg6MTk1OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0
IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGB9Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91
c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2J5dGVvcmRlci9zd2FiLmg6MTk1
OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVy
IGlzIGB9Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgy
NC9pbmNsdWRlL2xpbnV4L2J5dGVvcmRlci9zd2FiLmg6MTk2OiBFcnJvcjogUmVzdCBvZiBs
aW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGB9Jy4KL2hvbWUvc2Fu
dG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2J5
dGVvcmRlci9nZW5lcmljLmg6MTUwOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0
ZXJuIF9fdTMyIG50b2hsKF9fdTMyKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2Fn
aS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2J5dGVvcmRlci9nZW5lcmljLmg6MTUx
OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJuIF9fdTMyIGh0b25sKF9fdTMy
KScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNs
dWRlL2xpbnV4L2J5dGVvcmRlci9nZW5lcmljLmg6MTU2OiBFcnJvcjogdW5yZWNvZ25pemVk
IG9wY29kZSBgZXh0ZXJuIHVuc2lnbmVkIHNob3J0IGludCBudG9ocyh1bnNpZ25lZCBzaG9y
dCBpbnQpJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvbGludXgvYnl0ZW9yZGVyL2dlbmVyaWMuaDoxNTc6IEVycm9yOiB1bnJlY29n
bml6ZWQgb3Bjb2RlIGBleHRlcm4gdW5zaWduZWQgc2hvcnQgaW50IGh0b25zKHVuc2lnbmVk
IHNob3J0IGludCknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xp
bnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDo0MTogRXJyb3I6IHVucmVjb2duaXplZCBv
cGNvZGUgYGV4dGVybiBpbnQgY29uc29sZV9wcmludGtbXScKL2hvbWUvc2FudG9zaC9Vc2Fn
aUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjU4
OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgc3RydWN0IGNvbXBsZXRpb24nCi9ob21l
L3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51
eC9rZXJuZWwuaDo2MDogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYGV4dGVybiBzdHJ1
Y3Qgbm90aWZpZXJfYmxvY2sqcGFuaWNfbm90aWZpZXJfbGlzdCcKL2hvbWUvc2FudG9zaC9V
c2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5o
OjYxOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgdm9pZCBwYW5pYyhjb25zdCBjaGFy
KmZtdCwuLi4pJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51
eDI0L2luY2x1ZGUvbGludXgva2VybmVsLmg6NjI6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bj
b2RlIGBfX2F0dHJpYnV0ZV9fICgobm9yZXR1cm4sZm9ybWF0KHByaW50ZiwxLDIpKSknCi9o
b21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9s
aW51eC9rZXJuZWwuaDo2MzogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYHZvaWQgZG9f
ZXhpdChsb25nIGVycm9yX2NvZGUpJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdp
L2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgva2VybmVsLmg6NjQ6IEVycm9yOiB1bnJl
Y29nbml6ZWQgb3Bjb2RlIGBfX2F0dHJpYnV0ZV9fKChub3JldHVybikpJwovaG9tZS9zYW50
b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgva2Vy
bmVsLmg6NjU6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB2b2lkIGNvbXBsZXRlX2Fu
ZF9leGl0KHN0cnVjdCBjb21wbGV0aW9uKixsb25nKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtl
cm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjY2OiBF
cnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgX19hdHRyaWJ1dGVfXygobm9yZXR1cm4pKScK
L2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRl
L2xpbnV4L2tlcm5lbC5oOjY3OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJu
IGludCBhYnMoaW50KScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwv
bGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjY4OiBFcnJvcjogdW5yZWNvZ25pemVk
IG9wY29kZSBgZXh0ZXJuIHVuc2lnbmVkIGxvbmcgc2ltcGxlX3N0cnRvdWwoY29uc3QgY2hh
ciosY2hhcioqLHVuc2lnbmVkIGludCknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNh
Z2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDo2OTogRXJyb3I6IHVu
cmVjb2duaXplZCBvcGNvZGUgYGV4dGVybiBsb25nIHNpbXBsZV9zdHJ0b2woY29uc3QgY2hh
ciosY2hhcioqLHVuc2lnbmVkIGludCknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNh
Z2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDo3MDogRXJyb3I6IHVu
cmVjb2duaXplZCBvcGNvZGUgYGV4dGVybiB1bnNpZ25lZCBsb25nIGxvbmcgc2ltcGxlX3N0
cnRvdWxsKGNvbnN0IGNoYXIqLGNoYXIqKix1bnNpZ25lZCBpbnQpJwovaG9tZS9zYW50b3No
L1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgva2VybmVs
Lmg6NzE6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBleHRlcm4gbG9uZyBsb25nIHNp
bXBsZV9zdHJ0b2xsKGNvbnN0IGNoYXIqLGNoYXIqKix1bnNpZ25lZCBpbnQpJwovaG9tZS9z
YW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgv
a2VybmVsLmg6NzI6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBleHRlcm4gaW50IHNw
cmludGYoY2hhcipidWYsY29uc3QgY2hhcipmbXQsLi4uKScKL2hvbWUvc2FudG9zaC9Vc2Fn
aUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjcz
OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgX19hdHRyaWJ1dGVfXyAoKGZvcm1hdChw
cmludGYsMiwzKSkpJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9s
aW51eDI0L2luY2x1ZGUvbGludXgva2VybmVsLmg6NzQ6IEVycm9yOiB1bnJlY29nbml6ZWQg
b3Bjb2RlIGBleHRlcm4gaW50IHZzcHJpbnRmKGNoYXIqYnVmLGNvbnN0IGNoYXIqLHZhX2xp
c3QpJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2lu
Y2x1ZGUvbGludXgva2VybmVsLmg6NzU6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBl
eHRlcm4gaW50IHNucHJpbnRmKGNoYXIqYnVmLHNpemVfdCBzaXplLGNvbnN0IGNoYXIqZm10
LC4uLiknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQv
aW5jbHVkZS9saW51eC9rZXJuZWwuaDo3NjogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUg
YF9fYXR0cmlidXRlX18gKChmb3JtYXQocHJpbnRmLDMsNCkpKScKL2hvbWUvc2FudG9zaC9V
c2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5o
Ojc3OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJuIGludCB2c25wcmludGYo
Y2hhcipidWYsc2l6ZV90IHNpemUsY29uc3QgY2hhcipmbXQsdmFfbGlzdCBhcmdzKScKL2hv
bWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xp
bnV4L2tlcm5lbC5oOjc5OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJuIGlu
dCBzc2NhbmYoY29uc3QgY2hhciosY29uc3QgY2hhciosLi4uKScKL2hvbWUvc2FudG9zaC9V
c2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5o
OjgwOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgX19hdHRyaWJ1dGVfXyAoKGZvcm1h
dChzY2FuZiwyLDMpKSknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVs
L2xpbnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDo4MTogRXJyb3I6IHVucmVjb2duaXpl
ZCBvcGNvZGUgYGV4dGVybiBpbnQgdnNzY2FuZihjb25zdCBjaGFyKixjb25zdCBjaGFyKix2
YV9saXN0KScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgy
NC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjgzOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29k
ZSBgZXh0ZXJuIGludCBnZXRfb3B0aW9uKGNoYXIqKnN0cixpbnQqcGludCknCi9ob21lL3Nh
bnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9r
ZXJuZWwuaDo4NDogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYGV4dGVybiBjaGFyKmdl
dF9vcHRpb25zKGNoYXIqc3RyLGludCBuaW50cyxpbnQqaW50cyknCi9ob21lL3NhbnRvc2gv
VXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwu
aDo4NTogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYGV4dGVybiB1bnNpZ25lZCBsb25n
IGxvbmcgbWVtcGFyc2UoY2hhcipwdHIsY2hhcioqcmV0cHRyKScKL2hvbWUvc2FudG9zaC9V
c2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5o
Ojg2OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJuIHZvaWQgZGV2X3Byb2Jl
X2xvY2sodm9pZCknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xp
bnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDo4NzogRXJyb3I6IHVucmVjb2duaXplZCBv
cGNvZGUgYGV4dGVybiB2b2lkIGRldl9wcm9iZV91bmxvY2sodm9pZCknCi9ob21lL3NhbnRv
c2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9rZXJu
ZWwuaDo4OTogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYGV4dGVybiBpbnQgc2Vzc2lv
bl9vZl9wZ3JwKGludCBwZ3JwKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9r
ZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjkxOiBFcnJvcjogdW5yZWNv
Z25pemVkIG9wY29kZSBgaW50IHByaW50ayhjb25zdCBjaGFyKmZtdCwuLi4pJwovaG9tZS9z
YW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgv
a2VybmVsLmg6OTI6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBfX2F0dHJpYnV0ZV9f
ICgoZm9ybWF0KHByaW50ZiwxLDIpKSknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNh
Z2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDo5NDogRXJyb3I6IHVu
cmVjb2duaXplZCBvcGNvZGUgYHN0YXRpYyBpbmxpbmUgdm9pZCBjb25zb2xlX3NpbGVudCh2
b2lkKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9p
bmNsdWRlL2xpbnV4L2tlcm5lbC5oOjk1OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQu
IEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGB7Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtl
cm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjk2OiBF
cnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlz
IGAoJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9p
bmNsdWRlL2xpbnV4L2tlcm5lbC5oOjk3OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQu
IEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGB9Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtl
cm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjk5OiBF
cnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgc3RhdGljIGlubGluZSB2b2lkIGNvbnNvbGVf
dmVyYm9zZSh2b2lkKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwv
bGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjEwMDogRXJyb3I6IFJlc3Qgb2YgbGlu
ZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgeycuCi9ob21lL3NhbnRv
c2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9rZXJu
ZWwuaDoxMDE6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBpZiAoKGNvbnNvbGVfcHJp
bnRrWzBdKSknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4
MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDoxMDI6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdu
b3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYCgnLgovaG9tZS9zYW50b3NoL1Vz
YWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgva2VybmVsLmg6
MTAzOiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFj
dGVyIGlzIGB9Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGlu
dXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjEwNTogRXJyb3I6IHVucmVjb2duaXplZCBv
cGNvZGUgYGV4dGVybiB2b2lkIGJ1c3Rfc3BpbmxvY2tzKGludCB5ZXMpJwovaG9tZS9zYW50
b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgva2Vy
bmVsLmg6MTA2OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJuIGludCBvb3Bz
X2luX3Byb2dyZXNzJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9s
aW51eDI0L2luY2x1ZGUvbGludXgva2VybmVsLmg6MTA4OiBFcnJvcjogdW5yZWNvZ25pemVk
IG9wY29kZSBgZXh0ZXJuIGludCB0YWludGVkJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVs
L3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgva2VybmVsLmg6MTA5OiBFcnJv
cjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJuIGNvbnN0IGNoYXIqcHJpbnRfdGFpbnRl
ZCh2b2lkKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgy
NC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjExMTogRXJyb3I6IHVucmVjb2duaXplZCBvcGNv
ZGUgYGV4dGVybiB2b2lkIGR1bXBfc3RhY2sodm9pZCknCi9ob21lL3NhbnRvc2gvVXNhZ2lL
ZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDoxNzQ6
IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBleHRlcm4gdm9pZCBfX291dF9vZl9saW5l
X2J1ZyhpbnQgbGluZSlfX2F0dHJpYnV0ZV9fKChub3JldHVybikpJwovaG9tZS9zYW50b3No
L1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgva2VybmVs
Lmg6MTgwOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgc3RydWN0IHN5c2luZm97Jwov
aG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUv
bGludXgva2VybmVsLmg6MTgxOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgbG9uZyB1
cHRpbWUnCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQv
aW5jbHVkZS9saW51eC9rZXJuZWwuaDoxODI6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2Rl
IGB1bnNpZ25lZCBsb25nIGxvYWRzWzNdJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3Vz
YWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGludXgva2VybmVsLmg6MTgzOiBFcnJvcjog
dW5yZWNvZ25pemVkIG9wY29kZSBgdW5zaWduZWQgbG9uZyB0b3RhbHJhbScKL2hvbWUvc2Fu
dG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tl
cm5lbC5oOjE4NDogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYHVuc2lnbmVkIGxvbmcg
ZnJlZXJhbScvaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvbGludXgva2VybmVsLmg6MTg1OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29k
ZSBgdW5zaWduZWQgbG9uZyBzaGFyZWRyYW0nCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwv
dXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDoxODY6IEVycm9y
OiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIGJ1ZmZlcnJhbScKL2hvbWUv
c2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4
L2tlcm5lbC5oOjE4NzogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYHVuc2lnbmVkIGxv
bmcgdG90YWxzd2FwJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9s
aW51eDI0L2luY2x1ZGUvbGludXgva2VybmVsLmg6MTg4OiBFcnJvcjogdW5yZWNvZ25pemVk
IG9wY29kZSBgdW5zaWduZWQgbG9uZyBmcmVlc3dhcCcKL2hvbWUvc2FudG9zaC9Vc2FnaUtl
cm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4L2tlcm5lbC5oOjE4OTog
RXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYHVuc2lnbmVkIHNob3J0IHByb2NzJwovaG9t
ZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGlu
dXgva2VybmVsLmg6MTkwOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgdW5zaWduZWQg
c2hvcnQgcGFkJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51
eDI0L2luY2x1ZGUvbGludXgva2VybmVsLmg6MTkxOiBFcnJvcjogdW5yZWNvZ25pemVkIG9w
Y29kZSBgdW5zaWduZWQgbG9uZyB0b3RhbGhpZ2gnCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJu
ZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDoxOTI6IEVy
cm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIGZyZWVoaWdoJwovaG9t
ZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvbGlu
dXgva2VybmVsLmg6MTkzOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgdW5zaWduZWQg
aW50IG1lbV91bml0Jy9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xp
bnV4MjQvaW5jbHVkZS9saW51eC9rZXJuZWwuaDoxOTQ6IEVycm9yOiB1bnJlY29nbml6ZWQg
b3Bjb2RlIGBjaGFyIF9mWzIwLTIqc2l6ZW9mKGxvbmcpLXNpemVvZihpbnQpXScKL2hvbWUv
c2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2xpbnV4
L2tlcm5lbC5oOjE5NTogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25v
cmVkIGNoYXJhY3RlciBpcyBgfScuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kv
a2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHRyYWNlLmg6MzE6IEVycm9yOiB1bnJlY29n
bml6ZWQgb3Bjb2RlIGBzdHJ1Y3QgcHRfcmVnc3snCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJu
ZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHRyYWNlLmg6MzM6IEVycm9y
OiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIHBhZDBbNl0nCi9ob21lL3Nh
bnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHRy
YWNlLmg6MzY6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIHJl
Z3NbMzJdJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvYXNtL3B0cmFjZS5oOjM5OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBg
dW5zaWduZWQgbG9uZyBsbycKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJu
ZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wdHJhY2UuaDo0MDogRXJyb3I6IHVucmVjb2duaXpl
ZCBvcGNvZGUgYHVuc2lnbmVkIGxvbmcgaGknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwv
dXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHRyYWNlLmg6NDU6IEVycm9yOiB1
bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIGNwMF9lcGMnCi9ob21lL3NhbnRv
c2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHRyYWNl
Lmg6NDY6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIGNwMF9i
YWR2YWRkcicKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgy
NC9pbmNsdWRlL2FzbS9wdHJhY2UuaDo0NzogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUg
YHVuc2lnbmVkIGxvbmcgY3AwX3N0YXR1cycvaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3Vz
YWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3B0cmFjZS5oOjQ4OiBFcnJvcjogdW5y
ZWNvZ25pemVkIG9wY29kZSBgdW5zaWduZWQgbG9uZyBjcDBfY2F1c2UnCi9ob21lL3NhbnRv
c2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHRyYWNl
Lmg6NDk6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFy
YWN0ZXIKaXMgYH0nLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9s
aW51eDI0L2luY2x1ZGUvYXNtL3B0cmFjZS5oOjEwNjogRXJyb3I6IHVucmVjb2duaXplZCBv
cGNvZGUgYGV4dGVybiB2b2lkIHNob3dfcmVncyhzdHJ1Y3QgcHRfcmVncyopJwovaG9tZS9z
YW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5
c3RlbS5oOjI3OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgX19hc21fXyAoJwovaG9t
ZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNt
L3N5c3RlbS5oOjI4OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9y
ZWQgY2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9r
ZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoyOTogRXJyb3I6IFJlc3Qgb2Yg
bGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlcgppcyBgIicuCi9ob21lL3Nh
bnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lz
dGVtLmg6MzA6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBj
aGFyYWN0ZXIKaXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5l
bC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjMxOiBFcnJvcjogUmVzdCBvZiBsaW5l
IGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUvc2FudG9z
aC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0u
aDozMjogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJh
Y3RlcgppcyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xp
bnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6MzM6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdu
b3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIKaXMgYCInLgovaG9tZS9zYW50b3NoL1Vz
YWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjM0
OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVy
CmlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgy
NC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDozNTogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVk
LiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlcgppcyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lL
ZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6MzY6IEVy
cm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIKaXMg
YCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2lu
Y2x1ZGUvYXNtL3N5c3RlbS5oOjM3OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZp
cnN0IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5l
bC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDozOTogRXJyb3I6
IHVucmVjb2duaXplZCBvcGNvZGUgYGV4dGVybiBfX2lubGluZV9fIHZvaWQnCi9ob21lL3Nh
bnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lz
dGVtLmg6NDA6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBfX3N0aSh2b2lkKScKL2hv
bWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2Fz
bS9zeXN0ZW0uaDo0MTogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25v
cmVkIGNoYXJhY3RlcgppcyBgeycuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kv
a2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6NDI6IEVycm9yOiB1bnJlY29n
bml6ZWQgb3Bjb2RlIGBfX2FzbV9fIF9fdm9sYXRpbGVfXygnCi9ob21lL3NhbnRvc2gvVXNh
Z2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6NDM6
IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIK
aXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjQ0OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQu
IEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGA6Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtl
cm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDo0NTogRXJy
b3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlcgppcyBg
OicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5j
bHVkZS9hc20vc3lzdGVtLmg6NDY6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmly
c3QgaWdub3JlZCBjaGFyYWN0ZXIKaXMgYDonLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVs
L3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjQ3OiBFcnJvcjog
UmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGB9Jy4K
L2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRl
L2FzbS9zeXN0ZW0uaDo1NjogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYF9fYXNtX18g
KCcKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNs
dWRlL2FzbS9zeXN0ZW0uaDo1NzogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJz
dCBpZ25vcmVkIGNoYXJhY3RlcgppcyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwv
dXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6NTg6IEVycm9yOiBS
ZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIKaXMgYCInLgov
aG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUv
YXNtL3N5c3RlbS5oOjU5OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGln
bm9yZWQgY2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2Fn
aS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDo2MDogRXJyb3I6IFJlc3Qg
b2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlcgppcyBgIicuCi9ob21l
L3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20v
c3lzdGVtLmg6NjE6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3Jl
ZCBjaGFyYWN0ZXIKaXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tl
cm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjYyOiBFcnJvcjogUmVzdCBvZiBs
aW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUvc2Fu
dG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0
ZW0uaDo2MzogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNo
YXJhY3RlcgppcyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVs
L2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6NjQ6IEVycm9yOiBSZXN0IG9mIGxpbmUg
aWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIKaXMgYCInLgovaG9tZS9zYW50b3No
L1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5o
OjY1OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFj
dGVyCmlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGlu
dXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDo2NjogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25v
cmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlcgppcyBgIicuCi9ob21lL3NhbnRvc2gvVXNh
Z2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6Njc6
IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIK
aXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjY4OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQu
IEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtl
cm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDo2OTogRXJy
b3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlcgppcyBg
IicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5j
bHVkZS9hc20vc3lzdGVtLmg6NzE6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBleHRl
cm4gX19pbmxpbmVfXyB2b2lkJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tl
cm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjcyOiBFcnJvcjogdW5yZWNvZ25p
emVkIG9wY29kZSBgX19jbGkodm9pZCknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNh
Z2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6NzM6IEVycm9yOiBSZXN0
IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIKaXMgYHsnLgovaG9t
ZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNt
L3N5c3RlbS5oOjc0OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgX19hc21fXyBfX3Zv
bGF0aWxlX18oJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51
eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjc1OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9y
ZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2Fn
aUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDo3Njog
RXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3Rlcgpp
cyBgOicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQv
aW5jbHVkZS9hc20vc3lzdGVtLmg6Nzc6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4g
Rmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIKaXMgYDonLgovaG9tZS9zYW50b3NoL1VzYWdpS2Vy
bmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjc4OiBFcnJv
cjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGA6
Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNs
dWRlL2FzbS9zeXN0ZW0uaDo3OTogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJz
dCBpZ25vcmVkIGNoYXJhY3RlcgppcyBgfScuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwv
dXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6ODE6IEVycm9yOiB1
bnJlY29nbml6ZWQgb3Bjb2RlIGBfX2FzbV9fICgnCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJu
ZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6ODI6IEVycm9y
OiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIKaXMgYCIn
LgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1
ZGUvYXNtL3N5c3RlbS5oOjgzOiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0
IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91
c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDo4NDogRXJyb3I6IFJl
c3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlcgppcyBgIicuCi9o
b21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9h
c20vc3lzdGVtLmg6ODU6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdu
b3JlZCBjaGFyYWN0ZXIKaXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdp
L2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjg2OiBFcnJvcjogUmVzdCBv
ZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUv
c2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9z
eXN0ZW0uaDo4NzogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVk
IGNoYXJhY3RlcgppcyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2Vy
bmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6OTQ6IEVycm9yOiB1bnJlY29nbml6
ZWQgb3Bjb2RlIGBfX2FzbV9fICgnCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kv
a2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6OTU6IEVycm9yOiBSZXN0IG9m
IGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIKaXMgYCInLgovaG9tZS9z
YW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5
c3RlbS5oOjk2OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQg
Y2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJu
ZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDo5NzogRXJyb3I6IFJlc3Qgb2YgbGlu
ZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlcgppcyBgIicuCi9ob21lL3NhbnRv
c2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVt
Lmg6OTg6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFy
YWN0ZXIKaXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9s
aW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjk5OiBFcnJvcjogUmVzdCBvZiBsaW5lIGln
bm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyCmlzIGAiJy4KL2hvbWUvc2FudG9zaC9V
c2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDox
MDA6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0
ZXIgaXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51
eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjEwMTogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25v
cmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgIicuCi9ob21lL3NhbnRvc2gvVXNh
Z2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6MTAy
OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVy
IGlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgy
NC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoxMDM6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3Jl
ZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdp
S2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjEwNDog
RXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBp
cyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQv
aW5jbHVkZS9hc20vc3lzdGVtLmg6MTA1OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQu
IEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtl
cm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoxMDY6IEVy
cm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMg
YCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2lu
Y2x1ZGUvYXNtL3N5c3RlbS5oOjEwNzogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBG
aXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJu
ZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6MTA4OiBFcnJv
cjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGAi
Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNs
dWRlL2FzbS9zeXN0ZW0uaDoxMTc6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBfX2Fz
bV9fKCInCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQv
aW5jbHVkZS9hc20vc3lzdGVtLmg6MTE4OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQu
IEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtl
cm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoxMTk6IEVy
cm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMg
YCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2lu
Y2x1ZGUvYXNtL3N5c3RlbS5oOjEyMDogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBG
aXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJu
ZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6MTIxOiBFcnJv
cjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGAi
Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNs
dWRlL2FzbS9zeXN0ZW0uaDoxMjI6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmly
c3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVs
L3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjEyMzogRXJyb3I6
IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgIicu
Ci9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVk
ZS9hc20vc3lzdGVtLmg6MTI0OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0
IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91
c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoxMjU6IEVycm9yOiBS
ZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYCInLgov
aG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUv
YXNtL3N5c3RlbS5oOjEyNjogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBp
Z25vcmVkIGNoYXJhY3RlciBpcyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNh
Z2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6MTI3OiBFcnJvcjogUmVz
dCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGAiJy4KL2hv
bWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2Fz
bS9zeXN0ZW0uaDoxMjg6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdu
b3JlZCBjaGFyYWN0ZXIgaXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdp
L2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjEyOTogRXJyb3I6IFJlc3Qg
b2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgIicuCi9ob21l
L3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20v
c3lzdGVtLmg6MTMwOiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9y
ZWQgY2hhcmFjdGVyIGlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9r
ZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoxMzE6IEVycm9yOiBSZXN0IG9m
IGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYCInLgovaG9tZS9z
YW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5
c3RlbS5oOjI0NjogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYGV4dGVybiB2b2lkKnJl
c3VtZSh2b2lkKmxhc3Qsdm9pZCpuZXh0KScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91
c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoyNTE6IEVycm9yOiB1
bnJlY29nbml6ZWQgb3Bjb2RlIGBzdHJ1Y3QgdGFza19zdHJ1Y3QnCi9ob21lL3NhbnRvc2gv
VXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6
MjUzOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJuIHZvaWQgbGF6eV9mcHVf
c3dpdGNoKHZvaWQqKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwv
bGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoyNTQ6IEVycm9yOiB1bnJlY29nbml6ZWQg
b3Bjb2RlIGBleHRlcm4gdm9pZCBpbml0X2ZwdSh2b2lkKScKL2hvbWUvc2FudG9zaC9Vc2Fn
aUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoyNTU6
IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBleHRlcm4gdm9pZCBzYXZlX2ZwKHN0cnVj
dCB0YXNrX3N0cnVjdCopJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5l
bC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjI1NjogRXJyb3I6IHVucmVjb2duaXpl
ZCBvcGNvZGUgYGV4dGVybiB2b2lkIHJlc3RvcmVfZnAoc3RydWN0IHRhc2tfc3RydWN0Kikn
Ci9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVk
ZS9hc20vc3lzdGVtLmg6MjY3OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJu
IF9faW5saW5lX18gdW5zaWduZWQgbG9uZyB4Y2hnX3UzMih2b2xhdGlsZSBpbnQqbSx1bnNp
Z25lZCBsb25nIHZhbCknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVs
L2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6MjY4OiBFcnJvcjogUmVzdCBvZiBsaW5l
IGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGB7Jy4KL2hvbWUvc2FudG9z
aC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0u
aDoyNzA6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIGR1bW15
JwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1
ZGUvYXNtL3N5c3RlbS5oOjI3MjogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYF9fYXNt
X18gX192b2xhdGlsZV9fKCcKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJu
ZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoyNzM6IEVycm9yOiBSZXN0IG9mIGxp
bmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYCInLgovaG9tZS9zYW50
b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3Rl
bS5oOjI3NDogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNo
YXJhY3RlciBpcyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVs
L2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6Mjc1OiBFcnJvcjogUmVzdCBvZiBsaW5l
IGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGAiJy4KL2hvbWUvc2FudG9z
aC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0u
aDoyNzY6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFy
YWN0ZXIgaXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9s
aW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjI3NzogRXJyb3I6IFJlc3Qgb2YgbGluZSBp
Z25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgIicuCi9ob21lL3NhbnRvc2gv
VXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6
Mjc4OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFj
dGVyIGlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGlu
dXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoyNzk6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdu
b3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYCInLgovaG9tZS9zYW50b3NoL1Vz
YWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjI4
MDogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3Rl
ciBpcyBgIicuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4
MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6MjgxOiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9y
ZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGAiJy4KL2hvbWUvc2FudG9zaC9Vc2Fn
aUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDoyODI6
IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIg
aXMgYCInLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjI4MzogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVk
LiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgOicuCi9ob21lL3NhbnRvc2gvVXNhZ2lL
ZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6Mjg0OiBF
cnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlz
IGA6Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9p
bmNsdWRlL2FzbS9zeXN0ZW0uaDoyODU6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4g
Rmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYDonLgovaG9tZS9zYW50b3NoL1VzYWdpS2Vy
bmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjI4NzogRXJy
b3I6IHVucmVjb2duaXplZCBvcGNvZGUgYHJldHVybiB2YWwnCi9ob21lL3NhbnRvc2gvVXNh
Z2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6Mjk4
OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVy
IGlzIGB9Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgy
NC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDozMDM6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2Rl
IGBzdGF0aWMgX19pbmxpbmVfXyB1bnNpZ25lZCBsb25nJwovaG9tZS9zYW50b3NoL1VzYWdp
S2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjMwNDog
RXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYF9feGNoZyh1bnNpZ25lZCBsb25nIHgsdm9s
YXRpbGUgdm9pZCpwdHIsaW50IHNpemUpJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3Vz
YWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjMwNTogRXJyb3I6IFJl
c3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgeycuCi9o
b21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9h
c20vc3lzdGVtLmg6MzA2OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgc3dpdGNoIChz
aXplKXsnCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQv
aW5jbHVkZS9hc20vc3lzdGVtLmg6MzA3OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBg
Y2FzZSA0OicKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgy
NC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDozMDg6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2Rl
IGByZXR1cm4geGNoZ191MzIocHRyLHgpJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3Vz
YWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjMwOTogRXJyb3I6IFJl
c3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgfScuCi9o
b21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9h
c20vc3lzdGVtLmg6MzEwOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgcmV0dXJuIHgn
Ci9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVk
ZS9hc20vc3lzdGVtLmg6MzExOiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0
IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGB9Jy4KL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91
c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDozMTM6IEVycm9yOiB1
bnJlY29nbml6ZWQgb3Bjb2RlIGBleHRlcm4gdm9pZCpzZXRfZXhjZXB0X3ZlY3RvcihpbnQg
bix2b2lkKmFkZHIpJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9s
aW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjMxNTogRXJyb3I6IHVucmVjb2duaXplZCBv
cGNvZGUgYGV4dGVybiB2b2lkIF9fZGllKGNvbnN0CmNoYXIqLHN0cnVjdCBwdF9yZWdzKixj
b25zdCBjaGFyKmZpbGUsJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5l
bC9saW51eDI0L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjMxNjogRXJyb3I6IHVucmVjb2duaXpl
ZCBvcGNvZGUgYGNvbnN0IGNoYXIqZnVuYyx1bnNpZ25lZCBsb25nIGxpbmUpX19hdHRyaWJ1
dGVfXygobm9yZXR1cm4pKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJu
ZWwvbGludXgyNC9pbmNsdWRlL2FzbS9zeXN0ZW0uaDozMTc6IEVycm9yOiB1bnJlY29nbml6
ZWQgb3Bjb2RlIGBleHRlcm4gdm9pZCBfX2RpZV9pZl9rZXJuZWwoY29uc3QgY2hhciosc3Ry
dWN0IHB0X3JlZ3MqLGNvbnN0IGNoYXIqZmlsZSwnCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJu
ZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vc3lzdGVtLmg6MzE4OiBFcnJv
cjogdW5yZWNvZ25pemVkIG9wY29kZSBgY29uc3QgY2hhcipmdW5jLHVuc2lnbmVkIGxvbmcg
bGluZSknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQv
aW5jbHVkZS9hc20vcHJvY2Vzc29yLmg6MzE6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2Rl
IGBzdHJ1Y3QgY3B1aW5mb19taXBzeycKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2Fn
aS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDozMjogRXJyb3I6IHVu
cmVjb2duaXplZCBvcGNvZGUgYHVuc2lnbmVkIGxvbmcgdWRlbGF5X3ZhbCcKL2hvbWUvc2Fu
dG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9j
ZXNzb3IuaDozMzogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYHVuc2lnbmVkIGxvbmcq
cGdkX3F1aWNrJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51
eDI0L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjM0OiBFcnJvcjogdW5yZWNvZ25pemVkIG9w
Y29kZSBgdW5zaWduZWQgbG9uZypwdGVfcXVpY2snCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJu
ZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmg6MzU6IEVy
cm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIHBndGFibGVfY2FjaGVf
c3onCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5j
bHVkZS9hc20vcHJvY2Vzc29yLmg6MzY6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1
bnNpZ25lZCBsb25nIGFzaWRfY2FjaGUnCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNh
Z2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmg6Mzc6IEVycm9yOiBS
ZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYH0nLgov
aG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUv
YXNtL3Byb2Nlc3Nvci5oOjQyOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJu
IHZvaWQoKmNwdV93YWl0KSh2b2lkKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2Fn
aS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDo0MzogRXJyb3I6IHVu
cmVjb2duaXplZCBvcGNvZGUgYGV4dGVybiB2b2lkIHIzMDgxX3dhaXQodm9pZCknCi9ob21l
L3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20v
cHJvY2Vzc29yLmg6NDQ6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBleHRlcm4gdm9p
ZCByMzl4eF93YWl0KHZvaWQpJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tl
cm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjQ1OiBFcnJvcjogdW5yZWNv
Z25pemVkIG9wY29kZSBgZXh0ZXJuIHZvaWQgcjRrX3dhaXQodm9pZCknCi9ob21lL3NhbnRv
c2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHJvY2Vz
c29yLmg6NDY6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBleHRlcm4gdm9pZCBhdTFr
X3dhaXQodm9pZCknCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xp
bnV4MjQvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmg6NDg6IEVycm9yOiB1bnJlY29nbml6ZWQg
b3Bjb2RlIGBleHRlcm4gc3RydWN0IGNwdWluZm9fbWlwcyBjcHVfZGF0YVtdJwovaG9tZS9z
YW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3By
b2Nlc3Nvci5oOjQ5OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJuIHVuc2ln
bmVkIGludCB2Y2VkX2NvdW50LHZjZWlfY291bnQnCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJu
ZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmg6NjE6IEVy
cm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBleHRlcm4gaW50IEVJU0FfYnVzJwovaG9tZS9z
YW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3By
b2Nlc3Nvci5oOjc2OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJuIHN0cnVj
dCB0YXNrX3N0cnVjdCpsYXN0X3Rhc2tfdXNlZF9tYXRoJwovaG9tZS9zYW50b3NoL1VzYWdp
S2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjk4
OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgc3RydWN0IG1pcHNfZnB1X2hhcmRfc3Ry
dWN0eycKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9p
bmNsdWRlL2FzbS9wcm9jZXNzb3IuaDo5OTogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUg
YGRvdWJsZSBmcF9yZWdzWzMyXScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9r
ZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxMDA6IEVycm9yOiB1bnJl
Y29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBpbnQgY29udHJvbCcvaG9tZS9zYW50b3NoL1Vz
YWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5o
OjEwMTogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJh
Y3RlciBpcyBgfScuCi9ob21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xp
bnV4MjQvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmg6MTA5OiBFcnJvcjogdW5yZWNvZ25pemVk
IG9wY29kZSBgdHlwZWRlZiB1NjQgZnB1cmVnX3QnL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5l
bC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxMTA6IEVy
cm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBzdHJ1Y3QgbWlwc19mcHVfc29mdF9zdHJ1Y3R7
JwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1
ZGUvYXNtL3Byb2Nlc3Nvci5oOjExMTogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYGZw
dXJlZ190IHJlZ3NbMzJdJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5l
bC9saW51eDI0L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjExMjogRXJyb3I6IHVucmVjb2du
aXplZCBvcGNvZGUgYHVuc2lnbmVkIGludCBzcicKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5l
bC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxMTM6IEVy
cm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMg
YH0nLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2lu
Y2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjExNTogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUg
YHVuaW9uIG1pcHNfZnB1X3VuaW9ueycKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2Fn
aS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxMTY6IEVycm9yOiB1
bnJlY29nbml6ZWQgb3Bjb2RlIGBzdHJ1Y3QgbWlwc19mcHVfaGFyZF9zdHJ1Y3QgaGFyZCcK
L2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRl
L2FzbS9wcm9jZXNzb3IuaDoxMTc6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBzdHJ1
Y3QgbWlwc19mcHVfc29mdF9zdHJ1Y3Qgc29mdCcKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5l
bC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxMTg6IEVy
cm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMg
YH0nLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2lu
Y2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjEyNDogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUg
YHR5cGVkZWYgc3RydWN0eycKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJu
ZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxMjU6IEVycm9yOiB1bnJlY29n
bml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIHNlZycKL2hvbWUvc2FudG9zaC9Vc2FnaUtl
cm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxMjY6
IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIg
aXMgYH0nLgovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjEzMTogRXJyb3I6IHVucmVjb2duaXplZCBvcGNv
ZGUgYHN0cnVjdCB0aHJlYWRfc3RydWN0eycKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91
c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxMzM6IEVycm9y
OiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIHJlZzE2JwovaG9tZS9zYW50
b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3Byb2Nl
c3Nvci5oOjEzNDogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYHVuc2lnbmVkIGxvbmcg
cmVnMTcscmVnMTgscmVnMTkscmVnMjAscmVnMjEscmVnMjIscmVnMjMnCi9ob21lL3NhbnRv
c2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHJvY2Vz
c29yLmg6MTM1OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgdW5zaWduZWQgbG9uZyBy
ZWcyOSxyZWczMCxyZWczMScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJu
ZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxMzg6IEVycm9yOiB1bnJlY29n
bml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIGNwMF9zdGF0dXMnCi9ob21lL3NhbnRvc2gv
VXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHJvY2Vzc29y
Lmg6MTQxOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgdW5pb24gbWlwc19mcHVfdW5p
b24KZnB1JwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjE0NDogRXJyb3I6IHVucmVjb2duaXplZCBvcGNv
ZGUgYHVuc2lnbmVkIGxvbmcgY3AwX2JhZHZhZGRyJwovaG9tZS9zYW50b3NoL1VzYWdpS2Vy
bmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjE0NTog
RXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYHVuc2lnbmVkIGxvbmcgY3AwX2JhZHVhZGRy
JwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0L2luY2x1
ZGUvYXNtL3Byb2Nlc3Nvci5oOjE0NjogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYHVu
c2lnbmVkIGxvbmcgZXJyb3JfY29kZScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2Fn
aS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxNDc6IEVycm9yOiB1
bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIHRyYXBfbm8nCi9ob21lL3NhbnRv
c2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHJvY2Vz
c29yLmg6MTUwOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgdW5zaWduZWQgbG9uZyBt
ZmxhZ3MnL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9p
bmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxNTE6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2Rl
IGBtbV9zZWdtZW50X3QgY3VycmVudF9kcycKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91
c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoxNTI6IEVycm9y
OiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNpZ25lZCBsb25nIGlyaXhfdHJhbXBvbGluZScK
L2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRl
L2FzbS9wcm9jZXNzb3IuaDoxNTM6IEVycm9yOiB1bnJlY29nbml6ZWQgb3Bjb2RlIGB1bnNp
Z25lZCBsb25nIGlyaXhfb2xkY3R4JwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdp
L2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjE1NDogRXJyb3I6IFJl
c3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgfScuCi9o
b21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9h
c20vcHJvY2Vzc29yLmg6MTkxOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJu
IGludCBrZXJuZWxfdGhyZWFkKGludCgqZm4pKHZvaWQqKSx2b2lkKmFyZyx1bnNpZ25lZCBs
b25nIGZsYWdzKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91c2FnaS9rZXJuZWwvbGlu
dXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoyMDA6IEVycm9yOiB1bnJlY29nbml6ZWQg
b3Bjb2RlIGBzdGF0aWMgaW5saW5lIHVuc2lnbmVkIGxvbmcgdGhyZWFkX3NhdmVkX3BjKHN0
cnVjdCB0aHJlYWRfc3RydWN0KnQpJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdp
L2tlcm5lbC9saW51eDI0L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjIwMTogRXJyb3I6IFJl
c3Qgb2YgbGluZSBpZ25vcmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgeycuCi9o
b21lL3NhbnRvc2gvVXNhZ2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9h
c20vcHJvY2Vzc29yLmg6MjAyOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgZXh0ZXJu
IHZvaWQgcmV0X2Zyb21fZm9yayh2b2lkKScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91
c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoyMDU6IEVycm9y
OiB1bnJlY29nbml6ZWQgb3Bjb2RlIGBpZiAodC0+cmVnMzE9PSh1bnNpZ25lZCBsb25nKXJl
dF9mcm9tX2ZvcmspJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9s
aW51eDI0L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjIwNjogRXJyb3I6IHVucmVjb2duaXpl
ZCBvcGNvZGUgYHJldHVybiB0LT5yZWczMScKL2hvbWUvc2FudG9zaC9Vc2FnaUtlcm5lbC91
c2FnaS9rZXJuZWwvbGludXgyNC9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaDoyMDg6IEVycm9y
OiB1bnJlY29nbml6ZWQgb3Bjb2RlIGByZXR1cm4gKCh1bnNpZ25lZCBsb25nKil0LT5yZWcy
OSlbMTNdJwovaG9tZS9zYW50b3NoL1VzYWdpS2VybmVsL3VzYWdpL2tlcm5lbC9saW51eDI0
L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oOjIwOTogRXJyb3I6IFJlc3Qgb2YgbGluZSBpZ25v
cmVkLiBGaXJzdCBpZ25vcmVkIGNoYXJhY3RlciBpcyBgfScuCi9ob21lL3NhbnRvc2gvVXNh
Z2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmg6
MjIyOiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBgdW5zaWduZWQgbG9uZyBnZXRfd2No
YW4oc3RydWN0IHRhc2tfc3RydWN0KnApJwptYWtlWzFdOiAqKiogW2ludC1oYW5kbGVyLm9d
IEVycm9yIDEKbWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgYC9ob21lL3NhbnRvc2gvVXNh
Z2lLZXJuZWwvdXNhZ2kva2VybmVsL2xpbnV4MjQvYXJjaC9taXBzL2phenonCm1ha2U6ICoq
KiBbX2Rpcl9hcmNoL21pcHMvamF6el0gRXJyb3IgMgpbcm9vdEBsb2NhbGhvc3QgbGludXgy
NF0jCgo=

--Next_1047469389---0-203.199.83.25-15017--


From kunitake@linux-ipv6.org Wed Mar 12 15:05:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 15:05:57 +0000 (GMT)
Received: from eatkyo128013.adsl.ppp.infoweb.ne.jp ([IPv6:::ffff:218.217.47.13]:26920
	"EHLO stardust") by linux-mips.org with ESMTP id <S8225199AbTCLPF5>;
	Wed, 12 Mar 2003 15:05:57 +0000
Received: from stardust ([127.0.0.1])
	by stardust with smtp (Exim 3.36 #1 (Debian))
	id 18t7nK-0000SI-00; Thu, 13 Mar 2003 00:05:26 +0900
Date: Thu, 13 Mar 2003 00:05:24 +0900
From: KUNITAKE Koichi <kunitake@linux-ipv6.org>
To: usagi-users@linux-ipv6.org
Cc: linux-mips@linux-mips.org
Subject: Re: (usagi-users 02270) Re: Usagi kernel for MIPS target
In-Reply-To: <20030312114309.15051.qmail@webmail15.rediffmail.com>
References: <20030312114309.15051.qmail@webmail15.rediffmail.com>
X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-debian-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <E18t7nK-0000SI-00@stardust>
Return-Path: <kunitake@linux-ipv6.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1703
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kunitake@linux-ipv6.org
Precedence: bulk
X-list: linux-mips
Content-Length: 521
Lines: 23

  Uhm...

  You couldn't complie vanilla kernel, could you?
  I don't think you has failed in compile owing to USAGI's code.

  I'm sorry, I don't know details any more about cross-comiling.
  Does anyone know the cause of these errors?

Best regards,

On 12 Mar 2003 11:43:09 -0000
"Santosh " <ipv6_san@rediffmail.com> wrote:

>thanks.
>i followed the give steps.
>
>When it comes to mips specific code, i get a string of errors.
>pls go through the file attached.
>
>TIA.
>
>-Santosh
>---------------------------------

From ranjanp@efi.com Wed Mar 12 18:05:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Mar 2003 18:05:29 +0000 (GMT)
Received: from mail2.efi.com ([IPv6:::ffff:192.68.228.89]:45066 "HELO
	fcexgw02.efi.internal") by linux-mips.org with SMTP
	id <S8225199AbTCLSF3>; Wed, 12 Mar 2003 18:05:29 +0000
Received: from 10.3.12.13 by fcexgw02.efi.internal (InterScan E-Mail VirusWall NT); Wed, 12 Mar 2003 10:05:21 -0800
Received: by fcexbh02.efi.com with Internet Mail Service (5.5.2656.59)
	id <GY2RZMXF>; Wed, 12 Mar 2003 10:05:21 -0800
Message-ID: <D9F6B9DABA4CAE4B92850252C52383AB0796823C@ex-eng-corp.efi.com>
From: Ranjan Parthasarathy <ranjanp@efi.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Disabling lwl and lwr instruction generation
Date: Wed, 12 Mar 2003 10:05:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
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: 1704
X-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
Content-Length: 86
Lines: 5

Is there a way to tell gcc to not generate the lwl, lwr instructions?

Thanks

Ranjan

From ralf@linux-mips.net Thu Mar 13 00:03:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 00:03:58 +0000 (GMT)
Received: from p508B6845.dip.t-dialin.net ([IPv6:::ffff:80.139.104.69]:62657
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225199AbTCMAD5>; Thu, 13 Mar 2003 00:03:57 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2D03n606685;
	Thu, 13 Mar 2003 01:03:49 +0100
Date: Thu, 13 Mar 2003 01:03:49 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Hilik Stein <hilik@netvision.net.il>
Cc: linux-mips@linux-mips.org
Subject: Re: allocating a large memory area
Message-ID: <20030313010349.B29568@linux-mips.org>
References: <438113fe62.3fe6243811@netvision.net.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <438113fe62.3fe6243811@netvision.net.il>; from hilik@netvision.net.il on Wed, Mar 12, 2003 at 01:28:02PM +0200
Return-Path: <ralf@linux-mips.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: 1705
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1548
Lines: 33

On Wed, Mar 12, 2003 at 01:28:02PM +0200, Hilik Stein wrote:

> i am building a kernel based fast packet handler which runs on kernel 
> 2.4.20. 
> my code resides inside the kernel, which is running on sb1 core. 
> i need to allocate a large memory region for my data (32MB), which is far 
> beyond what kmalloc can provide for me. 
> i do not want to use vmalloc, since it will allocate the memory out of 
> KSEG2, which is too slow and will generate too many exceptions when i 
> have to access my data randomly. 
> i was thinking of limiting the linux from accessing the highest physical 
> 32MB by using "mem=224M" kernel command line parameter. this was i 
> can access my data using 0x8e000000 through KSEG1. 

0x8e000000 a KSEG0 address.  If you care about performance you don't want
to use KSEG1 :)

> is this safe ? anything i need to consider before moving forward with that 
> approach ? 

It's the only sensible approach.  __get_free_pages()'s limit for allocation
is order 10 by default which would like to PAGE_SIZE * 2^10 = 4MB by
default.  Increasing is possible by setting the config symbol
CONFIG_FORCE_MAX_ZONEORDER to the desired value - but that doesn't seem
like a good idea for a one-time allocation as it affects performance and
has heavy fragmentation issues.

kmalloc isn't suitable either.  It's got it's own limit of 128k which could
be raised but that doesn't make much sense for other reasons including the
fact that kmalloc is implemented on top of the gfp so the issues in the
last paragraph apply as well.

  Ralf

From brad@ltc.com Thu Mar 13 00:23:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 00:23:28 +0000 (GMT)
Received: from harrier.mail.pas.earthlink.net ([IPv6:::ffff:207.217.120.12]:18343
	"EHLO harrier.mail.pas.earthlink.net") by linux-mips.org with ESMTP
	id <S8225199AbTCMAX1>; Thu, 13 Mar 2003 00:23:27 +0000
Received: from sdn-ap-007masprip0443.dialsprint.net ([63.186.129.189] helo=lahoo.priv)
	by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 18tGVG-0005NT-00; Wed, 12 Mar 2003 16:23:23 -0800
Received: from prefect.priv ([10.1.1.102] helo=prefect)
	by lahoo.priv with smtp (Exim 3.36 #1 (Debian))
	id 18tGEM-000588-00; Wed, 12 Mar 2003 19:05:54 -0500
Message-ID: <01fe01c2e8f6$c41451a0$6601010a@prefect>
From: "Bradley D. LaRonde" <brad@ltc.com>
To: "Hilik Stein" <hilik@netvision.net.il>
Cc: <linux-mips@linux-mips.org>
References: <438113fe62.3fe6243811@netvision.net.il>
Subject: Re: allocating a large memory area
Date: Wed, 12 Mar 2003 19:23:26 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <brad@ltc.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1706
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brad@ltc.com
Precedence: bulk
X-list: linux-mips
Content-Length: 991
Lines: 26

----- Original Message -----
From: "Hilik Stein" <hilik@netvision.net.il>
To: <linux-mips@linux-mips.org>
Sent: Wednesday, March 12, 2003 6:28 AM
Subject: allocating a large memory area


> i need to allocate a large memory region for my data (32MB), which is far
> beyond what kmalloc can provide for me.
> i do not want to use vmalloc, since it will allocate the memory out of
> KSEG2, which is too slow and will generate too many exceptions when i
> have to access my data randomly.
> i was thinking of limiting the linux from accessing the highest physical
> 32MB by using "mem=224M" kernel command line parameter. this was i
> can access my data using 0x8e000000 through KSEG1.

Or put it below the kernel load point.

Or... I've used this trick - define a large array and let the linker make
space for it in .bss.  This is convenient since now the kernel has no
special requirement about load address or memory limit and the address can
just be a pointer to the array.

Regards,
Brad


From ralf@linux-mips.net Thu Mar 13 00:43:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 00:43:44 +0000 (GMT)
Received: from p508B6845.dip.t-dialin.net ([IPv6:::ffff:80.139.104.69]:34242
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225199AbTCMAnn>; Thu, 13 Mar 2003 00:43:43 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2D0hcn07412;
	Thu, 13 Mar 2003 01:43:38 +0100
Date: Thu, 13 Mar 2003 01:43:38 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Ranjan Parthasarathy <ranjanp@efi.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Disabling lwl and lwr instruction generation
Message-ID: <20030313014338.C29568@linux-mips.org>
References: <D9F6B9DABA4CAE4B92850252C52383AB0796823C@ex-eng-corp.efi.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: <D9F6B9DABA4CAE4B92850252C52383AB0796823C@ex-eng-corp.efi.com>; from ranjanp@efi.com on Wed, Mar 12, 2003 at 10:05:20AM -0800
Return-Path: <ralf@linux-mips.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: 1707
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 240
Lines: 8

On Wed, Mar 12, 2003 at 10:05:20AM -0800, Ranjan Parthasarathy wrote:

> Is there a way to tell gcc to not generate the lwl, lwr instructions?

Gcc will only ever generate these instructions when __attribute__((unaligned))
is used.

  Ralf

From rh@matriplex.com Thu Mar 13 00:51:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 00:51:17 +0000 (GMT)
Received: from [IPv6:::ffff:65.160.120.251] ([IPv6:::ffff:65.160.120.251]:49930
	"EHLO mail.matriplex.com") by linux-mips.org with ESMTP
	id <S8225199AbTCMAvQ>; Thu, 13 Mar 2003 00:51:16 +0000
Received: from mail.matriplex.com (mail.matriplex.com [65.160.120.251])
	by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id QAA00886;
	Wed, 12 Mar 2003 16:50:53 -0800 (PST)
	(envelope-from rh@matriplex.com)
Date: Wed, 12 Mar 2003 16:50:53 -0800 (PST)
From: Richard Hodges <rh@matriplex.com>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Ranjan Parthasarathy <ranjanp@efi.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Disabling lwl and lwr instruction generation
In-Reply-To: <20030313014338.C29568@linux-mips.org>
Message-ID: <Pine.BSF.4.50.0303121647400.95890-100000@mail.matriplex.com>
References: <D9F6B9DABA4CAE4B92850252C52383AB0796823C@ex-eng-corp.efi.com>
 <20030313014338.C29568@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <rh@matriplex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1708
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rh@matriplex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 554
Lines: 17

On Thu, 13 Mar 2003, Ralf Baechle wrote:

> On Wed, Mar 12, 2003 at 10:05:20AM -0800, Ranjan Parthasarathy wrote:
>
> > Is there a way to tell gcc to not generate the lwl, lwr instructions?
>
> Gcc will only ever generate these instructions when __attribute__((unaligned))
> is used.

I got lwl and lwr from a memcpy() with two void pointers...

I quickly changed those to the (aligned) structure pointers instead, and
then memcpy() changed to ordinary word loads and stores.

So, is somebody starting a toolchain for that new Chinese CPU? :-)

-Richard

From ica2_ts@csv.ica.uni-stuttgart.de Thu Mar 13 00:52:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 00:52:07 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:30639
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225199AbTCMAwF>; Thu, 13 Mar 2003 00:52:05 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 18tGx1-001qpe-00; Thu, 13 Mar 2003 01:52:03 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 18tGx1-00022v-00; Thu, 13 Mar 2003 01:52:03 +0100
Date: Thu, 13 Mar 2003 01:52:03 +0100
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Ranjan Parthasarathy <ranjanp@efi.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Disabling lwl and lwr instruction generation
Message-ID: <20030313005203.GH13122@rembrandt.csv.ica.uni-stuttgart.de>
References: <D9F6B9DABA4CAE4B92850252C52383AB0796823C@ex-eng-corp.efi.com> <20030313014338.C29568@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030313014338.C29568@linux-mips.org>
User-Agent: Mutt/1.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: 1709
X-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
Content-Length: 370
Lines: 13

Ralf Baechle wrote:
> On Wed, Mar 12, 2003 at 10:05:20AM -0800, Ranjan Parthasarathy wrote:
> 
> > Is there a way to tell gcc to not generate the lwl, lwr instructions?
> 
> Gcc will only ever generate these instructions when __attribute__((unaligned))
> is used.

Which might be not that obvious, e.g. __attribute__((packed)) can cause such
instructions, too.


Thiemo

From ralf@linux-mips.net Thu Mar 13 01:19:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 01:19:02 +0000 (GMT)
Received: from p508B6845.dip.t-dialin.net ([IPv6:::ffff:80.139.104.69]:1219
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225199AbTCMBTB>; Thu, 13 Mar 2003 01:19:01 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2D1ItA08153;
	Thu, 13 Mar 2003 02:18:55 +0100
Date: Thu, 13 Mar 2003 02:18:55 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Ranjan Parthasarathy <ranjanp@efi.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Disabling lwl and lwr instruction generation
Message-ID: <20030313021855.A7940@linux-mips.org>
References: <D9F6B9DABA4CAE4B92850252C52383AB0796823C@ex-eng-corp.efi.com> <20030313014338.C29568@linux-mips.org> <20030313005203.GH13122@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030313005203.GH13122@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Thu, Mar 13, 2003 at 01:52:03AM +0100
Return-Path: <ralf@linux-mips.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: 1710
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 528
Lines: 16

On Thu, Mar 13, 2003 at 01:52:03AM +0100, Thiemo Seufer wrote:

> > On Wed, Mar 12, 2003 at 10:05:20AM -0800, Ranjan Parthasarathy wrote:
> > 
> > > Is there a way to tell gcc to not generate the lwl, lwr instructions?
> > 
> > Gcc will only ever generate these instructions when __attribute__((unaligned))
> > is used.
> 
> Which might be not that obvious, e.g. __attribute__((packed)) can cause such
> instructions, too.

Typo - I meant __attribute__((packed)).  There is no such thing as
 __attribute__((unaligned)).

  Ralf

From ralf@linux-mips.net Thu Mar 13 01:33:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 01:33:59 +0000 (GMT)
Received: from p508B6845.dip.t-dialin.net ([IPv6:::ffff:80.139.104.69]:20163
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225199AbTCMBd6>; Thu, 13 Mar 2003 01:33:58 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2D1XjF08451;
	Thu, 13 Mar 2003 02:33:45 +0100
Date: Thu, 13 Mar 2003 02:33:45 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Richard Hodges <rh@matriplex.com>
Cc: Ranjan Parthasarathy <ranjanp@efi.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Disabling lwl and lwr instruction generation
Message-ID: <20030313023344.A7013@linux-mips.org>
References: <D9F6B9DABA4CAE4B92850252C52383AB0796823C@ex-eng-corp.efi.com> <20030313014338.C29568@linux-mips.org> <Pine.BSF.4.50.0303121647400.95890-100000@mail.matriplex.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: <Pine.BSF.4.50.0303121647400.95890-100000@mail.matriplex.com>; from rh@matriplex.com on Wed, Mar 12, 2003 at 04:50:53PM -0800
Return-Path: <ralf@linux-mips.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: 1711
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 672
Lines: 17

On Wed, Mar 12, 2003 at 04:50:53PM -0800, Richard Hodges wrote:

> I got lwl and lwr from a memcpy() with two void pointers...
> 
> I quickly changed those to the (aligned) structure pointers instead, and
> then memcpy() changed to ordinary word loads and stores.
> 
> So, is somebody starting a toolchain for that new Chinese CPU? :-)

Wouldn't be the first processor without lwl/lwr instructions.  There have
been a few that didn't implement it for silly bean^Wgate counting issues
others have done it for patent and licensing reasons.

(Afair MIPS's patent is about to expire and IBM's prior art patent in the
same area is even way older but that legalese ...)

  Ralf

From jsun@mvista.com Thu Mar 13 02:01:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 02:01:39 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:60399 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225199AbTCMCBi>;
	Thu, 13 Mar 2003 02:01:38 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h2D21ac02704;
	Wed, 12 Mar 2003 18:01:36 -0800
Date: Wed, 12 Mar 2003 18:01:36 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH] memory leak in ptrace 
Message-ID: <20030312180136.F24687@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="rwEMma7ioTxnRzrJ"
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: 1712
X-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
Content-Length: 4315
Lines: 184


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


Several places in sys_ptrace() don't decrease the page
count where they should.  This will cause memory leak
later when the traced task is freed.

This patch is initially brought up by Sony people and modified
by Drow and me.

Jun


--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="030312.2.4-ptrace-memory-leak.patch"

diff -Nru linux/arch/mips/kernel/ptrace.c.orig linux/arch/mips/kernel/ptrace.c
--- linux/arch/mips/kernel/ptrace.c.orig	Thu Nov  7 14:05:33 2002
+++ linux/arch/mips/kernel/ptrace.c	Wed Mar 12 17:28:34 2003
@@ -72,7 +72,7 @@
 
 	ret = -EPERM;
 	if (pid == 1)		/* you may not mess with init */
-		goto out;
+		goto out_tsk;
 
 	if (request == PTRACE_ATTACH) {
 		ret = ptrace_attach(child);
@@ -94,8 +94,7 @@
 		if (copied != sizeof(tmp))
 			break;
 		ret = put_user(tmp,(unsigned long *) data);
-
-		goto out;
+		break;
 		}
 
 	/* Read the word at location addr in the USER area.  */
@@ -164,10 +163,10 @@
 		default:
 			tmp = 0;
 			ret = -EIO;
-			goto out;
+			goto out_tsk;
 		}
 		ret = put_user(tmp, (unsigned long *) data);
-		goto out;
+		break;
 		}
 
 	case PTRACE_POKETEXT: /* write the word at location addr. */
@@ -177,7 +176,7 @@
 		    == sizeof(data))
 			break;
 		ret = -EIO;
-		goto out;
+		break;
 
 	case PTRACE_POKEUSR: {
 		struct pt_regs *regs;
@@ -277,7 +276,7 @@
 
 	default:
 		ret = -EIO;
-		goto out;
+		break;
 	}
 out_tsk:
 	free_task_struct(child);
diff -Nru linux/arch/mips64/kernel/ptrace.c.orig linux/arch/mips64/kernel/ptrace.c
--- linux/arch/mips64/kernel/ptrace.c.orig	Wed Jan 29 15:33:04 2003
+++ linux/arch/mips64/kernel/ptrace.c	Wed Mar 12 17:34:33 2003
@@ -206,7 +206,7 @@
 			ret = -EIO;
 			break;
 		}
-		goto out;
+		break;
 		}
 	case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
 	case PTRACE_CONT: { /* restart after signal. */
@@ -293,7 +293,7 @@
 
 	ret = -EPERM;
 	if (pid == 1)		/* you may not mess with init */
-		goto out;
+		goto out_tsk;
 
 	if (request == PTRACE_ATTACH) {
 		ret = ptrace_attach(child);
@@ -427,7 +427,7 @@
 			ret = -EIO;
 			break;
 		}
-		goto out;
+		break;
 		}
 	case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
 	case PTRACE_CONT: { /* restart after signal. */

--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="030312.2.5-ptrace-memory-leak.patch"

diff -Nru linux/arch/mips/kernel/ptrace.c.orig linux/arch/mips/kernel/ptrace.c
--- linux/arch/mips/kernel/ptrace.c.orig	Thu Dec 12 13:58:26 2002
+++ linux/arch/mips/kernel/ptrace.c	Wed Mar 12 17:41:56 2003
@@ -73,7 +73,7 @@
 
 	ret = -EPERM;
 	if (pid == 1)		/* you may not mess with init */
-		goto out;
+		goto out_tsk;
 
 	if (request == PTRACE_ATTACH) {
 		ret = ptrace_attach(child);
@@ -95,8 +95,7 @@
 		if (copied != sizeof(tmp))
 			break;
 		ret = put_user(tmp,(unsigned long *) data);
-
-		goto out;
+		break;
 		}
 
 	/* Read the word at location addr in the USER area.  */
@@ -165,10 +164,10 @@
 		default:
 			tmp = 0;
 			ret = -EIO;
-			goto out;
+			goto out_tsk;
 		}
 		ret = put_user(tmp, (unsigned long *) data);
-		goto out;
+		break;
 		}
 
 	case PTRACE_POKETEXT: /* write the word at location addr. */
@@ -178,7 +177,7 @@
 		    == sizeof(data))
 			break;
 		ret = -EIO;
-		goto out;
+		break;
 
 	case PTRACE_POKEUSR: {
 		struct pt_regs *regs;
diff -Nru linux/arch/mips64/kernel/ptrace.c.orig linux/arch/mips64/kernel/ptrace.c
--- linux/arch/mips64/kernel/ptrace.c.orig	Thu Feb 13 11:37:35 2003
+++ linux/arch/mips64/kernel/ptrace.c	Wed Mar 12 17:41:56 2003
@@ -206,7 +206,7 @@
 			ret = -EIO;
 			break;
 		}
-		goto out;
+		break;
 		}
 	case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
 	case PTRACE_CONT: { /* restart after signal. */
@@ -286,7 +286,7 @@
 
 	ret = -EPERM;
 	if (pid == 1)		/* you may not mess with init */
-		goto out;
+		goto out_tsk;
 
 	if (request == PTRACE_ATTACH) {
 		ret = ptrace_attach(child);
@@ -420,7 +420,7 @@
 			ret = -EIO;
 			break;
 		}
-		goto out;
+		break;
 		}
 	case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
 	case PTRACE_CONT: { /* restart after signal. */

--rwEMma7ioTxnRzrJ--

From fxzhang@ict.ac.cn Thu Mar 13 02:22:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 02:22:25 +0000 (GMT)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:32195
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225199AbTCMCWY>; Thu, 13 Mar 2003 02:22:24 +0000
Received: (qmail 24841 invoked from network); 13 Mar 2003 02:03:37 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 13 Mar 2003 02:03:37 -0000
Message-ID: <3E709EC2.7050501@ict.ac.cn>
Date: Thu, 13 Mar 2003 10:07:46 -0500
From: Zhang Fuxin <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020809
X-Accept-Language: zh-cn, en-us
MIME-Version: 1.0
To: Richard Hodges <rh@matriplex.com>
CC: Ralf Baechle <ralf@linux-mips.org>,
	Ranjan Parthasarathy <ranjanp@efi.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Disabling lwl and lwr instruction generation
References: <D9F6B9DABA4CAE4B92850252C52383AB0796823C@ex-eng-corp.efi.com> <20030313014338.C29568@linux-mips.org> <Pine.BSF.4.50.0303121647400.95890-100000@mail.matriplex.com>
Content-Type: text/plain; charset=x-gbk; 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: 1713
X-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
Content-Length: 927
Lines: 50



Richard Hodges wrote:

>On Thu, 13 Mar 2003, Ralf Baechle wrote:
>
>  
>
>>On Wed, Mar 12, 2003 at 10:05:20AM -0800, Ranjan Parthasarathy wrote:
>>
>>    
>>
>>>Is there a way to tell gcc to not generate the lwl, lwr instructions?
>>>      
>>>
>>Gcc will only ever generate these instructions when __attribute__((unaligned))
>>is used.
>>    
>>
>
>I got lwl and lwr from a memcpy() with two void pointers...
>
>I quickly changed those to the (aligned) structure pointers instead, and
>then memcpy() changed to ordinary word loads and stores.
>
>So, is somebody starting a toolchain for that new Chinese CPU? :-)
>  
>

I don't hear about it,but it will happen soon or later:)

We work around lwl/lwr problem by modifying toolchain from H.J. Lu's rh 
port.

it seems that gcc will explicitly output lwl/lwr for unaligned block 
copy,in other cases it will generate
ulW macros for gas to handle.





>-Richard
>
>
>
>  
>



From fxzhang@ict.ac.cn Thu Mar 13 03:01:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 03:01:34 +0000 (GMT)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:47300
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225223AbTCMDBd>; Thu, 13 Mar 2003 03:01:33 +0000
Received: (qmail 2110 invoked from network); 13 Mar 2003 02:43:09 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 13 Mar 2003 02:43:09 -0000
Message-ID: <3E70A805.1030007@ict.ac.cn>
Date: Thu, 13 Mar 2003 10:47:17 -0500
From: Zhang Fuxin <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020809
X-Accept-Language: zh-cn, en-us
MIME-Version: 1.0
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: linux/mips on simos
Content-Type: text/plain; charset=x-gbk; 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: 1714
X-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
Content-Length: 844
Lines: 22

hi,
Recently i am working on stanford SIMOS and trying to make it
run linux/mips kernel.

I've managed to run debian-mips root disk on it now. Work includes
adding a serial device simulation to simos,hack around memory/io
address mapping and adapt a linux/mips kernel for simos.

Many powerful features are to be brought back. I am struggling with
SIMOS symbol handling for ELF kernels. The backdoor,data collection
etc. need check too. I would be very glad if anybody here is willing to
help.

The main purpose of my work is to provide a studying environment for people
who want to learn something about linux/mips but without corresponding
hardware at hand. There are more and more such people in China, and I
am a member of a free orgnization that want to help them.

I believe SIMOS will be helpful for linux/mips kernel developing too.




From quintela@mandrakesoft.com Thu Mar 13 03:50:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 03:50:12 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:17461 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225199AbTCMDuL>;
	Thu, 13 Mar 2003 03:50:11 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 6F1166EC; Thu, 13 Mar 2003 04:50:08 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: 1/2 cleanup of c-andes.c
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 13 Mar 2003 04:50:08 +0100
Message-ID: <863cls6i33.fsf@trasno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1715
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 4318
Lines: 142


Hi ralf

Make only once the detection of the secondary cache line size.
Once there, make  andes_flush_icache_page have the right types and
remove the wrong export.

Later, Juan.


 build/arch/mips64/mm/c-andes.c     |   53 ++++++++++++++++++++++++-------------
 build/include/asm-mips64/pgtable.h |    7 ----
 2 files changed, 36 insertions(+), 24 deletions(-)

diff -puN build/include/asm-mips64/pgtable.h~mips64-sc-line-size build/include/asm-mips64/pgtable.h
--- 24/build/include/asm-mips64/pgtable.h~mips64-sc-line-size	2003-03-13 04:11:14.000000000 +0100
+++ 24-quintela/build/include/asm-mips64/pgtable.h	2003-03-13 04:11:14.000000000 +0100
@@ -61,7 +61,6 @@ extern void (*_flush_cache_l1)(void);
  * are io coherent. The only place where we might be overoptimizing
  * out icache flushes are from mprotect (when PROT_EXEC is added).
  */
-extern void andes_flush_icache_page(unsigned long);
 #define flush_cache_mm(mm)		do { } while(0)
 #define flush_cache_range(mm,start,end)	do { } while(0)
 #define flush_cache_page(vma,page)	do { } while(0)
@@ -69,11 +68,7 @@ extern void andes_flush_icache_page(unsi
 #define flush_icache_range(start, end)	_flush_cache_l1()
 #define flush_icache_user_range(vma, page, addr, len) \
 	flush_icache_page((vma), (page))
-#define flush_icache_page(vma, page)					\
-do {									\
-	if ((vma)->vm_flags & VM_EXEC)					\
-		andes_flush_icache_page(phys_to_virt(page_to_phys(page))); \
-} while (0)
+#define flush_icache_page(vma, page)	_flush_icache_page(vma, page)
 
 #else
 
diff -puN build/arch/mips64/mm/c-andes.c~mips64-sc-line-size build/arch/mips64/mm/c-andes.c
--- 24/build/arch/mips64/mm/c-andes.c~mips64-sc-line-size	2003-03-13 04:11:14.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/c-andes.c	2003-03-13 04:34:10.000000000 +0100
@@ -17,8 +17,6 @@
 #include <asm/system.h>
 #include <asm/mmu_context.h>
 
-static int scache_lsz64;
-
 extern void andes_clear_page(void * page);
 extern void andes_copy_page(void * to, void * from);
 
@@ -35,12 +33,14 @@ static void andes_flush_cache_l1(void)
  * This is only used during initialization time. vmalloc() also calls
  * this, but that will be changed pretty soon.
  */
-static void andes_flush_cache_l2(void)
+static void andes_flush_cache_l2_64(void)
 {
-	if (sc_lsize() == 64)
-		blast_scache64();
-	else
-		blast_scache128();
+	blast_scache64();
+}
+
+static void andes_flush_cache_l2_128(void)
+{
+	blast_scache128();
 }
 
 static void andes_flush_cache_all(void)
@@ -50,7 +50,7 @@ static void andes_flush_cache_all(void)
 static void andes___flush_cache_all(void)
 {
 	andes_flush_cache_l1();
-	andes_flush_cache_l2();
+	flush_cache_l2();
 }
 
 /*
@@ -60,14 +60,29 @@ static void andes___flush_cache_all(void
  * secondary cache will result in any entries in the primary caches also
  * getting invalidated.
  */
-void andes_flush_icache_page(unsigned long page)
+
+static void andes_flush_icache_page64(struct vm_area_struct *vma,
+				      struct page *page)
 {
-	if (scache_lsz64)
-		blast_scache64_page(page);
-	else
-		blast_scache128_page(page);
+	unsigned long pfn;
+	if (!(vma->vm_flags & VM_EXEC))
+		return;
+
+	pfn = (unsigned long)phys_to_virt(page_to_phys(page));
+	blast_scache64_page(pfn);
 }
 
+static void andes_flush_icache_page128(struct vm_area_struct *vma,
+	struct page *page)
+{
+	unsigned long pfn;
+	if (!(vma->vm_flags & VM_EXEC))
+		return;
+
+	pfn = (unsigned long)phys_to_virt(page_to_phys(page));
+	blast_scache128_page(pfn);
+ }
+
 static void andes_flush_cache_sigtramp(unsigned long addr)
 {
 	protected_writeback_dcache_line(addr & ~(dc_lsize - 1));
@@ -95,13 +110,15 @@ void __init ld_mmu_andes(void)
 	_flush_cache_all = andes_flush_cache_all;
 	___flush_cache_all = andes___flush_cache_all;
 	_flush_cache_l1 = andes_flush_cache_l1;
-	_flush_cache_l2 = andes_flush_cache_l2;
 	_flush_cache_sigtramp = andes_flush_cache_sigtramp;
 
-	if (sc_lsize() == 64)
-		scache_lsz64 = 1;
-	else
-		scache_lsz64 = 0;
+	if (sc_lsize() == 64) {
+		_flush_cache_l2 = andes_flush_cache_l2_64;
+		_flush_icache_page = andes_flush_icache_page64;
+	} else {
+		_flush_cache_l2 = andes_flush_cache_l2_128;
+		_flush_icache_page = andes_flush_icache_page128;
+	}
 
 	flush_cache_l1();
 }

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 13 03:50:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 03:50:32 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:17717 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225219AbTCMDuM>;
	Thu, 13 Mar 2003 03:50:12 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 3A2FE6EE; Thu, 13 Mar 2003 04:50:11 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: 2/2 remove flush_cache_l1/l2
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 13 Mar 2003 04:50:11 +0100
Message-ID: <861y1c6i30.fsf@trasno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1716
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 12389
Lines: 327


Hi

__flush_cache_all is enough for the uses that flush_cache_l1/l2 had.

Later, Juan.

 build/arch/mips/sgi-ip27/ip27-init.c    |    6 +----
 build/arch/mips64/kernel/mips64_ksyms.c |    5 ----
 build/arch/mips64/kernel/syscall.c      |    2 -
 build/arch/mips64/mm/c-andes.c          |   38 ++++++++++++++------------------
 build/arch/mips64/mm/c-mips64.c         |    3 --
 build/arch/mips64/mm/c-r4k.c            |   15 ------------
 build/arch/mips64/mm/c-sb1.c            |    1 
 build/arch/mips64/mm/init.c             |    2 -
 build/arch/mips64/mm/loadmmu.c          |    5 ----
 build/include/asm-mips64/pgtable.h      |   10 --------
 10 files changed, 23 insertions(+), 64 deletions(-)

diff -puN build/include/asm-mips64/pgtable.h~remove_flush_cache_l12 build/include/asm-mips64/pgtable.h
--- 24/build/include/asm-mips64/pgtable.h~remove_flush_cache_l12	2003-03-13 04:35:38.000000000 +0100
+++ 24-quintela/build/include/asm-mips64/pgtable.h	2003-03-13 04:35:38.000000000 +0100
@@ -41,11 +41,6 @@ extern void (*_flush_icache_page)(struct
 extern void (*_flush_cache_sigtramp)(unsigned long addr);
 extern void (*_flush_icache_all)(void);
 
-/* These suck ...  */
-extern void (*_flush_cache_l2)(void);
-extern void (*_flush_cache_l1)(void);
-
-
 #define flush_page_to_ram(page)		do { } while(0)
 
 #define flush_cache_all()		_flush_cache_all()
@@ -65,7 +60,7 @@ extern void (*_flush_cache_l1)(void);
 #define flush_cache_range(mm,start,end)	do { } while(0)
 #define flush_cache_page(vma,page)	do { } while(0)
 #define flush_dcache_page(page)		do { } while(0)
-#define flush_icache_range(start, end)	_flush_cache_l1()
+#define flush_icache_range(start, end)	_flush_icache_range(start, end)
 #define flush_icache_user_range(vma, page, addr, len) \
 	flush_icache_page((vma), (page))
 #define flush_icache_page(vma, page)	_flush_icache_page(vma, page)
@@ -90,9 +85,6 @@ extern void (*_flush_cache_l1)(void);
 #define flush_icache_all()		do { } while(0)
 #endif
 
-#define flush_cache_l2()		_flush_cache_l2()
-#define flush_cache_l1()		_flush_cache_l1()
-
 /*
  * This flag is used to indicate that the page pointed to by a pte
  * is dirty and requires cleaning before returning it to the user.
diff -puN build/arch/mips64/mm/c-andes.c~remove_flush_cache_l12 build/arch/mips64/mm/c-andes.c
--- 24/build/arch/mips64/mm/c-andes.c~remove_flush_cache_l12	2003-03-13 04:35:38.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/c-andes.c	2003-03-13 04:45:26.000000000 +0100
@@ -29,28 +29,20 @@ static void andes_flush_cache_l1(void)
 	blast_dcache32(); blast_icache64();
 }
 
-/*
- * This is only used during initialization time. vmalloc() also calls
- * this, but that will be changed pretty soon.
- */
-static void andes_flush_cache_l2_64(void)
-{
-	blast_scache64();
-}
-
-static void andes_flush_cache_l2_128(void)
+static void andes_flush_cache_all(void)
 {
-	blast_scache128();
 }
 
-static void andes_flush_cache_all(void)
+static void andes___flush_cache_all64(void)
 {
+	blast_dcache32(); blast_icache64();
+	blast_scache64();
 }
 
-static void andes___flush_cache_all(void)
+static void andes___flush_cache_all128(void)
 {
-	andes_flush_cache_l1();
-	flush_cache_l2();
+	blast_dcache32(); blast_icache64();
+	blast_scache128();
 }
 
 /*
@@ -81,7 +73,13 @@ static void andes_flush_icache_page128(s
 
 	pfn = (unsigned long)phys_to_virt(page_to_phys(page));
 	blast_scache128_page(pfn);
- }
+}
+
+static void andes_flush_icache_range(unsigned long start,
+	unsigned long end)
+{
+	blast_icache64();
+}
 
 static void andes_flush_cache_sigtramp(unsigned long addr)
 {
@@ -108,17 +106,15 @@ void __init ld_mmu_andes(void)
 	_copy_page = andes_copy_page;
 
 	_flush_cache_all = andes_flush_cache_all;
-	___flush_cache_all = andes___flush_cache_all;
-	_flush_cache_l1 = andes_flush_cache_l1;
 	_flush_cache_sigtramp = andes_flush_cache_sigtramp;
 
 	if (sc_lsize() == 64) {
-		_flush_cache_l2 = andes_flush_cache_l2_64;
+		___flush_cache_all = andes___flush_cache_all64;
 		_flush_icache_page = andes_flush_icache_page64;
 	} else {
-		_flush_cache_l2 = andes_flush_cache_l2_128;
+		___flush_cache_all = andes___flush_cache_all128;
 		_flush_icache_page = andes_flush_icache_page128;
 	}
 
-	flush_cache_l1();
+	__flush_cache_all();
 }
diff -puN build/arch/mips64/mm/c-mips64.c~remove_flush_cache_l12 build/arch/mips64/mm/c-mips64.c
--- 24/build/arch/mips64/mm/c-mips64.c~remove_flush_cache_l12	2003-03-13 04:35:38.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/c-mips64.c	2003-03-13 04:35:38.000000000 +0100
@@ -713,8 +713,7 @@ void __init ld_mmu_mips64(void)
 	_flush_cache_sigtramp = mips64_flush_cache_sigtramp;
 	_flush_icache_range = mips64_flush_icache_range;	/* Ouch */
 	_flush_icache_all = mips64_flush_icache_all;
-	_flush_cache_l1 = _flush_cache_all;
-	_flush_cache_l2 = _flush_cache_all;
+	_flush_cache_all = _flush_cache_all;
 
 	__flush_cache_all();
 }
diff -puN build/arch/mips64/mm/loadmmu.c~remove_flush_cache_l12 build/arch/mips64/mm/loadmmu.c
--- 24/build/arch/mips64/mm/loadmmu.c~remove_flush_cache_l12	2003-03-13 04:35:38.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/loadmmu.c	2003-03-13 04:35:38.000000000 +0100
@@ -36,11 +36,6 @@ void (*_flush_icache_range)(unsigned lon
 void (*_flush_icache_page)(struct vm_area_struct *vma, struct page *page);
 void (*_flush_icache_all)(void);
 
-/* MIPS specific cache operations */
-void (*_flush_cache_l2)(void);
-void (*_flush_cache_l1)(void);
-
-
 /* DMA cache operations. */
 void (*_dma_cache_wback_inv)(unsigned long start, unsigned long size);
 void (*_dma_cache_wback)(unsigned long start, unsigned long size);
diff -puN build/arch/mips64/mm/init.c~remove_flush_cache_l12 build/arch/mips64/mm/init.c
--- 24/build/arch/mips64/mm/init.c~remove_flush_cache_l12	2003-03-13 04:35:38.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/init.c	2003-03-13 04:41:44.000000000 +0100
@@ -114,7 +114,7 @@ int do_check_pgt_cache(int low, int high
 asmlinkage int sys_cacheflush(void *addr, int bytes, int cache)
 {
 	/* XXX Just get it working for now... */
-	flush_cache_l1();
+	__flush_cache_all();
 	return 0;
 }
 
diff -puN build/arch/mips64/kernel/mips64_ksyms.c~remove_flush_cache_l12 build/arch/mips64/kernel/mips64_ksyms.c
--- 24/build/arch/mips64/kernel/mips64_ksyms.c~remove_flush_cache_l12	2003-03-13 04:35:38.000000000 +0100
+++ 24-quintela/build/arch/mips64/kernel/mips64_ksyms.c	2003-03-13 04:35:38.000000000 +0100
@@ -79,11 +79,6 @@ EXPORT_SYMBOL_NOVERS(__strnlen_user_asm)
 /* Networking helper routines. */
 EXPORT_SYMBOL(csum_partial_copy);
 
-/*
- * Functions to control caches.
- */
-EXPORT_SYMBOL(_flush_cache_l1);
-
 #ifdef CONFIG_NONCOHERENT_IO
 EXPORT_SYMBOL(_dma_cache_wback_inv);
 EXPORT_SYMBOL(_dma_cache_inv);
diff -puN build/arch/mips64/kernel/syscall.c~remove_flush_cache_l12 build/arch/mips64/kernel/syscall.c
--- 24/build/arch/mips64/kernel/syscall.c~remove_flush_cache_l12	2003-03-13 04:35:38.000000000 +0100
+++ 24-quintela/build/arch/mips64/kernel/syscall.c	2003-03-13 04:42:29.000000000 +0100
@@ -221,7 +221,7 @@ asmlinkage int sys_sysmips(int cmd, long
 		return 0;
 
 	case FLUSH_CACHE:
-		flush_cache_l2();
+		__flush_cache_all();
 		return 0;
 
 	case MIPS_RDNVRAM:
diff -puN build/arch/mips64/mm/c-r4k.c~remove_flush_cache_l12 build/arch/mips64/mm/c-r4k.c
--- 24/build/arch/mips64/mm/c-r4k.c~remove_flush_cache_l12	2003-03-13 04:35:38.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/c-r4k.c	2003-03-13 04:35:38.000000000 +0100
@@ -1079,10 +1079,6 @@ static void r4600v20k_flush_cache_sigtra
 #endif
 }
 
-static void r4k_flush_cache_l2(void)
-{
-}
-
 void __update_cache(struct vm_area_struct *vma, unsigned long address,
 	pte_t pte)
 {
@@ -1225,7 +1221,6 @@ static void __init setup_noscache_funcs(
 		_clear_page = r4k_clear_page_d16;
 		_copy_page = r4k_copy_page_d16;
 		_flush_cache_all = r4k_flush_cache_all_d16i16;
-		_flush_cache_l1 = r4k_flush_cache_all_d16i16;
 		_flush_cache_mm = r4k_flush_cache_mm_d16i16;
 		_flush_cache_range = r4k_flush_cache_range_d16i16;
 		_flush_cache_page = r4k_flush_cache_page_d16i16;
@@ -1243,7 +1238,6 @@ static void __init setup_noscache_funcs(
 			_copy_page = r4k_copy_page_d32;
 		}
 		_flush_cache_all = r4k_flush_cache_all_d32i32;
-		_flush_cache_l1 = r4k_flush_cache_all_d32i32;
 		_flush_cache_mm = r4k_flush_cache_mm_d32i32;
 		_flush_cache_range = r4k_flush_cache_range_d32i32;
 		_flush_cache_page = r4k_flush_cache_page_d32i32;
@@ -1265,7 +1259,6 @@ static void __init setup_scache_funcs(vo
 		switch (dc_lsize) {
 		case 16:
 			_flush_cache_all = r4k_flush_cache_all_s16d16i16;
-			_flush_cache_l1 = r4k_flush_cache_all_s16d16i16;
 			_flush_cache_mm = r4k_flush_cache_mm_s16d16i16;
 			_flush_cache_range = r4k_flush_cache_range_s16d16i16;
 			_flush_cache_page = r4k_flush_cache_page_s16d16i16;
@@ -1280,14 +1273,12 @@ static void __init setup_scache_funcs(vo
 		switch (dc_lsize) {
 		case 16:
 			_flush_cache_all = r4k_flush_cache_all_s32d16i16;
-			_flush_cache_l1 = r4k_flush_cache_all_s32d16i16;
 			_flush_cache_mm = r4k_flush_cache_mm_s32d16i16;
 			_flush_cache_range = r4k_flush_cache_range_s32d16i16;
 			_flush_cache_page = r4k_flush_cache_page_s32d16i16;
 			break;
 		case 32:
 			_flush_cache_all = r4k_flush_cache_all_s32d32i32;
-			_flush_cache_l1 = r4k_flush_cache_all_s32d32i32;
 			_flush_cache_mm = r4k_flush_cache_mm_s32d32i32;
 			_flush_cache_range = r4k_flush_cache_range_s32d32i32;
 			_flush_cache_page = r4k_flush_cache_page_s32d32i32;
@@ -1300,14 +1291,12 @@ static void __init setup_scache_funcs(vo
 		switch (dc_lsize) {
 		case 16:
 			_flush_cache_all = r4k_flush_cache_all_s64d16i16;
-			_flush_cache_l1 = r4k_flush_cache_all_s64d16i16;
 			_flush_cache_mm = r4k_flush_cache_mm_s64d16i16;
 			_flush_cache_range = r4k_flush_cache_range_s64d16i16;
 			_flush_cache_page = r4k_flush_cache_page_s64d16i16;
 			break;
 		case 32:
 			_flush_cache_all = r4k_flush_cache_all_s64d32i32;
-			_flush_cache_l1 = r4k_flush_cache_all_s64d32i32;
 			_flush_cache_mm = r4k_flush_cache_mm_s64d32i32;
 			_flush_cache_range = r4k_flush_cache_range_s64d32i32;
 			_flush_cache_page = r4k_flush_cache_page_s64d32i32;
@@ -1320,14 +1309,12 @@ static void __init setup_scache_funcs(vo
 		switch (dc_lsize) {
 		case 16:
 			_flush_cache_all = r4k_flush_cache_all_s128d16i16;
-			_flush_cache_l1 = r4k_flush_cache_all_s128d16i16;
 			_flush_cache_mm = r4k_flush_cache_mm_s128d16i16;
 			_flush_cache_range = r4k_flush_cache_range_s128d16i16;
 			_flush_cache_page = r4k_flush_cache_page_s128d16i16;
 			break;
 		case 32:
 			_flush_cache_all = r4k_flush_cache_all_s128d32i32;
-			_flush_cache_l1 = r4k_flush_cache_all_s128d32i32;
 			_flush_cache_mm = r4k_flush_cache_mm_s128d32i32;
 			_flush_cache_range = r4k_flush_cache_range_s128d32i32;
 			_flush_cache_page = r4k_flush_cache_page_s128d32i32;
@@ -1408,7 +1395,5 @@ void __init ld_mmu_r4xx0(void)
 	_flush_dcache_page = r4k_flush_dcache_page;
 	_flush_icache_range = r4k_flush_icache_range;	/* Ouch */
 
-	_flush_cache_l2 = r4k_flush_cache_l2;
-
 	__flush_cache_all();
 }
diff -puN build/arch/mips/sgi-ip27/ip27-init.c~remove_flush_cache_l12 build/arch/mips/sgi-ip27/ip27-init.c
--- 24/build/arch/mips/sgi-ip27/ip27-init.c~remove_flush_cache_l12	2003-03-13 04:35:38.000000000 +0100
+++ 24-quintela/build/arch/mips/sgi-ip27/ip27-init.c	2003-03-13 04:43:47.000000000 +0100
@@ -332,8 +332,7 @@ void per_hub_init(cnodeid_t cnode)
 			memcpy((void *)(KSEG0 + 0x100), (void *) KSEG0, 0x80);
 			memcpy((void *)(KSEG0 + 0x180), &except_vec3_generic,
 								0x100);
-			flush_cache_l1();
-			flush_cache_l2();
+			__flush_cache_all();
 		}
 #endif
 	}
@@ -432,8 +431,7 @@ void __init start_secondary(void)
 	init_mfhi_war();
 #endif
 	local_flush_tlb_all();
-	flush_cache_l1();
-	flush_cache_l2();
+	__flush_cache_all();
 
 	local_irq_enable();
 #if 0
diff -puN build/arch/mips64/mm/c-sb1.c~remove_flush_cache_l12 build/arch/mips64/mm/c-sb1.c
--- 24/build/arch/mips64/mm/c-sb1.c~remove_flush_cache_l12	2003-03-13 04:35:38.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/c-sb1.c	2003-03-13 04:35:38.000000000 +0100
@@ -522,7 +522,6 @@ void ld_mmu_sb1(void)
 
 	/* Full flushes */
 	___flush_cache_all = sb1___flush_cache_all;
-	_flush_cache_l1 = sb1___flush_cache_all;
 
 	change_c0_config(CONF_CM_CMASK, CONF_CM_DEFAULT);
 	/*

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From ipv6_san@rediffmail.com Thu Mar 13 08:14:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 08:14:55 +0000 (GMT)
Received: from webmail28.rediffmail.com ([IPv6:::ffff:203.199.83.38]:457 "HELO
	rediffmail.com") by linux-mips.org with SMTP id <S8225195AbTCMIOy>;
	Thu, 13 Mar 2003 08:14:54 +0000
Received: (qmail 13673 invoked by uid 510); 13 Mar 2003 08:14:00 -0000
Date: 13 Mar 2003 08:14:00 -0000
Message-ID: <20030313081400.13672.qmail@webmail28.rediffmail.com>
Received: from unknown (194.175.117.86) by rediffmail.com via HTTP; 13 mar 2003 08:14:00 -0000
MIME-Version: 1.0
From: "Santosh " <ipv6_san@rediffmail.com>
Reply-To: "Santosh " <ipv6_san@rediffmail.com>
To: usagi-users@linux-ipv6.org
Cc: linux-mips@linux-mips.org
Subject: Error compiling Usagi for MIPS
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <ipv6_san@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1717
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ipv6_san@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2447
Lines: 71

I'm trying to compile the Usagi kernel 2.4.20 for MIPS Malta 
board.
(usagi-linux24-sSTABLE200302_20030214.tar from linux-ipv6.org)
My gcc version is 2.95.3

I did
#make ARCH=mips config
#make ARCH=mips dep
#make ARCH=mips clean
#make ARCH=mips CROSS_COMPILE=mipsel-linux- vmlinux

Now i get following error..
mipsel-linux-gcc -D__KERNEL__ 
-I/home/santosh/UsagiKernel/usagi/kernel/linux24/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing 
-fno-common -fomit-frame-pointer -I 
/home/santosh/UsagiKernel/usagi/kernel/linux24/include/asm/gcc -G 
0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap   
-nostdinc -iwithprefix include -DKBUILD_BASENAME=kbd_no
-c -o kbd-no.o kbd-no.c
rm -f lib.a
mipsel-linux-ar  rcs lib.a csum_partial.o csum_partial_copy.o 
rtc-std.o rtc-no.o memcpy.o memset.o watch.o strlen_user.o 
strncpy_user.o strnlen_user.o dump_tlb.o kbd-std.o kbd-no.o
make[2]: Leaving directory 
`/home/santosh/UsagiKernel/usagi/kernel/linux24/arch/mips/lib'
make[1]: Leaving directory 
`/home/santosh/UsagiKernel/usagi/kernel/linux24/arch/mips/lib'
sed -e 's/@@LOADADDR@@/0x80100000/' <arch/mips/ld.script.in 
 >arch/mips/ld.script
mipsel-linux-ld -G 0 -static  -T arch/mips/ld.script 
arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o 
init/version.o init/do_mounts.o \
         --start-group \
         arch/mips/kernel/kernel.o arch/mips/mm/mm.o 
kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o 
arch/mips/math-emu/fpu_emulator.o \
          drivers/char/char.o drivers/block/block.o 
drivers/misc/misc.o drivers/net/net.o drivers/media/media.o 
drivers/pci/driver.o drivers/video/video.o \
         net/network.o \
         crypto/crypto.o \
         arch/mips/lib/lib.a 
/home/santosh/UsagiKernel/usagi/kernel/linux24/lib/lib.a 
arch/mips/mips-boards/malta/malta.o 
arch/mips/mips-boards/generic/mipsboards.o \
         --end-group \
         -o vmlinux
kernel/kernel.o: In function `interruptible_sleep_on':
sched.c(__ksymtab+0xde8): undefined reference to `dump_stack'
drivers/pci/driver.o: In function `pci_scan_device':
pci.c(.text+0x5c0): undefined reference to 
`pcibios_enable_device'
make: *** [vmlinux] Error 1
#
#

what is wrong here ??? Is it a bug ???

Regds,
-Santosh
-------------------------------





__________________________________________________________
Great Travel Deals, Airfares, Hotels on
http://r.rediff.com/r?www.journeymart.com/rediff/travel.asp&&sign&&jmart


From vincent.stehle@stepmind.com Thu Mar 13 10:10:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 10:10:19 +0000 (GMT)
Received: from ppp-104.net10.magic.fr ([IPv6:::ffff:195.154.128.104]:20740
	"HELO volvic.sud.stepmind.com") by linux-mips.org with SMTP
	id <S8225195AbTCMKKS>; Thu, 13 Mar 2003 10:10:18 +0000
Received: (qmail 8226 invoked from network); 13 Mar 2003 10:00:16 -0000
Received: from eku.sud.stepmind.com (HELO stepmind.com) (192.168.1.103)
  by volvic.sud.stepmind.com with SMTP; 13 Mar 2003 10:00:16 -0000
Message-ID: <3E7057A6.60007@stepmind.com>
Date: Thu, 13 Mar 2003 11:04:22 +0100
From: =?ISO-8859-1?Q?Vincent_Stehl=E9?= <vincent.stehle@stepmind.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030302
X-Accept-Language: fr, en, de
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: PROM variables
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Return-Path: <vincent.stehle@stepmind.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1718
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vincent.stehle@stepmind.com
Precedence: bulk
X-list: linux-mips
Content-Length: 361
Lines: 16


Hi all,

Is there a way to get/set PROM variables under Linux ?

I have an indigo2 with no display, and setting the variables without 
reverting to the monitor through the serial line would be very handy.

As I doubt there is currently a solution, I was thinking about 
implementing this as a /proc subdir. What do you think ?

Regards,

-- 
  Vincent Stehlé


From quintela@mandrakesoft.com Thu Mar 13 10:17:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 10:17:57 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:8258 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225195AbTCMKR4> convert rfc822-to-8bit;
	Thu, 13 Mar 2003 10:17:56 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id F22646EC; Thu, 13 Mar 2003 11:17:54 +0100 (CET)
To: Vincent =?iso-8859-1?q?Stehl=E9?= <vincent.stehle@stepmind.com>
Cc: linux-mips@linux-mips.org
Subject: Re: PROM variables
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <3E7057A6.60007@stepmind.com> (Vincent
 =?iso-8859-1?q?Stehl=E9's?= message of "Thu, 13 Mar 2003 11:04:22 +0100")
References: <3E7057A6.60007@stepmind.com>
Date: Thu, 13 Mar 2003 11:17:54 +0100
Message-ID: <86hea7k1t9.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1719
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 742
Lines: 23

>>>>> "vincent" == Vincent Stehlé <vincent.stehle@stepmind.com> writes:

vincent> Hi all,

vincent> Is there a way to get/set PROM variables under Linux ?

vincent> I have an indigo2 with no display, and setting the variables without
vincent> reverting to the monitor through the serial line would be very handy.

vincent> As I doubt there is currently a solution, I was thinking about
vincent> implementing this as a /proc subdir. What do you think ?

You can set them through the serial console in the same way that you
can set it in the monitor?

Are you sure that you have set the prom variables to use the serial
console?

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From agx@sigxcpu.org Thu Mar 13 10:28:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 10:28:11 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:27578
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225195AbTCMK2L>; Thu, 13 Mar 2003 10:28:11 +0000
Received: from bogon.sigxcpu.org (kons-d9bb5401.pool.mediaWays.net [217.187.84.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 40DE22BC2D; Thu, 13 Mar 2003 11:28:08 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 555DA1735C; Thu, 13 Mar 2003 11:26:02 +0100 (CET)
Date: Thu, 13 Mar 2003 11:26:01 +0100
From: Guido Guenther <agx@sigxcpu.org>
To: Vincent =?iso-8859-1?Q?Stehl=E9?= <vincent.stehle@stepmind.com>
Cc: linux-mips@linux-mips.org
Subject: Re: PROM variables
Message-ID: <20030313102601.GD24866@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	Vincent =?iso-8859-1?Q?Stehl=E9?= <vincent.stehle@stepmind.com>,
	linux-mips@linux-mips.org
References: <3E7057A6.60007@stepmind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3E7057A6.60007@stepmind.com>
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1720
X-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
Content-Length: 759
Lines: 18

Hi Vincent,
On Thu, Mar 13, 2003 at 11:04:22AM +0100, Vincent Stehlé wrote:
> Is there a way to get/set PROM variables under Linux ?
Not for IP22.

> I have an indigo2 with no display, and setting the variables without 
> reverting to the monitor through the serial line would be very handy.
If you pull out the graphics board the machine will switch to the serial
line.

> As I doubt there is currently a solution, I was thinking about 
> implementing this as a /proc subdir. What do you think ?
What about multiple files in /proc/arcs which have the PROM variables as
name and its value as contents? When doing this I'd write into the NVRAM
directly instead of using the Arcs functions, I think the necessary info
is in the IRIX headers.
Regards,
 -- Guido

From ladis@linux-mips.org Thu Mar 13 10:28:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 10:28:31 +0000 (GMT)
Received: from ftp.ckdenergo.cz ([IPv6:::ffff:80.95.97.155]:58033 "EHLO simek")
	by linux-mips.org with ESMTP id <S8225223AbTCMK2X>;
	Thu, 13 Mar 2003 10:28:23 +0000
Received: from ladis by simek with local (Exim 3.36 #1 (Debian))
	id 18tPvs-0001JV-00; Thu, 13 Mar 2003 11:27:28 +0100
Date: Thu, 13 Mar 2003 11:27:18 +0100
To: Vincent =?iso-8859-2?Q?Stehl=E9?= <vincent.stehle@stepmind.com>
Cc: linux-mips@linux-mips.org
Subject: Re: PROM variables
Message-ID: <20030313102718.GA5032@simek>
References: <3E7057A6.60007@stepmind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3E7057A6.60007@stepmind.com>
User-Agent: Mutt/1.5.3i
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: 1721
X-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
Content-Length: 538
Lines: 17

On Thu, Mar 13, 2003 at 11:04:22AM +0100, Vincent Stehlé wrote:
> Hi all,
> 
> Is there a way to get/set PROM variables under Linux ?

no.

> I have an indigo2 with no display, and setting the variables without 
> reverting to the monitor through the serial line would be very handy.
> 
> As I doubt there is currently a solution, I was thinking about 
> implementing this as a /proc subdir. What do you think ?

we discussed this issue on #irc yesterday. it seems that conclusion was
implement it as ioctl on some /dev/prom (?).

	ladis

From takano@os-omicron.org Thu Mar 13 11:28:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 11:28:30 +0000 (GMT)
Received: from [IPv6:::ffff:133.36.48.43] ([IPv6:::ffff:133.36.48.43]:40875
	"EHLO cat.os-omicron.org") by linux-mips.org with ESMTP
	id <S8225223AbTCML23>; Thu, 13 Mar 2003 11:28:29 +0000
Received: from wl04.sys.cs.tuat.ac.jp (pisces.sys.cs.tuat.ac.jp [165.93.162.82])
	by cat.os-omicron.org (Postfix) with SMTP
	id C4619A4E4; Thu, 13 Mar 2003 20:30:19 +0900 (JST)
Date: Thu, 13 Mar 2003 20:27:27 +0900
From: TAKANO Ryousei <takano@os-omicron.org>
To: Zhang Fuxin <fxzhang@ict.ac.cn>
Cc: linux-mips@linux-mips.org
Subject: Re: linux/mips on simos
Message-Id: <20030313202727.627e65ce.takano@os-omicron.org>
In-Reply-To: <3E70A805.1030007@ict.ac.cn>
References: <3E70A805.1030007@ict.ac.cn>
Organization: OS/omicron Project
X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i386-vine-linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <takano@os-omicron.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1722
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: takano@os-omicron.org
Precedence: bulk
X-list: linux-mips
Content-Length: 261
Lines: 11

Hi Zhang,

> Recently i am working on stanford SIMOS and trying to make it
> run linux/mips kernel.
> 
I am interesting in your work.
I found the following paper about Linux/SimOS.
http://academic.csuohio.edu/yuc/papers/Ben-ICPP2002.pdf

Thanks,
TAKANO Ryousei

From ladis@linux-mips.org Thu Mar 13 11:37:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 11:37:43 +0000 (GMT)
Received: from ftp.ckdenergo.cz ([IPv6:::ffff:80.95.97.155]:42200 "EHLO simek")
	by linux-mips.org with ESMTP id <S8225223AbTCMLhm>;
	Thu, 13 Mar 2003 11:37:42 +0000
Received: from ladis by simek with local (Exim 3.36 #1 (Debian))
	id 18tQxc-0001g4-00; Thu, 13 Mar 2003 12:33:20 +0100
Date: Thu, 13 Mar 2003 12:33:10 +0100
To: Guido Guenther <agx@sigxcpu.org>,
	Vincent =?iso-8859-2?Q?Stehl=E9?= <vincent.stehle@stepmind.com>,
	linux-mips@linux-mips.org
Subject: Re: PROM variables
Message-ID: <20030313113310.GA6151@simek>
References: <3E7057A6.60007@stepmind.com> <20030313102601.GD24866@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030313102601.GD24866@bogon.ms20.nix>
User-Agent: Mutt/1.5.3i
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: 1723
X-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
Content-Length: 517
Lines: 13

On Thu, Mar 13, 2003 at 11:26:01AM +0100, Guido Guenther wrote:
[snip]
> > As I doubt there is currently a solution, I was thinking about 
> > implementing this as a /proc subdir. What do you think ?
> What about multiple files in /proc/arcs which have the PROM variables as
> name and its value as contents? 

hmm, how would you add/remove variable?

> When doing this I'd write into the NVRAM directly instead of using the
> Arcs functions, I think the necessary info is in the IRIX headers.
> Regards,
>  -- Guido

From quintela@mandrakesoft.com Thu Mar 13 11:42:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 11:42:03 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:581 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225223AbTCMLmC>;
	Thu, 13 Mar 2003 11:42:02 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 443396EC; Thu, 13 Mar 2003 12:42:02 +0100 (CET)
To: Ladislav Michl <ladis@linux-mips.org>
Cc: Guido Guenther <agx@sigxcpu.org>,
	Vincent =?iso-8859-2?q?Stehl=E9?= <vincent.stehle@stepmind.com>,
	linux-mips@linux-mips.org
Subject: Re: PROM variables
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030313113310.GA6151@simek> (Ladislav Michl's message of
 "Thu, 13 Mar 2003 12:33:10 +0100")
References: <3E7057A6.60007@stepmind.com>
	<20030313102601.GD24866@bogon.ms20.nix> <20030313113310.GA6151@simek>
Date: Thu, 13 Mar 2003 12:42:02 +0100
Message-ID: <868yvjjxx1.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1724
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 607
Lines: 21

>>>>> "ladislav" == Ladislav Michl <ladis@linux-mips.org> writes:

ladislav> On Thu, Mar 13, 2003 at 11:26:01AM +0100, Guido Guenther wrote:
ladislav> [snip]
>> > As I doubt there is currently a solution, I was thinking about 
>> > implementing this as a /proc subdir. What do you think ?
>> What about multiple files in /proc/arcs which have the PROM variables as
>> name and its value as contents? 

ladislav> hmm, how would you add/remove variable?

echo "value" > new_variable_name 

??

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 13 11:42:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 11:42:55 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:3397 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225223AbTCMLmz>;
	Thu, 13 Mar 2003 11:42:55 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id A86636EC; Thu, 13 Mar 2003 12:42:54 +0100 (CET)
To: Ladislav Michl <ladis@linux-mips.org>
Cc: Guido Guenther <agx@sigxcpu.org>,
	Vincent =?iso-8859-2?q?Stehl=E9?= <vincent.stehle@stepmind.com>,
	linux-mips@linux-mips.org
Subject: Re: PROM variables
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030313113310.GA6151@simek> (Ladislav Michl's message of
 "Thu, 13 Mar 2003 12:33:10 +0100")
References: <3E7057A6.60007@stepmind.com>
	<20030313102601.GD24866@bogon.ms20.nix> <20030313113310.GA6151@simek>
Date: Thu, 13 Mar 2003 12:42:54 +0100
Message-ID: <864r67jxvl.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1725
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 694
Lines: 24

>>>>> "ladislav" == Ladislav Michl <ladis@linux-mips.org> writes:

ladislav> On Thu, Mar 13, 2003 at 11:26:01AM +0100, Guido Guenther wrote:
ladislav> [snip]
>> > As I doubt there is currently a solution, I was thinking about 
>> > implementing this as a /proc subdir. What do you think ?
>> What about multiple files in /proc/arcs which have the PROM variables as
>> name and its value as contents? 

ladislav> hmm, how would you add/remove variable?

Forgot to tell how to remove the variable in previous mail :)

rm old_variable 

should do, no need at all of ioctl crap :)

Later, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From fxzhang@ict.ac.cn Thu Mar 13 12:38:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 12:38:00 +0000 (GMT)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:63439
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225223AbTCMMiA>; Thu, 13 Mar 2003 12:38:00 +0000
Received: (qmail 31782 invoked from network); 13 Mar 2003 12:19:10 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 13 Mar 2003 12:19:10 -0000
Message-ID: <3E712F0F.40004@ict.ac.cn>
Date: Thu, 13 Mar 2003 20:23:27 -0500
From: Zhang Fuxin <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020809
X-Accept-Language: zh-cn, en-us
MIME-Version: 1.0
To: TAKANO Ryousei <takano@os-omicron.org>
CC: linux-mips@linux-mips.org
Subject: Re: linux/mips on simos
References: <3E70A805.1030007@ict.ac.cn> <20030313202727.627e65ce.takano@os-omicron.org>
Content-Type: text/plain; charset=x-gbk; 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: 1726
X-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
Content-Length: 715
Lines: 36


Thank you.I've read that paper before,but i can't find their source anywhere
and failed to notice that it is quit new(2002),I should have contacted 
the authors
first.

My work is available at
ftp://www.akaembed.org/uploads/tmp/simos-linux.tar.gz currently it can run
debian mips root disk(of course you should be able to replace the 
ramdisk with
your apps),but many things don't work yet.

TAKANO Ryousei wrote:

>Hi Zhang,
>
>  
>
>>Recently i am working on stanford SIMOS and trying to make it
>>run linux/mips kernel.
>>
>>    
>>
>I am interesting in your work.
>I found the following paper about Linux/SimOS.
>http://academic.csuohio.edu/yuc/papers/Ben-ICPP2002.pdf
>
>Thanks,
>TAKANO Ryousei
>
>
>
>  
>



From br1@4g-systems.de Thu Mar 13 13:08:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 13:08:08 +0000 (GMT)
Received: from moutvdom.kundenserver.de ([IPv6:::ffff:212.227.126.250]:56811
	"EHLO moutvdom.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225223AbTCMNIH>; Thu, 13 Mar 2003 13:08:07 +0000
Received: from [212.227.126.220] (helo=mrvdomng.kundenserver.de)
	by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1)
	id 18tSRL-0006OF-00
	for linux-mips@linux-mips.org; Thu, 13 Mar 2003 14:08:07 +0100
Received: from [62.109.119.183] (helo=192.168.202.41)
	by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 18tSRK-0003cC-00
	for linux-mips@linux-mips.org; Thu, 13 Mar 2003 14:08:06 +0100
From: Bruno Randolf <br1@4g-systems.de>
Organization: 4G Mobile Systeme
To: linux-mips@linux-mips.org
Subject: Re: Mycable XXS board
Date: Thu, 13 Mar 2003 14:08:05 +0100
User-Agent: KMail/1.5
References: <3E689267.3070509@prosyst.bg> <3E6E588A.1090702@amd.com> <3E6E5BE0.4000203@embeddededge.com>
In-Reply-To: <3E6E5BE0.4000203@embeddededge.com>
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_1KIc+DdgiliP8jV"
Message-Id: <200303131408.05612.br1@4g-systems.de>
Return-Path: <br1@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: 1727
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: br1@4g-systems.de
Precedence: bulk
X-list: linux-mips
Content-Length: 3015
Lines: 83


--Boundary-00=_1KIc+DdgiliP8jV
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Tuesday 11 March 2003 22:57, Dan Malek wrote:
> I would like to hear the
> results of the message posted earlier today about the proper power up
> of the USB interface on this board :-)

hello!

i got USB to work with the proper power up :)
the builtin usb devices still dont accept a new address (maybe thats ok?), but 
i can see the attached usb devices and they are powered. i tested a serial 
driver which also loads and detects the device fine. looks good, but i havent 
tested any functionality yet.

i attach a patch with the usb power up for the mycable XXS board, which also 
defines a new config option for this board. i'm not sure if this is the 
correct way to do it, so please correct me...

bruno
--Boundary-00=_1KIc+DdgiliP8jV
Content-Type: text/x-diff;
  charset="iso-8859-1";
  name="mycable_XXS_config.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="mycable_XXS_config.diff"

--- cvs-linux-mips-2_4/arch/mips/config-shared.in	Fri Mar  7 18:29:18 2003
+++ mips-2_4/arch/mips/config-shared.in	Thu Mar 13 13:52:47 2003
@@ -29,6 +29,9 @@
 fi
 dep_bool 'Support for Alchemy PB1100 board' CONFIG_MIPS_PB1100 $CONFIG_MIPS32
 dep_bool 'Support for Alchemy PB1500 board' CONFIG_MIPS_PB1500 $CONFIG_MIPS32
+if [ "$CONFIG_MIPS_PB1500" = "y" ]; then
+   bool '  Support for mycable XXS board' CONFIG_MYCABLE_XXS_1500
+fi
 dep_bool 'Support for BAGET MIPS series (EXPERIMENTAL)' CONFIG_BAGET_MIPS $CONFIG_MIPS32 $CONFIG_EXPERIMENTAL
 bool 'Support for CASIO CASSIOPEIA E-10/15/55/65' CONFIG_CASIO_E55
 dep_bool 'Support for Cobalt Server (EXPERIMENTAL)' CONFIG_MIPS_COBALT $CONFIG_EXPERIMENTAL

--Boundary-00=_1KIc+DdgiliP8jV
Content-Type: text/x-diff;
  charset="iso-8859-1";
  name="mycable_XXS_usb_power.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="mycable_XXS_usb_power.diff"

--- cvs-linux-mips-2_4/arch/mips/au1000/pb1500/setup.c	Thu Mar 13 14:00:00 2003
+++ mips-2_4/arch/mips/au1000/pb1500/setup.c	Thu Mar 13 14:04:53 2003
@@ -197,8 +197,24 @@
 	pin_func |= 0x8000;
 #endif
 	au_writel(pin_func, SYS_PINFUNC);
-#endif // defined (CONFIG_USB_OHCI) || defined (CONFIG_AU1X00_USB_DEVICE)
 
+#ifdef CONFIG_MYCABLE_XXS_1500
+	// set multiple use pins (UART3/GPIO) to UART (it's used as UART too)
+	pin_func = au_readl(SYS_PINFUNC) & (u32)(~SYS_PF_UR3);
+	pin_func |= SYS_PF_UR3;
+	au_writel(pin_func, SYS_PINFUNC);
+
+	// enable UART
+	au_writel(0x01, UART3_ADDR+UART_MOD_CNTRL); // clock enable (CE)
+	mdelay(10);
+	au_writel(0x03, UART3_ADDR+UART_MOD_CNTRL); // CE and "enable"
+	mdelay(10);
+
+	// enable DTR = USB power up
+	au_writel(0x01, UART3_ADDR+UART_MCR); //? UART_MCR_DTR is 0x01???
+#endif
+
+#endif // defined (CONFIG_USB_OHCI) || defined (CONFIG_AU1X00_USB_DEVICE)
 
 #ifdef CONFIG_USB_OHCI
 	// enable host controller and wait for reset done

--Boundary-00=_1KIc+DdgiliP8jV--


From dan@embeddededge.com Thu Mar 13 16:03:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 16:03:33 +0000 (GMT)
Received: from 154-84-51-66.reonbroadband.com ([IPv6:::ffff:66.51.84.154]:4992
	"EHLO tibook.netx4.com") by linux-mips.org with ESMTP
	id <S8225223AbTCMQDd>; Thu, 13 Mar 2003 16:03:33 +0000
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 h2DG3Qc00922;
	Thu, 13 Mar 2003 11:03:26 -0500
Message-ID: <3E70ABCE.9030909@embeddededge.com>
Date: Thu, 13 Mar 2003 11:03:26 -0500
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bruno Randolf <br1@4g-systems.de>
CC: linux-mips@linux-mips.org
Subject: Re: Mycable XXS board
References: <3E689267.3070509@prosyst.bg> <3E6E588A.1090702@amd.com> <3E6E5BE0.4000203@embeddededge.com> <200303131408.05612.br1@4g-systems.de>
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: 1728
X-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
Content-Length: 437
Lines: 17

Bruno Randolf wrote:

> i got USB to work with the proper power up :)

Cool, thanks for the update.

> i attach a patch with the usb power up for the mycable XXS board,

The way this should really be done is to have a board definition,
directory and files unique to the XXS board.  Hacking the PB1500
may be the fast way to get it done locally, but it isn't the right
way from a Linux structure/maintenance viewpoint.

Thanks.

	-- Dan


From vincent.stehle@stepmind.com Thu Mar 13 16:13:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 16:13:58 +0000 (GMT)
Received: from ppp-104.net10.magic.fr ([IPv6:::ffff:195.154.128.104]:63238
	"HELO volvic.sud.stepmind.com") by linux-mips.org with SMTP
	id <S8225223AbTCMQN5>; Thu, 13 Mar 2003 16:13:57 +0000
Received: (qmail 27150 invoked from network); 13 Mar 2003 16:03:51 -0000
Received: from eku.sud.stepmind.com (HELO stepmind.com) (192.168.1.103)
  by volvic.sud.stepmind.com with SMTP; 13 Mar 2003 16:03:51 -0000
Message-ID: <3E70ACE0.5010306@stepmind.com>
Date: Thu, 13 Mar 2003 17:08:00 +0100
From: =?ISO-8859-1?Q?Vincent_Stehl=E9?= <vincent.stehle@stepmind.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030302
X-Accept-Language: fr, en, de
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: PROM variables
References: <3E7057A6.60007@stepmind.com> <20030313102601.GD24866@bogon.ms20.nix>
In-Reply-To: <20030313102601.GD24866@bogon.ms20.nix>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Return-Path: <vincent.stehle@stepmind.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1729
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vincent.stehle@stepmind.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1087
Lines: 34

Guido Guenther wrote:
[..]
> When doing this I'd write into the NVRAM
> directly instead of using the Arcs functions, I think the necessary info
> is in the IRIX headers.

I had a look at the ARC spec. (ARC/riscspec.pdf), and I am affraid the 
only (documented) way to access PROM env. variables are the two get/set 
functions.

In that case, the /proc approach makes sense IMHO.

Looking at hpc3 spec. and ip22-sc.c, I understand that PROM data are 
stored in the EEPROM behind the hpc3.

Maybe a reasonable approach is:

o write a new char device driver (as pc's /dev/nvram for example)
o move eeprom read/write routines from ip22-sc.c somewhere else,
   and use those routines both in ip22-sc.c and the char driver
o guess the format/offsets of the info. stored in nvram
o then write some user space app. to do the env. variable
   specific part.

In that latter case, the /proc approach makes less sense IMHO.

What do you think ? Am I missing some documentation ? Is there more in 
the IRIX headers ? (can't check right now, but I have them at home)

Regards,

--
  Vincent Stehlé


From br1@4g-systems.de Thu Mar 13 17:23:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 17:23:28 +0000 (GMT)
Received: from moutvdom.kundenserver.de ([IPv6:::ffff:212.227.126.251]:28879
	"EHLO moutvdom.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225223AbTCMRX1>; Thu, 13 Mar 2003 17:23:27 +0000
Received: from [212.227.126.221] (helo=mrvdomng.kundenserver.de)
	by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1)
	id 18tWQN-0002Gq-00; Thu, 13 Mar 2003 18:23:23 +0100
Received: from [62.109.119.183] (helo=192.168.202.41)
	by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 18tWQN-0000yG-00; Thu, 13 Mar 2003 18:23:23 +0100
From: Bruno Randolf <br1@4g-systems.de>
Organization: 4G Mobile Systeme
To: Dan Malek <dan@embeddededge.com>
Subject: Re: Mycable XXS board
Date: Thu, 13 Mar 2003 18:23:22 +0100
User-Agent: KMail/1.5
Cc: linux-mips@linux-mips.org
References: <3E689267.3070509@prosyst.bg> <200303131408.05612.br1@4g-systems.de> <3E70ABCE.9030909@embeddededge.com>
In-Reply-To: <3E70ABCE.9030909@embeddededge.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200303131823.22343.br1@4g-systems.de>
Return-Path: <br1@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: 1730
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: br1@4g-systems.de
Precedence: bulk
X-list: linux-mips
Content-Length: 401
Lines: 12

On Thursday 13 March 2003 17:03, Dan Malek wrote:

> The way this should really be done is to have a board definition,
> directory and files unique to the XXS board.  Hacking the PB1500
> may be the fast way to get it done locally, but it isn't the right
> way from a Linux structure/maintenance viewpoint.

allright, i can do that - but doesn't this create a lot of unnecessary copied 
code?

bruno


From dan@embeddededge.com Thu Mar 13 17:51:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 17:51:01 +0000 (GMT)
Received: from 154-84-51-66.reonbroadband.com ([IPv6:::ffff:66.51.84.154]:30080
	"EHLO tibook.netx4.com") by linux-mips.org with ESMTP
	id <S8225223AbTCMRvA>; Thu, 13 Mar 2003 17:51:00 +0000
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 h2DHolc01141;
	Thu, 13 Mar 2003 12:50:47 -0500
Message-ID: <3E70C4F7.4030008@embeddededge.com>
Date: Thu, 13 Mar 2003 12:50:47 -0500
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bruno Randolf <br1@4g-systems.de>
CC: linux-mips@linux-mips.org
Subject: Re: Mycable XXS board
References: <3E689267.3070509@prosyst.bg> <200303131408.05612.br1@4g-systems.de> <3E70ABCE.9030909@embeddededge.com> <200303131823.22343.br1@4g-systems.de>
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: 1731
X-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
Content-Length: 452
Lines: 17

Bruno Randolf wrote:

> allright, i can do that - but doesn't this create a lot of unnecessary copied 
> code?

Initially, perhaps, but over time similar software will be moved into
common areas.  IMHO, it helps to keep these boards separate because
it serves to remind us the XXS board is not a PB1500.  You may also
find more things unique to your board, so the unique board configuration
will become useful to isolate features.

Thanks.


	-- Dan



From ranjanp@efi.com Thu Mar 13 18:01:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 18:01:38 +0000 (GMT)
Received: from mail3.efi.com ([IPv6:::ffff:192.68.228.90]:56329 "HELO
	fcexgw03.efi.internal") by linux-mips.org with SMTP
	id <S8225223AbTCMSBi> convert rfc822-to-8bit; Thu, 13 Mar 2003 18:01:38 +0000
Received: from 10.3.12.12 by fcexgw03.efi.internal (InterScan E-Mail VirusWall NT); Thu, 13 Mar 2003 10:00:50 -0800
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: Disabling lwl and lwr instruction generation
Date: Thu, 13 Mar 2003 10:00:47 -0800
Message-ID: <D9F6B9DABA4CAE4B92850252C52383AB07968240@ex-eng-corp.efi.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Disabling lwl and lwr instruction generation
Thread-Index: AcLpAJ3NhIG4bZ4lTiedoyVdN97f4gAiQp8A
From: "Ranjan Parthasarathy" <ranjanp@efi.com>
To: "Ralf Baechle" <ralf@linux-mips.org>,
	"Richard Hodges" <rh@matriplex.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: 1732
X-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
Content-Length: 1148
Lines: 31

Thanks for all your replies and no I am not working on the chinese processor :-). BTW it would be nice to have a mips option on override cpu options for disabling the lwl,lwr,swl,swr similar to "Cpu has ll/sc".

Thanks

Ranjan

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Wednesday, March 12, 2003 5:34 PM
To: Richard Hodges
Cc: Ranjan Parthasarathy; 'linux-mips@linux-mips.org'
Subject: Re: Disabling lwl and lwr instruction generation


On Wed, Mar 12, 2003 at 04:50:53PM -0800, Richard Hodges wrote:

> I got lwl and lwr from a memcpy() with two void pointers...
> 
> I quickly changed those to the (aligned) structure pointers instead, and
> then memcpy() changed to ordinary word loads and stores.
> 
> So, is somebody starting a toolchain for that new Chinese CPU? :-)

Wouldn't be the first processor without lwl/lwr instructions.  There have
been a few that didn't implement it for silly bean^Wgate counting issues
others have done it for patent and licensing reasons.

(Afair MIPS's patent is about to expire and IBM's prior art patent in the
same area is even way older but that legalese ...)

  Ralf

From ppopov@mvista.com Thu Mar 13 18:07:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 18:07:28 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:8700 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225223AbTCMSH1>;
	Thu, 13 Mar 2003 18:07:27 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA14833;
	Thu, 13 Mar 2003 10:07:16 -0800
Subject: Re: Mycable XXS board
From: Pete Popov <ppopov@mvista.com>
To: Bruno Randolf <br1@4g-systems.de>
Cc: linux-mips@linux-mips.org
In-Reply-To: <3E70C4F7.4030008@embeddededge.com>
References: <3E689267.3070509@prosyst.bg>
	 <200303131408.05612.br1@4g-systems.de> <3E70ABCE.9030909@embeddededge.com>
	 <200303131823.22343.br1@4g-systems.de>  <3E70C4F7.4030008@embeddededge.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047578844.819.35.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 13 Mar 2003 10:07:25 -0800
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: 1733
X-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
Content-Length: 937
Lines: 32

On Thu, 2003-03-13 at 09:50, Dan Malek wrote:
> Bruno Randolf wrote:
> 
> > allright, i can do that - but doesn't this create a lot of unnecessary copied 
> > code?
> 
> Initially, perhaps, but over time similar software will be moved into
> common areas.  IMHO, it helps to keep these boards separate because
> it serves to remind us the XXS board is not a PB1500.  You may also
> find more things unique to your board, so the unique board configuration
> will become useful to isolate features.

I agree with that.  Everything that's in common between the Au boards
should be in the common directory, arch/mips/au1000/common. But like Dan
said, by the time you're done with the entire board port, you may find
other unique things to your board which require additional ifdefs, and
keeping the board separate would be cleaner.

If this a board that's available off the shelf to customers?

Pete


> Thanks.
> 
> 
> 	-- Dan
> 
> 
> 
> 


From ranjanp@efi.com Thu Mar 13 18:09:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 18:09:43 +0000 (GMT)
Received: from mail3.efi.com ([IPv6:::ffff:192.68.228.90]:30479 "HELO
	fcexgw03.efi.internal") by linux-mips.org with SMTP
	id <S8225223AbTCMSJm> convert rfc822-to-8bit; Thu, 13 Mar 2003 18:09:42 +0000
Received: from 10.3.12.12 by fcexgw03.efi.internal (InterScan E-Mail VirusWall NT); Thu, 13 Mar 2003 10:09:04 -0800
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: Disabling lwl and lwr instruction generation
Date: Thu, 13 Mar 2003 10:09:03 -0800
Message-ID: <D9F6B9DABA4CAE4B92850252C52383AB07968241@ex-eng-corp.efi.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Disabling lwl and lwr instruction generation
Thread-Index: AcLpAJ3NhIG4bZ4lTiedoyVdN97f4gAigrvw
From: "Ranjan Parthasarathy" <ranjanp@efi.com>
To: "Ralf Baechle" <ralf@linux-mips.org>,
	"Richard Hodges" <rh@matriplex.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: 1734
X-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
Content-Length: 1452
Lines: 35

From the gcc sources, the compiler generates the lwl,lwr etc. in the block move code in gcc/config/mips/mips.c ( output_block_move ). 

There is an option -mmemcpy which tells gcc to use a memcpy compiled in with the sources for this block move instead of gcc genetrating code. The problem however with this is that arch/mips/lib/memcpy.S is optimized using lwl,lwr,swl,swr. If this can be  modified so that lwl,lwr,swl,swr is used if enabled as a kernel option, it might work very well. 

Any ideas / suggestions?

Thanks

Ranjan

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Wednesday, March 12, 2003 5:34 PM
To: Richard Hodges
Cc: Ranjan Parthasarathy; 'linux-mips@linux-mips.org'
Subject: Re: Disabling lwl and lwr instruction generation


On Wed, Mar 12, 2003 at 04:50:53PM -0800, Richard Hodges wrote:

> I got lwl and lwr from a memcpy() with two void pointers...
> 
> I quickly changed those to the (aligned) structure pointers instead, and
> then memcpy() changed to ordinary word loads and stores.
> 
> So, is somebody starting a toolchain for that new Chinese CPU? :-)

Wouldn't be the first processor without lwl/lwr instructions.  There have
been a few that didn't implement it for silly bean^Wgate counting issues
others have done it for patent and licensing reasons.

(Afair MIPS's patent is about to expire and IBM's prior art patent in the
same area is even way older but that legalese ...)

  Ralf

From baitisj@idealab.com Thu Mar 13 18:47:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 18:47:11 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:44504 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225223AbTCMSrK>;
	Thu, 13 Mar 2003 18:47:10 +0000
Received: (qmail 18445 invoked by uid 6180); 13 Mar 2003 18:47:04 -0000
Date: Thu, 13 Mar 2003 10:47:04 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: arch/mips/au1000/common/irq.c
Message-ID: <20030313104704.V20129@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: 1735
X-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
Content-Length: 888
Lines: 42

Pete:

I've got a question concerning irq.c. In intc0_req0_irqdispatch() (linux_2_4
branch) on lines 545 thru 552, the code reads:

      for (i=0; i<32; i++) {
          if ((intc0_req0 & (1<<i))) {
              intc0_req0 &= ~(1<<i);
              do_IRQ(irq, regs);
              break;
          }
          irq++;
      }

My question is: why do we increment i and irq independently?
Why doesn't the code read:

      for (i=0; i<32; i++) {
          if ((intc0_req0 & (1<<i))) {
              intc0_req0 &= ~(1<<i);
              do_IRQ(i, regs);
              break;
          }
      }

Thanks for your help!

-Jeff





-- 
         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 dan@embeddededge.com Thu Mar 13 18:51:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 18:51:03 +0000 (GMT)
Received: from 154-84-51-66.reonbroadband.com ([IPv6:::ffff:66.51.84.154]:38784
	"EHLO tibook.netx4.com") by linux-mips.org with ESMTP
	id <S8225223AbTCMSux>; Thu, 13 Mar 2003 18:50:53 +0000
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 h2DIokc01209;
	Thu, 13 Mar 2003 13:50:46 -0500
Message-ID: <3E70D306.5090608@embeddededge.com>
Date: Thu, 13 Mar 2003 13:50:46 -0500
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: baitisj@evolution.com
CC: Pete Popov <ppopov@mvista.com>, linux-mips@linux-mips.org
Subject: Re: arch/mips/au1000/common/irq.c
References: <20030313104704.V20129@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: 1736
X-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
Content-Length: 324
Lines: 16

Jeff Baitis wrote:

> Pete:
> 
> I've got a question concerning irq.c. In intc0_req0_irqdispatch() (linux_2_4
> branch) on lines 545 thru 552, the code reads:

I'm hacking these functions to use 'clz' and for other updates, so
the code will be changing soon, anyway :-)  Comment on the next version :-)

Thanks.


	-- Dan



From ppopov@mvista.com Thu Mar 13 18:59:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 18:59:49 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:35827 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225223AbTCMS7t>;
	Thu, 13 Mar 2003 18:59:49 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA16850;
	Thu, 13 Mar 2003 10:59:42 -0800
Subject: Re: arch/mips/au1000/common/irq.c
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com
Cc: linux-mips@linux-mips.org
In-Reply-To: <20030313104704.V20129@luca.pas.lab>
References: <20030313104704.V20129@luca.pas.lab>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047581991.819.52.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 13 Mar 2003 10:59:51 -0800
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: 1737
X-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
Content-Length: 919
Lines: 34

On Thu, 2003-03-13 at 10:47, Jeff Baitis wrote:
> Pete:
> 
> I've got a question concerning irq.c. In intc0_req0_irqdispatch() (linux_2_4
> branch) on lines 545 thru 552, the code reads:
> 
>       for (i=0; i<32; i++) {
>           if ((intc0_req0 & (1<<i))) {
>               intc0_req0 &= ~(1<<i);
>               do_IRQ(irq, regs);
>               break;
>           }
>           irq++;
>       }
> 
> My question is: why do we increment i and irq independently?
> Why doesn't the code read:
> 
>       for (i=0; i<32; i++) {
>           if ((intc0_req0 & (1<<i))) {
>               intc0_req0 &= ~(1<<i);
>               do_IRQ(i, regs);
>               break;
>           }
>       }
> 
> Thanks for your help!

No reason. It was probably more clear to me when writing the code and
later I didn't look for such improvements. Like Dan said though, he's
updating/optimizing that part of the code anyway ...

Pete


From hartvig@ekner.info Thu Mar 13 20:04:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 20:04:50 +0000 (GMT)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:28165 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225223AbTCMUEu>;
	Thu, 13 Mar 2003 20:04:50 +0000
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id B6370B6A9
	for <linux-mips@linux-mips.org>; Thu, 13 Mar 2003 21:04:46 +0100 (CET)
Message-ID: <3E70E52E.B6FF1C2A@ekner.info>
Date: Thu, 13 Mar 2003 21:08:15 +0100
From: Hartvig Ekner <hartvig@ekner.info>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Patches for Au1000: PCI int problem, DB1500 board reset & ethernet
Content-Type: multipart/mixed;
 boundary="------------28C30766B1EB581C0E18AA6B"
Return-Path: <hartvig@ekner.info>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1738
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvig@ekner.info
Precedence: bulk
X-list: linux-mips
Content-Length: 3925
Lines: 133

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

Hi,

The first patch below fixes interrupt setup for DB1500. The PCI interrupts were polarized wrongly, causing a deadlock when used.
The second patch adds board reset using HW register for DB1500.
The third patch reverses interrupt handling order for RX & TX to minimize packet loss in high-load situations.

/Hartvig



--------------28C30766B1EB581C0E18AA6B
Content-Type: text/plain; charset=us-ascii;
 name="IRQ_patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="IRQ_patch"

Index: irq.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/common/irq.c,v
retrieving revision 1.11.2.14
diff -u -r1.11.2.14 irq.c
--- irq.c	26 Feb 2003 21:14:24 -0000	1.11.2.14
+++ irq.c	13 Mar 2003 19:45:57 -0000
@@ -430,14 +430,10 @@
 			case AU1000_IRDA_RX_INT:
 
 			case AU1000_MAC0_DMA_INT:
-#if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_DB1000) || defined(CONFIG_MIPS_DB1500)
-			case AU1000_MAC1_DMA_INT:
-#endif
-#ifdef CONFIG_MIPS_PB1500
+#if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_DB1000) || defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_DB1500)
 			case AU1000_MAC1_DMA_INT:
 #endif
 			case AU1500_GPIO_204:
-
 				setup_local_irq(i, INTC_INT_HIGH_LEVEL, 0);
 				irq_desc[i].handler = &level_irq_type;
 				break;
@@ -446,7 +442,7 @@
 			case AU1000_GPIO_15:
 #endif
 		        case AU1000_USB_HOST_INT:
-#ifdef CONFIG_MIPS_PB1500
+#if defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_DB1500)
 			case AU1000_PCI_INTA:
 			case AU1000_PCI_INTB:
 			case AU1000_PCI_INTC:
@@ -488,9 +484,9 @@
 			case AU1000_RTC_MATCH0_INT:
 			case AU1000_RTC_MATCH1_INT:
 			case AU1000_RTC_MATCH2_INT:
-			        setup_local_irq(i, INTC_INT_RISE_EDGE, 0);
-                                irq_desc[i].handler = &rise_edge_irq_type;
-                                break;
+				setup_local_irq(i, INTC_INT_RISE_EDGE, 0);
+				irq_desc[i].handler = &rise_edge_irq_type;
+				break;
 
 				 // Careful if you change match 2 request!
 				 // The interrupt handler is called directly

--------------28C30766B1EB581C0E18AA6B
Content-Type: text/plain; charset=us-ascii;
 name="RESET_patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="RESET_patch"

Index: reset.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/common/reset.c,v
retrieving revision 1.2.2.8
diff -u -r1.2.2.8 reset.c
--- reset.c	11 Dec 2002 06:12:29 -0000	1.2.2.8
+++ reset.c	13 Mar 2003 19:46:03 -0000
@@ -111,15 +111,13 @@
 	set_c0_config(CONF_CM_UNCACHED);
 	flush_cache_all();
 	write_c0_wired(0);
- 
-#ifdef CONFIG_MIPS_PB1500
-	au_writel(0x00000000, 0xAE00001C);
-#endif
 
-#ifdef CONFIG_MIPS_PB1100
+#if defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_PB1100) || defined(CONFIG_MIPS_DB1500)
+	/* Do a HW reset if the board can do it */
+
 	au_writel(0x00000000, 0xAE00001C);
 #endif
- 
+
 	__asm__ __volatile__("jr\t%0"::"r"(0xbfc00000));
 }
 

--------------28C30766B1EB581C0E18AA6B
Content-Type: text/plain; charset=us-ascii;
 name="ETH_patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ETH_patch"

Index: au1000_eth.c
===================================================================
RCS file: /home/cvs/linux/drivers/net/au1000_eth.c,v
retrieving revision 1.5.2.15
diff -u -r1.5.2.15 au1000_eth.c
--- au1000_eth.c	3 Mar 2003 06:40:30 -0000	1.5.2.15
+++ au1000_eth.c	13 Mar 2003 20:01:51 -0000
@@ -1414,8 +1414,11 @@
 		printk(KERN_ERR "%s: isr: null dev ptr\n", dev->name);
 		return;
 	}
-	au1000_tx_ack(dev);
+
+	/* Handle RX interrupts first to minimize chance of overrun */
+
 	au1000_rx(dev);
+	au1000_tx_ack(dev);
 }
 
 

--------------28C30766B1EB581C0E18AA6B--


From hartvig@ekner.info Thu Mar 13 20:28:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 20:28:49 +0000 (GMT)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:63504 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225223AbTCMU2s>;
	Thu, 13 Mar 2003 20:28:48 +0000
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id 103DFB51E
	for <linux-mips@linux-mips.org>; Thu, 13 Mar 2003 21:28:47 +0100 (CET)
Message-ID: <3E70EACF.8F6629E4@ekner.info>
Date: Thu, 13 Mar 2003 21:32:15 +0100
From: Hartvig Ekner <hartvig@ekner.info>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: IRQ warnings during boot on Au1500/DB1500
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <hartvig@ekner.info>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1739
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvig@ekner.info
Precedence: bulk
X-list: linux-mips
Content-Length: 3195
Lines: 82

Hi,

with current 2.4 CVS, I get these messages during boot on a DB1500:

...
eth0: Using AMD 79C874 10/100 BaseT PHY as default
eth1: Au1xxx ethernet found at 0xb1510000, irq 29
eth1: AMD 79C874 10/100 BaseT PHY at phy address 31
eth1: Using AMD 79C874 10/100 BaseT PHY as default
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20268: IDE controller at PCI slot 00:0d.0
PDC20268: chipset revision 2
PDC20268: not 100% native mode: will probe irqs later
PDC20268: ROM enabled at 0x000dc000
    ide0: BM-DMA at 0x0520-0x0527, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x0528-0x052f, BIOS settings: hdc:pio, hdd:pio
hda: IBM-DTLA-307030, ATA DISK drive
blk: queue 802d01e0, I/O limit 4095Mb (mask 0xffffffff)
warning: end_irq 62 did not enable (6)
warning: end_irq 60 did not enable (6)
warning: end_irq 59 did not enable (6)
warning: end_irq 58 did not enable (6)
warning: end_irq 57 did not enable (6)
warning: end_irq 55 did not enable (6)
warning: end_irq 54 did not enable (6)
warning: end_irq 52 did not enable (6)
warning: end_irq 51 did not enable (6)
warning: end_irq 50 did not enable (6)
warning: end_irq 49 did not enable (6)
warning: end_irq 48 did not enable (6)
warning: end_irq 46 did not enable (6)
warning: end_irq 45 did not enable (6)
warning: end_irq 44 did not enable (6)
warning: end_irq 43 did not enable (6)
warning: end_irq 42 did not enable (6)
warning: end_irq 41 did not enable (6)
warning: end_irq 40 did not enable (6)
warning: end_irq 39 did not enable (6)
warning: end_irq 38 did not enable (6)
warning: end_irq 18 did not enable (6)
warning: end_irq 14 did not enable (6)
warning: end_irq 62 did not enable (16)
warning: end_irq 60 did not enable (16)
warning: end_irq 59 did not enable (16)
warning: end_irq 58 did not enable (16)
warning: end_irq 57 did not enable (16)
warning: end_irq 55 did not enable (16)
warning: end_irq 54 did not enable (16)
warning: end_irq 52 did not enable (16)
warning: end_irq 51 did not enable (16)
warning: end_irq 50 did not enable (16)
warning: end_irq 49 did not enable (16)
warning: end_irq 48 did not enable (16)
warning: end_irq 46 did not enable (16)
warning: end_irq 45 did not enable (16)
warning: end_irq 44 did not enable (16)
warning: end_irq 43 did not enable (16)
warning: end_irq 42 did not enable (16)
warning: end_irq 41 did not enable (16)
warning: end_irq 40 did not enable (16)
warning: end_irq 39 did not enable (16)
warning: end_irq 38 did not enable (16)
warning: end_irq 18 did not enable (16)
hde: IRQ probe failed (0xfffbfffe)
warning: end_irq 62 did not enable (6)
warning: end_irq 60 did not enable (6)
warning: end_irq 59 did not enable (6)
warning: end_irq 58 did not enable (6)
warning: end_irq 57 did not enable (6)
warning: end_irq 55 did not enable (6)
warning: end_irq 54 did not enable (6)
warning: end_irq 52 did not enable (6)
warning: end_irq 51 did not enable (6)
warning: end_irq 50 did not enable (6)
warning: end_irq 49 did not enable (6)

Once the IDE probing is done, these messages don't seem to appear any more, and the kernel runs ok. Anybody seeing similar messages?

/Hartvig



From ppopov@mvista.com Thu Mar 13 20:35:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 20:35:56 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:3824 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225223AbTCMUfz>;
	Thu, 13 Mar 2003 20:35:55 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA21062;
	Thu, 13 Mar 2003 12:35:51 -0800
Subject: Re: IRQ warnings during boot on Au1500/DB1500
From: Pete Popov <ppopov@mvista.com>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <3E70EACF.8F6629E4@ekner.info>
References: <3E70EACF.8F6629E4@ekner.info>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047587761.819.63.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 13 Mar 2003 12:36:01 -0800
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: 1740
X-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
Content-Length: 610
Lines: 17


> Once the IDE probing is done, these messages don't seem to appear any more, and the kernel runs ok. 
> Anybody seeing similar messages?

Yes. I just mentioned that to Ralf but he wasn't sure where they are
coming from. I took a quick look and the cause is the irq probing being
done by the ide code. I don't know if that's "normal" but it feels like
there's something not quite right.  

On the bright side, the new ide patches Ralf checked in fix the ide-cs
pcmcia driver and with the new pcmcia pb1500 patch I checked in (and
with new CPU silicon), you can now use the pcmcia slot on the Pb1500.

Pete




From ZhouY.external@infineon.com Thu Mar 13 20:46:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 20:46:57 +0000 (GMT)
Received: from smtp1.infineon.com ([IPv6:::ffff:194.175.117.76]:48107 "EHLO
	smtp1.infineon.com") by linux-mips.org with ESMTP
	id <S8225223AbTCMUq5>; Thu, 13 Mar 2003 20:46:57 +0000
Received: from mucse011.eu.infineon.com (mucse011.ifx-mail1.com [172.29.27.228])
	by smtp1.infineon.com (8.12.8/8.12.8) with ESMTP id h2DKcD5X011807
	for <linux-mips@linux-mips.org>; Thu, 13 Mar 2003 21:38:13 +0100 (MET)
Received: by mucse011.eu.infineon.com with Internet Mail Service (5.5.2653.19)
	id <G626QV0C>; Thu, 13 Mar 2003 21:46:50 +0100
Message-ID: <3A5A80BF651115469CA99C8928706CB603D7B312@mucse004.eu.infineon.com>
From: ZhouY.external@infineon.com
To: linux-mips@linux-mips.org
Subject: How can I know whether the timer of the Linux is correct or not?
Date: Thu, 13 Mar 2003 21:46:50 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <ZhouY.external@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: 1741
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ZhouY.external@infineon.com
Precedence: bulk
X-list: linux-mips
Content-Length: 419
Lines: 14

Hello everyone,
  I am using a pre-compiled Linux kernel(2.4.18) to boot my MIPS 4Kc Malta
Board. Since I want to measure the performance of my applications, I decided
to use the syscall 'clock_gettime' to get the time data, but how can I
determine whether these time results fits my board's frequency or not, i.e.
are these results true?
  Anybody knows that?
  Thanks in advance!

  Best regards,

  Yidan Zhou
  
  

From ralf@linux-mips.net Thu Mar 13 21:35:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 21:35:40 +0000 (GMT)
Received: from p508B78BD.dip.t-dialin.net ([IPv6:::ffff:80.139.120.189]:32213
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225223AbTCMVfj>; Thu, 13 Mar 2003 21:35:39 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2DLZTb32464;
	Thu, 13 Mar 2003 22:35:29 +0100
Date: Thu, 13 Mar 2003 22:35:29 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Ranjan Parthasarathy <ranjanp@efi.com>
Cc: Richard Hodges <rh@matriplex.com>, linux-mips@linux-mips.org
Subject: Re: Disabling lwl and lwr instruction generation
Message-ID: <20030313223529.D30512@linux-mips.org>
References: <D9F6B9DABA4CAE4B92850252C52383AB07968241@ex-eng-corp.efi.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: <D9F6B9DABA4CAE4B92850252C52383AB07968241@ex-eng-corp.efi.com>; from ranjanp@efi.com on Thu, Mar 13, 2003 at 10:09:03AM -0800
Return-Path: <ralf@linux-mips.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: 1742
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 692
Lines: 15

On Thu, Mar 13, 2003 at 10:09:03AM -0800, Ranjan Parthasarathy wrote:

> From the gcc sources, the compiler generates the lwl,lwr etc. in the block
> move code in gcc/config/mips/mips.c ( output_block_move ). 
> 
> There is an option -mmemcpy which tells gcc to use a memcpy compiled in
> with the sources for this block move instead of gcc genetrating code. The
> problem however with this is that arch/mips/lib/memcpy.S is optimized
> using lwl,lwr,swl,swr. If this can be  modified so that lwl,lwr,swl,swr
> is used if enabled as a kernel option, it might work very well. 

Replace those unaligned copies with a word-wise or even bytewise copying.
Not good for performance but ...

  Ralf

From baitisj@idealab.com Thu Mar 13 22:13:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 22:13:35 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:16345 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225223AbTCMWNe>;
	Thu, 13 Mar 2003 22:13:34 +0000
Received: (qmail 21239 invoked by uid 6180); 13 Mar 2003 22:13:31 -0000
Date: Thu, 13 Mar 2003 14:13:31 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Dan Malek <dan@embeddededge.com>
Cc: Pete Popov <ppopov@mvista.com>, linux-mips@linux-mips.org
Subject: Re: arch/mips/au1000/common/irq.c
Message-ID: <20030313141331.Y20129@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030313104704.V20129@luca.pas.lab> <3E70D306.5090608@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: <3E70D306.5090608@embeddededge.com>; from dan@embeddededge.com on Thu, Mar 13, 2003 at 01:50:46PM -0500
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: 1743
X-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
Content-Length: 1236
Lines: 48

Dan:

I just verified that I get an IRQ storm when I plug a 3.3-volt based SMC
EPIC/100 network card into the PCI slot of the Au1500. Before I bring the
interface up, I notice that the driver tries to allocate IRQ 1 (INTA). This is
the same IRQ that the ill-fated CardBus bridge attempts to use. ;)

As soon as I bring the SMC interface up using ifconfig (and have the interface
plugged into an active Ethernet network), the IRQ storm ensues.

I'll try Hartvig's patch, look over the irq.c levels, and see how everything
fares.

Thanks all!

Regards,

Jeff


On Thu, Mar 13, 2003 at 01:50:46PM -0500, Dan Malek wrote:
> Jeff Baitis wrote:
> 
> > Pete:
> > 
> > I've got a question concerning irq.c. In intc0_req0_irqdispatch() (linux_2_4
> > branch) on lines 545 thru 552, the code reads:
> 
> I'm hacking these functions to use 'clz' and for other updates, so
> the code will be changing soon, anyway :-)  Comment on the next version :-)
> 
> Thanks.
> 
> 
> 	-- Dan
> 
> 
> 

-- 
         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 Thu Mar 13 22:16:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 22:16:48 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:18393 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225223AbTCMWQr>;
	Thu, 13 Mar 2003 22:16:47 +0000
Received: (qmail 21301 invoked by uid 6180); 13 Mar 2003 22:16:46 -0000
Date: Thu, 13 Mar 2003 14:16:46 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: IRQ warnings during boot on Au1500/DB1500
Message-ID: <20030313141645.A20129@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <3E70EACF.8F6629E4@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3E70EACF.8F6629E4@ekner.info>; from hartvig@ekner.info on Thu, Mar 13, 2003 at 09:32:15PM +0100
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: 1744
X-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
Content-Length: 3807
Lines: 103

Hartvig:

I get the same messages when I try to use a PCI CardBus bridge in polling mode
(INTA disabled).

Regards,
Jeff


On Thu, Mar 13, 2003 at 09:32:15PM +0100, Hartvig Ekner wrote:
> Hi,
> 
> with current 2.4 CVS, I get these messages during boot on a DB1500:
> 
> ...
> eth0: Using AMD 79C874 10/100 BaseT PHY as default
> eth1: Au1xxx ethernet found at 0xb1510000, irq 29
> eth1: AMD 79C874 10/100 BaseT PHY at phy address 31
> eth1: Using AMD 79C874 10/100 BaseT PHY as default
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> PDC20268: IDE controller at PCI slot 00:0d.0
> PDC20268: chipset revision 2
> PDC20268: not 100% native mode: will probe irqs later
> PDC20268: ROM enabled at 0x000dc000
>     ide0: BM-DMA at 0x0520-0x0527, BIOS settings: hda:pio, hdb:pio
>     ide1: BM-DMA at 0x0528-0x052f, BIOS settings: hdc:pio, hdd:pio
> hda: IBM-DTLA-307030, ATA DISK drive
> blk: queue 802d01e0, I/O limit 4095Mb (mask 0xffffffff)
> warning: end_irq 62 did not enable (6)
> warning: end_irq 60 did not enable (6)
> warning: end_irq 59 did not enable (6)
> warning: end_irq 58 did not enable (6)
> warning: end_irq 57 did not enable (6)
> warning: end_irq 55 did not enable (6)
> warning: end_irq 54 did not enable (6)
> warning: end_irq 52 did not enable (6)
> warning: end_irq 51 did not enable (6)
> warning: end_irq 50 did not enable (6)
> warning: end_irq 49 did not enable (6)
> warning: end_irq 48 did not enable (6)
> warning: end_irq 46 did not enable (6)
> warning: end_irq 45 did not enable (6)
> warning: end_irq 44 did not enable (6)
> warning: end_irq 43 did not enable (6)
> warning: end_irq 42 did not enable (6)
> warning: end_irq 41 did not enable (6)
> warning: end_irq 40 did not enable (6)
> warning: end_irq 39 did not enable (6)
> warning: end_irq 38 did not enable (6)
> warning: end_irq 18 did not enable (6)
> warning: end_irq 14 did not enable (6)
> warning: end_irq 62 did not enable (16)
> warning: end_irq 60 did not enable (16)
> warning: end_irq 59 did not enable (16)
> warning: end_irq 58 did not enable (16)
> warning: end_irq 57 did not enable (16)
> warning: end_irq 55 did not enable (16)
> warning: end_irq 54 did not enable (16)
> warning: end_irq 52 did not enable (16)
> warning: end_irq 51 did not enable (16)
> warning: end_irq 50 did not enable (16)
> warning: end_irq 49 did not enable (16)
> warning: end_irq 48 did not enable (16)
> warning: end_irq 46 did not enable (16)
> warning: end_irq 45 did not enable (16)
> warning: end_irq 44 did not enable (16)
> warning: end_irq 43 did not enable (16)
> warning: end_irq 42 did not enable (16)
> warning: end_irq 41 did not enable (16)
> warning: end_irq 40 did not enable (16)
> warning: end_irq 39 did not enable (16)
> warning: end_irq 38 did not enable (16)
> warning: end_irq 18 did not enable (16)
> hde: IRQ probe failed (0xfffbfffe)
> warning: end_irq 62 did not enable (6)
> warning: end_irq 60 did not enable (6)
> warning: end_irq 59 did not enable (6)
> warning: end_irq 58 did not enable (6)
> warning: end_irq 57 did not enable (6)
> warning: end_irq 55 did not enable (6)
> warning: end_irq 54 did not enable (6)
> warning: end_irq 52 did not enable (6)
> warning: end_irq 51 did not enable (6)
> warning: end_irq 50 did not enable (6)
> warning: end_irq 49 did not enable (6)
> 
> Once the IDE probing is done, these messages don't seem to appear any more, and the kernel runs ok. Anybody seeing similar messages?
> 
> /Hartvig
> 
> 
> 

-- 
         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 Thu Mar 13 22:25:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 22:25:04 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:20953 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225223AbTCMWZD>;
	Thu, 13 Mar 2003 22:25:03 +0000
Received: (qmail 21418 invoked by uid 6180); 13 Mar 2003 22:25:00 -0000
Date: Thu, 13 Mar 2003 14:25:00 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Dan Malek <dan@embeddededge.com>
Cc: Pete Popov <ppopov@mvista.com>, linux-mips@linux-mips.org,
	Hartvig Ekner <hartvig@ekner.info>
Subject: Re: arch/mips/au1000/common/irq.c
Message-ID: <20030313142500.B20129@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030313104704.V20129@luca.pas.lab> <3E70D306.5090608@embeddededge.com> <20030313141331.Y20129@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: <20030313141331.Y20129@luca.pas.lab>; from baitisj@evolution.com on Thu, Mar 13, 2003 at 02:13:31PM -0800
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: 1745
X-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
Content-Length: 1767
Lines: 68

Hartvig's patch has solved my IRQ storm problems. Thank you all very much for
your attention!

Regards,

Jeff


On Thu, Mar 13, 2003 at 02:13:31PM -0800, Jeff Baitis wrote:
> Dan:
> 
> I just verified that I get an IRQ storm when I plug a 3.3-volt based SMC
> EPIC/100 network card into the PCI slot of the Au1500. Before I bring the
> interface up, I notice that the driver tries to allocate IRQ 1 (INTA). This is
> the same IRQ that the ill-fated CardBus bridge attempts to use. ;)
> 
> As soon as I bring the SMC interface up using ifconfig (and have the interface
> plugged into an active Ethernet network), the IRQ storm ensues.
> 
> I'll try Hartvig's patch, look over the irq.c levels, and see how everything
> fares.
> 
> Thanks all!
> 
> Regards,
> 
> Jeff
> 
> 
> On Thu, Mar 13, 2003 at 01:50:46PM -0500, Dan Malek wrote:
> > Jeff Baitis wrote:
> > 
> > > Pete:
> > > 
> > > I've got a question concerning irq.c. In intc0_req0_irqdispatch() (linux_2_4
> > > branch) on lines 545 thru 552, the code reads:
> > 
> > I'm hacking these functions to use 'clz' and for other updates, so
> > the code will be changing soon, anyway :-)  Comment on the next version :-)
> > 
> > Thanks.
> > 
> > 
> > 	-- Dan
> > 
> > 
> > 
> 
> -- 
>          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 ppopov@mvista.com Thu Mar 13 22:46:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 22:46:37 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:46576 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225255AbTCMWqg>;
	Thu, 13 Mar 2003 22:46:36 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA26403;
	Thu, 13 Mar 2003 14:45:27 -0800
Subject: Re: Patches for Au1000: PCI int problem, DB1500 board reset &
	ethernet
From: Pete Popov <ppopov@mvista.com>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <3E70E52E.B6FF1C2A@ekner.info>
References: <3E70E52E.B6FF1C2A@ekner.info>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047595537.819.131.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 13 Mar 2003 14:45:38 -0800
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: 1746
X-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
Content-Length: 4018
Lines: 129

On Thu, 2003-03-13 at 12:08, Hartvig Ekner wrote:
> Hi,
> 
> The first patch below fixes interrupt setup for DB1500. The PCI interrupts 
> were polarized wrongly, causing a deadlock when used.

Applied. Thanks for catching that one. I had tested the Db1500 pci slot
with a graphics card. I guess the interrupt handling doesn't get tested
with a frame buffer driver :)

> The second patch adds board reset using HW register for DB1500.

I want to see if this is applicable to all Db boards before checking it
in.

> The third patch reverses interrupt handling order for RX & TX to 
> minimize packet loss in high-load situations.

Applied. Though I wonder about the performance when the target is
transmitting heavily vs receiving.

Pete

> 
> /Hartvig
> 
> 
> 
> ______________________________________________________________________
> 
> Index: irq.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/common/irq.c,v
> retrieving revision 1.11.2.14
> diff -u -r1.11.2.14 irq.c
> --- irq.c	26 Feb 2003 21:14:24 -0000	1.11.2.14
> +++ irq.c	13 Mar 2003 19:45:57 -0000
> @@ -430,14 +430,10 @@
>  			case AU1000_IRDA_RX_INT:
>  
>  			case AU1000_MAC0_DMA_INT:
> -#if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_DB1000) || defined(CONFIG_MIPS_DB1500)
> -			case AU1000_MAC1_DMA_INT:
> -#endif
> -#ifdef CONFIG_MIPS_PB1500
> +#if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_DB1000) || defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_DB1500)
>  			case AU1000_MAC1_DMA_INT:
>  #endif
>  			case AU1500_GPIO_204:
> -
>  				setup_local_irq(i, INTC_INT_HIGH_LEVEL, 0);
>  				irq_desc[i].handler = &level_irq_type;
>  				break;
> @@ -446,7 +442,7 @@
>  			case AU1000_GPIO_15:
>  #endif
>  		        case AU1000_USB_HOST_INT:
> -#ifdef CONFIG_MIPS_PB1500
> +#if defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_DB1500)
>  			case AU1000_PCI_INTA:
>  			case AU1000_PCI_INTB:
>  			case AU1000_PCI_INTC:
> @@ -488,9 +484,9 @@
>  			case AU1000_RTC_MATCH0_INT:
>  			case AU1000_RTC_MATCH1_INT:
>  			case AU1000_RTC_MATCH2_INT:
> -			        setup_local_irq(i, INTC_INT_RISE_EDGE, 0);
> -                                irq_desc[i].handler = &rise_edge_irq_type;
> -                                break;
> +				setup_local_irq(i, INTC_INT_RISE_EDGE, 0);
> +				irq_desc[i].handler = &rise_edge_irq_type;
> +				break;
>  
>  				 // Careful if you change match 2 request!
>  				 // The interrupt handler is called directly
> 
> ______________________________________________________________________
> 
> Index: reset.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/common/reset.c,v
> retrieving revision 1.2.2.8
> diff -u -r1.2.2.8 reset.c
> --- reset.c	11 Dec 2002 06:12:29 -0000	1.2.2.8
> +++ reset.c	13 Mar 2003 19:46:03 -0000
> @@ -111,15 +111,13 @@
>  	set_c0_config(CONF_CM_UNCACHED);
>  	flush_cache_all();
>  	write_c0_wired(0);
> - 
> -#ifdef CONFIG_MIPS_PB1500
> -	au_writel(0x00000000, 0xAE00001C);
> -#endif
>  
> -#ifdef CONFIG_MIPS_PB1100
> +#if defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_PB1100) || defined(CONFIG_MIPS_DB1500)
> +	/* Do a HW reset if the board can do it */
> +
>  	au_writel(0x00000000, 0xAE00001C);
>  #endif
> - 
> +
>  	__asm__ __volatile__("jr\t%0"::"r"(0xbfc00000));
>  }
>  
> 
> ______________________________________________________________________
> 
> Index: au1000_eth.c
> ===================================================================
> RCS file: /home/cvs/linux/drivers/net/au1000_eth.c,v
> retrieving revision 1.5.2.15
> diff -u -r1.5.2.15 au1000_eth.c
> --- au1000_eth.c	3 Mar 2003 06:40:30 -0000	1.5.2.15
> +++ au1000_eth.c	13 Mar 2003 20:01:51 -0000
> @@ -1414,8 +1414,11 @@
>  		printk(KERN_ERR "%s: isr: null dev ptr\n", dev->name);
>  		return;
>  	}
> -	au1000_tx_ack(dev);
> +
> +	/* Handle RX interrupts first to minimize chance of overrun */
> +
>  	au1000_rx(dev);
> +	au1000_tx_ack(dev);
>  }
>  
> 


From ppopov@mvista.com Thu Mar 13 22:50:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 22:50:18 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27122 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225223AbTCMWuR>;
	Thu, 13 Mar 2003 22:50:17 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA26741;
	Thu, 13 Mar 2003 14:50:14 -0800
Subject: Re: Patches for Au1000: PCI int problem, DB1500 board reset &
	ethernet
From: Pete Popov <ppopov@mvista.com>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <3E70E52E.B6FF1C2A@ekner.info>
References: <3E70E52E.B6FF1C2A@ekner.info>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047595825.819.134.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 13 Mar 2003 14:50:25 -0800
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: 1747
X-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
Content-Length: 211
Lines: 9


> The second patch adds board reset using HW register for DB1500.

OK, that's applicable to all Db boards so I modified the patch and
applied it; might need to cleanup that later (the long ifdef line).

Pete



From alan@lxorguk.ukuu.org.uk Thu Mar 13 23:12:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Mar 2003 23:12:43 +0000 (GMT)
Received: from pc2-cwma1-4-cust86.swan.cable.ntl.com ([IPv6:::ffff:213.105.254.86]:14800
	"EHLO irongate.swansea.linux.org.uk") by linux-mips.org with ESMTP
	id <S8225223AbTCMXMm>; Thu, 13 Mar 2003 23:12:42 +0000
Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1])
	by irongate.swansea.linux.org.uk (8.12.7/8.12.7) with ESMTP id h2E0L6Yf027532;
	Fri, 14 Mar 2003 00:21:06 GMT
Received: (from alan@localhost)
	by irongate.swansea.linux.org.uk (8.12.7/8.12.7/Submit) id h2E0L4nn027530;
	Fri, 14 Mar 2003 00:21:04 GMT
X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Disabling lwl and lwr instruction generation
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Ranjan Parthasarathy <ranjanp@efi.com>,
	Richard Hodges <rh@matriplex.com>, linux-mips@linux-mips.org
In-Reply-To: <20030313223529.D30512@linux-mips.org>
References: <D9F6B9DABA4CAE4B92850252C52383AB07968241@ex-eng-corp.efi.com>
	 <20030313223529.D30512@linux-mips.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1047601263.27471.10.camel@irongate.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 (1.2.1-4) 
Date: 14 Mar 2003 00:21:03 +0000
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1748
X-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
Content-Length: 393
Lines: 11

On Thu, 2003-03-13 at 21:35, Ralf Baechle wrote:
> Replace those unaligned copies with a word-wise or even bytewise copying.
> Not good for performance but ...

Depends on (src^dest) & 3. Glibc may have the code you need to get it
right, although it will also depend on how smart the cpu cache is - if
you have a write through cache then shift/mask/write in 32/64 chunks
may be fastest


Alan

From wgowcher@yahoo.com Fri Mar 14 02:13:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Mar 2003 02:13:12 +0000 (GMT)
Received: from web11905.mail.yahoo.com ([IPv6:::ffff:216.136.172.189]:26628
	"HELO web11905.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225223AbTCNCNM>; Fri, 14 Mar 2003 02:13:12 +0000
Message-ID: <20030314021308.60082.qmail@web11905.mail.yahoo.com>
Received: from [209.243.184.164] by web11905.mail.yahoo.com via HTTP; Thu, 13 Mar 2003 18:13:08 PST
Date: Thu, 13 Mar 2003 18:13:08 -0800 (PST)
From: Wayne Gowcher <wgowcher@yahoo.com>
Subject: Tips on inspecting / debuging cache
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <wgowcher@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1749
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wgowcher@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 492
Lines: 22

Dear List,

I am wondering if someone could point me towards
articles / source code that would give me a little
insight into how to debug cache problems in mips.

For example , how do I inspect the contents of the
cache ? Are there routines to dump out the contents of
the cache ?

Any help, tips , pointers would be appreciated.

TIA

Wayne 



__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

From kevink@mips.com Fri Mar 14 08:15:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Mar 2003 08:15:37 +0000 (GMT)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:21897 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225197AbTCNIPg>;
	Fri, 14 Mar 2003 08:15:36 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h2E8FJUe017662;
	Fri, 14 Mar 2003 00:15:19 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id AAA20692;
	Fri, 14 Mar 2003 00:15:19 -0800 (PST)
Message-ID: <001301c2ea02$d27a9bc0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Wayne Gowcher" <wgowcher@yahoo.com>, <linux-mips@linux-mips.org>
References: <20030314021308.60082.qmail@web11905.mail.yahoo.com>
Subject: Re: Tips on inspecting / debuging cache
Date: Fri, 14 Mar 2003 09:22:13 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1750
X-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
Content-Length: 1049
Lines: 27

> I am wondering if someone could point me towards
> articles / source code that would give me a little
> insight into how to debug cache problems in mips.
> 
> For example , how do I inspect the contents of the
> cache ? 

Which MIPS CPU are you using?  The CACHE instruction
was introduced with the R4000 CPU as an implementation
dependent feature, and was finally standardized in the MIPS32
and MIPS64 architecture specs.  See
http://www.mips.com/publications/processor_architecture.html
In MIPS32, to be able to properly inspect the cache, one needs
a CPU which implements the optional Index_Load_Tag CACHE 
operation and has both TagHi/TagLo (required) DataHi/DataLo 
(optional) registers. Pre-MIPS32 CPUs may offer the ability
to inspect the cache with variant mechanisms (see your chip
spec), or not at all.

>Are there routines to dump out the contents of
> the cache ?

People write them from time to time, but so far I don't
think anyone has written a "standard" cache dump API
or implementation in the Linux kernel.

            Kevin K.

From ralf@linux-mips.net Fri Mar 14 19:26:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Mar 2003 19:26:15 +0000 (GMT)
Received: from p508B7656.dip.t-dialin.net ([IPv6:::ffff:80.139.118.86]:2539
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225202AbTCNT0P>; Fri, 14 Mar 2003 19:26:15 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2EJQ9q04333;
	Fri, 14 Mar 2003 20:26:09 +0100
Date: Fri, 14 Mar 2003 20:26:09 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Wayne Gowcher <wgowcher@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Tips on inspecting / debuging cache
Message-ID: <20030314202609.A3670@linux-mips.org>
References: <20030314021308.60082.qmail@web11905.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030314021308.60082.qmail@web11905.mail.yahoo.com>; from wgowcher@yahoo.com on Thu, Mar 13, 2003 at 06:13:08PM -0800
Return-Path: <ralf@linux-mips.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: 1751
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1376
Lines: 29

On Thu, Mar 13, 2003 at 06:13:08PM -0800, Wayne Gowcher wrote:

> I am wondering if someone could point me towards
> articles / source code that would give me a little
> insight into how to debug cache problems in mips.
> 
> For example , how do I inspect the contents of the
> cache ? Are there routines to dump out the contents of
> the cache ?

Frankly, such code isn't to useful.  The problems in the cache code can
be fairly subtle.  The only thing that has worked halfway well is reading
the code 1,000 times more after having read it 1,000 times.  And because
it's such a nice job, read it another 1000 times when finished.

If you're refering to the current round of cache problems introduced about
three days ago when I eleminated flush_page_to_ram() and replace it
with flush_dcache_page() - the untested quickfix is changing the
definitions of clear_user_page() and copy_user_page() in <asm/page.h> to
flush the data cache after the operation, for example by invoking
flush_cache_all().  This particular problem affects all processors with
virtually indexed data caches except the R4000 and R4000 SC and MC
versions and the R10000 family.

And everybody's favorite question, was this necessary that late in 2.4?
Yes, it was.  The new mechanism deals is not only more efficient it also
deals better with aliases between the pagecache and userspace mappings.

  Ralf

From baitisj@idealab.com Fri Mar 14 20:23:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Mar 2003 20:23:57 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:24540 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225202AbTCNUX4>;
	Fri, 14 Mar 2003 20:23:56 +0000
Received: (qmail 5876 invoked by uid 6180); 14 Mar 2003 20:23:52 -0000
Date: Fri, 14 Mar 2003 12:23:52 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Success! Full CardBus/EXCA on PCI->Cardbus Bridge + DbAU1500
Message-ID: <20030314122352.F20129@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: 1752
X-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
Content-Length: 2011
Lines: 65

Everyone:

Thank you very much for helping this green hand get up to speed on the MIPS
platform.  I have successfully configured card services to work with the
current linux_2_4 CVS, in conjunction with a TI PCI1510 PCI->CardBus bridge.

There are a few card services options that you will need, in order to replicate
my work:

1. The pcmcia_core cis_speed needs to be set to a fairly low value.
   I have successfully used `modprobe pcmcia_core cis_speed=10` and 
   `modprobe pcmcia_core cis_speed=1.`

2. The PCMCIA memory window must map into the memory window assigned
   by the PCI device autoconfiguration. Since my `lspci -v` shows:

   00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56
       Subsystem: Unknown device 5678:1234
       Flags: bus master, medium devsel, latency 168, IRQ 1
       Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
       Bus: primary=00, secondary=05, subordinate=00, sec-latency=176
       Memory window 0: 40001000-40002000 (prefetchable)
       Memory window 1: 40400000-407ff000
       I/O window 0: 00004000-000040ff
       I/O window 1: 00004400-000044ff
       16-bit legacy interface ports at 0001
 
   I configured /etc/pcmcia/config.opts as follows:

       #
       # Local PCMCIA Configuration File
       #
       #----------------------------------------------------------------------
       
       # System resources available for PCMCIA devices
       # remember to modprobe pcmcia_core cis_speed=10
       
       include port 0x100-0x4ff, port 0xc00-0xcff
       include memory 0x40000000-0x40ffffff

       #-------------------------- eof 


Special thanks to Pete for answering so many of my questions.


I hope you find this information useful!



Best regards,

Jeff



-- 
         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 ppopov@mvista.com Fri Mar 14 21:34:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Mar 2003 21:34:11 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:12286 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225202AbTCNVeK>;
	Fri, 14 Mar 2003 21:34:10 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id NAA02473;
	Fri, 14 Mar 2003 13:34:05 -0800
Subject: Re: Success! Full CardBus/EXCA on PCI->Cardbus Bridge + DbAU1500
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030314122352.F20129@luca.pas.lab>
References: <20030314122352.F20129@luca.pas.lab>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1047677667.18887.162.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 14 Mar 2003 13:34:28 -0800
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: 1753
X-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
Content-Length: 2106
Lines: 55

On Fri, 2003-03-14 at 12:23, Jeff Baitis wrote:
> Everyone:
> 
> Thank you very much for helping this green hand get up to speed on the MIPS
> platform.  I have successfully configured card services to work with the
> current linux_2_4 CVS, in conjunction with a TI PCI1510 PCI->CardBus bridge.
> 
> There are a few card services options that you will need, in order to replicate
> my work:
> 
> 1. The pcmcia_core cis_speed needs to be set to a fairly low value.
>    I have successfully used `modprobe pcmcia_core cis_speed=10` and 
>    `modprobe pcmcia_core cis_speed=1.`
> 
> 2. The PCMCIA memory window must map into the memory window assigned
>    by the PCI device autoconfiguration. Since my `lspci -v` shows:
> 
>    00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56
>        Subsystem: Unknown device 5678:1234
>        Flags: bus master, medium devsel, latency 168, IRQ 1
>        Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
>        Bus: primary=00, secondary=05, subordinate=00, sec-latency=176
>        Memory window 0: 40001000-40002000 (prefetchable)
>        Memory window 1: 40400000-407ff000
>        I/O window 0: 00004000-000040ff
>        I/O window 1: 00004400-000044ff
>        16-bit legacy interface ports at 0001
>  
>    I configured /etc/pcmcia/config.opts as follows:
> 
>        #
>        # Local PCMCIA Configuration File
>        #
>        #----------------------------------------------------------------------
>        
>        # System resources available for PCMCIA devices
>        # remember to modprobe pcmcia_core cis_speed=10
>        
>        include port 0x100-0x4ff, port 0xc00-0xcff
>        include memory 0x40000000-0x40ffffff
> 
>        #-------------------------- eof 

Yep, I had to do that way back then when I got the same sort of setup
working.  Good job figuring that out :)

Just to confirm, this setup works with the current linux-mips.org plus
the above info?  No other patches are required, correct?

I think I'll start an Alchemy/AMD FAQ or something in my directory and
put this information there. Thanks!

Pete



From wgowcher@yahoo.com Fri Mar 14 21:53:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Mar 2003 21:53:49 +0000 (GMT)
Received: from web11904.mail.yahoo.com ([IPv6:::ffff:216.136.172.188]:59149
	"HELO web11904.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225202AbTCNVxt>; Fri, 14 Mar 2003 21:53:49 +0000
Message-ID: <20030314215346.38796.qmail@web11904.mail.yahoo.com>
Received: from [209.243.184.164] by web11904.mail.yahoo.com via HTTP; Fri, 14 Mar 2003 13:53:46 PST
Date: Fri, 14 Mar 2003 13:53:46 -0800 (PST)
From: Wayne Gowcher <wgowcher@yahoo.com>
Subject: Re: Tips on inspecting / debuging cache
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20030314202609.A3670@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <wgowcher@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1754
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wgowcher@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 269
Lines: 13

Ralf,

Thanks for the feedback.

I believe my problem is not due to your recent
changes. But thanks for the heads up :)



__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

From baitisj@idealab.com Fri Mar 14 21:57:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Mar 2003 21:57:24 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:39132 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225202AbTCNV5X>;
	Fri, 14 Mar 2003 21:57:23 +0000
Received: (qmail 6956 invoked by uid 6180); 14 Mar 2003 21:57:21 -0000
Date: Fri, 14 Mar 2003 13:57:21 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Success! Full CardBus/EXCA on PCI->Cardbus Bridge + DbAU1500
Message-ID: <20030314135721.G20129@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030314122352.F20129@luca.pas.lab> <1047677667.18887.162.camel@zeus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <1047677667.18887.162.camel@zeus.mvista.com>; from ppopov@mvista.com on Fri, Mar 14, 2003 at 01:34:28PM -0800
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: 1755
X-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
Content-Length: 4874
Lines: 130

On Fri, Mar 14, 2003 at 01:34:28PM -0800, Pete Popov wrote:

> Yep, I had to do that way back then when I got the same sort of setup
> working.  Good job figuring that out :)
> 
> Just to confirm, this setup works with the current linux-mips.org plus
> the above info?  No other patches are required, correct?
> 
> I think I'll start an Alchemy/AMD FAQ or something in my directory and
> put this information there. Thanks!

The patches that I'm using:

Pete's 36bit_addr_2.4.21-pre4.patch
Pete's 64bit_pcmcia.patch

Additionally, I had to apply the patch to include/asm-mips/io.h in order
to get the hermes/orinoco drivers to compile. (I posted this patch earlier, and
someone suggested that the SLOW_DOWN_IO; call was not necessary). Find it below.

I have some other patches applied; they should not affect PCMCIA. I'll check
out clean source and patch it with this bare minimum, and let you know
if something else is required.

Thanks, Pete -- a FAQ about your patches will really help people who are
starting out on the Alchemy platform.

Regards,

Jeff


  Index: io.h
  ===================================================================
  RCS file: /home/cvs/linux/include/asm-mips/io.h,v
  retrieving revision 1.29.2.20
  diff -u -r1.29.2.20 io.h
  --- io.h        25 Feb 2003 22:03:12 -0000      1.29.2.20
  +++ io.h        14 Mar 2003 21:50:14 -0000
  @@ -332,12 +332,25 @@
          SLOW_DOWN_IO;                                                   \
   } while(0)
  °
  -#define outw_p(val,port)                                               \
  -do {                                                                   \
  -       *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
  -               __ioswab16(val);                                        \
  -       SLOW_DOWN_IO;                                                   \
  -} while(0)
  +/* baitisj */
  +static inline u16 outw_p(u16 val, unsigned long port)
  +{
  +    register u16 retval;
  +    do {
  +        retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
  +            __ioswab16(val);
  +        SLOW_DOWN_IO;
  +    } while(0);
  +    return retval;
  +}
  +/*°°
  + *  #define outw_p(val,port)                                           \
  + *  do {                                                                       \
  + *     *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
  + *             __ioswab16(val);                                        \
  + *     SLOW_DOWN_IO;                                                   \
  + *  } while(0)
  + */
  °
   #define outl_p(val,port)                                               \
   do {                                                                   \
  
> On Fri, 2003-03-14 at 12:23, Jeff Baitis wrote:
> > Everyone:
> > 
> > Thank you very much for helping this green hand get up to speed on the MIPS
> > platform.  I have successfully configured card services to work with the
> > current linux_2_4 CVS, in conjunction with a TI PCI1510 PCI->CardBus bridge.
> > 
> > There are a few card services options that you will need, in order to replicate
> > my work:
> > 
> > 1. The pcmcia_core cis_speed needs to be set to a fairly low value.
> >    I have successfully used `modprobe pcmcia_core cis_speed=10` and 
> >    `modprobe pcmcia_core cis_speed=1.`
> > 
> > 2. The PCMCIA memory window must map into the memory window assigned
> >    by the PCI device autoconfiguration. Since my `lspci -v` shows:
> > 
> >    00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56
> >        Subsystem: Unknown device 5678:1234
> >        Flags: bus master, medium devsel, latency 168, IRQ 1
> >        Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
> >        Bus: primary=00, secondary=05, subordinate=00, sec-latency=176
> >        Memory window 0: 40001000-40002000 (prefetchable)
> >        Memory window 1: 40400000-407ff000
> >        I/O window 0: 00004000-000040ff
> >        I/O window 1: 00004400-000044ff
> >        16-bit legacy interface ports at 0001
> >  
> >    I configured /etc/pcmcia/config.opts as follows:
> > 
> >        #
> >        # Local PCMCIA Configuration File
> >        #
> >        #----------------------------------------------------------------------
> >        
> >        # System resources available for PCMCIA devices
> >        # remember to modprobe pcmcia_core cis_speed=10
> >        
> >        include port 0x100-0x4ff, port 0xc00-0xcff
> >        include memory 0x40000000-0x40ffffff
> > 
> >        #-------------------------- eof 
> 
> 
> Pete
> 
> 
> 

-- 
         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 Adam_Kiepul@pmc-sierra.com Fri Mar 14 23:27:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Mar 2003 23:27:03 +0000 (GMT)
Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:46841 "HELO
	mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8225263AbTCNX1C>; Fri, 14 Mar 2003 23:27:02 +0000
Received: (qmail 24289 invoked by uid 104); 14 Mar 2003 23:26:55 -0000
Received: from Adam_Kiepul@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4252.  Clear:. 
 Processed in 1.209598 secs); 14 Mar 2003 23:26:55 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.com with SMTP; 14 Mar 2003 23:26:53 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2ENQqh01812;
	Fri, 14 Mar 2003 15:26:52 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4NR55>; Fri, 14 Mar 2003 15:26:52 -0800
Message-ID: <71690137A786F7428FF9670D47CB95ED10E01E@SJE4EXM01>
From: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>
To: "'Wayne Gowcher'" <wgowcher@yahoo.com>, linux-mips@linux-mips.org
Subject: RE: Tips on inspecting / debuging cache
Date: Fri, 14 Mar 2003 15:23:52 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Return-Path: <Adam_Kiepul@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1756
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Adam_Kiepul@pmc-sierra.com
Precedence: bulk
X-list: linux-mips
Content-Length: 7038
Lines: 285

Hi Wayne,

Enclosed please find routines that I developed for PMC-Sierra RM52x1 and RM7000 processors.
Enjoy!

Adam


# Cache Dump - will dump the cache contents from I or D cache.
# Arguments:
# a0 is 0 for I Cache or 1 for D Cache
# a1 is the pointer to the Tag/States Array. Size is Cache Size / 4. There are 2 words per line.
# a2 is the pointer to the Data Array (size equal to the Cache size, MUST be Set Size aligned)
# Note: For user's convenience the pointers can be in KSeg1 or KSeg0.
#
# The TagHi/TagLo registers are stored in an array pointed to by the 2nd argument.
#
# TagHi_Address(Set, Index) = a1 + Set*(SET_SIZE/4) + 8*Index
# TagLo_Address(Set, Index) = a1 + Set*(SET_SIZE/4) + 8*Index + 4
#
# In case of RM52x1 Caches are 32KB total, 2-way set-associative so SET_SIZE is 16KB.
# With 32B line size there are 16KB/32B = 512 lines per Set.
# Thus:
#
# TagHi_Address(Set, Index) = a1 + Set*4096 + 8*Index
# TagLo_Address(Set, Index) = a1 + Set*4096 + 8*Index + 4
#
# Where Set is 0..1 and Index is 0..511.
#
# Cache Data fields are stored in an array pointed to by the 3rd argument.
#
# Line_Data_Address(Set, Index) = a2 + Set*SET_SIZE + Index*32
#
# In case of RM52x1 it is:
#
# Line_Data_Address(Set, Index) = a2 + Set*16384 + Index*32
#
# Note: The Original Physical Address of a cache line has to be calculated based on Tag and Index.
#
# In case of RM52x1 the Physical Address of the cache line is calculated as follows:
#
# PA = ((TagLo & 0xffffff00) << 4) | ((Index*32) & 0x00000fff)
#
# Note: The PA and Data Field are only valid if the line is marked Valid in the TagLo.
# This means that the State field (TagLo[7:6]) must be 3 for D Cache or 2 for I Cache.



#define C0_TAGLO			$28
#define C0_TAGHI			$29

#define Index_Load_Tag_I		4
#define Index_Load_Tag_D		5
#define Index_Store_Tag_I		8
#define Index_Store_Tag_D		9
#define Hit_Writeback_I			24
#define Hit_Writeback_D			25
#define Create_Dirty_Exclusive_D	13

#define ICACHE_VALID			2
#define DCACHE_VALID			3


# Now: 1 is for RM52x1 and 0 is for RM7000

#define RM52x1				1

#if RM52x1
#define CACHE_SIZE			0x00008000
#else
#define CACHE_SIZE			0x00004000
#endif


	.text

	.set noreorder
	.set noat

	.globl cachedmp
	.ent	cachedmp

	.align 5

cachedmp:

# Switch to K1 (optional for D Cache dumping)

	la	t0, 1f
	li	t1, 0x20000000
	or	t0, t1
	jr	t0
	nop
1:

# Read and Modify the Tags/States

	li	t0, 0x80000000				# base address for Index cache ops in t0
	li	t1, 0x80000000+CACHE_SIZE-32		# end address in t1
	li	at, 0x20000000
	or	t2, a1, at				# convert a1 to a K1 address and put to t2
	or	a2, at
	xor	a2, at					# make sure pointer in a2 is a K0 address
	or	t3, a2, zero				# copy a2 to t3
L1:	bne	a0, zero, 1f
	nop
	cache	Index_Load_Tag_I, (t0)
	b	2f
	nop
1:	cache	Index_Load_Tag_D, (t0)
2:	nop ; nop ; nop ; nop
	mfc0	t4, C0_TAGHI
	mfc0	t5, C0_TAGLO
	sw	t4, 0(t2)				# preserve the original Tags/States
	sw	t5, 4(t2)
	li	t7, 0x1ffff000				# mask for PA[28:12]
	and	t7, t3					# mask bits of the pointer in t3
	srl	t7, 4					# t7 is now a Tag for the pointer
#if RM52x1
	li	t6, 0x0000003f
	and	t6, t5					# mask off the PTagLo and PState
	or	t6, t7					# "paste" the Tag value to t6
#else
	mtc0	t7, C0_TAGHI				# in RM7k the Tag is in TAGHI
	li	t6, 0xfff0003f
	and	t6, t5					# mask off the PState
#endif
	bne	a0, zero, 1f				# now set the PState field as valid
	nop
	b	2f
	ori	t6, ICACHE_VALID<<6
1:	ori	t6, DCACHE_VALID<<6
2:	mtc0	t6, C0_TAGLO				# write the new value to TAGLO
	nop ; nop ; nop ; nop
	bne	a0, zero, 1f
	nop
	cache	Index_Store_Tag_I, (t0)			# write back to the cache line states
	b	2f
	nop
1:	cache	Index_Store_Tag_D, (t0)
2:	addiu	t2, 8
	addiu	t3, 32
	bne	t0, t1, L1
	addiu	t0, 32

# For D Cache need to touch the lines in order to set the W bits (make them Dirty)
# We can not use Create_Dirty_Exclusive because it would clear the data fields.
# Therefore we read and store back a word in every line.

	beq	a0, zero, 1f				# Skip for I Cache
	nop

	or	t0, a2, zero
	li	t1, CACHE_SIZE-32
	addu	t1, t0
L2:	lw	t2, (t0)
	sw	t2, (t0)
	bne	t0, t1, L2
	addiu	t0, 32
1:

# Now Write Back the cache contents

	or	t0, a2, zero
	li	t1, CACHE_SIZE-32
	addu	t1, t0
L3:	bne	a0, zero, 1f
	nop
	cache	Hit_Writeback_I, (t0)
	b	2f
	nop
1:	cache	Hit_Writeback_D, (t0)
2:	bne	t0, t1, L3
	addiu	t0, 32

	jr	ra
	nop

	.end	cachedmp

##############################

/* Now: 1 is for RM52x1 and 0 is for RM7000 */

#define RM52x1				1


#if RM52x1
#define CACHE_SIZE	0x00008000
#define SET			2
#else
#define CACHE_SIZE	0x00004000
#define SET			4
#endif

#define SET_SIZE		(CACHE_SIZE/SET)
#define INDEX		SET_SIZE/32

#define Tag_Array_1	0xa0208000
#define Data_Array_1	0xa0200000
#define Tag_Array_2	0xa0218000
#define Data_Array_2	0xa0210000

unsigned char serial_buffer[250];

CacheDisplay(unsigned long TagsAddr, unsigned long DataAddr)
{ int Set, Index, i;
  unsigned long TAGHI, TAGLO, PA, State, Word, *CurrentTags, *CurrentWord;

CurrentTags=(unsigned long *)TagsAddr;

#if RM52x1
CurrentWord=(unsigned long *)DataAddr;
#else
CurrentWord=(unsigned long *)(DataAddr&0xdfffffff);
#endif
/* For RM7k we need to read the written-back data cached just in case it ends up in L2 */

for(Set=0; Set<SET; Set++)
    for(Index=0; Index<INDEX; Index++)
        { sprintf(serial_buffer, "\n\rSet: %d, Index: %03d", Set, Index);
          dumpstr(serial_buffer);
          TAGHI=*CurrentTags++;
          TAGLO=*CurrentTags++;
          sprintf(serial_buffer, "\n\rTAGHI=0x%08x, TAGLO=0x%08x", TAGHI, TAGLO);
          dumpstr(serial_buffer);
#if RM52x1
          PA=((TAGLO & 0xffffff00) << 4) | ((Index*32) & 0x00000fff);
#else
          PA=((TAGHI & 0xffffff00) << 4) | ((Index*32) & 0x00000fff);
#endif
          State=(TAGLO & 0x000000c0)>>6;
          sprintf(serial_buffer, "\n\rPA=0x%08x, State=0x%x, Data Words:\n\r", PA, State);
          dumpstr(serial_buffer);
          for(i=0; i<8; i++)
             { Word=*CurrentWord++;
               sprintf(serial_buffer, "%08x ", Word);
               dumpstr(serial_buffer);
             }
          dumpstr("\n\r");
        }
}

main()
{ 
dumpstr("\n\rRunning the cachedmp for D Cache\n\r");
cachedmp(1, Tag_Array_1, Data_Array_1);
CacheDisplay(Tag_Array_1, Data_Array_1);
dumpstr("\n\rRunning the cachedmp for I Cache\n\r");
cachedmp(0, Tag_Array_2, Data_Array_2);
CacheDisplay(Tag_Array_2, Data_Array_2);
}




-----Original Message-----
From: Wayne Gowcher [mailto:wgowcher@yahoo.com]
Sent: Thursday, March 13, 2003 6:13 PM
To: linux-mips@linux-mips.org
Subject: Tips on inspecting / debuging cache


Dear List,

I am wondering if someone could point me towards
articles / source code that would give me a little
insight into how to debug cache problems in mips.

For example , how do I inspect the contents of the
cache ? Are there routines to dump out the contents of
the cache ?

Any help, tips , pointers would be appreciated.

TIA

Wayne 



__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

From arthur.petitpierre@gadz.org Sun Mar 16 00:16:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 Mar 2003 00:16:34 +0000 (GMT)
Received: from [IPv6:::ffff:195.101.176.125] ([IPv6:::ffff:195.101.176.125]:60043
	"EHLO magma.kin.home") by linux-mips.org with ESMTP
	id <S8225232AbTCPAQd>; Sun, 16 Mar 2003 00:16:33 +0000
Received: from rabuzou.kin.home ([172.20.0.98] helo=localhost)
	by magma.kin.home with smtp (Exim 3.35 #1 (Debian))
	id 18uLpA-0001mZ-00
	for <linux-mips@linux-mips.org>; Sun, 16 Mar 2003 01:16:24 +0100
Date: Sun, 16 Mar 2003 01:16:13 +0100
From: Arthur Petitpierre <arthur.petitpierre@gadz.org>
To: linux-mips@linux-mips.org
Subject: kernel compilation error on indy with r4600
Message-Id: <20030316011613.766aa81d.arthur.petitpierre@gadz.org>
Organization: KIN
X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <arthur.petitpierre@gadz.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1757
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: arthur.petitpierre@gadz.org
Precedence: bulk
X-list: linux-mips
Content-Length: 809
Lines: 14

	Hi,

I've got an Indy whith a r46000 cpu and a Debian installed on it, and when I try to compile a new kernel (with gcc-2.95),
I do 'make menuconfig', 'make dep' without any problem and when I try 'make vmlinux', I got error as following :

gcc -D__KERNEL__ -I/usr/src/kernel-source-2.4.19/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /usr/src/kernel-source-2.4.19/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap   -DKBUILD_BASENAME=main -c -o init/main.o init/main.c
as: unrecognized option `-mcpu=r4600'
init/main.c: In function `calibrate_delay':
init/main.c:199: Internal compiler error:
init/main.c:199: output pipe has been closed
make: *** [init/main.o] Error 1

Any solution to fix it. Thanks,
		Arthur

From fxzhang@ict.ac.cn Sun Mar 16 06:36:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 Mar 2003 06:37:00 +0000 (GMT)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:45454
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8224851AbTCPGg7>; Sun, 16 Mar 2003 06:36:59 +0000
Received: (qmail 5028 invoked from network); 16 Mar 2003 06:20:51 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 16 Mar 2003 06:20:51 -0000
Message-ID: <3E74CF10.5080305@ict.ac.cn>
Date: Sun, 16 Mar 2003 14:22:56 -0500
From: Zhang Fuxin <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020809
X-Accept-Language: zh-cn, en-us
MIME-Version: 1.0
To: Arthur Petitpierre <arthur.petitpierre@gadz.org>
CC: linux-mips@linux-mips.org
Subject: Re: kernel compilation error on indy with r4600
References: <20030316011613.766aa81d.arthur.petitpierre@gadz.org>
Content-Type: text/plain; charset=x-gbk; 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: 1758
X-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
Content-Length: 988
Lines: 30



Arthur Petitpierre wrote:

>	Hi,
>
>I've got an Indy whith a r46000 cpu and a Debian installed on it, and when I try to compile a new kernel (with gcc-2.95),
>I do 'make menuconfig', 'make dep' without any problem and when I try 'make vmlinux', I got error as following :
>
>gcc -D__KERNEL__ -I/usr/src/kernel-source-2.4.19/include -Wall -Wstrict-prototypes -Wno-trigraphs 
>
^^^^^^Are you sure you are using mips gcc? If you are cross-compiling,it 
should normally be mips(el)-linux-gcc here

>-O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /usr/src/kernel-source-2.4.19/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap   -DKBUILD_BASENAME=main -c -o init/main.o init/main.c
>as: unrecognized option `-mcpu=r4600'
>init/main.c: In function `calibrate_delay':
>init/main.c:199: Internal compiler error:
>init/main.c:199: output pipe has been closed
>make: *** [init/main.o] Error 1
>
>Any solution to fix it. Thanks,
>		Arthur
>
>
>
>  
>



From jwhwang@daelimins.com Tue Mar 18 07:41:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 07:41:03 +0000 (GMT)
Received: from [IPv6:::ffff:203.226.2.19] ([IPv6:::ffff:203.226.2.19]:57863
	"EHLO mail.ditco.com") by linux-mips.org with ESMTP
	id <S8225072AbTCRHlC>; Tue, 18 Mar 2003 07:41:02 +0000
Received: from LocalHost ([203.226.1.239])
	by mail.ditco.com (8.9.3/8.9.3) with ESMTP id QAA24810
	for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 16:39:02 +0900
From: =?ks_c_5601-1987?B?yLLA57/t?= <jwhwang@daelimins.com>
To: <linux-mips@linux-mips.org>
Subject: about linux porting on SGI origin 300
Date: Tue, 18 Mar 2003 16:46:01 +0900
Message-ID: <000001c2ed22$6c55f9c0$ef01e2cb@LocalHost>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C2ED6D.DC3DA1C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <jwhwang@daelimins.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1759
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jwhwang@daelimins.com
Precedence: bulk
X-list: linux-mips
Content-Length: 8566
Lines: 276

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C2ED6D.DC3DA1C0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit

I hoe your business prospers.
I have some question about linux-mips.
I have SGI origin 300 (4cpu, 2.5GB mem, FC-AL), but I want to install
Linux on this machine.
Is it possible?
Can I make this machine DB Server(Oracle 9i) ?
Please let me know,,,
 
Best Regards,,,,
 
Jaewook hwang
Daelim information & Service CO. 

------=_NextPart_000_0001_01C2ED6D.DC3DA1C0
Content-Type: text/html;
	charset="ks_c_5601-1987"
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=3D"http://www.w3.org/TR/REC-html40">

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


<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@01C2ED6D.DB4F4A20">
<!--[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:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEve=
ry>
  =
<w:DisplayVerticalDrawingGridEvery>2</w:DisplayVerticalDrawingGridEvery>
  <w:Compatibility>
   <w:SpaceForUL/>
   <w:BalanceSingleByteDoubleByteWidth/>
   <w:DoNotLeaveBackslashAlone/>
   <w:ULTrailSpace/>
   <w:DoNotExpandShiftReturn/>
   <w:AdjustLineHeightInTable/>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:=B9=D9=C5=C1;
	panose-1:2 3 6 0 0 1 1 1 1 1;
	mso-font-alt:Batang;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:=B1=BC=B8=B2;
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-alt:Gulim;
	mso-font-charset:129;
	mso-generic-font-family:modern;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:"\@=B1=BC=B8=B2";
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-charset:129;
	mso-generic-font-family:modern;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:"\@=B9=D9=C5=C1";
	panose-1:2 3 6 0 0 1 1 1 1 1;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	mso-pagination:none;
	text-autospace:none;
	word-break:break-hangul;
	font-size:10.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:=B9=D9=C5=C1;
	mso-hansi-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:1.0pt;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
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:=B1=BC=B8=B2;
	mso-ascii-font-family:=B1=BC=B8=B2;
	mso-fareast-font-family:=B1=BC=B8=B2;
	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 Definitions */
 @page
	{mso-page-border-surround-header:no;
	mso-page-border-surround-footer:no;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:99.25pt 3.0cm 3.0cm 3.0cm;
	mso-header-margin:42.55pt;
	mso-footer-margin:49.6pt;
	mso-paper-source:0;
	layout-grid:18.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"=C7=A5=C1=D8 =C7=A5";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DKO link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:40.0pt'>

<div class=3DSection1 style=3D'layout-grid:18.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3D=B1=BC=B8=B2><span =
lang=3DEN-US style=3D'font-size:10.0pt;
mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-font-family:=
Arial;
mso-bidi-font-family:Arial'>I hoe your business =
prospers.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B1=BC=B8=B2><span =
lang=3DEN-US style=3D'font-size:10.0pt;
mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-font-family:=
Arial;
mso-bidi-font-family:Arial'>I have some question about <span =
class=3DSpellE>linux-mips</span>.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B1=BC=B8=B2><span =
lang=3DEN-US style=3D'font-size:10.0pt;
mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-font-family:=
Arial;
mso-bidi-font-family:Arial'>I have SGI origin 300 (4cpu, 2.5GB <span
class=3DSpellE>mem</span>, FC-AL), but I want to install Linux on this =
machine.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B1=BC=B8=B2><span =
lang=3DEN-US style=3D'font-size:10.0pt;
mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-font-family:=
Arial;
mso-bidi-font-family:Arial'>Is it possible?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B1=BC=B8=B2><span =
lang=3DEN-US style=3D'font-size:10.0pt;
mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-font-family:=
Arial;
mso-bidi-font-family:Arial'>Can I make this machine DB <span =
class=3DGramE>Server(</span>Oracle
9i) ?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B1=BC=B8=B2><span =
lang=3DEN-US style=3D'font-size:10.0pt;
mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-font-family:=
Arial;
mso-bidi-font-family:Arial'>Please let me know<span =
class=3DGramE>,,,</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B1=BC=B8=B2><span =
lang=3DEN-US style=3D'font-size:10.0pt;
mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-font-family:=
Arial;
mso-bidi-font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B1=BC=B8=B2><span =
lang=3DEN-US style=3D'font-size:10.0pt;
mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-font-family:=
Arial;
mso-bidi-font-family:Arial'>Best Regards<span =
class=3DGramE>,,,,</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B1=BC=B8=B2><span =
lang=3DEN-US style=3D'font-size:10.0pt;
mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-font-family:=
Arial;
mso-bidi-font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><span class=3DSpellE><font size=3D2 =
face=3D=B1=BC=B8=B2><span lang=3DEN-US
style=3D'font-size:10.0pt;mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=
=B2;mso-hansi-font-family:
Arial;mso-bidi-font-family:Arial'>Jaewook</span></font></span><font =
face=3D=B1=BC=B8=B2><span
lang=3DEN-US =
style=3D'mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-fon=
t-family:
Arial;mso-bidi-font-family:Arial'> <span =
class=3DSpellE>hwang</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DSpellE><font size=3D2 =
face=3D=B1=BC=B8=B2><span lang=3DEN-US
style=3D'font-size:10.0pt;mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=
=B2;mso-hansi-font-family:
Arial;mso-bidi-font-family:Arial'>Daelim</span></font></span><font =
face=3D=B1=BC=B8=B2><span
lang=3DEN-US =
style=3D'mso-bidi-font-size:10.0pt;font-family:=B1=BC=B8=B2;mso-hansi-fon=
t-family:
Arial;mso-bidi-font-family:Arial'> information &amp; Service CO. =
<o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C2ED6D.DC3DA1C0--


From hartvig@ekner.info Tue Mar 18 08:12:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 08:12:40 +0000 (GMT)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:37390 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225072AbTCRIMk>;
	Tue, 18 Mar 2003 08:12:40 +0000
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id A1571B5F8
	for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 09:12:30 +0100 (CET)
Message-ID: <3E76D5FC.323C0C74@ekner.info>
Date: Tue, 18 Mar 2003 09:17:00 +0100
From: Hartvig Ekner <hartvig@ekner.info>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Patch to make Db1500 Audio codec recognized
Content-Type: multipart/mixed;
 boundary="------------B342AF166B0D036F4D1E2481"
Return-Path: <hartvig@ekner.info>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1760
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvig@ekner.info
Precedence: bulk
X-list: linux-mips
Content-Length: 1202
Lines: 36

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

A small patch to make the AMD Db1500 Audio codec correctly recognized.

/Hartvig



--------------B342AF166B0D036F4D1E2481
Content-Type: text/plain; charset=us-ascii;
 name="ac97_patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ac97_patch"

Index: ac97_codec.c
===================================================================
RCS file: /home/cvs/linux/drivers/sound/Attic/ac97_codec.c,v
retrieving revision 1.18.2.4
diff -u -r1.18.2.4 ac97_codec.c
--- ac97_codec.c	25 Feb 2003 22:03:09 -0000	1.18.2.4
+++ ac97_codec.c	18 Mar 2003 08:10:53 -0000
@@ -153,6 +153,7 @@
 	{0x83847608, "SigmaTel STAC9708",	&sigmatel_9708_ops},
 	{0x83847609, "SigmaTel STAC9721/23",	&sigmatel_9721_ops},
 	{0x83847644, "SigmaTel STAC9744/45",	&sigmatel_9744_ops},
+	{0x83847652, "SigmaTel STAC9752/53",	&default_ops},
 	{0x83847656, "SigmaTel STAC9756/57",	&sigmatel_9744_ops},
 	{0x83847666, "SigmaTel STAC9750T",	&sigmatel_9744_ops},
 	{0x83847684, "SigmaTel STAC9783/84?",	&null_ops},

--------------B342AF166B0D036F4D1E2481--


From soeren.laursen@scrooge.dk Tue Mar 18 09:52:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 09:52:59 +0000 (GMT)
Received: from 213.237.12.36.adsl.ynoe.worldonline.dk ([IPv6:::ffff:213.237.12.36]:6983
	"EHLO HUGIN") by linux-mips.org with ESMTP id <S8225072AbTCRJw6> convert rfc822-to-8bit;
	Tue, 18 Mar 2003 09:52:58 +0000
Received: from amavis by HUGIN with scanned-ok (Exim 3.12 #1 (Debian))
	id 18vDm4-0002F2-00
	for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 10:52:48 +0100
Received: from athlon-pc ([10.0.0.2] helo=athlon-800)
	by HUGIN with esmtp (Exim 3.12 #1 (Debian))
	id 18vDm3-0002Et-00; Tue, 18 Mar 2003 10:52:47 +0100
From: "Soeren Laursen" <soeren.laursen@scrooge.dk>
To: linux-mips@linux-mips.org
Date: Tue, 18 Mar 2003 10:52:49 +0100
MIME-Version: 1.0
Subject: Re: about linux porting on SGI origin 300
Reply-to: soeren.laursen@scrooge.dk
CC: whwang@daelimins.com
Message-ID: <3E76FA81.19936.4A4FD6@localhost>
Priority: normal
In-reply-to: <000001c2ed22$6c55f9c0$ef01e2cb@LocalHost>
X-mailer: Pegasus Mail for Windows (v4.02)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8BIT
Content-description: Mail message body
X-Virus-Scanned: by AMaViS perl-11
Return-Path: <soeren.laursen@scrooge.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: 1761
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: soeren.laursen@scrooge.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 96
Lines: 6

> Can I make this machine DB Server(Oracle 9i) ?
Yes, if you run IRIX,

Regards,

Søren Laursen

From soeren.laursen@scrooge.dk Tue Mar 18 12:57:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 12:57:29 +0000 (GMT)
Received: from 213.237.12.36.adsl.ynoe.worldonline.dk ([IPv6:::ffff:213.237.12.36]:32072
	"EHLO HUGIN") by linux-mips.org with ESMTP id <S8225199AbTCRM52> convert rfc822-to-8bit;
	Tue, 18 Mar 2003 12:57:28 +0000
Received: from amavis by HUGIN with scanned-ok (Exim 3.12 #1 (Debian))
	id 18vGeX-00066X-00
	for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 13:57:13 +0100
Received: from athlon-pc ([10.0.0.2] helo=athlon-800)
	by HUGIN with esmtp (Exim 3.12 #1 (Debian))
	id 18vGeS-00066F-00; Tue, 18 Mar 2003 13:57:08 +0100
From: "Soeren Laursen" <soeren.laursen@scrooge.dk>
To: Florian Laws <florian@void.s.bawue.de>
Date: Tue, 18 Mar 2003 13:57:12 +0100
MIME-Version: 1.0
Subject: Re: about linux porting on SGI origin 300
Reply-to: soeren.laursen@scrooge.dk
CC: linux-mips@linux-mips.org
Message-ID: <3E7725B8.26789.F31A40@localhost>
Priority: normal
In-reply-to: <20030318124653.GB724@void.s.bawue.de>
References: <3E76FA81.19936.4A4FD6@localhost>
X-mailer: Pegasus Mail for Windows (v4.02)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8BIT
Content-description: Mail message body
X-Virus-Scanned: by AMaViS perl-11
Return-Path: <soeren.laursen@scrooge.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: 1762
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: soeren.laursen@scrooge.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 358
Lines: 19

Ups, 
Your are right, Oracle9i is dead on the IRIX 

Regards,

Søren,
> On Tue, Mar 18, 2003 at 10:52:49AM +0100, Soeren Laursen wrote:
> > > Can I make this machine DB Server(Oracle 9i) ?
> > Yes, if you run IRIX,
> 
> Oracle 9i is available for IRIX?
> Thanks for the info, i thought, Oracle stopped supporting IRIX
> with 8i.
> 
> Regards,
> 
> Florian



From agx@sigxcpu.org Tue Mar 18 15:44:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 15:44:15 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:17359
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225203AbTCRPoO>; Tue, 18 Mar 2003 15:44:14 +0000
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id CC67E2BC30
	for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 16:44:09 +0100 (CET)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 23196-04
 for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 16:44:08 +0100 (CET)
Received: from bogon.sigxcpu.org (kons-d9bb543c.pool.mediaWays.net [217.187.84.60])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 001E42BC2F
	for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 16:44:07 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 52AFC1735C; Tue, 18 Mar 2003 16:41:56 +0100 (CET)
Date: Tue, 18 Mar 2003 16:41:56 +0100
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030318154155.GF2613@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1763
X-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
Content-Length: 250
Lines: 9

Hi,
it seems newer binutils doen't know about -mcpu anymore. Is it correct
to simply change:
 -mcpu=r5000 -mips2 -Wa,--trap
to
 -mtune=r5000 -mips2 -Wa,--trap
for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
Regards,
 -- Guido

From ica2_ts@csv.ica.uni-stuttgart.de Tue Mar 18 16:03:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 16:03:07 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:50109
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225203AbTCRQDG>; Tue, 18 Mar 2003 16:03:06 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 18vJYO-001y95-00; Tue, 18 Mar 2003 17:03:04 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 18vJYN-0003EG-00; Tue, 18 Mar 2003 17:03:03 +0100
Date: Tue, 18 Mar 2003 17:03:03 +0100
To: linux-mips@linux-mips.org
Cc: Guido Guenther <agx@sigxcpu.org>
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030318154155.GF2613@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030318154155.GF2613@bogon.ms20.nix>
User-Agent: Mutt/1.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: 1764
X-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
Content-Length: 557
Lines: 21

Guido Guenther wrote:
> Hi,
> it seems newer binutils doen't know about -mcpu anymore. Is it correct
> to simply change:
>  -mcpu=r5000 -mips2 -Wa,--trap
> to
>  -mtune=r5000 -mips2 -Wa,--trap

On newer toolchains this will select r6000 opcodes with r5000 scheduling.

Try
   -mabi=o32 -march=r5000 -Wa,--trap
This may fail if the compiler is very old, though.

> for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.

This was fixed in very recent gcc. -mips2 should be an alias for -march=r6000
and -mips4 one for -march=r8000.


Thiemo

From listbox@evernex.com Tue Mar 18 17:42:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 17:43:00 +0000 (GMT)
Received: from mta9-0.mail.adelphia.net ([IPv6:::ffff:64.8.50.199]:17634 "EHLO
	mta9.adelphia.net") by linux-mips.org with ESMTP
	id <S8225203AbTCRRm7>; Tue, 18 Mar 2003 17:42:59 +0000
Received: from there ([24.51.55.15]) by mta6.adelphia.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP
          id <20030318172414.MLZJ7686.mta6.adelphia.net@there>
          for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 12:24:14 -0500
Content-Type: text/plain;
  charset="iso-8859-1"
From: Neurophyre <listbox@evernex.com>
To: linux-mips@linux-mips.org
Subject: 2.4.20 SCSI problems on NASRaQ
Date: Tue, 18 Mar 2003 12:24:10 -0500
X-Mailer: KMail [version 1.3.2]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20030318172414.MLZJ7686.mta6.adelphia.net@there>
Return-Path: <listbox@evernex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1765
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: listbox@evernex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1344
Lines: 36

Hello all.  I'm trying to get Debian 3.0r1 working usefully on a
MIPS-based Seagate (Cobalt) NASRaQ.  The system uses the same processor
as the Qube 2 and has an integrated 53c860 SCSI controller, which would
appear to be supported by no fewer than three kernel drivers!

I'm compiling the kernel source available at
ftp://ftp.linux-mips.org/pub/linux/mips/kernel/test/linux-2.4.20.tar.gz
WITH Paul Martin's tulip and PCIfun patches applied.  I should mention
that the stock 2.4.20 source with the debian kernel-patch-2.4-cobalt
package applied to it presented numerous problems and I had to give up.

The problem is that upon boot (or module installation), I get similar
messages from all three SCSI drivers.

Examples:

sym.0.8.0: IO region 0x10102000[0..127] is in use
or
ncr53c8xx: IO region 0x10102000[0..127] is in use

On boot, the boot process just goes on, but no 'scsi0 blah blah'
printout occurs, and nothing is printed about a tape drive I have
attached to the machine for testing.

When installing as a module (only tested with sym53c8xx driver) the
module installation fails and a message like above is printed to the
serial console.

Doing a 'cat /proc/scsi/scsi' yields

Attached devices: none

no matter what.

Does anyone have any suggestions?  We'd really like to modernize the
NASRaQ and still be able to use its SCSI port.

From agx@sigxcpu.org Tue Mar 18 17:44:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 17:44:57 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:64463
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225203AbTCRRo5>; Tue, 18 Mar 2003 17:44:57 +0000
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 92D592BC30
	for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 18:44:54 +0100 (CET)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 23757-01
 for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 18:44:53 +0100 (CET)
Received: from bogon.sigxcpu.org (kons-d9bb543c.pool.mediaWays.net [217.187.84.60])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 8C9652BC2F
	for <linux-mips@linux-mips.org>; Tue, 18 Mar 2003 18:44:53 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 83B4E1735C; Tue, 18 Mar 2003 18:42:41 +0100 (CET)
Date: Tue, 18 Mar 2003 18:42:41 +0100
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030318174241.GG2613@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1766
X-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
Content-Length: 763
Lines: 16

On Tue, Mar 18, 2003 at 05:03:03PM +0100, Thiemo Seufer wrote:
> Try
>    -mabi=o32 -march=r5000 -Wa,--trap
> This may fail if the compiler is very old, though.
> 
> > for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
> 
> This was fixed in very recent gcc. -mips2 should be an alias for -march=r6000
> and -mips4 one for -march=r8000.
Is it correct that -mipsX in contrast to -march=rXXXX has the difference
of not only selecting a specific CPU instruction set but also an abi
(o32 or n64)? If so wouldn't it be cleaner to remove -mipsX altogether
and use -march=rXXXX and -mabi=o32, etc? The different meanings of these
options in different toolchain versions confuse me a lot. What is the
final intended usage of these options?
 -- Guido

From ica2_ts@csv.ica.uni-stuttgart.de Tue Mar 18 19:08:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 19:08:44 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:8638
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225203AbTCRTIn>; Tue, 18 Mar 2003 19:08:43 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 18vMS1-001wwg-00; Tue, 18 Mar 2003 20:08:41 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 18vMS1-0004xw-00; Tue, 18 Mar 2003 20:08:41 +0100
Date: Tue, 18 Mar 2003 20:08:41 +0100
To: linux-mips@linux-mips.org
Cc: Guido Guenther <agx@sigxcpu.org>
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030318174241.GG2613@bogon.ms20.nix>
User-Agent: Mutt/1.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: 1767
X-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
Content-Length: 2381
Lines: 71

Guido Guenther wrote:
> On Tue, Mar 18, 2003 at 05:03:03PM +0100, Thiemo Seufer wrote:
> > Try
> >    -mabi=o32 -march=r5000 -Wa,--trap
> > This may fail if the compiler is very old, though.
> > 
> > > for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
> > 
> > This was fixed in very recent gcc. -mips2 should be an alias for -march=r6000
> > and -mips4 one for -march=r8000.
> Is it correct that -mipsX in contrast to -march=rXXXX has the difference
> of not only selecting a specific CPU instruction set but also an abi
> (o32 or n64)?

Only for old compilers, an only for some cases. :-/

-mipsX is the old method for selecting both CPU and ABI, resembling the way
SGI did it for their toolchain. Then there was the need to support different
CPUs, which led to -mcpu/-mXXXX. The result was an inconsistent mess,
especially -mips2 has multiple overloaded semantics.

> If so wouldn't it be cleaner to remove -mipsX altogether
> and use -march=rXXXX and -mabi=o32, etc?

This would be nice, but older compilers don't have -march/-mtune.
IIRC gcc 3.0.X is the first one to employ these. Similiar for -mabi.

> The different meanings of these
> options in different toolchain versions confuse me a lot. What is the
> final intended usage of these options?

For usual userland the ABI defines everything needed. This means

No options at all:
Produce, hosted on a single ABI system, a userland binary with the lowest
possible ISA.

-mabi=FOO: 
Produce, hosted on a multi ABI system, a userland binary with the lowest
possible ISA for the selected ABI.

Then there are optimizations for different CPUs.

-march=BAR:
Allow opcodes for CPU BAR in addition to the ISA ones.

-mtune=BAZ:
Optimize opcode scheduling for CPU BAZ.

Some embedded systems don't care much about ABI compatibility, they
use also

-mgp32/-mfp32:
Restrict register width to 32 bits on 64 bit CPUs.

Then, there are the backward compatibility options.

-mipsX:
Is an alias for -march=QUUX, where QUUX is the CPU closest to the respective
ISA. Note that this is only backward compatible for the assembler, not for
the compiler which implied some o32 features for -mips2.

-mcpu=XXX, -mYYYY:
Old CPU selection code, mostly gone now. Superseded by -march/-mtune.


For my private linux kernels, I use a new CONFIG_MIPS_NEW_TOOLCHAIN in the
Makefile. I don't see a better way around it.


Thiemo

From achim.hensel@ruhr-uni-bochum.de Tue Mar 18 22:48:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 22:48:19 +0000 (GMT)
Received: from mout1.freenet.de ([IPv6:::ffff:194.97.50.132]:35259 "EHLO
	mout1.freenet.de") by linux-mips.org with ESMTP id <S8225203AbTCRWsS>;
	Tue, 18 Mar 2003 22:48:18 +0000
Received: from [194.97.55.148] (helo=mx5.freenet.de)
	by mout1.freenet.de with asmtp (Exim 4.14)
	id 18vPsV-0004F3-HV; Tue, 18 Mar 2003 23:48:15 +0100
Received: from p508f5fbc.dip.t-dialin.net ([80.143.95.188] helo=server.private.priv)
	by mx5.freenet.de with asmtp (ID aspam@freenet.de) (Exim 4.14 #1)
	id 18vPsV-0000Er-9a; Tue, 18 Mar 2003 23:48:15 +0100
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 h2IMmCtc000979;
	Tue, 18 Mar 2003 23:48:13 +0100 (CET)
Date: Tue, 18 Mar 2003 23:48:44 +0100
From: Achim Hensel <achim.hensel@ruhr-uni-bochum.de>
To: port-sgimips@netbsd.org, Linux-MIPS <linux-mips@linux-mips.org>
Subject: Running on R4k/R3k Indigo
Message-Id: <20030318234844.2e465609.achim.hensel@ruhr-uni-bochum.de>
X-Mailer: Sylpheed version 0.8.10 (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: 1768
X-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
Content-Length: 344
Lines: 14

Hello, folks (of both lists)

I recently got both an R4k and an R3k SGI Indigo. 

I know, none of them is supported at the moment.
So, I want to try to change that.

I hadn't started yet, but every help is appreciated.

CU,
	Achim

P.S.: This was posted to both lists, as I don't know, which OS 
has the better starting point for my computers.

From agx@sigxcpu.org Tue Mar 18 23:27:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Mar 2003 23:27:14 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:19668
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225203AbTCRX1N>; Tue, 18 Mar 2003 23:27:13 +0000
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id CBDB62BC30; Wed, 19 Mar 2003 00:27:08 +0100 (CET)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 25323-05;
 Wed, 19 Mar 2003 00:27:08 +0100 (CET)
Received: from bogon.sigxcpu.org (kons-d9bb543c.pool.mediaWays.net [217.187.84.60])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id CD8B22BC2F; Wed, 19 Mar 2003 00:27:07 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 732071735C; Wed, 19 Mar 2003 00:24:54 +0100 (CET)
Date: Wed, 19 Mar 2003 00:24:54 +0100
From: Guido Guenther <agx@sigxcpu.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030318232454.GA19990@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1769
X-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
Content-Length: 896
Lines: 28

Hi Thiemo,
thanks a lot for the explanations!

On Tue, Mar 18, 2003 at 08:08:41PM +0100, Thiemo Seufer wrote:
> This would be nice, but older compilers don't have -march/-mtune.
> IIRC gcc 3.0.X is the first one to employ these. Similiar for -mabi.
I don't care about old compilers at the moment ;)

[..snip..] 
> -mabi=FOO: 
> Produce, hosted on a multi ABI system, a userland binary with the lowest
> possible ISA for the selected ABI.
> 
> Then there are optimizations for different CPUs.
> 
> -march=BAR:
> Allow opcodes for CPU BAR in addition to the ISA ones.
> 
> -mtune=BAZ:
> Optimize opcode scheduling for CPU BAZ.
So to build kernels for say IP22 R5k I'd change the current
	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
to 
	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
where as for R4X00 I use
	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
Correct?
 -- Guido

From ica2_ts@csv.ica.uni-stuttgart.de Wed Mar 19 00:17:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Mar 2003 00:17:02 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:41662
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225203AbTCSARB>; Wed, 19 Mar 2003 00:17:01 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 18vRGG-001yVY-00; Wed, 19 Mar 2003 01:16:52 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 18vRGG-000666-00; Wed, 19 Mar 2003 01:16:52 +0100
Date: Wed, 19 Mar 2003 01:16:52 +0100
To: linux-mips@linux-mips.org
Cc: Guido Guenther <agx@sigxcpu.org>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318232454.GA19990@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030318232454.GA19990@bogon.ms20.nix>
User-Agent: Mutt/1.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: 1770
X-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
Content-Length: 556
Lines: 20

Guido Guenther wrote:
[snip]
> > -march=BAR:
> > Allow opcodes for CPU BAR in addition to the ISA ones.
> > 
> > -mtune=BAZ:
> > Optimize opcode scheduling for CPU BAZ.
> So to build kernels for say IP22 R5k I'd change the current
> 	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
> to 
> 	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
> where as for R4X00 I use
> 	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
> Correct?

Yes, this should work. You can leave the -mtune out, since it defaults
to the value of -march anyway.


Thiemo

From agx@sigxcpu.org Wed Mar 19 01:27:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Mar 2003 01:27:58 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:469
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225203AbTCSB15>; Wed, 19 Mar 2003 01:27:57 +0000
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id F41B42BC30; Wed, 19 Mar 2003 02:27:55 +0100 (CET)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 25766-07;
 Wed, 19 Mar 2003 02:27:55 +0100 (CET)
Received: from bogon.sigxcpu.org (kons-d9bb543c.pool.mediaWays.net [217.187.84.60])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 102602BC2F; Wed, 19 Mar 2003 02:27:55 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 801331735C; Wed, 19 Mar 2003 02:25:40 +0100 (CET)
Date: Wed, 19 Mar 2003 02:25:40 +0100
From: Guido Guenther <agx@sigxcpu.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030319012540.GF19990@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318232454.GA19990@bogon.ms20.nix> <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1771
X-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
Content-Length: 187
Lines: 5

On Wed, Mar 19, 2003 at 01:16:52AM +0100, Thiemo Seufer wrote:
> Yes, this should work. You can leave the -mtune out, since it defaults
> to the value of -march anyway.
Thanks.
 -- Guido

From ashish.anand@inspiretech.com Wed Mar 19 07:19:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Mar 2003 07:19:09 +0000 (GMT)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:51599
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8225073AbTCSHTI>; Wed, 19 Mar 2003 07:19:08 +0000
Received: from mail.inspiretech.com (mail.inspiretech.com [150.1.1.1])
	by smtp.inspirtek.com (8.12.5/8.12.5) with ESMTP id h2J7YeQm029902
	for <linux-mips@linux-mips.org>; Wed, 19 Mar 2003 13:04:43 +0530
Message-Id: <200303190734.h2J7YeQm029902@smtp.inspirtek.com>
Received: from WorldClient [150.1.1.1] by inspiretech.com [150.1.1.1]
	with SMTP (MDaemon.v3.5.7.R)
	for <linux-mips@linux-mips.org>; Wed, 19 Mar 2003 12:41:52 +0530
Date: Wed, 19 Mar 2003 12:41:50 +0530
From: "Ashish anand" <ashish.anand@inspiretech.com>
To: linux-mips@linux-mips.org
Subject: PCI status error 0x2a80..
X-Mailer: WorldClient Standard 3.5.0e
X-MDRemoteIP: 150.1.1.1
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: 1772
X-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
Content-Length: 807
Lines: 26

Hello,
I am experiencing the PCI bus error for a network card(Realtek 8139)
operation.
whenever it tries to transmit packets it prints the error like

eth0: PCI Bus error 0x2a80.

PCI status 0x2a80 as per pci specs suggests pci master and target
abort.
other basic infrastructures like  interupts , pci-dma and cards pci
resources are well in place.also i am able to receive all packets.
I have ensured other pci config registers like Latency timer and
command register are initialised to appropiate values.
pci command has been set to 0x7  ( io + mem + busmaster).

1.what can be other reasons for this to happen ..?

2.if pci master and target abort happens how the card is able to recive
the packets..?

3.does this situation demand pci debugging or driver level debugging?

Best Regards,
Ashish Anand



From jbglaw@dvmwest.gt.owl.de Wed Mar 19 07:19:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Mar 2003 07:19:29 +0000 (GMT)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:59914 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225218AbTCSHTV>; Wed, 19 Mar 2003 07:19:21 +0000
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id E56824AA49; Wed, 19 Mar 2003 08:19:19 +0100 (CET)
Date: Wed, 19 Mar 2003 08:19:19 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Achim Hensel <achim.hensel@ruhr-uni-bochum.de>
Cc: port-sgimips@netbsd.org, Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: Running on R4k/R3k Indigo
Message-ID: <20030319071919.GY28454@lug-owl.de>
Mail-Followup-To: Achim Hensel <achim.hensel@ruhr-uni-bochum.de>,
	port-sgimips@netbsd.org, Linux-MIPS <linux-mips@linux-mips.org>
References: <20030318234844.2e465609.achim.hensel@ruhr-uni-bochum.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="g3IWFuR7/O9KKcN6"
Content-Disposition: inline
In-Reply-To: <20030318234844.2e465609.achim.hensel@ruhr-uni-bochum.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: 1773
X-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
Content-Length: 1317
Lines: 45


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

On Tue, 2003-03-18 23:48:44 +0100, Achim Hensel <achim.hensel@ruhr-uni-boch=
um.de>
wrote in message <20030318234844.2e465609.achim.hensel@ruhr-uni-bochum.de>:
> Hello, folks (of both lists)
>=20
> I recently got both an R4k and an R3k SGI Indigo.=20

There are some of them flyin' around.

> I know, none of them is supported at the moment.
> So, I want to try to change that.

Well... I've started to look at some assembler dumps of the Irix kernel.
This is a lenghty approach, though. That's more than 30MB of text:(

Even with that, there are some issues...

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));

--g3IWFuR7/O9KKcN6
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+eBn3Hb1edYOZ4bsRAjFpAKCDv16ZlIwIJTmuELGX+0ZBIywS/wCfR+9U
036gAQIqyF+VXrmnSw0FsAU=
=3G/D
-----END PGP SIGNATURE-----

--g3IWFuR7/O9KKcN6--

From lindahl@keyresearch.com Wed Mar 19 08:01:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Mar 2003 08:01:07 +0000 (GMT)
Received: from 12-234-18-241.client.attbi.com ([IPv6:::ffff:12.234.18.241]:46981
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225218AbTCSIBG>; Wed, 19 Mar 2003 08:01:06 +0000
Received: from localhost.localdomain (localhost [127.0.0.1])
	by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h2J813Bg001663
	for <linux-mips@linux-mips.org>; Wed, 19 Mar 2003 00:01:03 -0800
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id h2J812Hm001661
	for linux-mips@linux-mips.org; Wed, 19 Mar 2003 00:01:02 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Wed, 19 Mar 2003 00:01:02 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: PCI status error 0x2a80..
Message-ID: <20030319080102.GA1530@greglaptop.attbi.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <200303190734.h2J7YeQm029902@smtp.inspirtek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200303190734.h2J7YeQm029902@smtp.inspirtek.com>
User-Agent: Mutt/1.4i
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: 1774
X-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
Content-Length: 272
Lines: 10

On Wed, Mar 19, 2003 at 12:41:50PM +0530, Ashish anand wrote:

> I am experiencing the PCI bus error for a network card(Realtek 8139)
> operation.

This is the card that locks up when you try to drive it with maximum
traffic under both Linux and Windows, right?

-- greg


From debashis@alumnux.com Wed Mar 19 08:20:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Mar 2003 08:20:59 +0000 (GMT)
Received: from [IPv6:::ffff:203.197.124.190] ([IPv6:::ffff:203.197.124.190]:5134
	"EHLO alumnux.com") by linux-mips.org with ESMTP
	id <S8225218AbTCSIU6>; Wed, 19 Mar 2003 08:20:58 +0000
Received: from alumnux.com (mamata.alumnus.co.in [192.168.10.121])
	by alumnux.com (8.9.3/8.9.3) with ESMTP id TAA10147
	for <linux-mips@linux-mips.org>; Wed, 19 Mar 2003 19:28:50 +0530
Message-ID: <3E78284D.9BE358B2@alumnux.com>
Date: Wed, 19 Mar 2003 13:50:29 +0530
From: debashis <debashis@alumnux.com>
Organization: Alumnus Software Ltd
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: compressed image for mips:malta
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <debashis@alumnux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1775
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: debashis@alumnux.com
Precedence: bulk
X-list: linux-mips
Content-Length: 593
Lines: 21

Hi,
I am working with a mips malta 4KC box. It supports vmlinux. The linux
kernel version that I am using is 2.4.18

However the size of the vmlinux image looks high (more than 1M).  I am
trying to get a smaller image (with neworking). Need some help :

Is their any compressed image is supported for this particular board?

Does the loader need some change to support compressed image?

In case I need to provide support for the compressed image, is there any
similar board on which the compressed image support is present?

Any suggession is welcome.

Thanks in advance.

Regards,
debashis


From sjhill@realitydiluted.com Wed Mar 19 19:42:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Mar 2003 19:42:13 +0000 (GMT)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:52164
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225221AbTCSTmM>; Wed, 19 Mar 2003 19:42:12 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 18vjRy-0005bH-00; Wed, 19 Mar 2003 13:42:10 -0600
Message-ID: <3E78C814.6000607@realitydiluted.com>
Date: Wed, 19 Mar 2003 14:42:12 -0500
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10
X-Accept-Language: en
MIME-Version: 1.0
To: port-sgimips@netbsd.org, linux-mips@linux-mips.org
Subject: Mirrored pages of old 'reality.sgi.com' webserver...
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: 1776
X-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
Content-Length: 559
Lines: 14

Greetings.

I had done a massive mirror of webpages from the old 'reality.sgi.com'
server about a year ago before it disappeared. I mirrored all of the
people's pages that had real content. I just finished uploading it to
my server a few days ago and thought I would share it with people so
that some good content did not die. Please note, if SGI or the owners
of the content contact me and ask me to remove some or all of the
content, I will immediately comply. Until then, enjoy. Cheers.

    http://www.realitydiluted.com/mirrors/reality.sgi.com/

-Steve


From ralf@linux-mips.net Wed Mar 19 19:56:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Mar 2003 19:56:46 +0000 (GMT)
Received: from p508B543E.dip.t-dialin.net ([IPv6:::ffff:80.139.84.62]:8086
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225221AbTCST4q>; Wed, 19 Mar 2003 19:56:46 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2JJufT30732;
	Wed, 19 Mar 2003 20:56:41 +0100
Date: Wed, 19 Mar 2003 20:56:41 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Ashish anand <ashish.anand@inspiretech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: PCI status error 0x2a80..
Message-ID: <20030319205641.B23957@linux-mips.org>
References: <200303190734.h2J7YeQm029902@smtp.inspirtek.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: <200303190734.h2J7YeQm029902@smtp.inspirtek.com>; from ashish.anand@inspiretech.com on Wed, Mar 19, 2003 at 12:41:50PM +0530
Return-Path: <ralf@linux-mips.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: 1777
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 398
Lines: 11

On Wed, Mar 19, 2003 at 12:41:50PM +0530, Ashish anand wrote:

> I am experiencing the PCI bus error for a network card(Realtek 8139)
> operation.

The 8139 has been driving driver writers crazy over the years.  Too many
too bugy variants.  I remember a guy who had a car number plate with
RTL 8139 printed on it on his wall because he managed to improve the
situation by a few percent ...

  Ralf

From listbox@evernex.com Thu Mar 20 01:25:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Mar 2003 01:25:48 +0000 (GMT)
Received: from mta10-0.mail.adelphia.net ([IPv6:::ffff:64.8.50.202]:24253 "EHLO
	mta10.adelphia.net") by linux-mips.org with ESMTP
	id <S8225221AbTCTBZr>; Thu, 20 Mar 2003 01:25:47 +0000
Received: from there ([24.51.54.5]) by mta3.adelphia.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP
          id <20030319222337.LNDN8997.mta3.adelphia.net@there>
          for <linux-mips@linux-mips.org>; Wed, 19 Mar 2003 17:23:37 -0500
Content-Type: text/plain;
  charset="iso-8859-1"
From: Neurophyre <listbox@evernex.com>
To: linux-mips@linux-mips.org
Subject: Re: 2.4.20 SCSI problems on NASRaQ
Date: Wed, 19 Mar 2003 17:23:29 -0500
X-Mailer: KMail [version 1.3.2]
References: <20030318172414.MLZJ7686.mta6.adelphia.net@there>
In-Reply-To: <20030318172414.MLZJ7686.mta6.adelphia.net@there>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20030319222337.LNDN8997.mta3.adelphia.net@there>
Return-Path: <listbox@evernex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1778
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: listbox@evernex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2863
Lines: 65

A little update on the problems with none of the 3 drivers initializing 
the 53c860 SCSI controller on the Seagate (Cobalt) NASRaQ:

I've built the 2.5.47 CVS snapshot kernel from linux-mips.org, but even 
with just about everything modularized, the kernel is just over 100K 
too big for the NASRaQ's boot loader.  So, it would seem without 
getting very creative that 2.4.x is the end of the road for this 
hardware.. this means I can't test to see if any of the drivers now 
work in the linux-mips source tree.

I also thought it might be good to include /proc/pci, since someone 
off-list mentioned to me that perhaps some other device is reserving 
the controller's address space (?)..  again, here's what the message 
from all three drivers looks like (using the newest one as an example):

sym.0.8.0: IO region 0x10102000[0..127] is in use

here is /proc/pci.  The SCSI controller is device 8.

PCI devices found:
  Bus  0, device   0, function  0:
    Class 0580: PCI device 11ab:4146 (rev 17).
      Master Capable.  Latency=64.
      Non-prefetchable 32 bit memory at 0x0 [0x3ffffff].
      Non-prefetchable 32 bit memory at 0x4000000 [0x4000fff].
      Non-prefetchable 32 bit memory at 0x1c000000 [0x1dffffff].
      Non-prefetchable 32 bit memory at 0x1f000000 [0x1fffffff].
      Non-prefetchable 32 bit memory at 0x14000000 [0x14000fff].
      I/O at 0x14000000 [0x14000fff].
  Bus  0, device   7, function  0:
    Class 0200: PCI device 1011:0019 (rev 65).
      IRQ 4.
      Master Capable.  Latency=64.  Min Gnt=20.Max Lat=40.
      I/O at 0x100000 [0x10007f].
      Non-prefetchable 32 bit memory at 0x12000000 [0x120003ff].
  Bus  0, device   8, function  0:
    Class 0100: PCI device 1000:0006 (rev 2).
      IRQ 4.
      Master Capable.  No bursts.  Min Gnt=8.Max Lat=64.
      I/O at 0x10102000 [0x101020ff].
      Non-prefetchable 32 bit memory at 0x2000 [0x20ff].
  Bus  0, device   9, function  0:
    Class 0601: PCI device 1106:0586 (rev 39).
  Bus  0, device   9, function  1:
    Class 0101: PCI device 1106:0571 (rev 6).
      Master Capable.  Latency=64.
      I/O at 0xcc00 [0xcc0f].
  Bus  0, device   9, function  2:
    Class 0c03: PCI device 1106:3038 (rev 2).
      Master Capable.  Latency=22.
      I/O at 0x300 [0x31f].


If anybody has any suggestions of what I might be able to do to get the 
SCSI controller working, I'd love to hear it.  Also if there are any 
other things you would like to see besides what I've shown.  I'm not a 
kernel hacker.  :-(

As it stands now, anybody with a MIPS-based NASRaQ is out in the cold 
when it comes to upgrading their system.

Finally, since the SCSI controller obviously worked with Cobalt's 
(patched) 2.0 kernel, maybe an older kernel might work?  Does anybody 
have any snapshots of the 2.2.x source tree with MIPS patches applied?  
Or access to Cobalt's old patches even?

From ralf@linux-mips.net Thu Mar 20 10:16:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Mar 2003 10:16:28 +0000 (GMT)
Received: from p508B6F73.dip.t-dialin.net ([IPv6:::ffff:80.139.111.115]:10404
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225073AbTCTKQ1>; Thu, 20 Mar 2003 10:16:27 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2KAGPa14049
	for linux-mips@linux-mips.org; Thu, 20 Mar 2003 11:16:25 +0100
Date: Thu, 20 Mar 2003 11:16:25 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Cache code changes
Message-ID: <20030320111625.A13219@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
Return-Path: <ralf@linux-mips.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: 1779
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 3138
Lines: 62

Thought I should drop a note about the recent cache code changes in the
Linux 2.4 and 2.5 code in CVS to explain what's going on.

flush_page_to_ram() has long been a deprecated interface and been scheduled
to be removed for years.  It's considered a inefficient, badly designed
interface.  It's use it for dealing with virtual aliases in the primary
cache.  That is whenever the memory managment code creates or modifies
a page that is mapped to userspace it has to writeback and invalidate the
kernel mapping of this page to avoid virtual aliases.

flush_page_to_ram() turned out to be a rather ad-hoc interface; the
obvious but inefficient interface approach.  It's also not capable of
fully dealing with all types of cache aliases like aliases between the
page cache and user mappings.  Which may lead to silent data corruption
and that's the reason why I'm doing such intrusive kernel surgery for a
supposedly stable kernel.  So there now is an alternative interface
available in the kernel, flush_dcache_page().  flush_dcache_page() is
implements a two stage approach.  It marks pages which are in the page
cache and therefore could possibly alias with userspace as possibly
residing in cache if it doesn't flush them immediately.  This allows
delaying cache flushes - possibly infinitely.  Which quite obviously is
a performance gain.

Side effect - some implementations of flush_icache_page() knew that it's
invocations are always preceeded by flush_page_to_ram() so the D-cache
flush can be omitted.  This is no longer there case.  Another bug fixed
along the way (but not yet for all processors) was flush_cache_page() not
flushing the instruction cache ...

Along with that I've also cleaned the cache code for R4000 and R4400 CPUs.
Continuing the mess seemed to be plain unmaintainable and at the same
time huge.  The heavily changed code (for your amusement now using a few
new code constructs :-) is now over 40% smaller meassure in LOCs and about
2/3 smaller in code size and should make it fairly easy to add support for
strange beasts such as TX39, TX49 or R5432 style caches caches.

Why is it still not working?  Well, below a kludge that will get the
latest 2.4 code to work again for all processors that are suffering from
cache aliases.  It's an inefficient solution but good enough for now.

  Ralf

Index: include/asm-mips/page.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/page.h,v
retrieving revision 1.14.2.11
diff -u -r1.14.2.11 page.h
--- include/asm-mips/page.h	20 Dec 2002 02:34:17 -0000	1.14.2.11
+++ include/asm-mips/page.h	19 Mar 2003 13:21:32 -0000
@@ -64,8 +64,10 @@
 
 #define clear_page(page)	_clear_page(page)
 #define copy_page(to, from)	_copy_page(to, from)
-#define clear_user_page(page, vaddr)	clear_page(page)
-#define copy_user_page(to, from, vaddr)	copy_page(to, from)
+#define clear_user_page(page, vaddr) \
+	do { clear_page(page); flush_cache_all(); } while (0)
+#define copy_user_page(to, from, vaddr)	\
+	do { copy_page(to, from); flush_cache_all(); } while (0)
 
 /*
  * These are used to make use of C type-checking..

From fxzhang@ict.ac.cn Thu Mar 20 11:08:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Mar 2003 11:08:55 +0000 (GMT)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:32952
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225073AbTCTLIq>; Thu, 20 Mar 2003 11:08:46 +0000
Received: (qmail 28210 invoked from network); 20 Mar 2003 10:51:43 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 20 Mar 2003 10:51:43 -0000
Message-ID: <3E79A121.6000409@ict.ac.cn>
Date: Thu, 20 Mar 2003 19:08:17 +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: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Subject: Re: Cache code changes
References: <20030320111625.A13219@linux-mips.org>
In-Reply-To: <20030320111625.A13219@linux-mips.org>
Content-Type: text/plain; charset=ISO-8859-1; 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: 1780
X-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
Content-Length: 3914
Lines: 89

I am very glad to see this happens:)

Currently linux/mips is really far from efficient,I've some data for 
this declaration:
   For most SPEC CPU 2000 programs we run on a 4-way superscalar CPU 
simulator
,we get <0.20 IPC in kernel mode,while the IPCs for the whole execution 
are often much
higher(0.5-1.5). We believe this has something to do with the overly 
used cache flushes.

BTW, for 2.4.17,it seems this path is still not safe for cache aliases:
    copy_cow_page for newly forked process, we use kernel virtual address
to do the copy,but without flush first.
add a flush_page_to_ram before the copy fix the errors.

but i am not sure whether i am missing something
 

Ralf Baechle wrote:

>Thought I should drop a note about the recent cache code changes in the
>Linux 2.4 and 2.5 code in CVS to explain what's going on.
>
>flush_page_to_ram() has long been a deprecated interface and been scheduled
>to be removed for years.  It's considered a inefficient, badly designed
>interface.  It's use it for dealing with virtual aliases in the primary
>cache.  That is whenever the memory managment code creates or modifies
>a page that is mapped to userspace it has to writeback and invalidate the
>kernel mapping of this page to avoid virtual aliases.
>
>flush_page_to_ram() turned out to be a rather ad-hoc interface; the
>obvious but inefficient interface approach.  It's also not capable of
>fully dealing with all types of cache aliases like aliases between the
>page cache and user mappings.  Which may lead to silent data corruption
>and that's the reason why I'm doing such intrusive kernel surgery for a
>supposedly stable kernel.  So there now is an alternative interface
>available in the kernel, flush_dcache_page().  flush_dcache_page() is
>implements a two stage approach.  It marks pages which are in the page
>cache and therefore could possibly alias with userspace as possibly
>residing in cache if it doesn't flush them immediately.  This allows
>delaying cache flushes - possibly infinitely.  Which quite obviously is
>a performance gain.
>
>Side effect - some implementations of flush_icache_page() knew that it's
>invocations are always preceeded by flush_page_to_ram() so the D-cache
>flush can be omitted.  This is no longer there case.  Another bug fixed
>along the way (but not yet for all processors) was flush_cache_page() not
>flushing the instruction cache ...
>
>Along with that I've also cleaned the cache code for R4000 and R4400 CPUs.
>Continuing the mess seemed to be plain unmaintainable and at the same
>time huge.  The heavily changed code (for your amusement now using a few
>new code constructs :-) is now over 40% smaller meassure in LOCs and about
>2/3 smaller in code size and should make it fairly easy to add support for
>strange beasts such as TX39, TX49 or R5432 style caches caches.
>
>Why is it still not working?  Well, below a kludge that will get the
>latest 2.4 code to work again for all processors that are suffering from
>cache aliases.  It's an inefficient solution but good enough for now.
>
>  Ralf
>
>Index: include/asm-mips/page.h
>===================================================================
>RCS file: /home/cvs/linux/include/asm-mips/page.h,v
>retrieving revision 1.14.2.11
>diff -u -r1.14.2.11 page.h
>--- include/asm-mips/page.h	20 Dec 2002 02:34:17 -0000	1.14.2.11
>+++ include/asm-mips/page.h	19 Mar 2003 13:21:32 -0000
>@@ -64,8 +64,10 @@
> 
> #define clear_page(page)	_clear_page(page)
> #define copy_page(to, from)	_copy_page(to, from)
>-#define clear_user_page(page, vaddr)	clear_page(page)
>-#define copy_user_page(to, from, vaddr)	copy_page(to, from)
>+#define clear_user_page(page, vaddr) \
>+	do { clear_page(page); flush_cache_all(); } while (0)
>+#define copy_user_page(to, from, vaddr)	\
>+	do { copy_page(to, from); flush_cache_all(); } while (0)
> 
> /*
>  * These are used to make use of C type-checking..
>
>
>
>  
>


From ralf@linux-mips.net Thu Mar 20 12:05:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Mar 2003 12:05:39 +0000 (GMT)
Received: from p508B6F73.dip.t-dialin.net ([IPv6:::ffff:80.139.111.115]:54949
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225073AbTCTMFi>; Thu, 20 Mar 2003 12:05:38 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2KC5TL16122;
	Thu, 20 Mar 2003 13:05:29 +0100
Date: Thu, 20 Mar 2003 13:05:29 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: linux-mips@linux-mips.org
Subject: Re: Cache code changes
Message-ID: <20030320130528.A15475@linux-mips.org>
References: <20030320111625.A13219@linux-mips.org> <3E79A121.6000409@ict.ac.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E79A121.6000409@ict.ac.cn>; from fxzhang@ict.ac.cn on Thu, Mar 20, 2003 at 07:08:17PM +0800
Return-Path: <ralf@linux-mips.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: 1781
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1200
Lines: 32

On Thu, Mar 20, 2003 at 07:08:17PM +0800, Fuxin Zhang wrote:

> I am very glad to see this happens:)


> Currently linux/mips is really far from efficient,I've some data for 
> this declaration:
>    For most SPEC CPU 2000 programs we run on a 4-way superscalar CPU 
> simulator
> ,we get <0.20 IPC in kernel mode,while the IPCs for the whole execution 
> are often much
> higher(0.5-1.5). We believe this has something to do with the overly 
> used cache flushes.

What type of cache are you using in this simulation?  Virtual/physical
indexing/tagging, what associativity?

Linux/MIPS's handling of virtually indexed data caches isn't as good as
it should be but that's what I'm working on.

> BTW, for 2.4.17,it seems this path is still not safe for cache aliases:
>     copy_cow_page for newly forked process, we use kernel virtual address
> to do the copy,but without flush first.
> add a flush_page_to_ram before the copy fix the errors.
> 
> but i am not sure whether i am missing something

The functions clear_user_page and copy_user_page are supposed to take care
of aliases in this case.  That's what the little patch did in my previous
mail did, just in a rather inefficient way.

  Ralf

From hartvig@ekner.info Fri Mar 21 08:50:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Mar 2003 08:50:06 +0000 (GMT)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:1292 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225194AbTCUIuD>;
	Fri, 21 Mar 2003 08:50:03 +0000
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id 39AEBB5A1
	for <linux-mips@linux-mips.org>; Fri, 21 Mar 2003 09:49:55 +0100 (CET)
Message-ID: <3E7AD36E.26E2EA94@ekner.info>
Date: Fri, 21 Mar 2003 09:55:10 +0100
From: Hartvig Ekner <hartvig@ekner.info>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Patches for all four au1000 setup.c files
Content-Type: multipart/mixed;
 boundary="------------B90FDD20FDEC016885A15C78"
Return-Path: <hartvig@ekner.info>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1782
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvig@ekner.info
Precedence: bulk
X-list: linux-mips
Content-Length: 5002
Lines: 186

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

Hi,

the patches below for all four au1000 setup.c files removes the wbflush() routine, as this is no longer necessary
(handled by the generic code now, which does a sync). This also means that it is not necessary to say yes to
CONFIG_CPU_ADVANCED and override the CPU_HAS_WB setting, as the generic MIPS32 code will do just fine.

The patch for the db1x00 setup.c file also fixes a bug which prevented VRA from being used with Audio Codecs
which support it.

/Hartvig



--------------B90FDD20FDEC016885A15C78
Content-Type: text/plain; charset=us-ascii;
 name="setup.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="setup.patch"

Index: db1x00/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 setup.c
--- db1x00/setup.c	7 Jan 2003 10:41:30 -0000	1.1.2.3
+++ db1x00/setup.c	21 Mar 2003 08:44:49 -0000
@@ -61,7 +61,6 @@
 extern struct ide_ops *ide_ops;
 #endif
 
-void (*__wbflush) (void);
 extern struct rtc_ops no_rtc_ops;
 extern char * __init prom_getcmdline(void);
 extern void au1000_restart(char *);
@@ -76,11 +75,6 @@
 
 void __init bus_error_init(void) { /* nothing */ }
 
-void au1x00_wbflush(void)
-{
-	__asm__ volatile ("sync");
-}
-
 void __init au1x00_setup(void)
 {
 	char *argptr;
@@ -109,14 +103,13 @@
     }
 #endif
 
-#if defined(CONFIG_SOUND_AU1000) && !defined(CONFIG_CPU_AU1000)
+#if defined(CONFIG_SOUND_AU1X00) && !defined(CONFIG_CPU_AU1000)
 	// au1000 does not support vra, au1500 and au1100 do
-    strcat(argptr, " au1000_audio=vra");
-    argptr = prom_getcmdline();
+	strcat(argptr, " au1000_audio=vra");
+	argptr = prom_getcmdline();
 #endif
 
 	rtc_ops = &no_rtc_ops;
-	__wbflush = au1x00_wbflush;
 	_machine_restart = au1000_restart;
 	_machine_halt = au1000_halt;
 	_machine_power_off = au1000_power_off;
Index: pb1000/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/pb1000/setup.c,v
retrieving revision 1.8.2.8
diff -u -r1.8.2.8 setup.c
--- pb1000/setup.c	11 Dec 2002 06:12:29 -0000	1.8.2.8
+++ pb1000/setup.c	21 Mar 2003 08:44:50 -0000
@@ -67,7 +67,6 @@
 extern struct ide_ops *ide_ops;
 #endif
 
-void (*__wbflush) (void);
 extern struct rtc_ops no_rtc_ops;
 extern char * __init prom_getcmdline(void);
 extern void au1000_restart(char *);
@@ -78,11 +77,6 @@
 
 void __init bus_error_init(void) { /* nothing */ }
 
-void au1000_wbflush(void)
-{
-	__asm__ volatile ("sync");
-}
-
 void __init au1x00_setup(void)
 {
 	char *argptr;
@@ -103,7 +97,6 @@
 #endif
 
 	rtc_ops = &no_rtc_ops;
-        __wbflush = au1000_wbflush;
 	_machine_restart = au1000_restart;
 	_machine_halt = au1000_halt;
 	_machine_power_off = au1000_power_off;
Index: pb1100/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/pb1100/setup.c,v
retrieving revision 1.1.2.6
diff -u -r1.1.2.6 setup.c
--- pb1100/setup.c	31 Dec 2002 05:00:22 -0000	1.1.2.6
+++ pb1100/setup.c	21 Mar 2003 08:44:50 -0000
@@ -71,7 +71,6 @@
 extern struct rtc_ops pb1500_rtc_ops;
 #endif
 
-void (*__wbflush) (void);
 extern char * __init prom_getcmdline(void);
 extern void au1000_restart(char *);
 extern void au1000_halt(void);
@@ -82,11 +81,6 @@
 
 void __init bus_error_init(void) { /* nothing */ }
 
-void au1100_wbflush(void)
-{
-	__asm__ volatile ("sync");
-}
-
 void __init au1x00_setup(void)
 {
 	char *argptr;
@@ -112,7 +106,6 @@
 	argptr = prom_getcmdline();
 #endif
 
-        __wbflush = au1100_wbflush;
 	_machine_restart = au1000_restart;
 	_machine_halt = au1000_halt;
 	_machine_power_off = au1000_power_off;
Index: pb1500/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
retrieving revision 1.1.2.10
diff -u -r1.1.2.10 setup.c
--- pb1500/setup.c	29 Dec 2002 10:30:35 -0000	1.1.2.10
+++ pb1500/setup.c	21 Mar 2003 08:44:50 -0000
@@ -43,7 +43,6 @@
 #include <asm/mipsregs.h>
 #include <asm/reboot.h>
 #include <asm/pgtable.h>
-#include <asm/wbflush.h>
 #include <asm/au1000.h>
 #include <asm/pb1500.h>
 
@@ -72,7 +71,6 @@
 extern struct rtc_ops pb1500_rtc_ops;
 #endif
 
-void (*__wbflush) (void);
 extern char * __init prom_getcmdline(void);
 extern void au1000_restart(char *);
 extern void au1000_halt(void);
@@ -87,11 +85,6 @@
 
 void __init bus_error_init(void) { /* nothing */ }
 
-void au1500_wbflush(void)
-{
-	__asm__ volatile ("sync");
-}
-
 void __init au1x00_setup(void)
 {
 	char *argptr;
@@ -117,7 +110,6 @@
 	argptr = prom_getcmdline();
 #endif
 
-        __wbflush = au1500_wbflush;
 	_machine_restart = au1000_restart;
 	_machine_halt = au1000_halt;
 	_machine_power_off = au1000_power_off;

--------------B90FDD20FDEC016885A15C78--


From dom@mips.com Fri Mar 21 11:54:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Mar 2003 11:54:22 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:17929 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225194AbTCULyT>;
	Fri, 21 Mar 2003 11:54:19 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 18wLCD-0003y6-00; Fri, 21 Mar 2003 12:00:25 +0000
Received: from gladsmuir.algor.co.uk ([172.20.192.66])
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 18wL5u-0002jX-00; Fri, 21 Mar 2003 11:53:55 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15994.64849.704568.803119@gladsmuir.algor.co.uk>
Date: Fri, 21 Mar 2003 11:53:53 +0000
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Cache code changes
In-Reply-To: <20030320111625.A13219@linux-mips.org>
References: <20030320111625.A13219@linux-mips.org>
X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-0.9, required 4.5, AWL,
	IN_REP_TO, REFERENCES, SPAM_PHRASE_00_01)
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: 1783
X-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
Content-Length: 144
Lines: 11


Ralf,

> flush_page_to_ram()...

Can you remind me where I can find the specification of what these
functions are supposed to do?

--
Dominic


From quintela@mandrakesoft.com Fri Mar 21 14:48:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Mar 2003 14:48:58 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:20839 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225194AbTCUOs4>;
	Fri, 21 Mar 2003 14:48:56 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 2695C720; Fri, 21 Mar 2003 15:48:53 +0100 (CET)
To: Dominic Sweetman <dom@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: Cache code changes
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <15994.64849.704568.803119@gladsmuir.algor.co.uk> (Dominic
 Sweetman's message of "Fri, 21 Mar 2003 11:53:53 +0000")
References: <20030320111625.A13219@linux-mips.org>
	<15994.64849.704568.803119@gladsmuir.algor.co.uk>
Date: Fri, 21 Mar 2003 15:48:52 +0100
Message-ID: <86k7esvkq3.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1784
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 389
Lines: 18

>>>>> "dominic" == Dominic Sweetman <dom@mips.com> writes:

dominic> Ralf,

>> flush_page_to_ram()...

dominic> Can you remind me where I can find the specification of what these
dominic> functions are supposed to do?

In the linux source:

linux/Documentation/cachetlb.txt

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From ppopov@mvista.com Fri Mar 21 15:59:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Mar 2003 15:59:28 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:53496 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225194AbTCUP71>;
	Fri, 21 Mar 2003 15:59:27 +0000
Received: from localhost (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id HAA22104;
	Fri, 21 Mar 2003 07:58:17 -0800
Subject: Re: Patches for all four au1000 setup.c files
From: Pete Popov <ppopov@mvista.com>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <3E7AD36E.26E2EA94@ekner.info>
References: <3E7AD36E.26E2EA94@ekner.info>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1048262309.11983.0.camel@adsl.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 21 Mar 2003 07:58:29 -0800
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: 1785
X-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
Content-Length: 5118
Lines: 179

Thanks, I'll take care of them.

Pete

On Fri, 2003-03-21 at 00:55, Hartvig Ekner wrote:
> Hi,
> 
> the patches below for all four au1000 setup.c files removes the wbflush() routine, as this is no longer necessary
> (handled by the generic code now, which does a sync). This also means that it is not necessary to say yes to
> CONFIG_CPU_ADVANCED and override the CPU_HAS_WB setting, as the generic MIPS32 code will do just fine.
> 
> The patch for the db1x00 setup.c file also fixes a bug which prevented VRA from being used with Audio Codecs
> which support it.
> 
> /Hartvig
> 
> 
> 
> ______________________________________________________________________
> 
> Index: db1x00/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> retrieving revision 1.1.2.3
> diff -u -r1.1.2.3 setup.c
> --- db1x00/setup.c	7 Jan 2003 10:41:30 -0000	1.1.2.3
> +++ db1x00/setup.c	21 Mar 2003 08:44:49 -0000
> @@ -61,7 +61,6 @@
>  extern struct ide_ops *ide_ops;
>  #endif
>  
> -void (*__wbflush) (void);
>  extern struct rtc_ops no_rtc_ops;
>  extern char * __init prom_getcmdline(void);
>  extern void au1000_restart(char *);
> @@ -76,11 +75,6 @@
>  
>  void __init bus_error_init(void) { /* nothing */ }
>  
> -void au1x00_wbflush(void)
> -{
> -	__asm__ volatile ("sync");
> -}
> -
>  void __init au1x00_setup(void)
>  {
>  	char *argptr;
> @@ -109,14 +103,13 @@
>      }
>  #endif
>  
> -#if defined(CONFIG_SOUND_AU1000) && !defined(CONFIG_CPU_AU1000)
> +#if defined(CONFIG_SOUND_AU1X00) && !defined(CONFIG_CPU_AU1000)
>  	// au1000 does not support vra, au1500 and au1100 do
> -    strcat(argptr, " au1000_audio=vra");
> -    argptr = prom_getcmdline();
> +	strcat(argptr, " au1000_audio=vra");
> +	argptr = prom_getcmdline();
>  #endif
>  
>  	rtc_ops = &no_rtc_ops;
> -	__wbflush = au1x00_wbflush;
>  	_machine_restart = au1000_restart;
>  	_machine_halt = au1000_halt;
>  	_machine_power_off = au1000_power_off;
> Index: pb1000/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1000/setup.c,v
> retrieving revision 1.8.2.8
> diff -u -r1.8.2.8 setup.c
> --- pb1000/setup.c	11 Dec 2002 06:12:29 -0000	1.8.2.8
> +++ pb1000/setup.c	21 Mar 2003 08:44:50 -0000
> @@ -67,7 +67,6 @@
>  extern struct ide_ops *ide_ops;
>  #endif
>  
> -void (*__wbflush) (void);
>  extern struct rtc_ops no_rtc_ops;
>  extern char * __init prom_getcmdline(void);
>  extern void au1000_restart(char *);
> @@ -78,11 +77,6 @@
>  
>  void __init bus_error_init(void) { /* nothing */ }
>  
> -void au1000_wbflush(void)
> -{
> -	__asm__ volatile ("sync");
> -}
> -
>  void __init au1x00_setup(void)
>  {
>  	char *argptr;
> @@ -103,7 +97,6 @@
>  #endif
>  
>  	rtc_ops = &no_rtc_ops;
> -        __wbflush = au1000_wbflush;
>  	_machine_restart = au1000_restart;
>  	_machine_halt = au1000_halt;
>  	_machine_power_off = au1000_power_off;
> Index: pb1100/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1100/setup.c,v
> retrieving revision 1.1.2.6
> diff -u -r1.1.2.6 setup.c
> --- pb1100/setup.c	31 Dec 2002 05:00:22 -0000	1.1.2.6
> +++ pb1100/setup.c	21 Mar 2003 08:44:50 -0000
> @@ -71,7 +71,6 @@
>  extern struct rtc_ops pb1500_rtc_ops;
>  #endif
>  
> -void (*__wbflush) (void);
>  extern char * __init prom_getcmdline(void);
>  extern void au1000_restart(char *);
>  extern void au1000_halt(void);
> @@ -82,11 +81,6 @@
>  
>  void __init bus_error_init(void) { /* nothing */ }
>  
> -void au1100_wbflush(void)
> -{
> -	__asm__ volatile ("sync");
> -}
> -
>  void __init au1x00_setup(void)
>  {
>  	char *argptr;
> @@ -112,7 +106,6 @@
>  	argptr = prom_getcmdline();
>  #endif
>  
> -        __wbflush = au1100_wbflush;
>  	_machine_restart = au1000_restart;
>  	_machine_halt = au1000_halt;
>  	_machine_power_off = au1000_power_off;
> Index: pb1500/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
> retrieving revision 1.1.2.10
> diff -u -r1.1.2.10 setup.c
> --- pb1500/setup.c	29 Dec 2002 10:30:35 -0000	1.1.2.10
> +++ pb1500/setup.c	21 Mar 2003 08:44:50 -0000
> @@ -43,7 +43,6 @@
>  #include <asm/mipsregs.h>
>  #include <asm/reboot.h>
>  #include <asm/pgtable.h>
> -#include <asm/wbflush.h>
>  #include <asm/au1000.h>
>  #include <asm/pb1500.h>
>  
> @@ -72,7 +71,6 @@
>  extern struct rtc_ops pb1500_rtc_ops;
>  #endif
>  
> -void (*__wbflush) (void);
>  extern char * __init prom_getcmdline(void);
>  extern void au1000_restart(char *);
>  extern void au1000_halt(void);
> @@ -87,11 +85,6 @@
>  
>  void __init bus_error_init(void) { /* nothing */ }
>  
> -void au1500_wbflush(void)
> -{
> -	__asm__ volatile ("sync");
> -}
> -
>  void __init au1x00_setup(void)
>  {
>  	char *argptr;
> @@ -117,7 +110,6 @@
>  	argptr = prom_getcmdline();
>  #endif
>  
> -        __wbflush = au1500_wbflush;
>  	_machine_restart = au1000_restart;
>  	_machine_halt = au1000_halt;
>  	_machine_power_off = au1000_power_off;


From ppopov@mvista.com Fri Mar 21 18:55:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Mar 2003 18:55:46 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:51699 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225194AbTCUSzp>;
	Fri, 21 Mar 2003 18:55:45 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA28382
	for <linux-mips@linux-mips.org>; Fri, 21 Mar 2003 10:55:43 -0800
Subject: Re: Success! Full CardBus/EXCA on PCI->Cardbus Bridge + DbAU1500
From: Pete Popov <ppopov@mvista.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030314135721.G20129@luca.pas.lab>
References: <20030314122352.F20129@luca.pas.lab>
	 <1047677667.18887.162.camel@zeus.mvista.com>
	 <20030314135721.G20129@luca.pas.lab>
Content-Type: text/plain; charset=ISO-8859-1
Organization: MontaVista Software
Message-Id: <1048273049.14211.56.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 21 Mar 2003 10:57:29 -0800
Content-Transfer-Encoding: 8bit
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: 1786
X-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
Content-Length: 2482
Lines: 65

Jeff,

I don't touch generic files, especially io.h :), so Ralf will have to
decide whether to apply the patch or not.

Pete

> Additionally, I had to apply the patch to include/asm-mips/io.h in order
> to get the hermes/orinoco drivers to compile. (I posted this patch earlier, and
> someone suggested that the SLOW_DOWN_IO; call was not necessary). Find it below.
> 
> I have some other patches applied; they should not affect PCMCIA. I'll check
> out clean source and patch it with this bare minimum, and let you know
> if something else is required.
> 
> Thanks, Pete -- a FAQ about your patches will really help people who are
> starting out on the Alchemy platform.
> 
> Regards,
> 
> Jeff
> 
> 
>   Index: io.h
>   ===================================================================
>   RCS file: /home/cvs/linux/include/asm-mips/io.h,v
>   retrieving revision 1.29.2.20
>   diff -u -r1.29.2.20 io.h
>   --- io.h        25 Feb 2003 22:03:12 -0000      1.29.2.20
>   +++ io.h        14 Mar 2003 21:50:14 -0000
>   @@ -332,12 +332,25 @@
>           SLOW_DOWN_IO;                                                   \
>    } while(0)
>   °
>   -#define outw_p(val,port)                                               \
>   -do {                                                                   \
>   -       *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
>   -               __ioswab16(val);                                        \
>   -       SLOW_DOWN_IO;                                                   \
>   -} while(0)
>   +/* baitisj */
>   +static inline u16 outw_p(u16 val, unsigned long port)
>   +{
>   +    register u16 retval;
>   +    do {
>   +        retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
>   +            __ioswab16(val);
>   +        SLOW_DOWN_IO;
>   +    } while(0);
>   +    return retval;
>   +}
>   +/*°°
>   + *  #define outw_p(val,port)                                           \
>   + *  do {                                                                       \
>   + *     *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
>   + *             __ioswab16(val);                                        \
>   + *     SLOW_DOWN_IO;                                                   \
>   + *  } while(0)
>   + */
>   °
>    #define outl_p(val,port)                                               \
>    do {                                                                   \
>   



From baitisj@idealab.com Fri Mar 21 19:39:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Mar 2003 19:39:58 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:51333 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225194AbTCUTj5>;
	Fri, 21 Mar 2003 19:39:57 +0000
Received: (qmail 5090 invoked by uid 6180); 21 Mar 2003 19:39:40 -0000
Date: Fri, 21 Mar 2003 11:39:40 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Patches for all four au1000 setup.c files
Message-ID: <20030321113940.O26687@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <3E7AD36E.26E2EA94@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3E7AD36E.26E2EA94@ekner.info>; from hartvig@ekner.info on Fri, Mar 21, 2003 at 09:55:10AM +0100
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: 1787
X-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
Content-Length: 6382
Lines: 231

On the subject of __wbflush():

It seems to me that setup.c should be exporting __wbflush, since there are some
modules that require this symbol. Try compiling the 8139 ethernet module, or
HostAP wireless drivers :)

Are the following patches correct?
Thanks!

-Jeff

Index: Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/Makefile,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 Makefile
--- Makefile    5 Mar 2003 08:18:58 -0000       1.1.2.2
+++ Makefile    21 Mar 2003 19:34:11 -0000
@@ -19,4 +19,6 @@
 
 obj-y := init.o setup.o
 
+export-objs := setup.o
+
 include $(TOPDIR)/Rules.make


Index: setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 setup.c
--- setup.c     7 Jan 2003 10:41:30 -0000       1.1.2.3
+++ setup.c     21 Mar 2003 19:34:19 -0000
@@ -242,3 +242,7 @@
                return phys_addr;
 }
 #endif
+
+#include <linux/module.h>
+EXPORT_SYMBOL(__wbflush);
+






On Fri, Mar 21, 2003 at 09:55:10AM +0100, Hartvig Ekner wrote:
> Hi,
> 
> the patches below for all four au1000 setup.c files removes the wbflush() routine, as this is no longer necessary
> (handled by the generic code now, which does a sync). This also means that it is not necessary to say yes to
> CONFIG_CPU_ADVANCED and override the CPU_HAS_WB setting, as the generic MIPS32 code will do just fine.
> 
> The patch for the db1x00 setup.c file also fixes a bug which prevented VRA from being used with Audio Codecs
> which support it.
> 
> /Hartvig
> 
> 

> Index: db1x00/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> retrieving revision 1.1.2.3
> diff -u -r1.1.2.3 setup.c
> --- db1x00/setup.c	7 Jan 2003 10:41:30 -0000	1.1.2.3
> +++ db1x00/setup.c	21 Mar 2003 08:44:49 -0000
> @@ -61,7 +61,6 @@
>  extern struct ide_ops *ide_ops;
>  #endif
>  
> -void (*__wbflush) (void);
>  extern struct rtc_ops no_rtc_ops;
>  extern char * __init prom_getcmdline(void);
>  extern void au1000_restart(char *);
> @@ -76,11 +75,6 @@
>  
>  void __init bus_error_init(void) { /* nothing */ }
>  
> -void au1x00_wbflush(void)
> -{
> -	__asm__ volatile ("sync");
> -}
> -
>  void __init au1x00_setup(void)
>  {
>  	char *argptr;
> @@ -109,14 +103,13 @@
>      }
>  #endif
>  
> -#if defined(CONFIG_SOUND_AU1000) && !defined(CONFIG_CPU_AU1000)
> +#if defined(CONFIG_SOUND_AU1X00) && !defined(CONFIG_CPU_AU1000)
>  	// au1000 does not support vra, au1500 and au1100 do
> -    strcat(argptr, " au1000_audio=vra");
> -    argptr = prom_getcmdline();
> +	strcat(argptr, " au1000_audio=vra");
> +	argptr = prom_getcmdline();
>  #endif
>  
>  	rtc_ops = &no_rtc_ops;
> -	__wbflush = au1x00_wbflush;
>  	_machine_restart = au1000_restart;
>  	_machine_halt = au1000_halt;
>  	_machine_power_off = au1000_power_off;
> Index: pb1000/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1000/setup.c,v
> retrieving revision 1.8.2.8
> diff -u -r1.8.2.8 setup.c
> --- pb1000/setup.c	11 Dec 2002 06:12:29 -0000	1.8.2.8
> +++ pb1000/setup.c	21 Mar 2003 08:44:50 -0000
> @@ -67,7 +67,6 @@
>  extern struct ide_ops *ide_ops;
>  #endif
>  
> -void (*__wbflush) (void);
>  extern struct rtc_ops no_rtc_ops;
>  extern char * __init prom_getcmdline(void);
>  extern void au1000_restart(char *);
> @@ -78,11 +77,6 @@
>  
>  void __init bus_error_init(void) { /* nothing */ }
>  
> -void au1000_wbflush(void)
> -{
> -	__asm__ volatile ("sync");
> -}
> -
>  void __init au1x00_setup(void)
>  {
>  	char *argptr;
> @@ -103,7 +97,6 @@
>  #endif
>  
>  	rtc_ops = &no_rtc_ops;
> -        __wbflush = au1000_wbflush;
>  	_machine_restart = au1000_restart;
>  	_machine_halt = au1000_halt;
>  	_machine_power_off = au1000_power_off;
> Index: pb1100/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1100/setup.c,v
> retrieving revision 1.1.2.6
> diff -u -r1.1.2.6 setup.c
> --- pb1100/setup.c	31 Dec 2002 05:00:22 -0000	1.1.2.6
> +++ pb1100/setup.c	21 Mar 2003 08:44:50 -0000
> @@ -71,7 +71,6 @@
>  extern struct rtc_ops pb1500_rtc_ops;
>  #endif
>  
> -void (*__wbflush) (void);
>  extern char * __init prom_getcmdline(void);
>  extern void au1000_restart(char *);
>  extern void au1000_halt(void);
> @@ -82,11 +81,6 @@
>  
>  void __init bus_error_init(void) { /* nothing */ }
>  
> -void au1100_wbflush(void)
> -{
> -	__asm__ volatile ("sync");
> -}
> -
>  void __init au1x00_setup(void)
>  {
>  	char *argptr;
> @@ -112,7 +106,6 @@
>  	argptr = prom_getcmdline();
>  #endif
>  
> -        __wbflush = au1100_wbflush;
>  	_machine_restart = au1000_restart;
>  	_machine_halt = au1000_halt;
>  	_machine_power_off = au1000_power_off;
> Index: pb1500/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
> retrieving revision 1.1.2.10
> diff -u -r1.1.2.10 setup.c
> --- pb1500/setup.c	29 Dec 2002 10:30:35 -0000	1.1.2.10
> +++ pb1500/setup.c	21 Mar 2003 08:44:50 -0000
> @@ -43,7 +43,6 @@
>  #include <asm/mipsregs.h>
>  #include <asm/reboot.h>
>  #include <asm/pgtable.h>
> -#include <asm/wbflush.h>
>  #include <asm/au1000.h>
>  #include <asm/pb1500.h>
>  
> @@ -72,7 +71,6 @@
>  extern struct rtc_ops pb1500_rtc_ops;
>  #endif
>  
> -void (*__wbflush) (void);
>  extern char * __init prom_getcmdline(void);
>  extern void au1000_restart(char *);
>  extern void au1000_halt(void);
> @@ -87,11 +85,6 @@
>  
>  void __init bus_error_init(void) { /* nothing */ }
>  
> -void au1500_wbflush(void)
> -{
> -	__asm__ volatile ("sync");
> -}
> -
>  void __init au1x00_setup(void)
>  {
>  	char *argptr;
> @@ -117,7 +110,6 @@
>  	argptr = prom_getcmdline();
>  #endif
>  
> -        __wbflush = au1500_wbflush;
>  	_machine_restart = au1000_restart;
>  	_machine_halt = au1000_halt;
>  	_machine_power_off = au1000_power_off;


-- 
         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 quintela@mandrakesoft.com Fri Mar 21 20:54:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Mar 2003 20:54:45 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:44147 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225194AbTCUUyo> convert rfc822-to-8bit;
	Fri, 21 Mar 2003 20:54:44 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 9C62D720; Fri, 21 Mar 2003 21:54:20 +0100 (CET)
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Success! Full CardBus/EXCA on PCI->Cardbus Bridge + DbAU1500
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <1048273049.14211.56.camel@zeus.mvista.com> (Pete Popov's
 message of "21 Mar 2003 10:57:29 -0800")
References: <20030314122352.F20129@luca.pas.lab>
	<1047677667.18887.162.camel@zeus.mvista.com>
	<20030314135721.G20129@luca.pas.lab>
	<1048273049.14211.56.camel@zeus.mvista.com>
Date: Fri, 21 Mar 2003 21:54:20 +0100
Message-ID: <86n0jophj7.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1788
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1669
Lines: 49

>>>>> "pete" == Pete Popov <ppopov@mvista.com> writes:

Hi
>> Index: io.h
>> ===================================================================
>> RCS file: /home/cvs/linux/include/asm-mips/io.h,v
>> retrieving revision 1.29.2.20
>> diff -u -r1.29.2.20 io.h
>> --- io.h        25 Feb 2003 22:03:12 -0000      1.29.2.20
>> +++ io.h        14 Mar 2003 21:50:14 -0000
>> @@ -332,12 +332,25 @@
>> SLOW_DOWN_IO;                                                   \
>> } while(0)
>> °
>> -#define outw_p(val,port)                                               \
>> -do {                                                                   \
>> -       *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
>> -               __ioswab16(val);                                        \
>> -       SLOW_DOWN_IO;                                                   \
>> -} while(0)
>> +/* baitisj */
>> +static inline u16 outw_p(u16 val, unsigned long port)
>> +{
>> +    register u16 retval;
>> +    do {
>> +        retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
>> +            __ioswab16(val);
>> +        SLOW_DOWN_IO;
>> +    } while(0);
>> +    return retval;
>> +}

static inline u16 outw_p(u16 val, unsigned long port)
{
        u16 retval; 
        retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
               __ioswab16(val);
               SLOW_DOWN_IO;
        return retval;
}

while do construct inside a function shouldn't be needed when you have
a function.  And register is obsolete :)

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From hartvig@ekner.info Fri Mar 21 22:07:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Mar 2003 22:07:43 +0000 (GMT)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:18697 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225194AbTCUWHL>;
	Fri, 21 Mar 2003 22:07:11 +0000
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP
	id D5AEAB4C6; Fri, 21 Mar 2003 23:06:45 +0100 (CET)
Message-ID: <3E7B8E39.CC463FEC@ekner.info>
Date: Fri, 21 Mar 2003 23:12:09 +0100
From: Hartvig Ekner <hartvig@ekner.info>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686)
X-Accept-Language: en
MIME-Version: 1.0
To: baitisj@evolution.com
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Patches for all four au1000 setup.c files
References: <3E7AD36E.26E2EA94@ekner.info> <20030321113940.O26687@luca.pas.lab>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <hartvig@ekner.info>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1789
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvig@ekner.info
Precedence: bulk
X-list: linux-mips
Content-Length: 7894
Lines: 252

Hi Jeff,

Are you talking about these two 8139 files from 2.4?

/home/hartvige/src/linux/linux-ralf/drivers/net> ls *8139*.c
8139cp.c  8139too.c

I can't see that they are using wbflush in any way. Grepping after wbflush through the
entire 2.4 tree, it seems wbflush is something only present on some dec platforms and then
the au1000 stuff - which would mean that any driver directly calling __wbflush would be
unable to compile/load on the majority of kernels. Or am I missing something? (I haven't
been using modules under MIPS at all).

In fact, I can't find a single file including wbflush.h except system.h, and it doesn't look
like anybody else should directly be including the wbflush.h file, but only use the macros
in system.h:

#define wmb()           fast_wmb()
#define rmb()           fast_rmb()
#define mb()            wbflush();
#define iob()           wbflush();

(which are differently defined if there is no WB configured).

/Hartvig

Jeff Baitis wrote:

> On the subject of __wbflush():
>
> It seems to me that setup.c should be exporting __wbflush, since there are some
> modules that require this symbol. Try compiling the 8139 ethernet module, or
> HostAP wireless drivers :)
>
> Are the following patches correct?
> Thanks!
>
> -Jeff
>
> Index: Makefile
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/Makefile,v
> retrieving revision 1.1.2.2
> diff -u -r1.1.2.2 Makefile
> --- Makefile    5 Mar 2003 08:18:58 -0000       1.1.2.2
> +++ Makefile    21 Mar 2003 19:34:11 -0000
> @@ -19,4 +19,6 @@
>
>  obj-y := init.o setup.o
>
> +export-objs := setup.o
> +
>  include $(TOPDIR)/Rules.make
>
> Index: setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> retrieving revision 1.1.2.3
> diff -u -r1.1.2.3 setup.c
> --- setup.c     7 Jan 2003 10:41:30 -0000       1.1.2.3
> +++ setup.c     21 Mar 2003 19:34:19 -0000
> @@ -242,3 +242,7 @@
>                 return phys_addr;
>  }
>  #endif
> +
> +#include <linux/module.h>
> +EXPORT_SYMBOL(__wbflush);
> +
>
> On Fri, Mar 21, 2003 at 09:55:10AM +0100, Hartvig Ekner wrote:
> > Hi,
> >
> > the patches below for all four au1000 setup.c files removes the wbflush() routine, as this is no longer necessary
> > (handled by the generic code now, which does a sync). This also means that it is not necessary to say yes to
> > CONFIG_CPU_ADVANCED and override the CPU_HAS_WB setting, as the generic MIPS32 code will do just fine.
> >
> > The patch for the db1x00 setup.c file also fixes a bug which prevented VRA from being used with Audio Codecs
> > which support it.
> >
> > /Hartvig
> >
> >
>
> > Index: db1x00/setup.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> > retrieving revision 1.1.2.3
> > diff -u -r1.1.2.3 setup.c
> > --- db1x00/setup.c    7 Jan 2003 10:41:30 -0000       1.1.2.3
> > +++ db1x00/setup.c    21 Mar 2003 08:44:49 -0000
> > @@ -61,7 +61,6 @@
> >  extern struct ide_ops *ide_ops;
> >  #endif
> >
> > -void (*__wbflush) (void);
> >  extern struct rtc_ops no_rtc_ops;
> >  extern char * __init prom_getcmdline(void);
> >  extern void au1000_restart(char *);
> > @@ -76,11 +75,6 @@
> >
> >  void __init bus_error_init(void) { /* nothing */ }
> >
> > -void au1x00_wbflush(void)
> > -{
> > -     __asm__ volatile ("sync");
> > -}
> > -
> >  void __init au1x00_setup(void)
> >  {
> >       char *argptr;
> > @@ -109,14 +103,13 @@
> >      }
> >  #endif
> >
> > -#if defined(CONFIG_SOUND_AU1000) && !defined(CONFIG_CPU_AU1000)
> > +#if defined(CONFIG_SOUND_AU1X00) && !defined(CONFIG_CPU_AU1000)
> >       // au1000 does not support vra, au1500 and au1100 do
> > -    strcat(argptr, " au1000_audio=vra");
> > -    argptr = prom_getcmdline();
> > +     strcat(argptr, " au1000_audio=vra");
> > +     argptr = prom_getcmdline();
> >  #endif
> >
> >       rtc_ops = &no_rtc_ops;
> > -     __wbflush = au1x00_wbflush;
> >       _machine_restart = au1000_restart;
> >       _machine_halt = au1000_halt;
> >       _machine_power_off = au1000_power_off;
> > Index: pb1000/setup.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/au1000/pb1000/setup.c,v
> > retrieving revision 1.8.2.8
> > diff -u -r1.8.2.8 setup.c
> > --- pb1000/setup.c    11 Dec 2002 06:12:29 -0000      1.8.2.8
> > +++ pb1000/setup.c    21 Mar 2003 08:44:50 -0000
> > @@ -67,7 +67,6 @@
> >  extern struct ide_ops *ide_ops;
> >  #endif
> >
> > -void (*__wbflush) (void);
> >  extern struct rtc_ops no_rtc_ops;
> >  extern char * __init prom_getcmdline(void);
> >  extern void au1000_restart(char *);
> > @@ -78,11 +77,6 @@
> >
> >  void __init bus_error_init(void) { /* nothing */ }
> >
> > -void au1000_wbflush(void)
> > -{
> > -     __asm__ volatile ("sync");
> > -}
> > -
> >  void __init au1x00_setup(void)
> >  {
> >       char *argptr;
> > @@ -103,7 +97,6 @@
> >  #endif
> >
> >       rtc_ops = &no_rtc_ops;
> > -        __wbflush = au1000_wbflush;
> >       _machine_restart = au1000_restart;
> >       _machine_halt = au1000_halt;
> >       _machine_power_off = au1000_power_off;
> > Index: pb1100/setup.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/au1000/pb1100/setup.c,v
> > retrieving revision 1.1.2.6
> > diff -u -r1.1.2.6 setup.c
> > --- pb1100/setup.c    31 Dec 2002 05:00:22 -0000      1.1.2.6
> > +++ pb1100/setup.c    21 Mar 2003 08:44:50 -0000
> > @@ -71,7 +71,6 @@
> >  extern struct rtc_ops pb1500_rtc_ops;
> >  #endif
> >
> > -void (*__wbflush) (void);
> >  extern char * __init prom_getcmdline(void);
> >  extern void au1000_restart(char *);
> >  extern void au1000_halt(void);
> > @@ -82,11 +81,6 @@
> >
> >  void __init bus_error_init(void) { /* nothing */ }
> >
> > -void au1100_wbflush(void)
> > -{
> > -     __asm__ volatile ("sync");
> > -}
> > -
> >  void __init au1x00_setup(void)
> >  {
> >       char *argptr;
> > @@ -112,7 +106,6 @@
> >       argptr = prom_getcmdline();
> >  #endif
> >
> > -        __wbflush = au1100_wbflush;
> >       _machine_restart = au1000_restart;
> >       _machine_halt = au1000_halt;
> >       _machine_power_off = au1000_power_off;
> > Index: pb1500/setup.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
> > retrieving revision 1.1.2.10
> > diff -u -r1.1.2.10 setup.c
> > --- pb1500/setup.c    29 Dec 2002 10:30:35 -0000      1.1.2.10
> > +++ pb1500/setup.c    21 Mar 2003 08:44:50 -0000
> > @@ -43,7 +43,6 @@
> >  #include <asm/mipsregs.h>
> >  #include <asm/reboot.h>
> >  #include <asm/pgtable.h>
> > -#include <asm/wbflush.h>
> >  #include <asm/au1000.h>
> >  #include <asm/pb1500.h>
> >
> > @@ -72,7 +71,6 @@
> >  extern struct rtc_ops pb1500_rtc_ops;
> >  #endif
> >
> > -void (*__wbflush) (void);
> >  extern char * __init prom_getcmdline(void);
> >  extern void au1000_restart(char *);
> >  extern void au1000_halt(void);
> > @@ -87,11 +85,6 @@
> >
> >  void __init bus_error_init(void) { /* nothing */ }
> >
> > -void au1500_wbflush(void)
> > -{
> > -     __asm__ volatile ("sync");
> > -}
> > -
> >  void __init au1x00_setup(void)
> >  {
> >       char *argptr;
> > @@ -117,7 +110,6 @@
> >       argptr = prom_getcmdline();
> >  #endif
> >
> > -        __wbflush = au1500_wbflush;
> >       _machine_restart = au1000_restart;
> >       _machine_halt = au1000_halt;
> >       _machine_power_off = au1000_power_off;
>
> --
>          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 quintela@mandrakesoft.com Fri Mar 21 22:33:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Mar 2003 22:33:24 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:10871 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225194AbTCUWdX>;
	Fri, 21 Mar 2003 22:33:23 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id A3F6F720; Fri, 21 Mar 2003 23:33:21 +0100 (CET)
To: Hartvig Ekner <hartvig@ekner.info>
Cc: baitisj@evolution.com,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Patches for all four au1000 setup.c files
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <3E7B8E39.CC463FEC@ekner.info> (Hartvig Ekner's message of
 "Fri, 21 Mar 2003 23:12:09 +0100")
References: <3E7AD36E.26E2EA94@ekner.info>
	<20030321113940.O26687@luca.pas.lab> <3E7B8E39.CC463FEC@ekner.info>
Date: Fri, 21 Mar 2003 23:33:21 +0100
Message-ID: <86fzpgpcy6.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1790
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2011
Lines: 52

>>>>> "hartvig" == Hartvig Ekner <hartvig@ekner.info> writes:


hartvig> I can't see that they are using wbflush in any way. Grepping
hartvig> after wbflush through the entire 2.4 tree, it seems wbflush
hartvig> is something only present on some dec platforms and then the
hartvig> au1000 stuff - which would mean that any driver directly
hartvig> calling __wbflush would be unable to compile/load on the
hartvig> majority of kernels. Or am I missing something? (I haven't
hartvig> been using modules under MIPS at all).

Yes, you missed the definition of mb() :p

quintela$ grep "mb(" drivers/net/8139* | grep -v rmb | grep -v wmb
drivers/net/8139too.c:          mb();
quintela$ 


hartvig> In fact, I can't find a single file including wbflush.h
hartvig> except system.h, and it doesn't look like anybody else should
hartvig> directly be including the wbflush.h file, but only use the
hartvig> macros in system.h:

hartvig> #define wmb()           fast_wmb()
hartvig> #define rmb()           fast_rmb()
hartvig> #define mb()            wbflush();
hartvig> #define iob()           wbflush();

hartvig> (which are differently defined if there is no WB configured).

but WB is configured in :)

quintela$ grep WB arch/mips/defconfig-pb1*
arch/mips/defconfig-pb1000:CONFIG_CPU_HAS_WB=y
arch/mips/defconfig-pb1100:CONFIG_CPU_HAS_WB=y
arch/mips/defconfig-pb1500:CONFIG_CPU_HAS_WB=y
quintela$ 

Other thing is that this machine should be using wbflush at all, but
that is a different story.  I agree with  (/me looks in archive),
*your* patch removing wbflush for that boards.  They are only doing
"sync" ond wbflush, and that is the thing that __sync() already does.

I.e. If I have to chooses wich patch to integrate, the one exporting
__wbflush(), or the one removing it altogether from pb1*, I will
choose removing it.  It looks superflous.

Later, Juan "who don't have that processor, and handwaving is easy".

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From hartvig@ekner.info Fri Mar 21 22:40:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Mar 2003 22:40:19 +0000 (GMT)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:27918 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225194AbTCUWkS>;
	Fri, 21 Mar 2003 22:40:18 +0000
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP
	id 41D85B4CD; Fri, 21 Mar 2003 23:40:17 +0100 (CET)
Message-ID: <3E7B9615.FB66BF53@ekner.info>
Date: Fri, 21 Mar 2003 23:45:41 +0100
From: Hartvig Ekner <hartvig@ekner.info>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Juan Quintela <quintela@mandrakesoft.com>
Cc: baitisj@evolution.com,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Patches for all four au1000 setup.c files
References: <3E7AD36E.26E2EA94@ekner.info>
		<20030321113940.O26687@luca.pas.lab> <3E7B8E39.CC463FEC@ekner.info> <86fzpgpcy6.fsf@trasno.mitica>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <hartvig@ekner.info>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1791
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvig@ekner.info
Precedence: bulk
X-list: linux-mips
Content-Length: 2652
Lines: 71

Hi Juan,

Juan Quintela wrote:

> >>>>> "hartvig" == Hartvig Ekner <hartvig@ekner.info> writes:
>
> hartvig> I can't see that they are using wbflush in any way. Grepping
> hartvig> after wbflush through the entire 2.4 tree, it seems wbflush
> hartvig> is something only present on some dec platforms and then the
> hartvig> au1000 stuff - which would mean that any driver directly
> hartvig> calling __wbflush would be unable to compile/load on the
> hartvig> majority of kernels. Or am I missing something? (I haven't
> hartvig> been using modules under MIPS at all).
>
> Yes, you missed the definition of mb() :p
>
> quintela$ grep "mb(" drivers/net/8139* | grep -v rmb | grep -v wmb
> drivers/net/8139too.c:          mb();
> quintela$
>
> hartvig> In fact, I can't find a single file including wbflush.h
> hartvig> except system.h, and it doesn't look like anybody else should
> hartvig> directly be including the wbflush.h file, but only use the
> hartvig> macros in system.h:
>
> hartvig> #define wmb()           fast_wmb()
> hartvig> #define rmb()           fast_rmb()
> hartvig> #define mb()            wbflush();
> hartvig> #define iob()           wbflush();
>
> hartvig> (which are differently defined if there is no WB configured).
>
> but WB is configured in :)
>

That's the problem! Wb does not need to be configured in, it is a mistake. My patch was missing
the required fixes to the defconfig files, it was only described in the mail.  So I think the only
thing missing is a patch to fix all the pb/db defconfig files to look like this:

# CONFIG_CPU_ADVANCED is not set
CONFIG_CPU_HAS_LLSC=y
# CONFIG_CPU_HAS_LLDSCD is not set
# CONFIG_CPU_HAS_WB is not set
CONFIG_CPU_HAS_SYNC=y

... which is the setting also used by all other MIPS32 CPUs. Then everything should be ok.

/Hartvig

>
> quintela$ grep WB arch/mips/defconfig-pb1*
> arch/mips/defconfig-pb1000:CONFIG_CPU_HAS_WB=y
> arch/mips/defconfig-pb1100:CONFIG_CPU_HAS_WB=y
> arch/mips/defconfig-pb1500:CONFIG_CPU_HAS_WB=y
> quintela$
>
> Other thing is that this machine should be using wbflush at all, but
> that is a different story.  I agree with  (/me looks in archive),
> *your* patch removing wbflush for that boards.  They are only doing
> "sync" ond wbflush, and that is the thing that __sync() already does.
>
> I.e. If I have to chooses wich patch to integrate, the one exporting
> __wbflush(), or the one removing it altogether from pb1*, I will
> choose removing it.  It looks superflous.
>
> Later, Juan "who don't have that processor, and handwaving is easy".
>
> --
> In theory, practice and theory are the same, but in practice they
> are different -- Larry McVoy


From jim@thelemkes.ca Sat Mar 22 00:54:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 22 Mar 2003 00:54:22 +0000 (GMT)
Received: from toclean2.bellnexxia.net ([IPv6:::ffff:209.226.175.37]:7388 "EHLO
	toclean2-srv.bellnexxia.net") by linux-mips.org with ESMTP
	id <S8225207AbTCVAyU>; Sat, 22 Mar 2003 00:54:20 +0000
Received: from buoy.thelemkes.ca ([64.229.251.113])
          by tomts23-srv.bellnexxia.net
          (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP
          id <20030321200043.SFYN24451.tomts23-srv.bellnexxia.net@buoy.thelemkes.ca>;
          Fri, 21 Mar 2003 15:00:43 -0500
Received: from mast.thelemkes.ca (mast.thelemkes.ca [192.168.62.70])
	by buoy.thelemkes.ca (Postfix) with ESMTP
	id 338F11FF3; Fri, 21 Mar 2003 15:00:43 -0500 (EST)
Subject: Re: Running on R4k/R3k Indigo
From: James Lemke <jim@thelemkes.ca>
To: Achim Hensel <achim.hensel@ruhr-uni-bochum.de>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20030318234844.2e465609.achim.hensel@ruhr-uni-bochum.de>
References: <20030318234844.2e465609.achim.hensel@ruhr-uni-bochum.de>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 21 Mar 2003 15:00:52 -0500
Message-Id: <1048276852.32056.25.camel@mast.thelemkes.ca>
Mime-Version: 1.0
Return-Path: <jim@thelemkes.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: 1792
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jim@thelemkes.ca
Precedence: bulk
X-list: linux-mips
Content-Length: 839
Lines: 31

On Tue, 2003-03-18 at 17:48, Achim Hensel wrote:
> Hello, folks (of both lists)
> 
> I recently got both an R4k and an R3k SGI Indigo. 
> 
> I know, none of them is supported at the moment.
> So, I want to try to change that.
> 
> I hadn't started yet, but every help is appreciated.
> 
> CU,
> 	Achim
> 
> P.S.: This was posted to both lists, as I don't know, which OS 
> has the better starting point for my computers.
Hi Achim,
I'm also thinking about porting Linux to an R3K Indigo.
So I'm curious --
Did you get any response to your post on linux-mips@linux-mips.org or
port-sgimips@netbsd.org?
Have you made any progress yet?

Cheers,
Jim.

-- 
Jim Lemke   jim@TheLemkes.ca   Barrie, Ontario
1986 Concours, COG #2637    1992 ST1100, STOC #3750
Those who dance are considered insane
by those who can't hear the music.  George Carlin


From agx@sigxcpu.org Sat Mar 22 21:23:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 22 Mar 2003 21:23:22 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:29421
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225207AbTCVVXV>; Sat, 22 Mar 2003 21:23:21 +0000
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id E6B212BC31; Sat, 22 Mar 2003 22:23:18 +0100 (CET)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 15044-06;
 Sat, 22 Mar 2003 22:23:17 +0100 (CET)
Received: from bogon.sigxcpu.org (kons-d9bb5455.pool.mediaWays.net [217.187.84.85])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 9EC772BC2D; Sat, 22 Mar 2003 22:23:16 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 440031735C; Sat, 22 Mar 2003 22:20:40 +0100 (CET)
Date: Sat, 22 Mar 2003 22:20:39 +0100
From: Guido Guenther <agx@sigxcpu.org>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: [PATCH 2.5]: move do_signal32 declaration upwards
Message-ID: <20030322212039.GA19984@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	ralf@linux-mips.org, linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="7JfCtLOvnd9MIVvH"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1793
X-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
Content-Length: 1338
Lines: 44


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

Hi,
do_signal32 is needed in do_signal but declared after that function
which makes this an implicit declaration. Moving the declaration upward
fixes the warning. Patch attached, please apply.
 -- Guido

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="do_signal32.diff"

Index: arch/mips64/kernel/signal.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/signal.c,v
retrieving revision 1.37
diff -u -p -r1.37 signal.c
--- arch/mips64/kernel/signal.c	6 Mar 2003 21:30:48 -0000	1.37
+++ arch/mips64/kernel/signal.c	22 Mar 2003 21:18:45 -0000
@@ -341,6 +341,10 @@ static inline void handle_signal(unsigne
 	}
 }
 
+
+extern int do_signal32(sigset_t *oldset, struct pt_regs *regs);
+extern int do_irix_signal(sigset_t *oldset, struct pt_regs *regs);
+
 asmlinkage int do_signal(sigset_t *oldset, struct pt_regs *regs)
 {
 	siginfo_t info;
@@ -377,8 +381,6 @@ asmlinkage int do_signal(sigset_t *oldse
 	return 0;
 }
 
-extern int do_irix_signal(sigset_t *oldset, struct pt_regs *regs);
-extern int do_signal32(sigset_t *oldset, struct pt_regs *regs);
 
 /*
  * notification of userspace execution resumption

--7JfCtLOvnd9MIVvH--

From agx@sigxcpu.org Sun Mar 23 21:24:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 23 Mar 2003 21:24:11 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:51848
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225195AbTCWVYK>; Sun, 23 Mar 2003 21:24:10 +0000
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 7296A2BC31
	for <linux-mips@linux-mips.org>; Sun, 23 Mar 2003 22:24:03 +0100 (CET)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 21943-04
 for <linux-mips@linux-mips.org>; Sun, 23 Mar 2003 22:24:02 +0100 (CET)
Received: from bogon.sigxcpu.org (kons-d9bb5426.pool.mediaWays.net [217.187.84.38])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 6BDD42BC2D
	for <linux-mips@linux-mips.org>; Sun, 23 Mar 2003 22:24:01 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id C94411735C; Sun, 23 Mar 2003 22:21:44 +0100 (CET)
Date: Sun, 23 Mar 2003 19:43:17 +0100
From: Guido Guenther <agx@debian.org>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org, vivien.chappelier@linux-mips.org
Subject: [PATCH 2.5]: IP32 enable power button
Message-ID: <20030323184317.GE26796@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="RhUH2Ysw6aD5utA4"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Resent-From: agx@sigxcpu.org
Resent-Date: Sun, 23 Mar 2003 22:21:44 +0100
Resent-To: linux-mips@linux-mips.org
Resent-Message-Id: <20030323212144.C94411735C@bogon.sigxcpu.org>
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: 1794
X-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
Content-Length: 8868
Lines: 297


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

Hi,
the attached patch enables the power button on IP32 and adds definitions
for the extra registers of the ds1728[57]. Please apply.
Regards,
 -- Guido

--RhUH2Ysw6aD5utA4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ip32-pwr-button.diff"

Index: arch/mips/sgi-ip32/ip32-reset.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip32/ip32-reset.c,v
retrieving revision 1.1
diff -u -p -r1.1 ip32-reset.c
--- arch/mips/sgi-ip32/ip32-reset.c	25 Jul 2002 19:10:08 -0000	1.1
+++ arch/mips/sgi-ip32/ip32-reset.c	23 Mar 2003 18:27:34 -0000
@@ -5,30 +5,186 @@
  *
  * Copyright (C) 2001 Keith M Wesolowski
  * Copyright (C) 2001 Paul Mundt
+ * Copyright (C) 2003 Guido Guenther <agx@sigxcpu.org>
+ *
+ * based on sgi-ip22/ip22-reset.c
  */
+
 #include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/notifier.h>
+#include <linux/ds17287rtc.h>
 
+#include <asm/irq.h>
 #include <asm/reboot.h>
 #include <asm/sgialib.h>
+#include <asm/addrspace.h>
+#include <asm/types.h>
+#include <asm/system.h>
+#include <asm/ip32/ip32_ints.h>
+
+#define POWERDOWN_TIMEOUT	120
+/*
+ * Blink frequency during reboot grace period and when paniced.
+ */
+#define POWERDOWN_FREQ		(HZ / 4)
+#define PANIC_FREQ		(HZ / 8)
+
+static struct timer_list power_timer, blink_timer, debounce_timer;
+static int shuting_down = 0, has_paniced = 0;
+
+static void ip32_machine_restart(char *command) __attribute__((noreturn));
+static void ip32_machine_halt(void) __attribute__((noreturn));
+static void ip32_machine_power_off(void) __attribute__((noreturn));
 
 static void ip32_machine_restart(char *cmd)
 {
+	if (shuting_down)
+		ip32_machine_power_off();
 	ArcReboot();
 }
 
 static inline void ip32_machine_halt(void)
 {
+	if (shuting_down)
+		ip32_machine_power_off();
 	ArcEnterInteractiveMode();
 }
 
 static void ip32_machine_power_off(void)
 {
-	ip32_machine_halt();
+	volatile unsigned char reg_a, xctrl_a, xctrl_b;
+
+	reg_a = CMOS_READ(RTC_REG_A);
+
+	/* setup for kickstart & wake-up (DS12287 Ref. Man. p. 19) */
+	reg_a &= ~DS_REGA_DV2;
+	reg_a |= DS_REGA_DV1 | DS_REGA_DV0;
+	CMOS_WRITE(reg_a, RTC_REG_A);
+
+	while(1) {
+		xctrl_a = CMOS_READ(DS_B1_XCTRL4A) 
+				& ~(DS_XCTRL4A_WF | DS_XCTRL4A_KF);
+		xctrl_a = DS_XCTRL4A_PAB; /* power off flag */
+		xctrl_b = CMOS_READ(DS_B1_XCTRL4B) 
+				| DS_XCTRL4B_WFE | DS_XCTRL4B_KFE;
+		CMOS_WRITE(xctrl_b, DS_B1_XCTRL4B);
+		CMOS_WRITE(xctrl_a, DS_B1_XCTRL4A);
+	}
+}
+
+static void power_timeout(unsigned long data)
+{
+	ip32_machine_power_off();
 }
 
-void __init ip32_reboot_setup(void)
+static void blink_timeout(unsigned long data)
+{
+	u64 mc_led =  mace_read_64(MACEISA_FLASH_NIC_REG);
+
+	mc_led ^= MACEISA_LED_RED;
+	if(has_paniced) 
+		mc_led &= ~MACEISA_LED_GREEN;
+	mace_write_64(MACEISA_FLASH_NIC_REG, mc_led);
+	mod_timer(&blink_timer, jiffies+data);
+}
+
+static void debounce(unsigned long data)
+{
+	volatile unsigned char reg_a,reg_c,xctrl_a;
+
+	reg_c = CMOS_READ(RTC_INTR_FLAGS);
+	reg_a = CMOS_READ(RTC_REG_A);
+	CMOS_WRITE(reg_a | DS_REGA_DV0, RTC_REG_A);
+	xctrl_a = CMOS_READ(DS_B1_XCTRL4A);
+	if( xctrl_a & DS_XCTRL4A_KF || reg_c & RTC_IRQF ) {
+		/* Interrupt still being sent. */
+		debounce_timer.expires = jiffies + 5; /* 0.05s  */
+		add_timer(&debounce_timer);
+
+		/* clear interrupt source */
+		CMOS_WRITE( xctrl_a & ~(DS_XCTRL4A_KF|DS_XCTRL4A_WF|DS_XCTRL4A_RF),
+			    DS_B1_XCTRL4A);
+		CMOS_WRITE(reg_a & ~DS_REGA_DV0, RTC_REG_A);
+		return;
+	}
+	CMOS_WRITE(reg_a & ~DS_REGA_DV0, RTC_REG_A);
+
+	if (has_paniced)
+		ArcReboot();
+
+	enable_irq(MACEISA_RTC_IRQ);
+}
+
+static inline void ip32_power_button(void)
+{
+	if (has_paniced)
+		return;
+
+	if (shuting_down || kill_proc(1, SIGINT, 1)) {
+		/* No init process or button pressed twice.  */
+		ip32_machine_power_off();
+	}
+
+	shuting_down = 1;
+	blink_timer.data = POWERDOWN_FREQ;
+	blink_timeout(POWERDOWN_FREQ);
+
+	init_timer(&power_timer);
+	power_timer.function = power_timeout;
+	power_timer.expires = jiffies + POWERDOWN_TIMEOUT * HZ;
+	add_timer(&power_timer);
+}
+
+static void ip32_rtc_int(int irq, void *dev_id, struct pt_regs *regs)
+{
+	volatile unsigned char reg_c;
+
+	reg_c = CMOS_READ(RTC_INTR_FLAGS);
+	if( reg_c & RTC_IRQF ) {
+		/* Wait until interrupt goes away */
+		disable_irq(MACEISA_RTC_IRQ);
+		init_timer(&debounce_timer);
+		debounce_timer.function = debounce;
+		debounce_timer.expires = jiffies + 5;
+		add_timer(&debounce_timer);
+	} else
+		printk(KERN_WARNING 
+			"%s: RTC IRQ without RTC_IRQF\n", __FUNCTION__);
+
+	printk(KERN_DEBUG "Power button pressed\n");
+	ip32_power_button();
+}
+
+static int panic_event(struct notifier_block *this, unsigned long event,
+                      void *ptr)
+{
+	if (has_paniced)
+		return NOTIFY_DONE;
+	has_paniced = 1;
+
+	blink_timer.data = PANIC_FREQ;
+	blink_timeout(PANIC_FREQ);
+
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block panic_block = {
+	.notifier_call	= panic_event,
+};
+
+static __init int ip32_reboot_setup(void)
 {
 	_machine_restart = ip32_machine_restart;
 	_machine_halt = ip32_machine_halt;
 	_machine_power_off = ip32_machine_power_off;
+	request_irq(MACEISA_RTC_IRQ, ip32_rtc_int, 0, "rtc", NULL);
+	init_timer(&blink_timer);
+	blink_timer.function = blink_timeout;
+	notifier_chain_register(&panic_notifier_list, &panic_block);
+
+	return 0;
 }
+
+subsys_initcall(ip32_reboot_setup);
Index: arch/mips/sgi-ip32/ip32-setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip32/ip32-setup.c,v
retrieving revision 1.2
diff -u -p -r1.2 ip32-setup.c
--- arch/mips/sgi-ip32/ip32-setup.c	21 Sep 2002 21:21:18 -0000	1.2
+++ arch/mips/sgi-ip32/ip32-setup.c	23 Mar 2003 18:27:34 -0000
@@ -89,8 +105,6 @@ void __init ip32_setup(void)
 #ifdef CONFIG_VT
 	conswitchp = &dummy_con;
 #endif
-
-	ip32_reboot_setup();
 
 	rtc_ops = &ip32_rtc_ops;
 	board_time_init = ip32_time_init;
--- /dev/null	Sat Mar 16 18:32:44 2002
+++ include/linux/ds17287rtc.h	Sun Mar 23 17:58:47 2003
@@ -0,0 +1,64 @@
+/* 
+ * ds17287rtc.h - register definitions for the ds1728[57] RTC / CMOS RAM
+ *
+ * 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.
+ * 
+ * (C) 2003 Guido Guenther <agx@sigxcpu.org>
+ *
+ */
+
+#ifndef _DS17287RTC_H
+#define _DS17287RTC_H
+
+#include <asm/io.h>
+#include <linux/rtc.h>			/* get the user-level API */
+#include <linux/spinlock.h>		/* spinlock_t */
+#include <linux/mc146818rtc.h>
+
+/* register A */
+#define DS_REGA_DV2 0x40		/* countdown chain */
+#define DS_REGA_DV1 0x20		/* oscillator enable */
+#define DS_REGA_DV0 0x10		/* bank select */
+
+/* bank 1 registers */
+#define DS_B1_MODEL	 0x40		/* model number byte */
+#define DS_B1_SN1 	 0x41		/* serial number byte 1 */
+#define DS_B1_SN2 	 0x42		/* serial number byte 2 */
+#define DS_B1_SN3 	 0x43		/* serial number byte 3 */
+#define DS_B1_SN4 	 0x44		/* serial number byte 4 */
+#define DS_B1_SN5 	 0x45		/* serial number byte 5 */
+#define DS_B1_SN6 	 0x46		/* serial number byte 6 */
+#define DS_B1_CRC 	 0x47		/* CRC byte */
+#define DS_B1_CENTURY 	 0x48		/* Century byte */
+#define DS_B1_DALARM 	 0x49		/* date alarm */
+#define DS_B1_XCTRL4A	 0x4a		/* extendec control register 4a */
+#define DS_B1_XCTRL4B	 0x4b		/* extendec control register 4b */
+#define DS_B1_RTCADDR2 	 0x4e		/* rtc address 2 */
+#define DS_B1_RTCADDR3 	 0x4f		/* rtc address 2 */
+#define DS_B1_RAMLSB	 0x50		/* extended ram LSB */
+#define DS_B1_RAMMSB	 0x51		/* extended ram MSB */
+#define DS_B1_RAMDPORT	 0x53		/* extended ram data port */
+
+/* register details */
+/* extended control register 4a */
+#define DS_XCTRL4A_VRT2  0x80 		/* valid ram and time */
+#define DS_XCTRL4A_INCR  0x40		/* increment progress status */
+#define DS_XCTRL4A_BME   0x20		/* burst mode enable */
+#define DS_XCTRL4A_PAB   0x08		/* power active bar ctrl */
+#define DS_XCTRL4A_RF    0x04		/* ram clear flag */
+#define DS_XCTRL4A_WF    0x02		/* wake up alarm flag */
+#define DS_XCTRL4A_KF    0x01		/* kickstart flag */
+
+/* extended control register 4b */
+#define DS_XCTRL4B_ABE   0x80 		/* auxiliary battery enable */
+#define DS_XCTRL4B_E32K	 0x40		/* enable 32.768 kHz Output */
+#define DS_XCTRL4B_CS    0x20		/* crystal select */
+#define DS_XCTRL4B_RCE   0x10		/* ram clear enable */
+#define DS_XCTRL4B_PRS   0x08		/* PAB resec select */
+#define DS_XCTRL4B_RIE   0x04		/* ram clear interrupt enable */
+#define DS_XCTRL4B_WFE   0x02		/* wake up alarm interrupt enable */
+#define DS_XCTRL4B_KFE   0x01		/* kickstart interrupt enable */
+
+#endif /* _DS17287RTC_H */

--RhUH2Ysw6aD5utA4--


From agx@sigxcpu.org Mon Mar 24 00:48:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 00:48:36 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:42126
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225195AbTCXAsf>; Mon, 24 Mar 2003 00:48:35 +0000
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 2EEF12BC31; Mon, 24 Mar 2003 01:48:33 +0100 (CET)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 23156-02;
 Mon, 24 Mar 2003 01:48:32 +0100 (CET)
Received: from bogon.sigxcpu.org (kons-d9bb5426.pool.mediaWays.net [217.187.84.38])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 2AC272BC2D; Mon, 24 Mar 2003 01:48:32 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 17CC51735C; Mon, 24 Mar 2003 01:46:15 +0100 (CET)
Date: Mon, 24 Mar 2003 01:46:14 +0100
From: Guido Guenther <agx@debian.org>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, vivien.chappelier@linux-mips.org
Subject: Re: [PATCH 2.5]: IP32 enable power button
Message-ID: <20030324004614.GH26796@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@debian.org>,
	ralf@linux-mips.org, linux-mips@linux-mips.org,
	vivien.chappelier@linux-mips.org
References: <20030323184317.GE26796@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030323184317.GE26796@bogon.ms20.nix>
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1795
X-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@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 393
Lines: 8

On Sun, Mar 23, 2003 at 07:43:17PM +0100, Guido Guenther wrote:
> the attached patch enables the power button on IP32 and adds definitions
> for the extra registers of the ds1728[57]. Please apply.
Hmm...the patch that worked without problems all over the day now
refuses to shut of the machine. I'll have to look into that and post a
fixed version when I know whats wrong.
Regards,
 -- Guido

From jscheel@activevb.de Mon Mar 24 07:15:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 07:15:28 +0000 (GMT)
Received: from [IPv6:::ffff:212.12.33.223] ([IPv6:::ffff:212.12.33.223]:8320
	"EHLO jusst.de") by linux-mips.org with ESMTP id <S8224847AbTCXHP1> convert rfc822-to-8bit;
	Mon, 24 Mar 2003 07:15:27 +0000
Received: from pd9e31316.dip.t-dialin.net ([217.227.19.22] helo=juli.scheel-home.de)
	by jusst.de with asmtp (Exim 4.05)
	id 18xM5u-0007V8-00
	for linux-mips@linux-mips.org; Mon, 24 Mar 2003 08:10:06 +0100
From: Julian Scheel <jscheel@activevb.de>
To: linux-mips@linux-mips.org
Subject: Set Registers for VR4181A
Date: Mon, 24 Mar 2003 08:16:03 +0100
User-Agent: KMail/1.5
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Message-Id: <200303240816.03482.jscheel@activevb.de>
Return-Path: <jscheel@activevb.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: 1796
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jscheel@activevb.de
Precedence: bulk
X-list: linux-mips
Content-Length: 591
Lines: 16

Hi all,

as I wrote a few weeks ago I have a NEC VR4181A-Board, on which I want to get 
linux running. Currently I have a kernel which should work, but it can't 
boot, since linux seems to expect that the registers have been already set by 
the bootloader. Since the used bootloader is a very small one which only 
proceeds the given files (written by a friend of me) it didn't do this job, 
so linux tries to access registers, which are not set yet.

So I need a bootloader which can do the job and works with my CPU/Board. Can 
someone give me a hint which one to use?

-- 
Grüße,
Julian


From ralf@linux-mips.net Mon Mar 24 13:05:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 13:05:38 +0000 (GMT)
Received: from p508B6D77.dip.t-dialin.net ([IPv6:::ffff:80.139.109.119]:14209
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224847AbTCXNFh>; Mon, 24 Mar 2003 13:05:37 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2OD5U906302;
	Mon, 24 Mar 2003 14:05:30 +0100
Date: Mon, 24 Mar 2003 14:05:30 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Julian Scheel <jscheel@activevb.de>
Cc: linux-mips@linux-mips.org
Subject: Re: Set Registers for VR4181A
Message-ID: <20030324140529.C4959@linux-mips.org>
References: <200303240816.03482.jscheel@activevb.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200303240816.03482.jscheel@activevb.de>; from jscheel@activevb.de on Mon, Mar 24, 2003 at 08:16:03AM +0100
Return-Path: <ralf@linux-mips.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: 1797
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 646
Lines: 13

On Mon, Mar 24, 2003 at 08:16:03AM +0100, Julian Scheel wrote:

> as I wrote a few weeks ago I have a NEC VR4181A-Board, on which I want to get 
> linux running. Currently I have a kernel which should work, but it can't 
> boot, since linux seems to expect that the registers have been already set by 
> the bootloader. Since the used bootloader is a very small one which only 
> proceeds the given files (written by a friend of me) it didn't do this job, 
> so linux tries to access registers, which are not set yet.

Fixinging the few assumptions that Linus is making about the initializaton
state of the machine should be fairly easy.

  Ralf

From quintela@mandrakesoft.com Mon Mar 24 13:44:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 13:44:47 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:27513 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8224847AbTCXNoq>;
	Mon, 24 Mar 2003 13:44:46 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 24D986EE; Mon, 24 Mar 2003 14:44:31 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Julian Scheel <jscheel@activevb.de>, linux-mips@linux-mips.org
Subject: Re: Set Registers for VR4181A
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030324140529.C4959@linux-mips.org> (Ralf Baechle's message
 of "Mon, 24 Mar 2003 14:05:30 +0100")
References: <200303240816.03482.jscheel@activevb.de>
	<20030324140529.C4959@linux-mips.org>
Date: Mon, 24 Mar 2003 14:44:31 +0100
Message-ID: <86r88wc20w.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1798
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 969
Lines: 23

>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:

ralf> On Mon, Mar 24, 2003 at 08:16:03AM +0100, Julian Scheel wrote:
>> as I wrote a few weeks ago I have a NEC VR4181A-Board, on which I want to get 
>> linux running. Currently I have a kernel which should work, but it can't 
>> boot, since linux seems to expect that the registers have been already set by 
>> the bootloader. Since the used bootloader is a very small one which only 
>> proceeds the given files (written by a friend of me) it didn't do this job, 
>> so linux tries to access registers, which are not set yet.

ralf> Fixinging the few assumptions that Linus is making about the initializaton
                                         ^^^^^
ralf> state of the machine should be fairly easy.

I assume you mean Linux :)

Later, Juan "who didn't knew that Linus hacked in Linux/MIPS lately"



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From sjhill@realitydiluted.com Mon Mar 24 16:01:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 16:01:01 +0000 (GMT)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:3285
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8224847AbTCXQBA>; Mon, 24 Mar 2003 16:01:00 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 18xUNd-0000cG-00
	for <linux-mips@linux-mips.org>; Mon, 24 Mar 2003 10:00:57 -0600
Message-ID: <3E7F2BB4.8060108@realitydiluted.com>
Date: Mon, 24 Mar 2003 11:00:52 -0500
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030319 Debian/1.3-3
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Proposed patch for MIPS PCI autoscanning code...
Content-Type: multipart/mixed;
 boundary="------------080607010901090009070100"
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: 1799
X-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
Content-Length: 2374
Lines: 70

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

In the PCI autoscanning code for MIPS the assumption is made that the
generic 'pci_read_XXX' and 'pci_write_XXX' will suffice when initially
autoscanning the bus. These functions are defined in the main top-level
PCI code. For one of my platforms, this simply does not hold since the
platform specific PCI functions defined in the 'pci_ops' structure for
the 'mips_pci_channel' need to be used. I propose the following patch
to fix this. Comments before I apply this?

-Steve

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

--- pci_channel.h	2001-08-18 10:19:34.000000000 -0400
+++ pci_channel.h.new	2003-03-24 10:54:29.000000000 -0500
@@ -11,12 +11,13 @@
 #include <linux/pci.h>
 
 /*
- * Each pci channel is a top-level PCI bus seem by CPU.  A machine  with
+ * Each pci channel is a top-level PCI bus seen by CPU.  A machine  with
  * multiple PCI channels may have multiple PCI host controllers or a
  * single controller supporting multiple channels.
  */
 struct pci_channel {
 	struct pci_ops *pci_ops;
+	struct pci_ops *early_pci_ops;
 	struct resource *io_resource;
 	struct resource *mem_resource;
 	int first_devfn;

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

--- pci_auto.c	2001-11-26 20:07:06.000000000 -0500
+++ pci_auto.c.new	2003-03-24 10:54:14.000000000 -0500
@@ -74,9 +74,14 @@
 int early_##rw##_config_##size(struct pci_channel *hose,		\
 	int top_bus, int bus, int devfn, int offset, type value)	\
 {									\
-	return pci_##rw##_config_##size(				\
-		fake_pci_dev(hose, top_bus, bus, devfn),		\
-		offset, value);						\
+	if (hose->early_pci_ops->rw##_##size != NULL)			\
+		return hose->early_pci_ops->rw##_##size(		\
+			fake_pci_dev(hose, top_bus, bus, devfn),	\
+			offset, value);					\
+	else								\
+		return pci_##rw##_config_##size(			\
+			fake_pci_dev(hose, top_bus, bus, devfn),	\
+			offset, value);					\
 }
 
 EARLY_PCI_OP(read, byte, u8 *)

--------------080607010901090009070100--


From jsun@mvista.com Mon Mar 24 18:09:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 18:09:04 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:52208 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224847AbTCXSJD>;
	Mon, 24 Mar 2003 18:09:03 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h2OI8tV29471;
	Mon, 24 Mar 2003 10:08:55 -0800
Date: Mon, 24 Mar 2003 10:08:55 -0800
From: Jun Sun <jsun@mvista.com>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Proposed patch for MIPS PCI autoscanning code...
Message-ID: <20030324100855.M1926@mvista.com>
References: <3E7F2BB4.8060108@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3E7F2BB4.8060108@realitydiluted.com>; from sjhill@realitydiluted.com on Mon, Mar 24, 2003 at 11:00:52AM -0500
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: 1800
X-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
Content-Length: 2152
Lines: 58

On Mon, Mar 24, 2003 at 11:00:52AM -0500, Steven J. Hill wrote:
> In the PCI autoscanning code for MIPS the assumption is made that the
> generic 'pci_read_XXX' and 'pci_write_XXX' will suffice when initially
> autoscanning the bus. These functions are defined in the main top-level
> PCI code. For one of my platforms, this simply does not hold since the
> platform specific PCI functions defined in the 'pci_ops' structure for
> the 'mips_pci_channel' need to be used. I propose the following patch
> to fix this. Comments before I apply this?
>

Can you illustrate more why the generic PCI functions won't work in your
case?

Also, if you do check in the patch, please also update all the boards
that uses pci_channel so that they will still compile. 

Jun


> --- pci_channel.h	2001-08-18 10:19:34.000000000 -0400
> +++ pci_channel.h.new	2003-03-24 10:54:29.000000000 -0500
> @@ -11,12 +11,13 @@
>  #include <linux/pci.h>
>  
>  /*
> - * Each pci channel is a top-level PCI bus seem by CPU.  A machine  with
> + * Each pci channel is a top-level PCI bus seen by CPU.  A machine  with
>   * multiple PCI channels may have multiple PCI host controllers or a
>   * single controller supporting multiple channels.
>   */
>  struct pci_channel {
>  	struct pci_ops *pci_ops;
> +	struct pci_ops *early_pci_ops;
>  	struct resource *io_resource;
>  	struct resource *mem_resource;
>  	int first_devfn;

> --- pci_auto.c	2001-11-26 20:07:06.000000000 -0500
> +++ pci_auto.c.new	2003-03-24 10:54:14.000000000 -0500
> @@ -74,9 +74,14 @@
>  int early_##rw##_config_##size(struct pci_channel *hose,		\
>  	int top_bus, int bus, int devfn, int offset, type value)	\
>  {									\
> -	return pci_##rw##_config_##size(				\
> -		fake_pci_dev(hose, top_bus, bus, devfn),		\
> -		offset, value);						\
> +	if (hose->early_pci_ops->rw##_##size != NULL)			\
> +		return hose->early_pci_ops->rw##_##size(		\
> +			fake_pci_dev(hose, top_bus, bus, devfn),	\
> +			offset, value);					\
> +	else								\
> +		return pci_##rw##_config_##size(			\
> +			fake_pci_dev(hose, top_bus, bus, devfn),	\
> +			offset, value);					\
>  }
>  
>  EARLY_PCI_OP(read, byte, u8 *)


From sjhill@realitydiluted.com Mon Mar 24 19:40:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 19:40:01 +0000 (GMT)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:24534
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8224847AbTCXTkB>; Mon, 24 Mar 2003 19:40:01 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 18xXnY-0000ps-00; Mon, 24 Mar 2003 13:39:56 -0600
Message-ID: <3E7F5F04.7020108@realitydiluted.com>
Date: Mon, 24 Mar 2003 14:39:48 -0500
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030319 Debian/1.3-3
X-Accept-Language: en
MIME-Version: 1.0
To: Jun Sun <jsun@mvista.com>
CC: linux-mips@linux-mips.org
Subject: Re: Proposed patch for MIPS PCI autoscanning code...
References: <3E7F2BB4.8060108@realitydiluted.com> <20030324100855.M1926@mvista.com>
In-Reply-To: <20030324100855.M1926@mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1801
X-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
Content-Length: 264
Lines: 11

Jun Sun wrote:
> 
> Can you illustrate more why the generic PCI functions won't work in your
> case?
> 
It turned out to be additional locking that was added in that I did not
know about and hence the patch should be discarded :). Oh well, it's a
Monday.

-Steve


From ralf@linux-mips.net Mon Mar 24 21:40:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 21:40:55 +0000 (GMT)
Received: from p508B6D77.dip.t-dialin.net ([IPv6:::ffff:80.139.109.119]:25995
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224847AbTCXVkw>; Mon, 24 Mar 2003 21:40:52 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2OLefp17739;
	Mon, 24 Mar 2003 22:40:41 +0100
Date: Mon, 24 Mar 2003 22:40:41 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Guido Guenther <agx@debian.org>, linux-mips@linux-mips.org,
	vivien.chappelier@linux-mips.org
Subject: Re: [PATCH 2.5]: IP32 enable power button
Message-ID: <20030324224041.B16592@linux-mips.org>
References: <20030323184317.GE26796@bogon.ms20.nix> <20030324004614.GH26796@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030324004614.GH26796@bogon.ms20.nix>; from agx@debian.org on Mon, Mar 24, 2003 at 01:46:14AM +0100
Return-Path: <ralf@linux-mips.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: 1802
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 495
Lines: 12

On Mon, Mar 24, 2003 at 01:46:14AM +0100, Guido Guenther wrote:

> On Sun, Mar 23, 2003 at 07:43:17PM +0100, Guido Guenther wrote:
> > the attached patch enables the power button on IP32 and adds definitions
> > for the extra registers of the ds1728[57]. Please apply.
> Hmm...the patch that worked without problems all over the day now
> refuses to shut of the machine. I'll have to look into that and post a
> fixed version when I know whats wrong.

Ok, will ignore the patch for now,

  Ralf

From ralf@linux-mips.net Mon Mar 24 22:00:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 22:00:30 +0000 (GMT)
Received: from p508B6D77.dip.t-dialin.net ([IPv6:::ffff:80.139.109.119]:53643
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225209AbTCXWA3>; Mon, 24 Mar 2003 22:00:29 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2OLxYX18162;
	Mon, 24 Mar 2003 22:59:34 +0100
Date: Mon, 24 Mar 2003 22:59:34 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Guido Guenther <agx@sigxcpu.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH 2.5]: move do_signal32 declaration upwards
Message-ID: <20030324225934.D16592@linux-mips.org>
References: <20030322212039.GA19984@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030322212039.GA19984@bogon.ms20.nix>; from agx@sigxcpu.org on Sat, Mar 22, 2003 at 10:20:39PM +0100
Return-Path: <ralf@linux-mips.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: 1803
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 286
Lines: 9

On Sat, Mar 22, 2003 at 10:20:39PM +0100, Guido Guenther wrote:

> do_signal32 is needed in do_signal but declared after that function
> which makes this an implicit declaration. Moving the declaration upward
> fixes the warning. Patch attached, please apply.

Thanks, applied,

  Ralf

From agx@sigxcpu.org Mon Mar 24 22:45:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 22:45:11 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:39062
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8224847AbTCXWpK>; Mon, 24 Mar 2003 22:45:10 +0000
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 0B7E72BC31; Mon, 24 Mar 2003 23:45:09 +0100 (CET)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 29412-07;
 Mon, 24 Mar 2003 23:45:08 +0100 (CET)
Received: from bogon.sigxcpu.org (kons-d9bb5431.pool.mediaWays.net [217.187.84.49])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 029402BC2D; Mon, 24 Mar 2003 23:45:07 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id EB06D1735C; Mon, 24 Mar 2003 23:42:50 +0100 (CET)
Date: Mon, 24 Mar 2003 23:42:50 +0100
From: Guido Guenther <agx@debian.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org, vivien.chappelier@linux-mips.org
Subject: Re: [PATCH 2.5]: IP32 enable power button
Message-ID: <20030324224250.GW26796@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@debian.org>,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	vivien.chappelier@linux-mips.org
References: <20030323184317.GE26796@bogon.ms20.nix> <20030324004614.GH26796@bogon.ms20.nix> <20030324224041.B16592@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030324224041.B16592@linux-mips.org>
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1804
X-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@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 800
Lines: 17

On Mon, Mar 24, 2003 at 10:40:41PM +0100, Ralf Baechle wrote:
> On Mon, Mar 24, 2003 at 01:46:14AM +0100, Guido Guenther wrote:
> 
> > On Sun, Mar 23, 2003 at 07:43:17PM +0100, Guido Guenther wrote:
> > > the attached patch enables the power button on IP32 and adds definitions
> > > for the extra registers of the ds1728[57]. Please apply.
> > Hmm...the patch that worked without problems all over the day now
> > refuses to shut of the machine. I'll have to look into that and post a
> > fixed version when I know whats wrong.
> 
> Ok, will ignore the patch for now,
I have a fixed version at:
 http://honk.physik.uni-konstanz.de/linux-mips/kernel-patches/2.5/ip32-pwr-button.diff
which works here without problems now but I'll give it some more testing
before resubmitting it.
Regards,
  -- Guido

From yaelgilad@myrealbox.com Mon Mar 24 23:24:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Mar 2003 23:24:20 +0000 (GMT)
Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:57514
	"EHLO smtp-send.myrealbox.com") by linux-mips.org with ESMTP
	id <S8225219AbTCXXYS> convert rfc822-to-8bit; Mon, 24 Mar 2003 23:24:18 +0000
Received: from yaelgilad [194.90.64.161] by myrealbox.com
	with NetMail ModWeb Module; Mon, 24 Mar 2003 07:11:15 +0000
Subject: Second Embedded Ramdisk
From: "Gilad Benjamini" <yaelgilad@myrealbox.com>
To: kernelnewbies@nl.linux.org, linux-mips@linux-mips.org
Date: Mon, 24 Mar 2003 07:11:15 +0000
X-Mailer: NetMail ModWeb Module
X-Sender: yaelgilad
MIME-Version: 1.0
Message-ID: <1048489875.74c25880yaelgilad@myrealbox.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Return-Path: <yaelgilad@myrealbox.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1805
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yaelgilad@myrealbox.com
Precedence: bulk
X-list: linux-mips
Content-Length: 367
Lines: 15

Hi,
I am compiling a linux-mips kernel with an 
embedded ramdisk as the root file system.
The file system include modules which are inserted
and not used later on. I've increased the 
ramdisk accordingly, but this is wasted memory
after module insertion.

How can I avoid this waste ?
Can I embed a second ramdisk into the kernel 
image and later unmount it ?

TIA



From ranjanp@efi.com Tue Mar 25 00:26:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Mar 2003 00:26:43 +0000 (GMT)
Received: from mail3.efi.com ([IPv6:::ffff:192.68.228.90]:8973 "HELO
	fcexgw03.efi.internal") by linux-mips.org with SMTP
	id <S8225213AbTCYA0n>; Tue, 25 Mar 2003 00:26:43 +0000
Received: from 10.3.12.12 by fcexgw03.efi.internal (InterScan E-Mail VirusWall NT); Mon, 24 Mar 2003 16:26:35 -0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C2F265.311CE0B0"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: arch/mips/kernel/setup.c patch - wrong start_pfn with CONFIG_EMBEDDED_RAMDISK
Date: Mon, 24 Mar 2003 16:26:34 -0800
Message-ID: <D9F6B9DABA4CAE4B92850252C52383AB0796825E@ex-eng-corp.efi.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: arch/mips/kernel/setup.c patch - wrong start_pfn with CONFIG_EMBEDDED_RAMDISK
Thread-Index: AcLyZTEn9QmHLPghQR2hDCENa/7/ag==
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: 1806
X-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
Content-Length: 1908
Lines: 45

This is a multi-part message in MIME format.

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

I would like to submit the following change to arch/mips/kernel/setup.c. =
The start_pfn is not correct in case CONFIG_EMBEDDED_RAMDISK is slected. =
The ramdisk pages are added twice.

The diff -Naur output is attached to the mail.

Thanks

Ranjan

 <<diff.output.txt>>=20

------_=_NextPart_001_01C2F265.311CE0B0
Content-Type: text/plain;
	name="diff.output.txt"
Content-Transfer-Encoding: base64
Content-Description: diff.output.txt
Content-Disposition: attachment;
	filename="diff.output.txt"

ZGlmZiAtTmF1ciBsaW51eC1kZXYvYXJjaC9taXBzL2tlcm5lbC9zZXR1cC5jIGxpbnV4LWRldi1w
YXRjaC9hcmNoL21pcHMva2VybmVsL3NldHVwLmMKLS0tIGxpbnV4LWRldi9hcmNoL21pcHMva2Vy
bmVsL3NldHVwLmMJV2VkIERlYyAxOCAxNTo0MDoxNCAyMDAyCisrKyBsaW51eC1kZXYtcGF0Y2gv
YXJjaC9taXBzL2tlcm5lbC9zZXR1cC5jCU1vbiBNYXIgMjQgMTY6MTM6MDcgMjAwMwpAQCAtMjU1
LDYgKzI1NSwxNiBAQAogCWludCBpOwogCiAjaWZkZWYgQ09ORklHX0JMS19ERVZfSU5JVFJECisj
aWZkZWYgQ09ORklHX0VNQkVEREVEX1JBTURJU0sKKwkvKgorCSAqIEVtYmVkZGVkIHJhbWRpc2sg
LT4gX2VuZCBhZnRlciB0aGUgcmFtZGlzayBzbyBubyBuZWVkIHRvIGFkZCB0aGVzZQorCSAqIHBh
Z2VzIGFnYWluCisJICoKKwkgKiBQYXJ0aWFsbHkgdXNlZCBwYWdlcyBhcmUgbm90IHVzYWJsZSAt
IHRodXMKKwkgKiB3ZSBhcmUgcm91bmRpbmcgdXB3YXJkcy4KKwkgKi8KKwlzdGFydF9wZm4gPSBQ
Rk5fVVAoX19wYSgmX2VuZCkpOworI2Vsc2UKIAl0bXAgPSAoKCh1bnNpZ25lZCBsb25nKSZfZW5k
ICsgUEFHRV9TSVpFLTEpICYgUEFHRV9NQVNLKSAtIDg7CiAJaWYgKHRtcCA8ICh1bnNpZ25lZCBs
b25nKSZfZW5kKQogCQl0bXAgKz0gUEFHRV9TSVpFOwpAQCAtMjY0LDYgKzI3NCw3IEBACiAJCWlu
aXRyZF9lbmQgPSBpbml0cmRfc3RhcnQgKyBpbml0cmRfaGVhZGVyWzFdOwogCX0KIAlzdGFydF9w
Zm4gPSBQRk5fVVAoX19wYSgoJl9lbmQpKyhpbml0cmRfZW5kIC0gaW5pdHJkX3N0YXJ0KSArIFBB
R0VfU0laRSkpOworI2VuZGlmCiAjZWxzZQogCS8qCiAJICogUGFydGlhbGx5IHVzZWQgcGFnZXMg
YXJlIG5vdCB1c2FibGUgLSB0aHVzCg==

------_=_NextPart_001_01C2F265.311CE0B0--

From WayneChen@aiptek.com.tw Tue Mar 25 00:44:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Mar 2003 00:44:13 +0000 (GMT)
Received: from h237-210-243-242.seed.net.tw ([IPv6:::ffff:210.243.242.237]:57336
	"EHLO relay.aiptek.com.tw") by linux-mips.org with ESMTP
	id <S8225213AbTCYAoM>; Tue, 25 Mar 2003 00:44:12 +0000
Received: from mail.aiptek.com.tw (mail.aiptek.com.tw [10.0.1.149])
	by relay.aiptek.com.tw (8.11.6/8.11.6) with ESMTP id h2P8hO009951
	for <linux-mips@linux-mips.org>; Tue, 25 Mar 2003 16:43:52 +0800
Received: from WayneChen ([10.0.3.112]) by mail.aiptek.com.tw with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 25 Mar 2003 08:42:49 +0800
From: "Wayne Chen" <waynechen@aiptek.com.tw>
To: <linux-mips@linux-mips.org>
Subject: unregistered
Date: Tue, 25 Mar 2003 08:42:48 +0800
Message-ID: <001001c2f267$75d17610$7003000a@aiptek.com.tw>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: base64
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.2800.1106
In-Reply-To: <20030324234938Z8225213-1272+976@linux-mips.org>
Importance: Normal
X-OriginalArrivalTime: 25 Mar 2003 00:42:49.0403 (UTC) FILETIME=[75F048B0:01C2F267]
Return-Path: <WayneChen@aiptek.com.tw>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1807
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: waynechen@aiptek.com.tw
Precedence: bulk
X-list: linux-mips
Content-Length: 889
Lines: 13

SSB3b3VsZCBsaWtlIHRvIHVucmVnaXN0ZXIuDQoNCg0KDQoNCg0KDQogDQogICAgs6+wtsJFIC8g
V2F5bmUgQ2hlbg0KICAgICAgQUlQVEVLIEludGVybmF0aW9uYWwgSW5jLg0KICAgICAgVGVsOiA4
ODYtMy01Njc4MTM4IGV4dDI3MiANCiAgICAgIEZheDogODg2LTMtNTY3ODU2OQ0KICAgICAgTWFp
bDogd2F5bmVjaGVuQGFpcHRlay5jb20udHcgDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IHJhbGZAbGludXgtbWlwcy5vcmcgW21haWx0bzpyYWxmQGxpbnV4LW1pcHMub3Jn
XQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMjUsIDIwMDMgNzo1MCBBTQ0KVG86IGxpbnV4LWN2c0Bs
aW51eC1taXBzLm9yZw0KU3ViamVjdDogQ1ZTIFVwZGF0ZUAtbWlwcy5vcmc6IGxpbnV4IA0KDQoN
Cg0KQ1ZTUk9PVDoJL2hvbWUvY3ZzDQpNb2R1bGUgbmFtZToJbGludXgNCkNoYW5nZXMgYnk6CXJh
bGZAZnRwLmxpbnV4LW1pcHMub3JnCTAzLzAzLzI0IDIzOjQ5OjMzDQoNCk1vZGlmaWVkIGZpbGVz
Og0KCWFyY2gvbWlwcy9tbSAgIDogYy1taXBzMzIuYyBjLXI1NDMyLmMgYy1ybTdrLmMgDQoJYXJj
aC9taXBzNjQvbW0gOiBjLW1pcHM2NC5jIA0KDQpMb2cgbWVzc2FnZToNCglEZWxldGUgdW51c2Vk
IGRlZmluaXRpb25zIG9mIEJBUlJJRVIuDQoNCg0K


From yaelgilad@myrealbox.com Tue Mar 25 01:27:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Mar 2003 01:27:43 +0000 (GMT)
Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:36457
	"EHLO smtp-send.myrealbox.com") by linux-mips.org with ESMTP
	id <S8225212AbTCYB1n> convert rfc822-to-8bit; Tue, 25 Mar 2003 01:27:43 +0000
Received: from yaelgilad [194.90.64.161] by myrealbox.com
	with NetMail ModWeb Module; Sun, 23 Mar 2003 14:54:07 +0000
Subject: Second embedded ramdisk
From: "Gilad Benjamini" <yaelgilad@myrealbox.com>
To: linux-mips@linux-mips.org
Date: Sun, 23 Mar 2003 14:54:07 +0000
X-Mailer: NetMail ModWeb Module
X-Sender: yaelgilad
MIME-Version: 1.0
Message-ID: <1048431247.d25840c0yaelgilad@myrealbox.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Return-Path: <yaelgilad@myrealbox.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1808
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yaelgilad@myrealbox.com
Precedence: bulk
X-list: linux-mips
Content-Length: 244
Lines: 8

I am currently embedding a root-ram-disk within
my kernel image.
Can I embed a second disk ?

Motivation: The second disk will contain modules
to be inserted upon startup. I don't need the modules
later, so I'd rather umount this file system.


From baitisj@idealab.com Tue Mar 25 02:04:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Mar 2003 02:04:55 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:51086 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225227AbTCYCEy>;
	Tue, 25 Mar 2003 02:04:54 +0000
Received: (qmail 30720 invoked by uid 6180); 25 Mar 2003 02:04:47 -0000
Date: Mon, 24 Mar 2003 18:04:47 -0800
From: Jeff Baitis <baitisj@evolution.com>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Juan Quintela <quintela@mandrakesoft.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Patches for all four au1000 setup.c files
Message-ID: <20030324180446.S26687@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <3E7AD36E.26E2EA94@ekner.info> <20030321113940.O26687@luca.pas.lab> <3E7B8E39.CC463FEC@ekner.info> <86fzpgpcy6.fsf@trasno.mitica> <3E7B9615.FB66BF53@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3E7B9615.FB66BF53@ekner.info>; from hartvig@ekner.info on Fri, Mar 21, 2003 at 11:45:41PM +0100
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: 1809
X-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
Content-Length: 3291
Lines: 91

Yes. mb() was at the heart of the problem.

I've applied the patches that remove wbflush, and de-configured my .config,
and everything is compiling just fine!

Thanks,

Jeff

On Fri, Mar 21, 2003 at 11:45:41PM +0100, Hartvig Ekner wrote:
> Hi Juan,
> 
> Juan Quintela wrote:
> 
> > >>>>> "hartvig" == Hartvig Ekner <hartvig@ekner.info> writes:
> >
> > hartvig> I can't see that they are using wbflush in any way. Grepping
> > hartvig> after wbflush through the entire 2.4 tree, it seems wbflush
> > hartvig> is something only present on some dec platforms and then the
> > hartvig> au1000 stuff - which would mean that any driver directly
> > hartvig> calling __wbflush would be unable to compile/load on the
> > hartvig> majority of kernels. Or am I missing something? (I haven't
> > hartvig> been using modules under MIPS at all).
> >
> > Yes, you missed the definition of mb() :p
> >
> > quintela$ grep "mb(" drivers/net/8139* | grep -v rmb | grep -v wmb
> > drivers/net/8139too.c:          mb();
> > quintela$
> >
> > hartvig> In fact, I can't find a single file including wbflush.h
> > hartvig> except system.h, and it doesn't look like anybody else should
> > hartvig> directly be including the wbflush.h file, but only use the
> > hartvig> macros in system.h:
> >
> > hartvig> #define wmb()           fast_wmb()
> > hartvig> #define rmb()           fast_rmb()
> > hartvig> #define mb()            wbflush();
> > hartvig> #define iob()           wbflush();
> >
> > hartvig> (which are differently defined if there is no WB configured).
> >
> > but WB is configured in :)
> >
> 
> That's the problem! Wb does not need to be configured in, it is a mistake. My patch was missing
> the required fixes to the defconfig files, it was only described in the mail.  So I think the only
> thing missing is a patch to fix all the pb/db defconfig files to look like this:
> 
> # CONFIG_CPU_ADVANCED is not set
> CONFIG_CPU_HAS_LLSC=y
> # CONFIG_CPU_HAS_LLDSCD is not set
> # CONFIG_CPU_HAS_WB is not set
> CONFIG_CPU_HAS_SYNC=y
> 
> ... which is the setting also used by all other MIPS32 CPUs. Then everything should be ok.
> 
> /Hartvig
> 
> >
> > quintela$ grep WB arch/mips/defconfig-pb1*
> > arch/mips/defconfig-pb1000:CONFIG_CPU_HAS_WB=y
> > arch/mips/defconfig-pb1100:CONFIG_CPU_HAS_WB=y
> > arch/mips/defconfig-pb1500:CONFIG_CPU_HAS_WB=y
> > quintela$
> >
> > Other thing is that this machine should be using wbflush at all, but
> > that is a different story.  I agree with  (/me looks in archive),
> > *your* patch removing wbflush for that boards.  They are only doing
> > "sync" ond wbflush, and that is the thing that __sync() already does.
> >
> > I.e. If I have to chooses wich patch to integrate, the one exporting
> > __wbflush(), or the one removing it altogether from pb1*, I will
> > choose removing it.  It looks superflous.
> >
> > Later, Juan "who don't have that processor, and handwaving is easy".
> >
> > --
> > In theory, practice and theory are the same, but in practice they
> > are different -- Larry McVoy
> 

-- 
         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 yaelgilad@myrealbox.com Wed Mar 26 08:33:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Mar 2003 08:33:22 +0000 (GMT)
Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:27241
	"EHLO smtp-send.myrealbox.com") by linux-mips.org with ESMTP
	id <S8224851AbTCZIdV> convert rfc822-to-8bit; Wed, 26 Mar 2003 08:33:21 +0000
Received: from yaelgilad [81.218.95.46] by myrealbox.com
	with NetMail ModWeb Module; Wed, 26 Mar 2003 08:33:21 +0000
Subject: Relative Checksum
From: "Gilad Benjamini" <yaelgilad@myrealbox.com>
To: linux-mips@linux-mips.org
Date: Wed, 26 Mar 2003 08:33:21 +0000
X-Mailer: NetMail ModWeb Module
X-Sender: yaelgilad
MIME-Version: 1.0
Message-ID: <1048667601.7d003520yaelgilad@myrealbox.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Return-Path: <yaelgilad@myrealbox.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1810
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yaelgilad@myrealbox.com
Precedence: bulk
X-list: linux-mips
Content-Length: 234
Lines: 11

Hi,
ip_fast_csum provides an asm version for IP checksum.
Any available mips-asm implementation out there for 
a relative checksum?

i.e. I get a packet, change
a field or two, and want to compute just the 
change in the checksum.




From macro@ds2.pg.gda.pl Wed Mar 26 16:04:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Mar 2003 16:04:37 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:9193 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224851AbTCZQEg>; Wed, 26 Mar 2003 16:04:36 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA23146;
	Wed, 26 Mar 2003 17:05:04 +0100 (MET)
Date: Wed, 26 Mar 2003 17:05:04 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org, Guido Guenther <agx@sigxcpu.org>
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
In-Reply-To: <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030326170313.20767F-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: 1811
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 459
Lines: 13

On Tue, 18 Mar 2003, Thiemo Seufer wrote:

> For my private linux kernels, I use a new CONFIG_MIPS_NEW_TOOLCHAIN in the
> Makefile. I don't see a better way around it.

 An automatic selection between new-style and old-style gcc options is on
my to-do list.

-- 
+  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 Mar 26 16:52:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Mar 2003 16:52:14 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:23018 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225200AbTCZQwO>; Wed, 26 Mar 2003 16:52:14 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA23672;
	Wed, 26 Mar 2003 17:52:40 +0100 (MET)
Date: Wed, 26 Mar 2003 17:52:40 +0100 (MET)
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: <20030306011121Z8225204-1272+770@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030326175117.20767L-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: 1812
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 624
Lines: 20

On Thu, 6 Mar 2003 kwalker@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: Tag: linux_2_4 war.h 
> 	include/asm-mips64: Tag: linux_2_4 war.h 
> 	drivers/char   : Tag: linux_2_4 Config.in Makefile 
> 	                 sb1250_duart.c 
> Added files:
> 	drivers/char   : Tag: linux_2_4 mips_rtc.c 
> 
> Log message:
> 	many uart fixes, add workaround

 Hmm, how does mips_rtc.c relate to the rest of the commit?

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


From br1@4g-systems.de Wed Mar 26 17:54:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Mar 2003 17:54:21 +0000 (GMT)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.171]:13505
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8224827AbTCZRyT> convert rfc822-to-8bit; Wed, 26 Mar 2003 17:54:19 +0000
Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 18yF6Q-0003cK-00
	for linux-mips@linux-mips.org; Wed, 26 Mar 2003 18:54:18 +0100
Received: from [62.109.119.183] (helo=192.168.202.41)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 18yF6Q-00089P-00
	for linux-mips@linux-mips.org; Wed, 26 Mar 2003 18:54:18 +0100
From: Bruno Randolf <br1@4g-systems.de>
Organization: 4G Mobile Systeme
To: linux-mips@linux-mips.org
Subject: au1500 mm problems?
Date: Wed, 26 Mar 2003 18:54:01 +0100
User-Agent: KMail/1.5
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Content-Description: clearsigned data
Content-Disposition: inline
Message-Id: <200303261854.10478.br1@4g-systems.de>
Return-Path: <br1@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: 1813
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: br1@4g-systems.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1082
Lines: 42

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

hello!

i am regularily getting the following 2 types of kernel oopses on my au1500 
based board (mycable XXS), whenever i try to do something more demanding to 
the CPU (like compiling):

Unhandled kernel unaligned access in unaligned.c::emulate_load_store_insn,
line 481:

Unable to handle kernel paging request at virtual address 02000014, epc ==
80137554, ra == 4
Oops in fault.c::do_page_fault, line 205:

do you have any suggestions for me what could be causes for these? 

i have 64MB ram and my root filesystem mounted over NFS. branch linux_2_4 a 
few weeks ago. i can provide you with the complete oops if that would help.

btw: i cant use petes 36bit patch on the latest linux_2_4 branch anymore - it 
always gives me a "Reserved instruction in kernel code in traps.c::do_ri, 
line 654:" when i boot the kernel.

thanks,
bruno







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

iD8DBQE+gelCfg2jtUL97G4RAqdAAJ9EHSZ4vaCMAOPTSM0uekiRk2aDVQCeIoZs
WP4h2LkaKgDc4s21w5qM3NY=
=gwBM
-----END PGP SIGNATURE-----


From ralf@linux-mips.net Wed Mar 26 18:16:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Mar 2003 18:16:06 +0000 (GMT)
Received: from p508B68B0.dip.t-dialin.net ([IPv6:::ffff:80.139.104.176]:43706
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224827AbTCZSQF>; Wed, 26 Mar 2003 18:16:05 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2QIG1I19987;
	Wed, 26 Mar 2003 19:16:01 +0100
Date: Wed, 26 Mar 2003 19:16:01 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Gilad Benjamini <yaelgilad@myrealbox.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Relative Checksum
Message-ID: <20030326191601.A19939@linux-mips.org>
References: <1048667601.7d003520yaelgilad@myrealbox.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: <1048667601.7d003520yaelgilad@myrealbox.com>; from yaelgilad@myrealbox.com on Wed, Mar 26, 2003 at 08:33:21AM +0000
Return-Path: <ralf@linux-mips.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: 1814
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 426
Lines: 14

On Wed, Mar 26, 2003 at 08:33:21AM +0000, Gilad Benjamini wrote:

> ip_fast_csum provides an asm version for IP checksum.
> Any available mips-asm implementation out there for 
> a relative checksum?
> 
> i.e. I get a packet, change
> a field or two, and want to compute just the 
> change in the checksum.

I suggest to look at the code for IP masquerading which already does things
like this when rewriting packets.

  Ralf

From alan@lxorguk.ukuu.org.uk Wed Mar 26 18:24:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Mar 2003 18:24:37 +0000 (GMT)
Received: from pc2-cwma1-4-cust86.swan.cable.ntl.com ([IPv6:::ffff:213.105.254.86]:60603
	"EHLO irongate.swansea.linux.org.uk") by linux-mips.org with ESMTP
	id <S8224827AbTCZSYg>; Wed, 26 Mar 2003 18:24:36 +0000
Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1])
	by irongate.swansea.linux.org.uk (8.12.7/8.12.7) with ESMTP id h2QJcRYf000388;
	Wed, 26 Mar 2003 19:38:27 GMT
Received: (from alan@localhost)
	by irongate.swansea.linux.org.uk (8.12.7/8.12.7/Submit) id h2QJcPau000386;
	Wed, 26 Mar 2003 19:38:25 GMT
X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Relative Checksum
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org
In-Reply-To: <20030326191601.A19939@linux-mips.org>
References: <1048667601.7d003520yaelgilad@myrealbox.com>
	 <20030326191601.A19939@linux-mips.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1048707504.31837.44.camel@irongate.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 26 Mar 2003 19:38:24 +0000
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1815
X-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
Content-Length: 624
Lines: 17

On Wed, 2003-03-26 at 18:16, Ralf Baechle wrote:
> On Wed, Mar 26, 2003 at 08:33:21AM +0000, Gilad Benjamini wrote:
> 
> > ip_fast_csum provides an asm version for IP checksum.
> > Any available mips-asm implementation out there for 
> > a relative checksum?
> > 
> > i.e. I get a packet, change
> > a field or two, and want to compute just the 
> > change in the checksum.
> 
> I suggest to look at the code for IP masquerading which already does things
> like this when rewriting packets.

Also read the RFC material on the danger of relative checksum updates.
There are a couple of interesting gotcha's with some stacks


From ranjanp@efi.com Wed Mar 26 19:21:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Mar 2003 19:21:45 +0000 (GMT)
Received: from mail3.efi.com ([IPv6:::ffff:192.68.228.90]:16911 "HELO
	fcexgw03.efi.internal") by linux-mips.org with SMTP
	id <S8225208AbTCZTVo>; Wed, 26 Mar 2003 19:21:44 +0000
Received: from 10.3.12.13 by fcexgw03.efi.internal (InterScan E-Mail VirusWall NT); Wed, 26 Mar 2003 11:21:36 -0800
Received: by fcexbh02.efi.com with Internet Mail Service (5.5.2656.59)
	id <GY2SA7SF>; Wed, 26 Mar 2003 11:21:36 -0800
Message-ID: <D9F6B9DABA4CAE4B92850252C52383AB07968265@ex-eng-corp.efi.com>
From: Ranjan Parthasarathy <ranjanp@efi.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: [PATCH 2.4] : setup.c start_pfn wrong with CONFIG_EMBEDDED_RAMDIS
	K enabled
Date: Wed, 26 Mar 2003 11:21:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C2F3CC.E9673BD0"
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: 1816
X-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
Content-Length: 1763
Lines: 60

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_000_01C2F3CC.E9673BD0
Content-Type: text/plain;
	charset="iso-8859-1"

> I would like to submit the following change to arch/mips/kernel/setup.c.
> The start_pfn is not correct in case CONFIG_EMBEDDED_RAMDISK is slected.
> The ramdisk pages are added twice.
> 
> The diff -Naur output is attached to the mail.
> 
> Thanks
> 
> Ranjan
> 
>  <<diff.output.txt>> 

------_=_NextPart_000_01C2F3CC.E9673BD0
Content-Type: text/plain;
	name="diff.output.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="diff.output.txt"

diff -Naur linux-dev/arch/mips/kernel/setup.c =
linux-dev-patch/arch/mips/kernel/setup.c=0A=
--- linux-dev/arch/mips/kernel/setup.c	Wed Dec 18 15:40:14 2002=0A=
+++ linux-dev-patch/arch/mips/kernel/setup.c	Mon Mar 24 16:13:07 =
2003=0A=
@@ -255,6 +255,16 @@=0A=
 	int i;=0A=
 =0A=
 #ifdef CONFIG_BLK_DEV_INITRD=0A=
+#ifdef CONFIG_EMBEDDED_RAMDISK=0A=
+	/*=0A=
+	 * Embedded ramdisk -> _end after the ramdisk so no need to add =
these=0A=
+	 * pages again=0A=
+	 *=0A=
+	 * Partially used pages are not usable - thus=0A=
+	 * we are rounding upwards.=0A=
+	 */=0A=
+	start_pfn =3D PFN_UP(__pa(&_end));=0A=
+#else=0A=
 	tmp =3D (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - 8;=0A=
 	if (tmp < (unsigned long)&_end)=0A=
 		tmp +=3D PAGE_SIZE;=0A=
@@ -264,6 +274,7 @@=0A=
 		initrd_end =3D initrd_start + initrd_header[1];=0A=
 	}=0A=
 	start_pfn =3D PFN_UP(__pa((&_end)+(initrd_end - initrd_start) + =
PAGE_SIZE));=0A=
+#endif=0A=
 #else=0A=
 	/*=0A=
 	 * Partially used pages are not usable - thus=0A=

------_=_NextPart_000_01C2F3CC.E9673BD0--

From le.mail@adelphia.net Wed Mar 26 20:35:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Mar 2003 20:35:31 +0000 (GMT)
Received: from p508B68B0.dip.t-dialin.net ([IPv6:::ffff:80.139.104.176]:37074
	"EHLO p508B68B0.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8224827AbTCZUf2>; Wed, 26 Mar 2003 20:35:28 +0000
Received: from mta4-0.mail.adelphia.net ([IPv6:::ffff:64.8.50.184]:22733 "EHLO
	mta4.adelphia.net") by ralf.linux-mips.org with ESMTP
	id <S868139AbTCZUf0>; Wed, 26 Mar 2003 21:35:26 +0100
Received: from adelphia.net ([24.51.82.174]) by mta4.adelphia.net
          (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP
          id <20030326203509.TGVR26682.mta4.adelphia.net@adelphia.net>
          for <linux-mips@linux-mips.org>; Wed, 26 Mar 2003 15:35:09 -0500
Date: Wed, 26 Mar 2003 15:35:08 -0500
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: need referral
From: le <le.mail@adelphia.net>
To: linux-mips@linux-mips.org
Content-Transfer-Encoding: 7bit
Message-Id: <6F7DFAFC-5FCA-11D7-A85F-00039313A424@adelphia.net>
X-Mailer: Apple Mail (2.551)
Return-Path: <le.mail@adelphia.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: 1817
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: le.mail@adelphia.net
Precedence: bulk
X-list: linux-mips
Content-Length: 1170
Lines: 34

Hello all,

I am a newbie who has been lurking on this board for a short while and
I can tell I'm in over my technical head.

I'd like a referral to a list serv that would help me to refurbish
a 1993 R4600PC Indy with 1995 Sony GDM-17E11 monitor which I've recently
acquired.

It has two internal SCSI HD, no FDD and no CD. The Irix OS is damaged 
and the system doesn't boot.
I've rigged an old Apple external CD to the SCSI bus and can access the
Irix CD system disks from it. The unit has 4x8MB RAM, 8 bit Indy color 
graphics and a web cam included.

Some questions:
What are some good uses for this old unit? I have another machine as my 
primary computer.
I hope to use it for web browsing and image manipulation.
It must work on my 10/100 Mbps LAN and be accessible from a local Mac 
OS 10.2.4 G4.
Should I reinstall Irix 5.3 or upgrade to Irix 6.2.  I have CDs for 
both.
I would rather install some linux flavor on this machine instead, due 
to the availability of software.
If so, what distro? debian, Red Hat, other?

If you could point me in the direction of a list-serv that deals with 
this level of question, I would be
greatly appreciative.

Thanks
lee


From ppopov@mvista.com Wed Mar 26 20:38:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Mar 2003 20:38:27 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:50427 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224827AbTCZUi0>;
	Wed, 26 Mar 2003 20:38:26 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA18108;
	Wed, 26 Mar 2003 12:38:22 -0800
Subject: Re: au1500 mm problems?
From: Pete Popov <ppopov@mvista.com>
To: Bruno Randolf <br1@4g-systems.de>
Cc: linux-mips@linux-mips.org
In-Reply-To: <200303261854.10478.br1@4g-systems.de>
References: <200303261854.10478.br1@4g-systems.de>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1048711127.23483.188.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 26 Mar 2003 12:38:47 -0800
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: 1818
X-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
Content-Length: 1175
Lines: 30


> i am regularily getting the following 2 types of kernel oopses on my au1500 
> based board (mycable XXS), whenever i try to do something more demanding to 
> the CPU (like compiling):
> 
> Unhandled kernel unaligned access in unaligned.c::emulate_load_store_insn,
> line 481:
> 
> Unable to handle kernel paging request at virtual address 02000014, epc ==
> 80137554, ra == 4
> Oops in fault.c::do_page_fault, line 205:
> 
> do you have any suggestions for me what could be causes for these? 

Natively compiling large apps or the kernel seems to really stress the
hardware and the software. The last time I had a problem with native
compiles resulting in similar crashes, it turned out to be a CPU
hardware bug, which has long been fixed since then.

> i have 64MB ram and my root filesystem mounted over NFS. branch linux_2_4 a 
> few weeks ago. i can provide you with the complete oops if that would help.
> 
> btw: i cant use petes 36bit patch on the latest linux_2_4 branch anymore - it 
> always gives me a "Reserved instruction in kernel code in traps.c::do_ri, 
> line 654:" when i boot the kernel.

Hmm, I'll test it on the Db board and see what happened.

Pete


From quintela@mandrakesoft.com Thu Mar 27 02:53:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:53:35 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:9859 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8224827AbTC0Cxd>;
	Thu, 27 Mar 2003 02:53:33 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id D8DC546A4B; Thu, 27 Mar 2003 03:52:05 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: Make IP22 compile without newport
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:52:05 +0100
Message-ID: <m2u1dped2i.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1819
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3833
Lines: 125


Hi

Make sgi-ip22 compile without newport support.  Users that don't have
a graphic card (or an unsupported graphics card) don't need it.

Once there, I remove a duplicated call to gfx_register().

TODO: shmiq.o can also be removed when you don't have setup
     CONFIG_NEWPORT_CONSOLE or CONFIG_NEWPORT_GFX.  But they have an
     incestous relation with this file.

Later, Juan.

 build/arch/mips/sgi-ip22/ip22-setup.c |    3 ++-
 build/drivers/char/misc.c             |    5 -----
 build/drivers/sgi/char/Makefile       |    5 +++--
 build/drivers/sgi/char/shmiq.c        |   11 +++++++++--
 4 files changed, 14 insertions(+), 10 deletions(-)

diff -puN build/arch/mips/sgi-ip22/ip22-setup.c~newport build/arch/mips/sgi-ip22/ip22-setup.c
--- 24/build/arch/mips/sgi-ip22/ip22-setup.c~newport	2003-03-26 17:53:58.000000000 +0100
+++ 24-quintela/build/arch/mips/sgi-ip22/ip22-setup.c	2003-03-26 17:53:58.000000000 +0100
@@ -142,8 +142,9 @@ void __init ip22_setup(void)
 	/* Now enable boardcaches, if any. */
 	indy_sc_init();
 #endif
+#ifdef CONFIG_VT
 	conswitchp = NULL;
-
+#endif
 	/* Set the IO space to some sane value */
 	set_io_port_base (KSEG1ADDR (0x00080000));
 
diff -puN build/drivers/sgi/char/Makefile~newport build/drivers/sgi/char/Makefile
--- 24/build/drivers/sgi/char/Makefile~newport	2003-03-26 17:53:58.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/Makefile	2003-03-26 18:53:50.000000000 +0100
@@ -10,10 +10,11 @@
 O_TARGET := sgichar.o
 
 export-objs	:= newport.o rrm.o shmiq.o sgicons.o usema.o rrm.o
-obj-y		:= newport.o shmiq.o sgicons.o usema.o streamable.o
+obj-y		:= shmiq.o
 
 obj-$(CONFIG_IP22_SERIAL)	+= sgiserial.o
+obj-$(CONFIG_SGI_NEWPORT_CONSOLE)	+= newport.o streamable.o
 obj-$(CONFIG_SGI_DS1286)	+= ds1286.o
-obj-$(CONFIG_SGI_NEWPORT_GFX)	+= graphics.o rrm.o
+obj-$(CONFIG_SGI_NEWPORT_GFX)	+= sgicons.o graphics.o rrm.o usema.o
 
 include $(TOPDIR)/Rules.make
diff -puN build/drivers/sgi/char/shmiq.c~newport build/drivers/sgi/char/shmiq.c
--- 24/build/drivers/sgi/char/shmiq.c~newport	2003-03-26 17:53:58.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/shmiq.c	2003-03-26 18:40:12.000000000 +0100
@@ -166,6 +166,7 @@ shmiq_forget_file (unsigned long fdes)
 	return 0;
 }
 
+#ifdef CONFIG_SGI_NEWPORT_GFX
 static int
 shmiq_sioc (int device, int cmd, struct strioctl *s)
 {
@@ -194,12 +195,12 @@ shmiq_sioc (int device, int cmd, struct 
 	printk ("Unknown I_STR request for shmiq device: 0x%x\n", cmd);
 	return -EINVAL;
 }
+#endif /* CONFIG_SGI_NEWPORT_GFX */
 
 static int
 shmiq_ioctl (struct inode *inode, struct file *f, unsigned int cmd, unsigned long arg)
 {
 	struct file *file;
-	struct strioctl sioc;
 	int v;
 
 	switch (cmd){
@@ -226,7 +227,10 @@ shmiq_ioctl (struct inode *inode, struct
 		v = shmiq_forget_file (arg);
 		return v;
 
-	case I_STR:
+#ifdef CONFIG_SGI_NEWPORT_GFX
+	case I_STR: {
+		struct strioctl sioc;
+
 		v = get_sioc (&sioc, arg);
 		if (v)
 			return v;
@@ -234,6 +238,8 @@ shmiq_ioctl (struct inode *inode, struct
 		/* FIXME: This forces device = 0 */
 		return shmiq_sioc (0, sioc.ic_cmd, &sioc);
 	}
+#endif
+	}
 
 	return -EINVAL;
 
@@ -471,3 +477,4 @@ shmiq_init (void)
 }
 
 EXPORT_SYMBOL(shmiq_init);
+EXPORT_SYMBOL(shmiq_push_event);
diff -puN build/drivers/char/misc.c~newport build/drivers/char/misc.c
--- 24/build/drivers/char/misc.c~newport	2003-03-26 17:53:58.000000000 +0100
+++ 24-quintela/build/drivers/char/misc.c	2003-03-26 17:53:58.000000000 +0100
@@ -266,12 +266,7 @@ int __init misc_init(void)
 	pmu_device_init();
 #endif
 #ifdef CONFIG_SGI_NEWPORT_GFX
-	gfx_register ();
-#endif
-#ifdef CONFIG_SGI_IP22
 	streamable_init ();
-#endif
-#ifdef CONFIG_SGI_NEWPORT_GFX
 	gfx_register ();
 #endif
 #ifdef CONFIG_TOSHIBA

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:53:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:53:55 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:10371 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225195AbTC0Cxn>;
	Thu, 27 Mar 2003 02:53:43 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 5761646A59; Thu, 27 Mar 2003 03:52:16 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: Remove unneded conditional
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:52:16 +0100
Message-ID: <m2r88ted27.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1820
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1072
Lines: 30

 build/arch/mips/math-emu/sp_sub.c |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff -puN build/arch/mips/math-emu/sp_sub.c~consolidate_conditional build/arch/mips/math-emu/sp_sub.c
--- 24/build/arch/mips/math-emu/sp_sub.c~consolidate_conditional	2003-03-19 23:32:43.000000000 +0100
+++ 24-quintela/build/arch/mips/math-emu/sp_sub.c	2003-03-19 23:33:57.000000000 +0100
@@ -167,12 +167,11 @@ ieee754sp ieee754sp_sub(ieee754sp x, iee
 			xe = xe;
 			xs = ys;
 		}
-		if (xm == 0) {
-			if (ieee754_csr.rm == IEEE754_RD)
-				return ieee754sp_zero(1);	/* round negative inf. => sign = -1 */
-			else
-				return ieee754sp_zero(0);	/* other round modes   => sign = 1 */
-		}
+		if (xm == 0)
+			/* if IEEE754_RD round negative inf. => sign = -1
+			      other round modes              => sign = 1 */
+			return ieee754sp_zero(ieee754_csr.rm == IEEE754_RD);
+
 		/* normalize to rounding precision
 		 */
 		while ((xm >> (SP_MBITS + 3)) == 0) {

_

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:54:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:54:15 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:10883 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225196AbTC0Cxx>;
	Thu, 27 Mar 2003 02:53:53 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 7557146A59; Thu, 27 Mar 2003 03:52:26 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: remove pgd_base
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:52:26 +0100
Message-ID: <m2ptoded1x.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1821
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1410
Lines: 54


Hi

pgd_base was only used in the CONFIG_HIGHMEM.  Used constant
propagation and we are done.

Later, Juan.


 build/arch/mips/mm/init.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

diff -puN build/arch/mips/mm/init.c~remove_unused_var_init.c build/arch/mips/mm/init.c
--- 24/build/arch/mips/mm/init.c~remove_unused_var_init.c	2003-03-19 23:37:26.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/init.c	2003-03-19 23:39:06.000000000 +0100
@@ -193,7 +193,7 @@ static void __init fixrange_init (unsign
 void __init pagetable_init(void)
 {
 	unsigned long vaddr;
-	pgd_t *pgd, *pgd_base;
+	pgd_t *pgd;
 	pmd_t *pmd;
 	pte_t *pte;
 
@@ -202,20 +202,18 @@ void __init pagetable_init(void)
 	pgd_init((unsigned long)swapper_pg_dir +
 	         sizeof(pgd_t ) * USER_PTRS_PER_PGD);
 
-	pgd_base = swapper_pg_dir;
-
 #ifdef CONFIG_HIGHMEM
 	/*
 	 * Fixed mappings:
 	 */
 	vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK;
-	fixrange_init(vaddr, 0, pgd_base);
+	fixrange_init(vaddr, 0, swapper_pg_dir);
 
 	/*
 	 * Permanent kmaps:
 	 */
 	vaddr = PKMAP_BASE;
-	fixrange_init(vaddr, vaddr + PAGE_SIZE*LAST_PKMAP, pgd_base);
+	fixrange_init(vaddr, vaddr + PAGE_SIZE*LAST_PKMAP, swapper_pg_dir);
 
 	pgd = swapper_pg_dir + __pgd_offset(vaddr);
 	pmd = pmd_offset(pgd, vaddr);

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:54:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:54:35 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:11395 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225201AbTC0CyF>;
	Thu, 27 Mar 2003 02:54:05 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id EFEA546A59; Thu, 27 Mar 2003 03:52:38 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: ifdef highmem code
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:52:38 +0100
Message-ID: <m2n0jhed1l.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1822
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1192
Lines: 50


Hi
        this patch applies on top of the:
             
                [PATCH]: remove pgd_base

Later, Juan.

ifdef var names & fixrange_init function that are only needed in the
CONFIG_HIGHMEM case.


 build/arch/mips/mm/init.c |    4 ++++
 1 files changed, 4 insertions(+)

diff -puN build/arch/mips/mm/init.c~ifdef_higmem_only_code build/arch/mips/mm/init.c
--- 24/build/arch/mips/mm/init.c~ifdef_higmem_only_code	2003-03-20 00:30:37.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/init.c	2003-03-20 00:33:30.000000000 +0100
@@ -161,6 +161,7 @@ void show_mem(void)
 extern char _ftext, _etext, _fdata, _edata;
 extern char __init_begin, __init_end;
 
+#ifdef CONFIG_HIGHMEM
 static void __init fixrange_init (unsigned long start, unsigned long end,
 	pgd_t *pgd_base)
 {
@@ -189,13 +190,16 @@ static void __init fixrange_init (unsign
 		j = 0;
 	}
 }
+#endif
 
 void __init pagetable_init(void)
 {
+#ifdef CONFIG_HIGHMEM
 	unsigned long vaddr;
 	pgd_t *pgd;
 	pmd_t *pmd;
 	pte_t *pte;
+#endif
 
 	/* Initialize the entire pgd.  */
 	pgd_init((unsigned long)swapper_pg_dir);

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:54:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:54:56 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:11907 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225212AbTC0CyS>;
	Thu, 27 Mar 2003 02:54:18 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 3DE1646A59; Thu, 27 Mar 2003 03:52:51 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: sync code of dump_tlb.c between mips & mips64 vers
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:52:51 +0100
Message-ID: <m2k7eled18.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1823
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 7111
Lines: 260


Hi

Merge the non-conflicting changes between both files.

Later, Juan.

 build/arch/mips/lib/dump_tlb.c   |   65 +++++++++++++++++----------------------
 build/arch/mips64/lib/dump_tlb.c |   22 ++++++-------
 2 files changed, 39 insertions(+), 48 deletions(-)

diff -puN build/arch/mips/lib/dump_tlb.c~sync_dump_tlb.c build/arch/mips/lib/dump_tlb.c
--- 24/build/arch/mips/lib/dump_tlb.c~sync_dump_tlb.c	2003-03-21 00:28:20.000000000 +0100
+++ 24-quintela/build/arch/mips/lib/dump_tlb.c	2003-03-21 01:33:48.000000000 +0100
@@ -11,13 +11,13 @@
 #include <linux/string.h>
 
 #include <asm/bootinfo.h>
-#include <asm/cpu.h>
 #include <asm/cachectl.h>
+#include <asm/cpu.h>
 #include <asm/mipsregs.h>
 #include <asm/page.h>
 #include <asm/pgtable.h>
 
-static inline const char *msg2str(unsigned int mask)
+static inline const char *msk2str(unsigned int mask)
 {
 	switch (mask) {
 	case PM_4K:	return "4kb";
@@ -32,19 +32,18 @@ static inline const char *msg2str(unsign
 	case PM_256M:	return "256Mb";
 #endif
 	}
+	return "Unknown size";
 }
 
 void dump_tlb(int first, int last)
 {
-	int	i;
-	unsigned int pagemask, c0, c1, asid;
 	unsigned long long entrylo0, entrylo1;
-	unsigned long entryhi;
+	unsigned long entryhi, asid;
+	unsigned int pagemask, c0, c1, i;
 
 	asid = read_c0_entryhi() & 0xff;
 
-	printk("\n");
-	for(i=first;i<=last;i++) {
+	for (i = first; i <= last; i++) {
 		write_c0_index(i);
 		__asm__ __volatile__(
 			".set\tmips3\n\t"
@@ -65,26 +64,27 @@ void dump_tlb(int first, int last)
 			/*
 			 * Only print entries in use
 			 */
-			printk("Index: %2d pgmask=%s ", i, msg2str(pagemask));
+			printk("Index: %2d pgmask=%s ", i, msk2str(pagemask));
 
 			c0 = (entrylo0 >> 3) & 7;
 			c1 = (entrylo1 >> 3) & 7;
 
 			printk("va=%08lx asid=%02lx\n",
-			       (entryhi & 0xffffe000), (entryhi & 0xff));
-			printk("\t\t\t[pa=%08Lx c=%d d=%d v=%d g=%Ld]\n",
+			       (entryhi & 0xffffe000),
+			       (entryhi & 0xff));
+			printk("\t[pa=%08Lx c=%d d=%d v=%d g=%Ld]",
 			       (entrylo0 << 6) & PAGE_MASK, c0,
 			       (entrylo0 & 4) ? 1 : 0,
 			       (entrylo0 & 2) ? 1 : 0,
 			       (entrylo0 & 1));
-			printk("\t\t\t[pa=%08Lx c=%d d=%d v=%d g=%Ld]\n",
+			printk("[pa=%08Lx c=%d d=%d v=%d g=%Ld]\n",
 			       (entrylo1 << 6) & PAGE_MASK, c1,
 			       (entrylo1 & 4) ? 1 : 0,
 			       (entrylo1 & 2) ? 1 : 0,
 			       (entrylo1 & 1));
-			printk("\n");
 		}
 	}
+	printk("\n");
 
 	write_c0_entryhi(asid);
 }
@@ -109,8 +109,7 @@ void dump_tlb_wired(void)
 		"nop;nop;nop;nop;nop;nop;nop\n\t"	\
 		".set\treorder");
 
-void
-dump_tlb_addr(unsigned long addr)
+void dump_tlb_addr(unsigned long addr)
 {
 	unsigned long flags, oldpid;
 	int index;
@@ -135,45 +134,43 @@ dump_tlb_addr(unsigned long addr)
 	dump_tlb(index, index);
 }
 
-void
-dump_tlb_nonwired(void)
+void dump_tlb_nonwired(void)
 {
 	dump_tlb(read_c0_wired(), mips_cpu.tlbsize - 1);
 }
 
-void
-dump_list_process(struct task_struct *t, void *address)
+void dump_list_process(struct task_struct *t, void *address)
 {
 	pgd_t	*page_dir, *pgd;
 	pmd_t	*pmd;
 	pte_t	*pte, page;
-	unsigned int addr;
+	unsigned long addr;
 	unsigned long val;
 
-	addr = (unsigned int) address;
+	addr = (unsigned long) address;
 
-	printk("Addr                 == %08x\n", addr);
-	printk("task                 == %08p\n", t);
-	printk("task->mm             == %08p\n", t->mm);
-	//printk("tasks->mm.pgd        == %08x\n", (unsigned int) t->mm->pgd);
+	printk("Addr                 == %08lx\n", addr);
+	printk("task                 == %8p\n", t);
+	printk("task->mm             == %8p\n", t->mm);
+	//printk("tasks->mm.pgd        == %8p\n", t->mm->pgd);
 
 	if (addr > KSEG0)
 		page_dir = pgd_offset_k(0);
 	else
 		page_dir = pgd_offset(t->mm, 0);
-	printk("page_dir == %08x\n", (unsigned int) page_dir);
+	printk("page_dir == %08lx\n", (unsigned long) page_dir);
 
 	if (addr > KSEG0)
 		pgd = pgd_offset_k(addr);
 	else
 		pgd = pgd_offset(t->mm, addr);
-	printk("pgd == %08x, ", (unsigned int) pgd);
+	printk("pgd == %8p, ", pgd);
 
 	pmd = pmd_offset(pgd, addr);
-	printk("pmd == %08x, ", (unsigned int) pmd);
+	printk("pmd == %8p, ", pmd);
 
 	pte = pte_offset(pmd, addr);
-	printk("pte == %08x, ", (unsigned int) pte);
+	printk("pte == %8p, ", pte);
 
 	page = *pte;
 #ifdef CONFIG_64BIT_PHYS_ADDR
@@ -194,14 +191,12 @@ dump_list_process(struct task_struct *t,
 	printk("\n");
 }
 
-void
-dump_list_current(void *address)
+void dump_list_current(void *address)
 {
 	dump_list_process(current, address);
 }
 
-unsigned int
-vtop(void *address)
+unsigned int vtop(void *address)
 {
 	pgd_t	*pgd;
 	pmd_t	*pmd;
@@ -218,13 +213,11 @@ vtop(void *address)
 	return paddr;
 }
 
-void
-dump16(unsigned long *p)
+void dump16(unsigned long *p)
 {
 	int i;
 
-	for(i=0;i<8;i++)
-	{
+	for(i = 0; i < 8; i++) {
 		printk("*%8p = %08lx, ", p, *p); p++;
 		printk("*%8p = %08lx\n", p, *p); p++;
 	}
diff -puN build/arch/mips64/lib/dump_tlb.c~sync_dump_tlb.c build/arch/mips64/lib/dump_tlb.c
--- 24/build/arch/mips64/lib/dump_tlb.c~sync_dump_tlb.c	2003-03-21 00:42:47.000000000 +0100
+++ 24-quintela/build/arch/mips64/lib/dump_tlb.c	2003-03-21 01:13:38.000000000 +0100
@@ -29,11 +29,13 @@ static inline const char *msk2str(unsign
 	case PM_64M:	return "64Mb";
 	case PM_256M:	return "256Mb";
 	}
+	return "Unknown size";
 }
 
 void dump_tlb(int first, int last)
 {
-	unsigned long s_entryhi, entryhi, entrylo0, entrylo1, asid;
+	unsigned long entrylo0, entrylo1;
+	unsigned long s_entryhi, entryhi, asid;
 	unsigned int s_index, pagemask, c0, c1, i;
 
 	s_entryhi = read_c0_entryhi();
@@ -66,7 +68,7 @@ void dump_tlb(int first, int last)
 
 			printk("va=%011lx asid=%02lx\n",
 			       (entryhi & ~0x1fffUL),
-			       entryhi & 0xff);
+			       (entryhi & 0xff));
 			printk("\t[pa=%011lx c=%d d=%d v=%d g=%ld] ",
 			       (entrylo0 << 6) & PAGE_MASK, c0,
 			       (entrylo0 & 4) ? 1 : 0,
@@ -146,19 +148,19 @@ void dump_list_process(struct task_struc
 	addr = (unsigned long) address;
 
 	printk("Addr                 == %08lx\n", addr);
-	printk("tasks->mm.pgd        == %08lx\n", (unsigned long) t->mm->pgd);
+	printk("tasks->mm.pgd        == %8p\n", t->mm->pgd);
 
 	page_dir = pgd_offset(t->mm, 0);
 	printk("page_dir == %08lx\n", (unsigned long) page_dir);
 
 	pgd = pgd_offset(t->mm, addr);
-	printk("pgd == %08lx, ", (unsigned long) pgd);
+	printk("pgd == %8p, ", pgd);
 
 	pmd = pmd_offset(pgd, addr);
-	printk("pmd == %08lx, ", (unsigned long) pmd);
+	printk("pmd == %8p, ", pmd);
 
 	pte = pte_offset(pmd, addr);
-	printk("pte == %08lx, ", (unsigned long) pte);
+	printk("pte == %8p, ", pte);
 
 	page = *pte;
 	printk("page == %08lx\n", pte_val(page));
@@ -202,11 +204,7 @@ void dump16(unsigned long *p)
 	int i;
 
 	for(i = 0; i < 8; i++) {
-		printk("*%08lx == %08lx, ",
-		       (unsigned long)p, (unsigned long)*p);
-		p++;
-		printk("*%08lx == %08lx\n",
-		       (unsigned long)p, (unsigned long)*p);
-		p++;
+		printk("*%8p = %08lx, ", p, *p); p++;
+		printk("*%8p = %08lx\n", p, *p); p++;
 	}
 }

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:55:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:55:16 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:12419 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225213AbTC0Cyd>;
	Thu, 27 Mar 2003 02:54:33 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 3148946A59; Thu, 27 Mar 2003 03:53:07 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: Same cp0 regs are 64bits and other 32bit
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:53:07 +0100
Message-ID: <m2he9ped0s.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1824
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1415
Lines: 45


Hi

*some* cp0 regs are unsigned long, not unsigned int.

Later, Juan.


 build/arch/mips/kernel/traps.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

diff -puN build/arch/mips/kernel/traps.c~cp0_regs_are_unsigned_long build/arch/mips/kernel/traps.c
--- 24/build/arch/mips/kernel/traps.c~cp0_regs_are_unsigned_long	2003-03-25 22:35:22.000000000 +0100
+++ 24-quintela/build/arch/mips/kernel/traps.c	2003-03-25 22:36:59.000000000 +0100
@@ -788,9 +788,8 @@ asmlinkage void cache_parity_error(void)
 	unsigned int reg_val;
 
 	/* For the moment, report the problem and hang. */
-	reg_val = read_c0_errorepc();
 	printk("Cache error exception:\n");
-	printk("cp0_errorepc == %08x\n", read_c0_errorepc());
+	printk("cp0_errorepc == %08lx\n", read_c0_errorepc());
 	reg_val = read_c0_cacheerr();
 	printk("c0_cacheerr == %08x\n", reg_val);
 
@@ -809,10 +808,10 @@ asmlinkage void cache_parity_error(void)
 
 #if defined(CONFIG_CPU_MIPS32) || defined (CONFIG_CPU_MIPS64)
 	if (reg_val & (1<<22))
-		printk("DErrAddr0: 0x%08x\n", read_c0_derraddr0());
+		printk("DErrAddr0: 0x%08lx\n", read_c0_derraddr0());
 
 	if (reg_val & (1<<23))
-		printk("DErrAddr1: 0x%08x\n", read_c0_derraddr1());
+		printk("DErrAddr1: 0x%08lx\n", read_c0_derraddr1());
 #endif
 
 	panic("Can't handle the cache error!");

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:55:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:55:36 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:12931 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225219AbTC0Cyr>;
	Thu, 27 Mar 2003 02:54:47 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id C272046A59; Thu, 27 Mar 2003 03:53:20 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: move unused variable to right ifdef branch
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:53:20 +0100
Message-ID: <m2fzp9ed0f.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1825
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1270
Lines: 49


Hi

config1 was only usend inside the ifdef.  Move definition there.

Once here, make things u32 instead of unsigned int.

Later, Juan.

 build/arch/mips/mm/tlb-r4k.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff -puN build/arch/mips/mm/tlb-r4k.c~move_unused_var_tlb-r4k.c build/arch/mips/mm/tlb-r4k.c
--- 24/build/arch/mips/mm/tlb-r4k.c~move_unused_var_tlb-r4k.c	2003-03-21 02:03:48.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/tlb-r4k.c	2003-03-21 02:05:07.000000000 +0100
@@ -333,9 +333,8 @@ out:
 
 static void __init probe_tlb(unsigned long config)
 {
-	unsigned int prid, config1;
+	u32 prid = read_c0_prid() & 0xff00;
 
-	prid = read_c0_prid() & 0xff00;
 	if (prid == PRID_IMP_RM7000 || !(config & (1 << 31)))
 		/*
 		 * Not a MIPS32 complianant CPU.  Config 1 register not
@@ -345,11 +344,13 @@ static void __init probe_tlb(unsigned lo
 		return;
 
 #if defined(CONFIG_CPU_MIPS32) || defined (CONFIG_CPU_MIPS64)
-	config1 = read_c0_config1();
 	if (!((config >> 7) & 3))
 		panic("No MMU present");
-	else
+	else {
+		u32 config1 = read_c0_config1();
+
 		mips_cpu.tlbsize = ((config1 >> 25) & 0x3f) + 1;
+	}
 #endif
 }
 

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:55:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:55:56 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:13443 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225220AbTC0Cy6>;
	Thu, 27 Mar 2003 02:54:58 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 0229746A59; Thu, 27 Mar 2003 03:53:31 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: prototypes are already on hearder
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:53:30 +0100
Message-ID: <m2d6kded05.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1826
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 762
Lines: 34


Hi

This prototypes are already in gconsole.h.

Later, Juan.


 build/drivers/sgi/char/graphics.c |    6 ------
 1 files changed, 6 deletions(-)

diff -puN build/drivers/sgi/char/graphics.c~remove_unused_prototypes build/drivers/sgi/char/graphics.c
--- 24/build/drivers/sgi/char/graphics.c~remove_unused_prototypes	2003-03-22 00:51:19.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/graphics.c	2003-03-22 00:51:32.000000000 +0100
@@ -53,12 +53,6 @@ static int boards;
 
 #define GRAPHICS_CARD(inode) 0
 
-/*
-void enable_gconsole(void) {};
-void disable_gconsole(void) {};
-*/
-
-
 int
 sgi_graphics_open (struct inode *inode, struct file *file)
 {

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:56:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:56:17 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:13955 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225222AbTC0CzJ>;
	Thu, 27 Mar 2003 02:55:09 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 4058546A59; Thu, 27 Mar 2003 03:53:43 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: sgiserial 1/7: flags are unsigned long
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:53:43 +0100
Message-ID: <m2adfheczs.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1827
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1372
Lines: 49


Hi

flags should be long, not int.


 build/drivers/sgi/char/sgiserial.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff -puN build/drivers/sgi/char/sgiserial.c~sgserial_flags build/drivers/sgi/char/sgiserial.c
--- 24/build/drivers/sgi/char/sgiserial.c~sgserial_flags	2003-03-22 01:37:45.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/sgiserial.c	2003-03-22 01:43:17.000000000 +0100
@@ -886,7 +886,8 @@ static void zs_cons_put_char(char ch)
 {
 	struct sgi_zschannel *chan = zs_conschan;
 	volatile unsigned char junk;
-	int flags, loops = 0;
+	unsigned long flags;
+	int loops = 0;
 
 	save_flags(flags); cli();
 	while(((junk = chan->control) & Tx_BUF_EMP)==0 && loops < 10000) {
@@ -911,7 +912,8 @@ static void rs_put_char(struct tty_struc
 	struct sgi_zschannel *chan =
 		((struct sgi_serial *)tty->driver_data)->zs_channel;
 	volatile unsigned char junk;
-	int flags, loops = 0;
+	unsigned long flags;
+	int loops = 0;
 
 	save_flags(flags); cli();
 	while(((junk = chan->control) & Tx_BUF_EMP)==0 && loops < 10000) {
@@ -1854,7 +1856,8 @@ volatile int test_done;
 /* rs_init inits the driver */
 int rs_init(void)
 {
-	int chip, channel, i, flags;
+	unsigned long flags;
+	int chip, channel, i;
 	struct sgi_serial *info;
 
 

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:56:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:56:37 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:14467 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225225AbTC0CzQ>;
	Thu, 27 Mar 2003 02:55:16 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 6B3BA46A59; Thu, 27 Mar 2003 03:53:50 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: sgiserial 2/7 s/__INLINE__/inline/
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:53:50 +0100
Message-ID: <m28yv1eczl.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1828
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1929
Lines: 64


Hi

s/_INLINE_/inline/


 build/drivers/sgi/char/sgiserial.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff -puN build/drivers/sgi/char/sgiserial.c~sgiserial__INLINE_ build/drivers/sgi/char/sgiserial.c
--- 24/build/drivers/sgi/char/sgiserial.c~sgiserial__INLINE_	2003-03-25 22:38:06.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/sgiserial.c	2003-03-25 22:39:04.000000000 +0100
@@ -118,8 +118,6 @@ static int serial_refcount;
 #define RS_STROBE_TIME 10
 #define RS_ISR_PASS_LIMIT 256
 
-#define _INLINE_ inline
-
 static void change_speed(struct sgi_serial *info);
 
 static struct tty_struct *serial_table[NUM_CHANNELS];
@@ -387,7 +385,7 @@ static inline void rs_recv_clear(struct 
  * This routine is used by the interrupt handler to schedule
  * processing in the software interrupt portion of the driver.
  */
-static _INLINE_ void rs_sched_event(struct sgi_serial *info,
+static inline void rs_sched_event(struct sgi_serial *info,
 				    int event)
 {
 	info->event |= 1 << event;
@@ -399,7 +397,7 @@ static _INLINE_ void rs_sched_event(stru
 extern void set_async_breakpoint(unsigned int epc);
 #endif
 
-static _INLINE_ void receive_chars(struct sgi_serial *info, struct pt_regs *regs)
+static inline void receive_chars(struct sgi_serial *info, struct pt_regs *regs)
 {
 	struct tty_struct *tty = info->tty;
 	volatile unsigned char junk;
@@ -460,7 +458,7 @@ clear_and_exit:
 	return;
 }
 
-static _INLINE_ void transmit_chars(struct sgi_serial *info)
+static inline void transmit_chars(struct sgi_serial *info)
 {
 	volatile unsigned char junk;
 
@@ -518,7 +516,7 @@ clear_and_return:
 	return;
 }
 
-static _INLINE_ void status_handle(struct sgi_serial *info)
+static inline void status_handle(struct sgi_serial *info)
 {
 	volatile unsigned char junk;
 	unsigned char status;

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:56:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:56:57 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:14979 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225227AbTC0Cze>;
	Thu, 27 Mar 2003 02:55:34 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 2FBC446A59; Thu, 27 Mar 2003 03:54:08 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: sgiserial 3/7: globals are 0 initialized by default
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:54:08 +0100
Message-ID: <m27kalecz3.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1829
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 939
Lines: 30


Hi

globals are already zero initialized.


 build/drivers/sgi/char/sgiserial.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -puN build/drivers/sgi/char/sgiserial.c~sgiserial_zero_initialize build/drivers/sgi/char/sgiserial.c
--- 24/build/drivers/sgi/char/sgiserial.c~sgiserial_zero_initialize	2003-03-22 01:57:47.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/sgiserial.c	2003-03-22 01:58:00.000000000 +0100
@@ -49,8 +49,8 @@
 #define NUM_SERIAL 1     /* One chip on board. */
 #define NUM_CHANNELS (NUM_SERIAL * 2)
 
-struct sgi_zslayout *zs_chips[NUM_SERIAL] = { 0, };
-struct sgi_zschannel *zs_channels[NUM_CHANNELS] = { 0, 0, };
+struct sgi_zslayout *zs_chips[NUM_SERIAL];
+struct sgi_zschannel *zs_channels[NUM_CHANNELS];
 struct sgi_zschannel *zs_conschan;
 struct sgi_zschannel *zs_kgdbchan;
 

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:57:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:57:18 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:15491 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225228AbTC0Czo>;
	Thu, 27 Mar 2003 02:55:44 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id C6BD146A59; Thu, 27 Mar 2003 03:54:17 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: sgiserial 4/7: s/MIN/min/
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:54:17 +0100
Message-ID: <m24r5pecyu.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1830
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1867
Lines: 56


Hi

use min() instead of local defined MIN().


 build/drivers/sgi/char/sgiserial.c |   10 +++-------
 1 files changed, 3 insertions(+), 7 deletions(-)

diff -puN build/drivers/sgi/char/sgiserial.c~sgiserial_MIN build/drivers/sgi/char/sgiserial.c
--- 24/build/drivers/sgi/char/sgiserial.c~sgiserial_MIN	2003-03-22 02:02:12.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/sgiserial.c	2003-03-22 02:02:53.000000000 +0100
@@ -124,10 +124,6 @@ static struct tty_struct *serial_table[N
 static struct termios *serial_termios[NUM_CHANNELS];
 static struct termios *serial_termios_locked[NUM_CHANNELS];
 
-#ifndef MIN
-#define MIN(a,b)	((a) < (b) ? (a) : (b))
-#endif
-
 /*
  * tmp_buf is used as a temporary buffer by serial_write.  We need to
  * lock it in case the memcpy_fromfs blocks while swapping in a page,
@@ -985,7 +981,7 @@ static void rs_fair_output(void)
 		zs_cons_put_char(c);
 
 		save_flags(flags);  cli();
-		left = MIN(info->xmit_cnt, left-1);
+		left = min(info->xmit_cnt, left-1);
 	}
 
 	/* Last character is being transmitted now (hopefully). */
@@ -1014,7 +1010,7 @@ static int rs_write(struct tty_struct * 
 	save_flags(flags);
 	while (1) {
 		cli();
-		c = MIN(count, MIN(SERIAL_XMIT_SIZE - info->xmit_cnt - 1,
+		c = min(count, min(SERIAL_XMIT_SIZE - info->xmit_cnt - 1,
 				   SERIAL_XMIT_SIZE - info->xmit_head));
 		if (c <= 0)
 			break;
@@ -1022,7 +1018,7 @@ static int rs_write(struct tty_struct * 
 		if (from_user) {
 			down(&tmp_buf_sem);
 			copy_from_user(tmp_buf, buf, c);
-			c = MIN(c, MIN(SERIAL_XMIT_SIZE - info->xmit_cnt - 1,
+			c = min(c, min(SERIAL_XMIT_SIZE - info->xmit_cnt - 1,
 				       SERIAL_XMIT_SIZE - info->xmit_head));
 			memcpy(info->xmit_buf + info->xmit_head, tmp_buf, c);
 			up(&tmp_buf_sem);

_

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:57:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:57:38 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:16003 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225229AbTC0Czt>;
	Thu, 27 Mar 2003 02:55:49 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 263C846A59; Thu, 27 Mar 2003 03:54:23 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: sgiserial 5/7: remove test_done (unused variable)
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:54:23 +0100
Message-ID: <m23cl9ecyo.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1831
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 679
Lines: 28


Hi

test_done is not used in the code.


 build/drivers/sgi/char/sgiserial.c |    2 --
 1 files changed, 2 deletions(-)

diff -puN build/drivers/sgi/char/sgiserial.c~sgiserial_remove_test_done build/drivers/sgi/char/sgiserial.c
--- 24/build/drivers/sgi/char/sgiserial.c~sgiserial_remove_test_done	2003-03-22 02:07:19.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/sgiserial.c	2003-03-22 02:07:25.000000000 +0100
@@ -1845,8 +1845,6 @@ rs_cons_check(struct sgi_serial *ss, int
 	}
 }
 
-volatile int test_done;
-
 /* rs_init inits the driver */
 int rs_init(void)
 {

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:57:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:57:58 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:16515 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225230AbTC0Czz>;
	Thu, 27 Mar 2003 02:55:55 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 1511546A59; Thu, 27 Mar 2003 03:54:29 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: sgiserial 6/7: Remove declare only stuff
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:54:29 +0100
Message-ID: <m21y0tecyi.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1832
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 991
Lines: 34


Hi

This defines are not used in the driver at all.

 build/drivers/sgi/char/sgiserial.c |    8 --------
 1 files changed, 8 deletions(-)

diff -puN build/drivers/sgi/char/sgiserial.c~sgiserial_removing_unused_stuff build/drivers/sgi/char/sgiserial.c
--- 24/build/drivers/sgi/char/sgiserial.c~sgiserial_removing_unused_stuff	2003-03-24 02:15:37.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/sgiserial.c	2003-03-24 02:16:42.000000000 +0100
@@ -108,15 +108,7 @@ static int serial_refcount;
 /* number of characters left in xmit buffer before we ask for more */
 #define WAKEUP_CHARS 256
 
-/* Debugging... DEBUG_INTR is bad to use when one of the zs
- * lines is your console ;(
- */
-#undef SERIAL_DEBUG_INTR
 #undef SERIAL_DEBUG_OPEN
-#undef SERIAL_DEBUG_FLOW
-
-#define RS_STROBE_TIME 10
-#define RS_ISR_PASS_LIMIT 256
 
 static void change_speed(struct sgi_serial *info);
 

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:58:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:58:18 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:17027 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225232AbTC0C4C>;
	Thu, 27 Mar 2003 02:56:02 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 0245346A59; Thu, 27 Mar 2003 03:54:34 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: Better handling of PG_dcache_dirty
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:54:34 +0100
Message-ID: <m2znnhcydx.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1833
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 6106
Lines: 157


Hi

Use coherent names:
    s/Page_dcache_dirty/PageDcacheDirty/
And remove WO pg_flags variable (too much copy & paste from sparc64).

Later, Juan.


 build/arch/mips/mm/c-mips32.c      |    3 +--
 build/arch/mips/mm/c-r4k.c         |    3 +--
 build/arch/mips/mm/c-r5432.c       |    3 +--
 build/arch/mips/mm/c-tx39.c        |    3 +--
 build/arch/mips/mm/c-tx49.c        |    3 +--
 build/arch/mips64/mm/c-mips64.c    |    3 +--
 build/arch/mips64/mm/c-r4k.c       |    3 +--
 build/include/asm-mips/pgtable.h   |    2 +-
 build/include/asm-mips64/pgtable.h |    2 +-
 9 files changed, 9 insertions(+), 16 deletions(-)

diff -puN build/include/asm-mips/pgtable.h~PG_dcache_dirty build/include/asm-mips/pgtable.h
--- 24/build/include/asm-mips/pgtable.h~PG_dcache_dirty	2003-03-27 02:25:51.000000000 +0100
+++ 24-quintela/build/include/asm-mips/pgtable.h	2003-03-27 02:26:35.000000000 +0100
@@ -70,7 +70,7 @@ extern void (*_flush_icache_all)(void);
  */
 #define PG_dcache_dirty			PG_arch_1
 
-#define Page_dcache_dirty(page)		\
+#define PageDcacheDirty(page)		\
 	test_bit(PG_dcache_dirty, &(page)->flags)
 #define SetPageDcacheDirty(page)	\
 	set_bit(PG_dcache_dirty, &(page)->flags)
diff -puN build/include/asm-mips64/pgtable.h~PG_dcache_dirty build/include/asm-mips64/pgtable.h
--- 24/build/include/asm-mips64/pgtable.h~PG_dcache_dirty	2003-03-27 02:25:54.000000000 +0100
+++ 24-quintela/build/include/asm-mips64/pgtable.h	2003-03-27 02:26:09.000000000 +0100
@@ -77,7 +77,7 @@ extern void (*_flush_icache_all)(void);
  */
 #define PG_dcache_dirty			PG_arch_1
 
-#define Page_dcache_dirty(page)		\
+#define PageDcacheDirty(page)		\
 	test_bit(PG_dcache_dirty, &(page)->flags)
 #define SetPageDcacheDirty(page)	\
 	set_bit(PG_dcache_dirty, &(page)->flags)
diff -puN build/arch/mips64/mm/c-r4k.c~PG_dcache_dirty build/arch/mips64/mm/c-r4k.c
--- 24/build/arch/mips64/mm/c-r4k.c~PG_dcache_dirty	2003-03-27 02:27:38.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/c-r4k.c	2003-03-27 02:56:24.000000000 +0100
@@ -1085,10 +1085,9 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
 	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	    PageDcacheDirty(page)) {
 		r4k_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips64/mm/c-mips64.c~PG_dcache_dirty build/arch/mips64/mm/c-mips64.c
--- 24/build/arch/mips64/mm/c-mips64.c~PG_dcache_dirty	2003-03-27 02:27:40.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/c-mips64.c	2003-03-27 02:56:18.000000000 +0100
@@ -425,10 +425,9 @@ void __update_cache(struct vm_area_struc
         pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
 	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	    PageDcacheDirty(page)) {
 		mips64_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips/mm/c-mips32.c~PG_dcache_dirty build/arch/mips/mm/c-mips32.c
--- 24/build/arch/mips/mm/c-mips32.c~PG_dcache_dirty	2003-03-27 02:27:54.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-mips32.c	2003-03-27 02:55:23.000000000 +0100
@@ -409,10 +409,9 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
 	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	    PageDcacheDirty(page)) {
 		mips32_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips/mm/c-r4k.c~PG_dcache_dirty build/arch/mips/mm/c-r4k.c
--- 24/build/arch/mips/mm/c-r4k.c~PG_dcache_dirty	2003-03-27 02:28:00.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r4k.c	2003-03-27 02:55:29.000000000 +0100
@@ -568,10 +568,9 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
 	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	    PageDcacheDirty(page)) {
 		r4k_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips/mm/c-r5432.c~PG_dcache_dirty build/arch/mips/mm/c-r5432.c
--- 24/build/arch/mips/mm/c-r5432.c~PG_dcache_dirty	2003-03-27 02:28:03.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r5432.c	2003-03-27 02:55:35.000000000 +0100
@@ -437,10 +437,9 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
 	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	    PageDcacheDirty(page)) {
 		r5432_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips/mm/c-tx39.c~PG_dcache_dirty build/arch/mips/mm/c-tx39.c
--- 24/build/arch/mips/mm/c-tx39.c~PG_dcache_dirty	2003-03-27 02:28:11.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-tx39.c	2003-03-27 02:55:41.000000000 +0100
@@ -323,10 +323,9 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
 	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	    PageDcacheDirty(page)) {
 		tx39_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips/mm/c-tx49.c~PG_dcache_dirty build/arch/mips/mm/c-tx49.c
--- 24/build/arch/mips/mm/c-tx49.c~PG_dcache_dirty	2003-03-27 02:28:13.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-tx49.c	2003-03-27 02:55:47.000000000 +0100
@@ -284,10 +284,9 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
 	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	    PageDcacheDirty(page)) {
 		tx49_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:58:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:58:39 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:17539 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225233AbTC0C4T>;
	Thu, 27 Mar 2003 02:56:19 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id DB98C46A59; Thu, 27 Mar 2003 03:54:52 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: missing prototype of unblank_screen
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:54:52 +0100
Message-ID: <m2y931cydf.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1834
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 681
Lines: 27


Hi

unblank_screen prototype is declared in <linux/vt_kern.h>.


 build/arch/mips/mm/fault.c |    1 +
 1 files changed, 1 insertion(+)

diff -puN build/arch/mips/mm/fault.c~missing_unblank_screen build/arch/mips/mm/fault.c
--- 24/build/arch/mips/mm/fault.c~missing_unblank_screen	2003-03-27 00:20:19.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/fault.c	2003-03-27 00:20:39.000000000 +0100
@@ -19,6 +19,7 @@
 #include <linux/smp.h>
 #include <linux/smp_lock.h>
 #include <linux/version.h>
+#include <linux/vt_kern.h>
 
 #include <asm/branch.h>
 #include <asm/hardirq.h>

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:58:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:58:59 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:18051 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225235AbTC0C4Z>;
	Thu, 27 Mar 2003 02:56:25 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id E66B746A59; Thu, 27 Mar 2003 03:54:58 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: everybody includes bcache.h
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:54:58 +0100
Message-ID: <m2wuilcyd9.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1835
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3671
Lines: 91


Hi
        on all that files, none of the things declared on bcache.h are
        used.

Later, Juan.


 build/arch/mips/ddb5xxx/ddb5074/setup.c   |    1 -
 build/arch/mips/ddb5xxx/ddb5476/setup.c   |    1 -
 build/arch/mips/ddb5xxx/ddb5477/setup.c   |    1 -
 build/arch/mips/jmr3927/rbhma3100/setup.c |    1 -
 build/arch/mips/sni/pcimt_scache.c        |    2 +-
 build/arch/mips/sni/setup.c               |    1 -
 6 files changed, 1 insertion(+), 6 deletions(-)

diff -puN build/arch/mips/ddb5xxx/ddb5074/setup.c~remove_unused_bcache.h_includes build/arch/mips/ddb5xxx/ddb5074/setup.c
--- 24/build/arch/mips/ddb5xxx/ddb5074/setup.c~remove_unused_bcache.h_includes	2003-03-27 01:32:57.000000000 +0100
+++ 24-quintela/build/arch/mips/ddb5xxx/ddb5074/setup.c	2003-03-27 01:33:30.000000000 +0100
@@ -20,7 +20,6 @@
 #include <linux/irq.h>
 
 #include <asm/addrspace.h>
-#include <asm/bcache.h>
 #include <asm/keyboard.h>
 #include <asm/irq.h>
 #include <asm/reboot.h>
diff -puN build/arch/mips/ddb5xxx/ddb5476/setup.c~remove_unused_bcache.h_includes build/arch/mips/ddb5xxx/ddb5476/setup.c
--- 24/build/arch/mips/ddb5xxx/ddb5476/setup.c~remove_unused_bcache.h_includes	2003-03-27 01:33:16.000000000 +0100
+++ 24-quintela/build/arch/mips/ddb5xxx/ddb5476/setup.c	2003-03-27 01:33:43.000000000 +0100
@@ -18,7 +18,6 @@
 #include <linux/ide.h>
 
 #include <asm/addrspace.h>
-#include <asm/bcache.h>
 #include <asm/keyboard.h>
 #include <asm/irq.h>
 #include <asm/reboot.h>
diff -puN build/arch/mips/ddb5xxx/ddb5477/setup.c~remove_unused_bcache.h_includes build/arch/mips/ddb5xxx/ddb5477/setup.c
--- 24/build/arch/mips/ddb5xxx/ddb5477/setup.c~remove_unused_bcache.h_includes	2003-03-27 01:33:24.000000000 +0100
+++ 24-quintela/build/arch/mips/ddb5xxx/ddb5477/setup.c	2003-03-27 01:33:51.000000000 +0100
@@ -28,7 +28,6 @@
 #include <asm/bootinfo.h>
 #include <asm/addrspace.h>
 #include <asm/time.h>
-#include <asm/bcache.h>
 #include <asm/irq.h>
 #include <asm/reboot.h>
 #include <asm/gdb-stub.h>
diff -puN build/arch/mips/jmr3927/rbhma3100/setup.c~remove_unused_bcache.h_includes build/arch/mips/jmr3927/rbhma3100/setup.c
--- 24/build/arch/mips/jmr3927/rbhma3100/setup.c~remove_unused_bcache.h_includes	2003-03-27 01:34:39.000000000 +0100
+++ 24-quintela/build/arch/mips/jmr3927/rbhma3100/setup.c	2003-03-27 01:34:43.000000000 +0100
@@ -49,7 +49,6 @@
 
 #include <asm/addrspace.h>
 #include <asm/time.h>
-#include <asm/bcache.h>
 #include <asm/irq.h>
 #include <asm/reboot.h>
 #include <asm/gdb-stub.h>
diff -puN build/arch/mips/sgi-ip22/ip22-setup.c~remove_unused_bcache.h_includes build/arch/mips/sgi-ip22/ip22-setup.c
diff -puN build/arch/mips/sni/setup.c~remove_unused_bcache.h_includes build/arch/mips/sni/setup.c
--- 24/build/arch/mips/sni/setup.c~remove_unused_bcache.h_includes	2003-03-27 01:36:36.000000000 +0100
+++ 24-quintela/build/arch/mips/sni/setup.c	2003-03-27 01:37:39.000000000 +0100
@@ -22,7 +22,6 @@
 #include <linux/pc_keyb.h>
 #include <linux/ide.h>
 
-#include <asm/bcache.h>
 #include <asm/bootinfo.h>
 #include <asm/keyboard.h>
 #include <asm/io.h>
diff -puN build/arch/mips/sni/pcimt_scache.c~remove_unused_bcache.h_includes build/arch/mips/sni/pcimt_scache.c
--- 24/build/arch/mips/sni/pcimt_scache.c~remove_unused_bcache.h_includes	2003-03-27 01:37:26.000000000 +0100
+++ 24-quintela/build/arch/mips/sni/pcimt_scache.c	2003-03-27 01:37:32.000000000 +0100
@@ -9,7 +9,7 @@
  */
 #include <linux/init.h>
 #include <linux/kernel.h>
-#include <asm/bcache.h>
+
 #include <asm/sni.h>
 
 #define cacheconf (*(volatile unsigned int *)PCIMT_CACHECONF)

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Thu Mar 27 02:59:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 02:59:19 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:18563 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225236AbTC0C4d>;
	Thu, 27 Mar 2003 02:56:33 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id C2CF546A59; Thu, 27 Mar 2003 03:55:03 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: sgiserial 7/7: ->pendregs is a WOV
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Thu, 27 Mar 2003 03:55:03 +0100
Message-ID: <m2vfy5cyd4.fsf@mandrakesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1836
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 6900
Lines: 214


Hi

->peonages[] array is a WO variable.


 build/drivers/sgi/char/sgiserial.c |   49 ++++++-------------------------------
 build/drivers/sgi/char/sgiserial.h |    3 --
 2 files changed, 8 insertions(+), 44 deletions(-)

diff -puN build/drivers/sgi/char/sgiserial.c~sgiserial_remove_pendregs build/drivers/sgi/char/sgiserial.c
--- 24/build/drivers/sgi/char/sgiserial.c~sgiserial_remove_pendregs	2003-03-26 18:54:23.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/sgiserial.c	2003-03-26 18:54:23.000000000 +0100
@@ -223,11 +223,9 @@ static inline void zs_rtsdtr(struct sgi_
 {
 	if(set) {
 		ss->curregs[5] |= (RTS | DTR);
-		ss->pendregs[5] = ss->curregs[5];
 		write_zsreg(ss->zs_channel, 5, ss->curregs[5]);
 	} else {
 		ss->curregs[5] &= ~(RTS | DTR);
-		ss->pendregs[5] = ss->curregs[5];
 		write_zsreg(ss->zs_channel, 5, ss->curregs[5]);
 	}
 	return;
@@ -285,7 +283,6 @@ static void rs_stop(struct tty_struct *t
 	save_flags(flags); cli();
 	if (info->curregs[5] & TxENAB) {
 		info->curregs[5] &= ~TxENAB;
-		info->pendregs[5] &= ~TxENAB;
 		write_zsreg(info->zs_channel, 5, info->curregs[5]);
 	}
 	restore_flags(flags);
@@ -302,7 +299,6 @@ static void rs_start(struct tty_struct *
 	save_flags(flags); cli();
 	if (info->xmit_cnt && info->xmit_buf && !(info->curregs[5] & TxENAB)) {
 		info->curregs[5] |= TxENAB;
-		info->pendregs[5] = info->curregs[5];
 		write_zsreg(info->zs_channel, 5, info->curregs[5]);
 	}
 	restore_flags(flags);
@@ -527,13 +523,11 @@ static inline void status_handle(struct 
 		if((info->tty->termios->c_cflag & CRTSCTS) &&
 		   ((info->curregs[3] & AUTO_ENAB)==0)) {
 			info->curregs[3] |= AUTO_ENAB;
-			info->pendregs[3] |= AUTO_ENAB;
 			write_zsreg(info->zs_channel, 3, info->curregs[3]);
 		}
 	} else {
 		if((info->curregs[3] & AUTO_ENAB)) {
 			info->curregs[3] &= ~AUTO_ENAB;
-			info->pendregs[3] &= ~AUTO_ENAB;
 			write_zsreg(info->zs_channel, 3, info->curregs[3]);
 		}
 	}
@@ -699,14 +693,10 @@ static int startup(struct sgi_serial * i
 	 * Finally, enable sequencing and interrupts
 	 */
 	info->curregs[1] |= (info->curregs[1] & ~0x18) | (EXT_INT_ENAB|INT_ALL_Rx);
-	info->pendregs[1] = info->curregs[1];
 	info->curregs[3] |= (RxENABLE | Rx8);
-	info->pendregs[3] = info->curregs[3];
 	/* We enable Tx interrupts as needed. */
 	info->curregs[5] |= (TxENAB | Tx8);
-	info->pendregs[5] = info->curregs[5];
 	info->curregs[9] |= (NV | MIE);
-	info->pendregs[9] = info->curregs[9];
 	write_zsreg(info->zs_channel, 3, info->curregs[3]);
 	write_zsreg(info->zs_channel, 5, info->curregs[5]);
 	write_zsreg(info->zs_channel, 9, info->curregs[9]);
@@ -808,58 +798,44 @@ static void change_speed(struct sgi_seri
 	case CS5:
 		info->curregs[3] &= ~(0xc0);
 		info->curregs[3] |= Rx5;
-		info->pendregs[3] = info->curregs[3];
 		info->curregs[5] &= ~(0xe0);
 		info->curregs[5] |= Tx5;
-		info->pendregs[5] = info->curregs[5];
 		break;
 	case CS6:
 		info->curregs[3] &= ~(0xc0);
 		info->curregs[3] |= Rx6;
-		info->pendregs[3] = info->curregs[3];
 		info->curregs[5] &= ~(0xe0);
 		info->curregs[5] |= Tx6;
-		info->pendregs[5] = info->curregs[5];
 		break;
 	case CS7:
 		info->curregs[3] &= ~(0xc0);
 		info->curregs[3] |= Rx7;
-		info->pendregs[3] = info->curregs[3];
 		info->curregs[5] &= ~(0xe0);
 		info->curregs[5] |= Tx7;
-		info->pendregs[5] = info->curregs[5];
 		break;
 	case CS8:
 	default: /* defaults to 8 bits */
 		info->curregs[3] &= ~(0xc0);
 		info->curregs[3] |= Rx8;
-		info->pendregs[3] = info->curregs[3];
 		info->curregs[5] &= ~(0xe0);
 		info->curregs[5] |= Tx8;
-		info->pendregs[5] = info->curregs[5];
 		break;
 	}
 	info->curregs[4] &= ~(0x0c);
-	if (cflag & CSTOPB) {
+	if (cflag & CSTOPB)
 		info->curregs[4] |= SB2;
-	} else {
+	else
 		info->curregs[4] |= SB1;
-	}
-	info->pendregs[4] = info->curregs[4];
-	if (cflag & PARENB) {
+
+	if (cflag & PARENB)
 		info->curregs[4] |= PAR_ENA;
-		info->pendregs[4] |= PAR_ENA;
-	} else {
+	else
 		info->curregs[4] &= ~PAR_ENA;
-		info->pendregs[4] &= ~PAR_ENA;
-	}
-	if (!(cflag & PARODD)) {
+
+	if (!(cflag & PARODD))
 		info->curregs[4] |= PAR_EVEN;
-		info->pendregs[4] |= PAR_EVEN;
-	} else {
+	else
 		info->curregs[4] &= ~PAR_EVEN;
-		info->pendregs[4] &= ~PAR_EVEN;
-	}
 
 	/* Load up the new values */
 	load_zsregs(info->zs_channel, info->curregs);
@@ -1037,10 +1013,8 @@ static int rs_write(struct tty_struct * 
 	 */
 		/* Enable transmitter */
 		info->curregs[1] |= TxINT_ENAB|EXT_INT_ENAB;
-		info->pendregs[1] |= TxINT_ENAB|EXT_INT_ENAB;
 		write_zsreg(info->zs_channel, 1, info->curregs[1]);
 		info->curregs[5] |= TxENAB;
-		info->pendregs[5] |= TxENAB;
 		write_zsreg(info->zs_channel, 5, info->curregs[5]);
 
 	/*
@@ -1113,10 +1087,8 @@ static void rs_flush_chars(struct tty_st
 	/* Enable transmitter */
 	save_flags(flags); cli();
 	info->curregs[1] |= TxINT_ENAB|EXT_INT_ENAB;
-	info->pendregs[1] |= TxINT_ENAB|EXT_INT_ENAB;
 	write_zsreg(info->zs_channel, 1, info->curregs[1]);
 	info->curregs[5] |= TxENAB;
-	info->pendregs[5] |= TxENAB;
 	write_zsreg(info->zs_channel, 5, info->curregs[5]);
 
 	/*
@@ -1166,7 +1138,6 @@ static void rs_throttle(struct tty_struc
 	/* Turn off RTS line */
 	cli();
 	info->curregs[5] &= ~RTS;
-	info->pendregs[5] &= ~RTS;
 	write_zsreg(info->zs_channel, 5, info->curregs[5]);
 	sti();
 }
@@ -1194,7 +1165,6 @@ static void rs_unthrottle(struct tty_str
 	/* Assert RTS line */
 	cli();
 	info->curregs[5] |= RTS;
-	info->pendregs[5] |= RTS;
 	write_zsreg(info->zs_channel, 5, info->curregs[5]);
 	sti();
 }
@@ -1521,10 +1491,8 @@ static void rs_close(struct tty_struct *
 	 */
 	/** if (!info->iscons) ... **/
 	info->curregs[3] &= ~RxENABLE;
-	info->pendregs[3] = info->curregs[3];
 	write_zsreg(info->zs_channel, 3, info->curregs[3]);
 	info->curregs[1] &= ~(0x18);
-	info->pendregs[1] = info->curregs[1];
 	write_zsreg(info->zs_channel, 1, info->curregs[1]);
 	ZS_CLEARFIFO(info->zs_channel);
 
@@ -2245,7 +2213,6 @@ static int __init zs_console_setup(struc
 	zscons_regs[12] = brg & 0xff;
 	zscons_regs[13] = (brg >> 8) & 0xff;
 	memcpy(info->curregs, zscons_regs, sizeof(zscons_regs));
-	memcpy(info->pendregs, zscons_regs, sizeof(zscons_regs));
 	load_zsregs(info->zs_channel, zscons_regs);
 	ZS_CLEARERR(info->zs_channel);
 	ZS_CLEARFIFO(info->zs_channel);
diff -puN build/drivers/sgi/char/sgiserial.h~sgiserial_remove_pendregs build/drivers/sgi/char/sgiserial.h
--- 24/build/drivers/sgi/char/sgiserial.h~sgiserial_remove_pendregs	2003-03-26 18:54:23.000000000 +0100
+++ 24-quintela/build/drivers/sgi/char/sgiserial.h	2003-03-26 18:54:23.000000000 +0100
@@ -122,9 +122,6 @@ struct sgi_serial {
 	/* Current write register values */
 	unsigned char curregs[NUM_ZSREGS];
 
-	/* Values we need to set next opportunity */
-	unsigned char pendregs[NUM_ZSREGS];
-
 	char change_needed;
 
 	int			magic;

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From ralf@linux-mips.net Thu Mar 27 12:44:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Mar 2003 12:44:27 +0000 (GMT)
Received: from p508B6693.dip.t-dialin.net ([IPv6:::ffff:80.139.102.147]:39627
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224827AbTC0Mo0>; Thu, 27 Mar 2003 12:44:26 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2RCiG526597;
	Thu, 27 Mar 2003 13:44:16 +0100
Date: Thu, 27 Mar 2003 13:44:16 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Juan Quintela <quintela@mandrakesoft.com>
Cc: mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: sgiserial 1/7: flags are unsigned long
Message-ID: <20030327134416.B26267@linux-mips.org>
References: <m2adfheczs.fsf@mandrakesoft.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: <m2adfheczs.fsf@mandrakesoft.com>; from quintela@mandrakesoft.com on Thu, Mar 27, 2003 at 03:53:43AM +0100
Return-Path: <ralf@linux-mips.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: 1837
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 639
Lines: 15

On Thu, Mar 27, 2003 at 03:53:43AM +0100, Juan Quintela wrote:

> Subject: [PATCH]: sgiserial 1/7: flags are unsigned long

I applied the whole series of sgiserial patches.

I'm tired of maintaining the dead support for running IRIX's X server on
Linux.  It was never working more than marginally and since Miguel de
Icaza has given up working on that in favor of Gnome the code is just a
maintenance pain.  Worse, probably there's haven a dozen bad bugs hidden
in there allowing users to crash the system or do other sinister stuff.
So if you want to continue your cleanup cruzade by eleminating
drivers/sgi/ - I'm all for it :-)

  Ralf

From quintela@mandrakesoft.com Fri Mar 28 00:52:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:52:54 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:3461 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8224827AbTC1Aww>;
	Fri, 28 Mar 2003 00:52:52 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 2305C46BA4; Fri, 28 Mar 2003 01:51:20 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: no way to build pg.o
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:51:20 +0100
Message-ID: <m265q4b9fb.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1838
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 811
Lines: 30


Hi
	There is no file from which generate pg.o

Later, Juan.



 build/arch/mips/mm/Makefile |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN build/arch/mips/mm/Makefile~pg.c_dont_exist build/arch/mips/mm/Makefile
--- 24/build/arch/mips/mm/Makefile~pg.c_dont_exist	2003-03-28 00:19:04.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/Makefile	2003-03-28 00:19:18.000000000 +0100
@@ -12,7 +12,7 @@ O_TARGET := mm.o
 
 export-objs			+= ioremap.o loadmmu.o
 obj-y				+= extable.o init.o ioremap.o fault.o \
-				   pg.o loadmmu.o
+				   loadmmu.o
 
 obj-$(CONFIG_CPU_R3000)		+= pg-r3k.o c-r3k.o tlb-r3k.o tlbex-r3k.o
 obj-$(CONFIG_CPU_TX39XX)	+= pg-r3k.o c-tx39.o tlb-r3k.o tlbex-r3k.o

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Mar 28 00:53:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:53:14 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:3973 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225072AbTC1AxB>;
	Fri, 28 Mar 2003 00:53:01 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id CA98246BA6; Fri, 28 Mar 2003 01:51:32 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: add .cvsignore
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:51:32 +0100
Message-ID: <m23cl8b9ez.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1839
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 554
Lines: 27


Hi
	this is the same .cvsignore than for the 32bits branch.

Later, Juan.


 build/arch/mips64/boot/.cvsignore |    6 ++++++
 1 files changed, 6 insertions(+)

diff -puN /dev/null build/arch/mips64/boot/.cvsignore
--- /dev/null	1970-01-01 01:00:00.000000000 +0100
+++ 24-quintela/build/arch/mips64/boot/.cvsignore	2003-03-28 00:27:04.000000000 +0100
@@ -0,0 +1,6 @@
+.depend
+.*.flags
+mkboot zImage zImage.tmp
+addinitrd
+elf2ecoff
+vmlinux.ecoff

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Mar 28 00:53:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:53:34 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:4485 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225195AbTC1AxG>;
	Fri, 28 Mar 2003 00:53:06 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 14AB946BA6; Fri, 28 Mar 2003 01:51:38 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: cswitch not defined if !CONFIG_VT
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:51:38 +0100
Message-ID: <m21y0sb9et.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1840
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 838
Lines: 31


Hi
	cswitch is only used when CONFIG_VT is defined.

Later, Juan.


 build/arch/mips/sgi-ip22/ip22-setup.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

diff -puN build/arch/mips/sgi-ip22/ip22-setup.c~cswitch_only_needed_by_VT build/arch/mips/sgi-ip22/ip22-setup.c
--- 24/build/arch/mips/sgi-ip22/ip22-setup.c~cswitch_only_needed_by_VT	2003-03-28 00:15:26.000000000 +0100
+++ 24-quintela/build/arch/mips/sgi-ip22/ip22-setup.c	2003-03-28 00:15:50.000000000 +0100
@@ -142,8 +142,9 @@ void __init ip22_setup(void)
 	/* Now enable boardcaches, if any. */
 	indy_sc_init();
 #endif
+#ifdef CONFIG_VT
 	conswitchp = NULL;
-
+#endif
 	/* Set the IO space to some sane value */
 	set_io_port_base (KSEG1ADDR (0x00080000));
 

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Mar 28 00:53:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:53:54 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:4997 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225196AbTC1AxR>;
	Fri, 28 Mar 2003 00:53:17 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 1B93C46BA6; Fri, 28 Mar 2003 01:51:46 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: PG_cache_dirty (take 2)
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:51:46 +0100
Message-ID: <m2znng9uu5.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1841
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 6319
Lines: 155




Use coherent names:
    s/Page_dcache_dirty/PageDcacheDirty/
And remove WO pg_flags variable.


 build/arch/mips/mm/c-mips32.c      |    4 +---
 build/arch/mips/mm/c-r4k.c         |    4 +---
 build/arch/mips/mm/c-r5432.c       |    4 +---
 build/arch/mips/mm/c-tx39.c        |    4 +---
 build/arch/mips/mm/c-tx49.c        |    4 +---
 build/arch/mips64/mm/c-mips64.c    |    4 +---
 build/arch/mips64/mm/c-r4k.c       |    4 +---
 build/include/asm-mips/pgtable.h   |    2 +-
 build/include/asm-mips64/pgtable.h |    2 +-
 9 files changed, 9 insertions(+), 23 deletions(-)

diff -puN build/include/asm-mips/pgtable.h~PG_dcache_dirty build/include/asm-mips/pgtable.h
--- 24/build/include/asm-mips/pgtable.h~PG_dcache_dirty	2003-03-28 00:36:50.000000000 +0100
+++ 24-quintela/build/include/asm-mips/pgtable.h	2003-03-28 00:36:50.000000000 +0100
@@ -70,7 +70,7 @@ extern void (*_flush_icache_all)(void);
  */
 #define PG_dcache_dirty			PG_arch_1
 
-#define Page_dcache_dirty(page)		\
+#define PageDcacheDirty(page)		\
 	test_bit(PG_dcache_dirty, &(page)->flags)
 #define SetPageDcacheDirty(page)	\
 	set_bit(PG_dcache_dirty, &(page)->flags)
diff -puN build/include/asm-mips64/pgtable.h~PG_dcache_dirty build/include/asm-mips64/pgtable.h
--- 24/build/include/asm-mips64/pgtable.h~PG_dcache_dirty	2003-03-28 00:36:50.000000000 +0100
+++ 24-quintela/build/include/asm-mips64/pgtable.h	2003-03-28 00:36:50.000000000 +0100
@@ -77,7 +77,7 @@ extern void (*_flush_icache_all)(void);
  */
 #define PG_dcache_dirty			PG_arch_1
 
-#define Page_dcache_dirty(page)		\
+#define PageDcacheDirty(page)		\
 	test_bit(PG_dcache_dirty, &(page)->flags)
 #define SetPageDcacheDirty(page)	\
 	set_bit(PG_dcache_dirty, &(page)->flags)
diff -puN build/arch/mips64/mm/c-r4k.c~PG_dcache_dirty build/arch/mips64/mm/c-r4k.c
--- 24/build/arch/mips64/mm/c-r4k.c~PG_dcache_dirty	2003-03-28 00:36:50.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/c-r4k.c	2003-03-28 00:36:50.000000000 +0100
@@ -1085,10 +1085,8 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	if (VALID_PAGE(page) && page->mapping && PageDcacheDirty(page)) {
 		r4k_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips64/mm/c-mips64.c~PG_dcache_dirty build/arch/mips64/mm/c-mips64.c
--- 24/build/arch/mips64/mm/c-mips64.c~PG_dcache_dirty	2003-03-28 00:36:50.000000000 +0100
+++ 24-quintela/build/arch/mips64/mm/c-mips64.c	2003-03-28 00:36:50.000000000 +0100
@@ -440,10 +440,8 @@ void __update_cache(struct vm_area_struc
         pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	if (VALID_PAGE(page) && page->mapping && PageDcacheDirty(page)) {
 		mips64_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips/mm/c-mips32.c~PG_dcache_dirty build/arch/mips/mm/c-mips32.c
--- 24/build/arch/mips/mm/c-mips32.c~PG_dcache_dirty	2003-03-28 00:36:50.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-mips32.c	2003-03-28 00:36:50.000000000 +0100
@@ -423,10 +423,8 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	if (VALID_PAGE(page) && page->mapping && PageDcacheDirty(page)) {
 		mips32_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips/mm/c-r4k.c~PG_dcache_dirty build/arch/mips/mm/c-r4k.c
--- 24/build/arch/mips/mm/c-r4k.c~PG_dcache_dirty	2003-03-28 00:36:50.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r4k.c	2003-03-28 00:36:50.000000000 +0100
@@ -582,10 +582,8 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	if (VALID_PAGE(page) && page->mapping && PageDcacheDirty(page)) {
 		r4k_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips/mm/c-r5432.c~PG_dcache_dirty build/arch/mips/mm/c-r5432.c
--- 24/build/arch/mips/mm/c-r5432.c~PG_dcache_dirty	2003-03-28 00:36:50.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r5432.c	2003-03-28 00:36:50.000000000 +0100
@@ -437,10 +437,8 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	if (VALID_PAGE(page) && page->mapping && PageDcacheDirty(page)) {
 		r5432_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips/mm/c-tx39.c~PG_dcache_dirty build/arch/mips/mm/c-tx39.c
--- 24/build/arch/mips/mm/c-tx39.c~PG_dcache_dirty	2003-03-28 00:36:50.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-tx39.c	2003-03-28 00:37:05.000000000 +0100
@@ -323,10 +323,8 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	if (VALID_PAGE(page) && page->mapping && PageDcacheDirty(page)) {
 		tx39_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);
diff -puN build/arch/mips/mm/c-tx49.c~PG_dcache_dirty build/arch/mips/mm/c-tx49.c
--- 24/build/arch/mips/mm/c-tx49.c~PG_dcache_dirty	2003-03-28 00:36:50.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-tx49.c	2003-03-28 00:36:50.000000000 +0100
@@ -284,10 +284,8 @@ void __update_cache(struct vm_area_struc
 	pte_t pte)
 {
 	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
 
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
+	if (VALID_PAGE(page) && page->mapping && PageDcacheDirty(page)) {
 		tx49_flush_dcache_page_impl(page);
 
 		ClearPageDcacheDirty(page);

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Mar 28 00:54:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:54:14 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:5509 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225199AbTC1Ax0>;
	Fri, 28 Mar 2003 00:53:26 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 88E6C46BA6; Fri, 28 Mar 2003 01:51:57 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: c-r4k.c 1/7 s/switch/formula/
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:51:57 +0100
Message-ID: <m2y9309utu.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1842
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 950
Lines: 42


Hi
	use the same calculation for sc_size as in every other *_size.

Later, Juan.


 build/arch/mips/mm/c-r4k.c |   15 +--------------
 1 files changed, 1 insertion(+), 14 deletions(-)

diff -puN build/arch/mips/mm/c-r4k.c~c-r4k_remove_switch build/arch/mips/mm/c-r4k.c
--- 24/build/arch/mips/mm/c-r4k.c~c-r4k_remove_switch	2003-03-28 00:33:48.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r4k.c	2003-03-28 00:33:48.000000000 +0100
@@ -635,20 +635,7 @@ static int __init probe_scache(unsigned 
 	if ((config >> 17) & 1)
 		return 0;
 
-	switch ((config >> 22) & 3) {
-	case 0:
-		sc_lsize = 16;
-		break;
-	case 1:
-		sc_lsize = 32;
-		break;
-	case 2:
-		sc_lsize = 64;
-		break;
-	case 3:
-		sc_lsize = 128;
-		break;
-	}
+	sc_lsize = 16 << ((config >> 22) & 3);
 
 	begin = (unsigned long) &stext;
 	begin &= ~((4 * 1024 * 1024) - 1);

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Mar 28 00:54:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:54:34 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:6021 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225200AbTC1Axd>;
	Fri, 28 Mar 2003 00:53:33 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 6A89A46BA6; Fri, 28 Mar 2003 01:52:04 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: c-r4k.c 2/7 micro prid optimization
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:52:04 +0100
Message-ID: <m2wuik9utn.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1843
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 902
Lines: 36


Hi
        prid is only used during init.

Later, Juan.

 build/arch/mips/mm/c-r4k.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

diff -puN build/arch/mips/mm/c-r4k.c~c-r4k_move_prid_call build/arch/mips/mm/c-r4k.c
--- 24/build/arch/mips/mm/c-r4k.c~c-r4k_move_prid_call	2003-03-27 15:40:38.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r4k.c	2003-03-27 15:41:06.000000000 +0100
@@ -45,7 +45,7 @@ static unsigned long scache_size, sc_lsi
 
 static void r4k_blast_dcache_page(unsigned long addr)
 {
-	unsigned int prid = read_c0_prid() & 0xfff0;
+	unsigned int prid;
 	static void *l = &&init;
 
 	goto *l;
@@ -74,6 +74,7 @@ dc_32_r4600:
 	}
 
 init:
+	prid = read_c0_prid() & 0xfff0;
 	if (prid == 0x2010)			/* R4600 V1.7 */
 		l = &&dc_32_r4600;
 	else if (dc_lsize == 16)

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Mar 28 00:54:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:54:54 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:6533 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225201AbTC1Axm>;
	Fri, 28 Mar 2003 00:53:42 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 13E4E46BA6; Fri, 28 Mar 2003 01:52:14 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: c-r4k.c 3/7 flush_cache_sigtramp cleanup
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:52:14 +0100
Message-ID: <m2u1do9utd.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1844
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2473
Lines: 85


Hi
	we _always_ know what version of sigtramp we need to call, 
	just made it explicit. As an added bonus, we only pay penalizations
	now on the buggy cpus (aka 4600).

Later, Juan.


 build/arch/mips/mm/c-r4k.c |   31 +++++++++++++++++++------------
 1 files changed, 19 insertions(+), 12 deletions(-)

diff -puN build/arch/mips/mm/c-r4k.c~c-r4k_sigtramp build/arch/mips/mm/c-r4k.c
--- 24/build/arch/mips/mm/c-r4k.c~c-r4k_sigtramp	2003-03-28 00:41:17.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r4k.c	2003-03-28 00:43:42.000000000 +0100
@@ -531,22 +531,25 @@ static void r4k_dma_cache_inv_sc(unsigne
  */
 static void r4k_flush_cache_sigtramp(unsigned long addr)
 {
+	protected_writeback_dcache_line(addr & ~(dc_lsize - 1));
+	protected_flush_icache_line(addr & ~(ic_lsize - 1));
+}
+
+static void r4600v17_flush_cache_sigtramp(unsigned long addr)
+{
 #ifdef R4600_V1_HIT_DCACHE_WAR
 	unsigned long flags;
 
 	local_irq_save(flags);
 	__asm__ __volatile__("nop;nop;nop;nop");
 #endif
-
-	protected_writeback_dcache_line(addr & ~(dc_lsize - 1));
-	protected_flush_icache_line(addr & ~(ic_lsize - 1));
-
+	r4k_flush_cache_sigtramp(addr);
 #ifdef R4600_V1_HIT_DCACHE_WAR
 	local_irq_restore(flags);
 #endif
 }
 
-static void r4600v20k_flush_cache_sigtramp(unsigned long addr)
+static void r4600v20_flush_cache_sigtramp(unsigned long addr)
 {
 #ifdef R4600_V2_HIT_CACHEOP_WAR
 	unsigned long flags;
@@ -556,10 +559,7 @@ static void r4600v20k_flush_cache_sigtra
 	/* Clear internal cache refill buffer */
 	*(volatile unsigned int *)KSEG1;
 #endif
-
-	protected_writeback_dcache_line(addr & ~(dc_lsize - 1));
-	protected_flush_icache_line(addr & ~(ic_lsize - 1));
-
+	r4k_flush_cache_sigtramp(addr);
 #ifdef R4600_V2_HIT_CACHEOP_WAR
 	local_irq_restore(flags);
 #endif
@@ -810,9 +810,16 @@ void __init ld_mmu_r4xx0(void)
 	}
 
 	_flush_dcache_page = r4k_flush_dcache_page;
-	_flush_cache_sigtramp = r4k_flush_cache_sigtramp;
-	if ((read_c0_prid() & 0xfff0) == 0x2020) {
-		_flush_cache_sigtramp = r4600v20k_flush_cache_sigtramp;
+
+	switch(read_c0_prid() & 0xfff0) {
+	case 0x2010:
+		_flush_cache_sigtramp = r4600v17_flush_cache_sigtramp;
+		break;
+	case 0x2020:
+		_flush_cache_sigtramp = r4600v20_flush_cache_sigtramp;
+		break;
+	default:
+		_flush_cache_sigtramp = r4k_flush_cache_sigtramp;
 	}
 	_flush_icache_range = r4k_flush_icache_range;	/* Ouch */
 

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Mar 28 00:55:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:55:15 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:7045 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225204AbTC1Axs>;
	Fri, 28 Mar 2003 00:53:48 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id ECDC646BA6; Fri, 28 Mar 2003 01:52:19 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: c-r4k.c 4/7 flush_cache_mm cleanup
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:52:19 +0100
Message-ID: <m2smt89ut8.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1845
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1921
Lines: 59


Hi
	flush_cache_mm can use __flush_cache_all.

Later, Juan.


 build/arch/mips/mm/c-r4k.c |   18 +++++-------------
 1 files changed, 5 insertions(+), 13 deletions(-)

diff -puN build/arch/mips/mm/c-r4k.c~c-r4k_flush_cache_mm build/arch/mips/mm/c-r4k.c
--- 24/build/arch/mips/mm/c-r4k.c~c-r4k_flush_cache_mm	2003-03-28 00:54:48.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r4k.c	2003-03-28 00:57:35.000000000 +0100
@@ -255,18 +255,10 @@ static void r4k_flush_cache_range(struct
  * the cache created only by a certain context, but on the MIPS
  * (and actually certain Sparc's) we cannot.
  */
-static void r4k_flush_scache_mm(struct mm_struct *mm)
+static void r4k_flush_cache_mm(struct mm_struct *mm)
 {
-	if (cpu_context(smp_processor_id(), mm) != 0) {
-		r4k_flush_scache_all();
-	}
-}
-
-static void r4k_flush_pcache_mm(struct mm_struct *mm)
-{
-	if (cpu_context(smp_processor_id(), mm) != 0) {
-		r4k_flush_pcache_all();
-	}
+	if (cpu_context(smp_processor_id(), mm) != 0)
+		__flush_cache_all();
 }
 
 static void r4k_flush_cache_page(struct vm_area_struct *vma,
@@ -709,7 +701,7 @@ static void __init setup_noscache_funcs(
 	}
 	_flush_cache_all = r4k_flush_pcache_all;
 	___flush_cache_all = r4k_flush_pcache_all;
-	_flush_cache_mm = r4k_flush_pcache_mm;
+	_flush_cache_mm = r4k_flush_cache_mm;
 	_flush_cache_page = r4k_flush_cache_page;
 	_flush_icache_page = r4k_flush_icache_page;
 	_flush_cache_range = r4k_flush_cache_range;
@@ -745,7 +737,7 @@ static void __init setup_scache_funcs(vo
 
 	_flush_cache_all = r4k_flush_pcache_all;
 	___flush_cache_all = r4k_flush_scache_all;
-	_flush_cache_mm = r4k_flush_scache_mm;
+	_flush_cache_mm = r4k_flush_cache_mm;
 	_flush_cache_range = r4k_flush_cache_range;
 	_flush_cache_page = r4k_flush_cache_page;
 	_flush_icache_page = r4k_flush_icache_page;

_

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Mar 28 00:55:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:55:35 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:7557 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225208AbTC1AyB>;
	Fri, 28 Mar 2003 00:54:01 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id A4D3746BA6; Fri, 28 Mar 2003 01:52:32 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: c-r4k.c 5/7 unduplicate declarations
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:52:32 +0100
Message-ID: <m2ptoc9usv.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1846
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2438
Lines: 78



Hi
	Lots of _flush_* functions are asigned the same value in the 
	case of only pcache or scache.

Later, Juan.


 build/arch/mips/mm/c-r4k.c |   20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)

diff -puN build/arch/mips/mm/c-r4k.c~c-r4k_unduplicate_repated_code build/arch/mips/mm/c-r4k.c
--- 24/build/arch/mips/mm/c-r4k.c~c-r4k_unduplicate_repated_code	2003-03-28 00:58:39.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r4k.c	2003-03-28 01:01:43.000000000 +0100
@@ -699,12 +699,7 @@ static void __init setup_noscache_funcs(
 		}
 		break;
 	}
-	_flush_cache_all = r4k_flush_pcache_all;
 	___flush_cache_all = r4k_flush_pcache_all;
-	_flush_cache_mm = r4k_flush_cache_mm;
-	_flush_cache_page = r4k_flush_cache_page;
-	_flush_icache_page = r4k_flush_icache_page;
-	_flush_cache_range = r4k_flush_cache_range;
 
 	_dma_cache_wback_inv = r4k_dma_cache_wback_inv_pc;
 	_dma_cache_wback = r4k_dma_cache_wback_inv_pc;
@@ -735,12 +730,7 @@ static void __init setup_scache_funcs(vo
 		break;
 	}
 
-	_flush_cache_all = r4k_flush_pcache_all;
 	___flush_cache_all = r4k_flush_scache_all;
-	_flush_cache_mm = r4k_flush_cache_mm;
-	_flush_cache_range = r4k_flush_cache_range;
-	_flush_cache_page = r4k_flush_cache_page;
-	_flush_icache_page = r4k_flush_icache_page;
 
 	_dma_cache_wback_inv = r4k_dma_cache_wback_inv_sc;
 	_dma_cache_wback = r4k_dma_cache_wback_inv_sc;
@@ -793,6 +783,14 @@ void __init ld_mmu_r4xx0(void)
 	probe_dcache(config);
 	setup_scache(config);
 
+	_flush_cache_all = r4k_flush_pcache_all;
+	_flush_cache_range = r4k_flush_cache_range;
+	_flush_icache_range = r4k_flush_icache_range;	/* Ouch */
+	_flush_cache_mm = r4k_flush_cache_mm;
+	_flush_cache_page = r4k_flush_cache_page;
+	_flush_dcache_page = r4k_flush_dcache_page;
+	_flush_icache_page = r4k_flush_icache_page;
+
 	switch(mips_cpu.cputype) {
 	case CPU_R4600:			/* QED style two way caches? */
 	case CPU_R4700:
@@ -801,7 +799,6 @@ void __init ld_mmu_r4xx0(void)
 		_flush_cache_page = r4k_flush_cache_page_r4600;
 	}
 
-	_flush_dcache_page = r4k_flush_dcache_page;
 
 	switch(read_c0_prid() & 0xfff0) {
 	case 0x2010:
@@ -813,7 +810,6 @@ void __init ld_mmu_r4xx0(void)
 	default:
 		_flush_cache_sigtramp = r4k_flush_cache_sigtramp;
 	}
-	_flush_icache_range = r4k_flush_icache_range;	/* Ouch */
 
 	__flush_cache_all();
 }

_

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Mar 28 00:55:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:55:55 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:8069 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225209AbTC1AyI>;
	Fri, 28 Mar 2003 00:54:08 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 18EDD46BA6; Fri, 28 Mar 2003 01:52:39 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: c-r4k.c 6/7 simplify flush_cache_page
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:52:39 +0100
Message-ID: <m2of3w9uso.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1847
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 5507
Lines: 193


Hi
	create r4k_blast_page{indexed} functions.  That allows to remove the
	r4600 variant of the r4k_flush_page_cache.  Once there, fix the bug
	we were testing _PAGE_VALID, instead of _PAGE_PRESENT.

	Once there, also define a nice inline to test for _PAGE_VALID.

Later, Juan.


 build/arch/mips/mm/c-r4k.c       |  122 +++++++++++++++------------------------
 build/include/asm-mips/pgtable.h |    1 
 2 files changed, 48 insertions(+), 75 deletions(-)

diff -puN build/include/asm-mips/pgtable.h~c-r4k_flush_cache_page build/include/asm-mips/pgtable.h
--- 24/build/include/asm-mips/pgtable.h~c-r4k_flush_cache_page	2003-03-28 01:18:02.000000000 +0100
+++ 24-quintela/build/include/asm-mips/pgtable.h	2003-03-28 01:19:33.000000000 +0100
@@ -220,6 +220,7 @@ static inline void pmd_set(pmd_t * pmdp,
 
 static inline int pte_none(pte_t pte)    { return !(pte_val(pte) & ~_PAGE_GLOBAL); }
 static inline int pte_present(pte_t pte) { return pte_val(pte) & _PAGE_PRESENT; }
+static inline int pte_valid(pte_t pte) { return pte_val(pte) & _PAGE_VALID; }
 
 /* Certain architectures need to do special things when pte's
  * within a page table are directly modified.  Thus, the following
diff -puN build/arch/mips/mm/c-r4k.c~c-r4k_flush_cache_page build/arch/mips/mm/c-r4k.c
--- 24/build/arch/mips/mm/c-r4k.c~c-r4k_flush_cache_page	2003-03-28 01:18:16.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r4k.c	2003-03-28 01:37:01.000000000 +0100
@@ -228,6 +228,49 @@ init:
 	goto *l;
 }
 
+static void r4k_blast_cache_page(unsigned long page, int exec)
+{
+	r4k_blast_dcache_page(page);
+	if (exec)
+		r4k_blast_icache_page(page);
+}
+
+static void r4k_blast_cache_page_indexed(unsigned long page, int exec)
+{
+	unsigned long addr = (KSEG0 + (page & (dcache_size - 1)));
+	static void *l = &&init;
+
+	goto *l;
+
+normal:
+	r4k_blast_dcache_page_indexed(addr);
+	if (exec)
+		r4k_blast_icache_page_indexed(addr);
+	return;
+
+r4600:
+	r4k_blast_dcache_page_indexed(addr);
+	r4k_blast_dcache_page_indexed(addr & dcache_waybit);
+	if (exec) {
+		r4k_blast_icache_page_indexed(addr);
+		r4k_blast_icache_page_indexed(addr ^ icache_waybit);
+	}
+	return;
+
+init:
+	switch(mips_cpu.cputype) {
+	case CPU_R4600:			/* QED style two way caches? */
+	case CPU_R4700:
+	case CPU_R5000:
+	case CPU_NEVADA:
+		l = && r4600;
+		break;
+	default:
+		l = &&normal;
+	}
+	goto *l;
+}
+
 static inline void r4k_flush_scache_all(void)
 {
 	r4k_blast_dcache();
@@ -286,7 +329,7 @@ static void r4k_flush_cache_page(struct 
 	 * If the page isn't marked valid, the page cannot possibly be
 	 * in the cache.
 	 */
-	if (!(pte_val(*ptep) & _PAGE_VALID))
+	if (!pte_present(*ptep))
 		return;
 
 	/*
@@ -295,11 +338,8 @@ static void r4k_flush_cache_page(struct 
 	 * for every cache flush operation.  So we do indexed flushes
 	 * in that case, which doesn't overly flush the cache too much.
 	 */
-	if (mm == current->active_mm) {
-		r4k_blast_dcache_page(page);
-		if (exec)
-			r4k_blast_icache_page(page);
-
+	if ((mm == current->active_mm) && pte_valid(*ptep)) {
+		r4k_blast_cache_page(page, exec);
 		return;
 	}
 
@@ -307,66 +347,7 @@ static void r4k_flush_cache_page(struct 
 	 * Do indexed flush, too much work to get the (possible) TLB refills
 	 * to work correctly.
 	 */
-	page = (KSEG0 + (page & (dcache_size - 1)));
-	r4k_blast_dcache_page_indexed(page);
-	if (exec)
-		r4k_blast_icache_page_indexed(page);
-}
-
-static void r4k_flush_cache_page_r4600(struct vm_area_struct *vma,
-	unsigned long page)
-{
-	int exec = vma->vm_flags & VM_EXEC;
-	struct mm_struct *mm = vma->vm_mm;
-	pgd_t *pgdp;
-	pmd_t *pmdp;
-	pte_t *ptep;
-
-	/*
-	 * If ownes no valid ASID yet, cannot possibly have gotten
-	 * this page into the cache.
-	 */
-	if (cpu_context(smp_processor_id(), mm) == 0)
-		return;
-
-	page &= PAGE_MASK;
-	pgdp = pgd_offset(mm, page);
-	pmdp = pmd_offset(pgdp, page);
-	ptep = pte_offset(pmdp, page);
-
-	/*
-	 * If the page isn't marked valid, the page cannot possibly be
-	 * in the cache.
-	 */
-	if (!(pte_val(*ptep) & _PAGE_PRESENT))
-		return;
-
-	/*
-	 * Doing flushes for another ASID than the current one is
-	 * too difficult since stupid R4k caches do a TLB translation
-	 * for every cache flush operation.  So we do indexed flushes
-	 * in that case, which doesn't overly flush the cache too much.
-	 */
-	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) {
-		r4k_blast_dcache_page(page);
-		if (exec)
-			r4k_blast_icache_page(page);
-
-		return;
-	}
-
-	/*
-	 * Do indexed flush, too much work to get the (possible)
-	 * tlb refills to work correctly.
-	 */
-	page = KSEG0 + (page & (dcache_size - 1));
-	r4k_blast_dcache_page_indexed(page);
-	r4k_blast_dcache_page_indexed(page ^ dcache_waybit);
-
-	if (exec) {
-		r4k_blast_icache_page_indexed(page);
-		r4k_blast_icache_page_indexed(page ^ icache_waybit);
-	}
+	r4k_blast_cache_page_indexed(page, exec);
 }
 
 static void r4k_flush_dcache_page_impl(struct page *page)
@@ -791,15 +772,6 @@ void __init ld_mmu_r4xx0(void)
 	_flush_dcache_page = r4k_flush_dcache_page;
 	_flush_icache_page = r4k_flush_icache_page;
 
-	switch(mips_cpu.cputype) {
-	case CPU_R4600:			/* QED style two way caches? */
-	case CPU_R4700:
-	case CPU_R5000:
-	case CPU_NEVADA:
-		_flush_cache_page = r4k_flush_cache_page_r4600;
-	}
-
-
 	switch(read_c0_prid() & 0xfff0) {
 	case 0x2010:
 		_flush_cache_sigtramp = r4600v17_flush_cache_sigtramp;

_


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Mar 28 00:56:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 00:56:15 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:8581 "EHLO
	neno.mitica") by linux-mips.org with ESMTP id <S8225196AbTC1AyN>;
	Fri, 28 Mar 2003 00:54:13 +0000
Received: by neno.mitica (Postfix, from userid 501)
	id 6D57346BA6; Fri, 28 Mar 2003 01:52:45 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: c-r4k.c 7/7 minor cleanups
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: Fri, 28 Mar 2003 01:52:45 +0100
Message-ID: <m2n0jg9usi.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1848
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1238
Lines: 51


Hi
	- No need to test for a WAR when we _know_ that the WAR is there.
	- Use the pcache function already defined.

Later, Juan.


 build/arch/mips/mm/c-r4k.c |   10 ++--------
 1 files changed, 2 insertions(+), 8 deletions(-)

diff -puN build/arch/mips/mm/c-r4k.c~c-r4k_minor_cleanups build/arch/mips/mm/c-r4k.c
--- 24/build/arch/mips/mm/c-r4k.c~c-r4k_minor_cleanups	2003-03-28 01:23:29.000000000 +0100
+++ 24-quintela/build/arch/mips/mm/c-r4k.c	2003-03-28 01:25:10.000000000 +0100
@@ -59,17 +59,13 @@ dc_32:
 	return;
 
 dc_32_r4600:
-#ifdef R4600_V1_HIT_DCACHE_WAR
 	{
 	unsigned long flags;
 
 	local_irq_save(flags);
 	__asm__ __volatile__("nop;nop;nop;nop");
-#endif
 	blast_dcache32_page(addr);
-#ifdef R4600_V1_HIT_DCACHE_WAR
 	local_irq_restore(flags);
-#endif
 	return;
 	}
 
@@ -287,10 +283,8 @@ static inline void r4k_flush_pcache_all(
 static void r4k_flush_cache_range(struct mm_struct *mm,
 	unsigned long start, unsigned long end)
 {
-	if (cpu_context(smp_processor_id(), mm) != 0) {
-		r4k_blast_dcache();
-		r4k_blast_icache();
-	}
+	if (cpu_context(smp_processor_id(), mm) != 0)
+		r4k_flush_pcache_all();
 }
 
 /*

_

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From macro@ds2.pg.gda.pl Fri Mar 28 17:51:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 17:51:29 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:28086 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224827AbTC1Rv3>; Fri, 28 Mar 2003 17:51:29 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA27053;
	Fri, 28 Mar 2003 18:51:57 +0100 (MET)
Date: Fri, 28 Mar 2003 18:51:57 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Juan Quintela <quintela@mandrakesoft.com>
cc: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: c-r4k.c 4/7 flush_cache_mm cleanup
In-Reply-To: <m2smt89ut8.fsf@neno.mitica>
Message-ID: <Pine.GSO.3.96.1030328175039.26178B-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: 1849
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 476
Lines: 13

On Fri, 28 Mar 2003, Juan Quintela wrote:

> 	flush_cache_mm can use __flush_cache_all.

 Wrong, it should use r4k_flush_pcache_all() unconditionally, but I'm told
such a setup triggers a bug somewhere, that needs to be tracked down
before committing that change to the CVS.

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


From ralf@linux-mips.net Fri Mar 28 19:00:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 19:00:05 +0000 (GMT)
Received: from p508B652B.dip.t-dialin.net ([IPv6:::ffff:80.139.101.43]:2278
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224827AbTC1TAE>; Fri, 28 Mar 2003 19:00:04 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2SIxrB19202;
	Fri, 28 Mar 2003 19:59:53 +0100
Date: Fri, 28 Mar 2003 19:59:53 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Juan Quintela <quintela@mandrakesoft.com>,
	mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: c-r4k.c 4/7 flush_cache_mm cleanup
Message-ID: <20030328195953.A17890@linux-mips.org>
References: <m2smt89ut8.fsf@neno.mitica> <Pine.GSO.3.96.1030328175039.26178B-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.1030328175039.26178B-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Mar 28, 2003 at 06:51:57PM +0100
Return-Path: <ralf@linux-mips.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: 1850
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 949
Lines: 20

On Fri, Mar 28, 2003 at 06:51:57PM +0100, Maciej W. Rozycki wrote:

> > 	flush_cache_mm can use __flush_cache_all.
> 
>  Wrong, it should use r4k_flush_pcache_all() unconditionally, but I'm told
> such a setup triggers a bug somewhere, that needs to be tracked down
> before committing that change to the CVS.

Now that the problem is mentioned on the list lemme elaborate a bit.  The
problem mentioned only affects R4000SC and R4400SC processors.
Flush_cache_mm is only used when a mm is either copied on fork or when
it's finally destroyed.  Because the S-cache is is physically indexed
and the P-cache is refilled from the S-cache if data should be still in
there we don't need to flush the S-cache ever for any of the mm's
cacheflushing functions.  So the observation that things are only
working properly if we do flush the S-cache also suggest we're either
having a bug elsewhere in the cache code or we're hitting a hardware
problem.

  Ralf

From hartvig@ekner.info Fri Mar 28 19:08:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 19:08:17 +0000 (GMT)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:24074 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8224827AbTC1TIP>;
	Fri, 28 Mar 2003 19:08:15 +0000
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id F1CB0B4DB
	for <linux-mips@linux-mips.org>; Fri, 28 Mar 2003 20:08:12 +0100 (CET)
Message-ID: <3E849F22.7BC4EDE@ekner.info>
Date: Fri, 28 Mar 2003 20:14:42 +0100
From: Hartvig Ekner <hartvig@ekner.info>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Au1000 ethernet patch
Content-Type: multipart/mixed;
 boundary="------------60A5F95BF5B2DA5B7D3F1B34"
Return-Path: <hartvig@ekner.info>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1851
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvig@ekner.info
Precedence: bulk
X-list: linux-mips
Content-Length: 1253
Lines: 38

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

The following patch fixes an error where ethernet minimum packets are 4 bytes too long. This caused certain
devices not to respond to ARP requests (which is a bug on their side as well, but.....).

/Hartvig



--------------60A5F95BF5B2DA5B7D3F1B34
Content-Type: text/plain; charset=us-ascii;
 name="eth_patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="eth_patch"

Index: au1000_eth.h
===================================================================
RCS file: /home/cvs/linux/drivers/net/au1000_eth.h,v
retrieving revision 1.2.2.8
diff -u -r1.2.2.8 au1000_eth.h
--- au1000_eth.h	3 Mar 2003 06:40:30 -0000	1.2.2.8
+++ au1000_eth.h	28 Mar 2003 19:05:48 -0000
@@ -36,7 +36,7 @@
 #define MAX_BUF_SIZE 2048
 
 #define ETH_TX_TIMEOUT HZ/4
-#define MAC_MIN_PKT_SIZE 64
+#define MAC_MIN_PKT_SIZE 60
 
 #if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_PB1100) || defined(CONFIG_MIPS_DB1000) || defined(CONFIG_MIPS_DB1100) || defined(CONFIG_MIPS_DB1500)
 #define PHY_ADDRESS              0

--------------60A5F95BF5B2DA5B7D3F1B34--


From quintela@mandrakesoft.com Fri Mar 28 19:33:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 19:33:25 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:40788 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225272AbTC1TdY>;
	Fri, 28 Mar 2003 19:33:24 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 0A6396EE; Fri, 28 Mar 2003 20:33:22 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: c-r4k.c 4/7 flush_cache_mm cleanup
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030328195953.A17890@linux-mips.org> (Ralf Baechle's message
 of "Fri, 28 Mar 2003 19:59:53 +0100")
References: <m2smt89ut8.fsf@neno.mitica>
	<Pine.GSO.3.96.1030328175039.26178B-100000@delta.ds2.pg.gda.pl>
	<20030328195953.A17890@linux-mips.org>
Date: Fri, 28 Mar 2003 20:33:22 +0100
Message-ID: <86smt79th9.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1852
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1457
Lines: 32

>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:

ralf> On Fri, Mar 28, 2003 at 06:51:57PM +0100, Maciej W. Rozycki wrote:
>> > 	flush_cache_mm can use __flush_cache_all.
>> 
>> Wrong, it should use r4k_flush_pcache_all() unconditionally, but I'm told
>> such a setup triggers a bug somewhere, that needs to be tracked down
>> before committing that change to the CVS.

ralf> Now that the problem is mentioned on the list lemme elaborate a bit.  The
ralf> problem mentioned only affects R4000SC and R4400SC processors.
ralf> Flush_cache_mm is only used when a mm is either copied on fork or when
ralf> it's finally destroyed.  Because the S-cache is is physically indexed
ralf> and the P-cache is refilled from the S-cache if data should be still in
ralf> there we don't need to flush the S-cache ever for any of the mm's
ralf> cacheflushing functions.  So the observation that things are only
ralf> working properly if we do flush the S-cache also suggest we're either
ralf> having a bug elsewhere in the cache code or we're hitting a hardware
ralf> problem.

Ok, will took a look at that (casually my I2 has an R4400SC), but I
still think that patch can be applied.  It has the same behaviour than
actual code.  And it is a cleanup.  When we found the bug, we can do a
s/__flush_cache_all/r4k_flush_pcache_all/

on that function.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From ppopov@mvista.com Fri Mar 28 22:37:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 22:37:36 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:3314 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224827AbTC1Whg>;
	Fri, 28 Mar 2003 22:37:36 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA03352
	for <linux-mips@linux-mips.org>; Fri, 28 Mar 2003 14:37:33 -0800
Subject: Re: Au1000 ethernet patch
From: Pete Popov <ppopov@mvista.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <3E849F22.7BC4EDE@ekner.info>
References: <3E849F22.7BC4EDE@ekner.info>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1048891068.17369.50.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 28 Mar 2003 14:37:48 -0800
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: 1853
X-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
Content-Length: 1082
Lines: 33


On Fri, 2003-03-28 at 11:14, Hartvig Ekner wrote:
> The following patch fixes an error where ethernet minimum packets are 4 bytes too long. This caused certain
> devices not to respond to ARP requests (which is a bug on their side as well, but.....).


Thanks, I'll apply it later tonight.

Pete

> /Hartvig
> 
> 
> 
> ______________________________________________________________________
> 
> Index: au1000_eth.h
> ===================================================================
> RCS file: /home/cvs/linux/drivers/net/au1000_eth.h,v
> retrieving revision 1.2.2.8
> diff -u -r1.2.2.8 au1000_eth.h
> --- au1000_eth.h	3 Mar 2003 06:40:30 -0000	1.2.2.8
> +++ au1000_eth.h	28 Mar 2003 19:05:48 -0000
> @@ -36,7 +36,7 @@
>  #define MAX_BUF_SIZE 2048
>  
>  #define ETH_TX_TIMEOUT HZ/4
> -#define MAC_MIN_PKT_SIZE 64
> +#define MAC_MIN_PKT_SIZE 60
>  
>  #if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_PB1100) || defined(CONFIG_MIPS_DB1000) || defined(CONFIG_MIPS_DB1100) || defined(CONFIG_MIPS_DB1500)
>  #define PHY_ADDRESS              0


From ppopov@mvista.com Fri Mar 28 22:39:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 22:39:19 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:28146 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224827AbTC1WjS>;
	Fri, 28 Mar 2003 22:39:18 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA03406
	for <linux-mips@linux-mips.org>; Fri, 28 Mar 2003 14:39:16 -0800
Subject: Au1x 36bit addr
From: Pete Popov <ppopov@mvista.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1048891172.17369.53.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 28 Mar 2003 14:39:32 -0800
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: 1854
X-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
Content-Length: 211
Lines: 7


I know some people on the list are doing Au1x development, so I thought
I would let you know that the 36bit address support is now in the tree,
so I'll remove the patch from my directory and the README.

Pete


From ralf@linux-mips.net Fri Mar 28 23:42:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 23:42:01 +0000 (GMT)
Received: from p508B652B.dip.t-dialin.net ([IPv6:::ffff:80.139.101.43]:22250
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224827AbTC1XmA>; Fri, 28 Mar 2003 23:42:00 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2SNfrj20358;
	Sat, 29 Mar 2003 00:41:53 +0100
Date: Sat, 29 Mar 2003 00:41:53 +0100
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: Au1000 ethernet patch
Message-ID: <20030329004153.A20126@linux-mips.org>
References: <3E849F22.7BC4EDE@ekner.info> <1048891068.17369.50.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: <1048891068.17369.50.camel@zeus.mvista.com>; from ppopov@mvista.com on Fri, Mar 28, 2003 at 02:37:48PM -0800
Return-Path: <ralf@linux-mips.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: 1855
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 445
Lines: 12

On Fri, Mar 28, 2003 at 02:37:48PM -0800, Pete Popov wrote:

> On Fri, 2003-03-28 at 11:14, Hartvig Ekner wrote:
> > The following patch fixes an error where ethernet minimum packets are 4 bytes too long. This caused certain
> > devices not to respond to ARP requests (which is a bug on their side as well, but.....).
> 
> 
> Thanks, I'll apply it later tonight.

<asm/if_ether.h> already defines the constant ETH_ZLEN for this purpose.

  Ralf

From ppopov@mvista.com Fri Mar 28 23:48:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 23:48:11 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:2042 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225195AbTC1XsK>;
	Fri, 28 Mar 2003 23:48:10 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA06092;
	Fri, 28 Mar 2003 15:48:08 -0800
Subject: Re: Au1000 ethernet patch
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: <20030329004153.A20126@linux-mips.org>
References: <3E849F22.7BC4EDE@ekner.info>
	 <1048891068.17369.50.camel@zeus.mvista.com>
	 <20030329004153.A20126@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1048895304.29891.8.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 28 Mar 2003 15:48:24 -0800
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: 1856
X-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
Content-Length: 555
Lines: 16

On Fri, 2003-03-28 at 15:41, Ralf Baechle wrote:
> On Fri, Mar 28, 2003 at 02:37:48PM -0800, Pete Popov wrote:
> 
> > On Fri, 2003-03-28 at 11:14, Hartvig Ekner wrote:
> > > The following patch fixes an error where ethernet minimum packets are 4 bytes too long. This caused certain
> > > devices not to respond to ARP requests (which is a bug on their side as well, but.....).
> > 
> > 
> > Thanks, I'll apply it later tonight.
> 
> <asm/if_ether.h> already defines the constant ETH_ZLEN for this purpose.

Great, thanks. I'll make the correction.

Pete


From ralf@linux-mips.net Fri Mar 28 23:54:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Mar 2003 23:54:42 +0000 (GMT)
Received: from p508B652B.dip.t-dialin.net ([IPv6:::ffff:80.139.101.43]:44522
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224827AbTC1Xyl>; Fri, 28 Mar 2003 23:54:41 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2SNscc20645;
	Sat, 29 Mar 2003 00:54:38 +0100
Date: Sat, 29 Mar 2003 00:54:38 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Juan Quintela <quintela@mandrakesoft.com>
Cc: mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: no way to build pg.o
Message-ID: <20030329005438.B20495@linux-mips.org>
References: <m265q4b9fb.fsf@neno.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: <m265q4b9fb.fsf@neno.mitica>; from quintela@mandrakesoft.com on Fri, Mar 28, 2003 at 01:51:20AM +0100
Return-Path: <ralf@linux-mips.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: 1857
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 191
Lines: 9

On Fri, Mar 28, 2003 at 01:51:20AM +0100, Juan Quintela wrote:

> 	There is no file from which generate pg.o

Already fixed before I took a look at your patch ...

Thanks anyway ...

   Ralf

From ralf@linux-mips.net Sat Mar 29 00:08:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 29 Mar 2003 00:08:23 +0000 (GMT)
Received: from p508B652B.dip.t-dialin.net ([IPv6:::ffff:80.139.101.43]:62698
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225258AbTC2AIW>; Sat, 29 Mar 2003 00:08:22 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2T08J126207;
	Sat, 29 Mar 2003 01:08:19 +0100
Date: Sat, 29 Mar 2003 01:08:19 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Juan Quintela <quintela@mandrakesoft.com>
Cc: mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: cswitch not defined if !CONFIG_VT
Message-ID: <20030329010819.A20657@linux-mips.org>
References: <m21y0sb9et.fsf@neno.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: <m21y0sb9et.fsf@neno.mitica>; from quintela@mandrakesoft.com on Fri, Mar 28, 2003 at 01:51:38AM +0100
Return-Path: <ralf@linux-mips.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: 1858
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 133
Lines: 7

On Fri, Mar 28, 2003 at 01:51:38AM +0100, Juan Quintela wrote:

> 	cswitch is only used when CONFIG_VT is defined.

Applied,

  Ralf

From ralf@linux-mips.net Sat Mar 29 00:49:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 29 Mar 2003 00:49:51 +0000 (GMT)
Received: from p508B652B.dip.t-dialin.net ([IPv6:::ffff:80.139.101.43]:52971
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224861AbTC2Atv>; Sat, 29 Mar 2003 00:49:51 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2T0nlO27010;
	Sat, 29 Mar 2003 01:49:47 +0100
Date: Sat, 29 Mar 2003 01:49:47 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Juan Quintela <quintela@mandrakesoft.com>
Cc: mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: c-r4k.c 1/7 s/switch/formula/
Message-ID: <20030329014947.A26735@linux-mips.org>
References: <m2y9309utu.fsf@neno.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: <m2y9309utu.fsf@neno.mitica>; from quintela@mandrakesoft.com on Fri, Mar 28, 2003 at 01:51:57AM +0100
Return-Path: <ralf@linux-mips.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: 1859
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 202
Lines: 7

On Fri, Mar 28, 2003 at 01:51:57AM +0100, Juan Quintela wrote:

> 	use the same calculation for sc_size as in every other *_size.

Thanks, this pointless switch has been on my list for a while.

  Ralf

From avinash.s@inspiretech.com Sat Mar 29 07:03:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 29 Mar 2003 07:03:45 +0000 (GMT)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:14208
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8224861AbTC2HDn>; Sat, 29 Mar 2003 07:03:43 +0000
Received: from mail.inspiretech.com (mail.inspiretech.com [150.1.1.1])
	by smtp.inspirtek.com (8.12.5/8.12.5) with ESMTP id h2T7NYq6006229
	for <linux-mips@linux-mips.org>; Sat, 29 Mar 2003 12:53:40 +0530
Message-Id: <200303290723.h2T7NYq6006229@smtp.inspirtek.com>
Received: from WorldClient [150.1.1.1] by inspiretech.com [150.1.1.1]
	with SMTP (MDaemon.v3.5.7.R)
	for <linux-mips@linux-mips.org>; Sat, 29 Mar 2003 12:24:43 +0530
Date: Sat, 29 Mar 2003 12:24:42 +0530
From: "Avinash S." <avinash.s@inspiretech.com>
To: "linux" <linux-mips@linux-mips.org>
Subject: 
X-Mailer: WorldClient Standard 3.5.0e
X-MDRemoteIP: 150.1.1.1
X-Return-Path: avinash.s@inspiretech.com
X-MDaemon-Deliver-To: linux-mips@linux-mips.org
Return-Path: <avinash.s@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: 1860
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: avinash.s@inspiretech.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1848
Lines: 45

Hello,

Im trying to build a kernel config for a big endian IDT79S334 board. I 
have sucessfully mangaged to get a vmlinux image using Embedix tools for 
little endian but am having problems with big endian configs. I am using 
binutils version 2.8. I get an error when i reaches irq.c saying:
Unknown ISA level 
Unknown opcode 'clz'

im using a mips-linux-gcc from egcs pacakge(1.1.2-4). Does anyone know 
how to solve this problem or where can i get a mips-linux-gcc that 
supports the opcode.

Thanks in advance
Avinash


pS: here is the make dump that shows the error.
--------------------------------------------------------------------------
make[1]: Entering directory 
`/home1/ixe2424/proj/ixe2424/IDT/linux/arch/mips/rc32300/79S334'
make all_targets
make[2]: Entering directory 
`/home1/ixe2424/proj/ixe2424/IDT/linux/arch/mips/rc32300/79S334'
mips-linux-gcc -I /home1/ixe2424/proj/ixe2424/IDT/linux/include/asm/gcc -
D__KERNEL__ -I/home1/ixe2424/proj/ixe2424/IDT/linux/include -Wall -
Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer  -fno-common -
fno-strict-aliasing -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -Wa,--
trap -pipe   -DKBUILD_BASENAME=irq  -c -o irq.o irq.c
{standard input}: Assembler messages:
{standard input}:1076: Error: unknown ISA level
{standard input}:1077: Error: unrecognized opcode `clz'
{standard input}:1116: Error: unknown ISA level
{standard input}:1117: Error: unrecognized opcode `clz'
{standard input}:1193: Error: unknown ISA level
{standard input}:1194: Error: unrecognized opcode `clz'
make[2]: *** [irq.o] Error 1
make[2]: Leaving directory 
`/home1/ixe2424/proj/ixe2424/IDT/linux/arch/mips/rc32300/79S334'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory 
`/home1/ixe2424/proj/ixe2424/IDT/linux/arch/mips/rc32300/79S334'
make: *** [_dir_arch/mips/rc32300/79S334] Error 2



From ica2_ts@csv.ica.uni-stuttgart.de Sat Mar 29 07:25:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 29 Mar 2003 07:25:45 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:12303
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224861AbTC2HZo>; Sat, 29 Mar 2003 07:25:44 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 18zAik-0004o9-00; Sat, 29 Mar 2003 08:25:42 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 18zAij-00052r-00; Sat, 29 Mar 2003 08:25:41 +0100
Date: Sat, 29 Mar 2003 08:25:41 +0100
To: "Avinash S." <avinash.s@inspiretech.com>
Cc: linux <linux-mips@linux-mips.org>
Subject: Re: your mail
Message-ID: <20030329072541.GD14490@rembrandt.csv.ica.uni-stuttgart.de>
References: <200303290723.h2T7NYq6006229@smtp.inspirtek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200303290723.h2T7NYq6006229@smtp.inspirtek.com>
User-Agent: Mutt/1.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: 1861
X-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
Content-Length: 647
Lines: 21

Avinash S. wrote:
> Hello,
> 
> Im trying to build a kernel config for a big endian IDT79S334 board. I 
> have sucessfully mangaged to get a vmlinux image using Embedix tools for 
> little endian but am having problems with big endian configs. I am using 
> binutils version 2.8. I get an error when i reaches irq.c saying:
                   ^^^
That's _very_ old.

> Unknown ISA level 
> Unknown opcode 'clz'
> 
> im using a mips-linux-gcc from egcs pacakge(1.1.2-4). Does anyone know 
> how to solve this problem or where can i get a mips-linux-gcc that 
> supports the opcode.

It's the assembler, not the compiler. Upgrade binutils.


Thiemo

From quintela@mandrakesoft.com Sat Mar 29 14:41:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 29 Mar 2003 14:41:04 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:10873 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225072AbTC2OlD>;
	Sat, 29 Mar 2003 14:41:03 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id DACAE6EE; Sat, 29 Mar 2003 15:41:01 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: c-r4k.c 4/7 flush_cache_mm cleanup
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030328195953.A17890@linux-mips.org> (Ralf Baechle's message
 of "Fri, 28 Mar 2003 19:59:53 +0100")
References: <m2smt89ut8.fsf@neno.mitica>
	<Pine.GSO.3.96.1030328175039.26178B-100000@delta.ds2.pg.gda.pl>
	<20030328195953.A17890@linux-mips.org>
Date: Sat, 29 Mar 2003 15:41:01 +0100
Message-ID: <867kaii6bm.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1862
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1788
Lines: 45

>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:

ralf> On Fri, Mar 28, 2003 at 06:51:57PM +0100, Maciej W. Rozycki wrote:
>> > 	flush_cache_mm can use __flush_cache_all.
>> 
>> Wrong, it should use r4k_flush_pcache_all() unconditionally, but I'm told
>> such a setup triggers a bug somewhere, that needs to be tracked down
>> before committing that change to the CVS.

ralf> Now that the problem is mentioned on the list lemme elaborate a bit.  The
ralf> problem mentioned only affects R4000SC and R4400SC processors.
ralf> Flush_cache_mm is only used when a mm is either copied on fork or when
ralf> it's finally destroyed.  Because the S-cache is is physically indexed
ralf> and the P-cache is refilled from the S-cache if data should be still in
ralf> there we don't need to flush the S-cache ever for any of the mm's
ralf> cacheflushing functions.  So the observation that things are only
ralf> working properly if we do flush the S-cache also suggest we're either
ralf> having a bug elsewhere in the cache code or we're hitting a hardware
ralf> problem.

Just to add some more data points. flush_cache_mm() is only called
from two places:

- kernel/fork.c::dup_mmap()
- mm/mmap.c::exit_mmap()

I just changed flush_cache_mm() to be r4k_flush_pcache_all() and put
after the two calls a __flush_cache_all().  As expected everything
worked :)

Now if I removed teh __flush_cache_all() for any of the callers,
everything goes well.  But if I remove it for both of them things
crashed during boot.  I am looking at the code of both functions, and
can't see a good reason for them to fail :(

Does that ring any bells on you?

I am still investigating that one.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From ppopov@mvista.com Sun Mar 30 20:33:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 30 Mar 2003 20:33:15 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:9468 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225072AbTC3TdN>;
	Sun, 30 Mar 2003 20:33:13 +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 LAA01684;
	Sun, 30 Mar 2003 11:33:05 -0800
Subject: Re: IDE initialization on AU1500?
From: Pete Popov <ppopov@mvista.com>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <3E873DA0.A8B9B807@ekner.info>
References: <3E873DA0.A8B9B807@ekner.info>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1049052911.1919.11.camel@adsl.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 30 Mar 2003 11:35:11 -0800
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: 1863
X-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
Content-Length: 2507
Lines: 63

Hi Hartvig,

I added the mailing list to the CC because someone else might have a
better answer.

On Sun, 2003-03-30 at 10:55, Hartvig Ekner wrote:
> Hi Pete,
> 
> I upgraded to the latest 2.4, and all the end_irq warnings which were there a few
> weeks back are gone. 

Yep, I got rid of the debug print :). I had put that print in irq.c a
long time ago, and it never caused any problems. But back then, the irq
probing routines were null in MIPS, so we never saw the print.

> Now it looks like this:
> 
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> PDC20268: IDE controller at PCI slot 00:0d.0
> PDC20268: chipset revision 2
> PDC20268: not 100% native mode: will probe irqs later
> PDC20268: ROM enabled at 0x000dc000
>     ide0: BM-DMA at 0x0520-0x0527, BIOS settings: hda:pio, hdb:pio
>     ide1: BM-DMA at 0x0528-0x052f, BIOS settings: hdc:pio, hdd:pio
> hdc: IBM-DTLA-307030, ATA DISK drive
> blk: queue 802f7a58, I/O limit 4095Mb (mask 0xffffffff)
> hdg: IRQ probe failed (0xfffbfffe)
> hdg: IRQ probe failed (0xfffbbffe)
> hdi: probing with STATUS(0x24) instead of ALTSTATUS(0x00)
> hdi: IRQ probe failed (0xfffbfffe)
> hdi: IRQ probe failed (0xfffbbffe)
> hdk: probing with STATUS(0x24) instead of ALTSTATUS(0x00)
> ide1 at 0x510-0x517,0x51a on irq 1
> hdc: host protected area => 1
> hdc: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
> Partition check:
>  hdc: hdc1 hdc2 hdc3 hdc4
> 
> Are the "IRQ probe failed" and "probing with ..." messages expected and ok?  

Well, since the ide subsystem is probing all the drives, and there are
no drives to be found, I would have to say that the failures are to be
expected.

> Is there something platform
> specific which tells the IDE driver to look for 11 drives (hda-hdk) or what is 
> going on here? 

include/asm-mips/ide.h defines MAX_HWIFS 10, if not already defined.

> As you can probably tell, I don't have any specific knowledge about
> how the IDE initialization works and how it interacts with the
> platform specific code (if at all), but I would somehow imagine that
> unless the IDE drivers detect an IDE controller (as done above: ide0,
> ide1) no probing should be performed for drives outside the possible
> range of the detected IDE controllers (hda-hdd in this case).

That's a good point. I don't know what's going on, which is why I added
the mailing list to the CC. Something seems not quite right.

Pete


From lyle@zevion.com Mon Mar 31 06:29:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 06:29:37 +0100 (BST)
Received: from rrcs-central-24-123-115-43.biz.rr.com ([IPv6:::ffff:24.123.115.43]:7176
	"EHLO Radium.intranet") by linux-mips.org with ESMTP
	id <S8225220AbTCaF3e>; Mon, 31 Mar 2003 06:29:34 +0100
Received: from RADIUM ([192.168.1.19])
	by Radium.intranet (8.9.3/8.9.3) with ESMTP id XAA02113
	for <linux-mips@linux-mips.org>; Sun, 30 Mar 2003 23:21:16 -0600
From: "Lyle Bainbridge" <lyle@zevion.com>
To: "'linux-mips'" <linux-mips@linux-mips.org>
Subject: RE: IDE initialization on AU1500?
Date: Sun, 30 Mar 2003 23:29:28 -0600
Message-ID: <000201c2f746$7fe683a0$1301a8c0@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
In-Reply-To: <1049052911.1919.11.camel@adsl.pacbell.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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: 1864
X-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
Content-Length: 3826
Lines: 106

Hi,

I can say much about the IRQ probe failure, but I do have an issue
with the scanning of drives.  Pete is correct that the MAX_HWIFS
definition determines the number of ide interfaces, and ide code
will scan for drives on all of them, even if most interfaces are
not present.  In my case I know that I have only one hw interface
and was able to set this to one (1).  That way no time is wasted
in scanning non-existent interfaces. Saves a few 10s of milliseconds
at boot time :-)  It won't 'fix' the IRQ probe failure you are
seeing, but you'll certainly avoid it.

Still, I can't explain why the scanning of non-existent hwifs was
ever done this way.  I wonder if this was rectified when the IDE
subsystem was refactored in the 2.5 kernel.  I know this new IDE
code was back ported to 2.4.21 also. Let's hope things are a done
a little bit better in this new code.
 
Lyle



> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Pete Popov
> Sent: Sunday, March 30, 2003 1:35 PM
> To: Hartvig Ekner
> Cc: linux-mips
> Subject: Re: IDE initialization on AU1500?
> 
> 
> Hi Hartvig,
> 
> I added the mailing list to the CC because someone else might 
> have a better answer.
> 
> On Sun, 2003-03-30 at 10:55, Hartvig Ekner wrote:
> > Hi Pete,
> > 
> > I upgraded to the latest 2.4, and all the end_irq warnings 
> which were 
> > there a few weeks back are gone.
> 
> Yep, I got rid of the debug print :). I had put that print in 
> irq.c a long time ago, and it never caused any problems. But 
> back then, the irq probing routines were null in MIPS, so we 
> never saw the print.
> 
> > Now it looks like this:
> > 
> > Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
> > ide: Assuming 33MHz system bus speed for PIO modes; override with 
> > idebus=xx
> > PDC20268: IDE controller at PCI slot 00:0d.0
> > PDC20268: chipset revision 2
> > PDC20268: not 100% native mode: will probe irqs later
> > PDC20268: ROM enabled at 0x000dc000
> >     ide0: BM-DMA at 0x0520-0x0527, BIOS settings: hda:pio, hdb:pio
> >     ide1: BM-DMA at 0x0528-0x052f, BIOS settings: hdc:pio, hdd:pio
> > hdc: IBM-DTLA-307030, ATA DISK drive
> > blk: queue 802f7a58, I/O limit 4095Mb (mask 0xffffffff)
> > hdg: IRQ probe failed (0xfffbfffe)
> > hdg: IRQ probe failed (0xfffbbffe)
> > hdi: probing with STATUS(0x24) instead of ALTSTATUS(0x00)
> > hdi: IRQ probe failed (0xfffbfffe)
> > hdi: IRQ probe failed (0xfffbbffe)
> > hdk: probing with STATUS(0x24) instead of ALTSTATUS(0x00)
> > ide1 at 0x510-0x517,0x51a on irq 1
> > hdc: host protected area => 1
> > hdc: 60036480 sectors (30739 MB) w/1916KiB Cache, 
> CHS=59560/16/63, UDMA(100)
> > Partition check:
> >  hdc: hdc1 hdc2 hdc3 hdc4
> > 
> > Are the "IRQ probe failed" and "probing with ..." messages expected 
> > and ok?
> 
> Well, since the ide subsystem is probing all the drives, and 
> there are no drives to be found, I would have to say that the 
> failures are to be expected.
> 
> > Is there something platform
> > specific which tells the IDE driver to look for 11 drives 
> (hda-hdk) or 
> > what is
> > going on here? 
> 
> include/asm-mips/ide.h defines MAX_HWIFS 10, if not already defined.
> 
> > As you can probably tell, I don't have any specific knowledge about 
> > how the IDE initialization works and how it interacts with the 
> > platform specific code (if at all), but I would somehow 
> imagine that 
> > unless the IDE drivers detect an IDE controller (as done 
> above: ide0,
> > ide1) no probing should be performed for drives outside the 
> possible 
> > range of the detected IDE controllers (hda-hdd in this case).
> 
> That's a good point. I don't know what's going on, which is 
> why I added the mailing list to the CC. Something seems not 
> quite right.
> 
> Pete
> 


From ppopov@mvista.com Mon Mar 31 09:28:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 09:28:41 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:40177 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225192AbTCaI2k>;
	Mon, 31 Mar 2003 09:28:40 +0100
Received: from localhost (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id AAA10160;
	Mon, 31 Mar 2003 00:28:31 -0800
Subject: RE: IDE initialization on AU1500?
From: Pete Popov <ppopov@mvista.com>
To: Lyle Bainbridge <lyle@zevion.com>
Cc: "'linux-mips'" <linux-mips@linux-mips.org>
In-Reply-To: <000201c2f746$7fe683a0$1301a8c0@RADIUM>
References: <000201c2f746$7fe683a0$1301a8c0@RADIUM>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1049099444.1964.18.camel@adsl.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 31 Mar 2003 00:30:44 -0800
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: 1865
X-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
Content-Length: 4350
Lines: 119

On Sun, 2003-03-30 at 21:29, Lyle Bainbridge wrote:
> Hi,
> 
> I can say much about the IRQ probe failure, but I do have an issue
> with the scanning of drives.  Pete is correct that the MAX_HWIFS
> definition determines the number of ide interfaces, and ide code
> will scan for drives on all of them, even if most interfaces are
> not present.  In my case I know that I have only one hw interface
> and was able to set this to one (1).  That way no time is wasted
> in scanning non-existent interfaces. Saves a few 10s of milliseconds
> at boot time :-)  It won't 'fix' the IRQ probe failure you are
> seeing, but you'll certainly avoid it.
> 
> Still, I can't explain why the scanning of non-existent hwifs was
> ever done this way.  

If I'm not mistaken, this appears to be something new in 2.4.21-pre4,
where the ide subsystem is a backport of 2.5.  It would be interesting
to boot an x86 2.4.21-pre-something with the same ide subsystem and see
if it behaves the same way. 

Pete

> I wonder if this was rectified when the IDE
> subsystem was refactored in the 2.5 kernel.  I know this new IDE
> code was back ported to 2.4.21 also. Let's hope things are a done
> a little bit better in this new code.
>  
> Lyle
> 
> 
> 
> > -----Original Message-----
> > From: linux-mips-bounce@linux-mips.org 
> > [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Pete Popov
> > Sent: Sunday, March 30, 2003 1:35 PM
> > To: Hartvig Ekner
> > Cc: linux-mips
> > Subject: Re: IDE initialization on AU1500?
> > 
> > 
> > Hi Hartvig,
> > 
> > I added the mailing list to the CC because someone else might 
> > have a better answer.
> > 
> > On Sun, 2003-03-30 at 10:55, Hartvig Ekner wrote:
> > > Hi Pete,
> > > 
> > > I upgraded to the latest 2.4, and all the end_irq warnings 
> > which were 
> > > there a few weeks back are gone.
> > 
> > Yep, I got rid of the debug print :). I had put that print in 
> > irq.c a long time ago, and it never caused any problems. But 
> > back then, the irq probing routines were null in MIPS, so we 
> > never saw the print.
> > 
> > > Now it looks like this:
> > > 
> > > Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
> > > ide: Assuming 33MHz system bus speed for PIO modes; override with 
> > > idebus=xx
> > > PDC20268: IDE controller at PCI slot 00:0d.0
> > > PDC20268: chipset revision 2
> > > PDC20268: not 100% native mode: will probe irqs later
> > > PDC20268: ROM enabled at 0x000dc000
> > >     ide0: BM-DMA at 0x0520-0x0527, BIOS settings: hda:pio, hdb:pio
> > >     ide1: BM-DMA at 0x0528-0x052f, BIOS settings: hdc:pio, hdd:pio
> > > hdc: IBM-DTLA-307030, ATA DISK drive
> > > blk: queue 802f7a58, I/O limit 4095Mb (mask 0xffffffff)
> > > hdg: IRQ probe failed (0xfffbfffe)
> > > hdg: IRQ probe failed (0xfffbbffe)
> > > hdi: probing with STATUS(0x24) instead of ALTSTATUS(0x00)
> > > hdi: IRQ probe failed (0xfffbfffe)
> > > hdi: IRQ probe failed (0xfffbbffe)
> > > hdk: probing with STATUS(0x24) instead of ALTSTATUS(0x00)
> > > ide1 at 0x510-0x517,0x51a on irq 1
> > > hdc: host protected area => 1
> > > hdc: 60036480 sectors (30739 MB) w/1916KiB Cache, 
> > CHS=59560/16/63, UDMA(100)
> > > Partition check:
> > >  hdc: hdc1 hdc2 hdc3 hdc4
> > > 
> > > Are the "IRQ probe failed" and "probing with ..." messages expected 
> > > and ok?
> > 
> > Well, since the ide subsystem is probing all the drives, and 
> > there are no drives to be found, I would have to say that the 
> > failures are to be expected.
> > 
> > > Is there something platform
> > > specific which tells the IDE driver to look for 11 drives 
> > (hda-hdk) or 
> > > what is
> > > going on here? 
> > 
> > include/asm-mips/ide.h defines MAX_HWIFS 10, if not already defined.
> > 
> > > As you can probably tell, I don't have any specific knowledge about 
> > > how the IDE initialization works and how it interacts with the 
> > > platform specific code (if at all), but I would somehow 
> > imagine that 
> > > unless the IDE drivers detect an IDE controller (as done 
> > above: ide0,
> > > ide1) no probing should be performed for drives outside the 
> > possible 
> > > range of the detected IDE controllers (hda-hdd in this case).
> > 
> > That's a good point. I don't know what's going on, which is 
> > why I added the mailing list to the CC. Something seems not 
> > quite right.
> > 
> > Pete
> > 
> 
> 
> 


From quintela@mandrakesoft.com Mon Mar 31 11:50:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 11:50:20 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:49237 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225192AbTCaKuT>;
	Mon, 31 Mar 2003 11:50:19 +0100
Received: by trasno.mitica (Postfix, from userid 1001)
	id E2AEF720; Mon, 31 Mar 2003 12:50:16 +0200 (CEST)
To: "Lyle Bainbridge" <lyle@zevion.com>
Cc: "'linux-mips'" <linux-mips@linux-mips.org>
Subject: Re: IDE initialization on AU1500?
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <000201c2f746$7fe683a0$1301a8c0@RADIUM> ("Lyle Bainbridge"'s
 message of "Sun, 30 Mar 2003 23:29:28 -0600")
References: <000201c2f746$7fe683a0$1301a8c0@RADIUM>
Date: Mon, 31 Mar 2003 12:50:16 +0200
Message-ID: <86r88n4xp3.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1866
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 774
Lines: 25

>>>>> "lyle" == Lyle Bainbridge <lyle@zevion.com> writes:

Hi

lyle> Still, I can't explain why the scanning of non-existent hwifs was
lyle> ever done this way.  I wonder if this was rectified when the IDE
lyle> subsystem was refactored in the 2.5 kernel.  I know this new IDE
lyle> code was back ported to 2.4.21 also. Let's hope things are a done
lyle> a little bit better in this new code.

Just nick-pitting, it is the other way around:

- 2.4.X (X < 20 ide code)
- 2.4.X Andrew Hendrik code, lately adopted by Alan Cox.
- 2.5.X refactoring (jsut dropped)


Now 2.4.21-preX and 2.5.X (where X is something new), have the Andrew
Hendrik/Alan Cox IDE code.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From hartvig@ekner.info Mon Mar 31 13:01:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 13:01:21 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:14354 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225307AbTCaMBU>;
	Mon, 31 Mar 2003 13:01:20 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP
	id 8DAA4B597; Mon, 31 Mar 2003 14:01:17 +0200 (CEST)
Message-ID: <3E882FB8.BBFDACE2@ekner.info>
Date: Mon, 31 Mar 2003 14:08:24 +0200
From: Hartvig Ekner <hartvig@ekner.info>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Pete Popov <ppopov@mvista.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Au1500 hardware cache coherency
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <hartvig@ekner.info>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1867
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvig@ekner.info
Precedence: bulk
X-list: linux-mips
Content-Length: 1222
Lines: 22

Hi Pete,

I am attempting to use the HW coherency feature of the AU1500 to avoid SW flushes and increase the performance.
In the config-shared.in file, I can see that the CONFIG_NONCOHERENT_IO define is always set for the AMD
eval boards, which results in SW cache flushes when dma_cache_xxx functions are called. If HW coherency is
working, this define should not be set.

However, in your drivers, you only call the dma_cache functions from au1000/common/usbdev.c, but not from e.g. the ethernet
driver or the audio driver. Is this intentional? It seems that the ethernet & audio driver already relies on HW
coherency to function correctly (and it also sets the MAC enable bits accordingly, to force all ETH DMA
accesses to be coherent), so why not USB also?

When turning off NONCOHERENT_IO, there are some bugs (not in AU1000 code) which prevents the code from
compiling, but I have fixed these. And the kernel boots, but during some large disk-copy tests, I get occasional
data errors which I'm looking in to.

So before spending more time on debugging this, and creating patches for using HW coherency, I wanted to hear
your input - maybe there are known problems in the Au1500 coherency implementation?

/Hartvig



From ralf@linux-mips.net Mon Mar 31 13:01:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 13:01:51 +0100 (BST)
Received: from p508B6D12.dip.t-dialin.net ([IPv6:::ffff:80.139.109.18]:15534
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225307AbTCaMBt>; Mon, 31 Mar 2003 13:01:49 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h2VC1g221267
	for linux-mips@linux-mips.org; Mon, 31 Mar 2003 14:01:42 +0200
Date: Mon, 31 Mar 2003 14:01:42 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: Cache code changes
Message-ID: <20030331140142.A20843@linux-mips.org>
References: <20030320111625.A13219@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030320111625.A13219@linux-mips.org>; from ralf@linux-mips.org on Thu, Mar 20, 2003 at 11:16:25AM +0100
Return-Path: <ralf@linux-mips.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: 1868
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 28366
Lines: 935

So below a fix for the 32-bit 2.4 kernel to resolve the remaining cache
problems.  I tried another much more complex fix but it turned out to be
not implementable with the memory managment infrastructure provided by
Linux 2.4.

This patch also begins to exploit some of the optimizations enabled by the
new flush_dcache_page interface.  As the result this is the fastest 2.4
kernel so far.  The benefits are entirely for virtually indexed data
caches; the smaller the caches, the higher the gain.

  Ralf

diff -u -r1.22.2.5 syscall.c
--- arch/mips/kernel/syscall.c 13 Mar 2003 14:29:14 -0000
+++ arch/mips/kernel/syscall.c 31 Mar 2003 11:36:02 -0000
@@ -55,10 +55,11 @@
 	return res;
 }
 
-#define MMAP_SHARED_ALIGN 0x8000
-#define COLOUR_ALIGN(addr, pgoff)					\
-	((((addr)+ MMAP_SHARED_ALIGN - 1)&~(MMAP_SHARED_ALIGN - 1)) +	\
-	 (((pgoff) << PAGE_SHIFT) & (MMAP_SHARED_ALIGN - 1)))
+unsigned long shm_align_mask = PAGE_SIZE - 1;	/* Sane caches */
+
+#define COLOUR_ALIGN(addr,pgoff)				\
+	((((addr) + shm_align_mask) & ~shm_align_mask) +	\
+	 (((pgoff) << PAGE_SHIFT) & shm_align_mask))
 
 unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
 	unsigned long len, unsigned long pgoff, unsigned long flags)
@@ -71,7 +72,7 @@
 		 * We do not accept a shared mapping if it would violate
 		 * cache aliasing constraints.
 		 */
-		if ((flags & MAP_SHARED) && (addr & (MMAP_SHARED_ALIGN - 1)))
+		if ((flags & MAP_SHARED) && (addr & shm_align_mask))
 			return -EINVAL;
 		return addr;
 	}
diff -u -r1.27.2.11 Makefile
--- arch/mips/mm/Makefile 29 Mar 2003 04:02:49 -0000
+++ arch/mips/mm/Makefile 31 Mar 2003 11:36:02 -0000
@@ -11,7 +11,8 @@
 O_TARGET := mm.o
 
 export-objs			+= ioremap.o loadmmu.o remap.o
-obj-y				+= extable.o init.o ioremap.o fault.o loadmmu.o
+obj-y				+= cache.o extable.o init.o ioremap.o fault.o \
+				   loadmmu.o
 
 obj-$(CONFIG_CPU_R3000)		+= pg-r3k.o c-r3k.o tlb-r3k.o tlbex-r3k.o
 obj-$(CONFIG_CPU_TX39XX)	+= pg-r3k.o c-tx39.o tlb-r3k.o tlbex-r3k.o
diff -u -r1.3.2.16 c-mips32.c
--- arch/mips/mm/c-mips32.c 25 Mar 2003 14:30:19 -0000
+++ arch/mips/mm/c-mips32.c 31 Mar 2003 11:36:04 -0000
@@ -251,33 +251,14 @@
 	}
 }
 
-static void mips32_flush_dcache_page_impl(struct page *page)
+static void mips32_flush_data_cache_page(unsigned long addr)
 {
-	unsigned long addr = (unsigned long)page_address(page);
-
 	if (sc_lsize)
 		blast_scache_page(addr);
 	else
 		blast_dcache_page(addr);
 }
 
-static void mips32_flush_dcache_page(struct page *page)
-{
-	if (page->mapping && page->mapping->i_mmap == NULL &&
-	    page->mapping->i_mmap_shared == NULL) {
-		SetPageDcacheDirty(page);
-
-		return;
-	}
-
-	/*
-	 * We could delay the flush for the !page->mapping case too.  But that
-	 * case is for exec env/arg pages and those are %99 certainly going to
-	 * get faulted into the tlb (and thus flushed) anyways.
-	 */
-	mips32_flush_dcache_page_impl(page);
-}
-
 static void
 mips32_flush_icache_page_s(struct vm_area_struct *vma, struct page *page)
 {
@@ -419,21 +400,6 @@
 	}
 }
 
-void __update_cache(struct vm_area_struct *vma, unsigned long address,
-	pte_t pte)
-{
-	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
-
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
-		mips32_flush_dcache_page_impl(page);
-
-		ClearPageDcacheDirty(page);
-	}
-}
-
-
 /* Detect and size the various caches. */
 static void __init probe_icache(unsigned long config)
 {
@@ -695,9 +661,17 @@
 	probe_dcache(config);
 	setup_scache(config);
 
+	/*
+	 * XXX Some MIPS32 processors have physically indexed caches.  This
+	 * code supports virtually indexed processors and will be unnecessarily
+	 * unefficient on physically indexed processors.
+	 */
+	shm_align_mask = max_t(unsigned long, mips_cpu.dcache.sets * dc_lsize,
+	                       PAGE_SIZE) - 1;
+
 	_flush_cache_sigtramp = mips32_flush_cache_sigtramp;
-	_flush_dcache_page = mips32_flush_dcache_page;
 	_flush_icache_range = mips32_flush_icache_range;	/* Ouch */
+	_flush_data_cache_page = mips32_flush_data_cache_page;
 	_flush_icache_all = mips32_flush_icache_all;
 
 	__flush_cache_all();
diff -u -r1.4.2.6 c-r3k.c
--- arch/mips/mm/c-r3k.c 25 Mar 2003 03:26:20 -0000
+++ arch/mips/mm/c-r3k.c 31 Mar 2003 11:36:04 -0000
@@ -258,7 +258,7 @@
 {
 }
 
-static void r3k_flush_dcache_page(struct page * page)
+static void r3k_flush_data_cache_page(unsigned long addr)
 {
 }
 
@@ -314,11 +314,6 @@
 	r3k_flush_dcache_range(start, start + size);
 }
 
-void __update_cache(struct vm_area_struct *vma, unsigned long address,
-	pte_t pte)
-{
-}
-
 void __init ld_mmu_r23000(void)
 {
 	unsigned long config;
@@ -333,16 +328,16 @@
 	_flush_cache_mm = r3k_flush_cache_mm;
 	_flush_cache_range = r3k_flush_cache_range;
 	_flush_cache_page = r3k_flush_cache_page;
-	_flush_cache_sigtramp = r3k_flush_cache_sigtramp;
-	_flush_dcache_page = r3k_flush_dcache_page;
 	_flush_icache_page = r3k_flush_icache_page;
 	_flush_icache_range = r3k_flush_icache_range;
 
+	_flush_cache_sigtramp = r3k_flush_cache_sigtramp;
+	_flush_data_cache_page = r3k_flush_data_cache_page;
+
 	_dma_cache_wback_inv = r3k_dma_cache_wback_inv;
 
 	printk("Primary instruction cache %dkb, linesize %d bytes\n",
 		(int) (icache_size >> 10), (int) icache_lsize);
 	printk("Primary data cache %dkb, linesize %d bytes\n",
 		(int) (dcache_size >> 10), (int) dcache_lsize);
-
 }
diff -u -r1.3.2.23 c-r4k.c
--- arch/mips/mm/c-r4k.c 29 Mar 2003 00:48:52 -0000
+++ arch/mips/mm/c-r4k.c 31 Mar 2003 11:36:04 -0000
@@ -390,30 +390,11 @@
 	}
 }
 
-static void r4k_flush_dcache_page_impl(struct page *page)
+static void r4k_flush_data_cache_page(unsigned long addr)
 {
-	unsigned long addr = (unsigned long) page_address(page);
-
 	r4k_blast_dcache_page(addr);
 }
 
-static void r4k_flush_dcache_page(struct page *page)
-{
-	if (page->mapping && page->mapping->i_mmap == NULL &&
-	    page->mapping->i_mmap_shared == NULL) {
-		SetPageDcacheDirty(page);
-
-		return;
-	}
-
-	/*
-	 * We could delay the flush for the !page->mapping case too.  But that
-	 * case is for exec env/arg pages and those are %99 certainly going to
-	 * get faulted into the tlb (and thus flushed) anyways.
-	 */
-	r4k_flush_dcache_page_impl(page);
-}
-
 static void r4k_flush_icache_range(unsigned long start, unsigned long end)
 {
 	r4k_flush_pcache_all();
@@ -578,20 +559,6 @@
 #endif
 }
 
-void __update_cache(struct vm_area_struct *vma, unsigned long address,
-	pte_t pte)
-{
-	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
-
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
-		r4k_flush_dcache_page_impl(page);
-
-		ClearPageDcacheDirty(page);
-	}
-}
-
 static void __init probe_icache(unsigned long config)
 {
 	switch (mips_cpu.cputype) {
@@ -804,6 +771,7 @@
 {
 	unsigned long config = read_c0_config();
 	extern char except_vec2_generic;
+	unsigned int sets;
 
 	/* Default cache error handler for R4000 family */
 
@@ -822,13 +790,22 @@
 	case CPU_R5000:
 	case CPU_NEVADA:
 		_flush_cache_page = r4k_flush_cache_page_r4600;
+		sets = 1;
+		break;
+
+	default:
+		sets = 0;
+		break;
 	}
 
-	_flush_dcache_page = r4k_flush_dcache_page;
+	shm_align_mask = max_t(unsigned long,
+	                       (dcache_size >> sets) - 1, PAGE_SIZE - 1);
+
 	_flush_cache_sigtramp = r4k_flush_cache_sigtramp;
 	if ((read_c0_prid() & 0xfff0) == 0x2020) {
 		_flush_cache_sigtramp = r4600v20k_flush_cache_sigtramp;
 	}
+	_flush_data_cache_page = r4k_flush_data_cache_page;
 	_flush_icache_range = r4k_flush_icache_range;	/* Ouch */
 
 	__flush_cache_all();
diff -u -r1.4.2.8 c-r5432.c
--- arch/mips/mm/c-r5432.c 25 Mar 2003 01:11:34 -0000
+++ arch/mips/mm/c-r5432.c 31 Mar 2003 11:36:05 -0000
@@ -332,28 +332,11 @@
 	}
 }
 
-static void r5432_flush_dcache_page_impl(struct page *page)
+static void r5432_flush_data_cache_page(unsigned long addr)
 {
 	blast_dcache32_page((unsigned long)page_address(page));
 }
 
-static void r5432_flush_dcache_page(struct page *page)
-{
-	if (page->mapping && page->mapping->i_mmap == NULL &&
-	    page->mapping->i_mmap_shared == NULL) {
-		SetPageDcacheDirty(page);
-
-		return;
-	}
-
-	/*
-	 * We could delay the flush for the !page->mapping case too.  But that
-	 * case is for exec env/arg pages and those are %99 certainly going to
-	 * get faulted into the tlb (and thus flushed) anyways.
-	 */
-	r5432_flush_dcache_page_impl(page);
-}
-
 static void
 r5432_flush_icache_range(unsigned long start, unsigned long end)
 {
@@ -433,20 +416,6 @@
 	protected_flush_icache_line(addr & ~(ic_lsize - 1));
 }
 
-void __update_cache(struct vm_area_struct *vma, unsigned long address,
-	pte_t pte)
-{
-	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
-
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
-		r5432_flush_dcache_page_impl(page);
-
-		ClearPageDcacheDirty(page);
-	}
-}
-
 /* Detect and size the various r4k caches. */
 static void __init probe_icache(unsigned long config)
 {
@@ -480,21 +449,27 @@
 	probe_icache(config);
 	probe_dcache(config);
 
+	shm_align_mask = max_t(unsigned long,
+	                       (dcache_size >> 1) - 1, PAGE_SIZE - 1);
+
 	_clear_page = r5432_clear_page_d32;
 	_copy_page = r5432_copy_page_d32;
+
 	_flush_cache_all = r5432_flush_cache_all_d32i32;
 	___flush_cache_all = r5432_flush_cache_all_d32i32;
 	_flush_cache_mm = r5432_flush_cache_mm_d32i32;
 	_flush_cache_range = r5432_flush_cache_range_d32i32;
 	_flush_cache_page = r5432_flush_cache_page_d32i32;
-	_flush_dcache_page = r5432_flush_dcache_page;
+	_flush_icache_range = r5432_flush_icache_range;	/* Ouch */
 	_flush_icache_page = r5432_flush_icache_page_i32;
+
+
+	_flush_cache_sigtramp = r5432_flush_cache_sigtramp;
+	_flush_data_cache_page = r5432_flush_data_cache_page;
+
 	_dma_cache_wback_inv = r5432_dma_cache_wback_inv_pc;
 	_dma_cache_wback = r5432_dma_cache_wback;
 	_dma_cache_inv = r5432_dma_cache_inv_pc;
-
-	_flush_cache_sigtramp = r5432_flush_cache_sigtramp;
-	_flush_icache_range = r5432_flush_icache_range;	/* Ouch */
 
 	__flush_cache_all();
 }
diff -u -r1.4.2.9 c-rm7k.c
--- arch/mips/mm/c-rm7k.c 24 Mar 2003 23:49:27 -0000
+++ arch/mips/mm/c-rm7k.c 31 Mar 2003 11:36:05 -0000
@@ -90,7 +90,7 @@
 {
 }
 
-static void rm7k_flush_dcache_page(struct page * page)
+static void rm7k_flush_data_cache_page(unsigned long addr)
 {
 }
 
@@ -187,11 +187,6 @@
 	protected_flush_icache_line(addr & ~(ic_lsize - 1));
 }
 
-void __update_cache(struct vm_area_struct *vma, unsigned long address,
-	pte_t pte)
-{
-}
-
 /* Detect and size the caches. */
 static inline void probe_icache(unsigned long config)
 {
@@ -336,10 +331,13 @@
 	_flush_cache_mm = rm7k_flush_cache_mm_d32i32;
 	_flush_cache_range = rm7k_flush_cache_range_d32i32;
 	_flush_cache_page = rm7k_flush_cache_page_d32i32;
-	_flush_dcache_page = rm7k_flush_dcache_page;
-	_flush_cache_sigtramp = rm7k_flush_cache_sigtramp;
 	_flush_icache_range = rm7k_flush_icache_range;
 	_flush_icache_page = rm7k_flush_icache_page;
+
+	_flush_cache_sigtramp = rm7k_flush_cache_sigtramp;
+	_flush_data_cache_page = rm7k_flush_data_cache_page;
+
+	shm_align_mask = PAGE_SIZE - 1;
 
 	_dma_cache_wback_inv = rm7k_dma_cache_wback_inv;
 	_dma_cache_wback = rm7k_dma_cache_wback;
diff -u -r1.11.2.22 c-sb1.c
--- arch/mips/mm/c-sb1.c 12 Mar 2003 16:39:54 -0000
+++ arch/mips/mm/c-sb1.c 31 Mar 2003 11:36:07 -0000
@@ -420,11 +420,6 @@
 {
 }
 
-void __update_cache(struct vm_area_struct *vma, unsigned long address,
-	pte_t pte)
-{
-}
-
 /*
  *  Cache set values (from the mips64 spec)
  * 0 - 64
@@ -534,13 +529,14 @@
 	_flush_cache_page = (void (*)(struct vm_area_struct *, unsigned long))sb1_nop;
 	_flush_cache_mm = (void (*)(struct mm_struct *))sb1_nop;
 	_flush_cache_all = sb1_nop;
-	_flush_dcache_page = (void *) sb1_nop;
 
 	/* These routines are for Icache coherence with the Dcache */
 	_flush_icache_range = sb1_flush_icache_range;
 	_flush_icache_page = sb1_flush_icache_page;
 	_flush_icache_all = __sb1_flush_icache_all; /* local only */
+
 	_flush_cache_sigtramp = sb1_flush_cache_sigtramp;
+	_flush_data_cache_page = (void *) sb1_nop;
 
 	/* Full flush */
 	___flush_cache_all = sb1___flush_cache_all;
diff -u -r1.4.2.9 c-tx39.c
--- arch/mips/mm/c-tx39.c 25 Mar 2003 14:30:19 -0000
+++ arch/mips/mm/c-tx39.c 31 Mar 2003 11:36:07 -0000
@@ -34,7 +34,7 @@
 
 extern int r3k_have_wired_reg;	/* in r3k-tlb.c */
 
-static void tx39h_flush_dcache_page(struct page * page)
+static void tx39h_flush_data_cache_page(unsigned long addr)
 {
 }
 
@@ -204,30 +204,11 @@
 		tx39_blast_icache_page_indexed(page);
 }
 
-static void tx39_flush_dcache_page_impl(struct page *page)
+static void tx39_flush_data_cache_page(unsigned long addr)
 {
-	unsigned long addr = (unsigned long) page_address(page);
-
 	tx39_blast_dcache_page(addr);
 }
 
-static void tx39_flush_dcache_page(struct page *page)
-{
-	if (page->mapping && page->mapping->i_mmap == NULL &&
-	    page->mapping->i_mmap_shared == NULL) {
-	        SetPageDcacheDirty(page);
-
-		return;
-	}
-
-	/*
-	 * We could delay the flush for the !page->mapping case too.  But that
-	 * case is for exec env/arg pages and those are %99 certainly going to
-	 * get faulted into the tlb (and thus flushed) anyways.
-	 */
-	tx39_flush_dcache_page_impl(page);
-}
-
 static void tx39_flush_icache_range(unsigned long start, unsigned long end)
 {
 	flush_cache_all();
@@ -319,20 +300,6 @@
 	local_irq_restore(flags);
 }
 
-void __update_cache(struct vm_area_struct *vma, unsigned long address,
-	pte_t pte)
-{
-	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
-
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
-		tx39_flush_dcache_page_impl(page);
-
-		ClearPageDcacheDirty(page);
-	}
-}
-
 /* currently clear_user_page/copy_user_page needs this... */
 void __flush_dcache_all(void)
 {
@@ -384,12 +351,16 @@
 		_flush_cache_mm		= (void *) tx39h_flush_icache_all;
 		_flush_cache_range	= (void *) tx39h_flush_icache_all;
 		_flush_cache_page	= (void *) tx39h_flush_icache_all;
-		_flush_cache_sigtramp	= (void *) tx39h_flush_icache_all;
-		_flush_dcache_page	= tx39h_flush_dcache_page;
 		_flush_icache_page	= (void *) tx39h_flush_icache_all;
 		_flush_icache_range	= (void *) tx39h_flush_icache_all;
 
-		_dma_cache_wback_inv = tx39h_dma_cache_wback_inv;
+		_flush_cache_sigtramp	= (void *) tx39h_flush_icache_all;
+		_flush_data_cache_page	= (void *) tx39h_flush_icache_all;
+
+		_dma_cache_wback_inv	= tx39h_dma_cache_wback_inv;
+
+		shm_align_mask		= PAGE_SIZE - 1;
+
 		break;
 
 	case CPU_TX3922:
@@ -405,14 +376,19 @@
 		_flush_cache_mm = tx39_flush_cache_mm;
 		_flush_cache_range = tx39_flush_cache_range;
 		_flush_cache_page = tx39_flush_cache_page;
-		_flush_cache_sigtramp = tx39_flush_cache_sigtramp;
-		_flush_dcache_page = tx39_flush_dcache_page;
 		_flush_icache_page = tx39_flush_icache_page;
 		_flush_icache_range = tx39_flush_icache_range;
 
+		_flush_cache_sigtramp = tx39_flush_cache_sigtramp;
+		_flush_data_cache_page = tx39_flush_data_cache_page;
+
 		_dma_cache_wback_inv = tx39_dma_cache_wback_inv;
 		_dma_cache_wback = tx39_dma_cache_wback;
 		_dma_cache_inv = tx39_dma_cache_inv;
+
+		shm_align_mask = max_t(unsigned long,
+		                       (dcache_size / mips_cpu.dcache.ways) - 1,
+		                       PAGE_SIZE - 1);
 
 		break;
 	}
diff -u -r1.3.2.11 c-tx49.c
--- arch/mips/mm/c-tx49.c 25 Mar 2003 01:11:34 -0000
+++ arch/mips/mm/c-tx49.c 31 Mar 2003 11:36:07 -0000
@@ -174,30 +174,11 @@
 		tx49_blast_icache_page_indexed(page);
 }
 
-static void tx49_flush_dcache_page_impl(struct page *page)
+static void tx49_flush_data_cache_page(unsigned long addr)
 {
-	unsigned long addr = (unsigned long) page_address(page);
-
 	tx49_blast_dcache_page(addr);
 }
 
-static void tx49_flush_dcache_page(struct page *page)
-{
-	if (page->mapping && page->mapping->i_mmap == NULL &&
-	    page->mapping->i_mmap_shared == NULL) {
-		SetPageDcacheDirty(page);
-
-		return;
-	}
-
-	/*
-	 * We could delay the flush for the !page->mapping case too.  But that
-	 * case is for exec env/arg pages and those are %99 certainly going to
-	 * get faulted into the tlb (and thus flushed) anyways.
-	 */
-	tx49_flush_dcache_page_impl(page);
-}
-
 static void
 tx49_flush_icache_range(unsigned long start, unsigned long end)
 {
@@ -280,20 +261,6 @@
 	protected_flush_icache_line(addr & ~(ic_lsize - 1));
 }
 
-void __update_cache(struct vm_area_struct *vma, unsigned long address,
-	pte_t pte)
-{
-	struct page *page = pte_page(pte);
-	unsigned long pg_flags;
-
-	if (VALID_PAGE(page) && page->mapping &&
-	    ((pg_flags = page->flags) & (1UL << PG_dcache_dirty))) {
-		tx49_flush_dcache_page_impl(page);
-
-		ClearPageDcacheDirty(page);
-	}
-}
-
 /* currently clear_user_page/copy_user_page needs this... */
 void __flush_dcache_all(void)
 {
@@ -305,6 +272,8 @@
 {
 	icache_size = 1 << (12 + ((config >> 9) & 7));
 	ic_lsize = 16 << ((config >> 5) & 1);
+	mips_cpu.icache.ways = 1;
+	mips_cpu.icache.sets = icache_size / mips_cpu.icache.linesz;
 
 	printk("Primary instruction cache %dkb, linesize %d bytes.\n",
 	       icache_size >> 10, ic_lsize);
@@ -314,6 +283,8 @@
 {
 	dcache_size = 1 << (12 + ((config >> 6) & 7));
 	dc_lsize = 16 << ((config >> 4) & 1);
+	mips_cpu.dcache.ways = 1;
+	mips_cpu.dcache.sets = dcache_size / mips_cpu.dcache.linesz;
 
 	printk("Primary data cache %dkb, linesize %d bytes.\n",
 	       dcache_size >> 10, dc_lsize);
@@ -337,14 +308,6 @@
 
 	probe_icache(config);
 	probe_dcache(config);
-	if (mips_cpu.icache.ways == 0)
-		mips_cpu.icache.ways = 1;
-	if (mips_cpu.dcache.ways == 0)
-		mips_cpu.dcache.ways = 1;
-	mips_cpu.icache.sets =
-		icache_size / mips_cpu.icache.ways / mips_cpu.icache.linesz;
-	mips_cpu.dcache.sets =
-		dcache_size / mips_cpu.dcache.ways / mips_cpu.dcache.linesz;
 
 	switch (dc_lsize) {
 	case 16:
@@ -361,15 +324,15 @@
 	_flush_cache_mm = tx49_flush_cache_mm;
 	_flush_cache_range = tx49_flush_cache_range;
 	_flush_cache_page = tx49_flush_cache_page;
+	_flush_icache_range = tx49_flush_icache_range;	/* Ouch */
 	_flush_icache_page = tx49_flush_icache_page;
-	_flush_dcache_page = tx49_flush_dcache_page;
+
+	_flush_cache_sigtramp = tx49_flush_cache_sigtramp;
+	_flush_data_cache_page = tx49_flush_data_cache_page;
 
 	_dma_cache_wback_inv = tx49_dma_cache_wback_inv;
 	_dma_cache_wback = tx49_dma_cache_wback;
 	_dma_cache_inv = tx49_dma_cache_inv;
-
-	_flush_cache_sigtramp = tx49_flush_cache_sigtramp;
-	_flush_icache_range = tx49_flush_icache_range;	/* Ouch */
 
 	__flush_cache_all();
 }
diff -N arch/mips/mm/cache.c
--- arch/mips/mm/cache.c 1 Jan 1970 00:00:00 -0000
+++ arch/mips/mm/cache.c 31 Mar 2003 11:36:07 -0000
@@ -0,0 +1,57 @@
+/*
+ * 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) 1994 - 2003 by Ralf Baechle
+ */
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/mm.h>
+
+#include <asm/cacheflush.h>
+
+asmlinkage int sys_cacheflush(void *addr, int bytes, int cache)
+{
+	/* This should flush more selectivly ...  */
+	__flush_cache_all();
+
+	return 0;
+}
+
+void flush_dcache_page(struct page *page)
+{
+	unsigned long addr;
+
+	if (page->mapping && page->mapping->i_mmap == NULL &&
+	    page->mapping->i_mmap_shared == NULL) {
+		SetPageDcacheDirty(page);
+
+		return;
+	}
+
+	/*
+	 * We could delay the flush for the !page->mapping case too.  But that
+	 * case is for exec env/arg pages and those are %99 certainly going to
+	 * get faulted into the tlb (and thus flushed) anyways.
+	 */
+	addr = (unsigned long) page_address(page);
+	flush_data_cache_page(addr);
+}
+
+void __update_cache(struct vm_area_struct *vma, unsigned long address,
+        pte_t pte)
+{
+	struct page *page = pte_page(pte);
+	unsigned long addr;
+
+	if (VALID_PAGE(page) && page->mapping &&
+	    (page->flags & (1UL << PG_dcache_dirty))) {
+		if (pages_do_alias(page_address(page), address & PAGE_MASK)) {
+			addr = (unsigned long) page_address(page);
+			flush_data_cache_page(addr);
+		}
+
+		ClearPageDcacheDirty(page);
+	}
+}
diff -u -r1.38.2.7 init.c
--- arch/mips/mm/init.c 5 Aug 2002 23:53:35 -0000
+++ arch/mips/mm/init.c 31 Mar 2003 11:36:10 -0000
@@ -45,15 +45,6 @@
 
 extern void prom_free_prom_memory(void);
 
-
-asmlinkage int sys_cacheflush(void *addr, int bytes, int cache)
-{
-	/* This should flush more selectivly ...  */
-	__flush_cache_all();
-
-	return 0;
-}
-
 /*
  * We have upto 8 empty zeroed pages so we can map one of the right colour
  * when needed.  This is necessary only on R4000 / R4400 SC and MC versions
@@ -67,7 +58,8 @@
 {
 	unsigned long order, size;
 	struct page *page;
-	if(mips_cpu.options & MIPS_CPU_VCE)
+
+	if (mips_cpu.options & MIPS_CPU_VCE)
 		order = 3;
 	else
 		order = 0;
diff -u -r1.45.2.2 loadmmu.c
--- arch/mips/mm/loadmmu.c 12 Mar 2003 15:06:35 -0000
+++ arch/mips/mm/loadmmu.c 31 Mar 2003 11:36:10 -0000
@@ -29,11 +29,11 @@
 void (*_flush_cache_range)(struct mm_struct *mm, unsigned long start,
 			  unsigned long end);
 void (*_flush_cache_page)(struct vm_area_struct *vma, unsigned long page);
-void (*_flush_cache_sigtramp)(unsigned long addr);
 void (*_flush_icache_range)(unsigned long start, unsigned long end);
 void (*_flush_icache_page)(struct vm_area_struct *vma, struct page *page);
 
-void (*_flush_dcache_page)(struct page * page);
+void (*_flush_cache_sigtramp)(unsigned long addr);
+void (*_flush_data_cache_page)(unsigned long addr);
 void (*_flush_icache_all)(void);
 
 #ifdef CONFIG_NONCOHERENT_IO
diff -N include/asm-mips/cacheflush.h
--- include/asm-mips/cacheflush.h 1 Jan 1970 00:00:00 -0000
+++ include/asm-mips/cacheflush.h 31 Mar 2003 11:36:30 -0000
@@ -0,0 +1,69 @@
+/*
+ * 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) 1994, 95, 96, 97, 98, 99, 2000 by Ralf Baechle at alii
+ * Copyright (C) 1999 Silicon Graphics, Inc.
+ */
+#ifndef __ASM_CACHEFLUSH_H
+#define __ASM_CACHEFLUSH_H
+
+#include <linux/config.h>
+
+struct mm_struct;
+struct vm_area_struct;
+struct page;
+
+/* Cache flushing:
+ *
+ *  - flush_cache_all() flushes entire cache
+ *  - flush_cache_mm(mm) flushes the specified mm context's cache lines
+ *  - flush_cache_page(mm, vmaddr) flushes a single page
+ *  - flush_cache_range(mm, start, end) flushes a range of pages
+ *  - flush_page_to_ram(page) write back kernel page to ram
+ *  - flush_icache_range(start, end) flush a range of instructions
+ *
+ * MIPS specific flush operations:
+ *
+ *  - flush_cache_sigtramp() flush signal trampoline
+ *  - flush_icache_all() flush the entire instruction cache
+ *  - flush_data_cache_page() flushes a page from the data cache
+ */
+extern void (*_flush_cache_all)(void);
+extern void (*___flush_cache_all)(void);
+extern void (*_flush_cache_mm)(struct mm_struct *mm);
+extern void (*_flush_cache_range)(struct mm_struct *mm, unsigned long start,
+	unsigned long end);
+extern void (*_flush_cache_page)(struct vm_area_struct *vma,
+	unsigned long page);
+extern void flush_dcache_page(struct page * page);
+extern void (*_flush_icache_range)(unsigned long start, unsigned long end);
+extern void (*_flush_icache_page)(struct vm_area_struct *vma,
+	struct page *page);
+
+extern void (*_flush_cache_sigtramp)(unsigned long addr);
+extern void (*_flush_icache_all)(void);
+extern void (*_flush_data_cache_page)(unsigned long addr);
+
+#define flush_cache_all()		_flush_cache_all()
+#define __flush_cache_all()		___flush_cache_all()
+#define flush_cache_mm(mm)		_flush_cache_mm(mm)
+#define flush_cache_range(mm,start,end)	_flush_cache_range(mm,start,end)
+#define flush_cache_page(vma,page)	_flush_cache_page(vma, page)
+#define flush_page_to_ram(page)		do { } while (0)
+
+#define flush_icache_range(start, end)	_flush_icache_range(start,end)
+#define flush_icache_user_range(vma, page, addr, len) \
+					_flush_icache_page((vma), (page))
+#define flush_icache_page(vma, page) 	_flush_icache_page(vma, page)
+
+#define flush_cache_sigtramp(addr)	_flush_cache_sigtramp(addr)
+#define flush_data_cache_page(addr)	_flush_data_cache_page(addr)
+#ifdef CONFIG_VTAG_ICACHE
+#define flush_icache_all()		_flush_icache_all()
+#else
+#define flush_icache_all()		do { } while(0)
+#endif
+
+#endif /* __ASM_CACHEFLUSH_H */
diff -u -r1.14.2.12 page.h
--- include/asm-mips/page.h 28 Mar 2003 19:29:53 -0000
+++ include/asm-mips/page.h 31 Mar 2003 11:36:30 -0000
@@ -10,8 +10,6 @@
 #ifndef __ASM_PAGE_H
 #define __ASM_PAGE_H
 
-#include <linux/config.h>
-
 /* PAGE_SHIFT determines the page size */
 #define PAGE_SHIFT	12
 #define PAGE_SIZE	(1L << PAGE_SHIFT)
@@ -21,6 +19,10 @@
 
 #ifndef __ASSEMBLY__
 
+#include <linux/config.h>
+
+#include <asm/cacheflush.h>
+
 #define BUG() do { printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); *(int *)0=0; } while (0)
 #define PAGE_BUG(page) do {  BUG(); } while (0)
 
@@ -64,8 +66,32 @@
 
 #define clear_page(page)	_clear_page(page)
 #define copy_page(to, from)	_copy_page(to, from)
-#define clear_user_page(page, vaddr)	clear_page(page)
-#define copy_user_page(to, from, vaddr)	copy_page(to, from)
+
+extern unsigned long shm_align_mask;
+
+static inline unsigned long pages_do_alias(unsigned long addr1,
+	unsigned long addr2)
+{
+	return (addr1 ^ addr2) & shm_align_mask;
+}
+
+static inline void clear_user_page(void *page, unsigned long vaddr)
+{
+	unsigned long kaddr = (unsigned long) page;
+
+	clear_page(page);
+	if (pages_do_alias(kaddr, vaddr))
+		flush_data_cache_page(kaddr);
+}
+
+static inline void copy_user_page(void * to, void * from, unsigned long vaddr)
+{
+	unsigned long kto = (unsigned long) to;
+
+	copy_page(to, from);
+	if (pages_do_alias(kto, vaddr))
+		flush_data_cache_page(kto);
+}
 
 /*
  * These are used to make use of C type-checking..
diff -u -r1.63.2.17 pgtable.h
--- include/asm-mips/pgtable.h 28 Mar 2003 19:29:53 -0000
+++ include/asm-mips/pgtable.h 31 Mar 2003 11:36:31 -0000
@@ -17,55 +17,9 @@
 
 #include <linux/linkage.h>
 #include <asm/cachectl.h>
+#include <asm/cacheflush.h>
 #include <asm/fixmap.h>
 #include <asm/types.h>
-
-/* Cache flushing:
- *
- *  - flush_cache_all() flushes entire cache
- *  - flush_cache_mm(mm) flushes the specified mm context's cache lines
- *  - flush_cache_page(mm, vmaddr) flushes a single page
- *  - flush_cache_range(mm, start, end) flushes a range of pages
- *  - flush_page_to_ram(page) write back kernel page to ram
- *  - flush_icache_range(start, end) flush a range of instructions
- *
- *  - flush_cache_sigtramp() flush signal trampoline
- *  - flush_icache_all() flush the entire instruction cache
- */
-extern void (*_flush_cache_all)(void);
-extern void (*___flush_cache_all)(void);
-extern void (*_flush_cache_mm)(struct mm_struct *mm);
-extern void (*_flush_cache_range)(struct mm_struct *mm, unsigned long start,
-	unsigned long end);
-extern void (*_flush_cache_page)(struct vm_area_struct *vma,
-	unsigned long page);
-extern void (*_flush_dcache_page)(struct page * page);
-extern void (*_flush_icache_range)(unsigned long start, unsigned long end);
-extern void (*_flush_icache_page)(struct vm_area_struct *vma,
-	struct page *page);
-extern void (*_flush_cache_sigtramp)(unsigned long addr);
-extern void (*_flush_icache_all)(void);
-
-#define flush_dcache_page(page)		_flush_dcache_page(page)
-
-#define flush_cache_all()		_flush_cache_all()
-#define __flush_cache_all()		___flush_cache_all()
-#define flush_cache_mm(mm)		_flush_cache_mm(mm)
-#define flush_cache_range(mm,start,end)	_flush_cache_range(mm,start,end)
-#define flush_cache_page(vma,page)	_flush_cache_page(vma, page)
-#define flush_page_to_ram(page)		do { } while (0)
-
-#define flush_icache_range(start, end)	_flush_icache_range(start,end)
-#define flush_icache_user_range(vma, page, addr, len) \
-					_flush_icache_page((vma), (page))
-#define flush_icache_page(vma, page) 	_flush_icache_page(vma, page)
-
-#define flush_cache_sigtramp(addr)	_flush_cache_sigtramp(addr)
-#ifdef CONFIG_VTAG_ICACHE
-#define flush_icache_all()		_flush_icache_all()
-#else
-#define flush_icache_all()		do { } while(0)
-#endif
 
 /*
  * This flag is used to indicate that the page pointed to by a pte

From jbglaw@dvmwest.gt.owl.de Mon Mar 31 13:20:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 13:20:50 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:20495 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225192AbTCaMUu>; Mon, 31 Mar 2003 13:20:50 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 1AD524AB75; Mon, 31 Mar 2003 14:20:48 +0200 (CEST)
Date: Mon, 31 Mar 2003 14:20:48 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: [Patch-2.5] Small compile fix
Message-ID: <20030331122047.GJ26678@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="+9faIjRurCDpBc7U"
Content-Disposition: inline
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: 1869
X-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
Content-Length: 1283
Lines: 47


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

Hi!

I've tried to compile 2.5.x with nearly the default config. This patch
is needed (the file does exist neither exist one nor two times...).

MfG, JBG


diff -u -r1.2 i8042-ip22io.h
--- drivers/input/serio/i8042-ip22io.h	19 Mar 2003 04:23:47 -0000	1.2
+++ drivers/input/serio/i8042-ip22io.h	31 Mar 2003 12:08:20 -0000
@@ -3,8 +3,6 @@
=20
 #include <asm/sgi/ioc.h>
 #include <asm/sgi/ip22.h>
-#include <asm/sgi/sgint23.h>
-#include <asm/sgi/sgint23.h>
=20
 /*
  * This program is free software; you can redistribute it and/or modify it

--=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));

--+9faIjRurCDpBc7U
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+iDKfHb1edYOZ4bsRAoBqAJ94YghyyNJ0eptLec/NGSoSCZhNRwCdE6NW
O5Gb5B/J8g1w22dDw8dxJSw=
=zFpN
-----END PGP SIGNATURE-----

--+9faIjRurCDpBc7U--

From jbglaw@dvmwest.gt.owl.de Mon Mar 31 13:49:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 13:49:41 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:55055 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225192AbTCaMtl>; Mon, 31 Mar 2003 13:49:41 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 632784AB75; Mon, 31 Mar 2003 14:49:40 +0200 (CEST)
Date: Mon, 31 Mar 2003 14:49:40 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: [Patch-2.5] Add path to elf2ecoff
Message-ID: <20030331124940.GL26678@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="64LDleNqNegJ4g97"
Content-Disposition: inline
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: 1870
X-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
Content-Length: 1586
Lines: 55


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

Hi!

This small patch is needed since `pwd` is _not_ the directory a
Makefile resides in.

MfG, JBG


Index: arch/mips/boot/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/ftp/pub/mirror/CVS/ftp.linux-mips.org/linux/arch/mips/boot/=
Makefile,v
retrieving revision 1.22
diff -u -r1.22 Makefile
--- arch/mips/boot/Makefile	9 Mar 2003 13:58:13 -0000	1.22
+++ arch/mips/boot/Makefile	31 Mar 2003 12:38:59 -0000
@@ -32,7 +32,7 @@
 		$< $@
=20
 vmlinux.ecoff:	$(obj)/elf2ecoff vmlinux
-	./elf2ecoff vmlinux $(obj)/vmlinux.ecoff $(E2EFLAGS)
+	$(obj)/elf2ecoff vmlinux $(obj)/vmlinux.ecoff $(E2EFLAGS)
=20
 $(obj)/elf2ecoff: $(obj)/elf2ecoff.c
 	$(HOSTCC) -o $@ $^


--=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));

--64LDleNqNegJ4g97
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+iDlkHb1edYOZ4bsRAkoLAJ0aDO4aKZL2Fgc8QmaD4x/TMQwg7QCcDA7d
WbvSBw4KFYJNxRDFc73oLZU=
=gaEl
-----END PGP SIGNATURE-----

--64LDleNqNegJ4g97--

From quintela@mandrakesoft.com Mon Mar 31 14:28:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 14:28:31 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:5211 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225192AbTCaN2a>;
	Mon, 31 Mar 2003 14:28:30 +0100
Received: by trasno.mitica (Postfix, from userid 1001)
	id 2F409720; Mon, 31 Mar 2003 15:28:30 +0200 (CEST)
To: linux-mips@linux-mips.org
Subject: Re: [Patch-2.5] Add path to elf2ecoff
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030331124940.GL26678@lug-owl.de> (Jan-Benedict Glaw's
 message of "Mon, 31 Mar 2003 14:49:40 +0200")
References: <20030331124940.GL26678@lug-owl.de>
Date: Mon, 31 Mar 2003 15:28:30 +0200
Message-ID: <86fzp34qdd.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1871
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1054
Lines: 32

>>>>> "jbglaw" == Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:

jbglaw> Hi!
jbglaw> This small patch is needed since `pwd` is _not_ the directory a
jbglaw> Makefile resides in.

jbglaw> MfG, JBG


jbglaw> Index: arch/mips/boot/Makefile
jbglaw> ===================================================================
jbglaw> RCS file: /home/ftp/pub/mirror/CVS/ftp.linux-mips.org/linux/arch/mips/boot/Makefile,v
jbglaw> retrieving revision 1.22
jbglaw> diff -u -r1.22 Makefile
jbglaw> --- arch/mips/boot/Makefile	9 Mar 2003 13:58:13 -0000	1.22
jbglaw> +++ arch/mips/boot/Makefile	31 Mar 2003 12:38:59 -0000
jbglaw> @@ -32,7 +32,7 @@
jbglaw> $< $@
 
jbglaw> vmlinux.ecoff:	$(obj)/elf2ecoff vmlinux
jbglaw> -	./elf2ecoff vmlinux $(obj)/vmlinux.ecoff $(E2EFLAGS)
jbglaw> +	$(obj)/elf2ecoff vmlinux $(obj)/vmlinux.ecoff $(E2EFLAGS)
 
jbglaw> $(obj)/elf2ecoff: $(obj)/elf2ecoff.c
jbglaw> $(HOSTCC) -o $@ $^

I agree, I had to add it also to get it to compile :p


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From eric.devolder@amd.com Mon Mar 31 15:42:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 15:42:17 +0100 (BST)
Received: from amdext2.amd.com ([IPv6:::ffff:163.181.251.1]:62152 "EHLO
	amdext2.amd.com") by linux-mips.org with ESMTP id <S8225192AbTCaOmJ>;
	Mon, 31 Mar 2003 15:42:09 +0100
Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22])
	by amdext2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id h2VEc6Qo016921;
	Mon, 31 Mar 2003 08:41:59 -0600 (CST)
Received: from 163.181.250.1SAUSGW02.amd.com with ESMTP (AMD SMTP Relay
 (MMS v5.0)); Mon, 31 Mar 2003 08:41:56 -0600
X-Server-Uuid: BB5E7757-34FD-4146-B9CC-0950D472AE87
Received: from pcsmail.amd.com (pcsmail.amd.com [163.181.41.222]) by
 amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id h2VEfp2p008088; Mon,
 31 Mar 2003 08:41:51 -0600 (CST)
Received: from amd.com (PC-DEVOLDER.amd.com [163.181.60.19]) by
 pcsmail.amd.com (8.11.6/8.11.6) with ESMTP id h2VEfpa29056; Mon, 31 Mar
 2003 08:41:51 -0600
Message-ID: <3E8853B3.9080902@amd.com>
Date: Mon, 31 Mar 2003 08:41:55 -0600
From: "Eric DeVolder" <eric.devolder@amd.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1)
 Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hartvig Ekner" <hartvig@ekner.info>
cc: "Pete Popov" <ppopov@mvista.com>,
	"Linux MIPS mailing list" <linux-mips@linux-mips.org>
Subject: Re: Au1500 hardware cache coherency
References: <3E882FB8.BBFDACE2@ekner.info>
X-WSS-ID: 12968C3E2041578-01-01
Content-Type: text/plain;
 charset=us-ascii;
 format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <eric.devolder@amd.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1872
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eric.devolder@amd.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1717
Lines: 47

There are data cache snoop bugs with respect to PCI on the Au1500. For the
Au1500s soldered on DbAu1500 boards to-date, PCI can not use coherent
transactions. Details in the Specification Update for the Au1500 
available from:

www.amd.com/pcs
  -> Technical Resources
        -> AMD Alchemy Solutions Development Board Support

Login with your board and you'll be presented with various docs, 
including the
spec update.

Regards,
Eric

Hartvig Ekner wrote:

>Hi Pete,
>
>I am attempting to use the HW coherency feature of the AU1500 to avoid SW flushes and increase the performance.
>In the config-shared.in file, I can see that the CONFIG_NONCOHERENT_IO define is always set for the AMD
>eval boards, which results in SW cache flushes when dma_cache_xxx functions are called. If HW coherency is
>working, this define should not be set.
>
>However, in your drivers, you only call the dma_cache functions from au1000/common/usbdev.c, but not from e.g. the ethernet
>driver or the audio driver. Is this intentional? It seems that the ethernet & audio driver already relies on HW
>coherency to function correctly (and it also sets the MAC enable bits accordingly, to force all ETH DMA
>accesses to be coherent), so why not USB also?
>
>When turning off NONCOHERENT_IO, there are some bugs (not in AU1000 code) which prevents the code from
>compiling, but I have fixed these. And the kernel boots, but during some large disk-copy tests, I get occasional
>data errors which I'm looking in to.
>
>So before spending more time on debugging this, and creating patches for using HW coherency, I wanted to hear
>your input - maybe there are known problems in the Au1500 coherency implementation?
>
>/Hartvig
>
>
>
>
>  
>




From hartvig@ekner.info Mon Mar 31 16:07:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 16:07:51 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:19213 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225192AbTCaPHs>;
	Mon, 31 Mar 2003 16:07:48 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP
	id D88D9B5CD; Mon, 31 Mar 2003 17:07:39 +0200 (CEST)
Message-ID: <3E885B68.6927451E@ekner.info>
Date: Mon, 31 Mar 2003 17:14:48 +0200
From: Hartvig Ekner <hartvig@ekner.info>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric DeVolder <eric.devolder@amd.com>
Cc: Pete Popov <ppopov@mvista.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Au1500 hardware cache coherency
References: <3E882FB8.BBFDACE2@ekner.info> <3E8853B3.9080902@amd.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <hartvig@ekner.info>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1873
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvig@ekner.info
Precedence: bulk
X-list: linux-mips
Content-Length: 6098
Lines: 112

Hi Eric,

is that errata #12 you are referring to? (only present on silicon stepping AB?) Or are there
others also?

While using HW coherency for copying large files on disk, I do get occasional data errors
which always look like this:

  00061000  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 33 32 0a  Linie:    24832.
  00061010  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 33 33 0a  Linie:    24833.
  00061020  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 33 34 0a  Linie:    24834.
  00061030  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 33 35 0a  Linie:    24835.
  00061040  38 33 35 0a 4c 69 6e 69 65 3a 20 20 20 20 32 34  835.Linie:    24
  00061050  38 33 36 0a 4c 69 6e 69 65 3a 20 20 20 20 32 34  836.Linie:    24
  00061060  38 33 37 0a 38 33 37 0a 4c 69 6e 69 65 3a 20 20  837.837.Linie:
  00061070  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 33 39 0a  Linie:    24839.
  00061080  38 33 39 0a 4c 69 6e 69 65 3a 20 20 20 20 32 34  839.Linie:    24
  00061090  38 34 30 0a 4c 69 6e 69 65 3a 20 20 20 20 32 34  840.Linie:    24
  000610a0  38 34 31 0a 38 34 31 0a 4c 69 6e 69 65 3a 20 20  841.841.Linie:
  000610b0  20 20 32 34 65 3a 20 20 20 20 32 34 38 34 33 0a    24e:    24843.
  000610c0  38 34 33 0a 4c 69 6e 69 65 3a 20 20 20 20 32 34  843.Linie:    24
  000610d0  38 34 34 0a 4c 69 6e 69 65 3a 20 20 20 20 32 34  844.Linie:    24
  000610e0  38 34 35 0a 38 34 35 0a 4c 69 6e 69 65 3a 20 20  845.845.Linie:
  000610f0  20 20 32 34 65 3a 20 20 20 20 32 34 38 34 37 0a    24e:    24847.
  00061100  38 34 37 0a 4c 69 6e 69 65 3a 20 20 20 20 32 34  847.Linie:    24
  00061110  38 34 38 0a 4c 69 6e 69 65 3a 20 20 20 20 32 34  848.Linie:    24
  00061120  38 34 39 0a 38 34 39 0a 4c 69 6e 69 65 3a 20 20  849.849.Linie:
  00061130  20 20 32 34 65 3a 20 20 20 20 32 34 38 35 31 0a    24e:    24851.
  00061140  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 35 32 0a  Linie:    24852.
  00061150  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 35 33 0a  Linie:    24853.
  00061160  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 35 34 0a  Linie:    24854.
  00061170  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 35 35 0a  Linie:    24855.
  00061180  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 35 36 0a  Linie:    24856.
  00061190  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 35 37 0a  Linie:    24857.
  000611a0  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 35 38 0a  Linie:    24858.
  000611b0  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 35 39 0a  Linie:    24859.
  000611c0  4c 69 6e 69 65 3a 20 20 20 20 32 34 38 36 30 0a  Linie:    24860.

The file consists of 16-byte lines with increasing line numbers. Note that most of
the errors are cacheline oriented,  but there are also "skews" of 4 bytes going
into the next cacheline.

However, interestingly enough, switching HW coherency off entirely
(in PCI_CFG) and using uncached PCI buffers, there are still failures:

  001ec060  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 35 38 0a  Linie:   125958.
  001ec070  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 35 39 0a  Linie:   125959.
  001ec080  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 36 30 0a  Linie:   125960.
  001ec090  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 36 31 0a  Linie:   125961.
  001ec0a0  00 00 00 00 00 00 00 00 03 00 09 00 00 00 00 00  ................
  001ec0b0  00 00 00 00 00 00 00 00 03 00 0a 00 00 00 00 00  ................
  001ec0c0  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 36 34 0a  Linie:   125964.
  001ec0d0  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 36 35 0a  Linie:   125965.
  001ec0e0  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 36 36 0a  Linie:   125966.
  001ec0f0  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 36 37 0a  Linie:   125967.
  001ec100  00 00 00 00 00 00 00 00 10 00 00 00 c7 00 00 00  ................
  001ec110  00 00 00 00 00 00 00 00 10 00 00 00 dd 00 00 00  ................
  001ec120  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 37 30 0a  Linie:   125970.
  001ec130  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 37 31 0a  Linie:   125971.
  001ec140  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 37 32 0a  Linie:   125972.
  001ec150  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 37 33 0a  Linie:   125973.
  001ec160  4c 69 6e 69 65 3a 20 20 20 31 32 35 39 37 34 0a  Linie:   125974.

Is there anything else than bit 16 in the PCI_CFG register which needs to be set
to force non-coherent PCI accesses and avoid the PCI errata?

/Hartvig



Eric DeVolder wrote:

> There are data cache snoop bugs with respect to PCI on the Au1500. For the
> Au1500s soldered on DbAu1500 boards to-date, PCI can not use coherent
> transactions. Details in the Specification Update for the Au1500
> available from:
>
> www.amd.com/pcs
>   -> Technical Resources
>         -> AMD Alchemy Solutions Development Board Support
>
> Login with your board and you'll be presented with various docs,
> including the
> spec update.
>
> Regards,
> Eric
>
> Hartvig Ekner wrote:
>
> >Hi Pete,
> >
> >I am attempting to use the HW coherency feature of the AU1500 to avoid SW flushes and increase the performance.
> >In the config-shared.in file, I can see that the CONFIG_NONCOHERENT_IO define is always set for the AMD
> >eval boards, which results in SW cache flushes when dma_cache_xxx functions are called. If HW coherency is
> >working, this define should not be set.
> >
> >However, in your drivers, you only call the dma_cache functions from au1000/common/usbdev.c, but not from e.g. the ethernet
> >driver or the audio driver. Is this intentional? It seems that the ethernet & audio driver already relies on HW
> >coherency to function correctly (and it also sets the MAC enable bits accordingly, to force all ETH DMA
> >accesses to be coherent), so why not USB also?
> >
> >When turning off NONCOHERENT_IO, there are some bugs (not in AU1000 code) which prevents the code from
> >compiling, but I have fixed these. And the kernel boots, but during some large disk-copy tests, I get occasional
> >data errors which I'm looking in to.
> >
> >So before spending more time on debugging this, and creating patches for using HW coherency, I wanted to hear
> >your input - maybe there are known problems in the Au1500 coherency implementation?
> >
> >/Hartvig
> >


From Amit.Lubovsky@infineon.com Mon Mar 31 16:44:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 16:44:52 +0100 (BST)
Received: from smtp2.infineon.com ([IPv6:::ffff:194.175.117.77]:26531 "EHLO
	smtp2.infineon.com") by linux-mips.org with ESMTP
	id <S8225192AbTCaPou>; Mon, 31 Mar 2003 16:44:50 +0100
Received: from mucse011.eu.infineon.com (mucse011.ifx-mail1.com [172.29.27.228])
	by smtp2.infineon.com (8.12.8/8.12.8) with ESMTP id h2VFgOV1017725
	for <linux-mips@linux-mips.org>; Mon, 31 Mar 2003 17:42:24 +0200 (MEST)
Received: by mucse011.eu.infineon.com with Internet Mail Service (5.5.2653.19)
	id <2A24JQ5L>; Mon, 31 Mar 2003 17:44:44 +0200
Message-ID: <04C8EDC5AE3FD611ABE40002B39CF69B07F37F@ntah901e.savan.com>
From: Amit.Lubovsky@infineon.com
To: linux-mips@linux-mips.org
Subject: mips5kc - cpu registers
Date: Mon, 31 Mar 2003 18:45:43 +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: 1874
X-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
Content-Length: 219
Lines: 15

Hi,
is there a possibility to use cpu registers in the code (temporarily)
instead of allocating 
automatic variables something like:
	func a()
	{
		FAST int, i, tmp;
		tmp = ...
		...
	}

as in vxWorks ?

Thanks,
Amit.

From quintela@mandrakesoft.com Mon Mar 31 17:05:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 17:05:14 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:17760 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225192AbTCaQFN>;
	Mon, 31 Mar 2003 17:05:13 +0100
Received: by trasno.mitica (Postfix, from userid 1001)
	id A2EE5720; Mon, 31 Mar 2003 18:05:07 +0200 (CEST)
To: Amit.Lubovsky@infineon.com
Cc: linux-mips@linux-mips.org
Subject: Re: mips5kc - cpu registers
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <04C8EDC5AE3FD611ABE40002B39CF69B07F37F@ntah901e.savan.com> (Amit.Lubovsky@infineon.com's
 message of "Mon, 31 Mar 2003 18:45:43 +0200")
References: <04C8EDC5AE3FD611ABE40002B39CF69B07F37F@ntah901e.savan.com>
Date: Mon, 31 Mar 2003 18:05:07 +0200
Message-ID: <863cl3a5e4.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1875
X-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@mandrakesoft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 707
Lines: 27

>>>>> "amit" == Amit Lubovsky <Amit.Lubovsky@infineon.com> writes:

amit> Hi,
amit> is there a possibility to use cpu registers in the code (temporarily)
amit> instead of allocating 
amit> automatic variables something like:
amit> func a()
amit> {
amit> FAST int, i, tmp;
amit> tmp = ...
amit> ...
amit> }

theorically, 
             register int i, tmp;

should de that, but I think that no modern compiler will honour the
register keyword.  Anyways, you should be doing something really
strange for the  compiler not to choose a register for a local
variable when it should automagically.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From kevink@mips.com Mon Mar 31 18:14:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 18:14:49 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:31118 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225192AbTCaROn>;
	Mon, 31 Mar 2003 18:14:43 +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 h2VHERUe019453;
	Mon, 31 Mar 2003 09:14:27 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA03799;
	Mon, 31 Mar 2003 09:14:22 -0800 (PST)
Message-ID: <009401c2f7aa$0137f2a0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: <Amit.Lubovsky@infineon.com>, <linux-mips@linux-mips.org>
References: <04C8EDC5AE3FD611ABE40002B39CF69B07F37F@ntah901e.savan.com>
Subject: Re: mips5kc - cpu registers
Date: Mon, 31 Mar 2003 19:21:29 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
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: 1876
X-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
Content-Length: 669
Lines: 31

In general, gcc (and most other compilers)
will do this for you automatically if you enable
any reasonable level of optimization.  There
is no need to designate the variable as "FAST",
one simply needs to avoid having it be global,
static, or volatile.

----- Original Message ----- 
From: <Amit.Lubovsky@infineon.com>
To: <linux-mips@linux-mips.org>
Sent: Monday, March 31, 2003 6:45 PM
Subject: mips5kc - cpu registers


> Hi,
> is there a possibility to use cpu registers in the code (temporarily)
> instead of allocating 
> automatic variables something like:
> func a()
> {
> FAST int, i, tmp;
> tmp = ...
> ...
> }
> 
> as in vxWorks ?
> 
> Thanks,
> Amit.
> 
> 

From eric.devolder@amd.com Mon Mar 31 19:07:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 Mar 2003 19:07:10 +0100 (BST)
Received: from amdext2.amd.com ([IPv6:::ffff:163.181.251.1]:6859 "EHLO
	amdext2.amd.com") by linux-mips.org with ESMTP id <S8225192AbTCaSHJ>;
	Mon, 31 Mar 2003 19:07:09 +0100
Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22])
	by amdext2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id h2VI6pQD015639;
	Mon, 31 Mar 2003 12:06:52 -0600 (CST)
Received: from 163.181.250.1SAUSGW02.amd.com with ESMTP (AMD SMTP Relay
 (MMS v5.0)); Mon, 31 Mar 2003 12:06:49 -0600
X-Server-Uuid: BB5E7757-34FD-4146-B9CC-0950D472AE87
Received: from pcsmail.amd.com (pcsmail.amd.com [163.181.41.222]) by
 amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id h2VI6j2p018353; Mon,
 31 Mar 2003 12:06:45 -0600 (CST)
Received: from amd.com (PC-DEVOLDER.amd.com [163.181.60.19]) by
 pcsmail.amd.com (8.11.6/8.11.6) with ESMTP id h2VI6ia01844; Mon, 31 Mar
 2003 12:06:44 -0600
Message-ID: <3E8883B8.1000000@amd.com>
Date: Mon, 31 Mar 2003 12:06:48 -0600
From: "Eric DeVolder" <eric.devolder@amd.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1)
 Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hartvig Ekner" <hartvig@ekner.info>
cc: "Pete Popov" <ppopov@mvista.com>,
	"Linux MIPS mailing list" <linux-mips@linux-mips.org>
Subject: Re: Au1500 hardware cache coherency
References: <3E882FB8.BBFDACE2@ekner.info> <3E8853B3.9080902@amd.com>
 <3E885B68.6927451E@ekner.info>
X-WSS-ID: 12965C332062258-01-01
Content-Type: multipart/alternative;
 boundary=------------010607060208010703070103
Return-Path: <eric.devolder@amd.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1877
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eric.devolder@amd.com
Precedence: bulk
X-list: linux-mips
Content-Length: 14888
Lines: 322


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

Yes, this is precisely the errata; my apologies for failing to list it 
explicitly earlier.
The only other one to be aware of is that Config[OD] must be set, and 
the YAMON
booter does this, but if you ever do a R-M-W of Config, then Config[OD] 
is reset to
zero (this is errata #4).

Also, keep in mind that you need CONFIG_NONCOHERENT_IO set so that
the dma cache routines do a flush (and invalidate) to memory, and that 
these routines
need to be called at the appropriate places in the driver.

In your data dump where ther