From michaelanburaj@hotmail.com Thu May  1 00:56:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 May 2003 00:56:57 +0100 (BST)
Received: from bay1-f156.bay1.hotmail.com ([IPv6:::ffff:65.54.245.156]:32269
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225205AbTD3X4z>; Thu, 1 May 2003 00:56:55 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 30 Apr 2003 16:56:48 -0700
Received: from 207.13.167.2 by by1fd.bay1.hotmail.msn.com with HTTP;
	Wed, 30 Apr 2003 23:56:48 GMT
X-Originating-IP: [207.13.167.2]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Cc: lindahl@keyresearch.com
Subject: not able to receive emails from the Mailing lists
Date: Wed, 30 Apr 2003 16:56:48 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F156S37uOP2ace0001fa38@hotmail.com>
X-OriginalArrivalTime: 30 Apr 2003 23:56:48.0588 (UTC) FILETIME=[29A618C0:01C30F74]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2238
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,

I did not receive your mail straight from the Mailing lists. After checking 
the archives I found your email.

For some reason the Mailing lists is not sending me emails. Is there 
something wrong with my subscription request?

Cheers,
-Mike.


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


From fxzhang@ict.ac.cn Thu May  1 06:40:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 May 2003 06:40:31 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:33515
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225196AbTEAFk3>; Thu, 1 May 2003 06:40:29 +0100
Received: (qmail 8814 invoked from network); 1 May 2003 05:14:39 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 1 May 2003 05:14:39 -0000
Message-ID: <3EB0B329.9030603@ict.ac.cn>
Date: Thu, 01 May 2003 13:39:53 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>, gcc@gcc.gnu.org
Subject: GCC -O2 failure for mipsel
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Return-Path: <fxzhang@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2239
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fxzhang@ict.ac.cn
Precedence: bulk
X-list: linux-mips

Hello,
I've met a case where mipsel-linux-gcc -O2 fails,for both
2.96 and the fresh new 3.2.3. Maybe someone can tell me
what's wrong.

I've reduced the problem to the test case below,compile it
with mipsel-linux-gcc -O2(FROM H.J.Lu's redhat miniport,all version,
and 3.2.3 is tested too)


#define PUT_CODE(x,code) ((x)->code = (code))
union test_union {
struct test *t;
int a;
};

struct test {
unsigned short code;
union test_union u[1];
};

char memory[2000];

struct test *test_alloc(int code)
{
struct test *t;
int length=sizeof(struct test);

t = (struct test*)memory;
length = (sizeof(struct test) - sizeof(union test_union)-1)/sizeof(int);
for (;length>=0;length--)
((int*)t)[length] = 0;

PUT_CODE(t,code);

return t;
}

int main()
{
struct test *t;

t = test_alloc(4);

printf("t->code=%d\n",t->code);
}


Problem happens in test_alloc:

00400890 <test_alloc>:
400890: 3c1c0fc0 lui gp,0xfc0
400894: 279c77b0 addiu gp,gp,30640
400898: 0399e021 addu gp,gp,t9
40089c: 8f828054 lw v0,-32684(gp)
4008a0: 8f818054 lw at,-32684(gp)
4008a4: 00000000 nop
4008a8: a4240000 sh a0,0(at)
4008ac: 03e00008 jr ra
4008b0: ac400000 sw zero,0(v0)
--->the last sw is wrong,it should not be reorder to run later than 4008a8.

And gcc experts will find this is a simplfied case of rtx_alloc:).
Yes,the failure
shows up when i try to compile SPEC CPU2000 176.gcc with -O2. The const0_rtx
's code will be set to zero like above.

Thank you in advance.


Regards




From aph@redhat.com Thu May  1 09:28:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 May 2003 09:28:41 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:36358 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225196AbTEAI2j>;
	Thu, 1 May 2003 09:28:39 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h418RoD29377;
	Thu, 1 May 2003 04:27:50 -0400
Received: from redhat.com (IDENT:y6RMD+R7Tdq3XkYrX2sKatLSNiJ11hpr@vpn50-7.rdu.redhat.com [172.16.50.7])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h418Rnq19269;
	Thu, 1 May 2003 04:27:49 -0400
Received: (from aph@localhost)
	by redhat.com (8.11.6/8.11.0) id h418Rid05801;
	Thu, 1 May 2003 09:27:44 +0100
From: Andrew Haley <aph@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16048.55936.346808.522687@cuddles.redhat.com>
Date: Thu, 1 May 2003 09:27:44 +0100
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>, gcc@gcc.gnu.org
Subject: GCC -O2 failure for mipsel
In-Reply-To: <3EB0B329.9030603@ict.ac.cn>
References: <3EB0B329.9030603@ict.ac.cn>
X-Mailer: VM 7.14 under Emacs 21.2.1
Return-Path: <aph@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-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2240
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aph@redhat.com
Precedence: bulk
X-list: linux-mips

Fuxin Zhang writes:
 > Hello,
 > I've met a case where mipsel-linux-gcc -O2 fails,for both
 > 2.96 and the fresh new 3.2.3. Maybe someone can tell me
 > what's wrong.

Your code is incorrect.

 > I've reduced the problem to the test case below,compile it
 > with mipsel-linux-gcc -O2(FROM H.J.Lu's redhat miniport,all version,
 > and 3.2.3 is tested too)
 > 
 > 
 > #define PUT_CODE(x,code) ((x)->code = (code))
 > union test_union {
 > struct test *t;
 > int a;
 > };
 > 
 > struct test {
 > unsigned short code;
 > union test_union u[1];
 > };
 > 
 > char memory[2000];
 > 
 > struct test *test_alloc(int code)
 > {
 > struct test *t;
 > int length=sizeof(struct test);
 > 
 > t = (struct test*)memory;
 > length = (sizeof(struct test) - sizeof(union test_union)-1)/sizeof(int);
 > for (;length>=0;length--)

This is the errant line:

 > ((int*)t)[length] = 0;

You have declared t as a pointer to struct test, but you're using it
as a pointer to int.  If you look at Pointers, Section 6.2.2.3 in ISO
9899-1990 you'll see that this results in undefined behaviour.

-fno-strict-aliasing should generate the code you want, but it's
better to fix your source.  If you want to use a pointer as a
different type, put it in a union.

Andrew.

From fxzhang@ict.ac.cn Thu May  1 09:42:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 May 2003 09:42:19 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:23168
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225196AbTEAImR>; Thu, 1 May 2003 09:42:17 +0100
Received: (qmail 4954 invoked from network); 1 May 2003 08:16:27 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 1 May 2003 08:16:27 -0000
Message-ID: <3EB0DDC6.5080108@ict.ac.cn>
Date: Thu, 01 May 2003 16:41:42 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: Andrew Haley <aph@redhat.com>
CC: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>, gcc@gcc.gnu.org
Subject: Re: GCC -O2 failure for mipsel
References: <3EB0B329.9030603@ict.ac.cn> <16048.55936.346808.522687@cuddles.redhat.com>
In-Reply-To: <16048.55936.346808.522687@cuddles.redhat.com>
Content-Type: text/plain; charset=gb18030; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <fxzhang@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2241
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fxzhang@ict.ac.cn
Precedence: bulk
X-list: linux-mips

 Thanks, -fno-strict-aliasing works.
--The actual code can't be changed: because it is part of spec cpu2000:)

Andrew Haley wrote:

>Fuxin Zhang writes:
> > Hello,
> > I've met a case where mipsel-linux-gcc -O2 fails,for both
> > 2.96 and the fresh new 3.2.3. Maybe someone can tell me
> > what's wrong.
>
>Your code is incorrect.
>
> > I've reduced the problem to the test case below,compile it
> > with mipsel-linux-gcc -O2(FROM H.J.Lu's redhat miniport,all version,
> > and 3.2.3 is tested too)
> > 
> > 
> > #define PUT_CODE(x,code) ((x)->code = (code))
> > union test_union {
> > struct test *t;
> > int a;
> > };
> > 
> > struct test {
> > unsigned short code;
> > union test_union u[1];
> > };
> > 
> > char memory[2000];
> > 
> > struct test *test_alloc(int code)
> > {
> > struct test *t;
> > int length=sizeof(struct test);
> > 
> > t = (struct test*)memory;
> > length = (sizeof(struct test) - sizeof(union test_union)-1)/sizeof(int);
> > for (;length>=0;length--)
>
>This is the errant line:
>
> > ((int*)t)[length] = 0;
>
>You have declared t as a pointer to struct test, but you're using it
>as a pointer to int.  If you look at Pointers, Section 6.2.2.3 in ISO
>9899-1990 you'll see that this results in undefined behaviour.
>
>-fno-strict-aliasing should generate the code you want, but it's
>better to fix your source.  If you want to use a pointer as a
>different type, put it in a union.
>
>Andrew.
>
>
>  
>


From aph@redhat.com Thu May  1 09:46:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 May 2003 09:46:33 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:53262 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225196AbTEAIqb>;
	Thu, 1 May 2003 09:46:31 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h418kRD00468;
	Thu, 1 May 2003 04:46:27 -0400
Received: from redhat.com (IDENT:g1uT+0K5dE+oNhWqHzBheWaHvt6PAWVt@vpn50-11.rdu.redhat.com [172.16.50.11])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h418kRq23564;
	Thu, 1 May 2003 04:46:27 -0400
Received: (from aph@localhost)
	by redhat.com (8.11.6/8.11.0) id h418kM006000;
	Thu, 1 May 2003 09:46:22 +0100
From: Andrew Haley <aph@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16048.57054.224964.883062@cuddles.redhat.com>
Date: Thu, 1 May 2003 09:46:22 +0100
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>, gcc@gcc.gnu.org
Subject: Re: GCC -O2 failure for mipsel
In-Reply-To: <3EB0DDC6.5080108@ict.ac.cn>
References: <3EB0B329.9030603@ict.ac.cn>
	<16048.55936.346808.522687@cuddles.redhat.com>
	<3EB0DDC6.5080108@ict.ac.cn>
X-Mailer: VM 7.14 under Emacs 21.2.1
Return-Path: <aph@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-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2242
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aph@redhat.com
Precedence: bulk
X-list: linux-mips

Fuxin Zhang writes:
 >  Thanks, -fno-strict-aliasing works.
 > --The actual code can't be changed: because it is part of spec cpu2000:)

Perhaps SPEC need to have ISO C explained to them...

Andrew.

From lindahl@keyresearch.com Thu May  1 09:50:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 May 2003 09:50:25 +0100 (BST)
Received: from 12-234-18-241.client.attbi.com ([IPv6:::ffff:12.234.18.241]:57216
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225196AbTEAIuX>; Thu, 1 May 2003 09:50:23 +0100
Received: from localhost.localdomain (greglaptop [127.0.0.1])
	by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h418oKnm001900
	for <linux-mips@linux-mips.org>; Thu, 1 May 2003 01:50:20 -0700
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id h418oJQR001898
	for linux-mips@linux-mips.org; Thu, 1 May 2003 01:50:19 -0700
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 1 May 2003 01:50:18 -0700
From: Greg Lindahl <lindahl@keyresearch.com>
To: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: GCC -O2 failure for mipsel
Message-ID: <20030501085018.GA1885@greglaptop.attbi.com>
Mail-Followup-To: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
References: <3EB0B329.9030603@ict.ac.cn> <16048.55936.346808.522687@cuddles.redhat.com> <3EB0DDC6.5080108@ict.ac.cn> <16048.57054.224964.883062@cuddles.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16048.57054.224964.883062@cuddles.redhat.com>
User-Agent: Mutt/1.4.1i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2243
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Thu, May 01, 2003 at 09:46:22AM +0100, Andrew Haley wrote:
> Fuxin Zhang writes:
>  >  Thanks, -fno-strict-aliasing works.
>  > --The actual code can't be changed: because it is part of spec cpu2000:)
> 
> Perhaps SPEC need to have ISO C explained to them...

It's just there so you can't turn on aliasing for reasonable base
options. It's all a conspiracy, I tell you...

greg


From michaelanburaj@hotmail.com Thu May  1 09:53:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 May 2003 09:53:31 +0100 (BST)
Received: from bay1-f21.bay1.hotmail.com ([IPv6:::ffff:65.54.245.21]:63238
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225196AbTEAIx3>; Thu, 1 May 2003 09:53:29 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 1 May 2003 01:53:21 -0700
Received: from 4.3.108.196 by by1fd.bay1.hotmail.msn.com with HTTP;
	Thu, 01 May 2003 08:53:21 GMT
X-Originating-IP: [4.3.108.196]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Thu, 01 May 2003 01:53:21 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F21LXSNq5rwfvh00018d6b@hotmail.com>
X-OriginalArrivalTime: 01 May 2003 08:53:21.0829 (UTC) FILETIME=[1E50D550:01C30FBF]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2244
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,

I got passed the config issue, Thanks to all & Greg.

Now when I try making "make ARCH=mips", I get a lot of errors:

/usr/src/linux-2.4.20-6/include/linux/mm.h:188: parse error before 
`pte_addr_t'
/usr/src/linux-2.4.20-6/include/linux/mm.h:188: warning: no semicolon at end 
of
struct or union
/usr/src/linux-2.4.20-6/include/linux/mm.h:188: warning: no semicolon at end 
of
struct or union
/usr/src/linux-2.4.20-6/include/linux/mm.h:189: warning: type defaults to 
`int'
in declaration of `pte'
/usr/src/linux-2.4.20-6/include/linux/mm.h:189: warning: data definition has 
no
type or storage class
/usr/src/linux-2.4.20-6/include/linux/mm.h:208: parse error before `}'


I get more error like the ones above.

Please let me know the reason for the same.

Thanks,
-Mike.

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


From pinskia@physics.uc.edu Thu May  1 12:01:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 May 2003 12:01:08 +0100 (BST)
Received: from nr2-216-196-136-17.fuse.net ([IPv6:::ffff:216.196.136.17]:29962
	"EHLO dellpi.pinski.fam") by linux-mips.org with ESMTP
	id <S8225196AbTEALBB>; Thu, 1 May 2003 12:01:01 +0100
Received: from physics.uc.edu (IDENT:pinskia@localhost.pinski.fam [127.0.0.1])
	by dellpi.pinski.fam (8.12.2/8.12.1) with ESMTP id h41B0oMJ025267;
	Thu, 1 May 2003 07:00:50 -0400 (EDT)
Date: Thu, 1 May 2003 07:00:51 -0400
Subject: Re: GCC -O2 failure for mipsel
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Andrew Pinski <pinskia@physics.uc.edu>,
	Fuxin Zhang <fxzhang@ict.ac.cn>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>,
	gcc@gcc.gnu.org
To: Andrew Haley <aph@redhat.com>
From: Andrew Pinski <pinskia@physics.uc.edu>
In-Reply-To: <16048.57054.224964.883062@cuddles.redhat.com>
Message-Id: <2BE9BD5D-7BC4-11D7-A4A1-000393A6D2F2@physics.uc.edu>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Return-Path: <pinskia@physics.uc.edu>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2245
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pinskia@physics.uc.edu
Precedence: bulk
X-list: linux-mips

It is the gcc component of SPEC that needs explaining to, this has been 
talked about before:
<http://gcc.gnu.org/ml/gcc/2002-01/msg00711.html>

Thanks,
Andrew Pinski

On Thursday, May 1, 2003, at 04:46 US/Eastern, Andrew Haley wrote:

> Fuxin Zhang writes:
>>  Thanks, -fno-strict-aliasing works.
>> --The actual code can't be changed: because it is part of spec 
>> cpu2000:)
>
> Perhaps SPEC need to have ISO C explained to them...
>
> Andrew.
>
>


From ashish_ibm@rediffmail.com Thu May  1 15:33:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 May 2003 15:33:04 +0100 (BST)
Received: from webmail35.rediffmail.com ([IPv6:::ffff:203.199.83.246]:30117
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225196AbTEAOdA>; Thu, 1 May 2003 15:33:00 +0100
Received: (qmail 1495 invoked by uid 510); 1 May 2003 14:32:41 -0000
Date: 1 May 2003 14:32:41 -0000
Message-ID: <20030501143241.1494.qmail@webmail35.rediffmail.com>
Received: from unknown (210.210.48.141) by rediffmail.com via HTTP; 01 may 2003 14:32:41 -0000
MIME-Version: 1.0
From: "ashish  anand" <ashish_ibm@rediffmail.com>
Reply-To: "ashish  anand" <ashish_ibm@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: running purely uncached ..
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <ashish_ibm@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2246
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish_ibm@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello,

I am back to mips plateform after a long gap.
in my kernel source tree i observed in arch/mips/mm/r4xx0.c 
though
there are other support routines for flush , invalidate and 
maintain
the cache consistency ..but there is no mention of running purely 
uncached using the old style code CONFIG_MIPS_UNCACHED or 
otherwise.

Best Regards,
Ashish





From ralf@linux-mips.net Thu May  1 20:26:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 May 2003 20:27:01 +0100 (BST)
Received: from p508B5752.dip.t-dialin.net ([IPv6:::ffff:80.139.87.82]:30389
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225196AbTEAT0s>; Thu, 1 May 2003 20:26:48 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h41JQPX23531;
	Thu, 1 May 2003 21:26:25 +0200
Date: Thu, 1 May 2003 21:26:25 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: ashish anand <ashish_ibm@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: running purely uncached ..
Message-ID: <20030501212625.A17635@linux-mips.org>
References: <20030501143241.1494.qmail@webmail35.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030501143241.1494.qmail@webmail35.rediffmail.com>; from ashish_ibm@rediffmail.com on Thu, May 01, 2003 at 02:32:41PM -0000
Return-Path: <ralf@linux-mips.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2247
X-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, May 01, 2003 at 02:32:41PM -0000, ashish  anand wrote:

> in my kernel source tree i observed in arch/mips/mm/r4xx0.c though
> there are other support routines for flush , invalidate and maintain
> the cache consistency ..but there is no mention of running purely 
> uncached using the old style code CONFIG_MIPS_UNCACHED or otherwise.

CONFIG_MIPS_UNCACHED still exists but it's only selectable when SMP
support is disabled.

Usual warning applies - running uncached is not well supported and is
extremly slow.  It is mostly intended for hardware people who need to
observe all actions of the processor externally.

  Ralf

From baitisj@idealab.com Fri May  2 02:47:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 May 2003 02:47:18 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:7622 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225196AbTEBBrP>;
	Fri, 2 May 2003 02:47:15 +0100
Received: (qmail 20312 invoked by uid 6180); 2 May 2003 01:47:11 -0000
Date: Thu, 1 May 2003 18:47:11 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: linux-mips@linux-mips.org
Subject: Yenta: probing ISA IRQs on a non-ISA machine and sometimes locking up!  ;)
Message-ID: <20030501184711.D30468@luca.pas.lab>
Reply-To: baitisj@evolution.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2248
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

Delving further into the PCI->CardBus bridge, I noticed that my system locks up
under certain conditions when the yenta_socket driver is trying to probe
for PCMCIA ISA interrupts.

yenta_get_socket_capabilities() calls probe_irq_on() in arch/mips/kernel/irq.c.
The lock up happens when the probe performs the first iteration over the IRQ
descriptors, looking for longstanding IRQs. I added some debugging output, and
it get down to IRQ 34, and then stopped. (AU1000 GPIO pin 2? this pin isn't
connected on our board... )

Anyhow, when the probe *does* succeed, the IRQ poll returns 0x0000. I guess my
question is, why even bother with this polling on a machine without an ISA bus?
I believe that the CardBus bridge PCI configuration registers route socket
events to the PCI INTA pin anyway...

My happy hack is to have yenta_get_socket_capabilities always return 0x0. But
I'm still concerned that probe_irq_on() intermittently fails...

Thanks for letting me interrupt you with this question.

Regards,
Jeff

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From michaelanburaj@hotmail.com Fri May  2 04:25:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 May 2003 04:25:34 +0100 (BST)
Received: from bay1-f28.bay1.hotmail.com ([IPv6:::ffff:65.54.245.28]:51209
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225200AbTEBDZb>; Fri, 2 May 2003 04:25:31 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 1 May 2003 20:25:21 -0700
Received: from 4.3.108.196 by by1fd.bay1.hotmail.msn.com with HTTP;
	Fri, 02 May 2003 03:25:20 GMT
X-Originating-IP: [4.3.108.196]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
Date: Thu, 01 May 2003 20:25:20 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F28gEpTX5V3Gyk00001423@hotmail.com>
X-OriginalArrivalTime: 02 May 2003 03:25:21.0224 (UTC) FILETIME=[762C9480:01C3105A]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2249
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,

I gave up on the linux source from Redhat 9. Now I pulled source from CVS
$ cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co linux

Then I configured using,
$ make ARCH=mips menuconfig

selected Atlas board & saved it.

Then I get the following errors while trying to build the image:

[root@localhost linux]# make
make -f scripts/Makefile.build obj=arch/mips/kernel 
arch/mips/kernel/offset.s
  gcc -Wp,-MD,arch/mips/kernel/.offset.s.d -D__KERNEL__ -Iinclude -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
-fno-strict-aliasing -fno-common -I /usr/src/linux/include/asm/gcc -G 0 
-mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -nostdinc 
-iwithprefix include    -DKBUILD_BASENAME=offset   -S -o 
arch/mips/kernel/offset.s arch/mips/kernel/offset.c
gcc: cannot specify -o with -c or -S and multiple compilations
make[1]: *** [arch/mips/kernel/offset.s] Error 1
make: *** [arch/mips/kernel/offset.s] Error 2

Please somebody, who built linux image for Atlas 4Kc board earlier, show me 
the procedure to build Redboot linux images (srec).

will this dream come true? I am new to linux & I could only affored a Atlas 
board for myself to learn linux on MIPS at home.

Please help me!!!

Thanks,
-Mike.



>From: "Michael Anburaj" <michaelanburaj@hotmail.com>
>To: linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board
>Date: Thu, 01 May 2003 01:53:21 -0700
>
>Hi,
>
>I got passed the config issue, Thanks to all & Greg.
>
>Now when I try making "make ARCH=mips", I get a lot of errors:
>
>/usr/src/linux-2.4.20-6/include/linux/mm.h:188: parse error before 
>`pte_addr_t'
>/usr/src/linux-2.4.20-6/include/linux/mm.h:188: warning: no semicolon at 
>end of
>struct or union
>/usr/src/linux-2.4.20-6/include/linux/mm.h:188: warning: no semicolon at 
>end of
>struct or union
>/usr/src/linux-2.4.20-6/include/linux/mm.h:189: warning: type defaults to 
>`int'
>in declaration of `pte'
>/usr/src/linux-2.4.20-6/include/linux/mm.h:189: warning: data definition 
>has no
>type or storage class
>/usr/src/linux-2.4.20-6/include/linux/mm.h:208: parse error before `}'
>
>
>I get more error like the ones above.
>
>Please let me know the reason for the same.
>
>Thanks,
>-Mike.
>
>_________________________________________________________________
>Protect your PC - get McAfee.com VirusScan Online  
>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>


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


From kaos@sgi.com Fri May  2 05:18:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 May 2003 05:18:32 +0100 (BST)
Received: from zok.SGI.COM ([IPv6:::ffff:204.94.215.101]:5808 "EHLO
	zok.sgi.com") by linux-mips.org with ESMTP id <S8225200AbTEBESa>;
	Fri, 2 May 2003 05:18:30 +0100
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130])
	by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h424IKVV014914;
	Thu, 1 May 2003 21:18:21 -0700
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA04399; Fri, 2 May 2003 14:18:19 +1000
Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331)
	id 7D7403001F4; Fri,  2 May 2003 14:18:18 +1000 (EST)
Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1])
	by kao2.melbourne.sgi.com (Postfix) with ESMTP
	id 65838164; Fri,  2 May 2003 14:18:18 +1000 (EST)
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
From: Keith Owens <kaos@sgi.com>
To: "Michael Anburaj" <michaelanburaj@hotmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board -problems :( 
In-reply-to: Your message of "Thu, 01 May 2003 20:25:20 MST."
             <BAY1-F28gEpTX5V3Gyk00001423@hotmail.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 02 May 2003 14:18:13 +1000
Message-ID: <8921.1051849093@kao2.melbourne.sgi.com>
Return-Path: <kaos@sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2250
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@sgi.com
Precedence: bulk
X-list: linux-mips

On Thu, 01 May 2003 20:25:20 -0700, 
"Michael Anburaj" <michaelanburaj@hotmail.com> wrote:
>Then I configured using,
>$ make ARCH=mips menuconfig
>[root@localhost linux]# make
>make -f scripts/Makefile.build obj=arch/mips/kernel 
>arch/mips/kernel/offset.s
>  gcc -Wp,-MD,arch/mips/kernel/.offset.s.d -D__KERNEL__ -Iinclude -Wall 
>-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
>-fno-strict-aliasing -fno-common -I /usr/src/linux/include/asm/gcc -G 0 
>-mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -nostdinc 
>-iwithprefix include    -DKBUILD_BASENAME=offset   -S -o 
>arch/mips/kernel/offset.s arch/mips/kernel/offset.c
>gcc: cannot specify -o with -c or -S and multiple compilations
>make[1]: *** [arch/mips/kernel/offset.s] Error 1
>make: *** [arch/mips/kernel/offset.s] Error 2

You have to specify ARCH=mips on _all_ make commands, not just make
*config.  Do 'make ARCH=mips' for the second one.


From michaelanburaj@hotmail.com Fri May  2 06:07:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 May 2003 06:07:43 +0100 (BST)
Received: from bay1-f99.bay1.hotmail.com ([IPv6:::ffff:65.54.245.99]:30472
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225200AbTEBFHl>; Fri, 2 May 2003 06:07:41 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 1 May 2003 22:07:32 -0700
Received: from 4.3.108.196 by by1fd.bay1.hotmail.msn.com with HTTP;
	Fri, 02 May 2003 05:07:32 GMT
X-Originating-IP: [4.3.108.196]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
Date: Thu, 01 May 2003 22:07:32 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F99BGpEI2rV4Zn000015fa@hotmail.com>
X-OriginalArrivalTime: 02 May 2003 05:07:32.0867 (UTC) FILETIME=[BCEB0D30:01C31068]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2251
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi Keith,

I did try that too...


[root@localhost linux]# make ARCH=mips
make -f scripts/Makefile.build obj=arch/mips/kernel 
arch/mips/kernel/offset.s
  gcc -Wp,-MD,arch/mips/kernel/.offset.s.d -D__KERNEL__ -Iinclude -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
-fno-strict-aliasing -fno-common -I /usr/src/linux/include/asm/gcc -G 0 
-mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -nostdinc 
-iwithprefix include    -DKBUILD_BASENAME=offset   -S -o 
arch/mips/kernel/offset.s arch/mips/kernel/offset.c
gcc: cannot specify -o with -c or -S and multiple compilations
make[1]: *** [arch/mips/kernel/offset.s] Error 1
make: *** [arch/mips/kernel/offset.s] Error 2


Thanks,
-Mike.






>From: Keith Owens <kaos@sgi.com>
>To: "Michael Anburaj" <michaelanburaj@hotmail.com>
>CC: linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board -problems :( Date: Fri, 02 May 
>2003 14:18:13 +1000
>
>On Thu, 01 May 2003 20:25:20 -0700,
>"Michael Anburaj" <michaelanburaj@hotmail.com> wrote:
> >Then I configured using,
> >$ make ARCH=mips menuconfig
> >[root@localhost linux]# make
> >make -f scripts/Makefile.build obj=arch/mips/kernel
> >arch/mips/kernel/offset.s
> >  gcc -Wp,-MD,arch/mips/kernel/.offset.s.d -D__KERNEL__ -Iinclude -Wall
> >-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> >-fno-strict-aliasing -fno-common -I /usr/src/linux/include/asm/gcc -G 0
> >-mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -nostdinc
> >-iwithprefix include    -DKBUILD_BASENAME=offset   -S -o
> >arch/mips/kernel/offset.s arch/mips/kernel/offset.c
> >gcc: cannot specify -o with -c or -S and multiple compilations
> >make[1]: *** [arch/mips/kernel/offset.s] Error 1
> >make: *** [arch/mips/kernel/offset.s] Error 2
>
>You have to specify ARCH=mips on _all_ make commands, not just make
>*config.  Do 'make ARCH=mips' for the second one.
>


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


From kaos@sgi.com Fri May  2 06:22:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 May 2003 06:22:32 +0100 (BST)
Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:27359 "EHLO rj.sgi.com")
	by linux-mips.org with ESMTP id <S8225200AbTEBFW2>;
	Fri, 2 May 2003 06:22:28 +0100
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130])
	by rj.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h425MME0012695;
	Thu, 1 May 2003 22:22:22 -0700
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04935; Fri, 2 May 2003 15:22:20 +1000
Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331)
	id 46DBC3001F4; Fri,  2 May 2003 15:22:18 +1000 (EST)
Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1])
	by kao2.melbourne.sgi.com (Postfix) with ESMTP
	id CD471164; Fri,  2 May 2003 15:22:18 +1000 (EST)
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
From: Keith Owens <kaos@sgi.com>
To: "Michael Anburaj" <michaelanburaj@hotmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board -problems :( 
In-reply-to: Your message of "Thu, 01 May 2003 22:07:32 MST."
             <BAY1-F99BGpEI2rV4Zn000015fa@hotmail.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 02 May 2003 15:22:13 +1000
Message-ID: <9709.1051852933@kao2.melbourne.sgi.com>
Return-Path: <kaos@sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2252
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@sgi.com
Precedence: bulk
X-list: linux-mips

On Thu, 01 May 2003 22:07:32 -0700, 
"Michael Anburaj" <michaelanburaj@hotmail.com> wrote:
>I did try that too...
>
>[root@localhost linux]# make ARCH=mips
>make -f scripts/Makefile.build obj=arch/mips/kernel 
>arch/mips/kernel/offset.s
>  gcc -Wp,-MD,arch/mips/kernel/.offset.s.d -D__KERNEL__ -Iinclude -Wall 
>-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
>-fno-strict-aliasing -fno-common -I /usr/src/linux/include/asm/gcc -G 0 
>-mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -nostdinc 
>-iwithprefix include    -DKBUILD_BASENAME=offset   -S -o 
>arch/mips/kernel/offset.s arch/mips/kernel/offset.c
>gcc: cannot specify -o with -c or -S and multiple compilations
>make[1]: *** [arch/mips/kernel/offset.s] Error 1
>make: *** [arch/mips/kernel/offset.s] Error 2

Because you mentioned Redhat 9, I have to assume that you are cross
compiling from i386 to mips, is that correct?  If so, you need make
ARCH=mips and you have to specify the cross compile tools as well,
something like this :-

  make ARCH=mips CROSS_COMPILE=/usr/bin/mips-linux- ...

If you are doing a native mips compile then the problem is that your
version of gcc does not like one or more of the command options, the
unknown option is being treated as a filename.


From michaelanburaj@hotmail.com Fri May  2 07:48:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 May 2003 07:48:09 +0100 (BST)
Received: from bay1-f146.bay1.hotmail.com ([IPv6:::ffff:65.54.245.146]:63754
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225200AbTEBGsH>; Fri, 2 May 2003 07:48:07 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 1 May 2003 23:47:58 -0700
Received: from 4.3.108.196 by by1fd.bay1.hotmail.msn.com with HTTP;
	Fri, 02 May 2003 06:47:57 GMT
X-Originating-IP: [4.3.108.196]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: kaos@sgi.com
Cc: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
Date: Thu, 01 May 2003 23:47:57 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F146KLpgTFur2i000018f6@hotmail.com>
X-OriginalArrivalTime: 02 May 2003 06:47:58.0010 (UTC) FILETIME=[C42EE9A0:01C31076]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2253
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi Keith,

Thanks a lot.

Now its showing some ray of hope....

drivers/char/nvram.c | /sbin/genksyms  -k 2.5.47 > 
include/linux/modules/drivers/char/nvram.ver.tmp
drivers/char/nvram.c:45: warning: `PC' redefined
include/asm/ptrace.h:18: warning: this is the location of the previous 
definition
drivers/char/nvram.c:61: #error Cannot build nvram driver for this machine 
configuration.
make[3]: *** [include/linux/modules/drivers/char/nvram.ver] Error 1
make[2]: *** [drivers/char] Error 2
make[1]: *** [_modver_drivers] Error 2
make: *** [.hdepend] Error 2


Is this (NVRAM) not a mandatory device? If so is it possible to remove it 
using the menuconfig? I chose Atlas 4Kc. Let me know where it is located or 
the issue with this issue.

Thanks again,
-Mike.






>From: Keith Owens <kaos@sgi.com>
>To: "Michael Anburaj" <michaelanburaj@hotmail.com>
>CC: linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board -problems :( Date: Fri, 02 May 
>2003 15:22:13 +1000
>
>On Thu, 01 May 2003 22:07:32 -0700,
>"Michael Anburaj" <michaelanburaj@hotmail.com> wrote:
> >I did try that too...
> >
> >[root@localhost linux]# make ARCH=mips
> >make -f scripts/Makefile.build obj=arch/mips/kernel
> >arch/mips/kernel/offset.s
> >  gcc -Wp,-MD,arch/mips/kernel/.offset.s.d -D__KERNEL__ -Iinclude -Wall
> >-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> >-fno-strict-aliasing -fno-common -I /usr/src/linux/include/asm/gcc -G 0
> >-mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -nostdinc
> >-iwithprefix include    -DKBUILD_BASENAME=offset   -S -o
> >arch/mips/kernel/offset.s arch/mips/kernel/offset.c
> >gcc: cannot specify -o with -c or -S and multiple compilations
> >make[1]: *** [arch/mips/kernel/offset.s] Error 1
> >make: *** [arch/mips/kernel/offset.s] Error 2
>
>Because you mentioned Redhat 9, I have to assume that you are cross
>compiling from i386 to mips, is that correct?  If so, you need make
>ARCH=mips and you have to specify the cross compile tools as well,
>something like this :-
>
>   make ARCH=mips CROSS_COMPILE=/usr/bin/mips-linux- ...
>
>If you are doing a native mips compile then the problem is that your
>version of gcc does not like one or more of the command options, the
>unknown option is being treated as a filename.
>


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


From anemo@mba.ocn.ne.jp Fri May  2 13:57:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 May 2003 13:57:55 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:58305 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225197AbTEBM5x>; Fri, 2 May 2003 13:57:53 +0100
Received: from localhost (p5238-ip01funabasi.chiba.ocn.ne.jp [219.96.147.238])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id CB7613EC2; Fri,  2 May 2003 21:57:45 +0900 (JST)
Date: Fri, 02 May 2003 22:05:17 +0900 (JST)
Message-Id: <20030502.220517.74756988.anemo@mba.ocn.ne.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: initrd_header for mips64 kernel
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2254
X-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 initrd_header in mips64 cvs kernel is broken.  The
initrd_header should be consist of two 32bit words while 32bit
addinitrd is used for 64bit kernel too.

diff -ur linux-mips-cvs/arch/mips64/kernel/setup.c linux.new/arch/mips64/kernel/setup.c
--- linux-mips-cvs/arch/mips64/kernel/setup.c	Wed Apr  9 22:06:57 2003
+++ linux.new/arch/mips64/kernel/setup.c	Fri May  2 21:47:36 2003
@@ -245,7 +245,7 @@
 {
 #ifdef CONFIG_BLK_DEV_INITRD
 	unsigned long tmp;
-	unsigned long *initrd_header;
+	unsigned int *initrd_header;
 #endif
 	unsigned long bootmap_size;
 	unsigned long start_pfn, max_pfn;
@@ -255,7 +255,7 @@
 	tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - 8;
 	if (tmp < (unsigned long)&_end)
 		tmp += PAGE_SIZE;
-	initrd_header = (unsigned long *)tmp;
+	initrd_header = (unsigned int *)tmp;
 	if (initrd_header[0] == 0x494E5244) {
 		initrd_start = (unsigned long)&initrd_header[2];
 		initrd_end = initrd_start + initrd_header[1];
---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Fri May  2 14:57:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 May 2003 14:57:22 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:2001 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225197AbTEBN5U>; Fri, 2 May 2003 14:57:20 +0100
Received: from localhost (p5238-ip01funabasi.chiba.ocn.ne.jp [219.96.147.238])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id B84673F11; Fri,  2 May 2003 22:57:14 +0900 (JST)
Date: Fri, 02 May 2003 23:04:46 +0900 (JST)
Message-Id: <20030502.230446.25481355.anemo@mba.ocn.ne.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Cc: nemoto@toshiba-tops.co.jp
Subject: magic constants in thread_saved_pc and get_wchan
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2255
X-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

There are some magic constants about stack layout in thread_saved_pc()
and get_wchan().  Also I think get_wchan() for 32bit kernel is
something wrong. (it is not easy to explain HOW wrong...)

This patch (for 2.4 cvs) get rid of these magic constants by analyzing
kernel codes in runtime.

I posted same patch some time ago.  This is basically same as the
previous one but regenerated against current cvs tree and now
contains changes for mips64.


diff -ur linux-mips-cvs/arch/mips/kernel/process.c linux.new/arch/mips/kernel/process.c
--- linux-mips-cvs/arch/mips/kernel/process.c	Sat Jan 11 00:49:59 2003
+++ linux.new/arch/mips/kernel/process.c	Fri May  2 22:07:13 2003
@@ -18,6 +18,8 @@
 #include <linux/sys.h>
 #include <linux/user.h>
 #include <linux/a.out.h>
+#include <linux/init.h>
+#include <linux/completion.h>
 
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
@@ -31,6 +33,7 @@
 #include <asm/io.h>
 #include <asm/elf.h>
 #include <asm/isadep.h>
+#include <asm/inst.h>
 
 ATTRIB_NORET void cpu_idle(void)
 {
@@ -169,6 +172,61 @@
 #define first_sched	((unsigned long) scheduling_functions_start_here)
 #define last_sched	((unsigned long) scheduling_functions_end_here)
 
+struct mips_frame_info schedule_frame;
+static struct mips_frame_info schedule_timeout_frame;
+static struct mips_frame_info sleep_on_frame;
+static struct mips_frame_info sleep_on_timeout_frame;
+static struct mips_frame_info wait_for_completion_frame;
+static int mips_frame_info_initialized;
+static int __init get_frame_info(struct mips_frame_info *info, void *func)
+{
+	int i;
+	union mips_instruction *ip = (union mips_instruction *)func;
+	info->pc_offset = -1;
+	info->frame_offset = -1;
+	for (i = 0; i < 128; i++, ip++) {
+		/* if jal, jalr, jr, stop. */
+		if (ip->j_format.opcode == jal_op ||
+		    (ip->r_format.opcode == spec_op &&
+		     (ip->r_format.func == jalr_op ||
+		      ip->r_format.func == jr_op)))
+			break;
+		if (ip->i_format.opcode == sw_op &&
+		    ip->i_format.rs == 29) {
+			/* sw $ra, offset($sp) */
+			if (ip->i_format.rt == 31) {
+				if (info->pc_offset != -1)
+					break;
+				info->pc_offset =
+					ip->i_format.simmediate / sizeof(long);
+			}
+			/* sw $s8, offset($sp) */
+			if (ip->i_format.rt == 30) {
+				if (info->frame_offset != -1)
+					break;
+				info->frame_offset =
+					ip->i_format.simmediate / sizeof(long);
+			}
+		}
+	}
+	if (info->pc_offset == -1 || info->frame_offset == -1) {
+		printk("Can't analize prologue code at %p\n", func);
+		info->pc_offset = -1;
+		info->frame_offset = -1;
+		return -1;
+	}
+	return 0;
+}
+void __init frame_info_init(void)
+{
+	mips_frame_info_initialized =
+		!get_frame_info(&schedule_frame, schedule) &&
+		!get_frame_info(&schedule_timeout_frame, schedule_timeout) &&
+		!get_frame_info(&sleep_on_frame, sleep_on) &&
+		!get_frame_info(&sleep_on_timeout_frame, sleep_on_timeout) &&
+		!get_frame_info(&wait_for_completion_frame, wait_for_completion);
+}
+
 /* get_wchan - a maintenance nightmare^W^Wpain in the ass ...  */
 unsigned long get_wchan(struct task_struct *p)
 {
@@ -177,6 +235,8 @@
 	if (!p || p == current || p->state == TASK_RUNNING)
 		return 0;
 
+	if (!mips_frame_info_initialized)
+		return 0;
 	pc = thread_saved_pc(&p->thread);
 	if (pc < first_sched || pc >= last_sched) {
 		return pc;
@@ -190,29 +250,33 @@
 		goto schedule_timeout_caller;
 	if (pc >= (unsigned long)interruptible_sleep_on)
 		goto schedule_caller;
-	/* Fall through */
+	if (pc >= (unsigned long)wait_for_completion)
+		goto schedule_caller;
+	goto schedule_timeout_caller;
 
 schedule_caller:
-	pc = ((unsigned long *)p->thread.reg30)[13];
-
+	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
+	if (pc >= (unsigned long) sleep_on)
+		pc = ((unsigned long *)frame)[sleep_on_frame.pc_offset];
+	else
+		pc = ((unsigned long *)frame)[wait_for_completion_frame.pc_offset];
 	return pc;
 
 schedule_timeout_caller:
 	/*
 	 * The schedule_timeout frame
 	 */
-	frame = ((unsigned long *)p->thread.reg30)[13];
+	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
 
 	/*
 	 * frame now points to sleep_on_timeout's frame
 	 */
-	frame = ((unsigned long *)frame)[9];
-	pc    = ((unsigned long *)frame)[10];
+	pc    = ((unsigned long *)frame)[schedule_timeout_frame.pc_offset];
 
 	if (pc >= first_sched && pc < last_sched) {
-		/* schedule_timeout called by interruptible_sleep_on_timeout */
-		frame = ((unsigned long *)frame)[9];
-		pc    = ((unsigned long *)frame)[10];
+		/* schedule_timeout called by [interruptible_]sleep_on_timeout */
+		frame = ((unsigned long *)frame)[schedule_timeout_frame.frame_offset];
+		pc    = ((unsigned long *)frame)[sleep_on_timeout_frame.pc_offset];
 	}
 
 	return pc;
diff -ur linux-mips-cvs/arch/mips/kernel/setup.c linux.new/arch/mips/kernel/setup.c
--- linux-mips-cvs/arch/mips/kernel/setup.c	Thu Apr 17 23:54:17 2003
+++ linux.new/arch/mips/kernel/setup.c	Fri May  2 21:47:29 2003
@@ -494,7 +494,9 @@
 	void swarm_setup(void);
 	void hp_setup(void);
 	void au1x00_setup(void);
+	void frame_info_init(void);
 
+	frame_info_init();
 #ifdef CONFIG_BLK_DEV_FD
 	fd_ops = &no_fd_ops;
 #endif
diff -ur linux-mips-cvs/arch/mips64/kernel/process.c linux.new/arch/mips64/kernel/process.c
--- linux-mips-cvs/arch/mips64/kernel/process.c	Sun Feb 23 18:55:39 2003
+++ linux.new/arch/mips64/kernel/process.c	Fri May  2 22:07:20 2003
@@ -19,6 +19,8 @@
 #include <linux/sys.h>
 #include <linux/user.h>
 #include <linux/a.out.h>
+#include <linux/init.h>
+#include <linux/completion.h>
 
 #include <asm/bootinfo.h>
 #include <asm/pgtable.h>
@@ -31,6 +33,7 @@
 #include <asm/elf.h>
 #include <asm/cpu.h>
 #include <asm/fpu.h>
+#include <asm/inst.h>
 
 ATTRIB_NORET void cpu_idle(void)
 {
@@ -162,6 +165,61 @@
 #define first_sched	((unsigned long) scheduling_functions_start_here)
 #define last_sched	((unsigned long) scheduling_functions_end_here)
 
+struct mips_frame_info schedule_frame;
+static struct mips_frame_info schedule_timeout_frame;
+static struct mips_frame_info sleep_on_frame;
+static struct mips_frame_info sleep_on_timeout_frame;
+static struct mips_frame_info wait_for_completion_frame;
+static int mips_frame_info_initialized;
+static int __init get_frame_info(struct mips_frame_info *info, void *func)
+{
+	int i;
+	union mips_instruction *ip = (union mips_instruction *)func;
+	info->pc_offset = -1;
+	info->frame_offset = -1;
+	for (i = 0; i < 128; i++, ip++) {
+		/* if jal, jalr, jr, stop. */
+		if (ip->j_format.opcode == jal_op ||
+		    (ip->r_format.opcode == spec_op &&
+		     (ip->r_format.func == jalr_op ||
+		      ip->r_format.func == jr_op)))
+			break;
+		if (ip->i_format.opcode == sd_op &&
+		    ip->i_format.rs == 29) {
+			/* sd $ra, offset($sp) */
+			if (ip->i_format.rt == 31) {
+				if (info->pc_offset != -1)
+					break;
+				info->pc_offset =
+					ip->i_format.simmediate / sizeof(long);
+			}
+			/* sd $s8, offset($sp) */
+			if (ip->i_format.rt == 30) {
+				if (info->frame_offset != -1)
+					break;
+				info->frame_offset =
+					ip->i_format.simmediate / sizeof(long);
+			}
+		}
+	}
+	if (info->pc_offset == -1 || info->frame_offset == -1) {
+		printk("Can't analize prologue code at %p\n", func);
+		info->pc_offset = -1;
+		info->frame_offset = -1;
+		return -1;
+	}
+	return 0;
+}
+void __init frame_info_init(void)
+{
+	mips_frame_info_initialized =
+		!get_frame_info(&schedule_frame, schedule) &&
+		!get_frame_info(&schedule_timeout_frame, schedule_timeout) &&
+		!get_frame_info(&sleep_on_frame, sleep_on) &&
+		!get_frame_info(&sleep_on_timeout_frame, sleep_on_timeout) &&
+		!get_frame_info(&wait_for_completion_frame, wait_for_completion);
+}
+
 /* get_wchan - a maintenance nightmare ...  */
 unsigned long get_wchan(struct task_struct *p)
 {
@@ -170,6 +228,8 @@
 	if (!p || p == current || p->state == TASK_RUNNING)
 		return 0;
 
+	if (!mips_frame_info_initialized)
+		return 0;
 	pc = thread_saved_pc(&p->thread);
 	if (pc < first_sched || pc >= last_sched)
 		goto out;
@@ -182,26 +242,29 @@
 		goto schedule_timeout_caller;
 	if (pc >= (unsigned long)interruptible_sleep_on)
 		goto schedule_caller;
+	if (pc >= (unsigned long)wait_for_completion)
+		goto schedule_caller;
 	goto schedule_timeout_caller;
 
 schedule_caller:
-	frame = ((unsigned long *)p->thread.reg30)[10];
-	pc    = ((unsigned long *)frame)[7];
+	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
+	if (pc >= (unsigned long) sleep_on)
+		pc = ((unsigned long *)frame)[sleep_on_frame.pc_offset];
+	else
+		pc = ((unsigned long *)frame)[wait_for_completion_frame.pc_offset];
 	goto out;
 
 schedule_timeout_caller:
 	/* Must be schedule_timeout ...  */
-	pc    = ((unsigned long *)p->thread.reg30)[11];
-	frame = ((unsigned long *)p->thread.reg30)[10];
+	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
 
 	/* The schedule_timeout frame ...  */
-	pc    = ((unsigned long *)frame)[9];
-	frame = ((unsigned long *)frame)[8];
+	pc    = ((unsigned long *)frame)[schedule_timeout_frame.pc_offset];
 
 	if (pc >= first_sched && pc < last_sched) {
-		/* schedule_timeout called by interruptible_sleep_on_timeout */
-		pc    = ((unsigned long *)frame)[7];
-		frame = ((unsigned long *)frame)[6];
+		/* schedule_timeout called by [interruptible_]sleep_on_timeout */
+		frame = ((unsigned long *)frame)[schedule_timeout_frame.frame_offset];
+		pc    = ((unsigned long *)frame)[sleep_on_timeout_frame.pc_offset];
 	}
 
 out:
diff -ur linux-mips-cvs/arch/mips64/kernel/setup.c linux.new/arch/mips64/kernel/setup.c
--- linux-mips-cvs/arch/mips64/kernel/setup.c	Wed Apr  9 22:06:57 2003
+++ linux.new/arch/mips64/kernel/setup.c	Fri May  2 22:06:40 2003
@@ -419,7 +419,9 @@
 	extern void ip32_setup(void);
 	extern void swarm_setup(void);
 	extern void malta_setup(void);
+	extern void frame_info_init(void);
 
+	frame_info_init();
 #ifdef CONFIG_DECSTATION
 	decstation_setup();
 #endif
diff -ur linux-mips-cvs/include/asm-mips/processor.h linux.new/include/asm-mips/processor.h
--- linux-mips-cvs/include/asm-mips/processor.h	Fri Apr 25 23:43:48 2003
+++ linux.new/include/asm-mips/processor.h	Fri May  2 21:47:02 2003
@@ -240,6 +240,11 @@
 #define copy_segments(p, mm) do { } while(0)
 #define release_segments(mm) do { } while(0)
 
+struct mips_frame_info {
+	int frame_offset;
+	int pc_offset;
+};
+extern struct mips_frame_info schedule_frame;
 /*
  * Return saved PC of a blocked thread.
  */
@@ -251,7 +256,9 @@
 	if (t->reg31 == (unsigned long) ret_from_fork)
 		return t->reg31;
 
-	return ((unsigned long *)t->reg29)[13];
+	if (schedule_frame.pc_offset < 0)
+		return 0;
+	return ((unsigned long *)t->reg29)[schedule_frame.pc_offset];
 }
 
 /*
diff -ur linux-mips-cvs/include/asm-mips64/processor.h linux.new/include/asm-mips64/processor.h
--- linux-mips-cvs/include/asm-mips64/processor.h	Fri Apr 25 23:43:49 2003
+++ linux.new/include/asm-mips64/processor.h	Fri May  2 21:47:09 2003
@@ -280,6 +280,11 @@
 #define copy_segments(p, mm) do { } while(0)
 #define release_segments(mm) do { } while(0)
 
+struct mips_frame_info {
+	int frame_offset;
+	int pc_offset;
+};
+extern struct mips_frame_info schedule_frame;
 /*
  * Return saved PC of a blocked thread.
  */
@@ -291,7 +296,9 @@
 	if (t->reg31 == (unsigned long) ret_from_sys_call)
 		return t->reg31;
 
-	return ((unsigned long*)t->reg29)[11];
+	if (schedule_frame.pc_offset < 0)
+		return 0;
+	return ((unsigned long *)t->reg29)[schedule_frame.pc_offset];
 }
 
 #define user_mode(regs)	(((regs)->cp0_status & ST0_KSU) == KSU_USER)
---
Atsushi Nemoto

From Geert.Uytterhoeven@sonycom.com Fri May  2 15:18:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 May 2003 15:18:55 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:40091 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225197AbTEBOSw>;
	Fri, 2 May 2003 15:18:52 +0100
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26])
	by mail.sonytel.be (8.9.0p/8.8.6) with ESMTP id QAA01361;
	Fri, 2 May 2003 16:18:41 +0200 (MET DST)
Date: Fri, 2 May 2003 16:18:42 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: initrd_header for mips64 kernel
In-Reply-To: <20030502.220517.74756988.anemo@mba.ocn.ne.jp>
Message-ID: <Pine.GSO.4.21.0305021617560.5468-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2256
X-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, 2 May 2003, Atsushi Nemoto wrote:
> I found that initrd_header in mips64 cvs kernel is broken.  The
> initrd_header should be consist of two 32bit words while 32bit
> addinitrd is used for 64bit kernel too.
> 
> diff -ur linux-mips-cvs/arch/mips64/kernel/setup.c linux.new/arch/mips64/kernel/setup.c
> --- linux-mips-cvs/arch/mips64/kernel/setup.c	Wed Apr  9 22:06:57 2003
> +++ linux.new/arch/mips64/kernel/setup.c	Fri May  2 21:47:36 2003
> @@ -245,7 +245,7 @@
>  {
>  #ifdef CONFIG_BLK_DEV_INITRD
>  	unsigned long tmp;
> -	unsigned long *initrd_header;
> +	unsigned int *initrd_header;

I think you better use u32 if it must be a 32-bit value.

>  #endif
>  	unsigned long bootmap_size;
>  	unsigned long start_pfn, max_pfn;
> @@ -255,7 +255,7 @@
>  	tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - 8;
>  	if (tmp < (unsigned long)&_end)
>  		tmp += PAGE_SIZE;
> -	initrd_header = (unsigned long *)tmp;
> +	initrd_header = (unsigned int *)tmp;
>  	if (initrd_header[0] == 0x494E5244) {
>  		initrd_start = (unsigned long)&initrd_header[2];
>  		initrd_end = initrd_start + initrd_header[1];

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 jzhang@elmic.com Sat May  3 01:05:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 May 2003 01:05:35 +0100 (BST)
Received: from 64-132-170-33.gen.twtelecom.net ([IPv6:::ffff:64.132.170.33]:30213
	"EHLO smtp.gcis.net") by linux-mips.org with ESMTP
	id <S8225212AbTECAFc>; Sat, 3 May 2003 01:05:32 +0100
Received: from winMe [12.99.240.208] by smtp.gcis.net with ESMTP
  (SMTPD32-7.07) id A7F22D9010E; Fri, 02 May 2003 20:06:10 -0400
Reply-To: <jzhang@elmic.com>
From: "Jimmy Zhang" <jzhang@elmic.com>
To: <linux-mips@linux-mips.org>
Subject: How to make part of kseg0 uncached
Date: Fri, 2 May 2003 16:56:44 -0700
Message-ID: <004f01c31106$7cb63de0$0300a8c0@riverside>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam.
Return-Path: <jzhang@elmic.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2257
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jzhang@elmic.com
Precedence: bulk
X-list: linux-mips

It is pretty simple to make the WHOLE kseg0 cached or uncached. However,
I only want part of kseg0 uncached. 

I must uncache that region because it gives me too much trouble with DMA
data, however, I don't want to uncache the whole kseg0 segment in order
to get better performance.  Kseg0 is not mapped through TLB, so it seems
I can't achieve my goal through TLB. 

Cite from the book See Mips Run, "if you feel that your system needs to
make uncached references to cacheable memory, then I strongly recommand
that you divide memory into regions that are always accessed uncached
and regions that are always accessed through the cache - and don't let
them overlap. " But how ?

Thanks,

Jimmy


From ralf@linux-mips.net Sat May  3 02:07:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 May 2003 02:07:16 +0100 (BST)
Received: from p508B5484.dip.t-dialin.net ([IPv6:::ffff:80.139.84.132]:31959
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225200AbTECBHN>; Sat, 3 May 2003 02:07:13 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h4316wv24644;
	Sat, 3 May 2003 03:06:58 +0200
Date: Sat, 3 May 2003 03:06:58 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jimmy Zhang <jzhang@elmic.com>
Cc: linux-mips@linux-mips.org
Subject: Re: How to make part of kseg0 uncached
Message-ID: <20030503030657.A1756@linux-mips.org>
References: <004f01c31106$7cb63de0$0300a8c0@riverside>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <004f01c31106$7cb63de0$0300a8c0@riverside>; from jzhang@elmic.com on Fri, May 02, 2003 at 04:56:44PM -0700
Return-Path: <ralf@linux-mips.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2258
X-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, May 02, 2003 at 04:56:44PM -0700, Jimmy Zhang wrote:

> It is pretty simple to make the WHOLE kseg0 cached or uncached. However,
> I only want part of kseg0 uncached. 
> 
> I must uncache that region because it gives me too much trouble with DMA
> data, however, I don't want to uncache the whole kseg0 segment in order
> to get better performance.  Kseg0 is not mapped through TLB, so it seems
> I can't achieve my goal through TLB. 
> 
> Cite from the book See Mips Run, "if you feel that your system needs to
> make uncached references to cacheable memory, then I strongly recommand
> that you divide memory into regions that are always accessed uncached
> and regions that are always accessed through the cache - and don't let
> them overlap. " But how ?

By not using KSEG0 for all your data.  As you figured the caching mode only
can only modifed for the entire KSEG0.  And because some part of your
code such as exception handlers will always run in KSEG0 you never want
to switch KSEG0 to uncached.  Easy solution, KSEG1 maps the same address
space as KSEG0 but is always uncached.  The usual warning applies, using
uncached memory is a bad idea in most cases.

  Ralf

From ralf@linux-mips.net Sat May  3 02:09:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 May 2003 02:09:56 +0100 (BST)
Received: from p508B5484.dip.t-dialin.net ([IPv6:::ffff:80.139.84.132]:35287
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225200AbTECBJy>; Sat, 3 May 2003 02:09:54 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h4319Ym24702;
	Sat, 3 May 2003 03:09:34 +0200
Date: Sat, 3 May 2003 03:09:34 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Keith Owens <kaos@sgi.com>
Cc: Michael Anburaj <michaelanburaj@hotmail.com>,
	linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
Message-ID: <20030503030934.B1756@linux-mips.org>
References: <BAY1-F28gEpTX5V3Gyk00001423@hotmail.com> <8921.1051849093@kao2.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <8921.1051849093@kao2.melbourne.sgi.com>; from kaos@sgi.com on Fri, May 02, 2003 at 02:18:13PM +1000
Return-Path: <ralf@linux-mips.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2259
X-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, May 02, 2003 at 02:18:13PM +1000, Keith Owens wrote:

> You have to specify ARCH=mips on _all_ make commands, not just make
> *config.  Do 'make ARCH=mips' for the second one.

In the MIPS kernel source I've hardwired ARCH=mips.  He'd either have
to pass something like CROSS_COMPILE=mips-linux- or set the config
option CONFIG_CROSSCOMPILE.

  Ralf

From michaelanburaj@hotmail.com Sat May  3 03:37:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 May 2003 03:37:12 +0100 (BST)
Received: from bay1-f164.bay1.hotmail.com ([IPv6:::ffff:65.54.245.164]:55824
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225213AbTECChJ>; Sat, 3 May 2003 03:37:09 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 2 May 2003 19:36:55 -0700
Received: from 207.13.167.2 by by1fd.bay1.hotmail.msn.com with HTTP;
	Sat, 03 May 2003 02:36:55 GMT
X-Originating-IP: [207.13.167.2]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: ralf@linux-mips.org, kaos@sgi.com
Cc: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
Date: Fri, 02 May 2003 19:36:55 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F164XsFFsAitVG00004184@hotmail.com>
X-OriginalArrivalTime: 03 May 2003 02:36:55.0773 (UTC) FILETIME=[DCCDB0D0:01C3111C]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2260
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi Ralph,

It will be great if you or any one from this forum enumerate all the build 
steps for building the Linux kernel (to work with Redboot or Flash image) 
for Atlas 4Kc board from scratch.

Development platform: Redhat Linux 9
Target Linux source: linux-mips’s CVS repository
Mips-linux tool-chain: rpm’s downloaded from link provided by linux-mips.com

I would be very much grateful for this help.

Thanks & Cheers,
-Mike.







>From: Ralf Baechle <ralf@linux-mips.org>
>To: Keith Owens <kaos@sgi.com>
>CC: Michael Anburaj <michaelanburaj@hotmail.com>,linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
>Date: Sat, 3 May 2003 03:09:34 +0200
>
>On Fri, May 02, 2003 at 02:18:13PM +1000, Keith Owens wrote:
>
> > You have to specify ARCH=mips on _all_ make commands, not just make
> > *config.  Do 'make ARCH=mips' for the second one.
>
>In the MIPS kernel source I've hardwired ARCH=mips.  He'd either have
>to pass something like CROSS_COMPILE=mips-linux- or set the config
>option CONFIG_CROSSCOMPILE.
>
>   Ralf
>


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


From michaelanburaj@hotmail.com Sat May  3 03:54:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 May 2003 03:54:18 +0100 (BST)
Received: from bay1-f85.bay1.hotmail.com ([IPv6:::ffff:65.54.245.85]:6928 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225213AbTECCyQ>;
	Sat, 3 May 2003 03:54:16 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 2 May 2003 19:54:07 -0700
Received: from 207.13.167.2 by by1fd.bay1.hotmail.msn.com with HTTP;
	Sat, 03 May 2003 02:54:07 GMT
X-Originating-IP: [207.13.167.2]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: ralf@linux-mips.org, kaos@sgi.com
Cc: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
Date: Fri, 02 May 2003 19:54:07 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F85pZpoMsDUISj00004247@hotmail.com>
X-OriginalArrivalTime: 03 May 2003 02:54:07.0775 (UTC) FILETIME=[43ECB2F0:01C3111F]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2261
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi Ralph,

More info.

For the most part it looks like its building. But source files of some of 
the drivers are failing. Like for instance NVRAM ( nvram.c ), some file 
system files & some video driver files.

A friend of mine said this. “Do menuconfig & select the appropriate board 
option (for me it is MIPS Atlas 4Kc). And you don’t have to worry about all 
the other options (like the file systems, & device drivers) – At least to 
get it to build initially”. Is that statement right? What he meant was, when 
you select a board the remaining things get customized automatically 
according to the board option. So, if I selected Atlas 4Kc board then only 
the drivers, file systems & other modules relevant to Atlas 4Kc would get 
enabled for the build to follow. Is that right?

If that’s true, then I shouldn’t face these many number of errors when 
building FS & device driver modules.

To work around this, each time I see an error, I do “$ make ARCH=mips 
menuconfig”, go find the option corresponding to the module & disable it. So 
that those files never get built & then the build progresses a bit before it 
break again. I am yet to complete this activity (probably today after work & 
this weekend I will do this). Do you think it’s best way to go about this?

Thanks & Cheers,
-Mike.







>From: Ralf Baechle <ralf@linux-mips.org>
>To: Keith Owens <kaos@sgi.com>
>CC: Michael Anburaj <michaelanburaj@hotmail.com>,linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
>Date: Sat, 3 May 2003 03:09:34 +0200
>
>On Fri, May 02, 2003 at 02:18:13PM +1000, Keith Owens wrote:
>
> > You have to specify ARCH=mips on _all_ make commands, not just make
> > *config.  Do 'make ARCH=mips' for the second one.
>
>In the MIPS kernel source I've hardwired ARCH=mips.  He'd either have
>to pass something like CROSS_COMPILE=mips-linux- or set the config
>option CONFIG_CROSSCOMPILE.
>
>   Ralf
>


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


From anemo@mba.ocn.ne.jp Sat May  3 06:07:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 May 2003 06:07:54 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:37846 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225202AbTECFHu>; Sat, 3 May 2003 06:07:50 +0100
Received: from localhost (p3166-ip01funabasi.chiba.ocn.ne.jp [61.112.99.166])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 17CDD4769; Sat,  3 May 2003 14:07:44 +0900 (JST)
Date: Sat, 03 May 2003 14:15:18 +0900 (JST)
Message-Id: <20030503.141518.74756767.anemo@mba.ocn.ne.jp>
To: geert@linux-m68k.org
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: initrd_header for mips64 kernel
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.GSO.4.21.0305021617560.5468-100000@vervain.sonytel.be>
References: <20030502.220517.74756988.anemo@mba.ocn.ne.jp>
	<Pine.GSO.4.21.0305021617560.5468-100000@vervain.sonytel.be>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2262
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Fri, 2 May 2003 16:18:42 +0200 (MEST), Geert Uytterhoeven <geert@linux-m68k.org> said:
geert> I think you better use u32 if it must be a 32-bit value.

Certainly.  Also it is better to use u32 in 32bit kernel too.

diff -ur linux-mips-cvs/arch/mips/kernel/setup.c linux.new/arch/mips/kernel/setup.c
--- linux-mips-cvs/arch/mips/kernel/setup.c	Thu Apr 17 23:54:17 2003
+++ linux.new/arch/mips/kernel/setup.c	Sat May  3 14:09:27 2003
@@ -246,17 +246,17 @@
 {
 #ifdef CONFIG_BLK_DEV_INITRD
 	unsigned long tmp;
-	unsigned long *initrd_header;
+	u32 *initrd_header;
 #endif
 	unsigned long bootmap_size;
 	unsigned long start_pfn, max_pfn, max_low_pfn, first_usable_pfn;
 	int i;
 
 #ifdef CONFIG_BLK_DEV_INITRD
-	tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - 8;
+	tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - sizeof(u32) * 2;
 	if (tmp < (unsigned long)&_end)
 		tmp += PAGE_SIZE;
-	initrd_header = (unsigned long *)tmp;
+	initrd_header = (u32 *)tmp;
 	if (initrd_header[0] == 0x494E5244) {
 		initrd_start = (unsigned long)&initrd_header[2];
 		initrd_end = initrd_start + initrd_header[1];
diff -ur linux-mips-cvs/arch/mips64/kernel/setup.c linux.new/arch/mips64/kernel/setup.c
--- linux-mips-cvs/arch/mips64/kernel/setup.c	Wed Apr  9 22:06:57 2003
+++ linux.new/arch/mips64/kernel/setup.c	Sat May  3 14:09:35 2003
@@ -245,17 +245,17 @@
 {
 #ifdef CONFIG_BLK_DEV_INITRD
 	unsigned long tmp;
-	unsigned long *initrd_header;
+	u32 *initrd_header;
 #endif
 	unsigned long bootmap_size;
 	unsigned long start_pfn, max_pfn;
 	int i;
 
 #ifdef CONFIG_BLK_DEV_INITRD
-	tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - 8;
+	tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - sizeof(u32) * 2;
 	if (tmp < (unsigned long)&_end)
 		tmp += PAGE_SIZE;
-	initrd_header = (unsigned long *)tmp;
+	initrd_header = (u32 *)tmp;
 	if (initrd_header[0] == 0x494E5244) {
 		initrd_start = (unsigned long)&initrd_header[2];
 		initrd_end = initrd_start + initrd_header[1];
---
Atsushi Nemoto

From michaelanburaj@hotmail.com Sat May  3 10:06:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 May 2003 10:06:10 +0100 (BST)
Received: from bay1-f89.bay1.hotmail.com ([IPv6:::ffff:65.54.245.89]:35595
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225202AbTECJGI>; Sat, 3 May 2003 10:06:08 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sat, 3 May 2003 02:05:58 -0700
Received: from 4.3.108.196 by by1fd.bay1.hotmail.msn.com with HTTP;
	Sat, 03 May 2003 09:05:58 GMT
X-Originating-IP: [4.3.108.196]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
Date: Sat, 03 May 2003 02:05:58 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F8903oHMwVN7mi000048ad@hotmail.com>
X-OriginalArrivalTime: 03 May 2003 09:05:58.0951 (UTC) FILETIME=[366BFB70:01C31153]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2263
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi all,

Finaly, I could compile vmlinux. I thought of booting this RAM image using 
the on board Redboot.

For which I needed a serial com utility ( like the windows Hyperterminal). I 
tried minicom & configured for /dev/ttyS1 & 115200 bauds & no hardware 
handshaking (PC has a COM1 port). Nothing seems to work. Can any one suggest 
a method to debug this issue? Or any other utility.

Thanks,
-Mike.


>From: "Michael Anburaj" <michaelanburaj@hotmail.com>
>To: ralf@linux-mips.org, kaos@sgi.com
>CC: linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
>Date: Fri, 02 May 2003 19:54:07 -0700
>
>Hi Ralph,
>
>More info.
>
>For the most part it looks like its building. But source files of some of 
>the drivers are failing. Like for instance NVRAM ( nvram.c ), some file 
>system files & some video driver files.
>
>A friend of mine said this. “Do menuconfig & select the appropriate board 
>option (for me it is MIPS Atlas 4Kc). And you don’t have to worry about all 
>the other options (like the file systems, & device drivers) – At least to 
>get it to build initially”. Is that statement right? What he meant was, 
>when you select a board the remaining things get customized automatically 
>according to the board option. So, if I selected Atlas 4Kc board then only 
>the drivers, file systems & other modules relevant to Atlas 4Kc would get 
>enabled for the build to follow. Is that right?
>
>If that’s true, then I shouldn’t face these many number of errors when 
>building FS & device driver modules.
>
>To work around this, each time I see an error, I do “$ make ARCH=mips 
>menuconfig”, go find the option corresponding to the module & disable it. 
>So that those files never get built & then the build progresses a bit 
>before it break again. I am yet to complete this activity (probably today 
>after work & this weekend I will do this). Do you think it’s best way to go 
>about this?
>
>Thanks & Cheers,
>-Mike.
>
>
>
>
>
>
>
>>From: Ralf Baechle <ralf@linux-mips.org>
>>To: Keith Owens <kaos@sgi.com>
>>CC: Michael Anburaj <michaelanburaj@hotmail.com>,linux-mips@linux-mips.org
>>Subject: Re: Linux for MIPS Atlas 4Kc board -problems :(
>>Date: Sat, 3 May 2003 03:09:34 +0200
>>
>>On Fri, May 02, 2003 at 02:18:13PM +1000, Keith Owens wrote:
>>
>> > You have to specify ARCH=mips on _all_ make commands, not just make
>> > *config.  Do 'make ARCH=mips' for the second one.
>>
>>In the MIPS kernel source I've hardwired ARCH=mips.  He'd either have
>>to pass something like CROSS_COMPILE=mips-linux- or set the config
>>option CONFIG_CROSSCOMPILE.
>>
>>   Ralf
>>
>
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 2 months FREE*  
>http://join.msn.com/?page=features/junkmail
>
>

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


From anemo@mba.ocn.ne.jp Sat May  3 13:57:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 May 2003 13:57:06 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:28881 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225202AbTECM5D>; Sat, 3 May 2003 13:57:03 +0100
Received: from localhost (p3166-ip01funabasi.chiba.ocn.ne.jp [61.112.99.166])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id D34AA40D5; Sat,  3 May 2003 21:56:56 +0900 (JST)
Date: Sat, 03 May 2003 22:04:31 +0900 (JST)
Message-Id: <20030503.220431.41626489.anemo@mba.ocn.ne.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Cc: nemoto@toshiba-tops.co.jp
Subject: Re: magic constants in thread_saved_pc and get_wchan
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030502.230446.25481355.anemo@mba.ocn.ne.jp>
References: <20030502.230446.25481355.anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2264
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Fri, 02 May 2003 23:04:46 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> There are some magic constants about stack layout in
anemo> thread_saved_pc() and get_wchan().  Also I think get_wchan()
anemo> for 32bit kernel is something wrong. (it is not easy to explain
anemo> HOW wrong...)

anemo> This patch (for 2.4 cvs) get rid of these magic constants by
anemo> analyzing kernel codes in runtime.

And this is (untested) 2.5 version of the patch.

diff -ur linux-mips-2.5-cvs/arch/mips/kernel/process.c linux-2.5.new/arch/mips/kernel/process.c
--- linux-mips-2.5-cvs/arch/mips/kernel/process.c	Fri Jan 10 04:16:50 2003
+++ linux-2.5.new/arch/mips/kernel/process.c	Sat May  3 21:51:51 2003
@@ -18,6 +18,8 @@
 #include <linux/sys.h>
 #include <linux/user.h>
 #include <linux/a.out.h>
+#include <linux/init.h>
+#include <linux/completion.h>
 
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
@@ -31,6 +33,7 @@
 #include <asm/io.h>
 #include <asm/elf.h>
 #include <asm/isadep.h>
+#include <asm/inst.h>
 
 /*
  * We use this if we don't have any better idle routine..
@@ -172,6 +175,65 @@
 	return retval;
 }
 
+struct mips_frame_info {
+	int frame_offset;
+	int pc_offset;
+};
+static struct mips_frame_info schedule_frame;
+static struct mips_frame_info schedule_timeout_frame;
+static struct mips_frame_info sleep_on_frame;
+static struct mips_frame_info sleep_on_timeout_frame;
+static struct mips_frame_info wait_for_completion_frame;
+static int mips_frame_info_initialized;
+static int __init get_frame_info(struct mips_frame_info *info, void *func)
+{
+	int i;
+	union mips_instruction *ip = (union mips_instruction *)func;
+	info->pc_offset = -1;
+	info->frame_offset = -1;
+	for (i = 0; i < 128; i++, ip++) {
+		/* if jal, jalr, jr, stop. */
+		if (ip->j_format.opcode == jal_op ||
+		    (ip->r_format.opcode == spec_op &&
+		     (ip->r_format.func == jalr_op ||
+		      ip->r_format.func == jr_op)))
+			break;
+		if (ip->i_format.opcode == sw_op &&
+		    ip->i_format.rs == 29) {
+			/* sw $ra, offset($sp) */
+			if (ip->i_format.rt == 31) {
+				if (info->pc_offset != -1)
+					break;
+				info->pc_offset =
+					ip->i_format.simmediate / sizeof(long);
+			}
+			/* sw $s8, offset($sp) */
+			if (ip->i_format.rt == 30) {
+				if (info->frame_offset != -1)
+					break;
+				info->frame_offset =
+					ip->i_format.simmediate / sizeof(long);
+			}
+		}
+	}
+	if (info->pc_offset == -1 || info->frame_offset == -1) {
+		printk("Can't analize prologue code at %p\n", func);
+		info->pc_offset = -1;
+		info->frame_offset = -1;
+		return -1;
+	}
+	return 0;
+}
+void __init frame_info_init(void)
+{
+	mips_frame_info_initialized =
+		!get_frame_info(&schedule_frame, schedule) &&
+		!get_frame_info(&schedule_timeout_frame, schedule_timeout) &&
+		!get_frame_info(&sleep_on_frame, sleep_on) &&
+		!get_frame_info(&sleep_on_timeout_frame, sleep_on_timeout) &&
+		!get_frame_info(&wait_for_completion_frame, wait_for_completion);
+}
+
 unsigned long thread_saved_pc(struct thread_struct *t)
 {
 	extern void ret_from_fork(void);
@@ -180,7 +242,9 @@
 	if (t->reg31 == (unsigned long) ret_from_fork)
 	return t->reg31;
 
-	return ((unsigned long *)t->reg29)[13];
+	if (schedule_frame.pc_offset < 0)
+		return 0;
+	return ((unsigned long *)t->reg29)[schedule_frame.pc_offset];
 }
 
 /*
@@ -199,6 +263,8 @@
 	if (!p || p == current || p->state == TASK_RUNNING)
 		return 0;
 
+	if (!mips_frame_info_initialized)
+		return 0;
 	pc = thread_saved_pc(&p->thread);
 	if (pc < first_sched || pc >= last_sched) {
 		return pc;
@@ -212,29 +278,33 @@
 		goto schedule_timeout_caller;
 	if (pc >= (unsigned long)interruptible_sleep_on)
 		goto schedule_caller;
-	/* Fall through */
+	if (pc >= (unsigned long)wait_for_completion)
+		goto schedule_caller;
+	goto schedule_timeout_caller;
 
 schedule_caller:
-	pc = ((unsigned long *)p->thread.reg30)[13];
-
+	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
+	if (pc >= (unsigned long) sleep_on)
+		pc = ((unsigned long *)frame)[sleep_on_frame.pc_offset];
+	else
+		pc = ((unsigned long *)frame)[wait_for_completion_frame.pc_offset];
 	return pc;
 
 schedule_timeout_caller:
 	/*
 	 * The schedule_timeout frame
 	 */
-	frame = ((unsigned long *)p->thread.reg30)[13];
+	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
 
 	/*
 	 * frame now points to sleep_on_timeout's frame
 	 */
-	frame = ((unsigned long *)frame)[9];
-	pc    = ((unsigned long *)frame)[10];
+	pc    = ((unsigned long *)frame)[schedule_timeout_frame.pc_offset];
 
 	if (pc >= first_sched && pc < last_sched) {
-		/* schedule_timeout called by interruptible_sleep_on_timeout */
-		frame = ((unsigned long *)frame)[9];
-		pc    = ((unsigned long *)frame)[10];
+		/* schedule_timeout called by [interruptible_]sleep_on_timeout */
+		frame = ((unsigned long *)frame)[schedule_timeout_frame.frame_offset];
+		pc    = ((unsigned long *)frame)[sleep_on_timeout_frame.pc_offset];
 	}
 
 	return pc;
diff -ur linux-mips-2.5-cvs/arch/mips/kernel/setup.c linux-2.5.new/arch/mips/kernel/setup.c
--- linux-mips-2.5-cvs/arch/mips/kernel/setup.c	Sat Apr 12 02:28:23 2003
+++ linux-2.5.new/arch/mips/kernel/setup.c	Sat May  3 21:25:54 2003
@@ -493,7 +493,9 @@
 	void au1000_setup(void);
 	void au1100_setup(void);
 	void au1500_setup(void);
+	void frame_info_init(void);
 
+	frame_info_init();
 #ifdef CONFIG_BLK_DEV_FD
 	fd_ops = &no_fd_ops;
 #endif
diff -ur linux-mips-2.5-cvs/arch/mips64/kernel/process.c linux-2.5.new/arch/mips64/kernel/process.c
--- linux-mips-2.5-cvs/arch/mips64/kernel/process.c	Fri Feb 21 04:47:25 2003
+++ linux-2.5.new/arch/mips64/kernel/process.c	Sat May  3 21:51:45 2003
@@ -19,6 +19,8 @@
 #include <linux/sys.h>
 #include <linux/user.h>
 #include <linux/a.out.h>
+#include <linux/init.h>
+#include <linux/completion.h>
 
 #include <asm/bootinfo.h>
 #include <asm/pgtable.h>
@@ -31,6 +33,7 @@
 #include <asm/elf.h>
 #include <asm/cpu.h>
 #include <asm/fpu.h>
+#include <asm/inst.h>
 
 /*
  * We use this if we don't have any better idle routine..
@@ -163,6 +166,65 @@
 	return retval;
 }
 
+struct mips_frame_info {
+	int frame_offset;
+	int pc_offset;
+};
+static struct mips_frame_info schedule_frame;
+static struct mips_frame_info schedule_timeout_frame;
+static struct mips_frame_info sleep_on_frame;
+static struct mips_frame_info sleep_on_timeout_frame;
+static struct mips_frame_info wait_for_completion_frame;
+static int mips_frame_info_initialized;
+static int __init get_frame_info(struct mips_frame_info *info, void *func)
+{
+	int i;
+	union mips_instruction *ip = (union mips_instruction *)func;
+	info->pc_offset = -1;
+	info->frame_offset = -1;
+	for (i = 0; i < 128; i++, ip++) {
+		/* if jal, jalr, jr, stop. */
+		if (ip->j_format.opcode == jal_op ||
+		    (ip->r_format.opcode == spec_op &&
+		     (ip->r_format.func == jalr_op ||
+		      ip->r_format.func == jr_op)))
+			break;
+		if (ip->i_format.opcode == sd_op &&
+		    ip->i_format.rs == 29) {
+			/* sd $ra, offset($sp) */
+			if (ip->i_format.rt == 31) {
+				if (info->pc_offset != -1)
+					break;
+				info->pc_offset =
+					ip->i_format.simmediate / sizeof(long);
+			}
+			/* sd $s8, offset($sp) */
+			if (ip->i_format.rt == 30) {
+				if (info->frame_offset != -1)
+					break;
+				info->frame_offset =
+					ip->i_format.simmediate / sizeof(long);
+			}
+		}
+	}
+	if (info->pc_offset == -1 || info->frame_offset == -1) {
+		printk("Can't analize prologue code at %p\n", func);
+		info->pc_offset = -1;
+		info->frame_offset = -1;
+		return -1;
+	}
+	return 0;
+}
+void __init frame_info_init(void)
+{
+	mips_frame_info_initialized =
+		!get_frame_info(&schedule_frame, schedule) &&
+		!get_frame_info(&schedule_timeout_frame, schedule_timeout) &&
+		!get_frame_info(&sleep_on_frame, sleep_on) &&
+		!get_frame_info(&sleep_on_timeout_frame, sleep_on_timeout) &&
+		!get_frame_info(&wait_for_completion_frame, wait_for_completion);
+}
+
 /*
  * Return saved PC of a blocked thread.
  */
@@ -174,7 +236,9 @@
 	if (t->reg31 == (unsigned long) ret_from_fork)
 		return t->reg31;
 
-	return ((unsigned long*)t->reg29)[11];
+	if (schedule_frame.pc_offset < 0)
+		return 0;
+	return ((unsigned long *)t->reg29)[schedule_frame.pc_offset];
 }
 
 /*
@@ -193,6 +257,8 @@
 	if (!p || p == current || p->state == TASK_RUNNING)
 		return 0;
 
+	if (!mips_frame_info_initialized)
+		return 0;
 	pc = thread_saved_pc(&p->thread);
 	if (pc < first_sched || pc >= last_sched)
 		goto out;
@@ -205,26 +271,29 @@
 		goto schedule_timeout_caller;
 	if (pc >= (unsigned long)interruptible_sleep_on)
 		goto schedule_caller;
+	if (pc >= (unsigned long)wait_for_completion)
+		goto schedule_caller;
 	goto schedule_timeout_caller;
 
 schedule_caller:
-	frame = ((unsigned long *)p->thread.reg30)[10];
-	pc    = ((unsigned long *)frame)[7];
+	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
+	if (pc >= (unsigned long) sleep_on)
+		pc = ((unsigned long *)frame)[sleep_on_frame.pc_offset];
+	else
+		pc = ((unsigned long *)frame)[wait_for_completion_frame.pc_offset];
 	goto out;
 
 schedule_timeout_caller:
 	/* Must be schedule_timeout ...  */
-	pc    = ((unsigned long *)p->thread.reg30)[11];
-	frame = ((unsigned long *)p->thread.reg30)[10];
+	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
 
 	/* The schedule_timeout frame ...  */
-	pc    = ((unsigned long *)frame)[9];
-	frame = ((unsigned long *)frame)[8];
+	pc    = ((unsigned long *)frame)[schedule_timeout_frame.pc_offset];
 
 	if (pc >= first_sched && pc < last_sched) {
-		/* schedule_timeout called by interruptible_sleep_on_timeout */
-		pc    = ((unsigned long *)frame)[7];
-		frame = ((unsigned long *)frame)[6];
+		/* schedule_timeout called by [interruptible_]sleep_on_timeout */
+		frame = ((unsigned long *)frame)[schedule_timeout_frame.frame_offset];
+		pc    = ((unsigned long *)frame)[sleep_on_timeout_frame.pc_offset];
 	}
 
 out:
diff -ur linux-mips-2.5-cvs/arch/mips64/kernel/setup.c linux-2.5.new/arch/mips64/kernel/setup.c
--- linux-mips-2.5-cvs/arch/mips64/kernel/setup.c	Wed Apr  9 09:46:47 2003
+++ linux-2.5.new/arch/mips64/kernel/setup.c	Sat May  3 21:25:59 2003
@@ -421,7 +421,9 @@
 	extern void ip32_setup(void);
 	extern void swarm_setup(void);
 	extern void malta_setup(void);
+	void frame_info_init(void);
 
+	frame_info_init();
 #ifdef CONFIG_DECSTATION
 	decstation_setup();
 #endif
---
Atsushi Nemoto

From michael_e_guo@hotmail.com Sun May  4 04:15:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 May 2003 04:15:56 +0100 (BST)
Received: from bay8-f55.bay8.hotmail.com ([IPv6:::ffff:64.4.27.55]:49937 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225255AbTEDDPv>;
	Sun, 4 May 2003 04:15:51 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sat, 3 May 2003 20:15:41 -0700
Received: from 211.150.235.16 by by8fd.bay8.hotmail.msn.com with HTTP;
	Sun, 04 May 2003 03:15:40 GMT
X-Originating-IP: [211.150.235.16]
X-Originating-Email: [michael_e_guo@hotmail.com]
From: "Guo Michael" <michael_e_guo@hotmail.com>
To: linux-mips@linux-mips.org
Subject: linux_2_4 on RM7000
Date: Sun, 04 May 2003 11:15:40 +0800
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: <BAY8-F55DEJmGzrLCCt00000427@hotmail.com>
X-OriginalArrivalTime: 04 May 2003 03:15:41.0245 (UTC) FILETIME=[714E4ED0:01C311EB]
Return-Path: <michael_e_guo@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-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2265
X-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_e_guo@hotmail.com
Precedence: bulk
X-list: linux-mips

Hello,
     I've been using the kernel from linux-mips.org on my board with RM7000 
CPU for several month with no problem. I checked out a new copy from 
linux-mips.org recently and found the cache code had been rewritten all 
over the place, and the new file sc-rm7k.c cannot even compile. After a 
quick check on that file according to the error messages it seems that 
nobody has even tried to compile this file.

My question is: does the new cache code work with rm7k cpu now? or in the 
future? 
anybody tried that on rm7k with success?

Thanks in advance

-Michael




_________________________________________________________________
Ãâ·ŅÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn  


From ralf@linux-mips.net Sun May  4 14:16:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 May 2003 14:16:34 +0100 (BST)
Received: from p508B64F1.dip.t-dialin.net ([IPv6:::ffff:80.139.100.241]:7041
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225211AbTEDNQb>; Sun, 4 May 2003 14:16:31 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h44DGNb08037;
	Sun, 4 May 2003 15:16:23 +0200
Date: Sun, 4 May 2003 15:16:22 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Guo Michael <michael_e_guo@hotmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: linux_2_4 on RM7000
Message-ID: <20030504151622.A3621@linux-mips.org>
References: <BAY8-F55DEJmGzrLCCt00000427@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <BAY8-F55DEJmGzrLCCt00000427@hotmail.com>; from michael_e_guo@hotmail.com on Sun, May 04, 2003 at 11:15:40AM +0800
Return-Path: <ralf@linux-mips.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2266
X-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, May 04, 2003 at 11:15:40AM +0800, Guo Michael wrote:

>      I've been using the kernel from linux-mips.org on my board with RM7000 
> CPU for several month with no problem. I checked out a new copy from 
> linux-mips.org recently and found the cache code had been rewritten all 
> over the place, and the new file sc-rm7k.c cannot even compile. After a 
> quick check on that file according to the error messages it seems that 
> nobody has even tried to compile this file.
> 
> My question is: does the new cache code work with rm7k cpu now? or in the 
> future?  anybody tried that on rm7k with success?

Somehow you're the only one to complain.  Details?

  Ralf

From michael_e_guo@hotmail.com Sun May  4 15:01:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 May 2003 15:01:29 +0100 (BST)
Received: from bay8-f66.bay8.hotmail.com ([IPv6:::ffff:64.4.27.66]:63751 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225211AbTEDOB1>;
	Sun, 4 May 2003 15:01:27 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 4 May 2003 07:01:16 -0700
Received: from 211.150.239.139 by by8fd.bay8.hotmail.msn.com with HTTP;
	Sun, 04 May 2003 14:01:16 GMT
X-Originating-IP: [211.150.239.139]
X-Originating-Email: [michael_e_guo@hotmail.com]
From: "Guo Michael" <michael_e_guo@hotmail.com>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: linux_2_4 on RM7000
Date: Sun, 04 May 2003 22:01:16 +0800
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: <BAY8-F66OgRGkQ6mByS0000fd73@hotmail.com>
X-OriginalArrivalTime: 04 May 2003 14:01:16.0851 (UTC) FILETIME=[A186B830:01C31245]
Return-Path: <michael_e_guo@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-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2267
X-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_e_guo@hotmail.com
Precedence: bulk
X-list: linux-mips

I've found the problem, I should define CONFIG_BOARD_SCACHE and 
CONFIG_RM7000_CPU_SCACHE first, right? But it still said scache_way_size is 
undefined in sc-rm7k.c and the printk on line 143 in rm7k_sc_probe need a 
little fix. After I fixed these it works.

Thanks.



>From: Ralf Baechle <ralf@linux-mips.org>
>To: Guo Michael <michael_e_guo@hotmail.com>
>CC: linux-mips@linux-mips.org
>Subject: Re: linux_2_4 on RM7000
>Date: Sun, 4 May 2003 15:16:22 +0200
>
>On Sun, May 04, 2003 at 11:15:40AM +0800, Guo Michael wrote:
>
> >      I've been using the kernel from linux-mips.org on my board with 
RM7000
> > CPU for several month with no problem. I checked out a new copy from
> > linux-mips.org recently and found the cache code had been rewritten all
> > over the place, and the new file sc-rm7k.c cannot even compile. After a
> > quick check on that file according to the error messages it seems that
> > nobody has even tried to compile this file.
> >
> > My question is: does the new cache code work with rm7k cpu now? or in 
the
> > future?  anybody tried that on rm7k with success?
>
>Somehow you're the only one to complain.  Details?
>
>   Ralf
>


_________________________________________________________________
Ãâ·ŅÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn  


From ralf@linux-mips.net Sun May  4 15:31:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 May 2003 15:31:26 +0100 (BST)
Received: from p508B64F1.dip.t-dialin.net ([IPv6:::ffff:80.139.100.241]:9858
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225211AbTEDObX>; Sun, 4 May 2003 15:31:23 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h44EVJY09750;
	Sun, 4 May 2003 16:31:19 +0200
Date: Sun, 4 May 2003 16:31:19 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Guo Michael <michael_e_guo@hotmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: linux_2_4 on RM7000
Message-ID: <20030504163119.A9719@linux-mips.org>
References: <BAY8-F66OgRGkQ6mByS0000fd73@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <BAY8-F66OgRGkQ6mByS0000fd73@hotmail.com>; from michael_e_guo@hotmail.com on Sun, May 04, 2003 at 10:01:16PM +0800
Return-Path: <ralf@linux-mips.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2268
X-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, May 04, 2003 at 10:01:16PM +0800, Guo Michael wrote:

> I've found the problem, I should define CONFIG_BOARD_SCACHE and 
> CONFIG_RM7000_CPU_SCACHE first, right? But it still said scache_way_size is 
> undefined in sc-rm7k.c and the printk on line 143 in rm7k_sc_probe need a 
> little fix. After I fixed these it works.

Oh - seems like I fixed that little problem without noticing in this
source tree.  Actually I tried to fix some R10000 silliness :-)

  Ralf

From michaelanburaj@hotmail.com Mon May  5 01:27:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 May 2003 01:27:37 +0100 (BST)
Received: from bay1-f6.bay1.hotmail.com ([IPv6:::ffff:65.54.245.6]:8456 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225206AbTEEA1f>;
	Mon, 5 May 2003 01:27:35 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 4 May 2003 17:27:26 -0700
Received: from 4.42.101.130 by by1fd.bay1.hotmail.msn.com with HTTP;
	Mon, 05 May 2003 00:27:25 GMT
X-Originating-IP: [4.42.101.130]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Sun, 04 May 2003 17:27:25 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F6t67zLTJTBUsl000074ca@hotmail.com>
X-OriginalArrivalTime: 05 May 2003 00:27:26.0232 (UTC) FILETIME=[1A9F5180:01C3129D]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2269
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,

Finally, I could compile vmlinux. I thought of booting this RAM image (or 
its SREC equivalent) using the onboard YAMON (in BIG endian mode - I am 
having trouble building Redboot in BIG endian mode <issue ported at ecos 
forum>, so for now thought of using YAMON). After downloding the 
vmlinux.srec over the serial port (Starting at 0x80100000), I issued the go 
command to run the image. I get the following message:

YAMON> go

LINUX started...

* Exception (user) : Reserved instruction *
BadVAddr = 0x00000000  Cause    = 0x00808028
Compare  = 0x00061a80  Config   = 0x80038083
Config1  = 0x1e9b4d8a  Context  = 0x63800000
Count    = 0xb9188fd8  DEPC     = 0x21424255
Debug    = 0x0400dc0b  EPC      = 0x80122258
EntryHi  = 0x00000068  EntryLo0 = 0x028ff72e
EntryLo1 = 0x035a241f  ErrorEPC = 0x8003add0
Index    = 0x0000000b  PRId     = 0x00018001
PageMask = 0x01b90000  Random   = 0x0000000d
Status   = 0x00000402  WatchHi  = 0x00000000
WatchLo  = 0x00000000  Wired    = 0x00000000
Hi       = 0x00000000  Lo       = 0x04000000

$ 0(zr):0x00000000  $ 8(t0):0x00000000  $16(s0):0x802d810a  
$24(t8):0xffffffff
$ 1(at):0x80280000  $ 9(t1):0x00000000  $17(s1):0x802d810c  
$25(t9):0x802c1e94
$ 2(v0):0x0000000a  $10(t2):0x8024f401  $18(s2):0x00000400  
$26(k0):0x00000000
$ 3(v1):0x00000000  $11(t3):0x00000000  $19(s3):0x00000001  
$27(k1):0x00000000
$ 4(a0):0x00000000  $12(t4):0x00000000  $20(s4):0x0000001a  
$28(gp):0x802c0000
$ 5(a1):0x80280000  $13(t5):0x00000000  $21(s5):0x0000000a  
$29(sp):0x802c1f58
$ 6(a2):0x8024385a  $14(t6):0x802d8109  $22(s6):0x0000003e  
$30(s8):0x800b1080
$ 7(a3):0x00000000  $15(t7):0xfffffffe  $23(s7):0x0000003c  
$31(ra):0x80122230


The linux image started fine, but caused an exception after a while. Is this 
because Linux is not compatible with YAMON? If so, what are the possible 
monitor programs that can go with Linux? Please point me to the documents in 
this regard (documents on running Linux executable on Atlas 4Kc board).

Or will Linux work with any ROM monitor? If so, please let me know the 
reason for the exception.

Thanks a lot,
-Mike.

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


From muthu@iqmail.net Mon May  5 03:42:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 May 2003 03:42:34 +0100 (BST)
Received: from vopmail.sfo.interquest.net ([IPv6:::ffff:66.135.128.69]:23558
	"EHLO micaiah.rwc.iqcicom.com") by linux-mips.org with ESMTP
	id <S8225206AbTEECmc>; Mon, 5 May 2003 03:42:32 +0100
Received: from Muruga.localdomain (unverified [66.135.134.124]) by micaiah.rwc.iqcicom.com
 (Vircom SMTPRS 2.0.244) with ESMTP id <B0006179507@micaiah.rwc.iqcicom.com>;
 Sun, 4 May 2003 19:42:26 -0700
Received: from localhost (muthu@localhost)
	by Muruga.localdomain (8.11.6/8.11.2) with ESMTP id h452Ln914777;
	Sun, 4 May 2003 19:21:49 -0700
Date: Sun, 4 May 2003 19:21:49 -0700 (PDT)
From: Muthukumar Ratty <muthu@iqmail.net>
To: Michael Anburaj <michaelanburaj@hotmail.com>
cc: <linux-mips@linux-mips.org>
Subject: Re: Linux for MIPS Atlas 4Kc board
In-Reply-To: <BAY1-F6t67zLTJTBUsl000074ca@hotmail.com>
Message-ID: <Pine.LNX.4.33.0305041914120.14758-100000@Muruga.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <muthu@iqmail.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2270
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: muthu@iqmail.net
Precedence: bulk
X-list: linux-mips


Hi Mike,

I dont know what version you are trying but the one at linux_2_4 branch
(linux2.4.21-pre4) seems to work. You can get it with

cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -r linux_2_4 linux

to configure, you can use the default config. from head do ..

cp arch/mips/default-atlas .config

I tried little endian. If you want that you need to select it in the
config.

Muthu


On Sun, 4 May 2003, Michael Anburaj wrote:

> Hi,
>
> Finally, I could compile vmlinux. I thought of booting this RAM image (or
> its SREC equivalent) using the onboard YAMON (in BIG endian mode - I am
> having trouble building Redboot in BIG endian mode <issue ported at ecos
> forum>, so for now thought of using YAMON). After downloding the
> vmlinux.srec over the serial port (Starting at 0x80100000), I issued the go
> command to run the image. I get the following message:
>
> YAMON> go
>
> LINUX started...
>
> * Exception (user) : Reserved instruction *
> BadVAddr = 0x00000000  Cause    = 0x00808028
> Compare  = 0x00061a80  Config   = 0x80038083
> Config1  = 0x1e9b4d8a  Context  = 0x63800000
> Count    = 0xb9188fd8  DEPC     = 0x21424255
> Debug    = 0x0400dc0b  EPC      = 0x80122258
> EntryHi  = 0x00000068  EntryLo0 = 0x028ff72e
> EntryLo1 = 0x035a241f  ErrorEPC = 0x8003add0
> Index    = 0x0000000b  PRId     = 0x00018001
> PageMask = 0x01b90000  Random   = 0x0000000d
> Status   = 0x00000402  WatchHi  = 0x00000000
> WatchLo  = 0x00000000  Wired    = 0x00000000
> Hi       = 0x00000000  Lo       = 0x04000000
>
> $ 0(zr):0x00000000  $ 8(t0):0x00000000  $16(s0):0x802d810a
> $24(t8):0xffffffff
> $ 1(at):0x80280000  $ 9(t1):0x00000000  $17(s1):0x802d810c
> $25(t9):0x802c1e94
> $ 2(v0):0x0000000a  $10(t2):0x8024f401  $18(s2):0x00000400
> $26(k0):0x00000000
> $ 3(v1):0x00000000  $11(t3):0x00000000  $19(s3):0x00000001
> $27(k1):0x00000000
> $ 4(a0):0x00000000  $12(t4):0x00000000  $20(s4):0x0000001a
> $28(gp):0x802c0000
> $ 5(a1):0x80280000  $13(t5):0x00000000  $21(s5):0x0000000a
> $29(sp):0x802c1f58
> $ 6(a2):0x8024385a  $14(t6):0x802d8109  $22(s6):0x0000003e
> $30(s8):0x800b1080
> $ 7(a3):0x00000000  $15(t7):0xfffffffe  $23(s7):0x0000003c
> $31(ra):0x80122230
>
>
> The linux image started fine, but caused an exception after a while. Is this
> because Linux is not compatible with YAMON? If so, what are the possible
> monitor programs that can go with Linux? Please point me to the documents in
> this regard (documents on running Linux executable on Atlas 4Kc board).
>
> Or will Linux work with any ROM monitor? If so, please let me know the
> reason for the exception.
>
> Thanks a lot,
> -Mike.
>
> _________________________________________________________________
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>


From michaelanburaj@hotmail.com Mon May  5 09:26:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 May 2003 09:26:45 +0100 (BST)
Received: from bay1-f36.bay1.hotmail.com ([IPv6:::ffff:65.54.245.36]:1806 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8224861AbTEEI0k>;
	Mon, 5 May 2003 09:26:40 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 5 May 2003 01:26:31 -0700
Received: from 4.42.101.130 by by1fd.bay1.hotmail.msn.com with HTTP;
	Mon, 05 May 2003 08:26:30 GMT
X-Originating-IP: [4.42.101.130]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Cc: muthu@iqmail.net
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Mon, 05 May 2003 01:26:30 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F36IZS2TRqf69a00007fcb@hotmail.com>
X-OriginalArrivalTime: 05 May 2003 08:26:31.0170 (UTC) FILETIME=[07F0C620:01C312E0]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2271
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,

Thanks a lot Muthu & all others who helped me.

I used the defconfig-atlas to configure my linux build & it works great on 
my board! <Probably I did not read the docs well, sorry> Thanks again, but I 
still have one more hurdle to jump over to kick start this excercise with 
linux.

Messages on my console (I used 'go' on YAMON prompt to start linux):
-------------------------------------------------------------------

Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00


Please advise me the simplest form of starting linux from YAMON prompt after 
downloading the image(srec) on to RAM.
Also please point me to a doc. that talks about the possible parameters when 
starting Linux.

Thanks everyone & Cheers,
-Mike.



>From: Muthukumar Ratty <muthu@iqmail.net>
>To: Michael Anburaj <michaelanburaj@hotmail.com>
>Subject: Re: Linux for MIPS Atlas 4Kc board
>Date: Sun, 4 May 2003 22:49:40 -0700 (PDT)
>
>On Sun, 4 May 2003, Michael Anburaj wrote:
>
> > Hi Muthu,
> >
> > So, I guess then I would have to do,
> >
> > make menuconfig & choose little endian after "cp arch/mips/default-atlas
> > .config".
>
>small typo, its defconfig-atlas :)
>
>Yes, if you want to run little-endian. But I would suggest you try the big
>endian first (since I guess you have tools for that already).
>
>
> >Am I right? If so, Do I need mipsel-linux??? Because, as I
>
>If you decide to go with little-endian then you need mipsel-linux-*. You
>can either get it from linux-mips or build your own.
>
> > understand mips-linux tool-chain if for big endian.
> >
> > Did you run the final image on top of YAMON?
> >
>
>Yes. I used YAMON to net load the image. But I guess it doesnt matter
>(redboot/yamon/any). Actually I tried RedBoot before for linux-2.4.3 and
>it worked like a champ.
>
>Muthu
>
>
> > Please help me out & thanks,
> > -Mike.
> >
> >
> >
> >
> >
> >
> > >From: Muthukumar Ratty <muthu@iqmail.net>
> > >To: Michael Anburaj <michaelanburaj@hotmail.com>
> > >CC: <linux-mips@linux-mips.org>
> > >Subject: Re: Linux for MIPS Atlas 4Kc board
> > >Date: Sun, 4 May 2003 19:21:49 -0700 (PDT)
> > >
> > >
> > >Hi Mike,
> > >
> > >I dont know what version you are trying but the one at linux_2_4 branch
> > >(linux2.4.21-pre4) seems to work. You can get it with
> > >
> > >cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -r linux_2_4 linux
> > >
> > >to configure, you can use the default config. from head do ..
> > >
> > >cp arch/mips/default-atlas .config
> > >
> > >I tried little endian. If you want that you need to select it in the
> > >config.
> > >
> > >Muthu
> > >
> > >
> > >On Sun, 4 May 2003, Michael Anburaj wrote:
> > >
> > > > Hi,
> > > >
> > > > Finally, I could compile vmlinux. I thought of booting this RAM 
>image
> > >(or
> > > > its SREC equivalent) using the onboard YAMON (in BIG endian mode - I 
>am
> > > > having trouble building Redboot in BIG endian mode <issue ported at 
>ecos
> > > > forum>, so for now thought of using YAMON). After downloding the
> > > > vmlinux.srec over the serial port (Starting at 0x80100000), I issued 
>the
> > >go
> > > > command to run the image. I get the following message:
> > > >
> > > > YAMON> go
> > > >
> > > > LINUX started...
> > > >
> > > > * Exception (user) : Reserved instruction *
> > > > BadVAddr = 0x00000000  Cause    = 0x00808028
> > > > Compare  = 0x00061a80  Config   = 0x80038083
> > > > Config1  = 0x1e9b4d8a  Context  = 0x63800000
> > > > Count    = 0xb9188fd8  DEPC     = 0x21424255
> > > > Debug    = 0x0400dc0b  EPC      = 0x80122258
> > > > EntryHi  = 0x00000068  EntryLo0 = 0x028ff72e
> > > > EntryLo1 = 0x035a241f  ErrorEPC = 0x8003add0
> > > > Index    = 0x0000000b  PRId     = 0x00018001
> > > > PageMask = 0x01b90000  Random   = 0x0000000d
> > > > Status   = 0x00000402  WatchHi  = 0x00000000
> > > > WatchLo  = 0x00000000  Wired    = 0x00000000
> > > > Hi       = 0x00000000  Lo       = 0x04000000
> > > >
> > > > $ 0(zr):0x00000000  $ 8(t0):0x00000000  $16(s0):0x802d810a
> > > > $24(t8):0xffffffff
> > > > $ 1(at):0x80280000  $ 9(t1):0x00000000  $17(s1):0x802d810c
> > > > $25(t9):0x802c1e94
> > > > $ 2(v0):0x0000000a  $10(t2):0x8024f401  $18(s2):0x00000400
> > > > $26(k0):0x00000000
> > > > $ 3(v1):0x00000000  $11(t3):0x00000000  $19(s3):0x00000001
> > > > $27(k1):0x00000000
> > > > $ 4(a0):0x00000000  $12(t4):0x00000000  $20(s4):0x0000001a
> > > > $28(gp):0x802c0000
> > > > $ 5(a1):0x80280000  $13(t5):0x00000000  $21(s5):0x0000000a
> > > > $29(sp):0x802c1f58
> > > > $ 6(a2):0x8024385a  $14(t6):0x802d8109  $22(s6):0x0000003e
> > > > $30(s8):0x800b1080
> > > > $ 7(a3):0x00000000  $15(t7):0xfffffffe  $23(s7):0x0000003c
> > > > $31(ra):0x80122230
> > > >
> > > >
> > > > The linux image started fine, but caused an exception after a while. 
>Is
> > >this
> > > > because Linux is not compatible with YAMON? If so, what are the 
>possible
> > > > monitor programs that can go with Linux? Please point me to the
> > >documents in
> > > > this regard (documents on running Linux executable on Atlas 4Kc 
>board).
> > > >
> > > > Or will Linux work with any ROM monitor? If so, please let me know 
>the
> > > > reason for the exception.
> > > >
> > > > Thanks a lot,
> > > > -Mike.
> > > >
> > > > _________________________________________________________________
> > > > STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> > > > http://join.msn.com/?page=features/junkmail
> > > >
> > > >
> > >
> >
> >
> > _________________________________________________________________
> > Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> > http://join.msn.com/?page=features/junkmail
> >
>


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


From geert@linux-m68k.org Mon May  5 10:48:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 May 2003 10:48:54 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:32681 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTEEJsq>;
	Mon, 5 May 2003 10:48:46 +0100
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27])
	by mail.sonytel.be (8.9.0p/8.8.6) with ESMTP id LAA19126;
	Mon, 5 May 2003 11:47:49 +0200 (MET DST)
Date: Mon, 5 May 2003 11:47:48 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Petko Manolov <petkan@users.sourceforge.net>,
	Greg Kroah-Hartman <greg@kroah.com>,
	Ralf Baechle <ralf@linux-mips.org>
cc: linux-usb-devel@lists.sourceforge.net,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	Dimitri Torfs <Dimitri.Torfs@sonycom.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Big endian RTL8150
Message-ID: <Pine.GSO.4.21.0305051135140.9126-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2272
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

	Hi,

The RTL8150 USB Ethernet driver doesn't work on big endian machines. Here are
patches (for both 2.4.x and 2.5.x) to fix that. The fix was tested on the
2.4.20 and 2.4.21-rc1 version of the driver on big endian MIPS.

Changes:
  - Fix endianness of rx_creg (from Dimitri Torfs <Dimitri.Torfs@sonycom.com>)
  - Kill unused last parameter of async_set_registers()

--- linux-2.4.21-rc1/drivers/usb/rtl8150.c.orig	Wed Jan 29 10:14:22 2003
+++ linux-2.4.21-rc1/rtl8150.c	Mon May  5 11:27:37 2003
@@ -155,7 +155,7 @@
 	clear_bit(RX_REG_SET, &dev->flags);
 }
 
-static int async_set_registers(rtl8150_t * dev, u16 indx, u16 size, void *data)
+static int async_set_registers(rtl8150_t * dev, u16 indx, u16 size)
 {
 	int ret;
 
@@ -426,7 +426,8 @@
 	if (rtl8150_reset(dev)) {
 		warn("%s - device reset failed", __FUNCTION__);
 	}
-	dev->rx_creg = rcr = 0x9e;	/* bit7=1 attach Rx info at the end */
+	rcr = 0x9e;	/* bit7=1 attach Rx info at the end */
+	dev->rx_creg = cpu_to_le16(rcr);
 	tcr = 0xd8;
 	cr = 0x0c;
 	set_registers(dev, RCR, 1, &rcr);
@@ -471,18 +472,18 @@
 	dev = netdev->priv;
 	netif_stop_queue(netdev);
 	if (netdev->flags & IFF_PROMISC) {
-		dev->rx_creg |= 0x0001;
+		dev->rx_creg |= cpu_to_le16(0x0001);
 		info("%s: promiscuous mode", netdev->name);
 	} else if ((netdev->mc_count > multicast_filter_limit) ||
 		   (netdev->flags & IFF_ALLMULTI)) {
-		dev->rx_creg &= 0xfffe;
-		dev->rx_creg |= 0x0002;
+		dev->rx_creg &= cpu_to_le16(0xfffe);
+		dev->rx_creg |= cpu_to_le16(0x0002);
 		info("%s: allmulti set", netdev->name);
 	} else {
 		/* ~RX_MULTICAST, ~RX_PROMISCUOUS */
-		dev->rx_creg &= 0x00fc;
+		dev->rx_creg &= cpu_to_le16(0x00fc);
 	}
-	async_set_registers(dev, RCR, 2, &dev->rx_creg);
+	async_set_registers(dev, RCR, 2);
 	netif_wake_queue(netdev);
 }
 
--- linux-2.5.69/drivers/usb/net/rtl8150.c.orig	Sun Apr 20 12:28:50 2003
+++ linux-2.5.69/drivers/usb/net/rtl8150.c	Mon May  5 11:32:05 2003
@@ -160,7 +160,7 @@
 	clear_bit(RX_REG_SET, &dev->flags);
 }
 
-static int async_set_registers(rtl8150_t * dev, u16 indx, u16 size, void *data)
+static int async_set_registers(rtl8150_t * dev, u16 indx, u16 size)
 {
 	int ret;
 
@@ -537,7 +537,8 @@
 		warn("%s - device reset failed", __FUNCTION__);
 	}
 	/* RCR bit7=1 attach Rx info at the end;  =0 HW CRC (which is broken) */
-	dev->rx_creg = rcr = 0x9e;
+	rcr = 0x9e;	/* bit7=1 attach Rx info at the end */
+	dev->rx_creg = cpu_to_le16(rcr);
 	tcr = 0xd8;
 	cr = 0x0c;
 	if (!(rcr & 0x80))
@@ -584,18 +585,18 @@
 	dev = netdev->priv;
 	netif_stop_queue(netdev);
 	if (netdev->flags & IFF_PROMISC) {
-		dev->rx_creg |= 0x0001;
+		dev->rx_creg |= cpu_to_le16(0x0001);
 		info("%s: promiscuous mode", netdev->name);
 	} else if ((netdev->mc_count > multicast_filter_limit) ||
 		   (netdev->flags & IFF_ALLMULTI)) {
-		dev->rx_creg &= 0xfffe;
-		dev->rx_creg |= 0x0002;
+		dev->rx_creg &= cpu_to_le16(0xfffe);
+		dev->rx_creg |= cpu_to_le16(0x0002);
 		info("%s: allmulti set", netdev->name);
 	} else {
 		/* ~RX_MULTICAST, ~RX_PROMISCUOUS */
-		dev->rx_creg &= 0x00fc;
+		dev->rx_creg &= cpu_to_le16(0x00fc);
 	}
-	async_set_registers(dev, RCR, 2, &dev->rx_creg);
+	async_set_registers(dev, RCR, 2);
 	netif_wake_queue(netdev);
 }
 

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 ashish.anand@inspiretech.com Mon May  5 12:14:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 May 2003 12:14:36 +0100 (BST)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:27520
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8225211AbTEELOe>; Mon, 5 May 2003 12:14:34 +0100
Received: from mail.inspiretech.com (mail.inspiretech.com [192.168.42.3])
	by smtp.inspirtek.com (8.12.5/8.12.5) with ESMTP id h45BUFSM004475
	for <linux-mips@linux-mips.org>; Mon, 5 May 2003 17:00:24 +0530
Message-Id: <200305051130.h45BUFSM004475@smtp.inspirtek.com>
Received: from WorldClient [192.168.42.3] by inspiretech.com [192.168.42.3]
	with SMTP (MDaemon.v3.5.7.R)
	for <linux-mips@linux-mips.org>; Mon, 05 May 2003 16:36:45 +0530
Date: Mon, 05 May 2003 16:36:43 +0530
From: "Ashish anand" <ashish.anand@inspiretech.com>
To: linux-mips@linux-mips.org
Subject: Dma data is a byte stream..?
X-Mailer: WorldClient Standard 3.5.0e
X-MDRemoteIP: 192.168.42.3
X-Return-Path: ashish.anand@inspiretech.com
X-MDaemon-Deliver-To: linux-mips@linux-mips.org
Return-Path: <ashish.anand@inspiretech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-archive-position: 2273
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish.anand@inspiretech.com
Precedence: bulk
X-list: linux-mips

Hello,

I have a question regarding endianness bit in PCI bridge dma windiw
setting register.
regardless of this endianness bit setting my n/w card or other pci card
works..it can
only be possible if bus master treats the dma data as byte stream.

now questions are..
1> then why there is provision of a endiannness bit in pci bridge ..though
still i haven't
gone through the every bit of my manual.

2> if dma data is byte stream , then why there would be a aligmenmt
constraints for 
receive or transmit buffers in system memory..

Best Regards,
Ashish Anand



From bruno.randolf@4g-systems.de Mon May  5 19:06:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 May 2003 19:06:19 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.177]:25024
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225211AbTEESGQ> convert rfc822-to-8bit; Mon, 5 May 2003 19:06:16 +0100
Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 19CkLt-0001HT-00; Mon, 05 May 2003 20:06:13 +0200
Received: from [213.39.199.64] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 19CkLs-0002VY-00; Mon, 05 May 2003 20:06:13 +0200
From: Bruno Randolf <bruno.randolf@4g-systems.de>
Organization: 4G Mobile Systeme
To: linux-mips@linux-mips.org
Subject: Re: insmod segfault
Date: Mon, 5 May 2003 20:06:11 +0200
User-Agent: KMail/1.5.1
References: <200304171329.37998.bruno.randolf@4g-systems.de>
In-Reply-To: <200304171329.37998.bruno.randolf@4g-systems.de>
MIME-Version: 1.0
Content-Description: clearsigned data
Content-Disposition: inline
Cc: Bill Gatliff <bgat@billgatliff.com>
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Message-Id: <200305052006.11484.bruno.randolf@4g-systems.de>
Return-Path: <bruno.randolf@4g-systems.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2274
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.de
Precedence: bulk
X-list: linux-mips

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

to answer my own question, for completeness sake and to save others from the 
same struggles i've been going thru: this is the oh so simple answer, i got 
from Bill Gatliff <bgat@billgatliff.com>

> Compiling modules with this:
>
> $ mips-linux-gcc -c -O2 -D__KERNEL__ -Wall -fomit-frame-pointer \
>   -fno-strict-aliasing -fno-common -finline-limit=5000 -G 0 -fno-pic \
>   -mno-abicalls -mcpu=r4600 -mips2 -mlong-calls -Wa,--trap -DMODULE  \
>   chardev.c
>
>fixed the problem.

yes, it does. aparently the important thing is the "-fno-common" flag.

i'd be intererrested in further explanations, if anyone cares... ;)

bruno

On Thursday 17 April 2003 13:29, you wrote:
> hello!
>
> i have problems with a kernel module: when i insmod it, i get a
> segmentation fault and "Unable to handle kernel paging request at virtual
> address 00000004" oops, so as far as i understand it, it seems like
> relocation does not occur properly.
>
> i can reproduce the problem with the attached simple test code. when i
> insmod only hello_module.o it works fine, but when i insmod the result of
> "ld" (mod.o) i get the error. so it seems the problem is with the linker.
> or am i using wrong compiler / linker flags or doing something stupid?
>
> i compile with "gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
> -fno-strict-aliasing -mno-abicalls -G 0 -fno-pic -mcpu=r4600 -mips2
> -Wa,--trap -pipe -mlong-calls -I/usr/src/linux/include -O3 -D__KERNEL__
> -DLINUX -DMESSAGES"
>
> and link with "ld -r -o mod.o hello_module.o b.o"
>
> versions:
> * au1500 CPU
> * kernel version 2.4.21-pre4 from cvs
> * gcc version 3.0.4 (also: gcc version 2.95.4)
> * GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux
> * insmod version 2.4.15
>
> objdump -x mod.o says:
>
> ---
>
> mod.o:     file format elf32-tradlittlemips
> mod.o
> architecture: mips:6000, flags 0x00000011:
> HAS_RELOC, HAS_SYMS
> start address 0x00000000
> private flags = 10001001: [abi=O32] [mips2] [not 32bitmode]
>
> Sections:
> Idx Name          Size      VMA               LMA               File off
> Algn 0 .reginfo      00000018  00000000  00000000  00000034  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA,
> LINK_ONCE_SAME_SIZE 1 .text         00000070  00000000  00000000  00000050
> 2**4
>                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>   2 .rodata       00000030  00000000  00000000  000000c0  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   3 .modinfo      0000001c  00000000  00000000  000000f0  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   4 .data         00000000  00000000  00000000  00000110  2**4
>                   CONTENTS, ALLOC, LOAD, DATA
>   5 .sbss         00000000  00000000  00000000  00000110  2**0
>                   ALLOC
>   6 .bss          00000000  00000000  00000000  00000110  2**4
>                   ALLOC
>   7 .comment      00000024  00000000  00000000  00000110  2**0
>                   CONTENTS, READONLY
>   8 .pdr          00000040  00000000  00000000  00000134  2**2
>                   CONTENTS, RELOC, READONLY
> SYMBOL TABLE:
> 00000000 l    d  .reginfo       00000000
> 00000000 l    d  .text  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  .rodata        00000000
> 00000000 l    d  .modinfo       00000000
> 00000000 l    d  .data  00000000
> 00000000 l    d  .sbss  00000000
> 00000000 l    d  .bss   00000000
> 00000000 l    d  .comment       00000000
> 00000000 l    d  .pdr   00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    d  *ABS*  00000000
> 00000000 l    df *ABS*  00000000 hello_module.c
> 00000000 l     O .modinfo       0000001b __module_kernel_version
> 00000000 l    df *ABS*  00000000 b.c
> 00000004 g     O .scommon       00000004 b
> 00000038 g     F .text  00000000 cleanup_module
> 00000000 g     F .text  00000000 init_module
> 00000000         *UND*  00000000 printk
> 00000004 g     O .scommon       00000004 glob_int
>
>
> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE              VALUE
> 00000008 R_MIPS_HI16       .rodata
> 0000000c R_MIPS_LO16       .rodata
> 00000010 R_MIPS_HI16       printk
> 00000014 R_MIPS_LO16       printk
> 00000028 R_MIPS_HI16       glob_int
> 0000002c R_MIPS_LO16       glob_int
> 00000040 R_MIPS_HI16       .rodata
> 00000044 R_MIPS_LO16       .rodata
> 00000048 R_MIPS_HI16       printk
> 0000004c R_MIPS_LO16       printk
>
>
> RELOCATION RECORDS FOR [.pdr]:
> OFFSET   TYPE              VALUE
> 00000000 R_MIPS_32         init_module
> 00000020 R_MIPS_32         cleanup_module
>
> ---
>
> thanks for any hints.
>
> btw: this issue is not related to the one i posted about before ("au1500mm
> problems") - which is resolved already and was caused by a wrong
> initialization of the dual PHY ethernet hardware.
>
> bruno

- --
4G Mobile Systeme GmbH
Sierichstrasse 149
22299 Hamburg
fon: +49 (0)40 / 48 40 33 28
fax: +49 (0)40 / 48 40 33 30
mail: bruno.randolf@4g-systems.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+tqgTfg2jtUL97G4RAhLKAJwIvTB023VeaoFJRB4EWdCUtgfeRQCbBSwF
HVAUiWvT8rOHi5dMgwlYopo=
=VkdJ
-----END PGP SIGNATURE-----


From greg@kroah.com Mon May  5 22:38:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 May 2003 22:38:54 +0100 (BST)
Received: from e33.co.us.ibm.com ([IPv6:::ffff:32.97.110.131]:37370 "EHLO
	e33.co.us.ibm.com") by linux-mips.org with ESMTP
	id <S8225211AbTEEViu>; Mon, 5 May 2003 22:38:50 +0100
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h45LcdXD290622;
	Mon, 5 May 2003 17:38:40 -0400
Received: from gateway.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
	by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h45LcTV3177168;
	Mon, 5 May 2003 15:38:31 -0600
Received: from dyn9-47-17-242.beaverton.ibm.com (dyn9-47-17-242.beaverton.ibm.com [9.47.17.242])
	by gateway.beaverton.ibm.com (8.11.6/8.11.6) with ESMTP id h45LZqh29608;
	Mon, 5 May 2003 14:35:52 -0700
Received: from greg by echidna.kroah.org with local (masqmail 0.2.19)
 id 19Cngp-0o0-00; Mon, 05 May 2003 14:40:03 -0700
Date: Mon, 5 May 2003 14:40:03 -0700
From: Greg KH <greg@kroah.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Petko Manolov <petkan@users.sourceforge.net>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-usb-devel@lists.sourceforge.net,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	Dimitri Torfs <Dimitri.Torfs@sonycom.com>
Subject: Re: Big endian RTL8150
Message-ID: <20030505214003.GB2941@kroah.com>
References: <Pine.GSO.4.21.0305051135140.9126-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0305051135140.9126-100000@vervain.sonytel.be>
User-Agent: Mutt/1.4.1i
Return-Path: <greg@kroah.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2275
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: greg@kroah.com
Precedence: bulk
X-list: linux-mips

On Mon, May 05, 2003 at 11:47:48AM +0200, Geert Uytterhoeven wrote:
> 	Hi,
> 
> The RTL8150 USB Ethernet driver doesn't work on big endian machines. Here are
> patches (for both 2.4.x and 2.5.x) to fix that. The fix was tested on the
> 2.4.20 and 2.4.21-rc1 version of the driver on big endian MIPS.

Thanks, I've applied this to my 2.4 and 2.5 trees and will forward them
on up the food chain.

greg k-h

From muthu@iqmail.net Mon May  5 23:12:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 May 2003 23:13:00 +0100 (BST)
Received: from vopmail.sfo.interquest.net ([IPv6:::ffff:66.135.128.69]:26382
	"EHLO micaiah.rwc.iqcicom.com") by linux-mips.org with ESMTP
	id <S8225211AbTEEWM6>; Mon, 5 May 2003 23:12:58 +0100
Received: from Muruga.localdomain (unverified [66.135.134.124]) by micaiah.rwc.iqcicom.com
 (Vircom SMTPRS 2.0.244) with ESMTP id <B0006204760@micaiah.rwc.iqcicom.com>;
 Mon, 5 May 2003 15:12:54 -0700
Received: from localhost (muthu@localhost)
	by Muruga.localdomain (8.11.6/8.11.2) with ESMTP id h45Lq7718514;
	Mon, 5 May 2003 14:52:07 -0700
Date: Mon, 5 May 2003 14:52:07 -0700 (PDT)
From: Muthukumar Ratty <muthu@iqmail.net>
To: Michael Anburaj <michaelanburaj@hotmail.com>
cc: <linux-mips@linux-mips.org>
Subject: Re: Linux for MIPS Atlas 4Kc board
In-Reply-To: <BAY1-F36IZS2TRqf69a00007fcb@hotmail.com>
Message-ID: <Pine.LNX.4.33.0305051444530.18383-100000@Muruga.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <muthu@iqmail.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2276
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: muthu@iqmail.net
Precedence: bulk
X-list: linux-mips


Hi Mike,
You need to set up the userland. I got it from the mips website
ftp://ftp.mips.com/pub/linux/mips/installation/redhat7.1/. There is a good
document on how to install it. You can install it on a hard disk or use an
NFS mounted system and set the bootvariable root=... properly.

For an NFS system I use

go . nfsroot=10.10.10.1:/shiva/export/linux/mipsel

Muthu.

PS: There are other distributions you can try too. Checkout linux-mips
website or google for it.



On Mon, 5 May 2003, Michael Anburaj wrote:

> Hi,
>
> Thanks a lot Muthu & all others who helped me.
>
> I used the defconfig-atlas to configure my linux build & it works great on
> my board! <Probably I did not read the docs well, sorry> Thanks again, but I
> still have one more hurdle to jump over to kick start this excercise with
> linux.
>
> Messages on my console (I used 'go' on YAMON prompt to start linux):
> -------------------------------------------------------------------
>
> Root-NFS: No NFS server available, giving up.
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "" or 02:00
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 02:00
>
>
> Please advise me the simplest form of starting linux from YAMON prompt after
> downloading the image(srec) on to RAM.
> Also please point me to a doc. that talks about the possible parameters when
> starting Linux.
>
> Thanks everyone & Cheers,
> -Mike.
>
>
>
> >From: Muthukumar Ratty <muthu@iqmail.net>
> >To: Michael Anburaj <michaelanburaj@hotmail.com>
> >Subject: Re: Linux for MIPS Atlas 4Kc board
> >Date: Sun, 4 May 2003 22:49:40 -0700 (PDT)
> >
> >On Sun, 4 May 2003, Michael Anburaj wrote:
> >
> > > Hi Muthu,
> > >
> > > So, I guess then I would have to do,
> > >
> > > make menuconfig & choose little endian after "cp arch/mips/default-atlas
> > > .config".
> >
> >small typo, its defconfig-atlas :)
> >
> >Yes, if you want to run little-endian. But I would suggest you try the big
> >endian first (since I guess you have tools for that already).
> >
> >
> > >Am I right? If so, Do I need mipsel-linux??? Because, as I
> >
> >If you decide to go with little-endian then you need mipsel-linux-*. You
> >can either get it from linux-mips or build your own.
> >
> > > understand mips-linux tool-chain if for big endian.
> > >
> > > Did you run the final image on top of YAMON?
> > >
> >
> >Yes. I used YAMON to net load the image. But I guess it doesnt matter
> >(redboot/yamon/any). Actually I tried RedBoot before for linux-2.4.3 and
> >it worked like a champ.
> >
> >Muthu
> >
> >
> > > Please help me out & thanks,
> > > -Mike.
> > >
> > >
> > >
> > >
> > >
> > >
> > > >From: Muthukumar Ratty <muthu@iqmail.net>
> > > >To: Michael Anburaj <michaelanburaj@hotmail.com>
> > > >CC: <linux-mips@linux-mips.org>
> > > >Subject: Re: Linux for MIPS Atlas 4Kc board
> > > >Date: Sun, 4 May 2003 19:21:49 -0700 (PDT)
> > > >
> > > >
> > > >Hi Mike,
> > > >
> > > >I dont know what version you are trying but the one at linux_2_4 branch
> > > >(linux2.4.21-pre4) seems to work. You can get it with
> > > >
> > > >cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -r linux_2_4 linux
> > > >
> > > >to configure, you can use the default config. from head do ..
> > > >
> > > >cp arch/mips/default-atlas .config
> > > >
> > > >I tried little endian. If you want that you need to select it in the
> > > >config.
> > > >
> > > >Muthu
> > > >
> > > >
> > > >On Sun, 4 May 2003, Michael Anburaj wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Finally, I could compile vmlinux. I thought of booting this RAM
> >image
> > > >(or
> > > > > its SREC equivalent) using the onboard YAMON (in BIG endian mode - I
> >am
> > > > > having trouble building Redboot in BIG endian mode <issue ported at
> >ecos
> > > > > forum>, so for now thought of using YAMON). After downloding the
> > > > > vmlinux.srec over the serial port (Starting at 0x80100000), I issued
> >the
> > > >go
> > > > > command to run the image. I get the following message:
> > > > >
> > > > > YAMON> go
> > > > >
> > > > > LINUX started...
> > > > >
> > > > > * Exception (user) : Reserved instruction *
> > > > > BadVAddr = 0x00000000  Cause    = 0x00808028
> > > > > Compare  = 0x00061a80  Config   = 0x80038083
> > > > > Config1  = 0x1e9b4d8a  Context  = 0x63800000
> > > > > Count    = 0xb9188fd8  DEPC     = 0x21424255
> > > > > Debug    = 0x0400dc0b  EPC      = 0x80122258
> > > > > EntryHi  = 0x00000068  EntryLo0 = 0x028ff72e
> > > > > EntryLo1 = 0x035a241f  ErrorEPC = 0x8003add0
> > > > > Index    = 0x0000000b  PRId     = 0x00018001
> > > > > PageMask = 0x01b90000  Random   = 0x0000000d
> > > > > Status   = 0x00000402  WatchHi  = 0x00000000
> > > > > WatchLo  = 0x00000000  Wired    = 0x00000000
> > > > > Hi       = 0x00000000  Lo       = 0x04000000
> > > > >
> > > > > $ 0(zr):0x00000000  $ 8(t0):0x00000000  $16(s0):0x802d810a
> > > > > $24(t8):0xffffffff
> > > > > $ 1(at):0x80280000  $ 9(t1):0x00000000  $17(s1):0x802d810c
> > > > > $25(t9):0x802c1e94
> > > > > $ 2(v0):0x0000000a  $10(t2):0x8024f401  $18(s2):0x00000400
> > > > > $26(k0):0x00000000
> > > > > $ 3(v1):0x00000000  $11(t3):0x00000000  $19(s3):0x00000001
> > > > > $27(k1):0x00000000
> > > > > $ 4(a0):0x00000000  $12(t4):0x00000000  $20(s4):0x0000001a
> > > > > $28(gp):0x802c0000
> > > > > $ 5(a1):0x80280000  $13(t5):0x00000000  $21(s5):0x0000000a
> > > > > $29(sp):0x802c1f58
> > > > > $ 6(a2):0x8024385a  $14(t6):0x802d8109  $22(s6):0x0000003e
> > > > > $30(s8):0x800b1080
> > > > > $ 7(a3):0x00000000  $15(t7):0xfffffffe  $23(s7):0x0000003c
> > > > > $31(ra):0x80122230
> > > > >
> > > > >
> > > > > The linux image started fine, but caused an exception after a while.
> >Is
> > > >this
> > > > > because Linux is not compatible with YAMON? If so, what are the
> >possible
> > > > > monitor programs that can go with Linux? Please point me to the
> > > >documents in
> > > > > this regard (documents on running Linux executable on Atlas 4Kc
> >board).
> > > > >
> > > > > Or will Linux work with any ROM monitor? If so, please let me know
> >the
> > > > > reason for the exception.
> > > > >
> > > > > Thanks a lot,
> > > > > -Mike.
> > > > >
> > > > > _________________________________________________________________
> > > > > STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> > > > > http://join.msn.com/?page=features/junkmail
> > > > >
> > > > >
> > > >
> > >
> > >
> > > _________________________________________________________________
> > > Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> > > http://join.msn.com/?page=features/junkmail
> > >
> >
>
>
> _________________________________________________________________
> Tired of spam? Get advanced junk mail protection with MSN 8.
> http://join.msn.com/?page=features/junkmail
>
>


From hjl@lucon.org Tue May  6 06:33:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 May 2003 06:33:23 +0100 (BST)
Received: from rwcrmhc51.attbi.com ([IPv6:::ffff:204.127.198.38]:671 "EHLO
	rwcrmhc51.attbi.com") by linux-mips.org with ESMTP
	id <S8225211AbTEFFdS>; Tue, 6 May 2003 06:33:18 +0100
Received: from lucon.org (12-234-88-5.client.attbi.com[12.234.88.5])
          by attbi.com (rwcrmhc51) with ESMTP
          id <2003050605330405100jdkuee>; Tue, 6 May 2003 05:33:04 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 62BE52C681; Mon,  5 May 2003 22:33:01 -0700 (PDT)
Date: Mon, 5 May 2003 22:33:01 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: linux-gcc@vger.kernel.org,
	GNU C Library <libc-alpha@sources.redhat.com>,
	gcc@gcc.gnu.org, Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ron Guilmette <rfg@monkeys.com>,
	"Polstra; John" <linux-binutils-in@polstra.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	Leonard Zubkoff <lnz@dandelion.com>,
	"Steven J. Hill" <sjhill@cotw.com>
Subject: The Linux binutils 2.14.90.0.1 is released
Message-ID: <20030505223301.A28436@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.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: 2277
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hjl@lucon.org
Precedence: bulk
X-list: linux-mips

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

The Linux/mips support is added. You have to use

# rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz

to build it. Or you can read mips/README in the source tree to apply
the mips patches and build it by hand.

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

Changes from binutils 2.13.90.0.20:

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

Changes from binutils 2.13.90.0.18:

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

Changes from binutils 2.13.90.0.16:

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

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

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

Changes from binutils 2.13.90.0.10:

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

Changes from binutils 2.13.90.0.4:

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

Changes from binutils 2.13.90.0.3:

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

Changes from binutils 2.13.90.0.2:

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

The file list:

1. binutils-2.14.90.0.1.tar.gz. Source code.
2. binutils-2.13.90.0.18-2.14.90.0.1.diff.gz. Patch against the
   previous beta source code.
3. binutils-2.14.90.0.1-1.i386.rpm. IA-32 binary RPM for RedHat 9.

There is no separate source rpm. You can do

# rpm -ta binutils-2.14.90.0.1.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
05/05/2003

From michael_e_guo@hotmail.com Tue May  6 07:55:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 May 2003 07:55:04 +0100 (BST)
Received: from bay8-f125.bay8.hotmail.com ([IPv6:::ffff:64.4.27.125]:40210
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225211AbTEFGzC>; Tue, 6 May 2003 07:55:02 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 5 May 2003 23:54:53 -0700
Received: from 159.226.39.179 by by8fd.bay8.hotmail.msn.com with HTTP;
	Tue, 06 May 2003 06:54:52 GMT
X-Originating-IP: [159.226.39.179]
X-Originating-Email: [michael_e_guo@hotmail.com]
From: "Guo Michael" <michael_e_guo@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Which compiler should I use to make mips64 kernel
Date: Tue, 06 May 2003 14:54:52 +0800
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: <BAY8-F125H3IhA1qfT700013d0f@hotmail.com>
X-OriginalArrivalTime: 06 May 2003 06:54:53.0129 (UTC) FILETIME=[65440B90:01C3139C]
Return-Path: <michael_e_guo@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: 2278
X-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_e_guo@hotmail.com
Precedence: bulk
X-list: linux-mips

Hello, I want to build mips64el kernel and downloaded the mips64el 
toolchain from ftp://ftp.ds2.pg.gda.pl/pub/macro/ (Maciej W. Rozycki's 
site) and I got following errors:
. scripts/mkversion > .tmpversion
mips64el-linux-gcc -D__KERNEL__ -I/home/michael/linux-working/linux/include 
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing 
-fno-common -fomit-frame-pointer -I 
/home/michael/linux-working/linux/include/asm/gcc -mabi=64 -G 0 
-mno-abicalls -fno-pic -Wa,--trap -pipe -mcpu=r4600 -mips3 -Wa,-32 
-Wa,-mgp64  -DUTS_MACHINE='"mips64"' -DKBUILD_BASENAME=version -c -o 
init/version.o init/version.c
make CFLAGS="-D__KERNEL__ -I/home/michael/linux-working/linux/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer -I /home/michael/linux-working/linux/include/asm/gcc 
-mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mcpu=r4600 -mips3 
-Wa,-32 -Wa,-mgp64 " -C  arch/mips/tools
make[1]: Entering directory 
`/home/michael/linux-working/linux/arch/mips/tools'
cmp -s offset.h 
/home/michael/linux-working/linux/include/asm-mips64/offset.h || (cp 
offset.h /home/michael/linux-working/linux/include/asm-mips64/offset.h.new 
&& mv /home/michael/linux-working/linux/include/asm-mips64/offset.h.new 
/home/michael/linux-working/linux/include/asm-mips64/offset.h)
make[1]: Leaving directory 
`/home/michael/linux-working/linux/arch/mips/tools'
make CFLAGS="-D__KERNEL__ -I/home/michael/linux-working/linux/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer -I /home/michael/linux-working/linux/include/asm/gcc 
-mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mcpu=r4600 -mips3 
-Wa,-32 -Wa,-mgp64 " -C  kernel
make[1]: Entering directory `/home/michael/linux-working/linux/kernel'
make all_targets
make[2]: Entering directory `/home/michael/linux-working/linux/kernel'
rm -f kernel.o
mips64el-linux-ld  -r -o kernel.o sched.o dma.o fork.o exec_domain.o 
panic.o printk.o module.o exit.o itimer.o info.o time.o softirq.o 
resource.o sysctl.o acct.o capability.o ptrace.o timer.o user.o signal.o 
sys.o kmod.o context.o ksyms.o
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
mips64el-linux-ld: Attempt to do relocateable link with 
elf32-tradlittlemips input and elf64-tradlittlemips output
mips64el-linux-ld: final link failed: File in wrong format
make[2]: *** [kernel.o] Error 1
make[2]: Leaving directory `/home/michael/linux-working/linux/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/home/michael/linux-working/linux/kernel'
make: *** [_dir_kernel] Error 2

Where should I get the right toolchain or how can I build one?


-Michael

_________________________________________________________________
ÓëÁŠŧúĩÄÅóÓŅ―øÐÐ―ŧÁũĢŽĮëĘđÓà MSN Messenger:  http://messenger.msn.com/cn  


From ralf@linux-mips.org Tue May  6 13:40:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 May 2003 13:40:42 +0100 (BST)
Received: from p508B791F.dip.t-dialin.net ([IPv6:::ffff:80.139.121.31]:45953
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225211AbTEFMkk>; Tue, 6 May 2003 13:40:40 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h46CeWts002638;
	Tue, 6 May 2003 14:40:33 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h46CeTTg002637;
	Tue, 6 May 2003 14:40:29 +0200
Date: Tue, 6 May 2003 14:40:29 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Guo Michael <michael_e_guo@hotmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Which compiler should I use to make mips64 kernel
Message-ID: <20030506124029.GA2180@linux-mips.org>
References: <BAY8-F125H3IhA1qfT700013d0f@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BAY8-F125H3IhA1qfT700013d0f@hotmail.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: 2279
X-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, May 06, 2003 at 02:54:52PM +0800, Guo Michael wrote:

> mips64el-linux-ld  -r -o kernel.o sched.o dma.o fork.o exec_domain.o 
> panic.o printk.o module.o exit.o itimer.o info.o time.o softirq.o 
> resource.o sysctl.o acct.o capability.o ptrace.o timer.o user.o signal.o 
> sys.o kmod.o context.o ksyms.o
> mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117

This is a known but not yet fixed problem that only seems to hit certain
kernel configurations; I believe it somehow tied to little endianess also.

  Ralf

From macro@ds2.pg.gda.pl Tue May  6 14:03:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 May 2003 14:03:49 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:42687 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225211AbTEFNDr>; Tue, 6 May 2003 14:03:47 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA07473;
	Tue, 6 May 2003 15:04:18 +0200 (MET DST)
Date: Tue, 6 May 2003 15:04:18 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Guo Michael <michael_e_guo@hotmail.com>
cc: linux-mips@linux-mips.org
Subject: Re: Which compiler should I use to make mips64 kernel
In-Reply-To: <BAY8-F125H3IhA1qfT700013d0f@hotmail.com>
Message-ID: <Pine.GSO.3.96.1030506144654.5097B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2280
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 6 May 2003, Guo Michael wrote:

> Hello, I want to build mips64el kernel and downloaded the mips64el 
> toolchain from ftp://ftp.ds2.pg.gda.pl/pub/macro/ (Maciej W. Rozycki's 
> site) and I got following errors:

 My 64-bit binutils package has `ld' that assumes output is to be 64-bit
ELF.  When fed with 32-bit ELF objects such as these created by `as -32'
(as invoked when building the kernel) it should convert them to 64-bit on
the fly, but it wasn't really ever tested and doesn't work.  There are two
immediate ways to deal with that: 

1. Add "-m elf32ltsmip" or "-m elf32btsmip" (depending on the endianness) 
to `ld' invocation (there is a commented-out example how to do this in
arch/mips64/Makefile).  This is probably the simplest and safest way to
deal with the problem.  It could probably be added to the CVS to avoid
confusion. 

2. Build all objects as 64-bit.  This will enlarge the kernel noticeably
and possibly reveal bugs.  I have a patch (or maybe a hack) to enable such
a setup if you were really interested. 

  Maciej

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


From hjl@lucon.org Tue May  6 16:41:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 May 2003 16:41:33 +0100 (BST)
Received: from rwcrmhc51.attbi.com ([IPv6:::ffff:204.127.198.38]:30372 "EHLO
	rwcrmhc51.attbi.com") by linux-mips.org with ESMTP
	id <S8225211AbTEFPlb>; Tue, 6 May 2003 16:41:31 +0100
Received: from lucon.org (12-234-88-5.client.attbi.com[12.234.88.5])
          by attbi.com (rwcrmhc51) with ESMTP
          id <2003050615412105100jgcgfe>; Tue, 6 May 2003 15:41:21 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id A5A6F2C681; Tue,  6 May 2003 08:41:19 -0700 (PDT)
Date: Tue, 6 May 2003 08:41:19 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: Andreas Jaeger <aj@suse.de>
Cc: binutils@sources.redhat.com, gcc@gcc.gnu.org,
	GNU C Library <libc-alpha@sources.redhat.com>,
	Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ron Guilmette <rfg@monkeys.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	Leonard Zubkoff <lnz@dandelion.com>,
	"Steven J. Hill" <sjhill@cotw.com>, linux-gcc@vger.kernel.org
Subject: PATCH: Don't use empy files in ld-elfvers
Message-ID: <20030506084119.A4370@lucon.org>
References: <20030505223301.A28436@lucon.org> <hod6iwy26e.fsf@byrd.suse.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="WhfpMioaduB5tiZL"
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <hod6iwy26e.fsf@byrd.suse.de>; from aj@suse.de on Tue, May 06, 2003 at 09:17:13AM +0200
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: 2281
X-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


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

On Tue, May 06, 2003 at 09:17:13AM +0200, Andreas Jaeger wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
>=20
> > This is the beta release of binutils 2.14.90.0.1 for Linux, which is
> > based on binutils 2003 0505 in CVS on sourecs.redhat.com plus various
> > changes. It is purely for Linux.
> >
> > The Linux/mips support is added. You have to use
> >
> > # rpm --target=3D[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz
> >
> > to build it. Or you can read mips/README in the source tree to apply
> > the mips patches and build it by hand.
> >
> > Please report any bugs related to binutils 2.14.90.0.1 to hjl@lucon.org.
>=20
> HJ,
>=20
> the package is broken, the testsuite fails since the following
> (empty!) files from the ld/testsuite are not part of the tarball:
>=20
>=20
> ./testsuite/ld-elfvers/vers25b.c
> ./testsuite/ld-elfvers/vers25b.dsym
> ./testsuite/ld-elfvers/vers25b.ver
> ./testsuite/ld-elfvers/vers26b.dsym
> ./testsuite/ld-elfvers/vers26b.ver
> ./testsuite/ld-elfvers/vers27b.dsym
> ./testsuite/ld-elfvers/vers27b.ver
> ./testsuite/ld-elfvers/vers27c.c
> ./testsuite/ld-elfvers/vers27c.dsym
> ./testsuite/ld-elfvers/vers27c.ver
>=20

It is not such a good idea to use empty files in CVS. I will check in
this patch. Please apply binutils-2.14.90.0.1-empty-test.patch to the
Linux binutils 2.14.90.0.1.


H.J.

--WhfpMioaduB5tiZL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="binutils-2.14.90.0.1-empty-test.patch"
Content-Transfer-Encoding: quoted-printable

2003-05-06  H.J. Lu <hjl@gnu.org>

	* ld-elfvers/vers.exp (objdump_versionstuff): Support comment
	in expected version file.

	* ld-elfvers/vers25b.c: Add a line of comment.
	* ld-elfvers/vers25b.dsym: Likwise.
	* ld-elfvers/vers25b.ver: Likwise.
	* ld-elfvers/vers26b.dsym: Likwise.
	* ld-elfvers/vers26b.ver: Likwise.
	* ld-elfvers/vers27b.dsym: Likwise.
	* ld-elfvers/vers27b.ver: Likwise.
	* ld-elfvers/vers27c.c: Likwise.
	* ld-elfvers/vers27c.dsym: Likwise.
	* ld-elfvers/vers27c.ver: Likwise.

--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers.exp.empty	2003-05-05 =
14:46:50.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers.exp	2003-05-06 08:32:=
18.000000000 -0700
@@ -457,7 +457,11 @@ proc objdump_versionstuff { objdump obje
=20
 	set f1 [open $tmpdir/objdump.out r]
 	set f2 [open $expectfile r]
-	gets $f2 l2
+	while { [gets $f2 l2] !=3D -1 } {
+	    if { ![regexp "^#.*$" $l2] } then {
+		break
+	    }
+	}=20
 	while { [gets $f1 l1] !=3D -1 } {
 	    if { [string match $l2 $l1] } then {
 		if { [gets $f2 l2] =3D=3D -1 } then {
--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers25b.c.empty	2003-05-06=
 08:32:18.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers25b.c	2003-05-06 08:32=
:18.000000000 -0700
@@ -0,0 +1 @@
+/* Empty file  */
--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers25b.dsym.empty	2003-05=
-06 08:32:18.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers25b.dsym	2003-05-06 08=
:32:18.000000000 -0700
@@ -0,0 +1 @@
+# Empty file.
--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers25b.ver.empty	2003-05-=
06 08:32:18.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers25b.ver	2003-05-06 08:=
32:18.000000000 -0700
@@ -0,0 +1 @@
+# Empty file
--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers26b.dsym.empty	2003-05=
-06 08:32:18.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers26b.dsym	2003-05-06 08=
:32:18.000000000 -0700
@@ -0,0 +1 @@
+# Empty file
--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers26b.ver.empty	2003-05-=
06 08:32:18.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers26b.ver	2003-05-06 08:=
32:18.000000000 -0700
@@ -0,0 +1 @@
+# Empty file
--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers27b.dsym.empty	2003-05=
-06 08:32:18.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers27b.dsym	2003-05-06 08=
:32:18.000000000 -0700
@@ -0,0 +1 @@
+# Empty file
--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers27b.ver.empty	2003-05-=
06 08:32:18.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers27b.ver	2003-05-06 08:=
32:18.000000000 -0700
@@ -0,0 +1 @@
+# Empty file
--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers27c.c.empty	2003-05-06=
 08:32:18.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers27c.c	2003-05-06 08:32=
:18.000000000 -0700
@@ -0,0 +1 @@
+/* Empty file  */
--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers27c.dsym.empty	2003-05=
-06 08:32:18.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers27c.dsym	2003-05-06 08=
:32:18.000000000 -0700
@@ -0,0 +1 @@
+# Empty file
--- binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers27c.ver.empty	2003-05-=
06 08:32:18.000000000 -0700
+++ binutils-2.14.90.0.1/ld/testsuite/ld-elfvers/vers27c.ver	2003-05-06 08:=
32:18.000000000 -0700
@@ -0,0 +1 @@
+# Empty file

--WhfpMioaduB5tiZL--

From petkan@users.sourceforge.net Wed May  7 06:30:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 May 2003 06:30:14 +0100 (BST)
Received: from [IPv6:::ffff:217.9.239.72] ([IPv6:::ffff:217.9.239.72]:13952
	"EHLO tequila.rakia.org") by linux-mips.org with ESMTP
	id <S8225072AbTEGFaM>; Wed, 7 May 2003 06:30:12 +0100
Received: from localhost ([127.0.0.1])
	by tequila.rakia.org with esmtp 
	(Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian))
	id 19DISq-0000l5-00; Wed, 07 May 2003 09:31:41 +0300
Date: Wed, 7 May 2003 09:31:40 +0300 (EEST)
From: Petko Manolov <petkan@users.sourceforge.net>
X-X-Sender: petkan@tequila.rakia.org
To: Greg KH <greg@kroah.com>
cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	"linux-usb-devel@lists.sourceforge.net" 
	<linux-usb-devel@lists.sourceforge.net>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	Dimitri Torfs <Dimitri.Torfs@sonycom.com>
Subject: Re: Big endian RTL8150
In-Reply-To: <20030505214003.GB2941@kroah.com>
Message-ID: <Pine.LNX.4.50.0305070926230.2916-100000@tequila.rakia.org>
References: <Pine.GSO.4.21.0305051135140.9126-100000@vervain.sonytel.be>
 <20030505214003.GB2941@kroah.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <petkan@users.sourceforge.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: 2282
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: petkan@users.sourceforge.net
Precedence: bulk
X-list: linux-mips



On Mon, 5 May 2003, Greg KH wrote:

> On Mon, May 05, 2003 at 11:47:48AM +0200, Geert Uytterhoeven wrote:
> > 	Hi,
> >
> > The RTL8150 USB Ethernet driver doesn't work on big endian machines. Here are
> > patches (for both 2.4.x and 2.5.x) to fix that. The fix was tested on the
> > 2.4.20 and 2.4.21-rc1 version of the driver on big endian MIPS.
>
> Thanks, I've applied this to my 2.4 and 2.5 trees and will forward them
> on up the food chain.

Those changes were living in my official RTL8150 cvs site for some time,
waiting for comments from big-endian machine users.  I guess this should
mean thumbs up. :)


		Petko

From ladis@linux-mips.org Wed May  7 21:32:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 May 2003 21:32:06 +0100 (BST)
Received: from p0329.as-l042.contactel.cz ([IPv6:::ffff:194.108.238.75]:516
	"EHLO kopretinka") by linux-mips.org with ESMTP id <S8225220AbTEGUcD>;
	Wed, 7 May 2003 21:32:03 +0100
Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian))
	id 19DVX2-0000B1-00; Wed, 07 May 2003 22:28:52 +0200
Date: Wed, 7 May 2003 22:28:51 +0200
To: linux-mips@linux-mips.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Subject: [PATCH] SGI Seeq cleanup
Message-ID: <20030507202851.GA668@kopretinka>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
From: Ladislav Michl <ladis@linux-mips.org>
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2283
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

read eaddr using NVRAM access fuctions and make various cleanups so driver
can be build as module


diff -Naur linux_2_4/drivers/net/Config.in linux_2_4-fucked/drivers/net/Config.in
--- linux_2_4/drivers/net/Config.in	Wed Apr 16 09:11:57 2003
+++ linux_2_4-fucked/drivers/net/Config.in	Wed May  7 19:55:30 2003
@@ -217,7 +217,7 @@
       dep_tristate '    D-Link DE620 pocket adapter support' CONFIG_DE620 $CONFIG_ISA
    fi
    if [ "$CONFIG_SGI_IP22" = "y" ]; then
-      bool '  SGI Seeq ethernet controller support' CONFIG_SGISEEQ
+      tristate '  SGI Seeq ethernet controller support' CONFIG_SGISEEQ
    fi
    if [ "$CONFIG_DECSTATION" = "y" ]; then
       tristate '  DEC LANCE ethernet controller support' CONFIG_DECLANCE
diff -Naur linux_2_4/drivers/net/Space.c linux_2_4-fucked/drivers/net/Space.c
--- linux_2_4/drivers/net/Space.c	Thu Aug  1 21:51:01 2002
+++ linux_2_4-fucked/drivers/net/Space.c	Wed May  7 19:55:30 2003
@@ -83,7 +83,6 @@
 extern int SK_init(struct net_device *);
 extern int seeq8005_probe(struct net_device *);
 extern int smc_init( struct net_device * );
-extern int sgiseeq_probe(struct net_device *);
 extern int atarilance_probe(struct net_device *);
 extern int sun3lance_probe(struct net_device *);
 extern int sun3_82586_probe(struct net_device *);
@@ -366,14 +365,6 @@
 	{NULL, 0},
 };
 
-
-static struct devprobe sgi_probes[] __initdata = {
-#ifdef CONFIG_SGISEEQ
-	{sgiseeq_probe, 0},
-#endif
-	{NULL, 0},
-};
-
 static struct devprobe mips_probes[] __initdata = {
 #ifdef CONFIG_MIPS_JAZZ_SONIC
 	{sonic_probe, 0},
@@ -407,8 +398,6 @@
 	if (probe_list(dev, m68k_probes) == 0)
 		return 0;
 	if (probe_list(dev, mips_probes) == 0)
-		return 0;
-	if (probe_list(dev, sgi_probes) == 0)
 		return 0;
 	if (probe_list(dev, eisa_probes) == 0)
 		return 0;
diff -Naur linux_2_4/drivers/net/sgiseeq.c linux_2_4-fucked/drivers/net/sgiseeq.c
--- linux_2_4/drivers/net/sgiseeq.c	Wed Mar 19 18:33:03 2003
+++ linux_2_4-fucked/drivers/net/sgiseeq.c	Wed May  7 19:55:30 2003
@@ -5,6 +5,7 @@
  */
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/init.h>
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/interrupt.h>
@@ -96,8 +97,8 @@
 struct sgiseeq_private {
 	volatile struct sgiseeq_init_block srings;
 	char *name;
-	volatile struct hpc3_ethregs *hregs;
-	volatile struct sgiseeq_regs *sregs;
+	struct hpc3_ethregs *hregs;
+	struct sgiseeq_regs *sregs;
 
 	/* Ring entry counters. */
 	unsigned int rx_new, tx_new;
@@ -108,17 +109,22 @@
 	unsigned char mode;
 
 	struct net_device_stats stats;
+
+	struct net_device *next_module;
 };
 
-static inline void hpc3_eth_reset(volatile struct hpc3_ethregs *hregs)
+/* A list of all installed seeq devices, for removing the driver module. */
+static struct net_device *root_sgiseeq_dev;
+
+static inline void hpc3_eth_reset(struct hpc3_ethregs *hregs)
 {
 	hregs->rx_reset = (HPC3_ERXRST_CRESET | HPC3_ERXRST_CLRIRQ);
 	udelay(20);
 	hregs->rx_reset = 0;
 }
 
-static inline void reset_hpc3_and_seeq(volatile struct hpc3_ethregs *hregs,
-				       volatile struct sgiseeq_regs *sregs)
+static inline void reset_hpc3_and_seeq(struct hpc3_ethregs *hregs,
+				       struct sgiseeq_regs *sregs)
 {
 	hregs->rx_ctrl = hregs->tx_ctrl = 0;
 	hpc3_eth_reset(hregs);
@@ -128,15 +134,15 @@
 		       SEEQ_RCMD_IDRIB | SEEQ_RCMD_ICRC)
 
 static inline void seeq_go(struct sgiseeq_private *sp,
-			   volatile struct hpc3_ethregs *hregs,
-			   volatile struct sgiseeq_regs *sregs)
+			   struct hpc3_ethregs *hregs,
+			   struct sgiseeq_regs *sregs)
 {
 	sregs->rstat = sp->mode | RSTAT_GO_BITS;
 	hregs->rx_ctrl = HPC3_ERXCTRL_ACTIVE;
 }
 
 static inline void seeq_load_eaddr(struct net_device *dev,
-				   volatile struct sgiseeq_regs *sregs)
+				   struct sgiseeq_regs *sregs)
 {
 	int i;
 
@@ -177,7 +183,6 @@
 				return -ENOMEM;
 			ib->tx_desc[i].buf_vaddr = KSEG1ADDR(buffer);
 			ib->tx_desc[i].tdma.pbuf = PHYSADDR(buffer);
-//			flush_cache_all();
 		}
 		ib->tx_desc[i].tdma.cntinfo = (TCNTINFO_INIT);
 	}
@@ -192,7 +197,6 @@
 				return -ENOMEM;
 			ib->rx_desc[i].buf_vaddr = KSEG1ADDR(buffer);
 			ib->rx_desc[i].rdma.pbuf = PHYSADDR(buffer);
-//			flush_cache_all();
 		}
 		ib->rx_desc[i].rdma.cntinfo = (RCNTINFO_INIT);
 	}
@@ -209,7 +213,7 @@
 	static int once;
 	struct sgiseeq_rx_desc *r = gpriv->srings.rx_desc;
 	struct sgiseeq_tx_desc *t = gpriv->srings.tx_desc;
-	volatile struct hpc3_ethregs *hregs = gpriv->hregs;
+	struct hpc3_ethregs *hregs = gpriv->hregs;
 	int i;
 
 	if(once)
@@ -248,9 +252,9 @@
 #define RDMACFG_INIT    (HPC3_ERXDCFG_FRXDC | HPC3_ERXDCFG_FEOP | HPC3_ERXDCFG_FIRQ)
 
 static int init_seeq(struct net_device *dev, struct sgiseeq_private *sp,
-		      volatile struct sgiseeq_regs *sregs)
+		     struct sgiseeq_regs *sregs)
 {
-	volatile struct hpc3_ethregs *hregs = sp->hregs;
+	struct hpc3_ethregs *hregs = sp->hregs;
 	int err;
 
 	reset_hpc3_and_seeq(hregs, sregs);
@@ -291,8 +295,8 @@
 }
 
 static inline void rx_maybe_restart(struct sgiseeq_private *sp,
-				    volatile struct hpc3_ethregs *hregs,
-				    volatile struct sgiseeq_regs *sregs)
+				    struct hpc3_ethregs *hregs,
+				    struct sgiseeq_regs *sregs)
 {
 	if (!(hregs->rx_ctrl & HPC3_ERXCTRL_ACTIVE)) {
 		hregs->rx_ndptr = PHYSADDR(&sp->srings.rx_desc[sp->rx_new]);
@@ -305,8 +309,8 @@
 				(rd) = &(sp)->srings.rx_desc[(sp)->rx_new])
 
 static inline void sgiseeq_rx(struct net_device *dev, struct sgiseeq_private *sp,
-			      volatile struct hpc3_ethregs *hregs,
-			      volatile struct sgiseeq_regs *sregs)
+			      struct hpc3_ethregs *hregs,
+			      struct sgiseeq_regs *sregs)
 {
 	struct sgiseeq_rx_desc *rd;
 	struct sk_buff *skb = 0;
@@ -338,7 +342,7 @@
 				sp->stats.rx_packets++;
 				sp->stats.rx_bytes += len;
 			} else {
-				printk ("%s: Memory squeeze, deferring packet.\n",
+				printk (KERN_NOTICE "%s: Memory squeeze, deferring packet.\n",
 					dev->name);
 				sp->stats.rx_dropped++;
 			}
@@ -356,7 +360,7 @@
 }
 
 static inline void tx_maybe_reset_collisions(struct sgiseeq_private *sp,
-					     volatile struct sgiseeq_regs *sregs)
+					     struct sgiseeq_regs *sregs)
 {
 	if (sp->is_edlc) {
 		sregs->rw.wregs.control = sp->control & ~(SEEQ_CTRL_XCNT);
@@ -365,7 +369,7 @@
 }
 
 static inline void kick_tx(struct sgiseeq_tx_desc *td,
-			   volatile struct hpc3_ethregs *hregs)
+			   struct hpc3_ethregs *hregs)
 {
 	/* If the HPC aint doin nothin, and there are more packets
 	 * with ETXD cleared and XIU set we must make very certain
@@ -383,8 +387,8 @@
 }
 
 static inline void sgiseeq_tx(struct net_device *dev, struct sgiseeq_private *sp,
-			      volatile struct hpc3_ethregs *hregs,
-			      volatile struct sgiseeq_regs *sregs)
+			      struct hpc3_ethregs *hregs,
+			      struct sgiseeq_regs *sregs)
 {
 	struct sgiseeq_tx_desc *td;
 	unsigned long status = hregs->tx_ctrl;
@@ -426,8 +430,8 @@
 {
 	struct net_device *dev = (struct net_device *) dev_id;
 	struct sgiseeq_private *sp = (struct sgiseeq_private *) dev->priv;
-	volatile struct hpc3_ethregs *hregs = sp->hregs;
-	volatile struct sgiseeq_regs *sregs = sp->sregs;
+	struct hpc3_ethregs *hregs = sp->hregs;
+	struct sgiseeq_regs *sregs = sp->sregs;
 
 	/* Ack the IRQ and set software state. */
 	hregs->rx_reset = HPC3_ERXRST_CLRIRQ;
@@ -435,7 +439,7 @@
 	/* Always check for received packets. */
 	sgiseeq_rx(dev, sp, hregs, sregs);
 
-	/* Only check for tx acks iff we have something queued. */
+	/* Only check for tx acks if we have something queued. */
 	if (sp->tx_old != sp->tx_new)
 		sgiseeq_tx(dev, sp, hregs, sregs);
 
@@ -447,47 +451,34 @@
 static int sgiseeq_open(struct net_device *dev)
 {
 	struct sgiseeq_private *sp = (struct sgiseeq_private *)dev->priv;
-	volatile struct sgiseeq_regs *sregs = sp->sregs;
-	unsigned long flags;
-	int err;
-
-	__save_and_cli(flags);
+	struct sgiseeq_regs *sregs = sp->sregs;
 
-	err = -EAGAIN;
-	if (request_irq(dev->irq, sgiseeq_interrupt, 0, sgiseeqstr, dev)) {
-		printk("Seeq8003: Can't get irq %d\n", dev->irq);
-		goto out;
-	}
-	err = init_seeq(dev, sp, sregs);
+	int err = init_seeq(dev, sp, sregs);
 	if (err)
-		goto out;
+		return err;
 
 	netif_start_queue(dev);
 
-out:
-	__restore_flags(flags);
-	return err;
+	return 0;
 }
 
 static int sgiseeq_close(struct net_device *dev)
 {
 	struct sgiseeq_private *sp = (struct sgiseeq_private *) dev->priv;
-	volatile struct sgiseeq_regs *sregs = sp->sregs;
+	struct sgiseeq_regs *sregs = sp->sregs;
 
 	netif_stop_queue(dev);
 
 	/* Shutdown the Seeq. */
 	reset_hpc3_and_seeq(sp->hregs, sregs);
 
-	free_irq(dev->irq, dev);
-
 	return 0;
 }
 
 static inline int sgiseeq_reset(struct net_device *dev)
 {
 	struct sgiseeq_private *sp = (struct sgiseeq_private *) dev->priv;
-	volatile struct sgiseeq_regs *sregs = sp->sregs;
+	struct sgiseeq_regs *sregs = sp->sregs;
 	int err;
 
 	err = init_seeq(dev, sp, sregs);
@@ -509,7 +500,7 @@
 static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct sgiseeq_private *sp = (struct sgiseeq_private *) dev->priv;
-	volatile struct hpc3_ethregs *hregs = sp->hregs;
+	struct hpc3_ethregs *hregs = sp->hregs;
 	unsigned long flags;
 	struct sgiseeq_tx_desc *td;
 	int skblen, len, entry;
@@ -565,7 +556,7 @@
 
 static void timeout(struct net_device *dev)
 {
-	printk("%s: transmit timed out, resetting\n", dev->name);
+	printk(KERN_NOTICE "%s: transmit timed out, resetting\n", dev->name);
 	sgiseeq_reset(dev);
 
 	dev->trans_start = jiffies;
@@ -608,41 +599,58 @@
 	buf[i].rdma.pnext = PHYSADDR(&buf[0]);
 }
 
-static char onboard_eth_addr[6];
-
 #define ALIGNED(x)  ((((unsigned long)(x)) + 0xf) & ~(0xf))
 
-int sgiseeq_init(struct net_device *dev, struct sgiseeq_regs *sregs,
-		 struct hpc3_ethregs *hregs, int irq)
+int sgiseeq_init(struct hpc3_regs* regs, int irq)
 {
-	static unsigned version_printed;
-	int i;
+	struct net_device *dev;
 	struct sgiseeq_private *sp;
-
-	dev->priv = (struct sgiseeq_private *) get_zeroed_page(GFP_KERNEL);
-	if (dev->priv == NULL)
+	int i;
+	
+	sp = (struct sgiseeq_private *) get_zeroed_page(GFP_KERNEL);
+	if (!sp) {
+		printk (KERN_ERR
+			"Seeq8003: Could not allocate private data.\n");
 		return -ENOMEM;
+	}
 
-	if (!version_printed++)
-		printk(version);
-
-	printk("%s: SGI Seeq8003 ", dev->name);
-
-	for (i = 0; i < 6; i++)
-		printk("%2.2x%c",
-		       dev->dev_addr[i] = onboard_eth_addr[i],
-		       i == 5 ? ' ': ':');
+	dev = init_etherdev(NULL, 0);
+	if (!dev) {
+		printk (KERN_ERR
+			"Seeq8003: Could not allocate memory for device.\n");
+		free_page((unsigned long) sp);
+		return -ENOMEM;
+	}
+	/* let unregister_netdev free memory for us */
+	dev->features |= NETIF_F_DYNALLOC;
 
+	if (request_irq(irq, sgiseeq_interrupt, 0, sgiseeqstr, dev)) {
+		printk(KERN_ERR "Seeq8003: Can't get irq %d\n", dev->irq);
+		free_page((unsigned long) sp);
+		unregister_netdev(dev);
+		return -EAGAIN;
+	}
+
+	printk(KERN_INFO "%s: SGI Seeq8003 ", dev->name);
+
+#define EADDR_NVOFS     250
+	for (i = 0; i < 3; i++) {
+		unsigned short tmp = ip22_nvram_read(EADDR_NVOFS / 2 + i);
+
+		printk("%2.2x:%2.2x%c",
+			dev->dev_addr[2 * i]     = tmp >> 8,
+			dev->dev_addr[2 * i + 1] = tmp & 0xff,
+			i == 2 ? ' ' : ':');
+	}
 	printk("\n");
 
-	sp = (struct sgiseeq_private *) dev->priv;
+	dev->priv = sp;
 #ifdef DEBUG
 	gpriv = sp;
 	gdev = dev;
 #endif
-	memset((char *)dev->priv, 0, sizeof(struct sgiseeq_private));
-	sp->sregs = sregs;
-	sp->hregs = hregs;
+	sp->sregs = (struct sgiseeq_regs *) &hpc3c0->eth_ext[0];
+	sp->hregs = &hpc3c0->ethregs;
 	sp->name = sgiseeqstr;
 
 	sp->srings.rx_desc = (struct sgiseeq_rx_desc *)
@@ -659,14 +667,13 @@
 	setup_tx_ring(sp->srings.tx_desc, SEEQ_TX_BUFFERS);
 
 	/* Reset the chip. */
-	hpc3_eth_reset((volatile struct hpc3_ethregs *) hregs);
+	hpc3_eth_reset(sp->hregs);
 
-	sp->is_edlc = !(sregs->rw.rregs.collision_tx[0] & 0xff);
-	if (sp->is_edlc) {
+	sp->is_edlc = !(sp->sregs->rw.rregs.collision_tx[0] & 0xff);
+	if (sp->is_edlc)
 		sp->control = (SEEQ_CTRL_XCNT | SEEQ_CTRL_ACCNT |
 			       SEEQ_CTRL_SFLAG | SEEQ_CTRL_ESHORT |
 			       SEEQ_CTRL_ENCARR);
-	}
 
 	dev->open                 = sgiseeq_open;
 	dev->stop                 = sgiseeq_close;
@@ -679,58 +686,36 @@
 	dev->dma                  = 0;
 	ether_setup(dev);
 
+	sp->next_module = root_sgiseeq_dev;
+	root_sgiseeq_dev = dev;
+
 	return 0;
 }
 
-static inline unsigned char str2hexnum(unsigned char c)
+static int __init sgiseeq_probe(void)
 {
-	if (c >= '0' && c <= '9')
-		return c - '0';
-	if (c >= 'a' && c <= 'f')
-		return c - 'a' + 10;
-	return 0; /* foo */
+	printk(version);
+
+	/* On board adapter on 1st HPC is always present */
+	return sgiseeq_init(hpc3c0, SGI_ENET_IRQ);
 }
 
-static inline void str2eaddr(unsigned char *ea, unsigned char *str)
+static void __exit sgiseeq_exit(void)
 {
-	int i;
-
-	for (i = 0; i < 6; i++) {
-		unsigned char num;
+	struct sgiseeq_private *sp;
+	struct net_device *next, *dev = root_sgiseeq_dev;
 
-		if(*str == ':')
-			str++;
-		num = str2hexnum(*str++) << 4;
-		num |= (str2hexnum(*str++));
-		ea[i] = num;
+	while (dev) {
+		sp = (struct sgiseeq_private *) dev->priv;
+		next = sp->next_module;
+		free_irq(dev->irq, dev);
+		free_page((unsigned long) sp);
+		unregister_netdev(dev);
+		dev = next;
 	}
 }
 
-int sgiseeq_probe(struct net_device *dev)
-{
-	static int initialized;
-	char *ep;
-
-	if (initialized)	/* Already initialized? */
-		return 1;
-	initialized++;
-
-	/* First get the ethernet address of the onboard interface from ARCS.
-	 * This is fragile; PROM doesn't like running from cache.
-	 * On MIPS64 it crashes for some other, yet unknown reason ...
-	 */
-	ep = ArcGetEnvironmentVariable("eaddr");
-	if (ep == NULL) {
-		/*
-		 * This one is likely to be caused by a broken NVRAM
-		 */
-		printk(KERN_CRIT "Seeq8003: Can't get MAC address!\n");
-		return -ENODEV;
-	}
-	str2eaddr(onboard_eth_addr, ep);
-	return sgiseeq_init(dev,
-			    (struct sgiseeq_regs *) (KSEG1ADDR(0x1fbd4000)),
-			    &hpc3c0->ethregs, SGI_ENET_IRQ);
-}
+module_init(sgiseeq_probe);
+module_exit(sgiseeq_exit);
 
 MODULE_LICENSE("GPL");

From ladis@linux-mips.org Wed May  7 21:32:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 May 2003 21:32:28 +0100 (BST)
Received: from p0329.as-l042.contactel.cz ([IPv6:::ffff:194.108.238.75]:772
	"EHLO kopretinka") by linux-mips.org with ESMTP id <S8225222AbTEGUcG>;
	Wed, 7 May 2003 21:32:06 +0100
Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian))
	id 19DVQr-0000AX-00; Wed, 07 May 2003 22:22:29 +0200
Date: Wed, 7 May 2003 22:22:29 +0200
To: linux-mips@linux-mips.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Subject: [PATCH] sc-ip22.c cleanup
Message-ID: <20030507202229.GA627@kopretinka>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
From: Ladislav Michl <ladis@linux-mips.org>
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2284
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

use serial eeprom access functions to detect scache size


diff -Naur linux_2_4/arch/mips/mm/sc-ip22.c linux_2_4-fucked/arch/mips/mm/sc-ip22.c
--- linux_2_4/arch/mips/mm/sc-ip22.c	Thu Apr 17 02:29:14 2003
+++ linux_2_4-fucked/arch/mips/mm/sc-ip22.c	Wed May  7 20:10:22 2003
@@ -14,9 +14,7 @@
 #include <asm/pgtable.h>
 #include <asm/system.h>
 #include <asm/bootinfo.h>
-#include <asm/mmu_context.h>
-#include <asm/sgialib.h>
-#include <asm/sgi/sgi.h>
+#include <asm/sgi/ip22.h>
 #include <asm/sgi/mc.h>
 
 /* Secondary cache size in bytes, if present.  */
@@ -149,60 +147,14 @@
 
 static inline int __init indy_sc_probe(void)
 {
-	volatile unsigned int *cpu_control;
-	unsigned short cmd = 0xc220;
-	unsigned long data = 0;
-	int i, n;
-
-#ifdef __MIPSEB__
-	cpu_control = (volatile unsigned int *) KSEG1ADDR(0x1fa00034);
-#else
-	cpu_control = (volatile unsigned int *) KSEG1ADDR(0x1fa00030);
-#endif
-#define DEASSERT(bit) (*(cpu_control) &= (~(bit)))
-#define ASSERT(bit) (*(cpu_control) |= (bit))
-#define DELAY  for(n = 0; n < 100000; n++) __asm__ __volatile__("")
-	DEASSERT(SGIMC_EEPROM_PRE);
-	DEASSERT(SGIMC_EEPROM_SDATAO);
-	DEASSERT(SGIMC_EEPROM_SECLOCK);
-	DEASSERT(SGIMC_EEPROM_PRE);
-	DELAY;
-	ASSERT(SGIMC_EEPROM_CSEL); ASSERT(SGIMC_EEPROM_SECLOCK);
-	for(i = 0; i < 11; i++) {
-		if(cmd & (1<<15))
-			ASSERT(SGIMC_EEPROM_SDATAO);
-		else
-			DEASSERT(SGIMC_EEPROM_SDATAO);
-		DEASSERT(SGIMC_EEPROM_SECLOCK);
-		ASSERT(SGIMC_EEPROM_SECLOCK);
-		cmd <<= 1;
-	}
-	DEASSERT(SGIMC_EEPROM_SDATAO);
-	for(i = 0; i < (sizeof(unsigned short) * 8); i++) {
-		unsigned int tmp;
-
-		DEASSERT(SGIMC_EEPROM_SECLOCK);
-		DELAY;
-		ASSERT(SGIMC_EEPROM_SECLOCK);
-		DELAY;
-		data <<= 1;
-		tmp = *cpu_control;
-		if(tmp & SGIMC_EEPROM_SDATAI)
-			data |= 1;
-	}
-	DEASSERT(SGIMC_EEPROM_SECLOCK);
-	DEASSERT(SGIMC_EEPROM_CSEL);
-	ASSERT(SGIMC_EEPROM_PRE);
-	ASSERT(SGIMC_EEPROM_SECLOCK);
-
-	data <<= PAGE_SHIFT;
-	if (data == 0)
+	unsigned long size = ip22_eeprom_read(&sgimc->eeprom, 17);
+	size <<= PAGE_SHIFT;
+	if (size == 0)
 		return 0;
 
-	scache_size = data;
-
 	printk(KERN_INFO "R4600/R5000 SCACHE size %ldK, linesize 32 bytes.\n",
-	       scache_size >> 10);
+	       size >> 10);
+	scache_size = size;
 
 	return 1;
 }
diff -Naur linux_2_4/arch/mips/mm/sc-ip22.c linux_2_4-fucked/arch/mips/mm/sc-ip22.c
--- linux_2_4/arch/mips/mm/sc-ip22.c	Thu Apr 17 02:29:14 2003
+++ linux_2_4-fucked/arch/mips/mm/sc-ip22.c	Wed May  7 20:10:22 2003
@@ -14,9 +14,7 @@
 #include <asm/pgtable.h>
 #include <asm/system.h>
 #include <asm/bootinfo.h>
-#include <asm/mmu_context.h>
-#include <asm/sgialib.h>
-#include <asm/sgi/sgi.h>
+#include <asm/sgi/ip22.h>
 #include <asm/sgi/mc.h>
 
 /* Secondary cache size in bytes, if present.  */
@@ -149,60 +147,14 @@
 
 static inline int __init indy_sc_probe(void)
 {
-	volatile unsigned int *cpu_control;
-	unsigned short cmd = 0xc220;
-	unsigned long data = 0;
-	int i, n;
-
-#ifdef __MIPSEB__
-	cpu_control = (volatile unsigned int *) KSEG1ADDR(0x1fa00034);
-#else
-	cpu_control = (volatile unsigned int *) KSEG1ADDR(0x1fa00030);
-#endif
-#define DEASSERT(bit) (*(cpu_control) &= (~(bit)))
-#define ASSERT(bit) (*(cpu_control) |= (bit))
-#define DELAY  for(n = 0; n < 100000; n++) __asm__ __volatile__("")
-	DEASSERT(SGIMC_EEPROM_PRE);
-	DEASSERT(SGIMC_EEPROM_SDATAO);
-	DEASSERT(SGIMC_EEPROM_SECLOCK);
-	DEASSERT(SGIMC_EEPROM_PRE);
-	DELAY;
-	ASSERT(SGIMC_EEPROM_CSEL); ASSERT(SGIMC_EEPROM_SECLOCK);
-	for(i = 0; i < 11; i++) {
-		if(cmd & (1<<15))
-			ASSERT(SGIMC_EEPROM_SDATAO);
-		else
-			DEASSERT(SGIMC_EEPROM_SDATAO);
-		DEASSERT(SGIMC_EEPROM_SECLOCK);
-		ASSERT(SGIMC_EEPROM_SECLOCK);
-		cmd <<= 1;
-	}
-	DEASSERT(SGIMC_EEPROM_SDATAO);
-	for(i = 0; i < (sizeof(unsigned short) * 8); i++) {
-		unsigned int tmp;
-
-		DEASSERT(SGIMC_EEPROM_SECLOCK);
-		DELAY;
-		ASSERT(SGIMC_EEPROM_SECLOCK);
-		DELAY;
-		data <<= 1;
-		tmp = *cpu_control;
-		if(tmp & SGIMC_EEPROM_SDATAI)
-			data |= 1;
-	}
-	DEASSERT(SGIMC_EEPROM_SECLOCK);
-	DEASSERT(SGIMC_EEPROM_CSEL);
-	ASSERT(SGIMC_EEPROM_PRE);
-	ASSERT(SGIMC_EEPROM_SECLOCK);
-
-	data <<= PAGE_SHIFT;
-	if (data == 0)
+	unsigned long size = ip22_eeprom_read(&sgimc->eeprom, 17);
+	size <<= PAGE_SHIFT;
+	if (size == 0)
 		return 0;
 
-	scache_size = data;
-
 	printk(KERN_INFO "R4600/R5000 SCACHE size %ldK, linesize 32 bytes.\n",
-	       scache_size >> 10);
+	       size >> 10);
+	scache_size = size;
 
 	return 1;
 }

From ladis@linux-mips.org Wed May  7 21:32:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 May 2003 21:32:50 +0100 (BST)
Received: from p0329.as-l042.contactel.cz ([IPv6:::ffff:194.108.238.75]:1028
	"EHLO kopretinka") by linux-mips.org with ESMTP id <S8225226AbTEGUcL>;
	Wed, 7 May 2003 21:32:11 +0100
Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian))
	id 19DVN9-00009x-00; Wed, 07 May 2003 22:18:39 +0200
Date: Wed, 7 May 2003 22:18:39 +0200
To: linux-mips@linux-mips.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Subject: [PATCH] implement NVRAM access for Indy
Message-ID: <20030507201839.GA598@kopretinka>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
From: Ladislav Michl <ladis@linux-mips.org>
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2285
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips


This patch brings you access to NVRAM chips and serial EEPROMs. Next
posts will show how useful it can be (not mentioning /proc interface to
PROM variables i'm going to implement :))

generated for 2.4 version. i'll generate 2.5 version if anyone is
interested...


diff -Naur linux_2_4/arch/mips/sgi-ip22/Makefile linux_2_4-fucked/arch/mips/sgi-ip22/Makefile
--- linux_2_4/arch/mips/sgi-ip22/Makefile	Tue May  6 03:20:28 2003
+++ linux_2_4-fucked/arch/mips/sgi-ip22/Makefile	Wed May  7 19:55:29 2003
@@ -14,8 +14,8 @@
 
 export-objs	:= ip22-ksyms.o
 obj-y		+= ip22-mc.o ip22-hpc.o ip22-int.o ip22-irq.o ip22-berr.o \
-		   ip22-time.o ip22-rtc.o ip22-reset.o ip22-system.o \
-		   ip22-setup.o ip22-ksyms.o
+		   ip22-time.o ip22-rtc.o ip22-nvram.o ip22-reset.o \
+		   ip22-system.o ip22-setup.o ip22-ksyms.o
 
 obj-$(CONFIG_IP22_EISA)		+= ip22-eisa.o
 
diff -Naur linux_2_4/arch/mips/sgi-ip22/ip22-ksyms.c linux_2_4-fucked/arch/mips/sgi-ip22/ip22-ksyms.c
--- linux_2_4/arch/mips/sgi-ip22/ip22-ksyms.c	Tue May  6 03:20:49 2003
+++ linux_2_4-fucked/arch/mips/sgi-ip22/ip22-ksyms.c	Wed May  7 19:55:30 2003
@@ -7,6 +7,7 @@
 #include <asm/sgi/mc.h>
 #include <asm/sgi/hpc3.h>
 #include <asm/sgi/ioc.h>
+#include <asm/sgi/ip22.h>
 
 EXPORT_SYMBOL(sgimc);
 EXPORT_SYMBOL(hpc3c0);
@@ -14,5 +15,7 @@
 EXPORT_SYMBOL(sgioc);
 
 extern void (*indy_volume_button)(int);
-
 EXPORT_SYMBOL(indy_volume_button);
+
+EXPORT_SYMBOL(ip22_eeprom_read);
+EXPORT_SYMBOL(ip22_nvram_read);
diff -Naur linux_2_4/arch/mips/sgi-ip22/ip22-nvram.c linux_2_4-fucked/arch/mips/sgi-ip22/ip22-nvram.c
--- linux_2_4/arch/mips/sgi-ip22/ip22-nvram.c	Thu Jan  1 01:00:00 1970
+++ linux_2_4-fucked/arch/mips/sgi-ip22/ip22-nvram.c	Wed May  7 21:31:32 2003
@@ -0,0 +1,114 @@
+/*
+ * ip22-nvram.c: NVRAM and serial EEPROM handling.
+ *
+ * Copyright (C) 2003 Ladislav Michl (ladis@linux-mips.org)
+ */
+
+#include <asm/sgi/hpc3.h>
+#include <asm/sgi/ip22.h>
+
+/* Control opcode for serial eeprom  */
+#define EEPROM_READ	0xc000	/* serial memory read */
+#define EEPROM_WEN	0x9800	/* write enable before prog modes */
+#define EEPROM_WRITE	0xa000	/* serial memory write */
+#define EEPROM_WRALL	0x8800	/* write all registers */
+#define EEPROM_WDS	0x8000	/* disable all programming */
+#define	EEPROM_PRREAD	0xc000	/* read protect register */
+#define	EEPROM_PREN	0x9800	/* enable protect register mode */
+#define	EEPROM_PRCLEAR	0xffff	/* clear protect register */
+#define	EEPROM_PRWRITE	0xa000	/* write protect register */
+#define	EEPROM_PRDS	0x8000	/* disable protect register, forever */
+
+#define EEPROM_EPROT	0x01	/* Protect register enable */
+#define EEPROM_CSEL	0x02	/* Chip select */
+#define EEPROM_ECLK	0x04	/* EEPROM clock */
+#define EEPROM_DATO	0x08	/* Data out */
+#define EEPROM_DATI	0x10	/* Data in */
+
+/* We need to use this functions early... */
+#define delay()	({						\
+	int x;							\
+	for (x=0; x<100000; x++) __asm__ __volatile__(""); })
+
+#define eeprom_cs_on(ptr) ({	\
+	*ptr &= ~EEPROM_DATO;	\
+	*ptr &= ~EEPROM_ECLK;	\
+	*ptr &= ~EEPROM_EPROT;	\
+	delay();		\
+	*ptr |= EEPROM_CSEL;	\
+	*ptr |= EEPROM_ECLK; })
+
+		
+#define eeprom_cs_off(ptr) ({	\
+	*ptr &= ~EEPROM_ECLK;	\
+	*ptr &= ~EEPROM_CSEL;	\
+	*ptr |= EEPROM_EPROT;	\
+	*ptr |= EEPROM_ECLK; })
+
+#define	BITS_IN_COMMAND	11
+/*
+ * clock in the nvram command and the register number. For the
+ * national semiconductor nv ram chip the op code is 3 bits and
+ * the address is 6/8 bits. 
+ */
+static inline void eeprom_cmd(volatile unsigned int *ctrl, unsigned cmd,
+			      unsigned reg)
+{
+	unsigned short ser_cmd;
+	int i;
+
+	ser_cmd = cmd | (reg << (16 - BITS_IN_COMMAND));
+	for (i = 0; i < BITS_IN_COMMAND; i++) {
+		if (ser_cmd & (1<<15))	/* if high order bit set */
+			*ctrl |= EEPROM_DATO;
+		else
+			*ctrl &= ~EEPROM_DATO;
+		*ctrl &= ~EEPROM_ECLK;
+		*ctrl |= EEPROM_ECLK;
+		ser_cmd <<= 1;
+	}
+	*ctrl &= ~EEPROM_DATO;	/* see data sheet timing diagram */
+}
+
+unsigned short ip22_eeprom_read(volatile unsigned int *ctrl, int reg)
+{
+	unsigned short res = 0;
+	int i;
+
+	*ctrl &= ~EEPROM_EPROT;
+	eeprom_cs_on(ctrl);
+	eeprom_cmd(ctrl, EEPROM_READ, reg);
+
+	/* clock the data ouf of serial mem */
+	for (i = 0; i < 16; i++) {
+		*ctrl &= ~EEPROM_ECLK;
+		delay();
+		*ctrl |= EEPROM_ECLK;
+		delay();
+		res <<= 1;
+		if (*ctrl & EEPROM_DATI)
+			res |= 1;
+	}
+		
+	eeprom_cs_off(ctrl);
+
+	return res;
+}
+
+/*
+ * Read specified register from main NVRAM
+ */
+unsigned short ip22_nvram_read(int reg)
+{
+	if (ip22_is_fullhouse())
+		/* IP22 (Indigo2 aka FullHouse) stores env variables into
+		 * 93CS56 Microwire Bus EEPROM 2048 Bit (128x16) */
+		return ip22_eeprom_read(&hpc3c0->eeprom, reg);
+	else {
+		unsigned short tmp;
+		/* IP24 (Indy aka Guiness) uses DS1386 8K version */
+		reg = 2 * reg + 64;
+		tmp = hpc3c0->bbram[reg++] & 0xff;
+		return (tmp << 8) | (hpc3c0->bbram[reg] & 0xff);
+	}		
+}
diff -Naur linux_2_4/arch/mips/sgi-ip22/ip22-rtc.c linux_2_4-fucked/arch/mips/sgi-ip22/ip22-rtc.c
--- linux_2_4/arch/mips/sgi-ip22/ip22-rtc.c	Tue May  6 03:20:49 2003
+++ linux_2_4-fucked/arch/mips/sgi-ip22/ip22-rtc.c	Wed May  7 19:55:30 2003
@@ -8,20 +8,16 @@
  * Copyright (C) 1998, 2001 by Ralf Baechle
  */
 #include <asm/ds1286.h>
-#include <asm/sgi/ip22.h>
+#include <asm/sgi/hpc3.h>
 
 static unsigned char ip22_rtc_read_data(unsigned long addr)
 {
-	volatile unsigned int *rtcregs = (void *)IP22_CLOCK_REGS;
-
-	return rtcregs[addr];
+	return hpc3c0->rtcregs[addr];
 }
 
 static void ip22_rtc_write_data(unsigned char data, unsigned long addr)
 {
-	volatile unsigned int *rtcregs = (void *)IP22_CLOCK_REGS;
-
-	rtcregs[addr] = data;
+	hpc3c0->rtcregs[addr] = data;
 }
 
 static int ip22_rtc_bcd_mode(void)
diff -Naur linux_2_4/include/asm-mips/sgi/hpc3.h linux_2_4-fucked/include/asm-mips/sgi/hpc3.h
--- linux_2_4/include/asm-mips/sgi/hpc3.h	Tue May  6 03:21:22 2003
+++ linux_2_4-fucked/include/asm-mips/sgi/hpc3.h	Wed May  7 21:20:17 2003
@@ -206,7 +206,7 @@
 #define HPC3_GIOMISC_ERTIME	0x1	/* Enable external timer real time. */
 #define HPC3_GIOMISC_DENDIAN	0x2	/* dma descriptor endian, 1=lit 0=big */
 
-	volatile u32 eeprom_data;	/* EEPROM data reg. */
+	volatile u32 eeprom;		/* EEPROM data reg. */
 #define HPC3_EEPROM_EPROT	0x01	/* Protect register enable */
 #define HPC3_EEPROM_CSEL	0x02	/* Chip select */
 #define HPC3_EEPROM_ECLK	0x04	/* EEPROM clock */
@@ -298,7 +298,10 @@
 #define HPC3_PROM_STAT	0x1	/* General purpose status bit in gout */
 
 	u32 _unused7[0x1000/4 - 1];
-	volatile u32 pbus_promram[16384];	/* 64k of PROM battery backed ram */
+	union {
+		volatile u32 bbram[8192];	/* Battery backed ram */
+		volatile u32 rtcregs[14];	/* Dallas clock registers */
+	};
 };
 
 /* 
diff -Naur linux_2_4/include/asm-mips/sgi/ip22.h linux_2_4-fucked/include/asm-mips/sgi/ip22.h
--- linux_2_4/include/asm-mips/sgi/ip22.h	Tue May  6 03:21:24 2003
+++ linux_2_4-fucked/include/asm-mips/sgi/ip22.h	Wed May  7 20:00:31 2003
@@ -71,6 +71,7 @@
 
 #define ip22_is_fullhouse()	(sgioc->sysid & SGIOC_SYSID_FULLHOUSE)
 
-#define IP22_CLOCK_REGS (KSEG1ADDR(0x1fbe0000))
+extern unsigned short ip22_eeprom_read(volatile unsigned int *ctrl, int reg);
+extern unsigned short ip22_nvram_read(int reg);
 
 #endif
diff -Naur linux_2_4/include/asm-mips64/sgi/hpc3.h linux_2_4-fucked/include/asm-mips64/sgi/hpc3.h
--- linux_2_4/include/asm-mips64/sgi/hpc3.h	Tue May  6 03:21:28 2003
+++ linux_2_4-fucked/include/asm-mips64/sgi/hpc3.h	Wed May  7 21:46:08 2003
@@ -206,7 +206,7 @@
 #define HPC3_GIOMISC_ERTIME	0x1	/* Enable external timer real time. */
 #define HPC3_GIOMISC_DENDIAN	0x2	/* dma descriptor endian, 1=lit 0=big */
 
-	volatile u32 eeprom_data;	/* EEPROM data reg. */
+	volatile u32 eeprom;		/* EEPROM data reg. */
 #define HPC3_EEPROM_EPROT	0x01	/* Protect register enable */
 #define HPC3_EEPROM_CSEL	0x02	/* Chip select */
 #define HPC3_EEPROM_ECLK	0x04	/* EEPROM clock */
@@ -298,7 +298,10 @@
 #define HPC3_PROM_STAT	0x1	/* General purpose status bit in gout */
 
 	u32 _unused7[0x1000/4 - 1];
-	volatile u32 pbus_promram[16384];	/* 64k of PROM battery backed ram */
+	union {
+		volatile u32 bbram[8192];	/* Battery backed ram */
+		volatile u32 rtcregs[14];	/* Dallas clock registers */
+	};
 };
 
 /* 
diff -Naur linux_2_4/include/asm-mips64/sgi/ip22.h linux_2_4-fucked/include/asm-mips64/sgi/ip22.h
--- linux_2_4/include/asm-mips64/sgi/ip22.h	Tue May  6 03:21:30 2003
+++ linux_2_4-fucked/include/asm-mips64/sgi/ip22.h	Wed May  7 19:55:29 2003
@@ -6,7 +6,7 @@
  * ip22.h: Definitions for SGI IP22 machines
  *
  * Copyright (C) 1996 David S. Miller
- * Copyright (C) 1997, 1999, 2000 Ralf Baechle
+ * Copyright (C) 1997, 1998, 1999, 2000 Ralf Baechle
  */
 
 #ifndef _SGI_IP22_H
@@ -71,6 +71,7 @@
 
 #define ip22_is_fullhouse()	(sgioc->sysid & SGIOC_SYSID_FULLHOUSE)
 
-#define IP22_CLOCK_REGS (KSEG1ADDR(0x1fbe0000))
+extern unsigned short ip22_eeprom_read(volatile unsigned int *ctrl, int reg);
+extern unsigned short ip22_nvram_read(int reg);
 
 #endif

From quintela@mandrakesoft.com Wed May  7 23:15:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 May 2003 23:15:28 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:14692 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225227AbTEGWPZ>;
	Wed, 7 May 2003 23:15:25 +0100
Received: by trasno.mitica (Postfix, from userid 1001)
	id C4CB67DC; Thu,  8 May 2003 00:14:56 +0200 (CEST)
To: Ladislav Michl <ladis@linux-mips.org>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] SGI Seeq cleanup
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030507202851.GA668@kopretinka> (Ladislav Michl's message of
 "Wed, 7 May 2003 22:28:51 +0200")
References: <20030507202851.GA668@kopretinka>
Date: Thu, 08 May 2003 00:14:56 +0200
Message-ID: <86d6iul7z3.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2286
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@mandrakesoft.com
Precedence: bulk
X-list: linux-mips

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

ladis> read eaddr using NVRAM access fuctions and make various cleanups so driver
ladis> can be build as module

You are my hero!

[ Removal of Space.c entry ] 

Hero++

ladis> @@ -96,8 +97,8 @@
ladis> struct sgiseeq_private {
ladis> volatile struct sgiseeq_init_block srings;
ladis> char *name;
ladis> -	volatile struct hpc3_ethregs *hregs;
ladis> -	volatile struct sgiseeq_regs *sregs;
ladis> +	struct hpc3_ethregs *hregs;
ladis> +	struct sgiseeq_regs *sregs;

I read through all the patch, and I didn't understand why volatile is
not needed anymore :(

Althought not that I did understand why it was needed in the first
place :)

ladis> @@ -435,7 +439,7 @@
ladis> /* Always check for received packets. */
ladis> sgiseeq_rx(dev, sp, hregs, sregs);
 
ladis> -	/* Only check for tx acks iff we have something queued. */
ladis> +	/* Only check for tx acks if we have something queued. */
ladis> if (sp->tx_old != sp->tx_new)
ladis> sgiseeq_tx(dev, sp, hregs, sregs);

iff == Math speak for if and only if.  Not sure if iff is needed in
that context at all.

Later, Juan. 

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

From quintela@mandrakesoft.com Wed May  7 23:17:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 May 2003 23:17:46 +0100 (BST)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:22116 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225227AbTEGWRo>;
	Wed, 7 May 2003 23:17:44 +0100
Received: by trasno.mitica (Postfix, from userid 1001)
	id 51AEA7DC; Thu,  8 May 2003 00:17:18 +0200 (CEST)
To: Ladislav Michl <ladis@linux-mips.org>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] sc-ip22.c cleanup
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030507202229.GA627@kopretinka> (Ladislav Michl's message of
 "Wed, 7 May 2003 22:22:29 +0200")
References: <20030507202229.GA627@kopretinka>
Date: Thu, 08 May 2003 00:17:18 +0200
Message-ID: <8665oml7v5.fsf@trasno.mitica>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2287
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@mandrakesoft.com
Precedence: bulk
X-list: linux-mips

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

Hi

ladis> +	unsigned long size = ip22_eeprom_read(&sgimc->eeprom, 17);

Defining somewhere what 17 mean could be a good idea :)

Except for that looks like a good gain, you remove a lot fo code :)

Later, Juan.

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

From baitisj@idealab.com Thu May  8 04:31:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 04:31:36 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:49366 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225192AbTEHDbb>;
	Thu, 8 May 2003 04:31:31 +0100
Received: (qmail 3351 invoked by uid 6180); 8 May 2003 03:31:27 -0000
Date: Wed, 7 May 2003 20:31:27 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: linux-mips@linux-mips.org
Subject: USB OHCI device port on Alchemy
Message-ID: <20030507203127.U30468@luca.pas.lab>
Reply-To: baitisj@evolution.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2288
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

Out of curiousity:

Has anyone played with the AU1X00 USB device port yet? If not, what would you
guys suggest that the AU1X00 appear as? USB over Ethernet? Or maybe a simple
dummy device that will perform bulk transfers?

Thanks!

-Jeff


-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From wesolows@foobazco.org Thu May  8 07:11:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 07:11:32 +0100 (BST)
Received: from janus.foobazco.org ([IPv6:::ffff:198.144.194.226]:10501 "EHLO
	mail.foobazco.org") by linux-mips.org with ESMTP
	id <S8225192AbTEHGLa>; Thu, 8 May 2003 07:11:30 +0100
Received: from fallout.sjc.foobazco.org (fallout.sjc.foobazco.org [192.168.21.20])
	by mail.foobazco.org (Postfix) with ESMTP
	id 64DB91BD8D; Wed,  7 May 2003 23:11:23 -0700 (PDT)
Received: by fallout.sjc.foobazco.org (Postfix, from userid 1014)
	id B8C2624; Wed,  7 May 2003 23:11:17 -0700 (PDT)
Date: Wed, 7 May 2003 23:11:17 -0700
From: Keith M Wesolowski <wesolows@foobazco.org>
To: Ladislav Michl <ladis@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Highmem detection for Indigo2
Message-ID: <20030508061117.GA30191@foobazco.org>
References: <20030428071639.GA7578@simek>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030428071639.GA7578@simek>
User-Agent: Mutt/1.5.4i
Return-Path: <wesolows@foobazco.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2289
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wesolows@foobazco.org
Precedence: bulk
X-list: linux-mips

On Mon, Apr 28, 2003 at 09:16:39AM +0200, Ladislav Michl wrote:

> Following patch builds whole RAM map based of MC's memory configuration
> registers, does some samity checks adds high system memory (if any) to
> bootmem.

> +static void init_bootmem(void)
...
> +	init_bootmem();

This is a pretty unfortunate choice of names for this function.  See
mm/bootmem.c.

Other than that, your patch works fine for me; my Indy has 192MB
memory and it's detected properly.  I do get an oops in do_be from
xdm, but I get that without the patch also.

Determined physical RAM map:
 memory: 00001000 @ 00000000 (reserved)
 memory: 00001000 @ 00001000 (reserved)
 memory: 001e1000 @ 08002000 (reserved)
 memory: 0055d000 @ 081e3000 (usable)
 memory: 000c0000 @ 08740000 (ROM data)
 memory: 0b800000 @ 08800000 (usable)

I need to do the same kind of thing for ip32 as the ARC memory
detection has the same shortcoming on that platform.  No sense having
a machine support 1GB memory and only looking for 256MB of it,
especially in a 64-bit kernel.  ARC[S] really does seem to be useless.

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
	"May Buddha bless all stubborn people!"
				-- Uliassutai Karakorum Blake

From Yasushi.SHOJI@atmark-techno.com Thu May  8 07:53:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 07:53:39 +0100 (BST)
Received: from dns1.atmark-techno.com ([IPv6:::ffff:61.199.192.114]:63495 "EHLO
	dns1.atmark-techno.com") by linux-mips.org with ESMTP
	id <S8225230AbTEHGxh>; Thu, 8 May 2003 07:53:37 +0100
Received: from wat.atmark-techno.com (unknown [192.168.10.81])
	by dns1.atmark-techno.com (Postfix) with ESMTP
	id 294643E4CC; Thu,  8 May 2003 15:53:35 +0900 (JST)
Date: Thu, 08 May 2003 15:53:34 +0900
From: Yasushi SHOJI <yashi@atmark-techno.com>
To: baitisj@evolution.com
Cc: linux-mips@linux-mips.org
Subject: Re: USB OHCI device port on Alchemy
In-Reply-To: <20030507203127.U30468@luca.pas.lab>
References: <20030507203127.U30468@luca.pas.lab>
User-Agent: User-Agent: Wanderlust/2.10.0
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20030508065335.294643E4CC@dns1.atmark-techno.com>
Return-Path: <Yasushi.SHOJI@atmark-techno.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2290
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yashi@atmark-techno.com
Precedence: bulk
X-list: linux-mips

At Wed, 7 May 2003 20:31:27 -0700,
Jeff Baitis wrote:
> 
> Has anyone played with the AU1X00 USB device port yet? If not, what would you
> guys suggest that the AU1X00 appear as? USB over Ethernet? Or maybe a simple
> dummy device that will perform bulk transfers?

there are au1000_usbraw.c and au1000_usbtty.c in linux-mips.org's CVS
under drivers/char.

I'd be excited to see usb storage driver for usb device.

as a related topic, does anyone know how usb gadget api is coming? I'm
assuming that once usb gadget stabilized and people start using it,
we'll be converting au1's usb dev driver to gadget api, no?

or people already working on it?
--
      yashi

From ladis@linux-mips.org Thu May  8 08:45:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 08:45:53 +0100 (BST)
Received: from p0241.as-l042.contactel.cz ([IPv6:::ffff:194.108.237.241]:3332
	"EHLO kopretinka") by linux-mips.org with ESMTP id <S8225230AbTEHHpv>;
	Thu, 8 May 2003 08:45:51 +0100
Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian))
	id 19Dg3Z-0000Gs-00; Thu, 08 May 2003 09:43:09 +0200
Date: Thu, 8 May 2003 09:43:09 +0200
To: Juan Quintela <quintela@mandrakesoft.com>
Cc: Ladislav Michl <ladis@linux-mips.org>, linux-mips@linux-mips.org,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] SGI Seeq cleanup
Message-ID: <20030508074308.GB837@kopretinka>
References: <20030507202851.GA668@kopretinka> <86d6iul7z3.fsf@trasno.mitica>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86d6iul7z3.fsf@trasno.mitica>
User-Agent: Mutt/1.3.28i
From: Ladislav Michl <ladis@linux-mips.org>
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2291
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, May 08, 2003 at 12:14:56AM +0200, Juan Quintela wrote:
> >>>>> "ladis" == Ladislav Michl <ladis@linux-mips.org> writes:
> 
> ladis> read eaddr using NVRAM access fuctions and make various cleanups so driver
> ladis> can be build as module
> 
> You are my hero!
> 
> [ Removal of Space.c entry ] 

Question comes in mind: It's possible to have ISA eth card installed in
Indigo2. How to ensure that onboard Seeq will be always eth0 without
using Space.c? (and don't advice me to build driver for ISA card as
module :))

> Hero++
> 
> ladis> @@ -96,8 +97,8 @@
> ladis> struct sgiseeq_private {
> ladis> volatile struct sgiseeq_init_block srings;
> ladis> char *name;
> ladis> -	volatile struct hpc3_ethregs *hregs;
> ladis> -	volatile struct sgiseeq_regs *sregs;
> ladis> +	struct hpc3_ethregs *hregs;
> ladis> +	struct sgiseeq_regs *sregs;
> 
> I read through all the patch, and I didn't understand why volatile is
> not needed anymore :(
> 
> Althought not that I did understand why it was needed in the first
> place :)

I think struct members have to be volatile, not struct itself.

> ladis> @@ -435,7 +439,7 @@
> ladis> /* Always check for received packets. */
> ladis> sgiseeq_rx(dev, sp, hregs, sregs);
>  
> ladis> -	/* Only check for tx acks iff we have something queued. */
> ladis> +	/* Only check for tx acks if we have something queued. */
> ladis> if (sp->tx_old != sp->tx_new)
> ladis> sgiseeq_tx(dev, sp, hregs, sregs);
> 
> iff == Math speak for if and only if.  Not sure if iff is needed in
> that context at all.

Ah, didn't know it. But i'd say simple if is enough in this case :)

	ladis

From ladis@linux-mips.org Thu May  8 08:46:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 08:46:15 +0100 (BST)
Received: from p0241.as-l042.contactel.cz ([IPv6:::ffff:194.108.237.241]:4100
	"EHLO kopretinka") by linux-mips.org with ESMTP id <S8225235AbTEHHqB>;
	Thu, 8 May 2003 08:46:01 +0100
Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian))
	id 19Dfsm-0000Gf-00; Thu, 08 May 2003 09:32:00 +0200
Date: Thu, 8 May 2003 09:32:00 +0200
To: Keith M Wesolowski <wesolows@foobazco.org>
Cc: linux-mips@linux-mips.org, Guido Guenther <agx@sigxcpu.org>
Subject: Re: [PATCH] Highmem detection for Indigo2
Message-ID: <20030508073200.GA837@kopretinka>
References: <20030428071639.GA7578@simek> <20030508061117.GA30191@foobazco.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030508061117.GA30191@foobazco.org>
User-Agent: Mutt/1.3.28i
From: Ladislav Michl <ladis@linux-mips.org>
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2292
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, May 07, 2003 at 11:11:17PM -0700, Keith M Wesolowski wrote:
> On Mon, Apr 28, 2003 at 09:16:39AM +0200, Ladislav Michl wrote:
> 
> > Following patch builds whole RAM map based of MC's memory configuration
> > registers, does some samity checks adds high system memory (if any) to
> > bootmem.
> 
> > +static void init_bootmem(void)
> ...
> > +	init_bootmem();
> 
> This is a pretty unfortunate choice of names for this function.  See
> mm/bootmem.c.

what about probe_memory or detect_memory?

> Other than that, your patch works fine for me; my Indy has 192MB
> memory and it's detected properly.  I do get an oops in do_be from
> xdm, but I get that without the patch also.
> 
> Determined physical RAM map:
>  memory: 00001000 @ 00000000 (reserved)
>  memory: 00001000 @ 00001000 (reserved)
>  memory: 001e1000 @ 08002000 (reserved)
>  memory: 0055d000 @ 081e3000 (usable)
>  memory: 000c0000 @ 08740000 (ROM data)
>  memory: 0b800000 @ 08800000 (usable)

that's not relevant part. information from memconfig registers is
printed above "Determined physical RAM map" [1]
MC: Probing memory configuration:
 Bank0:  32M @ 10000000
 Bank1: 128M @ 08000000
  
> I need to do the same kind of thing for ip32 as the ARC memory
> detection has the same shortcoming on that platform.  No sense having
> a machine support 1GB memory and only looking for 256MB of it,
> especially in a 64-bit kernel.  ARC[S] really does seem to be useless.

[1] This patch still uses ARCS to determine low 256M of memory, because
Indy can't have more anyway, it is useful only for FullHouse machines.
Purpose of this patch is to detect memory above 0x20000000. Idea was to
let people test if memconfig registers provides relevant informations
and then get rid of ARCS based memory probing completely. Kernel
reserves its memory itself and we know where exceptions vectors are (do
i need reserve space for them explicitly?), so the only problem is ARCS
data (it's not possible to detect where ARCS stores them without asking
it). If no ARCS call will be made after mm initialization (thoose few
remaining is easy to avoid) this should be also no problem.

Guido told me he is working device detection based on ARCS calls. I'm
not sure is this way will be acceptale for him...

	ladis

From agx@sigxcpu.org Thu May  8 10:38:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 10:38:27 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:38324
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225235AbTEHJiZ>; Thu, 8 May 2003 10:38:25 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 0CA232BC31; Thu,  8 May 2003 11:38:23 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 09245-01;
 Thu,  8 May 2003 11:38:21 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id DA2C72BC38; Thu,  8 May 2003 11:38:15 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id BBB9E1735D; Thu,  8 May 2003 10:50:04 +0200 (CEST)
Date: Thu, 8 May 2003 10:50:04 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: Ladislav Michl <ladis@linux-mips.org>
Cc: Keith M Wesolowski <wesolows@foobazco.org>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] Highmem detection for Indigo2
Message-ID: <20030508085004.GI13672@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	Ladislav Michl <ladis@linux-mips.org>,
	Keith M Wesolowski <wesolows@foobazco.org>, linux-mips@linux-mips.org
References: <20030428071639.GA7578@simek> <20030508061117.GA30191@foobazco.org> <20030508073200.GA837@kopretinka>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030508073200.GA837@kopretinka>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2293
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Thu, May 08, 2003 at 09:32:00AM +0200, Ladislav Michl wrote:
> Guido told me he is working device detection based on ARCS calls. I'm
> not sure is this way will be acceptale for him...
Having what the ARC spec calls "System Configuration Data" in a tree
like structure would be a nice thing, I think. I have some code for this
around here but wanted to check sysfs in 2.5 to see if it eases up the
representation - we could finally properly detect the primary graphics
board with that.
 -- Guido

From agx@sigxcpu.org Thu May  8 10:38:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 10:38:48 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:38068
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225236AbTEHJiZ>; Thu, 8 May 2003 10:38:25 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 34A842BC3A; Thu,  8 May 2003 11:38:22 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 09113-08;
 Thu,  8 May 2003 11:38:20 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id D4D502BC31; Thu,  8 May 2003 11:38:15 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id A72B51739C; Thu,  8 May 2003 10:58:15 +0200 (CEST)
Date: Thu, 8 May 2003 10:58:15 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: Keith M Wesolowski <wesolows@foobazco.org>
Cc: linux-mips@linux-mips.org, Ladislav Michl <ladis@linux-mips.org>
Subject: Re: [PATCH] Highmem detection for Indigo2
Message-ID: <20030508085814.GJ13672@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	Keith M Wesolowski <wesolows@foobazco.org>,
	linux-mips@linux-mips.org, Ladislav Michl <ladis@linux-mips.org>
References: <20030428071639.GA7578@simek> <20030508061117.GA30191@foobazco.org> <20030508073200.GA837@kopretinka>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030508073200.GA837@kopretinka>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2294
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Wed, May 07, 2003 at 11:11:17PM -0700, Keith M Wesolowski wrote:
> Other than that, your patch works fine for me; my Indy has 192MB
> memory and it's detected properly.  I do get an oops in do_be from
> xdm, but I get that without the patch also.
That's xdm reading heaps of data from /dev/mem blindly (touching regions
it better shouldn't read from) for prng purposes. We had a fix in
Debian's xdm, hope the problem didn't creep back in. What X are you
running?
 -- Guido

From michaelanburaj@hotmail.com Thu May  8 11:10:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 11:10:04 +0100 (BST)
Received: from bay1-f62.bay1.hotmail.com ([IPv6:::ffff:65.54.245.62]:64006
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225236AbTEHKKC>; Thu, 8 May 2003 11:10:02 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 8 May 2003 03:09:53 -0700
Received: from 4.35.224.219 by by1fd.bay1.hotmail.msn.com with HTTP;
	Thu, 08 May 2003 10:09:53 GMT
X-Originating-IP: [4.35.224.219]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Thu, 08 May 2003 03:09:53 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F62WlX0MGOV6T000004f80@hotmail.com>
X-OriginalArrivalTime: 08 May 2003 10:09:53.0319 (UTC) FILETIME=[F7F2DB70:01C31549]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2295
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi all,

Finally I got the Atlas 4Kc board running YAMON to talk to Host PC running 
RedHat Linux 9 & download vmlinux.rec throught tftp. I have set-up NFS 
export in the same PC under /export/RedHat7.1

After the vmlinux.rec got downloaded, I issued the following command on the 
YAMON (MIPS tartget) prompt to start the downloaded linux kernel:

go . nsfroot=4.42.102.7:/export/RedHat7.1

while the Linux kernel was booting up, I  monitored the tcp/ip traffic on 
the host PC using 'tcpdump -n'. The Linux did not send any packets. why?

YAMON console dump of Linux kernel start-up messages:
------------------------------------------------------------------------------

YAMON> load tftp:
About to load tftp://4.42.102.7/vmlinux.rec
Press Ctrl-C to break
........................................
........................................
........................................
........................................
......................................
Start = 0x8024a040, range = (0x80100000,0x8028dfff), format = SREC
YAMON> go . nfsroot=4.42.102.7:/export/RedHat7.1

LINUX started...
Config serial console: ttyS0,115200
CPU revision is: 00018001
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 16kB 4-way, linesize 16 bytes.
Linux version 2.4.21-pre4 (root@localhost.localdomain) (gcc version 
egcs-2.91.63Determined physical RAM map:
memory: 00001000 @ 00000000 (reserved)
memory: 000ef000 @ 00001000 (ROM data)
memory: 00010000 @ 000f0000 (ROM data)
memory: 001a4000 @ 00100000 (reserved)
memory: 03d5c000 @ 002a4000 (usable)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: nfsroot=4.42.102.7:/export/RedHat7.1
calculating r4koff... 00061a87(400007)
CPU frequency 80.00 MHz
Calibrating delay loop... 79.66 BogoMIPS
Memory: 62120k/62832k available (1308k kernel code, 712k reserved, 164k 
data, 1)Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware on host bus 0.
PCI: device 01:02.0 has unknown header type 7f, ignoring.
PCI: device 01:06.0 has unknown header type 7f, ignoring.
PCI: device 01:18.0 has unknown header type 7f, ignoring.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ 
SERIAL_PCI edttyS00 at 0x1f000900 (irq = 0) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Found SAA9730 (PCI) at 0x10800000, irq 16.
SCSI subsystem driver Revision: 1.00
ncr53c8xx: at PCI bus 0, device 16, function 0
ncr53c8xx: 53c810a detected
ncr53c810a-0: rev 0x12 on pci bus 0 device 16 function 0 irq 17
ncr53c810a-0: ID 7, Fast-10, Parity Checking
scsi0 : ncr53c8xx-3.4.3b-20010512
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 4.42.102.7
RPC: sendmsg returned error 128
portmap: RPC call returned error 128
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 4.42.102.7
RPC: sendmsg returned error 128
portmap: RPC call returned error 128
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 128
mount: RPC call returned error 128
Root-NFS: Server returned error -128 while mounting /export/RedHat7.1
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00



Please let me know if you have any clues on this...

Thanks a lot,
-Mike.

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


From jbglaw@dvmwest.gt.owl.de Thu May  8 12:20:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 12:20:58 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:17672 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225239AbTEHLU4>; Thu, 8 May 2003 12:20:56 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 34D874AB98; Thu,  8 May 2003 13:20:53 +0200 (CEST)
Date: Thu, 8 May 2003 13:20:53 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Message-ID: <20030508112052.GT27494@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <BAY1-F62WlX0MGOV6T000004f80@hotmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="/tCzywT4ru0wuIhW"
Content-Disposition: inline
In-Reply-To: <BAY1-F62WlX0MGOV6T000004f80@hotmail.com>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2296
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


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

On Thu, 2003-05-08 03:09:53 -0700, Michael Anburaj <michaelanburaj@hotmail.=
com>
wrote in message <BAY1-F62WlX0MGOV6T000004f80@hotmail.com>:
> Hi all,
>=20
> Finally I got the Atlas 4Kc board running YAMON to talk to Host PC runnin=
g=20
> RedHat Linux 9 & download vmlinux.rec throught tftp. I have set-up NFS=20
> export in the same PC under /export/RedHat7.1
>=20
> After the vmlinux.rec got downloaded, I issued the following command on t=
he=20
> YAMON (MIPS tartget) prompt to start the downloaded linux kernel:
>=20
> go . nsfroot=3D4.42.102.7:/export/RedHat7.1
                                           ^^^^^^^

I think the box doesn't have an IP address, nor has it been told to pick
one. You should add 'ip=3Dbootp' or 'ip=3Ddhcp' to your command line.

> Protect your PC - get McAfee.com VirusScan Online =20
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963

Protecting a PeeCee is more an act of not shooting one's own feet by
running known-bad software...

MfG, JBG

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

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

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

iD8DBQE+uj2UHb1edYOZ4bsRAsVnAJ97Air0mXDemeh/ibno99tBwQ6dPQCbBH37
cozPrwBsIn1nT1u3L0W7RXE=
=oRVZ
-----END PGP SIGNATURE-----

--/tCzywT4ru0wuIhW--

From ralf@linux-mips.org Thu May  8 13:20:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 13:20:22 +0100 (BST)
Received: from p508B5AA9.dip.t-dialin.net ([IPv6:::ffff:80.139.90.169]:31936
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225239AbTEHMUU>; Thu, 8 May 2003 13:20:20 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h48CKHts007310;
	Thu, 8 May 2003 14:20:17 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h48CKC8v007309;
	Thu, 8 May 2003 14:20:12 +0200
Date: Thu, 8 May 2003 14:20:11 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Ladislav Michl <ladis@linux-mips.org>
Cc: Juan Quintela <quintela@mandrakesoft.com>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] SGI Seeq cleanup
Message-ID: <20030508122011.GA7210@linux-mips.org>
References: <20030507202851.GA668@kopretinka> <86d6iul7z3.fsf@trasno.mitica> <20030508074308.GB837@kopretinka>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030508074308.GB837@kopretinka>
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: 2297
X-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, May 08, 2003 at 09:43:09AM +0200, Ladislav Michl wrote:

> > You are my hero!
> > 
> > [ Removal of Space.c entry ] 

Absolutely, Space.c, RIP - Rot In Pieces.

> Question comes in mind: It's possible to have ISA eth card installed in
> Indigo2. How to ensure that onboard Seeq will be always eth0 without
> using Space.c? (and don't advice me to build driver for ISA card as
> module :))

You just need to make sure sgiseeq.o is linked in before any of the ISA
drivers.

ISA link ordering is sort of emprical rocket science but fortunately
the IP22 Seeq isn't ISA.

  Ralf

From wesolows@foobazco.org Thu May  8 17:40:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 17:40:29 +0100 (BST)
Received: from janus.foobazco.org ([IPv6:::ffff:198.144.194.226]:19973 "EHLO
	mail.foobazco.org") by linux-mips.org with ESMTP
	id <S8225239AbTEHQk1>; Thu, 8 May 2003 17:40:27 +0100
Received: by mail.foobazco.org (Postfix, from userid 1014)
	id DBEC11BD8F; Thu,  8 May 2003 09:40:22 -0700 (PDT)
Date: Thu, 8 May 2003 09:40:22 -0700
From: Keith M Wesolowski <wesolows@foobazco.org>
To: Guido Guenther <agx@sigxcpu.org>, linux-mips@linux-mips.org,
	Ladislav Michl <ladis@linux-mips.org>
Subject: Re: xdm oopses
Message-ID: <20030508164022.GA8956@foobazco.org>
References: <20030428071639.GA7578@simek> <20030508061117.GA30191@foobazco.org> <20030508073200.GA837@kopretinka> <20030508085814.GJ13672@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030508085814.GJ13672@bogon.ms20.nix>
User-Agent: Mutt/1.5.3i
Return-Path: <wesolows@foobazco.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2298
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wesolows@foobazco.org
Precedence: bulk
X-list: linux-mips

On Thu, May 08, 2003 at 10:58:15AM +0200, Guido Guenther wrote:

> On Wed, May 07, 2003 at 11:11:17PM -0700, Keith M Wesolowski wrote:
> > Other than that, your patch works fine for me; my Indy has 192MB
> > memory and it's detected properly.  I do get an oops in do_be from
> > xdm, but I get that without the patch also.

> That's xdm reading heaps of data from /dev/mem blindly (touching regions
> it better shouldn't read from) for prng purposes. We had a fix in
> Debian's xdm, hope the problem didn't creep back in. What X are you
> running?

This is from Debian - 4.1.0-16.

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
	"May Buddha bless all stubborn people!"
				-- Uliassutai Karakorum Blake

From michaelanburaj@hotmail.com Thu May  8 18:03:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 18:03:05 +0100 (BST)
Received: from bay1-f17.bay1.hotmail.com ([IPv6:::ffff:65.54.245.17]:28424
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225239AbTEHRDD>; Thu, 8 May 2003 18:03:03 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 8 May 2003 10:02:55 -0700
Received: from 4.35.224.219 by by1fd.bay1.hotmail.msn.com with HTTP;
	Thu, 08 May 2003 17:02:54 GMT
X-Originating-IP: [4.35.224.219]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Thu, 08 May 2003 10:02:54 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F17fJpbi7Phnzi00006011@hotmail.com>
X-OriginalArrivalTime: 08 May 2003 17:02:55.0190 (UTC) FILETIME=[AB184760:01C31583]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2299
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi JBG,

The MIPS box (Atlas running YAMON) has a fixed IP address assigned by me. 
TFTP boot works fine. But this IP is held within the boot monitor program 
(YAMON).

YAMON> set

baseboardserial (RO)   0000000197
bootfile        (R/W)  vmlinux.rec
bootprot        (R/W)  tftp
bootserport     (R/W)  tty0
bootserver      (R/W)  4.42.102.7
cpuconfig       (R/W)
ethaddr         (RO)   00.d0.a0.00.00.ed
fpu             (R/W)
gateway         (R/W)  12.235.80.1
ipaddr          (R/W)  4.42.102.6
memsize         (RO)   0x04000000
modetty0        (R/W)  115200,n,8,1,hw
modetty1        (R/W)  115200,n,8,1,hw
prompt          (R/W)  YAMON
start           (R/W)
startdelay      (R/W)
subnetmask      (R/W)  255.255.252.0
yamonrev        (RO)   02.04

Apart from the dynamic IP address assignment methods....
Suggest me a method to communicate this value to the RAM resident Linux 
kernel. Or can I assign a fixed IP addredd by passing it as a parameter when 
the linux kernel boots up? If so what is the syntax & please point me to the 
document that has this info. about passed parameter when booting the kernel.

Thanks,
-Mike.


>From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
>To: linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board
>Date: Thu, 8 May 2003 13:20:53 +0200
>
>On Thu, 2003-05-08 03:09:53 -0700, Michael Anburaj 
><michaelanburaj@hotmail.com>
>wrote in message <BAY1-F62WlX0MGOV6T000004f80@hotmail.com>:
> > Hi all,
> >
> > Finally I got the Atlas 4Kc board running YAMON to talk to Host PC 
>running
> > RedHat Linux 9 & download vmlinux.rec throught tftp. I have set-up NFS
> > export in the same PC under /export/RedHat7.1
> >
> > After the vmlinux.rec got downloaded, I issued the following command on 
>the
> > YAMON (MIPS tartget) prompt to start the downloaded linux kernel:
> >
> > go . nsfroot=4.42.102.7:/export/RedHat7.1
>                                            ^^^^^^^
>
>I think the box doesn't have an IP address, nor has it been told to pick
>one. You should add 'ip=bootp' or 'ip=dhcp' to your command line.
>
> > Protect your PC - get McAfee.com VirusScan Online
> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>Protecting a PeeCee is more an act of not shooting one's own feet by
>running known-bad software...
>
>MfG, JBG
>
>--
>    Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
>    "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen 
>Krieg
>     fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im 
>Irak!
>       ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
><< attach3 >>

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


From agx@sigxcpu.org Thu May  8 18:04:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 18:04:46 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:54455
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225239AbTEHREn>; Thu, 8 May 2003 18:04:43 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 6EDD32BC32; Thu,  8 May 2003 19:04:34 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 11758-07;
 Thu,  8 May 2003 19:04:33 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 6BE672BC31; Thu,  8 May 2003 19:04:28 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id E17491735D; Thu,  8 May 2003 19:00:51 +0200 (CEST)
Date: Thu, 8 May 2003 19:00:51 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Cc: Keith M Wesolowski <wesolows@foobazco.org>,
	Ladislav Michl <ladis@linux-mips.org>
Subject: Re: xdm oopses
Message-ID: <20030508170051.GD29550@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org,
	Keith M Wesolowski <wesolows@foobazco.org>,
	Ladislav Michl <ladis@linux-mips.org>
References: <20030428071639.GA7578@simek> <20030508061117.GA30191@foobazco.org> <20030508073200.GA837@kopretinka> <20030508085814.GJ13672@bogon.ms20.nix> <20030508164022.GA8956@foobazco.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030508164022.GA8956@foobazco.org>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2300
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Thu, May 08, 2003 at 09:40:22AM -0700, Keith M Wesolowski wrote:
> > That's xdm reading heaps of data from /dev/mem blindly (touching regions
> > it better shouldn't read from) for prng purposes. We had a fix in
> > Debian's xdm, hope the problem didn't creep back in. What X are you
> > running?
> 
> This is from Debian - 4.1.0-16.
The changes went into 4.2.1-4 at 18 Nov 2002.
 -- Guido

From ppopov@mvista.com Thu May  8 18:40:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 18:40:29 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:30960 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225239AbTEHRk1>;
	Thu, 8 May 2003 18:40:27 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA26643;
	Thu, 8 May 2003 10:40:21 -0700
Subject: Re: USB OHCI device port on Alchemy
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com, Steve Longerbeam <stevel@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030507203127.U30468@luca.pas.lab>
References: <20030507203127.U30468@luca.pas.lab>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1052415629.558.91.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 08 May 2003 10:40:29 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2301
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips


On Wed, 2003-05-07 at 20:31, Jeff Baitis wrote:
> Out of curiousity:
> 
> Has anyone played with the AU1X00 USB device port yet? If not, what would you
> guys suggest that the AU1X00 appear as? USB over Ethernet? Or maybe a simple
> dummy device that will perform bulk transfers?

Steve wrote it, tried, knows all about it :)

Pete


From macro@ds2.pg.gda.pl Thu May  8 20:22:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 20:22:35 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:8659 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225239AbTEHTWa>; Thu, 8 May 2003 20:22:30 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA17767;
	Thu, 8 May 2003 21:21:41 +0200 (MET DST)
Date: Thu, 8 May 2003 21:21:41 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Guo Michael <michael_e_guo@hotmail.com>, linux-mips@linux-mips.org
Subject: Re: Which compiler should I use to make mips64 kernel
In-Reply-To: <20030506124029.GA2180@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030508211935.12320G-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2302
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 6 May 2003, Ralf Baechle wrote:

> > mips64el-linux-ld  -r -o kernel.o sched.o dma.o fork.o exec_domain.o 
> > panic.o printk.o module.o exit.o itimer.o info.o time.o softirq.o 
> > resource.o sysctl.o acct.o capability.o ptrace.o timer.o user.o signal.o 
> > sys.o kmod.o context.o ksyms.o
> > mips64el-linux-ld: BFD 2.13.2.1 assertion fail elflink.h:5117
> 
> This is a known but not yet fixed problem that only seems to hit certain
> kernel configurations; I believe it somehow tied to little endianess also.

 This patch makes ld work for the kernel regardless of the default
emulation (output format).  What do you think?

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

patch-mips-2.4.21-pre4-20030505-mips64-ld-oformat-0
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030505.macro/arch/mips64/Makefile linux-mips-2.4.21-pre4-20030505/arch/mips64/Makefile
--- linux-mips-2.4.21-pre4-20030505.macro/arch/mips64/Makefile	2003-02-27 03:56:44.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030505/arch/mips64/Makefile	2003-05-08 15:44:25.000000000 +0000
@@ -251,10 +251,20 @@ LINKFLAGS += -T arch/mips64/ld.script.el
 #LINKFLAGS += -T arch/mips64/ld.script.elf64
 endif
 
+ifdef CONFIG_CPU_LITTLE_ENDIAN
+32bit-bfd = elf32-tradlittlemips
+64bit-bfd = elf64-tradlittlemips
+else
+32bit-bfd = elf32-tradbigmips
+64bit-bfd = elf64-tradbigmips
+endif
+
 
 AFLAGS		+= $(GCCFLAGS)
 CFLAGS		+= $(GCCFLAGS)
 
+LD		+= --oformat $(32bit-bfd)
+
 
 LINKFLAGS += -Ttext $(LOADADDR)
 
@@ -266,12 +276,6 @@ LIBS := arch/mips64/lib/lib.a $(LIBS)
 
 MAKEBOOT = $(MAKE) -C arch/$(ARCH)/boot
 
-ifdef CONFIG_CPU_LITTLE_ENDIAN
-64bit-bfd = elf64-tradlittlemips
-else
-64bit-bfd = elf64-tradbigmips
-endif
-
 vmlinux: arch/mips64/ld.script.elf32
 arch/mips64/ld.script.elf32: arch/mips64/ld.script.elf32.S
 	$(CPP) -C -P -I$(HPATH) -imacros $(HPATH)/asm-mips64/sn/mapped_kernel.h -Umips arch/mips64/ld.script.elf32.S > arch/mips64/ld.script.elf32


From baitisj@idealab.com Thu May  8 22:15:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 22:15:06 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:985 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225239AbTEHVPD>;
	Thu, 8 May 2003 22:15:03 +0100
Received: (qmail 13177 invoked by uid 6180); 8 May 2003 21:14:58 -0000
Date: Thu, 8 May 2003 14:14:58 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: Yasushi SHOJI <yashi@atmark-techno.com>
Cc: linux-mips@linux-mips.org, stevel@mvista.com
Subject: Re: USB OHCI device port on Alchemy
Message-ID: <20030508141457.V30468@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030507203127.U30468@luca.pas.lab> <20030508065335.294643E4CC@dns1.atmark-techno.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030508065335.294643E4CC@dns1.atmark-techno.com>; from yashi@atmark-techno.com on Thu, May 08, 2003 at 03:53:34PM +0900
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2303
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

Ah, thanks Yashi, I didn't notice this since I was looking in the USB driver
directories ;)

Steve:

The option seems to be inactive in the kernel config; maybe this patch should
be applied? Or is there a reason why this option is inaccessible?

Thanks,

Jeff

Index: Config.in
===================================================================
RCS file: /home/cvs/linux/drivers/char/Attic/Config.in,v
retrieving revision 1.72.2.28
diff -u -r1.72.2.28 Config.in
--- Config.in   23 Apr 2003 00:23:24 -0000     1.72.2.28
+++ Config.in   8 May 2003 21:13:05 -0000
@@ -91,10 +91,11 @@
         if [ "$CONFIG_AU1X00_UART" = "y" ]; then
            bool '        Enable Au1x00 serial console' CONFIG_AU1X00_SERIAL_CONSOLE
          fi
+     bool '  Enable Au1x00 USB Device Support' CONFIG_AU1X00_USB_DEVICE
         if [ "$CONFIG_AU1X00_USB_DEVICE" = "y" ]; then
-           dep_tristate '  Au1x00 USB TTY Device support' CONFIG_AU1X00_USB_TTY $CONFIG_AU1X00_USB_DEVICE
+           dep_tristate '        Au1x00 USB TTY Device support' CONFIG_AU1X00_USB_TTY $CONFIG_AU1X00_USB_DEVICE
            if [ "$CONFIG_AU1000_USB_TTY" != "y" ]; then
-              dep_tristate '  Au1x00 USB Raw Device support' CONFIG_AU1X00_USB_RAW $CONFIG_AU1X00_USB_DEVICE
+              dep_tristate '        Au1x00 USB Raw Device support' CONFIG_AU1X00_USB_RAW $CONFIG_AU1X00_USB_DEVICE
            fi
          fi
       fi





On Thu, May 08, 2003 at 03:53:34PM +0900, Yasushi SHOJI wrote:
> At Wed, 7 May 2003 20:31:27 -0700,
> Jeff Baitis wrote:
> > 
> > Has anyone played with the AU1X00 USB device port yet? If not, what would you
> > guys suggest that the AU1X00 appear as? USB over Ethernet? Or maybe a simple
> > dummy device that will perform bulk transfers?
> 
> there are au1000_usbraw.c and au1000_usbtty.c in linux-mips.org's CVS
> under drivers/char.
> 
> I'd be excited to see usb storage driver for usb device.
> 
> as a related topic, does anyone know how usb gadget api is coming? I'm
> assuming that once usb gadget stabilized and people start using it,
> we'll be converting au1's usb dev driver to gadget api, no?
> 
> or people already working on it?
> --
>       yashi
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From stevel@mvista.com Thu May  8 22:21:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 22:21:37 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:51707 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225239AbTEHVVe>;
	Thu, 8 May 2003 22:21:34 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA02403;
	Thu, 8 May 2003 14:21:28 -0700
Message-ID: <3EBACA58.3050303@mvista.com>
Date: Thu, 08 May 2003 14:21:28 -0700
From: Steve Longerbeam <stevel@mvista.com>
Organization: MontaVista Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: baitisj@evolution.com
CC: Pete Popov <ppopov@mvista.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: USB OHCI device port on Alchemy
References: <20030507203127.U30468@luca.pas.lab> <1052415629.558.91.camel@zeus.mvista.com>
Content-Type: multipart/mixed;
 boundary="------------090100010504090006050707"
Return-Path: <stevel@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: 2304
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: stevel@mvista.com
Precedence: bulk
X-list: linux-mips


This is a multi-part message in MIME format.
--------------090100010504090006050707
Content-Type: multipart/alternative;
 boundary="------------070000070702080909070203"



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



Pete Popov wrote:

>On Wed, 2003-05-07 at 20:31, Jeff Baitis wrote:
>  
>
>>Out of curiousity:
>>
>>Has anyone played with the AU1X00 USB device port yet? If not, what would you
>>guys suggest that the AU1X00 appear as? USB over Ethernet? Or maybe a simple
>>dummy device that will perform bulk transfers?
>>    
>>
>
>Steve wrote it, tried, knows all about it :)
>

Hi Jeff,

Ok, so there's more interest in this driver than I expected, so I guess
it's high time I write some docs for it under Documentation/mips
somewhere.

In the meantime, attached are some instructions on how to use the TTY
function driver.

In answer to your questions, there is no USB over ethernet function
driver. But I did write a "raw" function driver that simply presents
a bulk IN and bulk OUT endpoint for raw bulk data transfer. I will
write up some instructions on that as well.

Steve

-- 
Steve Longerbeam
MontaVista Software, Inc.
office:408-328-9008, fax:408-328-3875
http://www.mvista.com



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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
<br>
<br>
Pete Popov wrote:<br>
<blockquote type="cite"
 cite="mid1052415629.558.91.camel@zeus.mvista.com">
  <pre wrap="">On Wed, 2003-05-07 at 20:31, Jeff Baitis wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Out of curiousity:

Has anyone played with the AU1X00 USB device port yet? If not, what would you
guys suggest that the AU1X00 appear as? USB over Ethernet? Or maybe a simple
dummy device that will perform bulk transfers?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Steve wrote it, tried, knows all about it :)</pre>
</blockquote>
<br>
Hi Jeff,<br>
<br>
Ok, so there's more interest in this driver than I expected, so I guess<br>
it's high time I write some docs for it under Documentation/mips<br>
somewhere.<br>
<br>
In the meantime, attached are some instructions on how to use the TTY<br>
function driver.<br>
<br>
In answer to your questions, there is no USB over ethernet function<br>
driver. But I did write a "raw" function driver that simply presents<br>
a bulk IN and bulk OUT endpoint for raw bulk data transfer. I will<br>
write up some instructions on that as well.<br>
<br>
Steve<br>
<br>
<pre class="moz-signature" cols="$mailwrapcol">-- 
Steve Longerbeam
MontaVista Software, Inc.
office:408-328-9008, fax:408-328-3875
<a class="moz-txt-link-freetext" href="http://www.mvista.com">http://www.mvista.com</a>
</pre>
<br>
</body>
</html>

--------------070000070702080909070203--

--------------090100010504090006050707
Content-Type: text/plain;
 name="au1x00_usbdev.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="au1x00_usbdev.txt"

Instructions for using the Au1x00 USB TTY Function driver
---------------------------------------------------------

Note: These instructions assume the use of a Pb1500 reference board
(Au1500) but should work with the Pb1000, Pb1100, and Db1x00
boards as well (but is untested on these boards).

Follow these steps:

1.   cp arch/mips/configs/defconfig-pb1500 .config
     make oldconfig
     make menuconfig
     (enable 'Au1000 USB TTY Device support' under char devices as built-in).
     make dep; make
     mips_fp_le-objcopy -O srec vmlinux /tftpboot/vmlinux.s3

2. Now you have a kernel with the Au1x00 USB device TTY driver
   support built-in. Boot a Pb1500 with this kernel.

3. Now you have a choice, you can use a PC as the USB host,
   or a Pb1x00. I have used both a PC and two Pb1500s side-by-side,
   one as the USB host and one as the TTY device. Remember that
   if you use another Pb1000/Pb1500 as the USB host, you'll need
   seperate NFS servers to provide two completely seperate root
   filesystems.

4. On the USB host, enable usbserial generic support as a module. Under
   "USB support -->", go to "USB Serial Converter support  --->" and
   enable "USB Serial Converter support" as a module, then enable
   "USB Generic Serial Driver".
   
5. Install the usbserial module on the host:

     insmod usbserial vendor=0x6d04 product=0x0bc0

6. Make sure you've got the usb TTY nodes on your host:

     mknod /dev/ttyUSB0 c 188 0
     mknod /dev/ttyUSB1 c 188 1

7. On the USB device, make the usb TTY device nodes:

     mknod /dev/ttyUSBdev0 c 189 0
     mknod /dev/ttyUSBdev1 c 189 1

8. Now you should be ready to connect host to device. You can
    tail -f /var/log/kern.log on both sides to watch the progress of
    communication on the control endpoint 0. When the device is
    configured, you should see something about "usbserial attached"
    on the host, and:

Jan  1 00:01:31 10 kernel: usbdev.c: do_setup: req 9 SET_CONFIGURATION
Jan  1 00:01:31 10 kernel: usbdev.c: set config, config=1

    on the device.

9. Now you can try actually communicating over the TTY ports. Try
    running minicom on both sides, the host minicom opens
    /dev/ttyUSB0, the device minicom opens /dev/ttyUSBdev0. Type
    into either minicom window and you should see the characters
    appear on the other side.

10. Try starting a getty login process on either side. On the host:

     getty ttyUSB0 &

     and on the device:

     getty ttyUSBdev0 &

     You should then see a login prompt in minicom on the opposite
     sides.

11. Try echoing strings to the other side:

     echo hello world > /dev/ttyUSB0    # hello world should appear in minicom on device-side

     echo hello world > /dev/ttyUSBdev0    # hello world should appear in minicom on host-side

12. You can try the above minicom/getty/echo tests on port 1, but last
    I checked, endpoints 4 and 5 (which make up port 1) were still
    having problems.

--------------090100010504090006050707--


From stevel@mvista.com Thu May  8 22:31:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 22:31:26 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:35575 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225239AbTEHVbY>;
	Thu, 8 May 2003 22:31:24 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA02783;
	Thu, 8 May 2003 14:31:16 -0700
Message-ID: <3EBACCA4.8030803@mvista.com>
Date: Thu, 08 May 2003 14:31:16 -0700
From: Steve Longerbeam <stevel@mvista.com>
Organization: MontaVista Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: baitisj@evolution.com
CC: Yasushi SHOJI <yashi@atmark-techno.com>, linux-mips@linux-mips.org,
	Pete Popov <ppopov@mvista.com>
Subject: Re: USB OHCI device port on Alchemy
References: <20030507203127.U30468@luca.pas.lab> <20030508065335.294643E4CC@dns1.atmark-techno.com> <20030508141457.V30468@luca.pas.lab>
Content-Type: multipart/mixed;
 boundary="------------010801020101030607050905"
Return-Path: <stevel@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: 2305
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: stevel@mvista.com
Precedence: bulk
X-list: linux-mips


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



Jeff Baitis wrote:

>Ah, thanks Yashi, I didn't notice this since I was looking in the USB driver
>directories ;)
>
>Steve:
>
>The option seems to be inactive in the kernel config; maybe this patch should
>be applied? Or is there a reason why this option is inaccessible?
>

Jeff, Yashi:

I wrote a similar patch to Yashi's. I've attached it.

Pete: have you applied this to linux-mips yet?


>
>On Thu, May 08, 2003 at 03:53:34PM +0900, Yasushi SHOJI wrote:
>  
>
>>At Wed, 7 May 2003 20:31:27 -0700,
>>Jeff Baitis wrote:
>>    
>>
>>>Has anyone played with the AU1X00 USB device port yet? If not, what would you
>>>guys suggest that the AU1X00 appear as? USB over Ethernet? Or maybe a simple
>>>dummy device that will perform bulk transfers?
>>>      
>>>
>>there are au1000_usbraw.c and au1000_usbtty.c in linux-mips.org's CVS
>>under drivers/char.
>>
>>I'd be excited to see usb storage driver for usb device.
>>
>>as a related topic, does anyone know how usb gadget api is coming? I'm
>>assuming that once usb gadget stabilized and people start using it,
>>we'll be converting au1's usb dev driver to gadget api, no?
>>

This is the first time I've heard of the gadget api, but I'd love to 
port the
au1x00 usb dev driver to a full-featured device-side protocol stack, as soon
as the community agrees on one.

When I wrote this driver, I implemented my own, very limited, device and
function api, as there still wasn't an accepted device-side api. But 
sounds like
maybe that will finally happen.

Steve


--------------010801020101030607050905
Content-Type: text/plain;
 name="au1000-usbd.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="au1000-usbd.patch"

Index: arch/mips/config.in
===================================================================
RCS file: /cvsdev/mvl-kernel/linux/arch/mips/config.in,v
retrieving revision 1.20.2.15
diff -u -r1.20.2.15 config.in
--- arch/mips/config.in	19 Feb 2003 11:34:46 -0000	1.20.2.15
+++ arch/mips/config.in	29 Apr 2003 21:56:12 -0000
@@ -391,7 +391,6 @@
    define_bool CONFIG_NONCOHERENT_IO y
    define_bool CONFIG_PC_KEYB y
    define_bool CONFIG_SWAP_IO_SPACE y
-   define_bool CONFIG_AU1000_USB_DEVICE y
 fi
 if [ "$CONFIG_MIPS_PB1500" = "y" ]; then
    define_bool CONFIG_MIPS_AU1000 y
Index: drivers/char/Config.in
===================================================================
RCS file: /cvsdev/mvl-kernel/linux/drivers/char/Config.in,v
retrieving revision 1.14.4.11
diff -u -r1.14.4.11 Config.in
--- drivers/char/Config.in	26 Mar 2003 03:51:58 -0000	1.14.4.11
+++ drivers/char/Config.in	29 Apr 2003 21:56:23 -0000
@@ -71,9 +71,13 @@
      if [ "$CONFIG_AU1000_UART" = "y" ]; then
          bool '        Enable Au1000 serial console' CONFIG_AU1000_SERIAL_CONSOLE
      fi
-     dep_tristate '  Au1000 USB TTY Device support' CONFIG_AU1000_USB_TTY $CONFIG_AU1000_USB_DEVICE
+     dep_tristate '  Au1000 USB TTY Device support' CONFIG_AU1000_USB_TTY $CONFIG_MIPS_AU1000
      if [ "$CONFIG_AU1000_USB_TTY" != "y" ]; then
-        dep_tristate '  Au1000 USB Raw Device support' CONFIG_AU1000_USB_RAW $CONFIG_AU1000_USB_DEVICE
+        dep_tristate '  Au1000 USB Raw Device support' CONFIG_AU1000_USB_RAW $CONFIG_MIPS_AU1000
+     fi
+     if [ "$CONFIG_AU1000_USB_TTY" != "n" -o \
+          "$CONFIG_AU1000_USB_RAW" != "n" ]; then
+	define_bool CONFIG_AU1000_USB_DEVICE y
      fi
      bool 'TXx927 SIO support' CONFIG_TXX927_SERIAL 
      if [ "$CONFIG_TXX927_SERIAL" = "y" ]; then

--------------010801020101030607050905--


From jbglaw@dvmwest.gt.owl.de Thu May  8 22:41:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 May 2003 22:41:03 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:56078 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225239AbTEHVlB>; Thu, 8 May 2003 22:41:01 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 62C654AB98; Thu,  8 May 2003 23:40:57 +0200 (CEST)
Date: Thu, 8 May 2003 23:40:57 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Message-ID: <20030508214057.GW27494@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <BAY1-F17fJpbi7Phnzi00006011@hotmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="0fs/EiH13ppNklOL"
Content-Disposition: inline
In-Reply-To: <BAY1-F17fJpbi7Phnzi00006011@hotmail.com>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2306
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


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

On Thu, 2003-05-08 10:02:54 -0700, Michael Anburaj <michaelanburaj@hotmail.=
com>
wrote in message <BAY1-F17fJpbi7Phnzi00006011@hotmail.com>:
> Hi JBG,
>=20
> The MIPS box (Atlas running YAMON) has a fixed IP address assigned by me.=
=20
> TFTP boot works fine. But this IP is held within the boot monitor program=
=20
> (YAMON).
>=20
> YAMON> set
[...]

That doesn't help you. This is yamon, it's not Linux:)

> Apart from the dynamic IP address assignment methods....
> Suggest me a method to communicate this value to the RAM resident Linux=
=20
> kernel. Or can I assign a fixed IP addredd by passing it as a parameter=
=20

Look at ./linux/net/ipv4/ipconfig.c

> when the linux kernel boots up? If so what is the syntax & please point m=
e=20

Yes.

> to the document that has this info. about passed parameter when booting t=
he=20

The source file is the document, syntax is described there, too.

> kernel.

Please answer under old emails, not above them.

HTH, JBG

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

--0fs/EiH13ppNklOL
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+us7pHb1edYOZ4bsRAut5AKCMN/pjF4/c5+dhg69PtmK76uQpzQCeLvz8
s9qUhSo6JFEI5YlBKqdECLg=
=cLea
-----END PGP SIGNATURE-----

--0fs/EiH13ppNklOL--

From baitisj@idealab.com Fri May  9 00:41:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 00:41:48 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:31449 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225239AbTEHXlg>;
	Fri, 9 May 2003 00:41:36 +0100
Received: (qmail 14689 invoked by uid 6180); 8 May 2003 23:41:34 -0000
Date: Thu, 8 May 2003 16:41:34 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: Steve Longerbeam <stevel@mvista.com>
Cc: Yasushi SHOJI <yashi@atmark-techno.com>, linux-mips@linux-mips.org,
	Pete Popov <ppopov@mvista.com>
Subject: Re: USB OHCI device port on Alchemy
Message-ID: <20030508164134.C30468@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030507203127.U30468@luca.pas.lab> <20030508065335.294643E4CC@dns1.atmark-techno.com> <20030508141457.V30468@luca.pas.lab> <3EBACCA4.8030803@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3EBACCA4.8030803@mvista.com>; from stevel@mvista.com on Thu, May 08, 2003 at 02:31:16PM -0700
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2307
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

All:

Steve's patch includes some configuration options that I missed. Make sure you
use his, not mine.

Sorry to cause confusion. I put his down below.

Thanks!

-Jeff

> Index: arch/mips/config.in
> ===================================================================
> RCS file: /cvsdev/mvl-kernel/linux/arch/mips/config.in,v
> retrieving revision 1.20.2.15
> diff -u -r1.20.2.15 config.in
> --- arch/mips/config.in	19 Feb 2003 11:34:46 -0000	1.20.2.15
> +++ arch/mips/config.in	29 Apr 2003 21:56:12 -0000
> @@ -391,7 +391,6 @@
>     define_bool CONFIG_NONCOHERENT_IO y
>     define_bool CONFIG_PC_KEYB y
>     define_bool CONFIG_SWAP_IO_SPACE y
> -   define_bool CONFIG_AU1000_USB_DEVICE y
>  fi
>  if [ "$CONFIG_MIPS_PB1500" = "y" ]; then
>     define_bool CONFIG_MIPS_AU1000 y
> Index: drivers/char/Config.in
> ===================================================================
> RCS file: /cvsdev/mvl-kernel/linux/drivers/char/Config.in,v
> retrieving revision 1.14.4.11
> diff -u -r1.14.4.11 Config.in
> --- drivers/char/Config.in	26 Mar 2003 03:51:58 -0000	1.14.4.11
> +++ drivers/char/Config.in	29 Apr 2003 21:56:23 -0000
> @@ -71,9 +71,13 @@
>       if [ "$CONFIG_AU1000_UART" = "y" ]; then
>           bool '        Enable Au1000 serial console' CONFIG_AU1000_SERIAL_CONSOLE
>       fi
> -     dep_tristate '  Au1000 USB TTY Device support' CONFIG_AU1000_USB_TTY $CONFIG_AU1000_USB_DEVICE
> +     dep_tristate '  Au1000 USB TTY Device support' CONFIG_AU1000_USB_TTY $CONFIG_MIPS_AU1000
>       if [ "$CONFIG_AU1000_USB_TTY" != "y" ]; then
> -        dep_tristate '  Au1000 USB Raw Device support' CONFIG_AU1000_USB_RAW $CONFIG_AU1000_USB_DEVICE
> +        dep_tristate '  Au1000 USB Raw Device support' CONFIG_AU1000_USB_RAW $CONFIG_MIPS_AU1000
> +     fi
> +     if [ "$CONFIG_AU1000_USB_TTY" != "n" -o \
> +          "$CONFIG_AU1000_USB_RAW" != "n" ]; then
> +	define_bool CONFIG_AU1000_USB_DEVICE y
>       fi
>       bool 'TXx927 SIO support' CONFIG_TXX927_SERIAL 
>       if [ "$CONFIG_TXX927_SERIAL" = "y" ]; then
On Thu, May 08, 2003 at 02:31:16PM -0700, Steve Longerbeam wrote:
> 
> 
> Jeff Baitis wrote:
> 
> >Ah, thanks Yashi, I didn't notice this since I was looking in the USB driver
> >directories ;)
> >
> >Steve:
> >
> >The option seems to be inactive in the kernel config; maybe this patch should
> >be applied? Or is there a reason why this option is inaccessible?
> >
> 
> Jeff, Yashi:
> 
> I wrote a similar patch to Yashi's. I've attached it.
> 
> Pete: have you applied this to linux-mips yet?
> 
> 
> >
> >On Thu, May 08, 2003 at 03:53:34PM +0900, Yasushi SHOJI wrote:
> >  
> >
> >>At Wed, 7 May 2003 20:31:27 -0700,
> >>Jeff Baitis wrote:
> >>    
> >>
> >>>Has anyone played with the AU1X00 USB device port yet? If not, what would you
> >>>guys suggest that the AU1X00 appear as? USB over Ethernet? Or maybe a simple
> >>>dummy device that will perform bulk transfers?
> >>>      
> >>>
> >>there are au1000_usbraw.c and au1000_usbtty.c in linux-mips.org's CVS
> >>under drivers/char.
> >>
> >>I'd be excited to see usb storage driver for usb device.
> >>
> >>as a related topic, does anyone know how usb gadget api is coming? I'm
> >>assuming that once usb gadget stabilized and people start using it,
> >>we'll be converting au1's usb dev driver to gadget api, no?
> >>
> 
> This is the first time I've heard of the gadget api, but I'd love to 
> port the
> au1x00 usb dev driver to a full-featured device-side protocol stack, as soon
> as the community agrees on one.
> 
> When I wrote this driver, I implemented my own, very limited, device and
> function api, as there still wasn't an accepted device-side api. But 
> sounds like
> maybe that will finally happen.
> 
> Steve
> 



-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From ppopov@mvista.com Fri May  9 00:43:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 00:43:43 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:49395 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225239AbTEHXnl>;
	Fri, 9 May 2003 00:43:41 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA21570;
	Thu, 8 May 2003 16:43:35 -0700
Subject: Re: USB OHCI device port on Alchemy
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com
Cc: Steve Longerbeam <stevel@mvista.com>,
	Yasushi SHOJI <yashi@atmark-techno.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030508164134.C30468@luca.pas.lab>
References: <20030507203127.U30468@luca.pas.lab>
	 <20030508065335.294643E4CC@dns1.atmark-techno.com>
	 <20030508141457.V30468@luca.pas.lab> <3EBACCA4.8030803@mvista.com>
	 <20030508164134.C30468@luca.pas.lab>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1052437426.558.119.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 08 May 2003 16:43:46 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2308
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips


I'll check it in later.

Pete

On Thu, 2003-05-08 at 16:41, Jeff Baitis wrote:
> All:
> 
> Steve's patch includes some configuration options that I missed. Make sure you
> use his, not mine.
> 
> Sorry to cause confusion. I put his down below.
> 
> Thanks!
> 
> -Jeff
> 
> > Index: arch/mips/config.in
> > ===================================================================
> > RCS file: /cvsdev/mvl-kernel/linux/arch/mips/config.in,v
> > retrieving revision 1.20.2.15
> > diff -u -r1.20.2.15 config.in
> > --- arch/mips/config.in	19 Feb 2003 11:34:46 -0000	1.20.2.15
> > +++ arch/mips/config.in	29 Apr 2003 21:56:12 -0000
> > @@ -391,7 +391,6 @@
> >     define_bool CONFIG_NONCOHERENT_IO y
> >     define_bool CONFIG_PC_KEYB y
> >     define_bool CONFIG_SWAP_IO_SPACE y
> > -   define_bool CONFIG_AU1000_USB_DEVICE y
> >  fi
> >  if [ "$CONFIG_MIPS_PB1500" = "y" ]; then
> >     define_bool CONFIG_MIPS_AU1000 y
> > Index: drivers/char/Config.in
> > ===================================================================
> > RCS file: /cvsdev/mvl-kernel/linux/drivers/char/Config.in,v
> > retrieving revision 1.14.4.11
> > diff -u -r1.14.4.11 Config.in
> > --- drivers/char/Config.in	26 Mar 2003 03:51:58 -0000	1.14.4.11
> > +++ drivers/char/Config.in	29 Apr 2003 21:56:23 -0000
> > @@ -71,9 +71,13 @@
> >       if [ "$CONFIG_AU1000_UART" = "y" ]; then
> >           bool '        Enable Au1000 serial console' CONFIG_AU1000_SERIAL_CONSOLE
> >       fi
> > -     dep_tristate '  Au1000 USB TTY Device support' CONFIG_AU1000_USB_TTY $CONFIG_AU1000_USB_DEVICE
> > +     dep_tristate '  Au1000 USB TTY Device support' CONFIG_AU1000_USB_TTY $CONFIG_MIPS_AU1000
> >       if [ "$CONFIG_AU1000_USB_TTY" != "y" ]; then
> > -        dep_tristate '  Au1000 USB Raw Device support' CONFIG_AU1000_USB_RAW $CONFIG_AU1000_USB_DEVICE
> > +        dep_tristate '  Au1000 USB Raw Device support' CONFIG_AU1000_USB_RAW $CONFIG_MIPS_AU1000
> > +     fi
> > +     if [ "$CONFIG_AU1000_USB_TTY" != "n" -o \
> > +          "$CONFIG_AU1000_USB_RAW" != "n" ]; then
> > +	define_bool CONFIG_AU1000_USB_DEVICE y
> >       fi
> >       bool 'TXx927 SIO support' CONFIG_TXX927_SERIAL 
> >       if [ "$CONFIG_TXX927_SERIAL" = "y" ]; then
> On Thu, May 08, 2003 at 02:31:16PM -0700, Steve Longerbeam wrote:
> > 
> > 
> > Jeff Baitis wrote:
> > 
> > >Ah, thanks Yashi, I didn't notice this since I was looking in the USB driver
> > >directories ;)
> > >
> > >Steve:
> > >
> > >The option seems to be inactive in the kernel config; maybe this patch should
> > >be applied? Or is there a reason why this option is inaccessible?
> > >
> > 
> > Jeff, Yashi:
> > 
> > I wrote a similar patch to Yashi's. I've attached it.
> > 
> > Pete: have you applied this to linux-mips yet?
> > 
> > 
> > >
> > >On Thu, May 08, 2003 at 03:53:34PM +0900, Yasushi SHOJI wrote:
> > >  
> > >
> > >>At Wed, 7 May 2003 20:31:27 -0700,
> > >>Jeff Baitis wrote:
> > >>    
> > >>
> > >>>Has anyone played with the AU1X00 USB device port yet? If not, what would you
> > >>>guys suggest that the AU1X00 appear as? USB over Ethernet? Or maybe a simple
> > >>>dummy device that will perform bulk transfers?
> > >>>      
> > >>>
> > >>there are au1000_usbraw.c and au1000_usbtty.c in linux-mips.org's CVS
> > >>under drivers/char.
> > >>
> > >>I'd be excited to see usb storage driver for usb device.
> > >>
> > >>as a related topic, does anyone know how usb gadget api is coming? I'm
> > >>assuming that once usb gadget stabilized and people start using it,
> > >>we'll be converting au1's usb dev driver to gadget api, no?
> > >>
> > 
> > This is the first time I've heard of the gadget api, but I'd love to 
> > port the
> > au1x00 usb dev driver to a full-featured device-side protocol stack, as soon
> > as the community agrees on one.
> > 
> > When I wrote this driver, I implemented my own, very limited, device and
> > function api, as there still wasn't an accepted device-side api. But 
> > sounds like
> > maybe that will finally happen.
> > 
> > Steve
> > 
> 
> 


From smills_ho@coventive.com Fri May  9 03:04:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 03:05:05 +0100 (BST)
Received: from [IPv6:::ffff:202.145.53.89] ([IPv6:::ffff:202.145.53.89]:29374
	"EHLO miao.coventive.com") by linux-mips.org with ESMTP
	id <S8225254AbTEICEx>; Fri, 9 May 2003 03:04:53 +0100
Received: from pc208 (PC208.ia.kh.coventive.com [192.168.23.208] (may be forged))
	by miao.coventive.com (8.11.6/8.11.6) with SMTP id h4924ex21902;
	Fri, 9 May 2003 10:04:43 +0800
Message-ID: <000a01c315cf$8171ac70$d017a8c0@pc208>
From: "smills_ho" <smills_ho@coventive.com>
To: "Linux/MIPS Development" <linux-mips@linux-mips.org>
Cc: <gcc@gcc.gnu.org>
References: <3EB0B329.9030603@ict.ac.cn> <16048.55936.346808.522687@cuddles.redhat.com> <3EB0DDC6.5080108@ict.ac.cn> <16048.57054.224964.883062@cuddles.redhat.com> <20030501085018.GA1885@greglaptop.attbi.com>
Subject: Problem of cross-mipsel-compiler GLIBC-2.3.X
Date: Fri, 9 May 2003 10:05:43 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <smills_ho@coventive.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2309
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: smills_ho@coventive.com
Precedence: bulk
X-list: linux-mips

Dear All,
    I want to make a cross-compilered glibc-2.3.x and I get the source from
ftp.gun.org. GCC version is 3.2.3, binutils is 2.13.2.1. The step is as
following:

1. Try to build binutils
2. Try to make static GCC
3. Try to make glibc -----> Then it is failed

Is there anybody know what's going on or somebody had successfully to build
the crossed glibc-2.3.x?

Thanks and best regs,


From michaelanburaj@hotmail.com Fri May  9 06:47:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 06:47:52 +0100 (BST)
Received: from bay1-f57.bay1.hotmail.com ([IPv6:::ffff:65.54.245.57]:16653
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225073AbTEIFrt>; Fri, 9 May 2003 06:47:49 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 8 May 2003 22:47:40 -0700
Received: from 4.35.224.219 by by1fd.bay1.hotmail.msn.com with HTTP;
	Fri, 09 May 2003 05:47:40 GMT
X-Originating-IP: [4.35.224.219]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: jbglaw@lug-owl.de, linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Thu, 08 May 2003 22:47:40 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F57ShEHR6jvPP600007b5b@hotmail.com>
X-OriginalArrivalTime: 09 May 2003 05:47:40.0939 (UTC) FILETIME=[8121EDB0:01C315EE]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2310
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi JBG,

I have passed a static IP address as parameter.

YAMON> go . nfsroot=4.42.102.7:/export/RedHat7.1 \
? ip=4.42.102.6:4.42.102.7:4.42.102.1:255.255.252.0

LINUX started...
Config serial console: ttyS0,115200
CPU revision is: 00018001
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 16kB 4-way, linesize 16 bytes.
Linux version 2.4.21-pre4 (root@localhost.localdomain) (gcc version 
egcs-2.91.63Determined physical RAM map:
memory: 00001000 @ 00000000 (reserved)
memory: 000ef000 @ 00001000 (ROM data)
memory: 00010000 @ 000f0000 (ROM data)
memory: 001a4000 @ 00100000 (reserved)
memory: 03d5c000 @ 002a4000 (usable)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: nfsroot=4.42.102.7:/export/RedHat7.1 
ip=4.42.102.6:4.42.100calculating r4koff... 00061a83(400003)
CPU frequency 80.00 MHz
Calibrating delay loop... 79.66 BogoMIPS
Memory: 62120k/62832k available (1308k kernel code, 712k reserved, 164k 
data, 1)Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware on host bus 0.
PCI: device 01:06.0 has unknown header type 7f, ignoring.
PCI: device 01:0b.0 has unknown header type 7f, ignoring.
PCI: device 01:0d.0 has unknown header type 7f, ignoring.
PCI: device 01:0f.0 has unknown header type 7f, ignoring.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ 
SERIAL_PCI edttyS00 at 0x1f000900 (irq = 0) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Found SAA9730 (PCI) at 0x10800000, irq 16.
SCSI subsystem driver Revision: 1.00
ncr53c8xx: at PCI bus 0, device 16, function 0
ncr53c8xx: 53c810a detected
ncr53c810a-0: rev 0x12 on pci bus 0 device 16 function 0 irq 17
ncr53c810a-0: ID 7, Fast-10, Parity Checking
scsi0 : ncr53c8xx-3.4.3b-20010512
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
IP-Config: Complete:
      device=eth0, addr=4.42.102.6, mask=255.255.252.0, gw=4.42.102.1,
     host=4.42.102.6, domain=, nis-domain=(none),
     bootserver=4.42.102.7, rootserver=4.42.102.7, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 4.42.102.7
Looking up port of RPC 100005/1 on 4.42.102.7
Root-NFS: Server returned error -13 while mounting /export/RedHat7.1
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00

Let me why NFS server is returning error -13.

Thanks,
-Mike.


>From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
>To: linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board
>Date: Thu, 8 May 2003 23:40:57 +0200
>
>On Thu, 2003-05-08 10:02:54 -0700, Michael Anburaj 
><michaelanburaj@hotmail.com>
>wrote in message <BAY1-F17fJpbi7Phnzi00006011@hotmail.com>:
> > Hi JBG,
> >
> > The MIPS box (Atlas running YAMON) has a fixed IP address assigned by 
>me.
> > TFTP boot works fine. But this IP is held within the boot monitor 
>program
> > (YAMON).
> >
> > YAMON> set
>[...]
>
>That doesn't help you. This is yamon, it's not Linux:)
>
> > Apart from the dynamic IP address assignment methods....
> > Suggest me a method to communicate this value to the RAM resident Linux
> > kernel. Or can I assign a fixed IP addredd by passing it as a parameter
>
>Look at ./linux/net/ipv4/ipconfig.c
>
> > when the linux kernel boots up? If so what is the syntax & please point 
>me
>
>Yes.
>
> > to the document that has this info. about passed parameter when booting 
>the
>
>The source file is the document, syntax is described there, too.
>
> > kernel.
>
>Please answer under old emails, not above them.
>
>HTH, JBG
>
>--
>    Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
>    "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen 
>Krieg
>     fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im 
>Irak!
>       ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
><< attach3 >>

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


From jinum@esntechnologies.co.in Fri May  9 06:54:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 06:54:27 +0100 (BST)
Received: from [IPv6:::ffff:202.125.80.34] ([IPv6:::ffff:202.125.80.34]:20745
	"EHLO mail.esn.activedirectory") by linux-mips.org with ESMTP
	id <S8225073AbTEIFyZ>; Fri, 9 May 2003 06:54:25 +0100
Received: by mail.esn.activedirectory with Internet Mail Service (5.5.2650.10)
	id <K3RTBJLV>; Fri, 9 May 2003 11:24:31 +0530
Message-ID: <AF572D578398634881E52418B28925670EFF20@mail.esn.activedirectory>
From: JinuM <jinum@esntechnologies.co.in>
To: linux-mips@linux-mips.org
Subject: open file in kernel mode
Date: Fri, 9 May 2003 11:24:25 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <jinum@esntechnologies.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: 2311
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jinum@esntechnologies.co.in
Precedence: bulk
X-list: linux-mips


Hi,

Can anyone help me with this simple problem.

I am trying to write a firmware loader driver. Instead of reading the
firmware as a buffer(predefined array)  we would like to read the firmware
from a file (say /root/firmware). Do we have some function which reads the
file contents in kernel mode.

-Jinu


From michaelanburaj@hotmail.com Fri May  9 07:31:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 07:31:42 +0100 (BST)
Received: from bay1-f19.bay1.hotmail.com ([IPv6:::ffff:65.54.245.19]:9740 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225073AbTEIGbk>;
	Fri, 9 May 2003 07:31:40 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 8 May 2003 23:31:31 -0700
Received: from 4.35.224.219 by by1fd.bay1.hotmail.msn.com with HTTP;
	Fri, 09 May 2003 06:31:31 GMT
X-Originating-IP: [4.35.224.219]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Thu, 08 May 2003 23:31:31 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F19KkLxFjjBsVV00007bcf@hotmail.com>
X-OriginalArrivalTime: 09 May 2003 06:31:31.0864 (UTC) FILETIME=[A1493980:01C315F4]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2312
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

more info...

clipping from Linux startup messages:
-----------------------------------------------------
Root-NFS: Server returned error -13 while mounting /tftpboot/4.42.102.6

clipping from /var/log/messages:
--------------------------------------------
May  8 19:54:42 localhost rpc.mountd: refused mount request from 4.42.102.6 
for
/tftpboot/4.42.102.6 (/): no export entry


Why is Linux (running on the MIPS board) trying '/tftpboot/4.42.102.6'. 
Should it not try '/export/RedHat7.1'

Please let me know what is missing or what I should do to get passed this 
issue.

-Mike.


>From: "Michael Anburaj" <michaelanburaj@hotmail.com>
>To: jbglaw@lug-owl.de, linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board
>Date: Thu, 08 May 2003 22:47:40 -0700
>
>Hi JBG,
>
>I have passed a static IP address as parameter.
>
>YAMON> go . nfsroot=4.42.102.7:/export/RedHat7.1 \
>? ip=4.42.102.6:4.42.102.7:4.42.102.1:255.255.252.0
>
>LINUX started...
>Config serial console: ttyS0,115200
>CPU revision is: 00018001
>Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 
>bytes.
>Primary data cache 16kB 4-way, linesize 16 bytes.
>Linux version 2.4.21-pre4 (root@localhost.localdomain) (gcc version 
>egcs-2.91.63Determined physical RAM map:
>memory: 00001000 @ 00000000 (reserved)
>memory: 000ef000 @ 00001000 (ROM data)
>memory: 00010000 @ 000f0000 (ROM data)
>memory: 001a4000 @ 00100000 (reserved)
>memory: 03d5c000 @ 002a4000 (usable)
>On node 0 totalpages: 16384
>zone(0): 16384 pages.
>zone(1): 0 pages.
>zone(2): 0 pages.
>Kernel command line: nfsroot=4.42.102.7:/export/RedHat7.1 
>ip=4.42.102.6:4.42.100calculating r4koff... 00061a83(400003)
>CPU frequency 80.00 MHz
>Calibrating delay loop... 79.66 BogoMIPS
>Memory: 62120k/62832k available (1308k kernel code, 712k reserved, 164k 
>data, 1)Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
>Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
>Mount cache hash table entries: 512 (order: 0, 4096 bytes)
>Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
>Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
>Checking for 'wait' instruction...  available.
>POSIX conformance testing by UNIFIX
>PCI: Probing PCI hardware on host bus 0.
>PCI: device 01:06.0 has unknown header type 7f, ignoring.
>PCI: device 01:0b.0 has unknown header type 7f, ignoring.
>PCI: device 01:0d.0 has unknown header type 7f, ignoring.
>PCI: device 01:0f.0 has unknown header type 7f, ignoring.
>Linux NET4.0 for Linux 2.4
>Based upon Swansea University Computer Society NET3.039
>Initializing RT netlink socket
>Starting kswapd
>pty: 256 Unix98 ptys configured
>Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ 
>SERIAL_PCI edttyS00 at 0x1f000900 (irq = 0) is a 16550A
>RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
>loop: loaded (max 8 devices)
>Found SAA9730 (PCI) at 0x10800000, irq 16.
>SCSI subsystem driver Revision: 1.00
>ncr53c8xx: at PCI bus 0, device 16, function 0
>ncr53c8xx: 53c810a detected
>ncr53c810a-0: rev 0x12 on pci bus 0 device 16 function 0 irq 17
>ncr53c810a-0: ID 7, Fast-10, Parity Checking
>scsi0 : ncr53c8xx-3.4.3b-20010512
>NET4: Linux TCP/IP 1.0 for NET4.0
>IP Protocols: ICMP, UDP, TCP, IGMP
>IP: routing cache hash table of 512 buckets, 4Kbytes
>TCP: Hash tables configured (established 4096 bind 4096)
>IP-Config: Complete:
>      device=eth0, addr=4.42.102.6, mask=255.255.252.0, gw=4.42.102.1,
>     host=4.42.102.6, domain=, nis-domain=(none),
>     bootserver=4.42.102.7, rootserver=4.42.102.7, rootpath=
>NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
>Looking up port of RPC 100003/2 on 4.42.102.7
>Looking up port of RPC 100005/1 on 4.42.102.7
>Root-NFS: Server returned error -13 while mounting /export/RedHat7.1
>VFS: Unable to mount root fs via NFS, trying floppy.
>VFS: Cannot open root device "" or 02:00
>Please append a correct "root=" boot option
>Kernel panic: VFS: Unable to mount root fs on 02:00
>
>Let me why NFS server is returning error -13.
>
>Thanks,
>-Mike.
>
>
>>From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
>>To: linux-mips@linux-mips.org
>>Subject: Re: Linux for MIPS Atlas 4Kc board
>>Date: Thu, 8 May 2003 23:40:57 +0200
>>
>>On Thu, 2003-05-08 10:02:54 -0700, Michael Anburaj 
>><michaelanburaj@hotmail.com>
>>wrote in message <BAY1-F17fJpbi7Phnzi00006011@hotmail.com>:
>> > Hi JBG,
>> >
>> > The MIPS box (Atlas running YAMON) has a fixed IP address assigned by 
>>me.
>> > TFTP boot works fine. But this IP is held within the boot monitor 
>>program
>> > (YAMON).
>> >
>> > YAMON> set
>>[...]
>>
>>That doesn't help you. This is yamon, it's not Linux:)
>>
>> > Apart from the dynamic IP address assignment methods....
>> > Suggest me a method to communicate this value to the RAM resident Linux
>> > kernel. Or can I assign a fixed IP addredd by passing it as a parameter
>>
>>Look at ./linux/net/ipv4/ipconfig.c
>>
>> > when the linux kernel boots up? If so what is the syntax & please point 
>>me
>>
>>Yes.
>>
>> > to the document that has this info. about passed parameter when booting 
>>the
>>
>>The source file is the document, syntax is described there, too.
>>
>> > kernel.
>>
>>Please answer under old emails, not above them.
>>
>>HTH, JBG
>>
>>--
>>    Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
>>    "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen 
>>Krieg
>>     fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im 
>>Irak!
>>       ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | 
>>TCPA));
>><< attach3 >>
>
>_________________________________________________________________
>Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
>http://join.msn.com/?page=features/junkmail
>
>

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


From echristo@redhat.com Fri May  9 08:21:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 08:21:40 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:12.150.115.133]:42769 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225073AbTEIHVh>;
	Fri, 9 May 2003 08:21:37 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id h497AqZ12039;
	Fri, 9 May 2003 03:10:52 -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 h497LKT10309;
	Fri, 9 May 2003 03:21:20 -0400
Received: from [192.168.123.164] (vpn50-8.rdu.redhat.com [172.16.50.8])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h497LAM10063;
	Fri, 9 May 2003 00:21:19 -0700
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X
From: Eric Christopher <echristo@redhat.com>
To: smills_ho <smills_ho@coventive.com>
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>, gcc@gcc.gnu.org
In-Reply-To: <000a01c315cf$8171ac70$d017a8c0@pc208>
References: <3EB0B329.9030603@ict.ac.cn>
	 <16048.55936.346808.522687@cuddles.redhat.com> <3EB0DDC6.5080108@ict.ac.cn>
	 <16048.57054.224964.883062@cuddles.redhat.com>
	 <20030501085018.GA1885@greglaptop.attbi.com>
	 <000a01c315cf$8171ac70$d017a8c0@pc208>
Content-Type: text/plain
Organization: 
Message-Id: <1052464867.2485.3.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 09 May 2003 00:21:07 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2313
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips

On Thu, 2003-05-08 at 19:05, smills_ho wrote:
> Dear All,
>     I want to make a cross-compilered glibc-2.3.x and I get the source from
> ftp.gun.org. GCC version is 3.2.3, binutils is 2.13.2.1. The step is as
> following:
> 
> 1. Try to build binutils
> 2. Try to make static GCC
> 3. Try to make glibc -----> Then it is failed
> 
> Is there anybody know what's going on or somebody had successfully to build
> the crossed glibc-2.3.x?

A host cross host compiler for linux systems is a little more involved
than this :)

However, I don't know where you went wrong since you really didn't
provide much in the way of information as to what you did or where it
failed.

-eric

-- 
Eric Christopher <echristo@redhat.com>


From kumba@gentoo.org Fri May  9 08:26:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 08:26:53 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.116]:30450 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225073AbTEIH0v>; Fri, 9 May 2003 08:26:51 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout01.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003))
 with ESMTP id <0HEL00MDGZBX1R@mtaout01.icomcast.net> for
 linux-mips@linux-mips.org; Fri, 09 May 2003 03:26:21 -0400 (EDT)
Date: Fri, 09 May 2003 03:29:10 -0400
From: Kumba <kumba@gentoo.org>
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X
In-reply-to: <1052464867.2485.3.camel@ghostwheel.sfbay.redhat.com>
To: linux-mips@linux-mips.org
Reply-to: kumba@gentoo.org
Message-id: <3EBB58C6.3070604@gentoo.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
References: <3EB0B329.9030603@ict.ac.cn>
 <16048.55936.346808.522687@cuddles.redhat.com> <3EB0DDC6.5080108@ict.ac.cn>
 <16048.57054.224964.883062@cuddles.redhat.com>
 <20030501085018.GA1885@greglaptop.attbi.com>
 <000a01c315cf$8171ac70$d017a8c0@pc208>
 <1052464867.2485.3.camel@ghostwheel.sfbay.redhat.com>
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: 2314
X-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

Oddly enough, I followed these basic steps and wound up with a working 
cross-compiler from sparc64 -> mipseb (Sun Blade 100 to mips 
big-endian).  Gcc nor glibc gave me any issues.....However, when I tried 
the same exact steps on i686, glibc complained about libgcc not being 
available, among other things.  It's got me baffled, but I'm not exactly 
complaining.  Currently, it's gcc-3.2.3 (propolice patched) + 
glibc-2.3.2 + binutils-2.13.90.0.20, which it'll get rebuilt for the new 
binutils 2.14.

--Kumba



Eric Christopher wrote:
> On Thu, 2003-05-08 at 19:05, smills_ho wrote:
> 
>>Dear All,
>>    I want to make a cross-compilered glibc-2.3.x and I get the source from
>>ftp.gun.org. GCC version is 3.2.3, binutils is 2.13.2.1. The step is as
>>following:
>>
>>1. Try to build binutils
>>2. Try to make static GCC
>>3. Try to make glibc -----> Then it is failed
>>
>>Is there anybody know what's going on or somebody had successfully to build
>>the crossed glibc-2.3.x?
> 
> 
> A host cross host compiler for linux systems is a little more involved
> than this :)
> 
> However, I don't know where you went wrong since you really didn't
> provide much in the way of information as to what you did or where it
> failed.
> 
> -eric
> 



From smills_ho@coventive.com Fri May  9 09:10:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 09:10:12 +0100 (BST)
Received: from [IPv6:::ffff:202.145.53.89] ([IPv6:::ffff:202.145.53.89]:42942
	"EHLO miao.coventive.com") by linux-mips.org with ESMTP
	id <S8225073AbTEIIKK>; Fri, 9 May 2003 09:10:10 +0100
Received: from pc208 (PC208.ia.kh.coventive.com [192.168.23.208] (may be forged))
	by miao.coventive.com (8.11.6/8.11.6) with SMTP id h4989sx22641;
	Fri, 9 May 2003 16:09:55 +0800
Message-ID: <001601c31602$86838de0$d017a8c0@pc208>
From: "smills_ho" <smills_ho@coventive.com>
To: "Eric Christopher" <echristo@redhat.com>
Cc: "Linux/MIPS Development" <linux-mips@linux-mips.org>,
	<gcc@gcc.gnu.org>
References: <3EB0B329.9030603@ict.ac.cn> <16048.55936.346808.522687@cuddles.redhat.com> <3EB0DDC6.5080108@ict.ac.cn> <16048.57054.224964.883062@cuddles.redhat.com> <20030501085018.GA1885@greglaptop.attbi.com> <000a01c315cf$8171ac70$d017a8c0@pc208> <1052464867.2485.3.camel@ghostwheel.sfbay.redhat.com>
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X
Date: Fri, 9 May 2003 16:10:59 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <smills_ho@coventive.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2315
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: smills_ho@coventive.com
Precedence: bulk
X-list: linux-mips

Dear Eric,
    I follow the step that provide by Bradley
http://www.ltc.com/~brad/mips/mipsel-linux-cross-toolchain-building.txt

Thanks and best regards

----- Original Message -----
From: "Eric Christopher" <echristo@redhat.com>
To: "smills_ho" <smills_ho@coventive.com>
Cc: "Linux/MIPS Development" <linux-mips@linux-mips.org>; <gcc@gcc.gnu.org>
Sent: Friday, May 09, 2003 3:21 PM
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X


> On Thu, 2003-05-08 at 19:05, smills_ho wrote:
> > Dear All,
> >     I want to make a cross-compilered glibc-2.3.x and I get the source
from
> > ftp.gun.org. GCC version is 3.2.3, binutils is 2.13.2.1. The step is as
> > following:
> >
> > 1. Try to build binutils
> > 2. Try to make static GCC
> > 3. Try to make glibc -----> Then it is failed
> >
> > Is there anybody know what's going on or somebody had successfully to
build
> > the crossed glibc-2.3.x?
>
> A host cross host compiler for linux systems is a little more involved
> than this :)
>
> However, I don't know where you went wrong since you really didn't
> provide much in the way of information as to what you did or where it
> failed.
>
> -eric
>
> --
> Eric Christopher <echristo@redhat.com>
>


From smills_ho@coventive.com Fri May  9 09:14:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 09:14:26 +0100 (BST)
Received: from [IPv6:::ffff:202.145.53.89] ([IPv6:::ffff:202.145.53.89]:43966
	"EHLO miao.coventive.com") by linux-mips.org with ESMTP
	id <S8225073AbTEIIOY>; Fri, 9 May 2003 09:14:24 +0100
Received: from pc208 (PC208.ia.kh.coventive.com [192.168.23.208] (may be forged))
	by miao.coventive.com (8.11.6/8.11.6) with SMTP id h498E8x22657;
	Fri, 9 May 2003 16:14:10 +0800
Message-ID: <001f01c31603$1ed7fbd0$d017a8c0@pc208>
From: "smills_ho" <smills_ho@coventive.com>
To: <kumba@gentoo.org>, <linux-mips@linux-mips.org>
References: <3EB0B329.9030603@ict.ac.cn> <16048.55936.346808.522687@cuddles.redhat.com> <3EB0DDC6.5080108@ict.ac.cn> <16048.57054.224964.883062@cuddles.redhat.com> <20030501085018.GA1885@greglaptop.attbi.com> <000a01c315cf$8171ac70$d017a8c0@pc208> <1052464867.2485.3.camel@ghostwheel.sfbay.redhat.com> <3EBB58C6.3070604@gentoo.org>
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X
Date: Fri, 9 May 2003 16:15:12 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <smills_ho@coventive.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2316
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: smills_ho@coventive.com
Precedence: bulk
X-list: linux-mips

Dear Kumba,
    Should we try this binutils-2.13.90.0.20?
We try the version binutils-2.13.90.0.18 (Debian used) and it is failed on
cross-gcc step :-(

Thanks and best regards,

----- Original Message -----
From: "Kumba" <kumba@gentoo.org>
To: <linux-mips@linux-mips.org>
Sent: Friday, May 09, 2003 3:29 PM
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X


> Oddly enough, I followed these basic steps and wound up with a working
> cross-compiler from sparc64 -> mipseb (Sun Blade 100 to mips
> big-endian).  Gcc nor glibc gave me any issues.....However, when I tried
> the same exact steps on i686, glibc complained about libgcc not being
> available, among other things.  It's got me baffled, but I'm not exactly
> complaining.  Currently, it's gcc-3.2.3 (propolice patched) +
> glibc-2.3.2 + binutils-2.13.90.0.20, which it'll get rebuilt for the new
> binutils 2.14.
>
> --Kumba
>
>
>
> Eric Christopher wrote:
> > On Thu, 2003-05-08 at 19:05, smills_ho wrote:
> >
> >>Dear All,
> >>    I want to make a cross-compilered glibc-2.3.x and I get the source
from
> >>ftp.gun.org. GCC version is 3.2.3, binutils is 2.13.2.1. The step is as
> >>following:
> >>
> >>1. Try to build binutils
> >>2. Try to make static GCC
> >>3. Try to make glibc -----> Then it is failed
> >>
> >>Is there anybody know what's going on or somebody had successfully to
build
> >>the crossed glibc-2.3.x?
> >
> >
> > A host cross host compiler for linux systems is a little more involved
> > than this :)
> >
> > However, I don't know where you went wrong since you really didn't
> > provide much in the way of information as to what you did or where it
> > failed.
> >
> > -eric
> >
>
>


From jbglaw@dvmwest.gt.owl.de Fri May  9 09:25:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 09:25:36 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:56849 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225073AbTEIIZe>; Fri, 9 May 2003 09:25:34 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 231E84ABA6; Fri,  9 May 2003 10:25:30 +0200 (CEST)
Date: Fri, 9 May 2003 10:25:30 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Message-ID: <20030509082529.GX27494@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <BAY1-F19KkLxFjjBsVV00007bcf@hotmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="EEnv9zyGND1dPpWR"
Content-Disposition: inline
In-Reply-To: <BAY1-F19KkLxFjjBsVV00007bcf@hotmail.com>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2317
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


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

On Thu, 2003-05-08 23:31:31 -0700, Michael Anburaj <michaelanburaj@hotmail.=
com>
wrote in message <BAY1-F19KkLxFjjBsVV00007bcf@hotmail.com>:
> more info...
>=20
> clipping from Linux startup messages:
> -----------------------------------------------------
> Root-NFS: Server returned error -13 while mounting /tftpboot/4.42.102.6
>=20
> clipping from /var/log/messages:
> --------------------------------------------
> May  8 19:54:42 localhost rpc.mountd: refused mount request from 4.42.102=
.6=20
> for
> /tftpboot/4.42.102.6 (/): no export entry
>=20
>=20
> Why is Linux (running on the MIPS board) trying '/tftpboot/4.42.102.6'.=
=20
> Should it not try '/export/RedHat7.1'

See ./linux/fs/nfs/nfsroot.c for this. ...and please, answer _under_ an
old email and remove anything you no longer directly reply to.

MfG, JBG

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

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

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

iD8DBQE+u2X5Hb1edYOZ4bsRAqmsAJ9JQniqqjjiJXvagWs3wEmJ4ZH4LQCdFpJn
ULk4cLBoelAAkdv5S1FeGv0=
=QRIZ
-----END PGP SIGNATURE-----

--EEnv9zyGND1dPpWR--

From kumba@gentoo.org Fri May  9 09:28:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 09:28:17 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.115]:43968 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225073AbTEII2N>; Fri, 9 May 2003 09:28:13 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout02.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003))
 with ESMTP id <0HEM00DMV25H73@mtaout02.icomcast.net> for
 linux-mips@linux-mips.org; Fri, 09 May 2003 04:27:17 -0400 (EDT)
Date: Fri, 09 May 2003 04:30:06 -0400
From: Kumba <kumba@gentoo.org>
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X
In-reply-to: <001f01c31603$1ed7fbd0$d017a8c0@pc208>
To: linux-mips@linux-mips.org
Reply-to: kumba@gentoo.org
Message-id: <3EBB670E.4020200@gentoo.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
References: <3EB0B329.9030603@ict.ac.cn>
 <16048.55936.346808.522687@cuddles.redhat.com> <3EB0DDC6.5080108@ict.ac.cn>
 <16048.57054.224964.883062@cuddles.redhat.com>
 <20030501085018.GA1885@greglaptop.attbi.com>
 <000a01c315cf$8171ac70$d017a8c0@pc208>
 <1052464867.2485.3.camel@ghostwheel.sfbay.redhat.com>
 <3EBB58C6.3070604@gentoo.org> <001f01c31603$1ed7fbd0$d017a8c0@pc208>
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: 2318
X-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


	I'm not quite sure.  I don't see how trying it could hurt, maybe it 
will work, maybe it won't.  Although, 2.14.90.0.1 was just released as 
well, you might try that, or even CVS Head, as I heard that includes 
last-minute mips fixes.  I'm fairly new to the whole cross-compiler 
thing myself, and recently discovered the HOWTO mentioned in your 
previous mail, which I'm looking at to try and get an i686->mips 
cross-compiler going.  For now though, my sparc->mips cross-compiler 
works, so it's what I'll rely on the most.

--Kumba


smills_ho wrote:
> Dear Kumba,
>     Should we try this binutils-2.13.90.0.20?
> We try the version binutils-2.13.90.0.18 (Debian used) and it is failed on
> cross-gcc step :-(
> 
> Thanks and best regards,
> 
> ----- Original Message -----
> From: "Kumba" <kumba@gentoo.org>
> To: <linux-mips@linux-mips.org>
> Sent: Friday, May 09, 2003 3:29 PM
> Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X
> 
> 
> 
>>Oddly enough, I followed these basic steps and wound up with a working
>>cross-compiler from sparc64 -> mipseb (Sun Blade 100 to mips
>>big-endian).  Gcc nor glibc gave me any issues.....However, when I tried
>>the same exact steps on i686, glibc complained about libgcc not being
>>available, among other things.  It's got me baffled, but I'm not exactly
>>complaining.  Currently, it's gcc-3.2.3 (propolice patched) +
>>glibc-2.3.2 + binutils-2.13.90.0.20, which it'll get rebuilt for the new
>>binutils 2.14.
>>
>>--Kumba
>>
>>
>>
>>Eric Christopher wrote:
>>
>>>On Thu, 2003-05-08 at 19:05, smills_ho wrote:
>>>
>>>
>>>>Dear All,
>>>>   I want to make a cross-compilered glibc-2.3.x and I get the source
> 
> from
> 
>>>>ftp.gun.org. GCC version is 3.2.3, binutils is 2.13.2.1. The step is as
>>>>following:
>>>>
>>>>1. Try to build binutils
>>>>2. Try to make static GCC
>>>>3. Try to make glibc -----> Then it is failed
>>>>
>>>>Is there anybody know what's going on or somebody had successfully to
> 
> build
> 
>>>>the crossed glibc-2.3.x?
>>>
>>>
>>>A host cross host compiler for linux systems is a little more involved
>>>than this :)
>>>
>>>However, I don't know where you went wrong since you really didn't
>>>provide much in the way of information as to what you did or where it
>>>failed.
>>>
>>>-eric
>>>
>>
>>
> 
> 
> 



From smills_ho@coventive.com Fri May  9 10:40:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 10:40:18 +0100 (BST)
Received: from [IPv6:::ffff:202.145.53.89] ([IPv6:::ffff:202.145.53.89]:45246
	"EHLO miao.coventive.com") by linux-mips.org with ESMTP
	id <S8225073AbTEIJkP>; Fri, 9 May 2003 10:40:15 +0100
Received: from pc208 (PC208.ia.kh.coventive.com [192.168.23.208] (may be forged))
	by miao.coventive.com (8.11.6/8.11.6) with SMTP id h499dsx22809;
	Fri, 9 May 2003 17:39:56 +0800
Message-ID: <000401c3160f$1a087bf0$d017a8c0@pc208>
From: "smills_ho" <smills_ho@coventive.com>
To: <kumba@gentoo.org>, <linux-mips@linux-mips.org>
References: <3EB0B329.9030603@ict.ac.cn> <16048.55936.346808.522687@cuddles.redhat.com> <3EB0DDC6.5080108@ict.ac.cn> <16048.57054.224964.883062@cuddles.redhat.com> <20030501085018.GA1885@greglaptop.attbi.com> <000a01c315cf$8171ac70$d017a8c0@pc208> <1052464867.2485.3.camel@ghostwheel.sfbay.redhat.com> <3EBB58C6.3070604@gentoo.org> <001f01c31603$1ed7fbd0$d017a8c0@pc208> <3EBB670E.4020200@gentoo.org>
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X
Date: Fri, 9 May 2003 17:40:58 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <smills_ho@coventive.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2319
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: smills_ho@coventive.com
Precedence: bulk
X-list: linux-mips

Dear Kumba,

    After try several versions of binutils and glibc , it works in crossing
XFree86 4.2.1.
binutils 2.13.2.1 + gcc 3.2.3 + glibc 2.3.2
and some patchs come from debian's packages ( binutils 2.13.90.0.18 ,
gcc-3.2.1,glibc-2.3.1)

Thanks and best regards,

Smills_ho

----- Original Message -----
From: "Kumba" <kumba@gentoo.org>
To: <linux-mips@linux-mips.org>
Sent: Friday, May 09, 2003 4:30 PM
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X


>
> I'm not quite sure.  I don't see how trying it could hurt, maybe it
> will work, maybe it won't.  Although, 2.14.90.0.1 was just released as
> well, you might try that, or even CVS Head, as I heard that includes
> last-minute mips fixes.  I'm fairly new to the whole cross-compiler
> thing myself, and recently discovered the HOWTO mentioned in your
> previous mail, which I'm looking at to try and get an i686->mips
> cross-compiler going.  For now though, my sparc->mips cross-compiler
> works, so it's what I'll rely on the most.
>
> --Kumba
>
>
> smills_ho wrote:
> > Dear Kumba,
> >     Should we try this binutils-2.13.90.0.20?
> > We try the version binutils-2.13.90.0.18 (Debian used) and it is failed
on
> > cross-gcc step :-(
> >
> > Thanks and best regards,
> >
> > ----- Original Message -----
> > From: "Kumba" <kumba@gentoo.org>
> > To: <linux-mips@linux-mips.org>
> > Sent: Friday, May 09, 2003 3:29 PM
> > Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X
> >
> >
> >
> >>Oddly enough, I followed these basic steps and wound up with a working
> >>cross-compiler from sparc64 -> mipseb (Sun Blade 100 to mips
> >>big-endian).  Gcc nor glibc gave me any issues.....However, when I tried
> >>the same exact steps on i686, glibc complained about libgcc not being
> >>available, among other things.  It's got me baffled, but I'm not exactly
> >>complaining.  Currently, it's gcc-3.2.3 (propolice patched) +
> >>glibc-2.3.2 + binutils-2.13.90.0.20, which it'll get rebuilt for the new
> >>binutils 2.14.
> >>
> >>--Kumba
> >>
> >>
> >>
> >>Eric Christopher wrote:
> >>
> >>>On Thu, 2003-05-08 at 19:05, smills_ho wrote:
> >>>
> >>>
> >>>>Dear All,
> >>>>   I want to make a cross-compilered glibc-2.3.x and I get the source
> >
> > from
> >
> >>>>ftp.gun.org. GCC version is 3.2.3, binutils is 2.13.2.1. The step is
as
> >>>>following:
> >>>>
> >>>>1. Try to build binutils
> >>>>2. Try to make static GCC
> >>>>3. Try to make glibc -----> Then it is failed
> >>>>
> >>>>Is there anybody know what's going on or somebody had successfully to
> >
> > build
> >
> >>>>the crossed glibc-2.3.x?
> >>>
> >>>
> >>>A host cross host compiler for linux systems is a little more involved
> >>>than this :)
> >>>
> >>>However, I don't know where you went wrong since you really didn't
> >>>provide much in the way of information as to what you did or where it
> >>>failed.
> >>>
> >>>-eric
> >>>
> >>
> >>
> >
> >
> >
>
>


From agx@sigxcpu.org Fri May  9 12:23:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 12:23:57 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:56511
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225262AbTEILXy>; Fri, 9 May 2003 12:23:54 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 1EDCA2BC3A
	for <linux-mips@linux-mips.org>; Fri,  9 May 2003 13:23:52 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 17626-06
 for <linux-mips@linux-mips.org>; Fri,  9 May 2003 13:23:51 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 082FB2BC39
	for <linux-mips@linux-mips.org>; Fri,  9 May 2003 13:23:51 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id D446D1735D; Fri,  9 May 2003 13:20:14 +0200 (CEST)
Date: Fri, 9 May 2003 13:20:14 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X
Message-ID: <20030509112014.GC30563@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <3EB0B329.9030603@ict.ac.cn> <16048.55936.346808.522687@cuddles.redhat.com> <3EB0DDC6.5080108@ict.ac.cn> <16048.57054.224964.883062@cuddles.redhat.com> <20030501085018.GA1885@greglaptop.attbi.com> <000a01c315cf$8171ac70$d017a8c0@pc208> <1052464867.2485.3.camel@ghostwheel.sfbay.redhat.com> <3EBB58C6.3070604@gentoo.org> <001f01c31603$1ed7fbd0$d017a8c0@pc208> <3EBB670E.4020200@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EBB670E.4020200@gentoo.org>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2320
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Fri, May 09, 2003 at 04:30:06AM -0400, Kumba wrote:
> will work, maybe it won't.  Although, 2.14.90.0.1 was just released as 
> well, you might try that, or even CVS Head, as I heard that includes 
> last-minute mips fixes.  I'm fairly new to the whole cross-compiler 
I needed 2.14.90.0.1 to get the glibc testcases build right. Without
them I had lot's of unresolded "__libc_global_ctors" among others which
looked like a symbol visibility problem. 
Regards,
 -- Guido

From Yasushi.SHOJI@atmark-techno.com Fri May  9 14:37:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 14:37:07 +0100 (BST)
Received: from dns1.atmark-techno.com ([IPv6:::ffff:61.199.192.114]:10760 "EHLO
	dns1.atmark-techno.com") by linux-mips.org with ESMTP
	id <S8225262AbTEINhF>; Fri, 9 May 2003 14:37:05 +0100
Received: from wat.atmark-techno.com (unknown [192.168.10.81])
	by dns1.atmark-techno.com (Postfix) with ESMTP
	id B71AF3E4CC; Fri,  9 May 2003 22:36:59 +0900 (JST)
Date: Fri, 09 May 2003 22:36:59 +0900
From: Yasushi SHOJI <yashi@atmark-techno.com>
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: [PATCH] typo fix for au1's pcmcia debugging code
User-Agent: User-Agent: Wanderlust/2.10.0
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: multipart/mixed;
 boundary="Multipart_Fri_May__9_22:36:59_2003-1"
Message-Id: <20030509133659.B71AF3E4CC@dns1.atmark-techno.com>
Return-Path: <Yasushi.SHOJI@atmark-techno.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2321
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yashi@atmark-techno.com
Precedence: bulk
X-list: linux-mips

--Multipart_Fri_May__9_22:36:59_2003-1
Content-Type: text/plain; charset=US-ASCII

Hi Pete,

this is just a quick typo fix patch for current 2.4 branch on
linux-mips.org.

I'm assuming that the original code was intended to use macro
`DEBUG()' defined in cs_internal.h.

and macro `DEBUG()' requires `int pc_debug' declared somewhere.

Hope I'm not misunderstanding anything.

regards,
--
       yashi

--Multipart_Fri_May__9_22:36:59_2003-1
Content-Type: text/plain; type=patch; charset=US-ASCII
Content-Disposition: attachment; filename="pcmcia-debug.patch"
Content-Transfer-Encoding: base64

SW5kZXg6IGRyaXZlcnMvcGNtY2lhL2F1MTAwMF9kYjF4MDAuYwo9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJD
UyBmaWxlOiAvaG9tZS9jdnMvbGludXgvZHJpdmVycy9wY21jaWEvQXR0aWMvYXUxMDAwX2Ri
MXgwMC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEuMi4yCmRpZmYgLXUgLXIxLjEuMi4y
IGF1MTAwMF9kYjF4MDAuYwotLS0gZHJpdmVycy9wY21jaWEvYXUxMDAwX2RiMXgwMC5jCTcg
SmFuIDIwMDMgMTA6NDE6MzAgLTAwMDAJMS4xLjIuMgorKysgZHJpdmVycy9wY21jaWEvYXUx
MDAwX2RiMXgwMC5jCTkgTWF5IDIwMDMgMDk6MzE6MzIgLTAwMDAKQEAgLTk0LDggKzk0LDgg
QEAKIAkJaW5zZXJ0ZWQgPSAhKGJjc3ItPnN0YXR1cyAmICgxPDw1KSk7CiAJfQogCi0JREVC
VUcoS0VSTl9ERUJVRyAiZGIxeDAwIHNvY2tldCAlZDogaW5zZXJ0ZWQgJWQsIHZzICVkXG4i
LCAKLQkJCXNvY2ssIGluc2VydGVkLCB2cyk7CisJREVCVUcoMywgImRiMXgwMCBzb2NrZXQg
JWQ6IGluc2VydGVkICVkLCB2cyAlZFxuIiwKKyAgICAgICAgICAgICAgc29jaywgaW5zZXJ0
ZWQsIHZzKTsKIAogCWlmIChpbnNlcnRlZCkgewogCQlzd2l0Y2ggKHZzKSB7CkBAIC0xNjEs
OCArMTYxLDggQEAKIAogCWlmKHNvY2sgPiBQQ01DSUFfTUFYX1NPQ0spIHJldHVybiAtMTsK
IAotCURFQlVHKEtFUk5fREVCVUcgInNvY2tldCAlZCBWY2MgJWRWIFZwcCAlZFYsIHJlc2V0
ICVkXG4iLCAKLQkJCXNvY2ssIGNvbmZpZ3VyZS0+dmNjLCBjb25maWd1cmUtPnZwcCwgY29u
ZmlndXJlLT5yZXNldCk7CisJREVCVUcoMywgInNvY2tldCAlZCBWY2MgJWRWIFZwcCAlZFYs
IHJlc2V0ICVkXG4iLCAKKyAgICAgICAgICAgICAgc29jaywgY29uZmlndXJlLT52Y2MsIGNv
bmZpZ3VyZS0+dnBwLCBjb25maWd1cmUtPnJlc2V0KTsKIAogCS8qIHBjbWNpYSByZWcgd2Fz
IHNldCB0byB6ZXJvIGF0IGluaXQgdGltZS4gQmUgY2FyZWZ1bCB3aGVuCiAJICogaW5pdGlh
bGl6aW5nIGEgc29ja2V0IG5vdCB0byB3aXBlIG91dCB0aGUgc2V0dGluZ3Mgb2YgdGhlIApJ
bmRleDogZHJpdmVycy9wY21jaWEvYXUxMDAwX2dlbmVyaWMuYwo9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJD
UyBmaWxlOiAvaG9tZS9jdnMvbGludXgvZHJpdmVycy9wY21jaWEvYXUxMDAwX2dlbmVyaWMu
Yyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4zLjIuOQpkaWZmIC11IC1yMS4zLjIuOSBhdTEw
MDBfZ2VuZXJpYy5jCi0tLSBkcml2ZXJzL3BjbWNpYS9hdTEwMDBfZ2VuZXJpYy5jCTEzIE1h
ciAyMDAzIDAwOjA0OjQ4IC0wMDAwCTEuMy4yLjkKKysrIGRyaXZlcnMvcGNtY2lhL2F1MTAw
MF9nZW5lcmljLmMJOSBNYXkgMjAwMyAwOTozMTozMiAtMDAwMApAQCAtNTYsNyArNTYsNyBA
QAogI2luY2x1ZGUgPGFzbS9hdTEwMDBfcGNtY2lhLmg+CiAKICNpZmRlZiBQQ01DSUFfREVC
VUcKLXN0YXRpYyBpbnQgcGNfZGVidWc7CitpbnQgcGNfZGVidWcgPSBQQ01DSUFfREVCVUc7
CiAjZW5kaWYKIAogTU9EVUxFX0xJQ0VOU0UoIkdQTCIpOwpJbmRleDogZHJpdmVycy9wY21j
aWEvYXUxMDAwX3BiMXgwMC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL2N2cy9s
aW51eC9kcml2ZXJzL3BjbWNpYS9hdTEwMDBfcGIxeDAwLmMsdgpyZXRyaWV2aW5nIHJldmlz
aW9uIDEuMS4yLjMKZGlmZiAtdSAtcjEuMS4yLjMgYXUxMDAwX3BiMXgwMC5jCi0tLSBkcml2
ZXJzL3BjbWNpYS9hdTEwMDBfcGIxeDAwLmMJMTMgTWFyIDIwMDMgMDA6MDQ6NDggLTAwMDAJ
MS4xLjIuMworKysgZHJpdmVycy9wY21jaWEvYXUxMDAwX3BiMXgwMC5jCTkgTWF5IDIwMDMg
MDk6MzE6MzMgLTAwMDAKQEAgLTIxOSw4ICsyMTksOCBAQAogCX0KIAogCXBjciAmPSB+UENS
X1NMT1RfMF9SU1Q7Ci0JREVCVUcoS0VSTl9JTkZPICJWY2MgJWRWIFZwcCAlZFYsIHBjciAl
eFxuIiwgCi0JCQljb25maWd1cmUtPnZjYywgY29uZmlndXJlLT52cHAsIHBjcik7CisJREVC
VUcoMywgIlZjYyAlZFYgVnBwICVkViwgcGNyICV4XG4iLAorICAgICAgICAgICAgICBjb25m
aWd1cmUtPnZjYywgY29uZmlndXJlLT52cHAsIHBjcik7CiAJc3dpdGNoKGNvbmZpZ3VyZS0+
dmNjKXsKIAkJY2FzZSAwOiAgLyogVmNjIDAgKi8KIAkJCXN3aXRjaChjb25maWd1cmUtPnZw
cCkgewpAQCAtMzMwLDggKzMzMCw4IEBACiAKIAlwY3IgPSBhdV9yZWFkdyhQQ01DSUFfQk9B
UkRfUkVHKSAmIH4weGY7CiAKLQlERUJVRyhLRVJOX0lORk8gIlZjYyAlZFYgVnBwICVkViwg
cGNyICV4LCByZXNldCAlZFxuIiwgCi0JCQljb25maWd1cmUtPnZjYywgY29uZmlndXJlLT52
cHAsIHBjciwgY29uZmlndXJlLT5yZXNldCk7CisJREVCVUcoMywgIlZjYyAlZFYgVnBwICVk
ViwgcGNyICV4LCByZXNldCAlZFxuIiwgCisgICAgICAgICAgICAgIGNvbmZpZ3VyZS0+dmNj
LCBjb25maWd1cmUtPnZwcCwgcGNyLCBjb25maWd1cmUtPnJlc2V0KTsKIAogCiAJc3dpdGNo
KGNvbmZpZ3VyZS0+dmNjKXsK

--Multipart_Fri_May__9_22:36:59_2003-1--

From brad@parker.boston.ma.us Fri May  9 14:37:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 14:37:28 +0100 (BST)
Received: from h0000c06cf87e.ne.client2.attbi.com ([IPv6:::ffff:24.147.212.21]:17157
	"EHLO compaq.parker.boston.ma.us") by linux-mips.org with ESMTP
	id <S8225265AbTEINhW>; Fri, 9 May 2003 14:37:22 +0100
Received: from p2.parker.boston.ma.us (p2 [192.245.5.16])
	by compaq.parker.boston.ma.us (8.11.6/8.11.6) with ESMTP id h49DbEH05340;
	Fri, 9 May 2003 09:37:15 -0400
Received: from p2 (brad@localhost)
	by p2.parker.boston.ma.us (8.11.6/8.11.6) with ESMTP id h49DbEL17415;
	Fri, 9 May 2003 09:37:14 -0400
Message-Id: <200305091337.h49DbEL17415@p2.parker.boston.ma.us>
From: Brad Parker <brad@heeltoe.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
cc: baitisj@evolution.com
Subject: Re: USB OHCI device port on Alchemy 
In-Reply-To: Message from Pete Popov <ppopov@mvista.com> 
   of "08 May 2003 10:40:29 PDT." <1052415629.558.91.camel@zeus.mvista.com> 
Organization: Heeltoe Consulting
X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 20.7.1
Date: Fri, 09 May 2003 09:37:14 -0400
Return-Path: <brad@parker.boston.ma.us>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2322
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brad@heeltoe.com
Precedence: bulk
X-list: linux-mips


>On Wed, 2003-05-07 at 20:31, Jeff Baitis wrote:
>> Out of curiousity:
>> 
>> Has anyone played with the AU1X00 USB device port yet? If not, what would yo
>u
>> guys suggest that the AU1X00 appear as? USB over Ethernet? Or maybe a simple
>> dummy device that will perform bulk transfers?

I'm surprised no one has mentioned all the bugs :-)

Just so you know, the function side controller (i.e. "device") on the
au1100 is/was seriously buggy.  The folks at AMD are (or were) working
on a fix.  It was possible to get it to work, but it was very painful.

I don't remember the details of the chip revs, but as I recall all of
the au1100 parts which had been released as of the end of last year had
these bugs.

[fyi: the folks at Belcarra have done a lot of work on this problem and
know it well]

The ohci controller (i.e. "host") works fine, as far as I know, for all
modes (interrupt, bulk, isochronous).

-brad

From qfan@mmc.atmel.com Fri May  9 15:37:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 15:37:45 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:36392
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225266AbTEIOhn>; Fri, 9 May 2003 15:37:43 +0100
Received: from pluto.mmc.atmel.com (pluto.mmc.atmel.com [10.127.240.51])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA02372
	for <linux-mips@linux-mips.org>; Fri, 9 May 2003 10:37:37 -0400 (EDT)
Received: from localhost (qfan@localhost)
	by pluto.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA24855
	for <linux-mips@linux-mips.org>; Fri, 9 May 2003 10:37:36 -0400 (EDT)
X-Authentication-Warning: pluto.mmc.atmel.com: qfan owned process doing -bs
Date: Fri, 9 May 2003 10:37:36 -0400 (EDT)
From: Qing Fan <qfan@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: mips64 linux SEAD-2 compile
Message-ID: <Pine.GSO.4.44.0305091033200.24708-100000@pluto.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <qfan@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2323
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: qfan@mmc.atmel.com
Precedence: bulk
X-list: linux-mips



The cross compile tool I am using is:
binutils-mips64el-linux-2.13.1-1.i386.rpm

Here is a section from  Linux makefile ./arch/mips64/Makefile, which I
don't quite understand:

# The 64-bit ELF tools are pretty broken so at this time we generate
64-bit
# ELF files from 32-bit files by conversion.
#
ifdef CONFIG_BOOT_ELF64
CFLAGS += -Wa,-32
LINKFLAGS += -T arch/mips64/ld.script.elf32
#AS += -64
#LD += -m elf64bmip
#LD += -m elf64ltsmip
#LINKFLAGS += -T arch/mips64/ld.script.elf64
endif



When I tried to compile with this configuration, I received the following
error:

make[1]: Entering directory
`/home/dkesselr/scratch64/linux-2.4.18.sead/kernel'
make all_targets
make[2]: Entering directory
`/home/dkesselr/scratch64/linux-2.4.18.sead/kernel'
mips64el-linux-gcc -D__KERNEL__
-I/home/dkesselr/scratch64/linux-2.4.18.sead/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -I
/home/dkesselr/scratch64/linux-2.4.18.sead/include/asm/gcc -D__KERNEL__
-I/home/dkesselr/scratch64/linux-2.4.18.sead/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -mabi=64 -G 0 -mno-abicalls -fno-pic
-Wa,--trap -pipe -g -mcpu=r8000 -mips4 -Wa,-32   -DKBUILD_BASENAME=sched
-fno-omit-frame-pointer -c -o sched.o sched.c
{standard input}: Assembler messages:
{standard input}:1478: Warning: dla used to load 32-bit register
{standard input}:1598: Error: Number (0xffffffff) larger than 32 bits
{standard input}:1631: Warning: dla used to load 32-bit register
{standard input}:1663: Warning: dla used to load 32-bit register
{standard input}:1824: Warning: dla used to load 32-bit register
{standard input}:1825: Warning: dla used to load 32-bit register
{standard input}:1833: Warning: dla used to load 32-bit register
{standard input}:1834: Warning: dla used to load 32-bit register
{standard input}:1850: Warning: dla used to load 32-bit register
{standard input}:1868: Warning: dla used to load 32-bit register
{standard input}:1872: Warning: dla used to load 32-bit register
{standard input}:1873: Warning: dla used to load 32-bit register
{standard input}:1888: Warning: dla used to load 32-bit register
{standard input}:2364: Warning: dla used to load 32-bit register
{standard input}:2393: Warning: dla used to load 32-bit register
{standard input}:2394: Warning: dla used to load 32-bit register
{standard input}:2450: Warning: dla used to load 32-bit register
{standard input}:2451: Warning: dla used to load 32-bit register
{standard input}:2483: Warning: dla used to load 32-bit register
...
make[2]: *** [sched.o] Error 1
make[2]: Leaving directory
`/home/dkesselr/scratch64/linux-2.4.18.sead/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory
`/home/dkesselr/scratch64/linux-2.4.18.sead/kernel'
make: *** [_dir_kernel] Error 2


Then, I tried to comment out the 32-bit stuff and uncomment the 64-bit
stuff in the Makefile to

ifdef CONFIG_BOOT_ELF64
#CFLAGS += -Wa,-32
#LINKFLAGS += -T arch/mips64/ld.script.elf32
AS += -64
LD += -m elf64bmip
LD += -m elf64ltsmip
LINKFLAGS += -T arch/mips64/ld.script.elf64
endif

The compile went successfully, and 'vmlinus.sre' is created.  However, I
cannot successfully download it to the SEAD board, maybe because of the
64-bit elf format that the tools cannot support?


I need someone to point me to the right direction.  What exactly do I
need to do to make this to work?


Thanks,
qfan


From ralf@linux-mips.org Fri May  9 16:06:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 16:06:51 +0100 (BST)
Received: from p508B7184.dip.t-dialin.net ([IPv6:::ffff:80.139.113.132]:62134
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225266AbTEIPGs>; Fri, 9 May 2003 16:06:48 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h49F6Jts007895;
	Fri, 9 May 2003 17:06:19 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h49F6Csk007894;
	Fri, 9 May 2003 17:06:12 +0200
Date: Fri, 9 May 2003 17:06:12 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: JinuM <jinum@esntechnologies.co.in>
Cc: linux-mips@linux-mips.org
Subject: Re: open file in kernel mode
Message-ID: <20030509150612.GA7837@linux-mips.org>
References: <AF572D578398634881E52418B28925670EFF20@mail.esn.activedirectory>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AF572D578398634881E52418B28925670EFF20@mail.esn.activedirectory>
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: 2324
X-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, May 09, 2003 at 11:24:25AM +0530, JinuM wrote:

> I am trying to write a firmware loader driver. Instead of reading the
> firmware as a buffer(predefined array)  we would like to read the firmware
> from a file (say /root/firmware). Do we have some function which reads the
> file contents in kernel mode.

This one seems a candidate for an faq ...

Provide some special file in /dev/ and use a small user application to
install the firmware by writing it into that file.

  Ralf

From echristo@redhat.com Fri May  9 18:14:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 18:14:09 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:12.150.115.133]:39684 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225255AbTEIROG>;
	Fri, 9 May 2003 18:14:06 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id h49H3HZ25755;
	Fri, 9 May 2003 13:03:17 -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 h49HDiT31415;
	Fri, 9 May 2003 13:13:44 -0400
Received: from [192.168.123.164] (vpn50-8.rdu.redhat.com [172.16.50.8])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h49HDgM13970;
	Fri, 9 May 2003 10:13:43 -0700
Subject: Re: Problem of cross-mipsel-compiler GLIBC-2.3.X
From: Eric Christopher <echristo@redhat.com>
To: smills_ho <smills_ho@coventive.com>
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>, gcc@gcc.gnu.org
In-Reply-To: <001601c31602$86838de0$d017a8c0@pc208>
References: <3EB0B329.9030603@ict.ac.cn>
	 <16048.55936.346808.522687@cuddles.redhat.com> <3EB0DDC6.5080108@ict.ac.cn>
	 <16048.57054.224964.883062@cuddles.redhat.com>
	 <20030501085018.GA1885@greglaptop.attbi.com>
	 <000a01c315cf$8171ac70$d017a8c0@pc208>
	 <1052464867.2485.3.camel@ghostwheel.sfbay.redhat.com>
	 <001601c31602$86838de0$d017a8c0@pc208>
Content-Type: text/plain
Organization: 
Message-Id: <1052500416.3389.14.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 09 May 2003 10:13:36 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2325
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips

On Fri, 2003-05-09 at 01:10, smills_ho wrote:
> Dear Eric,
>     I follow the step that provide by Bradley
> http://www.ltc.com/~brad/mips/mipsel-linux-cross-toolchain-building.txt

I'd bug Brad then :)

-eric

-- 
Eric Christopher <echristo@redhat.com>


From michaelanburaj@hotmail.com Fri May  9 19:34:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 19:34:14 +0100 (BST)
Received: from bay1-f135.bay1.hotmail.com ([IPv6:::ffff:65.54.245.135]:59154
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225255AbTEISeM>; Fri, 9 May 2003 19:34:12 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 9 May 2003 11:34:03 -0700
Received: from 4.35.224.219 by by1fd.bay1.hotmail.msn.com with HTTP;
	Fri, 09 May 2003 18:34:03 GMT
X-Originating-IP: [4.35.224.219]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: jbglaw@lug-owl.de, linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Fri, 09 May 2003 11:34:03 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F13582h4PPyd7D00009472@hotmail.com>
X-OriginalArrivalTime: 09 May 2003 18:34:03.0466 (UTC) FILETIME=[90DABAA0:01C31659]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2326
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Almost there...

Looking up port of RPC 100003/2 on 4.42.102.7
portmap: server 4.42.102.7 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 4.42.102.7
portmap: server 4.42.102.7 not responding, timed out
Root-NFS: Unable to get mountd port number from server, using default
mount: server 4.42.102.7 not responding, timed out
Root-NFS: Server returned error -5 while mounting /export/RedHat7.1
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00

Where can I find the explanation for these nfs error codes? Why is it 
returning -5?


Clipping from /var/log/messages:

May  9 08:07:50 localhost exportfs[2460]: No 'sync' or 'async' option 
specified
for export "*:/export/RedHat7.1".   Assuming default behaviour ('sync').   
NOTE: this default has changed from previous versions
May  9 08:07:50 localhost exportfs: exportfs: No 'sync' or 'async' option 
specified for export "*:/export/RedHat7.1".
May  9 08:07:50 localhost exportfs:   Assuming default behaviour ('sync').
May  9 08:07:50 localhost exportfs:   NOTE: this default has changed from 
previous versions


Is 'sync' ok?

--Mike.

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


From ralf@linux-mips.org Fri May  9 20:08:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 20:08:43 +0100 (BST)
Received: from p508B7184.dip.t-dialin.net ([IPv6:::ffff:80.139.113.132]:5573
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225255AbTEITIl>; Fri, 9 May 2003 20:08:41 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h49J8Rts012279;
	Fri, 9 May 2003 21:08:27 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h49J8NtE012278;
	Fri, 9 May 2003 21:08:23 +0200
Date: Fri, 9 May 2003 21:08:23 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Keith M Wesolowski <wesolows@foobazco.org>
Cc: Ladislav Michl <ladis@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] Highmem detection for Indigo2
Message-ID: <20030509190823.GA29398@linux-mips.org>
References: <20030428071639.GA7578@simek> <20030508061117.GA30191@foobazco.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030508061117.GA30191@foobazco.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: 2327
X-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, May 07, 2003 at 11:11:17PM -0700, Keith M Wesolowski wrote:

> > Following patch builds whole RAM map based of MC's memory configuration
> > registers, does some samity checks adds high system memory (if any) to
> > bootmem.
> 
> > +static void init_bootmem(void)
> ...
> > +	init_bootmem();
> 
> This is a pretty unfortunate choice of names for this function.  See
> mm/bootmem.c.
> 
> Other than that, your patch works fine for me; my Indy has 192MB
> memory and it's detected properly.  I do get an oops in do_be from
> xdm, but I get that without the patch also.
> 
> Determined physical RAM map:
>  memory: 00001000 @ 00000000 (reserved)
>  memory: 00001000 @ 00001000 (reserved)
>  memory: 001e1000 @ 08002000 (reserved)
>  memory: 0055d000 @ 081e3000 (usable)
>  memory: 000c0000 @ 08740000 (ROM data)
>  memory: 0b800000 @ 08800000 (usable)
> 
> I need to do the same kind of thing for ip32 as the ARC memory
> detection has the same shortcoming on that platform.  No sense having
> a machine support 1GB memory and only looking for 256MB of it,
> especially in a 64-bit kernel.  ARC[S] really does seem to be useless.

That's what I'm saying since '94.  ARC was a commitee approach of the
ACE consortium which soon died.  The firmware part of the ARC standard
was also published as the Microsoft Portable Bootloader Standard but
Today every ARC implementation has some major deviations from the
standard rendering the term standard into nothing but a cynic demonation ...

  Ralf

From benmen@gmx.de Fri May  9 20:45:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 20:45:55 +0100 (BST)
Received: from nx5.HRZ.Uni-Dortmund.DE ([IPv6:::ffff:129.217.131.21]:44484
	"EHLO nx5.hrz.uni-dortmund.de") by linux-mips.org with ESMTP
	id <S8225255AbTEITpw>; Fri, 9 May 2003 20:45:52 +0100
Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51])
	by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id 7F78D4AA626
	for <linux-mips@linux-mips.org>; Fri,  9 May 2003 21:45:51 +0200 (MET DST)
Received: from linuxpc1 (p508EFA07.dip.t-dialin.net [80.142.250.7])
	(authenticated (0 bits))
	by unimail.uni-dortmund.de (8.12.9+Sun/8.11.6) with ESMTP id h49JjhtC015886
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NOT)
	for <linux-mips@linux-mips.org>; Fri, 9 May 2003 21:45:44 +0200 (MEST)
From: Benjamin =?iso-8859-1?q?Menk=FCc?= <benmen@gmx.de>
Reply-To: menkuec@auto-intern.com
To: linux-mips@linux-mips.org
Subject: compiling glibc
Date: Fri, 9 May 2003 21:45:43 +0200
User-Agent: KMail/1.5.1
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200305092145.43690.benmen@gmx.de>
X-MailScanner-Information: UniDo-UniMail
X-MailScanner: Found to be clean
Return-Path: <benmen@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: 2328
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: benmen@gmx.de
Precedence: bulk
X-list: linux-mips

Hi,

I cross-compiled binutils 2.13 and gcc-3.2.3 successfully for mips.

[benmen@linuxpc1 mipsel-glibc] LD_LIBRARY_PATH="" CFLAGS="-O2 -g 
-finline-limit=10000" ../glibc-2.3.2/configure --build=i686-linux 
--host=mipsel-linux --enable-add-ons --prefix=/home/benmen/mipsel

...

When I try to compile glibc I get this error:

[benmen@linuxpc1 mipsel-glibc] make
make -r PARALLELMFLAGS="" CVSOPTS="" -C ../glibc-2.3.2 objdir=`pwd` all
...
make[2]: Leaving directory `/home/benmen/mips/glibc-2.3.2/csu'
make[2]: Entering directory `/home/benmen/mips/glibc-2.3.2/csu'
gcc ../sysdeps/unix/sysv/linux/init-first.c -c -std=gnu99 -O2 -Wall -Winline 
-Wstrict-prototypes -Wwrite-strings -finline-limit=10000 -g      -I../include 
-I. -I/home/benmen/mips/mipsel-glibc/csu -I.. -I../libio  
-I/home/benmen/mips/mipsel-glibc -I../sysdeps/mips/elf 
-I../linuxthreads/sysdeps/unix/sysv/linux/mips 
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread 
-I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv 
-I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/mips 
-I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/linux 
-I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman 
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips 
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/mips/mipsel 
-I../sysdeps/mips/fpu -I../sysdeps/mips -I../sysdeps/wordsize-32 
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 
-I../sysdeps/generic/elf -I../sysdeps/generic   -D_LIBC_REENTRANT -include 
../include/libc-symbols.h       -DHAVE_INITFINI -o 
/home/benmen/mips/mipsel-glibc/csu/init-first.o
In file included from ../linuxthreads/descr.h:42,
                 from ../linuxthreads/internals.h:29,
                 from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:27,
                 from ../sysdeps/generic/ldsodefs.h:38,
                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
                 from ../sysdeps/mips/elf/ldsodefs.h:25,
                 from ../sysdeps/unix/sysv/linux/init-first.c:30:
../linuxthreads/sysdeps/mips/pt-machine.h:48: invalid register name for 
`stack_pointer'
In file included from ../sysdeps/unix/sysv/linux/mips/sys/procfs.h:29,
                 from ../linuxthreads_db/proc_service.h:20,
                 from ../linuxthreads_db/thread_dbP.h:7,
                 from ../linuxthreads/descr.h:43,
                 from ../linuxthreads/internals.h:29,
                 from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:27,
                 from ../sysdeps/generic/ldsodefs.h:38,
                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
                 from ../sysdeps/mips/elf/ldsodefs.h:25,
                 from ../sysdeps/unix/sysv/linux/init-first.c:30:
../sysdeps/unix/sysv/linux/mips/sys/user.h:26:21: asm/reg.h: Datei oder 
Verzeichnis nicht gefunden
In file included from ../sysdeps/unix/sysv/linux/mips/sys/procfs.h:29,
                 from ../linuxthreads_db/proc_service.h:20,
                 from ../linuxthreads_db/thread_dbP.h:7,
                 from ../linuxthreads/descr.h:43,
                 from ../linuxthreads/internals.h:29,
                 from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:27,
                 from ../sysdeps/generic/ldsodefs.h:38,
                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
                 from ../sysdeps/mips/elf/ldsodefs.h:25,
                 from ../sysdeps/unix/sysv/linux/init-first.c:30:
../sysdeps/unix/sysv/linux/mips/sys/user.h:30: `EF_SIZE' undeclared here (not 
in a function)
../sysdeps/unix/sysv/linux/mips/sys/user.h:41: confused by earlier errors, 
bailing out
make[2]: *** [/home/benmen/mips/mipsel-glibc/csu/init-first.o] Fehler 1
make[2]: Leaving directory `/home/benmen/mips/glibc-2.3.2/csu'
make[1]: *** [csu/subdir_lib] Fehler 2
make[1]: Leaving directory `/home/benmen/mips/glibc-2.3.2'
make: *** [all] Fehler 2
Verzeichnis: ~/mips/mipsel-glibc
[benmen@linuxpc1 mipsel-glibc]

The headers including asm/reg.h are located in /home/benmen/mipsel/include ...
the mipsel-linux-gcc + binutils stuff is in /home/benmen/mipsel/bin ...

Thanks for Your help.

regards,

Ben

From ica2_ts@csv.ica.uni-stuttgart.de Fri May  9 22:45:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 May 2003 22:45:36 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:63382
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225255AbTEIVpd>; Fri, 9 May 2003 22:45:33 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19EFfr-00177q-00; Fri, 09 May 2003 23:45:03 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19EFfp-0005TO-00; Fri, 09 May 2003 23:45:01 +0200
Date: Fri, 9 May 2003 23:45:01 +0200
To: menkuec@auto-intern.com
Cc: linux-mips@linux-mips.org
Subject: Re: compiling glibc
Message-ID: <20030509214501.GA18697@rembrandt.csv.ica.uni-stuttgart.de>
References: <200305092145.43690.benmen@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200305092145.43690.benmen@gmx.de>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2329
X-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

Benjamin Menküc wrote:
> Hi,
> 
> I cross-compiled binutils 2.13 and gcc-3.2.3 successfully for mips.
> 
> [benmen@linuxpc1 mipsel-glibc] LD_LIBRARY_PATH="" CFLAGS="-O2 -g 
> -finline-limit=10000" ../glibc-2.3.2/configure --build=i686-linux 
> --host=mipsel-linux --enable-add-ons --prefix=/home/benmen/mipsel

It also needs the headers of the already correctly configured
kernel, added by --with-headers=/path/to/linux/headers.


Thiemo

From benmen@gmx.de Sat May 10 02:03:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 02:04:02 +0100 (BST)
Received: from nx5.HRZ.Uni-Dortmund.DE ([IPv6:::ffff:129.217.131.21]:20733
	"EHLO nx5.hrz.uni-dortmund.de") by linux-mips.org with ESMTP
	id <S8225276AbTEJBD6>; Sat, 10 May 2003 02:03:58 +0100
Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51])
	by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP
	id 9ED7E4AA605; Sat, 10 May 2003 03:03:55 +0200 (MET DST)
Received: from linuxpc1 (p508EFA07.dip.t-dialin.net [80.142.250.7])
	(authenticated (0 bits))
	by unimail.uni-dortmund.de (8.12.9+Sun/8.11.6) with ESMTP id h4A13ntC027032
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NOT);
	Sat, 10 May 2003 03:03:50 +0200 (MEST)
From: Benjamin =?iso-8859-1?q?Menk=FCc?= <benmen@gmx.de>
Reply-To: menkuec@auto-intern.com
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Subject: Re: compiling glibc
Date: Sat, 10 May 2003 03:03:48 +0200
User-Agent: KMail/1.5.1
References: <200305092145.43690.benmen@gmx.de> <20030509214501.GA18697@rembrandt.csv.ica.uni-stuttgart.de>
In-Reply-To: <20030509214501.GA18697@rembrandt.csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200305100303.48870.benmen@gmx.de>
X-MailScanner-Information: UniDo-UniMail
X-MailScanner: Found to be clean
Return-Path: <benmen@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: 2330
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: benmen@gmx.de
Precedence: bulk
X-list: linux-mips

When I add the include stuff I still get this error:

[benmen@linuxpc1 mipsel-glibc] LD_LIBRARY_PATH="" CFLAGS="-O2 -g 
-finline-limit=10000" ../glibc-2.3.2/configure --build=i686-linux 
--host=mipsel-linux --enable-add-ons --prefix=/home/benmen/mipsel 
--with-headers=/home/benmen/mips/kernel/mips-2.4.20/include

....

[benmen@linuxpc1 mipsel-glibc] make

...

make[2]: Leaving directory `/home/benmen/mips/glibc-2.3.2/csu'
make[2]: Entering directory `/home/benmen/mips/glibc-2.3.2/csu'
gcc ../sysdeps/unix/sysv/linux/init-first.c -c -std=gnu99 -O2 -Wall -Winline 
-Wstrict-prototypes -Wwrite-strings -finline-limit=10000 -g      -I../include 
-I. -I/home/benmen/mips/mipsel-glibc/csu -I.. -I../libio  
-I/home/benmen/mips/mipsel-glibc -I../sysdeps/mips/elf 
-I../linuxthreads/sysdeps/unix/sysv/linux/mips 
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread 
-I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv 
-I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/mips 
-I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/linux 
-I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman 
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips 
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/mips/mipsel 
-I../sysdeps/mips/fpu -I../sysdeps/mips -I../sysdeps/wordsize-32 
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 
-I../sysdeps/generic/elf -I../sysdeps/generic  -nostdinc -isystem 
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include -isystem 
/home/benmen/mips/kernel/mips-2.4.20/include -D_LIBC_REENTRANT -include 
../include/libc-symbols.h       -DHAVE_INITFINI -o 
/home/benmen/mips/mipsel-glibc/csu/init-first.o
In file included from ../linuxthreads/descr.h:42,
                 from ../linuxthreads/internals.h:29,
                 from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:27,
                 from ../sysdeps/generic/ldsodefs.h:38,
                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
                 from ../sysdeps/mips/elf/ldsodefs.h:25,
                 from ../sysdeps/unix/sysv/linux/init-first.c:30:
../linuxthreads/sysdeps/mips/pt-machine.h:48: invalid register name for 
`stack_pointer'
make[2]: *** [/home/benmen/mips/mipsel-glibc/csu/init-first.o] Fehler 1
make[2]: Leaving directory `/home/benmen/mips/glibc-2.3.2/csu'
make[1]: *** [csu/subdir_lib] Fehler 2
make[1]: Leaving directory `/home/benmen/mips/glibc-2.3.2'
make: *** [all] Fehler 2

regards,

Ben


From kumba@gentoo.org Sat May 10 05:18:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 05:18:51 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.116]:22338 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225278AbTEJESs>; Sat, 10 May 2003 05:18:48 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout01.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003))
 with ESMTP id <0HEN00DUTL9XC2@mtaout01.icomcast.net> for
 linux-mips@linux-mips.org; Sat, 10 May 2003 00:17:57 -0400 (EDT)
Date: Sat, 10 May 2003 00:20:49 -0400
From: Kumba <kumba@gentoo.org>
Subject: OpenSSL/Binutils Issues
To: linux-mips@linux-mips.org
Reply-to: linux-mips@linux-mips.org
Message-id: <3EBC7E21.6040109@gentoo.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
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: 2331
X-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


	Greetings all,

	Having some issues with Binutils and OpenSSL on mips.  Trying to 
bootstrap a machine using binutils-2.14.90.0.1, gcc-3.2.3, & 
glibc-2.3.2, and use -mips3 -mabi=32.  It's working good so far, I 
almost have a complete system built in chroot, only problem is OpenSSL 
doesn't seem to coorperate well with the latest Binutils.

	OpenSSL itself builds, but other programs have issues attempting to 
make use of it.  I've known of the issue since one user said OpenSSH 
doesn't work, but this time, while building wget, wget's configure 
program was unable to use OpenSSL.  The Error messages are below.

	Wget's configure builds this code as "conftest.c":

		#include "confdefs.h"

		int RSA_new();
		int SSL_new();
		main(){return 0;}

	And Compiles it with:

		gcc -o conftest -O3 -mips3 -mabi=32 -mtune=r4400 -pipe
		-fomit-frame-pointer -I/usr/include/openssl 3.c  -lssl
		-lcrypto -ldl

	Which builds fine.  Then the error hits when attempting to execute the 
"conftest" executable:

		./conftest: error while loading shared libraries:
		usr/lib/libcrypto.so.0.9.6: unexpected reloc type 0x68


	Has anyone seen anything like this?  My base mips install on my SGI 
Indigo2 is built using binutils-2.13.90.0.16, which builds everything 
fine, just doesn't cooperate well with -mips3 or higher options.  I'm 
not sure if this is mips-specific, or if I need to bother the OpenSSL 
team about it.

	Ideas?

--Kumba




From drow@false.org Sat May 10 05:25:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 05:25:54 +0100 (BST)
Received: from crack.them.org ([IPv6:::ffff:146.82.138.56]:23530 "EHLO
	crack.them.org") by linux-mips.org with ESMTP id <S8225278AbTEJEZw>;
	Sat, 10 May 2003 05:25:52 +0100
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 19ELvu-0005Ev-00; Fri, 09 May 2003 23:26:02 -0500
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 19ELvT-0000bz-00; Sat, 10 May 2003 00:25:35 -0400
Date: Sat, 10 May 2003 00:25:35 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: menkuec@auto-intern.com
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org
Subject: Re: compiling glibc
Message-ID: <20030510042535.GA2336@nevyn.them.org>
References: <200305092145.43690.benmen@gmx.de> <20030509214501.GA18697@rembrandt.csv.ica.uni-stuttgart.de> <200305100303.48870.benmen@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200305100303.48870.benmen@gmx.de>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@false.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2332
X-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 Sat, May 10, 2003 at 03:03:48AM +0200, Benjamin Menküc wrote:
> When I add the include stuff I still get this error:
> 
> [benmen@linuxpc1 mipsel-glibc] LD_LIBRARY_PATH="" CFLAGS="-O2 -g 
> -finline-limit=10000" ../glibc-2.3.2/configure --build=i686-linux 
> --host=mipsel-linux --enable-add-ons --prefix=/home/benmen/mipsel 
> --with-headers=/home/benmen/mips/kernel/mips-2.4.20/include

You didn't set CC and AS.  It's using the native compiler, not the
cross.

> 
> ....
> 
> [benmen@linuxpc1 mipsel-glibc] make
> 
> ...
> 
> make[2]: Leaving directory `/home/benmen/mips/glibc-2.3.2/csu'
> make[2]: Entering directory `/home/benmen/mips/glibc-2.3.2/csu'
> gcc ../sysdeps/unix/sysv/linux/init-first.c -c -std=gnu99 -O2 -Wall -Winline 
> -Wstrict-prototypes -Wwrite-strings -finline-limit=10000 -g      -I../include 
> -I. -I/home/benmen/mips/mipsel-glibc/csu -I.. -I../libio  
> -I/home/benmen/mips/mipsel-glibc -I../sysdeps/mips/elf 
> -I../linuxthreads/sysdeps/unix/sysv/linux/mips 
> -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread 
> -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv 
> -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/mips 
> -I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/linux 
> -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman 
> -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips 
> -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/mips/mipsel 
> -I../sysdeps/mips/fpu -I../sysdeps/mips -I../sysdeps/wordsize-32 
> -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 
> -I../sysdeps/generic/elf -I../sysdeps/generic  -nostdinc -isystem 
> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include -isystem 
> /home/benmen/mips/kernel/mips-2.4.20/include -D_LIBC_REENTRANT -include 
> ../include/libc-symbols.h       -DHAVE_INITFINI -o 
> /home/benmen/mips/mipsel-glibc/csu/init-first.o
> In file included from ../linuxthreads/descr.h:42,
>                  from ../linuxthreads/internals.h:29,
>                  from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:27,
>                  from ../sysdeps/generic/ldsodefs.h:38,
>                  from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
>                  from ../sysdeps/mips/elf/ldsodefs.h:25,
>                  from ../sysdeps/unix/sysv/linux/init-first.c:30:
> ../linuxthreads/sysdeps/mips/pt-machine.h:48: invalid register name for 
> `stack_pointer'
> make[2]: *** [/home/benmen/mips/mipsel-glibc/csu/init-first.o] Fehler 1
> make[2]: Leaving directory `/home/benmen/mips/glibc-2.3.2/csu'
> make[1]: *** [csu/subdir_lib] Fehler 2
> make[1]: Leaving directory `/home/benmen/mips/glibc-2.3.2'
> make: *** [all] Fehler 2
> 
> regards,
> 
> Ben
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From michaelanburaj@hotmail.com Sat May 10 05:57:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 05:57:57 +0100 (BST)
Received: from bay1-f45.bay1.hotmail.com ([IPv6:::ffff:65.54.245.45]:20744
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225278AbTEJE5z>; Sat, 10 May 2003 05:57:55 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 9 May 2003 21:57:47 -0700
Received: from 4.35.224.219 by by1fd.bay1.hotmail.msn.com with HTTP;
	Sat, 10 May 2003 04:57:46 GMT
X-Originating-IP: [4.35.224.219]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: jbglaw@lug-owl.de, linux-mips@linux-mips.org
Cc: muthu@iqmail.net
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Fri, 09 May 2003 21:57:46 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F45jlKqwWil63h0000a6fd@hotmail.com>
X-OriginalArrivalTime: 10 May 2003 04:57:47.0274 (UTC) FILETIME=[B32EA6A0:01C316B0]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2333
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,

The linux kernel on the Atlas board went past the NFS issue.

Now a new one :(


Warning: unable to open an initial console.
Kernel panic: No init found.  Try passing init= option to kernel.


in src/linux/init/main.c

open("/dev/console", O_RDWR, 0) is returning a negative value. I don't have 
a video device on board., required? Will /dev/console open a UART port 
(/dev/ttyS0 or /dev/tty0)? Why am I getting this error?

1. Is the kernel not build properly (did not include console driver)?
2. Should I pass init=blablabla as a parameter? <but nothing like that is 
specified in the doc.>.

Advice me please...

Thanks,

-Mike.

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus


From muthu@iqmail.net Sat May 10 07:05:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 07:05:55 +0100 (BST)
Received: from vopmail.sfo.interquest.net ([IPv6:::ffff:66.135.128.69]:34574
	"EHLO micaiah.rwc.iqcicom.com") by linux-mips.org with ESMTP
	id <S8225278AbTEJGFx>; Sat, 10 May 2003 07:05:53 +0100
Received: from Muruga.localdomain (unverified [66.135.134.124]) by micaiah.rwc.iqcicom.com
 (Vircom SMTPRS 2.0.244) with ESMTP id <B0006366709@micaiah.rwc.iqcicom.com>;
 Fri, 9 May 2003 23:05:48 -0700
Received: from localhost (muthu@localhost)
	by Muruga.localdomain (8.11.6/8.11.2) with ESMTP id h4A5iEY12859;
	Fri, 9 May 2003 22:44:14 -0700
Date: Fri, 9 May 2003 22:44:13 -0700 (PDT)
From: Muthukumar Ratty <muthu@iqmail.net>
To: Michael Anburaj <michaelanburaj@hotmail.com>
cc: <linux-mips@linux-mips.org>
Subject: Re: Linux for MIPS Atlas 4Kc board
In-Reply-To: <BAY1-F45jlKqwWil63h0000a6fd@hotmail.com>
Message-ID: <Pine.LNX.4.33.0305092241080.12630-100000@Muruga.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <muthu@iqmail.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2334
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: muthu@iqmail.net
Precedence: bulk
X-list: linux-mips

> Warning: unable to open an initial console.
> Kernel panic: No init found.  Try passing init= option to kernel.
>


do you have init in /export/.../sbin Probably exporting wrong
directory?

>
> in src/linux/init/main.c
>
> open("/dev/console", O_RDWR, 0) is returning a negative value. I don't have
> a video device on board., required? Will /dev/console open a UART port
> (/dev/ttyS0 or /dev/tty0)? Why am I getting this error?
>
> 1. Is the kernel not build properly (did not include console driver)?
> 2. Should I pass init=blablabla as a parameter? <but nothing like that is
> specified in the doc.>.
>
> Advice me please...
>
> Thanks,
>
> -Mike.
>
> _________________________________________________________________
> MSN 8 with e-mail virus protection service: 2 months FREE*
> http://join.msn.com/?page=features/virus
>
>



From muthu@iqmail.net Sat May 10 07:12:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 07:12:05 +0100 (BST)
Received: from vopmail.sfo.interquest.net ([IPv6:::ffff:66.135.128.69]:58382
	"EHLO micaiah.rwc.iqcicom.com") by linux-mips.org with ESMTP
	id <S8225278AbTEJGMB>; Sat, 10 May 2003 07:12:01 +0100
Received: from Muruga.localdomain (unverified [66.135.134.124]) by micaiah.rwc.iqcicom.com
 (Vircom SMTPRS 2.0.244) with ESMTP id <B0006366815@micaiah.rwc.iqcicom.com> for <linux-mips@linux-mips.org>;
 Fri, 9 May 2003 23:11:59 -0700
Received: from localhost (muthu@localhost)
	by Muruga.localdomain (8.11.6/8.11.2) with ESMTP id h4A5oON12880
	for <linux-mips@linux-mips.org>; Fri, 9 May 2003 22:50:24 -0700
Date: Fri, 9 May 2003 22:50:24 -0700 (PDT)
From: Muthukumar Ratty <muthu@iqmail.net>
To: <linux-mips@linux-mips.org>
Subject: Re: OpenSSL/Binutils Issues
In-Reply-To: <3EBC7E21.6040109@gentoo.org>
Message-ID: <Pine.LNX.4.33.0305092248450.12875-100000@Muruga.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <muthu@iqmail.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2335
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: muthu@iqmail.net
Precedence: bulk
X-list: linux-mips

> 		./conftest: error while loading shared libraries:
> 		usr/lib/libcrypto.so.0.9.6: unexpected reloc type 0x68
>


something really wrong with your crypto library (has some non mips
specific rel. syms???)

> not sure if this is mips-specific, or if I need to bother the OpenSSL
> team about it.

probably you should :)


>
> 	Ideas?
>
> --Kumba
>
>
>
>



From benmen@gmx.de Sat May 10 10:56:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 10:56:20 +0100 (BST)
Received: from nx5.HRZ.Uni-Dortmund.DE ([IPv6:::ffff:129.217.131.21]:61802
	"EHLO nx5.hrz.uni-dortmund.de") by linux-mips.org with ESMTP
	id <S8225278AbTEJJ4S> convert rfc822-to-8bit; Sat, 10 May 2003 10:56:18 +0100
Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51])
	by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP
	id E61154AA981; Sat, 10 May 2003 11:56:15 +0200 (MET DST)
Received: from linuxpc1 (p508EFB9C.dip.t-dialin.net [80.142.251.156])
	(authenticated (0 bits))
	by unimail.uni-dortmund.de (8.12.9+Sun/8.11.6) with ESMTP id h4A9u9tC011079
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NOT);
	Sat, 10 May 2003 11:56:10 +0200 (MEST)
From: Benjamin =?iso-8859-1?q?Menk=FCc?= <benmen@gmx.de>
Reply-To: menkuec@auto-intern.com
To: Daniel Jacobowitz <dan@debian.org>
Subject: Re: compiling glibc
Date: Sat, 10 May 2003 11:56:08 +0200
User-Agent: KMail/1.5.1
References: <200305092145.43690.benmen@gmx.de> <200305100303.48870.benmen@gmx.de> <20030510042535.GA2336@nevyn.them.org>
In-Reply-To: <20030510042535.GA2336@nevyn.them.org>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Message-Id: <200305101156.08254.benmen@gmx.de>
X-MailScanner-Information: UniDo-UniMail
X-MailScanner: Found to be clean
Return-Path: <benmen@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: 2336
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: benmen@gmx.de
Precedence: bulk
X-list: linux-mips

Okay, it works now when I set CC=mipsel-linux-gcc and AS=mipsel-linux-as

[benmen@linuxpc1 mipsel-glibc] LD_LIBRARY_PATH="" CFLAGS="-O2 -g 
-finline-limit=10000" CC="mipsel-linux-gcc" AS="mipsel-linux-as" 
../glibc-2.3.2/configure --build=i686-linux --host=mipsel-linux 
--enable-add-ons --prefix=/home/benmen/mipsel 
--with-headers=/home/benmen/mips/kernel/mips-2.4.20/include

until this comes:

make[2]: Entering directory `/home/benmen/mips/glibc-2.3.2/misc'
make[2]: *** Keine Regel vorhanden, um das Target 
ŧ/home/benmen/mips/mipsel-glibc/misc/cachectl.oŦ,
  benötigt von ŧ/home/benmen/mips/mipsel-glibc/misc/stamp.oŦ, zu erstellen.  
Schluss.
make[2]: Leaving directory `/home/benmen/mips/glibc-2.3.2/misc'
make[1]: *** [misc/subdir_lib] Fehler 2
make[1]: Leaving directory `/home/benmen/mips/glibc-2.3.2'
make: *** [all] Fehler 2
Verzeichnis: ~/mips/mipsel-glibc
[benmen@linuxpc1 mipsel-glibc]

PS: shouldn't the Makefile take care of the CC and AS variables?

regards,

Ben

From jbglaw@dvmwest.gt.owl.de Sat May 10 11:30:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 11:30:15 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:18184 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225278AbTEJKaN>; Sat, 10 May 2003 11:30:13 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 4835D4ABBB; Sat, 10 May 2003 12:30:10 +0200 (CEST)
Date: Sat, 10 May 2003 12:30:10 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Message-ID: <20030510103009.GF27494@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <BAY1-F45jlKqwWil63h0000a6fd@hotmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="EhL9IO3QiJLbitD/"
Content-Disposition: inline
In-Reply-To: <BAY1-F45jlKqwWil63h0000a6fd@hotmail.com>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2337
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


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

On Fri, 2003-05-09 21:57:46 -0700, Michael Anburaj <michaelanburaj@hotmail.=
com>
wrote in message <BAY1-F45jlKqwWil63h0000a6fd@hotmail.com>:
>=20
> Warning: unable to open an initial console.
> Kernel panic: No init found.  Try passing init=3D option to kernel.
>=20
> in src/linux/init/main.c
>=20
> open("/dev/console", O_RDWR, 0) is returning a negative value. I don't ha=
ve=20
> a video device on board., required? Will /dev/console open a UART port=20
> (/dev/ttyS0 or /dev/tty0)? Why am I getting this error?

/dev/console (within your NFS root) should be a char device with 0x05 as
major and 0x01 as minor.

If you want so use serial console, you need to pass "console=3D/dev/ttyS0"
(or similar if your serial devices use a different naming scheme) along
with kernel's command line.

"init" is another thing. Your NFS root should include a /sbin/init or
or /etc/init or /bin/init or /bin/sh. If none of those exists, you
loose. Somewhere, you told that you get -5 as error code. This is EIO
IIRC so maybe your network card's driver is buggy. For debugging this,
you should use tcpdump (or ethereal) as well as userspace NFS server and
attach a strace to it:)

> 1. Is the kernel not build properly (did not include console driver)?

You need serial drivers compiled in and you need to configure them as
console drivers (serial console). Additionally, you need to pass
"console=3DttyS0" as kernel command line option.

> 2. Should I pass init=3Dblablabla as a parameter? <but nothing like that =
is=20
> specified in the doc.>.

In normal cases, you don't need to pass that. Kernel should just pick
/sbin/init and execute it. /sbin/init will then start everything needed.
Could you please do this:

$ cd /path/to/nfsroot
$ file sbin/inint

MfG, JBG

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

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

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

iD8DBQE+vNSxHb1edYOZ4bsRAhM+AJ9G9Ksz9aNWsGz48mYZ/TmjFrxwiwCdG31a
44xZ42+81I+pzNqxPPId1cI=
=gBm4
-----END PGP SIGNATURE-----

--EhL9IO3QiJLbitD/--

From benmen@gmx.de Sat May 10 12:21:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 12:21:34 +0100 (BST)
Received: from nx5.HRZ.Uni-Dortmund.DE ([IPv6:::ffff:129.217.131.21]:44151
	"EHLO nx5.hrz.uni-dortmund.de") by linux-mips.org with ESMTP
	id <S8225278AbTEJLVb>; Sat, 10 May 2003 12:21:31 +0100
Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51])
	by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id 245314AA2B9
	for <linux-mips@linux-mips.org>; Sat, 10 May 2003 13:21:29 +0200 (MET DST)
Received: from linuxpc1 (p508EFB9C.dip.t-dialin.net [80.142.251.156])
	(authenticated (0 bits))
	by unimail.uni-dortmund.de (8.12.9+Sun/8.11.6) with ESMTP id h4ABLMtC014169
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NOT)
	for <linux-mips@linux-mips.org>; Sat, 10 May 2003 13:21:23 +0200 (MEST)
From: Benjamin =?iso-8859-1?q?Menk=FCc?= <benmen@gmx.de>
Reply-To: menkuec@auto-intern.com
To: linux-mips@linux-mips.org
Subject: Re: compiling glibc
Date: Sat, 10 May 2003 13:21:21 +0200
User-Agent: KMail/1.5.1
References: <200305092145.43690.benmen@gmx.de> <20030510042535.GA2336@nevyn.them.org> <200305101156.08254.benmen@gmx.de>
In-Reply-To: <200305101156.08254.benmen@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200305101321.21232.benmen@gmx.de>
X-MailScanner-Information: UniDo-UniMail
X-MailScanner: Found to be clean
Return-Path: <benmen@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: 2338
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: benmen@gmx.de
Precedence: bulk
X-list: linux-mips

Okay, I fixed this problem by adding --disable-profile:

[benmen@linuxpc1 mipsel-glibc] LD_LIBRARY_PATH="" CFLAGS="-O2 -g 
-finline-limit=10000" CC="mipsel-linux-gcc" AS="mipsel-linux-as" 
../glibc-2.3.2/configure --build=i686-linux --host=mipsel-linux 
--enable-add-ons --prefix=/home/benmen/mipsel 
--with-headers=/home/benmen/mips/kernel/mips-2.4.20/include --disable-profile

...

Now I can compile until this comes:

[benmen@linuxpc1 mipsel-glibc] BUILD_CC=gcc CC=mipsel-linux-gcc ma

...

make[3]: Leaving directory `/home/benmen/mips/glibc-2.3.2/elf'
mipsel-linux-gcc   -nostdlib -nostartfiles -r -o 
/home/benmen/mips/mipsel-glibc/elf/librtld.os '-Wl,-(' 
/home/benmen/mips/mipsel-glibc/elf/dl-allobjs.os 
/home/benmen/mips/mipsel-glibc/elf/rtld-libc.a -lgcc '-Wl,-)'
mipsel-linux-gcc   -nostdlib -nostartfiles -shared                      \
   -Wl,-z,defs -Wl,--verbose 2>&1 |     \
          sed -e '/^=========/,/^=========/!d;/^=========/d'    \
              -e 's/\. = 0 + SIZEOF_HEADERS;/& _begin = . - SIZEOF_HEADERS;/' 
\
          > /home/benmen/mips/mipsel-glibc/elf/ld.so.lds
mipsel-linux-gcc   -nostdlib -nostartfiles -shared -o 
/home/benmen/mips/mipsel-glibc/elf/ld.so                  \
           -Wl,-z,defs                          \
          /home/benmen/mips/mipsel-glibc/elf/librtld.os 
-Wl,--version-script=/home/benmen/mips/mipsel-glibc/ld.map    \
          -Wl,-soname=ld.so.1 -T /home/benmen/mips/mipsel-glibc/elf/ld.so.lds
/home/benmen/mips/mipsel-glibc/elf/librtld.os: In function 
`_dl_resolve_conflicts':
/home/benmen/mips/glibc-2.3.2/elf/dl-conflict.c:65: undefined reference to 
`elf_machine_rela.7'
collect2: ld returned 1 exit status
make[2]: *** [/home/benmen/mips/mipsel-glibc/elf/ld.so] Fehler 1
make[2]: Leaving directory `/home/benmen/mips/glibc-2.3.2/elf'
make[1]: *** [elf/subdir_lib] Fehler 2
make[1]: Leaving directory `/home/benmen/mips/glibc-2.3.2'
make: *** [all] Fehler 2
Verzeichnis: ~/mips/mipsel-glibc
[benmen@linuxpc1 mipsel-glibc]

regards,

Ben


From ica2_ts@csv.ica.uni-stuttgart.de Sat May 10 15:20:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 15:20:05 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:54680
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225278AbTEJOUD>; Sat, 10 May 2003 15:20:03 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19EVCj-0018X4-00
	for linux-mips@linux-mips.org; Sat, 10 May 2003 16:20:01 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19EVCi-0002ZR-00
	for <linux-mips@linux-mips.org>; Sat, 10 May 2003 16:20:00 +0200
Date: Sat, 10 May 2003 16:19:59 +0200
To: linux-mips@linux-mips.org
Subject: Re: OpenSSL/Binutils Issues
Message-ID: <20030510141959.GB18697@rembrandt.csv.ica.uni-stuttgart.de>
References: <3EBC7E21.6040109@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EBC7E21.6040109@gentoo.org>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2339
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Kumba wrote:
[snip]
> 	Which builds fine.  Then the error hits when attempting to execute 
> 	the "conftest" executable:
> 
> 		./conftest: error while loading shared libraries:
> 		usr/lib/libcrypto.so.0.9.6: unexpected reloc type 0x68

This libcrypto seems to be broken. 0x68 is not a valid MIPS reloc type
at all, and a shared lib should use only R_MIPS_32 (type 2) relocations
anyway.

> 	Has anyone seen anything like this?  My base mips install on my SGI 
> Indigo2 is built using binutils-2.13.90.0.16, which builds everything 
> fine, just doesn't cooperate well with -mips3 or higher options.  I'm 
> not sure if this is mips-specific, or if I need to bother the OpenSSL 
> team about it.

It is probably a binutils issue. Can you send the output of
objdump -R usr/lib/libcrypto.so.0.9.6 |grep R_MIPS |grep -v \(R_MIPS_32\|R_MIPS_NONE\)


Thiemo

From michaelanburaj@hotmail.com Sat May 10 16:56:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 16:56:11 +0100 (BST)
Received: from bay1-f3.bay1.hotmail.com ([IPv6:::ffff:65.54.245.3]:65029 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225278AbTEJP4J>;
	Sat, 10 May 2003 16:56:09 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sat, 10 May 2003 08:56:01 -0700
Received: from 4.35.224.219 by by1fd.bay1.hotmail.msn.com with HTTP;
	Sat, 10 May 2003 15:56:01 GMT
X-Originating-IP: [4.35.224.219]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: jbglaw@lug-owl.de, linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Sat, 10 May 2003 08:56:01 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F3AmEaJswFCHOz0000b1d9@hotmail.com>
X-OriginalArrivalTime: 10 May 2003 15:56:01.0357 (UTC) FILETIME=[A77D77D0:01C3170C]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2340
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,

>"init" is another thing. Your NFS root should include a /sbin/init or
>or /etc/init or /bin/init or /bin/sh. If none of those exists, you
>loose.


For setting up the NFS, I did the following:
1. exported the /export/RedHat7.1
2. downloaded MIPS_RedHat7.1_Release-02.00.tar from 
ftp://ftp.mips.com/pub/linux/mips/installation/redhat7.1/02.00

this tar file has the following:

linux\installation\RedHat7.1\RPMS\mips\ <contains a lot of rpms>
linux\installation\RedHat7.1\RPMS\mipsel\ <contains a lot of rpms>
linux\installation\RedHat7.1\RPMS\noarch\ <contains a lot of rpms>
linux\installation\RedHat7.1\install\ <contains a Makefile, install.list, 
install.script>
linux\installation\RedHat7.1\install\root\etc\ <contains inittab, securetty>
linux\installation\RedHat7.1\install\root\etc\sysconfig\ <contains network>
linux\installation\RedHat7.1\install\root\etc\xinetd.d\ <contains telnet, 
rlogin, rsh,rexec, hosts>

& some more files.

Now tell me what should be extracted to my NFS export /export/RedHat7.1 
(along with their relative path info.).

Also let me know what path to be passed on to the kernel as parameter to 
nfsroot=
Is it simply /export/Redhat7.1?

Another question: I don't see a init file in the tar. or is inittab similar? 
Is this "MIPS_RedHat7.1_Release-02.00.tar" tar file the right file & the 
only file that is needed for now; that has the right stuff in it? Or do I 
need to get the right file from a different tar file?


Thanks,
-Mike.

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


From muthu@iqmail.net Sat May 10 20:25:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 20:25:55 +0100 (BST)
Received: from vopmail.sfo.interquest.net ([IPv6:::ffff:66.135.128.69]:47889
	"EHLO micaiah.rwc.iqcicom.com") by linux-mips.org with ESMTP
	id <S8225290AbTEJTZx>; Sat, 10 May 2003 20:25:53 +0100
Received: from Muruga.localdomain (unverified [66.135.134.124]) by micaiah.rwc.iqcicom.com
 (Vircom SMTPRS 2.0.244) with ESMTP id <B0006382563@micaiah.rwc.iqcicom.com>;
 Sat, 10 May 2003 12:25:51 -0700
Received: from localhost (muthu@localhost)
	by Muruga.localdomain (8.11.6/8.11.2) with ESMTP id h4AJ48d13881;
	Sat, 10 May 2003 12:04:08 -0700
Date: Sat, 10 May 2003 12:04:08 -0700 (PDT)
From: Muthukumar Ratty <muthu@iqmail.net>
To: <linux-mips@linux-mips.org>
cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Subject: MIPS specific ELF doc? (Re: OpenSSL/Binutils Issues)
In-Reply-To: <20030510141959.GB18697@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.33.0305101159250.13866-100000@Muruga.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <muthu@iqmail.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2341
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: muthu@iqmail.net
Precedence: bulk
X-list: linux-mips


Hi,
Where can I get MIPS processor specific ELF document (if there is any?)
Thanks
Muthu.




From kumba@gentoo.org Sat May 10 20:28:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 20:28:03 +0100 (BST)
Received: from smtp-out.comcast.net ([IPv6:::ffff:24.153.64.116]:59640 "EHLO
	smtp-out.comcast.net") by linux-mips.org with ESMTP
	id <S8225290AbTEJT2A>; Sat, 10 May 2003 20:28:00 +0100
Received: from gentoo.org
 (pcp02545003pcs.waldrf01.md.comcast.net [68.48.92.102])
 by mtaout01.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003))
 with ESMTP id <0HEO00MCIREH0Z@mtaout01.icomcast.net> for
 linux-mips@linux-mips.org; Sat, 10 May 2003 15:27:53 -0400 (EDT)
Date: Sat, 10 May 2003 15:30:46 -0400
From: Kumba <kumba@gentoo.org>
Subject: Re: OpenSSL/Binutils Issues
To: linux-mips@linux-mips.org
Reply-to: kumba12345@comcast.net
Message-id: <3EBD5366.70705@gentoo.org>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_LXLHwkY3zK0CyBluimbQ7g)"
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
 Gecko/20030312
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2342
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

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


It's attached in gzip format, as there was quite a bit of a return. 
Many assertion fails and invalid symbol indexes.

Let me know if you need anything more.

--Kumba


Thiemo Wrote:
>Kumba wrote:
[snip]
>> 	Which builds fine.  Then the error hits when attempting to execute 
>> 	the "conftest" executable:
>> 
>> 		./conftest: error while loading shared libraries:
>> 		usr/lib/libcrypto.so.0.9.6: unexpected reloc type 0x68
>
> This libcrypto seems to be broken. 0x68 is not a valid MIPS reloc type
> at all, and a shared lib should use only R_MIPS_32 (type 2) relocations
> anyway.

>> 	Has anyone seen anything like this?  My base mips install on my SGI 
>> Indigo2 is built using binutils-2.13.90.0.16, which builds everything 
>> fine, just doesn't cooperate well with -mips3 or higher options.  I'm 
>> not sure if this is mips-specific, or if I need to bother the OpenSSL 
>> team about it.
>
> It is probably a binutils issue. Can you send the output of
> objdump -R usr/lib/libcrypto.so.0.9.6 |grep R_MIPS |grep -v \(R_MIPS_32\|R_MIPS_NONE\)
> 
> 
> Thiemo









--Boundary_(ID_LXLHwkY3zK0CyBluimbQ7g)
Content-type: application/x-gzip; name=crypto-grep-mips.txt.gz
Content-transfer-encoding: base64
Content-disposition: inline; filename=crypto-grep-mips.txt.gz

H4sICIBRvT4CA2NyeXB0by1ncmVwLW1pcHMudHh0AO2dTWtbVxCG94X8hwvZJAtf3/N55/Uq
lKbQRdKSLusSJEtJVWRJSHaIIT++aut9Qs2UZzELG8mLlznS9TOjo/twfjvu93evFruPy8Vu
NSw3u/u7zfb0+/Nhv/xzdX97GC7eDZenw+JmfXl/Ol5uN8u/f26OD4e7/Xjaj9OosQ9fPh7X
h+Hd+zc//fLr45OLT8P1i3//8r7k6y+PD9/+/Pb19ctn333/4w9XXw9+MR7X23H1sHt5NZwf
7W8Wd5v9bpiGPxanYbP7tNhuVsPp4Xa5356frtafh+kx+vxryGMqo6ZzVOpDnqacUu7D4nRa
H/+J+bDYbIf19kPJF7ebw2m8uUpVLQIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIi
IAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIiIAIigB7wX2/GLnNrX78f+wnp/X+42/sJ
5c2uizf24oUur0+e701P7MVndnnF9b2p7MW7ErOzidlndnls5HY2cueJXR6b2XP25MJc2Iuv
rotv7MWzmT2zmT2zmT2zmW1sZlvy5IKxx2RjM9vYc7axoW9s6Jvr1oaxmW1sZovNbLHnbLGh
Lzb0xYa+2NAXG/piT/pidw2hu4ZNE7s8z0nfpuyaXtgvbWWX19jldXZ5M7s8Y5cnTy4kNnJT
YpeX2eWxoZ/Y0E9s6KfuygU2sxOb2cmV2ZnN7MxmdmYzOxfXS6e6prOJmV2JmdnEzGxiZvbO
RGEjt7CRW9jILewxubDH5MKGfmHvjRR21yjsrlHYXaN63uBtlQ39yoZ+ZUO/sqFf2dCvrpN+
ZTO7spld2cxu7Em/saHf2NBvbOg3NvQbG/psE9Mau2uwVU5jq5zW2V2D7YJad731xVXlNLbK
aZ3NbLYLamwX1NguqLFdUGO7oMZ2QW1mT/psmdRmdtdg26g2u27vzLNrOpvZbBfU2C6oGZvZ
5jpns11QM9dbX9gqp7FVTjP2nM12QY3tghrbBTW2C2psF9TYLqixXVBju6DGdkGN7YIa2wU1
tgsqtgsqVxdUU2YvvrguvrIX39jldXZ5M7s8Y5fn6RWJ7YKK7YKK7YKK7YKK7YKK7YIqsaHP
lknFlkmV2IM620YV20YV20ZVZneNzO4abB9Wmd012EKt2EKt2EKtiqcaJbYPK7YPK7YPK7YP
K7YPq9Jd//HYzP4WnfUJ6WzkutqoYtuoYtuoqq476myZVGyZVJU9JrNtVFVX5FbXDXG2C6rm
+h0kW+UUW+UUW+UUW+UUW+WU66GaYpuYaq7IZYuUYouUYh+qqc5mdq+uVzYbuWwTU2wTU2wT
U2wTU7PrzgRbpBRbpBRbpBRbpBRbpBT7WE+xj/UUW+UUW+WUuUKfbWKKfaynzHU7mn0qp75F
5XxCOhu5bBNTbBNTbBNTckUuW6QUW6QUW6SUXPdG5IpctsYotsYotsYotMZYJ7TGeC7P8SvE
c3p2TS/sl7ayy2vs8jq7vNn1yjb24tnITWzkojXGc3mZXR4b+okN/cSGfmJDH60xnstjd43E
7hqZ3TUyu2tkdtfI7K6R2V0js7tGZneNzO4amd01sjw/aBU29Asb+sV1e6ewmV3YzC5sZhc2
swub2YXN7OLK7MpmdnXdUa/sObuymV3ZzK7N9dJhI7eykVvZyK2uyG1s5Db2mNxcx2RvD/Iv
CfnI4ILZAAA=

--Boundary_(ID_LXLHwkY3zK0CyBluimbQ7g)--

From ica2_ts@csv.ica.uni-stuttgart.de Sat May 10 20:36:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 20:36:44 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:19098
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225290AbTEJTgm>; Sat, 10 May 2003 20:36:42 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19Ea99-00195U-00; Sat, 10 May 2003 21:36:39 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19Ea98-0002g0-00; Sat, 10 May 2003 21:36:38 +0200
Date: Sat, 10 May 2003 21:36:38 +0200
To: Muthukumar Ratty <muthu@iqmail.net>
Cc: linux-mips@linux-mips.org
Subject: Re: MIPS specific ELF doc? (Re: OpenSSL/Binutils Issues)
Message-ID: <20030510193638.GA10445@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030510141959.GB18697@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.33.0305101159250.13866-100000@Muruga.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.33.0305101159250.13866-100000@Muruga.localdomain>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2343
X-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

Muthukumar Ratty wrote:
> 
> Hi,
> Where can I get MIPS processor specific ELF document (if there is any?)

http://www.caldera.com/developers/devspecs/


Thiemo

From drow@false.org Sat May 10 20:43:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 20:44:01 +0100 (BST)
Received: from crack.them.org ([IPv6:::ffff:146.82.138.56]:3310 "EHLO
	crack.them.org") by linux-mips.org with ESMTP id <S8225290AbTEJTn7>;
	Sat, 10 May 2003 20:43:59 +0100
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 19EaGZ-0006P6-00; Sat, 10 May 2003 14:44:20 -0500
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 19EaG7-00048j-00; Sat, 10 May 2003 15:43:51 -0400
Date: Sat, 10 May 2003 15:43:51 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: menkuec@auto-intern.com
Cc: linux-mips@linux-mips.org
Subject: Re: compiling glibc
Message-ID: <20030510194351.GA15891@nevyn.them.org>
References: <200305092145.43690.benmen@gmx.de> <20030510042535.GA2336@nevyn.them.org> <200305101156.08254.benmen@gmx.de> <200305101321.21232.benmen@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200305101321.21232.benmen@gmx.de>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@false.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2344
X-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 Sat, May 10, 2003 at 01:21:21PM +0200, Benjamin Menküc wrote:
> Okay, I fixed this problem by adding --disable-profile:
> 
> [benmen@linuxpc1 mipsel-glibc] LD_LIBRARY_PATH="" CFLAGS="-O2 -g 
> -finline-limit=10000" CC="mipsel-linux-gcc" AS="mipsel-linux-as" 
> ../glibc-2.3.2/configure --build=i686-linux --host=mipsel-linux 
> --enable-add-ons --prefix=/home/benmen/mipsel 
> --with-headers=/home/benmen/mips/kernel/mips-2.4.20/include --disable-profile
> 
> ...
> 
> Now I can compile until this comes:

Try glibc from CVS instead of 2.3.2.  Known bug.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From jbglaw@dvmwest.gt.owl.de Sat May 10 20:49:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 20:49:48 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:22279 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225290AbTEJTtp>; Sat, 10 May 2003 20:49:45 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id D89D04ABD1; Sat, 10 May 2003 21:49:42 +0200 (CEST)
Date: Sat, 10 May 2003 21:49:42 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Message-ID: <20030510194942.GH27494@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <BAY1-F3AmEaJswFCHOz0000b1d9@hotmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="btZF9mwWYNBxqm8J"
Content-Disposition: inline
In-Reply-To: <BAY1-F3AmEaJswFCHOz0000b1d9@hotmail.com>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2345
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


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

On Sat, 2003-05-10 08:56:01 -0700, Michael Anburaj <michaelanburaj@hotmail.=
com>
wrote in message <BAY1-F3AmEaJswFCHOz0000b1d9@hotmail.com>:
> Hi,
>=20
> >"init" is another thing. Your NFS root should include a /sbin/init or
> >or /etc/init or /bin/init or /bin/sh. If none of those exists, you
> >loose.
>=20
>=20
> For setting up the NFS, I did the following:
> 1. exported the /export/RedHat7.1

That's okay.

> 2. downloaded MIPS_RedHat7.1_Release-02.00.tar from=20
> ftp://ftp.mips.com/pub/linux/mips/installation/redhat7.1/02.00
>=20
> this tar file has the following:
>=20
> linux\installation\RedHat7.1\RPMS\mips\ <contains a lot of rpms>
> linux\installation\RedHat7.1\RPMS\mipsel\ <contains a lot of rpms>
> linux\installation\RedHat7.1\RPMS\noarch\ <contains a lot of rpms>
> linux\installation\RedHat7.1\install\ <contains a Makefile, install.list,=
=20
> install.script>
> linux\installation\RedHat7.1\install\root\etc\ <contains inittab, securet=
ty>
> linux\installation\RedHat7.1\install\root\etc\sysconfig\ <contains networ=
k>
> linux\installation\RedHat7.1\install\root\etc\xinetd.d\ <contains telnet,=
=20
> rlogin, rsh,rexec, hosts>
>=20
> & some more files.
>=20
> Now tell me what should be extracted to my NFS export /export/RedHat7.1=
=20
> (along with their relative path info.).

Well, I think you should start reaing the files in the install path
(Makefile, install.list etc.). You should also notice that with Linux
you've got '/' as path separator, not DOSsish '\'.

Basically, I *think* your board is big endian, so you need to unpack
everything from the mips and the noarch directory.

After that, there should be:

/export/Redhat7.1/sbin/init
/export/Redhat7.1/bin/sh

=2E..and all the other files.

> Also let me know what path to be passed on to the kernel as parameter to=
=20
> nfsroot=3D
> Is it simply /export/Redhat7.1?

nfsroot=3Dser.ver.ip.addr:/export/Redhat7.1

> Another question: I don't see a init file in the tar. or is inittab=20
> similar? Is this "MIPS_RedHat7.1_Release-02.00.tar" tar file the right fi=
le=20

If you'd cared to look into that file, it's only a plain text file, no
executable file. So these are different things.

> & the only file that is needed for now; that has the right stuff in it? O=
r=20

Possibly. I've got no chance to look into it and to now you haven't
posted a URL from which I can get that file's contents...

> do I need to get the right file from a different tar file?

Maybe. Maybe not. Depends...

MfG, JBG

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

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

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

iD8DBQE+vVfWHb1edYOZ4bsRAjV4AKCNsZC/spycYWy7Mxc2lFwvhOhnQwCaAz5i
VJUEYljDKumBDi30j0llNrI=
=4aRu
-----END PGP SIGNATURE-----

--btZF9mwWYNBxqm8J--

From michaelanburaj@hotmail.com Sat May 10 22:07:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 May 2003 22:07:50 +0100 (BST)
Received: from bay1-f15.bay1.hotmail.com ([IPv6:::ffff:65.54.245.15]:54538
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225290AbTEJVHr>; Sat, 10 May 2003 22:07:47 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sat, 10 May 2003 14:07:38 -0700
Received: from 4.35.224.219 by by1fd.bay1.hotmail.msn.com with HTTP;
	Sat, 10 May 2003 21:07:38 GMT
X-Originating-IP: [4.35.224.219]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: jbglaw@lug-owl.de, linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Sat, 10 May 2003 14:07:38 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F15L4VKw8SffVL0000b841@hotmail.com>
X-OriginalArrivalTime: 10 May 2003 21:07:38.0791 (UTC) FILETIME=[30077B70:01C31738]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2346
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi JBG,

>Possibly. I've got no chance to look into it and to now you haven't
>posted a URL from which I can get that file's contents...
>


MIPS_RedHat7.1_Release-02.00.tar from
ftp://ftp.mips.com/pub/linux/mips/installation/redhat7.1/02.00


Mean while I will try to do something with tht Makefile & init.script

Thanks a lot,
-Mike.

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


From benmen@gmx.de Sun May 11 01:35:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 May 2003 01:35:30 +0100 (BST)
Received: from nx5.HRZ.Uni-Dortmund.DE ([IPv6:::ffff:129.217.131.21]:51953
	"EHLO nx5.hrz.uni-dortmund.de") by linux-mips.org with ESMTP
	id <S8225299AbTEKAf1> convert rfc822-to-8bit; Sun, 11 May 2003 01:35:27 +0100
Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51])
	by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP
	id 06C654AA1DD; Sun, 11 May 2003 02:35:24 +0200 (MET DST)
Received: from linuxpc1 (p508EFB9C.dip.t-dialin.net [80.142.251.156])
	(authenticated (0 bits))
	by unimail.uni-dortmund.de (8.12.9+Sun/8.11.6) with ESMTP id h4B0ZFtC010632
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NOT);
	Sun, 11 May 2003 02:35:19 +0200 (MEST)
From: Benjamin =?iso-8859-1?q?Menk=FCc?= <benmen@gmx.de>
Reply-To: menkuec@auto-intern.com
To: Daniel Jacobowitz <dan@debian.org>
Subject: Re: compiling glibc
Date: Sun, 11 May 2003 02:35:14 +0200
User-Agent: KMail/1.5.1
References: <200305092145.43690.benmen@gmx.de> <200305101321.21232.benmen@gmx.de> <20030510194351.GA15891@nevyn.them.org>
In-Reply-To: <20030510194351.GA15891@nevyn.them.org>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Message-Id: <200305110235.14606.benmen@gmx.de>
X-MailScanner-Information: UniDo-UniMail
X-MailScanner: Found to be clean
Return-Path: <benmen@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: 2347
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: benmen@gmx.de
Precedence: bulk
X-list: linux-mips

Hi,

now I get this weird error:

...

make[2]: Entering directory `/home/benmen/mips/glibc-cvs/misc'
rm -f /home/benmen/mips/mipsel-glibc/misc/syscall-list.d-t
{ \
 echo '/* Generated at libc build time from kernel syscall list.  */';\
 echo ''; \
 echo '#ifndef _SYSCALL_H'; \
 echo '# error "Never use <bits/syscall.h> directly; include <sys/syscall.h> 
instead."'; \
 echo '#endif'; \
 echo ''; \
 rm -f /home/benmen/mips/mipsel-glibc/misc/syscall-list.h.newt; \
 SUNPRO_DEPENDENCIES='/home/benmen/mips/mipsel-glibc/misc/syscall-list.d-t 
/home/benmen/mips/mipsel-glibc/misc/syscall-list.d' \
 mipsel-linux-gcc -mabi=32 -E -x c -I /home/benmen/mips/mipsel-glibc -nostdinc 
-isystem /home/benmen/mipsel/lib/gcc-lib/mipsel-linux/3.2.3/include -isystem 
/home/benmen/mips/kernel/mips-2.4.20/include 
../sysdeps/unix/sysv/linux/mips/sys/syscall.h -D_LIBC -dM | \
 sed -n 's@^#define __NR_\([^ ]*\) .*$@#define SYS_\1 __NR_\1@p' > 
/home/benmen/mips/mipsel-glibc/misc/syscall-list.h.newt; \
 if grep SYS_O32_ /home/benmen/mips/mipsel-glibc/misc/syscall-list.h.newt > 
/dev/null; then \
   echo '#if defined _ABI64 && _MIPS_SIM == _ABI64'; \
   sed -n 's/^\(#define SYS_\)N64_/\1/p' < 
/home/benmen/mips/mipsel-glibc/misc/syscall-list.h.newt; \
   echo '#elif defined _ABIN32 && _MIPS_SIM == _ABIN32'; \
   sed -n 's/^\(#define SYS_\)N32_/\1/p' < 
/home/benmen/mips/mipsel-glibc/misc/syscall-list.h.newt; \
   echo '#else'; \
   sed -n 's/^\(#define SYS_\)O32_/\1/p' < 
/home/benmen/mips/mipsel-glibc/misc/syscall-list.h.newt; \
   echo '#endif'; \
   sed -n '/^#define SYS_\([ON]32\|N64\)_/p' < 
/home/benmen/mips/mipsel-glibc/misc/syscall-list.h.newt; \
 else \
   cat /home/benmen/mips/mipsel-glibc/misc/syscall-list.h.newt; \
 fi; \
 rm /home/benmen/mips/mipsel-glibc/misc/syscall-list.h.newt; \
} > /home/benmen/mips/mipsel-glibc/misc/syscall-list.h.new
/bin/sh: line 1: /home/benmen/mips/mipsel-glibc/misc/syscall-list.h.new: Datei 
oder Verzeichnis nicht gefunden
mv -f /home/benmen/mips/mipsel-glibc/misc/syscall-list.h.new 
/home/benmen/mips/mipsel-glibc/misc/syscall-list.h
mv: Aufruf von stat für 
ŧ/home/benmen/mips/mipsel-glibc/misc/syscall-list.h.newŦ nicht möglich: Datei 
oder Verzeichnis nicht gefunden
make[2]: *** [/home/benmen/mips/mipsel-glibc/misc/syscall-list.d] Fehler 1
make[2]: Leaving directory `/home/benmen/mips/glibc-cvs/misc'
make[1]: *** [misc/subdir_lib] Fehler 2
make[1]: Leaving directory `/home/benmen/mips/glibc-cvs'
make: *** [all] Fehler 2
Verzeichnis: ~/mips/mipsel-glibc
[benmen@linuxpc1 mipsel-glibc]

regards,

Ben

From agx@sigxcpu.org Sun May 11 10:31:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 May 2003 10:31:53 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:64206
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225193AbTEKJbv>; Sun, 11 May 2003 10:31:51 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id C68992BC36
	for <linux-mips@linux-mips.org>; Sun, 11 May 2003 11:31:48 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 31083-02
 for <linux-mips@linux-mips.org>; Sun, 11 May 2003 11:31:47 +0200 (CEST)
Received: from bogon.sigxcpu.org (kons-d9bb55c8.pool.mediaWays.net [217.187.85.200])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 56ACD2BC35
	for <linux-mips@linux-mips.org>; Sun, 11 May 2003 11:31:47 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 197171737F; Sun, 11 May 2003 11:28:29 +0200 (CEST)
Date: Sun, 11 May 2003 11:28:29 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: compiling glibc
Message-ID: <20030511092828.GA3889@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <200305092145.43690.benmen@gmx.de> <200305101321.21232.benmen@gmx.de> <20030510194351.GA15891@nevyn.them.org> <200305110235.14606.benmen@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200305110235.14606.benmen@gmx.de>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2348
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Sun, May 11, 2003 at 02:35:14AM +0200, Benjamin Menküc wrote:
[..snip..] 
> /bin/sh: line 1: /home/benmen/mips/mipsel-glibc/misc/syscall-list.h.new: Datei 
> oder Verzeichnis nicht gefunden
> mv -f /home/benmen/mips/mipsel-glibc/misc/syscall-list.h.new 
> /home/benmen/mips/mipsel-glibc/misc/syscall-list.h
> mv: Aufruf von stat für 
[..snip..] 

Index: sysdeps/unix/sysv/linux/mips/Makefile
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/mips/Makefile,v
retrieving revision 1.8
diff -u -p -u -r1.8 Makefile
--- sysdeps/unix/sysv/linux/mips/Makefile	17 Mar 2003 15:50:05 -0000	1.8
+++ sysdeps/unix/sysv/linux/mips/Makefile	5 May 2003 08:53:35 -0000
@@ -15,6 +15,7 @@ no_syscall_list_h = 1
 # We generate not only SYS_<syscall>, pointing at SYS_<abi>_<syscall> if
 # it exists, but also define SYS_<abi>_<syscall> for all ABIs.
 $(objpfx)syscall-%.h $(objpfx)syscall-%.d: ../sysdeps/unix/sysv/linux/mips/sys/syscall.h
+	mkdir -p $(objpfx)
 	rm -f $(@:.h=.d)-t
 	{ \
 	 echo '/* Generated at libc build time from kernel syscall list.  */';\

Hope that helps,
 -- Guido

From benmen@gmx.de Sun May 11 11:53:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 May 2003 11:54:01 +0100 (BST)
Received: from nx5.HRZ.Uni-Dortmund.DE ([IPv6:::ffff:129.217.131.21]:9315 "EHLO
	nx5.hrz.uni-dortmund.de") by linux-mips.org with ESMTP
	id <S8225193AbTEKKx4> convert rfc822-to-8bit; Sun, 11 May 2003 11:53:56 +0100
Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51])
	by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id BB5FE4AA7E0
	for <linux-mips@linux-mips.org>; Sun, 11 May 2003 12:53:54 +0200 (MET DST)
Received: from linuxpc1 (p508EDBF0.dip.t-dialin.net [80.142.219.240])
	(authenticated (0 bits))
	by unimail.uni-dortmund.de (8.12.9+Sun/8.11.6) with ESMTP id h4BAr3tC024362
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NOT)
	for <linux-mips@linux-mips.org>; Sun, 11 May 2003 12:53:39 +0200 (MEST)
From: Benjamin =?iso-8859-1?q?Menk=FCc?= <benmen@gmx.de>
Reply-To: menkuec@auto-intern.com
To: linux-mips@linux-mips.org
Subject: Re: compiling glibc
Date: Sun, 11 May 2003 12:52:52 +0200
User-Agent: KMail/1.5.1
References: <200305092145.43690.benmen@gmx.de> <200305110235.14606.benmen@gmx.de> <20030511092828.GA3889@bogon.ms20.nix>
In-Reply-To: <20030511092828.GA3889@bogon.ms20.nix>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Message-Id: <200305111252.52661.benmen@gmx.de>
X-MailScanner-Information: UniDo-UniMail
X-MailScanner: Found to be clean
Return-Path: <benmen@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: 2349
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: benmen@gmx.de
Precedence: bulk
X-list: linux-mips

Now it went a little further until here:

make[2]: Leaving directory `/home/benmen/mips/glibc-cvs/misc'
make[2]: Entering directory `/home/benmen/mips/glibc-cvs/misc'
mipsel-linux-gcc -mabi=32 ../sysdeps/unix/sysv/linux/mips/brk.c -c -std=gnu99 
-O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -finline-limit=10000 
-g      -I../include -I. -I/home/benmen/mips/mipsel-glibc/misc -I.. 
-I../libio  -I/home/benmen/mips/mipsel-glibc -I../sysdeps/mips/elf 
-I../linuxthreads/sysdeps/unix/sysv/linux/mips 
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread 
-I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv 
-I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/mips 
-I../sysdeps/unix/sysv/linux/mips/mips32 -I../sysdeps/unix/sysv/linux/mips 
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common 
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv 
-I../sysdeps/unix/mips/mips32 -I../sysdeps/unix/mips -I../sysdeps/unix 
-I../sysdeps/posix -I../sysdeps/mips/mips32 -I../sysdeps/mips 
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 
-I../sysdeps/wordsize-32 -I../sysdeps/mips/fpu -I../sysdeps/ieee754 
-I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem 
/home/benmen/mipsel/lib/gcc-lib/mipsel-linux/3.2.3/include -isystem 
/home/benmen/mips/kernel/mips-2.4.20/include -D_LIBC_REENTRANT -include 
../include/libc-symbols.h  -DPIC     -o 
/home/benmen/mips/mipsel-glibc/misc/brk.o -MD -MP -MF 
/home/benmen/mips/mipsel-glibc/misc/brk.o.dt
as: Unbekannte Option ŧ-O2Ŧ
make[2]: *** [/home/benmen/mips/mipsel-glibc/misc/brk.o] Fehler 1
make[2]: Leaving directory `/home/benmen/mips/glibc-cvs/misc'
make[1]: *** [misc/subdir_lib] Fehler 2
make[1]: Leaving directory `/home/benmen/mips/glibc-cvs'
make: *** [all] Fehler 2
Verzeichnis: ~/mips/mipsel-glibc
[benmen@linuxpc1 mipsel-glibc]

I am going the try now if it works when I remove the CFLAGS="-O2 ..." from my 
configure line.... however it should be possible to compile it with O2 
shouldn't it?

regards,

Ben

From benmen@gmx.de Sun May 11 12:01:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 May 2003 12:01:17 +0100 (BST)
Received: from nx5.HRZ.Uni-Dortmund.DE ([IPv6:::ffff:129.217.131.21]:4708 "EHLO
	nx5.hrz.uni-dortmund.de") by linux-mips.org with ESMTP
	id <S8225193AbTEKLBP>; Sun, 11 May 2003 12:01:15 +0100
Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51])
	by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id 68DF64AA7E0
	for <linux-mips@linux-mips.org>; Sun, 11 May 2003 13:01:14 +0200 (MET DST)
Received: from linuxpc1 (p508EDBF0.dip.t-dialin.net [80.142.219.240])
	(authenticated (0 bits))
	by unimail.uni-dortmund.de (8.12.9+Sun/8.11.6) with ESMTP id h4BB0rtC024684
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NOT)
	for <linux-mips@linux-mips.org>; Sun, 11 May 2003 13:01:05 +0200 (MEST)
From: Benjamin =?iso-8859-1?q?Menk=FCc?= <benmen@gmx.de>
Reply-To: menkuec@auto-intern.com
To: linux-mips@linux-mips.org
Subject: Re: compiling glibc
Date: Sun, 11 May 2003 13:00:50 +0200
User-Agent: KMail/1.5.1
References: <200305092145.43690.benmen@gmx.de> <20030511092828.GA3889@bogon.ms20.nix> <200305111252.52661.benmen@gmx.de>
In-Reply-To: <200305111252.52661.benmen@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200305111300.50226.benmen@gmx.de>
X-MailScanner-Information: UniDo-UniMail
X-MailScanner: Found to be clean
Return-Path: <benmen@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: 2350
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: benmen@gmx.de
Precedence: bulk
X-list: linux-mips

I have to put some optimization flag into CFLAG="" because otherwise I get the 
error: glibc can't be compiled without optimization...

what should I do?

regards,

Ben

From agx@sigxcpu.org Sun May 11 22:51:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 May 2003 22:51:25 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:3794
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225193AbTEKVvX>; Sun, 11 May 2003 22:51:23 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id AD54D2BC36
	for <linux-mips@linux-mips.org>; Sun, 11 May 2003 23:51:20 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 01509-09
 for <linux-mips@linux-mips.org>; Sun, 11 May 2003 23:51:20 +0200 (CEST)
Received: from bogon.sigxcpu.org (kons-d9bb55c8.pool.mediaWays.net [217.187.85.200])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id C5C332BC35
	for <linux-mips@linux-mips.org>; Sun, 11 May 2003 23:51:19 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id DEB7D1737F; Sun, 11 May 2003 23:48:01 +0200 (CEST)
Date: Sun, 11 May 2003 23:48:01 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: compiling glibc
Message-ID: <20030511214801.GC3889@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <200305092145.43690.benmen@gmx.de> <20030511092828.GA3889@bogon.ms20.nix> <200305111252.52661.benmen@gmx.de> <200305111300.50226.benmen@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200305111300.50226.benmen@gmx.de>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2351
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Sun, May 11, 2003 at 01:00:50PM +0200, Benjamin Menküc wrote:
> I have to put some optimization flag into CFLAG="" because otherwise I get the 
> error: glibc can't be compiled without optimization...
> 
> what should I do?
Does it work when you don't set CFLAGS at all? Please use LC_ALL=C for
the error messages.
 -- Guido

From ladis@linux-mips.org Mon May 12 11:56:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 May 2003 11:56:45 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@sirjeppe-pt.tunnel.tserv1.fmt.ipv6.he.net)) by linux-mips.org
	id <S8225203AbTELK4l>; Mon, 12 May 2003 11:56:41 +0100
Date: Mon, 12 May 2003 11:56:41 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: memory for exception vectors
Message-ID: <20030512115641.F17151@ftp.linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2352
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

Could anyone tell me where is space for exception vectors reserved? Many boards
(for example Alchemy Pb1000, Galileo EV96100 or Galileo EV64120A) simply
registers all available RAM with add_memory_region call, but I didn't find code
which reserves first 0x200 (on most CPUs) for exceptions vectors anywhere. I'd
guess there is something obvious what I'm missing. Can you help me to see it?

Thanks,
	ladis

From jsun@mvista.com Mon May 12 18:44:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 May 2003 18:44:17 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:45038 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225205AbTELRoK>;
	Mon, 12 May 2003 18:44:10 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h4CHi8m24182;
	Mon, 12 May 2003 10:44:08 -0700
Date: Mon, 12 May 2003 10:44:08 -0700
From: Jun Sun <jsun@mvista.com>
To: Ladislav Michl <ladis@linux-mips.org>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: memory for exception vectors
Message-ID: <20030512104408.C24045@mvista.com>
References: <20030512115641.F17151@ftp.linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030512115641.F17151@ftp.linux-mips.org>; from ladis@linux-mips.org on Mon, May 12, 2003 at 11:56:41AM +0100
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2353
X-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, May 12, 2003 at 11:56:41AM +0100, Ladislav Michl wrote:
> Could anyone tell me where is space for exception vectors reserved? Many boards
> (for example Alchemy Pb1000, Galileo EV96100 or Galileo EV64120A) simply
> registers all available RAM with add_memory_region call, but I didn't find code
> which reserves first 0x200 (on most CPUs) for exceptions vectors anywhere. I'd
> guess there is something obvious what I'm missing. Can you help me to see it?
>

Kernel only uses memory after the end of kernel image.  In that sense, all
memory before LOADADDR (see arch/mips/Makefile) is reserved.

Jun

From michaelanburaj@hotmail.com Tue May 13 08:31:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 08:31:20 +0100 (BST)
Received: from bay1-f148.bay1.hotmail.com ([IPv6:::ffff:65.54.245.148]:46095
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225195AbTEMHbR>; Tue, 13 May 2003 08:31:17 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 13 May 2003 00:31:07 -0700
Received: from 4.35.224.219 by by1fd.bay1.hotmail.msn.com with HTTP;
	Tue, 13 May 2003 07:31:07 GMT
X-Originating-IP: [4.35.224.219]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Re: Linux for MIPS Atlas 4Kc board
Date: Tue, 13 May 2003 00:31:07 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F148TJjwW2RbV300012183@hotmail.com>
X-OriginalArrivalTime: 13 May 2003 07:31:07.0772 (UTC) FILETIME=[9E587BC0:01C31921]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2354
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,

>MIPS_RedHat7.1_Release-02.00.tar from
>ftp://ftp.mips.com/pub/linux/mips/installation/redhat7.1/02.00
>

Thats not the right one. The right file for NFS root for mips is the one 
(nfsroot.mips.redhat7.1.eb-01.00.tar.gz) at 
ftp://ftp.mips.com/pub/linux/mips/rootfs_nfs/redhat7.1

I extracted it to my /export/... folder & Linux booted well on the Atlas 
board.

Question:
1. I could see some interactive configuration menus with buttons <'OK' , 
'Cancel' surrounded with a couple of dots>. As I press the tab key to 
navigate to a button, nothing gets highlighted or there isnt a means to know 
a particlar button got selected. Is there a special config in minicom to 
view these better? I even tried the First char of the string to enble it 
<like 'O' for "OK" button & 'C' for Cancel button & 'N' for Next button>, 
but did not work. Please let me know a better way for this.

2. I got this message at last & nothing seems to happen after which <But I 
see a lot of ethernet activity between the Atlas & the host>.

clipping of the messages from linux as seen on minicom:
-----------------------------------------------------------------------------
Starting keytable:  Loading keymap: /etc/rc3.d/S17keytable: /dev/tty0: No 
such e[FAILED]
Loading system font: [  OK  ]
[FAILED]
Initializing random number generator:  [  OK  ]
Mounting other filesystems:  [  OK  ]
Starting automounter:[  OK  ]
Starting atd: [  OK  ]
Starting xinetd: [  OK  ]
Starting NFS file locking services:
Starting NFS lockd: lockdsvc: Function not implemented
[FAILED]
Starting NFS statd: [  OK  ]
Starting postfix: [  OK  ]
Starting crond: [  OK  ]
Starting anacron: [  OK  ]
.?...?..??..?.?..??..?..??.??.?    ???  ?.?  ?. ?  ?????.  ??  ?  ? ??? ? .? 
. ?

3. Did I miss some key configs during the 1st time setup menus? If so, How 
to revisite the linux config menus?

Please advice me. Also point me to relevant documentation. Mean while let me 
search for one...

Thanks,
-Mike.

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


From zhangfei@cnic.ac.cn Tue May 13 09:47:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 09:48:02 +0100 (BST)
Received: from orange.cnc.ac.cn ([IPv6:::ffff:159.226.2.22]:23973 "EHLO
	mail.sdb.ac.cn") by linux-mips.org with ESMTP id <S8225200AbTEMIr7>;
	Tue, 13 May 2003 09:47:59 +0100
Received: from moon (unknown [210.25.135.67])
	by mail.sdb.ac.cn (Postfix) with ESMTP id 64708F7CD3
	for <linux-mips@linux-mips.org>; Tue, 13 May 2003 16:57:06 +0800 (CST)
From: "Zhang Fei" <zhangfei@cnic.ac.cn>
Reply-To: zhangfei@cnic.ac.cn
To: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: Where to get base system for initializing?
Organization: CNIC,CAS of CHINA
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Date: Tue, 13 May 2003 16:47:34 +0800
Message-Id: <20030513085706.64708F7CD3@mail.sdb.ac.cn>
Return-Path: <zhangfei@cnic.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2355
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zhangfei@cnic.ac.cn
Precedence: bulk
X-list: linux-mips

hi all,
   Now, I can boot my SGI-O2(R5000,IP32)box by downloading "vmlinux" kernel through filebootp/dhcp,
It displayed some messages of booting,but stopped at init base system by NFS,because I haven't put any base system files in the NFS root directory.
   
   I googled through all the websites I can,but got nothing I need.  
   Where can I get the proper base system for NFS boot? 

   Thanks for any help in advance :-P

	

 				

Zhang Fei
zhangfei@cnic.ac.cn
2003-05-13
============================================
R&D Division
Computer Network Information Center
Chinese Acdamy of Science
Beijing , China
Tel:010-62536760
Fax:010-62560928
Zip code:100080




From ladis@linux-mips.org Tue May 13 10:51:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 10:51:48 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8225204AbTEMJvp>; Tue, 13 May 2003 10:51:45 +0100
Date: Tue, 13 May 2003 10:51:45 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: memory for exception vectors
Message-ID: <20030513105145.D22288@ftp.linux-mips.org>
References: <20030512115641.F17151@ftp.linux-mips.org> <20030512104408.C24045@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030512104408.C24045@mvista.com>; from jsun@mvista.com on Mon, May 12, 2003 at 10:44:08AM -0700
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2356
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, May 12, 2003 at 10:44:08AM -0700, Jun Sun wrote:
> On Mon, May 12, 2003 at 11:56:41AM +0100, Ladislav Michl wrote:
> > Could anyone tell me where is space for exception vectors reserved? Many boards
> > (for example Alchemy Pb1000, Galileo EV96100 or Galileo EV64120A) simply
> > registers all available RAM with add_memory_region call, but I didn't find code
> > which reserves first 0x200 (on most CPUs) for exceptions vectors anywhere. I'd
> > guess there is something obvious what I'm missing. Can you help me to see it?
> 
> Kernel only uses memory after the end of kernel image.  In that sense, all
> memory before LOADADDR (see arch/mips/Makefile) is reserved.

I'm afraid, I didn't find any code which does what you're describing here.
But in arch/mips/mm/init.c is function setup_zero_pages which allocates
first (or first eight if CPU has VCE) page(s). Does it do the trick?

	ladis

From agx@sigxcpu.org Tue May 13 12:37:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 12:37:20 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:41695
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225204AbTEMLhQ>; Tue, 13 May 2003 12:37:16 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id F091B2BC36; Tue, 13 May 2003 13:37:08 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 13361-09;
 Tue, 13 May 2003 13:37:02 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 7713C2BC35; Tue, 13 May 2003 13:36:57 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id EA5A81737F; Tue, 13 May 2003 13:33:16 +0200 (CEST)
Date: Tue, 13 May 2003 13:33:16 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030513113316.GU3889@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318232454.GA19990@bogon.ms20.nix> <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2357
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Wed, Mar 19, 2003 at 01:16:52AM +0100, Thiemo Seufer wrote:
> Guido Guenther wrote:
> [snip]
> > > -march=BAR:
> > > Allow opcodes for CPU BAR in addition to the ISA ones.
> > > 
> > > -mtune=BAZ:
> > > Optimize opcode scheduling for CPU BAZ.
> > So to build kernels for say IP22 R5k I'd change the current
> > 	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
> > to 
> > 	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
> > where as for R4X00 I use
> > 	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
> > Correct?
> 
> Yes, this should work. You can leave the -mtune out, since it defaults
> to the value of -march anyway.
Just for completeness: I had to use:
	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
to make gcc-3.3 happy (note the 32 instead of o32). gcc-3.2 doesn't seem
to handle these options correctly at all.
 -- Guido

From dkesselr@mmc.atmel.com Tue May 13 14:14:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 14:14:03 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:36378
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225204AbTEMNOB>; Tue, 13 May 2003 14:14:01 +0100
Received: from mmc.atmel.com (pc-11.mmc.atmel.com [10.127.240.141])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA17050
	for <linux-mips@linux-mips.org>; Tue, 13 May 2003 09:13:53 -0400 (EDT)
Message-ID: <3EC0EF90.7090705@mmc.atmel.com>
Date: Tue, 13 May 2003 09:13:52 -0400
From: David Kesselring <dkesselr@mmc.atmel.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: accessing 64bit device
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2358
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

Hello,
We are trying to test a 64bit device implemented in an fpga connected to 
a 5kc on a MIPS Sead board.
My understanding is that linux built in 32bit mode can access this 64bit 
memory controller using a compile or linker option XPHYS.
I cannot find any documentation or examples on how to do this. If you 
have any suggestions or resources that could be useful, please let me know.
Sincerely,
David Kesselring

-- 
--------------------------------
W. David Kesselring
Sr. Software Engineer
Tel  : (919) 462_6587
Fax  : (919) 462_0300
Email: dkesselr@mmc.atmel.com
--------------------------------
Atmel
3800 Gateway Centre, Suite 311
Morrisville, NC 27560
-------------------------------- 



From jsun@mvista.com Tue May 13 17:52:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 17:52:51 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27385 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225215AbTEMQwt>;
	Tue, 13 May 2003 17:52:49 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h4DGqid27220;
	Tue, 13 May 2003 09:52:44 -0700
Date: Tue, 13 May 2003 09:52:44 -0700
From: Jun Sun <jsun@mvista.com>
To: Ladislav Michl <ladis@linux-mips.org>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: memory for exception vectors
Message-ID: <20030513095244.B26990@mvista.com>
References: <20030512115641.F17151@ftp.linux-mips.org> <20030512104408.C24045@mvista.com> <20030513105145.D22288@ftp.linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030513105145.D22288@ftp.linux-mips.org>; from ladis@linux-mips.org on Tue, May 13, 2003 at 10:51:45AM +0100
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2359
X-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, May 13, 2003 at 10:51:45AM +0100, Ladislav Michl wrote:
> On Mon, May 12, 2003 at 10:44:08AM -0700, Jun Sun wrote:
> > On Mon, May 12, 2003 at 11:56:41AM +0100, Ladislav Michl wrote:
> > > Could anyone tell me where is space for exception vectors reserved? Many boards
> > > (for example Alchemy Pb1000, Galileo EV96100 or Galileo EV64120A) simply
> > > registers all available RAM with add_memory_region call, but I didn't find code
> > > which reserves first 0x200 (on most CPUs) for exceptions vectors anywhere. I'd
> > > guess there is something obvious what I'm missing. Can you help me to see it?
> > 
> > Kernel only uses memory after the end of kernel image.  In that sense, all
> > memory before LOADADDR (see arch/mips/Makefile) is reserved.
> 
> I'm afraid, I didn't find any code which does what you're describing here.
> But in arch/mips/mm/init.c is function setup_zero_pages which allocates
> first (or first eight if CPU has VCE) page(s). Does it do the trick?
>

Now you are really pushing me. :)

I figured that out a while back.  I think you can find answers in
arch/mips/kernel/setup.c, 

	start_pfn = PFN_UP(__pa(&_end));

I think zero pages are allocated so that all future read-only zero-filled
pages can be mapped to them.  They are allocated at the beginning of
start_pfn, which is also after kernel image.

Jun 

From ladis@linux-mips.org Tue May 13 18:11:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 18:11:57 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8225215AbTEMRLw>; Tue, 13 May 2003 18:11:52 +0100
Date: Tue, 13 May 2003 18:11:52 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: memory for exception vectors
Message-ID: <20030513181152.A5160@ftp.linux-mips.org>
References: <20030512115641.F17151@ftp.linux-mips.org> <20030512104408.C24045@mvista.com> <20030513105145.D22288@ftp.linux-mips.org> <20030513095244.B26990@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030513095244.B26990@mvista.com>; from jsun@mvista.com on Tue, May 13, 2003 at 09:52:44AM -0700
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2360
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, May 13, 2003 at 09:52:44AM -0700, Jun Sun wrote:
[snip]
> I figured that out a while back.  I think you can find answers in
> arch/mips/kernel/setup.c, 
> 
> 	start_pfn = PFN_UP(__pa(&_end));

Strange I read that file many times, but for yet unknown reason never noticed
__pa(&_end). That's what I call selective blindness :)

> I think zero pages are allocated so that all future read-only zero-filled
> pages can be mapped to them.  They are allocated at the beginning of
> start_pfn, which is also after kernel image.

Thanks a lot for explanation, now I'm sure that MC based memory probing for
IP22 will not break anything. Patch will come tomorrow.

	Ladis

From ica2_ts@csv.ica.uni-stuttgart.de Tue May 13 20:27:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 20:27:41 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:30628
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225221AbTEMT1i>; Tue, 13 May 2003 20:27:38 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19FfR3-001Dfa-00; Tue, 13 May 2003 21:27:37 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19FfR1-000538-00; Tue, 13 May 2003 21:27:35 +0200
Date: Tue, 13 May 2003 21:27:35 +0200
To: linux-mips@linux-mips.org
Cc: Guido Guenther <agx@sigxcpu.org>
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030513192735.GA16497@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318232454.GA19990@bogon.ms20.nix> <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de> <20030513113316.GU3889@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030513113316.GU3889@bogon.ms20.nix>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2361
X-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

Guido Guenther wrote:
[snip]
> > > So to build kernels for say IP22 R5k I'd change the current
> > > 	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
> > > to 
> > > 	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
> > > where as for R4X00 I use
> > > 	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
> > > Correct?
> > 
> > Yes, this should work. You can leave the -mtune out, since it defaults
> > to the value of -march anyway.
> Just for completeness: I had to use:
> 	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
> to make gcc-3.3 happy (note the 32 instead of o32).

Yes, IIRC 64 vs. n64 has the same problem.

> gcc-3.2 doesn't seem
> to handle these options correctly at all.

AFAICS you can still drop the -mtune part.


Thiemo

From drow@false.org Tue May 13 20:36:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 20:36:53 +0100 (BST)
Received: from crack.them.org ([IPv6:::ffff:146.82.138.56]:61843 "EHLO
	crack.them.org") by linux-mips.org with ESMTP id <S8225221AbTEMTgv>;
	Tue, 13 May 2003 20:36:51 +0100
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 19Ffa3-00070H-00; Tue, 13 May 2003 14:36:55 -0500
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 19FfZZ-0003fU-00; Tue, 13 May 2003 15:36:25 -0400
Date: Tue, 13 May 2003 15:36:25 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org, Guido Guenther <agx@sigxcpu.org>
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030513193625.GA14066@nevyn.them.org>
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318232454.GA19990@bogon.ms20.nix> <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de> <20030513113316.GU3889@bogon.ms20.nix> <20030513192735.GA16497@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030513192735.GA16497@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@false.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2362
X-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, May 13, 2003 at 09:27:35PM +0200, Thiemo Seufer wrote:
> Guido Guenther wrote:
> [snip]
> > > > So to build kernels for say IP22 R5k I'd change the current
> > > > 	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
> > > > to 
> > > > 	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
> > > > where as for R4X00 I use
> > > > 	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
> > > > Correct?
> > > 
> > > Yes, this should work. You can leave the -mtune out, since it defaults
> > > to the value of -march anyway.
> > Just for completeness: I had to use:
> > 	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
> > to make gcc-3.3 happy (note the 32 instead of o32).
> 
> Yes, IIRC 64 vs. n64 has the same problem.

That's not quite the same: 64 is o64, n64 is n64.  GCC's never called
the 32-bit ABI "o32".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ica2_ts@csv.ica.uni-stuttgart.de Tue May 13 20:59:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 20:59:37 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:41380
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225221AbTEMT7d>; Tue, 13 May 2003 20:59:33 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19Ffvs-001Cuo-00; Tue, 13 May 2003 21:59:28 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19Ffvs-000554-00; Tue, 13 May 2003 21:59:28 +0200
Date: Tue, 13 May 2003 21:59:28 +0200
To: Daniel Jacobowitz <dan@debian.org>
Cc: linux-mips@linux-mips.org, Guido Guenther <agx@sigxcpu.org>
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030513195928.GB16497@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318232454.GA19990@bogon.ms20.nix> <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de> <20030513113316.GU3889@bogon.ms20.nix> <20030513192735.GA16497@rembrandt.csv.ica.uni-stuttgart.de> <20030513193625.GA14066@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030513193625.GA14066@nevyn.them.org>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2363
X-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

Daniel Jacobowitz wrote:
[snip]
> > > Just for completeness: I had to use:
> > > 	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
> > > to make gcc-3.3 happy (note the 32 instead of o32).
> > 
> > Yes, IIRC 64 vs. n64 has the same problem.
> 
> That's not quite the same: 64 is o64, n64 is n64.

I don't think so (There's -mabi=o64).
Otherwise I would have built all my NewABI 64bit Executables as
o64 without noticing ever. :-)

> GCC's never called the 32-bit ABI "o32".

True, but it might be clearer if it did.


Thiemo

From agx@sigxcpu.org Tue May 13 21:15:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 21:15:33 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:61411
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225221AbTEMUP3>; Tue, 13 May 2003 21:15:29 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 5A2CD2BC37
	for <linux-mips@linux-mips.org>; Tue, 13 May 2003 22:15:25 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 16299-06
 for <linux-mips@linux-mips.org>; Tue, 13 May 2003 22:15:24 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 6FE722BC35
	for <linux-mips@linux-mips.org>; Tue, 13 May 2003 22:15:24 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id D58631737F; Tue, 13 May 2003 22:11:44 +0200 (CEST)
Date: Tue, 13 May 2003 22:11:44 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030513201144.GY3889@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318232454.GA19990@bogon.ms20.nix> <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de> <20030513113316.GU3889@bogon.ms20.nix> <20030513192735.GA16497@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030513192735.GA16497@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2364
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Tue, May 13, 2003 at 09:27:35PM +0200, Thiemo Seufer wrote:
> Guido Guenther wrote:
[..snip..] 
> > to make gcc-3.3 happy (note the 32 instead of o32).
> 
> Yes, IIRC 64 vs. n64 has the same problem.
I think 64 is o64 not n64.

> > gcc-3.2 doesn't seem
> > to handle these options correctly at all.
> 
> AFAICS you can still drop the -mtune part.
Yes, thanks for pointing this out. I'm just leaving this in the Makefile
to know what to change if I want to tune for another cpu.
 -- Guido

From ica2_ts@csv.ica.uni-stuttgart.de Tue May 13 21:50:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 21:50:27 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:421
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225229AbTEMUuX>; Tue, 13 May 2003 21:50:23 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19Fgj8-001DTa-00; Tue, 13 May 2003 22:50:22 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19Fgj8-0005BX-00; Tue, 13 May 2003 22:50:22 +0200
Date: Tue, 13 May 2003 22:50:21 +0200
To: Guido Guenther <agx@sigxcpu.org>
Cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030513205021.GC16497@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318232454.GA19990@bogon.ms20.nix> <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de> <20030513113316.GU3889@bogon.ms20.nix> <20030513192735.GA16497@rembrandt.csv.ica.uni-stuttgart.de> <20030513201144.GY3889@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030513201144.GY3889@bogon.ms20.nix>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2365
X-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

Guido Guenther wrote:
> On Tue, May 13, 2003 at 09:27:35PM +0200, Thiemo Seufer wrote:
> > Guido Guenther wrote:
> [..snip..] 
> > > to make gcc-3.3 happy (note the 32 instead of o32).
> > 
> > Yes, IIRC 64 vs. n64 has the same problem.
> I think 64 is o64 not n64.

Strange, you are now the second to say so. Where does this idea stem from?

I just had a look at the gcc sources, the mips*-linux config doesn't
support o64 at all.


Thiemo

From agx@sigxcpu.org Tue May 13 23:25:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 May 2003 23:25:57 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:54656
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225197AbTEMWZq>; Tue, 13 May 2003 23:25:46 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 0967B2BC35
	for <linux-mips@linux-mips.org>; Wed, 14 May 2003 00:25:46 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 17580-01
 for <linux-mips@linux-mips.org>; Wed, 14 May 2003 00:25:37 +0200 (CEST)
Received: from bogon.sigxcpu.org (kons-d9bb542e.pool.mediaWays.net [217.187.84.46])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id B8AAD2BC33
	for <linux-mips@linux-mips.org>; Wed, 14 May 2003 00:25:36 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id DE8891737F; Wed, 14 May 2003 00:22:15 +0200 (CEST)
Date: Wed, 14 May 2003 00:22:15 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030513222215.GA440@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318232454.GA19990@bogon.ms20.nix> <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de> <20030513113316.GU3889@bogon.ms20.nix> <20030513192735.GA16497@rembrandt.csv.ica.uni-stuttgart.de> <20030513201144.GY3889@bogon.ms20.nix> <20030513205021.GC16497@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030513205021.GC16497@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2366
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Tue, May 13, 2003 at 10:50:21PM +0200, Thiemo Seufer wrote:
> I just had a look at the gcc sources, the mips*-linux config doesn't
> support o64 at all.
It seems I was wrong (I got confused by the way the kernel calls gcc).
Looking at gcc-3.3:

#define ABI_32  0
#define ABI_N32 1
#define ABI_64  2
#define ABI_EABI 3
#define ABI_O64  4

The naming is very "unfortunate", though. We have (n32,64) and (32,o64).
Wouldn't it help to at least allow for n64 and o32 commandline options?
-mabi=32 and -mabi=64 will have to be kept for Irix compatibility
though, I think.
 -- Guido

From ladis@linux-mips.org Wed May 14 08:54:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 08:54:30 +0100 (BST)
Received: from ftp.ckdenergo.cz ([IPv6:::ffff:80.95.97.155]:14579 "EHLO simek")
	by linux-mips.org with ESMTP id <S8224861AbTENHy2>;
	Wed, 14 May 2003 08:54:28 +0100
Received: from ladis by simek with local (Exim 3.36 #1 (Debian))
	id 19Fr5C-0001EN-00; Wed, 14 May 2003 09:53:50 +0200
Date: Wed, 14 May 2003 09:53:40 +0200
To: linux-mips@linux-mips.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Subject: [PATCH] High memory detection for Indigo2
Message-ID: <20030514075340.GA4710@simek>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
From: Ladislav Michl <ladis@linux-mips.org>
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2367
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

Hi,

this is second version of high memory detection for Indigo2.
It will allow to use more that 256M RAM. I was told by Ralf that
CONFIG_HIGHMEM is broken for I2, so you'll need to build 64bit
kernel to use it (I was also told there is more bugs related to
high memory support and I think that once high memory is detected
properly more people will be interested in hunting those bugs :))
Patch also completely replaces ARCS based memory detection by
memory controller based one. We need to read memory configuration
from MC anyway, so this will make kernel a bit smaller.


Index: arch/mips/sgi-ip22/ip22-mc.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip22/ip22-mc.c,v
retrieving revision 1.1.2.7
diff -u -r1.1.2.7 ip22-mc.c
--- arch/mips/sgi-ip22/ip22-mc.c	6 Apr 2003 01:47:27 -0000	1.1.2.7
+++ arch/mips/sgi-ip22/ip22-mc.c	14 May 2003 07:37:53 -0000
@@ -1,51 +1,111 @@
 /*
- * ip22-mc.c: Routines for manipulating the INDY memory controller.
+ * ip22-mc.c: Routines for manipulating SGI Memory Controller.
  *
  * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com)
  * Copyright (C) 1999 Andrew R. Baker (andrewb@uab.edu) - Indigo2 changes
+ * Copyright (C) 2003 Ladislav Michl  (ladis@linux-mips.org)
  */
 
 #include <linux/init.h>
 #include <linux/kernel.h>
 
 #include <asm/addrspace.h>
+#include <asm/bootinfo.h>
 #include <asm/ptrace.h>
 #include <asm/sgialib.h>
 #include <asm/sgi/mc.h>
 #include <asm/sgi/hpc3.h>
 #include <asm/sgi/ip22.h>
 
-/* #define DEBUG_SGIMC */
-
 struct sgimc_regs *sgimc;
 
-#ifdef DEBUG_SGIMC
-static inline char *mconfig_string(unsigned long val)
+static inline unsigned int get_bank_size(unsigned int val)
 {
 	switch(val & SGIMC_MCONFIG_RMASK) {
-	case SGIMC_MCONFIG_FOURMB:
-		return "4MB";
-
-	case SGIMC_MCONFIG_EIGHTMB:
-		return "8MB";
+	case SGIMC_MCONFIG_256K: return 4*4*256 * 1024;
+	case SGIMC_MCONFIG_512K: return 4*4*512 * 1024;
+	case SGIMC_MCONFIG_1M:   return 4*4*1024 * 1024;
+	case SGIMC_MCONFIG_2M:   return 4*4*2048 * 1024;
+	case SGIMC_MCONFIG_4M:   return 4*4*4096 * 1024;
+	case SGIMC_MCONFIG_8M:   return 4*4*8192 * 1024;
+	default:                 return 0;
+	}
+}
 
-	case SGIMC_MCONFIG_SXTEENMB:
-		return "16MB";
+static inline unsigned int get_bank_config(int bank)
+{
+	unsigned int res = bank > 1 ? sgimc->mconfig1 : sgimc->mconfig0;
+	return bank % 2 ? res & 0xffff : res >> 16;
+}
 
-	case SGIMC_MCONFIG_TTWOMB:
-		return "32MB";
+struct mem {
+	unsigned long addr;
+	unsigned long size;
+};
 
-	case SGIMC_MCONFIG_SFOURMB:
-		return "64MB";
+/*
+ * Detect installed memory, do some sanity checks and notify kernel about it
+ */
+static void probe_memory(void)
+{
+	int i, j, found, cnt = 0;
+	struct mem bank[4];
+	struct mem space[2] = {{SGIMC_SEG0_BADDR, 0}, {SGIMC_SEG1_BADDR, 0}};
+
+	printk(KERN_INFO "MC: Probing memory configuration:\n");
+	for (i = 0; i < ARRAY_SIZE(bank); i++) {
+		int tmp = get_bank_config(i);
+		if (!(tmp & SGIMC_MCONFIG_BVALID))
+			continue;
+
+		if (!(bank[cnt].size = get_bank_size(tmp))) {
+			printk(KERN_WARNING " bank%d: unknown, ignored\n", i);
+			continue;
+		}
 
-	case SGIMC_MCONFIG_OTEIGHTMB:
-		return "128MB";
+		bank[cnt].addr = (tmp & SGIMC_MCONFIG_BASEADDR) << 22;
+		printk(KERN_INFO " bank%d: %3ldM @ %08lx\n",
+			i, bank[cnt].size / 1024 / 1024, bank[cnt].addr);
+		cnt++;
+	}
 
-	default:
-		return "wheee, unknown";
+	/* And you thought bubble sort is dead algorithm... */
+	do {
+		unsigned long addr, size;
+
+		found = 0;
+		for (i = 1; i < cnt; i++)
+			if (bank[i-1].addr > bank[i].addr) {
+				addr = bank[i].addr;
+				size = bank[i].size;
+				bank[i].addr = bank[i-1].addr;
+				bank[i].size = bank[i-1].size;
+				bank[i-1].addr = addr;
+				bank[i-1].size = size;
+				found = 1;
+			}
+	} while (found);
+
+	/* Figure out how are memory banks mapped into spaces */
+	for (i = 0; i < cnt; i++) {
+		found = 0;
+		for (j = 0; j < ARRAY_SIZE(space) && !found; j++)
+			if (space[j].addr + space[j].size == bank[i].addr) {
+				space[j].size += bank[i].size;
+				found = 1;
+			}
+		/* There is either hole or overlapping memory */
+		if (!found)
+			printk(KERN_CRIT "MC: Memory configuration mismatch "
+					 "(%08lx), expect Bus Error soon\n",
+					 bank[i].addr);
 	}
+
+	for (i = 0; i < ARRAY_SIZE(space); i++)
+		if (space[i].size)
+			add_memory_region(space[i].addr, space[i].size,
+					  BOOT_MEM_RAM);
 }
-#endif
 
 void __init sgimc_init(void)
 {
@@ -56,17 +116,6 @@
 	printk(KERN_INFO "MC: SGI memory controller Revision %d\n",
 	       (int) sgimc->systemid & SGIMC_SYSID_MASKREV);
 
-#ifdef DEBUG_SGIMC
-	prom_printf("sgimc_init: memconfig0<%s> mconfig1<%s>\n",
-		    mconfig_string(sgimc->mconfig0),
-		    mconfig_string(sgimc->mconfig1));
-
-	prom_printf("mcdump: cpuctrl0<%08lx> cpuctrl1<%08lx>\n",
-		    sgimc->cpuctrl0, sgimc->cpuctrl1);
-	prom_printf("mcdump: divider<%08lx>, gioparm<%04x>\n",
-		    sgimc->divider, sgimc->gioparm);
-#endif
-
 	/* Place the MC into a known state.  This must be done before
 	 * interrupts are first enabled etc.
 	 */
@@ -126,27 +175,32 @@
 	 */
 
 	/* First the basic invariants across all GIO64 implementations. */
-	tmp = SGIMC_GIOPAR_HPC64;    /* All 1st HPC's interface at 64bits. */
-	tmp |= SGIMC_GIOPAR_ONEBUS;  /* Only one physical GIO bus exists. */
+	tmp = SGIMC_GIOPAR_HPC64;	/* All 1st HPC's interface at 64bits */
+	tmp |= SGIMC_GIOPAR_ONEBUS;	/* Only one physical GIO bus exists */
 
 	if (ip22_is_fullhouse()) {
 		/* Fullhouse specific settings. */
 		if (SGIOC_SYSID_BOARDREV(sgioc->sysid) < 2) {
-			tmp |= SGIMC_GIOPAR_HPC264; /* 2nd HPC at 64bits */
-			tmp |= SGIMC_GIOPAR_PLINEEXP0; /* exp0 pipelines */
-			tmp |= SGIMC_GIOPAR_MASTEREXP1;/* exp1 masters */
-			tmp |= SGIMC_GIOPAR_RTIMEEXP0; /* exp0 is realtime */
+			tmp |= SGIMC_GIOPAR_HPC264;	/* 2nd HPC at 64bits */
+			tmp |= SGIMC_GIOPAR_PLINEEXP0;	/* exp0 pipelines */
+			tmp |= SGIMC_GIOPAR_MASTEREXP1;	/* exp1 masters */
+			tmp |= SGIMC_GIOPAR_RTIMEEXP0;	/* exp0 is realtime */
 		} else {
-			tmp |= SGIMC_GIOPAR_HPC264; /* 2nd HPC 64bits */
-			tmp |= SGIMC_GIOPAR_PLINEEXP0; /* exp[01] pipelined */
+			tmp |= SGIMC_GIOPAR_HPC264;	/* 2nd HPC 64bits */
+			tmp |= SGIMC_GIOPAR_PLINEEXP0;	/* exp[01] pipelined */
 			tmp |= SGIMC_GIOPAR_PLINEEXP1;
-			tmp |= SGIMC_GIOPAR_MASTEREISA;/* EISA masters */
-			tmp |= SGIMC_GIOPAR_GFX64; 	/* GFX at 64 bits */
+			tmp |= SGIMC_GIOPAR_MASTEREISA;	/* EISA masters */
+			tmp |= SGIMC_GIOPAR_GFX64;	/* GFX at 64 bits */
 		}
 	} else {
 		/* Guiness specific settings. */
-		tmp |= SGIMC_GIOPAR_EISA64;     /* MC talks to EISA at 64bits */
-		tmp |= SGIMC_GIOPAR_MASTEREISA; /* EISA bus can act as master */
+		tmp |= SGIMC_GIOPAR_EISA64;	/* MC talks to EISA at 64bits */
+		tmp |= SGIMC_GIOPAR_MASTEREISA;	/* EISA bus can act as master */
 	}
-	sgimc->giopar = tmp; /* poof */
+	sgimc->giopar = tmp;	/* poof */
+
+	probe_memory();
 }
+
+void __init prom_meminit(void) {}
+void __init prom_free_prom_memory (void) {}
Index: arch/mips/config-shared.in
===================================================================
RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v
retrieving revision 1.1.2.59
diff -u -r1.1.2.59 config-shared.in
--- arch/mips/config-shared.in	5 May 2003 07:50:48 -0000	1.1.2.59
+++ arch/mips/config-shared.in	14 May 2003 07:37:53 -0000
@@ -481,7 +481,6 @@
 fi
 if [ "$CONFIG_SGI_IP22" = "y" ]; then
    define_bool CONFIG_ARC32 y
-   define_bool CONFIG_ARC_MEMORY y
    define_bool CONFIG_ARC_PROMLIB y
    define_bool CONFIG_BOARD_SCACHE y
    define_bool CONFIG_BOOT_ELF32 y
Index: include/asm-mips/sgi/mc.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/sgi/mc.h,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 mc.h
--- include/asm-mips/sgi/mc.h	27 Apr 2003 22:25:28 -0000	1.1.2.2
+++ include/asm-mips/sgi/mc.h	14 May 2003 07:37:53 -0000
@@ -95,19 +95,22 @@
 	u32 _unused10[3];
 	volatile u32 lbursttp;	/* Time period for long bursts */
 
+	/* MC chip can drive up to 4 bank 4 SIMMs each. All SIMMs in bank must
+	 * be the same size. The size encoding for supported SIMMs is bellow */
 	u32 _unused11[9];
 	volatile u32 mconfig0;	/* Memory config register zero */
 	u32 _unused12;
 	volatile u32 mconfig1;	/* Memory config register one */
-
-	/* These defines apply to both mconfig registers above. */
-#define SGIMC_MCONFIG_FOURMB	0x00000000 /* Physical ram = 4megs */
-#define SGIMC_MCONFIG_EIGHTMB	0x00000100 /* Physical ram = 8megs */
-#define SGIMC_MCONFIG_SXTEENMB	0x00000300 /* Physical ram = 16megs */
-#define SGIMC_MCONFIG_TTWOMB	0x00000700 /* Physical ram = 32megs */
-#define SGIMC_MCONFIG_SFOURMB	0x00000f00 /* Physical ram = 64megs */
-#define SGIMC_MCONFIG_OTEIGHTMB	0x00001f00 /* Physical ram = 128megs */
+#define SGIMC_MCONFIG_BASEADDR	0x000000ff /* Base address of bank*/
+#define SGIMC_MCONFIG_256K	0x00000000 /* 256k x 36 bits */
+#define SGIMC_MCONFIG_512K	0x00000100 /* 512k x 36 bits, 2 subbanks */
+#define SGIMC_MCONFIG_1M	0x00000300 /* 1M   x 36 bits */
+#define SGIMC_MCONFIG_2M	0x00000700 /* 2M   x 36 bits, 2 subbanks */
+#define SGIMC_MCONFIG_4M	0x00000f00 /* 4M   x 36 bits */
+#define SGIMC_MCONFIG_8M	0x00001f00 /* 8M   x 36 bits, 2 subbanks */
 #define SGIMC_MCONFIG_RMASK	0x00001f00 /* Ram config bitmask */
+#define SGIMC_MCONFIG_BVALID	0x00002000 /* Bank is valid */
+#define SGIMC_MCONFIG_SBANKS	0x00004000 /* Number of subbanks */
 
 	u32 _unused13;
 	volatile u32 cmacc;        /* Mem access config for CPU */
Index: include/asm-mips64/sgi/mc.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/sgi/mc.h,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 mc.h
--- include/asm-mips64/sgi/mc.h	27 Apr 2003 22:25:28 -0000	1.1.2.2
+++ include/asm-mips64/sgi/mc.h	14 May 2003 07:37:53 -0000
@@ -95,19 +95,22 @@
 	u32 _unused10[3];
 	volatile u32 lbursttp;	/* Time period for long bursts */
 
+	/* MC chip can drive up to 4 bank 4 SIMMs each. All SIMMs in bank must
+	 * be the same size. The size encoding for supported SIMMs is bellow */
 	u32 _unused11[9];
 	volatile u32 mconfig0;	/* Memory config register zero */
 	u32 _unused12;
 	volatile u32 mconfig1;	/* Memory config register one */
-
-	/* These defines apply to both mconfig registers above. */
-#define SGIMC_MCONFIG_FOURMB	0x00000000 /* Physical ram = 4megs */
-#define SGIMC_MCONFIG_EIGHTMB	0x00000100 /* Physical ram = 8megs */
-#define SGIMC_MCONFIG_SXTEENMB	0x00000300 /* Physical ram = 16megs */
-#define SGIMC_MCONFIG_TTWOMB	0x00000700 /* Physical ram = 32megs */
-#define SGIMC_MCONFIG_SFOURMB	0x00000f00 /* Physical ram = 64megs */
-#define SGIMC_MCONFIG_OTEIGHTMB	0x00001f00 /* Physical ram = 128megs */
+#define SGIMC_MCONFIG_BASEADDR	0x000000ff /* Base address of bank*/
+#define SGIMC_MCONFIG_256K	0x00000000 /* 256k x 36 bits */
+#define SGIMC_MCONFIG_512K	0x00000100 /* 512k x 36 bits, 2 subbanks */
+#define SGIMC_MCONFIG_1M	0x00000300 /* 1M   x 36 bits */
+#define SGIMC_MCONFIG_2M	0x00000700 /* 2M   x 36 bits, 2 subbanks */
+#define SGIMC_MCONFIG_4M	0x00000f00 /* 4M   x 36 bits */
+#define SGIMC_MCONFIG_8M	0x00001f00 /* 8M   x 36 bits, 2 subbanks */
 #define SGIMC_MCONFIG_RMASK	0x00001f00 /* Ram config bitmask */
+#define SGIMC_MCONFIG_BVALID	0x00002000 /* Bank is valid */
+#define SGIMC_MCONFIG_SBANKS	0x00004000 /* Number of subbanks */
 
 	u32 _unused13;
 	volatile u32 cmacc;        /* Mem access config for CPU */

From achim.hensel@ruhr-uni-bochum.de Wed May 14 11:29:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 11:29:28 +0100 (BST)
Received: from mout2.freenet.de ([IPv6:::ffff:194.97.50.155]:57490 "EHLO
	mout2.freenet.de") by linux-mips.org with ESMTP id <S8224861AbTENK3Y>;
	Wed, 14 May 2003 11:29:24 +0100
Received: from [194.97.50.144] (helo=mx1.freenet.de)
	by mout2.freenet.de with asmtp (Exim 4.15)
	id 19FtVi-00050C-Gx
	for linux-mips@linux-mips.org; Wed, 14 May 2003 12:29:22 +0200
Received: from p508f6cc2.dip.t-dialin.net ([80.143.108.194] helo=server.private.priv)
	by mx1.freenet.de with asmtp (ID aspam@freenet.de) (Exim 4.15 #3)
	id 19FtVi-00080d-2e
	for linux-mips@linux-mips.org; Wed, 14 May 2003 12:29:22 +0200
Received: from physik.private.priv (physik.private.priv [192.168.1.10])
	by server.private.priv (8.12.6/8.12.6) with SMTP id h4EATJqR079205
	for <linux-mips@linux-mips.org>; Wed, 14 May 2003 12:29:20 +0200 (CEST)
Date: Wed, 14 May 2003 12:31:44 +0200
From: Achim Hensel <achim.hensel@ruhr-uni-bochum.de>
To: linux-mips@linux-mips.org
Subject: Branch relocation fixing at Kernel-compiling with Debian-toolchain
Message-Id: <20030514123144.52da1d81.achim.hensel@ruhr-uni-bochum.de>
X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd4.7)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <achim.hensel@ruhr-uni-bochum.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2368
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: achim.hensel@ruhr-uni-bochum.de
Precedence: bulk
X-list: linux-mips

Hello, folks 

[I try to build Linux for a R4k Indigo1. I'm using as and ld of the
debian-toolchain with mips-linux-as/mips-linux-ld 2.13.90.0.18
20030121. At the moment, the kernel just compiles, but is not bootable
due to further adaption.]

As I'm not much into MIPS or gas assembler (most experience with 6502),
I would like to have some hints how to work around some kernel-compiling
errors:

When compiling the linux-mips.org kernel from the CVS-MAIN branch,
compiling stopped, as expected at the two assembler files 
entry.S and scall_o32.S in linux/arch/mips/kernel/ (both recent
versions) with a BFD-RELOC_16_PCREL_S2. 

The fix of combining global/local label, mentioned in 
http://sources.redhat.com/ml/binutils/2003-02/msg00205.htm
and other places, got me around the problem. Not every branch needed the
fix. Just one error remains:

In entry.S rev 1.49, around line 63, the branch target label
resume_kernel is defined by either a line statement
(ENTRY(resume_kernel), l.79) or a #definition from an other label (l.
52), depending on some #Config-options.

As work around I hardwired the branch label to one of them.

Any hints to adapt the fix to this problem? 
Diff/Patch for the rest will be posted if requested.

[Now working on with ELF2ECOFF converting]

CU,
	Achim

From agx@sigxcpu.org Wed May 14 11:41:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 11:41:06 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:38789
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8224861AbTENKlE>; Wed, 14 May 2003 11:41:04 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 046942BC34
	for <linux-mips@linux-mips.org>; Wed, 14 May 2003 12:41:03 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 21271-07
 for <linux-mips@linux-mips.org>; Wed, 14 May 2003 12:41:02 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 236B12BC33
	for <linux-mips@linux-mips.org>; Wed, 14 May 2003 12:41:02 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id CDAFB1737F; Wed, 14 May 2003 12:40:40 +0200 (CEST)
Date: Wed, 14 May 2003 12:40:40 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: Branch relocation fixing at Kernel-compiling with Debian-toolchain
Message-ID: <20030514104040.GZ3889@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <20030514123144.52da1d81.achim.hensel@ruhr-uni-bochum.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030514123144.52da1d81.achim.hensel@ruhr-uni-bochum.de>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2369
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Wed, May 14, 2003 at 12:31:44PM +0200, Achim Hensel wrote:
> [I try to build Linux for a R4k Indigo1. I'm using as and ld of the
> debian-toolchain with mips-linux-as/mips-linux-ld 2.13.90.0.18
> 20030121. At the moment, the kernel just compiles, but is not bootable
> due to further adaption.]
The simplest fix probably is to use 2.14.90.0.1. I have debs for mips
here if this is of any use.
 -- Guido

From macro@ds2.pg.gda.pl Wed May 14 11:52:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 11:52:55 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:4555 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTENKwx>; Wed, 14 May 2003 11:52:53 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA26330;
	Wed, 14 May 2003 12:53:33 +0200 (MET DST)
Date: Wed, 14 May 2003 12:53:32 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Guido Guenther <agx@sigxcpu.org>
cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
In-Reply-To: <20030513222215.GA440@bogon.ms20.nix>
Message-ID: <Pine.GSO.3.96.1030514124924.26213A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2370
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 14 May 2003, Guido Guenther wrote:

> Looking at gcc-3.3:
> 
> #define ABI_32  0
> #define ABI_N32 1
> #define ABI_64  2
> #define ABI_EABI 3
> #define ABI_O64  4
> 
> The naming is very "unfortunate", though. We have (n32,64) and (32,o64).
> Wouldn't it help to at least allow for n64 and o32 commandline options?
> -mabi=32 and -mabi=64 will have to be kept for Irix compatibility
> though, I think.

 Why unfortunate?  You use "32" and "64" for normal stuff, and the rest
for special cases ("n32" isn't really 32-bit and "o64" isn't really 64-bit
-- both lie in the middle).  Additional aliases of the "n64" and "o32"
form would make more confusion, IMHO. 

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


From rjh@cita.utoronto.ca Wed May 14 12:02:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 12:02:32 +0100 (BST)
Received: from rail.cita.utoronto.ca ([IPv6:::ffff:128.100.76.4]:58029 "EHLO
	rail.cita.utoronto.ca") by linux-mips.org with ESMTP
	id <S8224861AbTENLC3>; Wed, 14 May 2003 12:02:29 +0100
Received: from [128.100.76.51] (falcon.cita.utoronto.ca) by rail.cita.utoronto.ca id 20621; Wed, 14 May 2003 07:02:28
Received: from falcon.cita.utoronto.ca (localhost [127.0.0.1])
	by cita.utoronto.ca (8.12.8/8.12.5) with ESMTP id h4EB2SVk008615;
	Wed, 14 May 2003 07:02:28 -0400
Received: (from rjh@localhost)
	by falcon.cita.utoronto.ca (8.12.8/8.12.8/Submit) id h4EB2SOa008613;
	Wed, 14 May 2003 07:02:28 -0400
Date: Wed, 14 May 2003 07:02:27 -0400
From: Robin Humble <rjh@cita.utoronto.ca>
To: Achim Hensel <achim.hensel@ruhr-uni-bochum.de>
Cc: linux-mips@linux-mips.org
Subject: r4k Indigo 1 (was Re: Branch relocation fixing at Kernel-compiling with Debian-toolchain)
Message-ID: <20030514110227.GA8503@falcon.cita.utoronto.ca>
References: <20030514123144.52da1d81.achim.hensel@ruhr-uni-bochum.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030514123144.52da1d81.achim.hensel@ruhr-uni-bochum.de>
User-Agent: Mutt/1.4.1i
Return-Path: <rjh@cita.utoronto.ca>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2371
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rjh@cita.utoronto.ca
Precedence: bulk
X-list: linux-mips

On Wed, May 14, 2003 at 12:31:44PM +0200, Achim Hensel wrote:
>[I try to build Linux for a R4k Indigo1. I'm using as and ld of the

Please let me know how you go with this... I'd like to try it too.
Are you compiling a generic r4k kernel? Is there much chipset
documentation available?

cheers,
robin

From ica2_ts@csv.ica.uni-stuttgart.de Wed May 14 16:12:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 16:12:31 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:17064
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225240AbTENPM0>; Wed, 14 May 2003 16:12:26 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19FxvT-001Eq5-00; Wed, 14 May 2003 17:12:15 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19FxvQ-0002fQ-00; Wed, 14 May 2003 17:12:12 +0200
Date: Wed, 14 May 2003 17:12:12 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030514151212.GC8833@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030513222215.GA440@bogon.ms20.nix> <Pine.GSO.3.96.1030514124924.26213A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030514124924.26213A-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2372
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
> On Wed, 14 May 2003, Guido Guenther wrote:
> 
> > Looking at gcc-3.3:
> > 
> > #define ABI_32  0
> > #define ABI_N32 1
> > #define ABI_64  2
> > #define ABI_EABI 3
> > #define ABI_O64  4
> > 
> > The naming is very "unfortunate", though. We have (n32,64) and (32,o64).
> > Wouldn't it help to at least allow for n64 and o32 commandline options?
> > -mabi=32 and -mabi=64 will have to be kept for Irix compatibility
> > though, I think.
> 
>  Why unfortunate?  You use "32" and "64" for normal stuff, and the rest
> for special cases ("n32" isn't really 32-bit and "o64" isn't really 64-bit
> -- both lie in the middle).

Exactly this is the sort of confusion which makes the naming unfortunate.
-32 and -64 had never much to do with 32/64 bit but designate ABIs.

> Additional aliases of the "n64" and "o32"
> form would make more confusion, IMHO. 

I disagree.


Thiemo

From macro@ds2.pg.gda.pl Wed May 14 18:03:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 18:03:07 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:57051 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225242AbTENRDE>; Wed, 14 May 2003 18:03:04 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA01371;
	Wed, 14 May 2003 19:03:51 +0200 (MET DST)
Date: Wed, 14 May 2003 19:03:49 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
In-Reply-To: <20030514151212.GC8833@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030514181714.26213I-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2373
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 14 May 2003, Thiemo Seufer wrote:

> >  Why unfortunate?  You use "32" and "64" for normal stuff, and the rest
> > for special cases ("n32" isn't really 32-bit and "o64" isn't really 64-bit
> > -- both lie in the middle).
> 
> Exactly this is the sort of confusion which makes the naming unfortunate.
> -32 and -64 had never much to do with 32/64 bit but designate ABIs.

 Well, "32" is 32-bit address/data and "64" is 64-bit address/data. 
That's essentially pure 32-bit and 64-bit, respectively.  Of course some
data format has to be emitted by tools, so there has to be an ABI
associated with each of these variants. 

 And "n32" and "o64" are 32-bit address/64-bit data -- you can use 64-bit
data, e.g. in gas, but you cannot use 64-bit addressing, e.g. a
section/segment cannot be bigger than 4 GB. 

 The naming isn't consistent, indeed -- there could be, say:

- "32" for 32-bit support -- unambiguous, since there is only one
variation,

- "64" for 64-bit support -- requiring an additional option for selecting
the ABI, bailing out without one (or defaulting to a preconfigured ABI).

 Alternatively, there could be no "32" option -- tools configured for
"mips" would only emit 32-bit binaries and tools configured for "mips64" 
-- 64-bit and mixed ones, depending on one of the "64", "o64" and "n32"
options. 

 Of course all options could be renamed to avoid confusion.

> > Additional aliases of the "n64" and "o32"
> > form would make more confusion, IMHO. 
> 
> I disagree.

 I won't insist -- if people find this suitable for them, then it's great.
I won't use these additional aliases, so that's irrelevant for me.

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


From ica2_ts@csv.ica.uni-stuttgart.de Wed May 14 18:50:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 18:50:57 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:43688
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225242AbTENRuz>; Wed, 14 May 2003 18:50:55 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19G0OJ-001ESI-00; Wed, 14 May 2003 19:50:11 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19G0OJ-00047G-00; Wed, 14 May 2003 19:50:11 +0200
Date: Wed, 14 May 2003 19:50:11 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030514175011.GD8833@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030514151212.GC8833@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030514181714.26213I-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030514181714.26213I-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2374
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
[snip]
> On Wed, 14 May 2003, Thiemo Seufer wrote:
> 
> > >  Why unfortunate?  You use "32" and "64" for normal stuff, and the rest
> > > for special cases ("n32" isn't really 32-bit and "o64" isn't really 64-bit
> > > -- both lie in the middle).
> > 
> > Exactly this is the sort of confusion which makes the naming unfortunate.
> > -32 and -64 had never much to do with 32/64 bit but designate ABIs.
> 
>  Well, "32" is 32-bit address/data and "64" is 64-bit address/data. 
> That's essentially pure 32-bit and 64-bit, respectively.  Of course some
> data format has to be emitted by tools, so there has to be an ABI
> associated with each of these variants. 

That's just backwards. An ABI defines much more, e.g. calling
conventions and GOT sizes. The register size is just another
property of the ABI.

> And "n32" and "o64" are 32-bit address/64-bit data -- you can use 64-bit
> data, e.g. in gas, but you cannot use 64-bit addressing, e.g. a
> section/segment cannot be bigger than 4 GB. 
> 
>  The naming isn't consistent, indeed -- there could be, say:
> 
> - "32" for 32-bit support -- unambiguous, since there is only one
> variation,

This assumption fails if there will ever be an improved 32bit ABI with
e.g. NewABI calling conventions, as the MEABI tried some time ago.

> - "64" for 64-bit support -- requiring an additional option for selecting
> the ABI, bailing out without one (or defaulting to a preconfigured ABI).

Argh! Once again, the _ABI_ defines if it supports 64bit. For an
ABI-compliant system, there's no point in having a register-size
selection option.

>  Alternatively, there could be no "32" option -- tools configured for
> "mips" would only emit 32-bit binaries

What is a "32-bit binary"? o32, EABI, MEABI or another
yet-to-be-invented one?

> and tools configured for "mips64" 
> -- 64-bit and mixed ones, depending on one of the "64", "o64" and "n32"
> options. 

What's desireable here depends on the target system. For Linux,
the current way is IMHO the best: o32 only for mips-linux, and
o32, n32 and n64 for mips64-linux, with n32 as default.
o64 isn't useful for Linux, and only interesting for backward
compatibility elsewhere.


Thiemo

From ralf@linux-mips.org Wed May 14 19:00:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 19:00:07 +0100 (BST)
Received: from p508B56B7.dip.t-dialin.net ([IPv6:::ffff:80.139.86.183]:13288
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225242AbTENSAF>; Wed, 14 May 2003 19:00:05 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4EI0a4P026324;
	Wed, 14 May 2003 20:00:36 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4EI0YNg026323;
	Wed, 14 May 2003 20:00:34 +0200
Date: Wed, 14 May 2003 20:00:34 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Robin Humble <rjh@cita.utoronto.ca>
Cc: Achim Hensel <achim.hensel@ruhr-uni-bochum.de>,
	linux-mips@linux-mips.org
Subject: Re: r4k Indigo 1 (was Re: Branch relocation fixing at Kernel-compiling with Debian-toolchain)
Message-ID: <20030514180034.GA13328@linux-mips.org>
References: <20030514123144.52da1d81.achim.hensel@ruhr-uni-bochum.de> <20030514110227.GA8503@falcon.cita.utoronto.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030514110227.GA8503@falcon.cita.utoronto.ca>
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: 2375
X-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, May 14, 2003 at 07:02:27AM -0400, Robin Humble wrote:

> On Wed, May 14, 2003 at 12:31:44PM +0200, Achim Hensel wrote:
> >[I try to build Linux for a R4k Indigo1. I'm using as and ld of the
> 
> Please let me know how you go with this... I'd like to try it too.
> Are you compiling a generic r4k kernel? Is there much chipset
> documentation available?

Little; however it's know that the machine is relativly similar to the
Indy for example so it seems doable for somebody with enough time.

  Ralf

From macro@ds2.pg.gda.pl Wed May 14 19:09:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 19:09:03 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:18399 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225242AbTENSJB>; Wed, 14 May 2003 19:09:01 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA02257;
	Wed, 14 May 2003 20:09:42 +0200 (MET DST)
Date: Wed, 14 May 2003 20:09:41 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
In-Reply-To: <20030514175011.GD8833@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030514195854.26213L-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2376
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 14 May 2003, Thiemo Seufer wrote:

> >  Well, "32" is 32-bit address/data and "64" is 64-bit address/data. 
> > That's essentially pure 32-bit and 64-bit, respectively.  Of course some
> > data format has to be emitted by tools, so there has to be an ABI
> > associated with each of these variants. 
> 
> That's just backwards. An ABI defines much more, e.g. calling
> conventions and GOT sizes. The register size is just another
> property of the ABI.

 OK -- maybe I am biased because there is only a single ABI for 32-bit and
64-bit binaries each.  So please just forget it.

> What's desireable here depends on the target system. For Linux,
> the current way is IMHO the best: o32 only for mips-linux, and
> o32, n32 and n64 for mips64-linux, with n32 as default.

 Of course the choice of the default should be configurable (for binutils
it probably already is -- I recall Richard Sandiford making changes in
this area, for gcc -- no idea).

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


From agx@sigxcpu.org Wed May 14 19:32:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 19:32:47 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:21129
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225242AbTENScp>; Wed, 14 May 2003 19:32:45 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 06AC62BC33
	for <linux-mips@linux-mips.org>; Wed, 14 May 2003 20:32:43 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 23816-04
 for <linux-mips@linux-mips.org>; Wed, 14 May 2003 20:32:42 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 3EACA2BC32
	for <linux-mips@linux-mips.org>; Wed, 14 May 2003 20:32:42 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id BF6841737F; Wed, 14 May 2003 20:32:18 +0200 (CEST)
Date: Wed, 14 May 2003 20:32:18 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: r4k Indigo 1 (was Re: Branch relocation fixing at Kernel-compiling with Debian-toolchain)
Message-ID: <20030514183218.GE3889@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <20030514123144.52da1d81.achim.hensel@ruhr-uni-bochum.de> <20030514110227.GA8503@falcon.cita.utoronto.ca> <20030514180034.GA13328@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030514180034.GA13328@linux-mips.org>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2377
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Wed, May 14, 2003 at 08:00:34PM +0200, Ralf Baechle wrote:
> Little; however it's know that the machine is relativly similar to the
> Indy for example so it seems doable for somebody with enough time.
Maybe I'm stating the obvious but good look into Irix's /usr/include
helps a lot. It seems to have almost everything in it to get the Indigo
going (without serial consoel of course).
 -- Guido

From agx@sigxcpu.org Wed May 14 19:42:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 19:42:53 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:26249
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225242AbTENSmt>; Wed, 14 May 2003 19:42:49 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 0EE162BC33
	for <linux-mips@linux-mips.org>; Wed, 14 May 2003 20:42:49 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 23872-02
 for <linux-mips@linux-mips.org>; Wed, 14 May 2003 20:42:48 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 0AF1B2BC32
	for <linux-mips@linux-mips.org>; Wed, 14 May 2003 20:42:48 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 8329B1737F; Wed, 14 May 2003 20:42:24 +0200 (CEST)
Date: Wed, 14 May 2003 20:42:24 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: r4k Indigo 1 (was Re: Branch relocation fixing at Kernel-compiling with Debian-toolchain)
Message-ID: <20030514184224.GA3152@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <20030514123144.52da1d81.achim.hensel@ruhr-uni-bochum.de> <20030514110227.GA8503@falcon.cita.utoronto.ca> <20030514180034.GA13328@linux-mips.org> <20030514183218.GE3889@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030514183218.GE3889@bogon.ms20.nix>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2378
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Wed, May 14, 2003 at 08:32:18PM +0200, Guido Guenther wrote:
> On Wed, May 14, 2003 at 08:00:34PM +0200, Ralf Baechle wrote:
> > Little; however it's know that the machine is relativly similar to the
> > Indy for example so it seems doable for somebody with enough time.
> Maybe I'm stating the obvious but good look into Irix's /usr/include
> helps a lot. It seems to have almost everything in it to get the Indigo
> going (without serial consoel of course).
_without_ fb and _with_ serial console only is what I wanted to say.
 -- Guido

From ica2_ts@csv.ica.uni-stuttgart.de Wed May 14 19:43:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 19:43:15 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:50856
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225249AbTENSm7>; Wed, 14 May 2003 19:42:59 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19G1DN-001F0G-00; Wed, 14 May 2003 20:42:57 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19G1DM-00060Q-00; Wed, 14 May 2003 20:42:56 +0200
Date: Wed, 14 May 2003 20:42:56 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030514184256.GE8833@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030514175011.GD8833@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030514195854.26213L-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030514195854.26213L-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2379
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
[snip]
> > What's desireable here depends on the target system. For Linux,
> > the current way is IMHO the best: o32 only for mips-linux, and
> > o32, n32 and n64 for mips64-linux, with n32 as default.
> 
>  Of course the choice of the default should be configurable (for binutils
> it probably already is

It isn't, and probably will never be. Of course you could introduce
just another configuration, with the bfd vector of your choice as
default.

> -- I recall Richard Sandiford making changes in
> this area, for gcc -- no idea).

It would also need a different config which defines a different
MIPS_DEFAULT_ABI.


Thiemo

From ralf@linux-mips.org Wed May 14 20:29:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 20:29:58 +0100 (BST)
Received: from p508B56B7.dip.t-dialin.net ([IPv6:::ffff:80.139.86.183]:37101
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225206AbTENT34>; Wed, 14 May 2003 20:29:56 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4EJUZ4P029078;
	Wed, 14 May 2003 21:30:35 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4EJUWO1029077;
	Wed, 14 May 2003 21:30:32 +0200
Date: Wed, 14 May 2003 21:30:32 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Guido Guenther <agx@sigxcpu.org>, linux-mips@linux-mips.org
Subject: Re: r4k Indigo 1 (was Re: Branch relocation fixing at Kernel-compiling with Debian-toolchain)
Message-ID: <20030514193032.GA26327@linux-mips.org>
References: <20030514123144.52da1d81.achim.hensel@ruhr-uni-bochum.de> <20030514110227.GA8503@falcon.cita.utoronto.ca> <20030514180034.GA13328@linux-mips.org> <20030514183218.GE3889@bogon.ms20.nix> <20030514184224.GA3152@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030514184224.GA3152@bogon.ms20.nix>
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: 2380
X-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, May 14, 2003 at 08:42:24PM +0200, Guido Guenther wrote:

> > > Little; however it's know that the machine is relativly similar to the
> > > Indy for example so it seems doable for somebody with enough time.
> > Maybe I'm stating the obvious but good look into Irix's /usr/include
> > helps a lot. It seems to have almost everything in it to get the Indigo
> > going (without serial consoel of course).
> _without_ fb and _with_ serial console only is what I wanted to say.
>  -- Guido

Thta still leaves alot of details open - but yes, it's certainly a step
into the right direction.  And there's always the hope once there is a
start somebody at SGI will throw real docs into our direction ...

  Ralf

From Manoj_Ekbote@pmc-sierra.com Wed May 14 20:55:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 20:55:57 +0100 (BST)
Received: from father.pmc-sierra.com ([IPv6:::ffff:216.241.224.13]:25578 "HELO
	father.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8225206AbTENTzx>; Wed, 14 May 2003 20:55:53 +0100
Received: (qmail 12183 invoked by uid 104); 14 May 2003 19:55:45 -0000
Received: from Manoj_Ekbote@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4263.  Clear:. 
 Processed in 0.492987 secs); 14 May 2003 19:55:45 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.com with SMTP; 14 May 2003 19:55:44 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h4EJtij24295
	for <linux-mips@linux-mips.org>; Wed, 14 May 2003 12:55:44 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <H6VDXK2K>; Wed, 14 May 2003 12:55:43 -0700
Message-ID: <9DFF23E1E33391449FDC324526D1F2590172ECC6@SJC1EXM02>
From: Manoj Ekbote <Manoj_Ekbote@pmc-sierra.com>
To: "Linux-Mips (E-mail)" <linux-mips@linux-mips.org>
Subject: mips toolchain for solaris
Date: Wed, 14 May 2003 12:55:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Manoj_Ekbote@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2381
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Manoj_Ekbote@pmc-sierra.com
Precedence: bulk
X-list: linux-mips

I don't know if this is the right place for this question but...
Is there a place where I could find the latest mips cross-toolchain for the Solaris platform?

thanks,
- Manoj


From laguest@abyss2.demon.co.uk Wed May 14 21:26:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 21:26:17 +0100 (BST)
Received: from anchor-post-33.mail.demon.net ([IPv6:::ffff:194.217.242.91]:54535
	"EHLO anchor-post-33.mail.demon.net") by linux-mips.org with ESMTP
	id <S8225206AbTENU0N>; Wed, 14 May 2003 21:26:13 +0100
Received: from abyss2.demon.co.uk ([62.49.62.197] helo=rogue.abyss2.demon.co.uk)
	by anchor-post-33.mail.demon.net with esmtp (Exim 3.35 #1)
	id 19G2pB-000LX2-0X; Wed, 14 May 2003 21:26:05 +0100
Subject: Re: mips toolchain for solaris
From: "Luke A. Guest" <laguest@abyss2.demon.co.uk>
To: Manoj Ekbote <Manoj_Ekbote@pmc-sierra.com>
Cc: "Linux-Mips (E-mail)" <linux-mips@linux-mips.org>
In-Reply-To: <9DFF23E1E33391449FDC324526D1F2590172ECC6@SJC1EXM02>
References: <9DFF23E1E33391449FDC324526D1F2590172ECC6@SJC1EXM02>
Content-Type: text/plain
Organization: 
Message-Id: <1052943962.23940.2.camel@rogue.abyss2.demon.co.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4- 
Date: 14 May 2003 21:26:02 +0100
Content-Transfer-Encoding: 7bit
Return-Path: <laguest@abyss2.demon.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: 2382
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: laguest@abyss2.demon.co.uk
Precedence: bulk
X-list: linux-mips

On Wed, 2003-05-14 at 20:55, Manoj Ekbote wrote:
> I don't know if this is the right place for this question but...
> Is there a place where I could find the latest mips cross-toolchain for the Solaris platform?

You could just build a cross compiler (gcc) for mips-elf. Depends on
whether you require a libc. I just built this particular version of the
compiler as I don't require anything else.

Luke.



From ralf@linux-mips.org Wed May 14 21:42:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 21:42:58 +0100 (BST)
Received: from p508B56B7.dip.t-dialin.net ([IPv6:::ffff:80.139.86.183]:33155
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225206AbTENUm4>; Wed, 14 May 2003 21:42:56 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4EKhV4P030602;
	Wed, 14 May 2003 22:43:31 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4EKhQVG030601;
	Wed, 14 May 2003 22:43:26 +0200
Date: Wed, 14 May 2003 22:43:26 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Manoj Ekbote <Manoj_Ekbote@pmc-sierra.com>
Cc: "Linux-Mips (E-mail)" <linux-mips@linux-mips.org>
Subject: Re: mips toolchain for solaris
Message-ID: <20030514204326.GA29111@linux-mips.org>
References: <9DFF23E1E33391449FDC324526D1F2590172ECC6@SJC1EXM02>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9DFF23E1E33391449FDC324526D1F2590172ECC6@SJC1EXM02>
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: 2383
X-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, May 14, 2003 at 12:55:42PM -0700, Manoj Ekbote wrote:

> I don't know if this is the right place for this question but...
> Is there a place where I could find the latest mips cross-toolchain for
> the Solaris platform?

Building for Solaris should be quite forward, along the lines as described
in the web pages.  I used to distribute Solaris binaries a long time ago
but stopped when I had not received any indication of them actually
being used for a very long time ...

  Ralf

From ralf@linux-mips.org Wed May 14 21:45:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 21:45:05 +0100 (BST)
Received: from p508B56B7.dip.t-dialin.net ([IPv6:::ffff:80.139.86.183]:41859
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225206AbTENUpD>; Wed, 14 May 2003 21:45:03 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4EKih4P030637;
	Wed, 14 May 2003 22:44:43 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4EKihrT030636;
	Wed, 14 May 2003 22:44:43 +0200
Date: Wed, 14 May 2003 22:44:43 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Luke A. Guest" <laguest@abyss2.demon.co.uk>
Cc: Manoj Ekbote <Manoj_Ekbote@pmc-sierra.com>,
	"Linux-Mips (E-mail)" <linux-mips@linux-mips.org>
Subject: Re: mips toolchain for solaris
Message-ID: <20030514204443.GB29111@linux-mips.org>
References: <9DFF23E1E33391449FDC324526D1F2590172ECC6@SJC1EXM02> <1052943962.23940.2.camel@rogue.abyss2.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1052943962.23940.2.camel@rogue.abyss2.demon.co.uk>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2384
X-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, May 14, 2003 at 09:26:02PM +0100, Luke A. Guest wrote:

> On Wed, 2003-05-14 at 20:55, Manoj Ekbote wrote:
> > I don't know if this is the right place for this question but...
> > Is there a place where I could find the latest mips cross-toolchain for the Solaris platform?
> 
> You could just build a cross compiler (gcc) for mips-elf. Depends on
> whether you require a libc. I just built this particular version of the
> compiler as I don't require anything else.

mips-elf is *NOT* a usable configuration to do anythign for Linux/MIPS
targets.

  Ralf

From baitisj@idealab.com Wed May 14 23:26:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 23:26:52 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:27881 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225217AbTENW0u>;
	Wed, 14 May 2003 23:26:50 +0100
Received: (qmail 15087 invoked by uid 6180); 14 May 2003 22:26:43 -0000
Date: Wed, 14 May 2003 15:26:43 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: linux-mips@linux-mips.org
Subject: Power On Self Test and testing memory
Message-ID: <20030514152643.A5897@luca.pas.lab>
Reply-To: baitisj@evolution.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2385
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

Hi all:

I implemented memory tests in my bootloader code for the AU1500. I'm trying
to figure out why Linux boots when loaded into cached KSEG0 (0x 80c0 0000),
but my memory test FAILS for this same region.

(pretty backwards huh? get linux booting, then write memory tests!)


I start by writing 0x5555 5555 to all of uncached memory, reading it back, and
I write 0xAAAA AAAA to all of uncached memory and read it back.

This works great.

Next, I try to write 0x5555 5555 to cached KSEG0 memory, and it fails at addr
0x8000FE50. But Linux boots!

I'm not issuing SYNC commands when writing to cached memory; could this be
the problem?

We've exhaustively verified the memory burst parameters, etc. They look good.

Thank you in advance for your ideas!

Regards,
Jeff

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From ppopov@mvista.com Wed May 14 23:34:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 23:34:06 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:2552 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225217AbTENWeE>;
	Wed, 14 May 2003 23:34:04 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA27828;
	Wed, 14 May 2003 15:33:59 -0700
Subject: Re: Power On Self Test and testing memory
From: Pete Popov <ppopov@mvista.com>
To: baitisj@evolution.com
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20030514152643.A5897@luca.pas.lab>
References: <20030514152643.A5897@luca.pas.lab>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1052951641.788.225.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 14 May 2003 15:34:01 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2386
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, 2003-05-14 at 15:26, Jeff Baitis wrote:
> Hi all:
> 
> I implemented memory tests in my bootloader code for the AU1500. I'm trying
> to figure out why Linux boots when loaded into cached KSEG0 (0x 80c0 0000),
> but my memory test FAILS for this same region.
> 
> (pretty backwards huh? get linux booting, then write memory tests!)
> 
> 
> I start by writing 0x5555 5555 to all of uncached memory, reading it back, and
> I write 0xAAAA AAAA to all of uncached memory and read it back.
> 
> This works great.
> 
> Next, I try to write 0x5555 5555 to cached KSEG0 memory, and it fails at addr
> 0x8000FE50. But Linux boots!

You're not overwriting any of the boot exception vectors, right?  What's
the failure exactly and how does the test work?

Pete

> I'm not issuing SYNC commands when writing to cached memory; could this be
> the problem?
> 
> We've exhaustively verified the memory burst parameters, etc. They look good.
> 
> Thank you in advance for your ideas!
> 
> Regards,
> Jeff


From lyle@zevion.com Wed May 14 23:56:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 May 2003 23:56:40 +0100 (BST)
Received: from host31.ipowerweb.com ([IPv6:::ffff:12.129.198.131]:38810 "EHLO
	host31.ipowerweb.com") by linux-mips.org with ESMTP
	id <S8225206AbTENW4d>; Wed, 14 May 2003 23:56:33 +0100
Received: from rrcs-central-24-123-115-43.biz.rr.com ([24.123.115.43] helo=RADIUM)
	by host31.ipowerweb.com with esmtp (Exim 3.36 #1)
	id 19G5B0-0007dY-00
	for linux-mips@linux-mips.org; Wed, 14 May 2003 15:56:46 -0700
From: "Lyle Bainbridge" <lyle@zevion.com>
To: <linux-mips@linux-mips.org>
Subject: RE: Power On Self Test and testing memory
Date: Wed, 14 May 2003 17:56:26 -0500
Message-ID: <000001c31a6c$0e504e80$0a01a8c0@RADIUM>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
In-Reply-To: <20030514152643.A5897@luca.pas.lab>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host31.ipowerweb.com
X-AntiAbuse: Original Domain - linux-mips.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - zevion.com
Return-Path: <lyle@zevion.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2387
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lyle@zevion.com
Precedence: bulk
X-list: linux-mips

Hi,

I used the same strategy, but had similar issues.
So I just skip the first couple of 1000 bytes.
I'd like to find out why too.

Also, memory wraps.  If I have 32MB of RAM @ 0x80000000,
then run the memory test in non-existent memory from
0x82000000 to 0x83ffffff it appears to reference 0x80000000
to 0x81ffffff.  Can this be made to fail?

Lyle


> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Jeff Baitis
> Sent: Wednesday, May 14, 2003 5:27 PM
> To: linux-mips@linux-mips.org
> Subject: Power On Self Test and testing memory
> 
> 
> Hi all:
> 
> I implemented memory tests in my bootloader code for the 
> AU1500. I'm trying to figure out why Linux boots when loaded 
> into cached KSEG0 (0x 80c0 0000), but my memory test FAILS 
> for this same region.
> 
> (pretty backwards huh? get linux booting, then write memory tests!)
> 
> 
> I start by writing 0x5555 5555 to all of uncached memory, 
> reading it back, and I write 0xAAAA AAAA to all of uncached 
> memory and read it back.
> 
> This works great.
> 
> Next, I try to write 0x5555 5555 to cached KSEG0 memory, and 
> it fails at addr 0x8000FE50. But Linux boots!
> 
> I'm not issuing SYNC commands when writing to cached memory; 
> could this be the problem?
> 
> We've exhaustively verified the memory burst parameters, etc. 
> They look good.
> 
> Thank you in advance for your ideas!
> 
> Regards,
> Jeff
> 
> -- 
>          Jeffrey Baitis - Associate Software Engineer
> 
>                     Evolution Robotics, Inc.
>                      130 West Union Street
>                        Pasadena CA 91103
> 
>  tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 
> 


From ppopov@mvista.com Thu May 15 00:00:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 00:00:51 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:43759 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225206AbTENXAt>;
	Thu, 15 May 2003 00:00:49 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA28982;
	Wed, 14 May 2003 16:00:40 -0700
Subject: RE: Power On Self Test and testing memory
From: Pete Popov <ppopov@mvista.com>
To: Lyle Bainbridge <lyle@zevion.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <000001c31a6c$0e504e80$0a01a8c0@RADIUM>
References: <000001c31a6c$0e504e80$0a01a8c0@RADIUM>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1052953242.788.230.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 14 May 2003 16:00:43 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2388
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, 2003-05-14 at 15:56, Lyle Bainbridge wrote:
> Hi,
> 
> I used the same strategy, but had similar issues.
> So I just skip the first couple of 1000 bytes.
> I'd like to find out why too.
> 
> Also, memory wraps.  If I have 32MB of RAM @ 0x80000000,
> then run the memory test in non-existent memory from
> 0x82000000 to 0x83ffffff it appears to reference 0x80000000
> to 0x81ffffff.  Can this be made to fail?

Write something other than 5555 5555 and you'll catch the "problem". If
you write the address of the memory location or in the inverse of the
address, you'll catch the wrap around.

Pete

> Lyle
> 
> 
> > -----Original Message-----
> > From: linux-mips-bounce@linux-mips.org 
> > [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Jeff Baitis
> > Sent: Wednesday, May 14, 2003 5:27 PM
> > To: linux-mips@linux-mips.org
> > Subject: Power On Self Test and testing memory
> > 
> > 
> > Hi all:
> > 
> > I implemented memory tests in my bootloader code for the 
> > AU1500. I'm trying to figure out why Linux boots when loaded 
> > into cached KSEG0 (0x 80c0 0000), but my memory test FAILS 
> > for this same region.
> > 
> > (pretty backwards huh? get linux booting, then write memory tests!)
> > 
> > 
> > I start by writing 0x5555 5555 to all of uncached memory, 
> > reading it back, and I write 0xAAAA AAAA to all of uncached 
> > memory and read it back.
> > 
> > This works great.
> > 
> > Next, I try to write 0x5555 5555 to cached KSEG0 memory, and 
> > it fails at addr 0x8000FE50. But Linux boots!
> > 
> > I'm not issuing SYNC commands when writing to cached memory; 
> > could this be the problem?
> > 
> > We've exhaustively verified the memory burst parameters, etc. 
> > They look good.
> > 
> > Thank you in advance for your ideas!
> > 
> > Regards,
> > Jeff
> > 
> > -- 
> >          Jeffrey Baitis - Associate Software Engineer
> > 
> >                     Evolution Robotics, Inc.
> >                      130 West Union Street
> >                        Pasadena CA 91103
> > 
> >  tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 
> > 
> 
> 
> 


From baitisj@idealab.com Thu May 15 01:27:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 01:27:06 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:47849 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225206AbTEOA1D>;
	Thu, 15 May 2003 01:27:03 +0100
Received: (qmail 16398 invoked by uid 6180); 15 May 2003 00:27:01 -0000
Date: Wed, 14 May 2003 17:27:01 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Power On Self Test and testing memory
Message-ID: <20030514172701.B5897@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <20030514152643.A5897@luca.pas.lab> <1052951641.788.225.camel@zeus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <1052951641.788.225.camel@zeus.mvista.com>; from ppopov@mvista.com on Wed, May 14, 2003 at 03:34:01PM -0700
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2389
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

Hi Pete:

I forgot that I'm overwriting the RAM-based exception vectors. Earlier I had
disabled interrupts in the CP0 status register bit 0, but Linux actually needs
them enabled... :)

So, I changed my test to start at base address 0x80001000, but I still get the
same failure at the same RAM location.

Also important to mention is that my bootloader is executing from flash ROM,
and my initialization is very similar to the YAMON initialization file that
comes with the DbAu1500 eval board.

Here's what my code is like:

// in __main

failures = (int)loader_memcheck((UINT32)0xA0001000, (UINT32)0xA4000000, 0xAAAAAAAA);
failures = (int)loader_memcheck((UINT32)0xA0001000, (UINT32)0xA4000000, 0x55555555);
failures = (int)loader_memcheck((UINT32)0x80001000, (UINT32)0x84000000, 0xAAAAAAAA);
// Try to invalidate cache and go again
failures = (int)loader_memcheck((UINT32)0x80001000, (UINT32)0x84000000, 0xAAAAAAAA);

....


static unsigned int loader_memcheck( UINT32 base_addr, UINT32 max_addr, UINT32 test_data)
{   
    for (i = base_addr; i < max_addr; i=i+4)
    {
        *((unsigned int *)i) = test_data;
    }
    
    failures = 0;
    first_failure = 0xffffffff;
    for (i = base_addr; i < max_addr; i=i+4)
    {
        if (*((unsigned int *)i) != test_data)
        {
            if ((unsigned int)i < (unsigned int)first_failure)
            {
                first_failure = i;
            }
    
            ++failures;
        }
    }
    // if failures !=0 print_hex(first_failure)
    return failures;
}

So, after I execute this code, I pull up the EJTAG debugger, and
poke around.

I notice that even though the C code says that the first failure is at 0x8000fe50,
but when I poke around, I find:

    ...
    (gdb) p/x *(0x8000fe04)
    $27 = 0xaaaaaaaa

    (gdb) p/x *(0x8000fe08)
    $28 = 0x10fe0080

    (gdb) p/x *(0x8000fe10)
    $29 = 0x38000000
    ...

It seems like I'm having some cache coherency issues, since the results while
executing code are quite differenet.

Thanks for your help, Pete!

-Jeff

On Wed, May 14, 2003 at 03:34:01PM -0700, Pete Popov wrote:
> On Wed, 2003-05-14 at 15:26, Jeff Baitis wrote:
> > Hi all:
> > 
> > I implemented memory tests in my bootloader code for the AU1500. I'm trying
> > to figure out why Linux boots when loaded into cached KSEG0 (0x 80c0 0000),
> > but my memory test FAILS for this same region.
> > 
> > (pretty backwards huh? get linux booting, then write memory tests!)
> > 
> > 
> > I start by writing 0x5555 5555 to all of uncached memory, reading it back, and
> > I write 0xAAAA AAAA to all of uncached memory and read it back.
> > 
> > This works great.
> > 
> > Next, I try to write 0x5555 5555 to cached KSEG0 memory, and it fails at addr
> > 0x8000FE50. But Linux boots!
> 
> You're not overwriting any of the boot exception vectors, right?  What's
> the failure exactly and how does the test work?
> 
> Pete
> 
> > I'm not issuing SYNC commands when writing to cached memory; could this be
> > the problem?
> > 
> > We've exhaustively verified the memory burst parameters, etc. They look good.
> > 
> > Thank you in advance for your ideas!
> > 
> > Regards,
> > Jeff
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From lyle@zevion.com Thu May 15 03:43:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 03:43:35 +0100 (BST)
Received: from host31.ipowerweb.com ([IPv6:::ffff:12.129.198.131]:16520 "EHLO
	host31.ipowerweb.com") by linux-mips.org with ESMTP
	id <S8225206AbTEOCnc>; Thu, 15 May 2003 03:43:32 +0100
Received: from rrcs-central-24-123-115-43.biz.rr.com ([24.123.115.43] helo=RADIUM)
	by host31.ipowerweb.com with esmtp (Exim 3.36 #1)
	id 19G8iK-0002DZ-00; Wed, 14 May 2003 19:43:24 -0700
From: "Lyle Bainbridge" <lyle@zevion.com>
To: <baitisj@evolution.com>, "'Pete Popov'" <ppopov@mvista.com>
Cc: "'Linux MIPS mailing list'" <linux-mips@linux-mips.org>
Subject: RE: Power On Self Test and testing memory
Date: Wed, 14 May 2003 21:43:24 -0500
Message-ID: <000001c31a8b$c3406720$0a01a8c0@RADIUM>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal
In-Reply-To: <20030514172701.B5897@luca.pas.lab>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host31.ipowerweb.com
X-AntiAbuse: Original Domain - linux-mips.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - zevion.com
Return-Path: <lyle@zevion.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2390
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lyle@zevion.com
Precedence: bulk
X-list: linux-mips

Hi,

Where is does your stack start?  Seems to me that your
stack pointer might start at around 0x80010000 and of
course it grows down from there.  I suspect you're
overwriting the stack.

Just a thought.

Cheers,
Lyle


> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Jeff Baitis
> Sent: Wednesday, May 14, 2003 7:27 PM
> To: Pete Popov
> Cc: Linux MIPS mailing list
> Subject: Re: Power On Self Test and testing memory
> 
> 
> Hi Pete:
> 
> I forgot that I'm overwriting the RAM-based exception 
> vectors. Earlier I had disabled interrupts in the CP0 status 
> register bit 0, but Linux actually needs them enabled... :)
> 
> So, I changed my test to start at base address 0x80001000, 
> but I still get the same failure at the same RAM location.
> 
> Also important to mention is that my bootloader is executing 
> from flash ROM, and my initialization is very similar to the 
> YAMON initialization file that comes with the DbAu1500 eval board.
> 
> Here's what my code is like:
> 
> // in __main
> 
> failures = (int)loader_memcheck((UINT32)0xA0001000, 
> (UINT32)0xA4000000, 0xAAAAAAAA); failures = 
> (int)loader_memcheck((UINT32)0xA0001000, (UINT32)0xA4000000, 
> 0x55555555); failures = 
> (int)loader_memcheck((UINT32)0x80001000, (UINT32)0x84000000, 
> 0xAAAAAAAA); // Try to invalidate cache and go again failures 
> = (int)loader_memcheck((UINT32)0x80001000, 
> (UINT32)0x84000000, 0xAAAAAAAA);
> 
> ....
> 
> 
> static unsigned int loader_memcheck( UINT32 base_addr, UINT32 
> max_addr, UINT32 test_data)
> {   
>     for (i = base_addr; i < max_addr; i=i+4)
>     {
>         *((unsigned int *)i) = test_data;
>     }
>     
>     failures = 0;
>     first_failure = 0xffffffff;
>     for (i = base_addr; i < max_addr; i=i+4)
>     {
>         if (*((unsigned int *)i) != test_data)
>         {
>             if ((unsigned int)i < (unsigned int)first_failure)
>             {
>                 first_failure = i;
>             }
>     
>             ++failures;
>         }
>     }
>     // if failures !=0 print_hex(first_failure)
>     return failures;
> }
> 
> So, after I execute this code, I pull up the EJTAG debugger, 
> and poke around.
> 
> I notice that even though the C code says that the first 
> failure is at 0x8000fe50, but when I poke around, I find:
> 
>     ...
>     (gdb) p/x *(0x8000fe04)
>     $27 = 0xaaaaaaaa
> 
>     (gdb) p/x *(0x8000fe08)
>     $28 = 0x10fe0080
> 
>     (gdb) p/x *(0x8000fe10)
>     $29 = 0x38000000
>     ...
> 
> It seems like I'm having some cache coherency issues, since 
> the results while executing code are quite differenet.
> 
> Thanks for your help, Pete!
> 
> -Jeff
> 
> On Wed, May 14, 2003 at 03:34:01PM -0700, Pete Popov wrote:
> > On Wed, 2003-05-14 at 15:26, Jeff Baitis wrote:
> > > Hi all:
> > > 
> > > I implemented memory tests in my bootloader code for the 
> AU1500. I'm 
> > > trying to figure out why Linux boots when loaded into 
> cached KSEG0 
> > > (0x 80c0 0000), but my memory test FAILS for this same region.
> > > 
> > > (pretty backwards huh? get linux booting, then write 
> memory tests!)
> > > 
> > > 
> > > I start by writing 0x5555 5555 to all of uncached memory, 
> reading it 
> > > back, and I write 0xAAAA AAAA to all of uncached memory 
> and read it 
> > > back.
> > > 
> > > This works great.
> > > 
> > > Next, I try to write 0x5555 5555 to cached KSEG0 memory, and it 
> > > fails at addr 0x8000FE50. But Linux boots!
> > 
> > You're not overwriting any of the boot exception vectors, right?  
> > What's the failure exactly and how does the test work?
> > 
> > Pete
> > 
> > > I'm not issuing SYNC commands when writing to cached 
> memory; could 
> > > this be the problem?
> > > 
> > > We've exhaustively verified the memory burst parameters, 
> etc. They 
> > > look good.
> > > 
> > > Thank you in advance for your ideas!
> > > 
> > > Regards,
> > > Jeff
> > 
> 
> -- 
>          Jeffrey Baitis - Associate Software Engineer
> 
>                     Evolution Robotics, Inc.
>                      130 West Union Street
>                        Pasadena CA 91103
> 
>  tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 
> 


From drow@false.org Thu May 15 04:55:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 04:55:17 +0100 (BST)
Received: from crack.them.org ([IPv6:::ffff:146.82.138.56]:15264 "EHLO
	crack.them.org") by linux-mips.org with ESMTP id <S8225206AbTEODzP>;
	Thu, 15 May 2003 04:55:15 +0100
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 19G9qD-0001nL-00; Wed, 14 May 2003 22:55:37 -0500
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 19G9pj-0001DO-00; Wed, 14 May 2003 23:55:07 -0400
Date: Wed, 14 May 2003 23:55:07 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org, Guido Guenther <agx@sigxcpu.org>
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030515035507.GA4654@nevyn.them.org>
References: <20030318154155.GF2613@bogon.ms20.nix> <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318174241.GG2613@bogon.ms20.nix> <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de> <20030318232454.GA19990@bogon.ms20.nix> <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de> <20030513113316.GU3889@bogon.ms20.nix> <20030513192735.GA16497@rembrandt.csv.ica.uni-stuttgart.de> <20030513193625.GA14066@nevyn.them.org> <20030513195928.GB16497@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030513195928.GB16497@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@false.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2391
X-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, May 13, 2003 at 09:59:28PM +0200, Thiemo Seufer wrote:
> Daniel Jacobowitz wrote:
> [snip]
> > > > Just for completeness: I had to use:
> > > > 	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
> > > > to make gcc-3.3 happy (note the 32 instead of o32).
> > > 
> > > Yes, IIRC 64 vs. n64 has the same problem.
> > 
> > That's not quite the same: 64 is o64, n64 is n64.
> 
> I don't think so (There's -mabi=o64).
> Otherwise I would have built all my NewABI 64bit Executables as
> o64 without noticing ever. :-)

You are, of course, right :)

> > GCC's never called the 32-bit ABI "o32".
> 
> True, but it might be clearer if it did.

I suppose... too late now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From macro@ds2.pg.gda.pl Thu May 15 12:38:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 12:38:46 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:13713 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225206AbTEOLio>; Thu, 15 May 2003 12:38:44 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA16131;
	Thu, 15 May 2003 13:39:30 +0200 (MET DST)
Date: Thu, 15 May 2003 13:39:30 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
In-Reply-To: <20030514184256.GE8833@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030515133141.16026A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2392
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 14 May 2003, Thiemo Seufer wrote:

> >  Of course the choice of the default should be configurable (for binutils
> > it probably already is
> 
> It isn't, and probably will never be. Of course you could introduce
> just another configuration, with the bfd vector of your choice as
> default.

 Hmm, I would assume "mipsn32*-linux" defaults to n32 and "mips64*-linux" 
-- to (n)64.  It isn't the case, indeed.

> > -- I recall Richard Sandiford making changes in
> > this area, for gcc -- no idea).
> 
> It would also need a different config which defines a different
> MIPS_DEFAULT_ABI.

 I will do the change as described above when I am working on mips64
glibc.  Also config.guess will probably have to be updated to be capable
to determine which one of these two configurations is used in a given
system, so that one need not specify "--build=" to get what is desired.

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


From ica2_ts@csv.ica.uni-stuttgart.de Thu May 15 12:51:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 12:51:07 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:36267
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225206AbTEOLvE>; Thu, 15 May 2003 12:51:04 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19GHFp-001Gc1-00; Thu, 15 May 2003 13:50:33 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19GHFo-0004PX-00; Thu, 15 May 2003 13:50:32 +0200
Date: Thu, 15 May 2003 13:50:32 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
Message-ID: <20030515115032.GP8833@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030514184256.GE8833@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030515133141.16026A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030515133141.16026A-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2393
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
> On Wed, 14 May 2003, Thiemo Seufer wrote:
> 
> > >  Of course the choice of the default should be configurable (for binutils
> > > it probably already is
> > 
> > It isn't, and probably will never be. Of course you could introduce
> > just another configuration, with the bfd vector of your choice as
> > default.
> 
>  Hmm, I would assume "mipsn32*-linux" defaults to n32 and "mips64*-linux" 
> -- to (n)64.  It isn't the case, indeed.

IMHO it's not particularily useful to have both of these. I assume a n64
capable system will always implement n32 also, for better performance
and less memory consumption, and the majority of applications will run
as n32. IOW, there's little need for a n64-defaulting configuration.

But IIRC we disagree about this point.


Thiemo

From macro@ds2.pg.gda.pl Thu May 15 13:37:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 13:38:01 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:56467 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225206AbTEOMh7>; Thu, 15 May 2003 13:37:59 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA16816;
	Thu, 15 May 2003 14:38:46 +0200 (MET DST)
Date: Thu, 15 May 2003 14:38:45 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: -mcpu vs. binutils 2.13.90.0.18
In-Reply-To: <20030515115032.GP8833@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030515142409.16026D-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2394
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 15 May 2003, Thiemo Seufer wrote:

> >  Hmm, I would assume "mipsn32*-linux" defaults to n32 and "mips64*-linux" 
> > -- to (n)64.  It isn't the case, indeed.
> 
> IMHO it's not particularily useful to have both of these. I assume a n64
> capable system will always implement n32 also, for better performance
> and less memory consumption, and the majority of applications will run
> as n32. IOW, there's little need for a n64-defaulting configuration.
> 
> But IIRC we disagree about this point.

 It's not about whether we agree or not -- it's about letting a user make
a choice what suits him better.  We need not force anyone to accept our
points of view -- it's one of the main advantages of free software. 

 Also I would like to allow glibc to be configured without n32 and won't
object disallowing (n)64 alternatively.  I already run kernels that
support o32 and (n)64 only (o32 is temporary, of course, until glibc
supports (n)64), so it's not true an (n)64-capable system always supports
n32. 

 BTW, you may want a program to be built as (n)64 whenever it uses mmap() 
and can operate on the so called "large files".  So there may be
significantly more programs requiring the (n)64 format than it may seem at
the first thought. 

  Maciej

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


From lyle@zevion.com Thu May 15 15:38:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 15:38:17 +0100 (BST)
Received: from host31.ipowerweb.com ([IPv6:::ffff:12.129.198.131]:65180 "EHLO
	host31.ipowerweb.com") by linux-mips.org with ESMTP
	id <S8225222AbTEOOiP>; Thu, 15 May 2003 15:38:15 +0100
Received: from rrcs-central-24-123-115-43.biz.rr.com ([24.123.115.43] helo=RADIUM)
	by host31.ipowerweb.com with esmtp (Exim 3.36 #1)
	id 19GJs1-0004WK-00
	for linux-mips@linux-mips.org; Thu, 15 May 2003 07:38:09 -0700
From: "Lyle Bainbridge" <lyle@zevion.com>
To: "'Linux MIPS mailing list'" <linux-mips@linux-mips.org>
Subject: RE: Power On Self Test and testing memory
Date: Thu, 15 May 2003 09:38:07 -0500
Message-ID: <000001c31aef$9b2624a0$0a01a8c0@RADIUM>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <000001c31a8b$c3406720$0a01a8c0@RADIUM>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host31.ipowerweb.com
X-AntiAbuse: Original Domain - linux-mips.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - zevion.com
Return-Path: <lyle@zevion.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2395
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lyle@zevion.com
Precedence: bulk
X-list: linux-mips



> Where is does your stack start?  Seems to me that your
> stack pointer might start at around 0x80010000 and of

I meant 0xa0010000 (kseg1).  Of course that is still physically
at 0x80010000.


From mw@izd.de Thu May 15 17:02:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 17:02:40 +0100 (BST)
Received: from mail.securewebs.net ([IPv6:::ffff:80.190.40.19]:59654 "EHLO
	izd.de") by linux-mips.org with ESMTP id <S8225222AbTEOQCg> convert rfc822-to-8bit;
	Thu, 15 May 2003 17:02:36 +0100
Received: from so9 [80.132.171.173] by izd.de with ESMTP
  (SMTPD32-7.15) id AA1A122A009A; Thu, 15 May 2003 18:02:34 +0200
From: "Michael Weichselgartner" <mw@izd.de>
To: <linux-mips@linux-mips.org>
Subject: RaQ2+ NIC problem
Date: Thu, 15 May 2003 18:02:34 +0200
Message-ID: <002101c31afb$663f6510$0300a8c0@so9>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Return-Path: <mw@izd.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: 2396
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mw@izd.de
Precedence: bulk
X-list: linux-mips

hello,

i currently have a big problem and i hope someone could help.

I am running debian woody with kernel 2.4.18 (fresh from the current 
cvs tree)on a cobalt RaQ2+. Everything works smooth but one or two 
times a day all network traffic stops. The server is still running 
and i can log into the RaQ2+ on the serial console. If i restart the 
network (/etc/init.d/netwroking restart) i get no errors and 
everything works well again.

The tulip driver is 0.9.15-pre9. So i decided to upgrade to kernel
 2.4.20 because the driver there is 0.9.15-pre12. It took some time 
to get a stabel configuration. Now with the kernel 2.4.20 the 
network problem is bigger than ever. Simply loging into the RaQ with 
ssh and running midnight commander is freezing the nics. Or if i log 
into webmin the nics freeze as soon as the first website appears.

The same effect is with kernel 2.4.21. Therefore i recompiled all 
kernels with tulip support as module to get greater flexibility 
(itīs much easyer to play with insmod and rmmod). No matter what 
otpions i use (10Mbit, 100Mbit, Half or Fulldublex) the results 
are still the same: 

- kernel 2.4.18 with tulip 0.9.15-pre9: nics freeze 1 to 2 times a day 
- kernel > 2.4.18 with tulip 0.9.15-pre12: nics freeze after just a few
minutes

I played with the tulip drivers and compiled later revisions as 
modules to use with kernel 2.4.18 and earlyer revisions to use 
with kernel 2.4.20 and above. No effort.

Fortunately i have six RaQ2+ so i can test different kernels with 
different tulip drivers but this is driving me nuts. I spent nearly 
4 hours each day for the past 4 weeks to get rid of this nic problem 
but i dont know what to do next.

Btw. even if i use only one nic (no matter wether eth0 or eth1) the 
problem occurs. I have an old RaQ2 with only 1 nic running stable 
on 2.4.18 with tulip 0.9.15-pre9.

Unfortunately tulip debug mode is not working (neither in the kernel 
nor as an option while loading the module) so i cant see any 
problems within the nic driver. I tried to compile tulip-diag but 
this is not working due to limitations of the kernel source tree.

>From other lists i know there are many people having this problem 
but none of them has ever solved it. Any ideas what i could do next 
or do you have a solution?

Your feedback is welcome.

Best regards

Michael


From js@convergence.de Thu May 15 18:09:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 18:09:14 +0100 (BST)
Received: from mail.convergence.de ([IPv6:::ffff:212.84.236.4]:28342 "EHLO
	mail.convergence.de") by linux-mips.org with ESMTP
	id <S8225211AbTEORJL>; Thu, 15 May 2003 18:09:11 +0100
Received: from [10.1.1.152] (helo=hell)
	by mail.convergence.de with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.14)
	id 19GME5-0003CI-Ub
	for linux-mips@linux-mips.org; Thu, 15 May 2003 19:09:06 +0200
Received: from js by hell with local (Exim 3.35 #1 (Debian))
	id 19GMEF-0003jP-00
	for <linux-mips@linux-mips.org>; Thu, 15 May 2003 19:09:15 +0200
Date: Thu, 15 May 2003 19:09:15 +0200
From: Johannes Stezenbach <js@convergence.de>
To: linux-mips@linux-mips.org
Subject: [PATCH] implement dump_stack()
Message-ID: <20030515170915.GB14246@convergence.de>
Mail-Followup-To: Johannes Stezenbach <js@convergence.de>,
	linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <js@convergence.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2397
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: js@convergence.de
Precedence: bulk
X-list: linux-mips

Hi,

dump_stack() is declared in linux/kernel.h, and exported in
kernel/ksyms.c, but there is no implementation for mips.
It is useful for debugging.

Patch below is for linux_2_4 branch of arch/mips, but
maybe also applies for 2.5 and arch/mips64. The comment
is copied from arch/i386. It is debatable whether the
show_stack(0) is useful or show_trace(0) would be enough.
Adjust to your liking.

Regards,
Johannes


Index: linux/arch/mips/kernel/traps.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/traps.c,v
retrieving revision 1.99.2.54
diff -u -p -r1.99.2.54 traps.c
--- linux/arch/mips/kernel/traps.c	27 Apr 2003 23:34:46 -0000	1.99.2.54
+++ linux/arch/mips/kernel/traps.c	15 May 2003 15:51:38 -0000
@@ -190,6 +190,15 @@ void show_trace(long *sp)
 	printk("\n");
 }
 
+/*
+ * The architecture-independent backtrace generator
+ */
+void dump_stack(void)
+{
+        show_stack(0);
+        show_trace(0);
+}
+
 void show_trace_task(struct task_struct *tsk)
 {
 	show_trace((long *)tsk->thread.reg29);

From baitisj@idealab.com Thu May 15 19:03:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 19:03:36 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:21995 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225211AbTEOSDe>;
	Thu, 15 May 2003 19:03:34 +0100
Received: (qmail 25263 invoked by uid 6180); 15 May 2003 18:03:30 -0000
Date: Thu, 15 May 2003 11:03:30 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: Lyle Bainbridge <lyle@zevion.com>
Cc: 'Linux MIPS mailing list' <linux-mips@linux-mips.org>
Subject: Re: Power On Self Test and testing memory
Message-ID: <20030515110330.C5897@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <000001c31a8b$c3406720$0a01a8c0@RADIUM> <000001c31aef$9b2624a0$0a01a8c0@RADIUM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <000001c31aef$9b2624a0$0a01a8c0@RADIUM>; from lyle@zevion.com on Thu, May 15, 2003 at 09:38:07AM -0500
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2398
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

Oh yeah, I forgot about that!  I feel very stupid right now.

Thanks for the help!


-Jeff


On Thu, May 15, 2003 at 09:38:07AM -0500, Lyle Bainbridge wrote:
> 
> 
> > Where is does your stack start?  Seems to me that your
> > stack pointer might start at around 0x80010000 and of
> 
> I meant 0xa0010000 (kseg1).  Of course that is still physically
> at 0x80010000.
> 
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From michaelanburaj@hotmail.com Thu May 15 23:37:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 May 2003 23:37:04 +0100 (BST)
Received: from bay1-f58.bay1.hotmail.com ([IPv6:::ffff:65.54.245.58]:28176
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225211AbTEOWhC>; Thu, 15 May 2003 23:37:02 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 15 May 2003 15:36:53 -0700
Received: from 207.13.167.2 by by1fd.bay1.hotmail.msn.com with HTTP;
	Thu, 15 May 2003 22:36:53 GMT
X-Originating-IP: [207.13.167.2]
X-Originating-Email: [michaelanburaj@hotmail.com]
From: "Michael Anburaj" <michaelanburaj@hotmail.com>
To: linux-mips@linux-mips.org
Cc: edotkumar@yahoo.com
Subject: Re: Linux for MIPS Atlas 4Kc board -Eureka!!!
Date: Thu, 15 May 2003 15:36:53 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F58fPefLJGWSa10001b587@hotmail.com>
X-OriginalArrivalTime: 15 May 2003 22:36:53.0306 (UTC) FILETIME=[7BA261A0:01C31B32]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2399
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi All,

Thanks a lot guys.

At last I am able to login as root & work on the linux console.

I had to change the baud rate to 38400. Because Linux was opening the serial 
port at 38400 bauds (understood it by going through the init scripts at 
/etc).


Cheers,
-Mike.



>From: "Michael Anburaj" <michaelanburaj@hotmail.com>
>To: linux-mips@linux-mips.org
>Subject: Re: Linux for MIPS Atlas 4Kc board
>Date: Tue, 13 May 2003 00:31:07 -0700
>
>Hi,
>
>>MIPS_RedHat7.1_Release-02.00.tar from
>>ftp://ftp.mips.com/pub/linux/mips/installation/redhat7.1/02.00
>>
>
>Thats not the right one. The right file for NFS root for mips is the one 
>(nfsroot.mips.redhat7.1.eb-01.00.tar.gz) at 
>ftp://ftp.mips.com/pub/linux/mips/rootfs_nfs/redhat7.1
>
>I extracted it to my /export/... folder & Linux booted well on the Atlas 
>board.
>
>Question:
>1. I could see some interactive configuration menus with buttons <'OK' , 
>'Cancel' surrounded with a couple of dots>. As I press the tab key to 
>navigate to a button, nothing gets highlighted or there isnt a means to 
>know a particlar button got selected. Is there a special config in minicom 
>to view these better? I even tried the First char of the string to enble it 
><like 'O' for "OK" button & 'C' for Cancel button & 'N' for Next button>, 
>but did not work. Please let me know a better way for this.
>
>2. I got this message at last & nothing seems to happen after which <But I 
>see a lot of ethernet activity between the Atlas & the host>.
>
>clipping of the messages from linux as seen on minicom:
>-----------------------------------------------------------------------------
>Starting keytable:  Loading keymap: /etc/rc3.d/S17keytable: /dev/tty0: No 
>such e[FAILED]
>Loading system font: [  OK  ]
>[FAILED]
>Initializing random number generator:  [  OK  ]
>Mounting other filesystems:  [  OK  ]
>Starting automounter:[  OK  ]
>Starting atd: [  OK  ]
>Starting xinetd: [  OK  ]
>Starting NFS file locking services:
>Starting NFS lockd: lockdsvc: Function not implemented
>[FAILED]
>Starting NFS statd: [  OK  ]
>Starting postfix: [  OK  ]
>Starting crond: [  OK  ]
>Starting anacron: [  OK  ]
>.?...?..??..?.?..??..?..??.??.?    ???  ?.?  ?. ?  ?????.  ??  ?  ? ??? ? 
>.? . ?
>
>3. Did I miss some key configs during the 1st time setup menus? If so, How 
>to revisite the linux config menus?
>
>Please advice me. Also point me to relevant documentation. Mean while let 
>me search for one...
>
>Thanks,
>-Mike.
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 2 months FREE*  
>http://join.msn.com/?page=features/junkmail
>
>

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


From jbglaw@dvmwest.gt.owl.de Fri May 16 14:46:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 May 2003 14:46:21 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:53257 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225217AbTEPNqN>; Fri, 16 May 2003 14:46:13 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id C07514AB9E; Fri, 16 May 2003 15:46:11 +0200 (CEST)
Date: Fri, 16 May 2003 15:46:11 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: 2.5.x on Indy r4600
Message-ID: <20030516134611.GH27494@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="zs32KGgguTW8DKq/"
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2400
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


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

Hi!

I'm currently tryin' to get 2.5.x running on MIPS (for background,
please read http://www.lug-owl.de/~jbglaw/linux-ports/ ). I got current
CVS HEAD to build (with minor tweaks), but my Indy doesn't completely
load the kernel (via tftp). It starts loading the kernel, but TFTP
packet #3810 (containing bytes 1950208..1950719 resp. 1dc200..1dc3ff
from the kernel file) gets NACKed with error (5), code 3 (wrt. ethereal,
this is "Disk full or allocation exceeded"). After this, the box seems to
be completely dead: no serial break, no power button, no reset
button...).

Because 2.4.x basically runs on this machine, I suspect the linker
script changes. I've tried some older versions (added missing symbols
into them) to see if I can overcome these loading problems. Up to now, I
failed. Here's my kernel image's "objdump -h" output:

$ mips-linux-objdump -h indy-kernel

indy-kernel:     file format elf32-tradbigmips

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00176bfc  88002000  88002000  00001000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00022fd0  88178c00  88178c00  00177c00  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .kstrtab      00005b2c  8819bbd0  8819bbd0  0019abd0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 __ex_table    00001ad8  881a1700  881a1700  001a0700  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 __dbe_table   00000000  881a31d8  881a31d8  001a21d8  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 __ksymtab     000029a0  881a31d8  881a31d8  001a21d8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .data         0001d000  881a6000  881a6000  001a5000  2**12
                  CONTENTS, ALLOC, LOAD, DATA
  7 .data.cacheline_aligned 00001c40  881c3000  881c3000  001c2000  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  8 .data.init_task 00002000  881c6000  881c6000  001c4000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .reginfo      00000018  881c8000  881c8000  001c6000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE
 10 .init.text    000126c4  881c8018  881c8018  001c6018  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .init.data    00002f1c  881da6dc  881da6dc  001d86dc  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 12 .init.setup   000000d0  881dd600  881dd600  001db600  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 13 .initcall.init 000000d8  881dd6d0  881dd6d0  001db6d0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 14 .init.ramfs   00000080  881de000  881de000  001dc000  2**0
                  CONTENTS, ALLOC, LOAD, DATA
 15 .sbss         00000010  881df000  881df000  001dd000  2**3
                  ALLOC
 16 .bss          0003b620  881df020  881df020  001dd010  2**5
                  ALLOC
 17 .comment      00003e08  8821a640  8821a640  001dd010  2**0
                  CONTENTS, READONLY
 18 .pdr          0002b1e0  00000000  00000000  001e0e18  2**2
                  CONTENTS, READONLY
 19 .mdebug.abi32 00000000  00000000  00000000  0020bff8  2**0
                  CONTENTS, READONLY

Does anybody have some suggestions for me?

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

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

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

iD8DBQE+xOujHb1edYOZ4bsRAs9VAJ9PcQObYrp48PggU9ACKFSli9uGjQCcDAtT
1EjKGV3VemlpqrKC5p+EUM0=
=FUH9
-----END PGP SIGNATURE-----

--zs32KGgguTW8DKq/--

From macro@ds2.pg.gda.pl Fri May 16 15:29:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 May 2003 15:30:01 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:37341 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225222AbTEPO35>; Fri, 16 May 2003 15:29:57 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA06741;
	Fri, 16 May 2003 16:30:36 +0200 (MET DST)
Date: Fri, 16 May 2003 16:30:36 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
cc: linux-mips@linux-mips.org
Subject: Re: 2.5.x on Indy r4600
In-Reply-To: <20030516134611.GH27494@lug-owl.de>
Message-ID: <Pine.GSO.3.96.1030516161253.6533A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2401
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 16 May 2003, Jan-Benedict Glaw wrote:

> I'm currently tryin' to get 2.5.x running on MIPS (for background,
> please read http://www.lug-owl.de/~jbglaw/linux-ports/ ). I got current
> CVS HEAD to build (with minor tweaks), but my Indy doesn't completely
> load the kernel (via tftp). It starts loading the kernel, but TFTP
> packet #3810 (containing bytes 1950208..1950719 resp. 1dc200..1dc3ff
> from the kernel file) gets NACKed with error (5), code 3 (wrt. ethereal,
> this is "Disk full or allocation exceeded"). After this, the box seems to
> be completely dead: no serial break, no power button, no reset
> button...).
[...]
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
[...]
>  14 .init.ramfs   00000080  881de000  881de000  001dc000  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
>  15 .sbss         00000010  881df000  881df000  001dd000  2**3
>                   ALLOC
>  16 .bss          0003b620  881df020  881df020  001dd010  2**5
>                   ALLOC
>  17 .comment      00003e08  8821a640  8821a640  001dd010  2**0
>                   CONTENTS, READONLY
>  18 .pdr          0002b1e0  00000000  00000000  001e0e18  2**2
>                   CONTENTS, READONLY
>  19 .mdebug.abi32 00000000  00000000  00000000  0020bff8  2**0
>                   CONTENTS, READONLY

 Hmm, the NACK is reasonable as probably nothing beyond 1dc07f is loadable
-- `objdump -p' would determine it definitely.  Better yet, please try
`readelf -Sl', which reports additional data beyond what's obtainable with
`objdump'.  But why that unloadable data is requested at all? 

 There is something strange about the .comment section -- it's not
allocatable, yet it has addresses set.  Anyway, it need not be relevant
here as section headers are not interpreted by your boot loader.

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


From jbglaw@dvmwest.gt.owl.de Fri May 16 15:54:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 May 2003 15:55:10 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:39434 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225225AbTEPOy6>; Fri, 16 May 2003 15:54:58 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 050CF4AB9C; Fri, 16 May 2003 16:54:52 +0200 (CEST)
Date: Fri, 16 May 2003 16:54:52 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: 2.5.x on Indy r4600
Message-ID: <20030516145452.GJ27494@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030516134611.GH27494@lug-owl.de> <Pine.GSO.3.96.1030516161253.6533A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="y87zqFmoGECkYaVu"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030516161253.6533A-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2402
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


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

On Fri, 2003-05-16 16:30:36 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
wrote in message <Pine.GSO.3.96.1030516161253.6533A-100000@delta.ds2.pg.gda=
.pl>:
> On Fri, 16 May 2003, Jan-Benedict Glaw wrote:

[Non-booting 2.5.x on Indy]

> [...]
> > Sections:
> > Idx Name          Size      VMA       LMA       File off  Algn
> [...]
> >  14 .init.ramfs   00000080  881de000  881de000  001dc000  2**0
> >                   CONTENTS, ALLOC, LOAD, DATA
> >  15 .sbss         00000010  881df000  881df000  001dd000  2**3
> >                   ALLOC
> >  16 .bss          0003b620  881df020  881df020  001dd010  2**5
> >                   ALLOC
> >  17 .comment      00003e08  8821a640  8821a640  001dd010  2**0
> >                   CONTENTS, READONLY
> >  18 .pdr          0002b1e0  00000000  00000000  001e0e18  2**2
> >                   CONTENTS, READONLY
> >  19 .mdebug.abi32 00000000  00000000  00000000  0020bff8  2**0
> >                   CONTENTS, READONLY
>=20
>  Hmm, the NACK is reasonable as probably nothing beyond 1dc07f is loadable
> -- `objdump -p' would determine it definitely.  Better yet, please try

$ mips-linux-objdump -p indy-kernel

indy-kernel:     file format elf32-tradbigmips

Program Header:
0x70000000 off    0x001c6000 vaddr 0x881c8000 paddr 0x881c8000 align 2**2
         filesz 0x00000018 memsz 0x00000018 flags r--
    LOAD off    0x00001000 vaddr 0x88002000 paddr 0x88002000 align 2**12
         filesz 0x001a3b78 memsz 0x001a3b78 flags r-x
    LOAD off    0x001a5000 vaddr 0x881a6000 paddr 0x881a6000 align 2**12
         filesz 0x0001ec40 memsz 0x0001ec40 flags rw-
    LOAD off    0x001c4000 vaddr 0x881c6000 paddr 0x881c6000 align 2**12
         filesz 0x00018080 memsz 0x00054640 flags rwx
private flags =3D 10001001: [abi=3DO32] [mips2] [not 32bitmode]



> `readelf -Sl', which reports additional data beyond what's obtainable with

$ mips-linux-readelf -Sl indy-kernel

There are 24 section headers, starting at offset 0x20c0dc:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk I=
nf Al
  [ 0]                   NULL            00000000 000000 000000 00      0  =
 0  0
  [ 1] .text             PROGBITS        88002000 001000 176bfc 00  AX  0  =
 0 32
  [ 2] .rodata           PROGBITS        88178c00 177c00 022fd0 00   A  0  =
 0 16
  [ 3] .kstrtab          PROGBITS        8819bbd0 19abd0 005b2c 00   A  0  =
 0  4
  [ 4] __ex_table        PROGBITS        881a1700 1a0700 001ad8 00   A  0  =
 0  4
  [ 5] __dbe_table       PROGBITS        881a31d8 1a21d8 000000 00   A  0  =
 0  1
  [ 6] __ksymtab         PROGBITS        881a31d8 1a21d8 0029a0 00   A  0  =
 0  4
  [ 7] .data             PROGBITS        881a6000 1a5000 01d000 00  WA  0  =
 0 4096
  [ 8] .data.cacheline_a PROGBITS        881c3000 1c2000 001c40 00  WA  0  =
 0 32
  [ 9] .data.init_task   PROGBITS        881c6000 1c4000 002000 00  WA  0  =
 0  4
  [10] .reginfo          MIPS_REGINFO    881c8000 1c6000 000018 18   A  0  =
 0  4
  [11] .init.text        PROGBITS        881c8018 1c6018 0126c4 00  AX  0  =
 0  4
  [12] .init.data        PROGBITS        881da6dc 1d86dc 002f1c 00  WA  0  =
 0  4
  [13] .init.setup       PROGBITS        881dd600 1db600 0000d0 00  WA  0  =
 0  4
  [14] .initcall.init    PROGBITS        881dd6d0 1db6d0 0000d8 00  WA  0  =
 0  4
  [15] .init.ramfs       PROGBITS        881de000 1dc000 000080 00  WA  0  =
 0  1
  [16] .sbss             NOBITS          881df000 1dd000 000010 00 WAp  0  =
 0  8
  [17] .bss              NOBITS          881df020 1dd010 03b620 00  WA  0  =
 0 32
  [18] .comment          PROGBITS        8821a640 1dd010 003e08 00      0  =
 0  1
  [19] .pdr              PROGBITS        00000000 1e0e18 02b1e0 00      0  =
 0  4
  [20] .mdebug.abi32     PROGBITS        00000000 20bff8 000000 00      0  =
 0  1
  [21] .shstrtab         STRTAB          00000000 20bff8 0000e2 00      0  =
 0  1
  [22] .symtab           SYMTAB          00000000 20c49c 02bb90 10     23 1=
37f  4
  [23] .strtab           STRTAB          00000000 23802c 02e857 00      0  =
 0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0x881c8058
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  REGINFO        0x1c6000 0x881c8000 0x881c8000 0x00018 0x00018 R   0x4
  LOAD           0x001000 0x88002000 0x88002000 0x1a3b78 0x1a3b78 R E 0x1000
  LOAD           0x1a5000 0x881a6000 0x881a6000 0x1ec40 0x1ec40 RW  0x1000
  LOAD           0x1c4000 0x881c6000 0x881c6000 0x18080 0x54640 RWE 0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .reginfo=20
   01     .text .rodata .kstrtab __ex_table __ksymtab=20
   02     .data .data.cacheline_aligned=20
   03     .data.init_task .reginfo .init.text .init.data .init.setup .initc=
all.init .init.ramfs .sbss .bss=20

> `objdump'.  But why that unloadable data is requested at all?=20

Thanks for looking at it! Maybe I'll get it up at some time:)

MfG, JBG

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

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

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

iD8DBQE+xPu8Hb1edYOZ4bsRAjTEAJwNQumvLp3s0v2BFQT4L00nx2L1XgCfQxHv
QA84J5eWULCt9uE88qBCaMc=
=cqs/
-----END PGP SIGNATURE-----

--y87zqFmoGECkYaVu--

From hjl@lucon.org Fri May 16 16:06:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 May 2003 16:06:09 +0100 (BST)
Received: from sccrmhc02.attbi.com ([IPv6:::ffff:204.127.202.62]:17911 "EHLO
	sccrmhc02.attbi.com") by linux-mips.org with ESMTP
	id <S8225225AbTEPPGE>; Fri, 16 May 2003 16:06:04 +0100
Received: from lucon.org (12-234-88-5.client.attbi.com[12.234.88.5])
          by attbi.com (sccrmhc02) with ESMTP
          id <2003051615055000200ha7jte>; Fri, 16 May 2003 15:05:50 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id D783F2C681; Fri, 16 May 2003 08:05:44 -0700 (PDT)
Date: Fri, 16 May 2003 08:05:44 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org,
	GNU C Library <libc-alpha@sources.redhat.com>,
	Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ron Guilmette <rfg@monkeys.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	Leonard Zubkoff <lnz@dandelion.com>,
	"Steven J. Hill" <sjhill@cotw.com>
Subject: The Linux binutils 2.14.90.0.2 is released
Message-ID: <20030516080544.A30912@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.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: 2403
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hjl@lucon.org
Precedence: bulk
X-list: linux-mips

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

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

Changes from binutils 2.14.90.0.1:

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

Changes from binutils 2.13.90.0.20:

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

Changes from binutils 2.13.90.0.18:

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

Changes from binutils 2.13.90.0.16:

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

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

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

Changes from binutils 2.13.90.0.10:

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

Changes from binutils 2.13.90.0.4:

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

Changes from binutils 2.13.90.0.3:

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

Changes from binutils 2.13.90.0.2:

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

The file list:

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

There is no separate source rpm. You can do

# rpm -ta binutils-2.14.90.0.2.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
05/16/2003

From macro@ds2.pg.gda.pl Fri May 16 16:47:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 May 2003 16:47:12 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:30177 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225218AbTEPPrK>; Fri, 16 May 2003 16:47:10 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA07646;
	Fri, 16 May 2003 17:47:58 +0200 (MET DST)
Date: Fri, 16 May 2003 17:47:58 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
cc: linux-mips@linux-mips.org
Subject: Re: 2.5.x on Indy r4600
In-Reply-To: <20030516145452.GJ27494@lug-owl.de>
Message-ID: <Pine.GSO.3.96.1030516171048.6533K-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2404
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 16 May 2003, Jan-Benedict Glaw wrote:

> $ mips-linux-objdump -p indy-kernel
> 
> indy-kernel:     file format elf32-tradbigmips
> 
> Program Header:
> 0x70000000 off    0x001c6000 vaddr 0x881c8000 paddr 0x881c8000 align 2**2
>          filesz 0x00000018 memsz 0x00000018 flags r--
>     LOAD off    0x00001000 vaddr 0x88002000 paddr 0x88002000 align 2**12
>          filesz 0x001a3b78 memsz 0x001a3b78 flags r-x
>     LOAD off    0x001a5000 vaddr 0x881a6000 paddr 0x881a6000 align 2**12
>          filesz 0x0001ec40 memsz 0x0001ec40 flags rw-
>     LOAD off    0x001c4000 vaddr 0x881c6000 paddr 0x881c6000 align 2**12
>          filesz 0x00018080 memsz 0x00054640 flags rwx
> private flags = 10001001: [abi=O32] [mips2] [not 32bitmode]

 Hmm, it looks reasonable and the end is indeed at 0x1dc07f (= 0x1c4000 +
0x18080 - 1).

> Elf file type is EXEC (Executable file)
> Entry point 0x881c8058
> There are 4 program headers, starting at offset 52
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   REGINFO        0x1c6000 0x881c8000 0x881c8000 0x00018 0x00018 R   0x4
>   LOAD           0x001000 0x88002000 0x88002000 0x1a3b78 0x1a3b78 R E 0x1000
>   LOAD           0x1a5000 0x881a6000 0x881a6000 0x1ec40 0x1ec40 RW  0x1000
>   LOAD           0x1c4000 0x881c6000 0x881c6000 0x18080 0x54640 RWE 0x1000

 And this looks fine, too.

 But there is a notable difference to 2.4 kernels, at least these I
inspected.  There are three loadable segments as opposed to two for 2.4
and the boot loader may be unhappy about it, e.g. it may have a bug that
gets hit.  You might want to reduce the number of segments (by changing
section flags -- look for ".section" gas directives).

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


From ica2_ts@csv.ica.uni-stuttgart.de Fri May 16 16:57:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 May 2003 16:57:07 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:13488
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225218AbTEPP5E>; Fri, 16 May 2003 16:57:04 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19GhZt-001J0W-00; Fri, 16 May 2003 17:57:01 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19GhZr-0003ZX-00; Fri, 16 May 2003 17:56:59 +0200
Date: Fri, 16 May 2003 17:56:59 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Jan-Benedict Glaw <jbglaw@lug-owl.de>, linux-mips@linux-mips.org
Subject: Re: 2.5.x on Indy r4600
Message-ID: <20030516155659.GR8833@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030516145452.GJ27494@lug-owl.de> <Pine.GSO.3.96.1030516171048.6533K-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030516171048.6533K-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2405
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Maciej W. Rozycki wrote:
> On Fri, 16 May 2003, Jan-Benedict Glaw wrote:
> 
> > $ mips-linux-objdump -p indy-kernel
> > 
> > indy-kernel:     file format elf32-tradbigmips
> > 
> > Program Header:
> > 0x70000000 off    0x001c6000 vaddr 0x881c8000 paddr 0x881c8000 align 2**2
> >          filesz 0x00000018 memsz 0x00000018 flags r--
> >     LOAD off    0x00001000 vaddr 0x88002000 paddr 0x88002000 align 2**12
> >          filesz 0x001a3b78 memsz 0x001a3b78 flags r-x
> >     LOAD off    0x001a5000 vaddr 0x881a6000 paddr 0x881a6000 align 2**12
> >          filesz 0x0001ec40 memsz 0x0001ec40 flags rw-
> >     LOAD off    0x001c4000 vaddr 0x881c6000 paddr 0x881c6000 align 2**12
> >          filesz 0x00018080 memsz 0x00054640 flags rwx
> > private flags = 10001001: [abi=O32] [mips2] [not 32bitmode]
> 
>  Hmm, it looks reasonable and the end is indeed at 0x1dc07f (= 0x1c4000 +
> 0x18080 - 1).
> 
> > Elf file type is EXEC (Executable file)
> > Entry point 0x881c8058
> > There are 4 program headers, starting at offset 52
> > 
> > Program Headers:
> >   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> >   REGINFO        0x1c6000 0x881c8000 0x881c8000 0x00018 0x00018 R   0x4
> >   LOAD           0x001000 0x88002000 0x88002000 0x1a3b78 0x1a3b78 R E 0x1000
> >   LOAD           0x1a5000 0x881a6000 0x881a6000 0x1ec40 0x1ec40 RW  0x1000
> >   LOAD           0x1c4000 0x881c6000 0x881c6000 0x18080 0x54640 RWE 0x1000
> 
>  And this looks fine, too.
> 
>  But there is a notable difference to 2.4 kernels, at least these I
> inspected.  There are three loadable segments as opposed to two for 2.4
> and the boot loader may be unhappy about it, e.g. it may have a bug that
> gets hit.  You might want to reduce the number of segments (by changing
> section flags -- look for ".section" gas directives).

It's simpler to combine the relevant sections in the linker script than
to change the code.


Thiemo

From benmen@gmx.de Fri May 16 22:33:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 May 2003 22:33:52 +0100 (BST)
Received: from nx5.HRZ.Uni-Dortmund.DE ([IPv6:::ffff:129.217.131.21]:42325
	"EHLO nx5.hrz.uni-dortmund.de") by linux-mips.org with ESMTP
	id <S8225218AbTEPVds>; Fri, 16 May 2003 22:33:48 +0100
Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51])
	by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id C8A304AA621
	for <linux-mips@linux-mips.org>; Fri, 16 May 2003 23:33:45 +0200 (MET DST)
Received: from linuxpc1 (p508EF54A.dip.t-dialin.net [80.142.245.74])
	(authenticated (0 bits))
	by unimail.uni-dortmund.de (8.12.9+Sun/8.11.6) with ESMTP id h4GLXatC002368
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NOT)
	for <linux-mips@linux-mips.org>; Fri, 16 May 2003 23:33:41 +0200 (MEST)
From: Benjamin =?iso-8859-1?q?Menk=FCc?= <benmen@gmx.de>
Reply-To: menkuec@auto-intern.com
To: linux-mips@linux-mips.org
Subject: cvs glibc bug?
Date: Fri, 16 May 2003 23:33:34 +0200
User-Agent: KMail/1.5.1
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200305162333.34877.benmen@gmx.de>
X-MailScanner-Information: UniDo-UniMail
X-MailScanner: Found to be clean
Return-Path: <benmen@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: 2406
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: benmen@gmx.de
Precedence: bulk
X-list: linux-mips

Hi,

is this a bug?

[benmen@linuxpc1 mipsel-glibc] LC_ALL=C LD_LIBRARY_PATH="" CFLAGS="-g 
-finline-limit=10000 -O2" CC="mipsel-linux-gcc" AS="mipsel-linux-as" 
../glibc-cvs/configure --build=i686-linux --host=mipsel-linux 
--enable-add-ons --prefix=/home/benmen/mipsel 
--with-headers=/home/benmen/mips/kernel/mips-2.4.20/include --disable-profile

....

[benmen@linuxpc1 mipsel-glibc] LC_ALL=C mak

...

mipsel-linux-gcc -mabi=32 ../sysdeps/unix/sysv/linux/sigtimedwait.c -c 
-std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings 
-finline-limit=10000 -g      -I../include -I. 
-I/home/benmen/mips/mipsel-glibc/signal -I.. -I../libio  
-I/home/benmen/mips/mipsel-glibc -I../sysdeps/mips/elf 
-I../linuxthreads/sysdeps/unix/sysv/linux/mips 
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread 
-I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv 
-I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/mips 
-I../sysdeps/unix/sysv/linux/mips/mips32 -I../sysdeps/unix/sysv/linux/mips 
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common 
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv 
-I../sysdeps/unix/mips/mips32 -I../sysdeps/unix/mips -I../sysdeps/unix 
-I../sysdeps/posix -I../sysdeps/mips/mips32 -I../sysdeps/mips 
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 
-I../sysdeps/wordsize-32 -I../sysdeps/mips/fpu -I../sysdeps/ieee754 
-I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem 
/home/benmen/mipsel/lib/gcc-lib/mipsel-linux/3.2.3/include -isystem 
/home/benmen/mips/kernel/mips-2.4.20/include -D_LIBC_REENTRANT -include 
../include/libc-symbols.h  -DPIC     -o 
/home/benmen/mips/mipsel-glibc/signal/sigtimedwait.o -MD -MP -MF 
/home/benmen/mips/mipsel-glibc/signal/sigtimedwait.o.dt
../sysdeps/unix/sysv/linux/sigtimedwait.c: In function `do_sigtimedwait':
../sysdeps/unix/sysv/linux/sigtimedwait.c:44: `SI_TKILL' undeclared (first use 
in this function)
../sysdeps/unix/sysv/linux/sigtimedwait.c:44: (Each undeclared identifier is 
reported only once
../sysdeps/unix/sysv/linux/sigtimedwait.c:44: for each function it appears 
in.)
make[2]: *** [/home/benmen/mips/mipsel-glibc/signal/sigtimedwait.o] Error 1
make[2]: Leaving directory `/home/benmen/mips/glibc-cvs/signal'
make[1]: *** [signal/subdir_lib] Error 2
make[1]: Leaving directory `/home/benmen/mips/glibc-cvs'
make: *** [all] Error 2

regards,

Ben

From ica2_ts@csv.ica.uni-stuttgart.de Fri May 16 22:51:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 May 2003 22:51:53 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:2737
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225226AbTEPVvu>; Fri, 16 May 2003 22:51:50 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19Gn7F-001Ikb-00
	for linux-mips@linux-mips.org; Fri, 16 May 2003 23:51:49 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19Gn7D-0000PA-00
	for <linux-mips@linux-mips.org>; Fri, 16 May 2003 23:51:47 +0200
Date: Fri, 16 May 2003 23:51:47 +0200
To: linux-mips@linux-mips.org
Subject: Re: cvs glibc bug?
Message-ID: <20030516215147.GT8833@rembrandt.csv.ica.uni-stuttgart.de>
References: <200305162333.34877.benmen@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200305162333.34877.benmen@gmx.de>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2407
X-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

Benjamin Menküc wrote:
> Hi,
> 
> is this a bug?

You could argue so.

[snip]
> ../sysdeps/unix/sysv/linux/sigtimedwait.c: In function `do_sigtimedwait':
> ../sysdeps/unix/sysv/linux/sigtimedwait.c:44: `SI_TKILL' undeclared (first use 
> in this function)

SI_TKILL is new in glibc and not yet ported to mips.


Thiemo

From ica2_ts@csv.ica.uni-stuttgart.de Fri May 16 23:27:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 May 2003 23:27:52 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:14001
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225234AbTEPW1u>; Fri, 16 May 2003 23:27:50 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19Gng5-001JEO-00
	for linux-mips@linux-mips.org; Sat, 17 May 2003 00:27:49 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19Gng5-00014T-00
	for <linux-mips@linux-mips.org>; Sat, 17 May 2003 00:27:49 +0200
Date: Sat, 17 May 2003 00:27:48 +0200
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030516222748.GU8833@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030516221926Z8225233-1272+1964@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030516221926Z8225233-1272+1964@linux-mips.org>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2408
X-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@linux-mips.org wrote:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	03/05/16 23:19:22
> 
> Modified files:
> 	arch/mips64/kernel: linux32.c 
> 
> Log message:
> 	Remove egcs 1.1.2 workarounds from 32-bit compat code.

Ah, endlich! Welche gcc Version wird nun die empfohlene?


Thiemo

From benmen@gmx.de Sat May 17 09:25:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 May 2003 09:25:50 +0100 (BST)
Received: from nx5.HRZ.Uni-Dortmund.DE ([IPv6:::ffff:129.217.131.21]:57022
	"EHLO nx5.hrz.uni-dortmund.de") by linux-mips.org with ESMTP
	id <S8225192AbTEQIZr>; Sat, 17 May 2003 09:25:47 +0100
Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51])
	by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id D9A4C4AABBA
	for <linux-mips@linux-mips.org>; Sat, 17 May 2003 10:25:45 +0200 (MET DST)
Received: from linuxpc1 (p508EF54A.dip.t-dialin.net [80.142.245.74])
	(authenticated (0 bits))
	by unimail.uni-dortmund.de (8.12.9+Sun/8.11.6) with ESMTP id h4H8PctC018433
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NOT)
	for <linux-mips@linux-mips.org>; Sat, 17 May 2003 10:25:41 +0200 (MEST)
From: Benjamin =?iso-8859-1?q?Menk=FCc?= <benmen@gmx.de>
Reply-To: menkuec@auto-intern.com
To: linux-mips@linux-mips.org
Subject: Re: cvs glibc bug?
Date: Sat, 17 May 2003 10:25:37 +0200
User-Agent: KMail/1.5.1
References: <200305162333.34877.benmen@gmx.de> <20030516215147.GT8833@rembrandt.csv.ica.uni-stuttgart.de>
In-Reply-To: <20030516215147.GT8833@rembrandt.csv.ica.uni-stuttgart.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200305171025.37684.benmen@gmx.de>
X-MailScanner-Information: UniDo-UniMail
X-MailScanner: Found to be clean
Return-Path: <benmen@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: 2409
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: benmen@gmx.de
Precedence: bulk
X-list: linux-mips

can I disable SI_TKILL stuff somehow so that glibc compiles for mips?

regards,

Ben

From anemo@mba.ocn.ne.jp Sat May 17 13:37:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 May 2003 13:37:46 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:31462 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225192AbTEQMho>; Sat, 17 May 2003 13:37:44 +0100
Received: from localhost (p0446-ip01funabasi.chiba.ocn.ne.jp [211.130.235.192])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 16C18429A; Sat, 17 May 2003 21:37:37 +0900 (JST)
Date: Sat, 17 May 2003 21:45:55 +0900 (JST)
Message-Id: <20030517.214555.74756802.anemo@mba.ocn.ne.jp>
To: ralf@linux-mips.org, linux-mips@linux-mips.org
Cc: nemoto@toshiba-tops.co.jp
Subject: fix FIXADDR_TOP for TX39/TX49
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2410
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

On TX39/TX49, high 16MB in virtual address space
(0xff000000-0xffffffff) are reserved and can not be used as
normal mapped/cached segment.

This patch fixes FIXADDR_TOP for TX39/TX49.  FIXADDR_TOP is used not
only if CONFIG_HIGHMEM is enabled.  It is also used for high limit
address for vmalloc.  

This patch can be applied to both 2.4 and 2.5.  I'm not sure whether
subtracting 0x2000 is necessary or not but doing it is a safe bet.
Please apply.

diff -u linux-mips-cvs/include/asm-mips/fixmap.h linux.new/include/asm-mips/
--- linux-mips-cvs/include/asm-mips/fixmap.h	Fri Jan 18 12:16:24 2002
+++ linux.new/include/asm-mips/fixmap.h	Sat May 17 21:25:18 2003
@@ -71,7 +71,11 @@
  * the start of the fixmap, and leave one page empty
  * at the top of mem..
  */
+#if defined(CONFIG_CPU_TX39XX) || defined(CONFIG_CPU_TX49XX)
+#define FIXADDR_TOP	(0xff000000UL - 0x2000)
+#else
 #define FIXADDR_TOP	(0xffffe000UL)
+#endif
 #define FIXADDR_SIZE	(__end_of_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START	(FIXADDR_TOP - FIXADDR_SIZE)
 
---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Sat May 17 13:49:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 May 2003 13:49:48 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:28353 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225192AbTEQMtq>; Sat, 17 May 2003 13:49:46 +0100
Received: from localhost (p0446-ip01funabasi.chiba.ocn.ne.jp [211.130.235.192])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id D7516374A; Sat, 17 May 2003 21:49:42 +0900 (JST)
Date: Sat, 17 May 2003 21:58:06 +0900 (JST)
Message-Id: <20030517.215806.92590717.anemo@mba.ocn.ne.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Cc: nemoto@toshiba-tops.co.jp
Subject: please give ieee1394 a chance
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2411
X-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

Now ieee1394 drivers (at least ohci1394 and sbp2) will work on mips.
Please give them a chance.

diff -u linux-mips-cvs/arch/mips/config-shared.in linux.new/arch/mips/
--- linux-mips-cvs/arch/mips/config-shared.in	Mon May  5 21:31:50 2003
+++ linux.new/arch/mips/config-shared.in	Sat May 17 21:50:35 2003
@@ -876,6 +876,8 @@
 fi
 endmenu
 
+source drivers/ieee1394/Config.in
+
 if [ "$CONFIG_PCI" = "y" ]; then
    source drivers/message/i2o/Config.in
 fi
---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Sat May 17 14:00:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 May 2003 14:00:36 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:33738 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225192AbTEQNAe>; Sat, 17 May 2003 14:00:34 +0100
Received: from localhost (p0446-ip01funabasi.chiba.ocn.ne.jp [211.130.235.192])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 60E76376E; Sat, 17 May 2003 22:00:30 +0900 (JST)
Date: Sat, 17 May 2003 22:08:48 +0900 (JST)
Message-Id: <20030517.220848.71082015.anemo@mba.ocn.ne.jp>
To: ralf@linux-mips.org, linux-mips@linux-mips.org
Cc: nemoto@toshiba-tops.co.jp
Subject: TX49 support for mips64 kernel
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2412
X-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

TX49 should be able to run mips64 kernel.  Please add a
CONFIG_CPU_TX49XX entry to arch/mips64/mm/Makefile.

diff -u linux-mips-cvs/arch/mips64/mm/Makefile linux.new/arch/mips64/mm/
--- linux-mips-cvs/arch/mips64/mm/Makefile	Fri Apr 25 23:43:44 2003
+++ linux.new/arch/mips64/mm/Makefile	Sat May 17 21:59:28 2003
@@ -16,6 +16,7 @@
 obj-$(CONFIG_CPU_NEVADA)	+= c-r4k.o pg-r4k.o tlb-r4k.o tlb-glue-r4k.o
 obj-$(CONFIG_CPU_R5432)		+= c-r4k.o pg-r4k.o tlb-r4k.o tlb-glue-r4k.o
 obj-$(CONFIG_CPU_RM7000)	+= c-r4k.o pg-r4k.o tlb-r4k.o tlb-glue-r4k.o
+obj-$(CONFIG_CPU_TX49XX)	+= c-r4k.o pg-r4k.o tlb-r4k.o tlb-glue-r4k.o
 obj-$(CONFIG_CPU_R10000)	+= c-r4k.o pg-r4k.o tlb-andes.o tlb-glue-r4k.o
 obj-$(CONFIG_CPU_SB1)		+= c-sb1.o pg-sb1.o tlb-sb1.o tlb-glue-sb1.o \
 				   cex-sb1.o cerr-sb1.o
---
Atsushi Nemoto

From macro@ds2.pg.gda.pl Sat May 17 17:12:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 May 2003 17:12:41 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:6569 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225192AbTEQQMj>; Sat, 17 May 2003 17:12:39 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA23804;
	Sat, 17 May 2003 18:13:14 +0200 (MET DST)
Date: Sat, 17 May 2003 18:13:13 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030516222748.GU8833@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030517181052.23610C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2413
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Sat, 17 May 2003, Thiemo Seufer wrote:

> > Log message:
> > 	Remove egcs 1.1.2 workarounds from 32-bit compat code.
> 
> Ah, endlich! Welche gcc Version wird nun die empfohlene?

 Marvelous, indeed.  You should be satisfied with patched 2.95.x as I am
so far, or if you are brave enough, you may try 3.3.

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


From jsun@mvista.com Mon May 19 17:45:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 May 2003 17:45:43 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:56050 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225218AbTESQpk>;
	Mon, 19 May 2003 17:45:40 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h4JGjYx01511;
	Mon, 19 May 2003 09:45:34 -0700
Date: Mon, 19 May 2003 09:45:34 -0700
From: Jun Sun <jsun@mvista.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org,
	nemoto@toshiba-tops.co.jp, jsun@mvista.com
Subject: Re: please give ieee1394 a chance
Message-ID: <20030519094534.C32567@mvista.com>
References: <20030517.215806.92590717.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030517.215806.92590717.anemo@mba.ocn.ne.jp>; from anemo@mba.ocn.ne.jp on Sat, May 17, 2003 at 09:58:06PM +0900
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2414
X-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


Indeed.  This option should be there.

I have heard people get it working or at least trying to get
it working on MIPS.

Jun

On Sat, May 17, 2003 at 09:58:06PM +0900, Atsushi Nemoto wrote:
> Now ieee1394 drivers (at least ohci1394 and sbp2) will work on mips.
> Please give them a chance.
> 
> diff -u linux-mips-cvs/arch/mips/config-shared.in linux.new/arch/mips/
> --- linux-mips-cvs/arch/mips/config-shared.in	Mon May  5 21:31:50 2003
> +++ linux.new/arch/mips/config-shared.in	Sat May 17 21:50:35 2003
> @@ -876,6 +876,8 @@
>  fi
>  endmenu
>  
> +source drivers/ieee1394/Config.in
> +
>  if [ "$CONFIG_PCI" = "y" ]; then
>     source drivers/message/i2o/Config.in
>  fi
> ---
> Atsushi Nemoto
> 

From benmen@gmx.de Tue May 20 14:18:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 May 2003 14:18:07 +0100 (BST)
Received: from nx5.HRZ.Uni-Dortmund.DE ([IPv6:::ffff:129.217.131.21]:54124
	"EHLO nx5.hrz.uni-dortmund.de") by linux-mips.org with ESMTP
	id <S8225196AbTETNSD>; Tue, 20 May 2003 14:18:03 +0100
Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51])
	by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id 38C6A4AF8E0
	for <linux-mips@linux-mips.org>; Tue, 20 May 2003 15:17:55 +0200 (MET DST)
Received: from linuxpc1 (p508EDD8B.dip.t-dialin.net [80.142.221.139])
	(authenticated (0 bits))
	by unimail.uni-dortmund.de (8.12.9+Sun/8.11.6) with ESMTP id h4KDHjtC013930
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NOT)
	for <linux-mips@linux-mips.org>; Tue, 20 May 2003 15:17:49 +0200 (MEST)
From: Benjamin =?iso-8859-1?q?Menk=FCc?= <benmen@gmx.de>
Reply-To: menkuec@auto-intern.com
To: linux-mips@linux-mips.org
Subject: mathinline.h + cross-compiler
Date: Tue, 20 May 2003 15:17:43 +0200
User-Agent: KMail/1.5.1
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200305201517.43195.benmen@gmx.de>
X-MailScanner-Information: UniDo-UniMail
X-MailScanner: Found to be clean
Return-Path: <benmen@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: 2415
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: benmen@gmx.de
Precedence: bulk
X-list: linux-mips

When I compile gcc with glibc I get the following error:

/home/benmen/mips/mipsel-gcc/gcc/xgcc -B/home/benmen/mips/mipsel-gcc/gcc/ 
-B/home/benmen/mipsel/mipsel-linux/bin/ 
-B/home/benmen/mipsel/mipsel-linux/lib/ -isystem 
/home/benmen/mipsel/mipsel-linux/include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. 
-I../../../gcc-3.2.3/libiberty/../include  -W -Wall -Wtraditional -pedantic 
../../../gcc-3.2.3/libiberty/floatformat.c
../../../gcc-3.2.3/libiberty/floatformat.c: In function 
`floatformat_to_double':
/home/benmen/mipsel/include/bits/mathinline.h:524: inconsistent operand 
constraints in an `asm'
/home/benmen/mipsel/include/bits/mathinline.h:524: inconsistent operand 
constraints in an `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `atan2':
/home/benmen/mipsel/include/bits/mathinline.h:425: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `atan2f':
/home/benmen/mipsel/include/bits/mathinline.h:425: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `atan2l':
/home/benmen/mipsel/include/bits/mathinline.h:425: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `__atan2l':
/home/benmen/mipsel/include/bits/mathinline.h:426: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `fmod':
/home/benmen/mipsel/include/bits/mathinline.h:429: unknown register name `ax' 
in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `fmodf':
/home/benmen/mipsel/include/bits/mathinline.h:429: unknown register name `ax' 
in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `fmodl':
/home/benmen/mipsel/include/bits/mathinline.h:429: unknown register name `ax' 
in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `atan':
/home/benmen/mipsel/include/bits/mathinline.h:466: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `atanf':
/home/benmen/mipsel/include/bits/mathinline.h:466: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `atanl':
/home/benmen/mipsel/include/bits/mathinline.h:466: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `log1p':
/home/benmen/mipsel/include/bits/mathinline.h:539: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `log1pf':
/home/benmen/mipsel/include/bits/mathinline.h:539: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `log1pl':
/home/benmen/mipsel/include/bits/mathinline.h:539: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `asinh':
/home/benmen/mipsel/include/bits/mathinline.h:539: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `asinhf':
/home/benmen/mipsel/include/bits/mathinline.h:539: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `asinhl':
/home/benmen/mipsel/include/bits/mathinline.h:539: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `atanh':
/home/benmen/mipsel/include/bits/mathinline.h:539: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `atanhf':
/home/benmen/mipsel/include/bits/mathinline.h:539: unknown register name 
`st(1)' in `asm'
/home/benmen/mipsel/include/bits/mathinline.h: In function `atanhl':
/home/benmen/mipsel/include/bits/mathinline.h:539: unknown register name 
`st(1)' in `asm'
make[1]: *** [floatformat.o] Fehler 1
make[1]: Leaving directory 
`/home/benmen/mips/mipsel-gcc/mipsel-linux/libiberty'
make: *** [all-target-libiberty] Fehler 2
Verzeichnis: ~/mips/mipsel-gcc
[benmen@linuxpc1 mipsel-gcc]


This issue has already been in this list 
http://www.spinics.net/lists/mips/msg12229.html but without an answer... 

I have linked the asm dir from the kernel sources into my mipsel/include ... 
However I can not find a mips-specific mathinline.h... There is not 
include/bits dir for mips anywhere....

I configure gcc like this (the last 2 options don't change anything for me): 

[benmen@linuxpc1 mipsel-gcc] ../gcc-3.2.3/configure --target=mipsel-linux 
--enable-languages=c,c++ --prefix=/home/benmen/mipsel 
--with-libs=/home/benmen/mipsel/lib 
--with-headers=/home/benmen/mips/kernel/mips-2.4.20/include 
--includedir=/home/benmen/mips/include

regards,

Ben

From yuasa@hh.iij4u.or.jp Tue May 20 14:42:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 May 2003 14:42:06 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:61921 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225196AbTETNmC>;
	Tue, 20 May 2003 14:42:02 +0100
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id WAA09379;
	Tue, 20 May 2003 22:41:56 +0900 (JST)
Received: 4UMDO00 id h4KDfur13567; Tue, 20 May 2003 22:41:56 +0900 (JST)
Received: 4UMRO00 id h4KDfse13155; Tue, 20 May 2003 22:41:55 +0900 (JST)
	from stratos.frog (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Tue, 20 May 2003 22:41:45 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, matsu@megasolution.jp,
	linux-mips@linux-mips.org
Subject: [patch] TANBAC TB0229(NEC VR4131)
Message-Id: <20030520224145.1b2bdcc1.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Tue__20_May_2003_22:41:45_+0900_08458450"
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: 2416
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

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

Hello Ralf,

We made TANBAC TB0229(not TB0226) patches for v2.4 and v2.5.

Would you apply these patch to CVS on ftp.linux-mips.org?

Best Regards,

Yoichi


--Multipart_Tue__20_May_2003_22:41:45_+0900_08458450
Content-Type: text/plain;
 name="tanbac-tb0229-v24.diff"
Content-Disposition: attachment;
 filename="tanbac-tb0229-v24.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/Makefile linux/arch/mips/Makefile
--- linux.orig/arch/mips/Makefile	Tue May 20 14:35:19 2003
+++ linux/arch/mips/Makefile	Tue May 20 15:39:05 2003
@@ -448,6 +448,17 @@
 endif
 
 #
+# TANBAC TB0229 (VR4131DIMM)
+#
+ifdef CONFIG_TANBAC_TB0229
+SUBDIRS		+= arch/mips/vr41xx/common \
+		   arch/mips/vr41xx/tanbac-tb0229
+CORE_FILES	+= arch/mips/vr41xx/common/vr41xx.o \
+		   arch/mips/vr41xx/tanbac-tb0229/tb0229.o
+LOADADDR	:= 0x80000000
+endif
+
+#
 # Philips Nino
 #
 ifdef CONFIG_NINO
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/config-shared.in linux/arch/mips/config-shared.in
--- linux.orig/arch/mips/config-shared.in	Tue May 20 14:35:19 2003
+++ linux/arch/mips/config-shared.in	Tue May 20 15:39:05 2003
@@ -195,6 +195,11 @@
 fi
 bool 'Support for SNI RM200 PCI' CONFIG_SNI_RM200_PCI
 bool 'Support for TANBAC TB0226 (Mbase)' CONFIG_TANBAC_TB0226
+bool 'Support for TANBAC TB0229 (VR4131DIMM)' CONFIG_TANBAC_TB0229
+if [ "$CONFIG_TANBAC_TB0229" = "y" ]; then
+   bool '  Add TANBAC TB0219 Base board support' CONFIG_TANBAC_TB0219
+fi
+
 dep_bool 'Support for Toshiba JMR-TX3927 board' CONFIG_TOSHIBA_JMR3927 $CONFIG_MIPS32
 bool 'Support for Toshiba RBTX49[23]7 Reference Board' CONFIG_TOSHIBA_RBTX4927
 bool 'Support for Victor MP-C303/304' CONFIG_VICTOR_MPC30X
@@ -555,6 +560,19 @@
    define_bool CONFIG_PCI_AUTO y
    define_bool CONFIG_DUMMY_KEYB y
    define_bool CONFIG_SERIAL_MANY_PORTS y
+fi
+if [ "$CONFIG_TANBAC_TB0229" = "y" ]; then
+    define_bool CONFIG_CPU_VR41XX y
+    define_bool CONFIG_IRQ_CPU y
+    define_bool CONFIG_NEW_TIME_C y
+    define_bool CONFIG_VR41XX_TIME_C y
+    define_bool CONFIG_NONCOHERENT_IO y
+    define_bool CONFIG_ISA n
+    define_bool CONFIG_PCI y
+    define_bool CONFIG_NEW_PCI y
+    define_bool CONFIG_PCI_AUTO y
+    define_bool CONFIG_DUMMY_KEYB y
+    define_bool CONFIG_SERIAL_MANY_PORTS y
 fi
 if [ "$CONFIG_TOSHIBA_JMR3927" = "y" ]; then
    define_bool CONFIG_TOSHIBA_BOARDS y
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/defconfig-tb0229 linux/arch/mips/defconfig-tb0229
--- linux.orig/arch/mips/defconfig-tb0229	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/defconfig-tb0229	Tue May 20 15:39:05 2003
@@ -0,0 +1,632 @@
+#
+# Automatically generated make config: don't edit
+#
+CONFIG_MIPS=y
+CONFIG_MIPS32=y
+# CONFIG_MIPS64 is not set
+
+#
+# Code maturity level options
+#
+CONFIG_EXPERIMENTAL=y
+
+#
+# Loadable module support
+#
+CONFIG_MODULES=y
+# CONFIG_MODVERSIONS is not set
+CONFIG_KMOD=y
+
+#
+# Machine selection
+#
+# CONFIG_ACER_PICA_61 is not set
+# CONFIG_MIPS_DB1000 is not set
+# CONFIG_MIPS_DB1100 is not set
+# CONFIG_MIPS_DB1500 is not set
+# CONFIG_MIPS_PB1000 is not set
+# CONFIG_MIPS_PB1100 is not set
+# CONFIG_MIPS_PB1500 is not set
+# CONFIG_BAGET_MIPS is not set
+# CONFIG_CASIO_E55 is not set
+# CONFIG_MIPS_COBALT is not set
+# CONFIG_DECSTATION is not set
+# CONFIG_MIPS_EV64120 is not set
+# CONFIG_MIPS_EV96100 is not set
+# CONFIG_MIPS_IVR is not set
+# CONFIG_HP_LASERJET is not set
+# CONFIG_IBM_WORKPAD is not set
+# CONFIG_LASAT is not set
+# CONFIG_MIPS_ITE8172 is not set
+# CONFIG_MIPS_ATLAS is not set
+# CONFIG_MIPS_MAGNUM_4000 is not set
+# CONFIG_MIPS_MALTA is not set
+# CONFIG_MIPS_SEAD is not set
+# CONFIG_MOMENCO_OCELOT is not set
+# CONFIG_MOMENCO_OCELOT_G is not set
+# CONFIG_DDB5074 is not set
+# CONFIG_DDB5476 is not set
+# CONFIG_DDB5477 is not set
+# CONFIG_NEC_OSPREY is not set
+# CONFIG_NEC_EAGLE is not set
+# CONFIG_OLIVETTI_M700 is not set
+# CONFIG_NINO is not set
+# CONFIG_SGI_IP22 is not set
+# CONFIG_SGI_IP27 is not set
+# CONFIG_SGI_IP32 is not set
+# CONFIG_SIBYTE_SB1xxx_SOC is not set
+# CONFIG_SNI_RM200_PCI is not set
+# CONFIG_TANBAC_TB0226 is not set
+CONFIG_TANBAC_TB0229=y
+CONFIG_TANBAC_TB0219=y
+# CONFIG_TOSHIBA_JMR3927 is not set
+# CONFIG_TOSHIBA_RBTX4927 is not set
+# CONFIG_VICTOR_MPC30X is not set
+# CONFIG_ZAO_CAPCELLA is not set
+# CONFIG_HIGHMEM is not set
+CONFIG_RWSEM_GENERIC_SPINLOCK=y
+# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
+CONFIG_CPU_VR41XX=y
+CONFIG_IRQ_CPU=y
+CONFIG_NEW_TIME_C=y
+CONFIG_VR41XX_TIME_C=y
+CONFIG_NONCOHERENT_IO=y
+# CONFIG_ISA is not set
+CONFIG_PCI=y
+CONFIG_NEW_PCI=y
+CONFIG_PCI_AUTO=y
+CONFIG_DUMMY_KEYB=y
+CONFIG_SERIAL_MANY_PORTS=y
+# CONFIG_MIPS_AU1000 is not set
+
+#
+# CPU selection
+#
+# CONFIG_CPU_MIPS32 is not set
+# CONFIG_CPU_MIPS64 is not set
+# CONFIG_CPU_R3000 is not set
+# CONFIG_CPU_TX39XX is not set
+CONFIG_CPU_VR41XX=y
+# CONFIG_CPU_R4300 is not set
+# CONFIG_CPU_R4X00 is not set
+# CONFIG_CPU_TX49XX is not set
+# CONFIG_CPU_R5000 is not set
+# CONFIG_CPU_R5432 is not set
+# CONFIG_CPU_R6000 is not set
+# CONFIG_CPU_NEVADA is not set
+# CONFIG_CPU_R8000 is not set
+# CONFIG_CPU_R10000 is not set
+# CONFIG_CPU_RM7000 is not set
+# CONFIG_CPU_SB1 is not set
+# CONFIG_CPU_ADVANCED is not set
+# CONFIG_CPU_HAS_LLSC is not set
+# CONFIG_CPU_HAS_LLDSCD is not set
+# CONFIG_CPU_HAS_WB is not set
+CONFIG_CPU_HAS_SYNC=y
+
+#
+# General setup
+#
+CONFIG_CPU_LITTLE_ENDIAN=y
+CONFIG_NET=y
+# CONFIG_PCI_NAMES is not set
+# CONFIG_ISA is not set
+# CONFIG_EISA is not set
+# CONFIG_TC is not set
+# CONFIG_MCA is not set
+# CONFIG_SBUS is not set
+# CONFIG_HOTPLUG is not set
+# CONFIG_PCMCIA is not set
+# CONFIG_HOTPLUG_PCI is not set
+CONFIG_SYSVIPC=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+CONFIG_SYSCTL=y
+CONFIG_KCORE_ELF=y
+# CONFIG_KCORE_AOUT is not set
+# CONFIG_BINFMT_AOUT is not set
+CONFIG_BINFMT_ELF=y
+# CONFIG_MIPS32_COMPAT is not set
+# CONFIG_MIPS32_O32 is not set
+# CONFIG_MIPS32_N32 is not set
+# CONFIG_BINFMT_ELF32 is not set
+# CONFIG_BINFMT_MISC is not set
+# CONFIG_PM is not set
+
+#
+# Memory Technology Devices (MTD)
+#
+# CONFIG_MTD is not set
+
+#
+# Parallel port support
+#
+# CONFIG_PARPORT is not set
+
+#
+# Plug and Play configuration
+#
+# CONFIG_PNP is not set
+# CONFIG_ISAPNP is not set
+
+#
+# Block devices
+#
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_DEV_XD is not set
+# CONFIG_PARIDE is not set
+# CONFIG_BLK_CPQ_DA is not set
+# CONFIG_BLK_CPQ_CISS_DA is not set
+# CONFIG_CISS_SCSI_TAPE is not set
+# CONFIG_BLK_DEV_DAC960 is not set
+# CONFIG_BLK_DEV_UMEM is not set
+CONFIG_BLK_DEV_LOOP=y
+# CONFIG_BLK_DEV_NBD is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=4096
+# CONFIG_BLK_DEV_INITRD is not set
+# CONFIG_BLK_STATS is not set
+
+#
+# Multi-device support (RAID and LVM)
+#
+# CONFIG_MD is not set
+# CONFIG_BLK_DEV_MD is not set
+# CONFIG_MD_LINEAR is not set
+# CONFIG_MD_RAID0 is not set
+# CONFIG_MD_RAID1 is not set
+# CONFIG_MD_RAID5 is not set
+# CONFIG_MD_MULTIPATH is not set
+# CONFIG_BLK_DEV_LVM is not set
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+CONFIG_PACKET_MMAP=y
+CONFIG_NETLINK_DEV=y
+# CONFIG_NETFILTER is not set
+# CONFIG_FILTER is not set
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_PNP=y
+# CONFIG_IP_PNP_DHCP is not set
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_IP_MROUTE is not set
+# CONFIG_ARPD is not set
+# CONFIG_INET_ECN is not set
+# CONFIG_SYN_COOKIES is not set
+# CONFIG_IPV6 is not set
+# CONFIG_KHTTPD is not set
+# CONFIG_ATM is not set
+# CONFIG_VLAN_8021Q is not set
+
+#
+#  
+#
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+
+#
+# Appletalk devices
+#
+# CONFIG_DEV_APPLETALK is not set
+# CONFIG_DECNET is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_LLC is not set
+# CONFIG_NET_DIVERT is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+# CONFIG_NET_FASTROUTE is not set
+# CONFIG_NET_HW_FLOWCONTROL is not set
+
+#
+# QoS and/or fair queueing
+#
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+
+#
+# Telephony Support
+#
+# CONFIG_PHONE is not set
+# CONFIG_PHONE_IXJ is not set
+# CONFIG_PHONE_IXJ_PCMCIA is not set
+
+#
+# ATA/IDE/MFM/RLL support
+#
+# CONFIG_IDE is not set
+# CONFIG_BLK_DEV_IDE_MODES is not set
+# CONFIG_BLK_DEV_HD is not set
+
+#
+# SCSI support
+#
+# CONFIG_SCSI is not set
+
+#
+# I2O device support
+#
+# CONFIG_I2O is not set
+# CONFIG_I2O_PCI is not set
+# CONFIG_I2O_BLOCK is not set
+# CONFIG_I2O_LAN is not set
+# CONFIG_I2O_SCSI is not set
+# CONFIG_I2O_PROC is not set
+
+#
+# Network device support
+#
+CONFIG_NETDEVICES=y
+
+#
+# ARCnet devices
+#
+# CONFIG_ARCNET is not set
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+# CONFIG_ETHERTAP is not set
+
+#
+# Ethernet (10 or 100Mbit)
+#
+CONFIG_NET_ETHERNET=y
+# CONFIG_SUNLANCE is not set
+# CONFIG_HAPPYMEAL is not set
+# CONFIG_SUNBMAC is not set
+# CONFIG_SUNQE is not set
+# CONFIG_SUNGEM is not set
+CONFIG_NET_VENDOR_3COM=y
+# CONFIG_EL1 is not set
+# CONFIG_EL2 is not set
+# CONFIG_ELPLUS is not set
+# CONFIG_EL16 is not set
+# CONFIG_ELMC is not set
+# CONFIG_ELMC_II is not set
+CONFIG_VORTEX=y
+# CONFIG_LANCE is not set
+# CONFIG_NET_VENDOR_SMC is not set
+# CONFIG_NET_VENDOR_RACAL is not set
+# CONFIG_HP100 is not set
+# CONFIG_NET_ISA is not set
+CONFIG_NET_PCI=y
+# CONFIG_PCNET32 is not set
+# CONFIG_AMD8111_ETH is not set
+# CONFIG_ADAPTEC_STARFIRE is not set
+# CONFIG_APRICOT is not set
+# CONFIG_CS89x0 is not set
+# CONFIG_TULIP is not set
+# CONFIG_DE4X5 is not set
+# CONFIG_DGRS is not set
+# CONFIG_DM9102 is not set
+CONFIG_EEPRO100=y
+# CONFIG_E100 is not set
+# CONFIG_LNE390 is not set
+# CONFIG_FEALNX is not set
+# CONFIG_NATSEMI is not set
+# CONFIG_NE2K_PCI is not set
+# CONFIG_NE3210 is not set
+# CONFIG_ES3210 is not set
+CONFIG_8139CP=y
+CONFIG_8139TOO=y
+# CONFIG_8139TOO_PIO is not set
+# CONFIG_8139TOO_TUNE_TWISTER is not set
+# CONFIG_8139TOO_8129 is not set
+# CONFIG_8139_OLD_RX_RESET is not set
+# CONFIG_SIS900 is not set
+# CONFIG_EPIC100 is not set
+# CONFIG_SUNDANCE is not set
+# CONFIG_SUNDANCE_MMIO is not set
+# CONFIG_TLAN is not set
+# CONFIG_TC35815 is not set
+# CONFIG_VIA_RHINE is not set
+# CONFIG_VIA_RHINE_MMIO is not set
+# CONFIG_WINBOND_840 is not set
+# CONFIG_LAN_SAA9730 is not set
+# CONFIG_NET_POCKET is not set
+
+#
+# Ethernet (1000 Mbit)
+#
+# CONFIG_ACENIC is not set
+# CONFIG_DL2K is not set
+# CONFIG_E1000 is not set
+# CONFIG_MYRI_SBUS is not set
+# CONFIG_NS83820 is not set
+# CONFIG_HAMACHI is not set
+# CONFIG_YELLOWFIN is not set
+# CONFIG_R8169 is not set
+# CONFIG_SK98LIN is not set
+# CONFIG_TIGON3 is not set
+# CONFIG_FDDI is not set
+# CONFIG_HIPPI is not set
+# CONFIG_PLIP is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+
+#
+# Wireless LAN (non-hamradio)
+#
+# CONFIG_NET_RADIO is not set
+
+#
+# Token Ring devices
+#
+# CONFIG_TR is not set
+# CONFIG_NET_FC is not set
+# CONFIG_RCPCI is not set
+# CONFIG_SHAPER is not set
+
+#
+# Wan interfaces
+#
+# CONFIG_WAN is not set
+
+#
+# Amateur Radio support
+#
+# CONFIG_HAMRADIO is not set
+
+#
+# IrDA (infrared) support
+#
+# CONFIG_IRDA is not set
+
+#
+# ISDN subsystem
+#
+# CONFIG_ISDN is not set
+
+#
+# Input core support
+#
+# CONFIG_INPUT is not set
+# CONFIG_INPUT_KEYBDEV is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_JOYDEV is not set
+# CONFIG_INPUT_EVDEV is not set
+
+#
+# Character devices
+#
+CONFIG_VT=y
+# CONFIG_VT_CONSOLE is not set
+CONFIG_SERIAL=y
+CONFIG_SERIAL_CONSOLE=y
+# CONFIG_SERIAL_EXTENDED is not set
+# CONFIG_SERIAL_NONSTANDARD is not set
+CONFIG_UNIX98_PTYS=y
+CONFIG_UNIX98_PTY_COUNT=256
+
+#
+# I2C support
+#
+# CONFIG_I2C is not set
+
+#
+# Mice
+#
+# CONFIG_BUSMOUSE is not set
+# CONFIG_MOUSE is not set
+
+#
+# Joysticks
+#
+# CONFIG_INPUT_GAMEPORT is not set
+
+#
+# Input core support is needed for gameports
+#
+
+#
+# Input core support is needed for joysticks
+#
+# CONFIG_QIC02_TAPE is not set
+# CONFIG_IPMI_HANDLER is not set
+# CONFIG_IPMI_PANIC_EVENT is not set
+# CONFIG_IPMI_DEVICE_INTERFACE is not set
+# CONFIG_IPMI_KCS is not set
+# CONFIG_IPMI_WATCHDOG is not set
+
+#
+# Watchdog Cards
+#
+CONFIG_WATCHDOG=y
+# CONFIG_WATCHDOG_NOWAYOUT is not set
+# CONFIG_ACQUIRE_WDT is not set
+# CONFIG_ADVANTECH_WDT is not set
+# CONFIG_ALIM7101_WDT is not set
+# CONFIG_SC520_WDT is not set
+# CONFIG_PCWATCHDOG is not set
+# CONFIG_EUROTECH_WDT is not set
+# CONFIG_IB700_WDT is not set
+# CONFIG_WAFER_WDT is not set
+# CONFIG_I810_TCO is not set
+# CONFIG_MIXCOMWD is not set
+# CONFIG_60XX_WDT is not set
+# CONFIG_SC1200_WDT is not set
+# CONFIG_SCx200_WDT is not set
+# CONFIG_SOFT_WATCHDOG is not set
+# CONFIG_W83877F_WDT is not set
+# CONFIG_WDT is not set
+# CONFIG_WDTPCI is not set
+# CONFIG_MACHZ_WDT is not set
+# CONFIG_INDYDOG is not set
+# CONFIG_AMD7XX_TCO is not set
+# CONFIG_SCx200_GPIO is not set
+# CONFIG_AMD_PM768 is not set
+# CONFIG_NVRAM is not set
+# CONFIG_RTC is not set
+# CONFIG_MIPS_RTC is not set
+# CONFIG_DTLK is not set
+# CONFIG_R3964 is not set
+# CONFIG_APPLICOM is not set
+
+#
+# Ftape, the floppy tape device driver
+#
+# CONFIG_FTAPE is not set
+# CONFIG_AGP is not set
+# CONFIG_DRM is not set
+
+#
+# File systems
+#
+# CONFIG_QUOTA is not set
+CONFIG_AUTOFS_FS=y
+CONFIG_AUTOFS4_FS=y
+# CONFIG_REISERFS_FS is not set
+# CONFIG_REISERFS_CHECK is not set
+# CONFIG_REISERFS_PROC_INFO is not set
+# CONFIG_ADFS_FS is not set
+# CONFIG_ADFS_FS_RW is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BEFS_DEBUG is not set
+# CONFIG_BFS_FS is not set
+# CONFIG_EXT3_FS is not set
+# CONFIG_JBD is not set
+# CONFIG_JBD_DEBUG is not set
+# CONFIG_FAT_FS is not set
+# CONFIG_MSDOS_FS is not set
+# CONFIG_UMSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_EFS_FS is not set
+# CONFIG_JFFS_FS is not set
+# CONFIG_JFFS2_FS is not set
+# CONFIG_CRAMFS is not set
+# CONFIG_TMPFS is not set
+CONFIG_RAMFS=y
+# CONFIG_ISO9660_FS is not set
+# CONFIG_JOLIET is not set
+# CONFIG_ZISOFS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_JFS_DEBUG is not set
+# CONFIG_JFS_STATISTICS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_VXFS_FS is not set
+# CONFIG_NTFS_FS is not set
+# CONFIG_NTFS_RW is not set
+# CONFIG_HPFS_FS is not set
+CONFIG_PROC_FS=y
+# CONFIG_DEVFS_FS is not set
+# CONFIG_DEVFS_MOUNT is not set
+# CONFIG_DEVFS_DEBUG is not set
+CONFIG_DEVPTS_FS=y
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_QNX4FS_RW is not set
+# CONFIG_ROMFS_FS is not set
+CONFIG_EXT2_FS=y
+# CONFIG_SYSV_FS is not set
+# CONFIG_UDF_FS is not set
+# CONFIG_UDF_RW is not set
+# CONFIG_UFS_FS is not set
+# CONFIG_UFS_FS_WRITE is not set
+
+#
+# Network File Systems
+#
+# CONFIG_CODA_FS is not set
+# CONFIG_INTERMEZZO_FS is not set
+CONFIG_NFS_FS=y
+# CONFIG_NFS_V3 is not set
+CONFIG_ROOT_NFS=y
+CONFIG_NFSD=y
+# CONFIG_NFSD_V3 is not set
+# CONFIG_NFSD_TCP is not set
+CONFIG_SUNRPC=y
+CONFIG_LOCKD=y
+# CONFIG_SMB_FS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_NCPFS_PACKET_SIGNING is not set
+# CONFIG_NCPFS_IOCTL_LOCKING is not set
+# CONFIG_NCPFS_STRONG is not set
+# CONFIG_NCPFS_NFS_NS is not set
+# CONFIG_NCPFS_OS2_NS is not set
+# CONFIG_NCPFS_SMALLDOS is not set
+# CONFIG_NCPFS_NLS is not set
+# CONFIG_NCPFS_EXTRAS is not set
+# CONFIG_ZISOFS_FS is not set
+
+#
+# Partition Types
+#
+CONFIG_PARTITION_ADVANCED=y
+# CONFIG_ACORN_PARTITION is not set
+# CONFIG_OSF_PARTITION is not set
+# CONFIG_AMIGA_PARTITION is not set
+# CONFIG_ATARI_PARTITION is not set
+# CONFIG_MAC_PARTITION is not set
+CONFIG_MSDOS_PARTITION=y
+# CONFIG_BSD_DISKLABEL is not set
+# CONFIG_MINIX_SUBPARTITION is not set
+# CONFIG_SOLARIS_X86_PARTITION is not set
+# CONFIG_UNIXWARE_DISKLABEL is not set
+# CONFIG_LDM_PARTITION is not set
+# CONFIG_SGI_PARTITION is not set
+# CONFIG_ULTRIX_PARTITION is not set
+# CONFIG_SUN_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
+# CONFIG_SMB_NLS is not set
+# CONFIG_NLS is not set
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+
+#
+# Console drivers
+#
+# CONFIG_VGA_CONSOLE is not set
+# CONFIG_MDA_CONSOLE is not set
+
+#
+# Frame-buffer support
+#
+# CONFIG_FB is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+
+#
+# USB support
+#
+# CONFIG_USB is not set
+
+#
+# Bluetooth support
+#
+# CONFIG_BLUEZ is not set
+
+#
+# Kernel hacking
+#
+CONFIG_CROSSCOMPILE=y
+# CONFIG_RUNTIME_DEBUG is not set
+# CONFIG_KGDB is not set
+# CONFIG_GDB_CONSOLE is not set
+# CONFIG_MAGIC_SYSRQ is not set
+# CONFIG_MIPS_UNCACHED is not set
+
+#
+# Library routines
+#
+# CONFIG_ZLIB_INFLATE is not set
+# CONFIG_ZLIB_DEFLATE is not set
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/setup.c linux/arch/mips/kernel/setup.c
--- linux.orig/arch/mips/kernel/setup.c	Wed May  7 12:06:45 2003
+++ linux/arch/mips/kernel/setup.c	Tue May 20 15:39:05 2003
@@ -622,6 +622,11 @@
 			tanbac_tb0226_setup();
 			break;
 #endif
+#ifdef CONFIG_TANBAC_TB0229
+		case MACH_TANBAC_TB0229:
+			tanbac_tb0229_setup();
+			break;
+#endif
 		}
 		break;
 #endif
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0229/Makefile linux/arch/mips/vr41xx/tanbac-tb0229/Makefile
--- linux.orig/arch/mips/vr41xx/tanbac-tb0229/Makefile	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/Makefile	Tue May 20 15:39:05 2003
@@ -0,0 +1,19 @@
+#
+# Makefile for the TANBAC TB0229(VR4131DIMM) specific parts of the kernel
+#
+# Note! Dependencies are done automagically by 'make dep', which also
+# removes any old dependencies. DON'T put your own dependencies here
+# unless it's something special (ie not a .c file).
+#
+
+USE_STANDARD_AS_RULE := true
+
+O_TARGET := tb0229.o
+
+all: tb0229.o
+
+obj-y	:= init.o setup.o reboot.o
+
+obj-$(CONFIG_PCI)	+= pci_fixup.o
+
+include $(TOPDIR)/Rules.make
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0229/init.c linux/arch/mips/vr41xx/tanbac-tb0229/init.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0229/init.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/init.c	Tue May 20 21:52:52 2003
@@ -0,0 +1,69 @@
+/*
+ * FILE NAME
+ *	arch/mips/vr41xx/tanbac-tb0229/init.c
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Initialisation code for the TANBAC TB0229(VR4131DIMM)
+ *
+ * Copyright 2002,2003 Yoichi Yuasa
+ *                yuasa@hh.iij4u.or.jp
+ *
+ * Modified for TANBAC TB0229:
+ * Copyright 2003 Megasolution Inc.
+ *                matsu@megasolution.jp
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/string.h>
+
+#include <asm/bootinfo.h>
+#include <asm/cpu.h>
+#include <asm/mipsregs.h>
+#include <asm/vr41xx/vr41xx.h>
+
+char arcs_cmdline[CL_SIZE];
+
+const char *get_system_type(void)
+{
+	return "TANBAC TB0229";
+}
+
+void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
+{
+	u32 config;
+	int i;
+
+	/*
+	 * collect args and prepare cmd_line
+	 */
+	for (i = 1; i < argc; i++) {
+		strcat(arcs_cmdline, argv[i]);
+		if (i < (argc - 1))
+			strcat(arcs_cmdline, " ");
+	}
+
+	mips_machgroup = MACH_GROUP_NEC_VR41XX;
+	mips_machtype = MACH_TANBAC_TB0229;
+
+	switch (current_cpu_data.processor_id) {
+	case PRID_VR4131_REV1_2:
+		config = read_c0_config();
+		config &= ~0x00000030UL;
+		config |= 0x00410000UL;
+		write_c0_config(config);
+		break;
+	default:
+		break;
+	}
+}
+
+void __init prom_free_prom_memory (void)
+{
+}
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c linux/arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c	Tue May 20 15:39:05 2003
@@ -0,0 +1,71 @@
+/*
+ * FILE NAME
+ *	arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	The TANBAC TB0229(VR4131DIMM) specific PCI fixups.
+ *
+ * Copyright 2003 Megasolution Inc.
+ *                matsu@megasolution.jp
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+
+#include <asm/vr41xx/tb0229.h>
+
+void __init pcibios_fixup_resources(struct pci_dev *dev)
+{
+}
+
+void __init pcibios_fixup(void)
+{
+}
+
+void __init pcibios_fixup_irqs(void)
+{
+#ifdef CONFIG_TANBAC_TB0219
+	struct pci_dev *dev;
+	u8 slot;
+
+	pci_for_each_dev(dev) {
+		slot = PCI_SLOT(dev->devfn);
+		dev->irq = 0;
+
+		switch (slot) {
+		case 12:
+			vr41xx_set_irq_trigger(TB0219_PCI_SLOT1_PIN , TRIGGER_LEVEL,
+			                       SIGNAL_THROUGH);
+			vr41xx_set_irq_level(TB0219_PCI_SLOT1_PIN, LEVEL_LOW);
+			dev->irq = TB0219_PCI_SLOT1_IRQ;
+			break;
+		case 13:
+			vr41xx_set_irq_trigger(TB0219_PCI_SLOT2_PIN , TRIGGER_LEVEL,
+			                       SIGNAL_THROUGH);
+			vr41xx_set_irq_level(TB0219_PCI_SLOT2_PIN, LEVEL_LOW);
+			dev->irq = TB0219_PCI_SLOT2_IRQ;
+			break;
+		case 14:
+			vr41xx_set_irq_trigger(TB0219_PCI_SLOT3_PIN , TRIGGER_LEVEL,
+			                       SIGNAL_THROUGH);
+			vr41xx_set_irq_level(TB0219_PCI_SLOT3_PIN, LEVEL_LOW);
+			dev->irq = TB0219_PCI_SLOT3_IRQ;
+			break;
+		default:
+			break;
+		}
+
+		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
+	}
+#endif
+}
+
+unsigned int pcibios_assign_all_busses(void)
+{
+	return 0;
+}
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0229/reboot.c linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0229/reboot.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c	Tue May 20 15:39:05 2003
@@ -0,0 +1,30 @@
+/*
+ * FILE NAME
+ *	arch/mips/vr41xx/tanbac-tb0229/reboot.c
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Depending on TANBAC TB0229(VR4131DIMM) of reboot system call.
+ *
+ * Copyright 2003 Megasolution Inc.
+ *                matsu@megasolution.jp
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+#include <asm/io.h>
+#include <asm/vr41xx/tb0229.h>
+
+#define tb0229_hard_reset()	writew(0, TB0219_RESET_REGS)
+
+void tanbac_tb0229_restart(char *command)
+{
+#ifdef CONFIG_TANBAC_TB0219
+	local_irq_disable();
+	tb0229_hard_reset();
+	while (1);
+#else
+	vr41xx_restart(command);
+#endif
+}
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0229/setup.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Tue May 20 17:38:32 2003
@@ -0,0 +1,126 @@
+/*
+ * FILE NAME
+ *	arch/mips/vr41xx/tanbac-tb0229/setup.c
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Setup for the TANBAC TB0229 (VR4131DIMM)
+ *
+ * Copyright 2002,2003 Yoichi Yuasa
+ *                yuasa@hh.iij4u.or.jp
+ *
+ * Modified for TANBAC TB0229:
+ * Copyright 2003 Megasolution Inc.
+ *                matsu@megasolution.jp
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+#include <linux/config.h>
+#include <linux/blk.h>
+#include <linux/console.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+
+#include <asm/pci_channel.h>
+#include <asm/reboot.h>
+#include <asm/time.h>
+#include <asm/vr41xx/tb0229.h>
+
+#ifdef CONFIG_BLK_DEV_INITRD
+extern void * __rd_start, * __rd_end;
+#endif
+
+#ifdef CONFIG_PCI
+static struct resource vr41xx_pci_io_resource = {
+	.name	= "PCI I/O space",
+	.start	= VR41XX_PCI_IO_START,
+	.end	= VR41XX_PCI_IO_END,
+	.flags	= IORESOURCE_IO,
+};
+
+static struct resource vr41xx_pci_mem_resource = {
+	.name	= "PCI memory space",
+	.start	= VR41XX_PCI_MEM_START,
+	.end	= VR41XX_PCI_MEM_END,
+	.flags	= IORESOURCE_MEM,
+};
+
+extern struct pci_ops vr41xx_pci_ops;
+
+struct pci_channel mips_pci_channels[] = {
+	{	.pci_ops	= &vr41xx_pci_ops,
+		.io_resource	= &vr41xx_pci_io_resource,
+		.mem_resource	= &vr41xx_pci_mem_resource,
+		.first_devfn	= 0,
+		.last_devfn	= 256,	},
+	{	.pci_ops	= NULL,
+		.io_resource	= NULL,
+		.mem_resource	= NULL,
+		.first_devfn	= 0,
+		.last_devfn	= 0,	}
+};
+
+struct vr41xx_pci_address_space vr41xx_pci_mem1 = {
+	.internal_base	= VR41XX_PCI_MEM1_BASE,
+	.address_mask	= VR41XX_PCI_MEM1_MASK,
+	.pci_base	= IO_MEM1_RESOURCE_START,
+};
+
+struct vr41xx_pci_address_space vr41xx_pci_mem2 = {
+	.internal_base	= VR41XX_PCI_MEM2_BASE,
+	.address_mask	= VR41XX_PCI_MEM2_MASK,
+	.pci_base	= IO_MEM2_RESOURCE_START,
+};
+
+struct vr41xx_pci_address_space vr41xx_pci_io = {
+	.internal_base	= VR41XX_PCI_IO_BASE,
+	.address_mask	= VR41XX_PCI_IO_MASK,
+	.pci_base	= IO_PORT_RESOURCE_START,
+};
+
+static struct vr41xx_pci_address_map pci_address_map = {
+	.mem1	= &vr41xx_pci_mem1,
+	.mem2	= &vr41xx_pci_mem2,
+	.io	= &vr41xx_pci_io,
+};
+#endif
+
+void __init tanbac_tb0229_setup(void)
+{
+	set_io_port_base(IO_PORT_BASE);
+	ioport_resource.start = IO_PORT_RESOURCE_START;
+	ioport_resource.end = IO_PORT_RESOURCE_END;
+	iomem_resource.start = IO_MEM1_RESOURCE_START;
+	iomem_resource.end = IO_MEM2_RESOURCE_END;
+
+#ifdef CONFIG_BLK_DEV_INITRD
+	ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0);
+	initrd_start = (unsigned long)&__rd_start;
+	initrd_end = (unsigned long)&__rd_end;
+#endif
+
+	_machine_restart = tanbac_tb0229_restart;
+	_machine_halt = vr41xx_halt;
+	_machine_power_off = vr41xx_power_off;
+
+	board_time_init = vr41xx_time_init;
+	board_timer_setup = vr41xx_timer_setup;
+
+#ifdef CONFIG_FB
+	conswitchp = &dummy_con;
+#endif
+
+	vr41xx_bcu_init();
+
+	vr41xx_cmu_init(0);
+
+	vr41xx_siu_init(SIU_RS232C, 0);
+	vr41xx_dsiu_init();
+
+#ifdef CONFIG_PCI
+	vr41xx_pciu_init(&pci_address_map);
+#endif
+}
+
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/bootinfo.h linux/include/asm-mips/bootinfo.h
--- linux.orig/include/asm-mips/bootinfo.h	Mon Apr 14 10:47:07 2003
+++ linux/include/asm-mips/bootinfo.h	Tue May 20 17:48:14 2003
@@ -184,6 +184,7 @@
 #define MACH_IBM_WORKPAD	4	/* IBM WorkPad z50 */
 #define MACH_CASIO_E55		5	/* CASIO CASSIOPEIA E-10/15/55/65 */
 #define MACH_TANBAC_TB0226	6	/* TANBAC TB0226 (MBASE) */
+#define MACH_TANBAC_TB0229	7	/* TANBAC TB0229 (VR4131DIMM) */
 
 #define CL_SIZE			(256)
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/tb0229.h linux/include/asm-mips/vr41xx/tb0229.h
--- linux.orig/include/asm-mips/vr41xx/tb0229.h	Thu Jan  1 09:00:00 1970
+++ linux/include/asm-mips/vr41xx/tb0229.h	Tue May 20 17:48:32 2003
@@ -0,0 +1,73 @@
+/*
+ * FILE NAME
+ *	include/asm-mips/vr41xx/tb0229.h
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Include file for TANBAC TB0229 and TB0219.
+ *
+ * Copyright 2002,2003 Yoichi Yuasa
+ *                yuasa@hh.iij4u.or.jp
+ *
+ * Modified for TANBAC TB0229:
+ * Copyright 2003 Megasolution Inc.
+ *                matsu@megasolution.jp
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+#ifndef __TANBAC_TB0229_H
+#define __TANBAC_TB0229_H
+
+#include <asm/addrspace.h>
+#include <asm/vr41xx/vr41xx.h>
+
+/*
+ * Board specific address mapping
+ */
+#define VR41XX_PCI_MEM1_BASE		0x10000000
+#define VR41XX_PCI_MEM1_SIZE		0x04000000
+#define VR41XX_PCI_MEM1_MASK		0x7c000000
+
+#define VR41XX_PCI_MEM2_BASE		0x14000000
+#define VR41XX_PCI_MEM2_SIZE		0x02000000
+#define VR41XX_PCI_MEM2_MASK		0x7e000000
+
+#define VR41XX_PCI_IO_BASE		0x16000000
+#define VR41XX_PCI_IO_SIZE		0x02000000
+#define VR41XX_PCI_IO_MASK		0x7e000000
+
+#define VR41XX_PCI_IO_START		0x01000000
+#define VR41XX_PCI_IO_END		0x01ffffff
+
+#define VR41XX_PCI_MEM_START		0x12000000
+#define VR41XX_PCI_MEM_END		0x15ffffff
+
+#define IO_PORT_BASE			KSEG1ADDR(VR41XX_PCI_IO_BASE)
+#define IO_PORT_RESOURCE_START		0
+#define IO_PORT_RESOURCE_END		VR41XX_PCI_IO_SIZE
+#define IO_MEM1_RESOURCE_START		VR41XX_PCI_MEM1_BASE
+#define IO_MEM1_RESOURCE_END		(VR41XX_PCI_MEM1_BASE + VR41XX_PCI_MEM1_SIZE)
+#define IO_MEM2_RESOURCE_START		VR41XX_PCI_MEM2_BASE
+#define IO_MEM2_RESOURCE_END		(VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE)
+
+/*
+ * General-Purpose I/O Pin Number
+ */
+#define TB0219_PCI_SLOT1_PIN		2
+#define TB0219_PCI_SLOT2_PIN		3
+#define TB0219_PCI_SLOT3_PIN		4
+
+/*
+ * Interrupt Number
+ */
+#define TB0219_PCI_SLOT1_IRQ		GIU_IRQ(TB0219_PCI_SLOT1_PIN)
+#define TB0219_PCI_SLOT2_IRQ		GIU_IRQ(TB0219_PCI_SLOT2_PIN)
+#define TB0219_PCI_SLOT3_IRQ		GIU_IRQ(TB0219_PCI_SLOT3_PIN)
+
+#define TB0219_RESET_REGS		KSEG1ADDR(0x0a00000e)
+
+extern void tanbac_tb0229_restart(char *command);
+
+#endif /* __TANBAC_TB0229_H */


--Multipart_Tue__20_May_2003_22:41:45_+0900_08458450
Content-Type: text/plain;
 name="tanbac-tb0229-v25.diff"
Content-Disposition: attachment;
 filename="tanbac-tb0229-v25.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/Kconfig-shared linux/arch/mips/Kconfig-shared
--- linux.orig/arch/mips/Kconfig-shared	Wed May  7 12:09:12 2003
+++ linux/arch/mips/Kconfig-shared	Tue May 20 16:01:11 2003
@@ -16,7 +16,7 @@
 
 config PCI_AUTO
 	bool "Support for PCI AUTO Config" if MIPS_PB1000
-	default y if ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || NEC_EAGLE || DDB5477 || DDB5476 || DDB5074 || MIPS_ITE8172 || MIPS_IVR || MIPS_EV96100 || MIPS_PB1500 || TANBAC_TB0226
+	default y if ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || NEC_EAGLE || DDB5477 || DDB5476 || DDB5074 || MIPS_ITE8172 || MIPS_IVR || MIPS_EV96100 || MIPS_PB1500 || TANBAC_TB0226 || TANBAC_TB0229
 
 
 config BAGET_MIPS
@@ -453,7 +453,7 @@
 
 config PCI
 	bool "Support for PCI controller" if SIBYTE_SB1xxx_SOC && SIBYTE_SB1250
-	default y if ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || SNI_RM200_PCI || SGI_IP32 || SGI_IP27 || NEC_EAGLE || DDB5477 || DDB5476 || DDB5074 || MOMENCO_OCELOT_G || MOMENCO_OCELOT || MIPS_MALTA || MIPS_ATLAS || LASAT || MIPS_ITE8172 || HP_LASERJET || MIPS_IVR || MIPS_EV96100 || MIPS_EV64120 || MIPS_COBALT || MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000 || TANBAC_TB0226
+	default y if ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || SNI_RM200_PCI || SGI_IP32 || SGI_IP27 || NEC_EAGLE || DDB5477 || DDB5476 || DDB5074 || MOMENCO_OCELOT_G || MOMENCO_OCELOT || MIPS_MALTA || MIPS_ATLAS || LASAT || MIPS_ITE8172 || HP_LASERJET || MIPS_IVR || MIPS_EV96100 || MIPS_EV64120 || MIPS_COBALT || MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000 || TANBAC_TB0226 || TANBAC_TB0229
 	help
 	  Find out whether you have a PCI motherboard. PCI is the name of a
 	  bus system, i.e. the way the CPU talks to the other stuff inside
@@ -483,6 +483,12 @@
 	  The TANBAC TB0226 (Mbase) is a MIPS-based platform manufactured by TANBAC.
 	  Please refer to <http://www.tanbac.co.jp/> about Mbase.
 
+config TANBAC_TB0229
+	bool "Support for TANBAC TB0229 (VR4131DIMM)"
+	help
+	  The TANBAC TB0229 (VR4131DIMM) is a MIPS-based platform manufactured by TANBAC.
+	  Please refer to <http://www.tanbac.co.jp/> about VR4131DIMM.
+
 config TOSHIBA_JMR3927
 	bool "Support for Toshiba JMR-TX3927 board"
 	depends on MIPS32
@@ -540,8 +546,8 @@
 
 config NONCOHERENT_IO
 	bool
-	depends on ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || SNI_RM200_PCI || SGI_IP32 || SGI_IP22 || NINO || NEC_EAGLE || NEC_OSPREY || DDB5477 || DDB5476 || DDB5074 || MOMENCO_OCELOT_G || MOMENCO_OCELOT || MIPS_SEAD || MIPS_MALTA || MIPS_MAGNUM_4000 || OLIVETTI_M700 || MIPS_ATLAS || LASAT || MIPS_ITE8172 || IBM_WORKPAD || HP_LASERJET || MIPS_IVR || MIPS_EV96100 || MIPS_EV64120 || DECSTATION || MIPS_COBALT || MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000 || CASIO_E55 || ACER_PICA_61 || TANBAC_TB0226
-	default y if ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || SNI_RM200_PCI || SGI_IP32 || SGI_IP22 || NINO || NEC_EAGLE || NEC_OSPREY || DDB5477 || DDB5476 || DDB5074 || MOMENCO_OCELOT_G || MOMENCO_OCELOT || MIPS_SEAD || MIPS_MALTA || MIPS_MAGNUM_4000 || OLIVETTI_M700 || MIPS_ATLAS || LASAT || MIPS_ITE8172 || IBM_WORKPAD || HP_LASERJET || MIPS_IVR || MIPS_EV96100 || MIPS_EV64120 || DECSTATION || MIPS_COBALT || MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000 || CASIO_E55 || ACER_PICA_61 || TANBAC_TB0226
+	depends on ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || SNI_RM200_PCI || SGI_IP32 || SGI_IP22 || NINO || NEC_EAGLE || NEC_OSPREY || DDB5477 || DDB5476 || DDB5074 || MOMENCO_OCELOT_G || MOMENCO_OCELOT || MIPS_SEAD || MIPS_MALTA || MIPS_MAGNUM_4000 || OLIVETTI_M700 || MIPS_ATLAS || LASAT || MIPS_ITE8172 || IBM_WORKPAD || HP_LASERJET || MIPS_IVR || MIPS_EV96100 || MIPS_EV64120 || DECSTATION || MIPS_COBALT || MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000 || CASIO_E55 || ACER_PICA_61 || TANBAC_TB0226 || TANBAC_TB0229
+	default y if ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || SNI_RM200_PCI || SGI_IP32 || SGI_IP22 || NINO || NEC_EAGLE || NEC_OSPREY || DDB5477 || DDB5476 || DDB5074 || MOMENCO_OCELOT_G || MOMENCO_OCELOT || MIPS_SEAD || MIPS_MALTA || MIPS_MAGNUM_4000 || OLIVETTI_M700 || MIPS_ATLAS || LASAT || MIPS_ITE8172 || IBM_WORKPAD || HP_LASERJET || MIPS_IVR || MIPS_EV96100 || MIPS_EV64120 || DECSTATION || MIPS_COBALT || MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000 || CASIO_E55 || ACER_PICA_61 || TANBAC_TB0226 || TANBAC_TB0229
 	default n if (SIBYTE_SB1250 || SGI_IP27)
 
 config CPU_LITTLE_ENDIAN
@@ -555,22 +561,22 @@
 
 config IRQ_CPU
 	bool
-	depends on ZAO_CAPCELLA || VICTOR_MPC30X || SGI_IP22 || NEC_EAGLE || NEC_OSPREY || DDB5477 || DDB5476 || DDB5074 || IBM_WORKPAD || HP_LASERJET || DECSTATION || CASIO_E55 || TANBAC_TB0226
+	depends on ZAO_CAPCELLA || VICTOR_MPC30X || SGI_IP22 || NEC_EAGLE || NEC_OSPREY || DDB5477 || DDB5476 || DDB5074 || IBM_WORKPAD || HP_LASERJET || DECSTATION || CASIO_E55 || TANBAC_TB0226 || TANBAC_TB0229
 	default y
 
 config VR41XX_TIME_C
 	bool
-	depends on ZAO_CAPCELLA || VICTOR_MPC30X || NEC_EAGLE || IBM_WORKPAD || CASIO_E55 || TANBAC_TB0226
+	depends on ZAO_CAPCELLA || VICTOR_MPC30X || NEC_EAGLE || IBM_WORKPAD || CASIO_E55 || TANBAC_TB0226 || TANBAC_TB0229
 	default y
 
 config DUMMY_KEYB
 	bool
-	depends on ZAO_CAPCELLA || VICTOR_MPC30X || SIBYTE_SB1250 || NEC_EAGLE || NEC_OSPREY || DDB5477 || IBM_WORKPAD || CASIO_E55 || TANBAC_TB0226
+	depends on ZAO_CAPCELLA || VICTOR_MPC30X || SIBYTE_SB1250 || NEC_EAGLE || NEC_OSPREY || DDB5477 || IBM_WORKPAD || CASIO_E55 || TANBAC_TB0226 || TANBAC_TB0229
 	default y
 
 config VR41XX_COMMON
 	bool
-	depends on NEC_EAGLE || ZAO_CAPCELLA || VICTOR_MPC30X || IBM_WORKPAD || CASIO_E55 || TANBAC_TB0226
+	depends on NEC_EAGLE || ZAO_CAPCELLA || VICTOR_MPC30X || IBM_WORKPAD || CASIO_E55 || TANBAC_TB0226 || TANBAC_TB0229
 	default y
 
 config VRC4173
@@ -594,7 +600,7 @@
 
 config NEW_PCI
 	bool
-	depends on ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || NEC_EAGLE || DDB5477 || DDB5476 || DDB5074 || MIPS_ITE8172 || HP_LASERJET || MIPS_IVR || MIPS_EV96100 || MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000 || TANBAC_TB0226
+	depends on ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || NEC_EAGLE || DDB5477 || DDB5476 || DDB5074 || MIPS_ITE8172 || HP_LASERJET || MIPS_IVR || MIPS_EV96100 || MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000 || TANBAC_TB0226 || TANBAC_TB0229
 	default y
 
 config SWAP_IO_SPACE
@@ -746,6 +752,11 @@
 	bool
 	depends on TOSHIBA_JMR3927 || TOSHIBA_RBTX4927
 	default y
+
+config TANBAC_TB0219
+	bool "Added TANBAC TB0219 Base board support"
+	depends on TANBAC_TB0229
+
 endmenu
 
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/Makefile linux/arch/mips/Makefile
--- linux.orig/arch/mips/Makefile	Wed May  7 12:09:12 2003
+++ linux/arch/mips/Makefile	Tue May 20 16:01:11 2003
@@ -272,6 +272,12 @@
 load-$(CONFIG_TANBAC_TB0226)	+= 0x80000000
 
 #
+# TANBAC TB0229 VR4131DIMM (VR4131)
+#
+core-$(CONFIG_TANBAC_TB0229)	+= arch/mips/vr41xx/tanbac-tb0229/
+load-$(CONFIG_TANBAC_TB0229)	+= 0x80000000
+
+#
 # Philips Nino
 #
 core-$(CONFIG_NINO)		+= arch/mips/philips/nino/
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/defconfig-tb0229 linux/arch/mips/defconfig-tb0229
--- linux.orig/arch/mips/defconfig-tb0229	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/defconfig-tb0229	Tue May 20 16:51:13 2003
@@ -0,0 +1,624 @@
+#
+# Automatically generated make config: don't edit
+#
+CONFIG_MIPS=y
+CONFIG_MIPS32=y
+# CONFIG_MIPS64 is not set
+
+#
+# Code maturity level options
+#
+CONFIG_EXPERIMENTAL=y
+
+#
+# General setup
+#
+CONFIG_NET=y
+CONFIG_SYSVIPC=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+CONFIG_SYSCTL=y
+
+#
+# Loadable module support
+#
+CONFIG_MODULES=y
+CONFIG_MODVERSIONS=y
+CONFIG_KMOD=y
+
+#
+# Machine selection
+#
+# CONFIG_ACER_PICA_61 is not set
+CONFIG_PCI_AUTO=y
+# CONFIG_BAGET_MIPS is not set
+# CONFIG_CASIO_E55 is not set
+# CONFIG_MIPS_COBALT is not set
+# CONFIG_DECSTATION is not set
+# CONFIG_MIPS_EV64120 is not set
+# CONFIG_MIPS_EV96100 is not set
+# CONFIG_MIPS_IVR is not set
+# CONFIG_LASAT is not set
+# CONFIG_HP_LASERJET is not set
+# CONFIG_IBM_WORKPAD is not set
+# CONFIG_MIPS_ITE8172 is not set
+# CONFIG_MIPS_ATLAS is not set
+# CONFIG_MIPS_MAGNUM_4000 is not set
+# CONFIG_MIPS_MALTA is not set
+# CONFIG_MIPS_SEAD is not set
+# CONFIG_MOMENCO_OCELOT is not set
+# CONFIG_MOMENCO_OCELOT_G is not set
+# CONFIG_DDB5074 is not set
+# CONFIG_DDB5476 is not set
+# CONFIG_DDB5477 is not set
+# CONFIG_NEC_OSPREY is not set
+# CONFIG_NEC_EAGLE is not set
+# CONFIG_OLIVETTI_M700 is not set
+# CONFIG_NINO is not set
+# CONFIG_SGI_IP22 is not set
+# CONFIG_SGI_IP32 is not set
+# CONFIG_SOC_AU1X00 is not set
+# CONFIG_SIBYTE_SB1xxx_SOC is not set
+CONFIG_PCI=y
+# CONFIG_SNI_RM200_PCI is not set
+# CONFIG_TANBAC_TB0226 is not set
+CONFIG_TANBAC_TB0229=y
+# CONFIG_TOSHIBA_JMR3927 is not set
+# CONFIG_TOSHIBA_RBTX4927 is not set
+# CONFIG_VICTOR_MPC30X is not set
+# CONFIG_ZAO_CAPCELLA is not set
+CONFIG_RWSEM_GENERIC_SPINLOCK=y
+CONFIG_NONCOHERENT_IO=y
+CONFIG_CPU_LITTLE_ENDIAN=y
+CONFIG_IRQ_CPU=y
+CONFIG_VR41XX_TIME_C=y
+CONFIG_DUMMY_KEYB=y
+CONFIG_VR41XX_COMMON=y
+CONFIG_NEW_PCI=y
+# CONFIG_FB is not set
+CONFIG_TANBAC_TB0219=y
+
+#
+# CPU selection
+#
+# CONFIG_CPU_MIPS32 is not set
+# CONFIG_CPU_MIPS64 is not set
+# CONFIG_CPU_R3000 is not set
+# CONFIG_CPU_TX39XX is not set
+CONFIG_CPU_VR41XX=y
+# CONFIG_CPU_R4300 is not set
+# CONFIG_CPU_R4X00 is not set
+# CONFIG_CPU_TX49XX is not set
+# CONFIG_CPU_R5000 is not set
+# CONFIG_CPU_R5432 is not set
+# CONFIG_CPU_R6000 is not set
+# CONFIG_CPU_NEVADA is not set
+# CONFIG_CPU_R8000 is not set
+# CONFIG_CPU_R10000 is not set
+# CONFIG_CPU_RM7000 is not set
+# CONFIG_CPU_SB1 is not set
+# CONFIG_CPU_ADVANCED is not set
+CONFIG_CPU_HAS_SYNC=y
+# CONFIG_PREEMPT is not set
+
+#
+# Bus options (PCI, PCMCIA, EISA, ISA, TC)
+#
+CONFIG_PCI_NAMES=y
+CONFIG_MMU=y
+CONFIG_SWAP=y
+# CONFIG_HOTPLUG is not set
+
+#
+# Executable file formats
+#
+CONFIG_KCORE_ELF=y
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+
+#
+# Memory Technology Devices (MTD)
+#
+# CONFIG_MTD is not set
+
+#
+# Parallel port support
+#
+# CONFIG_PARPORT is not set
+
+#
+# Plug and Play configuration
+#
+# CONFIG_PNP is not set
+
+#
+# Block devices
+#
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_CPQ_DA is not set
+# CONFIG_BLK_CPQ_CISS_DA is not set
+# CONFIG_BLK_DEV_DAC960 is not set
+# CONFIG_BLK_DEV_UMEM is not set
+CONFIG_BLK_DEV_LOOP=m
+CONFIG_BLK_DEV_NBD=m
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=4096
+# CONFIG_BLK_DEV_INITRD is not set
+
+#
+# ATA/ATAPI/MFM/RLL support
+#
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+# CONFIG_SCSI is not set
+
+#
+# Multi-device support (RAID and LVM)
+#
+# CONFIG_MD is not set
+
+#
+# Fusion MPT device support
+#
+
+#
+# IEEE 1394 (FireWire) support (EXPERIMENTAL)
+#
+# CONFIG_IEEE1394 is not set
+
+#
+# I2O device support
+#
+# CONFIG_I2O is not set
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_NETLINK_DEV=m
+# CONFIG_NETFILTER is not set
+CONFIG_FILTER=y
+CONFIG_UNIX=y
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_NAT=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_TOS=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_ROUTE_LARGE_TABLES=y
+CONFIG_IP_PNP=y
+# CONFIG_IP_PNP_DHCP is not set
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+CONFIG_NET_IPIP=m
+CONFIG_NET_IPGRE=m
+# CONFIG_NET_IPGRE_BROADCAST is not set
+# CONFIG_IP_MROUTE is not set
+# CONFIG_ARPD is not set
+# CONFIG_INET_ECN is not set
+CONFIG_SYN_COOKIES=y
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_IPV6 is not set
+
+#
+# SCTP Configuration (EXPERIMENTAL)
+#
+CONFIG_IPV6_SCTP__=y
+# CONFIG_IP_SCTP is not set
+# CONFIG_ATM is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_LLC is not set
+# CONFIG_DECNET is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_NET_DIVERT is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+# CONFIG_NET_FASTROUTE is not set
+# CONFIG_NET_HW_FLOWCONTROL is not set
+
+#
+# QoS and/or fair queueing
+#
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+
+#
+# Network device support
+#
+CONFIG_NETDEVICES=y
+
+#
+# ARCnet devices
+#
+# CONFIG_ARCNET is not set
+CONFIG_DUMMY=m
+# CONFIG_BONDING is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+# CONFIG_ETHERTAP is not set
+
+#
+# Ethernet (10 or 100Mbit)
+#
+CONFIG_NET_ETHERNET=y
+# CONFIG_HAPPYMEAL is not set
+# CONFIG_SUNGEM is not set
+CONFIG_NET_VENDOR_3COM=y
+CONFIG_VORTEX=y
+# CONFIG_NET_VENDOR_SMC is not set
+# CONFIG_NET_VENDOR_RACAL is not set
+
+#
+# Tulip family network device support
+#
+# CONFIG_NET_TULIP is not set
+# CONFIG_HP100 is not set
+CONFIG_NET_PCI=y
+# CONFIG_PCNET32 is not set
+# CONFIG_ADAPTEC_STARFIRE is not set
+# CONFIG_B44 is not set
+# CONFIG_TC35815 is not set
+# CONFIG_DGRS is not set
+CONFIG_EEPRO100=y
+# CONFIG_E100 is not set
+# CONFIG_FEALNX is not set
+# CONFIG_NATSEMI is not set
+# CONFIG_NE2K_PCI is not set
+CONFIG_8139CP=y
+CONFIG_8139TOO=y
+# CONFIG_8139TOO_PIO is not set
+# CONFIG_8139TOO_TUNE_TWISTER is not set
+# CONFIG_8139TOO_8129 is not set
+# CONFIG_8139_OLD_RX_RESET is not set
+# CONFIG_SIS900 is not set
+# CONFIG_EPIC100 is not set
+# CONFIG_SUNDANCE is not set
+# CONFIG_TLAN is not set
+# CONFIG_VIA_RHINE is not set
+# CONFIG_LAN_SAA9730 is not set
+# CONFIG_NET_POCKET is not set
+
+#
+# Ethernet (1000 Mbit)
+#
+CONFIG_ACENIC=m
+# CONFIG_ACENIC_OMIT_TIGON_I is not set
+CONFIG_DL2K=m
+CONFIG_E1000=m
+# CONFIG_E1000_NAPI is not set
+CONFIG_NS83820=m
+CONFIG_HAMACHI=m
+CONFIG_YELLOWFIN=m
+CONFIG_SK98LIN=m
+CONFIG_TIGON3=m
+# CONFIG_FDDI is not set
+# CONFIG_HIPPI is not set
+CONFIG_PPP=m
+CONFIG_PPP_MULTILINK=y
+CONFIG_PPP_FILTER=y
+CONFIG_PPP_ASYNC=m
+CONFIG_PPP_SYNC_TTY=m
+CONFIG_PPP_DEFLATE=m
+CONFIG_PPP_BSDCOMP=m
+CONFIG_PPPOE=m
+CONFIG_SLIP=m
+CONFIG_SLIP_COMPRESSED=y
+CONFIG_SLIP_SMART=y
+CONFIG_SLIP_MODE_SLIP6=y
+
+#
+# Wireless LAN (non-hamradio)
+#
+# CONFIG_NET_RADIO is not set
+
+#
+# Token Ring devices
+#
+# CONFIG_TR is not set
+# CONFIG_NET_FC is not set
+# CONFIG_RCPCI is not set
+# CONFIG_SHAPER is not set
+
+#
+# Wan interfaces
+#
+# CONFIG_WAN is not set
+
+#
+# Amateur Radio support
+#
+# CONFIG_HAMRADIO is not set
+
+#
+# IrDA (infrared) support
+#
+# CONFIG_IRDA is not set
+
+#
+# ISDN subsystem
+#
+# CONFIG_ISDN_BOOL is not set
+
+#
+# Telephony Support
+#
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+CONFIG_INPUT=y
+
+#
+# Userland interfaces
+#
+CONFIG_INPUT_MOUSEDEV=m
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
+CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024
+# CONFIG_INPUT_JOYDEV is not set
+# CONFIG_INPUT_TSDEV is not set
+# CONFIG_INPUT_EVDEV is not set
+# CONFIG_INPUT_EVBUG is not set
+
+#
+# Input I/O drivers
+#
+# CONFIG_GAMEPORT is not set
+CONFIG_SOUND_GAMEPORT=y
+# CONFIG_SERIO is not set
+
+#
+# Input Device Drivers
+#
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_INPUT_JOYSTICK is not set
+# CONFIG_INPUT_TOUCHSCREEN is not set
+# CONFIG_INPUT_MISC is not set
+
+#
+# Character devices
+#
+CONFIG_VT=y
+# CONFIG_VT_CONSOLE is not set
+CONFIG_HW_CONSOLE=y
+# CONFIG_SERIAL_NONSTANDARD is not set
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+# CONFIG_SERIAL_8250_EXTENDED is not set
+
+#
+# Non-8250 serial port support
+#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_UNIX98_PTYS=y
+CONFIG_UNIX98_PTY_COUNT=256
+
+#
+# I2C support
+#
+# CONFIG_I2C is not set
+
+#
+# Mice
+#
+# CONFIG_BUSMOUSE is not set
+# CONFIG_QIC02_TAPE is not set
+
+#
+# Watchdog Cards
+#
+# CONFIG_WATCHDOG is not set
+# CONFIG_NVRAM is not set
+# CONFIG_RTC is not set
+# CONFIG_GEN_RTC is not set
+# CONFIG_DTLK is not set
+# CONFIG_R3964 is not set
+# CONFIG_APPLICOM is not set
+
+#
+# Ftape, the floppy tape device driver
+#
+# CONFIG_FTAPE is not set
+# CONFIG_AGP is not set
+# CONFIG_DRM is not set
+# CONFIG_RAW_DRIVER is not set
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+
+#
+# File systems
+#
+# CONFIG_QUOTA is not set
+CONFIG_QUOTACTL=y
+# CONFIG_AUTOFS_FS is not set
+CONFIG_AUTOFS4_FS=y
+# CONFIG_REISERFS_FS is not set
+# CONFIG_ADFS_FS is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BFS_FS is not set
+CONFIG_EXT3_FS=m
+CONFIG_EXT3_FS_XATTR=y
+# CONFIG_EXT3_FS_POSIX_ACL is not set
+CONFIG_JBD=y
+# CONFIG_JBD_DEBUG is not set
+CONFIG_FAT_FS=m
+CONFIG_MSDOS_FS=m
+CONFIG_VFAT_FS=m
+# CONFIG_EFS_FS is not set
+CONFIG_CRAMFS=m
+CONFIG_TMPFS=y
+CONFIG_RAMFS=y
+CONFIG_ISO9660_FS=y
+CONFIG_JOLIET=y
+CONFIG_ZISOFS=y
+CONFIG_JFS_FS=m
+# CONFIG_JFS_POSIX_ACL is not set
+# CONFIG_JFS_DEBUG is not set
+# CONFIG_JFS_STATISTICS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_VXFS_FS is not set
+# CONFIG_NTFS_FS is not set
+# CONFIG_HPFS_FS is not set
+CONFIG_PROC_FS=y
+# CONFIG_DEVFS_FS is not set
+CONFIG_DEVPTS_FS=y
+# CONFIG_QNX4FS_FS is not set
+CONFIG_ROMFS_FS=m
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UDF_FS is not set
+# CONFIG_UFS_FS is not set
+CONFIG_XFS_FS=y
+# CONFIG_XFS_RT is not set
+CONFIG_XFS_QUOTA=y
+CONFIG_XFS_POSIX_ACL=y
+
+#
+# Network File Systems
+#
+# CONFIG_CODA_FS is not set
+# CONFIG_INTERMEZZO_FS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V4 is not set
+CONFIG_ROOT_NFS=y
+CONFIG_NFSD=y
+CONFIG_NFSD_V3=y
+# CONFIG_NFSD_V4 is not set
+CONFIG_NFSD_TCP=y
+CONFIG_SUNRPC=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_EXPORTFS=y
+# CONFIG_CIFS is not set
+CONFIG_SMB_FS=m
+CONFIG_SMB_NLS_DEFAULT=y
+CONFIG_SMB_NLS_REMOTE="cp932"
+# CONFIG_NCP_FS is not set
+# CONFIG_AFS_FS is not set
+CONFIG_ZISOFS_FS=y
+CONFIG_FS_MBCACHE=y
+
+#
+# Partition Types
+#
+# CONFIG_PARTITION_ADVANCED is not set
+CONFIG_MSDOS_PARTITION=y
+CONFIG_SMB_NLS=y
+CONFIG_NLS=y
+
+#
+# Native Language Support
+#
+CONFIG_NLS_DEFAULT="iso8859-1"
+CONFIG_NLS_CODEPAGE_437=m
+# CONFIG_NLS_CODEPAGE_737 is not set
+# CONFIG_NLS_CODEPAGE_775 is not set
+# CONFIG_NLS_CODEPAGE_850 is not set
+# CONFIG_NLS_CODEPAGE_852 is not set
+# CONFIG_NLS_CODEPAGE_855 is not set
+# CONFIG_NLS_CODEPAGE_857 is not set
+# CONFIG_NLS_CODEPAGE_860 is not set
+# CONFIG_NLS_CODEPAGE_861 is not set
+# CONFIG_NLS_CODEPAGE_862 is not set
+# CONFIG_NLS_CODEPAGE_863 is not set
+# CONFIG_NLS_CODEPAGE_864 is not set
+# CONFIG_NLS_CODEPAGE_865 is not set
+# CONFIG_NLS_CODEPAGE_866 is not set
+# CONFIG_NLS_CODEPAGE_869 is not set
+# CONFIG_NLS_CODEPAGE_936 is not set
+# CONFIG_NLS_CODEPAGE_950 is not set
+CONFIG_NLS_CODEPAGE_932=m
+# CONFIG_NLS_CODEPAGE_949 is not set
+# CONFIG_NLS_CODEPAGE_874 is not set
+# CONFIG_NLS_ISO8859_8 is not set
+# CONFIG_NLS_CODEPAGE_1250 is not set
+# CONFIG_NLS_CODEPAGE_1251 is not set
+CONFIG_NLS_ISO8859_1=m
+# CONFIG_NLS_ISO8859_2 is not set
+# CONFIG_NLS_ISO8859_3 is not set
+# CONFIG_NLS_ISO8859_4 is not set
+# CONFIG_NLS_ISO8859_5 is not set
+# CONFIG_NLS_ISO8859_6 is not set
+# CONFIG_NLS_ISO8859_7 is not set
+# CONFIG_NLS_ISO8859_9 is not set
+# CONFIG_NLS_ISO8859_13 is not set
+# CONFIG_NLS_ISO8859_14 is not set
+# CONFIG_NLS_ISO8859_15 is not set
+# CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
+# CONFIG_NLS_UTF8 is not set
+
+#
+# Console drivers
+#
+# CONFIG_VGA_CONSOLE is not set
+# CONFIG_MDA_CONSOLE is not set
+
+#
+# Frame-buffer support
+#
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+
+#
+# USB support
+#
+# CONFIG_USB is not set
+
+#
+# Bluetooth support
+#
+# CONFIG_BT is not set
+
+#
+# Kernel hacking
+#
+CONFIG_CROSSCOMPILE=y
+# CONFIG_DEBUG_KERNEL is not set
+
+#
+# Security options
+#
+CONFIG_SECURITY_CAPABILITIES=y
+
+#
+# Cryptographic options
+#
+# CONFIG_CRYPTO is not set
+
+#
+# Library routines
+#
+# CONFIG_CRC32 is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_ZLIB_DEFLATE=m
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/setup.c linux/arch/mips/kernel/setup.c
--- linux.orig/arch/mips/kernel/setup.c	Wed May  7 12:09:14 2003
+++ linux/arch/mips/kernel/setup.c	Tue May 20 16:01:11 2003
@@ -611,6 +611,11 @@
 			casio_e55_setup();
 			break;
 #endif
+#ifdef CONFIG_TANBAC_TB0229
+		case MACH_TANBAC_TB0229:
+			tanbac_tb0229_setup();
+			break;
+#endif
 		}
 		break;
 #endif
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0229/Makefile linux/arch/mips/vr41xx/tanbac-tb0229/Makefile
--- linux.orig/arch/mips/vr41xx/tanbac-tb0229/Makefile	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/Makefile	Tue May 20 16:01:11 2003
@@ -0,0 +1,7 @@
+#
+# Makefile for the TANBAC TB0229(VR4131DIMM) specific parts of the kernel
+#
+
+obj-y	:= init.o reboot.o setup.o
+
+obj-$(CONFIG_PCI)	+= pci_fixup.o
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0229/init.c linux/arch/mips/vr41xx/tanbac-tb0229/init.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0229/init.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/init.c	Tue May 20 21:52:11 2003
@@ -0,0 +1,69 @@
+/*
+ * FILE NAME
+ *	arch/mips/vr41xx/tanbac-tb0229/init.c
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Initialisation code for the TANBAC TB0229(VR4131DIMM)
+ *
+ * Copyright 2002,2003 Yoichi Yuasa
+ *                yuasa@hh.iij4u.or.jp
+ *
+ * Modified for TANBAC TB0229:
+ * Copyright 2003 Megasolution Inc.
+ *                matsu@megasolution.jp
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/string.h>
+
+#include <asm/bootinfo.h>
+#include <asm/cpu.h>
+#include <asm/mipsregs.h>
+#include <asm/vr41xx/vr41xx.h>
+
+char arcs_cmdline[CL_SIZE];
+
+const char *get_system_type(void)
+{
+	return "TANBAC TB0229";
+}
+
+void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
+{
+	u32 config;
+	int i;
+
+	/*
+	 * collect args and prepare cmd_line
+	 */
+	for (i = 1; i < argc; i++) {
+		strcat(arcs_cmdline, argv[i]);
+		if (i < (argc - 1))
+			strcat(arcs_cmdline, " ");
+	}
+
+	mips_machgroup = MACH_GROUP_NEC_VR41XX;
+	mips_machtype = MACH_TANBAC_TB0229;
+
+	switch (current_cpu_data.processor_id) {
+	case PRID_VR4131_REV1_2:
+		config = read_c0_config();
+		config &= ~0x00000030UL;
+		config |= 0x00410000UL;
+		write_c0_config(config);
+		break;
+	default:
+		break;
+	}
+}
+
+void __init prom_free_prom_memory (void)
+{
+}
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c linux/arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c	Tue May 20 16:01:11 2003
@@ -0,0 +1,71 @@
+/*
+ * FILE NAME
+ *	arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	The TANBAC TB0229(VR4131DIMM) specific PCI fixups.
+ *
+ * Copyright 2003 Megasolution Inc.
+ *                matsu@megasolution.jp
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+
+#include <asm/vr41xx/tb0229.h>
+
+void __init pcibios_fixup_resources(struct pci_dev *dev)
+{
+}
+
+void __init pcibios_fixup(void)
+{
+}
+
+void __init pcibios_fixup_irqs(void)
+{
+#ifdef CONFIG_TANBAC_TB0219
+	struct pci_dev *dev;
+	u8 slot;
+
+	pci_for_each_dev(dev) {
+		slot = PCI_SLOT(dev->devfn);
+		dev->irq = 0;
+
+		switch (slot) {
+		case 12:
+			vr41xx_set_irq_trigger(TB0219_PCI_SLOT1_PIN , TRIGGER_LEVEL,
+			                       SIGNAL_THROUGH);
+			vr41xx_set_irq_level(TB0219_PCI_SLOT1_PIN, LEVEL_LOW);
+			dev->irq = TB0219_PCI_SLOT1_IRQ;
+			break;
+		case 13:
+			vr41xx_set_irq_trigger(TB0219_PCI_SLOT2_PIN , TRIGGER_LEVEL,
+			                       SIGNAL_THROUGH);
+			vr41xx_set_irq_level(TB0219_PCI_SLOT2_PIN, LEVEL_LOW);
+			dev->irq = TB0219_PCI_SLOT2_IRQ;
+			break;
+		case 14:
+			vr41xx_set_irq_trigger(TB0219_PCI_SLOT3_PIN , TRIGGER_LEVEL,
+			                       SIGNAL_THROUGH);
+			vr41xx_set_irq_level(TB0219_PCI_SLOT3_PIN, LEVEL_LOW);
+			dev->irq = TB0219_PCI_SLOT3_IRQ;
+			break;
+		default:
+			break;
+		}
+
+		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
+	}
+#endif
+}
+
+unsigned int pcibios_assign_all_busses(void)
+{
+	return 0;
+}
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0229/reboot.c linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0229/reboot.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c	Tue May 20 16:01:11 2003
@@ -0,0 +1,30 @@
+/*
+ * FILE NAME
+ *	arch/mips/vr41xx/tanbac-tb0229/reboot.c
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Depending on TANBAC TB0229(VR4131DIMM) of reboot system call.
+ *
+ * Copyright 2003 Megasolution Inc.
+ *                matsu@megasolution.jp
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+#include <asm/io.h>
+#include <asm/vr41xx/tb0229.h>
+
+#define tb0229_hard_reset()	writew(0, TB0219_RESET_REGS)
+
+void tanbac_tb0229_restart(char *command)
+{
+#ifdef CONFIG_TANBAC_TB0219
+	local_irq_disable();
+	tb0229_hard_reset();
+	while (1);
+#else
+	vr41xx_restart(command);
+#endif
+}
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0229/setup.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Tue May 20 17:32:44 2003
@@ -0,0 +1,127 @@
+/*
+ * FILE NAME
+ *	arch/mips/vr41xx/tanbac-tb0229/setup.c
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Setup for the TANBAC TB0229 (VR4131DIMM)
+ *
+ * Copyright 2002,2003 Yoichi Yuasa
+ *                yuasa@hh.iij4u.or.jp
+ *
+ * Modified for TANBAC TB0229:
+ * Copyright 2003 Megasolution Inc.
+ *                matsu@megasolution.jp
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+#include <linux/config.h>
+#include <linux/blk.h>
+#include <linux/console.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/root_dev.h>
+
+#include <asm/pci_channel.h>
+#include <asm/reboot.h>
+#include <asm/time.h>
+#include <asm/vr41xx/tb0229.h>
+
+#ifdef CONFIG_BLK_DEV_INITRD
+extern void * __rd_start, * __rd_end;
+#endif
+
+#ifdef CONFIG_PCI
+static struct resource vr41xx_pci_io_resource = {
+	.name	= "PCI I/O space",
+	.start	= VR41XX_PCI_IO_START,
+	.end	= VR41XX_PCI_IO_END,
+	.flags	= IORESOURCE_IO,
+};
+
+static struct resource vr41xx_pci_mem_resource = {
+	.name	= "PCI memory space",
+	.start	= VR41XX_PCI_MEM_START,
+	.end	= VR41XX_PCI_MEM_END,
+	.flags	= IORESOURCE_MEM,
+};
+
+extern struct pci_ops vr41xx_pci_ops;
+
+struct pci_channel mips_pci_channels[] = {
+	{	.pci_ops	= &vr41xx_pci_ops,
+		.io_resource	= &vr41xx_pci_io_resource,
+		.mem_resource	= &vr41xx_pci_mem_resource,
+		.first_devfn	= 0,
+		.last_devfn	= 256,	},
+	{	.pci_ops	= NULL,
+		.io_resource	= NULL,
+		.mem_resource	= NULL,
+		.first_devfn	= 0,
+		.last_devfn	= 0,	}
+};
+
+struct vr41xx_pci_address_space vr41xx_pci_mem1 = {
+	.internal_base	= VR41XX_PCI_MEM1_BASE,
+	.address_mask	= VR41XX_PCI_MEM1_MASK,
+	.pci_base	= IO_MEM1_RESOURCE_START,
+};
+
+struct vr41xx_pci_address_space vr41xx_pci_mem2 = {
+	.internal_base	= VR41XX_PCI_MEM2_BASE,
+	.address_mask	= VR41XX_PCI_MEM2_MASK,
+	.pci_base	= IO_MEM2_RESOURCE_START,
+};
+
+struct vr41xx_pci_address_space vr41xx_pci_io = {
+	.internal_base	= VR41XX_PCI_IO_BASE,
+	.address_mask	= VR41XX_PCI_IO_MASK,
+	.pci_base	= IO_PORT_RESOURCE_START
+};
+
+static struct vr41xx_pci_address_map pci_address_map = {
+	.mem1	= &vr41xx_pci_mem1,
+	.mem2	= &vr41xx_pci_mem2,
+	.io	= &vr41xx_pci_io,
+};
+#endif
+
+void __init tanbac_tb0229_setup(void)
+{
+	set_io_port_base(IO_PORT_BASE);
+	ioport_resource.start = IO_PORT_RESOURCE_START;
+	ioport_resource.end = IO_PORT_RESOURCE_END;
+	iomem_resource.start = IO_MEM1_RESOURCE_START;
+	iomem_resource.end = IO_MEM2_RESOURCE_END;
+
+#ifdef CONFIG_BLK_DEV_INITRD
+	ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0);
+	initrd_start = (unsigned long)&__rd_start;
+	initrd_end = (unsigned long)&__rd_end;
+#endif
+
+	_machine_restart = tanbac_tb0229_restart;
+	_machine_halt = vr41xx_halt;
+	_machine_power_off = vr41xx_power_off;
+
+	board_time_init = vr41xx_time_init;
+	board_timer_setup = vr41xx_timer_setup;
+
+#ifdef CONFIG_FB
+	conswitchp = &dummy_con;
+#endif
+
+	vr41xx_bcu_init();
+
+	vr41xx_cmu_init(0);
+
+	vr41xx_siu_init(SIU_RS232C, 0);
+	vr41xx_dsiu_init();
+
+#ifdef CONFIG_PCI
+	vr41xx_pciu_init(&pci_address_map);
+#endif
+}
+
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/bootinfo.h linux/include/asm-mips/bootinfo.h
--- linux.orig/include/asm-mips/bootinfo.h	Wed May  7 12:09:15 2003
+++ linux/include/asm-mips/bootinfo.h	Tue May 20 16:01:11 2003
@@ -184,6 +184,7 @@
 #define MACH_IBM_WORKPAD	4	/* IBM WorkPad z50 */
 #define MACH_CASIO_E55		5	/* CASIO CASSIOPEIA E-10/15/55/65 */
 #define MACH_TANBAC_TB0226	6	/* TANBAC TB0226 (Mbase) */
+#define MACH_TANBAC_TB0229	7	/* TANBAC TB0229 (VR4131DIMM) */
 
 #define CL_SIZE			(256)
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/tb0229.h linux/include/asm-mips/vr41xx/tb0229.h
--- linux.orig/include/asm-mips/vr41xx/tb0229.h	Thu Jan  1 09:00:00 1970
+++ linux/include/asm-mips/vr41xx/tb0229.h	Tue May 20 16:01:11 2003
@@ -0,0 +1,73 @@
+/*
+ * FILE NAME
+ *	include/asm-mips/vr41xx/tb0229.h
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Include file for TANBAC TB0229 and TB0219.
+ *
+ * Copyright 2002,2003 Yoichi Yuasa
+ *                yuasa@hh.iij4u.or.jp
+ *
+ * Modified for TANBAC TB0229:
+ * Copyright 2003 Megasolution Inc.
+ *                matsu@megasolution.jp
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+#ifndef __TANBAC_TB0229_H
+#define __TANBAC_TB0229_H
+
+#include <asm/addrspace.h>
+#include <asm/vr41xx/vr41xx.h>
+
+/*
+ * Board specific address mapping
+ */
+#define VR41XX_PCI_MEM1_BASE		0x10000000
+#define VR41XX_PCI_MEM1_SIZE		0x04000000
+#define VR41XX_PCI_MEM1_MASK		0x7c000000
+
+#define VR41XX_PCI_MEM2_BASE		0x14000000
+#define VR41XX_PCI_MEM2_SIZE		0x02000000
+#define VR41XX_PCI_MEM2_MASK		0x7e000000
+
+#define VR41XX_PCI_IO_BASE		0x16000000
+#define VR41XX_PCI_IO_SIZE		0x02000000
+#define VR41XX_PCI_IO_MASK		0x7e000000
+
+#define VR41XX_PCI_IO_START		0x01000000
+#define VR41XX_PCI_IO_END		0x01ffffff
+
+#define VR41XX_PCI_MEM_START		0x12000000
+#define VR41XX_PCI_MEM_END		0x15ffffff
+
+#define IO_PORT_BASE			KSEG1ADDR(VR41XX_PCI_IO_BASE)
+#define IO_PORT_RESOURCE_START		0
+#define IO_PORT_RESOURCE_END		VR41XX_PCI_IO_SIZE
+#define IO_MEM1_RESOURCE_START		VR41XX_PCI_MEM1_BASE
+#define IO_MEM1_RESOURCE_END		(VR41XX_PCI_MEM1_BASE + VR41XX_PCI_MEM1_SIZE)
+#define IO_MEM2_RESOURCE_START		VR41XX_PCI_MEM2_BASE
+#define IO_MEM2_RESOURCE_END		(VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE)
+
+/*
+ * General-Purpose I/O Pin Number
+ */
+#define TB0219_PCI_SLOT1_PIN		2
+#define TB0219_PCI_SLOT2_PIN		3
+#define TB0219_PCI_SLOT3_PIN		4
+
+/*
+ * Interrupt Number
+ */
+#define TB0219_PCI_SLOT1_IRQ		GIU_IRQ(TB0219_PCI_SLOT1_PIN)
+#define TB0219_PCI_SLOT2_IRQ		GIU_IRQ(TB0219_PCI_SLOT2_PIN)
+#define TB0219_PCI_SLOT3_IRQ		GIU_IRQ(TB0219_PCI_SLOT3_PIN)
+
+#define TB0219_RESET_REGS		KSEG1ADDR(0x0a00000e)
+
+extern void tanbac_tb0229_restart(char *command);
+
+#endif /* __TANBAC_TB0229_H */


--Multipart_Tue__20_May_2003_22:41:45_+0900_08458450--

From agx@sigxcpu.org Tue May 20 14:58:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 May 2003 14:58:51 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:61121
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225196AbTETN6r>; Tue, 20 May 2003 14:58:47 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 7AD9C2BC3E
	for <linux-mips@linux-mips.org>; Tue, 20 May 2003 15:58:33 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 00984-08
 for <linux-mips@linux-mips.org>; Tue, 20 May 2003 15:58:32 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 515F42BC36
	for <linux-mips@linux-mips.org>; Tue, 20 May 2003 15:58:32 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 179C91737F; Tue, 20 May 2003 15:54:42 +0200 (CEST)
Date: Tue, 20 May 2003 15:54:42 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: cvs glibc bug?
Message-ID: <20030520135441.GI11034@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <200305162333.34877.benmen@gmx.de> <20030516215147.GT8833@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030516215147.GT8833@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.3i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2417
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Fri, May 16, 2003 at 11:51:47PM +0200, Thiemo Seufer wrote:
> SI_TKILL is new in glibc and not yet ported to mips.
Well, the kernel's include/asm-mips/siginfo.h defines SI_KILL as -6
while glibc defines SI_ASYNCNL as -6. Is there a reason for this or is
this just a typo, all other architectures define the later as -60. If
it's a typo i'd like to keep this in sync with other architectures:
 
Index: sysdeps/unix/sysv/linux/mips/bits/siginfo.h
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/mips/bits/siginfo.h,v
retrieving revision 1.9
diff -u -p -u -r1.9 siginfo.h
--- sysdeps/unix/sysv/linux/mips/bits/siginfo.h	5 Dec 2002 00:23:59 -0000	1.9
+++ sysdeps/unix/sysv/linux/mips/bits/siginfo.h	20 May 2003 12:57:08 -0000
@@ -119,8 +119,10 @@ typedef struct siginfo
    signals.  */
 enum
 {
-  SI_ASYNCNL = -6,		/* Sent by asynch name lookup completion.  */
+  SI_ASYNCNL = -60,		/* Sent by asynch name lookup completion.  */
 # define SI_ASYNCNL	SI_ASYNCNL
+  SI_TKILL = -6,		/* Sent by tkill. */
+# define SI_TKILL	SI_TKILL
   SI_SIGIO,			/* Sent by queued SIGIO. */
 # define SI_SIGIO	SI_SIGIO
   SI_MESGQ,			/* Sent by real time mesq state change.  */

Regards,
 -- Guido

From yaelgilad@myrealbox.com Tue May 20 19:32:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 May 2003 19:32:38 +0100 (BST)
Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:30765
	"EHLO smtp-send.myrealbox.com") by linux-mips.org with ESMTP
	id <S8225196AbTETScd> convert rfc822-to-8bit; Tue, 20 May 2003 19:32:33 +0100
Received: from yaelgilad [81.218.93.123] by myrealbox.com
	with NetMail ModWeb Module; Tue, 20 May 2003 18:32:31 +0000
Subject: lwl-lwr
From: "Gilad Benjamini" <yaelgilad@myrealbox.com>
To: linux-mips@linux-mips.org
Date: Tue, 20 May 2003 18:32:31 +0000
X-Mailer: NetMail ModWeb Module
X-Sender: yaelgilad
MIME-Version: 1.0
Message-ID: <1053455551.996c4860yaelgilad@myrealbox.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Return-Path: <yaelgilad@myrealbox.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2418
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yaelgilad@myrealbox.com
Precedence: bulk
X-list: linux-mips

Hi,
About two months ago there was a discussion
here about disabling lwl-lwr.

Can someone shed some light on why the discussion
emerged ?

Is this a performance issue, a processor which 
doesn't support it, or something else ?

If this is a performance issue, I'll be happy
to hear more details.

TIA



From wjhun@cisco.com Tue May 20 19:51:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 May 2003 19:51:15 +0100 (BST)
Received: from sj-core-1.cisco.com ([IPv6:::ffff:171.71.177.237]:14481 "EHLO
	sj-core-1.cisco.com") by linux-mips.org with ESMTP
	id <S8225196AbTETSvD>; Tue, 20 May 2003 19:51:03 +0100
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4KIoseS029085;
	Tue, 20 May 2003 11:50:54 -0700 (PDT)
Received: from wjhun-lnx2.cisco.com (wjhun-lnx2.cisco.com [128.107.165.34])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AEI23749;
	Tue, 20 May 2003 11:50:53 -0700 (PDT)
Received: from wjhun by wjhun-lnx2.cisco.com with local (Exim 3.36 #1 (Debian))
	id 19IBwa-0004bq-00; Tue, 20 May 2003 11:34:36 -0700
Date: Tue, 20 May 2003 11:34:36 -0700
To: Gilad Benjamini <yaelgilad@myrealbox.com>
Cc: linux-mips@linux-mips.org
Subject: Re: lwl-lwr
Message-ID: <20030520183436.GJ726@cisco.com>
References: <1053455551.996c4860yaelgilad@myrealbox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1053455551.996c4860yaelgilad@myrealbox.com>
User-Agent: Mutt/1.5.3i
From: Will Jhun <wjhun@cisco.com>
Return-Path: <wjhun@cisco.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2419
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wjhun@cisco.com
Precedence: bulk
X-list: linux-mips

Some free or "MIPS-like" CPUs don't implement it because of a patent
problem. I've seen at least one implementation on opencores.org that has
this (missing) feature.

Probably if the compiler were to emit lwl and lwr code via
__attribute__((packed)), these instructions would have to be emulated by
the kernel on such a CPU. I imagine this would be quite a bit worse than
just doing two normal loads and extracting the desired word.

Will

On Tue, May 20, 2003 at 06:32:31PM +0000, Gilad Benjamini wrote:
> Hi,
> About two months ago there was a discussion
> here about disabling lwl-lwr.
> 
> Can someone shed some light on why the discussion
> emerged ?
> 
> Is this a performance issue, a processor which 
> doesn't support it, or something else ?
> 
> If this is a performance issue, I'll be happy
> to hear more details.
> 
> TIA
> 
> 
> 

From kevink@mips.com Tue May 20 19:58:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 May 2003 19:58:59 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:15809 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225196AbTETS65>;
	Tue, 20 May 2003 19:58:57 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h4KIwkUe016036
	for <linux-mips@linux-mips.org>; Tue, 20 May 2003 11:58:46 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id LAA10655;
	Tue, 20 May 2003 11:58:45 -0700 (PDT)
Message-ID: <025401c31f03$0e993370$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Gilad Benjamini" <yaelgilad@myrealbox.com>,
	<linux-mips@linux-mips.org>
References: <1053455551.996c4860yaelgilad@myrealbox.com>
Subject: Re: lwl-lwr
Date: Tue, 20 May 2003 21:07:26 +0200
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 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2420
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips

> About two months ago there was a discussion
> here about disabling lwl-lwr.
> 
> Can someone shed some light on why the discussion
> emerged ?
> 
> Is this a performance issue, a processor which 
> doesn't support it, or something else ?
> 
> If this is a performance issue, I'll be happy
> to hear more details.

I don't remember the discussion in question, but it's a question
which comes up from time to time, due to the existence of 
MIPS-like CPUs which lack the (patented) lwl/lwr mechanism
for dealing with unaligned data.  The Lexra cores, for example.

There's really no such thing as "disabling" lwl/lwr.  They are part 
of the base MIPS instruction set.  If one wants to live without them, 
one can either rig a compiler to emit multi-instruction sequences instead 
of lwr/lwl to do the appropriate shifts and masks (which is slower on all 
targets), or you can rig the OS to emulate them, and hope that the processors 
lacking support will take clean reserved instruction traps, where the function 
can be emulated (which is "free" for code running  on CPUs with lwl/lwr, 
but *really* slow for the guys doing emulation).

            Kevin K.

From ppopov@mvista.com Tue May 20 23:09:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 May 2003 23:09:10 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:7418 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225196AbTETWJI>;
	Tue, 20 May 2003 23:09:08 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA29645
	for <linux-mips@linux-mips.org>; Tue, 20 May 2003 15:09:05 -0700
Subject: Au1x zboot
From: Pete Popov <ppopov@mvista.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1053468620.28562.144.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 20 May 2003 15:10:20 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2421
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips


I know someone was recently asking for this.  I put a zImage patch on my
directory (/pub/linux/mips/people/ppopov) called zboot_patch for the
Alchemy boards. The code was ported from PPC sometime ago so it's pretty
generic and I think it's pretty easy to add support for other boards.
The bits were just updated by Embedded Edge so I uploaded the patch and
also sent it to Ralf.  There are two new targets, one for a zImage you
load to RAM and run; the other for an image you store in flash.  The
README has some details and example uses.

Pete


From ralf@linux-mips.org Wed May 21 01:34:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 May 2003 01:34:51 +0100 (BST)
Received: (from localhost user: 'ralf' uid#501 fake: STDIN
	(ralf@sirjeppe-pt.tunnel.tserv1.fmt.ipv6.he.net)) by linux-mips.org
	id <S8225196AbTEUAet>; Wed, 21 May 2003 01:34:49 +0100
Date: Wed, 21 May 2003 01:34:49 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org
Subject: Re: lwl-lwr
Message-ID: <20030521013449.A16378@linux-mips.org>
References: <1053455551.996c4860yaelgilad@myrealbox.com> <025401c31f03$0e993370$10eca8c0@grendel>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <025401c31f03$0e993370$10eca8c0@grendel>; from kevink@mips.com on Tue, May 20, 2003 at 09:07:26PM +0200
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: 2422
X-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, May 20, 2003 at 09:07:26PM +0200, Kevin D. Kissell wrote:

> I don't remember the discussion in question, but it's a question
> which comes up from time to time, due to the existence of 
> MIPS-like CPUs which lack the (patented) lwl/lwr mechanism
> for dealing with unaligned data.  The Lexra cores, for example.
> 
> There's really no such thing as "disabling" lwl/lwr.  They are part 
> of the base MIPS instruction set.  If one wants to live without them, 
> one can either rig a compiler to emit multi-instruction sequences instead 
> of lwr/lwl to do the appropriate shifts and masks (which is slower on all 
> targets), or you can rig the OS to emulate them, and hope that the processors 
> lacking support will take clean reserved instruction traps, where the function 
> can be emulated (which is "free" for code running  on CPUs with lwl/lwr, 
> but *really* slow for the guys doing emulation).

Technically you're right ...  In reality lwl/lwr are covered by US patent
4,814,976 which would also cover a software implementation.  So unless MIPS
grants a license for the purpose of emulation in the Linux kernel ...

  Ralf

From ppopov@mvista.com Wed May 21 02:10:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 May 2003 02:10:04 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:57071 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225232AbTEUBDv>;
	Wed, 21 May 2003 02:03:51 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA02426;
	Tue, 20 May 2003 18:03:49 -0700
Subject: Re: patch: change config options for au1x00 usb device
From: Pete Popov <ppopov@mvista.com>
To: Steve Longerbeam <stevel@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>,
	Jun Sun <jsun@mvista.com>
In-Reply-To: <3EAF17A8.8050805@mvista.com>
References: <3EAF17A8.8050805@mvista.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1053479105.1247.18.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 20 May 2003 18:05:05 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2423
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips


On Tue, 2003-04-29 at 17:24, Steve Longerbeam wrote:
> Attached patch fixes CONFIG_AU1000_USB_DEVICE, which
> had to be defined manually for each au1x00-based board in
> arch/mips/config.in. The patch defines it automatically if one of
> the au1x00 usb function drivers have been enabled.

I finally got to this patch but it doesn't look like the patch was
against the linux-mips tree, so I manually patched it.

Pete


From jsun@mvista.com Wed May 21 03:11:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 May 2003 03:11:29 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:54779 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225196AbTEUCL0>;
	Wed, 21 May 2003 03:11:26 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h4L2BOZ04265;
	Tue, 20 May 2003 19:11:24 -0700
Date: Tue, 20 May 2003 19:11:24 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: special include/asm/siginfo.h for MIPS
Message-ID: <20030520191124.N32567@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: 2424
X-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


MIPS has different values from all other arches in this file.
(such as SIGEV_NONE, etc)  Does anybody know why?

Because of this in 2.5 everybody else now goes to use the 
the generic version of siginfo, while MIPS uses its own special
version.

Even worse the new usage of SIGEV_XXX seems to suggest
sigev_notify is bitwise-or'ed flag instead of enumeration of integers.
This is in a direct conflict with current MIPS values.

Any thoughts?  Can we just use what other arches are using?

Jun

From ashish.anand@inspiretech.com Wed May 21 06:57:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 May 2003 06:58:00 +0100 (BST)
Received: from inspiration-98-179-ban.inspiretech.com ([IPv6:::ffff:203.196.179.98]:16003
	"EHLO smtp.inspirtek.com") by linux-mips.org with ESMTP
	id <S8225193AbTEUF55>; Wed, 21 May 2003 06:57:57 +0100
Received: from mail.inspiretech.com (mail.inspiretech.com [192.168.42.3])
	by smtp.inspirtek.com (8.12.5/8.12.5) with ESMTP id h4L6HqI9006634
	for <linux-mips@linux-mips.org>; Wed, 21 May 2003 11:48:04 +0530
Message-Id: <200305210618.h4L6HqI9006634@smtp.inspirtek.com>
Received: from WorldClient [192.168.42.3] by inspiretech.com [192.168.42.3]
	with SMTP (MDaemon.v3.5.7.R)
	for <linux-mips@linux-mips.org>; Wed, 21 May 2003 11:16:50 +0530
Date: Wed, 21 May 2003 11:16:49 +0530
From: "Ashish anand" <ashish.anand@inspiretech.com>
To: linux-mips@linux-mips.org
Subject: Any complications of using CONFIG_MIPS_UNCACHED..?
X-Mailer: WorldClient Standard 3.5.0e
X-MDRemoteIP: 192.168.42.3
X-Return-Path: ashish.anand@inspiretech.com
X-MDaemon-Deliver-To: linux-mips@linux-mips.org
Return-Path: <ashish.anand@inspiretech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2425
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish.anand@inspiretech.com
Precedence: bulk
X-list: linux-mips

Hello,

I saw a good bit of discussion about CONFIG_MIPS_UNCACHED but
still i am yet to know...

If I want to use CONFIG_MIPS_UNCACHED (ignoring performance)
what all the side-effects and any restrictions that linux should
take care in software ?

I observed something surprising on my R4k mips system(virtually indexed
caches), after i use this option my driver never got status updation by
device in transmit and receive decriptors in system memory , Irrespective
of I (flushed+invalidate) caches or not...

if i don't use CONFIG_MIPS_UNCACHED then before checking status I need to 
(flush+invalidate) cache and whole thing works great...

Regards,
Ashish



From macro@ds2.pg.gda.pl Wed May 21 10:55:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 May 2003 10:55:58 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:48017 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225201AbTEUJzz>; Wed, 21 May 2003 10:55:55 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA02293;
	Wed, 21 May 2003 11:56:45 +0200 (MET DST)
Date: Wed, 21 May 2003 11:56:44 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: "Kevin D. Kissell" <kevink@mips.com>,
	Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org
Subject: Re: lwl-lwr
In-Reply-To: <20030521013449.A16378@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030521115345.2088D-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2426
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 21 May 2003, Ralf Baechle wrote:

> > There's really no such thing as "disabling" lwl/lwr.  They are part 
> > of the base MIPS instruction set.  If one wants to live without them, 
> > one can either rig a compiler to emit multi-instruction sequences instead 
> > of lwr/lwl to do the appropriate shifts and masks (which is slower on all 
> > targets), or you can rig the OS to emulate them, and hope that the processors 
> > lacking support will take clean reserved instruction traps, where the function 
> > can be emulated (which is "free" for code running  on CPUs with lwl/lwr, 
> > but *really* slow for the guys doing emulation).
> 
> Technically you're right ...  In reality lwl/lwr are covered by US patent
> 4,814,976 which would also cover a software implementation.  So unless MIPS
> grants a license for the purpose of emulation in the Linux kernel ...

 For practical reasons I believe it can be dealt with without patent
infringing, but I am not that excited with doing anything at all about it. 

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


From kevink@mips.com Wed May 21 14:32:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 May 2003 14:32:34 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:912 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225193AbTEUNcC>;
	Wed, 21 May 2003 14:32:02 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h4LDViUe026721;
	Wed, 21 May 2003 06:31:44 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA24448;
	Wed, 21 May 2003 06:31:42 -0700 (PDT)
Message-ID: <007a01c31f9e$8a784ee0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	"Ralf Baechle" <ralf@linux-mips.org>
Cc: "Gilad Benjamini" <yaelgilad@myrealbox.com>,
	<linux-mips@linux-mips.org>
References: <Pine.GSO.3.96.1030521115345.2088D-100000@delta.ds2.pg.gda.pl>
Subject: Re: lwl-lwr
Date: Wed, 21 May 2003 15:40:25 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2427
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips

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

> On Wed, 21 May 2003, Ralf Baechle wrote:
> 
> > > There's really no such thing as "disabling" lwl/lwr.  They are part 
> > > of the base MIPS instruction set.  If one wants to live without them, 
> > > one can either rig a compiler to emit multi-instruction sequences instead 
> > > of lwr/lwl to do the appropriate shifts and masks (which is slower on all 
> > > targets), or you can rig the OS to emulate them, and hope that the processors 
> > > lacking support will take clean reserved instruction traps, where the function 
> > > can be emulated (which is "free" for code running  on CPUs with lwl/lwr, 
> > > but *really* slow for the guys doing emulation).
> > 
> > Technically you're right ...  In reality lwl/lwr are covered by US patent
> > 4,814,976 which would also cover a software implementation.  So unless MIPS
> > grants a license for the purpose of emulation in the Linux kernel ...
> 
>  For practical reasons I believe it can be dealt with without patent
> infringing, but I am not that excited with doing anything at all about it. 

I agree.  I've never read the patent, but now that you mention it, I do
recall having heard that it covers software implementations.  Lets just
leave this one alone...

            Kevin K.

From alan@lxorguk.ukuu.org.uk Wed May 21 14:47:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 May 2003 14:48:01 +0100 (BST)
Received: from pc2-cwma1-4-cust86.swan.cable.ntl.com ([IPv6:::ffff:213.105.254.86]:60861
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8225193AbTEUNr7>; Wed, 21 May 2003 14:47:59 +0100
Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.8/8.12.5) with ESMTP id h4LCnnRQ000966;
	Wed, 21 May 2003 13:49:50 +0100
Received: (from alan@localhost)
	by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h4LCnjTk000964;
	Wed, 21 May 2003 13:49:46 +0100
X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: lwl-lwr
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Kevin D. Kissell" <kevink@mips.com>,
	Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org
In-Reply-To: <20030521013449.A16378@linux-mips.org>
References: <1053455551.996c4860yaelgilad@myrealbox.com>
	 <025401c31f03$0e993370$10eca8c0@grendel>
	 <20030521013449.A16378@linux-mips.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1053521383.32700.21.camel@dhcp22.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 21 May 2003 13:49:45 +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: 2428
X-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 Mer, 2003-05-21 at 01:34, Ralf Baechle wrote:
> > of the base MIPS instruction set.  If one wants to live without them, 
> > one can either rig a compiler to emit multi-instruction sequences instead 
> > of lwr/lwl to do the appropriate shifts and masks (which is slower on all 

This would seem the sane approach. 

> Technically you're right ...  In reality lwl/lwr are covered by US patent
> 4,814,976 which would also cover a software implementation.  So unless MIPS
> grants a license for the purpose of emulation in the Linux kernel ...

They would need to grant a license for general GPL use, the GPL itself
does not intend to allow other restrictions that would make the code non
free. There are a billion examples of prior art for software fixing up
of exceptions and software emulation of alignment fixups however.

Maybe MIPS can clarify their position officially.


From bdempsey@transfinity.com Wed May 21 22:50:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 May 2003 22:51:26 +0100 (BST)
Received: from ws1.transfinity.com ([IPv6:::ffff:63.99.219.193]:15014 "EHLO
	ws1.transfinity.com") by linux-mips.org with ESMTP
	id <S8225205AbTEUVuy>; Wed, 21 May 2003 22:50:54 +0100
Received: from transfinity.com (adsl-216-61-82-33.dsl.rcsntx.swbell.net [216.61.82.33])
	by ws1.transfinity.com (Postfix) with ESMTP id 197F0681A1
	for <linux-mips@linux-mips.org>; Wed, 21 May 2003 16:50:53 -0500 (CDT)
Message-ID: <3ECBF4BC.24E5FFE6@transfinity.com>
Date: Wed, 21 May 2003 16:50:52 -0500
From: Bob Dempsey <bdempsey@transfinity.com>
X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.18-27.7.x i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Cobalt RAQ 2 woes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <bdempsey@transfinity.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2429
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bdempsey@transfinity.com
Precedence: bulk
X-list: linux-mips

Okay, I've been trying on and off for weeks now to get ANY 2.4 kernel to run on my Cobalt RAQ 2 recently aquired on EBay for $250. It runs Cobalt's 2.0 kernel just fine, and I've managed to upgrade gcc and binutils to 2.95.4 and 2.13.2.1 respectively. I can build the 2.5.47 kernel out of cvs cleanly, but when it boots I get swap errors like:

swap_dup: Bad swap file entry 4081004e

over and over and over.

The latest 2.4 kernel source from cvs also compiles cleanly, but just hangs.

Both of these kernels die in the execve() call at the end of init/main.c.

My debugging has lead me to believe there is some problem with the tlb, but I could certainly be wrong. Any suggestions?

--
------------------------------------------------------------------------
Bob Dempsey                                     972-866-9199x104(V)
Vice President R&D                              972-866-0179(F)
Transfinity Corp                                bdempsey@transfinity.com
4851 LBJ Freeway                                Dallas, TX 75244




From Geert.Uytterhoeven@sonycom.com Fri May 23 14:47:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 14:47:55 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:28670 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTEWNrw>;
	Fri, 23 May 2003 14:47:52 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h4NDlOLT005469;
	Fri, 23 May 2003 15:47:34 +0200 (MEST)
Date: Fri, 23 May 2003 15:47:29 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: [PATCH] Arrow keys on USB keyboards
Message-ID: <Pine.GSO.4.21.0305231545030.26586-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2430
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

	Hi Ralf,

This patch fixes the arrow keys (and all other keys that generate E0/E1
scancode prefixes on AT keyboards) by adding support for E0/E1 scancode
prefixes to the dummy keyboard driver if CONFIG_INPUT=y.

Rationale: When using the new input layer (i.e. with a USB keyboard or a custom
input device), the input layer relies on kbd_translate() in the low-level
keyboard driver to convert from AT-style scancodes to keycodes. If you don't
have a PS/2 keyboard interface and don't compile in the PS/2 keyboard driver,
you have to enable the dummy keyboard driver, which naively assumes that
keycodes and scancodes are interchangeable. This is correct if you do not have
a keyboard, but fails for prefixed scancodes if you do have a keyboard which
uses the new input layer.

--- linux-mips-2.4.x/drivers/char/dummy_keyb.c	Tue Apr  1 16:33:31 2003
+++ linux/drivers/char/dummy_keyb.c	Wed Apr 30 08:12:19 2003
@@ -23,9 +23,12 @@
  * CONFIG_VT.
  *
  */
+
+#include <linux/config.h>
 #include <linux/sched.h>
 #include <linux/errno.h>
 #include <linux/init.h>
+#include <linux/input.h>
 
 void kbd_leds(unsigned char leds)
 {
@@ -41,6 +44,84 @@
 	return scancode;
 }
 
+#ifdef CONFIG_INPUT
+static unsigned char e0_keys[128] = {
+	0, 0, 0, KEY_KPCOMMA, 0, KEY_INTL3, 0, 0,		/* 0x00-0x07 */
+	0, 0, 0, 0, KEY_LANG1, KEY_LANG2, 0, 0,			/* 0x08-0x0f */
+	0, 0, 0, 0, 0, 0, 0, 0,					/* 0x10-0x17 */
+	0, 0, 0, 0, KEY_KPENTER, KEY_RIGHTCTRL, KEY_VOLUMEUP, 0,/* 0x18-0x1f */
+	0, 0, 0, 0, 0, KEY_VOLUMEDOWN, KEY_MUTE, 0,		/* 0x20-0x27 */
+	0, 0, 0, 0, 0, 0, 0, 0,					/* 0x28-0x2f */
+	0, 0, 0, 0, 0, KEY_KPSLASH, 0, KEY_SYSRQ,		/* 0x30-0x37 */
+	KEY_RIGHTALT, KEY_BRIGHTNESSUP, KEY_BRIGHTNESSDOWN, 
+		KEY_EJECTCD, 0, 0, 0, 0,			/* 0x38-0x3f */
+	0, 0, 0, 0, 0, 0, 0, KEY_HOME,				/* 0x40-0x47 */
+	KEY_UP, KEY_PAGEUP, 0, KEY_LEFT, 0, KEY_RIGHT, 0, KEY_END, /* 0x48-0x4f */
+	KEY_DOWN, KEY_PAGEDOWN, KEY_INSERT, KEY_DELETE, 0, 0, 0, 0, /* 0x50-0x57 */
+	0, 0, 0, KEY_LEFTMETA, KEY_RIGHTMETA, KEY_COMPOSE, KEY_POWER, 0, /* 0x58-0x5f */
+	0, 0, 0, 0, 0, 0, 0, 0,					/* 0x60-0x67 */
+	0, 0, 0, 0, 0, 0, 0, KEY_MACRO,				/* 0x68-0x6f */
+	0, 0, 0, 0, 0, 0, 0, 0,					/* 0x70-0x77 */
+	0, 0, 0, 0, 0, 0, 0, 0					/* 0x78-0x7f */
+};
+
+int kbd_translate(unsigned char scancode, unsigned char *keycode,
+	char raw_mode)
+{
+	/* This code was copied from char/pc_keyb.c and will be
+	 * superflous when the input layer is fully integrated.
+	 * We don't need the high_keys handling, so this part
+	 * has been removed.
+	 */
+	static int prev_scancode = 0;
+
+	/* special prefix scancodes.. */
+	if (scancode == 0xe0 || scancode == 0xe1) {
+		prev_scancode = scancode;
+		return 0;
+	}
+
+	scancode &= 0x7f;
+
+	if (prev_scancode) {
+		if (prev_scancode != 0xe0) {
+			if (prev_scancode == 0xe1 && scancode == 0x1d) {
+				prev_scancode = 0x100;
+				return 0;
+			} else if (prev_scancode == 0x100 && scancode == 0x45) {
+				*keycode = KEY_PAUSE;
+				prev_scancode = 0;
+			} else {
+				if (!raw_mode)
+					printk(KERN_INFO "keyboard: unknown e1 escape sequence\n");
+				prev_scancode = 0;
+				return 0;
+			}
+		} else {
+			prev_scancode = 0;
+			if (scancode == 0x2a || scancode == 0x36)
+				return 0;
+		}
+		if (e0_keys[scancode])
+			*keycode = e0_keys[scancode];
+		else {
+			if (!raw_mode)
+				printk(KERN_INFO "keyboard: unknown scancode e0 %02x\n",
+				       scancode);
+			return 0;
+		}
+	} else {
+		switch (scancode) {
+		case  91: scancode = KEY_LINEFEED; break;
+		case  92: scancode = KEY_KPEQUAL; break;
+		case 125: scancode = KEY_INTL1; break;
+		}
+		*keycode = scancode;
+	}
+	return 1;
+}
+
+#else
 int kbd_translate(unsigned char scancode, unsigned char *keycode,
 	char raw_mode)
 {
@@ -48,6 +129,7 @@
 
 	return 1;
 }
+#endif
 
 char kbd_unexpected_up(unsigned char keycode)
 {

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 Geert.Uytterhoeven@sonycom.com Fri May 23 14:51:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 14:51:14 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:64129 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTEWNvL>;
	Fri, 23 May 2003 14:51:11 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h4NDotLT005864;
	Fri, 23 May 2003 15:50:56 +0200 (MEST)
Date: Fri, 23 May 2003 15:51:00 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: [PATCH] pci_alloc_consistent() crash
Message-ID: <Pine.GSO.4.21.0305231549510.26586-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2431
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

	Hi Ralf,

Avoid a NULL-pointer dereference when using pci_alloc_consistent() for PCI-like
buses (i.e. hwdev = NULL).

--- linux-mips-2.4.x/arch/mips/kernel/pci-dma.c	Tue Apr  1 16:21:18 2003
+++ linux/arch/mips/kernel/pci-dma.c	Thu May 15 18:17:35 2003
@@ -21,6 +21,7 @@
 {
 	void *ret;
 	int gfp = GFP_ATOMIC;
+	struct pci_bus *bus = NULL;
 
 #ifdef CONFIG_ISA
 	if (hwdev == NULL || hwdev->dma_mask != 0xffffffff)
@@ -30,7 +31,9 @@
 
 	if (ret != NULL) {
 		memset(ret, 0, size);
-		*dma_handle = bus_to_baddr(hwdev->bus, __pa(ret));
+		if (hwdev)
+			bus = hwdev->bus;
+		*dma_handle = bus_to_baddr(bus, __pa(ret));
 #ifdef CONFIG_NONCOHERENT_IO
 		dma_cache_wback_inv((unsigned long) ret, size);
 		ret = UNCAC_ADDR(ret);

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 Geert.Uytterhoeven@sonycom.com Fri May 23 14:52:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 14:52:57 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:11651 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTEWNwz>;
	Fri, 23 May 2003 14:52:55 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h4NDqeLT006028;
	Fri, 23 May 2003 15:52:41 +0200 (MEST)
Date: Fri, 23 May 2003 15:52:45 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: [PATCH] Embedded ramdisks
Message-ID: <Pine.GSO.4.21.0305231551110.26586-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2432
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

	Hi Ralf,

Fix the dependency for embedded ramdisks by using the contents of
CONFIG_EMBEDDED_RAMDISK_IMAGE (after stripping the leading and trailing double
quotes) instead of using the hardcoded filename `ramdisk.gz'.

--- linux-mips-2.4.x/arch/mips/ramdisk/Makefile	Tue Apr  1 16:22:04 2003
+++ linux/arch/mips/ramdisk/Makefile	Wed Apr  2 18:31:48 2003
@@ -8,7 +8,7 @@
 
 O_FORMAT = $(shell $(OBJDUMP) -i | head -2 | grep elf32)
 img = $(CONFIG_EMBEDDED_RAMDISK_IMAGE)
-ramdisk.o: ramdisk.gz ld.script
+ramdisk.o: $(subst ",,$(img)) ld.script
 	echo "O_FORMAT:  " $(O_FORMAT)
 	$(LD) -T ld.script -b binary --oformat $(O_FORMAT) -o $@ $(img)
 

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 Geert.Uytterhoeven@sonycom.com Fri May 23 14:53:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 14:54:01 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:4997 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTEWNx7>;
	Fri, 23 May 2003 14:53:59 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h4NDrjLT006185;
	Fri, 23 May 2003 15:53:45 +0200 (MEST)
Date: Fri, 23 May 2003 15:53:50 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: [PATCH] Vr41xx unaligned access update
Message-ID: <Pine.GSO.4.21.0305231553070.26586-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2433
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

	Hi Ralf,

Update fix for some (Vr41xx?) CPUs, where if an unaligned access happens in a
branch delay slot and the branch is not taken, EPC may point at the branch
instruction while the BD bit in the cause register is not set:
  - Remove tests for unconditional jumps, since they are always taken
  - Add test for a branch in a branch delay slot

--- linux-mips-2.4.x/arch/mips/kernel/unaligned.c	Mon May  5 16:23:43 2003
+++ linux/arch/mips/kernel/unaligned.c	Tue May  6 14:24:56 2003
@@ -99,6 +99,7 @@
 	union mips_instruction insn;
 	unsigned long value, fixup;
 	unsigned int res;
+	int branch = 0;
 
 	regs->regs[0] = 0;
 	*regptr=NULL;
@@ -145,8 +146,6 @@
 	 * but the BD bit in the cause register is not set.
 	 */
 	case bcond_op:
-	case j_op:
-	case jal_op:
 	case beq_op:
 	case bne_op:
 	case blez_op:
@@ -155,7 +154,11 @@
 	case bnel_op:
 	case blezl_op:
 	case bgtzl_op:
-	case jalx_op:
+		if (branch) {
+		    /* branch in a branch delay slot */
+		    goto sigill;
+		}
+		branch = 1;
 		pc += 4;
 		goto retry;
 

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 Geert.Uytterhoeven@sonycom.com Fri May 23 14:56:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 14:56:39 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:31623 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTEWN42>;
	Fri, 23 May 2003 14:56:28 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h4NDuCLT006438;
	Fri, 23 May 2003 15:56:12 +0200 (MEST)
Date: Fri, 23 May 2003 15:56:17 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: [PATCH] Kill warnings
Message-ID: <Pine.GSO.4.21.0305231554020.26586-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2434
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

	Hi Ralf,

Kill warnings:
  - Fix incorrect printf()-style format specifier
  - Move static inline get_insn_opcode() before first usage
  - Add missing cast of return value of page_address()
  - Refactor probe_tlb() to avoid unused variables on non-MIPS32/64 CPUs

--- linux-mips-2.4.x/arch/mips/kernel/setup.c	Mon May  5 16:23:41 2003
+++ linux/arch/mips/kernel/setup.c	Wed May  7 11:48:49 2003
@@ -396,7 +396,7 @@
 		       initrd_size);
 		if (PHYSADDR(initrd_end) > PFN_PHYS(max_low_pfn)) {
 			printk("initrd extends beyond end of memory "
-			       "(0x%08lx > 0x%08lx)\ndisabling initrd\n",
+			       "(0x%08x > 0x%08lx)\ndisabling initrd\n",
 			       PHYSADDR(initrd_end),
 			       PFN_PHYS(max_low_pfn));
 			initrd_start = initrd_end = 0;
--- linux-mips-2.4.x/arch/mips/kernel/traps.c	Mon May  5 16:23:42 2003
+++ linux/arch/mips/kernel/traps.c	Wed May  7 11:48:58 2003
@@ -488,6 +488,19 @@
 	force_sig(signal, current);
 }
 
+static inline int get_insn_opcode(struct pt_regs *regs, unsigned int *opcode)
+{
+	unsigned int *epc;
+
+	epc = (unsigned int *) regs->cp0_epc +
+	      ((regs->cp0_cause & CAUSEF_BD) != 0);
+	if (!get_user(*opcode, epc))
+		return 0;
+
+	force_sig(SIGSEGV, current);
+	return 1;
+}
+
 /*
  * ll uses the opcode of lwc0 and sc uses the opcode of swc0.  That is both
  * opcodes are supposed to result in coprocessor unusable exceptions if
@@ -564,19 +577,6 @@
 	}
 
 	force_sig(SIGFPE, current);
-}
-
-static inline int get_insn_opcode(struct pt_regs *regs, unsigned int *opcode)
-{
-	unsigned int *epc;
-
-	epc = (unsigned int *) regs->cp0_epc +
-	      ((regs->cp0_cause & CAUSEF_BD) != 0);
-	if (!get_user(*opcode, epc))
-		return 0;
-
-	force_sig(SIGSEGV, current);
-	return 1;
 }
 
 asmlinkage void do_bp(struct pt_regs *regs)
--- linux-mips-2.4.x/arch/mips/mm/cache.c	Mon May  5 16:30:45 2003
+++ linux/arch/mips/mm/cache.c	Wed May  7 11:49:15 2003
@@ -54,10 +54,9 @@
 	page = pte_page(pte);
 	if (VALID_PAGE(page) && page->mapping &&
 	    (page->flags & (1UL << PG_dcache_dirty))) {
-		if (pages_do_alias(page_address(page), address & PAGE_MASK)) {
-			addr = (unsigned long) page_address(page);
+		addr = (unsigned long)page_address(page);
+		if (pages_do_alias(addr, address & PAGE_MASK))
 			flush_data_cache_page(addr);
-		}
 
 		ClearPageDcacheDirty(page);
 	}
--- linux-mips-2.4.x/arch/mips/mm/tlb-r4k.c	Mon May  5 16:23:58 2003
+++ linux/arch/mips/mm/tlb-r4k.c	Wed May  7 11:49:27 2003
@@ -339,24 +339,24 @@
 
 static void __init probe_tlb(unsigned long config)
 {
+#if defined(CONFIG_CPU_MIPS32) || defined (CONFIG_CPU_MIPS64)
 	unsigned int prid, config1;
 
 	prid = read_c0_prid() & 0xff00;
-	if (prid == PRID_IMP_RM7000 || !(config & (1 << 31)))
-		/*
-		 * Not a MIPS32 complianant CPU.  Config 1 register not
-		 * supported, we assume R4k style.  Cpu probing already figured
-		 * out the number of tlb entries.
-		 */
+	if (prid != PRID_IMP_RM7000 && (config & (1 << 31))) {
+		config1 = read_c0_config1();
+		if (!((config >> 7) & 3))
+			panic("No MMU present");
+		else
+			current_cpu_data.tlbsize = ((config1 >> 25) & 0x3f) + 1;
 		return;
-
-#if defined(CONFIG_CPU_MIPS32) || defined (CONFIG_CPU_MIPS64)
-	config1 = read_c0_config1();
-	if (!((config >> 7) & 3))
-		panic("No MMU present");
-	else
-		current_cpu_data.tlbsize = ((config1 >> 25) & 0x3f) + 1;
+	}
 #endif
+	/*
+	 * Not a MIPS32 compliant CPU.  Config 1 register not
+	 * supported, we assume R4k style.  Cpu probing already figured
+	 * out the number of tlb entries.
+	 */
 }
 
 void __init r4k_tlb_init(void)

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 macro@ds2.pg.gda.pl Fri May 23 15:05:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 15:05:31 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:45719 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTEWOF2>; Fri, 23 May 2003 15:05:28 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA17158;
	Fri, 23 May 2003 16:05:43 +0200 (MET DST)
Date: Fri, 23 May 2003 16:05:43 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Arrow keys on USB keyboards
In-Reply-To: <Pine.GSO.4.21.0305231545030.26586-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1030523155904.14542E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2435
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 23 May 2003, Geert Uytterhoeven wrote:

> This patch fixes the arrow keys (and all other keys that generate E0/E1
> scancode prefixes on AT keyboards) by adding support for E0/E1 scancode
> prefixes to the dummy keyboard driver if CONFIG_INPUT=y.
> 
> Rationale: When using the new input layer (i.e. with a USB keyboard or a custom
> input device), the input layer relies on kbd_translate() in the low-level
> keyboard driver to convert from AT-style scancodes to keycodes. If you don't
> have a PS/2 keyboard interface and don't compile in the PS/2 keyboard driver,
> you have to enable the dummy keyboard driver, which naively assumes that
> keycodes and scancodes are interchangeable. This is correct if you do not have
> a keyboard, but fails for prefixed scancodes if you do have a keyboard which
> uses the new input layer.

 Hmm, if the PC/AT keyboard translation is needed by other devices beside
pc_keyb.c, then why isn't the common part put into a separate file to be
used by all devices depending on this translation as needed?  I think
dummy_keyb.c should be kept plain and simple as it is now. 

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


From macro@ds2.pg.gda.pl Fri May 23 15:11:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 15:11:40 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:1176 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTEWOLi>; Fri, 23 May 2003 15:11:38 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA17254;
	Fri, 23 May 2003 16:12:20 +0200 (MET DST)
Date: Fri, 23 May 2003 16:12:20 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Vr41xx unaligned access update
In-Reply-To: <Pine.GSO.4.21.0305231553070.26586-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1030523160920.14542F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2436
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 23 May 2003, Geert Uytterhoeven wrote:

> @@ -145,8 +146,6 @@
>  	 * but the BD bit in the cause register is not set.
>  	 */
>  	case bcond_op:
> -	case j_op:
> -	case jal_op:
>  	case beq_op:
>  	case bne_op:
>  	case blez_op:
> @@ -155,7 +154,11 @@
>  	case bnel_op:
>  	case blezl_op:
>  	case bgtzl_op:
> -	case jalx_op:
> +		if (branch) {
> +		    /* branch in a branch delay slot */
> +		    goto sigill;
> +		}
> +		branch = 1;
>  		pc += 4;
>  		goto retry;

 Hmm, what tree is it against?  I can't see code matching these hunks in
our tree at linux-mips.org.

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


From Geert.Uytterhoeven@sonycom.com Fri May 23 15:15:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 15:15:31 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:11427 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTEWOP2>;
	Fri, 23 May 2003 15:15:28 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h4NEEtLT009020;
	Fri, 23 May 2003 16:14:57 +0200 (MEST)
Date: Fri, 23 May 2003 16:15:00 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Vojtech Pavlik <vojtech@suse.cz>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Arrow keys on USB keyboards
In-Reply-To: <Pine.GSO.3.96.1030523155904.14542E-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0305231609021.26586-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2437
X-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, 23 May 2003, Maciej W. Rozycki wrote:
> On Fri, 23 May 2003, Geert Uytterhoeven wrote:
> > This patch fixes the arrow keys (and all other keys that generate E0/E1
> > scancode prefixes on AT keyboards) by adding support for E0/E1 scancode
> > prefixes to the dummy keyboard driver if CONFIG_INPUT=y.
> > 
> > Rationale: When using the new input layer (i.e. with a USB keyboard or a custom
> > input device), the input layer relies on kbd_translate() in the low-level
> > keyboard driver to convert from AT-style scancodes to keycodes. If you don't
> > have a PS/2 keyboard interface and don't compile in the PS/2 keyboard driver,
> > you have to enable the dummy keyboard driver, which naively assumes that
> > keycodes and scancodes are interchangeable. This is correct if you do not have
> > a keyboard, but fails for prefixed scancodes if you do have a keyboard which
> > uses the new input layer.
> 
>  Hmm, if the PC/AT keyboard translation is needed by other devices beside
> pc_keyb.c, then why isn't the common part put into a separate file to be
> used by all devices depending on this translation as needed?  I think
> dummy_keyb.c should be kept plain and simple as it is now. 

In 2.5.x it's (probably) that way. In 2.4.x the input layer is more like a hack
to get USB working. On PCs, you always compile in both PS/2 keyboard and USB
keyboard support, so it always works. The dummy_keyb.c is used on MIPS only.
BTW, I forgot to mention: I just copied what the PPC guys do on PowerMac, cfr.
drivers/macintosh/mac_hid.c.

But it indeed makes sense to move kbd_translate() into the input layer itself.
Vojtech, what do you think?

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 Geert.Uytterhoeven@sonycom.com Fri May 23 15:20:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 15:20:04 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:62890 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTEWOUC>;
	Fri, 23 May 2003 15:20:02 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h4NEJbLT009752;
	Fri, 23 May 2003 16:19:37 +0200 (MEST)
Date: Fri, 23 May 2003 16:19:42 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Vr41xx unaligned access update
In-Reply-To: <Pine.GSO.3.96.1030523160920.14542F-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0305231618590.26586-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2438
X-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, 23 May 2003, Maciej W. Rozycki wrote:
> On Fri, 23 May 2003, Geert Uytterhoeven wrote:
> > @@ -145,8 +146,6 @@
> >  	 * but the BD bit in the cause register is not set.
> >  	 */
> >  	case bcond_op:
> > -	case j_op:
> > -	case jal_op:
> >  	case beq_op:
> >  	case bne_op:
> >  	case blez_op:
> > @@ -155,7 +154,11 @@
> >  	case bnel_op:
> >  	case blezl_op:
> >  	case bgtzl_op:
> > -	case jalx_op:
> > +		if (branch) {
> > +		    /* branch in a branch delay slot */
> > +		    goto sigill;
> > +		}
> > +		branch = 1;
> >  		pc += 4;
> >  		goto retry;
> 
>  Hmm, what tree is it against?  I can't see code matching these hunks in
> our tree at linux-mips.org.

Check out the 2.4.x branch. I did verify that all patches apply.

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 macro@ds2.pg.gda.pl Fri May 23 15:59:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 15:59:03 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:64153 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224861AbTEWO7A>; Fri, 23 May 2003 15:59:00 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA17834;
	Fri, 23 May 2003 16:59:43 +0200 (MET DST)
Date: Fri, 23 May 2003 16:59:43 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Vr41xx unaligned access update
In-Reply-To: <Pine.GSO.4.21.0305231618590.26586-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1030523165223.14542I-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2439
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 23 May 2003, Geert Uytterhoeven wrote:

> >  Hmm, what tree is it against?  I can't see code matching these hunks in
> > our tree at linux-mips.org.
> 
> Check out the 2.4.x branch. I did verify that all patches apply.

 Being much surprised I've double checked this before replying, both a
nightly snapshot at my local system here and directly at
ftp.linux-mips.org.  I'm using a branch tagged as "linux_2_4".  AFAIK, it
is *the* 2.4 branch.  And AFAIK, it is the only branch that is actively
maintained these days.

 Also I recall the discussion on the BD issue on these chips once, but I
can't recall any results of it going into the CVS. 

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


From Geert.Uytterhoeven@sonycom.com Fri May 23 16:14:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 16:14:52 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:38029 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTEWPOu>;
	Fri, 23 May 2003 16:14:50 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h4NFEaLT018919;
	Fri, 23 May 2003 17:14:36 +0200 (MEST)
Date: Fri, 23 May 2003 17:14:40 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Vr41xx unaligned access update
In-Reply-To: <Pine.GSO.3.96.1030523165223.14542I-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0305231713540.26586-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2440
X-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, 23 May 2003, Maciej W. Rozycki wrote:
> On Fri, 23 May 2003, Geert Uytterhoeven wrote:
> > >  Hmm, what tree is it against?  I can't see code matching these hunks in
> > > our tree at linux-mips.org.
> > 
> > Check out the 2.4.x branch. I did verify that all patches apply.
> 
>  Being much surprised I've double checked this before replying, both a
> nightly snapshot at my local system here and directly at
> ftp.linux-mips.org.  I'm using a branch tagged as "linux_2_4".  AFAIK, it
> is *the* 2.4 branch.  And AFAIK, it is the only branch that is actively
> maintained these days.
> 
>  Also I recall the discussion on the BD issue on these chips once, but I
> can't recall any results of it going into the CVS. 

Sorry, my fault. My `clean' Linux/MIPS CVS tree wasn't as clean as I thought.
So please ignore.

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 hjl@lucon.org Fri May 23 19:54:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 19:54:07 +0100 (BST)
Received: from sccrmhc01.attbi.com ([IPv6:::ffff:204.127.202.61]:50672 "EHLO
	sccrmhc01.attbi.com") by linux-mips.org with ESMTP
	id <S8225259AbTEWSyE>; Fri, 23 May 2003 19:54:04 +0100
Received: from lucon.org (12-234-88-5.client.attbi.com[12.234.88.5])
          by attbi.com (sccrmhc01) with ESMTP
          id <2003052318534600100rv1dde>; Fri, 23 May 2003 18:53:46 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 2593D2C683; Fri, 23 May 2003 11:53:39 -0700 (PDT)
Date: Fri, 23 May 2003 11:53:39 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org,
	GNU C Library <libc-alpha@sources.redhat.com>,
	Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ron Guilmette <rfg@monkeys.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	"Steven J. Hill" <sjhill@cotw.com>
Subject: The Linux binutils 2.14.90.0.3 is released
Message-ID: <20030523115339.A4699@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.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: 2441
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hjl@lucon.org
Precedence: bulk
X-list: linux-mips

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

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

If you don't use

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

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

Changes from binutils 2.14.90.0.2:

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

Changes from binutils 2.14.90.0.1:

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

Changes from binutils 2.13.90.0.20:

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

Changes from binutils 2.13.90.0.18:

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

Changes from binutils 2.13.90.0.16:

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

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

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

Changes from binutils 2.13.90.0.10:

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

Changes from binutils 2.13.90.0.4:

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

Changes from binutils 2.13.90.0.3:

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

Changes from binutils 2.13.90.0.2:

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

The file list:

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

There is no separate source rpm. You can do

# rpm -ta binutils-2.14.90.0.3.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
05/23/2003

From wgowcher@yahoo.com Fri May 23 22:59:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 May 2003 22:59:41 +0100 (BST)
Received: from web11901.mail.yahoo.com ([IPv6:::ffff:216.136.172.185]:61229
	"HELO web11901.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225209AbTEWV7i>; Fri, 23 May 2003 22:59:38 +0100
Message-ID: <20030523215935.71373.qmail@web11901.mail.yahoo.com>
Received: from [209.243.184.182] by web11901.mail.yahoo.com via HTTP; Fri, 23 May 2003 14:59:35 PDT
Date: Fri, 23 May 2003 14:59:35 -0700 (PDT)
From: Wayne Gowcher <wgowcher@yahoo.com>
Subject: pci_alloc_consistent usage
To: Linux-MIPS <linux-mips@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <wgowcher@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2442
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wgowcher@yahoo.com
Precedence: bulk
X-list: linux-mips

I am working on a driver that uses PCI DMA transfers
from system memory to the PCI device. On the 2.4.18
kernel it worked OK, but now when it is recompiled for
2.4.20 it doesn't. Digging into things I have found
that the function virt_to_phys() has been changed from
:
return PHYSADDR(address)

to
return (unsigned long)address - PAGE_OFFSET

Where PAGE_OFFSET is 0x8000 0000, and where PHYSADDR
would AND the address against 0x1FFF FFFF. As far as I
can tell the problem comes from pci_alloc_consistent
doing :

ret = UNCAC_ADDR(ret) 

which converts a 0x8xxx address to 0xAxxx, and then
when you pass this 0xAxxx_xxxx address through
virt_to_phys() you get an address of the form
0x2xxx_xxxx. This 0x2xxx_xxxx is passed to the dma
controller as the physical address to where it must
read / write data, and because it is 0x2xxx_xxxx and
not 0x0xxx_xxxx an exception occurs.

At first I just tried AND'ing out the 0xA.. like
PHYSADDR used to do it, but with that change i no
longer get the exception, but the driver does not dma
the data across - it just sits there.

I read DMA-mapping.txt and it says virt_to_phys() will
be phased out, and should be used, but doesn't
elaborate any further (like how you should do it now
).

So after that long intro, my question is :

Anybody know where I'm going wrong and how to fix
things ?

Also any tips on what drivers to look at for good
examples would also be appreciated.

TIA


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

From hadi@shell.cyberus.ca Sun May 25 05:19:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 May 2003 05:19:31 +0100 (BST)
Received: from shell.cyberus.ca ([IPv6:::ffff:216.191.236.4]:32264 "EHLO
	shell.cyberus.ca") by linux-mips.org with ESMTP id <S8225072AbTEYETW>;
	Sun, 25 May 2003 05:19:22 +0100
Received: from hadi (helo=localhost)
	by shell.cyberus.ca with local-esmtp (Exim 4.14)
	id 19JmyJ-000EFN-VO
	for linux-mips@linux-mips.org; Sun, 25 May 2003 00:18:59 -0400
Date: Sun, 25 May 2003 00:18:59 -0400 (EDT)
From: Jamal Hadi <hadi@shell.cyberus.ca>
To: linux-mips@linux-mips.org
Subject: profiling SMP/SB1250
Message-ID: <20030525001222.B54761@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <hadi@shell.cyberus.ca>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2443
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hadi@shell.cyberus.ca
Precedence: bulk
X-list: linux-mips


Hi,

Newbie to MIPS here and not on the list (so cc me please).
I am playing around with a SB1250 board; it has two CPUs. Attempt to
kernel profile:
on bootup selected profile=2 to enable profiling(validated because
/proc/profile shows up). readprofile produce some strange
output after i ran a lot of interupt related stresses. The output seems
to claim the CPU was idle ... I know it was not.
The SB1250 ties all IO interupts on CPU0 - i wonder if this was causing me
some issues? Is what i am doing the right way to turn on profiling on
MIPS or the SB1250?

cheers,
jamal



From hjl@lucon.org Sun May 25 16:24:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 May 2003 16:24:44 +0100 (BST)
Received: from rwcrmhc53.attbi.com ([IPv6:::ffff:204.127.198.39]:40685 "EHLO
	rwcrmhc53.attbi.com") by linux-mips.org with ESMTP
	id <S8225072AbTEYPYl>; Sun, 25 May 2003 16:24:41 +0100
Received: from lucon.org (12-234-88-5.client.attbi.com[12.234.88.5])
          by attbi.com (rwcrmhc53) with ESMTP
          id <2003052515243305300r5fpae>; Sun, 25 May 2003 15:24:33 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id C60BB2C683; Sun, 25 May 2003 08:24:31 -0700 (PDT)
Date: Sun, 25 May 2003 08:24:31 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: Jack Howarth <howarth@bromo.msbb.uc.edu>
Cc: GNU C Library <libc-alpha@sources.redhat.com>, gcc@gcc.gnu.org,
	Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ron Guilmette <rfg@monkeys.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	"Steven J. Hill" <sjhill@cotw.com>, linux-gcc@vger.kernel.org
Subject: The Linux binutils 2.14.90.0.4 is released
Message-ID: <20030525082431.A16986@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.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: 2444
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hjl@lucon.org
Precedence: bulk
X-list: linux-mips

This release is to work around the libtool issue with libopcodes.

H.J.
From GCC summit in Ottawa.
---
This is the beta release of binutils 2.14.90.0.4 for Linux, which is
based on binutils 2003 0523 in CVS on sourecs.redhat.com plus various
changes. It is purely for Linux.

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

If you don't use

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

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

Changes from binutils 2.14.90.0.3:

1. Work around the brain dead libtool.

Changes from binutils 2.14.90.0.2:

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

Changes from binutils 2.14.90.0.1:

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

Changes from binutils 2.13.90.0.20:

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

Changes from binutils 2.13.90.0.18:

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

Changes from binutils 2.13.90.0.16:

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

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

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

Changes from binutils 2.13.90.0.10:

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

Changes from binutils 2.13.90.0.4:

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

Changes from binutils 2.13.90.0.3:

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

Changes from binutils 2.13.90.0.2:

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

The file list:

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

There is no separate source rpm. You can do

# rpm -ta binutils-2.14.90.0.4.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
05/25/2003

From jinum@esntechnologies.co.in Mon May 26 14:26:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 May 2003 14:26:55 +0100 (BST)
Received: from [IPv6:::ffff:202.125.80.34] ([IPv6:::ffff:202.125.80.34]:28166
	"EHLO mail.esn.activedirectory") by linux-mips.org with ESMTP
	id <S8225192AbTEZN0w>; Mon, 26 May 2003 14:26:52 +0100
Received: by mail.esn.activedirectory with Internet Mail Service (5.5.2650.10)
	id <LAZ0NQT5>; Mon, 26 May 2003 18:56:16 +0530
Message-ID: <AF572D578398634881E52418B2892567122B4C@mail.esn.activedirectory>
From: JinuM <jinum@esntechnologies.co.in>
To: linux-mips@linux-mips.org
Subject: PCI Conf Space in application mode
Date: Mon, 26 May 2003 18:56:13 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <jinum@esntechnologies.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: 2445
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jinum@esntechnologies.co.in
Precedence: bulk
X-list: linux-mips

Hi!

I am looking at an application to print PCI Configuration space on MIPS
platform in user mode.

On my x86 system i do that using iopl() call n then accessing PCI Conf space
through ADDRESS port(0xCF8) and DATA port(0xCFC). Here i have no problems
accessing the IO ports.

But i believe its not the same in MIPS architecture. How can i read n write
into some IO port(memory mapped in MIPS) on MIPS platform. Can i only access
these ports in driver mode?

The x86 code does compile with a mips cross compiler and i am able to
execute it. But the output that i see is some junk getting printed on one
line. 

Thanx in advance.

Regards,
Jinu


From macro@ds2.pg.gda.pl Mon May 26 14:42:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 May 2003 14:42:25 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:41185 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225192AbTEZNmX>; Mon, 26 May 2003 14:42:23 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA06886;
	Mon, 26 May 2003 15:43:05 +0200 (MET DST)
Date: Mon, 26 May 2003 15:43:04 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: JinuM <jinum@esntechnologies.co.in>
cc: linux-mips@linux-mips.org
Subject: Re: PCI Conf Space in application mode
In-Reply-To: <AF572D578398634881E52418B2892567122B4C@mail.esn.activedirectory>
Message-ID: <Pine.GSO.3.96.1030526154030.4495B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2446
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 26 May 2003, JinuM wrote:

> But i believe its not the same in MIPS architecture. How can i read n write
> into some IO port(memory mapped in MIPS) on MIPS platform. Can i only access
> these ports in driver mode?

 Use /dev/port or /dev/mem.

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


From bmc@phunnypharm.org Mon May 26 16:28:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 May 2003 16:28:16 +0100 (BST)
Received: from bristol.phunnypharm.org ([IPv6:::ffff:65.207.35.130]:8101 "EHLO
	bristol.phunnypharm.org") by linux-mips.org with ESMTP
	id <S8225192AbTEZP2N>; Mon, 26 May 2003 16:28:13 +0100
Received: from hopper.phunnypharm.org ([65.207.35.143] ident=mail)
	by bristol.phunnypharm.org with esmtp (Exim 3.36 #1 (Debian))
	id 19KJtH-0000iC-00; Mon, 26 May 2003 11:27:59 -0400
Received: from bmc by hopper.phunnypharm.org with local (Exim 3.36 #1 (Debian))
	id 19KJ6p-0003yT-00; Mon, 26 May 2003 10:37:55 -0400
Date: Mon, 26 May 2003 10:37:55 -0400
From: Ben Collins <bcollins@debian.org>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: [PATCH] Fix thinko in mips/mips64 sys_sysmips
Message-ID: <20030526143755.GT2657@phunnypharm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <bmc@phunnypharm.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: 2447
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bcollins@debian.org
Precedence: bulk
X-list: linux-mips

This has already been fixed in Linus' tree. Here's hoping it gets into
2.4 sometime soon. Note in the patch that "node" is the userspace
pointer and "nodename" is the string where "node" was
strncpy_from_user()'d to.

So it really should be using "nodename".



Index: linux-2.4/arch/mips64/kernel/syscall.c
===================================================================
--- linux-2.4/arch/mips64/kernel/syscall.c	(revision 3226)
+++ linux-2.4/arch/mips64/kernel/syscall.c	(working copy)
@@ -207,7 +207,7 @@
 			return -EFAULT;
 
 		down_write(&uts_sem);
-		strncpy(system_utsname.nodename, name, len);
+		strncpy(system_utsname.nodename, nodename, len);
 		system_utsname.nodename[len] = '\0';
 		up_write(&uts_sem);
 		return 0;
Index: linux-2.4/arch/mips/kernel/sysmips.c
===================================================================
--- linux-2.4/arch/mips/kernel/sysmips.c	(revision 3226)
+++ linux-2.4/arch/mips/kernel/sysmips.c	(working copy)
@@ -65,7 +65,7 @@
 			return -EFAULT;
 
 		down_write(&uts_sem);
-		strncpy(system_utsname.nodename, name, len);
+		strncpy(system_utsname.nodename, nodename, len);
 		system_utsname.nodename[len] = '\0';
 		up_write(&uts_sem);
 		return 0;

From hadi@shell.cyberus.ca Mon May 26 18:54:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 May 2003 18:54:59 +0100 (BST)
Received: from shell.cyberus.ca ([IPv6:::ffff:216.191.236.4]:35338 "EHLO
	shell.cyberus.ca") by linux-mips.org with ESMTP id <S8225217AbTEZRyz>;
	Mon, 26 May 2003 18:54:55 +0100
Received: from hadi (helo=localhost)
	by shell.cyberus.ca with local-esmtp (Exim 4.14)
	id 19KM8n-000FHP-CX
	for linux-mips@linux-mips.org; Mon, 26 May 2003 13:52:09 -0400
Date: Mon, 26 May 2003 13:52:09 -0400 (EDT)
From: Jamal Hadi <hadi@shell.cyberus.ca>
To: linux-mips@linux-mips.org
Subject: Re: profiling SMP/SB1250
In-Reply-To: <20030525001222.B54761@shell.cyberus.ca>
Message-ID: <20030526135012.S58731@shell.cyberus.ca>
References: <20030525001222.B54761@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <hadi@shell.cyberus.ca>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2448
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hadi@shell.cyberus.ca
Precedence: bulk
X-list: linux-mips


As a followup to my own question and incase someone is interested;
profiling works fine - you need to use -n option to readprofile
(which is not needed in x86).
If anyone knows what tools to use check cache misses etc on the
bcom 1250, please email me.

cheers,
jamal

On Sun, 25 May 2003, Jamal Hadi wrote:

>
> Hi,
>
> Newbie to MIPS here and not on the list (so cc me please).
> I am playing around with a SB1250 board; it has two CPUs. Attempt to
> kernel profile:
> on bootup selected profile=2 to enable profiling(validated because
> /proc/profile shows up). readprofile produce some strange
> output after i ran a lot of interupt related stresses. The output seems
> to claim the CPU was idle ... I know it was not.
> The SB1250 ties all IO interupts on CPU0 - i wonder if this was causing me
> some issues? Is what i am doing the right way to turn on profiling on
> MIPS or the SB1250?
>
> cheers,
> jamal
>
>
>

From alan@lxorguk.ukuu.org.uk Tue May 27 01:31:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 01:31:29 +0100 (BST)
Received: from pc2-cwma1-4-cust86.swan.cable.ntl.com ([IPv6:::ffff:213.105.254.86]:3788
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8225213AbTE0AbV>; Tue, 27 May 2003 01:31:21 +0100
Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.8/8.12.5) with ESMTP id h4QNXJRQ017282;
	Tue, 27 May 2003 00:33:20 +0100
Received: (from alan@localhost)
	by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h4QNXCkT017280;
	Tue, 27 May 2003 00:33:12 +0100
X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: PCI Conf Space in application mode
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: JinuM <jinum@esntechnologies.co.in>
Cc: linux-mips@linux-mips.org
In-Reply-To: <AF572D578398634881E52418B2892567122B4C@mail.esn.activedirectory>
References: <AF572D578398634881E52418B2892567122B4C@mail.esn.activedirectory>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1053991990.17128.12.camel@dhcp22.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 27 May 2003 00:33:12 +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: 2449
X-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 my x86 system i do that using iopl() call n then accessing PCI Conf space
> through ADDRESS port(0xCF8) and DATA port(0xCFC). Here i have no problems
> accessing the IO ports.

This is wrong. If the kernel does a PCI config access between your two
accesses you will break the system. See pcilib as used by lspci



From ralf@linux-mips.org Tue May 27 05:09:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 05:09:54 +0100 (BST)
Received: from p508B77C3.dip.t-dialin.net ([IPv6:::ffff:80.139.119.195]:22203
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225213AbTE0EJv>; Tue, 27 May 2003 05:09:51 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4R49lbY013927;
	Mon, 26 May 2003 21:09:47 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4R49jcA013925;
	Tue, 27 May 2003 06:09:45 +0200
Date: Tue, 27 May 2003 06:09:45 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Embedded ramdisks
Message-ID: <20030527040945.GA13908@linux-mips.org>
References: <Pine.GSO.4.21.0305231551110.26586-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0305231551110.26586-100000@vervain.sonytel.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: 2450
X-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, May 23, 2003 at 03:52:45PM +0200, Geert Uytterhoeven wrote:

> Fix the dependency for embedded ramdisks by using the contents of
> CONFIG_EMBEDDED_RAMDISK_IMAGE (after stripping the leading and trailing double
> quotes) instead of using the hardcoded filename `ramdisk.gz'.

Thanks, applied.

  Ralf

From ralf@linux-mips.org Tue May 27 05:18:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 05:18:38 +0100 (BST)
Received: from p508B77C3.dip.t-dialin.net ([IPv6:::ffff:80.139.119.195]:56763
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225219AbTE0ESf>; Tue, 27 May 2003 05:18:35 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4R4IVbY014043;
	Mon, 26 May 2003 21:18:31 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4R4IVMg014042;
	Tue, 27 May 2003 06:18:31 +0200
Date: Tue, 27 May 2003 06:18:30 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] pci_alloc_consistent() crash
Message-ID: <20030527041830.GA14012@linux-mips.org>
References: <Pine.GSO.4.21.0305231549510.26586-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0305231549510.26586-100000@vervain.sonytel.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: 2451
X-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, May 23, 2003 at 03:51:00PM +0200, Geert Uytterhoeven wrote:

> Avoid a NULL-pointer dereference when using pci_alloc_consistent() for
> PCI-like buses (i.e. hwdev = NULL).

Thanks, applied.

  Ralf

From ralf@linux-mips.org Tue May 27 05:25:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 05:25:06 +0100 (BST)
Received: from p508B77C3.dip.t-dialin.net ([IPv6:::ffff:80.139.119.195]:12988
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225219AbTE0EZE>; Tue, 27 May 2003 05:25:04 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4R4OibY014096;
	Mon, 26 May 2003 21:24:44 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4R4OgqD014095;
	Tue, 27 May 2003 06:24:42 +0200
Date: Tue, 27 May 2003 06:24:42 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Ben Collins <bcollins@debian.org>
Cc: Marcelo Tosatti <marcelo@conectiva.com.br>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix thinko in mips/mips64 sys_sysmips
Message-ID: <20030527042442.GB14012@linux-mips.org>
References: <20030526143755.GT2657@phunnypharm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030526143755.GT2657@phunnypharm.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: 2452
X-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, May 26, 2003 at 10:37:55AM -0400, Ben Collins wrote:

> This has already been fixed in Linus' tree. Here's hoping it gets into
> 2.4 sometime soon. Note in the patch that "node" is the userspace
> pointer and "nodename" is the string where "node" was
> strncpy_from_user()'d to.
> 
> So it really should be using "nodename".

Thanks, applied.

This function being an afaik unused stoneage compatibility function is
a candidate to die anyway ...

  Ralf

From ralf@linux-mips.org Tue May 27 06:47:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 06:47:23 +0100 (BST)
Received: from p508B77C3.dip.t-dialin.net ([IPv6:::ffff:80.139.119.195]:1729
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225228AbTE0FrU>; Tue, 27 May 2003 06:47:20 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4R5ksbY019737;
	Mon, 26 May 2003 22:46:54 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4R5knPr019736;
	Tue, 27 May 2003 07:46:49 +0200
Date: Tue, 27 May 2003 07:46:49 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Arrow keys on USB keyboards
Message-ID: <20030527054649.GA19562@linux-mips.org>
References: <Pine.GSO.4.21.0305231545030.26586-100000@vervain.sonytel.be> <Pine.GSO.3.96.1030523155904.14542E-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030523155904.14542E-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2453
X-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, May 23, 2003 at 04:05:43PM +0200, Maciej W. Rozycki wrote:

>  Hmm, if the PC/AT keyboard translation is needed by other devices beside
> pc_keyb.c, then why isn't the common part put into a separate file to be
> used by all devices depending on this translation as needed?  I think
> dummy_keyb.c should be kept plain and simple as it is now. 

You're right but for 2.4 this looks like an acceptable solution for now so
I'm going to apply this until somebody comes up with a better solution.

  Ralf

From ralf@linux-mips.org Tue May 27 10:17:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 10:17:47 +0100 (BST)
Received: from p508B77C3.dip.t-dialin.net ([IPv6:::ffff:80.139.119.195]:39117
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225232AbTE0JRo>; Tue, 27 May 2003 10:17:44 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4R9HgbY023487;
	Tue, 27 May 2003 02:17:42 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4R9Heid023486;
	Tue, 27 May 2003 11:17:40 +0200
Date: Tue, 27 May 2003 11:17:40 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Wayne Gowcher <wgowcher@yahoo.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: pci_alloc_consistent usage
Message-ID: <20030527091740.GA23296@linux-mips.org>
References: <20030523215935.71373.qmail@web11901.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030523215935.71373.qmail@web11901.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: 2454
X-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, May 23, 2003 at 02:59:35PM -0700, Wayne Gowcher wrote:

> Where PAGE_OFFSET is 0x8000 0000, and where PHYSADDR
> would AND the address against 0x1FFF FFFF. As far as I
> can tell the problem comes from pci_alloc_consistent
> doing :
> 
> ret = UNCAC_ADDR(ret) 
> 
> which converts a 0x8xxx address to 0xAxxx, and then
> when you pass this 0xAxxx_xxxx address through
> virt_to_phys() you get an address of the form
> 0x2xxx_xxxx. This 0x2xxx_xxxx is passed to the dma
> controller as the physical address to where it must
> read / write data, and because it is 0x2xxx_xxxx and
> not 0x0xxx_xxxx an exception occurs.

The change was partly done to catch broken code, partly because a
subtraction is potencially faster on some processors.

> At first I just tried AND'ing out the 0xA.. like
> PHYSADDR used to do it, but with that change i no
> longer get the exception, but the driver does not dma
> the data across - it just sits there.
> 
> I read DMA-mapping.txt and it says virt_to_phys() will
> be phased out, and should be used, but doesn't
> elaborate any further (like how you should do it now).

Use the value returned by pci_alloc_consistent in *dma_handle instead
of trying to do any conversions with of pci_alloc_consistent's return
value.

  Ralf

From ralf@linux-mips.org Tue May 27 10:26:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 10:26:58 +0100 (BST)
Received: from p508B77C3.dip.t-dialin.net ([IPv6:::ffff:80.139.119.195]:22478
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225232AbTE0J04>; Tue, 27 May 2003 10:26:56 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4R9QobY023587;
	Tue, 27 May 2003 02:26:50 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4R9QnxQ023586;
	Tue, 27 May 2003 11:26:49 +0200
Date: Tue, 27 May 2003 11:26:49 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Ashish anand <ashish.anand@inspiretech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Any complications of using CONFIG_MIPS_UNCACHED..?
Message-ID: <20030527092649.GB23296@linux-mips.org>
References: <200305210618.h4L6HqI9006634@smtp.inspirtek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200305210618.h4L6HqI9006634@smtp.inspirtek.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: 2455
X-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, May 21, 2003 at 11:16:49AM +0530, Ashish anand wrote:

> I saw a good bit of discussion about CONFIG_MIPS_UNCACHED but
> still i am yet to know...
> 
> If I want to use CONFIG_MIPS_UNCACHED (ignoring performance)
> what all the side-effects and any restrictions that linux should
> take care in software ?
> 
> I observed something surprising on my R4k mips system(virtually indexed
> caches), after i use this option my driver never got status updation by
> device in transmit and receive decriptors in system memory , Irrespective
> of I (flushed+invalidate) caches or not...

Descriptors sounds like networking.  Network descriptors should usually
be stored in uncached or otherwise coherent space that is allocated
through pci_alloc_consistent anyway.  If you do that CONFIG_MIPS_UNCACHED
should not make any difference anymore.

> if i don't use CONFIG_MIPS_UNCACHED then before checking status I need to 
> (flush+invalidate) cache and whole thing works great...

That's a funny bug.  Normally the opposite behaviour would be expected for
a bug ...

  Ralf

From fxzhang@ict.ac.cn Tue May 27 10:35:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 10:35:30 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:44220
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225232AbTE0JfX>; Tue, 27 May 2003 10:35:23 +0100
Received: (qmail 16451 invoked from network); 27 May 2003 09:05:03 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 27 May 2003 09:05:03 -0000
Message-ID: <3ED33148.2040008@ict.ac.cn>
Date: Tue, 27 May 2003 17:35:04 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: about gas load_address
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Return-Path: <fxzhang@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2456
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fxzhang@ict.ac.cn
Precedence: bulk
X-list: linux-mips

hi,all

(sorry if it is somewhat out of topic,but i think most mips experts
are here:)

else if (mips_pic == SVR4_PIC && ! mips_big_got)
{
expressionS ex;

/* If this is a reference to an external symbol, we want
lw $reg,<sym>($gp) (BFD_RELOC_MIPS_GOT16)
Otherwise we want
lw $reg,<sym>($gp) (BFD_RELOC_MIPS_GOT16)
nop
QUESTION:
Could somebody tell me why we generate a unconditional 'nop' here?
addiu $reg,$reg,<sym> (BFD_RELOC_LO16)
If there is a constant, it must be added in after.

If we have NewABI, we want
lw $reg,<sym+cst>($gp) (BFD_RELOC_MIPS_GOT_DISP)
unless we're referencing a global symbol with a non-zero
offset, in which case cst must be added separately. */

Thanks in advance.




From ralf@linux-mips.org Tue May 27 10:53:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 10:53:38 +0100 (BST)
Received: from p508B77C3.dip.t-dialin.net ([IPv6:::ffff:80.139.119.195]:49359
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225232AbTE0Jxg>; Tue, 27 May 2003 10:53:36 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4R9rRbY023831;
	Tue, 27 May 2003 02:53:27 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4R9rOxv023830;
	Tue, 27 May 2003 11:53:24 +0200
Date: Tue, 27 May 2003 11:53:24 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: about gas load_address
Message-ID: <20030527095324.GC23296@linux-mips.org>
References: <3ED33148.2040008@ict.ac.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3ED33148.2040008@ict.ac.cn>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2457
X-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, May 27, 2003 at 05:35:04PM +0800, Fuxin Zhang wrote:
> Date:	Tue, 27 May 2003 17:35:04 +0800
> From:	Fuxin Zhang <fxzhang@ict.ac.cn>
> To:	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Funny alias for this list :-)

> (sorry if it is somewhat out of topic,but i think most mips experts
> are here:)

Certainly more on topic than making prank calls ;-)

> else if (mips_pic == SVR4_PIC && ! mips_big_got)
> {
> expressionS ex;
> 
> /* If this is a reference to an external symbol, we want
> lw $reg,<sym>($gp) (BFD_RELOC_MIPS_GOT16)
> Otherwise we want
> lw $reg,<sym>($gp) (BFD_RELOC_MIPS_GOT16)
> nop
> QUESTION:
> Could somebody tell me why we generate a unconditional 'nop' here?
> addiu $reg,$reg,<sym> (BFD_RELOC_LO16)
> If there is a constant, it must be added in after.

The nop would only be needed for the R2000/R3000 family where a load
instruction may not immediately be followed by it's consumer instruction.
NewABI implies MIPS III or higher so the nop wouldn't be required for
such processors.  Gcc and gas have sort of a tradition of throwing many
more nops in than needed ...

> If we have NewABI, we want
> lw $reg,<sym+cst>($gp) (BFD_RELOC_MIPS_GOT_DISP)
> unless we're referencing a global symbol with a non-zero
> offset, in which case cst must be added separately. */

  Ralf

From anemo@mba.ocn.ne.jp Tue May 27 11:07:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 11:08:10 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:34842
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225232AbTE0KHi>; Tue, 27 May 2003 11:07:38 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 27 May 2003 10:07:35 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h4RA7Kjf006331;
	Tue, 27 May 2003 19:07:21 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Tue, 27 May 2003 19:07:49 +0900 (JST)
Message-Id: <20030527.190749.39150100.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org
Cc: wgowcher@yahoo.com, linux-mips@linux-mips.org
Subject: Re: pci_alloc_consistent usage
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030527091740.GA23296@linux-mips.org>
References: <20030523215935.71373.qmail@web11901.mail.yahoo.com>
	<20030527091740.GA23296@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2458
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Tue, 27 May 2003 11:17:40 +0200, Ralf Baechle <ralf@linux-mips.org> said:
ralf> Use the value returned by pci_alloc_consistent in *dma_handle
ralf> instead of trying to do any conversions with of
ralf> pci_alloc_consistent's return value.

How about virt_to_page()?

Currently, many sound drivers (including ALSA) pass a
pci_alloc_consistent's return value to virt_to_page.  While
virt_to_page is defined as below, we can not pass KSEG1 address
(returned by pci_alloc_consistent) to virt_to_page.

#define __pa(x)		((unsigned long) (x) - PAGE_OFFSET)
#define virt_to_page(kaddr)	(mem_map + (__pa(kaddr) >> PAGE_SHIFT))

Following definition can handle this case properly,

#define virt_to_page(kaddr)	(mem_map + (PHYSADDR(kaddr) >> PAGE_SHIFT))

But as ralf said, PHYSADDR() may be is a bit slower then __pa().

Is it worth to change?  Or should we fix the driver using virt_to_page
with pci_alloc_consistent?

---
Atsushi Nemoto

From hch@infradead.org Tue May 27 11:53:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 11:53:27 +0100 (BST)
Received: from carisma.slowglass.com ([IPv6:::ffff:195.224.96.167]:5641 "EHLO
	phoenix.infradead.org") by linux-mips.org with ESMTP
	id <S8225073AbTE0KxZ>; Tue, 27 May 2003 11:53:25 +0100
Received: from hch by phoenix.infradead.org with local (Exim 4.10)
	id 19Kc54-0001r1-00; Tue, 27 May 2003 11:53:22 +0100
Date: Tue, 27 May 2003 11:53:22 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: ralf@linux-mips.org, wgowcher@yahoo.com, linux-mips@linux-mips.org
Subject: Re: pci_alloc_consistent usage
Message-ID: <20030527115322.A7124@infradead.org>
References: <20030523215935.71373.qmail@web11901.mail.yahoo.com> <20030527091740.GA23296@linux-mips.org> <20030527.190749.39150100.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030527.190749.39150100.nemoto@toshiba-tops.co.jp>; from anemo@mba.ocn.ne.jp on Tue, May 27, 2003 at 07:07:49PM +0900
Return-Path: <hch@infradead.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: 2459
X-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@infradead.org
Precedence: bulk
X-list: linux-mips

On Tue, May 27, 2003 at 07:07:49PM +0900, Atsushi Nemoto wrote:
> >>>>> On Tue, 27 May 2003 11:17:40 +0200, Ralf Baechle <ralf@linux-mips.org> said:
> ralf> Use the value returned by pci_alloc_consistent in *dma_handle
> ralf> instead of trying to do any conversions with of
> ralf> pci_alloc_consistent's return value.
> 
> How about virt_to_page()?
> 
> Currently, many sound drivers (including ALSA) pass a
> pci_alloc_consistent's return value to virt_to_page.

You are not allow to do so.  Any driver doing this is broken.


From ralf@linux-mips.org Tue May 27 12:22:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 12:22:53 +0100 (BST)
Received: from p508B77C3.dip.t-dialin.net ([IPv6:::ffff:80.139.119.195]:48085
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225073AbTE0LWv>; Tue, 27 May 2003 12:22:51 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4RBMgbY025029;
	Tue, 27 May 2003 04:22:44 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4RBMcAq025028;
	Tue, 27 May 2003 13:22:38 +0200
Date: Tue, 27 May 2003 13:22:37 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, wgowcher@yahoo.com,
	linux-mips@linux-mips.org
Subject: Re: pci_alloc_consistent usage
Message-ID: <20030527112237.GA24905@linux-mips.org>
References: <20030523215935.71373.qmail@web11901.mail.yahoo.com> <20030527091740.GA23296@linux-mips.org> <20030527.190749.39150100.nemoto@toshiba-tops.co.jp> <20030527115322.A7124@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030527115322.A7124@infradead.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: 2460
X-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, May 27, 2003 at 11:53:22AM +0100, Christoph Hellwig wrote:

> > ralf> Use the value returned by pci_alloc_consistent in *dma_handle
> > ralf> instead of trying to do any conversions with of
> > ralf> pci_alloc_consistent's return value.
> > 
> > How about virt_to_page()?
> > 
> > Currently, many sound drivers (including ALSA) pass a
> > pci_alloc_consistent's return value to virt_to_page.
> 
> You are not allow to do so.  Any driver doing this is broken.

That however is exactly what's documented in DMA-mapping.txt:

[...]
portably refer to any piece of memory.  If you have a cpu pointer
(which may be validly DMA'd too) you may easily obtain the page
and offset using something like this:
                                                                                
        struct page *page = virt_to_page(ptr);
        unsigned long offset = ((unsigned long)ptr & ~PAGE_MASK);
[...]

While it's officially documented I still don't like it.  A double
conversion such as page_address(virt_to_page(ptr)) would accidently
turn a pointer of an uncached mapping into one to a cached area for the
same object - that will almost certainly not work as expected on a
non-coherent machine.

  Ralf

From hch@infradead.org Tue May 27 12:33:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 12:33:34 +0100 (BST)
Received: from phoenix.infradead.org ([IPv6:::ffff:195.224.96.167]:23561 "EHLO
	phoenix.infradead.org") by linux-mips.org with ESMTP
	id <S8225073AbTE0Ldc>; Tue, 27 May 2003 12:33:32 +0100
Received: from hch by phoenix.infradead.org with local (Exim 4.10)
	id 19Kcht-00021B-00; Tue, 27 May 2003 12:33:29 +0100
Date: Tue, 27 May 2003 12:33:29 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, wgowcher@yahoo.com,
	linux-mips@linux-mips.org
Subject: Re: pci_alloc_consistent usage
Message-ID: <20030527123329.A7750@infradead.org>
References: <20030523215935.71373.qmail@web11901.mail.yahoo.com> <20030527091740.GA23296@linux-mips.org> <20030527.190749.39150100.nemoto@toshiba-tops.co.jp> <20030527115322.A7124@infradead.org> <20030527112237.GA24905@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030527112237.GA24905@linux-mips.org>; from ralf@linux-mips.org on Tue, May 27, 2003 at 01:22:37PM +0200
Return-Path: <hch@infradead.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: 2461
X-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@infradead.org
Precedence: bulk
X-list: linux-mips

On Tue, May 27, 2003 at 01:22:37PM +0200, Ralf Baechle wrote:
> [...]
> portably refer to any piece of memory.  If you have a cpu pointer
> (which may be validly DMA'd too) you may easily obtain the page
> and offset using something like this:
>                                                                                 
>         struct page *page = virt_to_page(ptr);
>         unsigned long offset = ((unsigned long)ptr & ~PAGE_MASK);
> [...]
> 
> While it's officially documented I still don't like it.

Hmm, I remembered that some ports used vmalloc-like allocators for
this and virt_to_page doesn't work for those..


From ralf@linux-mips.org Tue May 27 12:45:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 12:45:57 +0100 (BST)
Received: from p508B77C3.dip.t-dialin.net ([IPv6:::ffff:80.139.119.195]:61910
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225073AbTE0Lpz>; Tue, 27 May 2003 12:45:55 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4RBjpbY025287;
	Tue, 27 May 2003 04:45:51 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4RBjpcP025286;
	Tue, 27 May 2003 13:45:51 +0200
Date: Tue, 27 May 2003 13:45:51 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, wgowcher@yahoo.com,
	linux-mips@linux-mips.org
Subject: Re: pci_alloc_consistent usage
Message-ID: <20030527114551.GC24905@linux-mips.org>
References: <20030523215935.71373.qmail@web11901.mail.yahoo.com> <20030527091740.GA23296@linux-mips.org> <20030527.190749.39150100.nemoto@toshiba-tops.co.jp> <20030527115322.A7124@infradead.org> <20030527112237.GA24905@linux-mips.org> <20030527123329.A7750@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030527123329.A7750@infradead.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: 2462
X-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, May 27, 2003 at 12:33:29PM +0100, Christoph Hellwig wrote:

> On Tue, May 27, 2003 at 01:22:37PM +0200, Ralf Baechle wrote:
> > [...]
> > portably refer to any piece of memory.  If you have a cpu pointer
> > (which may be validly DMA'd too) you may easily obtain the page
> > and offset using something like this:
> >                                                                                 
> >         struct page *page = virt_to_page(ptr);
> >         unsigned long offset = ((unsigned long)ptr & ~PAGE_MASK);
> > [...]
> > 
> > While it's officially documented I still don't like it.
> 
> Hmm, I remembered that some ports used vmalloc-like allocators for
> this and virt_to_page doesn't work for those..

There's at least one MIPS system which we don't support anymore but which
would have to be supported by something like this.

Whatever - virt_to_page should then be considered a a legacy API which we
have to try to support as well as possible in the hope it's going to fade
away ...

  Ralf

From ralf@linux-mips.org Tue May 27 13:48:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 13:48:18 +0100 (BST)
Received: from p508B77C3.dip.t-dialin.net ([IPv6:::ffff:80.139.119.195]:11482
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225073AbTE0MsP>; Tue, 27 May 2003 13:48:15 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h4RCmAbY025902;
	Tue, 27 May 2003 05:48:10 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h4RCmAY6025901;
	Tue, 27 May 2003 14:48:10 +0200
Date: Tue, 27 May 2003 14:48:10 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: special include/asm/siginfo.h for MIPS
Message-ID: <20030527124810.GB25333@linux-mips.org>
References: <20030520191124.N32567@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030520191124.N32567@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: 2463
X-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, May 20, 2003 at 07:11:24PM -0700, Jun Sun wrote:

> Any thoughts?  Can we just use what other arches are using?

No.  Changing the Linux ABI is not an option without forcing reason
unless you somehow can show that some interface simply wasn't used.

  Ralf

From macro@ds2.pg.gda.pl Tue May 27 14:14:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 14:15:01 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:52397 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225073AbTE0NO7>; Tue, 27 May 2003 14:14:59 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA25379;
	Tue, 27 May 2003 15:15:33 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 27 May 2003 15:15:33 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Arrow keys on USB keyboards
In-Reply-To: <20030527054649.GA19562@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030527150418.24408B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2464
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 27 May 2003, Ralf Baechle wrote:

> >  Hmm, if the PC/AT keyboard translation is needed by other devices beside
> > pc_keyb.c, then why isn't the common part put into a separate file to be
> > used by all devices depending on this translation as needed?  I think
> > dummy_keyb.c should be kept plain and simple as it is now. 
> 
> You're right but for 2.4 this looks like an acceptable solution for now so
> I'm going to apply this until somebody comes up with a better solution.

 Hmm, as I've understood that's a 2.4-only problem as 2.5 has it solved
differently.  And I do think the translation really belong to the drivers
that use it -- why can't it be included with the USB keyboard driver or as
a library file?  Why an unrelated driver has to be cluttered? 

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


From geert@linux-m68k.org Tue May 27 14:30:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 14:30:08 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:59381 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225073AbTE0NaG>;
	Tue, 27 May 2003 14:30:06 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h4RDTrLT024409;
	Tue, 27 May 2003 15:29:53 +0200 (MEST)
Date: Tue, 27 May 2003 15:29:54 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Arrow keys on USB keyboards
In-Reply-To: <Pine.GSO.3.96.1030527150418.24408B-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0305271521210.29405-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2465
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 27 May 2003, Maciej W. Rozycki wrote:
> On Tue, 27 May 2003, Ralf Baechle wrote:
> > >  Hmm, if the PC/AT keyboard translation is needed by other devices beside
> > > pc_keyb.c, then why isn't the common part put into a separate file to be
> > > used by all devices depending on this translation as needed?  I think
> > > dummy_keyb.c should be kept plain and simple as it is now. 
> > 
> > You're right but for 2.4 this looks like an acceptable solution for now so
> > I'm going to apply this until somebody comes up with a better solution.
> 
>  Hmm, as I've understood that's a 2.4-only problem as 2.5 has it solved
> differently.  And I do think the translation really belong to the drivers
> that use it -- why can't it be included with the USB keyboard driver or as
> a library file?  Why an unrelated driver has to be cluttered? 

It's not really used by a driver, but by the input subsystem itself. You could
add the translation to drivers/char/keyboard.c, but then it will break if you
use both the input subsystem (e.g. USB keyboard) and some other non-PS/2
keyboard driver.

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 macro@ds2.pg.gda.pl Tue May 27 14:50:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 14:50:18 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:51631 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225073AbTE0NuP>; Tue, 27 May 2003 14:50:15 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA25830;
	Tue, 27 May 2003 15:50:59 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 27 May 2003 15:50:59 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Arrow keys on USB keyboards
In-Reply-To: <Pine.GSO.4.21.0305271521210.29405-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1030527154004.24408D-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2466
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 27 May 2003, Geert Uytterhoeven wrote:

> >  Hmm, as I've understood that's a 2.4-only problem as 2.5 has it solved
> > differently.  And I do think the translation really belong to the drivers
> > that use it -- why can't it be included with the USB keyboard driver or as
> > a library file?  Why an unrelated driver has to be cluttered? 
> 
> It's not really used by a driver, but by the input subsystem itself. You could
> add the translation to drivers/char/keyboard.c, but then it will break if you
> use both the input subsystem (e.g. USB keyboard) and some other non-PS/2
> keyboard driver.

 I don't understand -- the scancode mapping is specific to a keyboard
type.  Both PC/AT and USB keyboards may use the same scancodes by chance,
but others have different ones.  So how can the input subsystem need a
PC/AT specific mapping?  Adding the table to drivers/char/keyboard.c
certainly makes no sense as the file is meant to be generic. 

 BTW, the PS/2 mapping is yet different and doesn't use prefixes. 

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


From Geert.Uytterhoeven@sonycom.com Tue May 27 14:57:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 14:57:12 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:42652 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225073AbTE0N5K>;
	Tue, 27 May 2003 14:57:10 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h4RDv0LT028158;
	Tue, 27 May 2003 15:57:01 +0200 (MEST)
Date: Tue, 27 May 2003 15:57:01 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Arrow keys on USB keyboards
In-Reply-To: <Pine.GSO.3.96.1030527154004.24408D-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0305271552430.29405-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2467
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 27 May 2003, Maciej W. Rozycki wrote:
> On Tue, 27 May 2003, Geert Uytterhoeven wrote:
> > >  Hmm, as I've understood that's a 2.4-only problem as 2.5 has it solved
> > > differently.  And I do think the translation really belong to the drivers
> > > that use it -- why can't it be included with the USB keyboard driver or as
> > > a library file?  Why an unrelated driver has to be cluttered? 
> > 
> > It's not really used by a driver, but by the input subsystem itself. You could
> > add the translation to drivers/char/keyboard.c, but then it will break if you
> > use both the input subsystem (e.g. USB keyboard) and some other non-PS/2
> > keyboard driver.
> 
>  I don't understand -- the scancode mapping is specific to a keyboard
> type.  Both PC/AT and USB keyboards may use the same scancodes by chance,
> but others have different ones.  So how can the input subsystem need a
> PC/AT specific mapping?  Adding the table to drivers/char/keyboard.c
> certainly makes no sense as the file is meant to be generic. 

Scancode mapping is indeed specific to the keyboard type.

However, the input subsystem converts Linux input keycodes (cfr.
<linux/input.h>) to PC/AT scancodes, and feeds them to handle_scancode() in
drivers/char/keyboard.c. handle_scancode() calls kbd_translate() to translate
scancodes to keycodes, which is keyboard driver specific.

Since the input subsystem feeds PC/AT scancodes to handle_scancode(),
kbd_translate() needs to know about PC/AT scancodes. For the PS/2 keyboard
driver this is OK, for the dummy keyboard driver this is OK after my patch, but
for any other keyboard driver this will not 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 macro@ds2.pg.gda.pl Tue May 27 15:16:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 15:16:20 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:13745 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225073AbTE0OQS>; Tue, 27 May 2003 15:16:18 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA26198;
	Tue, 27 May 2003 16:16:22 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 27 May 2003 16:16:22 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Arrow keys on USB keyboards
In-Reply-To: <Pine.GSO.4.21.0305271552430.29405-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1030527160058.24408F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2468
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 27 May 2003, Geert Uytterhoeven wrote:

> However, the input subsystem converts Linux input keycodes (cfr.
> <linux/input.h>) to PC/AT scancodes, and feeds them to handle_scancode() in
> drivers/char/keyboard.c. handle_scancode() calls kbd_translate() to translate
> scancodes to keycodes, which is keyboard driver specific.

 Oh what a mess! -- why does it do so?  Since as I understand these input
keycodes are already translated from scancodes, why do they need to be
translated "back" to PC/AT scancodes (possibly with private inventions for
keys that do not exist on PC/AT or PS/2 keyboards) only to be translated
to medium-raw keycodes (for a total number of four translations from an
original scancode to a final cooked sequence)?  Why can't the input layer
provide its own kbd_translate() function translating directly from input
keycodes to medium-raw keycodes (or why the input keycodes are different
from medium-raw keycodes at all)?

 After all it looks like the input layer can be treated like a virtual
keyboard driver itself. 

> Since the input subsystem feeds PC/AT scancodes to handle_scancode(),
> kbd_translate() needs to know about PC/AT scancodes. For the PS/2 keyboard
> driver this is OK, for the dummy keyboard driver this is OK after my patch, but
> for any other keyboard driver this will not work.

 Why can't the input layer be fixed instead?  Given the interface between
the input layer and drivers/char/keyboard.c is internal the impact on
backend drivers should be nonexistent, hence no incompatibility problem
for 2.4.

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


From brad@patton.com Tue May 27 19:45:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 19:46:00 +0100 (BST)
Received: from emma.patton.com ([IPv6:::ffff:209.49.110.2]:41225 "EHLO
	emma.patton.com") by linux-mips.org with ESMTP id <S8225073AbTE0Sp6>;
	Tue, 27 May 2003 19:45:58 +0100
Received: from barrett ([209.49.110.172])
	by emma.patton.com (8.9.0/8.9.0) with SMTP id OAA06751
	for <linux-mips@linux-mips.org>; Tue, 27 May 2003 14:44:17 -0400 (EDT)
From: "Brad Barrett" <brad@patton.com>
To: "'Linux-Mips@Linux-Mips. Org'" <linux-mips@linux-mips.org>
Subject: "relocation truncated to fit"
Date: Tue, 27 May 2003 14:44:16 -0400
Message-ID: <BBEBJGNKIDPPHNAJKDFHAECPCJAA.brad@patton.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Return-Path: <brad@patton.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2469
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brad@patton.com
Precedence: bulk
X-list: linux-mips

Preface:
--------
I have a userspace toolchain issue.  I'm not sure where to post it, so I'll
start here.  I know some toolchain people are on this list.  If there's a more
appropriate mailing list someone let me know.

Synopsis:
---------
I am cross-compiling (on x86) the GNU Gatekeeper using "homebuilt" GNU
mipsel-linux tools.  For those not familiar with Gatekeeper there are three
parts.  Two libraries: pwlib and openh323, and then a gatekeeper client called
openh323gk which links to both libraries.

I am able to build pwlib completely--both static and shared versions of both the
debug and regular libraries.  I can build static versions of both debug and
regular openh323, but when linking the shared versions I get relocation
truncation errors (details below).  If try to build the openh323gk client using
either of the static openh323 libs that I was able to create, I get the same
kinds of relocation truncation errors at link time.

Details:
--------
Here is the link step that fails from the openh323 library build:

mipsel-linux-g++ -shared -Wl,-soname,libh323_linux_mips_r.so.1 -o
/home/brad/openh323/lib/libh323_linux_mips_r.so.1.11.7 -s -fPIC -L/home/brad/pwl
ib/lib -L/home/brad/openh323/lib -lpthread
/home/brad/openh323/lib/obj_linux_mips_r/h225_1.o  [... continues with 169 other
.o files]

The error output is thousands of the following:
/home/brad/openh323/lib/obj_linux_mips_r/h235.o(.gnu.linkonce.t._ZNK14H235_ENCRY
PTEDI27H235_EncodedKeySyncMaterialE5CloneEv+0x98): In function
`H235_ENCRYPTED<H235_EncodedKeySyncMaterial>::Clone() const': : relocation
truncated to fit: R_MIPS_GOT16 vtable for
H235_ENCRYPTED<H235_EncodedKeySyncMaterial>
/home/brad/openh323/lib/obj_linux_mips_r/h235.o(.gnu.linkonce.t._ZNK14H235_ENCRY
PTEDI27H235_EncodedKeySyncMaterialE5CloneEv+0xb0): In function
`H235_ENCRYPTED<H235_EncodedKeySyncMaterial>::Clone() const': : relocation
truncated to fit: R_MIPS_CALL16
PASN_ObjectId::PASN_ObjectId[in-charge](PASN_ObjectId const&)
/home/brad/openh323/lib/obj_linux_mips_r/h235.o(.gnu.linkonce.t._ZNK14H235_ENCRY
PTEDI27H235_EncodedKeySyncMaterialE5CloneEv+0xd0): In function
`H235_ENCRYPTED<H235_EncodedKeySyncMaterial>::Clone() const': : relocation
truncated to fit: R_MIPS_CALL16 H235_Params::H235_Params[in-charge](H235_Params
const&)
[...]

I built the cross-tools myself.  They are now about 6-8 months old.  They
consist of:
- gcc version 3.2.1 20020903 (prerelease)
- GNU ld version 2.13.90.0.10 20021010  [from H.J. Lu]
- glibc version 2.2.5

What I know:
------------
Googling hasn't turn up much, with the exception of an intriguing exchange from
Sept 2001  on this mailing list:

Petter Reinholdtsen reports similar messages when (native) compiling "a huge C++
program" (actually Opera) on an Indy:
http://www.spinics.net/lists/mips/msg04568.html

Wilbern Cobb suggests using -G4, -G2, or -G1, which Petter reports reduces the
messages but does not eliminate them.  Then Ryan Murray says that every static
library used in the link, including libc_noshared.a and libgcc.a, must be
compiled with -Wa,xgot.  H.J. Lu appears to think it's an -fpic vs -fPIC issue
(which from my level of understanding seems very plausible).  Most interesting
of all is that Ryan notes that this issue is *known* to affect Openh323.
http://www.spinics.net/lists/mips/msg04575.html

There is no follow up post from Petter, so how he resolved the issue is unknown.

From what I can gather, the -Gn option seems like a workaround, not a fix for
the root problem.  I have tried forcing -fPIC on every file in pwlib and
openh323, but this does not resolve the problem.  Perhaps my glibc libraries
contain some pic instead of PIC though?  "-Wa,xgot" seems like a whole lot of
work...essentially rebuilding the toolchain.  I have not tried it yet.  I'm
hoping someone will be able to give me a more conclusive diagnosis and allow me
to avoid hours of banging my head against the wall.

Is this a known issue (or just better understood than in Sept 2001) with the
mips linker?  Do I need newer tools, or a patch, or to rebuild the tools
differently?

Has anyone successfully built (native or cross) GNU Gatekeeper on MIPS?

Thanks in advance,
Brad
--
Brad Barrett
Senior Design Engineer, Patton Electronics
7622 Rickenbacker Dr., Gaithersburg, MD 20879
301/975-1000 x361


From ica2_ts@csv.ica.uni-stuttgart.de Tue May 27 20:27:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 May 2003 20:27:32 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:24786
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225073AbTE0T13>; Tue, 27 May 2003 20:27:29 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 19Kk5w-001avu-00; Tue, 27 May 2003 21:26:48 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19Kk5s-0000yn-00; Tue, 27 May 2003 21:26:44 +0200
Date: Tue, 27 May 2003 21:26:44 +0200
To: Brad Barrett <brad@patton.com>
Cc: "'Linux-Mips@Linux-Mips. Org'" <linux-mips@linux-mips.org>
Subject: Re: "relocation truncated to fit"
Message-ID: <20030527192643.GH18653@rembrandt.csv.ica.uni-stuttgart.de>
Mail-Followup-To: ica2_ts, Brad Barrett <brad@patton.com>,
	"'Linux-Mips@Linux-Mips. Org'" <linux-mips@linux-mips.org>
References: <BBEBJGNKIDPPHNAJKDFHAECPCJAA.brad@patton.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BBEBJGNKIDPPHNAJKDFHAECPCJAA.brad@patton.com>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2470
X-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

Brad Barrett wrote:
> Preface:
> --------
> I have a userspace toolchain issue.  I'm not sure where to post it, so I'll
> start here.

binutils@sources.redhat.com is probably the better place for this.

[snip]
> I built the cross-tools myself.  They are now about 6-8 months old.  They
> consist of:
> - gcc version 3.2.1 20020903 (prerelease)
> - GNU ld version 2.13.90.0.10 20021010  [from H.J. Lu]
> - glibc version 2.2.5

An upgrade is IMHO the best solution:
gcc 3.3 will fix some "branch out of range" issues, and binutils
newer than 2.13.90.0.18 implement multigot. Both together should
solve the problem.

> What I know:
> ------------
> Googling hasn't turn up much, with the exception of an intriguing exchange from
> Sept 2001  on this mailing list:

The GOT overflow problem is quite well known, it hits every largish
executable for O32 MIPS. Most notably Mozilla and parts of KDE were
affected, too.

> Petter Reinholdtsen reports similar messages when (native) compiling "a huge C++
> program" (actually Opera) on an Indy:
> http://www.spinics.net/lists/mips/msg04568.html
> 
> Wilbern Cobb suggests using -G4, -G2, or -G1, which Petter reports reduces the
> messages but does not eliminate them.

These reduce GOT usage at the expense of speed and size, so they
help a bit as workaround.

> Then Ryan Murray says that every static
> library used in the link, including libc_noshared.a and libgcc.a, must be
> compiled with -Wa,xgot.

Would also work, but is binary incompatible then.


Thiemo

From anemo@mba.ocn.ne.jp Wed May 28 02:30:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 May 2003 02:31:27 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:65056
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225214AbTE1Bay>; Wed, 28 May 2003 02:30:54 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 28 May 2003 01:30:52 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h4S1UHjf007873;
	Wed, 28 May 2003 10:30:17 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Wed, 28 May 2003 10:30:46 +0900 (JST)
Message-Id: <20030528.103046.41627144.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org
Cc: hch@infradead.org, anemo@mba.ocn.ne.jp, wgowcher@yahoo.com,
	linux-mips@linux-mips.org
Subject: Re: pci_alloc_consistent usage
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030527114551.GC24905@linux-mips.org>
	<20030527112237.GA24905@linux-mips.org>
References: <20030527112237.GA24905@linux-mips.org>
	<20030527123329.A7750@infradead.org>
	<20030527114551.GC24905@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2471
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Tue, 27 May 2003 13:22:37 +0200, Ralf Baechle <ralf@linux-mips.org> said:
ralf> While it's officially documented I still don't like it.  A
ralf> double conversion such as page_address(virt_to_page(ptr)) would
ralf> accidently turn a pointer of an uncached mapping into one to a
ralf> cached area for the same object - that will almost certainly not
ralf> work as expected on a non-coherent machine.

Yes, it's dangerous, I agree.

ralf> Whatever - virt_to_page should then be considered a a legacy API
ralf> which we have to try to support as well as possible in the hope
ralf> it's going to fade away ...

I hope so.  For now we can do something like:

     buf = pci_alloc_consistent(dev, size, &dmabuf);
#if defined(__mips__) && defined(CONFIG_NONCOHERENT_IO)
     page = virt_to_page(CAC_ADDR(buf));
#else
     page = virt_to_page(buf);
#endif

Ugly but I do not want to add extra overhead to virt_to_page itself...

---
Atsushi Nemoto

From zhanght@netpower.com.cn Thu May 29 04:50:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 May 2003 04:50:08 +0100 (BST)
Received: from [IPv6:::ffff:211.154.175.2] ([IPv6:::ffff:211.154.175.2]:34308
	"EHLO mail.netpower.com.cn") by linux-mips.org with ESMTP
	id <S8225200AbTE2DuF>; Thu, 29 May 2003 04:50:05 +0100
Received: from netpower.com.cn [192.168.0.196] by mail.netpower.com.cn with ESMTP
  (SMTPD32-7.07) id A2634370048; Thu, 29 May 2003 11:45:39 +0800
Message-ID: <3ED586BE.9050906@netpower.com.cn>
Date: Thu, 29 May 2003 12:04:14 +0800
From: Zhang Haitao <zhanght@netpower.com.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Hi, this is my patch for broadcom sb1250-mac.c
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <zhanght@netpower.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: 2472
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zhanght@netpower.com.cn
Precedence: bulk
X-list: linux-mips

Hi, i've got sb1250-mac.c from broadcom directly,
but find the original driver are not working stable when
delivering 64bytes framesize packets under gigabits circumstance.
This patch have been ported a part of NAPI (added an sbmac_poll 
function,dev->quota = 80 )
and modified some parameters to enhance the packets processing performance
eg. tx&rx dma discriptor numbers and dual TX channel configuration.
at the same, in order to let may driver working in Gigafiber circumstance,
i also added some codes for fiber mode controll.

After using my pacth, my board can process 140Mbps 64bytes packets under 
linux.

but there are still some problem exsit in my driver :
seems that bug will be trigger when running into fiber mode
and i also use klogd to collect some oops message, hope someone can told me
what's happend to make my kernel crashed.... :-(

i'm very glad to let all of you to review this patch
or give me some advice from the oops message!

Thanks in advance !
 
yours
Zhang Haitao

here i post my most part of this patch  and oops message get from klogd

----------------------------------------
< static int int_pktcnt = 32;
< static int int_timeout = 1024;
---
 > #ifdef CONFIG_SBMAC_COALESCE
 > static int int_pktcnt = 0;
 > static int int_timeout = 0;
 > #endif
94,95d95
< #define CONFIG_SB1250_NAPI
< #define NAPI_LOP_MAX 10
156,159c154,155
< #define SBMAC_MAX_TXDESCR     128
< #define SBMAC_MAX_RXDESCR     128
---
 > #define SBMAC_MAX_TXDESCR     32
 > #define SBMAC_MAX_RXDESCR     32
270,272d263
<
<       int              sbm_fibermode;
<       int              sbm_phy_oldsignaldetect;
293a285
 > static void sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d);
300d291
< /*static void sbmac_init_and_start(struct sbmac_softc *sc);*/
304,310d294
< #ifdef CONFIG_SB1250_NAPI
< static int sbmac_poll(struct net_device *dev_instance, int *budget);
< static inline void sbmac_irq_disable(struct sbmac_softc *s);
< static inline void sbmac_irq_enable(struct sbmac_softc *s);
< #else
< static void sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d);
< #endif
312c296
< static int sbmac_init(struct net_device *dev);
---
 > static int sbmac_init(struct net_device *dev, int idx);
460,468d442
< /* Added for Fiber mode detection
< just read Signal Detect alternation */
<
< #define MII_AUXCTL      0x18   /* Auxiliary Control Register */
<
< #define MII_SGMIISR     0x0C    /* SGMII/100-X Status Register */
<
< #define SGMIISR_FIBERSDS      0x2000
<
480,490d453
< #ifdef CONFIG_SB1250_NAPI
< static inline void sbmac_irq_disable(struct sbmac_softc *s){
<          SBMAC_WRITECSR(s->sbm_imr,
<                      ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << 
S_MAC_TX_CH0));
< }
< static inline void sbmac_irq_enable(struct sbmac_softc *s){
<       SBMAC_WRITECSR(s->sbm_imr,
<                      ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << 
S_MAC_TX_CH0) |
<                      ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << 
S_MAC_RX_CH0));
< }
< #endif
1075,1082c1040,1042
<       phys = KVTOPHYS(sb->data);
<       ncb = NUMCACHEBLKS(length+(phys & (CACHELINESIZE-1)));
< #ifdef CONFIG_SBMAC_COALESCE
<       /* do not interript per DMA transfer*/
<       dsc->dscr_a = phys |
<               V_DMA_DSCRA_A_SIZE(ncb) |
<               M_DMA_ETHTX_SOP;
< #else
---
 >       phys = virt_to_phys(sb->data);
 >       ncb = NUMCACHEBLKS(length+(phys & (SMP_CACHE_BYTES - 1)));
 >
1084a1045
 > #ifndef CONFIG_SBMAC_COALESCE
1085a1047
 > #endif
1166c1129
< #ifndef CONFIG_SB1250_NAPI
---
 >
1213,1221c1176,1177
<               if (curidx == hwidx) break;
<               /*{
<                       int i;
<                       for (i=0;;i++) {
<                       if ((dsc->dscr_a & M_DMA_ETHRX_SOP) != 0)
<                               break;
<                       if (i >= NAPI_LOP_MAX) goto ret;
<                       }
<               }*/
---
 >               if (curidx == hwidx)
 >                       break;
1392d1355
<               //__kfree_skb(sb); //try free fast
1433,1434c1396
<
<       int auxctl;
---
1455,1456d1416
<
<       s->sbm_phy_oldsignaldetect =0;
1478,1481d1438
<
<       /*
<        * Fiber/Copper Mode AutoDetection
<        */
1483,1489d1439
<       sbmac_mii_write(s,1,MII_AUXCTL,0x2007);
<       auxctl = sbmac_mii_read(s,1,MII_AUXCTL);
<       if(auxctl)
<               {
<                       s->sbm_fibermode=1;
<               }
<       else s->sbm_fibermode=0;
1686,1687d1635
<                      M_MAC_RXDMA_EN1 |
<                      M_MAC_TXDMA_EN1 |
2182c2107
<                * Receives on channel 0,1
---
 >                * Receives on channel 0
2198,2206c2123,2128
<        * (EOP_SEEN is part of M_MAC_INT_CHANNEL << S_MAC_RX_CH0)
<        */
<
<
<       if (isr & (M_MAC_INT_CHANNEL << S_MAC_RX_CH0)) {
< #ifdef CONFIG_SB1250_NAPI
<               if (netif_rx_schedule_prep(dev)) {
<                       sbmac_irq_disable(sc);
<                       __netif_rx_schedule(dev);
---
 >                * (EOP_SEEN is part of M_MAC_INT_CHANNEL << S_MAC_RX_CH0)
 >                */
 >
 >
 >               if (isr & (M_MAC_INT_CHANNEL << S_MAC_RX_CH0)) {
 >                       sbdma_rx_process(sc,&(sc->sbm_rxdma));
2208,2210d2129
< #else
<               sbdma_rx_process(sc,&(sc->sbm_rxdma));
< #endif
2213d2131
< }
2251,2268d2172
< #ifdef CONFIG_SB1250_NAPI
< //#define NAPI_POL_MAX 100
< static int sbmac_poll(struct net_device *dev_instance, int *budget) {
<       struct net_device *dev = (struct net_device *) dev_instance;
<     struct sbmac_softc *sc = (struct sbmac_softc *) (dev_instance->priv);
<     sbmacdma_t *d = &(sc->sbm_rxdma);
<     int rx_work_limit = *budget;
<       unsigned long flags;
<       long int receive=0;
<       int curidx;
<       int hwidx;
<
<       sbdmadscr_t *dsc;
<       struct sk_buff *sb;
<       int len;
<
<     if(rx_work_limit > dev->quota)
<           rx_work_limit = dev->quota;
2270,2382d2173
<     for (;;) {
<               if(--rx_work_limit < 0) goto not_done;
<               curidx = d->sbdma_remptr - d->sbdma_dscrtable;
<               hwidx = (int) (((SBMAC_READCSR(d->sbdma_curdscr) & 
M_DMA_CURDSCR_ADDR) -
<                               d->sbdma_dscrtable_phys) / 
sizeof(sbdmadscr_t));
<               if (curidx == hwidx) break;
<
<               dsc = &(d->sbdma_dscrtable[curidx]);
<               sb = d->sbdma_ctxtable[curidx];
<               d->sbdma_ctxtable[curidx] = NULL;
<
<               len = (int)G_DMA_DSCRB_PKT_SIZE(dsc->dscr_b) - 4;
<               if (!(dsc->dscr_a & M_DMA_ETHRX_BAD)) {
<
<
<                       if (sbdma_add_rcvbuffer(d,NULL) == -ENOBUFS) {
<                           sc->sbm_stats.rx_dropped++;
<                           sbdma_add_rcvbuffer(d,sb);  /* re-add old 
buffer */
<                           }
<                       else {
<                           /*
<                            * Set length into the packet
<                            */
<                           skb_put(sb,len);
<
<                           /*
<                            * Buffer has been replaced on the receive ring.
<                            * Pass the buffer to the kernel
<                            */
<                           sc->sbm_stats.rx_bytes += len;
<                           sc->sbm_stats.rx_packets++;receive++;
<                           sb->protocol = 
eth_type_trans(sb,d->sbdma_eth->sbm_dev);
<                             if (sc->rx_hw_checksum == ENABLE) {
<                           /* if the ip checksum is good indicate in skb.
<                               else set CHECKSUM_NONE as device failed to
<                                       checksum the packet */
<
<                              if (((dsc->dscr_b) |M_DMA_ETHRX_BADTCPCS) ||
<                                 ((dsc->dscr_a)| M_DMA_ETHRX_BADIP4CS)){
<                                 sb->ip_summed = CHECKSUM_NONE;
<                              } else {
<                                printk(KERN_DEBUG "hw checksum fail .\n");
<                                sb->ip_summed = CHECKSUM_UNNECESSARY;
<                              }
<                           } /*rx_hw_checksum */
<                             netif_receive_skb(sb);
<                           }
<               }
<               else {
<                       /*
<                        * Packet was mangled somehow.  Just drop it and
<                        * put it back on the receive ring.
<                        */
<                       sc->sbm_stats.rx_errors++;
<                       sbdma_add_rcvbuffer(d,sb);
<               }
<
<               d->sbdma_remptr = SBDMA_NEXTBUF(d,sbdma_remptr);
<
<       }
<       if (!receive) receive = 1;
<       dev->quota -= receive;
<       *budget -= receive;
<
<       spin_lock_irqsave(&sc->sbm_lock,flags);
<       netif_rx_complete(dev);
<         sbmac_irq_enable(sc);
<       spin_unlock_irqrestore(&sc->sbm_lock,flags);
<       return 0;
< not_done:
<       dev->quota -= receive;
<       *budget -= receive;
<       return 1;
< }
< #endif
2639,2642d2437
< #ifdef CONFIG_SB1250_NAPI
<         dev->poll       = sbmac_poll;
<         dev->weight     =dev->quota = 80;
< #endif
2646,2652c2441,2442
<       if (soc_pass >= K_SYS_REVISION_PASS3) {
<               /* In pass3 we do dumb checksum in TX */
<               dev->features |= NETIF_F_IP_CSUM;
<       }
<
<         /* This is needed for PASS2 for Rx H/W checksum feature */
<       sbmac_set_iphdr_offset( sc);
---
 >       /* This is needed for PASS2 for Rx H/W checksum feature */
 >       sbmac_set_iphdr_offset(sc);
2720,2723d2508
<       int signaldetect;
<
<       if(s->sbm_fibermode == 0)
<               {
< #ifdef CONFIG_NET_SB1250_MAC_QUIET
<     noisy = 0;
< #endif
2818,2852d2601
<    }
<    else
<       { //fiber mode
<
<       chg=0;
<       printk("sbm_phy_oldsignaldetect:%d\n",s->sbm_phy_oldsignaldetect);
<
<       signaldetect = (SGMIISR_FIBERSDS & 
sbmac_mii_read(s,s->sbm_phys[0],MII_SGMIISR));
<
<     printk("current signaldetect:%d\n",signaldetect);
<
<       if (signaldetect == 0)
<               {
<               printk("link state is DOWN!\n");
<               s->sbm_phy_oldsignaldetect = 0;
<               return 0;
<               }
<       else
<               {
<               if(s->sbm_phy_oldsignaldetect != signaldetect)
<               {
<               s->sbm_phy_oldsignaldetect = signaldetect;
<               chg = 1;
<               printk("link state has been changed\n");
<               }
<               }
<       if (chg==0) return 0;
<               printk("Link is up\n");
<               s->sbm_speed = sbmac_speed_1000;
<               s->sbm_duplex = sbmac_duplex_full;
<               s->sbm_fc = sbmac_fc_frame;
<               s->sbm_state = sbmac_state_on;
<       noisy =0;
<        printk("fiber mode.\t");
<       }
2865d2611
<       int signaldetect;
2868,2870c2614
<
<     if(sc->sbm_fibermode == 0)
<     {
2883,2899d2626
<     }
<     else
<     {
<       signaldetect = (SGMIISR_FIBERSDS & 
sbmac_mii_read(sc,sc->sbm_phys[0],MII_SGMIISR));
<               if(sc->sbm_phy_oldsignaldetect != signaldetect)
<               {
<                 sc->sbm_phy_oldsignaldetect = signaldetect;
<               if (signaldetect) {
<                  printk("netif_carrier_on. \n");
<                netif_carrier_on(dev);
<               }
<               else {
<                netif_carrier_off(dev);
<               }
<                 printk("link state has been changed\n");
<               }
<     }
2905,2915c2632,2642
<       if (sbmac_mii_poll(sc,1)) {
<           if (sc->sbm_state != sbmac_state_off) {
<               /*
<                * something changed, restart the channel
<                */
<               if (debug > 1) {
<                   printk("%s: restarting channel because speed changed\n",
<                          sc->sbm_dev->name);
<                   }
<               sbmac_channel_stop(sc);
<               sbmac_channel_start(sc);
---
 >       if (sbmac_mii_poll(sc,noisy_mii)) {
 >               if (sc->sbm_state != sbmac_state_off) {
 >                       /*
 >                        * something changed, restart the channel
 >                        */
 >                       if (debug > 1) {
 >                               printk("%s: restarting channel because 
speed changed\n",
 >                                      sc->sbm_dev->name);
 >                       }
 >                       sbmac_channel_stop(sc);
 >                       sbmac_channel_start(sc);
3163c2893
<               sbmac_init(dev);
---
 >               sbmac_init(dev, macidx);

----------------------------------------------------
and blow is the oops messages
----------------------------------------------------
May 28 14:16:04 netpower kernel: napi mac_irq disable.
May 28 14:16:04 netpower kernel: skput:over: 801dce38:2498 put:2498 
dev:eth2kern
el BUG at skbuff.c:92!
May 28 14:16:04 netpower kernel: Unable to handle kernel paging request 
at virtu
al address 00000000, epc == 801f1a5c, ra == 801dce4c
May 28 14:16:04 netpower kernel: Oops in fault.c::do_page_fault, line 219:
May 28 14:16:04 netpower kernel: $0 : 00000000 10001f00 0000001b 
00000000 000000
01 80cbe000 00000001 00000000
May 28 14:16:04 netpower kernel: $8 : 007d351a 00000000 00008001 
00000000 802f63
79 fffffffa 0000000a 802afc79
May 28 14:16:04 netpower kernel: $16: 8fe1b980 000009c2 8fe16a74 
8fe16960 8fe140
00 0000004f 00000000 8fe16800
May 28 14:16:04 netpower kernel: $24: ffffffff 
00000002                   802ae0
00 802afdb8 8fe16800 801dce4c
May 28 14:16:04 netpower kernel: Hi : 00000003
May 28 14:16:04 netpower kernel: Lo : 33333334
May 28 14:16:04 netpower kernel: epc  : 801f1a5c    Not tainted
May 28 14:16:04 netpower kernel: Status: 10001f03
May 28 14:16:04 netpower kernel: Cause : 1080000c
May 28 14:16:04 netpower kernel: Process swapper (pid: 0, 
stackpage=802ae000)
May 28 14:16:04 netpower kernel: Stack:    802993c0 802993d8 0000005c 
00000001 8
fe16800 8fe16960 801dce4c
May 28 14:16:04 netpower kernel:  80115490 00000000 2ac58da0 80296972 
8fe16968 8
fe168c0 8fe16800 00000001
May 28 14:16:04 netpower kernel:  802c11dc 802c11dc 802c11c0 00000000 
00016424 8
ffae460 801f7874 00000000
May 28 14:16:04 netpower kernel:  802afe20 8029695c 00000001 0000012c 
ffffffff 00000000 802c0c90 fffffffb
May 28 14:16:04 netpower kernel:  00000000 10001f00 802afea8 8ffd1208 
8fed1cb0 8011ae44 801037d4 8010bb34
May 28 14:16:04 netpower kernel:  00000037 ...
May 28 14:16:04 netpower kernel: Call Trace:   
[dm_head_vals.0+1568/4944] [dm_head_vals.0+1592/4944] 
[sbmac_poll+524/1240] [printk+608/688] [twist_table.0+3010/3712]
May 28 14:16:04 netpower kernel:  [net_rx_action+356/704] 
[twist_table.0+2988/3712] [do_softirq+228/440] 
[handle_IRQ_event+144/304] [local_timer_interrupt+152/164] [do_IRQ+316/372]
May 28 14:16:04 netpower kernel:  [sb1250_timer_interrupt+248/252] 
[sb1250_time_init+8/588] [cpu_idle+60/112] [cpu_idle+92/112] 
[init+0/468] [std_ide_release_region+204/2360]
May 28 14:16:04 netpower kernel:  [std_ide_release_region+268/2360]
May 28 14:16:04 netpower kernel:
May 28 14:16:04 netpower kernel: Code: 0c04548c  2406005c  8fbf0018 
<ac000000> 03e00008  27bd0020  3c02802a  244293e4  0807c68e
May 28 14:16:04 netpower kernel: Kernel panic: Aiee, killing interrupt 
handler!


 



From lindahl@keyresearch.com Thu May 29 08:21:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 May 2003 08:21:22 +0100 (BST)
Received: from 12-234-29-238.client.attbi.com ([IPv6:::ffff:12.234.29.238]:58754
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225200AbTE2HVU>; Thu, 29 May 2003 08:21:20 +0100
Received: from localhost.localdomain (greglaptop [127.0.0.1])
	by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h4T7LJ4H001615
	for <linux-mips@linux-mips.org>; Thu, 29 May 2003 00:21:19 -0700
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id h4T7LIYQ001613
	for linux-mips@linux-mips.org; Thu, 29 May 2003 00:21:18 -0700
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 29 May 2003 00:21:18 -0700
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: Hi, this is my patch for broadcom sb1250-mac.c
Message-ID: <20030529072118.GC1496@greglaptop.greghome.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <3ED586BE.9050906@netpower.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3ED586BE.9050906@netpower.com.cn>
User-Agent: Mutt/1.4.1i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2473
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

> May 28 14:16:04 netpower kernel: skput:over: 801dce38:2498 put:2498 
> dev:eth2kern
> el BUG at skbuff.c:92!

I think this is your clue:

eth2kernel BUG at skbuff.c:92

Go read the code -- it's a overrun for skb_put().

-- greg


From roy_maligro@hotmail.com Thu May 29 18:40:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 May 2003 18:40:27 +0100 (BST)
Received: from f49.sea2.hotmail.com ([IPv6:::ffff:207.68.165.49]:29457 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225213AbTE2RkZ>;
	Thu, 29 May 2003 18:40:25 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 29 May 2003 10:40:16 -0700
Received: from 202.78.97.15 by sea2fd.sea2.hotmail.msn.com with HTTP;
	Thu, 29 May 2003 17:40:16 GMT
X-Originating-IP: [202.78.97.15]
X-Originating-Email: [roy_maligro@hotmail.com]
From: "Roy Maligro" <roy_maligro@hotmail.com>
To: linux-mips@linux-mips.org
Subject: RE: linux on SHARP mips3000
Date: Fri, 30 May 2003 01:40:16 +0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <Sea2-F49gVtu8T3jJLR000136ee@hotmail.com>
X-OriginalArrivalTime: 29 May 2003 17:40:16.0488 (UTC) FILETIME=[5DAFF680:01C32609]
Return-Path: <roy_maligro@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: 2474
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: roy_maligro@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi,
  i have here a Handheld PC SHARP Telios with MIPS3000 family processor and 
installed a windows CE japanese. My problem is that i want to convert my HPC 
into a linux OS under MIPS family because i cannot understand a japanese 
language, i'm more on english side. This unit is only a gift for me of my 
japanese pal.
Is there any workaround to convert that into a linux? is it possible?. I'm 
basically less knowledge in linux. I hope you can give me some tips and idea 
how to install a linux in my HPC.
I'm very thankfull if you can help me.

Thanks! more power to linux-mips.org!


ROY

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


From kevink@mips.com Thu May 29 18:51:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 May 2003 18:51:09 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:33208 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225213AbTE2RvH>;
	Thu, 29 May 2003 18:51:07 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h4THopUe014489;
	Thu, 29 May 2003 10:50:51 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id KAA02582;
	Thu, 29 May 2003 10:50:51 -0700 (PDT)
Message-ID: <03a301c3260c$179d1760$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Roy Maligro" <roy_maligro@hotmail.com>,
	<linux-mips@linux-mips.org>
References: <Sea2-F49gVtu8T3jJLR000136ee@hotmail.com>
Subject: Re: linux on SHARP mips3000
Date: Thu, 29 May 2003 19:59:45 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2475
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips

http://www.sikigami.com/~fuku/linux-telios/index-en.html

----- Original Message ----- 
From: "Roy Maligro" <roy_maligro@hotmail.com>
To: <linux-mips@linux-mips.org>
Sent: Thursday, May 29, 2003 7:40 PM
Subject: RE: linux on SHARP mips3000


> Hi,
>   i have here a Handheld PC SHARP Telios with MIPS3000 family processor and 
> installed a windows CE japanese. My problem is that i want to convert my HPC 
> into a linux OS under MIPS family because i cannot understand a japanese 
> language, i'm more on english side. This unit is only a gift for me of my 
> japanese pal.
> Is there any workaround to convert that into a linux? is it possible?. I'm 
> basically less knowledge in linux. I hope you can give me some tips and idea 
> how to install a linux in my HPC.
> I'm very thankfull if you can help me.
> 
> Thanks! more power to linux-mips.org!
> 
> 
> ROY
> 
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online 
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> 
> 
> 

From zhanght@netpower.com.cn Thu May 29 19:50:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 May 2003 19:51:01 +0100 (BST)
Received: from [IPv6:::ffff:211.154.175.2] ([IPv6:::ffff:211.154.175.2]:38149
	"EHLO mail.netpower.com.cn") by linux-mips.org with ESMTP
	id <S8225215AbTE2Su6>; Thu, 29 May 2003 19:50:58 +0100
Received: from RavProxy [218.244.240.150] by mail.netpower.com.cn with ESMTP
  (SMTPD32-7.07) id A588E400B2; Fri, 30 May 2003 02:46:32 +0800
Date: Fri, 30 May 2003 2:43:35 +0800
From: "Zhang Haitao" <zhanght@netpower.com.cn>
Reply-To: zhanght@netpower.com.cn
To: Greg Lindahl <lindahl@keyresearch.com>
CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: Re: Re: Hi, this is my patch for broadcom sb1250-mac.c
Organization: netpower
X-mailer: Foxmail 4.1 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <200305300246578.SM00840@RavProxy>
Return-Path: <zhanght@netpower.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: 2476
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zhanght@netpower.com.cn
Precedence: bulk
X-list: linux-mips

Hi all
i've corrected some bugs in my last driver,
now the driver work properly both under copper mode and fiber mode. 
so this time i resend it in a more clear style :-)
and hope this time you all will glad to review it.
(you can turn off/on the NAPI options to do some contrast test 
for both original mode and NAPI mode, even the parameters for original mode 
have been modified for better performance)

and dear Greg Lindahl:
you just pointed out the function skb_over_panic(), but there are many reasons will lead that fault!
	  so i've tried to modified sbmac_mii_poll() and removed manually called 
netif_carrier_on() there, i think call netif_carrier_on() from here is the main reason lead my kernel
crashed. 
	as you know we use sbmac_mii_poll to set the link parameters but call netif_carrier_on() and netif_carrier_off() in sbmac_mii_timer(), so if i manualy call netif_carrier_on() to set LINK_STAT_START,
it will lead link status wrong! eg. sometimes that DMA channel have been stopped by other reasons, but driver can not find out that and skb can not be released in time, so an skb_over_panic() happen here.
so is that right?
waiting for your reply soon!

-------------------------
--- ./sb1250-broadcom.c	2003-05-30 00:48:36.000000000 +0800
+++ ./sb1250-mac.debug.c	2003-05-30 00:48:36.000000000 +0800
@@ -44,8 +44,8 @@
 static int full_duplex[MAX_UNITS] = {-1, -1, -1};
 #endif
 
-static int int_pktcnt = 0;
-static int int_timeout = 0;
+static int int_pktcnt = 32;
+static int int_timeout = 1024;
 
 /* Operational parameters that usually are not changed. */
 
@@ -91,7 +91,8 @@
 static char version1[] __devinitdata =
 "sb1250-mac.c:1.00 1/11/2001 Written by Mitch Lichtenberg (mpl@broadcom.com)\n";
 #endif
-
+#define CONFIG_SB1250_NAPI 
+#define NAPI_LOP_MAX 10
 
 
 MODULE_AUTHOR("Mitch Lichtenberg (mpl@broadcom.com)");
@@ -154,8 +155,8 @@
 
 #define PKSEG1(x) ((sbmac_port_t) KSEG1ADDR(x))
 
-#define SBMAC_MAX_TXDESCR	32
-#define SBMAC_MAX_RXDESCR	32
+#define SBMAC_MAX_TXDESCR	128
+#define SBMAC_MAX_RXDESCR	128
 
 #define ETHER_ALIGN	2
 #define ETHER_ADDR_LEN	6
@@ -190,8 +191,8 @@
 	int		 sbdma_txdir;       /* direction (1=transmit) */
 	int		 sbdma_maxdescr;	/* total # of descriptors in ring */
 #ifdef CONFIG_SBMAC_COALESCE
-        int              sbdma_int_pktcnt;  /* # descriptors rx/tx before interrupt*/
-        int              sbdma_int_timeout; /* # usec rx/tx interrupt */
+        int              sbdma_int_pktcnt;  /* # descriptors rx before interrupt*/
+        int              sbdma_int_timeout; /* # usec rx interrupt */
 #endif
 
 	sbmac_port_t     sbdma_config0;	/* DMA config register 0 */
@@ -262,11 +263,13 @@
 	
 	u_char           sbm_hwaddr[ETHER_ADDR_LEN];
 	
-	sbmacdma_t       sbm_txdma;		/* for now, only use channel 0 */
+	sbmacdma_t       sbm_txdma;		/* for now, use channel 0 */
 	sbmacdma_t       sbm_rxdma;
 	int              rx_hw_checksum;
 	int 		 sbe_idx;
 	
+	int              sbm_fibermode;
+	int 		 sbm_phy_oldsignaldetect;
 };
 
 
@@ -288,7 +291,6 @@
 static int sbdma_add_txbuffer(sbmacdma_t *d,struct sk_buff *m);
 static void sbdma_emptyring(sbmacdma_t *d);
 static void sbdma_fillring(sbmacdma_t *d);
-static void sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d);
 static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d);
 static int sbmac_initctx(struct sbmac_softc *s);
 static void sbmac_channel_start(struct sbmac_softc *s);
@@ -299,6 +301,13 @@
 static uint64_t sbmac_addr2reg(unsigned char *ptr);
 static void sbmac_intr(int irq,void *dev_instance,struct pt_regs *rgs);
 static int sbmac_start_tx(struct sk_buff *skb, struct net_device *dev);
+#ifdef CONFIG_SB1250_NAPI
+static int sbmac_poll(struct net_device *dev_instance, int *budget);
+static inline void sbmac_irq_disable(struct sbmac_softc *s);
+static inline void sbmac_irq_enable(struct sbmac_softc *s);
+#else
+static void sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d);
+#endif
 static void sbmac_setmulti(struct sbmac_softc *sc);
 static int sbmac_init(struct net_device *dev);
 static int sbmac_set_speed(struct sbmac_softc *s,sbmac_speed_t speed);
@@ -448,6 +457,15 @@
 #define PHYSUP_LINKUP	 0x04
 #define PHYSUP_FDX       0x02
 
+/* Added for Fiber mode detection 
+just read Signal Detect alternation */
+
+#define MII_AUXCTL      0x18   /* Auxiliary Control Register */
+
+#define MII_SGMIISR     0x0C    /* SGMII/100-X Status Register */
+
+#define SGMIISR_FIBERSDS	0x2000
+
 #define	MII_BMCR	0x00 	/* Basic mode control register (rw) */
 #define	MII_BMSR	0x01	/* Basic mode status register (ro) */
 #define MII_K1STSR	0x0A	/* 1K Status Register (ro) */
@@ -459,6 +477,17 @@
 #define ENABLE 		1
 #define DISABLE		0
 
+#ifdef CONFIG_SB1250_NAPI
+static inline void sbmac_irq_disable(struct sbmac_softc *s){
+         SBMAC_WRITECSR(s->sbm_imr, 
+		       ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_TX_CH0));
+}
+static inline void sbmac_irq_enable(struct sbmac_softc *s){
+	SBMAC_WRITECSR(s->sbm_imr,
+		       ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_TX_CH0) |
+		       ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_RX_CH0));
+}
+#endif
 /**********************************************************************
  *  SBMAC_MII_SYNC(s)
  *  
@@ -759,7 +788,7 @@
 	
 #ifdef CONFIG_SBMAC_COALESCE
         /*
-         * Setup Rx/Tx DMA coalescing defaults
+         * Setup RxTx DMA coalescing defaults
          */
 
 		if ( int_pktcnt ) {
@@ -944,7 +973,7 @@
 		sb_new = sb;
 		/* 
 		 * nothing special to reinit buffer, it's already aligned
-		 * and sb->data already points to a good place.
+		 * and sb->tail already points to a good place.
 		 */
 	}
 	
@@ -956,11 +985,11 @@
         /*
          * Do not interrupt per DMA transfer.
          */
-        dsc->dscr_a = KVTOPHYS(sb_new->data) |
+        dsc->dscr_a = KVTOPHYS(sb_new->tail) |
                 V_DMA_DSCRA_A_SIZE(NUMCACHEBLKS(pktsize+ETHER_ALIGN)) |
                 0;
 #else
-	dsc->dscr_a = KVTOPHYS(sb_new->data) |
+	dsc->dscr_a = KVTOPHYS(sb_new->tail) |
 		V_DMA_DSCRA_A_SIZE(NUMCACHEBLKS(pktsize+ETHER_ALIGN)) |
 		M_DMA_DSCRA_INTERRUPT;
 #endif
@@ -1045,16 +1074,17 @@
 	
 	phys = KVTOPHYS(sb->data);
 	ncb = NUMCACHEBLKS(length+(phys & (CACHELINESIZE-1)));
-	
+#ifdef CONFIG_SBMAC_COALESCE
+	/* do not interript per DMA transfer*/
 	dsc->dscr_a = phys | 
 		V_DMA_DSCRA_A_SIZE(ncb) |
-#ifdef CONFIG_SBMAC_COALESCE
-                0 |
+		M_DMA_ETHTX_SOP;
 #else
+	dsc->dscr_a = phys | 
+		V_DMA_DSCRA_A_SIZE(ncb) |
 		M_DMA_DSCRA_INTERRUPT |
-#endif
 		M_DMA_ETHTX_SOP;
-	
+#endif	
 	/* transmitting: set outbound options and length */
 
 	dsc->dscr_b = V_DMA_DSCRB_OPTIONS(K_DMA_ETHTX_APPENDCRC_APPENDPAD) |
@@ -1133,7 +1163,7 @@
 	}
 }
 
-
+#ifndef CONFIG_SB1250_NAPI
 /**********************************************************************
  *  SBDMA_RX_PROCESS(sc,d)
  *  
@@ -1181,6 +1211,14 @@
 		 */
 		
 		if (curidx == hwidx) break;
+		/*{
+			int i;
+			for (i=0;;i++) {
+			if ((dsc->dscr_a & M_DMA_ETHRX_SOP) != 0) 
+				break;
+			if (i >= NAPI_LOP_MAX) goto ret;
+			}
+		}*/
 		
 		/*
 		 * Otherwise, get the packet's sk_buff ptr back
@@ -1236,7 +1274,6 @@
 				 sb->ip_summed = CHECKSUM_UNNECESSARY;
 			       }
 			    } /*rx_hw_checksum */
-
 			    netif_rx(sb);
 			    }
 		}
@@ -1258,7 +1295,7 @@
 		
 	}
 }
-
+#endif
 
 
 /**********************************************************************
@@ -1352,6 +1389,7 @@
 		 */
 		
 		dev_kfree_skb_irq(sb);
+		//__kfree_skb(sb); //try free fast
 		
 		/* 
 		 * .. and advance to the next buffer.
@@ -1393,6 +1431,7 @@
 static int sbmac_initctx(struct sbmac_softc *s)
 {
 	
+	int auxctl;	
 	/* 
 	 * figure out the addresses of some ports 
 	 */
@@ -1414,6 +1453,8 @@
 	s->sbm_phy_oldk1stsr = 0;
 	s->sbm_phy_oldlinkstat = 0;
 	
+	s->sbm_phy_oldsignaldetect =0;
+	
 	/*
 	 * Initialize the DMA channels.  Right now, only one per MAC is used
 	 * Note: Only do this _once_, as it allocates memory from the kernel!
@@ -1421,7 +1462,6 @@
 	
 	sbdma_initctx(&(s->sbm_txdma),s,0,DMA_TX,SBMAC_MAX_TXDESCR);
 	sbdma_initctx(&(s->sbm_rxdma),s,0,DMA_RX,SBMAC_MAX_RXDESCR);
-	
 	/*
 	 * initial state is OFF
 	 */
@@ -1436,6 +1476,17 @@
 	s->sbm_duplex = sbmac_duplex_half;
 	s->sbm_fc = sbmac_fc_disabled;
 	
+	/*
+	 * Fiber/Copper Mode AutoDetection
+	 */
+	
+	sbmac_mii_write(s,1,MII_AUXCTL,0x2007);
+	auxctl = sbmac_mii_read(s,1,MII_AUXCTL);
+	if(auxctl)
+		{
+			s->sbm_fibermode=1;
+		}
+	else s->sbm_fibermode=0;
 	return 0;
 }
 
@@ -1632,6 +1683,8 @@
 	SBMAC_WRITECSR(s->sbm_macenable,
 		       M_MAC_RXDMA_EN0 |
 		       M_MAC_TXDMA_EN0 |
+		       M_MAC_RXDMA_EN1 |
+		       M_MAC_TXDMA_EN1 |
 		       M_MAC_RX_ENABLE |
 		       M_MAC_TX_ENABLE);
 	
@@ -1645,6 +1698,7 @@
 	SBMAC_WRITECSR(s->sbm_imr,
 		       ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_TX_CH0) |
 		       ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_RX_CH0));
+		       
 #else
 	/*
 	 * Accept any kind of interrupt on TX and RX DMA channel 0
@@ -1967,7 +2021,7 @@
 			V_MAC_IFG_TX_1000 |
 			V_MAC_IFG_THRSH_1000 |
 			V_MAC_SLOT_SIZE_1000;
-		cfg |= V_MAC_SPEED_SEL_1000MBPS | M_MAC_BURST_EN;
+cfg |= V_MAC_SPEED_SEL_1000MBPS | M_MAC_BURST_EN;
 		break;
 		
 	case sbmac_speed_auto:		/* XXX not implemented */
@@ -2102,6 +2156,7 @@
 {
 	struct net_device *dev = (struct net_device *) dev_instance;
 	struct sbmac_softc *sc = (struct sbmac_softc *) (dev->priv);
+
 	uint64_t isr;
 	
 	for (;;) {
@@ -2124,7 +2179,7 @@
 		}
 		
 		/*
-		 * Receives on channel 0
+		 * Receives on channel 0,1
 		 */
 
 		/*
@@ -2145,40 +2200,43 @@
 		 
 		
 		if (isr & (M_MAC_INT_CHANNEL << S_MAC_RX_CH0)) {
-			sbdma_rx_process(sc,&(sc->sbm_rxdma));
+#ifdef CONFIG_SB1250_NAPI
+		if (netif_rx_schedule_prep(dev)) {
+			sbmac_irq_disable(sc);
+			__netif_rx_schedule(dev);
 		}
+#else
+		sbdma_rx_process(sc,&(sc->sbm_rxdma));
+#endif	
 	}
-	
+}
 }
 
 
 /**********************************************************************
- *  SBMAC_START_TX(skb,dev)
- *  
- *  Start output on the specified interface.  Basically, we 
- *  queue as many buffers as we can until the ring fills up, or
- *  we run off the end of the queue, whichever comes first.
- *  
- *  Input parameters: 
- *  	   
- *  	   
- *  Return value:
- *  	   nothing
- ********************************************************************* */
+*  SBMAC_START_TX(skb,dev)
+*  
+*  Start output on the specified interface.  Basically, we 
+*  queue as many buffers as we can until the ring fills up, or
+*  we run off the end of the queue, whichever comes first.
+*  
+*  Input parameters: 
+*  	   
+*  	   
+*  Return value:
+*  	   nothing
+********************************************************************* */
 static int sbmac_start_tx(struct sk_buff *skb, struct net_device *dev)
 {
-	struct sbmac_softc *sc = (struct sbmac_softc *)dev->priv;
-	
-	/* lock eth irq */
-	spin_lock_irq (&sc->sbm_lock);
-	
-	/*
+struct sbmac_softc *sc = (struct sbmac_softc *)dev->priv;
+spin_lock_irq (&sc->sbm_lock);
+/*
 	 * Put the buffer on the transmit ring.  If we 
 	 * don't have room, stop the queue.
 	 */
 	
-	if (sbdma_add_txbuffer(&(sc->sbm_txdma),skb)) {
-		/* XXX save skb that we could not send */
+if (sbdma_add_txbuffer(&(sc->sbm_txdma),skb)) {
+		/* XXX save skb that we could not send, then test 1 channel */
 		netif_stop_queue(dev);
 		spin_unlock_irq(&sc->sbm_lock);
 
@@ -2186,12 +2244,142 @@
 	}
 	
 	dev->trans_start = jiffies;
-	
 	spin_unlock_irq (&sc->sbm_lock);
 	
 	return 0;
 }
+#ifdef CONFIG_SB1250_NAPI
+//#define NAPI_POL_MAX 100
+static int sbmac_poll(struct net_device *dev_instance, int *budget) {
+	struct net_device *dev = (struct net_device *) dev_instance;
+    struct sbmac_softc *sc = (struct sbmac_softc *) (dev_instance->priv);
+    sbmacdma_t *d = &(sc->sbm_rxdma);
+    int rx_work_limit = *budget;
+	unsigned long flags;
+	long int receive=0;
+	int curidx;
+	int hwidx;
+	
+	sbdmadscr_t *dsc;
+	struct sk_buff *sb;
+	int len;
+	
+    if(rx_work_limit > dev->quota)
+          rx_work_limit = dev->quota;
+
+    for (;;) {
+		/* 
+		 * figure out where we are (as an index) and where
+		 * the hardware is (also as an index)
+		 *
+		 * This could be done faster if (for example) the 
+		 * descriptor table was page-aligned and contiguous in
+		 * both virtual and physical memory -- you could then
+		 * just compare the low-order bits of the virtual address
+		 * (sbdma_remptr) and the physical address (sbdma_curdscr CSR)
+		 */
+		if(--rx_work_limit < 0) goto not_done;
+		curidx = d->sbdma_remptr - d->sbdma_dscrtable;
+		hwidx = (int) (((SBMAC_READCSR(d->sbdma_curdscr) & M_DMA_CURDSCR_ADDR) -
+				d->sbdma_dscrtable_phys) / sizeof(sbdmadscr_t));
+		
+		/*
+		 * If they're the same, that means we've processed all
+		 * of the descriptors up to (but not including) the one that
+		 * the hardware is working on right now.
+		 */
+		
+		if (curidx == hwidx) break;
+				
+		/*
+		 * Otherwise, get the packet's sk_buff ptr back
+		 */
+		
+		dsc = &(d->sbdma_dscrtable[curidx]);
+		sb = d->sbdma_ctxtable[curidx];
+		d->sbdma_ctxtable[curidx] = NULL;
+		
+		len = (int)G_DMA_DSCRB_PKT_SIZE(dsc->dscr_b) - 4;
 
+		/*
+		 * Check packet status.  If good, process it.
+		 * If not, silently drop it and put it back on the
+		 * receive ring.
+		 */
+		
+		if (!(dsc->dscr_a & M_DMA_ETHRX_BAD)) {
+			
+       			/*
+			 * Add a new buffer to replace the old one.  If we fail
+			 * to allocate a buffer, we're going to drop this
+			 * packet and put it right back on the receive ring.
+			 */
+			
+			if (sbdma_add_rcvbuffer(d,NULL) == -ENOBUFS) {
+			    sc->sbm_stats.rx_dropped++;
+			    sbdma_add_rcvbuffer(d,sb);	/* re-add old buffer */
+			    }
+			else {
+			    /*
+			     * Set length into the packet
+			     */
+			    skb_put(sb,len);
+
+			    /*
+			     * Buffer has been replaced on the receive ring.
+			     * Pass the buffer to the kernel
+			     */
+			    sc->sbm_stats.rx_bytes += len;
+			    sc->sbm_stats.rx_packets++;receive++;
+			    sb->protocol = eth_type_trans(sb,d->sbdma_eth->sbm_dev);
+                            if (sc->rx_hw_checksum == ENABLE) {
+			    /* if the ip checksum is good indicate in skb.
+		                else set CHECKSUM_NONE as device failed to
+					checksum the packet */
+
+			       if (((dsc->dscr_b) |M_DMA_ETHRX_BADTCPCS) ||
+			     	  ((dsc->dscr_a)| M_DMA_ETHRX_BADIP4CS)){
+				  sb->ip_summed = CHECKSUM_NONE;
+			       } else {
+				 printk(KERN_DEBUG "hw checksum fail .\n");
+				 sb->ip_summed = CHECKSUM_UNNECESSARY;
+			       }
+			    } /*rx_hw_checksum */
+                            netif_receive_skb(sb);
+			    }
+		}
+		else {
+			/*
+			 * Packet was mangled somehow.  Just drop it and
+			 * put it back on the receive ring.
+			 */
+			sc->sbm_stats.rx_errors++;
+			sbdma_add_rcvbuffer(d,sb);
+		}
+		
+		
+		/* 
+		 * .. and advance to the next buffer.
+		 */
+		
+		d->sbdma_remptr = SBDMA_NEXTBUF(d,sbdma_remptr);
+	
+	}
+	if (!receive) receive = 1;
+	dev->quota -= receive;
+	*budget -= receive;
+	
+	spin_lock_irqsave(&sc->sbm_lock,flags);
+	netif_rx_complete(dev);
+        sbmac_irq_enable(sc);
+	spin_unlock_irqrestore(&sc->sbm_lock,flags);
+	return 0;
+not_done:
+	dev->quota -= receive;
+	*budget -= receive;
+	return 1;
+}
+#endif
 /**********************************************************************
  *  SBMAC_SETMULTI(sc)
  *  
@@ -2448,6 +2636,10 @@
 	dev->do_ioctl           = sbmac_mii_ioctl;
 	dev->tx_timeout         = sbmac_tx_timeout;
 	dev->watchdog_timeo     = TX_TIMEOUT;
+#ifdef CONFIG_SB1250_NAPI
+        dev->poll       = sbmac_poll;
+        dev->weight     =dev->quota = 80;
+#endif
 
 	dev->change_mtu         = sb1250_change_mtu;
 
@@ -2525,6 +2717,10 @@
     char buffer[100];
     char *p = buffer;
 
+	int signaldetect;
+    
+	if(s->sbm_fibermode == 0)
+		{
     /* Read the mode status and mode control registers. */
     bmsr = sbmac_mii_read(s,s->sbm_phys[0],MII_BMSR);
     bmcr = sbmac_mii_read(s,s->sbm_phys[0],MII_BMCR);
@@ -2539,7 +2735,6 @@
     else {
 	k1stsr = 0;
 	}
-
     chg = 0;
 
     if ((bmsr & BMSR_LINKSTAT) == 0) {
@@ -2620,6 +2815,41 @@
 	    printk(KERN_INFO "%s: %s\n",s->sbm_dev->name,buffer);
 	    }
 
+   }
+   else 
+   	{ //fiber mode
+
+ 	chg=0;
+ 	printk("sbm_phy_oldsignaldetect:%d\n",s->sbm_phy_oldsignaldetect);
+ 	
+	signaldetect = (SGMIISR_FIBERSDS & sbmac_mii_read(s,s->sbm_phys[0],MII_SGMIISR));
+
+    printk("current signaldetect:%d\n",signaldetect);
+    
+   	if (signaldetect == 0)
+   		{
+   		printk("link state is DOWN!\n");
+		s->sbm_phy_oldsignaldetect = 0;
+		return 0;
+		}
+   	else 
+		{
+		if(s->sbm_phy_oldsignaldetect != signaldetect)
+   		{
+   		s->sbm_phy_oldsignaldetect = signaldetect;
+   		chg = 1;
+   		printk("link state has been changed\n");
+   		}
+		}
+   	if (chg==0) return 0;
+   		printk("Link is up\n");
+   		s->sbm_speed = sbmac_speed_1000;
+   		s->sbm_duplex = sbmac_duplex_full;
+   		s->sbm_fc = sbmac_fc_frame;
+   		s->sbm_state = sbmac_state_on;
+	noisy =0; 
+       printk("fiber mode.\t");
+ 	}  
     return 1;
 }
 
@@ -2632,9 +2862,12 @@
 	struct sbmac_softc *sc = (struct sbmac_softc *)dev->priv;
 	int next_tick = HZ;
 	int mii_status;
+	int signaldetect;
 
 	spin_lock_irq (&sc->sbm_lock);
 	
+    if(sc->sbm_fibermode == 0)
+    {	
 	/* make IFF_RUNNING follow the MII status bit "Link established" */
 	mii_status = sbmac_mii_read(sc, sc->sbm_phys[0], MII_BMSR);
 	
@@ -2647,6 +2880,23 @@
 			netif_carrier_off(dev);	
 		}
 	}
+    }
+    else
+    {
+	signaldetect = (SGMIISR_FIBERSDS & sbmac_mii_read(sc,sc->sbm_phys[0],MII_SGMIISR));
+              if(sc->sbm_phy_oldsignaldetect != signaldetect)
+              {
+                sc->sbm_phy_oldsignaldetect = signaldetect;
+		if (signaldetect) {
+                 printk("netif_carrier_on. \n");
+		 netif_carrier_on(dev);
+ 		}
+ 		else {
+		 netif_carrier_off(dev);
+ 		}
+                printk("link state has been changed\n");
+              }
+    }
 	
 	/*
 	 * Poll the PHY to see what speed we should be running at


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

Yours
Zhang Haitao
zhanght@netpower.com.cn
2003-05-30


======= 2003-05-29 00:21:00 =======

>> May 28 14:16:04 netpower kernel: skput:over: 801dce38:2498 put:2498 
>> dev:eth2kern
>> el BUG at skbuff.c:92!
>
>I think this is your clue:
>
>eth2kernel BUG at skbuff.c:92
>
>Go read the code -- it's a overrun for skb_put().
>
>-- greg

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




From lindahl@keyresearch.com Thu May 29 20:05:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 May 2003 20:06:00 +0100 (BST)
Received: from 66-122-194-201.ded.pacbell.net ([IPv6:::ffff:66.122.194.201]:12929
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225219AbTE2TF5>; Thu, 29 May 2003 20:05:57 +0100
Received: from localhost.localdomain (greglaptop [127.0.0.1])
	by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h4TJ618E001573
	for <linux-mips@linux-mips.org>; Thu, 29 May 2003 12:06:01 -0700
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id h4TJ614b001571
	for linux-mips@linux-mips.org; Thu, 29 May 2003 12:06:01 -0700
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 29 May 2003 12:06:01 -0700
From: Greg Lindahl <lindahl@keyresearch.com>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: Re: Hi, this is my patch for broadcom sb1250-mac.c
Message-ID: <20030529190601.GA1488@greglaptop.internal.keyresearch.com>
Mail-Followup-To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
References: <200305300246578.SM00840@RavProxy>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200305300246578.SM00840@RavProxy>
User-Agent: Mutt/1.4.1i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2477
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Fri, May 30, 2003 at 02:43:35AM +0800, Zhang Haitao wrote:

> and dear Greg Lindahl:
> you just pointed out the function skb_over_panic(), but there are
> many reasons will lead that fault!

It is not an obvious bug, but this is an important clue. If you then
look at skb_put (in include/linux/skbuff.h) you will find that you
have written beyond the end of a skbuf, or a stray pointer has damaged
the size of the skbuf. I would next put some debugging code before
every skb_put() call (there are only 2 in sbmac.c) to see if it will
overflow, and printk something if it is.

Any kernel bug that you can make happen repeatedly can be debugged in
this fashion.

-- greg


From erik@greendragon.org Thu May 29 22:37:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 May 2003 22:37:17 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:42637 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225219AbTE2VhP>;
	Thu, 29 May 2003 22:37:15 +0100
Received: from mahes.visi.com (mahes.visi.com [209.98.98.96])
	by mail-out.visi.com (Postfix) with ESMTP id 3F011371F
	for <linux-mips@linux-mips.org>; Thu, 29 May 2003 16:37:17 -0500 (CDT)
Received: from mahes.visi.com (localhost [127.0.0.1])
	by mahes.visi.com (8.12.9/8.12.5) with ESMTP id h4TLbAKe000869
	for <linux-mips@linux-mips.org>; Thu, 29 May 2003 16:37:10 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mahes.visi.com (8.12.9/8.12.5/Submit) id h4TLb9G1000868
	for linux-mips@linux-mips.org; Thu, 29 May 2003 21:37:09 GMT
X-Authentication-Warning: mahes.visi.com: www set sender to erik@greendragon.org using -f
Received: from stpns.guidant.com (stpns.guidant.com [132.189.76.10]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Thu, 29 May 2003 21:37:09 +0000
Message-ID: <1054244229.3ed67d85a0c39@my.visi.com>
Date: Thu, 29 May 2003 21:37:09 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: linux-mips@linux-mips.org
Subject: another handheld question
References: <Sea2-F49gVtu8T3jJLR000136ee@hotmail.com> <03a301c3260c$179d1760$10eca8c0@grendel>
In-Reply-To: <03a301c3260c$179d1760$10eca8c0@grendel>
MIME-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP: 132.189.76.10
Return-Path: <erik@greendragon.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2478
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips


As long as we're on the subject of pocket PCs, has anyone done anything for the
Fujitsu Pencentra 130?  I know NetBSD sort of runs on it, but I'm not sure if
they got anything but the console port working.

Erik




Quoting "Kevin D. Kissell" <kevink@mips.com>:

> http://www.sikigami.com/~fuku/linux-telios/index-en.html
> 
> ----- Original Message -----
> From: "Roy Maligro" <roy_maligro@hotmail.com>
> To: <linux-mips@linux-mips.org>
> Sent: Thursday, May 29, 2003 7:40 PM
> Subject: RE: linux on SHARP mips3000
> 
> 
> > Hi,
> >   i have here a Handheld PC SHARP Telios with MIPS3000 family processor and
> > installed a windows CE japanese. My problem is that i want to convert my
> HPC
> > into a linux OS under MIPS family because i cannot understand a japanese
> > language, i'm more on english side. This unit is only a gift for me of my
> > japanese pal.
> > Is there any workaround to convert that into a linux? is it possible?. I'm
> > basically less knowledge in linux. I hope you can give me some tips and
> idea
> > how to install a linux in my HPC.
> > I'm very thankfull if you can help me.
> >
> > Thanks! more power to linux-mips.org!
> >
> >
> > ROY
> >
> > _________________________________________________________________
> > Protect your PC - get McAfee.com VirusScan Online
> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> >
> >
> >


-- 
Erik J. Green
erik@greendragon.org

From kevink@mips.com Fri May 30 11:01:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 May 2003 11:01:29 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:28289 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225236AbTE3KBS>;
	Fri, 30 May 2003 11:01:18 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h4UA10Ue022714;
	Fri, 30 May 2003 03:01:01 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA23600;
	Fri, 30 May 2003 03:00:58 -0700 (PDT)
Message-ID: <00f201c32693$9f270b50$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Erik J. Green" <erik@greendragon.org>, <linux-mips@linux-mips.org>
References: <Sea2-F49gVtu8T3jJLR000136ee@hotmail.com> <03a301c3260c$179d1760$10eca8c0@grendel> <1054244229.3ed67d85a0c39@my.visi.com>
Subject: Re: another handheld question
Date: Fri, 30 May 2003 12:09:54 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2479
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips

I found the site for the Telios in 5 seconds with Google.
Have you done any searching at all on the Pencentra?

----- Original Message ----- 
From: "Erik J. Green" <erik@greendragon.org>
To: <linux-mips@linux-mips.org>
Sent: Thursday, May 29, 2003 11:37 PM
Subject: another handheld question


> 
> As long as we're on the subject of pocket PCs, has anyone done anything for the
> Fujitsu Pencentra 130?  I know NetBSD sort of runs on it, but I'm not sure if
> they got anything but the console port working.
> 
> Erik
> 
> 
> 
> 
> Quoting "Kevin D. Kissell" <kevink@mips.com>:
> 
> > http://www.sikigami.com/~fuku/linux-telios/index-en.html
> > 
> > ----- Original Message -----
> > From: "Roy Maligro" <roy_maligro@hotmail.com>
> > To: <linux-mips@linux-mips.org>
> > Sent: Thursday, May 29, 2003 7:40 PM
> > Subject: RE: linux on SHARP mips3000
> > 
> > 
> > > Hi,
> > >   i have here a Handheld PC SHARP Telios with MIPS3000 family processor and
> > > installed a windows CE japanese. My problem is that i want to convert my
> > HPC
> > > into a linux OS under MIPS family because i cannot understand a japanese
> > > language, i'm more on english side. This unit is only a gift for me of my
> > > japanese pal.
> > > Is there any workaround to convert that into a linux? is it possible?. I'm
> > > basically less knowledge in linux. I hope you can give me some tips and
> > idea
> > > how to install a linux in my HPC.
> > > I'm very thankfull if you can help me.
> > >
> > > Thanks! more power to linux-mips.org!
> > >
> > >
> > > ROY
> > >
> > > _________________________________________________________________
> > > Protect your PC - get McAfee.com VirusScan Online
> > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> > >
> > >
> > >
> 
> 
> -- 
> Erik J. Green
> erik@greendragon.org
> 
> 

From erik@greendragon.org Fri May 30 14:29:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 May 2003 14:29:22 +0100 (BST)
Received: from kauket.visi.com ([IPv6:::ffff:209.98.98.22]:60059 "HELO
	mail-out.visi.com") by linux-mips.org with SMTP id <S8225236AbTE3N3U>;
	Fri, 30 May 2003 14:29:20 +0100
Received: from mahes.visi.com (mahes.visi.com [209.98.98.96])
	by mail-out.visi.com (Postfix) with ESMTP id 1CFD53785
	for <linux-mips@linux-mips.org>; Fri, 30 May 2003 08:29:25 -0500 (CDT)
Received: from mahes.visi.com (localhost [127.0.0.1])
	by mahes.visi.com (8.12.9/8.12.5) with ESMTP id h4UDTHKe005902
	for <linux-mips@linux-mips.org>; Fri, 30 May 2003 08:29:17 -0500 (CDT)
	(envelope-from erik@greendragon.org)
Received: (from www@localhost)
	by mahes.visi.com (8.12.9/8.12.5/Submit) id h4UDTHrN005901
	for linux-mips@linux-mips.org; Fri, 30 May 2003 13:29:17 GMT
X-Authentication-Warning: mahes.visi.com: www set sender to erik@greendragon.org using -f
Received: from stpns.guidant.com (stpns.guidant.com [132.189.76.10]) 
	by my.visi.com (IMP) with HTTP 
	for <longshot@imap.visi.com>; Fri, 30 May 2003 13:29:17 +0000
Message-ID: <1054301357.3ed75cad71c14@my.visi.com>
Date: Fri, 30 May 2003 13:29:17 +0000
From: "Erik J. Green" <erik@greendragon.org>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: another handheld question
References: <Sea2-F49gVtu8T3jJLR000136ee@hotmail.com> <03a301c3260c$179d1760$10eca8c0@grendel> <1054244229.3ed67d85a0c39@my.visi.com> <00f201c32693$9f270b50$10eca8c0@grendel>
In-Reply-To: <00f201c32693$9f270b50$10eca8c0@grendel>
MIME-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP: 132.189.76.10
Return-Path: <erik@greendragon.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2480
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: erik@greendragon.org
Precedence: bulk
X-list: linux-mips

Quoting "Kevin D. Kissell" <kevink@mips.com>:

> I found the site for the Telios in 5 seconds with Google.
> Have you done any searching at all on the Pencentra?


Something like ~50 searches using multiple keywords, and found nothing but a few
vague mentions of people getting Netbsd to boot, or stating that Linux runs on
the 130.  No touchpad drivers/info, or any technical info on the Pencentra
hardware, which is what I really wanted.  

It's all well and good that the kernel boots using a bootloader from CE, but
it's much more useful if there are drivers for hardware other than the serial
port.  Hence the question here, in the heart of Linux/mips development, which
will tell me if I'm about to re-invent the wheel trying to get this thing up and
running.



Erik






> 
> ----- Original Message -----
> From: "Erik J. Green" <erik@greendragon.org>
> To: <linux-mips@linux-mips.org>
> Sent: Thursday, May 29, 2003 11:37 PM
> Subject: another handheld question
> 
> 
> >
> > As long as we're on the subject of pocket PCs, has anyone done anything for
> the
> > Fujitsu Pencentra 130?  I know NetBSD sort of runs on it, but I'm not sure
> if
> > they got anything but the console port working.
> >
> > Erik
> >
> >
> >
> >
> > Quoting "Kevin D. Kissell" <kevink@mips.com>:
> >
> > > http://www.sikigami.com/~fuku/linux-telios/index-en.html
> > >
> > > ----- Original Message -----
> > > From: "Roy Maligro" <roy_maligro@hotmail.com>
> > > To: <linux-mips@linux-mips.org>
> > > Sent: Thursday, May 29, 2003 7:40 PM
> > > Subject: RE: linux on SHARP mips3000
> > >
> > >
> > > > Hi,
> > > >   i have here a Handheld PC SHARP Telios with MIPS3000 family processor
> and
> > > > installed a windows CE japanese. My problem is that i want to convert
> my
> > > HPC
> > > > into a linux OS under MIPS family because i cannot understand a
> japanese
> > > > language, i'm more on english side. This unit is only a gift for me of
> my
> > > > japanese pal.
> > > > Is there any workaround to convert that into a linux? is it possible?.
> I'm
> > > > basically less knowledge in linux. I hope you can give me some tips and
> > > idea
> > > > how to install a linux in my HPC.
> > > > I'm very thankfull if you can help me.
> > > >
> > > > Thanks! more power to linux-mips.org!
> > > >
> > > >
> > > > ROY
> > > >
> > > > _________________________________________________________________
> > > > Protect your PC - get McAfee.com VirusScan Online
> > > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> > > >
> > > >
> > > >
> >
> >
> > --
> > Erik J. Green
> > erik@greendragon.org
> >
> >


-- 
Erik J. Green
erik@greendragon.org

From brad@patton.com Fri May 30 16:21:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 May 2003 16:22:02 +0100 (BST)
Received: from emma.patton.com ([IPv6:::ffff:209.49.110.2]:39184 "EHLO
	emma.patton.com") by linux-mips.org with ESMTP id <S8225236AbTE3PV6>;
	Fri, 30 May 2003 16:21:58 +0100
Received: from barrett ([209.49.110.172])
	by emma.patton.com (8.9.0/8.9.0) with SMTP id LAA24915;
	Fri, 30 May 2003 11:22:10 -0400 (EDT)
From: "Brad Barrett" <brad@patton.com>
To: "Thiemo Seufer" <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: "'Linux-Mips@Linux-Mips. Org'" <linux-mips@linux-mips.org>
Subject: RE: "relocation truncated to fit" -- SOLVED!
Date: Fri, 30 May 2003 11:21:53 -0400
Message-ID: <BBEBJGNKIDPPHNAJKDFHEEFDCJAA.brad@patton.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <20030527192643.GH18653@rembrandt.csv.ica.uni-stuttgart.de>
Importance: Normal
Return-Path: <brad@patton.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2481
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brad@patton.com
Precedence: bulk
X-list: linux-mips

I wanted to make sure I reported back my results...

I updated only binutils to the latest version (2.14.90.0.4), cleaned the source
trees, and rebuilt with success.  This saved me much time that might have been
spent on the -GN or -Wa,xgot workarounds (which might not even have worked).

So thanks a lot Thiemo!

Brad

-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Thiemo Seufer
Sent: Tuesday, May 27, 2003 3:27 PM
To: Brad Barrett
Cc: 'Linux-Mips@Linux-Mips. Org'
Subject: Re: "relocation truncated to fit"


Brad Barrett wrote:
> Preface:
> --------
> I have a userspace toolchain issue.  I'm not sure where to post it, so I'll
> start here.

binutils@sources.redhat.com is probably the better place for this.

[snip]
> I built the cross-tools myself.  They are now about 6-8 months old.  They
> consist of:
> - gcc version 3.2.1 20020903 (prerelease)
> - GNU ld version 2.13.90.0.10 20021010  [from H.J. Lu]
> - glibc version 2.2.5

An upgrade is IMHO the best solution:
gcc 3.3 will fix some "branch out of range" issues, and binutils
newer than 2.13.90.0.18 implement multigot. Both together should
solve the problem.

> What I know:
> ------------
> Googling hasn't turn up much, with the exception of an intriguing exchange
from
> Sept 2001  on this mailing list:

The GOT overflow problem is quite well known, it hits every largish
executable for O32 MIPS. Most notably Mozilla and parts of KDE were
affected, too.

> Petter Reinholdtsen reports similar messages when (native) compiling "a huge
C++
> program" (actually Opera) on an Indy:
> http://www.spinics.net/lists/mips/msg04568.html
>
> Wilbern Cobb suggests using -G4, -G2, or -G1, which Petter reports reduces the
> messages but does not eliminate them.

These reduce GOT usage at the expense of speed and size, so they
help a bit as workaround.

> Then Ryan Murray says that every static
> library used in the link, including libc_noshared.a and libgcc.a, must be
> compiled with -Wa,xgot.

Would also work, but is binary incompatible then.


Thiemo


From mw@izd.de Fri May 30 18:00:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 May 2003 18:00:37 +0100 (BST)
Received: from mail.securewebs.net ([IPv6:::ffff:80.190.40.19]:6929 "EHLO
	izd.de") by linux-mips.org with ESMTP id <S8225236AbTE3RAf> convert rfc822-to-8bit;
	Fri, 30 May 2003 18:00:35 +0100
Received: from so9 [80.132.168.241] by izd.de with ESMTP
  (SMTPD32-7.15) id AE2C12E0074; Fri, 30 May 2003 19:00:28 +0200
From: "Michael Weichselgartner" <mw@izd.de>
To: <linux-mips@linux-mips.org>
Subject: RaQ2+ NIC problem 2nd try
Date: Fri, 30 May 2003 19:00:28 +0200
Message-ID: <005d01c326cc$f9468c80$0300a8c0@so9>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Return-Path: <mw@izd.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: 2482
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mw@izd.de
Precedence: bulk
X-list: linux-mips

hello,

unfortunately i never got feedback to my problem allthough
i know many people have the same problem. So i will try it
again with additional information.

Used hardware: Cobalt RaQ2+, 256MB, Nevada CPU, Galileo Chipset
Used OS: Debian 3.0 Woody, Kernel 2.4.18/2.4.20/2.4.21

Problem: If i enable both nicīs network traffic stops after
a few minutes withour any error message.

No matter wether you use tulip as module or not. The higher
the kernel version the shorter the time until all networktraffic
stops. The server is still running and i can logon to the
serial console. Restarting networking solves the problem
until i connect with ssh, ftp or whatever and start to 
transfer data (even fast scrolling in midnight commander
kills the network traffic).

If load only one of the nicīs (tulip as module and only
one alias for modutils) everthing works great, fast and day
for day.

I spent weeks to locate the problem by reading the old
(original) source of the cobalttulip_raq driver (Kernel 2.0). 
But i am not able to see which patches have been merged into
the kernel 2.4.x because the entire format has changed.

The question is has someone fixed this bug?
Did the developers merge the cobalt specific changes?

I have seen a lot of information in the old drivers telling
the RaQ would not be DMA COHERENT and therefore needs
some cache flushing within the network driver. I cant
see such information in the current tulip driver (0.9.12 - 0.9.15).
Could this cause the freezing?

I realy do not know what else i can do. Any hints?

Your feedback is welcome.

Best regards

Michael


From n_gale@ok.ru Fri May 30 21:30:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 May 2003 21:30:08 +0100 (BST)
Received: from frontend3.aha.ru ([IPv6:::ffff:195.2.83.143]:33996 "EHLO
	frontend3.aha.ru") by linux-mips.org with ESMTP id <S8225237AbTE3UaG>;
	Fri, 30 May 2003 21:30:06 +0100
Received: from [195.2.83.134] (HELO backend4.aha.ru)
  by frontend3.aha.ru (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 3721699; Sat, 31 May 2003 00:29:57 +0400
Received: from [81.211.38.202] (account <n_gale@ok.ru>)
  by backend4.aha.ru (CommuniGate Pro WebUser 4.0.6/D1)
  with HTTP id 13584424; Sat, 31 May 2003 00:29:57 +0400
From: <n_gale@ok.ru>
Subject: DBAu1500 board flash downloading
To: ppopov@mvista.com, baitisj@evolution.com, linux-mips@linux-mips.org
X-Mailer: CommuniGate Pro Web Mailer v.4.0.6/D1
Date: Sat, 31 May 2003 00:29:57 +0400
Message-ID: <web-13584424@backend4.aha.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1251"; format="flowed"
Content-Transfer-Encoding: 8bit
Return-Path: <n_gale@ok.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: 2483
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: n_gale@ok.ru
Precedence: bulk
X-list: linux-mips

First Name: Serguei
Last Name: Soloviev
Email: n_gale@ok.ru
Company: 
Category: DBAu1500 board question

Dear sirs. Few days ago I started the work with DBAu1500 
but unfortunatly among included software toolchain I 
didn't find 
any utility to download startup code into clean flash.

Does anybody have any flash programming utility wich 
probably works via EJTAG to download code to DBAu-flash or 
if I have absolutely clean or bad written flash due to 
uncleanly interrupted programming process for example due 
to power fail I need to insert it to the programmer to 
download boot software? 
I can not belive that there is no any simple utility 
working via LPT-port to do this.
Pls. help me find such utility and a primitive sheme with 
one HC244 and few resistors how to solder an adapter from 
LPT to JTAG.

  Thank u in advance.

---
Professional hosting for everyone - http://www.host.ru

From baitisj@idealab.com Fri May 30 22:45:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 May 2003 22:45:41 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:4013 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225237AbTE3Vpj>;
	Fri, 30 May 2003 22:45:39 +0100
Received: (qmail 30151 invoked by uid 6180); 30 May 2003 21:45:35 -0000
Date: Fri, 30 May 2003 14:45:35 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: n_gale@ok.ru
Cc: linux-mips@linux-mips.org
Subject: Re: DBAu1500 board flash downloading
Message-ID: <20030530144535.T29389@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <web-13584424@backend4.aha.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <web-13584424@backend4.aha.ru>; from n_gale@ok.ru on Sat, May 31, 2003 at 12:29:57AM +0400
Return-Path: <baitisj@idealab.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2484
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

Serguei:

Rather than building an EJTAG interface, I recommend the Raven EJTAG interface.
It plugs into your LPT port, and will plug into the EJTAG interface on your
DBAu1500 board.

The device is available through {http://www.macraigor.com}.

Linux software for this device is available at {http://www.ocdemon.com/}.

I assume that you will probably be trying to re-load YAMON onto the flash
device. I never tried re-loading YAMON, so I cannot comment about problems you
might have hear.


But here's the path that I essentially followed. I co-authored a bootloader
that can execute out of RAM, and wrote a driver for the AMD flash device.  My
bootloader uses a chunk of hacked-up YAMON code so that an SREC can be loaded
through serial, and I wrote a simple driver for AMD mirror-bit flash.

The trick was to set the CP0 configuration registers over GDB so that you can
load a bootloader into RAM, and then jump to the appropriate start address.

1. Plug in the RAVEN, turn it on.

2. Set the CP0 configuration registers through GDB so that RAM will refresh
   properly.

3. Load bootloader into uncached RAM through GDB and tell GDB to jump to
   the bootloader entry point.

4. Use the bootloader to erase flash.

5. The bootloader can also load an SREC through the serial port, and write it
   to flash. In your case, you would load YAMON.srec, and then write it to
   flash.

Good luck. Hopefully AMD support will be able to help you, too.

-Jeff



On Sat, May 31, 2003 at 12:29:57AM +0400, n_gale@ok.ru wrote:
> First Name: Serguei
> Last Name: Soloviev
> Email: n_gale@ok.ru
> Company: 
> Category: DBAu1500 board question
> 
> Dear sirs. Few days ago I started the work with DBAu1500 
> but unfortunatly among included software toolchain I 
> didn't find 
> any utility to download startup code into clean flash.
> 
> Does anybody have any flash programming utility wich 
> probably works via EJTAG to download code to DBAu-flash or 
> if I have absolutely clean or bad written flash due to 
> uncleanly interrupted programming process for example due 
> to power fail I need to insert it to the programmer to 
> download boot software? 
> I can not belive that there is no any simple utility 
> working via LPT-port to do this.
> Pls. help me find such utility and a primitive sheme with 
> one HC244 and few resistors how to solder an adapter from 
> LPT to JTAG.
> 
>   Thank u in advance.
> 
> ---
> Professional hosting for everyone - http://www.host.ru
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com