From geert@linux-m68k.org Thu Apr  1 09:31:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Apr 2004 09:31:25 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:57984 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225776AbUDAIbZ>;
	Thu, 1 Apr 2004 09:31:25 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i318VMdU026574;
	Thu, 1 Apr 2004 10:31:23 +0200 (MEST)
Date: Thu, 1 Apr 2004 10:31:22 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Brian Murphy <brian@murphy.dk>
cc: "Steven J. Hill" <sjhill@realitydiluted.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: BUG in pcnet32.c?
In-Reply-To: <406B2E90.5060307@murphy.dk>
Message-ID: <Pine.GSO.4.58.0404011030310.12755@waterleaf.sonytel.be>
References: <4068809F.8070103@murphy.dk> <4068864D.1020209@realitydiluted.com>
 <406B2E90.5060307@murphy.dk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4715
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 495
Lines: 16

On Wed, 31 Mar 2004, Brian Murphy wrote:
> Anyway the attached patch fixes my problems, is anyone interested in
> reviewing it?

I guess netdev@oss.sgi.com and tsbogend@alpha.franken.de are.

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 Thu Apr  1 18:31:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Apr 2004 18:31:59 +0100 (BST)
Received: from p508B578D.dip.t-dialin.net ([IPv6:::ffff:80.139.87.141]:29234
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225788AbUDARb6>; Thu, 1 Apr 2004 18:31:58 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i31HVuoM029524;
	Thu, 1 Apr 2004 19:31:56 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i31HVsWI029522;
	Thu, 1 Apr 2004 19:31:54 +0200
Date: Thu, 1 Apr 2004 19:31:54 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brian@murphy.dk>
Cc: "Steven J. Hill" <sjhill@realitydiluted.com>,
	linux-mips@linux-mips.org
Subject: Re: BUG in pcnet32.c?
Message-ID: <20040401173154.GA30634@linux-mips.org>
References: <4068809F.8070103@murphy.dk> <4068864D.1020209@realitydiluted.com> <406B2E90.5060307@murphy.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <406B2E90.5060307@murphy.dk>
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: 4717
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 455
Lines: 12

On Wed, Mar 31, 2004 at 10:48:16PM +0200, Brian Murphy wrote:

> Not sure what you mean. I get the panic "Break instruction in kernel 
> code" from do_bp
> in traps.c. This seems like a strange "assertion" to me...

The more information BUG or BUG_ON provide the bigger the kernel gets.
Using a simple break instruction was simply the smallest thing.  The
previous, just slightly more verbose BUG() implementation did result
in ~ 87k of bloat ...

  Ralf

From brian@murphy.dk Fri Apr  2 09:28:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Apr 2004 09:28:27 +0100 (BST)
Received: from [IPv6:::ffff:213.83.151.3] ([IPv6:::ffff:213.83.151.3]:35529
	"EHLO dk-ex01.thrane.tt.ad") by linux-mips.org with ESMTP
	id <S8225256AbUDBI20>; Fri, 2 Apr 2004 09:28:26 +0100
Received: from murphy.dk ([10.1.6.102]) by dk-ex01.thrane.tt.ad with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 2 Apr 2004 10:27:57 +0200
Message-ID: <406D240C.8020208@murphy.dk>
Date: Fri, 02 Apr 2004 10:27:56 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3
X-Accept-Language: en, en-ie
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Subject: Re: BUG in pcnet32.c?
References: <4068809F.8070103@murphy.dk> <4068864D.1020209@realitydiluted.com> <406B2E90.5060307@murphy.dk> <20040401173154.GA30634@linux-mips.org>
In-Reply-To: <20040401173154.GA30634@linux-mips.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Apr 2004 08:27:57.0051 (UTC) FILETIME=[66AFECB0:01C4188C]
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4718
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 589
Lines: 23

Ralf Baechle wrote:

>On Wed, Mar 31, 2004 at 10:48:16PM +0200, Brian Murphy wrote:
>
>  
>
>>Not sure what you mean. I get the panic "Break instruction in kernel 
>>code" from do_bp
>>in traps.c. This seems like a strange "assertion" to me...
>>    
>>
>
>The more information BUG or BUG_ON provide the bigger the kernel gets.
>Using a simple break instruction was simply the smallest thing.  The
>previous, just slightly more verbose BUG() implementation did result
>in ~ 87k of bloat ...
>  
>
Perhaps you could mention this usage of break explicitly in the message 
in do_bp.

/Brian


From ralf@linux-mips.org Fri Apr  2 09:39:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Apr 2004 09:39:04 +0100 (BST)
Received: from p508B7001.dip.t-dialin.net ([IPv6:::ffff:80.139.112.1]:3686
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225248AbUDBIjC>; Fri, 2 Apr 2004 09:39:02 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i328d1oM019720;
	Fri, 2 Apr 2004 10:39:01 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i328d0P0019719;
	Fri, 2 Apr 2004 10:39:00 +0200
Date: Fri, 2 Apr 2004 10:39:00 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brian@murphy.dk>
Cc: linux-mips@linux-mips.org
Subject: Re: BUG in pcnet32.c?
Message-ID: <20040402083900.GB19375@linux-mips.org>
References: <4068809F.8070103@murphy.dk> <4068864D.1020209@realitydiluted.com> <406B2E90.5060307@murphy.dk> <20040401173154.GA30634@linux-mips.org> <406D240C.8020208@murphy.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <406D240C.8020208@murphy.dk>
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: 4719
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 493
Lines: 15

On Fri, Apr 02, 2004 at 10:27:56AM +0200, Brian Murphy wrote:

> >The more information BUG or BUG_ON provide the bigger the kernel gets.
> >Using a simple break instruction was simply the smallest thing.  The
> >previous, just slightly more verbose BUG() implementation did result
> >in ~ 87k of bloat ...
> > 
> >
> Perhaps you could mention this usage of break explicitly in the message 
> in do_bp.

That's easy, BUG() and BUG_ON() if the condition was met use a break
instruction.

  Ralf

From raiko@niisi.msk.ru Fri Apr  2 10:44:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Apr 2004 10:44:12 +0100 (BST)
Received: from [IPv6:::ffff:193.232.173.111] ([IPv6:::ffff:193.232.173.111]:57700
	"EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP
	id <S8225254AbUDBJoL>; Fri, 2 Apr 2004 10:44:11 +0100
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.11.7/8.11.7) with ESMTP id i329irV27376
	for <linux-mips@linux-mips.org>; Fri, 2 Apr 2004 13:44:53 +0400
Received: from t06.niisi.ras.ru (localhost.localdomain [127.0.0.1])
	by t06.niisi.ras.ru (8.12.8/8.12.8) with ESMTP id i329fwFi004708
	for <linux-mips@linux-mips.org>; Fri, 2 Apr 2004 13:41:59 +0400
Received: (from uucp@localhost)
	by t06.niisi.ras.ru (8.12.8/8.12.8/Submit) with UUCP id i329fwor004706
	for linux-mips@linux-mips.org; Fri, 2 Apr 2004 13:41:58 +0400
Received: from niisi.msk.ru (aa01 [172.16.0.1])
	by aa19.niisi.msk.ru (8.12.8/8.12.8) with ESMTP id i329dxUY018426
	for <linux-mips@linux-mips.org>; Fri, 2 Apr 2004 13:39:59 +0400
Received: from niisi.msk.ru (t34 [193.232.173.34])
	by niisi.msk.ru (8.12.5/8.12.5) with ESMTP id i329dvuj018401
	for <linux-mips@linux-mips.org>; Fri, 2 Apr 2004 13:39:57 +0400 (MSK)
Message-ID: <406D3566.3FC6067C@niisi.msk.ru>
Date: Fri, 02 Apr 2004 13:41:58 +0400
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: strace on a linux/mips
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Return-Path: <raiko@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4720
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: raiko@niisi.msk.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 1022
Lines: 26

Hello,

Strace can't follow fork on a linux/mips (on all kernels, mips, mips64,
o32, n32, etc).

When fork occurs, strace changes syscall number from fork to clone in v0
and sets CLONE_PTRACE in a0.
Unfortunately, a kernel forms an address of a syscall routine before
strace performs its dirty tricks. Thus, only thing strace can do is
playing with syscall routine's address via t2. It's not so useful
because strace doesn't know where a syscall table is in. Strace is still
able to change first 4 arguments, though.

BTW, opening t2 to the ptrace(2) interface isn't good thing too. I am
not sure I can gain root by pondering t2, but I'm sure it's a hole for a
DoS attack, at least. (For lazy people, a kernel restores t2 from the
stack and does jalr t2 after the process being traced is resumed.)

The solution is to repeat parsing syscall number (and number of
arguments) on return from syscall_trace.
Another solution is to call syscall_trace early, before parsing.

Have somebody got yet another idea?

Regards,
Gleb.

From macro@ds2.pg.gda.pl Fri Apr  2 14:46:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Apr 2004 14:46:48 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:36748 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225532AbUDBNqi>; Fri, 2 Apr 2004 14:46:38 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 3D1E74787C; Fri,  2 Apr 2004 15:46:25 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 2ECCC47781; Fri,  2 Apr 2004 15:46:25 +0200 (CEST)
Date: Fri, 2 Apr 2004 15:46:25 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: [patch] Fragile constructs in c-sb1.c
Message-ID: <Pine.LNX.4.55.0404021534430.4735@jurand.ds.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: 4721
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 3523
Lines: 95

Hello,

 There's a bunch of ugly and fragile constructs defining assembler symbols
in c-sb1.c that depending on the configuration lead at least to an
unresolved reference to local_sb1___flush_cache_all upon a final link.  
Here's a fix that changes them to an equivalent implementation using a
documented gcc syntax.

 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.24-pre2-20040116-c-sb1-0
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/c-sb1.c linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/c-sb1.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/c-sb1.c	2004-01-15 03:57:03.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/c-sb1.c	2004-04-01 21:10:41.000000000 +0000
@@ -2,6 +2,7 @@
  * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com)
  * Copyright (C) 1997, 2001 Ralf Baechle (ralf@gnu.org)
  * Copyright (C) 2000, 2001, 2002, 2003 Broadcom Corporation
+ * Copyright (C) 2004  Maciej W. Rozycki
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -231,8 +232,8 @@ static void sb1_flush_cache_page(struct 
 	local_sb1_flush_cache_page(vma, addr);
 }
 #else
-void sb1_flush_cache_page(struct vm_area_struct *vma, unsigned long addr);
-asm("sb1_flush_cache_page = local_sb1_flush_cache_page");
+void sb1_flush_cache_page(struct vm_area_struct *vma, unsigned long addr)
+	__attribute__((alias("local_sb1_flush_cache_page")));
 #endif
 
 /*
@@ -280,8 +281,8 @@ static void local_sb1___flush_cache_all(
 }
 
 #ifdef CONFIG_SMP
-extern void sb1___flush_cache_all_ipi(void *ignored);
-asm("sb1___flush_cache_all_ipi = local_sb1___flush_cache_all");
+void sb1___flush_cache_all_ipi(void *ignored)
+	__attribute__((alias("local_sb1___flush_cache_all")));
 
 static void sb1___flush_cache_all(void)
 {
@@ -289,8 +290,8 @@ static void sb1___flush_cache_all(void)
 	local_sb1___flush_cache_all();
 }
 #else
-extern void sb1___flush_cache_all(void);
-asm("sb1___flush_cache_all = local_sb1___flush_cache_all");
+void sb1___flush_cache_all(void)
+	__attribute__((alias("local_sb1___flush_cache_all")));
 #endif
 
 /*
@@ -340,8 +341,8 @@ void sb1_flush_icache_range(unsigned lon
 	local_sb1_flush_icache_range(start, end);
 }
 #else
-void sb1_flush_icache_range(unsigned long start, unsigned long end);
-asm("sb1_flush_icache_range = local_sb1_flush_icache_range");
+void sb1_flush_icache_range(unsigned long start, unsigned long end)
+	__attribute__((alias("local_sb1_flush_icache_range")));
 #endif
 
 /*
@@ -398,8 +399,8 @@ static void sb1_flush_icache_page(struct
 	local_sb1_flush_icache_page(vma, page);
 }
 #else
-void sb1_flush_icache_page(struct vm_area_struct *vma, struct page *page);
-asm("sb1_flush_icache_page = local_sb1_flush_icache_page");
+void sb1_flush_icache_page(struct vm_area_struct *vma, struct page *page)
+	__attribute__((alias("local_sb1_flush_icache_page")));
 #endif
 
 /*
@@ -447,8 +448,8 @@ static void sb1_flush_cache_sigtramp(uns
 	smp_call_function(sb1_flush_cache_sigtramp_ipi, (void *) addr, 1, 1);
 }
 #else
-void sb1_flush_cache_sigtramp(unsigned long addr);
-asm("sb1_flush_cache_sigtramp = local_sb1_flush_cache_sigtramp");
+void sb1_flush_cache_sigtramp(unsigned long addr)
+	__attribute__((alias("local_sb1_flush_cache_sigtramp")));
 #endif
 
 

From sjhill@realitydiluted.com Fri Apr  2 15:36:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Apr 2004 15:36:38 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:29652 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225532AbUDBOgh>; Fri, 2 Apr 2004 15:36:37 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1B9Pm1-0001Ql-00; Fri, 02 Apr 2004 08:35:57 -0600
Message-ID: <406D7A1E.6080201@realitydiluted.com>
Date: Fri, 02 Apr 2004 09:35:10 -0500
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Debian/1.6-3
X-Accept-Language: en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Fragile constructs in c-sb1.c
References: <Pine.LNX.4.55.0404021534430.4735@jurand.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.55.0404021534430.4735@jurand.ds.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4722
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 469
Lines: 14

Maciej W. Rozycki wrote:
> 
>  There's a bunch of ugly and fragile constructs defining assembler symbols
> in c-sb1.c that depending on the configuration lead at least to an
> unresolved reference to local_sb1___flush_cache_all upon a final link.  
> Here's a fix that changes them to an equivalent implementation using a
> documented gcc syntax.
> 
>  OK to apply?
>
Heh, you beat me to it :). I had very similar problems with the same
function. Please apply.

-Steve

From macro@ds2.pg.gda.pl Fri Apr  2 15:56:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Apr 2004 15:56:09 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:4002 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225532AbUDBO4I>; Fri, 2 Apr 2004 15:56:08 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 21B1349C2F; Fri,  2 Apr 2004 16:56:02 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 018904787C; Fri,  2 Apr 2004 16:56:01 +0200 (CEST)
Date: Fri, 2 Apr 2004 16:56:01 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: [patch] SMP bootstrap for SB1250
Message-ID: <Pine.LNX.4.55.0404021633280.4735@jurand.ds.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: 4723
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 5199
Lines: 122

Hello,

 smp_boot_cpus() in arch/mips/sibyte/sb1250/smp.c does CPU enumeration in
an awkward way -- resulting in physical IDs different from what they
really are.  Additionally the code breaks for more than two processors
present -- subsequent CPUs get assigned numbers beyond NR_CPUS.  While
this may not bite for current SB1250 implementations, it need not
necessarily always be the case and the code seems to be intended to handle
such configurations.

 Here's a proposed fix.  It requires an API change for
prom_boot_secondary() to return a status, but I think it's desirable as it
lets the invoker know if the call failed for some reason.  Some code
elsewhere already defines the function this way. ;-)  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.25-20040322-swarm-smpboot-1
diff -up --recursive --new-file linux-mips-2.4.25-20040322.macro/arch/mips/sibyte/cfe/smp.c linux-mips-2.4.25-20040322/arch/mips/sibyte/cfe/smp.c
--- linux-mips-2.4.25-20040322.macro/arch/mips/sibyte/cfe/smp.c	2004-01-06 03:56:57.000000000 +0000
+++ linux-mips-2.4.25-20040322/arch/mips/sibyte/cfe/smp.c	2004-04-02 08:41:08.000000000 +0000
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2000, 2001, 2002, 2003 Broadcom Corporation
+ * Copyright (C) 2004  Maciej W. Rozycki
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -26,7 +27,7 @@
 
 /* Boot all other cpus in the system, initialize them, and
    bring them into the boot fn */
-void prom_boot_secondary(int cpu, unsigned long sp, unsigned long gp)
+int prom_boot_secondary(int cpu, unsigned long sp, unsigned long gp)
 {
 	int retval;
 	
@@ -34,6 +35,8 @@ void prom_boot_secondary(int cpu, unsign
 	if (retval != 0) {
 		printk("cfe_start_cpu(%i) returned %i\n" , cpu, retval);
 	}
+
+	return retval;
 }
 
 void prom_init_secondary(void)
diff -up --recursive --new-file linux-mips-2.4.25-20040322.macro/arch/mips/sibyte/sb1250/smp.c linux-mips-2.4.25-20040322/arch/mips/sibyte/sb1250/smp.c
--- linux-mips-2.4.25-20040322.macro/arch/mips/sibyte/sb1250/smp.c	2004-01-28 03:56:49.000000000 +0000
+++ linux-mips-2.4.25-20040322/arch/mips/sibyte/sb1250/smp.c	2004-04-02 14:27:08.000000000 +0000
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2001 Broadcom Corporation
+ * Copyright (C) 2004  Maciej W. Rozycki
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -138,7 +139,7 @@ void __init smp_boot_cpus(void)
 	 * This loop attempts to compensate for "holes" in the CPU
 	 * numbering.  It's overkill, but general.
 	 */
-	for (i = 1; i < smp_num_cpus; ) {
+	for (i = 1; i < smp_num_cpus && cur_cpu < NR_CPUS; i++) {
 		struct task_struct *p;
 		struct pt_regs regs;
 		printk("Starting CPU %d... ", i);
@@ -158,15 +159,20 @@ void __init smp_boot_cpus(void)
 		unhash_process(p);
 
 		do {
+			int status;
+
 			/* Iterate until we find a CPU that comes up */
 			cur_cpu++;
-			prom_boot_secondary(cur_cpu,
-					    (unsigned long)p + KERNEL_STACK_SIZE - 32,
-					    (unsigned long)p);
-		} while (cur_cpu < smp_num_cpus - 1);
-		__cpu_number_map[cur_cpu] = i;
-		__cpu_logical_map[i] = cur_cpu;
-		i++;
+			status = prom_boot_secondary(cur_cpu,
+						    (unsigned long)p +
+						    KERNEL_STACK_SIZE - 32,
+						    (unsigned long)p);
+			if (status == 0) {
+				__cpu_number_map[cur_cpu] = i;
+				__cpu_logical_map[i] = cur_cpu;
+				break;
+			}
+		} while (cur_cpu < NR_CPUS);
 	}
 
 	/* Wait for everyone to come up */
diff -up --recursive --new-file linux-mips-2.4.25-20040322.macro/include/asm-mips/smp.h linux-mips-2.4.25-20040322/include/asm-mips/smp.h
--- linux-mips-2.4.25-20040322.macro/include/asm-mips/smp.h	2003-12-31 03:57:06.000000000 +0000
+++ linux-mips-2.4.25-20040322/include/asm-mips/smp.h	2004-04-02 14:27:08.000000000 +0000
@@ -106,7 +106,7 @@ void core_send_ipi(int cpu, unsigned int
  * Clear all undefined state in the cpu, set up sp and gp to the passed
  * values, and kick the cpu into smp_bootstrap();
  */
-void prom_boot_secondary(int cpu, unsigned long sp, unsigned long gp);
+int prom_boot_secondary(int cpu, unsigned long sp, unsigned long gp);
 
 /*
  *  After we've done initial boot, this function is called to allow the
diff -up --recursive --new-file linux-mips-2.4.25-20040322.macro/include/asm-mips64/smp.h linux-mips-2.4.25-20040322/include/asm-mips64/smp.h
--- linux-mips-2.4.25-20040322.macro/include/asm-mips64/smp.h	2003-12-31 03:57:06.000000000 +0000
+++ linux-mips-2.4.25-20040322/include/asm-mips64/smp.h	2004-04-02 14:27:08.000000000 +0000
@@ -106,7 +106,7 @@ void core_send_ipi(int cpu, unsigned int
  * Clear all undefined state in the cpu, set up sp and gp to the passed
  * values, and kick the cpu into smp_bootstrap();
  */
-void prom_boot_secondary(int cpu, unsigned long sp, unsigned long gp);
+int prom_boot_secondary(int cpu, unsigned long sp, unsigned long gp);
 
 /*
  *  After we've done initial boot, this function is called to allow the

From baitisj@evolution.com Fri Apr  2 18:07:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Apr 2004 18:07:09 +0100 (BST)
Received: from mx2.idealab.com ([IPv6:::ffff:64.208.8.4]:24848 "EHLO
	indiana.idealab.com") by linux-mips.org with ESMTP
	id <S8225539AbUDBRHJ>; Fri, 2 Apr 2004 18:07:09 +0100
Received: (qmail 86564 invoked by uid 72); 2 Apr 2004 17:06:58 -0000
Received: from baitisj@evolution.com by indiana.idealab.com by uid 70 with qmail-scanner-1.20rc1 
 (sweep: 2.14/3.73.  Clear:RC:1:. 
 Processed in 0.024167 secs); 02 Apr 2004 17:06:58 -0000
X-Qmail-Scanner-Mail-From: baitisj@evolution.com via indiana.idealab.com
X-Qmail-Scanner: 1.20rc1 (Clear:RC:1:. Processed in 0.024167 secs)
Received: from unknown (HELO powerpuff.evo1.pas.lab) (10.1.22.10)
  by 0 with SMTP; 2 Apr 2004 17:06:58 -0000
Subject: PATCH: drivers/sound/ite8172.c, versus kernel_2_4_24
From: Jeffrey Baitis <baitisj@evolution.com>
Reply-To: baitisj@evolution.com
To: linux-mips@linux-mips.org
Content-Type: text/plain
Organization: Evolution Robotics
Message-Id: <1080925619.25555.2.camel@powerpuff.evo1.pas.lab>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 02 Apr 2004 09:06:59 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <baitisj@evolution.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4724
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips
Content-Length: 530
Lines: 17

Here's a patch to make the ITE8172 sound driver compile on the
kernel_2_4_24 branch.

-- drivers/sound/ite8172.c     30 Mar 2004 01:38:00 -0000      1.1.1.1
+++ drivers/sound/ite8172.c     2 Apr 2004 17:02:01 -0000
@@ -2180,7 +2180,7 @@
        release_region(s->io, pci_resource_len(dev,0));
        unregister_sound_dsp(s->dev_audio);
        unregister_sound_mixer(s->codec->dev_mixer);
-       ac97_codec_release(s->codec);
+       ac97_release_codec(s->codec);
        kfree(s);
        pci_set_drvdata(dev, NULL);
}

-Jeff


From karsten@excalibur.cologne.de Sun Apr  4 12:52:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Apr 2004 12:52:11 +0100 (BST)
Received: from natsmtp00.rzone.de ([IPv6:::ffff:81.169.145.165]:16544 "EHLO
	natsmtp00.webmailer.de") by linux-mips.org with ESMTP
	id <S8225554AbUDDLwK>; Sun, 4 Apr 2004 12:52:10 +0100
Received: from excalibur.cologne.de (pD9E40B40.dip.t-dialin.net [217.228.11.64])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i34Bq5vZ016645;
	Sun, 4 Apr 2004 13:52:05 +0200 (MEST)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 1BA6Af-0007Vp-00; Sun, 04 Apr 2004 13:52:13 +0200
Date: Sun, 4 Apr 2004 13:52:12 +0200
From: Karsten Merker <karsten@excalibur.cologne.de>
To: debian-mips@lists.debian.org, linux-mips@linux-mips.org
Subject: Kernel vs. glibc problems
Message-ID: <20040404115212.GA22445@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	debian-mips@lists.debian.org, linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4725
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2384
Lines: 52

Hallo everybody,

I am experiencing problems with current kernels depending on which glibc
version I have installed and on which machine I run my tests.

On a DECstation 5000/150, having an R4000SC, everything works fine,
regardless which combination of kernel and glibc I use. Tested
combinations:
- Debian 2.4.19 plus Debian/Woody glibc (2.2.5)
- Debian 2.4.19 plus Debian/Sarge glibc (2.3.2)
- CVS 2.4.25 from 2004/03/25 plus Debian/Sarge glibc (2.3.2)

On a DECstation 5000/20, having an R3000, the following combinations work:
- Debian 2.4.19 plus Debian/Woody glibc (2.2.5)
- Debian 2.4.19 plus Debian/Sarge glibc (2.3.2)
- CVS 2.4.25 from 2004/03/25 plus Debian/Woody glibc (2.2.5)
But running the same CVS 2.4.25 with the Debian/Sarge glibc (2.3.2)
causes (at least) ls, sleep and tar to die with "illegal instruction".

Similar behavior regarding 2.4.25 plus Debian/Sid glibc (2.3.2) has
been reported for a DECstation 5000/133 (also R3k).

Besides, there has been a report on debian-mips in
<599FD8BDB7FBD511A4D10008C7CFB6DC06FB93DA@dfwex02.allegiancetelecom.com>
that similar behaviour also happened on a Cobalt box, which
has an R5k-compatible core. Quotation from that email:
"Last time I tried it, it broke tar, ls -l, gcc, and just about everything
else that called the gettimeofday() system call.", which fits
to my experiences on the R3k DECstations.

All this seems to point to some kernel-vs-glibc mismatch. The only
thing I could dig out in this regard was the change in struct msqid_ds
(see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200215), but
that does not explain why this happens on an R3k DECstation but
not on an R4k DECstation while it happens on an R5k Cobalt, 
and the change done there should not affect ls and sleep.
Strangely the CVS kernel works fine with the _old_ glibc on the
R3k DECstations, but not with the new one, even though it should
be the other way round as the CVS kernel AFAICS has the fixes
listes in the aforementioned bugreport. 
Some problem with instruction emulation (ll/sc) on R3k came to
my mind, but that does not explain the problems on the Cobalt.

Any ideas what could cause this behaviour?

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

From agx@sigxcpu.org Sun Apr  4 17:22:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Apr 2004 17:22:09 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:32431
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225789AbUDDQWI>; Sun, 4 Apr 2004 17:22:08 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id AB8FE2BC42; Sun,  4 Apr 2004 18:22:07 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
	by localhost (honk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 17695-06; Sun, 4 Apr 2004 18:22:02 +0200 (CEST)
Received: from bogon.sigxcpu.org (xdsl-213-196-194-203.netcologne.de [213.196.194.203])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id D79982BC48; Sun,  4 Apr 2004 18:21:39 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 0250B4092; Sun,  4 Apr 2004 17:50:10 +0200 (CEST)
Date: Sun, 4 Apr 2004 17:50:10 +0200
From: Guido Guenther <agx@debian.org>
To: debian-mips@lists.debian.org, linux-mips@linux-mips.org
Cc: Karsten Merker <karsten@excalibur.cologne.de>
Subject: Re: Kernel vs. glibc problems
Message-ID: <20040404155010.GA1975@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@debian.org>,
	debian-mips@lists.debian.org, linux-mips@linux-mips.org,
	Karsten Merker <karsten@excalibur.cologne.de>
References: <20040404115212.GA22445@excalibur.cologne.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN"
Content-Disposition: inline
In-Reply-To: <20040404115212.GA22445@excalibur.cologne.de>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at honk.physik.uni-konstanz.de
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: 4726
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 968
Lines: 30


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

On Sun, Apr 04, 2004 at 01:52:12PM +0200, Karsten Merker wrote:
> On a DECstation 5000/20, having an R3000, the following combinations work:
> - Debian 2.4.19 plus Debian/Woody glibc (2.2.5)
> - Debian 2.4.19 plus Debian/Sarge glibc (2.3.2)
> - CVS 2.4.25 from 2004/03/25 plus Debian/Woody glibc (2.2.5)
> But running the same CVS 2.4.25 with the Debian/Sarge glibc (2.3.2)
> causes (at least) ls, sleep and tar to die with "illegal instruction".
What is the illegal instruction? Gdb should tell.
Cheers,
 -- Guido

--J/dobhs11T7y2rNN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFAcC6yn88szT8+ZCYRAsWHAJwNBlVrPqOIq411ILBAJxax8ej+lwCdE/8i
GdFVRbK+wS6ZdNfgmhR6fac=
=riat
-----END PGP SIGNATURE-----

--J/dobhs11T7y2rNN--

From karsten@excalibur.cologne.de Sun Apr  4 18:35:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Apr 2004 18:35:07 +0100 (BST)
Received: from natsmtp00.rzone.de ([IPv6:::ffff:81.169.145.165]:32393 "EHLO
	natsmtp00.webmailer.de") by linux-mips.org with ESMTP
	id <S8225814AbUDDRfG>; Sun, 4 Apr 2004 18:35:06 +0100
Received: from excalibur.cologne.de (pD9E40B40.dip.t-dialin.net [217.228.11.64])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i34HZ1FT021254;
	Sun, 4 Apr 2004 19:35:01 +0200 (MEST)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 1BABWa-00085o-00; Sun, 04 Apr 2004 19:35:12 +0200
Date: Sun, 4 Apr 2004 19:35:12 +0200
From: Karsten Merker <karsten@excalibur.cologne.de>
To: debian-mips@lists.debian.org, linux-mips@linux-mips.org
Cc: ralf@gnu.org
Subject: Re: Kernel vs. glibc problems
Message-ID: <20040404173512.GA31039@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	debian-mips@lists.debian.org, linux-mips@linux-mips.org,
	ralf@gnu.org
References: <20040404115212.GA22445@excalibur.cologne.de> <20040404155010.GA1975@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040404155010.GA1975@bogon.ms20.nix>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4727
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips
Content-Length: 997
Lines: 22

On Sun, Apr 04, 2004 at 05:50:10PM +0200, Guido Guenther wrote:
> On Sun, Apr 04, 2004 at 01:52:12PM +0200, Karsten Merker wrote:
> > On a DECstation 5000/20, having an R3000, the following combinations work:
> > - Debian 2.4.19 plus Debian/Woody glibc (2.2.5)
> > - Debian 2.4.19 plus Debian/Sarge glibc (2.3.2)
> > - CVS 2.4.25 from 2004/03/25 plus Debian/Woody glibc (2.2.5)
> > But running the same CVS 2.4.25 with the Debian/Sarge glibc (2.3.2)
> > causes (at least) ls, sleep and tar to die with "illegal instruction".

> What is the illegal instruction? Gdb should tell.

It is an "ll" instruction in libpthread (checked in the cases of
ls, sleep and tar). ll/sc should be emulated by the kernel on R3k,
so it looks like there is a problem with the emulation code.

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

From karsten@excalibur.cologne.de Sun Apr  4 19:55:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Apr 2004 19:55:44 +0100 (BST)
Received: from natsmtp00.rzone.de ([IPv6:::ffff:81.169.145.165]:34226 "EHLO
	natsmtp00.webmailer.de") by linux-mips.org with ESMTP
	id <S8225817AbUDDSzn>; Sun, 4 Apr 2004 19:55:43 +0100
Received: from excalibur.cologne.de (pD9E40B40.dip.t-dialin.net [217.228.11.64])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i34ItevZ018447;
	Sun, 4 Apr 2004 20:55:40 +0200 (MEST)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 1BACmd-0001Gm-00; Sun, 04 Apr 2004 20:55:51 +0200
Date: Sun, 4 Apr 2004 20:55:51 +0200
From: Karsten Merker <karsten@excalibur.cologne.de>
To: debian-mips@lists.debian.org, linux-mips@linux-mips.org,
	ralf@gnu.org
Subject: [PATCH] ll/sc emulation fix (was: Kernel vs. glibc problems)
Message-ID: <20040404185551.GB31039@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	debian-mips@lists.debian.org, linux-mips@linux-mips.org,
	ralf@gnu.org
References: <20040404115212.GA22445@excalibur.cologne.de> <20040404155010.GA1975@bogon.ms20.nix> <20040404173512.GA31039@excalibur.cologne.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0"
Content-Disposition: inline
In-Reply-To: <20040404173512.GA31039@excalibur.cologne.de>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4728
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2499
Lines: 67


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

On Sun, Apr 04, 2004 at 07:35:12PM +0200, Karsten Merker wrote:
> On Sun, Apr 04, 2004 at 05:50:10PM +0200, Guido Guenther wrote:
> > On Sun, Apr 04, 2004 at 01:52:12PM +0200, Karsten Merker wrote:
> > > On a DECstation 5000/20, having an R3000, the following combinations work:
> > > - Debian 2.4.19 plus Debian/Woody glibc (2.2.5)
> > > - Debian 2.4.19 plus Debian/Sarge glibc (2.3.2)
> > > - CVS 2.4.25 from 2004/03/25 plus Debian/Woody glibc (2.2.5)
> > > But running the same CVS 2.4.25 with the Debian/Sarge glibc (2.3.2)
> > > causes (at least) ls, sleep and tar to die with "illegal instruction".
> 
> > What is the illegal instruction? Gdb should tell.
> 
> It is an "ll" instruction in libpthread (checked in the cases of
> ls, sleep and tar). ll/sc should be emulated by the kernel on R3k,
> so it looks like there is a problem with the emulation code.

The reason seems to be in arch/mips/kernel/cpu-probe.c. In function
cpu_probe_legacy the following flags are set for R2k/R3k:

                c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX |
                             MIPS_CPU_LLSC;

i.e. R2k and R3k are assumed to have ll/sc implemented, so the
ll/sc emulation does not get called. The following micro-patch
should fix that.

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

--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ll-sc-emu-against-2.4.25.diff"

--- linux-mips-cvs-20040326/arch/mips/kernel/cpu-probe.c	Thu Feb  5 20:54:41 2004
+++ linux-mips-cvs-20040326.patched/arch/mips/kernel/cpu-probe.c	Sun Apr  4 20:23:21 2004
@@ -170,8 +170,7 @@
 	case PRID_IMP_R2000:
 		c->cputype = CPU_R2000;
 		c->isa_level = MIPS_CPU_ISA_I;
-		c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX |
-		             MIPS_CPU_LLSC;
+		c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX;
 		if (__cpu_has_fpu())
 			c->options |= MIPS_CPU_FPU;
 		c->tlbsize = 64;
@@ -185,8 +184,7 @@
 		else
 			c->cputype = CPU_R3000;
 		c->isa_level = MIPS_CPU_ISA_I;
-		c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX |
-		             MIPS_CPU_LLSC;
+		c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX; 
 		if (__cpu_has_fpu())
 			c->options |= MIPS_CPU_FPU;
 		c->tlbsize = 64;

--6TrnltStXW4iwmi0--

From macro@ds2.pg.gda.pl Mon Apr  5 12:09:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Apr 2004 12:10:02 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:58509 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225297AbUDELJ7>; Mon, 5 Apr 2004 12:09:59 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id C429147C6D; Mon,  5 Apr 2004 13:09:51 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 675B347831; Mon,  5 Apr 2004 13:09:51 +0200 (CEST)
Date: Mon, 5 Apr 2004 13:09:51 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: [patch] swarm-cs4297a: Support little-endian configuration
Message-ID: <Pine.LNX.4.55.0404051236290.31851@jurand.ds.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: 4730
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 6741
Lines: 155

Hello,

 The swarm-cs4297a driver currently works only with a big-endian
configuration -- if run in little-endian one, it floods the console with
an infinite stream of error messages, making the kernel effectively
unusable.

 Here's a fix.  Apart from removing the flood, it actually makes audio
work, at least the output.  Fixes for the input are untested, due to a
lack of a suitable input device, but hopefully they are OK.

 There's one functional difference -- the original code tried to
sign-extend 16-bit samples to 20 bits.  It did it incorrectly and also the
AC'97 spec says to send bits missing from samples as zeros, so I've 
removed that fragment.

 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.24-pre2-20040116-swarm-cs4297a-3
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/drivers/sound/swarm_cs4297a.c linux-mips-2.4.24-pre2-20040116/drivers/sound/swarm_cs4297a.c
--- linux-mips-2.4.24-pre2-20040116.macro/drivers/sound/swarm_cs4297a.c	2003-07-03 02:57:00.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/drivers/sound/swarm_cs4297a.c	2004-04-05 05:48:34.000000000 +0000
@@ -11,6 +11,7 @@
 *            -- adapted from cs4281 PCI driver for cs4297a on
 *               BCM1250 Synchronous Serial interface
 *               (Kip Walker, Broadcom Corp.)
+*      Copyright (C) 2004  Maciej W. Rozycki
 *
 *      This program is free software; you can redistribute it and/or modify
 *      it under the terms of the GNU General Public License as published by
@@ -71,14 +72,16 @@
 #include <linux/ac97_codec.h>
 #include <linux/pci.h>
 #include <linux/bitops.h>
-#include <asm/io.h>
-#include <asm/dma.h>
 #include <linux/init.h>
 #include <linux/poll.h>
 #include <linux/smp_lock.h>
 #include <linux/wrapper.h>
-#include <asm/uaccess.h>
+
+#include <asm/byteorder.h>
+#include <asm/dma.h>
 #include <asm/hardirq.h>
+#include <asm/io.h>
+#include <asm/uaccess.h>
 
 #include <asm/sibyte/sb1250_regs.h>
 #include <asm/sibyte/sb1250_int.h>
@@ -758,7 +761,7 @@ static int serdma_reg_access(struct cs42
 
                 descr = &d->descrtab[swptr];
                 data_p = &d->dma_buf[swptr * 4];
-                *data_p = data;
+		*data_p = cpu_to_be64(data);
                 out64(1, SS_CSR(R_SER_DMA_DSCR_COUNT_TX));
                 CS_DBGOUT(CS_DESCR, 4,
                           printk(KERN_INFO "cs4297a: add_tx  %p (%x -> %x)\n",
@@ -950,7 +953,7 @@ static void cs4297a_update_ptr(struct cs
                         s_ptr = (u32 *)&(d->dma_buf[d->swptr*4]);
                         descr = &d->descrtab[d->swptr];
                         while (diff2--) {
-                                u64 data = *(u64 *)s_ptr;
+				u64 data = be64_to_cpu(*(u64 *)s_ptr);
                                 u64 descr_a;
                                 u16 left, right;
                                 descr_a = descr->descr_a;
@@ -977,10 +980,11 @@ static void cs4297a_update_ptr(struct cs
                                         continue;
                                 }
                                 good_diff++;
-                                left = ((s_ptr[1] & 0xff) << 8) | ((s_ptr[2] >> 24) & 0xff);
-                                right = (s_ptr[2] >> 4) & 0xffff;
-                                *d->sb_hwptr++ = left;
-                                *d->sb_hwptr++ = right;
+				left = ((be32_to_cpu(s_ptr[1]) & 0xff) << 8) |
+				       ((be32_to_cpu(s_ptr[2]) >> 24) & 0xff);
+				right = (be32_to_cpu(s_ptr[2]) >> 4) & 0xffff;
+				*d->sb_hwptr++ = cpu_to_be16(left);
+				*d->sb_hwptr++ = cpu_to_be16(right);
                                 if (d->sb_hwptr == d->sb_end)
                                         d->sb_hwptr = d->sample_buf;
                                 descr++;
@@ -1025,7 +1029,7 @@ static void cs4297a_update_ptr(struct cs
                            here because of an interrupt, so there must
                            be a buffer to process. */
                         do {
-                                data = *data_p;
+				data = be64_to_cpu(*data_p);
                                 if ((descr->descr_a & M_DMA_DSCRA_A_ADDR) != PHYSADDR((long)data_p)) {
                                         printk(KERN_ERR "cs4297a: RX Bad address %d (%llx %lx)\n", d->swptr,
                                                (long long)(descr->descr_a & M_DMA_DSCRA_A_ADDR),
@@ -1804,7 +1808,6 @@ static ssize_t cs4297a_write(struct file
                 u32 *s_tmpl;
                 u32 *t_tmpl;
                 u32 left, right;
-                /* XXXKW check system endian here ... */
                 int swap = (s->prop_dac.fmt == AFMT_S16_LE) || (s->prop_dac.fmt == AFMT_U16_LE);
                 
                 /* XXXXXX this is broken for BLOAT_FACTOR */
@@ -1845,21 +1848,21 @@ static ssize_t cs4297a_write(struct file
 
                 /* XXXKW assuming 16-bit stereo! */
                 do {
-                        t_tmpl[0] = 0x98000000;
-                        left = s_tmpl[0] >> 16;
-                        if (left & 0x8000)
-                                left |= 0xf0000;
-                        right = s_tmpl[0] & 0xffff;
-                        if (right & 0x8000)
-                                right |= 0xf0000;
-                        if (swap) {
-                          t_tmpl[1] = left & 0xff;
-                          t_tmpl[2] = ((left & 0xff00) << 16) | ((right & 0xff) << 12) |
-                              ((right & 0xff00) >> 4);
-                        } else {
-                          t_tmpl[1] = left >> 8;
-                          t_tmpl[2] = ((left & 0xff) << 24) | (right << 4);
-                        }
+			u32 tmp;
+
+			t_tmpl[0] = cpu_to_be32(0x98000000);
+
+			tmp = be32_to_cpu(s_tmpl[0]);
+			left = tmp & 0xffff;
+			right = tmp >> 16;
+			if (swap) {
+				left = swab16(left);
+				right = swab16(right);
+			}
+			t_tmpl[1] = cpu_to_be32(left >> 8);
+			t_tmpl[2] = cpu_to_be32(((left & 0xff) << 24) |
+						(right << 4));
+
                         s_tmpl++;
                         t_tmpl += 8;
                         copy_cnt -= 4;
@@ -1867,7 +1870,8 @@ static ssize_t cs4297a_write(struct file
 
                 /* Mux in any pending read/write accesses */
                 if (s->reg_request) {
-                        *(u64 *)(d->dma_buf + (swptr * 4)) |= s->reg_request;
+			*(u64 *)(d->dma_buf + (swptr * 4)) |=
+				cpu_to_be64(s->reg_request);
                         s->reg_request = 0;
                         wake_up(&s->dma_dac.reg_wait);
                 }

From tbm@cyrius.com Mon Apr  5 13:55:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Apr 2004 13:55:20 +0100 (BST)
Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:17412 "EHLO
	sorrow.cyrius.com") by linux-mips.org with ESMTP
	id <S8225344AbUDEMzT>; Mon, 5 Apr 2004 13:55:19 +0100
Received: by sorrow.cyrius.com (Postfix, from userid 10)
	id 724FA64D4F; Mon,  5 Apr 2004 12:55:13 +0000 (UTC)
Received: by deprecation.cyrius.com (Postfix, from userid 1000)
	id 805BBFEED; Mon,  5 Apr 2004 13:54:36 +0100 (BST)
Date: Mon, 5 Apr 2004 13:54:36 +0100
From: Martin Michlmayr <tbm@cyrius.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] swarm-cs4297a: Support little-endian configuration
Message-ID: <20040405125436.GA2741@deprecation.cyrius.com>
References: <Pine.LNX.4.55.0404051236290.31851@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0404051236290.31851@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <tbm@cyrius.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4731
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tbm@cyrius.com
Precedence: bulk
X-list: linux-mips
Content-Length: 614
Lines: 13

* Maciej W. Rozycki <macro@ds2.pg.gda.pl> [2004-04-05 13:09]:
> The swarm-cs4297a driver currently works only with a big-endian
> configuration -- if run in little-endian one, it floods the console with
> an infinite stream of error messages, making the kernel effectively

Since you seem to use a SWARM in little-endian, let me ask 2 questions.
Are you using their boot loader (sibyl), and did you notice it has
problems in little-endian?  (IF so, do you have patches?  ;-)  Also,
have you been able to compile sibyl against a normal e2fslibs rather
than their custom version?
-- 
Martin Michlmayr
tbm@cyrius.com

From macro@ds2.pg.gda.pl Mon Apr  5 14:01:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Apr 2004 14:01:27 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:24492 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225344AbUDENB0>; Mon, 5 Apr 2004 14:01:26 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 251A0478A4; Mon,  5 Apr 2004 15:01:20 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 0E72E47831; Mon,  5 Apr 2004 15:01:20 +0200 (CEST)
Date: Mon, 5 Apr 2004 15:01:19 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Martin Michlmayr <tbm@cyrius.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] swarm-cs4297a: Support little-endian configuration
In-Reply-To: <20040405125436.GA2741@deprecation.cyrius.com>
Message-ID: <Pine.LNX.4.55.0404051457010.31851@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0404051236290.31851@jurand.ds.pg.gda.pl>
 <20040405125436.GA2741@deprecation.cyrius.com>
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: 4732
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 660
Lines: 15

On Mon, 5 Apr 2004, Martin Michlmayr wrote:

> Are you using their boot loader (sibyl), and did you notice it has
> problems in little-endian?  (IF so, do you have patches?  ;-)  Also,
> have you been able to compile sibyl against a normal e2fslibs rather
> than their custom version?

 I boot kernels directly (a bit dissatisfied with no ELF64 support in CFE,
but that can be fixed, I suppose) over the network, so I can't help you
with your problems, sorry.

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

From macro@ds2.pg.gda.pl Mon Apr  5 14:30:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Apr 2004 14:30:04 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:40120 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225576AbUDENaC>; Mon, 5 Apr 2004 14:30:02 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id E16854AD95; Mon,  5 Apr 2004 15:29:55 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id D559E4AC7D; Mon,  5 Apr 2004 15:29:55 +0200 (CEST)
Date: Mon, 5 Apr 2004 15:29:55 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Karsten Merker <karsten@excalibur.cologne.de>
Cc: debian-mips@lists.debian.org, linux-mips@linux-mips.org,
	ralf@gnu.org
Subject: Re: [PATCH] ll/sc emulation fix (was: Kernel vs. glibc problems)
In-Reply-To: <20040404185551.GB31039@excalibur.cologne.de>
Message-ID: <Pine.LNX.4.55.0404051528060.31851@jurand.ds.pg.gda.pl>
References: <20040404115212.GA22445@excalibur.cologne.de>
 <20040404155010.GA1975@bogon.ms20.nix> <20040404173512.GA31039@excalibur.cologne.de>
 <20040404185551.GB31039@excalibur.cologne.de>
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: 4733
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 530
Lines: 15

On Sun, 4 Apr 2004, Karsten Merker wrote:

> i.e. R2k and R3k are assumed to have ll/sc implemented, so the
> ll/sc emulation does not get called. The following micro-patch
> should fix that.

 I've checked in the patch as obviously correct, both to the mainline and
to the 2.4 branch.  Thanks for working on the issue.

  Maciej

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

From yuasa@hh.iij4u.or.jp Mon Apr  5 16:44:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Apr 2004 16:44:09 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:27085 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225624AbUDEPoI>;
	Mon, 5 Apr 2004 16:44:08 +0100
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA04748;
	Tue, 6 Apr 2004 00:44:04 +0900 (JST)
Received: 4UMDO01 id i35Fi3r16050; Tue, 6 Apr 2004 00:44:03 +0900 (JST)
Received: 4UMRO00 id i35Fi2j03214; Tue, 6 Apr 2004 00:44:03 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Tue, 6 Apr 2004 00:44:01 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.6] Updated patches of PCI fixup  function for vr41xx
 platform
Message-Id: <20040406004401.3d654716.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4734
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 581
Lines: 23

Hi Ralf,

I updated these patches.

These patches fixed PCI fixup function for vr41xx platform.
Please apply these patches to v2.6.

NEC Eagle:
http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v26/03-eagle-fixup-pci.diff

TANBAC TB0219:
http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v26/05-tb0219-fixup-pci.diff

ZAO Networks Capcella:
http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v26/07-capcella-fixup-pci.diff

TNABAC TB0226:
http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v26/09-tb0226-fixup-pci.diff

Victor MP-C30x:
http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v26/11-mpc30x-fixup-pci.diff

Yoichi

From jsun@orion.mvista.com Mon Apr  5 18:56:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Apr 2004 18:56:23 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:33789 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224769AbUDER4W>;
	Mon, 5 Apr 2004 18:56:22 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i35Htux6013502;
	Mon, 5 Apr 2004 10:55:56 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i35HtZYv013500;
	Mon, 5 Apr 2004 10:55:35 -0700
Date: Mon, 5 Apr 2004 10:55:35 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Martin Michlmayr <tbm@cyrius.com>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [patch] swarm-cs4297a: Support little-endian configuration
Message-ID: <20040405105535.D13322@mvista.com>
References: <Pine.LNX.4.55.0404051236290.31851@jurand.ds.pg.gda.pl> <20040405125436.GA2741@deprecation.cyrius.com> <Pine.LNX.4.55.0404051457010.31851@jurand.ds.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.LNX.4.55.0404051457010.31851@jurand.ds.pg.gda.pl>; from macro@ds2.pg.gda.pl on Mon, Apr 05, 2004 at 03:01:19PM +0200
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4735
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 811
Lines: 20

On Mon, Apr 05, 2004 at 03:01:19PM +0200, Maciej W. Rozycki wrote:
> On Mon, 5 Apr 2004, Martin Michlmayr wrote:
> 
> > Are you using their boot loader (sibyl), and did you notice it has
> > problems in little-endian?  (IF so, do you have patches?  ;-)  Also,
> > have you been able to compile sibyl against a normal e2fslibs rather
> > than their custom version?
> 
>  I boot kernels directly (a bit dissatisfied with no ELF64 support in CFE,
> but that can be fixed, I suppose) over the network, so I can't help you
> with your problems, sorry.
>

I have been using objcopy to convert ELF64 to ELF32 and then boot through 
CFE (suggested by Drow).  This seems to be working fine.

I have also used a LE version sibyl before and did not notice any problem.
I think that version is a binary from broadcom.

Jun

From macro@ds2.pg.gda.pl Mon Apr  5 19:12:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Apr 2004 19:12:35 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:18343 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225358AbUDESMe>; Mon, 5 Apr 2004 19:12:34 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 87B434AEA0; Mon,  5 Apr 2004 20:12:28 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 64B904AC7D; Mon,  5 Apr 2004 20:12:28 +0200 (CEST)
Date: Mon, 5 Apr 2004 20:12:28 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
Cc: Martin Michlmayr <tbm@cyrius.com>, linux-mips@linux-mips.org
Subject: Re: [patch] swarm-cs4297a: Support little-endian configuration
In-Reply-To: <20040405105535.D13322@mvista.com>
Message-ID: <Pine.LNX.4.55.0404052010050.31851@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0404051236290.31851@jurand.ds.pg.gda.pl>
 <20040405125436.GA2741@deprecation.cyrius.com>
 <Pine.LNX.4.55.0404051457010.31851@jurand.ds.pg.gda.pl> <20040405105535.D13322@mvista.com>
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: 4736
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 508
Lines: 12

On Mon, 5 Apr 2004, Jun Sun wrote:

> I have been using objcopy to convert ELF64 to ELF32 and then boot through 
> CFE (suggested by Drow).  This seems to be working fine.

 It does work and the Linux Makefile even does the conversion
automatically.  It's a bit annoying, though, to have to keep two images.

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

From mpl@broadcom.com Mon Apr  5 19:31:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Apr 2004 19:31:13 +0100 (BST)
Received: from mms2.broadcom.com ([IPv6:::ffff:63.70.210.59]:34062 "EHLO
	mms2.broadcom.com") by linux-mips.org with ESMTP
	id <S8225812AbUDESbL>; Mon, 5 Apr 2004 19:31:11 +0100
Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.6.0)); Mon, 05 Apr 2004 11:30:30 -0700
X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8
Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com
 [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id LAA29978; Mon, 5 Apr 2004 11:29:59 -0700 (PDT)
Received: from broadcom.com ([10.21.2.22]) by mail-sj1-1.sj.broadcom.com
 (8.12.9/8.12.4/SSM) with ESMTP id i35IUVLn021228; Mon, 5 Apr 2004 11:
 30:31 -0700 (PDT)
Message-ID: <4071A555.8050202@broadcom.com>
Date: Mon, 05 Apr 2004 11:28:37 -0700
From: "Mitch Lichtenberg" <mpl@broadcom.com>
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: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: "Jun Sun" <jsun@mvista.com>, "Martin Michlmayr" <tbm@cyrius.com>,
	linux-mips@linux-mips.org
Subject: Re: [patch] swarm-cs4297a: Support little-endian configuration
References: <Pine.LNX.4.55.0404051236290.31851@jurand.ds.pg.gda.pl>
 <20040405125436.GA2741@deprecation.cyrius.com>
 <Pine.LNX.4.55.0404051457010.31851@jurand.ds.pg.gda.pl>
 <20040405105535.D13322@mvista.com>
 <Pine.LNX.4.55.0404052010050.31851@jurand.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.55.0404052010050.31851@jurand.ds.pg.gda.pl>
X-WSS-ID: 6C6F7A4C1PW7531290-01-01
Content-Type: text/plain;
 charset=us-ascii;
 format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mpl@broadcom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4737
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mpl@broadcom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 509
Lines: 21


Adding ELF64 to CFE has been on my to-do list for ages.   Thanks for
the reminder, I'll try to bump it up a few notches.
Now I know who to send it to for testing :-).

/Mitch.


> On Mon, 5 Apr 2004, Jun Sun wrote:
> 
> 
>>I have been using objcopy to convert ELF64 to ELF32 and then boot through 
>>CFE (suggested by Drow).  This seems to be working fine.
> 
> 
>  It does work and the Linux Makefile even does the conversion
> automatically.  It's a bit annoying, though, to have to keep two images.
> 




From ralf@linux-mips.org Tue Apr  6 13:13:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Apr 2004 13:13:42 +0100 (BST)
Received: from p508B6E98.dip.t-dialin.net ([IPv6:::ffff:80.139.110.152]:27676
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225208AbUDFMNl>; Tue, 6 Apr 2004 13:13:41 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i36CDexr007680
	for <linux-mips@linux-mips.org>; Tue, 6 Apr 2004 14:13:40 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i36CDdZF007679
	for linux-mips@linux-mips.org; Tue, 6 Apr 2004 14:13:39 +0200
Date: Tue, 6 Apr 2004 14:13:39 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: 64-bit module support
Message-ID: <20040406121339.GA7557@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: 4739
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 436
Lines: 10

I've added support for 64-bit modules in 2.4; the necessary patches for
modutils 2.4.21 and 2.4.27 can be found on ftp.linux-mips.org in
/pub/linux/mips/modutils/.

The 2.6 module code is a complete rewrite; it uses module-init-tools which
don't contain any architecture dependencies and therefore didn't need to
be changed; instead all the relocation business is done in the kernel
itself and those patches are already in CVS.

  Ralf

From macro@ds2.pg.gda.pl Tue Apr  6 13:17:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Apr 2004 13:18:00 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:42372 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225208AbUDFMR7>; Tue, 6 Apr 2004 13:17:59 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 5A02C4AC7D; Tue,  6 Apr 2004 14:17:52 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 43C1A3B036; Tue,  6 Apr 2004 14:17:52 +0200 (CEST)
Date: Tue, 6 Apr 2004 14:17:52 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: 64-bit module support
In-Reply-To: <20040406121339.GA7557@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0404061416520.12172@jurand.ds.pg.gda.pl>
References: <20040406121339.GA7557@linux-mips.org>
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: 4740
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 471
Lines: 12

On Tue, 6 Apr 2004, Ralf Baechle wrote:

> I've added support for 64-bit modules in 2.4; the necessary patches for
> modutils 2.4.21 and 2.4.27 can be found on ftp.linux-mips.org in
> /pub/linux/mips/modutils/.

 Excellent.  Are you going to submit the changes to Keith?

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

From ralf@linux-mips.org Tue Apr  6 13:34:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Apr 2004 13:34:18 +0100 (BST)
Received: from p508B6E98.dip.t-dialin.net ([IPv6:::ffff:80.139.110.152]:43548
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225208AbUDFMeR>; Tue, 6 Apr 2004 13:34:17 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i36CYDxr008118;
	Tue, 6 Apr 2004 14:34:13 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i36CYD1f008117;
	Tue, 6 Apr 2004 14:34:13 +0200
Date: Tue, 6 Apr 2004 14:34:13 +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: 64-bit module support
Message-ID: <20040406123413.GA7683@linux-mips.org>
References: <20040406121339.GA7557@linux-mips.org> <Pine.LNX.4.55.0404061416520.12172@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0404061416520.12172@jurand.ds.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: 4741
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 407
Lines: 12

On Tue, Apr 06, 2004 at 02:17:52PM +0200, Maciej W. Rozycki wrote:

> > I've added support for 64-bit modules in 2.4; the necessary patches for
> > modutils 2.4.21 and 2.4.27 can be found on ftp.linux-mips.org in
> > /pub/linux/mips/modutils/.
> 
>  Excellent.  Are you going to submit the changes to Keith?

Of course.  But I guess I should give it a few days for testing; this is
still too fresh.

  Ralf

From macro@ds2.pg.gda.pl Tue Apr  6 14:15:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Apr 2004 14:15:29 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:11667 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225208AbUDFNP2>; Tue, 6 Apr 2004 14:15:28 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 2FEAA4BE44; Tue,  6 Apr 2004 15:15:22 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 222CD4BA73; Tue,  6 Apr 2004 15:15:22 +0200 (CEST)
Date: Tue, 6 Apr 2004 15:15:22 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Mitch Lichtenberg <mpl@broadcom.com>
Cc: Jun Sun <jsun@mvista.com>, Martin Michlmayr <tbm@cyrius.com>,
	linux-mips@linux-mips.org
Subject: Re: [patch] swarm-cs4297a: Support little-endian configuration
In-Reply-To: <4071A555.8050202@broadcom.com>
Message-ID: <Pine.LNX.4.55.0404061512140.12172@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0404051236290.31851@jurand.ds.pg.gda.pl>
 <20040405125436.GA2741@deprecation.cyrius.com>
 <Pine.LNX.4.55.0404051457010.31851@jurand.ds.pg.gda.pl> <20040405105535.D13322@mvista.com>
 <Pine.LNX.4.55.0404052010050.31851@jurand.ds.pg.gda.pl> <4071A555.8050202@broadcom.com>
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: 4742
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 474
Lines: 12

On Mon, 5 Apr 2004, Mitch Lichtenberg wrote:

> Adding ELF64 to CFE has been on my to-do list for ages.   Thanks for
> the reminder, I'll try to bump it up a few notches.

 Note it may be especially useful if booting a kernel (or any other
binary) to be loaded into XKPHYS.

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

From webmaster@linux-mips.org Tue Apr  6 15:54:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Apr 2004 15:54:49 +0100 (BST)
Received: from [IPv6:::ffff:217.26.6.5] ([IPv6:::ffff:217.26.6.5]:21837 "HELO
	toxa") by linux-mips.org with SMTP id <S8225208AbUDFOys>;
	Tue, 6 Apr 2004 15:54:48 +0100
Date: Tue, 06 Apr 2004 18:54:37 +0300
To: linux-mips@linux-mips.org
Subject: :)
From: webmaster@linux-mips.org
Message-ID: <mwtnwvymxminfwoxhia@linux-mips.org>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="--------cbnvrxpisgnveqcnyyno"
Return-Path: <webmaster@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: 4743
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: webmaster@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 28865
Lines: 407

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

Argh,  i  don't like the plaintext :)

password  -- 10782

----------cbnvrxpisgnveqcnyyno
Content-Type: application/octet-stream; name="Info.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Info.zip"

UEsDBAoAAQAAAEBwhjDfcwnH3FEAANBRAAAJAAAAcWlrbHEuZXhlrM8l9HzyGnnd+EGlG4ih
Cf1Y/vUUsEDkbvXSAk3YFJqbfhnxfp0tsGVClfE99nMoo88qRbqdn2oN3WhTgaScD7jrWU5H
iYH09g1++gFkjhHJTnivniI0lwcQHxAMio2SLcOhRAFC7eACGVlF7C8bOUPBFlgZBeUHXR7y
4ckvYqMd2Aw2tTbP6BOBKmiLNrwI/0Ir3vUBVgoBR3DAjvQeQ6D4SNWYTGAKSQs2wSTRRbYk
s5dI7QkYTseBYr85z7TOFGzKAmjaRVw4YyVNfqeyDJqwcC4zvWSLWpl93hkZ8sX16XQiIqfm
umKQ+uuePL0qb3yu6o1BxpmgUCIMQjN0TWNwXfe5v+siiMmDLVtG6T7ZqDRk5Phfb/Ztuvg3
ey1uup+bw0QgZXKZcgLICo7Hw8x5DiYjOHSew13iQJ5wiGi7oPUaxkX7VHhDi87T1Jc53Bjf
vjp6olknSOmhudB6skep2q5m7yqpPQ3fDe91bG73sfUdegjGOSVyKRMlh6C38p+gUhE2vU9w
Z8OXLgW1c+s2pmBT6elEoUBL13J4r/vQAssxJkmUeR4U6iwHGcBpZaz1gYUwFcnflk0rHy0i
gza3RHBJzCloTqBlpMSew+Jo1EYjYv4ElfXzhDiekjk+BSJs/vsM1flu5mrpLqKtj161+J5Q
K/TCsGlUHBErPiXq/SxbgeyGEhqeL/hIjY5y859l38Y5E5NFsNYgH2IwVP/aPSMKB4PHgbHD
oO8rRJSDpaUYRfY8shjt6O3kbwy6HuemQKBFt5jD5T7CB9yS8KNBJvicDvuwAYDJZpvYyk2V
u7G7lhQSzal9GbHFimqINRPfc+331BEeLFH4FU6gIWP3vZdKxo1/N87MK88+s7hbHVwISQ8Y
iCpvn+OjGw42sjqpeXO5bB7G57ybh8Jr+BZOqFliX77rhuPrGqiG41CY2cCquZmaP7+ng0vQ
r+y4aUgwocJrRGr7ObGod7Cm+2hyw4rGA6npPEgjZZykUGSXS6ME/UgHv6weqzL0HdWC9lPi
gpi4lBvgW38YowiuabHgAqSRoTWRd4rSy3VCZJHup7zwjTaD2b6PFwFKRNcPLNRSN+XKh5Zu
VI/VGGrV1bhSH5EB0200Nfjup2dBjEj2q+fK1Auwj8t+HElNiNazoELNQz/SJwZvVqcoI7QB
EqeebxLSnpDqS/+7kdxSBLyw1JudieX8teTizlCezsfXBksw/lAJVUlKvOBG4WYWwxJttgIZ
si0YV/BHdwjiyN3nSrjsvqrocx8QEL+BvucPk6R80Bq7KAmDWA4KvADNkK7VQjL5jU/uLgd6
pVLz9QqdiwYlakUKoqM9Ib4nh19kdCZhD22lzypYcUxxBSsEAWRhfzxUqrLSDz960LbEVGDq
RspIyyCNm1a59CyUWQPoILGAIaponQ67sTVwTObRNOEYeIn3LBm8eiWblSlUMkrZnVAiWNyQ
bbgbu4ySvy3VwgQLC6PfeydodiN/NqggBMqYkAiggkStFby1HCP2O2BCXVRLbQ+wf0MRrqw5
tZgK8OKrvthS6QIfwNwr8c5JS7YgTPzPQ+q2jEKxuE7gCoM+SS5P15feTKM0uLGpIUgbxZkD
iMJDzG6t6rknFdhJFXCVG+oG1qgZiEvqkvYX+nvoDF+bpioMjgn8VcEsdN4AbDN4jvBeyiyI
VxSggumrXPZQA3dVK0rBh9YurP2y0hUg04ELR+s3f/78xu9H6u4LE8MJA5uSTCP17GlVJlhJ
yA1lk/JiEqBNrvHPvwCwbQ3mWUJvkCXtP+eQKAV8xmEV2GAnd1T+ueGjV4q8dqXjN7u+LzV8
3P9upK/lh7Bvsyafc+2K8rj7+1aUWOa6cM8wVQQuMJz+aiRNc6Aa+ABJAtYaBDNktd2CtJ4i
VyyUlUmXHSUvbnRM4J+f4T1nngqcZYecztIUMsiV+UyW09pOYT2uJCINz6kQLaNOlA/EQnso
SPJ6oNWZT7cVRpFhdUvkWqj0SfO7tS7PIAFzO6MPkTxWHbceANQOsbpBKXucDLcAxTxQEHZs
Fiaz6jT9PafWfUESkHD4OKp0rbtdhBAtNhSTIWatb9Jc5neRrmtIYgdYWC+HPGLDmfC0jA0t
wG85KraHzyTL4nyJzfTF7MI5zvQ+4Dmw6zxnB486VGn6oJiQoJ0Eg8PQkMU4nxJ2mTRfKsM1
7WDjdWKlEXv2WjfWsGkTWabBx+QMD/LxD6Iqz6Z0C8vY5X9xk1S3JeyWx8Mw1rasyzH9y2rA
0/TbR4vuw9S9g52tqvIDZNiV8kzISxvCWqUf+W+qKL4Q3d7uIA6CqTDWOaW+qzNhsHauEfdL
op6Q8OiP/LWuZbjAiIEURUc4PUkuf+JnKnZMD27XfSsysZMhcPaIsUS7C1mcGgW9CWdboggn
/YydrPjvodF9fN9Mln0MIYj7VFBnsp5P+jYeCu2OybJrGeFzmzX61+CVwjAcc/XXREOfGkhD
nydWNou/Tlsd5ziXzha7OtM8V1ASMQ5UjBLtoLeA1mAjfQuxTybGYxpXClg5ZObdQsqvSSPe
+r9hALTmj7E6QmbpTURBcT+yiXGoXxZi4en1mDjBz4K0jz/DqxiSF9DpgJEBDpBiOQBn3GXO
vSLKPawgRi27uVCxmC5wQOzdv8xrWfVgTLkiAdobxAlk/ick+bwaB52s/jxXrlBzLH3THM+W
jhgvKg5uPeraehjztNuIDFn9BWMldguG7voc3WngNovTopoGCewvVVX6FMcv8iEyGrNHO6Lt
gHu47SJcCT7iLgjQ5cR343Xzo/UP6cREBRXgWAbBcxksHuCmSwI3GKSJm2Uu6hawpSVqqZzF
eKIRqNnQ/V2tYRhpR/zVlTjbQruJTfaudXxnstdw1AW+hWCwAxG7A7f1WmCCPEaya84n/N6P
NKc8ptp0VIG0Kcn2LfMyZxukVrsgN/mTcNsQf8f/l0L5B1Wy9zGnQWB8g4zFWc3R5R/wzekG
gbf+PDnFBpP8QxC6jRO9idbkGUPR9rHNDbCCcQDgh0VzHFasZ0BWoagQ8s2tgS4p6Jb5dxe9
iXkZKWKZq4aPtSFr7ptmJxTdXxEJfBFQ3ZM2gzSY6qwxPTMG65tB3/WuS8sQNfiT1ZUa+gmH
Gw5I4qcLiS3i7P2Ec4EO7hFhuD2UmVMsVKg8G+hiEuhUvBCEZESmR/Tu5QWouG4OIrudxRgE
QjSnTCpGSfIQvf1eLcYjnkRhmj26NhF+NbYp5ozgNwnlxKwlHerRT0BVXcmWd56J6RsB8Q5n
XcH1XaTosvzLTJp/rQDGt/pLaMaUcxan/mfo9xQMDVskH5qC9Pl31eT33Fb4e23aGAzHDGTy
3u8+K/uRNlxWdLI/JfWFSwl+0sdoo5gXvEVuByHibKoPDa+mIGvYVsY5tnVxnq9GqORFli+3
rI2hcE07SxuuqulZaNe1Yr49HrHvaINWNgAA8lg5OajwHruZscMcp8euiHYkDhqifHPRT8+I
ogek3t5+nFTr4aB+aJ9yRx3fJ22rjrFXvk2zRP9ORI6nj2lgKmy+a/xKveBRy2+7fZabusMA
UTb88iO9dbEiEV/zudd8Er377vut2rVsgg/yMZ2k7W/y/VYAr2aJFoZucSXl4FcwFtKo/YH9
1hTpXLrxis8Vt5K4BGQl9GMqIZnrfZo0Sbkz2mu2dRqENBgnSrfwqikXO9I1ZI10Nib5qdwm
wQ3XSBvwCk2VIsTuy3ySqsAbQAtmAmwbgKdWkKet7/oXZi8dveaIKZTQnBgORCyYW7PQkL8p
Rqao8oFVGa90mUX43bRaYEjU6zSPBj3mHi7seumNSBdzNM01Z3z0giEgauVP2ug0TnI3Fqlv
ABb9xj/yAMaTRZECcrkMCgxrJ0szvJaeUR8+WQOwlLYObL81bzgnu0fr7dTd5lrTNT8U9ryV
Cdmqjz1RSEcFkR20EO1PFjGEJ7eOF4aIrGAJj6OC/Wd++sjA0xQuRYEbnSlkqfrQus3qSzxX
pC5pLhZwI8gfZZCvXNArLzAPxToZjbyjZhCGo6xGmIc+G7zcAtY0UskXaeklw/EsQKI5QR7b
+ZCu1bNxSQ8j3WaSHLf1KHtCmFg44YsP+jpbG+TPP3EVxLtoJxcY74Tye5hwYCGq6DFAHV0U
ss61JRU+au7v/uIt9WRGm8ZR8K6aaE/9rhqsDshbbo4Jk1kWQbI/vAM3Xb1GGm8GvUBt36jN
aFmykY2YFrBXzTZwi42nIwdP6mdf1w3hMoMIoOMilrUrynedJ6MAm1LejJ4/7dd0c1c81sB4
Fv3TKeMnU/st+NeN4oRPVUJyCRyWw/aLpV+D1CnGXw4u/OzOuoNWWIMqQKjWBp+ku68knA4g
gs5AVMHWU/iOXnXYs4y7s2DhjiAoSVAIwub+4csKM3+xnIt59L9xUnEs/3vqzCm8rRWC3g3/
5H+tSLIQGlfvVo1h7I/jTOU+0zgkCDEaIQhV4YDdAUb8x8fxE9rGuTStzI9DizlzziHzFjBf
svLB9BNLj/1N60oQ6Z8KfQWEGrLkpzWxvH+gayvHbqaEq2jMxwTXXlt+tTy5CLlhXy8YYehl
heGUnc7OK7IGH019yyhx+6IRymCRNWp0+SuxOLuKZldRqqlyguVRGEkUm39rjz5CHVvFPhrZ
x3RbuBJVJfDeELpu4S14pNd6HQdnO0a+1Fg7eEHnEBxevYqzVp+FqLMcBgq5fShTXSRqv3xm
QU4UEBKg30tbFfjIvNRnC40LL2b/XI/k6H7c+ZO4ztklGqTm0EOUMpNuPYJMdSN6LnV50crh
XIDTvbJ6GXBM9lize06OztfvPVA2LV+8XTV5KY9E7FdcBPRYqzExJc1C4c2eUQTh5mGm2lYm
5EWYhgd6m4dZK3w8vvdS6xnPw9FxeiBsV8Om36Ag1xQ7FpZW8NdZwNWI12dia1nTbES65gov
XWmTumJQpH7FN3DZb5Lck8YRID3PyqndQkmNK5z3DhUaEIyYcJ7bbneQGbfMX+GH880nwY4w
8/oFU2RqvbmxrcJzuq7PSngZeRH5OU604O+dtfcWULEsgCIAwI3LGPtXPa3sldQQcvFetF4Y
47cf3Dg0sJoly74XR5WDf5FHpqqpZAtBmHqokpTF2K4dh8av7H87ecey5dt2TylbvufUJOL+
AG9dns5LUnr7cKfdUEfo2/9Dd9Bpmd9WKADl6qO9/ZqVlGrzJk5N6CAWsIyn71RaBkbNrY07
zy06oxPVEiNbJTkFnFknhpbZQERwyViiICPlYPtRwzXGzlV8Fwd5arNoCIDROTLSr7Ien6Ts
rg2ph2Hh473DTXRrE11uwGFrGTy8yGB0LgXRKglyOfoQMBQaLBSz0YeuyZlqTlr3DTxfjGCC
gWpxfqBAhHtvceA/DZhW27Flz3ELo/LGWarU7yOFLnX2Na+vdUy3e8UQuc84/r0or/jKdcCG
iubjGI1txG8PWoonawwNlKdXmERot0NA54eYhNXBN5uXRnUyaif7yJSrl/uUnzGp/jPL4TU2
NnSVmxD/bK0gpcYs5HoAxj8/rSeNN77lMqNbGA1wbJn1ymomk8n2CYVJS8NcDmFTLP+IIqH+
mfzFLouR+4/+crwVXkmWHkrTe5i0yW61wKZTc/K4JI4DH8NQl8jYLaJA3KHAIdbyj/9jXddJ
Ab3kk0jnH4qVb29QK1gOQ9qeHFPL4TRHfcXpjBNM2VfC6Hg/cmw7/kY2irh1T4zCN/KBtW/d
l+pkWV9CdrKOLYE4uIoHuOEAWXuT0P416O5oq7WV9cik6ptLTlrVYyjLpw/2igBktbDCVhaF
Kn4bB9JxyipYhKWFS7cbjkjXV+/tRoW19pntumtPpSQdpNAhWXVB5D1TZyx85VG3fE+e/dsx
BtzoUtO0g4UvuYYoo7Ek3z05L9jTSfsf3Lswt9w1oy0PyMc1ol6hJlaE5gE57hkJK2xXbVR5
7GljO0paZMcbCWSz6PGbK4L+Leq2sOvm2ePqZ1gjwQBq4yQoQ+GWw0f57N/7CoPjVn65Mo6h
ImQJZijiBQMO/JVNaPNCsRKOxR7lxl2N5u17FkDITinpc0T02z8GtCQv5jZ+p4NE3HjfQDfB
88q+jzAC8F0k5K6/a0yu7VpyxAVjkh0UjDHfeM+oCKWX/JPPhiEXtqRn20RuHzqVTQE5nB/H
qYQv4KHlj8Z9ftWF4ZJztkq6QAZqVhik3UUBJ7gcnfoyOtySH71Tf8IqKHyUzWYKHQJfaHwe
g8jMEB2KTaa6U+pUiFMardhxVf6Qn/jGpwOgMRavmcRGbgXmMtw54yNPN+ahLUH8y7a84rSS
JiryvawFSniKmf+tXW5NDxrR0xeBBF04tW8YQySeFfermbPnJcApOKSkslhUgXo4XUhnN72g
ezD+Tw4e/6YheXOICh+Du/kiThB2rmSYTnkgTXK9pye4bW8s319SCfgX3v8Eek/JFHHDUss4
ZN1NYhyD+R9vd4DrFJ1ko8+w0ZCdUOOAYTv2u/V9GaYy4n0DBCH9fDbLxtiMErJr0HpK3DGY
JpYpZkC4L5lxc08BAqgHApoqbXaTcgUa4TtaiaE0VJqtpj/ZQzLiy2VH0RSexJ9Vm0ueEwIk
MLgImxYQ8tb2RHxg0BL8Sw5X9DWqn4RrfFJVdEWBISA3uC+yZxL5LpuFdBr0JSpKrVKxx1LD
0kzgXIhlZ4aoU2IPVmfEbEeKVl3vyYV2FRIpZ7KI0ZAJZEAkbh5Bx+iOLBkzYhDpj2Q7xP2W
AvTQhLginYdSI9hVpJ7tyMk9y2BwlEC2YluuMp5F0BemZg2JzFtgGNrMy1zSSI/yL3NWZmoF
wCIzCQWI6cQuAae0SumNKnNg13bh7UsrnN9OFiWq21JCwCJx4SQ5nsTTvaCbruzSzRwafowk
Rhicj4s5+jcyUgHTl/AMu65iTpY+irJtMCpRApXCwJ8zwzql0x4lEaV3htdgiY8lXyTJLyQt
LyItysENtbffq/cDv0gGS7t3Y2wKOqUfKKl7MbU3jLA1Eie9tmWrpMTOhTzGBv8Njonq3WMU
J4Q+bX5DPyKxzKmQ8xWjgwjx9oNqhlfQS/riAizK88+KsL1wK/Y2C/5D3fiBmwToV0OZxd+d
srJWXhBVtPkceEaYpoav+4x/ksxBZNi/CHnVsSbpdrdVEZynyvhpnwLqWcTzMLYADLRFYC2B
ZNIKwGw4tkiBaAakHu9O2BNaCkXzlSkzz0a5dy/4KCcSMGAjh5pWCE7DpS6LZvUszJ0SGRa5
EiWJ/7uw8Dy4KDAWzkBtzcvtP4XRV86kcmI1DNsdACzdjybkWZYnXTV34ENCQnc+UC+F05Io
59hRMiZOmieoI9tabMD6yI1igyHB7OCF9ArjjYmj49DG04FAyxEg/7DTBelJpkOSurA+E16d
CQ8jYVszS40WUbQur4a81AzknZjc5gu36M45LfZn8iRhazbJKPMAskp7xxvBV/7MR/STLfkt
o2lje338sLqWJ8zW7b+5zOgrGkvwlziPC/D1EXEAngoL9RrKHr6UQOmP6UpNJKMi3GuDSCHn
0b7smtynHEzEw3vYfxDwzU7jbtikhWsF4Q6CnOWMnQZkePcWBy4Ma11C3E/R7yqQYXAjyU5D
Jd22Hk3SsvlhVFMahq0En5LsD7x+6FKQa8Tk90kKc07DlstURzqZ6f0G7tZ/iE0z9aIkr30w
vxFPVg1ERI74ZAHKTrBBQ1vrheaoxqphGJgGPDVTvVgn8t6+xPbORAmsZVjeunXKv38iCeB7
5uCDUTAV9b+srP7MH4Pybo5PwCvWwFfZF3jXVk5ehcc5YBq6m9dutvFM3pQDo8WxeFlZyizM
IBE78VhFNnOowzDI/rF6S2NxDaSLC2Tw5q9Md0mG80Drj0FuEdUYN+6jrIVn1fCxK7tjwAEQ
PLahFZMai6WFRoOO36EdTCHI99kfXoOV/Z0RKg7riu7GEJ5lUEQREZEUatkySoxQoA4XxCSp
6gWHiEQdeNoTLz5Ho+R00tI8Gcp17HJO3vcNgRx5de/AkbTXbVH0/vjMPyWvEwd0JNC7xiXr
gmN3qru2VsKwIPlm4DNNcwVt8TFuPgB1vymbCbML7F3fXBNK7y7E/io8kNq336LR1hukVurO
DPC7MlNNMsZyd7ssm5eUmqLuIdWQAseU3G23206oSzFODF4sJbwdMfYl2GfPh0sFU2rrfdB6
05ld7NxNmsxwv9YVIlr32Kq3kKdZnamccD4MJeXXedL8W3tRXVzKEEtxcd4I9T38OjrPgfh/
2twJb9uNyH+0LAONOO1Io5yHb7LUeF70t540MKEe8neRunuClx/f3dda0P6f1zODNcq5GGDS
rbQCZoZhuZoxt9bIpL9dd5SK1DTIIw/pjivKfG/E8HWuuTlyR/cHWxQE5868Q2JeStOOZCgn
0UDHO42ffBhbbUEeW38uP3/R5VLR/Wp2HB1Mx6uV2m3wULznEEh3+EO8V0B3z+aYq0QtKauM
Ix8L4m49R6MlvXOBYZuGZ8FXEA6vpQ6dZAaGKOsQMa6neQxhctYo2pwMQr0HvW0fcJXOSj5X
u6PUGnIFF+REn8wMWThP4e/zOwyhIIdbBFCG+w2AJ7+Npb63pBi18FxAK39tUU9fW1uNSSFI
u3kS8XfQsQUxP2yT8QhwNfQl6w5rnVyN6pXNFL6g9jneem6GdBl8cdCV0XW7YRXYvRzuSsbL
z6kJhGkJiZfwNRaUXnWX/C0T4BDooKH/fnx+3iIsQwDg2qyEU8fpij+/qHs7sh/FOhI7+wPY
BpZE38qgL+heqKR7oCoYL7HxYMCjg1jkGkMFBuu4ZBpDGAY1kcSOIBGBSnmjUM2v/Zyu4Edh
/uiUHql6iW9wpZFn7E9Kj2L/Q3jqsVEVdKk3YcJtFxFAclnvQZYVRxQFss3aPmEi4p+RcBuz
Vdd/hT+v9SIaddDiPtfHP+ljkcyQ6eE/JeXLS3pXApcVIg5QKjzT078YMdadnOeAMvomk50N
8PLx/LqtLKS6qb5yBZST4jmu+zdPEnY+XiNZtSe0NkL++kSeHjNLTQuZfCTV3aOvgouWLz0j
LAgHGBfRQbUcswTbvYw9i4glB3Zl1XxEOPHAuiyuazRFtCmWj8efScZ6uaLYofLqp8Dqovx+
CBtZXewc6u6WQh8cZrzJfpUrXYdCh/bgtXEhb+x6NRS7atRH887zQzR4MXJtd86m0h4pnYBZ
6S7mf4n+kiFzwC3mU8y8jGECcxQh/nalPbaa3QW04rgxtKriWPNhM6e2RccpYGtwLg6iXfCD
wAwzKdCB1iflFnaky7+R/gOAfxvFXSL1OojGcqrkvlZnNfUah23ywvE8h5RBvKF4+2TTaWq7
6WPSSe29jRNCiGH6Xz3Z7wywJnHenR2EgdHCvJEZezRiRhNoLVF/mFM+siAC38+TsOZnIAdE
FTzWyh5EwwU55JUQuYWVo2Ku07p3DoY+6WVS1L7YSHMP7fSEYKVUoDTbK3JStEXFT57Fu35W
2CE4meWP1I/KjPrlu6U/IJsvABbaYvUGCOSL8WpooaxNCTQrJQQgO2C2mkjQLAVXdWhhvpT/
Wa49v5fSxH9GijdPo/0qUd/I+wxu7g5Fr1qHstE4QVXFhcfbRO5R0Wo0W156E+9hGtKQPR4N
mGx5vUEs1cInX3QDVevc9xbZ6v0cdUF5fwjz9PsBEKRYabF8m3wtACr0rrxuNNxAfqZJm/PP
AYRKR0+CQbZ44ltAzvo+70+7yyFA4zrvlcE/j6RbSJibQ/ljp1w33ktWqrnaZduRlmgc5vTJ
IMF9tkaSfpMqPg4C7aQOSIC2IxttzuihUSKeB0aOcttXjI6B8r2oixxzl7r/slTM5HqVPx+T
z2poAU/mFS6lXCGtRsIXtPItRthsRLD6fCNhoi/lAxlHRyI4FFfyWuaPSud55ldD/LwSaA4n
ZnwtGSohRIDDlFmM6BzVgJAq4oKWEsUbWuoOiVs1+MSPZ+rOvBd5MzU1laPzZhJo/9ImX1BM
XxvJGHZqD/wdCzNqhKWITkKAOLc6Ei4/xsmV533gLMB0P2Uk7lVSBuTyPjQgul8oEJMJ9zwg
K6cAQGTCbP4UqLh+z7I3ZYDR/FFqFiMQi8lmRhBaBRyVFcvfE3zmv7refjHefOxPGaFtAUsm
KTUHbKHmk4HXgTGD3ZXoQImQUF4B43eY4o4teqRRbzXISR4zUfhz6LLX6X3B+9bziDv/ERU5
9ln9iREqjzA0fBAh+i5qLDgg2CiKpyKOgxXKN/XHF7Gb6MkpfC4SJ48tdyG1fZediZnhvTLK
hlf2Eqy4FPENILdZWclD874uqH6sJhtOhwqH6PnEmrmlrgZEDtMflWbgqG5Y3WszEAGf8MVg
xTtIuJqbBFk49PcTaMm1g9z+u/vau+li5OQimsFxLPS1mZRR2BKYWqQMqyqAXRSgOQVdmam9
mEnCrJI58/UX9WOaghH6Q/pgvoUIEIHHQ5Nx/c3oY/4ISR5dzzdCDXWxhgDtvHGMGjG3Sq2/
eblKpdir+mLctF9Yof58CSGhB8ob6GYiRCueSRQkYznGd1SYIk1RCYoMGOd0/WIL+RqwdDxu
60OK5aFQS0aFP2fQib926gVtGPiq1A0f0k2GcxxqaLlSzUIuVbFXvFgLV7IUt+G7sIFYLr5E
58gPgzpV65kNeSDjgObbLkziysNwJctsFnz9Kynh5D14KxWcTwN/BcGgsjVzHY532zziVh6l
T+5Bi1vKsLQR5IvMtTWX56iS2kQlIuWWf175PNMdf9fCTqi90Ms9+3ecOHMipdBW/lzqA9Av
UGG/vP6zg2PsAWPSFYeqhFCekA58VRgdhhcR1LNVxW+qlVvR10W0uMribLSpMMgo5+bMBvrV
Wa5LSMkJJP+uGv3pRJjnHHaijPgm44tbR/mPXwrL850qSNzcNq2gF5tRNax2mpNyLoRWmMuw
MACJkNFn0wEZYYSZWYGc6QMDCCNWgP2SeZxJiRfPBWbQ4mMqX/5CdFHHVcSZjgUFH5wjdjA5
4LEznVjQfUYfD1xw868AHkBCd31e1Fr2WB++TnQxjw8qq+9RUaY0ns8jLK7TAN6NZQVxg1MU
yxw/V6iC7rBpP0VQsHaPflHWS0hGZKuauN55arTOoGboSuZeiFA6RHa01pbc4fZQ80w4Zsk6
1YpP9xwE46aC+gY4GovhBK0lucb6upFeMtpd3KrWHRfC265TUyfDomz1KwsG9mbxhHb8PHqT
qb5P8KGJO5E4L2Rl10okCXvuOxDg8lW5665gFzfG491jQxTrnIoMp/1pcBbDfccs+nv8sYFG
jjiYNEkP2GAO5hDtZcmoVleEl5nUCvoNfinDcEUCZD2Yqd3weAAShpTDo4SN9VKBzEW9FeEM
Amyastzizpoxcr5IYV7J5jmHKHOZ28nGF44iUedn+yu78a/TYAD6jBtGgW9sZJ7fcWL6FoJH
FC3mQV4/u/a8hiGhM3KrvSQ09t+1yKvTWHFdV2RD2Iltj5HmxtbSS7gSkjzKv0EDzGi032NZ
X+f7s9FDoqhIbAk2vhc/1ThG6gs/5CJHS0WX7wC4Ty46sQt7fUCMW17a5DtF900TAvw+B2AO
0XiQyl8Et29aFk5d0YW+kpn9Z/s75b6pRwAPZAYLS9N9GPkBVav3x+17eAtIxRT9MDa/ED8F
snhMCxSsdZ/4UNBG5q4Ib1gAMtG5anASqOiws7EiJQcFed0wUGD6TZN4mQrS2RZzcZSqsFv9
Vb8obJLSkCegW+7Rif68lUrXo09rij+whz4YZdINNkkinHRRcS5Xyrhn84c94gDjeR7wHAjI
DnZcU7m5Fi8KC3G3xSr/pt9Xttf5LUBGl60X3qgxkikqY5AIv1LQsUDcbDL9kJr3AEFZCOZJ
DnBrsL8l+tztAFrSNizHadGuQekniSkxQhJANlR4kTcefjrVlH7c7c/e/X1qiYUTW8tTAk2m
KpTKjnRQZOWR/e973jO5uHuZ1JCAwL29Ws8J67vqF6WFUw019zo6IEo7YShPDbF0a4Kct1ZN
/pT+zybHnsk5skzqV+cqOUwj3KJl8CD4f7MNlcwMveIAEjX5zS2M/eURV3YJhhd23vCy0+lB
D9MTg4tEpUWLnenF2GyIQS7GUlO2+7m0/JEKqyDl3OpuBCEDDOFv/3H5c8O295sFl/Cs7F7X
Ntr0hGQyHqsct2NnWKr06sFrPNCrYaDsibfNz8yMVI2ueRUHhMTqTnWtJECyip+0G0KJBtSz
JCc4XKQ7kmARNS9EKIy7jo8zkA60lei5PFH+Ws0etLijvR+U9Aam4zn1EBbycCPj31IDVYTx
USHWXp6bbKKDzbfQStzlbFonJGQ7bnoR25yR5GUXDR68gW4wrqLvOLKe2nA26CBhnCGJDAa0
avth+hcjpxIvplfTZHUxTX20JhLFixh/jDoTGhrAuOwLocVuBGSXrK6OAofpwUCUoPjJtGqR
pmNkTcklzNKXLnk/qATDR3Wax7qlkbvtEpkijouUROM8v93fKzDStvW7Zz45GNEsaj+FpgfM
AUuIW70161RdJYnsP/e1ER0yXI0ODvGFXBT7jI9yDmgOZFGc7N3KU7/l4qS6qm9PL8OvV1J2
G+iWkdJBpDyrCGCtKTCyNaDJSYmdB/TO2JqAZkys8p2lKYimXq7b1WYxKIszRfiv5jWDSXdH
HB+6kZ+xOSsBihOVTs8TaTcfmizb1tDoT6loTi+E9dKTW/OoF5jlG/Xwt3DkLIABeiS4rcWl
GjRaWldQFbTaYmM7BL+ZuNsWJDVybvyCl/g384KyGByhQhExbL5OpdFBEU2m2tzedk59WjaH
Q7vl+P2nkS0Mwjh5L6ws+D1wVqLHKRvFoOH67VpSCThWfteUiVe5TonaNhcVFpEB8YQq5Npi
jJOUMGEm0Qx11Zx0l0lUdlR7zhU+9n1tJwH3Gk688imeuB8RcaraIeObgkGRXjsFiQfYY9Xh
efGYMGbXgtjfJ40IQpYcOC+lfjh/TO/jpgoFmGzXRI7/tCI8sgE+vmntePBepFRqPML/A8nn
UtXMaiJBaGFbBzLb8SlgGzaM9AtNU0cmRokT8K04RrPwVU2QtXqVrQqZZBaYb5Si7w13RsXc
XRuZu3X3oPTPZfcLtDXQYEe7Qw48B6jf70dngm4ivzk9bVP94XLhHAILvgCQkP2pMR0BPNti
alg7baxiVHmwZ/HkLpE6Y5jHuo0TBaIOmAGVynl182rATD4uXRAbyONNKcQbMz4L8g/+2O7K
vGYLMsB/kYi+9v0Wf6eTqqaIePMuN3DCp/tc2iKLgjqvucZd6EouRIDv2bMCCr0Tg0p7GfVh
2NWfloKnXtiv5Gh3VlSnF0imN8KZuWZRQ5zBuZQBqWSGZI1RBf+FNdnDEjqTbQ6d88lggmHm
/jLhfy3ZfL4DokA/tbOOqJ051gHos80scOGnejb294tEop8OIyy/ydd1rPMWyzYscoARjtkp
ibuXXvNbeDLEziRAc9UqoH2HiOXgl8WpECNyk0Ip5mgfZsR6h+mgf+OA3tw7OEZeYq/8JSAC
gSCAS66qfpPJ3c5aTn3+SfV1LpoEgl48146tYkvY0L0mS+JqJ4Fwwn4d/40jlR22LE8szWvL
A/tX0B/t4xrw5y2QZPAJgU3dv66e8wvorTKuRHxYBxiMh6Ll7oQveiJfhYbCfCUFxsvFnuI4
1lB4fsfN+V/AnB8B8g+ikVUMDaWYiiNybVOD9TI86VTGnmakCqyOQBlbLFso4smu5NSTPZTS
Xy3EORnTrkb8i4e2bWECjuKndu6yLh694jTQv5fLuMbBmyBnKTjEHtRt2ObRiC1JB6/P1Lg6
u3ZJ2lexBlV23+ozsnA1AP7Guwp1+V7POsra51jKmH7SUFDGl4MTZqvYPgOsehj4pCpLJdWg
WK7vrPY/7wyQy0C2FhNTXZUzV3ZNfxaQaWxNJ3jiTB9r1Gls8lUczCQqSSqeIzOjwuqy2AY7
PbdWV9ytQY+DHCr4totj6xUZ7G7lp0/yLkiKc3W7rkAPR3TvBnDvZHTyQO5CAwc4qdlGJMSK
pfsq/pniKqLWq3d4PI4+f6FJE/ph/YlYmETsiN+Bo1k7LZLMsWF8UHwbmGcGOSemgLqx6wUJ
cV0i4JpfvhDiww51+XVZ9xB8J5Ft920XmnZRLEhY4iUN6oBvK3iFKM8mxWWVEJZ8Ithgj19l
VFJV0mhJTYDnKl20WzP6Lc9HPDH3BBhIo2ev9lCX2U8D2M6a5/3Ekixb7thv0PoszIY/aBNK
aO5tQu0wYYA8WewtAFM+BzcEbdVfVWqIPEEvlTJ1NvBGQqwRrLQaOSXqNXM7Q4WnJ4aSx9tA
N9ZXhVj+J/Bieh6JMmSpdIYy5zPD8ANjwwkKHaInkLPWakmzvP/iZObxY3Si/+zBuzs7SShi
SteLx2bOvWsdr9M8oOb1cmjzs5/MssDQ5hEw4BW6HN8LdU9p7Avzv1TregUK2Ul3S9AJO+DF
kKvXSUFW0cuJHtXU0jo5qYgg+RMaGTcN66iwpoM/bz91xzJDw1MWoNN+DsdvnhMe0R8gguH5
iLNWj6oj4Kmc5TEJwaG7T2YeN+qUEGUAniyCOSXKLikWN6SvC3KY1q595gxsTTW5xjGYvy2L
IEzKRqg9S+dUm/LhSKTXAIVEYrSVE1JjYH6CO4XaeJexATeTVg6HlPCvpZInEnUBsNqnPAdW
dL4F1c1dduVdMqm51Ux4tgLCNqRUfCiCyT9dTox3rqHJUGTPDxAwx+OHmKA8ViNyfPlGb2g0
8J1jRT0QfJIwdqv19ByPakaBVAwAIxvkRpD4RDtOxYZctSp06L04DosOHzsRYj0kO1yuq6pd
Vmy6vl4YV3R7Xd8oUiSefLeopr/Di6wWRt8IAVb06KBo7SaQi2xdBX3LGM3yw10ozu2DR3MT
Bv6ETd/uJE4tpNWwkdOfD9pnA30tFbJnJE6U3U8c1hs6EF46F4HMa3Y3gVKQiBkmZPEX70b6
cSjjUoMS+AvpVdcIopeqmSO1kvEjvOa+0WG2TaU7pMvyeSZ3rRmyYM4UPySW1LqDyKL0XdS+
R66FgA33FMTITnlMTxGDdKUQ8Iu2U0xo3oHsEaIJGklb/VkNBDCo0k5hieK4a873qWI4khLR
gBrdzSGYEoPv5xrlrSJ+vps2YsEHex+2Y5/UT0Di/1VKmumMRvxuZzMhCQOQjJ5TU5OoXI/s
VWR/3piHu+0sTGikhL/o9ey4Lm2pcPf/4dJu5oF0ioYe2HXrBuT0j3ut0FLjTqSVW46Kr5uu
WMLZufjSKxWMD8oNHFzhZDHv8un42Q0eumpoacpxt90d9LbcOwAfKsW5hjGh6EMX5CV3EGe0
D9fPArJimrujEe2JFxMeE2nbtvnnzi2aoGYwd5dZ83ZAz636Go03FBGUn+GtTu/m9hBoHogR
AjIRZdlXHW7o05SPO/ysY6QUPdb+P55e1faVjsju+/NLPakk+hXTfTxaZDgTcdCHiW7psbxr
ouZ9VWLHZ1tmGHSep565yBeOd/uJXnxFs6uI6kVlqeef0X7HVWt3OQaF5IH+nx99zf7FIkxo
MIwV1ap6bhUHWsmySe1tN9M849unvrouRBqNzQKEdDrcbEMyZnkW7O+xRx2lZdOlRKefQOjh
Osk0oZdk6P1ydsuV6W2LskU4FxZbDfa5g6DYbqU17eG5gyTXXXLjhNWhh4qklzjYjzPmW60h
CQdab/TWwnbTzHJncSfIP/duNwbVH+T4lePJEewdaMyVB3oOgkbIvoF568cXIwD1Zr7ZZHu8
V2bra1xSmETcoGVQqeRct80J0OqSiuCHW8eZXmpokVDnfRWNCujukK5htsN3NIHObGXrKMKo
9UcKUhpRkzlwe+1/+Gok/bewBkOfMSWuLa9vTL7KhBKHdGn3QmF27CqwuR11RJoGyce0B+id
CG3ssFK5U0H9GiJLSeloq3ojPGudFwbyEcgBYGP5J1kWNYQU3HC9IKOGcgAK9TSxqoxZIbn5
DpwFpbef1XS+uQ/JAa1fH7MUl18726pVUCTaiV656Mub3lphZVTVTmiOb8G5XzRwolYzWmdD
JAqmkpGitrIXvXoW+SIIK9wQi9xKPo6O7ZJ9rP3wMG8nVfMdBpdK3EfMj2shHLeSMvTCKmyc
GGD6v1HERynIQiJQY0Ex0zK4DPR4GkJnXkGVVsMTDB6SScYUcbloprvnbt2ABtZbGQPQ3WOl
zCWGMG7/5DoXeYefJHeg/GjBqHXg4JD09KRLcGhZ9VD5hm5bycg83YgARP7A08IBlvZxZs4c
WYQ4Zq+E/wUJo/C4NhmTlEACLUrIx4Ii+/OtRw4CaBi9fG1F5bDt3EC92G9oErtA5tGE6tLK
lwElzP5poZEO2JhFh8Jb95B0LWowNYe0lNhuJhTJgQ5Ki51mjhgjsvRszmebRDbbMkA3OQne
wtGPwpk+1ydCSvscBl708m/ukj00pc8jrDd7f1YudrWDojy7J1YQ+axXaHQgZmtI8YTOqL82
ji5HnMWvbRj8mrd5f6eem3evDwokqtjxHbYG2b0XgpAD1P+bIMPgt2ojFBSbVTNAGyYS6fER
5tG6NVZ0SGrRwfeGA1XMkyS9FRAvdupooqnT4GYQGWBHcZDo/taNg+ZJAdEVYAojkW1rPIs3
R+u2lcwlQb8xdVPX4roqnFZz+VArFPcpbJ3W4T3/UQG2PuPS2N7Arqo7uNHiIiTcbscJSRse
SeayHg3TomR9YW1k5vCn47sxNTvKse9Pez/SUMpRIAv6dF5731OINQGSLJDLQrVBluzuth85
GYyaIj5KDrCf2kpyx+N0+GqCMqbwh21PjGbFl79ju6YZd+ofcymG4g6O6M35EXVsdsBZ6BuY
jdIDpaI0B6jknjWDsQR/ETVoWV8zWxamxUwZPCA0T9tkbLuajXcyIK8OSdNnZ2s21Q1NacGD
QWRfa00b5Wa3V4Go7dkI5zEEBRMc2vgx3YGZCSXI2GybFqwJ2LyDsOJqOj0ag3cQaCaHrwSo
zedKgErLafetkcsxgFpFj87o1tzrDtBq0eeA2AuVHy2JlAuslflvDG/fAgXaCsIS/PqjGa7Q
oPhsEKQPraIEu1vIM3lyaAzHu09CEpc3USAfue9GY1hBAdvlWddNcIKQlNu/ip2H4sWRoaIY
eby/kNi4ZdyslxCplKkYqkg1pupKcOOevCbcMw3ClcxfeokbV5aSPeaf0/C2WnFwhEH3j7Ty
NC5/EflfyhjdpACW6CFG9NX0pMt4grL4cVe9elQIQNdOYSIkTpXVqilFJ/gghL+HUcmdQCU+
ivqCmbtgRAZQM47I5D7ZRaLoNdBseo74Fvz0dqd/74UYcKL7eb10/EUc5VqseLMtm+JgdNlS
nRScA6YjZm7cIqBNJ3zzx1VW0fOTrzkhGlsFNogza78p5/xI6OnUGMwOCVaqq1De/ms726HD
pWyBwAyM+m+i6CVQIHnP2O6bGbDPtZ3uK7+S7fgRk+9Ky6r/ZfUaeMoSCL/hVRmEWgQ+GoKC
HdPeHf1HRpWHXMSmjL26iaS42PhCBmL8wrZija4wGk2qKi6M5NI+Y7RAfd6zSJrp1W6DD4JU
fmxXdFoeiHYMRBUngEaSoIU5iECAMbxlnLUUOEUSB0AJVO6RxiuETQJXgZACf5av48TaZSIM
tguBkA0soCSo1Uu1EtdKoMVGSKso0clRWRjxbRGwpOoGbhAntUEWleUKiqTS6sf24Q53TKR/
4Pfc9vWn7Qz7y5oatxdMi1zICLAaMiYMFvfjdLkvGEf/XlQoC7vCmEJgVZc63sibhpNVnAYv
EaOqnIfVdtPUW6y/GG9pWSZ657uhZwdz08Jd1yY+fFmM4bm9SLN0XEEcNCvLqErW3WjV+F0N
58w+5p8qv1Xi8aBAXHE3oisOUfMUgqPugcCgE+qqMS7IAPur4p5cC7oXi6iSEOc6VNhUE9p4
5ul5e2EbIrrENbaVpW27JUPw3z8ElgK4b21tTj+LdvhcGdxfczHMyxEwQXkX6gt8TgdotPGc
aAdXgv2wxG2LIdCxRJFvjOlq8dAQZVhnnUkhkBsKlVih2NBd6XhbgdwOwh8DQw5+qzJmBFuq
gwrrZH8NkZPH2Em3NIexEdtDAnfG8kj4oe8u4UCoke63N8vZR6bl7G/CCtkV5yZMD0/a4ntm
ctqPGorD2br/WYzM3MHLeYA8RFIq1bzeSGumqm5tXW+IQZZJgyXFlS1Cxv/QZw0HGenBAD23
jCElSGyP5oudqh7muGqxtQIwkAjwOXLhEwbmrUdK38cB0VkVNF3W0Y3/KwoF8VqN/OhCNvkk
GlPztvGwYjD8x0ZNhivII8dCJm13eU8qfgHwil4INjEaeDlW4ePsaXv5xYkhojtossR4euGD
hV2VBYc83in837INe877j9Yurnh/ElBNpQz4umOousoZFUnd7oLjecLV1pvmMnMzT62k5Wcs
1XLGTWpqIVZF8G3TsMOFD2WzlsjMarMAeqFUu7xVAZ0pGz0HiSTMAPvtm52iLYE2aOQSFcL9
80Hz3nXxMgJPdpcSlhoNloC1U4tDmlYdm9cOJD7eC5OQdrd4isuGJetVuaE/8FWZZh9nJwfi
o0XfGUbPv73iSykn35Upy1Fq0FhxDBO8MBwrBmbIH6T4B5e6kdgLd5MgttpA3A17hPjItMJX
E6PTn6pUXEmsryHXBYzBL3Kc/sx4hhOZUJbxJeOLgx9orBowaN766FyQNY4vYMPlRieRDDlD
Mv3qiS2KmeUJw/vxa5Qa3YGTpFUFVIoT0g2cq/XBbOuG+DRBK3agNReSTSxfpqpmUq0M/R8m
kI0dgEwtWXrgfIIQCFlapvBisdQRSCE25jUceZhv1qGAbNRi9Cc2HwR4G87FnPr4Nb5Etnv3
yWPv7kTHJdGBAUVdyLuUECGG8x/bwANGuznIWsMBsJhXepAQlAJssgGT+XX6x20q2qiCswtu
HH5eLfVZMM9PaV9/GByk7CiH9aTz0zKrO6H5J61+Ym+a8wbiz5K5RfVtIcMpbfVXIdDVO77x
B7Cs5zZqU3ZC1zirQSFQxLD47Pv+uINt1QPJLo0Z49alCbO0OgkxGdr92u3/PmmGjlSLgsfR
70TzW3c+UM/WMagpIcHCCjQwiIbSvU7ekahZziE58UGWmniM2RAFAm/h4OSsXpATgOE6OIQK
jIveJZJet+UX+9QdvT/6/qts1zHWEuxQmu7sPBV4A45R0M9z40IxgubUHqY0/CATvUgODRBX
WnKGoCX0Vy16+FwSNis7BALolVKfOXGrYV0v8hdVcTgO89ydg5uuItaBZhaBdNwBCTxmRsCQ
6D23UDEkW6UD0MP0bOZ4XnmSgR545KT8qFJVw1BMxlVvTgizIvAZUuiyiDqy7af0/+3otFn9
0anC/2PFR5Q+IEdnvMY5WbpkFiEQn283fwdajhkf/oDt9d5+CWpzn/TFU5FdWBASjsR2adsc
JMQjr0qs+5P6Z+JzL1BO92DjcYIfrwWxgMzMLs7fNFbaqrBHafMw4LaV+b1J5v07i29LkEQ1
YFXIOIMHImdKQ56vyeuIql0WgtpxAqVMxUeGqcUMJyhOBAw0w9N6aG1hUZc86ksTO3kkiJwk
qSaOhty8gYNAmoMds232gDkH1hkFaziWVnSR/Us4s2b3ltL08F5t6fnANT3TrHw3HII5a8xC
4Vg3sEYTwxtDkhb3KhsXrNFIQrzJ+YxkBW9foRGubn84oA2GdwIPTRIlKjqM6BntHtl2K8GS
CdpOtgVCUQO3z4E0V83MRG2TrzKUCBptaKX0d95yHGeJ5rOj+z18BTIKVyMDjjiP26jduICm
P6zYnLCFe9ic/laC6o6nn02ZF8YAXRbyYkj2fExxcUclLiqo/04ym1V4HMi5Jqs7rMEEhS0D
HRowP522/XjVqpGwO4OLAwvX4Avl9gQNbt1/FtHFxo58pHu9i3pCEw/Ra3K/WmWFpkwqJKYT
HtyOYIhD0KO0iby6EpA3CgcMqQKY+/qZPknMHPAjm+FM3iCQfrNyV4BmZcaCmSJN8uBt/klS
ldbIQlETYr3GSl8mq2DJEvbXWm42+cdymQS8vJDrghPpnespApTgQRMVNxVYGGWYDvq1yItJ
dKh0DHWe9kz3akUnLwM8Q6FJtJFBu3l88x2Aq290bEL7dnW2Z2OYPHI4V63qO/9bb5nAwQTO
qmwUSdsBpAb2krPRP0Swsc1CB2F5YyOD75MdxZU+AZ+4EJqh3KJhLgioe/TX7PKdV6K6I7rX
dBPyHHs2/yyv11iK2lQXNp3VW+nFgY/BX8lm1XTUfSDePvaWTjESAwW2p9T3gGeiYC0IMZ6F
FgoCtKkOWGfbNZ8DEWLk+GQS/w21gXztjFEUgH2ZGiUrKSBvsBQdDppIvrFy78qwz/FbO2+h
77O/6coge/jwNQ9hFfWP2Un7gz/ZkmmSVGhsP94hOxzMUI/fH5cfqhoVp9MlbQVPHNVHwosq
6EsYWA7fhiYh96fMvuGLJckA8HEYE9uwB/jFmMl5lj0byNK1XAOe2zVbWhg+Jw7xUzYa4QZd
6znqvI3//R1eQjD2G/0QbR8gvBvzcxnRsgJwhzUIHWhZbDOeLcx+iNRfmR0ItzQ6DjV8xdQo
uVj2nAQqlxaf0b61SGWANyrboujxAJ7EdjANcP7PjfSog1TaHtw/Jpu7sCCNQSu9rSYnD9s/
vfh/PACe/xpFDB0pehmA4FyBZugoq9YT4CDA8vAPnfcVNvP80+ZTzQea8g8AKXEuizjPVcQG
YnUNYVm6+r27MrYqgEjTQzxPgHAbgeT9JY59BM19SLS5x+PlWn2/HO3uPDtevsm8T7B3J5W2
nVyYyDBp729Y9/uvskyt6dALQEVjgyu/UeC/KAW4sRWIDh2/8m2uFlT+ukIZtpc2z657xIZc
tyRczp5mQBndxQb2+b9BdYAsjCUeDAxqRJkyg1Vn9d8dFNcU12ENM1F8LZKnv8zpvrVKEZAV
l1KNrCtLXrN5rur2VoCaqS26t+2wWEmB1xEFISk9LC0XmdSrLCe4Cbt623VXHrQyIeTgV456
HzQommQov0aeIOnmlq5pUNti8W+p5trRQmgcCSxVuR8yc/cV685AGNfEVOAoPK4u8uzRgXFs
1zaKAol/bEGg2OHXHO95uMZctqI6fdexFFyAH73BzHZn+W9odvf3TNRDgp/2MvrhgrHBxHv1
RnuiGoBGK87UPaLQi3MMAjhUoqF/5Pc536BbXgI8eOKiK2vdy/C366IH9ZzBUDQAAqnhYYrj
mrc8LkU8Mu4IqbWZ43BkjyNwyD3FIuWuFXyEhN+kFz36G9BQmGJDJxzCvoPobH53dqZdxumz
/JIeMGuNVK+jHfhK0WFaN7DCKQj7LU3ULzwb8gNQlQVvTS2d+dN4LhEfKQKRsGIleQrcMezv
uvHvhfC2kidMLsfYE1kdDuApfkBoWmVervfbvlYWes2r/Wv2WVAbYvD4rb+pVJQ7MPlO1KW7
C0mK5j/gx95ZwZhmx5L8xPRZfOvNU22tWpbtWmr+XK07vbMJm/mk0UOKLymoDtIKZo9vPzQE
d0I3Lcm9iexzxdmcfWT0KVQ7gzD2QIHsdsy244sbrfPgUJbbe6LdzQ+HVM3iaGN3V7WAViq3
1Lfv9MqsDbat2b5eGhvbS57de6XvABBKY+vJFa9XIpdXkC3ZTkMBgVHit6KGhY/2enj3zB0b
0DcRdujO+JwzEQaSm1N3e/pXtZ/gC2L7v1p5ruwMgsZan82F11gqEziyonBhsCVgf4T4Yefn
PYO4JtIXCD7imJGN6c4bfgKY5Mx/tFP37DhL4sLpXw+dV+iO9DMa+R3IuVPgzqQAoUs8Ocjr
eic3+NRCJLb17P2rpD5zS/CVx+ZHbKAngJqK4BD2yfoSHEOjcmVMrJek/2ONaLznRiMD0BFf
EZBTwlrgRjbYqIQS6OJa00c5IS5nkZY194Iq+mRikNi/uehSzFLRFHmfCSlwaaSGfxS7N+Iv
HFWGcGIs5Ilvrl/iqVUo0F4xIMg/Y2XXcPvqS56VK49DuRld3WewIvaJy9XgHg2eqnfRSdxT
6fOGTHJCe4/MDXijmL/80ILwtH2fXocn7y179ZGkvaW9d6LY4kyUs25T8f7NN2ese6kZLKNG
W5Oe73RkZE0vUxQAHz+nbj42hDLrIjDG0bgbaHsELNGhuHn5M3zkbkNMUXD8CvX7/7UQiOG8
VP5UiaR42+eHBTME2PYfenJwPA1AP9L3Gitvy97OIahStZmvPuFXD2g1AxLFUB9iZZcz9shi
bRwiDlejAGbAtDCZRL8pZOR6mfIB3+AAYXzaRzjt69muh8wmU5znpPHWmq/kc+wWTgCWs/cQ
zkRe8mlEIVXHo1NftDzNdvvKi0roflOi9UsmzwLWg8X6DtTklSZjD74k3PpFNK6kbyNj1joW
/h145NMrwCCuX7e+Vi4+eBFhybcwvd/O2ZKcNi3k5d9ltigVW9tMrwYq/ITweiWZxOirfuFs
4nTBfhp4rj2k1Sj+JxH7UmX/OZqqVb5t1pnYObVLLFbZmNH2GV0eldda0G6GFAFtaTOFolh0
hGDtZCPYPVYZHHdB+gHQoXyllof5+bGE59P8Mdyjy+wux8nvzoI+HG16+Ib3pH290nXgmXze
XDYM2VJw0enUEkG5hWA8kUhZtfPv/5foyx2q3Nmyko9ODjp+FzWb8iik1gJfLL6hsdDBJRtZ
V+qigsrYyq5+JqTpG6a6EPkTrSpRhze0mmAgh2/3PGXehJT/VUpBLKb8zy9nUhDXdIOAXa+G
9JzUGIcfgWeEO3EF2UIyrbsq/XA43ri6mxSEycifefIslL71ASQOqrVR0MMaRDZaoFUqfbNA
GKeDnQBnzY2CzCS6iQ135EecCiWrrvF2++FkJcmYxehIkimT1tC8Yrjm5nf90zCU96C16dF3
0rph1YUh68pp5mrxYqJrsORlAUnuFaEljTZjK7GgXzcdfKtZxg+WFPN+1UeOgq95Jqnh03os
nu60b9N2KOtNyQsdk3rL0fEsNax+6nkdvN7gjQ9KaDALzy8618tXl7aCz/wPp5g9BxpywZgo
ZzRy7R+jMkNp7kMZRulbCi8k+VYLUe/mZw7NNNyvd72HlHqp8kLsvi9oNhlnwuiJ+xqR1NdP
gNmVEXQnXNxPcvkx9XTdZCjvl66n2tyUvL9e302cWy0BE4QwwTlv8A/0FoEWkguJLbQp0UUd
nUZwC5MeAn4pdo+89HGPxecsR18ChK+YBQg7Gl+xgRckeh6bakuBsnD3K9JYIy8I810YXrrT
MMajVeLNHjzXzwBIaOWK/AVZ7uL5gjcliZyq/C205IJcOVfcq2gXf3HxDkXwx7VCU5P7MCXv
fi6VrUULul/eFY3WoDjsUm1gohAa7Gpa2fx9glrnnKniOtbJfDWpd+PoUjgE/SKHuCTdx7Qr
eogaH6RzAxPoN9Fk+osfUEsFYnrWu7dVGHFqKk9TqdFoYoJ4FyhPkFcSMZQ7bpFZtAtM5t5S
CwfHzDozJKvZpIZsxE2Sd4RKUl9DQN/W07Z5AESRQGdzD9GseEsfq0KixSa7IbRZE4jNPxkU
VNDcsi207Ls8fSCuJth/caXVxp+GQj2YKGVt2xPYPxpMn9mvBrjUQGyBV77+ZqGiX7rnpjNq
iNpfJWw4SMiFtq547mP8wCRdqdOl9ZxMYnd43fMQWNsAZaF5vspM8YZzlrKAeBNEbFV87kHg
c6/cybloC49qbJUjSpf6X/OxBg4OZcGEJ19IOVLzzeVw5QkVsxrsD8fK6JD9AdTvoGEISIIm
P257MX2WR573xXtf2IGK5Y5Bt5d5m/m6qF6CxwE/wYD16wyqtUMUTcE4bZJExCL0GoSUKxOT
3wTZutcV4iEK4B1hcz0Hc2BmPgO55qaW4/HIE6flTPqI2IrcNsZ9aVxDyMxP0a383KbzxoH1
/i1S4dte2ya4Q1wHI0A2bFVN2hTqEXCOaMZEtkGYxmnPwe8kIt/+pyHqvpcv/QPS6mMWwGuR
380w34NAy2R9Do3iDX4yY+DazUjE5cdko3UqLnvsAw2NhYXIw3gsqz9Wrgfp+OHYbnAkQQHC
r9YXFdUwtKh99Mw3OMHvomASnHEgxDyzaXtRDSyyJQq7qAqKn9D4fbx4hQJ9xjBVJ8vFjDWq
mM5nF3mVn8VmJzit53ptynBGjpZAbcGMedU6At5KSuGtRJdk+6NCnGx8/2pDb0oiRqCNUHsa
NfiQJwAVi4I54kZWObA+v58VGEDWayxvXwCTmGAWYIYP3FmHkMjtsadBYCe8LwHIhFlJH+kK
b8RCfkYgg3LFoXsHgo7zAKOXPvrVMr4AKCNuKR0Ty3P/zH7AotFHg/iSGuMLv0md03evZeZK
uC115IgHbQckoXwtZhPbPrM9Q1iCV8JpmN0O6kdTbnEu17IS2sWbNjAbsYfR3xOMNTSW9LGu
r8/vIReBw19OJSQI9F4pbvMdp/CpDH4StoTejUYUjyBbwD+iE/siqtUcXuh898a05mMnQMJn
XETvrHkwL+FA4IMHvtcYhfc+V5qO8ZVTWUiG6hPy1hCmtibhzO3/dK1ZI4LKrYeE8vRvFjNy
35Z+wApi/0O/s8JazE6ayp7ePLbBvpx/Y/+qXZvRqKcvHBNpecbr2oMQ+An1iSJYQERKgM3O
JErZiWWU6rH+KVP1C0nWz7pQR6pO770mrieNgUqw78bAe+8uPVXt+bSItKi8X7JfKfaprR7b
4m5yzQrBt46z9LOx/t1BMJqVuSjijgk8UnhvrNVqoj7tw4+pdiIHS6TpV5Z+CQkp99aMA5EY
jen1DfA35y0E2lpXSCRb7u8GQwYvnQeYkowLd5YJdOLHIR/ejDHWUNejPxf2puOnNd25yvEV
sd2LGkHmmpmg687Go8lPtzoMTY3+YV/TA5P7zNC8n6KMADKUBO4DE4rg9D6s3r7FATO/Rm8M
2BBxD8dsTzwT0KsMaolYu3E/2WJxTsDM2xG2PIrm0MFCPsMO0a3VsdaBiTnuUCAanTUQqRao
d2KPsu/8/dNnl0D0SOa8ERTonp0J3dmibkYYAjYLUsc8YV+dd3LKtf4spAAjAdwGPSAOh9gO
aS8mrQdM6ugWc/6NkoZS/ElprxCZJpbQWSfnSEF1tELmc3I8z2EteEoxhlsQ92UvGs4Ba7EF
2m/LzbyuQcykjlOEKXichs+RVufE1yghCMjOCrZfyEJ+sgnL5T7jmo3ugDrzE68AMyUPwbSY
t2GVZmqOrk5hhct9G6BeEPlKxGmXjfZTr+5g9XoZjCQDa5Y4rcy2wGGrJOP1zfh20mGOJWJK
eJrtWErPqE0l+ZBgxE5Idys+u4yLlB3B0B2kIVEaF0+FXWPA+1EV+SEnip/lSvCS0ojejky9
jXa49wnVYqEj0u0HvDlQIa7mzwhPdA8QpxdlYnIPdu/Bkm3lOPhqymqw26EZHhzndRo925Kh
JNC7XXdhNZW5RQmZvyhi6jo3s41GvX6u1pe1ugaUJnzGg+rc06IKu7SWd1D5ij6XBf9pV5SL
BCn1olboNiyMLhGGVsdmx3YvTI/OUzVr963GEwoib7HGYVWzdqCYYy+YlCvuG7LktajLW6Cb
mAKtBWhqeJz77hZzOUYJPAKt+RjWMT3eZ41AJLqM08sm8SWg/lhw+uv+P+f4K31ttpCuHh4k
xHmlu69Axt8sgiW3LnJJRv/yvrv2iNI5fUuFlMnTguKr6WsuzPwFXFwBf5EcwfNWM64GQ69F
OBkPYlnJv9qa/130hodMhnXTZGN/ZfFPyT6qMyuuIOshCVkdzhgANm2+M5Pn7NQlsD0WVL76
PQ+e0IzbbtB/gdnqHUf4EwRKqP6S4Nc583HwRhIEHTXmsrVjCl3itIjtsmonJydYBnyMwkB0
T/YN9fxiCqWBPlyhdiIWAKiwFCvrsXaOeNVOzStUjcBG5K8TDNJ7ajWNBJ8x5FdJ3bJL5WWU
nlKtnv3u1JUN7IjQvSTjbdomMKtqwDkWX6/dTpYrry0MD1I16hS6fGew3AXTlnreE5+YcUtH
E/ClPLAHxqZskHcgO7B9F2b0BMsSpMJKT7GgTPVnuUeFz39D2tICtDi6Mce7FOAz9OS4Uqwk
0W13srbzVXSkreMp08JNGsjQjoM0qY3R+1QL/NFgJrPTnFFejnCfk+lHVj2Cg+yehMYB/99s
Xg8b9+FCOxM/3CAxIery5xFmJL/BXsq4AvuzChj3awfuy+t8ZNjTT1TsR9kzSlkWmcUzsiH9
0l+NjmibotLk3YDMp62rsGrX0gq6C5vmIMQP47PDloV6mdheV+mf6EGw29UgYVH5GKBxGwz3
/DNXT9+SPNyyE+L65pV7CnHEj/lc0KBbfOt64a9A0SSFUsTKev/cOyL9M09K2Cs87kAmnedk
RdbFX8ewFWVPsEMXDk2IBUPPmWm4CfGz6UvZ/4GCcrohRHKsqifY4XXlhnDR8psdz+t0/wKU
2gbHnSHre+vGjwp2g2SPJmbTpK/QzkqSJIAXRXiUs5B/M1KCis7kWQxputC74DEmowEoIxcD
fpmxvrTd6RAhGWGZCLGc6iC6xAGPtPYyc/uqyc5uLjBvyl0r6PVrqvXHfPAhtzIoJM+B1r93
rFKsTFmoTxQQqrSb9KkwKGjmSVFHtTf+vOd/0u2bvgVlSN8KiLVt0H0r/4Xk9pE9sYVAdHUT
I9rxvX+o7xs5jXXgGprQn+E7Aqea1IS8Msf2Fov02oTHZWtfXCcUsWfpmL4i+d021rXUHqht
ACVXtjY9OXW/VjrbjVEveG8fqVaq82/LNTdWg7vVxXGGcLWCRlcvtxiwSvoNIcbRtJZ4knuv
6YaGMCAz8ODeDte96dpEoy2LOK43DAym/6oujgG8YkfyXZNohTQjByqXTCHW75PyWuT+byu+
RU63gl0sJiggPhnSBi/INXiQEPiSr3A2AMkMQXBBTLXczQcXpQoQFXRM8x/Nvmz85uQIvT90
9qkVbwXLirqaT8vQSIca96jseEQ8w8A7DmRxSRu6k1XU9m146FPxrEMl/Kj23t4B+pu18e9N
XEaiO45Wgy9IXbpyCgUXoaCkIR7wSXrczsFBPItRuV4cP70cVWnH4629/FAkK0DRBWsJeUda
lL+QuGeMt1rf7Jp7QNSSXTtVRuVk2QboagBxMfwA/G4pct3Ys1rDdsihZPrZE1qhEN1zD3de
kTfAb/InucNpyvG1ooMI35pXqI6C8SOy7f5BtsNqA8ehYbeqhcL95fBIKExgEn58KqTCTFAY
YgoI7iSz9/pDqHGgUQpLtJtstg3AjzJoh5XKqKfsrUCLhIWT18RMO2go/zkviC6qRiyomROH
2a4MQg4pK51JGv8fxk+/mMgIjOmExsRIyQhN0K/rs10p9SFKr0Qu3A0OD+KNJqEiEWwtr4yS
LmIcNfIZUSTXa7UEHlhPgLMTQzslqCZN19H23tsin3CRitIVbL8yX6y7iTZCRVxxIhdSCHka
tJq7GIqD/m4bwdN/jFh/J659P0DF+NlwH0yXxQGIol2zZ+XRSb9BH5upWVMOeuEqbvGso7vf
ZOPL6Fje4gXOijRAwxSGVlMhtuPq4Iu6Zn0xGeVZxqIUzevWPBOGAysb3fDAT51J5jiV8q6O
+v35wml6iz/0rFxzpP3WAPfrx/hC3iIAy4j1sUK8sYOeVmQY1CWAZJtHIRWLSafeaCgmcCBA
zXSscnoZygusFlbEyQLvdBNiv2OjPy84bjoaqxJxdr8jhhXaPMShSSNQWD77stn9TdoOTYxB
VK9kejox0AVbk2arj8LEl/Yxar1ZTeVW9LbY9aG/aOjnf2vSDjnu4RcGO81urlIkuC8xcDtx
lKomWUatITqDpfbzEJlAgqk0geJYsgBmmxo20nmGLy/nr7FTPPuPctYfxvl8Qnf/3jYVIXan
JZEFpz5vE2T4bN9ZpFPQvQoF9UvtYPrw2h/U8yoFpAKG958k3vRsR+zp4RSOzUGTjXUpxZrJ
DIdeISUOd2DyXt/5ioTki9yvWZYFVK12bFlfOWFUAtH9euYvIgXeNZLiEFBLAQIUAAoAAQAA
AEBwhjDfcwnH3FEAANBRAAAJAAAAAAAAAAEAIAAAAAAAAABxaWtscS5leGVQSwUGAAAAAAEA
AQA3AAAAA1IAAAAA

----------cbnvrxpisgnveqcnyyno--


From karsten@excalibur.cologne.de Tue Apr  6 19:26:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Apr 2004 19:26:14 +0100 (BST)
Received: from natsmtp00.rzone.de ([IPv6:::ffff:81.169.145.165]:63932 "EHLO
	natsmtp00.webmailer.de") by linux-mips.org with ESMTP
	id <S8224941AbUDFS0O>; Tue, 6 Apr 2004 19:26:14 +0100
Received: from excalibur.cologne.de (p50851417.dip.t-dialin.net [80.133.20.23])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i36IQBvZ009914
	for <linux-mips@linux-mips.org>; Tue, 6 Apr 2004 20:26:12 +0200 (MEST)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 1BAusp-0003Mv-00
	for <linux-mips@linux-mips.org>; Tue, 06 Apr 2004 20:01:11 +0200
Date: Tue, 6 Apr 2004 20:01:10 +0200
From: Karsten Merker <karsten@excalibur.cologne.de>
To: linux-mips@linux-mips.org
Subject: SB1250 build currently broken in 2.4
Message-ID: <20040406180110.GA4650@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4744
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1083
Lines: 30

Hallo everybody,

I have tried building a kernel for a Broadcom SB1250 board from current
cvs (2.4 branch) with defconfig-sb1250-swarm. This fails with:

mips-linux-ld -m elf32btsmip  -r -o kernel.o branch.o cpu-probe.o irq.o
process.o signal.o entry.o traps.o ptrace.o reset.o semaphore.o setup.o
syscall.o sysmips.o ipc.o scall_o32.o unaligned.o mips_ksyms.o r4k_fpu.o
r4k_switch.o smp.o time.o proc.o pci-dma.o
smp.o(.kstrtab+0x48): multiple definition of __kstrtab_cpu_data'
setup.o(.kstrtab+0x0): first defined here
smp.o(__ksymtab+0x20): multiple definition of __ksymtab_cpu_data'
setup.o(__ksymtab+0x0): first defined here
make[1]: *** [kernel.o] Error 1
make[1]: Leaving directory /tmp/linux/arch/mips/kernel'
make: *** [_dir_arch/mips/kernel] Error 2

It looks like the line

EXPORT_SYMBOL(cpu_data);

in arch/mips/kernel/smp.c should not be there.

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

From brm@murphy.dk Tue Apr  6 20:56:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Apr 2004 20:56:51 +0100 (BST)
Received: from [IPv6:::ffff:217.157.140.228] ([IPv6:::ffff:217.157.140.228]:9547
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225827AbUDFT4u>; Tue, 6 Apr 2004 20:56:50 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 1BAwgW-0000IJ-00; Tue, 06 Apr 2004 21:56:36 +0200
To: ralf@linux-mips.org
Cc: brian@murphy.dk, linux-mips@linux-mips.org
Message-Id: <E1BAwgW-0000IJ-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Tue, 06 Apr 2004 21:56:36 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4745
Subject: (no subject)
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 1192
Lines: 31

Hi Ralf,
	the arbitrary change of lasat machine numbers in revision 1.70 
of bootinfo.h means the lasat machines don't get very far in the boot
process. I use this number as an index into several arrays to dynamically
set up the minor hardware differences between the two machines, 
it being off by one causes a horrible crash the first time one of the 
values is used.

Was there a good reason for the change or can you apply the following patch
to allow these systems to boot...?

/Brian

Index: include/asm-mips/bootinfo.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/bootinfo.h,v
retrieving revision 1.73
diff -u -r1.73 bootinfo.h
--- include/asm-mips/bootinfo.h	15 Mar 2004 07:55:26 -0000	1.73
+++ include/asm-mips/bootinfo.h	6 Apr 2004 19:46:13 -0000
@@ -200,8 +200,8 @@
  * Valid machtype for group LASAT
  */
 #define MACH_GROUP_LASAT       21
-#define  MACH_LASAT_100		1	/* Masquerade II/SP100/SP50/SP25 */
-#define  MACH_LASAT_200		2	/* Masquerade PRO/SP200 */
+#define  MACH_LASAT_100		0	/* Masquerade II/SP100/SP50/SP25 */
+#define  MACH_LASAT_200		1	/* Masquerade PRO/SP200 */
 
 /*
  * Valid machtype for group TITAN

From thomas.koeller@baslerweb.com Wed Apr  7 17:12:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Apr 2004 17:12:32 +0100 (BST)
Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:13324
	"EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP
	id <S8225426AbUDGQMb>; Wed, 7 Apr 2004 17:12:31 +0100
Received: from comm1.baslerweb.com ([172.16.13.2]) by proxy.baslerweb.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35)
          with ESMTP id com; Wed, 7 Apr 2004 18:12:12 +0200
Received: from [172.16.13.253] (localhost [172.16.13.253]) by comm1.baslerweb.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id H8ZDRHZ3; Wed, 7 Apr 2004 18:12:29 +0200
From: Thomas Koeller <thomas.koeller@baslerweb.com>
Organization: Basler AG
To: linux-mips@linux-mips.org
Subject: Re: titan ethernet driver
Date: Wed, 7 Apr 2004 18:14:02 +0200
User-Agent: KMail/1.6.1
Cc: Ralf Baechle <ralf@linux-mips.org>, lachwani@pmc-sierra.com
References: <200403261512.06502.thomas.koeller@baslerweb.com> <20040326212001.GA4927@linux-mips.org>
In-Reply-To: <20040326212001.GA4927@linux-mips.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200404071814.02477.thomas.koeller@baslerweb.com>
Return-Path: <thomas.koeller@baslerweb.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4747
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thomas.koeller@baslerweb.com
Precedence: bulk
X-list: linux-mips
Content-Length: 583
Lines: 22

Ralf Baechle wrote:

> I'm going to fix Yosemite / Titan support in 2.6 asap - as soon as I get
> the board which should be somewhen next week.

Hi Ralf,

Manish told me (off this list) that he submitted his revised PMC-Sierra
Yosemite stuff to you. Will it be available from CVS any time soon? If
at all possible, don't delay this, I am waiting impatiently...

tk
-- 
--------------------------------------------------

Thomas Koeller, Software Development
Basler Vision Technologies

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

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

From brm@murphy.dk Wed Apr  7 20:24:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Apr 2004 20:24:30 +0100 (BST)
Received: from [IPv6:::ffff:217.157.140.228] ([IPv6:::ffff:217.157.140.228]:50251
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225438AbUDGTY3>; Wed, 7 Apr 2004 20:24:29 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 1BBIer-00009h-00; Wed, 07 Apr 2004 21:24:21 +0200
To: ralf@mips-linux.org
Subject: [PATCH 2.5] LASAT bootinfo machine number reversion
Cc: linux-mips@linux-mips.org
Message-Id: <E1BBIer-00009h-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Wed, 07 Apr 2004 21:24:21 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4748
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 1247
Lines: 32

Hi Ralf,
	Missed the subject the last time, so here it is again.
The arbitrary change of lasat machine numbers in revision 1.70 
of bootinfo.h means the lasat machines don't get very far in the boot
process. I use this number as an index into several arrays to dynamically
set up the minor hardware differences between the two machines, 
it being off by one causes a horrible crash the first time one of the 
values is used.

Was there a good reason for the change or can you apply the following patch
to allow these systems to boot...?

/Brian

Index: include/asm-mips/bootinfo.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/bootinfo.h,v
retrieving revision 1.73
diff -u -r1.73 bootinfo.h
--- include/asm-mips/bootinfo.h	15 Mar 2004 07:55:26 -0000	1.73
+++ include/asm-mips/bootinfo.h	6 Apr 2004 19:46:13 -0000
@@ -200,8 +200,8 @@
  * Valid machtype for group LASAT
  */
 #define MACH_GROUP_LASAT       21
-#define  MACH_LASAT_100		1	/* Masquerade II/SP100/SP50/SP25 */
-#define  MACH_LASAT_200		2	/* Masquerade PRO/SP200 */
+#define  MACH_LASAT_100		0	/* Masquerade II/SP100/SP50/SP25 */
+#define  MACH_LASAT_200		1	/* Masquerade PRO/SP200 */
 
 /*
  * Valid machtype for group TITAN

From brm@murphy.dk Wed Apr  7 22:34:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Apr 2004 22:34:13 +0100 (BST)
Received: from [IPv6:::ffff:217.157.140.228] ([IPv6:::ffff:217.157.140.228]:2380
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225456AbUDGVeM>; Wed, 7 Apr 2004 22:34:12 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 1BBKgO-0001W0-00; Wed, 07 Apr 2004 23:34:05 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.5] LASAT updates
Cc: linux-mips@linux-mips.org
Message-Id: <E1BBKgO-0001W0-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Wed, 07 Apr 2004 23:34:05 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4749
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 11090
Lines: 365

Hi Ralf,
	this patch includes various cleanups and re-impliments pci support
for the Lasat platforms. It includes the machinfo patch I sent before.
It also includes a patch to allow an ethernet device to have irq 0 on 
lasat platforms. I have tried many times to get the network folk to accept
a patch but they don't even reply. Interrupt 0 is a very valid interrupt
for a pci device (255 means undefined) but on a pc 0 is always taken
by the timer so most bioses seem to be broken and set an undefined pci
interrupt to 0 and not to 255. Drivers such as pcnet impliment accordingly.
Anyway since there are CONFIG_LASAT hacks in pcnet32.c already it
should not be a big problem to have one more ;).

I found that I needed to set MAX_HWIFS to 2 in 
include/asm-mips/mach-generic/ide.h
The ide drivers take forever to time out the probe for the other 16 devices
which don't exist on a Lasat board. Is there an official way to disable this 
probing? Setting MAX_HWIFS does not seem possible except by hacking in this 
file.

With this patch the Lasat machines seem to have a reasonably stable 2.6.4
support (although crashme can create a process which cannot die without
a reset).
Thanks for the hard work guys - the last time I looked at 2.5 support it
barely booted.

/Brian

Index: arch/mips/lasat/Makefile
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- arch/mips/lasat/Makefile	19 Oct 2003 21:08:57 -0000	1.9
+++ arch/mips/lasat/Makefile	29 Oct 2003 18:10:07 -0000
@@ -7,7 +7,6 @@
 
 obj-$(CONFIG_LASAT_SYSCTL)	+= sysctl.o
 obj-$(CONFIG_DS1603)		+= ds1603.o
-obj-$(CONFIG_PCI)		+= pci.o
 obj-$(CONFIG_PICVUE)		+= picvue.o
 obj-$(CONFIG_PICVUE_PROC)	+= picvue_proc.o
 
Index: arch/mips/lasat/interrupt.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/interrupt.c,v
retrieving revision 1.9
diff -u -r1.9 interrupt.c
--- arch/mips/lasat/interrupt.c	18 Nov 2003 01:17:46 -0000	1.9
+++ arch/mips/lasat/interrupt.c	6 Apr 2004 20:57:35 -0000
@@ -33,7 +33,7 @@
 static volatile int *lasat_int_mask = NULL;
 static volatile int lasat_int_mask_shift;
 
-extern asmlinkage void mipsIRQ(void);
+extern asmlinkage void lasatIRQ(void);
 
 void disable_lasat_irq(unsigned int irq_nr)
 {
@@ -141,7 +141,6 @@
 		*lasat_int_mask = 0;
 		break;
 	case MACH_LASAT_200:
-		printk("**** MACH_LASAT_200 interrupt routines\n");
 		lasat_int_status = (void *)LASAT_INT_STATUS_REG_200;
 		lasat_int_mask = (void *)LASAT_INT_MASK_REG_200;
 		lasat_int_mask_shift = LASATINT_MASK_SHIFT_200;
@@ -153,7 +152,7 @@
 	}
 
 	/* Now safe to set the exception vector. */
-	set_except_vector(0, mipsIRQ);
+	set_except_vector(0, lasatIRQ);
 
 	for (i = 0; i <= LASATINT_END; i++) {
 		irq_desc[i].status	= IRQ_DISABLED;
Index: arch/mips/lasat/lasatIRQ.S
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/lasatIRQ.S,v
retrieving revision 1.4
diff -u -r1.4 lasatIRQ.S
--- arch/mips/lasat/lasatIRQ.S	18 Nov 2003 01:17:46 -0000	1.4
+++ arch/mips/lasat/lasatIRQ.S	26 Jan 2004 17:20:16 -0000
@@ -24,12 +24,13 @@
 
 	.text
 	.set	noreorder
-	.set	noat
 	.align	5
-	NESTED(mipsIRQ, PT_SIZE, sp)
+	NESTED(lasatIRQ, PT_SIZE, sp)
+	.set	noat
 	SAVE_ALL
 	CLI
 	.set	at
+	.set	noreorder
 
 	mfc0	s0, CP0_CAUSE		# get irq mask
 
@@ -39,9 +40,9 @@
 	 andi	a0, s0, CAUSEF_IP2	# delay slot, check hw0 interrupt
 
 	/* Wheee, a timer interrupt. */
-	move	a0, sp
-	jal	lasat_timer_interrupt
-	 nop
+	li	a0, 7
+	jal	ll_timer_interrupt
+	 move	a1, sp
 
 	j	ret_from_irq
 	 nop
@@ -65,4 +66,4 @@
 
 	j	ret_from_irq
 	 nop
-	END(mipsIRQ)
+	END(lasatIRQ)
Index: arch/mips/lasat/setup.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/setup.c,v
retrieving revision 1.12
diff -u -r1.12 setup.c
--- arch/mips/lasat/setup.c	28 Jan 2004 22:16:39 -0000	1.12
+++ arch/mips/lasat/setup.c	5 Apr 2004 22:00:10 -0000
@@ -44,7 +44,6 @@
 #endif
 
 #include "ds1603.h"
-#include "at93c.h"
 #include <asm/lasat/ds1603.h>
 #include <asm/lasat/picvue.h>
 #include <asm/lasat/eeprom.h>
@@ -126,12 +125,6 @@
 	change_c0_status(ST0_IM, IE_IRQ0 | IE_IRQ5);
 }
 
-#define MIPS_CPU_TIMER_IRQ 7
-asmlinkage void lasat_timer_interrupt(struct pt_regs *regs)
-{
-	ll_timer_interrupt(MIPS_CPU_TIMER_IRQ, regs);
-}
-
 #define DYNAMIC_SERIAL_INIT
 #ifdef DYNAMIC_SERIAL_INIT
 void __init serial_init(void)
Index: arch/mips/lasat/image/Makefile
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/image/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- arch/mips/lasat/image/Makefile	22 Jun 2003 02:19:24 -0000	1.6
+++ arch/mips/lasat/image/Makefile	30 Jan 2004 11:30:13 -0000
@@ -18,14 +18,15 @@
 
 LDSCRIPT= -L$(obj) -Tromscript.normal
 
-AFLAGS_head.o += -D_kernel_start=0x$(KERNEL_START) \
+HEAD_DEFINES := -D_kernel_start=0x$(KERNEL_START) \
 		-D_kernel_entry=0x$(KERNEL_ENTRY) \
 		-D VERSION="\"$(Version)\"" \
 		-D TIMESTAMP=$(shell date +%s) 
 
-head.o: $(KERNEL_IMAGE)
+$(obj)/head.o: $(obj)/head.S $(KERNEL_IMAGE)
+	$(CC) -fno-pic $(HEAD_DEFINES) -I$(TOPDIR)/include -c -o $@ $<
 
-obj-y = head.o kImage.o
+OBJECTS = head.o kImage.o
 
 rom.sw:	$(obj)/rom.sw
 
@@ -36,7 +37,7 @@
 	$(OBJCOPY) -O binary -S $^ $@
 
 # Rule to make the bootloader
-$(obj)/rom: $(addprefix $(obj)/,$(obj-y))
+$(obj)/rom: $(addprefix $(obj)/,$(OBJECTS))
 	$(LD) $(LDFLAGS) $(LDSCRIPT) -o $@ $^
 
 $(obj)/%.o: $(obj)/%.gz
Index: arch/mips/pci/Makefile
===================================================================
RCS file: /cvs/linux/arch/mips/pci/Makefile,v
retrieving revision 1.13
diff -u -r1.13 Makefile
--- arch/mips/pci/Makefile	17 Mar 2004 17:24:38 -0000	1.13
+++ arch/mips/pci/Makefile	23 Mar 2004 21:23:01 -0000
@@ -24,6 +24,7 @@
 obj-$(CONFIG_DDB5476)		+= ops-ddb5476.o pci-ddb5476.o
 obj-$(CONFIG_DDB5477)		+= fixup-ddb5477.o pci-ddb5477.o ops-ddb5477.o
 obj-$(CONFIG_HP_LASERJET)	+= pci-hplj.o
+obj-$(CONFIG_LASAT)		+= pci-lasat.o fixup-lasat.o
 obj-$(CONFIG_MIPS_ATLAS)	+= fixup-atlas.o
 obj-$(CONFIG_MIPS_COBALT)	+= fixup-cobalt.o
 obj-$(CONFIG_MIPS_EV96100)	+= fixup-ev64120.o
Index: drivers/net/pcnet32.c
===================================================================
RCS file: /cvs/linux/drivers/net/pcnet32.c,v
retrieving revision 1.59
diff -u -r1.59 pcnet32.c
--- drivers/net/pcnet32.c	11 Mar 2004 16:46:51 -0000	1.59
+++ drivers/net/pcnet32.c	7 Apr 2004 19:56:05 -0000
@@ -1144,7 +1144,10 @@
     int i;
     int rc;
 
-    if (dev->irq == 0 ||
+    if (
+#ifndef CONFIG_LASAT
+        dev->irq == 0 ||
+#endif
 	request_irq(dev->irq, &pcnet32_interrupt,
 		    lp->shared_irq ? SA_SHIRQ : 0, lp->name, (void *)dev)) {
 	return -EAGAIN;
Index: include/asm-mips/bootinfo.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/bootinfo.h,v
retrieving revision 1.73
diff -u -r1.73 bootinfo.h
--- include/asm-mips/bootinfo.h	15 Mar 2004 07:55:26 -0000	1.73
+++ include/asm-mips/bootinfo.h	6 Apr 2004 19:46:13 -0000
@@ -200,8 +200,8 @@
  * Valid machtype for group LASAT
  */
 #define MACH_GROUP_LASAT       21
-#define  MACH_LASAT_100		1	/* Masquerade II/SP100/SP50/SP25 */
-#define  MACH_LASAT_200		2	/* Masquerade PRO/SP200 */
+#define  MACH_LASAT_100		0	/* Masquerade II/SP100/SP50/SP25 */
+#define  MACH_LASAT_200		1	/* Masquerade PRO/SP200 */
 
 /*
  * Valid machtype for group TITAN
--- /dev/null	2003-04-09 22:42:25.000000000 +0200
+++ arch/mips/pci/fixup-lasat.c	2003-11-17 20:37:45.000000000 +0100
@@ -0,0 +1,10 @@
+#include <linux/init.h>
+#include <linux/pci.h>
+
+void __init pcibios_fixup_irqs(void)
+{
+}
+
+struct pci_fixup pcibios_fixups[] __initdata = {
+    { 0 }
+};
--- /dev/null	2003-04-09 22:42:25.000000000 +0200
+++ arch/mips/pci/pci-lasat.c	2004-04-06 23:32:57.000000000 +0200
@@ -0,0 +1,89 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2000, 2001 Keith M Wesolowski
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/pci.h>
+#include <linux/types.h>
+#include <linux/interrupt.h>
+#include <linux/pci.h>
+#include <asm/pci_channel.h>
+#include <linux/delay.h>
+#include <asm/bootinfo.h>
+
+extern struct pci_ops nile4_pci_ops;
+extern struct pci_ops gt64120_pci_ops;
+static struct resource lasat_pci_mem_resource = {
+	.name	= "LASAT PCI MEM",
+	.start	= 0x18000000,
+	.end	= 0x19FFFFFF,
+	.flags	= IORESOURCE_MEM,
+};
+
+static struct resource lasat_pci_io_resource = {
+	.name	= "LASAT PCI IO",
+	.start	= 0x1a000000,
+	.end	= 0x1bFFFFFF,
+	.flags	= IORESOURCE_IO,
+};
+
+static struct pci_controller lasat_pci_controller = {
+	.mem_resource	= &lasat_pci_mem_resource,
+	.io_resource	= &lasat_pci_io_resource,
+};
+
+static int __init lasat_pci_setup(void)
+{
+ 	printk("PCI: starting\n");
+
+        switch (mips_machtype) {
+            case MACH_LASAT_100:
+                lasat_pci_controller.pci_ops = &gt64120_pci_ops;
+                break;
+            case MACH_LASAT_200:
+                lasat_pci_controller.pci_ops = &nile4_pci_ops;
+                break;
+            default:
+                panic("pcibios_init: mips_machtype incorrect");
+        }
+
+	register_pci_controller(&lasat_pci_controller);
+        return 0;
+}
+early_initcall(lasat_pci_setup);
+
+#define LASATINT_ETH1   0
+#define LASATINT_ETH0   1
+#define LASATINT_HDC    2
+#define LASATINT_COMP   3
+#define LASATINT_HDLC   4
+#define LASATINT_PCIA   5
+#define LASATINT_PCIB   6
+#define LASATINT_PCIC   7
+#define LASATINT_PCID   8
+int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
+{
+    switch (slot) {
+        case 1:
+            return LASATINT_PCIA;   /* Expansion Module 0 */
+        case 2:
+            return LASATINT_PCIB;   /* Expansion Module 1 */
+        case 3:
+            return LASATINT_PCIC;   /* Expansion Module 2 */
+        case 4:
+            return LASATINT_ETH1;   /* Ethernet 1 (LAN 2) */
+        case 5:
+            return LASATINT_ETH0;   /* Ethernet 0 (LAN 1) */
+        case 6:
+            return LASATINT_HDC;    /* IDE controller */
+        default:
+            return 0xff;            /* Illegal */
+    }
+
+    return -1;
+}
--- arch/mips/lasat/pci.c	2004-04-07 23:09:38.000000000 +0200
+++ /dev/null	2003-04-09 22:42:25.000000000 +0200
@@ -1,25 +0,0 @@
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/pci.h>
-#include <asm/bootinfo.h>
-
-extern struct pci_ops nile4_pci_ops;
-extern struct pci_ops gt64120_pci_ops;
-
-void __init pcibios_init(void)
-{
-	struct pci_ops *pci_ops;
-
-	switch (mips_machtype) {
-	case MACH_LASAT_100:
-		pci_ops = &gt64120_pci_ops;
-		break;
-	case MACH_LASAT_200:
-		pci_ops = &nile4_pci_ops;
-		break;
-	default:
-		panic("pcibios_init: mips_machtype incorrect");
-	}
-
-	pci_scan_bus(0, pci_ops, NULL);
-}

From brm@murphy.dk Wed Apr  7 22:38:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Apr 2004 22:38:33 +0100 (BST)
Received: from [IPv6:::ffff:217.157.140.228] ([IPv6:::ffff:217.157.140.228]:2892
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225459AbUDGVic>; Wed, 7 Apr 2004 22:38:32 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 1BBKkc-0001WY-00; Wed, 07 Apr 2004 23:38:26 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.4] LASAT updates
Cc: linux-mips@linux-mips.org
Message-Id: <E1BBKkc-0001WY-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Wed, 07 Apr 2004 23:38:26 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4750
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 1081
Lines: 38

Hi Ralf, 
	this is a small patch to make the Lasat rom image build again
after some LDFLAGS changes which broke it.

/Brian

Index: arch/mips/lasat/image/Makefile
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/image/Makefile,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 Makefile
--- arch/mips/lasat/image/Makefile	24 Feb 2003 21:26:19 -0000	1.1.2.3
+++ arch/mips/lasat/image/Makefile	30 Jan 2004 11:30:03 -0000
@@ -24,12 +24,13 @@
 
 LDSCRIPT= -Tromscript.normal
 
-AFLAGS_head.o = -D_kernel_start=0x$(KERNEL_START) \
+HEAD_DEFINES = -D_kernel_start=0x$(KERNEL_START) \
 		-D_kernel_entry=0x$(KERNEL_ENTRY) \
 		-D VERSION="\"$(Version)\"" \
 		-D TIMESTAMP=$(shell date +%s) 
 
-head.o: $(KERNEL_IMAGE)
+head.o: head.S $(KERNEL_IMAGE)
+	$(CC) -fno-pic $(HEAD_DEFINES) -I$(TOPDIR)/include -c -o $@ $<
 
 OBJECTS= head.o kImage.o
 
@@ -44,7 +45,7 @@
 	$(LD) $(LDFLAGS) $(LDSCRIPT) -o rom $(OBJECTS) 
 
 %.o: %.gz
-	$(LD) -r -o $@ -b binary $<
+	$(LD) $(LDFLAGS) -r -o $@ -b binary $<
 
 %.gz: %.bin
 	gzip -cf -9 $< > $@

From mcetra@navynet.it Mon Apr 12 05:58:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Apr 2004 05:58:50 +0100 (BST)
Received: from [IPv6:::ffff:213.188.213.77] ([IPv6:::ffff:213.188.213.77]:39324
	"EHLO server1.navynet.it") by linux-mips.org with ESMTP
	id <S8225766AbUDLE6s>; Mon, 12 Apr 2004 05:58:48 +0100
Received: from localhost (server1 [127.0.0.1])
	by server1.navynet.it (Postfix) with ESMTP id A831F84008
	for <linux-mips@linux-mips.org>; Mon, 12 Apr 2004 06:58:39 +0200 (CEST)
Received: from server1.navynet.it ([127.0.0.1])
 by localhost (server1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 17933-05 for <linux-mips@linux-mips.org>;
 Mon, 12 Apr 2004 06:58:37 +0200 (CEST)
Received: from guendalin (host12-150.pool8175.interbusiness.it [81.75.150.12])
	by server1.navynet.it (Postfix) with ESMTP id CFC7B84029
	for <linux-mips@linux-mips.org>; Mon, 12 Apr 2004 06:58:23 +0200 (CEST)
From: "Massimo Cetra" <mcetra@navynet.it>
To: <linux-mips@linux-mips.org>
Subject: Raq2 & 2.6.4 : Strange output fro msomewhere
Date: Mon, 12 Apr 2004 06:58:20 +0100
Message-ID: <000301c42053$2ae67fe0$e60a0a0a@guendalin>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Virus-Scanned: by amavisd-new-20030616-p3 (Navynet) at navynet.it
Return-Path: <mcetra@navynet.it>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4751
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mcetra@navynet.it
Precedence: bulk
X-list: linux-mips
Content-Length: 834
Lines: 32

Hi!

(i'm new here).
I have managed to compile CVS kernels for 2.6.4 and 2.4.25 trees on my
Raq2... And they work great.

Now...
Under heavy load (generating kernel_headers debian package), i saw the
following:

-cobalt:/proc# uptime
Unknown HZ value! (79) Assume 100.
 06:54:27 up 14 min,  2 users,  load average: 1.77, 1.37, 0.69
cobalt:/proc# sar 2 2
Linux 2.6.4 (cobalt)    04/12/04

06:54:32          CPU     %user     %nice   %system     %idle
06:54:34          all     18.31      0.00     81.69      0.00
06:54:36          all     16.67      0.00     83.33      0.00
Average:          all     17.60      0.00     82.40      0.00
cobalt:/proc# uname -a
Linux cobalt 2.6.4 #2 Mon Apr 12 05:50:49 CEST 2004 mips unknown
cobalt:/proc#


What is : "Unknown HZ value! (79) Assume 100." ????????????????????????

Thanks..

 Massimo



From kevink@mips.com Mon Apr 12 08:22:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Apr 2004 08:22:16 +0100 (BST)
Received: from mx.mips.com ([IPv6:::ffff:206.31.31.226]:51925 "EHLO
	mx.mips.com") by linux-mips.org with ESMTP id <S8225906AbUDLHWP>;
	Mon, 12 Apr 2004 08:22:15 +0100
Received: from mercury.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.12.11/8.12.11) with ESMTP id i3C7C2jQ015564;
	Mon, 12 Apr 2004 00:12:02 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by mercury.mips.com (8.12.11/8.12.11) with SMTP id i3C7M06L021171;
	Mon, 12 Apr 2004 00:22:01 -0700 (PDT)
Message-ID: <000501c4205f$2ef003c0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Massimo Cetra" <mcetra@navynet.it>, <linux-mips@linux-mips.org>
References: <000301c42053$2ae67fe0$e60a0a0a@guendalin>
Subject: Re: Raq2 & 2.6.4 : Strange output fro msomewhere
Date: Mon, 12 Apr 2004 09:24:21 +0200
Organization: MIPS Technologies Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Scanned-By: MIMEDefang 2.39
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: 4752
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1840
Lines: 56

I don't have the sources to "uptime" handy, but the concept of a "HZ" value
us something that goes back to AT&T UNIX, representing the number of
clock interrupts per second.  It was originally 60, as it was based on the 
wall current AC frequency in the US, but once 100 became a popular
value once people started having faster CPUs and stopped using their
power supplies to generate the signal.

Historically, it was a constant specified in some kernel/system header
file like "sys/param.h".

So I would tend to conclude that the uptime program does some kind 
of switch-driven computation based on the value of HZ it picks up (at
build time?), that the value for the Raq2 is 79, and that 79 isn't one
of the values recognized by the code.

----- Original Message ----- 
From: "Massimo Cetra" <mcetra@navynet.it>
To: <linux-mips@linux-mips.org>
Sent: Monday, April 12, 2004 7:58
Subject: Raq2 & 2.6.4 : Strange output fro msomewhere


> Hi!
> 
> (i'm new here).
> I have managed to compile CVS kernels for 2.6.4 and 2.4.25 trees on my
> Raq2... And they work great.
> 
> Now...
> Under heavy load (generating kernel_headers debian package), i saw the
> following:
> 
> -cobalt:/proc# uptime
> Unknown HZ value! (79) Assume 100.
>  06:54:27 up 14 min,  2 users,  load average: 1.77, 1.37, 0.69
> cobalt:/proc# sar 2 2
> Linux 2.6.4 (cobalt)    04/12/04
> 
> 06:54:32          CPU     %user     %nice   %system     %idle
> 06:54:34          all     18.31      0.00     81.69      0.00
> 06:54:36          all     16.67      0.00     83.33      0.00
> Average:          all     17.60      0.00     82.40      0.00
> cobalt:/proc# uname -a
> Linux cobalt 2.6.4 #2 Mon Apr 12 05:50:49 CEST 2004 mips unknown
> cobalt:/proc#
> 
> 
> What is : "Unknown HZ value! (79) Assume 100." ????????????????????????
> 
> Thanks..
> 
>  Massimo
> 
> 
> 
> 

From kumba@gentoo.org Mon Apr 12 08:52:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Apr 2004 08:52:52 +0100 (BST)
Received: from rwcrmhc11.comcast.net ([IPv6:::ffff:204.127.198.35]:48620 "EHLO
	rwcrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225914AbUDLHwv>; Mon, 12 Apr 2004 08:52:51 +0100
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (rwcrmhc11) with ESMTP
          id <2004041207524201300ff693e>
          (Authid: kumba12345);
          Mon, 12 Apr 2004 07:52:42 +0000
Message-ID: <407A4B01.5010701@gentoo.org>
Date: Mon, 12 Apr 2004 03:53:37 -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.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Raq2 & 2.6.4 : Strange output fro msomewhere
References: <000301c42053$2ae67fe0$e60a0a0a@guendalin>
In-Reply-To: <000301c42053$2ae67fe0$e60a0a0a@guendalin>
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: 4753
X-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
Content-Length: 1338
Lines: 43

Massimo Cetra wrote:

> Hi!
> 
> (i'm new here).
> I have managed to compile CVS kernels for 2.6.4 and 2.4.25 trees on my
> Raq2... And they work great.
> 
> Now...
> Under heavy load (generating kernel_headers debian package), i saw the
> following:
> 
> -cobalt:/proc# uptime
> Unknown HZ value! (79) Assume 100.
>  06:54:27 up 14 min,  2 users,  load average: 1.77, 1.37, 0.69
> cobalt:/proc# sar 2 2
> Linux 2.6.4 (cobalt)    04/12/04
> 
> 06:54:32          CPU     %user     %nice   %system     %idle
> 06:54:34          all     18.31      0.00     81.69      0.00
> 06:54:36          all     16.67      0.00     83.33      0.00
> Average:          all     17.60      0.00     82.40      0.00
> cobalt:/proc# uname -a
> Linux cobalt 2.6.4 #2 Mon Apr 12 05:50:49 CEST 2004 mips unknown
> cobalt:/proc#
> 
> 
> What is : "Unknown HZ value! (79) Assume 100." ????????????????????????
> 
> Thanks..

What does dmesg say your bogomips are?  There's a patch that fixes a 
small calculation error.  Without it, bogomips reports in at ~2,500, 
instead of 250.  Call it a guess, but if you missed that patch, that 
might be your bug.  Otherwise, I'm not too sure.


--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 flo@rfc822.org Mon Apr 12 16:54:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Apr 2004 16:54:14 +0100 (BST)
Received: from noose.gt.owl.de ([IPv6:::ffff:62.52.19.4]:25618 "EHLO
	noose.gt.owl.de") by linux-mips.org with ESMTP id <S8226077AbUDLPyM>;
	Mon, 12 Apr 2004 16:54:12 +0100
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 3745F25E8C; Mon, 12 Apr 2004 17:54:11 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 672AA24417F; Mon, 12 Apr 2004 17:54:06 +0200 (CEST)
Date: Mon, 12 Apr 2004 17:54:06 +0200
From: Florian Lohoff <flo@rfc822.org>
To: Massimo Cetra <mcetra@navynet.it>
Cc: linux-mips@linux-mips.org
Subject: Re: Raq2 & 2.6.4 : Strange output fro msomewhere
Message-ID: <20040412155406.GC2482@paradigm.rfc822.org>
References: <000301c42053$2ae67fe0$e60a0a0a@guendalin>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="0FWGRsEUTYx4i2U9"
Content-Disposition: inline
In-Reply-To: <000301c42053$2ae67fe0$e60a0a0a@guendalin>
Organization: rfc822 - pure communication
User-Agent: Mutt/1.5.4i
Return-Path: <flo@rfc822.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4754
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips
Content-Length: 870
Lines: 33


--0FWGRsEUTYx4i2U9
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 12, 2004 at 06:58:20AM +0100, Massimo Cetra wrote:
> -cobalt:/proc# uptime
> Unknown HZ value! (79) Assume 100.
>  06:54:27 up 14 min,  2 users,  load average: 1.77, 1.37, 0.69

IIRC this is a hint to upgrade your procps :)

2.6 from the Documentation/Changes requires at least 3.2.0

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

--0FWGRsEUTYx4i2U9
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAerueUaz2rXW+gJcRAoccAKCjuSejxKuWA64u9HyaetprYKHeGACgluTj
Vk+R8evUhTfdPBXFH6z9NIo=
=jY7r
-----END PGP SIGNATURE-----

--0FWGRsEUTYx4i2U9--

From sskowron@ET.PUT.Poznan.PL Mon Apr 12 17:30:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Apr 2004 17:30:29 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:61883
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226091AbUDLQa2>; Mon, 12 Apr 2004 17:30:28 +0100
Received: from athena (athena [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3CGUQD00661
	for <linux-mips@linux-mips.org>; Mon, 12 Apr 2004 18:30:26 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena (MailMonitor for SMTP v1.2.2 ) ;
	Mon, 12 Apr 2004 18:30:25 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3CGUPl28904
	for <linux-mips@linux-mips.org>; Mon, 12 Apr 2004 18:30:25 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Mon, 12 Apr 2004 18:30:25 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: XIO invalid access
Message-ID: <Pine.GSO.4.10.10404121821430.28412-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4755
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 611
Lines: 20

Hello!

I have a question: what happens on a XIO invalid access? I am looking at
the MGras MAIN_WIDGET space and sometimes the Octane just locks up. I
have captured all exceptions (I pass interrupts to the original PROM
handler) and an access to MAIN_WIDGET_BASE+00020104 causes a hang. The
reset button works, which is nothing special. But the power button works,
too, and that's something I don't really understand, as it is an
interrupt, too.

Do you know something more about XIO exception handling?

Thank you in advance,

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From sskowron@ET.PUT.Poznan.PL Mon Apr 12 21:51:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Apr 2004 21:51:20 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:6125 "EHLO
	europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225226AbUDLUvS>; Mon, 12 Apr 2004 21:51:18 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3CKpGf28591
	for <linux-mips@linux-mips.org>; Mon, 12 Apr 2004 22:51:16 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Mon, 12 Apr 2004 22:51:15 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3CKpDM09112
	for <linux-mips@linux-mips.org>; Mon, 12 Apr 2004 22:51:13 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Mon, 12 Apr 2004 22:51:13 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Work on IP30
Message-ID: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4756
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 981
Lines: 23

My Octane got as far as 'Calibrating delay loop... ' now. It works with
ARCS graphical console, which is a Good Thing. Memory identification is
correct. Caches work OK. I'm going to do the IRQs tomorrow, but I foresee
it will be really hard as there is no documentation for the HEART. Well,
we shall experiment.

Fortunately, the Octane has one really nice feature: the power button is
hooked up to an interrupt source. It may prove quite useful for debugging.

Interesting note: the ARCS console breaks when I change KSEG0 cache
coherence in the CP0_CONFIG register (in c-r4k.c). Of course, it breaks
sooner or later, not exactly afterwards, unless I flush cache exactly
after changing; it breaks immediately then. I don't give a hoot, because
IP30 has almost no RAM in KSEG0 and the kernel runs in XKPHYS, always
cached copy-on-write. But those of you with another machines might be
interested.

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From ralf@linux-mips.org Tue Apr 13 00:13:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 00:13:16 +0100 (BST)
Received: from p508B7906.dip.t-dialin.net ([IPv6:::ffff:80.139.121.6]:47730
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225507AbUDLXNQ>; Tue, 13 Apr 2004 00:13:16 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3CNDBxr004030;
	Tue, 13 Apr 2004 01:13:11 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3CND9lA004029;
	Tue, 13 Apr 2004 01:13:09 +0200
Date: Tue, 13 Apr 2004 01:13:09 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: Work on IP30
Message-ID: <20040412231309.GA702@linux-mips.org>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.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: 4757
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 777
Lines: 17

On Mon, Apr 12, 2004 at 10:51:13PM +0200, Stanislaw Skowronek wrote:

> Interesting note: the ARCS console breaks when I change KSEG0 cache
> coherence in the CP0_CONFIG register (in c-r4k.c). Of course, it breaks
> sooner or later, not exactly afterwards, unless I flush cache exactly
> after changing; it breaks immediately then. I don't give a hoot, because
> IP30 has almost no RAM in KSEG0 and the kernel runs in XKPHYS, always
> cached copy-on-write. But those of you with another machines might be
> interested.

Most firmware breaks at some point due to Linux fiddling with it's
resources.  What differs is how and when it breaks.  In case of IP27 the
first TLB flush for example is going to kill ARC.

And remember, it's written ARC but pronounced ARGGHHHH ;)

  Ralf

From brad@laronde.org Tue Apr 13 00:42:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 00:42:51 +0100 (BST)
Received: from ispmxmta06-srv.alltel.net ([IPv6:::ffff:166.102.165.167]:53164
	"EHLO ispmxmta06-srv.alltel.net") by linux-mips.org with ESMTP
	id <S8225263AbUDLXmu>; Tue, 13 Apr 2004 00:42:50 +0100
Received: from lahoo.priv ([162.39.1.206]) by ispmxmta06-srv.alltel.net
          with ESMTP
          id <20040412234237.FFXL22068.ispmxmta06-srv.alltel.net@lahoo.priv>
          for <linux-mips@linux-mips.org>; Mon, 12 Apr 2004 18:42:37 -0500
Received: from prefect.priv ([10.1.1.141] helo=prefect)
	by lahoo.priv with smtp (Exim 3.36 #1 (Debian))
	id 1BDAqU-0006kp-00
	for <linux-mips@linux-mips.org>; Mon, 12 Apr 2004 19:28:06 -0400
Message-ID: <03f301c420e7$d8de2d70$8d01010a@prefect>
From: "Bradley D. LaRonde" <brad@laronde.org>
To: <linux-mips@linux-mips.org>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl> <20040412231309.GA702@linux-mips.org>
Subject: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" in time.c
Date: Mon, 12 Apr 2004 19:42:41 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <brad@laronde.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: 4758
X-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@laronde.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1428
Lines: 45

This 2.4 patch look OK?

Regards,
Brad

diff -u -r1.1.1.1 time.c
--- arch/mips/kernel/time.c     10 Nov 2003 21:06:52 -0000      1.1.1.1
+++ arch/mips/kernel/time.c     12 Apr 2004 23:41:38 -0000
@@ -242,7 +242,7 @@
        __asm__("multu  %1,%2"
                : "=h" (res)
                : "r" (count), "r" (sll32_usecs_per_cycle)
-               : "lo", "accum");
+               : "lo", "hi");

        /*
         * Due to possible jiffies inconsistencies, we need to check
@@ -297,7 +297,7 @@
        __asm__("multu  %1,%2"
                : "=h" (res)
                : "r" (count), "r" (quotient)
-               : "lo", "accum");
+               : "lo", "hi");

        /*
         * Due to possible jiffies inconsistencies, we need to check
@@ -339,7 +339,7 @@
                                : "r" (timerhi), "m" (timerlo),
                                  "r" (tmp), "r" (USECS_PER_JIFFY),
                                  "r" (USECS_PER_JIFFY_FRAC)
-                               : "hi", "lo", "accum");
+                               : "hi", "lo", "hi");
                        cached_quotient = quotient;
                }
        }
@@ -353,7 +353,7 @@
        __asm__("multu  %1,%2"
                : "=h" (res)
                : "r" (count), "r" (quotient)
-               : "lo", "accum");
+               : "lo", "hi");

        /*
         * Due to possible jiffies inconsistencies, we need to check


From brad@laronde.org Tue Apr 13 01:53:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 01:53:06 +0100 (BST)
Received: from ispmxmta06-srv.alltel.net ([IPv6:::ffff:166.102.165.167]:48382
	"EHLO ispmxmta06-srv.alltel.net") by linux-mips.org with ESMTP
	id <S8225272AbUDMAxF>; Tue, 13 Apr 2004 01:53:05 +0100
Received: from lahoo.priv ([162.39.1.206]) by ispmxmta06-srv.alltel.net
          with ESMTP
          id <20040413005258.GOLV22068.ispmxmta06-srv.alltel.net@lahoo.priv>
          for <linux-mips@linux-mips.org>; Mon, 12 Apr 2004 19:52:58 -0500
Received: from prefect.priv ([10.1.1.141] helo=prefect)
	by lahoo.priv with smtp (Exim 3.36 #1 (Debian))
	id 1BDBwZ-00079x-00
	for <linux-mips@linux-mips.org>; Mon, 12 Apr 2004 20:38:27 -0400
Message-ID: <048e01c420f1$ad4ae3b0$8d01010a@prefect>
From: "Bradley D. LaRonde" <brad@laronde.org>
To: <linux-mips@linux-mips.org>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl> <20040412231309.GA702@linux-mips.org> <03f301c420e7$d8de2d70$8d01010a@prefect>
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" in time.c
Date: Mon, 12 Apr 2004 20:53:03 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <brad@laronde.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: 4759
X-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@laronde.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1918
Lines: 66

Uh oh, with this patch:

...
time.c: In function `fixed_rate_gettimeoffset':
time.c:242: error: can't find a register in class `HI_REG' while reloading
`asm'
...

Regards,
Brad

----- Original Message ----- 
From: "Bradley D. LaRonde" <brad@laronde.org>
To: <linux-mips@linux-mips.org>
Sent: Monday, April 12, 2004 7:42 PM
Subject: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" in time.c


> This 2.4 patch look OK?
>
> Regards,
> Brad
>
> diff -u -r1.1.1.1 time.c
> --- arch/mips/kernel/time.c     10 Nov 2003 21:06:52 -0000      1.1.1.1
> +++ arch/mips/kernel/time.c     12 Apr 2004 23:41:38 -0000
> @@ -242,7 +242,7 @@
>         __asm__("multu  %1,%2"
>                 : "=h" (res)
>                 : "r" (count), "r" (sll32_usecs_per_cycle)
> -               : "lo", "accum");
> +               : "lo", "hi");
>
>         /*
>          * Due to possible jiffies inconsistencies, we need to check
> @@ -297,7 +297,7 @@
>         __asm__("multu  %1,%2"
>                 : "=h" (res)
>                 : "r" (count), "r" (quotient)
> -               : "lo", "accum");
> +               : "lo", "hi");
>
>         /*
>          * Due to possible jiffies inconsistencies, we need to check
> @@ -339,7 +339,7 @@
>                                 : "r" (timerhi), "m" (timerlo),
>                                   "r" (tmp), "r" (USECS_PER_JIFFY),
>                                   "r" (USECS_PER_JIFFY_FRAC)
> -                               : "hi", "lo", "accum");
> +                               : "hi", "lo", "hi");
>                         cached_quotient = quotient;
>                 }
>         }
> @@ -353,7 +353,7 @@
>         __asm__("multu  %1,%2"
>                 : "=h" (res)
>                 : "r" (count), "r" (quotient)
> -               : "lo", "accum");
> +               : "lo", "hi");
>
>         /*
>          * Due to possible jiffies inconsistencies, we need to check
>
>
>


From echristo@redhat.com Tue Apr 13 02:02:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 02:02:14 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:29317 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225272AbUDMBCN>;
	Tue, 13 Apr 2004 02:02:13 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i3D122TM026708;
	Mon, 12 Apr 2004 21:02:02 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3D129M20455;
	Mon, 12 Apr 2004 21:02:09 -0400
Received: from [192.168.123.106] (vpn26-5.sfbay.redhat.com [172.16.26.5])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i3D128C01852;
	Mon, 12 Apr 2004 18:02:08 -0700
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" in
	time.c
From: Eric Christopher <echristo@redhat.com>
To: "Bradley D. LaRonde" <brad@laronde.org>
Cc: linux-mips@linux-mips.org
In-Reply-To: <048e01c420f1$ad4ae3b0$8d01010a@prefect>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl>
	 <20040412231309.GA702@linux-mips.org>
	 <03f301c420e7$d8de2d70$8d01010a@prefect>
	 <048e01c420f1$ad4ae3b0$8d01010a@prefect>
Content-Type: text/plain
Message-Id: <1081818125.19719.14.camel@dzur.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Mon, 12 Apr 2004 18:02:08 -0700
Content-Transfer-Encoding: 7bit
X-RedHat-Spam-Score: 0 
Return-Path: <echristo@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: 4760
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 849
Lines: 28

On Mon, 2004-04-12 at 17:53, Bradley D. LaRonde wrote:
> Uh oh, with this patch:
> 
> ...
> time.c: In function `fixed_rate_gettimeoffset':
> time.c:242: error: can't find a register in class `HI_REG' while reloading
> `asm'
> ...

> >
> >         /*
> >          * Due to possible jiffies inconsistencies, we need to check
> > @@ -339,7 +339,7 @@
> >                                 : "r" (timerhi), "m" (timerlo),
> >                                   "r" (tmp), "r" (USECS_PER_JIFFY),
> >                                   "r" (USECS_PER_JIFFY_FRAC)
> > -                               : "hi", "lo", "accum");
> > +                               : "hi", "lo", "hi");
> >                         cached_quotient = quotient;


Maybe this hunk where you use "hi" twice for the same asm statement?

-eric

-- 
Eric Christopher <echristo@redhat.com>


From brad@laronde.org Tue Apr 13 02:05:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 02:05:41 +0100 (BST)
Received: from ispmxmta09-srv.alltel.net ([IPv6:::ffff:166.102.165.170]:18645
	"EHLO ispmxmta09-srv.alltel.net") by linux-mips.org with ESMTP
	id <S8225272AbUDMBFj>; Tue, 13 Apr 2004 02:05:39 +0100
Received: from lahoo.priv ([162.39.1.206]) by ispmxmta09-srv.alltel.net
          with ESMTP
          id <20040413010529.DUVQ2984.ispmxmta09-srv.alltel.net@lahoo.priv>;
          Mon, 12 Apr 2004 20:05:29 -0500
Received: from prefect.priv ([10.1.1.141] helo=prefect)
	by lahoo.priv with smtp (Exim 3.36 #1 (Debian))
	id 1BDC8f-0007BB-00; Mon, 12 Apr 2004 20:50:57 -0400
Message-ID: <04d501c420f3$6c836a30$8d01010a@prefect>
From: "Bradley D. LaRonde" <brad@laronde.org>
To: <linux-mips@linux-mips.org>,
	"Eric Christopher" <echristo@redhat.com>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl> <20040412231309.GA702@linux-mips.org> <03f301c420e7$d8de2d70$8d01010a@prefect> <048e01c420f1$ad4ae3b0$8d01010a@prefect> <1081818125.19719.14.camel@dzur.sfbay.redhat.com>
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" intime.c
Date: Mon, 12 Apr 2004 21:05:34 -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@laronde.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: 4761
X-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@laronde.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1377
Lines: 45

----- Original Message ----- 
From: "Eric Christopher" <echristo@redhat.com>
To: "Bradley D. LaRonde" <brad@laronde.org>
Cc: <linux-mips@linux-mips.org>
Sent: Monday, April 12, 2004 9:02 PM
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi"
intime.c


> On Mon, 2004-04-12 at 17:53, Bradley D. LaRonde wrote:
> > Uh oh, with this patch:
> >
> > ...
> > time.c: In function `fixed_rate_gettimeoffset':
> > time.c:242: error: can't find a register in class `HI_REG' while
reloading
> > `asm'
> > ...
>
> > >
> > >         /*
> > >          * Due to possible jiffies inconsistencies, we need to check
> > > @@ -339,7 +339,7 @@
> > >                                 : "r" (timerhi), "m" (timerlo),
> > >                                   "r" (tmp), "r" (USECS_PER_JIFFY),
> > >                                   "r" (USECS_PER_JIFFY_FRAC)
> > > -                               : "hi", "lo", "accum");
> > > +                               : "hi", "lo", "hi");
> > >                         cached_quotient = quotient;
>
>
> Maybe this hunk where you use "hi" twice for the same asm statement?

Yeah, that's messed up, but it fails here too:

@@ -242,7 +242,7 @@
        __asm__("multu  %1,%2"
                : "=h" (res)
                : "r" (count), "r" (sll32_usecs_per_cycle)
-               : "lo", "accum");
+               : "lo", "hi");

Regards,
Brad


From drow@crack.them.org Tue Apr 13 02:07:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 02:07:38 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:30338 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225272AbUDMBHh>;
	Tue, 13 Apr 2004 02:07:37 +0100
Received: from drow by nevyn.them.org with local (Exim 4.31 #1 (Debian))
	id 1BDCOi-0001yX-Va; Mon, 12 Apr 2004 21:07:33 -0400
Date: Mon, 12 Apr 2004 21:07:32 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: "Bradley D. LaRonde" <brad@laronde.org>
Cc: linux-mips@linux-mips.org, Eric Christopher <echristo@redhat.com>
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" intime.c
Message-ID: <20040413010732.GA7560@nevyn.them.org>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl> <20040412231309.GA702@linux-mips.org> <03f301c420e7$d8de2d70$8d01010a@prefect> <048e01c420f1$ad4ae3b0$8d01010a@prefect> <1081818125.19719.14.camel@dzur.sfbay.redhat.com> <04d501c420f3$6c836a30$8d01010a@prefect>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <04d501c420f3$6c836a30$8d01010a@prefect>
User-Agent: Mutt/1.5.5.1+cvs20040105i
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: 4762
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1666
Lines: 48

On Mon, Apr 12, 2004 at 09:05:34PM -0400, Bradley D. LaRonde wrote:
> ----- Original Message ----- 
> From: "Eric Christopher" <echristo@redhat.com>
> To: "Bradley D. LaRonde" <brad@laronde.org>
> Cc: <linux-mips@linux-mips.org>
> Sent: Monday, April 12, 2004 9:02 PM
> Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi"
> intime.c
> 
> 
> > On Mon, 2004-04-12 at 17:53, Bradley D. LaRonde wrote:
> > > Uh oh, with this patch:
> > >
> > > ...
> > > time.c: In function `fixed_rate_gettimeoffset':
> > > time.c:242: error: can't find a register in class `HI_REG' while
> reloading
> > > `asm'
> > > ...
> >
> > > >
> > > >         /*
> > > >          * Due to possible jiffies inconsistencies, we need to check
> > > > @@ -339,7 +339,7 @@
> > > >                                 : "r" (timerhi), "m" (timerlo),
> > > >                                   "r" (tmp), "r" (USECS_PER_JIFFY),
> > > >                                   "r" (USECS_PER_JIFFY_FRAC)
> > > > -                               : "hi", "lo", "accum");
> > > > +                               : "hi", "lo", "hi");
> > > >                         cached_quotient = quotient;
> >
> >
> > Maybe this hunk where you use "hi" twice for the same asm statement?
> 
> Yeah, that's messed up, but it fails here too:
> 
> @@ -242,7 +242,7 @@
>         __asm__("multu  %1,%2"
>                 : "=h" (res)
>                 : "r" (count), "r" (sll32_usecs_per_cycle)
> -               : "lo", "accum");
> +               : "lo", "hi");

Because the asm is outputting something in HI - see the =h?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From brad@laronde.org Tue Apr 13 02:12:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 02:12:07 +0100 (BST)
Received: from ispmxmta09-srv.alltel.net ([IPv6:::ffff:166.102.165.170]:43484
	"EHLO ispmxmta09-srv.alltel.net") by linux-mips.org with ESMTP
	id <S8225272AbUDMBMG>; Tue, 13 Apr 2004 02:12:06 +0100
Received: from lahoo.priv ([162.39.1.206]) by ispmxmta09-srv.alltel.net
          with ESMTP
          id <20040413011159.DXUD2984.ispmxmta09-srv.alltel.net@lahoo.priv>;
          Mon, 12 Apr 2004 20:11:59 -0500
Received: from prefect.priv ([10.1.1.141] helo=prefect)
	by lahoo.priv with smtp (Exim 3.36 #1 (Debian))
	id 1BDCEy-0007HP-00; Mon, 12 Apr 2004 20:57:28 -0400
Message-ID: <04f501c420f4$5563f620$8d01010a@prefect>
From: "Bradley D. LaRonde" <brad@laronde.org>
To: "Daniel Jacobowitz" <dan@debian.org>
Cc: <linux-mips@linux-mips.org>,
	"Eric Christopher" <echristo@redhat.com>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl> <20040412231309.GA702@linux-mips.org> <03f301c420e7$d8de2d70$8d01010a@prefect> <048e01c420f1$ad4ae3b0$8d01010a@prefect> <1081818125.19719.14.camel@dzur.sfbay.redhat.com> <04d501c420f3$6c836a30$8d01010a@prefect> <20040413010732.GA7560@nevyn.them.org>
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" intime.c
Date: Mon, 12 Apr 2004 21:12:04 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <brad@laronde.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: 4763
X-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@laronde.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2082
Lines: 63

----- Original Message ----- 
From: "Daniel Jacobowitz" <dan@debian.org>
To: "Bradley D. LaRonde" <brad@laronde.org>
Cc: <linux-mips@linux-mips.org>; "Eric Christopher" <echristo@redhat.com>
Sent: Monday, April 12, 2004 9:07 PM
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi"
intime.c


> On Mon, Apr 12, 2004 at 09:05:34PM -0400, Bradley D. LaRonde wrote:
> > ----- Original Message ----- 
> > From: "Eric Christopher" <echristo@redhat.com>
> > To: "Bradley D. LaRonde" <brad@laronde.org>
> > Cc: <linux-mips@linux-mips.org>
> > Sent: Monday, April 12, 2004 9:02 PM
> > Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi"
> > intime.c
> >
> >
> > > On Mon, 2004-04-12 at 17:53, Bradley D. LaRonde wrote:
> > > > Uh oh, with this patch:
> > > >
> > > > ...
> > > > time.c: In function `fixed_rate_gettimeoffset':
> > > > time.c:242: error: can't find a register in class `HI_REG' while
> > reloading
> > > > `asm'
> > > > ...
> > >
> > > > >
> > > > >         /*
> > > > >          * Due to possible jiffies inconsistencies, we need to
check
> > > > > @@ -339,7 +339,7 @@
> > > > >                                 : "r" (timerhi), "m" (timerlo),
> > > > >                                   "r" (tmp), "r"
(USECS_PER_JIFFY),
> > > > >                                   "r" (USECS_PER_JIFFY_FRAC)
> > > > > -                               : "hi", "lo", "accum");
> > > > > +                               : "hi", "lo", "hi");
> > > > >                         cached_quotient = quotient;
> > >
> > >
> > > Maybe this hunk where you use "hi" twice for the same asm statement?
> >
> > Yeah, that's messed up, but it fails here too:
> >
> > @@ -242,7 +242,7 @@
> >         __asm__("multu  %1,%2"
> >                 : "=h" (res)
> >                 : "r" (count), "r" (sll32_usecs_per_cycle)
> > -               : "lo", "accum");
> > +               : "lo", "hi");
>
> Because the asm is outputting something in HI - see the =h?

Oh... yeah, I guess gcc knows that the output is clobbered.  :-P

So just remove the accum clobbers?

Regards,
Brad


From brad@laronde.org Tue Apr 13 02:23:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 02:23:31 +0100 (BST)
Received: from ispmxmta09-srv.alltel.net ([IPv6:::ffff:166.102.165.170]:58090
	"EHLO ispmxmta09-srv.alltel.net") by linux-mips.org with ESMTP
	id <S8225272AbUDMBXa>; Tue, 13 Apr 2004 02:23:30 +0100
Received: from lahoo.priv ([162.39.1.206]) by ispmxmta09-srv.alltel.net
          with ESMTP
          id <20040413012322.EEEX2984.ispmxmta09-srv.alltel.net@lahoo.priv>;
          Mon, 12 Apr 2004 20:23:22 -0500
Received: from prefect.priv ([10.1.1.141] helo=prefect)
	by lahoo.priv with smtp (Exim 3.36 #1 (Debian))
	id 1BDCPy-0007L7-00; Mon, 12 Apr 2004 21:08:50 -0400
Message-ID: <053c01c420f5$ec230190$8d01010a@prefect>
From: "Bradley D. LaRonde" <brad@laronde.org>
To: <linux-mips@linux-mips.org>
Cc: "Eric Christopher" <echristo@redhat.com>,
	"Daniel Jacobowitz" <dan@debian.org>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl> <20040412231309.GA702@linux-mips.org> <03f301c420e7$d8de2d70$8d01010a@prefect> <048e01c420f1$ad4ae3b0$8d01010a@prefect> <1081818125.19719.14.camel@dzur.sfbay.redhat.com> <04d501c420f3$6c836a30$8d01010a@prefect> <20040413010732.GA7560@nevyn.them.org> <04f501c420f4$5563f620$8d01010a@prefect>
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" intime.c
Date: Mon, 12 Apr 2004 21:23:27 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <brad@laronde.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: 4764
X-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@laronde.org
Precedence: bulk
X-list: linux-mips
Content-Length: 4163
Lines: 124

OK, so this patch actually builds, and it sounds like it will do the job,
since "accum" means "hi and low", "lo" is already clobbered in all cases,
and either "hi" is the output and doesn't need clobbering (hunks 1, 2, and
4), or "hi" is already clobbered (hunk 3).

Regards,
Brad

diff -u -r1.1.1.1 time.c
--- arch/mips/kernel/time.c     10 Nov 2003 21:06:52 -0000      1.1.1.1
+++ arch/mips/kernel/time.c     13 Apr 2004 01:19:15 -0000
@@ -242,7 +242,7 @@
        __asm__("multu  %1,%2"
                : "=h" (res)
                : "r" (count), "r" (sll32_usecs_per_cycle)
-               : "lo", "accum");
+               : "lo");

        /*
         * Due to possible jiffies inconsistencies, we need to check
@@ -297,7 +297,7 @@
        __asm__("multu  %1,%2"
                : "=h" (res)
                : "r" (count), "r" (quotient)
-               : "lo", "accum");
+               : "lo");

        /*
         * Due to possible jiffies inconsistencies, we need to check
@@ -339,7 +339,7 @@
                                : "r" (timerhi), "m" (timerlo),
                                  "r" (tmp), "r" (USECS_PER_JIFFY),
                                  "r" (USECS_PER_JIFFY_FRAC)
-                               : "hi", "lo", "accum");
+                               : "hi", "lo");
                        cached_quotient = quotient;
                }
        }
@@ -353,7 +353,7 @@
        __asm__("multu  %1,%2"
                : "=h" (res)
                : "r" (count), "r" (quotient)
-               : "lo", "accum");
+               : "lo");

        /*
         * Due to possible jiffies inconsistencies, we need to check


----- Original Message ----- 
From: "Bradley D. LaRonde" <brad@laronde.org>
To: "Daniel Jacobowitz" <dan@debian.org>
Cc: <linux-mips@linux-mips.org>; "Eric Christopher" <echristo@redhat.com>
Sent: Monday, April 12, 2004 9:12 PM
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi"
intime.c


> ----- Original Message ----- 
> From: "Daniel Jacobowitz" <dan@debian.org>
> To: "Bradley D. LaRonde" <brad@laronde.org>
> Cc: <linux-mips@linux-mips.org>; "Eric Christopher" <echristo@redhat.com>
> Sent: Monday, April 12, 2004 9:07 PM
> Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi"
> intime.c
>
>
> > On Mon, Apr 12, 2004 at 09:05:34PM -0400, Bradley D. LaRonde wrote:
> > > ----- Original Message ----- 
> > > From: "Eric Christopher" <echristo@redhat.com>
> > > To: "Bradley D. LaRonde" <brad@laronde.org>
> > > Cc: <linux-mips@linux-mips.org>
> > > Sent: Monday, April 12, 2004 9:02 PM
> > > Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi"
> > > intime.c
> > >
> > >
> > > > On Mon, 2004-04-12 at 17:53, Bradley D. LaRonde wrote:
> > > > > Uh oh, with this patch:
> > > > >
> > > > > ...
> > > > > time.c: In function `fixed_rate_gettimeoffset':
> > > > > time.c:242: error: can't find a register in class `HI_REG' while
> > > reloading
> > > > > `asm'
> > > > > ...
> > > >
> > > > > >
> > > > > >         /*
> > > > > >          * Due to possible jiffies inconsistencies, we need to
> check
> > > > > > @@ -339,7 +339,7 @@
> > > > > >                                 : "r" (timerhi), "m" (timerlo),
> > > > > >                                   "r" (tmp), "r"
> (USECS_PER_JIFFY),
> > > > > >                                   "r" (USECS_PER_JIFFY_FRAC)
> > > > > > -                               : "hi", "lo", "accum");
> > > > > > +                               : "hi", "lo", "hi");
> > > > > >                         cached_quotient = quotient;
> > > >
> > > >
> > > > Maybe this hunk where you use "hi" twice for the same asm statement?
> > >
> > > Yeah, that's messed up, but it fails here too:
> > >
> > > @@ -242,7 +242,7 @@
> > >         __asm__("multu  %1,%2"
> > >                 : "=h" (res)
> > >                 : "r" (count), "r" (sll32_usecs_per_cycle)
> > > -               : "lo", "accum");
> > > +               : "lo", "hi");
> >
> > Because the asm is outputting something in HI - see the =h?
>
> Oh... yeah, I guess gcc knows that the output is clobbered.  :-P
>
> So just remove the accum clobbers?
>
> Regards,
> Brad
>
>
>


From collar@onlinehome.de Tue Apr 13 10:35:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 10:35:59 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.173]:23510
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225206AbUDMJfz>; Tue, 13 Apr 2004 10:35:55 +0100
Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1BDKKf-0006wL-00
	for linux-mips@linux-mips.org; Tue, 13 Apr 2004 11:35:53 +0200
Received: from [80.133.133.17] (helo=p50858511.dip0.t-ipconnect.de)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1BDKKc-0006S3-00
	for linux-mips@linux-mips.org; Tue, 13 Apr 2004 11:35:50 +0200
From: Benjamin Collar <collar@onlinehome.de>
To: linux-mips@linux-mips.org
Subject: Hello
Date: Tue, 13 Apr 2004 11:38:22 +0200
User-Agent: KMail/1.6.1
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200404131138.22725.collar@onlinehome.de>
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:117708237306e4cac4d5753bf8790907
Return-Path: <collar@onlinehome.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: 4765
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: collar@onlinehome.de
Precedence: bulk
X-list: linux-mips
Content-Length: 832
Lines: 20

Greetings

I've joined this mailing list because I've started a new project: I want to 
port linux 2.6 to the Agenda VR3 PDA.

The Agenda already runs Linux--2.4.0 I think, based on the kernel that was at 
linux-vr.org but now appears to be gone.

I'm totally a beginner here, so please bear with me :)

What I'm doing at the moment is, I'm trying to understand where all of the 
code has gone! There is a different directory structure in 2.6. If someone 
can answer these questions, I'd very much appreciate it:

1. What's the difference between a NEC 4181 and NEC 41xx? In 2.6 there are 
subdirectories for each of these, while in the VR kernel all the code was in 
arch/mips/41xx. The Agenda is a 4181. Should I be using the 4181 common code 
or the 41xx?

2. Where did linux-vr go? Does anyone know where I can get the patches?

From yuasa@hh.iij4u.or.jp Tue Apr 13 11:06:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 11:06:28 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:48378 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225548AbUDMKG1>;
	Tue, 13 Apr 2004 11:06:27 +0100
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id TAA04623;
	Tue, 13 Apr 2004 19:06:20 +0900 (JST)
Received: 4UMDO01 id i3DA6JX23676; Tue, 13 Apr 2004 19:06:19 +0900 (JST)
Received: 4UMRO00 id i3DA6I119784; Tue, 13 Apr 2004 19:06:18 +0900 (JST)
	from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Tue, 13 Apr 2004 19:06:18 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Benjamin Collar <collar@onlinehome.de>
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: Hello
Message-Id: <20040413190618.5c3c2a66.yuasa@hh.iij4u.or.jp>
In-Reply-To: <200404131138.22725.collar@onlinehome.de>
References: <200404131138.22725.collar@onlinehome.de>
X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4766
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 1135
Lines: 32

On Tue, 13 Apr 2004 11:38:22 +0200
Benjamin Collar <collar@onlinehome.de> wrote:

> Greetings
> 
> I've joined this mailing list because I've started a new project: I want to 
> port linux 2.6 to the Agenda VR3 PDA.
> 
> The Agenda already runs Linux--2.4.0 I think, based on the kernel that was at 
> linux-vr.org but now appears to be gone.
> 
> I'm totally a beginner here, so please bear with me :)
> 
> What I'm doing at the moment is, I'm trying to understand where all of the 
> code has gone! There is a different directory structure in 2.6. If someone 
> can answer these questions, I'd very much appreciate it:
> 
> 1. What's the difference between a NEC 4181 and NEC 41xx? In 2.6 there are 
> subdirectories for each of these, while in the VR kernel all the code was in 
> arch/mips/41xx. The Agenda is a 4181. Should I be using the 4181 common code 
> or the 41xx?

VR4181 is not same as other VR4100 series.
We already have codes for VR4181 in arch/mips/vr4181.
You can start from these codes.

> 2. Where did linux-vr go? Does anyone know where I can get the patches?

http://www.linux-mips.org/cvsweb/linux-vr/

Yoichi


From ashley@seamlessrecruitment.com Tue Apr 13 11:33:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 12:02:28 +0100 (BST)
Received: from [IPv6:::ffff:212.42.179.107] ([IPv6:::ffff:212.42.179.107]:14791
	"EHLO fortytwo.seamlessrecruitment.com") by linux-mips.org with ESMTP
	id <S8225619AbUDMKdV>; Tue, 13 Apr 2004 11:33:21 +0100
Received: from seamlessrecruitment.com (roi.seamlessrecruitment.com [10.0.0.3])
	by fortytwo.seamlessrecruitment.com (Postfix) with ESMTP id 6B276443A420
	for <linux-mips@linux-mips.org>; Tue, 13 Apr 2004 11:33:13 +0100 (BST)
Message-ID: <407BC212.8000303@seamlessrecruitment.com>
Date: Tue, 13 Apr 2004 11:33:54 +0100
From: Ashley Evans <ashley@seamlessrecruitment.com>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040306)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: R4400MC
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ashley@seamlessrecruitment.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4767
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: ashley@seamlessrecruitment.com
Precedence: bulk
X-list: linux-mips
Content-Length: 264
Lines: 9

Hi,

I'm also new to the list. I'm hoping that the HOWTO hasn't been updated 
re. the status of the above processor.

I've just aquired a Challenge DM w/ dual R4400mc processors and would 
really like to run Linux (or anything that's OSS for that matter).

Ashley

From macro@ds2.pg.gda.pl Tue Apr 13 13:57:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 13:57:18 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:43998 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225846AbUDMM5O>; Tue, 13 Apr 2004 13:57:14 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 1B6F14794B; Tue, 13 Apr 2004 14:57:07 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id B589C47775; Tue, 13 Apr 2004 14:57:07 +0200 (CEST)
Date: Tue, 13 Apr 2004 14:57:07 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Bradley D. LaRonde" <brad@laronde.org>
Cc: linux-mips@linux-mips.org, Eric Christopher <echristo@redhat.com>,
	Daniel Jacobowitz <dan@debian.org>
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" intime.c
In-Reply-To: <053c01c420f5$ec230190$8d01010a@prefect>
Message-ID: <Pine.LNX.4.55.0404131451200.15949@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl>
 <20040412231309.GA702@linux-mips.org> <03f301c420e7$d8de2d70$8d01010a@prefect>
 <048e01c420f1$ad4ae3b0$8d01010a@prefect> <1081818125.19719.14.camel@dzur.sfbay.redhat.com>
 <04d501c420f3$6c836a30$8d01010a@prefect> <20040413010732.GA7560@nevyn.them.org>
 <04f501c420f4$5563f620$8d01010a@prefect> <053c01c420f5$ec230190$8d01010a@prefect>
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: 4768
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 4192
Lines: 107

On Mon, 12 Apr 2004, Bradley D. LaRonde wrote:

> OK, so this patch actually builds, and it sounds like it will do the job,
> since "accum" means "hi and low", "lo" is already clobbered in all cases,
> and either "hi" is the output and doesn't need clobbering (hunks 1, 2, and
> 4), or "hi" is already clobbered (hunk 3).

 There are more places this should be dealt with and I have the following 
preliminary patch for this, but I'm unsure about removal of "accum" being 
completely safe for older compilers.

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

patch-mips-2.4.24-pre2-20040116-mips-gcc3-2
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/time.c linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/time.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/time.c	2004-01-15 03:56:58.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/time.c	2004-02-02 04:38:34.000000000 +0000
@@ -242,7 +242,7 @@ static unsigned long fixed_rate_gettimeo
 	__asm__("multu	%1,%2"
 		: "=h" (res)
 		: "r" (count), "r" (sll32_usecs_per_cycle)
-		: "lo", "accum");
+		: "lo");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
@@ -297,7 +297,7 @@ static unsigned long calibrate_div32_get
 	__asm__("multu  %1,%2"
 		: "=h" (res)
 		: "r" (count), "r" (quotient)
-		: "lo", "accum");
+		: "lo");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
@@ -339,7 +339,7 @@ static unsigned long calibrate_div64_get
 				: "r" (timerhi), "m" (timerlo),
 				  "r" (tmp), "r" (USECS_PER_JIFFY),
 				  "r" (USECS_PER_JIFFY_FRAC)
-				: "hi", "lo", "accum");
+				: "hi", "lo");
 			cached_quotient = quotient;
 		}
 	}
@@ -353,7 +353,7 @@ static unsigned long calibrate_div64_get
 	__asm__("multu	%1,%2"
 		: "=h" (res)
 		: "r" (count), "r" (quotient)
-		: "lo", "accum");
+		: "lo");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/cpu-probe.c linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/cpu-probe.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/cpu-probe.c	2003-12-11 03:56:36.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/cpu-probe.c	2004-02-02 04:44:30.000000000 +0000
@@ -177,7 +177,7 @@ static inline void mult_sh_align_mod(lon
 		".set	pop"
 		: "=&r" (lv1), "=r" (lw)
 		: "r" (m1), "r" (m2), "r" (s), "I" (0)
-		: "hi", "lo", "accum");
+		: "hi", "lo");
 	/* We have to use single integers for m1 and m2 and a double
 	 * one for p to be sure the mulsidi3 gcc's RTL multiplication
 	 * instruction has the workaround applied.  Older versions of
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/time.c linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/time.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/time.c	2004-01-15 03:57:03.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/time.c	2004-02-02 04:39:21.000000000 +0000
@@ -242,7 +242,7 @@ static unsigned long fixed_rate_gettimeo
 	__asm__("multu	%1,%2"
 		: "=h" (res)
 		: "r" (count), "r" (sll32_usecs_per_cycle)
-		: "lo", "accum");
+		: "lo");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
@@ -297,7 +297,7 @@ static unsigned long calibrate_div32_get
 	__asm__("multu  %1,%2"
 		: "=h" (res)
 		: "r" (count), "r" (quotient)
-		: "lo", "accum");
+		: "lo");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
@@ -339,7 +339,7 @@ static unsigned long calibrate_div64_get
 				: "r" (timerhi), "m" (timerlo),
 				  "r" (tmp), "r" (USECS_PER_JIFFY),
 				  "r" (USECS_PER_JIFFY_FRAC)
-				: "hi", "lo", "accum");
+				: "hi", "lo");
 			cached_quotient = quotient;
 		}
 	}
@@ -353,7 +353,7 @@ static unsigned long calibrate_div64_get
 	__asm__("multu	%1,%2"
 		: "=h" (res)
 		: "r" (count), "r" (quotient)
-		: "lo", "accum");
+		: "lo");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check

From hjl@lucon.org Tue Apr 13 17:23:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 17:23:44 +0100 (BST)
Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:11732 "EHLO
	sccrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225249AbUDMQXn>; Tue, 13 Apr 2004 17:23:43 +0100
Received: from lucon.org ([24.6.43.109]) by comcast.net (sccrmhc11) with ESMTP
          id <20040413162326011009idvhe>; Tue, 13 Apr 2004 16:23:31 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 3142764D15; Tue, 13 Apr 2004 09:23:22 -0700 (PDT)
Date: Tue, 13 Apr 2004 09:23:22 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org,
	GNU C Library <libc-alpha@sources.redhat.com>,
	Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	"Steven J. Hill" <sjhill@realitydiluted.com>
Subject: The Linux binutils 2.15.90.0.2 is released
Message-ID: <20040413162322.GA14515@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: 4769
X-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
Content-Length: 4938
Lines: 180

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

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

If you don't use

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

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

Changes from binutils 2.15.90.0.1.1:

1. Update from binutils 2004 0412.
2. Add --as-needed/--no-as-needed to linker.
3. Fix -z defs in linker.
4. Always reserve the memory for ia64 dynamic linker.
5. Fix a race condition in ia64 lazy binding.

Changes from binutils 2.15.90.0.1:

1. Fixed an ia64 assembler bug.
2. Install the assembler man page.

Changes from binutils 2.14.90.0.8:

1. Update from binutils 2004 0303.
2. Fixed linker for undefined symbols with non-default visibility.
3. Sped up linker weakdef symbol handling.
4. Fixed mixing ELF32 and ELF64 object files in archive.
5. Added ia64 linker brl optimization.
6. Fixed ia64 linker to disallow invalid dynamic relocations.
7. Fixed DT_TEXTREL handling in ia64 linker.
8. Fixed alignment handling in ia64 assembler.
9. Improved ia64 assembler unwind table handling. 

Changes from binutils 2.14.90.0.7:

1. Update from binutils 2004 0114.
2. Fixed an ia64 assembler unwind table bug. 
3. Better handle IPF linker relaxation overflow.
4. Fixed misc PPC bugs.

Changes from binutils 2.14.90.0.6:

1. Update from binutils 2003 1029.
2. Allow type changes for undefined symbols.
3. Fix EH frame optimization.
4. Fix the check for undefined versioned symbol with wildcard.
5. Support generating code for Itanium.
6. Detect and warn bad symbol index.
7. Update IPF assemebler DV check.

Changes from binutils 2.14.90.0.5:

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

Changes from binutils 2.14.90.0.4.1:

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

Changes from binutils 2.14.90.0.4:
 
1. Fix an ia64 assembler hint@pause bug.
2. Support Intel 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.15.90.0.2.tar.bz2. Source code.
2. binutils-2.15.90.0.1.1-2.15.90.0.2.diff.bz2. Patch against the
   previous beta source code.
3. binutils-2.15.90.0.2-1.i386.rpm. IA-32 binary RPM for RedHat EL 3.
4. binutils-2.15.90.0.2-1.ia64.rpm. IA-64 binary RPM for RedHat EL 3.
5. binutils-2.15.90.0.2-1.x86_64.rpm. X64_64 binary RPM for RedHat EL 3.

There is no separate source rpm. You can do

# rpmbuild -ta binutils-2.15.90.0.2.tar.bz2

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
04/13/2004

From brad@laronde.org Tue Apr 13 20:20:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 20:20:54 +0100 (BST)
Received: from ispmxmta09-srv.alltel.net ([IPv6:::ffff:166.102.165.170]:62975
	"EHLO ispmxmta09-srv.alltel.net") by linux-mips.org with ESMTP
	id <S8225801AbUDMTUx>; Tue, 13 Apr 2004 20:20:53 +0100
Received: from lahoo.priv ([162.39.1.206]) by ispmxmta09-srv.alltel.net
          with ESMTP
          id <20040413192043.VXPA2984.ispmxmta09-srv.alltel.net@lahoo.priv>
          for <linux-mips@linux-mips.org>; Tue, 13 Apr 2004 14:20:43 -0500
Received: from prefect.priv ([10.1.1.141] helo=prefect)
	by lahoo.priv with smtp (Exim 3.36 #1 (Debian))
	id 1BDTET-0006Ax-00
	for <linux-mips@linux-mips.org>; Tue, 13 Apr 2004 15:06:05 -0400
Message-ID: <028001c4218c$6d792350$8d01010a@prefect>
From: "Bradley D. LaRonde" <brad@laronde.org>
To: <linux-mips@linux-mips.org>
Subject: [PATCH] catch "new" gcc 3.4.0 sections
Date: Tue, 13 Apr 2004 15:20:48 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <brad@laronde.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: 4770
X-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@laronde.org
Precedence: bulk
X-list: linux-mips
Content-Length: 717
Lines: 27

Building with gcc 3.4.0 emits a couple new sections, .rodata.cst4 and
.rodata.str1.4, which the current ld.script doesn't contemplate.  Here is a
patch to catch them (and maybe some other latent ones).

Anyone know why or when these sections are emitted?

Regards,
Brad


diff -u -r1.1.1.1 ld.script.in
--- arch/mips/ld.script.in      10 Nov 2003 21:06:52 -0000      1.1.1.1
+++ arch/mips/ld.script.in      13 Apr 2004 19:18:25 -0000
@@ -11,6 +11,11 @@
     *(.text)
     *(.rodata)
     *(.rodata1)
+    *(.rodata.str1.1);
+    *(.rodata.str1.4);
+    *(.rodata.str1.32);
+    *(.rodata.cst4);
+    *(.rodata.cst8);
     /* .gnu.warning sections are handled specially by elf32.em.  */
     *(.gnu.warning)
   } =0



From ica2_ts@csv.ica.uni-stuttgart.de Tue Apr 13 20:32:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 20:32:04 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:57415
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225804AbUDMTcD>; Tue, 13 Apr 2004 20:32:03 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail)
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1BDTdX-00065a-00
	for <linux-mips@linux-mips.org>; Tue, 13 Apr 2004 21:31:59 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1BDTdW-0004up-00
	for <linux-mips@linux-mips.org>; Tue, 13 Apr 2004 21:31:58 +0200
Date: Tue, 13 Apr 2004 21:31:58 +0200
To: linux-mips@linux-mips.org
Subject: Re: [PATCH] catch "new" gcc 3.4.0 sections
Message-ID: <20040413193158.GO27939@rembrandt.csv.ica.uni-stuttgart.de>
References: <028001c4218c$6d792350$8d01010a@prefect>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <028001c4218c$6d792350$8d01010a@prefect>
User-Agent: Mutt/1.5.5.1i
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: 4771
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 838
Lines: 31

Bradley D. LaRonde wrote:
> Building with gcc 3.4.0 emits a couple new sections, .rodata.cst4 and
> .rodata.str1.4, which the current ld.script doesn't contemplate.  Here is a
> patch to catch them (and maybe some other latent ones).
> 
> Anyone know why or when these sections are emitted?

I'd guess to keep differently aligned strings in separate sections,
as a preliminary for improved string merging.

> Regards,
> Brad
> 
> 
> diff -u -r1.1.1.1 ld.script.in
> --- arch/mips/ld.script.in      10 Nov 2003 21:06:52 -0000      1.1.1.1
> +++ arch/mips/ld.script.in      13 Apr 2004 19:18:25 -0000
> @@ -11,6 +11,11 @@
>      *(.text)
>      *(.rodata)
>      *(.rodata1)
> +    *(.rodata.str1.1);
> +    *(.rodata.str1.4);
> +    *(.rodata.str1.32);
> +    *(.rodata.cst4);
> +    *(.rodata.cst8);

Why not just *(.rodata*); ?


Thiemo

From brad@laronde.org Tue Apr 13 20:43:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Apr 2004 20:43:43 +0100 (BST)
Received: from ispmxmta05-srv.alltel.net ([IPv6:::ffff:166.102.165.166]:19140
	"EHLO ispmxmta05-srv.alltel.net") by linux-mips.org with ESMTP
	id <S8225331AbUDMTnm>; Tue, 13 Apr 2004 20:43:42 +0100
Received: from lahoo.priv ([162.39.1.206]) by ispmxmta05-srv.alltel.net
          with ESMTP
          id <20040413194333.TPGI29083.ispmxmta05-srv.alltel.net@lahoo.priv>;
          Tue, 13 Apr 2004 14:43:33 -0500
Received: from prefect.priv ([10.1.1.141] helo=prefect)
	by lahoo.priv with smtp (Exim 3.36 #1 (Debian))
	id 1BDTaZ-0006Ci-00; Tue, 13 Apr 2004 15:28:55 -0400
Message-ID: <02ea01c4218f$9ea240d0$8d01010a@prefect>
From: "Bradley D. LaRonde" <brad@laronde.org>
To: <linux-mips@linux-mips.org>,
	"Thiemo Seufer" <ica2_ts@csv.ica.uni-stuttgart.de>
References: <028001c4218c$6d792350$8d01010a@prefect> <20040413193158.GO27939@rembrandt.csv.ica.uni-stuttgart.de>
Subject: Re: [PATCH] catch "new" gcc 3.4.0 sections
Date: Tue, 13 Apr 2004 15:43:39 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <brad@laronde.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: 4772
X-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@laronde.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1236
Lines: 44

----- Original Message ----- 
From: "Thiemo Seufer" <ica2_ts@csv.ica.uni-stuttgart.de>
To: <linux-mips@linux-mips.org>
Sent: Tuesday, April 13, 2004 3:31 PM
Subject: Re: [PATCH] catch "new" gcc 3.4.0 sections


> Bradley D. LaRonde wrote:
> > Building with gcc 3.4.0 emits a couple new sections, .rodata.cst4 and
> > .rodata.str1.4, which the current ld.script doesn't contemplate.  Here
is a
> > patch to catch them (and maybe some other latent ones).
> >
> > Anyone know why or when these sections are emitted?
>
> I'd guess to keep differently aligned strings in separate sections,
> as a preliminary for improved string merging.
>
> > Regards,
> > Brad
> >
> >
> > diff -u -r1.1.1.1 ld.script.in
> > --- arch/mips/ld.script.in      10 Nov 2003 21:06:52 -0000      1.1.1.1
> > +++ arch/mips/ld.script.in      13 Apr 2004 19:18:25 -0000
> > @@ -11,6 +11,11 @@
> >      *(.text)
> >      *(.rodata)
> >      *(.rodata1)
> > +    *(.rodata.str1.1);
> > +    *(.rodata.str1.4);
> > +    *(.rodata.str1.32);
> > +    *(.rodata.cst4);
> > +    *(.rodata.cst8);
>
> Why not just *(.rodata*); ?

I dunno.  There is already a tradition with .rodata and .rodata1 being
listed separately.  Maybe to spy on future gcc behavior?


Regards,
Brad


From remex_cao@sjtu.edu.cn Wed Apr 14 07:03:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 07:03:09 +0100 (BST)
Received: from mail.sjtu.edu.cn ([IPv6:::ffff:202.112.26.55]:61879 "EHLO
	mx1.sjtu.edu.cn") by linux-mips.org with ESMTP id <S8224771AbUDNGDH>;
	Wed, 14 Apr 2004 07:03:07 +0100
Received: from localhost (mx1.sjtu.edu.cn [127.0.0.1])
	by mx1.sjtu.edu.cn (Postfix) with ESMTP id 714B57B0222
	for <linux-mips@linux-mips.org>; Wed, 14 Apr 2004 14:03:02 +0800 (CST)
Received: from mx1.sjtu.edu.cn ([127.0.0.1])
 by localhost (mx1.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 22302-03 for <linux-mips@linux-mips.org>;
 Wed, 14 Apr 2004 14:03:02 +0800 (CST)
Received: from caoxiang (unknown [218.193.188.71])
	by mx1.sjtu.edu.cn (Postfix) with ESMTP id F2F297B01A5
	for <linux-mips@linux-mips.org>; Wed, 14 Apr 2004 14:03:01 +0800 (CST)
Date: Wed, 14 Apr 2004 14:05:23 +0800
From: "caoxiang" <remex_cao@sjtu.edu.cn>
Reply-To: remex_cao@sjtu.edu.cn
To: "Linux MIPS" <linux-mips@linux-mips.org>
Subject: 
Organization: sjtu
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====003_Dragon652456816835_====="
Message-Id: <20040414060301.F2F297B01A5@mx1.sjtu.edu.cn>
X-Virus-Scanned: by amavisd-new at mx1.sjtu.edu.cn
Return-Path: <remex_cao@sjtu.edu.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: 4773
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: remex_cao@sjtu.edu.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 3153
Lines: 40


This is a multi-part message in MIME format.

--=====003_Dragon652456816835_=====
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit

Greetings

I've encountered a problem when I am porting linux 2.4.3 to the SEAD-2 board.

The tool-chain I used include:
gcc-mipsel-linux-2.95.4
gcc-mips-linux-2.95.4
binutils-mipsel-linux-2.13.1
An error occured like that When I make the kernel:
mipsel-linux-ld -static -G 0 -T arch/mips/ld.script arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o \        --start-group \        arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o \        drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o  drivers/parport/driver.o drivers/usb/usbdrv.o \        net/network.o \        arch/mips/lib/lib.a /usr/local/0_mips/linux-2.4.3/lib/lib.a arch/mips/mips-boards/sead/sead.o arch/mips/mips-boards/generic/mipsboards.o \        --end-group \        -o vmlinuxmipsel-linux-ld: target elf32-littlemips not foundmake: *** [vmlinux] Error 1
As I change to big endian the problem still exists. Shall I apply some patch?
Thanks for help.
remex

--=====003_Dragon652456816835_=====
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR></HEAD>
<BODY bgColor=#e7e7e7><PRE>Greetings

I've encountered a problem when I am porting linux 2.4.3 to the SEAD-2 board.

The tool-chain I used include:</PRE><PRE>gcc-mipsel-linux-2.95.4</PRE><PRE>gcc-mips-linux-2.95.4</PRE><PRE>binutils-mipsel-linux-2.13.1</PRE><PRE>An error occured like that When I make the kernel:</PRE><PRE>mipsel-linux-ld -static -G 0 -T arch/mips/ld.script arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o \<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --start-group \<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o \<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o&nbsp; drivers/parport/driver.o drivers/usb/usbdrv.o \<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; net/network.o \<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; arch/mips/lib/lib.a /usr/local/0_mips/linux-2.4.3/lib/lib.a arch/mips/mips-boards/sead/sead.o arch/mips/mips-
 boards/generic/mipsboards.o \<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --end-group \<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -o vmlinux<BR>mipsel-linux-ld: target elf32-littlemips not found<BR>make: *** [vmlinux] Error 1</PRE><PRE>As I change to big endian the problem still exists. Shall I apply some patch?</PRE><PRE>Thanks for help.</PRE><PRE>remex</PRE><!--X-Body-of-Message-End--><!--X-MsgBody-End--><!--X-Follow-Ups--></BODY></HTML>

--=====003_Dragon652456816835_=====--


From fxzhang@ict.ac.cn Wed Apr 14 07:36:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 07:36:16 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:51082 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225814AbUDNGgO>;
	Wed, 14 Apr 2004 07:36:14 +0100
Received: (qmail 11389 invoked from network); 14 Apr 2004 06:30:46 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.187)
  by mail.ict.ac.cn with SMTP; 14 Apr 2004 06:30:46 -0000
Message-ID: <407D843B.1070405@ict.ac.cn>
Date: Wed, 14 Apr 2004 14:34:35 -0400
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: zh-cn, en-us
MIME-Version: 1.0
To: remex_cao@sjtu.edu.cn
CC: linux-mips@linux-mips.org
Subject: Re: 
References: <20040414060301.F2F297B01A5@mx1.sjtu.edu.cn>
In-Reply-To: <20040414060301.F2F297B01A5@mx1.sjtu.edu.cn>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Return-Path: <fxzhang@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4774
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fxzhang@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 1300
Lines: 42



caoxiang wrote:

>Greetings
>
>I've encountered a problem when I am porting linux 2.4.3 to the SEAD-2 board.
>
>The tool-chain I used include:
>
>gcc-mipsel-linux-2.95.4
>
>gcc-mips-linux-2.95.4
>
>binutils-mipsel-linux-2.13.1
>
>An error occured like that When I make the kernel:
>
>mipsel-linux-ld -static -G 0 -T arch/mips/ld.script arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o \
>        --start-group \
>        arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o \
>        drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o  drivers/parport/driver.o drivers/usb/usbdrv.o \
>        net/network.o \
>        arch/mips/lib/lib.a /usr/local/0_mips/linux-2.4.3/lib/lib.a arch/mips/mips-boards/sead/sead.o arch/mips/mips-
> boards/generic/mipsboards.o \
>        --end-group \
>        -o vmlinux
>mipsel-linux-ld: target elf32-littlemips not found
>  
>
change elf32-littlemips in arch/mips/ld.script to elf32-tradlittlemips

use mipsel-linux-ld --verbose to show supported OUTPUT_FORMAT of your ld

>make: *** [vmlinux] Error 1
>
>As I change to big endian the problem still exists. Shall I apply some patch?
>
>Thanks for help.
>
>remex
>

From ralf@linux-mips.org Wed Apr 14 13:52:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 15:18:00 +0100 (BST)
Received: from p508B7BFD.dip.t-dialin.net ([IPv6:::ffff:80.139.123.253]:57882
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225730AbUDNMwC>; Wed, 14 Apr 2004 13:52:02 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3ECq1xr010246;
	Wed, 14 Apr 2004 14:52:01 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3ECq0Ap010243;
	Wed, 14 Apr 2004 14:52:00 +0200
Date: Wed, 14 Apr 2004 14:52:00 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Ashley Evans <ashley@seamlessrecruitment.com>
Cc: linux-mips@linux-mips.org
Subject: Re: R4400MC
Message-ID: <20040414125200.GA9206@linux-mips.org>
References: <407BC212.8000303@seamlessrecruitment.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <407BC212.8000303@seamlessrecruitment.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: 4775
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 435
Lines: 12

On Tue, Apr 13, 2004 at 11:33:54AM +0100, Ashley Evans wrote:

> I'm also new to the list. I'm hoping that the HOWTO hasn't been updated 
> re. the status of the above processor.
> 
> I've just aquired a Challenge DM w/ dual R4400mc processors and would 
> really like to run Linux (or anything that's OSS for that matter).

Challenge DM isn't supported and won't be as long as nobody makes an
attempt to support it, sorry ...

  Ralf

From ashley@seamlessrecruitment.com Wed Apr 14 16:46:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 16:46:40 +0100 (BST)
Received: from [IPv6:::ffff:212.42.179.107] ([IPv6:::ffff:212.42.179.107]:20108
	"EHLO fortytwo.seamlessrecruitment.com") by linux-mips.org with ESMTP
	id <S8225734AbUDNPqj>; Wed, 14 Apr 2004 16:46:39 +0100
Received: from seamlessrecruitment.com (roi.seamlessrecruitment.com [10.0.0.3])
	by fortytwo.seamlessrecruitment.com (Postfix) with ESMTP id 0D50A442E080
	for <linux-mips@linux-mips.org>; Wed, 14 Apr 2004 16:46:29 +0100 (BST)
Message-ID: <407D5CDA.6070407@seamlessrecruitment.com>
Date: Wed, 14 Apr 2004 16:46:34 +0100
From: Ashley Evans <ashley@seamlessrecruitment.com>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040306)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: R4400MC
References: <407BC212.8000303@seamlessrecruitment.com> <20040414125200.GA9206@linux-mips.org>
In-Reply-To: <20040414125200.GA9206@linux-mips.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ashley@seamlessrecruitment.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4776
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashley@seamlessrecruitment.com
Precedence: bulk
X-list: linux-mips
Content-Length: 682
Lines: 29

Ralf Baechle wrote:

>On Tue, Apr 13, 2004 at 11:33:54AM +0100, Ashley Evans wrote:
>
>  
>
>>I'm also new to the list. I'm hoping that the HOWTO hasn't been updated 
>>re. the status of the above processor.
>>
>>I've just aquired a Challenge DM w/ dual R4400mc processors and would 
>>really like to run Linux (or anything that's OSS for that matter).
>>    
>>
>
>Challenge DM isn't supported and won't be as long as nobody makes an
>attempt to support it, sorry ...
>
>  Ralf
>  
>

Thanks, just thought I'd ask.

I believe it's the cache controller that's the problem? I don't have the 
skills to do it myself but if somebody could explain the issue i'd like 
to know?

Ashley


From p2@mind.be Wed Apr 14 20:58:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 20:58:47 +0100 (BST)
Received: from NAT.office.mind.be ([IPv6:::ffff:62.166.230.82]:53123 "EHLO
	codecarver.intern.mind.be") by linux-mips.org with ESMTP
	id <S8225747AbUDNT6o>; Wed, 14 Apr 2004 20:58:44 +0100
Received: from p2 by codecarver with local (Exim 3.36 #1 (Debian))
	id 1BDqTd-0001LQ-00
	for <linux-mips@linux-mips.org>; Wed, 14 Apr 2004 21:55:17 +0200
Date: Wed, 14 Apr 2004 21:55:17 +0200
To: linux-mips@linux-mips.org
Subject: TIOCGSERIAL for SB1250 UARTs
Message-ID: <20040414195517.GA1615@mind.be>
Mail-Followup-To: peter.de.schrijver@mind.be, linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU"
Content-Disposition: inline
X-Answer: 42
X-Operating-system: Debian GNU/Linux
X-Message-Flag: Get yourself a real email client. http://www.mutt.org/
X-mate: Mate, man gewoehnt sich an alles
User-Agent: Mutt/1.5.5.1+cvs20040105i
From: Peter 'p2' De Schrijver <p2@mind.be>
Return-Path: <p2@mind.be>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4777
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: p2@mind.be
Precedence: bulk
X-list: linux-mips
Content-Length: 2562
Lines: 101


--Bn2rw/3z4jIqBvZU
Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c"
Content-Disposition: inline


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

Hi,

The attached patch implements the TIOCGSERIAL ioctl for the SB1250
DUART.=20

Thanks,

Peter (p2).

--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=sb1250-serial-patch-1
Content-Transfer-Encoding: quoted-printable

--- linux-2.4.24/drivers/char/sb1250_duart.c	2003-08-25 13:44:41.000000000 =
+0200
+++ linux-qube/linux-2.4.24/linux/drivers/char/sb1250_duart.c	2004-04-03 20=
:40:05.000000000 +0200
@@ -498,9 +498,31 @@
 	duart_set_cflag(us->line, tty->termios->c_cflag);
 }
=20
+static int get_serial_info(uart_state_t *us, struct serial_struct * retinf=
o) {
+
+	struct serial_struct tmp;
+
+	memset(&tmp, 0, sizeof(tmp));
+
+	tmp.type=3DPORT_SB1250;
+	tmp.line=3Dus->line;
+	tmp.port=3DA_DUART_CHANREG(tmp.line,0);
+	tmp.irq=3DK_INT_UART_0 + tmp.line;
+	tmp.xmit_fifo_size=3D16; /* fixed by hw */
+	tmp.baud_base=3D5000000;
+	tmp.io_type=3DSERIAL_IO_MEM;
+
+	if (copy_to_user(retinfo,&tmp,sizeof(*retinfo)))
+		return -EFAULT;
+
+	return 0;
+}
+
 static int duart_ioctl(struct tty_struct *tty, struct file * file,
 		       unsigned int cmd, unsigned long arg)
 {
+	uart_state_t *us =3D (uart_state_t *) tty->driver_data;
+
 /*	if (serial_paranoia_check(info, tty->device, "rs_ioctl"))
 	return -ENODEV;*/
 	switch (cmd) {
@@ -517,7 +539,7 @@
 		printk("Ignoring TIOCMSET\n");
 		break;
 	case TIOCGSERIAL:
-		printk("Ignoring TIOCGSERIAL\n");
+		return get_serial_info(us,(struct serial_struct *) arg);
 		break;
 	case TIOCSSERIAL:
 		printk("Ignoring TIOCSSERIAL\n");
--- linux-2.4.24/include/linux/serial.h	2002-08-03 02:39:45.000000000 +0200
+++ linux-qube/linux-2.4.24/linux/include/linux/serial.h	2004-04-03 20:14:3=
7.000000000 +0200
@@ -75,7 +75,8 @@
 #define PORT_16654	11
 #define PORT_16850	12
 #define PORT_RSA	13	/* RSA-DV II/S card */
-#define PORT_MAX	13
+#define PORT_SB1250	14
+#define PORT_MAX	14
=20
 #define SERIAL_IO_PORT	0
 #define SERIAL_IO_HUB6	1

--sm4nu43k4a2Rpi4c--

--Bn2rw/3z4jIqBvZU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFAfZclKLKVw/RurbsRAvQzAJoDRsaOVlHuc7qFAgu62kEOv3tgcACfdmQk
SaxGh0AimGqI3r9DpypyH6I=
=uWhe
-----END PGP SIGNATURE-----

--Bn2rw/3z4jIqBvZU--

From Jiang.Xu@echostar.com Wed Apr 14 21:18:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 21:18:30 +0100 (BST)
Received: from mailout2.echostar.com ([IPv6:::ffff:204.76.128.102]:50951 "EHLO
	mailout2.echostar.com") by linux-mips.org with ESMTP
	id <S8225747AbUDNUS1>; Wed, 14 Apr 2004 21:18:27 +0100
Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19)
	id <2LYLSY2W>; Wed, 14 Apr 2004 14:18:20 -0600
Message-ID: <F71A246055866844B66AFEB10654E7860F1B0B@riv-exchb6.echostar.com>
From: "Xu, Jiang" <Jiang.Xu@echostar.com>
To: linux-mips@linux-mips.org
Subject: questions about keyboard
Date: Wed, 14 Apr 2004 14:18:18 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4225D.9FF8CAD9"
Return-Path: <Jiang.Xu@echostar.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4778
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Jiang.Xu@echostar.com
Precedence: bulk
X-list: linux-mips
Content-Length: 4200
Lines: 90

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_01C4225D.9FF8CAD9
Content-Type: text/plain

Hi,  All,
 
I tried couple places and hope can get some help here.
 
I try to connect a USB keyboard device to a mips embedded system.
There is no console or X Window or any type of the graphic system
configured.
All I want to do is to:
The user can dynamically connect the USB keyboard to the device. The device
will listen to the key event from the keyboard and response by doing certain
things.
 
I believe I successfully configured the USB keyboard.  I verified this by
put "printk" at the first line of the function handle_scancode in
keyboard.c.  Everytime when I push the key on the keyboard, I see that
printk.
 
However, what I don't get is how can I get the key event from the kernel?  I
tried to listen to all the ttyN, but none of them connect to the keyboard.  
I wonder how I can write a user space application that can get the key
event?  Could somebody help me out?  Because it is an embedded device, there
is no X.
 
Thanks
 
John
 

------_=_NextPart_001_01C4225D.9FF8CAD9
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>Message</TITLE>

<META content="MSHTML 5.50.4937.800" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004>Hi,&nbsp; 
All,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=640081020-14042004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004>I tried couple 
places and hope can get some help here.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=640081020-14042004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004>I try to connect a 
USB keyboard device to a mips embedded system.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004>There is no console 
or X Window or any type of the graphic system configured.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004>All I want to do is 
to:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004>The user can 
dynamically connect the USB keyboard to the device.&nbsp;The device will listen 
to the key event from the keyboard and response by doing certain 
things.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=640081020-14042004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004>I believe I 
successfully configured the USB keyboard.&nbsp; I verified this by put "printk" 
at the first line of the function handle_scancode in keyboard.c.&nbsp; Everytime 
when I push the key on the keyboard, I see that printk.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=640081020-14042004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004>However, what I 
don't get&nbsp;is how can I get the key event from the kernel?&nbsp; I tried to 
listen to all the ttyN, but none of them connect to the keyboard.&nbsp; 
</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004>I wonder how I can 
write a user space application that can get the key event?&nbsp; <SPAN 
class=640081020-14042004>Could somebody help me out?&nbsp; Because it is an 
embedded device, there is no X.</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004><SPAN 
class=640081020-14042004></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004><SPAN 
class=640081020-14042004>Thanks</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004><SPAN 
class=640081020-14042004></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=640081020-14042004><SPAN 
class=640081020-14042004>John</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=640081020-14042004></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C4225D.9FF8CAD9--

From jbglaw@dvmwest.gt.owl.de Wed Apr 14 21:25:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 21:25:40 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:63147 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225747AbUDNUZh>; Wed, 14 Apr 2004 21:25:37 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id D924F4B60F; Wed, 14 Apr 2004 22:25:34 +0200 (CEST)
Date: Wed, 14 Apr 2004 22:25:34 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: questions about keyboard
Message-ID: <20040414202534.GS630@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <F71A246055866844B66AFEB10654E7860F1B0B@riv-exchb6.echostar.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="JMCz+drDJ1SjddZX"
Content-Disposition: inline
In-Reply-To: <F71A246055866844B66AFEB10654E7860F1B0B@riv-exchb6.echostar.com>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4779
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1438
Lines: 45


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

On Wed, 2004-04-14 14:18:18 -0600, Xu, Jiang <Jiang.Xu@echostar.com>
wrote in message <F71A246055866844B66AFEB10654E7860F1B0B@riv-exchb6.echosta=
r.com>:
> However, what I don't get is how can I get the key event from the kernel?=
  I
> tried to listen to all the ttyN, but none of them connect to the keyboard=
=2E =20
> I wonder how I can write a user space application that can get the key
> event?  Could somebody help me out?  Because it is an embedded device, th=
ere
> is no X.

Well, one of /dev/tty, /dev/tty0 or /dev/console should work. If you'd
likt to use the new'n'fancy style, use /dev/input/eventX .

MfG, JBG

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

--JMCz+drDJ1SjddZX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFAfZ4+Hb1edYOZ4bsRAtgSAJ9dXSGVPTKKo3wTPHEGDAXw97j6qwCfQetG
XkGcwwZk7KvbiM+bl6RYJT4=
=kdun
-----END PGP SIGNATURE-----

--JMCz+drDJ1SjddZX--

From Jiang.Xu@echostar.com Wed Apr 14 21:31:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 21:31:32 +0100 (BST)
Received: from mailout2.echostar.com ([IPv6:::ffff:204.76.128.102]:28679 "EHLO
	mailout2.echostar.com") by linux-mips.org with ESMTP
	id <S8225747AbUDNUbb> convert rfc822-to-8bit; Wed, 14 Apr 2004 21:31:31 +0100
Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19)
	id <2LYLS50M>; Wed, 14 Apr 2004 14:31:24 -0600
Message-ID: <F71A246055866844B66AFEB10654E7860F1B0C@riv-exchb6.echostar.com>
From: "Xu, Jiang" <Jiang.Xu@echostar.com>
To: linux-mips@linux-mips.org
Subject: RE: questions about keyboard
Date: Wed, 14 Apr 2004 14:31:18 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Return-Path: <Jiang.Xu@echostar.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4780
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Jiang.Xu@echostar.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1523
Lines: 41

Well, this is the problem.
For some reasons, none of the /dev/tty /dev/tty0... /dev/console is
connected to the keyboard, I have tried listening all of them.  Did I
configured something wrong? But kernel seems to be getting the key event
from the keyboard.
Another question is if it should connect to one of those device nodes, is
there anyway I can hack the kernel to see where the key event sent to?

Thanks

John


-----Original Message-----
From: Jan-Benedict Glaw [mailto:jbglaw@lug-owl.de] 
Sent: Wednesday, April 14, 2004 2:26 PM
To: linux-mips@linux-mips.org
Subject: Re: questions about keyboard


On Wed, 2004-04-14 14:18:18 -0600, Xu, Jiang <Jiang.Xu@echostar.com> wrote
in message <F71A246055866844B66AFEB10654E7860F1B0B@riv-exchb6.echostar.com>:
> However, what I don't get is how can I get the key event from the 
> kernel?  I tried to listen to all the ttyN, but none of them connect to
the keyboard.
> I wonder how I can write a user space application that can get the key
> event?  Could somebody help me out?  Because it is an embedded device,
there
> is no X.

Well, one of /dev/tty, /dev/tty0 or /dev/console should work. If you'd likt
to use the new'n'fancy style, use /dev/input/eventX .

MfG, JBG

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

From geert@linux-m68k.org Wed Apr 14 21:36:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 21:36:43 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:51595 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225742AbUDNUgm>;
	Wed, 14 Apr 2004 21:36:42 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i3EKaa4P000042;
	Wed, 14 Apr 2004 22:36:39 +0200 (MEST)
Date: Wed, 14 Apr 2004 22:36:36 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Xu, Jiang" <Jiang.Xu@echostar.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: RE: questions about keyboard
In-Reply-To: <F71A246055866844B66AFEB10654E7860F1B0C@riv-exchb6.echostar.com>
Message-ID: <Pine.GSO.4.58.0404142235540.22408@waterleaf.sonytel.be>
References: <F71A246055866844B66AFEB10654E7860F1B0C@riv-exchb6.echostar.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4781
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1670
Lines: 43

On Wed, 14 Apr 2004, Xu, Jiang wrote:
> Well, this is the problem.
> For some reasons, none of the /dev/tty /dev/tty0... /dev/console is
> connected to the keyboard, I have tried listening all of them.  Did I
> configured something wrong? But kernel seems to be getting the key event
> from the keyboard.
> Another question is if it should connect to one of those device nodes, is
> there anyway I can hack the kernel to see where the key event sent to?

Do you have CONFIG_VT=y? I guess not.

Do you receive anything on /dev/input/eventX?

> -----Original Message-----
> From: Jan-Benedict Glaw [mailto:jbglaw@lug-owl.de]
> Sent: Wednesday, April 14, 2004 2:26 PM
> To: linux-mips@linux-mips.org
> Subject: Re: questions about keyboard
>
>
> On Wed, 2004-04-14 14:18:18 -0600, Xu, Jiang <Jiang.Xu@echostar.com> wrote
> in message <F71A246055866844B66AFEB10654E7860F1B0B@riv-exchb6.echostar.com>:
> > However, what I don't get is how can I get the key event from the
> > kernel?  I tried to listen to all the ttyN, but none of them connect to
> the keyboard.
> > I wonder how I can write a user space application that can get the key
> > event?  Could somebody help me out?  Because it is an embedded device,
> there
> > is no X.
>
> Well, one of /dev/tty, /dev/tty0 or /dev/console should work. If you'd likt
> to use the new'n'fancy style, use /dev/input/eventX .

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 Jiang.Xu@echostar.com Wed Apr 14 21:56:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 21:56:44 +0100 (BST)
Received: from mailout1.echostar.com ([IPv6:::ffff:204.76.128.101]:40714 "EHLO
	mailout1.echostar.com") by linux-mips.org with ESMTP
	id <S8225742AbUDNU4n>; Wed, 14 Apr 2004 21:56:43 +0100
Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19)
	id <2LYLTAR0>; Wed, 14 Apr 2004 14:56:25 -0600
Message-ID: <F71A246055866844B66AFEB10654E7860F1B0D@riv-exchb6.echostar.com>
From: "Xu, Jiang" <Jiang.Xu@echostar.com>
To: 'Geert Uytterhoeven' <geert@linux-m68k.org>
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: RE: questions about keyboard
Date: Wed, 14 Apr 2004 14:56:20 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Return-Path: <Jiang.Xu@echostar.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4782
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Jiang.Xu@echostar.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2663
Lines: 81

I do turn on CONFIG_VT, if I don't I will not be able to pass compiling the
keyboard.c and some other stuffs.
Because I did not turn on INPUT_EVDEV, so I did not create the device node
before. 

However, I just gave it a quick try by turning on INPUT_EVDEV and create the
device nodes; and actually I saw response on input/event0!! Thanks!

Now I have some questions:
1.  I have CONFIG_VT on, so why ttyN is not connected to the device? I saw
console.o and tty_io.o, etc.
What may be wrong or did I miss doing some things that I should do?
2.  In the application, how can I know which input/event# the usb keyboard
connects to?
3.  Is there some reference documents about how to read things from
input/event# ? I mean such as how to read key event?

Thanks

John




-----Original Message-----
From: Geert Uytterhoeven [mailto:geert@linux-m68k.org] 
Sent: Wednesday, April 14, 2004 2:37 PM
To: Xu, Jiang
Cc: Linux/MIPS Development
Subject: RE: questions about keyboard


On Wed, 14 Apr 2004, Xu, Jiang wrote:
> Well, this is the problem.
> For some reasons, none of the /dev/tty /dev/tty0... /dev/console is 
> connected to the keyboard, I have tried listening all of them.  Did I 
> configured something wrong? But kernel seems to be getting the key 
> event from the keyboard. Another question is if it should connect to 
> one of those device nodes, is there anyway I can hack the kernel to 
> see where the key event sent to?

Do you have CONFIG_VT=y? I guess not.

Do you receive anything on /dev/input/eventX?

> -----Original Message-----
> From: Jan-Benedict Glaw [mailto:jbglaw@lug-owl.de]
> Sent: Wednesday, April 14, 2004 2:26 PM
> To: linux-mips@linux-mips.org
> Subject: Re: questions about keyboard
>
>
> On Wed, 2004-04-14 14:18:18 -0600, Xu, Jiang <Jiang.Xu@echostar.com> 
> wrote in message 
> <F71A246055866844B66AFEB10654E7860F1B0B@riv-exchb6.echostar.com>:
> > However, what I don't get is how can I get the key event from the 
> > kernel?  I tried to listen to all the ttyN, but none of them connect 
> > to
> the keyboard.
> > I wonder how I can write a user space application that can get the 
> > key event?  Could somebody help me out?  Because it is an embedded 
> > device,
> there
> > is no X.
>
> Well, one of /dev/tty, /dev/tty0 or /dev/console should work. If you'd 
> likt to use the new'n'fancy style, use /dev/input/eventX .

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 brm@murphy.dk Wed Apr 14 22:26:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 22:26:46 +0100 (BST)
Received: from [IPv6:::ffff:217.157.140.228] ([IPv6:::ffff:217.157.140.228]:6996
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225742AbUDNV0o>; Wed, 14 Apr 2004 22:26:44 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 1BDru0-0000aY-00; Wed, 14 Apr 2004 23:26:36 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.5] LASAT ndelay changes
Cc: linux-mips@linux-mips.org
Message-Id: <E1BDru0-0000aY-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Wed, 14 Apr 2004 23:26:36 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4783
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 5858
Lines: 214

Hi Ralf,
	this brings back lasat_ndelay which is necessary because the eeprom
containing information about memory sizes (among other things) needs ndelay
very early on, before it is calibrated. You removed this code in a cleanup
round a long time ago but it really is necessary for the system to work.
The rtc also uses a bit-banging interface and is read before ndelay is
calibrated (using the rtc).

Initcalls now have a return code.

There was an unused variable left after a cleanup.

Please apply when you have time. I will come and poke you some day
soon if you don't ;).

/Brian

Index: arch/mips/lasat/at93c.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/at93c.c,v
retrieving revision 1.2
diff -u -r1.2 at93c.c
--- arch/mips/lasat/at93c.c	25 Feb 2003 22:39:02 -0000	1.2
+++ arch/mips/lasat/at93c.c	14 Apr 2004 18:49:04 -0000
@@ -41,9 +41,9 @@
 static void at93c_cycle_clk(u32 data)
 {
 	at93c_reg_write(data | at93c->clk);
-	ndelay(250);
+	lasat_ndelay(250);
 	at93c_reg_write(data & ~at93c->clk);
-	ndelay(250);
+	lasat_ndelay(250);
 }
 
 static void at93c_write_databit(u8 bit)
@@ -55,7 +55,7 @@
 		data &= ~(1 << at93c->wdata_shift);
 
 	at93c_reg_write(data);
-	ndelay(100);
+	lasat_ndelay(100);
 	at93c_cycle_clk(data);
 }
 
@@ -95,13 +95,13 @@
 static void at93c_init_op(void)
 {
 	at93c_reg_write((at93c_reg_read() | at93c->cs) & ~at93c->clk & ~(1 << at93c->rdata_shift));
-	ndelay(50);
+	lasat_ndelay(50);
 }
 
 static void at93c_end_op(void)
 {
 	at93c_reg_write(at93c_reg_read() & ~at93c->cs);
-	ndelay(250);
+	lasat_ndelay(250);
 }
 
 static void at93c_wait(void) 
Index: arch/mips/lasat/ds1603.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/ds1603.c,v
retrieving revision 1.3
diff -u -r1.3 ds1603.c
--- arch/mips/lasat/ds1603.c	25 Feb 2003 22:39:02 -0000	1.3
+++ arch/mips/lasat/ds1603.c	14 Apr 2004 19:05:57 -0000
@@ -51,14 +51,14 @@
 {
 	data |= ds1603->clk;
 	rtc_reg_write(data);
-	ndelay(250);
+	lasat_ndelay(250);
 	if (ds1603->data_reversed)
 		data &= ~ds1603->data;
 	else
 		data |= ds1603->data;
 	data &= ~ds1603->clk;
 	rtc_reg_write(data);
-	ndelay(250 + ds1603->huge_delay);
+	lasat_ndelay(250 + ds1603->huge_delay);
 }
 
 static void rtc_write_databit(unsigned int bit)
@@ -72,7 +72,7 @@
 		data &= ~ds1603->data;
 
 	rtc_reg_write(data);
-	ndelay(50 + ds1603->huge_delay);
+	lasat_ndelay(50 + ds1603->huge_delay);
 	rtc_cycle_clock(data);
 }
 
@@ -125,13 +125,13 @@
 
 	rtc_reg_write(rtc_reg_read() & ~ds1603->clk);
 
-	ndelay(50);
+	lasat_ndelay(50);
 }
 
 static void rtc_end_op(void)
 {
 	rtc_nrst_low();
-	ndelay(1000);
+	lasat_ndelay(1000);
 }
 
 /* interface */
Index: arch/mips/lasat/interrupt.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/interrupt.c,v
retrieving revision 1.10
diff -u -r1.10 interrupt.c
--- arch/mips/lasat/interrupt.c	13 Apr 2004 22:07:45 -0000	1.10
+++ arch/mips/lasat/interrupt.c	13 Apr 2004 22:35:54 -0000
@@ -112,7 +112,6 @@
 
 void lasat_hw0_irqdispatch(struct pt_regs *regs)
 {
-	struct irqaction *action;
 	unsigned long int_status;
 	int irq;
 
Index: arch/mips/lasat/prom.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/prom.c,v
retrieving revision 1.9
diff -u -r1.9 prom.c
--- arch/mips/lasat/prom.c	28 Jan 2004 22:16:39 -0000	1.9
+++ arch/mips/lasat/prom.c	14 Apr 2004 19:00:10 -0000
@@ -46,6 +46,8 @@
 		null_prom_display;
 void (* prom_monitor)(void) = null_prom_monitor;
 
+unsigned int lasat_ndelay_divider;
+
 #define PROM_PRINTFBUF_SIZE 256
 static char prom_printfbuf[PROM_PRINTFBUF_SIZE];
 
@@ -98,10 +100,15 @@
 
 	setup_prom_vectors();
 
-	if (current_cpu_data.cputype == CPU_R5000)
+	if (current_cpu_data.cputype == CPU_R5000) {
+	        prom_printf("LASAT 200 board\n");
 		mips_machtype = MACH_LASAT_200;
-	else
+                lasat_ndelay_divider = LASAT_200_DIVIDER;
+        } else {
+	        prom_printf("LASAT 100 board\n");
 		mips_machtype = MACH_LASAT_100;
+                lasat_ndelay_divider = LASAT_100_DIVIDER;
+        }
 
 	at93c = &at93c_defs[mips_machtype];
 
Index: arch/mips/lasat/setup.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/setup.c,v
retrieving revision 1.13
diff -u -r1.13 setup.c
--- arch/mips/lasat/setup.c	13 Apr 2004 22:07:45 -0000	1.13
+++ arch/mips/lasat/setup.c	13 Apr 2004 22:27:54 -0000
@@ -155,7 +155,7 @@
 }
 #endif
 
-static void __init lasat_setup(void)
+static int __init lasat_setup(void)
 {
 	int i;
 	lasat_misc  = &lasat_misc_info[mips_machtype];
@@ -185,6 +185,8 @@
 	change_c0_status(ST0_BEV,0);
 
 	prom_printf("Lasat specific initialization complete\n");
+
+        return 0;
 }
 
 early_initcall(lasat_setup);
Index: include/asm-mips/lasat/lasat.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/lasat/lasat.h,v
retrieving revision 1.4
diff -u -r1.4 lasat.h
--- include/asm-mips/lasat/lasat.h	6 Jun 2003 11:47:49 -0000	1.4
+++ include/asm-mips/lasat/lasat.h	14 Apr 2004 21:14:39 -0000
@@ -220,7 +220,22 @@
 #define N_MACHTYPES		2
 /* for calibration of delays */
 
+/* the lasat_ndelay function is necessary because it is used at an 
+ * early stage of the boot process where ndelay is not calibrated.
+ * It is used for the bit-banging rtc and eeprom drivers */
+
 #include <asm/delay.h>
+/* calculating with the slowest board with 100 MHz clock */
+#define LASAT_100_DIVIDER 20
+/* All 200's run at 250 MHz clock */
+#define LASAT_200_DIVIDER 8
+
+extern unsigned int lasat_ndelay_divider;
+
+static inline void lasat_ndelay(unsigned int ns)
+{
+            __delay(ns / lasat_ndelay_divider);
+}
 
 extern void (* prom_printf)(const char *fmt, ...);
 

From pdh@colonel-panic.org Wed Apr 14 23:53:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Apr 2004 23:53:40 +0100 (BST)
Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:32385 "EHLO
	skeleton-jack.localnet") by linux-mips.org with ESMTP
	id <S8225738AbUDNWxj>; Wed, 14 Apr 2004 23:53:39 +0100
Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian))
	id 1BDtG5-0001M0-00
	for <linux-mips@linux-mips.org>; Wed, 14 Apr 2004 23:53:29 +0100
Date: Wed, 14 Apr 2004 23:53:29 +0100
To: linux-mips@linux-mips.org
Subject: BUG() in sys_swapon
Message-ID: <20040414225329.GA4842@skeleton-jack>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.5.1+cvs20040105i
From: Peter Horton <pdh@colonel-panic.org>
Return-Path: <pdh@colonel-panic.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: 4784
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pdh@colonel-panic.org
Precedence: bulk
X-list: linux-mips
Content-Length: 427
Lines: 15

The current 2.6.x tree running on a Cobalt Qube throws an OOPS from
sys_swapon().

It looks like this is because line 1257 in r1.89 of mm/swapfile.c
(2.6.x) compiles to a BUG().

    ... swp_type(pte_to_swp_entry(swp_entry_to_pte(swp_entry(~0UL,0)))))

swp_entry(~0UL,0)			--> f800_0000
swp_entry_to_pte(f800_0000)
    __swp_entry(1f, 0000_0000)		--> 0000_003e
    pte_file(0000_003e)			--> 0000_0010
    BUG_ON(0000_0010)

P.

From ralf@linux-mips.org Thu Apr 15 03:57:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Apr 2004 03:57:14 +0100 (BST)
Received: from p508B780A.dip.t-dialin.net ([IPv6:::ffff:80.139.120.10]:52515
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225754AbUDOC5L>; Thu, 15 Apr 2004 03:57:11 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3F2v8xr028364;
	Thu, 15 Apr 2004 04:57:08 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3F2v8UX028363;
	Thu, 15 Apr 2004 04:57:08 +0200
Date: Thu, 15 Apr 2004 04:57:08 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Ashley Evans <ashley@seamlessrecruitment.com>
Cc: linux-mips@linux-mips.org
Subject: Re: R4400MC
Message-ID: <20040415025708.GA27738@linux-mips.org>
References: <407BC212.8000303@seamlessrecruitment.com> <20040414125200.GA9206@linux-mips.org> <407D5CDA.6070407@seamlessrecruitment.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <407D5CDA.6070407@seamlessrecruitment.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: 4785
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 409
Lines: 12

On Wed, Apr 14, 2004 at 04:46:34PM +0100, Ashley Evans wrote:

> Thanks, just thought I'd ask.
> 
> I believe it's the cache controller that's the problem? I don't have the 
> skills to do it myself but if somebody could explain the issue i'd like 
> to know?

No, the cache controller is really the same as in the SC CPU which is
already supported.  The problem is everything else around the CPU ...

  Ralf

From jbglaw@dvmwest.gt.owl.de Thu Apr 15 09:36:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Apr 2004 09:36:21 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:30135 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225736AbUDOIgN>; Thu, 15 Apr 2004 09:36:13 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 1647D4B5F1; Thu, 15 Apr 2004 10:36:10 +0200 (CEST)
Date: Thu, 15 Apr 2004 10:36:09 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: questions about keyboard
Message-ID: <20040415083609.GU630@lug-owl.de>
Mail-Followup-To: Linux/MIPS Development <linux-mips@linux-mips.org>
References: <F71A246055866844B66AFEB10654E7860F1B0D@riv-exchb6.echostar.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="xbjSOCWVZ1q9zj4g"
Content-Disposition: inline
In-Reply-To: <F71A246055866844B66AFEB10654E7860F1B0D@riv-exchb6.echostar.com>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4787
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2172
Lines: 71


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

On Wed, 2004-04-14 14:56:20 -0600, Xu, Jiang <Jiang.Xu@echostar.com>
wrote in message <F71A246055866844B66AFEB10654E7860F1B0D@riv-exchb6.echosta=
r.com>:
> 2.  In the application, how can I know which input/event# the usb keyboard
> connects to?

You don't. You can

	- Hope that your keyboard is the one and only device...
	- Read /proc/bus/input/devices - there should be a "kbd" handler
	  in the "H: " section
	- select() on all event* devices and just only process
	  keypresses generated from "normal" keys.

> 3.  Is there some reference documents about how to read things from
> input/event# ? I mean such as how to read key event?

I don't think there's really good docu available, but it's really
simple. Just open all devices, select() until there's data available (or
just call a blocking read() on it). Something like this should work, but
you'd better add error checking to the open() call...

#include <linux/input.h>

ssize_t ret;
struct input_event my_input;
int fd;

fd =3D open ("/dev/input/event0", O_RDONLY);
for (;;) {
	ret =3D read (fd, &my_input, sizeof (my_input));
	if (ret !=3D sizeof (my_input)
		break;

	if (my_input.type !=3D EV_KEY)
		continue;
	/* my_input.code and my_input.type now contain the key and
	   press/release state; refer to the #defines in linux/input.h
	   for the mapping .code -> ASCII value */
}
close (fd);


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

--xbjSOCWVZ1q9zj4g
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFAfkl5Hb1edYOZ4bsRAph9AJ9nVPP0TBtiqgmMoma7lwaqcw59SwCggZrv
hBwPnfb9+Hj4tX5v6JpsF20=
=DmoR
-----END PGP SIGNATURE-----

--xbjSOCWVZ1q9zj4g--

From hjl@lucon.org Thu Apr 15 16:48:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Apr 2004 16:48:45 +0100 (BST)
Received: from sccrmhc13.comcast.net ([IPv6:::ffff:204.127.202.64]:27063 "EHLO
	sccrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8225740AbUDOPsn>; Thu, 15 Apr 2004 16:48:43 +0100
Received: from lucon.org ([24.6.43.109]) by comcast.net (sccrmhc13) with ESMTP
          id <20040415154827016003er10e>; Thu, 15 Apr 2004 15:48:35 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 4BF9764D14; Thu, 15 Apr 2004 08:48:24 -0700 (PDT)
Date: Thu, 15 Apr 2004 08:48:24 -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.15.90.0.3 is released
Message-ID: <20040415154824.GA28202@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: 4788
X-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
Content-Length: 5139
Lines: 187

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

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

If you don't use

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

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

Changes from binutils 2.15.90.0.2:

1. Update from binutils 2004 0415.
2. Fix the linker for weak undefined symbol handling.
3. Fix the ELF/Sparc and ELF/Sparc64 linker for statically linking PIC
code.

Changes from binutils 2.15.90.0.1.1:

1. Update from binutils 2004 0412.
2. Add --as-needed/--no-as-needed to linker.
3. Fix -z defs in linker.
4. Always reserve the memory for ia64 dynamic linker.
5. Fix a race condition in ia64 lazy binding.

Changes from binutils 2.15.90.0.1:

1. Fixed an ia64 assembler bug.
2. Install the assembler man page.

Changes from binutils 2.14.90.0.8:

1. Update from binutils 2004 0303.
2. Fixed linker for undefined symbols with non-default visibility.
3. Sped up linker weakdef symbol handling.
4. Fixed mixing ELF32 and ELF64 object files in archive.
5. Added ia64 linker brl optimization.
6. Fixed ia64 linker to disallow invalid dynamic relocations.
7. Fixed DT_TEXTREL handling in ia64 linker.
8. Fixed alignment handling in ia64 assembler.
9. Improved ia64 assembler unwind table handling. 

Changes from binutils 2.14.90.0.7:

1. Update from binutils 2004 0114.
2. Fixed an ia64 assembler unwind table bug. 
3. Better handle IPF linker relaxation overflow.
4. Fixed misc PPC bugs.

Changes from binutils 2.14.90.0.6:

1. Update from binutils 2003 1029.
2. Allow type changes for undefined symbols.
3. Fix EH frame optimization.
4. Fix the check for undefined versioned symbol with wildcard.
5. Support generating code for Itanium.
6. Detect and warn bad symbol index.
7. Update IPF assemebler DV check.

Changes from binutils 2.14.90.0.5:

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

Changes from binutils 2.14.90.0.4.1:

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

Changes from binutils 2.14.90.0.4:
 
1. Fix an ia64 assembler hint@pause bug.
2. Support Intel 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.15.90.0.3.tar.bz2. Source code.
2. binutils-2.15.90.0.2-2.15.90.0.3.diff.bz2. Patch against the
   previous beta source code.
3. binutils-2.15.90.0.3-1.i386.rpm. IA-32 binary RPM for RedHat EL 3.
4. binutils-2.15.90.0.3-1.ia64.rpm. IA-64 binary RPM for RedHat EL 3.
5. binutils-2.15.90.0.3-1.x86_64.rpm. X64_64 binary RPM for RedHat EL 3.

There is no separate source rpm. You can do

# rpmbuild -ta binutils-2.15.90.0.3.tar.bz2

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
04/15/2004

From Jiang.Xu@echostar.com Thu Apr 15 21:09:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Apr 2004 21:09:14 +0100 (BST)
Received: from mailout2.echostar.com ([IPv6:::ffff:204.76.128.102]:38408 "EHLO
	mailout2.echostar.com") by linux-mips.org with ESMTP
	id <S8224947AbUDOUJN> convert rfc822-to-8bit; Thu, 15 Apr 2004 21:09:13 +0100
Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19)
	id <2LYLZNKH>; Thu, 15 Apr 2004 14:08:58 -0600
Message-ID: <F71A246055866844B66AFEB10654E7860F1B10@riv-exchb6.echostar.com>
From: "Xu, Jiang" <Jiang.Xu@echostar.com>
To: 'Jan-Benedict Glaw' <jbglaw@lug-owl.de>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: RE: questions about keyboard
Date: Thu, 15 Apr 2004 14:08:54 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Return-Path: <Jiang.Xu@echostar.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4790
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Jiang.Xu@echostar.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2721
Lines: 92

Thanks for the reply, I did some testing and found some interesting things:

1.  Everytime I push the key on the keyboard, I can see something out from
/dev/input/event0 by "cat /dev/input/event0".
However, I don't see a directory named "proc/input", did I miss configure
something in the kernel?
2.  read() does work and is a blocking read.  However, if I use select, then
it does not work.
Select() never detects the state change.
Here is the sample code I am using:
{
   int test_fd = -1;
   fd_set rfds;
   struct timeval tv;
  
   tv.tv_sec = 1;
   tv.tv_usec = 0;
   test_fd = open("/dev/input/event0", O_RDONLY); 
   if( test_fd < 0 )
     exit(0);
   
   while( 1 )
   {	
	FD_ZERO(&rfds);
	FD_SET(test_fd, &rfds);
      retval = select( 1, &rfds, NULL, NULL, &tv );
      if( retval )
         printf("\nDetects something....");
   }
}

What could be wrong?

Thanks

John

-----Original Message-----
From: Jan-Benedict Glaw [mailto:jbglaw@lug-owl.de] 
Sent: Thursday, April 15, 2004 2:36 AM
To: Linux/MIPS Development
Subject: Re: questions about keyboard


On Wed, 2004-04-14 14:56:20 -0600, Xu, Jiang <Jiang.Xu@echostar.com> wrote
in message <F71A246055866844B66AFEB10654E7860F1B0D@riv-exchb6.echostar.com>:
> 2.  In the application, how can I know which input/event# the usb 
> keyboard connects to?

You don't. You can

	- Hope that your keyboard is the one and only device...
	- Read /proc/bus/input/devices - there should be a "kbd" handler
	  in the "H: " section
	- select() on all event* devices and just only process
	  keypresses generated from "normal" keys.

> 3.  Is there some reference documents about how to read things from 
> input/event# ? I mean such as how to read key event?

I don't think there's really good docu available, but it's really simple.
Just open all devices, select() until there's data available (or just call a
blocking read() on it). Something like this should work, but you'd better
add error checking to the open() call...

#include <linux/input.h>

ssize_t ret;
struct input_event my_input;
int fd;

fd = open ("/dev/input/event0", O_RDONLY);
for (;;) {
	ret = read (fd, &my_input, sizeof (my_input));
	if (ret != sizeof (my_input)
		break;

	if (my_input.type != EV_KEY)
		continue;
	/* my_input.code and my_input.type now contain the key and
	   press/release state; refer to the #defines in linux/input.h
	   for the mapping .code -> ASCII value */
}
close (fd);


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

From jbglaw@dvmwest.gt.owl.de Thu Apr 15 21:22:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Apr 2004 21:22:22 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:35274 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225208AbUDOUWU>; Thu, 15 Apr 2004 21:22:20 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id CCBC24B65F; Thu, 15 Apr 2004 22:22:18 +0200 (CEST)
Date: Thu, 15 Apr 2004 22:22:18 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: questions about keyboard
Message-ID: <20040415202218.GI630@lug-owl.de>
Mail-Followup-To: Linux/MIPS Development <linux-mips@linux-mips.org>
References: <F71A246055866844B66AFEB10654E7860F1B10@riv-exchb6.echostar.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="4YfhVOqjnG2FJTMT"
Content-Disposition: inline
In-Reply-To: <F71A246055866844B66AFEB10654E7860F1B10@riv-exchb6.echostar.com>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4791
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2445
Lines: 88


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

On Thu, 2004-04-15 14:08:54 -0600, Xu, Jiang <Jiang.Xu@echostar.com>
wrote in message <F71A246055866844B66AFEB10654E7860F1B10@riv-exchb6.echosta=
r.com>:
> Thanks for the reply, I did some testing and found some interesting thing=
s:
>=20
> 1.  Everytime I push the key on the keyboard, I can see something out from
> /dev/input/event0 by "cat /dev/input/event0".
> However, I don't see a directory named "proc/input", did I miss configure
> something in the kernel?

Maybe your kernel isn't configured with CONFIG_PROC_FS=3Dy ?
Maybe it's not mounted?

> 2.  read() does work and is a blocking read.  However, if I use select, t=
hen
> it does not work.
> Select() never detects the state change.
> Here is the sample code I am using:
> {
>    int test_fd =3D -1;

No need to initialize - you're assigning a value before accessing it.

>    fd_set rfds;
>    struct timeval tv;
>  =20
>    tv.tv_sec =3D 1;
>    tv.tv_usec =3D 0;

tv_* need to be set before *every* select () invocation, not only once.

>    test_fd =3D open("/dev/input/event0", O_RDONLY);=20
>    if( test_fd < 0 )
>      exit(0);
>   =20
>    while( 1 )
>    {=09
> 	FD_ZERO(&rfds);
> 	FD_SET(test_fd, &rfds);
>       retval =3D select( 1, &rfds, NULL, NULL, &tv );

That's wrong. The "1" should be "fd + 1".

>       if( retval )
>          printf("\nDetects something....");

A negative retval would also be !=3D 0 ...

>    }
> }
>=20
> What could be wrong?

Most probably it's the hardcoded "1" with the select. That is, select
only looks at all fd's which are smaller than one, so only fd=3D0 would be
testes, but this one isn't in the set, so...

MfG, JBG

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

--4YfhVOqjnG2FJTMT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFAfu76Hb1edYOZ4bsRAi9xAKCSP9oll0gcfiozDmwAZFX3jEFRMwCfd01l
+wjn2UcvlkkyjTv+n2mBgRU=
=HFCE
-----END PGP SIGNATURE-----

--4YfhVOqjnG2FJTMT--

From Jiang.Xu@echostar.com Thu Apr 15 21:44:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Apr 2004 21:44:40 +0100 (BST)
Received: from mailout2.echostar.com ([IPv6:::ffff:204.76.128.102]:49926 "EHLO
	mailout2.echostar.com") by linux-mips.org with ESMTP
	id <S8224952AbUDOUoj> convert rfc822-to-8bit; Thu, 15 Apr 2004 21:44:39 +0100
Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19)
	id <2LYLZ4DX>; Thu, 15 Apr 2004 14:44:29 -0600
Message-ID: <F71A246055866844B66AFEB10654E7860F1B11@riv-exchb6.echostar.com>
From: "Xu, Jiang" <Jiang.Xu@echostar.com>
To: 'Jan-Benedict Glaw' <jbglaw@lug-owl.de>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: RE: questions about keyboard
Date: Thu, 15 Apr 2004 14:44:25 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Return-Path: <Jiang.Xu@echostar.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4792
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Jiang.Xu@echostar.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2673
Lines: 89

I really really appreciate your help.  
That is a very stupid bug, I should review my code more carefully before I
sent out for help.  Sorry about that, I guess somehow my brain just messed
up.  

Anyway, I did turn on the CONFIG_PROC_FS.  
I also mount the usb by "mount -t usbdevfs none /proc/bus/usb"; and if I
"cat /proc/filesystems" it does show "usbdevfs".  
However, is there a "inputdevfs" and is there a similar command line such as
"mount -t inputdevfs none /proc/bus/input"?
I don't see anything like "CONFIG_INPUT_DEVICEFS"?
I am using 2.4.18 kernel.

Thanks

John


-----Original Message-----
From: Jan-Benedict Glaw [mailto:jbglaw@lug-owl.de] 
Sent: Thursday, April 15, 2004 2:22 PM
To: Linux/MIPS Development
Subject: Re: questions about keyboard


On Thu, 2004-04-15 14:08:54 -0600, Xu, Jiang <Jiang.Xu@echostar.com> wrote
in message <F71A246055866844B66AFEB10654E7860F1B10@riv-exchb6.echostar.com>:
> Thanks for the reply, I did some testing and found some interesting 
> things:
> 
> 1.  Everytime I push the key on the keyboard, I can see something out 
> from /dev/input/event0 by "cat /dev/input/event0". However, I don't 
> see a directory named "proc/input", did I miss configure something in 
> the kernel?

Maybe your kernel isn't configured with CONFIG_PROC_FS=y ? Maybe it's not
mounted?

> 2.  read() does work and is a blocking read.  However, if I use 
> select, then it does not work.
> Select() never detects the state change.
> Here is the sample code I am using:
> {
>    int test_fd = -1;

No need to initialize - you're assigning a value before accessing it.

>    fd_set rfds;
>    struct timeval tv;
>   
>    tv.tv_sec = 1;
>    tv.tv_usec = 0;

tv_* need to be set before *every* select () invocation, not only once.

>    test_fd = open("/dev/input/event0", O_RDONLY); 
>    if( test_fd < 0 )
>      exit(0);
>    
>    while( 1 )
>    {	
> 	FD_ZERO(&rfds);
> 	FD_SET(test_fd, &rfds);
>       retval = select( 1, &rfds, NULL, NULL, &tv );

That's wrong. The "1" should be "fd + 1".

>       if( retval )
>          printf("\nDetects something....");

A negative retval would also be != 0 ...

>    }
> }
> 
> What could be wrong?

Most probably it's the hardcoded "1" with the select. That is, select only
looks at all fd's which are smaller than one, so only fd=0 would be testes,
but this one isn't in the set, so...

MfG, JBG

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

From jykim@torinet.co.kr Fri Apr 16 00:47:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Apr 2004 00:47:42 +0100 (BST)
Received: from [IPv6:::ffff:222.98.69.125] ([IPv6:::ffff:222.98.69.125]:38599
	"EHLO torinet.co.kr") by linux-mips.org with ESMTP
	id <S8225222AbUDOXrc>; Fri, 16 Apr 2004 00:47:32 +0100
Received: from stephen ([222.98.69.120])
	by torinet.co.kr (8.12.8/8.12.8) with ESMTP id i3G0a65i008854
	for <linux-mips@linux-mips.org>; Fri, 16 Apr 2004 09:36:07 +0900
Message-Id: <200404160036.i3G0a65i008854@torinet.co.kr>
From: "JinYoung Kim" <jykim@torinet.co.kr>
To: <linux-mips@linux-mips.org>
Subject: large memory support on  kernel 2.4.21 for 64bit on sb1250?
Date: Fri, 16 Apr 2004 08:47:43 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
thread-index: AcQiEc+4hUP/KmzdSuWfWLV9eA05Xw==
Return-Path: <jykim@torinet.co.kr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4793
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jykim@torinet.co.kr
Precedence: bulk
X-list: linux-mips
Content-Length: 486
Lines: 21

Hello,
 
Is large memory support stable on kernel 2.4.21 with broadcom patch 1 and 2?
 
Would anybody test followingscenrio with BCM91250 reference board or your
own?
 
run ping fluding background to any system from the board.
run it again.
run ping fluding to the board from the system above.
 
panic (page fault) or DBE error occured immediately in my test.
 
I have 2GB main memory, but samething happend on 512MB.
32bit kernel does not have any problem.
 
Jin
 
vroom@magicn.com
 


From yiwang1@umbc.edu Fri Apr 16 03:52:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Apr 2004 03:52:24 +0100 (BST)
Received: from mx3out.umbc.edu ([IPv6:::ffff:130.85.25.12]:60340 "EHLO
	mx3out.umbc.edu") by linux-mips.org with ESMTP id <S8225747AbUDPCwX>;
	Fri, 16 Apr 2004 03:52:23 +0100
Received: from webmail.umbc.edu (nuts.umbc.edu [130.85.24.70])
	by mx3out.umbc.edu (8.12.10/8.12.10/UMBC-Central 1.1.2.1  mxout  1.2.2.3) with SMTP id i3G2qKD2008613
	for <linux-mips@linux-mips.org>; Thu, 15 Apr 2004 22:52:20 -0400 (EDT)
Received: from 130.85.168.85
        (SquirrelMail authenticated user yiwang1)
        by webmail.umbc.edu with HTTP;
        Thu, 15 Apr 2004 22:52:20 -0400 (EDT)
Message-ID: <1279.130.85.168.85.1082083940.squirrel@webmail.umbc.edu>
Date: Thu, 15 Apr 2004 22:52:20 -0400 (EDT)
Subject: building mips cross compiler -- an error when compiling glibc
From: yiwang1@umbc.edu
To: linux-mips@linux-mips.org
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3
Importance: Normal
X-AvMilter-Key: 1082084241:d60ea87feda58c82b300969e60e17056
X-Avmilter: Message Skipped, too small
X-Processed-By: MilterMonkey Version 0.9 -- http://www.membrain.com/miltermonkey
Return-Path: <yiwang1@umbc.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: 4794
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yiwang1@umbc.edu
Precedence: bulk
X-list: linux-mips
Content-Length: 2715
Lines: 61

Hi, I'm building a mips cross compiler on a i686 machine. The sources I
used are:
gcc-3.2.2
glibc-2.3.2
binutils-2.14.90.0.8
linux-2.4.20

I can successfully finish binutils installation and gcc bootstrap
installation. I also finished copying kernel headers. Then I met a problem
when compiling glibc. The error is like this:
... ...
/home/xmt/mips/bin/mipsel-linuxelf-gcc ../sysdeps/unix/sysv/linux/sa_len.c
-c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings
-mabi=32 -mips3
     -I../include -I. -I/home/doudou/build-glibc/socket -I.. -I../libio 
-I/home/doudou/build-glibc -I../sysdeps/mips/elf
-I../linuxthreads/sysdeps/unix/sysv/linux/mips
-I../linuxthreads/sysdeps/unix/sysv/linux
-I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../linuxthreads/sysdeps/mips -I../sysdeps/unix/sysv/linux/mips
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
-I../sysdeps/unix/common -I../sysdeps/unix/mman
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/mips/mipsel
-I../sysdeps/mips/fpu -I../sysdeps/mips -I../sysdeps/wordsize-32
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64
-I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic 
-nostdinc -isystem
/home/xmt/mips/bin/../lib/gcc-lib/mipsel-linuxelf/3.2.2/include
-isystem /home/xmt/mips/include/ -D_LIBC_REENTRANT -D_LIBC_REENTRANT
-include ../include/libc-symbols.h  -DPIC     -o
/home/doudou/build-glibc/socket/sa_len.o
In file included from /home/xmt/mips/include/linux/config.h:4,
                 from /home/xmt/mips/include/asm/types.h:12,
                 from ../sysdeps/unix/sysv/linux/netatalk/at.h:22,
                 from ../sysdeps/unix/sysv/linux/sa_len.c:22:
/home/xmt/mips/include/linux/autoconf.h:1:2: #error Invalid kernel header
included in userspace
make[2]: *** [/home/doudou/build-glibc/socket/sa_len.o] Error 1
make[2]: Leaving directory `/home/doudou/glibc-2.3.2/socket'
make[1]: *** [socket/subdir_lib] Error 2
make[1]: Leaving directory `/home/doudou/glibc-2.3.2'
make: *** [all] Error 2

The first error is at autoconf.h. My configure command line is:

CC="/home/xmt/mips/bin/mipsel-linuxelf-gcc" CFLAGS="-O2 -mips3 -mabi=32"
AR="/home/xmt/mips/bin/mipsel-linuxelf-ar"
RANLIB="/home/xmt/mips/bin/mipsel-linuxelf-ranlib"
../glibc-2.3.2/configure --prefix=/home/xmt/mips/ --host=mipsel-linuxelf
--build=i686-pc-linux-gnu --without-tls --without-__thread
--enable-add-ons=linuxthreads --enable-kernel=2.4.20 --with-gd=no
--without-cvs --disable-profile --with-headers="/home/xmt/mips/include/"

Any ideas on how to solve this problem? Thanks.

Sam
---------
UMBC


From sskowron@ET.PUT.Poznan.PL Fri Apr 16 22:13:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Apr 2004 22:13:37 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:32248
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225772AbUDPVNf>; Fri, 16 Apr 2004 22:13:35 +0100
Received: from athena (athena [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3GLDTm13849
	for <linux-mips@linux-mips.org>; Fri, 16 Apr 2004 23:13:30 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena (MailMonitor for SMTP v1.2.2 ) ;
	Fri, 16 Apr 2004 23:13:29 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3GLDTp26462
	for <linux-mips@linux-mips.org>; Fri, 16 Apr 2004 23:13:29 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Fri, 16 Apr 2004 23:13:29 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: IP30 goes relatively far now
Message-ID: <Pine.GSO.4.10.10404162305570.25696-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4795
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 1020
Lines: 30

Hello,

I'm currently doing a reverse-engineered IP30 port of Linux-MIPS.
Currently I'm using 2.6.1 as my base.

I don't know if it's been already fixed in >2.6.1, but in genex.S there
should be a 'nop' between 'jal do_\handler' and 'ret_from_exception'. The
symptom is a hang on 'Checking for the daddi bug...'. Somebody apparently
got used to '.set reorder' :P

Well, now the kernel crashes a bit later. Actually, it gets to 'mice: PS/2
mouse device common for all mice' and then gets an Instruction bus error.
I will look into this.

Currently the kernel supports only MGRAS graphics (SI, SSI, MXI, SE, SSE,
MXE) and uniprocessor. I don't have a SMP machine here, but I guess it
would not be particularly hard to do. The ODYSSEY (VPro) would be a bit
harder, as its architecture is vastly different from the MGRAS. Anyone
interested may send me a VPro6 ;)

When I get to 'cannot mount root', I will release the kernel patch.

Yours,

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From florian@void.s.bawue.de Fri Apr 16 22:24:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Apr 2004 22:24:22 +0100 (BST)
Received: from bremen.shuttle.de ([IPv6:::ffff:194.95.249.251]:10425 "EHLO
	bremen.shuttle.de") by linux-mips.org with ESMTP
	id <S8225789AbUDPVYV>; Fri, 16 Apr 2004 22:24:21 +0100
Received: from void.s.bawue.de (a122.shuttle.de [194.95.224.122])
	by bremen.shuttle.de (Postfix) with ESMTP id 4C0D03BBDB
	for <linux-mips@linux-mips.org>; Fri, 16 Apr 2004 23:24:18 +0200 (CEST)
Received: from florian by void.s.bawue.de with local (Exim 3.33 #1 (Debian))
	id 1BEZyB-0000Wh-00; Fri, 16 Apr 2004 22:29:51 +0200
Date: Fri, 16 Apr 2004 22:29:51 +0200
To: linux-mips@linux-mips.org
Subject: Re: IP30 goes relatively far now
Message-ID: <20040416202950.GA1691@void.s.bawue.de>
Mail-Followup-To: Florian Laws <florian@void.s.bawue.de>,
	linux-mips@linux-mips.org
References: <Pine.GSO.4.10.10404162305570.25696-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404162305570.25696-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.5.4i
From: Florian Laws <florian@void.s.bawue.de>
Return-Path: <florian@void.s.bawue.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: 4796
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: florian@void.s.bawue.de
Precedence: bulk
X-list: linux-mips
Content-Length: 565
Lines: 14

On Fri, Apr 16, 2004 at 11:13:29PM +0200, Stanislaw Skowronek wrote:
> 
> Currently the kernel supports only MGRAS graphics (SI, SSI, MXI, SE, SSE,
> MXE) and uniprocessor. I don't have a SMP machine here, but I guess it
> would not be particularly hard to do. The ODYSSEY (VPro) would be a bit
> harder, as its architecture is vastly different from the MGRAS. Anyone
> interested may send me a VPro6 ;)

Aren't the SI, MXI very similiar to the IMPACT graphic boards of the
Indigo2 machines? If so, this might be interesting for IP22/29 as well.

Regards,

Florian

From macro@ds2.pg.gda.pl Fri Apr 16 22:42:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Apr 2004 22:42:57 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:38802 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225792AbUDPVm4>; Fri, 16 Apr 2004 22:42:56 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 7EFE047607; Fri, 16 Apr 2004 23:42:48 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 7116D459C1; Fri, 16 Apr 2004 23:42:48 +0200 (CEST)
Date: Fri, 16 Apr 2004 23:42:48 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: IP30 goes relatively far now
In-Reply-To: <Pine.GSO.4.10.10404162305570.25696-100000@helios.et.put.poznan.pl>
Message-ID: <Pine.LNX.4.55.0404162332150.24278@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404162305570.25696-100000@helios.et.put.poznan.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: 4797
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 647
Lines: 16

On Fri, 16 Apr 2004, Stanislaw Skowronek wrote:

> I don't know if it's been already fixed in >2.6.1, but in genex.S there
> should be a 'nop' between 'jal do_\handler' and 'ret_from_exception'. The
> symptom is a hang on 'Checking for the daddi bug...'. Somebody apparently
> got used to '.set reorder' :P

 The bug is elsewhere -- there's an incorrect extraneous ".set push" in
the file.  I'll commit a fix immediately.

 Thanks for the report.

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

From macro@ds2.pg.gda.pl Fri Apr 16 23:19:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Apr 2004 23:19:08 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:55969 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224802AbUDPWTG>; Fri, 16 Apr 2004 23:19:06 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 5FB414787C; Sat, 17 Apr 2004 00:19:00 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 4E130474E9; Sat, 17 Apr 2004 00:19:00 +0200 (CEST)
Date: Sat, 17 Apr 2004 00:19:00 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: IP30 goes relatively far now
In-Reply-To: <Pine.LNX.4.55.0404162332150.24278@jurand.ds.pg.gda.pl>
Message-ID: <Pine.LNX.4.55.0404170000540.24278@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404162305570.25696-100000@helios.et.put.poznan.pl>
 <Pine.LNX.4.55.0404162332150.24278@jurand.ds.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: 4798
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1166
Lines: 31

On Fri, 16 Apr 2004, Maciej W. Rozycki wrote:

> > I don't know if it's been already fixed in >2.6.1, but in genex.S there
> > should be a 'nop' between 'jal do_\handler' and 'ret_from_exception'. The
> > symptom is a hang on 'Checking for the daddi bug...'. Somebody apparently
> > got used to '.set reorder' :P
> 
>  The bug is elsewhere -- there's an incorrect extraneous ".set push" in
> the file.  I'll commit a fix immediately.

 I must have been blind -- there's a matching ".set pop" elsewhere.  Is a 
"nop" really missing in the output?  I've assembled the file and I can't 
see any problem:

000000000000022c <handle_daddi_ov_int>:
 22c:	0c000000 	jal	0 <except_vec0_generic>
			22c: R_MIPS_26	do_daddi_ov
			22c: R_MIPS_NONE	*ABS*
			22c: R_MIPS_NONE	*ABS*
 230:	03a0202d 	move	a0,sp
 234:	08000000 	j	0 <except_vec0_generic>
			234: R_MIPS_26	ret_from_exception
			234: R_MIPS_NONE	*ABS*
			234: R_MIPS_NONE	*ABS*
 238:	00000000 	nop
 23c:	00000000 	nop

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

From ken@mail.seefried.com Sat Apr 17 04:31:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Apr 2004 04:31:59 +0100 (BST)
Received: from [IPv6:::ffff:65.82.153.254] ([IPv6:::ffff:65.82.153.254]:14760
	"HELO mail.seefried.com") by linux-mips.org with SMTP
	id <S8224898AbUDQDb6>; Sat, 17 Apr 2004 04:31:58 +0100
Received: (qmail 14459 invoked by uid 1000); 17 Apr 2004 03:31:54 -0000
Message-ID: <20040417033154.14458.qmail@mail.seefried.com>
From: "Ken Seefried" <ken@seefried.com>
To: linux-mips@linux-mips.org
Subject: IDT 7RS385 Eval Board Manual
Date: Fri, 16 Apr 2004 23:31:54 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"
Content-Transfer-Encoding: 7bit
Return-Path: <ken@mail.seefried.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4799
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ken@seefried.com
Precedence: bulk
X-list: linux-mips
Content-Length: 140
Lines: 6

 

Does anyone have the hardware manual for an IDT 7RS385 MIPS 3052E (79R3052E) 
Evaluation Board?  I'd *really* appreciate a copy... 

Ken

From sskowron@ET.PUT.Poznan.PL Sat Apr 17 05:24:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Apr 2004 05:24:08 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:35042
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8224898AbUDQEYH>; Sat, 17 Apr 2004 05:24:07 +0100
Received: from athena (athena [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3H4O5m16201;
	Sat, 17 Apr 2004 06:24:05 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 17 Apr 2004 06:24:01 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3H4O1N11193;
	Sat, 17 Apr 2004 06:24:01 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 17 Apr 2004 06:24:01 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: linux-mips@linux-mips.org
Subject: Re: IP30 goes relatively far now
In-Reply-To: <Pine.LNX.4.55.0404170000540.24278@jurand.ds.pg.gda.pl>
Message-ID: <Pine.GSO.4.10.10404170612440.10514-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4800
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 1562
Lines: 46

>  I must have been blind -- there's a matching ".set pop" elsewhere.  Is a 
> "nop" really missing in the output?  I've assembled the file and I can't 
> see any problem:
> 
> 000000000000022c <handle_daddi_ov_int>:
>  22c:	0c000000 	jal	0 <except_vec0_generic>
> 			22c: R_MIPS_26	do_daddi_ov
> 			22c: R_MIPS_NONE	*ABS*
> 			22c: R_MIPS_NONE	*ABS*
>  230:	03a0202d 	move	a0,sp
>  234:	08000000 	j	0 <except_vec0_generic>
> 			234: R_MIPS_26	ret_from_exception
> 			234: R_MIPS_NONE	*ABS*
> 			234: R_MIPS_NONE	*ABS*
>  238:	00000000 	nop
>  23c:	00000000 	nop

Oooh, it's SOOO strange!

For me, it is:

   ...
 228:   03a0202d        move    a0,sp
 22c:   0c000000        jal     0 <except_vec0_generic>
                        22c: R_MIPS_26  do_daddi_ov
                        22c: R_MIPS_NONE        *ABS*
                        22c: R_MIPS_NONE        *ABS*
 230:   08000000        j       0 <except_vec0_generic>
                        230: R_MIPS_26  ret_from_exception
                        230: R_MIPS_NONE        *ABS*
                        230: R_MIPS_NONE        *ABS*

because the last '.set *reorder' before is in 'nmi_handler', and it is a
'.set noreorder'. I will get a newer kernel (I did 2.6.1 because it worked
for me, and 2.6.3 crashed on my PC with astonishing frequency, so I didn't
want to take a chance) and check.

Anyway, the procedure is 'handle_daddi_ov' and not 'handle_daddi_ov_int'
in my genex.S, and it's substantially longer than your code. Do you have
the SAVE_ALL there? I don't see it.

Yours,

Stanislaw Skowronek



From sskowron@ET.PUT.Poznan.PL Sat Apr 17 05:51:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Apr 2004 05:51:04 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:39393
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8224898AbUDQEvD>; Sat, 17 Apr 2004 05:51:03 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3H4p1h17043
	for <linux-mips@linux-mips.org>; Sat, 17 Apr 2004 06:51:01 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 17 Apr 2004 06:51:00 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3H4oxG12096
	for <linux-mips@linux-mips.org>; Sat, 17 Apr 2004 06:50:59 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 17 Apr 2004 06:50:59 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Re: IP30 goes relatively far now (photos)
In-Reply-To: <Pine.LNX.4.55.0404170000540.24278@jurand.ds.pg.gda.pl>
Message-ID: <Pine.GSO.4.10.10404170649270.12038-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4801
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 169
Lines: 10

For the little unbeliever in all of us:

http://www.et.put.poznan.pl/~sskowron/ip30/

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From kumba@gentoo.org Sat Apr 17 06:09:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Apr 2004 06:09:22 +0100 (BST)
Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:57529 "EHLO
	rwcrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8224898AbUDQFJV>; Sat, 17 Apr 2004 06:09:21 +0100
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (rwcrmhc12) with ESMTP
          id <20040417050913014001co09e>
          (Authid: kumba12345);
          Sat, 17 Apr 2004 05:09:14 +0000
Message-ID: <4080BC39.5030401@gentoo.org>
Date: Sat, 17 Apr 2004 01:10:17 -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.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: IP30 goes relatively far now (photos)
References: <Pine.GSO.4.10.10404170649270.12038-100000@helios.et.put.poznan.pl>
In-Reply-To: <Pine.GSO.4.10.10404170649270.12038-100000@helios.et.put.poznan.pl>
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: 4802
X-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
Content-Length: 500
Lines: 20

Stanislaw Skowronek wrote:
> For the little unbeliever in all of us:
> 
> http://www.et.put.poznan.pl/~sskowron/ip30/
> 
> Stanislaw Skowronek

All I'll say is that SGI Logo in the background of the console is 
*awesome* :)

Think the driver for the Octane console is gonna be usable for the 
Impact cards on the Indigo2?


--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 macro@ds2.pg.gda.pl Sat Apr 17 07:30:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Apr 2004 07:30:56 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:48837 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224898AbUDQGax>; Sat, 17 Apr 2004 07:30:53 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id E0E4247A40; Sat, 17 Apr 2004 08:30:44 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id CA45E47745; Sat, 17 Apr 2004 08:30:44 +0200 (CEST)
Date: Sat, 17 Apr 2004 08:30:44 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: IP30 goes relatively far now
In-Reply-To: <Pine.GSO.4.10.10404170612440.10514-100000@helios.et.put.poznan.pl>
Message-ID: <Pine.LNX.4.55.0404170817260.24278@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404170612440.10514-100000@helios.et.put.poznan.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: 4803
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1378
Lines: 32

On Sat, 17 Apr 2004, Stanislaw Skowronek wrote:

> because the last '.set *reorder' before is in 'nmi_handler', and it is a
> '.set noreorder'. I will get a newer kernel (I did 2.6.1 because it worked

 Ouch -- there used to be such a bug in the past, but it was fixed on Aug
6th, 2003.  Please update indeed -- your snapshot is severly old and there
have been plenty updates since then, so chances are you may struggle with
problems that have been dealt with elsewhere, too.  Please use the CVS, of
course.

> for me, and 2.6.3 crashed on my PC with astonishing frequency, so I didn't
> want to take a chance) and check.

 Well, the stability of the i386 and the MIPS port for a given version is
sometimes unrelated. ;-)

> Anyway, the procedure is 'handle_daddi_ov' and not 'handle_daddi_ov_int'
> in my genex.S, and it's substantially longer than your code. Do you have
> the SAVE_ALL there? I don't see it.

 I've stripped the preceding unrelated entry code.  The "_int" alternate
entry points to exception handlers were merged from 2.4 on Jan 3th (only
handle_fpe_int is actually needed, for R3k-class CPUs, as they handle the
FP error as an ordinary interrupt).

  Maciej

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

From robbat2@orbis-terrarum.net Sat Apr 17 08:46:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Apr 2004 08:46:54 +0100 (BST)
Received: from shawidc-mo1.cg.shawcable.net ([IPv6:::ffff:24.71.223.10]:5426
	"EHLO pd2mo3so.prod.shaw.ca") by linux-mips.org with ESMTP
	id <S8224898AbUDQHqx>; Sat, 17 Apr 2004 08:46:53 +0100
Received: from pd5mr5so.prod.shaw.ca
 (pd5mr5so-qfe3.prod.shaw.ca [10.0.141.181]) by l-daemon
 (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003))
 with ESMTP id <0HWB009J50V1TX@l-daemon> for linux-mips@linux-mips.org; Sat,
 17 Apr 2004 01:30:37 -0600 (MDT)
Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148])
 by pd5mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar
 15 2004)) with ESMTP id <0HWB007KK0XXUWM0@pd5mr5so.prod.shaw.ca> for
 linux-mips@linux-mips.org; Sat, 17 Apr 2004 01:32:21 -0600 (MDT)
Received: from curie.orbis-terrarum.net
 (S01060050da688d47.vc.shawcable.net [24.84.49.144])
 by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003))
 with ESMTP id <0HWB0032G0V0LQ@l-daemon> for linux-mips@linux-mips.org; Sat,
 17 Apr 2004 01:30:37 -0600 (MDT)
Received: (qmail 10224 invoked by uid 10000); Sat, 17 Apr 2004 00:28:43 -0700
Date: Sat, 17 Apr 2004 00:28:43 -0700
From: "Robin H. Johnson" <robbat2@gentoo.org>
Subject: Re: IP30 goes relatively far now (photos)
In-reply-to: <Pine.GSO.4.10.10404170649270.12038-100000@helios.et.put.poznan.pl>
To: linux-mips@linux-mips.org
Mail-followup-to: linux-mips@linux-mips.org
Message-id: <20040417072843.GA9762@curie-int.orbis-terrarum.net>
MIME-version: 1.0
Content-type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary=LQksG6bCIzRHxTLp
Content-disposition: inline
User-Agent: Mutt/1.5.6i
References: <Pine.LNX.4.55.0404170000540.24278@jurand.ds.pg.gda.pl>
 <Pine.GSO.4.10.10404170649270.12038-100000@helios.et.put.poznan.pl>
Return-Path: <robbat2@orbis-terrarum.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4804
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: robbat2@gentoo.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1125
Lines: 36


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

On Sat, Apr 17, 2004 at 06:50:59AM +0200, Stanislaw Skowronek wrote:
> For the little unbeliever in all of us:
> http://www.et.put.poznan.pl/~sskowron/ip30/
Really nice, esp. the 1GB of ram in there and the logo ;-).

What CPU is in your octane tho? I've got access to an R12k Octane that
could be ripe for linux if R10/12k is ever made to work (I'm waiting for
a book from Barnes+Noble so I can try to do an O2 R12k).

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

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

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

iD8DBQFAgNyrsnuUTjSIToURAjA/AJwOYuc7DtXd28+oK70MLh29Ks6xsgCeMUg8
9J7IkVwzvoKIfI1KwZ6ZhOk=
=yNu6
-----END PGP SIGNATURE-----

--LQksG6bCIzRHxTLp--

From sjhill@realitydiluted.com Sun Apr 18 03:39:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Apr 2004 03:39:33 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:46804 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8224923AbUDRCjb>; Sun, 18 Apr 2004 03:39:31 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1BF2Cy-0000JZ-00; Sat, 17 Apr 2004 21:39:00 -0500
Message-ID: <4081EA5F.5000802@realitydiluted.com>
Date: Sat, 17 Apr 2004 22:39:27 -0400
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5
X-Accept-Language: en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC: "Bradley D. LaRonde" <brad@laronde.org>, linux-mips@linux-mips.org,
	Eric Christopher <echristo@redhat.com>,
	Daniel Jacobowitz <dan@debian.org>
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" intime.c
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl> <20040412231309.GA702@linux-mips.org> <03f301c420e7$d8de2d70$8d01010a@prefect> <048e01c420f1$ad4ae3b0$8d01010a@prefect> <1081818125.19719.14.camel@dzur.sfbay.redhat.com> <04d501c420f3$6c836a30$8d01010a@prefect> <20040413010732.GA7560@nevyn.them.org> <04f501c420f4$5563f620$8d01010a@prefect> <053c01c420f5$ec230190$8d01010a@prefect> <Pine.LNX.4.55.0404131451200.15949@jurand.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.55.0404131451200.15949@jurand.ds.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4805
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 401
Lines: 11

Maciej W. Rozycki wrote:
> 
>  There are more places this should be dealt with and I have the following 
> preliminary patch for this, but I'm unsure about removal of "accum" being 
> completely safe for older compilers.
> 
Works fine for gcc-3.1.1 and my Swarm board boots just fine with this
change and it seems stable. I vote for you to go ahead and commit the
fixes to CVS. Thanks Maciej.

-Steve

From ralf@linux-mips.org Sun Apr 18 14:01:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Apr 2004 14:01:20 +0100 (BST)
Received: from p508B7EE5.dip.t-dialin.net ([IPv6:::ffff:80.139.126.229]:51537
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224927AbUDRNBS>; Sun, 18 Apr 2004 14:01:18 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3ID0qxr016368;
	Sun, 18 Apr 2004 15:00:52 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3ID0UFe016367;
	Sun, 18 Apr 2004 15:00:30 +0200
Date: Sun, 18 Apr 2004 15:00:30 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: "Bradley D. LaRonde" <brad@laronde.org>, linux-mips@linux-mips.org,
	Eric Christopher <echristo@redhat.com>,
	Daniel Jacobowitz <dan@debian.org>
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" intime.c
Message-ID: <20040418130029.GA23489@linux-mips.org>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl> <20040412231309.GA702@linux-mips.org> <03f301c420e7$d8de2d70$8d01010a@prefect> <048e01c420f1$ad4ae3b0$8d01010a@prefect> <1081818125.19719.14.camel@dzur.sfbay.redhat.com> <04d501c420f3$6c836a30$8d01010a@prefect> <20040413010732.GA7560@nevyn.them.org> <04f501c420f4$5563f620$8d01010a@prefect> <053c01c420f5$ec230190$8d01010a@prefect> <Pine.LNX.4.55.0404131451200.15949@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0404131451200.15949@jurand.ds.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: 4806
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 731
Lines: 17

On Tue, Apr 13, 2004 at 02:57:07PM +0200, Maciej W. Rozycki wrote:

> 
> > OK, so this patch actually builds, and it sounds like it will do the job,
> > since "accum" means "hi and low", "lo" is already clobbered in all cases,
> > and either "hi" is the output and doesn't need clobbering (hunks 1, 2, and
> > 4), or "hi" is already clobbered (hunk 3).
> 
>  There are more places this should be dealt with and I have the following 
> preliminary patch for this, but I'm unsure about removal of "accum" being 
> completely safe for older compilers.

From everything I know about the behavior of older compilers this should
be save.  "accum" was treated a little strage in some context anyway, so
I'm happy to see it go ...

  Ralf

From macro@ds2.pg.gda.pl Mon Apr 19 12:50:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Apr 2004 12:50:26 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:23230 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224991AbUDSLuZ>; Mon, 19 Apr 2004 12:50:25 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id C516A4AD2E; Mon, 19 Apr 2004 13:50:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id B157047855; Mon, 19 Apr 2004 13:50:13 +0200 (CEST)
Date: Mon, 19 Apr 2004 13:50:13 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: "Bradley D. LaRonde" <brad@laronde.org>, linux-mips@linux-mips.org,
	Eric Christopher <echristo@redhat.com>,
	Daniel Jacobowitz <dan@debian.org>
Subject: Re: [PATCH] gcc 3.4 drops "accum" clobber, replace with "hi" intime.c
In-Reply-To: <4081EA5F.5000802@realitydiluted.com>
Message-ID: <Pine.LNX.4.55.0404191344520.23098@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404122244110.8735-100000@helios.et.put.poznan.pl>
 <20040412231309.GA702@linux-mips.org> <03f301c420e7$d8de2d70$8d01010a@prefect>
 <048e01c420f1$ad4ae3b0$8d01010a@prefect> <1081818125.19719.14.camel@dzur.sfbay.redhat.com>
 <04d501c420f3$6c836a30$8d01010a@prefect> <20040413010732.GA7560@nevyn.them.org>
 <04f501c420f4$5563f620$8d01010a@prefect> <053c01c420f5$ec230190$8d01010a@prefect>
 <Pine.LNX.4.55.0404131451200.15949@jurand.ds.pg.gda.pl>
 <4081EA5F.5000802@realitydiluted.com>
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: 4807
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 588
Lines: 14

On Sat, 17 Apr 2004, Steven J. Hill wrote:

> Works fine for gcc-3.1.1 and my Swarm board boots just fine with this
> change and it seems stable. I vote for you to go ahead and commit the
> fixes to CVS. Thanks Maciej.

 I'm worried more about 2.95.  And even if it works now, it may stop after
some changes, if the compiler decides it's safe to keep something in
"accum" across the asm.

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

From rmk+linux-mips=linux-mips.org@arm.linux.org.uk Mon Apr 19 14:21:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Apr 2004 14:21:56 +0100 (BST)
Received: from caramon.arm.linux.org.uk ([IPv6:::ffff:212.18.232.186]:15630
	"EHLO caramon.arm.linux.org.uk") by linux-mips.org with ESMTP
	id <S8225197AbUDSNVy>; Mon, 19 Apr 2004 14:21:54 +0100
Received: from [2002:d412:e8ba:1:201:80ff:fe4b:1778] (helo=dyn-67.arm.linux.org.uk)
	by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.32)
	id 1BFYia-0005hd-Eh; Mon, 19 Apr 2004 14:21:48 +0100
Received: from rmk by dyn-67.arm.linux.org.uk with local (Exim 4.32)
	id 1BFYiZ-000564-Vs; Mon, 19 Apr 2004 14:21:47 +0100
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Linux Kernel List <linux-kernel@vger.kernel.org>, ralf@gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] Clean up asm/pgalloc.h include (mips)
In-Reply-To: <20040418232314.A2045@flint.arm.linux.org.uk>; from rmk+lkml@arm.linux.org.uk on Sun, Apr 18, 2004 at 11:23:14PM +0100
References: <20040418231720.C12222@flint.arm.linux.org.uk> <20040418232314.A2045@flint.arm.linux.org.uk>
Message-Id: <E1BFYiZ-000564-Vs@dyn-67.arm.linux.org.uk>
Date: Mon, 19 Apr 2004 14:21:47 +0100
Return-Path: <rmk+linux-mips=linux-mips.org@arm.linux.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4808
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rmk+lkml@arm.linux.org.uk
Precedence: bulk
X-list: linux-mips
Content-Length: 4652
Lines: 141

This patch cleans up needless includes of asm/pgalloc.h from the
arch/mips/ subtree.  This has not been compile tested, so
needs the architecture maintainers (or willing volunteers) to
test.

Please ensure that at least the first two patches have already
been applied to your tree; they can be found at:

	http://lkml.org/lkml/2004/4/18/86
	http://lkml.org/lkml/2004/4/18/87

This patch is part of a larger patch aiming towards getting the
include of asm/pgtable.h out of linux/mm.h, so that asm/pgtable.h
can sanely get at things like mm_struct and friends.

In the event that any of these files fails to build, chances are
you need to include some other header file rather than pgalloc.h.
Normally this is either asm/pgtable.h (unlikely), asm/cacheflush.h
or asm/tlbflush.h.

===== arch/mips/baget/baget.c 1.2 vs edited =====
--- 1.2/arch/mips/baget/baget.c	Tue Apr 15 04:10:11 2003
+++ edited/arch/mips/baget/baget.c	Mon Apr 19 13:38:40 2004
@@ -12,7 +12,6 @@
 #include <asm/bootinfo.h>
 #include <asm/mipsregs.h>
 #include <asm/pgtable.h>
-#include <asm/pgalloc.h>
 
 #include <asm/baget/baget.h>
 
===== arch/mips/kernel/irixelf.c 1.9 vs edited =====
--- 1.9/arch/mips/kernel/irixelf.c	Mon Apr 12 18:54:53 2004
+++ edited/arch/mips/kernel/irixelf.c	Mon Apr 19 13:38:40 2004
@@ -31,7 +31,6 @@
 #include <linux/smp_lock.h>
 
 #include <asm/uaccess.h>
-#include <asm/pgalloc.h>
 #include <asm/mipsregs.h>
 #include <asm/prctl.h>
 
===== arch/mips/kernel/signal32.c 1.15 vs edited =====
--- 1.15/arch/mips/kernel/signal32.c	Sat Apr 17 19:19:30 2004
+++ edited/arch/mips/kernel/signal32.c	Mon Apr 19 13:38:40 2004
@@ -21,7 +21,6 @@
 
 #include <asm/asm.h>
 #include <asm/bitops.h>
-#include <asm/pgalloc.h>
 #include <asm/sim.h>
 #include <asm/uaccess.h>
 #include <asm/ucontext.h>
===== arch/mips/kernel/signal_n32.c 1.2 vs edited =====
--- 1.2/arch/mips/kernel/signal_n32.c	Thu Feb 19 20:53:00 2004
+++ edited/arch/mips/kernel/signal_n32.c	Mon Apr 19 13:38:40 2004
@@ -29,7 +29,6 @@
 
 #include <asm/asm.h>
 #include <asm/bitops.h>
-#include <asm/pgalloc.h>
 #include <asm/sim.h>
 #include <asm/uaccess.h>
 #include <asm/ucontext.h>
===== arch/mips/kernel/sysirix.c 1.23 vs edited =====
--- 1.23/arch/mips/kernel/sysirix.c	Wed Mar 31 14:31:23 2004
+++ edited/arch/mips/kernel/sysirix.c	Mon Apr 19 13:38:40 2004
@@ -33,7 +33,6 @@
 
 #include <asm/ptrace.h>
 #include <asm/page.h>
-#include <asm/pgalloc.h>
 #include <asm/uaccess.h>
 #include <asm/inventory.h>
 
===== arch/mips/mm/fault.c 1.9 vs edited =====
--- 1.9/arch/mips/mm/fault.c	Thu Feb 19 20:53:00 2004
+++ edited/arch/mips/mm/fault.c	Mon Apr 19 13:38:40 2004
@@ -22,7 +22,6 @@
 
 #include <asm/branch.h>
 #include <asm/hardirq.h>
-#include <asm/pgalloc.h>
 #include <asm/mmu_context.h>
 #include <asm/system.h>
 #include <asm/uaccess.h>
===== arch/mips/mm/init.c 1.1 vs edited =====
--- 1.1/arch/mips/mm/init.c	Sat Feb 21 01:33:01 2004
+++ edited/arch/mips/mm/init.c	Mon Apr 19 13:38:40 2004
@@ -29,7 +29,6 @@
 #include <asm/cachectl.h>
 #include <asm/cpu.h>
 #include <asm/dma.h>
-#include <asm/pgalloc.h>
 #include <asm/mmu_context.h>
 #include <asm/sections.h>
 #include <asm/tlb.h>
===== arch/mips/mm/ioremap.c 1.5 vs edited =====
--- 1.5/arch/mips/mm/ioremap.c	Thu Oct  2 08:11:59 2003
+++ edited/arch/mips/mm/ioremap.c	Mon Apr 19 13:38:40 2004
@@ -13,7 +13,6 @@
 #include <linux/vmalloc.h>
 #include <asm/cacheflush.h>
 #include <asm/io.h>
-#include <asm/pgalloc.h>
 #include <asm/tlbflush.h>
 
 static inline void remap_area_pte(pte_t * pte, unsigned long address,
===== arch/mips/mm/pgtable-64.c 1.2 vs edited =====
--- 1.2/arch/mips/mm/pgtable-64.c	Thu Feb 19 20:53:00 2004
+++ edited/arch/mips/mm/pgtable-64.c	Mon Apr 19 13:38:40 2004
@@ -9,7 +9,6 @@
 #include <linux/init.h>
 #include <linux/mm.h>
 #include <asm/pgtable.h>
-#include <asm/pgalloc.h>
 
 void pgd_init(unsigned long page)
 {
===== arch/mips/sgi-ip27/ip27-init.c 1.10 vs edited =====
--- 1.10/arch/mips/sgi-ip27/ip27-init.c	Thu Feb 19 20:53:02 2004
+++ edited/arch/mips/sgi-ip27/ip27-init.c	Mon Apr 19 13:38:40 2004
@@ -14,7 +14,6 @@
 #include <linux/mm.h>
 #include <linux/cpumask.h>
 #include <asm/cpu.h>
-#include <asm/pgalloc.h>
 #include <asm/pgtable.h>
 #include <asm/sn/types.h>
 #include <asm/sn/sn0/addrs.h>
===== arch/mips/sgi-ip27/ip27-memory.c 1.8 vs edited =====
--- 1.8/arch/mips/sgi-ip27/ip27-memory.c	Thu Feb 19 20:53:02 2004
+++ edited/arch/mips/sgi-ip27/ip27-memory.c	Mon Apr 19 13:38:40 2004
@@ -20,7 +20,6 @@
 #include <asm/bootinfo.h>
 #include <asm/addrspace.h>
 #include <asm/pgtable.h>
-#include <asm/pgalloc.h>
 #include <asm/sn/types.h>
 #include <asm/sn/addrs.h>
 #include <asm/sn/hub.h>

From ralf@linux-mips.org Mon Apr 19 17:37:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Apr 2004 17:37:03 +0100 (BST)
Received: from p508B6729.dip.t-dialin.net ([IPv6:::ffff:80.139.103.41]:64018
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225215AbUDSQhB>; Mon, 19 Apr 2004 17:37:01 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3JGanxT018088;
	Mon, 19 Apr 2004 18:36:49 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3JGam0N018087;
	Mon, 19 Apr 2004 18:36:48 +0200
Date: Mon, 19 Apr 2004 18:36:48 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] Clean up asm/pgalloc.h include (mips)
Message-ID: <20040419163648.GA24745@linux-mips.org>
References: <20040418231720.C12222@flint.arm.linux.org.uk> <20040418232314.A2045@flint.arm.linux.org.uk> <E1BFYiZ-000564-Vs@dyn-67.arm.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1BFYiZ-000564-Vs@dyn-67.arm.linux.org.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: 4809
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 7375
Lines: 220

On Mon, Apr 19, 2004 at 02:21:47PM +0100, Russell King wrote:

> This patch cleans up needless includes of asm/pgalloc.h from the
> arch/mips/ subtree.  This has not been compile tested, so
> needs the architecture maintainers (or willing volunteers) to
> test.
> 
> Please ensure that at least the first two patches have already
> been applied to your tree; they can be found at:
> 
> 	http://lkml.org/lkml/2004/4/18/86
> 	http://lkml.org/lkml/2004/4/18/87
> 
> This patch is part of a larger patch aiming towards getting the
> include of asm/pgtable.h out of linux/mm.h, so that asm/pgtable.h
> can sanely get at things like mm_struct and friends.
> 
> In the event that any of these files fails to build, chances are
> you need to include some other header file rather than pgalloc.h.
> Normally this is either asm/pgtable.h (unlikely), asm/cacheflush.h
> or asm/tlbflush.h.

It needed a little fixing for one because of recent changed to the IP27
code and to keep things building.  The updated patch against linux-mips.org's
cvs which I'm about to checkin, is below.

  Ralf

Index: arch/mips/baget/baget.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/baget/baget.c,v
retrieving revision 1.4
diff -u -r1.4 baget.c
--- arch/mips/baget/baget.c	6 Aug 2002 00:08:53 -0000	1.4
+++ arch/mips/baget/baget.c	19 Apr 2004 16:28:55 -0000
@@ -12,7 +12,6 @@
 #include <asm/bootinfo.h>
 #include <asm/mipsregs.h>
 #include <asm/pgtable.h>
-#include <asm/pgalloc.h>
 
 #include <asm/baget/baget.h>
 
Index: arch/mips/kernel/irixelf.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/irixelf.c,v
retrieving revision 1.54
diff -u -r1.54 irixelf.c
--- arch/mips/kernel/irixelf.c	19 Oct 2003 00:50:08 -0000	1.54
+++ arch/mips/kernel/irixelf.c	19 Apr 2004 16:28:58 -0000
@@ -31,7 +31,6 @@
 #include <linux/smp_lock.h>
 
 #include <asm/uaccess.h>
-#include <asm/pgalloc.h>
 #include <asm/mipsregs.h>
 #include <asm/prctl.h>
 
Index: arch/mips/kernel/signal32.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/signal32.c,v
retrieving revision 1.10
diff -u -r1.10 signal32.c
--- arch/mips/kernel/signal32.c	11 Mar 2004 16:46:43 -0000	1.10
+++ arch/mips/kernel/signal32.c	19 Apr 2004 16:28:58 -0000
@@ -21,7 +21,6 @@
 
 #include <asm/asm.h>
 #include <asm/bitops.h>
-#include <asm/pgalloc.h>
 #include <asm/sim.h>
 #include <asm/uaccess.h>
 #include <asm/ucontext.h>
Index: arch/mips/kernel/signal_n32.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/signal_n32.c,v
retrieving revision 1.4
diff -u -r1.4 signal_n32.c
--- arch/mips/kernel/signal_n32.c	3 Mar 2004 12:54:20 -0000	1.4
+++ arch/mips/kernel/signal_n32.c	19 Apr 2004 16:28:58 -0000
@@ -29,7 +29,6 @@
 
 #include <asm/asm.h>
 #include <asm/bitops.h>
-#include <asm/pgalloc.h>
 #include <asm/sim.h>
 #include <asm/uaccess.h>
 #include <asm/ucontext.h>
Index: arch/mips/kernel/sysirix.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/sysirix.c,v
retrieving revision 1.58
diff -u -r1.58 sysirix.c
--- arch/mips/kernel/sysirix.c	12 Apr 2004 20:23:24 -0000	1.58
+++ arch/mips/kernel/sysirix.c	19 Apr 2004 16:28:58 -0000
@@ -33,7 +33,6 @@
 
 #include <asm/ptrace.h>
 #include <asm/page.h>
-#include <asm/pgalloc.h>
 #include <asm/uaccess.h>
 #include <asm/inventory.h>
 
Index: arch/mips/mm/fault.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/fault.c,v
retrieving revision 1.52
diff -u -r1.52 fault.c
--- arch/mips/mm/fault.c	18 Dec 2003 21:52:33 -0000	1.52
+++ arch/mips/mm/fault.c	19 Apr 2004 16:28:58 -0000
@@ -22,7 +22,6 @@
 
 #include <asm/branch.h>
 #include <asm/hardirq.h>
-#include <asm/pgalloc.h>
 #include <asm/mmu_context.h>
 #include <asm/system.h>
 #include <asm/uaccess.h>
Index: arch/mips/mm/init.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/init.c,v
retrieving revision 1.67
diff -u -r1.67 init.c
--- arch/mips/mm/init.c	19 Mar 2004 01:26:10 -0000	1.67
+++ arch/mips/mm/init.c	19 Apr 2004 16:28:58 -0000
@@ -29,9 +29,10 @@
 #include <asm/cachectl.h>
 #include <asm/cpu.h>
 #include <asm/dma.h>
-#include <asm/pgalloc.h>
 #include <asm/mmu_context.h>
 #include <asm/sections.h>
+#include <asm/pgtable.h>
+#include <asm/pgalloc.h>
 #include <asm/tlb.h>
 
 DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
Index: arch/mips/mm/ioremap.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/ioremap.c,v
retrieving revision 1.18
diff -u -r1.18 ioremap.c
--- arch/mips/mm/ioremap.c	25 Feb 2004 22:09:29 -0000	1.18
+++ arch/mips/mm/ioremap.c	19 Apr 2004 16:28:58 -0000
@@ -13,7 +13,6 @@
 #include <linux/vmalloc.h>
 #include <asm/cacheflush.h>
 #include <asm/io.h>
-#include <asm/pgalloc.h>
 #include <asm/tlbflush.h>
 
 static inline void remap_area_pte(pte_t * pte, unsigned long address,
Index: arch/mips/mm/pgtable-64.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/pgtable-64.c,v
retrieving revision 1.3
diff -u -r1.3 pgtable-64.c
--- arch/mips/mm/pgtable-64.c	27 Aug 2003 17:10:00 -0000	1.3
+++ arch/mips/mm/pgtable-64.c	19 Apr 2004 16:28:58 -0000
@@ -9,7 +9,6 @@
 #include <linux/init.h>
 #include <linux/mm.h>
 #include <asm/pgtable.h>
-#include <asm/pgalloc.h>
 
 void pgd_init(unsigned long page)
 {
Index: arch/mips/sgi-ip27/ip27-init.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip27/ip27-init.c,v
retrieving revision 1.58
diff -u -r1.58 ip27-init.c
--- arch/mips/sgi-ip27/ip27-init.c	12 Apr 2004 20:23:25 -0000	1.58
+++ arch/mips/sgi-ip27/ip27-init.c	19 Apr 2004 16:29:00 -0000
@@ -15,7 +15,6 @@
 #include <linux/cpumask.h>
 #include <asm/cpu.h>
 #include <asm/io.h>
-#include <asm/pgalloc.h>
 #include <asm/pgtable.h>
 #include <asm/time.h>
 #include <asm/sn/types.h>
Index: include/asm-mips/pgalloc.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/pgalloc.h,v
retrieving revision 1.30
diff -u -r1.30 pgalloc.h
--- include/asm-mips/pgalloc.h	14 Aug 2003 15:54:42 -0000	1.30
+++ include/asm-mips/pgalloc.h	19 Apr 2004 16:29:02 -0000
@@ -122,12 +122,6 @@
 
 #endif
 
-/*
- * Used for the b0rked handling of kernel pagetables on the 64-bit kernel.
- */
-extern pte_t kptbl[(PAGE_SIZE << PGD_ORDER)/sizeof(pte_t)];
-extern pmd_t kpmdtbl[PTRS_PER_PMD];
-
 #define check_pgt_cache()	do { } while (0)
 
 #endif /* _ASM_PGALLOC_H */
Index: include/asm-mips/pgtable-64.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/pgtable-64.h,v
retrieving revision 1.11
diff -u -r1.11 pgtable-64.h
--- include/asm-mips/pgtable-64.h	5 Jan 2004 23:29:13 -0000	1.11
+++ include/asm-mips/pgtable-64.h	19 Apr 2004 16:29:02 -0000
@@ -216,4 +216,10 @@
 
 typedef pte_t *pte_addr_t;
 
+/*
+ * Used for the b0rked handling of kernel pagetables on the 64-bit kernel.
+ */
+extern pte_t kptbl[(PAGE_SIZE << PGD_ORDER)/sizeof(pte_t)];
+extern pmd_t kpmdtbl[PTRS_PER_PMD];
+
 #endif /* _ASM_PGTABLE_64_H */

From jsun@orion.mvista.com Tue Apr 20 02:07:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 02:07:26 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:49658 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225250AbUDTBHY>;
	Tue, 20 Apr 2004 02:07:24 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i3K17Kx6020489;
	Mon, 19 Apr 2004 18:07:20 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i3K17KXO020487;
	Mon, 19 Apr 2004 18:07:20 -0700
Date: Mon, 19 Apr 2004 18:07:20 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [RFC] Separate time support for using cpu timer
Message-ID: <20040419180720.H14976@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="eRtJSFbw+EEWtPj3"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4810
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 16852
Lines: 602


--eRtJSFbw+EEWtPj3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


Background
----------

The current arch/mips/kernel/time.c has been stretched over the time
such that it now looks like a convoluted spaghetti to me:

1) it was originally designed to be flexible so that we could support
   all imaginable timer sources and timer setups:
	. use cpu timer (count/compare pair)
	. use board timer, with cpu count and known frequency
	. use board timer, with cpu count and unknown frequency
	. use board timer, with cpu count and unknown frequency, and
	  we can use 64bit division
	. jiffy interrupt through do_IRQ
	. jiffy interrupt through ll_timer_interrupt
	.....

2) introduction of 32bit SMP causes more complexity

3) the hpt_xxx stuff introduces another abstraction layer between hw
   timer (where cpu timer is treated as one kind of hw timers) and the time 
   subsystem.


Solution
--------

All the boards that I am really concerned right now have cpu count/compare
registers.  I believe this will even more so in the future.

Therefore I like to propose a separate time support for systems that use
cpu timer as their system timer.

As you can see from the patch, the new code is much simpler.


The hidden agenda
-----------------

OK, I admit there is another motivation in all of this.  Linux is moving
to have higher resolution timer.  For example, see the introduction of high resolution 
posix timer (http://sourceforge.net/projects/high-res-timers/).  Having a MIPS common
time routine based on cpu timer makes it much easier to support
such a feature for MIPS boards.  We don't need to mess with individual board timer
anymore.

In addition I think in 2.7 time frame Linux needs to replace its ancient jiffy
time system with a natively higher resolution time system.  A MIPS cpu timer based 
routine would evolve much better into the future.


The patch
---------

The attached is the patch for UP case.  I will post an additional patch for SMP
case later.

The patch is currently designed to be drop-in replace for arch/mips/kernel/time.c.
As you can see from the patch, you will only need to modify the Kconfig to define
CPU_TIMER for the qualified boards.

Comments?

Jun

--eRtJSFbw+EEWtPj3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="040419.a-cpu-timer.patch"

diff -Nru linux/arch/mips/Kconfig.orig linux/arch/mips/Kconfig
--- linux/arch/mips/Kconfig.orig	2004-04-19 16:33:42.000000000 -0700
+++ linux/arch/mips/Kconfig	2004-04-19 16:42:18.000000000 -0700
@@ -320,6 +320,7 @@
 config DDB5477
 	bool "Support for NEC DDB Vrc-5477"
 	select IRQ_CPU
+	select CPU_TIMER
 	help
 	  This enables support for the R5432-based NEC DDB Vrc-5477,
 	  or Rockhopper/SolutionGear boards with R5432/R5500 CPUs.
@@ -516,6 +517,7 @@
 config SIBYTE_SWARM
 	bool "BCM91250A-SWARM"
 	select SIBYTE_SB1250
+	select CPU_TIMER
 
 config SIBYTE_SENTOSA
 	bool "BCM91250E-Sentosa"
@@ -800,6 +802,13 @@
 	  byte order. These modes require different kernels. Say Y if your
 	  machine is little endian, N if it's a big endian machine.
 
+config CPU_TIMER
+	bool
+	help
+	  If CPU has count/compare registers (most do), and they are used
+	  as system timer, you can say 'Y' here to use the alternative
+	  time routines.
+
 config IRQ_CPU
 	bool
 
diff -Nru linux/arch/mips/kernel/cpu-timer.c.orig linux/arch/mips/kernel/cpu-timer.c
--- linux/arch/mips/kernel/cpu-timer.c.orig	2004-04-19 16:33:42.000000000 -0700
+++ linux/arch/mips/kernel/cpu-timer.c	2004-04-19 17:01:13.000000000 -0700
@@ -0,0 +1,445 @@
+/*
+ * Copyright 2004 MontaVista Software Inc.
+ * Author: Jun Sun, jsun@mvista.com or jsun@junsun.net
+ *
+ * This routine provides time routines for boards that use cpu count/compare
+ * as their system timer.  A couple of requirements:
+ *   . Must have count/compare register and use them as your system timer
+ *     (obviously)
+ *   . Timer interrupt must go through do_IRQ() or ll_timer_interrupt()
+ *   . You must know or calibrate cpu timer frequency.
+ *
+ * See more in Documentation/mips/time.README.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+#include <linux/config.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#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>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+
+#include <asm/bootinfo.h>
+#include <asm/cpu.h>
+#include <asm/cpu-features.h>
+#include <asm/div64.h>
+#include <asm/hardirq.h>
+#include <asm/sections.h>
+#include <asm/time.h>
+#include <asm/debug.h>
+
+/*
+ * 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_SIZE
+
+#define TICK_SIZE	(tick_nsec / 1000)
+
+u64 jiffies_64 = INITIAL_JIFFIES;
+
+EXPORT_SYMBOL(jiffies_64);
+
+/*
+ * forward reference
+ */
+extern volatile unsigned long wall_jiffies;
+
+/*
+ * By default we provide the null RTC ops
+ */
+static unsigned long null_rtc_get_time(void)
+{
+	return mktime(2000, 1, 1, 0, 0, 0);
+}
+
+static int null_rtc_set_time(unsigned long sec)
+{
+	return 0;
+}
+
+unsigned long (*rtc_get_time)(void) = null_rtc_get_time;
+int (*rtc_set_time)(unsigned long) = null_rtc_set_time;
+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 last_count;
+
+/* last time when xtime and rtc are sync'ed up */
+static long last_rtc_update;
+
+/* any missed timer interrupts */
+int missed_timer_count;
+
+
+/*
+ * Gettimeoffset routines.  These routines returns the time duration
+ * since last timer interrupt in usecs.
+ */
+static unsigned long get_intra_jiffy_offset(void)
+{
+	u32 count;
+	unsigned long res;
+
+	/* Get last timer tick in absolute kernel time */
+	count = read_c0_count();
+
+	/* 
+	 * .. relative to previous jiffy (32 bits is enough).
+	 * This routine should be protected by xtime_lock.  No race condition.
+	 * In SMP case, count may occasionally be behind last_count.
+	 */ 
+	/*
+	 * FIXME: time_after/time_before() not 64bit safe?
+	 */
+	if (time_after(count, last_count))
+	       count -= last_count;
+	else
+		count = 0;
+
+	__asm__("multu	%1,%2"
+		: "=h" (res)
+		: "r" (count), "r" (sll32_usecs_per_cycle)
+		: "lo", "accum");
+
+	/*
+	 * Due to possible jiffies inconsistencies, we need to check
+	 * the result so that we'll get a timer that is monotonic.
+	 */
+	if (res >= USECS_PER_JIFFY)
+		res = USECS_PER_JIFFY;
+
+	return res;
+}
+
+/*
+ * This version of gettimeofday has better than microsecond precision.
+ */
+void do_gettimeofday(struct timeval *tv)
+{
+	unsigned long seq;
+	unsigned long lost;
+	unsigned long usec, sec;
+	unsigned long max_ntp_tick;
+
+	do {
+		seq = read_seqbegin(&xtime_lock);
+
+		usec = get_intra_jiffy_offset();
+
+		lost = jiffies - wall_jiffies;
+
+		/*
+		 * If time_adjust is negative then NTP is slowing the clock
+		 * so make sure not to go into next possible interval.
+		 * Better to lose some accuracy than have time go backwards..
+		 */
+		if (unlikely(time_adjust < 0)) {
+			max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
+			usec = min(usec, max_ntp_tick);
+
+			if (lost)
+				usec += lost * max_ntp_tick;
+		} else if (unlikely(lost))
+			usec += lost * (USEC_PER_SEC / HZ);
+
+		sec = xtime.tv_sec;
+		usec += (xtime.tv_nsec / 1000);
+	} while (read_seqretry(&xtime_lock, seq));
+
+	while (usec >= 1000000) {
+		usec -= 1000000;
+		sec++;
+	}
+	
+	tv->tv_sec = sec;
+	tv->tv_usec = usec;
+}
+
+EXPORT_SYMBOL(do_gettimeofday);
+
+int do_settimeofday(struct timespec *tv)
+{
+	time_t wtm_sec, sec = tv->tv_sec;
+	long wtm_nsec, nsec = tv->tv_nsec;
+
+	if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
+		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
+	 * made, and then undo it!
+	 */
+	nsec -= get_intra_jiffy_offset() * NSEC_PER_USEC;
+	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);
+
+	set_normalized_timespec(&xtime, sec, nsec);
+	set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec);
+
+	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;
+}
+
+EXPORT_SYMBOL(do_settimeofday);
+
+
+/*
+ * local_timer_interrupt() does profiling and process accounting
+ * on a per-CPU basis.
+ *
+ * In UP mode, it is invoked from the (global) timer_interrupt.
+ *
+ * In SMP mode, it might invoked by per-CPU timer interrupt, or
+ * a broadcasted inter-processor interrupt which itself is triggered
+ * by the global timer interrupt.
+ */
+void local_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+	if (!user_mode(regs)) {
+		if (prof_buffer && current->pid) {
+			unsigned long pc = regs->cp0_epc;
+
+			pc -= (unsigned long) _stext;
+			pc >>= prof_shift;
+			/*
+			 * Dont ignore out-of-bounds pc values silently,
+			 * put them into the last histogram slot, so if
+			 * present, they will show up as a sharp peak.
+			 */
+			if (pc > prof_len - 1)
+				pc = prof_len - 1;
+			atomic_inc((atomic_t *)&prof_buffer[pc]);
+		}
+	}
+}
+
+/*
+ * Timer interrupt service routines.  This function
+ * is set as irqaction->handler and is invoked through do_IRQ.
+ */
+irqreturn_t timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+	unsigned long compare;
+
+	db_assert(smp_processor_id() == 0);
+
+	write_seqlock(&xtime_lock);
+
+	missed_timer_count--;
+	do {
+		missed_timer_count++;
+
+		/* Ack this timer interrupt and set the next one.  */
+		last_count += cycles_per_jiffy;
+		compare = last_count + cycles_per_jiffy;
+		write_c0_compare(compare);
+
+		do_timer(regs);
+
+	} while (time_before_eq(compare, (unsigned long)read_c0_count()));
+
+	/*
+	 * If we have an externally synchronized Linux clock, then update
+	 * CMOS clock accordingly every ~11 minutes. rtc_set_time() has to be
+	 * called as close as possible to 500 ms before the new second starts.
+	 */
+	if ((time_status & STA_UNSYNC) == 0 &&
+	    xtime.tv_sec > last_rtc_update + 660 &&
+	    (xtime.tv_nsec / 1000) >= 500000 - ((unsigned) TICK_SIZE) / 2 &&
+	    (xtime.tv_nsec / 1000) <= 500000 + ((unsigned) TICK_SIZE) / 2) {
+		if (rtc_set_mmss(xtime.tv_sec) == 0) {
+			last_rtc_update = xtime.tv_sec;
+		} else {
+			/* do it again in 60 s */
+			last_rtc_update = xtime.tv_sec - 600;
+		}
+	}
+
+	write_sequnlock(&xtime_lock);
+
+	/*
+	 * We call local_timer_interrupt() to do profiling and process 
+	 * accouting.
+	 */
+	local_timer_interrupt(irq, dev_id, regs);
+
+	return IRQ_HANDLED;
+}
+
+asmlinkage void ll_timer_interrupt(int irq, struct pt_regs *regs)
+{
+	irq_enter();
+	kstat_this_cpu.irqs[irq]++;
+
+	/* we keep interrupt disabled all the time */
+	timer_interrupt(irq, NULL, regs);
+
+	irq_exit();
+}
+
+/*
+ * time_init() - it does the following things.
+ *
+ * .) board_time_init() (or in board setup routine) -
+ * 	a) set up RTC routines,
+ *      b) calibrate and set the mips_hpt_frequency
+ * .) set rtc_set_mmss if it is not set by board code
+ * .) setup xtime based on rtc_get_time().
+ * .) init walt_to_monotonic
+ * .) calculate a couple of cached variables for later usage
+ * .) board_timer_setup() -
+ * 	. If you use ll_timer_interrupt(), do
+ *			set_c0_status(IE_IRQ5);
+ *		
+ *	. Otherwise if you are using IRQ_CPU, do
+ *		setup_irq(CPU_IRQ_BASE + 7, irq)
+ *
+ *	. If you are not using ll_timer_interrupt() (i.e., go through
+ *	  do_IRQ()) and you are not using IRQ_CPU, you can work around,
+ *	  but you probably really should ask yourself why.
+ */
+
+void (*board_time_init)(void);
+void (*board_timer_setup)(struct irqaction *irq);
+
+unsigned int mips_hpt_frequency;
+
+static struct irqaction timer_irqaction = {
+	.handler = timer_interrupt,
+	.flags = SA_INTERRUPT,
+	.name = "timer",
+};
+
+void __init time_init(void)
+{
+	if (board_time_init)
+		board_time_init();
+
+	db_assert(mips_hpt_frequency != 0);
+
+	if (!rtc_set_mmss)
+		rtc_set_mmss = rtc_set_time;
+
+	xtime.tv_sec = rtc_get_time();
+	xtime.tv_nsec = 0;
+
+	set_normalized_timespec(&wall_to_monotonic,
+	                        -xtime.tv_sec, -xtime.tv_nsec);
+
+	/* Calculate cache parameters.  */
+	cycles_per_jiffy = (mips_hpt_frequency + HZ / 2) / HZ;
+
+	/* sll32_usecs_per_cycle = 10^6 * 2^32 / mips_hpt_frequency  */
+	{ 
+		u64 div = ((u64)1000000 << 32) + mips_hpt_frequency / 2;
+		do_div(div, mips_hpt_frequency);
+		sll32_usecs_per_cycle = div;
+	}
+
+	/* Report the high precision timer rate for a reference.  */
+	printk("Using %u.%03u MHz cpu timer.\n",
+		       ((mips_hpt_frequency + 500) / 1000) / 1000,
+		       ((mips_hpt_frequency + 500) / 1000) % 1000);
+
+	/* initialize cp0 count and compare */
+	write_c0_compare(cycles_per_jiffy);
+	write_c0_count(0);
+	last_count = 0;
+
+	/*
+	 * Call board specific timer interrupt setup.
+	 *
+	 * this pointer must be setup in machine setup routine.
+	 *
+	 * 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
+	 * is not invoked accidentally.
+	 */
+	board_timer_setup(&timer_irqaction);
+}
+
+#define FEBRUARY		2
+#define STARTOFTIME		1970
+#define SECDAY			86400L
+#define SECYR			(SECDAY * 365)
+#define leapyear(y)		((!((y) % 4) && ((y) % 100)) || !((y) % 400))
+#define days_in_year(y)		(leapyear(y) ? 366 : 365)
+#define days_in_month(m)	(month_days[(m) - 1])
+
+static int month_days[12] = {
+	31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
+};
+
+void to_tm(unsigned long tim, struct rtc_time *tm)
+{
+	long hms, day, gday;
+	int i;
+
+	gday = day = tim / SECDAY;
+	hms = tim % SECDAY;
+
+	/* Hours, minutes, seconds are easy */
+	tm->tm_hour = hms / 3600;
+	tm->tm_min = (hms % 3600) / 60;
+	tm->tm_sec = (hms % 3600) % 60;
+
+	/* Number of years in days */
+	for (i = STARTOFTIME; day >= days_in_year(i); i++)
+		day -= days_in_year(i);
+	tm->tm_year = i;
+
+	/* Number of months in days left */
+	if (leapyear(tm->tm_year))
+		days_in_month(FEBRUARY) = 29;
+	for (i = 1; day >= days_in_month(i); i++)
+		day -= days_in_month(i);
+	days_in_month(FEBRUARY) = 28;
+	tm->tm_mon = i - 1;		/* tm_mon starts from 0 to 11 */
+
+	/* Days are what is left over (+1) from all that. */
+	tm->tm_mday = day + 1;
+
+	/*
+	 * Determine the day of week
+	 */
+	tm->tm_wday = (gday + 4) % 7;	/* 1970/1/1 was Thursday */
+}
+
+EXPORT_SYMBOL(to_tm);
+EXPORT_SYMBOL(rtc_set_time);
+EXPORT_SYMBOL(rtc_get_time);
diff -Nru linux/arch/mips/kernel/Makefile.orig linux/arch/mips/kernel/Makefile
--- linux/arch/mips/kernel/Makefile.orig	2004-04-19 16:33:42.000000000 -0700
+++ linux/arch/mips/kernel/Makefile	2004-04-19 16:42:18.000000000 -0700
@@ -6,7 +6,13 @@
 
 obj-y		+= cpu-probe.o branch.o entry.o genex.o irq.o process.o \
 		   ptrace.o reset.o semaphore.o setup.o signal.o syscall.o \
-		   time.o traps.o unaligned.o
+		   traps.o unaligned.o
+
+ifdef CONFIG_CPU_TIMER
+obj-y				+= cpu-timer.o
+else
+obj-y				+= time.o
+endif
 
 ifdef CONFIG_MODULES
 obj-y				+= mips_ksyms.o
diff -Nru linux/arch/mips/kernel/proc.c.orig linux/arch/mips/kernel/proc.c
--- linux/arch/mips/kernel/proc.c.orig	2004-04-19 16:33:42.000000000 -0700
+++ linux/arch/mips/kernel/proc.c	2004-04-19 16:42:18.000000000 -0700
@@ -78,7 +78,9 @@
 	[CPU_SR71000]	"Sandcraft SR71000"
 };
 
-
+#if defined(CONFIG_CPU_TIMER)
+extern int missed_timer_count;
+#endif
 static int show_cpuinfo(struct seq_file *m, void *v)
 {
 	unsigned int version = current_cpu_data.processor_id;
@@ -121,6 +123,10 @@
 	seq_printf(m, fmt, 'D', vced_count);
 	seq_printf(m, fmt, 'I', vcei_count);
 
+#if defined(CONFIG_CPU_TIMER)
+	seq_printf(m, "missed timers\t\t: %d\n", missed_timer_count);
+#endif
+
 	return 0;
 }
 

--eRtJSFbw+EEWtPj3--

From jh@hansen-telecom.dk Tue Apr 20 08:45:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 08:45:19 +0100 (BST)
Received: from smtp130.tiscali.dk ([IPv6:::ffff:62.79.79.112]:47881 "EHLO
	smtp130.tiscali.dk") by linux-mips.org with ESMTP
	id <S8225245AbUDTHpS>; Tue, 20 Apr 2004 08:45:18 +0100
Received: from cpmail.dk.tiscali.com (mail.tiscali.dk [212.54.64.159])
	by smtp130.tiscali.dk (8.12.11/8.12.11) with ESMTP id i3K7jFTD073776
	for <linux-mips@linux-mips.org>; Tue, 20 Apr 2004 09:45:15 +0200 (CEST)
	(envelope-from jh@hansen-telecom.dk)
Received: from jorg (62.79.30.226) by cpmail.dk.tiscali.com (6.7.018)
        id 407273BB004759F8 for linux-mips@linux-mips.org; Tue, 20 Apr 2004 09:45:14 +0200
From: =?iso-8859-1?Q?J=F8rg_Ulrich_Hansen?= <jh@hansen-telecom.dk>
To: "Linux-Mips" <linux-mips@linux-mips.org>
Subject: Re: building mips cross compiler -- an error when compiling glibc
Date: Tue, 20 Apr 2004 09:44:47 +0200
Message-ID: <EIEHIDHKGJLNEPLOGOPOOEHPCGAA.jh@hansen-telecom.dk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <jh@hansen-telecom.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4811
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jh@hansen-telecom.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 288
Lines: 12


a good choice would be www.kegel.com/crosstool, that worked for me.

If you are doing embedded and want to use uclibc on your target then uclibc
toolchain http://www.uclibc.org/toolchains.html is a good choice.

Both take care of any patches needed.

That has also worked for me.

Jorg


From jh@hansen-telecom.dk Tue Apr 20 10:43:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 10:43:55 +0100 (BST)
Received: from smtp220.tiscali.dk ([IPv6:::ffff:62.79.79.114]:58121 "EHLO
	smtp220.tiscali.dk") by linux-mips.org with ESMTP
	id <S8225250AbUDTJny>; Tue, 20 Apr 2004 10:43:54 +0100
Received: from cpmail.dk.tiscali.com (mail.tiscali.dk [212.54.64.159])
	by smtp220.tiscali.dk (8.12.11/8.12.11) with ESMTP id i3K9hq75009390
	for <linux-mips@linux-mips.org>; Tue, 20 Apr 2004 11:43:52 +0200 (CEST)
	(envelope-from jh@hansen-telecom.dk)
Received: from jorg (62.79.30.226) by cpmail.dk.tiscali.com (6.7.018)
        id 404B99FB0087ECF2 for linux-mips@linux-mips.org; Tue, 20 Apr 2004 11:43:52 +0200
From: =?iso-8859-1?Q?J=F8rg_Ulrich_Hansen?= <jh@hansen-telecom.dk>
To: "Linux-Mips" <linux-mips@linux-mips.org>
Subject: Framebuffer for au1100
Date: Tue, 20 Apr 2004 11:43:25 +0200
Message-ID: <EIEHIDHKGJLNEPLOGOPOKEIACGAA.jh@hansen-telecom.dk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <jh@hansen-telecom.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4812
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jh@hansen-telecom.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 490
Lines: 15

Hi

I was trying to make use of framebuffer for a db1100 board. It looks like
au1100fb.c is not updated to kernel 2.6. It makes use of some structs and
procedures in fbcon that has been removed in 2.6.
Any ideas what is needed to get au1100fb.c to work in 2.6?
Has someone 2.6 to work with frambuffers on au1100?
I think that au1100fb is written for pb1100 that has an epson lcd controller
fitted.
Does that mean that nothing has been done for the internal lcd controller?


regards Jorg



From phorton@bitbox.co.uk Tue Apr 20 13:26:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 13:26:35 +0100 (BST)
Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:80.176.203.50]:52407 "EHLO
	pangolin.localnet") by linux-mips.org with ESMTP
	id <S8225759AbUDTM0e>; Tue, 20 Apr 2004 13:26:34 +0100
Received: from sprocket.localnet ([192.168.1.27] helo=bitbox.co.uk)
	by pangolin.localnet with esmtp (Exim 3.35 #1 (Debian))
	id 1BFuKa-00047H-00
	for <linux-mips@linux-mips.org>; Tue, 20 Apr 2004 13:26:28 +0100
Message-ID: <408516F3.5040700@bitbox.co.uk>
Date: Tue, 20 Apr 2004 13:26:27 +0100
From: Peter Horton <phorton@bitbox.co.uk>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Cobalt SCSI controller
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <phorton@bitbox.co.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4813
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: phorton@bitbox.co.uk
Precedence: bulk
X-list: linux-mips
Content-Length: 89
Lines: 5

Does anyone know where I can find a data sheet for this beast ?

It's an LSI 53C860.

P.

From macro@ds2.pg.gda.pl Tue Apr 20 14:41:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 14:41:43 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:53996 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225780AbUDTNll>; Tue, 20 Apr 2004 14:41:41 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id D46264AD95; Tue, 20 Apr 2004 15:41:32 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id BA9FE4794B; Tue, 20 Apr 2004 15:41:32 +0200 (CEST)
Date: Tue, 20 Apr 2004 15:41:32 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [RFC] Separate time support for using cpu timer
In-Reply-To: <20040419180720.H14976@mvista.com>
Message-ID: <Pine.LNX.4.55.0404201522220.28193@jurand.ds.pg.gda.pl>
References: <20040419180720.H14976@mvista.com>
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: 4814
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 2040
Lines: 49

On Mon, 19 Apr 2004, Jun Sun wrote:

> Solution
> --------
> 
> All the boards that I am really concerned right now have cpu count/compare
> registers.  I believe this will even more so in the future.
> 
> Therefore I like to propose a separate time support for systems that use
> cpu timer as their system timer.
> 
> As you can see from the patch, the new code is much simpler.

 It makes it separate again -- more maintenance burden and a bigger
opportunity to have functional divergence, sigh...

 Additionally I don't think using the CP0 Count & Compare registers for
the system timer is the way to go.  It's rather a way to escape when
there's no other possibility.  A lot of systems have a reliable external
timer interrupt source and using it actually would free the CP0 registers
for other uses, like profiling or a programmable interval timer.

> The hidden agenda
> -----------------
> 
> OK, I admit there is another motivation in all of this.  Linux is moving
> to have higher resolution timer.  For example, see the introduction of high resolution 
> posix timer (http://sourceforge.net/projects/high-res-timers/).  Having a MIPS common
> time routine based on cpu timer makes it much easier to support
> such a feature for MIPS boards.  We don't need to mess with individual board timer
> anymore.
> 
> In addition I think in 2.7 time frame Linux needs to replace its ancient jiffy
> time system with a natively higher resolution time system.  A MIPS cpu timer based 
> routine would evolve much better into the future.

 Well, I don't think the two issues are coupled together, although, there
may be certain dependencies.  E.g. an external time source may actually
have a good resolution.

 Anyway, the details may be worth discussing when 2.7 spins off,
preferably on the LKML, as this is about generic support.

  Maciej

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

From ppopov@mvista.com Tue Apr 20 16:30:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 16:30:43 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:57338 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225285AbUDTPam>;
	Tue, 20 Apr 2004 16:30:42 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id IAA24311;
	Tue, 20 Apr 2004 08:30:23 -0700
Message-ID: <4085420D.7040403@mvista.com>
Date: Tue, 20 Apr 2004 08:30:21 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?J=F8rg_Ulrich_Hansen?= <jh@hansen-telecom.dk>
CC: Linux-Mips <linux-mips@linux-mips.org>
Subject: Re: Framebuffer for au1100
References: <EIEHIDHKGJLNEPLOGOPOKEIACGAA.jh@hansen-telecom.dk>
In-Reply-To: <EIEHIDHKGJLNEPLOGOPOKEIACGAA.jh@hansen-telecom.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4815
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1026
Lines: 23

Jørg Ulrich Hansen wrote:

>Hi
>
>I was trying to make use of framebuffer for a db1100 board. It looks like
>au1100fb.c is not updated to kernel 2.6. It makes use of some structs and
>procedures in fbcon that has been removed in 2.6.
>Any ideas what is needed to get au1100fb.c to work in 2.6?
>Has someone 2.6 to work with frambuffers on au1100?
>I think that au1100fb is written for pb1100 that has an epson lcd controller
>fitted.
>Does that mean that nothing has been done for the internal lcd controller?
>  
>
No, the internal au1100 fb controller is supported in 2.4. The external 
epson controller is supported through the LCD chip select. What needs to 
be done in 2.6 is an update of the au1100fb driver to the new api. Right 
now what I'm working on part time is syncing up 2.6 with the latest 2.4 
updates and getting the basic features functioning, including the 36 bit 
address support. Then the drivers update will come one at a time. Of 
course, if someone else has time to help, patches are welcomed :)

Pete

From jh@hansen-telecom.dk Tue Apr 20 17:06:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 17:06:15 +0100 (BST)
Received: from pfepc.post.tele.dk ([IPv6:::ffff:195.41.46.237]:14740 "EHLO
	pfepc.post.tele.dk") by linux-mips.org with ESMTP
	id <S8225288AbUDTQGO> convert rfc822-to-8bit; Tue, 20 Apr 2004 17:06:14 +0100
Received: from ANNEMETTE (0x50c71479.adsl-fixed.tele.dk [80.199.20.121])
	by pfepc.post.tele.dk (Postfix) with ESMTP id DB7D226283E;
	Tue, 20 Apr 2004 18:06:09 +0200 (CEST)
From: =?iso-8859-1?Q?J=F8rg_Ulrich_Hansen?= <jh@hansen-telecom.dk>
To: "'Pete Popov'" <ppopov@mvista.com>
Cc: "Linux-Mips" <linux-mips@linux-mips.org>
Subject: SV: Framebuffer for au1100
Date: Tue, 20 Apr 2004 18:06:27 +0200
Message-ID: <004f01c426f1$7085b080$050ba8c0@ANNEMETTE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <4085420D.7040403@mvista.com>
Return-Path: <jh@hansen-telecom.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4816
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jh@hansen-telecom.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 1383
Lines: 46

> Jørg Ulrich Hansen wrote:
> 
> >Hi
> >
> >I was trying to make use of framebuffer for a db1100 board. It looks 
> >like au1100fb.c is not updated to kernel 2.6. It makes use of some 
> >structs and procedures in fbcon that has been removed in 
> 2.6. Any ideas 
> >what is needed to get au1100fb.c to work in 2.6? Has someone 2.6 to 
> >work with frambuffers on au1100? I think that au1100fb is 
> written for 
> >pb1100 that has an epson lcd controller fitted.
> >Does that mean that nothing has been done for the internal 
> lcd controller?
> >  
> >
> No, the internal au1100 fb controller is supported in 2.4. 
> The external 
> epson controller is supported through the LCD chip select. 
> What needs to 
> be done in 2.6 is an update of the au1100fb driver to the new 
> api. Right 
> now what I'm working on part time is syncing up 2.6 with the 
> latest 2.4 
> updates and getting the basic features functioning, including 
> the 36 bit 
> address support. Then the drivers update will come one at a time. Of 
> course, if someone else has time to help, patches are welcomed :)
> 
> Pete
> 
Hi

If you can put me in the right direction I am very keen on helping.
I have included the file in Kconfig but then it wound compile because of
the old 2.4 files (fbcon).
What are the tasks and are you aware of any framebuffer code that are
already modyfired?

Regards Jorg




 


From ppopov@mvista.com Tue Apr 20 17:34:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 17:34:47 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:64499 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225428AbUDTQeq>;
	Tue, 20 Apr 2004 17:34:46 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA29054;
	Tue, 20 Apr 2004 09:34:41 -0700
Message-ID: <40855117.5070100@mvista.com>
Date: Tue, 20 Apr 2004 09:34:31 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?J=F8rg_Ulrich_Hansen?= <jh@hansen-telecom.dk>
CC: Linux-Mips <linux-mips@linux-mips.org>
Subject: Re: SV: Framebuffer for au1100
References: <004f01c426f1$7085b080$050ba8c0@ANNEMETTE>
In-Reply-To: <004f01c426f1$7085b080$050ba8c0@ANNEMETTE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4817
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 742
Lines: 19


>Hi
>
>If you can put me in the right direction I am very keen on helping.
>I have included the file in Kconfig but then it wound compile because of
>the old 2.4 files (fbcon).
>What are the tasks and are you aware of any framebuffer code that are
>already modyfired?
>  
>
The entire FB API is different. Take a look at the skeleton fb driver -- 
there are headers with each function explaining what it does. There may 
be some other documentation in the Documentation directory but I'm not 
sure. It's not as easy as updated Kconfig. But fortunately the au1100fb 
driver is a pretty simple driver so updating it shouldn't be that bad. I 
would suggest you follow the example of a 2.6 FB driver that has been 
updated to the new API.

Pete

From jsun@orion.mvista.com Tue Apr 20 18:51:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 18:51:19 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27638 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225288AbUDTRvS>;
	Tue, 20 Apr 2004 18:51:18 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i3KHpGx6027959;
	Tue, 20 Apr 2004 10:51:16 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i3KHpGPK027957;
	Tue, 20 Apr 2004 10:51:16 -0700
Date: Tue, 20 Apr 2004 10:51:16 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20040420105116.C22846@mvista.com>
References: <20040420163230Z8225288-1530+99@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040420163230Z8225288-1530+99@linux-mips.org>; from sjhill@linux-mips.org on Tue, Apr 20, 2004 at 05:32:25PM +0100
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4818
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 634
Lines: 21

On Tue, Apr 20, 2004 at 05:32:25PM +0100, sjhill@linux-mips.org wrote:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	sjhill@ftp.linux-mips.org	04/04/20 17:32:25
> 
> Modified files:
> 	arch/mips      : Tag: linux_2_4 config-shared.in 
> 
> Log message:
> 	Do not allow CONFIG_PCI_AUTO to be selectable to discourage new users
> 	from using this b0rked code.
> 

CONFIG_PCI_AUTO was meant to a board attribute.  It should not be changed
to be a choice at the first place.

And, the code is not bOrked.  In 2.4 it is a life saver for most MIPS boards
whose firmware do not do a proper or full PCI resource assignment.

Jun

From ralf@linux-mips.org Tue Apr 20 21:11:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 21:11:34 +0100 (BST)
Received: from p508B7E6E.dip.t-dialin.net ([IPv6:::ffff:80.139.126.110]:64546
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225288AbUDTULc>; Tue, 20 Apr 2004 21:11:32 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3KKBTxT024774;
	Tue, 20 Apr 2004 22:11:29 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3KKBT62024773;
	Tue, 20 Apr 2004 22:11:29 +0200
Date: Tue, 20 Apr 2004 22:11:28 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20040420201128.GC24025@linux-mips.org>
References: <20040420163230Z8225288-1530+99@linux-mips.org> <20040420105116.C22846@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040420105116.C22846@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: 4819
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 512
Lines: 13

On Tue, Apr 20, 2004 at 10:51:16AM -0700, Jun Sun wrote:

> CONFIG_PCI_AUTO was meant to a board attribute.  It should not be changed
> to be a choice at the first place.
> 
> And, the code is not bOrked.  In 2.4 it is a life saver for most MIPS boards
> whose firmware do not do a proper or full PCI resource assignment.

drivers/pci can do that, you just need to supply a few board specific
functions, see for example arch/alpha/kernel/pci.c.  So pci_auto.c isn't
only b0rked, it also duplicates code.

  Ralf

From ppopov@mvista.com Tue Apr 20 21:20:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 21:20:56 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:39419 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225288AbUDTUUz>;
	Tue, 20 Apr 2004 21:20:55 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id NAA11637;
	Tue, 20 Apr 2004 13:20:48 -0700
Message-ID: <4085861D.4030603@mvista.com>
Date: Tue, 20 Apr 2004 13:20:45 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
References: <20040420163230Z8225288-1530+99@linux-mips.org> <20040420105116.C22846@mvista.com> <20040420201128.GC24025@linux-mips.org>
In-Reply-To: <20040420201128.GC24025@linux-mips.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4820
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1194
Lines: 32

Ralf Baechle wrote:

>On Tue, Apr 20, 2004 at 10:51:16AM -0700, Jun Sun wrote:
>
>  
>
>>CONFIG_PCI_AUTO was meant to a board attribute.  It should not be changed
>>to be a choice at the first place.
>>
>>And, the code is not bOrked.  In 2.4 it is a life saver for most MIPS boards
>>whose firmware do not do a proper or full PCI resource assignment.
>>    
>>
>
>drivers/pci can do that, you just need to supply a few board specific
>functions, see for example arch/alpha/kernel/pci.c.  
>
>So pci_auto.c isn't only b0rked, it also duplicates code.
>  
>
I guess I have different take on it, in line with Jun's. Before pci 
auto, I remember new boards going in without proper pci config support 
or with massive amounts of new board specific code. Take a look at the 
gt64xxx code (though I think it's been cleaned up a lot since then). 
After pci auto, adding pci support for a new board became trivial and I 
haven't seen anymore code duplication with new boards adding their own, 
complete, pci resource assignment routines.  Pci auto was added a long 
time ago. If it has outlived its purpose, that's fine, but back then it 
was a major improvement to the mips pci subsystem, imho.

Pete


From rainer@canavan.de Tue Apr 20 21:23:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 21:23:19 +0100 (BST)
Received: from h-213.61.10.4.host.de.colt.net ([IPv6:::ffff:213.61.10.4]:3990
	"EHLO erstmal.office.sevenval.de") by linux-mips.org with ESMTP
	id <S8225288AbUDTUXS>; Tue, 20 Apr 2004 21:23:18 +0100
Received: from ozone.nonet (d42-191.dsl.easysurfnet.de [83.121.42.191])
	by erstmal.office.sevenval.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id i3KKNAZ29189
	for <linux-mips@linux-mips.org>; Tue, 20 Apr 2004 22:23:11 +0200
Received: from ozone.nonet (localhost [127.0.0.1])
	by ozone.nonet (SGI-8.12.5/8.12.5) with ESMTP id i3KKNtgR001375
	for <linux-mips@linux-mips.org>; Tue, 20 Apr 2004 22:23:55 +0200 (CEST)
Received: (from canavan@localhost)
	by ozone.nonet (SGI-8.12.5/8.12.5/Submit) id i3KKNsHx001373
	for linux-mips@linux-mips.org; Tue, 20 Apr 2004 22:23:54 +0200 (CEST)
Message-Id: <200404202023.i3KKNsHx001373@ozone.nonet>
Date: Tue, 20 Apr 2004 22:23:54 +0200 (CEST)
To: linux-mips@linux-mips.org
Subject: Re: Cobalt SCSI controller
From: "Rainer M. Canavan" <rainer@canavan.de>
X-Mailer: Ishmail 2.1.0-20040411-mips-sgi-irix6.5 <http://ishmail.sourceforge.net>
MIME-Version: 1.0
Content-Type: text/plain
Return-Path: <rainer@canavan.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: 4821
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rainer@canavan.de
Precedence: bulk
X-list: linux-mips
Content-Length: 210
Lines: 8

> Does anyone know where I can find a data sheet for this beast ?
> 
> It's an LSI 53C860.

Some info on the 860 is in symbios_8xxpg_21.pdf found at 
http://www.tangro.de/~hf/macbsd/symbios_53cXXX_doc/

rainer

From jsun@orion.mvista.com Tue Apr 20 23:23:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 23:23:11 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:39926 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225525AbUDTWXI>;
	Tue, 20 Apr 2004 23:23:08 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i3KMN6x6009693;
	Tue, 20 Apr 2004 15:23:06 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i3KMN6OJ009691;
	Tue, 20 Apr 2004 15:23:06 -0700
Date: Tue, 20 Apr 2004 15:23:06 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [RFC] Support cpu timer for SMP case
Message-ID: <20040420152306.E22846@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4822
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 10670
Lines: 393


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


This patch illustrates that the cpu timer can be used as
system timer on a SMP system:

1) count/compare on CPU 0 registers are used to generate 
   jiffy interrupts

2) at the end of processing jiffy interrupt, cpu 0 sends
   a special inter-processor interrupt (IPI) to all other
   cpus and make them do process accounting stuff 
   (local_timer_interrupt()).

3) count registers on all CPU 0 are sync'ed up at the beginning.
   As a result we will have a consistent time reading on 
   all CPUs (do_gettimeofday()).

This patch assumes that the count registers on different CPUs
don't drift from each other after they sync up.  If they do drift,
we can change the code to allow periodic sync up.  We can
probably even support different count frequencies.

This patch is actually tested to be working on sibyte boards.

As a by-product of the patch we also fix a "gettimeofday() going backward"
problem on those smp boards.

Jun

P.S., the patch really looks more complicated than it should be, because
	I am leaving the old time code for the board there but "ifdef"ed out.
	If we make a complete transition to cpu timer, all the ifdef's and
	old time code for the board should go away.

--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="040420.a-cpu-timer-for-smp.patch"

diff -u linux/arch/mips/Kconfig linux/arch/mips/Kconfig
--- linux/arch/mips/Kconfig	2004-04-19 16:42:18.000000000 -0700
+++ linux/arch/mips/Kconfig	2004-04-20 14:38:18.000000000 -0700
@@ -522,10 +522,12 @@
 config SIBYTE_SENTOSA
 	bool "BCM91250E-Sentosa"
 	select SIBYTE_SB1250
+	select CPU_TIMER
 
 config SIBYTE_RHONE
 	bool "BCM91125E-Rhone"
 	select SIBYTE_BCM1125H
+	select CPU_TIMER
 
 config SIBYTE_CARMEL
 	bool "BCM91120x-Carmel"
diff -u linux/arch/mips/kernel/cpu-timer.c linux/arch/mips/kernel/cpu-timer.c
--- linux/arch/mips/kernel/cpu-timer.c	2004-04-19 17:01:13.000000000 -0700
+++ linux/arch/mips/kernel/cpu-timer.c	2004-04-20 14:23:11.000000000 -0700
@@ -244,6 +244,11 @@
 			atomic_inc((atomic_t *)&prof_buffer[pc]);
 		}
 	}
+
+#ifdef CONFIG_SMP
+	/* in UP mode, update_process_times() is invoked by do_timer() */
+	update_process_times(user_mode(regs));
+#endif
 }
 
 /*
@@ -296,6 +301,16 @@
 	 */
 	local_timer_interrupt(irq, dev_id, regs);
 
+#if defined(CONFIG_SMP)
+	/* In SMP mode, we also ask other CPUs to do the same */
+	{ 
+		int i;
+		for (i = 1; i < NR_CPUS; i++) 
+			if (cpu_online(i))
+				core_send_ipi(i, SMP_EMULATE_LOCAL_TIMER);
+	}
+#endif
+
 	return IRQ_HANDLED;
 }
 
@@ -446,0 +461,135 @@
+
+#if defined(CONFIG_SMP)
+static atomic_t  rend_start;
+static atomic_t  rend_ready;
+static atomic_t  rend_cpus;
+
+static void rendezvous_init(int v)
+{
+       atomic_set(&rend_cpus, 0); mb();
+       atomic_set(&rend_start, v); mb();
+       atomic_set(&rend_ready, v); mb();
+}
+
+static void rendezvous_master(int v)
+{
+       db_assert(atomic_read(&rend_start) != v); 
+
+       atomic_set(&rend_cpus, 0); mb();
+       atomic_set(&rend_start, v); mb();
+       while (atomic_read(&rend_cpus) != num_online_cpus() -1)
+               mb();
+       atomic_set(&rend_ready, v); mb();
+}
+
+#define rendezvous_master_extra(v, cmd) { \
+       int val=(v); \
+       db_assert(atomic_read(&rend_start) != val); \
+       atomic_set(&rend_cpus, 0); mb(); \
+       atomic_set(&rend_start, val); mb(); \
+       while (atomic_read(&rend_cpus) != num_online_cpus() -1) mb(); \
+       { cmd; } \
+       atomic_set(&rend_ready, val); mb(); \
+}
+       
+static void rendezvous_slave(int v)
+{
+       while (atomic_read(&rend_start) != v)
+               mb();
+       atomic_inc(&rend_cpus); mb();
+       while (atomic_read(&rend_ready) != v)
+               mb();
+}
+
+static void rendezvous_slave_exit(int v)
+{
+       while (atomic_read(&rend_start) != v)
+               mb();
+       atomic_inc(&rend_cpus); mb();
+}
+
+#define        LOOPS           8
+static u32 c0_count[NR_CPUS];
+static u32 c[NR_CPUS][LOOPS+1];
+static void sync_c0_count_slave(void *info)
+{
+       unsigned long flags;
+       int i, loop;
+       int cpu = smp_processor_id();
+       u32 diff;
+       int prev_diff;
+
+       db_assert(cpu != 0);
+
+       i=1;
+       prev_diff = 0;
+
+       local_irq_save(flags);
+       for (loop=0; loop<= LOOPS; loop++) {
+
+               rendezvous_slave(i++);
+               c[cpu][loop] = c0_count[cpu] = read_c0_count(); mb();
+
+               if (loop == LOOPS)
+                       break;
+
+               rendezvous_slave(i++);
+               diff = c0_count[0] - c0_count[cpu];
+               diff += (u32)prev_diff;
+               diff += read_c0_count();
+               write_c0_count(diff);
+       
+               /* discard the first diff which is probably very big */ 
+               if (loop > 0)
+                      prev_diff = (prev_diff >> 1) +
+                              ((int)(c0_count[0] - c0_count[cpu]) >> 1);
+       }
+
+       rendezvous_slave_exit(i++);
+       local_irq_restore(flags);
+}
+
+void sync_c0_count(void)
+{
+       int cpu=smp_processor_id();
+       unsigned long flags;
+       int i, loop;
+
+       db_assert(cpu == 0);
+
+       printk("SMP: start to sync c0 count...\n");
+
+       i=0; rendezvous_init(i++);
+
+       smp_call_function(sync_c0_count_slave, NULL, 0, 0);
+
+       local_irq_save(flags);
+       for (loop=0; loop<= LOOPS; loop++) {
+               /* wait for all cpus to gether here */
+               rendezvous_master(i++);
+               c[cpu][loop] = c0_count[cpu] = read_c0_count(); mb();
+
+               if (loop == LOOPS)
+                       break;
+
+               rendezvous_master(i++);
+               /* master does nothing here */
+       }
+
+       rendezvous_master(i++);
+       local_irq_restore(flags);
+
+       /* print results */
+       printk("SMP: end of c0 count sync'ing ... \n");
+       for (i=0; i<= LOOPS; i++) {
+               int j;
+               printk("\t%08x", c[0][i]);
+               for (j=1; j<NR_CPUS; j++) 
+                       if (c[j][i] == 0) 
+                               printk("\t-");
+                       else
+                               printk("\t%d", c[j][i] - c[0][i]);
+               printk("\n");
+       }
+}
+#endif
only in patch2:
unchanged:
--- linux/include/asm-mips/smp.h.orig	2004-03-09 16:41:35.000000000 -0800
+++ linux/include/asm-mips/smp.h	2004-04-20 13:55:09.000000000 -0700
@@ -46,6 +46,7 @@
 
 #define SMP_RESCHEDULE_YOURSELF	0x1	/* XXX braindead */
 #define SMP_CALL_FUNCTION	0x2
+#define SMP_EMULATE_LOCAL_TIMER	0x4
 
 extern cpumask_t phys_cpu_present_map;
 extern cpumask_t cpu_online_map;
only in patch2:
unchanged:
--- linux/arch/mips/sibyte/swarm/setup.c.orig	2004-03-15 17:55:24.000000000 -0800
+++ linux/arch/mips/sibyte/swarm/setup.c	2004-04-20 14:00:02.000000000 -0700
@@ -57,6 +57,7 @@
 
 void __init swarm_timer_setup(struct irqaction *irq)
 {
+#if !defined(CONFIG_CPU_TIMER)
         /*
          * we don't set up irqaction, because we will deliver timer
          * interrupts through low-level (direct) meachanism.
@@ -64,6 +65,7 @@
 
         /* We only need to setup the generic timer */
         sb1250_time_init();
+#endif
 }
 
 int swarm_be_handler(struct pt_regs *regs, int is_fixup)
@@ -104,6 +106,9 @@
 		rtc_set_time = m41t81_set_time;
 	}
 
+	/* hack for now */
+	mips_hpt_frequency = 600000000;
+
 	printk("This kernel optimized for "
 #ifdef CONFIG_SIMULATION
 	       "simulation"
only in patch2:
unchanged:
--- linux/arch/mips/sibyte/sb1250/Makefile.orig	2003-10-02 14:34:44.000000000 -0700
+++ linux/arch/mips/sibyte/sb1250/Makefile	2004-04-20 14:40:29.000000000 -0700
@@ -1,8 +1,12 @@
-obj-y := setup.o irq.o irq_handler.o time.o
+obj-y := setup.o irq.o irq_handler.o 
 
 obj-$(CONFIG_SMP)			+= smp.o
 obj-$(CONFIG_SIBYTE_TBPROF)		+= bcm1250_tbprof.o
 obj-$(CONFIG_SIBYTE_STANDALONE)		+= prom.o
 obj-$(CONFIG_SIBYTE_BUS_WATCHER)	+= bus_watcher.o
 
+ifndef CONFIG_CPU_TIMER
+obj-y					+= time.o
+endif
+
 EXTRA_AFLAGS := $(CFLAGS)
only in patch2:
unchanged:
--- linux/arch/mips/sibyte/sb1250/irq_handler.S.orig	2004-01-05 10:48:17.000000000 -0800
+++ linux/arch/mips/sibyte/sb1250/irq_handler.S	2004-04-20 14:18:01.000000000 -0700
@@ -65,6 +65,8 @@
 #endif
 	/* Read cause */
 	mfc0	s0, CP0_CAUSE
+	mfc0    t0, CP0_STATUS
+	and     s0, s0, t0              /* mask away disabled irqs */
 
 #ifdef CONFIG_SIBYTE_SB1250_PROF
 	/* Cpu performance counter interrupt is routed to IP[7] */
@@ -80,6 +82,17 @@
 0:
 #endif
 
+#if defined(CONFIG_CPU_TIMER)
+	andi    t1, s0, CAUSEF_IP7
+	beqz    t1, 1f
+	nop
+	li      a0, 64
+	move    a1, sp
+	jal     ll_timer_interrupt
+	nop
+	j       ret_from_irq
+	nop
+#else
 	/* Timer interrupt is routed to IP[4] */
 	andi	t1, s0, CAUSEF_IP4
 	beqz	t1, 1f
@@ -88,6 +101,7 @@
 	 move	a0, sp			/* Pass the registers along */
 	j	ret_from_irq
 	 nop				# delay slot
+#endif
 1:
 
 #ifdef CONFIG_SMP
only in patch2:
unchanged:
--- linux/arch/mips/sibyte/sb1250/irq.c.orig	2003-11-10 15:24:40.000000000 -0800
+++ linux/arch/mips/sibyte/sb1250/irq.c	2004-04-20 14:14:37.000000000 -0700
@@ -386,6 +386,9 @@
 #ifdef CONFIG_KGDB
 	imask |= STATUSF_IP6;
 #endif
+#if defined(CONFIG_CPU_TIMER)
+	imask |= STATUSF_IP7;
+#endif
 	/* Enable necessary IPs, disable the rest */
 	change_c0_status(ST0_IM, imask);
 	set_except_vector(0, sb1250_irq_handler);
only in patch2:
unchanged:
--- linux/arch/mips/sibyte/sb1250/smp.c.orig	2004-03-15 17:55:24.000000000 -0800
+++ linux/arch/mips/sibyte/sb1250/smp.c	2004-04-20 14:43:23.000000000 -0700
@@ -22,6 +22,7 @@
 #include <linux/smp.h>
 #include <linux/kernel_stat.h>
 
+#include <asm/time.h>
 #include <asm/mmu_context.h>
 #include <asm/io.h>
 #include <asm/sibyte/sb1250.h>
@@ -57,8 +58,10 @@
 
 void sb1250_smp_finish(void)
 {
+#if !defined(CONFIG_CPU_TIMER)
 	extern void sb1250_time_init(void);
 	sb1250_time_init();
+#endif
 	local_irq_enable();
 }
 
@@ -95,4 +98,10 @@
 
 	if (action & SMP_CALL_FUNCTION)
 		smp_call_function_interrupt();
+
+	if (action & SMP_EMULATE_LOCAL_TIMER) {
+		irq_enter();
+		local_timer_interrupt(0, NULL, regs);
+		irq_exit();
+	}
 }
only in patch2:
unchanged:
--- linux/arch/mips/kernel/smp.c.orig	2004-03-09 16:40:21.000000000 -0800
+++ linux/arch/mips/kernel/smp.c	2004-04-20 14:18:55.000000000 -0700
@@ -224,6 +224,13 @@
 void __init smp_cpus_done(unsigned int max_cpus)
 {
 	prom_cpus_done();
+
+#if defined(CONFIG_CPU_TIMER)
+	{
+		extern void sync_c0_count(void);
+		sync_c0_count();
+	}
+#endif
 }
 
 /* called from main before smp_init() */

--tKW2IUtsqtDRztdT--

From jsun@orion.mvista.com Tue Apr 20 23:31:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 23:31:11 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:16881 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225525AbUDTWbK>;
	Tue, 20 Apr 2004 23:31:10 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i3KMV8x6009780;
	Tue, 20 Apr 2004 15:31:08 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i3KMV8ZX009778;
	Tue, 20 Apr 2004 15:31:08 -0700
Date: Tue, 20 Apr 2004 15:31:08 -0700
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20040420153108.F22846@mvista.com>
References: <20040420163230Z8225288-1530+99@linux-mips.org> <20040420105116.C22846@mvista.com> <20040420201128.GC24025@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040420201128.GC24025@linux-mips.org>; from ralf@linux-mips.org on Tue, Apr 20, 2004 at 10:11:28PM +0200
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4823
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 858
Lines: 22

On Tue, Apr 20, 2004 at 10:11:28PM +0200, Ralf Baechle wrote:
> On Tue, Apr 20, 2004 at 10:51:16AM -0700, Jun Sun wrote:
> 
> > CONFIG_PCI_AUTO was meant to a board attribute.  It should not be changed
> > to be a choice at the first place.
> > 
> > And, the code is not bOrked.  In 2.4 it is a life saver for most MIPS boards
> > whose firmware do not do a proper or full PCI resource assignment.
> 
> drivers/pci can do that, you just need to supply a few board specific
> functions, see for example arch/alpha/kernel/pci.c.  So pci_auto.c isn't
> only b0rked, it also duplicates code.
> 

Has anybody succssfully used pci_assign_unassigned_resources() in latest 2.4?
It was badly broken in early 2.4 kernels while pci_auto was the only 
option.

So at most you can only say "pci_assign_unassigned_resources() can
finally does what pci_auto does". :)

Jun

From hverhagen@dse.nl Tue Apr 20 23:45:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 23:45:35 +0100 (BST)
Received: from amsfep12-int.chello.nl ([IPv6:::ffff:213.46.243.18]:13841 "EHLO
	amsfep12-int.chello.nl") by linux-mips.org with ESMTP
	id <S8225525AbUDTWpe>; Tue, 20 Apr 2004 23:45:34 +0100
Received: from node-d-8d2e.a2000.nl ([62.195.141.46])
          by amsfep12-int.chello.nl
          (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP
          id <20040420224526.FLAG18840.amsfep12-int.chello.nl@node-d-8d2e.a2000.nl>;
          Wed, 21 Apr 2004 00:45:26 +0200
Subject: locking problems with mips atomicity ?
From: Harm Verhagen <hverhagen@dse.nl>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Organization: 
Message-Id: <1082501074.13783.54.camel@node-d-8d2e.a2000.nl>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 21 Apr 2004 00:44:34 +0200
Content-Transfer-Encoding: 7bit
Return-Path: <hverhagen@dse.nl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4824
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hverhagen@dse.nl
Precedence: bulk
X-list: linux-mips
Content-Length: 1132
Lines: 40

Hi folks,

I noticed the following thread "locking problem with mips atomicity" on
the GCC mailing list, and I started to wonder if the linux kernel has
the same problem.

http://gcc.gnu.org/ml/gcc/2004-03/threads.html#01061


It about the problem that gcc can generate loads (using AT) in between
the ll and sc instructions (which is not legal according to the MIPS
spec) This can happen when  incorrect constraints are used with the
inline assembly, and the inline assembly happens to be in an inline
functions.

The code from linux 2.4.26 arch-mips/atomic.h looks _very_ similar to
the code described in the thread that has a BUG.

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

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

So I wonder if there is a bug here. 
Can some MIPS guru check ? :)


Please copy me on replies as I'm not subscribed

Kind regards,
Harm Verhagen


From drow@crack.them.org Tue Apr 20 23:49:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 23:49:13 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:39647 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225525AbUDTWtM>;
	Tue, 20 Apr 2004 23:49:12 +0100
Received: from drow by nevyn.them.org with local (Exim 4.32 #1 (Debian))
	id 1BG437-0001Bu-1B; Tue, 20 Apr 2004 18:49:05 -0400
Date: Tue, 20 Apr 2004 18:49:05 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Harm Verhagen <hverhagen@dse.nl>
Cc: linux-mips@linux-mips.org
Subject: Re: locking problems with mips atomicity ?
Message-ID: <20040420224904.GA21924@nevyn.them.org>
References: <1082501074.13783.54.camel@node-d-8d2e.a2000.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1082501074.13783.54.camel@node-d-8d2e.a2000.nl>
User-Agent: Mutt/1.5.5.1+cvs20040105i
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: 4825
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 948
Lines: 28

On Wed, Apr 21, 2004 at 12:44:34AM +0200, Harm Verhagen wrote:
> The code from linux 2.4.26 arch-mips/atomic.h looks _very_ similar to
> the code described in the thread that has a BUG.
> 
> static __inline__ void atomic_add(int i, atomic_t * v)
> {
> 	unsigned long temp;
> 
> 	__asm__ __volatile__(
> 		"1:   ll      %0, %1      # atomic_add\n"
> 		"     addu    %0, %2                  \n"
> 		"     sc      %0, %1                  \n"
> 		"     beqz    %0, 1b                  \n"
> 		: "=&r" (temp), "=m" (v->counter)
> 		: "Ir" (i), "m" (v->counter));
> }
> 
> So I wonder if there is a bug here. 
> Can some MIPS guru check ? :)

It won't be a problem in the kernel.  The problem only happens when the
assembler expands a macro to multiple instructions including a load,
and that only happens for position-independent code; the kernel is not
PIC.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From hverhagen@dse.nl Tue Apr 20 23:54:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 23:54:54 +0100 (BST)
Received: from amsfep17-int.chello.nl ([IPv6:::ffff:213.46.243.15]:30294 "EHLO
	amsfep17-int.chello.nl") by linux-mips.org with ESMTP
	id <S8225770AbUDTWyx>; Tue, 20 Apr 2004 23:54:53 +0100
Received: from node-d-8d2e.a2000.nl ([62.195.141.46])
          by amsfep17-int.chello.nl
          (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP
          id <20040420225448.EBDX15425.amsfep17-int.chello.nl@node-d-8d2e.a2000.nl>;
          Wed, 21 Apr 2004 00:54:48 +0200
Subject: Re: locking problems with mips atomicity ?
From: Harm Verhagen <hverhagen@dse.nl>
To: Daniel Jacobowitz <dan@debian.org>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040420224904.GA21924@nevyn.them.org>
References: <1082501074.13783.54.camel@node-d-8d2e.a2000.nl>
	 <20040420224904.GA21924@nevyn.them.org>
Content-Type: text/plain
Organization: 
Message-Id: <1082501636.13783.69.camel@node-d-8d2e.a2000.nl>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 21 Apr 2004 00:53:56 +0200
Content-Transfer-Encoding: 7bit
Return-Path: <hverhagen@dse.nl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4826
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hverhagen@dse.nl
Precedence: bulk
X-list: linux-mips
Content-Length: 1138
Lines: 32

On Wed, 2004-04-21 at 00:49, Daniel Jacobowitz wrote:
> On Wed, Apr 21, 2004 at 12:44:34AM +0200, Harm Verhagen wrote:
> > The code from linux 2.4.26 arch-mips/atomic.h looks _very_ similar to
> > the code described in the thread that has a BUG.
> > 
> > static __inline__ void atomic_add(int i, atomic_t * v)
> > {
> > 	unsigned long temp;
> > 
> > 	__asm__ __volatile__(
> > 		"1:   ll      %0, %1      # atomic_add\n"
> > 		"     addu    %0, %2                  \n"
> > 		"     sc      %0, %1                  \n"
> > 		"     beqz    %0, 1b                  \n"
> > 		: "=&r" (temp), "=m" (v->counter)
> > 		: "Ir" (i), "m" (v->counter));
> > }
> > 
> > So I wonder if there is a bug here. 
> > Can some MIPS guru check ? :)
> 
> It won't be a problem in the kernel.  The problem only happens when the
> assembler expands a macro to multiple instructions including a load,
> and that only happens for position-independent code; the kernel is not
> PIC.
Sorry for not understanding completely. What makes the gcc code PIC
then? The code looks similar, an inline function with inline assembly.
Could you elaborate ?

Kind regards,
Harm


From drow@crack.them.org Tue Apr 20 23:56:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Apr 2004 23:56:34 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:44511 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225727AbUDTW4c>;
	Tue, 20 Apr 2004 23:56:32 +0100
Received: from drow by nevyn.them.org with local (Exim 4.32 #1 (Debian))
	id 1BG4AE-000203-PN; Tue, 20 Apr 2004 18:56:29 -0400
Date: Tue, 20 Apr 2004 18:56:26 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Harm Verhagen <hverhagen@dse.nl>
Cc: linux-mips@linux-mips.org
Subject: Re: locking problems with mips atomicity ?
Message-ID: <20040420225626.GA5980@nevyn.them.org>
References: <1082501074.13783.54.camel@node-d-8d2e.a2000.nl> <20040420224904.GA21924@nevyn.them.org> <1082501636.13783.69.camel@node-d-8d2e.a2000.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1082501636.13783.69.camel@node-d-8d2e.a2000.nl>
User-Agent: Mutt/1.5.5.1+cvs20040105i
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: 4827
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1578
Lines: 39

On Wed, Apr 21, 2004 at 12:53:56AM +0200, Harm Verhagen wrote:
> On Wed, 2004-04-21 at 00:49, Daniel Jacobowitz wrote:
> > On Wed, Apr 21, 2004 at 12:44:34AM +0200, Harm Verhagen wrote:
> > > The code from linux 2.4.26 arch-mips/atomic.h looks _very_ similar to
> > > the code described in the thread that has a BUG.
> > > 
> > > static __inline__ void atomic_add(int i, atomic_t * v)
> > > {
> > > 	unsigned long temp;
> > > 
> > > 	__asm__ __volatile__(
> > > 		"1:   ll      %0, %1      # atomic_add\n"
> > > 		"     addu    %0, %2                  \n"
> > > 		"     sc      %0, %1                  \n"
> > > 		"     beqz    %0, 1b                  \n"
> > > 		: "=&r" (temp), "=m" (v->counter)
> > > 		: "Ir" (i), "m" (v->counter));
> > > }
> > > 
> > > So I wonder if there is a bug here. 
> > > Can some MIPS guru check ? :)
> > 
> > It won't be a problem in the kernel.  The problem only happens when the
> > assembler expands a macro to multiple instructions including a load,
> > and that only happens for position-independent code; the kernel is not
> > PIC.
> Sorry for not understanding completely. What makes the gcc code PIC
> then? The code looks similar, an inline function with inline assembly.
> Could you elaborate ?

You may want to look for documentation describing the MIPS PIC
conventions.  Good luck; they're bizarre.

The problem is that in userspace "ll $2, symbol_name" may expand to a
load of the address of symbol_name from the GOT (global offset table).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From jsun@orion.mvista.com Wed Apr 21 00:25:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 00:25:10 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:60398 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225727AbUDTXZI>;
	Wed, 21 Apr 2004 00:25:08 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i3KNP0x6023838;
	Tue, 20 Apr 2004 16:25:00 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i3KNP0xo023836;
	Tue, 20 Apr 2004 16:25:00 -0700
Date: Tue, 20 Apr 2004 16:25:00 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [RFC] Separate time support for using cpu timer
Message-ID: <20040420162500.H22846@mvista.com>
References: <20040419180720.H14976@mvista.com> <Pine.LNX.4.55.0404201522220.28193@jurand.ds.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.LNX.4.55.0404201522220.28193@jurand.ds.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Apr 20, 2004 at 03:41:32PM +0200
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4828
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1399
Lines: 36

On Tue, Apr 20, 2004 at 03:41:32PM +0200, Maciej W. Rozycki wrote:
> On Mon, 19 Apr 2004, Jun Sun wrote:
> 
> > Solution
> > --------
> > 
> > All the boards that I am really concerned right now have cpu count/compare
> > registers.  I believe this will even more so in the future.
> > 
> > Therefore I like to propose a separate time support for systems that use
> > cpu timer as their system timer.
> > 
> > As you can see from the patch, the new code is much simpler.
> 
>  It makes it separate again -- more maintenance burden and a bigger
> opportunity to have functional divergence, sigh...
> 

Pretty much true for lots of improvement we made in the past a couple of
years .... :)

>  Additionally I don't think using the CP0 Count & Compare registers for
> the system timer is the way to go.  It's rather a way to escape when
> there's no other possibility.  A lot of systems have a reliable external
> timer interrupt source and using it actually would free the CP0 registers
> for other uses, like profiling or a programmable interval timer.
> 

I was rather neutral on this point until I started to add HRT/VST support to 
MIPS.  When adding such features you really just want one common timer code.
And the best choice for MIPS is cpu timer.

BTW, I plan to submit MIPS/HRT support based on the cpu-timer patch.  Hopefully 
this will catch more attention to the cpu timer patch....

Jun

From sskowron@ET.PUT.Poznan.PL Wed Apr 21 04:39:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 04:39:56 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:653 "EHLO
	athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225226AbUDUDjz>; Wed, 21 Apr 2004 04:39:55 +0100
Received: from athena (athena [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3L3dru25710
	for <linux-mips@linux-mips.org>; Wed, 21 Apr 2004 05:39:53 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena (MailMonitor for SMTP v1.2.2 ) ;
	Wed, 21 Apr 2004 05:39:53 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3L3dqH19640
	for <linux-mips@linux-mips.org>; Wed, 21 Apr 2004 05:39:52 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Wed, 21 Apr 2004 05:39:52 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Re: [RFC] Separate time support for using cpu timer
In-Reply-To: <20040420162500.H22846@mvista.com>
Message-ID: <Pine.GSO.4.10.10404210537180.19332-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4829
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 449
Lines: 13

I must admit I would prefer a separate timer module. For instance, on the
IP30 there is a very convenient HEART timer available, and I don't see a
case for wasting a core-synchronized CPU timer (which proved indispensable
during my reverse engineering of the ARCS PROM, as you can't
breakpoint-debug a PROM) for the purpose of not-necessariliy-synchronized
timing.

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From raiko@niisi.msk.ru Wed Apr 21 09:51:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 09:51:35 +0100 (BST)
Received: from [IPv6:::ffff:193.232.173.111] ([IPv6:::ffff:193.232.173.111]:24582
	"EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP
	id <S8225792AbUDUIvb>; Wed, 21 Apr 2004 09:51:31 +0100
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.11.7/8.11.7) with ESMTP id i3L7q1R05544;
	Wed, 21 Apr 2004 11:52:01 +0400
Received: from t06.niisi.ras.ru (localhost.localdomain [127.0.0.1])
	by t06.niisi.ras.ru (8.12.8/8.12.8) with ESMTP id i3L8msFi030726;
	Wed, 21 Apr 2004 12:48:54 +0400
Received: (from uucp@localhost)
	by t06.niisi.ras.ru (8.12.8/8.12.8/Submit) with UUCP id i3L8msQY030724;
	Wed, 21 Apr 2004 12:48:54 +0400
Received: from niisi.msk.ru (aa01 [172.16.0.1])
	by aa19.niisi.msk.ru (8.12.8/8.12.8) with ESMTP id i3L8oTfX023432;
	Wed, 21 Apr 2004 12:50:30 +0400
Received: from niisi.msk.ru (t34 [193.232.173.34])
	by niisi.msk.ru (8.12.5/8.12.5) with ESMTP id i3L8oRtH028167;
	Wed, 21 Apr 2004 12:50:28 +0400 (MSK)
Message-ID: <408636EA.3004C913@niisi.msk.ru>
Date: Wed, 21 Apr 2004 12:55:06 +0400
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Jun Sun <jsun@mvista.com>
CC: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
References: <20040420163230Z8225288-1530+99@linux-mips.org> <20040420105116.C22846@mvista.com> <20040420201128.GC24025@linux-mips.org> <20040420153108.F22846@mvista.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
X-Scanned-By: milter-spamc/0.13.216 (aa19 [172.16.0.19]); Wed, 21 Apr 2004 12:50:30 +0400
Return-Path: <raiko@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4830
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: raiko@niisi.msk.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 1378
Lines: 39

Jun Sun wrote:
> 
> Has anybody succssfully used pci_assign_unassigned_resources() in latest 2.4?
> It was badly broken in early 2.4 kernels while pci_auto was the only
> option.

In fact, I have used pci_assign_unassigned_resources() from early 2.4
days. The only code I had to supply was
fixup of PCI-PCI bridge spaces which was done in pcibios_fixup_bus,
something like
        if(!bus->self) /* Primary busses */
                bus->resource[0] = &ioport_resource;
                bus->resource[1] = &iomem_resource;
	else /* busses behind PCI-PCI bridges */
	    for IO, MEM, and PREFETCH spaces:
                bus->resource[i] =
&bus->self->resource[PCI_BRIDGE_RESOURCES+i];
                bus->resource[i]->start =
bus->parent->resource[i]->start;
                bus->resource[i]->end   = bus->parent->resource[i]->end;
                bus->resource[i]->flags =
bus->parent->resource[i]->flags;
                bus->resource[i]->name  = bus->name;


Ah, I had to disable ISA mapping in 2.4.25.

After that, pci_assign_unassigned_resources() assigns all resources
properly. If for some reason, you have to preserve PBAR's values
assigned by a BIOS, setup pci_dev.resource[].parent before invoking
pci_assign_unassigned_resources.
> 
> So at most you can only say "pci_assign_unassigned_resources() can
> finally does what pci_auto does". :)

Exactly.

Regards,
Gleb.

From macro@ds2.pg.gda.pl Wed Apr 21 13:43:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 13:43:19 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:30094 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225803AbUDUMnR>; Wed, 21 Apr 2004 13:43:17 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id BEEF747624; Wed, 21 Apr 2004 14:43:10 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id B3345475C5; Wed, 21 Apr 2004 14:43:10 +0200 (CEST)
Date: Wed, 21 Apr 2004 14:43:10 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Daniel Jacobowitz <dan@debian.org>
Cc: Harm Verhagen <hverhagen@dse.nl>, linux-mips@linux-mips.org
Subject: Re: locking problems with mips atomicity ?
In-Reply-To: <20040420224904.GA21924@nevyn.them.org>
Message-ID: <Pine.LNX.4.55.0404211434370.28167@jurand.ds.pg.gda.pl>
References: <1082501074.13783.54.camel@node-d-8d2e.a2000.nl>
 <20040420224904.GA21924@nevyn.them.org>
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: 4831
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1292
Lines: 33

On Tue, 20 Apr 2004, Daniel Jacobowitz wrote:

> > static __inline__ void atomic_add(int i, atomic_t * v)
> > {
> > 	unsigned long temp;
> > 
> > 	__asm__ __volatile__(
> > 		"1:   ll      %0, %1      # atomic_add\n"
> > 		"     addu    %0, %2                  \n"
> > 		"     sc      %0, %1                  \n"
> > 		"     beqz    %0, 1b                  \n"
> > 		: "=&r" (temp), "=m" (v->counter)
> > 		: "Ir" (i), "m" (v->counter));
> > }
> > 
> > So I wonder if there is a bug here. 
> > Can some MIPS guru check ? :)
> 
> It won't be a problem in the kernel.  The problem only happens when the
> assembler expands a macro to multiple instructions including a load,
> and that only happens for position-independent code; the kernel is not
> PIC.

 And if using a function like the above is to be PIC, the solution is to
use the "R" constraint for the ll/sc memory operand to assure it's passed
to gas as a machine-expressible address, although I'm not sure if that's
currently handled by gcc correctly (2.95.x definitely has problems with
it; I'm going to look into it for 3.5.0 soon).

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

From macro@ds2.pg.gda.pl Wed Apr 21 14:19:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 14:19:52 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:18075 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225803AbUDUNTv>; Wed, 21 Apr 2004 14:19:51 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id AF2AB47A40; Wed, 21 Apr 2004 15:19:45 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 9BA2F475C5; Wed, 21 Apr 2004 15:19:45 +0200 (CEST)
Date: Wed, 21 Apr 2004 15:19:45 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [RFC] Separate time support for using cpu timer
In-Reply-To: <20040420162500.H22846@mvista.com>
Message-ID: <Pine.LNX.4.55.0404211445470.28167@jurand.ds.pg.gda.pl>
References: <20040419180720.H14976@mvista.com> <Pine.LNX.4.55.0404201522220.28193@jurand.ds.pg.gda.pl>
 <20040420162500.H22846@mvista.com>
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: 4832
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1284
Lines: 28

On Tue, 20 Apr 2004, Jun Sun wrote:

> >  It makes it separate again -- more maintenance burden and a bigger
> > opportunity to have functional divergence, sigh...
> 
> Pretty much true for lots of improvement we made in the past a couple of
> years .... :)

 Hmm, s/improvement/hacks/, perhaps?

> >  Additionally I don't think using the CP0 Count & Compare registers for
> > the system timer is the way to go.  It's rather a way to escape when
> > there's no other possibility.  A lot of systems have a reliable external
> > timer interrupt source and using it actually would free the CP0 registers
> > for other uses, like profiling or a programmable interval timer.
> 
> I was rather neutral on this point until I started to add HRT/VST support to 
> MIPS.  When adding such features you really just want one common timer code.
> And the best choice for MIPS is cpu timer.

 Well, with the _hpt_ abstraction layer you have one common timer code,
regardless of the actual timer hardware used.  If there's some
functionality you miss there, we may discuss about possible solutions.

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

From macro@ds2.pg.gda.pl Wed Apr 21 15:11:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 15:11:37 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:63913 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225806AbUDUOLg>; Wed, 21 Apr 2004 15:11:36 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id AFAE14AE0D; Wed, 21 Apr 2004 16:11:29 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 9E82A4AC7D; Wed, 21 Apr 2004 16:11:29 +0200 (CEST)
Date: Wed, 21 Apr 2004 16:11:29 +0200 (CEST)
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: CVS Update@-mips.org: linux
In-Reply-To: <20040420153108.F22846@mvista.com>
Message-ID: <Pine.LNX.4.55.0404211608570.28167@jurand.ds.pg.gda.pl>
References: <20040420163230Z8225288-1530+99@linux-mips.org>
 <20040420105116.C22846@mvista.com> <20040420201128.GC24025@linux-mips.org>
 <20040420153108.F22846@mvista.com>
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: 4833
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 781
Lines: 18

On Tue, 20 Apr 2004, Jun Sun wrote:

> > drivers/pci can do that, you just need to supply a few board specific
> > functions, see for example arch/alpha/kernel/pci.c.  So pci_auto.c isn't
> > only b0rked, it also duplicates code.
> 
> Has anybody succssfully used pci_assign_unassigned_resources() in latest 2.4?
> It was badly broken in early 2.4 kernels while pci_auto was the only 
> option.

 In that case, fixing pci_assign_unassigned_resources() was the right way
to go, instead of implementing a system-specific workaround.  There are no
excuses -- the source is available.

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

From yuasa@hh.iij4u.or.jp Wed Apr 21 15:17:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 15:17:05 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:23786 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225806AbUDUORD>;
	Wed, 21 Apr 2004 15:17:03 +0100
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id XAA28791;
	Wed, 21 Apr 2004 23:16:59 +0900 (JST)
Received: 4UMDO00 id i3LEGwq03092; Wed, 21 Apr 2004 23:16:59 +0900 (JST)
Received: 4UMRO01 id i3LEGvL09669; Wed, 21 Apr 2004 23:16:58 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Wed, 21 Apr 2004 23:16:56 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [patch][2.6] Kconfig patche for vr41xx's companion chip
Message-Id: <20040421231656.70361328.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4834
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 1215
Lines: 45

Hello Ralf,

This patch makes vr41xx's companion chip item depend on MACH_VR41XX.

Please apply this patch to cvs.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/Kconfig linux/arch/mips/Kconfig
--- linux-orig/arch/mips/Kconfig	Sun Mar 21 22:06:02 2004
+++ linux/arch/mips/Kconfig	Sun Apr  4 00:14:55 2004
@@ -117,6 +117,18 @@
 	depends on MACH_VR41XX
 	select IRQ_CPU
 
+config VRC4171
+	tristate "add NEC VRC4171 companion chip support"
+	depends on MACH_VR41XX && ISA
+	---help---
+	  The NEC VRC4171/4171A is a companion chip for NEC VR4111/VR4121.
+
+config VRC4173
+	tristate "add NEC VRC4173 companion chip support"
+	depends on MACH_VR41XX && PCI
+	---help---
+	  The NEC VRC4173 is a companion chip for NEC VR4122/VR4131.
+
 config TOSHIBA_JMR3927
 	bool "Support for Toshiba JMR-TX3927 board"
 	depends on MIPS32
@@ -810,14 +822,6 @@
 	bool
 	depends on ZAO_CAPCELLA || VICTOR_MPC30X || SIBYTE_SB1xxx_SOC || NEC_EAGLE || NEC_OSPREY || DDB5477 || CASIO_E55 || TANBAC_TB0226 || TANBAC_TB0229
 	default y
-
-config VRC4171
-	tristate "NEC VRC4171 Support"
-	depends on IBM_WORKPAD
-
-config VRC4173
-	tristate "NEC VRC4173 Support"
-	depends on NEC_EAGLE || VICTOR_MPC30X
 
 config DDB5XXX_COMMON
 	bool

From jsun@orion.mvista.com Wed Apr 21 18:20:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 18:20:20 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:52472 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225837AbUDURUT>;
	Wed, 21 Apr 2004 18:20:19 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i3LHKDx6032428;
	Wed, 21 Apr 2004 10:20:13 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i3LHKDCM032426;
	Wed, 21 Apr 2004 10:20:13 -0700
Date: Wed, 21 Apr 2004 10:20:13 -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: CVS Update@-mips.org: linux
Message-ID: <20040421102013.F32072@mvista.com>
References: <20040420163230Z8225288-1530+99@linux-mips.org> <20040420105116.C22846@mvista.com> <20040420201128.GC24025@linux-mips.org> <20040420153108.F22846@mvista.com> <Pine.LNX.4.55.0404211608570.28167@jurand.ds.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.LNX.4.55.0404211608570.28167@jurand.ds.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Apr 21, 2004 at 04:11:29PM +0200
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4835
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1189
Lines: 31

On Wed, Apr 21, 2004 at 04:11:29PM +0200, Maciej W. Rozycki wrote:
> On Tue, 20 Apr 2004, Jun Sun wrote:
> 
> > > drivers/pci can do that, you just need to supply a few board specific
> > > functions, see for example arch/alpha/kernel/pci.c.  So pci_auto.c isn't
> > > only b0rked, it also duplicates code.
> > 
> > Has anybody succssfully used pci_assign_unassigned_resources() in latest 2.4?
> > It was badly broken in early 2.4 kernels while pci_auto was the only 
> > option.
> 
>  In that case, fixing pci_assign_unassigned_resources() was the right way
> to go, instead of implementing a system-specific workaround.  

Using pci_auto() represented a different approach, which to many seems more
correct.  It does assignment first and then scanning.  It is supplied
as a replacement for broken firmware.

At one time a couple of pci_auto()'s existed in more than one arch.  And
there was a chance to make this approach the official one and completely 
eliminate pci_assign_unassigned_resources().

Having competing approaches co-existing in Linux is a norm.

> There are no
> excuses -- the source is available.
> 

Please don't always assume other people are more ignorant ....

Jun

From yuasa@hh.iij4u.or.jp Wed Apr 21 18:24:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 18:24:18 +0100 (BST)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:3522 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225837AbUDURYR>;
	Wed, 21 Apr 2004 18:24:17 +0100
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id CAA28061;
	Thu, 22 Apr 2004 02:24:13 +0900 (JST)
Received: 4UMDO00 id i3LHODq04662; Thu, 22 Apr 2004 02:24:13 +0900 (JST)
Received: 4UMRO00 id i3LHOCG12575; Thu, 22 Apr 2004 02:24:12 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Thu, 22 Apr 2004 02:24:09 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [patch][2.6] PCI fixup function for NEC Eagle
Message-Id: <20040422022409.56428e62.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4836
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 9687
Lines: 311

Hello Ralf,

This patch fixes the PCI fixup function for NEC Eagle.

Please apply to CVS.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/pci/Makefile linux/arch/mips/pci/Makefile
--- linux-orig/arch/mips/pci/Makefile	Thu Apr 15 00:06:22 2004
+++ linux/arch/mips/pci/Makefile	Thu Apr 22 00:34:12 2004
@@ -38,7 +38,7 @@
 obj-$(CONFIG_MOMENCO_OCELOT)	+= fixup-ocelot.o pci-ocelot.o
 obj-$(CONFIG_MOMENCO_OCELOT_C)	+= pci-ocelot-c.o
 obj-$(CONFIG_MOMENCO_OCELOT_G)	+= pci-ocelot-g.o
-obj-$(CONFIG_NEC_EAGLE)		+= fixup-eagle.o ops-vrc4173.o
+obj-$(CONFIG_NEC_EAGLE)		+= fixup-eagle.o
 obj-$(CONFIG_PMC_YOSEMITE)	+= fixup-yosemite.o ops-titan.o
 obj-$(CONFIG_SGI_IP27)		+= pci-ip27.o
 obj-$(CONFIG_SGI_IP32)		+= fixup-ip32.o ops-mace.o pci-ip32.o
diff -urN -X dontdiff linux-orig/arch/mips/pci/fixup-eagle.c linux/arch/mips/pci/fixup-eagle.c
--- linux-orig/arch/mips/pci/fixup-eagle.c	Fri Feb 20 00:49:46 2004
+++ linux/arch/mips/pci/fixup-eagle.c	Thu Apr 22 00:34:12 2004
@@ -1,15 +1,25 @@
 /*
- * arch/mips/vr41xx/nec-eagle/pci_fixup.c
+ *  fixup-eagle.c, The NEC Eagle/Hawk Board specific PCI fixups.
  *
- * The NEC Eagle/Hawk Board specific PCI fixups.
+ *  Copyright (C) 2001-2002,2004  MontaVista Software, Inc.
+ *    Author: Yoichi Yuasa <yyuasa@mvista.com, or source@mvista.com>
+ *  Copyright (C) 2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
- * Author: Yoichi Yuasa <you@mvista.com, or source@mvista.com>
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
  *
- * 2001-2002,2004 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
+#include <linux/config.h>
 #include <linux/init.h>
 #include <linux/pci.h>
 
@@ -29,13 +39,13 @@
 #define SLOT	PCISLOT_IRQ
 
 static char irq_tab_eagle[][5] __initdata = {
- [ 8] = { 0,    INTA, INTB, INTC, INTD },
- [ 9] = { 0,    INTD, INTA, INTB, INTC },
- [10] = { 0,    INTC, INTD, INTA, INTB },
- [12] = { 0, PCMCIA1,    0,    0,    0 },
- [13] = { 0, PCMCIA2,    0,    0,    0 },
- [28] = { 0,     LAN,    0,    0,    0 },
- [29] = { 0,    SLOT, INTB, INTC, INTD },
+ [ 8] = { -1,    INTA, INTB, INTC, INTD },
+ [ 9] = { -1,    INTD, INTA, INTB, INTC },
+ [10] = { -1,    INTC, INTD, INTA, INTB },
+ [12] = { -1, PCMCIA1,   -1,   -1,   -1 },
+ [13] = { -1, PCMCIA2,   -1,   -1,   -1 },
+ [28] = { -1,     LAN,  LAN,  LAN,  LAN },
+ [29] = { -1,    SLOT, INTB, INTC, INTD },
 };
 
 /*
@@ -58,3 +68,97 @@
 struct pci_fixup pcibios_fixups[] __initdata = {
 	{	.pass = 0,	},
 };
+
+#ifdef CONFIG_VRC4173
+/*
+ * PCI configuration registers
+ */
+#define PCICONFAREG	KSEG1ADDR(0x0f000c18)
+#define PCICONFDREG	KSEG1ADDR(0x0f000c14)
+
+static inline void pci_config_write_byte(u8 reg, u8 val)
+{
+	u32 data;
+	int shift;
+
+	writel((1UL << 0x1e) | (reg & 0xfc), PCICONFAREG);
+	data = readl(PCICONFDREG);
+
+	shift = (reg & 3) << 3;
+	data &= ~(0xff << shift);
+	data |= (((u32) val) << shift);
+
+	writel(data, PCICONFDREG);
+}
+
+static inline u16 pci_config_read_halfword(u8 reg)
+{
+	u32 data;
+
+	writel(((1UL << 30) | (reg & 0xfc)), PCICONFAREG);
+	data = readl(PCICONFDREG);
+
+	return (u16) (data >> ((reg & 2) << 3));
+}
+
+static inline u32 pci_config_read_word(u8 reg)
+{
+	writel(((1UL << 30) | (reg & 0xfc)), PCICONFAREG);
+
+	return readl(PCICONFDREG);
+}
+
+static inline void pci_config_write_word(u8 reg, u32 val)
+{
+	writel((1UL << 0x1e) | (reg & 0xfc), PCICONFAREG);
+	writel(val, PCICONFDREG);
+}
+
+/*
+ * Pre-fixup for AC97U/CARDU/USBU of VRC4173
+ */
+static int __init vrc4173_prefixup(void)
+{
+	u32 cmdsts, base;
+	u16 cmu_mask;
+
+
+	if ((pci_config_read_halfword(PCI_VENDOR_ID) == PCI_VENDOR_ID_NEC) &&
+	    (pci_config_read_halfword(PCI_DEVICE_ID) == PCI_DEVICE_ID_NEC_VRC4173)) {
+		/*
+		 * Initialized NEC VRC4173 Bus Control Unit
+		 */
+		cmdsts = pci_config_read_word(PCI_COMMAND);
+		pci_config_write_word(PCI_COMMAND,
+		                      cmdsts | PCI_COMMAND_IO |
+		                      PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
+
+		pci_config_write_byte(PCI_LATENCY_TIMER, 0x80);
+
+		pci_config_write_word(PCI_BASE_ADDRESS_0, VR41XX_PCI_IO_START);
+		base = pci_config_read_word(PCI_BASE_ADDRESS_0);
+		base &= PCI_BASE_ADDRESS_IO_MASK;
+		pci_config_write_byte(0x40, 0x01);
+
+		/* CARDU1 IDSEL = AD12, CARDU2 IDSEL = AD13 */
+		pci_config_write_byte(0x41, 0);
+
+		cmu_mask = 0x1000;
+		outw(cmu_mask, base + 0x040);
+		cmu_mask |= 0x0800;
+		outw(cmu_mask, base + 0x040);
+
+		outw(0x000f, base + 0x042);	/* Soft reset of CMU */
+		cmu_mask |= 0x05e0;
+		outw(cmu_mask, base + 0x040);
+		cmu_mask = inw(base + 0x040);	/* dummy read */
+		outw(0x0000, base + 0x042);
+
+		return 0;
+	}
+
+	return -ENODEV;
+}
+
+early_initcall(vrc4173_prefixup);
+#endif
diff -urN -X dontdiff linux-orig/arch/mips/pci/ops-vrc4173.c linux/arch/mips/pci/ops-vrc4173.c
--- linux-orig/arch/mips/pci/ops-vrc4173.c	Fri Jun 13 23:19:56 2003
+++ linux/arch/mips/pci/ops-vrc4173.c	Thu Jan  1 09:00:00 1970
@@ -1,120 +0,0 @@
-/*
- * FILE NAME
- *	arch/mips/vr41xx/nec-eagle/vrc4173.c
- *
- * BRIEF MODULE DESCRIPTION
- *	Pre-setup for NEC VRC4173.
- *
- * Author: Yoichi Yuasa
- *         yyuasa@mvista.com or source@mvista.com
- *
- * Copyright 2001,2002 MontaVista Software Inc.
- *
- *  This program is free software; you can redistribute it and/or modify it
- *  under the terms of the GNU General Public License as published by the
- *  Free Software Foundation; either version 2 of the License, or (at your
- *  option) any later version.
- *
- *  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
- *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
- *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
- *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
- *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- *  You should have received a copy of the GNU General Public License along
- *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  675 Mass Ave, Cambridge, MA 02139, USA.
- */
-#include <linux/init.h>
-#include <linux/pci.h>
-#include <linux/module.h>
-
-#include <asm/io.h>
-#include <asm/vr41xx/eagle.h>
-#include <asm/vr41xx/vrc4173.h>
-
-#define PCI_CONFIG_ADDR	KSEG1ADDR(0x0f000c18)
-#define PCI_CONFIG_DATA	KSEG1ADDR(0x0f000c14)
-
-static inline void config_writeb(u8 reg, u8 val)
-{
-	u32 data;
-	int shift;
-
-	writel((1UL << 0x1e) | (reg & 0xfc), PCI_CONFIG_ADDR);
-	data = readl(PCI_CONFIG_DATA);
-
-	shift = (reg & 3) << 3;
-	data &= ~(0xff << shift);
-	data |= (((u32) val) << shift);
-
-	writel(data, PCI_CONFIG_DATA);
-}
-
-static inline u16 config_readw(u8 reg)
-{
-	u32 data;
-
-	writel(((1UL << 30) | (reg & 0xfc)), PCI_CONFIG_ADDR);
-	data = readl(PCI_CONFIG_DATA);
-
-	return (u16) (data >> ((reg & 2) << 3));
-}
-
-static inline u32 config_readl(u8 reg)
-{
-	writel(((1UL << 30) | (reg & 0xfc)), PCI_CONFIG_ADDR);
-
-	return readl(PCI_CONFIG_DATA);
-}
-
-static inline void config_writel(u8 reg, u32 val)
-{
-	writel((1UL << 0x1e) | (reg & 0xfc), PCI_CONFIG_ADDR);
-	writel(val, PCI_CONFIG_DATA);
-}
-
-void __init vrc4173_preinit(void)
-{
-	u32 cmdsts, base;
-	u16 cmu_mask;
-
-
-	if ((config_readw(PCI_VENDOR_ID) == PCI_VENDOR_ID_NEC) &&
-	    (config_readw(PCI_DEVICE_ID) == PCI_DEVICE_ID_NEC_VRC4173)) {
-		/*
-		 * Initialized NEC VRC4173 Bus Control Unit
-		 */
-		cmdsts = config_readl(PCI_COMMAND);
-		config_writel(PCI_COMMAND,
-			      cmdsts |
-			      PCI_COMMAND_IO |
-			      PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
-
-		config_writeb(PCI_LATENCY_TIMER, 0x80);
-
-		config_writel(PCI_BASE_ADDRESS_0, VR41XX_PCI_IO_START);
-		base = config_readl(PCI_BASE_ADDRESS_0);
-		base &= PCI_BASE_ADDRESS_IO_MASK;
-		config_writeb(0x40, 0x01);
-
-		/* CARDU1 IDSEL = AD12, CARDU2 IDSEL = AD13 */
-		config_writeb(0x41, 0);
-
-		cmu_mask = 0x1000;
-		outw(cmu_mask, base + 0x040);
-		cmu_mask |= 0x0800;
-		outw(cmu_mask, base + 0x040);
-
-		outw(0x000f, base + 0x042);	/* Soft reset of CMU */
-		cmu_mask |= 0x05e0;
-		outw(cmu_mask, base + 0x040);
-		cmu_mask = inw(base + 0x040);	/* dummy read */
-		outw(0x0000, base + 0x042);
-	}
-}
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c	Thu Feb 26 07:05:00 2004
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Thu Apr 22 00:34:12 2004
@@ -86,8 +86,6 @@
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);
-
-	vrc4173_preinit();
 #endif
 
 	return 0;

From jsun@orion.mvista.com Wed Apr 21 18:26:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 18:26:43 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:36857 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225837AbUDUR0m>;
	Wed, 21 Apr 2004 18:26:42 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i3LHQdx6032445;
	Wed, 21 Apr 2004 10:26:39 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i3LHQdZG032443;
	Wed, 21 Apr 2004 10:26:39 -0700
Date: Wed, 21 Apr 2004 10:26:39 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [RFC] Separate time support for using cpu timer
Message-ID: <20040421102639.G32072@mvista.com>
References: <20040419180720.H14976@mvista.com> <Pine.LNX.4.55.0404201522220.28193@jurand.ds.pg.gda.pl> <20040420162500.H22846@mvista.com> <Pine.LNX.4.55.0404211445470.28167@jurand.ds.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.LNX.4.55.0404211445470.28167@jurand.ds.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Apr 21, 2004 at 03:19:45PM +0200
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4837
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1623
Lines: 37

On Wed, Apr 21, 2004 at 03:19:45PM +0200, Maciej W. Rozycki wrote:
> On Tue, 20 Apr 2004, Jun Sun wrote:
> 
> > >  It makes it separate again -- more maintenance burden and a bigger
> > > opportunity to have functional divergence, sigh...
> > 
> > Pretty much true for lots of improvement we made in the past a couple of
> > years .... :)
> 
>  Hmm, s/improvement/hacks/, perhaps?
> 
> > >  Additionally I don't think using the CP0 Count & Compare registers for
> > > the system timer is the way to go.  It's rather a way to escape when
> > > there's no other possibility.  A lot of systems have a reliable external
> > > timer interrupt source and using it actually would free the CP0 registers
> > > for other uses, like profiling or a programmable interval timer.
> > 
> > I was rather neutral on this point until I started to add HRT/VST support to 
> > MIPS.  When adding such features you really just want one common timer code.
> > And the best choice for MIPS is cpu timer.
> 
>  Well, with the _hpt_ abstraction layer you have one common timer code,
> regardless of the actual timer hardware used.  If there's some
> functionality you miss there, we may discuss about possible solutions.
> 

Current high resolution timer code calls for two logic timers, one for
the old jiffy timer and one for intra-jiffy timer interrupt.

Even if you can extend hpt interface to accomondate this, each board
would still end up implementing a lot of complex code.

With cpu timer, however, we can "multiplex" the same timer to 
emulate both logical timers.  All boards using cpu timer can have HRT without 
any code change.

Jun

From macro@ds2.pg.gda.pl Wed Apr 21 19:04:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 19:05:00 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:60303 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225837AbUDUSE6>; Wed, 21 Apr 2004 19:04:58 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 16B694AEA0; Wed, 21 Apr 2004 20:04:50 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id E4B1447A40; Wed, 21 Apr 2004 20:04:50 +0200 (CEST)
Date: Wed, 21 Apr 2004 20:04:50 +0200 (CEST)
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: CVS Update@-mips.org: linux
In-Reply-To: <20040421102013.F32072@mvista.com>
Message-ID: <Pine.LNX.4.55.0404211925270.28167@jurand.ds.pg.gda.pl>
References: <20040420163230Z8225288-1530+99@linux-mips.org>
 <20040420105116.C22846@mvista.com> <20040420201128.GC24025@linux-mips.org>
 <20040420153108.F22846@mvista.com> <Pine.LNX.4.55.0404211608570.28167@jurand.ds.pg.gda.pl>
 <20040421102013.F32072@mvista.com>
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: 4838
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 3140
Lines: 70

On Wed, 21 Apr 2004, Jun Sun wrote:

> >  In that case, fixing pci_assign_unassigned_resources() was the right way
> > to go, instead of implementing a system-specific workaround.  
> 
> Using pci_auto() represented a different approach, which to many seems more
> correct.  It does assignment first and then scanning.  It is supplied
> as a replacement for broken firmware.

 Well the Alpha port did resource management since its early days, due to
the complexity of Alpha setups (I'm pretty sure DEC was first to put
PCI-PCI bridges into their systems on a regular basis) and firmware
oddities (not necessarily due to brokenness but rather competing
assumptions, although there was an option to run MILO from the system
flash ROM and then the system wouldn't execute a lot of initialization
steps before passing control to Linux), like setting up I/O port
allocations above 0xffff, which would surprise some drivers.  That means
around 1995 or 1996.  So the code has been out there for a long time --
long enough to make any remaining problems resolved.

> At one time a couple of pci_auto()'s existed in more than one arch.  And
> there was a chance to make this approach the official one and completely 
> eliminate pci_assign_unassigned_resources().

 But if it didn't happen, then it means it was not the right approach.

> Having competing approaches co-existing in Linux is a norm.

 Well, it's normal for development series.  For stable series there's an
established way of doing stuff and port maintainers should migrate.  
Actually, there's a "feature freeze" point in the development series
(which you probably know) to let maintainers finish before a stable
release.  In reality it does not always happen as depending on various 
factors maintainers may have more or less resources available, but better 
or worse they work on eliminating obsolete cruft.

 I'm writing of in-tree development here -- people can do research on
alternatives off-tree, of course, including working and testing in stable
series.  If proved to be good, the results are typically merged in the
early days of development series.

> > There are no
> > excuses -- the source is available.
> 
> Please don't always assume other people are more ignorant ....

 This is insulting -- I never assume that.  One has to prove that to me
first.

 In cases like this, I've noticed the trend is to think: "Well, Linus[1]
is too tough to be convinced to accept arbitrary changes, so let's just
code our stuff independently and keep it with system-specific bits."  But 
as I wrote, code is available and you have two proper choices:

1. Fix what's wrong in the existing code.

2. Propose a superior alternative.

#1 may be easier and #2 may provide better results.  But it doesn't happen
-- I hardly ever hear any voice in discussions on the LKML from people
involved in developing for the MIPS platform.

[1] Substitute a subsystem maintainer as needed.

  Maciej

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

From B.Zolnierkiewicz@elka.pw.edu.pl Wed Apr 21 21:14:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Apr 2004 21:14:49 +0100 (BST)
Received: from mion.elka.pw.edu.pl ([IPv6:::ffff:194.29.160.35]:7298 "EHLO
	mion.elka.pw.edu.pl") by linux-mips.org with ESMTP
	id <S8225867AbUDUUOs>; Wed, 21 Apr 2004 21:14:48 +0100
Received: from chello062179061026.chello.pl ([62.179.61.26]:33964 "EHLO
	192.168.0.252") by mion.elka.pw.edu.pl with ESMTP id <S25947AbUDUUOe>;
	Wed, 21 Apr 2004 22:14:34 +0200
From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
To: linux-mips@linux-mips.org
Subject: [PATCH] it8172.c: ide_init_hwif_ports() -> ide_std_init_ports()
Date: Wed, 21 Apr 2004 22:13:43 +0200
User-Agent: KMail/1.5.3
Cc: linux-ide@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200404212213.43990.bzolnier@elka.pw.edu.pl>
X-Virus-Scanned: by AMaViS perl-11 mion
Return-Path: <B.Zolnierkiewicz@elka.pw.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4839
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: B.Zolnierkiewicz@elka.pw.edu.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 990
Lines: 29


Self-explanatory. :-)


[PATCH] it8172.c: ide_init_hwif_ports() -> ide_std_init_ports()

This driver can be compiled only on mips (depends on MIPS_ITE8172 || MIPS_IVR)
so replace ide_init_hwif_ports() with ide_std_init_ports().

 linux-2.6.6-rc1-bk5-bzolnier/drivers/ide/pci/it8172.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -puN drivers/ide/pci/it8172.c~it8172_std_init_ports drivers/ide/pci/it8172.c
--- linux-2.6.6-rc1-bk5/drivers/ide/pci/it8172.c~it8172_std_init_ports	2004-04-21 00:37:17.601970896 +0200
+++ linux-2.6.6-rc1-bk5-bzolnier/drivers/ide/pci/it8172.c	2004-04-21 00:37:17.605970288 +0200
@@ -263,8 +263,8 @@ static void __init init_hwif_it8172 (ide
 
 	cmdBase = dev->resource[0].start;
 	ctrlBase = dev->resource[1].start;
-    
-	ide_init_hwif_ports(&hwif->hw, cmdBase, ctrlBase | 2, NULL);
+
+	ide_std_init_ports(&hwif->hw, cmdBase, ctrlBase | 2);
 	memcpy(hwif->io_ports, hwif->hw.io_ports, sizeof(hwif->io_ports));
 	hwif->noprobe = 0;
 

_


From surej@mistralsoftware.com Thu Apr 22 10:50:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Apr 2004 10:50:28 +0100 (BST)
Received: from [IPv6:::ffff:203.196.146.243] ([IPv6:::ffff:203.196.146.243]:14198
	"EHLO Mistralsoftware.com") by linux-mips.org with ESMTP
	id <S8225248AbUDVJu1>; Thu, 22 Apr 2004 10:50:27 +0100
Received: from mistralsoftware.com ([192.168.13.239])
	(authenticated user surej@mistralsoftware.com)
	by mistralsoftware.com (mistralsoftware.com [192.168.10.12])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000113979.msg
	for <linux-mips@linux-mips.org>; Thu, 22 Apr 2004 15:20:07 +0530
Message-ID: <408796AD.4000208@mistralsoftware.com>
Date: Thu, 22 Apr 2004 15:25:57 +0530
From: Surej Anwar <surej@mistralsoftware.com>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040306)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: CF Ethernet support on mips
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: surej@mistralsoftware.com
X-Spam-Processed: mistralsoftware.com, Thu, 22 Apr 2004 15:20:07 +0530
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.13.239
X-Return-Path: surej@mistralsoftware.com
X-MDaemon-Deliver-To: linux-mips@linux-mips.org
X-MDAV-Processed: mistralsoftware.com, Thu, 22 Apr 2004 15:20:11 +0530
Return-Path: <surej@mistralsoftware.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4840
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: surej@mistralsoftware.com
Precedence: bulk
X-list: linux-mips
Content-Length: 218
Lines: 10

Hi,

    I need to use a CF Ethernet card on a VR4131 based system. Could 
anyone suggest one, which is well supported on linux 2.4.18 ? Also are 
there any drivers available for the same?

Thanks in advance,
Surej.



From yuasa@hh.iij4u.or.jp Thu Apr 22 15:00:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Apr 2004 15:00:15 +0100 (BST)
Received: from p508B5E7C.dip.t-dialin.net ([IPv6:::ffff:80.139.94.124]:28389
	"EHLO p508B5E7C.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225286AbUDVOAO>; Thu, 22 Apr 2004 15:00:14 +0100
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:28663 "EHLO
	mo02.iij4u.or.jp") by linux-mips.net with ESMTP id <S869009AbUDVNwX>;
	Thu, 22 Apr 2004 15:52:23 +0200
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id WAA21970;
	Thu, 22 Apr 2004 22:51:44 +0900 (JST)
Received: 4UMDO01 id i3MDpiR28649; Thu, 22 Apr 2004 22:51:44 +0900 (JST)
Received: 4UMRO00 id i3MDpgF04690; Thu, 22 Apr 2004 22:51:43 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Thu, 22 Apr 2004 22:51:42 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Surej Anwar <surej@mistralsoftware.com>
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: CF Ethernet support on mips
Message-Id: <20040422225142.07c93ed9.yuasa@hh.iij4u.or.jp>
In-Reply-To: <408796AD.4000208@mistralsoftware.com>
References: <408796AD.4000208@mistralsoftware.com>
X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4841
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 360
Lines: 14

On Thu, 22 Apr 2004 15:25:57 +0530
Surej Anwar <surej@mistralsoftware.com> wrote:

> Hi,
> 
>     I need to use a CF Ethernet card on a VR4131 based system. Could 
> anyone suggest one, which is well supported on linux 2.4.18 ? Also are 
> there any drivers available for the same?

Which PCMCIA controller do you use?
I think that it has no problem.

Yoichi


From agd5f@yahoo.com Thu Apr 22 18:49:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Apr 2004 18:49:20 +0100 (BST)
Received: from web11309.mail.yahoo.com ([IPv6:::ffff:216.136.129.26]:12164
	"HELO web11309.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225308AbUDVRtT>; Thu, 22 Apr 2004 18:49:19 +0100
Message-ID: <20040422174916.42579.qmail@web11309.mail.yahoo.com>
Received: from [66.93.100.212] by web11309.mail.yahoo.com via HTTP; Thu, 22 Apr 2004 10:49:16 PDT
Date: Thu, 22 Apr 2004 10:49:16 -0700 (PDT)
From: Alex Deucher <agd5f@yahoo.com>
Subject: few questions about linux on sgi machines
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <agd5f@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4842
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agd5f@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 547
Lines: 20

Is the PCI slot supported on the o2 (i.e., could I put a linux
supported pci card in and use it)?  Also is the o2 AV IO board
supported?  Is that encompassed by VICE or is that separate?

What about the PCI slots on o200?  Are they supported?

Also, out of curiosity, is there a list somewhere of all the asics in
the Octane?  e.g., sound chip(s), ethernet, parallel/serial, etc.

Thanks,

Alex


	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

From sskowron@ET.PUT.Poznan.PL Thu Apr 22 19:28:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Apr 2004 19:28:53 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:16776
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225463AbUDVS2u>; Thu, 22 Apr 2004 19:28:50 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3MISmN19091;
	Thu, 22 Apr 2004 20:28:48 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Thu, 22 Apr 2004 20:28:47 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3MISkQ27607;
	Thu, 22 Apr 2004 20:28:47 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Thu, 22 Apr 2004 20:28:46 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: Alex Deucher <agd5f@yahoo.com>
cc: linux-mips@linux-mips.org
Subject: Re: few questions about linux on sgi machines
In-Reply-To: <20040422174916.42579.qmail@web11309.mail.yahoo.com>
Message-ID: <Pine.GSO.4.10.10404222022560.27253-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4843
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 655
Lines: 28

> Also, out of curiosity, is there a list somewhere of all the asics in
> the Octane?  e.g., sound chip(s), ethernet, parallel/serial, etc.

Yes! (It depends what do you call an ASIC. I use it for a SGI-specific
chip with no docs at all.)

-- Base I/O --
HEART	memory controller, Xtalk bridge
IOC3	multi-I/O
RAD1	audio
BRIDGE	Xtalk-PCI bridge?
-- Frontplane --
XBOW	Xtalk router
-- PCI card cage (correct this) --
BRIDGE	Xtalk-PCI bridge
-- MardiGras (this is one big mystery) --
HQ4	Xtalk bridge
GE11	geometry engine
RE4	raster engine
PP1	?
VC3	video controller?
CMAP	colormap?

I'm writing this from memory, so correct me please.

Stanislaw Skowronek



From hch@lst.de Thu Apr 22 21:29:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Apr 2004 21:29:16 +0100 (BST)
Received: from verein.lst.de ([IPv6:::ffff:212.34.189.10]:56714 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8225528AbUDVU3Q>;
	Thu, 22 Apr 2004 21:29:16 +0100
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3MKT7Qc013283
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Thu, 22 Apr 2004 22:29:08 +0200
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i3MKT7MJ013281;
	Thu, 22 Apr 2004 22:29:07 +0200
Date: Thu, 22 Apr 2004 22:29:07 +0200
From: Christoph Hellwig <hch@lst.de>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: Alex Deucher <agd5f@yahoo.com>, linux-mips@linux-mips.org
Subject: Re: few questions about linux on sgi machines
Message-ID: <20040422202907.GA13266@lst.de>
References: <20040422174916.42579.qmail@web11309.mail.yahoo.com> <Pine.GSO.4.10.10404222022560.27253-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404222022560.27253-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.3.28i
X-Spam-Score: -4.901 () BAYES_00
X-Scanned-By: MIMEDefang 2.39
Return-Path: <hch@lst.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4844
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@lst.de
Precedence: bulk
X-list: linux-mips
Content-Length: 471
Lines: 17

On Thu, Apr 22, 2004 at 08:28:46PM +0200, Stanislaw Skowronek wrote:
> > Also, out of curiosity, is there a list somewhere of all the asics in
> > the Octane?  e.g., sound chip(s), ethernet, parallel/serial, etc.
> 
> Yes! (It depends what do you call an ASIC. I use it for a SGI-specific
> chip with no docs at all.)
> 
> -- Base I/O --
> BRIDGE	Xtalk-PCI bridge?

Yes.  The same as used in the IP27 btw.

> -- Frontplane --
> XBOW	Xtalk router

Also shared witg IP27.


From brad@laronde.org Fri Apr 23 04:22:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 04:22:48 +0100 (BST)
Received: from ispmxmta06-srv.alltel.net ([IPv6:::ffff:166.102.165.167]:43395
	"EHLO ispmxmta06-srv.alltel.net") by linux-mips.org with ESMTP
	id <S8224770AbUDWDWr>; Fri, 23 Apr 2004 04:22:47 +0100
Received: from lahoo.priv ([162.39.1.206]) by ispmxmta06-srv.alltel.net
          with ESMTP
          id <20040423032239.QXNV24676.ispmxmta06-srv.alltel.net@lahoo.priv>
          for <linux-mips@linux-mips.org>; Thu, 22 Apr 2004 22:22:39 -0500
Received: from prefect.priv ([10.1.1.141] helo=prefect)
	by lahoo.priv with smtp (Exim 3.36 #1 (Debian))
	id 1BGr1R-0005hF-00
	for <linux-mips@linux-mips.org>; Thu, 22 Apr 2004 23:06:37 -0400
Message-ID: <06d601c428e2$3ba1dcc0$8d01010a@prefect>
From: "Bradley D. LaRonde" <brad@laronde.org>
To: <linux-mips@linux-mips.org>
Subject: inconsistent operand constraints in 'asm' in unaligned.h:66 using gcc 3.4
Date: Thu, 22 Apr 2004 23:22:40 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Return-Path: <brad@laronde.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: 4845
X-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@laronde.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1166
Lines: 43

gcc 3.4 complians about:

include/asm/unaligned.h:66: error: inconsistent operand constraints in an
`asm'

from linux CVS 2.4 branch.  That's:

/*
 * Store doubleword ununaligned.
 */
static inline void __stq_u(unsigned long __val, unsigned long long * __addr)
{
        __asm__("usw\t%1, %0\n\t"
                "usw\t%D1, 4+%0"
                : "=m" (*__addr)
                : "r" (__val));
}

I was baffled by the "%D1" syntax until Thiemo Seufer pointed out that %D1
assembled to "one register higher than the register chosen for %1".
Ooooookay.  But gcc complains about a constraint problem.  Maybe "r" and
"%Dn" don't get along (long)?

Anyway... what about __val's type?  I would expect that to be "unsigned long
long" for -mabi=32.  Otherwise will "%D" get what the asm author expected?
If I do change it to "unsigned long long" then I get two of the constraint
errors.  Ooooookay.  Anyone got a constraint that means "consecutive
register pair"?

I finally decided to punt and write:

static inline void __stq_u(unsigned long long __val, unsigned long long *
__addr)
{
        *__addr = __val;
}

Is this OK?  Is there a better solution?


Regards,
Brad


From jhdew@torinet.co.kr Fri Apr 23 09:00:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 09:00:59 +0100 (BST)
Received: from [IPv6:::ffff:222.98.69.125] ([IPv6:::ffff:222.98.69.125]:31459
	"EHLO torinet.co.kr") by linux-mips.org with ESMTP
	id <S8225305AbUDWIA5> convert rfc822-to-8bit; Fri, 23 Apr 2004 09:00:57 +0100
Received: from jhdew ([222.98.69.113])
	by torinet.co.kr (8.12.8/8.12.8) with ESMTP id i3N8px5i009307
	for <linux-mips@linux-mips.org>; Fri, 23 Apr 2004 17:51:59 +0900
From: =?ks_c_5601-1987?B?wOXB+Mit?= <jhdew@torinet.co.kr>
To: <linux-mips@linux-mips.org>
Subject: Problem with 64-bit kernel in SB1250 processor board.
Date: Fri, 23 Apr 2004 17:01:09 +0900
Message-ID: <000601c42909$236b5e20$714562de@jhdew>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: 8BIT
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Return-Path: <jhdew@torinet.co.kr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4846
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jhdew@torinet.co.kr
Precedence: bulk
X-list: linux-mips
Content-Length: 564
Lines: 20

Hello,

I¡¯m testing SB1250 processor board with 64bits linux kernel.
I used last source(linux-2.4.21) from Broadcom sibyte site.

But, when I did ping flooding 2-3 times (back ground running) to any
host system from my board, it panics. (mainly page fault error)
With 32bit linux kernel, no panic. Any idea?
How stable SB1250 processor in 64-bit linux kernel?

I doubt paging management of SB1250 in 64-bit kernel.
Any idea?

From Jang
+++++++++++++++++++++++++++++++++++
www.torinet.co.kr
jhdew@torinet.co.kr
+82-31-708-7072
+++++++++++++++++++++++++++++++++++


From flo@rfc822.org Fri Apr 23 09:03:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 09:03:06 +0100 (BST)
Received: from noose.gt.owl.de ([IPv6:::ffff:62.52.19.4]:22283 "EHLO
	noose.gt.owl.de") by linux-mips.org with ESMTP id <S8225305AbUDWIDE>;
	Fri, 23 Apr 2004 09:03:04 +0100
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 9DF3C25DE5; Fri, 23 Apr 2004 10:02:58 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 0C56D25C2C9; Fri, 23 Apr 2004 10:02:48 +0200 (CEST)
Date: Fri, 23 Apr 2004 10:02:48 +0200
From: Florian Lohoff <flo@rfc822.org>
To: linux-mips@linux-mips.org
Subject: MC Parity Error
Message-ID: <20040423080247.GC5814@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="B4IIlcmfBL/1gGOG"
Content-Disposition: inline
Organization: rfc822 - pure communication
User-Agent: Mutt/1.5.4i
Return-Path: <flo@rfc822.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4847
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips
Content-Length: 985
Lines: 36


--B4IIlcmfBL/1gGOG
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,
success report for the MC Bus Error handler :)

Apr 19 23:17:32 resume kernel: MC Bus Error
Apr 19 23:17:32 resume kernel: CPU error 0x380<RD PAR > @ 0x0f4c6308
Apr 19 23:17:32 resume kernel: Instruction bus error, epc =3D=3D 2accf310, =
ra =3D=3D 2accf2c8

I guess i have bad memory. The interesting point is that the machine
continued to run for another 2 days. Shouldnt a memory error halt the
machine ?

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

--B4IIlcmfBL/1gGOG
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAiM2nUaz2rXW+gJcRAuEuAKCWKw8QZ7m1z/wNMOCcHuIaaXfN9gCg13k8
l4K8WfxDBfmNX1GCVVTf/2g=
=bXuP
-----END PGP SIGNATURE-----

--B4IIlcmfBL/1gGOG--

From macro@ds2.pg.gda.pl Fri Apr 23 14:07:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 14:07:54 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:43476 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225737AbUDWNHu>; Fri, 23 Apr 2004 14:07:50 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id B93BD4C002; Fri, 23 Apr 2004 15:07:43 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id A876C47855; Fri, 23 Apr 2004 15:07:43 +0200 (CEST)
Date: Fri, 23 Apr 2004 15:07:43 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Bradley D. LaRonde" <brad@laronde.org>,
	Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: inconsistent operand constraints in 'asm' in unaligned.h:66
 using gcc 3.4
In-Reply-To: <06d601c428e2$3ba1dcc0$8d01010a@prefect>
Message-ID: <Pine.LNX.4.55.0404231454120.14494@jurand.ds.pg.gda.pl>
References: <06d601c428e2$3ba1dcc0$8d01010a@prefect>
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: 4848
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1783
Lines: 71

On Thu, 22 Apr 2004, Bradley D. LaRonde wrote:

> gcc 3.4 complians about:
> 
> include/asm/unaligned.h:66: error: inconsistent operand constraints in an
> `asm'
> 
> from linux CVS 2.4 branch.  That's:
> 
> /*
>  * Store doubleword ununaligned.
>  */
> static inline void __stq_u(unsigned long __val, unsigned long long * __addr)
> {
>         __asm__("usw\t%1, %0\n\t"
>                 "usw\t%D1, 4+%0"
>                 : "=m" (*__addr)
>                 : "r" (__val));
> }

 As usually recent gcc is invaluable in finding dubious constructs. ;-)

> I finally decided to punt and write:
> 
> static inline void __stq_u(unsigned long long __val, unsigned long long *
> __addr)
> {
>         *__addr = __val;
> }
> 
> Is this OK?  Is there a better solution?

 No.  Yes.

 Reviving old tricks about unaligned data I've come with the following
implementation:

void __stq_u(unsigned long long __val, unsigned long long *__addr)
{
	typedef struct {
		unsigned long long v __attribute__((packed));
	} ull_u_t;
	ull_u_t *a = (ull_u_t *)__addr;

        a->v = __val;
}

which yields a nice and desirable code:

unaligned.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <__stq_u>:
   0:	a8c40003 	swl	a0,3(a2)
   4:	b8c40000 	swr	a0,0(a2)
   8:	a8c50007 	swl	a1,7(a2)
   c:	03e00008 	jr	ra
  10:	b8c50004 	swr	a1,4(a2)
	...

I'm pretty sure it works fine with gcc 2.95.x as well -- for Alpha it used
to, even with such antiques as egcs 1.1.2.

 Ralf, I can see 2.6 already does the right thing -- I suppose you won't
mind me backporting (copying?) 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 Fri Apr 23 14:11:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 14:11:26 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:16341 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225739AbUDWNLZ>; Fri, 23 Apr 2004 14:11:25 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 97EF14C064; Fri, 23 Apr 2004 15:11:19 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 8C30C4C055; Fri, 23 Apr 2004 15:11:19 +0200 (CEST)
Date: Fri, 23 Apr 2004 15:11:19 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Florian Lohoff <flo@rfc822.org>
Cc: linux-mips@linux-mips.org
Subject: Re: MC Parity Error
In-Reply-To: <20040423080247.GC5814@paradigm.rfc822.org>
Message-ID: <Pine.LNX.4.55.0404231509190.14494@jurand.ds.pg.gda.pl>
References: <20040423080247.GC5814@paradigm.rfc822.org>
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: 4849
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 743
Lines: 19

On Fri, 23 Apr 2004, Florian Lohoff wrote:

> success report for the MC Bus Error handler :)
> 
> Apr 19 23:17:32 resume kernel: MC Bus Error
> Apr 19 23:17:32 resume kernel: CPU error 0x380<RD PAR > @ 0x0f4c6308
> Apr 19 23:17:32 resume kernel: Instruction bus error, epc == 2accf310, ra == 2accf2c8
> 
> I guess i have bad memory. The interesting point is that the machine
> continued to run for another 2 days. Shouldnt a memory error halt the
> machine ?

 As it happened in the user mode, I'd expect only the victim process to be
killed.

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

From ralf@linux-mips.org Fri Apr 23 14:15:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 14:15:33 +0100 (BST)
Received: from p508B6C3A.dip.t-dialin.net ([IPv6:::ffff:80.139.108.58]:63052
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225737AbUDWNPc>; Fri, 23 Apr 2004 14:15:32 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3NDF6xT016654;
	Fri, 23 Apr 2004 15:15:06 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3NDEjKJ016651;
	Fri, 23 Apr 2004 15:14:45 +0200
Date: Fri, 23 Apr 2004 15:14:45 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: "Bradley D. LaRonde" <brad@laronde.org>, linux-mips@linux-mips.org
Subject: Re: inconsistent operand constraints in 'asm' in unaligned.h:66 using gcc 3.4
Message-ID: <20040423131445.GA16274@linux-mips.org>
References: <06d601c428e2$3ba1dcc0$8d01010a@prefect> <Pine.LNX.4.55.0404231454120.14494@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0404231454120.14494@jurand.ds.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: 4850
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 495
Lines: 13

On Fri, Apr 23, 2004 at 03:07:43PM +0200, Maciej W. Rozycki wrote:

> I'm pretty sure it works fine with gcc 2.95.x as well -- for Alpha it used
> to, even with such antiques as egcs 1.1.2.
> 
>  Ralf, I can see 2.6 already does the right thing -- I suppose you won't
> mind me backporting (copying?) it?

I certainly won't.  I think the 2.4 implementation was originally written
necessary upto egcs 1.0 which were generating correct but very inefficient
code for __attribute((packed)).

  Ralf

From hch@lst.de Fri Apr 23 14:17:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 14:17:09 +0100 (BST)
Received: from verein.lst.de ([IPv6:::ffff:212.34.189.10]:2721 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8225737AbUDWNRI>;
	Fri, 23 Apr 2004 14:17:08 +0100
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3NDH6Qc027459
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 23 Apr 2004 15:17:06 +0200
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i3NDH697027457;
	Fri, 23 Apr 2004 15:17:06 +0200
Date: Fri, 23 Apr 2004 15:17:06 +0200
From: Christoph Hellwig <hch@lst.de>
To: Alex Deucher <agd5f@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: few questions about linux on sgi machines
Message-ID: <20040423131706.GA27375@lst.de>
References: <20040422174916.42579.qmail@web11309.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040422174916.42579.qmail@web11309.mail.yahoo.com>
User-Agent: Mutt/1.3.28i
X-Spam-Score: -4.901 () BAYES_00
X-Scanned-By: MIMEDefang 2.39
Return-Path: <hch@lst.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4851
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@lst.de
Precedence: bulk
X-list: linux-mips
Content-Length: 700
Lines: 13

On Thu, Apr 22, 2004 at 10:49:16AM -0700, Alex Deucher wrote:
> What about the PCI slots on o200?  Are they supported?

There's is PCI support but there's some problems, mosty because the
Linux support code isn't as nice as it should and we support only
glogic fibre channels and scsi cards and the SGI ioc3 currently.

Fixing that is in-progress but even then you could have problems with
most standard linux drivers because the pci hardware on all systems
using the bridge ASIC and it's sucessors (xbridge, pic) violate some
ordering contraints in the PCI spec.  The SGI folks doing the SN1/SN2
IA64 port have come up with workaround for xbride and pic but I'm not
sure they're applicable to IP27.

From agd5f@yahoo.com Fri Apr 23 14:29:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 14:29:13 +0100 (BST)
Received: from web11301.mail.yahoo.com ([IPv6:::ffff:216.136.131.204]:1678
	"HELO web11301.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225737AbUDWN3L>; Fri, 23 Apr 2004 14:29:11 +0100
Message-ID: <20040423132901.97621.qmail@web11301.mail.yahoo.com>
Received: from [66.93.100.212] by web11301.mail.yahoo.com via HTTP; Fri, 23 Apr 2004 06:29:01 PDT
Date: Fri, 23 Apr 2004 06:29:01 -0700 (PDT)
From: Alex Deucher <agd5f@yahoo.com>
Subject: Re: few questions about linux on sgi machines
To: Christoph Hellwig <hch@lst.de>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040423131706.GA27375@lst.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <agd5f@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4852
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agd5f@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1030
Lines: 31


--- Christoph Hellwig <hch@lst.de> wrote:
> On Thu, Apr 22, 2004 at 10:49:16AM -0700, Alex Deucher wrote:
> > What about the PCI slots on o200?  Are they supported?
> 
> There's is PCI support but there's some problems, mosty because the
> Linux support code isn't as nice as it should and we support only
> glogic fibre channels and scsi cards and the SGI ioc3 currently.
> 
> Fixing that is in-progress but even then you could have problems with
> most standard linux drivers because the pci hardware on all systems
> using the bridge ASIC and it's sucessors (xbridge, pic) violate some
> ordering contraints in the PCI spec.  The SGI folks doing the SN1/SN2
> IA64 port have come up with workaround for xbride and pic but I'm not
> sure they're applicable to IP27.

I assume IP30 has the same problems since they are similarly
architected?  What about IP32?

Thanks,

Alex



	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

From hch@lst.de Fri Apr 23 14:31:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 14:31:08 +0100 (BST)
Received: from verein.lst.de ([IPv6:::ffff:212.34.189.10]:19873 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8225737AbUDWNbH>;
	Fri, 23 Apr 2004 14:31:07 +0100
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3NDV6Qc027727
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 23 Apr 2004 15:31:06 +0200
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i3NDV6Lb027725;
	Fri, 23 Apr 2004 15:31:06 +0200
Date: Fri, 23 Apr 2004 15:31:06 +0200
From: Christoph Hellwig <hch@lst.de>
To: Alex Deucher <agd5f@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: few questions about linux on sgi machines
Message-ID: <20040423133106.GA27699@lst.de>
References: <20040423131706.GA27375@lst.de> <20040423132901.97621.qmail@web11301.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040423132901.97621.qmail@web11301.mail.yahoo.com>
User-Agent: Mutt/1.3.28i
X-Spam-Score: -4.901 () BAYES_00
X-Scanned-By: MIMEDefang 2.39
Return-Path: <hch@lst.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4853
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@lst.de
Precedence: bulk
X-list: linux-mips
Content-Length: 298
Lines: 10

On Fri, Apr 23, 2004 at 06:29:01AM -0700, Alex Deucher wrote:
> I assume IP30 has the same problems since they are similarly
> architected?

I guess it has the same problems as it's using the bridge ASIC, too.

> What about IP32?

It uses a completely different pci subsystem that should be okay.


From agd5f@yahoo.com Fri Apr 23 14:51:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 14:51:01 +0100 (BST)
Received: from web11302.mail.yahoo.com ([IPv6:::ffff:216.136.131.205]:14898
	"HELO web11302.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225753AbUDWNvA>; Fri, 23 Apr 2004 14:51:00 +0100
Message-ID: <20040423135056.68405.qmail@web11302.mail.yahoo.com>
Received: from [66.93.100.212] by web11302.mail.yahoo.com via HTTP; Fri, 23 Apr 2004 06:50:56 PDT
Date: Fri, 23 Apr 2004 06:50:56 -0700 (PDT)
From: Alex Deucher <agd5f@yahoo.com>
Subject: Re: few questions about linux on sgi machines
To: Ladislav Michl <ladis@linux-mips.org>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040422204013.GA2506@kopretinka>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <agd5f@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4854
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agd5f@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1106
Lines: 36


--- Ladislav Michl <ladis@linux-mips.org> wrote:
> On Thu, Apr 22, 2004 at 10:49:16AM -0700, Alex Deucher wrote:
> > Is the PCI slot supported on the o2 (i.e., could I put a linux
> > supported pci card in and use it)?  Also is the o2 AV IO board
> > supported?  Is that encompassed by VICE or is that separate?
> 
> PCI is supported with some limitations. MMIO doesn't work for certain
> endianess combinations, but PIO should be okay.
> 
> O2's AV IO is part of VICE. Vivien Chappelier wrote original ALSA
> driver
> and I did some work on it later, but stopped due to some buzz world
> stuff (am I shy to show unfinished code ;-)). You may find Vivien's
> patches here: http://www.linux-mips.org/~glaurung/
> Video input is currently unsupported (no video4linux driver)

Are there databooks floating around for the AV stuff or does it have to
be reverse engineered?  Does it use standard chips or is it custom sgi
stuff?

Thanks,

Alex

> 
> 	ladis



	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

From Tim.Stephens@motorola.com Fri Apr 23 17:04:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 17:04:45 +0100 (BST)
Received: from ftpbox.mot.com ([IPv6:::ffff:129.188.136.101]:43947 "EHLO
	ftpbox.mot.com") by linux-mips.org with ESMTP id <S8225794AbUDWQEo>;
	Fri, 23 Apr 2004 17:04:44 +0100
Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i3NG4gXU028857
	for <linux-mips@linux-mips.org>; Fri, 23 Apr 2004 09:04:42 -0700 (MST)
Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121])
	by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i3NG4BXP019479
	for <linux-mips@linux-mips.org>; Fri, 23 Apr 2004 11:04:41 -0500
Received: by ca25exm01 with Internet Mail Service (5.5.2657.2)
	id <F55XWC98>; Fri, 23 Apr 2004 09:04:10 -0700
Message-ID: <D5A7E45D575DD61180130002A5DB377C04E48C99@ca25exm01>
From: Stephens Tim-MGI1634 <Tim.Stephens@motorola.com>
To: linux-mips@linux-mips.org
Subject: Why does serial.c not allow you to share the serial console port 
	 interrupt?
Date: Fri, 23 Apr 2004 09:04:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: text/plain
Return-Path: <Tim.Stephens@motorola.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4855
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Tim.Stephens@motorola.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1012
Lines: 25

Hello,

I'm trying to understand why the serial.c driver does not allow the sharing of the serial console interrupt.  There are several places on the net the mention you cannot share the console interrupt, however there is no explaination why.  I assume it has something to do with OOPS reporting.  Please advise.

I'm trying to enable the second serial port on a MIPS based embedded system.  Both serial ports (16550 type) are attached to the same MIPS interrupt.  The console is attached to ttyS0, which shares the MIPS interrupt with ttyS1.

The code in question is:

#ifdef CONFIG_SERIAL_CONSOLE
    /*
     *    The interrupt of the serial console port
     *    can't be shared.
     */
    if (sercons.flags & CON_CONSDEV) {
        for(i = 0; i < NR_PORTS; i++)
            if (i != sercons.index &&
                rs_table[i].irq == rs_table[sercons.index].irq)
                rs_table[i].irq = 0;
    }
#endif

If I change the #ifdef to #if 0 both the console and ttyS1 seem to work ok.

Thanks,
Tim

From ralf@linux-mips.org Fri Apr 23 17:46:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 17:46:01 +0100 (BST)
Received: from p508B6C3A.dip.t-dialin.net ([IPv6:::ffff:80.139.108.58]:1359
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225794AbUDWQp7>; Fri, 23 Apr 2004 17:45:59 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3NGjcxT016564;
	Fri, 23 Apr 2004 18:45:38 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3NGjHmc016563;
	Fri, 23 Apr 2004 18:45:17 +0200
Date: Fri, 23 Apr 2004 18:45:17 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Florian Lohoff <flo@rfc822.org>, linux-mips@linux-mips.org
Subject: Re: MC Parity Error
Message-ID: <20040423164517.GA16401@linux-mips.org>
References: <20040423080247.GC5814@paradigm.rfc822.org> <Pine.LNX.4.55.0404231509190.14494@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0404231509190.14494@jurand.ds.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: 4856
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 840
Lines: 21

On Fri, Apr 23, 2004 at 03:11:19PM +0200, Maciej W. Rozycki wrote:

> > success report for the MC Bus Error handler :)
> > 
> > Apr 19 23:17:32 resume kernel: MC Bus Error
> > Apr 19 23:17:32 resume kernel: CPU error 0x380<RD PAR > @ 0x0f4c6308
> > Apr 19 23:17:32 resume kernel: Instruction bus error, epc == 2accf310, ra == 2accf2c8
> > 
> > I guess i have bad memory. The interesting point is that the machine
> > continued to run for another 2 days. Shouldnt a memory error halt the
> > machine ?
> 
>  As it happened in the user mode, I'd expect only the victim process to be
> killed.

The KSU bits are meaningless.  On Indy like most other MIPS systems a
bus error exception may be delayed.  So the generic solution requires
tracking down the actual user, something which in the current kernel is
relativly easy due to rmap.

  Ralf

From macro@ds2.pg.gda.pl Fri Apr 23 18:11:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 18:11:45 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:49798 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225805AbUDWRLo>; Fri, 23 Apr 2004 18:11:44 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 9F03C4AEA0; Fri, 23 Apr 2004 19:11:36 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 8B39B47C6D; Fri, 23 Apr 2004 19:11:36 +0200 (CEST)
Date: Fri, 23 Apr 2004 19:11:36 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Florian Lohoff <flo@rfc822.org>, linux-mips@linux-mips.org
Subject: Re: MC Parity Error
In-Reply-To: <20040423164517.GA16401@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0404231849480.14494@jurand.ds.pg.gda.pl>
References: <20040423080247.GC5814@paradigm.rfc822.org>
 <Pine.LNX.4.55.0404231509190.14494@jurand.ds.pg.gda.pl>
 <20040423164517.GA16401@linux-mips.org>
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: 4857
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1703
Lines: 37

On Fri, 23 Apr 2004, Ralf Baechle wrote:

> > > success report for the MC Bus Error handler :)
> > > 
> > > Apr 19 23:17:32 resume kernel: MC Bus Error
> > > Apr 19 23:17:32 resume kernel: CPU error 0x380<RD PAR > @ 0x0f4c6308
> > > Apr 19 23:17:32 resume kernel: Instruction bus error, epc == 2accf310, ra == 2accf2c8
> > > 
> > > I guess i have bad memory. The interesting point is that the machine
> > > continued to run for another 2 days. Shouldnt a memory error halt the
> > > machine ?
> > 
> >  As it happened in the user mode, I'd expect only the victim process to be
> > killed.
> 
> The KSU bits are meaningless.  On Indy like most other MIPS systems a
> bus error exception may be delayed.  So the generic solution requires

 I beg your pardon?  AFAIK, bus errors are documented to be reported
precisely and my past experience with the systems I use confirms this.  
Otherwise bits in <asm/paccess.h> wouldn't work, but they do.  Of course
this is true for errors happening on read transactions (I have troubles
imagining a delayed read), but the semantics of the exception is defined
only for reads anyway.  For other transactions a general-purpose interrupt
should be used (and normally is).  Such an interrupt can happen any time,
indeed (but here it was an IBE, not an interrupt).

> tracking down the actual user, something which in the current kernel is
> relativly easy due to rmap.

 Well, that may be tough anyway -- imagine an uncorrectable memory error 
on a DMA transaction. ;-)

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

From santosh_khare2002@yahoo.com Fri Apr 23 19:44:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 19:44:46 +0100 (BST)
Received: from web10707.mail.yahoo.com ([IPv6:::ffff:216.136.130.215]:1340
	"HELO web10707.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225842AbUDWSop>; Fri, 23 Apr 2004 19:44:45 +0100
Message-ID: <20040423184441.36215.qmail@web10707.mail.yahoo.com>
Received: from [207.46.238.143] by web10707.mail.yahoo.com via HTTP; Fri, 23 Apr 2004 11:44:41 PDT
Date: Fri, 23 Apr 2004 11:44:41 -0700 (PDT)
From: santosh khare <santosh_khare2002@yahoo.com>
Subject: relocation overflow of type 4 __copy_user
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1118446702-1082745881=:36150"
Return-Path: <santosh_khare2002@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4858
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: santosh_khare2002@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1888
Lines: 57

--0-1118446702-1082745881=:36150
Content-Type: text/plain; charset=us-ascii

Hi
When I am trying to insmod iptables.o I am getting this error multiple times.
 
relocation overflow of type 4 __copy_user
relocation overflow of type 4 __copy_user
relocation overflow of type 4 __copy_user
.........
 
I was getting similar errors for printk etc but they disappeared after I changed the CFLAGS  for arch/mips/Makefile and included -mno-abicalls.
 
Please let me know how can I get rid of this relocation overflow.
 
Looking at /proc/ksyms I see following.
 
#cat /proc/ksyms | grep __copy_user
802e0144 __copy_user
 
Santosh
 



		
---------------------------------
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
--0-1118446702-1082745881=:36150
Content-Type: text/html; charset=us-ascii

<DIV>Hi</DIV>
<DIV>When I am trying to insmod iptables.o I am getting this error multiple times.</DIV>
<DIV>&nbsp;</DIV>
<DIV>relocation overflow of type 4 __copy_user</DIV>
<DIV>
<DIV>relocation overflow of type 4 __copy_user</DIV>
<DIV>
<DIV>relocation overflow of type 4 __copy_user</DIV>
<DIV>.........</DIV>
<DIV>&nbsp;</DIV>
<DIV>I was getting similar errors for printk etc but they disappeared after I changed the CFLAGS&nbsp; for arch/mips/Makefile and included -mno-abicalls.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Please let me know how can I get rid of this relocation overflow.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Looking at /proc/ksyms I see following.</DIV>
<DIV>&nbsp;</DIV>
<DIV>#cat /proc/ksyms | grep __copy_user</DIV>
<DIV>802e0144 __copy_user</DIV>
<DIV>&nbsp;</DIV>
<DIV>Santosh</DIV>
<DIV>&nbsp;</DIV></DIV></DIV><p>
		<hr size=1><font face=arial size=-1>Do you Yahoo!?<br>
Yahoo! Photos: <a href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=23765/*http://photos.yahoo.c
om/ph/print_splash">High-quality 4x6 digital prints for 25¢</a>
--0-1118446702-1082745881=:36150--

From santosh_khare2002@yahoo.com Fri Apr 23 19:45:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 19:45:08 +0100 (BST)
Received: from web10707.mail.yahoo.com ([IPv6:::ffff:216.136.130.215]:5436
	"HELO web10707.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225848AbUDWSoy>; Fri, 23 Apr 2004 19:44:54 +0100
Message-ID: <20040423184452.36232.qmail@web10707.mail.yahoo.com>
Received: from [207.46.238.143] by web10707.mail.yahoo.com via HTTP; Fri, 23 Apr 2004 11:44:52 PDT
Date: Fri, 23 Apr 2004 11:44:52 -0700 (PDT)
From: santosh khare <santosh_khare2002@yahoo.com>
Subject: relocation overflow of type 4 __copy_user
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1640851125-1082745892=:31844"
Return-Path: <santosh_khare2002@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4859
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: santosh_khare2002@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1888
Lines: 57

--0-1640851125-1082745892=:31844
Content-Type: text/plain; charset=us-ascii

Hi
When I am trying to insmod iptables.o I am getting this error multiple times.
 
relocation overflow of type 4 __copy_user
relocation overflow of type 4 __copy_user
relocation overflow of type 4 __copy_user
.........
 
I was getting similar errors for printk etc but they disappeared after I changed the CFLAGS  for arch/mips/Makefile and included -mno-abicalls.
 
Please let me know how can I get rid of this relocation overflow.
 
Looking at /proc/ksyms I see following.
 
#cat /proc/ksyms | grep __copy_user
802e0144 __copy_user
 
Santosh
 



		
---------------------------------
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
--0-1640851125-1082745892=:31844
Content-Type: text/html; charset=us-ascii

<DIV>Hi</DIV>
<DIV>When I am trying to insmod iptables.o I am getting this error multiple times.</DIV>
<DIV>&nbsp;</DIV>
<DIV>relocation overflow of type 4 __copy_user</DIV>
<DIV>
<DIV>relocation overflow of type 4 __copy_user</DIV>
<DIV>
<DIV>relocation overflow of type 4 __copy_user</DIV>
<DIV>.........</DIV>
<DIV>&nbsp;</DIV>
<DIV>I was getting similar errors for printk etc but they disappeared after I changed the CFLAGS&nbsp; for arch/mips/Makefile and included -mno-abicalls.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Please let me know how can I get rid of this relocation overflow.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Looking at /proc/ksyms I see following.</DIV>
<DIV>&nbsp;</DIV>
<DIV>#cat /proc/ksyms | grep __copy_user</DIV>
<DIV>802e0144 __copy_user</DIV>
<DIV>&nbsp;</DIV>
<DIV>Santosh</DIV>
<DIV>&nbsp;</DIV></DIV></DIV><p>
		<hr size=1><font face=arial size=-1>Do you Yahoo!?<br>
Yahoo! Photos: <a href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=23765/*http://photos.yahoo.c
om/ph/print_splash">High-quality 4x6 digital prints for 25¢</a>
--0-1640851125-1082745892=:31844--

From sjhill@realitydiluted.com Fri Apr 23 19:52:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 19:52:51 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:54947 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225848AbUDWSwv>; Fri, 23 Apr 2004 19:52:51 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1BH5mJ-0006Ul-00; Fri, 23 Apr 2004 13:52:00 -0500
Message-ID: <408965D2.7010703@realitydiluted.com>
Date: Fri, 23 Apr 2004 14:52:02 -0400
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5
X-Accept-Language: en
MIME-Version: 1.0
To: santosh khare <santosh_khare2002@yahoo.com>
CC: linux-mips@linux-mips.org
Subject: Re: relocation overflow of type 4 __copy_user
References: <20040423184441.36215.qmail@web10707.mail.yahoo.com>
In-Reply-To: <20040423184441.36215.qmail@web10707.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4860
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 520
Lines: 17

santosh khare wrote:
>
> When I am trying to insmod iptables.o I am getting this error multiple 
> times.
>  
> relocation overflow of type 4 __copy_user
> relocation overflow of type 4 __copy_user
> relocation overflow of type 4 __copy_user
> .........
>  
> I was getting similar errors for printk etc but they disappeared after I 
> changed the CFLAGS  for arch/mips/Makefile and included -mno-abicalls.
>
This flag is already included by default in both 2.4 and 2.6 kernels. How
did you compile your module?

-Steve

From dom@mips.com Fri Apr 23 21:44:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 21:44:26 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:2060 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225927AbUDWUoZ>;
	Fri, 23 Apr 2004 21:44:25 +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 1BH7lp-0002eN-00; Fri, 23 Apr 2004 21:59:37 +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 1BH7WV-0006th-00; Fri, 23 Apr 2004 21:43:48 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16521.32766.143451.421173@doms-laptop.algor.co.uk>
Date: Fri, 23 Apr 2004 13:43:42 -0700
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Florian Lohoff <flo@rfc822.org>, linux-mips@linux-mips.org
Subject: Re: MC Parity Error
In-Reply-To: <Pine.LNX.4.55.0404231849480.14494@jurand.ds.pg.gda.pl>
References: <20040423080247.GC5814@paradigm.rfc822.org>
	<Pine.LNX.4.55.0404231509190.14494@jurand.ds.pg.gda.pl>
	<20040423164517.GA16401@linux-mips.org>
	<Pine.LNX.4.55.0404231849480.14494@jurand.ds.pg.gda.pl>
X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.844, required 4, AWL,
	BAYES_00)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4861
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 615
Lines: 20


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

> > The KSU bits are meaningless.  On Indy like most other MIPS systems a
> > bus error exception may be delayed.  So the generic solution requires
> 
>  I beg your pardon?  AFAIK, bus errors are documented to be reported
> precisely...

You're both right :-) Data errors like this on an R4x00 are reported
as cache parity errors, and cache parity error exceptions are precise.
There's also a signalling mechanism typically used for an invalid
memory address, which generates a "bus error" exception, which is not
precise.

--
Dominic Sweetman
MIPS Technologies.



From macro@ds2.pg.gda.pl Fri Apr 23 22:06:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 22:06:34 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:17350 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225934AbUDWVGb>; Fri, 23 Apr 2004 22:06:31 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 98FE647C6D; Fri, 23 Apr 2004 23:06:24 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 852EC47855; Fri, 23 Apr 2004 23:06:24 +0200 (CEST)
Date: Fri, 23 Apr 2004 23:06:24 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dominic Sweetman <dom@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Florian Lohoff <flo@rfc822.org>, linux-mips@linux-mips.org
Subject: Re: MC Parity Error
In-Reply-To: <16521.32766.143451.421173@doms-laptop.algor.co.uk>
Message-ID: <Pine.LNX.4.55.0404232252080.14494@jurand.ds.pg.gda.pl>
References: <20040423080247.GC5814@paradigm.rfc822.org>
 <Pine.LNX.4.55.0404231509190.14494@jurand.ds.pg.gda.pl>
 <20040423164517.GA16401@linux-mips.org> <Pine.LNX.4.55.0404231849480.14494@jurand.ds.pg.gda.pl>
 <16521.32766.143451.421173@doms-laptop.algor.co.uk>
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: 4862
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 884
Lines: 21

On Fri, 23 Apr 2004, Dominic Sweetman wrote:

> > > The KSU bits are meaningless.  On Indy like most other MIPS systems a
> > > bus error exception may be delayed.  So the generic solution requires
> > 
> >  I beg your pardon?  AFAIK, bus errors are documented to be reported
> > precisely...
> 
> You're both right :-) Data errors like this on an R4x00 are reported
> as cache parity errors, and cache parity error exceptions are precise.
> There's also a signalling mechanism typically used for an invalid
> memory address, which generates a "bus error" exception, which is not
> precise.

 I refer to the situation, when SysCmd(5) is set in a response to a
processor read request.

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

From santosh_khare2002@yahoo.com Fri Apr 23 22:29:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Apr 2004 22:29:50 +0100 (BST)
Received: from web10702.mail.yahoo.com ([IPv6:::ffff:216.136.130.210]:64701
	"HELO web10702.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225934AbUDWV3t>; Fri, 23 Apr 2004 22:29:49 +0100
Message-ID: <20040423212946.48261.qmail@web10702.mail.yahoo.com>
Received: from [207.46.238.133] by web10702.mail.yahoo.com via HTTP; Fri, 23 Apr 2004 14:29:46 PDT
Date: Fri, 23 Apr 2004 14:29:46 -0700 (PDT)
From: santosh khare <santosh_khare2002@yahoo.com>
Subject: Re: relocation overflow of type 4 __copy_user
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1446260502-1082755786=:47980"
Return-Path: <santosh_khare2002@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4863
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: santosh_khare2002@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3538
Lines: 84

--0-1446260502-1082755786=:47980
Content-Type: text/plain; charset=us-ascii



I have changed 
CONFIG_IP_TABLES=y to 
CONFIG_IP_TABLES=m
 in .config file.
make modules now building ip_tables.o and I do not have this error any more.
Although, executing iptables utility is giving following error.
 
ip_tables: applet not found
can't initialize iptables table 'filter': table does not exist
perhaps iptables or your kernel needs to be upgraded.
 
Any ideas?
 
Santosh


"Steven J. Hill" <sjhill@realitydiluted.com> wrote:
santosh khare wrote:
>
> When I am trying to insmod iptables.o I am getting this error multiple 
> times.
> 
> relocation overflow of type 4 __copy_user
> relocation overflow of type 4 __copy_user
> relocation overflow of type 4 __copy_user
> .........
> 
> I was getting similar errors for printk etc but they disappeared after I 
> changed the CFLAGS for arch/mips/Makefile and included -mno-abicalls.
>
This flag is already included by default in both 2.4 and 2.6 kernels. How
did you compile your module?

-Steve

Santosh Khare
425 556 0845 (H)
425 241 3566 (C)

---------------------------------
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢


Santosh Khare
425 556 0845 (H)
425 241 3566 (C)
		
---------------------------------
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
--0-1446260502-1082755786=:47980
Content-Type: text/html; charset=us-ascii

<DIV><BR><BR>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<DIV>I have changed </DIV>
<DIV>CONFIG_IP_TABLES=y to </DIV>
<DIV>CONFIG_IP_TABLES=m</DIV>
<DIV>&nbsp;in .config file.</DIV>
<DIV>make modules now building ip_tables.o and I do not have this error any more.</DIV>
<DIV>Although, executing iptables utility is giving following error.</DIV>
<DIV>&nbsp;</DIV>
<DIV>ip_tables: applet not found</DIV>
<DIV>can't initialize iptables table 'filter': table does not exist</DIV>
<DIV>perhaps iptables or your kernel needs to be upgraded.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Any ideas?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Santosh</DIV>
<DIV><BR><BR><B><I>"Steven J. Hill" &lt;sjhill@realitydiluted.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">santosh khare wrote:<BR>&gt;<BR>&gt; When I am trying to insmod iptables.o I am getting this error multiple <BR>&gt; times.<BR>&gt; <BR>&gt; relocation overflow of type 4 __copy_user<BR>&gt; relocation overflow of type 4 __copy_user<BR>&gt; relocation overflow of type 4 __copy_user<BR>&gt; .........<BR>&gt; <BR>&gt; I was getting similar errors for printk etc but they disappeared after I <BR>&gt; changed the CFLAGS for arch/mips/Makefile and included -mno-abicalls.<BR>&gt;<BR>This flag is already included by default in both 2.4 and 2.6 kernels. How<BR>did you compile your module?<BR><BR>-Steve</BLOCKQUOTE><BR><BR>Santosh Khare<BR>425 556 0845 (H)<BR>425 241 3566 (C)
<P>
<HR SIZE=1>
<FONT face=arial size=-1>Do you Yahoo!?<BR>Yahoo! Photos: <A href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=23765/*http://photos.yahoo.com/ph/print_splash">High-quality 4x6 digital prints for 25¢</A></BLOCKQUOTE></DIV></FONT><BR><BR>Santosh Khare<br>425 556 0845 (H)<br>425 241 3566 (C)<p>
		<hr size=1><font face=arial size=-1>Do you Yahoo!?<br>
Yahoo! Photos: <a href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=23765/*http://photos.yahoo.c
om/ph/print_splash">High-quality 4x6 digital prints for 25¢</a>
--0-1446260502-1082755786=:47980--

From sskowron@ET.PUT.Poznan.PL Sat Apr 24 07:28:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 07:28:14 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:25743
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225204AbUDXG2N>; Sat, 24 Apr 2004 07:28:13 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O6SBN11772
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 08:28:11 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 08:28:10 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O6SAJ10879
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 08:28:10 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 08:28:09 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: 32-bit ABI
In-Reply-To: <Pine.LNX.4.55.0404231849480.14494@jurand.ds.pg.gda.pl>
Message-ID: <Pine.GSO.4.10.10404240825540.10762-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4864
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 481
Lines: 16

Hello,

why do we attempt to compile the kernel with 32-bit GAS abi and 64-bit GCC
abi? Is it because the module loader is broken and supports only 32-bit
ELFs? Then what about machines which load their kernels at weird 64-bit
addresses, like 0xa800000020004000 (Octane)?

I have changed it to 64-bit abi in my Octane kernel, because it won't even
compile otherwise. I've got gcc 3.3.2, gas 2.14.

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From yuasa@hh.iij4u.or.jp Sat Apr 24 07:48:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 07:48:57 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:55286 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225204AbUDXGsz>;
	Sat, 24 Apr 2004 07:48:55 +0100
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id PAB01784;
	Sat, 24 Apr 2004 15:48:51 +0900 (JST)
Received: 4UMDO00 id i3O6mpw11989; Sat, 24 Apr 2004 15:48:51 +0900 (JST)
Received: 4UMRO01 id i3O6mnm29349; Sat, 24 Apr 2004 15:48:50 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Sat, 24 Apr 2004 15:48:39 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.6] Update TB0229+TB0219 support
Message-Id: <20040424154839.5b0ea690.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4865
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 8311
Lines: 237

Hello Ralf,

This patch fixes so that the code of TB0229(CPU board) and
TB0219(base baord) may be divided correctly.

Please apply this patch to CVS

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/Makefile linux/arch/mips/vr41xx/tanbac-tb0229/Makefile
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/Makefile	Thu Feb 26 00:23:50 2004
+++ linux/arch/mips/vr41xx/tanbac-tb0229/Makefile	Sun Apr  4 01:31:31 2004
@@ -4,4 +4,4 @@
 
 obj-y				:= setup.o
 
-obj-$(CONFIG_TANBAC_TB0219)	+= reboot.o
+obj-$(CONFIG_TANBAC_TB0219)	+= tb0219.o
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/reboot.c linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/reboot.c	Sun Feb  1 21:41:34 2004
+++ linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c	Thu Jan  1 09:00:00 1970
@@ -1,27 +0,0 @@
-/*
- * FILE NAME
- *	arch/mips/vr41xx/tanbac-tb0229/reboot.c
- *
- * BRIEF MODULE DESCRIPTION
- *	Depending on TANBAC TB0229(VR4131DIMM) of reboot system call.
- *
- * Copyright 2003 Megasolution Inc.
- *                matsu@megasolution.jp
- *
- *  This program is free software; you can redistribute it and/or modify it
- *  under the terms of the GNU General Public License as published by the
- *  Free Software Foundation; either version 2 of the License, or (at your
- *  option) any later version.
- */
-#include <linux/config.h>
-#include <asm/io.h>
-#include <asm/vr41xx/tb0229.h>
-
-#define tb0229_hard_reset()	writew(0, TB0219_RESET_REGS)
-
-void tanbac_tb0229_restart(char *command)
-{
-	local_irq_disable();
-	tb0229_hard_reset();
-	while (1);
-}
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c	Thu Feb 26 00:23:50 2004
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Sun Apr  4 01:31:31 2004
@@ -25,7 +25,6 @@
 
 #include <asm/io.h>
 #include <asm/pci_channel.h>
-#include <asm/reboot.h>
 #include <asm/vr41xx/tb0229.h>
 
 #ifdef CONFIG_PCI
@@ -92,10 +91,6 @@
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);
-#endif
-
-#ifdef CONFIG_TANBAC_TB0219
-	_machine_restart = tanbac_tb0229_restart;
 #endif
 
 	return 0;
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/tb0219.c linux/arch/mips/vr41xx/tanbac-tb0229/tb0219.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/tb0219.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/tb0219.c	Sun Apr  4 01:31:31 2004
@@ -0,0 +1,45 @@
+/*
+ *  tb0219.c, Setup for the TANBAC TB0219
+ *
+ *  Copyright (C) 2003  Megasolution Inc. <matsu@megasolution.jp>
+ *  Copyright (C) 2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include <linux/init.h>
+
+#include <asm/io.h>
+#include <asm/reboot.h>
+#include <asm/vr41xx/tb0229.h>
+
+#define TB0219_RESET_REGS	KSEG1ADDR(0x0a00000e)
+
+#define tb0219_hard_reset()	writew(0, TB0219_RESET_REGS)
+
+void tanbac_tb0219_restart(char *command)
+{
+	local_irq_disable();
+	tb0219_hard_reset();
+	while (1);
+}
+
+static int __init tanbac_tb0219_setup(void)
+{
+	_machine_restart = tanbac_tb0219_restart;
+
+	return 0;
+}
+
+early_initcall(tanbac_tb0219_setup);
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/tb0219.h linux/include/asm-mips/vr41xx/tb0219.h
--- linux-orig/include/asm-mips/vr41xx/tb0219.h	Thu Jan  1 09:00:00 1970
+++ linux/include/asm-mips/vr41xx/tb0219.h	Sun Apr  4 01:31:31 2004
@@ -0,0 +1,42 @@
+/*
+ *  tb0219.h, Include file for TANBAC TB0219.
+ *
+ *  Copyright (C) 2002-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  Modified for TANBAC TB0219:
+ *  Copyright (C) 2003 Megasolution Inc.  <matsu@megasolution.jp>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#ifndef __TANBAC_TB0219_H
+#define __TANBAC_TB0219_H
+
+#include <asm/vr41xx/vr41xx.h>
+
+/*
+ * General-Purpose I/O Pin Number
+ */
+#define TB0219_PCI_SLOT1_PIN		2
+#define TB0219_PCI_SLOT2_PIN		3
+#define TB0219_PCI_SLOT3_PIN		4
+
+/*
+ * Interrupt Number
+ */
+#define TB0219_PCI_SLOT1_IRQ		GIU_IRQ(TB0219_PCI_SLOT1_PIN)
+#define TB0219_PCI_SLOT2_IRQ		GIU_IRQ(TB0219_PCI_SLOT2_PIN)
+#define TB0219_PCI_SLOT3_IRQ		GIU_IRQ(TB0219_PCI_SLOT3_PIN)
+
+#endif /* __TANBAC_TB0219_H */
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/tb0229.h linux/include/asm-mips/vr41xx/tb0229.h
--- linux-orig/include/asm-mips/vr41xx/tb0229.h	Thu May 22 06:55:39 2003
+++ linux/include/asm-mips/vr41xx/tb0229.h	Sun Apr  4 01:31:31 2004
@@ -1,27 +1,29 @@
 /*
- * FILE NAME
- *	include/asm-mips/vr41xx/tb0229.h
+ *  tb0229.h, Include file for TANBAC TB0229.
  *
- * BRIEF MODULE DESCRIPTION
- *	Include file for TANBAC TB0229 and TB0219.
+ *  Copyright (C) 2002-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
- * Copyright 2002,2003 Yoichi Yuasa
- *                yuasa@hh.iij4u.or.jp
+ *  Modified for TANBAC TB0229:
+ *  Copyright (C) 2003 Megasolution Inc.  <matsu@megasolution.jp>
  *
- * Modified for TANBAC TB0229:
- * Copyright 2003 Megasolution Inc.
- *                matsu@megasolution.jp
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
  *
- *  This program is free software; you can redistribute it and/or modify it
- *  under the terms of the GNU General Public License as published by the
- *  Free Software Foundation; either version 2 of the License, or (at your
- *  option) any later version.
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 #ifndef __TANBAC_TB0229_H
 #define __TANBAC_TB0229_H
 
 #include <asm/addrspace.h>
-#include <asm/vr41xx/vr41xx.h>
 
 /*
  * Board specific address mapping
@@ -51,23 +53,5 @@
 #define IO_MEM1_RESOURCE_END		(VR41XX_PCI_MEM1_BASE + VR41XX_PCI_MEM1_SIZE)
 #define IO_MEM2_RESOURCE_START		VR41XX_PCI_MEM2_BASE
 #define IO_MEM2_RESOURCE_END		(VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE)
-
-/*
- * General-Purpose I/O Pin Number
- */
-#define TB0219_PCI_SLOT1_PIN		2
-#define TB0219_PCI_SLOT2_PIN		3
-#define TB0219_PCI_SLOT3_PIN		4
-
-/*
- * Interrupt Number
- */
-#define TB0219_PCI_SLOT1_IRQ		GIU_IRQ(TB0219_PCI_SLOT1_PIN)
-#define TB0219_PCI_SLOT2_IRQ		GIU_IRQ(TB0219_PCI_SLOT2_PIN)
-#define TB0219_PCI_SLOT3_IRQ		GIU_IRQ(TB0219_PCI_SLOT3_PIN)
-
-#define TB0219_RESET_REGS		KSEG1ADDR(0x0a00000e)
-
-extern void tanbac_tb0229_restart(char *command);
 
 #endif /* __TANBAC_TB0229_H */

From ica2_ts@csv.ica.uni-stuttgart.de Sat Apr 24 08:09:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:09:10 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:779
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225204AbUDXHJJ>; Sat, 24 Apr 2004 08:09:09 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail)
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1BHHHf-0003Pg-00
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 09:09:07 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1BHHHf-0002ys-00
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 09:09:07 +0200
Date: Sat, 24 Apr 2004 09:09:07 +0200
To: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
Message-ID: <20040424070906.GN22147@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.LNX.4.55.0404231849480.14494@jurand.ds.pg.gda.pl> <Pine.GSO.4.10.10404240825540.10762-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404240825540.10762-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.5.5.1i
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: 4866
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 750
Lines: 24

Stanislaw Skowronek wrote:
> Hello,
> 
> why do we attempt to compile the kernel with 32-bit GAS abi and 64-bit GCC
> abi?

It optimizes away a few hundred kB of kernel code, but requires in turn
a sign-extended load-address plus ugly objcopy hacks.

> Is it because the module loader is broken and supports only 32-bit
> ELFs? Then what about machines which load their kernels at weird 64-bit
> addresses, like 0xa800000020004000 (Octane)?

Ah, the same as for IP28. :-) They can't be supported by the current
scheme.

> I have changed it to 64-bit abi in my Octane kernel, because it won't even
> compile otherwise. I've got gcc 3.3.2, gas 2.14.

You'll have to extend all the hand-coded asm memory accesses to do
64bit adressing as well.


Thiemo

From ralf@linux-mips.org Sat Apr 24 08:17:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:18:04 +0100 (BST)
Received: from p508B74B7.dip.t-dialin.net ([IPv6:::ffff:80.139.116.183]:23383
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225388AbUDXHRz>; Sat, 24 Apr 2004 08:17:55 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3O7HrxT025188;
	Sat, 24 Apr 2004 09:17:53 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3O7HqLs025187;
	Sat, 24 Apr 2004 09:17:52 +0200
Date: Sat, 24 Apr 2004 09:17:52 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
Message-ID: <20040424071751.GA561@linux-mips.org>
References: <Pine.LNX.4.55.0404231849480.14494@jurand.ds.pg.gda.pl> <Pine.GSO.4.10.10404240825540.10762-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404240825540.10762-100000@helios.et.put.poznan.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: 4867
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1769
Lines: 36

On Sat, Apr 24, 2004 at 08:28:09AM +0200, Stanislaw Skowronek wrote:

> why do we attempt to compile the kernel with 32-bit GAS abi and 64-bit GCC
> abi? Is it because the module loader is broken and supports only 32-bit
> ELFs? Then what about machines which load their kernels at weird 64-bit
> addresses, like 0xa800000020004000 (Octane)?

The whole thing was born as a dirty hack back in '99 or so to avoid the
totally broken and imcomplete implementation of 64-bit MIPS ELF in binutils.
By using these options we run the kernel in CKSEG0 which means 32-bit ELF
will suffice.  A nice side effect if a reduction of kernel size - this in
the end made the code model which was born as a hack the way of choice.

So there is no relation at all to modules.  You btw. can load 64-bit ELF
modules into a kernel which was built using above trick as 32-bit ELF.
That's necessary because modules are currently allocated through vmalloc
which allocates space in XKSEG.

A code model which I'm considering as alternative is -G optimization but
that will require a good bit of work; we would have to free up $28 which
right now we're already using for the current pointer.  A bunch of
declaration would simply need to be fixed.  Module loaders would need
support for R_MIPS_GPREL16 and we'd need a solution for the problem of
the kernel being too large, therefore overflowing the small data section.
Th latter is probably going to require binutils hacking, so non-trivial.

> I have changed it to 64-bit abi in my Octane kernel, because it won't even
> compile otherwise. I've got gcc 3.3.2, gas 2.14.

Octane has no memory at all in CKSEG0?

>   Paranoid: one who is truly in touch with reality.

The fact that you're paranoid doesn't meant they're not out to get you.

  Ralf

From macro@ds2.pg.gda.pl Sat Apr 24 08:18:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:18:26 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:5787 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225397AbUDXHSI>; Sat, 24 Apr 2004 08:18:08 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id F035E4AEA0; Sat, 24 Apr 2004 09:18:00 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id CEB41474B6; Sat, 24 Apr 2004 09:18:00 +0200 (CEST)
Date: Sat, 24 Apr 2004 09:18:00 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <Pine.GSO.4.10.10404240825540.10762-100000@helios.et.put.poznan.pl>
Message-ID: <Pine.LNX.4.55.0404240855580.14494@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404240825540.10762-100000@helios.et.put.poznan.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: 4868
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1705
Lines: 35

On Sat, 24 Apr 2004, Stanislaw Skowronek wrote:

> why do we attempt to compile the kernel with 32-bit GAS abi and 64-bit GCC
> abi? Is it because the module loader is broken and supports only 32-bit
> ELFs? Then what about machines which load their kernels at weird 64-bit
> addresses, like 0xa800000020004000 (Octane)?

1. Backward compatibility.  Old versions of gas/ld were buggy or
non-functional (depending on the version used) when using the (n)64 ABI.  
Search the mailing list archives -- I'm pretty sure anything since
2.13.2.1 should be safe, though.

2. Using the o32 ABI makes the binary smaller due to 32-bit pointers.  If
used without care, it can lead to pointer crops, though.  Anyway, some
people say it's important for them, despite the associated hassle.

> I have changed it to 64-bit abi in my Octane kernel, because it won't even
> compile otherwise. I've got gcc 3.3.2, gas 2.14.

 I know.  I build using (n)64 consistently for two years successfully --
it's OK even with gcc 2.95.x.  Making a choice between the ABIs for gas
user-selectable is on my to-do list for some time.  For now I think `make
gas-abi=64 ...' is probably the easiest workaround, though you'll need to
objcopy the resulting image to a 32-bit ELF file manually if your firmware
or loader cannot cope with 64-bit ELF binaries.  Well, I don't like the
automatic copy anyway -- it wastes too much disk space in the long run;
perhaps as a compromise it should be user-selectable, too (ditto about
SREC).

  Maciej

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

From sskowron@ET.PUT.Poznan.PL Sat Apr 24 08:31:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:31:18 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:58557
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225397AbUDXHbR>; Sat, 24 Apr 2004 08:31:17 +0100
Received: from athena (athena [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O7VFu17128;
	Sat, 24 Apr 2004 09:31:15 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 09:31:14 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O7VE313604;
	Sat, 24 Apr 2004 09:31:14 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 09:31:14 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <20040424071751.GA561@linux-mips.org>
Message-ID: <Pine.GSO.4.10.10404240927450.13336-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4869
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 888
Lines: 22

> So there is no relation at all to modules.  You btw. can load 64-bit ELF
> modules into a kernel which was built using above trick as 32-bit ELF.
> That's necessary because modules are currently allocated through vmalloc
> which allocates space in XKSEG.

Ah, so it's like that. Great. Is the ELF64 support still not correct?

> > I have changed it to 64-bit abi in my Octane kernel, because it won't even
> > compile otherwise. I've got gcc 3.3.2, gas 2.14.
> Octane has no memory at all in CKSEG0?

Well, as far as I know, and I'm probably right, it _does_ have some memory
there. A whopping 16 kilobytes of memory mirrored by the HEART to allow
placing exception vectors there (what a weird idea).

And you can't remap, I repeat, can't remap anything under 0x20000000
because there are the small Xtalk windows and HEART registers and God only
knows what else.

Stanislaw Skowronek



From sskowron@ET.PUT.Poznan.PL Sat Apr 24 08:34:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:34:59 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:4757 "EHLO
	europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225397AbUDXHe6>; Sat, 24 Apr 2004 08:34:58 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O7YuN12599;
	Sat, 24 Apr 2004 09:34:57 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 09:34:56 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O7YtN13820;
	Sat, 24 Apr 2004 09:34:55 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 09:34:55 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <Pine.LNX.4.55.0404240855580.14494@jurand.ds.pg.gda.pl>
Message-ID: <Pine.GSO.4.10.10404240931500.13336-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4870
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 1189
Lines: 25

>  I know.  I build using (n)64 consistently for two years successfully --
> it's OK even with gcc 2.95.x.  Making a choice between the ABIs for gas
> user-selectable is on my to-do list for some time.  For now I think `make
> gas-abi=64 ...' is probably the easiest workaround, though you'll need to
> objcopy the resulting image to a 32-bit ELF file manually if your firmware
> or loader cannot cope with 64-bit ELF binaries.  Well, I don't like the
> automatic copy anyway -- it wastes too much disk space in the long run;
> perhaps as a compromise it should be user-selectable, too (ditto about
> SREC).

True, the kernel is *huge* (some 7 MB). But there *will* be pointer crops
if I'm using the xkphys, and I can't use ckseg0 because there are only 16
kilobytes of RAM mapped there for exceptions. So I have to use abi=64. It
does work for me, anyway.

I think it really should be a config option. Even if not actually
user-selectable (why should it be?), it should default to 'y' for Octanes
and 'n' for everything else :)

Thank you for all your explanations. My idea about modules was because I
noticed some int->ptr conversion warnings I don't like at all.

Stanislaw Skowronek



From ica2_ts@csv.ica.uni-stuttgart.de Sat Apr 24 08:37:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:37:05 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:21515
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225397AbUDXHhE>; Sat, 24 Apr 2004 08:37:04 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail)
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1BHHih-0003hs-00
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 09:37:03 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1BHHih-00032O-00
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 09:37:03 +0200
Date: Sat, 24 Apr 2004 09:37:03 +0200
To: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
Message-ID: <20040424073703.GO22147@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.LNX.4.55.0404231849480.14494@jurand.ds.pg.gda.pl> <Pine.GSO.4.10.10404240825540.10762-100000@helios.et.put.poznan.pl> <20040424071751.GA561@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040424071751.GA561@linux-mips.org>
User-Agent: Mutt/1.5.5.1i
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: 4871
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 387
Lines: 11

Ralf Baechle wrote:
[snip]
> A code model which I'm considering as alternative is -G optimization but
> that will require a good bit of work; we would have to free up $28 which
> right now we're already using for the current pointer.

Gas has currently not much support for non-PIC n64 GP optimizations. The
recent changes have simplified the task of implementing them, though.


Thiemo

From ralf@linux-mips.org Sat Apr 24 08:38:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:38:05 +0100 (BST)
Received: from p508B74B7.dip.t-dialin.net ([IPv6:::ffff:80.139.116.183]:37463
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225397AbUDXHiF>; Sat, 24 Apr 2004 08:38:05 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3O7c2xT025636;
	Sat, 24 Apr 2004 09:38:02 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3O7c25m025635;
	Sat, 24 Apr 2004 09:38:02 +0200
Date: Sat, 24 Apr 2004 09:38:02 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
Message-ID: <20040424073802.GA25515@linux-mips.org>
References: <20040424071751.GA561@linux-mips.org> <Pine.GSO.4.10.10404240927450.13336-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404240927450.13336-100000@helios.et.put.poznan.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: 4872
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 881
Lines: 22

On Sat, Apr 24, 2004 at 09:31:14AM +0200, Stanislaw Skowronek wrote:

> > So there is no relation at all to modules.  You btw. can load 64-bit ELF
> > modules into a kernel which was built using above trick as 32-bit ELF.
> > That's necessary because modules are currently allocated through vmalloc
> > which allocates space in XKSEG.
> 
> Ah, so it's like that. Great. Is the ELF64 support still not correct?

No, it's supposed to be working now.

> > > I have changed it to 64-bit abi in my Octane kernel, because it won't even
> > > compile otherwise. I've got gcc 3.3.2, gas 2.14.
> > Octane has no memory at all in CKSEG0?
> 
> Well, as far as I know, and I'm probably right, it _does_ have some memory
> there. A whopping 16 kilobytes of memory mirrored by the HEART to allow
> placing exception vectors there (what a weird idea).

That's what the processor expects.

  Ralf

From ralf@linux-mips.org Sat Apr 24 08:44:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:44:50 +0100 (BST)
Received: from p508B74B7.dip.t-dialin.net ([IPv6:::ffff:80.139.116.183]:43351
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225397AbUDXHot>; Sat, 24 Apr 2004 08:44:49 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3O7iRxT025809;
	Sat, 24 Apr 2004 09:44:27 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3O7i7B5025808;
	Sat, 24 Apr 2004 09:44:07 +0200
Date: Sat, 24 Apr 2004 09:44:07 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
Message-ID: <20040424074407.GA25730@linux-mips.org>
References: <Pine.LNX.4.55.0404240855580.14494@jurand.ds.pg.gda.pl> <Pine.GSO.4.10.10404240931500.13336-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404240931500.13336-100000@helios.et.put.poznan.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: 4873
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 383
Lines: 10

On Sat, Apr 24, 2004 at 09:34:55AM +0200, Stanislaw Skowronek wrote:

> True, the kernel is *huge* (some 7 MB). But there *will* be pointer crops
> if I'm using the xkphys, and I can't use ckseg0 because there are only 16
> kilobytes of RAM mapped there for exceptions. So I have to use abi=64. It
> does work for me, anyway.

You could use a mapped address space, CKSEG2/3.

  Ralf

From sskowron@ET.PUT.Poznan.PL Sat Apr 24 08:46:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:46:54 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:46485
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225397AbUDXHqx>; Sat, 24 Apr 2004 08:46:53 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O7kmN12684;
	Sat, 24 Apr 2004 09:46:48 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 09:46:47 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O7klS14381;
	Sat, 24 Apr 2004 09:46:47 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 09:46:46 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <20040424073802.GA25515@linux-mips.org>
Message-ID: <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4874
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 531
Lines: 16

> > Ah, so it's like that. Great. Is the ELF64 support still not correct?
> No, it's supposed to be working now.

OK. File it away under 'compatibility cruft' then ;)

> > Well, as far as I know, and I'm probably right, it _does_ have some memory
> > there. A whopping 16 kilobytes of memory mirrored by the HEART to allow
> > placing exception vectors there (what a weird idea).
> That's what the processor expects.

Yeah. The weirdness is not in that part; what's weird is placing the rest
of memory somewhere else.

Stanislaw



From sskowron@ET.PUT.Poznan.PL Sat Apr 24 08:48:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:48:02 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:22719
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225397AbUDXHsC>; Sat, 24 Apr 2004 08:48:02 +0100
Received: from athena (athena [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O7lvu17216
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 09:47:57 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 09:47:57 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O7lv114450
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 09:47:57 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 09:47:56 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <20040424074407.GA25730@linux-mips.org>
Message-ID: <Pine.GSO.4.10.10404240946510.14182-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4875
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 476
Lines: 12

> > True, the kernel is *huge* (some 7 MB). But there *will* be pointer crops
> > if I'm using the xkphys, and I can't use ckseg0 because there are only 16
> > kilobytes of RAM mapped there for exceptions. So I have to use abi=64. It
> > does work for me, anyway.
> You could use a mapped address space, CKSEG2/3.

Yes, I could. I even know how to do that (thanks to Ralf's IP27 support),
however I think that making the kernel 64-bit-clean would benefit us all.

Stanislaw



From macro@ds2.pg.gda.pl Sat Apr 24 08:49:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:49:08 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:54685 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225758AbUDXHtH>; Sat, 24 Apr 2004 08:49:07 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id CBEBC4AEE3; Sat, 24 Apr 2004 09:48:58 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id F12E6474B6; Sat, 24 Apr 2004 09:48:58 +0200 (CEST)
Date: Sat, 24 Apr 2004 09:48:58 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <Pine.GSO.4.10.10404240931500.13336-100000@helios.et.put.poznan.pl>
Message-ID: <Pine.LNX.4.55.0404240938380.14494@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404240931500.13336-100000@helios.et.put.poznan.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: 4876
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1239
Lines: 28

On Sat, 24 Apr 2004, Stanislaw Skowronek wrote:

> True, the kernel is *huge* (some 7 MB). But there *will* be pointer crops

 Hmm, it depends on the number of drivers built-in -- my binaries are
usually around 3MB.  Or perhaps you should try strip? ;-)  You'll lose
symbol information for ksymoops then, though.

> if I'm using the xkphys, and I can't use ckseg0 because there are only 16
> kilobytes of RAM mapped there for exceptions. So I have to use abi=64. It
> does work for me, anyway.

 Sure, why wouldn't it?  Note, the current Makefile setup is intentionally 
easily tweakable for a fully 64-bit build.

> I think it really should be a config option. Even if not actually
> user-selectable (why should it be?), it should default to 'y' for Octanes
> and 'n' for everything else :)

 Well, I don't need it to be selectable, but I'd set all systems to use
the (n)64 ABI unconditionally, and the next minute someone would complain.  
;-)  Perhaps it can be unconditional for systems where the other setting 
makes no sense at all.

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

From macro@ds2.pg.gda.pl Sat Apr 24 08:51:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:51:29 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:6302 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225758AbUDXHv2>; Sat, 24 Apr 2004 08:51:28 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id CB80F4AEE3; Sat, 24 Apr 2004 09:51:22 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id B4F76475C5; Sat, 24 Apr 2004 09:51:22 +0200 (CEST)
Date: Sat, 24 Apr 2004 09:51:22 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.pl>
Message-ID: <Pine.LNX.4.55.0404240949350.14494@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.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: 4877
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 439
Lines: 12

On Sat, 24 Apr 2004, Stanislaw Skowronek wrote:

> Yeah. The weirdness is not in that part; what's weird is placing the rest
> of memory somewhere else.

 Perhaps to be able to put iomem stuff in CKSEG1 without implying a hole
in the RAM.

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

From ralf@linux-mips.org Sat Apr 24 08:56:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:56:28 +0100 (BST)
Received: from p508B74B7.dip.t-dialin.net ([IPv6:::ffff:80.139.116.183]:53335
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225758AbUDXH42>; Sat, 24 Apr 2004 08:56:28 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3O7u5xT029639;
	Sat, 24 Apr 2004 09:56:05 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3O7tjqu029043;
	Sat, 24 Apr 2004 09:55:45 +0200
Date: Sat, 24 Apr 2004 09:55:45 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
Message-ID: <20040424075545.GA27039@linux-mips.org>
References: <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.pl> <Pine.LNX.4.55.0404240949350.14494@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0404240949350.14494@jurand.ds.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: 4878
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 387
Lines: 12

On Sat, Apr 24, 2004 at 09:51:22AM +0200, Maciej W. Rozycki wrote:

> > Yeah. The weirdness is not in that part; what's weird is placing the rest
> > of memory somewhere else.
> 
>  Perhaps to be able to put iomem stuff in CKSEG1 without implying a hole
> in the RAM.

The machine is running a 64-bit kernel so likely it was designed with
little consideration for 32-bit issues.

  Ralf

From sskowron@ET.PUT.Poznan.PL Sat Apr 24 08:59:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 08:59:41 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:56000
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225758AbUDXH7l>; Sat, 24 Apr 2004 08:59:41 +0100
Received: from athena (athena [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O7xdu17334
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 09:59:40 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 09:59:39 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O7xdp15065
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 09:59:39 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 09:59:39 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: early_initcall
Message-ID: <Pine.GSO.4.10.10404240959130.15011-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4879
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 157
Lines: 8

What the hell is that? Nowhere declared and dead as a doornail in 2.6.5.

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From sskowron@ET.PUT.Poznan.PL Sat Apr 24 09:00:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 09:00:54 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:23958
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225758AbUDXIAx>; Sat, 24 Apr 2004 09:00:53 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O80qN12809
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 10:00:52 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 10:00:51 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O80pU15189
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 10:00:51 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 10:00:51 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: cancelpost ;)
Message-ID: <Pine.GSO.4.10.10404241000160.15164-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4880
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 190
Lines: 9

Sorry. A Google bug cropped an answer to my question on the base it was
'too similar'. Bovine fertilizer.

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From macro@ds2.pg.gda.pl Sat Apr 24 09:07:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 09:07:09 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:53918 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225758AbUDXIHI>; Sat, 24 Apr 2004 09:07:08 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id A0B184AEE3; Sat, 24 Apr 2004 10:07:02 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 905644AEA0; Sat, 24 Apr 2004 10:07:02 +0200 (CEST)
Date: Sat, 24 Apr 2004 10:07:02 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <20040424075545.GA27039@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0404240959200.14494@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.pl>
 <Pine.LNX.4.55.0404240949350.14494@jurand.ds.pg.gda.pl>
 <20040424075545.GA27039@linux-mips.org>
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: 4881
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1143
Lines: 26

On Sat, 24 Apr 2004, Ralf Baechle wrote:

> > > Yeah. The weirdness is not in that part; what's weird is placing the rest
> > > of memory somewhere else.
> > 
> >  Perhaps to be able to put iomem stuff in CKSEG1 without implying a hole
> > in the RAM.
> 
> The machine is running a 64-bit kernel so likely it was designed with
> little consideration for 32-bit issues.

 Well, the exception arrangement requires RAM starting from the physical
address 0.  It seems natural to place RAM just there, avoiding additional
complexity to address decoders.  But then firmware has to be somewere
around 0x1fc00000, so to support more than 508MB of RAM the designers
would have to create a hole in RAM, which would have to be handled by the
OS then.  Thus abandoning the idea of putting RAM low, placing it
somewhere above 0x1fffffff and just mapping some of it at 0 for the
exceptions seems a better solution.

 Fortunately everything is not a PC. :-)

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

From ralf@linux-mips.org Sat Apr 24 09:14:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 09:14:08 +0100 (BST)
Received: from p508B74B7.dip.t-dialin.net ([IPv6:::ffff:80.139.116.183]:856
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225758AbUDXIOH>; Sat, 24 Apr 2004 09:14:07 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3O8E5xT007432;
	Sat, 24 Apr 2004 10:14:05 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3O8E5Nq007431;
	Sat, 24 Apr 2004 10:14:05 +0200
Date: Sat, 24 Apr 2004 10:14:05 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
Message-ID: <20040424081405.GA26165@linux-mips.org>
References: <20040424073802.GA25515@linux-mips.org> <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.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: 4882
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1191
Lines: 30

On Sat, Apr 24, 2004 at 09:46:46AM +0200, Stanislaw Skowronek wrote:

> > > Ah, so it's like that. Great. Is the ELF64 support still not correct?
> > No, it's supposed to be working now.
> 
> OK. File it away under 'compatibility cruft' then ;)

The size difference this makes is still very significant.  In case of an
IP27 kernel default config:

   text    data     bss     dec     hex filename
2626662  747232  165760 3539654  3602c6 vmlinux
2907645 1283808  165760 4357213  427c5d vmlinux

The first kernel was built with the stock Makefile; the second was modified
to use 64-bit ELF using gcc 2.95.4 / binutils 2.13.2.1.  So I'd call those
817559 bytes kernel obesity ;)

> > > Well, as far as I know, and I'm probably right, it _does_ have some memory
> > > there. A whopping 16 kilobytes of memory mirrored by the HEART to allow
> > > placing exception vectors there (what a weird idea).
> > That's what the processor expects.
> 
> Yeah. The weirdness is not in that part; what's weird is placing the rest
> of memory somewhere else.

Not uncommon on SGI systems.  The Indy's memory also starts at 128MB; only
a few kB for exeption vectors are mirrored to physical address 0.

  Ralf

From sskowron@ET.PUT.Poznan.PL Sat Apr 24 09:14:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 09:14:31 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:26007
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225951AbUDXIOR>; Sat, 24 Apr 2004 09:14:17 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O8EFN12964;
	Sat, 24 Apr 2004 10:14:16 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 10:14:15 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O8EDl15963;
	Sat, 24 Apr 2004 10:14:13 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 10:14:13 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <Pine.LNX.4.55.0404240959200.14494@jurand.ds.pg.gda.pl>
Message-ID: <Pine.GSO.4.10.10404241008530.15622-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4883
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 1121
Lines: 25

>  Well, the exception arrangement requires RAM starting from the physical
> address 0.  It seems natural to place RAM just there, avoiding additional
> complexity to address decoders.  But then firmware has to be somewere
> around 0x1fc00000, so to support more than 508MB of RAM the designers
> would have to create a hole in RAM, which would have to be handled by the
> OS then.  Thus abandoning the idea of putting RAM low, placing it
> somewhere above 0x1fffffff and just mapping some of it at 0 for the
> exceptions seems a better solution.

OK, I forgot about the firmware placement. Why didn't they move it to
somewhere else when booting 64-bit? (A rhetorical question, I know.)

I would place some fixed code there. Or a different memory, maybe 16 kB of
static RAM so it will always be fast. With what is now, we have physical
and virtual aliasing and it's all a bit like a 

> Fortunately everything is not a PC. :-)

Yes, fortunately. The 386 memory management is a joke. The BIOS in the
middle is an even darker joke. Well, in my opinion the R8000 was right in
not having compatibility segments.

Stanislaw



From sskowron@ET.PUT.Poznan.PL Sat Apr 24 09:17:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 09:17:49 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:37527
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225951AbUDXIRs>; Sat, 24 Apr 2004 09:17:48 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O8HiN13000
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 10:17:44 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 10:17:43 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O8HgZ16205
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 10:17:42 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 10:17:42 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <20040424081405.GA26165@linux-mips.org>
Message-ID: <Pine.GSO.4.10.10404241015150.15622-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4884
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 697
Lines: 18

> The first kernel was built with the stock Makefile; the second was modified
> to use 64-bit ELF using gcc 2.95.4 / binutils 2.13.2.1.  So I'd call those
> 817559 bytes kernel obesity ;)

Yeah, true. It's really appalling. Make it a config option then, default
'n'. I will set it to 'y' for SGI_IP30. The Octane firmware has no
problems booting ELF64 (don't know about ELF32 though).

> > Yeah. The weirdness is not in that part; what's weird is placing the rest
> > of memory somewhere else.
> Not uncommon on SGI systems.  The Indy's memory also starts at 128MB; only
> a few kB for exeption vectors are mirrored to physical address 0.

They made a habit of this. The bastards. ;)

Stanislaw



From ralf@linux-mips.org Sat Apr 24 09:19:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 09:19:36 +0100 (BST)
Received: from p508B74B7.dip.t-dialin.net ([IPv6:::ffff:80.139.116.183]:6744
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225951AbUDXITg>; Sat, 24 Apr 2004 09:19:36 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3O8JExT007587;
	Sat, 24 Apr 2004 10:19:14 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3O8IsGB007558;
	Sat, 24 Apr 2004 10:18:54 +0200
Date: Sat, 24 Apr 2004 10:18:54 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
Message-ID: <20040424081854.GB26165@linux-mips.org>
References: <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.pl> <Pine.LNX.4.55.0404240949350.14494@jurand.ds.pg.gda.pl> <20040424075545.GA27039@linux-mips.org> <Pine.LNX.4.55.0404240959200.14494@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0404240959200.14494@jurand.ds.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: 4885
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1463
Lines: 31

On Sat, Apr 24, 2004 at 10:07:02AM +0200, Maciej W. Rozycki wrote:

> > > > Yeah. The weirdness is not in that part; what's weird is placing the rest
> > > > of memory somewhere else.
> > > 
> > >  Perhaps to be able to put iomem stuff in CKSEG1 without implying a hole
> > > in the RAM.
> > 
> > The machine is running a 64-bit kernel so likely it was designed with
> > little consideration for 32-bit issues.
> 
>  Well, the exception arrangement requires RAM starting from the physical
> address 0.  It seems natural to place RAM just there, avoiding additional
> complexity to address decoders.  But then firmware has to be somewere
> around 0x1fc00000, so to support more than 508MB of RAM the designers
> would have to create a hole in RAM, which would have to be handled by the
> OS then.  Thus abandoning the idea of putting RAM low, placing it
> somewhere above 0x1fffffff and just mapping some of it at 0 for the
> exceptions seems a better solution.
> 
>  Fortunately everything is not a PC. :-)

Actually the R10000 way to do something like this is to use the uncached
attribute like in the Origin.  It allows using the same physical address
space several times for different purposes.  So on node 0 of an Origin
indeed memory starts at physical address zero and there is no hole for
the firmware.  IP27 is afaik the only system using this R10000 feature
which surprises me a little due to the otherwise great similarity of these
two systems.

  Ralf

From macro@ds2.pg.gda.pl Sat Apr 24 09:23:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 09:23:41 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:61856 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225951AbUDXIXk>; Sat, 24 Apr 2004 09:23:40 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 86D574AEA0; Sat, 24 Apr 2004 10:23:34 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 73CAA47855; Sat, 24 Apr 2004 10:23:34 +0200 (CEST)
Date: Sat, 24 Apr 2004 10:23:34 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <20040424081854.GB26165@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0404241021140.14494@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.pl>
 <Pine.LNX.4.55.0404240949350.14494@jurand.ds.pg.gda.pl>
 <20040424075545.GA27039@linux-mips.org> <Pine.LNX.4.55.0404240959200.14494@jurand.ds.pg.gda.pl>
 <20040424081854.GB26165@linux-mips.org>
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: 4886
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 846
Lines: 17

On Sat, 24 Apr 2004, Ralf Baechle wrote:

> Actually the R10000 way to do something like this is to use the uncached
> attribute like in the Origin.  It allows using the same physical address
> space several times for different purposes.  So on node 0 of an Origin
> indeed memory starts at physical address zero and there is no hole for
> the firmware.  IP27 is afaik the only system using this R10000 feature
> which surprises me a little due to the otherwise great similarity of these
> two systems.

 That precludes the firmware from being run cached, though.  Not very 
nice, especially for callbacks, but perhaps a bit easier to deal with.

-- 
+  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 Sat Apr 24 09:26:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 09:26:36 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:5132
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225951AbUDXI0f>; Sat, 24 Apr 2004 09:26:35 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail)
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1BHIUb-0004NQ-00
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 10:26:33 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1BHIUb-0003HK-00
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 10:26:33 +0200
Date: Sat, 24 Apr 2004 10:26:33 +0200
To: linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
Message-ID: <20040424082633.GQ22147@rembrandt.csv.ica.uni-stuttgart.de>
References: <20040424081405.GA26165@linux-mips.org> <Pine.GSO.4.10.10404241015150.15622-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404241015150.15622-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.5.5.1i
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: 4887
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 477
Lines: 13

Stanislaw Skowronek wrote:
> > The first kernel was built with the stock Makefile; the second was modified
> > to use 64-bit ELF using gcc 2.95.4 / binutils 2.13.2.1.  So I'd call those
> > 817559 bytes kernel obesity ;)
> 
> Yeah, true. It's really appalling. Make it a config option then, default
> 'n'. I will set it to 'y' for SGI_IP30. The Octane firmware has no
> problems booting ELF64 (don't know about ELF32 though).

The IP28 firmware refuses to boot ELF32.


Thiemo

From ralf@linux-mips.org Sat Apr 24 09:27:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 09:27:38 +0100 (BST)
Received: from p508B74B7.dip.t-dialin.net ([IPv6:::ffff:80.139.116.183]:13656
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225951AbUDXI1i>; Sat, 24 Apr 2004 09:27:38 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3O8RFxT007770;
	Sat, 24 Apr 2004 10:27:15 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3O8QtkY007760;
	Sat, 24 Apr 2004 10:26:55 +0200
Date: Sat, 24 Apr 2004 10:26:55 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
Message-ID: <20040424082655.GC26165@linux-mips.org>
References: <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.pl> <Pine.LNX.4.55.0404240949350.14494@jurand.ds.pg.gda.pl> <20040424075545.GA27039@linux-mips.org> <Pine.LNX.4.55.0404240959200.14494@jurand.ds.pg.gda.pl> <20040424081854.GB26165@linux-mips.org> <Pine.LNX.4.55.0404241021140.14494@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0404241021140.14494@jurand.ds.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: 4888
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 799
Lines: 17

On Sat, Apr 24, 2004 at 10:23:34AM +0200, Maciej W. Rozycki wrote:

> > Actually the R10000 way to do something like this is to use the uncached
> > attribute like in the Origin.  It allows using the same physical address
> > space several times for different purposes.  So on node 0 of an Origin
> > indeed memory starts at physical address zero and there is no hole for
> > the firmware.  IP27 is afaik the only system using this R10000 feature
> > which surprises me a little due to the otherwise great similarity of these
> > two systems.
> 
>  That precludes the firmware from being run cached, though.  Not very 
> nice, especially for callbacks, but perhaps a bit easier to deal with.

Sane firmware copies itself to RAM at the earliest possible stage anyway -
ROMs are way too slow.

  Ralf

From macro@ds2.pg.gda.pl Sat Apr 24 09:49:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 09:49:17 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:20903 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225951AbUDXItQ>; Sat, 24 Apr 2004 09:49:16 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 0E5314AEE3; Sat, 24 Apr 2004 10:49:09 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id F1BDC4AEA0; Sat, 24 Apr 2004 10:49:09 +0200 (CEST)
Date: Sat, 24 Apr 2004 10:49:09 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
Subject: Re: 32-bit ABI
In-Reply-To: <20040424082655.GC26165@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0404241043160.14494@jurand.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10404240945500.14182-100000@helios.et.put.poznan.pl>
 <Pine.LNX.4.55.0404240949350.14494@jurand.ds.pg.gda.pl>
 <20040424075545.GA27039@linux-mips.org> <Pine.LNX.4.55.0404240959200.14494@jurand.ds.pg.gda.pl>
 <20040424081854.GB26165@linux-mips.org> <Pine.LNX.4.55.0404241021140.14494@jurand.ds.pg.gda.pl>
 <20040424082655.GC26165@linux-mips.org>
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: 4889
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 892
Lines: 20

On Sat, 24 Apr 2004, Ralf Baechle wrote:

> >  That precludes the firmware from being run cached, though.  Not very 
> > nice, especially for callbacks, but perhaps a bit easier to deal with.
> 
> Sane firmware copies itself to RAM at the earliest possible stage anyway -
> ROMs are way too slow.

 Indeed, though it excludes the RAM used from the OS control (unless the 
OS wants to block itself from the access to callbacks).

 FYI, DEC copies only the bits it currently needs (and e.g. option ROMs 
typically cannot be directly executed at all as they often are 8-bit, but 
return word-aligned data) and when booting the OS certain callback vector 
entries point to RAM and others to ROM.

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

From sskowron@ET.PUT.Poznan.PL Sat Apr 24 10:00:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 10:00:49 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:6347 "EHLO
	athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225951AbUDXJAq>; Sat, 24 Apr 2004 10:00:46 +0100
Received: from athena (athena [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O90iu18014
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 11:00:44 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 11:00:44 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3O90i218419
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 11:00:44 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 11:00:44 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: pci-ip27 memory ranges
Message-ID: <Pine.GSO.4.10.10404241059030.18252-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4890
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 300
Lines: 12

Why does the pci-ip27 driver register all memory resources (0UL - ~0UL)? I
had to change it to the appropriate Xtalk window to get the kernel to
recognize PCI at all.

Now, the IOC3 makes a kernel panic. Will see...

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From hch@lst.de Sat Apr 24 11:30:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 11:30:14 +0100 (BST)
Received: from verein.lst.de ([IPv6:::ffff:212.34.189.10]:41662 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8225962AbUDXKaN>;
	Sat, 24 Apr 2004 11:30:13 +0100
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3OAU4Qc015359
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Sat, 24 Apr 2004 12:30:05 +0200
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i3OAU4YC015357;
	Sat, 24 Apr 2004 12:30:04 +0200
Date: Sat, 24 Apr 2004 12:30:04 +0200
From: Christoph Hellwig <hch@lst.de>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: pci-ip27 memory ranges
Message-ID: <20040424103004.GA15322@lst.de>
References: <Pine.GSO.4.10.10404241059030.18252-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404241059030.18252-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.3.28i
X-Spam-Score: -4.901 () BAYES_00
X-Scanned-By: MIMEDefang 2.39
Return-Path: <hch@lst.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4891
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@lst.de
Precedence: bulk
X-list: linux-mips
Content-Length: 392
Lines: 8

On Sat, Apr 24, 2004 at 11:00:44AM +0200, Stanislaw Skowronek wrote:
> Why does the pci-ip27 driver register all memory resources (0UL - ~0UL)?

The current PCI support for IP27 is more or less a huge hack.  I plan to
hack it up to do the right thing based on the IRIX code for it released
by SGI, but it'll take a bit because that code isn't exactly readable
and my time is rather limited.


From sskowron@ET.PUT.Poznan.PL Sat Apr 24 18:14:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 18:14:42 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:18611
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225964AbUDXROl>; Sat, 24 Apr 2004 18:14:41 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3OHEYN17551
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 19:14:34 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 19:14:33 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3OHEWB10499
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 19:14:32 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 19:14:32 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Xtalk bridge IRQs
Message-ID: <Pine.GSO.4.10.10404241914160.10450-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4892
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 454
Lines: 14

Hello!

I've got a problem with Xtalk-PCI bridge IRQs. The IOC3 should send an
interrupt before transmitting a packet. I don't know if it sends it or
not, but for sure it does not arrive to me. The power button interrupt,
which is also routed via the bridge, works OK, so the IRQ router part of
the bridge is correctly services. However, I can't get any PCI interrupts.

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From ralf@linux-mips.org Sat Apr 24 19:20:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 19:20:41 +0100 (BST)
Received: from p508B74B7.dip.t-dialin.net ([IPv6:::ffff:80.139.116.183]:28253
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225971AbUDXSUk>; Sat, 24 Apr 2004 19:20:40 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3OIKJxT022689
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 20:20:19 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3OIJxCs022683;
	Sat, 24 Apr 2004 20:19:59 +0200
Date: Sat, 24 Apr 2004 20:19:59 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: Xtalk bridge IRQs
Message-ID: <20040424181959.GB21153@linux-mips.org>
References: <Pine.GSO.4.10.10404241914160.10450-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404241914160.10450-100000@helios.et.put.poznan.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: 4893
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1838
Lines: 35

On Sat, Apr 24, 2004 at 07:14:32PM +0200, Stanislaw Skowronek wrote:

> I've got a problem with Xtalk-PCI bridge IRQs. The IOC3 should send an
> interrupt before transmitting a packet. I don't know if it sends it or
> not, but for sure it does not arrive to me. The power button interrupt,
> which is also routed via the bridge, works OK, so the IRQ router part of
> the bridge is correctly services. However, I can't get any PCI interrupts.

The way that PCI interrupts work on IP27 is: A device's INTA pin is
connected to the BRIDGE ASIC.  When a device's interrupt line is asserted,
the bridge ASIC will store a value which consists of 0x100 | intnum into
another register; the address of that other register can be configured per
device in the BRIDGE chip.  The value is usuall the xtalk address of another
register in the HUB ASIC.  For HUB the value 0x100 | intnum would mean to
set bit intnum in the interrupt pending register.  The BRIDGE chip
can also be configured to send an interrupt clear packet if the PCI
interrupt is deasserted again; it's a good idea to have this enabled since
otherwise writing race-free interrupt handlers is a PITA.  The HUB
chip then asserts one of the CPU interrupt lines if a bit is set in the
interrupt pending register and mask0/mask1 register for the CPU.

For a single node system this could be slightly simplified - no idea if
SGI did that for the HEART design.  Anyway, in case of an Origin you'd
have to chase the interrupt through the various stages of processing:

 - Interupt sent from the device?
 - Interrupt asserted at BRIDGE?
 - Interrupt bit set in HUB chip?
 - Interrupt enabled in HUB mask register?
 - Interrupt pending in the CPU's cause register?
 - Interrupt bit set and EXL and ERL both clear in CPU status register?

I hope that's somehow applicable to the IP30 ...

  Ralf

From ralf@linux-mips.org Sat Apr 24 19:22:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 19:22:28 +0100 (BST)
Received: from p508B74B7.dip.t-dialin.net ([IPv6:::ffff:80.139.116.183]:30301
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225971AbUDXSW1>; Sat, 24 Apr 2004 19:22:27 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3OIM6xT022743
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 20:22:06 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3OILkmi022742;
	Sat, 24 Apr 2004 20:21:46 +0200
Date: Sat, 24 Apr 2004 20:21:46 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: pci-ip27 memory ranges
Message-ID: <20040424182146.GD26165@linux-mips.org>
References: <Pine.GSO.4.10.10404241059030.18252-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404241059030.18252-100000@helios.et.put.poznan.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: 4894
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 700
Lines: 16

On Sat, Apr 24, 2004 at 11:00:44AM +0200, Stanislaw Skowronek wrote:

> Why does the pci-ip27 driver register all memory resources (0UL - ~0UL)? I
> had to change it to the appropriate Xtalk window to get the kernel to
> recognize PCI at all.

The IP27 PCI code as it is in CVS is incomplete or even broken - however
fixing isn't entirely trivial.  The current workaround which I use - and
which due to being just an evil hack is not in CVS - to only scan the PCI
code.  The problem is the firmware does a very simple setup which hurts
performance very badly, so eventually Linux will have to do a full PCI
configuration for all PCI busses.

> Now, the IOC3 makes a kernel panic. Will see...

  Ralf

From sskowron@ET.PUT.Poznan.PL Sat Apr 24 19:34:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 19:34:19 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:14518
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225971AbUDXSeS>; Sat, 24 Apr 2004 19:34:18 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3OIYCN18048
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 20:34:12 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 24 Apr 2004 20:34:11 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3OIYAc14095
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 20:34:10 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sat, 24 Apr 2004 20:34:10 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Re: Xtalk bridge IRQs
In-Reply-To: <20040424181959.GB21153@linux-mips.org>
Message-ID: <Pine.GSO.4.10.10404242028250.13768-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4895
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 2073
Lines: 54

> The way that PCI interrupts work on IP27 is: A device's INTA pin is
> connected to the BRIDGE ASIC.

Only INTAs? Does each INTA of a device have a dedicated pin on the bridge
(I am not sure, but it seems so)?

> When a device's interrupt line is asserted, the bridge ASIC will store
> a value which consists of 0x100 | intnum into another register; the
> address of that other register can be configured per device in the
> BRIDGE chip.  The value is usuall the xtalk address of another
> register in the HUB ASIC.  For HUB the value 0x100 | intnum would mean
> to set bit intnum in the interrupt pending register.

OK, I figured that out from the IRIX headers. Apparently, HEART does it
the same way, only the register is at 0x80 and not 0x90.

> The BRIDGE chip can also be configured to send an interrupt clear
> packet if the PCI interrupt is deasserted again; it's a good idea to
> have this enabled since otherwise writing race-free interrupt handlers
> is a PITA.  The HUB chip then asserts one of the CPU interrupt lines
> if a bit is set in the interrupt pending register and mask0/mask1
> register for the CPU.

It is very similar to the HEART, then. But I didn't know about clear
packets.

> For a single node system this could be slightly simplified - no idea if
> SGI did that for the HEART design.  Anyway, in case of an Origin you'd
> have to chase the interrupt through the various stages of processing:
>  - Interupt sent from the device?

Well, I don't know... Should I take out my logic analyzer?

>  - Interrupt asserted at BRIDGE?

I don't know this, either.

>  - Interrupt bit set in HUB chip?

Well, if anything is asserted at the bridge, all the following steps are
correctly executed. It's a problem around the IOC. Could you please tell
me, how are IOC packets transmitted? What is the relation of this to the
interrupts?

I have tried to run NFSRoot, but the machine sends no packets, even though
it believes firmly that it sends (i.e. no error messages).

> I hope that's somehow applicable to the IP30 ...

So do I :)

Stanislaw Skowronek



From ralf@linux-mips.org Sat Apr 24 19:55:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Apr 2004 19:55:43 +0100 (BST)
Received: from p508B74B7.dip.t-dialin.net ([IPv6:::ffff:80.139.116.183]:52317
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225971AbUDXSzk>; Sat, 24 Apr 2004 19:55:40 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3OItJxT023463
	for <linux-mips@linux-mips.org>; Sat, 24 Apr 2004 20:55:19 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3OIsx78023456;
	Sat, 24 Apr 2004 20:54:59 +0200
Date: Sat, 24 Apr 2004 20:54:59 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: Xtalk bridge IRQs
Message-ID: <20040424185459.GA23008@linux-mips.org>
References: <20040424181959.GB21153@linux-mips.org> <Pine.GSO.4.10.10404242028250.13768-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404242028250.13768-100000@helios.et.put.poznan.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: 4896
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 3380
Lines: 78

On Sat, Apr 24, 2004 at 08:34:10PM +0200, Stanislaw Skowronek wrote:

> > The way that PCI interrupts work on IP27 is: A device's INTA pin is
> > connected to the BRIDGE ASIC.
> 
> Only INTAs? Does each INTA of a device have a dedicated pin on the bridge
> (I am not sure, but it seems so)?

If I recall right the INTA-INTD pins of each devices are logically or'ed
together.  Since IOC3 only uses INTA this simple fact doesn't really matter
to us anyway ...

> > The BRIDGE chip can also be configured to send an interrupt clear
> > packet if the PCI interrupt is deasserted again; it's a good idea to
> > have this enabled since otherwise writing race-free interrupt handlers
> > is a PITA.  The HUB chip then asserts one of the CPU interrupt lines
> > if a bit is set in the interrupt pending register and mask0/mask1
> > register for the CPU.
> 
> It is very similar to the HEART, then. But I didn't know about clear
> packets.

If BRIDGE isn't configured to send clear packets the interrupt needs to be
clear manually by a processor write to the HUB's register.  Leaving that
to the hardware is just simpler.

> > For a single node system this could be slightly simplified - no idea if
> > SGI did that for the HEART design.  Anyway, in case of an Origin you'd
> > have to chase the interrupt through the various stages of processing:
> >  - Interupt sent from the device?
> 
> Well, I don't know... Should I take out my logic analyzer?

Let's wait with the big guns :)

> >  - Interrupt asserted at BRIDGE?
> 
> I don't know this, either.

You can verify by reading the pending register.

> >  - Interrupt bit set in HUB chip?
> 
> Well, if anything is asserted at the bridge, all the following steps are
> correctly executed. It's a problem around the IOC. Could you please tell
> me, how are IOC packets transmitted? What is the relation of this to the
> interrupts?
> 
> I have tried to run NFSRoot, but the machine sends no packets, even though
> it believes firmly that it sends (i.e. no error messages).

IOC3 is basically your average mid-90s 100BaseT NIC.  If you know some other
NIC like for example a PCnet32, they're basically similar in their
fundamental concepts such as RX/TX rings.

An IOC3 TX ring consists of entries which each are 128 bytes long.  Each
contains a few status etc. bits, a few bytes that could be used to store a
small packet (ioc3-eth.c uses this) and two 64-bit pointers to actual
packet data.  IOC3 has the ugly constraint of not supporting transmit of
packets that cross a 16kB page boundary.  In that case of such a packet we
use the pointer to the second fragment, otherwise only the first.

IP27 support 32-bit mapped DMA which Linux doesn't support yet, so only
64-bit PCI devices will work atm.  For those the upper 16 bit specify extra
attributes which you'll find in include/asm-mips/pci/bridge.h which again
is just a copy of the IRIX <PCI/bridge.h>.

I think the way we use those bits should also be aplicable to IP30 but I'm
not sure never having seen any material on the machine.  You may want to
try to figure out what value the firmware uses when configuring the IOC3
for netbooting.

Does link negotiation and reading the MAC address from the NIC (Number In
a Can, that coin battery like Dallas chip near the IOC3) work?  At least
link negotiation would have to work before you'd have any chance to see
any packets.

  Ralf

From sskowron@ET.PUT.Poznan.PL Sun Apr 25 18:18:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Apr 2004 18:18:33 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:62145
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225457AbUDYRSa>; Sun, 25 Apr 2004 18:18:30 +0100
Received: from athena (athena [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3PHIJu03166
	for <linux-mips@linux-mips.org>; Sun, 25 Apr 2004 19:18:19 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena (MailMonitor for SMTP v1.2.2 ) ;
	Sun, 25 Apr 2004 19:18:19 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3PHIIo04098
	for <linux-mips@linux-mips.org>; Sun, 25 Apr 2004 19:18:18 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Sun, 25 Apr 2004 19:18:16 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Work on IP30
Message-ID: <Pine.GSO.4.10.10404251914350.3916-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4897
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 626
Lines: 27

Hello!

I have placed a alpha version of my patch for Octane at:

  http://www.et.put.poznan.pl/~sskowron/ip30/

Things currently unsupported:
  * SMP will not work,
  * qLogic SCSI driver oopses at the start,
  * keyboard is not written yet,
  * VPro (Odyssey) graphics,
  * ARCS console,
  * serial console,
  * PCI card cage (trivial, but I can't test it as I don't have one)

Things not yet tested:
  * new Octanes and Octane2s,
  * user mode (yes! I don't have yet a MIPS glibc to cross-compile for
    user mode),
  * almost everything

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From ralf@linux-mips.org Mon Apr 26 13:52:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Apr 2004 13:52:56 +0100 (BST)
Received: from p508B6198.dip.t-dialin.net ([IPv6:::ffff:80.139.97.152]:27507
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224921AbUDZMwy>; Mon, 26 Apr 2004 13:52:54 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3QCqrxT020836;
	Mon, 26 Apr 2004 14:52:53 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3QCqrkT020835;
	Mon, 26 Apr 2004 14:52:53 +0200
Date: Mon, 26 Apr 2004 14:52:53 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Alex Deucher <agd5f@yahoo.com>, linux-mips@linux-mips.org
Subject: Re: few questions about linux on sgi machines
Message-ID: <20040426125253.GA20409@linux-mips.org>
References: <20040423131706.GA27375@lst.de> <20040423132901.97621.qmail@web11301.mail.yahoo.com> <20040423133106.GA27699@lst.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040423133106.GA27699@lst.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: 4900
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 432
Lines: 15

On Fri, Apr 23, 2004 at 03:31:06PM +0200, Christoph Hellwig wrote:

> On Fri, Apr 23, 2004 at 06:29:01AM -0700, Alex Deucher wrote:
> > I assume IP30 has the same problems since they are similarly
> > architected?
> 
> I guess it has the same problems as it's using the bridge ASIC, too.
> 
> > What about IP32?
> 
> It uses a completely different pci subsystem that should be okay.

It's not fully PCI compliant either ...

  Ralf

From yuasa@hh.iij4u.or.jp Mon Apr 26 17:40:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Apr 2004 17:40:51 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:18677 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225998AbUDZQks>;
	Mon, 26 Apr 2004 17:40:48 +0100
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id BAA01979;
	Tue, 27 Apr 2004 01:40:44 +0900 (JST)
Received: 4UMDO01 id i3QGehT17592; Tue, 27 Apr 2004 01:40:44 +0900 (JST)
Received: 4UMRO00 id i3QGeg800211; Tue, 27 Apr 2004 01:40:42 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Tue, 27 Apr 2004 01:40:39 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.6] Fixes serial setup fot vr41xx
Message-Id: <20040427014039.102fdb50.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4901
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 12904
Lines: 401

Hello Ralf,

This patch fixes the serial setup for vr41xx.
Please apply this patch to CVS.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux-orig/arch/mips/vr41xx/casio-e55/setup.c	Thu Feb 26 00:23:50 2004
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Tue Apr 27 00:58:07 2004
@@ -35,7 +35,8 @@
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
 #ifdef CONFIG_SERIAL_8250
-	vr41xx_siu_init(SIU_RS232C, 0);
+	vr41xx_siu_init();
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
 #endif
 
 	return 0;
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux-orig/arch/mips/vr41xx/common/icu.c	Tue Jan 13 08:21:05 2004
+++ linux/arch/mips/vr41xx/common/icu.c	Mon Apr 26 23:56:42 2004
@@ -1,34 +1,23 @@
 /*
- * FILE NAME
- *	arch/mips/vr41xx/common/icu.c
+ *  icu.c, Interrupt Control Unit routines for the NEC VR4100 series.
  *
- * BRIEF MODULE DESCRIPTION
- *	Interrupt Control Unit routines for the NEC VR4100 series.
- *
- * Author: Yoichi Yuasa
- *         yyuasa@mvista.com or source@mvista.com
- *
- * Copyright 2001,2002 MontaVista Software Inc.
- *
- *  This program is free software; you can redistribute it and/or modify it
- *  under the terms of the GNU General Public License as published by the
- *  Free Software Foundation; either version 2 of the License, or (at your
- *  option) any later version.
- *
- *  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
- *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
- *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
- *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
- *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- *  You should have received a copy of the GNU General Public License along
- *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  675 Mass Ave, Cambridge, MA 02139, USA.
+ *  Copyright (C) 2001-2002  MontaVista Software Inc.
+ *    Author: Yoichi Yuasa <yyuasa@mvista.com or source@mvista.com>
+ *  Copyright (C) 2003-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 /*
  * Changes:
@@ -80,6 +69,8 @@
 #define GIUINTLREG	0x08
 #define MSYSINT1REG	0x0c
 #define MGIUINTLREG	0x14
+#define MDSIUINTREG	0x16
+ #define INTDSIU	0x0800
 #define NMIREG		0x18
 #define SOFTREG		0x1a
 #define INTASSIGN2	0x1c
@@ -144,6 +135,18 @@
 	write_icu2(res, offset);
 
 	return res;
+}
+
+/*=======================================================================*/
+
+void vr41xx_enable_dsiuint(void)
+{
+	set_icu1(MDSIUINTREG, INTDSIU);
+}
+
+void vr41xx_disable_dsiuint(void)
+{
+	clear_icu1(MDSIUINTREG, INTDSIU);
 }
 
 /*=======================================================================*/
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux-orig/arch/mips/vr41xx/common/serial.c	Thu Feb 26 00:23:50 2004
+++ linux/arch/mips/vr41xx/common/serial.c	Tue Apr 27 01:19:04 2004
@@ -40,14 +40,8 @@
 #include <asm/io.h>
 #include <asm/vr41xx/vr41xx.h>
 
-/* VR4111 and VR4121 SIU Registers */
-#define SIURB_TYPE1		KSEG1ADDR(0x0c000000)
 #define SIUIRSEL_TYPE1		KSEG1ADDR(0x0c000008)
-
-/* VR4122, VR4131 and VR4133 SIU Registers */
-#define SIURB_TYPE2		KSEG1ADDR(0x0f000800)
 #define SIUIRSEL_TYPE2		KSEG1ADDR(0x0f000808)
-
  #define USE_RS232C		0x00
  #define USE_IRDA		0x01
  #define SIU_USES_IRDA		0x00
@@ -58,21 +52,24 @@
  #define TMICTX			0x10
  #define TMICMODE		0x20
 
-#define SIU_BASE_BAUD		1152000
+#define SIU_BASE_TYPE1		0x0c000000UL	/* VR4111 and VR4121 */
+#define SIU_BASE_TYPE2		0x0f000800UL	/* VR4122, VR4131 and VR4133 */
+#define SIU_SIZE		0xcUL
 
-/* VR4122 and VR4131 DSIU Registers */
-#define DSIURB			KSEG1ADDR(0x0f000820)
+#define SIU_BASE_BAUD		1152000
 
-#define MDSIUINTREG		KSEG1ADDR(0x0f000096)
- #define INTDSIU		0x0800
+/* VR4122, VR4131 and VR4133 DSIU Registers */
+#define DSIU_BASE		0x0f000820UL
+#define DSIU_SIZE		0x8UL
 
 #define DSIU_BASE_BAUD		1152000
 
 int vr41xx_serial_ports = 0;
 
-void vr41xx_siu_ifselect(int interface, int module)
+void vr41xx_select_siu_interface(siu_interface_t interface,
+                                 irda_module_t module)
 {
-	u16 val = USE_RS232C;	/* Select RS-232C */
+	uint16_t val = USE_RS232C;	/* Select RS-232C */
 
 	/* Select IrDA */
 	if (interface == SIU_IRDA) {
@@ -86,6 +83,9 @@
 		case IRDA_HP:
 			val = IRDA_MODULE_HP;
 			break;
+		default:
+			printk(KERN_ERR "SIU: unknown IrDA module\n");
+			return;
 		}
 		val |= USE_IRDA | SIU_USES_IRDA;
 	}
@@ -101,45 +101,47 @@
 		writew(val, SIUIRSEL_TYPE2);
 		break;
 	default:
-		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
+		printk(KERN_ERR "SIU: unsupported CPU of NEC VR4100 series\n");
 		break;
 	}
 }
 
-void __init vr41xx_siu_init(int interface, int module)
+void __init vr41xx_siu_init(void)
 {
 	struct uart_port port;
 
-	vr41xx_siu_ifselect(interface, module);
-
 	memset(&port, 0, sizeof(port));
 
 	port.line = vr41xx_serial_ports;
-	port.uartclk = SIU_BASE_BAUD;
+	port.uartclk = SIU_BASE_BAUD * 16;
 	port.irq = SIU_IRQ;
-	port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
+	port.flags = UPF_RESOURCES | UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		port.membase = (char *)SIURB_TYPE1;
+		port.mapbase = SIU_BASE_TYPE1;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		port.membase = (char *)SIURB_TYPE2;
+		port.mapbase = SIU_BASE_TYPE2;
 		break;
 	default:
-		panic("Unexpected CPU of NEC VR4100 series");
-		break;
+		printk(KERN_ERR "SIU: unsupported CPU of NEC VR4100 series\n");
+		return;
 	}
 	port.regshift = 0;
 	port.iotype = UPIO_MEM;
-	if (early_serial_setup(&port) != 0)
-		printk(KERN_ERR "SIU setup failed!\n");
-
-	vr41xx_supply_clock(SIU_CLOCK);
+	port.membase = ioremap(port.mapbase, SIU_SIZE);
+	if (port.membase != NULL) {
+		if (early_serial_setup(&port) == 0) {
+			vr41xx_supply_clock(SIU_CLOCK);
+			vr41xx_serial_ports++;
+			return;
+		}
+	}
 
-	vr41xx_serial_ports++;
+	printk(KERN_ERR "SIU: setup failed!\n");
 }
 
 void __init vr41xx_dsiu_init(void)
@@ -148,24 +150,29 @@
 
 	if (current_cpu_data.cputype != CPU_VR4122 &&
 	    current_cpu_data.cputype != CPU_VR4131 &&
-	    current_cpu_data.cputype != CPU_VR4133)
+	    current_cpu_data.cputype != CPU_VR4133) {
+		printk(KERN_ERR "DSIU: unsupported CPU of NEC VR4100 series\n");
 		return;
+	}
 
 	memset(&port, 0, sizeof(port));
 
 	port.line = vr41xx_serial_ports;
-	port.uartclk = DSIU_BASE_BAUD;
+	port.uartclk = DSIU_BASE_BAUD * 16;
 	port.irq = DSIU_IRQ;
-	port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
-	port.membase = (char *)DSIURB;
+	port.flags = UPF_RESOURCES | UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
+	port.mapbase = DSIU_BASE;
 	port.regshift = 0;
 	port.iotype = UPIO_MEM;
-	if (early_serial_setup(&port) != 0)
-		printk(KERN_ERR "DSIU setup failed!\n");
-
-	vr41xx_supply_clock(DSIU_CLOCK);
-
-	writew(INTDSIU, MDSIUINTREG);
+	port.membase = ioremap(port.mapbase, DSIU_SIZE);
+	if (port.membase != NULL) {
+		if (early_serial_setup(&port) == 0) {
+			vr41xx_supply_clock(DSIU_CLOCK);
+			vr41xx_enable_dsiuint();
+			vr41xx_serial_ports++;
+			return;
+		}
+	}
 
-	vr41xx_serial_ports++;
+	printk(KERN_ERR "DSIU: setup failed!\n");
 }
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c	Thu Feb 26 00:23:50 2004
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Tue Apr 27 00:59:15 2004
@@ -35,7 +35,8 @@
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
 #ifdef CONFIG_SERIAL_8250
-	vr41xx_siu_init(SIU_RS232C, 0);
+	vr41xx_siu_init();
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
 #endif
 
 	return 0;
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c	Thu Feb 26 07:05:00 2004
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Tue Apr 27 01:00:14 2004
@@ -80,8 +80,10 @@
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
 #ifdef CONFIG_SERIAL_8250
+	vr41xx_siu_init();
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+
 	vr41xx_dsiu_init();
-	vr41xx_siu_init(SIU_RS232C, 0);
 #endif
 
 #ifdef CONFIG_PCI
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Thu Feb 26 00:23:50 2004
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	Tue Apr 27 01:01:10 2004
@@ -83,7 +83,10 @@
 	ioport_resource.start = IO_PORT_RESOURCE_START;
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
-	vr41xx_siu_init(SIU_RS232C, 0);
+#ifdef CONFIG_SERIAL_8250
+	vr41xx_siu_init();
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+#endif
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c	Thu Feb 26 00:23:50 2004
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Tue Apr 27 01:02:03 2004
@@ -87,8 +87,12 @@
 	ioport_resource.start = IO_PORT_RESOURCE_START;
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
-	vr41xx_siu_init(SIU_RS232C, 0);
+#ifdef CONFIG_SERIAL_8250
+	vr41xx_siu_init();
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+
 	vr41xx_dsiu_init();
+#endif
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Thu Feb 26 00:23:50 2004
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Tue Apr 27 01:03:24 2004
@@ -84,7 +84,8 @@
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
 #ifdef CONFIG_SERIAL_8250
-	vr41xx_siu_init(SIU_RS232C, 0);
+	vr41xx_siu_init();
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
 #endif
 
 #ifdef CONFIG_PCI
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux-orig/arch/mips/vr41xx/zao-capcella/setup.c	Thu Feb 26 00:23:50 2004
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Tue Apr 27 01:02:50 2004
@@ -84,7 +84,9 @@
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
 #ifdef CONFIG_SERIAL_8250
-	vr41xx_siu_init(SIU_RS232C, 0);
+	vr41xx_siu_init();
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+
 	vr41xx_dsiu_init();
 #endif
 
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux-orig/include/asm-mips/vr41xx/vr41xx.h	Thu Feb 26 07:05:01 2004
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Tue Apr 27 00:56:17 2004
@@ -136,6 +136,9 @@
 extern int vr41xx_set_intassign(unsigned int irq, unsigned char intassign);
 extern int vr41xx_cascade_irq(unsigned int irq, int (*get_irq_number)(int irq));
 
+extern void vr41xx_enable_dsiuint(void);
+extern void vr41xx_disable_dsiuint(void);
+
 /*
  * Power Management Unit
  */
@@ -189,22 +192,25 @@
 /*
  * Serial Interface Unit
  */
-extern void vr41xx_siu_init(int interface, int module);
-extern void vr41xx_siu_ifselect(int interface, int module);
+extern void vr41xx_siu_init(void);
 extern int vr41xx_serial_ports;
 
 /* SIU interfaces */
-enum {
+typedef enum {
 	SIU_RS232C,
 	SIU_IRDA
-};
+} siu_interface_t;
 
 /* IrDA interfaces */
-enum {
-	IRDA_SHARP = 1,
+typedef enum {
+	IRDA_NONE,
+	IRDA_SHARP,
 	IRDA_TEMIC,
 	IRDA_HP
-};
+} irda_module_t;
+
+extern void vr41xx_select_siu_interface(siu_interface_t interface,
+                                        irda_module_t module);
 
 /*
  * Debug Serial Interface Unit

From damian@clown-fish.com Mon Apr 26 21:05:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Apr 2004 21:05:25 +0100 (BST)
Received: from host-212-158-214-243.bulldogdsl.com ([IPv6:::ffff:212.158.214.243]:46858
	"EHLO megablaster5.clown-smart.co.uk") by linux-mips.org with ESMTP
	id <S8226002AbUDZUFY>; Mon, 26 Apr 2004 21:05:24 +0100
Received: from [127.0.0.1] (host-212-158-214-244.bulldogdsl.com [212.158.214.244])
	by megablaster5.clown-smart.co.uk (Postfix) with ESMTP id EBCEA45F11
	for <linux-mips@linux-mips.org>; Mon, 26 Apr 2004 21:16:39 +0100 (BST)
Message-ID: <408D6BFC.6030902@clown-fish.com>
Date: Mon, 26 Apr 2004 21:07:24 +0100
From: Damian Presswell <damian@clown-fish.com>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040426)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Linux Mips SGI O2 R5000 IP32 INSTALL
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <damian@clown-fish.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4902
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: damian@clown-fish.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1007
Lines: 26

My apologies if this is the wrong mailing list for this question -

I have recently aquired an SGI  O2 ip32 R5k box that I am trying to 
install linux onto -

I have managed to get a binary 64bit kernel to boot vis nfs and bootp() 
that I downloaded from Glaurungs website:

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

however I am unsure as to the correct rootfs that I am suposed to use - 
I pulled down the redhat 7.1 rootfs from somewhere but it hangs when 
trying to start the 'local' service - and wont boot if this service is 
switched off -

I would be grateful if you could suggest where I may download a suitable 
rootfs and ecoff boot image that will work together on my O2 box - would 
hate to give in at this stage - and indeed any other help you may be 
able to give me as a linux mips O2 user - I will put together an updated 
HOWTO once I am sure exactly what I am supposed to be doing - the 
information and resources on this subject do seem to be a little vague -

thanks for your time

Damian


From damian@clown-fish.com Mon Apr 26 21:52:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Apr 2004 21:52:35 +0100 (BST)
Received: from host-212-158-214-243.bulldogdsl.com ([IPv6:::ffff:212.158.214.243]:49674
	"EHLO megablaster5.clown-smart.co.uk") by linux-mips.org with ESMTP
	id <S8226002AbUDZUwc>; Mon, 26 Apr 2004 21:52:32 +0100
Received: from [127.0.0.1] (host-212-158-214-244.bulldogdsl.com [212.158.214.244])
	by megablaster5.clown-smart.co.uk (Postfix) with ESMTP id 5D9C442273
	for <linux-mips@linux-mips.org>; Mon, 26 Apr 2004 22:03:49 +0100 (BST)
Message-ID: <408D7709.6060600@clown-fish.com>
Date: Mon, 26 Apr 2004 21:54:33 +0100
From: Damian Presswell <damian@clown-fish.com>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040426)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: [Fwd: Linux Mips SGI O2 R5000 IP32 INSTALL]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <damian@clown-fish.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4903
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: damian@clown-fish.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1009
Lines: 28

My apologies if this is the wrong mailing list for this question -

I have recently aquired an SGI  O2 ip32 R5k box that I am trying to 
install linux onto -

I have managed to get a binary 64bit kernel to boot vis nfs and bootp() 
that I downloaded from Glaurungs website:

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

however I am unsure as to the correct rootfs that I am suposed to use - 
I pulled down the redhat 7.1 rootfs from somewhere but it hangs when 
trying to start the 'local' service - and wont boot if this service is 
switched off -

I would be grateful if you could suggest where I may download a suitable 
rootfs and ecoff boot image that will work together on my O2 box - would 
hate to give in at this stage - and indeed any other help you may be 
able to give me as a linux mips O2 user - I will put together an updated 
HOWTO once I am sure exactly what I am supposed to be doing - the 
information and resources on this subject do seem to be a little vague -

thanks for your time

Damian




From ilya@gateway.total-knowledge.com Mon Apr 26 23:24:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Apr 2004 23:24:48 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:17595
	"EHLO alpha.total-knowledge.com") by linux-mips.org with ESMTP
	id <S8226007AbUDZWYq>; Mon, 26 Apr 2004 23:24:46 +0100
Received: (qmail 13080 invoked from network); 26 Apr 2004 15:24:42 -0700
Received: from c-67-169-17-108.client.comcast.net (HELO gateway.total-knowledge.com) (67.169.17.108)
  by alpha.total-knowledge.com with SMTP; 26 Apr 2004 15:24:42 -0700
Received: (qmail 14523 invoked by uid 502); 26 Apr 2004 15:24:41 -0700
Date: Mon, 26 Apr 2004 15:24:41 -0700
From: ilya@theIlya.com
To: Damian Presswell <damian@clown-fish.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Linux Mips SGI O2 R5000 IP32 INSTALL
Message-ID: <20040426222441.GC1276@gateway.total-knowledge.com>
References: <408D6BFC.6030902@clown-fish.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <408D6BFC.6030902@clown-fish.com>
User-Agent: Mutt/1.5.6i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4904
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1301
Lines: 35

Use Gentoo.
Also, Glaurung's kernels are bit out-od-date. Use self-built
kernel from recent linux-mips.org CVS. In worst case, use
one of Gentoo's kernel binaries.

	Ilya.

On Mon, Apr 26, 2004 at 09:07:24PM +0100, Damian Presswell wrote:
> My apologies if this is the wrong mailing list for this question -
> 
> I have recently aquired an SGI  O2 ip32 R5k box that I am trying to 
> install linux onto -
> 
> I have managed to get a binary 64bit kernel to boot vis nfs and bootp() 
> that I downloaded from Glaurungs website:
> 
> http://www.linux-mips.org/~glaurung/
> 
> however I am unsure as to the correct rootfs that I am suposed to use - 
> I pulled down the redhat 7.1 rootfs from somewhere but it hangs when 
> trying to start the 'local' service - and wont boot if this service is 
> switched off -
> 
> I would be grateful if you could suggest where I may download a suitable 
> rootfs and ecoff boot image that will work together on my O2 box - would 
> hate to give in at this stage - and indeed any other help you may be 
> able to give me as a linux mips O2 user - I will put together an updated 
> HOWTO once I am sure exactly what I am supposed to be doing - the 
> information and resources on this subject do seem to be a little vague -
> 
> thanks for your time
> 
> Damian
> 
> 

From jsun@orion.mvista.com Tue Apr 27 02:59:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Apr 2004 02:59:37 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:52981 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8226016AbUD0B7g>;
	Tue, 27 Apr 2004 02:59:36 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i3R1xWx6028466;
	Mon, 26 Apr 2004 18:59:32 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i3R1xWHN028464;
	Mon, 26 Apr 2004 18:59:32 -0700
Date: Mon, 26 Apr 2004 18:59:32 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org,
	high-res-timers-discourse@lists.sourceforge.net
Cc: jsun@mvista.com
Subject: [EXPERIMENTAL] 2.6 high resolution timer (HRT) support for MIPS
Message-ID: <20040426185932.L19558@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4906
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 798
Lines: 20


This set of patches add high resolution posix timer support.  
You need to apply patches in the following order:

http://linux.junsun.net/patches/oss.sgi.com/experimental/040419.a-cpu-timer.patch
http://linux.junsun.net/patches/oss.sgi.com/experimental/040420.a-cpu-timer-for-smp.patch
http://linux.junsun.net/patches/oss.sgi.com/experimental/040426.a-hrtimers-2.6.5-1.0.patch
http://linux.junsun.net/patches/oss.sgi.com/experimental/040426.b-mips-hrt-2.6.patch

These patches are tested on NEC Rockhopper boards and Broadcom
bcm1250 boards (in SMP mode) against linux-mips.org CVS tree
around April 20, 2004 (kernel 2.6.5).

If you want HRT working on other boards, you need

        a) make sure the board is uing cpu timer as system timer
        b) enable CONFIG_CPU_TIMER for the board

Jun


From aluba1231.tw@yahoo.com.tw Tue Apr 27 10:11:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Apr 2004 10:11:21 +0100 (BST)
Received: from web17015.mail.tpe.yahoo.com ([IPv6:::ffff:202.1.236.166]:58788
	"HELO web17015.mail.tpe.yahoo.com") by linux-mips.org with SMTP
	id <S8226025AbUD0JLT>; Tue, 27 Apr 2004 10:11:19 +0100
Message-ID: <20040427091110.53701.qmail@web17015.mail.tpe.yahoo.com>
Received: from [210.243.228.66] by web17015.mail.tpe.yahoo.com via HTTP; Tue, 27 Apr 2004 17:11:10 CST
Date: Tue, 27 Apr 2004 17:11:10 +0800 (CST)
From: "=?big5?q?aluba1231.tw?=" <aluba1231.tw@yahoo.com.tw>
Subject: nfs server on mips platform?
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Return-Path: <aluba1231.tw@yahoo.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: 4907
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aluba1231.tw@yahoo.com.tw
Precedence: bulk
X-list: linux-mips
Content-Length: 7332
Lines: 232


ading cache ./config.cache
checking for gcc... (cached) mipsel-uclibc-gcc
checking whether the C compiler (mipsel-uclibc-gcc  )
works... yes
checking whether the C compiler (mipsel-uclibc-gcc  )
is a cross-compiler... yes
checking whether we are using GNU C... (cached) yes
checking whether mipsel-uclibc-gcc accepts -g...
(cached) yes
checking how to run the C preprocessor... (cached)
mipsel-uclibc-gcc -E
checking for a BSD compatible install... (cached)
/usr/bin/install -c
checking host system type... ./config.guess: line 941:
./dummy-4248: cannot execute binary file
i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for ranlib... (cached) mipsel-uclibc-ranlib
checking for ar... (cached) mipsel-uclibc-ar
checking for ld... (cached) mipsel-uclibc-ld
checking for ANSI C header files... (cached) yes
checking for GNU libc2... (cached) yes
checking for main in -lsocket... (cached) no
checking for main in -lnsl... (cached) yes
checking for crypt in -lcrypt... (cached) yes
checking for the tcp wrapper library... (cached) no
checking for innetgr... (cached) no
creating ./config.status
creating config.mk
creating nfs-utils.spec
creating utils/Makefile
creating support/include/config.h
support/include/config.h is unchanged
Making all in tools
Making all in rpcgen
Building rpcgen done.
Making all in getiversion
Building getiversion done.
Making all in getkversion
Building getkversion done.
Making all in rpcdebug
Building rpcdebug done.
Making all in locktest
Building testlk done.
Making all in support
Making all in include
Making all in nfs
Building libnfs.a done.
Making all in export
Building libexport.a done.
Making all in lib
Making all in misc
Building libmisc.a done.
Making all in utils
Making all in exportfs
Building exportfs done.
Making all in mountd
mipsel-uclibc-gcc  -L../../support/lib -o mountd
mountd.o mount_dispatch.o auth.o rmtab.o cache.o
svc_run.o -lexport -lnfs -lmisc   -lnsl
mountd.o: In function `killer':
mountd.o(.text+0xcc): undefined reference to
`pmap_unset'
mountd.o(.text+0xf0): undefined reference to
`pmap_unset'
mountd.o(.text+0x12c): undefined reference to
`pmap_unset'
mount_dispatch.o(.data+0x8): undefined reference to
`xdr_void'
mount_dispatch.o(.data+0x10): undefined reference to
`xdr_void'
mount_dispatch.o(.data+0x38): undefined reference to
`xdr_void'
mount_dispatch.o(.data+0x58): undefined reference to
`xdr_void'
mount_dispatch.o(.data+0x68): undefined reference to
`xdr_void'
mount_dispatch.o(.data+0x70): more undefined
references to `xdr_void' follow
svc_run.o: In function `my_svc_run':
svc_run.o(.text+0x3c): undefined reference to
`__rpc_thread_svc_fdset'
svc_run.o(.text+0x130): undefined reference to
`svc_getreqset'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_fhandle':
mount_xdr.o(.text+0x20): undefined reference to
`xdr_opaque'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_fhstatus':
mount_xdr.o(.text+0x7c): undefined reference to
`xdr_u_int'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_dirpath':
mount_xdr.o(.text+0x12c): undefined reference to
`xdr_string'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_name':
mount_xdr.o(.text+0x17c): undefined reference to
`xdr_string'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_mountlist':
mount_xdr.o(.text+0x1d0): undefined reference to
`xdr_pointer'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_groups':
mount_xdr.o(.text+0x2f0): undefined reference to
`xdr_pointer'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_exports':
mount_xdr.o(.text+0x3e4): undefined reference to
`xdr_pointer'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_ppathcnf':
mount_xdr.o(.text+0x548): undefined reference to
`xdr_int'
mount_xdr.o(.text+0x5b4): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x5e4): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x614): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x644): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x674): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x6a4): undefined reference to
`xdr_u_char'
mount_xdr.o(.text+0x6d4): undefined reference to
`xdr_char'
mount_xdr.o(.text+0x708): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x714): undefined reference to
`xdr_vector'
mount_xdr.o(.text+0x840): undefined reference to
`xdr_u_char'
mount_xdr.o(.text+0x870): undefined reference to
`xdr_char'
mount_xdr.o(.text+0x934): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x944): undefined reference to
`xdr_vector'
mount_xdr.o(.text+0x980): undefined reference to
`xdr_int'
mount_xdr.o(.text+0x9b0): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x9e0): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xa10): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xa40): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xa70): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xc14): undefined reference to
`xdr_u_char'
mount_xdr.o(.text+0xc44): undefined reference to
`xdr_char'
mount_xdr.o(.text+0xd28): undefined reference to
`xdr_int'
mount_xdr.o(.text+0xd58): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xd88): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xdb8): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xde8): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xe18): undefined reference to
`xdr_short'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_fhandle3':
mount_xdr.o(.text+0xe70): undefined reference to
`xdr_bytes'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_mountstat3':
mount_xdr.o(.text+0xebc): undefined reference to
`xdr_enum'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_mountres3_ok':
mount_xdr.o(.text+0xf5c): undefined reference to
`xdr_int'
mount_xdr.o(.text+0xf7c): undefined reference to
`xdr_array'
../../support/lib/libnfs.a(rpcmisc.o): In function
`rpc_init':
rpcmisc.o(.text+0xa4): undefined reference to
`pmap_unset'
rpcmisc.o(.text+0x164): undefined reference to
`svcudp_create'
rpcmisc.o(.text+0x1a0): undefined reference to
`svc_register'
rpcmisc.o(.text+0x328): undefined reference to
`svctcp_create'
rpcmisc.o(.text+0x364): undefined reference to
`svc_register'
../../support/lib/libnfs.a(rpcmisc.o): In function
`closedown':
rpcmisc.o(.text+0x788): undefined reference to
`__rpc_thread_svc_fdset'
../../support/lib/libnfs.a(rpcdispatch.o): In function
`rpc_dispatch':
rpcdispatch.o(.text+0xa0): undefined reference to
`svcerr_noproc'
rpcdispatch.o(.text+0x15c): undefined reference to
`svcerr_decode'
rpcdispatch.o(.text+0x1c0): undefined reference to
`svc_sendreply'
rpcdispatch.o(.text+0x228): undefined reference to
`svcerr_systemerr'
rpcdispatch.o(.text+0x258): undefined reference to
`svcerr_progvers'
../../support/lib/libnfs.a(svc_socket.o): In function
`svc_socket':
svc_socket.o(.text+0xec): undefined reference to
`__bzero'
svc_socket.o(.text+0x124): undefined reference to
`getrpcbynumber_r'
svc_socket.o(.text+0x194): undefined reference to
`bindresvport'
collect2: ld returned 1 exit status
make[3]: *** [mountd] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all] Error 2



-----------------------------------------------------------------
§Ûªñ¸ô¡I¡IEmail³B³B¦¬¡I
§K¶O¤U¸üYahoo!©_¼¯±¶®|¦C
http://tw.companion.yahoo.com/

From aluba1231.tw@yahoo.com.tw Tue Apr 27 10:46:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Apr 2004 10:46:30 +0100 (BST)
Received: from web17001.mail.tpe.yahoo.com ([IPv6:::ffff:202.1.236.222]:7027
	"HELO web17001.mail.tpe.yahoo.com") by linux-mips.org with SMTP
	id <S8226025AbUD0Jq2>; Tue, 27 Apr 2004 10:46:28 +0100
Message-ID: <20040427094618.39988.qmail@web17001.mail.tpe.yahoo.com>
Received: from [210.243.228.66] by web17001.mail.tpe.yahoo.com via HTTP; Tue, 27 Apr 2004 17:46:18 CST
Date: Tue, 27 Apr 2004 17:46:18 +0800 (CST)
From: "=?big5?q?aluba1231.tw?=" <aluba1231.tw@yahoo.com.tw>
Subject: nfs server on mips platform? 
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Return-Path: <aluba1231.tw@yahoo.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: 4908
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aluba1231.tw@yahoo.com.tw
Precedence: bulk
X-list: linux-mips
Content-Length: 7747
Lines: 246

Hi All,
 I am trying to set up a nfs server on the mipsel
platform. I got the nfs-utils package and did
configure/make  with cross compiling by
mipsel-uclibc-gcc, but It failed while making. Because
the tools rpcgen is also built to mips format. I tried
to revise the Makefile to build rpcgen in x86 format,
but it caused functions undefined reference problem.
Below is the meessage of making.
 
Thanks,
Michael

ading cache ./config.cache
checking for gcc... (cached) mipsel-uclibc-gcc
checking whether the C compiler (mipsel-uclibc-gcc  )
works... yes
checking whether the C compiler (mipsel-uclibc-gcc  )
is a cross-compiler... yes
checking whether we are using GNU C... (cached) yes
checking whether mipsel-uclibc-gcc accepts -g...
(cached) yes
checking how to run the C preprocessor... (cached)
mipsel-uclibc-gcc -E
checking for a BSD compatible install... (cached)
/usr/bin/install -c
checking host system type... ./config.guess: line 941:
./dummy-4248: cannot execute binary file
i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for ranlib... (cached) mipsel-uclibc-ranlib
checking for ar... (cached) mipsel-uclibc-ar
checking for ld... (cached) mipsel-uclibc-ld
checking for ANSI C header files... (cached) yes
checking for GNU libc2... (cached) yes
checking for main in -lsocket... (cached) no
checking for main in -lnsl... (cached) yes
checking for crypt in -lcrypt... (cached) yes
checking for the tcp wrapper library... (cached) no
checking for innetgr... (cached) no
creating ./config.status
creating config.mk
creating nfs-utils.spec
creating utils/Makefile
creating support/include/config.h
support/include/config.h is unchanged
Making all in tools
Making all in rpcgen
Building rpcgen done.
Making all in getiversion
Building getiversion done.
Making all in getkversion
Building getkversion done.
Making all in rpcdebug
Building rpcdebug done.
Making all in locktest
Building testlk done.
Making all in support
Making all in include
Making all in nfs
Building libnfs.a done.
Making all in export
Building libexport.a done.
Making all in lib
Making all in misc
Building libmisc.a done.
Making all in utils
Making all in exportfs
Building exportfs done.
Making all in mountd
mipsel-uclibc-gcc  -L../../support/lib -o mountd
mountd.o mount_dispatch.o auth.o rmtab.o cache.o
svc_run.o -lexport -lnfs -lmisc   -lnsl
mountd.o: In function `killer':
mountd.o(.text+0xcc): undefined reference to
`pmap_unset'
mountd.o(.text+0xf0): undefined reference to
`pmap_unset'
mountd.o(.text+0x12c): undefined reference to
`pmap_unset'
mount_dispatch.o(.data+0x8): undefined reference to
`xdr_void'
mount_dispatch.o(.data+0x10): undefined reference to
`xdr_void'
mount_dispatch.o(.data+0x38): undefined reference to
`xdr_void'
mount_dispatch.o(.data+0x58): undefined reference to
`xdr_void'
mount_dispatch.o(.data+0x68): undefined reference to
`xdr_void'
mount_dispatch.o(.data+0x70): more undefined
references to `xdr_void' follow
svc_run.o: In function `my_svc_run':
svc_run.o(.text+0x3c): undefined reference to
`__rpc_thread_svc_fdset'
svc_run.o(.text+0x130): undefined reference to
`svc_getreqset'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_fhandle':
mount_xdr.o(.text+0x20): undefined reference to
`xdr_opaque'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_fhstatus':
mount_xdr.o(.text+0x7c): undefined reference to
`xdr_u_int'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_dirpath':
mount_xdr.o(.text+0x12c): undefined reference to
`xdr_string'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_name':
mount_xdr.o(.text+0x17c): undefined reference to
`xdr_string'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_mountlist':
mount_xdr.o(.text+0x1d0): undefined reference to
`xdr_pointer'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_groups':
mount_xdr.o(.text+0x2f0): undefined reference to
`xdr_pointer'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_exports':
mount_xdr.o(.text+0x3e4): undefined reference to
`xdr_pointer'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_ppathcnf':
mount_xdr.o(.text+0x548): undefined reference to
`xdr_int'
mount_xdr.o(.text+0x5b4): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x5e4): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x614): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x644): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x674): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x6a4): undefined reference to
`xdr_u_char'
mount_xdr.o(.text+0x6d4): undefined reference to
`xdr_char'
mount_xdr.o(.text+0x708): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x714): undefined reference to
`xdr_vector'
mount_xdr.o(.text+0x840): undefined reference to
`xdr_u_char'
mount_xdr.o(.text+0x870): undefined reference to
`xdr_char'
mount_xdr.o(.text+0x934): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x944): undefined reference to
`xdr_vector'
mount_xdr.o(.text+0x980): undefined reference to
`xdr_int'
mount_xdr.o(.text+0x9b0): undefined reference to
`xdr_short'
mount_xdr.o(.text+0x9e0): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xa10): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xa40): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xa70): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xc14): undefined reference to
`xdr_u_char'
mount_xdr.o(.text+0xc44): undefined reference to
`xdr_char'
mount_xdr.o(.text+0xd28): undefined reference to
`xdr_int'
mount_xdr.o(.text+0xd58): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xd88): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xdb8): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xde8): undefined reference to
`xdr_short'
mount_xdr.o(.text+0xe18): undefined reference to
`xdr_short'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_fhandle3':
mount_xdr.o(.text+0xe70): undefined reference to
`xdr_bytes'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_mountstat3':
mount_xdr.o(.text+0xebc): undefined reference to
`xdr_enum'
../../support/lib/libexport.a(mount_xdr.o): In
function `xdr_mountres3_ok':
mount_xdr.o(.text+0xf5c): undefined reference to
`xdr_int'
mount_xdr.o(.text+0xf7c): undefined reference to
`xdr_array'
../../support/lib/libnfs.a(rpcmisc.o): In function
`rpc_init':
rpcmisc.o(.text+0xa4): undefined reference to
`pmap_unset'
rpcmisc.o(.text+0x164): undefined reference to
`svcudp_create'
rpcmisc.o(.text+0x1a0): undefined reference to
`svc_register'
rpcmisc.o(.text+0x328): undefined reference to
`svctcp_create'
rpcmisc.o(.text+0x364): undefined reference to
`svc_register'
../../support/lib/libnfs.a(rpcmisc.o): In function
`closedown':
rpcmisc.o(.text+0x788): undefined reference to
`__rpc_thread_svc_fdset'
../../support/lib/libnfs.a(rpcdispatch.o): In function
`rpc_dispatch':
rpcdispatch.o(.text+0xa0): undefined reference to
`svcerr_noproc'
rpcdispatch.o(.text+0x15c): undefined reference to
`svcerr_decode'
rpcdispatch.o(.text+0x1c0): undefined reference to
`svc_sendreply'
rpcdispatch.o(.text+0x228): undefined reference to
`svcerr_systemerr'
rpcdispatch.o(.text+0x258): undefined reference to
`svcerr_progvers'
../../support/lib/libnfs.a(svc_socket.o): In function
`svc_socket':
svc_socket.o(.text+0xec): undefined reference to
`__bzero'
svc_socket.o(.text+0x124): undefined reference to
`getrpcbynumber_r'
svc_socket.o(.text+0x194): undefined reference to
`bindresvport'
collect2: ld returned 1 exit status
make[3]: *** [mountd] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all] Error 2


 


-----------------------------------------------------------------
§Ûªñ¸ô¡I¡IEmail³B³B¦¬¡I
§K¶O¤U¸üYahoo!©_¼¯±¶®|¦C
http://tw.companion.yahoo.com/

From yuasa@hh.iij4u.or.jp Tue Apr 27 12:47:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Apr 2004 12:47:25 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:17899 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226033AbUD0LrW>;
	Tue, 27 Apr 2004 12:47:22 +0100
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id UAA25731;
	Tue, 27 Apr 2004 20:47:18 +0900 (JST)
Received: 4UMDO01 id i3RBlHh28405; Tue, 27 Apr 2004 20:47:17 +0900 (JST)
Received: 4UMRO00 id i3RBlGj18866; Tue, 27 Apr 2004 20:47:17 +0900 (JST)
	from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Tue, 27 Apr 2004 20:47:16 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: [PATCH Update][2.6] Fixes serial setup fot vr41xx
Message-Id: <20040427204716.1b6114f2.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20040427014039.102fdb50.yuasa@hh.iij4u.or.jp>
References: <20040427014039.102fdb50.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4909
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 13301
Lines: 400

Hello Ralf,

I sent a patch to you yesterday. it had still problem.
Please apply new patch to CVS.

This patch fixes the serial setup for vr41xx.

Thanks,

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux-orig/arch/mips/vr41xx/casio-e55/setup.c	2004-02-25 12:12:07.000000000 +0900
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	2004-04-27 20:35:28.000000000 +0900
@@ -35,7 +35,8 @@
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
 #ifdef CONFIG_SERIAL_8250
-	vr41xx_siu_init(SIU_RS232C, 0);
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+	vr41xx_siu_init();
 #endif
 
 	return 0;
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux-orig/arch/mips/vr41xx/common/icu.c	2004-01-13 10:42:26.000000000 +0900
+++ linux/arch/mips/vr41xx/common/icu.c	2004-04-27 20:35:29.000000000 +0900
@@ -1,34 +1,23 @@
 /*
- * FILE NAME
- *	arch/mips/vr41xx/common/icu.c
+ *  icu.c, Interrupt Control Unit routines for the NEC VR4100 series.
  *
- * BRIEF MODULE DESCRIPTION
- *	Interrupt Control Unit routines for the NEC VR4100 series.
+ *  Copyright (C) 2001-2002  MontaVista Software Inc.
+ *    Author: Yoichi Yuasa <yyuasa@mvista.com or source@mvista.com>
+ *  Copyright (C) 2003-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
- * Author: Yoichi Yuasa
- *         yyuasa@mvista.com or source@mvista.com
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
  *
- * Copyright 2001,2002 MontaVista Software Inc.
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
  *
- *  This program is free software; you can redistribute it and/or modify it
- *  under the terms of the GNU General Public License as published by the
- *  Free Software Foundation; either version 2 of the License, or (at your
- *  option) any later version.
- *
- *  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
- *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
- *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
- *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
- *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- *  You should have received a copy of the GNU General Public License along
- *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  675 Mass Ave, Cambridge, MA 02139, USA.
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 /*
  * Changes:
@@ -90,6 +79,9 @@
 #define MSYSINT2REG	0x06
 #define MGIUINTHREG	0x08
 
+#define MDSIUINTREG	KSEG1ADDR(0x0f000096)
+ #define INTDSIU	0x0800
+
 #define SYSINT1_IRQ_TO_PIN(x)	((x) - SYSINT1_IRQ_BASE)	/* Pin 0-15 */
 #define SYSINT2_IRQ_TO_PIN(x)	((x) - SYSINT2_IRQ_BASE)	/* Pin 0-15 */
 
@@ -148,6 +140,18 @@
 
 /*=======================================================================*/
 
+void vr41xx_enable_dsiuint(void)
+{
+	writew(INTDSIU, MDSIUINTREG);
+}
+
+void vr41xx_disable_dsiuint(void)
+{
+	writew(0, MDSIUINTREG);
+}
+
+/*=======================================================================*/
+
 static void enable_sysint1_irq(unsigned int irq)
 {
 	set_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq));
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux-orig/arch/mips/vr41xx/common/serial.c	2004-02-25 12:12:07.000000000 +0900
+++ linux/arch/mips/vr41xx/common/serial.c	2004-04-27 20:35:30.000000000 +0900
@@ -40,14 +40,8 @@
 #include <asm/io.h>
 #include <asm/vr41xx/vr41xx.h>
 
-/* VR4111 and VR4121 SIU Registers */
-#define SIURB_TYPE1		KSEG1ADDR(0x0c000000)
 #define SIUIRSEL_TYPE1		KSEG1ADDR(0x0c000008)
-
-/* VR4122, VR4131 and VR4133 SIU Registers */
-#define SIURB_TYPE2		KSEG1ADDR(0x0f000800)
 #define SIUIRSEL_TYPE2		KSEG1ADDR(0x0f000808)
-
  #define USE_RS232C		0x00
  #define USE_IRDA		0x01
  #define SIU_USES_IRDA		0x00
@@ -58,21 +52,24 @@
  #define TMICTX			0x10
  #define TMICMODE		0x20
 
-#define SIU_BASE_BAUD		1152000
+#define SIU_BASE_TYPE1		0x0c000000UL	/* VR4111 and VR4121 */
+#define SIU_BASE_TYPE2		0x0f000800UL	/* VR4122, VR4131 and VR4133 */
+#define SIU_SIZE		0x8UL
 
-/* VR4122 and VR4131 DSIU Registers */
-#define DSIURB			KSEG1ADDR(0x0f000820)
+#define SIU_BASE_BAUD		1152000
 
-#define MDSIUINTREG		KSEG1ADDR(0x0f000096)
- #define INTDSIU		0x0800
+/* VR4122, VR4131 and VR4133 DSIU Registers */
+#define DSIU_BASE		0x0f000820UL
+#define DSIU_SIZE		0x8UL
 
 #define DSIU_BASE_BAUD		1152000
 
 int vr41xx_serial_ports = 0;
 
-void vr41xx_siu_ifselect(int interface, int module)
+void vr41xx_select_siu_interface(siu_interface_t interface,
+                                 irda_module_t module)
 {
-	u16 val = USE_RS232C;	/* Select RS-232C */
+	uint16_t val = USE_RS232C;	/* Select RS-232C */
 
 	/* Select IrDA */
 	if (interface == SIU_IRDA) {
@@ -86,6 +83,9 @@
 		case IRDA_HP:
 			val = IRDA_MODULE_HP;
 			break;
+		default:
+			printk(KERN_ERR "SIU: unknown IrDA module\n");
+			return;
 		}
 		val |= USE_IRDA | SIU_USES_IRDA;
 	}
@@ -101,45 +101,47 @@
 		writew(val, SIUIRSEL_TYPE2);
 		break;
 	default:
-		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
+		printk(KERN_ERR "SIU: unsupported CPU of NEC VR4100 series\n");
 		break;
 	}
 }
 
-void __init vr41xx_siu_init(int interface, int module)
+void __init vr41xx_siu_init(void)
 {
 	struct uart_port port;
 
-	vr41xx_siu_ifselect(interface, module);
-
 	memset(&port, 0, sizeof(port));
 
 	port.line = vr41xx_serial_ports;
-	port.uartclk = SIU_BASE_BAUD;
+	port.uartclk = SIU_BASE_BAUD * 16;
 	port.irq = SIU_IRQ;
-	port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
+	port.flags = UPF_RESOURCES | UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		port.membase = (char *)SIURB_TYPE1;
+		port.mapbase = SIU_BASE_TYPE1;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		port.membase = (char *)SIURB_TYPE2;
+		port.mapbase = SIU_BASE_TYPE2;
 		break;
 	default:
-		panic("Unexpected CPU of NEC VR4100 series");
-		break;
+		printk(KERN_ERR "SIU: unsupported CPU of NEC VR4100 series\n");
+		return;
 	}
 	port.regshift = 0;
 	port.iotype = UPIO_MEM;
-	if (early_serial_setup(&port) != 0)
-		printk(KERN_ERR "SIU setup failed!\n");
-
-	vr41xx_supply_clock(SIU_CLOCK);
+	port.membase = ioremap(port.mapbase, SIU_SIZE);
+	if (port.membase != NULL) {
+		if (early_serial_setup(&port) == 0) {
+			vr41xx_supply_clock(SIU_CLOCK);
+			vr41xx_serial_ports++;
+			return;
+		}
+	}
 
-	vr41xx_serial_ports++;
+	printk(KERN_ERR "SIU: setup failed!\n");
 }
 
 void __init vr41xx_dsiu_init(void)
@@ -148,24 +150,29 @@
 
 	if (current_cpu_data.cputype != CPU_VR4122 &&
 	    current_cpu_data.cputype != CPU_VR4131 &&
-	    current_cpu_data.cputype != CPU_VR4133)
+	    current_cpu_data.cputype != CPU_VR4133) {
+		printk(KERN_ERR "DSIU: unsupported CPU of NEC VR4100 series\n");
 		return;
+	}
 
 	memset(&port, 0, sizeof(port));
 
 	port.line = vr41xx_serial_ports;
-	port.uartclk = DSIU_BASE_BAUD;
+	port.uartclk = DSIU_BASE_BAUD * 16;
 	port.irq = DSIU_IRQ;
-	port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
-	port.membase = (char *)DSIURB;
+	port.flags = UPF_RESOURCES | UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
+	port.mapbase = DSIU_BASE;
 	port.regshift = 0;
 	port.iotype = UPIO_MEM;
-	if (early_serial_setup(&port) != 0)
-		printk(KERN_ERR "DSIU setup failed!\n");
-
-	vr41xx_supply_clock(DSIU_CLOCK);
-
-	writew(INTDSIU, MDSIUINTREG);
+	port.membase = ioremap(port.mapbase, DSIU_SIZE);
+	if (port.membase != NULL) {
+		if (early_serial_setup(&port) == 0) {
+			vr41xx_supply_clock(DSIU_CLOCK);
+			vr41xx_enable_dsiuint();
+			vr41xx_serial_ports++;
+			return;
+		}
+	}
 
-	vr41xx_serial_ports++;
+	printk(KERN_ERR "DSIU: setup failed!\n");
 }
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c	2004-02-25 12:12:07.000000000 +0900
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	2004-04-27 20:35:30.000000000 +0900
@@ -35,7 +35,8 @@
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
 #ifdef CONFIG_SERIAL_8250
-	vr41xx_siu_init(SIU_RS232C, 0);
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+	vr41xx_siu_init();
 #endif
 
 	return 0;
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c	2004-02-26 10:39:18.000000000 +0900
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	2004-04-27 20:35:30.000000000 +0900
@@ -80,8 +80,9 @@
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
 #ifdef CONFIG_SERIAL_8250
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+	vr41xx_siu_init();
 	vr41xx_dsiu_init();
-	vr41xx_siu_init(SIU_RS232C, 0);
 #endif
 
 #ifdef CONFIG_PCI
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	2004-02-25 12:12:07.000000000 +0900
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	2004-04-27 20:35:30.000000000 +0900
@@ -83,7 +83,10 @@
 	ioport_resource.start = IO_PORT_RESOURCE_START;
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
-	vr41xx_siu_init(SIU_RS232C, 0);
+#ifdef CONFIG_SERIAL_8250
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+	vr41xx_siu_init();
+#endif
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c	2004-02-25 12:12:07.000000000 +0900
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	2004-04-27 20:35:30.000000000 +0900
@@ -87,8 +87,11 @@
 	ioport_resource.start = IO_PORT_RESOURCE_START;
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
-	vr41xx_siu_init(SIU_RS232C, 0);
+#ifdef CONFIG_SERIAL_8250
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+	vr41xx_siu_init();
 	vr41xx_dsiu_init();
+#endif
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c	2004-02-25 12:12:07.000000000 +0900
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	2004-04-27 20:35:30.000000000 +0900
@@ -84,7 +84,8 @@
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
 #ifdef CONFIG_SERIAL_8250
-	vr41xx_siu_init(SIU_RS232C, 0);
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+	vr41xx_siu_init();
 #endif
 
 #ifdef CONFIG_PCI
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux-orig/arch/mips/vr41xx/zao-capcella/setup.c	2004-02-25 12:12:07.000000000 +0900
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	2004-04-27 20:35:31.000000000 +0900
@@ -84,7 +84,8 @@
 	ioport_resource.end = IO_PORT_RESOURCE_END;
 
 #ifdef CONFIG_SERIAL_8250
-	vr41xx_siu_init(SIU_RS232C, 0);
+	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
+	vr41xx_siu_init();
 	vr41xx_dsiu_init();
 #endif
 
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux-orig/include/asm-mips/vr41xx/vr41xx.h	2004-02-26 10:39:20.000000000 +0900
+++ linux/include/asm-mips/vr41xx/vr41xx.h	2004-04-27 20:35:31.000000000 +0900
@@ -136,6 +136,9 @@
 extern int vr41xx_set_intassign(unsigned int irq, unsigned char intassign);
 extern int vr41xx_cascade_irq(unsigned int irq, int (*get_irq_number)(int irq));
 
+extern void vr41xx_enable_dsiuint(void);
+extern void vr41xx_disable_dsiuint(void);
+
 /*
  * Power Management Unit
  */
@@ -189,22 +192,25 @@
 /*
  * Serial Interface Unit
  */
-extern void vr41xx_siu_init(int interface, int module);
-extern void vr41xx_siu_ifselect(int interface, int module);
+extern void vr41xx_siu_init(void);
 extern int vr41xx_serial_ports;
 
 /* SIU interfaces */
-enum {
+typedef enum {
 	SIU_RS232C,
 	SIU_IRDA
-};
+} siu_interface_t;
 
 /* IrDA interfaces */
-enum {
-	IRDA_SHARP = 1,
+typedef enum {
+	IRDA_NONE,
+	IRDA_SHARP,
 	IRDA_TEMIC,
 	IRDA_HP
-};
+} irda_module_t;
+
+extern void vr41xx_select_siu_interface(siu_interface_t interface,
+                                        irda_module_t module);
 
 /*
  * Debug Serial Interface Unit

From yuasa@hh.iij4u.or.jp Tue Apr 27 12:48:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Apr 2004 12:48:55 +0100 (BST)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:9964 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226033AbUD0Lsy>;
	Tue, 27 Apr 2004 12:48:54 +0100
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id UAA27772;
	Tue, 27 Apr 2004 20:48:50 +0900 (JST)
Received: 4UMDO00 id i3RBmoP21485; Tue, 27 Apr 2004 20:48:50 +0900 (JST)
Received: 4UMRO01 id i3RBmnj04389; Tue, 27 Apr 2004 20:48:49 +0900 (JST)
	from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Tue, 27 Apr 2004 20:48:48 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: [Update PATCH][2.6] Update TB0229+TB0219 support
Message-Id: <20040427204848.3baeb489.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20040424154839.5b0ea690.yuasa@hh.iij4u.or.jp>
References: <20040424154839.5b0ea690.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4910
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 8393
Lines: 238

Hello Ralf,

I also updated this patch. Please apply serial patch first.

This patch fixes so that the code of TB0229(CPU board) and
TB0219(base baord) may be divided correctly.

Please apply

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/Makefile linux/arch/mips/vr41xx/tanbac-tb0229/Makefile
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/Makefile	2004-02-25 12:12:07.000000000 +0900
+++ linux/arch/mips/vr41xx/tanbac-tb0229/Makefile	2004-04-27 20:39:43.000000000 +0900
@@ -4,4 +4,4 @@
 
 obj-y				:= setup.o
 
-obj-$(CONFIG_TANBAC_TB0219)	+= reboot.o
+obj-$(CONFIG_TANBAC_TB0219)	+= tb0219.o
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/reboot.c linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/reboot.c	2004-02-02 11:24:21.000000000 +0900
+++ linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c	1970-01-01 09:00:00.000000000 +0900
@@ -1,27 +0,0 @@
-/*
- * FILE NAME
- *	arch/mips/vr41xx/tanbac-tb0229/reboot.c
- *
- * BRIEF MODULE DESCRIPTION
- *	Depending on TANBAC TB0229(VR4131DIMM) of reboot system call.
- *
- * Copyright 2003 Megasolution Inc.
- *                matsu@megasolution.jp
- *
- *  This program is free software; you can redistribute it and/or modify it
- *  under the terms of the GNU General Public License as published by the
- *  Free Software Foundation; either version 2 of the License, or (at your
- *  option) any later version.
- */
-#include <linux/config.h>
-#include <asm/io.h>
-#include <asm/vr41xx/tb0229.h>
-
-#define tb0229_hard_reset()	writew(0, TB0219_RESET_REGS)
-
-void tanbac_tb0229_restart(char *command)
-{
-	local_irq_disable();
-	tb0229_hard_reset();
-	while (1);
-}
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c	2004-04-27 20:39:24.000000000 +0900
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	2004-04-27 20:39:43.000000000 +0900
@@ -25,7 +25,6 @@
 
 #include <asm/io.h>
 #include <asm/pci_channel.h>
-#include <asm/reboot.h>
 #include <asm/vr41xx/tb0229.h>
 
 #ifdef CONFIG_PCI
@@ -97,10 +96,6 @@
 	vr41xx_pciu_init(&pci_address_map);
 #endif
 
-#ifdef CONFIG_TANBAC_TB0219
-	_machine_restart = tanbac_tb0229_restart;
-#endif
-
 	return 0;
 }
 
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/tb0219.c linux/arch/mips/vr41xx/tanbac-tb0229/tb0219.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/tb0219.c	1970-01-01 09:00:00.000000000 +0900
+++ linux/arch/mips/vr41xx/tanbac-tb0229/tb0219.c	2004-04-27 20:39:43.000000000 +0900
@@ -0,0 +1,45 @@
+/*
+ *  tb0219.c, Setup for the TANBAC TB0219
+ *
+ *  Copyright (C) 2003  Megasolution Inc. <matsu@megasolution.jp>
+ *  Copyright (C) 2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include <linux/init.h>
+
+#include <asm/io.h>
+#include <asm/reboot.h>
+#include <asm/vr41xx/tb0229.h>
+
+#define TB0219_RESET_REGS	KSEG1ADDR(0x0a00000e)
+
+#define tb0219_hard_reset()	writew(0, TB0219_RESET_REGS)
+
+void tanbac_tb0219_restart(char *command)
+{
+	local_irq_disable();
+	tb0219_hard_reset();
+	while (1);
+}
+
+static int __init tanbac_tb0219_setup(void)
+{
+	_machine_restart = tanbac_tb0219_restart;
+
+	return 0;
+}
+
+early_initcall(tanbac_tb0219_setup);
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/tb0219.h linux/include/asm-mips/vr41xx/tb0219.h
--- linux-orig/include/asm-mips/vr41xx/tb0219.h	1970-01-01 09:00:00.000000000 +0900
+++ linux/include/asm-mips/vr41xx/tb0219.h	2004-04-27 20:39:43.000000000 +0900
@@ -0,0 +1,42 @@
+/*
+ *  tb0219.h, Include file for TANBAC TB0219.
+ *
+ *  Copyright (C) 2002-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  Modified for TANBAC TB0219:
+ *  Copyright (C) 2003 Megasolution Inc.  <matsu@megasolution.jp>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#ifndef __TANBAC_TB0219_H
+#define __TANBAC_TB0219_H
+
+#include <asm/vr41xx/vr41xx.h>
+
+/*
+ * General-Purpose I/O Pin Number
+ */
+#define TB0219_PCI_SLOT1_PIN		2
+#define TB0219_PCI_SLOT2_PIN		3
+#define TB0219_PCI_SLOT3_PIN		4
+
+/*
+ * Interrupt Number
+ */
+#define TB0219_PCI_SLOT1_IRQ		GIU_IRQ(TB0219_PCI_SLOT1_PIN)
+#define TB0219_PCI_SLOT2_IRQ		GIU_IRQ(TB0219_PCI_SLOT2_PIN)
+#define TB0219_PCI_SLOT3_IRQ		GIU_IRQ(TB0219_PCI_SLOT3_PIN)
+
+#endif /* __TANBAC_TB0219_H */
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/tb0229.h linux/include/asm-mips/vr41xx/tb0229.h
--- linux-orig/include/asm-mips/vr41xx/tb0229.h	2003-05-22 06:55:39.000000000 +0900
+++ linux/include/asm-mips/vr41xx/tb0229.h	2004-04-27 20:39:43.000000000 +0900
@@ -1,27 +1,29 @@
 /*
- * FILE NAME
- *	include/asm-mips/vr41xx/tb0229.h
+ *  tb0229.h, Include file for TANBAC TB0229.
  *
- * BRIEF MODULE DESCRIPTION
- *	Include file for TANBAC TB0229 and TB0219.
+ *  Copyright (C) 2002-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
- * Copyright 2002,2003 Yoichi Yuasa
- *                yuasa@hh.iij4u.or.jp
+ *  Modified for TANBAC TB0229:
+ *  Copyright (C) 2003 Megasolution Inc.  <matsu@megasolution.jp>
  *
- * Modified for TANBAC TB0229:
- * Copyright 2003 Megasolution Inc.
- *                matsu@megasolution.jp
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
  *
- *  This program is free software; you can redistribute it and/or modify it
- *  under the terms of the GNU General Public License as published by the
- *  Free Software Foundation; either version 2 of the License, or (at your
- *  option) any later version.
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 #ifndef __TANBAC_TB0229_H
 #define __TANBAC_TB0229_H
 
 #include <asm/addrspace.h>
-#include <asm/vr41xx/vr41xx.h>
 
 /*
  * Board specific address mapping
@@ -52,22 +54,4 @@
 #define IO_MEM2_RESOURCE_START		VR41XX_PCI_MEM2_BASE
 #define IO_MEM2_RESOURCE_END		(VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE)
 
-/*
- * General-Purpose I/O Pin Number
- */
-#define TB0219_PCI_SLOT1_PIN		2
-#define TB0219_PCI_SLOT2_PIN		3
-#define TB0219_PCI_SLOT3_PIN		4
-
-/*
- * Interrupt Number
- */
-#define TB0219_PCI_SLOT1_IRQ		GIU_IRQ(TB0219_PCI_SLOT1_PIN)
-#define TB0219_PCI_SLOT2_IRQ		GIU_IRQ(TB0219_PCI_SLOT2_PIN)
-#define TB0219_PCI_SLOT3_IRQ		GIU_IRQ(TB0219_PCI_SLOT3_PIN)
-
-#define TB0219_RESET_REGS		KSEG1ADDR(0x0a00000e)
-
-extern void tanbac_tb0229_restart(char *command);
-
 #endif /* __TANBAC_TB0229_H */

From sskowron@ET.PUT.Poznan.PL Tue Apr 27 19:07:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Apr 2004 19:07:35 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:26821
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226045AbUD0SHc>; Tue, 27 Apr 2004 19:07:32 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3RI7PN03302
	for <linux-mips@linux-mips.org>; Tue, 27 Apr 2004 20:07:25 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Tue, 27 Apr 2004 20:07:24 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3RI7Oo15129
	for <linux-mips@linux-mips.org>; Tue, 27 Apr 2004 20:07:24 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Tue, 27 Apr 2004 20:07:23 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: TLB on R10k
Message-ID: <Pine.GSO.4.10.10404272004460.14972-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4912
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 392
Lines: 12

Why, in tlb-andes.c, all exception handlers are prefixed with an
ampersand (&) when copying them to main memory, only the r10k fill handler
isn't? I'm getting a blackhole-style crash (no messages, no panic,
interrupts dead as a doornail, nobody knows what is happening) as soon as
I try to jump to usermode.

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.



From ica2_ts@csv.ica.uni-stuttgart.de Tue Apr 27 19:33:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Apr 2004 19:33:13 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:46659
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8226045AbUD0SdM>; Tue, 27 Apr 2004 19:33:12 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail)
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1BIXOH-0000kX-00
	for <linux-mips@linux-mips.org>; Tue, 27 Apr 2004 20:33:09 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1BIXOH-00021Y-00
	for <linux-mips@linux-mips.org>; Tue, 27 Apr 2004 20:33:09 +0200
Date: Tue, 27 Apr 2004 20:33:09 +0200
To: linux-mips@linux-mips.org
Subject: Re: TLB on R10k
Message-ID: <20040427183309.GR16797@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.GSO.4.10.10404272004460.14972-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404272004460.14972-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.5.5.1i
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: 4913
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 327
Lines: 10

Stanislaw Skowronek wrote:
> Why, in tlb-andes.c, all exception handlers are prefixed with an
> ampersand (&) when copying them to main memory, only the r10k fill handler
> isn't?

Sloppiness, I guess. They resolve to function pointers anyway. But the
flush_icache_range should be fixed to cover all memcpy'ed memory.


Thiemo

From sskowron@ET.PUT.Poznan.PL Tue Apr 27 19:54:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Apr 2004 19:54:57 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:64944
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226045AbUD0Sy4>; Tue, 27 Apr 2004 19:54:56 +0100
Received: from athena (athena [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3RIsQu08681;
	Tue, 27 Apr 2004 20:54:26 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena (MailMonitor for SMTP v1.2.2 ) ;
	Tue, 27 Apr 2004 20:54:25 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3RIsP617186;
	Tue, 27 Apr 2004 20:54:25 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Tue, 27 Apr 2004 20:54:25 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: TLB on R10k
In-Reply-To: <20040427183309.GR16797@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.4.10.10404272053350.17125-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4914
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 338
Lines: 10

> Sloppiness, I guess. They resolve to function pointers anyway. But the
> flush_icache_range should be fixed to cover all memcpy'ed memory.

Yes, I've done it, too. Still gets hung. I wonder why, I have looked at
all exception code and it is 64-bit-clean (except for some bit that is
only compiled on SMP, so I don't really care).

/s



From ralf@linux-mips.org Tue Apr 27 20:29:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Apr 2004 20:29:11 +0100 (BST)
Received: from p508B663E.dip.t-dialin.net ([IPv6:::ffff:80.139.102.62]:47382
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226052AbUD0T3K>; Tue, 27 Apr 2004 20:29:10 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3RJSmxT009432
	for <linux-mips@linux-mips.org>; Tue, 27 Apr 2004 21:28:48 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3RJSSSI009428;
	Tue, 27 Apr 2004 21:28:28 +0200
Date: Tue, 27 Apr 2004 21:28:28 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: TLB on R10k
Message-ID: <20040427192828.GA7739@linux-mips.org>
References: <Pine.GSO.4.10.10404272004460.14972-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404272004460.14972-100000@helios.et.put.poznan.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: 4915
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 538
Lines: 12

On Tue, Apr 27, 2004 at 08:07:23PM +0200, Stanislaw Skowronek wrote:

> Why, in tlb-andes.c, all exception handlers are prefixed with an
> ampersand (&) when copying them to main memory, only the r10k fill handler
> isn't? I'm getting a blackhole-style crash (no messages, no panic,
> interrupts dead as a doornail, nobody knows what is happening) as soon as
> I try to jump to usermode.

Have you verified that the UX bit is set correctly by your kernel?  BEV
also plays a role but since you survive BogoMIPS it should be right.

  Ralf

From ongbh@ispworkshop.com Wed Apr 28 03:17:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Apr 2004 03:17:33 +0100 (BST)
Received: from eastgate.starhub.net.sg ([IPv6:::ffff:203.116.1.189]:33542 "EHLO
	eastgate.starhub.net.sg") by linux-mips.org with ESMTP
	id <S8226067AbUD1CRc>; Wed, 28 Apr 2004 03:17:32 +0100
Received: from support.antlabs.com (ant1-suntec.starhub.net.sg [203.118.8.2] (may be forged))
	by eastgate.starhub.net.sg (8.12.5/8.12.5) with SMTP id i3S2HT4F027678
	for <linux-mips@linux-mips.org>; Wed, 28 Apr 2004 10:17:29 +0800 (SST)
Received: (qmail 8581 invoked from network); 28 Apr 2004 02:17:28 -0000
Received: from unknown (HELO ispworkshop.com) (203.118.8.181)
  by 0 with SMTP; 28 Apr 2004 02:17:28 -0000
Message-ID: <408F141B.5010805@ispworkshop.com>
Date: Wed, 28 Apr 2004 10:16:59 +0800
From: Ong Beng Hui <ongbh@ispworkshop.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: broadcom sibyte reference board
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ongbh@ispworkshop.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4916
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ongbh@ispworkshop.com
Precedence: bulk
X-list: linux-mips
Content-Length: 175
Lines: 7

Hi,

If there any way for me to get a broadcom sibyte reference board ?

I called up the local office, and they refuse to get for me, been, I just
going use it for personal.


From sskowron@ET.PUT.Poznan.PL Wed Apr 28 06:37:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Apr 2004 06:37:16 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:27872
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8224933AbUD1FhP>; Wed, 28 Apr 2004 06:37:15 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3S5b7N07749;
	Wed, 28 Apr 2004 07:37:08 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Wed, 28 Apr 2004 07:37:07 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i3S5b6n09347;
	Wed, 28 Apr 2004 07:37:06 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Wed, 28 Apr 2004 07:37:06 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: TLB on R10k
In-Reply-To: <20040427192828.GA7739@linux-mips.org>
Message-ID: <Pine.GSO.4.10.10404280734480.9183-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 4917
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 636
Lines: 14

> Have you verified that the UX bit is set correctly by your kernel?  BEV
> also plays a role but since you survive BogoMIPS it should be right.

From what I remember, the UX bit is fixed set. I have made the machine
print a '*' (no, I didn't use printk, but since it's my own console
driver I'm pretty sure it can work in interrupts - all it does is
hardware writes) whenever it gets a TLB refill and flushed the TLB before
entering usermode. Guess what, I didn't get a single '*' after ERET. To
verify my method, I've made a single read from the usermode PC from the
kernel, and the '*' appeared. I don't know what's up.

Stanislaw



From damian@clown-fish.com Wed Apr 28 13:27:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Apr 2004 13:28:00 +0100 (BST)
Received: from host-212-158-214-243.bulldogdsl.com ([IPv6:::ffff:212.158.214.243]:9736
	"EHLO megablaster5.clown-smart.co.uk") by linux-mips.org with ESMTP
	id <S8226105AbUD1M16>; Wed, 28 Apr 2004 13:27:58 +0100
Received: from [127.0.0.1] (host-212-158-214-244.bulldogdsl.com [212.158.214.244])
	by megablaster5.clown-smart.co.uk (Postfix) with ESMTP
	id BA3AA32E57; Wed, 28 Apr 2004 13:39:49 +0100 (BST)
Message-ID: <408FA3C3.3060304@clown-fish.com>
Date: Wed, 28 Apr 2004 13:29:55 +0100
From: Damian Presswell <damian@clown-fish.com>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040426)
X-Accept-Language: en
MIME-Version: 1.0
To: ilya@theIlya.com
Cc: Damian Presswell <damian@clown-fish.com>, linux-mips@linux-mips.org
Subject: Re: Linux Mips SGI O2 R5000 IP32 INSTALL
References: <408D6BFC.6030902@clown-fish.com> <20040426222441.GC1276@gateway.total-knowledge.com>
In-Reply-To: <20040426222441.GC1276@gateway.total-knowledge.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <damian@clown-fish.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4918
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: damian@clown-fish.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2177
Lines: 73

Hi Ilya -

thanks for coming back to me -

I have managed to build a root filesystem using the gentoo sources that 
you suggested - however -
I am unable to boot off the hardisk -
I have fdisked the first scsi disk, created a 50 meg vlhdr, where I have 
copied my pre-compiled vmlinux binaries  -
it  appears to load and provide an entry point but then just hangs and 
goes no further -
I have also added the original netboot vmlinux  binary that I use to 
boot via tftpboot to the HD's volume header but it does the same thing - 
just hangs after the entry point -

I can boot the system using bootp(): and the kernel binary located  in  
the tftpboot using  root=dev/sda3 - but  cannot figure why it  doesnt 
seem to work off the volume header of the HD -

 once again -

any help would be appreciated -

thanks



ilya@theIlya.com wrote:

>Use Gentoo.
>Also, Glaurung's kernels are bit out-od-date. Use self-built
>kernel from recent linux-mips.org CVS. In worst case, use
>one of Gentoo's kernel binaries.
>
>	Ilya.
>
>On Mon, Apr 26, 2004 at 09:07:24PM +0100, Damian Presswell wrote:
>  
>
>>My apologies if this is the wrong mailing list for this question -
>>
>>I have recently aquired an SGI  O2 ip32 R5k box that I am trying to 
>>install linux onto -
>>
>>I have managed to get a binary 64bit kernel to boot vis nfs and bootp() 
>>that I downloaded from Glaurungs website:
>>
>>http://www.linux-mips.org/~glaurung/
>>
>>however I am unsure as to the correct rootfs that I am suposed to use - 
>>I pulled down the redhat 7.1 rootfs from somewhere but it hangs when 
>>trying to start the 'local' service - and wont boot if this service is 
>>switched off -
>>
>>I would be grateful if you could suggest where I may download a suitable 
>>rootfs and ecoff boot image that will work together on my O2 box - would 
>>hate to give in at this stage - and indeed any other help you may be 
>>able to give me as a linux mips O2 user - I will put together an updated 
>>HOWTO once I am sure exactly what I am supposed to be doing - the 
>>information and resources on this subject do seem to be a little vague -
>>
>>thanks for your time
>>
>>Damian
>>
>>
>>    
>>
>
>  
>



From agd5f@yahoo.com Wed Apr 28 16:05:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Apr 2004 16:05:40 +0100 (BST)
Received: from web11305.mail.yahoo.com ([IPv6:::ffff:216.136.131.208]:23567
	"HELO web11305.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8226121AbUD1PFi>; Wed, 28 Apr 2004 16:05:38 +0100
Message-ID: <20040428150520.17119.qmail@web11305.mail.yahoo.com>
Received: from [66.93.100.212] by web11305.mail.yahoo.com via HTTP; Wed, 28 Apr 2004 08:05:20 PDT
Date: Wed, 28 Apr 2004 08:05:20 -0700 (PDT)
From: Alex Deucher <agd5f@yahoo.com>
Subject: Re: TLB on R10k
To: sskowron@ET.PUT.Poznan.PL
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <agd5f@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4919
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agd5f@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1105
Lines: 32

This thread may be ARM specific, but it sounds like a similar problem. 
if it's of no use, please ignore.

http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2003-November/018303.html
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2003-November/018409.html

Alex

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

> Have you verified that the UX bit is set correctly by your kernel? 
BEV
> also plays a role but since you survive BogoMIPS it should be right.

From what I remember, the UX bit is fixed set. I have made the machine
print a '*' (no, I didn't use printk, but since it's my own console
driver I'm pretty sure it can work in interrupts - all it does is
hardware writes) whenever it gets a TLB refill and flushed the TLB
before
entering usermode. Guess what, I didn't get a single '*' after ERET. To
verify my method, I've made a single read from the usermode PC from the
kernel, and the '*' appeared. I don't know what's up.

Stanislaw


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

From ralf@linux-mips.org Wed Apr 28 18:28:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Apr 2004 18:28:03 +0100 (BST)
Received: from p508B60B2.dip.t-dialin.net ([IPv6:::ffff:80.139.96.178]:7204
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225208AbUD1R2C>; Wed, 28 Apr 2004 18:28:02 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3SHRfxT031872
	for <linux-mips@linux-mips.org>; Wed, 28 Apr 2004 19:27:41 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3SHRLQE031854;
	Wed, 28 Apr 2004 19:27:21 +0200
Date: Wed, 28 Apr 2004 19:27:21 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: TLB on R10k
Message-ID: <20040428172721.GA28007@linux-mips.org>
References: <20040427192828.GA7739@linux-mips.org> <Pine.GSO.4.10.10404280734480.9183-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10404280734480.9183-100000@helios.et.put.poznan.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: 4920
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 933
Lines: 20

On Wed, Apr 28, 2004 at 07:37:06AM +0200, Stanislaw Skowronek wrote:

> > Have you verified that the UX bit is set correctly by your kernel?  BEV
> > also plays a role but since you survive BogoMIPS it should be right.
> 
> >From what I remember, the UX bit is fixed set. I have made the machine
> print a '*' (no, I didn't use printk, but since it's my own console
> driver I'm pretty sure it can work in interrupts - all it does is
> hardware writes) whenever it gets a TLB refill and flushed the TLB before
> entering usermode. Guess what, I didn't get a single '*' after ERET. To
> verify my method, I've made a single read from the usermode PC from the
> kernel, and the '*' appeared. I don't know what's up.

printk can be used in exceptions.

Be careful when changing the TLB exception handlers.  They occupy slots
of just 128 bytes or 32 instructions.  Maybe your debugging code just
extended it beyond that maximum?

  Ralf

From ilya@theilya.com Wed Apr 28 19:55:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Apr 2004 19:55:44 +0100 (BST)
Received: from [IPv6:::ffff:66.151.148.199] ([IPv6:::ffff:66.151.148.199]:60679
	"EHLO eagle.qarbon.com") by linux-mips.org with ESMTP
	id <S8225211AbUD1Szm>; Wed, 28 Apr 2004 19:55:42 +0100
Received: (qmail 7337 invoked from network); 28 Apr 2004 11:55:32 -0700
Received: from unknown (HELO theilya.com) (ilya@192.168.2.42)
  by eagle.qarbon.com with AES256-SHA encrypted SMTP; 28 Apr 2004 11:55:32 -0700
Message-ID: <408FFE1E.5080605@theilya.com>
Date: Wed, 28 Apr 2004 11:55:26 -0700
From: "Ilya A. Volynets-Evenbakh" <ilya@theilya.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040317
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Damian Presswell <damian@clown-fish.com>
CC: linux-mips@linux-mips.org
Subject: Re: Linux Mips SGI O2 R5000 IP32 INSTALL
References: <408D6BFC.6030902@clown-fish.com> <20040426222441.GC1276@gateway.total-knowledge.com> <408FA3C3.3060304@clown-fish.com>
In-Reply-To: <408FA3C3.3060304@clown-fish.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ilya@theilya.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4921
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theilya.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2833
Lines: 82

Well, you are not the only one ;-)
Currently you cannot use volume header for loading linux kernel due to some
very strange bug. I spent two weeks chsing it, and then decided that my time
is better spent elsewhere. Also, dents in my walls resulting from 
contact between
my head and walls' surface do not look nice. For now, you should either use
dhcp/bootp or arcboot. Latest version of arcboot (0.3.8.-something, 
afair) should work out
of the box with O2. If it doesn't, let me know - I'll dig out my 
highly-hacked binary.

    Ilya.

Damian Presswell wrote:

> Hi Ilya -
>
> thanks for coming back to me -
>
> I have managed to build a root filesystem using the gentoo sources 
> that you suggested - however -
> I am unable to boot off the hardisk -
> I have fdisked the first scsi disk, created a 50 meg vlhdr, where I 
> have copied my pre-compiled vmlinux binaries  -
> it  appears to load and provide an entry point but then just hangs and 
> goes no further -
> I have also added the original netboot vmlinux  binary that I use to 
> boot via tftpboot to the HD's volume header but it does the same thing 
> - just hangs after the entry point -
>
> I can boot the system using bootp(): and the kernel binary located  
> in  the tftpboot using  root=dev/sda3 - but  cannot figure why it  
> doesnt seem to work off the volume header of the HD -
>
> once again -
>
> any help would be appreciated -
>
> thanks
>
>
>
> ilya@theIlya.com wrote:
>
>> Use Gentoo.
>> Also, Glaurung's kernels are bit out-od-date. Use self-built
>> kernel from recent linux-mips.org CVS. In worst case, use
>> one of Gentoo's kernel binaries.
>>
>>     Ilya.
>>
>> On Mon, Apr 26, 2004 at 09:07:24PM +0100, Damian Presswell wrote:
>>  
>>
>>> My apologies if this is the wrong mailing list for this question -
>>>
>>> I have recently aquired an SGI  O2 ip32 R5k box that I am trying to 
>>> install linux onto -
>>>
>>> I have managed to get a binary 64bit kernel to boot vis nfs and 
>>> bootp() that I downloaded from Glaurungs website:
>>>
>>> http://www.linux-mips.org/~glaurung/
>>>
>>> however I am unsure as to the correct rootfs that I am suposed to 
>>> use - I pulled down the redhat 7.1 rootfs from somewhere but it 
>>> hangs when trying to start the 'local' service - and wont boot if 
>>> this service is switched off -
>>>
>>> I would be grateful if you could suggest where I may download a 
>>> suitable rootfs and ecoff boot image that will work together on my 
>>> O2 box - would hate to give in at this stage - and indeed any other 
>>> help you may be able to give me as a linux mips O2 user - I will put 
>>> together an updated HOWTO once I am sure exactly what I am supposed 
>>> to be doing - the information and resources on this subject do seem 
>>> to be a little vague -
>>>
>>> thanks for your time
>>>
>>> Damian
>>


From egieswein@surewest.net Wed Apr 28 20:22:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Apr 2004 20:22:49 +0100 (BST)
Received: from smtp2.mc.surewest.net ([IPv6:::ffff:66.60.130.51]:1206 "HELO
	smtp2.mc.surewest.net") by linux-mips.org with SMTP
	id <S8225211AbUD1TWs>; Wed, 28 Apr 2004 20:22:48 +0100
Received: (s3-26405); Wed, 28 Apr 2004 12:22:45 -0700
Received: from unknown (HELO wm1.mc.surewest.net) (66.60.128.58)
  by smtp2.mc.surewest.net (s3-smtpd/0.90-beta3) with SMTP; Wed, 28 Apr 2004 12:22:44 -0700
Received: from 64.132.239.129
        (SquirrelMail authenticated user egieswein@surewest.net)
        by webmail.surewest.net with HTTP;
        Wed, 28 Apr 2004 12:22:44 -0700 (PDT)
Message-ID: <33002.64.132.239.129.1083180164.squirrel@webmail.surewest.net>
Date: Wed, 28 Apr 2004 12:22:44 -0700 (PDT)
Subject: Origin 2000 and linux
From: "Edison Gieswein" <egieswein@surewest.net>
To: linux-mips@linux-mips.org
Reply-To: egieswein@surewest.net
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3
Importance: Normal
X-TST: smtp2.mc.surewest.net SNWK3 0.31-65
Return-Path: <egieswein@surewest.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: 4922
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: egieswein@surewest.net
Precedence: bulk
X-list: linux-mips
Content-Length: 422
Lines: 11

just curious if anybody has any experiences they would care to share
regarding installing linux on an Origin 2000 system... currently I have 12
total processors.... (1 node w/ 8.... 1 node w/ 4)

and I'm trying to secure a test node (or 2...) for devel purposes....
(ie.. available to group for testing w/ serial console access via another
linux box...)

any suggestions/pointers would be appreciated...

Thanks... Edison

From ilya@theilya.com Wed Apr 28 20:47:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Apr 2004 20:47:19 +0100 (BST)
Received: from [IPv6:::ffff:66.151.148.199] ([IPv6:::ffff:66.151.148.199]:61450
	"EHLO eagle.qarbon.com") by linux-mips.org with ESMTP
	id <S8225234AbUD1TrQ>; Wed, 28 Apr 2004 20:47:16 +0100
Received: (qmail 15359 invoked from network); 28 Apr 2004 12:47:09 -0700
Received: from unknown (HELO theilya.com) (ilya@192.168.2.42)
  by eagle.qarbon.com with AES256-SHA encrypted SMTP; 28 Apr 2004 12:47:09 -0700
Message-ID: <40900A38.3070608@theilya.com>
Date: Wed, 28 Apr 2004 12:47:04 -0700
From: "Ilya A. Volynets-Evenbakh" <ilya@theilya.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040317
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: egieswein@surewest.net
CC: linux-mips@linux-mips.org
Subject: Re: Origin 2000 and linux
References: <33002.64.132.239.129.1083180164.squirrel@webmail.surewest.net>
In-Reply-To: <33002.64.132.239.129.1083180164.squirrel@webmail.surewest.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ilya@theilya.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4923
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theilya.com
Precedence: bulk
X-list: linux-mips
Content-Length: 580
Lines: 21

Use Gentoo/MIPS for userland.
Come down to irc://irc.freenode.net/#gentoo-mips and ask iluxa for 
kernel binary.

Edison Gieswein wrote:

>just curious if anybody has any experiences they would care to share
>regarding installing linux on an Origin 2000 system... currently I have 12
>total processors.... (1 node w/ 8.... 1 node w/ 4)
>
>and I'm trying to secure a test node (or 2...) for devel purposes....
>(ie.. available to group for testing w/ serial console access via another
>linux box...)
>
>any suggestions/pointers would be appreciated...
>
>Thanks... Edison
>
>  
>


From brm@murphy.dk Thu Apr 29 18:08:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Apr 2004 18:08:47 +0100 (BST)
Received: from port535.ds1-van.adsl.cybercity.dk ([IPv6:::ffff:217.157.140.228]:24935
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225727AbUD2RIq>; Thu, 29 Apr 2004 18:08:46 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 1BJF1Z-0000zc-00; Thu, 29 Apr 2004 19:08:38 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.4] LASAT rtc fix
Cc: linux-mips@linux-mips.org
Message-Id: <E1BJF1Z-0000zc-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Thu, 29 Apr 2004 19:08:38 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4924
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 1230
Lines: 57

Hi Ralf,
this makes the LASAT systems not spend 10 minutes fscking every bootup
because the rtc is read wrongly.

Please Apply.

/Brian

Index: arch/mips/lasat/ds1603.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/ds1603.c,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 ds1603.c
--- arch/mips/lasat/ds1603.c	24 Feb 2003 21:26:19 -0000	1.1.2.3
+++ arch/mips/lasat/ds1603.c	29 Apr 2004 16:21:48 -0000
@@ -51,14 +51,14 @@
 {
 	data |= ds1603->clk;
 	rtc_reg_write(data);
-	ndelay(250);
+	lasat_ndelay(250);
 	if (ds1603->data_reversed)
 		data &= ~ds1603->data;
 	else
 		data |= ds1603->data;
 	data &= ~ds1603->clk;
 	rtc_reg_write(data);
-	ndelay(250 + ds1603->huge_delay);
+	lasat_ndelay(250 + ds1603->huge_delay);
 }
 
 static void rtc_write_databit(unsigned int bit)
@@ -72,7 +72,7 @@
 		data &= ~ds1603->data;
 
 	rtc_reg_write(data);
-	ndelay(50 + ds1603->huge_delay);
+	lasat_ndelay(50 + ds1603->huge_delay);
 	rtc_cycle_clock(data);
 }
 
@@ -125,13 +125,13 @@
 
 	rtc_reg_write(rtc_reg_read() & ~ds1603->clk);
 
-	ndelay(50);
+	lasat_ndelay(50);
 }
 
 static void rtc_end_op(void)
 {
 	rtc_nrst_low();
-	ndelay(1000);
+	lasat_ndelay(1000);
 }
 
 /* interface */

From tim.bird@am.sony.com Thu Apr 29 19:57:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Apr 2004 19:57:46 +0100 (BST)
Received: from mail1.fw-sj.sony.com ([IPv6:::ffff:160.33.82.68]:30411 "EHLO
	mail1.fw-sj.sony.com") by linux-mips.org with ESMTP
	id <S8225489AbUD2S5n>; Thu, 29 Apr 2004 19:57:43 +0100
Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211])
	by mail1.fw-sj.sony.com (8.12.11/8.12.11) with ESMTP id i3TIvATL021399;
	Thu, 29 Apr 2004 18:57:15 GMT
Received: from am.sony.com ([43.134.85.186])
	by mail3.sjc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id i3TIusQL020149;
	Thu, 29 Apr 2004 18:56:54 GMT
Message-ID: <40915265.2050906@am.sony.com>
Date: Thu, 29 Apr 2004 12:07:17 -0700
From: Tim Bird <tim.bird@am.sony.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux kernel <linux-kernel@vger.kernel.org>
CC: linux-arm-kernel@lists.arm.linux.org.uk, linux-mips@linux-mips.org,
	linux-sh-ctl@m17n.org,
	CE Linux Developers List <celinux-dev@tree.celinuxforum.org>
Subject: CONFIG_XIP_ROM vs. CONFIG_XIP_KERNEL
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <tim.bird@am.sony.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4925
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tim.bird@am.sony.com
Precedence: bulk
X-list: linux-mips
Content-Length: 792
Lines: 29

I'm looking at some sources for kernel Execute-in-place (XIP).

I see references to CONFIG_XIP_ROM and CONFIG_XIP_KERNEL,
in different architecture branches of the same kernel
source tree.

Is this difference merely the result of inconsistent
usage, or is there a functional difference between
these two options?

I can imagine that CONFIG_XIP_ROM is intended only to
handle XIP in ROM, and that CONFIG_XIP_KERNEL possibly
handles additional cases like XIP in flash.  However,
before jumping to that conclusion I thought I would
ask if there is some intention behind the different
config names.

Thanks,

=============================
Tim Bird
Architecture Group Co-Chair
CE Linux Forum
Senior Staff Engineer
Sony Electronics
E-mail: Tim.Bird (at) am.sony.com
=============================



From ralf@linux-mips.org Thu Apr 29 21:09:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Apr 2004 21:09:41 +0100 (BST)
Received: from p508B630B.dip.t-dialin.net ([IPv6:::ffff:80.139.99.11]:61492
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225748AbUD2UJi>; Thu, 29 Apr 2004 21:09:38 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3TK9VxT023875;
	Thu, 29 Apr 2004 22:09:31 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3TK9RZ8023874;
	Thu, 29 Apr 2004 22:09:27 +0200
Date: Thu, 29 Apr 2004 22:09:27 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Tim Bird <tim.bird@am.sony.com>
Cc: linux kernel <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.arm.linux.org.uk, linux-mips@linux-mips.org,
	linux-sh-ctl@m17n.org,
	CE Linux Developers List <celinux-dev@tree.celinuxforum.org>
Subject: Re: CONFIG_XIP_ROM vs. CONFIG_XIP_KERNEL
Message-ID: <20040429200927.GB20401@linux-mips.org>
References: <40915265.2050906@am.sony.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40915265.2050906@am.sony.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: 4926
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 768
Lines: 22

On Thu, Apr 29, 2004 at 12:07:17PM -0700, Tim Bird wrote:

> I'm looking at some sources for kernel Execute-in-place (XIP).
> 
> I see references to CONFIG_XIP_ROM and CONFIG_XIP_KERNEL,
> in different architecture branches of the same kernel
> source tree.
> 
> Is this difference merely the result of inconsistent
> usage, or is there a functional difference between
> these two options?
> 
> I can imagine that CONFIG_XIP_ROM is intended only to
> handle XIP in ROM, and that CONFIG_XIP_KERNEL possibly
> handles additional cases like XIP in flash.  However,
> before jumping to that conclusion I thought I would
> ask if there is some intention behind the different
> config names.

Since you copied linux-mips - neither option is implemented for MIPS ...

  Ralf

From nico@cam.org Thu Apr 29 21:49:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Apr 2004 21:49:57 +0100 (BST)
Received: from modemcable166.48-200-24.mc.videotron.ca ([IPv6:::ffff:24.200.48.166]:33737
	"EHLO xanadu.home") by linux-mips.org with ESMTP
	id <S8225760AbUD2Ut4>; Thu, 29 Apr 2004 21:49:56 +0100
Received: from localhost (nico@localhost)
	by xanadu.home (8.11.6/8.11.6) with ESMTP id i3TKnj801327;
	Thu, 29 Apr 2004 16:49:45 -0400
X-Authentication-Warning: xanadu.home: nico owned process doing -bs
Date: Thu, 29 Apr 2004 16:49:45 -0400 (EDT)
From: Nicolas Pitre <nico@cam.org>
X-X-Sender: nico@xanadu.home
To: Tim Bird <tim.bird@am.sony.com>
cc: linux kernel <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.arm.linux.org.uk>,
	<linux-mips@linux-mips.org>, <linux-sh-ctl@m17n.org>,
	CE Linux Developers List <celinux-dev@tree.celinuxforum.org>
Subject: Re: CONFIG_XIP_ROM vs. CONFIG_XIP_KERNEL
In-Reply-To: <40915265.2050906@am.sony.com>
Message-ID: <Pine.LNX.4.44.0404291644170.30657-100000@xanadu.home>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <nico@cam.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: 4927
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nico@cam.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1047
Lines: 29

On Thu, 29 Apr 2004, Tim Bird wrote:

> I'm looking at some sources for kernel Execute-in-place (XIP).
> 
> I see references to CONFIG_XIP_ROM and CONFIG_XIP_KERNEL,
> in different architecture branches of the same kernel
> source tree.
> 
> Is this difference merely the result of inconsistent
> usage, or is there a functional difference between
> these two options?

It's the result of me deciding CONFIG_XIP_ROM wasn't totally appropriate ...  

> I can imagine that CONFIG_XIP_ROM is intended only to
> handle XIP in ROM, and that CONFIG_XIP_KERNEL possibly
> handles additional cases like XIP in flash.  However,
> before jumping to that conclusion I thought I would
> ask if there is some intention behind the different
> config names.

... so I renamed it to CONFIG_XIP_KERNEL.  Especially since there is also 
XIPable user space which also can be stored in ROM (or flash).  So please 
disregard CONFIG_XIP_ROM and use CONFIG_XIP_KERNEL.  Whether ROM or Flash is 
used is rather irrelevant to the code this option is linked to.


Nicolas


From jhecker@wireless.org.au Fri Apr 30 00:20:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Apr 2004 00:20:56 +0100 (BST)
Received: from 203-217-29-141.perm.iinet.net.au ([IPv6:::ffff:203.217.29.141]:11760
	"EHLO river.redflex.com.au") by linux-mips.org with ESMTP
	id <S8225769AbUD2XUz>; Fri, 30 Apr 2004 00:20:55 +0100
Received: from wireless.org.au ([192.168.88.165])
	by river.redflex.com.au (8.9.3/8.9.3) with ESMTP id JAA08039
	for <linux-mips@linux-mips.org>; Fri, 30 Apr 2004 09:20:52 +1000
Message-ID: <40918DF9.7010507@wireless.org.au>
Date: Fri, 30 Apr 2004 09:21:29 +1000
From: Jason Hecker <jhecker@wireless.org.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Lexra LX5820 documentation
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <jhecker@wireless.org.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: 4928
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jhecker@wireless.org.au
Precedence: bulk
X-list: linux-mips
Content-Length: 408
Lines: 9

I was wondering if anyone had any documentation lying around for the 
Lexra LX5820?  Far from being dead it's used in Realtek's RTL8181 
802.11b access point SoC.

I am finding it very difficult to come across any details on just how 
this CPU works (instruction set, MMU, cache etc.) and what differences 
there are to a regular MIPS core.

Any info would help a lot with this project http://rtl8181.sf.net

From ppopov@mvista.com Fri Apr 30 00:31:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Apr 2004 00:31:46 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:51189 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225769AbUD2Xbn>;
	Fri, 30 Apr 2004 00:31:43 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA06011;
	Thu, 29 Apr 2004 16:31:36 -0700
Message-ID: <40919055.5070706@mvista.com>
Date: Thu, 29 Apr 2004 16:31:33 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jason Hecker <jhecker@wireless.org.au>
CC: linux-mips@linux-mips.org
Subject: Re: Lexra LX5820 documentation
References: <40918DF9.7010507@wireless.org.au>
In-Reply-To: <40918DF9.7010507@wireless.org.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4929
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 672
Lines: 17

Jason Hecker wrote:

> I was wondering if anyone had any documentation lying around for the 
> Lexra LX5820?  Far from being dead it's used in Realtek's RTL8181 
> 802.11b access point SoC.
>
> I am finding it very difficult to come across any details on just how 
> this CPU works (instruction set, MMU, cache etc.) and what differences 
> there are to a regular MIPS core.
>
> Any info would help a lot with this project http://rtl8181.sf.net
>
I still have a pdf for the 4189 but I'm not sure about the NDA status so 
I can't give it away. I believe (could be wrong though) that MIPS Tech 
bought Lexra's assets, so they are probably the ones that have the docs.

Pete

From ralf@linux-mips.org Fri Apr 30 02:34:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Apr 2004 02:34:17 +0100 (BST)
Received: from p508B630B.dip.t-dialin.net ([IPv6:::ffff:80.139.99.11]:41272
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225780AbUD3BeQ>; Fri, 30 Apr 2004 02:34:16 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i3U1YBxT031210;
	Fri, 30 Apr 2004 03:34:11 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i3U1YAZO031209;
	Fri, 30 Apr 2004 03:34:10 +0200
Date: Fri, 30 Apr 2004 03:34:10 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Tim Bird <tim.bird@am.sony.com>
Cc: linux-mips@linux-mips.org,
	CE Linux Developers List <celinux-dev@tree.celinuxforum.org>
Subject: Re: CONFIG_XIP_ROM vs. CONFIG_XIP_KERNEL
Message-ID: <20040430013410.GA29246@linux-mips.org>
References: <40915265.2050906@am.sony.com> <20040429200927.GB20401@linux-mips.org> <40916C15.7000500@am.sony.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40916C15.7000500@am.sony.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: 4930
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1797
Lines: 43

On Thu, Apr 29, 2004 at 01:56:53PM -0700, Tim Bird wrote:

> Well this is interesting.  One the architectures where this is supported
> in my tree is MIPS.  I'm looking at the CELF source tree. The patch for
> this was submitted to me by Toshiba.  I had assumed (based on some other
> indications) that they were submitting stuff to me that they had already
> submitted to kernel.org or to the MIPS list.  This appears not to be
> the case.
> 
> We should discuss this.  I have some patches for MIPS stuff in the
> CELF tree from MontaVista, Toshiba, and NEC.   Unfortunately, the
> CELF tree is based on Linux 2.4.20, so I don't know how much of it,
> if any, would be useful to you.

Depends.  The linux-mips.org tree is at 2.4.26.  Some areas have changed
significantly since 2.4.20, some not at all.  If you want to send patches
please make sure they still apply to the latest kernel.

> How do I proceed with finding out what's interesting, and how to get
> it to you?  Just post some stuff (even if old) to the mips mailing
> list?  Request the originator to do such a post?  Do things need to
> be migrated to 2.6?

Preferably yes.  I don't really care who sends the patch as long as the
sender takes responsibility also after the initial submission.

Any new features preferably for 2.6.

>  Could we bypass that for a casual "is this interesting" review?  Etc.

If all you need is a comment, sure.

> The questions are endless.
> Let me know what you think.
> 
> And, BTW, in my tree the variable used for MIPS is CONFIG_XIP_ROM.
> For SH, it's CONFIG_XIP_KERNEL, and for ARM, it has conditionals
> for both, but only defines CONFIG_XIP_ROM in the config.in!

In the kernel.org kernel the only references to these symbols are to
CONFIG_XIP_KERNEL in a few files under arch/arm26.

  Ralf

From dom@mips.com Fri Apr 30 10:45:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Apr 2004 10:45:49 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:5644 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225800AbUD3Jps>;
	Fri, 30 Apr 2004 10:45:48 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1BJUox-0003wW-00; Fri, 30 Apr 2004 11:00:39 +0100
Received: from arsenal.mips.com ([192.168.192.197])
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1BJUZw-0002cL-00; Fri, 30 Apr 2004 10:45:08 +0100
Received: from dom by arsenal.mips.com with local (Exim 3.35 #1 (Debian))
	id 1BJUZv-0003k1-00; Fri, 30 Apr 2004 10:45:07 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16530.8227.672138.892561@arsenal.mips.com>
Date: Fri, 30 Apr 2004 10:45:07 +0100
To: Pete Popov <ppopov@mvista.com>
Cc: Jason Hecker <jhecker@wireless.org.au>, linux-mips@linux-mips.org
Subject: Re: Lexra LX5820 documentation
In-Reply-To: <40919055.5070706@mvista.com>
References: <40918DF9.7010507@wireless.org.au>
	<40919055.5070706@mvista.com>
X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.844, required 4, AWL,
	BAYES_00)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4931
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 683
Lines: 19


> > I was wondering if anyone had any documentation lying around for the 
> > Lexra LX5820?  Far from being dead it's used in Realtek's RTL8181 
> > 802.11b access point SoC.
> >
> > Any info would help a lot with this project http://rtl8181.sf.net
> >
> I still have a pdf for the 4189 but I'm not sure about the NDA status so 
> I can't give it away. I believe (could be wrong though) that MIPS Tech 
> bought Lexra's assets, so they are probably the ones that have the docs.

We did, we must: and I don't know right off how to find the manual, or
under what conditions I can give it out.  But I'll make some enquiries
and get back to you.

--
Dominic Sweetman
MIPS Technologies


From admin@nectarine.info Fri Apr 30 16:16:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Apr 2004 16:16:29 +0100 (BST)
Received: from [IPv6:::ffff:195.62.234.69] ([IPv6:::ffff:195.62.234.69]:45765
	"EHLO mail.nectarine.info") by linux-mips.org with ESMTP
	id <S8225845AbUD3PQ2>; Fri, 30 Apr 2004 16:16:28 +0100
Received: by mail.nectarine.info (Postfix, from userid 33)
	id 99EA9708002; Fri, 30 Apr 2004 17:16:27 +0200 (CEST)
Received: from 82.51.56.112 ( [82.51.56.112])
	as user admin@nectarine.info@mail.nectarine.info by www.nectarine.it with HTTP;
	Fri, 30 Apr 2004 17:16:27 +0200
Message-ID: <1083338187.40926dcb610a4@www.nectarine.it>
Date: Fri, 30 Apr 2004 17:16:27 +0200
From: admin@nectarine.info
To: linux-mips@linux-mips.org
Subject: Info on nec vr4181a
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.1
Return-Path: <admin@nectarine.info>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 4932
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: admin@nectarine.info
Precedence: bulk
X-list: linux-mips
Content-Length: 661
Lines: 14

Hi all,
i'am thinking to start development on this Nec starter kit,
which seems to be based on Acer pica cpu which is supported by linux-mips,
one of the most important things that i need on this system is the X server 
or some type of gui apart from ncurses which are probably nice but not enough 
for what i need to do. According to linux-mips website X for pica is not 
supported, there is any news about it ? I've seen that NetBSD and OpenBSD have 
support for X11 on acer pica so its port to linux wouldnt be too hard, starting 
a port is an option...but first i've to understand whats the situation around X 
and Acer pica...

Regards.

Giacomo Di Ciocco