From fxzhang@ict.ac.cn Fri Aug  1 01:40:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 01:40:38 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:45794
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225207AbTHAAkg>; Fri, 1 Aug 2003 01:40:36 +0100
Received: (qmail 23439 invoked from network); 1 Aug 2003 00:36:37 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 1 Aug 2003 00:36:37 -0000
Message-ID: <3F29B6EE.5070207@ict.ac.cn>
Date: Fri, 01 Aug 2003 08:40:14 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
References: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02>
In-Reply-To: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02>
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: 2951
X-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


Adam Kiepul wrote:

>Hi,
>
>If this is just to ensure the I Cache coherency for modified code then the following should be sufficient:
>
>cache Hit_Writeback_D, offset(base_register)
>cache Hit_Invalidate_I, offset(base_register)
>  
>
Current linux code does exactly this. But I was seeing all kinds of 
faults occuring around the
sigreturn point on the stack without a sync? And a sync does greatly 
improve the stablity.

>The ordering does matter however since the Hit_Invalidate_I makes sure the write buffer is flushed.
>
>Kind Regards,
>
>_______________________________
>
>Adam Kiepul
>Sr. Applications Engineer
>
>PMC-Sierra, Microprocessor Division
>Mission Towers One
>3975 Freedom Circle
>Santa Clara, CA 95054, USA
>Direct: 408 239 8124
>Fax: 408 492 9462
>
>
>
>-----Original Message-----
>From: Ralf Baechle [mailto:ralf@linux-mips.org]
>Sent: Thursday, July 31, 2003 4:47 AM
>To: Fuxin Zhang
>Cc: MAKE FUN PRANK CALLS
>Subject: Re: RM7k cache_flush_sigtramp
>
>
>On Thu, Jul 31, 2003 at 09:56:08AM +0800, Fuxin Zhang wrote:
>  
>
>>Date:	Thu, 31 Jul 2003 09:56:08 +0800
>>From:	Fuxin Zhang <fxzhang@ict.ac.cn>
>>To:	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
>>    
>>
>        ^^^^^^^^^^^^^^^^^^^^
>
>Funny name for the list :-)
>
>  
>
>>r4k_cache_flush_sigtrap seems not enough for RM7000 cpus because
>>there is a writebuffer between L1 dcache & L2 cache,so the written back
>>block may not be seen by icache. This small patch fixes crashes of my
>>Xserver on ev64240.
>>    
>>
>
>It would seem a similar fix is also needed in other places then?
>
>  Ralf
>
>
>  
>


From ralf@linux-mips.org Fri Aug  1 04:01:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 04:01:24 +0100 (BST)
Received: from p508B6081.dip.t-dialin.net ([IPv6:::ffff:80.139.96.129]:9901
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225207AbTHADBW>; Fri, 1 Aug 2003 04:01:22 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h7131Dx6010835;
	Fri, 1 Aug 2003 05:01:13 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h7131BqF010831;
	Fri, 1 Aug 2003 05:01:11 +0200
Date: Fri, 1 Aug 2003 05:01:11 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
Message-ID: <20030801030110.GD4197@linux-mips.org>
References: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02> <3F29B6EE.5070207@ict.ac.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F29B6EE.5070207@ict.ac.cn>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2952
X-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

Adam,

On Fri, Aug 01, 2003 at 08:40:14AM +0800, Fuxin Zhang wrote:

> Current linux code does exactly this. But I was seeing all kinds of 
> faults occuring around the
> sigreturn point on the stack without a sync? And a sync does greatly 
> improve the stablity.
> 
> >The ordering does matter however since the Hit_Invalidate_I makes sure the 
> >write buffer is flushed.

could there be an errata explaining Fuxin's findings?

Fuxin, what version are you running?

  Ralf

From fxzhang@ict.ac.cn Fri Aug  1 05:59:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 05:59:28 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:1513
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225207AbTHAE70>; Fri, 1 Aug 2003 05:59:26 +0100
Received: (qmail 11912 invoked from network); 1 Aug 2003 04:55:22 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 1 Aug 2003 04:55:22 -0000
Message-ID: <3F29F394.2030206@ict.ac.cn>
Date: Fri, 01 Aug 2003 12:59:00 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
References: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02> <3F29B6EE.5070207@ict.ac.cn> <20030801030110.GD4197@linux-mips.org>
In-Reply-To: <20030801030110.GD4197@linux-mips.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <fxzhang@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2953
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fxzhang@ict.ac.cn
Precedence: bulk
X-list: linux-mips

I am using a slightly modified 2.4.21-pre4,based on cvs of early this 
month(?).
We have merged with latest cvs, I will run it and report the result tonight.


Ralf Baechle wrote:

>Adam,
>
>On Fri, Aug 01, 2003 at 08:40:14AM +0800, Fuxin Zhang wrote:
>
>  
>
>>Current linux code does exactly this. But I was seeing all kinds of 
>>faults occuring around the
>>sigreturn point on the stack without a sync? And a sync does greatly 
>>improve the stablity.
>>
>>    
>>
>>>The ordering does matter however since the Hit_Invalidate_I makes sure the 
>>>write buffer is flushed.
>>>      
>>>
>
>could there be an errata explaining Fuxin's findings?
>
>Fuxin, what version are you running?
>
>  Ralf
>
>
>  
>


From dom@mips.com Fri Aug  1 08:53:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 08:53:46 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:35847 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225207AbTHAHxo>;
	Fri, 1 Aug 2003 08:53:44 +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 19iUkb-0006i2-00; Fri, 01 Aug 2003 08:54:57 +0100
Received: from olympia.mips.com ([192.168.192.128] helo=doms-laptop.algor.co.uk)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 19iUhQ-0003cr-00; Fri, 01 Aug 2003 08:51:40 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16170.7179.635988.268987@doms-laptop.algor.co.uk>
Date: Fri, 1 Aug 2003 08:51:39 +0100
To: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>
Cc: "'Ralf Baechle'" <ralf@linux-mips.org>,
	Fuxin Zhang <fxzhang@ict.ac.cn>, <linux-mips@linux-mips.org>
Subject: RE: RM7k cache_flush_sigtramp
In-Reply-To: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02>
References: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02>
X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-5.8, required 4, BAYES_01,
	QUOTED_EMAIL_TEXT, REFERENCES)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2954
X-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


> If this is just to ensure the I Cache coherency for modified code
> then the following should be sufficient:
> 
> cache Hit_Writeback_D, offset(base_register)
> cache Hit_Invalidate_I, offset(base_register)
> 
> The ordering does matter however since the Hit_Invalidate_I makes
> sure the write buffer is flushed.

I'm probably jumping into the middle of something, sorry... 

The MIPS32/MIPS64 release 2 architecture includes a useful instruction
SYNCI which does the whole job (repeat on each affected cache line)
and is legal in user mode; this will take a while to spread but I'd
recommend it as a model worth following.

So I hope that kernels will provide one function for "I've just
written instructions and now I want to execute them", and not export
the separate writeback-D/invalidate-I interface.

--
Dominic Sweetman
MIPS Technologies
dom@mips.com



From macro@ds2.pg.gda.pl Fri Aug  1 08:58:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 08:58:28 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:26791 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225214AbTHAH60>; Fri, 1 Aug 2003 08:58:26 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA03981;
	Fri, 1 Aug 2003 09:58:16 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 1 Aug 2003 09:58:15 +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: Malta + USB on 2.4, anyone?
In-Reply-To: <20030731111506.F14914@mvista.com>
Message-ID: <Pine.GSO.3.96.1030801095654.3800A-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: 2955
X-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, 31 Jul 2003, Jun Sun wrote:

> Using the alternative JE driver sovles the problem.  
> 
> I suspect the main UHCI driver does not get cache flushing
> or bus/virt address right.

 Well, since the JE driver is the UHCI driver for 2.6, I wouldn't care.

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


From anemo@mba.ocn.ne.jp Fri Aug  1 09:25:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 09:25:44 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:5647
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225207AbTHAIZl>; Fri, 1 Aug 2003 09:25:41 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 1 Aug 2003 08:25:40 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h718P5DV076264;
	Fri, 1 Aug 2003 17:25:05 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 01 Aug 2003 17:26:23 +0900 (JST)
Message-Id: <20030801.172623.85417982.nemoto@toshiba-tops.co.jp>
To: jsun@mvista.com
Cc: macro@ds2.pg.gda.pl, linux-mips@linux-mips.org
Subject: Re: Malta + USB on 2.4, anyone?
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030731111506.F14914@mvista.com>
References: <Pine.GSO.3.96.1030731121705.17497D-100000@delta.ds2.pg.gda.pl>
	<20030731103629.D14914@mvista.com>
	<20030731111506.F14914@mvista.com>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 2956
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Thu, 31 Jul 2003 11:15:06 -0700, Jun Sun <jsun@mvista.com> said:
jsun> I suspect the main UHCI driver does not get cache flushing or
jsun> bus/virt address right.

It seems usb_control_msg is not safe with an unaligned buffer.  Is
this patch solve your problem?

diff -u linux-2.4.21/drivers/usb/usb.c linux/drivers/usb/usb.c
--- linux-2.4.21/drivers/usb/usb.c	Tue Jul 15 13:49:34 2003
+++ linux/drivers/usb/usb.c	Tue Jul 15 21:20:44 2003
@@ -1172,9 +1172,24 @@
 {
 	struct usb_ctrlrequest *dr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL);
 	int ret;
+#ifdef __mips__ /* BUG??? */
+	void *tmpdata = NULL;
+#endif
 	
 	if (!dr)
 		return -ENOMEM;
+#ifdef __mips__ /* BUG??? */
+	if (size) {
+		tmpdata = kmalloc(size, GFP_KERNEL);
+		if (!data) {
+			kfree(dr);
+			return -ENOMEM;
+		}
+		memcpy(tmpdata, data, size);
+	} else {
+		tmpdata = data;
+	}
+#endif
 
 	dr->bRequestType = requesttype;
 	dr->bRequest = request;
@@ -1184,7 +1199,15 @@
 
 	//dbg("usb_control_msg");	
 
+#ifdef __mips__ /* BUG??? */
+	ret = usb_internal_control_msg(dev, pipe, dr, tmpdata, size, timeout);
+	if (size) {
+		memcpy(data, tmpdata, size);
+		kfree(tmpdata);
+	}
+#else
 	ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
+#endif
 
 	kfree(dr);
 
---
Atsushi Nemoto

From ralf@linux-mips.org Fri Aug  1 10:27:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 10:27:18 +0100 (BST)
Received: from p508B6D14.dip.t-dialin.net ([IPv6:::ffff:80.139.109.20]:52675
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225207AbTHAJ1H>; Fri, 1 Aug 2003 10:27:07 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h719Qtx6017992;
	Fri, 1 Aug 2003 11:26:55 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h719QoJF017991;
	Fri, 1 Aug 2003 11:26:50 +0200
Date: Fri, 1 Aug 2003 11:26:49 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Dominic Sweetman <dom@mips.com>
Cc: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	Fuxin Zhang <fxzhang@ict.ac.cn>, linux-mips@linux-mips.org
Subject: Re: RM7k cache_flush_sigtramp
Message-ID: <20030801092649.GA17624@linux-mips.org>
References: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02> <16170.7179.635988.268987@doms-laptop.algor.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16170.7179.635988.268987@doms-laptop.algor.co.uk>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2957
X-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, Aug 01, 2003 at 08:51:39AM +0100, Dominic Sweetman wrote:

> The MIPS32/MIPS64 release 2 architecture includes a useful instruction
> SYNCI which does the whole job (repeat on each affected cache line)
> and is legal in user mode; this will take a while to spread but I'd
> recommend it as a model worth following.

> So I hope that kernels will provide one function for "I've just
> written instructions and now I want to execute them", and not export
> the separate writeback-D/invalidate-I interface.

Linux supports the traditional MIPS UNIX cacheflush(2) syscall through
a libc interface.  Since I've not seen any other use for the call than
I/D-cache synchronization.  I'd just make cacheflush(3) use SYNCI where
available (Or maybe one of the other vendor specific mechanisms ...) and
fallback to cacheflush(2) where available.  Gcc would be another place
to teach about SYNCI for it's trampolines.

  Ralf

From macro@ds2.pg.gda.pl Fri Aug  1 13:05:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 13:05:44 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:31161 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225207AbTHAMFl>; Fri, 1 Aug 2003 13:05:41 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA06657;
	Fri, 1 Aug 2003 14:04:30 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 1 Aug 2003 14:04:29 +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] More time fixes: do_gettimeofday() & do_settimeofday()
Message-ID: <Pine.GSO.3.96.1030801134735.3800D-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: 2958
X-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 are fixes for do_gettimeofday() and do_settimeofday() not taking the
wall time and the value of tick properly into account.  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-20030725-mips-timeofday-0
diff -up --recursive --new-file linux-mips-2.4.21-20030725.macro/arch/mips/kernel/time.c linux-mips-2.4.21-20030725/arch/mips/kernel/time.c
--- linux-mips-2.4.21-20030725.macro/arch/mips/kernel/time.c	2003-07-25 02:56:34.000000000 +0000
+++ linux-mips-2.4.21-20030725/arch/mips/kernel/time.c	2003-07-31 21:27:18.000000000 +0000
@@ -18,6 +18,7 @@
 #include <linux/sched.h>
 #include <linux/param.h>
 #include <linux/time.h>
+#include <linux/timex.h>
 #include <linux/smp.h>
 #include <linux/kernel_stat.h>
 #include <linux/spinlock.h>
@@ -70,22 +71,23 @@ int (*rtc_set_mmss)(unsigned long);
  */
 void do_gettimeofday(struct timeval *tv)
 {
-	unsigned long flags;
+	unsigned long flags, lost;
 
 	read_lock_irqsave(&xtime_lock, flags);
+
 	*tv = xtime;
 	tv->tv_usec += do_gettimeoffset();
-
 	/*
-	 * xtime is atomically updated in timer_bh. jiffies - wall_jiffies
-	 * is nonzero if the timer bottom half hasnt executed yet.
+	 * xtime is atomically updated in timer_bh.  jiffies - wall_jiffies
+	 * is nonzero if the timer bottom half hasn't executed yet.
 	 */
-	if (jiffies - wall_jiffies)
-		tv->tv_usec += USECS_PER_JIFFY;
+	lost = jiffies - wall_jiffies;
+	if (lost)
+		tv->tv_usec += lost * tick;
 
 	read_unlock_irqrestore(&xtime_lock, flags);
 
-	if (tv->tv_usec >= 1000000) {
+	while (tv->tv_usec >= 1000000) {
 		tv->tv_usec -= 1000000;
 		tv->tv_sec++;
 	}
@@ -95,18 +97,20 @@ void do_settimeofday(struct timeval *tv)
 {
 	write_lock_irq(&xtime_lock);
 
-	/* This is revolting. We need to set the xtime.tv_usec
-	 * correctly. However, the value in this location is
-	 * is value at the last tick.
-	 * Discover what correction gettimeofday
-	 * would have done, and then undo it!
+	/*
+	 * This is revolting.  We need to set "xtime" correctly.  However,
+	 * the value in this location is the value at the most recent update
+	 * of wall time.  Discover what correction gettimeofday() would have
+	 * done, and then undo it!
 	 */
 	tv->tv_usec -= do_gettimeoffset();
+	tv->tv_usec -= (jiffies - wall_jiffies) * tick;
 
-	if (tv->tv_usec < 0) {
+	while (tv->tv_usec < 0) {
 		tv->tv_usec += 1000000;
 		tv->tv_sec--;
 	}
+
 	xtime = *tv;
 	time_adjust = 0;			/* stop active adjtime() */
 	time_status |= STA_UNSYNC;


From anemo@mba.ocn.ne.jp Fri Aug  1 14:26:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 14:26:19 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:32523
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225229AbTHAN0O>; Fri, 1 Aug 2003 14:26:14 +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; 1 Aug 2003 13:26:12 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h71DPrDV076992;
	Fri, 1 Aug 2003 22:25:54 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 01 Aug 2003 22:27:12 +0900 (JST)
Message-Id: <20030801.222712.123927329.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org
Cc: 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: <20030414.123514.74756574.nemoto@toshiba-tops.co.jp>
References: <20030412163215Z8225197-1272+1264@linux-mips.org>
	<20030414.123514.74756574.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: 2959
X-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 12:35:14 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> TOSHIBA_ICACHE_WAR can be removed.  This workaround is not
anemo> needed if kernel does not modify the cache codes itself in
anemo> run-time.

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

Very sorry, I was wrong (unfortunately).  TX49 does NOT work correctly
if CACHE instruction was issued for the line which the code exists
(even if the code was never modified in run-time).

I implemented the workaround again in another way (put the flushing
loop on an aligned place and do two phase flushing).  I did not use
"#ifdef" in c-r4k.c since gcc will be omit unnecessary codes
automatically.

This is a patch against 2.4 branch (mips version only.  mips64 is
same).  This also can be applied for 2.6 branch.  Please apply.


diff -ur linux-mips-cvs/arch/mips/mm/c-r4k.c linux.new/arch/mips/mm/c-r4k.c
--- linux-mips-cvs/arch/mips/mm/c-r4k.c	Fri Aug  1 22:03:00 2003
+++ linux.new/arch/mips/mm/c-r4k.c	Fri Aug  1 22:08:52 2003
@@ -149,6 +149,58 @@
 	goto *l;
 }
 
+/* force code alignment (used for TX49XX_ICACHE_INDEX_INV_WAR) */
+#define JUMP_TO_ALIGN(order) \
+	__asm__ __volatile__( \
+		"b\t1f\n\t" \
+		".align\t" #order "\n\t" \
+		"1:\n\t" \
+		)
+#define CACHE32_UNROLL32_ALIGN	JUMP_TO_ALIGN(10) /* 32 * 32 = 1024 */
+#define CACHE32_UNROLL32_ALIGN2	JUMP_TO_ALIGN(11)
+
+static inline void tx49_blast_icache32(void)
+{
+	unsigned long start = KSEG0;
+	unsigned long end = start + current_cpu_data.icache.waysize;
+	unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit;
+	unsigned long ws_end = current_cpu_data.icache.ways <<
+	                       current_cpu_data.icache.waybit;
+	unsigned long ws, addr;
+
+	CACHE32_UNROLL32_ALIGN2;
+	/* I'm in even chunk.  blast odd chunks */
+	for (ws = 0; ws < ws_end; ws += ws_inc) 
+		for (addr = start + 0x400; addr < end; addr += 0x400 * 2) 
+			cache32_unroll32(addr|ws,Index_Invalidate_I);
+	CACHE32_UNROLL32_ALIGN;
+	/* I'm in odd chunk.  blast even chunks */
+	for (ws = 0; ws < ws_end; ws += ws_inc) 
+		for (addr = start; addr < end; addr += 0x400 * 2) 
+			cache32_unroll32(addr|ws,Index_Invalidate_I);
+}
+
+static inline void tx49_blast_icache32_page_indexed(unsigned long page)
+{
+	unsigned long start = page;
+	unsigned long end = start + PAGE_SIZE;
+	unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit;
+	unsigned long ws_end = current_cpu_data.icache.ways <<
+	                       current_cpu_data.icache.waybit;
+	unsigned long ws, addr;
+
+	CACHE32_UNROLL32_ALIGN2;
+	/* I'm in even chunk.  blast odd chunks */
+	for (ws = 0; ws < ws_end; ws += ws_inc) 
+		for (addr = start + 0x400; addr < end; addr += 0x400 * 2) 
+			cache32_unroll32(addr|ws,Index_Invalidate_I);
+	CACHE32_UNROLL32_ALIGN;
+	/* I'm in odd chunk.  blast even chunks */
+	for (ws = 0; ws < ws_end; ws += ws_inc) 
+		for (addr = start; addr < end; addr += 0x400 * 2) 
+			cache32_unroll32(addr|ws,Index_Invalidate_I);
+}
+
 static void r4k_blast_icache_page(unsigned long addr)
 {
 	unsigned long ic_lsize = current_cpu_data.icache.linesz;
@@ -197,11 +249,18 @@
 	blast_icache64_page_indexed(addr);
 	return;
 
+ic_32_tx49:
+	tx49_blast_icache32_page_indexed(addr);
+	return;
+
 init:
 	if (ic_lsize == 16)
 		l = &&ic_16;
 	else if (ic_lsize == 32)
-		l = &&ic_32;
+		if (TX49XX_ICACHE_INDEX_INV_WAR)
+			l = &&ic_32_tx49;
+		else
+			l = &&ic_32;
 	else if (ic_lsize == 64)
 		l = &&ic_64;
 	goto *l;
@@ -226,11 +285,18 @@
 	blast_icache64();
 	return;
 
+ic_32_tx49:
+	tx49_blast_icache32();
+	return;
+
 init:
 	if (ic_lsize == 16)
 		l = &&ic_16;
 	else if (ic_lsize == 32)
-		l = &&ic_32;
+		if (TX49XX_ICACHE_INDEX_INV_WAR)
+			l = &&ic_32_tx49;
+		else
+			l = &&ic_32;
 	else if (ic_lsize == 64)
 		l = &&ic_64;
 	goto *l;
diff -ur linux-mips-cvs/include/asm-mips/war.h linux.new/include/asm-mips/war.h
--- linux-mips-cvs/include/asm-mips/war.h	Fri Aug  1 22:01:30 2003
+++ linux.new/include/asm-mips/war.h	Fri Aug  1 21:53:39 2003
@@ -148,6 +148,17 @@
 #endif
 
 /*
+ * From TX49/H2 manual: "If the instruction (i.e. CACHE) is issued for
+ * the line which this instruction itself exists, the following
+ * operation is not guaranteed."
+ *
+ * Workaround: do two phase flushing for Index_Invalidate_I
+ */
+#ifdef CONFIG_CPU_TX49XX
+#define TX49XX_ICACHE_INDEX_INV_WAR 1
+#endif
+
+/*
  * Workarounds default to off
  */
 #ifndef R4600_V1_HIT_CACHEOP_WAR
@@ -171,5 +182,8 @@
 #ifndef MIPS_CACHE_SYNC_WAR
 #define MIPS_CACHE_SYNC_WAR		0
 #endif
+#ifndef TX49XX_ICACHE_INDEX_INV_WAR
+#define TX49XX_ICACHE_INDEX_INV_WAR	0
+#endif
 
 #endif /* _ASM_WAR_H */
---
Atsushi Nemoto

From fxzhang@ict.ac.cn Fri Aug  1 15:19:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 15:19:16 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:36999
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225207AbTHAOTM>; Fri, 1 Aug 2003 15:19:12 +0100
Received: (qmail 13850 invoked from network); 1 Aug 2003 14:15:07 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 1 Aug 2003 14:15:07 -0000
Message-ID: <3F2A76CA.4080904@ict.ac.cn>
Date: Fri, 01 Aug 2003 22:18:50 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: Dominic Sweetman <dom@mips.com>,
	Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	linux-mips@linux-mips.org
Subject: Re: RM7k cache_flush_sigtramp
References: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02> <16170.7179.635988.268987@doms-laptop.algor.co.uk> <20030801092649.GA17624@linux-mips.org>
In-Reply-To: <20030801092649.GA17624@linux-mips.org>
Content-Type: text/plain; charset=gb18030; 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: 2960
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fxzhang@ict.ac.cn
Precedence: bulk
X-list: linux-mips

I just run a fresh new 2.4.21 kernel on my board, no luck.  The problem 
remains.
But I notice that my hardware may have some problems,especially with the 
add-on
ide card. Keep headaching...

As to the discussion of SYNC, I can't help wondering whether the cache 
management
should be totally hidden from programmers. People tends to write 
"safetest" code because
of all kinds of brain-damage different hardware, which leads to 
inefficient code. And this will
cancel out the potential speed benefit of simpler hardware. Also today's 
hardware seems not
as expensive as it was before...


Ralf Baechle wrote:

>On Fri, Aug 01, 2003 at 08:51:39AM +0100, Dominic Sweetman wrote:
>
>  
>
>>The MIPS32/MIPS64 release 2 architecture includes a useful instruction
>>SYNCI which does the whole job (repeat on each affected cache line)
>>and is legal in user mode; this will take a while to spread but I'd
>>recommend it as a model worth following.
>>    
>>
>
>  
>
>>So I hope that kernels will provide one function for "I've just
>>written instructions and now I want to execute them", and not export
>>the separate writeback-D/invalidate-I interface.
>>    
>>
>
>Linux supports the traditional MIPS UNIX cacheflush(2) syscall through
>a libc interface.  Since I've not seen any other use for the call than
>I/D-cache synchronization.  I'd just make cacheflush(3) use SYNCI where
>available (Or maybe one of the other vendor specific mechanisms ...) and
>fallback to cacheflush(2) where available.  Gcc would be another place
>to teach about SYNCI for it's trampolines.
>
>  Ralf
>
>
>
>  
>


From dkesselr@mmc.atmel.com Fri Aug  1 15:47:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 15:48:01 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:29085
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225233AbTHAOr6>; Fri, 1 Aug 2003 15:47:58 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA07930
	for <linux-mips@linux-mips.org>; Fri, 1 Aug 2003 10:47:51 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA07920
	for <linux-mips@linux-mips.org>; Fri, 1 Aug 2003 10:47:51 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Fri, 1 Aug 2003 10:47:51 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: sead_int.c
Message-ID: <Pine.GSO.4.44.0308011043090.7852-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2961
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

Tell me if I'm incorrect but it looks like this for condition is wrong.
There are only 2 defined irqs.

	for (i = 0; i <= SEADINT_END; i++)
	              ^^	should be just < ??

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


From Adam_Kiepul@pmc-sierra.com Fri Aug  1 16:42:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 16:43:03 +0100 (BST)
Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:42687 "HELO
	mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8225230AbTHAPm5>; Fri, 1 Aug 2003 16:42:57 +0100
Received: (qmail 17586 invoked by uid 104); 1 Aug 2003 15:42:46 -0000
Received: from Adam_Kiepul@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4281.  Clear:. 
 Processed in 0.585858 secs); 01 Aug 2003 15:42:46 -0000
Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236)
  by mother.pmc-sierra.com with SMTP; 1 Aug 2003 15:42:45 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogyruan.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id h71G9epD030282;
	Fri, 1 Aug 2003 09:09:40 -0700
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <P4MMVFK4>; Fri, 1 Aug 2003 08:42:43 -0700
Message-ID: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02>
From: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>
To: "'Fuxin Zhang'" <fxzhang@ict.ac.cn>,
	Ralf Baechle <ralf@linux-mips.org>
Cc: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: RE: RM7k cache_flush_sigtramp
Date: Fri, 1 Aug 2003 08:42:33 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Return-Path: <Adam_Kiepul@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2962
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Adam_Kiepul@pmc-sierra.com
Precedence: bulk
X-list: linux-mips

Hi Fuxin,

Could you please provide me with the _original_ Kernel code disassembly snippet around the point where your SYNC patch applies?
Also, can you check what RM7000 part revision is on your board? You can find it out by reading the PrID register.

I will check if there is an erratum that the code could trigger.

By the way, are you aware of any other ev64240 board that would exhibit the same behavior?

I would be quite careful drawing any conclusions at the moment since we can not preclude the possibility that it is simply a "bad CPU on the board" case. Please note that the SYNC instruction changes a lot in the manner things physically happen in the CPU so it can often mask off various problems, such as a bad part.

Thank you,

Adam


-----Original Message-----
From: Fuxin Zhang [mailto:fxzhang@ict.ac.cn]
Sent: Thursday, July 31, 2003 9:59 PM
To: Ralf Baechle
Cc: Adam Kiepul; MAKE FUN PRANK CALLS
Subject: Re: RM7k cache_flush_sigtramp


I am using a slightly modified 2.4.21-pre4,based on cvs of early this 
month(?).
We have merged with latest cvs, I will run it and report the result tonight.


Ralf Baechle wrote:

>Adam,
>
>On Fri, Aug 01, 2003 at 08:40:14AM +0800, Fuxin Zhang wrote:
>
>  
>
>>Current linux code does exactly this. But I was seeing all kinds of 
>>faults occuring around the
>>sigreturn point on the stack without a sync? And a sync does greatly 
>>improve the stablity.
>>
>>    
>>
>>>The ordering does matter however since the Hit_Invalidate_I makes sure the 
>>>write buffer is flushed.
>>>      
>>>
>
>could there be an errata explaining Fuxin's findings?
>
>Fuxin, what version are you running?
>
>  Ralf
>
>
>  
>

From jsun@mvista.com Fri Aug  1 18:24:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 18:24:50 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:46585 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225207AbTHARYs>;
	Fri, 1 Aug 2003 18:24:48 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h71HOhg11323;
	Fri, 1 Aug 2003 10:24:43 -0700
Date: Fri, 1 Aug 2003 10:24:43 -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] More time fixes: do_gettimeofday() & do_settimeofday()
Message-ID: <20030801102443.E11120@mvista.com>
References: <Pine.GSO.3.96.1030801134735.3800D-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.1030801134735.3800D-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Aug 01, 2003 at 02:04:29PM +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: 2963
X-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, Aug 01, 2003 at 02:04:29PM +0200, Maciej W. Rozycki wrote:
> Hello,
> 
>  Here are fixes for do_gettimeofday() and do_settimeofday() not taking the
> wall time and the value of tick properly into account.  OK to apply? 
>

That looks right to me.  I have fixed them internally, but never get around
to push into the linux-mips tree.

To be nit-picking, I might want to replace 'tick' with 'USECS_PER_JIFFY'.

Jun


From jsun@mvista.com Fri Aug  1 18:47:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Aug 2003 18:47:33 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:36599 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225207AbTHARrb>;
	Fri, 1 Aug 2003 18:47:31 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h71HlPU15176;
	Fri, 1 Aug 2003 10:47:25 -0700
Date: Fri, 1 Aug 2003 10:47:25 -0700
From: Jun Sun <jsun@mvista.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: macro@ds2.pg.gda.pl, linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Malta + USB on 2.4, anyone?
Message-ID: <20030801104725.I11120@mvista.com>
References: <Pine.GSO.3.96.1030731121705.17497D-100000@delta.ds2.pg.gda.pl> <20030731103629.D14914@mvista.com> <20030731111506.F14914@mvista.com> <20030801.172623.85417982.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030801.172623.85417982.nemoto@toshiba-tops.co.jp>; from anemo@mba.ocn.ne.jp on Fri, Aug 01, 2003 at 05:26:23PM +0900
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2964
X-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, Aug 01, 2003 at 05:26:23PM +0900, Atsushi Nemoto wrote:
> >>>>> On Thu, 31 Jul 2003 11:15:06 -0700, Jun Sun <jsun@mvista.com> said:
> jsun> I suspect the main UHCI driver does not get cache flushing or
> jsun> bus/virt address right.
> 
> It seems usb_control_msg is not safe with an unaligned buffer.  Is
> this patch solve your problem?
>

Nope.

The symptoms of erractic hw behavior seems to suggest maybe addressing
is wrong in physical space.  Just a guess.  I don't think I will spend
more time on this though. :)

Thanks for the patch.

Jun

From ppopov@mvista.com Sat Aug  2 02:49:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Aug 2003 02:49:09 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:56313 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225213AbTHBBtH>;
	Sat, 2 Aug 2003 02:49:07 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA12240
	for <linux-mips@linux-mips.org>; Fri, 1 Aug 2003 18:49:05 -0700
Subject: udelay
From: Pete Popov <ppopov@mvista.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1059788948.9224.62.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 01 Aug 2003 18:49:08 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2965
X-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

Looks like the latest udelay in 2.4 is borked. Anyway else notice that
problem?  I did a 10 sec test: mdelay works, udelay is broken, at least
for the CPU and toolchain I'm using.

Pete


From kumba@gentoo.org Sat Aug  2 03:42:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Aug 2003 03:42:44 +0100 (BST)
Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:3813 "EHLO
	sccrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225213AbTHBCmm>; Sat, 2 Aug 2003 03:42:42 +0100
Received: from gentoo.org (pcp02545003pcs.waldrf01.md.comcast.net[68.48.92.102](untrusted sender))
          by comcast.net (sccrmhc11) with SMTP
          id <2003080202423601100pmjp2e>
          (Authid: kumba12345);
          Sat, 2 Aug 2003 02:42:36 +0000
Message-ID: <3F2B2521.2060508@gentoo.org>
Date: Fri, 01 Aug 2003 22:42:41 -0400
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: udelay
References: <1059788948.9224.62.camel@zeus.mvista.com>
In-Reply-To: <1059788948.9224.62.camel@zeus.mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2966
X-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

Pete Popov wrote:

> Looks like the latest udelay in 2.4 is borked. Anyway else notice that
> problem?  I did a 10 sec test: mdelay works, udelay is broken, at least
> for the CPU and toolchain I'm using.
> 
> Pete

What's one way of testing this brokeness?  I've been trying to find some 
explanation for a bug of some sort in a cobalt RaQ2 in which the tulip 
driver (eth0) just stops dead after several minutes of use.  One of the 
notable features of the tulip driver patch needed to work on the RaQ2 
adds a "udelay(1000)" into the tulip source.  Without it, the eth0 on 
the RaQ2 is dead, so I wonder if these are related.

If they are related, then this behavior has been slowly getting worse it 
seems, as eth0 on the RaQ2 apparently has had smaller and smaller 
amounts of time needed before the interface died.  2.4.18, it took most 
of a day, by 2.4.21, it happens within seconds.

--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From debashis@alumnux.com Sat Aug  2 12:54:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Aug 2003 12:54:24 +0100 (BST)
Received: from [IPv6:::ffff:203.197.124.190] ([IPv6:::ffff:203.197.124.190]:17677
	"EHLO alumnux.com") by linux-mips.org with ESMTP
	id <S8225343AbTHBLyV>; Sat, 2 Aug 2003 12:54:21 +0100
Received: from mamata (mamata.alumnus.co.in [192.168.10.121])
	by alumnux.com (8.9.3/8.9.3) with SMTP id WAA11295
	for <linux-mips@linux-mips.org>; Sat, 2 Aug 2003 22:58:43 +0530
From: "debashis" <debashis@alumnux.com>
To: <linux-mips@linux-mips.org>
Subject: Mlata: Problem with Flash Write
Date: Sat, 2 Aug 2003 17:24:11 +0530
Message-ID: <HPEELEDLLMNGNMNENADLKEDHCAAA.debashis@alumnux.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Return-Path: <debashis@alumnux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2967
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: debashis@alumnux.com
Precedence: bulk
X-list: linux-mips

Hi,
I have a problem with writing into the FLASH of Malta board. I am trying to
describe the problem bellow. Please help me. I am using Malta 4KC box and
running Linux Kernel 2.4.18.

I have writen a File System (ext2) into Flash address 0x9E100000 using
Yamon's 'load' command.

I have also loaded my Vmlinux into RAM using Yamon's 'load' command. Now I
am trying to access the File System written into Flash (Loaded at address
0x9E100000) from vmlinux code. I am actually enabled the MTD support and
using Test RAM driver(linux/drivers/mtd/devices/mtdram.c) to get a MTD
device. The portion of the configuration is given bellow -

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
# CONFIG_MTD_PARTITIONS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CHAR is not set
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
......

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
CONFIG_MTD_MTDRAM=y
CONFIG_MTDRAM_TOTAL_SIZE=1024
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTDRAM_ABS_POS=1E100000

Also I did the small change in the mtdram.c file -

	mtd_info->type = MTD_NORFLASH;
	mtd_info->flags = MTD_CAP_NORFLASH;


Now, with the above cofiguration I am able to mount the File System from
Flash. I am able to read the files. Also I can add/delete files. However,
once I unmount the File System, none of the changes are reflected into
Flash. So next time when I mount, I am not able to view my changes. It is
all old stuff. I saw that the ram_write() function gets called during
unmount.

Do I need to use some other driver? Any test code/sample code is available
for this? Any other suggestion are welcome.

Regards,
debashis


From Geert.Uytterhoeven@sonycom.com Sat Aug  2 13:01:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Aug 2003 13:02:00 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:2264 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225343AbTHBMB4>;
	Sat, 2 Aug 2003 13:01:56 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h72C1m1W012821;
	Sat, 2 Aug 2003 14:01:48 +0200 (MEST)
Date: Sat, 2 Aug 2003 14:01:48 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Kumba <kumba@gentoo.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: udelay
In-Reply-To: <3F2B2521.2060508@gentoo.org>
Message-ID: <Pine.GSO.4.21.0308021401150.543-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: 2968
X-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, 1 Aug 2003, Kumba wrote:
> Pete Popov wrote:
> > Looks like the latest udelay in 2.4 is borked. Anyway else notice that
> > problem?  I did a 10 sec test: mdelay works, udelay is broken, at least
> > for the CPU and toolchain I'm using.
> 
> What's one way of testing this brokeness?  I've been trying to find some 
> explanation for a bug of some sort in a cobalt RaQ2 in which the tulip 
> driver (eth0) just stops dead after several minutes of use.  One of the 
> notable features of the tulip driver patch needed to work on the RaQ2 
> adds a "udelay(1000)" into the tulip source.  Without it, the eth0 on 
> the RaQ2 is dead, so I wonder if these are related.
> 
> If they are related, then this behavior has been slowly getting worse it 
> seems, as eth0 on the RaQ2 apparently has had smaller and smaller 
> amounts of time needed before the interface died.  2.4.18, it took most 
> of a day, by 2.4.21, it happens within seconds.

Any kernel messages (e.g. transmit timed out) from the tulip driver when it
dies?

Gr{oetje,eeting}s,

						Geert

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

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


From ralf@linux-mips.org Sat Aug  2 17:52:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Aug 2003 17:52:58 +0100 (BST)
Received: from p508B60FA.dip.t-dialin.net ([IPv6:::ffff:80.139.96.250]:10166
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225344AbTHBQwy>; Sat, 2 Aug 2003 17:52:54 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h72GqqpR004831;
	Sat, 2 Aug 2003 18:52:52 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h72GqpRe004830;
	Sat, 2 Aug 2003 18:52:51 +0200
Date: Sat, 2 Aug 2003 18:52:50 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: sead_int.c
Message-ID: <20030802165250.GA3697@linux-mips.org>
References: <Pine.GSO.4.44.0308011043090.7852-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0308011043090.7852-100000@ares.mmc.atmel.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2969
X-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, Aug 01, 2003 at 10:47:51AM -0400, David Kesselring wrote:

> Tell me if I'm incorrect but it looks like this for condition is wrong.
> There are only 2 defined irqs.
> 
> 	for (i = 0; i <= SEADINT_END; i++)
> 	              ^^	should be just < ??

Looks like you're right ...

  Ralf

From ralf@linux-mips.org Sat Aug  2 18:02:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Aug 2003 18:02:58 +0100 (BST)
Received: from p508B60FA.dip.t-dialin.net ([IPv6:::ffff:80.139.96.250]:52918
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225347AbTHBRC4>; Sat, 2 Aug 2003 18:02:56 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h72H2opR005047;
	Sat, 2 Aug 2003 19:02:50 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h72H2kua005046;
	Sat, 2 Aug 2003 19:02:46 +0200
Date: Sat, 2 Aug 2003 19:02:46 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: Dominic Sweetman <dom@mips.com>,
	Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	linux-mips@linux-mips.org
Subject: Re: RM7k cache_flush_sigtramp
Message-ID: <20030802170245.GA19401@linux-mips.org>
References: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02> <16170.7179.635988.268987@doms-laptop.algor.co.uk> <20030801092649.GA17624@linux-mips.org> <3F2A76CA.4080904@ict.ac.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F2A76CA.4080904@ict.ac.cn>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2970
X-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, Aug 01, 2003 at 10:18:50PM +0800, Fuxin Zhang wrote:

> I just run a fresh new 2.4.21 kernel on my board, no luck.  The problem 
> remains.  But I notice that my hardware may have some problems,
> especially with the add-on ide card. Keep headaching...
> 
> As to the discussion of SYNC, I can't help wondering whether the cache 
> management should be totally hidden from programmers. People tends to
> write "safetest" code because of all kinds of brain-damage different
> hardware, which leads to inefficient code. And this will cancel out the
> potential speed benefit of simpler hardware. Also today's hardware seems
> not as expensive as it was before...

Cache managment needs to be somehow hidden from programmers as well as
possible - the average programmer has no clue about how caches work.
We've come up with an API that hides the actual functioning of caches
pretty well for DMA devices, see Documentation/DMA-mapping.txt and in
2.6 also a more generalized version documented in Documentation/DMA-API.txt.

  Ralf

From ralf@linux-mips.org Sat Aug  2 18:05:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Aug 2003 18:05:48 +0100 (BST)
Received: from p508B60FA.dip.t-dialin.net ([IPv6:::ffff:80.139.96.250]:2231
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225347AbTHBRFq>; Sat, 2 Aug 2003 18:05:46 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h72H5hpR005112;
	Sat, 2 Aug 2003 19:05:43 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h72H5gLi005111;
	Sat, 2 Aug 2003 19:05:42 +0200
Date: Sat, 2 Aug 2003 19:05:42 +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] More time fixes: do_gettimeofday() & do_settimeofday()
Message-ID: <20030802170542.GB19401@linux-mips.org>
References: <Pine.GSO.3.96.1030801134735.3800D-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.1030801134735.3800D-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2971
X-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, Aug 01, 2003 at 02:04:29PM +0200, Maciej W. Rozycki wrote:

>  Here are fixes for do_gettimeofday() and do_settimeofday() not taking the
> wall time and the value of tick properly into account.  OK to apply? 

Yes, looks good.  One user less of USECS_PER_JIFFY ...

  Ralf

From kumba@gentoo.org Sat Aug  2 21:41:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Aug 2003 21:42:04 +0100 (BST)
Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:63383 "EHLO
	sccrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225213AbTHBUl7>; Sat, 2 Aug 2003 21:41:59 +0100
Received: from gentoo.org (pcp02545003pcs.waldrf01.md.comcast.net[68.48.92.102](untrusted sender))
          by comcast.net (sccrmhc12) with SMTP
          id <20030802204152012005ke30e>
          (Authid: kumba12345);
          Sat, 2 Aug 2003 20:41:52 +0000
Message-ID: <3F2C2217.5010006@gentoo.org>
Date: Sat, 02 Aug 2003 16:41:59 -0400
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: udelay
References: <Pine.GSO.4.21.0308021401150.543-100000@vervain.sonytel.be>
In-Reply-To: <Pine.GSO.4.21.0308021401150.543-100000@vervain.sonytel.be>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2972
X-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

Geert Uytterhoeven wrote:

> Any kernel messages (e.g. transmit timed out) from the tulip driver when it
> dies?

None that I can see.  If I'm using SSH, input/output just stops cold. 
In some cases, I have noticed that if you send a single character (like 
you were in a text editor when input/output died), and you wait a minute 
or so, it will appear.  This seems to mean the interface hasn't died 
completely, but seems to havce slowed down to the point of complete 
unsuability, like >1bps would be my guess.

Restarting the interface fixes it for several seconds until it drops 
again.  I usually disconnect from the serial console before trying any 
SSH activity, as serial console work + network activity can halt the 
kernel (which I have confirmed does occur in 2.4.21 CVS).

As an experiment, I did try replacing the udelay(1000) line in the 
cobalt patch with mdelay(1) to see if this udelay() brokeness was the 
issue, but it still drops out after several seconds.

--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From ralf@linux-mips.org Mon Aug  4 02:41:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 02:41:37 +0100 (BST)
Received: from p508B6AA9.dip.t-dialin.net ([IPv6:::ffff:80.139.106.169]:48317
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225213AbTHDBlf>; Mon, 4 Aug 2003 02:41:35 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h741fXpR004443;
	Mon, 4 Aug 2003 03:41:33 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h741fWB5004442;
	Mon, 4 Aug 2003 03:41:32 +0200
Date: Mon, 4 Aug 2003 03:41:32 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: udelay
Message-ID: <20030804014132.GA4419@linux-mips.org>
References: <1059788948.9224.62.camel@zeus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1059788948.9224.62.camel@zeus.mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2973
X-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, Aug 01, 2003 at 06:49:08PM -0700, Pete Popov wrote:

> Looks like the latest udelay in 2.4 is borked. Anyway else notice that
> problem?  I did a 10 sec test: mdelay works, udelay is broken, at least
> for the CPU and toolchain I'm using.

That just doesn't make sense.  Mdelay is based on udelay so if udelay
is broken mdelay should be broken, too.

  Ralf

From fxzhang@ict.ac.cn Mon Aug  4 04:38:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 04:39:01 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:27333
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225333AbTHDDi7>; Mon, 4 Aug 2003 04:38:59 +0100
Received: (qmail 15037 invoked from network); 4 Aug 2003 03:34:17 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 4 Aug 2003 03:34:17 -0000
Message-ID: <3F2DD534.1010905@ict.ac.cn>
Date: Mon, 04 Aug 2003 11:38:28 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>
CC: Ralf Baechle <ralf@linux-mips.org>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
References: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02>
In-Reply-To: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02>
Content-Type: text/plain; charset=gb18030; format=flowed
Content-Transfer-Encoding: 8bit
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: 2974
X-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

Hi Adam,
   
   My cpu PRID:  0x2732, runs at freq 133x2MHz

disassemble code before patch:

ffffffff8010f2fc <r4k_flush_cache_sigtramp>:
ffffffff8010f2fc:	3c03802c 	lui	v1,0x802c
ffffffff8010f300:	246367ec 	addiu	v1,v1,26604
ffffffff8010f304:	94620010 	lhu	v0,16(v1)
ffffffff8010f308:	94650000 	lhu	a1,0(v1)
ffffffff8010f30c:	00021023 	negu	v0,v0
ffffffff8010f310:	00821024 	and	v0,a0,v0
ffffffff8010f314:	bc550000 	cache	0x15,0(v0)
ffffffff8010f318:	00052823 	negu	a1,a1
ffffffff8010f31c:	00852024 	and	a0,a0,a1
ffffffff8010f320:	bc900000 	cache	0x10,0(a0)
ffffffff8010f324:	03e00008 	jr	ra
ffffffff8010f328:	00000000 	nop

disassemble code after patch:
ffffffff8010ceb0 <r4k_flush_cache_sigtramp>:
ffffffff8010ceb0:	3c03802f 	lui	v1,0x802f
ffffffff8010ceb4:	2463e3ac 	addiu	v1,v1,-7252
ffffffff8010ceb8:	94620010 	lhu	v0,16(v1)
ffffffff8010cebc:	94650000 	lhu	a1,0(v1)
ffffffff8010cec0:	00021023 	negu	v0,v0
ffffffff8010cec4:	00821024 	and	v0,a0,v0
ffffffff8010cec8:	bc550000 	cache	0x15,0(v0)
ffffffff8010cecc:	0000000f 	sync
ffffffff8010ced0:	00052823 	negu	a1,a1
ffffffff8010ced4:	00852024 	and	a0,a0,a1
ffffffff8010ced8:	bc900000 	cache	0x10,0(a0)
ffffffff8010cedc:	03e00008 	jr	ra
ffffffff8010cee0:	00000000 	nop


We do have more than one set of ev64240 and RM7k cpu��but it will take 
some time for
me to get another one for test. I will tell you the result once i do it.

Thank you.
 

Adam Kiepul wrote:

>Hi Fuxin,
>
>Could you please provide me with the _original_ Kernel code disassembly snippet around the point where your SYNC patch applies?
>Also, can you check what RM7000 part revision is on your board? You can find it out by reading the PrID register.
>
>I will check if there is an erratum that the code could trigger.
>
>By the way, are you aware of any other ev64240 board that would exhibit the same behavior?
>
>I would be quite careful drawing any conclusions at the moment since we can not preclude the possibility that it is simply a "bad CPU on the board" case. Please note that the SYNC instruction changes a lot in the manner things physically happen in the CPU so it can often mask off various problems, such as a bad part.
>
>Thank you,
>
>Adam
>
>
>-----Original Message-----
>From: Fuxin Zhang [mailto:fxzhang@ict.ac.cn]
>Sent: Thursday, July 31, 2003 9:59 PM
>To: Ralf Baechle
>Cc: Adam Kiepul; MAKE FUN PRANK CALLS
>Subject: Re: RM7k cache_flush_sigtramp
>
>
>I am using a slightly modified 2.4.21-pre4,based on cvs of early this 
>month(?).
>We have merged with latest cvs, I will run it and report the result tonight.
>
>
>Ralf Baechle wrote:
>
>  
>
>>Adam,
>>
>>On Fri, Aug 01, 2003 at 08:40:14AM +0800, Fuxin Zhang wrote:
>>
>> 
>>
>>    
>>
>>>Current linux code does exactly this. But I was seeing all kinds of 
>>>faults occuring around the
>>>sigreturn point on the stack without a sync? And a sync does greatly 
>>>improve the stablity.
>>>
>>>   
>>>
>>>      
>>>
>>>>The ordering does matter however since the Hit_Invalidate_I makes sure the 
>>>>write buffer is flushed.
>>>>     
>>>>
>>>>        
>>>>
>>could there be an errata explaining Fuxin's findings?
>>
>>Fuxin, what version are you running?
>>
>> Ralf
>>
>>
>> 
>>
>>    
>>
>
>
>
>  
>


From dom@mips.com Mon Aug  4 11:04:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 11:04:27 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:43529 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225334AbTHDKEQ>;
	Mon, 4 Aug 2003 11:04:16 +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 19jcDK-0001ct-00; Mon, 04 Aug 2003 11:05:14 +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 19jayF-0003wJ-00; Mon, 04 Aug 2003 09:45:35 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16174.7469.845997.741559@gladsmuir.mips.com>
Date: Mon, 4 Aug 2003 09:45:33 +0100
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>,
	Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	Fuxin Zhang <fxzhang@ict.ac.cn>, linux-mips@linux-mips.org
Subject: Re: RM7k cache_flush_sigtramp
In-Reply-To: <20030801092649.GA17624@linux-mips.org>
References: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02>
	<16170.7179.635988.268987@doms-laptop.algor.co.uk>
	<20030801092649.GA17624@linux-mips.org>
X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-0.8, required 4, AWL,
	QUOTED_EMAIL_TEXT, REFERENCES)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2975
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips


Ralf,

> Linux supports the traditional MIPS UNIX cacheflush(2) syscall through
> a libc interface.  Since I've not seen any other use for the call than
> I/D-cache synchronization.  I'd just make cacheflush(3) use SYNCI where
> available...

SYNCI just does what's required to execute code you just wrote: that's
a D-cache writeback and an I-cache invalidate.  It doesn't invalidate
the D-cache afterwards, which is required by the definition of
cacheflush(3).

I think it would be better to provide cache manipulation calls defined
top-down (by their purpose); but so long as we are stuck with calls
which are defined as performing particular low-level actions, it's
surely dangerous to guess that we know what they are used for so we
can trim the functions accordingly...

--
Dominic Sweetman
MIPS Technologies




From macro@ds2.pg.gda.pl Mon Aug  4 12:52:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 12:52:16 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:13565 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225213AbTHDLwM>; Mon, 4 Aug 2003 12:52:12 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA17309;
	Mon, 4 Aug 2003 13:51:58 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 4 Aug 2003 13:51:57 +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>,
	Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	Fuxin Zhang <fxzhang@ict.ac.cn>, linux-mips@linux-mips.org
Subject: Re: RM7k cache_flush_sigtramp
In-Reply-To: <16174.7469.845997.741559@gladsmuir.mips.com>
Message-ID: <Pine.GSO.3.96.1030804134034.17066B-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: 2976
X-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

Dominic,

> I think it would be better to provide cache manipulation calls defined
> top-down (by their purpose); but so long as we are stuck with calls
> which are defined as performing particular low-level actions, it's
> surely dangerous to guess that we know what they are used for so we
> can trim the functions accordingly...

 The API is not cast in stone -- if there's a justifiable benefit,
appropriate fuctions can be added; either completely new ones (possibly
inlined) or as an extension to cacheflush() (which still has 30 bits
freely available). 

  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 Mon Aug  4 15:29:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 15:29:18 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:49544 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225213AbTHDO3N>; Mon, 4 Aug 2003 15:29:13 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA18966;
	Mon, 4 Aug 2003 16:29:06 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 4 Aug 2003 16:29:06 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] More time fixes: do_gettimeofday() & do_settimeofday()
In-Reply-To: <20030801102443.E11120@mvista.com>
Message-ID: <Pine.GSO.3.96.1030804162531.17066F-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: 2977
X-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, 1 Aug 2003, Jun Sun wrote:

> To be nit-picking, I might want to replace 'tick' with 'USECS_PER_JIFFY'.

 OK -- since I want to keep USECS_PER_JIFFY_FRAC as otherwise
unrecoverable, I decided to keep USECS_PER_JIFFY as well for consistency. 
But that's only after (or together with) the next patch. 

-- 
+  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 Aug  4 15:31:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 15:31:26 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:61064 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225213AbTHDObW>; Mon, 4 Aug 2003 15:31:22 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA18988;
	Mon, 4 Aug 2003 16:31:19 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 4 Aug 2003 16:31:19 +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] More time fixes: do_gettimeofday() & do_settimeofday()
In-Reply-To: <20030802170542.GB19401@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030804162919.17066G-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: 2978
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Sat, 2 Aug 2003, Ralf Baechle wrote:

> >  Here are fixes for do_gettimeofday() and do_settimeofday() not taking the
> > wall time and the value of tick properly into account.  OK to apply? 
> 
> Yes, looks good.  One user less of USECS_PER_JIFFY ...

 Actually, I decided to keep USECS_PER_JIFFY, only redefining it more
sanely.

-- 
+  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 Aug  4 17:35:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 17:35:12 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:62353 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225245AbTHDQfG>; Mon, 4 Aug 2003 17:35:06 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA20158;
	Mon, 4 Aug 2003 18:34:58 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 4 Aug 2003 18:34:57 +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: linux-mips@linux-mips.org
Subject: [patch] 2.6: More time fixes: do_gettimeofday() & do_settimeofday()
Message-ID: <Pine.GSO.3.96.1030804183025.17066H-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: 2979
X-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 the respective update for the trunk.  OK?

 I think the code in the trunk and in the 2.4 branch can be further
unified.  Removing syntactic inconsistencies will lead to easier
cross-version maintenance.

  Maciej

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

patch-mips-2.6.0-test2-20030804-mips-timeofday-1
diff -up --recursive --new-file linux-mips-2.6.0-test2-20030804.macro/arch/mips/kernel/time.c linux-mips-2.6.0-test2-20030804/arch/mips/kernel/time.c
--- linux-mips-2.6.0-test2-20030804.macro/arch/mips/kernel/time.c	Thu Jul 31 14:54:57 2003
+++ linux-mips-2.6.0-test2-20030804/arch/mips/kernel/time.c	Mon Aug  4 15:28:28 2003
@@ -18,6 +18,7 @@
 #include <linux/sched.h>
 #include <linux/param.h>
 #include <linux/time.h>
+#include <linux/timex.h>
 #include <linux/smp.h>
 #include <linux/kernel_stat.h>
 #include <linux/spinlock.h>
@@ -76,18 +77,21 @@ int (*rtc_set_mmss)(unsigned long);
 void do_gettimeofday(struct timeval *tv)
 {
 	unsigned long seq;
+	unsigned long lost;
 	unsigned long usec, sec;
 
 	do {
 		seq = read_seqbegin(&xtime_lock);
+
 		usec = do_gettimeoffset();
-		{
-			unsigned long lost = jiffies - wall_jiffies;
-			if (lost)
-				usec += lost * (1000000 / HZ);
-		}
+
+		lost = jiffies - wall_jiffies;
+		if (lost)
+			usec += lost * TICK_SIZE;
+
 		sec = xtime.tv_sec;
 		usec += (xtime.tv_nsec / 1000);
+
 	} while (read_seqretry(&xtime_lock, seq));
 
 	while (usec >= 1000000) {
@@ -108,14 +112,15 @@ int do_settimeofday(struct timespec *tv)
 		return -EINVAL;
 
 	write_seqlock_irq(&xtime_lock);
+
 	/*
-	 * This is revolting. We need to set "xtime" correctly. However, the
-	 * value in this location is the value at the most recent update of
-	 * wall time.  Discover what correction gettimeofday() would have
+	 * This is revolting.  We need to set "xtime" correctly.  However,
+	 * the value in this location is the value at the most recent update
+	 * of wall time.  Discover what correction gettimeofday() would have
 	 * made, and then undo it!
 	 */
 	nsec -= do_gettimeoffset() * NSEC_PER_USEC;
-	nsec -= (jiffies - wall_jiffies) * TICK_NSEC;
+	nsec -= (jiffies - wall_jiffies) * tick_nsec;
 
 	wtm_sec  = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
 	wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);
@@ -123,10 +128,11 @@ int do_settimeofday(struct timespec *tv)
 	set_normalized_timespec(&xtime, sec, nsec);
 	set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec);
 
-	time_adjust = 0;		/* stop active adjtime() */
+	time_adjust = 0;			/* stop active adjtime() */
 	time_status |= STA_UNSYNC;
 	time_maxerror = NTP_PHASE_LIMIT;
 	time_esterror = NTP_PHASE_LIMIT;
+
 	write_sequnlock_irq(&xtime_lock);
 
 	return 0;


From macro@ds2.pg.gda.pl Mon Aug  4 18:19:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 18:19:39 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:21909 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224772AbTHDRTg>; Mon, 4 Aug 2003 18:19:36 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA20895;
	Mon, 4 Aug 2003 19:19:33 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 4 Aug 2003 19:19:32 +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: linux-mips@linux-mips.org
Subject: [patch] Time handling: now the big changes
Message-ID: <Pine.GSO.3.96.1030804183710.17066I-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: 2980
X-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,

 Now it's the time for the big changes.  The following patch adds a
pluggable handlers capability to the generic MIPS time handler.  Now most,
if not all systems can use the code, e.g. ones that fit one of the
following models: 

1. No external high precision timer (HPT), no R4k timer, an external timer
IRQ. 

2. An external HPT, no R4k timer, an external timer IRQ.

3. No external HPT, an R4k timer, an external timer IRQ. 

4. No external HPT, an R4k timer, an R4k timer IRQ. 

If a system has both an external HPT and an R4k timer, it can select which
one to use (e.g. based on the designed clock stability).  If a system has
both an external timer IRQ and an R4k timer IRQ, it can also select which
one to use (e.g. based on the flexibility of available intervals).

 Three pluggable handlers are available:

- mips_timer_ack() -- used to send an acknowledge to the originator of the
timer IRQ.  It may be used to reprogram a one-shot kind of IRQ source,
such as the R4k timer IRQ.  If unset by a board-specific backend, it
defaults to an R4k-specific handler if an R4k timer is available and its
driving frequency is known, otherwise it's set to a null handler (which
still makes sense for self-recoverable sources).

- mips_hpt_read() -- used to read a HPT.  If unset by a board-specific
backend, it defaults to an R4k-specific handler if an R4k timer is
available otherwise it's set to a null handler that always returns zeor
(no offsets to jiffies).

- mips_hpt_init() -- used to initialize a HPT.  It has a bit non-obvious
semantics: its argument is to be subtracted from the current value of the
HPT.  It's an aid for handling jiffy overflows (which are rare and thus
should be handled especially carefully -- hardly anyone will notice a
problem here, so once one happens it may be a complete disaster) -- if a
direct initialization is needed, "mips_hpt_init(mips_hpt_read() - <v>)"
can be used.  If in doubt, use the source, Luke.  Its default
initialization depends on mips_hpt_read() (the function makes no sense
alone): if that function is unset, it defaults to an R4k-specific handler
if an R4k timer is available, otherwise it's set to a null handler. 

 In addition to the above changes, a few fixes are included:

- USECS_PER_JIFFY is now set to tick,

- USECS_PER_JIFFY_FRAC is now properly zero-extended,

- division in calibrate_div64_gettimeoffset() now propely makes use of
USECS_PER_JIFFY_FRAC (for better accuracy), plus missing clobbers are
added,

- jiffies overflow trigger resets the HPT,

- internal gettimeoffset() functions are now static as they do not need to
be referred to externally.

 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-20030725-mips-time-6
diff -up --recursive --new-file linux-mips-2.4.21-20030725.macro/arch/mips/kernel/time.c linux-mips-2.4.21-20030725/arch/mips/kernel/time.c
--- linux-mips-2.4.21-20030725.macro/arch/mips/kernel/time.c	2003-07-31 21:27:18.000000000 +0000
+++ linux-mips-2.4.21-20030725/arch/mips/kernel/time.c	2003-08-03 17:43:49.000000000 +0000
@@ -31,9 +31,14 @@
 #include <asm/hardirq.h>
 #include <asm/div64.h>
 
-/* This is for machines which generate the exact clock. */
-#define USECS_PER_JIFFY (1000000/HZ)
-#define USECS_PER_JIFFY_FRAC ((u32)((1000000ULL << 32) / HZ))
+/*
+ * The integer part of the number of usecs per jiffy is taken from tick,
+ * but the fractional part is not recorded, so we calculate it using the
+ * initial value of HZ.  This aids systems where tick isn't really an
+ * integer (e.g. for HZ = 128).
+ */
+#define USECS_PER_JIFFY		tick
+#define USECS_PER_JIFFY_FRAC	((unsigned long)(u32)((1000000ULL << 32) / HZ))
 
 /*
  * forward reference
@@ -48,6 +53,7 @@ spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED
  */
 int emulate_local_timer_interrupt;
 
+
 /*
  * By default we provide the null RTC ops
  */
@@ -66,6 +72,84 @@ int (*rtc_set_time)(unsigned long) = nul
 int (*rtc_set_mmss)(unsigned long);
 
 
+/* usecs per counter cycle, shifted to left by 32 bits */
+static unsigned int sll32_usecs_per_cycle;
+
+/* how many counter cycles in a jiffy */
+static unsigned long cycles_per_jiffy;
+
+/* Cycle counter value at the previous timer interrupt.. */
+static unsigned int timerhi, timerlo;
+
+/* expirelo is the count value for next CPU timer interrupt */
+static unsigned int expirelo;
+
+
+/*
+ * Null timer ack for systems not needing one (e.g. i8254).
+ */
+static void null_timer_ack(void) { /* nothing */ }
+
+/*
+ * Null high precision timer functions for systems lacking one.
+ */
+static unsigned int null_hpt_read(void)
+{
+	return 0;
+}
+
+static void null_hpt_init(unsigned int count) { /* nothing */ }
+
+
+/*
+ * Timer ack for a R4k-compatible timer of a known frequency.
+ */
+static void c0_fixed_timer_ack(void)
+{
+	unsigned int count;
+
+	/* Ack this timer interrupt and set the next one.  */
+	expirelo += cycles_per_jiffy;
+	write_c0_compare(expirelo);
+
+	/* Check to see if we have missed any timer interrupts.  */
+	count = read_c0_count();
+	if ((count - expirelo) < 0x7fffffff) {
+		/* missed_timer_count++; */
+		expirelo = count + cycles_per_jiffy;
+		write_c0_compare(expirelo);
+	}
+}
+
+/*
+ * High precision timer functions for a R4k-compatible timer.
+ */
+static unsigned int c0_hpt_read(void)
+{
+	return read_c0_count();
+}
+
+/* For unknown frequency.  */
+static void c0_hpt_init(unsigned int count)
+{
+	write_c0_count(read_c0_count() - count);
+}
+
+/* For a known frequency.  Used as an interrupt source.  */
+static void c0_fixed_hpt_init(unsigned int count)
+{
+	expirelo = cycles_per_jiffy;
+	count = read_c0_count() - count;
+	write_c0_count(0);
+	write_c0_compare(cycles_per_jiffy);
+	write_c0_count(count);
+}
+
+void (*mips_timer_ack)(void);
+unsigned int (*mips_hpt_read)(void);
+void (*mips_hpt_init)(unsigned int);
+
+
 /*
  * timeofday services, for syscalls.
  */
@@ -128,42 +212,28 @@ void do_settimeofday(struct timeval *tv)
  * If the exact CPU counter frequency is known, use fixed_rate_gettimeoffset.
  * Otherwise use calibrate_gettimeoffset()
  *
- * If the CPU does not have counter register all, you can either supply
- * your own gettimeoffset() routine, or use null_gettimeoffset() routines,
- * which gives the same resolution as HZ.
+ * If the CPU does not have the counter register, you can either supply
+ * your own gettimeoffset() routine, or use null_gettimeoffset(), which
+ * gives the same resolution as HZ.
  */
 
-
-/* usecs per counter cycle, shifted to left by 32 bits */
-static unsigned int sll32_usecs_per_cycle;
-
-/* how many counter cycles in a jiffy */
-static unsigned long cycles_per_jiffy;
-
-/* Cycle counter value at the previous timer interrupt.. */
-static unsigned int timerhi, timerlo;
-
-/* expirelo is the count value for next CPU timer interrupt */
-static unsigned int expirelo;
-
-/* last time when xtime and rtc are sync'ed up */
-static long last_rtc_update;
-
-/* the function pointer to one of the gettimeoffset funcs*/
-unsigned long (*do_gettimeoffset)(void) = null_gettimeoffset;
-
 unsigned long null_gettimeoffset(void)
 {
 	return 0;
 }
 
-unsigned long fixed_rate_gettimeoffset(void)
+
+/* The function pointer to one of the gettimeoffset funcs.  */
+unsigned long (*do_gettimeoffset)(void) = null_gettimeoffset;
+
+
+static unsigned long fixed_rate_gettimeoffset(void)
 {
 	u32 count;
 	unsigned long res;
 
 	/* Get last timer tick in absolute kernel time */
-	count = read_c0_count();
+	count = mips_hpt_read();
 
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
@@ -183,6 +253,7 @@ unsigned long fixed_rate_gettimeoffset(v
 	return res;
 }
 
+
 /*
  * Cached "1/(clocks per usec) * 2^32" value.
  * It has to be recalculated once each jiffy.
@@ -192,11 +263,10 @@ static unsigned long cached_quotient;
 /* Last jiffy when calibrate_divXX_gettimeoffset() was called. */
 static unsigned long last_jiffies;
 
-
 /*
- * This is copied from dec/time.c:do_ioasic_gettimeoffset() by Maciej.
+ * This is moved from dec/time.c:do_ioasic_gettimeoffset() by Maciej.
  */
-unsigned long calibrate_div32_gettimeoffset(void)
+static unsigned long calibrate_div32_gettimeoffset(void)
 {
 	u32 count;
 	unsigned long res, tmp;
@@ -218,7 +288,7 @@ unsigned long calibrate_div32_gettimeoff
 	}
 
 	/* Get last timer tick in absolute kernel time */
-	count = read_c0_count();
+	count = mips_hpt_read();
 
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
@@ -238,7 +308,7 @@ unsigned long calibrate_div32_gettimeoff
 	return res;
 }
 
-unsigned long calibrate_div64_gettimeoffset(void)
+static unsigned long calibrate_div64_gettimeoffset(void)
 {
 	u32 count;
 	unsigned long res, tmp;
@@ -248,30 +318,33 @@ unsigned long calibrate_div64_gettimeoff
 
 	quotient = cached_quotient;
 
-	if (tmp && last_jiffies != tmp) {
+	if (last_jiffies != tmp) {
 		last_jiffies = tmp;
-		__asm__(".set	push\n\t"
-			".set	noreorder\n\t"
-			".set	noat\n\t"
-			".set	mips3\n\t"
-			"lwu	%0,%2\n\t"
-			"dsll32	$1,%1,0\n\t"
-			"or	$1,$1,%0\n\t"
-			"ddivu	$0,$1,%3\n\t"
-			"mflo	$1\n\t"
-			"dsll32	%0,%4,0\n\t"
-			"nop\n\t"
-			"ddivu	$0,%0,$1\n\t"
-			"mflo	%0\n\t"
-			".set	pop"
-			: "=&r" (quotient)
-			: "r" (timerhi), "m" (timerlo),
-			  "r" (tmp), "r" (USECS_PER_JIFFY));
-		cached_quotient = quotient;
+		if (last_jiffies) {
+			unsigned long r0;
+			__asm__(".set	push\n\t"
+				".set	mips3\n\t"
+				"lwu	%0,%3\n\t"
+				"dsll32	%1,%2,0\n\t"
+				"or	%1,%1,%0\n\t"
+				"ddivu	$0,%1,%4\n\t"
+				"mflo	%1\n\t"
+				"dsll32	%0,%5,0\n\t"
+				"or	%0,%0,%6\n\t"
+				"ddivu	$0,%0,%1\n\t"
+				"mflo	%0\n\t"
+				".set	pop"
+				: "=&r" (quotient), "=&r" (r0)
+				: "r" (timerhi), "m" (timerlo),
+				  "r" (tmp), "r" (USECS_PER_JIFFY),
+				  "r" (USECS_PER_JIFFY_FRAC)
+				: "hi", "lo", "accum");
+			cached_quotient = quotient;
+		}
 	}
 
 	/* Get last timer tick in absolute kernel time */
-	count = read_c0_count();
+	count = mips_hpt_read();
 
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
@@ -292,6 +365,9 @@ unsigned long calibrate_div64_gettimeoff
 }
 
 
+/* last time when xtime and rtc are sync'ed up */
+static long last_rtc_update;
+
 /*
  * local_timer_interrupt() does profiling and process accounting
  * on a per-CPU basis.
@@ -329,30 +405,19 @@ void local_timer_interrupt(int irq, void
 }
 
 /*
- * high-level timer interrupt service routines.  This function
+ * High-level timer interrupt service routines.  This function
  * is set as irqaction->handler and is invoked through do_IRQ.
  */
 void timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
-	if (cpu_has_counter) {
-		unsigned int count;
+	unsigned int count;
 
-		/* ack timer interrupt, and try to set next interrupt */
-		expirelo += cycles_per_jiffy;
-		write_c0_compare(expirelo);
-		count = read_c0_count();
+	count = mips_hpt_read();
+	mips_timer_ack();
 
-		/* check to see if we have missed any timer interrupts */
-		if ((count - expirelo) < 0x7fffffff) {
-			/* missed_timer_count++; */
-			expirelo = count + cycles_per_jiffy;
-			write_c0_compare(expirelo);
-		}
-
-		/* Update timerhi/timerlo for intra-jiffy calibration. */
-		timerhi += count < timerlo;	/* Wrap around */
-		timerlo = count;
-	}
+	/* Update timerhi/timerlo for intra-jiffy calibration. */
+	timerhi += count < timerlo;			/* Wrap around */
+	timerlo = count;
 
 	/*
 	 * call the generic timer interrupt handling
@@ -379,12 +444,13 @@ void timer_interrupt(int irq, void *dev_
 	read_unlock(&xtime_lock);
 
 	/*
-	 * If jiffies has overflowed in this timer_interrupt we must
+	 * If jiffies has overflown in this timer_interrupt, we must
 	 * update the timer[hi]/[lo] to make fast gettimeoffset funcs
 	 * quotient calc still valid. -arca
 	 */
 	if (!jiffies) {
 		timerhi = timerlo = 0;
+		mips_hpt_init(count);
 	}
 
 #if !defined(CONFIG_SMP)
@@ -484,50 +550,70 @@ void __init time_init(void)
 	xtime.tv_sec = rtc_get_time();
 	xtime.tv_usec = 0;
 
-	/* choose appropriate gettimeoffset routine */
-	if (!cpu_has_counter) {
-		/* no cpu counter - sorry */
-		do_gettimeoffset = null_gettimeoffset;
-	} else if (mips_counter_frequency != 0) {
-		/* we have cpu counter and know counter frequency! */
-		do_gettimeoffset = fixed_rate_gettimeoffset;
-	} else if ((current_cpu_data.isa_level == MIPS_CPU_ISA_M32) ||
-		   (current_cpu_data.isa_level == MIPS_CPU_ISA_I) ||
-		   (current_cpu_data.isa_level == MIPS_CPU_ISA_II) ) {
-		/* we need to calibrate the counter but we don't have
-		 * 64-bit division. */
-		do_gettimeoffset = calibrate_div32_gettimeoffset;
+	/* Choose appropriate high precision timer routines.  */
+	if (!cpu_has_counter && !mips_hpt_read) {
+		/* No high precision timer -- sorry.  */
+		mips_hpt_read = null_hpt_read;
+		mips_hpt_init = null_hpt_init;
+	} else if (!mips_counter_frequency) {
+		/* A high precision timer of unknown frequency.  */
+		if (!mips_hpt_read) {
+			/* No external high precision timer -- use R4k.  */
+			mips_hpt_read = c0_hpt_read;
+			mips_hpt_init = c0_hpt_init;
+		}
+
+		if ((current_cpu_data.isa_level == MIPS_CPU_ISA_M32) ||
+			 (current_cpu_data.isa_level == MIPS_CPU_ISA_I) ||
+			 (current_cpu_data.isa_level == MIPS_CPU_ISA_II))
+			/*
+			 * We need to calibrate the counter but we don't have
+			 * 64-bit division.
+			 */
+			do_gettimeoffset = calibrate_div32_gettimeoffset;
+		else
+			/*
+			 * We need to calibrate the counter but we *do* have
+			 * 64-bit division.
+			 */
+			do_gettimeoffset = calibrate_div64_gettimeoffset;
 	} else {
-		/* we need to calibrate the counter but we *do* have
-		 * 64-bit division. */
-		do_gettimeoffset = calibrate_div64_gettimeoffset;
-	}
+		/* We know counter frequency! */
+		if (!mips_hpt_read) {
+			/* No external high precision timer -- use R4k.  */
+			mips_hpt_read = c0_hpt_read;
+			mips_hpt_init = c0_fixed_hpt_init;
+
+			if (!mips_timer_ack)
+				/* R4k timer interrupt ack.  */
+				mips_timer_ack = c0_fixed_timer_ack;
+		}
 
-	/* caclulate cache parameters */
-	if (mips_counter_frequency) {
+		do_gettimeoffset = fixed_rate_gettimeoffset;
+
+		/* Calculate cache parameters.  */
 		cycles_per_jiffy = mips_counter_frequency / HZ;
 
-		/* sll32_usecs_per_cycle = 10^6 * 2^32 / mips_counter_freq */
-		/* any better way to do this? */
+		/* sll32_usecs_per_cycle = 10^6 * 2^32 / mips_counter_freq  */
+		/* Any better way to do this?  */
 		sll32_usecs_per_cycle = mips_counter_frequency / 100000;
 		sll32_usecs_per_cycle = 0xffffffff / sll32_usecs_per_cycle;
 		sll32_usecs_per_cycle *= 10;
-
-		/*
-		 * For those using cpu counter as timer,  this sets up the
-		 * first interrupt
-		 */
-		write_c0_compare(cycles_per_jiffy);
-		write_c0_count(0);
-		expirelo = cycles_per_jiffy;
 	}
 
+	if (!mips_timer_ack)
+		/* No timer interrupt ack (e.g. i8254).  */
+		mips_timer_ack = null_timer_ack;
+
+	/* This sets up the high precision timer for the first interrupt.  */
+	mips_hpt_init(mips_hpt_read());
+
 	/*
 	 * Call board specific timer interrupt setup.
 	 *
 	 * this pointer must be setup in machine setup routine.
 	 *
-	 * Even if the machine choose to use low-level timer interrupt,
+	 * Even if a machine chooses to use a low-level timer interrupt,
 	 * it still needs to setup the timer_irqaction.
 	 * In that case, it might be better to set timer_irqaction.handler
 	 * to be NULL function so that we are sure the high-level code
diff -up --recursive --new-file linux-mips-2.4.21-20030725.macro/arch/mips64/kernel/time.c linux-mips-2.4.21-20030725/arch/mips64/kernel/time.c
--- linux-mips-2.4.21-20030725.macro/arch/mips64/kernel/time.c	2003-07-31 21:27:18.000000000 +0000
+++ linux-mips-2.4.21-20030725/arch/mips64/kernel/time.c	2003-08-03 17:43:49.000000000 +0000
@@ -31,9 +31,14 @@
 #include <asm/hardirq.h>
 #include <asm/div64.h>
 
-/* This is for machines which generate the exact clock. */
-#define USECS_PER_JIFFY (1000000/HZ)
-#define USECS_PER_JIFFY_FRAC ((u32)((1000000ULL << 32) / HZ))
+/*
+ * The integer part of the number of usecs per jiffy is taken from tick,
+ * but the fractional part is not recorded, so we calculate it using the
+ * initial value of HZ.  This aids systems where tick isn't really an
+ * integer (e.g. for HZ = 128).
+ */
+#define USECS_PER_JIFFY		tick
+#define USECS_PER_JIFFY_FRAC	((unsigned long)(u32)((1000000ULL << 32) / HZ))
 
 /*
  * forward reference
@@ -48,6 +53,7 @@ spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED
  */
 int emulate_local_timer_interrupt;
 
+
 /*
  * By default we provide the null RTC ops
  */
@@ -66,6 +72,84 @@ int (*rtc_set_time)(unsigned long) = nul
 int (*rtc_set_mmss)(unsigned long);
 
 
+/* usecs per counter cycle, shifted to left by 32 bits */
+static unsigned int sll32_usecs_per_cycle;
+
+/* how many counter cycles in a jiffy */
+static unsigned long cycles_per_jiffy;
+
+/* Cycle counter value at the previous timer interrupt.. */
+static unsigned int timerhi, timerlo;
+
+/* expirelo is the count value for next CPU timer interrupt */
+static unsigned int expirelo;
+
+
+/*
+ * Null timer ack for systems not needing one (e.g. i8254).
+ */
+static void null_timer_ack(void) { /* nothing */ }
+
+/*
+ * Null high precision timer functions for systems lacking one.
+ */
+static unsigned int null_hpt_read(void)
+{
+	return 0;
+}
+
+static void null_hpt_init(unsigned int count) { /* nothing */ }
+
+
+/*
+ * Timer ack for a R4k-compatible timer of a known frequency.
+ */
+static void c0_fixed_timer_ack(void)
+{
+	unsigned int count;
+
+	/* Ack this timer interrupt and set the next one.  */
+	expirelo += cycles_per_jiffy;
+	write_c0_compare(expirelo);
+
+	/* Check to see if we have missed any timer interrupts.  */
+	count = read_c0_count();
+	if ((count - expirelo) < 0x7fffffff) {
+		/* missed_timer_count++; */
+		expirelo = count + cycles_per_jiffy;
+		write_c0_compare(expirelo);
+	}
+}
+
+/*
+ * High precision timer functions for a R4k-compatible timer.
+ */
+static unsigned int c0_hpt_read(void)
+{
+	return read_c0_count();
+}
+
+/* For unknown frequency.  */
+static void c0_hpt_init(unsigned int count)
+{
+	write_c0_count(read_c0_count() - count);
+}
+
+/* For a known frequency.  Used as an interrupt source.  */
+static void c0_fixed_hpt_init(unsigned int count)
+{
+	expirelo = cycles_per_jiffy;
+	count = read_c0_count() - count;
+	write_c0_count(0);
+	write_c0_compare(cycles_per_jiffy);
+	write_c0_count(count);
+}
+
+void (*mips_timer_ack)(void);
+unsigned int (*mips_hpt_read)(void);
+void (*mips_hpt_init)(unsigned int);
+
+
 /*
  * timeofday services, for syscalls.
  */
@@ -128,42 +212,28 @@ void do_settimeofday(struct timeval *tv)
  * If the exact CPU counter frequency is known, use fixed_rate_gettimeoffset.
  * Otherwise use calibrate_gettimeoffset()
  *
- * If the CPU does not have counter register all, you can either supply
- * your own gettimeoffset() routine, or use null_gettimeoffset() routines,
- * which gives the same resolution as HZ.
+ * If the CPU does not have the counter register, you can either supply
+ * your own gettimeoffset() routine, or use null_gettimeoffset(), which
+ * gives the same resolution as HZ.
  */
 
-
-/* usecs per counter cycle, shifted to left by 32 bits */
-static unsigned int sll32_usecs_per_cycle;
-
-/* how many counter cycles in a jiffy */
-static unsigned long cycles_per_jiffy;
-
-/* Cycle counter value at the previous timer interrupt.. */
-static unsigned int timerhi, timerlo;
-
-/* expirelo is the count value for next CPU timer interrupt */
-static unsigned int expirelo;
-
-/* last time when xtime and rtc are sync'ed up */
-static long last_rtc_update;
-
-/* the function pointer to one of the gettimeoffset funcs*/
-unsigned long (*do_gettimeoffset)(void) = null_gettimeoffset;
-
 unsigned long null_gettimeoffset(void)
 {
 	return 0;
 }
 
-unsigned long fixed_rate_gettimeoffset(void)
+
+/* The function pointer to one of the gettimeoffset funcs.  */
+unsigned long (*do_gettimeoffset)(void) = null_gettimeoffset;
+
+
+static unsigned long fixed_rate_gettimeoffset(void)
 {
 	u32 count;
 	unsigned long res;
 
 	/* Get last timer tick in absolute kernel time */
-	count = read_c0_count();
+	count = mips_hpt_read();
 
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
@@ -183,6 +253,7 @@ unsigned long fixed_rate_gettimeoffset(v
 	return res;
 }
 
+
 /*
  * Cached "1/(clocks per usec) * 2^32" value.
  * It has to be recalculated once each jiffy.
@@ -192,11 +263,10 @@ static unsigned long cached_quotient;
 /* Last jiffy when calibrate_divXX_gettimeoffset() was called. */
 static unsigned long last_jiffies;
 
-
 /*
- * This is copied from dec/time.c:do_ioasic_gettimeoffset() by Maciej.
+ * This is moved from dec/time.c:do_ioasic_gettimeoffset() by Maciej.
  */
-unsigned long calibrate_div32_gettimeoffset(void)
+static unsigned long calibrate_div32_gettimeoffset(void)
 {
 	u32 count;
 	unsigned long res, tmp;
@@ -218,7 +288,7 @@ unsigned long calibrate_div32_gettimeoff
 	}
 
 	/* Get last timer tick in absolute kernel time */
-	count = read_c0_count();
+	count = mips_hpt_read();
 
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
@@ -238,7 +308,7 @@ unsigned long calibrate_div32_gettimeoff
 	return res;
 }
 
-unsigned long calibrate_div64_gettimeoffset(void)
+static unsigned long calibrate_div64_gettimeoffset(void)
 {
 	u32 count;
 	unsigned long res, tmp;
@@ -248,30 +318,33 @@ unsigned long calibrate_div64_gettimeoff
 
 	quotient = cached_quotient;
 
-	if (tmp && last_jiffies != tmp) {
+	if (last_jiffies != tmp) {
 		last_jiffies = tmp;
-		__asm__(".set	push\n\t"
-			".set	noreorder\n\t"
-			".set	noat\n\t"
-			".set	mips3\n\t"
-			"lwu	%0,%2\n\t"
-			"dsll32	$1,%1,0\n\t"
-			"or	$1,$1,%0\n\t"
-			"ddivu	$0,$1,%3\n\t"
-			"mflo	$1\n\t"
-			"dsll32	%0,%4,0\n\t"
-			"nop\n\t"
-			"ddivu	$0,%0,$1\n\t"
-			"mflo	%0\n\t"
-			".set	pop"
-			: "=&r" (quotient)
-			: "r" (timerhi), "m" (timerlo),
-			  "r" (tmp), "r" (USECS_PER_JIFFY));
-		cached_quotient = quotient;
+		if (last_jiffies) {
+			unsigned long r0;
+			__asm__(".set	push\n\t"
+				".set	mips3\n\t"
+				"lwu	%0,%3\n\t"
+				"dsll32	%1,%2,0\n\t"
+				"or	%1,%1,%0\n\t"
+				"ddivu	$0,%1,%4\n\t"
+				"mflo	%1\n\t"
+				"dsll32	%0,%5,0\n\t"
+				"or	%0,%0,%6\n\t"
+				"ddivu	$0,%0,%1\n\t"
+				"mflo	%0\n\t"
+				".set	pop"
+				: "=&r" (quotient), "=&r" (r0)
+				: "r" (timerhi), "m" (timerlo),
+				  "r" (tmp), "r" (USECS_PER_JIFFY),
+				  "r" (USECS_PER_JIFFY_FRAC)
+				: "hi", "lo", "accum");
+			cached_quotient = quotient;
+		}
 	}
 
 	/* Get last timer tick in absolute kernel time */
-	count = read_c0_count();
+	count = mips_hpt_read();
 
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
@@ -292,6 +365,9 @@ unsigned long calibrate_div64_gettimeoff
 }
 
 
+/* last time when xtime and rtc are sync'ed up */
+static long last_rtc_update;
+
 /*
  * local_timer_interrupt() does profiling and process accounting
  * on a per-CPU basis.
@@ -329,30 +405,19 @@ void local_timer_interrupt(int irq, void
 }
 
 /*
- * high-level timer interrupt service routines.  This function
+ * High-level timer interrupt service routines.  This function
  * is set as irqaction->handler and is invoked through do_IRQ.
  */
 void timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
-	if (cpu_has_counter) {
-		unsigned int count;
+	unsigned int count;
 
-		/* ack timer interrupt, and try to set next interrupt */
-		expirelo += cycles_per_jiffy;
-		write_c0_compare(expirelo);
-		count = read_c0_count();
+	count = mips_hpt_read();
+	mips_timer_ack();
 
-		/* check to see if we have missed any timer interrupts */
-		if ((count - expirelo) < 0x7fffffff) {
-			/* missed_timer_count++; */
-			expirelo = count + cycles_per_jiffy;
-			write_c0_compare(expirelo);
-		}
-
-		/* Update timerhi/timerlo for intra-jiffy calibration. */
-		timerhi += count < timerlo;	/* Wrap around */
-		timerlo = count;
-	}
+	/* Update timerhi/timerlo for intra-jiffy calibration. */
+	timerhi += count < timerlo;			/* Wrap around */
+	timerlo = count;
 
 	/*
 	 * call the generic timer interrupt handling
@@ -379,12 +444,13 @@ void timer_interrupt(int irq, void *dev_
 	read_unlock(&xtime_lock);
 
 	/*
-	 * If jiffies has overflowed in this timer_interrupt we must
+	 * If jiffies has overflown in this timer_interrupt, we must
 	 * update the timer[hi]/[lo] to make fast gettimeoffset funcs
 	 * quotient calc still valid. -arca
 	 */
 	if (!jiffies) {
 		timerhi = timerlo = 0;
+		mips_hpt_init(count);
 	}
 
 #if !defined(CONFIG_SMP)
@@ -484,50 +550,70 @@ void __init time_init(void)
 	xtime.tv_sec = rtc_get_time();
 	xtime.tv_usec = 0;
 
-	/* choose appropriate gettimeoffset routine */
-	if (!cpu_has_counter) {
-		/* no cpu counter - sorry */
-		do_gettimeoffset = null_gettimeoffset;
-	} else if (mips_counter_frequency != 0) {
-		/* we have cpu counter and know counter frequency! */
-		do_gettimeoffset = fixed_rate_gettimeoffset;
-	} else if ((current_cpu_data.isa_level == MIPS_CPU_ISA_M32) ||
-		   (current_cpu_data.isa_level == MIPS_CPU_ISA_I) ||
-		   (current_cpu_data.isa_level == MIPS_CPU_ISA_II) ) {
-		/* we need to calibrate the counter but we don't have
-		 * 64-bit division. */
-		do_gettimeoffset = calibrate_div32_gettimeoffset;
+	/* Choose appropriate high precision timer routines.  */
+	if (!cpu_has_counter && !mips_hpt_read) {
+		/* No high precision timer -- sorry.  */
+		mips_hpt_read = null_hpt_read;
+		mips_hpt_init = null_hpt_init;
+	} else if (!mips_counter_frequency) {
+		/* A high precision timer of unknown frequency.  */
+		if (!mips_hpt_read) {
+			/* No external high precision timer -- use R4k.  */
+			mips_hpt_read = c0_hpt_read;
+			mips_hpt_init = c0_hpt_init;
+		}
+
+		if ((current_cpu_data.isa_level == MIPS_CPU_ISA_M32) ||
+			 (current_cpu_data.isa_level == MIPS_CPU_ISA_I) ||
+			 (current_cpu_data.isa_level == MIPS_CPU_ISA_II))
+			/*
+			 * We need to calibrate the counter but we don't have
+			 * 64-bit division.
+			 */
+			do_gettimeoffset = calibrate_div32_gettimeoffset;
+		else
+			/*
+			 * We need to calibrate the counter but we *do* have
+			 * 64-bit division.
+			 */
+			do_gettimeoffset = calibrate_div64_gettimeoffset;
 	} else {
-		/* we need to calibrate the counter but we *do* have
-		 * 64-bit division. */
-		do_gettimeoffset = calibrate_div64_gettimeoffset;
-	}
+		/* We know counter frequency! */
+		if (!mips_hpt_read) {
+			/* No external high precision timer -- use R4k.  */
+			mips_hpt_read = c0_hpt_read;
+			mips_hpt_init = c0_fixed_hpt_init;
+
+			if (!mips_timer_ack)
+				/* R4k timer interrupt ack.  */
+				mips_timer_ack = c0_fixed_timer_ack;
+		}
 
-	/* caclulate cache parameters */
-	if (mips_counter_frequency) {
+		do_gettimeoffset = fixed_rate_gettimeoffset;
+
+		/* Calculate cache parameters.  */
 		cycles_per_jiffy = mips_counter_frequency / HZ;
 
-		/* sll32_usecs_per_cycle = 10^6 * 2^32 / mips_counter_freq */
-		/* any better way to do this? */
+		/* sll32_usecs_per_cycle = 10^6 * 2^32 / mips_counter_freq  */
+		/* Any better way to do this?  */
 		sll32_usecs_per_cycle = mips_counter_frequency / 100000;
 		sll32_usecs_per_cycle = 0xffffffff / sll32_usecs_per_cycle;
 		sll32_usecs_per_cycle *= 10;
-
-		/*
-		 * For those using cpu counter as timer,  this sets up the
-		 * first interrupt
-		 */
-		write_c0_compare(cycles_per_jiffy);
-		write_c0_count(0);
-		expirelo = cycles_per_jiffy;
 	}
 
+	if (!mips_timer_ack)
+		/* No timer interrupt ack (e.g. i8254).  */
+		mips_timer_ack = null_timer_ack;
+
+	/* This sets up the high precision timer for the first interrupt.  */
+	mips_hpt_init(mips_hpt_read());
+
 	/*
 	 * Call board specific timer interrupt setup.
 	 *
 	 * this pointer must be setup in machine setup routine.
 	 *
-	 * Even if the machine choose to use low-level timer interrupt,
+	 * Even if a machine chooses to use a low-level timer interrupt,
 	 * it still needs to setup the timer_irqaction.
 	 * In that case, it might be better to set timer_irqaction.handler
 	 * to be NULL function so that we are sure the high-level code
diff -up --recursive --new-file linux-mips-2.4.21-20030725.macro/include/asm-mips/time.h linux-mips-2.4.21-20030725/include/asm-mips/time.h
--- linux-mips-2.4.21-20030725.macro/include/asm-mips/time.h	2003-07-25 23:07:42.000000000 +0000
+++ linux-mips-2.4.21-20030725/include/asm-mips/time.h	2003-08-03 17:47:55.000000000 +0000
@@ -36,6 +36,19 @@ extern int (*rtc_set_time)(unsigned long
 extern int (*rtc_set_mmss)(unsigned long);
 
 /*
+ * Timer interrupt ack function.
+ * May be NULL if the interrupt is self-recoverable.
+ */
+extern void (*mips_timer_ack)(void);
+
+/*
+ * High precision timer functions.
+ * If mips_hpt_read is NULL, an R4k-compatible timer setup is attempted.
+ */
+extern unsigned int (*mips_hpt_read)(void);
+extern void (*mips_hpt_init)(unsigned int);
+
+/*
  * to_tm() converts system time back to (year, mon, day, hour, min, sec).
  * It is intended to help implement rtc_set_time() functions.
  * Copied from PPC implementation.
@@ -49,11 +62,6 @@ extern void to_tm(unsigned long tim, str
  */
 extern unsigned long (*do_gettimeoffset)(void);
 
-extern unsigned long null_gettimeoffset(void);
-extern unsigned long fixed_rate_gettimeoffset(void);
-extern unsigned long calibrate_div32_gettimeoffset(void);
-extern unsigned long calibrate_div64_gettimeoffset(void);
-
 /*
  * high-level timer interrupt routines.
  */
diff -up --recursive --new-file linux-mips-2.4.21-20030725.macro/include/asm-mips64/time.h linux-mips-2.4.21-20030725/include/asm-mips64/time.h
--- linux-mips-2.4.21-20030725.macro/include/asm-mips64/time.h	2003-07-25 02:57:09.000000000 +0000
+++ linux-mips-2.4.21-20030725/include/asm-mips64/time.h	2003-08-03 17:47:55.000000000 +0000
@@ -36,6 +36,19 @@ extern int (*rtc_set_time)(unsigned long
 extern int (*rtc_set_mmss)(unsigned long);
 
 /*
+ * Timer interrupt ack function.
+ * May be NULL if the interrupt is self-recoverable.
+ */
+extern void (*mips_timer_ack)(void);
+
+/*
+ * High precision timer functions.
+ * If mips_hpt_read is NULL, an R4k-compatible timer setup is attempted.
+ */
+extern unsigned int (*mips_hpt_read)(void);
+extern void (*mips_hpt_init)(unsigned int);
+
+/*
  * to_tm() converts system time back to (year, mon, day, hour, min, sec).
  * It is intended to help implement rtc_set_time() functions.
  * Copied from PPC implementation.
@@ -49,11 +62,6 @@ extern void to_tm(unsigned long tim, str
  */
 extern unsigned long (*do_gettimeoffset)(void);
 
-extern unsigned long null_gettimeoffset(void);
-extern unsigned long fixed_rate_gettimeoffset(void);
-extern unsigned long calibrate_div32_gettimeoffset(void);
-extern unsigned long calibrate_div64_gettimeoffset(void);
-
 /*
  * high-level timer interrupt routines.
  */


From ppopov@mvista.com Mon Aug  4 18:28:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 18:28:51 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:65274 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224772AbTHDR2r>;
	Mon, 4 Aug 2003 18:28:47 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA01341;
	Mon, 4 Aug 2003 10:28:44 -0700
Subject: Re: udelay
From: Pete Popov <ppopov@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030804014132.GA4419@linux-mips.org>
References: <1059788948.9224.62.camel@zeus.mvista.com>
	 <20030804014132.GA4419@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1060018159.9217.93.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 04 Aug 2003 10:29:20 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2981
X-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 Sun, 2003-08-03 at 18:41, Ralf Baechle wrote:
> On Fri, Aug 01, 2003 at 06:49:08PM -0700, Pete Popov wrote:
> 
> > Looks like the latest udelay in 2.4 is borked. Anyway else notice that
> > problem?  I did a 10 sec test: mdelay works, udelay is broken, at least
> > for the CPU and toolchain I'm using.
> 
> That just doesn't make sense.  Mdelay is based on udelay so if udelay
> is broken mdelay should be broken, too.

I think the problem may be occurring when udelay is used with very large
values, like 10000. I've told the developer that that's not recommended
and to use mdelays in that case.

Pete


From ralf@linux-mips.org Mon Aug  4 22:38:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 22:38:19 +0100 (BST)
Received: from p508B61A2.dip.t-dialin.net ([IPv6:::ffff:80.139.97.162]:26518
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224772AbTHDViR>; Mon, 4 Aug 2003 22:38:17 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h74LcDpR028775;
	Mon, 4 Aug 2003 23:38:13 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h74LcC3B028774;
	Mon, 4 Aug 2003 23:38:12 +0200
Date: Mon, 4 Aug 2003 23:38:12 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: udelay
Message-ID: <20030804213812.GA21327@linux-mips.org>
References: <1059788948.9224.62.camel@zeus.mvista.com> <20030804014132.GA4419@linux-mips.org> <1060018159.9217.93.camel@zeus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1060018159.9217.93.camel@zeus.mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2982
X-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, Aug 04, 2003 at 10:29:20AM -0700, Pete Popov wrote:

> > > Looks like the latest udelay in 2.4 is borked. Anyway else notice that
> > > problem?  I did a 10 sec test: mdelay works, udelay is broken, at least
> > > for the CPU and toolchain I'm using.
> > 
> > That just doesn't make sense.  Mdelay is based on udelay so if udelay
> > is broken mdelay should be broken, too.
> 
> I think the problem may be occurring when udelay is used with very large
> values, like 10000. I've told the developer that that's not recommended
> and to use mdelays in that case.

Any bug report for udelay arguments larger than 1000 will probably be
ignored ...

  Ralf

From hamilton@redhat.com Mon Aug  4 22:58:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 22:58:24 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:1288 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224772AbTHDV6W>;
	Mon, 4 Aug 2003 22:58:22 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h74LwJZ12453;
	Mon, 4 Aug 2003 17:58:19 -0400
Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h74LwII14800;
	Mon, 4 Aug 2003 17:58:18 -0400
Received: from redhat.com (slurm.hsv.redhat.com [172.16.16.102])
	by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id h74LwGm32029;
	Mon, 4 Aug 2003 16:58:16 -0500
Message-ID: <3F2ED77A.2020803@redhat.com>
Date: Mon, 04 Aug 2003 17:00:26 -0500
From: Louis Hamilton <hamilton@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226
X-Accept-Language: en-us
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Subject: [patch] Mips64 RM{7,9}000 support
Content-Type: multipart/mixed;
 boundary="------------010102060601040501030303"
Return-Path: <hamilton@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2983
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hamilton@redhat.com
Precedence: bulk
X-list: linux-mips

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

Ralf,

Here is an updated patchfile with 64-bit support for the RM7000-based 
Ocelot-C and RM9000-based
Jaguar ATX platforms.

Both boards come up fine on NFS-mounted root filesystems and should 
apply cleanly to the current
2.4 tree.  This Jaguar support does not require himem since the hw can 
also boot fine with dmalow disabled.
Getting dmalow enabled w/ himem support for Jaguar will have to go in later.

If it looks ok, please check it into the tree.

Louis

Louis Hamilton    hamilton@redhat.com
Red Hat, Inc.


--------------010102060601040501030303
Content-Type: text/plain;
 name="patch-list-oce64_jag64"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch-list-oce64_jag64"

 Patch Summary:

 arch/mips/config-shared.in
 arch/mips/momentum/jaguar_atx/dbg_io.c
 arch/mips/momentum/jaguar_atx/int-handler.S
 arch/mips/momentum/jaguar_atx/irq.c
 arch/mips/momentum/jaguar_atx/jaguar_atx_fpga.h
 arch/mips/momentum/jaguar_atx/Makefile
 arch/mips/momentum/jaguar_atx/mv-irq.c
 arch/mips/momentum/jaguar_atx/pci.c
 arch/mips/momentum/jaguar_atx/pci-irq.c
 arch/mips/momentum/jaguar_atx/prom.c
 arch/mips/momentum/jaguar_atx/reset.c
 arch/mips/momentum/jaguar_atx/setup.c
 arch/mips/momentum/ocelot_c/ocelot_c_fpga.h
 arch/mips/momentum/ocelot_c/prom.c
 arch/mips/momentum/ocelot_c/reset.c
 arch/mips/momentum/ocelot_c/setup.c
 arch/mips64/defconfig-jaguar
 arch/mips64/defconfig-ocelotc
 arch/mips64/kernel/cpu-probe.c
 arch/mips64/kernel/proc.c
 arch/mips64/kernel/setup.c
 arch/mips64/kernel/traps.c
 arch/mips64/Makefile
 arch/mips64/mm/c-r4k.c
 arch/mips64/mm/loadmmu.c
 arch/mips64/mm/Makefile
 arch/mips64/mm/sc-rm7k.c
 arch/mips64/mm/tlbex-r4k.S
 arch/mips64/mm/tlb-r4k.c
 drivers/char/serial.c
 drivers/net/Config.in
 drivers/net/Makefile
 drivers/net/mv64340_eth.c
 drivers/net/mv64340_eth.h
 include/asm-mips64/addrspace.h
 include/asm-mips64/bootinfo.h
 include/asm-mips64/cpu.h
 include/asm-mips64/io.h
 include/asm-mips64/mipsregs.h
 include/asm-mips64/page.h
 include/asm-mips64/serial.h

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

H4sICIvALj8AA29jZTY0X2phZzY0X3BhdGNoAOxc63fayJL/jP+Kvk5uAuFhXsaveE5kELbm
AmIk4SQ7maMrhADFIDF6+JGZ2b99q7ol9EAYnJO7H3aHkxi5u+rXVdXd1VXdLU/M6ZSUfWdA
xpprHGmOPj9amiv3SLetqTkru3PNMSYV0yIr2/GeqT8ol8u7MHL1arVRrp6UGzVSa57Xq+eN
k0o1/JBy9bhaPSgWi7vaCnBOy9UmqTXOm43z4+MNnA8fSPmkVmqRIvw8JR8+HJCxbS/IW9lf
IT6Z2g7p20vD8vwlEXVjYXtAoTmTt6QtDrrCtdoX+/ygLapim++Jyh785etnEdTrfTDaRLMm
pNyWGZa7Dax9UHwG7Gdt5mtOmVM+bYP5mbsecZIKFAfFAzIxVuom3IBvk07nitw6evm4etIk
ef7TkJcEQFC4XmGNCTS0+nXwe5wqS+cEbvOklQCC3/fgOUnxnNAeh+9SrUqKzZOzUr1Oex0+
E2NqWgbTL2ASex1VAQnVNnk6IFPzgJhT8is5fL3F2Ifkkhw+HZLfLog3N6yDYjbslchJHVVu
c+0bHoC3UEn9Exioans4iki3yDlsC9sr5Y/cUBVEVR5y7WcwBiJocsNL0B1A/Qwd/zGyyVYF
wRp8r9uoIw3YrZhtt2h0/cctt4WUWW5LZdpyW8g2LLeN7qWWyxhxwRxKm2tLX91wt7wqKx1Q
U5VhrnE9dShKCkDjNGidHKPna52elU7oJMgR6RQMlwu40X60gHyhdbVqupKWBLXU5olaWgK1
Raw926g9W/PKV7V4Ffx6SKTmI/hnktZf7g/VNjfkrnp82gZUpbMmdebVs9IZVSnJHYm1pwGR
4YaT1aHEd3mlfRN0SjEL9iwDdksvZ8DiLNnQdm2NTWGZ6yNk5Bqk0+eIZxN9YWgOrIOrJ7LS
ZkbkzGXh6rPCq0CmDrlrXhzKwcJ3Ro3VOAn6P0Or5idUKmi/bGN/0U+S6ri6D1XC8JSqmEV1
lqbKwqIjbxcVNR3ZJVdfGMqNegJrsi3gWQYr59FXunKqmvd4NBnPVNOu6OmA5DnarEDoOfpc
7ax1Vq7VaVB0el6twr9EMNPKDoqexYwHWhBltdKYYYBULcFaWSvV6i0cJcVXpqUv/IlB3i9M
y38MAq/K/CeIEKByGgz4ST70xnxfxNHHX42uC4wmBNDc5ZFrOKa2AHZy9I50YQmHIU5YIdWG
LGxd80zbohEP2gx++BPy7gixgAdNyZqij6zce1oZIAfxLdecgTBEh7iQ+KblnV5k1EI5rWzU
L2Ko/KBDxO4m+CumIQk/sIYptdbxcVW94kYdtd4E88U/WLCTq3ma4sKCnVxnrRTXWWsPrtpZ
PclGC3ayNU5TmtGCnWzHJykhacFuIWvHSSlZwfMdMOQkQfmMSzIf43y2sYBF7HTiMlYfq6d7
cPG3/CDBVduHq89J/0pw1ffhYmFIjKtx+rwxOpzCqcdXghJXDDXbydTaZKrtZDrZZKrvZDrd
ZGo8r5WsiEO19kKtKFN9k6kZTfeXfyIfdHl5GboJfFyX//rV9a3fyINBfPBbzLOBv5wkHBzm
LXeTMeVKa3DFyTzJ+AQZBwvqaiqSbTL3uU90Km1hRiZaH1Mi6fIiXdLQEg/ZUbcr80mDktCe
jjEzXc9wiD2duoaXqZvYlVWpfatejbpdXor1SjapInEDWb2BnGwnqQxqpGG3kAoDRVL5AQaU
6/J87V2kX+EZPiFp2nx9Nx8d9F1R6nOR5fKN3Xw9YQCJgwitir2X8PXFDt9PMeabu/kkud6o
q+JIGY7Wgu7DR+WUFU4ZyZF+x/vKmWTMt/aVUxjExNyLT25LHETe4FujPsyfJPm29KBwK8ii
pPbkq4izukfPB3z9OF8t3SKdPUtjaTtP5aW2gjgF5pI2OXpwTM+A2USdCHUbWVMqcngSz3Xy
TwXayLt8/t5eQBC1MFgI9K6Qp46lSJ4KhQxxI5iPsPLw+acS+QZQ+V1IEEN/o1rc2+YE4sCx
PxMs08uz0IrGbSXGRyaap4XPKw2Uewp/cz17BSB/QN4IppiYrjaG1qDKcBx/5blU8VxaxNRc
LpFqgYZyiIEOyF+Rsa+BMTUwI0XABnKBZBPz3nRth3GELB2BuyJjk1k6l9lifFZCk4+nYash
RgAcQIS/XUau+Yha5WJbA7HBVlqDvYGWptPCTqY+MuWTXNVqgfz0EzmNyUnzxu/Rliqb+ytu
ZuxWXNCWmre9n2I+sMQ4/gzGADzQ7gdcCut6MNZ0Gp47MCc8oxOOKVg9zW8wOS5JlWrCxs7M
8ChFG6L9PA7CYCBBVpL/RzZCgdCBsBW+Rs0cjeWsmLiEJLnM2GazKhailrLCmphRH+Y40fL5
1LRO+dkC7doazL5LNupBGc93rLQ3SK63axsfFNG8Kz9mOWbM8ZNn/P+xX70aM2DWqI0FFSVm
m5ipa6E1XxnWxJy+bAcBrF2eQ3a7MJyKvE8Kn2DYdy8hwfQjNxSSwC/dVWjQDXhY9Q6K5B1p
26snx5zNPQI49eikom0vYYRCPClYeoVScr43t51z0tc8WBIfSAcG7pK8X07w+wOVU7crur38
CckpyxUYaUJsizzYzt05LSLJFmvQouVptxC7akS2p96D5hhRm2TdKsb1H5b3SIdtEPCvtOir
b8FXxTK8datd03G98sK4NxbRKobr2krz9DmohPF/+iSmsmZX5qZLVo49c7QlgcepY0AWEYh2
QZ5sn+iaBe4RED3HHIOVCAE3Dh1yBMBLG4biExRQMN+aQIM0hgBBli4GFPS368GIXBuW4UBS
Qob+eAFet2fqhgVpiwbtY4k7B+uNn5CeKYaSrI3UtQGcbtRcEGKYHmp2bzgu7tzUw8AlxCyh
wfKwRoD4DgWzV8haALGfCAQYETO1RCzUUVVOlvn+Ve+zqj67GZXcZoL/GaU4piFVcbMYJhMH
ukg3MuqABaTJqIDhoN9NoadSXIfRdFGnq5lWmR+yUC8aIWTHCAkP/oITv8AquVwFPO3Myh3j
84CXFb6TDxpjc1IFxBIZQq4o/Bc4TBdjq1xOxpMBrtfD53ZPoECwfuc0Dx+XU72a86ol0h5W
1TY3whw0Kq+zcuY8WRQBLVF6rx7s6RLGAOVmzqtBBVQyhq4qDKs0XHiorsdxTG2m1dgyvlHG
xUIFQtV0fn8Gr8bwavvi1Xbg1REPIKoEnMmEAi5w7G1irXTzUduB1gjQanuhjXegNQO0+j5o
u0Q7DsAa+4DtkqwVgDV3gsHo9HaAndDIdOUTz1waTgYG1NEqhoO1lr1afwWhrWU/kIVt3xFw
NcajB2sz2+xNpBIZwx1LdVpaCwZ7DbOLIPaNIvy5OfWoY1tq7h05xfjZhYmMhTZTHvIOrKcV
rDV3saBzCKFPN6cPEDgL9hv8r7XWFFlWOg1M3tpp8uV9q9loVtWJodsTY7vRqBdwDNuBhWKt
54NjWzOiLXCFxTUFlAU7ViqVoKGvOXflO6btu+rauDFwCJw2fVIhaG/tvqKZfo4VCzOnoQFo
B9n3Rk6rofeizWmL3MRWBekX1jjEYOrUsZdMq2iGx3Hq34Oznt1xpMaLkdZY4zRW87uxNsQ6
fjFULsTaEKv1nVjhvI5jnXwnVnx+x/FOvxNvcwKcR0jVOFKMOPBRG53wsvDe+X2/00FKuHc4
j8Q/NIyngC8M3+u1anb4nm8XtoTwpR0xfIlsxvDZITwEo5tRfNBwlUjmZGZIvlXKit8zK2cL
27Js64ODlQ6E8dAyDIw7R7O+pQs9iNa+JgrXMn5vTvGzbxEZRXpBcpGleYm1KmmLKdjL0OeY
A0NgP/0ws/yK7cwKEfsPzS5+bHrxY/OLHQlGYI0bQSZEFrvKR06CmBd+G0rirdDhcZP43//m
ZCx7+5ZwAyzgBp8J4T8NJV6WiSgRoT/sCXyHYQGCxA0UgZdLQCoM2r1RRxhcl8jVSCEDUQFZ
hb6gILIilqBpPuSPsRKxy9D6vNS+gTLuSugJymcqQFdQBthyF5rmyJCTFKE96nESGY6koQgx
O+rQEeR2jxP6fKeCUjC0gQhy3/IDEEK+gSyAENo+N1JuAItc0aOQnkAPRSg6KgpQEt9WYMYM
gicGBqqBgfASH0QmQ74t4AP/iQdlOOlzCQ0DcZPM/zICIqgkHa7PXYNu+aRRQtGUyDDUMtAD
7ZHE4z1BPJoi8uhKVgRlpPDkWhQ70CXQgsxLt0Kbly9IT5Qjs0EoVyK4l1SiVAAFRgMiquVI
Fqj9ILDjJWk0VARxUCA34kcwDciMcWCHGloMzIZmADuJ0mcUBO1DO6NEPt7wUA4DYEAIjRE5
tJOsSEJbidNBs4ooBZpG6pMBf90TrvlBm0cSEbE+CjJfgB4UZCQAYGz8Iwctj6gZsL8wLws1
pUM3HLkl2rtE6BKucyugGgEHDAtZCIYQFMmj9k3QHbFZ8BkmvTu3/cUEosp7Aya/bpj3MDk1
Qi8XhXMtPqnTcxo86YyhPcBUBfrIzVzgPSPLhqSUnWlgqIx426Y7c9HBYGudHMNq4bqEu4dJ
3taWY+qCS6TPkWq91jgrgVW49Z5BancAIlPLTqXtrMa0TC+z4s5wLAMiSk/LrgcP6C/SewSs
Cu+W0JstGVWQ1k8ya/BqSno7IhQxiKyza21c4rMhIYx6zBZjoY0zK2DFm9hZGyaQx9irrO2S
sW17pjVNWxerzMxCiDZetB/jPsGauwyvGQWbQXg0pjbqIBXEi1UVcpeaGh49513w/bpRIBmf
LwfF/B/0WEEFevcii2bHJ7y9Bh9VBQFVFb7DwzFVze8HkTvEhOuLt/Ld+Rfri3eYw0+sIkjF
EnUh/yGmqF+8f1ZLh+BrQn0PKe2+7dorBhvHPSeHl84hyVPbFAp7WydhEjTrX4lDVDrdt/ZW
+FC61xZ+otd+jKXDx0PdixstbDYw29r61towScuAbdA0TEh2iBYcUrkr01rY+p3qERjcKj6S
S1gRhYHaE9v/UkcD/OI74Q2zrm/p9F4b7u7p4POm/gL3GmJ7V3RXQdN1w2WbB+vjMJrk00NW
FoFRewIfMuSjO28LR8USqClFd93A7GFpcLqzrkKvTbAR372Il4dAicIQZ33MOmF+fGE/hDsh
U7qxSfcIQgg8sHuE5OlNXDrEDeEigpiglIDKBdV00utVlRXkC7HKN5fkv/P5dVt4rtPtFsj7
9+zAMyT785Lk1+3FiZCGDdMIn30V0mrOIeYO9dyiYT6m4vrQNUPRfEzTGF1C323TZmNz6j9j
jr2bL5HIXskj3NiYpao6v+cT9y+hIBiPGWMaKoMj/W2gvvUdsJArYX0KluIZFt47UJ0l3kd+
DjY5e6YLbeaysYIOgboB5HYhksq/CR1DidEV2IRaC15Dq6Ou5VqBdRBC+FYIAj7Vs51snLgC
CUmhzPH81R6abKocGCc656xeoEfEnVXIfx1MpiC0A7VXeOwJ3zgTNkwZ3OH4X7Dlj7NkuGi5
c9+b2A9WTPgMfdIaUzkghlI1aG632lvFzhiVkz3w6HE9wqgTw9V/hYffKqFLgLxD+kWFtBCz
u86f+IswgMToGrNYehso99yQjEvkeo6ve2T+EO36qhi/kkDC+UqfLOlGJSu+pFcFDoMr/iXm
gFJjk5Zu2ryUNTyxcLMvSqFBN+3PUCapksEIz8H+ogMNDwlgmFNbP5iOMcE4xvDYXZKLZP2w
Lw7U+zp6RH+VpoA4BXzTnTYL3NPG/ncmZGzfUcWUZE2UtjkQaCx60DVX1yZGuGVJLkGjPyC/
Ulk9pKGcus5wwYeWIAJiLOTe1Ej/lrIdlgiagf0kaItt7fmW74JZcB7s0RSj3kQProipVEuC
P3D3NnFlB0d0uOjCD9xdpBeVtMUiTEFjJznsqseDgRf9rRm7a0svjmkOZpKQu8ICVmE4sQsL
uOcFuSjuKGIGA9pqK0rEVnRoLxYJyEpVFfrkT4IPV/wtdSyqqi/MfBQeyAZIg61Pd5z7B4cn
uPAaj7oBc+fe0MEp4aK0eVpyQU0CZpphxm3qdHJuXHELtcKQkgVftToBw7q4y4ZCtYcj1ixS
5E16fYqY5D2pNeC7WAxu80SuI3QcuUsS9xsXaSo2BHLsOlayagK6zXPhTaB4TSAu1L3Jdhkb
98uC4zQ2gnHBSR/m0clIjXNWIm9SkyOy11Jz7mAo67ZlgdHBgYZGipelAGvQMW+i4b8BVsYa
BCKWvxwbzk68xgZevLb5bO1xliwb7oOVvzKn+LZLxvs4wLNywIR3+UPqisndbDLGg70v1uE6
WKV3t1ScGUGwPYaI9G5loxMrXKABcJt4qT0RPExhez00LvNsmJaGY9BQAWkeNJjU5+UC25xh
N6VS0l13rvCKoSz2eBp1sDhTBbFUMKRrLwwqQ8iMC9KLDmM2LmLsczSywbTvIc0G4488sNkE
j7/y3jw/rp/Xzp47vDluxs9uYleQrvCGCZHCO/wdDIVMnN/uepdw+/nO+mjj7xOGv08Y/j5h
+PuE4f/2CcPUwtVLjf0tA7U7vObUG3o9cX1pMbM6vfjhq8itZsQWY2rLVZXrdCSSx02j4KMz
z45vcBgL19jNGGcIF9AMHnwnhf6pBYm/zeUSr9alqKguAVXteSrl85DPJV4JTFGBk+OV4Fph
jr4G+JxoEWG2wUJE6Zbv1IDqeCsVtIrit7YStHsSEpxsJeB5mPd9+g4T0J3tlKcOVNpOqgZQ
jXdSNYFK30o1vPmMKRnaCugmO9GOgSp7HMWpWkCVNXZoP7Mb84+lpwKbfmN4zhiPxRT2q1dP
hWxAemf/sUD3Qcf5rKFdTAv66tVj4Xtv4/e1O5BhYewTgoW0+8aDIf2PDAPXmC+9usNu7ryC
f2Stc+LPA4UR3Vs36346ZRzYnvEPCBBx/8+wdNOApAd868SGPtR8z15qM1OHjP0J4663S2gG
/4jQ2xLm6/ocvLhrIwy+PXKPvBA62Qt8dSwCrJCOOHir4BsqNNgi9oOVICCYYyCKby3wpMT0
QGAXlGBbk+7K0PFd27xp0FRfIxWdoLIFpsRBsSJXXLwM9jrfHg4LBL66Pe5ahqf3+PcgXr+r
uJTIDojacZqyHpHZiCaqCidd88r5JYl6iVXZ46/lpxwpXpLlfRlPQO34XgT+RstWulleP+FP
x17CF92Jgm+aBUaArzP/0AI2EvylB5u948POUl/nFXEI0VXhSPLBWhXskpfNj0D0vW60hbT7
zo+Q/kfOjzXmS99MabVe8mZK4kLbMzfY9jQYu9wFse9658ixfQ9co0vnaJDpV+IE610HB1Oe
YGMYLy2uwYLNPtxqo29/Y2D0P+y9+18aydI4/LP5K3rdJ1mIoAyiQd3keRAwcsJtAU2y2Xzn
HWFUVm6HGRI9Z3P+9rcu3XNvwMTsuZnPbqLT3dW3quqq6uqq6Let/cLj45Po45N7+X0sd9Rg
h5IEB4eZO4+/NlnyqmWVJ4nec+W+ThkS19j1QpqrQzcP7HubkpcQGWU0nrl4UeiI5/i3NEXJ
8z2KdRvs6B6+10N4I8e4GLq7+fBVxy0bidW1PH66EC/FLnoEUz+qBO9PjX1SCFK3eJVh7PMr
PyrJHUGz7EtoI7DwJTUONhXFQFNRvFfTQrBp4V5N88Gm+Xs1NYJNjcSmwfWR13oX6maHrJnO
DYZtAGoI2K2BfxvIAfgSJiNy+It6nK3zTcBbmIBNUnvrR4+wTVeQVwWbMnESeMfws0jFuNaW
2M2npaW6cc7yoVdJqdo5s1HqvjFzZr31NiOescMGWaDpR74b9263RDaGknxviB2wRLuiB7+D
LwKVsXWHd1p7fbrW+OLrkKV1WHuY3FNgnP6e84Xft++4vDj8V93zP4AZLNvxf+qGRwan2+5v
32068qq0q3wphFcWcFA2rPknezQS5evhTJ57CQ4R6+xtHAuCXhZyBP4z8fUGkejU8E2j8Z0a
wiOrMJLfZ3HUNfQa41lnbRpQx6GAZ6XyG/xB0NuWWLehe+4H6rs64UssEPvQ8WzIZrYYMgzW
6e+BHBFWYpLiWcH7z8DNIMjfqAmiLEx7qjazD5vJrzBqLlRCe+SFLS4WwxHeSQsb5ciJ7ZKW
AYzQ7W9vK4mQViH8UiiVKPZEHFvk+pjOvG+Opp8z3i/oT4aHebwqLYFXl36Tlfn6Ee0i4etw
6YPlRWGSd6Pr8s1gp0QnazO10AATmzZKtabfnl9bBrqVy7J+00DHahWDF7NwqCEu/L5w3JjH
gM33kbQ0gb7x5A2uwFGgmJz+guX+RsjDy5sBvX+WgrEnxIYqbMUOoIxQkvIG23P1EGiiCSDo
oPThJPsyBZB2I4FzsSSu8e0J3jEHvXoa51npSRLw6wlUDjn2RL7Hj5aga0/ks47nKeeeyKeg
d88SH5sEpxPRQYML7rXiK6CLTmk5HNScyZkl7EwR3Q32rUiSZvYL6eUOF2IthwuhdbiAkrzO
4QLKnkX30ZMR7mUMQgPVWpYgqriuGYgqP6QNiAHe0wBUKB58tQHoHlFJHm/IH2/IH2/IH2/I
/2NvyNe2ZerfviH/XtuYuuJtm2I5CRbYWC9aS2nYJqp9TRi94G+Xa0GBrFutn4hcQJPpXYPI
IS7lyyDWAFkSW8xt2r1PwwHry8e1Vlc4eDBgJQwViSqOxAvqB+AN7E+ADU7AjK3sr6V3OBiz
Uj3vwmEYE47oko9iQwynjnk5vAVh7oIew7CK0x/ir89FP62eM3nvmUg2Go5nIxsPSLEJdYHx
O5sibDRyxRUo/yN76vXC73oIPczP0/kg2BlMRDyHvzgcHAaEY6svh5fNiIWxD9P9ZI3SR2v3
gTHc7tVH8d5dDNaZR7iT3fxavchXSuvPJDqVe3Zx/4nAjtyzj/VWK7Zc4V4IjaPdyNdN9Co0
Dl7hMLM3yU6zs8V8NnWIlnyK9CnJa4CQ5uhzbvZvRNZj4eVrG34fyoCtQANMi/AriETIXd35
HVIsEIt84TeY2qiy0225fQuynsOXUxMCYaMpjwPh8w08RtgSygACEqgjOBgG0KXI0t98IShS
OdKBcR45cSQM7zcjrZgENJCVp5dqoLJfuj6/hIXFOQBUr9PWAl+tyk5BfMa5tt6IDHRAP19a
w9FiboeNR+jwj+Zi06RtDK5dKhyrH7rKRML341Z5gWFLfWmdUuMFqb4/t0CCZbud0kelmz2q
5zjRn8UeWZYCpj/1c9aI2JWiWJTyI/GmFc6mCGl36C8KChlAAazuyMi9lohU9ENke2YpBrmY
8y5T8DnGgEtsTrP0RQT0vGBkwq3OcXYE+Mkg5MKkCaMMffxMt8GLsc0vJ0hoh4oOu2owytAB
zpfFDGRbqiXwnyUc61LCmLEwAMsOC07OGgiOYIQH/3kIfc3tvy6GcwyO9bvSU4acy8FRAke5
jUlBXq+HyQFslXse+C4DjWdjoceHk6WLC2QFjdgED4O64HfKrj0RO7SBYXz3xgb0gyewCeIb
iLzdk7M6+rpP4KSz1RKAUuUsEEsvF6NRqBGcuiAomyBnmyetM5BuqSnFCYPJTgnT6eplPp+C
gDNlqvOaH5cq6OVU64LMbDbPGscg9hIEy6OJCebLGBHteBzrW88sWPCljJiPLd+QgoybyRjZ
51Hw0geDK8JI0U7KEYDxp6QabIu5IHMIDyH7Cn7LvuKdxyY4vJe4Nma33uqlVC3493JCpjTs
XdY4OWuW4zWYoYBciHo07gKxJJ9vhLgUTQg5UZCN6DY28D5nZPfdEGMKWGcxec90PF5MkDxs
Ja7z0YNz90ZCC0FXumQ1CixjwPiEE82ZUuJE/zgyA6lV1lWkiLvntU7vrFRH7IpebOn7Mtbt
y1jaFy2V7AUa0lzpwj4t/pC8G34z6DfaUnrGLP7ADlOS1inGdR+rYCxu/uPvAb1wifOC/l1f
3mj692ohBJW/+KjiWdwpeHXItq6mnlFiiX++xFnGkReC+RvF4ihpRgSxR8p8pMz/dso0jX2P
OMWWCI5rN30vav1G9XIprRYfSfWRVP87SJX1omRaLX5/Ul3P8rBK5n2k1kdq/W+mVm768ELv
WrbHFVLvI20+0uZ/PW3+KWLvWpcRy+XeR2J9JNZHYn1gufdr7sKkvyocn/3xgLtbaZEiasVd
KrcajVKzgpF3xhS3agP+Rc/2QCG6jPaqtNmrT/04ZAlYvVwQVXqPhJdmWft2xoF2/Os6ISpT
evUpw0KpEjGxxrYjpGVcXkXRGFSUMZvDqTqrFymDT1ZNXq0N4GTueEahjsiZcHCLP0oYCqh4
Pv/2lZWdArrLrtkLcXArgzrBDz+LffrBczMkzz+AmX2lhvIBij8S4XGOt+wrRvVnzwT8bE9U
fjcVJ+hNtdM0q50OfVMhVWGAh6LCVzJPOaCW9ckajuipyIXdtzD77fRSbIZaeavRn45GQ/TJ
cH6bbBKDhFGMpq6Jm8QPHrw7umqteV6q07cvatQwUAreB5RSa3Wq3dZZBxhprUVcNgkDa62j
5W0b1Ya2MZS1Ou8l2yEYWOmHlwoL5IJ9A257Ia+eULiyuo0Pmi+Htyr6FbrOTfp3MjUO3vH1
rf61TP3i4IMKfBENuF/GzwzEL3spMBUnHNKO2KEveOWLAxKpAmbwLMooafVQL2P0oL6wxSso
Fwhh6AiOEg2nDGz3bGZbfBphZgYGsbMCw0lS8FehVD6tyrx8lKrqGRISBz6DRcZfcJWLcn2D
+Pi21GmiixYiIj6PdvEKLLomMLQi33ASGiosfDogpPP6Wr5xy4csxRuAXVT7eI8FqJd61Wb5
vdmrNTDFYML0f8YXQGtOP4wkMHnYM5o9TziwBF819fBg/YnDAH0Mjr6v+RFmkktktyxXJfp+
kKCITt+S60qgWn4tHTq+eD5NquZiBoerXzO5szinnk7djM+34uW2k5EJSmUAbnk4wHpP7M9A
1OgIos4DFlW9WfDPUI3C/DqK+YKUQr8pzoQLjhe+raaJUQfo0YWHGd5QgNt7yTivpNBKOb5R
tgL5wMyBUFEgvwRuERDTQoBeclsMaaI4ogfYG9UffiUFn1PvHvkj4JNmOjbR51uJ6UHBkFgc
MpvudGxfTAd3Ykwe1uTzyFmm4GSfstMA+0FMppMsrNJkQEnwqLEaOP+648vWPibiJidY/GjL
SU6DPaAVJXk9dhvu13tG2+ktfgr37v/xHqfFM2R7QsjPz+I70G2X+GQS/xsvrLVoY9HBgHEt
VgOOHt77BCYAZ7I8iKvoNSADYhLOIztAhQGWMMz6nJ2nwPWf5oq3yFnx33TCCZzxFjjINXzc
Dj0vjNAc+SD4JEdlzzn3cyIleYQWiUkODDwT+UagJbElkDKiH/Rz5D3OCVFUWE7g1YyFQQdK
DJIlg0IZ/q0N04eK6LtFU/IlGFbA/r/xEDfBHvwkzl+X+P2YXDs8rtkJB4ONokxa65a89G2w
LFPy2Bl9tu4cfqBEzvjclpUJOLlvhqMpeRFJJ49tIREfZ0rH3SvMCZzLacQ3iSq1nRaF+QPM
YGRwp1M4OeZXdlhUAyTBt3EoNCRiSLCyCMmX5JDjZGgH00psw3/U+qb4hy1h5PIFqG1gOt5/
pLzfjjy+o1qozZA450eyCmDBdOYEFR/6nR8qrTqPM2uI5avqDHSVYgfqykprQaL+1COnwCqQ
365Hi/Sb8+GjXIi/576E3kXJWLyrfH7F8756TLrCV7gfPoYj8KNPr7z3VijEIF4ioeDPwPTY
PUvZMijTicdTthVa5G5tX2uP1QIkAdQM1gKUw6zP6vUPh6cdwjk0jsKmZv0Q8FAthh2qlQRc
ni7os03rg+FkIzjKEZK9g8iraiyrSkvsMS8vpLK/1BwMBnjxyGTHv+C6Jyewxu3wfdZx4e/7
LGz9IEFe5Xs8D3v4MEE+0Hs+E3thfO8E1r6jbzj9HSr8qA/W8dEBzVG5VXKyYHYUVrG2hk58
gCty031LZjrtasungComEcWazXpexohtSZGO0O7mzuGYteeP4YliubG/50Oa5Pcy2rRZwYc0
Ud5/v9cl4jn8FRfw+AxazOeAVCZb9y84X03ypUOwCDbKNa/RR0gVmhil/yhq8QTuN5pOZ2JK
SS5GI3Ez4ahz1IZd4wHfPPs6wQVsNW2rf50KggbGnQoMlm4OsJBFeDJ4S6Av1cDNixCEtGer
8mq+ZN7PFiqgC9gLGUKFlZJQh9Kxn03/z55Ro1TkysNRNxpYzVDqBS4DVMy+EyUpXW541Sn+
v9hlic7XIb+x63y862NN14V1uza+btbaOe89cMfROWtnvB/s2GvxlqIt/uTpzHjUB8McIA9l
fUOC29aAx7iyQQEd31gwtFBYIDk/dfZIR3yZcBoXAGST7CsWT5XJCLths5EfvgGtZhkRHEPa
V7DYqCP4moL6whjyMtcM2htDl2G+5pO8Fz9I/BO6UoMv5DY2/vhD6PeKwKi98qdKgr+yEvgz
jRvsk63J3mVIfPmWAPVgfnnyVc/2MaLkesIZ1VxbMqPaDyqWMcT7xjYt3Ovp/tcIZZ4QUp8u
4Cg4tcbDkYuPYzogCZxabiCz8LUs+z8QRK4tlyQn8YGDPYefxXyMS3pSlPNlvAeQ5+4hxj2K
WPd+xqzNJTqOZtRcFcIRU9KM/aSXIRkLbUH0iul+yTg1D5c3Y8kkNpWPFglOGMOX09M4Qvpo
bKSeT2c2rFkKH+c9JyM4/SVz1WCF/mjq2FAj/BU5Jn/M0BX182gzfmKXXGN6eWliHTgE7RtV
hz5GoZDJ6xLHB5RFN8A4yu3tbaqDYHGEeEt0OVo411BRZVvaoLpQemW7jpogqdpHyWuCz9Iw
SYr8FWrRg0VgbQ5eCeIl1IdynS6JPh4lRdEkk6MnHgPtH2nq9GcLs48Jy47ir8uVv0S1dxpv
TQNCbmqOrb6J2EP9fNjHAfk2NH+tBM7e5LSrFCEmwWqw6bFSP0D0ZuC2Rze4oH/CBQDiKTn6
UDycVAZFchkVAVsJoOCRbWGWI3wpmOVaqoItZiMY211yviMyjuZyHIMHD9KI68SiKOxbdhow
L4Zuij2UyFOp7/gmq9nI6ke9OeLB0DFdKLqc5NG7pA9neSBgPGfUCayB7ypCS0w+J5RMFDjZ
evDJhSX/tb1Q5M8BvaTIAqZPL+z7dItJkqL9PpFPM7ye/LWSH1OpWMD3IBBMirmbJkcYI2xU
vCJnln5Kvg92XMBndQFX5MyZ01l/OrA/GHkyfBoZYVBqMu1/XzzfjczvvEixXFl5H21CSBLs
b/gxw9ZrBeB3BvA7e2X87vlk0Kh//+hFcor2VgzGifJqY/BXTqjlfQLJMjSaXEaZz788CaTR
ogXHXS53eQ8ijVSWTZ8n6NJUBKyO8pYGfr51U5F7GmA1Klwv/ozx0/wcFkf4WWFBqGE6RccG
NQ/tOfEla34V7Wd+JW9ige2qDsNVFqOj0Edmc7NFH+i6T1slCAwGT08BFBAMCmluMsKrivD4
1HSxBdcCSKFqDD8tuyV3QKyBegSH4FUT53mlcwlMvdw+A12p16tXzWqzUis1aTjYDw58a0s7
PJpRYlXM95qK1fbzwt63kbH/Na3ytLQycYluSrqmf9ooVyxIrE3gMJVz8KhilA4hu9xzQg5C
bsYWwKb9QgIJYQ5nRu4rcwhy9G0yiiMyUjcSt488nPZHwuAkyuIqSzxVdMWU5HcUHPYsyByE
8K8JpDrDDnVoyWi0mmJmyTgDVwuUExx8jF8GtX44SaWF495J38nQ/RCKKHQ5JGfbz8i54NJ4
P9sT31kjKJw+73+KCBDJvGtDro8rPfFUGrwGKKIwDV+cUZnw0AnU+sRnPZ5MQvV4Se/1Qfq7
QuMEeroRVw0JhHzPGR+sx0MiiNT/5J/PMOsPuY+oe21eoaMS+hgDx8cPKOfDGoNqZvtRPkNC
Zw7PlZ9+y/0UOckMPltweYPHCyxHAB8YFSNDo00Y+kZJnBfIWalgtxiYUn4GiPibAWf4S+U9
wE5n4RZsgKHMgkd8PTwHnThUJyMQmL50U2wGfI+G6kBlR4iUsf4UCbcCU/yBOg4N0Ltqd+eT
/niW2rxyUZrepDFm1OTV13Q66Hm9EZTziSwxWJIJbdzpCBfMXz0J4OVm2nOx2uBMqszN6CPt
Qgjms8ABq4wkaXXubERH8MfLhOoKuKKLUAu8pnWn0Oppztgf3ZJHQLCCL3WEFwmUFxIyo8vk
fY8slKfsrFgl1T5pnXLS9qYm4sOUs5AOgN734OCJ29PPqnkQ5Q7FU/ZYDWEyn+FkpNXwx2/m
Jf1PD88dVvIGuZNLaB3HMvxI1K5I/dXLr6d2Brc2wUs6x5MhPOIIgXpHx9dSKAJYn0RX0EF4
NPcnhMhg1qAEGg608nBbnuXJqIqGWdSwrq/m0wUKC41S+dR83WmdtUE3a1SbZfKl9qrJkMBU
S5YHct+tMlogRl/ZbN6ntQc4yuuJbzImWbo8jMbmZl9jqQzGrRxBscxP2hcVCUJkln3F9qPU
5jFZ066kCVbelHopchXYuKMLjgLNpSaPxx5P53cBC4emAV2GonvJ2JqlElzSom5w6KIv4d3r
CoCzSa11ByCrrnsJIKs/5C2AAnnPa4C9UAanR1O2F5vOuzPANL7GwcGLDN8edKzRpTi27P71
yP4zbhfCA/l3uJxJuArQ2+9jBn9tPNHZlYs3nkklnIZhOk8om9t4xicUsNU2cUwDe2TdSfM/
h/zkdTMluaH0AGxGCsj4tNCaBHz0iCsrjoy4OBzbN7Y9g31COpZu2jN0m5P5UZM4Leu+k09I
iS9ZFX6eFsHMpsXcC5ZCpYFA3yRYVSrefHd9Q4TSPO+UGjudXnnns+X2rwfTK0r7QL67oJzO
Xc6rh5qpsWPsg1TYn05krnaZvzJ3WyxkBHe9RaN8EXjPZwGLULfhXhcA/WpKVjY+RWnVU0Yu
t4V/5aCjtA9CBon0GmPkRD7uMIshWjEdxN0Rnnb2FA5/ckdhyEG/3marVytXxeZbBYhnhuDs
gTyuvuj2/doahfwxkwD/Nnn+nEITI5/EqICjO9+cSHEup5/tudKYPcULBQ7TBLw0zdTmNgzp
Nxc5/e5vk99c9DMWkT+buKaqcGMj0CS3fA7UvQmDCU4kaZ4M5V7nJWddXOu8lFXXPS9l9Yc8
LxXIe56Xu3uha3M1D+9OulOrnohGq3JWr4pKtVvu1ChgNxXG+XY0Z6iXtNNl1US5+emPpf1M
8HBadjrJ4yMnOhjJsrOYBDh8rJaRcAyscxJ5A008iDKalABiWTbI1eeT+Cr3ATXChOUQ4goE
xwnCw8I5HMkAEXSQm7k1+Vv0o2t/sn8PfUzYru8iGzzmRXjMi/CYF+ExL8J/Yl4EjSah9Rxa
4p6t9/Ue943CftEozt3+vdyRPluzZL8melJzTxem5clwde7oqFXcJnujj+lBaILOg23u5ws1
s67u2eIeWXOTk0ks0+YSEwAvVfNW7fAy1/2gb1msbHSzwnVstePYUtemZT5NOwlpMIDoFugP
iToRrwYlu5gLlOYpiv41eguDYjexkbCk89P6+u3R0ja+brS8XkT/OIrpKYijgZdvRwGHIxoP
KWwmK3xsK5X5OuCA6byvt1K3aZFKzVzb/GSNUuMbE3+cXd85KSiB4wiYpYkaW7VunjUpOkEl
Td4z++k/UA8LGxwvFo5JIcYDQxJ/R0MwsEBytX6+I1SgFVIGBLq20C5YlBMN9T4KKmAF5B26
+SVhnO42vAte/G5+ypsEKfL0D99/AzsGWU706scCxOj5UD4AYldv9vRGx6SZPQf9HTm7s42Y
wgqkqgG8/Goq8ypc2OIapgmDIu9xymoJItZn606gr5g9t39yuLV14UxHID+CPjuZcpI3NAiM
ZCyFIYW+sFTACzXCuwwIiAxg6P40GnGaQY52gu+DR2gj6V+DghxIzQKNt0WJ4/IvHDl6LGAn
/WvUcdS0HXs+hAMs7PXLvViiXeuVuDW1/DyEXg/TfG3HsVhAd24DboB2MNo4H87dhTXCQrVU
lDZzAvA79pWzkbu9LLBeGPgRq7MDcrb8oftRtOsV0I+6uTTW6fvV+351srdgJSO9scHmGa9W
0at1BhKhg7XyXGvgwxr4sLwRdgEm1bP9erZfr5HtksHLEZVWGaHu0gAv/cqXXmVERyHUdV4I
J6XhQmu1ooySnDkUEREYwdziTALybm0wMAmHTcKOlCJafz2BRkMfDfkxYPmSNYGYG+Z+4Y3y
PUDemhHA6Dmpw0IZ2JZ12k/qdOB9DJrbAp0a+w3V6Tjr3HESomFwJ1Z2bCd1fJnUsR3v+MlW
9PotvjoBu+B33ZQ/dTP+9E1Yd/GDix647FJnE5DJuXlcrpi9lnlca6JXaHojRd6h7LN5iXfE
6gMcRoU0iMtGDm+BwzBqTYJRroRhPMXKARA79PvPPwOgdIKoUSi6uy/uTLwNxPM2cNJo6Dri
rwf7qiYfduV7ng5bqCOYeC8wwea8puHEv3e2Nc+A3DBxrzHKIRw1oPXgF/QDc+y+Zzx23ClH
heLwNtKtVvb9IXf74vKySM6ltwXp1IGg4UN028JtLvninepurapsfOQdlR3QqFf2YH+UCAez
W1l5oCrjKqysfcGDh7VaWdXiqrCiK6sefEwHVl3FA1y57GpVpAPd+IaQctX+enZuin4kUdpR
KB25F7b7/w74rQK+QDuchHDH3nL2p5NPNj9ft2BRWNy/XIxQEhpbLvr2TzDfEa0X5vNewKqQ
4Clf/7kgW49TsBAUN4u21B1vu2MTWiD+Gl5X8mkh6vcs4er2rehHfyQqSKh5+dFDGp91cb/U
BBkXe11E6WV5ux3VTp4ARE8J/dt6ONDGB4AUltB8sKQ5NPHbI2ruAGbuIJkkALrQA8KmCStg
LemaXVM3osSnbSCpxZ8qSNqfbftGYo1KqYYKZIYej44ooB7eWqJkv5hl3WlWR8R9fb+fsa8t
z8kfO+eM1WsgV4QpeBHSYtriXKpLkniG87/KxM/P8cWsfByPNSgDfZFyxCffkUV0T3k5hn47
RE7Q0yUm7KKgcS99nRyQkfJI85v9wJCgUsJA5bRgzur8xXqRI1ltrxOv4vhVYg4yEW0bTQ4x
XTJ0iLrjGb6h5TH5E2BoL+MrwxVNaUhQpoJAzbAN4ShYGW0E8Zr4NVTNMxHE63pFCp+eUBxG
HBgM3IuXtCAfVdkmWHgUqo9BaZbVRnkqsXD4NzsM6QL0v8/cyJzeCPnuRHp6E9pPPWPA3A7H
xyUKCCv+gUP0GogR88FHvLkyrOKyBu8s4DTAQ58dqChLIj53v8Krog1KPEf2Rb6gkRq6Bw+U
gcvLYd+PR+lF6Q34nZm9TqnZbdR65i9n1bOq9za7U32dUvqK9xbg3hCMb4aQXw9Cp1qu1s6r
Xz8JPYA156AHEJ8CIM3fv5D9QvoJqNwfeCWy9rykgnH5YCCNhweZ/1qQS9Hy4WF+9dSXom4I
ZiLWtFudntmtdmqlukk3VK26h7XaPvWNKH6ccf/ujK/pzvjq7vJf010+0B3z0F7Q/eZ46GY5
+mO9WtG92kTJNiPK9Y4EIg9J4OuxN5jHrVKn0qme86NqjkJLdX8W+X1y6/GezcTfAR9yaCcM
ImKPL0AA69iftsXTvoo+u/FT6actCZA6kGrGfWFS3EXxY+726a0HOgB2+QzlTzxD1TF+RMiH
4ulg248PjDBevSp4Pz8z9qSioQXfqXarsJG9Uu+sG+qCQ92xof9QqLGL4HI4n4du/9pbc+kK
3keNK3drHD4JPmoQIivaKD5kQS6jSwTlhBX0spdt8wltF851FkRjdzpZ2bwYbx52OFvS1sjF
G/+lV3qtbwj6rLUYufFmZxOOycQ+bmR0V+2/kGDt36TAzviSYCJFXF5mRHSv1iCNpJ1lBO26
lrtwvDQNtMW5fHyTQzNy7DlIPuMZ1pcvSzyKe0Yaafp/N4cTkMRGI3uwebhpXThAIZsxSOix
Li5HlnMt77E1UJ+hUUgPkzlMfm+/MTxGparTOACV/jYvKpUOcZedHTJAsmRmcohZWE18RY3P
63/+OQ8/HrdaPYpc2yk1fKhGviihemF8VkD1AOJCLAP97t070WBhMZL0148MMOxjbGEgFjIi
oICav0lwWJXbXmmU6q23gUVmjiTQtQ3KsiAfo7sRPYxSSJi4MDllcYWfi+rn6CySmxb9pkZO
1zRgFNcssGc5XjWVIcfxXzGjNTYl9O4C1/Z1tVGpHp+9RrmhDD+cnFQxncDfSdYI628XZY76
RwqH/ysQ5BN2G83Rc+B98Qc9tZpNUW2YD6+uKNzVCPRzaR/CutwA0JceA4s/Nji5Cqq8Ll6z
0fU7T95rA7jIrXKhVhSEes2WJPMWZEPy8aX7RUdZCwZ+GxpaXla15uNw2REH/PJDcXkAVC3e
U5HaVEHgKbx7YNWe5oryuZ73Nc1ryxGndvMXQ9fsz3KoqxmmYl+p/8nn402kSy/8+2k6Agob
2cq/F9ZnbgN/QV/g39xN8duTYDDhyXR2JHR/PUiDbT5c/RFI5vAlcoOhfQq0I1+L4C2uIxXR
6cRWd7iXwzk+sQP1GF/zgr6qclxMphS6lkJxcjJueuePbooUsfPCvkTjJrkc4Z4FcioNpxwl
fQgV8OlP+H78s/0TJVKfzXBbMUocg8c7cjKD+pFn6WGmesfJmMG+89ADgeZ8RIANqiu/MdLx
rvxZrpniE8+fP4+OUTEGeiMbhq4e21qTYT+1WSa+i+xEtvRXiWr7x7bqLTJW3E/LpUO0yPib
Utme0pGO2ZrvwhhNigCMA05FwGUD65VONsQBMS9G0l4WmXaAqa32IJ/S7bnZ936QXjJaL25d
g6Xe5LpG6ACezxoG/CeMF4e5vcPC/r18ypcB3s3mitlcQRiFQyN/mDcSPcuBcUDfW/gP+ZaL
B/XiEw/qxSe+wotPrOXCfS8fbpmVSCjeZJqtcrUOh2qZ5c9T04RCeXGaWPgkq4q9wnI3R2kE
RPAuWndjpG/Nf1Jx14G0J3ysaiwCQIKNiaCEPzOvPSi+ptJE0Qkkp6mjdDmsY9yHNFdEQ4zU
W48Q/biFD0N/oTiITHZ7h7nC4V7yg458Zh+ILuOR3HoREMX9HtmJ7/iIQawbAzE2uyUvEYLz
W+MlAi6kkTOIgRm5QsbIvaD1/AIIqND1MTjSY3Ck7xscKRhEIjZfwe5s/2nBk9aa839rcKUn
WPAhwqw+3ifgkrhvwKXn6DexJOASSPviHgGXREDS97oHqZzrPkZc+jeMuPQYb+kx3tK/aLwl
cU9OIhLjLQkWB40DEKq38kYxQ7FFxFLKEDAVUMbWC6KTXR5ER6k6UBHgRoIdia8NdiS+PtgR
LcfubsbYRfX+QOn3uJXCCzAkVgUYevIwIYb81RGkOGsCDIlvCTAklgcYCugEyVZF8U0BhlDr
SDi4NQGG7qH9rgoEFK24nv4biNjzMArwfUMAGTlUgeFvpQNHNMVVAWfuqQt/n4AzZAoS2teW
sRJ+0kkGgN3MC6DL/YyRp/mHXAHlompCvRBbuHeol+w6EVqS6oBUoJUZN5aGhNlIiv4CRPJA
8V/E8vgv9yCxVbFDohXXI7FwkI9C1igIwzjchf+KMYpYi8TCAJVtFwAWkm27BlmZjICZae3A
GEIXGON725Q0gTHEQwTGwLHjuhSJ9RSRAnFdngj9E08hzTbRdzzRGG/wbTTNxWO/0Xcj8fv1
MPoZ3ztTIuUj34L6MA9LBemk3/JElFl2DpkWmdqKUphY6wmguM8TQPH4BND7+K/5BBDNA+s/
ARQrNkU89BNAsWQzGI0PmC8WJAN46Fd6QG3rvNJjifEBXumx4rNPtLlL93nM1tZ6d4eq5fd8
lyTCYJ6Le75LEvd9dyekQhl/d0frVDBonfYNf53WfcK17lKtmuP3W6qkJ1xyPb7xCRetXZEI
J2+ok1MO+0cKUuB5/JXbZ/KFPBnkMA+88B6ZefaT6NsO3+DwMsECIdZ/34LzXfm+Baezaxg4
nd3dfcUHvjBN6vTDB/Q6EUu8TsRKrxMafb6YAc1+d6+QKahbryfi29wi9gs7MG12ysvys5OI
VJpQI0EYTqj1ldHzkiBFxN/i4V5+aZDZHAfN+xH+Q/FyOsbVpSdnV+S7gE9TxtaNLb0RD2W+
RnuAocmgVQALXt4hkMCH3XzAES9Udb+AlWW3ZZS5oN8FKCx3YgSi6UgGFXOCXVTftaudWoMC
YgVa16fWgPMt0u4KZzHDVQoNjoL+0fj8L+fVTrfWaga/voHPAcgNfvUEgx/Z9GxNjZdrl8rV
jtmulUvmvhGap1ejXIIezOreXnIxLoRZbh2X6r3kCpVqGX10YZRLAFTP9wtGPre0xsE+yARL
atTOO8mlp22zXupWO3+paoZYO26Yb1udN+1SJbkCNC9p2nLXvWrReJFfUqPUAxhLyhul182z
hokSxNJa9V5pSXm3qptB2Eq3Th3z9Vq1yonUEQs7HiKrSuV4L/eioMEXKCy82F9W+CK5sFkt
m61uu1N9ry+vll7Xq8nFrXrtvNrr1czGC90mdF/XzFo7r9loWaoZXbd2/L5XNbvHxu3trdlt
lTXVmjWz0wAGSFnfE6v0Ss3jUtnsHefyec06BascaKq0uqe145LZOe69KxzoRn1eK/daHbPR
Lu/m3iVX+bXUAibRBnSol5KQofO2W22Yr6tNYHxls9uuNeut8psQQnCVd+XT16VKxSzVX7c6
td5pIwma9PonBTjA9Tq4aTm6qY6VwUIGfuu+LbVN4GjdNvC+wPdmCzD2tNoB1gzFwYLqW7MH
LNssBz6Si3W1frKbjx0YZunMiJKxYrogN2kYMY484biJle9ryAbLO7ta9oHFvXe7B+80m4jl
552Csay8U9hdBr5TeLe898LS3jt7Swff2SssW5rO/tLWzep5qaLhnNS8uLxz0kaXlBP2JaEr
l+KjjRCeEJ4e605cKDwtdU3gZCfVXvlUBxfr1OvdIFr6nyvdciXWJRa9PV4Gr/u+WQ5ID8r1
kwTvOMKGnUISJwOK7kkDKKpTe5fUb7PaC40SUyw3S42q5qysdTWbWNWWNMqagu7xmaaX01av
XT/TnH/tcqNc04CUDWOsW/X4vntea5dDEz7uVkyMYVrtAuMol3uaduVePSjjlVudKrKfECj+
WsIQoMu2IlYhXCyhhiRgfFDaLvXi31vM/8Ifm6GPPtgIr5QFjVq3nMQr5fuhnt2/nkxH06s7
wSHVHJFq9CrpMDLClyQYbWuOj6o4fltIqPa3s9TBp56JrUeLKzIttfEZS+ghUwRGs53U/pju
3GX28HCL4/obEIzPzRONuIbl5fYvpo5nqfJyDdBmWSXspFIqH+xruJeqc9aoJh+3srzearXD
uycLmsdLpoAV0FSprYCaQTdx9xcjd5iVqe3lxolUp1Sr0I7UzxtRDEhEgKbtov5Nwf/iyhhI
AG+qQazmD2ajUQpPFrhUvdak+ehEy95Jrd6rajSQhDJZctasvQsMoBblh7W22Tir90BB6+qU
l7ZZqpyXmuVqxewAaSf3A7UAS4M90QezclpuRzvE7yjftLUdYo0OEI52MaBSbWnp645GCgeo
GoTCtTGrZc05AwcXcKnWm5r26Gifa4TlN6e9nq7TUk+Dvef1UtMs5vLGL0l4J8LIWWtrBJ9S
r1R/kwSgNJuNbNcaafgHKNVNnTZ73KlVXmtW911eo8bXS+1jTUldo6ngdlRAZepoxlGFf3Vj
fAuLl4CsIdgngPJUR1/l9K15Um+9LfP7/KR1/GXaVdHoL63hXPx1YS/sIUaf/jECq4s3akt4
iHBtx01s2X7TA+0mqWkPZP3Z9XRyJ7qJZ88prFDi7vdKO7VKdadx0tjp1OvJJxdUWM55oQIl
b9YQhKp2mjjrbrlbS+6XSpasU5hpB/ktLBZ0iIHYAyJmqVNGH59ENIcyLQpVzhoNjaJ/3GpS
4PRktPzlrFSv/arDvN6ZhsFQDPdeKfGkrypPpZSRw2cMoC40LoZuOjJ5hhFl8aeldvt9o1qq
axjbWfN1VcOEEOY5SN+goe+CiLayUrexhJZlnU6prBvKaTtqgQtSAWvZATkZvupUtlKjUjQM
AxdEU6FSaveqZRQQOic13WHRO6vrjplKtfBOw+sqrzsakqg0Doxcor2XcqEbES1OfTTbtZYG
abQmyxPY8KbmVGiCUFRtaKw/zWr+jd42VDR2D8qaJcGyXksz0m6te6Aba7VdK2snAvhZQelD
s0N1nWLYK+/uFQ3NFp3XSmbntNbUQH1bayKNm8WCZlB4OHdLpYMXu5oKhLEtlPZW0TPM26dl
Hz/L1WZNQ0yVev6NHh10A+oWd4s6C/hpCV0tNVv+vlqHM/CkplnnTtHY15gAu28OinVdu17t
dau5m0QLAXfOoPIXCJ4TJpNgicbkEayiYRknlYpmAU5r7bamqN3W0EI3yjjk9r4dzm0KGo54
m8IgA9fWeG4NhtMIAiACdUqVCOGrc396Y09EB9WOxHOtt0zs0WBVp6wl+i4cIZHzTE3HmrDX
yKUVG8TbUqLMUhpbrr2Yiw5OOlkCAHTUTr02B3U0NZxczq25PUhrRJdORGdVjbuVJrS44OR5
kTZYltRmMlu4GILO1vTVbCfbO6gABCRM5AJiULfcqVab5ruXcAIUVlR6//LFftG36l5bc6vv
UsCLhM0+T7bpUGipoF3aizXVbdWrIQKSRdV3PTiiI0JquEoTWvdKwJA7EeNfqwHziEqbPm4R
J4zZQfzm78v1klaQrNRe16ptnZkNSzVE33pXMjG9Tr2uOz+pSreByYs0NWpdHVG8b5ZRaV9e
2tBpqSAW6xSfTq0L61nUAOYcRzXN0d7VfO/o5gfbWa90NGYHueto2Dd0l1KqyjvdPRCU5F/I
ejoTxUHRbPfeB6+Z/a+AXGfN3sv83n6QRZyXFSonEm2+rKHWfLIxEMgqXPH4rEtUqcObaJFs
/ZcpsJZh/yZCo0zmr0uNqs4YGGczVMu2BzIpypU1tumhAjVYt9XvyeP5pVbO5U3QNjTzq7Ub
NWDDzUpdx/elo3XZmg9ifL9XPq20NOpRt3yLl4+vtSItiO5muwH8T0M451qDX6eXfFmMd2ZQ
Fr4i7tU1lNvZPdDdgYEiVa9F9SA5+RPXmtn8kvByNJ3N7gR+UMrqYD78hMkCg+t0ol/+0mud
1tFJ7hyfCvGhFt3os5buRr8EDPuka55ouC4XF7TlnWoNaHoZgMqywpMlhadLyo6rywrjZUoy
ftfbhaIAg/nLcfgIg99NClqlEQ9LPW23y4ZUBnRNHlKv0Q4NiCqGbaXd1sH+fk4L+y9L+m3U
gIFqS8/fLWna7C3bm7Z2jfGayYxMAYQabX0oa/e60Ra/NN8VlvTfaTWWlMI257WFeD2mLTyr
nOjL4j0+CdukiAC7SQRYblVKWsCU+69R/fXXlmaJmifdMNbih/PdINago0Azsobwe7IUd9bs
tIP3uegpUYn+bp4XwuJh41iPK+W2tuxXwF/tyrWtuTukF0Y9TG8XXjTKJokuXd7VQyJj71Za
Xb9ubMzNum7Q9cQh0Z3Q2B4MLY2gXatUW7E7Glmni7GGwvW7ILck2j7PusfJ0gkWJNQ/Hi1s
dzp1r5NbHdfPqr8mtXtD7wzFtdW/UYZljyu1uihktmsRVaADohb6oizhhG9eVzSm/EbpNXrg
vO92ftExJTiK1euSpBHXhxeg190FEgcHJ/prvXYMNHNSL+mM9lSjUo3VWMtdlV9JRd9wJVVZ
5bAqqz2Ex6oC5bmsAqj9w92Dw734E7CQy2rx0WX10WX10WX1O7qsJtcJ6xlxT1UNSjy6rD66
rD66rD66rIaa/3u5rAZLCfdi/qHsqaoHGnVZDRQFHVYTHVIf/VRJmHr0U330U01Sth/9VB/U
TzXyuRkxJj46p/rFj86p0dJH51QJ/tE5VQf70Tn10Tn10Tn10Tn1n+uc6u+/9ETVlD56oT56
oYbR4dELNUkFf/RC9eSbRy/URy/URy/UQJVHL9RHL9RHL9SI1eLRCzVhaI9eqIF1evRC9cTu
Ry9UEoYfvVAfvVADZY9eqI9eqFGm9K/nhcopQXb6s0V2Np9e2LFUAol1kv1Q4/W8lBroPXpw
mDcOC7trJBBYDmtVeo4Dyh0Af8vQuH0MQ+y5tRwGv7AvSugTe5AcYqLm4Ef0HznkmN/eV3aj
CbUuvClHfq/CBxzVPofu3jdymXxORqDfYIAbG/3sK3d0gam0MF7y3LYGZj9ngpo/TWEE7ZRB
2fUO0mnxvwLEs0NRKB5RQz/HFnXZ7tQqZq3RVgPm1EvZV7CMMrWNP5sjVTh0LJOdZF8KdiGF
OrUuKI/nXh15jws1OoU3ZgsOLvGHX/mkfRb8dTd/0u6IPzh9EyVk9YrQXYaB7jznvNrPxfHQ
FegZNyHxESctVHZwFZ+YR6waDCcDzL5gO5jaEYt79WMgcwdWBe8BYIEwFvrQdrZlC9UQeqE/
hnj5Cv+VNe/EXwCCqqT+5GQlABqrtKPW5f67Fkg9JmK7VpQImrRpRdozscaerSZ3IKn+Ekrn
4qVEzlUkTe5njT10NN/dO9wr3Iu+Q2BWk3bhBdIQ/C1J+wM7u+0Xch83NunfzYz6zLQN35v2
J2tg+QVM4diAftjEPGMffLqgggMuUC3Q4Q2/47/+ZyB2+IjLLwpv+vhd/aHiPb94j4pX74uT
mM0lVr50Z5xoqhVaU2P3MLdO7pYlcAoCgOwWD43kmNWFPYpJjv9w0pZIvPmItzImGgjnDOpz
GPRUIOFVNGZ9zKkZ0zlIKBxi27TcWx9OIHPPBmUwm92lZDIik7OphXOrletmt/ZrlaK2j+0x
VsfsbkDXoUbh3/xGqzfYnVszZ8kGy/KlGyzreEQDtJc7ONzbWy85jw6Ot8EHh4WDxA0ucp4G
/EdmfsKTbrYwB5ZrfYAfPm5bzhDWyupfI9cqdYGtndQ6XbzlpLcRRyrxEfLJ/nTiUrbMFGcd
fja7graL+Ry4LUFLc07ZXZkvBP4SGMXeBo45G1kuBv93QFSdwRZjJmc8CCgThn96oPxzgY4H
nBpnm0DsEFaJHzh5xSClwU/g4M+0lXwETAenRN2nchHEs9zpeNiHc6GfeobR7c3xeHs8NilN
AWGanHT2ldV3h59sKIfVU1WXYlXDuoEBgvIV22NVkoxJqtSXzwCHgLJfHObW5N8xCJJ1I5BE
7HlB4g/8LXHnxzKIqa+7GxtbL0WWgW6AHnE9XYwGmJ1ggQm6YU8n4rNNefUsmcMVqW8GPc+f
iBAIQJmXc/IdJnCFJ0LykFhaZ+b7T7ZelyWA5PZb+vYH92iPiVLgP/EW5jTBBGCk99GLqIvF
cESTxNdK18IeLwCvp3POWPGiSPkPjWIhk+d0Hz/62a44bXm2TH552XKXk1U41NVytpv9EWnI
A/Ch+1Ewp5+K8cJBehHA1m5g8W1rDmPMChDPBlMQtkg6k8kc0jJNho3wKH3icGoiklDehm3Y
GnSFPQH9ilZnWWow9cP29Inonh1XgGFsrGjzRNRbcLZXKp2NQ0xQU+SsOjm15SKyaUnnBqhK
2n78oyTwI4xva8X4/MqRAciOK41SvfUW+g6PnpOhAEJx8jnN3BQ6yn8i+9wu14KLjkJIaIyz
/hD/z6KxPLDSUl6JVl3Gc8bjnX52XrhJOsX8smS+45eH+EbhEA6w3TU1wxgM7+QyAIyG9+SZ
+Xg6oSeCJ6p+McUPW8zHL25Mez63YKd3jZRMlrQxpOPOlFoAifwpYHGY74g9lkETwD0ya2XK
fQTqAOdwKR6QvFQ88NIe+d2Wzow92S0K+9TF9uXIunIwxS8L/GhFAKDmiVkpHwWmtBUev3ZK
W3HYz16KfwSAn/dKr48Ep77FhG3Cta6u7MGRdMUWF8AZyIWhW5UqkafYUEYXL2NOez4co11j
OOEsP2j3Yinh6Whwc5wRTx3+HwUqWsmncAbcgYaHmUplPtjci31Ou1lUuxj9w6nO77WpxPrM
ydThXbwEDu2wABqirtiTJg8hnD5nrFku/QHOjqbWYDxeaKjGK9XSjVfDS8qY3yXBPn+4F1eW
dJQTheLRDpDgfjLtULbPF7uBNY8IRb6ylRZ//JFUSnpTWmDpb1oQnb09TG2tAcFPG9LLQbCA
oBsFm2skiKxuFLTTaczit6xcN1HCLJQJN0YDEN4W5rxwe5sjjAKEKdyY7ujCQxixOqcRbJle
xgsUatEmLukdiNz+YeHFYX5vbayJAGGkyR8Wdg/zcXGRiJVUhC38Z5fQZnrxe/Z/EhAGD1Lm
5lMxu5I/wBoFfroaLWz+NQEMY9bGN4PhXb0fmK0EMAf3B5MwGs4RqAUDMh9wxjUAdY8NtTbO
hcFg+Ads6v9EQPjX38jChFa7vn0rv/Xh1OMfE/qQNHfPOT/JLtsDByABc42tcYwNR2qHR0fm
3qTKe/G66jUxLxdUGs7yeRrocuJUfSdzda9US55eDT/V7j5Zyg8OjTU1sQQoiqsb+4f5ZG3M
yB9QLkH6J5RJlnLGqqNtMHQwFIKfbzGLJ6bU3kEESBk//wz6+QbZc1nMUbJAfwT6wxo1Ofmb
lzcOJQBKHyczkauR0CVAIIecUcih2LQl/yXxCfPUK6ELJK1dA62wBnFjFg0EGlBhDlIuwayz
eKHSEptdSs2MMgrLJSyEjAZvAjLJbj4ok2x9JZSno5BoIzak8JJyAoIkjN7AHJ0w8RF+SPO4
oxOU88uq+aGhJLlOTFby/kT3TS2VcRQU4QKTrE4AJYacWDI42+3t7U0651CIWi0PAUcABoPs
oJuI04FyLfUE6niWaLRkvEArVj6uC+joJw5HxTuBo3I32RQdkYvQNlWxXXs+RgR2ry1XXFqL
ketlOQcx+fPQvR5OxKcxKP/TvphbkytUleUt0GBkbfzmjmcZYd/M3IsR0trIlZ9+m7lz+Bt+
hi2Cz4v4d7FxYf/1b+r7BPRk2dHGxo9kCZO/YoeTKdbfBvFjzNS0S4Z1/MdLLbphgirZrPVQ
m97hzNnyGfW19Tc0NmwL8RbtM2gXwLsRnCJnLEUMR5b/eYj3MfgDDNIi11P7rwvQlQka5peU
9zvUHC0KAQ3BEQ4bg3Ds035/MacaBUyuKfp3wF84efACdWYAh4VoiRQuLKwzspbA2A3AoIzf
uP7b1mh4NRFi74moV0snKcwwPbLNT3bfACnuBtnINjA/pJnJ1HIlFypkDpAJHSgbDch9Gze5
jMilbvDshaVH25X9CdZp5tqy3MiIYqh8OhjI4navanaqaAIQNzlxY7Cxcomoiegw2vibPZ9m
BP9tfNs3LyPrxYaB//D+PRHG4QaizT9vPDZwJkTMg8MN+vOj4C0iDAoRFe/NHu/NC+Nxb/6k
vak2KwlkIxPwFjJFTsCrrr//c3aD2SnvxT97D9anj4Nd2pHdwuOO/LlUYeSILFbKR0usrF7p
MtkoYmk1inhPSELNfSSjRFtr3jjMxe21lNw5t4eCEf5j5BJUCynXkzyP1pBItnKWXFnXUCIq
irQ/+NZU9qsA6T6dlmnNv95Qs6UkZ5aEL4buLr2h6pbF5+th/xpkttEI70Rwc0FGt/vbUraf
4ZXixE3zhaLKEb50qJ6sD12hUgJCS3MaudgaWcOJBeoPDHJb1ikzNCN8ryl94exBBi/ILMdZ
jG3RKdzAYt+NQKyMYBe7YDs7mIJ9x7HnQ2ukUCuxyMerxGKJDvlsfo/E5N3D3J4+wuAyEKud
Poxdsvhu0b9K19v4IvC2hEzwG0xdc/FSzB2THmTNFzMXVKnJ1cg+kmnRV/kRICZ8stChZo5C
quOaw/lfU4i6dvYV/JiR7BRE2S4/rOl0ztq9DO4+5ZK/J4Tuaa3zSybALZSz1Cav0GZGPIMa
dKvmfPChfGRjImIa98eoxV/61owU9nKpjZ6IZqnSqDUJ+Vgk2iXihH8P/JXEdskdScCXc9uO
TWXZ2FYvRMI+ZdbbJbVKoT3w1yywG4GavNbhWv6qc7WlE/IWWC45LWd+by+Hywn/Fv3l9LpP
xsr/GnRUlz9lVMAwxOfcJhEEGgoGKbxFEZs6fjWx3R1mgNugOoe4Sagozq9Cxf4hWBA5vCc8
NJZcNy4HsYpf5ff3UJnGf6Svw8Ceme58SIsmfureOW+mk4ndd0X3TfageHtLeiz+vAc/vx5e
WXiz5r2SLg2sGXL9S2s8HN0pxv9T9Jnx/wRvgsM9Hs+n1gBOF9EbXk0nuzEQ8jFyCALeYIsP
YvN/IkiqHAk2Aa827zZFdhqv4yOyqvXxiHw56FrlYjodiZ+EaJxn6VmyP9PouALvlqklzkq1
DrRv48OvXFIrM+dN6j6wjERYxlfByifCyifDuhySC8PYnixQbgrvQLtdNvHRUa3ajS7rEuIJ
Xx8llSSTTvziqCDy+cP87lI3s6UQVh70ObZC5ZR/54+4GOSOIqbzAZCAI8M1optL5G4gsI5k
6B9/4t9t9zpm7S/VOhglp0AXjuTLMZxPYcj4wVQeEroWZrn7FY0wpCW0E9F21nwA7ZbsX3Ae
/fgih4qTdzJU5X6hofVg1t1TGRY6/2J3n+JCS0tifGZZUaHOyEAnN/OdsBVrkG8/SRye3c2H
V9euSJXTAsaRFw3LhXqfRQXky7H4eTzAf/9POoZuA+N7hS2p9bGFfmXSXRA62c/J14nicj4d
H+p6mFsXtn39f1fWCBAaQW4PRx7M3jVoDKDQXM2tMSoPKC8JZ3rpfrbm9pG4my5AZ5jA+TcA
hjwfXiyAJwOD5whJBGE8BQy4w4+LCeI5Dg5tyY4ykL5unnmxINuLixFoU/Vh355I26cF/eNX
51raXqHJCY6iK0chTvCBDtlEj4Q9xFUVuLPoiZEnELIjCTWDhtuU5eLg5zKKWxpGfCdGluu3
3daugT/VgfLsv57OpGUc5qn0qoVjXy5GGYIBtcXbWu8U4yOWmu/F21KnU2r23h+R5Xy6kLYI
8kMDTWkIoGFuc1CX7mD4BKJR7ZRPoU3puFav9d7jLE5qvWa12xUnrY4oCXovVT6rlzqifdZp
t7rVbZAQbTKSEAT9ShNmjvGx8cB2reHI8Wf/HrZYWpqvrU82bHXfBqQagG7XB2RadxdJA8a5
Qm1/OY/wHACVDxQ9dDQV7jS+v9Te3+OMqE362xmxdyB6NiyVjSEU+zYQWXeBIHZ3cxlxPHVc
rNooCZHLG4YBmhawXnHWLXkzI2fZSX+0GNjiZ2DEi9sdVm63r1/FixRWJJVxNPXEIvZHTixa
0pkDWvggsWTmzmGyiUWX/Ymb3NNwiiwmuUiJqcnjGFkXyQVAAJPksQO4yTS5r5lmCEPd2JKX
oD+k7/ESYKb8vC95YMgZlpQ7NxeLy8tIETJzOe7gZ8sZ74AgO505kfpYMIxOHz/ic5ekyrMr
F7XahBJ+9e11HdSqQtHsEhbu0rTm0cUOzESZdALFm8ET63oTy3aeP9SfJ1sPBuqhYQnyGL4c
zh04hy0OskAMHc5ImV5BnqGSz10Nr6qRoxu4rPhXnuND/QGGiVghKmhz5Be+eGyo4LUUs4jX
ingrHveXStwxO+/MX86qZ+TDWzdbTbNX6r6RAEEPBW1u4jrckG2aovqu1ymZGM2+K3bz/ve3
nVJb2hpR3TitV5tiS6BbagH+N/b9msdnJyfVjtnoneGz3+yrsbuAGtjer1NrgsJXOutWzbNm
A4Zklur1jY3cLYh6Ly7hz/Ka+CydKhuGrMx0Gph1eL5xYJFO6U9SvfJptfzGPK71uhsbSUNZ
3oYGqptBkCPAdnTZpI2+DrTJA7s/suby0hl3yPNocYOqiIlGEBMEoUmKL7pREjZlmIzn+HBk
WTs4r2f3bNe/xgsfE3Y1qWEG6wdax6qYWAATCoK8glL6vGIoZO7HBvQugJ+zWH2TWLmTQrSk
aDBejclinCb3Ze9GAO3FKAWNqSF6UtDzgg/7H4+efB3zFSQondqjGUr8cvMckIvouckQOh7w
fZliaJPRHUtCX8cJgksRWkS+jjORIfg3ILh55O7zZOvvT7Y2BmOLJ+0K/JGtdejjw+DmtrMY
ufw4SpToAsARysQGagAc1DAD4NV8YUGeVVDMXZGvD0MQLwWICyYPCBiVg5cMEzfVPKvXMzSe
jHjmD4CeY43tsWO7KQaQETmuR0XSf8gb3Zev3KqkP6wsJaI3Fm3IP5LzsTJHNRyBDC41tm6H
48WYXURwdRaAlenAsUWWNzy5JnN5cnkyPgcbOoSPJA+iGO4dcV4QOKSFUDxWopCFFNDVnwno
qshnydeLSloLl6HnxGIG7MRZ9Pu242REtlprnpfq/PUStA4J60H+6NnUcrYB/xLnwIlgHYmv
iqTZUey5Wh1zBrQEKInIIYEFu8JS8Zw4QKBiiCYUewgVkLJE7xbwc7QzQGo6zvBXLA/CFy/x
ISD53OmGkxZRgAAqMkQ1KqSfQJGsyMPFKc+GExMj0aP5HV+Tpp6Fq2NZhmfC/I99+OTailfi
YE9eZHrffhb7Bb793GD4i4nqAejOBR11RSeem5/EL/xEhLrhCQEv1e5KDsPvL7twBPGzvLmd
xXNMPtqX+L/NhgDS7j1rf+edAL3hJ3aAYzDYCKkAqHLbe9gJmjW0tWA1HWeIGbgGiIRzthlg
C+qPYPMNKNEI3oAOFraEOxVjzluAdpjFaJSR97hjsucgAfmQFP/33oXSwsOeg24wX0wmyJth
OdRCY2HykUyV6HIq6C5Z7XQ4XAD/2XzqHIoTywXdH9S/KZ4tAlvP/DiW0rHUa0J7MbHGzFiT
B0CyxFcPAFuv2/8XH53vjW6+/+33PQ/mtyBfODe6w+AEcMcRO4C7l/QTYCbFJselsNDP3bWG
k9A54GkwD3kOeNy+uVP6DsycxIOEVUmx3IBOkpJjJ/N2jGaRJNqRe+XRn8Xo228k/NmNS0E1
AmCdGxPFG/Ec+AqzzH9d/o9Ui1HsTYwYgN7zgFopEJgiFCP3CObl3CmOM7Mmw36K6LZKFIuW
VAQlwQAms5s9/Iy0GyfYDfgPGCDw0lSsO5Q9TVhAB44TXSkKKFmxpwa0Q3xabBVJqZUSJsuU
+ASW7jEt4M1oXpbu8sK+BWlL+pZDb7wxUtqE31MBBXRLFOH/gE7r870foGo6GDwFl0c7o60t
riAxZ7s/hqV3MXwNoi4onNVm6bhe9a/Nw9Vx3GZ/4iokYp04oEgXpDIdGOqRXJ8SrYZaG2AO
RXb3lyuAc4n380z8I3f7Qi5ywjjwYSZUONIUb70UHFnmS3gai0tz5s4J3QnfUcwfWzPpcIFI
CIuVfYVkzXx/QzH9dWbsN8GkUZVGyTzptBqcayAdXlBm//QzrCkTLa+FZE+yAq5aKkp5SCoS
UFr8wFvYeuMt1ooDjwlHyiJ41AHPx9DRCfQSxK0vEl1NdPOag9AGP2dE3qMrj+5WkXIweEXt
EnsnIxCIJ/Z4RhcXovvmOIOP8OEIwghshDUYcMgfNDe3rvB0GuJRxbcwWFuEpZdlZP7ypchh
WAvF/eKjxt5NPLW5rmJDsTcguLCd2/BMkhYU6eESR2rkcuOu3ZdEEO4Ye50u3G37djaE1QYE
+X14eTmEn7ZE6vRXYHJGjsGBMsxjjIobEkQ6mS0Ep4XvWmgH0W1whd2NXHk8xtdhEca7DFAU
3Tg333ZqvWoqeL/vMRY2XXWqr1OejUOKWEmGJoVeytREstJ3l5bkAn2eW7OZPdfJTj1CTRma
DlH0M2bxXcx8IQplKsQIhCkVAc8+NnTUm48BG1WG+ATcYWOLB0HhUoZPEqVEIPpigC9+5wEy
PABJgcyPo8BrQaAhKfXjBaGb3v53ENZ0Ulp4NyLusf9Ssts/ReyKAI0TOAW2S5J+pfjLS5E+
+u7UxW+hPNMlqKo60jqjmkQKjVLZezImzVIc15oVbVVERtR/ByzXqSTxxdEYmtazLUXx7pvV
j3+qyqA1mgft5CpAmaZXtbLyTCaZm37dTx8Fu1hIwzqacxX4jG4qCqhHPd+LdlDBAbodTwf2
csMuue3QHcHQ6S+mDuL+3L5ajCw4q26FAvCvTiYx+ggswLcSRipSJR0iFSk30icZBUbUTk4w
nDVmBpUioAeWnn/TZSZIxldKsdAhIeKSquPj1FUIxpK2aQ4i6l1jnjUpJaMa21nrrEu51lhs
Er649s8a7jOv9T9CtzrpNYb/3c8jq9+3Z655aTnuzEJDrOYwosBrU2Et0MzrUqRV5XPEnjps
kLUEQhIzilxGAVLRye1CujINBgyFEfYnRwqOV3xy8ZXUAxEmyoqh6xUrCIgu82zcCroV45HC
9wvbHyTW4TfsYSKnRz/h+5iJfWVhkL7vdiGz1IlFc1sT2VndlY2nr+MfWWfguCavyXP4US9a
Tlm2hDp0lgQYB36ZzhxkKFN32p+OUEc36SIR/RXMaxd+Yh5k1tpKp1TXD0odk9CmxIco7C1A
KXXap50KJ/DD+w8ujcwWVVW8qtQDjuqv8ihHC0GJYGG2EAUNOCFmnLRYa/GQ76mTJgV3GtZw
w3Zt30Pg+56Ma4iU8nQMXc4AFUJLJUMyrjenwpnZfXyNcW3NB+QrilEKrpQ/I9DJYAoK34Xd
t/DFvr8keFcz+mzdsVqGFIMvNNRJvHDo8H0oVew/i8ijBBzZVO2dK2swJIExpSKgIRMjWmRT
Q1KAxBBvCOGfra20tF5sUQIjGbQRNItLtDdJBeP0LeGEILJjo0ZIZvww/IhiRCrslwFyBA3k
wxBNgx+jWleCgI9Cy595GeSyZggHj5ZKMDv5gLeZjW9kTpiwg8B46NKRBahm9W/sh7oC2v5z
JUl/FZYLkslWvt47tSxx+9533TxUffTXeOiK6NmW+ryLFlka1SNZkjWuo7uwzQBq7k/oMT+f
TR3iY7CB5K1njfDCg7kJrY+FMUb8zeWvGQaC5i6q6zMpEow+Q6OrIXqqDydyOOwYxq7dEmmY
a0LHnhcSG72ALl019gRjgIdeMWQEAfSCXTDJYBCaUhjjstVmq0n55i+VNS0jcvib5IDfk9VR
8Lugsv0dnEe0prEcs0r+hZRr5fCcIv6K913Ty7DClE6rsEo/MLEEfCeaLVhGDybKQbDrobdH
dD9/pMrxvj9Sjp+8cjyC0bcOpnML3CdWVRV4DTxfvEhV77vfdfiIiYIOl4ZbYWKYPshH5ghQ
OaGh1FN5HXZIpsAcbIiCvVuyGyNXpYOFxTuPI0WA+QXeAD7LVGtcAPXz6L/361EAFpmOzRGt
vLLB95RFHyOze5X9KKcpVHE7Z81mrfk67ZWjcyEtgTIj0lffFwrDcid7SR2tENw3kiXXZVK8
H0R8tZlVuuPFb85yy3CabyvZR0faz1FAYHyiUEoh8Uug6wc6dgA/7G9vb/OOLjd6odwgza5S
6r5hz8eUHJaGptMZ8fqkbeJhVK37BLi8M6kB3OD7q9ha8N0QlylBJE7IdLenWc1wZ7i2viKx
YjbeDHwDIN6vhUwVMXOCvK0mRCTTRhSAsR4AQwsgvx6AvAcgdh1Y7XRYTqhNPsFJM+Czh4+i
pAvB5L2JbOOSmqt2sVI9D+h938mAm7ROYQOuxKDILSURVpAmNe7W6bTHSmsYK8WjOyK4gD8h
HqUJjld+cxTyA0KE8kKQluOIYTjuaK2MxWFtYO8jOhxEbOUBnGi2erVyldGC0OHpgCWfoDjz
NJe/PdT9pfzQPOTJiJB9Ljye3MeIjfuDEfuS/5jQcDdWrRD7svfxT1VZUFoIv6kM3KAqQfcz
ul9izYlOyKX3OrIhgZLKfEDItaTwqrT+TLAQQ+MN+6Jzu9O7pfagXPfnw5k7nTuo/aEPwkS5
mDvqspZPEpCXa51flMYtRyaB0OhikmtMlf//23v3/jSOJWH4b/wpJtl3E7AuBnSxbMfZRYBk
jiWhBeTYJyfv/BCMJNbcDgO2tJs8n/3tuvR1eoaRLTvO+xx2T2zPTFVXd1dXV1VXV2W54D3G
+0wprkKPnc6m+JB1W3JzPMgPA/pddTbtKoe2qwCCMmN8rdC5P+Vc9pPCoYs/FD3ii+WXTF/C
1JlJTOQolkNISXJ2cRpsaAnhmBvLUKY5Qf9n0cyWEvyOqU9qp+cnzbBTO2u0T0vGnoV/NWKy
maLvMI7GvxfWBftDcHI/hrnBlcCGmeBtqZ0Kwv59KIUcaxDW0Z7jxTRONpA2MQS8NacNgu1V
zQgatrphBEzJwGBlb/p2c5UYSFKlBiwRll78weIgvVEZ2/fhRfed1MFO2w0xTfUQb2hBBewX
jxKxx+k4k+LavfNDl7mdhfzJF7dyH8c9yPourHaqUJABjqNCGdeRuET0rQuCJ3yZoPM2+C+w
4Fg38YZTdZr1ZutNk226evv0VKxVT1RVQNcDr67KZa0E1SFUD/cVK6A7Ecm1JpCLYrXsNgMK
TMsF2XzbayaIDgw6L6aTfvwexkMG1opttfcWc6DoTEl5SE2JOUsNObPaF4yFLWPaFVgMK9zy
8RLVPYeMu3wfcgBGk9SNlsoRVmPN0dRgPzP2ARVon4mhW+fgIeW1o+a98Z7b8d10ID0H/i9k
9Jxt+PPbdDC0xXHhZpkX7DrxGBgUHwXeG7JE/fGXSjR6qbPD0tKxMK123FpJ054eKps+dG54
l+O76HFMrWdqllb8qw//0gx1z3Ag8fsM4Memq0XAN5rduuQ3h0sFHGjUodC7+7JlLbO91zll
rG1ln+PJ7aucnpUQmq1o2W5QB/I87VKqus+Z5nix0PvVIUO9QdVCKEeoG6mJu8VQ7KBo1fwp
OZqRoY4porI9NyrSbx3ZthMnxzxp4dBYTSZ3Ko3NIppDghU+SgJdIVjeGjNDkVwSHQ5wwlmH
6mkGd/IHzspaOzPJ9dIx14t4cRr1pxhKzqHxARwCX41uRRNbmJRHFoaTWQwwhOPyDqJ5FykC
0bemOu6ayopVp7XqXXWL1FXXyVx1i6+y6hapq67zEKtu8dmrTgbuf8KqW9MSpCQCzPOF0Itn
q3h8Zwxlj4O8YygU4W2J2xiMQjQsjKvoZV9EYmJxGgEuhtOZn6wVBfrTDyPBbcsZbEoeDYO+
40+dtfa5smlxD9mU4GbFN5LnDMmzyJQ8GetrM6js7exvKom3mRR5dBeFa2ITve7uv7avBixc
O3n5MrjqC5sX589zC44dVZnXeWhJw41PJfDQC0lXkUmL9ESJa4tfqYl47pahJ9ZvosH74MTQ
l8UeAGq0lBGEBguEx5MRRhFqb0UF7g8Zxpxe/kXzcfCDMG6q6k4O3VKGw0M6/9Le8HUnXaY3
QWKBc8V0NL8LdS6BxWNlp0d743rmvezzAr0/34DeDKDe7l/FOhYq0lrruNepnXVPW71PM48x
jxyr0LHSCfCp0Ochhm+I4WC4bARj259i1BEMqNyxaf2na+FYV5kgfvJr2yWFBr7a2DCu33s3
AYH1V/jyN3klEOw9PCLC+6VrYJDZM6yGrS384g/meXWE5jcxvpPHerRTyl3O8qxNYVK1Q53S
RW4J5UoWqsEH/z78Xu2R35v+d1vS6Y00Y8iR7z5zWzV31Zyb6fq91LN9/rFWjiy+DTmCYlr8
+y8gTb6mtw0FR8crTuY6A/hQy5NOtjzJMhI8kqSTkCSFHFJk8QlSZLFOiixSpYhXjiwy5Eiq
xq3SAlyx6t0hk3ob9Hoa4ngpVKDvTUDxaCUUltFUGXxbgeDvmYyZm6SJGFfILD5ZyCSU15xC
Jqk05hEyC6+Q+WIR2ksoxZR2hos3YPEEdzCexWuiFLmeWuyc1OLbRTSO4AItHORy9A6GH97M
xsPYOpo1D2/h3xISkLY6/7WdfRibfQ9KnrWmH8A+1Pmr9/g1LSPe190HvmXZf48D1/TkRvQ+
47gPjusazYc4rsOmcpzXYSillWTvXikT/8UgirI0U9LhCNuGkxOfrp15DGnIpZEaV6fSP6Kv
gQrPfuMndqdf7rwu0cxXOZZTrSZN+y+3W8qg5vQ9k/yG6h6GvAzvmFHif7wx/nM1WkQUi5iM
NoJcElv2NhfPEC1No3XLCCLFt5J7otVESlSSeaXoy8Yg6SGU8sLMj7WZzOr61e0kby6vlEyO
QNDRxVldsGYv7PZqvYsu87tBixsyKXrK0e7frqgtyEB9X1goUa7zD1JQO+YHjIaeUJ00g6C3
gLIIcUROG14vqG5aF/cYcZrP3/JjGzcpn/DixDSNoI9SJsFNMYXXwWi5beQh8rp2xFrK8gz9
pCfj/WUY3wCnwF9LgqqF2F7AGbkRVNb7QNcM0uEKApvMqRaE9RZ3qI3P1OUvHDfbcuJENyuh
c3/ni4jyDtl5XyAEo2aAjuItqu5AIZlQGOsGjtSneuwwS5p1qRVZhFwzC5w4TnCWbO4Tso0+
UQlIlHi9mrnx/1tbQeO0Fsw+TiHfJuWCH8P9bzr+8yda6yUTreGNfhhLfn/U6nR7dCz2u3x2
UuNHHDHgScuGecvGdLMmme/MSXSmvHBWwjOFY1PlL+u1dfYyE7E3fRnvwS91AmtYdZnZy6Rn
vyhhaZjEyLQ7lODVfsFJqYAPfM6AwPYqWncWaSqzE3qmL0Vkr0fG4YagWp7f4TV/riwrc/0J
mG3IboZVSpZY6KuAJ7PXU7hYPLqGj8b9O7BIYb8F3Z3jOYFYLHin+d8vOn56mel5RbnwiC67
4oSzw+ua79ORMwSzhawggoXJ2eZvj7M/U6de0RT00iHnYsMrh4yBRjzGw3O2sIeM/UmWtHLW
IBozYlgGZKvj3o6X/9TswlTDaT3dBlCSgc6nN+y1oV8zeSQ46OoUYCTlQedcM2xGT5JXjwHn
zfKKsyBdAkDnl036StV20vVHoRp+hM1KThHlr1gYdXpwwmWypR/pbiZrncsZwnLqCyj0hVWF
hOzrzFaUtWmC+TJ4LehcyAnVc502aV3uVDropH8roGTqch1NzMQLsRZMIjGVgZiw0WQZDUtJ
jVRfDsVshmoovqxiyhQyv6ddare0RtHNP10x9SeZtZFIzpHrSgWsrNdPsy8KqiK/0ArcBQwh
aFC0ajcg+nozXOCwGE9Hc3wo/rAIvtmEesJhqwG712QuRmYGK3O2CEfDYsmAX1B2lseLpbcv
lAbkhZno4i+sbHNe3OLWFjGd3CThVMFwWeA8ZyclfSkzrHJqUqmqrzsOcJlIbrve7WAbikVH
lFN3MFtB4geqSxQHu/S03qnzG862S8J/4Qh/47naMxI61ot1fFpI8qa6rsp5fhPWaCnwqVQv
qMe8jbY4L6RRQk1aMVwEjpTPJ6R+Xo6WeIrU7lCENyhDjCleTSb9xR18ApsAlDpDCc8LFq4o
x5wkBLTqyN6uOZCG2LXoKrjaKPhBxXYlVNmOocqWIHWtgsoJIr8HzTChYv+gdcewe3F6Wuu8
k4xnzLBtL6hecQLYJE4fZY844im9U4V7dIpJlLZuuBBsLvat0bLIKez9OX1tC64juYN5I4az
RazriLfV5+PoewfKPUK3XztmHKX/tZM1Z4277JMed2REueAYnXWiSMWYhW1LB4NGUI7Msr21
a6ZsgcXNfi+huI3GutrWwhkLjsSCNuaQ9ANcQEkbaivY5b6SSUTpnUi6Zy98EPnG6pY7UUnb
VprXxMutn0G2z8RCe5kjL5QAm99QxuqCtVXw1lZC85iaCTYUZwbSpIR01dyvgo3ncXF1APA/
ACpAAPf8/9/AeawBghjT24gXYgSEXagHIXwFrlNuBJXnorN/lmRCPb7L/+uNPCKme2RLOOAF
+56yMUsSi6vKvkti6dfyb7zBJL5aLLd+fh/dbUPmLvGZ/ga2MD+ySj5klWxkcV7K4sVgLWVx
XsoQmUPZd/ByBURvzy7j2ThSaQDEj5OW6U+Iv/HdFOsgwnEFLFpDGvxKqtJv2zB5uL+FN6Ol
XMk0gZJpkFfF5ne7u2dggD5+J1kf0onBQEH43kFZiTj+bhoJ2zgcxSHeni9qSiVnM2vjd5ez
1cKBxwFcLsfBz8L8Vf3GiAvYHclCOYdcEzI+0924K7Jfem+QM/CdxxVprThM16a6xDTZKNCS
FP0DU9EHvfUz+K1DOoa0EfFKh8QeP71U48FQmKBeD5Jd5E4/3y2VjGEhUQeyEFNdvbQG+bxW
f22KuhcOlMxuZ0O5As16qaWbRjaaC5YYLMA9EIqJs78X02l8Spec7C+Yq2LBCgMZ8CwHlEbG
fubefTIxmyzqoAqCVFbUvOi2FQQ3fbsdY2uZGWsPeM3ulod0JxeOLeppV0P2M6/j0g8DhvU/
8XsufiONdky/Imx5ODSLht9v2l8HNjX0zNAO4PeH+ptXkjiyxHqqBQu7SLRw0Wjx/tlklLGO
DY1BjfWn8fb0ZnvR/+jAeLZZ5biFpfaF1sdnjKZQWqKFMZbsclvcaj3LHGL+8w9H4bPEI4Vh
acOmoBQ91woPb15Yr5Qprl7gR3kUJ5ARD6UD4YcCHxhDKO+x3KXQW6EifdP8SE8gerSBi0J0
EdJaU2cr3mHF4ZMxsqoCoG3dvvjCbkAZoID71ef53tyafIIvIKsbKnfoeaMAKjBzdcATuv8+
juIHzRSZdKpZ3cxM9UocYbmtZEoEzOUZRrfLP93ZRs40cpdLdSTPIa866EoPafoL+6bUwQvW
yqBzl7I+IUlMI1juh61eWVjc4o8DUqXYwRVRZjX2uIAZnNObJeWJLraTYhBDy2oHnidySYzg
0oC33o5xPuEzmPkoh0vnmKdwwjAWElmIe6g6tbzpT+HSsxnXCCdSEraHmV/Fi49YY9DBAxH3
ZXIQ6bIkEhRPztXRC3qj4kFf/G3x5LqP7n4SbpuMG3BIWPRPgYhguiiK8+PNDPJfQw4dSeCT
5NgaNKqBTboPkg42vRl4UUmbVa+3shpvd8QboKVOaHwj4wDBuRQSk8sxoiPIGzVy8rjQ08mM
G9oy7NlS4kiBQ48LnNO/tUjovj7UJECOJKnUCYbLd7mDt65H1rFXhlRR2xsN4pfe1owMNmpr
OqVCUDLGjF8rX9H16DpRvzBO7IiQRWYL/8uTW4SlAPHJJTcGKhwN822eP7qJAy1Mi+g6Fn9s
BbKhL5oJ15ML1xhLzEGKMaxcFRF7qYKl5uD6h0sJ8N9PrLiDGHFH3KnaOy8svM3kZizX41fZ
jb/RzZE2vw54czWD06DJo7FYX6w0RpQpPH0Tdpq1Rtio9Wr540JVaIaNFLc2lWbRnSy5TeZu
UgeUsmBzCACLLqUtI+8FhoPSVdab/nD2UcwtJm6xh4eduGtLnNn9fWkkZUFLIRQD0H3hfkgq
h/9j6CUeBlFnMhrQWV9yNGCniLHPII36etMZZV/QvDMbDIQcEis7uh0tVbFhzKY3laFXuM2v
8DaGkJ1Nk/Nm/bHQmODNJIJ421E8cSruOXwI7sBySZ0iOvNIb61aBWasGJFHGYswL//VaJAM
gl4wcXrGL+8CoYdMZx/H0VDVC4Qd6oOwvPGQTBP9CVHTyOn/x+qOf8VgJ7+jTgLQp8dZk9rw
f5IGC62DNC1YXkm7utIlS5F6I5JJqT+TGeXsngZQ4YA0ORkQ1JbWHJQ/+HGpqt2xdWmdE6ab
ZxjgkOwDl2KUxz2Gkmvl+Eajkx2vwWUktvdoUweBw2Wi+abSVAV9gjyldtFpMZfOFp9SAWwo
iACJPoUhO4FLExJ6FMfCwhALYEDqszxF01kb5OFTfCc4bgKpQJaL2Vil1YOaLxj3zvW2r6KP
Kmx7EdGNMz5gVT2lQNIla+cUOCbIE03ySRZE1UhQVSFQouCgHi5Ww8E3KkjNTZcevAgOL3rc
CYkC7u6BgjuaiK6Cqktp2tEQAI4Q2J6o4oTUkVWse6FV2rSYXW2Ggzgwb+YH5oV69Rl7z3Gn
9UfB/ZwRQGvGxkovDbCFGx1re2t8ux6uoqdiEQ0FOsGgndtDuuJAEgukaee2E5EXmq08Gg5L
3VjOlv1xqM4npbUB+/utrKfJiMU42+jOF6PZYrR0jF8vtWD5VsnyregBcBrf0AfV6SFKuFy5
2OgfRCqLAypjqnnOOXTFQAIjYHATEt1CSQnYmDFbKuMxrmrIUEJYSiC8cK3KyuTLm8iTtkIH
KOQpX2okdYNLgkbTs6mzqTxUKVOrkGmBFgSm1fCXyN0Mflj+MxyBa3LUl9mdJ/2FsGdviq3T
02ajVes1w8NXJUOjyM6tJtncUA/+IL3p/NU7++LMcL1DpbJPfFVVe7atT9tJGHnMvflAfOP9
SalB1ucGyQiMX5sdxI5EyJAh2flBDGWmiwGmwIB6L3HHY1tdK7iezYaqNuzsilDIfEJqsZGz
BaxIwzezGXBJWNwdhWI8paJBgAE3m8FsMqH7r1u09mKbLFYO9cZJgUPzWRyP2PN7jVWaIQWG
lFYRu7h4bREKKkUCmypd8B3Fm7y5ciYmYyxgV2FRsEnQAt8NFh65o0pMEDEtuFlrcCkrNVce
ELFFKPGmnfUvvvg9L1WRQvkhaAOIk24FvWkb0W8P6dBPbxHvy8s2H9YZwbdUU33b3sFKeha0
hw9+/7rHqiljv1yKU/2L+eioRutsuDIK8naUYWZd7hc0wTMxqMR2YotY3XJkeYK/2Rv2Narz
wiyH2BFfrzAhg6dIlMzzf/pmC2GCSvlJpYz/KwdNKd4b2Gl2xtqRZabsKj9KpqrG9KzeKvTO
nS7SGM3KT0TTftnZdsvSKWwU60unqZJGU+Uhaarci6ZqGk3Vh6Sp6qHpq9RAGAjLfLqa/8XX
E3qUnQVl98xcU1gxSe30w1mAys13Qvv4kU6n+mLKJrMPePpM4PpODf2bWMCzdmES+RNwfxX9
1JDGdtpuXJw0wxOxqM+6zeL3x+cnyAT8vHbRe9XuFL/v9C+j6CZ4fSP0n7tNyJnZvwpeza6u
hG5F3onT/lLMxsegcdNfTEwUEADcaZ33Wu2z4vdKQtA04uHFaX/xIRLaEXP890TYAzHaY+C1
B0P10LgCPKaMI2ENglG5WErfyHj2MRhHYljkQLFrAx2V9hHPNmgE33AfH+qH+tSjh1RX9Y/P
15APxfo7Hl334SxNcat2fCVmRokXg8+fGwdgdC8NzuTBhytW3sCc3dp5C2tEpDZN1RB1+2w0
JSisawqZYwA1w3HB2EopaM8jKksYB8XRdrQtvcuj5SbdOoQDdSggFC0HP5a2Ca5aChpgcF4B
3QYY2Ceb6kaaCdHsD26SNFJbsR7NYfBh1A8sHZbgSXNkZNhhGQwlb79gFmKVmpjr9gppMqG/
C0vqI8iUPnedxwRVfridigY0XAaBa4BgyoF/RI2NsjsKhe5qDmSLz46iPpxtxs+pHmWhsEVT
kViq4lm7K5oaRnMxQNFUGLqchZkOFGTNNcISyDq2MqUF5UWzKu2w2QsuIemQHQhq0VSWOCA4
Atvf1tRFNEzAgJCKDe87Ynkf9q8J4d2/hsRhazqkGFfer+yPwUmHzAsmM1myZn8ET9NwRlnL
ymBacJdJBGJaP0TTEThpP/bvFHFd9NimsJWaPKAqH8hQ8bQJojkdpsBCG8TEDAF4/GRSAGNA
dLP8HVYetlNxAbNdRhBLAliQYad8axQgmziSQZ8u0YKPWzDxldh0g0andhpc9qfvY/a5Myd3
4TkxlRy/eC6M2ljhBBcYIwRIXn1Wp8+RWn6hLiPay8v8/ghyIcjvZ8AjF1OsFkmqgKwdiSUc
LCySKmXO0j+VWMKRf66XX0tm/aW385t+HBlSAf8NLp453AFgq96C4H0zXcYwBRe4UAwJIkah
v6B8Gjw4xliAp4YukcVSRM/BdQ0PoV6XzPCmpKtBEbsst81O0vql3vSndwTXu33SuRUztxx9
gNUmPrjpj9Hlddo6lNEvLN9ARIB6h2eeOOFcOANEJ7ivBoMZ9QZc1jGGMC36k2hJGYwYieI6
ZLY0NjP5iwDJ3OO86VZv6b1X/K2XexynRTg8ws+SekJ2rWK67CeFnvIKLWfcQU/hS5uKmDph
UAGIZ5LpGE6NnT4egsNYdN/fUkao2/TRYAbAwzUxKeSQGqyElHSHBHyakCoHKrCCgASCJ4RE
9L6PTfCCAv/l8+C8f6cqu0PA2pQSB4AYGV1PMa4LD/1i4/CbNYyEqHqiBsDmT6SRJhwTBBC8
uXR4mmzflLwspZZVBDqCCtsVwyI7Y/EUZSpILPn5IhKTwNF1tliHSdWzIJcPD1MLQ5BilhSa
ZOzJMJNyMYqyq1bR6A/9BbmpoXF1OG/2RO4oz9VqkGediwijGQeYceCJykfAwwu8NYQjSQpS
kJG061QkcK6upqMrzAlEzyj/JJwo6ZEx1B1zfMWOay0iWIHGQgKZd9WfjMaj/oIwTqMRjD+j
uBUAOP7mmlKBYbGiV3YSYsec1UeLCnUTCkW8vENt6tYAxxLe9EwpueQJhpGSfnoSJ9h5rIw9
HMHqZ1kQdH9xHPo8Pz/yCfGP5rBgY+RBjqUDWZ4k9z/0R2PctxU+YELR7nZwxAnKCoXoto/K
CGRgvQ34Nj4fiCNyzDaCLegsnEoUMBKqNc5pSeb9mLumJgzzj5k7kNTOzV0Hd5yeomEzLxEe
EqjinWQuRYaZUwimwDiwYQp+hFn5MVAaQOogG2OALcsi05yeBDV3FiBy1mnUveO9yWuJRfWl
ecDNq1Poedg7IT9BQsGXl/Y5OKA0e0iUsqGhyaXjBtwZqLcoSXteWqjipgXOnjekZSKkxPhO
PvIOM0yAnKBInXrJo8irQF4iVkHN3CmDStUJnhycju3gTNgCC/FujDTT8RjUlZ2CFGR9gliI
mYzJmHEiW2zZQsmt4J3+HxPzz1p2DEPVpbjrrWOMu96G7Lg2e1BegMTg4fbIwwOrZIKH7uKp
inFRu5vBK6xpUOK0YDIaQrojAdRdCUaQCQkgJ+8HiKiBPd4+EASCDBnC3cXzQ9opxhSkwj03
hZIM2mEJJjmaGQ4+XNIpVcQxQWIuE6nLaJeWEU1y/+Fr81rgP9dC2E15QWYO02uwl94nQZJv
sspL8oc1H6xTu9gkSaAiJUxgtb+5crYLWcb07Mn9qKXcYcjtYrDnkGH6coTWJ8oAXg+o7PFU
XAqqFQfyOnfUTIAlm5Vl5CrW+iSh2ZZjhy10jKkGlVNvyksexIW6a4FB+dJY4pGWE5Q5BeBO
Mc3M2OF+DrKSp9hSqUWwvs6J0J8Cx6BRlmR2XGaUOAgYjjDAZoXamClPdBa4azGRUznLOBMg
WcCVDj54LXN6t4mtXBeOMSUP3bkgw+xHSBLBMgBMdPl9rDN+mlQ5ck3oOOMh9UpL7/44hg8F
pwyJa5aL0cCx6WTyVqkWx9oKgsTkpp6CPcZiWMxu9sqnU/9oGq9kJnUjpWihAJbiZeTcJ7HZ
T9sKpM8owWlw0GG71mkEJ7V37YueITA57hzvsWxdzkTntoPgbBb892oCPorhqH8tLBVU4yLY
cvqLOwMphGB2zmonAUb7HNXqTeXMpN+5z6b1m7OajfFUoqSYBZui8ZNy5Wom7LCPgA/nD3JY
wUz5tG7Tk6pOhM0f2u22AUAXG7ZdSFkf8tf93woKchhdjaac0tUsVZ6AJvvfadfjGUAZnwIN
IUawWD3gAb/yg8fDSd+iQIOj6ORXKcDRQkxXKL01JjC9Uo6cBLwVImD1XCzz/hIlxlDqukbs
sn0bRC6m4GF+rm894aTsI6MJcS4mty8kIPUrNlkJ2YwPWt/UTi6aBv4GQ6VNbgoajmdW2Cw0
PLs5sMF8eiiT2IAT7PlKIGh2WrUTQNHrtE8UDosc37wbu5UxqtpHmtz21M1ONjJpe5KSOGGD
2na5tj55K5Q5agrk9jJ2bJbVOgcW89N4dxQObt4XCvXzC9CpP4zAm9+rn1MsXryakHJntoZ7
D8PzVcZCskV7l+HPOdGo53NLk5b+d+MGHkNIJYb2Dd5MDP1ISeaH/T3BzPrq4ITO0cQTEn30
APIOkCChjgtZuZjxlRL6jvIfUV5XGZysEqaVgn8Iuu8bnqagITwNiDKbarS6X6itYiX46acA
b8t6eycDa4sLjuffDKy271k9J9GyRJskQPb5S1NQPAg2DDKIDqGPlTU59YtOJ+wcNcLjZq84
D0FTx0vENPpF+9HLYB6q7X+wXIy5/Ir6JPyn1VeFvOtFvhYZXL4zwSzkF91mw6AczE6HcuNR
GuXqE4dyhbzrIBe4U+g2UBHdGghRO8PS+5wxX64Z8959xnx5zzHvfc6YL9eMec8z5lmUZ4+6
DhOXjZy0zl6HF+dhr3XaFCp2oQDxbGVjQZy/ehceXnTfqS/oA/gExSccLIwN6QpnMMrRb17N
azTCOujwZtSQjoa8uQuhWoZUhbVWjaHhMvocc2cZ4e5GRJ+F6joNlQyx0ZozngBaBDPSy5nQ
EBTsinToFAL1zRcVSzq46QvtcBBOR5fC3qEuzOaw3RENa4YlvBSK6/yuaMWmxgtZ6d16PIyX
9NiIfhuh+xg0C1Ac7CsCDx1FAvE8lhUUbAUt+6zAOYDmABKEtMNH7OgRmdXYOvWwg/cwwTYG
EIEty4ceBqJKKajzMakPXB3ocJSFZeJxMmT4UCOEH7WoXcvyXbUEF3so6bKqJYX3uv65Gok1
CE5z8mXpoP9AtDERWpHgt6WBaqckz8RRQVlzMK6iPuyDSwPfbgkvWk7R2MPEfegViTjsRftL
l3jGQF/grbsp3LScGqj2SkEXVo4+bQXHlXxLB3J1INP0jQbqnFj7fcxRRP2YfAoxZSfXKFGB
JGNG+kbwEVvRgmibv6R+r46KkNFaZ+cXPYMzbLO78NgRqPKrDMyMWEhFG3M30u570m/xu06z
d9ExmfxsRtzzkIFn+HuSlCfaReGEzru7kox9TmwvhjfgZdKQfLEGRvoAXqYajxQxLT0TxTA8
hA/OGq3aWSkVuekheJliSdJtKgv1SavXEwrnQ2CnjLEwqIcnp6DCnrXD7i+1c04HCw976qG+
2PVv5DlvT1EGOBTBpRiz/6omPffgOyNQOYVy2/nxMt1GpusEfixSVw6lfcSXGv1fL/1f+75H
rzEZhJALJ+AK2F7cy9RvHyWqbfkJ08W2rJWAnjESdHkAtXqRo62HjBlXP2ujJem5xTfOkpus
EQCwbp/VIvqewQXmPrtt7vk9+lRA1PmsuKHdBud8HUm53ymkjPzy5jarfMg68gA8/toD8SOH
rRTJOYOTRFO7NErABzbWK3KNAH0GgFkznntbMjZ2q3cIqv3YZrSs4ebCcbu8Cz4uRks+e7EJ
kYFSP8YOJEWryet7OrBC6QZZ1KC6YDcrH/8YSwru1x5dB+ZoM/aCQUK4ZTTnyCNbqSKXSn9K
elJs95yj/5LcNEKH6WNXk8CQWv0x8YrFAhgmJCWkySqkchhtWx59U8EswkFYGvsww8gbjIIO
jTGbgxim9PVVkETsMVy6vTMLaZjhCakaCkpaeWSFqEDr4+iY1dzgEUFNpJMCfmGtxrbNkMty
qjUY32EY+Copn/Ms6+JzwWsEeu1768qeMDtrGDaCwT1i1xdMVe91zuGvdNZIzI23Xk0ifaht
L8WLtEwnQvUAD0jzTDoHYRsIz3udsFw0qeesJ2Zt4R9SXAyquPCvJg2/lUqllG7CLtBp+Lu5
WNPNRb5udh64m2YN5V8Xqd0cDnFhqGAgtepkFCoLX5by6inlTX9iKiTsYAgzNQvD0eD/Rp71
uVPhO9QxpP52Rq4cU103varGcGbp/UzJWtRGWpx7tsCWxdqGHOX3Xi3Z6rRuqtvsASJMBfWJ
LaI04S8Ritzx/hk0Tj3lNKbPnGmq3K+32uzRZLA3Asno3GZxzHqP/FoKXMNDk6HyGumsQM5K
stJL2H5EX4oJvmKakmPikUpcZVodMv5G7HlfRdc3hEOw5fjGujJoCSZG3UZQp/k+3Z+POv0o
lAyzowJs/SVlC4TfuRWK8LiAjlCl9s6xI4VCTQtIDnpJaDKFrk1EIO+mQIU9Q0/luJc+JJJJ
+GtLhq7Wm6lIjBWPE0liFcM5h8o4C+ds0tGMCmdPal/VaWPuDBnu54Lje35MQ816j1N2bBDe
JLQceDom/sa/0vkBRo7s/kZHh8Hv6tEe1fhAVMaXZfyyumt+WsFnlf2SKocp31STeHfwUTlL
mgueCGuNRic8af/iiBTqRHrRawX6qnX8ygd7Y8jdwSCaC8sXrjzEKkpOMqN393bEjRqqzaBW
rzcxqRC1bxWe/poiJFt8rGzxQcsjRYbYaOh+SWyuIqH9Le6kv/bCWnBXKmb0cYGDZwQTwlqn
4xIqBgl+dPDqEz6wD+3rPKpxQKOvpmQIq0JCWiXEVcoBTqEgewBUSumFSY/pA3SBoykhliId
9FADZbE6xPdi84HiLHC1PXLFqiHz7FEV3z0hkNiUhFFsl3B05w0Q4UBvB0nxhYYaBM5RVgAs
ygDXQbH3yt7jHujLUhiljHVbvqpt95Dnbh5JyAMH+35CHi4vx+Hs6kqwYeIVqAnqFUmLk9lA
hnzbvE7LAMWFIgsEZvn2SmgZ6hHKLN0kfKE/fwLHN4+D3ReULZavKfKXVL7VavMSjpbIvlKU
Cowa4b8zriYSxx8YN836l8Cm6kIkne4WYvHF4CYo8nhiBg48xeo0/9asa+n2XKYGw8yefZSj
MQlSrE/XXwZ61UvKG7XkgBWM+UnJQMt7nyXlGzVIDtdrdsKLs1YdirH1ML7ksNZt8veBLfyD
DWO6pYVntf4DTlm5yXEkjw0eUN+rLYf48n40ZZO0abIq5bS6FIrue2oZJ8HZYuQkdOkWZHIK
jIG/Go0xP9Q3PP6/0/hXvpXxd2aAQy6fe+wFs0rIV7MYnPMNse3zYhyPcYLh8rXam+ubQfe0
jptu+1SeDmceGxyDX2MxWwlFnA56I5eN4qDIclAg55uZ+n70D5Rx1lDO1buS3PzpbIC4Uez2
5Yx9nRyx5s5ux3fw/o4Hs3onmUKgZJoDVdMK5EiRbpe9/u9oQBe7vqHjXfNQyx8CYzhC4bMQ
w++1fY1soifT3liKzdtweHTRK5F8AD2uaGDBEz8TLdQxL9/W7WcbL8V29kXWq26ktKlsiJxE
HvmoVFmV3WGRl40nik3MAeqeyhHK2cfuebMODqDTi5PeZ/TWSyrlCvYT2vYQmkJiu/dK/Pdz
CfzjCws/zAUQTkaXocwTYIk+O4FA7vgjxBonMNBtO3/mcvP4DA9ftMpuoKBrPxSCQ9cXVxxK
/RVFHR3vAY2YAsDp5KZJWEy0xqkyz+ybvFbxVQRgcuLXir9RQq8friaTOyUKz/mkEp/i+LDd
ZfGAFoQjIVnQydA6DI/b7UbYrveava70hzbAX/GCPSDBKPhJfXwCaX/r7ZOTVldw4QvxTolI
aju/6gXo6u0LuNfUzda3RiWvEyIZmfiFlqoV+AlxDLwE7KNkM8gsfyBDvA6X7UigUynjiFpa
vcl1aC7Eh16HMqhOeheUoYf+SSLS7EOCzD9TA7l/HK/HHLezSytn/Mv0oiMQnowOvU7zuOSA
Ycrn8m3lCG2GveCxLQi4vBF/DPaFJC39+9QDJoOMzcA5XjAX2JeMwg2cdXWN6+o4x7rKkclN
Lq0F5zFe3sgLsjkQy/UTPNQCkpkt5RIKHI6XmTTlgtBXxTzkPezvyaeEpX+5tYBmZ7Go4H/+
2cfaeN5VufqCkWsuc5LOs0Xx0k64iujI/ZhS/FeFmndPW0ZObUqYkbYEti2EKllI8LEPfmex
wY/ItjXOGvvXfUxfRM/EA7ipP5pEAtLL71+W3Xvehb2IptFHdJ0DkVnLwVguDzzjSYeuGz+Z
eyXA8IZifAXv75XXBec84opacs5hPHKfD5d9JQisc+HfX2Jl83L5hfStgTetsmczWrJRiMaL
0lv1HEqDAjoTujgVGkSUcFmH8A5nZJl+xqE3nnrLod3aMqoR+vxXXF0z5ZT8K56Km6IrQ4ak
i4+Cs52p6xqDm9EcS0tdCnhKhnZHARfR9BpvKMiMdJwygZYQGh7yarBpGdD1Ck5CQrkjMOuB
zImxgpsy4EgaTY273SNIvUJ3ROg2hFXMAdKckFUCkbCMUYb4DUcxFlb4E+RQ/Qayb4w9Sfty
Sp8vtwvbLrJ7ip6EYOkuZ3NMZWSFWHNUCj40c6/pMxjaux+tqdqX4yKvqYrCCrbW4tGR9li1
qMgV0Cu5B6xUpA1LssKEcR3YjII46SSxQ8s5RNcE0WVjFjaCoF/EpkokQEUQI8EjBMlFi8lo
Cqk/mBYp4HTID0WwWaURKXcQo7Pqb1ERMS4fYo1/0o5WD+/VbwRI2hNUSImlpTs3LEwNTupk
cVLnMzgpNQbLN2tfkZ3uRVdubuo8LDd1Hpyb1nT7s5jJ9NsnPJRKC/H4x6wGPaoTR/yBgsMn
RXUr8rBjHg/fgzdTYiN9I2DZ8v5AydRYn3whmFnG+pe2g8RAyxhWOOIkH5g+GYdClnhR1Bp1
ya75LCTlwkY1J4nbY8YbKFJaDr6ggkENW5uw+FEGuSDYqSI76oQ9fn2kd0M+QLOXhMLI/ruw
km3ZXdWoksOd0GO+qhrj45zssEB3OHEgfMoOigmFVF+YM1g039pOizmmsr82RmFQIUHZyzg7
itlG+Scs5Gt3IUunmyfsXjLU/Zav6Xbz49NZFvWaNtC5h1Nf20JY65hLHylnuT/sT68wdy34
pja/5ZBnMeVbRok62mnqAtvfiZYfttad+rm2uHZAoEneH7IviuO0H86hh//oD5Y6bhsvpVns
rvKLy+uGJi14lvcl10Dg3cXYdRIENjHyOIcijbbT4R/LXbBjL3lKw5WxHQa/gPfJTsXaN5QB
ixysL8WpLx3EyVVr3Q/kq4GXq/gumNEgUx41vi84wtRvI0ovZuXbS1we/LIr3Q4xtVxn2Tup
z/Hof/k4dZcFfVPteGl+TjfrjrymKE+o+Fq9PK96mTxn8Cv3lDV4gCaQUfQTZgenzXIuKkqz
JJVYnfK8we9SZMvLdSqqkpyGeUON/RBIvDACmnaLyDRtgckhvcA60MP7B4H0X+IthUqJkzQA
VPu83m40sZfcZtZ8FDC1nJXjBj6HqGpIjM/HBEzpNzOg2OKb2kmroYdVGdKYsgaWq05gzbox
SGArFphjqvT4QECV/NdPydFSLzc2jEPa+wyFAHksvzd7Vr69Er8/yf9sOfXFpsdidvZNbXxI
ZJyg6stvf5+5+6WZgB2/Vpjc9fSmR7sZIeAbuf7NL2OrS9vpDIr/1F3MPmBaYxBm7mM5rcV/
7WMPsY9l72K5djDc6pxdDFHCx7actOyEryEnvbkxtiApDFYS6NyC51gIMLz+j3k8dAUiLEWA
dYfu6epSaWx0A7KYECZH1qnaMZ87ZVk3sKkyTLLyUKCLDllhAjLnCFYAkNnL0OQ3sKWkDcd+
UkEDhLBTytnJno0UM+Z5JBb0gRzAgpuMq2GQI46zxRlVegyElJdOOcbiOyH6JlzfEJLKlbad
AVWVg3w+Qk6d9yPkVFhRXQzBofFIDMqPqrdF9MbpTPolKvPuFH5gjLi7SRy6Y5k7FmX9gMzd
iRQq9tZVl+lTBLWyCpqcKLy7J1lVJ1w/w92OM1kY7OMDBd4JIZM+vejC3whQJ8f372+yXbi7
RUverSbERbggJwXd8IKvMnZMSY6NkRdXOrJ0l6pSUlA79KWJspPT0EyalTAsvyqXJFi6pSqs
Ymh5t2Ta49OGi/cGLHsAK9WI/tT47EUmw7qN8n1/6jbvE6Xrkt4YLmBOciNZO/lGca7Pbzye
QXUpl0OzvrQ5jxWID7Ox6NOYlMbOW8zSAkQzZkuTQETEBFJVoKjt2xd0kNdXgeZsZhkfg5Xg
0sC6hmwMblgaZASPS8kO6kMx4s/glCX+7skviplYcCrOCzl+99ed5+XfXkKq3BKfQ+IBa2JR
4nleSqIJatqshzoeTUZcSmN/9zXmeKX1ciq4YyJkFgofwe8H/E43XbTkE927/z2wn/4ciPE4
vDg6grsetbdht/X3ZloWDJs4uRnu727hBUManW2WoUki9ABsWOxHsYhP09t0zO5OsvqKGZPP
133Enz+Z/A9PhDHKReQlT/w6uv1tG/Ld41i8tOh64fmSU/dDE7cw0Z5vONm+DuHHpJA0wO1f
zpqN8PBdCPLmd7koOB071ibpXJz3PEin0e2SujJfAq+7+Yz0txuV3/gsOdlJgrWXGJ6WQ/YX
KIsYfoSaQkLsfCgWrXVZUsg2kd9mV+ZSUg06mV0ESPz+EpoXzZ5dnJzQNVZj1W4kh1zFS9TH
M0zylzrfuoPGPG9V8o9WmYfqQfrPQR5QMUsKD66TgHXvzbTD25L+5HjZicj9uTcTudbTkm7a
aa1yyj9vewqJsVCU0vTYNyRpJPmS/cCZYOWru3S8qf+0qdL70qZK71+myr9MlXuZKsuEpWKY
Kr1MU2VpSNmCYaf01tspy6Sd0strp/wZpkXvX6aF/Us3LZafblosvaaFrcwnOIesgkeUULMn
9yGVZHK9xi+e9R5MM08y9hrNPO5z5WryRrp7PF4QUZ56TBVk1E7iLX9pGyM9vRknyFHtOrUV
POUH0xTgZaoCvMyh1prfcA2qrE+U5sufpHy2TjtbenXZpVeXdRrKocjZLfxWsvS5XrY+u/Tp
swl9NXV6dMPL++mry/vrqyaY3RonoUzpNWux0VKtM8ngoAnlUWIT1XT8SmyidE3ZYndVK5L2
E0gQAuxv1KP3t24nrHVWWcoi8xKX0HiXaRpvz9J4jSyxnOV8xjfKYpkCmEONZYI53OxSegN/
TWTZ/1O0Zc68DBUdIGwVandMjQ0bFdVUVbjgXNbGOq60y7KKSyvmkorszsP5+yVWQdU3nqEg
st43VeFYVWwUeMWshQzlYbOqw0am/uDoIlzTGMZaFjCWJUuta+RLXbPVIC26xjzIds1ypTy3
uA6MASshQK2F1jYNbPCZRQPdSsSiqYALriwBPkraYBVjVh8OTU2ydWXSgxWbMQAoWeN5tOQ8
x7GNt28q7Ewba+Uf+6RG6zwagknwepVRDdwqTq0xmTJzrkp+fznFuqCqOkqPFbId1jHkJxdG
6fGMmKuClFVZfLOI7Nnwq6HQM7oycCS2F7NoUGJ+ttVQNDuddkd9a84uDD/qqmRzSZGO1qIC
p/agOnHYaXbbF516UyrCamFIIwuVGoOUbZv09uuvqMxCg0cXZ3VBdS/s9mq9i64tqHJqtAVd
3/NxoHnAzh+Poh+m94XzDDaxF66nW+43ARf+DjVzJw7PWaqHVJBJbSKNGc6cXDO6dLLFEfDI
WbZKvV1fV+Ul7hymvmvznyJGRjeLJhuSgRRry+z1aojyZa83BzAFwlAQACI5mAIuV9J6Rdpv
xs0nHzpS69wRwQVGgPZsId2SYbZ+lgoweXb/3uy0w/Nao9E6O+ZHx82zsN6pIyoxrG/fvg1a
MVemoADKcfAf34n/o0EVnxyyvwfNCtjc7sazvlCGJliDHkIhpsrxL10+0hoCZ4vAIriaXfSX
wpgaQmXs4Bdc0zin0rQdU0bXoax+oYdlm5BwRXX8ehQH8nPBkT08QQjbR0eQHr11RiZNIskk
o7FQm+yqB1IZJD+9hEMLMlkE0y3fF183O2cwIdK7Ln7fv5utghuwza76ozGRBD37SY2M4HaI
c9sS++vtJPrH9HtS8D1TjJEdSc4QJCmbwyKUnvq50+iHA8WP03RPMDIsrqXDhCJ7QuL36Mt5
XDJxGlV4iVMnl0VboVcGKTET+CVmH6eCueAaNN41Bj1/sZovuboMT46vY9rUcxaETPicfejR
8x56qNqsQPHReBXfoAdxPppzblOf3ZOkLt2i4yHRKVlQW5/Px3ekk0oFGxtDrnDKAK8rGgV0
j6YjQTioO6TABBcUWmn4DLK2da84LVr/3oAah/8eyPghSR0e3Sk6uFW8PsIVmRxnRJDDdnN2
vkdGRn4UWGofQEV73J/LtWeqGkmPC3XrpbWJKs/Eul1LmjueTctSYrRxbnzXfv3FDSUkGBcj
jsBWcLSIIryoiVtd0k+bw2QybwMpkydSBwSmW5QNDvT7m8Eiwn5SapxtUYC7m+wpPW2yZjcx
al81aijsrrWVZm4F8RJy3o2mUpkxiTKUVlXr6SNWtQy+txfG9+AQHo6gj5vBR6FkIpT4L6jW
GuNUbHofxDaAN1mN1cVp7Yz7VSoPhLMAr8b967+W2cGziXYH8Ng9zI7PNCC06i9wdt6ZOBYY
lMB8I+zI2dRlARaxDaE4hH9rH7pGBxSDE23fsLG9iMZRP/4mLQ57xec2O/CX1/aAed1MWCI+
q8NwqCvrJI/F8W0o+Tbt91LwAeA3vRODdt3tTyFFAMUNG6qm3canaP0mBqUPaX0LRZ7pnNre
NnRdB98P5KX06Esl2hWDIFeIgsUr+lAm1cFtdBaXr+XOxnQVctEFtUuI7xbLUO7zpmJhCVz3
yANjgNzxNjmpFPzwwyNVJmS9zYpnMmpgvvzQaAlljc95n0+x1+3B0rebtBNd7fmF852h06cs
HtNSQPbPY1Lgh/oEI6EvwnGEOY2G8E33+VvOfLRWrDnPpbPWpne0ZePYDyBl+TiWMsnZpXnp
fJq3434lZ+/PYGl89dV1Ub7vSAUg6ZY6/2toMSxmue3c6o3dH9GSrpQqrPJCmaGDgredtIHp
jHQg/AjK3cMWM1yRG4uxQukXqsQU1FBt1FRiVUtoMxoSHqoCaxzBetYiG83sjlc5mSVtqZ7x
6PamvxKrtNBx/GzY4Wma5mgGbcQQRrIdZGbP+FaUSdlLJdOFMokr9wupkp0MXzT5vq+C5MgD
ETwxnGnMr0QqdrP48lvUHc0V6mqOhqKYoUOu0yDdSqf8DA+dfS+UJF+vOPrjuwtmfLfXm91J
erPduV7rzU5UFL+3N7tjKrp4duMzoT6xaqk5kCkQtub7yA5Vv2+VUtU7ONq8mo3Hs48oG/WB
OS5gPpLESBZOAM85ztmzSy6/pL7LTSdV3TPTREM2/ixV96GCkdcocF5vM1a1Ux2Vj0uQ3cL0
cLtqWl51TruQrWboKWRoz2xljTLIsdYWU7godAyP0z7HXss4lqgvtzf2Aokmr0bReEh3kocj
rnzVX5oKsCreLs8uoIyZOgBfzeFQd9y/A1bM+UuNkk70NEWblZsZH4hPSTshjWC10BWJbVkI
E2QteEd57TjKa45Abp+8fWReNJEn33pzU/nxUyQjKhvmLRO3Ey8tYe7XexNCVDpX86q9axci
+9y/st67UB4Z0HkwPQ3pqn3jRhz0SrLnWt3Xr/quQwdeV/HtYhR9YNer4akEM4s3G8Pagi2o
v1zCwA+NVRip0HNYg8sUH6rklYdzoXa+PReq4zhLVX1bhhUwm/rG0q8Kn0Uf/QMAQ2qtV4dn
Hk4Z/saUVHs5PayDEyWU1BcxPwkx5kxuP+YEoLxLu1RoYXpkKHu8yDpJ55QJkktLK9jN5FLU
TIDf1MUY82mO42UfAEcm5j5a5p3ToseBTxwjq6NYYF/MOWEcyFpnzB0ORoSsMpbzyD5p5k3d
7o15aU5y/n3vzJnEOvJ0/TFyYmMz6Vu7u1HTpzMOD0ct2yDBcFD4/Gupak7Sp2bx3hq1RPvU
Ol6fWuf+PrUsmyuHbpEsqG6rA1++EJEdy4o30Qaz/pgysULW9f5YjCyZpjIYYhJBsuNRPIFN
pPNWqLvLm9yRrrw/CrA1uM3aPhKNVYy3L6tOyDsRm6SB479wt9/fDcTYj98jgsHNavo+Dl7Q
Rx/RY8XwQheBGrkDoSsC2kk/fo87nSILEdB7SU1kEzPojwerMcb/kA8OD6br4/cyHeXpmy3B
lbe3mGQfcWyq9PWL6J+r0QKXiLAHJIQelBHe6hpkJyxy0hWZisNcZywiL6GVqwZGSOoM9A8f
yUDEq79jyv44iYQIp18D/840e/WJluqZwQN65iljCzkLAY9Fh1+56FnjZWAlXEaW2+vRddPO
APqwv/RsmolFlpmjqBAkZ8n/Csfel58I2sBALFjQL+HQCWf3SVChGyJQUJmAxbP93Rc6Mkqs
zrpvZjLy9YjNaE2O2mIRCYErRTuQiUcWvqeX6WmJsjCjoA04u89A9MnJ8MND8FUuAuDFhPsJ
z96nCc/e/xXCMxycvA6uQDZG04GSiojBlkwpYpQXvC1Gu4ZI+otIUUGyMFLjf0lSjyRdfuuS
tHdvSdp7Gx61jtrhRee4edYLe686ze6r9omnBgqJVaRJiNLdry73oJDC/A4yBMAfFFiMnnPW
oSHLQxQvoQ7FaDZNP0Sln5OsX91ngpvso+ubJTeA2V+UC0Pd1kaDJHETX1Uzg+CT/4kWMwsV
3uKHaVFnoAa58iq7gZEOEehGljyrNXqN1/Op5zKlI9s3BlqfDsfoLY6LFwO+Wq5S/tu4U7Mk
D+OlC+nplgnO19rhR9Yy7AHwL32XnropugP9zsqzDPkwpSVndffPrn1EzFr0DvKmfwRpfekx
0oPDMkKs8b8DU+Ecy2HHa5a4vB/brT0u6Y/woi4Zfpw10Rj573SyxcdFITAWDqh+KDtAd335
i40N/Kd8x//U+Le2+NRHF+MU/7sKtlaLM7xd+oSutcZPxK73ZPKBRJMYw+0bFPfprx9tbW2t
wVCoPNt/tlWpbu1UgsrB83JZ/P+2vLJcDrbK++Xyo42NjTUtFarl8s5W+WCrvBtUdp/viv8/
sNDsCTT/+Z/iL5vlYKOyub9zEPznf6JBPQWLOgxNkfsqDMUr8RxkhecVwE0H49UwCn4aj6ar
2yeUXX775ufkKyAYON/3bjIbrsaR99V7UDLG3lcZjcXz0XQ8G7zHl+brfjyRIybfUf8Kh61e
uaCuiVesFxX9omq9qOoXu9aLHf3iwHqxq15UytaLPfWiar/YVy927RdP1YsD+8WBfFEp2y+e
yRdV50VFdX3XfaP6fuC+kZ2Hzd5+I3tfTbyR3d9NvJH9P0i84QFAncJ+wyNQTb7hIdhNvuEx
OEi8qdIYkOpiv6ExqHre0Bjset7QGBx43uAYsIZkv8ExqPre4Bjs+t7gGBz43sAYcDPOGxiD
qu/NDozBrvcNjMGBevOQ6tNDVhh9YFykLtGNnHmfiinCrnYj1KVgLEy8scx1oKqrCOXfqqgS
Q6K7b7mPD/XDxCtyt5CGRzlsdf4rPLs4DXYPKFXLBFJl4fjJ3NqboIyVUTdwwSsKPIFwo5KB
reLFVs3AVl2LDW9iop5mpH19KwwbYcuYJ/Pk/MXHcEzHKuXZTEZC8AVKzFhnQ0KlTqH8YalR
/RG5hREJHtnWzhpwnwbugMqrlQKPzPdVjN9f/hiX8NZV1B+YJxxESI8cJTbFY32vU7lSzC+g
4U0ExyuB0xm0b1wF7bkE4Emxfi96BMOqAjuQFDmmjeiqvxov5YCpPJUguywqzDn1BggHFSWc
FNaOg3U3B1LrhCTYJZyeluvt2klg7qUmBv0S6TkXcgJCTZzIEjwCwsmSQoMymwWkrGNIqqHi
hXOBJkgY4tL2BQ2WgSBVOqHCKCM06zAaqyCVo3AJd3PfS6tcJ/rqYECYmCy6ZkUHoJav4BYz
QalUjHB8NJnMppi4pPv6MIZqF6K9KSbAIHt0La73l7FDSicHKQs/KSuDFs2GwlC7F04iCbE+
wjvJ4s2yH79X4XFXYEBLDgOvH9iEs+VSmL03/fEVpiaDQzyEfqInZ/nPkP/GGNUxHLVzQQG1
FA8g8CPJgnmjyXx5ByEZI7GyITYAE/chNeh8JGhOhjecRZSB7IaC+GRsrBQRCaJGk2gRYv4Z
dmLCgMq0vUBliNnpw7C/XC5GlythOYVBscjXyIvd0/OwXqu/aoaH73rNbok8zmpkAQe2AEEf
1N+VMMTFYzHmoXQlwaOl9egP/PbRBsyMuRIgMVlRPIRW3HezeTQtJhaCMA0936K7I7ydCGz2
veng8WaQG8dsntYemto24cvwRqyNcbQA+jfJGNeNzSHO9zpOaUlgn/TJhI3i2NeoRFjigfu/
SFOL0SdsqWrj2cd/aWr2Dzfeh3eAkkPrVdSHOjNH4L2Bfe259q6Lgf44W7w3Stfc0Me5fKD8
7RUgBrkqdLVYaGyDxUxM9N08EjswJXFUztJhNBj3uWSgIMVAiAcQ/YXginFwPLoODkdGlXgO
JRtb9UwbzfPmWaN5Vm81u1/PW/dog3uGNXSCEPMy/i/FR2xSUsg/MFmjzBRCagjn9rb0IE/B
STq6MBUgs7rgm9rJRTPw//4hemv+QJ++OGvV4Vr9WbtzWjsJT9uNZqHwe8rHjeZR7eKkpzWt
cq5va53z9d/LksqH9bB1JMjpha3zsN0B4JwwrfO82AXOIP3beu28d9Fphr36eXjUqZ02u2Gj
1V3//UUj3/fGyEAT9xlJaOI+3x+eNy4kgI+zhJZDmTHyMxiXr0Q+KxR87XfPa2fU8nmt/rrZ
64a1LvNXKs3ntU6vBQIEhg5ivx5tOPTGw0lfJY1NIdE8XWcCgcICF9TBAPyOYHYwEMLdcH/3
sNULCr/Lb4576CVtnR9D5Jn4vFguAZ+YOHo+HJTdhClJYqGaS4Hzc4ahaNT2MSIKfLMWR4tR
f7x2MOxS2XrCRFcwErTdqTfDk9bZazH63S4UPPndeM0heLWLXjs8ax7D52Hj4vzkrf0ZT5f9
3dFJ+5ew3uucBNa3tcabsPvu9LTZ67Tq5kfWV0TXUR1lkeAbQd1FtwkNicEPPJ8enqtP/1Y7
NbCB7zTAk1GL4jZKF6P7R7WWSwRcmK6ddU9bvbCyH9Z6vebpea8bZA9R97zZbITHp61Wwaaz
0Wti58tBghh3+A7fwWTYH6mXoof1V7Wz46Y7WVDaQXA3rbewsrdXBWXeIbd+0oHVG5602+eH
4ksXCWR3gptUOM3Ntzio/h6rqYPlINptnZmA5mJIVp8IAuWr1J/1sj/DJXBaq2NA9TxaPllE
/x2BiU16hMn6tXq9ed4TaOpixBsdPPEyGuo0/9asO68r3AAl45KJrfAUlI9jZYSn2ZB1mwem
tXxbZURCN+lfmrrJBaQ8PR7PLsWqlfXuYr3Zn7YOhfqCgSuxrqSH7WA0f5zwiwmI8LjdboTt
eg8ELG9vDTG3v0CHb8s5v3/VOn6FQ538/rCW+FzKqvLtQfJ7DNY9Ax1CDK5aPc1OB74fpNDD
+6XTAHjA/QT5vwcAXw867VoDtZsEmADwdOFUbJutVABPH/iz/V0eKUOeg68+HWAvFEu6Un1q
wAkATx8YoFI9AIjq3p6GEACePjBAdW8fAPYqFQsgvQ97lSrSVK7uKAixE6X3QXy5CxCwYg0A
Tx9MzutCGAhxKXV6x9OHBACxKQOs4SUAsOZh19OH5tt6s9sFjbDePjlpdYXmYQB4+pBgDd2M
APD0IcF8FoCnDxdngttw8cgtW3Ff+XbPNw91t69Gp/fS5uGonlg9BODrQy3tewDw9qHR7KBm
lIAp3+77een4VHQiuaQBwNOH9pu0BgDA04e/1Q4Pxb7i78O+pw8wA9JcoCs+BsDTFLlU79TD
5pvEbAgATx8SLGcBePpwUut5GFUCDHgbOTd0Q471h7qSxfNup5TYQVBaH9WECgT6imil5eMj
biMN9Lx+mg6FPzift6FR4xK6XKP9i6f/mQ1L0IvzdYDYcMWGRqW4JmRJ7eSINZW8DUtQQ8nJ
arhqQwtNQStMrPA1UqDLGaDNs8NaOiQ0vGND48ySUlopl8X/MsarnAWaBYgNJ5hcA2eCJhu2
2l0DCvEXNrRQkHvpU5PZcA/V2PNO+7gjdoa1DT+1oUlth/Zr9Z6QHPdomEHXw1HDBx7WBHtG
sKc2ouFyXxJXClevA+OGn3mgZXgnEAAW0rtcPbZAM8C44UpZOQN6N1EcSbVfJpUnj/F50lNG
0u82HAj5J/TxpBrtcX6lElL2gwqGOW116xfti24qfFIIJh1p6SOwDrSSPXhroKuZ0NU10Dvp
0EUAD35HGkpr0OxmErGzBnovm4idnETs50JTXYfmaT40a4kynKZ+bOl8oUFTeCMpsb3QKbyR
FLte6BTegEHYo97v5ul9Cm9AiF0O6BTeACL270FECm8YaPbyoEnhDRONn6gM53gCm6tCkMcj
D6RnX3M97P4OrG84G9KzryUd9p/WcDakZ18T+1LtFDbyi/MGqN1oAoTdi9PTWsfdpzCe0gb3
Hx7kotsD2kxTkTEq0w9uH0Pcq2UDNLPl9OVvHGjkatkLmi61KulrXoOni63K0xzgGXKr8pTF
9n76ateI0iWX63vygmeIrsrBfejIEF4K0dM8iDLEl0a0njLjEMuPMJ1HNGgGjzzLAZ7OI67X
zguewSPVMo/AszwjkMIjiChdddPwGUxSrdyHkAwmkYiq5TyIMphEI1pPmXly6ceYPk8GrJ9N
MAY8D7ifTTBQPA+4n01wKKQemKFPGoj8bIJh6XnA/VyCdOzeiw4/l1iIdnIh8nOJjcig7JPM
Pz7cVlbgWzYDXSuwfiLs79bRu/Q9zxpyh+8yTrsT0GtBe+00Q8Ljz3KPzDPIdg1wBUoHemt6
XNUTcPukI4NCZTkNHN/Of9U7T3riPyV3dHkN52jJN7q8ivNCV3zQ1bzQVR/0Tl7oHR/0bl7o
XR/0Xl7oPR/0fl7ofR/007zQT/3zvZ4pfWq/nO+c0M/8850T2j1klBOeF9zLbbu5wb3stpcb
3Mtv+7nBvQz3NDf4Xm6h3OXAHdcx123U0/xyndbRYSYFNjFJp7kRolPhMB//LxO0mgmaFDf+
+KJU6OQxgQF9kAmd4Vxzer+fhScptQ5PTgGDMH+7v9TWHLMkpRZDQ+zJWnjXCy5Ae/kb3vNC
f0rDMni13emuhfc5nTT0OtqTBw6fyqa9+7Gpq+t6Y9gywHeywHMwapqu27sfq4Kum1vqODFy
fBCaKnE4WA5PJtaJQFeLM0DXbZlJYeVG4WX9PO78RCxbOhKn4dT4vvWg3pi/FNiknPM1rGMB
799wCmxStkEEnlijaW1lNZwWuZgyS7u+OU6LaMxs2AbtvdWg3ob3fNBOfGS+HtugAi7jYDWp
BPqgQ2FuQGrHTicBfZC6JjA0M+vncog/uDONbFcDTAn7zNOyASpab75pdvxgsmV3JbusrYNJ
veA72YsqAzoxZCo4df0vBTTjCNIi2nVW+INf87Ts9jcD0uex9kTU5u1zp9nt1eDgnFGs67Oj
MLiRupUDjNTN07ILWq2mg3qc3SkxwqngbhySBf6snNV6pmvZQVR5toaOZ5ngT8vlNXQ8S6ED
wp2tcOiMn8cvnIimzvglNAZPoHVGy5UkuBHElAnuXzbZ8dtGy66TlBdsHnhPn42gIow0TQvx
yQGaFhvkUVcB3IG+z0S5DWdN1K5ST8U+gDpnQs88bQmdt6sOEjnlh4AoB1vBL5CAeTOoYEb7
/lAj96HBBJNvaietBqN5+klo2ud12KMxdVuhjBUiZpP5OKKkZFeEQVVtykIBBAWc90SgaSuY
Ucy1Ia8xj5j5UzHwcHVHuRQ5ehGLUsRmlD87IYMf3MIKRm5ji98zDm/hBwKiXMrAa9YMtgxO
T/ZqF/FOxcCcg9iTuhtv6hBbLgSBI8QuOmtgQPK5QBBLuA6o6gKdCPK6Z7Vz0G5Oa0krDYCe
BbLH+aYHo2YzKPH1GAKAOxdnqXDeHsOmgQfb4Unz7Fgyxpoey0rDaU0VLS+MA/zmpHYW9mrH
xykBm0Xf+ReeBSCdGRPjnsKpcAEcGgjveGOdFxVRZLl801gDhPuOO/S9V+JbAuu9O08QWfQZ
+Se1dwKoCnG7OC7umVrRd2ik20iSpoDcIBkCeiWkEKzM5IaMQG6cjti9sKw0llZNG3L3MBvC
cluddCgEcvWNi7PXZ0JeAEyvdVbD4xe4g2QBHSRbcnPhJ1ty2YiGfFdots36ayH83MFA4VRO
WaqQWo8S5yaWKw2wDNlPMjYSkyLz0gRpglY9sIUCLhKX34kK2JrFhgzLzENFxZ1mtUh8cxyk
yNbGGhhfnMNx8wwbA2DZpwSQyxoARHzuhWF92gH6e7MDnoRGo3XmNUK8EqaXh90TEiYPu7vC
Avok5HvK2KUIi14edneFBVpiGUqwze4q6YDvpr7MSIu5egB3GZJbbvI/KuIfFfmPqviHUI//
oAPVdocuASfRQV4DKK8iS6RJzO3Xm5RaqyOL1vShPtQ8GmB5KM8Ps74orWYTgY9W02F/Ek2X
/TFVefBCmsBYCpiA67PVeGhV7sP81PFyO+gt7gLIYU34dMuq1hphwAw3TiVvWQPc37wu2Gdg
sAtV+LvgYEAuljt0AlEc9GVFYy65tW0hollzauGkTOCyv7iONEcI4/9YgDSEYNh0HjXftOpN
52H9sOs8Oa+3yslHFUkUPXphubkhLRdk5bgcXW9BjtP+FJRiMeARDPPJaLkci7GjF9MoEjoz
5ECNoDgaJr3AxUJXSWUOr38bXXHaiWExDA/hYv9Zo1U7K+kh4CQ1IZcIwqIkmMOqsl9QhWiw
/KMudiKLZelNRM0dgslqdAV93xZTfKVP+WqnWpBFCZ3GHHPBhcKKaVhfBYrsYDFDpzSLvNeb
bFGW5vF3z4HTHMXVYyxOModxmTWMybFT48al/fAzrHazmH0YDSGFW/2cyp/Hq4l/vOo0SE9M
myprjM51NRtvJRt3dIzqN9wB4NQl5H5xQP+QIl4N0b9FY4sNT1q9npD9+Tnx03jjExnxE9n+
U7jpc/j3EzgxP8vckxfzsvgn89SnMbHLiYIP4wj+wDpJ7SnmsTOlYiAeO+wZTMSuApncmH0f
yfTTJLgvpiMxbkM55kC/ULSBI4VirNwpMVbPhsR0C6povNR1HwTtQCuMmpD+/cloPBJfUSbH
aASpBQDVlBAbqnaWBuBygiqpZ+UmjG9ABfoUXrcxmJwiSE0wS10ySxIB1im4/8o2we+/6OxE
co8Ds1oalh2FaVK6ilE+VZYhJN6SJfFUIjen6kYsdDzBHAMENSD9C1UXT5QaCJaGULkjC4oy
X20PHpeDAn4vU9D9uv+b7hDzL0Fhkg1Oqq8XGNGAITxGe5m5qVy4kKIxX/igZaSmDzrGcm7c
tAXLHkNE4IXECICQIwAc4NQUOhpeSEgMdAyZ4ViwLKCs43L0IVLpMeNA8PCkL6srKwSLdQg6
XgSUURJJFUzbXw5ugnmfso2inFDsY+ckjWX1xNHwMbU/p9yllLQR0o0VnJptL7hCbXb9WYRc
eiB7ayCpIxQyijl1hdI67V9PVMneSLp4t4MjAciZ/kQnDXDc8nS5TswUh4mdaflhPl63gqRb
Fj3852aQKPWYG33Ph37poF/60ZudR/UCGoCaAoLjBAOKJjOHwFsLE0qhmgUoE3XczZcqw2pC
tlGxSG/u3N+Ifqvxnm58mdX4Mk/jS7vxXrJxbVY7olTmfty+CWrnrQDznqqTAVxc+qxCBf9Q
4ZQ48JXSwKWCWUmtFpN1TyExpxcYC+X6i/YYMJgEUJf7gfSleVpMtIm9x4SiLFgX0XVmxSDY
3qwponRkL1ILElEL1zlaIAKTdR0DXcmJ6gVRYRrO8GjNQ/66cnZdE2/No4xOpVdZyonX0u7O
nb0yB4utaOsNU3lFTpdqmOqizBGsJB0C56/eoRCBnFG+RiWb0STOb+7WsWcKg2It2DCejPLw
l53VGtu8TnmrmC+lXSE2hjmbzWzVLlaTbFVNzmAc9RfhZHQZcu24OGus5Nzj3nsFWWqzhIzH
yWTy4nSYu9ayv8zyi7UtLVVpZ5DKbnMSO/4+oczz+vZ5TgeR2NcyWs9o+1Nbzi5q/QA997Bw
tMCdRO2QsPHnnGJoytw/U+Q35vWW34AiYUiHFGIWn07MwksMv4FhxR0+lc6FS2fWl4jO6RHJ
3AL5yc1CRrDInDJPXCzoST+ebE1G83h/9wkgiuf9QSRrPWV/ows+ZX8H5ZqqW5XyVnUnKD97
Xt19Xi0nyjWpqk/rcZmln3aeV596Sz8d7G7uBxviv1j6KXgUGA7coMg5T4WFHXZ2d8rlEjJw
4R+PkIV//z3ly7fyS85Fmvbh6dNy3i+fGV9mNr6X88Oz5ptao5bny9PWeXd/t4TDVanubj4N
NirV/c1KBUdMnhi9vjisdSExbNl8hhHownDTBaBkdR4MiaEPHlEyUWRgMMf6siQdHHlIrzqo
Qomx0wdWr8uy+dtnB2Xrd3EiPVGB5+u+87XSSJyPw+bbk/CXTqGgYEFrvhVMGIPNKdRiKvMu
yHUhz9pn9fYrH2mAYzqbDmY3eKjgAxbNIpnlJKRuPdeyFQJsCUI2Y9XqTzIXrf6M19n+VmUP
KrXtVp9XK/daswlUT7HoW/n53o5Ytd4lW6nuwZqFP55aLCgUx1fhafu0KYY7bNebJ+2exY6e
9+FxoVDJ/qJeKBjhetYXf6sdX9Q6Ya33tlDYAeHx5LFYSY+DN/0xVDnoD27A84Q8fS30mHnQ
6jVzTNRgvsqYI3ybOT34hTMzO3vP93bvNTMmFjkpO/tuJT45KXtPYU7Ef+0pOe+0GmHr9Dw8
rR236pjMFSCS72k94wdPvR+QvMIPDuBDcLGc7lX3y8F//Md/2FmaNc5njHNn19/o3i7Jpr20
93sEv+cnevc1dgmLtCFn7u+jdNx/ytuJhACJ9aazWzmoiB7sVewXtYtKBZrZq9rPu52nFaR/
b+fRlvkCzmjx6Yb5VPbWzFBpfL1r8GerWwtOsApEJGQPlKWJc7DlKEtyjNbJjJEjLcrl55W9
5zvJXTmLJw0k5tbur+q4uwMsKf5bKdNkWHUP4xF42hHjz+Idy3z7ADe5Vxt7pGd/fuTWVhRU
b13O+othzA1pczew97TucStsnVefPkKn7WLqKHKXqzhczoQeB17m6t7+by8EreunDP6A6ikZ
E6c/yZw+/RmP/67g9qD89Plu5XklOf5Zk5hAlUNLqzwDfWMD/qzS0pK/EAzxF3+UiL2D3smh
dQxERz1UXBYnKbjp/w9MyHYQ/IIVym+i4G8ANYqD1XwoC3Qtx5cfR3A8BX9ZbAqdJF5dxlhm
nM7+wZfIxVMQHIT8aEoeOXTGxDcqDATrmuMXu4EQq8HgbgAeSvA3rOCATKCDl2j8Lhf9aTzu
Z+DYMXBw2EHANspoOoZlj0a4IDwUCtRlVIR/ivH5X6FnhaGYiDAUoya9kGFYBP3r+21Izj2d
LaLZYhgt/jH9x/L7jMXA7C7g4vH4H8v/p7wp/r/CUJ//VC5H8VZ0Y/7tUIOjxGP0vTCmgj8E
3yGH7lRA9B/sHmxWniGD/mWH+xuiJmO4n+Fw7//1h/vj6NshJ328d5/ieB/8/2C8vyFyvOO9
fluf96+zfC/0OnM7p08+Wx+z0KzfxisV9LbAH5Vd1skSc9BtUbqAw8rt7W3YbddLhuZdO27K
0hBJ010Y+lKR802ua9cZ4a42Xq8Dgb+8OKvX6iF6AMSHZc+H6wnQZmMqCcmuga4j9JuBMCqj
4WagXAbodbjsD95bNtAaMhnZairQbQaXUPgSTpIQg9SE1aCH4bxfvC0VCsWipZSWAvE02DIp
L5lQHyQUF+Dzgm9Y4KUczE8hBhnsLz/IXADyI2XgVrHU/I5QaO9nJjuIjGLzO6mWcmUHTWXx
h2kkSr7EaRP/uWgExUAWpg6eBELfLpnzor6nTAlYHbhwUNa2YuID5oerIWA0L16mfil/EiK9
+So1X0ltvmo3X05vvupvvmw1HzpAYeus1aMKkjDnJfJrbhX+V/xzNUQP+HPPEG8Go8U/n+MJ
JUZYxM+Dbq8R1tun4dFJ7bi7CUV67o+jWOu+OxOftNt0oxkkQPB7QE+7r1vnYa/Z7ZUE9qAQ
BKPZJJow+uLqQKwV7MMmvxDGUhjfjK6Wz4PqJrlrESgE75Kgl/vfDk+bp7CDKF+VI/DsbBzN
o7MuDRJw5VM0lsV/qzZTrsfhGM+GTZuUd3jQ114MR1OIyjnrVvb39qrBcAUVKjECry8Y/vTV
/wSDxZ0wacbb9t1KjShzjWx4IcxV8jTzizTmN/CGCTAf/wUJ5vH14LPYZ+P+7BNIqBT+2XDn
PtlXl4M2CmkD4p+AzbRhL+mg0XsQkcetgs4vUwlBg81kdQut6lpQAPi0jgeFPIsMBijfYALG
LlxATm0PpJNnDT76/wBrbvQLNXkDAA==
--------------010102060601040501030303--


From ppopov@mvista.com Mon Aug  4 23:03:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Aug 2003 23:03:54 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:5873 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224772AbTHDWDw>;
	Mon, 4 Aug 2003 23:03:52 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA18053;
	Mon, 4 Aug 2003 15:03:50 -0700
Subject: Re: udelay
From: Pete Popov <ppopov@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030804213812.GA21327@linux-mips.org>
References: <1059788948.9224.62.camel@zeus.mvista.com>
	 <20030804014132.GA4419@linux-mips.org>
	 <1060018159.9217.93.camel@zeus.mvista.com>
	 <20030804213812.GA21327@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1060034667.9224.219.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 04 Aug 2003 15:04:27 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2984
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Mon, 2003-08-04 at 14:38, Ralf Baechle wrote:
> On Mon, Aug 04, 2003 at 10:29:20AM -0700, Pete Popov wrote:
> 
> > > > Looks like the latest udelay in 2.4 is borked. Anyway else notice that
> > > > problem?  I did a 10 sec test: mdelay works, udelay is broken, at least
> > > > for the CPU and toolchain I'm using.
> > > 
> > > That just doesn't make sense.  Mdelay is based on udelay so if udelay
> > > is broken mdelay should be broken, too.
> > 
> > I think the problem may be occurring when udelay is used with very large
> > values, like 10000. I've told the developer that that's not recommended
> > and to use mdelays in that case.
> 
> Any bug report for udelay arguments larger than 1000 will probably be
> ignored ...

I found the 'bug' before I saw your udelay comment ;)

Pete


From michael_pruznick@mvista.com Tue Aug  5 01:05:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Aug 2003 01:05:49 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:7154 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224772AbTHEAFh>;
	Tue, 5 Aug 2003 01:05:37 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA22611
	for <linux-mips@linux-mips.org>; Mon, 4 Aug 2003 17:05:35 -0700
Message-ID: <3F2EF4CE.5D5BBC1E@mvista.com>
Date: Mon, 04 Aug 2003 18:05:34 -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: linux-mips@linux-mips.org
Subject: PATCH:2.4:makefile/vmlinux.srec
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: 2985
X-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


This patch allows an srec kernel to be built directly.

cvs diff -uN arch/mips/Makefile arch/mips/boot/Makefile
Index: arch/mips/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/Makefile,v
retrieving revision 1.78.2.36
diff -u -r1.78.2.36 Makefile
--- arch/mips/Makefile  5 Jul 2003 13:17:03 -0000       1.78.2.36
+++ arch/mips/Makefile  4 Aug 2003 23:53:38 -0000
@@ -627,6 +627,9 @@
 vmlinux.ecoff: vmlinux
        @$(MAKEBOOT) $@
 
+vmlinux.srec: vmlinux
+       @$(MAKEBOOT) $@
+
 archclean:
        @$(MAKEBOOT) clean
        rm -f arch/$(ARCH)/ld.script
Index: arch/mips/boot/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/boot/Makefile,v
retrieving revision 1.13.2.2
diff -u -r1.13.2.2 Makefile
--- arch/mips/boot/Makefile     1 Aug 2002 18:20:59 -0000       1.13.2.2
+++ arch/mips/boot/Makefile     4 Aug 2003 23:53:38 -0000
@@ -24,7 +24,7 @@
 drop-sections  = .reginfo .mdebug
 strip-flags    = $(addprefix --remove-section=,$(drop-sections))
 
-all: vmlinux.ecoff addinitrd
+all: vmlinux.ecoff vmlinux.srec addinitrd
 
 vmlinux.ecoff: $(CONFIGURE) elf2ecoff $(TOPDIR)/vmlinux
        ./elf2ecoff $(TOPDIR)/vmlinux vmlinux.ecoff $(E2EFLAGS)
@@ -32,6 +32,9 @@
 elf2ecoff: elf2ecoff.c
        $(HOSTCC) -o $@ $^
 
+vmlinux.srec: $(CONFIGURE) $(TOPDIR)/vmlinux
+       $(OBJCOPY) -S -O srec $(strip-flags) $(TOPDIR)/vmlinux vmlinux.srec
+
 addinitrd: addinitrd.c
        $(HOSTCC) -o $@ $^
 
@@ -40,10 +43,12 @@
 
 clean:
        rm -f vmlinux.ecoff
+       rm -f vmlinux.srec
        rm -f zImage zImage.tmp
 
 mrproper:
        rm -f vmlinux.ecoff
+       rm -f vmlinux.srec
        rm -f addinitrd
        rm -f elf2ecoff

From dmitry.antipov@mail.ru Tue Aug  5 15:11:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Aug 2003 15:11:29 +0100 (BST)
Received: from RT-soft-2.Moscow.itn.ru ([IPv6:::ffff:80.240.96.70]:2492 "HELO
	mail.dev.rtsoft.ru") by linux-mips.org with SMTP
	id <S8225307AbTHEOL0>; Tue, 5 Aug 2003 15:11:26 +0100
Received: (qmail 16125 invoked from network); 5 Aug 2003 14:08:01 -0000
Received: from antipov.dev.rtsoft.ru (HELO mail.ru) (192.168.1.213)
  by mail.dev.rtsoft.ru with SMTP; 5 Aug 2003 14:08:01 -0000
Message-ID: <3F2FB360.9040005@mail.ru>
Date: Tue, 05 Aug 2003 17:38:40 +0400
From: Dmitry Antipov <dmitry.antipov@mail.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: IT8172G on-board timers 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dmitry.antipov@mail.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2986
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dmitry.antipov@mail.ru
Precedence: bulk
X-list: linux-mips

Hello all,

 I'm working with IT8172-based MIPS board and want to use one of (or may 
be both) on-board timers.
For my purposes, it's required to generate irq from timer rarely, for 
example, each 1 sec, or each 5 sec
or so. (The usage of Linux timer interface (init_timer() etc...) is 
forbidden, and I don't want to touch
system timer to avoid the potential damage for basic timekeeping, 
scheduling, etc.). I have two problems:
- timer backward counter is 16-bit wide and reaches zero too fast, even 
starting from 0xffff;
- timer input clock may be one of CPU clock, CPU clock /4, CPU clock/8 
or CPU  clock /16, which looks
   very fast too
So, the minimum interrupt frequency from both timers is 96 ints/HZ (with 
TCR0.PST0 is 0 and
TCVR0 is 0xffff) and the maximum is around 150000 ints/HZ. Even the 
minimum is too large for me...

It seems this question is much more about h/w than about Linux, but I 
hope someone has an experience
with this arch :-) Is it possible to program on-board timer to generate 
interrupts with less frequency ?

Thanks,
Dmitry


From michael_pruznick@mvista.com Tue Aug  5 19:25:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Aug 2003 19:25:07 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:59889 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225258AbTHESZF>;
	Tue, 5 Aug 2003 19:25:05 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA25187
	for <linux-mips@linux-mips.org>; Tue, 5 Aug 2003 11:25:02 -0700
Message-ID: <3F2FF67D.8B0C2DFB@mvista.com>
Date: Tue, 05 Aug 2003 12:25:01 -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: linux-mips@linux-mips.org
Subject: PATCH:2.4:CONFIG_BINFMT_IRIX
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: 2987
X-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


All this does is put "CONFIG_BINFMT_IRIX is not set" into the
config files so that when switching dual-endian systems from LE
to BE this will default to "n" instead of "y".

The main problem with this is that, in general, there is no
need/desire to have CONFIG_BINFMT_IRIX included just because
the kernel is BE.  Rather than being forced to disable this,
I think the default should be off.

In some older kernels, it this causes compile errors, but that
problem doesn't seam to exit in the latest 2.4 tree.

I tested this with menuconfig and xconfig.

I'm not an expert in all the subtle dependencies issues with
the config.in files so there may be a better way do to this.


cvs diff -uN arch/mips/config-shared.in
Index: arch/mips/config-shared.in
===================================================================
RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v
retrieving revision 1.1.2.80
diff -u -r1.1.2.80 config-shared.in
--- arch/mips/config-shared.in  5 Aug 2003 11:13:39 -0000       1.1.2.80
+++ arch/mips/config-shared.in  5 Aug 2003 17:07:24 -0000
@@ -817,6 +817,8 @@
 
 if [ "$CONFIG_CPU_LITTLE_ENDIAN" = "n" ]; then
    bool 'Include IRIX binary compatibility' CONFIG_BINFMT_IRIX
+else
+   define_bool CONFIG_BINFMT_IRIX n
 fi
 
 if [ "$CONFIG_CPU_R10000" = "y" ]; then

From trott@bigpond.net.au Wed Aug  6 05:13:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 05:13:28 +0100 (BST)
Received: from mta07bw.bigpond.com ([IPv6:::ffff:144.135.24.134]:29411 "EHLO
	mta07bw.bigpond.com") by linux-mips.org with ESMTP
	id <S8225201AbTHFENV>; Wed, 6 Aug 2003 05:13:21 +0100
Received: from titan ([144.135.24.87]) by mta07bw.email.bigpond.com
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with SMTP id <0HJ600H48JL3KS@mta07bw.email.bigpond.com> for
 linux-mips@linux-mips.org; Wed, 06 Aug 2003 14:10:15 +1000 (EST)
Received: from cpe-203-45-209-27.qld.bigpond.net.au ([203.45.209.27])
 by bwmam07bpa.bigpond.com(MailRouter V3.2g 62/550314); Wed,
 06 Aug 2003 14:10:15 +0000
Date: Wed, 06 Aug 2003 14:10:19 +1000
From: Michael <trott@bigpond.net.au>
Subject: debuging problems
To: linux-mips@linux-mips.org
Reply-to: Michael <trott@bigpond.net.au>
Message-id: <003501c35bd0$a662bdc0$6400a8c0@titan>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Return-Path: <trott@bigpond.net.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: 2988
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: trott@bigpond.net.au
Precedence: bulk
X-list: linux-mips

i have written a mips program to verify if a given input is a magic square,

a magic square is a n*n matrix whose values are from 1..n^2, and each
row/column diagonal gives the same sum, this sum is know as the magic
number.

All my program does is go through and sum each of the rows then each of the
columns,  at every stage the sum of the row or column in question is
compared to the magic number, if not equal then not valid magic square. the
formula is given in my doco.

im having problems working out what the actual  problem is. I've completely
coded it and spent alot of time steping through it but i cant see any
problems. regardless of the input, the result is always negative.

just wondering has anyone got any suggestions, any help would be greatly
appreicated :)

ive pasted my program at the bottom of this,

thanks everyone

michael

_______________________________________________________________



#      Program Name:      Magic Square Verifier
#
#      Author:                 Michael
#
#                       The purpose of this program is to determine whether
or not
#                       a given input is a valid magic square.
#
#                       The start address for the matrix is to be given in
$8, with
#                       the size of the matrix supplied in $9. Major row
#                       representation must be used to store the matrix
values.
#
#                       At completeion of the program, $11 will store the
#                       result of the program. if $11 == 1, then input was a
#                       valid magic square, if $11 == 0, the input was not a
valid
#                       magic square.
#
#                       for more details, plese consult the attached program
#                       description file




      .text

main: li $11,0             #      is magic square = 0
      li $12,2             #      temporary
      li $13,0             #      Line number
      li $14,0             #      temporary
      li $16,0             #      Line position
      li $17,0             #      start address + offset
      li $18,4             #      constant 4
      li $19,0             #      Line total


                              #       Calculation of magic number for
specified n
      mul $10,$9,$9         #      n^2
      addi $10,$10,1         #      (n^2)+1
      mul $10,$10,$9        #      ((n^2)+1)n
      divu $10,$10,$12       #      (((n^2)+1)n)/2 == magic_number
      addi $15,$9,1          #      n+1

r1:   beq $13,$9,cr         #      branch if line# == n

r2:   beq $16,$9,r3         #       branch when line_pos == n


      mul $12,$13,$9        #      line# . n
      add $12,$12,$16       #      (line # . n)+ line_pos
      mul $12,$12,$18       #      ((line # . n)+ line_pos)4
      add $17,$8,$12        #      start address + offset
      lw $23, 0($17)       #       load word, viz[i], into $17
      add $19,$19,$23       #       line_total = line_total + viz[i]
      addi $16,$16,1         #      line_position ++
      j r2

r3:   bne $19,$10,exit      #       branch if line total != magic number
      addi $13,$13,1         #      line# ++
      li $16,0       #       set line_pos
      j r1

cr:   li $13,0       #      clear line number
      li $16,0       #      clear line position
      li $19,0       #      clear line total

c1:   beq $13,$9,sum       #      branch if line# == n

c2:   beq $16,$9,c3         #      branch if line# == n


      mul $12,$9,$18        #      n . 4
      mul $12,$12,$16       #      (n . 4) . line_position
      mul $14,$13,$18       #       line# . 4
      add $12,$12,$14       #      ((n . 4) . line_position)+( line# . 4)
      add $17,$12,$8        #      start address + offset
      lw $23,0($17)        #       load word, viz[i], into $17
      add $19,$19,$23       #      start address + offset
      addi $16,$16,1         #       line_total = line_total + viz[i]
      j c2

c3:   bne $19,$10,exit      #      branch if line_total != magic_number
      addi $13,$13,1         #      line# ++
      li $16,0       #      clear line _pos
      j c1

sum:  li $12,0
      li $14,0
      add $17,$8,$0

s1:   beq $12,$9,s2         #       branch if counter == n
      lw $23,0($17)        #      load word, viz[i], into $17
      add $14,$14,$23       #      seq_total = seq_total +  viz[i]
      addi $17,$17,4         #      viz[i] = viz[i + 1]
      addi $12,$12,1         #      counter ++
      j s1

s2:   li $16,0       #       total
      li $19,1       #      i of n


s3:   beq $19,$15,s4        #      branch if (i of n ) == (n + 1)
      add $16,$16,$19       #      total = total +  (i of n )
      addi $19,$19,1         #      (i of n ) ++

s4:   bne $16,$14,exit

dc:   li $12,0
      li $13,0
      li $16,0
      li $19,0

      mul $14,$15,$18       #     (n + 1) 4
      add $17,$8,$0         #     copy start addr to $17

d1:   beq $13,$9,d2         #      branch if line# == n

      lw $23,0($17)        #       load word, viz[i], into $17
      add $19,$19,$23       #       diag_total = diag_total + viz[i]
      add $17,$17,$14       #       viz[i] = viz[i+1]
      addi $13,$13,1         #       line# ++
      j d1

d2:   bne $19,$10,exit      #       branch if diagonal_total !=
magic_number
      j complete                #       else complete, therefore input is
magic square


complete:      li $11,1

exit:




From fxzhang@ict.ac.cn Wed Aug  6 12:00:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 12:00:55 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:15025
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225280AbTHFLAw>; Wed, 6 Aug 2003 12:00:52 +0100
Received: (qmail 15961 invoked from network); 6 Aug 2003 10:55:17 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by mail.ict.ac.cn with SMTP; 6 Aug 2003 10:55:17 -0000
Message-ID: <3F30DFB7.8030304@ict.ac.cn>
Date: Wed, 06 Aug 2003 19:00:07 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>
CC: Ralf Baechle <ralf@linux-mips.org>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
References: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02>
In-Reply-To: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02>
Content-Type: multipart/mixed;
 boundary="------------070804020907010709090500"
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: 2989
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fxzhang@ict.ac.cn
Precedence: bulk
X-list: linux-mips

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

hi,
   These days I have performed more experiments on our ev64240 board.

   Now it seems I get at least two problems: sigtramp flush and L3 cache.

   Let me descripe the phenomemena first.
      1.  fsck /dev/hda4(a 10G partition of 40G ide disk on a pci add-on 
card use
            intel piix4 chip) frequently fail with oops in various place:
                __remove_inode_queue, free_buffers, vmscan:359 etc.
       2. occasionally other apps may fail with segmentation fault or 
bus error.
       3. xwindow system is extremely unstable,both the applications and 
the
           Xserver may fail with sigill/sigsegv/sigbus etc.

   To address the problems, I modified arch/mips/signal.c to let kernel 
dump core
unconditionally(even if there are use handler installed) for 
sigill/sigsegv/sigbus.
By this way I get many core files for XFree86,then I find that they all 
look quite
similiar--all around the point of kernel generated sigreturn code(Two 
example are
 attached). Days ago i added a 'sync' after writeback and the situation 
was much better.
But then i still see this kinds of failure even with the 'sync'.  I have 
to go further back
to use 'Writeback_SD', so far no more such fault. But just as Adam 
pointed out,it may
just mask over another error.  I have tried to add code in 
r4k_flush_sigtramp and
sigreturn,and when xserver fails,I do observe that there are flush for 
the faulting point,
but no sigreturn executed. So it is at my wit's end:(. Maybe some 
complex schedule or
reentry problem? Or even a potential bug of context management(e.g.,we 
are using the
other's stack)?

   Using Writeback_SD only help xserver problem, the other problems look 
like
cache related. So I try to run with L3 cache disabled. That helps 
greatly, no oops
now. With a little tweak on ide code,the 'lost interrupt' problem seems 
gone too.
But with only L3 disabled, the Xserver problem remains.

  I am doing stress test now. Hope it won't give me more surprise.

  And here I have a question for Mr. Adam: original linux code use 
'Writeback_Inv_D"
and "Hit_Invalidate_I",not "Writeback_D" and "Hit_Invalidate_I",could it 
lead to the
problem?

 BTW:
   a silly question: how can i make my email show up pretier? I find 
that the mailing list
often break my lines very badly. I feel guilty for that:) I am using 
mozilla composer,the
original linebreaks are manually inserted(hit enter when i feel it is 
long enough).

Thank you for any help.
 
Adam Kiepul wrote:

>Hi Fuxin,
>
>Could you please provide me with the _original_ Kernel code disassembly snippet around the point where your SYNC patch applies?
>Also, can you check what RM7000 part revision is on your board? You can find it out by reading the PrID register.
>
>I will check if there is an erratum that the code could trigger.
>
>By the way, are you aware of any other ev64240 board that would exhibit the same behavior?
>
>I would be quite careful drawing any conclusions at the moment since we can not preclude the possibility that it is simply a "bad CPU on the board" case. Please note that the SYNC instruction changes a lot in the manner things physically happen in the CPU so it can often mask off various problems, such as a bad part.
>
>Thank you,
>
>Adam
>
>
>-----Original Message-----
>From: Fuxin Zhang [mailto:fxzhang@ict.ac.cn]
>Sent: Thursday, July 31, 2003 9:59 PM
>To: Ralf Baechle
>Cc: Adam Kiepul; MAKE FUN PRANK CALLS
>Subject: Re: RM7k cache_flush_sigtramp
>
>
>I am using a slightly modified 2.4.21-pre4,based on cvs of early this 
>month(?).
>We have merged with latest cvs, I will run it and report the result tonight.
>
>
>Ralf Baechle wrote:
>
>  
>
>>Adam,
>>
>>On Fri, Aug 01, 2003 at 08:40:14AM +0800, Fuxin Zhang wrote:
>>
>> 
>>
>>    
>>
>>>Current linux code does exactly this. But I was seeing all kinds of 
>>>faults occuring around the
>>>sigreturn point on the stack without a sync? And a sync does greatly 
>>>improve the stablity.
>>>
>>>   
>>>
>>>      
>>>
>>>>The ordering does matter however since the Hit_Invalidate_I makes sure the 
>>>>write buffer is flushed.
>>>>     
>>>>
>>>>        
>>>>
>>could there be an errata explaining Fuxin's findings?
>>
>>Fuxin, what version are you running?
>>
>> Ralf
>>
>>
>> 
>>
>>    
>>
>
>
>
>  
>

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

GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "mipsel-linux"...(no debugging symbols found)...
Core was generated by `/usr/bin/X11/X -dpi 100 -nolisten tcp'.
Program terminated with signal 4, Illegal instruction.
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/ld.so.1
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...
done.
Loaded symbols for /lib/libnss_files.so.2

    GDB is unable to find the start of the function at 0x7fff7600
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x7fff7600 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
#0  0x7fff7600 in ?? ()
(gdb) where
#0  0x7fff7600 in ?? ()
(gdb) disass 0x7fff7580 0x7fff7680
Dump of assembler code from 0x7fff7580 to 0x7fff7680:
0x7fff7580:	nop
0x7fff7584:	nop
0x7fff7588:	nop
0x7fff758c:	nop
0x7fff7590:	nop
0x7fff7594:	nop
0x7fff7598:	nop
0x7fff759c:	nop
0x7fff75a0:	nop
0x7fff75a4:	nop
0x7fff75a8:	nop
0x7fff75ac:	nop
0x7fff75b0:	nop
0x7fff75b4:	nop
0x7fff75b8:	nop
0x7fff75bc:	nop
0x7fff75c0:	nop
0x7fff75c4:	nop
0x7fff75c8:	nop
0x7fff75cc:	nop
0x7fff75d0:	nop
0x7fff75d4:	beq	at,t3,0x80003ef8
0x7fff75d8:	sllv	zero,zero,zero
0x7fff75dc:	0xe
0x7fff75e0:	beq	zero,gp,0x7ffef244
0x7fff75e4:	beq	zero,t0,0x800012e8
0x7fff75e8:	0x7fff7600
0x7fff75ec:	beq	zero,t2,0x7ffd98b0
0x7fff75f0:	sd	ra,-1(ra)
0x7fff75f4:	sd	ra,-1(ra)
0x7fff75f8:	slti	sp,s6,-25040
0x7fff75fc:	beq	zero,t2,0x7ffd9cc0
0x7fff7600:	li	v0,4119
0x7fff7604:	syscall
0x7fff7608:	0x12c
0x7fff760c:	lb	a0,-19437(zero)
0x7fff7610:	slti	s1,s6,17812
0x7fff7614:	nop
0x7fff7618:	nop
0x7fff761c:	nop
0x7fff7620:	0xcf9210
0x7fff7624:	nop
0x7fff7628:	mfhi	zero
0x7fff762c:	nop
0x7fff7630:	beq	zero,at,0x8000caa4
0x7fff7634:	nop
0x7fff7638:	0xe
0x7fff763c:	nop
0x7fff7640:	slti	v0,k1,28680
0x7fff7644:	nop
0x7fff7648:	0x1228
0x7fff764c:	nop
0x7fff7650:	nop
0x7fff7654:	nop
0x7fff7658:	multu	zero,zero
0x7fff765c:	nop
0x7fff7660:	nop
0x7fff7664:	nop
0x7fff7668:	slti	t9,s7,17756
0x7fff766c:	nop
0x7fff7670:	beq	at,t3,0x7fff6f04
0x7fff7674:	nop
0x7fff7678:	0x12c
0x7fff767c:	nop
End of assembler dump.
(gdb) info regs
(gdb) info regs 
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 b004b400 ffffffff ffffffff 00000001 7fff73f8 00000000 00000000 
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   0000b400 00000000 00000000 00000000 00000000 822b2880 822b2900 00000000 
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  00000000 102b3248 00000004 0000000e 101cdf18 102b1820 00000001 00000000 
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000000 006c86ec 00000000 00000000 10082740 7fff75f0 7fff7d08 7fff7600 
            sr       lo       hi      bad    cause       pc
      a004b413 00000002 00000000 8009c6a0 00000028 7fff7600 
           fsr      fir       fp
      00800004 00000000 00000000 
(gdb) quit

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

GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "mipsel-linux"...(no debugging symbols found)...
Core was generated by `/bin/sh /usr/bin/X11/startx'.
Program terminated with signal 4, Illegal instruction.

    GDB is unable to find the start of the function at 0x7fff75b8
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x7fff75b8 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
#0  0x7fff75b8 in ?? ()
(gdb) info reg
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 2ad918f0 2ad918f0 0000000a 00000012 7fff7538 00000001 00000001 
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   0000000a 2aca6394 00000000 00000004 00000000 00000000 00000000 07200720 
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  00000000 00000004 00000080 7fff7878 00000003 ffffffff 1000f0f8 00000001 
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000000 00000000 00000000 00000000 1000d880 7fff7590 00000003 7fff75a0 
            sr       lo       hi      bad    cause       pc
      a004f413 000001b0 00000000 8009c6a0 80000028 7fff75b8 
           fsr      fir       fp
      00000000 00000000 00000000 
(gdb) disass 0x7fff7500 0x7fff7600
Dump of assembler code from 0x7fff7500 to 0x7fff7600:
0x7fff7500:	0xc2009d
0x7fff7504:	0x10000e8
0x7fff7508:	0x11a0110
0x7fff750c:	0x990121
0x7fff7510:	slti	t9,s6,32304
0x7fff7514:	tltu	a0,t9,0x2
0x7fff7518:	slti	t9,s6,32304
0x7fff751c:	0x442c88
0x7fff7520:	nop
0x7fff7524:	nop
0x7fff7528:	nop
0x7fff752c:	nop
0x7fff7530:	b	0x7ffed734
0x7fff7534:	nop
0x7fff7538:	nop
0x7fff753c:	slti	t8,s6,-8108
0x7fff7540:	nop
0x7fff7544:	sllv	zero,zero,zero
0x7fff7548:	sll	zero,zero,0x2
0x7fff754c:	0x7fff7878
0x7fff7550:	sra	zero,zero,0x0
0x7fff7554:	sd	ra,-1(ra)
0x7fff7558:	b	0x7fff393c
0x7fff755c:	b	0x7ffed760
0x7fff7560:	teq	v0,a0,0xa9
0x7fff7564:	nop
0x7fff7568:	nop
0x7fff756c:	nop
0x7fff7570:	nop
0x7fff7574:	nop
0x7fff7578:	b	0x7ffed77c
0x7fff757c:	nop
0x7fff7580:	nop
0x7fff7584:	b	0x7ffed788
0x7fff7588:	0x7fff75a0
0x7fff758c:	0x1
0x7fff7590:	b	0x7fff2174
0x7fff7594:	0x7fff7804
0x7fff7598:	slti	t9,s6,32304
0x7fff759c:	0x475718
0x7fff75a0:	li	v0,4119
0x7fff75a4:	syscall
0x7fff75a8:	slti	t8,s6,-8108
0x7fff75ac:	lb	a0,-3053(zero)
0x7fff75b0:	slti	t5,s6,9620
0x7fff75b4:	nop
0x7fff75b8:	nop
0x7fff75bc:	nop
0x7fff75c0:	b	0x7fff8cb4
0x7fff75c4:	nop
0x7fff75c8:	sllv	zero,zero,zero
0x7fff75cc:	nop
0x7fff75d0:	nop
0x7fff75d4:	nop
0x7fff75d8:	sra	zero,zero,0x0
0x7fff75dc:	nop
0x7fff75e0:	0x7fff7878
0x7fff75e4:	nop
0x7fff75e8:	sll	zero,zero,0x2
0x7fff75ec:	nop
0x7fff75f0:	0x1
0x7fff75f4:	nop
0x7fff75f8:	mult	zero,zero
0x7fff75fc:	nop
End of assembler dump.
(gdb) quit

--------------070804020907010709090500--


From ralf@linux-mips.org Wed Aug  6 12:55:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 12:55:49 +0100 (BST)
Received: from p508B618D.dip.t-dialin.net ([IPv6:::ffff:80.139.97.141]:36534
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225280AbTHFLzq>; Wed, 6 Aug 2003 12:55:46 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h76BtapR031840;
	Wed, 6 Aug 2003 13:55:36 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h76BtWqj031839;
	Wed, 6 Aug 2003 13:55:32 +0200
Date: Wed, 6 Aug 2003 13:55:31 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
Message-ID: <20030806115531.GA12161@linux-mips.org>
References: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02> <3F30DFB7.8030304@ict.ac.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F30DFB7.8030304@ict.ac.cn>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2990
X-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, Aug 06, 2003 at 07:00:07PM +0800, Fuxin Zhang wrote:

>  And here I have a question for Mr. Adam: original linux code use 
> 'Writeback_Inv_D"
> and "Hit_Invalidate_I",not "Writeback_D" and "Hit_Invalidate_I",could it 
> lead to the
> problem?

No.  To synchronize the D-cache and I-cache it's irrelevant if you
invalidate the D-cache or not.

> BTW:
>   a silly question: how can i make my email show up pretier? I find 
> that the mailing list
> often break my lines very badly. I feel guilty for that:) I am using 
> mozilla composer,the
> original linebreaks are manually inserted(hit enter when i feel it is 
> long enough).

Format your email with hard breaks to about 75 columns.  75 columns
because god made vt100 with 80 columns so that leaves a bit of space for
quoting your mail nicely.

Now for your register dumps and information:

> (gdb) info reg
[...]
>            t8       t9       k0       k1       gp       sp       s8       ra
> R24  00000000 00000000 00000000 00000000 1000d880 7fff7590 00000003 7fff75a0
>            sr       lo       hi      bad    cause       pc
>      a004f413 000001b0 00000000 8009c6a0 80000028 7fff75b8
[...]

> 0x7fff75a0:     li      v0,4119
> 0x7fff75a4:     syscall

So the pc is pointing just after the trampoline which suspiciously looks
like the return of an old bug.  Could your application be doing something
unusual such as forking from a signal handler or similar?  The scenario
is about

 - kernel installs signal trampoline on stack
 - kernel forks.  Now the signal trampoline installed in the first step
   resides on a copy-on-write page.
 - newly created process touches the cow page, thereby resulting in
   breaking of the cow page.  Now parent and child have their own copy
   of the page.  BUT: flush_cache_page() doesn't properly flush this page.
 - Parent executes again on the copy of the page for which caches have
   not been flushed proplerly in the previous step, thereby failing to
   execute the trampoline - crash.

  Ralf

From fxzhang@ict.ac.cn Wed Aug  6 13:53:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 13:53:11 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:27572
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225280AbTHFMxH>; Wed, 6 Aug 2003 13:53:07 +0100
Received: (qmail 10865 invoked from network); 6 Aug 2003 12:47:53 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by mail.ict.ac.cn with SMTP; 6 Aug 2003 12:47:53 -0000
Message-ID: <3F30FA1E.3000002@ict.ac.cn>
Date: Wed, 06 Aug 2003 20:52:46 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
References: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02> <3F30DFB7.8030304@ict.ac.cn> <20030806115531.GA12161@linux-mips.org>
In-Reply-To: <20030806115531.GA12161@linux-mips.org>
Content-Type: text/plain; charset=gb18030; 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: 2991
X-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



Ralf Baechle wrote:

>On Wed, Aug 06, 2003 at 07:00:07PM +0800, Fuxin Zhang wrote:
>
>  
>
>> And here I have a question for Mr. Adam: original linux code use 
>>'Writeback_Inv_D"
>>and "Hit_Invalidate_I",not "Writeback_D" and "Hit_Invalidate_I",could it 
>>lead to the
>>problem?
>>    
>>
>
>No.  To synchronize the D-cache and I-cache it's irrelevant if you
>invalidate the D-cache or not.
>  
>
I think so. Just in case the hardware is doing something strange:)

>  
>
>>BTW:
>>  a silly question: how can i make my email show up pretier? I find 
>>that the mailing list
>>often break my lines very badly. I feel guilty for that:) I am using 
>>mozilla composer,the
>>original linebreaks are manually inserted(hit enter when i feel it is 
>>long enough).
>>    
>>
>
>Format your email with hard breaks to about 75 columns.  75 columns
>because god made vt100 with 80 columns so that leaves a bit of space for
>quoting your mail nicely.
>
Thanks:)

>
>Now for your register dumps and information:
>  
>
>>           sr       lo       hi      bad    cause       pc
>>     a004f413 000001b0 00000000 8009c6a0 80000028 7fff75b8
>>    
>>
>[...]
>  
>
>>0x7fff75a0:     li      v0,4119
>>0x7fff75a4:     syscall
>>    
>>
>
>So the pc is pointing just after the trampoline which suspiciously looks
>like the return of an old bug.  Could your application be doing something
>unusual such as forking from a signal handler or similar?  The scenario
>
I am not sure. It is stardard X distribution from debian-woody. Fairly 
easy to reproduce,just move the mouse
around and click here and there then it would die. Will check this 
later,but I think such a giant as Xserver
won't fork frequently.

>is about
>
> - kernel installs signal trampoline on stack
> - kernel forks.  Now the signal trampoline installed in the first step
>   resides on a copy-on-write page.
> - newly created process touches the cow page, thereby resulting in
>   breaking of the cow page.  Now parent and child have their own copy
>   of the page.  BUT: flush_cache_page() doesn't properly flush this page
>  
>
> - Parent executes again on the copy of the page for which caches have
>
If the new process touch the cow page first,shouldn't it get a new page 
and leave the original page for parent?
If so,the parent should be able to see the trampoline content from 
icache anyway(either L2 or memory should
have the value),though the child may not?

>   not been flushed proplerly in the previous step, thereby failing to
>   execute the trampoline - crash.
>
RM7000 has 16k 4-way set-associated primary caches,which are supposed to 
have no cache aliasing problem

Bad news:

oops again:(  while true; do fsck -y -f /dev/hda4 ; done 

after about 5 succeeded run.
So still some  problems lurking somewhere.

It seems I have to switch some hardware...

>
>  Ralf
>
>
>
>  
>


From ralf@linux-mips.org Wed Aug  6 15:45:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 15:45:24 +0100 (BST)
Received: from p508B618D.dip.t-dialin.net ([IPv6:::ffff:80.139.97.141]:37056
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225280AbTHFOpS>; Wed, 6 Aug 2003 15:45:18 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h76EjFpR002639;
	Wed, 6 Aug 2003 16:45:15 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h76EjEAE002638;
	Wed, 6 Aug 2003 16:45:14 +0200
Date: Wed, 6 Aug 2003 16:45:14 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
Message-ID: <20030806144513.GB12161@linux-mips.org>
References: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02> <3F30DFB7.8030304@ict.ac.cn> <20030806115531.GA12161@linux-mips.org> <3F30FA1E.3000002@ict.ac.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F30FA1E.3000002@ict.ac.cn>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2992
X-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, Aug 06, 2003 at 08:52:46PM +0800, Fuxin Zhang wrote:

> I am not sure. It is stardard X distribution from debian-woody. Fairly 
> easy to reproduce,just move the mouse
> around and click here and there then it would die. Will check this 
> later,but I think such a giant as Xserver won't fork frequently.

The scenario I was describing was just how we did originally discover the
bug.  Supposedly that was fixed but your register dump and dissassembly
show the exact fingerprint of that old problem, so I though I should
describe it in the hope it's going to help you.

> If the new process touch the cow page first,shouldn't it get a new page 
> and leave the original page for parent?
> If so,the parent should be able to see the trampoline content from 
> icache anyway(either L2 or memory should
> have the value),though the child may not?

RM7000 has a physically indexed cache.  That means if the copy of the
page wasn't explicitly or implicitly written back to L2 the process
whichever ends up with the copy of the page might fetch stale instructions
from memory - boom.

> >  not been flushed proplerly in the previous step, thereby failing to
> >  execute the trampoline - crash.
> >
> RM7000 has 16k 4-way set-associated primary caches,which are supposed to 
> have no cache aliasing problem

The described scenario is not an aliasing problem; it's the case where the
copy of the cow page hasn't properly been flushed at all.  When we
isolated the bug was that neither flush_page_to_ram() nor flush_cache_page()
were flushing the cache.  I suspect your case must be something fairly
similar.

  Ralf

From fxzhang@ict.ac.cn Wed Aug  6 16:04:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 16:04:42 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:19895
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225284AbTHFPEk>; Wed, 6 Aug 2003 16:04:40 +0100
Received: (qmail 9200 invoked from network); 6 Aug 2003 14:59:25 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by mail.ict.ac.cn with SMTP; 6 Aug 2003 14:59:25 -0000
Message-ID: <3F3118F3.1030001@ict.ac.cn>
Date: Wed, 06 Aug 2003 23:04:19 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
References: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02> <3F30DFB7.8030304@ict.ac.cn> <20030806115531.GA12161@linux-mips.org> <3F30FA1E.3000002@ict.ac.cn> <20030806144513.GB12161@linux-mips.org>
In-Reply-To: <20030806144513.GB12161@linux-mips.org>
Content-Type: text/plain; charset=gb18030; 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: 2993
X-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



Ralf Baechle wrote:

>>If the new process touch the cow page first,shouldn't it get a new page 
>>and leave the original page for parent?
>>If so,the parent should be able to see the trampoline content from 
>>icache anyway(either L2 or memory should
>>have the value),though the child may not?
>>    
>>
>
>RM7000 has a physically indexed cache.  That means if the copy of the
>page wasn't explicitly or implicitly written back to L2 the process
>whichever ends up with the copy of the page might fetch stale instructions
>from memory - boom.
>
>  
>
>>> not been flushed proplerly in the previous step, thereby failing to
>>> execute the trampoline - crash.
>>>
>>>      
>>>
>>RM7000 has 16k 4-way set-associated primary caches,which are supposed to 
>>have no cache aliasing problem
>>    
>>
>
>The described scenario is not an aliasing problem; it's the case where the
>copy of the cow page hasn't properly been flushed at all.  When we
>isolated the bug was that neither flush_page_to_ram() nor flush_cache_page()
>were flushing the cache.  I suspect your case must be something fairly
>  
>
After cache rewrite,flush_page_to_ram is null; and in this case 
flush_cache_page
 do nothing for a stack page. (It flushes only when has_dc_aliases or 
exec set).
So  the  one use  the new copy will  have problem ?!  Am I missing 
something?

Thank you very much, great Ralf:).

>similar.
>
>  Ralf
>
>
>  
>


From jsun@mvista.com Wed Aug  6 17:59:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 17:59:54 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:63223 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225285AbTHFQ7u>;
	Wed, 6 Aug 2003 17:59:50 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h76Gxk419084;
	Wed, 6 Aug 2003 09:59:46 -0700
Date: Wed, 6 Aug 2003 09:59:46 -0700
From: Jun Sun <jsun@mvista.com>
To: Dmitry Antipov <dmitry.antipov@mail.ru>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: IT8172G on-board timers
Message-ID: <20030806095946.C18963@mvista.com>
References: <3F2FB360.9040005@mail.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3F2FB360.9040005@mail.ru>; from dmitry.antipov@mail.ru on Tue, Aug 05, 2003 at 05:38:40PM +0400
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2994
X-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, Aug 05, 2003 at 05:38:40PM +0400, Dmitry Antipov wrote:
> Hello all,
> 
>  I'm working with IT8172-based MIPS board and want to use one of (or may 
> be both) on-board timers.
> For my purposes, it's required to generate irq from timer rarely, for 
> example, each 1 sec, or each 5 sec
> or so. (The usage of Linux timer interface (init_timer() etc...) is 
> forbidden

Using linux timer seems perfect for the need.  Why not?  For an example
of using timer you can take a look of my real time test suite

http://linux.junsun.net/preemp-test/

> , and I don't want to touch
> system timer to avoid the potential damage for basic timekeeping, 
> scheduling, etc.). I have two problems:
> - timer backward counter is 16-bit wide and reaches zero too fast, even 
> starting from 0xffff;
> - timer input clock may be one of CPU clock, CPU clock /4, CPU clock/8 
> or CPU  clock /16, which looks
>    very fast too
> So, the minimum interrupt frequency from both timers is 96 ints/HZ (with 
> TCR0.PST0 is 0 and
> TCVR0 is 0xffff) and the maximum is around 150000 ints/HZ. Even the 
> minimum is too large for me...
>

You can write a driver that "accumlates" the interrupts until a desired
duration is reached before it actually does anything useful.

Jun

From ranjanp@efi.com Wed Aug  6 20:08:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 20:08:45 +0100 (BST)
Received: from mail2.efi.com ([IPv6:::ffff:192.68.228.89]:15886 "EHLO
	fcexgw02.efi.internal") by linux-mips.org with ESMTP
	id <S8225281AbTHFTIm>; Wed, 6 Aug 2003 20:08:42 +0100
Received: from FCEXBH02.efi.com ([10.3.12.13]) by fcexgw02 with InterScan Messaging Security Suite; Wed, 06 Aug 2003 12:08:11 -0700
Received: by fcexbh02.efi.com with Internet Mail Service (5.5.2656.59)
	id <P5ZQGAWY>; Wed, 6 Aug 2003 12:08:11 -0700
Message-ID: <D9F6B9DABA4CAE4B92850252C52383AB079683A5@ex-eng-corp.efi.com>
From: Ranjan Parthasarathy <ranjanp@efi.com>
To: 'Michael' <trott@bigpond.net.au>, linux-mips@linux-mips.org
Subject: RE: debuging problems
Date: Wed, 6 Aug 2003 12:08:06 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <ranjanp@efi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2995
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ranjanp@efi.com
Precedence: bulk
X-list: linux-mips

You seem to be having branches in jump delay slots. Also there are some
loads in delay slots which I think might not be intentional. You might want
to check these.

e.g.
load in a branch/jump delay slot ( intentional ? )
j r1

cr:   li $13,0       #      clear line number

e.g.
branch in an jump delay slot (?)
j r2

r3:   bne $19,$10,exit      #       branch if line total != magic number

Thanks

Ranjan

-----Original Message-----
From: Michael [mailto:trott@bigpond.net.au]
Sent: Tuesday, August 05, 2003 9:10 PM
To: linux-mips@linux-mips.org
Subject: debuging problems


i have written a mips program to verify if a given input is a magic square,

a magic square is a n*n matrix whose values are from 1..n^2, and each
row/column diagonal gives the same sum, this sum is know as the magic
number.

All my program does is go through and sum each of the rows then each of the
columns,  at every stage the sum of the row or column in question is
compared to the magic number, if not equal then not valid magic square. the
formula is given in my doco.

im having problems working out what the actual  problem is. I've completely
coded it and spent alot of time steping through it but i cant see any
problems. regardless of the input, the result is always negative.

just wondering has anyone got any suggestions, any help would be greatly
appreicated :)

ive pasted my program at the bottom of this,

thanks everyone

michael

_______________________________________________________________



#      Program Name:      Magic Square Verifier
#
#      Author:                 Michael
#
#                       The purpose of this program is to determine whether
or not
#                       a given input is a valid magic square.
#
#                       The start address for the matrix is to be given in
$8, with
#                       the size of the matrix supplied in $9. Major row
#                       representation must be used to store the matrix
values.
#
#                       At completeion of the program, $11 will store the
#                       result of the program. if $11 == 1, then input was a
#                       valid magic square, if $11 == 0, the input was not a
valid
#                       magic square.
#
#                       for more details, plese consult the attached program
#                       description file




      .text

main: li $11,0             #      is magic square = 0
      li $12,2             #      temporary
      li $13,0             #      Line number
      li $14,0             #      temporary
      li $16,0             #      Line position
      li $17,0             #      start address + offset
      li $18,4             #      constant 4
      li $19,0             #      Line total


                              #       Calculation of magic number for
specified n
      mul $10,$9,$9         #      n^2
      addi $10,$10,1         #      (n^2)+1
      mul $10,$10,$9        #      ((n^2)+1)n
      divu $10,$10,$12       #      (((n^2)+1)n)/2 == magic_number
      addi $15,$9,1          #      n+1

r1:   beq $13,$9,cr         #      branch if line# == n

r2:   beq $16,$9,r3         #       branch when line_pos == n


      mul $12,$13,$9        #      line# . n
      add $12,$12,$16       #      (line # . n)+ line_pos
      mul $12,$12,$18       #      ((line # . n)+ line_pos)4
      add $17,$8,$12        #      start address + offset
      lw $23, 0($17)       #       load word, viz[i], into $17
      add $19,$19,$23       #       line_total = line_total + viz[i]
      addi $16,$16,1         #      line_position ++
      j r2

r3:   bne $19,$10,exit      #       branch if line total != magic number
      addi $13,$13,1         #      line# ++
      li $16,0       #       set line_pos
      j r1

cr:   li $13,0       #      clear line number
      li $16,0       #      clear line position
      li $19,0       #      clear line total

c1:   beq $13,$9,sum       #      branch if line# == n

c2:   beq $16,$9,c3         #      branch if line# == n


      mul $12,$9,$18        #      n . 4
      mul $12,$12,$16       #      (n . 4) . line_position
      mul $14,$13,$18       #       line# . 4
      add $12,$12,$14       #      ((n . 4) . line_position)+( line# . 4)
      add $17,$12,$8        #      start address + offset
      lw $23,0($17)        #       load word, viz[i], into $17
      add $19,$19,$23       #      start address + offset
      addi $16,$16,1         #       line_total = line_total + viz[i]
      j c2

c3:   bne $19,$10,exit      #      branch if line_total != magic_number
      addi $13,$13,1         #      line# ++
      li $16,0       #      clear line _pos
      j c1

sum:  li $12,0
      li $14,0
      add $17,$8,$0

s1:   beq $12,$9,s2         #       branch if counter == n
      lw $23,0($17)        #      load word, viz[i], into $17
      add $14,$14,$23       #      seq_total = seq_total +  viz[i]
      addi $17,$17,4         #      viz[i] = viz[i + 1]
      addi $12,$12,1         #      counter ++
      j s1

s2:   li $16,0       #       total
      li $19,1       #      i of n


s3:   beq $19,$15,s4        #      branch if (i of n ) == (n + 1)
      add $16,$16,$19       #      total = total +  (i of n )
      addi $19,$19,1         #      (i of n ) ++

s4:   bne $16,$14,exit

dc:   li $12,0
      li $13,0
      li $16,0
      li $19,0

      mul $14,$15,$18       #     (n + 1) 4
      add $17,$8,$0         #     copy start addr to $17

d1:   beq $13,$9,d2         #      branch if line# == n

      lw $23,0($17)        #       load word, viz[i], into $17
      add $19,$19,$23       #       diag_total = diag_total + viz[i]
      add $17,$17,$14       #       viz[i] = viz[i+1]
      addi $13,$13,1         #       line# ++
      j d1

d2:   bne $19,$10,exit      #       branch if diagonal_total !=
magic_number
      j complete                #       else complete, therefore input is
magic square


complete:      li $11,1

exit:




From michael_pruznick@mvista.com Wed Aug  6 21:12:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 21:12:41 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:56569 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225281AbTHFUMj>;
	Wed, 6 Aug 2003 21:12:39 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id NAA14671
	for <linux-mips@linux-mips.org>; Wed, 6 Aug 2003 13:12:36 -0700
Message-ID: <3F316133.3FF2C9EC@mvista.com>
Date: Wed, 06 Aug 2003 14:12:35 -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: linux-mips@linux-mips.org
Subject: PATCH:2.4:CONFIG_CMDLINE_BOOL
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: 2996
X-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

The patch at the bottom of this message adds support so that
a board can choose to have a command line specified in
the .config file or hard-coded. This is similar to what is
in the ppc tree.  All this patch does is create a config
question and store the info in the config file.  It is up
to each board to read or not read this info.

Here is one example of its use:
>#ifndef CONFIG_CMDLINE_BOOL
>#define CONFIG_CMDLINE "console=ttyS0,38400 ip=any root=nfs rw"
>#endif
>char arcs_cmdline[CL_SIZE] = CONFIG_CMDLINE;

Dynamic setting of args like this will still work with out
any changes. 
>#ifdef CONFIG_NE2000
>        argptr = prom_getcmdline();
>        if ((argptr = strstr(argptr, "ne_eth=")) == NULL) { 
>                argptr = prom_getcmdline();
>                strcat(argptr, " ne_eth=0x6020280,29");
>        }
>#endif

To you this you may need to modify this fn keeping two
things in mind.  A) setting *arcs_cmdline to 0 unconditionally
will clear the .config/hard-coded default.  B) If the board
supports a f/w command line string that should probably
over-ride and .config/hard-coded default.
>void __init
>prom_init_cmdline(int argc, char **argv)
>{
>       int i;  /* Always ignore the "-c" at argv[0] */
>
>       /* ignore all built-in args if any f/w args given */
>       if (argc > 1) {
>               *arcs_cmdline = '\0';
>       }
>       for (i = 1; i < argc; i++) {
>               if (i != 1) {
>                       strcat(arcs_cmdline, " ");
>               }
>               strcat(arcs_cmdline, argv[i]);
>       }
>}



Index: config-shared.in
===================================================================
RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v
retrieving revision 1.1.2.80
diff -u -r1.1.2.80 config-shared.in
--- config-shared.in    5 Aug 2003 11:13:39 -0000       1.1.2.80
+++ config-shared.in    6 Aug 2003 19:52:41 -0000
@@ -891,6 +891,11 @@
 fi
 endmenu
 
+bool 'Default kernel loader arguments' CONFIG_CMDLINE_BOOL
+if [ "$CONFIG_CMDLINE_BOOL" = "y" ] ; then
+   string 'Initial kernel command string' CONFIG_CMDLINE ""
+fi
+
 source drivers/mtd/Config.in
 
 source drivers/parport/Config.in

From jsun@mvista.com Wed Aug  6 22:01:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 22:01:53 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:55283 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225281AbTHFVBv>;
	Wed, 6 Aug 2003 22:01:51 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h76L1nh30035;
	Wed, 6 Aug 2003 14:01:49 -0700
Date: Wed, 6 Aug 2003 14:01:49 -0700
From: Jun Sun <jsun@mvista.com>
To: Michael Pruznick <michael_pruznick@mvista.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: PATCH:2.4:CONFIG_CMDLINE_BOOL
Message-ID: <20030806140149.G18963@mvista.com>
References: <3F316133.3FF2C9EC@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3F316133.3FF2C9EC@mvista.com>; from michael_pruznick@mvista.com on Wed, Aug 06, 2003 at 02:12:35PM -0600
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: 2997
X-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, Aug 06, 2003 at 02:12:35PM -0600, Michael Pruznick wrote:
> The patch at the bottom of this message adds support so that
> a board can choose to have a command line specified in
> the .config file or hard-coded. This is similar to what is
> in the ppc tree.  All this patch does is create a config
> question and store the info in the config file.  It is up
> to each board to read or not read this info.
>

This is a good feature.

However, I think it is better to 

1) always have CONFIG_CMDLINE defined
2) for boards that don't use it, it is "" (NULL string)
3) we need to modify all boards' prom_init routines so that they
   respect this config. 
4) (optionally) some ugly static ctrcpy of cmdline can now be
   moved to use config options

Jun

From ralf@linux-mips.org Wed Aug  6 23:30:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 23:30:17 +0100 (BST)
Received: from p508B618D.dip.t-dialin.net ([IPv6:::ffff:80.139.97.141]:21468
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225281AbTHFWaP>; Wed, 6 Aug 2003 23:30:15 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h76MUApR011881;
	Thu, 7 Aug 2003 00:30:10 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h76MU9UG011880;
	Thu, 7 Aug 2003 00:30:09 +0200
Date: Thu, 7 Aug 2003 00:30:09 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
Message-ID: <20030806223009.GA2669@linux-mips.org>
References: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02> <3F30DFB7.8030304@ict.ac.cn> <20030806115531.GA12161@linux-mips.org> <3F30FA1E.3000002@ict.ac.cn> <20030806144513.GB12161@linux-mips.org> <3F3118F3.1030001@ict.ac.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F3118F3.1030001@ict.ac.cn>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2998
X-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, Aug 06, 2003 at 11:04:19PM +0800, Fuxin Zhang wrote:

> After cache rewrite,flush_page_to_ram is null; and in this case 
> flush_cache_page
> do nothing for a stack page. (It flushes only when has_dc_aliases or 
> exec set).
> So  the  one use  the new copy will  have problem ?!  Am I missing 
> something?

The stack page contains the trampoline so it must be marked executable,
so on an RM7000 flush_dcache_page must flush both the D-cache and
I-cache.

  Ralf

From michael_pruznick@mvista.com Wed Aug  6 23:50:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Aug 2003 23:50:23 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:1522 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225281AbTHFWuV>;
	Wed, 6 Aug 2003 23:50:21 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA21379
	for <linux-mips@linux-mips.org>; Wed, 6 Aug 2003 15:50:19 -0700
Message-ID: <3F31862A.F2162035@mvista.com>
Date: Wed, 06 Aug 2003 16:50:18 -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: linux-mips@linux-mips.org
Subject: PATCH:2.6:makefile/vmlinux.srec
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: 2999
X-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

Jun Sun wrote:
> the make srec patch looks good to me.  I will take care of it.
> Also, please post patches for both branches whenever possible.

Here is the 2.6 version of the 2.4 srec build patch:

cvs diff -uN arch/mips/Makefile arch/mips/boot/Makefile
Index: arch/mips/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/Makefile,v
retrieving revision 1.131
diff -u -r1.131 Makefile
--- arch/mips/Makefile  30 Jul 2003 12:32:17 -0000      1.131
+++ arch/mips/Makefile  4 Aug 2003 23:59:12 -0000
@@ -531,6 +531,9 @@
 vmlinux.ecoff vmlinux.rm200: vmlinux
        +@$(call makeboot,$@)
 
+vmlinux.srec: vmlinux
+       +@$(call makeboot,$@)
+
 CLEAN_FILES += vmlinux.ecoff \
               vmlinux.rm200.tmp \
               vmlinux.rm200
Index: arch/mips/boot/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/boot/Makefile,v
retrieving revision 1.22
diff -u -r1.22 Makefile
--- arch/mips/boot/Makefile     9 Mar 2003 13:58:13 -0000       1.22
+++ arch/mips/boot/Makefile     4 Aug 2003 23:59:12 -0000
@@ -22,7 +22,7 @@
 drop-sections  = .reginfo .mdebug .comment .note
 strip-flags    = $(addprefix --remove-section=,$(drop-sections))
 
-all: vmlinux.ecoff addinitrd
+all: vmlinux.ecoff vmlinux.srec addinitrd
 
 vmlinux.rm200: vmlinux
        $(OBJCOPY) \
@@ -37,6 +37,9 @@
 $(obj)/elf2ecoff: $(obj)/elf2ecoff.c
        $(HOSTCC) -o $@ $^
 
+vmlinux.srec:  vmlinux
+       $(OBJCOPY) -S -O srec $(strip-flags) vmlinux $(obj)/vmlinux.srec
+
 $(obj)/addinitrd: $(obj)/addinitrd.c
        $(HOSTCC) -o $@ $^
 
@@ -47,5 +50,6 @@
               elf2ecoff \
               vmlinux.ecoff \
               vmlinux.rm200 \
+              vmlinux.srec \
               zImage.tmp \
               zImage

From jefflinux@hotmail.com Thu Aug  7 02:44:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Aug 2003 02:44:41 +0100 (BST)
Received: from law15-f97.law15.hotmail.com ([IPv6:::ffff:64.4.23.97]:45578
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225281AbTHGBoj>; Thu, 7 Aug 2003 02:44:39 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 6 Aug 2003 18:44:30 -0700
Received: from 202.145.53.89 by lw15fd.law15.hotmail.msn.com with HTTP;
	Thu, 07 Aug 2003 01:44:30 GMT
X-Originating-IP: [202.145.53.89]
X-Originating-Email: [jefflinux@hotmail.com]
From: "Palm Palm" <jefflinux@hotmail.com>
To: linux-mips@linux-mips.org
Subject: kernel 2.4.21 for VR4181A
Date: Thu, 07 Aug 2003 01:44:30 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=big5; format=flowed
Message-ID: <Law15-F979BekWo76Ua00033a5d@hotmail.com>
X-OriginalArrivalTime: 07 Aug 2003 01:44:30.0846 (UTC) FILETIME=[71EFE9E0:01C35C85]
Return-Path: <jefflinux@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: 3000
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jefflinux@hotmail.com
Precedence: bulk
X-list: linux-mips

Dear All,
    Is there anyone try Kernel 2.4.21 for VR4181A ?
We try to port VR4181A from 2.4.2 to 2.4.21 but it always failed after 
kernel mount the root.
We try to use ramdisk, jffs2-root, cramfs-root, they are all failed after 
mount.

PalmPalm

_________________________________________________________________
�Q妬�R�Hユ�Bね�H<br>MSN �u�Wユね�Gパ Match.com 苅�僉A���@�紐岬��w�鍼砂u�Wユ
ね�A鞍 http://match.msn.com.tw 


From trott@bigpond.net.au Thu Aug  7 03:01:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Aug 2003 03:01:14 +0100 (BST)
Received: from mta08bw.bigpond.com ([IPv6:::ffff:144.135.24.137]:61689 "EHLO
	mta08bw.bigpond.com") by linux-mips.org with ESMTP
	id <S8225281AbTHGCBJ>; Thu, 7 Aug 2003 03:01:09 +0100
Received: from titan ([144.135.24.72]) by mta08bw.email.bigpond.com
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with SMTP id <0HJ800B2D897RU@mta08bw.email.bigpond.com> for
 linux-mips@linux-mips.org; Thu, 07 Aug 2003 12:00:43 +1000 (EST)
Received: from cpe-203-45-209-27.qld.bigpond.net.au ([203.45.209.27])
 by bwmam02bpa.bigpond.com(MAM REL_3_3_2c 17/758429); Thu,
 07 Aug 2003 12:00:43 +0000
Date: Thu, 07 Aug 2003 12:00:45 +1000
From: Michael <trott@bigpond.net.au>
Subject: Re: debuging problems
To: Ranjan Parthasarathy <ranjanp@efi.com>, linux-mips@linux-mips.org
Reply-to: Michael <trott@bigpond.net.au>
Message-id: <02a901c35c87$b6d3a590$6400a8c0@titan>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <D9F6B9DABA4CAE4B92850252C52383AB079683A5@ex-eng-corp.efi.com>
Return-Path: <trott@bigpond.net.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: 3001
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: trott@bigpond.net.au
Precedence: bulk
X-list: linux-mips

Hi Ranjan

im not sure what you mean when you say load in a branch/jump delay slot.

im guessing thats whats causing the irregular behavior, the way i see it is
that  my 'bne' jump is never being executed, where this should be the
default behavior in the majority of inputs.



thanks for your help, its really appreicated :)

michael



----- Original Message ----- 
From: "Ranjan Parthasarathy" <ranjanp@efi.com>
To: "'Michael'" <trott@bigpond.net.au>; <linux-mips@linux-mips.org>
Sent: Thursday, August 07, 2003 5:08 AM
Subject: RE: debuging problems


> You seem to be having branches in jump delay slots. Also there are some
> loads in delay slots which I think might not be intentional. You might
want
> to check these.
>
> e.g.
> load in a branch/jump delay slot ( intentional ? )
> j r1
>
> cr:   li $13,0       #      clear line number
>
> e.g.
> branch in an jump delay slot (?)
> j r2
>
> r3:   bne $19,$10,exit      #       branch if line total != magic number
>
> Thanks
>
> Ranjan
>
> -----Original Message-----
> From: Michael [mailto:trott@bigpond.net.au]
> Sent: Tuesday, August 05, 2003 9:10 PM
> To: linux-mips@linux-mips.org
> Subject: debuging problems
>
>
> i have written a mips program to verify if a given input is a magic
square,
>
> a magic square is a n*n matrix whose values are from 1..n^2, and each
> row/column diagonal gives the same sum, this sum is know as the magic
> number.
>
> All my program does is go through and sum each of the rows then each of
the
> columns,  at every stage the sum of the row or column in question is
> compared to the magic number, if not equal then not valid magic square.
the
> formula is given in my doco.
>
> im having problems working out what the actual  problem is. I've
completely
> coded it and spent alot of time steping through it but i cant see any
> problems. regardless of the input, the result is always negative.
>
> just wondering has anyone got any suggestions, any help would be greatly
> appreicated :)
>
> ive pasted my program at the bottom of this,
>
> thanks everyone
>
> michael
>
> _______________________________________________________________
>
>
>
> #      Program Name:      Magic Square Verifier
> #
> #      Author:                 Michael
> #
> #                       The purpose of this program is to determine
whether
> or not
> #                       a given input is a valid magic square.
> #
> #                       The start address for the matrix is to be given in
> $8, with
> #                       the size of the matrix supplied in $9. Major row
> #                       representation must be used to store the matrix
> values.
> #
> #                       At completeion of the program, $11 will store the
> #                       result of the program. if $11 == 1, then input was
a
> #                       valid magic square, if $11 == 0, the input was not
a
> valid
> #                       magic square.
> #
> #                       for more details, plese consult the attached
program
> #                       description file
>
>
>
>
>       .text
>
> main: li $11,0             #      is magic square = 0
>       li $12,2             #      temporary
>       li $13,0             #      Line number
>       li $14,0             #      temporary
>       li $16,0             #      Line position
>       li $17,0             #      start address + offset
>       li $18,4             #      constant 4
>       li $19,0             #      Line total
>
>
>                               #       Calculation of magic number for
> specified n
>       mul $10,$9,$9         #      n^2
>       addi $10,$10,1         #      (n^2)+1
>       mul $10,$10,$9        #      ((n^2)+1)n
>       divu $10,$10,$12       #      (((n^2)+1)n)/2 == magic_number
>       addi $15,$9,1          #      n+1
>
> r1:   beq $13,$9,cr         #      branch if line# == n
>
> r2:   beq $16,$9,r3         #       branch when line_pos == n
>
>
>       mul $12,$13,$9        #      line# . n
>       add $12,$12,$16       #      (line # . n)+ line_pos
>       mul $12,$12,$18       #      ((line # . n)+ line_pos)4
>       add $17,$8,$12        #      start address + offset
>       lw $23, 0($17)       #       load word, viz[i], into $17
>       add $19,$19,$23       #       line_total = line_total + viz[i]
>       addi $16,$16,1         #      line_position ++
>       j r2
>
> r3:   bne $19,$10,exit      #       branch if line total != magic number
>       addi $13,$13,1         #      line# ++
>       li $16,0       #       set line_pos
>       j r1
>
> cr:   li $13,0       #      clear line number
>       li $16,0       #      clear line position
>       li $19,0       #      clear line total
>
> c1:   beq $13,$9,sum       #      branch if line# == n
>
> c2:   beq $16,$9,c3         #      branch if line# == n
>
>
>       mul $12,$9,$18        #      n . 4
>       mul $12,$12,$16       #      (n . 4) . line_position
>       mul $14,$13,$18       #       line# . 4
>       add $12,$12,$14       #      ((n . 4) . line_position)+( line# . 4)
>       add $17,$12,$8        #      start address + offset
>       lw $23,0($17)        #       load word, viz[i], into $17
>       add $19,$19,$23       #      start address + offset
>       addi $16,$16,1         #       line_total = line_total + viz[i]
>       j c2
>
> c3:   bne $19,$10,exit      #      branch if line_total != magic_number
>       addi $13,$13,1         #      line# ++
>       li $16,0       #      clear line _pos
>       j c1
>
> sum:  li $12,0
>       li $14,0
>       add $17,$8,$0
>
> s1:   beq $12,$9,s2         #       branch if counter == n
>       lw $23,0($17)        #      load word, viz[i], into $17
>       add $14,$14,$23       #      seq_total = seq_total +  viz[i]
>       addi $17,$17,4         #      viz[i] = viz[i + 1]
>       addi $12,$12,1         #      counter ++
>       j s1
>
> s2:   li $16,0       #       total
>       li $19,1       #      i of n
>
>
> s3:   beq $19,$15,s4        #      branch if (i of n ) == (n + 1)
>       add $16,$16,$19       #      total = total +  (i of n )
>       addi $19,$19,1         #      (i of n ) ++
>
> s4:   bne $16,$14,exit
>
> dc:   li $12,0
>       li $13,0
>       li $16,0
>       li $19,0
>
>       mul $14,$15,$18       #     (n + 1) 4
>       add $17,$8,$0         #     copy start addr to $17
>
> d1:   beq $13,$9,d2         #      branch if line# == n
>
>       lw $23,0($17)        #       load word, viz[i], into $17
>       add $19,$19,$23       #       diag_total = diag_total + viz[i]
>       add $17,$17,$14       #       viz[i] = viz[i+1]
>       addi $13,$13,1         #       line# ++
>       j d1
>
> d2:   bne $19,$10,exit      #       branch if diagonal_total !=
> magic_number
>       j complete                #       else complete, therefore input is
> magic square
>
>
> complete:      li $11,1
>
> exit:
>
>
>
>



From anemo@mba.ocn.ne.jp Thu Aug  7 11:02:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Aug 2003 11:02:19 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:3600
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225208AbTHGKCR>; Thu, 7 Aug 2003 11:02:17 +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; 7 Aug 2003 10:02: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 h77A23DV092873
	for <linux-mips@linux-mips.org>; Thu, 7 Aug 2003 19:02:03 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 07 Aug 2003 19:03:30 +0900 (JST)
Message-Id: <20030807.190330.26271096.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org
Subject: load/store address overflow on binutils 2.14
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3002
X-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

I'm trying binutils 2.14 (and binutils 2.14.90.0.5).  These versions
can not compile this inctruction.

	lw	$2, 0x80000000

$ mips-linux-gcc -c foo.s
b.S: Assembler messages:
foo.S:1: Error: load/store address overflow (max 32 bits)

Using such an immediate address for load instructions is legal?  I
found the error message in tc-mips.c and it looks like something
related to 64bit ABIs, but I just want to compile 32bit (standalone)
program.

Is this code really needed for 32bit ABI?

binutils-2.14/gas/config/tc-mips.c:6297
 	  else if (offset_expr.X_op == O_constant
 		   && !HAVE_64BIT_ADDRESS_CONSTANTS
 		   && !IS_SEXT_32BIT_NUM (offset_expr.X_add_number))
 	    as_bad (_("load/store address overflow (max 32 bits)"));

---
Atsushi Nemoto

From janip@dnmi.no Thu Aug  7 13:23:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Aug 2003 13:23:53 +0100 (BST)
Received: from smtp1.oslo.dnmi.no ([IPv6:::ffff:128.39.62.241]:62915 "EHLO
	smtp1.oslo.dnmi.no") by linux-mips.org with ESMTP
	id <S8225208AbTHGMXv>; Thu, 7 Aug 2003 13:23:51 +0100
Received: from amavis by smtp1.oslo.dnmi.no with scanned-ok (Exim 3.35 #1)
	id 19kjnz-0004e7-00 (Debian); Thu, 07 Aug 2003 12:23:43 +0000
Received: from spray.oslo.dnmi.no [157.249.16.126] 
	by smtp1.oslo.dnmi.no with esmtp (Exim 3.35 #1)
	id 19kjnz-0004do-00 (Debian); Thu, 07 Aug 2003 12:23:43 +0000
Received: from 127.0.0.1 (ident=unknown) by spray.oslo.dnmi.no with
 esmtp (MasqMail 0.1.16) id 19kjny-2io-00; Thu, 07 Aug 2003 14:23:42
 +0200
To: linux-mips@linux-mips.org
Cc: pladsen@pvv.org
Subject: Yet another HOWTO for Debian on Indy
From: Jan Ivar Pladsen <janip@met.no>
Date: 07 Aug 2003 14:23:32 +0200
Message-ID: <878yq5wta3.fsf@spray.oslo.dnmi.no>
Lines: 13
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by AMaViS snapshot-20010714
Return-Path: <janip@dnmi.no>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3003
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: janip@met.no
Precedence: bulk
X-list: linux-mips

I've read much of the existing documentation for installing Linux on
Indy. 

I've now made a readable (to me :-) summary available on
http://www.pvv.org/~pladsen/Indy/HOWTO.html

-JI

-- 
<><        
A Perl,    
Gnu/Linux, 
MySQL-user 


From michael_pruznick@mvista.com Thu Aug  7 19:02:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Aug 2003 19:02:25 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:46318 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225208AbTHGSCW>;
	Thu, 7 Aug 2003 19:02:22 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA03973
	for <linux-mips@linux-mips.org>; Thu, 7 Aug 2003 11:02:09 -0700
Message-ID: <3F329421.D86566A9@mvista.com>
Date: Thu, 07 Aug 2003 12:02:09 -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: linux-mips@linux-mips.org
Subject: Re: PATCH:2.4:CONFIG_BINFMT_IRIX
References: <3F2FF67D.8B0C2DFB@mvista.com>
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: 3004
X-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

This seams to be a better way to eliminate the irix
stuff from being automatically included when switching
a board from le to be.

I tested this with config, oldconfig, menuconfig
and xconfig and in all cases the default for
CONFIG_BINFMT_IRIX is now N.


2.4
Index: arch/mips/defconfig
===================================================================
RCS file: /home/cvs/linux/arch/mips/defconfig,v
retrieving revision 1.117.2.52
diff -u -r1.117.2.52 defconfig
--- arch/mips/defconfig 16 Jul 2003 19:27:30 -0000      1.117.2.52
+++ arch/mips/defconfig 7 Aug 2003 17:44:27 -0000
@@ -112,7 +112,7 @@
 # General setup
 #
 # CONFIG_CPU_LITTLE_ENDIAN is not set
-CONFIG_BINFMT_IRIX=y
+# CONFIG_BINFMT_IRIX is not set
 CONFIG_ARC_CONSOLE=y
 # CONFIG_IP22_EISA is not set
 CONFIG_NET=y


2.6
Index: arch/mips/defconfig
===================================================================
RCS file: /home/cvs/linux/arch/mips/defconfig,v
retrieving revision 1.211
diff -u -r1.211 defconfig
--- arch/mips/defconfig 31 Jul 2003 17:28:07 -0000      1.211
+++ arch/mips/defconfig 7 Aug 2003 17:55:32 -0000
@@ -130,7 +130,7 @@
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
 CONFIG_TRAD_SIGNALS=y
-CONFIG_BINFMT_IRIX=y
+# CONFIG_BINFMT_IRIX is not set
 
 #
 # Memory Technology Devices (MTD)



Michael Pruznick wrote:
> 
> All this does is put "CONFIG_BINFMT_IRIX is not set" into the
> config files so that when switching dual-endian systems from LE
> to BE this will default to "n" instead of "y".
> 
> The main problem with this is that, in general, there is no
> need/desire to have CONFIG_BINFMT_IRIX included just because
> the kernel is BE.  Rather than being forced to disable this,
> I think the default should be off.
> 
> In some older kernels, it this causes compile errors, but that
> problem doesn't seam to exit in the latest 2.4 tree.
> 
> I tested this with menuconfig and xconfig.
> 
> I'm not an expert in all the subtle dependencies issues with
> the config.in files so there may be a better way do to this.
> 
> cvs diff -uN arch/mips/config-shared.in
> Index: arch/mips/config-shared.in
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v
> retrieving revision 1.1.2.80
> diff -u -r1.1.2.80 config-shared.in
> --- arch/mips/config-shared.in  5 Aug 2003 11:13:39 -0000       1.1.2.80
> +++ arch/mips/config-shared.in  5 Aug 2003 17:07:24 -0000
> @@ -817,6 +817,8 @@
> 
>  if [ "$CONFIG_CPU_LITTLE_ENDIAN" = "n" ]; then
>     bool 'Include IRIX binary compatibility' CONFIG_BINFMT_IRIX
> +else
> +   define_bool CONFIG_BINFMT_IRIX n
>  fi
> 
>  if [ "$CONFIG_CPU_R10000" = "y" ]; then

-- 
Michael Pruznick, michael_pruznick@mvista.com, www.mvista.com
MontaVista Software, 1237 East Arques Ave, Sunnyvale, CA 94085
direct voice/fax:970-266-1108, main office:408-328-9200

From ica2_ts@csv.ica.uni-stuttgart.de Fri Aug  8 00:15:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Aug 2003 00:15:29 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:44618
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225208AbTHGXPZ>; Fri, 8 Aug 2003 00:15:25 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19ktyZ-0006lc-00; Fri, 08 Aug 2003 01:15:19 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19ktyY-0007WH-00; Fri, 08 Aug 2003 01:15:18 +0200
Date: Fri, 8 Aug 2003 01:15:18 +0200
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: load/store address overflow on binutils 2.14
Message-ID: <20030807231518.GH3759@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030807.190330.26271096.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030807.190330.26271096.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3005
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Atsushi Nemoto wrote:
> I'm trying binutils 2.14 (and binutils 2.14.90.0.5).  These versions
> can not compile this inctruction.
> 
> 	lw	$2, 0x80000000
> 
> $ mips-linux-gcc -c foo.s
> b.S: Assembler messages:
> foo.S:1: Error: load/store address overflow (max 32 bits)
> 
> Using such an immediate address for load instructions is legal?  I
> found the error message in tc-mips.c and it looks like something
> related to 64bit ABIs, but I just want to compile 32bit (standalone)
> program.
> 
> Is this code really needed for 32bit ABI?
> 
> binutils-2.14/gas/config/tc-mips.c:6297
>  	  else if (offset_expr.X_op == O_constant
>  		   && !HAVE_64BIT_ADDRESS_CONSTANTS
>  		   && !IS_SEXT_32BIT_NUM (offset_expr.X_add_number))
>  	    as_bad (_("load/store address overflow (max 32 bits)"));

It shouldn't trigger for 32bit, because 0x80000000 is a sign-extended
32bit number. How is mips-linux-as actually invoked?


Thiemo

From anemo@mba.ocn.ne.jp Fri Aug  8 02:09:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Aug 2003 02:09:54 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:55812
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225217AbTHHBJv>; Fri, 8 Aug 2003 02:09:51 +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; 8 Aug 2003 01:09:50 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h7819YDV094347;
	Fri, 8 Aug 2003 10:09:35 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 08 Aug 2003 10:11:02 +0900 (JST)
Message-Id: <20030808.101102.71082885.nemoto@toshiba-tops.co.jp>
To: ica2_ts@csv.ica.uni-stuttgart.de
Cc: linux-mips@linux-mips.org
Subject: Re: load/store address overflow on binutils 2.14
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030807231518.GH3759@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030807.190330.26271096.nemoto@toshiba-tops.co.jp>
	<20030807231518.GH3759@rembrandt.csv.ica.uni-stuttgart.de>
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: 3006
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Fri, 8 Aug 2003 01:15:18 +0200, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> said:
Thiemo> It shouldn't trigger for 32bit, because 0x80000000 is a
Thiemo> sign-extended 32bit number. How is mips-linux-as actually
Thiemo> invoked?

Like this (using mipsel):

$ mipsel-linux-gcc -o b.o -c -v b.S
Reading specs from /usr/lib/gcc-lib/mipsel-linux/3.3/specs
Configured with: ../gcc-3.3/configure --target=mipsel-linux --prefix=/usr --disable-nls --enable-languages=c --disable-shared --disable-threads
Thread model: single
gcc version 3.3
 /usr/lib/gcc-lib/mipsel-linux/3.3/cc1 -E -lang-asm -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 b.S -o /tmp/cceVg6Jo.s
ignoring nonexistent directory "/usr/mipsel-linux/sys-include"
ignoring nonexistent directory "/usr/mipsel-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-lib/mipsel-linux/3.3/include
End of search list.
 /usr/lib/gcc-lib/mipsel-linux/3.3/../../../../mipsel-linux/bin/as -EL -g0 -32 -v -KPIC -o b.o /tmp/cceVg6Jo.s
GNU assembler version 2.14 (mipsel-linux) using BFD version 2.14 20030612
b.S: Assembler messages:
b.S:1: Error: load/store address overflow (max 32 bits)

The b.S is just one line "lw $2, 0x80000000".

Just typing "mipsel-linux-as -o b.o b.S" produces same error.

---
Atsushi Nemoto

From ica2_ts@csv.ica.uni-stuttgart.de Fri Aug  8 04:07:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Aug 2003 04:07:25 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:26955
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224802AbTHHDHQ>; Fri, 8 Aug 2003 04:07:16 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19kxar-0008F5-00; Fri, 08 Aug 2003 05:07:05 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19kxar-0003dA-00; Fri, 08 Aug 2003 05:07:05 +0200
Date: Fri, 8 Aug 2003 05:07:05 +0200
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: load/store address overflow on binutils 2.14
Message-ID: <20030808030705.GJ3759@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030807.190330.26271096.nemoto@toshiba-tops.co.jp> <20030807231518.GH3759@rembrandt.csv.ica.uni-stuttgart.de> <20030808.101102.71082885.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030808.101102.71082885.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3007
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Atsushi Nemoto wrote:
> >>>>> On Fri, 8 Aug 2003 01:15:18 +0200, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> said:
> Thiemo> It shouldn't trigger for 32bit, because 0x80000000 is a
> Thiemo> sign-extended 32bit number. How is mips-linux-as actually
> Thiemo> invoked?
> 
> Like this (using mipsel):
> 
> $ mipsel-linux-gcc -o b.o -c -v b.S
> Reading specs from /usr/lib/gcc-lib/mipsel-linux/3.3/specs
> Configured with: ../gcc-3.3/configure --target=mipsel-linux --prefix=/usr --disable-nls --enable-languages=c --disable-shared --disable-threads
> Thread model: single
> gcc version 3.3
>  /usr/lib/gcc-lib/mipsel-linux/3.3/cc1 -E -lang-asm -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 b.S -o /tmp/cceVg6Jo.s
> ignoring nonexistent directory "/usr/mipsel-linux/sys-include"
> ignoring nonexistent directory "/usr/mipsel-linux/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/lib/gcc-lib/mipsel-linux/3.3/include
> End of search list.
>  /usr/lib/gcc-lib/mipsel-linux/3.3/../../../../mipsel-linux/bin/as -EL -g0 -32 -v -KPIC -o b.o /tmp/cceVg6Jo.s
> GNU assembler version 2.14 (mipsel-linux) using BFD version 2.14 20030612
> b.S: Assembler messages:
> b.S:1: Error: load/store address overflow (max 32 bits)
> 
> The b.S is just one line "lw $2, 0x80000000".

Using  0xffffffff80000000 is a really ugly workaround for it.
Seems like the constant isn't properly sign-extended inernally
by the assembler.


Thiemo

From agx@sigxcpu.org Fri Aug  8 13:50:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Aug 2003 13:50:34 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:56249
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225310AbTHHMua>; Fri, 8 Aug 2003 13:50:30 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id CD64E2BC3C; Fri,  8 Aug 2003 14:50: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 12490-04;
 Fri,  8 Aug 2003 14:50:24 +0200 (CEST)
Received: from bogon.sigxcpu.org (kons-d9bb55ca.pool.mediaWays.net [217.187.85.202])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 9B2C52BC42; Fri,  8 Aug 2003 14:50:18 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 9B0D7173AC; Thu,  7 Aug 2003 20:37:55 +0200 (CEST)
Date: Thu, 7 Aug 2003 20:37:55 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: Michael Pruznick <michael_pruznick@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: PATCH:2.4:CONFIG_BINFMT_IRIX
Message-ID: <20030807183755.GA9874@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	Michael Pruznick <michael_pruznick@mvista.com>,
	linux-mips@linux-mips.org
References: <3F2FF67D.8B0C2DFB@mvista.com> <3F329421.D86566A9@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9"
Content-Disposition: inline
In-Reply-To: <3F329421.D86566A9@mvista.com>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20021227-p2 (Debian)
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3008
X-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


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

On Thu, Aug 07, 2003 at 12:02:09PM -0600, Michael Pruznick wrote:
> This seams to be a better way to eliminate the irix
> stuff from being automatically included when switching
> a board from le to be.
What about leaving Irix compatibility off by default anyway. I don't
think it matters much these days.
 -- Guido

--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/MpyDn88szT8+ZCYRAtmlAKCBuPoGt2znMdfDMRznFuFsR+m4zQCfZ+jl
fGDONGHREN0TLrVyEuc+M+k=
=xV32
-----END PGP SIGNATURE-----

--PEIAKu/WMn1b1Hv9--

From anemo@mba.ocn.ne.jp Fri Aug  8 15:53:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Aug 2003 15:53:04 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:29400 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8224802AbTHHOxA>; Fri, 8 Aug 2003 15:53:00 +0100
Received: from localhost (p4124-ip02funabasi.chiba.ocn.ne.jp [61.112.102.124])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id A25B12E9D; Fri,  8 Aug 2003 23:52:56 +0900 (JST)
Date: Sat, 09 Aug 2003 00:06:03 +0900 (JST)
Message-Id: <20030809.000603.74756723.anemo@mba.ocn.ne.jp>
To: ica2_ts@csv.ica.uni-stuttgart.de
Cc: linux-mips@linux-mips.org
Subject: Re: load/store address overflow on binutils 2.14
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030808030705.GJ3759@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030807231518.GH3759@rembrandt.csv.ica.uni-stuttgart.de>
	<20030808.101102.71082885.nemoto@toshiba-tops.co.jp>
	<20030808030705.GJ3759@rembrandt.csv.ica.uni-stuttgart.de>
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: 3009
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Fri, 8 Aug 2003 05:07:05 +0200, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> said:
>> The b.S is just one line "lw $2, 0x80000000".
Thiemo> Using 0xffffffff80000000 is a really ugly workaround for it.
Thiemo> Seems like the constant isn't properly sign-extended inernally
Thiemo> by the assembler.

Yes the workaround works.  But I modified binutils (just remove the
checking code) instead of changing many constant definitions in my
programs.  For now it is enough for me.  Thank you.
---
Atsushi Nemoto

From ica2_ts@csv.ica.uni-stuttgart.de Sun Aug 10 13:08:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 10 Aug 2003 13:09:03 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:37461
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224821AbTHJMIy>; Sun, 10 Aug 2003 13:08:54 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19lp08-0001pF-00; Sun, 10 Aug 2003 14:08:44 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19lp08-0001XR-00; Sun, 10 Aug 2003 14:08:44 +0200
Date: Sun, 10 Aug 2003 14:08:44 +0200
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: load/store address overflow on binutils 2.14
Message-ID: <20030810120844.GB22977@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030807231518.GH3759@rembrandt.csv.ica.uni-stuttgart.de> <20030808.101102.71082885.nemoto@toshiba-tops.co.jp> <20030808030705.GJ3759@rembrandt.csv.ica.uni-stuttgart.de> <20030809.000603.74756723.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030809.000603.74756723.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3010
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Atsushi Nemoto wrote:
> >>>>> On Fri, 8 Aug 2003 05:07:05 +0200, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> said:
> >> The b.S is just one line "lw $2, 0x80000000".
> Thiemo> Using 0xffffffff80000000 is a really ugly workaround for it.
> Thiemo> Seems like the constant isn't properly sign-extended inernally
> Thiemo> by the assembler.
> 
> Yes the workaround works.  But I modified binutils (just remove the
> checking code) instead of changing many constant definitions in my
> programs.  For now it is enough for me.  Thank you.

It is probably not a real binutils bug, but related to gcc mishandling
'unsigned long long'. The simple testcase

int main(void)
{
        unsigned long long a = 0;

        printf("%016x\n", ~a);

        return 0;
}

outputs

00000000ffffffff

on my i386-linux system. On mips-linux it's even worse, the result is

000000000000000b

If this is really an arch-independent problem, any (cross-)compile on
a 32bit system for 64bit BFD can be broken.


Thiemo

From coldwell@frank.harvard.edu Sun Aug 10 15:36:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 10 Aug 2003 15:36:58 +0100 (BST)
Received: from frank.harvard.edu ([IPv6:::ffff:140.247.122.99]:12169 "EHLO
	frank.harvard.edu") by linux-mips.org with ESMTP
	id <S8224821AbTHJOgy>; Sun, 10 Aug 2003 15:36:54 +0100
Received: from frank.harvard.edu (frank.harvard.edu [140.247.122.99])
	by frank.harvard.edu (8.11.6/8.11.6) with ESMTP id h7AEapN16709;
	Sun, 10 Aug 2003 10:36:51 -0400
Date: Sun, 10 Aug 2003 10:36:51 -0400 (EDT)
From: Chip Coldwell <coldwell@frank.harvard.edu>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: load/store address overflow on binutils 2.14
In-Reply-To: <20030810120844.GB22977@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.44.0308101032240.16702-100000@frank.harvard.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <coldwell@frank.harvard.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: 3011
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: coldwell@frank.harvard.edu
Precedence: bulk
X-list: linux-mips

On Sun, 10 Aug 2003, Thiemo Seufer wrote:

> Atsushi Nemoto wrote:
> > >>>>> On Fri, 8 Aug 2003 05:07:05 +0200, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> said:
> > >> The b.S is just one line "lw $2, 0x80000000".
> > Thiemo> Using 0xffffffff80000000 is a really ugly workaround for it.
> > Thiemo> Seems like the constant isn't properly sign-extended inernally
> > Thiemo> by the assembler.
> > 
> > Yes the workaround works.  But I modified binutils (just remove the
> > checking code) instead of changing many constant definitions in my
> > programs.  For now it is enough for me.  Thank you.
> 
> It is probably not a real binutils bug, but related to gcc mishandling
> 'unsigned long long'. The simple testcase
> 
> int main(void)
> {
>         unsigned long long a = 0;
> 
>         printf("%016x\n", ~a);
> 
>         return 0;
> }
> 
> outputs
> 
> 00000000ffffffff
> 
> on my i386-linux system.

Strangely, this is actually "correct" behavior.  Arguments on
variable-length argument lists are implicitly "promoted" to unsigned
int at the widest.  See K&R 2nd ed. A6.1 and A7.3.2.  Things may have
changed with C99, but this would have been expected behavior for ANSI
C, and strange results were to be had when "long int" was wider than
"int" and was passed on a variable-length argument list.

Chip

-- 
Charles  M. "Chip" Coldwell      __o
"Turn on, log in, tune out"      \<
                              (@)/(@) 
-------------------------------------


From ica2_ts@csv.ica.uni-stuttgart.de Sun Aug 10 15:54:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 10 Aug 2003 15:54:34 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:6486
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225202AbTHJOya>; Sun, 10 Aug 2003 15:54:30 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19lraT-0002ig-00; Sun, 10 Aug 2003 16:54:25 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19lraT-00012G-00; Sun, 10 Aug 2003 16:54:25 +0200
Date: Sun, 10 Aug 2003 16:54:25 +0200
To: Chip Coldwell <coldwell@frank.harvard.edu>
Cc: linux-mips@linux-mips.org
Subject: Re: load/store address overflow on binutils 2.14
Message-ID: <20030810145425.GE22977@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030810120844.GB22977@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.44.0308101032240.16702-100000@frank.harvard.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0308101032240.16702-100000@frank.harvard.edu>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3012
X-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

Chip Coldwell wrote:
[snip]
> >         printf("%016x\n", ~a);
> > 
> >         return 0;
> > }
> > 
> > outputs
> > 
> > 00000000ffffffff
> > 
> > on my i386-linux system.
> 
> Strangely, this is actually "correct" behavior.  Arguments on
> variable-length argument lists are implicitly "promoted" to unsigned
> int at the widest.  See K&R 2nd ed. A6.1 and A7.3.2.

Ugh. Thanks for pointing this out. I wasn't aware of it.

	printf("%016Lx\n", ~a);

Produces the expected output. So it is actually an implementation
bug in binutils, which isn't fixable for 2.14 and earlier, because
those have to remain at K&R C level. The K&R requirement was only
recenly loosened.


Thiemo

From macro@ds2.pg.gda.pl Mon Aug 11 11:55:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Aug 2003 11:55:18 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:7141 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224821AbTHKKzQ>; Mon, 11 Aug 2003 11:55:16 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA18622;
	Mon, 11 Aug 2003 12:55:04 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 11 Aug 2003 12:55:02 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: Chip Coldwell <coldwell@frank.harvard.edu>,
	linux-mips@linux-mips.org
Subject: Re: load/store address overflow on binutils 2.14
In-Reply-To: <20030810145425.GE22977@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030811125208.18443A-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: 3013
X-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, 10 Aug 2003, Thiemo Seufer wrote:

> Produces the expected output. So it is actually an implementation
> bug in binutils, which isn't fixable for 2.14 and earlier, because
> those have to remain at K&R C level. The K&R requirement was only
> recenly loosened.

 Strangely enough, the Atsushi's code builds just fine with 2.13.2.1. 

-- 
+  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 Aug 11 14:02:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Aug 2003 14:02:32 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:17392 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224821AbTHKNCU>; Mon, 11 Aug 2003 14:02:20 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA19944;
	Mon, 11 Aug 2003 15:02:17 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 11 Aug 2003 15:02:16 +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] Generic time trailing clean-ups
Message-ID: <Pine.GSO.3.96.1030811144812.19197C-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: 3014
X-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 hopefully the final part (for now) of the generic time changes.
It addresses the following problems:

1. Due to the fact timers are initialized long before interrupts are
enabled, the high precision timer (HPT) is much fast compared to jiffies. 
This is now handled by reinitializing the HPT in timer_interrupt().

2. c0_fixed_hpt_init() doesn't set expirelo and cp0.compare properly
outside the first jiffy.

3. calibrate_div64_gettimeoffset() suffers from the R4000 erratum #28. 

 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-20030725-mips-time-init-4
diff -up --recursive --new-file linux-mips-2.4.21-20030725.macro/arch/mips/kernel/time.c linux-mips-2.4.21-20030725/arch/mips/kernel/time.c
--- linux-mips-2.4.21-20030725.macro/arch/mips/kernel/time.c	2003-08-05 00:10:35.000000000 +0000
+++ linux-mips-2.4.21-20030725/arch/mips/kernel/time.c	2003-08-09 20:23:25.000000000 +0000
@@ -138,10 +138,10 @@ static void c0_hpt_init(unsigned int cou
 /* For a known frequency.  Used as an interrupt source.  */
 static void c0_fixed_hpt_init(unsigned int count)
 {
-	expirelo = cycles_per_jiffy;
 	count = read_c0_count() - count;
-	write_c0_count(0);
-	write_c0_compare(cycles_per_jiffy);
+	expirelo = (count / cycles_per_jiffy + 1) * cycles_per_jiffy;
+	write_c0_count(expirelo - cycles_per_jiffy);
+	write_c0_compare(expirelo);
 	write_c0_count(count);
 }
 
@@ -328,6 +328,7 @@ static unsigned long calibrate_div64_get
 				"dsll32	%1,%2,0\n\t"
 				"or	%1,%1,%0\n\t"
 				"ddivu	$0,%1,%4\n\t"
+				"nop\n\t"		/* R4000 erratum #28 */
 				"dsll32	%0,%5,0\n\t"
 				"or	%0,%0,%6\n\t"
 				"mflo	%1\n\t"
@@ -410,6 +411,7 @@ void local_timer_interrupt(int irq, void
  */
 void timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
+	unsigned long j;
 	unsigned int count;
 
 	count = mips_hpt_read();
@@ -447,10 +449,41 @@ void timer_interrupt(int irq, void *dev_
 	 * If jiffies has overflown in this timer_interrupt, we must
 	 * update the timer[hi]/[lo] to make fast gettimeoffset funcs
 	 * quotient calc still valid. -arca
-	 */
-	if (!jiffies) {
-		timerhi = timerlo = 0;
-		mips_hpt_init(count);
+	 *
+	 * The first timer interrupt comes late as interrupts are
+	 * enabled long after timers are initialized.  Therefore the
+	 * high precision timer is fast, leading to wrong gettimeoffset()
+	 * calculations.  We deal with it by setting it based on the
+	 * number of its ticks between the second and the third interrupt.
+	 * That is still somewhat imprecise, but it's a good estimate.
+	 * --macro
+	 */
+	j = jiffies;
+	if (j < 4) {
+		static unsigned int prev_count;
+		static int hpt_initialized;
+
+		switch (j) {
+		case 0:
+			timerhi = timerlo = 0;
+			mips_hpt_init(count);
+			break;
+		case 2:
+			prev_count = count;
+			break;
+		case 3:
+			if (!hpt_initialized) {
+				unsigned int c3 = 3 * (count - prev_count);
+
+				timerhi = 0;
+				timerlo = c3;
+				mips_hpt_init(count - c3);
+				hpt_initialized = 1;
+			}
+			break;
+		default:
+			break;
+		}
 	}
 
 #if !defined(CONFIG_SMP)
diff -up --recursive --new-file linux-mips-2.4.21-20030725.macro/arch/mips64/kernel/time.c linux-mips-2.4.21-20030725/arch/mips64/kernel/time.c
--- linux-mips-2.4.21-20030725.macro/arch/mips64/kernel/time.c	2003-08-05 00:10:35.000000000 +0000
+++ linux-mips-2.4.21-20030725/arch/mips64/kernel/time.c	2003-08-09 20:23:42.000000000 +0000
@@ -138,10 +138,10 @@ static void c0_hpt_init(unsigned int cou
 /* For a known frequency.  Used as an interrupt source.  */
 static void c0_fixed_hpt_init(unsigned int count)
 {
-	expirelo = cycles_per_jiffy;
 	count = read_c0_count() - count;
-	write_c0_count(0);
-	write_c0_compare(cycles_per_jiffy);
+	expirelo = (count / cycles_per_jiffy + 1) * cycles_per_jiffy;
+	write_c0_count(expirelo - cycles_per_jiffy);
+	write_c0_compare(expirelo);
 	write_c0_count(count);
 }
 
@@ -185,7 +185,7 @@ void do_settimeofday(struct timeval *tv)
 	 * This is revolting.  We need to set "xtime" correctly.  However,
 	 * the value in this location is the value at the most recent update
 	 * of wall time.  Discover what correction gettimeofday() would have
-	 * done, and then undo it!
+	 * made, and then undo it!
 	 */
 	tv->tv_usec -= do_gettimeoffset();
 	tv->tv_usec -= (jiffies - wall_jiffies) * USECS_PER_JIFFY;
@@ -328,6 +328,7 @@ static unsigned long calibrate_div64_get
 				"dsll32	%1,%2,0\n\t"
 				"or	%1,%1,%0\n\t"
 				"ddivu	$0,%1,%4\n\t"
+				"nop\n\t"		/* R4000 erratum #28 */
 				"dsll32	%0,%5,0\n\t"
 				"or	%0,%0,%6\n\t"
 				"mflo	%1\n\t"
@@ -410,6 +411,7 @@ void local_timer_interrupt(int irq, void
  */
 void timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
+	unsigned long j;
 	unsigned int count;
 
 	count = mips_hpt_read();
@@ -447,10 +449,41 @@ void timer_interrupt(int irq, void *dev_
 	 * If jiffies has overflown in this timer_interrupt, we must
 	 * update the timer[hi]/[lo] to make fast gettimeoffset funcs
 	 * quotient calc still valid. -arca
-	 */
-	if (!jiffies) {
-		timerhi = timerlo = 0;
-		mips_hpt_init(count);
+	 *
+	 * The first timer interrupt comes late as interrupts are
+	 * enabled long after timers are initialized.  Therefore the
+	 * high precision timer is fast, leading to wrong gettimeoffset()
+	 * calculations.  We deal with it by setting it based on the
+	 * number of its ticks between the second and the third interrupt.
+	 * That is still somewhat imprecise, but it's a good estimate.
+	 * --macro
+	 */
+	j = jiffies;
+	if (j < 4) {
+		static unsigned int prev_count;
+		static int hpt_initialized;
+
+		switch (j) {
+		case 0:
+			timerhi = timerlo = 0;
+			mips_hpt_init(count);
+			break;
+		case 2:
+			prev_count = count;
+			break;
+		case 3:
+			if (!hpt_initialized) {
+				unsigned int c3 = 3 * (count - prev_count);
+
+				timerhi = 0;
+				timerlo = c3;
+				mips_hpt_init(count - c3);
+				hpt_initialized = 1;
+			}
+			break;
+		default:
+			break;
+		}
 	}
 
 #if !defined(CONFIG_SMP)


From dkesselr@mmc.atmel.com Mon Aug 11 19:28:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Aug 2003 19:28:57 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:22150
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225202AbTHKS2z>; Mon, 11 Aug 2003 19:28:55 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id OAA07856
	for <linux-mips@linux-mips.org>; Mon, 11 Aug 2003 14:28:47 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id OAA04603
	for <linux-mips@linux-mips.org>; Mon, 11 Aug 2003 14:28:47 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Mon, 11 Aug 2003 14:28:46 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: C0 config reg for 5k core
Message-ID: <Pine.GSO.4.44.0308111422220.4449-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3015
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

Has anyone else built linux 2.4 for a 5k or 5kf core? When comparing cpu.h
and the MIPS64 5K Processor Core Family Software Users Manual it doesn't
look to me that the c0-config1 reg is defined the same way. Am I reading
something wrong? For example in the spec FPU flag is bit0 while in cpu.h
it is bit4. Seems pretty basic.

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


From jsun@mvista.com Mon Aug 11 19:34:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Aug 2003 19:34:36 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:41971 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225202AbTHKSee>;
	Mon, 11 Aug 2003 19:34:34 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h7BIYSD09530;
	Mon, 11 Aug 2003 11:34:28 -0700
Date: Mon, 11 Aug 2003 11:34:28 -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] Generic time trailing clean-ups
Message-ID: <20030811113428.F9020@mvista.com>
References: <Pine.GSO.3.96.1030811144812.19197C-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.1030811144812.19197C-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Mon, Aug 11, 2003 at 03:02:16PM +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: 3016
X-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, Aug 11, 2003 at 03:02:16PM +0200, Maciej W. Rozycki wrote:
> Hello,
> 
>  Here is hopefully the final part (for now) of the generic time changes.
> It addresses the following problems:
> 
> -	 */
> -	if (!jiffies) {
> -		timerhi = timerlo = 0;
> -		mips_hpt_init(count);
> +	 *
> +	 * The first timer interrupt comes late as interrupts are
> +	 * enabled long after timers are initialized.  Therefore the
> +	 * high precision timer is fast, leading to wrong gettimeoffset()
> +	 * calculations.  We deal with it by setting it based on the
> +	 * number of its ticks between the second and the third interrupt.
> +	 * That is still somewhat imprecise, but it's a good estimate.
> +	 * --macro
> +	 */
> +	j = jiffies;
> +	if (j < 4) {
> +		static unsigned int prev_count;
> +		static int hpt_initialized;
> +
> +		switch (j) {
> +		case 0:
> +			timerhi = timerlo = 0;
> +			mips_hpt_init(count);
> +			break;
> +		case 2:
> +			prev_count = count;
> +			break;
> +		case 3:
> +			if (!hpt_initialized) {
> +				unsigned int c3 = 3 * (count - prev_count);
> +
> +				timerhi = 0;
> +				timerlo = c3;
> +				mips_hpt_init(count - c3);
> +				hpt_initialized = 1;
> +			}
> +			break;
> +		default:
> +			break;
> +		}
>  	}
> 

The first gettimeoffset() call is way after many jiffies (~50 normally?).  Such
an estimate is not necessary.

Also note jiffies can wrap around.  

Jun

From uhler@mips.com Mon Aug 11 20:32:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Aug 2003 20:32:12 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:31187 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225202AbTHKTcK>;
	Mon, 11 Aug 2003 20:32:10 +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 h7BJVPMO007685;
	Mon, 11 Aug 2003 12:31:25 -0700 (PDT)
Received: from uhler-linux.mips.com (uhler-linux [192.168.65.120])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA14771;
	Mon, 11 Aug 2003 12:32:07 -0700 (PDT)
Subject: Re: C0 config reg for 5k core
From: Mike Uhler <uhler@mips.com>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <Pine.GSO.4.44.0308111422220.4449-100000@ares.mmc.atmel.com>
References: <Pine.GSO.4.44.0308111422220.4449-100000@ares.mmc.atmel.com>
Content-Type: text/plain
Organization: MIPS Technologies, Inc.
Message-Id: <1060630328.1071.20.camel@uhler-linux.mips.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.0 
Date: 11 Aug 2003 12:32:08 -0700
Content-Transfer-Encoding: 7bit
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: 3017
X-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

Bit 0 of Config1 is FPU-present.  Bit 4 is "Performance counters
present".  I guarantee you that the 5K family implements this
pattern.

/gmu


On Mon, 2003-08-11 at 11:28, David Kesselring wrote:
> Has anyone else built linux 2.4 for a 5k or 5kf core? When comparing cpu.h
> and the MIPS64 5K Processor Core Family Software Users Manual it doesn't
> look to me that the c0-config1 reg is defined the same way. Am I reading
> something wrong? For example in the spec FPU flag is bit0 while in cpu.h
> it is bit4. Seems pretty basic.
> 
> David Kesselring
> Atmel MMC
> dkesselr@mmc.atmel.com
> 919-462-6587
-- 

Michael Uhler, Chief Technology Officer
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 dkesselr@mmc.atmel.com Mon Aug 11 20:58:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Aug 2003 20:58:10 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:50072
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225202AbTHKT6I>; Mon, 11 Aug 2003 20:58:08 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id PAA09116;
	Mon, 11 Aug 2003 15:58:00 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id PAA04682;
	Mon, 11 Aug 2003 15:58:00 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Mon, 11 Aug 2003 15:57:59 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: Mike Uhler <uhler@mips.com>
cc: linux-mips@linux-mips.org
Subject: Re: C0 config reg for 5k core
In-Reply-To: <1060630328.1071.20.camel@uhler-linux.mips.com>
Message-ID: <Pine.GSO.4.44.0308111556500.4643-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3018
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

Is this reg, supposed to be the same among all processor or does it
differ?

On 11 Aug 2003, Mike Uhler wrote:

> Bit 0 of Config1 is FPU-present.  Bit 4 is "Performance counters
> present".  I guarantee you that the 5K family implements this
> pattern.
>
> /gmu
>
>
> On Mon, 2003-08-11 at 11:28, David Kesselring wrote:
> > Has anyone else built linux 2.4 for a 5k or 5kf core? When comparing cpu.h
> > and the MIPS64 5K Processor Core Family Software Users Manual it doesn't
> > look to me that the c0-config1 reg is defined the same way. Am I reading
> > something wrong? For example in the spec FPU flag is bit0 while in cpu.h
> > it is bit4. Seems pretty basic.
> >
> > David Kesselring
> > Atmel MMC
> > dkesselr@mmc.atmel.com
> > 919-462-6587
> --
>
> Michael Uhler, Chief Technology Officer
> 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
>
>
>
>

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


From uhler@mips.com Mon Aug 11 21:00:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Aug 2003 21:00:31 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:26836 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225202AbTHKUA0>;
	Mon, 11 Aug 2003 21:00:26 +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 h7BJxlMO007981;
	Mon, 11 Aug 2003 12:59:47 -0700 (PDT)
Received: from uhler-linux.mips.com (uhler-linux [192.168.65.120])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id NAA15351;
	Mon, 11 Aug 2003 13:00:30 -0700 (PDT)
Subject: Re: C0 config reg for 5k core
From: Mike Uhler <uhler@mips.com>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <Pine.GSO.4.44.0308111556500.4643-100000@ares.mmc.atmel.com>
References: <Pine.GSO.4.44.0308111556500.4643-100000@ares.mmc.atmel.com>
Content-Type: text/plain
Organization: MIPS Technologies, Inc.
Message-Id: <1060632030.1071.29.camel@uhler-linux.mips.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.0 
Date: 11 Aug 2003 13:00:30 -0700
Content-Transfer-Encoding: 7bit
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: 3019
X-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

For MIPS32 and MIPS64 processors (the 5K is MIPS64), it is
architecturally defined and required, and the compatibility
verification testing verifies it (and, yes, we do run compatibility
verification testing on our own cores).

/gmu

On Mon, 2003-08-11 at 12:57, David Kesselring wrote:
> Is this reg, supposed to be the same among all processor or does it
> differ?
> 
> On 11 Aug 2003, Mike Uhler wrote:
> 
> > Bit 0 of Config1 is FPU-present.  Bit 4 is "Performance counters
> > present".  I guarantee you that the 5K family implements this
> > pattern.
> >
> > /gmu
> >
> >
> > On Mon, 2003-08-11 at 11:28, David Kesselring wrote:
> > > Has anyone else built linux 2.4 for a 5k or 5kf core? When comparing cpu.h
> > > and the MIPS64 5K Processor Core Family Software Users Manual it doesn't
> > > look to me that the c0-config1 reg is defined the same way. Am I reading
> > > something wrong? For example in the spec FPU flag is bit0 while in cpu.h
> > > it is bit4. Seems pretty basic.
> > >
> > > David Kesselring
> > > Atmel MMC
> > > dkesselr@mmc.atmel.com
> > > 919-462-6587
> > --
> >
> > Michael Uhler, Chief Technology Officer
> > 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
> >
> >
> >
> >
> 
> David Kesselring
> Atmel MMC
> dkesselr@mmc.atmel.com
> 919-462-6587
-- 

Michael Uhler, Chief Technology Officer
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 Geert.Uytterhoeven@sonycom.com Mon Aug 11 21:58:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Aug 2003 21:59:05 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:30949 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225202AbTHKU64>;
	Mon, 11 Aug 2003 21:58:56 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h7BKwDlW013978;
	Mon, 11 Aug 2003 22:58:13 +0200 (MEST)
Date: Mon, 11 Aug 2003 22:58:13 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: Chip Coldwell <coldwell@frank.harvard.edu>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: load/store address overflow on binutils 2.14
In-Reply-To: <20030810145425.GE22977@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.4.21.0308112257180.20421-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: 3020
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Sun, 10 Aug 2003, Thiemo Seufer wrote:
> Chip Coldwell wrote:
> [snip]
> > >         printf("%016x\n", ~a);
> > > 
> > >         return 0;
> > > }
> > > 
> > > outputs
> > > 
> > > 00000000ffffffff
> > > 
> > > on my i386-linux system.
> > 
> > Strangely, this is actually "correct" behavior.  Arguments on
> > variable-length argument lists are implicitly "promoted" to unsigned
> > int at the widest.  See K&R 2nd ed. A6.1 and A7.3.2.
> 
> Ugh. Thanks for pointing this out. I wasn't aware of it.
> 
> 	printf("%016Lx\n", ~a);
> 
> Produces the expected output. So it is actually an implementation
> bug in binutils, which isn't fixable for 2.14 and earlier, because
> those have to remain at K&R C level. The K&R requirement was only
> recenly loosened.

How can it print the correct output if ~a is `promoted' to unsigned int, while
you specify %Lx in the format string?

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 ica2_ts@csv.ica.uni-stuttgart.de Tue Aug 12 00:10:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 00:10:26 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:2908
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225218AbTHKXKY>; Tue, 12 Aug 2003 00:10:24 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19mLnw-00053W-00; Tue, 12 Aug 2003 01:10:20 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19mLnv-00067G-00; Tue, 12 Aug 2003 01:10:19 +0200
Date: Tue, 12 Aug 2003 01:10:19 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: load/store address overflow on binutils 2.14
Message-ID: <20030811231019.GA23104@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030810145425.GE22977@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030811125208.18443A-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.1030811125208.18443A-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3021
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
> On Sun, 10 Aug 2003, Thiemo Seufer wrote:
> 
> > Produces the expected output. So it is actually an implementation
> > bug in binutils, which isn't fixable for 2.14 and earlier, because
> > those have to remain at K&R C level. The K&R requirement was only
> > recenly loosened.
> 
>  Strangely enough, the Atsushi's code builds just fine with 2.13.2.1.

The test in binutils it stumbled over was added later.


Thiemo

From ica2_ts@csv.ica.uni-stuttgart.de Tue Aug 12 00:16:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 00:16:45 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:5468
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225218AbTHKXQk>; Tue, 12 Aug 2003 00:16:40 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19mLtz-00055o-00; Tue, 12 Aug 2003 01:16:35 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19mLtz-00067j-00; Tue, 12 Aug 2003 01:16:35 +0200
Date: Tue, 12 Aug 2003 01:16:35 +0200
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Chip Coldwell <coldwell@frank.harvard.edu>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: load/store address overflow on binutils 2.14
Message-ID: <20030811231635.GB23104@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030810145425.GE22977@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.4.21.0308112257180.20421-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0308112257180.20421-100000@vervain.sonytel.be>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3022
X-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

Geert Uytterhoeven wrote:
[snip]
> > > Strangely, this is actually "correct" behavior.  Arguments on
> > > variable-length argument lists are implicitly "promoted" to unsigned
> > > int at the widest.  See K&R 2nd ed. A6.1 and A7.3.2.
> > 
> > Ugh. Thanks for pointing this out. I wasn't aware of it.
> > 
> > 	printf("%016Lx\n", ~a);
> > 
> > Produces the expected output. So it is actually an implementation
> > bug in binutils, which isn't fixable for 2.14 and earlier, because
> > those have to remain at K&R C level. The K&R requirement was only
> > recenly loosened.
> 
> How can it print the correct output if ~a is `promoted' to unsigned int, while
> you specify %Lx in the format string?

From 'info gcc':

Double-Word Integers
====================

   ISO C99 supports data types for integers that are at least 64 bits
wide, and as an extension GCC supports them in C89 mode and in C++.
[...]
   There may be pitfalls when you use `long long' types for function
arguments, unless you declare function prototypes.  If a function
expects type `int' for its argument, and you pass a value of type `long
long int', confusion will result because the caller and the subroutine
will disagree about the number of bytes for the argument.  Likewise, if
the function expects `long long int' and you pass `int'.  The best way
to avoid such problems is to use prototypes.


Thiemo

From anemo@mba.ocn.ne.jp Tue Aug 12 07:25:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 07:25:42 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:50962
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225193AbTHLGZe>; Tue, 12 Aug 2003 07:25:34 +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; 12 Aug 2003 06:25:33 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h7C6PKDV005922
	for <linux-mips@linux-mips.org>; Tue, 12 Aug 2003 15:25:22 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Tue, 12 Aug 2003 15:26:54 +0900 (JST)
Message-Id: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org
Subject: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3023
X-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

I'm trying to compile kernel with gcc 3.3.1 and binutils 2.14.  I
found this report on this ML:

>>>>> On Tue, 13 May 2003 13:33:16 +0200, Guido Guenther <agx@sigxcpu.org> said:
Guido> Just for completeness: I had to use:
Guido>  GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
Guido> to make gcc-3.3 happy (note the 32 instead of o32). gcc-3.2
Guido> doesn't seem to handle these options correctly at all.

It can compile the kernel, but handle_adel_int (and handle_ades_int)
contain wrong codes.

8002630c <handle_adel_int> 40284000 	dmfc0	t0,$8
80026310 <handle_adel_int+0x4> 00000000 	nop
80026314 <handle_adel_int+0x8> ffa800a4 	sd	t0,164(sp)

The source code for this instructions are:

#define __BUILD_clear_ade(exception)                                    \
		.set	reorder;					\
		MFC0	t0,CP0_BADVADDR;                                \
		.set	noreorder;					\
		REG_S	t0,PT_BVADDR(sp);                               \
		KMODE

The macro MFC0 and REG_S are defined asm.h and depend on _MIPS_ISA.

#if (_MIPS_ISA == _MIPS_ISA_MIPS1) || (_MIPS_ISA == _MIPS_ISA_MIPS2) || \
    (_MIPS_ISA == _MIPS_ISA_MIPS32)
#define MFC0		mfc0
#define MTC0		mtc0
#endif
#if (_MIPS_ISA == _MIPS_ISA_MIPS3) || (_MIPS_ISA == _MIPS_ISA_MIPS4) || \
    (_MIPS_ISA == _MIPS_ISA_MIPS5) || (_MIPS_ISA == _MIPS_ISA_MIPS64)
#define MFC0		dmfc0
#define MTC0		dmtc0
#endif

The option -march=r4600 seems to make gcc 3.3.x choose MIPS_ISA_MIPS3.

So, the right options is:

	GCCFLAGS += -mabi=32 -march=mips2 -mtune=r4600 -Wa,--trap
(or	GCCFLAGS += $(call check_gcc, -mcpu=r4600 -mips2, -mabi=32 -march=mips2 -mtune=r4600) -Wa,--trap)

Isn't it?

---
Atsushi Nemoto

From kumba@gentoo.org Tue Aug 12 07:49:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 07:49:27 +0100 (BST)
Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:21728 "EHLO
	rwcrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225193AbTHLGtZ>; Tue, 12 Aug 2003 07:49:25 +0100
Received: from gentoo.org (pcp02545003pcs.waldrf01.md.comcast.net[68.48.92.102](untrusted sender))
          by comcast.net (rwcrmhc12) with SMTP
          id <2003081206491801400kaikhe>
          (Authid: kumba12345);
          Tue, 12 Aug 2003 06:49:18 +0000
Message-ID: <3F388E0C.50802@gentoo.org>
Date: Tue, 12 Aug 2003 02:49:48 -0400
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp>
In-Reply-To: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3024
X-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

Atsushi Nemoto wrote:

> I'm trying to compile kernel with gcc 3.3.1 and binutils 2.14.  I
> found this report on this ML:
> 
> 
>>>>>>On Tue, 13 May 2003 13:33:16 +0200, Guido Guenther <agx@sigxcpu.org> said:
> 
> Guido> Just for completeness: I had to use:
> Guido>  GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
> Guido> to make gcc-3.3 happy (note the 32 instead of o32). gcc-3.2
> Guido> doesn't seem to handle these options correctly at all.
> 
> It can compile the kernel, but handle_adel_int (and handle_ades_int)
> contain wrong codes.
> 
> 8002630c <handle_adel_int> 40284000 	dmfc0	t0,$8
> 80026310 <handle_adel_int+0x4> 00000000 	nop
> 80026314 <handle_adel_int+0x8> ffa800a4 	sd	t0,164(sp)
> 
> The source code for this instructions are:
> 
> #define __BUILD_clear_ade(exception)                                    \
> 		.set	reorder;					\
> 		MFC0	t0,CP0_BADVADDR;                                \
> 		.set	noreorder;					\
> 		REG_S	t0,PT_BVADDR(sp);                               \
> 		KMODE
> 
> The macro MFC0 and REG_S are defined asm.h and depend on _MIPS_ISA.
> 
> #if (_MIPS_ISA == _MIPS_ISA_MIPS1) || (_MIPS_ISA == _MIPS_ISA_MIPS2) || \
>     (_MIPS_ISA == _MIPS_ISA_MIPS32)
> #define MFC0		mfc0
> #define MTC0		mtc0
> #endif
> #if (_MIPS_ISA == _MIPS_ISA_MIPS3) || (_MIPS_ISA == _MIPS_ISA_MIPS4) || \
>     (_MIPS_ISA == _MIPS_ISA_MIPS5) || (_MIPS_ISA == _MIPS_ISA_MIPS64)
> #define MFC0		dmfc0
> #define MTC0		dmtc0
> #endif
> 
> The option -march=r4600 seems to make gcc 3.3.x choose MIPS_ISA_MIPS3.
> 
> So, the right options is:
> 
> 	GCCFLAGS += -mabi=32 -march=mips2 -mtune=r4600 -Wa,--trap
> (or	GCCFLAGS += $(call check_gcc, -mcpu=r4600 -mips2, -mabi=32 -march=mips2 -mtune=r4600) -Wa,--trap)
> 
> Isn't it?
> 
> ---
> Atsushi Nemoto


I don't claim to be an expert on all things mips yet, but If I recall 
correctly, the R4K processor line is a MIPS III capable processor.  So 
-mips3 -mabi=32 should be safe for it.  I've been building kernels off 
linux-mips.org CVS using "-mips3 -mabi=32 -Wa,--trap" in the 
arch/mips/Makefile, and it works great.

Several people I know using Indy's with R5000 processors use "-mips4 
-mabi=32 -Wa,--trap" (cause R5K is MIPS IV).  I know with gcc-3.3.x, 
-mipsX is just a synonym for the appropriate -march specifier, so it 
doesn't seem to make a different whether one uses -march or -mipsX.

I'm slowly working on building a Gentoo install using "-mips3 -mabi=32" 
code on my Indigo2 (Right now, it's a mix of -mips2 and -mips3 with a 
random -mips1 binary scattered around).  Quite a fun, albeit slow, 
experiment.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From ica2_ts@csv.ica.uni-stuttgart.de Tue Aug 12 07:51:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 07:51:26 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:16477
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225072AbTHLGvT>; Tue, 12 Aug 2003 07:51:19 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19mT02-0007bs-00
	for linux-mips@linux-mips.org; Tue, 12 Aug 2003 08:51:18 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19mT02-0006Cb-00
	for <linux-mips@linux-mips.org>; Tue, 12 Aug 2003 08:51:18 +0200
Date: Tue, 12 Aug 2003 08:51:18 +0200
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3025
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Atsushi Nemoto wrote:
> I'm trying to compile kernel with gcc 3.3.1 and binutils 2.14.  I
> found this report on this ML:
> 
> >>>>> On Tue, 13 May 2003 13:33:16 +0200, Guido Guenther <agx@sigxcpu.org> said:
> Guido> Just for completeness: I had to use:
> Guido>  GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
> Guido> to make gcc-3.3 happy (note the 32 instead of o32). gcc-3.2
> Guido> doesn't seem to handle these options correctly at all.
> 
> It can compile the kernel, but handle_adel_int (and handle_ades_int)
> contain wrong codes.
> 
> 8002630c <handle_adel_int> 40284000 	dmfc0	t0,$8
> 80026310 <handle_adel_int+0x4> 00000000 	nop
> 80026314 <handle_adel_int+0x8> ffa800a4 	sd	t0,164(sp)
> 
> The source code for this instructions are:
> 
> #define __BUILD_clear_ade(exception)                                    \
> 		.set	reorder;					\
> 		MFC0	t0,CP0_BADVADDR;                                \
> 		.set	noreorder;					\
> 		REG_S	t0,PT_BVADDR(sp);                               \
> 		KMODE
> 
> The macro MFC0 and REG_S are defined asm.h and depend on _MIPS_ISA.
> 
> #if (_MIPS_ISA == _MIPS_ISA_MIPS1) || (_MIPS_ISA == _MIPS_ISA_MIPS2) || \
>     (_MIPS_ISA == _MIPS_ISA_MIPS32)
> #define MFC0		mfc0
> #define MTC0		mtc0
> #endif
> #if (_MIPS_ISA == _MIPS_ISA_MIPS3) || (_MIPS_ISA == _MIPS_ISA_MIPS4) || \
>     (_MIPS_ISA == _MIPS_ISA_MIPS5) || (_MIPS_ISA == _MIPS_ISA_MIPS64)
> #define MFC0		dmfc0
> #define MTC0		dmtc0
> #endif
> 
> The option -march=r4600 seems to make gcc 3.3.x choose MIPS_ISA_MIPS3.

Which is ok, because the available ISA has little to do with the actually
used register width.

If the intention is to use mfc0 for 32bit kernels and dmfc0 for 64bit,
the check should probably be

#ifdef __mips64
# define MFC0		dmfc0
# define MTC0		dmtc0
#else
# define MFC0		mfc0
# define MTC0		mtc0
#endif

> So, the right options is:
> 
> 	GCCFLAGS += -mabi=32 -march=mips2 -mtune=r4600 -Wa,--trap
> (or	GCCFLAGS += $(call check_gcc, -mcpu=r4600 -mips2, -mabi=32 -march=mips2 -mtune=r4600) -Wa,--trap)
> 
> Isn't it?

-march=mips2 is an alias for -march=r6000, I don't think that's a
good choice.


Thiemo

From ica2_ts@csv.ica.uni-stuttgart.de Tue Aug 12 08:06:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 08:06:48 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:21853
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225072AbTHLHGq>; Tue, 12 Aug 2003 08:06:46 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19mTEz-0007iH-00
	for linux-mips@linux-mips.org; Tue, 12 Aug 2003 09:06:45 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19mTEz-0006EZ-00
	for <linux-mips@linux-mips.org>; Tue, 12 Aug 2003 09:06:45 +0200
Date: Tue, 12 Aug 2003 09:06:45 +0200
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030812070645.GF23104@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp> <3F388E0C.50802@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F388E0C.50802@gentoo.org>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3026
X-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

Kumba wrote:
[snip]
> I'm slowly working on building a Gentoo install using "-mips3 -mabi=32" 
> code on my Indigo2 (Right now, it's a mix of -mips2 and -mips3 with a 
> random -mips1 binary scattered around).  Quite a fun, albeit slow, 
> experiment.

I recommend to prefer -march=mips3 over -mips3. It documents the
intention to use a generic arch better and avoids confusion with
e.g. -mips16, which has a totally different meaning.

It won't work with old toolchains, though.


Thiemo

From kumba@gentoo.org Tue Aug 12 08:56:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 08:56:17 +0100 (BST)
Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:25047 "EHLO
	rwcrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225072AbTHLH4L>; Tue, 12 Aug 2003 08:56:11 +0100
Received: from gentoo.org (pcp02545003pcs.waldrf01.md.comcast.net[68.48.92.102](untrusted sender))
          by comcast.net (rwcrmhc12) with SMTP
          id <2003081207560401400kb0ope>
          (Authid: kumba12345);
          Tue, 12 Aug 2003 07:56:04 +0000
Message-ID: <3F389DB2.5020101@gentoo.org>
Date: Tue, 12 Aug 2003 03:56:34 -0400
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp> <3F388E0C.50802@gentoo.org> <20030812070645.GF23104@rembrandt.csv.ica.uni-stuttgart.de>
In-Reply-To: <20030812070645.GF23104@rembrandt.csv.ica.uni-stuttgart.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3027
X-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

Thiemo Seufer wrote:

> I recommend to prefer -march=mips3 over -mips3. It documents the
> intention to use a generic arch better and avoids confusion with
> e.g. -mips16, which has a totally different meaning.
> 
> It won't work with old toolchains, though.
> 
> 
> Thiemo

Good point.  Does the -march=mips3 work for gcc-3.2.x as well, or is 
that a gcc-3.3.x change?

--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From ica2_ts@csv.ica.uni-stuttgart.de Tue Aug 12 09:10:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 09:10:58 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:41565
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225072AbTHLIKy>; Tue, 12 Aug 2003 09:10:54 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19mUF2-000874-00
	for linux-mips@linux-mips.org; Tue, 12 Aug 2003 10:10:52 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19mUF2-0002G5-00
	for <linux-mips@linux-mips.org>; Tue, 12 Aug 2003 10:10:52 +0200
Date: Tue, 12 Aug 2003 10:10:52 +0200
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030812081052.GG23104@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp> <3F388E0C.50802@gentoo.org> <20030812070645.GF23104@rembrandt.csv.ica.uni-stuttgart.de> <3F389DB2.5020101@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F389DB2.5020101@gentoo.org>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3028
X-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

Kumba wrote:
> Thiemo Seufer wrote:
> 
> >I recommend to prefer -march=mips3 over -mips3. It documents the
> >intention to use a generic arch better and avoids confusion with
> >e.g. -mips16, which has a totally different meaning.
> >
> >It won't work with old toolchains, though.
> >
> >
> >Thiemo
> 
> Good point.  Does the -march=mips3 work for gcc-3.2.x as well, or is 
> that a gcc-3.3.x change?

It's only in 3.3 and upwards.


Thiemo

From kumba@gentoo.org Tue Aug 12 09:26:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 09:26:55 +0100 (BST)
Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:41110 "EHLO
	rwcrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8225072AbTHLI0v>; Tue, 12 Aug 2003 09:26:51 +0100
Received: from gentoo.org (pcp02545003pcs.waldrf01.md.comcast.net[68.48.92.102](untrusted sender))
          by comcast.net (rwcrmhc13) with SMTP
          id <20030812082643015006j4pje>
          (Authid: kumba12345);
          Tue, 12 Aug 2003 08:26:43 +0000
Message-ID: <3F38A4D2.9080105@gentoo.org>
Date: Tue, 12 Aug 2003 04:26:58 -0400
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp> <3F388E0C.50802@gentoo.org> <20030812070645.GF23104@rembrandt.csv.ica.uni-stuttgart.de> <3F389DB2.5020101@gentoo.org> <20030812081052.GG23104@rembrandt.csv.ica.uni-stuttgart.de>
In-Reply-To: <20030812081052.GG23104@rembrandt.csv.ica.uni-stuttgart.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3029
X-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

Thiemo Seufer wrote:

> It's only in 3.3 and upwards.
> 
> 
> Thiemo

Ahh.  This was why I was still using -mipsX, to maintain backwards 
compatibility until gcc-3.3.x becomes the mainstream compiler.

Something to keep in mind.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From nemoto@toshiba-tops.co.jp Tue Aug 12 10:24:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 10:24:12 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:4359
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225072AbTHLJYI>; Tue, 12 Aug 2003 10:24:08 +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; 12 Aug 2003 09:24:06 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h7C9Nt2S000528;
	Tue, 12 Aug 2003 18:23:55 +0900 (JST)
	(envelope-from nemoto@toshiba-tops.co.jp)
Date: Tue, 12 Aug 2003 18:25:29 +0900 (JST)
Message-Id: <20030812.182529.18309031.nemoto@toshiba-tops.co.jp>
To: kumba@gentoo.org
Cc: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
In-Reply-To: <3F388E0C.50802@gentoo.org>
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp>
	<3F388E0C.50802@gentoo.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <nemoto@toshiba-tops.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3030
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nemoto@toshiba-tops.co.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Tue, 12 Aug 2003 02:49:48 -0400, Kumba <kumba@gentoo.org> said:
kumba> I don't claim to be an expert on all things mips yet, but If I
kumba> recall correctly, the R4K processor line is a MIPS III capable
kumba> processor.  So -mips3 -mabi=32 should be safe for it.  I've
kumba> been building kernels off linux-mips.org CVS using "-mips3
kumba> -mabi=32 -Wa,--trap" in the arch/mips/Makefile, and it works
kumba> great.

Only affected code I found is __BUILD_clear_ade.  So the 32-bit kernel
compiled with -mips3 will work fine normally, but once an address
error occur the kernel will crash.

As Thiemo said, it seems include/asm-mips/asm.h should be fixed
instead of Makefile.  Still investigating...

---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Tue Aug 12 11:05:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 11:05:13 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:15114
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225072AbTHLKFL>; Tue, 12 Aug 2003 11:05: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; 12 Aug 2003 10:05:09 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h7CA522S000664
	for <linux-mips@linux-mips.org>; Tue, 12 Aug 2003 19:05:02 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Tue, 12 Aug 2003 19:06:36 +0900 (JST)
Message-Id: <20030812.190636.39150536.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp>
	<20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de>
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: 3031
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Tue, 12 Aug 2003 08:51:18 +0200, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> said:
>> The option -march=r4600 seems to make gcc 3.3.x choose
>> MIPS_ISA_MIPS3.

Thiemo> Which is ok, because the available ISA has little to do with
Thiemo> the actually used register width.

Thiemo> If the intention is to use mfc0 for 32bit kernels and dmfc0
Thiemo> for 64bit, the check should probably be

Thiemo> #ifdef __mips64
Thiemo> # define MFC0		dmfc0
Thiemo> # define MTC0		dmtc0
Thiemo> #else
Thiemo> # define MFC0		mfc0
Thiemo> # define MTC0		mtc0
Thiemo> #endif

Thanks for your explanations.  Perhaps the code should be fixed is
__BUILD_clear_ade in entry.S, but I'm not sure.  Does anybody know why
__BUILD_clear_ade uses MFC0 and REG_S though other parts using mfc0
and sw ?

From ica2_ts@csv.ica.uni-stuttgart.de Tue Aug 12 11:16:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 11:16:29 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:19550
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225072AbTHLKQ1>; Tue, 12 Aug 2003 11:16:27 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19mWCX-0000TL-00
	for linux-mips@linux-mips.org; Tue, 12 Aug 2003 12:16:25 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19mWCX-0001a4-00
	for <linux-mips@linux-mips.org>; Tue, 12 Aug 2003 12:16:25 +0200
Date: Tue, 12 Aug 2003 12:16:25 +0200
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030812101625.GJ23104@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp> <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de> <20030812.190636.39150536.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030812.190636.39150536.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3032
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Atsushi Nemoto wrote:
> >>>>> On Tue, 12 Aug 2003 08:51:18 +0200, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> said:
> >> The option -march=r4600 seems to make gcc 3.3.x choose
> >> MIPS_ISA_MIPS3.
> 
> Thiemo> Which is ok, because the available ISA has little to do with
> Thiemo> the actually used register width.
> 
> Thiemo> If the intention is to use mfc0 for 32bit kernels and dmfc0
> Thiemo> for 64bit, the check should probably be
> 
> Thiemo> #ifdef __mips64
> Thiemo> # define MFC0		dmfc0
> Thiemo> # define MTC0		dmtc0
> Thiemo> #else
> Thiemo> # define MFC0		mfc0
> Thiemo> # define MTC0		mtc0
> Thiemo> #endif
> 
> Thanks for your explanations.  Perhaps the code should be fixed is
> __BUILD_clear_ade in entry.S, but I'm not sure.  Does anybody know why
> __BUILD_clear_ade uses MFC0 and REG_S though other parts using mfc0
> and sw ?

Probably because BADVADDR has to be 64bit for 64bit kernels. :-)


Thiemo

From chris@mips.com Tue Aug 12 12:21:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 12:21:31 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:8722 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225072AbTHLLV1>;
	Tue, 12 Aug 2003 12:21:27 +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 19mXEG-0000Xn-00; Tue, 12 Aug 2003 12:22:16 +0100
Received: from holborn.algor.co.uk ([192.168.192.237] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 19mXDA-0001wE-00; Tue, 12 Aug 2003 12:21:08 +0100
Message-ID: <3F38CDA4.40208@mips.com>
Date: Tue, 12 Aug 2003 12:21:08 +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.0) Gecko/20020623 Debian/1.0.0-0.woody.1
MIME-Version: 1.0
To: David Kesselring <dkesselr@mmc.atmel.com>
CC: linux-mips@linux-mips.org
Subject: Re: C0 config reg for 5k core
References: <Pine.GSO.4.44.0308111422220.4449-100000@ares.mmc.atmel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-1.5, required 4, AWL,
	EMAIL_ATTRIBUTION, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES,
	USER_AGENT_MOZILLA_UA)
Return-Path: <chris@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3033
X-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

David Kesselring wrote:
> Has anyone else built linux 2.4 for a 5k or 5kf core? When comparing cpu.h

   I have :)

> and the MIPS64 5K Processor Core Family Software Users Manual it doesn't
> look to me that the c0-config1 reg is defined the same way. Am I reading
> something wrong? For example in the spec FPU flag is bit0 while in cpu.h
> it is bit4. Seems pretty basic.

   The option bits defined in cpu.h are software flags.  See 
arch/mips/kernel/setup.c where these flags are set for each processor by 
reading appropriate registers.

	Regards
		Chris

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


From dkesselr@mmc.atmel.com Tue Aug 12 13:39:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 13:39:40 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:54217
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225072AbTHLMji>; Tue, 12 Aug 2003 13:39:38 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id IAA16529
	for <linux-mips@linux-mips.org>; Tue, 12 Aug 2003 08:39:30 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id IAA05163
	for <linux-mips@linux-mips.org>; Tue, 12 Aug 2003 08:39:30 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Tue, 12 Aug 2003 08:39:30 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: Re: C0 config reg for 5k core
In-Reply-To: <3F38CDA4.40208@mips.com>
Message-ID: <Pine.GSO.4.44.0308120835500.4727-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3034
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

I see what is going on now. Thanks.

On Tue, 12 Aug 2003, Chris Dearman wrote:

> David Kesselring wrote:
> > Has anyone else built linux 2.4 for a 5k or 5kf core? When comparing cpu.h
>
>    I have :)
>
> > and the MIPS64 5K Processor Core Family Software Users Manual it doesn't
> > look to me that the c0-config1 reg is defined the same way. Am I reading
> > something wrong? For example in the spec FPU flag is bit0 while in cpu.h
> > it is bit4. Seems pretty basic.
>
>    The option bits defined in cpu.h are software flags.  See
> arch/mips/kernel/setup.c where these flags are set for each processor by
> reading appropriate registers.
>
> 	Regards
> 		Chris
>
> --
> Chris Dearman          The Fruit Farm, Ely Road    voice +44 1223 706206
> MIPS Technologies (UK) Chittering, Cambs, CB5 9PH  fax   +44 1223 706250
>
>
>

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


From macro@ds2.pg.gda.pl Tue Aug 12 14:34:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 14:34:40 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:57326 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225288AbTHLNei>; Tue, 12 Aug 2003 14:34:38 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA07910;
	Tue, 12 Aug 2003 15:34:27 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 12 Aug 2003 15:34:25 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time trailing clean-ups
In-Reply-To: <20030811113428.F9020@mvista.com>
Message-ID: <Pine.GSO.3.96.1030812125503.5935B-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: 3035
X-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, 11 Aug 2003, Jun Sun wrote:

> >  Here is hopefully the final part (for now) of the generic time changes.
> > It addresses the following problems:
> > 
> > -	 */
> > -	if (!jiffies) {
> > -		timerhi = timerlo = 0;
> > -		mips_hpt_init(count);
> > +	 *
> > +	 * The first timer interrupt comes late as interrupts are
> > +	 * enabled long after timers are initialized.  Therefore the
> > +	 * high precision timer is fast, leading to wrong gettimeoffset()
> > +	 * calculations.  We deal with it by setting it based on the
> > +	 * number of its ticks between the second and the third interrupt.
> > +	 * That is still somewhat imprecise, but it's a good estimate.
> > +	 * --macro
> > +	 */
> > +	j = jiffies;
> > +	if (j < 4) {
> > +		static unsigned int prev_count;
> > +		static int hpt_initialized;
> > +
> > +		switch (j) {
> > +		case 0:
> > +			timerhi = timerlo = 0;
> > +			mips_hpt_init(count);
> > +			break;
> > +		case 2:
> > +			prev_count = count;
> > +			break;
> > +		case 3:
> > +			if (!hpt_initialized) {
> > +				unsigned int c3 = 3 * (count - prev_count);
> > +
> > +				timerhi = 0;
> > +				timerlo = c3;
> > +				mips_hpt_init(count - c3);
> > +				hpt_initialized = 1;
> > +			}
> > +			break;
> > +		default:
> > +			break;
> > +		}
> >  	}
> > 
> 
> The first gettimeoffset() call is way after many jiffies (~50 normally?).  Such
> an estimate is not necessary.

 As a number of interrupts is lost (at least half a second worth of; it
depends on how long console_init() executes), it takes a few minutes for
gettimeoffset() to recover from the error -- r0 (which is the number of
HPT ticks in a jiffy) is too high.  As a result, offsets within jiffies as
calculated by gettimeoffset() are distributed unevenly.  You may not care,
but I use NTP on my systems and I do care.  With the above initialization,
r0 is almost correct from the beginning and after a few minutes of uptime
the error is no higher than one tick. 

 The fixed_rate_gettimeoffset() backend doesn't care but the calibrate_*()
ones do.

> Also note jiffies can wrap around.  

 Yep, it's already handled and the change above preserves it.

-- 
+  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 Aug 12 14:56:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 14:56:41 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:60400 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225288AbTHLN4j>; Tue, 12 Aug 2003 14:56:39 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA08158;
	Tue, 12 Aug 2003 15:56:27 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 12 Aug 2003 15:56:27 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
In-Reply-To: <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030812155517.7029C-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: 3036
X-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, 12 Aug 2003, Thiemo Seufer wrote:

> If the intention is to use mfc0 for 32bit kernels and dmfc0 for 64bit,
> the check should probably be
> 
> #ifdef __mips64
> # define MFC0		dmfc0
> # define MTC0		dmtc0
> #else
> # define MFC0		mfc0
> # define MTC0		mtc0
> #endif

 I'd go for CONFIG_MIPS64 here.

-- 
+  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 Tue Aug 12 15:04:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 15:04:56 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:14175
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225290AbTHLOEy>; Tue, 12 Aug 2003 15:04:54 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19mZlc-0001rz-00
	for linux-mips@linux-mips.org; Tue, 12 Aug 2003 16:04:52 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19mZlc-0001wt-00
	for <linux-mips@linux-mips.org>; Tue, 12 Aug 2003 16:04:52 +0200
Date: Tue, 12 Aug 2003 16:04:52 +0200
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030812140452.GD10792@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030812155517.7029C-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.1030812155517.7029C-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3037
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
> On Tue, 12 Aug 2003, Thiemo Seufer wrote:
> 
> > If the intention is to use mfc0 for 32bit kernels and dmfc0 for 64bit,
> > the check should probably be
> > 
> > #ifdef __mips64
> > # define MFC0		dmfc0
> > # define MTC0		dmtc0
> > #else
> > # define MFC0		mfc0
> > # define MTC0		mtc0
> > #endif
> 
>  I'd go for CONFIG_MIPS64 here.

This would work as well, but I prefer compiler intrinsic defines
over custom configury.


Thiemo

From macro@ds2.pg.gda.pl Tue Aug 12 15:40:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 15:40:22 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:47092 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225072AbTHLOkT>; Tue, 12 Aug 2003 15:40:19 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA08773
	for <linux-mips@linux-mips.org>; Tue, 12 Aug 2003 16:40:16 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 12 Aug 2003 16:40:15 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
In-Reply-To: <20030812140452.GD10792@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030812163438.7029F-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: 3038
X-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, 12 Aug 2003, Thiemo Seufer wrote:

> > > If the intention is to use mfc0 for 32bit kernels and dmfc0 for 64bit,
> > > the check should probably be
> > > 
> > > #ifdef __mips64
> > > # define MFC0		dmfc0
> > > # define MTC0		dmtc0
> > > #else
> > > # define MFC0		mfc0
> > > # define MTC0		mtc0
> > > #endif
> > 
> >  I'd go for CONFIG_MIPS64 here.
> 
> This would work as well, but I prefer compiler intrinsic defines
> over custom configury.

 Well, for Linux it seems appropriate to use a kernel's configuration to
select run-time behaviour -- in this case it's CONFIG_MIPS64 that was
selected by a user that matters (i.e. that we use 64-bit addressing) and
not a compiler's configuration.  Just the opposite to what's expected in
the userland. 

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


From anemo@mba.ocn.ne.jp Tue Aug 12 16:13:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 16:13:41 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:44541 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225072AbTHLPNa>; Tue, 12 Aug 2003 16:13:30 +0100
Received: from localhost (p0964-ip01funabasi.chiba.ocn.ne.jp [61.119.148.202])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id CAC5421A5
	for <linux-mips@linux-mips.org>; Wed, 13 Aug 2003 00:13:23 +0900 (JST)
Date: Wed, 13 Aug 2003 00:26:44 +0900 (JST)
Message-Id: <20030813.002644.59461513.anemo@mba.ocn.ne.jp>
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030812101625.GJ23104@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de>
	<20030812.190636.39150536.nemoto@toshiba-tops.co.jp>
	<20030812101625.GJ23104@rembrandt.csv.ica.uni-stuttgart.de>
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: 3039
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Tue, 12 Aug 2003 12:16:25 +0200, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> said:

>> Does anybody know why __BUILD_clear_ade uses MFC0 and REG_S
>> though other parts using mfc0 and sw ?

Thiemo> Probably because BADVADDR has to be 64bit for 64bit
Thiemo> kernels. :-)

If so, MFC0 and REG_S should be controlled by __mips64 (or
CONFIG_MIPS64) as you and Maciej W. Rozycki said in other mails.  I
wonder why currently is not.  Historical reason ? :-)

Now I'm looking 2.6 codes and there is same problem.  But 2.6 codes
does not use REG_S at all so the stack corruption will never happen.
FYI.

--- Atsushi Nemoto

From jsun@mvista.com Tue Aug 12 18:05:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Aug 2003 18:05:43 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:23280 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225072AbTHLRFl>;
	Tue, 12 Aug 2003 18:05:41 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h7CH5bN30210;
	Tue, 12 Aug 2003 10:05:37 -0700
Date: Tue, 12 Aug 2003 10:05:37 -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] Generic time trailing clean-ups
Message-ID: <20030812100537.B30067@mvista.com>
References: <20030811113428.F9020@mvista.com> <Pine.GSO.3.96.1030812125503.5935B-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.1030812125503.5935B-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Aug 12, 2003 at 03:34:25PM +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: 3040
X-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, Aug 12, 2003 at 03:34:25PM +0200, Maciej W. Rozycki wrote:
> On Mon, 11 Aug 2003, Jun Sun wrote:
> 
> > >  Here is hopefully the final part (for now) of the generic time changes.
> > > It addresses the following problems:
> > > 
> > > -	 */
> > > -	if (!jiffies) {
> > > -		timerhi = timerlo = 0;
> > > -		mips_hpt_init(count);
> > > +	 *
> > > +	 * The first timer interrupt comes late as interrupts are
> > > +	 * enabled long after timers are initialized.  Therefore the
> > > +	 * high precision timer is fast, leading to wrong gettimeoffset()
> > > +	 * calculations.  We deal with it by setting it based on the
> > > +	 * number of its ticks between the second and the third interrupt.
> > > +	 * That is still somewhat imprecise, but it's a good estimate.
> > > +	 * --macro
> > > +	 */
> > > +	j = jiffies;
> > > +	if (j < 4) {
> > > +		static unsigned int prev_count;
> > > +		static int hpt_initialized;
> > > +
> > > +		switch (j) {
> > > +		case 0:
> > > +			timerhi = timerlo = 0;
> > > +			mips_hpt_init(count);
> > > +			break;
> > > +		case 2:
> > > +			prev_count = count;
> > > +			break;
> > > +		case 3:
> > > +			if (!hpt_initialized) {
> > > +				unsigned int c3 = 3 * (count - prev_count);
> > > +
> > > +				timerhi = 0;
> > > +				timerlo = c3;
> > > +				mips_hpt_init(count - c3);
> > > +				hpt_initialized = 1;
> > > +			}
> > > +			break;
> > > +		default:
> > > +			break;
> > > +		}
> > >  	}
> > > 
> > 
> > The first gettimeoffset() call is way after many jiffies (~50 normally?).  Such
> > an estimate is not necessary.
> 
>  As a number of interrupts is lost (at least half a second worth of; it
> depends on how long console_init() executes), it takes a few minutes for
> gettimeoffset() to recover from the error -- r0 (which is the number of
> HPT ticks in a jiffy) is too high.  As a result, offsets within jiffies as
> calculated by gettimeoffset() are distributed unevenly.  You may not care,
> but I use NTP on my systems and I do care.  With the above initialization,
> r0 is almost correct from the beginning and after a few minutes of uptime
> the error is no higher than one tick. 
> 
>  The fixed_rate_gettimeoffset() backend doesn't care but the calibrate_*()
> ones do.

Perhaps we should always calibrate the counter frequency and forget about
all those calibrate_*() routines.  This will allow us to get rid of a few
funtions.  Plus knowing the frequency is generally a good thing (for some
performance measurement, for example).

I have a patch floating around just doing that, and in MontaVista tree
we have already done for a long time.

The patch is at 

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

(Wow!  I can't believe it was done almost two years ago.)

Jun

From macro@ds2.pg.gda.pl Wed Aug 13 13:25:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Aug 2003 13:25:22 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:2267 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225072AbTHMMZT>; Wed, 13 Aug 2003 13:25:19 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA26553;
	Wed, 13 Aug 2003 14:25:13 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 13 Aug 2003 14:25:12 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time trailing clean-ups
In-Reply-To: <20030812100537.B30067@mvista.com>
Message-ID: <Pine.GSO.3.96.1030813135602.25530C-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: 3041
X-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, 12 Aug 2003, Jun Sun wrote:

> >  As a number of interrupts is lost (at least half a second worth of; it
> > depends on how long console_init() executes), it takes a few minutes for
> > gettimeoffset() to recover from the error -- r0 (which is the number of
> > HPT ticks in a jiffy) is too high.  As a result, offsets within jiffies as
> > calculated by gettimeoffset() are distributed unevenly.  You may not care,
> > but I use NTP on my systems and I do care.  With the above initialization,
> > r0 is almost correct from the beginning and after a few minutes of uptime
> > the error is no higher than one tick. 
> > 
> >  The fixed_rate_gettimeoffset() backend doesn't care but the calibrate_*()
> > ones do.
> 
> Perhaps we should always calibrate the counter frequency and forget about
> all those calibrate_*() routines.  This will allow us to get rid of a few
> funtions.  Plus knowing the frequency is generally a good thing (for some
> performance measurement, for example).

 Of course calibrating the counter frequency beforehand would be a Good
Thing, but that's not exactly trivial.

> I have a patch floating around just doing that, and in MontaVista tree
> we have already done for a long time.
> 
> The patch is at 
> 
> http://linux.junsun.net/patches/oss.sgi.com/experimental/011128.calibrate_mips_counter.patch
> 
> (Wow!  I can't believe it was done almost two years ago.)

 That's good enough as a temporary hack, but not as a final solution.  I
think we need to do the calibration similarly to how calibrate_tsc() or
calibrate_APIC_clock() do that for the i386.  Specifically, we need to do
that with polling for appropriate accuracy (interrupt delivery time might
not be deterministic) and preferably before interrupts are enabled
(time_init() looks like a perfect place to do that).  And of course we
need to poll against the interrupt source as it's the frequency ratio that
matters (otherwise I could e.g. just read the TURBOchannel clock frequency
as reported by the firmware for the HPT on R3k DECstations).  That means
it needs to be done in platform-specific way.

 I have an idea how to make an abstraction layer for this purpose and I'll
make a patch for the DECstation soon.  The plan might be as follows: 

1. I'll apply the patch as is (Ralf has already approved it off-list) as
the calibrate_*() backends won't disappear immediately anyway. 

2. I'll provide the abstraction layer together with an example
implementation for the DECstation.

3. For 2.6 I'll add a warning about uninitialized mips_counter_frequency
and deprecation of calibrate_*() backends, so that platform maintainers
know what's going on.

4. After 2.7 starts code related to calibrate_*() will be removed and the
kernel will panic() if a HPT is found, but mips_counter_frequency is zero.

Any comments?

  Maciej

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


From demiurg@ti.com Wed Aug 13 14:46:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Aug 2003 14:46:38 +0100 (BST)
Received: from news.ti.com ([IPv6:::ffff:192.94.94.33]:55971 "EHLO
	dragon.ti.com") by linux-mips.org with ESMTP id <S8225289AbTHMNqZ>;
	Wed, 13 Aug 2003 14:46:25 +0100
Received: from dlep52.itg.ti.com ([157.170.134.103])
	by dragon.ti.com (8.12.9/8.12.9) with ESMTP id h7DDkH1p012950
	for <linux-mips@linux-mips.org>; Wed, 13 Aug 2003 08:46:18 -0500 (CDT)
Received: from dlep90.itg.ti.com (localhost [127.0.0.1])
	by dlep52.itg.ti.com (8.12.9/8.12.9) with ESMTP id h7DDkHTh018445
	for <linux-mips@linux-mips.org>; Wed, 13 Aug 2003 08:46:17 -0500 (CDT)
Received: from dlee70.itg.ti.com (dlee70.itg.ti.com [157.170.135.145])
	by dlep90.itg.ti.com (8.12.9/8.12.9) with ESMTP id h7DDkHJ5007891
	for <linux-mips@linux-mips.org>; Wed, 13 Aug 2003 08:46:17 -0500 (CDT)
Received: by dlee70.itg.ti.com with Internet Mail Service (5.5.2653.19)
	id <QZCGK96C>; Wed, 13 Aug 2003 08:46:17 -0500
Received: from ti.com (cbc0794930.isr.asp.ti.com [137.167.2.134]) by dile70.itg.ti.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id QZ2BQF5F; Wed, 13 Aug 2003 16:46:04 +0300
From: "Sirotkin, Alexander" <demiurg@ti.com>
To: linux-mips@linux-mips.org
Message-ID: <3F3A411C.70603@ti.com>
Date: Wed, 13 Aug 2003 16:46:04 +0300
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
Subject: tasklet latency and system calls on mips
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <demiurg@ti.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3042
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: demiurg@ti.com
Precedence: bulk
X-list: linux-mips

Hello dearest all.

I have a question regarding tasklets on MIPS. I suspect that there is a
bug in generic MIPS kernel, but I'm not sure yet.

Linux kernel has a couple of so called "checkpoints" when the system
should check if there are tasklets to
run and run them in the following way :

if (softirq_pending(cpu))
                    do_softirq();

One of these places is at the end of interrupt handler (do_IRQ()),
however this is not the only place. I was under
impression that this code should be called after system call too. The
caveat here is that on MIPS (contrary to
other architectures, such as x86) system call is not an interrupt (it's
a different exception) and has completely
different handler. So in x86 it is sufficient to call

if (softirq_pending(cpu))
                    do_softirq();

at the end of do_IRQ because do_IRQ handles system call too, but on MIPS
it is not. Therefore I believe
these lines should be added to the end of sys_syscall function on MIPS.

What do you think ?

P.S. The whole issue started when we noticed that user process making
many system calls has very
significant impact on device drivers running in tasklet mode and no
impact whatsoever on device
drivers running in interrupt mode.


From jsun@mvista.com Wed Aug 13 17:45:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Aug 2003 17:46:00 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:5364 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225294AbTHMQpr>;
	Wed, 13 Aug 2003 17:45:47 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h7DGjfH09736;
	Wed, 13 Aug 2003 09:45:41 -0700
Date: Wed, 13 Aug 2003 09:45:41 -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] Generic time trailing clean-ups
Message-ID: <20030813094541.B9655@mvista.com>
References: <20030812100537.B30067@mvista.com> <Pine.GSO.3.96.1030813135602.25530C-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.1030813135602.25530C-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Aug 13, 2003 at 02:25:12PM +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: 3043
X-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, Aug 13, 2003 at 02:25:12PM +0200, Maciej W. Rozycki wrote:
> On Tue, 12 Aug 2003, Jun Sun wrote:
> 
> > >  As a number of interrupts is lost (at least half a second worth of; it
> > > depends on how long console_init() executes), it takes a few minutes for
> > > gettimeoffset() to recover from the error -- r0 (which is the number of
> > > HPT ticks in a jiffy) is too high.  As a result, offsets within jiffies as
> > > calculated by gettimeoffset() are distributed unevenly.  You may not care,
> > > but I use NTP on my systems and I do care.  With the above initialization,
> > > r0 is almost correct from the beginning and after a few minutes of uptime
> > > the error is no higher than one tick. 
> > > 
> > >  The fixed_rate_gettimeoffset() backend doesn't care but the calibrate_*()
> > > ones do.
> > 
> > Perhaps we should always calibrate the counter frequency and forget about
> > all those calibrate_*() routines.  This will allow us to get rid of a few
> > funtions.  Plus knowing the frequency is generally a good thing (for some
> > performance measurement, for example).
> 
>  Of course calibrating the counter frequency beforehand would be a Good
> Thing, but that's not exactly trivial.
> 
> > I have a patch floating around just doing that, and in MontaVista tree
> > we have already done for a long time.
> > 
> > The patch is at 
> > 
> > http://linux.junsun.net/patches/oss.sgi.com/experimental/011128.calibrate_mips_counter.patch
> > 
> > (Wow!  I can't believe it was done almost two years ago.)
> 
>  That's good enough as a temporary hack, but not as a final solution.  I
> think we need to do the calibration similarly to how calibrate_tsc() or
> calibrate_APIC_clock() do that for the i386.  Specifically, we need to do
> that with polling for appropriate accuracy (interrupt delivery time might
> not be deterministic) and preferably before interrupts are enabled
> (time_init() looks like a perfect place to do that).  And of course we
> need to poll against the interrupt source as it's the frequency ratio that
> matters (otherwise I could e.g. just read the TURBOchannel clock frequency
> as reported by the firmware for the HPT on R3k DECstations).  That means
> it needs to be done in platform-specific way.
>

I don't like this idea.  This is way too much over-doing for little gain.

When counter frequency is calibrated, the system is just starting.  The interrupt
delivery time is rather deterministic. 

Then you also need to put into perspective of its usage in gettimeoffset.
We are talking about micro-second resolution.  calibration obtained this way
is accurate enough.

Over-abstraction is very bad for OS.  We need to recognize that danger.

In addition, this change expands MIPS common and board interface and increases
board-layer porting work.

>  I have an idea how to make an abstraction layer for this purpose and I'll
> make a patch for the DECstation soon.  The plan might be as follows: 
> 
> 1. I'll apply the patch as is (Ralf has already approved it off-list) as
> the calibrate_*() backends won't disappear immediately anyway. 
>

If you take the above view, the obvious action is to apply the 
calibration patch and get rid of all various calibrate_* routines.

Of course, future improvement is still possible even with doing this.  For example,
one interesting item is to calibrate and sync counters on a SMP system.

> 2. I'll provide the abstraction layer together with an example
> implementation for the DECstation.
> 
> 3. For 2.6 I'll add a warning about uninitialized mips_counter_frequency
> and deprecation of calibrate_*() backends, so that platform maintainers
> know what's going on.
> 
> 4. After 2.7 starts code related to calibrate_*() will be removed and the
> kernel will panic() if a HPT is found, but mips_counter_frequency is zero.
> 
> Any comments?
> 

That is my two cents.  

BTW, I am drafting a proposal to use a native high resolution clock/timer
interface for 2.7 kernel, with jiffie timer emulated on top of it.  If adopted, 
that will change the whole picture obviously.  But that is too far to be
a real factor here.  The only implication to MIPS is probably that we should 
encourage people to use CPU counter as the system timer as much as possible.
This will increase maximum code sharing and is future-proof.

Jun

From jsun@mvista.com Wed Aug 13 17:54:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Aug 2003 17:54:50 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:41206 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225294AbTHMQys>;
	Wed, 13 Aug 2003 17:54:48 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h7DGskj09878;
	Wed, 13 Aug 2003 09:54:46 -0700
Date: Wed, 13 Aug 2003 09:54:46 -0700
From: Jun Sun <jsun@mvista.com>
To: "Sirotkin, Alexander" <demiurg@ti.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: tasklet latency and system calls on mips
Message-ID: <20030813095446.C9655@mvista.com>
References: <3F3A411C.70603@ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3F3A411C.70603@ti.com>; from demiurg@ti.com on Wed, Aug 13, 2003 at 04:46:04PM +0300
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: 3044
X-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, Aug 13, 2003 at 04:46:04PM +0300, Sirotkin, Alexander wrote:
> Hello dearest all.
> 
> I have a question regarding tasklets on MIPS. I suspect that there is a
> bug in generic MIPS kernel, but I'm not sure yet.
> 
> Linux kernel has a couple of so called "checkpoints" when the system
> should check if there are tasklets to
> run and run them in the following way :
> 
> if (softirq_pending(cpu))
>                     do_softirq();
> 
> One of these places is at the end of interrupt handler (do_IRQ()),
> however this is not the only place. I was under
> impression that this code should be called after system call too. The
> caveat here is that on MIPS (contrary to
> other architectures, such as x86) system call is not an interrupt (it's
> a different exception) and has completely
> different handler. So in x86 it is sufficient to call
> 
> if (softirq_pending(cpu))
>                     do_softirq();
> 
> at the end of do_IRQ because do_IRQ handles system call too, but on MIPS
> it is not. Therefore I believe
> these lines should be added to the end of sys_syscall function on MIPS.
> 
> What do you think ?
> 

softirq/tasklet/bottom_half/etc should only be raised from interrupt
context.  Checking at the end of do_IRQ should be good enough.

One possible mistake in MIPS porting is that if the board uses its private
time interrupt routine poeple may forget to put the above two lines
at the end.  Check against that.

> P.S. The whole issue started when we noticed that user process making
> many system calls has very
> significant impact on device drivers running in tasklet mode 

What kind of impact?  On i386? Or on MIPS?

Jun

From ica2_ts@csv.ica.uni-stuttgart.de Thu Aug 14 04:04:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Aug 2003 04:04:04 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:57189
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225193AbTHNDEC>; Thu, 14 Aug 2003 04:04:02 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19n8PA-0005pJ-00
	for linux-mips@linux-mips.org; Thu, 14 Aug 2003 05:04:00 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19n8P9-000837-00
	for <linux-mips@linux-mips.org>; Thu, 14 Aug 2003 05:03:59 +0200
Date: Thu, 14 Aug 2003 05:03:59 +0200
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030814030359.GJ10792@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de> <20030812.190636.39150536.nemoto@toshiba-tops.co.jp> <20030812101625.GJ23104@rembrandt.csv.ica.uni-stuttgart.de> <20030813.002644.59461513.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030813.002644.59461513.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3045
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Atsushi Nemoto wrote:
> >>>>> On Tue, 12 Aug 2003 12:16:25 +0200, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> said:
> 
> >> Does anybody know why __BUILD_clear_ade uses MFC0 and REG_S
> >> though other parts using mfc0 and sw ?
> 
> Thiemo> Probably because BADVADDR has to be 64bit for 64bit
> Thiemo> kernels. :-)
> 
> If so, MFC0 and REG_S should be controlled by __mips64 (or
> CONFIG_MIPS64) as you and Maciej W. Rozycki said in other mails.  I
> wonder why currently is not.  Historical reason ? :-)

Pre-3.0 gcc used -mips2 instead of -mabi=32 as hint to generate
32bit code. I guess the defines were affected by this also.


Thiemo

From ica2_ts@csv.ica.uni-stuttgart.de Thu Aug 14 04:08:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Aug 2003 04:08:45 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:59493
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225208AbTHNDIm>; Thu, 14 Aug 2003 04:08:42 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19n8Th-0005rQ-00
	for linux-mips@linux-mips.org; Thu, 14 Aug 2003 05:08:41 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19n8Th-00083c-00
	for <linux-mips@linux-mips.org>; Thu, 14 Aug 2003 05:08:41 +0200
Date: Thu, 14 Aug 2003 05:08:41 +0200
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030814030841.GK10792@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030812140452.GD10792@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030812163438.7029F-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.1030812163438.7029F-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3046
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
> On Tue, 12 Aug 2003, Thiemo Seufer wrote:
> 
> > > > If the intention is to use mfc0 for 32bit kernels and dmfc0 for 64bit,
> > > > the check should probably be
> > > > 
> > > > #ifdef __mips64
> > > > # define MFC0		dmfc0
> > > > # define MTC0		dmtc0
> > > > #else
> > > > # define MFC0		mfc0
> > > > # define MTC0		mtc0
> > > > #endif
> > > 
> > >  I'd go for CONFIG_MIPS64 here.
> > 
> > This would work as well, but I prefer compiler intrinsic defines
> > over custom configury.
> 
>  Well, for Linux it seems appropriate to use a kernel's configuration to
> select run-time behaviour -- in this case it's CONFIG_MIPS64 that was
> selected by a user that matters (i.e. that we use 64-bit addressing) and
> not a compiler's configuration.  Just the opposite to what's expected in
> the userland. 

JFTR:
__mips64 denotes neither 64-bit addressing nor the compiler configuration.
It just means that the generated code uses 64 bit wide registers.


Thiemo

From wom@tateyama.hu Thu Aug 14 10:59:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Aug 2003 10:59:39 +0100 (BST)
Received: from c01.tateyama.hu ([IPv6:::ffff:152.66.119.129]:62212 "HELO
	server.tateyama.hu") by linux-mips.org with SMTP
	id <S8225209AbTHNJ7a>; Thu, 14 Aug 2003 10:59:30 +0100
Received: (qmail 32268 invoked from network); 14 Aug 2003 09:59:23 -0000
Received: from c22.tateyama.hu (152.66.119.150)
  by c01.tateyama.hu with SMTP; 14 Aug 2003 09:59:23 -0000
From: Gabor Kerenyi <wom@tateyama.hu>
Organization: Tateyama Ltd.
To: linux-mips@linux-mips.org
Subject: General I/O
Date: Thu, 14 Aug 2003 12:12:38 +0200
User-Agent: KMail/1.5.3
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200308141212.38679.wom@tateyama.hu>
Return-Path: <wom@tateyama.hu>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3047
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wom@tateyama.hu
Precedence: bulk
X-list: linux-mips

Hi!

I have a board with VR4181A. I would like to read/write
the General I/O port but I can't find anything how to do it.

I could wrote a small driver to setup and handle an interrupt
on GUINT0 using vr41xx_set_irq_trigger (a simple switch is
connected to PIN0)
But I need to set/clear pins to be able to connect an EEPROM
to GPIO and some other stuff.

I can't find functions to do this simple like set_gio(pin, state).

Can someone help?

The board is not known by anyone, it's made in Japan
(TOADKK-TCS8000).

Thanks,

Gabor


From macro@ds2.pg.gda.pl Thu Aug 14 12:31:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Aug 2003 12:31:46 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:46777 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225209AbTHNLbn>; Thu, 14 Aug 2003 12:31:43 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA15064;
	Thu, 14 Aug 2003 13:31:31 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 14 Aug 2003 13:31:31 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time trailing clean-ups
In-Reply-To: <20030813094541.B9655@mvista.com>
Message-ID: <Pine.GSO.3.96.1030814121949.14241A-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: 3048
X-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, 13 Aug 2003, Jun Sun wrote:

> >  That's good enough as a temporary hack, but not as a final solution.  I
> > think we need to do the calibration similarly to how calibrate_tsc() or
> > calibrate_APIC_clock() do that for the i386.  Specifically, we need to do
> > that with polling for appropriate accuracy (interrupt delivery time might
> > not be deterministic) and preferably before interrupts are enabled
> > (time_init() looks like a perfect place to do that).  And of course we
> > need to poll against the interrupt source as it's the frequency ratio that
> > matters (otherwise I could e.g. just read the TURBOchannel clock frequency
> > as reported by the firmware for the HPT on R3k DECstations).  That means
> > it needs to be done in platform-specific way.
> 
> I don't like this idea.  This is way too much over-doing for little gain.

 Well, others are doing it this way.  And for a reason. 

> When counter frequency is calibrated, the system is just starting.  The interrupt
> delivery time is rather deterministic. 

 Do you know all the interrupt controllers out there?  Cool.  But I don't,
and I am a wimp.  And I know e.g. the i386 has the message-driven APIC
which uses a relatively slow serial bus to transmit interrupt events to
processors.  And the delivery latency varies, depending on the arbitration
time, traffic on the bus, noise causing interrupt retransmits, etc. 
Search the LKML archive for recurring discussions about interrupt
latencies. 

> Then you also need to put into perspective of its usage in gettimeoffset.
> We are talking about micro-second resolution.  calibration obtained this way
> is accurate enough.

 Nanosecond for the 2.6 upwards.  And you don't want to have time
"freezes" (i.e. consecutive gettimeofday() calls returning the same value)
due to an overflow at the end of a jiffy, do you?

 Anyway, your change affects the core.  Have you tried submitting it to
Linus?  Or discussing at the LKML?  Interesting ideas might arise.

> Over-abstraction is very bad for OS.  We need to recognize that danger.

 Code duplication is yet worse.  This is the price paid for being
multiplatform within a single processor's architecture.  Compare that to
the i386 vs the PC/AT platform, although even that is changing these days.
And the Alpha at the other end, which uses platform specific vectors for
backends, even though Alphas don't differ as much as MIPS systems.

> In addition, this change expands MIPS common and board interface and increases
> board-layer porting work.

 What work?  It took me two minutes to add support for the DECstation for
the new interface.  That wasn't a big deal for me, even though whatever
I'm doing here, I am using my precious free time.  Compare it to various
changes say in drivers APIs happening every now and then.  But such is
Linux -- if something sucks and a better replacement is needed, it's done.

> >  I have an idea how to make an abstraction layer for this purpose and I'll
> > make a patch for the DECstation soon.  The plan might be as follows: 
> > 
> > 1. I'll apply the patch as is (Ralf has already approved it off-list) as
> > the calibrate_*() backends won't disappear immediately anyway. 
> 
> If you take the above view, the obvious action is to apply the 
> calibration patch and get rid of all various calibrate_* routines.

 That is the plan -- see the following points.  But 2.4 is too deep in the
maintenance stage to require all platforms to be updated.  Some are still
using private copies of time handlers!  But we can actually backport code
removal from 2.7 to later 2.6 if platforms get updated as appropriate.

> Of course, future improvement is still possible even with doing this.  For example,
> one interesting item is to calibrate and sync counters on a SMP system.

 Feel free to do this.  It shouldn't be that tough -- the i386 already
does that.  I don't have a SMP system to give me much enough incentive.

> > 2. I'll provide the abstraction layer together with an example
> > implementation for the DECstation.
> > 
> > 3. For 2.6 I'll add a warning about uninitialized mips_counter_frequency
> > and deprecation of calibrate_*() backends, so that platform maintainers
> > know what's going on.
> > 
> > 4. After 2.7 starts code related to calibrate_*() will be removed and the
> > kernel will panic() if a HPT is found, but mips_counter_frequency is zero.
> > 
> > Any comments?
> 
> That is my two cents.  
> 
> BTW, I am drafting a proposal to use a native high resolution clock/timer
> interface for 2.7 kernel, with jiffie timer emulated on top of it.  If adopted, 
> that will change the whole picture obviously.  But that is too far to be
> a real factor here.  The only implication to MIPS is probably that we should 
> encourage people to use CPU counter as the system timer as much as possible.
> This will increase maximum code sharing and is future-proof.

 I disagree -- the CPU counter should be used for the timer interrupt as
the last resort.  We might think of using it for scheduling purposes,
though (possibly with a different offset for each processor), and using an
external timer for timekeeping only.  This would give a cleaner handling
of timer events on SMP systems.  But I'm looking forward to seeing your
code when you have examples ready -- we can study the issues then (but
please keep in mind what the other ports or the core do in this matter).

 Here is my proposed patch.  It seems to work just fine both on an R3k
using a 25MHz external HPT and on an R4k using its internal HPT at 60MHz.
It lets all systems that have an external timer use the generic time code
by providing up to four backends (depending on the configuration),
typically quite trivial.  These systems that have no external timer at all
and need to rely on the R4k-style counter for timer interrupts, still need
to get its frequency from elsewhere (from the firmware, by hardcoding it,
etc.).  Once they do that, they can use the generic time code as well.

 OK to apply?  I'll update Documentation/mips/time.README when the dust
settles down.

  Maciej

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

patch-mips-2.4.21-20030811-mips-hpt-calibrate-3
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/au1000/common/time.c linux-mips-2.4.21-20030811/arch/mips/au1000/common/time.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/au1000/common/time.c	2003-03-26 03:56:33.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/au1000/common/time.c	2003-08-14 00:07:58.000000000 +0000
@@ -52,7 +52,7 @@ unsigned long missed_heart_beats = 0;
 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 rwlock_t xtime_lock;
-unsigned int mips_counter_frequency = 0;
+unsigned int mips_hpt_frequency = 0;
 
 /* Cycle counter value at the previous timer interrupt.. */
 static unsigned int timerhi = 0, timerlo = 0;
@@ -202,7 +202,7 @@ unsigned long cal_r4koff(void)
 
 	count = read_c0_count();
 	cpu_speed = count * 2;
-	mips_counter_frequency = count;
+	mips_hpt_frequency = count;
 	set_au1x00_uart_baud_base(((cpu_speed) / 4) / 16);
 	spin_unlock_irqrestore(&time_lock, flags);
 	return (cpu_speed / HZ);
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/ddb5xxx/ddb5476/setup.c linux-mips-2.4.21-20030811/arch/mips/ddb5xxx/ddb5476/setup.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/ddb5xxx/ddb5476/setup.c	2003-04-15 02:56:51.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/ddb5xxx/ddb5476/setup.c	2003-08-14 00:08:20.000000000 +0000
@@ -84,7 +84,7 @@ extern void rtc_ds1386_init(unsigned lon
 static void __init ddb_time_init(void)
 {
 #if defined(USE_CPU_COUNTER_TIMER)
-	mips_counter_frequency = CPU_COUNTER_FREQUENCY;
+	mips_hpt_frequency = CPU_COUNTER_FREQUENCY;
 #endif
 
 	/* we have ds1396 RTC chip */
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/ddb5xxx/ddb5477/setup.c linux-mips-2.4.21-20030811/arch/mips/ddb5xxx/ddb5477/setup.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/ddb5xxx/ddb5477/setup.c	2003-04-18 02:56:37.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/ddb5xxx/ddb5477/setup.c	2003-08-14 00:08:50.000000000 +0000
@@ -138,11 +138,11 @@ static void __init ddb_time_init(void)
 		bus_frequency = detect_bus_frequency(rtc_base);
 	}
 
-	/* mips_counter_frequency is 1/2 of the cpu core freq */
+	/* mips_hpt_frequency is 1/2 of the cpu core freq */
 	i =  (read_c0_config() >> 28 ) & 7;
 	if ((current_cpu_data.cputype == CPU_R5432) && (i == 3))
 		i = 4;
-	mips_counter_frequency = bus_frequency*(i+4)/4;
+	mips_hpt_frequency = bus_frequency*(i+4)/4;
 }
 
 extern int setup_irq(unsigned int irq, struct irqaction *irqaction);
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/dec/time.c linux-mips-2.4.21-20030811/arch/mips/dec/time.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/dec/time.c	2003-08-06 02:56:27.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/dec/time.c	2003-08-13 23:52:44.000000000 +0000
@@ -144,6 +144,11 @@ static int dec_rtc_set_mmss(unsigned lon
 }
 
 
+static int dec_timer_state(void)
+{
+	return (CMOS_READ(RTC_REG_C) & RTC_PF) != 0;
+}
+
 static void dec_timer_ack(void)
 {
 	CMOS_READ(RTC_REG_C);			/* Ack the RTC interrupt.  */
@@ -169,19 +174,23 @@ void __init dec_time_init(void)
 	rtc_get_time = dec_rtc_get_time;
 	rtc_set_mmss = dec_rtc_set_mmss;
 
+	mips_timer_state = dec_timer_state;
 	mips_timer_ack = dec_timer_ack;
+
 	if (!cpu_has_counter && IOASIC) {
 		/* For pre-R4k systems we use the I/O ASIC's counter.  */
 		mips_hpt_read = dec_ioasic_hpt_read;
 		mips_hpt_init = dec_ioasic_hpt_init;
 	}
+
+	/* Set up the rate of periodic DS1287 interrupts.  */
+	CMOS_WRITE(RTC_REF_CLCK_32KHZ | (16 - LOG_2_HZ), RTC_REG_A);
 }
 
 void __init dec_timer_setup(struct irqaction *irq)
 {
+	setup_irq(dec_interrupt[DEC_IRQ_RTC], irq);
+
 	/* Enable periodic DS1287 interrupts.  */
-	CMOS_WRITE(RTC_REF_CLCK_32KHZ | (16 - LOG_2_HZ), RTC_REG_A);
 	CMOS_WRITE(CMOS_READ(RTC_REG_B) | RTC_PIE, RTC_REG_B);
-
-	setup_irq(dec_interrupt[DEC_IRQ_RTC], irq);
 }
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/ite-boards/generic/time.c linux-mips-2.4.21-20030811/arch/mips/ite-boards/generic/time.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/ite-boards/generic/time.c	2003-04-26 02:56:37.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/ite-boards/generic/time.c	2003-08-14 00:09:30.000000000 +0000
@@ -114,7 +114,7 @@ hour_hw_to_bin(unsigned char c)
 
 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 unsigned int mips_hpt_frequency;
 
 /*
  * Figure out the r4k offset, the amount to increment the compare
@@ -138,12 +138,12 @@ static unsigned long __init cal_r4koff(v
 	while (CMOS_READ(RTC_REG_A) & RTC_UIP);
 	while (!(CMOS_READ(RTC_REG_A) & RTC_UIP));
 
-	mips_counter_frequency = read_c0_count();
+	mips_hpt_frequency = read_c0_count();
 
 	/* restore interrupts */
 	local_irq_restore(flags);
 
-	return (mips_counter_frequency / HZ);
+	return (mips_hpt_frequency / HZ);
 }
 
 static unsigned long 
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/kernel/time.c linux-mips-2.4.21-20030811/arch/mips/kernel/time.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/kernel/time.c	2003-08-11 20:57:07.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/kernel/time.c	2003-08-14 01:57:43.000000000 +0000
@@ -102,9 +102,9 @@ static void null_hpt_init(unsigned int c
 
 
 /*
- * Timer ack for a R4k-compatible timer of a known frequency.
+ * Timer ack for an R4k-compatible timer of a known frequency.
  */
-static void c0_fixed_timer_ack(void)
+static void c0_timer_ack(void)
 {
 	unsigned int count;
 
@@ -129,14 +129,14 @@ static unsigned int c0_hpt_read(void)
 	return read_c0_count();
 }
 
-/* For unknown frequency.  */
+/* For use solely as a high precision timer.  */
 static void c0_hpt_init(unsigned int count)
 {
 	write_c0_count(read_c0_count() - count);
 }
 
-/* For a known frequency.  Used as an interrupt source.  */
-static void c0_fixed_hpt_init(unsigned int count)
+/* For use both as a high precision timer and an interrupt source.  */
+static void c0_hpt_timer_init(unsigned int count)
 {
 	count = read_c0_count() - count;
 	expirelo = (count / cycles_per_jiffy + 1) * cycles_per_jiffy;
@@ -145,6 +145,7 @@ static void c0_fixed_hpt_init(unsigned i
 	write_c0_count(count);
 }
 
+int (*mips_timer_state)(void);
 void (*mips_timer_ack)(void);
 unsigned int (*mips_hpt_read)(void);
 void (*mips_hpt_init)(unsigned int);
@@ -548,7 +549,7 @@ asmlinkage void ll_local_timer_interrupt
  *
  * 1) board_time_init() -
  * 	a) (optional) set up RTC routines,
- *      b) (optional) calibrate and set the mips_counter_frequency
+ *      b) (optional) calibrate and set the mips_hpt_frequency
  *	    (only needed if you intended to use fixed_rate_gettimeoffset
  *	     or use cpu counter as timer interrupt source)
  * 2) setup xtime based on rtc_get_time().
@@ -563,7 +564,7 @@ asmlinkage void ll_local_timer_interrupt
 void (*board_time_init)(void);
 void (*board_timer_setup)(struct irqaction *irq);
 
-unsigned int mips_counter_frequency;
+unsigned int mips_hpt_frequency;
 
 static struct irqaction timer_irqaction = {
 	.handler = timer_interrupt,
@@ -571,6 +572,49 @@ static struct irqaction timer_irqaction 
 	.name = "timer",
 };
 
+static unsigned int __init calibrate_hpt(void)
+{
+	u64 frequency;
+	u32 hpt_start, hpt_end, hpt_count, hz;
+
+	const int loops = HZ / 10;
+	int log_2_loops = 0;
+	int i;
+
+	/*
+	 * We want to calibrate for 0.1s, but to avoid a 64-bit
+	 * division we round the number of loops up to the nearest
+	 * power of 2.
+	 */
+	while (loops > 1 << log_2_loops)
+		log_2_loops++;
+	i = 1 << log_2_loops;
+
+	/*
+	 * Wait for a rising edge of the timer interrupt.
+	 */
+	while (mips_timer_state());
+	while (!mips_timer_state());
+
+	/*
+	 * Now see how many high precision timer ticks happen
+	 * during the calculated number of periods between timer
+	 * interrupts.
+	 */
+	hpt_start = mips_hpt_read();
+	do {
+		while (mips_timer_state());
+		while (!mips_timer_state());
+	} while (--i);
+	hpt_end = mips_hpt_read();
+
+	hpt_count = hpt_end - hpt_start;
+	hz = HZ;
+	frequency = (u64)hpt_count * (u64)hz;
+
+	return frequency >> log_2_loops;
+}
+
 void __init time_init(void)
 {
 	if (board_time_init)
@@ -587,7 +631,7 @@ void __init time_init(void)
 		/* No high precision timer -- sorry.  */
 		mips_hpt_read = null_hpt_read;
 		mips_hpt_init = null_hpt_init;
-	} else if (!mips_counter_frequency) {
+	} else if (!mips_hpt_frequency && !mips_timer_state) {
 		/* A high precision timer of unknown frequency.  */
 		if (!mips_hpt_read) {
 			/* No external high precision timer -- use R4k.  */
@@ -610,27 +654,36 @@ void __init time_init(void)
 			 */
 			do_gettimeoffset = calibrate_div64_gettimeoffset;
 	} else {
-		/* We know counter frequency! */
+		/* We know counter frequency.  Or we can get it.  */
 		if (!mips_hpt_read) {
 			/* No external high precision timer -- use R4k.  */
 			mips_hpt_read = c0_hpt_read;
-			mips_hpt_init = c0_fixed_hpt_init;
 
-			if (!mips_timer_ack)
-				/* R4k timer interrupt ack.  */
-				mips_timer_ack = c0_fixed_timer_ack;
+			if (mips_timer_state)
+				mips_hpt_init = c0_hpt_init;
+			else {
+				/* No external timer interrupt -- use R4k.  */
+				mips_hpt_init = c0_hpt_timer_init;
+				mips_timer_ack = c0_timer_ack;
+			}
 		}
+		if (!mips_hpt_frequency)
+			mips_hpt_frequency = calibrate_hpt();
 
 		do_gettimeoffset = fixed_rate_gettimeoffset;
 
 		/* Calculate cache parameters.  */
-		cycles_per_jiffy = mips_counter_frequency / HZ;
+		cycles_per_jiffy = (mips_hpt_frequency + HZ / 2) / HZ;
 
 		/* sll32_usecs_per_cycle = 10^6 * 2^32 / mips_counter_freq  */
-		/* Any better way to do this?  */
-		sll32_usecs_per_cycle = mips_counter_frequency / 100000;
-		sll32_usecs_per_cycle = 0xffffffff / sll32_usecs_per_cycle;
-		sll32_usecs_per_cycle *= 10;
+		do_div64_32(sll32_usecs_per_cycle,
+			    1000000, mips_hpt_frequency / 2,
+			    mips_hpt_frequency);
+
+		/* Report the high precision timer rate for a reference.  */
+		printk("Using %u.%03u MHz high precision timer.\n",
+		       ((mips_hpt_frequency + 500) / 1000) / 1000,
+		       ((mips_hpt_frequency + 500) / 1000) % 1000);
 	}
 
 	if (!mips_timer_ack)
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/lasat/setup.c linux-mips-2.4.21-20030811/arch/mips/lasat/setup.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/lasat/setup.c	2003-04-15 02:56:53.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/lasat/setup.c	2003-08-14 00:09:41.000000000 +0000
@@ -138,7 +138,7 @@ static ide_ioreg_t lasat_ide_default_io_
 
 static void lasat_time_init(void)
 {
-	mips_counter_frequency = lasat_board_info.li_cpu_hz / 2;
+	mips_hpt_frequency = lasat_board_info.li_cpu_hz / 2;
 }
 
 static void lasat_timer_setup(struct irqaction *irq)
@@ -146,7 +146,7 @@ static void lasat_timer_setup(struct irq
 
 	write_c0_compare(
 		read_c0_count() + 
-		mips_counter_frequency / HZ);
+		mips_hpt_frequency / HZ);
 	change_c0_status(ST0_IM, IE_IRQ0 | IE_IRQ5);
 }
 
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/mips-boards/generic/time.c linux-mips-2.4.21-20030811/arch/mips/mips-boards/generic/time.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/mips-boards/generic/time.c	2003-03-26 03:56:35.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/mips-boards/generic/time.c	2003-08-14 00:09:58.000000000 +0000
@@ -102,12 +102,12 @@ static unsigned int __init cal_r4koff(vo
 	while (CMOS_READ(RTC_REG_A) & RTC_UIP);
 	while (!(CMOS_READ(RTC_REG_A) & RTC_UIP));
 
-	mips_counter_frequency = read_c0_count();
+	mips_hpt_frequency = read_c0_count();
 
 	/* restore interrupts */
 	local_irq_restore(flags);
 
-	return (mips_counter_frequency / HZ);
+	return (mips_hpt_frequency / HZ);
 }
 
 unsigned long __init mips_rtc_get_time(void)
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/momentum/ocelot_c/setup.c linux-mips-2.4.21-20030811/arch/mips/momentum/ocelot_c/setup.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/momentum/ocelot_c/setup.c	2003-04-15 02:56:54.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/momentum/ocelot_c/setup.c	2003-08-14 00:10:08.000000000 +0000
@@ -183,9 +183,9 @@ void momenco_timer_setup(struct irqactio
 void momenco_time_init(void)
 {
 #ifdef CONFIG_CPU_SR71000
-	mips_counter_frequency = cpu_clock;
+	mips_hpt_frequency = cpu_clock;
 #elif defined(CONFIG_CPU_RM7000)
-	mips_counter_frequency = cpu_clock / 2;
+	mips_hpt_frequency = cpu_clock / 2;
 #else
 #error Unknown CPU for this board
 #endif
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/sgi-ip22/ip22-time.c linux-mips-2.4.21-20030811/arch/mips/sgi-ip22/ip22-time.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/sgi-ip22/ip22-time.c	2003-07-13 02:56:38.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/sgi-ip22/ip22-time.c	2003-08-14 00:10:20.000000000 +0000
@@ -177,7 +177,7 @@ void indy_time_init(void)
 		(int) (r4k_tick / (500000 / HZ)),
 		(int) (r4k_tick % (500000 / HZ)));
 
-	mips_counter_frequency = r4k_tick * HZ;
+	mips_hpt_frequency = r4k_tick * HZ;
 }
 
 /* Generic SGI handler for (spurious) 8254 interrupts */
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/tx4927/common/tx4927_setup.c linux-mips-2.4.21-20030811/arch/mips/tx4927/common/tx4927_setup.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/tx4927/common/tx4927_setup.c	2003-04-11 17:26:20.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/tx4927/common/tx4927_setup.c	2003-08-14 00:10:32.000000000 +0000
@@ -120,7 +120,7 @@ void __init tx4927_timer_setup(struct ir
 
 	/* to generate the first timer interrupt */
 	c1 = read_c0_count();
-	count = c1 + (mips_counter_frequency / HZ);
+	count = c1 + (mips_hpt_frequency / HZ);
 	write_c0_compare(count);
 	c2 = read_c0_count();
 
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c linux-mips-2.4.21-20030811/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	2003-07-16 02:56:43.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	2003-08-14 00:10:52.000000000 +0000
@@ -1168,7 +1168,7 @@ toshiba_rbtx4927_time_init(void)
 				       ":rtc_ds1742_init()+\n");
 
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":Calibrate mips_counter_frequency-\n");
+				       ":Calibrate mips_hpt_frequency-\n");
 	rtc_ds1742_wait();
 
 	/* get the count */
@@ -1181,29 +1181,29 @@ toshiba_rbtx4927_time_init(void)
 	c2 = read_c0_count();
 
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":Calibrate mips_counter_frequency+\n");
+				       ":Calibrate mips_hpt_frequency+\n");
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
 				       ":c1=%12u\n", c1);
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
 				       ":c2=%12u\n", c2);
 
 	/* this diff is as close as we are going to get to counter ticks per sec */
-	mips_counter_frequency = abs(c2 - c1);
+	mips_hpt_frequency = abs(c2 - c1);
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":f1=%12u\n", mips_counter_frequency);
+				       ":f1=%12u\n", mips_hpt_frequency);
 
 	/* round to 1/10th of a MHz */
-	mips_counter_frequency /= (100 * 1000);
-	mips_counter_frequency *= (100 * 1000);
+	mips_hpt_frequency /= (100 * 1000);
+	mips_hpt_frequency *= (100 * 1000);
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":f2=%12u\n", mips_counter_frequency);
+				       ":f2=%12u\n", mips_hpt_frequency);
 
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_INFO,
-				       ":mips_counter_frequency=%uHz (%uMHz)\n",
-				       mips_counter_frequency,
-				       mips_counter_frequency / 1000000);
+				       ":mips_hpt_frequency=%uHz (%uMHz)\n",
+				       mips_hpt_frequency,
+				       mips_hpt_frequency / 1000000);
 #else
-	mips_counter_frequency = 100000000;
+	mips_hpt_frequency = 100000000;
 #endif
 
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT, "+\n");
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/vr41xx/common/bcu.c linux-mips-2.4.21-20030811/arch/mips/vr41xx/common/bcu.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/vr41xx/common/bcu.c	2003-04-07 02:56:30.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/vr41xx/common/bcu.c	2003-08-14 00:11:13.000000000 +0000
@@ -36,7 +36,7 @@
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
- *  - Calculate mips_counter_frequency properly on VR4131.
+ *  - Calculate mips_hpt_frequency properly on VR4131.
  *
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
  *  - New creation, NEC VR4122 and VR4131 are supported.
@@ -177,7 +177,7 @@ static inline unsigned long calculate_tc
 	return tclock;
 }
 
-static inline unsigned long calculate_mips_counter_frequency(unsigned long tclock)
+static inline unsigned long calculate_mips_hpt_frequency(unsigned long tclock)
 {
 	/*
 	 * VR4131 Revision 2.0 and 2.1 use a value of (tclock / 2).
@@ -202,5 +202,5 @@ void __init vr41xx_bcu_init(void)
 	vtclock = calculate_vtclock(clkspeed, pclock);
 	tclock = calculate_tclock(clkspeed, pclock, vtclock);
 
-	mips_counter_frequency = calculate_mips_counter_frequency(tclock);
+	mips_hpt_frequency = calculate_mips_hpt_frequency(tclock);
 }
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips/vr41xx/common/time.c linux-mips-2.4.21-20030811/arch/mips/vr41xx/common/time.c
--- linux-mips-2.4.21-20030811.macro/arch/mips/vr41xx/common/time.c	2003-04-07 02:56:30.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips/vr41xx/common/time.c	2003-08-14 00:11:23.000000000 +0000
@@ -89,5 +89,5 @@ void vr41xx_timer_setup(struct irqaction
 	setup_irq(MIPS_COUNTER_IRQ, irq);
 
 	count = read_c0_count();
-	write_c0_compare(count + (mips_counter_frequency / HZ));
+	write_c0_compare(count + (mips_hpt_frequency / HZ));
 }
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/arch/mips64/kernel/time.c linux-mips-2.4.21-20030811/arch/mips64/kernel/time.c
--- linux-mips-2.4.21-20030811.macro/arch/mips64/kernel/time.c	2003-08-11 20:57:17.000000000 +0000
+++ linux-mips-2.4.21-20030811/arch/mips64/kernel/time.c	2003-08-14 01:57:43.000000000 +0000
@@ -102,9 +102,9 @@ static void null_hpt_init(unsigned int c
 
 
 /*
- * Timer ack for a R4k-compatible timer of a known frequency.
+ * Timer ack for an R4k-compatible timer of a known frequency.
  */
-static void c0_fixed_timer_ack(void)
+static void c0_timer_ack(void)
 {
 	unsigned int count;
 
@@ -129,14 +129,14 @@ static unsigned int c0_hpt_read(void)
 	return read_c0_count();
 }
 
-/* For unknown frequency.  */
+/* For use solely as a high precision timer.  */
 static void c0_hpt_init(unsigned int count)
 {
 	write_c0_count(read_c0_count() - count);
 }
 
-/* For a known frequency.  Used as an interrupt source.  */
-static void c0_fixed_hpt_init(unsigned int count)
+/* For use both as a high precision timer and an interrupt source.  */
+static void c0_hpt_timer_init(unsigned int count)
 {
 	count = read_c0_count() - count;
 	expirelo = (count / cycles_per_jiffy + 1) * cycles_per_jiffy;
@@ -145,6 +145,7 @@ static void c0_fixed_hpt_init(unsigned i
 	write_c0_count(count);
 }
 
+int (*mips_timer_state)(void);
 void (*mips_timer_ack)(void);
 unsigned int (*mips_hpt_read)(void);
 void (*mips_hpt_init)(unsigned int);
@@ -548,7 +549,7 @@ asmlinkage void ll_local_timer_interrupt
  *
  * 1) board_time_init() -
  * 	a) (optional) set up RTC routines,
- *      b) (optional) calibrate and set the mips_counter_frequency
+ *      b) (optional) calibrate and set the mips_hpt_frequency
  *	    (only needed if you intended to use fixed_rate_gettimeoffset
  *	     or use cpu counter as timer interrupt source)
  * 2) setup xtime based on rtc_get_time().
@@ -563,7 +564,7 @@ asmlinkage void ll_local_timer_interrupt
 void (*board_time_init)(void);
 void (*board_timer_setup)(struct irqaction *irq);
 
-unsigned int mips_counter_frequency;
+unsigned int mips_hpt_frequency;
 
 static struct irqaction timer_irqaction = {
 	.handler = timer_interrupt,
@@ -571,6 +572,49 @@ static struct irqaction timer_irqaction 
 	.name = "timer",
 };
 
+static unsigned int __init calibrate_hpt(void)
+{
+	u64 frequency;
+	u32 hpt_start, hpt_end, hpt_count, hz;
+
+	const int loops = HZ / 10;
+	int log_2_loops = 0;
+	int i;
+
+	/*
+	 * We want to calibrate for 0.1s, but to avoid a 64-bit
+	 * division we round the number of loops up to the nearest
+	 * power of 2.
+	 */
+	while (loops > 1 << log_2_loops)
+		log_2_loops++;
+	i = 1 << log_2_loops;
+
+	/*
+	 * Wait for a rising edge of the timer interrupt.
+	 */
+	while (mips_timer_state());
+	while (!mips_timer_state());
+
+	/*
+	 * Now see how many high precision timer ticks happen
+	 * during the calculated number of periods between timer
+	 * interrupts.
+	 */
+	hpt_start = mips_hpt_read();
+	do {
+		while (mips_timer_state());
+		while (!mips_timer_state());
+	} while (--i);
+	hpt_end = mips_hpt_read();
+
+	hpt_count = hpt_end - hpt_start;
+	hz = HZ;
+	frequency = (u64)hpt_count * (u64)hz;
+
+	return frequency >> log_2_loops;
+}
+
 void __init time_init(void)
 {
 	if (board_time_init)
@@ -587,7 +631,7 @@ void __init time_init(void)
 		/* No high precision timer -- sorry.  */
 		mips_hpt_read = null_hpt_read;
 		mips_hpt_init = null_hpt_init;
-	} else if (!mips_counter_frequency) {
+	} else if (!mips_hpt_frequency && !mips_timer_state) {
 		/* A high precision timer of unknown frequency.  */
 		if (!mips_hpt_read) {
 			/* No external high precision timer -- use R4k.  */
@@ -610,27 +654,36 @@ void __init time_init(void)
 			 */
 			do_gettimeoffset = calibrate_div64_gettimeoffset;
 	} else {
-		/* We know counter frequency! */
+		/* We know counter frequency.  Or we can get it.  */
 		if (!mips_hpt_read) {
 			/* No external high precision timer -- use R4k.  */
 			mips_hpt_read = c0_hpt_read;
-			mips_hpt_init = c0_fixed_hpt_init;
 
-			if (!mips_timer_ack)
-				/* R4k timer interrupt ack.  */
-				mips_timer_ack = c0_fixed_timer_ack;
+			if (mips_timer_state)
+				mips_hpt_init = c0_hpt_init;
+			else {
+				/* No external timer interrupt -- use R4k.  */
+				mips_hpt_init = c0_hpt_timer_init;
+				mips_timer_ack = c0_timer_ack;
+			}
 		}
+		if (!mips_hpt_frequency)
+			mips_hpt_frequency = calibrate_hpt();
 
 		do_gettimeoffset = fixed_rate_gettimeoffset;
 
 		/* Calculate cache parameters.  */
-		cycles_per_jiffy = mips_counter_frequency / HZ;
+		cycles_per_jiffy = (mips_hpt_frequency + HZ / 2) / HZ;
 
 		/* sll32_usecs_per_cycle = 10^6 * 2^32 / mips_counter_freq  */
-		/* Any better way to do this?  */
-		sll32_usecs_per_cycle = mips_counter_frequency / 100000;
-		sll32_usecs_per_cycle = 0xffffffff / sll32_usecs_per_cycle;
-		sll32_usecs_per_cycle *= 10;
+		do_div64_32(sll32_usecs_per_cycle,
+			    1000000, mips_hpt_frequency / 2,
+			    mips_hpt_frequency);
+
+		/* Report the high precision timer rate for a reference.  */
+		printk("Using %u.%03u MHz high precision timer.\n",
+		       ((mips_hpt_frequency + 500) / 1000) / 1000,
+		       ((mips_hpt_frequency + 500) / 1000) % 1000);
 	}
 
 	if (!mips_timer_ack)
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/include/asm-mips/time.h linux-mips-2.4.21-20030811/include/asm-mips/time.h
--- linux-mips-2.4.21-20030811.macro/include/asm-mips/time.h	2003-08-06 02:57:03.000000000 +0000
+++ linux-mips-2.4.21-20030811/include/asm-mips/time.h	2003-08-14 00:32:44.000000000 +0000
@@ -36,9 +36,11 @@ extern int (*rtc_set_time)(unsigned long
 extern int (*rtc_set_mmss)(unsigned long);
 
 /*
- * Timer interrupt ack function.
- * May be NULL if the interrupt is self-recoverable.
+ * Timer interrupt functions.
+ * mips_timer_state is needed for high precision timer calibration.
+ * mips_timer_ack may be NULL if the interrupt is self-recoverable.
  */
+extern int (*mips_timer_state)(void);
 extern void (*mips_timer_ack)(void);
 
 /*
@@ -88,9 +90,10 @@ extern void (*board_time_init)(void);
 extern void (*board_timer_setup)(struct irqaction *irq);
 
 /*
- * mips_counter_frequency - must be set if you intend to use
- * counter as timer interrupt source or use fixed_rate_gettimeoffset.
+ * mips_hpt_frequency - must be set if you intend to use an R4k-compatible
+ * counter as a timer interrupt source; otherwise it can be set up
+ * automagically with an aid of mips_timer_state.
  */
-extern unsigned int mips_counter_frequency;
+extern unsigned int mips_hpt_frequency;
 
 #endif /* _ASM_TIME_H */
diff -up --recursive --new-file linux-mips-2.4.21-20030811.macro/include/asm-mips64/time.h linux-mips-2.4.21-20030811/include/asm-mips64/time.h
--- linux-mips-2.4.21-20030811.macro/include/asm-mips64/time.h	2003-08-11 22:16:06.000000000 +0000
+++ linux-mips-2.4.21-20030811/include/asm-mips64/time.h	2003-08-14 00:32:44.000000000 +0000
@@ -36,9 +36,11 @@ extern int (*rtc_set_time)(unsigned long
 extern int (*rtc_set_mmss)(unsigned long);
 
 /*
- * Timer interrupt ack function.
- * May be NULL if the interrupt is self-recoverable.
+ * Timer interrupt functions.
+ * mips_timer_state is needed for high precision timer calibration.
+ * mips_timer_ack may be NULL if the interrupt is self-recoverable.
  */
+extern int (*mips_timer_state)(void);
 extern void (*mips_timer_ack)(void);
 
 /*
@@ -88,9 +90,10 @@ extern void (*board_time_init)(void);
 extern void (*board_timer_setup)(struct irqaction *irq);
 
 /*
- * mips_counter_frequency - must be set if you intend to use
- * counter as timer interrupt source or use fixed_rate_gettimeoffset.
+ * mips_hpt_frequency - must be set if you intend to use an R4k-compatible
+ * counter as a timer interrupt source; otherwise it can be set up
+ * automagically with an aid of mips_timer_state.
  */
-extern unsigned int mips_counter_frequency;
+extern unsigned int mips_hpt_frequency;
 
 #endif /* _ASM_TIME_H */


From demiurg@ti.com Thu Aug 14 10:20:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Aug 2003 14:02:07 +0100 (BST)
Received: from news.ti.com ([IPv6:::ffff:192.94.94.33]:45714 "EHLO
	dragon.ti.com") by linux-mips.org with ESMTP id <S8225208AbTHNJUW>;
	Thu, 14 Aug 2003 10:20:22 +0100
Received: from dlep50.itg.ti.com ([157.170.141.74])
	by dragon.ti.com (8.12.9/8.12.9) with ESMTP id h7E9KE1p011159;
	Thu, 14 Aug 2003 04:20:14 -0500 (CDT)
Received: from dlep90.itg.ti.com (localhost [127.0.0.1])
	by dlep50.itg.ti.com (8.12.9/8.12.9) with ESMTP id h7E9KE20001047;
	Thu, 14 Aug 2003 04:20:14 -0500 (CDT)
Received: from dlee70.itg.ti.com (dlee70.itg.ti.com [157.170.135.145])
	by dlep90.itg.ti.com (8.12.9/8.12.9) with ESMTP id h7E9KEJ5000338;
	Thu, 14 Aug 2003 04:20:14 -0500 (CDT)
Received: by dlee70.itg.ti.com with Internet Mail Service (5.5.2653.19)
	id <QZCGMJG5>; Thu, 14 Aug 2003 04:20:14 -0500
Received: from ti.com (cbc0794930.isr.asp.ti.com [137.167.2.134]) by dile70.itg.ti.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q6F22TL6; Thu, 14 Aug 2003 12:17:52 +0300
From: "Sirotkin, Alexander" <demiurg@ti.com>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Message-ID: <3F3B53C0.30408@ti.com>
Date: Thu, 14 Aug 2003 12:17:52 +0300
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
Subject: Re: tasklet latency and system calls on mips
References: <3F3A411C.70603@ti.com> <20030813095446.C9655@mvista.com>
In-Reply-To: <20030813095446.C9655@mvista.com>
Content-Type: multipart/alternative;
 boundary="------------060908050308030909000207"
Return-Path: <demiurg@ti.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3049
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: demiurg@ti.com
Precedence: bulk
X-list: linux-mips

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

Hi.

See my comments below.

Jun Sun wrote:


On Wed, Aug 13, 2003 at 04:46:04PM +0300, Sirotkin, Alexander wrote:

  

Hello dearest all.



I have a question regarding tasklets on MIPS. I suspect that there is a

bug in generic MIPS kernel, but I'm not sure yet.



Linux kernel has a couple of so called "checkpoints" when the system

should check if there are tasklets to

run and run them in the following way :



if (softirq_pending(cpu))

                    do_softirq();



One of these places is at the end of interrupt handler (do_IRQ()),

however this is not the only place. I was under

impression that this code should be called after system call too. The

caveat here is that on MIPS (contrary to

other architectures, such as x86) system call is not an interrupt (it's

a different exception) and has completely

different handler. So in x86 it is sufficient to call



if (softirq_pending(cpu))

                    do_softirq();



at the end of do_IRQ because do_IRQ handles system call too, but on MIPS

it is not. Therefore I believe

these lines should be added to the end of sys_syscall function on MIPS.



What do you think ?



    



softirq/tasklet/bottom_half/etc should only be raised from interrupt

context.  Checking at the end of do_IRQ should be good enough.

  

On mips interrupt is an exception and system call is a different
exception. Different exceptions has different exception handlers,
at least that's what I was able to figure from entry.S file. So the
system call does not go through do_IRQ and do_softirq
is not called.





One possible mistake in MIPS porting is that if the board uses its
private

time interrupt routine poeple may forget to put the above two lines

at the end.  Check against that.

  

In our kernel port we do have these lines in the timer interrupt, that
is not a problem. 



P.S. The whole issue started when we noticed that user process making

many system calls has very

significant impact on device drivers running in tasklet mode 

    



What kind of impact?  On i386? Or on MIPS?



  

Jun


The impact is that if our driver works in tasklet mode then some user
mode application making system calls
causes some (although quite small) packet loss. It does not happen if we
don't use tasklet and do everything in the
ISR.

I suspect that what happens is as follows :

system call arrives and while it's being processed and interrupt to one
of the drivers arrives. This interrupt 
schedules a tasklet which however is not executed after the system call
finishes, only after the next timer
interrupt which causes up to 10 ms latency (not all the time, only when
somebody makes a system call).

It only happens on MIPS. There is no easy way to check this on x86.
-- 

Alexander Sirotkin

SW Engineer



Texas Instruments

Broadband Communications Israel (BCIL)

Tel:  +972-9-9706587

________________________________________________________________________

"Those who do not understand Unix are condemned to reinvent it, poorly."

      -- Henry Spencer 

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi.<br>
<br>
See my comments below.<br>
<br>
Jun Sun wrote:<br>
<blockquote type="cite" cite="mid20030813095446.C9655@mvista.com">
  <pre wrap="">On Wed, Aug 13, 2003 at 04:46:04PM +0300, Sirotkin, Alexander wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hello dearest all.

I have a question regarding tasklets on MIPS. I suspect that there is a
bug in generic MIPS kernel, but I'm not sure yet.

Linux kernel has a couple of so called "checkpoints" when the system
should check if there are tasklets to
run and run them in the following way :

if (softirq_pending(cpu))
                    do_softirq();

One of these places is at the end of interrupt handler (do_IRQ()),
however this is not the only place. I was under
impression that this code should be called after system call too. The
caveat here is that on MIPS (contrary to
other architectures, such as x86) system call is not an interrupt (it's
a different exception) and has completely
different handler. So in x86 it is sufficient to call

if (softirq_pending(cpu))
                    do_softirq();

at the end of do_IRQ because do_IRQ handles system call too, but on MIPS
it is not. Therefore I believe
these lines should be added to the end of sys_syscall function on MIPS.

What do you think ?

    </pre>
  </blockquote>
  <pre wrap=""><!---->
softirq/tasklet/bottom_half/etc should only be raised from interrupt
context.  Checking at the end of do_IRQ should be good enough.
  </pre>
</blockquote>
On mips interrupt is an exception and system call is a different
exception. Different exceptions has different exception handlers,<br>
at least that's what I was able to figure from entry.S file. So the
system call does not go through do_IRQ and do_softirq<br>
is not called.<br>
<br>
<blockquote type="cite" cite="mid20030813095446.C9655@mvista.com">
  <pre wrap="">
One possible mistake in MIPS porting is that if the board uses its private
time interrupt routine poeple may forget to put the above two lines
at the end.  Check against that.
  </pre>
</blockquote>
In our kernel port we do have these lines in the timer interrupt, that
is not a problem. <br>
<br>
<blockquote type="cite" cite="mid20030813095446.C9655@mvista.com">
  <blockquote type="cite">
    <pre wrap="">P.S. The whole issue started when we noticed that user process making
many system calls has very
significant impact on device drivers running in tasklet mode 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
What kind of impact?  On i386? Or on MIPS?

  </pre>
</blockquote>
<blockquote type="cite" cite="mid20030813095446.C9655@mvista.com">
  <pre wrap="">Jun</pre>
</blockquote>
<br>
The impact is that if our driver works in tasklet mode then some user
mode application making system calls<br>
causes some (although quite small) packet loss. It does not happen if
we don't use tasklet and do everything in the<br>
ISR.<br>
<br>
I suspect that what happens is as follows :<br>
<br>
system call arrives and while it's being processed and interrupt to one
of the drivers arrives. This interrupt <br>
schedules a tasklet which however is not executed after the system call
finishes, only after the next timer<br>
interrupt which causes up to 10 ms latency (not all the time, only when
somebody makes a system call).<br>
<pre wrap="">It only happens on MIPS. There is no easy way to check this on x86.
</pre>
<pre class="moz-signature" cols="72">-- 
Alexander Sirotkin
SW Engineer

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

--------------060908050308030909000207--

From jsun@mvista.com Thu Aug 14 17:13:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Aug 2003 17:13:36 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:7931 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225210AbTHNQNe>;
	Thu, 14 Aug 2003 17:13:34 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h7EGDQu01222;
	Thu, 14 Aug 2003 09:13:26 -0700
Date: Thu, 14 Aug 2003 09:13:26 -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] Generic time trailing clean-ups
Message-ID: <20030814091326.A1203@mvista.com>
References: <20030813094541.B9655@mvista.com> <Pine.GSO.3.96.1030814121949.14241A-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.1030814121949.14241A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Aug 14, 2003 at 01:31:31PM +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: 3050
X-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, Aug 14, 2003 at 01:31:31PM +0200, Maciej W. Rozycki wrote:
> On Wed, 13 Aug 2003, Jun Sun wrote:
> 

<snip> 

I am completely lost in your arguments.  Let us keep it to the basic.

Tell me what is wrong with the following, and why your proposal
is better than this:

1) get rid of calibrate_*() function
2) introduce a generic counter frequence calibration routine, which
   is only invoked when mips_counter_frequency is 0.
3) If any board is not happy with this calibration, it is free to
   do its calibration in board_timer_init(), which would set
   mips_counter_frequency to be non-zero.

Jun


From macro@ds2.pg.gda.pl Thu Aug 14 17:35:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Aug 2003 17:35:38 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:53197 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225209AbTHNQfg>; Thu, 14 Aug 2003 17:35:36 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA18484;
	Thu, 14 Aug 2003 18:35:28 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 14 Aug 2003 18:35:28 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time trailing clean-ups
In-Reply-To: <20030814091326.A1203@mvista.com>
Message-ID: <Pine.GSO.3.96.1030814182619.17768B-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: 3051
X-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, 14 Aug 2003, Jun Sun wrote:

> I am completely lost in your arguments.  Let us keep it to the basic.
> 
> Tell me what is wrong with the following, and why your proposal
> is better than this:
> 
> 1) get rid of calibrate_*() function
> 2) introduce a generic counter frequence calibration routine, which
>    is only invoked when mips_counter_frequency is 0.
> 3) If any board is not happy with this calibration, it is free to
>    do its calibration in board_timer_init(), which would set
>    mips_counter_frequency to be non-zero.

 So I am lost, too.  What I proposed with the patch is exactly what you
describe above.  So what's wrong with it?

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


From jsun@mvista.com Thu Aug 14 17:45:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Aug 2003 17:45:22 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27126 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225209AbTHNQpT>;
	Thu, 14 Aug 2003 17:45:19 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h7EGjF601287;
	Thu, 14 Aug 2003 09:45:15 -0700
Date: Thu, 14 Aug 2003 09:45:15 -0700
From: Jun Sun <jsun@mvista.com>
To: "Sirotkin, Alexander" <demiurg@ti.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: tasklet latency and system calls on mips
Message-ID: <20030814094515.B1203@mvista.com>
References: <3F3A411C.70603@ti.com> <20030813095446.C9655@mvista.com> <3F3B53C0.30408@ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3F3B53C0.30408@ti.com>; from demiurg@ti.com on Thu, Aug 14, 2003 at 12:17:52PM +0300
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: 3052
X-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, Aug 14, 2003 at 12:17:52PM +0300, Sirotkin, Alexander wrote:
> 
> I suspect that what happens is as follows :
> 
> system call arrives and while it's being processed and interrupt to one
> of the drivers arrives. This interrupt 
> schedules a tasklet which however is not executed after the system call
> finishes, 

The tasklet should be executed at the return of interrupt handling.
If not, there is a bug.


> only after the next timer
> interrupt which causes up to 10 ms latency (not all the time, only when
> somebody makes a system call).
> 

BTW, make sure tasklet_schedule() is indeed called in an interrupt handler.
I am not sure why will happen otherwise.

If you suspect it is a bug, you can easily trace them.  You may my
little tracing tool useful,

	http://linux.junsun.net/patches/generic/experimental/030716.a-jstrace.patch

Jun

From jsun@mvista.com Thu Aug 14 17:52:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Aug 2003 17:52:53 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:21497 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225209AbTHNQwv>;
	Thu, 14 Aug 2003 17:52:51 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h7EGqku01328;
	Thu, 14 Aug 2003 09:52:46 -0700
Date: Thu, 14 Aug 2003 09:52:46 -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] Generic time trailing clean-ups
Message-ID: <20030814095246.C1203@mvista.com>
References: <20030814091326.A1203@mvista.com> <Pine.GSO.3.96.1030814182619.17768B-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.1030814182619.17768B-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Aug 14, 2003 at 06:35:28PM +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: 3053
X-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, Aug 14, 2003 at 06:35:28PM +0200, Maciej W. Rozycki wrote:
> On Thu, 14 Aug 2003, Jun Sun wrote:
> 
> > I am completely lost in your arguments.  Let us keep it to the basic.
> > 
> > Tell me what is wrong with the following, and why your proposal
> > is better than this:
> > 
> > 1) get rid of calibrate_*() function
> > 2) introduce a generic counter frequence calibration routine, which
> >    is only invoked when mips_counter_frequency is 0.
> > 3) If any board is not happy with this calibration, it is free to
> >    do its calibration in board_timer_init(), which would set
> >    mips_counter_frequency to be non-zero.
> 
>  So I am lost, too.  What I proposed with the patch is exactly what you
> describe above.  So what's wrong with it?
>

Oh, really? :)

1) I don't see you " get rid of calibrate_*() function"
2) oh, why? because your "generic counter frequence" is not generic -
   it requires board-specific routines.  I was referring to using
   jiffies to calibrate frequency.
3) I also don't see picky boards "do its calibration in board_timer_init()".

Your proposal differs in every count. :)

Jun

From wilsonc@cellvision1.com.tw Fri Aug 15 11:21:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Aug 2003 11:21:36 +0100 (BST)
Received: from [IPv6:::ffff:211.21.189.117] ([IPv6:::ffff:211.21.189.117]:8618
	"EHLO ns.cellvision1.com.tw") by linux-mips.org with ESMTP
	id <S8225201AbTHOKVe>; Fri, 15 Aug 2003 11:21:34 +0100
Received: from cellvision1.com.tw ([211.21.189.118])
	by ns.cellvision1.com.tw (8.11.6/8.11.6) with ESMTP id h7FAPgq15033
	for <linux-mips@linux-mips.org>; Fri, 15 Aug 2003 18:25:45 +0800
Message-ID: <3F3CB4CC.8070109@cellvision1.com.tw>
Date: Fri, 15 Aug 2003 18:24:12 +0800
From: Wilson Chan <wilsonc@cellvision1.com.tw>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-TW; rv:1.2.1) Gecko/20030225
X-Accept-Language: zh-tw, en-us, zh
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: gdbserver and gdb debugging stub for mips
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <wilsonc@cellvision1.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: 3054
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wilsonc@cellvision1.com.tw
Precedence: bulk
X-list: linux-mips

Hi Sir:
   Does anybody has a gdbserver and gdb debugging stub for mips. I need
them to do remote debugging on mips. Thanks!

Wilson
08/15/2003


From zhufeng@koretide.com.cn Fri Aug 15 12:10:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Aug 2003 12:11:01 +0100 (BST)
Received: from p508B6225.dip.t-dialin.net ([IPv6:::ffff:80.139.98.37]:39591
	"EHLO p508B6225.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225201AbTHOLK7>; Fri, 15 Aug 2003 12:10:59 +0100
Received: from [IPv6:::ffff:210.22.155.234] ([IPv6:::ffff:210.22.155.234]:34732
	"EHLO mail.koretide.com.cn") by linux-mips.net with ESMTP
	id <S869101AbTHOLK5> convert rfc822-to-8bit; Fri, 15 Aug 2003 13:10:57 +0200
Received: from zhufeng ([192.168.1.12])
	(authenticated)
	by mail.koretide.com.cn (8.11.6/8.11.6) with ESMTP id h7FB8Yc18501;
	Fri, 15 Aug 2003 19:08:34 +0800
From: =?UTF-8?B?5pyx5Yek?= <zhufeng@koretide.com.cn>
To: "Wilson Chan" <wilsonc@cellvision1.com.tw>,
	<linux-mips@linux-mips.org>
Subject: RE: gdbserver and gdb debugging stub for mips
Date: Fri, 15 Aug 2003 19:10:26 +0800
Message-ID: <MGEELAPMEFMLFBMDBLKLGEKGCEAA.zhufeng@koretide.com.cn>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 8BIT
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
In-Reply-To: <3F3CB4CC.8070109@cellvision1.com.tw>
Return-Path: <zhufeng@koretide.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3055
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zhufeng@koretide.com.cn
Precedence: bulk
X-list: linux-mips

I'm also looking for them . If anybody who has , please tell me , thank you.

-----Original Message-----
From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Wilson Chan
Sent: 2003綛�8���15��� 18:24
To: linux-mips@linux-mips.org
Subject: gdbserver and gdb debugging stub for mips


Hi Sir:
   Does anybody has a gdbserver and gdb debugging stub for mips. I need
them to do remote debugging on mips. Thanks!

Wilson
08/15/2003


From wd@denx.de Fri Aug 15 14:50:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Aug 2003 14:50:56 +0100 (BST)
Received: from mailout05.sul.t-online.com ([IPv6:::ffff:194.25.134.82]:43137
	"EHLO mailout05.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225209AbTHONuy>; Fri, 15 Aug 2003 14:50:54 +0100
Received: from fwd05.aul.t-online.de 
	by mailout05.sul.t-online.com with smtp 
	id 19neyP-0004C8-04; Fri, 15 Aug 2003 15:50:33 +0200
Received: from denx.de (bRXB6mZLgenTq3HG63oLUTou8aQWCGKvNggP6t3GjM8bF5nPrwJarv@[217.235.230.57]) by fmrl05.sul.t-online.com
	with esmtp id 19neyK-1foEj20; Fri, 15 Aug 2003 15:50:28 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 01D2342BAD; Fri, 15 Aug 2003 15:50:24 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id B55C0C59E4; Fri, 15 Aug 2003 15:50:18 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id AEB2BC59E3; Fri, 15 Aug 2003 15:50:18 +0200 (MEST)
To: =?UTF-8?B?5pyx5Yek?= <zhufeng@koretide.com.cn>
Cc: "Wilson Chan" <wilsonc@cellvision1.com.tw>,
	linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: gdbserver and gdb debugging stub for mips 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Fri, 15 Aug 2003 19:10:26 +0800."
             <MGEELAPMEFMLFBMDBLKLGEKGCEAA.zhufeng@koretide.com.cn> 
Date: Fri, 15 Aug 2003 15:50:13 +0200
Message-Id: <20030815135018.B55C0C59E4@atlas.denx.de>
X-Seen: false
X-ID: bRXB6mZLgenTq3HG63oLUTou8aQWCGKvNggP6t3GjM8bF5nPrwJarv@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: 3056
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips

In message <MGEELAPMEFMLFBMDBLKLGEKGCEAA.zhufeng@koretide.com.cn> you wrote:
> I'm also looking for them . If anybody who has , please tell me , thank you.

MIPS isn't MIPS. What exactly are you looking for?

We have gdb (cross and native) / gdbserver included with our ELDK for
MIPS - this is for 4Kc CPUs.

See section "3. Embedded Linux Development Kit" at
http://www.denx.de/twiki/bin/view/DULG/BoardSelect (select incaip).

Hope this helps.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"If you can, help others. If you can't, at least don't hurt  others."
- the Dalai Lama

From drow@crack.them.org Fri Aug 15 15:21:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Aug 2003 15:21:48 +0100 (BST)
Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([IPv6:::ffff:66.93.172.17]:1488
	"EHLO nevyn.them.org") by linux-mips.org with ESMTP
	id <S8225209AbTHOOVq>; Fri, 15 Aug 2003 15:21:46 +0100
Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian))
	id 19nfSE-0006ST-RE; Fri, 15 Aug 2003 10:21:22 -0400
Date: Fri, 15 Aug 2003 10:21:22 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Wolfgang Denk <wd@denx.de>
Cc: ?????? <zhufeng@koretide.com.cn>,
	Wilson Chan <wilsonc@cellvision1.com.tw>,
	linux-mips@linux-mips.org
Subject: Re: gdbserver and gdb debugging stub for mips
Message-ID: <20030815142122.GA24803@nevyn.them.org>
References: <MGEELAPMEFMLFBMDBLKLGEKGCEAA.zhufeng@koretide.com.cn> <20030815135018.B55C0C59E4@atlas.denx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030815135018.B55C0C59E4@atlas.denx.de>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3057
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Fri, Aug 15, 2003 at 03:50:13PM +0200, Wolfgang Denk wrote:
> In message <MGEELAPMEFMLFBMDBLKLGEKGCEAA.zhufeng@koretide.com.cn> you wrote:
> > I'm also looking for them . If anybody who has , please tell me , thank you.
> 
> MIPS isn't MIPS. What exactly are you looking for?
> 
> We have gdb (cross and native) / gdbserver included with our ELDK for
> MIPS - this is for 4Kc CPUs.
> 
> See section "3. Embedded Linux Development Kit" at
> http://www.denx.de/twiki/bin/view/DULG/BoardSelect (select incaip).

They're also, uh, distributed with the source of GDB.  Builds like any
other target application.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From zhufeng@koretide.com.cn Fri Aug 15 15:49:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Aug 2003 15:49:48 +0100 (BST)
Received: from p508B6225.dip.t-dialin.net ([IPv6:::ffff:80.139.98.37]:31144
	"EHLO p508B6225.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225209AbTHOOtq>; Fri, 15 Aug 2003 15:49:46 +0100
Received: from [IPv6:::ffff:210.22.155.234] ([IPv6:::ffff:210.22.155.234]:685
	"EHLO mail.koretide.com.cn") by linux-mips.net with ESMTP
	id <S869101AbTHOOtp> convert rfc822-to-8bit; Fri, 15 Aug 2003 16:49:45 +0200
Received: from zhufeng ([192.168.1.12])
	(authenticated)
	by mail.koretide.com.cn (8.11.6/8.11.6) with ESMTP id h7FElSc21538;
	Fri, 15 Aug 2003 22:47:28 +0800
From: =?UTF-8?B?5pyx5Yek?= <zhufeng@koretide.com.cn>
To: <wd@denx.de>
Cc: "Wilson Chan" <wilsonc@cellvision1.com.tw>,
	<linux-mips@linux-mips.org>
Subject: RE: gdbserver and gdb debugging stub for mips 
Date: Fri, 15 Aug 2003 22:49:21 +0800
Message-ID: <MGEELAPMEFMLFBMDBLKLIEKICEAA.zhufeng@koretide.com.cn>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 8BIT
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <20030815135018.B55C0C59E4@atlas.denx.de>
Return-Path: <zhufeng@koretide.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3058
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zhufeng@koretide.com.cn
Precedence: bulk
X-list: linux-mips

 what do you mean by "MIPS is NOT MIPS"? Does it mean there are too many mips boards?

-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: 2003綛�8���15��� 21:50
To: ��狸揃誰
Cc: Wilson Chan; linux-mips@linux-mips.org
Subject: Re: gdbserver and gdb debugging stub for mips 


In message <MGEELAPMEFMLFBMDBLKLGEKGCEAA.zhufeng@koretide.com.cn> you wrote:
> I'm also looking for them . If anybody who has , please tell me , thank you.

MIPS isn't MIPS. What exactly are you looking for?

We have gdb (cross and native) / gdbserver included with our ELDK for
MIPS - this is for 4Kc CPUs.

See section "3. Embedded Linux Development Kit" at
http://www.denx.de/twiki/bin/view/DULG/BoardSelect (select incaip).

Hope this helps.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"If you can, help others. If you can't, at least don't hurt  others."
- the Dalai Lama


From wd@denx.de Fri Aug 15 16:08:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Aug 2003 16:08:20 +0100 (BST)
Received: from mailout05.sul.t-online.com ([IPv6:::ffff:194.25.134.82]:18858
	"EHLO mailout05.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225209AbTHOPIS>; Fri, 15 Aug 2003 16:08:18 +0100
Received: from fwd02.aul.t-online.de 
	by mailout05.sul.t-online.com with smtp 
	id 19ngBW-0007zD-02; Fri, 15 Aug 2003 17:08:10 +0200
Received: from denx.de (ZedUEcZcZe+6HFGYzJWkOPdVw5i0QtoEPi3Znlo2P0Jq+lOYcsNfs7@[217.235.230.57]) by fmrl02.sul.t-online.com
	with esmtp id 19ngBP-0NfIy80; Fri, 15 Aug 2003 17:08:03 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id DF66542C81; Fri, 15 Aug 2003 17:08:01 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id C4DCAC59E4; Fri, 15 Aug 2003 17:07:55 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id C19ADC59E3; Fri, 15 Aug 2003 17:07:55 +0200 (MEST)
To: =?UTF-8?B?5pyx5Yek?= <zhufeng@koretide.com.cn>
Cc: "Wilson Chan" <wilsonc@cellvision1.com.tw>,
	linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: gdbserver and gdb debugging stub for mips 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Fri, 15 Aug 2003 22:49:21 +0800."
             <MGEELAPMEFMLFBMDBLKLIEKICEAA.zhufeng@koretide.com.cn> 
Date: Fri, 15 Aug 2003 17:07:50 +0200
Message-Id: <20030815150755.C4DCAC59E4@atlas.denx.de>
X-Seen: false
X-ID: ZedUEcZcZe+6HFGYzJWkOPdVw5i0QtoEPi3Znlo2P0Jq+lOYcsNfs7@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: 3059
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips

In message <MGEELAPMEFMLFBMDBLKLIEKICEAA.zhufeng@koretide.com.cn> you wrote:
>  what do you mean by "MIPS is NOT MIPS"? Does it mean there are too many mips boards?

big endian, little endian, 32 bit, 64 bit, ...

It means that there are several  different  configurations,  and  you
must use tools to match your configuration.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Newer disks don't have a rectangular layout anymore,  but  Unix  (and
SunOS) still assumes this.     - Peter Koch in <koch.779356598@rhein>

From michaelanburaj@hotmail.com Fri Aug 15 20:37:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Aug 2003 20:37:42 +0100 (BST)
Received: from bay1-f6.bay1.hotmail.com ([IPv6:::ffff:65.54.245.6]:16659 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225201AbTHOThk>;
	Fri, 15 Aug 2003 20:37:40 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 15 Aug 2003 12:37:22 -0700
Received: from 207.13.167.2 by by1fd.bay1.hotmail.msn.com with HTTP;
	Fri, 15 Aug 2003 19:37:22 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: RTL8139 -- Link status change
Date: Fri, 15 Aug 2003 12:37:22 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F65q4IaYZVCA1G0003fe37@hotmail.com>
X-OriginalArrivalTime: 15 Aug 2003 19:37:22.0566 (UTC) FILETIME=[A5C6E260:01C36364]
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: 3060
X-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,

Setup: MIPS board -> Hub <- RH 9 (DHCP server)

I have a RTL8139 based PCI NIC inserted on the MIPS�s PCI (2.1) slot. The
WAL on the NIC is left floating (Is that a problem?). I am able to send
packets from the MIPS board to RH 9, but the packets sent from the RH 9 is
not reaching the MIPS board.

Even if the DHCP server is not connected, I see the Link status change
interrupt (status) bit of ISR going high after every packet sent from the
MIPS board. Seems like the cause for the problem I see, am I right?
Can somebody tell me why the link status is changing after a packet is sent
out?

Sample at every change in ISR:
-----------------------------
BMCR = 0x1100
BMSR = 0x782d
ANAR = 0x01e1
ANLPAR = 0x45e1
ANER = 0x0001
DIS = 0x0000
FCSC = 0x0000


Is there a register to look at, for the cause to this link status change
<The above registers don't change at all>? Please suggest me a way to debug
this issue.

Thanks,
-Mike.

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


From macro@ds2.pg.gda.pl Sat Aug 16 13:32:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Aug 2003 13:32:37 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:14720 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225303AbTHPMcc>; Sat, 16 Aug 2003 13:32:32 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA15430;
	Sat, 16 Aug 2003 14:32:18 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Sat, 16 Aug 2003 14:32:17 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time trailing clean-ups
In-Reply-To: <20030814095246.C1203@mvista.com>
Message-ID: <Pine.GSO.3.96.1030816142004.15339A-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: 3061
X-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, 14 Aug 2003, Jun Sun wrote:

> > > 1) get rid of calibrate_*() function
> > > 2) introduce a generic counter frequence calibration routine, which
> > >    is only invoked when mips_counter_frequency is 0.
> > > 3) If any board is not happy with this calibration, it is free to
> > >    do its calibration in board_timer_init(), which would set
> > >    mips_counter_frequency to be non-zero.
> > 
> >  So I am lost, too.  What I proposed with the patch is exactly what you
> > describe above.  So what's wrong with it?
> >
> 
> Oh, really? :)
> 
> 1) I don't see you " get rid of calibrate_*() function"

 The patch is for 2.4.  I won't cook a patch for 2.6 before applying this
one, sorry.  Feel free to do that yourself, based on my proposal.  If the
plan I've presented was unclear, then please tell me exactly, where. 

> 2) oh, why? because your "generic counter frequence" is not generic -
>    it requires board-specific routines.  I was referring to using
>    jiffies to calibrate frequency.

 The calibration routine is generic -- every backend can use it without
duplicating the code privately.  You cannot throw all platforms into a
single bag because of different timer IRQ sources.

 I have already written why jiffies cannot be used directly. 

> 3) I also don't see picky boards "do its calibration in board_timer_init()".

 If mips_hpt_frequency is non zero after calling board_time_init(), it's
not recalibrated -- have you actually read the code???

> Your proposal differs in every count. :)

 The details may differ a bit.  The principles are the same.

  Maciej

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


From zhufeng@koretide.com.cn Mon Aug 18 02:16:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Aug 2003 02:16:58 +0100 (BST)
Received: from [IPv6:::ffff:210.22.155.234] ([IPv6:::ffff:210.22.155.234]:25775
	"EHLO mail.koretide.com.cn") by linux-mips.org with ESMTP
	id <S8225258AbTHRBQq> convert rfc822-to-8bit; Mon, 18 Aug 2003 02:16:46 +0100
Received: from zhufeng ([192.168.1.12])
	(authenticated)
	by mail.koretide.com.cn (8.11.6/8.11.6) with ESMTP id h7I1E9c11662;
	Mon, 18 Aug 2003 09:14:12 +0800
From: "=?utf-8?Q?=E6=9C=B1=E5=87=A4\=28zhufeng\=29?=" 
	<zhufeng@koretide.com.cn>
To: <wd@denx.de>
Cc: "Wilson Chan" <wilsonc@cellvision1.com.tw>,
	<linux-mips@linux-mips.org>
Subject: RE: gdbserver and gdb debugging stub for mips 
Date: Mon, 18 Aug 2003 09:16:06 +0800
Message-ID: <MGEELAPMEFMLFBMDBLKLGEKOCEAA.zhufeng@koretide.com.cn>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8BIT
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
In-Reply-To: <20030815150755.C4DCAC59E4@atlas.denx.de>
Return-Path: <zhufeng@koretide.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3062
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zhufeng@koretide.com.cn
Precedence: bulk
X-list: linux-mips

when I build my mips program using gcc with -O0 , it is ok, while using -o2, there come the following questions.
lingking,,,

relocation truncated to fit: R_MIPS_GPREL16  __global_ctor_start
relocation truncated to fit: R_MIPS_GPREL16 __global_ctor_end
relocation truncated to fit: R_MIPS_GPREL16 _recycle_start 

and so on.

Has anybody encounter such questions?



-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: 2003綛�8���15��� 23:08
To: ��狸揃誰
Cc: Wilson Chan; linux-mips@linux-mips.org
Subject: Re: gdbserver and gdb debugging stub for mips 


In message <MGEELAPMEFMLFBMDBLKLIEKICEAA.zhufeng@koretide.com.cn> you wrote:
>  what do you mean by "MIPS is NOT MIPS"? Does it mean there are too many mips boards?

big endian, little endian, 32 bit, 64 bit, ...

It means that there are several  different  configurations,  and  you
must use tools to match your configuration.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Newer disks don't have a rectangular layout anymore,  but  Unix  (and
SunOS) still assumes this.     - Peter Koch in <koch.779356598@rhein>


From fxzhang@ict.ac.cn Mon Aug 18 06:20:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Aug 2003 06:20:17 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:18130
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225310AbTHRFUP>; Mon, 18 Aug 2003 06:20:15 +0100
Received: (qmail 15397 invoked from network); 18 Aug 2003 05:12:28 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.187)
  by mail.ict.ac.cn with SMTP; 18 Aug 2003 05:12:28 -0000
Message-ID: <3F4061FC.4080806@ict.ac.cn>
Date: Mon, 18 Aug 2003 13:19:56 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: =?gb18030?Q?=22=D6=EC=B7=EF=28zhufeng=29=22?= 
	<zhufeng@koretide.com.cn>
CC: linux-mips@linux-mips.org
Subject: Re: gdbserver and gdb debugging stub for mips
References: <MGEELAPMEFMLFBMDBLKLGEKOCEAA.zhufeng@koretide.com.cn>
In-Reply-To: <MGEELAPMEFMLFBMDBLKLGEKOCEAA.zhufeng@koretide.com.cn>
Content-Type: text/plain; charset=gb18030; format=flowed
Content-Transfer-Encoding: 8bit
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: 3063
X-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

An answer cited from elsewhere:
-----
    <snip>

    Rosimildo> /ecos/work/install/lib/libtarget.a(net_tcpip_ip_id.o): In function 
    Rosimildo> `ip_initid':
    Rosimildo> /ecos/ecos-1.3.1/packages/net/tcpip/v1_0b1/src/sys/netinet/ip_id.c:231: 
    Rosimildo> relocaton truncated to fit: R_MIPS_GPREL16 time

    Rosimildo> I am wondering if this seems familiar to anyone doing
    Rosimildo> MIPS stuff.

I think I know what the problem is, but I cannot be 100% sure.

The MIPS architecture allows for a certain amount of global data to be
accessed more quickly than others, using different instructions. The
compiler exploits this facility by putting small global variables into
sections .sdata and .sbss, rather than the normal sections .data and
.bss. Of course the compiler has no idea how many modules are going to
end up in the final executable. Hence at link-time it is possible that
there is now too much data in these sections, and you will get a
"relocation truncated" message. For most applications you will not hit
the limit, in fact I am somewhat surprised that any ordinary eCos
application would cause the problem to arise.

The correct solution would be for the linker to handle this situation
and decide which global variables should remain in the special region
and which ones should be moved elsewhere. In theory it could use
information such as the number of accesses to a particular global, or
maybe even profiling feedback, to decide which variables are most
worthwhile keeping in the special region. Unfortunately this would
require the linker changing the instructions used to access the
variables that are moved to the ordinary .data and .bss sections,
which is a non-trivial operation. Also, having the linker change
instructions would mess up other things such as the compiler's
attempts at instruction scheduling.

On occasion we have had requests to fix the toolchain so that it does
the right thing (for some definition of the right thing), but the work
is sufficiently involved that so far nobody has been willing to fund
it.

There is a workaround. The mips toolchain accepts an argument -G<num>,
with a default value of 8. This means that any global variable <= 8
bytes will end up in .sdata or .sbss. If you compile all the code with
a different value, e.g. -G4, then less data ends up in the special
sections so you will not hit the overflow condition. There is a
performance penalty, of course. I suggest experimenting with -G
values, and looking at the relevant gcc documentation as well since
things may have changed since the last time I looked at this. It might
also be worthwhile searching through the gcc mailing list archives at
http://gcc.gnu.org/ml/gcc/

Bart Veer // eCos net maintainer



幀件(zhufeng) wrote:

>when I build my mips program using gcc with -O0 , it is ok, while using -o2, there come the following questions.
>lingking,,,
>
>relocation truncated to fit: R_MIPS_GPREL16  __global_ctor_start
>relocation truncated to fit: R_MIPS_GPREL16 __global_ctor_end
>relocation truncated to fit: R_MIPS_GPREL16 _recycle_start 
>
>and so on.
>
>Has anybody encounter such questions?
>
>
>
>-----Original Message-----
>From: wd@denx.de [mailto:wd@denx.de]
>Sent: 2003綛���� 23:08
>To: ��狸揃誰
>Cc: Wilson Chan; linux-mips@linux-mips.org
>Subject: Re: gdbserver and gdb debugging stub for mips 
>
>
>In message <MGEELAPMEFMLFBMDBLKLIEKICEAA.zhufeng@koretide.com.cn> you wrote:
>  
>
>> what do you mean by "MIPS is NOT MIPS"? Does it mean there are too many mips boards?
>>    
>>
>
>big endian, little endian, 32 bit, 64 bit, ...
>
>It means that there are several  different  configurations,  and  you
>must use tools to match your configuration.
>
>Best regards,
>
>Wolfgang Denk
>
>  
>


From kimai@iodata.jp Mon Aug 18 08:17:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Aug 2003 08:17:11 +0100 (BST)
Received: from ns10.iodata.jp ([IPv6:::ffff:211.127.181.3]:13587 "HELO
	ns10.iodata.co.jp") by linux-mips.org with SMTP id <S8225301AbTHRHRG>;
	Mon, 18 Aug 2003 08:17:06 +0100
Received: (qmail 24432 invoked from network); 18 Aug 2003 07:16:57 -0000
Received: from fw40.iodata.jp (HELO isl50.iodata.co.jp) (fwuser@211.127.181.2)
  by ns10.iodata.jp with SMTP; 18 Aug 2003 07:16:57 -0000
Date: Mon, 18 Aug 2003 16:16:55 +0900
Message-ID: <m3d6f3fna0.wl@iodata.jp>
From: Kunihiko IMAI <kimai@iodata.jp>
To: linux-mips@linux-mips.org
Subject: Re: General I/O
In-Reply-To: <m3ekzjfoi2.wl@iodata.jp>
References: <200308141212.38679.wom@tateyama.hu>
	<m3ekzjfoi2.wl@iodata.jp>
MIME-Version: 1.0 (generated by SEMI 1.14.3 - =?ISO-2022-JP?B?IhskQjVtGyhC?=
 =?ISO-2022-JP?B?GyRCJU5DKxsoQiI=?=)
Content-Type: text/plain; charset=US-ASCII
Return-Path: <kimai@iodata.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: 3064
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kimai@iodata.jp
Precedence: bulk
X-list: linux-mips

Hi, 

At Thu, 14 Aug 2003 12:12:38 +0200,
Gabor Kerenyi wrote:

> I could wrote a small driver to setup and handle an interrupt
> on GUINT0 using vr41xx_set_irq_trigger (a simple switch is
> connected to PIN0)

These function ( macro ) set works only setting GPIO pin function.
They have no resource management.  If the pin is not assigned on
any function yet, you can freely set the pin function.

You can set these registers with write[bwl]/read[bwl] functions. Do
not use out[bwl]/in[bwl].  And the place of GPIO regsters are
relocated by bootloader.  It's better to use macros defined at
include/asm/vr41xx/toadkk-tcs8000.h.

> The board is not known by anyone, it's made in Japan
> (TOADKK-TCS8000).

The kernel with the board is local porting version, not submitted
linux-mips CVS.  The kernel is ported by LASER5 Co. Ltd.  And they
sell same card as L-Card A.

Thanks.
_._. __._  _ . ... _  .___ ._. _____ _... ._ _._ _.._. .____  _ . ... _

                                                          Kunihiko IMAI

From demiurg@ti.com Mon Aug 18 16:30:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Aug 2003 17:32:06 +0100 (BST)
Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:35216 "EHLO
	go4.ext.ti.com") by linux-mips.org with ESMTP id <S8225296AbTHRPaK>;
	Mon, 18 Aug 2003 16:30:10 +0100
Received: from dlep52.itg.ti.com ([157.170.134.103])
	by go4.ext.ti.com (8.12.9/8.12.9) with ESMTP id h7IFU2wD003339;
	Mon, 18 Aug 2003 10:30:02 -0500 (CDT)
Received: from dlep90.itg.ti.com (localhost [127.0.0.1])
	by dlep52.itg.ti.com (8.12.9/8.12.9) with ESMTP id h7IFU1Th009461;
	Mon, 18 Aug 2003 10:30:02 -0500 (CDT)
Received: from dlee70.itg.ti.com (dlee70.itg.ti.com [157.170.135.145])
	by dlep90.itg.ti.com (8.12.9/8.12.9) with ESMTP id h7IFU1J5020712;
	Mon, 18 Aug 2003 10:30:01 -0500 (CDT)
Received: by dlee70.itg.ti.com with Internet Mail Service (5.5.2653.19)
	id <QZCGQSVR>; Mon, 18 Aug 2003 10:30:01 -0500
Received: from ti.com (cbc0794930.isr.asp.ti.com [137.167.2.134]) by dile70.itg.ti.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q6F2JCPJ; Mon, 18 Aug 2003 18:29:52 +0300
From: "Sirotkin, Alexander" <demiurg@ti.com>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Message-ID: <3F40F0F0.1080106@ti.com>
Date: Mon, 18 Aug 2003 18:29:52 +0300
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
Subject: Re: tasklet latency and system calls on mips
References: <3F3A411C.70603@ti.com> <20030813095446.C9655@mvista.com> <3F3B53C0.30408@ti.com> <20030814094515.B1203@mvista.com>
In-Reply-To: <20030814094515.B1203@mvista.com>
Content-Type: multipart/alternative;
 boundary="------------080800070704020208060604"
Return-Path: <demiurg@ti.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3065
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: demiurg@ti.com
Precedence: bulk
X-list: linux-mips

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



Jun Sun wrote:


On Thu, Aug 14, 2003 at 12:17:52PM +0300, Sirotkin, Alexander wrote:

  

I suspect that what happens is as follows :



system call arrives and while it's being processed and interrupt to one

of the drivers arrives. This interrupt 

schedules a tasklet which however is not executed after the system call

finishes, 

    



The tasklet should be executed at the return of interrupt handling.

If not, there is a bug.

  

I have a feeling that we are going in circles. Tasklets are executed at
the return of interrupt handler.
However, I suspect that this is not enough. On mips (contrary to x86),
system call is NOT an interrupt.
It's a different exception with different handler. Therefore I suspect
that tasklets are NOT called at 
the end of system call exception handler (which is a different handler,
not do_IRQ).






  

only after the next timer

interrupt which causes up to 10 ms latency (not all the time, only when

somebody makes a system call).



    



BTW, make sure tasklet_schedule() is indeed called in an interrupt
handler.

I am not sure why will happen otherwise.



If you suspect it is a bug, you can easily trace them.  You may my

little tracing tool useful,

I can try to trace it, I just wanted to ensure that what I was saying
makes sense. See above.






	
http://linux.junsun.net/patches/generic/experimental/030716.a-jstrace.pa
tch
<http://linux.junsun.net/patches/generic/experimental/030716.a-jstrace.p
atch> 



Jun

  


-- 

Alexander Sirotkin

SW Engineer



Texas Instruments

Broadband Communications Israel (BCIL)

Tel:  +972-9-9706587

________________________________________________________________________

"Those who do not understand Unix are condemned to reinvent it, poorly."

      -- Henry Spencer 

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Jun Sun wrote:<br>
<blockquote type="cite" cite="mid20030814094515.B1203@mvista.com">
  <pre wrap="">On Thu, Aug 14, 2003 at 12:17:52PM +0300, Sirotkin, Alexander wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I suspect that what happens is as follows :

system call arrives and while it's being processed and interrupt to one
of the drivers arrives. This interrupt 
schedules a tasklet which however is not executed after the system call
finishes, 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The tasklet should be executed at the return of interrupt handling.
If not, there is a bug.
  </pre>
</blockquote>
I have a feeling that we are going in circles. Tasklets are executed at
the return of interrupt handler.<br>
However, I suspect that this is not enough. On mips (contrary to x86),
system call is NOT an interrupt.<br>
It's a different exception with different handler. Therefore I suspect
that tasklets are NOT called at <br>
the end of system call exception handler (which is a different handler,
not do_IRQ).<br>
<blockquote type="cite" cite="mid20030814094515.B1203@mvista.com">
  <pre wrap="">

  </pre>
  <blockquote type="cite">
    <pre wrap="">only after the next timer
interrupt which causes up to 10 ms latency (not all the time, only when
somebody makes a system call).

    </pre>
  </blockquote>
  <pre wrap=""><!---->
BTW, make sure tasklet_schedule() is indeed called in an interrupt handler.
I am not sure why will happen otherwise.

If you suspect it is a bug, you can easily trace them.  You may my
little tracing tool useful,</pre>
</blockquote>
I can try to trace it, I just wanted to ensure that what I was saying
makes sense. See above.<br>
<blockquote type="cite" cite="mid20030814094515.B1203@mvista.com">
  <pre wrap="">

	<a class="moz-txt-link-freetext" href="http://linux.junsun.net/patches/generic/experimental/030716.a-jstrace.patch">http://linux.junsun.net/patches/generic/experimental/030716.a-jstrace.patch</a>

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

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

--------------080800070704020208060604--

From jsun@mvista.com Mon Aug 18 18:08:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Aug 2003 18:08:44 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:19443 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225299AbTHRRIe>;
	Mon, 18 Aug 2003 18:08:34 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h7IH8VN16055;
	Mon, 18 Aug 2003 10:08:32 -0700
Date: Mon, 18 Aug 2003 10:08:31 -0700
From: Jun Sun <jsun@mvista.com>
To: "Sirotkin, Alexander" <demiurg@ti.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: tasklet latency and system calls on mips
Message-ID: <20030818100831.A16027@mvista.com>
References: <3F3A411C.70603@ti.com> <20030813095446.C9655@mvista.com> <3F3B53C0.30408@ti.com> <20030814094515.B1203@mvista.com> <3F40F0F0.1080106@ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3F40F0F0.1080106@ti.com>; from demiurg@ti.com on Mon, Aug 18, 2003 at 06:29:52PM +0300
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: 3066
X-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, Aug 18, 2003 at 06:29:52PM +0300, Sirotkin, Alexander wrote:
> 
> 
> 
> The tasklet should be executed at the return of interrupt handling.
> 
> If not, there is a bug.
> 
>   
> 
> I have a feeling that we are going in circles. Tasklets are executed at
> the return of interrupt handler.
> However, I suspect that this is not enough. 

If you follow this, plus "tasklet_schedule() is indeed called in an interrupt
handler", you will should see "executing tasklet at the return of interrupt
handler"  is _obviously_ enough.

> On mips (contrary to x86),
> system call is NOT an interrupt.
> It's a different exception with different handler. Therefore I suspect
> that tasklets are NOT called at 
> the end of system call exception handler (which is a different handler,
> not do_IRQ).
>

... which is fine, if you can follow the above logic.

Jun

From sagarwal10@hotmail.com Tue Aug 19 02:25:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Aug 2003 02:26:02 +0100 (BST)
Received: from law14-f111.law14.hotmail.com ([IPv6:::ffff:64.4.21.111]:10504
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225301AbTHSBZ7>; Tue, 19 Aug 2003 02:25:59 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 18 Aug 2003 18:25:49 -0700
Received: from 128.107.165.33 by lw14fd.law14.hotmail.msn.com with HTTP;
	Tue, 19 Aug 2003 01:25:48 GMT
X-Originating-IP: [128.107.165.33]
X-Originating-Email: [sagarwal10@hotmail.com]
From: "Shalabh Agarwal" <sagarwal10@hotmail.com>
To: linux-mips@linux-mips.org, java-linux@java.blackdown.org
Subject: JVM & JIT for MIPs processors
Date: Tue, 19 Aug 2003 01:25:48 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <Law14-F111iAwUI9NC100065ac2@hotmail.com>
X-OriginalArrivalTime: 19 Aug 2003 01:25:49.0234 (UTC) FILETIME=[D25C8120:01C365F0]
Return-Path: <sagarwal10@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: 3067
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sagarwal10@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi

I was wondering if there are any JVM and JITs on Linux with support for the 
extensive Java
libraries and would run on MIPs machines?

Kaffe doesn't seem complete enough and Blackdown doesn't have a MIPs 
download
available.

It doesn't have to be free - we would be ready to license software. If 
anyone knows
of any companies that do this I'd appreciate the information.

thanks.

_________________________________________________________________
<b>MSN 8:</b> Get 6 months for $9.95/month. 
http://join.msn.com/?page=dept/dialup


From Yasushi.SHOJI@atmark-techno.com Tue Aug 19 02:54:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Aug 2003 02:54:20 +0100 (BST)
Received: from dns1.atmark-techno.com ([IPv6:::ffff:61.199.192.114]:36101 "EHLO
	dns1.atmark-techno.com") by linux-mips.org with ESMTP
	id <S8225301AbTHSByS>; Tue, 19 Aug 2003 02:54:18 +0100
Received: from wat.atmark-techno.com (unknown [192.168.10.81])
	by dns1.atmark-techno.com (Postfix) with ESMTP id 312713E614
	for <linux-mips@linux-mips.org>; Tue, 19 Aug 2003 10:54:08 +0900 (JST)
Date: Tue, 19 Aug 2003 10:54:08 +0900
From: Yasushi SHOJI <Yasushi.SHOJI@atmark-techno.com>
To: linux-mips@linux-mips.org
Subject: GPIO support for db1100
User-Agent: User-Agent: Wanderlust/2.10.1
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20030819015408.312713E614@dns1.atmark-techno.com>
Return-Path: <Yasushi.SHOJI@atmark-techno.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3068
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Yasushi.SHOJI@atmark-techno.com
Precedence: bulk
X-list: linux-mips

Steve and all,

I'd like to add gpio support to db1100 and/or au1100.

since there already is au1000_gpio.c in driver/char, should I go
fixing and renaming au1000_gpio.c to au1x00_gpio.c or create
au1100_gpio.c and asm-mips/au1100_gpio.h?

tia,
--
       yashi

From ralf@linux-mips.org Tue Aug 19 04:38:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Aug 2003 04:38:50 +0100 (BST)
Received: from p508B5DEF.dip.t-dialin.net ([IPv6:::ffff:80.139.93.239]:56729
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225301AbTHSDis>; Tue, 19 Aug 2003 04:38:48 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h7J3cj8R007218;
	Tue, 19 Aug 2003 05:38:45 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h7J3ci4u007217;
	Tue, 19 Aug 2003 05:38:44 +0200
Date: Tue, 19 Aug 2003 05:38:43 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030819033843.GA6223@linux-mips.org>
References: <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030812155517.7029C-100000@delta.ds2.pg.gda.pl> <20030812140452.GD10792@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030812140452.GD10792@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3069
X-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, Aug 12, 2003 at 04:04:52PM +0200, Thiemo Seufer wrote:

> > > #ifdef __mips64
> > > # define MFC0		dmfc0
> > > # define MTC0		dmtc0
> > > #else
> > > # define MFC0		mfc0
> > > # define MTC0		mtc0
> > > #endif
> > 
> >  I'd go for CONFIG_MIPS64 here.
> 
> This would work as well, but I prefer compiler intrinsic defines
> over custom configury.

I agree for this particular header file because it's been copied into
user applications.  So ideally it should be able to live entirely without
CONFIG_* symbols rsp. <linux/config.h>.

  Ralf

From ralf@linux-mips.org Tue Aug 19 04:52:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Aug 2003 04:52:51 +0100 (BST)
Received: from p508B5DEF.dip.t-dialin.net ([IPv6:::ffff:80.139.93.239]:43418
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225301AbTHSDwt>; Tue, 19 Aug 2003 04:52:49 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h7J3qk8R007516;
	Tue, 19 Aug 2003 05:52:46 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h7J3qhap007515;
	Tue, 19 Aug 2003 05:52:43 +0200
Date: Tue, 19 Aug 2003 05:52:43 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Cc: kumba@gentoo.org, linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030819035242.GB6223@linux-mips.org>
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp> <3F388E0C.50802@gentoo.org> <20030812.182529.18309031.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030812.182529.18309031.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3070
X-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, Aug 12, 2003 at 06:25:29PM +0900, Atsushi Nemoto wrote:

> Only affected code I found is __BUILD_clear_ade.  So the 32-bit kernel
> compiled with -mips3 will work fine normally, but once an address
> error occur the kernel will crash.
> 
> As Thiemo said, it seems include/asm-mips/asm.h should be fixed
> instead of Makefile.  Still investigating...

No.  We may argue if the compiler is defining the wrong symbols for given
options or the Makefile passes the wrong options but the __mips64 symbol
is a define that exists since 64-bit MIPS compilers exist.  It simply
should not be defined at this point.

  Ralf

From ralf@linux-mips.org Tue Aug 19 04:57:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Aug 2003 04:58:00 +0100 (BST)
Received: from p508B5DEF.dip.t-dialin.net ([IPv6:::ffff:80.139.93.239]:63386
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225301AbTHSD56>; Tue, 19 Aug 2003 04:57:58 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h7J3vu8R007619;
	Tue, 19 Aug 2003 05:57:56 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h7J3vujF007618;
	Tue, 19 Aug 2003 05:57:56 +0200
Date: Tue, 19 Aug 2003 05:57:56 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030819035756.GC6223@linux-mips.org>
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp> <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3071
X-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, Aug 12, 2003 at 08:51:18AM +0200, Thiemo Seufer wrote:

> > 	GCCFLAGS += -mabi=32 -march=mips2 -mtune=r4600 -Wa,--trap
> > (or	GCCFLAGS += $(call check_gcc, -mcpu=r4600 -mips2, -mabi=32 -march=mips2 -mtune=r4600) -Wa,--trap)
> > 
> > Isn't it?
> 
> -march=mips2 is an alias for -march=r6000, I don't think that's a
> good choice.

Why? MIPSII / MIPS32 are the highest ISAs supported for building 32-bit
kernels so that makes sense.

  Ralf

From ica2_ts@csv.ica.uni-stuttgart.de Tue Aug 19 07:41:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Aug 2003 07:41:28 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:4729
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225301AbTHSGlZ>; Tue, 19 Aug 2003 07:41:25 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19p0BD-0004ZM-00
	for linux-mips@linux-mips.org; Tue, 19 Aug 2003 08:41:19 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19p0BC-0003xK-00
	for <linux-mips@linux-mips.org>; Tue, 19 Aug 2003 08:41:18 +0200
Date: Tue, 19 Aug 2003 08:41:18 +0200
To: linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030819064118.GB13468@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030812.152654.74756131.nemoto@toshiba-tops.co.jp> <20030812065118.GD23104@rembrandt.csv.ica.uni-stuttgart.de> <20030819035756.GC6223@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030819035756.GC6223@linux-mips.org>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3072
X-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

Ralf Baechle wrote:
> On Tue, Aug 12, 2003 at 08:51:18AM +0200, Thiemo Seufer wrote:
> 
> > > 	GCCFLAGS += -mabi=32 -march=mips2 -mtune=r4600 -Wa,--trap
> > > (or	GCCFLAGS += $(call check_gcc, -mcpu=r4600 -mips2, -mabi=32 -march=mips2 -mtune=r4600) -Wa,--trap)
> > > 
> > > Isn't it?
> > 
> > -march=mips2 is an alias for -march=r6000, I don't think that's a
> > good choice.
> 
> Why? MIPSII / MIPS32 are the highest ISAs supported for building 32-bit
> kernels so that makes sense.

Because you get only MIPS II instructions then. This doesn't matter
much for R4600, but the improvements of later ISAs won't be used.

-mabi=32 -march=r4600 works for 32bit kernels with newer toolchains,
there's no need to use -mtune separately.


Thiemo

From macro@ds2.pg.gda.pl Tue Aug 19 13:22:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Aug 2003 13:22:43 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:42638 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225309AbTHSMWl>; Tue, 19 Aug 2003 13:22:41 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA29602;
	Tue, 19 Aug 2003 14:22:38 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 19 Aug 2003 14:22:37 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
In-Reply-To: <20030819033843.GA6223@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030819140527.29184B-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: 3073
X-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, 19 Aug 2003, Ralf Baechle wrote:

> > > > #ifdef __mips64
> > > > # define MFC0		dmfc0
> > > > # define MTC0		dmtc0
> > > > #else
> > > > # define MFC0		mfc0
> > > > # define MTC0		mtc0
> > > > #endif
> > > 
> > >  I'd go for CONFIG_MIPS64 here.
> > 
> > This would work as well, but I prefer compiler intrinsic defines
> > over custom configury.
> 
> I agree for this particular header file because it's been copied into
> user applications.  So ideally it should be able to live entirely without
> CONFIG_* symbols rsp. <linux/config.h>.

 OK, I now recall <asm/asm.h> and <asm/regdef.h> as traditionally being
often included in user assembly.  But then we should get rid of
configuration dependency entirely, i.e. remove "#include <linux/config.h>" 
and a CONFIG_CPU_HAS_PREFETCH dependency.  Perhaps <asm/pref.h> would be
desireable if we don't want wasting cycles.

 It's a pity a more reasonable choice wasn't made for the location of
these headers -- the asm and linux trees shouldn't really be used for
userland.  For example Alpha has <alpha/regdef.h> that comes from glibc. 

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


From ralf@linux-mips.org Tue Aug 19 13:34:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Aug 2003 13:35:04 +0100 (BST)
Received: from p508B5DEF.dip.t-dialin.net ([IPv6:::ffff:80.139.93.239]:46777
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225309AbTHSMe7>; Tue, 19 Aug 2003 13:34:59 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h7JCYs8R017880;
	Tue, 19 Aug 2003 14:34:54 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h7JCYr7E017879;
	Tue, 19 Aug 2003 14:34:53 +0200
Date: Tue, 19 Aug 2003 14:34:53 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org
Subject: Re: GCCFLAGS for gcc 3.3.x (-march and _MIPS_ISA)
Message-ID: <20030819123453.GA17120@linux-mips.org>
References: <20030819033843.GA6223@linux-mips.org> <Pine.GSO.3.96.1030819140527.29184B-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.1030819140527.29184B-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3074
X-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, Aug 19, 2003 at 02:22:37PM +0200, Maciej W. Rozycki wrote:

>  OK, I now recall <asm/asm.h> and <asm/regdef.h> as traditionally being
> often included in user assembly.  But then we should get rid of
> configuration dependency entirely, i.e. remove "#include <linux/config.h>" 
> and a CONFIG_CPU_HAS_PREFETCH dependency.  Perhaps <asm/pref.h> would be
> desireable if we don't want wasting cycles.
> 
>  It's a pity a more reasonable choice wasn't made for the location of
> these headers -- the asm and linux trees shouldn't really be used for
> userland.  For example Alpha has <alpha/regdef.h> that comes from glibc. 

I completly agree on that.  Userspace should used <sys/regdef.h>,
<sys/fpregdef.h> and <sys/asm.h> for that which are the three de-facto
standard headers used throughout the MIPS world.

As for prefetching I like your suggestion of <asm/pref.h>.  The prefetching
stuff is a Linux extension of asm.h.  Moving it to it's own header file
along with the necessary bits for <linux/prefetch.h> would make a nice
cleanup.

  Ralf

From ppopov@mvista.com Tue Aug 19 17:06:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Aug 2003 17:06:30 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:14067 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225309AbTHSQG0>;
	Tue, 19 Aug 2003 17:06:26 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA02269;
	Tue, 19 Aug 2003 09:06:20 -0700
Subject: Re: GPIO support for db1100
From: Pete Popov <ppopov@mvista.com>
To: Yasushi SHOJI <Yasushi.SHOJI@atmark-techno.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030819015408.312713E614@dns1.atmark-techno.com>
References: <20030819015408.312713E614@dns1.atmark-techno.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1061309193.1488.450.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 19 Aug 2003 09:06:33 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3075
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Mon, 2003-08-18 at 18:54, Yasushi SHOJI wrote:
> Steve and all,
> 
> I'd like to add gpio support to db1100 and/or au1100.
> 
> since there already is au1000_gpio.c in driver/char, should I go
> fixing and renaming au1000_gpio.c to au1x00_gpio.c or create
> au1100_gpio.c and asm-mips/au1100_gpio.h?

Why do you need to rename the file? The only way to do that with cvs is
to delete it and add the new file, and then you lose all cvs log info.
It would have been nice to have named the file au1x00_gpio instead of
au1000_gpio, but I don't think that's critical to using the driver.

Pete


From Yasushi.SHOJI@atmark-techno.com Wed Aug 20 01:02:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Aug 2003 01:02:38 +0100 (BST)
Received: from dns1.atmark-techno.com ([IPv6:::ffff:61.199.192.114]:8199 "EHLO
	dns1.atmark-techno.com") by linux-mips.org with ESMTP
	id <S8225316AbTHTACg>; Wed, 20 Aug 2003 01:02:36 +0100
Received: from wat.atmark-techno.com (unknown [192.168.10.81])
	by dns1.atmark-techno.com (Postfix) with ESMTP
	id 8D1233E614; Wed, 20 Aug 2003 09:02:23 +0900 (JST)
Date: Wed, 20 Aug 2003 09:02:23 +0900
From: Yasushi SHOJI <Yasushi.SHOJI@atmark-techno.com>
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: GPIO support for db1100
In-Reply-To: <1061309193.1488.450.camel@zeus.mvista.com>
References: <20030819015408.312713E614@dns1.atmark-techno.com>
	<1061309193.1488.450.camel@zeus.mvista.com>
User-Agent: User-Agent: Wanderlust/2.10.1
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20030820000223.8D1233E614@dns1.atmark-techno.com>
Return-Path: <Yasushi.SHOJI@atmark-techno.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3076
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Yasushi.SHOJI@atmark-techno.com
Precedence: bulk
X-list: linux-mips

At 19 Aug 2003 09:06:33 -0700,
Pete Popov wrote:
> 
> On Mon, 2003-08-18 at 18:54, Yasushi SHOJI wrote:
> > Steve and all,
> > 
> > I'd like to add gpio support to db1100 and/or au1100.
> > 
> > since there already is au1000_gpio.c in driver/char, should I go
> > fixing and renaming au1000_gpio.c to au1x00_gpio.c or create
> > au1100_gpio.c and asm-mips/au1100_gpio.h?
> 
> Why do you need to rename the file? The only way to do that with cvs is
> to delete it and add the new file, and then you lose all cvs log info.
> It would have been nice to have named the file au1x00_gpio instead of
> au1000_gpio, but I don't think that's critical to using the driver.

I agree that file name is not critial at all.

so should I go with ifdef's to add au1100's primary and secondary gpio
support in au1000_gpio.c?

yes, even with primary gpio, pin assign differ between au1000 and
au1100. that means avail_mask in struct pinfuc_to_avail must change,
IMHO.
--
        yashi

From ppopov@mvista.com Wed Aug 20 01:07:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Aug 2003 01:07:43 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:56566 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225316AbTHTAHl>;
	Wed, 20 Aug 2003 01:07:41 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA25664;
	Tue, 19 Aug 2003 17:07:35 -0700
Subject: Re: GPIO support for db1100
From: Pete Popov <ppopov@mvista.com>
To: Yasushi SHOJI <Yasushi.SHOJI@atmark-techno.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030820000223.8D1233E614@dns1.atmark-techno.com>
References: <20030819015408.312713E614@dns1.atmark-techno.com>
	 <1061309193.1488.450.camel@zeus.mvista.com>
	 <20030820000223.8D1233E614@dns1.atmark-techno.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1061338072.1488.642.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 19 Aug 2003 17:07:52 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3077
X-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-08-19 at 17:02, Yasushi SHOJI wrote:
> At 19 Aug 2003 09:06:33 -0700,
> Pete Popov wrote:
> > 
> > On Mon, 2003-08-18 at 18:54, Yasushi SHOJI wrote:
> > > Steve and all,
> > > 
> > > I'd like to add gpio support to db1100 and/or au1100.
> > > 
> > > since there already is au1000_gpio.c in driver/char, should I go
> > > fixing and renaming au1000_gpio.c to au1x00_gpio.c or create
> > > au1100_gpio.c and asm-mips/au1100_gpio.h?
> > 
> > Why do you need to rename the file? The only way to do that with cvs is
> > to delete it and add the new file, and then you lose all cvs log info.
> > It would have been nice to have named the file au1x00_gpio instead of
> > au1000_gpio, but I don't think that's critical to using the driver.
> 
> I agree that file name is not critial at all.
> 
> so should I go with ifdef's to add au1100's primary and secondary gpio
> support in au1000_gpio.c?
> 
> yes, even with primary gpio, pin assign differ between au1000 and
> au1100. that means avail_mask in struct pinfuc_to_avail must change,
> IMHO.

Well, if there's too many changes, then perhaps a new driver is in
order. The secondary gpio on the au1100 and au1500 are similar, I think.
Perhaps you can make the driver work on both CPUs :)?

Pete


From Yasushi.SHOJI@atmark-techno.com Wed Aug 20 01:15:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Aug 2003 01:15:35 +0100 (BST)
Received: from dns1.atmark-techno.com ([IPv6:::ffff:61.199.192.114]:9223 "EHLO
	dns1.atmark-techno.com") by linux-mips.org with ESMTP
	id <S8225316AbTHTAPd>; Wed, 20 Aug 2003 01:15:33 +0100
Received: from wat.atmark-techno.com (unknown [192.168.10.81])
	by dns1.atmark-techno.com (Postfix) with ESMTP
	id 0CEC33E614; Wed, 20 Aug 2003 09:15:30 +0900 (JST)
Date: Wed, 20 Aug 2003 09:15:30 +0900
From: Yasushi SHOJI <Yasushi.SHOJI@atmark-techno.com>
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: GPIO support for db1100
In-Reply-To: <1061338072.1488.642.camel@zeus.mvista.com>
References: <20030819015408.312713E614@dns1.atmark-techno.com>
	<1061309193.1488.450.camel@zeus.mvista.com>
	<20030820000223.8D1233E614@dns1.atmark-techno.com>
	<1061338072.1488.642.camel@zeus.mvista.com>
User-Agent: User-Agent: Wanderlust/2.10.1
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20030820001531.0CEC33E614@dns1.atmark-techno.com>
Return-Path: <Yasushi.SHOJI@atmark-techno.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3078
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Yasushi.SHOJI@atmark-techno.com
Precedence: bulk
X-list: linux-mips

At 19 Aug 2003 17:07:52 -0700,
Pete Popov wrote:
> 
> On Tue, 2003-08-19 at 17:02, Yasushi SHOJI wrote:
> > At 19 Aug 2003 09:06:33 -0700,
> > Pete Popov wrote:
> > > 
> > > On Mon, 2003-08-18 at 18:54, Yasushi SHOJI wrote:
> > > > Steve and all,
> > > > 
> > > > I'd like to add gpio support to db1100 and/or au1100.
> > > > 
> > > > since there already is au1000_gpio.c in driver/char, should I go
> > > > fixing and renaming au1000_gpio.c to au1x00_gpio.c or create
> > > > au1100_gpio.c and asm-mips/au1100_gpio.h?
> > > 
> > > Why do you need to rename the file? The only way to do that with cvs is
> > > to delete it and add the new file, and then you lose all cvs log info.
> > > It would have been nice to have named the file au1x00_gpio instead of
> > > au1000_gpio, but I don't think that's critical to using the driver.
> > 
> > I agree that file name is not critial at all.
> > 
> > so should I go with ifdef's to add au1100's primary and secondary gpio
> > support in au1000_gpio.c?
> > 
> > yes, even with primary gpio, pin assign differ between au1000 and
> > au1100. that means avail_mask in struct pinfuc_to_avail must change,
> > IMHO.
> 
> Well, if there's too many changes, then perhaps a new driver is in
> order. The secondary gpio on the au1100 and au1500 are similar, I think.
> Perhaps you can make the driver work on both CPUs :)?

I'll try. but don't have au1500 here. so I need someone to test it.
--
        yashi

From mic@daemon.nethack.at Wed Aug 20 11:03:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Aug 2003 11:04:02 +0100 (BST)
Received: from daemon.nethack.at ([IPv6:::ffff:62.116.47.92]:6882 "EHLO
	daemon.nethack.at") by linux-mips.org with ESMTP
	id <S8224821AbTHTKD5>; Wed, 20 Aug 2003 11:03:57 +0100
Received: (qmail 32732 invoked by uid 1000); 20 Aug 2003 10:03:41 -0000
Date: Wed, 20 Aug 2003 12:03:40 +0200
From: Michael Dosser <mic@nethack.at>
To: linux-mips@linux-mips.org
Subject: mips64
Message-ID: <20030820100339.GO15525@nethack.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Organization: Nethack.at
X-Operating-System: Linux 2.4.19 mips
X-sig-random-gen: http://cfml.sourceforge.net/perl/chsig.tar.gz
X-spam-note: Sending SPAM is a violation of both Austrian and US law and will at least trigger a complaint at your providers postmaster.
Return-Path: <mic@daemon.nethack.at>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3079
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mic@nethack.at
Precedence: bulk
X-list: linux-mips

Hi,

I'm successfully running Debian/GNU Linux on a SGI Indy R4600PC@100Mhz
for over a year now. I'm very happy with the stability of Linux on that
machine. But since the machine is relatively slow (currently 30-35 
shell user continuosly connected), I bought an Indigo2 R4400SC@250Mhz.

I thought of putting a mips64 kernel on the new machine: Got the rpm's
from ftp.linux-mips.org, converted them with alien to debs and installed 
them on my quad xeon Debian box - checked out the linux source and 
started compiling:

# cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -r linux_2_4 linux
# cd linux
# make ARCH=mips64 dep
# make ARCH=mips64 clean
# make ARCH=mips64 all

Error message with gcc version egcs-2.91.66 19990314 (egcs-1.1.2
release)

[...]
make[2]: Entering directory `/usr/local/src/mips/linux/arch/mips/math-emu'
mips64-linux-gcc -D__KERNEL__ -I/usr/local/src/mips/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /usr/local/src/mips/linux/include/asm/gcc -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mcpu=r4600 -mips3 -Wa,-32 -Wa,-mgp64   -nostdinc -iwithprefix include -DKBUILD_BASENAME=cp1emu  -c -o cp1emu.o cp1emu.c
cp1emu.c: In function `fpu_emulator_cop1Handler':
cp1emu.c:1328: internal error--unrecognizable insn:
(insn 310 33 25 (set (reg:SI 159)
        (reg/v:DI 87)) -1 (insn_list:REG_DEP_ANTI 28 (insn_list 33 (nil)))
    (nil))
../../gcc/toplev.c:1367: Internal compiler error in function fatal_insn
make[2]: *** [cp1emu.o] Error 1
make[2]: Leaving directory `/usr/local/src/mips/linux/arch/mips/math-emu'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/local/src/mips/linux/arch/mips/math-emu'
make: *** [_dir_arch/mips/math-emu] Error 2
# 

Error with gcc version 2.95.4 20010319 (prerelease):

[...]
mips64-linux-ld --oformat elf32-tradbigmips   -r -o kernel.o sched.o
dma.o fork.o exec_domain.o panic.o printk.o module.o exit.o itimer.o
info.o time.o softirq.o resource.o sysctl.o acct.o capability.o ptrace.o
timer.o user.o signal.o sys.o kmod.o context.o ksyms.o
mips64-linux-ld: target elf32-tradbigmips not found
make[2]: *** [kernel.o] Error 1
make[2]: Leaving directory `/usr/local/src/mips/linux/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/local/src/mips/linux/kernel'
make: *** [_dir_kernel] Error 2
#

Ok, the latter seems to be related to objdump, right?
mips64-linux-objdump: supported targets: elf32-bigmips elf32-littlemips
elf64-bigmips elf64-littlemips ecoff-bigmips ecoff-littlemips
elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex
binary ihex

The package on linux-mips.org seems not to be including
elf32-tradbigmips ...

Can somebody help me with this? Btw: same errors with co -r linux_2_4_21
...

Thank you,mic

-- 
> Please specifically define where data goes that is sent to /dev/null
[...]
Answer 2.  All the data goes into another dimension, and comes out of
/dev/random.            Stephen Montgomery-Smith on freebsd-hackers

From ica2_ts@csv.ica.uni-stuttgart.de Wed Aug 20 11:15:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Aug 2003 11:15:14 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:48766
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224821AbTHTKPM>; Wed, 20 Aug 2003 11:15:12 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19pPzh-0005eH-00
	for linux-mips@linux-mips.org; Wed, 20 Aug 2003 12:15:09 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19pPzh-0000w8-00
	for <linux-mips@linux-mips.org>; Wed, 20 Aug 2003 12:15:09 +0200
Date: Wed, 20 Aug 2003 12:15:09 +0200
To: linux-mips@linux-mips.org
Subject: Re: mips64
Message-ID: <20030820101509.GA16419@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030820100339.GO15525@nethack.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030820100339.GO15525@nethack.at>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3080
X-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

Michael Dosser wrote:
> Hi,
> 
> I'm successfully running Debian/GNU Linux on a SGI Indy R4600PC@100Mhz
> for over a year now. I'm very happy with the stability of Linux on that
> machine. But since the machine is relatively slow (currently 30-35 
> shell user continuosly connected), I bought an Indigo2 R4400SC@250Mhz.
> 
> I thought of putting a mips64 kernel on the new machine: Got the rpm's
> from ftp.linux-mips.org, converted them with alien to debs and installed 
> them on my quad xeon Debian box - checked out the linux source and 
> started compiling:

The 64bit IP22 Kernel was broken for quite some time, I don't know if
this changed in the meanwhile.

[snip]
> Error message with gcc version egcs-2.91.66 19990314 (egcs-1.1.2
> release)
> 
> [...]
> make[2]: Entering directory `/usr/local/src/mips/linux/arch/mips/math-emu'
> mips64-linux-gcc -D__KERNEL__ -I/usr/local/src/mips/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /usr/local/src/mips/linux/include/asm/gcc -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mcpu=r4600 -mips3 -Wa,-32 -Wa,-mgp64   -nostdinc -iwithprefix include -DKBUILD_BASENAME=cp1emu  -c -o cp1emu.o cp1emu.c
> cp1emu.c: In function `fpu_emulator_cop1Handler':
> cp1emu.c:1328: internal error--unrecognizable insn:
> (insn 310 33 25 (set (reg:SI 159)
>         (reg/v:DI 87)) -1 (insn_list:REG_DEP_ANTI 28 (insn_list 33 (nil)))
>     (nil))
> ../../gcc/toplev.c:1367: Internal compiler error in function fatal_insn

egcs is known to be broken WRT, and horribly outdated anyway.

[snip]
> Error with gcc version 2.95.4 20010319 (prerelease):
> 
> [...]
> mips64-linux-ld --oformat elf32-tradbigmips   -r -o kernel.o sched.o
> dma.o fork.o exec_domain.o panic.o printk.o module.o exit.o itimer.o
> info.o time.o softirq.o resource.o sysctl.o acct.o capability.o ptrace.o
> timer.o user.o signal.o sys.o kmod.o context.o ksyms.o
> mips64-linux-ld: target elf32-tradbigmips not found
> make[2]: *** [kernel.o] Error 1
> make[2]: Leaving directory `/usr/local/src/mips/linux/kernel'
> make[1]: *** [first_rule] Error 2
> make[1]: Leaving directory `/usr/local/src/mips/linux/kernel'
> make: *** [_dir_kernel] Error 2
> #
> 
> Ok, the latter seems to be related to objdump, right?

No, this ld is too old to handle elf32-tradbigmips.
You'll need a more up to date toolchain.


Thiemo

From ladis@linux-mips.org Wed Aug 20 11:23:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Aug 2003 11:23:08 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8224821AbTHTKXG>; Wed, 20 Aug 2003 11:23:06 +0100
Date: Wed, 20 Aug 2003 11:23:06 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org, Michael Dosser <mic@nethack.at>
Subject: Re: mips64
Message-ID: <20030820112306.A2620@ftp.linux-mips.org>
References: <20030820100339.GO15525@nethack.at> <20030820101509.GA16419@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030820101509.GA16419@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Wed, Aug 20, 2003 at 12:15:09PM +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: 3081
X-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 Wed, Aug 20, 2003 at 12:15:09PM +0200, Thiemo Seufer wrote:
> Michael Dosser wrote:
> > Hi,
> > 
> > I'm successfully running Debian/GNU Linux on a SGI Indy R4600PC@100Mhz
> > for over a year now. I'm very happy with the stability of Linux on that
> > machine. But since the machine is relatively slow (currently 30-35 
> > shell user continuosly connected), I bought an Indigo2 R4400SC@250Mhz.
> > 
> > I thought of putting a mips64 kernel on the new machine: Got the rpm's
> > from ftp.linux-mips.org, converted them with alien to debs and installed 
> > them on my quad xeon Debian box - checked out the linux source and 
> > started compiling:
> 
> The 64bit IP22 Kernel was broken for quite some time, I don't know if
> this changed in the meanwhile.

It works now.

> [snip]
> > Error message with gcc version egcs-2.91.66 19990314 (egcs-1.1.2
> > release)
> > 
> > [...]
> > make[2]: Entering directory `/usr/local/src/mips/linux/arch/mips/math-emu'
> > mips64-linux-gcc -D__KERNEL__ -I/usr/local/src/mips/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /usr/local/src/mips/linux/include/asm/gcc -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mcpu=r4600 -mips3 -Wa,-32 -Wa,-mgp64   -nostdinc -iwithprefix include -DKBUILD_BASENAME=cp1emu  -c -o cp1emu.o cp1emu.c
> > cp1emu.c: In function `fpu_emulator_cop1Handler':
> > cp1emu.c:1328: internal error--unrecognizable insn:
> > (insn 310 33 25 (set (reg:SI 159)
> >         (reg/v:DI 87)) -1 (insn_list:REG_DEP_ANTI 28 (insn_list 33 (nil)))
> >     (nil))
> > ../../gcc/toplev.c:1367: Internal compiler error in function fatal_insn
> 
> egcs is known to be broken WRT, and horribly outdated anyway.
> 
> [snip]
> > Error with gcc version 2.95.4 20010319 (prerelease):
> > 
> > [...]
> > mips64-linux-ld --oformat elf32-tradbigmips   -r -o kernel.o sched.o
> > dma.o fork.o exec_domain.o panic.o printk.o module.o exit.o itimer.o
> > info.o time.o softirq.o resource.o sysctl.o acct.o capability.o ptrace.o
> > timer.o user.o signal.o sys.o kmod.o context.o ksyms.o
> > mips64-linux-ld: target elf32-tradbigmips not found
> > make[2]: *** [kernel.o] Error 1
> > make[2]: Leaving directory `/usr/local/src/mips/linux/kernel'
> > make[1]: *** [first_rule] Error 2
> > make[1]: Leaving directory `/usr/local/src/mips/linux/kernel'
> > make: *** [_dir_kernel] Error 2
> > #
> > 
> > Ok, the latter seems to be related to objdump, right?
> 
> No, this ld is too old to handle elf32-tradbigmips.
> You'll need a more up to date toolchain.

gcc-2.95.4 and binutils-2.14 works ok for me.

ladis

From mic@daemon.nethack.at Wed Aug 20 13:08:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Aug 2003 13:08:21 +0100 (BST)
Received: from daemon.nethack.at ([IPv6:::ffff:62.116.47.92]:46050 "EHLO
	daemon.nethack.at") by linux-mips.org with ESMTP
	id <S8224821AbTHTMIT>; Wed, 20 Aug 2003 13:08:19 +0100
Received: (qmail 1134 invoked by uid 1000); 20 Aug 2003 12:08:01 -0000
Date: Wed, 20 Aug 2003 14:08:01 +0200
From: Michael Dosser <mic@nethack.at>
To: linux-mips@linux-mips.org
Subject: Re: mips64
Message-ID: <20030820120759.GP15525@nethack.at>
References: <20030820100339.GO15525@nethack.at> <20030820101509.GA16419@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030820101509.GA16419@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.4.1i
Organization: Nethack.at
X-Operating-System: Linux 2.4.19 mips
X-sig-random-gen: http://cfml.sourceforge.net/perl/chsig.tar.gz
X-spam-note: Sending SPAM is a violation of both Austrian and US law and will at least trigger a complaint at your providers postmaster.
Return-Path: <mic@daemon.nethack.at>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3082
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mic@nethack.at
Precedence: bulk
X-list: linux-mips

Hi again,

* On 2003-08-20 12:15 <ica2_ts@csv.ica.uni-stuttgart.de> wrote:

> egcs is known to be broken WRT, and horribly outdated anyway.

That's right. But I thought better trying out first before writing an
email.

> No, this ld is too old to handle elf32-tradbigmips.
> You'll need a more up to date toolchain.

I could slap myself for this: I fetched binutils 2.9.5 instead of 2.13.1
while thinking 9 > 1 and not reading 13. *hmpf* Sorry for this. After
installing binutils-2.13.1 the compile went fine.

# ls -l arch/mips64/boot
total 2256
drwxr-xr-x    2 root     root         4096 Aug 20 11:13 CVS
-rw-r--r--    1 root     root          922 Jan 10  2003 Makefile
-rwxr-xr-x    1 root     root         7965 Aug 20 13:44 addinitrd
-rwxr-xr-x    1 root     root        16138 Aug 20 13:44 elf2ecoff
-rwxr-xr-x    1 root     root      2269392 Aug 20 13:44 vmlinux.ecoff
# file arch/mips64/boot/vmlinux.ecoff
vmlinux.ecoff: MIPSEB ECOFF executable (impure) stripped - version 0.200
#

That's it I suppose :) I'm looking forward to test this kernel ...

Thanks for your help.

Ciao,mic

-- 
while !asleep {sheep ++};

From michael_pruznick@mvista.com Wed Aug 20 23:48:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Aug 2003 23:48:34 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:45307 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224821AbTHTWsc>;
	Wed, 20 Aug 2003 23:48:32 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA17543
	for <linux-mips@linux-mips.org>; Wed, 20 Aug 2003 15:48:28 -0700
Message-ID: <3F43FABC.20E9C11@mvista.com>
Date: Wed, 20 Aug 2003 16:48:28 -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: linux-mips@linux-mips.org
Subject: root=nfs no longer works in 2.4
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: 3083
X-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

In the last week or so root=nfs has stopped
working.  Must now use root=/dev/nfs.

Just wondering if this is an intentional
change or a bug?

From taoyong2002cncq@yahoo.com.cn Thu Aug 21 08:32:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Aug 2003 08:32:46 +0100 (BST)
Received: from smtp014.mail.yahoo.com ([IPv6:::ffff:216.136.173.58]:14342 "HELO
	smtp014.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225345AbTHUHco>; Thu, 21 Aug 2003 08:32:44 +0100
Received: from unknown (HELO ime?ty) (taoyong2002cncq@61.186.188.65 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Aug 2003 07:32:24 -0000
From: "taoyong" <taoyong2002cncq@yahoo.com.cn>
To: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: Can the yaffs.o be made in Cygwine?
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Date: Thu, 21 Aug 2003 15:36:30 +0800
Message-Id: <20030821073244Z8225345-1272+4349@linux-mips.org>
Return-Path: <taoyong2002cncq@yahoo.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3084
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: taoyong2002cncq@yahoo.com.cn
Precedence: bulk
X-list: linux-mips

Hi all,

       I wonder whether the yaffs could be compiled under Cygwine with the mips-gcc, and get the yaffs.o .   The gcc is mips-gcc 3.2 .    Has someone tyied it?  


 best regards,
 yong





From zhufeng@koretide.com.cn Thu Aug 21 10:17:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Aug 2003 10:17:12 +0100 (BST)
Received: from p508B611E.dip.t-dialin.net ([IPv6:::ffff:80.139.97.30]:32972
	"EHLO p508B611E.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225347AbTHUJRK>; Thu, 21 Aug 2003 10:17:10 +0100
Received: from [IPv6:::ffff:210.22.155.234] ([IPv6:::ffff:210.22.155.234]:37054
	"EHLO mail.koretide.com.cn") by linux-mips.net with ESMTP
	id <S869160AbTHUJRD>; Thu, 21 Aug 2003 11:17:03 +0200
Received: from zhufeng ([192.168.1.12])
	(authenticated)
	by mail.koretide.com.cn (8.11.6/8.11.6) with ESMTP id h7L9Csc29003;
	Thu, 21 Aug 2003 17:12:54 +0800
From: =?gb2312?B?1uy371woemh1ZmVuZ1wp?= <zhufeng@koretide.com.cn>
To: "Fuxin Zhang" <fxzhang@ict.ac.cn>
Cc: <linux-mips@linux-mips.org>
Subject: RE: gdbserver and gdb debugging stub for mips
Date: Thu, 21 Aug 2003 17:14:56 +0800
Message-ID: <MGEELAPMEFMLFBMDBLKLMENDCEAA.zhufeng@koretide.com.cn>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <3F4061FC.4080806@ict.ac.cn>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <zhufeng@koretide.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3085
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zhufeng@koretide.com.cn
Precedence: bulk
X-list: linux-mips

I wanto access 0x40000000 on mips, I did the following,but still exception
happed:

     page MASK is set to 4k

    uint asid = 0;
    ulong reg_entryhi = 0x40000000 | asid;

    ulong reg_entrylo0;
    ulong phyadd0  = 0x20000000 >> 12;
    ulong pfn0 = phyadd0 << 6;
    uint tlb_C = 2 << 3;     //cache coherence bit
    uint tlb_D = 0 << 2;        //dirty bit
    uint tlb_V = 1 << 1;        // valid bit
    uint tlb_G = 1;             //global bit

    reg_entrylo0 = pfn0|tlb_C|tlb_D|tlb_V|tlb_G;
	set_entryhi(reg_entryhi);
	set_entrylo0(reg_entrylo0);
	set_entrylo1(0|tlb_G);
	tlb_write_indexed();

    *((unsigned long *)0x40000000) = 0x44;  //still trap into exception

what's the problem? thanks

-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Fuxin Zhang
Sent: 2003定8埖18晩 13:20
To: 幀件(zhufeng)
Cc: linux-mips@linux-mips.org
Subject: Re: gdbserver and gdb debugging stub for mips


An answer cited from elsewhere:
-----
    <snip>

    Rosimildo> /ecos/work/install/lib/libtarget.a(net_tcpip_ip_id.o): In
function
    Rosimildo> `ip_initid':
    Rosimildo>
/ecos/ecos-1.3.1/packages/net/tcpip/v1_0b1/src/sys/netinet/ip_id.c:231:
    Rosimildo> relocaton truncated to fit: R_MIPS_GPREL16 time

    Rosimildo> I am wondering if this seems familiar to anyone doing
    Rosimildo> MIPS stuff.

I think I know what the problem is, but I cannot be 100% sure.

The MIPS architecture allows for a certain amount of global data to be
accessed more quickly than others, using different instructions. The
compiler exploits this facility by putting small global variables into
sections .sdata and .sbss, rather than the normal sections .data and
.bss. Of course the compiler has no idea how many modules are going to
end up in the final executable. Hence at link-time it is possible that
there is now too much data in these sections, and you will get a
"relocation truncated" message. For most applications you will not hit
the limit, in fact I am somewhat surprised that any ordinary eCos
application would cause the problem to arise.

The correct solution would be for the linker to handle this situation
and decide which global variables should remain in the special region
and which ones should be moved elsewhere. In theory it could use
information such as the number of accesses to a particular global, or
maybe even profiling feedback, to decide which variables are most
worthwhile keeping in the special region. Unfortunately this would
require the linker changing the instructions used to access the
variables that are moved to the ordinary .data and .bss sections,
which is a non-trivial operation. Also, having the linker change
instructions would mess up other things such as the compiler's
attempts at instruction scheduling.

On occasion we have had requests to fix the toolchain so that it does
the right thing (for some definition of the right thing), but the work
is sufficiently involved that so far nobody has been willing to fund
it.

There is a workaround. The mips toolchain accepts an argument -G<num>,
with a default value of 8. This means that any global variable <= 8
bytes will end up in .sdata or .sbss. If you compile all the code with
a different value, e.g. -G4, then less data ends up in the special
sections so you will not hit the overflow condition. There is a
performance penalty, of course. I suggest experimenting with -G
values, and looking at the relevant gcc documentation as well since
things may have changed since the last time I looked at this. It might
also be worthwhile searching through the gcc mailing list archives at
http://gcc.gnu.org/ml/gcc/

Bart Veer // eCos net maintainer



幀件(zhufeng) wrote:

>when I build my mips program using gcc with -O0 , it is ok, while
using -o2, there come the following questions.
>lingking,,,
>
>relocation truncated to fit: R_MIPS_GPREL16  __global_ctor_start
>relocation truncated to fit: R_MIPS_GPREL16 __global_ctor_end
>relocation truncated to fit: R_MIPS_GPREL16 _recycle_start
>
>and so on.
>
>Has anybody encounter such questions?
>
>
>
>-----Original Message-----
>From: wd@denx.de [mailto:wd@denx.de]
>Sent: 2003綛??�� 23:08
>To: ��狸揃誰
>Cc: Wilson Chan; linux-mips@linux-mips.org
>Subject: Re: gdbserver and gdb debugging stub for mips
>
>
>In message <MGEELAPMEFMLFBMDBLKLIEKICEAA.zhufeng@koretide.com.cn> you
wrote:
>
>
>> what do you mean by "MIPS is NOT MIPS"? Does it mean there are too many
mips boards?
>>
>>
>
>big endian, little endian, 32 bit, 64 bit, ...
>
>It means that there are several  different  configurations,  and  you
>must use tools to match your configuration.
>
>Best regards,
>
>Wolfgang Denk
>
>
>


From fxzhang@ict.ac.cn Thu Aug 21 10:43:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Aug 2003 10:44:00 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:11212
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225347AbTHUJn6>; Thu, 21 Aug 2003 10:43:58 +0100
Received: (qmail 6464 invoked from network); 21 Aug 2003 09:35:30 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.187)
  by mail.ict.ac.cn with SMTP; 21 Aug 2003 09:35:30 -0000
Message-ID: <3F449440.4010403@ict.ac.cn>
Date: Thu, 21 Aug 2003 17:43:28 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: =?gb18030?Q?=22=D6=EC=B7=EF=5C=5C=28zhufeng=5C=5C=29=22?= 
	<zhufeng@koretide.com.cn>
CC: linux-mips@linux-mips.org
Subject: Re: gdbserver and gdb debugging stub for mips
References: <MGEELAPMEFMLFBMDBLKLMENDCEAA.zhufeng@koretide.com.cn>
In-Reply-To: <MGEELAPMEFMLFBMDBLKLMENDCEAA.zhufeng@koretide.com.cn>
Content-Type: text/plain; charset=gb18030; format=flowed
Content-Transfer-Encoding: 8bit
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: 3086
X-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



幀件(zhufeng) wrote:

>I wanto access 0x40000000 on mips, I did the following,but still exception
>happed:
>
>     page MASK is set to 4k
>
>    uint asid = 0;
>    ulong reg_entryhi = 0x40000000 | asid;
>
>    ulong reg_entrylo0;
>    ulong phyadd0  = 0x20000000 >> 12;
>    ulong pfn0 = phyadd0 << 6;
>    uint tlb_C = 2 << 3;     //cache coherence bit
>    uint tlb_D = 0 << 2;        //dirty bit
>  
>
You want to write then you should set this bit, D means "writable",not 
really dirty

>    uint tlb_V = 1 << 1;        // valid bit
>    uint tlb_G = 1;             //global bit
>
>    reg_entrylo0 = pfn0|tlb_C|tlb_D|tlb_V|tlb_G;
>	set_entryhi(reg_entryhi);
>	set_entrylo0(reg_entrylo0);
>	set_entrylo1(0|tlb_G);
>	tlb_write_indexed();
>
>    *((unsigned long *)0x40000000) = 0x44;  //still trap into exception
>
>what's the problem? thanks
>
>-----Original Message-----
>From: linux-mips-bounce@linux-mips.org
>[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Fuxin Zhang
>Sent: 2003定8埖18晩 13:20
>To: 幀件(zhufeng)
>Cc: linux-mips@linux-mips.org
>Subject: Re: gdbserver and gdb debugging stub for mips
>
>
>An answer cited from elsewhere:
>-----
>    <snip>
>
>    Rosimildo> /ecos/work/install/lib/libtarget.a(net_tcpip_ip_id.o): In
>function
>    Rosimildo> `ip_initid':
>    Rosimildo>
>/ecos/ecos-1.3.1/packages/net/tcpip/v1_0b1/src/sys/netinet/ip_id.c:231:
>    Rosimildo> relocaton truncated to fit: R_MIPS_GPREL16 time
>
>    Rosimildo> I am wondering if this seems familiar to anyone doing
>    Rosimildo> MIPS stuff.
>
>I think I know what the problem is, but I cannot be 100% sure.
>
>The MIPS architecture allows for a certain amount of global data to be
>accessed more quickly than others, using different instructions. The
>compiler exploits this facility by putting small global variables into
>sections .sdata and .sbss, rather than the normal sections .data and
>.bss. Of course the compiler has no idea how many modules are going to
>end up in the final executable. Hence at link-time it is possible that
>there is now too much data in these sections, and you will get a
>"relocation truncated" message. For most applications you will not hit
>the limit, in fact I am somewhat surprised that any ordinary eCos
>application would cause the problem to arise.
>
>The correct solution would be for the linker to handle this situation
>and decide which global variables should remain in the special region
>and which ones should be moved elsewhere. In theory it could use
>information such as the number of accesses to a particular global, or
>maybe even profiling feedback, to decide which variables are most
>worthwhile keeping in the special region. Unfortunately this would
>require the linker changing the instructions used to access the
>variables that are moved to the ordinary .data and .bss sections,
>which is a non-trivial operation. Also, having the linker change
>instructions would mess up other things such as the compiler's
>attempts at instruction scheduling.
>
>On occasion we have had requests to fix the toolchain so that it does
>the right thing (for some definition of the right thing), but the work
>is sufficiently involved that so far nobody has been willing to fund
>it.
>
>There is a workaround. The mips toolchain accepts an argument -G<num>,
>with a default value of 8. This means that any global variable <= 8
>bytes will end up in .sdata or .sbss. If you compile all the code with
>a different value, e.g. -G4, then less data ends up in the special
>sections so you will not hit the overflow condition. There is a
>performance penalty, of course. I suggest experimenting with -G
>values, and looking at the relevant gcc documentation as well since
>things may have changed since the last time I looked at this. It might
>also be worthwhile searching through the gcc mailing list archives at
>http://gcc.gnu.org/ml/gcc/
>
>Bart Veer // eCos net maintainer
>
>
>
>幀件(zhufeng) wrote:
>
>  
>
>>when I build my mips program using gcc with -O0 , it is ok, while
>>    
>>
>using -o2, there come the following questions.
>  
>
>>lingking,,,
>>
>>relocation truncated to fit: R_MIPS_GPREL16  __global_ctor_start
>>relocation truncated to fit: R_MIPS_GPREL16 __global_ctor_end
>>relocation truncated to fit: R_MIPS_GPREL16 _recycle_start
>>
>>and so on.
>>
>>Has anybody encounter such questions?
>>
>>
>>
>>-----Original Message-----
>>From: wd@denx.de [mailto:wd@denx.de]
>>Sent: 2003綛????�� 23:08
>>To: ��狸揃誰
>>Cc: Wilson Chan; linux-mips@linux-mips.org
>>Subject: Re: gdbserver and gdb debugging stub for mips
>>
>>
>>In message <MGEELAPMEFMLFBMDBLKLIEKICEAA.zhufeng@koretide.com.cn> you
>>    
>>
>wrote:
>  
>
>>    
>>
>>>what do you mean by "MIPS is NOT MIPS"? Does it mean there are too many
>>>      
>>>
>mips boards?
>  
>
>>>      
>>>
>>big endian, little endian, 32 bit, 64 bit, ...
>>
>>It means that there are several  different  configurations,  and  you
>>must use tools to match your configuration.
>>
>>Best regards,
>>
>>Wolfgang Denk
>>
>>
>>
>>    
>>
>
>
>
>  
>


From hjl@lucon.org Thu Aug 21 17:04:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Aug 2003 17:04:41 +0100 (BST)
Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:44443 "EHLO
	rwcrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225362AbTHUQEj>; Thu, 21 Aug 2003 17:04:39 +0100
Received: from lucon.org ([12.234.88.5]) by comcast.net (rwcrmhc12) with ESMTP
          id <2003082115550601400d0h7ee>; Thu, 21 Aug 2003 15:55:06 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 14B402C4E3; Thu, 21 Aug 2003 08:55:05 -0700 (PDT)
Date: Thu, 21 Aug 2003 08:55:04 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: linux-gcc@vger.kernel.org, Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	"Steven J. Hill" <sjhill@realitydiluted.com>, gcc@gcc.gnu.org,
	GNU C Library <libc-alpha@sources.redhat.com>
Subject: The Linux binutils 2.14.90.0.6 is released
Message-ID: <20030821155504.GA16941@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <hjl@lucon.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3087
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hjl@lucon.org
Precedence: bulk
X-list: linux-mips

This is the beta release of binutils 2.14.90.0.6 for Linux, which is
based on binutils 2003 0820 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.

Please report any bugs related to binutils 2.14.90.0.6 to hjl@lucon.org.

If you don't use

# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.gz

to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches.

Changes from binutils 2.14.90.0.5:

1. Update from binutils 2003 0820.
2. No longer use section names for ELF section types nor flags.
3. Fix some ELF/IA64 linker bugs.
4. Fix some ELF/ppc bugs.
5. Add archive support to readelf.

Changes from binutils 2.14.90.0.4.1:

1. Update from binutils 2003 0722.
2. Fix an ELF/mips linker bug.
3. Fix an ELF/hpppa linker bug.
4. Fix an ELF/ia64 assembler bug.
5. Fix a linkonce support with C++ debug.
6. A new working C++ demangler.
7. Various alpha, mips, ia64, ... bug fixes.
8. Support for the current gcc and glibc.

Changes from binutils 2.14.90.0.4:
 
1. Fix an ia64 assembler hint@pause bug.
2. Support Intel Precott New Instructions.

Changes from binutils 2.14.90.0.3:

1. Work around the brain dead libtool.

Changes from binutils 2.14.90.0.2:

1. Update from binutils 2003 0523.
2. Fix 2 ELF visibility bugs.
3. Fix ELF/ppc linker bugs.

Changes from binutils 2.14.90.0.1:

1. Update from binutils 2003 0515.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Add more IAS compatibilities to ia64 assembler.

Changes from binutils 2.13.90.0.20:

1. Update from binutils 2003 0505.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Fix some ia64 assembler bugs.
5. Add some IAS compatibilities to ia64 assembler.
6. Fix ELF common symbol alignment.
7. Fix ELF weak symbol handling.

Changes from binutils 2.13.90.0.18:

1. Update from binutils 2003 0319.
2. Fix an ia64 linker brl relaxation bug.
3. Fix some ELF/ppc linker bugs.

Changes from binutils 2.13.90.0.16:

1. Update from binutils 2003 0121.
2. Fix an ia64 gas bug.
3. Fix some TLS bugs.
4. Fix some ELF/ppc bugs.
5. Fix an ELF/m68k bug.

2. Include /usr/bin/c++filt.
Changes from binutils 2.13.90.0.14:

1. Update from binutils 2002 1126.
2. Include /usr/bin/c++filt.
3. Fix "ld -r" with execption handling.

Changes from binutils 2.13.90.0.10:

1. Update from binutils 2002 1114.
2. Fix ELF/alpha bugs.
3. Fix an ELF/i386 assembler bug.

Changes from binutils 2.13.90.0.4:

1. Update from binutils 2002 1010.
2. More ELF/PPC linker bug fixes.
3. Fix an ELF/alpha linker bug.
4. Fix an ELF/sparc linker bug to support Solaris.
5. More TLS updates.

Changes from binutils 2.13.90.0.3:

1. Update from binutils 2002 0814.
2. Fix symbol versioning bugs for gcc 3.2.
3. Fix mips gas.

Changes from binutils 2.13.90.0.2:

1. Update from binutils 2002 0809.
2. Fix a mips gas compatibility bug.
3. Fix an x86 TLS bfd bug.
4. Fix an x86 PIC gas bug.
5. Improve symbol versioning support.

The file list:

1. binutils-2.14.90.0.6.tar.gz. Source code.
2. binutils-2.14.90.0.5-2.14.90.0.6.diff.gz. Patch against the
   previous beta source code.
3. binutils-2.14.90.0.6-1.i386.rpm. IA-32 binary RPM for RedHat 9.
4. binutils-2.14.90.0.6-1.ia64.rpm. IA-64 binary RPM for RedHat AS 2.1.

There is no separate source rpm. You can do

# rpmbuild -ta binutils-2.14.90.0.6.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

1. http://www.kernel.org/pub/linux/devel/binutils/

Thanks.


H.J. Lu
hjl@lucon.org
08/21/2003

From Yasushi.SHOJI@atmark-techno.com Sun Aug 24 00:23:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 24 Aug 2003 00:23:56 +0100 (BST)
Received: from dns1.atmark-techno.com ([IPv6:::ffff:61.199.192.114]:46095 "EHLO
	dns1.atmark-techno.com") by linux-mips.org with ESMTP
	id <S8225356AbTHWXXy>; Sun, 24 Aug 2003 00:23:54 +0100
Received: from wat.atmark-techno.com (unknown [192.168.10.81])
	by dns1.atmark-techno.com (Postfix) with ESMTP id 2B9AF3E614
	for <linux-mips@linux-mips.org>; Sun, 24 Aug 2003 08:23:26 +0900 (JST)
Date: Sun, 24 Aug 2003 08:23:26 +0900
From: Yasushi SHOJI <yashi@atmark-techno.com>
To: linux-mips@linux-mips.org
Subject: SD/MMC with db1100
User-Agent: User-Agent: Wanderlust/2.10.1
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20030823232326.2B9AF3E614@dns1.atmark-techno.com>
Return-Path: <Yasushi.SHOJI@atmark-techno.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3088
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yashi@atmark-techno.com
Precedence: bulk
X-list: linux-mips

Hello all,

I'm now tring SD subsystem on Au1100 with Syrah Rev 1.

Before porting handhelds.org's mmc driver, I just tried the attached
code, but it doesn't seems to work.

SD controler seems to emit right command to sd card, but there is no
response from sd card and timeouts.

Could someone enlighten me what's wrong with my code? or does anyone
successfully used sd/mmc on au1?

tia,
--
         yashi (leaving to Canada in a few hours...)



#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/delay.h>

#include <asm/au1000.h>

MODULE_LICENSE("GPL");

int sd_init(void)
{
        u32 cpupll, sd;

        au_writel(0xffffffff, 0xb0600018); /* clear all status */

        /* just checking */
        cpupll = au_readl(0xb1900060) & 0x3f;
        sd = (au_readl(0xb190003c) & 0x3) + 2;
        printk("CPU PLL %d => CPU freq %dMHz\n", cpupll, 12 * cpupll);
        printk("System Bus clock Div %d => System Bus %dMHz\n",
               sd, 12 * cpupll / sd);
        printk("Peripheral clock is %dkHz\n",
               (12 * 1000) * cpupll / sd / 2);

        /* SD Enable Register */
        au_writel(0x1, 0xb060000c);      /* periperal rest: R */
        au_writel(0x3, 0xb060000c);      /* periperal reset and clock enable: R | CE */

        mdelay(1);

        /* SD Config Register */
        au_writel(0x3ff, 0xb0600008);    /* set slowest clock */

        printk("SD Clock is %dHz\n", (12 * 1000 * 1000) * cpupll / sd / 2 / (2*((0x1ff)+1)));

        /* SD Config Register 2*/
        au_writel(0x2, 0xb0600010);      /* FF(Force FIFO flush and reset) */
        au_writel(0x0, 0xb0600010);      /* clear FF */
        au_writel(0x1, 0xb0600010);      /* Enable serial interface state machine */

        /* SD Timeout Register */
        au_writel(0x1fffff, 0xb0600038); /* max timeout */

        /* CMD0 */
        au_writel(0x0, 0xb0600024);
        au_writel(0x1, 0xb0600020);

        while (!(au_readl(0xb0600018) & 0x10000))
                ;

        printk("Status Register %#x\n", au_readl(0xb0600018));
        au_writel(0x10000, 0xb0600018);
        printk("Status Register %#x\n", au_readl(0xb0600018));

        /* CMD1 */
        au_writel(0x0, 0xb0600024);
        au_writel(0x30101, 0xb0600020);  /* R3 | CMD1 | CT 0 | GO */
//        au_writel(0x0, 0xb0600024); /* ocr */
//        au_writel(0x32901, 0xb0600020);  /* R3 | CMD1 | CT 0 | GO */

        while (!(au_readl(0xb0600018) & 0x10000) &&
               !(au_readl(0xb0600018) & 0x20000))
                ;

        printk("Status Register %#x\n", au_readl(0xb0600018));

        printk("Response Register 0 %#x\n", au_readl(0xb0600034));
        printk("Response Register 1 %#x\n", au_readl(0xb0600030));
        printk("Response Register 2 %#x\n", au_readl(0xb060002c));
        printk("Response Register 3 %#x\n", au_readl(0xb0600028));

        mdelay(100);
        printk("Status Register %#x\n", au_readl(0xb0600018));

        return -1; /* too lazy to rmmod */
}

void sd_cleanup(void)
{
}

module_init(sd_init);
module_exit(sd_cleanup);

From dan@embeddededge.com Mon Aug 25 02:00:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Aug 2003 02:00:39 +0100 (BST)
Received: from x1000-57.tellink.net ([IPv6:::ffff:63.161.110.249]:33519 "EHLO
	tibook.netx4.com") by linux-mips.org with ESMTP id <S8225376AbTHYBAh>;
	Mon, 25 Aug 2003 02:00:37 +0100
Received: from embeddededge.com (IDENT:dan@localhost.localdomain [127.0.0.1])
	by tibook.netx4.com (8.11.1/8.11.1) with ESMTP id h7P11Ha00847;
	Sun, 24 Aug 2003 21:01:17 -0400
Message-ID: <3F495FDD.5070407@embeddededge.com>
Date: Sun, 24 Aug 2003 21:01:17 -0400
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yasushi SHOJI <yashi@atmark-techno.com>
CC: linux-mips@linux-mips.org
Subject: Re: SD/MMC with db1100
References: <20030823232326.2B9AF3E614@dns1.atmark-techno.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dan@embeddededge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3089
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@embeddededge.com
Precedence: bulk
X-list: linux-mips

Yasushi SHOJI wrote:

> Could someone enlighten me what's wrong with my code? or does anyone
> successfully used sd/mmc on au1?

There is a patch in Ralf's hands for the sd/mmc on this board.  If
it doesn't show up soon, we'll find a way to get it to you.


	-- Dan



From ppopov@mvista.com Mon Aug 25 17:16:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Aug 2003 17:16:46 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:51184 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225384AbTHYQQn>;
	Mon, 25 Aug 2003 17:16:43 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA30388;
	Mon, 25 Aug 2003 09:16:15 -0700
Subject: Re: SD/MMC with db1100
From: Pete Popov <ppopov@mvista.com>
To: Dan Malek <dan@embeddededge.com>
Cc: Yasushi SHOJI <yashi@atmark-techno.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <3F495FDD.5070407@embeddededge.com>
References: <20030823232326.2B9AF3E614@dns1.atmark-techno.com>
	 <3F495FDD.5070407@embeddededge.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1061828175.7493.1.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 25 Aug 2003 09:16:15 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3090
X-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 Sun, 2003-08-24 at 18:01, Dan Malek wrote:
> Yasushi SHOJI wrote:
> 
> > Could someone enlighten me what's wrong with my code? or does anyone
> > successfully used sd/mmc on au1?
> 
> There is a patch in Ralf's hands for the sd/mmc on this board.  If
> it doesn't show up soon, we'll find a way to get it to you.

It's been there for a little while now -- a couple of weeks or so I
think.

ftp.linux-mips.org:/pub/linux/mips/people/ppopov/au1x_mmc.patch


Pete


From ralf@linux-mips.org Mon Aug 25 18:18:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Aug 2003 18:18:35 +0100 (BST)
Received: from p508B61D6.dip.t-dialin.net ([IPv6:::ffff:80.139.97.214]:9367
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225389AbTHYRSc>; Mon, 25 Aug 2003 18:18:32 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h7PHIB8R016167
	for <linux-mips@linux-mips.org>; Mon, 25 Aug 2003 19:18:11 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h7PHI6AH016157
	for linux-mips@linux-mips.org; Mon, 25 Aug 2003 19:18:06 +0200
Date: Mon, 25 Aug 2003 19:18:05 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030825171805.GA15798@linux-mips.org>
References: <20030825170001Z8225388-1272+4466@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030825170001Z8225388-1272+4466@linux-mips.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3091
X-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, Aug 25, 2003 at 05:59:56PM +0100, kwalker@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	kwalker@ftp.linux-mips.org	03/08/25 17:59:56
> 
> Modified files:
> 	arch/mips/mm-64: init.c 
> 
> Log message:
> 	remove unnecessary HIGHMEM stuff from 64bit version

Stooop, highmem will soon be needed for 64-bit also to handle machines
that can't DMA to the entire memory.

  Ralf

From ralf@linux-mips.org Tue Aug 26 00:03:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 26 Aug 2003 00:03:21 +0100 (BST)
Received: from p508B61D6.dip.t-dialin.net ([IPv6:::ffff:80.139.97.214]:55228
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225395AbTHYXDT>; Tue, 26 Aug 2003 00:03:19 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h7PN2w8R009043
	for <linux-mips@linux-mips.org>; Tue, 26 Aug 2003 01:02:58 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h7PN2v40009042
	for linux-mips@linux-mips.org; Tue, 26 Aug 2003 01:02:57 +0200
Date: Tue, 26 Aug 2003 01:02:57 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: fadvise64
Message-ID: <20030825230257.GA8936@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3092
X-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

Seems like there was no real possibility of anybody using the new 2.5
syscall fadvise64 with it's screwed prototype so I'm simply going to
avoid adding any extra junk to the kernel and change fadvise64 to
make the real thing that is call sys_fadvise64_64.

If that is going to cause any potencial trouble for example with libc,
let me know ...

  Ralf

From jsun@junsun.net Tue Aug 26 01:18:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 26 Aug 2003 01:18:06 +0100 (BST)
Received: from 12-235-55-113.client.attbi.com ([IPv6:::ffff:12.235.55.113]:61345
	"EHLO gateway.junsun.net") by linux-mips.org with ESMTP
	id <S8225395AbTHZASE>; Tue, 26 Aug 2003 01:18:04 +0100
Received: from gateway.junsun.net (gateway [127.0.0.1])
	by gateway.junsun.net (8.12.8/8.12.8) with ESMTP id h7Q0K973007066;
	Mon, 25 Aug 2003 17:20:09 -0700
Received: (from jsun@localhost)
	by gateway.junsun.net (8.12.8/8.12.8/Submit) id h7Q0K7l2007064;
	Mon, 25 Aug 2003 17:20:07 -0700
Date: Mon, 25 Aug 2003 17:20:07 -0700
From: Jun Sun <jsun@junsun.net>
To: linux-mips@linux-mips.org
Subject: FW: Linux kernel job description
Message-ID: <20030826002007.GA6492@gateway.junsun.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <jsun@junsun.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3093
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@junsun.net
Precedence: bulk
X-list: linux-mips


Sorry for this occasional off-topic abuse of list, but I think many
poeople here might be interested.

Please send your inquiry/resume directly to danc@transquest.com.
I am just posting this for him.

I think the location is San Francisco, or somewhere in Silicon Valley.

Jun

----- Forwarded message from Daniel Crocker <danc@transquest.com> -----

Job Title: Linux Kernel Software Engineer (in a SAN/NAS environment)

Required:  Linux kernel knowledge and experience in filesystems, drivers,
and memory management.  The candidate should have knowledge of network
storage systems (SAN & NAS).  Experience with large scalable data center
management applications is desired.  Excellent C/C++ skills are required as
well as good written and verbal skills.  Ability to & desire to work in a
very strong, team-driven environment.

Role:  The position will be a very visible, senior hands-on member of a very
high-performance team that will extend the scope of virtual servers to
include additional architectures, optimization of server deployment, and
enhance the feature set to improve process/state management & reporting,
expand the capabilities of the software deployment paradigm, and further
abstract the details of management tasks from the workflow design.



----- End forwarded message -----

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

Some SysV IPC using old-style (without IPC_64 flag) does not work on
mips64 kernel.

I think SysV IPC conversion routine should set/clear IPC_64 flag when
calling native system-call routine if the conversion routine pass
their own data structures.

* should set IPC_64 for semid64_ds, msqid64_ds, shmid64_ds.
* should clear IPC_64 for shmid_ds.

Here is a patch against 2.4 tree.  This can be applied for 2.6 also.

diff -u linux-mips-cvs/arch/mips64/kernel/linux32.c linux/arch/mips64/kernel/linux32.c
--- linux-mips-cvs/arch/mips64/kernel/linux32.c	Tue Aug 26 20:49:10 2003
+++ linux/arch/mips64/kernel/linux32.c	Tue Aug 26 20:49:43 2003
@@ -1802,7 +1802,7 @@
 		fourth.__pad = &s;
 		old_fs = get_fs ();
 		set_fs (KERNEL_DS);
-		err = sys_semctl (first, second, third, fourth);
+		err = sys_semctl (first, second, third | IPC_64, fourth);
 		set_fs (old_fs);
 
 		if (third & IPC_64) {
@@ -1967,7 +1967,7 @@
 			break;
 		old_fs = get_fs ();
 		set_fs (KERNEL_DS);
-		err = sys_msgctl (first, second, (struct msqid_ds *)&m);
+		err = sys_msgctl (first, second | IPC_64, (struct msqid_ds *)&m);
 		set_fs (old_fs);
 		break;
 
@@ -1975,7 +1975,7 @@
 	case MSG_STAT:
 		old_fs = get_fs ();
 		set_fs (KERNEL_DS);
-		err = sys_msgctl (first, second, (struct msqid_ds *)&m);
+		err = sys_msgctl (first, second | IPC_64, (struct msqid_ds *)&m);
 		set_fs (old_fs);
 		if (second & IPC_64) {
 			if (!access_ok(VERIFY_WRITE, up64, sizeof(*up64))) {
@@ -2084,7 +2084,7 @@
 			break;
 		old_fs = get_fs ();
 		set_fs (KERNEL_DS);
-		err = sys_shmctl (first, second, &s);
+		err = sys_shmctl (first, second & ~IPC_64, &s);
 		set_fs (old_fs);
 		break;
 
@@ -2092,7 +2092,7 @@
 	case SHM_STAT:
 		old_fs = get_fs ();
 		set_fs (KERNEL_DS);
-		err = sys_shmctl (first, second, (void *) &s64);
+		err = sys_shmctl (first, second | IPC_64, (void *) &s64);
 		set_fs (old_fs);
 		if (err < 0)
 			break;
---
Atsushi Nemoto

From AdeelM@avaznet.com Wed Aug 27 15:36:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 27 Aug 2003 15:36:53 +0100 (BST)
Received: from p508B5CCA.dip.t-dialin.net ([IPv6:::ffff:80.139.92.202]:42890
	"EHLO p508B5CCA.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225296AbTH0Ogv>; Wed, 27 Aug 2003 15:36:51 +0100
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:26859
	"EHLO 1aurora.enabtech") by linux-mips.net with ESMTP
	id <S869488AbTH0Ogv>; Wed, 27 Aug 2003 16:36:51 +0200
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <RGSFMMWS>; Wed, 27 Aug 2003 19:30:27 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38262718E@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Subject: Information required
Date: Wed, 27 Aug 2003 19:30:26 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C36CA7.C23115D0"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3095
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

This 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_01C36CA7.C23115D0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
           I am involved in Embedded Linux Development for MIPS Processor. I
need to write a device driver for a MIPS Target Platform. When I insmod the
driver.o file, the linux bash script running on the target hardware gives me
the error message like ;
1. unable to resolve the printk function
2. unable to resolve the register_chardev function
etc.
Can you plz give me the direction as to how to proceed to tackle this
situation.
Regards,
 
ADEEL MALIK,
Design Engineer

------_=_NextPart_001_01C36CA7.C23115D0
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">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV>
<DIV>
<DIV><SPAN class=953500914-27082003><FONT size=2>H<SPAN 
class=697422714-27082003>i All</SPAN>,</FONT></SPAN></DIV>
<DIV><SPAN class=953500914-27082003><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN 
class=697422714-27082003>I am involved in Embedded Linux Development for MIPS 
Processor. </SPAN>I need to write a device driver for a MIPS Target Platform. 
When I insmod the driver.o file, the&nbsp;<SPAN class=451581314-27082003>linux 
</SPAN>bash script<SPAN class=451581314-27082003> running</SPAN><SPAN 
class=451581314-27082003>&nbsp;on the target hardware</SPAN>&nbsp;gives me the 
error message like ;</FONT></SPAN></DIV>
<DIV><SPAN class=953500914-27082003><FONT size=2>1. unable to resolve the printk 
function</FONT></SPAN></DIV>
<DIV><SPAN class=953500914-27082003><FONT size=2>2. unable to resolve the 
register_chardev function</FONT></SPAN></DIV>
<DIV><SPAN class=953500914-27082003><FONT size=2>etc.</FONT></SPAN></DIV>
<DIV><SPAN class=953500914-27082003><FONT size=2>Can you plz give me the 
direction as to how to proceed to tackle this situation.</FONT></SPAN></DIV>
<DIV><SPAN class=953500914-27082003><FONT size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=953500914-27082003><FONT 
size=2></FONT></SPAN>&nbsp;</DIV></DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM>ADEEL MALIK,</EM></FONT></DIV>
<DIV><SPAN class=451581314-27082003><FONT face=Georgia color=#0000ff 
size=2><EM>Design Engineer</EM></FONT></SPAN></DIV></DIV></BODY></HTML>

------_=_NextPart_001_01C36CA7.C23115D0--

From jsun@mvista.com Wed Aug 27 17:51:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 27 Aug 2003 17:51:59 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:37618 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225296AbTH0Qv4>;
	Wed, 27 Aug 2003 17:51:56 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h7RGpRY08844;
	Wed, 27 Aug 2003 09:51:27 -0700
Date: Wed, 27 Aug 2003 09:51:27 -0700
From: Jun Sun <jsun@mvista.com>
To: Adeel Malik <AdeelM@avaznet.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Information required
Message-ID: <20030827095127.D8701@mvista.com>
References: <10C6C1971DA00C4BB87AC0206E3CA38262718E@1aurora.enabtech>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <10C6C1971DA00C4BB87AC0206E3CA38262718E@1aurora.enabtech>; from AdeelM@avaznet.com on Wed, Aug 27, 2003 at 07:30:26PM +0500
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3096
X-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, Aug 27, 2003 at 07:30:26PM +0500, Adeel Malik wrote:
> Hi All,
>            I am involved in Embedded Linux Development for MIPS Processor. I
> need to write a device driver for a MIPS Target Platform. When I insmod the
> driver.o file, the linux bash script running on the target hardware gives me
> the error message like ;
> 1. unable to resolve the printk function
> 2. unable to resolve the register_chardev function
> etc.
> Can you plz give me the direction as to how to proceed to tackle this
> situation.

Make sure your kernel compiled with module option turned on.
Does it use module version (CONFIG_MODVERSIONS)?
If so, add -DMODVERSIONS -include $(KERNEL_PATH)/include/linux/modversions.h
to your CFLAGS.

Jun

From wesolows@foobazco.org Thu Aug 28 05:31:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Aug 2003 05:31:30 +0100 (BST)
Received: from janus.foobazco.org ([IPv6:::ffff:198.144.194.226]:45725 "EHLO
	mail.foobazco.org") by linux-mips.org with ESMTP
	id <S8225297AbTH1Eb2>; Thu, 28 Aug 2003 05:31:28 +0100
Received: from fallout.sjc.foobazco.org (fallout.sjc.foobazco.org [192.168.21.20])
	by mail.foobazco.org (Postfix) with ESMTP
	id 71394FA38; Wed, 27 Aug 2003 21:31:13 -0700 (PDT)
Received: by fallout.sjc.foobazco.org (Postfix, from userid 1014)
	id 18E5223; Wed, 27 Aug 2003 21:31:12 -0700 (PDT)
Date: Wed, 27 Aug 2003 21:31:12 -0700
From: Keith M Wesolowski <wesolows@foobazco.org>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: PATCH: avoid glibc conflict
Message-ID: <20030828043112.GA11094@foobazco.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <wesolows@foobazco.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3097
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wesolows@foobazco.org
Precedence: bulk
X-list: linux-mips

This is needed to avoid a conflict with glibc on bigendian platforms
when -O or higher is specified.  It's already in 2.6, and I'm not sure
why it hasn't been seen in 2.4.  The symptom is that this program will
not compile with -O2:

#include <asm/byteorder.h>
#include <netinet/in.h>
int main () { }

Here's the patch.

--- linux/include/linux/byteorder/generic.h.orig	2003-08-10 18:15:07.000000000 -0700
+++ linux/include/linux/byteorder/generic.h	2003-08-10 18:16:36.000000000 -0700
@@ -122,7 +122,7 @@
 #define be16_to_cpus __be16_to_cpus
 #endif
 
-
+#if defined(__KERNEL__)
 /*
  * Handle ntohl and suches. These have various compatibility
  * issues - like we want to give the prototype even though we
@@ -146,35 +146,26 @@
  * Do the prototypes. Somebody might want to take the
  * address or some such sick thing..
  */
-#if defined(__KERNEL__) || (defined (__GLIBC__) && __GLIBC__ >= 2)
 extern __u32			ntohl(__u32);
 extern __u32			htonl(__u32);
-#else
-extern unsigned long int	ntohl(unsigned long int);
-extern unsigned long int	htonl(unsigned long int);
-#endif
 extern unsigned short int	ntohs(unsigned short int);
 extern unsigned short int	htons(unsigned short int);
 
-
-#if defined(__GNUC__) && (__GNUC__ >= 2) && defined(__OPTIMIZE__) && !defined(__STRICT_ANSI__)
+#if defined(__GNUC__) && defined(__OPTIMIZE__)
 
 #define ___htonl(x) __cpu_to_be32(x)
 #define ___htons(x) __cpu_to_be16(x)
 #define ___ntohl(x) __be32_to_cpu(x)
 #define ___ntohs(x) __be16_to_cpu(x)
 
-#if defined(__KERNEL__) || (defined (__GLIBC__) && __GLIBC__ >= 2)
 #define htonl(x) ___htonl(x)
 #define ntohl(x) ___ntohl(x)
-#else
-#define htonl(x) ((unsigned long)___htonl(x))
-#define ntohl(x) ((unsigned long)___ntohl(x))
-#endif
 #define htons(x) ___htons(x)
 #define ntohs(x) ___ntohs(x)
 
 #endif /* OPTIMIZE */
 
+#endif /* KERNEL */
+
 
 #endif /* _LINUX_BYTEORDER_GENERIC_H */


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

From michael_pruznick@mvista.com Thu Aug 28 05:54:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Aug 2003 05:54:26 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:23546 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225297AbTH1EyY>;
	Thu, 28 Aug 2003 05:54:24 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id VAA16109
	for <linux-mips@linux-mips.org>; Wed, 27 Aug 2003 21:54:12 -0700
Message-ID: <3F4D8AF3.D9BF7D51@mvista.com>
Date: Wed, 27 Aug 2003 22:54:11 -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: linux-mips@linux-mips.org
Subject: PATCH:2.4:2.6:compile fails with outw_p() in :?
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: 3098
X-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

Because mips uses #define with do..while(0) for outw_p (and
not inline like other arches) herems.h fails to compile.  ?:
requires and expr and do..while(0) is a statement.  Here are
the compile errors followed by my proposed patches for both
2.4 and 2.6.

build errors with CONFIG_HERMES=y
hermes.h: In function `hermes_set_irqmask':
hermes.h:337: parse error before "do"
hermes.h:337: parse error before ';' token
hermes.h: In function `hermes_write_words':

2.4
Index: drivers/net/wireless/hermes.h
===================================================================
RCS file: /home/cvs/linux/drivers/net/wireless/hermes.h,v
retrieving revision 1.6.2.4
diff -u -r1.6.2.4 hermes.h
--- drivers/net/wireless/hermes.h       13 Aug 2003 17:19:20 -0000      1.6.2.4
+++ drivers/net/wireless/hermes.h       27 Aug 2003 21:37:24 -0000
@@ -302,12 +302,14 @@
 #define hermes_read_reg(hw, off) ((hw)->io_space ? \
        inw((hw)->iobase + ( (off) << (hw)->reg_spacing )) : \
        readw((hw)->iobase + ( (off) << (hw)->reg_spacing )))
-#define hermes_write_reg(hw, off, val) ((hw)->io_space ? \
-       outw_p((val), (hw)->iobase + ( (off) << (hw)->reg_spacing )) : \
-       writew((val), (hw)->iobase + ( (off) << (hw)->reg_spacing )))
-
-#define hermes_read_regn(hw, name) (hermes_read_reg((hw), HERMES_##name))
-#define hermes_write_regn(hw, name, val) (hermes_write_reg((hw), HERMES_##name, (val)))
+#define hermes_write_reg(hw, off, val) do { \
+       if ( (hw)->io_space ) \
+               outw_p((val), (hw)->iobase + ( (off) << (hw)->reg_spacing )); \
+       else \
+               writew((val), (hw)->iobase + ( (off) << (hw)->reg_spacing )); \
+       } while (0)
+#define hermes_read_regn(hw, name) hermes_read_reg((hw), HERMES_##name)
+#define hermes_write_regn(hw, name, val) hermes_write_reg((hw), HERMES_##name, (val))
 
 /* Function prototypes */
 void hermes_struct_init(hermes_t *hw, ulong address, int io_space, int reg_spacing);


2.6
Index: drivers/net/wireless/hermes.h
===================================================================
RCS file: /home/cvs/linux/drivers/net/wireless/hermes.h,v
retrieving revision 1.10
diff -u -r1.10 hermes.h
--- drivers/net/wireless/hermes.h       22 Jun 2003 23:09:54 -0000      1.10
+++ drivers/net/wireless/hermes.h       27 Aug 2003 21:46:20 -0000
@@ -302,12 +302,14 @@
 #define hermes_read_reg(hw, off) ((hw)->io_space ? \
        inw((hw)->iobase + ( (off) << (hw)->reg_spacing )) : \
        readw((hw)->iobase + ( (off) << (hw)->reg_spacing )))
-#define hermes_write_reg(hw, off, val) ((hw)->io_space ? \
-       outw_p((val), (hw)->iobase + ( (off) << (hw)->reg_spacing )) : \
-       writew((val), (hw)->iobase + ( (off) << (hw)->reg_spacing )))
-
-#define hermes_read_regn(hw, name) (hermes_read_reg((hw), HERMES_##name))
-#define hermes_write_regn(hw, name, val) (hermes_write_reg((hw), HERMES_##name, (val)))
+#define hermes_write_reg(hw, off, val) do { \
+       if ( (hw)->io_space ) \
+               outw_p((val), (hw)->iobase + ( (off) << (hw)->reg_spacing )); \
+       else \
+               writew((val), (hw)->iobase + ( (off) << (hw)->reg_spacing )); \
+       } while (0)
+#define hermes_read_regn(hw, name) hermes_read_reg((hw), HERMES_##name)
+#define hermes_write_regn(hw, name, val) hermes_write_reg((hw), HERMES_##name, (val))
 
 /* Function prototypes */
 void hermes_struct_init(hermes_t *hw, ulong address, int io_space, int reg_spacing);

From kevink@mips.com Thu Aug 28 09:04:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Aug 2003 09:05:30 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:64175 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225297AbTH1IE6>;
	Thu, 28 Aug 2003 09:04:58 +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 h7S83MEY001412;
	Thu, 28 Aug 2003 01:03:22 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA04101;
	Thu, 28 Aug 2003 01:04:46 -0700 (PDT)
Message-ID: <023201c36d3b$5ea07d20$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Shalabh Agarwal" <sagarwal10@hotmail.com>,
	<linux-mips@linux-mips.org>, <java-linux@blackdown.org>
References: <Law14-F111iAwUI9NC100065ac2@hotmail.com>
Subject: Re: JVM & JIT for MIPs processors
Date: Thu, 28 Aug 2003 10:06: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: 3099
X-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

Kaffe is the only "free" Java for MIPS/Linux that I have worked with.
There may be others, but if you don't mind paying for it, your options
would include the Insignia Jeode technology is now owned by
Esmertec (www.esmertec.com), and Skelmir's CEE-J (www.skelmir.com).
I have run both of these successfully on MIPS/Linux platforms.

----- Original Message ----- 
From: "Shalabh Agarwal" <sagarwal10@hotmail.com>
To: <linux-mips@linux-mips.org>; <java-linux@blackdown.org>
Sent: Tuesday, August 19, 2003 3:25 AM
Subject: JVM & JIT for MIPs processors


> Hi
> 
> I was wondering if there are any JVM and JITs on Linux with support for the 
> extensive Java
> libraries and would run on MIPs machines?
> 
> Kaffe doesn't seem complete enough and Blackdown doesn't have a MIPs 
> download
> available.
> 
> It doesn't have to be free - we would be ready to license software. If 
> anyone knows
> of any companies that do this I'd appreciate the information.
> 
> thanks.
> 
> _________________________________________________________________
> <b>MSN 8:</b> Get 6 months for $9.95/month. 
> http://join.msn.com/?page=dept/dialup
> 
> 
> 

From AdeelM@avaznet.com Thu Aug 28 16:20:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Aug 2003 16:20:37 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:60289
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225314AbTH1PUf>; Thu, 28 Aug 2003 16:20:35 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <RGSFMMXF>; Thu, 28 Aug 2003 20:14:07 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA3826271C3@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: RE: Information required
Date: Thu, 28 Aug 2003 20:14:06 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C36D77.05BDE7E0"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3100
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

This 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_01C36D77.05BDE7E0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Jun,

Thanks for the reply.I have checked for the unresolved function symbols like
"printk" and "register_chrdev", and found that they are present in
/proc/ksyms. So it appears to me that I may be compiling the module with
incorrect parameters.

Below is the Makefile for the Loadable Module:

/***************************************************************************
**************************************/

CROSS_COMPILE=
/backup/buildroot-QuickMIPS/build/staging_dir/bin/mipsel-uclibc-

TARGET = example_driver

INCLUDE = /backup/buildroot-QuickMIPS/build/linux-2.4.20/include

CC = $(CROSS_COMPILE)gcc -I${INCLUDE}

CFLAGS = -DMODVERSIONS -I${INCLUDE}/linux/modversions.h

${TARGET}.o: ${TARGET}.c

.PHONY: clean

clean:

rm -rf ${TARGET}.o

/***************************************************************************
*************************************/

Do you think that I need to modify the makefile or add some more options to
CFLAGS.

I have ensured that the kernel is compiled with "module-option" turned on.

Also my module uses symbol versioning (sometimes called module versioning).

I use the following lines of code at the start of header file to accomplish
this:

/***************************************************************************
**********************************/

#if defined (CONFIG_MODVERSIONS) && ! defined (MODVERSIONS)

#include <linux/modversions.h>

#define MODVERSIONS

#endif

/***************************************************************************
**********************************/

I have successfully cross-compiled user-space applications on the target
platform. Only when i do the kernel work, this unresolved symbol (like
printk, register_chrdev, etc..) phenomenon happens.

ADEEL MALIK,

 

-----Original Message-----

From: linux-mips-bounce@linux-mips.org

[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun

Sent: Wednesday, August 27, 2003 9:51 PM

To: Adeel Malik

Cc: linux-mips@linux-mips.org; jsun@mvista.com

Subject: Re: Information required

 

On Wed, Aug 27, 2003 at 07:30:26PM +0500, Adeel Malik wrote:

> Hi All,

> I am involved in Embedded Linux Development for MIPS Processor. I

> need to write a device driver for a MIPS Target Platform. When I insmod
the

> driver.o file, the linux bash script running on the target hardware gives
me

> the error message like ;

> 1. unable to resolve the printk function

> 2. unable to resolve the register_chardev function

> etc.

> Can you plz give me the direction as to how to proceed to tackle this

> situation.

Make sure your kernel compiled with module option turned on.

Does it use module version (CONFIG_MODVERSIONS)?

If so, add -DMODVERSIONS -include $(KERNEL_PATH)/include/linux/modversions.h

to your CFLAGS.

Jun

 


------_=_NextPart_001_01C36D77.05BDE7E0
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">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><FONT size=2>
<P>Hello Jun,</P>
<P>Thanks for the reply.I have checked for the unresolved function symbols like 
"printk" and "register_chrdev", and found that they are present in /proc/ksyms. 
So it appears to me that I may be compiling the module with incorrect 
parameters.</P>
<P>Below is the Makefile for the Loadable Module:</P>
<P>/*****************************************************************************************************************/</P>
<P>CROSS_COMPILE= 
/backup/buildroot-QuickMIPS/build/staging_dir/bin/mipsel-uclibc-</P>
<P>TARGET = example_driver</P>
<P>INCLUDE = /backup/buildroot-QuickMIPS/build/linux-2.4.20/include</P>
<P>CC = $(CROSS_COMPILE)gcc -I${INCLUDE}</P>
<P>CFLAGS = -DMODVERSIONS -I${INCLUDE}/linux/modversions.h</P>
<P>${TARGET}.o: ${TARGET}.c</P>
<P>.PHONY: clean</P>
<P>clean:</P>
<P>rm -rf ${TARGET}.o</P>
<P>/****************************************************************************************************************/</P>
<P>Do you think that I need to modify the makefile or add some more options to 
CFLAGS.</P>
<P>I have ensured that the kernel is compiled with "module-option" turned 
on.</P>
<P>Also my module uses symbol versioning (sometimes called module 
versioning).</P>
<P>I use the following lines of code at the start of header file to accomplish 
this:</P>
<P>/*************************************************************************************************************/</P>
<P>#if defined (CONFIG_MODVERSIONS) &amp;&amp; ! defined (MODVERSIONS)</P>
<P>#include &lt;linux/modversions.h&gt;</P>
<P>#define MODVERSIONS</P>
<P>#endif</P>
<P>/*************************************************************************************************************/</P>
<P>I have successfully cross-compiled user-space applications on the target 
platform. Only when i do the kernel work, this unresolved symbol (like printk, 
register_chrdev, etc..) phenomenon happens.</P>
<P>ADEEL MALIK,</P>
<P>&nbsp;</P>
<P>-----Original Message-----</P>
<P>From: linux-mips-bounce@linux-mips.org</P>
<P>[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun</P>
<P>Sent: Wednesday, August 27, 2003 9:51 PM</P>
<P>To: Adeel Malik</P>
<P>Cc: linux-mips@linux-mips.org; jsun@mvista.com</P>
<P>Subject: Re: Information required</P>
<P>&nbsp;</P>
<P>On Wed, Aug 27, 2003 at 07:30:26PM +0500, Adeel Malik wrote:</P>
<P>&gt; Hi All,</P>
<P>&gt; I am involved in Embedded Linux Development for MIPS Processor. I</P>
<P>&gt; need to write a device driver for a MIPS Target Platform. When I insmod 
the</P>
<P>&gt; driver.o file, the linux bash script running on the target hardware 
gives me</P>
<P>&gt; the error message like ;</P>
<P>&gt; 1. unable to resolve the printk function</P>
<P>&gt; 2. unable to resolve the register_chardev function</P>
<P>&gt; etc.</P>
<P>&gt; Can you plz give me the direction as to how to proceed to tackle 
this</P>
<P>&gt; situation.</P>
<P>Make sure your kernel compiled with module option turned on.</P>
<P>Does it use module version (CONFIG_MODVERSIONS)?</P>
<P>If so, add -DMODVERSIONS -include 
$(KERNEL_PATH)/include/linux/modversions.h</P>
<P>to your CFLAGS.</P>
<P>Jun</P>
<P>&nbsp;</P></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C36D77.05BDE7E0--

From embedlf@citiz.net Fri Aug 29 10:28:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Aug 2003 10:28:31 +0100 (BST)
Received: from [IPv6:::ffff:218.1.66.83] ([IPv6:::ffff:218.1.66.83]:46986 "HELO
	mail.citiz.net") by linux-mips.org with SMTP id <S8225217AbTH2J23> convert rfc822-to-8bit;
	Fri, 29 Aug 2003 10:28:29 +0100
Received: (umta 26746 invoked by uid 1820); 29 Aug 2003 09:28:02 -0000
X-Lasthop: 202.120.8.28
Received: from unknown (HELO hdtv) (unknown@202.120.8.28)
  by localhost with SMTP; 29 Aug 2003 09:28:02 -0000
From: "embedlf" <embedlf@citiz.net>
To: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: how I mount the root fs from ramdisk??
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Fri, 29 Aug 2003 17:35:5 +0800
Message-Id: <20030829092829Z8225217-1272+4649@linux-mips.org>
Return-Path: <embedlf@citiz.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: 3101
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: embedlf@citiz.net
Precedence: bulk
X-list: linux-mips

linux-mips:
	I use mips cpu board to design my product. I want run linux embeded in this board.
But in this process,there is not harddisk on the board.
	So I should mount the root fs on ramdisk. Do you think so? I should make a ramdisk.

dd if=/dev/zero of=/dev/ram bs=1k count=2048
mke2fs -vm0 /dev/ram 2048
mount -t ext2 /dev/ram /mnt/ram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After I mount it, I should copy some files to this folder.I used cross_compiler,
compiling linux on X86 PC.How do I make the file /sbin/init??where is the source??

dd if=/dev/ram bs=1k count=2048 | gzip -v9 > /tmp/ram_image.gz

	

　　　　　　　　embedlf
　　　　　　　　embedlf@citiz.net
　　　　　　　　　　2003-08-29



From jeff_lee@coventive.com Fri Aug 29 11:39:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Aug 2003 11:39:38 +0100 (BST)
Received: from 202-145-53-89.adsl.ttn.net ([IPv6:::ffff:202.145.53.89]:5509
	"EHLO miao.coventive.com") by linux-mips.org with ESMTP
	id <S8225309AbTH2Kjg>; Fri, 29 Aug 2003 11:39:36 +0100
Received: from jefflee (PC193.ia.kh.coventive.com [192.168.23.193] (may be forged))
	by miao.coventive.com (8.11.6/8.11.6) with SMTP id h7TAXmj00611;
	Fri, 29 Aug 2003 18:33:49 +0800
From: "jeff" <jeff_lee@coventive.com>
To: "embedlf" <embedlf@citiz.net>, <linux-mips@linux-mips.org>
Subject: RE: how I mount the root fs from ramdisk??
Date: Fri, 29 Aug 2003 18:39:39 +0800
Message-ID: <LPECIADMAHLPOFOIEEFNKEFODCAA.jeff_lee@coventive.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="GB2312"
Content-Transfer-Encoding: base64
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <20030829092829Z8225217-1272+4649@linux-mips.org>
Return-Path: <jeff_lee@coventive.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3102
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jeff_lee@coventive.com
Precedence: bulk
X-list: linux-mips

UGxlYXNlIGRvd25sb2FkIHRoZSBidXN5Ym94IGFuZCBtYWtlIGl0IHRvIGJlIG1pcHMgYmluYXJ5
Lg0KT3IgeW91IGNhbiBmaW5kIHNvbWUgdXNhYmxlIGluZm9ybWF0aW9uIGZyb20gaHR0cDovL2xp
bnV4Lmp1bnN1bi5uZXQNCg0KUmVnYXJkcywNCg0KSmVmZg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KRnJvbTogbGludXgtbWlwcy1ib3VuY2VAbGludXgtbWlwcy5vcmcgW21haWx0bzps
aW51eC1taXBzLWJvdW5jZUBsaW51eC1taXBzLm9yZ11PbiBCZWhhbGYgT2YgZW1iZWRsZg0KU2Vu
dDogRnJpZGF5LCBBdWd1c3QgMjksIDIwMDMgNTowMCBQTQ0KVG86IGxpbnV4LW1pcHNAbGludXgt
bWlwcy5vcmcNClN1YmplY3Q6IGhvdyBJIG1vdW50IHRoZSByb290IGZzIGZyb20gcmFtZGlzaz8/
DQoNCg0KbGludXgtbWlwczoNCglJIHVzZSBtaXBzIGNwdSBib2FyZCB0byBkZXNpZ24gbXkgcHJv
ZHVjdC4gSSB3YW50IHJ1biBsaW51eCBlbWJlZGVkIGluIHRoaXMgYm9hcmQuDQpCdXQgaW4gdGhp
cyBwcm9jZXNzLHRoZXJlIGlzIG5vdCBoYXJkZGlzayBvbiB0aGUgYm9hcmQuDQoJU28gSSBzaG91
bGQgbW91bnQgdGhlIHJvb3QgZnMgb24gcmFtZGlzay4gRG8geW91IHRoaW5rIHNvPyBJIHNob3Vs
ZCBtYWtlIGEgcmFtZGlzay4NCg0KZGQgaWY9L2Rldi96ZXJvIG9mPS9kZXYvcmFtIGJzPTFrIGNv
dW50PTIwNDgNCm1rZTJmcyAtdm0wIC9kZXYvcmFtIDIwNDgNCm1vdW50IC10IGV4dDIgL2Rldi9y
YW0gL21udC9yYW0NCn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4NCkFmdGVyIEkgbW91
bnQgaXQsIEkgc2hvdWxkIGNvcHkgc29tZSBmaWxlcyB0byB0aGlzIGZvbGRlci5JIHVzZWQgY3Jv
c3NfY29tcGlsZXIsDQpjb21waWxpbmcgbGludXggb24gWDg2IFBDLkhvdyBkbyBJIG1ha2UgdGhl
IGZpbGUgL3NiaW4vaW5pdD8/d2hlcmUgaXMgdGhlIHNvdXJjZT8/DQoNCmRkIGlmPS9kZXYvcmFt
IGJzPTFrIGNvdW50PTIwNDggfCBnemlwIC12OSA+IC90bXAvcmFtX2ltYWdlLmd6DQoNCgkNCg0K
oaGhoaGhoaGhoaGhoaGhoWVtYmVkbGYNCqGhoaGhoaGhoaGhoaGhoaFlbWJlZGxmQGNpdGl6Lm5l
dA0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDAzLTA4LTI5DQoNCg==


From AdeelM@avaznet.com Fri Aug 29 12:28:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Aug 2003 12:28:11 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:19081
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225309AbTH2L2J>; Fri, 29 Aug 2003 12:28:09 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <RGSFMMX5>; Fri, 29 Aug 2003 16:21:41 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA382627203@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: Dan Aizenstros <daizenstros@quicklogic.com>
Cc: linux-mips@linux-mips.org
Subject: RE: RE: Information required
Date: Fri, 29 Aug 2003 16:21:40 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3103
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

Hi Dan,
       I have tried -mlong-calls option to the compiler, but is still gives
"unable to resolve printk" when I insmod the LKM.
When I 'cat' the /proc/ksyms, it shows printk_Rcxyz.... When I disable the
MODVERSIONING by using 'make menuconfig' during kernel configuration
process, and build the kernel again for MIPS platform, the proc/ksyms still
shows the printk_Rcxyz ... i.e, function name with a suffix.
Can you elaborate as to what are the steps needed to build the kernel with
MODVERSIONING disabled, etc.....

Regards,
Adeel

-----Original Message-----
From: Dan Aizenstros [mailto:daizenstros@quicklogic.com]
Sent: Thursday, August 28, 2003 8:43 PM
To: AdeelM@avaznet.com
Subject: Re: RE: Information required


Hello Adeel,

You need to pass -mlong-calls to the compiler.
You can add it the CFLAGS.

Regards,

Dan Aizenstros
Software Engineering Manager
QuickLogic Canada

>>> Adeel Malik <AdeelM@avaznet.com> 08/28/03 08:22 AM >>>
Hello Jun,

Thanks for the reply.I have checked for the unresolved function symbols like
"printk" and "register_chrdev", and found that they are present in
/proc/ksyms. So it appears to me that I may be compiling the module with
incorrect parameters.

Below is the Makefile for the Loadable Module:

/***************************************************************************
**************************************/

CROSS_COMPILE=
/backup/buildroot-QuickMIPS/build/staging_dir/bin/mipsel-uclibc-

TARGET = example_driver

INCLUDE = /backup/buildroot-QuickMIPS/build/linux-2.4.20/include

CC = $(CROSS_COMPILE)gcc -I${INCLUDE}

CFLAGS = -DMODVERSIONS -I${INCLUDE}/linux/modversions.h

${TARGET}.o: ${TARGET}.c

.PHONY: clean

clean:

rm -rf ${TARGET}.o

/***************************************************************************
*************************************/

Do you think that I need to modify the makefile or add some more options to
CFLAGS.

I have ensured that the kernel is compiled with "module-option" turned on.

Also my module uses symbol versioning (sometimes called module versioning).

I use the following lines of code at the start of header file to accomplish
this:

/***************************************************************************
**********************************/

#if defined (CONFIG_MODVERSIONS) && ! defined (MODVERSIONS)

#include <linux/modversions.h>

#define MODVERSIONS

#endif

/***************************************************************************
*********************************/

I have successfully cross-compiled user-space applications on the target
platform. Only when i do the kernel work, this unresolved symbol (like
printk, register_chrdev, etc..) phenomenon happens.

ADEEL MALIK,

 

-----Original Message-----

From: linux-mips-bounce@linux-mips.org

[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun

Sent: Wednesday, August 27, 2003 9:51 PM

To: Adeel Malik

Cc: linux-mips@linux-mips.org; jsun@mvista.com

Subject: Re: Information required

 

On Wed, Aug 27, 2003 at 07:30:26PM +0500, Adeel Malik wrote:

> Hi All,

> I am involved in Embedded Linux Development for MIPS Processor. I

> need to write a device driver for a MIPS Target Platform. When I insmod
the

> driver.o file, the linux bash script running on the target hardware gives
me

> the error message like ;

> 1. unable to resolve the printk function

> 2. unable to resolve the register_chardev function

> etc.

> Can you plz give me the direction as to how to proceed to tackle this

> situation.

Make sure your kernel compiled with module option turned on.

Does it use module version (CONFIG_MODVERSIONS)?

If so, add -DMODVERSIONS -include $(KERNEL_PATH)/include/linux/modversions.h

to your CFLAGS.

Jun

 



From AdeelM@avaznet.com Fri Aug 29 14:03:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Aug 2003 14:03:27 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:4761
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225353AbTH2NDZ>; Fri, 29 Aug 2003 14:03:25 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <RGSFMMYS>; Fri, 29 Aug 2003 17:57:25 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA382627222@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Subject: help
Date: Fri, 29 Aug 2003 17:57:22 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C36E2D.1794B150"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3104
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

This 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_01C36E2D.1794B150
Content-Type: text/plain;
	charset="iso-8859-1"

 

------_=_NextPart_001_01C36E2D.1794B150
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">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><FONT size=2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C36E2D.1794B150--

From AdeelM@avaznet.com Fri Aug 29 14:17:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Aug 2003 14:17:56 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:32922
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225353AbTH2NRy>; Fri, 29 Aug 2003 14:17:54 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <RGSFMMYT>; Fri, 29 Aug 2003 18:11:55 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA382627225@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Subject: How to get info about previous archives
Date: Fri, 29 Aug 2003 18:11:52 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C36E2F.1E62F610"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3105
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

This 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_01C36E2F.1E62F610
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
         Can someone tell me as to how to acquire info of all the previous
messages posted and answered on Linux-mips platform.
 
Regards,
ADEEL

------_=_NextPart_001_01C36E2F.1E62F610
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">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=291350913-29082003><FONT size=2>Hi All,</FONT></SPAN></DIV>
<DIV><SPAN class=291350913-29082003><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Can someone tell me as 
to how to acquire info of all the previous messages posted and answered on 
Linux-mips platform.</FONT></SPAN></DIV>
<DIV><SPAN class=291350913-29082003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=291350913-29082003><FONT size=2>Regards,</FONT></SPAN></DIV>
<DIV><FONT face=Georgia color=#0000ff 
size=2><EM>ADEEL</EM></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C36E2F.1E62F610--

From AdeelM@avaznet.com Fri Aug 29 15:04:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Aug 2003 15:04:27 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:420
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225363AbTH2OEZ>; Fri, 29 Aug 2003 15:04:25 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <RGSFMMYW>; Fri, 29 Aug 2003 18:58:23 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA382627228@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: Steffen Malmgaard Mortensen <smm@futarque.com>
Cc: linux-mips@linux-mips.org
Subject: RE: help
Date: Fri, 29 Aug 2003 18:58:20 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C36E35.9C702180"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3106
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

This 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_01C36E35.9C702180
Content-Type: text/plain


Hi Steffen,
               I couldn't understand your point. I want to disable module
versioning and for this I start make menuconfig in the linux folder. From
this I disable module versioning and then I launck make dep, make clean and
then make from the toplevel directory.
I havn't checked the top-level makefile. Can you tell me what fields need to
be added to CFLAGS to disable the MODVERSIONING.



Regards,
Adeel

 -----Original Message-----
From: Steffen Malmgaard Mortensen [mailto:smm@futarque.com]
Sent: Friday, August 29, 2003 6:21 PM
To: Adeel Malik
Subject: Re: help


Have you tried with the CFLAGS from the kernel makefile?? 
/Steffen

Adeel Malik wrote:


 



------_=_NextPart_001_01C36E35.9C702180
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE></TITLE>

<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<BLOCKQUOTE><FONT face=Tahoma>
  <DIV class=OutlookMessageHeader dir=ltr align=left><SPAN 
  class=460415113-29082003></SPAN><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2>H<SPAN class=460415113-29082003>i 
  Steffen,</SPAN></FONT></FONT></FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT><FONT 
  color=#0000ff><FONT size=2><SPAN 
  class=460415113-29082003></SPAN></FONT></FONT></FONT><SPAN 
  class=460415113-29082003></SPAN><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2>&nbsp;<SPAN 
  class=460415113-29082003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  I couldn't understand your point. I want to disable module versioning and for 
  this I start make menuconfig in the linux folder. From this I disable module 
  versioning and then I launck make dep,&nbsp;make clean and then make from the 
  toplevel directory.</SPAN></FONT></FONT></FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT><FONT 
  color=#0000ff><FONT size=2><SPAN 
  class=460415113-29082003></SPAN></FONT></FONT></FONT><SPAN 
  class=460415113-29082003></SPAN><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2>I<SPAN class=460415113-29082003> havn't checked the top-level makefile. 
  Can you tell me what fields need to be added to CFLAGS to disable the 
  MODVERSIONING.</SPAN></FONT></FONT></FONT></DIV><FONT face=Arial><FONT 
  color=#0000ff><FONT size=2><SPAN 
  class=460415113-29082003></SPAN></FONT></FONT></FONT></FONT></BLOCKQUOTE>
<BLOCKQUOTE><FONT face=Tahoma><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2><SPAN class=460415113-29082003></SPAN></FONT></FONT></FONT>
  <DIV class=OutlookMessageHeader dir=ltr align=left><SPAN 
  class=460415113-29082003></SPAN><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2>R<SPAN 
  class=460415113-29082003>egards,</SPAN></FONT></FONT></FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT><FONT 
  color=#0000ff><FONT size=2><SPAN 
  class=460415113-29082003></SPAN></FONT></FONT></FONT><SPAN 
  class=460415113-29082003></SPAN><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2>A<SPAN 
  class=460415113-29082003>deel</SPAN></FONT></FONT></FONT><BR></DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT size=2><SPAN 
  class=460415113-29082003>&nbsp;</SPAN>-----Original 
  Message-----<BR><B>From:</B> Steffen Malmgaard Mortensen 
  [mailto:smm@futarque.com]<BR><B>Sent:</B> Friday, August 29, 2003 6:21 
  PM<BR><B>To:</B> Adeel Malik<BR><B>Subject:</B> Re: 
  help<BR><BR></DIV></FONT></FONT>Have you tried with the CFLAGS from the kernel 
  makefile?? <BR>/Steffen<BR><BR>Adeel Malik wrote:<BR>
  <BLOCKQUOTE cite=mid10C6C1971DA00C4BB87AC0206E3CA382627222@1aurora.enabtech 
  type="cite">
    <META content="MSHTML 6.00.2600.0" name=GENERATOR>
    <DIV>&nbsp;</DIV></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C36E35.9C702180--

From earlm@mips.com Fri Aug 29 18:31:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Aug 2003 18:32:04 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:29894 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225352AbTH2Rbc>;
	Fri, 29 Aug 2003 18:31:32 +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 h7THTwEY016718;
	Fri, 29 Aug 2003 10:29:59 -0700 (PDT)
Received: from xchange.mips.com (xchange [192.168.20.31])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id KAA11286;
	Fri, 29 Aug 2003 10:31:37 -0700 (PDT)
Received: by xchange.mips.com with Internet Mail Service (5.5.2653.19)
	id <Q30X1PTV>; Fri, 29 Aug 2003 10:28:59 -0700
Message-ID: <0C5F4C7A1E3ED51194E200508B2CE32A02264CFC@xchange.mips.com>
From: "Mitchell, Earl" <earlm@mips.com>
To: "'Adeel Malik'" <AdeelM@avaznet.com>, linux-mips@linux-mips.org
Subject: RE: How to get info about previous archives
Date: Fri, 29 Aug 2003 10:28:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C36E53.05879B60"
Return-Path: <earlm@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3107
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlm@mips.com
Precedence: bulk
X-list: linux-mips

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_01C36E53.05879B60
Content-Type: text/plain;
	charset="iso-8859-1"

This page tells you where you can ftp
the mailing lists archive files from. 
 
http://www.linux-mips.org/mail.html <http://www.linux-mips.org/mail.html> 
 
-earlm
 
-----Original Message-----
From: Adeel Malik [mailto:AdeelM@avaznet.com] 
Sent: Friday, August 29, 2003 6:12 AM
To: linux-mips@linux-mips.org
Subject: How to get info about previous archives
 
Hi All,
         Can someone tell me as to how to acquire info of all the previous
messages posted and answered on Linux-mips platform.
 
Regards,
ADEEL

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C36E18.72197F90">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"date"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:Georgia;
	panose-1:2 4 5 2 5 4 5 2 3 3;
	mso-font-charset:0;
	mso-generic-font-family:roman;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>This page tells you where you can =
ftp<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>the mailing lists archive files =
from. <o:p></o:p></span></font></p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><a
href=3D"http://www.linux-mips.org/mail.html">http://www.linux-mips.org/m=
ail.html</a><o:p></o:p></span></font></p>

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


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


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


<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Adeel Malik
[mailto:AdeelM@avaznet.com<span class=3DGramE>] <br>
<b><span style=3D'font-weight:bold'>Sent</span></b></span><b><span
style=3D'font-weight:bold'>:</span></b> </span></font><st1:date =
Month=3D"8" Day=3D"29"
Year=3D"2003"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:
 Tahoma'>Friday, August 29, 2003</span></font></st1:date><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
</span></font><st1:time
Hour=3D"6" Minute=3D"12"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>6:12 AM</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
linux-mips@linux-mips.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> How to get info =
about
previous archives</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
Can someone tell me as to how to acquire info of all the previous =
messages
posted and answered on Linux-mips platform.</span></font><font =
color=3Dblack
face=3DArial><span =
style=3D'font-family:Arial;color:black'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3DArial><span =
style=3D'font-size:
12.0pt;font-family:Arial;color:black'>&nbsp;<o:p></o:p></span></font></p=
>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black'>Regards,</span></font><font =
color=3Dblack
face=3DArial><span =
style=3D'font-family:Arial;color:black'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><em><i><font size=3D2 color=3Dblue =
face=3DGeorgia><span
style=3D'font-size:10.0pt;font-family:Georgia;mso-bidi-font-family:Arial=
;
color:blue'>ADEEL</span></font></i></em><font color=3Dblack =
face=3DArial><span
style=3D'font-family:Arial;color:black'><o:p></o:p></span></font></p>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C36E53.05879B60--

From earlm@mips.com Fri Aug 29 21:27:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Aug 2003 21:27:58 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:54216 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225352AbTH2U10> convert rfc822-to-8bit;
	Fri, 29 Aug 2003 21:27:26 +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 h7TKPsEY018410;
	Fri, 29 Aug 2003 13:25:54 -0700 (PDT)
Received: from xchange.mips.com (xchange [192.168.20.31])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id NAA16346;
	Fri, 29 Aug 2003 13:27:27 -0700 (PDT)
Received: by xchange.mips.com with Internet Mail Service (5.5.2653.19)
	id <Q30X1Q2G>; Fri, 29 Aug 2003 13:24:48 -0700
Message-ID: <0C5F4C7A1E3ED51194E200508B2CE32A02264D07@xchange.mips.com>
From: "Mitchell, Earl" <earlm@mips.com>
To: "'jeff'" <jeff_lee@coventive.com>, embedlf <embedlf@citiz.net>,
	linux-mips@linux-mips.org
Subject: RE: how I mount the root fs from ramdisk??
Date: Fri, 29 Aug 2003 13:24:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="GB2312"
Content-Transfer-Encoding: 8BIT
Return-Path: <earlm@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3108
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlm@mips.com
Precedence: bulk
X-list: linux-mips

This page is better for ramdisk howto ...

http://www.linux-vr.org/ramdisk.html

-earlm

>-----Original Message-----
>From: jeff [mailto:jeff_lee@coventive.com]
>Sent: Friday, August 29, 2003 3:40 AM
>To: embedlf; linux-mips@linux-mips.org
>Subject: RE: how I mount the root fs from ramdisk??
>
>Please download the busybox and make it to be mips binary.
>Or you can find some usable information from http://linux.junsun.net
>
>Regards,
>
>Jeff
>
>-----Original Message-----
>From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-
>mips.org]On Behalf Of embedlf
>Sent: Friday, August 29, 2003 5:00 PM
>To: linux-mips@linux-mips.org
>Subject: how I mount the root fs from ramdisk??
>
>
>linux-mips:
>	I use mips cpu board to design my product. I want run linux embeded
>in this board.
>But in this process,there is not harddisk on the board.
>	So I should mount the root fs on ramdisk. Do you think so? I should
>make a ramdisk.
>
>dd if=/dev/zero of=/dev/ram bs=1k count=2048
>mke2fs -vm0 /dev/ram 2048
>mount -t ext2 /dev/ram /mnt/ram
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>After I mount it, I should copy some files to this folder.I used
>cross_compiler,
>compiling linux on X86 PC.How do I make the file /sbin/init??where is the
>source??
>
>dd if=/dev/ram bs=1k count=2048 | gzip -v9 > /tmp/ram_image.gz
>
>
>
>　　　　　　　　embedlf
>　　　　　　　　embedlf@citiz.net
>　　　　　　　　　　2003-08-29


From madsen@tadpole.com Fri Aug 29 23:00:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Aug 2003 23:00:44 +0100 (BST)
Received: from mail.cyclecc.com ([IPv6:::ffff:66.106.186.120]:33767 "EHLO
	recycle.cyclecc.com") by linux-mips.org with ESMTP
	id <S8225352AbTH2WAM>; Fri, 29 Aug 2003 23:00:12 +0100
Received: from mail.cyclecc.com (recycle [66.106.186.120])
	by recycle.cyclecc.com (8.12.2+Sun/8.12.2) with SMTP id h7TM2LpR023458
	for <linux-mips@linux-mips.org>; Fri, 29 Aug 2003 15:02:21 -0700 (PDT)
Received: from tadpole.com ([66.106.186.2])
 by mail.cyclecc.com (SAVSMTP 3.1.1.32) with SMTP id M2003082915022026519
 for <linux-mips@linux-mips.org>; Fri, 29 Aug 2003 15:02:20 -0700
Message-ID: <3F4FCCD5.1000604@tadpole.com>
Date: Fri, 29 Aug 2003 14:59:49 -0700
From: Steve Madsen <madsen@tadpole.com>
Organization: Tadpole Computer, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Using more than 256 MB of memory on SB1250 in 32-bit mode
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <madsen@tadpole.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3109
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: madsen@tadpole.com
Precedence: bulk
X-list: linux-mips

Is it possible to use more than 256 MB of system memory with the Broadcom 
SB1250 in 32-bit mode?  The memory map I'm looking at shows me that the 
second 256 MB of memory is at physical address 0x80000000.  I suspect that 
due to the 2G/2G split in the kernel, I can't use memory this high without 
moving to the 64-bit kernel.

Would someone confirm this for me?

-- 
Steve Madsen <madsen@tadpole.com>
Tadpole Computer, Inc.  http://www.tadpole.com


From Steve.Finney@SpirentCom.COM Sat Aug 30 03:41:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 30 Aug 2003 03:41:03 +0100 (BST)
Received: from Iris.Adtech-Inc.COM ([IPv6:::ffff:63.165.80.18]:6684 "EHLO
	iris.Adtech-Inc.COM") by linux-mips.org with ESMTP
	id <S8225377AbTH3ClB> convert rfc822-to-8bit; Sat, 30 Aug 2003 03:41:01 +0100
content-class: urn:content-classes:message
Subject: RE: Using more than 256 MB of memory on SB1250 in 32-bit mode
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Date: Fri, 29 Aug 2003 16:40:58 -1000
Message-ID: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB73D@iris.adtech-inc.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Using more than 256 MB of memory on SB1250 in 32-bit mode
Thread-Index: AcNueSiTz/62aUoOQay7j1spfQAwsQAJaNnA
From: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
To: "Steve Madsen" <madsen@tadpole.com>, <linux-mips@linux-mips.org>
Return-Path: <Steve.Finney@SpirentCom.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3110
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Steve.Finney@SpirentCom.COM
Precedence: bulk
X-list: linux-mips

Not sure what you mean by "system memory". You can turn on CONFIG_HIGHMEM and get access to 512 MB physical memory  or more on the BCM with a 32-bit kernel, but you can't access memory above the low 256 MB  directly through KSEG0/1, so there are some things that the kernel can't use it for (though it can be allocated to user processes). Also, since CONFIG_DISCONTIGMEM isn't supported, you end up wasting a bunch of RAM on useless page table space (36MB for 512 MB physical), and there's also some caching weirdness if you try and mmap() /dev/mem to get user access to the >0x10000000 I/O registers. Also, your startup will report "1792 MB HIGHMEM available".

sf

> -----Original Message-----
> From: Steve Madsen [mailto:madsen@tadpole.com]
> Sent: Friday, August 29, 2003 12:00 PM
> To: linux-mips@linux-mips.org
> Subject: Using more than 256 MB of memory on SB1250 in 32-bit mode
> 
> 
> Is it possible to use more than 256 MB of system memory with 
> the Broadcom 
> SB1250 in 32-bit mode?  The memory map I'm looking at shows 
> me that the 
> second 256 MB of memory is at physical address 0x80000000.  I 
> suspect that 
> due to the 2G/2G split in the kernel, I can't use memory this 
> high without 
> moving to the 64-bit kernel.
> 
> Would someone confirm this for me?
> 
> -- 
> Steve Madsen <madsen@tadpole.com>
> Tadpole Computer, Inc.  http://www.tadpole.com
> 
> 

From AdeelM@avaznet.com Sat Aug 30 12:40:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 30 Aug 2003 12:41:00 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:44979
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225346AbTH3Lk5>; Sat, 30 Aug 2003 12:40:57 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <RGSFMMYX>; Sat, 30 Aug 2003 16:34:48 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA382627229@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: Dan Aizenstros <daizenstros@quicklogic.com>
Cc: linux-mips@linux-mips.org
Subject: RE: RE: Information required
Date: Sat, 30 Aug 2003 16:34:40 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3111
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

Hi Dan,
       I have been able to resolve all the unresolved function symbols, by
properly configuring the MODVERSIONING in the module code. Only two symbols
are left:

1. unresolved symbol Atomic_add
2. unresolved symbol Atomic_sub

These symbols are not even in /proc/ksyms and System.map file of the
cross-compild linux-2.4 directory.

So can you guide me further,

Thanks in advance,

Adeel



-----Original Message-----
From: Dan Aizenstros [mailto:daizenstros@quicklogic.com]
Sent: Thursday, August 28, 2003 8:43 PM
To: AdeelM@avaznet.com
Subject: Re: RE: Information required


Hello Adeel,

You need to pass -mlong-calls to the compiler.
You can add it the CFLAGS.

Regards,

Dan Aizenstros
Software Engineering Manager
QuickLogic Canada

>>> Adeel Malik <AdeelM@avaznet.com> 08/28/03 08:22 AM >>>
Hello Jun,

Thanks for the reply.I have checked for the unresolved function symbols like
"printk" and "register_chrdev", and found that they are present in
/proc/ksyms. So it appears to me that I may be compiling the module with
incorrect parameters.

Below is the Makefile for the Loadable Module:

/***************************************************************************
**************************************/

CROSS_COMPILE=
/backup/buildroot-QuickMIPS/build/staging_dir/bin/mipsel-uclibc-

TARGET = example_driver

INCLUDE = /backup/buildroot-QuickMIPS/build/linux-2.4.20/include

CC = $(CROSS_COMPILE)gcc -I${INCLUDE}

CFLAGS = -DMODVERSIONS -I${INCLUDE}/linux/modversions.h

${TARGET}.o: ${TARGET}.c

.PHONY: clean

clean:

rm -rf ${TARGET}.o

/***************************************************************************
*************************************/

Do you think that I need to modify the makefile or add some more options to
CFLAGS.

I have ensured that the kernel is compiled with "module-option" turned on.

Also my module uses symbol versioning (sometimes called module versioning).

I use the following lines of code at the start of header file to accomplish
this:

/***************************************************************************
**********************************/

#if defined (CONFIG_MODVERSIONS) && ! defined (MODVERSIONS)

#include <linux/modversions.h>

#define MODVERSIONS

#endif

/***************************************************************************
*********************************/

I have successfully cross-compiled user-space applications on the target
platform. Only when i do the kernel work, this unresolved symbol (like
printk, register_chrdev, etc..) phenomenon happens.

ADEEL MALIK,

 

-----Original Message-----

From: linux-mips-bounce@linux-mips.org

[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun

Sent: Wednesday, August 27, 2003 9:51 PM

To: Adeel Malik

Cc: linux-mips@linux-mips.org; jsun@mvista.com

Subject: Re: Information required

 

On Wed, Aug 27, 2003 at 07:30:26PM +0500, Adeel Malik wrote:

> Hi All,

> I am involved in Embedded Linux Development for MIPS Processor. I

> need to write a device driver for a MIPS Target Platform. When I insmod
the

> driver.o file, the linux bash script running on the target hardware gives
me

> the error message like ;

> 1. unable to resolve the printk function

> 2. unable to resolve the register_chardev function

> etc.

> Can you plz give me the direction as to how to proceed to tackle this

> situation.

Make sure your kernel compiled with module option turned on.

Does it use module version (CONFIG_MODVERSIONS)?

If so, add -DMODVERSIONS -include $(KERNEL_PATH)/include/linux/modversions.h

to your CFLAGS.

Jun

 



From brad@ltc.com Sun Aug 31 13:05:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 31 Aug 2003 13:06:21 +0100 (BST)
Received: from avocet.mail.pas.earthlink.net ([IPv6:::ffff:207.217.120.50]:5330
	"EHLO avocet.mail.pas.earthlink.net") by linux-mips.org with ESMTP
	id <S8225205AbTHaMFs>; Sun, 31 Aug 2003 13:05:48 +0100
Received: from sdn-ap-010masprip0276.dialsprint.net ([63.186.161.22] helo=lahoo.priv)
	by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 19tQwU-0005AM-00; Sun, 31 Aug 2003 05:04:27 -0700
Received: from prefect.priv ([10.1.1.102] helo=prefect)
	by lahoo.priv with smtp (Exim 3.36 #1 (Debian))
	id 19tQvI-0002fK-00; Sun, 31 Aug 2003 08:03:12 -0400
Message-ID: <009901c36fb8$08190970$6601010a@prefect>
From: "Bradley D. LaRonde" <brad@ltc.com>
To: "Adeel Malik" <AdeelM@avaznet.com>
Cc: <linux-mips@linux-mips.org>
References: <10C6C1971DA00C4BB87AC0206E3CA382627229@1aurora.enabtech>
Subject: Re: RE: Information required
Date: Sun, 31 Aug 2003 08:04:29 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <brad@ltc.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3112
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brad@ltc.com
Precedence: bulk
X-list: linux-mips

----- Original Message ----- 
From: "Adeel Malik" <AdeelM@avaznet.com>
To: "Dan Aizenstros" <daizenstros@quicklogic.com>
Cc: <linux-mips@linux-mips.org>
Sent: Saturday, August 30, 2003 7:34 AM
Subject: RE: RE: Information required


>        I have been able to resolve all the unresolved function symbols, by
> properly configuring the MODVERSIONING in the module code. Only two
symbols
> are left:
>
> 1. unresolved symbol Atomic_add
> 2. unresolved symbol Atomic_sub
>
> These symbols are not even in /proc/ksyms and System.map file of the
> cross-compild linux-2.4 directory.

I don't think you'll find those in Linux.  Maybe your module relies on
another module.

Regards,
Brad


From ralf@linux-mips.org Sun Aug 31 14:34:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 31 Aug 2003 14:34:40 +0100 (BST)
Received: from p508B6685.dip.t-dialin.net ([IPv6:::ffff:80.139.102.133]:38838
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225348AbTHaNei>; Sun, 31 Aug 2003 14:34:38 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h7VDYa1p001916;
	Sun, 31 Aug 2003 15:34:37 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h7VDYZDG001915;
	Sun, 31 Aug 2003 15:34:35 +0200
Date: Sun, 31 Aug 2003 15:34:34 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Steve Madsen <madsen@tadpole.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode
Message-ID: <20030831133434.GA23189@linux-mips.org>
References: <3F4FCCD5.1000604@tadpole.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F4FCCD5.1000604@tadpole.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3113
X-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, Aug 29, 2003 at 02:59:49PM -0700, Steve Madsen wrote:

> Is it possible to use more than 256 MB of system memory with the Broadcom 
> SB1250 in 32-bit mode?  The memory map I'm looking at shows me that the 
> second 256 MB of memory is at physical address 0x80000000.  I suspect that 
> due to the 2G/2G split in the kernel, I can't use memory this high without 
> moving to the 64-bit kernel.

Steve Finney's answer was correct; I'd like to add a few details though.

The explanation you gave isn't exactly right.  A 2GB/2GB split would normally
support 2GB of low memory.  We don't on MIPS due to the very inconvenient and
unchangable mappings of KSEG0/KSEG1 - something that may have been sweet
in '85 when the address map was designed but not today when 32-bit address
spaces are beginning to be fairly tight.

Highmem works ok in 2.4 as long as you have a reasonably low ratio of
highmem to lowmem.  For typical loads that means going beyond 4:1 isn't
sensible but the actual number may vary much based on exact system
configuration or workload.

  Ralf

From ralf@linux-mips.org Sun Aug 31 15:58:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 31 Aug 2003 15:59:00 +0100 (BST)
Received: from p508B6685.dip.t-dialin.net ([IPv6:::ffff:80.139.102.133]:3260
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225354AbTHaO65>; Sun, 31 Aug 2003 15:58:57 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h7VEwu1p009996;
	Sun, 31 Aug 2003 16:58:56 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h7VEwt1N009995;
	Sun, 31 Aug 2003 16:58:55 +0200
Date: Sun, 31 Aug 2003 16:58:54 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Ulrich Drepper <drepper@redhat.com>,
	Glibc hackers <libc-hacker@sources.redhat.com>,
	linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH] Fix sigevent_t stuff
Message-ID: <20030831145854.GB23189@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3114
X-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

Uli,

below patch fixes a mismatch between glibc and the kernel header's
definition on MIPS.  Please apply.

Thanks,

  Ralf

2003-08-31  Ralf Baechle  <ralf@linux-mips.org>

	* sysdeps/unix/sysv/linux/mips/bits/siginfo.h: Delete comment
	obsoleted by this patch.
	(__SIGEV_PAD_SIZE: Change the definition such that it'll keep the size
	of sigevent_t at SIGEV_MAX_SIZE bytes for 64-bit also.
	(SIGEV_MAX_SIZE): Remove unused definition making this match the
	kernel definition.

Index: sysdeps/unix/sysv/linux/mips/bits/siginfo.h
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/mips/bits/siginfo.h,v
retrieving revision 1.10
diff -u -r1.10 siginfo.h
--- sysdeps/unix/sysv/linux/mips/bits/siginfo.h	22 May 2003 02:26:29 -0000	1.10
+++ sysdeps/unix/sysv/linux/mips/bits/siginfo.h	31 Aug 2003 14:31:00 -0000
@@ -255,12 +255,13 @@
 
 /* Structure to transport application-defined values with signals.  */
 # define __SIGEV_MAX_SIZE	64
-# define __SIGEV_PAD_SIZE	((__SIGEV_MAX_SIZE / sizeof (int)) - 3)
+# define __SIGEV_HEAD_SIZE	(sizeof(long) + 2*sizeof(int))
+# define __SIGEV_PAD_SIZE	\
+	((__SIGEV_MAX_SIZE-__SIGEV_HEAD_SIZE) / sizeof(int))
 
 /* Forward declaration of the `pthread_attr_t' type.  */
 struct __pthread_attr_s;
 
-/* XXX This one might need to change!!!  */
 typedef struct sigevent
   {
     sigval_t sigev_value;
@@ -290,8 +291,6 @@
 # define SIGEV_SIGNAL	SIGEV_SIGNAL
   SIGEV_NONE,			/* Other notification: meaningless.  */
 # define SIGEV_NONE	SIGEV_NONE
-  SIGEV_CALLBACK,		/* Deliver via thread creation.  */
-# define SIGEV_CALLBACK	SIGEV_CALLBACK
   SIGEV_THREAD			/* Deliver via thread creation.  */
 # define SIGEV_THREAD	SIGEV_THREAD
 };

From ralf@linux-mips.org Sun Aug 31 17:12:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 31 Aug 2003 17:12:21 +0100 (BST)
Received: from p508B6685.dip.t-dialin.net ([IPv6:::ffff:80.139.102.133]:45760
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225361AbTHaQMT>; Sun, 31 Aug 2003 17:12:19 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h7VGCH1p011509;
	Sun, 31 Aug 2003 18:12:17 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h7VGCHGA011508;
	Sun, 31 Aug 2003 18:12:17 +0200
Date: Sun, 31 Aug 2003 18:12:17 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Ulrich Drepper <drepper@redhat.com>,
	Glibc hackers <libc-hacker@sources.redhat.com>,
	linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: Re: [PATCH] Fix sigevent_t stuff
Message-ID: <20030831161217.GA10286@linux-mips.org>
References: <20030831145854.GB23189@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030831145854.GB23189@linux-mips.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3115
X-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, Aug 31, 2003 at 04:58:54PM +0200, Ralf Baechle wrote:

> below patch fixes a mismatch between glibc and the kernel header's
> definition on MIPS.  Please apply.

Please ignore this patch.  Digging through the history of the missmatch
I came to the conclusion that this fix isn't the right one; I'll send
an updated patch.

  Ralf

From agx@sigxcpu.org Sun Aug 31 17:48:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 31 Aug 2003 17:48:40 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:36283
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225361AbTHaQsH>; Sun, 31 Aug 2003 17:48:07 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 5AD8F2BC3C; Sun, 31 Aug 2003 18:48:05 +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 25499-09;
 Sun, 31 Aug 2003 18:48:03 +0200 (CEST)
Received: from bogon.sigxcpu.org (kons-d9bb5586.pool.mediaWays.net [217.187.85.134])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 561962BC39; Sun, 31 Aug 2003 18:48:03 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 1E0E34099; Sun, 31 Aug 2003 18:48:12 +0200 (CEST)
Date: Sun, 31 Aug 2003 18:48:12 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Ulrich Drepper <drepper@redhat.com>, linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix sigevent_t stuff
Message-ID: <20030831164812.GB766@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Ulrich Drepper <drepper@redhat.com>, linux-mips@linux-mips.org
References: <20030831145854.GB23189@linux-mips.org> <20030831161217.GA10286@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="yNb1oOkm5a9FJOVX"
Content-Disposition: inline
In-Reply-To: <20030831161217.GA10286@linux-mips.org>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20021227-p2 (Debian)
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3116
X-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


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

Hi Ralf,
On Sun, Aug 31, 2003 at 06:12:17PM +0200, Ralf Baechle wrote:
> On Sun, Aug 31, 2003 at 04:58:54PM +0200, Ralf Baechle wrote:
>=20
> > below patch fixes a mismatch between glibc and the kernel header's
> > definition on MIPS.  Please apply.
>=20
> Please ignore this patch.  Digging through the history of the missmatch
> I came to the conclusion that this fix isn't the right one; I'll send
> an updated patch.
Could you please post these patches to libc-alpha in the future?  Only
very few people will see patches on libc-hacker since subscription is
restricted.
Regards,
 -- Guido

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

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

iD8DBQE/UibLn88szT8+ZCYRAqcCAJ9DCwVXYRJSRWENR4Ipdq+z+SNlcgCfZNOY
ibkbAI6yhM32rn2U/kxiWgg=
=+A8f
-----END PGP SIGNATURE-----

--yNb1oOkm5a9FJOVX--