From michael@cubic.org Sun Aug  1 09:28:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Aug 2004 09:29:03 +0100 (BST)
Received: from c154091.adsl.hansenet.de ([IPv6:::ffff:213.39.154.91]:37384
	"EHLO gruft.cubic.org") by linux-mips.org with ESMTP
	id <S8224851AbUHAI27>; Sun, 1 Aug 2004 09:28:59 +0100
Received: from cubic.org (starbase [192.168.10.1])
	by gruft.cubic.org (8.12.2/8.12.2) with ESMTP id i718SwW9003875
	for <linux-mips@linux-mips.org>; Sun, 1 Aug 2004 10:28:58 +0200
Message-ID: <410CAAD8.7070204@cubic.org>
Date: Sun, 01 Aug 2004 10:33:28 +0200
From: Michael Stickel <michael@cubic.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: ATI Rage XL
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <michael@cubic.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: 5577
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michael@cubic.org
Precedence: bulk
X-list: linux-mips

Hi.

I am new to the list.
I have a MIPS32 based platform with miniPCI slots and an ATI Rage XL.
There where rumors that there is code in the 2.6 Kernel that initializes 
the card for non-x86 platforms. I have found a file called xlinit.c
with a function atyfb_xl_init in it, but I did not find a place where it 
is called. I read that it is a patch from SGI to get the Rage XL running
on non X86 platforms.

Is all that only a rumor or does anyone have a pointer where to find
more information about the ATI Rage XL in non x86 platforms.

Michael
michael@cubic.org


From willem.acke@alcatel.be Mon Aug  2 10:19:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Aug 2004 10:19:40 +0100 (BST)
Received: from smail.alcatel.fr ([IPv6:::ffff:62.23.212.165]:45513 "EHLO
	smail.alcatel.fr") by linux-mips.org with ESMTP id <S8224772AbUHBJTg>;
	Mon, 2 Aug 2004 10:19:36 +0100
Received: from bemail03.netfr.alcatel.fr (bemail03.netfr.alcatel.fr [155.132.251.37])
	by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i729JPZv002931
	for <linux-mips@linux-mips.org>; Mon, 2 Aug 2004 11:19:31 +0200
Received: from alcatel.be ([172.31.202.2])
          by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.11)
          with ESMTP id 2004080211192669:1443 ;
          Mon, 2 Aug 2004 11:19:26 +0200 
Message-ID: <410E071F.4060907@alcatel.be>
Date: Mon, 02 Aug 2004 11:19:27 +0200
From: willem.acke@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: RM9000x2 TLB load exception
X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 08/02/2004 11:19:26,
	Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 08/02/2004 11:19:30,
	Serialize complete at 08/02/2004 11:19:30
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Alcanet-MTA-scanned-and-authorized: yes
Return-Path: <willem.acke@alcatel.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: 5578
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: willem.acke@alcatel.be
Precedence: bulk
X-list: linux-mips

All,

I'm trying to port the mips-kernel to a RM9000x2 based custom board.
The kernel file (mips 32) is loaded using VxWorks boot loader.
I got the to the point where the kernel starts loading, but exits with a 
'TLB load exception'.
After putting in a number of printks, it seems that it fails on 
'flush_icache_range' in arch/mips/mm/pg-r4k.c -> build_clear_page.
Since I'm a newbie to this, any pointers to how to tackle this problem 
would be appreciated.

Exception:
Tlb Load Exception
Exception Program Counter: 0x00000000
Status Register: 0x3404ff00
Cause Register: 0x01100008
Access Address : 0x00000000
Task: 0x83e2c760 ""

$0    =                0   t0    =          3ffffff   s0    =         
24810e00
at    =         3404ff00   t1    = fffffffffc1fffff   s1    = 
ffffffffac800000
v0    =                0   t2    = ffffffffffff0000   s2    = 
ffffffffac800004
v1    =                1   t3    =           800000   s3    = 
ffffffffcc9e0200
a0    = ffffffff801a6f30   t4    = ffffffffac000000   s4    = 
ffffffffac800008
a1    = ffffffff801a6f94   t5    =            40000   s5    = 
ffffffffac80000c
a2    = ffffffff801508e8   t6    =             7fff   s6    
=                0
a3    = ffffffff80173e84   t7    =         24000000   s7    =         
24840020
s8    = ffffffff83e2c268   k0    =                0
gp    = ffffffff80172000   k1    =                0   t8    
=                a
ra    = ffffffff80179254   sp    = ffffffff80173e80   t9    = 
ffffffffac80fff8
divlo =             1000   divhi =                0   sr    = 3404ff00
pc    =        0

Thanks in advance,

Wim Acke


From nigel@mips.com Mon Aug  2 21:04:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Aug 2004 21:04:12 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:18181 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225002AbUHBUEH>;
	Mon, 2 Aug 2004 21:04:07 +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 1BrjDw-0000wY-00; Mon, 02 Aug 2004 21:15:56 +0100
Received: from highbury.mips.com ([192.168.192.236] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1Brj2D-0002WQ-00; Mon, 02 Aug 2004 21:03:49 +0100
Message-ID: <410E9E25.7080104@mips.com>
Date: Mon, 02 Aug 2004 21:03:49 +0100
From: Nigel Stephens <nigel@mips.com>
Organization: MIPS Technologies
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.4) Gecko/20030624
X-Accept-Language: en-gb, en-us, en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@linux-mips.org>
CC: Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@redhat.com>,
	Richard Sandiford <rsandifo@redhat.com>,
	gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl> <87hds49bmo.fsf@redhat.com> <Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl> <20040719213801.GD14931@redhat.com> <Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl> <20040723202703.GB30931@redhat.com> <20040723211232.GB5138@linux-mips.org> <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-3.9, required 4, AWL,
	BAYES_00, USER_AGENT_MOZILLA_UA)
Return-Path: <nigel@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: 5579
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nigel@mips.com
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:

>On Fri, 23 Jul 2004, Ralf Baechle wrote:
>
>  
>
>>With a bit of hand waiving because haven't done benchmarks I guess Richard
>>might be right.  The subroutine calling overhead on modern processors is
>>rather low and smaller code means better cache hit rates ...
>>    
>>
>
> Well, I just worry the call may itself include at least the same number
>of instructions as the callee if inlined.  There would be no way for it to
>be faster.
>
> That may happen for a leaf function -- the call itself, plus $ra
>saving/restoration is already four instructions.  Now it's sufficient for
>two statics to be needed to preserve temporaries across such a call and
>the size of the caller is already the same.  With three statics, you lose
>even for a non-leaf function.  That's for a function containing a single
>call to such a shift -- if there are more, then you may win (but is it
>common?).
>
> So not only it may not be faster, but the resulting code may be bigger as
>well.  That said, the current GCC's implementation of these operations is
>not exactly optimal for current MIPS processors.  That's trivial to deal
>with in Linux, but would it be possible to pick a different implementation
>from libgcc based on the "-march=" setting, too?
>
> 
>

I second Maciej. My own recent experience when tuning the hell out of a 
software floating-point emulator was that efficient 64-bit shifts were 
really critical. I have a patch against gcc-3.4 which makes the 64-bit 
inline shifts somewhat smaller on ISAs which include the conditional 
move (movz/movn) instructions, but more importantly removes all branches 
from the inline code - which can be very expensive on long pipeline 
CPUs, since in this sort of code they tend to cause many branch 
mispredicts. Let me know if you want me to extract the patch - here's a 
table of the number of instructions generated by the original md pattern 
and the patched version:

		Instructions
		Old	New
ashldi3		12	9
ashrdi3		12	12
lshrdi3		12	9


If people really don't like the inline expansion, then maybe it could be 
enabled or disabled by a new -m option.

Nigel

-- 
                         Nigel Stephens         Mailto:nigel@mips.com
    _    _ ____  ___     MIPS Technologies      Phone.: +44 1223 706200
    |\  /|||___)(___     The Fruit Farm         Direct: +44 1223 706207
    | \/ |||    ____)    Ely Road, Chittering   Fax...: +44 1223 706250
     TECHNOLOGIES UK     Cambridge CB5 9PH      Cell..: +44 7976 686470
                         England                http://www.mips.com



From ralf@linux-mips.org Mon Aug  2 22:31:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Aug 2004 22:31:49 +0100 (BST)
Received: from p508B7C48.dip.t-dialin.net ([IPv6:::ffff:80.139.124.72]:24605
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224930AbUHBVbp>; Mon, 2 Aug 2004 22:31:45 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i72LVhkK008057;
	Mon, 2 Aug 2004 23:31:43 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i72LVgdW008056;
	Mon, 2 Aug 2004 23:31:42 +0200
Date: Mon, 2 Aug 2004 23:31:42 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: willem.acke@alcatel.be
Cc: linux-mips@linux-mips.org
Subject: Re: RM9000x2 TLB load exception
Message-ID: <20040802213142.GB3980@linux-mips.org>
References: <410E071F.4060907@alcatel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <410E071F.4060907@alcatel.be>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5580
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Aug 02, 2004 at 11:19:27AM +0200, willem.acke@alcatel.be wrote:

> I'm trying to port the mips-kernel to a RM9000x2 based custom board.
> The kernel file (mips 32) is loaded using VxWorks boot loader.
> I got the to the point where the kernel starts loading, but exits with a 
> 'TLB load exception'.
> After putting in a number of printks, it seems that it fails on 
> 'flush_icache_range' in arch/mips/mm/pg-r4k.c -> build_clear_page.
> Since I'm a newbie to this, any pointers to how to tackle this problem 
> would be appreciated.

Funny :-)  This is a particularly crazy function where I decieded to
generate the clear_function at runtime since we had to many versions
optimized for the one or other processor or configuration which had
become excessivly large.

> Exception:
> Tlb Load Exception
> Exception Program Counter: 0x00000000
> Status Register: 0x3404ff00
> Cause Register: 0x01100008
> Access Address : 0x00000000
> Task: 0x83e2c760 ""
[...]

The register dump is unseless since you didn't say what all the addresses
point to.

Other information that's needed to make sense out of a bug report would be:

 - gcc and binutils version used to compile the kernel
 - kernel version and also where did you get it from (linux-mips.org?)

  Ralf

From rsandifo@redhat.com Tue Aug  3 06:30:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Aug 2004 06:30:47 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:40633 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224850AbUHCFam>;
	Tue, 3 Aug 2004 06:30:42 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i735Uee1015116;
	Tue, 3 Aug 2004 01:30:40 -0400
Received: from localhost (mail@vpnuser3.surrey.redhat.com [172.16.9.3])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i735Uda22551;
	Tue, 3 Aug 2004 01:30:39 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1Brrsk-0000D2-00; Tue, 03 Aug 2004 06:30:38 +0100
To: Nigel Stephens <nigel@mips.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl>
	<87hds49bmo.fsf@redhat.com>
	<Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl>
	<20040719213801.GD14931@redhat.com>
	<Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl>
	<20040723202703.GB30931@redhat.com>
	<20040723211232.GB5138@linux-mips.org>
	<Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl>
	<410E9E25.7080104@mips.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Tue, 03 Aug 2004 06:30:38 +0100
In-Reply-To: <410E9E25.7080104@mips.com> (Nigel Stephens's message of "Mon,
 02 Aug 2004 21:03:49 +0100")
Message-ID: <87acxcbxfl.fsf@redhat.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@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: 5581
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

Nigel Stephens <nigel@mips.com> writes:
> I have a patch against gcc-3.4 which makes the 64-bit inline shifts
> somewhat smaller on ISAs which include the conditional move
> (movz/movn) instructions, but more importantly removes all branches
> from the inline code - which can be very expensive on long pipeline
> CPUs, since in this sort of code they tend to cause many branch
> mispredicts. Let me know if you want me to extract the patch - here's
> a table of the number of instructions generated by the original md
> pattern and the patched version:
>
> 		Instructions
> 		Old	New
> ashldi3		12	9
> ashrdi3		12	12
> lshrdi3		12	9
>
>
> If people really don't like the inline expansion, then maybe it could be
> enabled or disabled by a new -m option.

IMO, controlling with optimize_size would be enough.  But it sounds from
your description like the patch just adds a new hard-coded multi-insn
asm string.  Is that right?  If so, I'd really like to avoid that.

It would much better IMO if we handle this in the target-independent
parts of the compiler.  We can already open-code certain non-native
operations, it's "just" that wide shifts are a missing case.

If we handle it in a target-independent way, with each insn exposed
separately, we will be able to optimize special cases better.
We'll also get the usual scheduling benefits.

Richard

From nigel@mips.com Tue Aug  3 10:23:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Aug 2004 10:23:16 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:2566 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224936AbUHCJXL>;
	Tue, 3 Aug 2004 10:23:11 +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 1Brvh5-0000pM-00; Tue, 03 Aug 2004 10:34:51 +0100
Received: from kingsx.mips.com ([192.168.192.254] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1BrvV5-0003uH-00; Tue, 03 Aug 2004 10:22:27 +0100
Message-ID: <410F5964.3010109@mips.com>
Date: Tue, 03 Aug 2004 10:22:44 +0100
From: Nigel Stephens <nigel@mips.com>
Organization: MIPS Technologies
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Richard Sandiford <rsandifo@redhat.com>
CC: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl>	<87hds49bmo.fsf@redhat.com>	<Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl>	<20040719213801.GD14931@redhat.com>	<Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl>	<20040723202703.GB30931@redhat.com>	<20040723211232.GB5138@linux-mips.org>	<Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl>	<410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com>
In-Reply-To: <87acxcbxfl.fsf@redhat.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.85, required 4, AWL,
	BAYES_00)
Return-Path: <nigel@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: 5582
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nigel@mips.com
Precedence: bulk
X-list: linux-mips



Richard Sandiford wrote:

>Nigel Stephens <nigel@mips.com> writes:
>  
>
>>I have a patch against gcc-3.4 
>><snip>
>>If people really don't like the inline expansion, then maybe it could be
>>enabled or disabled by a new -m option.
>>    
>>
>
>IMO, controlling with optimize_size would be enough.  
>

Yes, that sounds right.

>But it sounds from
>your description like the patch just adds a new hard-coded multi-insn
>asm string.  Is that right?  If so, I'd really like to avoid that.
>
>  
>

Yes, and I totally agree with you.

>It would much better IMO if we handle this in the target-independent
>parts of the compiler.  We can already open-code certain non-native
>operations, it's "just" that wide shifts are a missing case.
>
>  
>

>If we handle it in a target-independent way, with each insn exposed
>separately, we will be able to optimize special cases better.
>We'll also get the usual scheduling benefits.
>  
>

I agree that we should open-code it for the obvious reasons, but does it 
have to be target independent, or could/should we prototype it with 
define_expand?

Nigel

From rsandifo@redhat.com Tue Aug  3 10:36:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Aug 2004 10:36:18 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:48045 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224935AbUHCJgO>;
	Tue, 3 Aug 2004 10:36:14 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i739aCe1002002;
	Tue, 3 Aug 2004 05:36:12 -0400
Received: from localhost (mail@vpnuser3.surrey.redhat.com [172.16.9.3])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i739aBa08652;
	Tue, 3 Aug 2004 05:36:11 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1BrviM-0006kp-00; Tue, 03 Aug 2004 10:36:10 +0100
To: Nigel Stephens <nigel@mips.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl>
	<87hds49bmo.fsf@redhat.com>
	<Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl>
	<20040719213801.GD14931@redhat.com>
	<Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl>
	<20040723202703.GB30931@redhat.com>
	<20040723211232.GB5138@linux-mips.org>
	<Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl>
	<410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com>
	<410F5964.3010109@mips.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Tue, 03 Aug 2004 10:36:09 +0100
In-Reply-To: <410F5964.3010109@mips.com> (Nigel Stephens's message of "Tue,
 03 Aug 2004 10:22:44 +0100")
Message-ID: <876580bm2e.fsf@redhat.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@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: 5583
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

Nigel Stephens <nigel@mips.com> writes:
>>If we handle it in a target-independent way, with each insn exposed
>>separately, we will be able to optimize special cases better.
>>We'll also get the usual scheduling benefits.
>
> I agree that we should open-code it for the obvious reasons, but does it
> have to be target independent, or could/should we prototype it with
> define_expand?

I think we should only use define_expands if there's a truly
MIPS-specific feature in the expansion (as there is in the block
move stuff, for example, where we use left/right loads and stores).

Now obviously I'm only guessing what insn sequence you're using,
but I suspect it doesn't involve anything that the middle-end
couldn't work out from stock optabs.  If there are different
trade-offs to be made during the expansion, they should probably
be predicated on rtx_costs.

Richard

From nigel@mips.com Tue Aug  3 10:54:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Aug 2004 10:54:57 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:20748 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224935AbUHCJyw>;
	Tue, 3 Aug 2004 10:54:52 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1BrwBn-00021m-00; Tue, 03 Aug 2004 11:06:35 +0100
Received: from kingsx.mips.com ([192.168.192.254] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1Brvzx-0004NX-00; Tue, 03 Aug 2004 10:54:21 +0100
Message-ID: <410F60DF.9020400@mips.com>
Date: Tue, 03 Aug 2004 10:54:39 +0100
From: Nigel Stephens <nigel@mips.com>
Organization: MIPS Technologies
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Richard Sandiford <rsandifo@redhat.com>
CC: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl>	<87hds49bmo.fsf@redhat.com>	<Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl>	<20040719213801.GD14931@redhat.com>	<Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl>	<20040723202703.GB30931@redhat.com>	<20040723211232.GB5138@linux-mips.org>	<Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl>	<410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com>	<410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com>
In-Reply-To: <876580bm2e.fsf@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.855, required 4, AWL,
	BAYES_00)
Return-Path: <nigel@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: 5584
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nigel@mips.com
Precedence: bulk
X-list: linux-mips



Richard Sandiford wrote:

>I think we should only use define_expands if there's a truly
>MIPS-specific feature in the expansion (as there is in the block
>move stuff, for example, where we use left/right loads and stores).
>
>  
>

Fair enough.

>Now obviously I'm only guessing what insn sequence you're using,
>  
>

OK, the simplest thing is for me to attach the define_insns. See below.

Note that there is one slightly controversial aspect of these sequences, 
which is that they don't truncate the shift count, so a shift outside of 
the range 0 to 63 will generate an "unusual" result.  This didn't cause 
any regression failures, and I believe that this is strictly speaking 
acceptable for C, since a shift is undefined outside of this range - but 
it could cause some "buggy" code to break. It wouldn't be hard to add an 
extra mask with 0x3f if people were nervous about this - it's just that 
I didn't have enough spare temp registers within the constraints of the 
existing DImode patterns.

---- cut here ---

;; XXX Would be better done using define_expand, so it can be scheduled
;; XXX Note won't handle a shift count outside the range 0 - 63
(define_insn "ashldi3_internal_movc"
  [(set (match_operand:DI 0 "register_operand" "=&d")
    (ashift:DI (match_operand:DI 1 "register_operand" "d")
           (match_operand:SI 2 "register_operand" "d")))
   (clobber (match_operand:SI 3 "register_operand" "=&d"))]
  "!TARGET_64BIT && !TARGET_DEBUG_G_MODE && !TARGET_MIPS16
   && ISA_HAS_CONDMOVE"
  "subu\t%3,%.,%2\;\
sll\t%M0,%M1,%2\;\
srl\t%3,%L1,%3\;\
sll\t%L0,%L1,%2\;\
movz\t%3,%.,%2\;\
or\t%M0,%M0,%3\;\
and\t%3,%2,32\;\
movn\t%M0,%L0,%3\;\
movn\t%L0,%.,%3"
  [(set_attr "type"    "darith")
   (set_attr "mode"    "DI")
   (set_attr "length"    "36")])

;; Same length as before, but avoids branches
;; XXX Note won't handle a shift count outside the range 0 - 63
(define_insn "ashrdi3_internal_movc"
  [(set (match_operand:DI 0 "register_operand" "=&d")
    (ashiftrt:DI (match_operand:DI 1 "register_operand" "d")
             (match_operand:SI 2 "register_operand" "d")))
   (clobber (match_operand:SI 3 "register_operand" "=&d"))]
  "!TARGET_64BIT && !TARGET_DEBUG_G_MODE && !TARGET_MIPS16
   && ISA_HAS_CONDMOVE"
  "subu\t%3,%.,%2\;\
srl\t%L0,%L1,%2\;\
sll\t%3,%M1,%3\;\
sra\t%M0,%M1,%2\;\
movz\t%3,%.,%2\;\
or\t%L0,%L0,%3\;\
and\t%3,%2,32\;\
movn\t%L0,%M0,%3\;\
movn\t%M0,%.,%3\;\
movn\t%3,%L0,%3\;\
sra\t%3,%3,31\;\
or\t%M0,%M0,%3"
  [(set_attr "type"    "darith")
   (set_attr "mode"    "DI")
   (set_attr "length"    "48")])

;;; XXX Note won't handle a shift count outside the range 0 - 63
(define_insn "lshrdi3_internal_movc"
  [(set (match_operand:DI 0 "register_operand" "=&d")
    (lshiftrt:DI (match_operand:DI 1 "register_operand" "d")
             (match_operand:SI 2 "register_operand" "d")))
   (clobber (match_operand:SI 3 "register_operand" "=&d"))]
  "!TARGET_64BIT && !TARGET_DEBUG_G_MODE && !TARGET_MIPS16
   && ISA_HAS_CONDMOVE"
  "subu\t%3,%.,%2\;\
srl\t%L0,%L1,%2\;\
sll\t%3,%M1,%3\;\
srl\t%M0,%M1,%2\;\
movz\t%3,%.,%2\;\
or\t%L0,%L0,%3\;\
and\t%3,%2,32\;\
movn\t%L0,%M0,%3\;\
movn\t%M0,%.,%3"
  [(set_attr "type"    "darith")
   (set_attr "mode"    "DI")
   (set_attr "length"    "36")])


From a.voropay@vmb-service.ru Tue Aug  3 15:09:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Aug 2004 15:09:55 +0100 (BST)
Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:924 "EHLO
	smtp.vmb-service.ru") by linux-mips.org with ESMTP
	id <S8224907AbUHCOJv>; Tue, 3 Aug 2004 15:09:51 +0100
Received: from office.vmb-service.ru ([80.73.192.47]:48391 "HELO portege")
	by Altair with SMTP id <S1168255AbUHCOJf>;
	Tue, 3 Aug 2004 18:09:35 +0400
Message-ID: <01ed01c47963$bc74a220$1701a8c0@portege>
From: "Alec Voropay" <a.voropay@vmb-service.ru>
To: <linux-mips@linux-mips.org>
Subject: SGI ARC .vs. ACE ARC BIOS
Date: Tue, 3 Aug 2004 18:11:12 +0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4942.400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400
Return-Path: <a.voropay@vmb-service.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: 5585
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: a.voropay@vmb-service.ru
Precedence: bulk
X-list: linux-mips

Hi!

 Can anyone explain a difference between SGI ARC BOOT-PROM
(sometimes called ARCS) and an old ACE ARC BIOS (Jazz/Magnum) ?
Is this equal (in functionality, not command line) ?

P.S.
http://www.netbsd.org/Documentation/Hardware/Machines/ARC/


--
-=AV=-


From giles67@yahoo.com Tue Aug  3 17:19:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Aug 2004 17:20:03 +0100 (BST)
Received: from web50803.mail.yahoo.com ([IPv6:::ffff:206.190.38.112]:61083
	"HELO web50803.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224907AbUHCQT4>; Tue, 3 Aug 2004 17:19:56 +0100
Message-ID: <20040803161949.89148.qmail@web50803.mail.yahoo.com>
Received: from [65.204.143.11] by web50803.mail.yahoo.com via HTTP; Tue, 03 Aug 2004 09:19:49 PDT
Date: Tue, 3 Aug 2004 09:19:49 -0700 (PDT)
From: G H <giles67@yahoo.com>
Subject: do_ri failure in cache flushing routines
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1918942025-1091549989=:87300"
Return-Path: <giles67@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: 5586
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: giles67@yahoo.com
Precedence: bulk
X-list: linux-mips

--0-1918942025-1091549989=:87300
Content-Type: text/plain; charset=us-ascii

While testing out an amd au1500 based board I have been getting " do_ri " exceptions that always occur in the cache flushing routines. More often than not in blast_icache_32().
 
So far this has mainly happened after running the board for days on end while running multiple telnet sessions to it. It has sometimes ( quite rarely ) happened after a few hours to a day of multiple telnet session use.
 
If left to run for days on end the the do_ri always occurs in a lcd daemon we have for updating a simple 40 row by 2 column I2c dispay and the oops trace is :
 
Reading Oops report from the terminal
$0 : 00000000 1000fc01 7fff76e0 ffffffe0 7fff76e0 8034880c ffffffff 00000000
$8 : ffffffff ffffffff 00000000 00000002 80313ae4 0005800b 00000340 849dbe20
$16: 7fff76d8 7fff7ea4 00416050 0000000e 8437ff30 00000000 8436da5c 8437e3d0
$24: 00000000 2afb0900                   8437e000 8437fe30 8437ff08 80105510
Hi : 00000000
Lo : 00000001
epc   : 8010cd50    Not tainted
Using defaults from ksymoops -t elf32-tradlittlemips -a mips:3000
Status: 1000fc03
Cause : 00800028
Process lcd (pid: 106, stackpage=8437e000)
Stack:    1000fc01 00000001 00000000 00000001 0000000e 00000080 00000000
 00000000 00000000 00000003 00000000 0000000a 00000001 802feda0 8437e000
 802fe920 84cec000 00000000 802fe920 803487e0 00000000 2ab34390 00000010
 80156614 8437e000 8437feb8 8437feb8 80104a98 1000fc03 b3b77d7a 000006c5
 00000021 00801000 8010f690 ffffffff 10015d08 7fff76e8 7fff76f0 1000fc01
 00000000 ...
Call Trace:   [<80156614>] [<80104a98>] [<8010f690>] [<80104aa4>] [<801097a0>]
 [<80162038>]
 Code: bc550000  00031823  00832024 <bc900000> 03e00008  00000000  3c028035  8c42881c  27bdffe8

>>$5; 8034880c <cpu_data+2c/80>
>>$12; 80313ae4 <contig_page_data+0/3ac>
>>$31; 80105510 <do_signal+2a8/df8>
>>PC;  8010cd50 <r4k_flush_cache_sigtramp+24/30>   <=====
Trace; 80156614 <iput+128/2b4>
Trace; 80104a98 <_sys_rt_sigsuspend+164/180>
Trace; 8010f690 <schedule+2d8/4fc>
Trace; 80104aa4 <_sys_rt_sigsuspend+170/180>
Trace; 801097a0 <stack_done+1c/38>
Trace; 80162038 <create_proc_entry+58/d0>
Code;  8010cd44 <r4k_flush_cache_sigtramp+18/30>
00000000 <_PC>:
Code;  8010cd44 <r4k_flush_cache_sigtramp+18/30>
   0:   bc550000  0xbc550000
Code;  8010cd48 <r4k_flush_cache_sigtramp+1c/30>
   4:   00031823  negu    v1,v1
Code;  8010cd4c <r4k_flush_cache_sigtramp+20/30>
   8:   00832024  and     a0,a0,v1
Code;  8010cd50 <r4k_flush_cache_sigtramp+24/30>   <=====
   c:   bc900000  0xbc900000   <=====
Code;  8010cd54 <r4k_flush_cache_sigtramp+28/30>
  10:   03e00008  jr      ra
Code;  8010cd58 <r4k_flush_cache_sigtramp+2c/30>
  14:   00000000  nop
Code;  8010cd5c <r4k_flush_icache_all+0/3c>
  18:   3c028035  lui     v0,0x8035
Code;  8010cd60 <r4k_flush_icache_all+4/3c>
  1c:   8c42881c  lw      v0,-30692(v0)
Code;  8010cd64 <r4k_flush_icache_all+8/3c>
  20:   27bdffe8  addiu   sp,sp,-24
 
But on the times it has happened after a few hours / a day or so it has happened due to activity on the serial console when running general linux commands the oops traces are at the end of this email.
 
I am using a 2.4.24 kernel from linux-mips cvs. 
 
Does anyone have any idea what could be causing this ? And possible ways to fix it ?
 
Can someone explain to me why the cache flushing routines are triggering a "reserved instruction" at random like this when up to the point of failure the same code must have been executed millions of times without triggering the exception ?
 
Any help in debugging this is greatly appreciated.
 
 
Failure in sshd :
 
Reserved instruction in kernel code in traps.c::do_ri, line 663:
 $0 : 00000000 80000000 80001c00 80001000 80000c00 00001000 00000001 00004000
 $8 : 00001000 00000000 820700f0 00000000 2afaee50 2afaee9c fffffff8 fffffffa
 $16: 810517c8 823acf60 0041ee48 820700f0 0041ee48 00000000 802feda0 00000000
 $24: fffffffe 0041ee48                   81dd4000 81dd5d98 00000004 8010cabc
 Hi : ffffa71d
 Lo : 00001da1
 epc   : 8010d66c    Not tainted
Using defaults from ksymoops -t elf32-tradlittlemips -a mips:3000
 Status: 1000fc03
 Cause : 00800028
 Process sshd (pid: 631, stackpage=81dd4000)
 Stack:    0041ee48 820700f0 0041ee48 00000000 810517c8 823acf60 0041ee48
  80125138 74737271 78777675 000000d8 0015a298 100151fc 0007831e 000000d8
  0015a298 00000000 00000000 000000d8 0015a298 000007de 0007831e 802feda0
  00000000 0041ee48 823acf60 81dd5f30 00000000 802fedbc 00000001 80125460
  801253f4 826d5cf0 82030a20 81dd5ed0 81dd5ed0 820700f0 0007831a 7fff78b0
  00000005 ...
 Call Trace:   [<80125138>] [<80125460>] [<801253f4>] [<80133d74>] [<8010c1d8>]
  [<8023112c>] [<80231510>] [<80126d88>] [<80125a0c>] [<8010e8bc>]
 Code: bc400260  bc400280  bc4002a0 <bc4002c0> bc4002e0  bc400300  bc400320  bc400340  bc400360

>>$22; 802feda0 <pci_socket_init+20/58>
>>$31; 8010cabc <r4k_flush_icache_page+138/218>
>>PC;  8010d66c <blast_icache32+a0/f0>   <=====
Trace; 80125138 <do_no_page+144/3b8>
Trace; 80125460 <handle_mm_fault+b4/278>
Trace; 801253f4 <handle_mm_fault+48/278>
Trace; 80133d74 <free_pages+48/50>
Trace; 8010c1d8 <do_page_fault+160/3c8>
Trace; 8023112c <sock_recvmsg+48/104>
Trace; 80231510 <sock_poll+28/34>
Trace; 80126d88 <do_brk+16c/23c>
Trace; 80125a0c <sys_brk+c8/140>
Trace; 8010e8bc <nopage_tlbl+f0/114>
Code;  8010d660 <blast_icache32+94/f0>
00000000 <_PC>:
Code;  8010d660 <blast_icache32+94/f0>
   0:   bc400260  0xbc400260
Code;  8010d664 <blast_icache32+98/f0>
   4:   bc400280  0xbc400280
Code;  8010d668 <blast_icache32+9c/f0>
   8:   bc4002a0  0xbc4002a0
Code;  8010d66c <blast_icache32+a0/f0>   <=====
   c:   bc4002c0  0xbc4002c0   <=====
Code;  8010d670 <blast_icache32+a4/f0>
  10:   bc4002e0  0xbc4002e0
Code;  8010d674 <blast_icache32+a8/f0>
  14:   bc400300  0xbc400300
Code;  8010d678 <blast_icache32+ac/f0>
  18:   bc400320  0xbc400320
Code;  8010d67c <blast_icache32+b0/f0>
  1c:   bc400340  0xbc400340
Code;  8010d680 <blast_icache32+b4/f0>
  20:   bc400360  0xbc400360

Failure in ls :
 

Reading Oops report from the terminal
Reserved instruction in kernel code in traps.c::do_ri, line 663:
$0 : 00000000 80000000 80002000 80001000 80000000 00002000 000079d8 00004000
$8 : 00000001 00000000 8349a0e8 00000b3b 7f1c0300 00000001 65726168 00000115
$16: 810e7d2c 834cb740 0041da54 8349a0e8 0041da54 00000000 83a96460 00000000
$24: 00000000 2abede20                   8010f58b 83481d98 00000000 8010cabc
Hi : ffff031c
Lo : 0000544c
epc   : 8010d634    Not tainted
Using defaults from ksymoops -t elf32-tradlittlemips -a mips:3000
Status: 1000fc03
Cause : 00800028
Process ls (pid: 1335, stackpage=83480000)
Stack:    0041da54 8349a0e8 0041da54 00000000 810e7d2c 834cb740 0041da54
 80125138 4c4b4a49 504f4e4d 000000d8 0010b2d8 62615a59 66656463 000000d8
 0010b2d8 00000000 00000000 000000d8 0010b2d8 48474645 4c4b4a49 83a96460
 00000000 0041da54 834cb740 83481f30 00000000 83a9647c 00000000 80125460
 801253f4 44434241 48474645 7fff7ce0 00000000 8349a0e8 83481eb8 80312cd0
 2ad2d520 ...
Call Trace:   [<80125138>] [<80125460>] [<801253f4>] [<801198e8>] [<8010c1d8>]
 [<801bf480>] [<80125b4c>] [<80126e08>] [<801ae43c>] [<8014de3c>] [<80125a0c>]
 [<8010e8bc>]
Code: bc4000a0  bc4000c0  bc4000e0 <bc400100> bc400120  bc400140  bc400160  bc400180  bc4001a0

>>$28; 8010f58b <schedule+1d3/4fc>
>>$31; 8010cabc <r4k_flush_icache_page+138/218>
>>PC;  8010d634 <blast_icache32+68/f0>   <=====
Trace; 80125138 <do_no_page+144/3b8>
Trace; 80125460 <handle_mm_fault+b4/278>
Trace; 801253f4 <handle_mm_fault+48/278>
Trace; 801198e8 <parse_table+16c/174>
Trace; 8010c1d8 <do_page_fault+160/3c8>
Trace; 801bf480 <ltxser_interrupt+204/32c>
Trace; 80125b4c <__vma_link+44/dc>
Trace; 80126e08 <do_brk+1ec/23c>
Trace; 801ae43c <tty_ioctl+15c/51c>
Trace; 8014de3c <sys_ioctl+a0/2e4>
Trace; 80125a0c <sys_brk+c8/140>
Trace; 8010e8bc <nopage_tlbl+f0/114>
Code;  8010d628 <blast_icache32+5c/f0>
00000000 <_PC>:
Code;  8010d628 <blast_icache32+5c/f0>
   0:   bc4000a0  0xbc4000a0
Code;  8010d62c <blast_icache32+60/f0>
   4:   bc4000c0  0xbc4000c0
Code;  8010d630 <blast_icache32+64/f0>
   8:   bc4000e0  0xbc4000e0
Code;  8010d634 <blast_icache32+68/f0>   <=====
   c:   bc400100  0xbc400100   <=====
Code;  8010d638 <blast_icache32+6c/f0>
  10:   bc400120  0xbc400120
Code;  8010d63c <blast_icache32+70/f0>
  14:   bc400140  0xbc400140
Code;  8010d640 <blast_icache32+74/f0>
  18:   bc400160  0xbc400160
Code;  8010d644 <blast_icache32+78/f0>
  1c:   bc400180  0xbc400180
Code;  8010d648 <blast_icache32+7c/f0>
  20:   bc4001a0  0xbc4001a0

Failure in stat:
 
Reserved instruction in kernel code in traps.c::do_ri, line 663:
$0 : 00000000 80000000 80002400 80001000 80000400 00002000 000079d8 00004000
$8 : 00000001 00000000 82ea8828 6ffffeff 6fffff72 00000063 40f2d4f7 00000000
$16: 810eeb84 834cb920 2ab051ac 82ea8828 2ab051ac 00000000 83a96460 00000000
$24: 00000000 2aabcd10                   8010f58b 82eb5d98 7fff7678 8010cabc
Hi : fffefb96
Lo : 000056ce
epc   : 8010d650    Not tainted
Using defaults from ksymoops -t elf32-tradlittlemips -a mips:3000
Status: 1000fc03
Cause : 00800028
Process stat (pid: 1376, stackpage=82eb4000)
Stack:    2ab051ac 82ea8828 2ab051ac 00000000 810eeb84 834cb920 2ab051ac
 80125138 00000000 856ff768 000000d8 0015b458 000005dc 000baa5c 000000d8
 0015b458 00000000 00000000 000000d8 0015b458 000000d8 000baa58 83a96460
 00000000 2ab051ac 834cb920 82eb5f30 00000000 83a9647c 00000001 80125460
 801253f4 834cb938 834cb920 834cbbc0 834cbbc0 82ea8828 0015bb1a 801267c8
 8010e8bc ...
Call Trace:   [<80125138>] [<80125460>] [<801253f4>] [<801267c8>] [<8010e8bc>]
 [<8010c1d8>] [<80126068>] [<8012d008>] [<801a074c>] [<80108034>] [<8010e8bc>]
Code: bc400180  bc4001a0  bc4001c0 <bc4001e0> bc400200  bc400220  bc400240  bc400260  bc400280

>>$28; 8010f58b <schedule+1d3/4fc>
>>$31; 8010cabc <r4k_flush_icache_page+138/218>
>>PC;  8010d650 <blast_icache32+84/f0>   <=====
Trace; 80125138 <do_no_page+144/3b8>
Trace; 80125460 <handle_mm_fault+b4/278>
Trace; 801253f4 <handle_mm_fault+48/278>
Trace; 801267c8 <unmap_fixup+1e4/1fc>
Trace; 8010e8bc <nopage_tlbl+f0/114>
Trace; 8010c1d8 <do_page_fault+160/3c8>
Trace; 80126068 <do_mmap_pgoff+350/5b0>
Trace; 8012d008 <mprotect_fixup+1f0/534>
Trace; 801a074c <fpu_emulator_cop1Handler+198/1bc>
Trace; 80108034 <do_cpu+2e0/334>
Trace; 8010e8bc <nopage_tlbl+f0/114>
Code;  8010d644 <blast_icache32+78/f0>
00000000 <_PC>:
Code;  8010d644 <blast_icache32+78/f0>
   0:   bc400180  0xbc400180
Code;  8010d648 <blast_icache32+7c/f0>
   4:   bc4001a0  0xbc4001a0
Code;  8010d64c <blast_icache32+80/f0>
   8:   bc4001c0  0xbc4001c0
Code;  8010d650 <blast_icache32+84/f0>   <=====
   c:   bc4001e0  0xbc4001e0   <=====
Code;  8010d654 <blast_icache32+88/f0>
  10:   bc400200  0xbc400200
Code;  8010d658 <blast_icache32+8c/f0>
  14:   bc400220  0xbc400220
Code;  8010d65c <blast_icache32+90/f0>
  18:   bc400240  0xbc400240
Code;  8010d660 <blast_icache32+94/f0>
  1c:   bc400260  0xbc400260
Code;  8010d664 <blast_icache32+98/f0>
  20:   bc400280  0xbc400280

  

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
--0-1918942025-1091549989=:87300
Content-Type: text/html; charset=us-ascii

<DIV>While testing out an amd au1500 based board I have been getting " do_ri "&nbsp;exceptions that always occur in the cache flushing routines. More often than not in blast_icache_32().</DIV>
<DIV>&nbsp;</DIV>
<DIV>So far this has mainly happened after&nbsp;running the board for days on end while running multiple telnet sessions to it. It has sometimes ( quite rarely ) happened after a few hours to a day of multiple telnet session use.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If left to run for days on end the the do_ri always occurs in a lcd daemon we have for updating a simple 40 row by 2 column I2c dispay and the oops trace is :</DIV>
<DIV>&nbsp;</DIV>
<DIV>Reading Oops report from the terminal<BR>$0 : 00000000 1000fc01 7fff76e0 ffffffe0 7fff76e0 8034880c ffffffff 00000000<BR>$8 : ffffffff ffffffff 00000000 00000002 80313ae4 0005800b 00000340 849dbe20<BR>$16: 7fff76d8 7fff7ea4 00416050 0000000e 8437ff30 00000000 8436da5c 8437e3d0<BR>$24: 00000000 2afb0900&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8437e000 8437fe30 8437ff08 80105510<BR>Hi : 00000000<BR>Lo : 00000001<BR>epc&nbsp;&nbsp; : 8010cd50&nbsp;&nbsp;&nbsp; Not tainted<BR>Using defaults from ksymoops -t elf32-tradlittlemips -a mips:3000<BR>Status: 1000fc03<BR>Cause : 00800028<BR>Process lcd (pid: 106, stackpage=8437e000)<BR>Stack:&nbsp;&nbsp;&nbsp; 1000fc01 00000001 00000000 00000001 0000000e 00000080 00000000<BR>&nbsp;00000000 00000000 00000003 00000000 0000000a 00000001 802feda0 8437e000<BR>&nbsp;802fe920 84cec000 00000000 802fe920 803487e0 00000000 2ab34390 00000010<BR>&nbsp;80156614 8437e000 8437feb8
 8437feb8 80104a98 1000fc03 b3b77d7a 000006c5<BR>&nbsp;00000021 00801000 8010f690 ffffffff 10015d08 7fff76e8 7fff76f0 1000fc01<BR>&nbsp;00000000 ...<BR>Call Trace:&nbsp;&nbsp; [&lt;80156614&gt;] [&lt;80104a98&gt;] [&lt;8010f690&gt;] [&lt;80104aa4&gt;] [&lt;801097a0&gt;]<BR>&nbsp;[&lt;80162038&gt;]<BR>&nbsp;Code: bc550000&nbsp; 00031823&nbsp; 00832024 &lt;bc900000&gt; 03e00008&nbsp; 00000000&nbsp; 3c028035&nbsp; 8c42881c&nbsp; 27bdffe8</DIV>
<DIV><BR>&gt;&gt;$5; 8034880c &lt;cpu_data+2c/80&gt;<BR>&gt;&gt;$12; 80313ae4 &lt;contig_page_data+0/3ac&gt;<BR>&gt;&gt;$31; 80105510 &lt;do_signal+2a8/df8&gt;</DIV>
<DIV>&gt;&gt;PC;&nbsp; 8010cd50 &lt;r4k_flush_cache_sigtramp+24/30&gt;&nbsp;&nbsp; &lt;=====</DIV>
<DIV>Trace; 80156614 &lt;iput+128/2b4&gt;<BR>Trace; 80104a98 &lt;_sys_rt_sigsuspend+164/180&gt;<BR>Trace; 8010f690 &lt;schedule+2d8/4fc&gt;<BR>Trace; 80104aa4 &lt;_sys_rt_sigsuspend+170/180&gt;<BR>Trace; 801097a0 &lt;stack_done+1c/38&gt;<BR>Trace; 80162038 &lt;create_proc_entry+58/d0&gt;</DIV>
<DIV>Code;&nbsp; 8010cd44 &lt;r4k_flush_cache_sigtramp+18/30&gt;<BR>00000000 &lt;_PC&gt;:<BR>Code;&nbsp; 8010cd44 &lt;r4k_flush_cache_sigtramp+18/30&gt;<BR>&nbsp;&nbsp; 0:&nbsp;&nbsp; bc550000&nbsp; 0xbc550000<BR>Code;&nbsp; 8010cd48 &lt;r4k_flush_cache_sigtramp+1c/30&gt;<BR>&nbsp;&nbsp; 4:&nbsp;&nbsp; 00031823&nbsp; negu&nbsp;&nbsp;&nbsp; v1,v1<BR>Code;&nbsp; 8010cd4c &lt;r4k_flush_cache_sigtramp+20/30&gt;<BR>&nbsp;&nbsp; 8:&nbsp;&nbsp; 00832024&nbsp; and&nbsp;&nbsp;&nbsp;&nbsp; a0,a0,v1<BR>Code;&nbsp; 8010cd50 &lt;r4k_flush_cache_sigtramp+24/30&gt;&nbsp;&nbsp; &lt;=====<BR>&nbsp;&nbsp; c:&nbsp;&nbsp; bc900000&nbsp; 0xbc900000&nbsp;&nbsp; &lt;=====<BR>Code;&nbsp; 8010cd54 &lt;r4k_flush_cache_sigtramp+28/30&gt;<BR>&nbsp; 10:&nbsp;&nbsp; 03e00008&nbsp; jr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ra<BR>Code;&nbsp; 8010cd58 &lt;r4k_flush_cache_sigtramp+2c/30&gt;<BR>&nbsp; 14:&nbsp;&nbsp; 00000000&nbsp; nop<BR>Code;&nbsp; 8010cd5c &lt;r4k_flush_icache_all+0/3c&gt;<BR>&nbsp; 18:&nbsp;&nbsp;
 3c028035&nbsp; lui&nbsp;&nbsp;&nbsp;&nbsp; v0,0x8035<BR>Code;&nbsp; 8010cd60 &lt;r4k_flush_icache_all+4/3c&gt;<BR>&nbsp; 1c:&nbsp;&nbsp; 8c42881c&nbsp; lw&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v0,-30692(v0)<BR>Code;&nbsp; 8010cd64 &lt;r4k_flush_icache_all+8/3c&gt;<BR>&nbsp; 20:&nbsp;&nbsp; 27bdffe8&nbsp; addiu&nbsp;&nbsp; sp,sp,-24</DIV>
<DIV>&nbsp;</DIV>
<DIV>But on the times it has happened after a few hours / a day or so it has happened due to activity on the serial console when running general linux commands the oops&nbsp;traces are at the end of this email.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I am using a 2.4.24 kernel from linux-mips cvs. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Does anyone have any idea what could be causing this ? And possible ways to fix it ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Can someone explain to me why the cache flushing routines are triggering a "reserved instruction" at random like this when up to the point of failure the same code must have been executed millions of times without triggering the exception ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Any help in debugging this is greatly appreciated.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Failure in sshd :</DIV>
<DIV>&nbsp;</DIV>
<DIV>Reserved instruction in kernel code in traps.c::do_ri, line 663:<BR>&nbsp;$0 : 00000000 80000000 80001c00 80001000 80000c00 00001000 00000001 00004000<BR>&nbsp;$8 : 00001000 00000000 820700f0 00000000 2afaee50 2afaee9c fffffff8 fffffffa<BR>&nbsp;$16: 810517c8 823acf60 0041ee48 820700f0 0041ee48 00000000 802feda0 00000000<BR>&nbsp;$24: fffffffe 0041ee48&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 81dd4000 81dd5d98 00000004 8010cabc<BR>&nbsp;Hi : ffffa71d<BR>&nbsp;Lo : 00001da1<BR>&nbsp;epc&nbsp;&nbsp; : 8010d66c&nbsp;&nbsp;&nbsp; Not tainted<BR>Using defaults from ksymoops -t elf32-tradlittlemips -a mips:3000<BR>&nbsp;Status: 1000fc03<BR>&nbsp;Cause : 00800028<BR>&nbsp;Process sshd (pid: 631, stackpage=81dd4000)<BR>&nbsp;Stack:&nbsp;&nbsp;&nbsp; 0041ee48 820700f0 0041ee48 00000000 810517c8 823acf60 0041ee48<BR>&nbsp; 80125138 74737271 78777675 000000d8 0015a298 100151fc 0007831e 000000d8<BR>&nbsp; 0015a298 00000000
 00000000 000000d8 0015a298 000007de 0007831e 802feda0<BR>&nbsp; 00000000 0041ee48 823acf60 81dd5f30 00000000 802fedbc 00000001 80125460<BR>&nbsp; 801253f4 826d5cf0 82030a20 81dd5ed0 81dd5ed0 820700f0 0007831a 7fff78b0<BR>&nbsp; 00000005 ...<BR>&nbsp;Call Trace:&nbsp;&nbsp; [&lt;80125138&gt;] [&lt;80125460&gt;] [&lt;801253f4&gt;] [&lt;80133d74&gt;] [&lt;8010c1d8&gt;]<BR>&nbsp; [&lt;8023112c&gt;] [&lt;80231510&gt;] [&lt;80126d88&gt;] [&lt;80125a0c&gt;] [&lt;8010e8bc&gt;]<BR>&nbsp;Code: bc400260&nbsp; bc400280&nbsp; bc4002a0 &lt;bc4002c0&gt; bc4002e0&nbsp; bc400300&nbsp; bc400320&nbsp; bc400340&nbsp; bc400360</DIV>
<DIV><BR>&gt;&gt;$22; 802feda0 &lt;pci_socket_init+20/58&gt;<BR>&gt;&gt;$31; 8010cabc &lt;r4k_flush_icache_page+138/218&gt;</DIV>
<DIV>&gt;&gt;PC;&nbsp; 8010d66c &lt;blast_icache32+a0/f0&gt;&nbsp;&nbsp; &lt;=====</DIV>
<DIV>Trace; 80125138 &lt;do_no_page+144/3b8&gt;<BR>Trace; 80125460 &lt;handle_mm_fault+b4/278&gt;<BR>Trace; 801253f4 &lt;handle_mm_fault+48/278&gt;<BR>Trace; 80133d74 &lt;free_pages+48/50&gt;<BR>Trace; 8010c1d8 &lt;do_page_fault+160/3c8&gt;<BR>Trace; 8023112c &lt;sock_recvmsg+48/104&gt;<BR>Trace; 80231510 &lt;sock_poll+28/34&gt;<BR>Trace; 80126d88 &lt;do_brk+16c/23c&gt;<BR>Trace; 80125a0c &lt;sys_brk+c8/140&gt;<BR>Trace; 8010e8bc &lt;nopage_tlbl+f0/114&gt;</DIV>
<DIV>Code;&nbsp; 8010d660 &lt;blast_icache32+94/f0&gt;<BR>00000000 &lt;_PC&gt;:<BR>Code;&nbsp; 8010d660 &lt;blast_icache32+94/f0&gt;<BR>&nbsp;&nbsp; 0:&nbsp;&nbsp; bc400260&nbsp; 0xbc400260<BR>Code;&nbsp; 8010d664 &lt;blast_icache32+98/f0&gt;<BR>&nbsp;&nbsp; 4:&nbsp;&nbsp; bc400280&nbsp; 0xbc400280<BR>Code;&nbsp; 8010d668 &lt;blast_icache32+9c/f0&gt;<BR>&nbsp;&nbsp; 8:&nbsp;&nbsp; bc4002a0&nbsp; 0xbc4002a0<BR>Code;&nbsp; 8010d66c &lt;blast_icache32+a0/f0&gt;&nbsp;&nbsp; &lt;=====<BR>&nbsp;&nbsp; c:&nbsp;&nbsp; bc4002c0&nbsp; 0xbc4002c0&nbsp;&nbsp; &lt;=====<BR>Code;&nbsp; 8010d670 &lt;blast_icache32+a4/f0&gt;<BR>&nbsp; 10:&nbsp;&nbsp; bc4002e0&nbsp; 0xbc4002e0<BR>Code;&nbsp; 8010d674 &lt;blast_icache32+a8/f0&gt;<BR>&nbsp; 14:&nbsp;&nbsp; bc400300&nbsp; 0xbc400300<BR>Code;&nbsp; 8010d678 &lt;blast_icache32+ac/f0&gt;<BR>&nbsp; 18:&nbsp;&nbsp; bc400320&nbsp; 0xbc400320<BR>Code;&nbsp; 8010d67c &lt;blast_icache32+b0/f0&gt;<BR>&nbsp; 1c:&nbsp;&nbsp; bc400340&nbsp; 0xbc400340<BR>Code;&nbsp;
 8010d680 &lt;blast_icache32+b4/f0&gt;<BR>&nbsp; 20:&nbsp;&nbsp; bc400360&nbsp; 0xbc400360<BR></DIV>
<DIV>
<DIV>Failure in&nbsp;ls :</DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV>Reading Oops report from the terminal<BR>Reserved instruction in kernel code in traps.c::do_ri, line 663:<BR>$0 : 00000000 80000000 80002000 80001000 80000000 00002000 000079d8 00004000<BR>$8 : 00000001 00000000 8349a0e8 00000b3b 7f1c0300 00000001 65726168 00000115<BR>$16: 810e7d2c 834cb740 0041da54 8349a0e8 0041da54 00000000 83a96460 00000000<BR>$24: 00000000 2abede20&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8010f58b 83481d98 00000000 8010cabc<BR>Hi : ffff031c<BR>Lo : 0000544c<BR>epc&nbsp;&nbsp; : 8010d634&nbsp;&nbsp;&nbsp; Not tainted<BR>Using defaults from ksymoops -t elf32-tradlittlemips -a mips:3000<BR>Status: 1000fc03<BR>Cause : 00800028<BR>Process ls (pid: 1335, stackpage=83480000)<BR>Stack:&nbsp;&nbsp;&nbsp; 0041da54 8349a0e8 0041da54 00000000 810e7d2c 834cb740 0041da54<BR>&nbsp;80125138 4c4b4a49 504f4e4d 000000d8 0010b2d8 62615a59 66656463 000000d8<BR>&nbsp;0010b2d8 00000000 00000000 000000d8 0010b2d8
 48474645 4c4b4a49 83a96460<BR>&nbsp;00000000 0041da54 834cb740 83481f30 00000000 83a9647c 00000000 80125460<BR>&nbsp;801253f4 44434241 48474645 7fff7ce0 00000000 8349a0e8 83481eb8 80312cd0<BR>&nbsp;2ad2d520 ...<BR>Call Trace:&nbsp;&nbsp; [&lt;80125138&gt;] [&lt;80125460&gt;] [&lt;801253f4&gt;] [&lt;801198e8&gt;] [&lt;8010c1d8&gt;]<BR>&nbsp;[&lt;801bf480&gt;] [&lt;80125b4c&gt;] [&lt;80126e08&gt;] [&lt;801ae43c&gt;] [&lt;8014de3c&gt;] [&lt;80125a0c&gt;]<BR>&nbsp;[&lt;8010e8bc&gt;]<BR>Code: bc4000a0&nbsp; bc4000c0&nbsp; bc4000e0 &lt;bc400100&gt; bc400120&nbsp; bc400140&nbsp; bc400160&nbsp; bc400180&nbsp; bc4001a0</DIV>
<DIV><BR>&gt;&gt;$28; 8010f58b &lt;schedule+1d3/4fc&gt;<BR>&gt;&gt;$31; 8010cabc &lt;r4k_flush_icache_page+138/218&gt;</DIV>
<DIV>&gt;&gt;PC;&nbsp; 8010d634 &lt;blast_icache32+68/f0&gt;&nbsp;&nbsp; &lt;=====</DIV>
<DIV>Trace; 80125138 &lt;do_no_page+144/3b8&gt;<BR>Trace; 80125460 &lt;handle_mm_fault+b4/278&gt;<BR>Trace; 801253f4 &lt;handle_mm_fault+48/278&gt;<BR>Trace; 801198e8 &lt;parse_table+16c/174&gt;<BR>Trace; 8010c1d8 &lt;do_page_fault+160/3c8&gt;<BR>Trace; 801bf480 &lt;ltxser_interrupt+204/32c&gt;<BR>Trace; 80125b4c &lt;__vma_link+44/dc&gt;<BR>Trace; 80126e08 &lt;do_brk+1ec/23c&gt;<BR>Trace; 801ae43c &lt;tty_ioctl+15c/51c&gt;<BR>Trace; 8014de3c &lt;sys_ioctl+a0/2e4&gt;<BR>Trace; 80125a0c &lt;sys_brk+c8/140&gt;<BR>Trace; 8010e8bc &lt;nopage_tlbl+f0/114&gt;</DIV>
<DIV>Code;&nbsp; 8010d628 &lt;blast_icache32+5c/f0&gt;<BR>00000000 &lt;_PC&gt;:<BR>Code;&nbsp; 8010d628 &lt;blast_icache32+5c/f0&gt;<BR>&nbsp;&nbsp; 0:&nbsp;&nbsp; bc4000a0&nbsp; 0xbc4000a0<BR>Code;&nbsp; 8010d62c &lt;blast_icache32+60/f0&gt;<BR>&nbsp;&nbsp; 4:&nbsp;&nbsp; bc4000c0&nbsp; 0xbc4000c0<BR>Code;&nbsp; 8010d630 &lt;blast_icache32+64/f0&gt;<BR>&nbsp;&nbsp; 8:&nbsp;&nbsp; bc4000e0&nbsp; 0xbc4000e0<BR>Code;&nbsp; 8010d634 &lt;blast_icache32+68/f0&gt;&nbsp;&nbsp; &lt;=====<BR>&nbsp;&nbsp; c:&nbsp;&nbsp; bc400100&nbsp; 0xbc400100&nbsp;&nbsp; &lt;=====<BR>Code;&nbsp; 8010d638 &lt;blast_icache32+6c/f0&gt;<BR>&nbsp; 10:&nbsp;&nbsp; bc400120&nbsp; 0xbc400120<BR>Code;&nbsp; 8010d63c &lt;blast_icache32+70/f0&gt;<BR>&nbsp; 14:&nbsp;&nbsp; bc400140&nbsp; 0xbc400140<BR>Code;&nbsp; 8010d640 &lt;blast_icache32+74/f0&gt;<BR>&nbsp; 18:&nbsp;&nbsp; bc400160&nbsp; 0xbc400160<BR>Code;&nbsp; 8010d644 &lt;blast_icache32+78/f0&gt;<BR>&nbsp; 1c:&nbsp;&nbsp; bc400180&nbsp; 0xbc400180<BR>Code;&nbsp;
 8010d648 &lt;blast_icache32+7c/f0&gt;<BR>&nbsp; 20:&nbsp;&nbsp; bc4001a0&nbsp; 0xbc4001a0<BR></DIV>
<DIV>Failure in stat:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Reserved instruction in kernel code in traps.c::do_ri, line 663:<BR>$0 : 00000000 80000000 80002400 80001000 80000400 00002000 000079d8 00004000<BR>$8 : 00000001 00000000 82ea8828 6ffffeff 6fffff72 00000063 40f2d4f7 00000000<BR>$16: 810eeb84 834cb920 2ab051ac 82ea8828 2ab051ac 00000000 83a96460 00000000<BR>$24: 00000000 2aabcd10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8010f58b 82eb5d98 7fff7678 8010cabc<BR>Hi : fffefb96<BR>Lo : 000056ce<BR>epc&nbsp;&nbsp; : 8010d650&nbsp;&nbsp;&nbsp; Not tainted<BR>Using defaults from ksymoops -t elf32-tradlittlemips -a mips:3000<BR>Status: 1000fc03<BR>Cause : 00800028<BR>Process stat (pid: 1376, stackpage=82eb4000)<BR>Stack:&nbsp;&nbsp;&nbsp; 2ab051ac 82ea8828 2ab051ac 00000000 810eeb84 834cb920 2ab051ac<BR>&nbsp;80125138 00000000 856ff768 000000d8 0015b458 000005dc 000baa5c 000000d8<BR>&nbsp;0015b458 00000000 00000000 000000d8 0015b458 000000d8 000baa58
 83a96460<BR>&nbsp;00000000 2ab051ac 834cb920 82eb5f30 00000000 83a9647c 00000001 80125460<BR>&nbsp;801253f4 834cb938 834cb920 834cbbc0 834cbbc0 82ea8828 0015bb1a 801267c8<BR>&nbsp;8010e8bc ...<BR>Call Trace:&nbsp;&nbsp; [&lt;80125138&gt;] [&lt;80125460&gt;] [&lt;801253f4&gt;] [&lt;801267c8&gt;] [&lt;8010e8bc&gt;]<BR>&nbsp;[&lt;8010c1d8&gt;] [&lt;80126068&gt;] [&lt;8012d008&gt;] [&lt;801a074c&gt;] [&lt;80108034&gt;] [&lt;8010e8bc&gt;]<BR>Code: bc400180&nbsp; bc4001a0&nbsp; bc4001c0 &lt;bc4001e0&gt; bc400200&nbsp; bc400220&nbsp; bc400240&nbsp; bc400260&nbsp; bc400280</DIV>
<DIV><BR>&gt;&gt;$28; 8010f58b &lt;schedule+1d3/4fc&gt;<BR>&gt;&gt;$31; 8010cabc &lt;r4k_flush_icache_page+138/218&gt;</DIV>
<DIV>&gt;&gt;PC;&nbsp; 8010d650 &lt;blast_icache32+84/f0&gt;&nbsp;&nbsp; &lt;=====</DIV>
<DIV>Trace; 80125138 &lt;do_no_page+144/3b8&gt;<BR>Trace; 80125460 &lt;handle_mm_fault+b4/278&gt;<BR>Trace; 801253f4 &lt;handle_mm_fault+48/278&gt;<BR>Trace; 801267c8 &lt;unmap_fixup+1e4/1fc&gt;<BR>Trace; 8010e8bc &lt;nopage_tlbl+f0/114&gt;<BR>Trace; 8010c1d8 &lt;do_page_fault+160/3c8&gt;<BR>Trace; 80126068 &lt;do_mmap_pgoff+350/5b0&gt;<BR>Trace; 8012d008 &lt;mprotect_fixup+1f0/534&gt;<BR>Trace; 801a074c &lt;fpu_emulator_cop1Handler+198/1bc&gt;<BR>Trace; 80108034 &lt;do_cpu+2e0/334&gt;<BR>Trace; 8010e8bc &lt;nopage_tlbl+f0/114&gt;</DIV>
<DIV>Code;&nbsp; 8010d644 &lt;blast_icache32+78/f0&gt;<BR>00000000 &lt;_PC&gt;:<BR>Code;&nbsp; 8010d644 &lt;blast_icache32+78/f0&gt;<BR>&nbsp;&nbsp; 0:&nbsp;&nbsp; bc400180&nbsp; 0xbc400180<BR>Code;&nbsp; 8010d648 &lt;blast_icache32+7c/f0&gt;<BR>&nbsp;&nbsp; 4:&nbsp;&nbsp; bc4001a0&nbsp; 0xbc4001a0<BR>Code;&nbsp; 8010d64c &lt;blast_icache32+80/f0&gt;<BR>&nbsp;&nbsp; 8:&nbsp;&nbsp; bc4001c0&nbsp; 0xbc4001c0<BR>Code;&nbsp; 8010d650 &lt;blast_icache32+84/f0&gt;&nbsp;&nbsp; &lt;=====<BR>&nbsp;&nbsp; c:&nbsp;&nbsp; bc4001e0&nbsp; 0xbc4001e0&nbsp;&nbsp; &lt;=====<BR>Code;&nbsp; 8010d654 &lt;blast_icache32+88/f0&gt;<BR>&nbsp; 10:&nbsp;&nbsp; bc400200&nbsp; 0xbc400200<BR>Code;&nbsp; 8010d658 &lt;blast_icache32+8c/f0&gt;<BR>&nbsp; 14:&nbsp;&nbsp; bc400220&nbsp; 0xbc400220<BR>Code;&nbsp; 8010d65c &lt;blast_icache32+90/f0&gt;<BR>&nbsp; 18:&nbsp;&nbsp; bc400240&nbsp; 0xbc400240<BR>Code;&nbsp; 8010d660 &lt;blast_icache32+94/f0&gt;<BR>&nbsp; 1c:&nbsp;&nbsp; bc400260&nbsp; 0xbc400260<BR>Code;&nbsp;
 8010d664 &lt;blast_icache32+98/f0&gt;<BR>&nbsp; 20:&nbsp;&nbsp; bc400280&nbsp; 0xbc400280<BR></DIV>
<DIV>&nbsp; </DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/aac/*http://promotions.yahoo.com/new_mail/static/ease.html">Yahoo! Mail Address AutoComplete</a> - You start. We finish.
--0-1918942025-1091549989=:87300--

From wsonguci@yahoo.com Tue Aug  3 20:22:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Aug 2004 20:22:56 +0100 (BST)
Received: from web40002.mail.yahoo.com ([IPv6:::ffff:66.218.78.20]:44972 "HELO
	web40002.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224907AbUHCTWv>; Tue, 3 Aug 2004 20:22:51 +0100
Message-ID: <20040803192244.5889.qmail@web40002.mail.yahoo.com>
Received: from [63.87.1.243] by web40002.mail.yahoo.com via HTTP; Tue, 03 Aug 2004 12:22:44 PDT
Date: Tue, 3 Aug 2004 12:22:44 -0700 (PDT)
From: Song Wang <wsonguci@yahoo.com>
Subject: 2.6 preemptive kernel on mips
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <wsonguci@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: 5587
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wsonguci@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,

Has anyone tried to enable kernel preemption on
Linux mips 2.6 kernel (mips32) and test it? If
so, which version does it work?

I tried on 2.6.3 and it didn't work.

Thanks.

-Song


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

From jsun@mvista.com Tue Aug  3 20:40:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Aug 2004 20:40:54 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:37108 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224907AbUHCTku>;
	Tue, 3 Aug 2004 20:40:50 +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 i73Jemar002112;
	Tue, 3 Aug 2004 12:40:48 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i73Jemum002111;
	Tue, 3 Aug 2004 12:40:48 -0700
Date: Tue, 3 Aug 2004 12:40:48 -0700
From: Jun Sun <jsun@mvista.com>
To: Song Wang <wsonguci@yahoo.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: 2.6 preemptive kernel on mips
Message-ID: <20040803124048.C1926@mvista.com>
References: <20040803192244.5889.qmail@web40002.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040803192244.5889.qmail@web40002.mail.yahoo.com>; from wsonguci@yahoo.com on Tue, Aug 03, 2004 at 12:22:44PM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5588
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, Aug 03, 2004 at 12:22:44PM -0700, Song Wang wrote:
> Hi,
> 
> Has anyone tried to enable kernel preemption on
> Linux mips 2.6 kernel (mips32) and test it? If
> so, which version does it work?
> 
> I tried on 2.6.3 and it didn't work.
> 

Try the latest kernel.  I checked preemption around 2.6.5 time
and I believe all the obvious problems are fixed then.

There are still some issues with both SMP and PREEMPT, but most
people won't see them in normal cases.

Jun

From ralf@linux-mips.org Wed Aug  4 01:50:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Aug 2004 01:50:33 +0100 (BST)
Received: from p508B65A8.dip.t-dialin.net ([IPv6:::ffff:80.139.101.168]:6010
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224907AbUHDAu3>; Wed, 4 Aug 2004 01:50:29 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i740oSHV010510;
	Wed, 4 Aug 2004 02:50:28 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i740oNh7010509;
	Wed, 4 Aug 2004 02:50:23 +0200
Date: Wed, 4 Aug 2004 02:50:23 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Alec Voropay <a.voropay@vmb-service.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: SGI ARC .vs. ACE ARC BIOS
Message-ID: <20040804005023.GA9046@linux-mips.org>
References: <01ed01c47963$bc74a220$1701a8c0@portege>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01ed01c47963$bc74a220$1701a8c0@portege>
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: 5589
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Aug 03, 2004 at 06:11:12PM +0400, Alec Voropay wrote:

>  Can anyone explain a difference between SGI ARC BOOT-PROM
> (sometimes called ARCS) and an old ACE ARC BIOS (Jazz/Magnum) ?
> Is this equal (in functionality, not command line) ?
> 
> P.S.
> http://www.netbsd.org/Documentation/Hardware/Machines/ARC/

ARC is a dead-born standard that standardizes both hardware and firmware.
All implementations violate it more or less.  The whole thing was
originally part of the ACE initiative, which also has developped the
Jazz design to which the Magnum, Acer and others are more or less related.
As I recall the Manum was some sort of reference implementation.  The
hardware specs were rather fuzzy and more or less obsolete from a UNIX
workstation perspective already ten years ago.  Not considering endianess -
SGI ARC(S) is big endian, other firmware is little endian - and for the
little ARC functionality that Linux is using the two can be considered
equivalent.

  Ralf

From macro@linux-mips.org Wed Aug  4 20:57:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Aug 2004 20:57:12 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:10770 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224924AbUHDT5H>; Wed, 4 Aug 2004 20:57:07 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 7303DE1CC2; Wed,  4 Aug 2004 21:56:59 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 06975-09; Wed,  4 Aug 2004 21:56:59 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 3B6BCE1C64; Wed,  4 Aug 2004 21:56:59 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i74JvFfF025382;
	Wed, 4 Aug 2004 21:57:16 +0200
Date: Wed, 4 Aug 2004 21:57:04 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Nigel Stephens <nigel@mips.com>
Cc: Richard Sandiford <rsandifo@redhat.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
In-Reply-To: <410F60DF.9020400@mips.com>
Message-ID: <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl>
 <87hds49bmo.fsf@redhat.com> <Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl>
 <20040719213801.GD14931@redhat.com> <Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl>
 <20040723202703.GB30931@redhat.com> <20040723211232.GB5138@linux-mips.org>
 <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl> <410E9E25.7080104@mips.com>
 <87acxcbxfl.fsf@redhat.com> <410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com>
 <410F60DF.9020400@mips.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 5590
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, 3 Aug 2004, Nigel Stephens wrote:

> Note that there is one slightly controversial aspect of these sequences, 
> which is that they don't truncate the shift count, so a shift outside of 
> the range 0 to 63 will generate an "unusual" result.  This didn't cause 
> any regression failures, and I believe that this is strictly speaking 
> acceptable for C, since a shift is undefined outside of this range - but 
> it could cause some "buggy" code to break. It wouldn't be hard to add an 
> extra mask with 0x3f if people were nervous about this - it's just that 
> I didn't have enough spare temp registers within the constraints of the 
> existing DImode patterns.

 Well, masking is trivial with no additional temporary :-) and for ashrdi3
we can "cheat" and use $at to require only a single additional instruction
compared to the others.

 Here are my proposals I've referred to previously.  Instruction counts
are 9, 9 and 10, respectively, as I've missed an additional instruction
required to handle shifts by 0 (or actually any multiples of 64).  The
semantics they implement corresponds to one of the dsllv, dsrlv and dsrav,
respectively.  I've expressed them in terms of functions rather than RTL
patterns, but a conversion is trivial.  This form was simply easier to
validate for me and they can be used as libgcc function replacements for
Linux for MIPS IV and higher ISAs.

long long __ashldi3(long long v, int c)
{
	long long r;
	long r0;

	asm(
		"sllv	%L0, %L2, %3\n\t"
		"sllv	%M0, %M2, %3\n\t"
		"not	%1, %3\n\t"
		"srlv	%1, %L2, %1\n\t"
		"srl	%1, %1, 1\n\t"
		"or	%M0, %M0, %1\n\t"
		"andi	%1, %3, 0x20\n\t"
		"movn	%M0, %L0, %1\n\t"
		"movn	%L0, $0, %1"
		: "=&r" (r), "=&r" (r0)
		: "r" (v), "r" (c));

	return r;
}

unsigned long long __lshrdi3(unsigned long long v, int c)
{
	unsigned long long r;
	long r0;

	asm(
		"srlv	%M0, %M2, %3\n\t"
		"srlv	%L0, %L2, %3\n\t"
		"not	%1, %3\n\t"
		"sllv	%1, %M2, %1\n\t"
		"sll	%1, %1, 1\n\t"
		"or	%L0, %L0, %1\n\t"
		"andi	%1, %3, 0x20\n\t"
		"movn	%L0, %M0, %1\n\t"
		"movn	%M0, $0, %1"
		: "=&r" (r), "=&r" (r0)
		: "r" (v), "r" (c));

	return r;
}

long long __ashrdi3(long long v, int c)
{
	long long r;
	long r0;

	asm(
		"not	%1, %3\n\t"
		"srav	%M0, %M2, %3\n\t"
		"srlv	%L0, %L2, %3\n\t"
		"sllv	%1, %M2, %1\n\t"
		"sll	%1, %1, 1\n\t"
		"or	%L0, %L0, %1\n\t"
		"andi	%1, %3, 0x20\n\t"
		".set	push\n\t"
		".set	noat\n\t"
		"sra	$1, %M2, 31\n\t"
		"movn	%L0, %M0, %1\n\t"
		"movn	%M0, $1, %1\n\t"
		".set	pop"
		: "=&r" (r), "=&r" (r0)
		: "r" (v), "r" (c));

	return r;
}

 I don't know if the middle-end is capable to express these operations,
but they are pure ALU, so I'd expect it to.

  Maciej

From nigel@mips.com Wed Aug  4 21:37:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Aug 2004 21:37:34 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:12551 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224986AbUHDUhV>;
	Wed, 4 Aug 2004 21:37:21 +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 1BsSh9-0008J3-00; Wed, 04 Aug 2004 21:49:07 +0100
Received: from highbury.mips.com ([192.168.192.236] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1BsSVU-00054D-00; Wed, 04 Aug 2004 21:37:04 +0100
Message-ID: <411148F0.2040605@mips.com>
Date: Wed, 04 Aug 2004 21:37:04 +0100
From: Nigel Stephens <nigel@mips.com>
Organization: MIPS Technologies
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.4) Gecko/20030624
X-Accept-Language: en-gb, en-us, en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@linux-mips.org>
CC: Richard Sandiford <rsandifo@redhat.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl> <87hds49bmo.fsf@redhat.com> <Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl> <20040719213801.GD14931@redhat.com> <Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl> <20040723202703.GB30931@redhat.com> <20040723211232.GB5138@linux-mips.org> <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl> <410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com> <410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com> <410F60DF.9020400@mips.com> <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.226, required 4, AWL,
	BAYES_00, USER_AGENT_MOZILLA_UA)
Return-Path: <nigel@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: 5591
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nigel@mips.com
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:

> Here are my proposals I've referred to previously.  Instruction counts
>are 9, 9 and 10, respectively, as I've missed an additional instruction
>required to handle shifts by 0 (or actually any multiples of 64). 
>

IMHO handling a shift by zero correctly is important.

>		"not	%1, %3\n\t"
>		"srlv	%1, %L2, %1\n\t"
>		"srl	%1, %1, 1\n\t"
>

Why not the shorter:

>		"neg	%1, %3\n\t"
>		"srlv	%1, %L2, %1\n\t"
>
>  
>

And then in __ashrdi3:

		"andi	%1, %3, 0x20\n\t"
		".set	push\n\t"
		".set	noat\n\t"
		"sra	$1, %M2, 31\n\t"
		"movn	%L0, %M0, %1\n\t"
		"movn	%M0, $1, %1\n\t"
		".set	pop"

Cute, but I think that should be

	"sra	$1, %M0, 31\n\t"

(i.e %M0 not %M2)

Nigel



From macro@linux-mips.org Wed Aug  4 21:54:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Aug 2004 21:54:45 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:50192 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224986AbUHDUyk>; Wed, 4 Aug 2004 21:54:40 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id A2888E1CC5; Wed,  4 Aug 2004 22:54:33 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 21857-07; Wed,  4 Aug 2004 22:54:33 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 67ECCE1CC2; Wed,  4 Aug 2004 22:54:33 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i74KspuH028027;
	Wed, 4 Aug 2004 22:54:51 +0200
Date: Wed, 4 Aug 2004 22:54:39 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Nigel Stephens <nigel@mips.com>
Cc: Richard Sandiford <rsandifo@redhat.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
In-Reply-To: <411148F0.2040605@mips.com>
Message-ID: <Pine.LNX.4.58L.0408042239260.11595@blysk.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl>
 <87hds49bmo.fsf@redhat.com> <Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl>
 <20040719213801.GD14931@redhat.com> <Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl>
 <20040723202703.GB30931@redhat.com> <20040723211232.GB5138@linux-mips.org>
 <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl> <410E9E25.7080104@mips.com>
 <87acxcbxfl.fsf@redhat.com> <410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com>
 <410F60DF.9020400@mips.com> <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
 <411148F0.2040605@mips.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 5592
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, 4 Aug 2004, Nigel Stephens wrote:

> > Here are my proposals I've referred to previously.  Instruction counts
> >are 9, 9 and 10, respectively, as I've missed an additional instruction
> >required to handle shifts by 0 (or actually any multiples of 64). 
> 
> IMHO handling a shift by zero correctly is important.

 Agreed, hence an additional instruction needed.

> >		"not	%1, %3\n\t"
> >		"srlv	%1, %L2, %1\n\t"
> >		"srl	%1, %1, 1\n\t"
> >
> 
> Why not the shorter:
> 
> >		"neg	%1, %3\n\t"
> >		"srlv	%1, %L2, %1\n\t"

 Notice the difference -- this shorter code doesn't handle shifts by zero
correctly. ;-)

> And then in __ashrdi3:
> 
> 		"andi	%1, %3, 0x20\n\t"
> 		".set	push\n\t"
> 		".set	noat\n\t"
> 		"sra	$1, %M2, 31\n\t"
> 		"movn	%L0, %M0, %1\n\t"
> 		"movn	%M0, $1, %1\n\t"
> 		".set	pop"
> 
> Cute, but I think that should be
> 
> 	"sra	$1, %M0, 31\n\t"
> 
> (i.e %M0 not %M2)

 Well, I've tested it for all shift counts and it works properly as is --
we care of the value of bit #31 to be shifted only and at this stage it's
the same in both registers.  So it's just a matter of style.

  Maciej

From bjorn.helgaas@hp.com Wed Aug  4 22:38:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Aug 2004 22:38:36 +0100 (BST)
Received: from atlrel9.hp.com ([IPv6:::ffff:156.153.255.214]:62879 "EHLO
	atlrel9.hp.com") by linux-mips.org with ESMTP id <S8225201AbUHDVic>;
	Wed, 4 Aug 2004 22:38:32 +0100
Received: from smtp1.fc.hp.com (smtp.fc.hp.com [15.11.136.119])
	by atlrel9.hp.com (Postfix) with ESMTP
	id 7E7D81A2B7; Wed,  4 Aug 2004 17:38:30 -0400 (EDT)
Received: from ldl.fc.hp.com (ldl.fc.hp.com [15.11.146.30])
	by smtp1.fc.hp.com (Postfix) with ESMTP
	id AE0B438592; Wed,  4 Aug 2004 15:38:22 -0600 (MDT)
Received: from localhost (localhost [127.0.0.1])
	by ldl.fc.hp.com (Postfix) with ESMTP id 85E3A1340F2;
	Wed,  4 Aug 2004 15:38:22 -0600 (MDT)
Received: from ldl.fc.hp.com ([127.0.0.1])
	by localhost (ldl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 04129-01; Wed, 4 Aug 2004 15:38:21 -0600 (MDT)
Received: from eeyore.helgaas (lart.fc.hp.com [15.11.146.31])
	by ldl.fc.hp.com (Postfix) with ESMTP id 7719A1340D4;
	Wed,  4 Aug 2004 15:38:21 -0600 (MDT)
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Andrew Morton <akpm@osdl.org>
Subject: [PATCH] ioc3-eth.c: add missing pci_enable_device()
Date: Wed, 4 Aug 2004 15:38:21 -0600
User-Agent: KMail/1.6.2
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200408041538.21128.bjorn.helgaas@hp.com>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ldl.fc.hp.com
Return-Path: <bjorn.helgaas@hp.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5593
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bjorn.helgaas@hp.com
Precedence: bulk
X-list: linux-mips

I don't have this hardware, so this has not been tested.


Add pci_enable_device()/pci_disable_device().  In the past, drivers
often worked without this, but it is now required in order to route
PCI interrupts correctly.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

===== drivers/net/ioc3-eth.c 1.26 vs edited =====
--- 1.26/drivers/net/ioc3-eth.c	2004-06-04 09:49:59 -06:00
+++ edited/drivers/net/ioc3-eth.c	2004-08-04 13:24:07 -06:00
@@ -1172,9 +1172,14 @@
 	u32 vendor, model, rev;
 	int err;
 
+	if (pci_enable_device(pdev))
+		return -ENODEV;
+
 	dev = alloc_etherdev(sizeof(struct ioc3_private));
-	if (!dev)
-		return -ENOMEM;
+	if (!dev) {
+		err = -ENOMEM;
+		goto out_disable;
+	}
 
 	err = pci_request_regions(pdev, "ioc3");
 	if (err)
@@ -1269,6 +1274,8 @@
 	pci_release_regions(pdev);
 out_free:
 	free_netdev(dev);
+out_disable:
+	pci_disable_device(pdev);
 	return err;
 }
 
@@ -1282,6 +1289,7 @@
 	iounmap(ioc3);
 	pci_release_regions(pdev);
 	free_netdev(dev);
+	pci_disable_device(pdev);
 }
 
 static struct pci_device_id ioc3_pci_tbl[] = {

From trini@kernel.crashing.org Wed Aug  4 22:51:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Aug 2004 22:51:52 +0100 (BST)
Received: from fed1rmmtao05.cox.net ([IPv6:::ffff:68.230.241.34]:42210 "EHLO
	fed1rmmtao05.cox.net") by linux-mips.org with ESMTP
	id <S8225214AbUHDVvs>; Wed, 4 Aug 2004 22:51:48 +0100
Received: from opus ([68.107.143.141]) by fed1rmmtao05.cox.net
          (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709)
          with ESMTP
          id <20040804215139.NGXX14278.fed1rmmtao05.cox.net@opus>;
          Wed, 4 Aug 2004 17:51:39 -0400
Date: Wed, 4 Aug 2004 14:51:40 -0700
From: Tom Rini <trini@kernel.crashing.org>
To: Jun Sun <jsun@mvista.com>
Cc: Song Wang <wsonguci@yahoo.com>, linux-mips@linux-mips.org
Subject: Re: 2.6 preemptive kernel on mips
Message-ID: <20040804215140.GP9235@smtp.west.cox.net>
References: <20040803192244.5889.qmail@web40002.mail.yahoo.com> <20040803124048.C1926@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040803124048.C1926@mvista.com>
User-Agent: Mutt/1.5.6+20040523i
Return-Path: <trini@kernel.crashing.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: 5594
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: trini@kernel.crashing.org
Precedence: bulk
X-list: linux-mips

On Tue, Aug 03, 2004 at 12:40:48PM -0700, Jun Sun wrote:

> On Tue, Aug 03, 2004 at 12:22:44PM -0700, Song Wang wrote:
> > Hi,
> > 
> > Has anyone tried to enable kernel preemption on
> > Linux mips 2.6 kernel (mips32) and test it? If
> > so, which version does it work?
> > 
> > I tried on 2.6.3 and it didn't work.
> > 
> 
> Try the latest kernel.  I checked preemption around 2.6.5 time
> and I believe all the obvious problems are fixed then.
> 
> There are still some issues with both SMP and PREEMPT, but most
> people won't see them in normal cases.

MIPS or generic?  It's claimed, at least, that SMP&&PREEMPT have no
fatal, generic, issues now (I forget if that was the case around 2.6.5).

-- 
Tom Rini
http://gate.crashing.org/~trini/

From jsun@mvista.com Wed Aug  4 23:25:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Aug 2004 23:25:22 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:20218 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225214AbUHDWZS>;
	Wed, 4 Aug 2004 23:25: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 i74MP7ar014157;
	Wed, 4 Aug 2004 15:25:07 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i74MP6fD014156;
	Wed, 4 Aug 2004 15:25:06 -0700
Date: Wed, 4 Aug 2004 15:25:06 -0700
From: Jun Sun <jsun@mvista.com>
To: Tom Rini <trini@kernel.crashing.org>
Cc: Song Wang <wsonguci@yahoo.com>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: 2.6 preemptive kernel on mips
Message-ID: <20040804152506.C6269@mvista.com>
References: <20040803192244.5889.qmail@web40002.mail.yahoo.com> <20040803124048.C1926@mvista.com> <20040804215140.GP9235@smtp.west.cox.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040804215140.GP9235@smtp.west.cox.net>; from trini@kernel.crashing.org on Wed, Aug 04, 2004 at 02:51:40PM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5595
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, Aug 04, 2004 at 02:51:40PM -0700, Tom Rini wrote:
> On Tue, Aug 03, 2004 at 12:40:48PM -0700, Jun Sun wrote:
> 
> > On Tue, Aug 03, 2004 at 12:22:44PM -0700, Song Wang wrote:
> > > Hi,
> > > 
> > > Has anyone tried to enable kernel preemption on
> > > Linux mips 2.6 kernel (mips32) and test it? If
> > > so, which version does it work?
> > > 
> > > I tried on 2.6.3 and it didn't work.
> > > 
> > 
> > Try the latest kernel.  I checked preemption around 2.6.5 time
> > and I believe all the obvious problems are fixed then.
> > 
> > There are still some issues with both SMP and PREEMPT, but most
> > people won't see them in normal cases.
> 
> MIPS or generic?  It's claimed, at least, that SMP&&PREEMPT have no
> fatal, generic, issues now (I forget if that was the case around 2.6.5).
> 

It is MIPS specific problems I was referring to (such as unsafe 
smp_processor_id() reference etc).

If you think about it the real problem is that kernel has non-migratable
regions, a section where process should not migrate from one CPU to
another.  Before preemtible kernel is introduced such non-migratable
regions are not a problem because they can't migrate during those
regions.

So a potentially better solution is to introduce non-migratable
regions during which scheduler promises not to migrate the processes.
Under such promises a process can actually be preempted while
it is in such a region.

Jun

From jsun@mvista.com Wed Aug  4 23:29:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Aug 2004 23:29:41 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:28399 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225214AbUHDW3h>;
	Wed, 4 Aug 2004 23:29:37 +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 i74MTaar014169;
	Wed, 4 Aug 2004 15:29:36 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i74MTaTH014168;
	Wed, 4 Aug 2004 15:29:36 -0700
Date: Wed, 4 Aug 2004 15:29:36 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: anybody tried NPTL?
Message-ID: <20040804152936.D6269@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5596
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


I am looking into porting NPTL to MIPS.  Just curious if
anybody has tried this before.

I notice there was a discussion about the ABI extension
for TLS (thread local storage) support.  Before that support
becomes a reality it seems one can still use NPTL with 
the help of additional system calls.

A rough search of latest glibc source shows there is
zero MIPS code for nptl.  A couple of other arches
are missing as well (such as ARM)

Jun

From nigel@mips.com Thu Aug  5 00:39:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 00:39:21 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:15885 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225214AbUHDXjQ>;
	Thu, 5 Aug 2004 00:39:16 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1BsVXB-0004A9-00; Thu, 05 Aug 2004 00:51:01 +0100
Received: from kingsx.mips.com ([192.168.192.254] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1BsVLT-0007OW-00; Thu, 05 Aug 2004 00:38:55 +0100
Message-ID: <4111739F.8010701@mips.com>
Date: Thu, 05 Aug 2004 00:39:11 +0100
From: Nigel Stephens <nigel@mips.com>
Organization: MIPS Technologies
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@linux-mips.org>
CC: Richard Sandiford <rsandifo@redhat.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl> <87hds49bmo.fsf@redhat.com> <Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl> <20040719213801.GD14931@redhat.com> <Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl> <20040723202703.GB30931@redhat.com> <20040723211232.GB5138@linux-mips.org> <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl> <410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com> <410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com> <410F60DF.9020400@mips.com> <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl> <411148F0.2040605@mips.com> <Pine.LNX.4.58L.0408042239260.11595@blysk.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.58L.0408042239260.11595@blysk.ds.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.712, required 4, AWL,
	BAYES_00)
Return-Path: <nigel@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: 5597
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nigel@mips.com
Precedence: bulk
X-list: linux-mips



Maciej W. Rozycki wrote:

>On Wed, 4 Aug 2004, Nigel Stephens wrote:
>
>  
>
>>>Here are my proposals I've referred to previously.  Instruction counts
>>>are 9, 9 and 10, respectively, as I've missed an additional instruction
>>>required to handle shifts by 0 (or actually any multiples of 64). 
>>>      
>>>
>>IMHO handling a shift by zero correctly is important.
>>    
>>
>
> Agreed, hence an additional instruction needed.
>
>  
>
>>>		"not	%1, %3\n\t"
>>>		"srlv	%1, %L2, %1\n\t"
>>>		"srl	%1, %1, 1\n\t"
>>>
>>>      
>>>
>>Why not the shorter:
>>
>>    
>>
>>>		"neg	%1, %3\n\t"
>>>		"srlv	%1, %L2, %1\n\t"
>>>      
>>>
>
> Notice the difference -- this shorter code doesn't handle shifts by zero
>correctly. ;-)
>  
>

Ah yes, I see. I did it with a conditional move to fix up after the 
shift, but same result.

>>And then in __ashrdi3:
>>
>>		"andi	%1, %3, 0x20\n\t"
>>		".set	push\n\t"
>>		".set	noat\n\t"
>>		"sra	$1, %M2, 31\n\t"
>>		"movn	%L0, %M0, %1\n\t"
>>		"movn	%M0, $1, %1\n\t"
>>		".set	pop"
>>
>>Cute, but I think that should be
>>
>>	"sra	$1, %M0, 31\n\t"
>>
>>(i.e %M0 not %M2)
>>    
>>
>
> Well, I've tested it for all shift counts and it works properly as is --
>we care of the value of bit #31 to be shifted only and at this stage it's
>the same in both registers.  So it's just a matter of style.
>
>  
>

OK, I see

Nigel

From kumba@gentoo.org Thu Aug  5 02:05:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 02:05:14 +0100 (BST)
Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:58558 "EHLO
	sccrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225214AbUHEBFK>; Thu, 5 Aug 2004 02:05:10 +0100
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (sccrmhc11) with ESMTP
          id <20040805010503011000d9a5e>
          (Authid: kumba12345);
          Thu, 5 Aug 2004 01:05:03 +0000
Message-ID: <411188A8.9040607@gentoo.org>
Date: Wed, 04 Aug 2004 21:08:56 -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: anybody tried NPTL?
References: <20040804152936.D6269@mvista.com>
In-Reply-To: <20040804152936.D6269@mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5598
X-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

Jun Sun wrote:

> I am looking into porting NPTL to MIPS.  Just curious if
> anybody has tried this before.
> 
> I notice there was a discussion about the ABI extension
> for TLS (thread local storage) support.  Before that support
> becomes a reality it seems one can still use NPTL with 
> the help of additional system calls.
> 
> A rough search of latest glibc source shows there is
> zero MIPS code for nptl.  A couple of other arches
> are missing as well (such as ARM)
> 
> Jun

All I've heard about this is that some kernel changes are (still?) 
needed, then just the glibc support along w/ TLS (Maybe compiler support?).

I believe I heard reports that the glibc people were looking to 
deprecate linuxthreads within a another release or two (but don't know 
specifics or anything), so it sounds like NPTL should be something to 
get working.


--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 akshay.singh@analog.com Thu Aug  5 14:06:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 14:07:01 +0100 (BST)
Received: from nwd2mail2.analog.com ([IPv6:::ffff:137.71.25.51]:21900 "EHLO
	nwd2mail2.analog.com") by linux-mips.org with ESMTP
	id <S8225230AbUHENG5>; Thu, 5 Aug 2004 14:06:57 +0100
Received: from nwd2mhb2.analog.com (nwd2mhb2.analog.com [137.71.6.12])
	by nwd2mail2.analog.com (8.12.10/8.12.10) with ESMTP id i75D6sfT026934
	for <linux-mips@ftp.linux-mips.org>; Thu, 5 Aug 2004 09:06:54 -0400
Received: from jasmine.cpgindia.analog.com ([10.121.13.30])
	by nwd2mhb2.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id JAA18049
	for <linux-mips@ftp.linux-mips.org>; Thu, 5 Aug 2004 09:06:55 -0400 (EDT)
Received: from asingh2d01 ([10.121.13.93])
	by jasmine.cpgindia.analog.com (8.9.1/8.9.1) with SMTP id SAA13722
	for <linux-mips@ftp.linux-mips.org>; Thu, 5 Aug 2004 18:36:50 +0530 (IST)
From: "akshay" <akshay.singh@analog.com>
To: <linux-mips@ftp.linux-mips.org>
Subject: RE: pthread uClibc
Date: Thu, 5 Aug 2004 18:48:48 +0530
Message-ID: <005601c47aee$beb7faf0$5d0d790a@asingh2d01>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Scanned-By: MIMEDefang 2.41
Return-Path: <akshay.singh@analog.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org
Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org
X-archive-position: 5599
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: akshay.singh@analog.com
Precedence: bulk
X-list: linux-mips


Hi,

I am trying to use pthread on mips based platform.

I have simple program to just create pthreads and when I run my program, it
goes does not come back and when I hit enter on screen, I see following
message on console.

pt: assertion failed in manager.c:154.

pt: assertion failed in manager.c:193.

Can someone plz help me here .


Thanks,
Akshay


From akshay.singh@analog.com Thu Aug  5 14:08:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 14:08:06 +0100 (BST)
Received: from nwd2mail2.analog.com ([IPv6:::ffff:137.71.25.51]:37772 "EHLO
	nwd2mail2.analog.com") by linux-mips.org with ESMTP
	id <S8225230AbUHENIC>; Thu, 5 Aug 2004 14:08:02 +0100
Received: from nwd2mhb2.analog.com (nwd2mhb2.analog.com [137.71.6.12])
	by nwd2mail2.analog.com (8.12.10/8.12.10) with ESMTP id i75D80fT027638
	for <linux-mips@linux-mips.org>; Thu, 5 Aug 2004 09:08:00 -0400
Received: from jasmine.cpgindia.analog.com ([10.121.13.30])
	by nwd2mhb2.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id JAA18438
	for <linux-mips@linux-mips.org>; Thu, 5 Aug 2004 09:08:00 -0400 (EDT)
Received: from asingh2d01 ([10.121.13.93])
	by jasmine.cpgindia.analog.com (8.9.1/8.9.1) with SMTP id SAA13917
	for <linux-mips@linux-mips.org>; Thu, 5 Aug 2004 18:37:56 +0530 (IST)
From: "akshay" <akshay.singh@analog.com>
To: <linux-mips@linux-mips.org>
Subject: RE: pthread uClibc
Date: Thu, 5 Aug 2004 18:49:52 +0530
Message-ID: <005701c47aee$e62424b0$5d0d790a@asingh2d01>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Scanned-By: MIMEDefang 2.41
Return-Path: <akshay.singh@analog.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5600
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: akshay.singh@analog.com
Precedence: bulk
X-list: linux-mips




Hi,

I am trying to use pthread on mips based platform.

I have simple program to just create pthreads and when I run my program, it
goes does not come back and when I hit enter on screen, I see following
message on console.

pt: assertion failed in manager.c:154.

pt: assertion failed in manager.c:193.

Can someone plz help me here .


Thanks,
Akshay


From jsun@mvista.com Thu Aug  5 18:14:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 18:14:59 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:30201 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225238AbUHEROz>;
	Thu, 5 Aug 2004 18:14:55 +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 i75HEqar028373;
	Thu, 5 Aug 2004 10:14:52 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i75HEp2S028372;
	Thu, 5 Aug 2004 10:14:51 -0700
Date: Thu, 5 Aug 2004 10:14:51 -0700
From: Jun Sun <jsun@mvista.com>
To: Kumba <kumba@gentoo.org>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: anybody tried NPTL?
Message-ID: <20040805101451.A28337@mvista.com>
References: <20040804152936.D6269@mvista.com> <411188A8.9040607@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <411188A8.9040607@gentoo.org>; from kumba@gentoo.org on Wed, Aug 04, 2004 at 09:08:56PM -0400
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5601
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, Aug 04, 2004 at 09:08:56PM -0400, Kumba wrote:
> Jun Sun wrote:
> 
> > I am looking into porting NPTL to MIPS.  Just curious if
> > anybody has tried this before.
> > 
> > I notice there was a discussion about the ABI extension
> > for TLS (thread local storage) support.  Before that support
> > becomes a reality it seems one can still use NPTL with 
> > the help of additional system calls.
> > 
> > A rough search of latest glibc source shows there is
> > zero MIPS code for nptl.  A couple of other arches
> > are missing as well (such as ARM)
> > 
> > Jun
> 
> All I've heard about this is that some kernel changes are (still?) 
> needed, then just the glibc support along w/ TLS (Maybe compiler support?).
> 

TLS support requires ABI change, which involves work in gcc and binutils.
At current stage I think only a few arches have added TLS support.
MIPS is definitely not one of them.  Does anybody know about the current
status, for MIPS and other arches?

I think the ABI change and TLS support might take a long time to 
be ready.  It appears meanwhile NPTL can run without TLS, but would
need a couple of additional system calls that get and set thread
local area.

> I believe I heard reports that the glibc people were looking to 
> deprecate linuxthreads within a another release or two (but don't know 
> specifics or anything), so it sounds like NPTL should be something to 
> get working.
> 

That surely puts some urgency on this matter. :)

Jun

From giles67@yahoo.com Thu Aug  5 19:04:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 19:04:39 +0100 (BST)
Received: from web50806.mail.yahoo.com ([IPv6:::ffff:206.190.38.115]:48532
	"HELO web50806.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224918AbUHESEe>; Thu, 5 Aug 2004 19:04:34 +0100
Message-ID: <20040805180427.59029.qmail@web50806.mail.yahoo.com>
Received: from [65.204.143.11] by web50806.mail.yahoo.com via HTTP; Thu, 05 Aug 2004 11:04:27 PDT
Date: Thu, 5 Aug 2004 11:04:27 -0700 (PDT)
From: G H <giles67@yahoo.com>
Subject: RE: do_ri failure in cache flushing routines
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-732148992-1091729067=:57330"
Return-Path: <giles67@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: 5602
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: giles67@yahoo.com
Precedence: bulk
X-list: linux-mips

--0-732148992-1091729067=:57330
Content-Type: text/plain; charset=us-ascii

I've not had much response to this question so I would like to rephrase it :
 
Can anyone think of any possible scenario where do_ri could occur in blast_icache32() ??
 
Is this possibly a cache synchronisation problem ??
 
TIA
 
>While testing out an amd au1500 based board I have been getting " do_ri " exceptions >that always occur in the cache flushing routines. More often than not in >blast_icache_32().
 
>So far this has mainly happened after running the board for days on end while running >multiple telnet sessions to it. It has sometimes ( quite rarely ) happened after a few >hours to a day of multiple telnet session use.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-732148992-1091729067=:57330
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>I've not had much response to this question so I would like to rephrase it :</DIV>
<DIV>&nbsp;</DIV>
<DIV>Can anyone think of any possible scenario where do_ri could occur in blast_icache32() ??</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is this possibly a cache synchronisation problem ??</DIV>
<DIV>&nbsp;</DIV>
<DIV>TIA</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;While testing out an amd au1500 based board I have been getting " do_ri "&nbsp;exceptions &gt;that always occur in the cache flushing routines. More often than not in &gt;blast_icache_32().</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;So far this has mainly happened after&nbsp;running the board for days on end while running &gt;multiple telnet sessions to it. It has sometimes ( quite rarely ) happened after a few &gt;hours to a day of multiple telnet session use.</DIV></DIV><p>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam?  Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com 
--0-732148992-1091729067=:57330--

From ppopov@mvista.com Thu Aug  5 19:09:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 19:09:13 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:12278 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224918AbUHESJJ>;
	Thu, 5 Aug 2004 19:09:09 +0100
Received: from [10.0.10.221] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA04261;
	Thu, 5 Aug 2004 11:09:02 -0700
Message-ID: <411277BD.7070108@mvista.com>
Date: Thu, 05 Aug 2004 11:09:01 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: G H <giles67@yahoo.com>
CC: linux-mips@linux-mips.org
Subject: Re: do_ri failure in cache flushing routines
References: <20040805180427.59029.qmail@web50806.mail.yahoo.com>
In-Reply-To: <20040805180427.59029.qmail@web50806.mail.yahoo.com>
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: 5603
X-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

G H wrote:

> I've not had much response to this question so I would like to 
> rephrase it :
>  
> Can anyone think of any possible scenario where do_ri could occur in 
> blast_icache32() ??
>  
> Is this possibly a cache synchronisation problem ??
>  

Could be a hardware memory glitch. I would use kgdb to put a breakpoint 
there and see what the data in memory looks like when this happens -- 
look for memory corruption, etc.

Pete

> TIA
>  
> >While testing out an amd au1500 based board I have been getting " 
> do_ri " exceptions >that always occur in the cache flushing routines. 
> More often than not in >blast_icache_32().
>  
> >So far this has mainly happened after running the board for days on 
> end while running >multiple telnet sessions to it. It has sometimes ( 
> quite rarely ) happened after a few >hours to a day of multiple telnet 
> session use.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>


From jsun@mvista.com Thu Aug  5 19:11:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 19:11:39 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:54776 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224918AbUHESLf>;
	Thu, 5 Aug 2004 19:11:35 +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 i75IBXar028599;
	Thu, 5 Aug 2004 11:11:33 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i75IBXDd028598;
	Thu, 5 Aug 2004 11:11:33 -0700
Date: Thu, 5 Aug 2004 11:11:33 -0700
From: Jun Sun <jsun@mvista.com>
To: G H <giles67@yahoo.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: do_ri failure in cache flushing routines
Message-ID: <20040805111133.B28337@mvista.com>
References: <20040805180427.59029.qmail@web50806.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040805180427.59029.qmail@web50806.mail.yahoo.com>; from giles67@yahoo.com on Thu, Aug 05, 2004 at 11:04:27AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5604
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Aug 05, 2004 at 11:04:27AM -0700, G H wrote:
> I've not had much response to this question so I would like to rephrase it :
>  
> Can anyone think of any possible scenario where do_ri could occur in blast_icache32() ??
>  

One possibility _could_ be the "instruction flushing itself" problem on
MIPS32.  However, as far as I know au1x00 CPUs don't suffer from this problem.
Anybody knows for sure?

You could try to use the two phase cache flushing (such as the one used
by tx47xx and also see an earlier related discussion thread) and see if
the problem goes away.

Jun

From ppopov@mvista.com Thu Aug  5 19:13:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 19:13:29 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:37883 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225241AbUHESNY>;
	Thu, 5 Aug 2004 19:13:24 +0100
Received: from [10.0.10.221] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA04934;
	Thu, 5 Aug 2004 11:13:17 -0700
Message-ID: <411278BC.5060306@mvista.com>
Date: Thu, 05 Aug 2004 11:13:16 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: G H <giles67@yahoo.com>
CC: linux-mips@linux-mips.org
Subject: Re: do_ri failure in cache flushing routines
References: <20040805180427.59029.qmail@web50806.mail.yahoo.com> <411277BD.7070108@mvista.com>
In-Reply-To: <411277BD.7070108@mvista.com>
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: 5605
X-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

Pete Popov wrote:

> G H wrote:
>
>> I've not had much response to this question so I would like to 
>> rephrase it :
>>  
>> Can anyone think of any possible scenario where do_ri could occur in 
>> blast_icache32() ??
>>  
>> Is this possibly a cache synchronisation problem ??
>>  
>
>
> Could be a hardware memory glitch. I would use kgdb to put a 
> breakpoint there and see what the data in memory looks like when this 
> happens -- look for memory corruption, etc.

Another thought, what other stress testing have you done on your board? 
Does it complete a full native kernel compile without crashing?

Pete

>
> Pete
>
>> TIA
>>  
>> >While testing out an amd au1500 based board I have been getting " 
>> do_ri " exceptions >that always occur in the cache flushing routines. 
>> More often than not in >blast_icache_32().
>>  
>> >So far this has mainly happened after running the board for days on 
>> end while running >multiple telnet sessions to it. It has sometimes ( 
>> quite rarely ) happened after a few >hours to a day of multiple 
>> telnet session use.
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>
>


From giles67@yahoo.com Thu Aug  5 21:16:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 21:16:54 +0100 (BST)
Received: from web50806.mail.yahoo.com ([IPv6:::ffff:206.190.38.115]:17751
	"HELO web50806.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225241AbUHEUQu>; Thu, 5 Aug 2004 21:16:50 +0100
Message-ID: <20040805201643.6422.qmail@web50806.mail.yahoo.com>
Received: from [65.204.143.11] by web50806.mail.yahoo.com via HTTP; Thu, 05 Aug 2004 13:16:43 PDT
Date: Thu, 5 Aug 2004 13:16:43 -0700 (PDT)
From: G H <giles67@yahoo.com>
Subject: Re: do_ri failure in cache flushing routines
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <411277BD.7070108@mvista.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-470146373-1091737003=:5841"
Return-Path: <giles67@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: 5606
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: giles67@yahoo.com
Precedence: bulk
X-list: linux-mips

--0-470146373-1091737003=:5841
Content-Type: text/plain; charset=us-ascii

At the moment I don't have the board set up for using kgdb and it's complicated by the fact that we only have one serial console port. But I am looking into setting it up for kgdb now.
 
As far as stressing the system, it doesn't have enough resources ( disk space ) to be able to compile the kernel, but we did write a simple program that would stress the system by spawning multiple threads, each one performing floating point calculations. With this test, top reported a load average of over 400 and we have seen no failure so far.

Pete Popov <ppopov@mvista.com> wrote:
G H wrote:

> I've not had much response to this question so I would like to 
> rephrase it :
> 
> Can anyone think of any possible scenario where do_ri could occur in 
> blast_icache32() ??
> 
> Is this possibly a cache synchronisation problem ??
> 

Could be a hardware memory glitch. I would use kgdb to put a breakpoint 
there and see what the data in memory looks like when this happens -- 
look for memory corruption, etc.

Pete

> TIA
> 
> >While testing out an amd au1500 based board I have been getting " 
> do_ri " exceptions >that always occur in the cache flushing routines. 
> More often than not in >blast_icache_32().
> 
> >So far this has mainly happened after running the board for days on 
> end while running >multiple telnet sessions to it. It has sometimes ( 
> quite rarely ) happened after a few >hours to a day of multiple telnet 
> session use.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>


		
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
--0-470146373-1091737003=:5841
Content-Type: text/html; charset=us-ascii

<DIV>At the moment I don't have the board set up for using kgdb and it's complicated by the fact that we only have one serial console port. But I am looking into setting it up for kgdb now.</DIV>
<DIV>&nbsp;</DIV>
<DIV>As far as stressing the system, it doesn't have enough resources ( disk space ) to be able to compile the kernel, but we did write a simple program that would stress the system by spawning multiple threads, each one performing floating point calculations. With this test, top reported a load average of over 400 and we&nbsp;have seen&nbsp;no&nbsp;failure so far.<BR><BR><B><I>Pete Popov &lt;ppopov@mvista.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">G H wrote:<BR><BR>&gt; I've not had much response to this question so I would like to <BR>&gt; rephrase it :<BR>&gt; <BR>&gt; Can anyone think of any possible scenario where do_ri could occur in <BR>&gt; blast_icache32() ??<BR>&gt; <BR>&gt; Is this possibly a cache synchronisation problem ??<BR>&gt; <BR><BR>Could be a hardware memory glitch. I would use kgdb to put a breakpoint <BR>there and see what the data in memory looks like when this happens -- <BR>look for memory corruption, etc.<BR><BR>Pete<BR><BR>&gt; TIA<BR>&gt; <BR>&gt; &gt;While testing out an amd au1500 based board I have been getting " <BR>&gt; do_ri " exceptions &gt;that always occur in the cache flushing routines. <BR>&gt; More often than not in &gt;blast_icache_32().<BR>&gt; <BR>&gt; &gt;So far this has mainly happened after running the board for days on <BR>&gt; end while running &gt;multiple telnet sessions to it.
 It has sometimes ( <BR>&gt; quite rarely ) happened after a few &gt;hours to a day of multiple telnet <BR>&gt; session use.<BR>&gt;<BR>&gt; __________________________________________________<BR>&gt; Do You Yahoo!?<BR>&gt; Tired of spam? Yahoo! Mail has the best spam protection around<BR>&gt; http://mail.yahoo.com<BR>&gt;<BR><BR></BLOCKQUOTE><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/aac/*http://promotions.yahoo.com/new_mail/static/ease.html">Yahoo! Mail Address AutoComplete</a> - You start. We finish.
--0-470146373-1091737003=:5841--

From giles67@yahoo.com Thu Aug  5 21:25:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 21:25:42 +0100 (BST)
Received: from web50810.mail.yahoo.com ([IPv6:::ffff:206.190.38.253]:35217
	"HELO web50810.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225241AbUHEUZh>; Thu, 5 Aug 2004 21:25:37 +0100
Message-ID: <20040805202530.36026.qmail@web50810.mail.yahoo.com>
Received: from [65.204.143.11] by web50810.mail.yahoo.com via HTTP; Thu, 05 Aug 2004 13:25:30 PDT
Date: Thu, 5 Aug 2004 13:25:30 -0700 (PDT)
From: G H <giles67@yahoo.com>
Subject: Re: do_ri failure in cache flushing routines
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
In-Reply-To: <20040805111133.B28337@mvista.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-729533103-1091737530=:34229"
Return-Path: <giles67@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: 5607
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: giles67@yahoo.com
Precedence: bulk
X-list: linux-mips

--0-729533103-1091737530=:34229
Content-Type: text/plain; charset=us-ascii

I was also thinking that maybe it could be related to the MIPS32 instruction cache flushing routine, so I tried applying the patch Ralf posted. The system still functioned OK for me, but one other in my group had their board lock up hard ( no oops produced ), and when I asked Ralf if that patch was ready for applying to CVS, he said it needed to be reworked before doing that. As a result we didn't follow up too closely on that avenue of investigation.
 
So basically what I am concluding from the responses so far , is that do_ri should NEVER occur in blast_icache32() and for it to do so, it could be either a hardware problem, or possibly the MIPS32 icache flushing problem.
Anyone agree / disagree ?
 
Jun Sun <jsun@mvista.com> wrote:


One possibility _could_ be the "instruction flushing itself" problem on
MIPS32. However, as far as I know au1x00 CPUs don't suffer from this problem.
Anybody knows for sure?


You could try to use the two phase cache flushing (such as the one used
by tx47xx and also see an earlier related discussion thread) and see if
the problem goes away.


		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
--0-729533103-1091737530=:34229
Content-Type: text/html; charset=us-ascii

<DIV>I was also thinking that maybe it could be related to the MIPS32 instruction cache flushing routine, so I tried applying the patch Ralf posted. The system still functioned OK for me, but one other in my group had their board lock up hard ( no oops produced ), and when I asked Ralf if that patch was ready for applying to CVS, he said it needed to be reworked before doing that. As a result we didn't follow up too closely on that avenue of investigation.</DIV>
<DIV>&nbsp;</DIV>
<DIV>So basically what I am concluding from the responses so far , is that do_ri should NEVER occur in blast_icache32() and for it to do so, it could be either a hardware problem, or possibly the MIPS32 icache flushing problem.</DIV>
<DIV>Anyone agree / disagree ?</DIV>
<DIV>&nbsp;</DIV>
<DIV><B><I>Jun Sun &lt;jsun@mvista.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P><BR>One possibility _could_ be the "instruction flushing itself" problem on<BR>MIPS32. However, as far as I know au1x00 CPUs don't suffer from this problem.<BR>Anybody knows for sure?</P>
<P><BR>You could try to use the two phase cache flushing (such as the one used<BR>by tx47xx and also see an earlier related discussion thread) and see if<BR>the problem goes away.<BR></P></BLOCKQUOTE><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/security/*http://promotions.yahoo.com/new_mail/static/protection.html">Yahoo! Mail</a> - You care about security. So do we.
--0-729533103-1091737530=:34229--

From Jiang.Xu@echostar.com Thu Aug  5 21:30:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 21:31:02 +0100 (BST)
Received: from mailout2.echostar.com ([IPv6:::ffff:204.76.128.102]:61706 "EHLO
	mailout2.echostar.com") by linux-mips.org with ESMTP
	id <S8225241AbUHEUa4>; Thu, 5 Aug 2004 21:30:56 +0100
Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19)
	id <QHDV02NK>; Thu, 5 Aug 2004 14:30:44 -0600
Message-ID: <F71A246055866844B66AFEB10654E7860F1B84@riv-exchb6.echostar.com>
From: "Xu, Jiang" <Jiang.Xu@echostar.com>
To: linux-mips@linux-mips.org
Subject: shared memory issues on linux kernel 2.4.18
Date: Thu, 5 Aug 2004 14:30:34 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C47B2B.0F1D2E15"
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: 5608
X-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

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_01C47B2B.0F1D2E15
Content-Type: text/plain

Hi, All,
 
The kernel version may be old to most of you guys, but this is what I am
doing the tests on.
 
Previously I use uclibc tool chain and compiling everything fine and it runs
fine; System V IPC works, including shared memory works...
The nightmare starts when I try to use glibc tool chain.  I downloaded
crosstool and successfully compiled everything.
However, when I run it problem happens on shared memory.
What I did for testing is this:
1) call shmget to allocate the shared memory
2) call shmat to mmap to process virtual memory space.
3) call shmctl to verify everything appeared fine.
4) for testing, just write couple bytes inside of that memory region.
 
The problem and also the interesting thing is:
If without 4) everything runs fine.
However, once excute 4) or any type of the writing to that memory region,
the box will get a kernel crash later, but not immediately....
I guess the kernel crashes when kswapd tried to do something, because the
oops happens on kswapd with the following information:
 
Kernel BUG at filemap.c:908!
Unable to handle kernel paging request at virtual address 00000000, epc ==
80025ebc, ra == 80025ebc
 
But if I do not excute 4) everything runs perfect without problem.
 
At now, I am completely out of clue, wonder anybody may have any ideas and
can help me out??
 
Thanks
 
John
 
 
 

------_=_NextPart_001_01C47B2B.0F1D2E15
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=119061920-05082004>Hi, 
All,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>The kernel version 
may be old to most of you guys, but this is what I am doing the tests 
on.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>Previously I use 
uclibc tool chain and compiling everything fine and it runs fine;&nbsp;System V 
IPC works, including shared memory works...</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>The nightmare starts 
when I try to use glibc tool chain.&nbsp; I downloaded crosstool and 
successfully compiled everything.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>However, when I run 
it problem happens on shared memory.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>What I did for 
testing is this:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>1) call shmget to 
allocate the shared memory</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>2) call shmat to 
mmap to process virtual memory space.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>3) call shmctl to 
verify everything appeared fine.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>4) for testing, just 
write couple bytes inside of that memory region.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>The problem and also 
the interesting thing is:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>If without 4) 
everything runs fine.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>However, once excute 
4) or any type of the writing to that memory region, the box will get a kernel 
crash later, but not immediately....</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>I guess the kernel 
crashes when kswapd tried to do something, because&nbsp;the</SPAN></FONT><FONT 
face=Arial size=2><SPAN class=119061920-05082004> oops happens on kswapd with 
the following information:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>Kernel BUG at 
filemap.c:908!</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>Unable to handle 
kernel paging request at virtual address 00000000, epc == 80025ebc, ra == 
80025ebc</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>But if I do not 
excute 4) everything runs perfect without problem.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=119061920-05082004>At now, I am 
completely out of clue, wonder anybody may have any ideas and can help me 
out??</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004>Thanks</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004>John</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=119061920-05082004></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C47B2B.0F1D2E15--

From ppopov@mvista.com Thu Aug  5 23:31:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Aug 2004 23:31:43 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:4856 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225257AbUHEWbh>;
	Thu, 5 Aug 2004 23:31:37 +0100
Received: from [10.0.10.221] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA22714;
	Thu, 5 Aug 2004 15:31:33 -0700
Message-ID: <4112B545.8090103@mvista.com>
Date: Thu, 05 Aug 2004 15:31:33 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: G H <giles67@yahoo.com>
CC: linux-mips@linux-mips.org
Subject: Re: do_ri failure in cache flushing routines
References: <20040805201643.6422.qmail@web50806.mail.yahoo.com>
In-Reply-To: <20040805201643.6422.qmail@web50806.mail.yahoo.com>
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: 5609
X-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

G H wrote:

> At the moment I don't have the board set up for using kgdb and it's 
> complicated by the fact that we only have one serial console port. But 
> I am looking into setting it up for kgdb now.

A single serial port will work fine.

>  
> As far as stressing the system, it doesn't have enough resources ( 
> disk space ) to be able to compile the kernel, but we did write a 
> simple program that would stress the system by spawning multiple 
> threads, each one performing floating point calculations. With this 
> test, top reported a load average of over 400 and we have 
> seen no failure so far.

You can use an NFS mounted root fs to do native builds, assuming you 
have a native toolchain. That's an excellent stress test.

Pete

>
> */Pete Popov <ppopov@mvista.com>/* wrote:
>
>     G H wrote:
>
>     > I've not had much response to this question so I would like to
>     > rephrase it :
>     >
>     > Can anyone think of any possible scenario where do_ri could
>     occur in
>     > blast_icache32() ??
>     >
>     > Is this possibly a cache synchronisation problem ??
>     >
>
>     Could be a hardware memory glitch. I would use kgdb to put a
>     breakpoint
>     there and see what the data in memory looks like when this happens --
>     look for memory corruption, etc.
>
>     Pete
>
>     > TIA
>     >
>     > >While testing out an amd au1500 based board I have been getting "
>     > do_ri " exceptions >that always occur in the cache flushing
>     routines.
>     > More often than not in >blast_icache_32().
>     >
>     > >So far this has mainly happened after running the board for
>     days on
>     > end while running >multiple telnet sessions t! o it. It has
>     sometimes (
>     > quite rarely ) happened after a few >hours to a day of multiple
>     telnet
>     > session use.
>     >
>     > __________________________________________________
>     > Do You Yahoo!?
>     > Tired of spam? Yahoo! Mail has the best spam protection around
>     > http://mail.yahoo.com
>     >
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete 
> <http://us.rd.yahoo.com/mail_us/taglines/aac/*http://promotions.yahoo.com/new_mail/static/ease.html> 
> - You start. We finish. 



From ralf@linux-mips.org Fri Aug  6 03:03:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Aug 2004 03:03:14 +0100 (BST)
Received: from p508B5F12.dip.t-dialin.net ([IPv6:::ffff:80.139.95.18]:31504
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225261AbUHFCDJ>; Fri, 6 Aug 2004 03:03:09 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i76235um028380;
	Fri, 6 Aug 2004 04:03:05 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i76235Dn028379;
	Fri, 6 Aug 2004 04:03:05 +0200
Date: Fri, 6 Aug 2004 04:03:04 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Kumba <kumba@gentoo.org>
Cc: linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Message-ID: <20040806020304.GA27895@linux-mips.org>
References: <20040804152936.D6269@mvista.com> <411188A8.9040607@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <411188A8.9040607@gentoo.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5610
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Aug 04, 2004 at 09:08:56PM -0400, Kumba wrote:

> >I am looking into porting NPTL to MIPS.  Just curious if
> >anybody has tried this before.
> >
> >I notice there was a discussion about the ABI extension
> >for TLS (thread local storage) support.  Before that support
> >becomes a reality it seems one can still use NPTL with 
> >the help of additional system calls.
> >
> >A rough search of latest glibc source shows there is
> >zero MIPS code for nptl.  A couple of other arches
> >are missing as well (such as ARM)
> >
> >Jun
> 
> All I've heard about this is that some kernel changes are (still?) 
> needed, then just the glibc support along w/ TLS (Maybe compiler support?).
> 
> I believe I heard reports that the glibc people were looking to 
> deprecate linuxthreads within a another release or two (but don't know 
> specifics or anything), so it sounds like NPTL should be something to 
> get working.

Threading support means breaking the ABI compatibility.  There are other
issues that can best be solved by breakin the ABI which is why this is
stretching out.

  Ralf

From akshay.singh@analog.com Fri Aug  6 05:01:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Aug 2004 05:01:25 +0100 (BST)
Received: from nwd2mail2.analog.com ([IPv6:::ffff:137.71.25.51]:47051 "EHLO
	nwd2mail2.analog.com") by linux-mips.org with ESMTP
	id <S8224896AbUHFEBV>; Fri, 6 Aug 2004 05:01:21 +0100
Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12])
	by nwd2mail2.analog.com (8.12.10/8.12.10) with ESMTP id i7641GfT001707
	for <linux-mips@linux-mips.org>; Fri, 6 Aug 2004 00:01:16 -0400
Received: from jasmine.cpgindia.analog.com ([10.121.13.30])
	by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id AAA09577
	for <linux-mips@linux-mips.org>; Fri, 6 Aug 2004 00:01:07 -0400 (EDT)
Received: from asingh2d01 ([10.121.13.93])
	by jasmine.cpgindia.analog.com (8.9.1/8.9.1) with SMTP id JAA04143
	for <linux-mips@linux-mips.org>; Fri, 6 Aug 2004 09:31:04 +0530 (IST)
From: "akshay" <akshay.singh@analog.com>
To: <linux-mips@linux-mips.org>
Subject: pthread uClibc
Date: Fri, 6 Aug 2004 09:43:03 +0530
Message-ID: <006101c47b6b$abbd6610$5d0d790a@asingh2d01>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Scanned-By: MIMEDefang 2.41
Return-Path: <akshay.singh@analog.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5611
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: akshay.singh@analog.com
Precedence: bulk
X-list: linux-mips


Hi,

I am trying to use pthread on mips based platform.

I have simple program to just create pthreads and when I run my program, it
goes in infinite loop and never comes back.
Though when I hit enter on console, I see following message on console.

pt: assertion failed in manager.c:154.

pt: assertion failed in manager.c:193.

Can someone plz help me here .



Here is the code for my program.
==============================================================
#include <stdio.h>
#include <pthread.h>

void print_message_function( void *ptr );

     pthread_t thread1;
     char *message1 = "Thread 1";

main()
{
     int  iret1, iret2;

    /* Create independant threads each of which will execute function */

     iret1 = pthread_create( &thread1, NULL, (void*)&print_message_function,
(v
oid*) message1);

printf("threads created ....\n");
     /* Wait till threads are complete before main continues. Unless we  */
     /* wait we run the risk of executing an exit which will terminate   */
     /* the process and all threads before the threads have completed.   */

     pthread_join( thread1, NULL);

     printf("Thread 1 returns: %d\n",iret1);
     exit(0);
}

void print_message_function( void *ptr )
{
     char *message;
     message = (char *) ptr;
     printf("%s \n", message);
}





Thanks,
Akshay



From ratin@koperasw.com Fri Aug  6 07:30:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Aug 2004 07:30:53 +0100 (BST)
Received: from host73.ipowerweb.com ([IPv6:::ffff:12.129.211.254]:57566 "EHLO
	host73.ipowerweb.com") by linux-mips.org with ESMTP
	id <S8224844AbUHFGas> convert rfc822-to-8bit; Fri, 6 Aug 2004 07:30:48 +0100
Received: from c-67-170-233-233.client.comcast.net ([67.170.233.233] helo=ratwin1)
	by host73.ipowerweb.com with asmtp (Exim 3.36 #1)
	id 1BsyER-0008LJ-00; Thu, 05 Aug 2004 23:29:35 -0700
Reply-To: <ratin@koperasw.com>
From: "Ratin Kumar" <ratin@koperasw.com>
To: "'akshay'" <akshay.singh@analog.com>, <linux-mips@linux-mips.org>
Subject: RE: pthread uClibc
Date: Thu, 5 Aug 2004 23:30:22 -0700
Organization: Kopera Software Inc.
Message-ID: <00bc01c47b7e$de436130$6401a8c0@ratwin1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <006101c47b6b$abbd6610$5d0d790a@asingh2d01>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host73.ipowerweb.com
X-AntiAbuse: Original Domain - linux-mips.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - koperasw.com
Return-Path: <ratin@koperasw.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5612
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ratin@koperasw.com
Precedence: bulk
X-list: linux-mips

It might make a bit more sense if you talk a bit about your setup/toolchain
(cross??) and version of libraries used....

-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of akshay
Sent: Thursday, August 05, 2004 9:13 PM
To: linux-mips@linux-mips.org
Subject: pthread uClibc


Hi,

I am trying to use pthread on mips based platform.

I have simple program to just create pthreads and when I run my program, it
goes in infinite loop and never comes back.
Though when I hit enter on console, I see following message on console.

pt: assertion failed in manager.c:154.

pt: assertion failed in manager.c:193.

Can someone plz help me here .



Here is the code for my program.
==============================================================
#include <stdio.h>
#include <pthread.h>

void print_message_function( void *ptr );

     pthread_t thread1;
     char *message1 = "Thread 1";

main()
{
     int  iret1, iret2;

    /* Create independant threads each of which will execute function */

     iret1 = pthread_create( &thread1, NULL, (void*)&print_message_function,
(v
oid*) message1);

printf("threads created ....\n");
     /* Wait till threads are complete before main continues. Unless we  */
     /* wait we run the risk of executing an exit which will terminate   */
     /* the process and all threads before the threads have completed.   */

     pthread_join( thread1, NULL);

     printf("Thread 1 returns: %d\n",iret1);
     exit(0);
}

void print_message_function( void *ptr )
{
     char *message;
     message = (char *) ptr;
     printf("%s \n", message);
}





Thanks,
Akshay








From thomas.koeller@baslerweb.com Fri Aug  6 17:34:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Aug 2004 17:34:56 +0100 (BST)
Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:39689
	"EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP
	id <S8224931AbUHFQew>; Fri, 6 Aug 2004 17:34:52 +0100
Received: from comm1.baslerweb.com (proxy.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
          for <linux-mips@linux-mips.org>; Fri, 6 Aug 2004 18:34:04 +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 PLG5QZ4Y; Fri, 6 Aug 2004 18:34:50 +0200
From: Thomas Koeller <thomas.koeller@baslerweb.com>
Organization: Basler AG
To: linux-mips@linux-mips.org
Subject: [PATCH] yosemite serial support
Date: Fri, 6 Aug 2004 18:36:24 +0200
User-Agent: KMail/1.6.2
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200408061836.24385.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: 5613
X-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

Hi,

the patch below adds support for the second serial
port on the PMC-Sierra Yosemite board.

tk

--- linux-mips/arch/mips/pmc-sierra/yosemite/setup.c    2004-07-20 11:43:44.000000000 +0200
+++ linux-mips-work/arch/mips/pmc-sierra/yosemite/setup.c       2004-08-06 18:30:55.518022384 +0200
@@ -156,11 +156,13 @@
 #define TITAN_UART_CLK         3686400
 #define TITAN_SERIAL_BASE_BAUD (TITAN_UART_CLK / 16)
 #define TITAN_SERIAL_IRQ       4
-#define TITAN_SERIAL_BASE      0xfd000008UL
+#define TITAN_SERIAL_BASE      0xfd000000UL
+#define TITAN_SERIAL_REG_SIZE  8

 static void __init py_map_ocd(void)
 {
-        struct uart_port up;
+       struct uart_port up;
+       static const char serr[] = KERN_ERR "Early serial init of port %u failed\n";

        /*
         * Not specifically interrupt stuff but in case of SMP core_send_ipi
@@ -171,20 +173,26 @@
                panic("Mapping OCD failed - game over.  Your score is 0.");

        /*
-        * Register to interrupt zero because we share the interrupt with
-        * the serial driver which we don't properly support yet.
+        * Set up serial port #1. Do not use autodetection; the result is
+        * not what we want.
         */
        memset(&up, 0, sizeof(up));
-       up.membase      = (unsigned char *) ioremap(TITAN_SERIAL_BASE, 8);
+       up.membase      = (unsigned char *) ioremap(TITAN_SERIAL_BASE, TITAN_SERIAL_REG_SIZE * 2);
        up.irq          = TITAN_SERIAL_IRQ;
        up.uartclk      = TITAN_UART_CLK;
        up.regshift     = 0;
        up.iotype       = UPIO_MEM;
-       up.flags        = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
-       up.line         = 0;
+       up.flags        = UPF_SHARE_IRQ;
+       up.line         = 1;
+       up.type         = PORT_16550A;
+       if (!up.membase || early_serial_setup(&up))
+               printk(serr, up.line);

+       /* And now for port #0. */
+       up.membase      += TITAN_SERIAL_REG_SIZE;
+       up.line         = 0;
        if (early_serial_setup(&up))
-               printk(KERN_ERR "Early serial init of port 0 failed\n");
+               printk(serr, up.line);
 }

 static int __init pmc_yosemite_setup(void)

-- 
--------------------------------------------------

Thomas Koeller, Software Development
Basler Vision Technologies

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

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

From rsandifo@redhat.com Sat Aug  7 20:01:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Aug 2004 20:02:01 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:9186 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224920AbUHGTBz>;
	Sat, 7 Aug 2004 20:01:55 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i77J1me1005484;
	Sat, 7 Aug 2004 15:01:48 -0400
Received: from localhost (mail@vpnuser2.surrey.redhat.com [172.16.9.2])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i77J1ja28505;
	Sat, 7 Aug 2004 15:01:45 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1BtWRr-0000Km-00; Sat, 07 Aug 2004 20:01:43 +0100
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl>
	<87hds49bmo.fsf@redhat.com>
	<Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl>
	<20040719213801.GD14931@redhat.com>
	<Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl>
	<20040723202703.GB30931@redhat.com>
	<20040723211232.GB5138@linux-mips.org>
	<Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl>
	<410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com>
	<410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com>
	<410F60DF.9020400@mips.com>
	<Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Sat, 07 Aug 2004 20:01:43 +0100
In-Reply-To: <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl> (Maciej
 W. Rozycki's message of "Wed, 4 Aug 2004 21:57:04 +0200 (CEST)")
Message-ID: <87r7qiwz54.fsf@redhat.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@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: 5614
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

FWIW, here's a work-in-progress patch.  It takes the current
optabs handling of doubleword shifts by constants and generalises
it to handle variable shifts as well.  I've tried to take advantage
of SHIFT_COUNT_TRUNCATED where possible.

Unfortunately, I'm not sure whether the code is good enough in the
!SHIFT_COUNT_TRUNCATED case.  E.g. ARM has special asm versions of
64-bit shifts, and it takes advantage of the fact that word shifts by
32 bits or more will set the result to 0 (ashl or lshr) or -1 (ashr).
We can't do that in optabs.c since !SHIFT_COUNT_TRUNCATED dosn't mean
that shifts _aren't_ truncated, it simply means that the behaviour of
out-of-range shifts is undefined.

I've checked that the new open-coded variable shifts do work on ARM,
but perhaps they should be disabled on !SHIFT_COUNT_TRUNCATED targets,
at least for now.

Anyway, the SHIFT_COUNT_TRUNCATED version produces MIPS sequences
that are the same length as Maciej's asm versions (assuming conditional
moves are available).  They should take 5 cycles on a typical 2-way
superscalar target.

I've bootstrapped & regression tested the patch on mips-sgi-irix6.5 but
it's not really ready for approval yet.  Just posting for info & comments.

Of course, this doesn't let linux off the hook.  It still needs to define
the libgcc shift functions if it wants to support -Os compilation.

Richard


	* optabs.c (simplify_expand_binop, expand_superword_shift)
	(expand_subword_shift, expand_doubleword_shift): New functions.
	Generalize expand_binop's handling of doubleword shifts so that
	it can cope with non-constant shift amounts.
	(expand_binop): Replace said handling with expand_doubleword_shift.

Index: optabs.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/optabs.c,v
retrieving revision 1.231
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.231 optabs.c
*** optabs.c	22 Jul 2004 08:20:35 -0000	1.231
--- optabs.c	7 Aug 2004 07:14:19 -0000
*************** optab_for_tree_code (enum tree_code code
*** 709,715 ****
--- 709,981 ----
        return NULL;
      }
  }
+ 
+ /* Like expand_binop, but return a constant rtx if the result can be
+    calculated at compile time.  The arguments and return value are
+    otherwise the same as for expand_binop.  */
+ 
+ static rtx
+ simplify_expand_binop (enum machine_mode mode, optab binoptab,
+ 		       rtx op0, rtx op1, rtx target, int unsignedp,
+ 		       enum optab_methods methods)
+ {
+   if (CONSTANT_P (op0) && CONSTANT_P (op1))
+     return simplify_gen_binary (binoptab->code, mode, op0, op1);
+   else
+     return expand_binop (mode, binoptab, op0, op1, target, unsignedp, methods);
+ }
  
+ /* This subroutine of expand_doubleword_shift handles the cases in which
+    the effective shift value is >= BITS_PER_WORD.  The arguments and return
+    value are the same as for the parent routine.  */
+ 
+ static bool
+ expand_superword_shift (enum machine_mode op1_mode, optab binoptab,
+ 			rtx outof_input, rtx op1,
+ 			rtx outof_target, rtx into_target,
+ 			int unsignedp, enum optab_methods methods)
+ {
+   rtx tmp;
+ 
+   /* If shifts aren't truncated, we should shift OUTOF_INPUT by
+      (OP1 - BITS_PER_WORD) bits and store the result in INTO_TARGET.
+      If shifts are truncated, we can just shift by OP1 itself .  */
+   if (SHIFT_COUNT_TRUNCATED && !CONSTANT_P (op1))
+     tmp = op1;
+   else
+     {
+       tmp = immed_double_const (BITS_PER_WORD, 0, op1_mode);
+       tmp = simplify_expand_binop (op1_mode, sub_optab, op1, tmp,
+ 				   0, true, methods);
+       if (tmp == 0)
+ 	return false;
+     }
+   tmp = expand_binop (word_mode, binoptab, outof_input, tmp,
+ 		      into_target, unsignedp, methods);
+   if (tmp == 0)
+     return false;
+   if (tmp != into_target)
+     emit_move_insn (into_target, tmp);
+ 
+   /* For a signed right shift, we must fill OUTOF_TARGET with copies
+      of the sign bit, otherwise we must fill it with zeros.  */
+   if (binoptab != ashr_optab)
+     tmp = CONST0_RTX (word_mode);
+   else
+     {
+       tmp = expand_binop (word_mode, binoptab,
+ 			  outof_input, GEN_INT (BITS_PER_WORD - 1),
+ 			  outof_target, unsignedp, methods);
+       if (tmp == 0)
+ 	return false;
+     }
+   if (tmp != outof_target)
+     emit_move_insn (outof_target, tmp);
+ 
+   return true;
+ }
+ 
+ /* This subroutine of expand_doubleword_shift handles the cases in which
+    the effective shift value is < BITS_PER_WORD.  The arguments and return
+    value are the same as for the parent routine.  */
+ 
+ static bool
+ expand_subword_shift (enum machine_mode op1_mode, optab binoptab,
+ 		      rtx outof_input, rtx into_input, rtx op1,
+ 		      rtx outof_target, rtx into_target,
+ 		      int unsignedp, enum optab_methods methods)
+ {
+   optab reverse_unsigned_shift, unsigned_shift;
+   rtx tmp, carries;
+ 
+   reverse_unsigned_shift = (binoptab == ashl_optab ? lshr_optab : ashl_optab);
+   unsigned_shift = (binoptab == ashl_optab ? ashl_optab : lshr_optab);
+ 
+   /* The low OP1 bits of INTO_TARGET come from the high bits of OUTOF_INPUT.
+      We therefore need to shift OUTOF_INPUT by (BITS_PER_WORD - OP1) bits in
+      the opposite direction to BINOPTAB.  */
+   if (GET_CODE (op1) != CONST_INT || INTVAL (op1) == 0)
+     {
+       /* We must avoid shifting by BITS_PER_WORD bits since that is
+ 	 either the same as a zero shift (if SHIFT_COUNT_TRUNCATED)
+ 	 or has undefined RTL semantics.  Do a single shift first,
+ 	 then shift by the remainder.  It's OK to use ~OP1 as the
+ 	 remainder if shift counts are truncated.  */
+       carries = expand_binop (word_mode, reverse_unsigned_shift,
+ 			      outof_input, const1_rtx, 0, unsignedp, methods);
+       if (SHIFT_COUNT_TRUNCATED && !CONSTANT_P (op1))
+ 	{
+ 	  tmp = immed_double_const (-1, -1, op1_mode);
+ 	  tmp = simplify_expand_binop (op1_mode, xor_optab, op1, tmp,
+ 				       0, true, methods);
+ 	}
+       else
+ 	{
+ 	  tmp = immed_double_const (BITS_PER_WORD - 1, 0, op1_mode);
+ 	  tmp = simplify_expand_binop (op1_mode, sub_optab, tmp, op1,
+ 				       0, true, methods);
+ 	}
+     }
+   else
+     {
+       carries = outof_input;
+       tmp = immed_double_const (BITS_PER_WORD, 0, op1_mode);
+       tmp = simplify_expand_binop (op1_mode, sub_optab, tmp, op1,
+ 				   0, true, methods);
+     }
+   if (tmp == 0 || carries == 0)
+     return false;
+   carries = expand_binop (word_mode, reverse_unsigned_shift,
+ 			  carries, tmp, 0, unsignedp, methods);
+   if (carries == 0)
+     return false;
+ 
+   /* Shift INTO_INPUT logically by OP1 bits...  */
+   tmp = expand_binop (word_mode, unsigned_shift, into_input, op1,
+ 		      0, unsignedp, methods);
+   if (tmp == 0)
+     return false;
+ 
+   /* ...and OR in the bits carried over from OUTOF_INPUT.  */
+   tmp = expand_binop (word_mode, ior_optab, carries, tmp,
+ 		      into_target, unsignedp, methods);
+   if (tmp == 0)
+     return false;
+   if (tmp != into_target)
+     emit_move_insn (into_target, tmp);
+ 
+   /* Use a standard word_mode shift for the out-of half.  */
+   tmp = expand_binop (word_mode, binoptab, outof_input, op1,
+ 		      outof_target, unsignedp, methods);
+   if (tmp == 0)
+     return false;
+   if (tmp != outof_target)
+     emit_move_insn (outof_target, tmp);
+ 
+   return true;
+ }
+ 
+ /* Expand a doubleword shift (ashl, ashr or lshr) using word-mode shifts.
+    OUTOF_INPUT is the input word that we are shifting away from and
+    INTO_INPUT is the word that we are shifting towards.  OUTOF_TARGET
+    and INTO_TARGET specify the equivalent words of the output.  OP1 is
+    the shift amount, which has mode OP1_MODE.  BINOPTAB, UNSIGNEDP and
+    METHODS are as for expand_binop.
+ 
+    This function must not assign to OUTOF_TARGET or INTO_TARGET
+    until it has completely finished with the input operands.
+ 
+    Return true if the shift could be successfully synthesized.  */
+ 
+ static bool
+ expand_doubleword_shift (enum machine_mode op1_mode, optab binoptab,
+ 			 rtx outof_input, rtx into_input, rtx op1,
+ 			 rtx outof_target, rtx into_target,
+ 			 int unsignedp, enum optab_methods methods)
+ {
+   rtx tmp, cmp1, cmp2;
+   rtx subword_label, done_label;
+ #ifdef HAVE_conditional_move
+   rtx start, outof_superword, into_superword;
+ #endif
+   enum rtx_code cmp_code;
+ 
+   /* Set CMP_CODE, CMP1 and CMP2 so that the rtx (CMP_CODE CMP1 CMP2)
+      is true when the effective shift value is less than BITS_PER_WORD.  */
+   tmp = immed_double_const (BITS_PER_WORD, 0, op1_mode);
+   if (SHIFT_COUNT_TRUNCATED)
+     {
+       cmp1 = simplify_expand_binop (op1_mode, and_optab,
+ 				    op1, tmp, 0, true, methods);
+       cmp2 = const0_rtx;
+       cmp_code = EQ;
+       if (cmp1 == 0)
+ 	return false;
+     }
+   else
+     {
+       cmp1 = op1;
+       cmp2 = tmp;
+       cmp_code = LT;
+     }
+ 
+   /* If we can compute the condition at compile time, pick the
+      appropriate subroutine.  */
+   tmp = simplify_relational_operation (cmp_code, SImode, op1_mode, cmp1, cmp2);
+   if (tmp != 0 && GET_CODE (tmp) == CONST_INT)
+     {
+       if (tmp == const0_rtx)
+ 	return expand_superword_shift (op1_mode, binoptab,
+ 				       outof_input, op1,
+ 				       outof_target, into_target,
+ 				       unsignedp, methods);
+       else
+ 	return expand_subword_shift (op1_mode, binoptab,
+ 				     outof_input, into_input, op1,
+ 				     outof_target, into_target,
+ 				     unsignedp, methods);
+     }
+ 
+ #ifdef HAVE_conditional_move
+   /* Try using conditional moves to select between the subword and
+      superword forms.  Do the superword version first, putting the
+      result into a temporary comprised of OUTOF_SUPERWORD and
+      INTO_SUPERWORD.  Then do the subword version and store it
+      directly into the final output.
+ 
+      Note that OUTOF_TARGET and INTO_SUPERWORD are both equal to
+      (shift OUTOF_INPUT OP1) when shift counts are truncated.  */
+   outof_superword = gen_reg_rtx (word_mode);
+   into_superword = gen_reg_rtx (word_mode);
+ 
+   start = get_last_insn ();
+   if (expand_superword_shift (op1_mode, binoptab,
+ 			      outof_input, op1,
+ 			      outof_superword, into_superword,
+ 			      unsignedp, methods)
+       && expand_subword_shift (op1_mode, binoptab,
+ 			       outof_input, into_input, op1,
+ 			       outof_target, into_target,
+ 			       unsignedp, methods)
+       && emit_conditional_move (into_target, cmp_code, cmp1, cmp2, op1_mode,
+ 				into_target, (SHIFT_COUNT_TRUNCATED
+ 					      ? outof_target
+ 					      : into_superword),
+ 				word_mode, unsignedp)
+       && emit_conditional_move (outof_target, cmp_code, cmp1, cmp2, op1_mode,
+ 				outof_target, outof_superword, word_mode,
+ 				unsignedp))
+     return true;
+ 
+   delete_insns_since (start);
+ #endif
+ 
+   /* As a last resort, use branches to select the correct alternative.  */
+   subword_label = gen_label_rtx ();
+   done_label = gen_label_rtx ();
+ 
+   do_compare_rtx_and_jump (cmp1, cmp2, cmp_code, true, op1_mode,
+ 			   0, 0, subword_label);
+ 
+   if (!expand_superword_shift (op1_mode, binoptab,
+ 			       outof_input, op1,
+ 			       outof_target, into_target,
+ 			       unsignedp, methods))
+     return false;
+ 
+   emit_jump_insn (gen_jump (done_label));
+   emit_barrier ();
+   emit_label (subword_label);
+ 
+   if (!expand_subword_shift (op1_mode, binoptab,
+ 			     outof_input, into_input, op1,
+ 			     outof_target, into_target,
+ 			     unsignedp, methods))
+     return false;
+ 
+   emit_label (done_label);
+   return true;
+ }
  
  /* Wrapper around expand_binop which takes an rtx code to specify
     the operation to perform, not an optab pointer.  All other
*************** expand_binop (enum machine_mode mode, op
*** 1035,1050 ****
    if ((binoptab == lshr_optab || binoptab == ashl_optab
         || binoptab == ashr_optab)
        && class == MODE_INT
!       && GET_CODE (op1) == CONST_INT
        && GET_MODE_SIZE (mode) == 2 * UNITS_PER_WORD
        && binoptab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing
        && ashl_optab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing
        && lshr_optab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing)
      {
!       rtx insns, inter, equiv_value;
        rtx into_target, outof_target;
        rtx into_input, outof_input;
!       int shift_count, left_shift, outof_word;
  
        /* If TARGET is the same as one of the operands, the REG_EQUAL note
  	 won't be accurate, so use a new target.  */
--- 1301,1317 ----
    if ((binoptab == lshr_optab || binoptab == ashl_optab
         || binoptab == ashr_optab)
        && class == MODE_INT
!       && (GET_CODE (op1) == CONST_INT || !optimize_size)
        && GET_MODE_SIZE (mode) == 2 * UNITS_PER_WORD
        && binoptab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing
        && ashl_optab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing
        && lshr_optab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing)
      {
!       rtx insns, equiv_value;
        rtx into_target, outof_target;
        rtx into_input, outof_input;
!       enum machine_mode op1_mode;
!       int left_shift, outof_word;
  
        /* If TARGET is the same as one of the operands, the REG_EQUAL note
  	 won't be accurate, so use a new target.  */
*************** expand_binop (enum machine_mode mode, op
*** 1053,1059 ****
  
        start_sequence ();
  
!       shift_count = INTVAL (op1);
  
        /* OUTOF_* is the word we are shifting bits away from, and
  	 INTO_* is the word that we are shifting bits towards, thus
--- 1320,1326 ----
  
        start_sequence ();
  
!       op1_mode = GET_MODE (op1) != VOIDmode ? GET_MODE (op1) : word_mode;
  
        /* OUTOF_* is the word we are shifting bits away from, and
  	 INTO_* is the word that we are shifting bits towards, thus
*************** expand_binop (enum machine_mode mode, op
*** 1069,1145 ****
        outof_input = operand_subword_force (op0, outof_word, mode);
        into_input = operand_subword_force (op0, 1 - outof_word, mode);
  
!       if (shift_count >= BITS_PER_WORD)
! 	{
! 	  inter = expand_binop (word_mode, binoptab,
! 			       outof_input,
! 			       GEN_INT (shift_count - BITS_PER_WORD),
! 			       into_target, unsignedp, next_methods);
! 
! 	  if (inter != 0 && inter != into_target)
! 	    emit_move_insn (into_target, inter);
! 
! 	  /* For a signed right shift, we must fill the word we are shifting
! 	     out of with copies of the sign bit.  Otherwise it is zeroed.  */
! 	  if (inter != 0 && binoptab != ashr_optab)
! 	    inter = CONST0_RTX (word_mode);
! 	  else if (inter != 0)
! 	    inter = expand_binop (word_mode, binoptab,
! 				  outof_input,
! 				  GEN_INT (BITS_PER_WORD - 1),
! 				  outof_target, unsignedp, next_methods);
! 
! 	  if (inter != 0 && inter != outof_target)
! 	    emit_move_insn (outof_target, inter);
! 	}
!       else
  	{
! 	  rtx carries;
! 	  optab reverse_unsigned_shift, unsigned_shift;
! 
! 	  /* For a shift of less then BITS_PER_WORD, to compute the carry,
! 	     we must do a logical shift in the opposite direction of the
! 	     desired shift.  */
! 
! 	  reverse_unsigned_shift = (left_shift ? lshr_optab : ashl_optab);
! 
! 	  /* For a shift of less than BITS_PER_WORD, to compute the word
! 	     shifted towards, we need to unsigned shift the orig value of
! 	     that word.  */
! 
! 	  unsigned_shift = (left_shift ? ashl_optab : lshr_optab);
! 
! 	  carries = expand_binop (word_mode, reverse_unsigned_shift,
! 				  outof_input,
! 				  GEN_INT (BITS_PER_WORD - shift_count),
! 				  0, unsignedp, next_methods);
  
- 	  if (carries == 0)
- 	    inter = 0;
- 	  else
- 	    inter = expand_binop (word_mode, unsigned_shift, into_input,
- 				  op1, 0, unsignedp, next_methods);
- 
- 	  if (inter != 0)
- 	    inter = expand_binop (word_mode, ior_optab, carries, inter,
- 				  into_target, unsignedp, next_methods);
- 
- 	  if (inter != 0 && inter != into_target)
- 	    emit_move_insn (into_target, inter);
- 
- 	  if (inter != 0)
- 	    inter = expand_binop (word_mode, binoptab, outof_input,
- 				  op1, outof_target, unsignedp, next_methods);
- 
- 	  if (inter != 0 && inter != outof_target)
- 	    emit_move_insn (outof_target, inter);
- 	}
- 
-       insns = get_insns ();
-       end_sequence ();
- 
-       if (inter != 0)
- 	{
  	  if (binoptab->code != UNKNOWN)
  	    equiv_value = gen_rtx_fmt_ee (binoptab->code, mode, op0, op1);
  	  else
--- 1336,1349 ----
        outof_input = operand_subword_force (op0, outof_word, mode);
        into_input = operand_subword_force (op0, 1 - outof_word, mode);
  
!       if (expand_doubleword_shift (op1_mode, binoptab,
! 				   outof_input, into_input, op1,
! 				   outof_target, into_target,
! 				   unsignedp, methods))
  	{
! 	  insns = get_insns ();
! 	  end_sequence ();
  
  	  if (binoptab->code != UNKNOWN)
  	    equiv_value = gen_rtx_fmt_ee (binoptab->code, mode, op0, op1);
  	  else
*************** expand_binop (enum machine_mode mode, op
*** 1148,1153 ****
--- 1352,1358 ----
  	  emit_no_conflict_block (insns, target, op0, op1, equiv_value);
  	  return target;
  	}
+       end_sequence ();
      }
  
    /* Synthesize double word rotates from single word shifts.  */

From rth@redhat.com Mon Aug  9 23:08:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Aug 2004 23:08:47 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:3033 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225002AbUHIWIn>;
	Mon, 9 Aug 2004 23:08:43 +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 i79LX0fu008535;
	Mon, 9 Aug 2004 17:33:00 -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 i79M8dX09238;
	Mon, 9 Aug 2004 18:08:39 -0400
Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i79M8cV29153;
	Mon, 9 Aug 2004 15:08:38 -0700
Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1])
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i79M8cOo016798;
	Mon, 9 Aug 2004 15:08:38 -0700
Received: (from rth@localhost)
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i79M8c8X016796;
	Mon, 9 Aug 2004 15:08:38 -0700
X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f
Date: Mon, 9 Aug 2004 15:08:38 -0700
From: Richard Henderson <rth@redhat.com>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
Message-ID: <20040809220838.GE16493@redhat.com>
Mail-Followup-To: Richard Henderson <rth@redhat.com>,
	Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
References: <20040723202703.GB30931@redhat.com> <20040723211232.GB5138@linux-mips.org> <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl> <410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com> <410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com> <410F60DF.9020400@mips.com> <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl> <87r7qiwz54.fsf@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87r7qiwz54.fsf@redhat.com>
User-Agent: Mutt/1.4.1i
Return-Path: <rth@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: 5615
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rth@redhat.com
Precedence: bulk
X-list: linux-mips

On Sat, Aug 07, 2004 at 08:01:43PM +0100, Richard Sandiford wrote:
> +   do_compare_rtx_and_jump (cmp1, cmp2, cmp_code, true, op1_mode,
> + 			   0, 0, subword_label);
> + 
> +   if (!expand_superword_shift (op1_mode, binoptab,
> + 			       outof_input, op1,
> + 			       outof_target, into_target,
> + 			       unsignedp, methods))
> +     return false;

Return without cleaning up the branch emitted?  In particular,
doing so without emitting the labels will result in ICEs.



r~

From rsandifo@redhat.com Tue Aug 10 06:30:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Aug 2004 06:30:43 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:46535 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224841AbUHJFai>;
	Tue, 10 Aug 2004 06:30:38 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7A5UZe1007950;
	Tue, 10 Aug 2004 01:30:35 -0400
Received: from localhost (mail@vpnuser2.surrey.redhat.com [172.16.9.2])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7A5UUa11250;
	Tue, 10 Aug 2004 01:30:30 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1BuPDQ-00008W-00; Tue, 10 Aug 2004 06:30:28 +0100
To: Richard Henderson <rth@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <20040723202703.GB30931@redhat.com>
	<20040723211232.GB5138@linux-mips.org>
	<Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl>
	<410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com>
	<410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com>
	<410F60DF.9020400@mips.com>
	<Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
	<87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Tue, 10 Aug 2004 06:30:28 +0100
In-Reply-To: <20040809220838.GE16493@redhat.com> (Richard Henderson's
 message of "Mon, 9 Aug 2004 15:08:38 -0700")
Message-ID: <87zn5336h7.fsf@redhat.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@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: 5616
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

Richard Henderson <rth@redhat.com> writes:
> On Sat, Aug 07, 2004 at 08:01:43PM +0100, Richard Sandiford wrote:
>> +   do_compare_rtx_and_jump (cmp1, cmp2, cmp_code, true, op1_mode,
>> + 			   0, 0, subword_label);
>> + 
>> +   if (!expand_superword_shift (op1_mode, binoptab,
>> + 			       outof_input, op1,
>> + 			       outof_target, into_target,
>> + 			       unsignedp, methods))
>> +     return false;
>
> Return without cleaning up the branch emitted?  In particular,
> doing so without emitting the labels will result in ICEs.

The whole thing's in a sequence that gets discarded if
expand_doubleword_shift returns false.  Isn't that enough?

Richad

From Ralf.Ackermann@KOM.tu-darmstadt.de Tue Aug 10 21:08:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Aug 2004 21:08:38 +0100 (BST)
Received: from drum.kom.e-technik.tu-darmstadt.de ([IPv6:::ffff:130.83.139.190]:31104
	"EHLO mailserver.KOM.e-technik.tu-darmstadt.de") by linux-mips.org
	with ESMTP id <S8225072AbUHJUId>; Tue, 10 Aug 2004 21:08:33 +0100
Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id WAA05288; Tue, 10 Aug 2004 22:07:55 +0200 (MEST)
Date: Tue, 10 Aug 2004 22:09:28 +0200 (CEST)
From: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
X-X-Sender: rac@shofar.kom.e-technik.tu-darmstadt.de
To: dev-list@meshcube.org
cc: Ralf Ackermann <rac@KOM.tu-darmstadt.de>, linux-mips@linux-mips.org
Subject: Q: PCI VGA on Meshcube - any progress?
In-Reply-To: <41176789.12682.FB0F085@localhost>
Message-ID: <Pine.LNX.4.58.0408102158480.14110@shofar.kom.e-technik.tu-darmstadt.de>
References: <41176789.12682.FB0F085@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Ralf.Ackermann@KOM.tu-darmstadt.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: 5617
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rac@KOM.tu-darmstadt.de
Precedence: bulk
X-list: linux-mips

Hello,

today my MS-9513 miniPCI VGA card arrived and I started trying to use it.
The card is identified in the /proc filesystem:

---------------
[root@meshcube01 root]# cat /proc/pci
PCI devices found:
  Bus  0, device   3, function  0:
    VGA compatible controller: ATI Technologies Inc Rage XL (rev 39).
      IRQ 5.
      Master Capable.  Latency=128.  Min Gnt=8.
      Non-prefetchable 32 bit memory at 0x40000000 [0x40ffffff].
      I/O at 0x300 [0x3ff].
      Non-prefetchable 32 bit memory at 0x41000000 [0x41000fff].
----------------

Nevertheless - it does not output any signal - which is probably / as 
expected due to the missing initialization (that is done by the BIOS on 
x86 systems).

Did anybody have any more practical success/experiences so far? If so:
 - Did you try to use the card with the fbdev code (and with which 
	kernel)?
 - Did somebody suceed in using an XFree X server (which?, any special 
	hints?)

In addition to a cross-compile environment I'm using a chrooted 
Redhat/MIPS installation. It does have the development tools and 
infrastructure to compile an XFree X server on my own - nevertheless, I'd 
like to share/wait for the experiences that others made before I spend 
more time on it right now.

Any hints are welcome!

Best regards
 Ralf

---------------------------------------------------------------
Dr. Ralf Ackermann            _         rac@KOM.tu-darmstadt.de
Multimedia Communications |/ | | |\/|           Merckstrasse 25
                          |\ |_| |  |  64283 Darmstadt, Germany
Tel.: (+49) 6151 16-6138                Fax: (+49) 6151 16-6152
---------------------------------------------------------------
             http://www.kom.tu-darmstadt.de/~rac
---------------------------------------------------------------

From Ralf.Ackermann@KOM.tu-darmstadt.de Tue Aug 10 21:30:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Aug 2004 21:30:44 +0100 (BST)
Received: from drum.kom.e-technik.tu-darmstadt.de ([IPv6:::ffff:130.83.139.190]:51328
	"EHLO mailserver.KOM.e-technik.tu-darmstadt.de") by linux-mips.org
	with ESMTP id <S8225072AbUHJUak>; Tue, 10 Aug 2004 21:30:40 +0100
Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id WAA05540; Tue, 10 Aug 2004 22:30:03 +0200 (MEST)
Date: Tue, 10 Aug 2004 22:31:37 +0200 (CEST)
From: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
X-X-Sender: rac@shofar.kom.e-technik.tu-darmstadt.de
To: dev-list@meshcube.org
cc: Ralf Ackermann <rac@KOM.tu-darmstadt.de>, linux-mips@linux-mips.org
Subject: Q: way to populate a (full featured) Debian/MIPS with the Meshcube
In-Reply-To: <Pine.LNX.4.58.0408102158480.14110@shofar.kom.e-technik.tu-darmstadt.de>
Message-ID: <Pine.LNX.4.58.0408102224260.14110@shofar.kom.e-technik.tu-darmstadt.de>
References: <41176789.12682.FB0F085@localhost>
 <Pine.LNX.4.58.0408102158480.14110@shofar.kom.e-technik.tu-darmstadt.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Ralf.Ackermann@KOM.tu-darmstadt.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: 5618
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rac@KOM.tu-darmstadt.de
Precedence: bulk
X-list: linux-mips

Hello,

since a few people (e.g. Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>) 
already earlier suggested to use a full-featured Debian/MIPS with the 
Meshcube - here are my 2 questions concerning that topic:
	1. Is there a step-by-step instruction list on how
		to bootstrap such an environment (with just the
		MeshCube and i386 Linux systems but no further MIPS system
		available)
	2. Could somebody provide a snapshot of a (basic) Debian/MIPS
		filesystem that can be mounted via NFS and chrooted to?
		(this would then let me start apt-get upgrading / 
		installing in it)
	(I could provide the storage space / connectivity to also host
		such a FS snapshot for others)

Many thanks for your help and best regards
 Ralf

---------------------------------------------------------------
Dr. Ralf Ackermann            _         rac@KOM.tu-darmstadt.de
Multimedia Communications |/ | | |\/|           Merckstrasse 25
                          |\ |_| |  |  64283 Darmstadt, Germany
Tel.: (+49) 6151 16-6138                Fax: (+49) 6151 16-6152
---------------------------------------------------------------
             http://www.kom.tu-darmstadt.de/~rac
---------------------------------------------------------------

From brederlo@informatik.uni-tuebingen.de Tue Aug 10 22:18:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Aug 2004 22:18:49 +0100 (BST)
Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:64949
	"EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP
	id <S8225195AbUHJVSo>; Tue, 10 Aug 2004 22:18:44 +0100
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id D472D115; Tue, 10 Aug 2004 23:18:37 +0200 (MST)
Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26])
 by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP
 id 30452-04; Tue, 10 Aug 2004 23:18:35 +0200 (DFT)
Received: from dual (semeai.Informatik.Uni-Tuebingen.De [134.2.15.66])
	by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id B1C7313B; Tue, 10 Aug 2004 23:18:33 +0200 (DFT)
Received: from mrvn by dual with local (Exim 4.34)
	id 1Bue0s-0004pE-2I; Tue, 10 Aug 2004 23:18:30 +0200
To: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
Cc: dev-list@meshcube.org, linux-mips@linux-mips.org
Subject: Re: Q: way to populate a (full featured) Debian/MIPS with the
 Meshcube
References: <41176789.12682.FB0F085@localhost>
	<Pine.LNX.4.58.0408102158480.14110@shofar.kom.e-technik.tu-darmstadt.de>
	<Pine.LNX.4.58.0408102224260.14110@shofar.kom.e-technik.tu-darmstadt.de>
From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Date: Tue, 10 Aug 2004 23:18:29 +0200
In-Reply-To: <Pine.LNX.4.58.0408102224260.14110@shofar.kom.e-technik.tu-darmstadt.de> (Ralf
 Ackermann's message of "Tue, 10 Aug 2004 22:31:37 +0200 (CEST)")
Message-ID: <878ycmlmje.fsf@mrvn.homelinux.org>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Return-Path: <brederlo@informatik.uni-tuebingen.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: 5619
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brederlo@informatik.uni-tuebingen.de
Precedence: bulk
X-list: linux-mips

Ralf Ackermann <rac@KOM.tu-darmstadt.de> writes:

> Hello,
>
> since a few people (e.g. Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>) 
> already earlier suggested to use a full-featured Debian/MIPS with the 
> Meshcube - here are my 2 questions concerning that topic:
> 	1. Is there a step-by-step instruction list on how
> 		to bootstrap such an environment (with just the
> 		MeshCube and i386 Linux systems but no further MIPS system
> 		available)

nfs-root? Debian (on that i386)?

cdebootstrap -amips sarge /tftpboot/<ip>/ http://ftp.de.debian.org/debian

That will fail after a while leaving you with a skeleton to boot from:

- create etc/fstab hosts resolv.conf apt/sources.list
- boot with init=/bin/sh
  - cd /var/cache/apt/archive/
  - dpkg --force-all -i libc6*deb
  - dpkg --force-all -i dpkg*deb
  - dpkg --force-all -i libc6*deb
  - dpkg -iGREB /var/cache/apt/archive/
  - dpkg -iGREB /var/cache/apt/archive/
  - dpkg -iGREB /var/cache/apt/archive/
  - check remaining dpkg errors if any
  - /usr/sbin/base-config
- adjust etc/inittab for serial console if you need
- reboot with normal init
- run dselect once going through all the top menu items to get all the
  standard packages added. You don't need to select any packages, just
  go into select once.

If you already have a unix on the meshcube run cdeboostrap there
(build it from source). Much easier.

> 	2. Could somebody provide a snapshot of a (basic) Debian/MIPS
> 		filesystem that can be mounted via NFS and chrooted to?
> 		(this would then let me start apt-get upgrading / 
> 		installing in it)
> 	(I could provide the storage space / connectivity to also host
> 		such a FS snapshot for others)

Again use cdebootstrap or debootstrap.

> Many thanks for your help and best regards
>  Ralf
>
> ---------------------------------------------------------------
> Dr. Ralf Ackermann            _         rac@KOM.tu-darmstadt.de
> Multimedia Communications |/ | | |\/|           Merckstrasse 25
>                           |\ |_| |  |  64283 Darmstadt, Germany
> Tel.: (+49) 6151 16-6138                Fax: (+49) 6151 16-6152
> ---------------------------------------------------------------
>              http://www.kom.tu-darmstadt.de/~rac
> ---------------------------------------------------------------

MfG
        Goswin

PS: You can ask your local DAluk for help if you get stuck too.

From rth@redhat.com Wed Aug 11 00:20:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 00:20:35 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:16011 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225197AbUHJXUa>;
	Wed, 11 Aug 2004 00:20:30 +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 i7AMijfu010383;
	Tue, 10 Aug 2004 18:44:45 -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 i7ANKLX29034;
	Tue, 10 Aug 2004 19:20:21 -0400
Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i7ANKLV13418;
	Tue, 10 Aug 2004 16:20:21 -0700
Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1])
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i7ANKLOo021940;
	Tue, 10 Aug 2004 16:20:21 -0700
Received: (from rth@localhost)
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i7ANKK3q021938;
	Tue, 10 Aug 2004 16:20:20 -0700
X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f
Date: Tue, 10 Aug 2004 16:20:20 -0700
From: Richard Henderson <rth@redhat.com>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
Message-ID: <20040810232020.GA21922@redhat.com>
Mail-Followup-To: Richard Henderson <rth@redhat.com>,
	Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
References: <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl> <410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com> <410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com> <410F60DF.9020400@mips.com> <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl> <87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com> <87zn5336h7.fsf@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87zn5336h7.fsf@redhat.com>
User-Agent: Mutt/1.4.1i
Return-Path: <rth@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: 5620
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rth@redhat.com
Precedence: bulk
X-list: linux-mips

On Tue, Aug 10, 2004 at 06:30:28AM +0100, Richard Sandiford wrote:
> The whole thing's in a sequence that gets discarded if
> expand_doubleword_shift returns false.  Isn't that enough?

Missed that, sorry.

Patch seems ok then.  We'd have to add a new macro/target flag
to handle non-truncating shifts -- we've got cases:

  (1) Large shift shifts out all bits (ARM)
  (2) Large shifts trap (VAX)
  (3) Shift count truncated to 31, always, which means QI/HI
      shifts are yield undefined results with large shifts.  (i386)


r~

From schwab@suse.de Wed Aug 11 01:29:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 01:29:33 +0100 (BST)
Received: from cantor.suse.de ([IPv6:::ffff:195.135.220.2]:1997 "EHLO
	Cantor.suse.de") by linux-mips.org with ESMTP id <S8225202AbUHKA33>;
	Wed, 11 Aug 2004 01:29:29 +0100
Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by Cantor.suse.de (Postfix) with ESMTP id 82B58A263DC;
	Wed, 11 Aug 2004 02:24:38 +0200 (CEST)
To: Richard Henderson <rth@redhat.com>
Cc: Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl>
	<410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com>
	<410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com>
	<410F60DF.9020400@mips.com>
	<Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
	<87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com>
	<87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com>
From: Andreas Schwab <schwab@suse.de>
X-Yow: I'm EXCITED!!  I want a FLANK STEAK WEEK-END!!  I think I'm JULIA
 CHILD!!
Date: Wed, 11 Aug 2004 02:24:37 +0200
In-Reply-To: <20040810232020.GA21922@redhat.com> (Richard Henderson's
 message of "Tue, 10 Aug 2004 16:20:20 -0700")
Message-ID: <je3c2usere.fsf@sykes.suse.de>
User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <schwab@suse.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: 5621
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: schwab@suse.de
Precedence: bulk
X-list: linux-mips

Richard Henderson <rth@redhat.com> writes:

> Patch seems ok then.  We'd have to add a new macro/target flag
> to handle non-truncating shifts -- we've got cases:
>
>   (1) Large shift shifts out all bits (ARM)
>   (2) Large shifts trap (VAX)
>   (3) Shift count truncated to 31, always, which means QI/HI
>       shifts are yield undefined results with large shifts.  (i386)
    (4) Shift count reduced modulo 64 (m68k)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

From paul@codesourcery.com Wed Aug 11 01:40:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 01:40:13 +0100 (BST)
Received: from pengo.systems.pipex.net ([IPv6:::ffff:62.241.160.193]:4537 "HELO
	pengo.systems.pipex.net") by linux-mips.org with SMTP
	id <S8225202AbUHKAkJ>; Wed, 11 Aug 2004 01:40:09 +0100
Received: from nowt.org (81-178-207-113.dsl.pipex.com [81.178.207.113])
	by pengo.systems.pipex.net (Postfix) with ESMTP id 91FD34C0011D;
	Wed, 11 Aug 2004 01:40:04 +0100 (BST)
Received: from wren.home (wren.home [192.168.1.7])
	by nowt.org (Postfix) with ESMTP id 39B23AC92;
	Wed, 11 Aug 2004 01:40:04 +0100 (BST)
From: Paul Brook <paul@codesourcery.com>
Organization: CodeSourcery
To: gcc-patches@gcc.gnu.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
Date: Wed, 11 Aug 2004 01:40:03 +0100
User-Agent: KMail/1.6.2
Cc: Richard Henderson <rth@redhat.com>,
	Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, linux-mips@linux-mips.org
References: <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl> <87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com>
In-Reply-To: <20040810232020.GA21922@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200408110140.03725.paul@codesourcery.com>
Return-Path: <paul@codesourcery.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5622
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: paul@codesourcery.com
Precedence: bulk
X-list: linux-mips

On Wednesday 11 August 2004 00:20, Richard Henderson wrote:
> On Tue, Aug 10, 2004 at 06:30:28AM +0100, Richard Sandiford wrote:
> > The whole thing's in a sequence that gets discarded if
> > expand_doubleword_shift returns false.  Isn't that enough?
>
> Missed that, sorry.
>
> Patch seems ok then.  We'd have to add a new macro/target flag
> to handle non-truncating shifts -- we've got cases:
>
>   (1) Large shift shifts out all bits (ARM)

ARM is actually shift count modulo 256

Paul

From rth@redhat.com Wed Aug 11 05:32:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 05:32:58 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:42921 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8224772AbUHKEcx>;
	Wed, 11 Aug 2004 05:32:53 +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 i7B3v3fu024512;
	Tue, 10 Aug 2004 23:57:03 -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 i7B4WiX07574;
	Wed, 11 Aug 2004 00:32:45 -0400
Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i7B4WiV23126;
	Tue, 10 Aug 2004 21:32:44 -0700
Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1])
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i7B4WiOo023115;
	Tue, 10 Aug 2004 21:32:44 -0700
Received: (from rth@localhost)
	by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i7B4Wi6Q023113;
	Tue, 10 Aug 2004 21:32:44 -0700
X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f
Date: Tue, 10 Aug 2004 21:32:44 -0700
From: Richard Henderson <rth@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
Message-ID: <20040811043244.GA23096@redhat.com>
Mail-Followup-To: Richard Henderson <rth@redhat.com>,
	Paul Brook <paul@codesourcery.com>, gcc-patches@gcc.gnu.org,
	Richard Sandiford <rsandifo@redhat.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, linux-mips@linux-mips.org
References: <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl> <87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com> <200408110140.03725.paul@codesourcery.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200408110140.03725.paul@codesourcery.com>
User-Agent: Mutt/1.4.1i
Return-Path: <rth@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: 5623
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rth@redhat.com
Precedence: bulk
X-list: linux-mips

On Wed, Aug 11, 2004 at 01:40:03AM +0100, Paul Brook wrote:
> ARM is actually shift count modulo 256

Ah, well.


r~

From Ralf.Ackermann@KOM.tu-darmstadt.de Wed Aug 11 08:34:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 08:34:11 +0100 (BST)
Received: from drum.kom.e-technik.tu-darmstadt.de ([IPv6:::ffff:130.83.139.190]:16009
	"EHLO mailserver.KOM.e-technik.tu-darmstadt.de") by linux-mips.org
	with ESMTP id <S8224839AbUHKHeH>; Wed, 11 Aug 2004 08:34:07 +0100
Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id JAA13244; Wed, 11 Aug 2004 09:34:00 +0200 (MEST)
Date: Wed, 11 Aug 2004 09:35:35 +0200 (CEST)
From: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
X-X-Sender: rac@shofar.kom.e-technik.tu-darmstadt.de
To: linux-mips@linux-mips.org
cc: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
Subject: Q: XFree86 (on MeshCube) from Debian?
Message-ID: <Pine.LNX.4.58.0408110935080.16674@shofar.kom.e-technik.tu-darmstadt.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Ralf.Ackermann@KOM.tu-darmstadt.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: 5624
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rac@KOM.tu-darmstadt.de
Precedence: bulk
X-list: linux-mips

Hello,

thanks a lot to the persons who helped me setting up a Debian/Sarge 
environment for the MeshCube (using cdebootstrap worked like a charm).

I may go on with an XFree86 server now (I tried using the ati module):
...
XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-6 20040709164028 
root@remake.rfc822
.org)
Release Date: 15 August 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.25 mips [ELF]
Build Date: 10 July 2004
...

Nevertheless - the server refuses to start because of:
Fatal server error:
xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)

Can this be fixed without having to install an alternative kernel on the 
cube? (e.g. by loading an additional / which? kernel module?)

best regards and thanks for your help
 Ralf

From tk@mycable.de Wed Aug 11 09:08:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 09:08:42 +0100 (BST)
Received: from mail.oricom.de ([IPv6:::ffff:62.116.167.249]:10883 "EHLO
	oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8224839AbUHKIIi>; Wed, 11 Aug 2004 09:08:38 +0100
Received: from mycable.de (p5086BF12.dip.t-dialin.net [80.134.191.18])
	(authenticated bits=0)
	by oricom4.internetx.de (8.13.0/8.13.0) with ESMTP id i7B87pmj021185;
	Wed, 11 Aug 2004 10:07:56 +0200
Message-ID: <4119D3B9.4050308@mycable.de>
Date: Wed, 11 Aug 2004 10:07:21 +0200
From: =?ISO-8859-1?Q?Tiemo_Kr=FCger_-_mycable_GmbH?= <tk@mycable.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
CC: linux-mips@linux-mips.org
Subject: Re: Q: XFree86 (on MeshCube) from Debian?
References: <Pine.LNX.4.58.0408110935080.16674@shofar.kom.e-technik.tu-darmstadt.de>
In-Reply-To: <Pine.LNX.4.58.0408110935080.16674@shofar.kom.e-technik.tu-darmstadt.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <tk@mycable.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5625
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tk@mycable.de
Precedence: bulk
X-list: linux-mips

Hi,


> Nevertheless - the server refuses to start because of:
> Fatal server error:
> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
> 

perhaps there is simply no /dev/tty0 ???

Maybe this will help:

http://mycable.de/xxs1500/cms/index.php?Linux:Graphics:Console


Tiemo


From michael.stickel@4g-systems.biz Wed Aug 11 10:05:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 10:05:58 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.188]:6876 "EHLO
	moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8224949AbUHKJFy>; Wed, 11 Aug 2004 10:05:54 +0100
Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1Bup3Q-0002lP-00
	for linux-mips@linux-mips.org; Wed, 11 Aug 2004 11:05:52 +0200
Received: from [80.129.147.123] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128)
	(Exim 3.35 #1)
	id 1Bup3Q-0002C9-00
	for linux-mips@linux-mips.org; Wed, 11 Aug 2004 11:05:52 +0200
From: Michael Stickel <michael.stickel@4g-systems.biz>
To: linux-mips@linux-mips.org
Subject: Re: Q: XFree86 (on MeshCube) from Debian?
Date: Wed, 11 Aug 2004 11:05:49 +0200
User-Agent: KMail/1.5.4
References: <Pine.LNX.4.58.0408110935080.16674@shofar.kom.e-technik.tu-darmstadt.de>
In-Reply-To: <Pine.LNX.4.58.0408110935080.16674@shofar.kom.e-technik.tu-darmstadt.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200408111105.50140.michael.stickel@4g-systems.biz>
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:f72049c8971f462876d14eb8b3ccbbf1
Return-Path: <michael.stickel@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5626
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michael.stickel@4g-systems.biz
Precedence: bulk
X-list: linux-mips


Do you have an nfs-rootfs?
If you have a serial cable you can load an alternate kernel from tftp.
It has to be in srec format.

On Wednesday 11 August 2004 09:35, you wrote:
> thanks a lot to the persons who helped me setting up a Debian/Sarge
> environment for the MeshCube (using cdebootstrap worked like a charm).
>
> I may go on with an XFree86 server now (I tried using the ati module):
> ...
> XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-6 20040709164028
> root@remake.rfc822
> .org)
> Release Date: 15 August 2003
> X Protocol Version 11, Revision 0, Release 6.6
> Build Operating System: Linux 2.4.25 mips [ELF]
> Build Date: 10 July 2004


From thomas.koeller@baslerweb.com Wed Aug 11 10:26:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 10:26:45 +0100 (BST)
Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:14866
	"EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP
	id <S8224839AbUHKJ0k>; Wed, 11 Aug 2004 10:26:40 +0100
Received: from comm1.baslerweb.com (proxy.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
          for <linux-mips@linux-mips.org>; Wed, 11 Aug 2004 11:25:43 +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 PLG5SNFT; Wed, 11 Aug 2004 11:26:37 +0200
From: Thomas Koeller <thomas.koeller@baslerweb.com>
Organization: Basler AG
To: linux-mips@linux-mips.org
Subject: [PATCH] serial support for yosemite
Date: Wed, 11 Aug 2004 11:28:44 +0200
User-Agent: KMail/1.6.2
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200408111128.44965.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: 5627
X-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

Hi,

this is a revised version of my previous yosemite patch.
It adds fully interrrupt-driven operation for both
serial ports as well as working kgdb support. It also
updates yosemite_defconfig to reflect the code changes.

tk




diff -rpu linux-mips/arch/mips/pmc-sierra/yosemite/dbg_io.c linux-mips-work/arch/mips/pmc-sierra/yosemite/dbg_io.c
--- linux-mips/arch/mips/pmc-sierra/yosemite/dbg_io.c	2004-05-20 17:01:41.000000000 +0200
+++ linux-mips-work/arch/mips/pmc-sierra/yosemite/dbg_io.c	2004-08-10 11:14:44.000000000 +0200
@@ -23,18 +23,22 @@
  *  675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
-/*
- * Support for KGDB for the Yosemite board. We make use of single serial
- * port to be used for KGDB as well as console. The second serial port
- * seems to be having a problem. Single IRQ is allocated for both the
- * ports. Hence, the interrupt routing code needs to figure out whether
- * the interrupt came from channel A or B.
- */
-
 #include <linux/config.h>
+#include <asm/io.h>
+
+#include "setup.h"
 
 #if defined(CONFIG_KGDB)
-#include <asm/serial.h>
+
+#if defined(CONFIG_SERIAL_8250) && CONFIG_SERIAL_8250_NR_UARTS > 1
+#error Debug port used by serial driver
+#endif
+
+#define TITAN_UART_CLK		3686400
+#define TITAN_SERIAL_BASE_BAUD	(TITAN_UART_CLK / 16)
+#define TITAN_SERIAL_BASE_0	0xfd000008UL
+#define TITAN_SERIAL_BASE_1	0xfd000000UL
+
 
 /*
  * Baud rate, Parity, Data and Stop bit settings for the
@@ -71,6 +75,7 @@
 #define	SERIAL_SEND_BUFFER	0x0
 #define	SERIAL_INTR_ENABLE	(1 * SERIAL_REG_OFS)
 #define	SERIAL_INTR_ID		(2 * SERIAL_REG_OFS)
+#define	SERIAL_FIFO_CONTROL	SERIAL_INTR_ID
 #define	SERIAL_DATA_FORMAT	(3 * SERIAL_REG_OFS)
 #define	SERIAL_LINE_CONTROL	(3 * SERIAL_REG_OFS)
 #define	SERIAL_MODEM_CONTROL	(4 * SERIAL_REG_OFS)
@@ -84,59 +89,26 @@
 #define	SERIAL_DIVISOR_MSB	(1 * SERIAL_REG_OFS)
 
 /*
- * Functions to READ and WRITE to serial port 0
+ * Functions to READ and WRITE to serial port
  */
-#define	SERIAL_READ(ofs)		(*((volatile unsigned char*)	\
-					(TITAN_SERIAL_BASE + ofs)))
-
-#define	SERIAL_WRITE(ofs, val)		((*((volatile unsigned char*)	\
-					(TITAN_SERIAL_BASE + ofs))) = val)
+#define	SERIAL_READ(ofs)		readb(serbase + ofs)
+#define	SERIAL_WRITE(ofs, val)		writeb((val), serbase + ofs)
 
-/*
- * Functions to READ and WRITE to serial port 1
- */
-#define	SERIAL_READ_1(ofs)		(*((volatile unsigned char*)	\
-					(TITAN_SERIAL_BASE_1 + ofs)
-
-#define	SERIAL_WRITE_1(ofs, val)	((*((volatile unsigned char*)	\
-					(TITAN_SERIAL_BASE_1 + ofs))) = val)
-
-/*
- * Second serial port initialization
- */
-void init_second_port(void)
-{
-	/* Disable Interrupts */
-	SERIAL_WRITE_1(SERIAL_LINE_CONTROL, 0x0);
-	SERIAL_WRITE_1(SERIAL_INTR_ENABLE, 0x0);
-
-	{
-		unsigned int divisor;
-
-		SERIAL_WRITE_1(SERIAL_LINE_CONTROL, 0x80);
-		divisor = TITAN_SERIAL_BASE_BAUD / YOSEMITE_BAUD_115200;
-		SERIAL_WRITE_1(SERIAL_DIVISOR_LSB, divisor & 0xff);
-
-		SERIAL_WRITE_1(SERIAL_DIVISOR_MSB,
-			       (divisor & 0xff00) >> 8);
-		SERIAL_WRITE_1(SERIAL_LINE_CONTROL, 0x0);
-	}
-
-	SERIAL_WRITE_1(SERIAL_DATA_FORMAT, YOSEMITE_DATA_8BIT |
-		       YOSEMITE_PARITY_NONE | YOSEMITE_STOP_1BIT);
-
-	/* Enable Interrupts */
-	SERIAL_WRITE_1(SERIAL_INTR_ENABLE, 0xf);
-}
+static int initialized = 0;
 
 /* Initialize the serial port for KGDB debugging */
 void debugInit(unsigned int baud, unsigned char data, unsigned char parity,
-	       unsigned char stop)
+	unsigned char stop)
 {
+	initialized = 1;
+	
 	/* Disable Interrupts */
 	SERIAL_WRITE(SERIAL_LINE_CONTROL, 0x0);
 	SERIAL_WRITE(SERIAL_INTR_ENABLE, 0x0);
 
+	/* Disable FIFOs */
+	SERIAL_WRITE(SERIAL_FIFO_CONTROL, 0x00);
+
 	{
 		unsigned int divisor;
 
@@ -152,15 +124,11 @@ void debugInit(unsigned int baud, unsign
 	SERIAL_WRITE(SERIAL_DATA_FORMAT, data | parity | stop);
 }
 
-static int remoteDebugInitialized = 0;
-
 unsigned char getDebugChar(void)
 {
-	if (!remoteDebugInitialized) {
-		remoteDebugInitialized = 1;
+	if (!initialized) {
 		debugInit(YOSEMITE_BAUD_115200,
-			  YOSEMITE_DATA_8BIT,
-			  YOSEMITE_PARITY_NONE, YOSEMITE_STOP_1BIT);
+			  YOSEMITE_DATA_8BIT, YOSEMITE_PARITY_NONE, YOSEMITE_STOP_1BIT);
 	}
 
 	while ((SERIAL_READ(SERIAL_LINE_STATUS) & 0x1) == 0);
@@ -169,11 +137,9 @@ unsigned char getDebugChar(void)
 
 int putDebugChar(unsigned char byte)
 {
-	if (!remoteDebugInitialized) {
-		remoteDebugInitialized = 1;
+	if (!initialized) {
 		debugInit(YOSEMITE_BAUD_115200,
-			  YOSEMITE_DATA_8BIT,
-			  YOSEMITE_PARITY_NONE, YOSEMITE_STOP_1BIT);
+			  YOSEMITE_DATA_8BIT, YOSEMITE_PARITY_NONE, YOSEMITE_STOP_1BIT);
 	}
 
 	while ((SERIAL_READ(SERIAL_LINE_STATUS) & 0x20) == 0);
diff -rpu linux-mips/arch/mips/pmc-sierra/yosemite/irq.c linux-mips-work/arch/mips/pmc-sierra/yosemite/irq.c
--- linux-mips/arch/mips/pmc-sierra/yosemite/irq.c	2004-07-14 16:21:29.000000000 +0200
+++ linux-mips-work/arch/mips/pmc-sierra/yosemite/irq.c	2004-08-10 11:33:57.000000000 +0200
@@ -110,7 +110,6 @@ asmlinkage void ll_ht_smp_irq_handler(in
 }
 
 #ifdef CONFIG_KGDB
-extern void init_second_port(void);
 extern void breakpoint(void);
 extern void set_debug_traps(void);
 #endif
@@ -126,18 +125,6 @@ void __init init_IRQ(void)
 	init_generic_irq();
 	mips_cpu_irq_init(0);
 	rm7k_cpu_irq_init(8);
-
-#ifdef CONFIG_KGDB
-	/* At this point, initialize the second serial port */
-	init_second_port();
-	printk("Start kgdb ... \n");
-	set_debug_traps();
-	breakpoint();
-#endif
-
-#ifdef CONFIG_GDB_CONSOLE
-	register_gdb_console();
-#endif
 }
 
 #ifdef CONFIG_KGDB
diff -rpu linux-mips/arch/mips/pmc-sierra/yosemite/setup.c linux-mips-work/arch/mips/pmc-sierra/yosemite/setup.c
--- linux-mips/arch/mips/pmc-sierra/yosemite/setup.c	2004-07-20 11:43:44.000000000 +0200
+++ linux-mips-work/arch/mips/pmc-sierra/yosemite/setup.c	2004-08-11 11:09:43.493286520 +0200
@@ -22,6 +22,7 @@
  *  with this program; if not, write  to the Free Software Foundation, Inc.,
  *  675 Mass Ave, Cambridge, MA 02139, USA.
  */
+#include <linux/config.h>
 #include <linux/bcd.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
@@ -44,6 +45,7 @@
 #include <asm/reboot.h>
 #include <asm/pci_channel.h>
 #include <asm/serial.h>
+#include <asm/gdb-stub.h>
 #include <linux/termios.h>
 #include <linux/tty.h>
 #include <linux/serial.h>
@@ -58,6 +60,7 @@ unsigned char titan_ge_mac_addr_base[6] 
 
 unsigned long cpu_clock;
 unsigned long yosemite_base;
+volatile unsigned char * serbase;
 
 void __init bus_error_init(void)
 {
@@ -156,11 +159,13 @@ EXPORT_SYMBOL(ocd_base);
 #define TITAN_UART_CLK		3686400
 #define TITAN_SERIAL_BASE_BAUD	(TITAN_UART_CLK / 16)
 #define TITAN_SERIAL_IRQ	4
-#define TITAN_SERIAL_BASE	0xfd000008UL
+#define TITAN_SERIAL_BASE	0xfd000000UL
+#define TITAN_SERIAL_REG_SIZE	8
 
 static void __init py_map_ocd(void)
 {
-        struct uart_port up;
+	static const char serr[] = KERN_ERR "Serial port #%u setup failed\n";
+	struct uart_port up;
 
 	/*
 	 * Not specifically interrupt stuff but in case of SMP core_send_ipi
@@ -170,21 +175,45 @@ static void __init py_map_ocd(void)
 	if (!ocd_base)
 		panic("Mapping OCD failed - game over.  Your score is 0.");
 
+	/* Map uart registers */
+	serbase = (unsigned char *) ioremap(TITAN_SERIAL_BASE, TITAN_SERIAL_REG_SIZE * 2);
+	if (!serbase)
+		panic("Failed to map UART registers");
+
+#if defined(CONFIG_SERIAL_8250)
 	/*
-	 * Register to interrupt zero because we share the interrupt with
-	 * the serial driver which we don't properly support yet.
+	 * Set up serial port #0. Do not use autodetection; the result is
+	 * not what we want.
 	 */
 	memset(&up, 0, sizeof(up));
-	up.membase      = (unsigned char *) ioremap(TITAN_SERIAL_BASE, 8);
+	up.membase      = serbase + TITAN_SERIAL_REG_SIZE;
 	up.irq          = TITAN_SERIAL_IRQ;
 	up.uartclk      = TITAN_UART_CLK;
 	up.regshift     = 0;
 	up.iotype       = UPIO_MEM;
-	up.flags        = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
+	up.type         = PORT_16550A;
+	up.flags        = UPF_SHARE_IRQ;
 	up.line         = 0;
+	if (early_serial_setup(&up))
+		printk(serr, up.line);
 
+#if CONFIG_SERIAL_8250_NR_UARTS > 1
+	/* And now for port #1. */
+	up.membase      = serbase;
+	up.line         = 1;
 	if (early_serial_setup(&up))
-		printk(KERN_ERR "Early serial init of port 0 failed\n");
+		printk(serr, up.line);
+#endif /* CONFIG_SERIAL_8250_NR_UARTS > 1 */
+#endif  /* defined(CONFIG_SERIAL_8250) */
+
+#ifdef CONFIG_KGDB
+	printk(KERN_INFO "Start kgdb ... \n");
+#ifdef CONFIG_GDB_CONSOLE
+	register_gdb_console();
+#endif
+	set_debug_traps();
+	breakpoint();
+#endif
 }
 
 static int __init pmc_yosemite_setup(void)
diff -rpu linux-mips/arch/mips/pmc-sierra/yosemite/setup.h linux-mips-work/arch/mips/pmc-sierra/yosemite/setup.h
--- linux-mips/arch/mips/pmc-sierra/yosemite/setup.h	2004-05-24 12:32:42.000000000 +0200
+++ linux-mips-work/arch/mips/pmc-sierra/yosemite/setup.h	2004-08-10 11:02:16.000000000 +0200
@@ -28,4 +28,7 @@
 #define	TITAN_ATMEL_24C32_SIZE		32768
 #define	TITAN_ATMEL_24C64_SIZE		65536
 
+/* UART base */
+extern volatile unsigned char * serbase;
+
 #endif /* __SETUP_H__ */
--- linux-mips/arch/mips/configs/yosemite_defconfig	2004-08-11 10:56:37.292807160 +0200
+++ linux-mips-work/arch/mips/configs/yosemite_defconfig	2004-08-11 11:22:35.905861960 +0200
@@ -352,8 +352,13 @@ CONFIG_SOUND_GAMEPORT=y
 #
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_NR_UARTS=4
-# CONFIG_SERIAL_8250_EXTENDED is not set
+CONFIG_SERIAL_8250_NR_UARTS=2
+CONFIG_SERIAL_8250_EXTENDED=y
+# CONFIG_SERIAL_8250_MANY_PORTS is not set
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+# CONFIG_SERIAL_8250_DETECT_IRQ is not set
+# CONFIG_SERIAL_8250_MULTIPORT is not set
+# CONFIG_SERIAL_8250_RSA is not set
 
 #
 # Non-8250 serial port support

-- 
--------------------------------------------------

Thomas Koeller, Software Development
Basler Vision Technologies

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

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

From brederlo@informatik.uni-tuebingen.de Wed Aug 11 19:46:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 19:46:19 +0100 (BST)
Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:17595
	"EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP
	id <S8225003AbUHKSqO>; Wed, 11 Aug 2004 19:46:14 +0100
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 22F8B10E; Wed, 11 Aug 2004 20:46:07 +0200 (MST)
Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26])
 by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP
 id 30314-05; Wed, 11 Aug 2004 20:46:05 +0200 (DFT)
Received: from dual (semeai.Informatik.Uni-Tuebingen.De [134.2.15.66])
	by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 79B18139; Wed, 11 Aug 2004 20:46:03 +0200 (DFT)
Received: from mrvn by dual with local (Exim 4.34)
	id 1Buy6o-0002Xx-MG; Wed, 11 Aug 2004 20:45:59 +0200
To: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
Cc: linux-mips@linux-mips.org
Subject: Re: Q: XFree86 (on MeshCube) from Debian?
References: <Pine.LNX.4.58.0408110935080.16674@shofar.kom.e-technik.tu-darmstadt.de>
From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Date: Wed, 11 Aug 2004 20:45:57 +0200
In-Reply-To: <Pine.LNX.4.58.0408110935080.16674@shofar.kom.e-technik.tu-darmstadt.de> (Ralf
 Ackermann's message of "Wed, 11 Aug 2004 09:35:35 +0200 (CEST)")
Message-ID: <87smatpl7e.fsf@mrvn.homelinux.org>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Return-Path: <brederlo@informatik.uni-tuebingen.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: 5628
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brederlo@informatik.uni-tuebingen.de
Precedence: bulk
X-list: linux-mips

Ralf Ackermann <rac@KOM.tu-darmstadt.de> writes:

> Hello,
>
> thanks a lot to the persons who helped me setting up a Debian/Sarge 
> environment for the MeshCube (using cdebootstrap worked like a charm).
>
> I may go on with an XFree86 server now (I tried using the ati module):
> ...
> XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-6 20040709164028 
> root@remake.rfc822
> .org)
> Release Date: 15 August 2003
> X Protocol Version 11, Revision 0, Release 6.6
> Build Operating System: Linux 2.4.25 mips [ELF]
> Build Date: 10 July 2004
> ...
>
> Nevertheless - the server refuses to start because of:
> Fatal server error:
> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
>
> Can this be fixed without having to install an alternative kernel on the 
> cube? (e.g. by loading an additional / which? kernel module?)

cdebootstrap only creates the absolutely essential device nodes for a
chroot. You need more device nodes, udev or devfs.

cd /dev
MAKEDEV generic

> best regards and thanks for your help
>  Ralf

MfG
        Goswin

From John.Foley@pollak.com Wed Aug 11 20:27:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 20:49:48 +0100 (BST)
Received: from mail.pollak.com ([IPv6:::ffff:199.105.206.135]:63826 "HELO
	canwebfilter01.pollak.com") by linux-mips.org with SMTP
	id <S8225003AbUHKT1g>; Wed, 11 Aug 2004 20:27:36 +0100
Received: from mailrouter.pollak.com ([204.26.10.31])
 by canwebfilter01.pollak.com (SMSSMTP 4.0.0.59) with SMTP id M2004081115272808594
 for <linux-mips@linux-mips.org>; Wed, 11 Aug 2004 15:27:28 -0400
Received: by mailrouter.pollak.com with Internet Mail Service (5.5.2657.72)
	id <QVHWKGP5>; Wed, 11 Aug 2004 15:33:02 -0400
Message-ID: <A89802C676E6124D86C0FC7C986B68F08C07C4@boston-exch.pollak.com>
From: "Foley, John" <John.Foley@pollak.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Free to a good home . . .
Date: Wed, 11 Aug 2004 15:26:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C47FD9.2065F4C0"
Return-Path: <John.Foley@pollak.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5629
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: John.Foley@pollak.com
Precedence: bulk
X-list: linux-mips

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

------_=_NextPart_001_01C47FD9.2065F4C0
Content-Type: text/plain

 

 

            I have several NeTpower FastSeries SP (MIPS R4600) workstations,
in various states of being stripped, that I am looking to donate to the
Linux cause. These machines are PCI and ISA (or EISA, depending on mobo rev)
and have DEC Tulip Ethernet and NCR FWSCSI (IIRC.)

            I'm located in Boston, and am willing to deliver and/or package
(within reason) in order to see these machines go to promote Linux.

 

            Any takers?

 

John T. Foley

Network Administrator, UNIX, CAD Systems, Data Coordinator

Pollak Engineered Products, Actuator Products Division, A Stoneridge Company

195 Freeport Street, Boston MA 02122

ph: (617) 474-7266 fax: (617) 282-9058

 

The geographical center of Boston is in Roxbury. Due north of the center we
find the South End. This is not to be confused with South Boston which lies
directly east from the South End. North of the South End is East Boston and
southwest of East Boston is the North End.

 



_________________________________________________________________ 
This electronic mail transmission contains confidential information intended
only for the person(s) and/or organization named. Any use, distribution,
copying or disclosure by or to any other person outside your organization is
strictly prohibited. If you received this transmission in error, please send
an electronic mail message to postmaster@pollak.com so we may instruct you
regarding its disposition.

------_=_NextPart_001_01C47FD9.2065F4C0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

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

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


<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; I have several NeTpower FastSeries SP (MIPS
R4600) workstations, in various states of being stripped, that I am =
looking to
donate to the Linux cause. These machines are PCI and ISA (or EISA, =
depending
on mobo rev) and have DEC Tulip Ethernet and NCR FWSCSI =
(IIRC.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; I'm located in <st1:City w:st=3D"on"><st1:place
 w:st=3D"on">Boston</st1:place></st1:City>, and am willing to deliver =
and/or
package (within reason) in order to see these machines go to promote =
Linux.<o:p></o:p></span></font></p>

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

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

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

<p style=3D'margin:0in;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>John T. Foley<o:p></o:p></span></font></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>Network Administrator, UNIX, CAD Systems, =
Data
Coordinator<o:p></o:p></span></font></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>Pollak Engineered Products, Actuator =
Products
Division, A Stoneridge Company<o:p></o:p></span></font></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><st1:address =
tabIndex=3D"0"
style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"
w:st=3D"on"><st1:Street w:st=3D"on"><font size=3D2 face=3D"Times New =
Roman"><span
  style=3D'font-size:10.0pt'>195 Freeport =
Street</span></font></st1:Street><font
 size=3D2><span style=3D'font-size:10.0pt'>, <st1:City =
w:st=3D"on">Boston</st1:City> <st1:State
 w:st=3D"on">MA</st1:State> <st1:PostalCode =
w:st=3D"on">02122</st1:PostalCode></span></font></st1:address><font
size=3D2><span style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>ph: (617) 474-7266 fax: (617) =
282-9058</span></font><o:p></o:p></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font><font size=3D2><span
style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>The geographical center of <st1:City =
w:st=3D"on"><st1:place
 w:st=3D"on">Boston</st1:place></st1:City> is in Roxbury. Due north of =
the center
we find the South End. This is not to be confused with <st1:place =
w:st=3D"on">South
 Boston</st1:place> which lies directly east from the South End. North =
of the
South End is East Boston and southwest of <st1:place w:st=3D"on">East =
Boston</st1:place>
is the North End.</span></font><font size=3D2><span =
style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>
<BR>
<BR>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">This electronic mail transmission =
contains confidential information intended only for the person(s) =
and/or organization named. Any use, distribution, copying or disclosure =
by or to any other person outside your organization is strictly =
prohibited. If you received this transmission in error, please send an =
electronic mail message to postmaster@pollak.com so we may instruct you =
regarding its disposition.</FONT></P>

------_=_NextPart_001_01C47FD9.2065F4C0--

From hch@lst.de Wed Aug 11 21:36:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Aug 2004 21:36:58 +0100 (BST)
Received: from verein.lst.de ([IPv6:::ffff:213.95.11.210]:35542 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8225208AbUHKUgy>;
	Wed, 11 Aug 2004 21:36:54 +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 i7BKar95005708
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Wed, 11 Aug 2004 22:36:53 +0200
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i7BKar6d005706;
	Wed, 11 Aug 2004 22:36:53 +0200
Date: Wed, 11 Aug 2004 22:36:53 +0200
From: Christoph Hellwig <hch@lst.de>
To: linux-mips@linux-mips.org
Cc: linux-cvs@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20040811203652.GA5680@lst.de>
References: <20040811202903Z8225206-1530+8297@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040811202903Z8225206-1530+8297@linux-mips.org>
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: 5630
X-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

On Wed, Aug 11, 2004 at 09:28:58PM +0100, ralf@linux-mips.org wrote:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	04/08/11 21:28:58
> 
> Modified files:
> 	fs/partitions  : sgi.c 
> 
> Log message:
> 	Handle MD array auto-detection in disk volume headers.

Note that adding more autodetection has been rejected for mainline
multiple times.


From mlohani@gmail.com Thu Aug 12 18:30:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Aug 2004 18:30:48 +0100 (BST)
Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.198]:17715 "EHLO
	mproxy.gmail.com") by linux-mips.org with ESMTP id <S8225212AbUHLRao>;
	Thu, 12 Aug 2004 18:30:44 +0100
Received: by mproxy.gmail.com with SMTP id 79so295472rnk
        for <linux-mips@linux-mips.org>; Thu, 12 Aug 2004 10:30:32 -0700 (PDT)
Received: by 10.38.171.68 with SMTP id t68mr80936rne;
        Thu, 12 Aug 2004 10:30:32 -0700 (PDT)
Message-ID: <b318a0150408121030389aa24c@mail.gmail.com>
Date: Thu, 12 Aug 2004 10:30:32 -0700
From: Manish Lohani <mlohani@gmail.com>
To: linux-mips@linux-mips.org
Subject: Busybox v0.60.2 insmod gives segmentation fault without any messages when trying to load a loadable module
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <mlohani@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5631
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mlohani@gmail.com
Precedence: bulk
X-list: linux-mips

I have a driver loadable module which i am compiling with the same gcc
flags as used to compile a kernel for a MIPS R5432 based NEC board.

On the development machine, to compile files driver1.c and driver2.c:
$ mips_fp_le-gcc -fomit-frame-pointer -fno-strict-aliasing -G 0
-mno-abicalls -fno-pic -pipe -mtune=r5000 -mlong-calls -mips2 -Wall -c
driver1.c

$mips_fp_le-ld -r -o driver --printmap --cref driver1.o driver2.o

mips_fp_le-gcc (GCC) version 3.3.1
mips_fp_le-ld (GNU ld) version 2.14

I have Busybox v0.60.2 on the target.

On the target:
# insmod ./driver
Using driver
Segmentation fault
#

Does anybody have any suggestions as to what could be wrong?

Thanks in advance,
Manu

From ddaney@avtrex.com Thu Aug 12 18:50:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Aug 2004 18:50:05 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:5704 "EHLO avtrex.com")
	by linux-mips.org with ESMTP id <S8225216AbUHLRuB>;
	Thu, 12 Aug 2004 18:50:01 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 12 Aug 2004 10:47:32 -0700
Message-ID: <411BAD50.6070004@avtrex.com>
Date: Thu, 12 Aug 2004 10:48:00 -0700
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Manish Lohani <mlohani@gmail.com>
CC: linux-mips@linux-mips.org
Subject: Re: Busybox v0.60.2 insmod gives segmentation fault without any messages
 when trying to load a loadable module
References: <b318a0150408121030389aa24c@mail.gmail.com>
In-Reply-To: <b318a0150408121030389aa24c@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Aug 2004 17:47:32.0625 (UTC) FILETIME=[71D0F010:01C48094]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5632
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

Manish Lohani wrote:
> I have a driver loadable module which i am compiling with the same gcc
> flags as used to compile a kernel for a MIPS R5432 based NEC board.
> 
> On the development machine, to compile files driver1.c and driver2.c:
> $ mips_fp_le-gcc -fomit-frame-pointer -fno-strict-aliasing -G 0
> -mno-abicalls -fno-pic -pipe -mtune=r5000 -mlong-calls -mips2 -Wall -c
> driver1.c
> 
> $mips_fp_le-ld -r -o driver --printmap --cref driver1.o driver2.o
> 
> mips_fp_le-gcc (GCC) version 3.3.1
> mips_fp_le-ld (GNU ld) version 2.14
> 
> I have Busybox v0.60.2 on the target.
> 
> On the target:
> # insmod ./driver
> Using driver
> Segmentation fault
> #
> 
> Does anybody have any suggestions as to what could be wrong?
> 

BusyBox0.60.x's insmod does not work with gcc-3.3 and above.

I use a patched version of the real insmod:

# insmod --version
insmod version 2.4.25

I forget where I put the patch, but the insmod author told me that the
patches were in a later version.  So if I were you, I would use version
2.4.26 or higher.

David Daney.


From Ralf.Ackermann@KOM.tu-darmstadt.de Thu Aug 12 19:01:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Aug 2004 19:01:11 +0100 (BST)
Received: from drum.kom.e-technik.tu-darmstadt.de ([IPv6:::ffff:130.83.139.190]:22190
	"EHLO mailserver.KOM.e-technik.tu-darmstadt.de") by linux-mips.org
	with ESMTP id <S8225216AbUHLSBH>; Thu, 12 Aug 2004 19:01:07 +0100
Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id UAA29716; Thu, 12 Aug 2004 20:00:47 +0200 (MEST)
Date: Thu, 12 Aug 2004 20:02:28 +0200 (CEST)
From: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
X-X-Sender: rac@shofar.kom.e-technik.tu-darmstadt.de
To: linuxconsole-dev@lists.sourceforge.net, linux-mips@linux-mips.org
cc: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
Subject: Q: problems with missing /dev/tty0 on X startup in MIPS system
Message-ID: <Pine.LNX.4.58.0408121954270.14123@shofar.kom.e-technik.tu-darmstadt.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Ralf.Ackermann@KOM.tu-darmstadt.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: 5633
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rac@KOM.tu-darmstadt.de
Precedence: bulk
X-list: linux-mips

Hello,

I'm trying to get VGA output on a MIPSel system (MeshCube 
http://www.meshcube.org) to work. 
The system uses a miniPCI ATI Rage VGA card (=> problem does not get 
initialized due to lack of system BIOS => hopefully initialized by int10 
XFree86 x86 emulator code).

I've attached an USB mouse and keyboard but fail to start X due to

Fatal server error:
xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)

My questions to those working with MIPS boards / on the Ruby/Linux console 
project are:
 - 1. How to test the USB input functionality?
	(I could test the mouse by doing: cat < /dev/input/mice
	=> any hints on doing something similar for the keyboard?)
 - 2. Any hints on the missing /dev/tty0 stuff? (this is maybe
	related to the console / keyboard stuff?)

Any hints are welcome, best regards
 Ralf

---------------------------------------------------------------
Dr. Ralf Ackermann            _         rac@KOM.tu-darmstadt.de
Multimedia Communications |/ | | |\/|           Merckstrasse 25
                          |\ |_| |  |  64283 Darmstadt, Germany
Tel.: (+49) 6151 16-6138                Fax: (+49) 6151 16-6152
---------------------------------------------------------------
             http://www.kom.tu-darmstadt.de/~rac
---------------------------------------------------------------

From geert@linux-m68k.org Thu Aug 12 20:05:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Aug 2004 20:05:07 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:20181 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225212AbUHLTFC>;
	Thu, 12 Aug 2004 20:05:02 +0100
Received: from waterleaf.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i7CJ4wn1017863;
	Thu, 12 Aug 2004 21:04:58 +0200 (MEST)
Date: Thu, 12 Aug 2004 21:04:58 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
cc: linuxconsole-dev@lists.sourceforge.net,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Q: problems with missing /dev/tty0 on X startup in MIPS system
In-Reply-To: <Pine.LNX.4.58.0408121954270.14123@shofar.kom.e-technik.tu-darmstadt.de>
Message-ID: <Pine.GSO.4.58.0408122101460.18214@waterleaf.sonytel.be>
References: <Pine.LNX.4.58.0408121954270.14123@shofar.kom.e-technik.tu-darmstadt.de>
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: 5634
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Thu, 12 Aug 2004, Ralf Ackermann wrote:
> I'm trying to get VGA output on a MIPSel system (MeshCube
> http://www.meshcube.org) to work.
> The system uses a miniPCI ATI Rage VGA card (=> problem does not get
> initialized due to lack of system BIOS => hopefully initialized by int10
> XFree86 x86 emulator code).

So virtual consoles are not working.

> I've attached an USB mouse and keyboard but fail to start X due to
>
> Fatal server error:
> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)

>  - 2. Any hints on the missing /dev/tty0 stuff? (this is maybe
> 	related to the console / keyboard stuff?)

Yep, that's the current virtual console. Do you have CONFIG_VT enabled? If yes,
probably the VC initialization failed due to vgacon failing. In that case, you
can try enabling dummycon (and hope X can wake up your graphics card).

BTW, there exists (depending on your kernel version) code in atyfb to
initialize the RAGE XL.

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 svetljo@gmx.de Thu Aug 12 20:11:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Aug 2004 20:11:43 +0100 (BST)
Received: from mail.gmx.net ([IPv6:::ffff:213.165.64.20]:39616 "HELO
	mail.gmx.net") by linux-mips.org with SMTP id <S8224933AbUHLTLj>;
	Thu, 12 Aug 2004 20:11:39 +0100
Received: (qmail 21046 invoked by uid 0); 12 Aug 2004 19:11:33 -0000
Received: from 213.23.33.61 by www3.gmx.net with HTTP;
	Thu, 12 Aug 2004 21:11:33 +0200 (MEST)
Date: Thu, 12 Aug 2004 21:11:33 +0200 (MEST)
From: "Svetoslav Slavtchev" <svetljo@gmx.de>
To: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
Cc: linuxconsole-dev@lists.sourceforge.net, linux-mips@linux-mips.org,
	rac@KOM.tu-darmstadt.de
MIME-Version: 1.0
References: <Pine.LNX.4.58.0408121954270.14123@shofar.kom.e-technik.tu-darmstadt.de>
Subject: Re: Q: problems with missing /dev/tty0 on X startup in MIPS system
X-Priority: 3 (Normal)
X-Authenticated: #20183004
Message-ID: <15387.1092337893@www3.gmx.net>
X-Mailer: WWW-Mail 1.6 (Global Message Exchange)
X-Flags: 0001
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-Path: <svetljo@gmx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5635
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: svetljo@gmx.de
Precedence: bulk
X-list: linux-mips

> Hello,
> 
> I'm trying to get VGA output on a MIPSel system (MeshCube 
> http://www.meshcube.org) to work. 
> The system uses a miniPCI ATI Rage VGA card (=> problem does not get 
> initialized due to lack of system BIOS => hopefully initialized by int10 
> XFree86 x86 emulator code).
> 
> I've attached an USB mouse and keyboard but fail to start X due to
> 
> Fatal server error:
> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
> 
> My questions to those working with MIPS boards / on the Ruby/Linux console
> project are:
>  - 1. How to test the USB input functionality?
> 	(I could test the mouse by doing: cat < /dev/input/mice
> 	=> any hints on doing something similar for the keyboard?)

not a guru here, but i hope this will help you
-----------------------
modprobe evdev
cat /proc/bus/input/devices
: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
H: Handlers=kbd event0
B: EV=120003
B: KEY=4 2000000 2b803878 f840d001 f2ffffdf ffefffff ffffffff fffffffe
B: LED=7
<snip>
cat /dev/input/event0
------
should give you some characters on typing to
the corresponding keyboard

>  - 2. Any hints on the missing /dev/tty0 stuff? (this is maybe
> 	related to the console / keyboard stuff?)
> 
> Any hints are welcome, best regards
>  Ralf

best,

svetljo

-- 
NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler!
GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl


From brederlo@informatik.uni-tuebingen.de Thu Aug 12 21:07:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Aug 2004 21:07:08 +0100 (BST)
Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:25027
	"EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP
	id <S8225216AbUHLUHE>; Thu, 12 Aug 2004 21:07:04 +0100
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 1CE3B117; Thu, 12 Aug 2004 22:06:58 +0200 (MST)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
 by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 34540-01; Thu, 12 Aug 2004 22:06:56 +0200 (DFT)
Received: from dual (semeai.Informatik.Uni-Tuebingen.De [134.2.15.66])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 05D80115; Thu, 12 Aug 2004 22:06:56 +0200 (MST)
Received: from mrvn by dual with local (Exim 4.34)
	id 1BvLqg-0001cO-9O; Thu, 12 Aug 2004 22:06:54 +0200
To: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
Cc: linuxconsole-dev@lists.sourceforge.net, linux-mips@linux-mips.org
Subject: Re: Q: problems with missing /dev/tty0 on X startup in MIPS system
References: <Pine.LNX.4.58.0408121954270.14123@shofar.kom.e-technik.tu-darmstadt.de>
From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Date: Thu, 12 Aug 2004 22:06:53 +0200
In-Reply-To: <Pine.LNX.4.58.0408121954270.14123@shofar.kom.e-technik.tu-darmstadt.de> (Ralf
 Ackermann's message of "Thu, 12 Aug 2004 20:02:28 +0200 (CEST)")
Message-ID: <874qn8m882.fsf@mrvn.homelinux.org>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Return-Path: <brederlo@informatik.uni-tuebingen.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: 5636
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brederlo@informatik.uni-tuebingen.de
Precedence: bulk
X-list: linux-mips

Ralf Ackermann <rac@KOM.tu-darmstadt.de> writes:

> Hello,
>
> I'm trying to get VGA output on a MIPSel system (MeshCube 
> http://www.meshcube.org) to work. 
> The system uses a miniPCI ATI Rage VGA card (=> problem does not get 
> initialized due to lack of system BIOS => hopefully initialized by int10 
> XFree86 x86 emulator code).
>
> I've attached an USB mouse and keyboard but fail to start X due to
>
> Fatal server error:
> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)

Didn't you see my mail about MAKEDEV?

MfG
        Goswin

From Ralf.Ackermann@KOM.tu-darmstadt.de Thu Aug 12 23:15:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Aug 2004 23:15:09 +0100 (BST)
Received: from drum.kom.e-technik.tu-darmstadt.de ([IPv6:::ffff:130.83.139.190]:29873
	"EHLO mailserver.KOM.e-technik.tu-darmstadt.de") by linux-mips.org
	with ESMTP id <S8225216AbUHLWPE>; Thu, 12 Aug 2004 23:15:04 +0100
Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id AAA02134; Fri, 13 Aug 2004 00:14:12 +0200 (MEST)
Date: Fri, 13 Aug 2004 00:15:49 +0200 (CEST)
From: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
X-X-Sender: rac@shofar.kom.e-technik.tu-darmstadt.de
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ralf Ackermann <rac@KOM.tu-darmstadt.de>, dev-list@meshcube.org,
	linuxconsole-dev@lists.sourceforge.net,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Q: problems with missing /dev/tty0 on X startup in MIPS system
In-Reply-To: <Pine.GSO.4.58.0408122101460.18214@waterleaf.sonytel.be>
Message-ID: <Pine.LNX.4.58.0408130009070.14554@shofar.kom.e-technik.tu-darmstadt.de>
References: <Pine.LNX.4.58.0408121954270.14123@shofar.kom.e-technik.tu-darmstadt.de>
 <Pine.GSO.4.58.0408122101460.18214@waterleaf.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Ralf.Ackermann@KOM.tu-darmstadt.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: 5637
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rac@KOM.tu-darmstadt.de
Precedence: bulk
X-list: linux-mips

Still unable to get the miniPCI ATI Rage to work with the meshcube.

> Yep, that's the current virtual console. Do you have CONFIG_VT enabled? If yes,
> probably the VC initialization failed due to vgacon failing. In that case, you
> can try enabling dummycon (and hope X can wake up your graphics card).
> 
> BTW, there exists (depending on your kernel version) code in atyfb to
> initialize the RAGE XL.

Hello Geert,

many thanks for your help. With the dummycon and the atyfb code activated 
(I'm using a 2.4.24 kernel) I was able to start the X server.

Unfortunately - neither the fbdev code nor the X startup activates the 
card.
The X startup failed with an "unable to map the card" once and now 
repeatedly fails with:

...
(==) Log file: "/var/log/XFree86.0.log", Time: Fri Aug 13 00:05:26 2004
(==) Using config file: "/etc/X11/XF86Config-4"
(EE) No devices detected.

Fatal server error:
no screens found

I do not see whether any int10 module specific code is executed (the X.log 
file does not indicate any module load activities at all.

Any hints here on the list on how to proceed? I'll probably better try 
to ask the Xfree people now.

best regards
 Ralf

From ppopov@mvista.com Thu Aug 12 23:28:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Aug 2004 23:28:43 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:54258 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225216AbUHLW2i>;
	Thu, 12 Aug 2004 23:28:38 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA07501;
	Thu, 12 Aug 2004 15:28:01 -0700
Message-ID: <411BEEF0.7060107@mvista.com>
Date: Thu, 12 Aug 2004 15:28:00 -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 Ackermann <rac@KOM.tu-darmstadt.de>
CC: Geert Uytterhoeven <geert@linux-m68k.org>, dev-list@meshcube.org,
	linuxconsole-dev@lists.sourceforge.net,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Q: problems with missing /dev/tty0 on X startup in MIPS system
References: <Pine.LNX.4.58.0408121954270.14123@shofar.kom.e-technik.tu-darmstadt.de> <Pine.GSO.4.58.0408122101460.18214@waterleaf.sonytel.be> <Pine.LNX.4.58.0408130009070.14554@shofar.kom.e-technik.tu-darmstadt.de>
In-Reply-To: <Pine.LNX.4.58.0408130009070.14554@shofar.kom.e-technik.tu-darmstadt.de>
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: 5638
X-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


>Unfortunately - neither the fbdev code nor the X startup activates the 
>card.
>The X startup failed with an "unable to map the card" once and now 
>repeatedly fails with:
>  
>

I don't know which ATI Rage card you have exactly, but there is a patch 
for the RageXL (tested on a MIPS board) on 
ftp.linux-mips.org:/pub/linux/mips/people/ppopov/2.4/aty_nobiosinit.patch.

The problem is that at kernel version 2.4.24 or .25, don't remember 
which one, the aty code was restructured and the patch does not apply 
anymore.

Pete

From belracu22@rediffmail.com Fri Aug 13 03:12:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Aug 2004 06:42:16 +0100 (BST)
Received: from webmail27.rediffmail.com ([IPv6:::ffff:203.199.83.37]:21523
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225216AbUHMCMn>; Fri, 13 Aug 2004 03:12:43 +0100
Received: (qmail 10802 invoked by uid 510); 13 Aug 2004 02:12:33 -0000
Date: 13 Aug 2004 02:12:33 -0000
Message-ID: <20040813021233.10801.qmail@webmail27.rediffmail.com>
Received: from unknown (61.30.127.4) by rediffmail.com via HTTP; 13 aug 2004 02:12:33 -0000
MIME-Version: 1.0
From: "bel racu" <belracu22@rediffmail.com>
Reply-To: "bel racu" <belracu22@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: lsmod -- used by ?
Content-type: multipart/alternative;
	boundary="Next_1092363153---0-203.199.83.37-10799"
Return-Path: <belracu22@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5639
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: belracu22@rediffmail.com
Precedence: bulk
X-list: linux-mips

 This is a multipart mime message


--Next_1092363153---0-203.199.83.37-10799
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0A&nbsp; <BR>=0AHello,<BR>=0A<BR>=0Atrying to get framebuffer up on au1=
500 Alchemy db1500 board.<BR>=0Awith cyberpro 5000 chipset PCI graphics car=
d.<BR>=0A<BR>=0AAble to insert the module cyber2000fb withot problem, <BR>=
=0Aand the cards gets registerd ... When issued lsmod i get some thing <BR>=
=0Astrange like this like this <BR>=0A<BR>=0A&nbsp;  #lsmod<BR>=0A&nbsp; &n=
bsp; Module&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Size&nbsp; &nbsp; Used=
 by&nbsp; &nbsp; Tainted: P&nbsp; <BR>=0A&nbsp; &nbsp; cyber2000fb&nbsp; &n=
bsp; &nbsp;  1776&nbsp; &nbsp; 63 <BR>=0A<BR>=0Awhat is does 63 under modul=
e UsedBy meeen ?<BR>=0A<BR>=0ARam=0A</P>=0A<br><br>=0A<A target=3D"_blank" =
HREF=3D"http://clients.rediff.com/signature/track_sig.asp"><IMG SRC=3D"http=
://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbox.ht=
m@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1092363153---0-203.199.83.37-10799
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

  =0AHello,=0A=0Atrying to get framebuffer up on au1500 Alchemy db1500 boar=
d.=0Awith cyberpro 5000 chipset PCI graphics card.=0A=0AAble to insert the =
module cyber2000fb withot problem, =0Aand the cards gets registerd ... When=
 issued lsmod i get some thing =0Astrange like this like this =0A=0A   #lsm=
od=0A    Module            Size    Used by    Tainted: P  =0A    cyber2000f=
b       1776    63 =0A=0Awhat is does 63 under module UsedBy meeen ?=0A=0AR=
am
--Next_1092363153---0-203.199.83.37-10799--


From Ralf.Ackermann@KOM.tu-darmstadt.de Fri Aug 13 07:58:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Aug 2004 07:58:51 +0100 (BST)
Received: from drum.kom.e-technik.tu-darmstadt.de ([IPv6:::ffff:130.83.139.190]:19383
	"EHLO mailserver.KOM.e-technik.tu-darmstadt.de") by linux-mips.org
	with ESMTP id <S8224837AbUHMG6q>; Fri, 13 Aug 2004 07:58:46 +0100
Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id IAA06809; Fri, 13 Aug 2004 08:57:36 +0200 (MEST)
Date: Fri, 13 Aug 2004 08:59:20 +0200 (CEST)
From: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
X-X-Sender: rac@shofar.kom.e-technik.tu-darmstadt.de
To: Michael Stickel <michael.stickel@4g-systems.biz>,
	michael@cubic.org, Pete Popov <ppopov@mvista.com>
cc: linux-mips@linux-mips.org, Ralf Ackermann <rac@KOM.tu-darmstadt.de>
Subject: Q: aty_nobiosinit.patch - to pre 2.4.24 kernel?
Message-ID: <Pine.LNX.4.58.0408130847400.16128@shofar.kom.e-technik.tu-darmstadt.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Ralf.Ackermann@KOM.tu-darmstadt.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: 5640
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rac@KOM.tu-darmstadt.de
Precedence: bulk
X-list: linux-mips

Hello Michael, hello all,

Looks like I need to make a custom (pre 2.4.24) kernel for the MeshCube.

Pete Popov pointed me to the patch - see below (many thanks!!). Have you 
been running pre 2.4.24 kernels on the MeshCube (AFAIK the CVS starts with 
2.4.24 already).

Otherwise - how to proceed for a MIPS or MTX1 specific kernel? Is that
	- starting with the standard kernel source from www.kernel.org
	- applying a patch (where from?) to it (I have only done this
		for ARM systems so far - where this procedure is the
		standard way)

Again - any hints highly welcome
 regards Ralf

PS: I'll finally document all the answers I got within the process in the 
Wiki => so we'll hopefully all profit from it.

----
original message:

I don't know which ATI Rage card you have exactly, but there is a patch 
for the RageXL (tested on a MIPS board) on 
ftp.linux-mips.org:/pub/linux/mips/people/ppopov/2.4/aty_nobiosinit.patch.

The problem is that at kernel version 2.4.24 or .25, don't remember 
which one, the aty code was restructured and the patch does not apply 
anymore.

Pete

From geert@linux-m68k.org Fri Aug 13 09:24:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Aug 2004 09:24:37 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:30672 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224837AbUHMIYc>;
	Fri, 13 Aug 2004 09:24:32 +0100
Received: from waterleaf.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i7D8OAn1013782;
	Fri, 13 Aug 2004 10:24:11 +0200 (MEST)
Date: Fri, 13 Aug 2004 10:24:10 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: bel racu <belracu22@rediffmail.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: lsmod -- used by ?
In-Reply-To: <20040813021233.10801.qmail@webmail27.rediffmail.com>
Message-ID: <Pine.GSO.4.58.0408131023300.28832@waterleaf.sonytel.be>
References: <20040813021233.10801.qmail@webmail27.rediffmail.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: 5641
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Fri, 13 Aug 2004, bel racu wrote:
> trying to get framebuffer up on au1500 Alchemy db1500 board.
> with cyberpro 5000 chipset PCI graphics card.
>
> Able to insert the module cyber2000fb withot problem,
> and the cards gets registerd ... When issued lsmod i get some thing
> strange like this like this
>
>    #lsmod
>     Module            Size    Used by    Tainted: P
>     cyber2000fb       1776    63
>
> what is does 63 under module UsedBy meeen ?

That's the maximum number of virtual consoles configured for the system. Fbcon
increments the use count for each virtual console.

Gr{oetje,eeting}s,

						Geert

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

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

From ralf@linux-mips.org Fri Aug 13 13:24:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Aug 2004 13:24:36 +0100 (BST)
Received: from p508B5CBB.dip.t-dialin.net ([IPv6:::ffff:80.139.92.187]:17273
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225240AbUHMMYc>; Fri, 13 Aug 2004 13:24:32 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7DCOVjS030180;
	Fri, 13 Aug 2004 14:24:31 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7DCOUYs030179;
	Fri, 13 Aug 2004 14:24:30 +0200
Date: Fri, 13 Aug 2004 14:24:30 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Foley, John" <John.Foley@pollak.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Free to a good home . . .
Message-ID: <20040813122430.GB29183@linux-mips.org>
References: <A89802C676E6124D86C0FC7C986B68F08C07C4@boston-exch.pollak.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <A89802C676E6124D86C0FC7C986B68F08C07C4@boston-exch.pollak.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: 5642
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Aug 11, 2004 at 03:26:40PM -0400, Foley, John wrote:

>             I have several NeTpower FastSeries SP (MIPS R4600) workstations,
> in various states of being stripped, that I am looking to donate to the
> Linux cause. These machines are PCI and ISA (or EISA, depending on mobo rev)
> and have DEC Tulip Ethernet and NCR FWSCSI (IIRC.)
> 
>             I'm located in Boston, and am willing to deliver and/or package
> (within reason) in order to see these machines go to promote Linux.

>             Any takers?

Afair these machines are already NetBSD supported and technically relatives
to systems for which Linux support is just suffering from some bitrot.  I
hope that motivates somebody to take the challenge.

  Ralf

From michael.stickel@4g-systems.biz Fri Aug 13 13:34:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Aug 2004 13:34:43 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.191]:45794
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225240AbUHMMej>; Fri, 13 Aug 2004 13:34:39 +0100
Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1BvbGX-000106-00
	for linux-mips@linux-mips.org; Fri, 13 Aug 2004 14:34:37 +0200
Received: from [80.129.146.122] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128)
	(Exim 3.35 #1)
	id 1BvbGW-0004LX-00
	for linux-mips@linux-mips.org; Fri, 13 Aug 2004 14:34:36 +0200
From: Michael Stickel <michael.stickel@4g-systems.biz>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Free to a good home . . .
Date: Fri, 13 Aug 2004 14:34:35 +0200
User-Agent: KMail/1.5.4
References: <A89802C676E6124D86C0FC7C986B68F08C07C4@boston-exch.pollak.com> <20040813122430.GB29183@linux-mips.org>
In-Reply-To: <20040813122430.GB29183@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200408131434.35827.michael.stickel@4g-systems.biz>
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:f72049c8971f462876d14eb8b3ccbbf1
Return-Path: <michael.stickel@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5643
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michael.stickel@4g-systems.biz
Precedence: bulk
X-list: linux-mips


I would like to take one, but I am locatet in Europe, so I assume the shipping 
would kill me.

Michael

On Friday 13 August 2004 14:24, you wrote:
> On Wed, Aug 11, 2004 at 03:26:40PM -0400, Foley, John wrote:
> >             I have several NeTpower FastSeries SP (MIPS R4600)
> > workstations, in various states of being stripped, that I am looking to
> > donate to the Linux cause. These machines are PCI and ISA (or EISA,
> > depending on mobo rev) and have DEC Tulip Ethernet and NCR FWSCSI (IIRC.)


From Ralf.Ackermann@KOM.tu-darmstadt.de Sat Aug 14 10:19:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Aug 2004 10:19:34 +0100 (BST)
Received: from drum.kom.e-technik.tu-darmstadt.de ([IPv6:::ffff:130.83.139.190]:16590
	"EHLO mailserver.KOM.e-technik.tu-darmstadt.de") by linux-mips.org
	with ESMTP id <S8224923AbUHNJT2> convert rfc822-to-8bit; Sat, 14 Aug 2004 10:19:28 +0100
Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id LAA12408; Sat, 14 Aug 2004 11:18:39 +0200 (MEST)
Date: Sat, 14 Aug 2004 11:20:27 +0200 (CEST)
From: Ralf Ackermann <rac@KOM.tu-darmstadt.de>
X-X-Sender: rac@shofar.kom.e-technik.tu-darmstadt.de
To: Michael Stickel <michael.stickel@4g-systems.biz>
cc: Pete Popov <ppopov@mvista.com>, dev-list@meshcube.org,
	linux-mips@linux-mips.org
Subject: MeshCube: ATI Rage VGA progress
Message-ID: <Pine.LNX.4.58.0408141104000.24021@shofar.kom.e-technik.tu-darmstadt.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Return-Path: <Ralf.Ackermann@KOM.tu-darmstadt.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: 5644
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rac@KOM.tu-darmstadt.de
Precedence: bulk
X-list: linux-mips

Hello Michael,

I managed to compile and start a 2.4.22 kernel (with aty... patch 
applied).
=> executes some atyfb specific code (see below)

atyfb: using auxiliary register aperture
atyfb: 3D RAGE (XL pCI-33MHz) [0x4752 rev 0x27] 4M DRAM, 29.498928 MHz 
XTAL, 23K
Console: switching to colour frame buffer device 80x25
fb0: ATY Mach64 frame buffer device on PCI
Dummy keyboard driver installed.
	=> the output varies from either
		- my monitor stating "no signal"
		- to "input not supported"
=> is there any further way to debug this behaviour?

---
Unfortunately the kernel later on reproducibly crashes at

NET4: Linux TCP/IP 1.fos: ICMP, UDP,�CP,�GMP
IP: rhats, CPreinti Pain sockets 1.0/SMP for Linux NET4.0.
Unable to handle kernel paging request at virtual address fffff000,�pc 
== 8028 0
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000

=> We can hopefully solve this by agreeing on a common (proven to work) 
test basis => see below.

------------------------

Can we do a few things to coordinate further work:

1. Are we using the same miniPCI ATI Rage XL? Mine is an Micro Star MS 
9513 and states

[root@meshcube02 /]# lspci -vv
0000:00:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 
27) (prog-if 00 [VGA])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping+ SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (2000ns min)
        Interrupt: pin A routed to IRQ 5
        Region 0: Memory at 40000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: I/O ports at 0300 [size=256]
        Region 2: Memory at 41000000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [5c] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

---
2. Can we please put 
	- a hint on what kernel source to use (e.g. tag for retrieval 
		from mips-linux CVS) and any necessary further
		modifications
	- a .config file for the kernel
on the Wiki?

Looking forward to seeing something on my monitor! :-)

regards
 Ralf

---------------------------------------------------------------
Dr. Ralf Ackermann            _         rac@KOM.tu-darmstadt.de
Multimedia Communications |/ | | |\/|           Merckstrasse 25
                          |\ |_| |  |  64283 Darmstadt, Germany
Tel.: (+49) 6151 16-6138                Fax: (+49) 6151 16-6152
---------------------------------------------------------------
             http://www.kom.tu-darmstadt.de/~rac
---------------------------------------------------------------

From milang@tal.org Mon Aug 16 18:37:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Aug 2004 18:37:09 +0100 (BST)
Received: from gw02.mail.saunalahti.fi ([IPv6:::ffff:195.197.172.116]:9667
	"EHLO gw02.mail.saunalahti.fi") by linux-mips.org with ESMTP
	id <S8224919AbUHPRhE>; Mon, 16 Aug 2004 18:37:04 +0100
Received: from fairytale.tal.org (cruel.tal.org [195.16.220.85])
	by gw02.mail.saunalahti.fi (Postfix) with ESMTP id A1BF4177E1
	for <linux-mips@linux-mips.org>; Mon, 16 Aug 2004 20:37:01 +0300 (EEST)
Received: from amos (unknown [195.16.220.84])
	by fairytale.tal.org (Postfix) with SMTP id 2C30B8DB0
	for <linux-mips@linux-mips.org>; Mon, 16 Aug 2004 20:45:33 +0300 (EEST)
Message-ID: <001401c483b8$51d289f0$54dc10c3@amos>
From: "Kaj-Michael Lang" <milang@tal.org>
To: <linux-mips@linux-mips.org>
Subject: O2 arcboot 32-bit kernel boot fix
Date: Mon, 16 Aug 2004 20:41:40 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Return-Path: <milang@tal.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: 5645
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: milang@tal.org
Precedence: bulk
X-list: linux-mips

Hi

Played with arcboot today and fixed (for me atleast) loading of 32-bit
kernels.
I've also added a very simple progress thing so you know something is
happening when
the kernel is loaded.
Anyway, the patch can be found here:
http://fairytale.tal.org/pub/talinux/patches/arcboot-O2boot-and-progress.patch

The fix was quite simple, arcboot was loading the kernel over itself, the
 -	.base     = 0x80004000,
+	.base     = 0x80002000,

change is the actual fix. 64-bit kernels loads fine after the fix.

There is some extra stuff (a patch from gentoo, removal debuging from e2fs
lib, etc) too..

-- 
Kaj-Michael Lang , milang@tal.org


From milang@tal.org Mon Aug 16 18:43:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Aug 2004 18:43:32 +0100 (BST)
Received: from gw02.mail.saunalahti.fi ([IPv6:::ffff:195.197.172.116]:48580
	"EHLO gw02.mail.saunalahti.fi") by linux-mips.org with ESMTP
	id <S8224938AbUHPRn1>; Mon, 16 Aug 2004 18:43:27 +0100
Received: from fairytale.tal.org (cruel.tal.org [195.16.220.85])
	by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 5CE29177E8
	for <linux-mips@linux-mips.org>; Mon, 16 Aug 2004 20:43:26 +0300 (EEST)
Received: from amos (unknown [195.16.220.84])
	by fairytale.tal.org (Postfix) with SMTP id 6AF428DB0
	for <linux-mips@linux-mips.org>; Mon, 16 Aug 2004 20:51:57 +0300 (EEST)
Message-ID: <001501c483b9$36dc6b60$54dc10c3@amos>
From: "Kaj-Michael Lang" <milang@tal.org>
To: <linux-mips@linux-mips.org>
Subject: O2 framebuffer and mmap..
Date: Mon, 16 Aug 2004 20:48:16 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Return-Path: <milang@tal.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: 5646
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: milang@tal.org
Precedence: bulk
X-list: linux-mips

Hi

The O2 fb driver (or something else) has broken mmap interface, you probably
know that. Anyway, I've tried to find the cause for it but I've haven't been
that succesfull.

I've patched a current cvs kernel with the old O2-fb
driver (from: http://www.linux-mips.org/~glaurung/)(before gbefb
merge/rename)
and mmap does not work with the old driver, so something else seem to
have changed so that the mmap things don't work. The 2.6.1 kernel on the
above page
does have a functional mmap (my test app and X works with it) but it's very
old..

Does anyone have any hints or ideas ?

Oh, and I've added some sysfs stuff to the gbefb driver, should I post the
changes here ?

-- 
Kaj-Michael Lang , milang@tal.org


From mrv@tusur.ru Tue Aug 17 02:58:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 02:58:32 +0100 (BST)
Received: from mx1.tusur.ru ([IPv6:::ffff:212.192.163.19]:14596 "EHLO tusur.ru")
	by linux-mips.org with ESMTP id <S8224865AbUHQB61>;
	Tue, 17 Aug 2004 02:58:27 +0100
Received: from localhost (localhost.tusur.ru [127.0.0.1])
	by tusur.ru (Postfix) with SMTP id A0860B72F1
	for <linux-mips@linux-mips.org>; Tue, 17 Aug 2004 08:53:50 +0700 (TSD)
X-AV-Checked: Tue Aug 17 08:53:50 2004 Ok
Received: from roman (unknown [211.189.34.20])
	by tusur.ru (Postfix) with ESMTP id 5E98BB4BAA
	for <linux-mips@linux-mips.org>; Tue, 17 Aug 2004 08:53:37 +0700 (TSD)
Message-ID: <001601c483fd$9e3ae180$1422bdd3@roman>
From: "Roman Mashak" <mrv@tusur.ru>
To: <linux-mips@linux-mips.org>
Subject: Yamon compiling and linking
Date: Tue, 17 Aug 2004 10:57:50 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1081
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081
FL-Build: Fidolook 2002 (SL) 6.0.2800.85 - 28/1/2003 19:07:30
X-Spam-DCC: : 
Return-Path: <mrv@tusur.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: 5647
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mrv@tusur.ru
Precedence: bulk
X-list: linux-mips

Hello!

I solved the problem with Yamon compiling I asked recently, but still have
technical related questions about Yamon linking & code allocating in memory.

Here it is.

When I compile little-endian only image, as far as I understood, I got image
without RESET code at the beginning, so according to the memory map and link
script (link_el.xn) - starting entry point is __RESET_HANDLER_END (locating
in init.S) and its address is 0x9fc10000.
So, I don't quite understand, how will be going after CPU reset? As
documentation's saying "following a reset, hardware fetches instructions
starting at the reset exception vector 0xBFC00000". But what is waiting at
this address, because reset code (reset.S) is not compiled and is not
linked?

Could you please make it clear to me?

Thanks in advance!

With best regards, Roman Mashak.  E-mail: mrv@tusur.ru


From milang@tal.org Tue Aug 17 07:52:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 07:52:14 +0100 (BST)
Received: from gw01.mail.saunalahti.fi ([IPv6:::ffff:195.197.172.115]:5796
	"EHLO gw01.mail.saunalahti.fi") by linux-mips.org with ESMTP
	id <S8224915AbUHQGwK>; Tue, 17 Aug 2004 07:52:10 +0100
Received: from fairytale.tal.org (cruel.tal.org [195.16.220.85])
	by gw01.mail.saunalahti.fi (Postfix) with ESMTP id F29374C9F8
	for <linux-mips@linux-mips.org>; Tue, 17 Aug 2004 09:52:07 +0300 (EEST)
Received: from amos (unknown [195.16.220.84])
	by fairytale.tal.org (Postfix) with SMTP id A41878DB0
	for <linux-mips@linux-mips.org>; Tue, 17 Aug 2004 10:00:40 +0300 (EEST)
Message-ID: <001901c48427$6272acd0$54dc10c3@amos>
From: "Kaj-Michael Lang" <milang@tal.org>
To: "linux-mips" <linux-mips@linux-mips.org>
Subject: cpu_has_llsc cleanup broke compilation.
Date: Tue, 17 Aug 2004 09:56:53 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Return-Path: <milang@tal.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: 5648
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: milang@tal.org
Precedence: bulk
X-list: linux-mips

The "using cpu_has_llsc cleanup all users of ll/sc and lld/scd." broke
compilation:

  CC      arch/mips/kernel/offset.s
In file included from include/asm/bitops.h:35,
                 from include/linux/bitops.h:4,
                 from include/linux/thread_info.h:20,
                 from include/linux/spinlock.h:12,
                 from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/mips/kernel/offset.c:14:
include/asm/system.h: In function `__xchg_u32':
include/asm/system.h:285: error: `cpu_data' undeclared (first use in this
function)
include/asm/system.h:285: error: (Each undeclared identifier is reported
only once
include/asm/system.h:285: error: for each function it appears in.)
include/asm/system.h:285: error: `MIPS_CPU_LLSC' undeclared (first use in
this function)
include/asm/system.h: In function `__cmpxchg_u32':
include/asm/system.h:382: error: `cpu_data' undeclared (first use in this
function)
include/asm/system.h:382: error: `MIPS_CPU_LLSC' undeclared (first use in
this function)
In file included from include/linux/bitops.h:4,
                 from include/linux/thread_info.h:20,
                 from include/linux/spinlock.h:12,
                 from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/mips/kernel/offset.c:14:
include/asm/bitops.h: In function `set_bit':
include/asm/bitops.h:72: error: `cpu_data' undeclared (first use in this
function)
include/asm/bitops.h:72: error: `MIPS_CPU_LLSC' undeclared (first use in
this function)
include/asm/bitops.h: In function `clear_bit':
include/asm/bitops.h:124: error: `cpu_data' undeclared (first use in this
function)
include/asm/bitops.h:124: error: `MIPS_CPU_LLSC' undeclared (first use in
this function)
include/asm/bitops.h: In function `change_bit':
include/asm/bitops.h:172: error: `cpu_data' undeclared (first use in this
function)
include/asm/bitops.h:172: error: `MIPS_CPU_LLSC' undeclared (first use in
this function)
include/asm/bitops.h: In function `test_and_set_bit':
include/asm/bitops.h:223: error: `cpu_data' undeclared (first use in this
function)
include/asm/bitops.h:223: error: `MIPS_CPU_LLSC' undeclared (first use in
this function)
include/asm/bitops.h: In function `test_and_clear_bit':
include/asm/bitops.h:295: error: `cpu_data' undeclared (first use in this
function)
include/asm/bitops.h:295: error: `MIPS_CPU_LLSC' undeclared (first use in
this function)
include/asm/bitops.h: In function `test_and_change_bit':
include/asm/bitops.h:368: error: `cpu_data' undeclared (first use in this
function)
include/asm/bitops.h:368: error: `MIPS_CPU_LLSC' undeclared (first use in
this function)
In file included from include/asm/thread_info.h:16,
                 from include/linux/thread_info.h:21,
                 from include/linux/spinlock.h:12,
                 from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/mips/kernel/offset.c:14:
include/asm/processor.h: At top level:
include/asm/processor.h:82: error: `cpu_data' used prior to declaration
make[1]: *** [arch/mips/kernel/offset.s] Error 1
make: *** [arch/mips/kernel/offset.s] Error 2
-- 
Kaj-Michael Lang , milang@tal.org


From marcus.gustafsson@kreatel.se Tue Aug 17 08:24:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 08:24:57 +0100 (BST)
Received: from www.kreatel.se ([IPv6:::ffff:212.214.69.146]:12539 "EHLO
	berntsson.kreatel.se") by linux-mips.org with ESMTP
	id <S8224916AbUHQHYw>; Tue, 17 Aug 2004 08:24:52 +0100
Received: by BERNTSSON with Internet Mail Service (5.5.2653.19)
	id <QFY123YN>; Tue, 17 Aug 2004 09:24:50 +0200
Message-ID: <5BB336130A66D7119DEF009027463C2C0F2CDA@BERNTSSON>
From: Marcus Gustafsson <marcus.gustafsson@kreatel.se>
To: linux-mips@linux-mips.org
Subject: RE: Busybox v0.60.2 insmod gives segmentation fault without any m
	essages when trying to load a loadable module
Date: Tue, 17 Aug 2004 09:24:49 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Return-Path: <marcus.gustafsson@kreatel.se>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5649
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: marcus.gustafsson@kreatel.se
Precedence: bulk
X-list: linux-mips


> Manish Lohani wrote:
> > I have a driver loadable module which i am compiling with 
> the same gcc
> > flags as used to compile a kernel for a MIPS R5432 based NEC board.
> > 
> > On the development machine, to compile files driver1.c and 
> driver2.c:
> > $ mips_fp_le-gcc -fomit-frame-pointer -fno-strict-aliasing -G 0
> > -mno-abicalls -fno-pic -pipe -mtune=r5000 -mlong-calls 
> -mips2 -Wall -c
> > driver1.c
> > 
> > $mips_fp_le-ld -r -o driver --printmap --cref driver1.o driver2.o
> > 
> > mips_fp_le-gcc (GCC) version 3.3.1
> > mips_fp_le-ld (GNU ld) version 2.14
> > 
> > I have Busybox v0.60.2 on the target.
> > 
> > On the target:
> > # insmod ./driver
> > Using driver
> > Segmentation fault
> > #
> > 
> > Does anybody have any suggestions as to what could be wrong?
> > 
> 
> BusyBox0.60.x's insmod does not work with gcc-3.3 and above.
> 
> I use a patched version of the real insmod:
> 
> # insmod --version
> insmod version 2.4.25
> 
> I forget where I put the patch, but the insmod author told me that the
> patches were in a later version.  So if I were you, I would 
> use version
> 2.4.26 or higher.
> 
> David Daney.

Im using gcc-3.3.3 and busybox-0.60.5 and insmod works if I strip the debug
symbols from the module.

/Marcus Gustafsson

From ralf@linux-mips.org Tue Aug 17 08:43:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 08:43:14 +0100 (BST)
Received: from p508B75A1.dip.t-dialin.net ([IPv6:::ffff:80.139.117.161]:50244
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224916AbUHQHnK>; Tue, 17 Aug 2004 08:43:10 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7H7h8Uv022767;
	Tue, 17 Aug 2004 09:43:08 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7H7h7d1022748;
	Tue, 17 Aug 2004 09:43:07 +0200
Date: Tue, 17 Aug 2004 09:43:07 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Kaj-Michael Lang <milang@tal.org>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: cpu_has_llsc cleanup broke compilation.
Message-ID: <20040817074307.GA21407@linux-mips.org>
References: <001901c48427$6272acd0$54dc10c3@amos>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001901c48427$6272acd0$54dc10c3@amos>
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: 5650
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Aug 17, 2004 at 09:56:53AM +0300, Kaj-Michael Lang wrote:

> The "using cpu_has_llsc cleanup all users of ll/sc and lld/scd." broke
> compilation:
> 
>   CC      arch/mips/kernel/offset.s
> In file included from include/asm/bitops.h:35,
>                  from include/linux/bitops.h:4,

Clearly a kernel bug - but one that also shows poor maintenance of your
target.  It should define cpu_has_llsc which it doesn't, so the kernel
will use generic code and deciede at runtime it should use ll/sc.  I'm
fixing this problem but you really should fix your target also.

  Ralf

From milang@tal.org Tue Aug 17 09:41:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 09:41:43 +0100 (BST)
Received: from gw01.mail.saunalahti.fi ([IPv6:::ffff:195.197.172.115]:47034
	"EHLO gw01.mail.saunalahti.fi") by linux-mips.org with ESMTP
	id <S8224916AbUHQIlj>; Tue, 17 Aug 2004 09:41:39 +0100
Received: from fairytale.tal.org (cruel.tal.org [195.16.220.85])
	by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 4931D4C959;
	Tue, 17 Aug 2004 11:41:38 +0300 (EEST)
Received: from amos (unknown [195.16.220.84])
	by fairytale.tal.org (Postfix) with SMTP
	id 9CCAF8DB0; Tue, 17 Aug 2004 11:50:13 +0300 (EEST)
Message-ID: <001301c48436$b06c6250$54dc10c3@amos>
From: "Kaj-Michael Lang" <milang@tal.org>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: "linux-mips" <linux-mips@linux-mips.org>
References: <001901c48427$6272acd0$54dc10c3@amos> <20040817074307.GA21407@linux-mips.org>
Subject: Re: cpu_has_llsc cleanup broke compilation.
Date: Tue, 17 Aug 2004 11:46:28 +0300
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Return-Path: <milang@tal.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: 5651
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: milang@tal.org
Precedence: bulk
X-list: linux-mips

> Clearly a kernel bug - but one that also shows poor maintenance of your
> target.  It should define cpu_has_llsc which it doesn't, so the kernel

It's IP32

> will use generic code and deciede at runtime it should use ll/sc.  I'm
> fixing this problem but you really should fix your target also.

If I knew what to do.. but I don't.. but trying to learn..

-- 
Kaj-Michael Lang , milang@tal.org

From chris@mips.com Tue Aug 17 11:46:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 11:46:22 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:59659 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224950AbUHQKqS>;
	Tue, 17 Aug 2004 11:46:18 +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 1Bx1el-00027L-00; Tue, 17 Aug 2004 11:57:31 +0100
Received: from holborn.mips.com ([192.168.192.237] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1Bx1TT-0000jw-00; Tue, 17 Aug 2004 11:45:51 +0100
Message-ID: <4121E1DF.9020801@mips.com>
Date: Tue, 17 Aug 2004 11:45:51 +0100
From: Chris Dearman <chris@mips.com>
Organization: MIPS Technologies (UK)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Roman Mashak <mrv@tusur.ru>
CC: linux-mips@linux-mips.org
Subject: Re: Yamon compiling and linking
References: <001601c483fd$9e3ae180$1422bdd3@roman>
In-Reply-To: <001601c483fd$9e3ae180$1422bdd3@roman>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-3.912, required 4, AWL,
	BAYES_00, USER_AGENT_MOZILLA_UA)
Return-Path: <chris@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5652
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chris@mips.com
Precedence: bulk
X-list: linux-mips

Roman Mashak wrote:
> When I compile little-endian only image, as far as I understood, I got image
> without RESET code at the beginning, so according to the memory map and link
> script (link_el.xn) - starting entry point is __RESET_HANDLER_END (locating
> in init.S) and its address is 0x9fc10000.
> So, I don't quite understand, how will be going after CPU reset? As
> documentation's saying "following a reset, hardware fetches instructions
> starting at the reset exception vector 0xBFC00000". But what is waiting at
> this address, because reset code (reset.S) is not compiled and is not
> linked?

   I think you are using modified YAMON sources... I can tell you how 
the build process works for the distributed version of YAMON:

   Invoking make in the  yamon/bin directory build two YAMON images (one 
big-endian & one little-endian) in the EB & EL subdirectories.  In 
addition some endianess independent reset code (reset.o) is built in 
yamon/bin. These three images are combined together to make a single 
yamon-02.xx.rec image that can run in either endianess.

   If you're only interested in running little-endian you should be able 
to simply combine the reset-02.xx.rec and EL/yamon-02.xx_el.rec images.

	Chris

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

From tbm@cyrius.com Tue Aug 17 15:56:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 15:56:24 +0100 (BST)
Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:25356 "EHLO
	sorrow.cyrius.com") by linux-mips.org with ESMTP
	id <S8225201AbUHQO4H>; Tue, 17 Aug 2004 15:56:07 +0100
Received: by sorrow.cyrius.com (Postfix, from userid 10)
	id 35E8264D40; Tue, 17 Aug 2004 14:56:01 +0000 (UTC)
Received: by deprecation.cyrius.com (Postfix, from userid 1000)
	id 58F1AFECE; Tue, 17 Aug 2004 15:55:50 +0100 (BST)
Date: Tue, 17 Aug 2004 15:55:50 +0100
From: Martin Michlmayr <tbm@cyrius.com>
To: Kaj-Michael Lang <milang@tal.org>
Cc: linux-mips@linux-mips.org
Subject: Re: O2 arcboot 32-bit kernel boot fix
Message-ID: <20040817145550.GB32393@deprecation.cyrius.com>
References: <001401c483b8$51d289f0$54dc10c3@amos>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001401c483b8$51d289f0$54dc10c3@amos>
User-Agent: Mutt/1.5.6+20040803i
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: 5653
X-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

* Kaj-Michael Lang <milang@tal.org> [2004-08-16 20:41]:
> Played with arcboot today and fixed (for me atleast) loading of 32-bit
> kernels.
...
> http://fairytale.tal.org/pub/talinux/patches/arcboot-O2boot-and-progress.patch
> The fix was quite simple, arcboot was loading the kernel over itself, the

It has previously been suggested that the kernel needs to be patched
but your patch is against arcboot.  Who has to change?
-- 
Martin Michlmayr
tbm@cyrius.com

From ralf@linux-mips.org Tue Aug 17 17:01:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 17:01:19 +0100 (BST)
Received: from p508B75A1.dip.t-dialin.net ([IPv6:::ffff:80.139.117.161]:51274
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225201AbUHQQBP>; Tue, 17 Aug 2004 17:01:15 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7HG1D1M000334;
	Tue, 17 Aug 2004 18:01:13 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7HG1AoF000331;
	Tue, 17 Aug 2004 18:01:10 +0200
Date: Tue, 17 Aug 2004 18:01:10 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Branch bug in gas on MIPS
Message-ID: <20040817160110.GA32594@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: 5654
X-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

Below little test case demonstrates a gas bug that results in swapping
of the two branch instructions and use of bogus destination addresses
for the first of the two branches.

[ralf@lappi tmp]$ cat s.s
1:      beqzl   $2, 1b
        beq     $4, $5, 1b
[ralf@lappi tmp]$ mips-linux-as -mips2 -o s.o s.s
[ralf@lappi tmp]$ mips-linux-objdump -d s.o
 
s.o:     file format elf32-tradbigmips
 
Disassembly of section .text:
 
00000000 <.text>:
   0:   1085ffff        beq     a0,a1,0x0
   4:   00000000        nop
   8:   50400000        beqzl   v0,0xc
   c:   00000000        nop

Have a nice day ;-)

  Ralf

From Saugata.Chatterjee@taec.toshiba.com Tue Aug 17 17:57:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 17:57:09 +0100 (BST)
Received: from mailhost.taec.toshiba.com ([IPv6:::ffff:209.243.128.33]:51370
	"EHLO mailhost.taec.toshiba.com") by linux-mips.org with ESMTP
	id <S8225201AbUHQQ5F>; Tue, 17 Aug 2004 17:57:05 +0100
Received: from hdqmta.taec.com (hdqmta.taec.com [209.243.180.59])
	by mailhost.taec.toshiba.com (8.12.7/8.12.7) with ESMTP id i7HGuwMC006397;
	Tue, 17 Aug 2004 09:56:59 -0700 (PDT)
Subject: Re: Yamon compiling and linking
To: "Roman Mashak" <mrv@tusur.ru>
Cc: linux-mips@linux-mips.org
X-Mailer: Lotus Notes Release 5.0.10  March 22, 2002
Message-ID: <OFBBD37EA1.A7922B89-ON88256EF3.005D0F89-88256EF3.005D49DB@taec.com>
From: Saugata.Chatterjee@taec.toshiba.com
Date: Tue, 17 Aug 2004 09:58:57 -0700
X-MIMETrack: Serialize by Router on HDQMTA/TOSHIBA_TAEC(Release 6.5|September 26, 2003) at
 08/17/2004 09:59:08 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Return-Path: <Saugata.Chatterjee@taec.toshiba.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5655
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Saugata.Chatterjee@taec.toshiba.com
Precedence: bulk
X-list: linux-mips






Reset code (reset.S) IS compiled and linked (at bfc00000 like it should
be), and pretty early on in there YAMON detects endianness and jumps to the
location of the appropriate endian image. Dump the output of make to a log
file and look for the compilation of reset.S.

 Hope that helps,
-Saugata.




                                                                                                                                           
                      "Roman Mashak"                                                                                                       
                      <mrv@tusur.ru>               To:       <linux-mips@linux-mips.org>                                                   
                      Sent by:                     cc:                                                                                     
                      linux-mips-bounce@lin        Subject:  Yamon compiling and linking                                                   
                      ux-mips.org                                                                                                          
                                                                                                                                           
                                                                                                                                           
                      08/16/2004 06:57 PM                                                                                                  
                                                                                                                                           
                                                                                                                                           




Hello!

I solved the problem with Yamon compiling I asked recently, but still have
technical related questions about Yamon linking & code allocating in
memory.

Here it is.

When I compile little-endian only image, as far as I understood, I got
image
without RESET code at the beginning, so according to the memory map and
link
script (link_el.xn) - starting entry point is __RESET_HANDLER_END (locating
in init.S) and its address is 0x9fc10000.
So, I don't quite understand, how will be going after CPU reset? As
documentation's saying "following a reset, hardware fetches instructions
starting at the reset exception vector 0xBFC00000". But what is waiting at
this address, because reset code (reset.S) is not compiled and is not
linked?

Could you please make it clear to me?

Thanks in advance!

With best regards, Roman Mashak.  E-mail: mrv@tusur.ru






From ralf@linux-mips.org Tue Aug 17 19:08:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 19:08:13 +0100 (BST)
Received: from p508B75A1.dip.t-dialin.net ([IPv6:::ffff:80.139.117.161]:24908
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225201AbUHQSIJ>; Tue, 17 Aug 2004 19:08:09 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7HI864L014923;
	Tue, 17 Aug 2004 20:08:06 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7HI86Un014920;
	Tue, 17 Aug 2004 20:08:06 +0200
Date: Tue, 17 Aug 2004 20:08:06 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Marcus Gustafsson <marcus.gustafsson@kreatel.se>
Cc: linux-mips@linux-mips.org
Subject: Re: Busybox v0.60.2 insmod gives segmentation fault without any m essages when trying to load a loadable module
Message-ID: <20040817180806.GA14578@linux-mips.org>
References: <5BB336130A66D7119DEF009027463C2C0F2CDA@BERNTSSON>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5BB336130A66D7119DEF009027463C2C0F2CDA@BERNTSSON>
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: 5656
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Aug 17, 2004 at 09:24:49AM +0200, Marcus Gustafsson wrote:

> Im using gcc-3.3.3 and busybox-0.60.5 and insmod works if I strip the debug
> symbols from the module.

Seems that insmod is derived from an awfully old version from kernel.org;
this bug was fixed years ago.

  Ralf

From aravindforl@yahoo.co.in Tue Aug 17 19:14:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 19:14:18 +0100 (BST)
Received: from web8202.mail.in.yahoo.com ([IPv6:::ffff:203.199.70.115]:15937
	"HELO web8202.mail.in.yahoo.com") by linux-mips.org with SMTP
	id <S8225201AbUHQSON>; Tue, 17 Aug 2004 19:14:13 +0100
Message-ID: <20040817181402.73079.qmail@web8202.mail.in.yahoo.com>
Received: from [202.63.115.3] by web8202.mail.in.yahoo.com via HTTP; Tue, 17 Aug 2004 19:14:02 BST
Date: Tue, 17 Aug 2004 19:14:02 +0100 (BST)
From: =?iso-8859-1?q?Arravind=20babu?= <aravindforl@yahoo.co.in>
Subject: Doubt on rootfs
To: linux-mips@linux-mips.org
Cc: binutils@sources.redhat.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1285638652-1092766442=:71801"
Content-Transfer-Encoding: 8bit
Return-Path: <aravindforl@yahoo.co.in>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5657
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aravindforl@yahoo.co.in
Precedence: bulk
X-list: linux-mips

--0-1285638652-1092766442=:71801
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi all,
 
         I am cross-compiling linux 2.4.20 onto MIPS .I compiled and i booted the system.When i gave the command mount at the prompt it gave the following things.
 
$mount
 
rootfs on / type rootfs (rw)
/dev/rom0 on / type romfs (ro)
/dev/ram0 on /var type ext2 (rw)
/proc on /proc type proc (rw)
/dev/mtdblock6 on /flash type jffs2 (rw)
/dev/ram1 on /upgrade type sramfs (rw)
/dev/mtdblock5 on /apps type cramfs (ro)
devpts on /dev/pts type devpts (rw)

 
When i gave the same command on a normal linux 2.4.20 machine i got the following.
 
$mount
 
/dev/sda1 on / type ext3 (rw)
none on /proc type proc (rw)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda5 on /home type ext3 (rw)
/dev/sdb1 on /home1 type ext3 (rw)
none on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

 
 
Why rootfs is not showing any device like in linux machine( /dev/sda1 on / type ext3)  ?
 I checked the files 
 
usr/src/linux/init/main.c
usr/src/linux/fs/ramfs/inode.c
usr/src/linux/fs/namespace.c
 
But i didnot got the point.Any idea is highly appreciated.My project is stopped due to this.Pls help me regarding this.
 
Thanks in advance,
Aravind.

Yahoo! India Matrimony: Find your life partneronline.
--0-1285638652-1092766442=:71801
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Hi all,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am cross-compiling linux 2.4.20 onto MIPS .I compiled and i booted the system.When i gave the command <STRONG>mount</STRONG> at the prompt it gave the following things.</DIV>
<DIV>&nbsp;</DIV>
<DIV>$mount</DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV><STRONG>rootfs</STRONG> on / type <STRONG>rootfs</STRONG> (rw)<BR>/dev/rom0 on / type romfs (ro)<BR>/dev/ram0 on /var type ext2 (rw)<BR>/proc on /proc type proc (rw)<BR>/dev/mtdblock6 on /flash type jffs2 (rw)<BR>/dev/ram1 on /upgrade type sramfs (rw)<BR>/dev/mtdblock5 on /apps type cramfs (ro)<BR>devpts on /dev/pts type devpts (rw)<BR></DIV>
<DIV>&nbsp;</DIV>
<DIV>When i gave the same command on a <STRONG>normal linux</STRONG> 2.4.20 machine i got the following.</DIV>
<DIV>&nbsp;</DIV>
<DIV>$mount</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG>/dev/sda1</STRONG> on / type <STRONG>ext3</STRONG> (rw)<BR>none on /proc type proc (rw)<BR>usbdevfs on /proc/bus/usb type usbdevfs (rw)<BR>none on /dev/pts type devpts (rw,gid=5,mode=620)<BR>/dev/sda5 on /home type ext3 (rw)<BR>/dev/sdb1 on /home1 type ext3 (rw)<BR>none on /dev/shm type tmpfs (rw)<BR>none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)<BR></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Why rootfs is not showing any device like in linux machine( <STRONG>/dev/sda1</STRONG> on / type <STRONG>ext3)</STRONG>&nbsp; ?</DIV>
<DIV>&nbsp;I checked the files </DIV>
<DIV>&nbsp;</DIV>
<DIV>usr/src/linux/init/main.c</DIV>
<DIV>usr/src/linux/fs/ramfs/inode.c</DIV>
<DIV>usr/src/linux/fs/namespace.c</DIV>
<DIV>&nbsp;</DIV>
<DIV>But i didnot got the point.Any idea is highly appreciated.My project is stopped due to this.Pls help me regarding this.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks in advance,</DIV>
<DIV>Aravind.</DIV><p><font face=arial size=-1>
<a href="http://in.rd.yahoo.com/specials/mailtg/*http://yahoo.shaadi.com/india-matrimony/" target="_blank">
<b>Yahoo! India Matrimony</a>:</b> Find your life partner
<a href="http://in.rd.yahoo.com/specials/mailtg2/*http://yahoo.shaadi.com/india-matrimony/" target="_blank">online</a>.</font>
--0-1285638652-1092766442=:71801--

From ddaney@avtrex.com Tue Aug 17 20:51:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 20:51:34 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:17366 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225209AbUHQTva>;
	Tue, 17 Aug 2004 20:51:30 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 17 Aug 2004 12:48:29 -0700
Message-ID: <41226134.7000401@avtrex.com>
Date: Tue, 17 Aug 2004 12:49:08 -0700
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: Marcus Gustafsson <marcus.gustafsson@kreatel.se>,
	linux-mips@linux-mips.org
Subject: Re: Busybox v0.60.2 insmod gives segmentation fault without any m
 essages when trying to load a loadable module
References: <5BB336130A66D7119DEF009027463C2C0F2CDA@BERNTSSON> <20040817180806.GA14578@linux-mips.org>
In-Reply-To: <20040817180806.GA14578@linux-mips.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Aug 2004 19:48:29.0416 (UTC) FILETIME=[2B441E80:01C48493]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5658
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

Ralf Baechle wrote:
> On Tue, Aug 17, 2004 at 09:24:49AM +0200, Marcus Gustafsson wrote:
> 
> 
>>Im using gcc-3.3.3 and busybox-0.60.5 and insmod works if I strip the debug
>>symbols from the module.
> 
> 
> Seems that insmod is derived from an awfully old version from kernel.org;
> this bug was fixed years ago.
> 

GCC 3.3 introduced several new debugging information sections.  The
ability of insmod to handle these new sections was not added until
around October 2003 (to my best recollection).

David Daney.


From ralf@linux-mips.org Tue Aug 17 23:24:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Aug 2004 23:25:02 +0100 (BST)
Received: from p508B75A1.dip.t-dialin.net ([IPv6:::ffff:80.139.117.161]:21839
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225219AbUHQWY5>; Tue, 17 Aug 2004 23:24:57 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7HMOnkq020891;
	Wed, 18 Aug 2004 00:24:49 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7HMOlN7020890;
	Wed, 18 Aug 2004 00:24:47 +0200
Date: Wed, 18 Aug 2004 00:24:47 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: David Daney <ddaney@avtrex.com>
Cc: Marcus Gustafsson <marcus.gustafsson@kreatel.se>,
	linux-mips@linux-mips.org
Subject: Re: Busybox v0.60.2 insmod gives segmentation fault without any m essages when trying to load a loadable module
Message-ID: <20040817222447.GA17065@linux-mips.org>
References: <5BB336130A66D7119DEF009027463C2C0F2CDA@BERNTSSON> <20040817180806.GA14578@linux-mips.org> <41226134.7000401@avtrex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41226134.7000401@avtrex.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: 5659
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Aug 17, 2004 at 12:49:08PM -0700, David Daney wrote:

> GCC 3.3 introduced several new debugging information sections.  The
> ability of insmod to handle these new sections was not added until
> around October 2003 (to my best recollection).

I know, around '97 I wrote the code that did reject the DWARF sections :-)

  Ralf

From tinglai@gmail.com Wed Aug 18 00:34:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 00:34:57 +0100 (BST)
Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.203]:54655 "EHLO
	mproxy.gmail.com") by linux-mips.org with ESMTP id <S8225219AbUHQXew>;
	Wed, 18 Aug 2004 00:34:52 +0100
Received: by mproxy.gmail.com with SMTP id 74so236638rnk
        for <linux-mips@linux-mips.org>; Tue, 17 Aug 2004 16:34:42 -0700 (PDT)
Received: by 10.38.125.1 with SMTP id x1mr214666rnc;
        Tue, 17 Aug 2004 16:34:41 -0700 (PDT)
Message-ID: <e2eac65704081716345c78b7c6@mail.gmail.com>
Date: Tue, 17 Aug 2004 19:34:41 -0400
From: Tim Lai <tinglai@gmail.com>
Reply-To: Tim Lai <tinglai@gmail.com>
To: linux-mips@linux-mips.org
Subject: problem with prefetch in user space
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <tinglai@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5660
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tinglai@gmail.com
Precedence: bulk
X-list: linux-mips

I am trying to use prefetch in user space. I am using mips_fp_be-gcc
version 3.2.1,
and the kernel is MontaVista 2.4 kernel.

I have a C program with the fellowing function:

inline void mips_prefetch(void *addr)
{
    __asm__ __volatile__(
                         ".set push                  \n"
                         ".set noreorder             \n"
                         ".set noat                  \n"
                         ".set mips4                 \n"

                         "     pref       4 ,  0(%0)  \n"  
              
                         ".set pop                   \n");
    return;
}

When I compile with gcc, 
/tmp/ccMHaOOf.s: Assembler messages:
/tmp/ccMHaOOf.s:5479: Error: illegal operands `pref'
make: *** [foo.o] Error 1

I tried add -mips4 option in gcc, it got even worst, 

/tmp/ccN6Xs81.s: Assembler messages:
/tmp/ccN6Xs81.s:54: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:55: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:128: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:129: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:171: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:223: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:224: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:420: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:421: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:698: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:776: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:801: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:815: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:857: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:858: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:913: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:1308: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:1377: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:1402: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:1424: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:1462: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:1497: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:1498: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:1953: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:1954: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:2023: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2092: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2145: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2275: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2313: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:2314: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:2360: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:2361: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:2395: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:2396: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:2480: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:2481: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:2565: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2575: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2609: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2686: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2692: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2714: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2741: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2745: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2793: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2818: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2824: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2849: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2858: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2883: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:2948: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:2949: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:3036: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:3037: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:3109: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3260: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3388: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3393: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3446: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3458: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3469: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3486: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3543: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3631: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3677: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3695: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3715: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3739: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3805: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3829: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3840: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3858: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3935: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3941: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3963: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3982: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:3994: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4012: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4086: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4101: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4142: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:4143: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:4196: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4210: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4236: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4264: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4285: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4311: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4330: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4386: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:4387: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:4673: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4714: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4882: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:4948: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5014: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5067: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5179: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5282: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5366: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5382: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5441: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5585: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:5586: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:5685: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5690: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5705: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5782: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:5783: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:5808: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5816: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5880: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:5915: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:5916: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:5925: Error: illegal operands `pref'
/tmp/ccN6Xs81.s:5926: Error: illegal operands `pref'
/tmp/ccN6Xs81.s:5927: Error: illegal operands `pref'
/tmp/ccN6Xs81.s:5928: Error: illegal operands `pref'
/tmp/ccN6Xs81.s:5929: Error: illegal operands `pref'
/tmp/ccN6Xs81.s:5930: Error: illegal operands `pref'
/tmp/ccN6Xs81.s:5931: Error: illegal operands `pref'
/tmp/ccN6Xs81.s:5962: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:5963: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:6008: Error: illegal operands `lui'
/tmp/ccN6Xs81.s:6009: Error: illegal operands `addiu'
/tmp/ccN6Xs81.s:6024: Warning: No .cprestore pseudo-op used in PIC code
/tmp/ccN6Xs81.s:6035: Warning: No .cprestore pseudo-op used in PIC code

Can anyone shine some light on this?
Is prefetch not mean for user program at all?
Have anyone got this to work?

Thanks.

Tim Lai

From ranidavuluri@yahoo.com Wed Aug 18 02:04:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 02:05:03 +0100 (BST)
Received: from web50310.mail.yahoo.com ([IPv6:::ffff:206.190.38.243]:23927
	"HELO web50310.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225219AbUHRBE7>; Wed, 18 Aug 2004 02:04:59 +0100
Message-ID: <20040818010451.71068.qmail@web50310.mail.yahoo.com>
Received: from [66.237.41.195] by web50310.mail.yahoo.com via HTTP; Tue, 17 Aug 2004 18:04:51 PDT
Date: Tue, 17 Aug 2004 18:04:51 -0700 (PDT)
From: usha davuluri <ranidavuluri@yahoo.com>
Subject: MIPS Malta board linux problem 
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <ranidavuluri@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: 5661
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ranidavuluri@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,
 I am trying to bring up the Malta board with the
prebuils kernel. I am using TFTP server for that. I am
pretty much sure that TFTP server is up on my host
Redhat linux laptop. Some how I am not able to load
the immage on to the board. Please any one can help me
to solve this problem. 
I tested the tftp with the $:xinetd -d command. The
out put came well( TFTP is running). Following error
messages I am getting when I try to load the linux
kernel using tftp.

load
tftp://192.168.0.115//vmlinux-2.4.3.malta.install.el-01.02.srec
About to load
tftp://192.168.0.115//vmlinux-2.4.3.malta.install.el-01.02.srec
Press Ctrl-C to break
Error : TFTP READ-REQ ERROR
Diag  : Host returned: ErrorCode = 2, ErrorMsg =
Access violation
Hint  : Check TFTP-server: file-existence,
directory/file-attributes
Thank you,
Usha.


		
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

From earlm@mips.com Wed Aug 18 02:19:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 02:19:24 +0100 (BST)
Received: from 209-232-97-206.ded.pacbell.net ([IPv6:::ffff:209.232.97.206]:50834
	"EHLO dns0.mips.com") by linux-mips.org with ESMTP
	id <S8225219AbUHRBTU> convert rfc822-to-8bit; Wed, 18 Aug 2004 02:19:20 +0100
Received: from mercury.mips.com (sbcns-dmz [209.232.97.193])
	by dns0.mips.com (8.12.11/8.12.11) with ESMTP id i7I1J9RI001957;
	Tue, 17 Aug 2004 18:19:09 -0700 (PDT)
Received: from exchange.MIPS.COM (exchange [192.168.20.29])
	by mercury.mips.com (8.12.11/8.12.11) with ESMTP id i7I1JBma012780;
	Tue, 17 Aug 2004 18:19:11 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: MIPS Malta board linux problem 
Date: Tue, 17 Aug 2004 18:19:11 -0700
Message-ID: <3CB54817FDF733459B230DD27C690CEC0E72F6@Exchange.MIPS.COM>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: MIPS Malta board linux problem 
Thread-Index: AcSEv3o+6ckYLAMNTymBmSifKp+6lwAAXqtQ
From: "Mitchell, Earl" <earlm@mips.com>
To: "usha davuluri" <ranidavuluri@yahoo.com>,
	<linux-mips@linux-mips.org>
X-Scanned-By: MIMEDefang 2.39
Return-Path: <earlm@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5662
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlm@mips.com
Precedence: bulk
X-list: linux-mips


I remember while back YAMON would get
"TFTP READ-REQ ERROR" when used with
the RH7.3 TFTP server. I believe this
was fixed in later revs. So if you are
using an old version of YAMON try a
more recent rev. 

-earlm

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of usha davuluri
> Sent: Tuesday, August 17, 2004 6:05 PM
> To: linux-mips@linux-mips.org
> Subject: MIPS Malta board linux problem 
> 
> 
> Hi,
>  I am trying to bring up the Malta board with the
> prebuils kernel. I am using TFTP server for that. I am
> pretty much sure that TFTP server is up on my host
> Redhat linux laptop. Some how I am not able to load
> the immage on to the board. Please any one can help me
> to solve this problem. 
> I tested the tftp with the $:xinetd -d command. The
> out put came well( TFTP is running). Following error
> messages I am getting when I try to load the linux
> kernel using tftp.
> 
> load
> tftp://192.168.0.115//vmlinux-2.4.3.malta.install.el-01.02.srec
> About to load
> tftp://192.168.0.115//vmlinux-2.4.3.malta.install.el-01.02.srec
> Press Ctrl-C to break
> Error : TFTP READ-REQ ERROR
> Diag  : Host returned: ErrorCode = 2, ErrorMsg =
> Access violation
> Hint  : Check TFTP-server: file-existence,
> directory/file-attributes
> Thank you,
> Usha.
> 
> 
> 		
> __________________________________
> Do you Yahoo!?
> Y! Messenger - Communicate in real time. Download now. 
> http://messenger.yahoo.com
> 
> 

From taoyong2002cncq@yahoo.com.cn Wed Aug 18 02:54:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 02:54:30 +0100 (BST)
Received: from smtp110.mail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.8]:63580
	"HELO smtp110.mail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8225219AbUHRByY>; Wed, 18 Aug 2004 02:54:24 +0100
Received: from unknown (HELO ime?ty) (taoyong2002cncq@202.202.6.143 with login)
  by smtp110.mail.sc5.yahoo.com with SMTP; 18 Aug 2004 01:54:19 -0000
Date: Wed, 18 Aug 2004 09:54:45 +0800
From: "taoyong" <taoyong2002cncq@yahoo.com.cn>
Reply-To: taoyong2002cncq@yahoo.com.cn
To: "linux-mips" <linux-mips@linux-mips.org>
Subject: does anyone have the BDI2000 config file for Cognet CSB350?
Organization: cqu-swcims
X-mailer: Foxmail 5.0 beta2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20040818015424Z8225219-1530+8612@linux-mips.org>
Return-Path: <taoyong2002cncq@yahoo.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5663
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: taoyong2002cncq@yahoo.com.cn
Precedence: bulk
X-list: linux-mips

Hi linux-mips,
    
      I use the BDI2000 to prog the flash of CSB350,but failed. I am not sure my configfile is correct or not. So anyone have use the CSB350 and would you  please send me the config file?

BDI>md 0xbfc00000
bfc00000 : 0000b400 00001000 00000000 00000200  ................
bfc00010 : 00000000 00000000 00000000 00000000  ................
bfc00020 : 00000000 00001000 00000000 00000000  ................
bfc00030 : 00000011 00004455 00008899 0000ccdd  ....UD..........
bfc00040 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfc00050 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfc00060 : 00003030 0000333a 00003a35 00003030  00..:3..5:..00..
bfc00070 : 00004500 0000ffff 0000ffff 0000ffff  .E..............
bfc00080 : 00003c09 00004089 00003c09 00003529  .<...@...<..)5..
bfc00090 : 00004089 00004080 00000000 00003c09  .@...@.......<..
bfc000a0 : 00004089 00002408 00002409 0000240a  .@...$...$...$..
bfc000b0 : 00004089 00004200 00000000 0000400b  .@...B.......@..
bfc000c0 : 00003c0c 0000018b 00002529 0000100b  .<......)%......
bfc000d0 : 00000000 00004088 00004080 00004080  .....@...@...@..
bfc000e0 : 00004080 00004200 00002508 0000150a  .@...B...%......
bfc000f0 : 00000000 00004080 00000000 00003c08  .....@.......<..

BDI>md 0xbfd00000
bfd00000 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd00010 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd00020 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd00030 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd00040 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd00050 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd00060 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd00070 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd00080 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd00090 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd000a0 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd000b0 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd000c0 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd000d0 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd000e0 : 0000ffff 0000ffff 0000ffff 0000ffff  ................
bfd000f0 : 0000ffff 0000ffff 0000ffff 0000ffff  ................

 





Best regards,

> Yong Tao 
> Insitute of Manufacture Engineering of Chongqing University,
> Chongqing,
> China 
> 400030
> tel:(+8623)65111224-108
>     (+86)13752931429





From ddaney@avtrex.com Wed Aug 18 05:02:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 05:02:24 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:17275 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8224842AbUHRECT>;
	Wed, 18 Aug 2004 05:02:19 +0100
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Subject: RE: MIPS Malta board linux problem
Date: Tue, 17 Aug 2004 20:59:17 -0700
Message-ID: <69397FFCADEFD94F8D5A0FC0FDBCBBDEF499@avtrex-server.hq.avtrex.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: MIPS Malta board linux problem 
Thread-Index: AcSEvwjAx9L3ac1MQsOavH98LAD1lQAGJx0z
From: "David Daney" <ddaney@avtrex.com>
To: "usha davuluri" <ranidavuluri@yahoo.com>,
	<linux-mips@linux-mips.org>
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5664
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

SXQgaGFzIHRvIGJlIHdvcmxkIHJlYWRhYmxlLiAgT3RoZXJ3aXNlIHRmdHBkIHdpbGwgbm90IHNl
cnZlIGl0IHVwLg0KIA0KRGF2aWQgRGFuZXkuDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LSANCglGcm9tOiBsaW51eC1taXBzLWJvdW5jZUBsaW51eC1taXBzLm9yZyBvbiBiZWhhbGYgb2Yg
dXNoYSBkYXZ1bHVyaSANCglTZW50OiBUdWUgOC8xNy8yMDA0IDY6MDQgUE0gDQoJVG86IGxpbnV4
LW1pcHNAbGludXgtbWlwcy5vcmcgDQoJQ2M6IA0KCVN1YmplY3Q6IE1JUFMgTWFsdGEgYm9hcmQg
bGludXggcHJvYmxlbSANCgkNCgkNCg0KCUhpLA0KCSBJIGFtIHRyeWluZyB0byBicmluZyB1cCB0
aGUgTWFsdGEgYm9hcmQgd2l0aCB0aGUNCglwcmVidWlscyBrZXJuZWwuIEkgYW0gdXNpbmcgVEZU
UCBzZXJ2ZXIgZm9yIHRoYXQuIEkgYW0NCglwcmV0dHkgbXVjaCBzdXJlIHRoYXQgVEZUUCBzZXJ2
ZXIgaXMgdXAgb24gbXkgaG9zdA0KCVJlZGhhdCBsaW51eCBsYXB0b3AuIFNvbWUgaG93IEkgYW0g
bm90IGFibGUgdG8gbG9hZA0KCXRoZSBpbW1hZ2Ugb24gdG8gdGhlIGJvYXJkLiBQbGVhc2UgYW55
IG9uZSBjYW4gaGVscCBtZQ0KCXRvIHNvbHZlIHRoaXMgcHJvYmxlbS4NCglJIHRlc3RlZCB0aGUg
dGZ0cCB3aXRoIHRoZSAkOnhpbmV0ZCAtZCBjb21tYW5kLiBUaGUNCglvdXQgcHV0IGNhbWUgd2Vs
bCggVEZUUCBpcyBydW5uaW5nKS4gRm9sbG93aW5nIGVycm9yDQoJbWVzc2FnZXMgSSBhbSBnZXR0
aW5nIHdoZW4gSSB0cnkgdG8gbG9hZCB0aGUgbGludXgNCglrZXJuZWwgdXNpbmcgdGZ0cC4NCgkN
Cglsb2FkDQoJdGZ0cDovLzE5Mi4xNjguMC4xMTUvL3ZtbGludXgtMi40LjMubWFsdGEuaW5zdGFs
bC5lbC0wMS4wMi5zcmVjDQoJQWJvdXQgdG8gbG9hZA0KCXRmdHA6Ly8xOTIuMTY4LjAuMTE1Ly92
bWxpbnV4LTIuNC4zLm1hbHRhLmluc3RhbGwuZWwtMDEuMDIuc3JlYw0KCVByZXNzIEN0cmwtQyB0
byBicmVhaw0KCUVycm9yIDogVEZUUCBSRUFELVJFUSBFUlJPUg0KCURpYWcgIDogSG9zdCByZXR1
cm5lZDogRXJyb3JDb2RlID0gMiwgRXJyb3JNc2cgPQ0KCUFjY2VzcyB2aW9sYXRpb24NCglIaW50
ICA6IENoZWNrIFRGVFAtc2VydmVyOiBmaWxlLWV4aXN0ZW5jZSwNCglkaXJlY3RvcnkvZmlsZS1h
dHRyaWJ1dGVzDQoJVGhhbmsgeW91LA0KCVVzaGEuDQoJDQoJDQoJICAgICAgICAgICAgICAgDQoJ
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCURvIHlvdSBZYWhvbyE/DQoJWSEg
TWVzc2VuZ2VyIC0gQ29tbXVuaWNhdGUgaW4gcmVhbCB0aW1lLiBEb3dubG9hZCBub3cuDQoJaHR0
cDovL21lc3Nlbmdlci55YWhvby5jb20NCgkNCgkNCg0K

From mrv@tusur.ru Wed Aug 18 06:51:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 06:51:10 +0100 (BST)
Received: from mx1.tusur.ru ([IPv6:::ffff:212.192.163.19]:15885 "EHLO tusur.ru")
	by linux-mips.org with ESMTP id <S8224912AbUHRFvG>;
	Wed, 18 Aug 2004 06:51:06 +0100
Received: from localhost (localhost.tusur.ru [127.0.0.1])
	by tusur.ru (Postfix) with SMTP id E02B4B87B6;
	Wed, 18 Aug 2004 12:46:28 +0700 (TSD)
X-AV-Checked: Wed Aug 18 12:46:28 2004 Ok
Received: from roman (unknown [211.189.34.20])
	by tusur.ru (Postfix) with ESMTP id CCDF0B87A9;
	Wed, 18 Aug 2004 12:46:26 +0700 (TSD)
Message-ID: <002601c484e7$4ea38e70$1422bdd3@roman>
From: "Roman Mashak" <mrv@tusur.ru>
To: "Chris Dearman" <chris@mips.com>, <linux-mips@linux-mips.org>
References: <001601c483fd$9e3ae180$1422bdd3@roman> <4121E1DF.9020801@mips.com>
Subject: Re: Yamon compiling and linking
Date: Wed, 18 Aug 2004 14:50:41 +0900
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.1081
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081
FL-Build: Fidolook 2002 (SL) 6.0.2800.85 - 28/1/2003 19:07:30
X-Spam-DCC: : 
Return-Path: <mrv@tusur.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: 5665
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mrv@tusur.ru
Precedence: bulk
X-list: linux-mips

Hello, Chris!
You wrote to "Roman Mashak" <mrv@tusur.ru> on Tue, 17 Aug 2004 11:45:51
+0100:

 CD>    I think you are using modified YAMON sources... I can tell you how
 CD> the build process works for the distributed version of YAMON:

   Sorry, i didn't mention that  I'm using YAMON source code supplied with
AMD Alchemy  AU1550 dev. board. But I've already sent my questions to AMD
support, and didn't get reply for 3 days, that's why I asked here.
 CD>    Invoking make in the  yamon/bin directory build two YAMON images
 CD> (one big-endian & one little-endian) in the EB & EL subdirectories.  In
    Yes, absolutely correct
 CD> addition some endianess independent reset code (reset.o) is built in
 CD> yamon/bin. These three images are combined together to make a single
 CD> yamon-02.xx.rec image that can run in either endianess.
    In my case - NOT. So, if I invoke 'make srec_el' to build little-endian
only image I get only LE image located in the bin/EL directory and nothing
in the upper directory.
 CD>    If you're only interested in running little-endian you should be
 CD> able to simply combine the reset-02.xx.rec and EL/yamon-02.xx_el.rec
 CD> images.
    So, I have to compile reset code seperately and combine it with LE
according to your device.

With best regards, Roman Mashak.  E-mail: mrv@tusur.ru


From mrv@tusur.ru Wed Aug 18 06:53:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 06:53:53 +0100 (BST)
Received: from mx1.tusur.ru ([IPv6:::ffff:212.192.163.19]:54543 "EHLO tusur.ru")
	by linux-mips.org with ESMTP id <S8224912AbUHRFxt>;
	Wed, 18 Aug 2004 06:53:49 +0100
Received: from localhost (localhost.tusur.ru [127.0.0.1])
	by tusur.ru (Postfix) with SMTP id 81F02B8818;
	Wed, 18 Aug 2004 12:49:14 +0700 (TSD)
X-AV-Checked: Wed Aug 18 12:49:14 2004 Ok
Received: from roman (unknown [211.189.34.20])
	by tusur.ru (Postfix) with ESMTP id 9DB68B853B;
	Wed, 18 Aug 2004 12:49:08 +0700 (TSD)
Message-ID: <002701c484e7$af440980$1422bdd3@roman>
From: "Roman Mashak" <mrv@tusur.ru>
To: <Saugata.Chatterjee@taec.toshiba.com>, <linux-mips@linux-mips.org>
References: <OFBBD37EA1.A7922B89-ON88256EF3.005D0F89-88256EF3.005D49DB@taec.com>
Subject: Re: Yamon compiling and linking
Date: Wed, 18 Aug 2004 14:53:18 +0900
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.1081
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081
FL-Build: Fidolook 2002 (SL) 6.0.2800.85 - 28/1/2003 19:07:30
X-Spam-DCC: : 
Return-Path: <mrv@tusur.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: 5666
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mrv@tusur.ru
Precedence: bulk
X-list: linux-mips

Hello, Saugata.Chatterjee@taec.toshiba.com!
You wrote to "Roman Mashak" <mrv@tusur.ru> on Tue, 17 Aug 2004
09:58:57 -0700:

SC> Reset code (reset.S) IS compiled and linked (at bfc00000 like it should
SC> be), and pretty early on in there YAMON detects endianness and jumps to
the
SC> location of the appropriate endian image. Dump the output of make to a
log
SC> file and look for the compilation of reset.S.

I have already investigated the 'makefile' and 'make' dump - and I've found
that reset code is compiled only in one case - when I compile both LE and BE
images.

Yes, I'm using AMD modified code and perhaps this is the reason, but their
support didn't answer yet.

Anyway - thank you for spending time for me.

With best regards, Roman Mashak.  E-mail: mrv@tusur.ru


From belracu22@rediffmail.com Wed Aug 18 07:15:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 07:15:41 +0100 (BST)
Received: from webmail18.rediffmail.com ([IPv6:::ffff:203.199.83.28]:28500
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8224912AbUHRGPf>; Wed, 18 Aug 2004 07:15:35 +0100
Received: (qmail 31315 invoked by uid 510); 18 Aug 2004 06:15:28 -0000
Date: 18 Aug 2004 06:15:28 -0000
Message-ID: <20040818061528.31314.qmail@webmail18.rediffmail.com>
Received: from unknown (61.30.127.4) by rediffmail.com via HTTP; 18 aug 2004 06:15:28 -0000
MIME-Version: 1.0
From: "bel racu" <belracu22@rediffmail.com>
Reply-To: "bel racu" <belracu22@rediffmail.com>
To: "Arravind babu" <aravindforl@yahoo.co.in>
Cc: binutils@sources.redhat.com, linux-mips@linux-mips.org
Subject: Re: Doubt on rootfs
Content-type: multipart/alternative;
	boundary="Next_1092809728---0-203.199.83.28-31305"
Return-Path: <belracu22@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5667
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: belracu22@rediffmail.com
Precedence: bulk
X-list: linux-mips

 This is a multipart mime message


--Next_1092809728---0-203.199.83.28-31305
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0A&nbsp; <BR>=0A<BR>=0A<BR>=0AOn Tue, 17 Aug 2004 Arravind babu wrote :=
<BR>=0A&gt;Hi all,<BR>=0A&gt;<BR>=0A&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
I am cross-compiling linux 2.4.20 onto MIPS .I compiled and i booted the sy=
stem.When i gave the command mount at the prompt it gave the following thin=
gs.<BR>=0A&gt;<BR>=0A&gt;$mount<BR>=0A&gt;<BR>=0A&gt;rootfs on / type rootf=
s (rw)<BR>=0A<BR>=0Ameen your Root filesystem is in memory<BR>=0A<BR>=0A&gt=
;/dev/rom0 on / type romfs (ro)<BR>=0A&gt;/dev/ram0 on /var type ext2 (rw)<=
BR>=0A<BR>=0ARamdisk&nbsp; mounted for /var with ext2 filesystem<BR>=0A<BR>=
=0A&gt;/proc on /proc type proc (rw)<BR>=0A<BR>=0AProcfs<BR>=0A<BR>=0A&gt;/=
dev/mtdblock6 on /flash type jffs2 (rw)<BR>=0A<BR>=0AFlash device with jffs=
2 filesystem<BR>=0A<BR>=0A&gt;/dev/ram1 on /upgrade type sramfs (rw)<BR>=0A=
&gt;/dev/mtdblock5 on /apps type cramfs (ro)<BR>=0A<BR>=0Aflash device hold=
ing ur filesystm and image<BR>=0A<BR>=0A&gt;devpts on /dev/pts type devpts =
(rw)<BR>=0A&gt;<BR>=0A&gt;<BR>=0A&gt;When i gave the same command on a norm=
al linux 2.4.20 machine i got the following.<BR>=0A&gt;<BR>=0A&gt;$mount<BR=
>=0A&gt;<BR>=0A&gt;/dev/sda1 on / type ext3 (rw)<BR>=0A&gt;none on /proc ty=
pe proc (rw)<BR>=0A&gt;usbdevfs on /proc/bus/usb type usbdevfs (rw)<BR>=0A&=
gt;none on /dev/pts type devpts (rw,gid=3D5,mode=3D620)<BR>=0A&gt;/dev/sda5=
 on /home type ext3 (rw)<BR>=0A&gt;/dev/sdb1 on /home1 type ext3 (rw)<BR>=
=0A&gt;none on /dev/shm type tmpfs (rw)<BR>=0A&gt;none on /proc/sys/fs/binf=
mt_misc type binfmt_misc (rw)<BR>=0A&gt;<BR>=0A<BR>=0Awhen u issue the Moun=
t command it will display all the mounted<BR>=0Adevices. U can also &quot;c=
at /etc/mout&quot; file to check the mounted devices<BR>=0Ain your system.<=
BR>=0A<BR>=0A<BR>=0A&gt;<BR>=0A&gt;Why rootfs is not showing any device lik=
e in linux machine( /dev/sda1 on / type ext3)&nbsp; ?<BR>=0A&gt;&nbsp; I ch=
ecked the files<BR>=0A<BR>=0A<BR>=0A&gt;usr/src/linux/init/main.c<BR>=0A&gt=
;usr/src/linux/fs/ramfs/inode.c<BR>=0A&gt;usr/src/linux/fs/namespace.c<BR>=
=0A&gt;<BR>=0A&gt;But i didnot got the point.Any idea is highly appreciated=
.My project is stopped due to this.Pls help me regarding this.<BR>=0A&gt;<B=
R>=0A&gt;Thanks in advance,<BR>=0A&gt;Aravind.<BR>=0A&gt;<BR>=0A&gt;Yahoo! =
India Matrimony: Find your life partneronline.<BR>=0A=0A</P>=0A<br><br>=0A<=
A target=3D"_blank" HREF=3D"http://clients.rediff.com/signature/track_sig.a=
sp"><IMG SRC=3D"http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.red=
iffmail.com/inbox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1092809728---0-203.199.83.28-31305
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

  =0A=0A=0AOn Tue, 17 Aug 2004 Arravind babu wrote :=0A>Hi all,=0A>=0A>    =
      I am cross-compiling linux 2.4.20 onto MIPS .I compiled and i booted =
the system.When i gave the command mount at the prompt it gave the followin=
g things.=0A>=0A>$mount=0A>=0A>rootfs on / type rootfs (rw)=0A=0Ameen your =
Root filesystem is in memory=0A=0A>/dev/rom0 on / type romfs (ro)=0A>/dev/r=
am0 on /var type ext2 (rw)=0A=0ARamdisk  mounted for /var with ext2 filesys=
tem=0A=0A>/proc on /proc type proc (rw)=0A=0AProcfs=0A=0A>/dev/mtdblock6 on=
 /flash type jffs2 (rw)=0A=0AFlash device with jffs2 filesystem=0A=0A>/dev/=
ram1 on /upgrade type sramfs (rw)=0A>/dev/mtdblock5 on /apps type cramfs (r=
o)=0A=0Aflash device holding ur filesystm and image=0A=0A>devpts on /dev/pt=
s type devpts (rw)=0A>=0A>=0A>When i gave the same command on a normal linu=
x 2.4.20 machine i got the following.=0A>=0A>$mount=0A>=0A>/dev/sda1 on / t=
ype ext3 (rw)=0A>none on /proc type proc (rw)=0A>usbdevfs on /proc/bus/usb =
type usbdevfs (rw)=0A>none on /dev/pts type devpts (rw,gid=3D5,mode=3D620)=
=0A>/dev/sda5 on /home type ext3 (rw)=0A>/dev/sdb1 on /home1 type ext3 (rw)=
=0A>none on /dev/shm type tmpfs (rw)=0A>none on /proc/sys/fs/binfmt_misc ty=
pe binfmt_misc (rw)=0A>=0A=0Awhen u issue the Mount command it will display=
 all the mounted=0Adevices. U can also "cat /etc/mout" file to check the mo=
unted devices=0Ain your system.=0A=0A=0A>=0A>Why rootfs is not showing any =
device like in linux machine( /dev/sda1 on / type ext3)  ?=0A>  I checked t=
he files=0A=0A=0A>usr/src/linux/init/main.c=0A>usr/src/linux/fs/ramfs/inode=
.c=0A>usr/src/linux/fs/namespace.c=0A>=0A>But i didnot got the point.Any id=
ea is highly appreciated.My project is stopped due to this.Pls help me rega=
rding this.=0A>=0A>Thanks in advance,=0A>Aravind.=0A>=0A>Yahoo! India Matri=
mony: Find your life partneronline.=0A
--Next_1092809728---0-203.199.83.28-31305--


From sskowron@ET.PUT.Poznan.PL Wed Aug 18 09:26:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 09:26:51 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:22965
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8224912AbUHRI0r>; Wed, 18 Aug 2004 09:26:47 +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 i7I8Qjd09001
	for <linux-mips@linux-mips.org>; Wed, 18 Aug 2004 10:26:45 +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, 18 Aug 2004 10:26:45 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i7I8Qie17098
	for <linux-mips@linux-mips.org>; Wed, 18 Aug 2004 10:26:44 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Wed, 18 Aug 2004 10:26:44 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Octane gfx works; SCSI woes
Message-ID: <Pine.GSO.4.10.10408181020010.16699-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: 5668
X-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

Hi again!

A new graphics driver for Octane is in order. This driver allows writing
user-mode gfx applications through register mapping and DMA. I would like
to ask anyone with an Octane to help me test this driver.

Currently, the only user-mode application taking advantage of this driver
is MPlayer, which works quite fine (if a bit slowly as there is no
assembly for MIPS - hint, hint!).

Especially wanted:
 * someone with SE/SI card (it is possible that the current driver is
   for double-RSS people only - MX*, SS* as I use RSS switching at some
   point - this has to be auto-detected and fixed!)
 * someone knowledgeable about SCSI (currently the ISP1040 controllers
   found in Octane bomb in a strange way with HCH's patched SCSI driver;
   they don't work at all with the QLISP driver).

Have fun,

Stanislaw Skowronek

--<=>--
  "You're not as old as the trees, not as young as the leaves.
   Not as free as the breeze, not as open as the seas."



From geert@linux-m68k.org Wed Aug 18 09:36:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 09:37:00 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:25071 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224912AbUHRIg4>;
	Wed, 18 Aug 2004 09:36:56 +0100
Received: from waterleaf.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i7I8asn1024409;
	Wed, 18 Aug 2004 10:36:54 +0200 (MEST)
Date: Wed, 18 Aug 2004 10:36:53 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: bel racu <belracu22@rediffmail.com>
cc: Arravind babu <aravindforl@yahoo.co.in>,
	binutils@sources.redhat.com,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Doubt on rootfs
In-Reply-To: <20040818061528.31314.qmail@webmail18.rediffmail.com>
Message-ID: <Pine.GSO.4.58.0408181036070.28415@waterleaf.sonytel.be>
References: <20040818061528.31314.qmail@webmail18.rediffmail.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: 5669
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Wed, 18 Aug 2004, bel racu wrote:
> when u issue the Mount command it will display all the mounted
> devices. U can also "cat /etc/mout" file to check the mounted devices
> in your system.

Or better, `cat /proc/mount', since /etc/mount may be out-of-date.

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 thomas.koeller@baslerweb.com Wed Aug 18 11:55:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 11:55:41 +0100 (BST)
Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:61968
	"EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP
	id <S8224912AbUHRKzg>; Wed, 18 Aug 2004 11:55:36 +0100
Received: from comm1.baslerweb.com (proxy.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, 18 Aug 2004 12:54:25 +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 PLG5VKFP; Wed, 18 Aug 2004 12:55:31 +0200
From: Thomas Koeller <thomas.koeller@baslerweb.com>
Organization: Basler AG
To: linux-mips@linux-mips.org
Subject: Re: [PATCH] serial support for yosemite
Date: Wed, 18 Aug 2004 12:57:44 +0200
User-Agent: KMail/1.6.2
References: <200408111128.44965.thomas.koeller@baslerweb.com>
In-Reply-To: <200408111128.44965.thomas.koeller@baslerweb.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200408181257.44060.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: 5670
X-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

Hi,

some time ago I posted this patch to the list. So far I 
have not received any response at all. As this is my
first attempt at contributing code to linux-mips.org,
I am wondering if I did it the right way?

Thomas
-- 
--------------------------------------------------

Thomas Koeller, Software Development
Basler Vision Technologies

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

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

From ralf@linux-mips.org Wed Aug 18 12:57:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 12:57:55 +0100 (BST)
Received: from p508B7E7F.dip.t-dialin.net ([IPv6:::ffff:80.139.126.127]:40279
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224912AbUHRL5r>; Wed, 18 Aug 2004 12:57:47 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7IBufJO015276;
	Wed, 18 Aug 2004 13:56:41 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7IBuIvT015275;
	Wed, 18 Aug 2004 13:56:18 +0200
Date: Wed, 18 Aug 2004 13:56:18 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Thomas Koeller <thomas.koeller@baslerweb.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] serial support for yosemite
Message-ID: <20040818115618.GA11356@linux-mips.org>
References: <200408111128.44965.thomas.koeller@baslerweb.com> <200408181257.44060.thomas.koeller@baslerweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200408181257.44060.thomas.koeller@baslerweb.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: 5671
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Aug 18, 2004 at 12:57:44PM +0200, Thomas Koeller wrote:

> some time ago I posted this patch to the list. So far I 
> have not received any response at all. As this is my
> first attempt at contributing code to linux-mips.org,
> I am wondering if I did it the right way?

I've been on a Linux trip of several weeks.

  Ralf

From maksik@gmx.co.uk Wed Aug 18 13:05:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 13:06:02 +0100 (BST)
Received: from skl1.ukl.uni-freiburg.de ([IPv6:::ffff:193.196.199.1]:44184
	"EHLO relay1.uniklinik-freiburg.de") by linux-mips.org with ESMTP
	id <S8224929AbUHRMF4>; Wed, 18 Aug 2004 13:05:56 +0100
Received: from ktl77.ukl.uni-freiburg.de (ktl77.ukl.uni-freiburg.de [193.196.226.77])
	by relay1.uniklinik-freiburg.de (Email) with ESMTP
	id 1F2012F314; Wed, 18 Aug 2004 14:05:50 +0200 (CEST)
From: Max Zaitsev <maksik@gmx.co.uk>
Organization: Mutella Dev co.
To: "Kaj-Michael Lang" <milang@tal.org>
Subject: Re: O2 arcboot 32-bit kernel boot fix
Date: Wed, 18 Aug 2004 14:05:53 +0200
User-Agent: KMail/1.6.2
References: <001401c483b8$51d289f0$54dc10c3@amos>
In-Reply-To: <001401c483b8$51d289f0$54dc10c3@amos>
Cc: <linux-mips@linux-mips.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200408181405.53977.maksik@gmx.co.uk>
Return-Path: <maksik@gmx.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: 5672
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maksik@gmx.co.uk
Precedence: bulk
X-list: linux-mips

Hi,

good news, but I cannot test your fix because I'm not able to compile a 
working arcboot binary. I've tried self-compilation with cgg 3.3 and 3.4 and 
neither worked (the binary was about 500K large and did nothing). I've tried 
cross-compilation, but it did not complete. The only working binary I was 
able to acquire was unpacked from the debian package. But kernel crashed with 
that anyways (I've tried only 64-bit kernels so far).

It would be very helpfull for me if you could enlighten me with the 
instructions to compile arcboot: which gcc version should I use and which 
tricks shall I apply to get it to compile. Or you may just send me the binary 
(or put it out on your Internet site). Or you can do both :-))

Regards,
Max

On Monday 16 August 2004 19:41, Kaj-Michael Lang wrote:
> Hi
>
> Played with arcboot today and fixed (for me atleast) loading of 32-bit
> kernels.
> I've also added a very simple progress thing so you know something is
> happening when
> the kernel is loaded.
> Anyway, the patch can be found here:
> http://fairytale.tal.org/pub/talinux/patches/arcboot-O2boot-and-progress.pa
>tch
>
> The fix was quite simple, arcboot was loading the kernel over itself, the
>  -	.base     = 0x80004000,
> +	.base     = 0x80002000,
>
> change is the actual fix. 64-bit kernels loads fine after the fix.
>
> There is some extra stuff (a patch from gentoo, removal debuging from e2fs
> lib, etc) too..

From ralf@linux-mips.org Wed Aug 18 13:30:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 13:30:21 +0100 (BST)
Received: from p508B7E7F.dip.t-dialin.net ([IPv6:::ffff:80.139.126.127]:59479
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224828AbUHRMaQ>; Wed, 18 Aug 2004 13:30:16 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7ICUEcE015714
	for <linux-mips@linux-mips.org>; Wed, 18 Aug 2004 14:30:14 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7ICUE6s015713
	for linux-mips@linux-mips.org; Wed, 18 Aug 2004 14:30:14 +0200
Date: Wed, 18 Aug 2004 14:30:14 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: Branch bug in gas on MIPS
Message-ID: <20040818123014.GA15627@linux-mips.org>
References: <20040817160110.GA32594@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040817160110.GA32594@linux-mips.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5673
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Aug 17, 2004 at 06:01:10PM +0200, Ralf Baechle wrote:

I've uploaded fixed rpm packages of cross-binutils built on Fedora Core 2
for i386 to ftp.linux-mips.org which fix the swapped branch bug which I
posted yesterday.

03347fbaefda6451ad025e05dd43fc79  binutils-mips-linux-2.13.2.1-4.i386.rpm
6d3f22d1666497d6d02e2a2534426709  binutils-mips64-linux-2.13.2.1-4.i386.rpm
aca35612fa321ca01b02e84512cd2ae7  binutils-mips64el-linux-2.13.2.1-4.i386.rpm
1e87615b74173a2a2c5b94b60dc4bb2e  binutils-mipsel-linux-2.13.2.1-4.i386.rpm
a26ba1110361c2c167223ad01ed1acc2  cross-binutils-2.13.2.1-4.src.rpm

Please verify the checksums; for about 2h before this announcement I had
broken rpm packages online.

The unbundled fix (credits for which belong to Thiemo Seufer) is below.

  Ralf

diff -urN binutils-2.13.2.1.orig/gas/config/tc-mips.c binutils-2.13.2.1/gas/config/tc-mips.c
--- binutils-2.13.2.1.orig/gas/config/tc-mips.c	2002-11-05 23:03:40.000000000 +0100
+++ binutils-2.13.2.1/gas/config/tc-mips.c	2004-08-18 13:15:31.553748456 +0200
@@ -2466,6 +2466,7 @@
 	  prev_insn_reloc_type[1] = BFD_RELOC_UNUSED;
 	  prev_insn_reloc_type[2] = BFD_RELOC_UNUSED;
 	  prev_insn_extended = 0;
+	  prev_insn_is_delay_slot = 1;
 	}
       else
 	{

From milang@tal.org Wed Aug 18 15:28:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 15:28:48 +0100 (BST)
Received: from gw01.mail.saunalahti.fi ([IPv6:::ffff:195.197.172.115]:50605
	"EHLO gw01.mail.saunalahti.fi") by linux-mips.org with ESMTP
	id <S8224929AbUHRO2n>; Wed, 18 Aug 2004 15:28:43 +0100
Received: from fairytale.tal.org (cruel.tal.org [195.16.220.85])
	by gw01.mail.saunalahti.fi (Postfix) with ESMTP id D50B34C743;
	Wed, 18 Aug 2004 17:28:39 +0300 (EEST)
Received: from amos (unknown [195.16.220.84])
	by fairytale.tal.org (Postfix) with SMTP
	id 63C9D8D78; Wed, 18 Aug 2004 17:37:18 +0300 (EEST)
Message-ID: <003901c48530$577b4f80$54dc10c3@amos>
From: "Kaj-Michael Lang" <milang@tal.org>
To: "Max Zaitsev" <maksik@gmx.co.uk>
Cc: <linux-mips@linux-mips.org>
References: <001401c483b8$51d289f0$54dc10c3@amos> <200408181405.53977.maksik@gmx.co.uk>
Subject: Re: O2 arcboot 32-bit kernel boot fix
Date: Wed, 18 Aug 2004 17:33:32 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Return-Path: <milang@tal.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: 5674
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: milang@tal.org
Precedence: bulk
X-list: linux-mips

> good news, but I cannot test your fix because I'm not able to compile a
> working arcboot binary. I've tried self-compilation with cgg 3.3 and 3.4
and

Did you just use the small fix or did you use the whole patch ?

-- 
Kaj-Michael Lang , milang@tal.org


From maksik@gmx.co.uk Wed Aug 18 15:46:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 15:47:00 +0100 (BST)
Received: from skl1.ukl.uni-freiburg.de ([IPv6:::ffff:193.196.199.1]:52643
	"EHLO relay1.uniklinik-freiburg.de") by linux-mips.org with ESMTP
	id <S8224929AbUHROqz>; Wed, 18 Aug 2004 15:46:55 +0100
Received: from ktl77.ukl.uni-freiburg.de (ktl77.ukl.uni-freiburg.de [193.196.226.77])
	by relay1.uniklinik-freiburg.de (Email) with ESMTP
	id 223ED2F2EA; Wed, 18 Aug 2004 16:46:49 +0200 (CEST)
From: Max Zaitsev <maksik@gmx.co.uk>
Organization: Mutella Dev co.
To: "Kaj-Michael Lang" <milang@tal.org>
Subject: Re: O2 arcboot 32-bit kernel boot fix
Date: Wed, 18 Aug 2004 16:46:53 +0200
User-Agent: KMail/1.6.2
References: <001401c483b8$51d289f0$54dc10c3@amos> <200408181405.53977.maksik@gmx.co.uk> <003901c48530$577b4f80$54dc10c3@amos>
In-Reply-To: <003901c48530$577b4f80$54dc10c3@amos>
Cc: <linux-mips@linux-mips.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200408181646.53698.maksik@gmx.co.uk>
Return-Path: <maksik@gmx.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: 5675
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maksik@gmx.co.uk
Precedence: bulk
X-list: linux-mips

> Did you just use the small fix or did you use the whole patch ?
>

No, I've just used the original 3.8.1 distribution and could not compile that 
I've tried it like a month ago and did not get anywhere neither with 
self-compilation nor with cross-compilation. I wrote Guido Guenther and he 
had said that he only tried to compile arcboot with gcc 2.95 and that gcc 3.x 
might have problems stripping some symbols that we want from the binary, 
while leaving the others, that we don't want... That would explain the factor 
10 increase in the resulting file size and it's inability to do anything...

So the thing is that the original arcboot 3.8.1 does not work for me if I 
compile (whereas the debian binary of the same version does), so it made no 
sense for me to try to apply your patch. I need to find a way to compile 
arcboot properly first. How do you do that yourself? Or do you think your 
fixes in makefiles make difference already? Actually, you've changed the 
LDFLAGS, which could be the problem... OK, I'll give it a try and let you 
know how it was.

Regards,
Max


From tinglai@gmail.com Wed Aug 18 16:06:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 16:06:39 +0100 (BST)
Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.196]:58718 "EHLO
	mproxy.gmail.com") by linux-mips.org with ESMTP id <S8224929AbUHRPGe>;
	Wed, 18 Aug 2004 16:06:34 +0100
Received: by mproxy.gmail.com with SMTP id 76so182196rnk
        for <linux-mips@linux-mips.org>; Wed, 18 Aug 2004 08:06:27 -0700 (PDT)
Received: by 10.38.13.31 with SMTP id 31mr481878rnm;
        Wed, 18 Aug 2004 08:06:27 -0700 (PDT)
Message-ID: <e2eac65704081808061f27cb5a@mail.gmail.com>
Date: Wed, 18 Aug 2004 11:06:27 -0400
From: Tim Lai <tinglai@gmail.com>
Reply-To: Tim Lai <tinglai@gmail.com>
To: Eric DeVolder <eric.devolder@amd.com>, linux-mips@linux-mips.org
Subject: Re: problem with prefetch in user space
In-Reply-To: <41235841.6090105@amd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <e2eac65704081716345c78b7c6@mail.gmail.com> <41235841.6090105@amd.com>
Return-Path: <tinglai@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5676
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tinglai@gmail.com
Precedence: bulk
X-list: linux-mips

Thanks for the suggestion.
I tried it, and still got the same error:

/tmp/cc73TRSF.s:5521: Error: illegal operands `pref'


On Wed, 18 Aug 2004 08:23:13 -0500, Eric DeVolder <eric.devolder@amd.com> wrote:
> try ".set mips32" instead of ".set mips4"
> 
> 
> 
> Tim Lai wrote:
> 
> >I am trying to use prefetch in user space. I am using mips_fp_be-gcc
> >version 3.2.1,
> >and the kernel is MontaVista 2.4 kernel.
> >
> >I have a C program with the fellowing function:
> >
> >inline void mips_prefetch(void *addr)
> >{
> >    __asm__ __volatile__(
> >                         ".set push                  \n"
> >                         ".set noreorder             \n"
> >                         ".set noat                  \n"
> >                         ".set mips4                 \n"
> >
> >                         "     pref       4 ,  0(%0)  \n"
> >
> >                         ".set pop                   \n");
> >    return;
> >}
> >
> >When I compile with gcc,
> >/tmp/ccMHaOOf.s: Assembler messages:
> >/tmp/ccMHaOOf.s:5479: Error: illegal operands `pref'
> >make: *** [foo.o] Error 1
> >
> >I tried add -mips4 option in gcc, it got even worst,
> >
> >/tmp/ccN6Xs81.s: Assembler messages:
> >/tmp/ccN6Xs81.s:54: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:55: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:128: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:129: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:171: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:223: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:224: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:420: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:421: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:698: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:776: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:801: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:815: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:857: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:858: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:913: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:1308: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:1377: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:1402: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:1424: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:1462: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:1497: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:1498: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:1953: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:1954: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:2023: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2092: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2145: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2275: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2313: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:2314: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:2360: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:2361: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:2395: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:2396: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:2480: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:2481: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:2565: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2575: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2609: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2686: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2692: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2714: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2741: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2745: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2793: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2818: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2824: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2849: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2858: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2883: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:2948: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:2949: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:3036: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:3037: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:3109: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3260: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3388: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3393: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3446: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3458: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3469: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3486: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3543: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3631: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3677: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3695: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3715: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3739: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3805: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3829: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3840: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3858: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3935: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3941: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3963: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3982: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:3994: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4012: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4086: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4101: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4142: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:4143: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:4196: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4210: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4236: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4264: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4285: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4311: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4330: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4386: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:4387: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:4673: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4714: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4882: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:4948: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5014: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5067: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5179: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5282: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5366: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5382: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5441: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5585: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:5586: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:5685: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5690: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5705: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5782: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:5783: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:5808: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5816: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5880: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:5915: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:5916: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:5925: Error: illegal operands `pref'
> >/tmp/ccN6Xs81.s:5926: Error: illegal operands `pref'
> >/tmp/ccN6Xs81.s:5927: Error: illegal operands `pref'
> >/tmp/ccN6Xs81.s:5928: Error: illegal operands `pref'
> >/tmp/ccN6Xs81.s:5929: Error: illegal operands `pref'
> >/tmp/ccN6Xs81.s:5930: Error: illegal operands `pref'
> >/tmp/ccN6Xs81.s:5931: Error: illegal operands `pref'
> >/tmp/ccN6Xs81.s:5962: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:5963: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:6008: Error: illegal operands `lui'
> >/tmp/ccN6Xs81.s:6009: Error: illegal operands `addiu'
> >/tmp/ccN6Xs81.s:6024: Warning: No .cprestore pseudo-op used in PIC code
> >/tmp/ccN6Xs81.s:6035: Warning: No .cprestore pseudo-op used in PIC code
> >
> >Can anyone shine some light on this?
> >Is prefetch not mean for user program at all?
> >Have anyone got this to work?
> >
> >Thanks.
> >
> >Tim Lai
> >
> >
> >
> >
> 
>

From ica2_ts@csv.ica.uni-stuttgart.de Wed Aug 18 16:34:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 16:34:55 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:17926
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224929AbUHRPev>; Wed, 18 Aug 2004 16:34:51 +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 1BxSPl-0005tD-00; Wed, 18 Aug 2004 17:31:49 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1BxSPk-0005qO-00; Wed, 18 Aug 2004 17:31:48 +0200
Date: Wed, 18 Aug 2004 17:31:48 +0200
To: Tim Lai <tinglai@gmail.com>
Cc: Eric DeVolder <eric.devolder@amd.com>, linux-mips@linux-mips.org
Subject: Re: problem with prefetch in user space
Message-ID: <20040818153148.GI23756@rembrandt.csv.ica.uni-stuttgart.de>
References: <e2eac65704081716345c78b7c6@mail.gmail.com> <41235841.6090105@amd.com> <e2eac65704081808061f27cb5a@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e2eac65704081808061f27cb5a@mail.gmail.com>
User-Agent: Mutt/1.5.6i
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: 5677
X-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

Tim Lai wrote:
> Thanks for the suggestion.
> I tried it, and still got the same error:
> 
> /tmp/cc73TRSF.s:5521: Error: illegal operands `pref'

That's because you use

> > >                         "     pref       4 ,  0(%0)  \n"
> > >
> > >                         ".set pop                   \n");

without defining %0 as a register input.


Thiemo

From zaitsev@ukl.uni-freiburg.de Wed Aug 18 16:52:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 16:52:43 +0100 (BST)
Received: from skl1.ukl.uni-freiburg.de ([IPv6:::ffff:193.196.199.1]:52904
	"EHLO relay1.uniklinik-freiburg.de") by linux-mips.org with ESMTP
	id <S8224929AbUHRPwi>; Wed, 18 Aug 2004 16:52:38 +0100
Received: from ktl77.ukl.uni-freiburg.de (ktl77.ukl.uni-freiburg.de [193.196.226.77])
	by relay1.uniklinik-freiburg.de (Email) with ESMTP
	id 3E3C12F291; Wed, 18 Aug 2004 17:52:30 +0200 (CEST)
From: Maxim Zaitsev <zaitsev@ukl.uni-freiburg.de>
Organization: University Hospital Freiburg
To: "Kaj-Michael Lang" <milang@tal.org>
Subject: Re: O2 arcboot 32-bit kernel boot fix
Date: Wed, 18 Aug 2004 17:52:35 +0200
User-Agent: KMail/1.6.2
Cc: <linux-mips@linux-mips.org>
References: <001401c483b8$51d289f0$54dc10c3@amos> <003901c48530$577b4f80$54dc10c3@amos> <200408181646.53698.maksik@gmx.co.uk>
In-Reply-To: <200408181646.53698.maksik@gmx.co.uk>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200408181752.35073.zaitsev@ukl.uni-freiburg.de>
Return-Path: <zaitsev@ukl.uni-freiburg.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: 5678
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zaitsev@ukl.uni-freiburg.de
Precedence: bulk
X-list: linux-mips

Ha!!! It works!!! Well, only 32-bit kernels work, but anyways, sorry for 
trouble. I must have tested it before bothering you with stupid questions... 

With regard to booting a 64-bit kernel it all looks OK, loading works and what 
I see in the end is:

Starting 64-bit kernel
--- Press <spacebar> to restart ---

No OOPs, no crash, nothing! Isn't that strange? Any ideas?

Regards,
Max

On Wednesday 18 August 2004 16:46, Max Zaitsev wrote:
> > Did you just use the small fix or did you use the whole patch ?
>
> No, I've just used the original 3.8.1 distribution and could not compile
> that I've tried it like a month ago and did not get anywhere neither with
> self-compilation nor with cross-compilation. I wrote Guido Guenther and he
> had said that he only tried to compile arcboot with gcc 2.95 and that gcc
> 3.x might have problems stripping some symbols that we want from the
> binary, while leaving the others, that we don't want... That would explain
> the factor 10 increase in the resulting file size and it's inability to do
> anything...
>
> So the thing is that the original arcboot 3.8.1 does not work for me if I
> compile (whereas the debian binary of the same version does), so it made no
> sense for me to try to apply your patch. I need to find a way to compile
> arcboot properly first. How do you do that yourself? Or do you think your
> fixes in makefiles make difference already? Actually, you've changed the
> LDFLAGS, which could be the problem... OK, I'll give it a try and let you
> know how it was.
>
> Regards,
> Max

-- 
Dr. Maxim Zaitsev
University Hospital Freiburg
Department of Diagnostic Radiology
Medical Physics
Hugstetterstr. 55
79106 Freiburg
Tel. (761) 270 3800
Fax. (761) 270 3831

From ica2_ts@csv.ica.uni-stuttgart.de Wed Aug 18 16:58:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 16:58:34 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:41222
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224929AbUHRP6W>; Wed, 18 Aug 2004 16:58:22 +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 1BxSpS-00069q-00; Wed, 18 Aug 2004 17:58:22 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1BxSpP-0005w6-00; Wed, 18 Aug 2004 17:58:19 +0200
Date: Wed, 18 Aug 2004 17:58:19 +0200
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org, binutils@sources.redhat.com,
	Daniel Jacobowitz <drow@false.org>
Subject: Re: Branch bug in gas on MIPS
Message-ID: <20040818155819.GJ23756@rembrandt.csv.ica.uni-stuttgart.de>
References: <20040817160110.GA32594@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040817160110.GA32594@linux-mips.org>
User-Agent: Mutt/1.5.6i
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: 5679
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Ralf Baechle wrote:
> Below little test case demonstrates a gas bug that results in swapping
> of the two branch instructions and use of bogus destination addresses
> for the first of the two branches.
> 
> [ralf@lappi tmp]$ cat s.s
> 1:      beqzl   $2, 1b
>         beq     $4, $5, 1b
> [ralf@lappi tmp]$ mips-linux-as -mips2 -o s.o s.s
> [ralf@lappi tmp]$ mips-linux-objdump -d s.o
>  
> s.o:     file format elf32-tradbigmips
>  
> Disassembly of section .text:
>  
> 00000000 <.text>:
>    0:   1085ffff        beq     a0,a1,0x0
>    4:   00000000        nop
>    8:   50400000        beqzl   v0,0xc
>    c:   00000000        nop

I applied the appended patch. Daniel, I think this should also go
in the branch.


Thiemo


/gas/ChangeLog
2004-08-18  Thiemo Seufer  <seufer@csv.ica.uni-stuttgart.de>
	* config/tc-mips.c (append_insn): Handle delay slots in branch likely
	correctly.

/gas/testsuite/ChangeLog
2004-08-18  Thiemo Seufer  <seufer@csv.ica.uni-stuttgart.de>
	* gas/mips/branch-swap.s: New testcase.
	* gas/mips/branch-swap.d: New testcase.
	* gas/mips/mips.exp: Run the testcase.


--- gas/config/tc-mips.c.old	2004-05-17 21:36:10.000000000 +0200
+++ gas/config/tc-mips.c	2004-08-17 20:00:43.000000000 +0200
@@ -2708,6 +2708,7 @@ append_insn (struct mips_cl_insn *ip, ex
 	  prev_insn_reloc_type[1] = BFD_RELOC_UNUSED;
 	  prev_insn_reloc_type[2] = BFD_RELOC_UNUSED;
 	  prev_insn_extended = 0;
+	  prev_insn_is_delay_slot = 1;
 	}
       else
 	{
--- gas/testsuite/gas/mips/mips.exp.old	2004-08-17 22:50:38.000000000 +0200
+++ gas/testsuite/gas/mips/mips.exp	2004-08-18 14:53:43.000000000 +0200
@@ -429,6 +429,7 @@ if { [istarget mips*-*-*] } then {
     run_dump_test_arches "branch-misc-1" [mips_arch_list_matching mips1]
     run_list_test_arches "branch-misc-2" "-32 -non_shared" [mips_arch_list_matching mips1]
     run_list_test_arches "branch-misc-2pic" "-32 -call_shared" [mips_arch_list_matching mips1]
+    run_dump_test "branch-swap"
 
     if $ilocks {
 	run_dump_test "div-ilocks"
--- gas/testsuite/gas/mips/branch-swap.s.old	1970-01-01 01:00:00.000000000 +0100
+++ gas/testsuite/gas/mips/branch-swap.s	2004-08-17 22:52:50.000000000 +0200
@@ -0,0 +1,9 @@
+	.set push
+	.set mips2
+1:	beqzl	$2, 1b
+	b	1b
+foo:	beqzl	$2, foo
+	b	foo
+
+	.set pop
+	.space 8
--- gas/testsuite/gas/mips/branch-swap.d.old	1970-01-01 01:00:00.000000000 +0100
+++ gas/testsuite/gas/mips/branch-swap.d	2004-08-17 22:57:36.000000000 +0200
@@ -0,0 +1,20 @@
+#as: -march=mips2
+#objdump: -dr
+#name: MIPS branch-swap
+
+.*:     file format .*mips.*
+
+Disassembly of section \.text:
+
+00000000 <foo-0x10>:
+   0:	5040ffff 	beqzl	v0,0 <foo-0x10>
+   4:	00000000 	nop
+   8:	1000fffd 	b	0 <foo-0x10>
+   c:	00000000 	nop
+
+00000010 <foo>:
+  10:	5040ffff 	beqzl	v0,10 <foo>
+  14:	00000000 	nop
+  18:	1000fffd 	b	10 <foo>
+  1c:	00000000 	nop
+	\.\.\.

From tinglai@gmail.com Wed Aug 18 17:42:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 17:42:21 +0100 (BST)
Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.195]:21066 "EHLO
	mproxy.gmail.com") by linux-mips.org with ESMTP id <S8224929AbUHRQmJ>;
	Wed, 18 Aug 2004 17:42:09 +0100
Received: by mproxy.gmail.com with SMTP id 76so187304rnk
        for <linux-mips@linux-mips.org>; Wed, 18 Aug 2004 09:42:04 -0700 (PDT)
Received: by 10.38.13.31 with SMTP id 31mr510410rnm;
        Wed, 18 Aug 2004 09:42:04 -0700 (PDT)
Message-ID: <e2eac657040818094264dc6a3b@mail.gmail.com>
Date: Wed, 18 Aug 2004 12:42:04 -0400
From: Tim Lai <tinglai@gmail.com>
Reply-To: Tim Lai <tinglai@gmail.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Subject: Re: problem with prefetch in user space
Cc: Eric DeVolder <eric.devolder@amd.com>, linux-mips@linux-mips.org
In-Reply-To: <20040818153148.GI23756@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <e2eac65704081716345c78b7c6@mail.gmail.com> <41235841.6090105@amd.com> <e2eac65704081808061f27cb5a@mail.gmail.com> <20040818153148.GI23756@rembrandt.csv.ica.uni-stuttgart.de>
Return-Path: <tinglai@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5680
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tinglai@gmail.com
Precedence: bulk
X-list: linux-mips

Thanks. 
I did some search and find no answer. How do I define %0 as a register input and
assign the value of "addr" to it?

Tim 

On Wed, 18 Aug 2004 17:31:48 +0200, Thiemo Seufer
<ica2_ts@csv.ica.uni-stuttgart.de> wrote:
> Tim Lai wrote:
> > Thanks for the suggestion.
> > I tried it, and still got the same error:
> >
> > /tmp/cc73TRSF.s:5521: Error: illegal operands `pref'
> 
> That's because you use
> 
> > > >                         "     pref       4 ,  0(%0)  \n"
> > > >
> > > >                         ".set pop                   \n");
> 
> without defining %0 as a register input.
> 
> 
> Thiemo
>

From ica2_ts@csv.ica.uni-stuttgart.de Wed Aug 18 18:13:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 18:13:51 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:2824
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224929AbUHRRNq>; Wed, 18 Aug 2004 18:13:46 +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 1BxU0N-0006sO-00; Wed, 18 Aug 2004 19:13:43 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1BxU0M-0006JL-00; Wed, 18 Aug 2004 19:13:42 +0200
Date: Wed, 18 Aug 2004 19:13:42 +0200
To: Tim Lai <tinglai@gmail.com>
Cc: Eric DeVolder <eric.devolder@amd.com>, linux-mips@linux-mips.org
Subject: Re: problem with prefetch in user space
Message-ID: <20040818171342.GN23756@rembrandt.csv.ica.uni-stuttgart.de>
References: <e2eac65704081716345c78b7c6@mail.gmail.com> <41235841.6090105@amd.com> <e2eac65704081808061f27cb5a@mail.gmail.com> <20040818153148.GI23756@rembrandt.csv.ica.uni-stuttgart.de> <e2eac657040818094264dc6a3b@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e2eac657040818094264dc6a3b@mail.gmail.com>
User-Agent: Mutt/1.5.6i
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: 5681
X-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

Tim Lai wrote:
> Thanks. 
> I did some search and find no answer. How do I define %0 as a register input and
> assign the value of "addr" to it?

Something like:

        __asm__ __volatile__(
		".set push\n"
		".set mips4\n"
		"pref " PREF_OP ", 0(%0)\n"
		".set pop\n"
		: "=r" (addr));

For more information: "info gcc" and the kernel sources.


Thiemo

From drow@nevyn.them.org Wed Aug 18 18:49:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 18:49:09 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:3297 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225004AbUHRRtC>;
	Wed, 18 Aug 2004 18:49:02 +0100
Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian))
	id 1BxUYR-00064z-Ux; Wed, 18 Aug 2004 13:48:56 -0400
Date: Wed, 18 Aug 2004 13:48:55 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: Branch bug in gas on MIPS
Message-ID: <20040818174855.GA23199@nevyn.them.org>
Mail-Followup-To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
References: <20040817160110.GA32594@linux-mips.org> <20040818155819.GJ23756@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040818155819.GJ23756@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <drow@nevyn.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: 5682
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Wed, Aug 18, 2004 at 05:58:19PM +0200, Thiemo Seufer wrote:
> Ralf Baechle wrote:
> > Below little test case demonstrates a gas bug that results in swapping
> > of the two branch instructions and use of bogus destination addresses
> > for the first of the two branches.
> > 
> > [ralf@lappi tmp]$ cat s.s
> > 1:      beqzl   $2, 1b
> >         beq     $4, $5, 1b
> > [ralf@lappi tmp]$ mips-linux-as -mips2 -o s.o s.s
> > [ralf@lappi tmp]$ mips-linux-objdump -d s.o
> >  
> > s.o:     file format elf32-tradbigmips
> >  
> > Disassembly of section .text:
> >  
> > 00000000 <.text>:
> >    0:   1085ffff        beq     a0,a1,0x0
> >    4:   00000000        nop
> >    8:   50400000        beqzl   v0,0xc
> >    c:   00000000        nop
> 
> I applied the appended patch. Daniel, I think this should also go
> in the branch.

OK.

-- 
Daniel Jacobowitz

From milang@tal.org Wed Aug 18 20:39:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 20:39:05 +0100 (BST)
Received: from [IPv6:::ffff:195.197.172.116] ([IPv6:::ffff:195.197.172.116]:46827
	"EHLO gw02.mail.saunalahti.fi") by linux-mips.org with ESMTP
	id <S8224990AbUHRTjA>; Wed, 18 Aug 2004 20:39:00 +0100
Received: from tori.tal.org (tori.tal.org [195.16.220.82])
	by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 612D417D44;
	Wed, 18 Aug 2004 22:38:48 +0300 (EEST)
Date: Wed, 18 Aug 2004 22:41:09 +0300 (EEST)
From: Kaj-Michael Lang <milang@tal.org>
To: Maxim Zaitsev <zaitsev@ukl.uni-freiburg.de>
Cc: linux-mips@linux-mips.org
Subject: Re: O2 arcboot 32-bit kernel boot fix
In-Reply-To: <200408181752.35073.zaitsev@ukl.uni-freiburg.de>
Message-ID: <Pine.LNX.4.58.0408182240280.12942@tori.tal.org>
References: <001401c483b8$51d289f0$54dc10c3@amos> <003901c48530$577b4f80$54dc10c3@amos>
 <200408181646.53698.maksik@gmx.co.uk> <200408181752.35073.zaitsev@ukl.uni-freiburg.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <milang@tal.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: 5683
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: milang@tal.org
Precedence: bulk
X-list: linux-mips

On Wed, 18 Aug 2004, Maxim Zaitsev wrote:

> Ha!!! It works!!! Well, only 32-bit kernels work, but anyways, sorry for
> trouble. I must have tested it before bothering you with stupid questions...
>
> With regard to booting a 64-bit kernel it all looks OK, loading works and what
> I see in the end is:

Don't use vmlinux.64, use plain vmlinux.. that works for me.

-- 
Kaj-Michael Lang, Turku, Finland
milang@tal.org http://www.tal.org

From milang@tal.org Wed Aug 18 23:16:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Aug 2004 23:16:12 +0100 (BST)
Received: from gw01.mail.saunalahti.fi ([IPv6:::ffff:195.197.172.115]:39578
	"EHLO gw01.mail.saunalahti.fi") by linux-mips.org with ESMTP
	id <S8224986AbUHRWQG>; Wed, 18 Aug 2004 23:16:06 +0100
Received: from tori.tal.org (tori.tal.org [195.16.220.82])
	by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 4DD7E4CB0E
	for <linux-mips@linux-mips.org>; Thu, 19 Aug 2004 01:16:04 +0300 (EEST)
Date: Thu, 19 Aug 2004 01:18:28 +0300 (EEST)
From: Kaj-Michael Lang <milang@tal.org>
To: linux-mips@linux-mips.org
Subject: Patch to fix O2 fb mmap + misc other fixes
Message-ID: <Pine.LNX.4.58.0408190115080.16742@tori.tal.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <milang@tal.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: 5684
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: milang@tal.org
Precedence: bulk
X-list: linux-mips

I found the problem to why mmap of the O2 fb didn't work...

Patch with mmap fix, fbset depth changing fix and sysfs support can be
found here: http://home.tal.org/~milang/o2/patches/

It might need some cleaning and such but it works for me.
Enjoy..

-- 
Kaj-Michael Lang, Turku, Finland
milang@tal.org http://www.tal.org

From chr@active.ch Thu Aug 19 14:34:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Aug 2004 14:34:38 +0100 (BST)
Received: from mail04.agrinet.ch ([IPv6:::ffff:81.221.250.53]:44039 "EHLO
	mail04.agrinet.ch") by linux-mips.org with ESMTP
	id <S8224924AbUHSNeb>; Thu, 19 Aug 2004 14:34:31 +0100
Received: by mail04.agrinet.ch (7.0.024) id 40FECDE10043A740 for linux-mips@linux-mips.org; Thu, 19 Aug 2004 15:34:24 +0200
From: chr@active.ch
Subject: Re: Protected Mail Delivery
To: linux-mips@linux-mips.org
Date: Thu, 19 Aug 2004 15:34:24 +0200
Message-ID: <40FECDE10043A73F@mail04.agrinet.ch>
In-Reply-To: <40FECDE10043A73E@mail04.agrinet.ch>
Precedence: junk
Delivered-To: chr@active.ch
Content-Type: text/plain; charset=ISO-8859-1
MIME-Version: 1.0
Return-Path: <chr@active.ch>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5685
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chr@active.ch
Precedence: bulk
X-list: linux-mips

Achtung neue Mail-Adresse !
Neu: vorname.familienname bei gleichem Provider oder rufen Sie uns bitte an (01/977 13 77) und wir werde die neue Adresse mitteilen. 

Leider erhalten wir pro Tag mehr als 100 Mails welche wir nicht wollen. Wir haben uns daher entschieden, eine neue Adresse zu waehlen.

Ihr Mail wird bei uns auf dem Mailserver automatisch geloescht !

From dom@mips.com Thu Aug 19 15:17:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Aug 2004 15:17:40 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:41225 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224912AbUHSORg>;
	Thu, 19 Aug 2004 15:17:36 +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 1BxnuJ-0001ra-00; Thu, 19 Aug 2004 15:28:47 +0100
Received: from arsenal.mips.com ([192.168.192.197])
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1Bxnj5-0007yB-00; Thu, 19 Aug 2004 15:17:11 +0100
Received: from dom by arsenal.mips.com with local (Exim 3.35 #1 (Debian))
	id 1Bxnj4-0001MT-00; Thu, 19 Aug 2004 15:17:10 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16676.46694.564448.344602@arsenal.mips.com>
Date: Thu, 19 Aug 2004 15:17:10 +0100
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
In-Reply-To: <20040804152936.D6269@mvista.com>
References: <20040804152936.D6269@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.348, required 4, AWL,
	BAYES_00, J_BACKHAIR_46)
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: 5686
X-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


Jun Sun,

> I am looking into porting NPTL to MIPS.  Just curious if
> anybody has tried this before.
> 
> I notice there was a discussion about the ABI extension
> for TLS (thread local storage) support.  Before that support
> becomes a reality it seems one can still use NPTL with 
> the help of additional system calls.

Well, this is an area of substantial interest to MIPS Technologies.
We are working on our multi-threading extension to the MIPS
architecture, and one of our longer-term aims is to achieve really
good NPTL performance.

As you said, this motivates a revision of the ABI.  Any incompatible
change to the ABI is painful, since everything has to be recompiled;
so our reasoning at the moment is that we might as well be radical...

MIPS Technologies would write up the definition; make and circulate
changes to the compiler, binutils and debugger; and make and circulate
supporting changes to the kernel and glibc.  We're aware this is only
a part of the problem, so we do need to figure out what will attract
community approval.

A few years ago I was volubly arguing in favour of keeping o32 until
we could move to n32/n64.  But times change: SGI compatibility
no longer seems important, and Linux on 32-bit MIPS CPUs needs
long-term support.

In many ways it's easier to get away from the ingenious but
troublesome stack-structure-based calling convention.  The "stack
structure" trick was invented so that o32 could work without function
prototypes - but function prototypes are now required, and something
with fixed-size arguments is simpler.  Something like the old
Cygnus/WRS EABI proposal, in fact...

So we're proposing:

o The register name<->number mapping is that of n64.

o Calling convention: register-, not slot-based. Each argument is
  represented by a register value. Arguments 0-7 travel in registers
  a0-7 (or fa0-7 as required for floating point types). If there are
  more than eight arguments, further ones are formed as if put in a
  register and then saved on the stack into a 64-bit slot (more than 8
  arguments is rare enough that we can afford to standardise on the
  big slots).
  
o Use floating point registers for double and float arguments, and
  integer registers for all integer/pointer values which will
  fit. Larger or structured data items are implicitly passed by
  reference: to maintain pass-by-value semantics, the compiler uses a
  copy-on-write trick if software writes a by-reference argument (or
  takes its address).  I'm told gcc is happy enough to do that.

o The return value comes back in two registers, with the second
  return-register used only when the return value consists of two
  scalars (ie a complex or double-precision number). [Folklore insists
  this is essential for Fortran support of complex numbers, and I
  don't want to fight folklore].

  All other non-scalar return values are returned via a pointer
  specified by the caller as an implicit first argument.

o Reserved registers: all the traditional ones. But now:

  - gp will be the GOT pointer in Linux, and should be defined as
    saved (ie a function must preserve values in this registers, which
    means it will need to save-and-restore the register if it is
    written locally).
    
  - we'll define some other register as a per-thread data pointer.

Some details are still to be worked out.  But do you think this is on
the right lines?  And who would like to take an active part in
specifying or reviewing?

--
Dominic Sweetman
MIPS Technologies


From a.voropay@vmb-service.ru Thu Aug 19 15:30:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Aug 2004 15:30:19 +0100 (BST)
Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:12224 "EHLO
	smtp.vmb-service.ru") by linux-mips.org with ESMTP
	id <S8224912AbUHSOaP>; Thu, 19 Aug 2004 15:30:15 +0100
Received: from office.vmb-service.ru ([80.73.192.47]:25349 "HELO portege")
	by Altair with SMTP id <S1274428AbUHSO37>;
	Thu, 19 Aug 2004 18:29:59 +0400
Message-ID: <006f01c485f9$41348b50$3c01a8c0@portege>
From: "Alec Voropay" <a.voropay@vmb-service.ru>
To: "Dominic Sweetman" <dom@mips.com>
Cc: <linux-mips@linux-mips.org>
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com>
Subject: Re: anybody tried NPTL?
Date: Thu, 19 Aug 2004 18:31:45 +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 5.50.4942.400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400
Return-Path: <a.voropay@vmb-service.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: 5687
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: a.voropay@vmb-service.ru
Precedence: bulk
X-list: linux-mips


> Well, this is an area of substantial interest to MIPS Technologies.
> We are working on our multi-threading extension to the MIPS
> architecture, and one of our longer-term aims is to achieve really
> good NPTL performance.

 Sorry for a bit offtopic..., as far as I remember, the Windows NT
MIPS edition has a working multithread implementation. Is this
implementation very copyrighted and is it possible to use something
ftom there for the NPTL implementation ?




--
-=AV=-


From ddaney@avtrex.com Thu Aug 19 17:04:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Aug 2004 17:04:41 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:1882 "EHLO avtrex.com")
	by linux-mips.org with ESMTP id <S8224930AbUHSQEg>;
	Thu, 19 Aug 2004 17:04:36 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 19 Aug 2004 09:01:24 -0700
Message-ID: <4124CED5.1020608@avtrex.com>
Date: Thu, 19 Aug 2004 09:01:25 -0700
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dominic Sweetman <dom@mips.com>
CC: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com>
In-Reply-To: <16676.46694.564448.344602@arsenal.mips.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Aug 2004 16:01:24.0698 (UTC) FILETIME=[C720A3A0:01C48605]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5688
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

Dominic Sweetman wrote:
> So we're proposing:
> 
> o The register name<->number mapping is that of n64.
> 
> o Calling convention: register-, not slot-based. Each argument is
>   represented by a register value. Arguments 0-7 travel in registers
>   a0-7 (or fa0-7 as required for floating point types). If there are
>   more than eight arguments, further ones are formed as if put in a
>   register and then saved on the stack into a 64-bit slot (more than 8
>   arguments is rare enough that we can afford to standardise on the
>   big slots).
>   
> o Use floating point registers for double and float arguments, and
>   integer registers for all integer/pointer values which will
>   fit. Larger or structured data items are implicitly passed by
>   reference: to maintain pass-by-value semantics, the compiler uses a
>   copy-on-write trick if software writes a by-reference argument (or
>   takes its address).  I'm told gcc is happy enough to do that.
> 
> o The return value comes back in two registers, with the second
>   return-register used only when the return value consists of two
>   scalars (ie a complex or double-precision number). [Folklore insists
>   this is essential for Fortran support of complex numbers, and I
>   don't want to fight folklore].
> 
>   All other non-scalar return values are returned via a pointer
>   specified by the caller as an implicit first argument.
> 
> o Reserved registers: all the traditional ones. But now:
> 
>   - gp will be the GOT pointer in Linux, and should be defined as
>     saved (ie a function must preserve values in this registers, which
>     means it will need to save-and-restore the register if it is
>     written locally).
>     
>   - we'll define some other register as a per-thread data pointer.
> 
> Some details are still to be worked out.  But do you think this is on
> the right lines?  And who would like to take an active part in
> specifying or reviewing?
> 
All of this sounds good to me.  However my current concerns are how to
make my code run on a mips32[r2] core with no floating point.  We are
using several different systems with variations of this cpu type.

So for me, making sure that a soft-float variant of the ABI is well
specified is also important.  I suppose it would be to treat
float/double values as appropriate encoding of 32/64 bit integer values.

David Daney.


From ralf@linux-mips.org Thu Aug 19 21:14:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Aug 2004 21:14:20 +0100 (BST)
Received: from p508B7861.dip.t-dialin.net ([IPv6:::ffff:80.139.120.97]:24685
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225011AbUHSUOQ>; Thu, 19 Aug 2004 21:14:16 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7JKE9R8032683;
	Thu, 19 Aug 2004 22:14:09 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7JKE8r2032682;
	Thu, 19 Aug 2004 22:14:08 +0200
Date: Thu, 19 Aug 2004 22:14:08 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] ioc3-eth.c: add missing pci_enable_device()
Message-ID: <20040819201408.GA32343@linux-mips.org>
References: <200408041538.21128.bjorn.helgaas@hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200408041538.21128.bjorn.helgaas@hp.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: 5689
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Aug 04, 2004 at 03:38:21PM -0600, Bjorn Helgaas wrote:

> I don't have this hardware, so this has not been tested.

Sure, it's SGI hw ;-)

> Add pci_enable_device()/pci_disable_device().  In the past, drivers
> often worked without this, but it is now required in order to route
> PCI interrupts correctly.

Applied.

  Ralf

From jsun@mvista.com Thu Aug 19 23:16:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Aug 2004 23:16:55 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:39153 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224990AbUHSWQt>;
	Thu, 19 Aug 2004 23:16:49 +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 i7JMGk7T008908;
	Thu, 19 Aug 2004 15:16:46 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i7JMGkH8008907;
	Thu, 19 Aug 2004 15:16:46 -0700
Date: Thu, 19 Aug 2004 15:16:46 -0700
From: Jun Sun <jsun@mvista.com>
To: Dominic Sweetman <dom@mips.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: anybody tried NPTL?
Message-ID: <20040819221646.GC8737@mvista.com>
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16676.46694.564448.344602@arsenal.mips.com>
User-Agent: Mutt/1.4i
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5690
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Aug 19, 2004 at 03:17:10PM +0100, Dominic Sweetman wrote:
> 
> Jun Sun,
> 
> > I am looking into porting NPTL to MIPS.  Just curious if
> > anybody has tried this before.
> > 
> > I notice there was a discussion about the ABI extension
> > for TLS (thread local storage) support.  Before that support
> > becomes a reality it seems one can still use NPTL with 
> > the help of additional system calls.
> 
> Well, this is an area of substantial interest to MIPS Technologies.
> We are working on our multi-threading extension to the MIPS
> architecture, and one of our longer-term aims is to achieve really
> good NPTL performance.
> 
> As you said, this motivates a revision of the ABI.  Any incompatible
> change to the ABI is painful, since everything has to be recompiled;
> so our reasoning at the moment is that we might as well be radical...
> 
> MIPS Technologies would write up the definition; make and circulate
> changes to the compiler, binutils and debugger; and make and circulate
> supporting changes to the kernel and glibc.  We're aware this is only
> a part of the problem, so we do need to figure out what will attract
> community approval.
> 
> A few years ago I was volubly arguing in favour of keeping o32 until
> we could move to n32/n64.  But times change: SGI compatibility
> no longer seems important, and Linux on 32-bit MIPS CPUs needs
> long-term support.
> 
> In many ways it's easier to get away from the ingenious but
> troublesome stack-structure-based calling convention.  The "stack
> structure" trick was invented so that o32 could work without function
> prototypes - but function prototypes are now required, and something
> with fixed-size arguments is simpler.  Something like the old
> Cygnus/WRS EABI proposal, in fact...
> 
> So we're proposing:
> 
> o The register name<->number mapping is that of n64.
> 
> o Calling convention: register-, not slot-based. Each argument is
>   represented by a register value. Arguments 0-7 travel in registers
>   a0-7 (or fa0-7 as required for floating point types). If there are
>   more than eight arguments, further ones are formed as if put in a
>   register and then saved on the stack into a 64-bit slot (more than 8
>   arguments is rare enough that we can afford to standardise on the
>   big slots).
>   
> o Use floating point registers for double and float arguments, and
>   integer registers for all integer/pointer values which will
>   fit. Larger or structured data items are implicitly passed by
>   reference: to maintain pass-by-value semantics, the compiler uses a
>   copy-on-write trick if software writes a by-reference argument (or
>   takes its address).  I'm told gcc is happy enough to do that.
> 
> o The return value comes back in two registers, with the second
>   return-register used only when the return value consists of two
>   scalars (ie a complex or double-precision number). [Folklore insists
>   this is essential for Fortran support of complex numbers, and I
>   don't want to fight folklore].
> 
>   All other non-scalar return values are returned via a pointer
>   specified by the caller as an implicit first argument.
> 
> o Reserved registers: all the traditional ones. But now:
> 
>   - gp will be the GOT pointer in Linux, and should be defined as
>     saved (ie a function must preserve values in this registers, which
>     means it will need to save-and-restore the register if it is
>     written locally).
>     
>   - we'll define some other register as a per-thread data pointer.
> 
> Some details are still to be worked out.  But do you think this is on
> the right lines?  And who would like to take an active part in
> specifying or reviewing?
>

I am not against any of those.  However, from NPTL implementation
point of view I really just care about the per-thread register.
What is the motivation of other changes?  Taking this chance to make
things all right in one shot?

Jun

From safiudeen@hotmail.com Fri Aug 20 06:20:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 06:20:13 +0100 (BST)
Received: from bay15-f16.bay15.hotmail.com ([IPv6:::ffff:65.54.185.16]:32781
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8224952AbUHTFUG>; Fri, 20 Aug 2004 06:20:06 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 19 Aug 2004 22:19:54 -0700
Received: from 220.247.240.49 by by15fd.bay15.hotmail.msn.com with HTTP;
	Fri, 20 Aug 2004 05:19:53 GMT
X-Originating-IP: [220.247.240.49]
X-Originating-Email: [safiudeen@hotmail.com]
X-Sender: safiudeen@hotmail.com
From: "safiudeen Ts" <safiudeen@hotmail.com>
To: linux-mips@linux-mips.org, ecartis@linux-mips.org
Cc: safiudeen@hotmail.com
Subject: PCMCIA genric sreail or modem support for db1100 bord
Date: Fri, 20 Aug 2004 05:19:53 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY15-F16oYe5yBEwlu0002e857@hotmail.com>
X-OriginalArrivalTime: 20 Aug 2004 05:19:54.0388 (UTC) FILETIME=[53872D40:01C48675]
Return-Path: <safiudeen@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5691
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: safiudeen@hotmail.com
Precedence: bulk
X-list: linux-mips

I am trying to make a pcmcia serial card to work with DB 1100 development 
bord mips prcessor mips au1100 runnning on linux 2.4.20
same pcmcia serial card works fine with my laptop running on linux 2.4.20-8

when try with db1100 it look like hanging in close
the test results are as follows

1) when I plug the card, cardmanegr start  it gives thettyS4 at  port 
0xc00703f8 and the irq 34
2) then card manager calls /etc/pcmcia/serial start /dev/ttvS4
   here it try to set the irq with o through the setserial,this give 
"resource busy or unavailable error"
3)I changed /etc/pcmcia/serial so that   setserial in /etc/pcmcia/serial can 
set irq 3
   after this when I remove the card and plug again, same port number and 
irq is set, then
        /etc/pcmcia/serial start /dev/ttvS4 runs , here it wait until press 
enter to return to prompt
4) now I used set seril to see the status out put is this

# setserial -a /dev/ttyS4
/dev/ttyS4, Line 4, UART: 16550, Port: 0xc00703f8, IRQ: 34
        Baud_base: 6188044, close_delay: 50, divisor: 0
        closing_wait: 3000, closing_wait2: infinte
        Flags: spd_normal skip_tes

and I checked /var/run/stab  this is the out put
# cat /var/run/stab
Socket 0: Serial or Modem
0       serial  serial_cs       0       ttyS4   4       68
Socket 1: empty

at this place evry thing look like ok
5) I run a smale serial prot test program it set the boud rate 9600, data 
bit 8 stop bit 1 , no parity
        , open the ttyS4 with the following options O_RDWR | O_NOCTTY | 
O_NONBLOCK
        write teststring of correctors to the ttyS4, and close.
        open and write functions return no error, the write function retunr 
the no. of bit writen correctly
        close function hangs here I connected other side of the serial port 
to a pc and started the minicom here I did'nt get any charecter writen to 
the port

6) I checked there irq usage in /proc/interrupts this is the result
cat /proc/interrupts

# cat /proc/interrupts
           CPU0
  0:      11914    Au1000 Level  serial
  2:          0    Au1000 Level  MMC
  6:          0    Au1000 Level  audio DAC
  7:          0    Au1000 Level  audio ADC
  8:          0    Au1000 Level  EP0 IN WR
  9:          0    Au1000 Level  EP1 IN WR
10:          0    Au1000 Level  EP2 IN WR
22:      22518    Au1000 Level  irda0
23:          0    Au1000 Level  irda0
24:          0  Au1000 Rise Edge  AU1100UDC Req
25:          0  Au1000 Rise Edge  AU1100UDC Sus
26:          0    Au1000 Level  usb-ohci
28:       8155    Au1000 Level  eth0
34:          0    Au1000 Level  serial

ERR:          0

it shows no any interupts happen to 34,
what should be the real problem ? if any one succeded in PCMCIA up with 
db1100 development please can you tell me the way to
configure the kernela and the the importan settings

if anyone succeded in bringing up PCMCIA serial or modem driver serial_cs 
working with this plartform
please help me in this regards

thanx
safiudeen

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail


From dom@mips.com Fri Aug 20 07:07:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 07:07:20 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:60433 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224791AbUHTGHQ>;
	Fri, 20 Aug 2004 07:07:16 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1By2jO-0008Vf-00; Fri, 20 Aug 2004 07:18:30 +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 1By2YE-0003C5-00; Fri, 20 Aug 2004 07:06:58 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16677.38151.342836.702112@doms-laptop.algor.co.uk>
Date: Thu, 19 Aug 2004 23:07:03 -0700
To: "Alec Voropay" <a.voropay@vmb-service.ru>
Cc: "Dominic Sweetman" <dom@mips.com>, <linux-mips@linux-mips.org>
Subject: Re: anybody tried NPTL?
In-Reply-To: <006f01c485f9$41348b50$3c01a8c0@portege>
References: <20040804152936.D6269@mvista.com>
	<16676.46694.564448.344602@arsenal.mips.com>
	<006f01c485f9$41348b50$3c01a8c0@portege>
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.348, required 4, AWL,
	BAYES_00, MICROSOFT)
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: 5692
X-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


Alec,

> > We are working on our multi-threading extension to the MIPS
> > architecture, and one of our longer-term aims is to achieve really
> > good NPTL performance.
> 
> Sorry for a bit offtopic..., as far as I remember, the Windows NT
> MIPS edition has a working multithread implementation. Is this
> implementation very copyrighted and is it possible to use something
> ftom there for the NPTL implementation ?

It's Microsoft, so yes it will be copyrighted and it would be better
if our staff didn't even look at it.

--
Dominic Sweetman
MIPS Technologies



From dom@mips.com Fri Aug 20 07:19:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 07:19:50 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:14099 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224791AbUHTGTp>;
	Fri, 20 Aug 2004 07:19:45 +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 1By2vT-0000Jz-00; Fri, 20 Aug 2004 07:30:59 +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 1By2kF-0003a7-00; Fri, 20 Aug 2004 07:19:24 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16677.38895.779836.353523@doms-laptop.algor.co.uk>
Date: Thu, 19 Aug 2004 23:19:27 -0700
To: David Daney <ddaney@avtrex.com>
Cc: Dominic Sweetman <dom@mips.com>, Jun Sun <jsun@mvista.com>,
	linux-mips@linux-mips.org, Nigel Stephens <nigel@mips.com>
Subject: Re: anybody tried NPTL?
In-Reply-To: <4124CED5.1020608@avtrex.com>
References: <20040804152936.D6269@mvista.com>
	<16676.46694.564448.344602@arsenal.mips.com>
	<4124CED5.1020608@avtrex.com>
X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.847, 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: 5693
X-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


David Daney (ddaney@avtrex.com) writes:

> All of this sounds good to me.  However my current concerns are how to
> make my code run on a mips32[r2] core with no floating point.  We are
> using several different systems with variations of this cpu type.
> 
> So for me, making sure that a soft-float variant of the ABI is well
> specified is also important.  I suppose it would be to treat
> float/double values as appropriate encoding of 32/64 bit integer values.

Exactly - that's certainly what we do with o32 -msoft-float.  I don't
think there are even any corner cases to worry about.

We've recently made some major improvements to our soft maths library
to make it many times faster, but still IEEE-compliant.  It was
originally written by Algorithmics - a GPL'd version is used in the
Linux/MIPS kernel to handle FPU exceptions.  I should probably check
before saying for certain, but I think we will distribute this under
straight GPL conditions.

If we had the time to do it, I guess we should put it on one of the OS
project sites... but I'll cc: Nigel Stephens (who wrote it).  If it
might be of use to you (which seems quite likely) perhaps we could do
a deal to get it on a site somewhere?  Let me know if you'd like sight
of it.

--
Dominic




From ralf@linux-mips.org Fri Aug 20 09:18:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 09:18:46 +0100 (BST)
Received: from p508B7A8B.dip.t-dialin.net ([IPv6:::ffff:80.139.122.139]:37493
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224791AbUHTISl>; Fri, 20 Aug 2004 09:18:41 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7K8IX7C017370;
	Fri, 20 Aug 2004 10:18:33 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7K8IW2Z017369;
	Fri, 20 Aug 2004 10:18:32 +0200
Date: Fri, 20 Aug 2004 10:18:32 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Srinivas Kommu <kommu@hotmail.com>, linux-mips@linux-mips.org
Subject: Re: mips32 kernel memory mapping
Message-ID: <20040820081832.GD15543@linux-mips.org>
References: <BAY1-F25sCR6nWqNG2Y00092cf9@hotmail.com> <Pine.LNX.4.58L.0407231348580.5644@blysk.ds.pg.gda.pl> <20040723202439.GA3711@linux-mips.org> <Pine.LNX.4.58L.0407261258010.3873@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58L.0407261258010.3873@blysk.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: 5694
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Jul 26, 2004 at 01:23:41PM +0200, Maciej W. Rozycki wrote:

> > There is a general perception among Linux users that 64-bit is new an
> > not really needed which in part I blame on the bs Intel is spreading to
> > hide the fact that for a long time they simply had no 64-bit roadmap at
> > all.
> 
>  Huh?  How's Intel's policy related to 64-bit Linux?  Especially for other
> processors, like MIPS.

Their wrong claims that only server machines need 64-bit.

>  Linux has supported 64-bit operation since ~1995 and around 1998 when I
> had an opportunity to use it on DEC Alpha, it (2.0.x) was already stable
> enough for regular use.  That is the generic core and the Alpha bits, of
> course -- the maturity of other processor support may vary, but for MIPS
> it's not worse than the 32-bit support.

At least after I fixed kernel mode page tables last week.  The 4MB limit
we had before that was just ridiculous.

> > There are still improvments to be made for BCM1250 support.  Somebody
> > thought scattering the first 1GB of memory through the lowest 4GB of
> > physical address space like a three year old his toys over the floor
> > was a good thing ...  The resulting holes in the memory map are wasting
> > significant amounts of memory for unused memory; the worst case number
> > that is reached for 64-bit kernel on a system with > 1GB of RAM is 96MB!
> 
>  Well, there are some resons given in the manual.  Anyway, memory seems to
> be remappable to 0x100000000 in the DRAM controller.  Still we probably
> have to keep low 256MB mapped and registered within Linux at 0 for bounce
> buffers for broken PCI hardware ("hidden" mapping for exception handlers 
> and kernel segments would be easier).
> 
>  With only 256MB installed in my system it would be tough for me to code
> anything interesting, though.  Perhaps another time.

I have 1GB and that's where 32-bit kernels are beginning to look really
like a bad idea on MIPS.  Fortunately on the BCM1250 and all the other
64-bit processors there is an easy way out.  Better even, some of the
embedded application performance numbers suggest significant performance
gains for 64-bit processing contrary to conventional wisdom about 64-bit
computing.

  Ralf

From safiudeen@hotmail.com Fri Aug 20 09:51:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 09:51:51 +0100 (BST)
Received: from bay15-f25.bay15.hotmail.com ([IPv6:::ffff:65.54.185.25]:16908
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8224791AbUHTIvr>; Fri, 20 Aug 2004 09:51:47 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 20 Aug 2004 01:51:39 -0700
Received: from 220.247.240.49 by by15fd.bay15.hotmail.msn.com with HTTP;
	Fri, 20 Aug 2004 08:51:39 GMT
X-Originating-IP: [220.247.240.49]
X-Originating-Email: [safiudeen@hotmail.com]
X-Sender: safiudeen@hotmail.com
From: "safiudeen Ts" <safiudeen@hotmail.com>
To: michael.stickel@4g-systems.biz, linux-mips@linux-mips.org
Subject: Re: PCMCIA genric sreail or modem support for db1100 bord
Date: Fri, 20 Aug 2004 08:51:39 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY15-F253abTd9QkTD0002f560@hotmail.com>
X-OriginalArrivalTime: 20 Aug 2004 08:51:39.0980 (UTC) FILETIME=[E8A6A8C0:01C48692]
Return-Path: <safiudeen@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5695
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: safiudeen@hotmail.com
Precedence: bulk
X-list: linux-mips

built in serial ports are working fine in DB1100 with linux-2.4.20 kernel
When we use a pcmcia serial card or modem, for most of the card, cardmaneger 
load serial_cs.o (actualy it uses the serial.o  fetures for registering the 
module).
This method work fine in my laptop.
same think hepens in db1100 bord also. I gues serial.o in bord db110 does'nt 
support well for serial_cs
.
If there is a stand alon serial_cs.o module for this board It may work 
without any problem.
if it is os where  can I get the seria_cs or any generic serial pcmcia 
driver for db1100 bord, or  otherwise is any serial.c available for db1100 
that can support pcmcia and inbuild serial as it works in labtop.

There is important think, when we connected in the laptop this pcmcia serial 
card detect is detected as 65550A but in the board it detected as 65550. I 
checked the serial.c code of db1100 there is no entry for this 65550A.

if any one worked with this DB1100 please help me to solve this problem


thanx
safiudeen

&gt;From: Michael Stickel &lt;michael.stickel@4g-systems.biz&gt;
&gt;To: &quot;safiudeen Ts&quot; &lt;safiudeen@hotmail.com&gt;
&gt;Subject: Re: PCMCIA genric sreail or modem support for db1100 bord
&gt;Date: Fri, 20 Aug 2004 10:07:40 +0200
&gt;
&gt;
&gt;Do you use the buildin serial ports?
&gt;
&gt;My last information is that the au1x00-serial module does not work
&gt;in parallel with the serial module because au1x00-serial.c is just a
&gt;modified copy of serial.c.
&gt;
&gt;Michael
&gt;

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


From joey@infodrom.org Fri Aug 20 11:47:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 11:47:40 +0100 (BST)
Received: from luonnotar.infodrom.org ([IPv6:::ffff:195.124.48.78]:24078 "EHLO
	luonnotar.infodrom.org") by linux-mips.org with ESMTP
	id <S8224911AbUHTKrg>; Fri, 20 Aug 2004 11:47:36 +0100
Received: by luonnotar.infodrom.org (Postfix, from userid 10)
	id 22E95366B8C; Fri, 20 Aug 2004 12:47:34 +0200 (CEST)
Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2)
	from infodrom.org by finlandia.Infodrom.North.DE
	via smail from stdin
	id <m1By6nG-000olzC@finlandia.Infodrom.North.DE>
	for linux-mips@linux-mips.org; Fri, 20 Aug 2004 12:38:46 +0200 (CEST) 
Date: Fri, 20 Aug 2004 12:38:46 +0200
From: Martin Schulze <joey@infodrom.org>
To: Linux for m68k <linux-m68k@phil.uni-sb.de>,
	Linux for MIPS <linux-mips@linux-mips.org>,
	Linux for PA-RISC <parisc-linux@lists.parisc-linux.org>,
	Linux for Powerpc <linuxppc-dev@lists.linuxppc.org>,
	Debian M68k Development <debian-68k@lists.debian.org>,
	Debian MIPS Development <debian-mips@lists.debian.org>,
	Debian PA-RISC Development <debian-hppa@lists.debian.org>,
	Debian Powerpc Development <debian-powerpc@lists.debian.org>,
	Debian ARM Development <debian-arm@lists.debian.org>
Subject: Invitation to the Oldenburg Linux Developers Meeting #9
Message-ID: <20040820103846.GZ1784@finlandia.infodrom.north.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.6+20040803i
Return-Path: <joey@infodrom.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: 5696
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joey@infodrom.org
Precedence: bulk
X-list: linux-mips

Moin!

       Invitation to the Oldenburg Linux Developers Meeting #9
       -------------------------------------------------------

Executive summary:

URL:   http://oldenburger.linuxtage.de/Oldenburg2004/
What:  Oldenburg Linux Developers Meeting #9
Who:   Every developer interested in Linux on non-i386 platforms
       Every developer interested in developing the debian-installer
When:  September, 22nd to 26th (Wednesday noon to Sunday afternoon)
Where: University of Oldenburg, science building in Oldenburg Wechloy
Orga:  ffis e.V., Martin 'Joey' Schulze


Keeping the tradition alive we will organise another Linux developers
meeting in Oldenburg this year at the last weekend of September.  This
year, however, we will be able to use the facility from Wednesday to
Sunday, hence, one day longer than before.

There were loud complaints last year about the meeting being too
short, so it will be extended by one day this time.  The meeting will
take place at the University of Oldenburg in the scientific building
in Oldenburg Wechloy.

the goal of this developers meeting is to provide developers a means
to work in common on the non-i386 Linux ports and related topics and
to further the exchange of ideas and discussion about the several
ports.

We will have dedicated working and sleeping rooms as before.  We
should be able to use three more rooms during the nights in case the
number of attending developers is too high for the two dedicated
sleeping rooms.  We will be able to use the shower facility of the
sports department nearby.

This year Debian developers will join us again for work on the new
debian-installer.  They will probably want to test the installer on
some "obscure" hardware they don't normally have access to, so don't
worry if you should receive such a request.

We will have dinner together in a restaurant in the evening.  A
preliminary plan is on the web already, but the restaurants and the
order may still change.  We will have a barbecue on Friday for this is
the tenth developers meeting already.

As usual we will have a never-ending breakfast in the large working
room.  I will get rolls each morning and ensure that there will be
butter, cheese, saussages, jam, Nutella and stuff.  I'll also take
care of non-alcoholic fluids.

Attendance is free of cost including food and beverage in the working
rooms (although we are always thankful for donations, EUR 10-20 per
person should cover the expenses).  However, for the barbecue on
Friday instead of a restaurant we would be thankful if you could take
a stake in the expenses, EUR 5-10 should cover the costs.

Beside machines, equipment and documentation you'll need to take with
you a sleeping bag, maybe a camping mat or cot, towels, shower suff,
personal toilett stuff, maybe medicine, clothes, mug and plate are
optional but helpful.

You'll find routing information on the website mentioned above.

If you would like to attend the meeting, please send back the
following form, so that we can calculate space, power and food.

Name ................:

Date of arrival .....: ( ) Wednesday, Sep, 22nd
                       ( ) Thursday, Sep, 23rd
                       ( ) Friday, Sep, 24th 
                       ( ) Saturday, Sep, 25th

Date of departure ...: ( ) Friday, Sep. 24th
                       ( ) Saturday, Sep. 25th
                       ( ) Sunday, Sep. 26th

[ ] Vegetarian (only needed for the barbecue)

___ usable seats in my car, once arrived (only if you come by car)

Special requirements for food: ______________________

If you come by train/plane and want me to pick up up in Bremen or
Oldenburg, please drop me the exact arrival and departure times as
well.

If you have any further questions, please don't hesitate to ask me.

Regards,

	Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erdös

Please always Cc to me when replying to me on the lists.

From joey@infodrom.org Fri Aug 20 12:28:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 12:28:18 +0100 (BST)
Received: from luonnotar.infodrom.org ([IPv6:::ffff:195.124.48.78]:37390 "EHLO
	luonnotar.infodrom.org") by linux-mips.org with ESMTP
	id <S8225200AbUHTL2N>; Fri, 20 Aug 2004 12:28:13 +0100
Received: by luonnotar.infodrom.org (Postfix, from userid 10)
	id BE002366B7C; Fri, 20 Aug 2004 13:28:05 +0200 (CEST)
Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2)
	from infodrom.org by finlandia.Infodrom.North.DE
	via smail from stdin
	id <m1By7ST-000olzC@finlandia.Infodrom.North.DE>
	for linux-mips@linux-mips.org; Fri, 20 Aug 2004 13:21:21 +0200 (CEST) 
Date: Fri, 20 Aug 2004 13:21:21 +0200
From: Martin Schulze <joey@infodrom.org>
To: Linux for m68k <linux-m68k@phil.uni-sb.de>,
	Linux for MIPS <linux-mips@linux-mips.org>,
	Linux for PA-RISC <parisc-linux@lists.parisc-linux.org>,
	Linux for Powerpc <linuxppc-dev@lists.linuxppc.org>,
	Debian M68k Development <debian-68k@lists.debian.org>,
	Debian MIPS Development <debian-mips@lists.debian.org>,
	Debian PA-RISC Development <debian-hppa@lists.debian.org>,
	Debian Powerpc Development <debian-powerpc@lists.debian.org>,
	Debian ARM Development <debian-arm@lists.debian.org>
Subject: Re: Invitation to the Oldenburg Linux Developers Meeting #9
Message-ID: <20040820112121.GA32210@finlandia.infodrom.north.de>
References: <20040820103846.GZ1784@finlandia.infodrom.north.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20040820103846.GZ1784@finlandia.infodrom.north.de>
User-Agent: Mutt/1.5.6+20040803i
Return-Path: <joey@infodrom.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: 5697
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joey@infodrom.org
Precedence: bulk
X-list: linux-mips

Martin Schulze wrote:
> Moin!
> 
>        Invitation to the Oldenburg Linux Developers Meeting #9
>        -------------------------------------------------------
> 
> Executive summary:
> 
> URL:   http://oldenburger.linuxtage.de/Oldenburg2004/

Correct URL is <http://meeting.ffis.de/Oldenburg2004/>.  The above
domain got lost unfortunately.

> What:  Oldenburg Linux Developers Meeting #9
> Who:   Every developer interested in Linux on non-i386 platforms
>        Every developer interested in developing the debian-installer
> When:  September, 22nd to 26th (Wednesday noon to Sunday afternoon)
> Where: University of Oldenburg, science building in Oldenburg Wechloy
> Orga:  ffis e.V., Martin 'Joey' Schulze

> If you would like to attend the meeting, please send back the
> following form, so that we can calculate space, power and food.
> 
> Name ................:
> 
> Date of arrival .....: ( ) Wednesday, Sep, 22nd
>                        ( ) Thursday, Sep, 23rd
>                        ( ) Friday, Sep, 24th 
>                        ( ) Saturday, Sep, 25th
> 
> Date of departure ...: ( ) Friday, Sep. 24th
>                        ( ) Saturday, Sep. 25th
>                        ( ) Sunday, Sep. 26th
> 
> [ ] Vegetarian (only needed for the barbecue)
> 
> ___ usable seats in my car, once arrived (only if you come by car)
> 
> Special requirements for food: ______________________
> 
> If you come by train/plane and want me to pick up up in Bremen or
> Oldenburg, please drop me the exact arrival and departure times as
> well.
> 
> If you have any further questions, please don't hesitate to ask me.

Regards,

	Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erdös

Please always Cc to me when replying to me on the lists.

From ralf@linux-mips.org Fri Aug 20 13:05:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 13:05:32 +0100 (BST)
Received: from p508B7A8B.dip.t-dialin.net ([IPv6:::ffff:80.139.122.139]:31096
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224911AbUHTMF2>; Fri, 20 Aug 2004 13:05:28 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7KC5Qto003567;
	Fri, 20 Aug 2004 14:05:26 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7KC5Qug003566;
	Fri, 20 Aug 2004 14:05:26 +0200
Date: Fri, 20 Aug 2004 14:05:26 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Song Wang <wsonguci@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Should #ifdef __KERNEL__ be added before #include <spaces.h> in asm-mips/addrspace.h ?
Message-ID: <20040820120526.GA27130@linux-mips.org>
References: <20040721000356.39366.qmail@web40003.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040721000356.39366.qmail@web40003.mail.yahoo.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5698
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jul 20, 2004 at 05:03:56PM -0700, Song Wang wrote:

> Should #ifdef _KERNEL__ be added before #include
> <spaces.h> in asm-mips/addrspace.h?
> 
> I think the reason is the same as when you added
> the #ifdef __KERNEL__ before #include <spaces.h>
> for asm-mips/page.h.

Some userspace software is expecting to get PAGE_SHIFT, PAGE_SIZE and
PAGE_MASK to be available in userspace via <asm/page.h>, so I
protected the inclusion of <asm/spaces.h> with __KERNEL__ but left
the definitions of these symbols unprotected.

  Ralf

From mike@cogcomp.com Fri Aug 20 13:59:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 13:59:48 +0100 (BST)
Received: from lakecmmtao02.coxmail.com ([IPv6:::ffff:68.99.120.69]:12488 "EHLO
	lakecmmtao02.coxmail.com") by linux-mips.org with ESMTP
	id <S8224911AbUHTM7o>; Fri, 20 Aug 2004 13:59:44 +0100
Received: from mike_desktop.cogcomp.com ([68.15.41.55])
          by lakecmmtao02.coxmail.com
          (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP
          id <20040820125935.ZULV6960.lakecmmtao02.coxmail.com@mike_desktop.cogcomp.com>;
          Fri, 20 Aug 2004 08:59:35 -0400
Message-Id: <6.0.3.0.2.20040820085527.066ee1c0@pop3.cedata.com>
X-Sender: cogent@cogcomp.com@pop3.cedata.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0
Date: Fri, 20 Aug 2004 08:59:12 -0400
To: "safiudeen Ts" <safiudeen@hotmail.com>
From: Michael Kelly <mike@cogcomp.com>
Subject: Re: PCMCIA genric sreail or modem support for db1100 bord
Cc: michael.stickel@4g-systems.biz, linux-mips@linux-mips.org
In-Reply-To: <BAY15-F253abTd9QkTD0002f560@hotmail.com>
References: <BAY15-F253abTd9QkTD0002f560@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Return-Path: <mike@cogcomp.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5699
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mike@cogcomp.com
Precedence: bulk
X-list: linux-mips

Safiudeen,

There is a known problem with some 8-bit cards and the Au1xxx family.
The following is from the FAQ for Linux that comes with the DB1100 CD:

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

25) Which PCMCIA cards work with Au1x00/Pb1x00 Linux?

The Au1x00/Pb1x00 Linux PCMCIA cardmgr has been tested and known to
work with the following PC Cards.  The Linux PCMCIA driver module is
listed to the left:

   ide_cs.o Ritek Corporation, ATA DISK drive (3.3V Compact Flash Adapter)
   ide_cs.o Butterfly Group 64M ATA disk drive (3.3V)
   ide_cs.o SanDisk 192MB FlashDisk ATA (3.3/5V)
   ide_cs.o SanDisk 10MB FlashDisk ATA (5V)
   ide_cs.o Hitach 64MB flash card (3.3/5V)
   ide_cs.o IO Data 256MB flash card (3.3/5V)
   ide_cs.o Toshiba 2GB hard drive (actual tiny drive, like the IBM 
MicroDrive) (3.3V/5V)
   ide_cs.o IBM Microdrive
   3c589.o  3COM 589 Ethernet card (5V)
   pcnet_cs.o Linksys Network Everywhere NP10T
   pcnet_cs.o Corega Ether PCC-TD
   pcnet_cs.o Corega FEther PCC-TXD
   pcnet_cs.o Laneed LD-CDL/T
   axnet_cs.o Buffalo Tough Connect LPC3-CLX

NOTE: The Au1000 and Au1500 require an 8-bit PCMCIA HBA work around
be implemented on the board in order for 8-bit cards (i.e. pcnet_cs.o)
to work properly. See app note "Au1000 8-bit PCMCIA HBA".

============================================================\

IIRC most serial cards are 8-bit.

Hope this helps,

Michael

At 04:51 AM 8/20/2004, safiudeen Ts wrote:
>built in serial ports are working fine in DB1100 with linux-2.4.20 kernel
>When we use a pcmcia serial card or modem, for most of the card, 
>cardmaneger load serial_cs.o (actualy it uses the serial.o  fetures for 
>registering the module).
>This method work fine in my laptop.
>same think hepens in db1100 bord also. I gues serial.o in bord db110 
>does'nt support well for serial_cs
>.
>If there is a stand alon serial_cs.o module for this board It may work 
>without any problem.
>if it is os where  can I get the seria_cs or any generic serial pcmcia 
>driver for db1100 bord, or  otherwise is any serial.c available for db1100 
>that can support pcmcia and inbuild serial as it works in labtop.
>
>There is important think, when we connected in the laptop this pcmcia 
>serial card detect is detected as 65550A but in the board it detected as 
>65550. I checked the serial.c code of db1100 there is no entry for this 65550A.
>
>if any one worked with this DB1100 please help me to solve this problem
>
>
>thanx
>safiudeen
>
>&gt;From: Michael Stickel &lt;michael.stickel@4g-systems.biz&gt;
>&gt;To: &quot;safiudeen Ts&quot; &lt;safiudeen@hotmail.com&gt;
>&gt;Subject: Re: PCMCIA genric sreail or modem support for db1100 bord
>&gt;Date: Fri, 20 Aug 2004 10:07:40 +0200
>&gt;
>&gt;
>&gt;Do you use the buildin serial ports?
>&gt;
>&gt;My last information is that the au1x00-serial module does not work
>&gt;in parallel with the serial module because au1x00-serial.c is just a
>&gt;modified copy of serial.c.
>&gt;
>&gt;Michael
>&gt;
>
>_________________________________________________________________
>Add photos to your messages with MSN 8. Get 2 months FREE*. 
>http://join.msn.com/?page=features/featuredemail
>

Michael J. Kelly
VP Engineering/Marketing
Cogent Computer Systems, Inc.
1130 Ten Rod Road
Suite A-201
North Kingstown, RI 02852
tel:401-295-6505 fax:401-295-6507
www.cogcomp.com
alternate email: mkelly6505@hotmail.com


From ica2_ts@csv.ica.uni-stuttgart.de Fri Aug 20 14:12:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 14:12:34 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:47654
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225206AbUHTNMa>; Fri, 20 Aug 2004 14:12:30 +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 1By9Bj-0006XO-00; Fri, 20 Aug 2004 15:12:11 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1By9Bi-0007Ec-00; Fri, 20 Aug 2004 15:12:10 +0200
Date: Fri, 20 Aug 2004 15:12:10 +0200
To: Dominic Sweetman <dom@mips.com>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Message-ID: <20040820131210.GE14937@rembrandt.csv.ica.uni-stuttgart.de>
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16676.46694.564448.344602@arsenal.mips.com>
User-Agent: Mutt/1.5.6i
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: 5700
X-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

Dominic Sweetman wrote:
[snip]
> So we're proposing:
> 
> o The register name<->number mapping is that of n64.
> 
> o Calling convention: register-, not slot-based. Each argument is
>   represented by a register value. Arguments 0-7 travel in registers
>   a0-7 (or fa0-7 as required for floating point types).

This suggests to have no fp temporaries left: fv0-1, fa0-7, fs0-5.
Is this intentional?


Thiemo

From dom@mips.com Fri Aug 20 14:46:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 14:46:43 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:36625 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224911AbUHTNqj>;
	Fri, 20 Aug 2004 14:46:39 +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 1By9tj-0003MH-00; Fri, 20 Aug 2004 14:57:39 +0100
Received: from arsenal.mips.com ([192.168.192.197])
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1By9ie-0001B8-00; Fri, 20 Aug 2004 14:46:12 +0100
Received: from dom by arsenal.mips.com with local (Exim 3.35 #1 (Debian))
	id 1By9ie-0002nS-00; Fri, 20 Aug 2004 14:46:12 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16678.163.774841.111369@arsenal.mips.com>
Date: Fri, 20 Aug 2004 14:46:11 +0100
To: Jun Sun <jsun@mvista.com>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
In-Reply-To: <20040819221646.GC8737@mvista.com>
References: <20040804152936.D6269@mvista.com>
	<16676.46694.564448.344602@arsenal.mips.com>
	<20040819221646.GC8737@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.848, 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: 5701
X-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


Jun Sun (jsun@mvista.com) writes:

> > [large expanse of new ABI stuff omitted]
>
> What is the motivation of other changes?  Taking this chance to make
> things all right in one shot?

Yes, and I did kind of cover this in the large expanse of stuff:

> > As you said, this motivates a revision of the ABI.  Any
> > incompatible change to the ABI is painful, since everything has to
> > be recompiled; so our reasoning at the moment is that we might as
> > well be radical...

o32 puts only four arguments in registers, which is less than optimal,
and continually reloads the GOT pointer (which is not defined as a
saved register in o32).

n32 (despite its name) runs exclusively on 64-bit CPUs.

So yes, we have strong reasons for making a larger change to the ABI,
and knowing how difficult it is...

> However, from NPTL implementation point of view I really just care
> about the per-thread register.

I guess our main message was that we felt it would be a mistake just
to add a thread register to o32 (which produces a substantially
incompatible new ABI anyway).

Until that all works, what we had in mind is that we'd do NPTL over
o32 by defining a system call to return a per-thread ID which is or
can be converted into a per-thread data pointer.  We suspected that
NPTL's per-thread-data model allows the use of cunning macros or
library functions to make that look OK.

Ought we to go further and see exactly how that can be done?

--
Dominic


From yuasa@hh.iij4u.or.jp Fri Aug 20 15:17:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 15:17:59 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:47077 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8224911AbUHTORy>;
	Fri, 20 Aug 2004 15:17:54 +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 XAA01789;
	Fri, 20 Aug 2004 23:17:49 +0900 (JST)
Received: 4UMDO01 id i7KEHms28677; Fri, 20 Aug 2004 23:17:49 +0900 (JST)
Received: 4UMRO00 id i7KEHkX3002417; Fri, 20 Aug 2004 23:17:47 +0900 (JST)
	from stratos (localhost [127.0.0.1]) (authenticated)
Date: Fri, 20 Aug 2004 23:17:32 +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] vr41xx: arch_init_irq
Message-Id: <20040820231732.5cf3c099.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-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: 5702
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

Hi Ralf,

The following line isn't needed in arch_init_irq().
Please apply this patch to v2.6 CVS tree.

Yoichi

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	Fri Aug 20 21:10:27 2004
+++ linux/arch/mips/vr41xx/common/icu.c	Fri Aug 20 22:57:35 2004
@@ -699,8 +699,6 @@
 
 void __init arch_init_irq(void)
 {
-	memset(irq_desc, 0, sizeof(irq_desc));
-
 	mips_cpu_irq_init(MIPS_CPU_IRQ_BASE);
 	init_vr41xx_icu_irq();
 	init_vr41xx_giuint_irq();

From ralf@linux-mips.org Fri Aug 20 16:00:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 16:00:29 +0100 (BST)
Received: from p508B7A8B.dip.t-dialin.net ([IPv6:::ffff:80.139.122.139]:36986
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbUHTPAZ>; Fri, 20 Aug 2004 16:00:25 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7KF0Ieu007125;
	Fri, 20 Aug 2004 17:00:18 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7KF081t007124;
	Fri, 20 Aug 2004 17:00:08 +0200
Date: Fri, 20 Aug 2004 17:00:08 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH] vr41xx: arch_init_irq
Message-ID: <20040820150008.GA7040@linux-mips.org>
References: <20040820231732.5cf3c099.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040820231732.5cf3c099.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5703
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Aug 20, 2004 at 11:17:32PM +0900, Yoichi Yuasa wrote:

> The following line isn't needed in arch_init_irq().
> Please apply this patch to v2.6 CVS tree.

Applied.  Thanks,

  Ralf

From dom@mips.com Fri Aug 20 17:53:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 17:53:29 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:53770 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224832AbUHTQxY>;
	Fri, 20 Aug 2004 17:53:24 +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 1ByCoK-0008IC-00; Fri, 20 Aug 2004 18:04:16 +0100
Received: from arsenal.mips.com ([192.168.192.197])
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1ByCdB-0003v6-00; Fri, 20 Aug 2004 17:52:45 +0100
Received: from dom by arsenal.mips.com with local (Exim 3.35 #1 (Debian))
	id 1ByCdA-0002se-00; Fri, 20 Aug 2004 17:52:44 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16678.11356.115235.767617@arsenal.mips.com>
Date: Fri, 20 Aug 2004 17:52:44 +0100
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Dominic Sweetman <dom@mips.com>, Jun Sun <jsun@mvista.com>,
	linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
In-Reply-To: <20040820131210.GE14937@rembrandt.csv.ica.uni-stuttgart.de>
References: <20040804152936.D6269@mvista.com>
	<16676.46694.564448.344602@arsenal.mips.com>
	<20040820131210.GE14937@rembrandt.csv.ica.uni-stuttgart.de>
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.348, required 4, AWL,
	BAYES_00, J_BACKHAIR_46)
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: 5704
X-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


Thiemo Seufer (ica2_ts@csv.ica.uni-stuttgart.de) writes:

> > So we're proposing:
> > 
> > o The register name<->number mapping is that of n64.
> > 
> > o Calling convention: register-, not slot-based. Each argument is
> >   represented by a register value. Arguments 0-7 travel in registers
> >   a0-7 (or fa0-7 as required for floating point types).
> 
> This suggests to have no fp temporaries left: fv0-1, fa0-7, fs0-5.
> Is this intentional?

No, there are lots really...

Long, long ago early MIPS CPUs had to use FP registers in pairs to get
FP doubles, so had only 16 effective registers.

But there are 32 real double-precision FP registers in all known
modern MIPS CPUs (well, all known pretty old ones, really) once you
turn off the backward-compatibility bit in the status register.  I
forgot to mention that... (or I could claim, weasel words, that this
is implied by the "name<->number mapping of n64").

--
Dominic


From ralf@linux-mips.org Fri Aug 20 21:45:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 21:45:07 +0100 (BST)
Received: from p508B7A8B.dip.t-dialin.net ([IPv6:::ffff:80.139.122.139]:46974
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225202AbUHTUpC>; Fri, 20 Aug 2004 21:45:02 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7KKingX014406;
	Fri, 20 Aug 2004 22:44:49 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7KKillb014405;
	Fri, 20 Aug 2004 22:44:47 +0200
Date: Fri, 20 Aug 2004 22:44:47 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Tim Lai <tinglai@gmail.com>, Eric DeVolder <eric.devolder@amd.com>,
	linux-mips@linux-mips.org
Subject: Re: problem with prefetch in user space
Message-ID: <20040820204447.GA14260@linux-mips.org>
References: <e2eac65704081716345c78b7c6@mail.gmail.com> <41235841.6090105@amd.com> <e2eac65704081808061f27cb5a@mail.gmail.com> <20040818153148.GI23756@rembrandt.csv.ica.uni-stuttgart.de> <e2eac657040818094264dc6a3b@mail.gmail.com> <20040818171342.GN23756@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040818171342.GN23756@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5705
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Aug 18, 2004 at 07:13:42PM +0200, Thiemo Seufer wrote:

> Something like:
> 
>         __asm__ __volatile__(
> 		".set push\n"
> 		".set mips4\n"
> 		"pref " PREF_OP ", 0(%0)\n"
> 		".set pop\n"
> 		: "=r" (addr));
> 
> For more information: "info gcc" and the kernel sources.

A few years ago somebody wrote a nice howto on inline assembler that also
contains all the architecture specifics.  Should be possible to track it
down via your favorite search engine.

  Ralf

From pdh@colonel-panic.org Fri Aug 20 23:47:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Aug 2004 23:47:33 +0100 (BST)
Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:27523 "EHLO
	skeleton-jack.localnet") by linux-mips.org with ESMTP
	id <S8224897AbUHTWr2>; Fri, 20 Aug 2004 23:47:28 +0100
Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian))
	id 1ByIAO-0001wr-00
	for <linux-mips@linux-mips.org>; Fri, 20 Aug 2004 23:47:24 +0100
Date: Fri, 20 Aug 2004 23:47:24 +0100
To: linux-mips@linux-mips.org
Subject: 64-bit kernels for the Qube
Message-ID: <20040820224724.GB7373@skeleton-jack>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040722i
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: 5706
X-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

I'm looking to build a 64-bit 2.6.x kernel for running on the Cobalt
Qube. Can someone tell me which binutils and gcc versions I should be
using ?

P.

From pf@net.alphadv.de Sat Aug 21 01:28:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 21 Aug 2004 01:28:35 +0100 (BST)
Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:6674 "EHLO
	mail.alphastar.de") by linux-mips.org with ESMTP
	id <S8224897AbUHUA2b>; Sat, 21 Aug 2004 01:28:31 +0100
Received: from Snailmail (217.249.225.133)
          by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==)
          for <linux-mips@linux-mips.org>; Sat, 21 Aug 2004 02:27:05 +0200
Received: from Opal.Peter (pf@Opal.Peter [192.168.1.1])
	by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id i7L0PMMt001011
	for <linux-mips@linux-mips.org>; Sat, 21 Aug 2004 02:25:23 +0200
Received: from localhost (pf@localhost)
	by Opal.Peter (8.9.3/8.9.3/Sendmail/Linux 2.2.5-15) with ESMTP id CAA04659
	for <linux-mips@linux-mips.org>; Sat, 21 Aug 2004 02:17:40 +0200
Date: Sat, 21 Aug 2004 02:17:40 +0200 (CEST)
From: Peter Fuerst <pf@net.alphadv.de>
To: linux-mips@linux-mips.org
Subject: IP28 Kernel patches
Message-ID: <Pine.LNX.4.21.0408210214270.4655-100000@Opal.Peter>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: pf@net.alphadv.de
Return-Path: <pf@net.alphadv.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: 5707
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pf@net.alphadv.de
Precedence: bulk
X-list: linux-mips


Hello !

The Kernel patches for SGI Indigo2 R10k (IP28) can now be found at
http://home.alphastar.de/fuerst/download.html


with kind regards...


From kumba@gentoo.org Sat Aug 21 01:38:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 21 Aug 2004 01:38:46 +0100 (BST)
Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:40074 "EHLO
	rwcrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8224897AbUHUAim>; Sat, 21 Aug 2004 01:38:42 +0100
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (rwcrmhc12) with ESMTP
          id <20040821003829014007romte>
          (Authid: kumba12345);
          Sat, 21 Aug 2004 00:38:33 +0000
Message-ID: <41269A5D.50700@gentoo.org>
Date: Fri, 20 Aug 2004 20:42:05 -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: 64-bit kernels for the Qube
References: <20040820224724.GB7373@skeleton-jack>
In-Reply-To: <20040820224724.GB7373@skeleton-jack>
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: 5708
X-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

Peter Horton wrote:

> I'm looking to build a 64-bit 2.6.x kernel for running on the Cobalt
> Qube. Can someone tell me which binutils and gcc versions I should be
> using ?
> 
> P.

gcc-3.3.4 and binutils-2.14.90.0.8 work for me (also tested 
2.15.90.0.3).  3.4.x has some issues, any kernel built with it seems to 
crash after checking for the daddui bug (tested on cobalt 32bit and O2 
64bit after applying a patch to remove 'accum' from several files).


--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 macleod@mail2000.com.tw Sun Aug 22 04:54:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Aug 2004 04:54:27 +0100 (BST)
Received: from m4.mail2000.com.tw ([IPv6:::ffff:210.200.181.213]:55055 "HELO
	m5.mail2000.com.tw") by linux-mips.org with SMTP
	id <S8224948AbUHVDyW> convert rfc822-to-8bit; Sun, 22 Aug 2004 04:54:22 +0100
Received: from 210.200.181.211
	by m5.mail2000.com.tw with Mail2000 ESMTP Server V3.20M(49043:0:AUTH_RELAY)
	(envelope-from <macleod@mail2000.com.tw>); Sun, 22 Aug 2004 11:54:11 +0800 (CST)
Received: By OpenMail Mailer;Sun, 22 Aug 2004 11:54:10 +0800 (CST)
From: "Macleod" <macleod@mail2000.com.tw>
Reply-To: macleod@mail2000.com.tw
Subject: System call select on R4600
Message-ID: <1093146850.1583.macleod@mail2000.com.tw>
To: linux-mips@linux-mips.org
Date: Sun, 22 Aug 2004 11:54:10 +0800 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8BIT
Return-Path: <macleod@mail2000.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: 5709
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macleod@mail2000.com.tw
Precedence: bulk
X-list: linux-mips


 My problem is "select" system call always return -1
 and errno is -4142, but sys_select has never been called.
 Think, it has some problem on handling system call. 
 Because if I change SYS(sys_select, 5) to 4 arguments,
 sys_select will be executed. 
 Thanks!

 Compiler: gcc-3.3.3
 Kernel: mips-linux-2.4.25/mips-linux-2.4.26
 Compile parameter:
 -Wno-inline \
 -Werror-implicit-function-declarations \
 -fno-PIC \
 -fno-common \
 -mno-abicalls \
 -mlong-calls \
 -march=r4600 \
 -mtune=r4600 \
 -G 0 \
 -Wa,--trap


From rs_javadi@yahoo.com Sun Aug 22 06:21:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Aug 2004 06:21:23 +0100 (BST)
Received: from web60805.mail.yahoo.com ([IPv6:::ffff:216.155.196.68]:32864
	"HELO web60805.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225207AbUHVFVR>; Sun, 22 Aug 2004 06:21:17 +0100
Message-ID: <20040822052109.77650.qmail@web60805.mail.yahoo.com>
Received: from [217.218.17.100] by web60805.mail.yahoo.com via HTTP; Sat, 21 Aug 2004 22:21:09 PDT
Date: Sat, 21 Aug 2004 22:21:09 -0700 (PDT)
From: Reza Javadi <rs_javadi@yahoo.com>
Subject: xine crash when playing DIVx with 128 MB RAM ...
To: xine-user@lists.sourceforge.net
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rs_javadi@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: 5710
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rs_javadi@yahoo.com
Precedence: bulk
X-list: linux-mips

Hello to all,

Our company is working on a set-top box (Internet
Appliance) which has a LFS (Linux From Scrach) as its
embedded OS. When I play DIVx movies with xine in 128
MB of RAM it crashes. 

I used gdb for debugging, but the problem is when I
run xine in gdb, I receive a SIGTRAP and then when I
use c (continuing) nothing happens and I do not have
any video and audio and I can not progress in
debugging. 

Therefore I need someone help to solve my  problem of
running xine with gdb to debug the crash.   

Is gdb useful in this particular case ?

Thanks

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From rs_javadi@yahoo.com Sun Aug 22 06:22:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Aug 2004 06:22:34 +0100 (BST)
Received: from web60808.mail.yahoo.com ([IPv6:::ffff:216.155.196.71]:65161
	"HELO web60808.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224802AbUHVFW3>; Sun, 22 Aug 2004 06:22:29 +0100
Message-ID: <20040822052222.1625.qmail@web60808.mail.yahoo.com>
Received: from [217.218.17.100] by web60808.mail.yahoo.com via HTTP; Sat, 21 Aug 2004 22:22:22 PDT
Date: Sat, 21 Aug 2004 22:22:22 -0700 (PDT)
From: Reza Javadi <rs_javadi@yahoo.com>
Subject: xine crash when playing DIVx with 128 MB RAM ...
To: xine-user@lists.sourceforge.net
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rs_javadi@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: 5711
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rs_javadi@yahoo.com
Precedence: bulk
X-list: linux-mips

Hello to all,

Our company is working on a set-top box (Internet
Appliance) which has a LFS (Linux From Scrach) as its
embedded OS. When I play DIVx movies with xine in 128
MB of RAM it crashes. 

I used gdb for debugging, but the problem is when I
run xine in gdb, I receive a SIGTRAP and then when I
use c (continuing) nothing happens and I do not have
any video and audio and I can not progress in
debugging. 

Therefore I need someone help to solve my  problem of
running xine with gdb to debug the crash.   

Is gdb useful in this particular case ?

Thanks


		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

From ralf@linux-mips.org Sun Aug 22 13:14:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Aug 2004 13:14:50 +0100 (BST)
Received: from p508B7531.dip.t-dialin.net ([IPv6:::ffff:80.139.117.49]:60710
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225212AbUHVMOq>; Sun, 22 Aug 2004 13:14:46 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7MCEipC029714;
	Sun, 22 Aug 2004 14:14:44 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7MCEaCD029713;
	Sun, 22 Aug 2004 14:14:36 +0200
Date: Sun, 22 Aug 2004 14:14:36 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Macleod <macleod@mail2000.com.tw>
Cc: linux-mips@linux-mips.org
Subject: Re: System call select on R4600
Message-ID: <20040822121436.GA29321@linux-mips.org>
References: <1093146850.1583.macleod@mail2000.com.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1093146850.1583.macleod@mail2000.com.tw>
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: 5712
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sun, Aug 22, 2004 at 11:54:10AM +0800, Macleod wrote:

>  My problem is "select" system call always return -1
>  and errno is -4142, but sys_select has never been called.
>  Think, it has some problem on handling system call. 
>  Because if I change SYS(sys_select, 5) to 4 arguments,
>  sys_select will be executed. 
>  Thanks!

This is a bug which was fixed a while ago.  I assume your application
is picking up a bad definition from an old kernel header package or so.
Still doing syscalls directly is a fragily; better avoid and use your
libc's select(3).

  Ralf

From macro@linux-mips.org Mon Aug 23 10:29:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 10:29:54 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:51470 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224953AbUHWJ3t>; Mon, 23 Aug 2004 10:29:49 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 5434BE1C91; Mon, 23 Aug 2004 11:29:45 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 18425-01; Mon, 23 Aug 2004 11:29:45 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 1D271E1C7B; Mon, 23 Aug 2004 11:29:45 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i7N9To0X004564;
	Mon, 23 Aug 2004 11:29:51 +0200
Date: Mon, 23 Aug 2004 11:29:46 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20040820120223Z8225206-1530+8785@linux-mips.org>
Message-ID: <Pine.LNX.4.58L.0408231124040.19572@blysk.ds.pg.gda.pl>
References: <20040820120223Z8225206-1530+8785@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 5713
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, 20 Aug 2004 ralf@linux-mips.org wrote:

> Log message:
> 	Undo change from rev 1.37; some userspace software is expecting
> 	PAGE_SIZE, PAGE_SHIFT and PAGE_MASK to be accessible through
> 	<asm/page.h>.  Sigh ...

 Fix that software then, instead of breaking good one (hint -- what is the
"right" value of PAGE_SHIFT and why it doesn't work for that system over
there?).  With these macros exported it's hard to guess whether the page
size can be hardcoded or it should get determined at the run time.  And 
with glibc you get a compilation error due to PAGE_SHIFT being undefined.  
Please revert the braindamage.

 What software is the offender, BTW?

  Maciej

From kumba@gentoo.org Mon Aug 23 10:50:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 10:50:45 +0100 (BST)
Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:42939 "EHLO
	rwcrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8224953AbUHWJul>; Mon, 23 Aug 2004 10:50:41 +0100
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (rwcrmhc12) with ESMTP
          id <20040823095034014007mmove>
          (Authid: kumba12345);
          Mon, 23 Aug 2004 09:50:34 +0000
Message-ID: <4129BECB.7000508@gentoo.org>
Date: Mon, 23 Aug 2004 05:54:19 -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: CVS Update@-mips.org: linux
References: <20040820120223Z8225206-1530+8785@linux-mips.org> <Pine.LNX.4.58L.0408231124040.19572@blysk.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.58L.0408231124040.19572@blysk.ds.pg.gda.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: 5714
X-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

Maciej W. Rozycki wrote:

> On Fri, 20 Aug 2004 ralf@linux-mips.org wrote:
> 
> 
>>Log message:
>>	Undo change from rev 1.37; some userspace software is expecting
>>	PAGE_SIZE, PAGE_SHIFT and PAGE_MASK to be accessible through
>>	<asm/page.h>.  Sigh ...
> 
> 
>  Fix that software then, instead of breaking good one (hint -- what is the
> "right" value of PAGE_SHIFT and why it doesn't work for that system over
> there?).  With these macros exported it's hard to guess whether the page
> size can be hardcoded or it should get determined at the run time.  And 
> with glibc you get a compilation error due to PAGE_SHIFT being undefined.  
> Please revert the braindamage.
> 
>  What software is the offender, BTW?
> 
>   Maciej

procps is probably the trigger of this.  Me and some other Gentoo/MIPS 
devs/users got into a bit of a heated discussion w/ the procps 
maintainer, who didn't quite like the fact that A) We don't use 
"sanitized" kernel headers B) PAGE_SIZE was hidden on MIPS and C) 
"properly sanitized" headers would provide PAGE_SIZE.  We opted instead 
for a patch to procps that used sysconf(_SC_PAGESIZE) to fetch the 
value, and I guess this just didn't rub the right way w/ the maintainer. 
  Got me.

I can post the discussions for those interested (or just looking for 
amusement), and anyone curious enough can look at proc/procps.h in the 
procps tree for a rather amusing (IMHO) comment on MIPS at the top of 
the source.


--Kumba

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

From ralf@linux-mips.org Mon Aug 23 11:24:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 11:24:08 +0100 (BST)
Received: from p508B66F0.dip.t-dialin.net ([IPv6:::ffff:80.139.102.240]:42292
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224953AbUHWKYD>; Mon, 23 Aug 2004 11:24:03 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7NAO25F019122;
	Mon, 23 Aug 2004 12:24:02 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7NAO2VJ019121;
	Mon, 23 Aug 2004 12:24:02 +0200
Date: Mon, 23 Aug 2004 12:24:02 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20040823102402.GC17067@linux-mips.org>
References: <20040820120223Z8225206-1530+8785@linux-mips.org> <Pine.LNX.4.58L.0408231124040.19572@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58L.0408231124040.19572@blysk.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: 5715
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Aug 23, 2004 at 11:29:46AM +0200, Maciej W. Rozycki wrote:

> > Log message:
> > 	Undo change from rev 1.37; some userspace software is expecting
> > 	PAGE_SIZE, PAGE_SHIFT and PAGE_MASK to be accessible through
> > 	<asm/page.h>.  Sigh ...
> 
>  Fix that software then, instead of breaking good one (hint -- what is the
> "right" value of PAGE_SHIFT and why it doesn't work for that system over
> there?).  With these macros exported it's hard to guess whether the page
> size can be hardcoded or it should get determined at the run time.  And 
> with glibc you get a compilation error due to PAGE_SHIFT being undefined.  
> Please revert the braindamage.

Due to PAGE_SHIFT being undefined?  You meant the opposite?

>  What software is the offender, BTW?

Procps but I have dark memories of other packages doing the same thing, so
I gave up and kludged the thing the same way other architectures do.
Even IA-64 which is suffering the same pains with variable page size.

  Ralf

From ralf@linux-mips.org Mon Aug 23 11:58:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 11:58:58 +0100 (BST)
Received: from p508B66F0.dip.t-dialin.net ([IPv6:::ffff:80.139.102.240]:64820
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225221AbUHWK6y>; Mon, 23 Aug 2004 11:58:54 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7NAwoQX019799;
	Mon, 23 Aug 2004 12:58:50 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7NAwoHH019798;
	Mon, 23 Aug 2004 12:58:50 +0200
Date: Mon, 23 Aug 2004 12:58:50 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Kumba <kumba@gentoo.org>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20040823105850.GA19125@linux-mips.org>
References: <20040820120223Z8225206-1530+8785@linux-mips.org> <Pine.LNX.4.58L.0408231124040.19572@blysk.ds.pg.gda.pl> <4129BECB.7000508@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4129BECB.7000508@gentoo.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5716
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Aug 23, 2004 at 05:54:19AM -0400, Kumba wrote:

> procps is probably the trigger of this.  Me and some other Gentoo/MIPS 
> devs/users got into a bit of a heated discussion w/ the procps 
> maintainer, who didn't quite like the fact that A) We don't use 
> "sanitized" kernel headers B) PAGE_SIZE was hidden on MIPS and C) 
> "properly sanitized" headers would provide PAGE_SIZE.  We opted instead 
> for a patch to procps that used sysconf(_SC_PAGESIZE) to fetch the 
> value, and I guess this just didn't rub the right way w/ the maintainer. 

Who happens to be Albert Calahan, just to mention the name.

As for the sanitized kernel headers package he's probably right.  At the
current state of Linux kernel headers - all architectures, not just MIPS -
mail threads like this will be unavoidable if we try to continue
supporting kernel headers in userspace.  I can be convinced to support
such use to the same point as i386 but not a single symbol beyond that.

> I can post the discussions for those interested (or just looking for 
> amusement), and anyone curious enough can look at proc/procps.h in the 
> procps tree for a rather amusing (IMHO) comment on MIPS at the top of 
> the source.

Whoever wrote that has a very screwed idea of the MIPS realities.

  Ralf

From macro@linux-mips.org Mon Aug 23 12:40:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 12:40:20 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:16905 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225221AbUHWLkQ>; Mon, 23 Aug 2004 12:40:16 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 41BF8E1C93; Mon, 23 Aug 2004 13:40:12 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 06406-05; Mon, 23 Aug 2004 13:40:12 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 1B10CE1C91; Mon, 23 Aug 2004 13:40:12 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i7NBeJJ8010772;
	Mon, 23 Aug 2004 13:40:20 +0200
Date: Mon, 23 Aug 2004 13:40:14 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20040823102402.GC17067@linux-mips.org>
Message-ID: <Pine.LNX.4.58L.0408231319350.19572@blysk.ds.pg.gda.pl>
References: <20040820120223Z8225206-1530+8785@linux-mips.org>
 <Pine.LNX.4.58L.0408231124040.19572@blysk.ds.pg.gda.pl>
 <20040823102402.GC17067@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 5717
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, 23 Aug 2004, Ralf Baechle wrote:

> Due to PAGE_SHIFT being undefined?  You meant the opposite?

 Yes.  No.  PAGE_SHIFT is defined conditionally based on 
CONFIG_PAGE_SIZE_*, which is of course undefined in a generic set of 
headers.

 With PAGE_SIZE undefined you can fall back to sysconf(_SC_PAGESIZE) or 
the page size in the ELF auxiliary vector (depending on the context).  

> Procps but I have dark memories of other packages doing the same thing, so
> I gave up and kludged the thing the same way other architectures do.
> Even IA-64 which is suffering the same pains with variable page size.

 Do they?  Anyway that's not a way to fix broken software.  Perhaps we 
could do the following hack to teach the resistant:

#ifndef __KERNEL__
#warning PAGE_SIZE is not a user macro, fix your program!
#define PAGE_SIZE sysconf(_SC_PAGESIZE)
#endif

but glibc might not be especially happy about such an alias.

 If you really insist on PAGE_SIZE being constant, then please at least
define it to the maximum supported size for the userland, so that page
alignment rules are kept.  I don't see any reason to keep bugs alive,
though.

  Maciej

From ralf@linux-mips.org Mon Aug 23 13:28:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 13:28:50 +0100 (BST)
Received: from p508B66F0.dip.t-dialin.net ([IPv6:::ffff:80.139.102.240]:5174
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225225AbUHWM2p>; Mon, 23 Aug 2004 13:28:45 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7NCShqU021626;
	Mon, 23 Aug 2004 14:28:43 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7NCShYW021623;
	Mon, 23 Aug 2004 14:28:43 +0200
Date: Mon, 23 Aug 2004 14:28:43 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Alec Voropay <a.voropay@vmb-service.ru>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Message-ID: <20040823122843.GB20905@linux-mips.org>
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com> <006f01c485f9$41348b50$3c01a8c0@portege>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <006f01c485f9$41348b50$3c01a8c0@portege>
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: 5718
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Aug 19, 2004 at 06:31:45PM +0400, Alec Voropay wrote:

> > Well, this is an area of substantial interest to MIPS Technologies.
> > We are working on our multi-threading extension to the MIPS
> > architecture, and one of our longer-term aims is to achieve really
> > good NPTL performance.
> 
>  Sorry for a bit offtopic..., as far as I remember, the Windows NT
> MIPS edition has a working multithread implementation. Is this
> implementation very copyrighted and is it possible to use something
> ftom there for the NPTL implementation ?

In addition to what Dom has already answered - there are very significant
differences between the multithreading as implemented in the Windows OS
family and the varioius threading implementations for Linux like classic
libpthreads, Linuxthreads, NPTL, Mozilla and more.  If we legally could
look at MS's code I'd not expect to find much useful for us there ...

  Ralf

From macro@linux-mips.org Mon Aug 23 13:56:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 13:56:55 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:11027 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225225AbUHWM4v>; Mon, 23 Aug 2004 13:56:51 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 1D6FBE1C91; Mon, 23 Aug 2004 14:56:47 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 18882-01; Mon, 23 Aug 2004 14:56:47 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id DEF54E1C63; Mon, 23 Aug 2004 14:56:46 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i7NCutot013954;
	Mon, 23 Aug 2004 14:56:56 +0200
Date: Mon, 23 Aug 2004 14:56:49 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Srinivas Kommu <kommu@hotmail.com>, linux-mips@linux-mips.org
Subject: Re: mips32 kernel memory mapping
In-Reply-To: <20040820081832.GD15543@linux-mips.org>
Message-ID: <Pine.LNX.4.58L.0408231455250.19572@blysk.ds.pg.gda.pl>
References: <BAY1-F25sCR6nWqNG2Y00092cf9@hotmail.com>
 <Pine.LNX.4.58L.0407231348580.5644@blysk.ds.pg.gda.pl> <20040723202439.GA3711@linux-mips.org>
 <Pine.LNX.4.58L.0407261258010.3873@blysk.ds.pg.gda.pl>
 <20040820081832.GD15543@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@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: 5719
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, 20 Aug 2004, Ralf Baechle wrote:

> I have 1GB and that's where 32-bit kernels are beginning to look really
> like a bad idea on MIPS.  Fortunately on the BCM1250 and all the other
> 64-bit processors there is an easy way out.  Better even, some of the
> embedded application performance numbers suggest significant performance
> gains for 64-bit processing contrary to conventional wisdom about 64-bit
> computing.

 But large memory holes are not necessarily nice anyway.

  Maciej

From drow@nevyn.them.org Mon Aug 23 14:29:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 14:29:07 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:48819 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225229AbUHWN3D>;
	Mon, 23 Aug 2004 14:29:03 +0100
Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian))
	id 1BzEsX-0008AN-2a; Mon, 23 Aug 2004 09:28:53 -0400
Date: Mon, 23 Aug 2004 09:28:53 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Dominic Sweetman <dom@mips.com>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Message-ID: <20040823132853.GA31354@nevyn.them.org>
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com> <20040819221646.GC8737@mvista.com> <16678.163.774841.111369@arsenal.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16678.163.774841.111369@arsenal.mips.com>
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <drow@nevyn.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: 5720
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Fri, Aug 20, 2004 at 02:46:11PM +0100, Dominic Sweetman wrote:
> I guess our main message was that we felt it would be a mistake just
> to add a thread register to o32 (which produces a substantially
> incompatible new ABI anyway).

Completely agree...

> Until that all works, what we had in mind is that we'd do NPTL over
> o32 by defining a system call to return a per-thread ID which is or
> can be converted into a per-thread data pointer.  We suspected that
> NPTL's per-thread-data model allows the use of cunning macros or
> library functions to make that look OK.
> 
> Ought we to go further and see exactly how that can be done?

It shouldn't be at all hard.  The way NPTL's __thread support works,
the only things that should have to know where the TLS base is are
(A) GCC, so it can load it and (B) GDB, via some new ptrace op.  I
don't know if you'd want to open-code the syscall or take the overhead
of a function call.  Ralf had some ideas?

-- 
Daniel Jacobowitz

From a.voropay@vmb-service.ru Mon Aug 23 16:09:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 16:09:08 +0100 (BST)
Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:939 "EHLO
	smtp.vmb-service.ru") by linux-mips.org with ESMTP
	id <S8225233AbUHWPJD>; Mon, 23 Aug 2004 16:09:03 +0100
Received: from office.vmb-service.ru ([80.73.192.47]:1036 "EHLO alec")
	by Altair with ESMTP id <S1157108AbUHWPIs>;
	Mon, 23 Aug 2004 19:08:48 +0400
Reply-To: <a.voropay@vmb-service.ru>
From: "Alec Voropay" <a.voropay@vmb-service.ru>
To: "'Ralf Baechle'" <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
Subject: RE: anybody tried NPTL?
Date: Mon, 23 Aug 2004 19:09:31 +0400
Organization: VMB-Service
Message-ID: <036001c48923$31563350$1701a8c0@alec>
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.4024
In-Reply-To: <20040823122843.GB20905@linux-mips.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400
Importance: Normal
Return-Path: <a.voropay@vmb-service.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: 5721
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: a.voropay@vmb-service.ru
Precedence: bulk
X-list: linux-mips

Ralf Baechle [mailto:ralf@linux-mips.org] wrote:

> In addition to what Dom has already answered - there are very 
> significant differences between the multithreading as
> implemented in the  Windows OS family and the varioius
> threading implementations for Linux  like classic
> libpthreads, Linuxthreads, NPTL, Mozilla and more.
> If we legally could look at MS's code I'd not expect to find
> much useful for us there ...

 OK, OK. You are right. However, as it is known, there is at
least one project "to bridge" Win32/multithread and *NIX :
 WINE.
http://winehq.com/site/docs/wine-devel/x3398

 Yes, the Win32/MIPS API (and ABI) is dead, but MIPS/multithreading
lives in the WindowsCE/MIPS HPCs.


 Unfortunately, I can't find any details about Win32/MIPS
implementation.


--
-=VA=-


From ralf@linux-mips.org Mon Aug 23 18:13:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 18:13:07 +0100 (BST)
Received: from p508B66F0.dip.t-dialin.net ([IPv6:::ffff:80.139.102.240]:22073
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225236AbUHWRND>; Mon, 23 Aug 2004 18:13:03 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7NHCwuR027355;
	Mon, 23 Aug 2004 19:12:58 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7NHCviJ027354;
	Mon, 23 Aug 2004 19:12:57 +0200
Date: Mon, 23 Aug 2004 19:12:57 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: Dominic Sweetman <dom@mips.com>, Jun Sun <jsun@mvista.com>,
	linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Message-ID: <20040823171256.GC21884@linux-mips.org>
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com> <20040819221646.GC8737@mvista.com> <16678.163.774841.111369@arsenal.mips.com> <20040823132853.GA31354@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040823132853.GA31354@nevyn.them.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5722
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Aug 23, 2004 at 09:28:53AM -0400, Daniel Jacobowitz wrote:

> On Fri, Aug 20, 2004 at 02:46:11PM +0100, Dominic Sweetman wrote:
> > I guess our main message was that we felt it would be a mistake just
> > to add a thread register to o32 (which produces a substantially
> > incompatible new ABI anyway).
> 
> Completely agree...
> 
> > Until that all works, what we had in mind is that we'd do NPTL over
> > o32 by defining a system call to return a per-thread ID which is or
> > can be converted into a per-thread data pointer.  We suspected that
> > NPTL's per-thread-data model allows the use of cunning macros or
> > library functions to make that look OK.
> > 
> > Ought we to go further and see exactly how that can be done?
> 
> It shouldn't be at all hard.  The way NPTL's __thread support works,
> the only things that should have to know where the TLS base is are
> (A) GCC, so it can load it and (B) GDB, via some new ptrace op.  I
> don't know if you'd want to open-code the syscall or take the overhead
> of a function call.  Ralf had some ideas?

Thiemo and have been compiling various pieces of code with different
gcc versions trying to find the best possible register for that purpose.
We used code bloat as (weak ...) indicator for register pressure.  It
turned out that $t9 was the best choice for all tested compiler versions;
thanks to the much improved register allocation of newer gcc the choice
of a particular register made far less difference on recent compilers
than on older compilers.

I've also implemented a fast system call for reading the thread registers.
Benchmarks did show that to have about half the latency of a regular
syscall; the hope was if gcc was doing clever optimization that overhead
would effectivly become zero.

I was favoring this low-overhead syscall approach because it would avoid
the loss of a register thus leaving performance of non-threaded code
unchanged but other developers generally favor the permanent allocation
of $t9 as a thread register.

Other crazy ideas did include a per-thread mapping containing the thread
pointer - and possibly more information in the future.

Finally one of the ideas was using one of $k0 / $k1 as thread pointer.
This would require changes to the exception handlers; any extra
instruction in the TLB refill handler would be particularly painful.

On the positive side if we had multiple register sets on a MIPSxx V2
processor we could exploit that to get rid of this overheade and do
other nice optimizations for TLB reload also.  Unfortunately these
register sets are optional feature of the architecture only.

  Ralf

From ralf@linux-mips.org Mon Aug 23 18:19:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 18:19:27 +0100 (BST)
Received: from p508B66F0.dip.t-dialin.net ([IPv6:::ffff:80.139.102.240]:28217
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225005AbUHWRTX>; Mon, 23 Aug 2004 18:19:23 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7NHJLKa027502;
	Mon, 23 Aug 2004 19:19:21 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7NHJL1l027501;
	Mon, 23 Aug 2004 19:19:21 +0200
Date: Mon, 23 Aug 2004 19:19:21 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Alec Voropay <a.voropay@vmb-service.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Message-ID: <20040823171921.GD21884@linux-mips.org>
References: <20040823122843.GB20905@linux-mips.org> <036001c48923$31563350$1701a8c0@alec>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <036001c48923$31563350$1701a8c0@alec>
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: 5723
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Aug 23, 2004 at 07:09:31PM +0400, Alec Voropay wrote:

>  OK, OK. You are right. However, as it is known, there is at
> least one project "to bridge" Win32/multithread and *NIX :
>  WINE.
> http://winehq.com/site/docs/wine-devel/x3398
> 
>  Yes, the Win32/MIPS API (and ABI) is dead, but MIPS/multithreading
> lives in the WindowsCE/MIPS HPCs.
> 
> 
>  Unfortunately, I can't find any details about Win32/MIPS
> implementation.

That's because for Windows on x86 there are tons of important binary-only
applications available and Linux would have to be bought if they're
available at all.  On MIPS we're not in this dependency situation, so
we hardly care about Win32.

  Ralf

From jsun@mvista.com Mon Aug 23 18:37:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 18:37:41 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:33787 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225005AbUHWRhg>;
	Mon, 23 Aug 2004 18:37: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 i7NHbX7T023185;
	Mon, 23 Aug 2004 10:37:33 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i7NHbWBM023184;
	Mon, 23 Aug 2004 10:37:32 -0700
Date: Mon, 23 Aug 2004 10:37:31 -0700
From: Jun Sun <jsun@mvista.com>
To: Daniel Jacobowitz <dan@debian.org>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: anybody tried NPTL?
Message-ID: <20040823173731.GC23004@mvista.com>
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com> <20040819221646.GC8737@mvista.com> <16678.163.774841.111369@arsenal.mips.com> <20040823132853.GA31354@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040823132853.GA31354@nevyn.them.org>
User-Agent: Mutt/1.4i
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5724
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Mon, Aug 23, 2004 at 09:28:53AM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 20, 2004 at 02:46:11PM +0100, Dominic Sweetman wrote:
> > I guess our main message was that we felt it would be a mistake just
> > to add a thread register to o32 (which produces a substantially
> > incompatible new ABI anyway).
> 
> Completely agree...
> 
> > Until that all works, what we had in mind is that we'd do NPTL over
> > o32 by defining a system call to return a per-thread ID which is or
> > can be converted into a per-thread data pointer.  We suspected that
> > NPTL's per-thread-data model allows the use of cunning macros or
> > library functions to make that look OK.
> > 
> > Ought we to go further and see exactly how that can be done?
> 
> It shouldn't be at all hard.  The way NPTL's __thread support works,
> the only things that should have to know where the TLS base is are
> (A) GCC, so it can load it and (B) GDB, via some new ptrace op. 

Are you implying one can implement TLS support without changing O32
ABI?  Interesting...

I know Boris Hu has tried to implemented NPTL with another approach which
does not rely on TLS support (use "--without-tls").  According to him
this approach is getting harder these days.

Jun

From drow@nevyn.them.org Mon Aug 23 18:44:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 18:44:57 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:10682 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225005AbUHWRov>;
	Mon, 23 Aug 2004 18:44:51 +0100
Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian))
	id 1BzIsB-0002Am-Da; Mon, 23 Aug 2004 13:44:47 -0400
Date: Mon, 23 Aug 2004 13:44:47 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>, Jun Sun <jsun@mvista.com>,
	linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Message-ID: <20040823174446.GA8197@nevyn.them.org>
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com> <20040819221646.GC8737@mvista.com> <16678.163.774841.111369@arsenal.mips.com> <20040823132853.GA31354@nevyn.them.org> <20040823171256.GC21884@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040823171256.GC21884@linux-mips.org>
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <drow@nevyn.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: 5725
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Mon, Aug 23, 2004 at 07:12:57PM +0200, Ralf Baechle wrote:
> Thiemo and have been compiling various pieces of code with different
> gcc versions trying to find the best possible register for that purpose.
> We used code bloat as (weak ...) indicator for register pressure.  It
> turned out that $t9 was the best choice for all tested compiler versions;
> thanks to the much improved register allocation of newer gcc the choice
> of a particular register made far less difference on recent compilers
> than on older compilers.
> 
> I've also implemented a fast system call for reading the thread registers.
> Benchmarks did show that to have about half the latency of a regular
> syscall; the hope was if gcc was doing clever optimization that overhead
> would effectivly become zero.
> 
> I was favoring this low-overhead syscall approach because it would avoid
> the loss of a register thus leaving performance of non-threaded code
> unchanged but other developers generally favor the permanent allocation
> of $t9 as a thread register.

Personally, I favor doing the low-overhead syscall for o32 and then
moving to the new ABI that MIPS is talking about with a thread
register.  I'm not sure what to do about n32/n64.

> Other crazy ideas did include a per-thread mapping containing the thread
> pointer - and possibly more information in the future.

Does MIPS have an efficient way to do this for SMP?

> On the positive side if we had multiple register sets on a MIPSxx V2
> processor we could exploit that to get rid of this overheade and do
> other nice optimizations for TLB reload also.  Unfortunately these
> register sets are optional feature of the architecture only.

That's more or less what was talked about for ARM v6.

-- 
Daniel Jacobowitz

From ralf@linux-mips.org Mon Aug 23 20:13:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 20:13:29 +0100 (BST)
Received: from p508B66F0.dip.t-dialin.net ([IPv6:::ffff:80.139.102.240]:48186
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225211AbUHWTNY>; Mon, 23 Aug 2004 20:13:24 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7NJDJnM029930;
	Mon, 23 Aug 2004 21:13:19 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7NJDJHo029929;
	Mon, 23 Aug 2004 21:13:19 +0200
Date: Mon, 23 Aug 2004 21:13:19 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: Dominic Sweetman <dom@mips.com>, Jun Sun <jsun@mvista.com>,
	linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Message-ID: <20040823191319.GA29165@linux-mips.org>
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com> <20040819221646.GC8737@mvista.com> <16678.163.774841.111369@arsenal.mips.com> <20040823132853.GA31354@nevyn.them.org> <20040823171256.GC21884@linux-mips.org> <20040823174446.GA8197@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040823174446.GA8197@nevyn.them.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5726
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Aug 23, 2004 at 01:44:47PM -0400, Daniel Jacobowitz wrote:

> Personally, I favor doing the low-overhead syscall for o32 and then
> moving to the new ABI that MIPS is talking about with a thread
> register.

I was always wondering how far gcc could optimize code to minimize this
special system call.  After all on Alpha something similar PAL-code based
was the method of choice.

> I'm not sure what to do about n32/n64.

I believe N32 / N64 are not widespead enough yet to be a big roadblock
for moving to new ABIs.  Whoever disagress should better speak up soon :-)

If we deciede to move to something entirely different than the existing
ABIs in the future will be able to support compatibility the same way
we're already doing.

> > Other crazy ideas did include a per-thread mapping containing the thread
> > pointer - and possibly more information in the future.
> 
> Does MIPS have an efficient way to do this for SMP?

It can be done making the TLB fault for that page about as expensive as
a null syscall.

> > On the positive side if we had multiple register sets on a MIPSxx V2
> > processor we could exploit that to get rid of this overheade and do
> > other nice optimizations for TLB reload also.  Unfortunately these
> > register sets are optional feature of the architecture only.
> 
> That's more or less what was talked about for ARM v6.

I'm unARMed here ;-)

  Ralf

From ralf@linux-mips.org Mon Aug 23 20:25:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Aug 2004 20:25:30 +0100 (BST)
Received: from p508B66F0.dip.t-dialin.net ([IPv6:::ffff:80.139.102.240]:62522
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225211AbUHWTZX>; Mon, 23 Aug 2004 20:25:23 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7NJPKlU030192;
	Mon, 23 Aug 2004 21:25:20 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7NJPKik030191;
	Mon, 23 Aug 2004 21:25:20 +0200
Date: Mon, 23 Aug 2004 21:25:20 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: Daniel Jacobowitz <dan@debian.org>,
	Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Message-ID: <20040823192520.GC29165@linux-mips.org>
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com> <20040819221646.GC8737@mvista.com> <16678.163.774841.111369@arsenal.mips.com> <20040823132853.GA31354@nevyn.them.org> <20040823173731.GC23004@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040823173731.GC23004@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: 5727
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Aug 23, 2004 at 10:37:31AM -0700, Jun Sun wrote:

> Are you implying one can implement TLS support without changing O32
> ABI?  Interesting...
> 
> I know Boris Hu has tried to implemented NPTL with another approach which
> does not rely on TLS support (use "--without-tls").  According to him
> this approach is getting harder these days.

The whole TLS pointer thing is about making TLS more efficient.  If
you wanted to use TLS without any kernel changes you could do that
based on the THREAD result value of pthread_create or something like
that.  It'd work but it'd also not be terribly efficient ...

  Ralf

From ralf@linux-mips.org Tue Aug 24 17:03:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Aug 2004 17:03:14 +0100 (BST)
Received: from p508B6A77.dip.t-dialin.net ([IPv6:::ffff:80.139.106.119]:55881
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225238AbUHXQDK>; Tue, 24 Aug 2004 17:03:10 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7OG39vX024553;
	Tue, 24 Aug 2004 18:03:09 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7OG34sV024449;
	Tue, 24 Aug 2004 18:03:04 +0200
Date: Tue, 24 Aug 2004 18:03:04 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Valdis.Kletnieks@vt.edu
Cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, linux-mips@linux-mips.org
Subject: Re: [PATCH] 2.6.9-rc1 - #ifdef cleanip for MIPS
Message-ID: <20040824160304.GA23826@linux-mips.org>
References: <200408241352.i7ODqf73026463@turing-police.cc.vt.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200408241352.i7ODqf73026463@turing-police.cc.vt.edu>
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: 5728
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Aug 24, 2004 at 09:52:41AM -0400, Valdis.Kletnieks@vt.edu wrote:

> Cleaning up some #if to use #ifdef instead, to make life safer for compiling
> with -Wundef.

Thanks, applied.

  Ralf

From aravindforl@yahoo.co.in Tue Aug 24 17:23:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Aug 2004 17:24:03 +0100 (BST)
Received: from web8201.mail.in.yahoo.com ([IPv6:::ffff:203.199.70.114]:38314
	"HELO web8201.mail.in.yahoo.com") by linux-mips.org with SMTP
	id <S8225238AbUHXQX7>; Tue, 24 Aug 2004 17:23:59 +0100
Message-ID: <20040824132249.79568.qmail@web8201.mail.in.yahoo.com>
Received: from [202.41.227.188] by web8201.mail.in.yahoo.com via HTTP; Tue, 24 Aug 2004 14:22:49 BST
Date: Tue, 24 Aug 2004 14:22:49 +0100 (BST)
From: =?iso-8859-1?q?Arravind=20babu?= <aravindforl@yahoo.co.in>
Subject: Testing File systmes and drivers in linux kernel 2.4.20 
To: binutils@sources.redhat.com
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1315701508-1093353769=:72915"
Content-Transfer-Encoding: 8bit
Return-Path: <aravindforl@yahoo.co.in>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5729
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aravindforl@yahoo.co.in
Precedence: bulk
X-list: linux-mips

--0-1315701508-1093353769=:72915
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi all,
 
       We upgraded the linux kernel 2.4.14 to 2.4.20 in our MIPS based embedded device.So we are planning to test the kernel stability.For this we have to test 
 
File systems (RAMdisk , ROMFS , JFFS , CRAMFS) ,
NAND driver ,
Ethernet driver.
 
Is there any tools available freely to test the above things? Pls tell me if there are any tools or links todo these tasks?
 
Thanks in advance,
Aravind.

Yahoo! India Matrimony: Find your life partneronline.
--0-1315701508-1093353769=:72915
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Hi all,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We upgraded the linux kernel 2.4.14 to 2.4.20 in our <STRONG>MIPS</STRONG> based embedded device.So we are planning to test the kernel stability.For this we have to test </DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG>File systems</STRONG> (RAMdisk , ROMFS , JFFS , CRAMFS) ,</DIV>
<DIV><STRONG>NAND </STRONG>driver ,</DIV>
<DIV><STRONG>Ethernet</STRONG> driver.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is there any tools available freely to test the above things? Pls tell me if there are any tools or links todo these tasks?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks in advance,</DIV>
<DIV>Aravind.</DIV><p><font face=arial size=-1>
<a href="http://in.rd.yahoo.com/specials/mailtg/*http://yahoo.shaadi.com/india-matrimony/" target="_blank">
<b>Yahoo! India Matrimony</a>:</b> Find your life partner
<a href="http://in.rd.yahoo.com/specials/mailtg2/*http://yahoo.shaadi.com/india-matrimony/" target="_blank">online</a>.</font>
--0-1315701508-1093353769=:72915--

From drow@nevyn.them.org Tue Aug 24 17:33:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Aug 2004 17:33:29 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:25552 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225238AbUHXQdR>;
	Tue, 24 Aug 2004 17:33:17 +0100
Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian))
	id 1BzeEK-0007wu-Px; Tue, 24 Aug 2004 12:33:04 -0400
Date: Tue, 24 Aug 2004 12:33:04 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Arravind babu <aravindforl@yahoo.co.in>
Cc: binutils@sources.redhat.com, linux-mips@linux-mips.org
Subject: Re: Testing File systmes and drivers in linux kernel 2.4.20
Message-ID: <20040824163304.GA30528@nevyn.them.org>
Mail-Followup-To: Arravind babu <aravindforl@yahoo.co.in>,
	binutils@sources.redhat.com, linux-mips@linux-mips.org
References: <20040824132249.79568.qmail@web8201.mail.in.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040824132249.79568.qmail@web8201.mail.in.yahoo.com>
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <drow@nevyn.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: 5730
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Tue, Aug 24, 2004 at 02:22:49PM +0100, Arravind babu wrote:
> Hi all,
>  
>        We upgraded the linux kernel 2.4.14 to 2.4.20 in our MIPS based embedded device.So we are planning to test the kernel stability.For this we have to test 
>  
> File systems (RAMdisk , ROMFS , JFFS , CRAMFS) ,
> NAND driver ,
> Ethernet driver.
>  
> Is there any tools available freely to test the above things? Pls tell me if there are any tools or links todo these tasks?

Why are you sending this to the binutils list?  Don't.

-- 
Daniel Jacobowitz

From ml@bhn.be Tue Aug 24 17:52:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Aug 2004 17:52:51 +0100 (BST)
Received: from b1.ovh.net ([IPv6:::ffff:213.186.33.51]:57993 "EHLO
	mail12.ha.ovh.net") by linux-mips.org with ESMTP
	id <S8225238AbUHXQwq>; Tue, 24 Aug 2004 17:52:46 +0100
Received: (qmail 28420 invoked by uid 503); 24 Aug 2004 16:52:45 -0000
Received: from unknown (HELO benoit-portable.bhn.be) (130.104.221.254)
  by ns0.ovh.net with SMTP; 24 Aug 2004 16:52:45 -0000
Message-Id: <6.1.1.1.2.20040824185046.045e52f0@pop.perso.be>
X-Sender: postmaster@bhn.be@mail.bhn.be
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Tue, 24 Aug 2004 18:52:40 +0200
To: linux-mips@linux-mips.org
From: Benoit Auquier <ml@bhn.be>
Subject: admtek adm5120
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Return-Path: <ml@bhn.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: 5731
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ml@bhn.be
Precedence: bulk
X-list: linux-mips

hi
i'm looking for kernel sources and config for this mips-based soc.
does anyone have an idea ? I already sent mail to admtek but with no 
response at all for the moment.

thanks in advance and sorry for my bad english


From hjl@lucon.org Tue Aug 24 18:58:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Aug 2004 18:58:23 +0100 (BST)
Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:45205 "EHLO
	rwcrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8225238AbUHXR6T>; Tue, 24 Aug 2004 18:58:19 +0100
Received: from lucon.org ([24.6.43.109]) by comcast.net (rwcrmhc13) with ESMTP
          id <2004082417581201500p9k6fe>; Tue, 24 Aug 2004 17:58:12 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id B68ED63EF8; Tue, 24 Aug 2004 10:58:11 -0700 (PDT)
Date: Tue, 24 Aug 2004 10:58:11 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: Brian Burrows <brianb@p3mc.net>
Cc: linux-mips@linux-mips.org
Subject: Re: broadcom mips
Message-ID: <20040824175811.GA20768@lucon.org>
References: <WorldClient-F200408232131.AA31111179@p3mc.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <WorldClient-F200408232131.AA31111179@p3mc.net>
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: 5732
X-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

You should ask it on the mips mailing list.


H.J.
On Mon, Aug 23, 2004 at 09:31:11PM -0700, Brian Burrows wrote:
> Hello,
> 
> I am new to linux, however i have been a windows programmer for years. Well 
> , i would like to compile a simple relocatable elf for a broadcom cpu , mips 
> r3000 . I have searched and searched and I am still not capable of making my 
> own cross compiler. 
> Do you know of any pre made ones? gcc?
> Any details you can / will give me are very appreciated
> 
> cheers
> brian

From bkemp@ucentric.com Tue Aug 24 21:12:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Aug 2004 21:12:29 +0100 (BST)
Received: from messageii.ucentric.com ([IPv6:::ffff:216.140.202.124]:29195
	"EHLO messageii.ucentric.com") by linux-mips.org with ESMTP
	id <S8225238AbUHXUMZ>; Tue, 24 Aug 2004 21:12:25 +0100
Received: from [192.168.11.23] by messageii.ucentric.com with HTTP; Tue, 24 Aug 2004 16:12:16 -0400
Date: Tue, 24 Aug 2004 16:12:16 -0400
Message-ID: <40B0AFD9000003B6@messageii.ucentric.com>
In-Reply-To: <20040824175811.GA20768@lucon.org>
From: "Brad Kemp" <bkemp@ucentric.com>
Subject: Re: broadcom mips
To: "H. J. Lu" <hjl@lucon.org>, "Brian Burrows" <brianb@p3mc.net>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Return-Path: <bkemp@ucentric.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5733
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bkemp@ucentric.com
Precedence: bulk
X-list: linux-mips

>H.J.
>On Mon, Aug 23, 2004 at 09:31:11PM -0700, Brian Burrows wrote:
>> Hello,
>> 
>> I am new to linux, however i have been a windows programmer for years.
>Well 
>> , i would like to compile a simple relocatable elf for a broadcom cpu
,
>mips 
>> r3000 . I have searched and searched and I am still not capable of making
>my 
>> own cross compiler. 
>> Do you know of any pre made ones? gcc?
>> Any details you can / will give me are very appreciated
>> 
>> cheers
>> brian
>
If these don't work for you
http://www.linux-mips.org/toolchain.html
You'll have to build it yourself
http://kegel.com/crosstool/
Brad





From macleod@mail2000.com.tw Wed Aug 25 03:18:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Aug 2004 03:18:28 +0100 (BST)
Received: from bak5.mail2000.com.tw ([IPv6:::ffff:210.200.181.242]:3859 "HELO
	bak5.mail2000.com.tw") by linux-mips.org with SMTP
	id <S8225242AbUHYCSX> convert rfc822-to-8bit; Wed, 25 Aug 2004 03:18:23 +0100
Received: from 210.200.181.211
	by bak5.mail2000.com.tw with Mail2000 ESMTP Server V2.71S(369:0:AUTH_RELAY)
	Wed, 25 Aug 2004 10:18:06 +0800 (CST);
	(envelope-from <macleod@mail2000.com.tw>)
Received: By OpenMail Mailer;Wed, 25 Aug 2004 10:18:04 +0800 (CST)
From: "Macleod" <macleod@mail2000.com.tw>
Reply-To: macleod@mail2000.com.tw
Subject: Re: System call select on R4600
Message-ID: <1093400284.64232.macleod@mail2000.com.tw>
To: linux-mips@linux-mips.org
Date: Wed, 25 Aug 2004 10:18:04 +0800 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8BIT
Return-Path: <macleod@mail2000.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: 5734
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macleod@mail2000.com.tw
Precedence: bulk
X-list: linux-mips


 After trace system, found this problem is from scall_o32.S
 line 161 in 2.4.26 kernel.

 bltz t0, bad_stack   # -> sp is bad

 If stack address larger than 0x7fffffff, branch will take, 
 and that's why I got "-4142" errno on select system call
 even parameters in stack are correct. I tried to remove this
 line and seems "select" works fine.


-----Original message-----
From:Ralf Baechle <ralf@linux-mips.org>
To:Macleod <macleod@mail2000.com.tw>
Cc:linux-mips@linux-mips.org
Date:Sun, 22 Aug 2004 14:14:36 +0200
Subject:Re: System call select on R4600

On Sun, Aug 22, 2004 at 11:54:10AM +0800, Macleod wrote:

>  My problem is "select" system call always return -1
>  and errno is -4142, but sys_select has never been called.
>  Think, it has some problem on handling system call. 
>  Because if I change SYS(sys_select, 5) to 4 arguments,
>  sys_select will be executed. 
>  Thanks!

This is a bug which was fixed a while ago.  I assume your application
is picking up a bad definition from an old kernel header package or so.
Still doing syscalls directly is a fragily; better avoid and use your
libc's select(3).

  Ralf


From ralf@linux-mips.org Wed Aug 25 09:00:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Aug 2004 09:00:58 +0100 (BST)
Received: from p508B5A8A.dip.t-dialin.net ([IPv6:::ffff:80.139.90.138]:39764
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224922AbUHYIAx>; Wed, 25 Aug 2004 09:00:53 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i7P80pN2027404;
	Wed, 25 Aug 2004 10:00:51 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i7P80jkS027403;
	Wed, 25 Aug 2004 10:00:45 +0200
Date: Wed, 25 Aug 2004 10:00:45 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Macleod <macleod@mail2000.com.tw>
Cc: linux-mips@linux-mips.org
Subject: Re: System call select on R4600
Message-ID: <20040825080045.GA25537@linux-mips.org>
References: <1093400284.64232.macleod@mail2000.com.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1093400284.64232.macleod@mail2000.com.tw>
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: 5735
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Aug 25, 2004 at 10:18:04AM +0800, Macleod wrote:

>  After trace system, found this problem is from scall_o32.S
>  line 161 in 2.4.26 kernel.
> 
>  bltz t0, bad_stack   # -> sp is bad
> 
>  If stack address larger than 0x7fffffff, branch will take, 
>  and that's why I got "-4142" errno on select system call
>  even parameters in stack are correct. I tried to remove this
>  line and seems "select" works fine.

Oh yes, I forgot on this one :-)  It's intentional; making all syscalls
work from kernel mode would add some overhead.  Possible solutions:

 - move to 64-bit kernels; the 64-bit syscall interface happens to support
   upto 8 arguments for syscalls from kernel mode.
 - move your module or parts of it to userspace.  Something that's using
   select suspiciously looks like something that shouldn't be in the kernel.
 - use the proper kernel APIs.  Kernel programming isn't user space
   programming.

  Ralf

From thomas.koeller@baslerweb.com Wed Aug 25 10:28:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Aug 2004 10:28:31 +0100 (BST)
Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:52231
	"EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP
	id <S8224922AbUHYJ20>; Wed, 25 Aug 2004 10:28:26 +0100
Received: from comm1.baslerweb.com (proxy.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
          for <linux-mips@linux-mips.org>; Wed, 25 Aug 2004 11:28:11 +0200
Received: from vclinux-1.basler.corp (localhost [172.16.13.253]) by comm1.baslerweb.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id RPG51AMP; Wed, 25 Aug 2004 11:28:24 +0200
From: Thomas Koeller <thomas.koeller@baslerweb.com>
Organization: Basler AG
To: linux-mips@linux-mips.org
Subject: ioremap() and CONFIG_SWAP_IO_SPACE
Date: Wed, 25 Aug 2004 11:30:53 +0200
User-Agent: KMail/1.6.2
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200408251130.53865.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: 5736
X-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

Hi,

my platform (PMC-Sierra Yosemite in big endian mode),
like many others, uses ioremap() to map device
registers, such as the RM9000's OCD registers.
To access those registers, the return value of
ioremap() is casted to a suitable pointer type and
dereferenced. This of course works, but the return
value of ioremap() is documented not to be a
directly dereferenceable pointer value, and accesses
to ioremapped addresses should be performed using
the readx/writex APIs.

I therefore decided to straighten this out and use those
APIs throughout, but that did not work. The platform
defines 'CONFIG_SWAP_IO_SPACE=y', which causes all
accesses through readx/writex to be byte-swapped. That
is not really appropriate, as the registers are in big
endian order. I therefore tried to change that setting
in yosemite_defconfig, only to find that every time
I do 'make oldconfig' it returns to its original
value of 'y'.

So here are my questions:

1. Am I right to conclude that the platform configuration
   should not set CONFIG_SWAP_IO_SPACE, or am I missing
   something?

2. What is the mechanism that causes that setting to
   always revert to enabled when doing 'make oldconfig'?
   How do I avoid that?

thanks,
Thomas
-- 
--------------------------------------------------

Thomas Koeller, Software Development
Basler Vision Technologies

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

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

From geert@linux-m68k.org Wed Aug 25 10:32:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Aug 2004 10:32:13 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:23269 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224922AbUHYJcJ>;
	Wed, 25 Aug 2004 10:32:09 +0100
Received: from waterleaf.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i7P9W6n1025935;
	Wed, 25 Aug 2004 11:32:07 +0200 (MEST)
Date: Wed, 25 Aug 2004 11:32:06 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Thomas Koeller <thomas.koeller@baslerweb.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: ioremap() and CONFIG_SWAP_IO_SPACE
In-Reply-To: <200408251130.53865.thomas.koeller@baslerweb.com>
Message-ID: <Pine.GSO.4.58.0408251131020.18759@waterleaf.sonytel.be>
References: <200408251130.53865.thomas.koeller@baslerweb.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: 5737
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Wed, 25 Aug 2004, Thomas Koeller wrote:
> my platform (PMC-Sierra Yosemite in big endian mode),
> like many others, uses ioremap() to map device
> registers, such as the RM9000's OCD registers.
> To access those registers, the return value of
> ioremap() is casted to a suitable pointer type and
> dereferenced. This of course works, but the return
> value of ioremap() is documented not to be a
> directly dereferenceable pointer value, and accesses
> to ioremapped addresses should be performed using
> the readx/writex APIs.

In theory, ioremap() and readb() and friends are meant for PCI memory space
only. RM9000's OCD registers are not PCI memory space, so there's no strict
guarantee readb() and friends will actually work.

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 sskowron@ET.PUT.Poznan.PL Wed Aug 25 10:54:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Aug 2004 10:55:03 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:24000
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8224941AbUHYJy6>; Wed, 25 Aug 2004 10:54: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 i7P9ssJ04790
	for <linux-mips@linux-mips.org>; Wed, 25 Aug 2004 11:54:55 +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, 25 Aug 2004 11:50:55 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i7P9orB06790
	for <linux-mips@linux-mips.org>; Wed, 25 Aug 2004 11:50:53 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Wed, 25 Aug 2004 11:50:53 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: IP30 (Octane) kernel release
Message-ID: <Pine.GSO.4.10.10408251149360.6674-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: 5738
X-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

Hello!

On
  http://www.et.put.poznan.pl/~sskowron/ip30/
there is a kernel for SGI Octane. It will be unstable on single-RSS cards
(SI, SE aka ESI). A fix for this is underway.

Have fun,

Stanislaw Skowronek

--<=>--
  "You're not as old as the trees, not as young as the leaves.
   Not as free as the breeze, not as open as the seas."



From wsonguci@yahoo.com Wed Aug 25 20:35:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Aug 2004 20:35:32 +0100 (BST)
Received: from web40001.mail.yahoo.com ([IPv6:::ffff:66.218.78.19]:63911 "HELO
	web40001.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225243AbUHYTfY>; Wed, 25 Aug 2004 20:35:24 +0100
Message-ID: <20040825193458.55841.qmail@web40001.mail.yahoo.com>
Received: from [63.87.1.243] by web40001.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 12:34:58 PDT
Date: Wed, 25 Aug 2004 12:34:58 -0700 (PDT)
From: Song Wang <wsonguci@yahoo.com>
Subject: Re: Should #ifdef __KERNEL__ be added before #include <spaces.h> in asm-mips/addrspace.h ?
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040820120526.GA27130@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <wsonguci@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: 5739
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wsonguci@yahoo.com
Precedence: bulk
X-list: linux-mips

Ralf,

The problem in asm-mips/addrspace.h when including
<spaces.h> is different. The problem is the path.

spaces.h lives in asm-mips/mach-generic,

Only when compiling kernel, asm-mips/mach-generic
is in the include path, because arch/mips/Makefile
defines it.

However, when compiling the user-space apps, they
don't know how to find spaces.h when they indirectly
include <asm/addrspace.h>


-Song


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

> On Tue, Jul 20, 2004 at 05:03:56PM -0700, Song Wang
> wrote:
> 
> > Should #ifdef _KERNEL__ be added before #include
> > <spaces.h> in asm-mips/addrspace.h?
> > 
> > I think the reason is the same as when you added
> > the #ifdef __KERNEL__ before #include <spaces.h>
> > for asm-mips/page.h.
> 
> Some userspace software is expecting to get
> PAGE_SHIFT, PAGE_SIZE and
> PAGE_MASK to be available in userspace via
> <asm/page.h>, so I
> protected the inclusion of <asm/spaces.h> with
> __KERNEL__ but left
> the definitions of these symbols unprotected.
> 
>   Ralf
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

From a.voropay@vmb-service.ru Thu Aug 26 14:31:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Aug 2004 14:31:24 +0100 (BST)
Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:13190 "EHLO
	smtp.vmb-service.ru") by linux-mips.org with ESMTP
	id <S8225008AbUHZNbT>; Thu, 26 Aug 2004 14:31:19 +0100
Received: from office.vmb-service.ru ([80.73.192.47]:38413 "EHLO alec")
	by Altair with ESMTP id <S1163772AbUHZNa7>;
	Thu, 26 Aug 2004 17:30:59 +0400
Reply-To: <a.voropay@vmb-service.ru>
From: "Alec Voropay" <a.voropay@vmb-service.ru>
To: <linux-mips@linux-mips.org>
Subject: BCM6350 / 3Com 3CR860 / Linux
Date: Thu, 26 Aug 2004 17:31:46 +0400
Organization: VMB-Service
Message-ID: <004a01c48b71$085f5fd0$1701a8c0@alec>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400
Importance: Normal
Return-Path: <a.voropay@vmb-service.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: 5740
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: a.voropay@vmb-service.ru
Precedence: bulk
X-list: linux-mips

Hi!

 Does anyone have information about Broadcom
BCM6350 cpu ? There is no information at the
www.broadcom.com site(only BCM6345 and BCM6348).


 3Com has built a tiny office firewall 3CR860/3CR870
at this CPU. Overview :(one long URL)
http://www.digit-life.com/articles2/router-3com-3cr870-95/router-3com-3c
r870-95.html



P.S. JFYI: 3Com provides GPL Source code
(MIPS Linux and MIPS toolchains) for this device !
http://support.3com.com/software/officeconnect.htm


-- 
-=AV=- 


From manwithastinkydog@yahoo.com Thu Aug 26 16:30:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Aug 2004 16:30:30 +0100 (BST)
Received: from web13301.mail.yahoo.com ([IPv6:::ffff:216.136.175.37]:57175
	"HELO web13301.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225196AbUHZPaY>; Thu, 26 Aug 2004 16:30:24 +0100
Message-ID: <20040826153021.108.qmail@web13301.mail.yahoo.com>
Received: from [12.33.232.234] by web13301.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 08:30:21 PDT
Date: Thu, 26 Aug 2004 08:30:21 -0700 (PDT)
From: Ken Giusti <manwithastinkydog@yahoo.com>
Subject: bcm1250 crash in eth rx in an -old- kernel
To: linux-mips <linux-mips@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <manwithastinkydog@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: 5741
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: manwithastinkydog@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,

I'm maintaining a bcm1250-based system that's running
an old kernel based on a 2.4 release provided by
sibyte
_way_ back - around 2/6/02.

The system is stable, but we do experience a very
rare kernel oops (on the order of perhaps 1 a month).
I've monitored these crashes for awhile now, and the
stackdumps are all similar in that they appear to 
involve the bcm5682 ethernet receive path.  Not exact,
but very similar, and always involving a socket
operation (allocation, wakeup, put).

I've eyeballed the codepath, no obvious error.  The
box is constantly sending/rcving enet traffic, so this
path is taken often with no ill affects (at least,
not immediately obvious ill affects :)

Our long-term goal is to move to a newer, 2.6-based
kernel, but that won't happen for awhile.  In the
meantime I'll need to maintain this kernel.  :(

It's a longshot, but I'm hoping that these crashes 
may jog somebody's long term memory...  

thanx in advance -K

Data bus error, epc == a02a9054, ra == a0114800
Unable to handle kernel paging request at virtual
address 00000004, epc == 8022c1c4, ra == 801e0c40
$0 : 00000000 10001f00 00000006 00000000 8058db54
8f48e140 10001f01 00000000
$8 : 40000000 00000000 b0020028 10001f00 00000000
8f22a000 10001f00 00000100
$16: 00000000 00000020 00000851 8ffd88a0 8ffde180
8f22bd70 803dd290 00000400
$24: ffffffff 00000001                   8f22a000
8f22bc80 2acfd008 801e0c40
epc  : 8022c1c4    Not tainted
Status: 10001f02
Cause : 1080000c
Process mem01 (pid: 6993, stackpage=8f22a000)
Stack: 00000000 8f22bcd0 80108200 00000000 00000000
8ffdf4b0 8ffd8890 801e0c40
       00800800 8f5389c0 8f5389c0 00000002 8f4af200
00000076 8ffd88b0 8ffdf4b0
       801e11c8 8f4233a0 802acf24 10001f01 8f22bd48
ffffffff 00000000 00000006
       8ffde180 8ffde000 00000001 801e31b0 00000000
8f57d0e0 8f57d0e0 8f5389c0
       8ffd0d20 02000001 00000013 00000000 8f22bd70
80109180 8f22bd20 8010f6d0
       00000000 ...
Call Trace: [<80108200>] [<801e0c40>] [<801e11c8>]
[<802acf24>] [<801e31b0>] [<80109180>]
 [<8010f6d0>] [<80109568>] [<802acf5c>] [<802777c0>]
[<80120988>] [<8010add8>]
 [<8011ac90>] [<8010aba8>] [<8010add8>] [<802ad758>]
[<802acf08>] [<80121ca0>]
 [<802b07c0>] [<802b07b8>] [<8010369c>] [<801031fc>]
[<802d5210>]
Code: 8ca30000  2442ffff  ac820008 <ac640004> ac830000
 aca00000  aca00004  aca00008  40016000

>>RA;  a0114800 <END_OF_CODE+1fb55800/????>
>>RA;  801e0c40 <sbdma_add_rcvbuffer+110/1b0>
>>$1; 10001f00 Before first symbol
>>$4; 8058db54 <rt_cache_stat+714/800>
>>$5; 8f48e140 <END_OF_CODE+eecf140/????>
>>$6; 10001f01 Before first symbol
>>$8; 40000000 Before first symbol
>>$10; b0020028 <END_OF_CODE+2fa61028/????>
>>$11; 10001f00 Before first symbol
>>$13; 8f22a000 <END_OF_CODE+ec6b000/????>
>>$14; 10001f00 Before first symbol
>>$18; 00000851 Before first symbol
>>$19; 8ffd88a0 <END_OF_CODE+fa198a0/????>
>>$20; 8ffde180 <END_OF_CODE+fa1f180/????>
>>$21; 8f22bd70 <END_OF_CODE+ec6cd70/????>
>>$22; 803dd290 <log_buf+1bf8/8000>
>>$24; ffffffff <END_OF_CODE+7fa40fff/????>
>>$26; 8f22a000 <END_OF_CODE+ec6b000/????>
>>$27; 8f22bc80 <END_OF_CODE+ec6cc80/????>
>>$28; 2acfd008 Before first symbol
>>$29; 801e0c40 <sbdma_add_rcvbuffer+110/1b0>

>>???; 8022c1c4 <alloc_skb+244/2c0>   <=====

Trace; 80108200 <smp_call_function_interrupt+d0/148>
Trace; 801e0c40 <sbdma_add_rcvbuffer+110/1b0>
Trace; 801e11c8 <sbdma_rx_process+180/310>
Trace; 802acf24 <sb1250_spc_irq_handler+e4/220>
Trace; 801e31b0 <sbmac_intr+268/318>
Trace; 80109180 <handle_IRQ_event+98/150>
Trace; 8010f6d0 <__wake_up+150/218>
Trace; 80109568 <do_IRQ+e0/198>
Trace; 802acf5c <sb1250_spc_irq_handler+11c/220>
Trace; 802777c0 <udp_v4_mcast_deliver+110/2c0>
Trace; 80120988 <do_timer+60/c0>
Trace; 8010add8 <ll_timer_interrupt+b8/c8>
Trace; 8011ac90 <do_softirq+c0/1d0>
Trace; 8010aba8 <timer_interrupt+70/1e8>
Trace; 8010add8 <ll_timer_interrupt+b8/c8>
Trace; 802ad758 <sb1250_gettimeoffset+c8/218>
Trace; 802acf08 <sb1250_spc_irq_handler+c8/220>
Trace; 80121ca0 <deliver_signal+28/100>
Trace; 802b07c0 <spc_rtc_get_time+cf8/11e8>
Trace; 802b07b8 <spc_rtc_get_time+cf0/11e8>
Trace; 8010369c <handle_dbe_int+20/44>
Trace; 801031fc <signal_return+14/38>
Trace; 802d5210 <mask_72_64+1748/2178>

-----------------------------------

Unable to handle kernel paging request at virtual
address fffffffc, epc == 8010f618, ra == 8022bb88
$0 : 00000000 10001f00 00000001 8f552390 8f55238c
00000001 00000001 000070d9
$8 : 00007532 000070d9 00000000 10001f00 b0020028
10001f00 00000000 00080000
$16: 8f56d0e0 00000000 00000000 8f55238c 00000001
8f552390 10001f01 80306bc4
$24: 0000000e 2ac1adc8                   8f24c000
8f24db80 8f24db80 8022bb88
epc  : 8010f618    Not tainted
Status: 10001f02
Cause : 00800008
Process ps (pid: 3312, stackpage=8f24c000)
Stack: 7661722f 000001b6 00000002 726f6f74 8f56d0e0
87ed9920 00000000 00000002
       87ead044 ac103fff ac100101 00000800 802f8e40
8022bb88 8f50bae0 00000001
       8f24c000 8f24dbe8 8f2d7320 8012c678 00000000
00000000 8f56d0e0 80277690
       00000000 8012c548 8f50bae0 00000001 00000000
8f56d0e0 87ed9920 802777d8
       00000000 cf08fb17 00000000 cf08fa13 0000005c
8f515740 87ed9920 0000005c
       87ead044 ...
Call Trace: [<8022bb88>] [<8012c678>] [<80277690>]
[<8012c548>] [<802777d8>] [<80277c38>]
 [<8012cad0>] [<8013cff0>] [<8024b650>] [<8024bcc0>]
[<80232580>] [<801e0c70>]
 [<80232d40>] [<8011acb8>] [<80108470>] [<801095e8>]
[<802ace1c>] [<80168300>]
 [<8013d788>] [<8010e5c0>] [<80172110>] [<8011f350>]
[<802a6ac8>] [<80171060>]
 [<8012db78>] [<8012d778>] [<80171460>] [<80147890>]
[<801069e0>] [<801537e0>]
 [<80107510>] [<80107510>]
Code: 00c0a021  3c178030  26f76bc4 <8e23fffc> 8fc4003c
 00003021  8c620000  00441024  00000000


>>RA;  8022bb88 <sock_def_readable+58/f0>
>>$1; 10001f00 Before first symbol
>>$3; 8f552390 <END_OF_CODE+ef93390/????>
>>$4; 8f55238c <END_OF_CODE+ef9338c/????>
>>$7; 000070d9 Before first symbol
>>$8; 00007532 Before first symbol
>>$9; 000070d9 Before first symbol
>>$11; 10001f00 Before first symbol
>>$12; b0020028 <END_OF_CODE+2fa61028/????>
>>$13; 10001f00 Before first symbol
>>$15; 00080000 Before first symbol
>>$16; 8f56d0e0 <END_OF_CODE+efae0e0/????>
>>$19; 8f55238c <END_OF_CODE+ef9338c/????>
>>$21; 8f552390 <END_OF_CODE+ef93390/????>
>>$22; 10001f01 Before first symbol
>>$23; 80306bc4 <write_fifo_fops+2c/48>
>>$25; 2ac1adc8 Before first symbol
>>$26; 8f24c000 <END_OF_CODE+ec8d000/????>
>>$27; 8f24db80 <END_OF_CODE+ec8eb80/????>
>>$28; 8f24db80 <END_OF_CODE+ec8eb80/????>
>>$29; 8022bb88 <sock_def_readable+58/f0>

>>???; 8010f618 <__wake_up+98/218>   <=====

Trace; 8022bb88 <sock_def_readable+58/f0>
Trace; 8012c678 <do_anonymous_page+388/398>
Trace; 80277690 <udp_queue_rcv_skb+338/358>
Trace; 8012c548 <do_anonymous_page+258/398>
Trace; 802777d8 <udp_v4_mcast_deliver+128/2c0>
Trace; 80277c38 <udp_rcv+1b8/3b8>
Trace; 8012cad0 <do_no_page+448/450>
Trace; 8013cff0 <_alloc_pages+28/38>
Trace; 8024b650 <ip_local_deliver+2c8/370>
Trace; 8024bcc0 <ip_rcv+5c8/770>
Trace; 80232580 <netif_rx+198/230>
Trace; 801e0c70 <sbdma_add_rcvbuffer+140/1b0>
Trace; 80232d40 <net_rx_action+280/590>
Trace; 8011acb8 <do_softirq+e8/1d0>
Trace; 80108470 <flush_tlb_range_ipi+20/30>
Trace; 801095e8 <do_IRQ+160/198>
Trace; 802ace1c <sb1250_irq_handler+15c/180>
Trace; 80168300 <get_empty_inode+d8/f0>
Trace; 8013d788 <free_pages+30/40>
Trace; 8010e5c0 <nopage_tlbs+104/124>
Trace; 80172110 <proc_pid_make_inode+28/128>
Trace; 8011f350 <access_process_vm+240/2b0>
Trace; 802a6ac8 <src_unaligned_dst_aligned+28/50>
Trace; 80171060 <proc_pid_cmdline+b0/170>
Trace; 8012db78 <do_mmap_pgoff+4e8/608>
Trace; 8012d778 <do_mmap_pgoff+e8/608>
Trace; 80171460 <proc_info_read+70/1a8>
Trace; 80147890 <sys_read+128/150>
Trace; 801069e0 <old_mmap+c8/100>
Trace; 801537e0 <sys_fstat64+78/a8>
Trace; 80107510 <stack_done+1c/38>
Trace; 80107510 <stack_done+1c/38>


------------------------------------


skput:over: 801ea5e8:118 put:118 dev:kernel BUG at
skbuff.c:100!
Unable to handle kernel paging request at virtual
address 00000000, epc == 802365ac, ra == 801ea600
Oops (core 0) in fault.c:do_page_fault, line 232:
$0 : 00000000 10001f00 0000001c 87e70000 8f413c5c
00000001 00000000 00001598
$8 : 00001598 fffffeff 00000000 0000000d b0020028
10001f00 00000000 00000100
$16: 8f4b8940 00000076 87fd3f00 87fd94b0 87fd8180
8f413d90 7fff7f22 00000000
$24: ffffffff 00000002                   8f412000
8f413cc8 8f38f750 801ea600
Hi : 00196604
Lo : 000cb302
epc  : 802365ac    Not tainted
Status: 10001f03
Cause : 1080000c
Process ps (pid: 31029, stackpage=8f412000)
Stack: 802d8e10 802d8e28 00000064 ffffffff 802d8e34
87fd94b0 801ea600 840e9538
       8023d4e0 841105e4 8023d4e0 00000001 00000000
00000006 87fd8180 87fd8000
       00000001 801ec570 00000000 80306890 fffffffb
00000000 8ffd0a14 02000001
       00000013 00000000 8f413d90 80109220 8010ac88
8010ad08 00000000 8f413d90
       80305280 8ffd0a14 00000000 00000013 fffffffb
80109608 00800800 00000f22
       00000002 ...
Call Trace: [<802d8e10>] [<802d8e28>] [<802d8e34>]
[<801ea600>] [<8023d4e0>] [<8023d4e0>]
 [<801ec570>] [<80109220>] [<8010ac88>] [<8010ad08>]
[<80109608>] [<802baa18>]
 [<802ba23c>] [<8010e590>] [<80177f10>] [<80178850>]
[<80120280>] [<802b3fac>]
 [<80176e60>] [<8012ed68>] [<8012e968>] [<80177260>]
[<8014ad50>] [<80106a80>]
 [<80157670>] [<801075b0>] [<801075b0>]
Code: 0c045546  24060064  8fbf0018  03e00008  27bd0020
 3c02802e  24428e34  0808d962 
In interrupt handler - not syncing

>>RA;  801ea600 <sbdma_rx_process+228/310>
>>$1; 10001f00 Before first symbol
>>$3; 87e70000 <END_OF_CODE+789f000/????>
>>$4; 8f413c5c <END_OF_CODE+ee42c5c/????>
>>$7; 00001598 Before first symbol
>>$8; 00001598 Before first symbol
>>$9; fffffeff <END_OF_CODE+7fa2eeff/????>
>>$12; b0020028 <END_OF_CODE+2fa4f028/????>
>>$13; 10001f00 Before first symbol
>>$16; 8f4b8940 <END_OF_CODE+eee7940/????>
>>$18; 87fd3f00 <END_OF_CODE+7a02f00/????>
>>$19; 87fd94b0 <END_OF_CODE+7a084b0/????>
>>$20; 87fd8180 <END_OF_CODE+7a07180/????>
>>$21; 8f413d90 <END_OF_CODE+ee42d90/????>
>>$22; 7fff7f22 Before first symbol
>>$24; ffffffff <END_OF_CODE+7fa2efff/????>
>>$26; 8f412000 <END_OF_CODE+ee41000/????>
>>$27; 8f413cc8 <END_OF_CODE+ee42cc8/????>
>>$28; 8f38f750 <END_OF_CODE+edbe750/????>
>>$29; 801ea600 <sbdma_rx_process+228/310>

>>???; 802365ac <skb_over_panic+4c/68>   

Trace; 802d8e10 <midplane_to_slot_c_table+3160/474c>
Trace; 802d8e28 <midplane_to_slot_c_table+3178/474c>
Trace; 802d8e34 <midplane_to_slot_c_table+3184/474c>
Trace; 801ea600 <sbdma_rx_process+228/310>
Trace; 8023d4e0 <net_rx_action+280/590>
Trace; 8023d4e0 <net_rx_action+280/590>
Trace; 801ec570 <sbmac_intr+298/318>
Trace; 80109220 <handle_IRQ_event+98/150>
Trace; 8010ac88 <local_timer_interrupt+b0/c0>
Trace; 8010ad08 <timer_interrupt+70/1e8>
Trace; 80109608 <do_IRQ+e0/198>
Trace; 802baa18 <sb1250_timer_interrupt+b8/e0>
Trace; 802ba23c <sb1250_irq_handler+15c/180>
Trace; 8010e590 <nopage_tlbl+104/114>
Trace; 80177f10 <proc_pid_make_inode+28/130>
Trace; 80178850 <proc_pid_lookup+1f8/2d8>
Trace; 80120280 <access_process_vm+240/2b0>
Trace; 802b3fac <l_exc+1c/34>
Trace; 80176e60 <proc_pid_cmdline+b0/170>
Trace; 8012ed68 <do_mmap_pgoff+4e8/608>
Trace; 8012e968 <do_mmap_pgoff+e8/608>
Trace; 80177260 <proc_info_read+70/1a8>
Trace; 8014ad50 <sys_read+128/150>
Trace; 80106a80 <old_mmap+c8/100>
Trace; 80157670 <sys_fstat64+78/a8>
Trace; 801075b0 <stack_done+1c/38>
Trace; 801075b0 <stack_done+1c/38>




		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

From manwithastinkydog@yahoo.com Thu Aug 26 16:45:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Aug 2004 16:46:00 +0100 (BST)
Received: from web13303.mail.yahoo.com ([IPv6:::ffff:216.136.175.39]:52334
	"HELO web13303.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225196AbUHZPpz>; Thu, 26 Aug 2004 16:45:55 +0100
Message-ID: <20040826154553.39496.qmail@web13303.mail.yahoo.com>
Received: from [12.33.232.234] by web13303.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 08:45:53 PDT
Date: Thu, 26 Aug 2004 08:45:53 -0700 (PDT)
From: Ken Giusti <manwithastinkydog@yahoo.com>
Subject: Re: bcm1250 crash in eth rx in an -old- kernel
To: linux-mips <linux-mips@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <manwithastinkydog@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: 5742
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: manwithastinkydog@yahoo.com
Precedence: bulk
X-list: linux-mips

s/bcm5682/bcm1250/g  - sorry.... -K

--- Ken Giusti <manwithastinkydog@yahoo.com> wrote:

> Hi,
> 
> I'm maintaining a bcm1250-based system that's
<snip>
> I've monitored these crashes for awhile now, and the
> stackdumps are all similar in that they appear to 
> involve the bcm5682 ethernet receive path.  Not
> exact,
> but very similar, and always involving a socket
> operation (allocation, wakeup, put).
<snip>


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

From ranidavuluri@yahoo.com Fri Aug 27 01:28:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Aug 2004 01:28:48 +0100 (BST)
Received: from web50307.mail.yahoo.com ([IPv6:::ffff:206.190.38.61]:52093 "HELO
	web50307.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225204AbUH0A2o>; Fri, 27 Aug 2004 01:28:44 +0100
Message-ID: <20040827002837.82864.qmail@web50307.mail.yahoo.com>
Received: from [66.237.41.195] by web50307.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 17:28:37 PDT
Date: Thu, 26 Aug 2004 17:28:37 -0700 (PDT)
From: usha davuluri <ranidavuluri@yahoo.com>
Subject: Vmlinux-2.4.18 booting problems on Malta
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <ranidavuluri@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: 5743
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ranidavuluri@yahoo.com
Precedence: bulk
X-list: linux-mips

* Exception (user) : Reserved instruction *
BadVAddr = 0x1ab0fe99  Cause    = 0x10808028
Compare  = 0x31a7e5fd  Config   = 0x80030083
Config1  = 0x1e9b4d8a  Context  = 0x7f0d5870
Count    = 0xf7cab5a2  DEPC     = 0x9bef8df4
Debug    = 0x0000dc3f  EPC      = 0x802e0024
EntryHi  = 0xa2fa40b3  EntryLo0 = 0x03ec7dee
EntryLo1 = 0x0290455c  ErrorEPC = 0x8002c34c
Index    = 0x0000000f  PRId     = 0x00018001
PageMask = 0x01974000  Random   = 0x00000007
Status   = 0x10002c02  WatchHi  = 0x00000000
WatchLo  = 0x00000000  Wired    = 0x00000000
Hi       = 0x00000013  Lo       = 0x53f7ceea

$ 0(zr):0x00000000  $ 8(t0):0x00000000 
$16(s0):0x00000000  $24(t8):0x00000000
$ 1(at):0x00000000  $ 9(t1):0x00000000 
$17(s1):0x00000000  $25(t9):0x00000000
$ 2(v0):0x00000000  $10(t2):0x00000000 
$18(s2):0x00000000  $26(k0):0x00000000
$ 3(v1):0x00000000  $11(t3):0x00000000 
$19(s3):0x00000000  $27(k1):0x00000000
$ 4(a0):0x00000002  $12(t4):0x10002c00 
$20(s4):0x00000000  $28(gp):0x802e0000
$ 5(a1):0x800a9770  $13(t5):0x1000001f 
$21(s5):0x00000000  $29(sp):0x800b3840
$ 6(a2):0x8006a4f0  $14(t6):0x00000000 
$22(s6):0x00000000  $30(s8):0x800b3840
$ 7(a3):0x04000000  $15(t7):0x00000000 
$23(s7):0x00000000  $31(ra):0x8003bd60

Hi all,
 I am getting the above error output when I say go
(starting address) after loading the kernel source.
please help me on this.
Thank you,
 Usha.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From belracu22@rediffmail.com Fri Aug 27 02:49:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Aug 2004 02:49:43 +0100 (BST)
Received: from webmail28.rediffmail.com ([IPv6:::ffff:203.199.83.38]:15959
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225204AbUH0Bth>; Fri, 27 Aug 2004 02:49:37 +0100
Received: (qmail 29842 invoked by uid 510); 27 Aug 2004 01:49:29 -0000
Date: 27 Aug 2004 01:49:29 -0000
Message-ID: <20040827014929.29841.qmail@webmail28.rediffmail.com>
Received: from unknown (61.220.211.195) by rediffmail.com via HTTP; 27 aug 2004 01:49:29 -0000
MIME-Version: 1.0
From: "bel racu" <belracu22@rediffmail.com>
Reply-To: "bel racu" <belracu22@rediffmail.com>
To: binutils@sources.redhat.com
Cc: linux-mips@linux-mips.org, aravindforl@yahoo.co.in
Subject: Re:
Content-type: multipart/alternative;
	boundary="Next_1093571369---0-203.199.83.38-29837"
Return-Path: <belracu22@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5744
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: belracu22@rediffmail.com
Precedence: bulk
X-list: linux-mips

 This is a multipart mime message


--Next_1093571369---0-203.199.83.38-29837
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0A<BR>=0A&gt;From:Arravind babu &lt;aravindforl@yahoo.co.in&gt; | Add t=
o Address Book | &gt;This is spam &nbsp; &nbsp; &nbsp;<BR>=0A&gt;To:&nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;binutils@sources.redhat.com<BR>=0A&gt;Subject:&n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp;Testing File systmes and drivers in linux k=
ernel 2.4.20<BR>=0A&gt;Date:&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Tue, 24 Aug 2=
004 22:03:47 IST<BR>=0A&gt;Cc:&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;linux-mips@=
linux-mips.org<BR>=0A&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  Note:&nbsp;  T=
o help protect your privacy, images from this &gt;message have been blocked=
.View images | What is this?<BR>=0A&gt;&nbsp; &nbsp; &nbsp;<BR>=0A&gt;Hi al=
l,<BR>=0A&gt; <BR>=0A&gt;&nbsp; &nbsp; &nbsp;  We upgraded the linux kernel=
 2.4.14 to 2.4.20 in our MIPS based &gt;embedded device.So we are planning =
to test the kernel stability.For &gt;this we have to test<BR>=0A&gt; <BR>=
=0A&gt;File systems (RAMdisk , ROMFS , JFFS , CRAMFS) ,<BR>=0A&gt;NAND driv=
er ,<BR>=0A&gt;Ethernet driver.<BR>=0A&gt; <BR>=0A&gt;Is there any tools av=
ailable freely to test the above things? Pls tell &gt;me if there are any t=
ools or links todo these tasks?<BR>=0A<BR>=0AFrom 2.4.18 to 2.4.20 there is=
 not much of change in the code for <BR>=0ARamdisk .Romfs Jffs and Cramfs..=
. except for&nbsp; --JFFS2 oops fixing...<BR>=0A<BR>=0ASee&nbsp; http://ltp=
.sourceforge.net/tooltable.php if u find some tools.<BR>=0ABut the best way=
 is ti write some simple programs to do ur own test,,<BR>=0Aand then make t=
hat code Open.<BR>=0A<BR>=0A&gt; <BR>=0A&gt;Thanks in advance,<BR>=0A&gt;Ar=
avind.=0A</P>=0A<br><br>=0A<A target=3D"_blank" HREF=3D"http://clients.redi=
ff.com/signature/track_sig.asp"><IMG SRC=3D"http://ads.rediff.com/RealMedia=
/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=3D0 VSPACE=
=3D0 HSPACE=3D0></a>=0A
--Next_1093571369---0-203.199.83.38-29837
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=0A>From:Arravind babu <aravindforl@yahoo.co.in> | Add to Address Book | >T=
his is spam 	=0A>To:    	binutils@sources.redhat.com=0A>Subject:    	Testin=
g File systmes and drivers in linux kernel 2.4.20=0A>Date:    	Tue, 24 Aug =
2004 22:03:47 IST=0A>Cc:    	linux-mips@linux-mips.org=0A>           Note: =
  To help protect your privacy, images from this >message have been blocked=
.View images | What is this?=0A>	=0A>Hi all,=0A> =0A>       We upgraded the=
 linux kernel 2.4.14 to 2.4.20 in our MIPS based >embedded device.So we are=
 planning to test the kernel stability.For >this we have to test=0A> =0A>Fi=
le systems (RAMdisk , ROMFS , JFFS , CRAMFS) ,=0A>NAND driver ,=0A>Ethernet=
 driver.=0A> =0A>Is there any tools available freely to test the above thin=
gs? Pls tell >me if there are any tools or links todo these tasks?=0A=0AFro=
m 2.4.18 to 2.4.20 there is not much of change in the code for =0ARamdisk .=
Romfs Jffs and Cramfs... except for  --JFFS2 oops fixing...=0A=0ASee  http:=
//ltp.sourceforge.net/tooltable.php if u find some tools.=0ABut the best wa=
y is ti write some simple programs to do ur own test,,=0Aand then make that=
 code Open.=0A=0A> =0A>Thanks in advance,=0A>Aravind.
--Next_1093571369---0-203.199.83.38-29837--


From chris@mips.com Fri Aug 27 14:36:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Aug 2004 14:36:26 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:53004 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224986AbUH0NgW>;
	Fri, 27 Aug 2004 14:36:22 +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 1C0h4Y-0002Gm-00; Fri, 27 Aug 2004 14:47:18 +0100
Received: from holborn.mips.com ([192.168.192.237] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1C0gtb-0003fO-00; Fri, 27 Aug 2004 14:35:59 +0100
Message-ID: <412F38BF.4000101@mips.com>
Date: Fri, 27 Aug 2004 14:35:59 +0100
From: Chris Dearman <chris@mips.com>
Organization: MIPS Technologies (UK)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: usha davuluri <ranidavuluri@yahoo.com>
CC: linux-mips@linux-mips.org
Subject: Re: Vmlinux-2.4.18 booting problems on Malta
References: <20040827002837.82864.qmail@web50307.mail.yahoo.com>
In-Reply-To: <20040827002837.82864.qmail@web50307.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-3.907, required 4, AWL,
	BAYES_00, USER_AGENT_MOZILLA_UA)
Return-Path: <chris@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5745
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chris@mips.com
Precedence: bulk
X-list: linux-mips

usha davuluri wrote:
> * Exception (user) : Reserved instruction *

> Debug    = 0x0000dc3f  EPC      = 0x802e0024

> Hi all,
>  I am getting the above error output when I say go
> (starting address) after loading the kernel source.
> please help me on this.
> Thank you,
>  Usha.


   Make sure you're really building a Malta kernel of the correct 
endianess and CPU type.  It's easy to load a big-endian kernel on a 
little endian board when using srecord downloads.

   Try disassembling the code at 0x802e0024 to see if it makes sense:
YAMON> dis 0x802e0024

   You didn't say what CPU you were using.  It's possible that the 
kernel is really using an instruction (eg a cacheop) that is not 
supported by your CPU.

	Chris

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

From megharaj@isofttech.com Fri Aug 27 15:13:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Aug 2004 15:13:22 +0100 (BST)
Received: from illchn-static-203.199.202.17.vsnl.net.in ([IPv6:::ffff:203.199.202.17]:58898
	"EHLO pub.isofttechindia.com") by linux-mips.org with ESMTP
	id <S8224986AbUH0ONS>; Fri, 27 Aug 2004 15:13:18 +0100
Received: from MEGHARAJISOFTT (JagdeepRao.isofttechindia.com [192.168.0.223] (may be forged))
	by pub.isofttechindia.com (8.11.0/8.11.0) with SMTP id i7RECXD21903
	for <linux-mips@linux-mips.org>; Fri, 27 Aug 2004 19:42:33 +0530
Message-ID: <004701c48c3f$e5b3f160$df00a8c0@MEGHARAJISOFTT>
From: "Megharaj" <megharaj@isofttech.com>
To: <linux-mips@linux-mips.org>
Subject: freeswa-ipsec for mips architecture.
Date: Fri, 27 Aug 2004 19:42:28 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0042_01C48C6D.FC652EF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-MailScanner: Found to be clean
Return-Path: <megharaj@isofttech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5746
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: megharaj@isofttech.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

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

hi,

i m new to this group.

i am trying to port freeswan(ipsec) for mips processor.

any useful links regarding freeswan(ipsec) porting to mips architecture.

Thnx n rgds.



------=_NextPart_000_0042_01C48C6D.FC652EF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>i m new to this group.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>i am trying to&nbsp;port freeswan(ipsec) f=
or mips=20
processor.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>any&nbsp;useful links regarding freeswan(i=
psec)=20
porting to mips architecture.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thnx n rgds.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0042_01C48C6D.FC652EF0--


From eokerson@texasconnect.net Fri Aug 27 15:45:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Aug 2004 15:45:42 +0100 (BST)
Received: from dallas.texasconnect.net ([IPv6:::ffff:208.232.232.3]:38672 "EHLO
	dallas.texasconnect.net") by linux-mips.org with ESMTP
	id <S8224986AbUH0Opi>; Fri, 27 Aug 2004 15:45:38 +0100
Received: from dallas.texasconnect.net (dallas.texasconnect.net [208.232.232.3])
	by dallas.texasconnect.net (8.12.9/8.12.9) with ESMTP id i7REjMic032762;
	Fri, 27 Aug 2004 09:45:22 -0500
Date: Fri, 27 Aug 2004 09:45:22 -0500 (CDT)
From: Ed Okerson <eokerson@texasconnect.net>
To: Megharaj <megharaj@isofttech.com>
cc: linux-mips@linux-mips.org
Subject: Re: freeswa-ipsec for mips architecture.
In-Reply-To: <004701c48c3f$e5b3f160$df00a8c0@MEGHARAJISOFTT>
Message-ID: <Pine.LNX.4.44.0408270944170.8861-100000@dallas.texasconnect.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <eokerson@texasconnect.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: 5747
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eokerson@texasconnect.net
Precedence: bulk
X-list: linux-mips

Have a look at OpenSwan.  FreeSwan is dead.  I believe the folks working
on the Linksys WRT54G hacking already have this working.

On Fri, 27 Aug 2004, Megharaj wrote:

> hi,
>
> i m new to this group.
>
> i am trying to port freeswan(ipsec) for mips processor.
>
> any useful links regarding freeswan(ipsec) porting to mips architecture.
>
> Thnx n rgds.
>
>
>


From delivery@hosyou-r.mine.nu Tue Aug 31 11:55:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 Aug 2004 11:55:26 +0100 (BST)
Received: from p2057-ipad70marunouchi.tokyo.ocn.ne.jp ([IPv6:::ffff:220.97.27.57]:57541
	"EHLO hosyou-r.mine.nu") by linux-mips.org with ESMTP
	id <S8224920AbUHaKzV>; Tue, 31 Aug 2004 11:55:21 +0100
Received: from hosyou-r.mine.nu (unknown [192.168.3.80])
	by hosyou-r.mine.nu (Postfix) with ESMTP id 2D8F35540DD
	for <linux-mips@linux-mips.org>; Tue, 31 Aug 2004 19:53:01 +0900 (JST)
Message-ID: <8224390.1093949581241.JavaMail.postgres@hosyou-r.mine.nu>
Date: Tue, 31 Aug 2004 19:53:01 +0900 (JST)
From: =?iso-2022-jp?Q?=1B=24B7P=3AQJ88K=25a=25k=25=5E=25=2C=1B=28B?= 
	<delivery@hosyou-r.mine.nu>
To: linux-mips@linux-mips.org
Subject: =?iso-2022-jp?Q?=1B$B!vL$>5Bz$H9XFI=3F=3D$79~=1B(B?=
 =?iso-2022-jp?Q?=1B$B$=5F9-9p"#=1B(B6=1B$B@iK|1=5F$G:#=1B(B?=
 =?iso-2022-jp?Q?=1B$B$NG:$=5F2r7h"##6@iK|1=5F$GG/6bIT0B$O2r7h$NJ}=1B(B?=
 =?iso-2022-jp?Q?=1B$BK!$O$"$j$^$9"#G/6b$O9q0MB8$GHa7`!&<+8J@U=1B(B?=
 =?iso-2022-jp?Q?=1B$BG$$G=1B(B8=1B$B@iK|1=5F"#7J5$2s=1B(B?=
 =?iso-2022-jp?Q?=1B$BI|3+;O$N;~$3$=3D%A%c%s%9=1B(B?=
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Return-Path: <delivery@hosyou-r.mine.nu>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5748
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: delivery@hosyou-r.mine.nu
Precedence: bulk
X-list: linux-mips

linux-mips@linux-mips.org$BMM(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!7P:QJ88K%a%k%^%,C4Ev!'LpBt(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!<u?.5qH]$9$k>l9g$O$=$N;]!!(Bhttp://gogoway.orgdns.org/melmaga/teishi.html$B$^$G(B
$B!!!!!!!!!!!!!!!!!!%a!<%k%^%,%8%s9XFI$N?=$79~$N>l9g$O!"$=$N;]$r!!(Bhttp://gogoway.orgdns.org/melmaga/$B!!$^$G(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!J0-5:$GB>?M$N9XFI$N?=$79~$r$5$l$?$N$,L$>5Bz9-9p!&K\?M?=$79~$_$O>5Bz9-9p!K!!(B
$B!!!!!!!!!!!!!!%a!<%k%^%,%8%s9-9p?=$79~$_$O!"$=$N;]$r(Bhttp://gogoway.orgdns.org/doc/honmousikomi.htm$B!!$^$G(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$=$NB>$NI=<(;v9`$O!"FC>&K!$K$h$j!"3F9-9p$N%j%s%/@h$KI=<((B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B
$B!!(B----$B#6@iK|1_$GG/6bIT0B$O2r7h(B----$BJ}K!$O$"$j$^$9!*(B------$B#6@iK|1_0J2<G/<}$NJ}$KBg4?7^$5$l$F$$$^$9(B--------$B!!(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!K\F|$N(B[$B$a!<$k$^$,$N(I@2DY(B]$B$O!]!Z=PMh$k!&$G$-$k!<#2#0:P0J>e$NCK=w$J$i=PMh$k![(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!:#$NG:$_$O!&!&!&#5@iK|1_$G2r7h=PMh$k!*L\E*$K$b;HMQ=PMh$k!*@83h8~>e=PMh$k(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!>-Mh$NIT0B$O!&!&!&#6@iK|1_Cy6b$G0B?4=PMh$k!*0B?48~>e$N:`NA$O;q6b$G=PMh$k!*(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=PMh$k$NJ}K!$OM-$j$^$9!<G<F@$7$?=PMh$kJ}K!$rDs6!$G$-$k%a%k%^%,$G$9!#(B

$B"!(,!N=PMh$k#P#R!O(,(,7J5$$O5^2sI|3+;O$7$^$7$?(,"#(B $B#22/1_!"(B $B#32/1_!"(B $B#52/#9@iK|1_<}F~<TB3=P$7$F$$$^$9!~"!(B

      $B4JC1$K:_Bp$G=PMh$k!T#52/#9@iK|1_>Z5rM-<}F~%S%8%M%9!U7P1D<TJg=8!<#2#0:P0J>eCK=w?=$79~$_=PMh$^$9!#(B
$B!!!!!!I{6H!&7s6H!&EZF|7P1D<T!&:_BpM>2K3hMQ7P1D<T!&Bh#2$N9b3[<}F~4uK><T!&1#$l2/K|D9<T4uK>$NJ}!9$KBg9%I>!*(B
$B!!!!!!!!(B
$B!!!!!!!!#3#8G/$N<B@SM-$j$^$9!#<}F~$O6d9T?6$j9~$_$G$9!#HkL)$K7P1D=PMh$^$9!#:G=i$O#3@iK|1_L\E*$K=PMh$^$9!#(B
$B!!!!!!!!3+6H$N%[!<%`%Z!<%8$OMQ0U$7$F$"$j$^$9$N$G%@%s%m!<%I$7$F#H#P:n@.$NLLE]$O$J$/Aa$/3+6H$G$-$k!#(B

$B!!!!!!!!!!!z(B--$B!~(B-$B#5@iK|1_Cy6b!&!&#32/1_$N;v6H;q6b!&!&O78e$N$?$a$K#4@iK|1_!&!&!z(B--$B!~(B--$B!z(B--$B"!(B
            
$B!!!!!!!!!!!!!!!!!!!!!!!!(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!>\$7$/$O(B     http://newjapan.orgdns.org/$B!!(B
$B!!(B
$B!!(B      $B2?;v$bO@$h$j>Z5r!&1=$h$j>Z5r!&>u67>Z5r$h$jJ*E*>Z5r!&:[H=41$HF1$8J*E*>Z5r$N$_$G;v<B3NG'!*(B

*-----$B#P#R(B------------------------------------------------------------------------------------------------*
 
$B!!!!!!!Z2H;v$r$7$J$,$i:_Bp%S%8%M%9![(B       $B9%$-$J;~4V$K%5%$%I%S%8%M%9(B! $B$7$+$b!V40A4:_Bp!W"v(B

$B!!(B $B$@$C$F<gIX$,N)$A>e$2$?$s$@$b$s(B! $BM%$7$5$,(B $B$$!A$C$Q$$(B o(^$B"&(B^)o$B=i$a$F$NI{<}F~$OMb7n$K$b$i$($?$o(B(*^-$B!,(B)v

                    $B!z(B:*:$B!y(B    http://www.powz.ne.nu    $B!y(B:*:$B!z(B
*-----$B#P#R(B------------------------------------------------------------------------------------------------*

                   $B#87n%W%l%*!<%W%sFCJL1o8NJg=8$N30;q7O%M%C%H%o!<%/4k6H$N0lHL8xJgOH(B

$B!!!!!!!!!!(B            $B!!(B           http://askmebiz.net/click/2/ad5.cgi
$B!z!y(B $B!2#P#R!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!y!z!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!y!z(B
$B!!(B
                   $B1?L?$rJQ$($k%o%s%/%j%C%/$bM-$j$^$9!#!!FCJL5.IP@J!!;D$j$o$:$+(B

                    *-------------------------------------------------------*
$B!z(Bo(^$B"`(B^o)  $BKhF|$,%a%C%A%c3Z$7$$$s$G$9$%$%!<!*!*(B (o^$B"`(B^)o$B!z(B           $B$^$5$+$3$s$JF|$,Mh$k$J$s$F$'$'!<!*(B
$B!!!!(B    $B!!(B   $BK\Ev$K?.$8$i$l$J!A!A!A$$!*!*(B($B!f"`!e(B)
           
                                  http://www.geocities.jp/chip0211/
 
                       $B$"$C$?$s$G$9!A!*!!(B $BC/$K$G$b=PMh$k!Z:_Bp![$N;E;v$,$!$!!*(B
    *-------$B#P#R(B--------------------------------------------------------------------------------------*

              $B"#"#(B  $B%9%?!<%H$O!"7n$K!V#5K|$G$b2T$2$l$P$C!*!W$C$F46$8$@$C$?$s$G$9!#"#"#(B

$B!!!!!!!!!!!!(B            $B$^$5$+!"G/<}!!$_$?$$$J!!!c7n<}!d!!$K$J$k$J$s$F!*(B
$B!!!!!!!!!!!!!!(B
           $B"""#""!!(B  $B!!!!<B:]$K2T$2$?OC$G$9"*(B  http://www.pre-get.or.tv/riepon/    $B"""#""(B
                     *-------------------------------------------------------*
                                         $B$($S$MMv$N8rG[(B
 http://www2.megax.ne.jp/ebine/   $B8rG[$G?72V$N:n=P(B  $BL4$N?'!!@D?'$rDI$$5a$a$F6=L#$N$"$kJ}$4K,Ld$/$@$5$$(B
                                      $BHNGd$bCW$7$F$*$j$^$9(B
*------$B#P#R(B-----------------------------------------------------------------------------------------------*

                                     http://www.geocities.jp/jabez_japan/
                $B9bB.;f@^$j5!!"9bB.;fJ>7W;;5!!"9bB.%3%$%s%+%&%s%?!<!"%3%$%sA*JL5!$G(B
                                        $B;vL3:n6H$r9bB.$G=hM}$7$^$9!#(B

*------$B#P#R(B-----------------------------------------------------------------------------------------------*

                $BL5NABN83HG40Hw!*7n3[ITMWGd@Z$j$N7HBSEEOC8~$1%Q%:%k%2!<%`@lLg%5%$%H!#(B
 $B%"!<%1!<%I$d(BPS$B$G?M5$$rGn$7$?!V%Q%:%k!<%W!W$d!"2{$+$7$N!V$@$k$^F;>l!W!"!VBgGW:V!W$,$"$J$?$N7HBS$GM7$Y$^$9!*(B
$B!!!!!!!!!!!J(BBREW$B!"(BVodafone$BBP1~!K(B $B#1%"%W%j!o#1#5#7!A$G$9$N$G!"$*;E;v$N9g4V$N$A$g$C$H$7$?B)H4$-$K(B
$B!!$*5$7Z$K@'Hs$4MxMQ2<$5$$"v(B               http://www.metro-japan.com/mobile/index.html

 $B!z(B--$B!~(B-$B!N(BPR]-$B!z(B--$B"!(B--$B!z(B--$B!~(B--$B!z!z(B-$B!Z2H;v$r$7$J$,$i:_Bp%S%8%M%9![(B-$B!~(B--$B!z(B--$B"!(B--$B!z=i$a$F$NI{<}F~$OMb7n(B--$B!~(B-$B!z(B

 $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!Z2H;v$r$7$J$,$i:_Bp%S%8%M%9![(B
$B!!(B $B9%$-$J;~4V$K%5%$%I%S%8%M%9(B! $B$7$+$b!V40A4:_Bp!W"v$@$C$F<gIX$,N)$A>e$2$?$s$@$b$s(B! $BM%$7$5$,(B $B$$!A$C$Q$$(B o
       
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!z(B:*:$B!y(B    http://www.powz.ne.nu    $B!y(B:*:$B!z(B
 
$B!!!z(B:*:$B!y(B    $B!y(B:*:$B!z!z(B:*:$B!y(B    $B!y(B:*:$B!z!z(B:*:$B!y(B    $B!y(B:*:$B!z!z(B:*:$B!y(B    $B!y(B:*:$B!z!z(B:*:$B!y(B    $B!y(B:*:$B!z!z(B:*:$B!y(B    *:$B!z(B


 $B!!!!!}!!K\F|$bEj9F!*$"$j$,$H$&$4$6$$$^$7$?"v!}%a%k%^%,H/9T<T!d8D?M$N7J5$2sI|;Y1g$H$*E75$>pJs<R(B

$B"#LH@U;v9`Ev%a!<%k%^%,%8%s$K7G:\$7$F$$$k>pJs$K4X$7$FH/9T<T$G$O0l@Z$N@UG$$rIi$$$^$;$s!#(B
$B!!0l@Z$N@UG$$rIi$$$+$M$^$9$N$G$4N;>5$/$@$5$$!#7G:\5-;v$K4X$9$k$*Ld$$9g$o$;$OD>@\Ej9F<T$X$*4j$$$$$?$7$^$9!#(B

$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(,(,!Z9-9pEj9F?o;~Jg=8Cf(B !!$B![(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"!9-9p!!#52s7G:\!\%l%s%?%k%9%Z!<%99-9p#3#0F|7G:\$G#3#0#0#01_"!(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"!9-9p!!#72s7G:\!\%l%s%?%k%9%Z!<%99-9p#4#5F|7G:\$G#4#0#0#01_"!(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"!9-9p#1#02s7G:\!\%l%s%?%k%9%Z!<%99-9p#6#0F|7G:\$G#5#0#0#01_"!(B
$B!!!!!!!!(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B
$B"#!!%"%I%l%9$G2r=|!~K\%a%k%^%,$NG[?.ITMW!"$^$?$OEPO?$7$?3P$($N$J$$>l9g$O<!$N%"%I%l%9$G2r=|$*4j$$CW$7$^$9!#(B
$B!!!!!!!!!!!!!!!!!!!!(Bhttp://gogoway.orgdns.org/melmaga/teishi.html $BG[?.?=$79~$_$b$3$A$i$G!*(B
$B!!!!!!!!!!!!!!(B
$B!!!!!!!!!!!|9-9pFCJL?=$79~<uIUCf!*!*!!8=:_$O!!%5!<%S%94|4V$H$J$C$F$*$j!"9-9pNA6b$rD:BW$7$F$*$j$^$;$s!#(B
$B!!!!!!!!!!!!$?$@$7!"7G:\$O%i%s%@%`$H$J$j$^$9$N$G!"$4N;>5$/$@$5$$!#(B

$B!!!!!!!!!!!!$^$?9-9pFbMF$K$h$C$F$O!!7G:\$r95$($5$;$F$$$?$@$/>l9g$b$4$6$$$^$9!#(B
$B!!!!!!!!!!!!9-9p$r?=$79~$s$G$$$?$@$$$?J}$K$O!"%a!<%k%^%,%8%s$rG[?.$5$;$F$$$?$@$-$^$9!#(B
$B!!!!!!!!!!!!$4N;>5$N>e!!$*?=$79~$_$/$@$5$$!#(B

$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(Bhttp://gogoway.orgdns.org/doc/honmousikomi.htm
                       ----------------------------------------------------------
$B!!!!!!!!!!!!!!!!!!!!!!(B            $B%a!<%k%^%,%8%s!!9-9pC4EvLpBt!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B
$B!!!!!!!!(B
-------------------------------------------
8$B7n(B31$BF|(B5$B;~H/I=(B

$B<gMWET;T(B    $B:#Lk(B                $BL@F|(B
$B;%KZ(B        $B1+(B                  $B@2$l(B                
$B@gBf(B        $B1+$N$A@2$l(B          $B@2$l(B                
$BEl5~(B        $BF^$j$N$A;~!9@2$l(B    $B@2$l(B                
$BD9Ln(B        $B1+$N$A@2$l(B          $B@2$l(B                
$B@E2,(B        $B1+$N$A@2$l(B          $B@2$l(B                
$BL>8E20(B      $BF^$j$N$A;~!9@2$l(B    $B@2$l(B                
$B?73c(B        $BF^$j0l;~1+(B          $B@2$l;~!9F^$j(B        
$B6bBt(B        $B1+$N$A@2$l(B          $B@2$l(B                
$BBg:e(B        $BF^$j$N$A;~!9@2$l(B    $B@2$l(B                
$B2,;3(B        $BF^$j$N$A;~!9@2$l(B    $B@2$l(B                
$B9-Eg(B        $BF^$j$N$A;~!9@2$l(B    $B@2$l(B                
$B9b>>(B        $B@2$l;~!9F^$j(B        $B@2$l(B                
$BJ!2,(B        $BF^$j$N$A;~!9@2$l(B    $B@2$l(B                
$B</;yEg(B      $B@2$l(B                $B@2$l(B                
$BFaGF(B        $B@2$l(B                $B@2$l;~!9F^$j(B        



From ichinoh@mb.neweb.ne.jp Tue Aug 31 15:49:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 Aug 2004 15:49:42 +0100 (BST)
Received: from imfep04.dion.ne.jp ([IPv6:::ffff:210.174.120.150]:49611 "EHLO
	imfep04.dion.ne.jp") by linux-mips.org with ESMTP
	id <S8224948AbUHaOth>; Tue, 31 Aug 2004 15:49:37 +0100
Received: from mb.neweb.ne.jp ([218.222.88.128]) by imfep04.dion.ne.jp
          (InterMail vM.4.01.03.31 201-229-121-131-20020322) with ESMTP
          id <20040831144932.CWRR32431.imfep04.dion.ne.jp@mb.neweb.ne.jp>
          for <linux-mips@linux-mips.org>; Tue, 31 Aug 2004 23:49:32 +0900
Date: Tue, 31 Aug 2004 23:49:31 +0900
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Reset of USB
From: ichinoh@mb.neweb.ne.jp
To: linux-mips@linux-mips.org
Content-Transfer-Encoding: 7bit
Message-Id: <F7800BBC-FB5C-11D8-85DA-000A956B2316@mb.neweb.ne.jp>
X-Mailer: Apple Mail (2.553)
Return-Path: <ichinoh@mb.neweb.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5749
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ichinoh@mb.neweb.ne.jp
Precedence: bulk
X-list: linux-mips

Hello ,

I invoked the Linux kernel on ALCHEMY DBAU1100 by U-BOOT.

The processing which resets USB-OHCI of the head of a kernel is not 
completed. (refer to *)

Au1100 does not indicate "reset is completed."
Is this phenomenon experienced?

In addition,
this phenomenon is not encountered when starting a kernel by YAMON.


*:
arch/mips/au1000/common/setup.c

#ifdef CONFIG_USB_OHCI
	// enable host controller and wait for reset done
	au_writel(0x08, USB_HOST_CONFIG);
	udelay(1000);
	au_writel(0x0E, USB_HOST_CONFIG);
	udelay(1000);
	au_readl(USB_HOST_CONFIG); // throw away first read
	while (!(au_readl(USB_HOST_CONFIG) & 0x10))
		au_readl(USB_HOST_CONFIG);
#endif

Best regards,
Nyauyama


From dhowells@redhat.com Tue Aug 31 16:12:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 Aug 2004 16:12:37 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:62176 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224948AbUHaPMc>;
	Tue, 31 Aug 2004 16:12:32 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7VFCVS0024717;
	Tue, 31 Aug 2004 11:12:31 -0400
Received: from warthog.cambridge.redhat.com (warthog.cambridge.redhat.com [172.16.18.73])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7VFCJ325414;
	Tue, 31 Aug 2004 11:12:19 -0400
Received: from warthog.cambridge.redhat.com (localhost.localdomain [127.0.0.1])
	by warthog.cambridge.redhat.com (8.12.11/8.12.8) with ESMTP id i7VFCIlm013075;
	Tue, 31 Aug 2004 16:12:18 +0100
Received: from redhat.com (dhowells@localhost)
	by warthog.cambridge.redhat.com (8.12.11/8.12.11/Submit) with ESMTP id i7VFCECt013072;
	Tue, 31 Aug 2004 16:12:14 +0100
X-Authentication-Warning: warthog.cambridge.redhat.com: dhowells owned process doing -bs
From: David Howells <dhowells@redhat.com>
In-Reply-To: <20040830232445.0b5aad79.akpm@osdl.org> 
References: <20040830232445.0b5aad79.akpm@osdl.org> 
To: Andrew Morton <akpm@osdl.org>, rth@twiddle.net,
	linux-mips@linux-mips.org, parisc-linux@parisc-linux.org,
	sparclinux@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] New error codes for Alpha, MIPS, PA-RISC, Sparc & Sparc64
User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 31 Aug 2004 16:12:14 +0100
Message-ID: <13071.1093965134@redhat.com>
Return-Path: <dhowells@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: 5750
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dhowells@redhat.com
Precedence: bulk
X-list: linux-mips


The attached patch adds the new error codes I added for key-related errors to
those archs that don't make use of <asm-generic/errno.h>, including Alpha,
MIPS, PA-RISC, Sparc and Sparc64. This is required to compile with CONFIG_KEYS
on those platforms.

Signed-Off-By: David Howells <dhowells@redhat.com>
---

warthog>diffstat keys-errors-2681mm4.diff 
 asm-alpha/errno.h   |    4 ++++
 asm-mips/errno.h    |    4 ++++
 asm-parisc/errno.h  |    4 ++++
 asm-sparc/errno.h   |    4 ++++
 asm-sparc64/errno.h |    4 ++++
 5 files changed, 20 insertions(+)

diff -uNrp linux-2.6.8.1-mm4-keys/include/asm-alpha/errno.h linux-2.6.8.1-mm4-keys-read/include/asm-alpha/errno.h
--- linux-2.6.8.1-mm4-keys/include/asm-alpha/errno.h	2004-06-18 13:42:21.000000000 +0100
+++ linux-2.6.8.1-mm4-keys-read/include/asm-alpha/errno.h	2004-08-31 10:10:11.466082943 +0100
@@ -110,5 +110,9 @@
 
 #define ENOMEDIUM	129	/* No medium found */
 #define EMEDIUMTYPE	130	/* Wrong medium type */
+#define	ENOKEY		131	/* Required key not available */
+#define	EKEYEXPIRED	132	/* Key has expired */
+#define	EKEYREVOKED	133	/* Key has been revoked */
+#define	EKEYREJECTED	134	/* Key was rejected by service */
 
 #endif
diff -uNrp linux-2.6.8.1-mm4-keys/include/asm-mips/errno.h linux-2.6.8.1-mm4-keys-read/include/asm-mips/errno.h
--- linux-2.6.8.1-mm4-keys/include/asm-mips/errno.h	2004-06-18 13:42:12.000000000 +0100
+++ linux-2.6.8.1-mm4-keys-read/include/asm-mips/errno.h	2004-08-31 10:12:16.492662321 +0100
@@ -110,6 +110,10 @@
  */
 #define ENOMEDIUM	159	/* No medium found */
 #define EMEDIUMTYPE	160	/* Wrong medium type */
+#define	ENOKEY		161	/* Required key not available */
+#define	EKEYEXPIRED	162	/* Key has expired */
+#define	EKEYREVOKED	163	/* Key has been revoked */
+#define	EKEYREJECTED	164	/* Key was rejected by service */
 
 #define EDQUOT		1133	/* Quota exceeded */
 
diff -uNrp linux-2.6.8.1-mm4-keys/include/asm-parisc/errno.h linux-2.6.8.1-mm4-keys-read/include/asm-parisc/errno.h
--- linux-2.6.8.1-mm4-keys/include/asm-parisc/errno.h	2004-06-18 13:42:13.000000000 +0100
+++ linux-2.6.8.1-mm4-keys-read/include/asm-parisc/errno.h	2004-08-31 10:11:51.478747181 +0100
@@ -67,6 +67,10 @@
 #define	EREMOTEIO	181	/* Remote I/O error */
 #define	ENOMEDIUM	182	/* No medium found */
 #define	EMEDIUMTYPE	183	/* Wrong medium type */
+#define	ENOKEY		184	/* Required key not available */
+#define	EKEYEXPIRED	185	/* Key has expired */
+#define	EKEYREVOKED	186	/* Key has been revoked */
+#define	EKEYREJECTED	187	/* Key was rejected by service */
 
 /* We now return you to your regularly scheduled HPUX. */
 
diff -uNrp linux-2.6.8.1-mm4-keys/include/asm-sparc/errno.h linux-2.6.8.1-mm4-keys-read/include/asm-sparc/errno.h
--- linux-2.6.8.1-mm4-keys/include/asm-sparc/errno.h	2004-06-18 13:42:21.000000000 +0100
+++ linux-2.6.8.1-mm4-keys-read/include/asm-sparc/errno.h	2004-08-31 10:10:55.134443332 +0100
@@ -101,5 +101,9 @@
 
 #define	ENOMEDIUM	125	/* No medium found */
 #define	EMEDIUMTYPE	126	/* Wrong medium type */
+#define	ENOKEY		127	/* Required key not available */
+#define	EKEYEXPIRED	128	/* Key has expired */
+#define	EKEYREVOKED	129	/* Key has been revoked */
+#define	EKEYREJECTED	130	/* Key was rejected by service */
 
 #endif
diff -uNrp linux-2.6.8.1-mm4-keys/include/asm-sparc64/errno.h linux-2.6.8.1-mm4-keys-read/include/asm-sparc64/errno.h
--- linux-2.6.8.1-mm4-keys/include/asm-sparc64/errno.h	2004-06-18 13:42:22.000000000 +0100
+++ linux-2.6.8.1-mm4-keys-read/include/asm-sparc64/errno.h	2004-08-31 10:09:36.730977977 +0100
@@ -101,5 +101,9 @@
 
 #define ENOMEDIUM       125     /* No medium found */
 #define EMEDIUMTYPE     126     /* Wrong medium type */
+#define	ENOKEY		127	/* Required key not available */
+#define	EKEYEXPIRED	128	/* Key has expired */
+#define	EKEYREVOKED	129	/* Key has been revoked */
+#define	EKEYREJECTED	130	/* Key was rejected by service */
 
 #endif /* !(_SPARC64_ERRNO_H) */

From anemo@mba.ocn.ne.jp Tue Aug 31 17:13:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 Aug 2004 17:14:00 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:41455 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8224948AbUHaQN4>; Tue, 31 Aug 2004 17:13:56 +0100
Received: from localhost (p2038-ipad11funabasi.chiba.ocn.ne.jp [219.162.37.38])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 2B099771D
	for <linux-mips@linux-mips.org>; Wed,  1 Sep 2004 01:13:53 +0900 (JST)
Date: Wed, 01 Sep 2004 01:22:23 +0900 (JST)
Message-Id: <20040901.012223.59462025.anemo@mba.ocn.ne.jp>
To: linux-mips@linux-mips.org
Subject: gcc 3.3.4/3.4.1 and get_user
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5751
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

I found that gcc 3.3.4/3.4.1 can not compile this sample code properly.

--- k.c ---
/* mips-linux-gcc -D__KERNEL__ -O2 -mno-abicalls -fno-pic -I $(KERNEL)/include -S k.c */
#include <asm/uaccess.h>

extern char ptr[];

static int func0(int arg0)
{
	return 0;
}

int func1(int *arg)
{
	int arg0 = arg[0];
	int arg1;

	if (arg0)
		return -1;
	arg0 = func0(0);
	get_user(arg1 , (int*)arg[1]);
	if (func0(ptr[arg0]))
		return 0;
	if (arg1)
		ptr[arg0] = 0;
	return 0;
}
--- k.c end ---

The codes around the first calling of func0 are:

	.set	noreorder
	.set	nomacro
	jal	func0
	.set	macro
	.set	reorder

	lw	$4,4($16)

The jal does not have delay slot.  Then "lw $4" (part of get_user)
executed as the delay slot instruction.

I create a sample code with very stripped version of get_user.

--- kk.c ---
/* mips-linux-gcc -O2 -mno-abicalls -fno-pic -S kk.c */

#define get_user(x,ptr)			\
{					\
	int __gu_val;			\
	__asm__ ("":"=r" (__gu_val));	\
	if (ptr) {			\
		__asm__ __volatile__(	\
		"\tlw\t%0,%1\n\t"	\
		:"=r" (__gu_val)	\
		:"o" (*(ptr)));		\
	}				\
	(x) = __gu_val;			\
}

extern char ptr[];

static int func0(int arg0)
{
	return 0;
}

int func1(int *arg)
{
	int arg0 = arg[0];
	int arg1;

	if (arg0)
		return -1;
	arg0 = func0(0);
	get_user(arg1 , (int*)arg[1]);
	if (func0(ptr[arg0]))
		return 0;
	if (arg1)
		ptr[arg0] = 0;
	return 0;
}
--- kk.c end ---

And complete output of gcc 3.3.4:

	.file	1 "kk.c"
	.section .mdebug.abi32
	.previous
	.text
	.align	2
	.ent	func0
	.type	func0, @function
func0:
	.frame	$sp,0,$31		# vars= 0, regs= 0/0, args= 0, extra= 0
	.mask	0x00000000,0
	.fmask	0x00000000,0
	.set	noreorder
	.set	nomacro
	j	$31
	move	$2,$0
	.set	macro
	.set	reorder

	.end	func0
	.align	2
	.globl	func1
	.ent	func1
	.type	func1, @function
func1:
	.frame	$sp,32,$31		# vars= 0, regs= 3/0, args= 16, extra= 0
	.mask	0x80030000,-8
	.fmask	0x00000000,0
	subu	$sp,$sp,32
	sw	$16,16($sp)
	sw	$31,24($sp)
	move	$16,$4
	sw	$17,20($sp)
	lw	$2,0($16)
	move	$4,$0
	.set	noreorder
	.set	nomacro
	bne	$2,$0,$L2
	li	$3,-1			# 0xffffffffffffffff
	.set	macro
	.set	reorder

	.set	noreorder
	.set	nomacro
	jal	func0
	.set	macro
	.set	reorder

	lw	$4,4($16)
	#nop
	beq	$4,$0,$L4
#APP
		lw	$17,0($4)
	
#NO_APP
$L4:
	la $16,ptr($2)
	lb	$4,0($16)
	jal	func0
	.set	noreorder
	.set	nomacro
	bne	$2,$0,$L2
	move	$3,$0
	.set	macro
	.set	reorder

	beq	$17,$0,$L2
	sb	$0,0($16)
$L2:
	lw	$31,24($sp)
	lw	$17,20($sp)
	lw	$16,16($sp)
	move	$2,$3
	.set	noreorder
	.set	nomacro
	j	$31
	addu	$sp,$sp,32
	.set	macro
	.set	reorder

	.end	func1
	.ident	"GCC: (GNU) 3.3.4"


Also complete output of gcc 3.4.1:

	.file	1 "kk.c"
	.section .mdebug.abi32
	.previous
	.text
	.align	2
	.ent	func0
	.type	func0, @function
func0:
	.frame	$sp,0,$31		# vars= 0, regs= 0/0, args= 0, gp= 0
	.mask	0x00000000,0
	.fmask	0x00000000,0
	.set	noreorder
	.set	nomacro
	
	j	$31
	move	$2,$0

	.set	macro
	.set	reorder
	.end	func0
	.align	2
	.globl	func1
	.ent	func1
	.type	func1, @function
func1:
	.frame	$sp,32,$31		# vars= 0, regs= 3/0, args= 16, gp= 0
	.mask	0x80030000,-8
	.fmask	0x00000000,0
	addiu	$sp,$sp,-32
	sw	$16,16($sp)
	sw	$31,24($sp)
	move	$16,$4
	sw	$17,20($sp)
	lw	$3,0($16)
	move	$4,$0
	.set	noreorder
	.set	nomacro
	bne	$3,$0,$L2
	li	$5,-1			# 0xffffffffffffffff
	.set	macro
	.set	reorder

	.set	noreorder
	.set	nomacro
	jal	func0
	.set	macro
	.set	reorder

	lw	$4,4($16)
	#nop
	.set	noreorder
	.set	nomacro
	bne	$4,$0,$L8
	move	$3,$2
	.set	macro
	.set	reorder

	lui	$2,%hi(ptr)
$L9:
	addiu	$2,$2,%lo(ptr)
	addu	$16,$3,$2
	lb	$4,0($16)
	jal	func0
	.set	noreorder
	.set	nomacro
	bne	$2,$0,$L2
	move	$5,$0
	.set	macro
	.set	reorder

	beq	$17,$0,$L2
	sb	$0,0($16)
$L2:
	lw	$31,24($sp)
	lw	$17,20($sp)
	lw	$16,16($sp)
	move	$2,$5
	.set	noreorder
	.set	nomacro
	j	$31
	addiu	$sp,$sp,32
	.set	macro
	.set	reorder

$L8:
#APP
		lw	$17,0($4)
	
#NO_APP
	.set	noreorder
	.set	nomacro
	j	$L9
	lui	$2,%hi(ptr)
	.set	macro
	.set	reorder

	.end	func1
	.ident	"GCC: (GNU) 3.4.1"


Is this a get_user's problem or gcc's?

---
Atsushi Nemoto

From alan@lxorguk.ukuu.org.uk Tue Aug 31 19:02:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 Aug 2004 19:02:32 +0100 (BST)
Received: from the-village.bc.nu ([IPv6:::ffff:81.2.110.252]:62856 "EHLO
	localhost.localdomain") by linux-mips.org with ESMTP
	id <S8224948AbUHaSCU>; Tue, 31 Aug 2004 19:02:20 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i7VH0KAa000769;
	Tue, 31 Aug 2004 18:00:20 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id i7VH0IXj000768;
	Tue, 31 Aug 2004 18:00:18 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: [parisc-linux] [PATCH] New error codes for Alpha, MIPS,
	PA-RISC, Sparc & Sparc64
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: David Howells <dhowells@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>, rth@twiddle.net,
	linux-mips@linux-mips.org,
	HPPA List <parisc-linux@parisc-linux.org>,
	sparclinux@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <13071.1093965134@redhat.com>
References: <20040830232445.0b5aad79.akpm@osdl.org>
	 <13071.1093965134@redhat.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1093971614.599.20.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Tue, 31 Aug 2004 18:00:15 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5752
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Maw, 2004-08-31 at 16:12, David Howells wrote:
> The attached patch adds the new error codes I added for key-related errors to
> those archs that don't make use of <asm-generic/errno.h>, including Alpha,
> MIPS, PA-RISC, Sparc and Sparc64. This is required to compile with CONFIG_KEYS
> on those platforms.

The patch seems to be mixing the fixups for remapping these error codes
into sparc, hpux, osf/1 and other compatibility layers on the platforms


From rsandifo@redhat.com Tue Aug 31 20:51:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 Aug 2004 20:51:41 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:19627 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224948AbUHaTvd>;
	Tue, 31 Aug 2004 20:51:33 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7VJpQS0015667;
	Tue, 31 Aug 2004 15:51:31 -0400
Received: from localhost (mail@vpnuser7.surrey.redhat.com [172.16.9.7])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7VJpL329465;
	Tue, 31 Aug 2004 15:51:22 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1C2Ef2-0001Dk-00; Tue, 31 Aug 2004 20:51:20 +0100
To: Richard Henderson <rth@redhat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Nigel Stephens <nigel@mips.com>, gcc-patches@gcc.gnu.org,
	linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit
 targets
References: <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl>
	<410E9E25.7080104@mips.com> <87acxcbxfl.fsf@redhat.com>
	<410F5964.3010109@mips.com> <876580bm2e.fsf@redhat.com>
	<410F60DF.9020400@mips.com>
	<Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl>
	<87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com>
	<87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Tue, 31 Aug 2004 20:51:20 +0100
In-Reply-To: <20040810232020.GA21922@redhat.com> (Richard Henderson's
 message of "Tue, 10 Aug 2004 16:20:20 -0700")
Message-ID: <87eklnw0g7.fsf@redhat.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@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: 5753
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

Richard Henderson <rth@redhat.com> writes:
> Patch seems ok then.  We'd have to add a new macro/target flag
> to handle non-truncating shifts -- we've got cases:
>
>   (1) Large shift shifts out all bits (ARM)
>   (2) Large shifts trap (VAX)
>   (3) Shift count truncated to 31, always, which means QI/HI
>       shifts are yield undefined results with large shifts.  (i386)

I'm not sure whether (2) really affects things much.  By default, the code
is supposed to do exactly what libgcc2.c would do, i.e.:

  - the double-word shift guarantees no particular behaviour for
    shifts counts outside the range [0, BITS_PER_WORD * 2)

  - for counts inside that range, the code will only use well-defined
    word-mode shifts.

In the patch I posted originally, SHIFT_COUNT_TRUNCATED changed the
default behaviour in two ways:

  a) it guaranteed that the doubleword shift would truncate the shift count.

  b) it enabled some extra optimisations, particularly in the conditional
     move case.

As you say, using S_C_T was a bit limited, especially since it requires a
particular behaviour for unrelated things like ZERO_EXTRACT.  So, to deal
with (1) and (3) from your list, the patch below adds a new target hook:

int TARGET_SHIFT_TRUNCATION_MASK (enum machine_mode MODE)

     This function describes how the standard shift patterns for MODE
     deal with shifts by negative amounts or by more than the width of
     the mode.  *Note shift patterns::.

     On many machines, the shift patterns will apply a mask M to the
     shift count, meaning that a fixed-width shift of X by Y is
     equivalent to an arbitrary-width shift of X by Y & M.  If this is
     true for mode MODE, the function should return M, otherwise it
     should return 0.  A return value of 0 indicates that no particular
     behavior is guaranteed.

     Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does
     _not_ apply to general shift rtxes; it applies only to instructions
     that are generated by the named shift patterns.

     The default implementation of this function returns
     `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0
     otherwise.  This definition is always safe, but if
     `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns
     nevertheless truncate the shift count, you may get better code by
     overriding it.

Thus the optimisations from (b) that used to be conditional on S_C_T
are now conditional on:

    TARGET_SHIFT_TRUNCATION_MASK (word_mode) == BITS_PER_WORD - 1

The truncation behaviour from (a) is guaranteed if:

    TARGET_SHIFT_TRUNCATION_MASK (double_word_mode) == BITS_PER_WORD * 2 - 1

although the optimisation only handles the latter if the former is also true.
In other cases, it punts unless T_S_T_M returns 0 for double_word_mode.

The point of the new hook is that allows us to optimise case (1) from
your list.  If:

    TARGET_SHIFT_TRUNCATION_MASK (word_mode) >= BITS_PER_WORD * 2 - 1

then (because out-of-range shift counts are undefined for the doubleword
shifts) we can use:

    outof_target = (shift outof_input op1)

as per config/arm/lib1funcs.asm.

One potential drawback of all this is that it generates rtxes that
rely on the behaviour of shifts by more than the word width.  At the
moment, simplify-rtx.c will fold such shifts using whatever the host
compiler thinks is suitable.  E.g.:

    case ASHIFT:
      if (arg1 < 0)
	return 0;

      if (SHIFT_COUNT_TRUNCATED)
	arg1 %= width;

      val = ((unsigned HOST_WIDE_INT) arg0) << arg1;
      break;

which accepts any positive arg1, even if !SHIFT_COUNT_TRUNCATED.

This seems pretty dubious anyway.  What if a define_expand in the backend
uses shifts to implement a complex named pattern?  I'd have thought the
backend would be free to use target-specific knowledge about what that
shift does with out-of-range values.  And if we are later able to
constant-fold the result, the code above might not do what the
target machine would do.

The patch therefore refuses to optimise out-of-range counts unless
SHIFT_COUNT_TRUNCATED.  It also fixes the following sign-extension code:

      /* Bootstrap compiler may not have sign extended the right shift.
	 Manually extend the sign to insure bootstrap cc matches gcc.  */
      if (arg0s < 0 && arg1 > 0)
	val |= ((HOST_WIDE_INT) -1) << (HOST_BITS_PER_WIDE_INT - arg1);

which isn't right for modes whose width is != HOST_BITS_PER_WIDE_INT.

As an example:

    unsigned long long f (unsigned long long x, int y) { return x << y; }

is now implemented thus for arm-elf-gcc -O2 -fno-schedule-insns:

	mov	r1, r1, asl r2
	rsb	r3, r2, #32
	orr	r1, r1, r0, lsr r3
	subs	ip, r2, #32
	movpl	r1, r0, asl ip
	mov	r0, r0, asl r2
	bx	lr

(without -fno-schedule-insns, the scheduler will increase register
pressure and force some call-saved registers live.)  This sequence
is at least the same length as the hand-coded lib1funcs.asm version,
so I hope it's better than the call we get now.

For mips64-elf-gcc -O2 -march=rm9000 -mabi=32, we get:

	nor	$7,$0,$6
	srl	$8,$5,1
	sll	$2,$4,$6
	srl	$8,$8,$7
	sll	$3,$5,$6
	or	$2,$8,$2
	andi	$6,$6,0x20
	movn	$2,$3,$6
	j	$31
	movn	$3,$0,$6

which is nicely superscalar, and the same length as Maciej's
hand-coded version.

As before, the patch will fall back on jumps if conditional moves
aren't available.

Bootstrapped & regression tested on i686-pc-linux-gnu and mips-sgi-irix6.5.
Also tested on arm-elf (default language set, test pattern arm-elf{,-mthumb}).
OK to install?

Richard


	* doc/md.texi (shift patterns): New anchor.  Add reference to
	TARGET_SHIFT_TRUNCATION_MASK.
	* doc/tm.texi (TARGET_SHIFT_TRUNCATION_MASK): Document.
	* target.h (shift_truncation_mask): New target hook.
	* targhook.h (default_shift_truncation_mask): Declare.
	* targhook.c (default_shift_truncation_mask): Define.
	* target-def.h (TARGET_SHIFT_TRUNCATION_MASK): Define.
	(TARGET_INITIALIZER): Include it.
	* simplify-rtx.c (simplify_binary_operation): Combine ASHIFT, ASHIFTRT
	and LSHIFTRT cases.  Truncate arg1 if SHIFT_COUNT_TRUNCATED, otherwise
	reject all out-of-range values.  Fix sign-extension code for modes
	whose width is smaller than HOST_BITS_PER_WIDE_INT.
	* optabs.c (simplify_expand_binop, force_expand_binop): New functions.
	(expand_superword_shift, expand_subword_shift): Likewise.
	(expand_doubleword_shift_condmove, expand_doubleword_shift): Likewise.
	(expand_binop): Use them to implement double-word shifts.
	* config/arm/arm.c (arm_shift_truncation_mask): New function.
	(TARGET_SHIFT_TRUNCATION_MASK): Define.

Index: doc/md.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/md.texi,v
retrieving revision 1.108
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.108 md.texi
*** doc/md.texi	23 Aug 2004 05:55:46 -0000	1.108
--- doc/md.texi	31 Aug 2004 18:44:55 -0000
*************** quotient or remainder and generate the a
*** 2884,2896 ****
  @item @samp{udivmod@var{m}4}
  Similar, but does unsigned division.
  
  @cindex @code{ashl@var{m}3} instruction pattern
  @item @samp{ashl@var{m}3}
  Arithmetic-shift operand 1 left by a number of bits specified by operand
  2, and store the result in operand 0.  Here @var{m} is the mode of
  operand 0 and operand 1; operand 2's mode is specified by the
  instruction pattern, and the compiler will convert the operand to that
! mode before generating the instruction.
  
  @cindex @code{ashr@var{m}3} instruction pattern
  @cindex @code{lshr@var{m}3} instruction pattern
--- 2884,2899 ----
  @item @samp{udivmod@var{m}4}
  Similar, but does unsigned division.
  
+ @anchor{shift patterns}
  @cindex @code{ashl@var{m}3} instruction pattern
  @item @samp{ashl@var{m}3}
  Arithmetic-shift operand 1 left by a number of bits specified by operand
  2, and store the result in operand 0.  Here @var{m} is the mode of
  operand 0 and operand 1; operand 2's mode is specified by the
  instruction pattern, and the compiler will convert the operand to that
! mode before generating the instruction.  The meaning of out-of-range shift
! counts can optionally be specified by @code{TARGET_SHIFT_TRUNCATION_MASK}.
! @xref{TARGET_SHIFT_TRUNCATION_MASK}.
  
  @cindex @code{ashr@var{m}3} instruction pattern
  @cindex @code{lshr@var{m}3} instruction pattern
Index: doc/tm.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/tm.texi,v
retrieving revision 1.360
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.360 tm.texi
*** doc/tm.texi	29 Aug 2004 22:10:44 -0000	1.360
--- doc/tm.texi	31 Aug 2004 18:45:09 -0000
*************** the implied truncation of the shift inst
*** 8731,8736 ****
--- 8731,8761 ----
  You need not define this macro if it would always have the value of zero.
  @end defmac
  
+ @anchor{TARGET_SHIFT_TRUNCATION_MASK}
+ @deftypefn {Target Hook} int TARGET_SHIFT_TRUNCATION_MASK (enum machine_mode @var{mode})
+ This function describes how the standard shift patterns for @var{mode}
+ deal with shifts by negative amounts or by more than the width of the mode.
+ @xref{shift patterns}.
+ 
+ On many machines, the shift patterns will apply a mask @var{m} to the
+ shift count, meaning that a fixed-width shift of @var{x} by @var{y} is
+ equivalent to an arbitrary-width shift of @var{x} by @var{y & m}.  If
+ this is true for mode @var{mode}, the function should return @var{m},
+ otherwise it should return 0.  A return value of 0 indicates that no
+ particular behavior is guaranteed.
+ 
+ Note that, unlike @code{SHIFT_COUNT_TRUNCATED}, this function does
+ @emph{not} apply to general shift rtxes; it applies only to instructions
+ that are generated by the named shift patterns.
+ 
+ The default implementation of this function returns
+ @code{GET_MODE_BITSIZE (@var{mode}) - 1} if @code{SHIFT_COUNT_TRUNCATED}
+ and 0 otherwise.  This definition is always safe, but if
+ @code{SHIFT_COUNT_TRUNCATED} is false, and some shift patterns
+ nevertheless truncate the shift count, you may get better code
+ by overriding it.
+ @end deftypefn
+ 
  @defmac TRULY_NOOP_TRUNCATION (@var{outprec}, @var{inprec})
  A C expression which is nonzero if on this machine it is safe to
  ``convert'' an integer of @var{inprec} bits to one of @var{outprec}
Index: target.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/target.h,v
retrieving revision 1.109
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.109 target.h
*** target.h	26 Aug 2004 00:24:34 -0000	1.109
--- target.h	31 Aug 2004 18:45:10 -0000
*************** struct gcc_target
*** 378,383 ****
--- 378,387 ----
    /* Undo the effects of encode_section_info on the symbol string.  */
    const char * (* strip_name_encoding) (const char *);
  
+   /* If shift optabs for MODE are known to always truncate the shift count,
+      return the mask that they apply.  Return 0 otherwise.  */
+   unsigned HOST_WIDE_INT (* shift_truncation_mask) (enum machine_mode mode);
+ 
    /* True if MODE is valid for a pointer in __attribute__((mode("MODE"))).  */
    bool (* valid_pointer_mode) (enum machine_mode mode);
  
Index: targhooks.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/targhooks.h,v
retrieving revision 2.18
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r2.18 targhooks.h
*** targhooks.h	26 Aug 2004 00:24:34 -0000	2.18
--- targhooks.h	31 Aug 2004 18:45:10 -0000
*************** extern bool hook_bool_CUMULATIVE_ARGS_fa
*** 32,37 ****
--- 32,39 ----
  extern bool default_pretend_outgoing_varargs_named (CUMULATIVE_ARGS *);
  
  extern enum machine_mode default_eh_return_filter_mode (void);
+ extern unsigned HOST_WIDE_INT default_shift_truncation_mask
+   (enum machine_mode);
  
  extern bool hook_bool_CUMULATIVE_ARGS_true (CUMULATIVE_ARGS *);
  extern tree default_cxx_guard_type (void);
Index: targhooks.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/targhooks.c,v
retrieving revision 2.27
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r2.27 targhooks.c
*** targhooks.c	26 Aug 2004 00:24:34 -0000	2.27
--- targhooks.c	31 Aug 2004 18:45:10 -0000
*************** default_eh_return_filter_mode (void)
*** 135,140 ****
--- 135,148 ----
    return word_mode;
  }
  
+ /* The default implementation of TARGET_SHIFT_TRUNCATION_MASK.  */
+ 
+ unsigned HOST_WIDE_INT
+ default_shift_truncation_mask (enum machine_mode mode)
+ {
+   return SHIFT_COUNT_TRUNCATED ? GET_MODE_BITSIZE (mode) - 1 : 0;
+ }
+ 
  /* Generic hook that takes a CUMULATIVE_ARGS pointer and returns true.  */
  
  bool
Index: target-def.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/target-def.h,v
retrieving revision 1.98
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.98 target-def.h
*** target-def.h	26 Aug 2004 00:24:33 -0000	1.98
--- target-def.h	31 Aug 2004 18:45:11 -0000
*************** #define TARGET_STRIP_NAME_ENCODING defau
*** 301,306 ****
--- 301,310 ----
  #define TARGET_BINDS_LOCAL_P default_binds_local_p
  #endif
  
+ #ifndef TARGET_SHIFT_TRUNCATION_MASK
+ #define TARGET_SHIFT_TRUNCATION_MASK default_shift_truncation_mask
+ #endif
+ 
  #ifndef TARGET_VALID_POINTER_MODE
  #define TARGET_VALID_POINTER_MODE default_valid_pointer_mode
  #endif
*************** #define TARGET_INITIALIZER			\
*** 478,483 ****
--- 482,488 ----
    TARGET_BINDS_LOCAL_P,				\
    TARGET_ENCODE_SECTION_INFO,			\
    TARGET_STRIP_NAME_ENCODING,			\
+   TARGET_SHIFT_TRUNCATION_MASK,			\
    TARGET_VALID_POINTER_MODE,                    \
    TARGET_SCALAR_MODE_SUPPORTED_P,		\
    TARGET_VECTOR_MODE_SUPPORTED_P,               \
Index: simplify-rtx.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.202
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.202 simplify-rtx.c
*** simplify-rtx.c	27 Jul 2004 19:09:32 -0000	1.202
--- simplify-rtx.c	31 Aug 2004 18:45:15 -0000
*************** simplify_binary_operation (enum rtx_code
*** 2343,2383 ****
        break;
  
      case LSHIFTRT:
-       /* If shift count is undefined, don't fold it; let the machine do
- 	 what it wants.  But truncate it if the machine will do that.  */
-       if (arg1 < 0)
- 	return 0;
- 
-       if (SHIFT_COUNT_TRUNCATED)
- 	arg1 %= width;
- 
-       val = ((unsigned HOST_WIDE_INT) arg0) >> arg1;
-       break;
- 
      case ASHIFT:
-       if (arg1 < 0)
- 	return 0;
- 
-       if (SHIFT_COUNT_TRUNCATED)
- 	arg1 %= width;
- 
-       val = ((unsigned HOST_WIDE_INT) arg0) << arg1;
-       break;
- 
      case ASHIFTRT:
!       if (arg1 < 0)
! 	return 0;
! 
        if (SHIFT_COUNT_TRUNCATED)
! 	arg1 %= width;
! 
!       val = arg0s >> arg1;
! 
!       /* Bootstrap compiler may not have sign extended the right shift.
! 	 Manually extend the sign to insure bootstrap cc matches gcc.  */
!       if (arg0s < 0 && arg1 > 0)
! 	val |= ((HOST_WIDE_INT) -1) << (HOST_BITS_PER_WIDE_INT - arg1);
  
        break;
  
      case ROTATERT:
--- 2343,2368 ----
        break;
  
      case LSHIFTRT:
      case ASHIFT:
      case ASHIFTRT:
!       /* Truncate the shift if SHIFT_COUNT_TRUNCATED, otherwise make sure the
! 	 value is in range.  We can't return any old value for out-of-range
! 	 arguments because either the middle-end (via shift_truncation_mask)
! 	 or the back-end might be relying on target-specific knowledge.
! 	 Nor can we rely on shift_truncation_mask, since the shift might
! 	 not be part of an ashlM3, lshrM3 or ashrM3 instruction.  */
        if (SHIFT_COUNT_TRUNCATED)
! 	arg1 = (unsigned HOST_WIDE_INT) arg1 % width;
!       else if (arg1 < 0 || arg1 >= GET_MODE_BITSIZE (mode))
! 	return 0;
  
+       val = (code == ASHIFT
+ 	     ? ((unsigned HOST_WIDE_INT) arg0) << arg1
+ 	     : ((unsigned HOST_WIDE_INT) arg0) >> arg1);
+ 
+       /* Sign-extend the result for arithmetic right shifts.  */
+       if (code == ASHIFTRT && arg0s < 0 && arg1 > 0)
+ 	val |= ((HOST_WIDE_INT) -1) << (width - arg1);
        break;
  
      case ROTATERT:
Index: optabs.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/optabs.c,v
retrieving revision 1.235
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.235 optabs.c
*** optabs.c	19 Aug 2004 22:24:54 -0000	1.235
--- optabs.c	31 Aug 2004 18:45:20 -0000
*************** optab_for_tree_code (enum tree_code code
*** 709,715 ****
--- 709,1064 ----
        return NULL;
      }
  }
+ 
+ /* Like expand_binop, but return a constant rtx if the result can be
+    calculated at compile time.  The arguments and return value are
+    otherwise the same as for expand_binop.  */
+ 
+ static rtx
+ simplify_expand_binop (enum machine_mode mode, optab binoptab,
+ 		       rtx op0, rtx op1, rtx target, int unsignedp,
+ 		       enum optab_methods methods)
+ {
+   if (CONSTANT_P (op0) && CONSTANT_P (op1))
+     return simplify_gen_binary (binoptab->code, mode, op0, op1);
+   else
+     return expand_binop (mode, binoptab, op0, op1, target, unsignedp, methods);
+ }
+ 
+ /* Like simplify_expand_binop, but always put the result in TARGET.
+    Return true if the expansion succeeded.  */
+ 
+ static bool
+ force_expand_binop (enum machine_mode mode, optab binoptab,
+ 		    rtx op0, rtx op1, rtx target, int unsignedp,
+ 		    enum optab_methods methods)
+ {
+   rtx x = simplify_expand_binop (mode, binoptab, op0, op1,
+ 				 target, unsignedp, methods);
+   if (x == 0)
+     return false;
+   if (x != target)
+     emit_move_insn (target, x);
+   return true;
+ }
+ 
+ /* This subroutine of expand_doubleword_shift handles the cases in which
+    the effective shift value is >= BITS_PER_WORD.  The arguments and return
+    value are the same as for the parent routine, except that SUPERWORD_OP1
+    is the shift count to use when shifting OUTOF_INPUT into INTO_TARGET.
+    INTO_TARGET may be null if the caller has decided to calculate it.  */
+ 
+ static bool
+ expand_superword_shift (optab binoptab, rtx outof_input, rtx superword_op1,
+ 			rtx outof_target, rtx into_target,
+ 			int unsignedp, enum optab_methods methods)
+ {
+   if (into_target != 0)
+     if (!force_expand_binop (word_mode, binoptab, outof_input, superword_op1,
+ 			     into_target, unsignedp, methods))
+       return false;
+ 
+   if (outof_target != 0)
+     {
+       /* For a signed right shift, we must fill OUTOF_TARGET with copies
+ 	 of the sign bit, otherwise we must fill it with zeros.  */
+       if (binoptab != ashr_optab)
+ 	emit_move_insn (outof_target, CONST0_RTX (word_mode));
+       else
+ 	if (!force_expand_binop (word_mode, binoptab,
+ 				 outof_input, GEN_INT (BITS_PER_WORD - 1),
+ 				 outof_target, unsignedp, methods))
+ 	  return false;
+     }
+   return true;
+ }
+ 
+ /* This subroutine of expand_doubleword_shift handles the cases in which
+    the effective shift value is < BITS_PER_WORD.  The arguments and return
+    value are the same as for the parent routine.  */
+ 
+ static bool
+ expand_subword_shift (enum machine_mode op1_mode, optab binoptab,
+ 		      rtx outof_input, rtx into_input, rtx op1,
+ 		      rtx outof_target, rtx into_target,
+ 		      int unsignedp, enum optab_methods methods,
+ 		      unsigned HOST_WIDE_INT shift_mask)
+ {
+   optab reverse_unsigned_shift, unsigned_shift;
+   rtx tmp, carries;
+ 
+   reverse_unsigned_shift = (binoptab == ashl_optab ? lshr_optab : ashl_optab);
+   unsigned_shift = (binoptab == ashl_optab ? ashl_optab : lshr_optab);
+ 
+   /* The low OP1 bits of INTO_TARGET come from the high bits of OUTOF_INPUT.
+      We therefore need to shift OUTOF_INPUT by (BITS_PER_WORD - OP1) bits in
+      the opposite direction to BINOPTAB.  */
+   if (CONSTANT_P (op1) || shift_mask >= BITS_PER_WORD)
+     {
+       carries = outof_input;
+       tmp = immed_double_const (BITS_PER_WORD, 0, op1_mode);
+       tmp = simplify_expand_binop (op1_mode, sub_optab, tmp, op1,
+ 				   0, true, methods);
+     }
+   else
+     {
+       /* We must avoid shifting by BITS_PER_WORD bits since that is either
+ 	 the same as a zero shift (if shift_mask == BITS_PER_WORD - 1) or
+ 	 has unknown behaviour.  Do a single shift first, then shift by the
+ 	 remainder.  It's OK to use ~OP1 as the remainder if shift counts
+ 	 are truncated to the mode size.  */
+       carries = expand_binop (word_mode, reverse_unsigned_shift,
+ 			      outof_input, const1_rtx, 0, unsignedp, methods);
+       if (shift_mask == BITS_PER_WORD - 1)
+ 	{
+ 	  tmp = immed_double_const (-1, -1, op1_mode);
+ 	  tmp = simplify_expand_binop (op1_mode, xor_optab, op1, tmp,
+ 				       0, true, methods);
+ 	}
+       else
+ 	{
+ 	  tmp = immed_double_const (BITS_PER_WORD - 1, 0, op1_mode);
+ 	  tmp = simplify_expand_binop (op1_mode, sub_optab, tmp, op1,
+ 				       0, true, methods);
+ 	}
+     }
+   if (tmp == 0 || carries == 0)
+     return false;
+   carries = expand_binop (word_mode, reverse_unsigned_shift,
+ 			  carries, tmp, 0, unsignedp, methods);
+   if (carries == 0)
+     return false;
+ 
+   /* Shift INTO_INPUT logically by OP1.  This is the last use of INTO_INPUT
+      so the result can go directly into INTO_TARGET if convenient.  */
+   tmp = expand_binop (word_mode, unsigned_shift, into_input, op1,
+ 		      into_target, unsignedp, methods);
+   if (tmp == 0)
+     return false;
+ 
+   /* Now OR in the bits carried over from OUTOF_INPUT.  */
+   if (!force_expand_binop (word_mode, ior_optab, tmp, carries,
+ 			   into_target, unsignedp, methods))
+     return false;
+ 
+   /* Use a standard word_mode shift for the out-of half.  */
+   if (outof_target != 0)
+     if (!force_expand_binop (word_mode, binoptab, outof_input, op1,
+ 			     outof_target, unsignedp, methods))
+       return false;
+ 
+   return true;
+ }
  
+ 
+ #ifdef HAVE_conditional_move
+ /* Try implementing expand_doubleword_shift using conditional moves.
+    The shift is by < BITS_PER_WORD if (CMP_CODE CMP1 CMP2) is true,
+    otherwise it is by >= BITS_PER_WORD.  SUBWORD_OP1 and SUPERWORD_OP1
+    are the shift counts to use in the former and latter case.  All other
+    arguments are the same as the parent routine.  */
+ 
+ static bool
+ expand_doubleword_shift_condmove (enum machine_mode op1_mode, optab binoptab,
+ 				  enum rtx_code cmp_code, rtx cmp1, rtx cmp2,
+ 				  rtx outof_input, rtx into_input,
+ 				  rtx subword_op1, rtx superword_op1,
+ 				  rtx outof_target, rtx into_target,
+ 				  int unsignedp, enum optab_methods methods,
+ 				  unsigned HOST_WIDE_INT shift_mask)
+ {
+   rtx outof_superword, into_superword;
+ 
+   /* Put the superword version of the output into OUTOF_SUPERWORD and
+      INTO_SUPERWORD.  */
+   outof_superword = outof_target != 0 ? gen_reg_rtx (word_mode) : 0;
+   if (outof_target != 0 && subword_op1 == superword_op1)
+     {
+       /* The value INTO_TARGET >> SUBWORD_OP1, which we later store in
+ 	 OUTOF_TARGET, is the same as the value of INTO_SUPERWORD.  */
+       into_superword = outof_target;
+       if (!expand_superword_shift (binoptab, outof_input, superword_op1,
+ 				   outof_superword, 0, unsignedp, methods))
+ 	return false;
+     }
+   else
+     {
+       into_superword = gen_reg_rtx (word_mode);
+       if (!expand_superword_shift (binoptab, outof_input, superword_op1,
+ 				   outof_superword, into_superword,
+ 				   unsignedp, methods))
+ 	return false;
+     }
+ 
+   /* Put the subword version directly in OUTOF_TARGET and INTO_TARGET.  */
+   if (!expand_subword_shift (op1_mode, binoptab,
+ 			     outof_input, into_input, subword_op1,
+ 			     outof_target, into_target,
+ 			     unsignedp, methods, shift_mask))
+     return false;
+ 
+   /* Select between them.  Do the INTO half first because INTO_SUPERWORD
+      might be the current value of OUTOF_TARGET.  */
+   if (!emit_conditional_move (into_target, cmp_code, cmp1, cmp2, op1_mode,
+ 			      into_target, into_superword, word_mode, false))
+     return false;
+ 
+   if (outof_target != 0)
+     if (!emit_conditional_move (outof_target, cmp_code, cmp1, cmp2, op1_mode,
+ 				outof_target, outof_superword,
+ 				word_mode, false))
+       return false;
+ 
+   return true;
+ }
+ #endif
+ 
+ /* Expand a doubleword shift (ashl, ashr or lshr) using word-mode shifts.
+    OUTOF_INPUT and INTO_INPUT are the two word-sized halves of the first
+    input operand; the shift moves bits in the direction OUTOF_INPUT->
+    INTO_TARGET.  OUTOF_TARGET and INTO_TARGET are the equivalent words
+    of the target.  OP1 is the shift count and OP1_MODE is its mode.
+    If OP1 is constant, it will have been truncated as appropriate
+    and is known to be nonzero.
+ 
+    If SHIFT_MASK is zero, the result of word shifts is undefined when the
+    shift count is outside the range [0, BITS_PER_WORD).  This routine must
+    avoid generating such shifts for OP1s in the range [0, BITS_PER_WORD * 2).
+ 
+    If SHIFT_MASK is nonzero, all word-mode shift counts are effectively
+    masked by it and shifts in the range [BITS_PER_WORD, SHIFT_MASK) will
+    fill with zeros or sign bits as appropriate.
+ 
+    If SHIFT_MASK is BITS_PER_WORD - 1, this routine will synthesise
+    a doubleword shift whose equivalent mask is BITS_PER_WORD * 2 - 1.
+    Doing this preserves semantics required by SHIFT_COUNT_TRUNCATED.
+    In all other cases, shifts by values outside [0, BITS_PER_UNIT * 2)
+    are undefined.
+ 
+    BINOPTAB, UNSIGNEDP and METHODS are as for expand_binop.  This function
+    may not use INTO_INPUT after modifying INTO_TARGET, and similarly for
+    OUTOF_INPUT and OUTOF_TARGET.  OUTOF_TARGET can be null if the parent
+    function wants to calculate it itself.
+ 
+    Return true if the shift could be successfully synthesized.  */
+ 
+ static bool
+ expand_doubleword_shift (enum machine_mode op1_mode, optab binoptab,
+ 			 rtx outof_input, rtx into_input, rtx op1,
+ 			 rtx outof_target, rtx into_target,
+ 			 int unsignedp, enum optab_methods methods,
+ 			 unsigned HOST_WIDE_INT shift_mask)
+ {
+   rtx superword_op1, tmp, cmp1, cmp2;
+   rtx subword_label, done_label;
+   enum rtx_code cmp_code;
+ 
+   /* See if word-mode shifts by BITS_PER_WORD...BITS_PER_WORD * 2 - 1 will
+      fill the result with sign or zero bits as appropriate.  If so, the value
+      of OUTOF_TARGET will always be (SHIFT OUTOF_INPUT OP1).   Recursively call
+      this routine to calculate INTO_TARGET (which depends on both OUTOF_INPUT
+      and INTO_INPUT), then emit code to set up OUTOF_TARGET.
+ 
+      This isn't worthwhile for constant shifts since the optimizers will
+      cope better with in-range shift counts.  */
+   if (shift_mask >= BITS_PER_WORD
+       && outof_target != 0
+       && !CONSTANT_P (op1))
+     {
+       if (!expand_doubleword_shift (op1_mode, binoptab,
+ 				    outof_input, into_input, op1,
+ 				    0, into_target,
+ 				    unsignedp, methods, shift_mask))
+ 	return false;
+       if (!force_expand_binop (word_mode, binoptab, outof_input, op1,
+ 			       outof_target, unsignedp, methods))
+ 	return false;
+       return true;
+     }
+ 
+   /* Set CMP_CODE, CMP1 and CMP2 so that the rtx (CMP_CODE CMP1 CMP2)
+      is true when the effective shift value is less than BITS_PER_WORD.
+      Set SUPERWORD_OP1 to the shift count that should be used to shift
+      OUTOF_INPUT into INTO_TARGET when the condition is false.  */
+   tmp = immed_double_const (BITS_PER_WORD, 0, op1_mode);
+   if (!CONSTANT_P (op1) && shift_mask == BITS_PER_WORD - 1)
+     {
+       /* Set CMP1 to OP1 & BITS_PER_WORD.  The result is zero iff OP1
+ 	 is a subword shift count.  */
+       cmp1 = simplify_expand_binop (op1_mode, and_optab, op1, tmp,
+ 				    0, true, methods);
+       cmp2 = CONST0_RTX (op1_mode);
+       cmp_code = EQ;
+       superword_op1 = op1;
+     }
+   else
+     {
+       /* Set CMP1 to OP1 - BITS_PER_WORD.  */
+       cmp1 = simplify_expand_binop (op1_mode, sub_optab, op1, tmp,
+ 				    0, true, methods);
+       cmp2 = CONST0_RTX (op1_mode);
+       cmp_code = LT;
+       superword_op1 = cmp1;
+     }
+   if (cmp1 == 0)
+     return false;
+ 
+   /* If we can compute the condition at compile time, pick the
+      appropriate subroutine.  */
+   tmp = simplify_relational_operation (cmp_code, SImode, op1_mode, cmp1, cmp2);
+   if (tmp != 0 && GET_CODE (tmp) == CONST_INT)
+     {
+       if (tmp == const0_rtx)
+ 	return expand_superword_shift (binoptab, outof_input, superword_op1,
+ 				       outof_target, into_target,
+ 				       unsignedp, methods);
+       else
+ 	return expand_subword_shift (op1_mode, binoptab,
+ 				     outof_input, into_input, op1,
+ 				     outof_target, into_target,
+ 				     unsignedp, methods, shift_mask);
+     }
+ 
+ #ifdef HAVE_conditional_move
+   /* Try using conditional moves to generate straight-line code.  */
+   {
+     rtx start = get_last_insn ();
+     if (expand_doubleword_shift_condmove (op1_mode, binoptab,
+ 					  cmp_code, cmp1, cmp2,
+ 					  outof_input, into_input,
+ 					  op1, superword_op1,
+ 					  outof_target, into_target,
+ 					  unsignedp, methods, shift_mask))
+       return true;
+     delete_insns_since (start);
+   }
+ #endif
+ 
+   /* As a last resort, use branches to select the correct alternative.  */
+   subword_label = gen_label_rtx ();
+   done_label = gen_label_rtx ();
+ 
+   do_compare_rtx_and_jump (cmp1, cmp2, cmp_code, false, op1_mode,
+ 			   0, 0, subword_label);
+ 
+   if (!expand_superword_shift (binoptab, outof_input, superword_op1,
+ 			       outof_target, into_target,
+ 			       unsignedp, methods))
+     return false;
+ 
+   emit_jump_insn (gen_jump (done_label));
+   emit_barrier ();
+   emit_label (subword_label);
+ 
+   if (!expand_subword_shift (op1_mode, binoptab,
+ 			     outof_input, into_input, op1,
+ 			     outof_target, into_target,
+ 			     unsignedp, methods, shift_mask))
+     return false;
+ 
+   emit_label (done_label);
+   return true;
+ }
  
  /* Wrapper around expand_binop which takes an rtx code to specify
     the operation to perform, not an optab pointer.  All other
*************** expand_binop (enum machine_mode mode, op
*** 1035,1152 ****
    if ((binoptab == lshr_optab || binoptab == ashl_optab
         || binoptab == ashr_optab)
        && class == MODE_INT
!       && GET_CODE (op1) == CONST_INT
        && GET_MODE_SIZE (mode) == 2 * UNITS_PER_WORD
        && binoptab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing
        && ashl_optab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing
        && lshr_optab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing)
      {
!       rtx insns, inter, equiv_value;
!       rtx into_target, outof_target;
!       rtx into_input, outof_input;
!       int shift_count, left_shift, outof_word;
! 
!       /* If TARGET is the same as one of the operands, the REG_EQUAL note
! 	 won't be accurate, so use a new target.  */
!       if (target == 0 || target == op0 || target == op1)
! 	target = gen_reg_rtx (mode);
! 
!       start_sequence ();
! 
!       shift_count = INTVAL (op1);
! 
!       /* OUTOF_* is the word we are shifting bits away from, and
! 	 INTO_* is the word that we are shifting bits towards, thus
! 	 they differ depending on the direction of the shift and
! 	 WORDS_BIG_ENDIAN.  */
! 
!       left_shift = binoptab == ashl_optab;
!       outof_word = left_shift ^ ! WORDS_BIG_ENDIAN;
! 
!       outof_target = operand_subword (target, outof_word, 1, mode);
!       into_target = operand_subword (target, 1 - outof_word, 1, mode);
! 
!       outof_input = operand_subword_force (op0, outof_word, mode);
!       into_input = operand_subword_force (op0, 1 - outof_word, mode);
! 
!       if (shift_count >= BITS_PER_WORD)
! 	{
! 	  inter = expand_binop (word_mode, binoptab,
! 			       outof_input,
! 			       GEN_INT (shift_count - BITS_PER_WORD),
! 			       into_target, unsignedp, next_methods);
! 
! 	  if (inter != 0 && inter != into_target)
! 	    emit_move_insn (into_target, inter);
! 
! 	  /* For a signed right shift, we must fill the word we are shifting
! 	     out of with copies of the sign bit.  Otherwise it is zeroed.  */
! 	  if (inter != 0 && binoptab != ashr_optab)
! 	    inter = CONST0_RTX (word_mode);
! 	  else if (inter != 0)
! 	    inter = expand_binop (word_mode, binoptab,
! 				  outof_input,
! 				  GEN_INT (BITS_PER_WORD - 1),
! 				  outof_target, unsignedp, next_methods);
! 
! 	  if (inter != 0 && inter != outof_target)
! 	    emit_move_insn (outof_target, inter);
! 	}
!       else
! 	{
! 	  rtx carries;
! 	  optab reverse_unsigned_shift, unsigned_shift;
! 
! 	  /* For a shift of less then BITS_PER_WORD, to compute the carry,
! 	     we must do a logical shift in the opposite direction of the
! 	     desired shift.  */
! 
! 	  reverse_unsigned_shift = (left_shift ? lshr_optab : ashl_optab);
! 
! 	  /* For a shift of less than BITS_PER_WORD, to compute the word
! 	     shifted towards, we need to unsigned shift the orig value of
! 	     that word.  */
! 
! 	  unsigned_shift = (left_shift ? ashl_optab : lshr_optab);
! 
! 	  carries = expand_binop (word_mode, reverse_unsigned_shift,
! 				  outof_input,
! 				  GEN_INT (BITS_PER_WORD - shift_count),
! 				  0, unsignedp, next_methods);
! 
! 	  if (carries == 0)
! 	    inter = 0;
! 	  else
! 	    inter = expand_binop (word_mode, unsigned_shift, into_input,
! 				  op1, 0, unsignedp, next_methods);
! 
! 	  if (inter != 0)
! 	    inter = expand_binop (word_mode, ior_optab, carries, inter,
! 				  into_target, unsignedp, next_methods);
! 
! 	  if (inter != 0 && inter != into_target)
! 	    emit_move_insn (into_target, inter);
! 
! 	  if (inter != 0)
! 	    inter = expand_binop (word_mode, binoptab, outof_input,
! 				  op1, outof_target, unsignedp, next_methods);
  
! 	  if (inter != 0 && inter != outof_target)
! 	    emit_move_insn (outof_target, inter);
! 	}
! 
!       insns = get_insns ();
!       end_sequence ();
! 
!       if (inter != 0)
! 	{
! 	  if (binoptab->code != UNKNOWN)
! 	    equiv_value = gen_rtx_fmt_ee (binoptab->code, mode, op0, op1);
! 	  else
! 	    equiv_value = 0;
  
! 	  emit_no_conflict_block (insns, target, op0, op1, equiv_value);
! 	  return target;
  	}
      }
  
--- 1384,1454 ----
    if ((binoptab == lshr_optab || binoptab == ashl_optab
         || binoptab == ashr_optab)
        && class == MODE_INT
!       && (GET_CODE (op1) == CONST_INT || !optimize_size)
        && GET_MODE_SIZE (mode) == 2 * UNITS_PER_WORD
        && binoptab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing
        && ashl_optab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing
        && lshr_optab->handlers[(int) word_mode].insn_code != CODE_FOR_nothing)
      {
!       unsigned HOST_WIDE_INT shift_mask, double_shift_mask;
!       enum machine_mode op1_mode;
  
!       double_shift_mask = targetm.shift_truncation_mask (mode);
!       shift_mask = targetm.shift_truncation_mask (word_mode);
!       op1_mode = GET_MODE (op1) != VOIDmode ? GET_MODE (op1) : word_mode;
! 
!       /* Apply the truncation to constant shifts.  */
!       if (double_shift_mask > 0 && GET_CODE (op1) == CONST_INT)
! 	op1 = GEN_INT (INTVAL (op1) & double_shift_mask);
! 
!       if (op1 == CONST0_RTX (op1_mode))
! 	return op0;
! 
!       /* Make sure that this is a combination that expand_doubleword_shift
! 	 can handle.  See the comments there for details.  */
!       if (double_shift_mask == 0
! 	  || (shift_mask == BITS_PER_WORD - 1
! 	      && double_shift_mask == BITS_PER_WORD * 2 - 1))
! 	{
! 	  rtx insns, equiv_value;
! 	  rtx into_target, outof_target;
! 	  rtx into_input, outof_input;
! 	  int left_shift, outof_word;
! 
! 	  /* If TARGET is the same as one of the operands, the REG_EQUAL note
! 	     won't be accurate, so use a new target.  */
! 	  if (target == 0 || target == op0 || target == op1)
! 	    target = gen_reg_rtx (mode);
! 
! 	  start_sequence ();
! 
! 	  /* OUTOF_* is the word we are shifting bits away from, and
! 	     INTO_* is the word that we are shifting bits towards, thus
! 	     they differ depending on the direction of the shift and
! 	     WORDS_BIG_ENDIAN.  */
! 
! 	  left_shift = binoptab == ashl_optab;
! 	  outof_word = left_shift ^ ! WORDS_BIG_ENDIAN;
! 
! 	  outof_target = operand_subword (target, outof_word, 1, mode);
! 	  into_target = operand_subword (target, 1 - outof_word, 1, mode);
! 
! 	  outof_input = operand_subword_force (op0, outof_word, mode);
! 	  into_input = operand_subword_force (op0, 1 - outof_word, mode);
! 
! 	  if (expand_doubleword_shift (op1_mode, binoptab,
! 				       outof_input, into_input, op1,
! 				       outof_target, into_target,
! 				       unsignedp, methods, shift_mask))
! 	    {
! 	      insns = get_insns ();
! 	      end_sequence ();
  
! 	      equiv_value = gen_rtx_fmt_ee (binoptab->code, mode, op0, op1);
! 	      emit_no_conflict_block (insns, target, op0, op1, equiv_value);
! 	      return target;
! 	    }
! 	  end_sequence ();
  	}
      }
  
Index: config/arm/arm.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/arm/arm.c,v
retrieving revision 1.399
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.399 arm.c
*** config/arm/arm.c	25 Aug 2004 09:52:09 -0000	1.399
--- config/arm/arm.c	31 Aug 2004 18:45:34 -0000
*************** static tree arm_get_cookie_size (tree);
*** 173,179 ****
  static bool arm_cookie_has_size (void);
  static bool arm_cxx_cdtor_returns_this (void);
  static void arm_init_libfuncs (void);
! 
  
  /* Initialize the GCC target structure.  */
  #if TARGET_DLLIMPORT_DECL_ATTRIBUTES
--- 173,179 ----
  static bool arm_cookie_has_size (void);
  static bool arm_cxx_cdtor_returns_this (void);
  static void arm_init_libfuncs (void);
! static unsigned HOST_WIDE_INT arm_shift_truncation_mask (enum machine_mode);
  
  /* Initialize the GCC target structure.  */
  #if TARGET_DLLIMPORT_DECL_ATTRIBUTES
*************** #define TARGET_RTX_COSTS arm_slowmul_rtx
*** 246,251 ****
--- 246,253 ----
  #undef  TARGET_ADDRESS_COST
  #define TARGET_ADDRESS_COST arm_address_cost
  
+ #undef TARGET_SHIFT_TRUNCATION_MASK
+ #define TARGET_SHIFT_TRUNCATION_MASK arm_shift_truncation_mask
  #undef TARGET_VECTOR_MODE_SUPPORTED_P
  #define TARGET_VECTOR_MODE_SUPPORTED_P arm_vector_mode_supported_p
  
*************** arm_vector_mode_supported_p (enum machin
*** 14307,14309 ****
--- 14309,14322 ----
  
    return false;
  }
+ 
+ /* Implement TARGET_SHIFT_TRUNCATION_MASK.  SImode shifts use normal
+    ARM insns and therefore guarantee that the shift count is modulo 256.
+    DImode shifts (those implemented by libgcc1.asm or by optabs.c)
+    guarantee no particular behavior for out-of-range counts.  */
+ 
+ static unsigned HOST_WIDE_INT
+ arm_shift_truncation_mask (enum machine_mode mode)
+ {
+   return mode == SImode ? 255 : 0;
+ }

From ppopov@mvista.com Tue Aug 31 22:40:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 Aug 2004 22:40:56 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:48893 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225207AbUHaVkw>;
	Tue, 31 Aug 2004 22:40:52 +0100
Received: from [10.0.10.221] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA30822;
	Tue, 31 Aug 2004 14:40:48 -0700
Message-ID: <4134F061.5080502@mvista.com>
Date: Tue, 31 Aug 2004 14:40:49 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ichinoh@mb.neweb.ne.jp
CC: linux-mips@linux-mips.org
Subject: Re: Reset of USB
References: <F7800BBC-FB5C-11D8-85DA-000A956B2316@mb.neweb.ne.jp>
In-Reply-To: <F7800BBC-FB5C-11D8-85DA-000A956B2316@mb.neweb.ne.jp>
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: 5754
X-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

ichinoh@mb.neweb.ne.jp wrote:

> Hello ,
>
> I invoked the Linux kernel on ALCHEMY DBAU1100 by U-BOOT.
>
> The processing which resets USB-OHCI of the head of a kernel is not 
> completed. (refer to *)
>
> Au1100 does not indicate "reset is completed."
> Is this phenomenon experienced?
>
> In addition,
> this phenomenon is not encountered when starting a kernel by YAMON.

Yamon initializes the CPU and then Linux doesn't have to touch too many 
registers. I'm guessing u-boot doesn't setup the clocking correctly, or 
at all, and that might be your problem. The Yamon code for these boards 
is available and it's easy to read the initialization code.  Take a look 
at it and that should solve your problem.

Pete

>
>
> *:
> arch/mips/au1000/common/setup.c
>
> #ifdef CONFIG_USB_OHCI
>     // enable host controller and wait for reset done
>     au_writel(0x08, USB_HOST_CONFIG);
>     udelay(1000);
>     au_writel(0x0E, USB_HOST_CONFIG);
>     udelay(1000);
>     au_readl(USB_HOST_CONFIG); // throw away first read
>     while (!(au_readl(USB_HOST_CONFIG) & 0x10))
>         au_readl(USB_HOST_CONFIG);
> #endif
>
> Best regards,
> Nyauyama
>
>