From macro@ds2.pg.gda.pl Wed Oct  1 04:58:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Oct 2003 04:58:24 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:56021 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225200AbTJAD6T>; Wed, 1 Oct 2003 04:58:19 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id FAA21101;
	Wed, 1 Oct 2003 05:58:17 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 1 Oct 2003 05:58:16 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: "Finney, Steve" <Steve.Finney@SpirentCom.COM>,
	linux-mips@linux-mips.org
Subject: Re: 64 bit operations w/32 bit kernel
In-Reply-To: <20030930184755.GA12599@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1031001055324.20371B-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: 3340
X-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, 30 Sep 2003, Ralf Baechle wrote:

> What I called a bug is the necessity to access hardware registers with
> 64-bit loads and stores in some systems as opposed to of 32-bit
> instructions - that simply doesn't work from 32-bit universes.
> 
> To clarify, it was my understanding of Steve's problem he needs 64-bit
> loads and stores, not something in the 64-bit physical address space.
> The later problem obviously would get a different answer.

 I must have missed the detail.  Well, if 64-bit transfers are needed,
then going for the 64-bit kernel is about the only way.  Or, as a wild
hack, perhaps "ldc1" and "sdc1" can be used, if it's known the FP is
present.

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


From macro@ds2.pg.gda.pl Wed Oct  1 05:26:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Oct 2003 05:26:09 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:31702 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225200AbTJAE0H>; Wed, 1 Oct 2003 05:26:07 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id GAA21337;
	Wed, 1 Oct 2003 06:26:03 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 1 Oct 2003 06:26:02 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Michael Uhler <uhler@mips.com>
cc: Ralf Baechle <ralf@linux-mips.org>,
	"Finney, Steve" <Steve.Finney@spirentcom.com>,
	linux-mips@linux-mips.org
Subject: Re: 64 bit operations w/32 bit kernel
In-Reply-To: <1064950055.12992.99.camel@uhler-linux.mips.com>
Message-ID: <Pine.GSO.3.96.1031001055849.20371C-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: 3341
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On 30 Sep 2003, Michael Uhler wrote:

> >  Well, I think this is OK -- 64-bit opcodes are generally useless for
> > software built for the o32 ABI, so they should not normally happen in
> > regular code.  Perhaps some fancy hand-coded assembly might try to use
> > them to get unusual results, including an invalid opcode trap handler for
> > the processors that do not support them at all.  But I don't think we
> > should try to work hard to prevent broken software from shooting into its
> > foot.
> 
> I'm not a real fan of architecting software to dismiss broken (or rogue)
> programs since it tends to open up a whole lot of holes that cause
> O/S crashes.  For instance, an o32 program should never be able to pass
> a non-sign-extended value thru a GPR to the O/S in a system call.  How
> many places in the O/S implicitly assume this is true?  The architecture

 That actually we get right -- the arguments at the stack are obviously
32-bit and the ones in argument registers are explicitly sign-extended
from their 32 LSBs in our syscall prologue for o32 syscalls.

> was never intended to run real 32-bit programs with 64-bit ops enabled,
> and I would strongly urge you not to do this now.

 After a bit of thinking, I consider this not to be a real problem.  Apart
from the kernel interface, which sanitizes values passed, the rest is pure
userland, where allowing undefined operation with 64-bit opcodes cannot
really hurt.  Of course running a buggy or malicious program may lead to
bad results or loss of data, but it'll be limited to the user responsible
for running such software and the root user by definition has to know what
he is doing and specifically he is responsible for not running untrusted
software on critical systems.

 That said, I don't really have a strong preference either way -- it just
doesn't seem to be worth the hassle for me to explicitly defend against
such a marginal case.  Although it may be good to try validating this
assumption with `crashme'. 

  Maciej

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


From tovbin@niisi.msk.ru Wed Oct  1 09:20:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Oct 2003 09:20:07 +0100 (BST)
Received: from [IPv6:::ffff:193.232.173.35] ([IPv6:::ffff:193.232.173.35]:56823
	"EHLO tux.NIISI") by linux-mips.org with ESMTP id <S8225200AbTJAIUA>;
	Wed, 1 Oct 2003 09:20:00 +0100
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tux.NIISI (8.11.6/8.11.6) with ESMTP id h918I4d21482
	for <linux-mips@linux-mips.org>; Wed, 1 Oct 2003 12:18:06 +0400
Date: Wed, 1 Oct 2003 12:18:04 +0400 (MSD)
From: Tommy Tovbin <tovbin@niisi.msk.ru>
X-X-Sender: tovbin@tux.NIISI
To: linux-mips@linux-mips.org
Subject: Problem with depmod
Message-ID: <Pine.LNX.4.44.0310011211090.21478-100000@tux.NIISI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <tovbin@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3342
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tovbin@niisi.msk.ru
Precedence: bulk
X-list: linux-mips


Hi, I've recompiled whole RedHat 7.3 on MIPS. Well, when I try to startup 
my system I`m getting an error like this:

Finding module dependencies:  depmod: cannot read ELF header from 
/lib/modules/2.4.18/modules.dep
depmod: cannot read ELF header from 
/lib/modules/2.4.18/modules.generic_string
depmod: /lib/modules/2.4.18/modules.ieee1394map is not an ELF file
depmod: /lib/modules/2.4.18/modules.isapnpmap is not an ELF file
depmod: cannot read ELF header from /lib/modules/2.4.18/modules.parportmap
depmod: /lib/modules/2.4.18/modules.pcimap is not an ELF file
depmod: cannot read ELF header from /lib/modules/2.4.18/modules.pnpbiosmap
depmod: /lib/modules/2.4.18/modules.usbmap is not an ELF file
[FAILED]

Can somebody help me?

PS: I've got the NULL modules.dep, because I havn't any modules, but I 
need kernel with LKM support.

Thx.

-- 
With regards, Tommy Tovbin. tovbin at niisi dot msk dot ru.
	Zz
       zZ
    |\ z    _,,,---,,_ /,`.-'`'_ ;-;;,_
   |,4-  ) )-,_..;\ (  `'_'
  '---''(_/--'  `-'\_)


From D.Mierzejewski@icm.edu.pl Wed Oct  1 12:02:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Oct 2003 12:02:16 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:28698 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225371AbTJALCM>;
	Wed, 1 Oct 2003 12:02:12 +0100
Received: from burza.icm.edu.pl (burza.icm.edu.pl [192.168.1.198])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.5/icm) with ESMTP id h91B0Xq6002347;
	Wed, 1 Oct 2003 13:02:02 +0200 (CEST)
Received: from rekin.icm.edu.pl (mail@rekin.icm.edu.pl [192.168.1.132])
	by burza.icm.edu.pl (8.12.9/8.12.9/rzm-2.9.3/icm) with ESMTP id h91AiO1e021524;
	Wed, 1 Oct 2003 12:44:25 +0200 (CEST)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1A4eSx-0005HF-00; Wed, 01 Oct 2003 12:44:19 +0200
Date: Wed, 1 Oct 2003 12:44:14 +0200
From: "Dominik 'Rathann' Mierzejewski" <D.Mierzejewski@icm.edu.pl>
To: linux-mips@linux-mips.org
Cc: Guido Guenther <agx@sigxcpu.org>
Subject: Re: [Indy] text console
Message-ID: <20031001104413.GA16929@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org,
	Guido Guenther <agx@sigxcpu.org>
References: <20030926122012.GC19876@icm.edu.pl> <20030930112541.GE26507@icm.edu.pl> <20030930135846.GB761@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030930135846.GB761@bogon.ms20.nix>
User-Agent: Mutt/1.3.28i
Return-Path: <D.Mierzejewski@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3343
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: D.Mierzejewski@icm.edu.pl
Precedence: bulk
X-list: linux-mips

On Tue, Sep 30, 2003 at 03:58:46PM +0200, Guido Guenther wrote:
> On Tue, Sep 30, 2003 at 01:25:42PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> > Doesn't anyone know? Please help or say it's impossible. I'm
> > stuck with 1280x1024@60Hz which is very uncomfortable to my
> > eyes.
> Try the "monitor" PROM variable to switch to 1024x768. See:
>  http://www.parallab.uib.no/SGI_bookshelves/SGI_Admin/books/IA_ConfigOps/sgi_html/ch09.html#LE63851-PARENT

Thanks. I've also found this page:
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/0650/bks/SGI_Admin/books/IA_ConfigOps/sgi_html/ch09.html#LE63851-PARENT
which appears to be the same, though.

They say nothing about supported values of the "monitor" variable in
PROM. After googling around I tried to "setenv monitor l", but it
doesn't seem to have any effect. A few people on the usenet say it's
possible to change the resolution only from within IRIX.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>

From kaos@sgi.com Wed Oct  1 12:48:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Oct 2003 12:49:05 +0100 (BST)
Received: from mail.ocs.com.au ([IPv6:::ffff:203.34.97.2]:46094 "HELO
	mail.ocs.com.au") by linux-mips.org with SMTP id <S8225371AbTJALsw>;
	Wed, 1 Oct 2003 12:48:52 +0100
Received: (qmail 24194 invoked from network); 1 Oct 2003 11:48:42 -0000
Received: from ocs3.intra.ocs.com.au (192.168.255.3)
  by mail.ocs.com.au with SMTP; 1 Oct 2003 11:48:42 -0000
Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331)
	id D25D9C02B9; Wed,  1 Oct 2003 21:48:41 +1000 (EST)
Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1])
	by ocs3.intra.ocs.com.au (Postfix) with ESMTP
	id A66F2140111; Wed,  1 Oct 2003 21:48:41 +1000 (EST)
X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4
From: Keith Owens <kaos@sgi.com>
To: Tommy Tovbin <tovbin@niisi.msk.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: Problem with depmod 
In-reply-to: Your message of "Wed, 01 Oct 2003 12:18:04 +0400."
             <Pine.LNX.4.44.0310011211090.21478-100000@tux.NIISI> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 01 Oct 2003 21:48:40 +1000
Message-ID: <3680.1065008920@ocs3.intra.ocs.com.au>
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-archive-position: 3344
X-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 Wed, 1 Oct 2003 12:18:04 +0400 (MSD), 
Tommy Tovbin <tovbin@niisi.msk.ru> wrote:
>
>Hi, I've recompiled whole RedHat 7.3 on MIPS. Well, when I try to startup 
>my system I`m getting an error like this:
>
>Finding module dependencies:  depmod: cannot read ELF header from 
>/lib/modules/2.4.18/modules.dep

Short answer: 'mkdir /lib/modules/2.4.18/kernel' or 'make modules_install'.

Long answer: You can feed depmod multiple module directories, so depmod
has to look for directory 'kernel' to work out the top level of each tree.
modules.dep and the other text files are only ignored at the top level
of each tree.  You have no 'kernel' directory under /lib/modules/2.4.18
so depmod does not ignore the text files.


From tovbin@niisi.msk.ru Wed Oct  1 14:36:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Oct 2003 14:36:34 +0100 (BST)
Received: from [IPv6:::ffff:193.232.173.35] ([IPv6:::ffff:193.232.173.35]:11770
	"EHLO tux.NIISI") by linux-mips.org with ESMTP id <S8225396AbTJANgX>;
	Wed, 1 Oct 2003 14:36:23 +0100
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tux.NIISI (8.11.6/8.11.6) with ESMTP id h91DYQd30390;
	Wed, 1 Oct 2003 17:34:26 +0400
Date: Wed, 1 Oct 2003 17:34:26 +0400 (MSD)
From: Tommy Tovbin <tovbin@niisi.msk.ru>
X-X-Sender: tovbin@tux.NIISI
To: Keith Owens <kaos@sgi.com>
cc: linux-mips@linux-mips.org, <raiko@niisi.msk.ru>
Subject: Re: Problem with depmod 
In-Reply-To: <3680.1065008920@ocs3.intra.ocs.com.au>
Message-ID: <Pine.LNX.4.44.0310011729080.30245-100000@tux.NIISI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <tovbin@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3346
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tovbin@niisi.msk.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 988
Lines: 34

On Wed, 1 Oct 2003, Keith Owens wrote:

> On Wed, 1 Oct 2003 12:18:04 +0400 (MSD), 
> Tommy Tovbin <tovbin@niisi.msk.ru> wrote:
> >
> >Hi, I've recompiled whole RedHat 7.3 on MIPS. Well, when I try to startup 
> >my system I`m getting an error like this:
> >
> >Finding module dependencies:  depmod: cannot read ELF header from 
> >/lib/modules/2.4.18/modules.dep
> 
> Short answer: 'mkdir /lib/modules/2.4.18/kernel' or 'make modules_install'.

> 
> Long answer: You can feed depmod multiple module directories, so depmod
> has to look for directory 'kernel' to work out the top level of each tree.
> modules.dep and the other text files are only ignored at the top level
> of each tree.  You have no 'kernel' directory under /lib/modules/2.4.18
> so depmod does not ignore the text files.
> 
> 
> 

Thanks a lot! 


-- 
With regards, Tommy Tovbin. tovbin at niisi dot msk dot ru.
	Zz
       zZ
    |\ z    _,,,---,,_ /,`.-'`'_ ;-;;,_
   |,4-  ) )-,_..;\ (  `'_'
  '---''(_/--'  `-'\_)


From AdeelM@avaznet.com Wed Oct  1 16:05:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Oct 2003 16:05:51 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:9963
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225396AbTJAPFs>; Wed, 1 Oct 2003 16:05:48 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <TPC4VW1M>; Wed, 1 Oct 2003 19:58:47 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264EE5C@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Subject: SREC utility
Date: Wed, 1 Oct 2003 19:58:46 +0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3882C.83EA1320"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3347
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2606
Lines: 57

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

------_=_NextPart_001_01C3882C.83EA1320
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
 
I have a binary file in Motorola's SREC format. The address field in each
S-record (S3) has a specific address value for a device such as an SDRAM. I
need to change the SREC file for mapping to another memory device located at
some other memory address. I want to have a utility that can convert the
SREC format file generated for some particular address range to another SREC
file generated for some other address range. I mean that utility should only
change the address field  and checksum field of my S-RECORD and modify it
for another address range. The utility should not change the data field of
S-Records anyhow.
 
Regards,
ADEEL MALIK,
 


------_=_NextPart_001_01C3882C.83EA1320
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial" hb_focus_attach="true">
<DIV><FONT size=2>
<DIV><SPAN class=153004814-01102003><FONT size=2>Hi All,</FONT></SPAN></DIV>
<DIV><SPAN class=153004814-01102003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=153004814-01102003><FONT size=2>I have a binary file in 
Motorola's SREC format. The address field in each S-record (S3) has a specific 
address value for a device such as an SDRAM. I&nbsp;need to change the SREC file 
for mapping to another memory device located at some other memory address. I 
want to have a utility that can convert the SREC format file generated for some 
particular&nbsp;address range to another SREC file generated for some other 
address range. I mean that utility should only change the 
<STRONG><U>address</U></STRONG> field&nbsp; and 
<U><STRONG>checksum</STRONG></U>&nbsp;field of my S-RECORD and modify it for 
another address range. The utility should not change the 
<STRONG><U>data</U></STRONG> field of S-Records anyhow.</FONT></SPAN></DIV>
<DIV><SPAN class=153004814-01102003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=153004814-01102003><FONT size=2>Regards,</FONT></SPAN></DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM>ADEEL 
MALIK,</EM></FONT></DIV></FONT></DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM></EM></FONT>&nbsp;</DIV>
<P></P></BODY></HTML>

------_=_NextPart_001_01C3882C.83EA1320--

From dkesselr@mmc.atmel.com Wed Oct  1 16:27:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Oct 2003 16:27:46 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:22575
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225396AbTJAP1h>; Wed, 1 Oct 2003 16:27:37 +0100
Received: from hydra.mmc.atmel.com (hydra.mmc.atmel.com [10.127.240.58])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id LAA05151
	for <linux-mips@linux-mips.org>; Wed, 1 Oct 2003 11:27:29 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by hydra.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id LAA07881
	for <linux-mips@linux-mips.org>; Wed, 1 Oct 2003 11:27:29 -0400 (EDT)
X-Authentication-Warning: hydra.mmc.atmel.com: dkesselr owned process doing -bs
Date: Wed, 1 Oct 2003 11:27:29 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: sound drivers
Message-ID: <Pine.GSO.4.44.0310011123390.7534-100000@hydra.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3348
X-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
Content-Length: 260
Lines: 8

Has anyone used alsa on mips? I need to impement a sound driver for our
dsp. It seems like all sound drivers should be developed for alsa. Is that
true? I've tried to build alsa and its' drivers but ran into a cross
compile problem.
Thanks,

David Kesselring


From ralf@linux-mips.org Wed Oct  1 17:24:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Oct 2003 17:24:28 +0100 (BST)
Received: from p508B5290.dip.t-dialin.net ([IPv6:::ffff:80.139.82.144]:64905
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225401AbTJAQY0>; Wed, 1 Oct 2003 17:24:26 +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 h91GOMNK008563;
	Wed, 1 Oct 2003 18:24:22 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h91GOK0X008562;
	Wed, 1 Oct 2003 18:24:20 +0200
Date: Wed, 1 Oct 2003 18:24:20 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Michael Uhler <uhler@mips.com>,
	"Finney, Steve" <Steve.Finney@spirentcom.com>,
	linux-mips@linux-mips.org
Subject: Re: 64 bit operations w/32 bit kernel
Message-ID: <20031001162420.GA28892@linux-mips.org>
References: <1064950055.12992.99.camel@uhler-linux.mips.com> <Pine.GSO.3.96.1031001055849.20371C-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.1031001055849.20371C-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: 3349
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1110
Lines: 23

On Wed, Oct 01, 2003 at 06:26:02AM +0200, Maciej W. Rozycki wrote:

> > was never intended to run real 32-bit programs with 64-bit ops enabled,
> > and I would strongly urge you not to do this now.
> 
>  After a bit of thinking, I consider this not to be a real problem.  Apart
> from the kernel interface, which sanitizes values passed, the rest is pure
> userland, where allowing undefined operation with 64-bit opcodes cannot
> really hurt.  Of course running a buggy or malicious program may lead to
> bad results or loss of data, but it'll be limited to the user responsible
> for running such software and the root user by definition has to know what
> he is doing and specifically he is responsible for not running untrusted
> software on critical systems.
> 
>  That said, I don't really have a strong preference either way -- it just
> doesn't seem to be worth the hassle for me to explicitly defend against
> such a marginal case.  Although it may be good to try validating this
> assumption with `crashme'. 

It's a while since this last has been done and all bugs showing up were
fixed ...

  Ralf

From jsun@mvista.com Thu Oct  2 00:50:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 00:50:29 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:7927 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225423AbTJAXu1>;
	Thu, 2 Oct 2003 00:50:27 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h91NoN929739;
	Wed, 1 Oct 2003 16:50:23 -0700
Date: Wed, 1 Oct 2003 16:50:23 -0700
From: Jun Sun <jsun@mvista.com>
To: Craig Mautner <craig.mautner@alumni.ucsd.edu>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: schedule() BUG
Message-ID: <20031001165023.A26517@mvista.com>
References: <JKEMLDJFFLGLICKLLEFJMEEOCOAA.craig.mautner@alumni.ucsd.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <JKEMLDJFFLGLICKLLEFJMEEOCOAA.craig.mautner@alumni.ucsd.edu>; from craig.mautner@alumni.ucsd.edu on Fri, Sep 12, 2003 at 11:04:16AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3350
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Sep 12, 2003 at 11:04:16AM -0700, Craig Mautner wrote:
> We are using mips-linux 2.4.17, gcc 3.2.1 (MontaVista) and crashing in
> schedule():
>
> Unable to handle kernel paging request at virtual address 00000000, epc ==
> 800153c0, ra == 800153c0
> $0 : 00000000 9001f800 0000001b 00000000 0000001a 83f56000 8298f4a0 0000001f
> $8 : 00000001 ffffe2e0 000022e0 00000000 fffffff9 ffffffff 0000000a 00000002
> $16: 00000000 00000000 82af0000 8298f4a0 83f56000 00000000 80008000 00000000
> $24: 82af1dc2 00000002                   82af0000 82af1ef8 82af1ef8 800153c0
> epc  : 800153c0    Not tainted
> 
> The code is:
> 
>     {
>       struct mm_struct *mm = next->mm;
>       struct mm_struct *oldmm = prev->active_mm;
>       if (!mm) {
>            if (next->active_mm) BUG();   <- this is where we crash
>            next->active_mm = oldmm;
>            atomic_inc(&oldmm->mm_count);
>            enter_lazy_tlb(oldmm, next, this_cpu);
>       }
>         .
>         .
>         .
> 
> This seems to happen in our case when 'next' points to 'kswapd' although we
> think it could happen when switching to any kernel task (i.e. those tasks
> with mm==NULL).
> 
> We think the culprit is that we are taking an interrupt and rescheduling
> while at a vulnerable point in 'schedule()'. Interrupts are enabled in line
> 743. If we get an interrupt any time after line 785:
> 
>            next->active_mm = oldmm;
> 
> but before line 806
> 
> 	__schedule_tail()
> 
> completes the swap, the interrupt can force 'schedule()' to be reentered via
> 'ret_from_intr()'.
> 
> If so, 'kswapd's 'active_mm' field will be left non-zero, but 'current' will
> not have been set to point to 'kswapd'. The next time 'schedule()' tries to
> switch to 'kswapd', 'next' points to 'kswapd', and
> 
>         next->mm == NULL
>         next->active_mm != NULL
> 
> which is detected as an invalid state, so we hit the BUG.
> 
> Some questions:
> 	Are we looking at this correctly?
> 	Has anyone ever seen this before?
> 	Is there a published fix?
> 
> Thanks,
> 
> -Craig
> 

This is an known problem.  Please try the attached patch.

On R5432 CPU, there is also an hardware bug which can cause the same
problem.  Please double-check vec3_generic to see if workaround is 
at the beginning of the handler.

BTW, 2.4.17 is an old kernel. You really need to upgrade.

Jun

From ralf@linux-mips.org Thu Oct  2 01:09:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 01:09:40 +0100 (BST)
Received: from p508B5290.dip.t-dialin.net ([IPv6:::ffff:80.139.82.144]:16549
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225423AbTJBAJi>; Thu, 2 Oct 2003 01:09:38 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h9209XNK018210;
	Thu, 2 Oct 2003 02:09:33 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9209VkW018209;
	Thu, 2 Oct 2003 02:09:31 +0200
Date: Thu, 2 Oct 2003 02:09:31 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: Craig Mautner <craig.mautner@alumni.ucsd.edu>,
	linux-mips@linux-mips.org
Subject: Re: schedule() BUG
Message-ID: <20031002000930.GA3264@linux-mips.org>
References: <JKEMLDJFFLGLICKLLEFJMEEOCOAA.craig.mautner@alumni.ucsd.edu> <20031001165023.A26517@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031001165023.A26517@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: 3351
X-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, Oct 01, 2003 at 04:50:23PM -0700, Jun Sun wrote:

> This is an known problem.  Please try the attached patch.

No patch attached :-)

  Ralf

From jsun@mvista.com Thu Oct  2 01:39:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 01:39:35 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:52467 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225428AbTJBAjd>;
	Thu, 2 Oct 2003 01:39:33 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h920dVO29910;
	Wed, 1 Oct 2003 17:39:31 -0700
Date: Wed, 1 Oct 2003 17:39:31 -0700
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Craig Mautner <craig.mautner@alumni.ucsd.edu>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: schedule() BUG
Message-ID: <20031001173931.B26517@mvista.com>
References: <JKEMLDJFFLGLICKLLEFJMEEOCOAA.craig.mautner@alumni.ucsd.edu> <20031001165023.A26517@mvista.com> <20031002000930.GA3264@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20031002000930.GA3264@linux-mips.org>; from ralf@linux-mips.org on Thu, Oct 02, 2003 at 02:09:31AM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3352
X-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


--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Oct 02, 2003 at 02:09:31AM +0200, Ralf Baechle wrote:
> On Wed, Oct 01, 2003 at 04:50:23PM -0700, Jun Sun wrote:
> 
> > This is an known problem.  Please try the attached patch.
> 
> No patch attached :-)
>

Doh!  Here you go.

Jun

--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="vmalloc-fault-with-no-active-mm.patch"

diff -Nru link/arch/mips/mm/fault.c.orig link/arch/mips/mm/fault.c
--- link/arch/mips/mm/fault.c.orig	Fri May 10 18:50:08 2002
+++ link/arch/mips/mm/fault.c	Fri May 23 10:39:10 2003
@@ -260,7 +260,7 @@
 		pgd_t *pgd, *pgd_k;
 		pmd_t *pmd, *pmd_k;
 
-		pgd = tsk->active_mm->pgd + offset;
+		pgd = (pgd_t *) pgd_current[smp_processor_id()] + offset;
 		pgd_k = init_mm.pgd + offset;
 
 		if (!pgd_present(*pgd)) {

--tThc/1wpZn/ma/RB--

From vbridgers@bandspeed.com Thu Oct  2 02:28:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 02:28:25 +0100 (BST)
Received: from mail.bandspeed.com ([IPv6:::ffff:64.132.226.131]:19050 "EHLO
	mars.bandspeed.com") by linux-mips.org with ESMTP
	id <S8225427AbTJBB2X>; Thu, 2 Oct 2003 02:28:23 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38884.738D0E78"
Subject: Kernel Profile Patch for Au1x00?
Date: Wed, 1 Oct 2003 20:28:15 -0500
Message-ID: <F2DE90354F0ED94EB7061060D9396547B98A5C@mars.bandspeed.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Kernel Profile Patch for Au1x00?
thread-index: AcOIhHOCORV/+iqaRZWHM2ealEqyiQ==
From: "Vince Bridgers" <vbridgers@bandspeed.com>
To: <linux-mips@linux-mips.org>
Return-Path: <vbridgers@bandspeed.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3353
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vbridgers@bandspeed.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C38884.738D0E78
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is there a kernel profile patch that anyone is aware of for the AMD
(Alchemy) part Au1000/Au1500? If not, can anyone provide info on a good
starting point to start a port?
=20
TIA,
=20
Vince
=20
=20

------_=_NextPart_001_01C38884.738D0E78
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C3885A.8AAAA820">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Is there a kernel profile patch that anyone is aware =
of for
the AMD (Alchemy) part Au1000/Au1500? If not, can anyone provide info on =
a good
starting point to start a port?<o:p></o:p></span></font></p>

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

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

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

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

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

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

</div>

</body>

</html>
=00
------_=_NextPart_001_01C38884.738D0E78--

From jeff_lee@coventive.com Thu Oct  2 02:50:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 02:50:36 +0100 (BST)
Received: from 202-145-53-89.adsl.ttn.net ([IPv6:::ffff:202.145.53.89]:17558
	"EHLO miao.coventive.com") by linux-mips.org with ESMTP
	id <S8225430AbTJBBue>; Thu, 2 Oct 2003 02:50:34 +0100
Received: from jefflee (PC193.ia.kh.coventive.com [192.168.23.193] (may be forged))
	by miao.coventive.com (8.11.6/8.11.6) with SMTP id h921oD709379;
	Thu, 2 Oct 2003 09:50:14 +0800
Message-ID: <032601c38888$67cf6240$c117a8c0@jefflee>
From: "jeff" <jeff_lee@coventive.com>
To: "David Kesselring" <dkesselr@mmc.atmel.com>,
	<linux-mips@linux-mips.org>
References: <Pine.GSO.4.44.0310011123390.7534-100000@hydra.mmc.atmel.com>
Subject: Re: sound drivers
Date: Thu, 2 Oct 2003 09:56:31 +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.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <jeff_lee@coventive.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3354
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jeff_lee@coventive.com
Precedence: bulk
X-list: linux-mips

What CPU are you using ?
We are under development about ALSA on VR4181A but still can't work.
Only playback is OK. Capture is failed.

Regards,

Jeff
----- Original Message ----- 
From: "David Kesselring" <dkesselr@mmc.atmel.com>
To: <linux-mips@linux-mips.org>
Sent: Wednesday, October 01, 2003 11:27 PM
Subject: sound drivers


> Has anyone used alsa on mips? I need to impement a sound driver for our
> dsp. It seems like all sound drivers should be developed for alsa. Is that
> true? I've tried to build alsa and its' drivers but ran into a cross
> compile problem.
> Thanks,
>
> David Kesselring
>


From drow@crack.them.org Thu Oct  2 05:28:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 05:28:29 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:59033 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225205AbTJBE2M>;
	Thu, 2 Oct 2003 05:28:12 +0100
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
	id 1A4v4P-0005zM-FJ; Thu, 02 Oct 2003 00:28:05 -0400
Date: Thu, 2 Oct 2003 00:28:05 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Jun Sun <jsun@mvista.com>
Cc: Craig Mautner <craig.mautner@alumni.ucsd.edu>,
	linux-mips@linux-mips.org
Subject: Re: schedule() BUG
Message-ID: <20031002042803.GA16208@nevyn.them.org>
References: <JKEMLDJFFLGLICKLLEFJMEEOCOAA.craig.mautner@alumni.ucsd.edu> <20031001165023.A26517@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031001165023.A26517@mvista.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3355
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Wed, Oct 01, 2003 at 04:50:23PM -0700, Jun Sun wrote:
> On Fri, Sep 12, 2003 at 11:04:16AM -0700, Craig Mautner wrote:
> > We are using mips-linux 2.4.17, gcc 3.2.1 (MontaVista) and crashing in
> > schedule():
> >
> > Unable to handle kernel paging request at virtual address 00000000, epc ==
> > 800153c0, ra == 800153c0
> > $0 : 00000000 9001f800 0000001b 00000000 0000001a 83f56000 8298f4a0 0000001f
> > $8 : 00000001 ffffe2e0 000022e0 00000000 fffffff9 ffffffff 0000000a 00000002
> > $16: 00000000 00000000 82af0000 8298f4a0 83f56000 00000000 80008000 00000000
> > $24: 82af1dc2 00000002                   82af0000 82af1ef8 82af1ef8 800153c0
> > epc  : 800153c0    Not tainted
> > 
> > The code is:
> > 
> >     {
> >       struct mm_struct *mm = next->mm;
> >       struct mm_struct *oldmm = prev->active_mm;
> >       if (!mm) {
> >            if (next->active_mm) BUG();   <- this is where we crash
> >            next->active_mm = oldmm;
> >            atomic_inc(&oldmm->mm_count);
> >            enter_lazy_tlb(oldmm, next, this_cpu);
> >       }
> >         .
> >         .
> >         .
> > 
> > This seems to happen in our case when 'next' points to 'kswapd' although we
> > think it could happen when switching to any kernel task (i.e. those tasks
> > with mm==NULL).
> > 
> > We think the culprit is that we are taking an interrupt and rescheduling
> > while at a vulnerable point in 'schedule()'. Interrupts are enabled in line
> > 743. If we get an interrupt any time after line 785:
> > 
> >            next->active_mm = oldmm;
> > 
> > but before line 806
> > 
> > 	__schedule_tail()
> > 
> > completes the swap, the interrupt can force 'schedule()' to be reentered via
> > 'ret_from_intr()'.
> > 
> > If so, 'kswapd's 'active_mm' field will be left non-zero, but 'current' will
> > not have been set to point to 'kswapd'. The next time 'schedule()' tries to
> > switch to 'kswapd', 'next' points to 'kswapd', and
> > 
> >         next->mm == NULL
> >         next->active_mm != NULL
> > 
> > which is detected as an invalid state, so we hit the BUG.
> > 
> > Some questions:
> > 	Are we looking at this correctly?
> > 	Has anyone ever seen this before?
> > 	Is there a published fix?
> > 
> > Thanks,
> > 
> > -Craig
> > 
> 
> This is an known problem.  Please try the attached patch.
> 
> On R5432 CPU, there is also an hardware bug which can cause the same
> problem.  Please double-check vec3_generic to see if workaround is 
> at the beginning of the handler.
> 
> BTW, 2.4.17 is an old kernel. You really need to upgrade.

By the way, in 2.6 the include of <asm/war.h> has vanished from
genex.S.  If you want the workaround to be compiled, then you need to
re-add that.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From anemo@mba.ocn.ne.jp Thu Oct  2 06:42:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 06:43:07 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:59398
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225208AbTJBFmf>; Thu, 2 Oct 2003 06:42:35 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for [62.254.210.162]) with SMTP; 2 Oct 2003 05:42:33 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h925gNgc014467
	for <linux-mips@linux-mips.org>; Thu, 2 Oct 2003 14:42:24 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 02 Oct 2003 14:45:08 +0900 (JST)
Message-Id: <20031002.144508.122621824.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org
Subject: time(2) for mips64
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 3356
X-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

Should mips64 kernel support time(2) system call for n32/n64 ABI?

Both 2.4 and 2.6 kernel define __NR_time and use sys_time.  But
sys_time in kernel/time.c is not 64-bit clean.

We should remove definition of __NR_time from unistd.h (and sys_time
from scall_64.S), or implement local version of sys_time.

Which way to go?
---
Atsushi Nemoto

From dkesselr@mmc.atmel.com Thu Oct  2 14:06:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 14:06:28 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:25248
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225360AbTJBNGZ>; Thu, 2 Oct 2003 14:06:25 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA16750;
	Thu, 2 Oct 2003 09:06:12 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA08506;
	Thu, 2 Oct 2003 09:06:12 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Thu, 2 Oct 2003 09:06:12 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: jeff <jeff_lee@coventive.com>
cc: linux-mips@linux-mips.org
Subject: Re: sound drivers
In-Reply-To: <032601c38888$67cf6240$c117a8c0@jefflee>
Message-ID: <Pine.GSO.4.44.0310020901500.8498-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3357
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

I just beginning to develop drivers for our SOC that includes a 5kf and
our own custom dsp for audio playback. The target market is the settop. Am
I correct in thinking that all audio drivers (mpeg,mp3,pcm) should be
integrated with ALSA? When you say "still can't work" are you getting it
compile with the linux-mips.org sources or something else?
Thanks,
David

On Thu, 2 Oct 2003, jeff wrote:

> What CPU are you using ?
> We are under development about ALSA on VR4181A but still can't work.
> Only playback is OK. Capture is failed.
>
> Regards,
>
> Jeff
> ----- Original Message -----
> From: "David Kesselring" <dkesselr@mmc.atmel.com>
> To: <linux-mips@linux-mips.org>
> Sent: Wednesday, October 01, 2003 11:27 PM
> Subject: sound drivers
>
>
> > Has anyone used alsa on mips? I need to impement a sound driver for our
> > dsp. It seems like all sound drivers should be developed for alsa. Is that
> > true? I've tried to build alsa and its' drivers but ran into a cross
> > compile problem.
> > Thanks,
> >
> > David Kesselring
> >
>
>

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


From macro@ds2.pg.gda.pl Thu Oct  2 14:07:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 14:07:34 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:14227 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225360AbTJBNHb>; Thu, 2 Oct 2003 14:07:31 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA15362;
	Thu, 2 Oct 2003 15:07:21 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 2 Oct 2003 15:07:20 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
cc: linux-mips@linux-mips.org
Subject: Re: time(2) for mips64
In-Reply-To: <20031002.144508.122621824.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.GSO.3.96.1031002150528.15189A-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: 3358
X-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, 2 Oct 2003, Atsushi Nemoto wrote:

> Should mips64 kernel support time(2) system call for n32/n64 ABI?

 time(2) is obsolete (by gettimeofday(2)) and should be removed for new
implementations.

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


From jeff_lee@coventive.com Thu Oct  2 14:44:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 14:44:13 +0100 (BST)
Received: from 202-145-53-89.adsl.ttn.net ([IPv6:::ffff:202.145.53.89]:4759
	"EHLO miao.coventive.com") by linux-mips.org with ESMTP
	id <S8225360AbTJBNoJ>; Thu, 2 Oct 2003 14:44:09 +0100
Received: from jefflee (PC193.ia.kh.coventive.com [192.168.23.193] (may be forged))
	by miao.coventive.com (8.11.6/8.11.6) with SMTP id h92Dhc710254;
	Thu, 2 Oct 2003 21:43:38 +0800
Message-ID: <04a701c388ec$10b9b050$c117a8c0@jefflee>
From: "jeff" <jeff_lee@coventive.com>
To: "David Kesselring" <dkesselr@mmc.atmel.com>
Cc: <linux-mips@linux-mips.org>
References: <Pine.GSO.4.44.0310020901500.8498-100000@ares.mmc.atmel.com>
Subject: Re: sound drivers
Date: Thu, 2 Oct 2003 21:49:56 +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.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <jeff_lee@coventive.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3359
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jeff_lee@coventive.com
Precedence: bulk
X-list: linux-mips

In here, we can use madplay to play MP3, vplay to run WAV file, etc.
Yes, we get the kernel source from linux-mips.org but we porting the ALSA
driver base on many others code. For example, we will refer the VIA
, StrongARM, ESS.... source code and combine to VR4181A ALSA
driver. BUT..... Capture still can't work :-(

Regards,

Jeff
----- Original Message ----- 
From: "David Kesselring" <dkesselr@mmc.atmel.com>
To: "jeff" <jeff_lee@coventive.com>
Cc: <linux-mips@linux-mips.org>
Sent: Thursday, October 02, 2003 9:06 PM
Subject: Re: sound drivers


> I just beginning to develop drivers for our SOC that includes a 5kf and
> our own custom dsp for audio playback. The target market is the settop. Am
> I correct in thinking that all audio drivers (mpeg,mp3,pcm) should be
> integrated with ALSA? When you say "still can't work" are you getting it
> compile with the linux-mips.org sources or something else?
> Thanks,
> David
>
> On Thu, 2 Oct 2003, jeff wrote:
>
> > What CPU are you using ?
> > We are under development about ALSA on VR4181A but still can't work.
> > Only playback is OK. Capture is failed.
> >
> > Regards,
> >
> > Jeff
> > ----- Original Message -----
> > From: "David Kesselring" <dkesselr@mmc.atmel.com>
> > To: <linux-mips@linux-mips.org>
> > Sent: Wednesday, October 01, 2003 11:27 PM
> > Subject: sound drivers
> >
> >
> > > Has anyone used alsa on mips? I need to impement a sound driver for
our
> > > dsp. It seems like all sound drivers should be developed for alsa. Is
that
> > > true? I've tried to build alsa and its' drivers but ran into a cross
> > > compile problem.
> > > Thanks,
> > >
> > > David Kesselring
> > >
> >
> >
>
> David Kesselring
> Atmel MMC
> dkesselr@mmc.atmel.com
> 919-462-6587
>


From anemo@mba.ocn.ne.jp Thu Oct  2 15:26:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Oct 2003 15:26:36 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:8934 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225402AbTJBO0E>; Thu, 2 Oct 2003 15:26:04 +0100
Received: from localhost (p7045-ip01funabasi.chiba.ocn.ne.jp [219.162.24.45])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id C105147BF; Thu,  2 Oct 2003 23:25:01 +0900 (JST)
Date: Thu, 02 Oct 2003 23:41:16 +0900 (JST)
Message-Id: <20031002.234116.74756712.anemo@mba.ocn.ne.jp>
To: macro@ds2.pg.gda.pl
Cc: linux-mips@linux-mips.org
Subject: Re: time(2) for mips64
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.GSO.3.96.1031002150528.15189A-100000@delta.ds2.pg.gda.pl>
References: <20031002.144508.122621824.nemoto@toshiba-tops.co.jp>
	<Pine.GSO.3.96.1031002150528.15189A-100000@delta.ds2.pg.gda.pl>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 3360
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Thu, 2 Oct 2003 15:07:20 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:

macro>  time(2) is obsolete (by gettimeofday(2)) and should be removed
macro> for new implementations.

Then could you apply these patches?

for 2.4:

diff -ur linux-mips-cvs/arch/mips64/kernel/scall_64.S linux.new/arch/mips64/kernel/scall_64.S
--- linux-mips-cvs/arch/mips64/kernel/scall_64.S	Tue Aug 26 23:41:57 2003
+++ linux.new/arch/mips64/kernel/scall_64.S	Thu Oct  2 23:15:23 2003
@@ -326,7 +326,7 @@
 	PTR	sys_lremovexattr		/* 5190 */
 	PTR	sys_fremovexattr
 	PTR	sys_tkill
-	PTR	sys_time
+	PTR	sys_ni_syscall
 	PTR	sys_ni_syscall			/* res. for futex */
 	PTR	sys_ni_syscall			/* 5195 rs. sched_setaffinity */
 	PTR	sys_ni_syscall			/* res. f. sched_getaffinity */
diff -ur linux-mips-cvs/arch/mips64/kernel/scall_n32.S linux.new/arch/mips64/kernel/scall_n32.S
--- linux-mips-cvs/arch/mips64/kernel/scall_n32.S	Tue Aug 26 23:41:58 2003
+++ linux.new/arch/mips64/kernel/scall_n32.S	Thu Oct  2 23:15:40 2003
@@ -326,7 +326,7 @@
 	PTR	sys_lremovexattr		/* 6190 */
 	PTR	sys_fremovexattr
 	PTR	sys_tkill
-	PTR	sys_time
+	PTR	sys_ni_syscall
 	PTR	sys_ni_syscall			/* res. for futex */
 	PTR	sys_ni_syscall			/* 6195 rs. sched_setaffinity */
 	PTR	sys_ni_syscall			/* res. f. sched_getaffinity */
diff -ur linux-mips-cvs/include/asm-mips64/unistd.h linux.new/include/asm-mips64/unistd.h
--- linux-mips-cvs/include/asm-mips64/unistd.h	Wed Sep 17 23:22:41 2003
+++ linux.new/include/asm-mips64/unistd.h	Thu Oct  2 23:13:19 2003
@@ -461,7 +461,7 @@
 #define __NR_lremovexattr		(__NR_Linux + 190)
 #define __NR_fremovexattr		(__NR_Linux + 191)
 #define __NR_tkill			(__NR_Linux + 192)
-#define __NR_time			(__NR_Linux + 193)
+#define __NR_unused193			(__NR_Linux + 193)
 #define __NR_futex			(__NR_Linux + 194)
 #define __NR_sched_setaffinity		(__NR_Linux + 195)
 #define __NR_sched_getaffinity		(__NR_Linux + 196)


And for 2.6:

diff -ur linux-mips-2.6-cvs/arch/mips/kernel/scall64-64.S linux-2.6.new/arch/mips/kernel/scall64-64.S
--- linux-mips-2.6-cvs/arch/mips/kernel/scall64-64.S	Sun Aug 31 20:14:45 2003
+++ linux-2.6.new/arch/mips/kernel/scall64-64.S	Thu Oct  2 23:21:18 2003
@@ -398,7 +398,7 @@
 	PTR	sys_lremovexattr		/* 5190 */
 	PTR	sys_fremovexattr
 	PTR	sys_tkill
-	PTR	sys_time
+	PTR	sys_ni_syscall
 	PTR	sys_futex
 	PTR	sys_sched_setaffinity		/* 5195 */
 	PTR	sys_sched_getaffinity
diff -ur linux-mips-2.6-cvs/arch/mips/kernel/scall64-n32.S linux-2.6.new/arch/mips/kernel/scall64-n32.S
--- linux-mips-2.6-cvs/arch/mips/kernel/scall64-n32.S	Sun Aug 31 20:14:45 2003
+++ linux-2.6.new/arch/mips/kernel/scall64-n32.S	Thu Oct  2 23:21:55 2003
@@ -303,7 +303,7 @@
 	PTR	sys_lremovexattr		/* 6190 */
 	PTR	sys_fremovexattr
 	PTR	sys_tkill
-	PTR	sys_time
+	PTR	sys_ni_syscall
 	PTR	compat_sys_futex
 	PTR	sys32_sched_setaffinity		/* 6195 */
 	PTR	sys32_sched_getaffinity
diff -ur linux-mips-2.6-cvs/include/asm-mips/unistd.h linux-2.6.new/include/asm-mips/unistd.h
--- linux-mips-2.6-cvs/include/asm-mips/unistd.h	Thu Jul 31 22:55:59 2003
+++ linux-2.6.new/include/asm-mips/unistd.h	Thu Oct  2 23:20:02 2003
@@ -498,7 +498,7 @@
 #define __NR_lremovexattr		(__NR_Linux + 190)
 #define __NR_fremovexattr		(__NR_Linux + 191)
 #define __NR_tkill			(__NR_Linux + 192)
-#define __NR_time			(__NR_Linux + 193)
+#define __NR_reserved193		(__NR_Linux + 193)
 #define __NR_futex			(__NR_Linux + 194)
 #define __NR_sched_setaffinity		(__NR_Linux + 195)
 #define __NR_sched_getaffinity		(__NR_Linux + 196)
@@ -742,7 +742,7 @@
 #define __NR_lremovexattr		(__NR_Linux + 190)
 #define __NR_fremovexattr		(__NR_Linux + 191)
 #define __NR_tkill			(__NR_Linux + 192)
-#define __NR_time			(__NR_Linux + 193)
+#define __NR_reserved193		(__NR_Linux + 193)
 #define __NR_futex			(__NR_Linux + 194)
 #define __NR_sched_setaffinity		(__NR_Linux + 195)
 #define __NR_sched_getaffinity		(__NR_Linux + 196)
---
Atsushi Nemoto

From vbridgers@bandspeed.com Fri Oct  3 15:45:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Oct 2003 15:45:33 +0100 (BST)
Received: from mail.bandspeed.com ([IPv6:::ffff:64.132.226.131]:4847 "EHLO
	mars.bandspeed.com") by linux-mips.org with ESMTP
	id <S8225454AbTJCOp3>; Fri, 3 Oct 2003 15:45:29 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C389BC.F8A1C4CB"
Subject: RE: Kernel Profile Patch for Au1x00?
Date: Fri, 3 Oct 2003 09:45:21 -0500
Message-ID: <F2DE90354F0ED94EB7061060D9396547B98A6B@mars.bandspeed.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Kernel Profile Patch for Au1x00?
thread-index: AcOJuuK1Rc+kCj4jRhGnkbSO/46gVQAAC4Ow
From: "Vince Bridgers" <vbridgers@bandspeed.com>
To: <linux-mips@linux-mips.org>
Cc: "Eric DeVolder" <eric.devolder@amd.com>
Return-Path: <vbridgers@bandspeed.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3361
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vbridgers@bandspeed.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C389BC.F8A1C4CB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks, Eric.=20
=20
I was looking for something more simple, like kernel-based statistical
hit profiling - for example: a timer interrupt that fires at some
regular rate, collects the current Program Counter value, bucket-izes
that data and does a symbol lookup on those buckets when queried. I'll
take a look at LTT to see if I can get it to work for my purposes.
=20
I sent an email to pcs.support previously, and Gerado told me there was
no patch available. I'll check with them again.
=20
Cheers!
=20
-----Original Message-----
From: Eric DeVolder [mailto:eric.devolder@amd.com]=20
Sent: Friday, October 03, 2003 9:30 AM
To: Vince Bridgers
Subject: Re: Kernel Profile Patch for Au1x00?
=20
There is the LTT, Linux Trace Toolkit, which can be used for profiling.
If you send email to pcs.support@amd.com, they should be able to
get you the files...


Vince Bridgers wrote:


Is there a kernel profile patch that anyone is aware of for the AMD
(Alchemy) part Au1000/Au1500? If not, can anyone provide info on a good
starting point to start a port?
=20
TIA,
=20
Vince
=20
=20

------_=_NextPart_001_01C389BC.F8A1C4CB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C38993.0FE3EFE0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks, Eric. =
<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I was looking for something more =
simple,
like kernel-based statistical hit profiling &#8211; for example: a timer
interrupt that fires at some regular rate, collects the current Program =
Counter
value, bucket-<span class=3DSpellE>izes</span> that data and does a =
symbol lookup
on those buckets when queried. I&#8217;ll take a look at LTT to see if I =
can
get it to work for my purposes.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I sent an email to <span =
class=3DSpellE>pcs.support</span>
previously, and <span class=3DSpellE>Gerado</span> told me there was no =
patch
available. I&#8217;ll check with them =
again.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Cheers!<o:p></o:p></span></font></p>=


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

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext'>-----Origi=
nal
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Eric DeVolder
[mailto:eric.devolder@amd.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, October 03, =
2003
9:30 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Vince Bridgers<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Kernel =
Profile Patch
for Au1x00?</span></font></p>

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

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>There is the =
LTT, Linux
Trace Toolkit, which can be used for profiling.<br>
If you send email to <a =
href=3D"mailto:pcs.support@amd.com">pcs.support@amd.com</a>,
they should be able to<br>
get you the files...<br>
<br>
<br>
Vince Bridgers wrote:<br style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'><!--[if =
gte mso 9]><xml>
 <u1:OfficeDocumentSettings>
  <u1:DoNotRelyOnCSS/>
 </u1:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <u2:WordDocument>
  <u2:SpellingState>Clean</u2:SpellingState>
  <u2:GrammarState>Clean</u2:GrammarState>
  <u2:DocumentKind>DocumentEmail</u2:DocumentKind>
  <u2:EnvelopeVis/>
  <u2:Compatibility>
   <u2:BreakWrappedTables/>
   <u2:SnapToGridInCell/>
   <u2:WrapTextWithPunct/>
   <u2:UseAsianBreakRules/>
  </u2:Compatibility>
  <u2:BrowserLevel>MicrosoftInternetExplorer4</u2:BrowserLevel>
 </u2:WordDocument>
</xml><![endif]-->Is there a kernel profile patch that anyone is aware =
of for
the AMD (Alchemy) part Au1000/Au1500? If not, can anyone provide info on =
a good
starting point to start a =
port?<u3:p></u3:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><u3:p>&nbsp;</u3:p></span></=
font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>TIA,<u3:p></u3:p></span></fo=
nt><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><u3:p>&nbsp;</u3:p></span></=
font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Vince<u3:p></u3:p></span></f=
ont><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><u3:p>&nbsp;</u3:p></span></=
font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><u3:p>&nbsp;</u3:p></span></=
font><o:p></o:p></p>

</div>

</body>

</html>
=00
------_=_NextPart_001_01C389BC.F8A1C4CB--

From macro@ds2.pg.gda.pl Fri Oct  3 20:20:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Oct 2003 20:20:23 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:44742 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225460AbTJCTUV>; Fri, 3 Oct 2003 20:20:21 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA06275;
	Fri, 3 Oct 2003 21:20:11 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 3 Oct 2003 21:20:11 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>,
	Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: time(2) for mips64
In-Reply-To: <20031002.234116.74756712.anemo@mba.ocn.ne.jp>
Message-ID: <Pine.GSO.3.96.1031003211755.5309A-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: 3363
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 464
Lines: 14

On Thu, 2 Oct 2003, Atsushi Nemoto wrote:

> macro>  time(2) is obsolete (by gettimeofday(2)) and should be removed
> macro> for new implementations.
> 
> Then could you apply these patches?

 I can, but they need an approval from Ralf.  Ralf, is the change OK? 

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


From mips082-nospam@vtnet.ca Fri Oct  3 21:09:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Oct 2003 21:09:11 +0100 (BST)
Received: from H42.C233.tor.velocet.net ([IPv6:::ffff:216.138.233.42]:29795
	"EHLO copper.vtnet.vjbtlw") by linux-mips.org with ESMTP
	id <S8225463AbTJCUJJ>; Fri, 3 Oct 2003 21:09:09 +0100
Received: from silicon.vtint.vjbtlw (silicon.vtint.vjbtlw [192.168.141.14])
	by copper.vtnet.vjbtlw (Postfix) with ESMTP id 8EF4839AFF
	for <linux-mips@linux-mips.org>; Fri,  3 Oct 2003 16:09:07 -0400 (EDT)
From: Trevor Woerner <mips082-nospam@vtnet.ca>
Reply-To: mips082-nospam@vtnet.ca
Subject: mailing list spam
Date: Fri, 3 Oct 2003 16:09:07 -0400
User-Agent: KMail/1.5
To: 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: <200310031609.07289.mips082-nospam@vtnet.ca>
Return-Path: <mips082-nospam@vtnet.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: 3364
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mips082-nospam@vtnet.ca
Precedence: bulk
X-list: linux-mips
Content-Length: 794
Lines: 17

I appreciate microsoft *.exe updates by email just as much as the next
guy, however...

I create email aliases for the different mailing lists I join. I
 noticed that I've been receiving a fair amount of spam to the email
 address I setup for this list. I figured it was because I posted
 something in the past, so I unsubscribed my old email address, created
 a new one, and re-subscribed.

Without having made any postings since the change, I have just received
spam to the new address I've setup for this list, which means someone
has access to the membership list. Any chance this could be looked into
and turned off?

The humorous part being, of course, how stringently the the list 
receiver is that the sender's email domain resolve properly. At least 
we know it's dns-resolvable spam!

From kaos@sgi.com Sat Oct  4 03:15:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 04 Oct 2003 03:15:38 +0100 (BST)
Received: from mail.ocs.com.au ([IPv6:::ffff:203.34.97.2]:36363 "HELO
	mail.ocs.com.au") by linux-mips.org with SMTP id <S8225465AbTJDCPf>;
	Sat, 4 Oct 2003 03:15:35 +0100
Received: (qmail 20450 invoked from network); 4 Oct 2003 02:15:26 -0000
Received: from ocs3.intra.ocs.com.au (192.168.255.3)
  by mail.ocs.com.au with SMTP; 4 Oct 2003 02:15:26 -0000
Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331)
	id B1B50C02CB; Sat,  4 Oct 2003 12:15:24 +1000 (EST)
Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1])
	by ocs3.intra.ocs.com.au (Postfix) with ESMTP id AE63B140086
	for <linux-mips@linux-mips.org>; Sat,  4 Oct 2003 12:15:24 +1000 (EST)
X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4
From: Keith Owens <kaos@sgi.com>
To: linux-mips@linux-mips.org
Subject: Re: mailing list spam 
In-reply-to: Your message of "Fri, 03 Oct 2003 16:09:07 -0400."
             <200310031609.07289.mips082-nospam@vtnet.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 04 Oct 2003 12:15:23 +1000
Message-ID: <10035.1065233723@ocs3.intra.ocs.com.au>
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-archive-position: 3365
X-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
Content-Length: 1122
Lines: 25

On Fri, 3 Oct 2003 16:09:07 -0400, 
Trevor Woerner <mips082-nospam@vtnet.ca> wrote:
>I appreciate microsoft *.exe updates by email just as much as the next
>guy, however...
>
>I create email aliases for the different mailing lists I join. I
> noticed that I've been receiving a fair amount of spam to the email
> address I setup for this list. I figured it was because I posted
> something in the past, so I unsubscribed my old email address, created
> a new one, and re-subscribed.
>
>Without having made any postings since the change, I have just received
>spam to the new address I've setup for this list, which means someone
>has access to the membership list. Any chance this could be looked into
>and turned off?

Not necessarily.  This particular virus hunts around for anything that
looks like an email address and spams it.  My logs show a couple of
these virus loads from the list itself, linux-mips.org does not filter
out this virus.

Oct  4 02:21:19 reject: header Content-Type: application/x-msdownload;
name="Upgrade53.exe" from mail.linux-mips.org[62.254.210.162];
from=<linux-mips-bounce@linux-mips.org>


From herbert@13thfloor.at Sat Oct  4 03:39:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 04 Oct 2003 03:39:31 +0100 (BST)
Received: from MAIL.13thfloor.at ([IPv6:::ffff:212.16.62.51]:14720 "EHLO
	mail.13thfloor.at") by linux-mips.org with ESMTP
	id <S8225465AbTJDCj2>; Sat, 4 Oct 2003 03:39:28 +0100
Received: by mail.13thfloor.at (Postfix, from userid 1001)
	id 12663510AA6; Sat,  4 Oct 2003 04:39:21 +0200 (CEST)
Date: Sat, 4 Oct 2003 04:39:21 +0200
From: Herbert Poetzl <herbert@13thfloor.at>
To: vserver@solucorp.qc.ca
Cc: linuxppc-dev@lists.linuxppc.org, linuxppc64-dev@lists.linuxppc.org,
	linux-mips@linux-mips.org, sparclinux@vger.kernel.org,
	ultralinux@vger.kernel.org, discuss@x86-64.org,
	linux-ia64@linuxia64.org
Subject: Syscall on Linux Platforms ...
Message-ID: <20031004023921.GA5807@DUK2.13thfloor.at>
Mail-Followup-To: vserver@solucorp.qc.ca,
	linuxppc-dev@lists.linuxppc.org, linuxppc64-dev@lists.linuxppc.org,
	linux-mips@linux-mips.org, sparclinux@vger.kernel.org,
	ultralinux@vger.kernel.org, discuss@x86-64.org,
	linux-ia64@linuxia64.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <herbert@13thfloor.at>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3366
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: herbert@13thfloor.at
Precedence: bulk
X-list: linux-mips
Content-Length: 1050
Lines: 40


The Linux-VServer Project recently got one syscall
reserved for i386, and, as this project is considered 
platform independant, would like to do similar for 
other platforms ...

we know that vservers work or at least where tested 
on the following platforms i386, x86_64, ppc, sparc, 
and sparc64 ...

please advice how to proceed ...

as I'm not subscribed to any of those lists (yet), 
please CC me, or the vserver mailing list ...

thanks in advance,
Herbert 



# This patch includes the following deltas:
#                  ChangeSet    1.1378  -> 1.1379
#       arch/i386/kernel/entry.S        1.68    -> 1.69
#

 entry.S |    1 +
 1 files changed, 1 insertion(+)


diff -Nru a/arch/i386/kernel/entry.S b/arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S  Wed Oct  1 11:14:26 2003
+++ b/arch/i386/kernel/entry.S  Wed Oct  1 11:14:26 2003
@@ -879,5 +879,6 @@
       	.long sys_tgkill        /* 270 */
       	.long sys_utimes
        .long sys_fadvise64_64
+	.long sys_ni_syscall    /* sys_vserver */

 nr_syscalls=(.-sys_call_table)/4


From ralf@linux-mips.org Sat Oct  4 15:34:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 04 Oct 2003 15:34:47 +0100 (BST)
Received: from p508B5CAE.dip.t-dialin.net ([IPv6:::ffff:80.139.92.174]:49572
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225465AbTJDOeh>; Sat, 4 Oct 2003 15:34:37 +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 h94EYaNK029121;
	Sat, 4 Oct 2003 16:34:36 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h94EYZ5I029120;
	Sat, 4 Oct 2003 16:34:35 +0200
Date: Sat, 4 Oct 2003 16:34:35 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Trevor Woerner <mips082-nospam@vtnet.ca>
Cc: linux-mips@linux-mips.org
Subject: Re: mailing list spam
Message-ID: <20031004143435.GA29083@linux-mips.org>
References: <200310031609.07289.mips082-nospam@vtnet.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200310031609.07289.mips082-nospam@vtnet.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: 3368
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 989
Lines: 25

On Fri, Oct 03, 2003 at 04:09:07PM -0400, Trevor Woerner wrote:

> I appreciate microsoft *.exe updates by email just as much as the next
> guy, however...
> 
> I create email aliases for the different mailing lists I join. I
>  noticed that I've been receiving a fair amount of spam to the email
>  address I setup for this list. I figured it was because I posted
>  something in the past, so I unsubscribed my old email address, created
>  a new one, and re-subscribed.
> 
> Without having made any postings since the change, I have just received
> spam to the new address I've setup for this list, which means someone
> has access to the membership list. Any chance this could be looked into
> and turned off?
> 
> The humorous part being, of course, how stringently the the list 
> receiver is that the sender's email domain resolve properly. At least 
> we know it's dns-resolvable spam!

You're victim of a dictionary attack.

This list is about Linux, not spam discussions.

  Ralf

From steve.scott@pioneer-pdt.com Tue Oct  7 03:02:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Oct 2003 03:02:42 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:53221
	"EHLO mail.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225424AbTJGCCk>; Tue, 7 Oct 2003 03:02:40 +0100
Received: from 127.0.0.1 (localhost.pioneer-pdt.com [127.0.0.1])
	by dummy.domain.name (Postfix) with SMTP
	id C29F49D808; Mon,  6 Oct 2003 19:02:32 -0700 (PDT)
Received: from janelle (unknown [172.30.2.14])
	by mail.pioneer-pdt.com (Postfix) with SMTP
	id 925B19D807; Mon,  6 Oct 2003 19:02:31 -0700 (PDT)
Message-ID: <017601c38c77$6d7225a0$2256fea9@janelle>
From: "Steve Scott" <steve.scott@pioneer-pdt.com>
To: <jsun@mvista.com>
Cc: <linux-mips@linux-mips.org>, <craig.mautner@pioneer-pdt.com>
References: <FJEIIOCBFAIOIDNKLPFJCECODAAA.koji.kawachi@pioneer-pdt.com>
Subject: Re: schedule() BUG
Date: Mon, 6 Oct 2003 19:05:06 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0173_01C38C3C.C0FF7780"
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: <steve.scott@pioneer-pdt.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3369
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: steve.scott@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips
Content-Length: 6665
Lines: 194

This is a multi-part message in MIME format.

------=_NextPart_000_0173_01C38C3C.C0FF7780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

We tried the fault.c patch Jun suggested, but it didn't solve the problem we were
having with the BUG() in schedule(). The patch at the beginning of
except_vec3_generic for the Vr5432 bug had previously been installed.

While chasing the BUG() in schedule(), though, we ran across another BUG() in
alloc_skb() in ...linux/net/core/skbuff.c. :

    alloc_skb called nonatomically from interrupt 80117acc
    kernel BUG at skbuff.c:179!

We changed the way sock_init_data initializes the 'allocation' field and
were able to get past this one (see attached sock.c.patch). We're not sure
if this fix needs to be permanent, or if it's just a temporary workaround.

For the schedule() BUG(), all evidence that we collected pointed to some
interrupt causing us to reenter schedule() (i.e., somehow schedule() was
called during an interrupt handler). We suspected something being run
from the timer interrupt bottom half, but were never able to prove it. We
also thought a remote possibility might be a pipeline hazard in the MIPS
causing the EPC register not to update on a nested exception, but NEC says
that can't happen on the Vr5432 that we're using...

We finally worked around the schedule BUG() by disabling interrupts
during the context switch in schedule(). This workaround required changes
in linux/kernel/sched.c and linux/arch/mips/kernel/r4k_switch.S (see attached
patches).

--steve

> 
> 
> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun
> Sent: Wednesday, October 01, 2003 4:50 PM
> To: Craig Mautner
> Cc: linux-mips@linux-mips.org; jsun@mvista.com
> Subject: Re: schedule() BUG
> 
> 
> On Fri, Sep 12, 2003 at 11:04:16AM -0700, Craig Mautner wrote:
> > We are using mips-linux 2.4.17, gcc 3.2.1 (MontaVista) and crashing in
> > schedule():
> >
> > Unable to handle kernel paging request at virtual address 00000000, epc ==
> > 800153c0, ra == 800153c0
> > $0 : 00000000 9001f800 0000001b 00000000 0000001a 83f56000 8298f4a0
> 0000001f
> > $8 : 00000001 ffffe2e0 000022e0 00000000 fffffff9 ffffffff 0000000a
> 00000002
> > $16: 00000000 00000000 82af0000 8298f4a0 83f56000 00000000 80008000
> 00000000
> > $24: 82af1dc2 00000002                   82af0000 82af1ef8 82af1ef8
> 800153c0
> > epc  : 800153c0    Not tainted
> >
> > The code is:
> >
> >     {
> >       struct mm_struct *mm = next->mm;
> >       struct mm_struct *oldmm = prev->active_mm;
> >       if (!mm) {
> >            if (next->active_mm) BUG();   <- this is where we crash
> >            next->active_mm = oldmm;
> >            atomic_inc(&oldmm->mm_count);
> >            enter_lazy_tlb(oldmm, next, this_cpu);
> >       }
> >         .
> >         .
> >         .
> >
> > This seems to happen in our case when 'next' points to 'kswapd' although
> we
> > think it could happen when switching to any kernel task (i.e. those tasks
> > with mm==NULL).
> >
> > We think the culprit is that we are taking an interrupt and rescheduling
> > while at a vulnerable point in 'schedule()'. Interrupts are enabled in
> line
> > 743. If we get an interrupt any time after line 785:
> >
> >            next->active_mm = oldmm;
> >
> > but before line 806
> >
> > __schedule_tail()
> >
> > completes the swap, the interrupt can force 'schedule()' to be reentered
> via
> > 'ret_from_intr()'.
> >
> > If so, 'kswapd's 'active_mm' field will be left non-zero, but 'current'
> will
> > not have been set to point to 'kswapd'. The next time 'schedule()' tries
> to
> > switch to 'kswapd', 'next' points to 'kswapd', and
> >
> >         next->mm == NULL
> >         next->active_mm != NULL
> >
> > which is detected as an invalid state, so we hit the BUG.
> >
> > Some questions:
> > Are we looking at this correctly?
> > Has anyone ever seen this before?
> > Is there a published fix?
> >
> > Thanks,
> >
> > -Craig
> >
> 
> This is an known problem.  Please try the attached patch.
> 
> On R5432 CPU, there is also an hardware bug which can cause the same
> problem.  Please double-check vec3_generic to see if workaround is
> at the beginning of the handler.
> 
> BTW, 2.4.17 is an old kernel. You really need to upgrade.
> 
> Jun
> 
> 
> 
------=_NextPart_000_0173_01C38C3C.C0FF7780
Content-Type: application/octet-stream;
	name="sock.c.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="sock.c.patch"

Index: /home/sscott/work/Software/linux/net/core/sock.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /usr/local/CVS/V4000/Software/linux/net/core/sock.c,v=0A=
retrieving revision 1.1.1.1=0A=
diff -r1.1.1.1 sock.c=0A=
1175c1175=0A=
< 	sk->allocation	=3D	GFP_KERNEL;=0A=
---=0A=
> 	sk->allocation	=3D	GFP_ATOMIC; /*GFP_KERNEL;*/=0A=

------=_NextPart_000_0173_01C38C3C.C0FF7780
Content-Type: application/octet-stream;
	name="r4k_switch.S.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="r4k_switch.S.patch"

Index: /home/sscott/work/Software/linux/arch/mips/kernel/r4k_switch.S=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: =
/usr/local/CVS/V4000/Software/linux/arch/mips/kernel/r4k_switch.S,v=0A=
retrieving revision 1.1.1.1=0A=
diff -r1.1.1.1 r4k_switch.S=0A=
38a39=0A=
> 	ori	t1, 0x1		/* srs - assume ints disabled in schedule(). Reenable =
when task resumes */=0A=
=0A=

------=_NextPart_000_0173_01C38C3C.C0FF7780
Content-Type: application/octet-stream;
	name="sched.c.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="sched.c.patch"

Index: /home/sscott/work/Software/linux/kernel/sched.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /usr/local/CVS/V4000/Software/linux/kernel/sched.c,v=0A=
retrieving revision 1.1.1.1=0A=
diff -r1.1.1.1 sched.c=0A=
743c743=0A=
< 	spin_unlock_irq(&runqueue_lock);=0A=
---=0A=
> /*srs	spin_unlock_irq(&runqueue_lock); */=0A=
747a748=0A=
> /*srs*/	spin_unlock_irq(&runqueue_lock);=0A=

------=_NextPart_000_0173_01C38C3C.C0FF7780--



From yuasa@hh.iij4u.or.jp Tue Oct  7 16:34:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Oct 2003 16:34:43 +0100 (BST)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:37846 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225450AbTJGPeL>;
	Tue, 7 Oct 2003 16:34:11 +0100
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA15618;
	Wed, 8 Oct 2003 00:34:05 +0900 (JST)
Received: 4UMDO01 id h97FY5714243; Wed, 8 Oct 2003 00:34:05 +0900 (JST)
Received: 4UMRO00 id h97FY2o02536; Wed, 8 Oct 2003 00:34:03 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Wed, 8 Oct 2003 00:34:02 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: [patch] VR4133
Message-Id: <20031008003402.23a326cb.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart=_Wed__8_Oct_2003_00_34_02_+0900_kZw.ZTWfLEhnRaFT"
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: 3370
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 39294
Lines: 1345

This is a multi-part message in MIME format.

--Multipart=_Wed__8_Oct_2003_00_34_02_+0900_kZw.ZTWfLEhnRaFT
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I made patches for NEC VR4133.
These patches add support of new CPU of NEC.

Please apply this patch to CVS tree.

Yoichi

--Multipart=_Wed__8_Oct_2003_00_34_02_+0900_kZw.ZTWfLEhnRaFT
Content-Type: text/plain;
 name="vr4133-v24.diff"
Content-Disposition: attachment;
 filename="vr4133-v24.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux.orig/arch/mips/kernel/cpu-probe.c	Wed Jul  2 09:21:43 2003
+++ linux/arch/mips/kernel/cpu-probe.c	Tue Oct  7 23:44:32 2003
@@ -238,8 +238,11 @@
 				else
 					c->cputype = CPU_VR4181A;
 				break;
-			case PRID_REV_VR4131:
-				c->cputype = CPU_VR4131;
+			case PRID_REV_VR4130:
+				if ((c->processor_id & 0xf) < 0x4)
+					c->cputype = CPU_VR4131;
+				else
+					c->cputype = CPU_VR4133;
 				break;
 			default:
 				printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/proc.c linux/arch/mips/kernel/proc.c
--- linux.orig/arch/mips/kernel/proc.c	Mon Jun 16 08:35:54 2003
+++ linux/arch/mips/kernel/proc.c	Sun Oct  5 02:03:09 2003
@@ -67,6 +67,7 @@
 	[CPU_VR4121]	"NEC VR4121",
 	[CPU_VR4122]	"NEC VR4122",
 	[CPU_VR4131]	"NEC VR4131",
+	[CPU_VR4133]	"NEC VR4133",
 	[CPU_VR4181]	"NEC VR4181",
 	[CPU_VR4181A]	"NEC VR4181A",
 	[CPU_SR71000]	"Sandcraft SR71000"
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux.orig/arch/mips/mm/c-r4k.c	Wed Aug  6 11:20:02 2003
+++ linux/arch/mips/mm/c-r4k.c	Sun Oct  5 02:13:42 2003
@@ -833,6 +833,8 @@
 		c->dcache.waybit = 0;
 		break;
 
+	case CPU_VR4133:
+		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux.orig/arch/mips/vr41xx/casio-e55/setup.c	Wed Jul 30 09:35:37 2003
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Mon Oct  6 15:23:58 2003
@@ -59,7 +59,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux.orig/arch/mips/vr41xx/common/bcu.c	Sat Aug 30 01:32:54 2003
+++ linux/arch/mips/vr41xx/common/bcu.c	Wed Oct  8 00:15:47 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - Calculate mips_hpt_frequency properly on VR4131.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -52,8 +53,8 @@
 
 #define VR4111_CLKSPEEDREG	KSEG1ADDR(0x0b000014)
 #define VR4122_CLKSPEEDREG	KSEG1ADDR(0x0f000014)
-#define VR4131_CLKSPEEDREG	VR4122_CLKSPEEDREG
  #define CLKSP(x)		((x) & 0x001f)
+ #define CLKSP_VR4133(x)	((x) & 0x0007)
 
  #define DIV2B			0x8000
  #define DIV3B			0x4000
@@ -72,8 +73,9 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121: return readw(VR4111_CLKSPEEDREG);
-	case CPU_VR4122: return readw(VR4122_CLKSPEEDREG);
-	case CPU_VR4131: return readw(VR4131_CLKSPEEDREG);
+	case CPU_VR4122:
+	case CPU_VR4131:
+	case CPU_VR4133: return readw(VR4122_CLKSPEEDREG);
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
@@ -90,19 +92,43 @@
 	case CPU_VR4111:
 	case CPU_VR4121:
 		pclock = 18432000 * 64;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4122:
 		pclock = 18432000 * 98;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4131:
 		pclock = 18432000 * 108;
+		pclock /= CLKSP(clkspeed);
+		break;
+	case CPU_VR4133:
+		switch (CLKSP_VR4133(clkspeed)) {
+		case 0:
+			pclock = 133000000;
+			break;
+		case 1:
+			pclock = 149000000;
+			break;
+		case 2:
+			pclock = 165900000;
+			break;
+		case 3:
+			pclock = 199100000;
+			break;
+		case 4:
+			pclock = 265900000;
+			break;
+		default:
+			printk(KERN_INFO "Unknown PClock speed for NEC VR4133\n");
+			break;
+		}
 		break;
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
 	}
 
-	pclock /= CLKSP(clkspeed);
 	printk(KERN_INFO "PClock: %ldHz\n", pclock);
 
 	return pclock;
@@ -135,6 +161,7 @@
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_vtclock = pclock / VTDIVMODE(clkspeed);
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
@@ -165,6 +192,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		tclock = vtclock / TDIVMODE(clkspeed);
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux.orig/arch/mips/vr41xx/common/cmu.c	Mon Apr  7 09:17:06 2003
+++ linux/arch/mips/vr41xx/common/cmu.c	Tue Oct  7 23:47:32 2003
@@ -33,38 +33,174 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
 #include <asm/io.h>
+#include <asm/vr41xx/vr41xx.h>
 
 #define VR4111_CMUCLKMSK	KSEG1ADDR(0x0b000060)
 #define VR4122_CMUCLKMSK	KSEG1ADDR(0x0f000060)
+ #define MSKPIU			0x0001
+ #define MSKSIU			0x0002
+ #define MSKAIU			0x0004
+ #define MSKKIU			0x0008
+ #define MSKFIR			0x0010
+ #define MSKDSIU		0x0820
+ #define MSKCSI			0x0040
+ #define MSKPCIU		0x0080
+ #define MSKSSIU		0x0100
+ #define MSKSHSP		0x0200
+ #define MSKFFIR		0x0400
+ #define MSKSCSI		0x1000
+ #define MSKPPCIU		0x2000
+#define VR4133_CMUCLKMSK2	KSEG1ADDR(0x0f000064)
+ #define MSKCEU			0x0001
+ #define MSKMAC0		0x0002
+ #define MSKMAC1		0x0004
 
 static u32 vr41xx_cmu_base;
-static u16 cmuclkmsk;
+static u16 cmuclkmsk, cmuclkmsk2;
 
-#define write_cmu(mask)	writew((mask), vr41xx_cmu_base)
+#define read_cmuclkmsk()	readw(vr41xx_cmu_base)
+#define read_cmuclkmsk2()	readw(VR4133_CMUCLKMSK2)
+#define write_cmuclkmsk()	writew(cmuclkmsk, vr41xx_cmu_base)
+#define write_cmuclkmsk2()	writew(cmuclkmsk2, VR4133_CMUCLKMSK2)
 
-void vr41xx_clock_supply(u16 mask)
+void vr41xx_clock_supply(unsigned int clock)
 {
-	cmuclkmsk |= mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk |= MSKPIU;
+		break;
+	case SIU_CLOCK:
+		cmuclkmsk |= MSKSIU | MSKSSIU;
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk |= MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk |= MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk |= MSKFIR | MSKFFIR;
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121)
+			cmuclkmsk |= MSKDSIU;
+		else
+			cmuclkmsk |= MSKSIU | MSKDSIU;
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk |= MSKCSI | MSKSCSI;
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk |= MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk |= MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk |= MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 |= MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 |= MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 |= MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void vr41xx_clock_mask(u16 mask)
+void vr41xx_clock_mask(unsigned int clock)
 {
-	cmuclkmsk &= ~mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk &= ~MSKPIU;
+		break;
+	case SIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		} else {
+			if (cmuclkmsk & MSKDSIU)
+				cmuclkmsk &= ~MSKSSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		}
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk &= ~MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk &= ~MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk &= ~(MSKFIR | MSKFFIR);
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~MSKDSIU;
+		} else {
+			if (cmuclkmsk & MSKSIU)
+				cmuclkmsk &= ~MSKDSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKDSIU);
+		}
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk &= ~(MSKCSI | MSKSCSI);
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk &= ~MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk &= ~MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk &= ~MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 &= ~MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void __init vr41xx_cmu_init(u16 mask)
+void __init vr41xx_cmu_init(void)
 {
 	switch (current_cpu_data.cputype) {
         case CPU_VR4111:
@@ -75,10 +211,14 @@
         case CPU_VR4131:
                 vr41xx_cmu_base = VR4122_CMUCLKMSK;
                 break;
+        case CPU_VR4133:
+                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+		cmuclkmsk2 = read_cmuclkmsk2();
+                break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
 		break;
         }
 
-	cmuclkmsk = mask;
+	cmuclkmsk = read_cmuclkmsk();
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux.orig/arch/mips/vr41xx/common/giu.c	Wed Apr 16 21:59:34 2003
+++ linux/arch/mips/vr41xx/common/giu.c	Tue Oct  7 23:50:48 2003
@@ -34,6 +34,9 @@
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
  *  - New creation, NEC VR4111, VR4121, VR4122 and VR4131 are supported.
+ *
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -246,6 +249,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_giu_base = VR4122_GIUIOSELL;
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux.orig/arch/mips/vr41xx/common/icu.c	Wed Apr 16 21:59:34 2003
+++ linux/arch/mips/vr41xx/common/icu.c	Tue Oct  7 23:50:07 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - kgdb support.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -290,6 +291,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_icu1_base = VR4122_SYSINT1REG;
 		vr41xx_icu2_base = VR4122_SYSINT2REG;
 		break;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/pciu.c linux/arch/mips/vr41xx/common/pciu.c
--- linux.orig/arch/mips/vr41xx/common/pciu.c	Mon Apr  7 09:17:06 2003
+++ linux/arch/mips/vr41xx/common/pciu.c	Mon Oct  6 15:57:20 2003
@@ -74,7 +74,7 @@
 		/*
 		 * Type 1 configuration
 		 */
-		if (bus > 255 || PCI_SLOT(dev_fn) > 31 || where > 255)
+		if (PCI_SLOT(dev_fn) > 31 || where > 255)
 			return -1;
 
 		writel((bus << 16)	|
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/pciu.h linux/arch/mips/vr41xx/common/pciu.h
--- linux.orig/arch/mips/vr41xx/common/pciu.h	Mon Jul 15 09:02:56 2002
+++ linux/arch/mips/vr41xx/common/pciu.h	Sun Oct  5 17:33:53 2003
@@ -107,9 +107,6 @@
 
 #define MAX_PCI_CLOCK			33333333
 
-#define PCIU_CLOCK			0x0080
-#define PCI_CLOCK			0x2000
-
 static inline int pciu_read_config_byte(int where, u8 *val)
 {
 	u32 data;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux.orig/arch/mips/vr41xx/common/serial.c	Mon Apr  7 09:17:06 2003
+++ linux/arch/mips/vr41xx/common/serial.c	Tue Oct  7 23:48:32 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -66,7 +67,6 @@
  #define TMICMODE		0x20
 
 #define SIU_BASE_BAUD		1152000
-#define SIU_CLOCK		0x0102
 
 /* VR4122 and VR4131 DSIU Registers */
 #define DSIURB			KSEG1ADDR(0x0f000820)
@@ -75,7 +75,6 @@
  #define INTDSIU		0x0800
 
 #define DSIU_BASE_BAUD		1152000
-#define DSIU_CLOCK		0x0802
 
 int vr41xx_serial_ports = 0;
 
@@ -106,6 +105,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		writew(val, VR4122_SIUIRSEL);
 		break;
 	default:
@@ -133,6 +133,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		s.iomem_base = (unsigned char *)VR4122_SIURB;
 		break;
 	default:
@@ -154,7 +155,8 @@
 	struct serial_struct s;
 
 	if (current_cpu_data.cputype != CPU_VR4122 &&
-	    current_cpu_data.cputype != CPU_VR4131)
+	    current_cpu_data.cputype != CPU_VR4131 &&
+	    current_cpu_data.cputype != CPU_VR4133)
 		return;
 
 	memset(&s, 0, sizeof(s));
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/time.c linux/arch/mips/vr41xx/common/time.c
--- linux.orig/arch/mips/vr41xx/common/time.c	Sat Aug 30 01:32:54 2003
+++ linux/arch/mips/vr41xx/common/time.c	Tue Oct  7 23:49:13 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4100 series are supported.
  *  - Added support for NEC VR4100 series RTC Unit.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4100 series are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/config.h>
 #include <linux/interrupt.h>
@@ -69,6 +70,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
                 vr41xx_rtc_base = VR4122_ETIMELREG;
                 break;
         default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Mon Oct  6 15:24:22 2003
@@ -59,7 +59,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Mon Oct  6 15:23:38 2003
@@ -140,7 +140,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	Mon Oct  6 15:24:43 2003
@@ -102,7 +102,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
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 May 22 06:36:53 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Mon Oct  6 15:24:52 2003
@@ -114,7 +114,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Mon Oct  6 15:25:08 2003
@@ -107,7 +107,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Mon Oct  6 15:25:21 2003
@@ -107,7 +107,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0x0102);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/cpu.h linux/include/asm-mips/cpu.h
--- linux.orig/include/asm-mips/cpu.h	Mon Jun 16 08:35:54 2003
+++ linux/include/asm-mips/cpu.h	Tue Oct  7 23:52:32 2003
@@ -99,7 +99,7 @@
 #define PRID_REV_VR4121		0x0060
 #define PRID_REV_VR4122		0x0070
 #define PRID_REV_VR4181A	0x0070	/* Same as VR4122 */
-#define PRID_REV_VR4131		0x0080
+#define PRID_REV_VR4130		0x0080
 
 /*
  * FPU implementation/revision register (CP1 control register 0).
@@ -166,7 +166,8 @@
 #define CPU_VR4181A		51
 #define CPU_AU1100		52
 #define CPU_SR71000		53
-#define CPU_LAST		53
+#define CPU_VR4133		54
+#define CPU_LAST		54
 
 /*
  * ISA Level encodings
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	Wed Jul 30 09:35:38 2003
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Wed Oct  8 00:10:05 2003
@@ -32,12 +32,15 @@
 #define PRID_VR4181A_REV1_0	0x00000c73
 #define PRID_VR4181A_REV1_1	0x00000c74
 
-/* VR4131 0x00000c80-0x00000c8f */
+/* VR4131 0x00000c80-0x00000c83 */
 #define PRID_VR4131_REV1_2	0x00000c80
 #define PRID_VR4131_REV2_0	0x00000c81
 #define PRID_VR4131_REV2_1	0x00000c82
 #define PRID_VR4131_REV2_2	0x00000c83
 
+/* VR4133 0x00000c84- */
+#define PRID_VR4133		0x00000c84
+
 /*
  * Bus Control Uint
  */
@@ -46,9 +49,25 @@
 /*
  * Clock Mask Unit
  */
-extern void vr41xx_cmu_init(u16 mask);
-extern void vr41xx_clock_supply(u16 mask);
-extern void vr41xx_clock_mask(u16 mask);
+extern void vr41xx_cmu_init(void);
+extern void vr41xx_clock_supply(unsigned int clock);
+extern void vr41xx_clock_mask(unsigned int clock);
+
+enum {
+	PIU_CLOCK,
+	SIU_CLOCK,
+	AIU_CLOCK,
+	KIU_CLOCK,
+	FIR_CLOCK,
+	DSIU_CLOCK,
+	CSI_CLOCK,
+	PCIU_CLOCK,
+	HSP_CLOCK,
+	PCI_CLOCK,
+	CEU_CLOCK,
+	ETHER0_CLOCK,
+	ETHER1_CLOCK
+};
 
 /*
  * Interrupt Control Unit

--Multipart=_Wed__8_Oct_2003_00_34_02_+0900_kZw.ZTWfLEhnRaFT
Content-Type: text/plain;
 name="vr4133-v26.diff"
Content-Disposition: attachment;
 filename="vr4133-v26.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux.orig/arch/mips/kernel/cpu-probe.c	Sun Aug  3 22:39:26 2003
+++ linux/arch/mips/kernel/cpu-probe.c	Tue Oct  7 23:59:57 2003
@@ -253,8 +253,11 @@
 				else
 					c->cputype = CPU_VR4181A;
 				break;
-			case PRID_REV_VR4131:
-				c->cputype = CPU_VR4131;
+			case PRID_REV_VR4130:
+				if ((c->processor_id & 0xf) < 0x4)
+					c->cputype = CPU_VR4131;
+				else
+					c->cputype = CPU_VR4133;
 				break;
 			default:
 				printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/proc.c linux/arch/mips/kernel/proc.c
--- linux.orig/arch/mips/kernel/proc.c	Sat Aug 30 01:35:36 2003
+++ linux/arch/mips/kernel/proc.c	Wed Oct  8 00:00:25 2003
@@ -68,6 +68,7 @@
 	[CPU_VR4121]	"NEC VR4121",
 	[CPU_VR4122]	"NEC VR4122",
 	[CPU_VR4131]	"NEC VR4131",
+	[CPU_VR4133]	"NEC VR4133",
 	[CPU_VR4181]	"NEC VR4181",
 	[CPU_VR4181A]	"NEC VR4181A",
 	[CPU_SR71000]	"Sandcraft SR71000"
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux.orig/arch/mips/mm/c-r4k.c	Mon Aug 18 21:33:19 2003
+++ linux/arch/mips/mm/c-r4k.c	Wed Oct  8 00:01:17 2003
@@ -831,6 +831,8 @@
 		c->dcache.waybit = 0;
 		break;
 
+	case CPU_VR4133:
+		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/pci/pci-vr41xx.h linux/arch/mips/pci/pci-vr41xx.h
--- linux.orig/arch/mips/pci/pci-vr41xx.h	Fri Jun 13 23:19:56 2003
+++ linux/arch/mips/pci/pci-vr41xx.h	Wed Oct  8 00:10:58 2003
@@ -107,9 +107,6 @@
 
 #define MAX_PCI_CLOCK			33333333
 
-#define PCIU_CLOCK			0x0080
-#define PCI_CLOCK			0x2000
-
 static inline int pciu_read_config_byte(int where, u8 * val)
 {
 	u32 data;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux.orig/arch/mips/vr41xx/casio-e55/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Wed Oct  8 00:01:43 2003
@@ -62,7 +62,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux.orig/arch/mips/vr41xx/common/bcu.c	Sat Aug 30 01:35:41 2003
+++ linux/arch/mips/vr41xx/common/bcu.c	Wed Oct  8 00:06:44 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - Calculate mips_hpt_frequency properly on VR4131.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -52,8 +53,8 @@
 
 #define VR4111_CLKSPEEDREG	KSEG1ADDR(0x0b000014)
 #define VR4122_CLKSPEEDREG	KSEG1ADDR(0x0f000014)
-#define VR4131_CLKSPEEDREG	VR4122_CLKSPEEDREG
  #define CLKSP(x)		((x) & 0x001f)
+ #define CLKSP_VR4133(x)	((x) & 0x0007)
 
  #define DIV2B			0x8000
  #define DIV3B			0x4000
@@ -72,8 +73,9 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121: return readw(VR4111_CLKSPEEDREG);
-	case CPU_VR4122: return readw(VR4122_CLKSPEEDREG);
-	case CPU_VR4131: return readw(VR4131_CLKSPEEDREG);
+	case CPU_VR4122:
+	case CPU_VR4131:
+	case CPU_VR4133: return readw(VR4122_CLKSPEEDREG);
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
@@ -90,19 +92,43 @@
 	case CPU_VR4111:
 	case CPU_VR4121:
 		pclock = 18432000 * 64;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4122:
 		pclock = 18432000 * 98;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4131:
 		pclock = 18432000 * 108;
+		pclock /= CLKSP(clkspeed);
+		break;
+	case CPU_VR4133:
+		switch (CLKSP_VR4133(clkspeed)) {
+		case 0:
+			pclock = 133000000;
+			break;
+		case 1:
+			pclock = 149000000;
+			break;
+		case 2:
+			pclock = 165900000;
+			break;
+		case 3:
+			pclock = 199100000;
+			break;
+		case 4:
+			pclock = 265900000;
+			break;
+		default:
+			printk(KERN_INFO "Unknown PClock speed for NEC VR4133\n");
+			break;
+		}
 		break;
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
 	}
 
-	pclock /= CLKSP(clkspeed);
 	printk(KERN_INFO "PClock: %ldHz\n", pclock);
 
 	return pclock;
@@ -135,6 +161,7 @@
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_vtclock = pclock / VTDIVMODE(clkspeed);
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
@@ -165,6 +192,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		tclock = vtclock / TDIVMODE(clkspeed);
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux.orig/arch/mips/vr41xx/common/cmu.c	Fri Apr 11 00:17:57 2003
+++ linux/arch/mips/vr41xx/common/cmu.c	Tue Oct  7 23:47:32 2003
@@ -33,38 +33,174 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
 #include <asm/io.h>
+#include <asm/vr41xx/vr41xx.h>
 
 #define VR4111_CMUCLKMSK	KSEG1ADDR(0x0b000060)
 #define VR4122_CMUCLKMSK	KSEG1ADDR(0x0f000060)
+ #define MSKPIU			0x0001
+ #define MSKSIU			0x0002
+ #define MSKAIU			0x0004
+ #define MSKKIU			0x0008
+ #define MSKFIR			0x0010
+ #define MSKDSIU		0x0820
+ #define MSKCSI			0x0040
+ #define MSKPCIU		0x0080
+ #define MSKSSIU		0x0100
+ #define MSKSHSP		0x0200
+ #define MSKFFIR		0x0400
+ #define MSKSCSI		0x1000
+ #define MSKPPCIU		0x2000
+#define VR4133_CMUCLKMSK2	KSEG1ADDR(0x0f000064)
+ #define MSKCEU			0x0001
+ #define MSKMAC0		0x0002
+ #define MSKMAC1		0x0004
+
+static u32 vr41xx_cmu_base;
+static u16 cmuclkmsk, cmuclkmsk2;
+
+#define read_cmuclkmsk()	readw(vr41xx_cmu_base)
+#define read_cmuclkmsk2()	readw(VR4133_CMUCLKMSK2)
+#define write_cmuclkmsk()	writew(cmuclkmsk, vr41xx_cmu_base)
+#define write_cmuclkmsk2()	writew(cmuclkmsk2, VR4133_CMUCLKMSK2)
 
-static u32 vr41xx_cmu_base = 0;
-static u16 cmuclkmsk = 0;
-
-#define write_cmu(mask)	writew((mask), vr41xx_cmu_base)
-
-void vr41xx_clock_supply(u16 mask)
+void vr41xx_clock_supply(unsigned int clock)
 {
-	cmuclkmsk |= mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk |= MSKPIU;
+		break;
+	case SIU_CLOCK:
+		cmuclkmsk |= MSKSIU | MSKSSIU;
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk |= MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk |= MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk |= MSKFIR | MSKFFIR;
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121)
+			cmuclkmsk |= MSKDSIU;
+		else
+			cmuclkmsk |= MSKSIU | MSKDSIU;
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk |= MSKCSI | MSKSCSI;
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk |= MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk |= MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk |= MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 |= MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 |= MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 |= MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void vr41xx_clock_mask(u16 mask)
+void vr41xx_clock_mask(unsigned int clock)
 {
-	cmuclkmsk &= ~mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk &= ~MSKPIU;
+		break;
+	case SIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		} else {
+			if (cmuclkmsk & MSKDSIU)
+				cmuclkmsk &= ~MSKSSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		}
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk &= ~MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk &= ~MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk &= ~(MSKFIR | MSKFFIR);
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~MSKDSIU;
+		} else {
+			if (cmuclkmsk & MSKSIU)
+				cmuclkmsk &= ~MSKDSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKDSIU);
+		}
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk &= ~(MSKCSI | MSKSCSI);
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk &= ~MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk &= ~MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk &= ~MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 &= ~MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void __init vr41xx_cmu_init(u16 mask)
+void __init vr41xx_cmu_init(void)
 {
 	switch (current_cpu_data.cputype) {
         case CPU_VR4111:
@@ -75,10 +211,14 @@
         case CPU_VR4131:
                 vr41xx_cmu_base = VR4122_CMUCLKMSK;
                 break;
+        case CPU_VR4133:
+                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+		cmuclkmsk2 = read_cmuclkmsk2();
+                break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
 		break;
         }
 
-	cmuclkmsk = mask;
+	cmuclkmsk = read_cmuclkmsk();
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux.orig/arch/mips/vr41xx/common/giu.c	Sat Apr 19 16:38:35 2003
+++ linux/arch/mips/vr41xx/common/giu.c	Wed Oct  8 00:08:42 2003
@@ -34,6 +34,9 @@
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
  *  - New creation, NEC VR4111, VR4121, VR4122 and VR4131 are supported.
+ *
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -246,6 +249,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_giu_base = VR4122_GIUIOSELL;
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux.orig/arch/mips/vr41xx/common/icu.c	Sat Apr 19 16:38:35 2003
+++ linux/arch/mips/vr41xx/common/icu.c	Wed Oct  8 00:09:27 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - kgdb support.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -290,6 +291,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_icu1_base = VR4122_SYSINT1REG;
 		vr41xx_icu2_base = VR4122_SYSINT2REG;
 		break;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux.orig/arch/mips/vr41xx/common/serial.c	Fri Apr 11 00:18:03 2003
+++ linux/arch/mips/vr41xx/common/serial.c	Wed Oct  8 00:12:26 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -66,7 +67,6 @@
  #define TMICMODE		0x20
 
 #define SIU_BASE_BAUD		1152000
-#define SIU_CLOCK		0x0102
 
 /* VR4122 and VR4131 DSIU Registers */
 #define DSIURB			KSEG1ADDR(0x0f000820)
@@ -75,7 +75,6 @@
  #define INTDSIU		0x0800
 
 #define DSIU_BASE_BAUD		1152000
-#define DSIU_CLOCK		0x0802
 
 int vr41xx_serial_ports = 0;
 
@@ -106,6 +105,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		writew(val, VR4122_SIUIRSEL);
 		break;
 	default:
@@ -133,6 +133,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		s.iomem_base = (unsigned char *)VR4122_SIURB;
 		break;
 	default:
@@ -154,7 +155,8 @@
 	struct serial_struct s;
 
 	if (current_cpu_data.cputype != CPU_VR4122 &&
-	    current_cpu_data.cputype != CPU_VR4131)
+	    current_cpu_data.cputype != CPU_VR4131 &&
+	    current_cpu_data.cputype != CPU_VR4133)
 		return;
 
 	memset(&s, 0, sizeof(s));
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/time.c linux/arch/mips/vr41xx/common/time.c
--- linux.orig/arch/mips/vr41xx/common/time.c	Sat Aug 30 01:35:41 2003
+++ linux/arch/mips/vr41xx/common/time.c	Wed Oct  8 00:13:09 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4100 series are supported.
  *  - Added support for NEC VR4100 series RTC Unit.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4100 series are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/config.h>
 #include <linux/interrupt.h>
@@ -69,6 +70,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
                 vr41xx_rtc_base = VR4122_ETIMELREG;
                 break;
         default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Wed Oct  8 00:13:26 2003
@@ -62,7 +62,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Wed Oct  8 00:14:08 2003
@@ -143,7 +143,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	Wed Oct  8 00:14:23 2003
@@ -110,7 +110,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
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	Tue Jul 29 23:50:25 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Wed Oct  8 00:14:33 2003
@@ -115,7 +115,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Wed Oct  8 00:14:43 2003
@@ -110,7 +110,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/setup.c	Wed Jul 30 22:36:56 2003
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Wed Oct  8 00:14:56 2003
@@ -110,7 +110,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0x0102);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/cpu.h linux/include/asm-mips/cpu.h
--- linux.orig/include/asm-mips/cpu.h	Sun Aug  3 22:39:36 2003
+++ linux/include/asm-mips/cpu.h	Wed Oct  8 00:16:43 2003
@@ -100,7 +100,7 @@
 #define PRID_REV_VR4121		0x0060
 #define PRID_REV_VR4122		0x0070
 #define PRID_REV_VR4181A	0x0070	/* Same as VR4122 */
-#define PRID_REV_VR4131		0x0080
+#define PRID_REV_VR4130		0x0080
 
 /*
  * FPU implementation/revision register (CP1 control register 0).
@@ -168,7 +168,8 @@
 #define CPU_AU1100		52
 #define CPU_SR71000		53
 #define CPU_25KF		54
-#define CPU_LAST		54
+#define CPU_VR4133		55
+#define CPU_LAST		55
 
 /*
  * ISA Level encodings
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	Wed Jul 30 22:36:56 2003
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Wed Oct  8 00:19:09 2003
@@ -32,12 +32,15 @@
 #define PRID_VR4181A_REV1_0	0x00000c73
 #define PRID_VR4181A_REV1_1	0x00000c74
 
-/* VR4131 0x00000c80-0x00000c8f */
+/* VR4131 0x00000c80-0x00000c83 */
 #define PRID_VR4131_REV1_2	0x00000c80
 #define PRID_VR4131_REV2_0	0x00000c81
 #define PRID_VR4131_REV2_1	0x00000c82
 #define PRID_VR4131_REV2_2	0x00000c83
 
+/* VR4131 0x00000c84- */
+#define PRID_VR4133		0x00000c84
+
 /*
  * Bus Control Uint
  */
@@ -46,9 +49,25 @@
 /*
  * Clock Mask Unit
  */
-extern void vr41xx_cmu_init(u16 mask);
-extern void vr41xx_clock_supply(u16 mask);
-extern void vr41xx_clock_mask(u16 mask);
+extern void vr41xx_cmu_init(void);
+extern void vr41xx_clock_supply(unsigned int clock);
+extern void vr41xx_clock_mask(unsigned int clock);
+
+enum {
+	PIU_CLOCK,
+	SIU_CLOCK,
+	AIU_CLOCK,
+	KIU_CLOCK,
+	FIR_CLOCK,
+	DSIU_CLOCK,
+	CSI_CLOCK,
+	PCIU_CLOCK,
+	HSP_CLOCK,
+	PCI_CLOCK,
+	CEU_CLOCK,
+	ETHER0_CLOCK,
+	ETHER1_CLOCK
+};
 
 /*
  * Interrupt Control Unit

--Multipart=_Wed__8_Oct_2003_00_34_02_+0900_kZw.ZTWfLEhnRaFT--

From yshitoot@stellartec.com Tue Oct  7 17:51:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Oct 2003 17:51:19 +0100 (BST)
Received: from mail.stellartec.com ([IPv6:::ffff:65.107.16.99]:55823 "EHLO
	nt_server.stellartec.com") by linux-mips.org with ESMTP
	id <S8225455AbTJGQvD>; Tue, 7 Oct 2003 17:51:03 +0100
Received: from wsyash ([192.168.1.109]) by nt_server.stellartec.com
          (Post.Office MTA v3.1.2 release (PO205-101c)
          ID# 568-43562U100L2S100) with SMTP id AAA356
          for <linux-mips@linux-mips.org>; Tue, 7 Oct 2003 09:50:50 -0700
Reply-To: <yshitoot@stellartec.com>
From: yshitoot@stellartec.com (Yashwant Shitoot)
To: <linux-mips@linux-mips.org>
Subject: touch panel
Date: Tue, 7 Oct 2003 09:50:17 -0700
Message-ID: <002e01c38cf3$16cea990$6d01a8c0@wsyash>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Return-Path: <yshitoot@stellartec.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3371
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yshitoot@stellartec.com
Precedence: bulk
X-list: linux-mips
Content-Length: 385
Lines: 20

Hello,

About 10% of the time as I lift my finger up the x or the y value changes
e.g.
from my printf statement

status=fffc0000, x=135, y=46
(similar numbers repeated a few times)
status=fffc0000, x=136, y=47
status=fffc0000, x=74, y=113
status=0.x=0,y=0

Have others seen this problem ? any suggestions ? (yes I can always through
away the
line before status changes)

thanks

yash


From noah@caltech.edu Tue Oct  7 20:46:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Oct 2003 21:15:15 +0100 (BST)
Received: from SteeleMR-loadb-NAT-49.caltech.edu ([IPv6:::ffff:131.215.49.69]:39549
	"EHLO water-ox.its.caltech.edu") by linux-mips.org with ESMTP
	id <S8225511AbTJGTqy>; Tue, 7 Oct 2003 20:46:54 +0100
Received: from fire-dog (fire-dog [192.168.1.4])
	by water-ox-postvirus (Postfix) with ESMTP id 862B026AC1A
	for <linux-mips@linux-mips.org>; Tue,  7 Oct 2003 12:46:46 -0700 (PDT)
Received: from earth-ox ([192.168.1.9])
	by fire-dog (MailMonitor for SMTP v1.2.2 ) ;
	Tue, 7 Oct 2003 12:46:45 -0700 (PDT)
Received: from blinky.its.caltech.edu (blinky.its.caltech.edu [131.215.48.132])
	by earth-ox.its.caltech.edu (Postfix) with ESMTP id 98C59109A1B
	for <linux-mips@linux-mips.org>; Tue,  7 Oct 2003 12:46:45 -0700 (PDT)
Received: from localhost (noah@localhost)
	by blinky.its.caltech.edu (8.12.9/8.12.8) with ESMTP id h97Jkip7025946
	for <linux-mips@linux-mips.org>; Tue, 7 Oct 2003 12:46:45 -0700 (PDT)
X-Authentication-Warning: blinky.its.caltech.edu: noah owned process doing -bs
Date: Tue, 7 Oct 2003 12:46:44 -0700 (PDT)
From: "Noah J. Misch" <noah@caltech.edu>
X-X-Sender: noah@blinky
To: linux-mips@linux-mips.org
Subject: Possible Missing include in arch/mips/kernel/vmlinux.lds.S
Message-ID: <Pine.GSO.4.58.0310071220150.23851@blinky>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <noah@caltech.edu>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3372
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: noah@caltech.edu
Precedence: bulk
X-list: linux-mips
Content-Length: 1309
Lines: 27

Please CC:/To: relevant messages to me; I do not subscribe to linux-mips.

Executive summary: File in subject line may need #include <linux/config.h>

I just wrote a new version of scripts/configcheck.pl, the script that runs
when you call 'make configcheck' in a linux source tree.  This script is
supposed to find files that need to include linux/config.h but do not
include it, and vice-versa.  I found only one file in the 2.6.0-test6 tree
that needs config.h and does not include it[1]:

arch/mips/kernel/vmlinux.lds.S

This file uses CONFIG_BOOT_ELF64, CONFIG_MIPS32, and CONFIG_MIPS64, but
neither it nor the one file it includes, asm-generic/vmlinux.lds.h,
include linux/config.h.  This is true both in the linux-2.6.0-test6
version, and also in the linux-mips CVS tree as of 3:00 PM 10/7/2003.

I don't use linux-mips myself, so I haven't verified this issue with a
real toolchain.  It seems pretty clear-cut, but if I'm mistaken, would one
of you send me arch/mips/kernel/.vmlinux.lds.s.cmd from the tree of a
built kernel so I can fix my methodology? :)

[1] That is, in a way that would cause bugs right now.  Many, many files
need config.h but include it only indirectly, and many files need config.h
but never compile standalone.  I found only one file that does not fall
into either category.


From sjhill@realitydiluted.com Tue Oct  7 21:21:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Oct 2003 21:21:36 +0100 (BST)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:4754
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225513AbTJGUVY>; Tue, 7 Oct 2003 21:21:24 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1A6yKg-0003g6-00
	for <linux-mips@linux-mips.org>; Tue, 07 Oct 2003 15:21:22 -0500
Message-ID: <3F832040.7070606@realitydiluted.com>
Date: Tue, 07 Oct 2003 16:21:20 -0400
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030930 Debian/1.4-5
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: [PATCH] Proposed NMI handling interface...
Content-Type: multipart/mixed;
 boundary="------------070004050009030404040309"
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3373
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3348
Lines: 114

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

Greetings.

I wanted to propose an NMI handling interface. I have attached
the header file and patches to 'arch/mips/kernel/traps.c'. The
user need only specify the offset address for the NMI vector
code and then they can also specify their own desired NMI
function. Comments?

-Steve

--------------070004050009030404040309
Content-Type: text/x-chdr;
 name="nmi.h"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="nmi.h"

/*
 * linux/include/asm-mips/nmi.h
 *
 * NMI interface definitions
 *
 * Copyright (C) 2003 TimeSys Corp.
 *                    S. James Hill (James.Hill@timesys.com)
 *                                  (sjhill@realitydiluted.com)
 *
 *  This program is free software; you can redistribute  it and/or modify it
 *  under  the terms of  the GNU General  Public License as published by the
 *  Free Software Foundation;  either version 2 of the  License, or (at your
 *  option) any later version.
 *
 *  THIS  SOFTWARE  IS PROVIDED   ``AS  IS'' AND   ANY  EXPRESS OR IMPLIED
 *  WARRANTIES,   INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED WARRANTIES OF
 *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
 *  NO  EVENT  SHALL   THE AUTHOR  BE    LIABLE FOR ANY   DIRECT, INDIRECT,
 *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 *  NOT LIMITED   TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; LOSS OF
 *  USE, DATA,  OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
 *  ANY THEORY OF LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
 *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 *  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 *  You should have received a copy of the  GNU General Public License along
 *  with this program; if not, write  to the Free Software Foundation, Inc.,
 *  675 Mass Ave, Cambridge, MA 02139, USA.
 */
#ifndef _ASM_NMI_H
#define _ASM_NMI_H

/*
 * NMI vector address offset.
 */
extern unsigned long nmi_addr;

/*
 * User-defined NMI function.
 */
extern void (*nmi_user_handler)(struct pt_regs *regs);

#endif

--------------070004050009030404040309
Content-Type: text/plain;
 name="traps.c.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="traps.c.diff"

--- traps.c.orig	Tue Oct  7 15:08:43 2003
+++ traps.c	Tue Oct  7 15:10:28 2003
@@ -64,6 +66,11 @@
 void (*board_be_init)(void);
 int (*board_be_handler)(struct pt_regs *regs, int is_fixup);
 
+#ifdef CONFIG_NMI
+unsigned long nmi_addr = 0;
+void (*nmi_user_handler)(struct pt_regs *regs);
+#endif
+
 int kstack_depth_to_print = 24;
 
 /*
@@ -841,6 +1095,8 @@
  */
 void nmi_exception_handler(struct pt_regs *regs)
 {
+	if (nmi_user_handler)
+		nmi_user_handler(regs);
 	printk("NMI taken!!!!\n");
 	die("NMI", regs);
 	while(1) ;
@@ -1009,6 +1265,14 @@
 		restore_fp_context = fpu_emulator_restore_context;
 	}
 
+#ifdef CONFIG_NMI
+	{
+		extern char except_vec_nmi;
+
+		memcpy((void *)(KSEG0 + nmi_addr), &except_vec_nmi, 0x8);
+	}
+#endif
+
 	flush_icache_range(KSEG0, KSEG0 + 0x400);
 
 	atomic_inc(&init_mm.mm_count);	/* XXX UP?  */

--------------070004050009030404040309--


From gil.lauer@ghs.com Tue Oct  7 21:50:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 07 Oct 2003 21:51:25 +0100 (BST)
Received: from eta.ghs.com ([IPv6:::ffff:63.102.70.66]:37361 "EHLO eta.ghs.com")
	by linux-mips.org with ESMTP id <S8225517AbTJGUux>;
	Tue, 7 Oct 2003 21:50:53 +0100
Received: from blaze.ghs.com (blaze.ghs.com [192.67.158.233])
	by eta.ghs.com (8.12.10/8.12.8) with ESMTP id h97KojiL018652
	for <linux-mips@linux-mips.org>; Tue, 7 Oct 2003 13:50:45 -0700 (PDT)
Received: from glghspc ([192.168.114.2])
	by blaze.ghs.com (8.12.9/8.12.9) with ESMTP id h97KoiIo027795
	for <linux-mips@linux-mips.org>; Tue, 7 Oct 2003 13:50:44 -0700 (PDT)
Reply-To: <gil.lauer@ghs.com>
From: "Gil Lauer" <gil.lauer@ghs.com>
To: <linux-mips@linux-mips.org>
Subject: Can't boot RedHat 7.3 Linux on Mips Malta
Date: Tue, 7 Oct 2003 13:51:02 -0700
Organization: Green Hills Software
Message-ID: <002501c38d14$b8611ba0$0272a8c0@glghspc>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0026_01C38CDA.0C0243A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Return-Path: <gil.lauer@ghs.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3374
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gil.lauer@ghs.com
Precedence: bulk
X-list: linux-mips
Content-Length: 12795
Lines: 372

This is a multi-part message in MIME format.

------=_NextPart_000_0026_01C38CDA.0C0243A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0027_01C38CDA.0C0243A0"


------=_NextPart_001_0027_01C38CDA.0C0243A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I am new to Linux and a new subscriber to linux-mips.

 

I downloaded the RedHat Linux distribution that MIPS Technology posts at
ftp://ftp.mips.com/pub/linux/mips/installation/redhat7.3/01.00/ and I
cannot get through the installation process.  I can load and run the
pre-built installation kernel, but when it tries to load the prebuilt
Linux image via NFS I get the following error:

 

Welcome to the MIPS installation of RedHat RPMS.

 

Install method (CD-ROM, NFS) [CD-ROM] NFS

 

IP-address of target system: [192.168.201.68] 192.168.114.150

SIOCSIFADDR: No such device

eth0: unknown interface: No such device

 

Since I have successfully loaded and run the prebuilt Linux installation
image via Yamon, I know that the network connection is working.  Since
this image is built to run on the Malta board, it is odd that it can't
find the built-in ethernet connection.

 

I have attached a complete log of the console output.  Any pointers on
where I am going wrong would be welcome.

 

Gil Lauer

 


------=_NextPart_001_0027_01C38CDA.0C0243A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

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


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I am new to Linux and a new subscriber to =
linux-mips.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I downloaded the RedHat Linux distribution that MIPS =
Technology
posts at <a
href=3D"ftp://ftp.mips.com/pub/linux/mips/installation/redhat7.3/01.00/">=
ftp://ftp.mips.com/pub/linux/mips/installation/redhat7.3/01.00/</a>
and I cannot get through the installation process.&nbsp; I can load and =
run the
pre-built installation kernel, but when it tries to load the prebuilt =
Linux
image via NFS I get the following error:</span></font></p>

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

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Welcome to the MIPS
installation of RedHat RPMS.</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DSV style=3D'font-size:10.0pt;font-family:"Courier New"'>Install =
method
(CD-ROM, NFS) [CD-ROM] NFS</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DSV style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>IP-address of =
target system:
[192.168.201.68] 192.168.114.150</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>SIOCSIFADDR: No =
such device</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>eth0: unknown =
interface: No
such device</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Since I have successfully loaded and run the prebuilt =
Linux
installation image via Yamon, I know that the network connection is
working.&nbsp; Since this image is built to run on the =
</span></font><font
  size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Malta</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> board, it
is odd that it can&#8217;t find the built-in ethernet =
connection.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I have attached a complete log of the console =
output.&nbsp;
Any pointers on where I am going wrong would be =
welcome.</span></font></p>

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

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

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

</div>

</body>

</html>

------=_NextPart_001_0027_01C38CDA.0C0243A0--

------=_NextPart_000_0026_01C38CDA.0C0243A0
Content-Type: text/plain;
	name="malta_linux_errlog.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="malta_linux_errlog.txt"

YAMON ROM Monitor, Revision 02.00.=0A=
Copyright (c) 1999-2000 MIPS Technologies, Inc. - All Rights Reserved.=0A=
=0A=
For a list of available commands, type 'help'.=0A=
=0A=
Compilation time =3D            Sep 11 2000  13:07:34=0A=
Board type/revision =3D         0x02 (Malta) / 0x00=0A=
Core board type/revision =3D    0x01 (CoreLV) / 0x01=0A=
FPGA revision =3D               0x0001=0A=
MAC address =3D                 00.d0.a0.00.02.6b=0A=
Board S/N =3D                   0000000371=0A=
PCI bus frequency =3D           33.33 MHz=0A=
Processor Company ID =3D        0x01 (MIPS Technologies, Inc.)=0A=
Processor ID/revision =3D       0x80 (MIPS 4Kc) / 0x01=0A=
Endianness =3D                  Big=0A=
CPU/Bus frequency =3D           80 MHz / 40 MHz=0A=
Flash memory size =3D           4 MByte=0A=
SDRAM size =3D                  64 MByte=0A=
First free SDRAM address =3D    0x80094530=0A=
=0A=
YAMON> load =
tftp://192.168.114.105/vmlinux-2.4.18.malta.install.eb-01.01.srec=0A=
About to load =
tftp://192.168.114.105/vmlinux-2.4.18.malta.install.eb-01.01.srec=0A=
Press Ctrl-C to break=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
........................................=0A=
..............................=0A=
Start =3D 0x8029e040, range =3D (0x80100000,0x8077bfff), format =3D SREC=0A=
YAMON> go=0A=
=0A=
LINUX started...=0A=
CPU revision is: 00018001=0A=
Primary instruction cache 16kb, linesize 16 bytes (4 ways)=0A=
Primary data cache 16kb, linesize 16 bytes (4 ways)=0A=
Linux version 2.4.18-MIPS-01.01 (carstenl@coplin20.mips.com) (gcc =
version 2.96-2Determined physical RAM map:=0A=
 memory: 00001000 @ 00000000 (reserved)=0A=
 memory: 000ef000 @ 00001000 (ROM data)=0A=
 memory: 00010000 @ 000f0000 (reserved)=0A=
 memory: 006ac000 @ 00100000 (reserved)=0A=
 memory: 03854000 @ 007ac000 (usable)=0A=
Initial ramdisk at: 0x802dc000 (4846464 bytes)=0A=
On node 0 totalpages: 16384=0A=
zone(0): 16384 pages.=0A=
zone(1): 0 pages.=0A=
zone(2): 0 pages.=0A=
Kernel command line:  console=3DttyS0,38400=0A=
calculating r4koff... 00061a8f(400015)=0A=
CPU frequency 80.00 MHz=0A=
Console: colour dummy device 80x25=0A=
Calibrating delay loop... 53.24 BogoMIPS=0A=
Memory: 56640k/57680k available (1647k kernel code, 1040k reserved, =
4860k data,)Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)=0A=
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)=0A=
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)=0A=
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)=0A=
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)=0A=
Checking for 'wait' instruction...  available.=0A=
POSIX conformance testing by UNIFIX=0A=
PCI: Probing PCI hardware on host bus 0.=0A=
Linux NET4.0 for Linux 2.4=0A=
Based upon Swansea University Computer Society NET3.039=0A=
Initializing RT netlink socket=0A=
Starting kswapd=0A=
initialize_kbd: Keyboard reset failed, no ACK=0A=
Detected PS/2 Mouse Port.=0A=
pty: 256 Unix98 ptys configured=0A=
keyboard: Timeout - AT keyboard not present?(ed)=0A=
keyboard: Timeout - AT keyboard not present?(f4)=0A=
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ =
SERIAL_PCI edttyS00 at 0x03f8 (irq =3D 4) is a 16550A=0A=
ttyS01 at 0x02f8 (irq =3D 3) is a 16550A=0A=
rtc: SRM (post-2000) epoch (2000) detected=0A=
Real Time Clock Driver v1.10e=0A=
block: 128 slots per queue, batch=3D32=0A=
RAMDISK driver initialized: 16 RAM disks of 18432K size 1024 blocksize=0A=
Uniform Multi-Platform E-IDE driver Revision: 6.31=0A=
ide: Assuming 33MHz system bus speed for PIO modes; override with =
idebus=3Dxx=0A=
PIIX4: IDE controller on PCI bus 00 dev 51=0A=
PIIX4: chipset revision 1=0A=
PIIX4: not 100% native mode: will probe irqs later=0A=
    ide0: BM-DMA at 0x1240-0x1247, BIOS settings: hda:pio, hdb:pio=0A=
    ide1: BM-DMA at 0x1248-0x124f, BIOS settings: hdc:pio, hdd:pio=0A=
hda: Maxtor 6E040L0, ATA DISK drive=0A=
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14=0A=
hda: 80293248 sectors (41110 MB) w/2048KiB Cache, CHS=3D79656/16/63, =
UDMA(33)=0A=
Partition check:=0A=
 hda: unknown partition table=0A=
loop: loaded (max 8 devices)=0A=
pcnet32_probe_pci: found device 0x001022.0x002000=0A=
    ioaddr=3D0x001200  resource_flags=3D0x000101=0A=
Linux video capture interface: v1.00=0A=
es1371: version v0.30 time 11:57:12 Nov 21 2002=0A=
NET4: Linux TCP/IP 1.0 for NET4.0=0A=
IP Protocols: ICMP, UDP, TCP=0A=
IP: routing cache hash table of 512 buckets, 4Kbytes=0A=
TCP: Hash tables configured (established 4096 bind 4096)=0A=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.=0A=
RAMDISK: Compressed image found at block 0=0A=
Freeing initrd memory: 4732k freed=0A=
EXT2-fs warning: checktime reached, running e2fsck is recommended=0A=
VFS: Mounted root (ext2 filesystem).=0A=
Freeing prom memory: 956kb freed=0A=
Freeing unused kernel memory: 120k freed=0A=
Algorithmics/MIPS FPU Emulator v1.5=0A=
Setting network parameters:  [  OK  ]=0A=
Bringing up interface lo:  [  OK  ]=0A=
Starting portmapper: [  OK  ]=0A=
=0A=
Welcome to the MIPS installation of RedHat RPMS.=0A=
=0A=
Install method (CD-ROM, NFS) [CD-ROM] NFS=0A=
=0A=
IP-address of target system: [192.168.201.68] 192.168.114.150=0A=
SIOCSIFADDR: No such device=0A=
eth0: unknown interface: No such device=0A=
=0A=
IP-address of target system is wrong, please try again=0A=
=0A=
IP-address of target system: [192.168.201.68]=0A=
SIOCSIFADDR: No such device=0A=
eth0: unknown interface: No such device=0A=
=0A=
IP-address of target system is wrong, please try again=0A=
=0A=
IP-address of target system: [192.168.201.68]=0A=

------=_NextPart_000_0026_01C38CDA.0C0243A0--


From macro@ds2.pg.gda.pl Wed Oct  8 10:06:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 10:06:12 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:43410 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225388AbTJHJGE>; Wed, 8 Oct 2003 10:06:04 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA26905;
	Wed, 8 Oct 2003 11:05:53 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 8 Oct 2003 11:05:53 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Proposed NMI handling interface...
In-Reply-To: <3F832040.7070606@realitydiluted.com>
Message-ID: <Pine.GSO.3.96.1031008105647.26799A-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: 3375
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 723
Lines: 17

On Tue, 7 Oct 2003, Steven J. Hill wrote:

> I wanted to propose an NMI handling interface. I have attached
> the header file and patches to 'arch/mips/kernel/traps.c'. The
> user need only specify the offset address for the NMI vector
> code and then they can also specify their own desired NMI
> function. Comments?

 You should consider something like "#define nmi_user_handler ((void
(*)(struct pt_regs *))0)" for !CONFIG_NMI and possibly also a way to
return from the frontend gracefully if the backend says it's OK.

-- 
+  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 Oct  8 15:23:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 15:24:11 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:42352
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225546AbTJHOXj>; Wed, 8 Oct 2003 15:23:39 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A7FE1-0002TY-00; Wed, 08 Oct 2003 16:23:37 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A7FE1-0004af-00; Wed, 08 Oct 2003 16:23:37 +0200
Date: Wed, 8 Oct 2003 16:23:37 +0200
To: debian-mips@lists.debian.org
Cc: linux-mips@linux-mips.org
Subject: Re: Question about use of PMAD-AA ethernet adapter on Decstation
Message-ID: <20031008142337.GI12409@rembrandt.csv.ica.uni-stuttgart.de>
References: <20031006202941.GS16118@opengraphics.com> <20031006213700.GA482@excalibur.cologne.de> <20031007142422.GU16118@opengraphics.com> <20031007174733.GX16118@opengraphics.com> <20031007180804.GQ9600@rembrandt.csv.ica.uni-stuttgart.de> <20031007191159.GY16118@opengraphics.com> <20031007205622.GT9600@rembrandt.csv.ica.uni-stuttgart.de> <20031008134509.GZ16118@opengraphics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031008134509.GZ16118@opengraphics.com>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3376
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2581
Lines: 67

Len Sorensen wrote:
> On Tue, Oct 07, 2003 at 10:56:22PM +0200, Thiemo Seufer wrote:
> > Len Sorensen wrote:
> > [snip]
> > > Trace; 8005da74 <update_process_times+34/11c>
> > > Trace; 8005dd18 <timer_bh+160/168>
> > > Trace; 8005de64 <do_timer+144/14c>
> > > Trace; 800598e4 <bh_action+60/d8>
> > > Trace; 801263bc <timer_interrupt+f8/1cc>
> > > Trace; 800596a0 <tasklet_hi_action+110/1a4>
> > > Trace; 80158898 <lance_interrupt+2b0/2d8>
> > > Trace; 80158888 <lance_interrupt+2a0/2d8>
> > > Trace; 80059170 <do_softirq+1a0/1a8>
> > > Trace; 8004a6e8 <do_IRQ+e4/12c>
> > > Trace; 8004a728 <do_IRQ+124/12c>
> > > Trace; 80125574 <handle_it+8/10>
> > > Trace; 80125574 <handle_it+8/10>
> > > Trace; 800432dc <cpu_idle+6c/74>
> > > Trace; 800432c0 <cpu_idle+50/74>
> > > Trace; 8020a37c <p.1+324/d38>
> > > Trace; 8004042c <init+0/194>
> > > Trace; 8020959c <genexcept_early+dc/9f0>
> > 
> > Those twice mentioned functions look funny.
> 
> I wonder if both drivers got an interrupt at the same time, but I am not
> really sure how interrupts are handled in the kernel.

The code in linux/arch/mips/dec/int-handler.S should serialize incoming
interrupts. I guess the stack trace was already overwritten in some way,
it is bogus. E.g., handle_it could never call itself.

> > [snip]
> > > Command running: ping 192.168.8.255\
> > > 
> > > About 15 machines are on the network and were responding to the ping.
> > 
> > Does the DECstation work stable in this case if it runs only with
> > the onboard interface?
> 
> I have had uptimes of 2 months on this machine, doing apt-get upgrades
> and such.  Never had it lock up on me before I tried using the PMAD-AA
> yesterday.
> 
> > Any chance the PMAD-AA crashes always after the same amount of
> > rx/tx traffic?
> 
> Doesn't look like it.  I wonder if it needs both network cards to have
> an interrupt simultaniously for it to happen.  I am having a hard time
> rerpoducing it today.
> 
> > Btw, while looking at the drivers source, I found some strange bits:
> > In dec_lance_init(), the lp->[rt]x_buf_ptr_cpu pointers for PMAD-AA are
> > initialized differently than the others, but the cp_{to,from}_buf()
> > functions handle it the same way than the onboard interface. AFAICS
> > this is a bug.
> > 
> > Further, dev->mem_end is only initialized for the onboard lance, not
> > for the others, but that's probably a minor glitch.
> 
> So at least a couple of things look like they need a bit of fixing then.

Unfortunately I don't have a PMAD-AA, but probably some of the
linux-mips folks can help. I'm Cc'ing that list.


Thiemo

From macro@ds2.pg.gda.pl Wed Oct  8 16:31:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 16:31:21 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:28064 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225545AbTJHPbS>; Wed, 8 Oct 2003 16:31:18 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA01514;
	Wed, 8 Oct 2003 17:31:10 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 8 Oct 2003 17:31:09 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: debian-mips@lists.debian.org, linux-mips@linux-mips.org
Subject: Re: Question about use of PMAD-AA ethernet adapter on Decstation
In-Reply-To: <20031008142337.GI12409@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1031008162829.26799D-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: 3377
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 4614
Lines: 95

On Wed, 8 Oct 2003, Thiemo Seufer wrote:

> > > [snip]
> > > > Trace; 8005da74 <update_process_times+34/11c>
> > > > Trace; 8005dd18 <timer_bh+160/168>
> > > > Trace; 8005de64 <do_timer+144/14c>
> > > > Trace; 800598e4 <bh_action+60/d8>
> > > > Trace; 801263bc <timer_interrupt+f8/1cc>
> > > > Trace; 800596a0 <tasklet_hi_action+110/1a4>
> > > > Trace; 80158898 <lance_interrupt+2b0/2d8>
> > > > Trace; 80158888 <lance_interrupt+2a0/2d8>
> > > > Trace; 80059170 <do_softirq+1a0/1a8>
> > > > Trace; 8004a6e8 <do_IRQ+e4/12c>
> > > > Trace; 8004a728 <do_IRQ+124/12c>
> > > > Trace; 80125574 <handle_it+8/10>
> > > > Trace; 80125574 <handle_it+8/10>
> > > > Trace; 800432dc <cpu_idle+6c/74>
> > > > Trace; 800432c0 <cpu_idle+50/74>
> > > > Trace; 8020a37c <p.1+324/d38>
> > > > Trace; 8004042c <init+0/194>
> > > > Trace; 8020959c <genexcept_early+dc/9f0>
> > > 
> > > Those twice mentioned functions look funny.

 The trace dump looks through the kernel stack and uses simple heuristics
to judge whether a word should be included or not: if it is in the range
covered by the kernel's text segment, it's printed.  It might be pure
coincidence a specific value corresponding to a kernel address is present
at the stack as it may actually be a leftover from past execution, e.g. 
within a stack frame reserved for local variables that hasn't been
initialized yet, or are simply unused for a particular execution path. 
You need to analyze the backtrace, comparing it to actual code involved to
see which of the addresses are results of real function calls. 

> > I wonder if both drivers got an interrupt at the same time, but I am not
> > really sure how interrupts are handled in the kernel.
> 
> The code in linux/arch/mips/dec/int-handler.S should serialize incoming
> interrupts. I guess the stack trace was already overwritten in some way,
> it is bogus. E.g., handle_it could never call itself.

 Well, most interrupt handlers can be interrupted by other interrupts,
only the high priority ones cannot.  These are marked with SA_INTERRUPT in
the flags.  Of course the entry code for IRQ handling cannot be
interrupted and only a single interrupt source is selected for handling
based on predefined priorities, but once execution reaches
handle_IRQ_event() (which calls specific handlers registered by drivers),
another interrupt can be taken. 

 The trace doesn't look suspicious at first sight to me.

> > > Btw, while looking at the drivers source, I found some strange bits:
> > > In dec_lance_init(), the lp->[rt]x_buf_ptr_cpu pointers for PMAD-AA are
> > > initialized differently than the others, but the cp_{to,from}_buf()
> > > functions handle it the same way than the onboard interface. AFAICS
> > > this is a bug.

 The PMAD-A cannot be handled the same way as the others since it has a
sane buffer space layout, something that cannot be said of the others. 
Therefore the stock declance.c driver doesn't handle the PMAD-A properly
-- that's functionality that needs to be implemented when the driver gets
restructured (it'll happen for 2.6 and probably a backport to 2.4 will be
available later as well).  There is a patch that converts the stock driver
into one working for the PMAD-A (but it doesn't work for the others than)
and I'm told Debian uses thus modified code as a separate driver.  The
patch is based on work by Dave Airlie and is available here:
'ftp://ftp.ds2.pg.gda.pl/pub/macro/drivers/pmad-a/patch-mips-2.4.20-pre6-20021222-declance-pmad-12.gz' 
-- it applies cleanly to the current version of declance.c.

> > > Further, dev->mem_end is only initialized for the onboard lance, not
> > > for the others, but that's probably a minor glitch.

 Both dev->mem_start and dev->mem_end are initialized incorrectly as they
should use bus addresses and now they use CPU virtual ones.  For
MIPS-based TURBOchannel systems, the mapping between the addresses is
quite straightforward, but it's not necessarily the case for the others.
The addresses should also be used for I/O resource allocation mamagement
which is not implemented in the driver.

 Your point about dev->mem_end is of course valid -- the bug wasn't
noticed, because the variable isn't used for anything in these cases.

> Unfortunately I don't have a PMAD-AA, but probably some of the
> linux-mips folks can help. I'm Cc'ing that list.

 Please send me the full oops report and I'll see what I can decipher from
it.

  Maciej

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


From ralf@linux-mips.org Wed Oct  8 17:06:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 17:06:10 +0100 (BST)
Received: from p508B7CAD.dip.t-dialin.net ([IPv6:::ffff:80.139.124.173]:23211
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225548AbTJHQGE>; Wed, 8 Oct 2003 17:06: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 h98G61NK019738;
	Wed, 8 Oct 2003 18:06:01 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h98G60gm019737;
	Wed, 8 Oct 2003 18:06:00 +0200
Date: Wed, 8 Oct 2003 18:06:00 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Proposed NMI handling interface...
Message-ID: <20031008160600.GA19102@linux-mips.org>
References: <3F832040.7070606@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F832040.7070606@realitydiluted.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: 3378
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 922
Lines: 18

On Tue, Oct 07, 2003 at 04:21:20PM -0400, Steven J. Hill wrote:

> I wanted to propose an NMI handling interface. I have attached
> the header file and patches to 'arch/mips/kernel/traps.c'. The
> user need only specify the offset address for the NMI vector
> code and then they can also specify their own desired NMI
> function. Comments?

That hook you're proposing isn't even necessary in generic code.  NMI
on MIPS hardware is a fairly odd type of exception - it goes straight to
0xbfc00000 which usually is a a firmware address - and lots of firmware
doesn't even offer an NMI hook.  So for those cases where it's possible,
you need to do something firmware anyway before jumping to Linux's NMI
handler.  An additional problem with the NMI design of MIPS is it's using
ErrorEPC, just like cache errors so you better pray - or simply design
systems only to rely on NMI for debugging and catastrophic failures.

  Ralf

From ica2_ts@csv.ica.uni-stuttgart.de Wed Oct  8 17:10:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 17:11:00 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:42609
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225454AbTJHQKV>; Wed, 8 Oct 2003 17:10:21 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A7GtF-0003Xj-00; Wed, 08 Oct 2003 18:10:17 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A7GtF-0004yZ-00; Wed, 08 Oct 2003 18:10:17 +0200
Date: Wed, 8 Oct 2003 18:10:17 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: debian-mips@lists.debian.org, linux-mips@linux-mips.org
Subject: Re: Question about use of PMAD-AA ethernet adapter on Decstation
Message-ID: <20031008161017.GL12409@rembrandt.csv.ica.uni-stuttgart.de>
References: <20031008142337.GI12409@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1031008162829.26799D-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.1031008162829.26799D-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3379
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 3252
Lines: 71

Maciej W. Rozycki wrote:
> On Wed, 8 Oct 2003, Thiemo Seufer wrote:
> 
> > > > [snip]
> > > > > Trace; 8005da74 <update_process_times+34/11c>
> > > > > Trace; 8005dd18 <timer_bh+160/168>
> > > > > Trace; 8005de64 <do_timer+144/14c>
> > > > > Trace; 800598e4 <bh_action+60/d8>
> > > > > Trace; 801263bc <timer_interrupt+f8/1cc>
> > > > > Trace; 800596a0 <tasklet_hi_action+110/1a4>
> > > > > Trace; 80158898 <lance_interrupt+2b0/2d8>
> > > > > Trace; 80158888 <lance_interrupt+2a0/2d8>
> > > > > Trace; 80059170 <do_softirq+1a0/1a8>
> > > > > Trace; 8004a6e8 <do_IRQ+e4/12c>
> > > > > Trace; 8004a728 <do_IRQ+124/12c>
> > > > > Trace; 80125574 <handle_it+8/10>
> > > > > Trace; 80125574 <handle_it+8/10>
> > > > > Trace; 800432dc <cpu_idle+6c/74>
> > > > > Trace; 800432c0 <cpu_idle+50/74>
> > > > > Trace; 8020a37c <p.1+324/d38>
> > > > > Trace; 8004042c <init+0/194>
> > > > > Trace; 8020959c <genexcept_early+dc/9f0>
> > > > 
> > > > Those twice mentioned functions look funny.
> 
>  The trace dump looks through the kernel stack and uses simple heuristics
> to judge whether a word should be included or not: if it is in the range
> covered by the kernel's text segment, it's printed.  It might be pure
> coincidence a specific value corresponding to a kernel address is present
> at the stack as it may actually be a leftover from past execution, e.g. 
> within a stack frame reserved for local variables that hasn't been
> initialized yet, or are simply unused for a particular execution path. 
> You need to analyze the backtrace, comparing it to actual code involved to
> see which of the addresses are results of real function calls. 

Ouch. I assumed ksymoops would do stack frame analysis.

[snip]
> There is a patch that converts the stock driver
> into one working for the PMAD-A (but it doesn't work for the others than)
> and I'm told Debian uses thus modified code as a separate driver.  The
> patch is based on work by Dave Airlie and is available here:
> 'ftp://ftp.ds2.pg.gda.pl/pub/macro/drivers/pmad-a/patch-mips-2.4.20-pre6-20021222-declance-pmad-12.gz' 
> -- it applies cleanly to the current version of declance.c.

Debian calls this specific driver pmadaa.c. I looked only at declance.c,
which seems to be the same as te linux-mips CVS version.

> > > > Further, dev->mem_end is only initialized for the onboard lance, not
> > > > for the others, but that's probably a minor glitch.
> 
>  Both dev->mem_start and dev->mem_end are initialized incorrectly as they
> should use bus addresses and now they use CPU virtual ones.  For
> MIPS-based TURBOchannel systems, the mapping between the addresses is
> quite straightforward, but it's not necessarily the case for the others.
> The addresses should also be used for I/O resource allocation mamagement
> which is not implemented in the driver.
> 
>  Your point about dev->mem_end is of course valid -- the bug wasn't
> noticed, because the variable isn't used for anything in these cases.
> 
> > Unfortunately I don't have a PMAD-AA, but probably some of the
> > linux-mips folks can help. I'm Cc'ing that list.
> 
>  Please send me the full oops report and I'll see what I can decipher from
> it.

Forwarded separately. It can also be found in the debian-mips archive.


Thiemo

From ralf@linux-mips.org Wed Oct  8 17:30:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 17:30:06 +0100 (BST)
Received: from p508B7CAD.dip.t-dialin.net ([IPv6:::ffff:80.139.124.173]:49068
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225551AbTJHQaD>; Wed, 8 Oct 2003 17:30: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 h98GU2NK020258;
	Wed, 8 Oct 2003 18:30:02 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h98GTxxP020250;
	Wed, 8 Oct 2003 18:29:59 +0200
Date: Wed, 8 Oct 2003 18:29:59 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Steve Scott <steve.scott@pioneer-pdt.com>
Cc: jsun@mvista.com, linux-mips@linux-mips.org,
	craig.mautner@pioneer-pdt.com
Subject: Re: schedule() BUG
Message-ID: <20031008162959.GB19102@linux-mips.org>
References: <FJEIIOCBFAIOIDNKLPFJCECODAAA.koji.kawachi@pioneer-pdt.com> <017601c38c77$6d7225a0$2256fea9@janelle>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <017601c38c77$6d7225a0$2256fea9@janelle>
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: 3380
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1770
Lines: 37

On Mon, Oct 06, 2003 at 07:05:06PM -0700, Steve Scott wrote:

> We tried the fault.c patch Jun suggested, but it didn't solve the problem we were
> having with the BUG() in schedule(). The patch at the beginning of
> except_vec3_generic for the Vr5432 bug had previously been installed.
> 
> While chasing the BUG() in schedule(), though, we ran across another BUG() in
> alloc_skb() in ...linux/net/core/skbuff.c. :
> 
>     alloc_skb called nonatomically from interrupt 80117acc
>     kernel BUG at skbuff.c:179!
> 
> We changed the way sock_init_data initializes the 'allocation' field and
> were able to get past this one (see attached sock.c.patch). We're not sure
> if this fix needs to be permanent, or if it's just a temporary workaround.
> 
> For the schedule() BUG(), all evidence that we collected pointed to some
> interrupt causing us to reenter schedule() (i.e., somehow schedule() was
> called during an interrupt handler). We suspected something being run
> from the timer interrupt bottom half, but were never able to prove it. We
> also thought a remote possibility might be a pipeline hazard in the MIPS
> causing the EPC register not to update on a nested exception, but NEC says
> that can't happen on the Vr5432 that we're using...

Can't happen on any MIPS.

> We finally worked around the schedule BUG() by disabling interrupts
> during the context switch in schedule(). This workaround required changes
> in linux/kernel/sched.c and linux/arch/mips/kernel/r4k_switch.S (see attached
> patches).

Ouch.  Forgive but if I'd not already ignore these patches for being
ed-style I'd ignore them for being completly broken - these
patches are harmful for performance and probably not going to achieve
stability by anything other than luck ...

  Ralf

From ralf@linux-mips.org Wed Oct  8 17:37:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 17:37:07 +0100 (BST)
Received: from p508B7CAD.dip.t-dialin.net ([IPv6:::ffff:80.139.124.173]:12461
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225550AbTJHQhF>; Wed, 8 Oct 2003 17:37: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 h98Gb2NK020442;
	Wed, 8 Oct 2003 18:37:02 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h98Gb2In020441;
	Wed, 8 Oct 2003 18:37:02 +0200
Date: Wed, 8 Oct 2003 18:37:02 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
Subject: Re: time(2) for mips64
Message-ID: <20031008163702.GC19102@linux-mips.org>
References: <20031002.234116.74756712.anemo@mba.ocn.ne.jp> <Pine.GSO.3.96.1031003211755.5309A-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.1031003211755.5309A-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: 3381
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 322
Lines: 12

On Fri, Oct 03, 2003 at 09:20:11PM +0200, Maciej W. Rozycki wrote:

> > macro>  time(2) is obsolete (by gettimeofday(2)) and should be removed
> > macro> for new implementations.
> > 
> > Then could you apply these patches?
> 
>  I can, but they need an approval from Ralf.  Ralf, is the change OK? 

Yes, please.

  Ralf

From jh@hansen-telecom.dk Wed Oct  8 17:49:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 17:50:13 +0100 (BST)
Received: from smtp120.tiscali.dk ([IPv6:::ffff:62.79.79.111]:31229 "EHLO
	smtp120.tiscali.dk") by linux-mips.org with ESMTP
	id <S8225548AbTJHQtl>; Wed, 8 Oct 2003 17:49:41 +0100
Received: from cpmail.dk.tiscali.com (mail.tiscali.dk [212.54.64.159])
	by smtp120.tiscali.dk (8.12.6p3/8.12.6) with ESMTP id h98Gnexs021345
	for <linux-mips@linux-mips.org>; Wed, 8 Oct 2003 18:49:40 +0200 (CEST)
	(envelope-from jh@hansen-telecom.dk)
Received: from jorg (62.79.30.226) by cpmail.dk.tiscali.com (6.7.018)
        id 3F79565D000DFECE for linux-mips@linux-mips.org; Wed, 8 Oct 2003 18:49:40 +0200
From: =?iso-8859-1?Q?J=F8rg_Ulrich_Hansen?= <jh@hansen-telecom.dk>
To: "Linux-Mips" <linux-mips@linux-mips.org>
Subject: What toolchain for vr4181
Date: Wed, 8 Oct 2003 18:49:32 +0200
Message-ID: <EIEHIDHKGJLNEPLOGOPOAEIGCFAA.jh@hansen-telecom.dk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Return-Path: <jh@hansen-telecom.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3382
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jh@hansen-telecom.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 628
Lines: 23

Hi

I am about to start porting Linux to my hardware with an vr4181 processor.
The hardware is very close to the osprey architecture. Now my problem is
what toolchain to use.
I could do with an up to date opinion.

? gcc-2.95.3
? gcc-2.95.4
? egcs-1.1.2
? gcc-3.2
? binutils 2.13
? glibc 2.2.5
? Any patches
? http://www.ltc.com/~brad/mips/mips-cross-toolchain/index.html
? http://kegel.com/crosstool/

Where is a good starting point for a toolchain that will build and work?
I would prefere to build it my self because at a later state I might build
it under cygwin. But a prebuild does also have interest.

Kind regards Jorg


From karsten@excalibur.cologne.de Wed Oct  8 18:32:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 18:33:23 +0100 (BST)
Received: from natsmtp00.rzone.de ([IPv6:::ffff:81.169.145.165]:59887 "EHLO
	natsmtp00.webmailer.de") by linux-mips.org with ESMTP
	id <S8225548AbTJHRcv>; Wed, 8 Oct 2003 18:32:51 +0100
Received: from excalibur.cologne.de (pD951111A.dip.t-dialin.net [217.81.17.26])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id h98HWjHi006108;
	Wed, 8 Oct 2003 19:32:45 +0200 (MEST)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 1A7IEH-0000NX-00; Wed, 08 Oct 2003 19:36:05 +0200
Date: Wed, 8 Oct 2003 19:36:05 +0200
From: Karsten Merker <karsten@excalibur.cologne.de>
To: debian-mips@lists.debian.org, linux-mips@linux-mips.org
Subject: Re: Question about use of PMAD-AA ethernet adapter on Decstation
Message-ID: <20031008173605.GA1359@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	debian-mips@lists.debian.org, linux-mips@linux-mips.org
References: <20031008142337.GI12409@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1031008162829.26799D-100000@delta.ds2.pg.gda.pl> <20031008161017.GL12409@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031008161017.GL12409@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3383
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1042
Lines: 24

On Wed, Oct 08, 2003 at 06:10:17PM +0200, Thiemo Seufer wrote:
> Maciej W. Rozycki wrote:

> > There is a patch that converts the stock driver
> > into one working for the PMAD-A (but it doesn't work for the others than)
> > and I'm told Debian uses thus modified code as a separate driver.  The
> > patch is based on work by Dave Airlie and is available here:
> > 'ftp://ftp.ds2.pg.gda.pl/pub/macro/drivers/pmad-a/patch-mips-2.4.20-pre6-20021222-declance-pmad-12.gz' 
> > -- it applies cleanly to the current version of declance.c.
> 
> Debian calls this specific driver pmadaa.c. I looked only at declance.c,
> which seems to be the same as te linux-mips CVS version.

The pmadaa.c in the Debian kernel is basically the original work of
Dave Airlie with just very slight adjustments to make it compile
with 2.4.19.

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

From lsorense@opengraphics.com Wed Oct  8 20:42:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 20:42:41 +0100 (BST)
Received: from opengraphics.com ([IPv6:::ffff:216.208.162.194]:45994 "EHLO
	hurricane.opengraphics.com") by linux-mips.org with ESMTP
	id <S8225562AbTJHTmi>; Wed, 8 Oct 2003 20:42:38 +0100
Received: from lsorense by hurricane.opengraphics.com with local (Exim 3.36 #1 (Debian))
	id 1A7KCF-00026u-00; Wed, 08 Oct 2003 15:42:07 -0400
Date: Wed, 8 Oct 2003 15:42:07 -0400
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	debian-mips@lists.debian.org, linux-mips@linux-mips.org
Subject: Re: Question about use of PMAD-AA ethernet adapter on Decstation
Message-ID: <20031008194207.GA16118@opengraphics.com>
References: <20031008142337.GI12409@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1031008162829.26799D-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.1031008162829.26799D-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.3.28i
From: Len Sorensen <lsorense@opengraphics.com>
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.694, required 5,
	AWL, BAYES_00)
Return-Path: <lsorense@opengraphics.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3384
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lsorense@opengraphics.com
Precedence: bulk
X-list: linux-mips
Content-Length: 7636
Lines: 167

On Wed, Oct 08, 2003 at 05:31:09PM +0200, Maciej W. Rozycki wrote:
>  The trace dump looks through the kernel stack and uses simple heuristics
> to judge whether a word should be included or not: if it is in the range
> covered by the kernel's text segment, it's printed.  It might be pure
> coincidence a specific value corresponding to a kernel address is present
> at the stack as it may actually be a leftover from past execution, e.g. 
> within a stack frame reserved for local variables that hasn't been
> initialized yet, or are simply unused for a particular execution path. 
> You need to analyze the backtrace, comparing it to actual code involved to
> see which of the addresses are results of real function calls. 
> 
>  Well, most interrupt handlers can be interrupted by other interrupts,
> only the high priority ones cannot.  These are marked with SA_INTERRUPT in
> the flags.  Of course the entry code for IRQ handling cannot be
> interrupted and only a single interrupt source is selected for handling
> based on predefined priorities, but once execution reaches
> handle_IRQ_event() (which calls specific handlers registered by drivers),
> another interrupt can be taken. 
> 
>  The trace doesn't look suspicious at first sight to me.
> 
>  The PMAD-A cannot be handled the same way as the others since it has a
> sane buffer space layout, something that cannot be said of the others. 
> Therefore the stock declance.c driver doesn't handle the PMAD-A properly
> -- that's functionality that needs to be implemented when the driver gets
> restructured (it'll happen for 2.6 and probably a backport to 2.4 will be
> available later as well).  There is a patch that converts the stock driver
> into one working for the PMAD-A (but it doesn't work for the others than)
> and I'm told Debian uses thus modified code as a separate driver.  The
> patch is based on work by Dave Airlie and is available here:
> 'ftp://ftp.ds2.pg.gda.pl/pub/macro/drivers/pmad-a/patch-mips-2.4.20-pre6-20021222-declance-pmad-12.gz' 
> -- it applies cleanly to the current version of declance.c.

Well I am runing declance for the onboard and pmadaa for the add on card
as far as I can tell.

>  Both dev->mem_start and dev->mem_end are initialized incorrectly as they
> should use bus addresses and now they use CPU virtual ones.  For
> MIPS-based TURBOchannel systems, the mapping between the addresses is
> quite straightforward, but it's not necessarily the case for the others.
> The addresses should also be used for I/O resource allocation mamagement
> which is not implemented in the driver.
> 
>  Your point about dev->mem_end is of course valid -- the bug wasn't
> noticed, because the variable isn't used for anything in these cases.
> 
>  Please send me the full oops report and I'll see what I can decipher from
> it.

Here is what I got on the console:

Instruction bus error, epc == 80045ae0, ra == 8005d8a8
Oops in traps.c::do_be, line 491:
$0 : 00000000 80280000 80280000 000f48b0 8027ef94 000f48b0 8027ef94 00000000
$8 : 8023e108 bc040000 00000020 874d227c 86b857e4 86b857e8 86b857e0 00000008
$16: 00000000 00000000 00000000 8027ebc0 80259820 fffffffe 00000000 04102060
$24: 00000000 2b107a90                   8023e000 8023fde0 8043ff80 8005d8a8
Hi : 00000000
Lo : 00000600
epc  : 80045ae0    Not tainted
Status: 1000e400
Cause : 00000018
Process swapper (pid: 0, stackpage=8023e000)
Stack:    00000000 8005da74 00000000 04102060 00000001 8005dd18 8027ebe0
 20000001 8027ebe0 8005de64 8027ebe0 800598e4 00000000 811b2940 8023fea8
 801263bc 800596a0 00000000 80158898 80158888 000000c0 80259848 00000000
 80259838 fffffffe 1000e400 8023fea8 00000000 80059170 30000400 fffffffb
 00000011 8004a6e8 8667c000 802590d0 8026c97c fffffffb 0000000d 8004a728
 8044e2d0 ...
Call Trace:   [<8005da74>] [<8005dd18>] [<8005de64>] [<800598e4>] [<801263bc>]
 [<800596a0>] [<80158898>] [<80158888>] [<80059170>] [<8004a6e8>] [<8004a728>]
 [<80125574>] [<80125574>] [<800432dc>] [<800432c0>] [<8020a37c>] [<8004042c>]
 [<8020959c>]

Code: 03a02021  080115e0  00000000 <401a6000> 00000000  001ad0c0  07400003  03a0d821  3c1b802b
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

Through ksymoops it gets to be:

Instruction bus error, epc == 80045ae0, ra == 8005d8a8
Oops in traps.c::do_be, line 491:
$0 : 00000000 80280000 80280000 000f48b0 8027ef94 000f48b0 8027ef94 00000000
$8 : 8023e108 bc040000 00000020 874d227c 86b857e4 86b857e8 86b857e0 00000008
$16: 00000000 00000000 00000000 8027ebc0 80259820 fffffffe 00000000 04102060
$24: 00000000 2b107a90                   8023e000 8023fde0 8043ff80 8005d8a8
Hi : 00000000
Lo : 00000600
epc  : 80045ae0    Not tainted
Using defaults from ksymoops -t elf32-tradlittlemips -a mips:3000
Status: 1000e400
Cause : 00000018
Process swapper (pid: 0, stackpage=8023e000)
Stack:    00000000 8005da74 00000000 04102060 00000001 8005dd18 8027ebe0
 20000001 8027ebe0 8005de64 8027ebe0 800598e4 00000000 811b2940 8023fea8
 801263bc 800596a0 00000000 80158898 80158888 000000c0 80259848 00000000
 80259838 fffffffe 1000e400 8023fea8 00000000 80059170 30000400 fffffffb
 00000011 8004a6e8 8667c000 802590d0 8026c97c fffffffb 0000000d 8004a728
 8044e2d0 ...
Call Trace:   [<8005da74>] [<8005dd18>] [<8005de64>] [<800598e4>] [<801263bc>]
 [<800596a0>] [<80158898>] [<80158888>] [<80059170>] [<8004a6e8>] [<8004a728>]
 [<80125574>] [<80125574>] [<800432dc>] [<800432c0>] [<8020a37c>] [<8004042c>]
 [<8020959c>]
Code: 03a02021  080115e0  00000000 <401a6000> 00000000  001ad0c0  07400003  03a0d821  3c1b802b


>>RA;  8005d8a8 <update_wall_time+18/7c>
>>$1; 80280000 <uidhash_table+2c/40c>
>>$2; 80280000 <uidhash_table+2c/40c>
>>$4; 8027ef94 <xtime+4/8>
>>$6; 8027ef94 <xtime+4/8>
>>$8; 8023e108 <init_task_union+108/2000>
>>$19; 8027ebc0 <irq_stat+0/20>
>>$20; 80259820 <tasklet_hi_vec+0/10>
>>$28; 8023e000 <init_task_union+0/2000>
>>$29; 8023fde0 <init_task_union+1de0/2000>
>>$31; 8005d8a8 <update_wall_time+18/7c>

>>PC;  80045ae0 <handle_ibe+0/cc>   <=====

Trace; 8005da74 <update_process_times+34/11c>
Trace; 8005dd18 <timer_bh+160/168>
Trace; 8005de64 <do_timer+144/14c>
Trace; 800598e4 <bh_action+60/d8>
Trace; 801263bc <timer_interrupt+f8/1cc>
Trace; 800596a0 <tasklet_hi_action+110/1a4>
Trace; 80158898 <lance_interrupt+2b0/2d8>
Trace; 80158888 <lance_interrupt+2a0/2d8>
Trace; 80059170 <do_softirq+1a0/1a8>
Trace; 8004a6e8 <do_IRQ+e4/12c>
Trace; 8004a728 <do_IRQ+124/12c>
Trace; 80125574 <handle_it+8/10>
Trace; 80125574 <handle_it+8/10>
Trace; 800432dc <cpu_idle+6c/74>
Trace; 800432c0 <cpu_idle+50/74>
Trace; 8020a37c <p.1+324/d38>
Trace; 8004042c <init+0/194>
Trace; 8020959c <genexcept_early+dc/9f0>

Code;  80045ad4 <handle_ades_int+28/34>
00000000 <_PC>:
Code;  80045ad4 <handle_ades_int+28/34>
   0:   03a02021  move    a0,sp
Code;  80045ad8 <handle_ades_int+2c/34>
   4:   080115e0  j       45780 <_PC+0x45780>
Code;  80045adc <handle_ades_int+30/34>
   8:   00000000  nop
Code;  80045ae0 <handle_ibe+0/cc>   <=====
   c:   401a6000  mfc0    k0,$12   <=====
Code;  80045ae4 <handle_ibe+4/cc>
  10:   00000000  nop
Code;  80045ae8 <handle_ibe+8/cc>
  14:   001ad0c0  sll     k0,k0,0x3
Code;  80045aec <handle_ibe+c/cc>
  18:   07400003  bltz    k0,28 <_PC+0x28>
Code;  80045af0 <handle_ibe+10/cc>
  1c:   03a0d821  move    k1,sp
Code;  80045af4 <handle_ibe+14/cc>
  20:   3c1b802b  lui     k1,0x802b

Kernel panic: Aiee, killing interrupt handler!

Does that help anything?  If not I may just have to assume it was a
fluke that the machine crashed twice in 15 minutes after putting in the
PMAD-AA card.  I haven't managed to make it crash today.

Len Sorensen

From sjhill@realitydiluted.com Wed Oct  8 21:12:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 21:12:28 +0100 (BST)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:64413
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225562AbTJHUM0>; Wed, 8 Oct 2003 21:12:26 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1A7KfU-0004Fv-00
	for <linux-mips@linux-mips.org>; Wed, 08 Oct 2003 15:12:20 -0500
Message-ID: <3F846FA3.6090208@realitydiluted.com>
Date: Wed, 08 Oct 2003 16:12:19 -0400
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030930 Debian/1.4-5
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: [PATCH] Toshiba RBTX4927 NMI handling code....
Content-Type: multipart/mixed;
 boundary="------------040801090006060007020702"
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3385
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 7581
Lines: 231

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

Greetings.

If no one has any objections, I would like to apply this patch.
This utilizes the NMI present on the RBTX4927 board and is quite
handy for debugging purposes. I have also refined my earlier NMI
code a bit and believe this to be much cleaner than before.

-Steve

--------------040801090006060007020702
Content-Type: text/plain;
 name="toshiba-rbtx4927-nmi.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="toshiba-rbtx4927-nmi.patch"

diff -urN linux/arch/mips/config-shared.in linux-patched/arch/mips/config-shared.in
--- linux/arch/mips/config-shared.in	Wed Sep 10 15:06:10 2003
+++ linux-patched/arch/mips/config-shared.in	Wed Oct  8 14:06:55 2003
@@ -647,6 +647,7 @@
    define_bool CONFIG_SWAP_IO_SPACE_L y
    define_bool CONFIG_ISA y
    define_bool CONFIG_NONCOHERENT_IO y
+   define_bool CONFIG_NMI y
 fi
 if [ "$CONFIG_VICTOR_MPC30X" = "y" ]; then
    define_bool CONFIG_IRQ_CPU y
diff -urN linux/arch/mips/defconfig-rbtx4927 linux-patched/arch/mips/defconfig-rbtx4927
--- linux/arch/mips/defconfig-rbtx4927	Tue Sep  9 20:17:31 2003
+++ linux-patched/arch/mips/defconfig-rbtx4927	Wed Oct  8 14:07:23 2003
@@ -1,5 +1,5 @@
 #
-# Automatically generated by make menuconfig: don't edit
+# Automatically generated make config: don't edit
 #
 CONFIG_MIPS=y
 CONFIG_MIPS32=y
@@ -76,7 +76,7 @@
 CONFIG_SWAP_IO_SPACE_L=y
 CONFIG_ISA=y
 CONFIG_NONCOHERENT_IO=y
-CONFIG_DUMMY_KEYB=y
+CONFIG_NMI=y
 # CONFIG_MIPS_AU1000 is not set
 
 #
@@ -199,6 +199,10 @@
 # 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
 
@@ -407,7 +411,6 @@
 # CONFIG_ESPSERIAL is not set
 # CONFIG_MOXA_INTELLIO is not set
 # CONFIG_MOXA_SMARTIO is not set
-# CONFIG_ISI is not set
 # CONFIG_SYNCLINK is not set
 # CONFIG_SYNCLINKMP is not set
 # CONFIG_N_HDLC is not set
@@ -416,12 +419,11 @@
 # CONFIG_SX is not set
 # CONFIG_RIO is not set
 # CONFIG_STALDRV is not set
-CONFIG_SERIAL_TXX9=y
-CONFIG_SERIAL_TXX9_CONSOLE=y
 # CONFIG_SERIAL_TX3912 is not set
 # CONFIG_SERIAL_TX3912_CONSOLE is not set
+CONFIG_SERIAL_TXX9=y
+CONFIG_SERIAL_TXX9_CONSOLE=y
 # CONFIG_TXX927_SERIAL is not set
-# CONFIG_TXX927_SERIAL_CONSOLE is not set
 # CONFIG_UNIX98_PTYS is not set
 
 #
@@ -439,6 +441,14 @@
 # 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
diff -urN linux/arch/mips/kernel/traps.c linux-patched/arch/mips/kernel/traps.c
--- linux/arch/mips/kernel/traps.c	Wed Sep 10 15:06:10 2003
+++ linux-patched/arch/mips/kernel/traps.c	Wed Oct  8 14:03:03 2003
@@ -1009,6 +1009,14 @@
 		restore_fp_context = fpu_emulator_restore_context;
 	}
 
+#ifdef CONFIG_NMI
+	{
+		extern void nmi_handler_setup (void);
+
+		nmi_handler_setup();
+	}
+#endif
+
 	flush_icache_range(KSEG0, KSEG0 + 0x400);
 
 	atomic_inc(&init_mm.mm_count);	/* XXX UP?  */
diff -urN linux/arch/mips/tx4927/toshiba_rbtx4927/Makefile linux-patched/arch/mips/tx4927/toshiba_rbtx4927/Makefile
--- linux/arch/mips/tx4927/toshiba_rbtx4927/Makefile	Fri Apr 11 13:26:20 2003
+++ linux-patched/arch/mips/tx4927/toshiba_rbtx4927/Makefile	Wed Oct  8 14:04:27 2003
@@ -16,5 +16,6 @@
 
 obj-$(CONFIG_PCI)	+= toshiba_rbtx4927_pci_fixup.o 
 obj-$(CONFIG_PCI)	+= toshiba_rbtx4927_pci_ops.o 
+obj-$(CONFIG_NMI)	+= toshiba_rbtx4927_nmi.o
 
 include $(TOPDIR)/Rules.make
diff -urN linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S linux-patched/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S
--- linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S	Wed Dec 31 19:00:00 1969
+++ linux-patched/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S	Wed Oct  8 14:03:29 2003
@@ -0,0 +1,46 @@
+/*
+ * linux/arch/mips/tx4927/toshiba_rbtx4927/tx4927_irq_handler.S
+ *
+ * NMI handler for Toshiba RBTX4927 board
+ *
+ * Copyright (C) 2003 TimeSys Corp.
+ *                    S. James Hill (James.Hill@timesys.com)
+ *                                  (sjhill@realitydiluted.com)
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ *
+ *  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
+ *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include <asm/regdef.h>
+#include <asm/stackframe.h>
+
+		.align	5
+		.set noat
+		NESTED(tx4927_nmi_handler, PT_SIZE, sp)
+		SAVE_ALL
+		CLI
+		.set at
+		mfc0	k0, CP0_STATUS
+		lui	k1, 0x50		/* Clear BEV and NMI */
+		nor	k1, zero, k1
+		and	k0, k1
+		mtc0	k0, CP0_STATUS
+		move	a0, sp
+		jal	toshiba_rbtx4927_nmi
+		END(tx4927_nmi_handler)
diff -urN linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c linux-patched/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
--- linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	Thu Aug 28 10:04:47 2003
+++ linux-patched/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	Wed Oct  8 14:08:29 2003
@@ -907,6 +907,46 @@
 	/* no return */
 }
 
+#ifdef CONFIG_NMI
+void toshiba_rbtx4927_nmi (struct pt_regs *regs)
+{
+	extern void show_code(unsigned int *pc);
+	extern void show_runqueue(void);
+	extern void show_stack(unsigned int *sp);
+	extern void show_state_nolock(void);
+	extern void show_trace(unsigned long *sp, unsigned int *ra,
+			       unsigned int *pc);
+
+	bust_spinlocks(1);
+	printk("\ncurrent = %d:%s\n",current->pid,current->comm);
+	show_regs(regs);
+	printk("Process %s (pid: %d, stackpage=%08lx)\n",
+		current->comm, current->pid, (unsigned long) current);
+	show_stack((unsigned int *)regs->regs[29]);
+	show_trace((unsigned long *)regs->regs[29], 
+	           (unsigned int *)regs->regs[31],
+	           (unsigned int *)regs->cp0_epc);
+	show_code((unsigned int *)regs->cp0_epc);
+	bust_spinlocks(0);
+}
+
+void nmi_handler_setup (void)
+{
+	extern void tx4927_nmi_handler (void);
+	unsigned long vec[2];
+
+	vec[0] = 0x08000000 |
+			(0x03ffffff & ((unsigned long)tx4927_nmi_handler >> 2));
+	vec[1] = 0;
+
+	/*
+	 * Our firmware (PMON in this case) has a NMI hook that
+	 * jumps to 0x80000220. We locate our NMI handler there.
+	 */
+	memcpy((void *)(KSEG0 + 0x220), &vec, 0x8);
+}
+#endif
+
 void __init toshiba_rbtx4927_setup(void)
 {
 	vu32 cp0_config;

--------------040801090006060007020702--


From jsun@mvista.com Wed Oct  8 22:18:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 22:18:19 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:57332 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225460AbTJHVSN>;
	Wed, 8 Oct 2003 22:18:13 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h98LI8106647;
	Wed, 8 Oct 2003 14:18:08 -0700
Date: Wed, 8 Oct 2003 14:18:08 -0700
From: Jun Sun <jsun@mvista.com>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [PATCH] Toshiba RBTX4927 NMI handling code....
Message-ID: <20031008141808.H3887@mvista.com>
References: <3F846FA3.6090208@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3F846FA3.6090208@realitydiluted.com>; from sjhill@realitydiluted.com on Wed, Oct 08, 2003 at 04:12:19PM -0400
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3386
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 7973
Lines: 232


CONFIGs are ugly.  I think it is better to add just:

if (board_nmi_handler_setup)
	board_nmi_handler_setup();

Define board_nmi_handler_setup and function pointer in traps.c
with NULL default value.

Each invidual board then decides whether it wants to initialize
the pointer to something meaningful or not.

Jun

On Wed, Oct 08, 2003 at 04:12:19PM -0400, Steven J. Hill wrote:
> Greetings.
> 
> If no one has any objections, I would like to apply this patch.
> This utilizes the NMI present on the RBTX4927 board and is quite
> handy for debugging purposes. I have also refined my earlier NMI
> code a bit and believe this to be much cleaner than before.
> 
> -Steve

> diff -urN linux/arch/mips/config-shared.in linux-patched/arch/mips/config-shared.in
> --- linux/arch/mips/config-shared.in	Wed Sep 10 15:06:10 2003
> +++ linux-patched/arch/mips/config-shared.in	Wed Oct  8 14:06:55 2003
> @@ -647,6 +647,7 @@
>     define_bool CONFIG_SWAP_IO_SPACE_L y
>     define_bool CONFIG_ISA y
>     define_bool CONFIG_NONCOHERENT_IO y
> +   define_bool CONFIG_NMI y
>  fi
>  if [ "$CONFIG_VICTOR_MPC30X" = "y" ]; then
>     define_bool CONFIG_IRQ_CPU y
> diff -urN linux/arch/mips/defconfig-rbtx4927 linux-patched/arch/mips/defconfig-rbtx4927
> --- linux/arch/mips/defconfig-rbtx4927	Tue Sep  9 20:17:31 2003
> +++ linux-patched/arch/mips/defconfig-rbtx4927	Wed Oct  8 14:07:23 2003
> @@ -1,5 +1,5 @@
>  #
> -# Automatically generated by make menuconfig: don't edit
> +# Automatically generated make config: don't edit
>  #
>  CONFIG_MIPS=y
>  CONFIG_MIPS32=y
> @@ -76,7 +76,7 @@
>  CONFIG_SWAP_IO_SPACE_L=y
>  CONFIG_ISA=y
>  CONFIG_NONCOHERENT_IO=y
> -CONFIG_DUMMY_KEYB=y
> +CONFIG_NMI=y
>  # CONFIG_MIPS_AU1000 is not set
>  
>  #
> @@ -199,6 +199,10 @@
>  # 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
>  
> @@ -407,7 +411,6 @@
>  # CONFIG_ESPSERIAL is not set
>  # CONFIG_MOXA_INTELLIO is not set
>  # CONFIG_MOXA_SMARTIO is not set
> -# CONFIG_ISI is not set
>  # CONFIG_SYNCLINK is not set
>  # CONFIG_SYNCLINKMP is not set
>  # CONFIG_N_HDLC is not set
> @@ -416,12 +419,11 @@
>  # CONFIG_SX is not set
>  # CONFIG_RIO is not set
>  # CONFIG_STALDRV is not set
> -CONFIG_SERIAL_TXX9=y
> -CONFIG_SERIAL_TXX9_CONSOLE=y
>  # CONFIG_SERIAL_TX3912 is not set
>  # CONFIG_SERIAL_TX3912_CONSOLE is not set
> +CONFIG_SERIAL_TXX9=y
> +CONFIG_SERIAL_TXX9_CONSOLE=y
>  # CONFIG_TXX927_SERIAL is not set
> -# CONFIG_TXX927_SERIAL_CONSOLE is not set
>  # CONFIG_UNIX98_PTYS is not set
>  
>  #
> @@ -439,6 +441,14 @@
>  # 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
> diff -urN linux/arch/mips/kernel/traps.c linux-patched/arch/mips/kernel/traps.c
> --- linux/arch/mips/kernel/traps.c	Wed Sep 10 15:06:10 2003
> +++ linux-patched/arch/mips/kernel/traps.c	Wed Oct  8 14:03:03 2003
> @@ -1009,6 +1009,14 @@
>  		restore_fp_context = fpu_emulator_restore_context;
>  	}
>  
> +#ifdef CONFIG_NMI
> +	{
> +		extern void nmi_handler_setup (void);
> +
> +		nmi_handler_setup();
> +	}
> +#endif
> +
>  	flush_icache_range(KSEG0, KSEG0 + 0x400);
>  
>  	atomic_inc(&init_mm.mm_count);	/* XXX UP?  */
> diff -urN linux/arch/mips/tx4927/toshiba_rbtx4927/Makefile linux-patched/arch/mips/tx4927/toshiba_rbtx4927/Makefile
> --- linux/arch/mips/tx4927/toshiba_rbtx4927/Makefile	Fri Apr 11 13:26:20 2003
> +++ linux-patched/arch/mips/tx4927/toshiba_rbtx4927/Makefile	Wed Oct  8 14:04:27 2003
> @@ -16,5 +16,6 @@
>  
>  obj-$(CONFIG_PCI)	+= toshiba_rbtx4927_pci_fixup.o 
>  obj-$(CONFIG_PCI)	+= toshiba_rbtx4927_pci_ops.o 
> +obj-$(CONFIG_NMI)	+= toshiba_rbtx4927_nmi.o
>  
>  include $(TOPDIR)/Rules.make
> diff -urN linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S linux-patched/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S
> --- linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S	Wed Dec 31 19:00:00 1969
> +++ linux-patched/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S	Wed Oct  8 14:03:29 2003
> @@ -0,0 +1,46 @@
> +/*
> + * linux/arch/mips/tx4927/toshiba_rbtx4927/tx4927_irq_handler.S
> + *
> + * NMI handler for Toshiba RBTX4927 board
> + *
> + * Copyright (C) 2003 TimeSys Corp.
> + *                    S. James Hill (James.Hill@timesys.com)
> + *                                  (sjhill@realitydiluted.com)
> + *
> + *  This program is free software; you can redistribute it and/or modify it
> + *  under the terms of the GNU General Public License as published by the
> + *  Free Software Foundation; either version 2 of the License, or (at your
> + *  option) any later version.
> + *
> + *  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> + *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> + *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> + *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
> + *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> + *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> + *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> + *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> + *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, write to the Free Software Foundation, Inc.,
> + *  675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +#include <asm/regdef.h>
> +#include <asm/stackframe.h>
> +
> +		.align	5
> +		.set noat
> +		NESTED(tx4927_nmi_handler, PT_SIZE, sp)
> +		SAVE_ALL
> +		CLI
> +		.set at
> +		mfc0	k0, CP0_STATUS
> +		lui	k1, 0x50		/* Clear BEV and NMI */
> +		nor	k1, zero, k1
> +		and	k0, k1
> +		mtc0	k0, CP0_STATUS
> +		move	a0, sp
> +		jal	toshiba_rbtx4927_nmi
> +		END(tx4927_nmi_handler)
> diff -urN linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c linux-patched/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
> --- linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	Thu Aug 28 10:04:47 2003
> +++ linux-patched/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	Wed Oct  8 14:08:29 2003
> @@ -907,6 +907,46 @@
>  	/* no return */
>  }
>  
> +#ifdef CONFIG_NMI
> +void toshiba_rbtx4927_nmi (struct pt_regs *regs)
> +{
> +	extern void show_code(unsigned int *pc);
> +	extern void show_runqueue(void);
> +	extern void show_stack(unsigned int *sp);
> +	extern void show_state_nolock(void);
> +	extern void show_trace(unsigned long *sp, unsigned int *ra,
> +			       unsigned int *pc);
> +
> +	bust_spinlocks(1);
> +	printk("\ncurrent = %d:%s\n",current->pid,current->comm);
> +	show_regs(regs);
> +	printk("Process %s (pid: %d, stackpage=%08lx)\n",
> +		current->comm, current->pid, (unsigned long) current);
> +	show_stack((unsigned int *)regs->regs[29]);
> +	show_trace((unsigned long *)regs->regs[29], 
> +	           (unsigned int *)regs->regs[31],
> +	           (unsigned int *)regs->cp0_epc);
> +	show_code((unsigned int *)regs->cp0_epc);
> +	bust_spinlocks(0);
> +}
> +
> +void nmi_handler_setup (void)
> +{
> +	extern void tx4927_nmi_handler (void);
> +	unsigned long vec[2];
> +
> +	vec[0] = 0x08000000 |
> +			(0x03ffffff & ((unsigned long)tx4927_nmi_handler >> 2));
> +	vec[1] = 0;
> +
> +	/*
> +	 * Our firmware (PMON in this case) has a NMI hook that
> +	 * jumps to 0x80000220. We locate our NMI handler there.
> +	 */
> +	memcpy((void *)(KSEG0 + 0x220), &vec, 0x8);
> +}
> +#endif
> +
>  void __init toshiba_rbtx4927_setup(void)
>  {
>  	vu32 cp0_config;


From exister99@velocitus.net Wed Oct  8 23:00:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Oct 2003 23:01:18 +0100 (BST)
Received: from mx20a.rmci.net ([IPv6:::ffff:205.162.184.37]:32690 "HELO
	mx20a.rmci.net") by linux-mips.org with SMTP id <S8225568AbTJHWAh>;
	Wed, 8 Oct 2003 23:00:37 +0100
Received: (qmail 11728 invoked from network); 8 Oct 2003 22:00:33 -0000
Received: from webmailb.rmci.net (HELO velocitus.net) (205.162.184.93)
  by mx20.rmci.net with SMTP; 8 Oct 2003 22:00:33 -0000
Received: from 156.153.254.2
        (SquirrelMail authenticated user exister99@velocitus.net)
        by webmail.rmci.net with HTTP;
        Wed, 8 Oct 2003 16:00:33 -0600 (MDT)
Message-ID: <5334.156.153.254.2.1065650433.squirrel@webmail.rmci.net>
Date: Wed, 8 Oct 2003 16:00:33 -0600 (MDT)
Subject: mips 32 bit HIGHMEM support
From: <exister99@velocitus.net>
To: <ralf@oss.sgi.com>
X-Priority: 3
Importance: Normal
X-MSMail-Priority: Normal
Cc: <linux-mips@linux-mips.org>
X-Mailer: SquirrelMail (version 1.2.7)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <exister99@velocitus.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: 3387
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: exister99@velocitus.net
Precedence: bulk
X-list: linux-mips
Content-Length: 2208
Lines: 56

Hello Ralf,

I work for HP in Boise, ID, USA.  For the last six months I have been
working with Linux in HP Laser jet Printers.  It is running in a formatter
board that features an ASIC with a MIPS 20Kc core.

The original Linux port was achieved by others working before me.  I began
working on applications for it when I started here (to make it print
actually).  As I have tried to milk more performance out of this board the
recurrent bottleneck has been the fact that the kernel only recognizes
512Mb of RAM.  So my current endeavor is fix the kernel so it sees the 1G
of RAM that is physically present in the system.

I reconfigured and rebuilt the kernel with HIGHMEM support.  HIGHMEM is
seen and booting up goes splendidly until init (pid 1) kicks off.  Early
on in the execution of init the system crashes.  Specifically it crashes
in do_page_fault().  A couple of strange things I have noticed:

1.  All memory pages are divied up between the DMA Zone and the HIGHMEM
Zone at bootup.  the NORMAL zone gets 0 pages.  Not sure if this is
normal.

2.  The virtual address that do_page_fault() chokes on is 0x00000000. 
This doesn't seem like a reasonable address for init to be accessing
especially considering its mem map only contains the chunks
0x10000000-0x10001000 and 0x400000-0x40b000 (I got these by traversing
init's mm->mm_rb tree).

I decided to contact you about this after digging up this old posting of
yours:

>Is anybody using 32-bit MIPS CPUs which have more than 512mb of memory or
>to be more exact have RAM that isn't accessible via the KSEG0 / KSEG1
>window?
>
>So far I haven't ever seen such a machine.  For 64-bit CPUs the right
>thing to do is easy - use a 64-bit kernel.  But for 32-bit CPUs the Intel
>highmem stuff in the memory managment now gives us a sane way to use
>the memory of such configuration with just a little bit of extra code.
>
>So if anybody wants support for such a configuration, please drop me a
>note.
>
>Thanks,
>
>  Ralf

I think this describes my machine.

If this is an issue who's solution is old news please point me to the
solution.  In any case any ideas or guidance regarding this crash would be
greatly appreciated.

Regards, Andrew Stone



From Steve.Finney@SpirentCom.COM Thu Oct  9 02:07:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 02:07:10 +0100 (BST)
Received: from Iris.Adtech-Inc.COM ([IPv6:::ffff:63.165.80.18]:30936 "EHLO
	iris.Adtech-Inc.COM") by linux-mips.org with ESMTP
	id <S8225580AbTJIBHI> convert rfc822-to-8bit; Thu, 9 Oct 2003 02:07:08 +0100
content-class: urn:content-classes:message
Subject: kmalloc question
Date: Wed, 8 Oct 2003 15:06:50 -1000
Message-ID: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB76D@iris.adtech-inc.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: kmalloc question
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcOOAaBsMOtG4wNEQ0WLKrZviKHYAg==
From: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
To: <linux-mips@linux-mips.org>
Return-Path: <Steve.Finney@SpirentCom.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3388
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Steve.Finney@SpirentCom.COM
Precedence: bulk
X-list: linux-mips
Content-Length: 390
Lines: 4

Is kmalloc (GFP_KERNEL) on a 32 bit HIGHMEM enabled MIPS kernel (BCM/Sibyte processor) guaranteed to allocate memory from the low, KSEG0/1 addressible region? I'm having trouble sorting through the slab.c code. On this processor, only 256 MB of DRAM is directly addressible; with more than 256 MB of RAM, there is 256 MB in zone 0, and the remainder in zone 2. Zone 1 is empty.

Thanks,
sf

From yuri@simpledevices.com Thu Oct  9 02:51:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 02:51:55 +0100 (BST)
Received: from simp98.iserver.net ([IPv6:::ffff:128.121.222.84]:10724 "EHLO
	simp98.iserver.net") by linux-mips.org with ESMTP
	id <S8225583AbTJIBvX>; Thu, 9 Oct 2003 02:51:23 +0100
Received: from simpledemkyosn (dsl092-191-011.sfo1.dsl.speakeasy.net [66.92.191.11])
	by simp98.iserver.net (8.12.9p1/8.11.2) with SMTP id h991pJ2Q024739
	for <linux-mips@linux-mips.org>; Thu, 9 Oct 2003 01:51:21 GMT
Message-ID: <00b001c38e03$bbc23960$e201a8c0@simpledemkyosn>
From: "Yuri" <yuri@simpledevices.com>
To: <linux-mips@linux-mips.org>
Subject: tx4927 support (newbie question)
Date: Wed, 8 Oct 2003 18:21:57 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00AD_01C38DC9.0EA8EB00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4927.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Return-Path: <yuri@simpledevices.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3389
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuri@simpledevices.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2447
Lines: 64

This is a multi-part message in MIME format.

------=_NextPart_000_00AD_01C38DC9.0EA8EB00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
I'm trying to get the 2.4 kernel running on rbtx4927 toshiba eval board.
There are config options to enable the board support in the kernel tree =
and also some relatively recent patches
specific to the board.  However the furthest I could get in the boot =
process is to the calibration of the delay loop.
I'm not sure whether all of the interrupts are disabled or just the =
timer, but jiffies are not getting incremented.  As far as I could trace =
it so far, the right irq setup routines are called in the init, but to =
no avail.  I'm using mipsel-linux-gcc version 2.95.4. version 2.95.3 had =
the same results.  I have tried linux_2_4 and linux_2_4_22_rc3 tags of =
the cvs
Thanks
Yuri


------=_NextPart_000_00AD_01C38DC9.0EA8EB00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3700.6699" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I'm trying to get the 2.4 kernel =
running on=20
rbtx4927 toshiba eval board.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>There are config options to enable the =
board=20
support in the kernel tree and also some relatively recent =
patches</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>specific to the board.&nbsp; However =
the furthest I=20
could get in the boot process is to the calibration of the delay=20
loop.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure whether&nbsp;all of the =
interrupts=20
are&nbsp;disabled or just the timer, but jiffies are not&nbsp;getting=20
incremented.&nbsp; As far as I could trace it so far, the right irq =
setup=20
routines are called in the init, but to no avail.&nbsp; I'm using=20
mipsel-linux-gcc version 2.95.4.&nbsp;version 2.95.3 had the same =
results.&nbsp;=20
I have tried linux_2_4 and linux_2_4_22_rc3 tags of the cvs</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Yuri</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00AD_01C38DC9.0EA8EB00--



From durai@isofttech.com Thu Oct  9 06:39:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 06:39:23 +0100 (BST)
Received: from [IPv6:::ffff:203.199.202.17] ([IPv6:::ffff:203.199.202.17]:776
	"EHLO pub.isofttechindia.com") by linux-mips.org with ESMTP
	id <S8225299AbTJIFjU>; Thu, 9 Oct 2003 06:39:20 +0100
Received: from DURAI ([192.168.0.107])
	by pub.isofttechindia.com (8.11.0/8.11.0) with SMTP id h995YGY03928
	for <linux-mips@linux-mips.org>; Thu, 9 Oct 2003 11:04:16 +0530
Message-ID: <007801c38e27$a1c81920$6b00a8c0@DURAI>
From: "durai" <durai@isofttech.com>
To: "mips" <linux-mips@linux-mips.org>
Subject: how to include mips assembly in c code?
Date: Thu, 9 Oct 2003 11:08:56 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0075_01C38E55.BB76DF40"
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
X-MailScanner: Found to be clean
Return-Path: <durai@isofttech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3390
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: durai@isofttech.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3684
Lines: 103

This is a multi-part message in MIME format.

------=_NextPart_000_0075_01C38E55.BB76DF40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hello,
I am having the following assembly code and i wanted to call this =
function from a c code.
can anybody tell me how to include this code in a c program?

/************************************************************************=
******
*
* sysWbFlush - flush the write buffer
*
* This routine flushes the write buffers, making certain all
* subsequent memory writes have occurred.  It is used during critical =
periods
* only, e.g., after memory-mapped I/O register access.
*
* RETURNS: N/A

* sysWbFlush (void)

*/
        .ent    sysWbFlush
sysWbFlush:
        li      t0, K1BASE              /* load uncached address        =
*/
        lw      t0, 0(t0)               /* read in order to flush       =
*/
        j       ra                      /* return to caller             =
*/
        .end    sysWbFlush


regards
durai
------=_NextPart_000_0075_01C38E55.BB76DF40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I am having the following assembly code =
and i=20
wanted to call this function from a c code.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>can anybody tell me how to include this =
code in a c=20
program?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>/***************************************************************=
***************<BR>*<BR>*=20
sysWbFlush - flush the write buffer<BR>*<BR>* This routine flushes the =
write=20
buffers, making certain all<BR>* subsequent memory writes have =
occurred.&nbsp;=20
It is used during critical periods<BR>* only, e.g., after memory-mapped =
I/O=20
register access.<BR>*<BR>* RETURNS: N/A</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>* sysWbFlush (void)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>*/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
.ent&nbsp;&nbsp;&nbsp;=20
sysWbFlush<BR>sysWbFlush:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
li&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t0,=20
K1BASE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
/* load uncached address&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
*/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lw&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t0,=20
0(t0)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
/* read in order to flush&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
*/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
j&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ra&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
/* return to=20
caller&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
*/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .end&nbsp;&nbsp;&nbsp;=20
sysWbFlush</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>durai</FONT></DIV></BODY></HTML>

------=_NextPart_000_0075_01C38E55.BB76DF40--


From ralf@linux-mips.org Thu Oct  9 08:54:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 08:54:53 +0100 (BST)
Received: from p508B7CAD.dip.t-dialin.net ([IPv6:::ffff:80.139.124.173]:63456
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225464AbTJIHyq>; Thu, 9 Oct 2003 08:54:46 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h997sJNK006941;
	Thu, 9 Oct 2003 09:54:20 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h997sFXg006940;
	Thu, 9 Oct 2003 09:54:15 +0200
Date: Thu, 9 Oct 2003 09:54:15 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: durai <durai@isofttech.com>
Cc: mips <linux-mips@linux-mips.org>
Subject: Re: how to include mips assembly in c code?
Message-ID: <20031009075415.GB19372@linux-mips.org>
References: <007801c38e27$a1c81920$6b00a8c0@DURAI>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <007801c38e27$a1c81920$6b00a8c0@DURAI>
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: 3391
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 542
Lines: 23

On Thu, Oct 09, 2003 at 11:08:56AM +0530, durai wrote:

> I am having the following assembly code and i wanted to call this function
> from a c code.
> can anybody tell me how to include this code in a c program?

Several solutions:

  #define sysWbFlush()	 do { (*(volatile unsigned int *)K1BASE) } while (0)

Or using your existing code:

  extern void sysWbFlush(void);

the call as

  sysWbFlush();

No point in using inline assembler for such a small fragment.

Anyway - I suggest you dump this code and look at <asm/wbflush.h>.

  Ralf

From mdharm@host099.momenco.com Thu Oct  9 09:05:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 09:05:53 +0100 (BST)
Received: from jeeves.momenco.com ([IPv6:::ffff:64.169.228.99]:7945 "EHLO 
	host099.momenco.com") by linux-mips.org with ESMTP
	id <S8225464AbTJIIFt>; Thu, 9 Oct 2003 09:05:49 +0100
Received: (from mdharm@localhost)
	by  host099.momenco.com (8.11.6/8.11.6) id h9985d203524;
	Thu, 9 Oct 2003 01:05:39 -0700
Date: Thu, 9 Oct 2003 01:05:39 -0700
From: Matthew Dharm <mdharm@momenco.com>
To: durai <durai@isofttech.com>
Cc: mips <linux-mips@linux-mips.org>
Subject: Re: how to include mips assembly in c code?
Message-ID: <20031009010539.B3375@momenco.com>
References: <007801c38e27$a1c81920$6b00a8c0@DURAI>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <007801c38e27$a1c81920$6b00a8c0@DURAI>; from durai@isofttech.com on Thu, Oct 09, 2003 at 11:08:56AM +0530
Organization: Momentum Computer, Inc.
X-Copyright: (C) 2003 Matthew Dharm, all rights reserved.
Return-Path: <mdharm@host099.momenco.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3392
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mdharm@momenco.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1280
Lines: 38

I feel compelled to point out that the source file you are quoting looks
suspiciously like it came from VxWorks, which means it is likely copyright
Wind River Systems.  Using their code without permission would be illegal.

Matt

On Thu, Oct 09, 2003 at 11:08:56AM +0530, durai wrote:
> hello,
> I am having the following assembly code and i wanted to call this function from a c code.
> can anybody tell me how to include this code in a c program?
> 
> /******************************************************************************
> *
> * sysWbFlush - flush the write buffer
> *
> * This routine flushes the write buffers, making certain all
> * subsequent memory writes have occurred.  It is used during critical periods
> * only, e.g., after memory-mapped I/O register access.
> *
> * RETURNS: N/A
> 
> * sysWbFlush (void)
> 
> */
>         .ent    sysWbFlush
> sysWbFlush:
>         li      t0, K1BASE              /* load uncached address        */
>         lw      t0, 0(t0)               /* read in order to flush       */
>         j       ra                      /* return to caller             */
>         .end    sysWbFlush
> 
> 
> regards
> durai
-- 
Matthew Dharm                              Work: mdharm@momenco.com
Senior Software Designer, Momentum Computer


From ralf@linux-mips.org Thu Oct  9 09:09:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 09:09:49 +0100 (BST)
Received: from p508B7CAD.dip.t-dialin.net ([IPv6:::ffff:80.139.124.173]:56801
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225392AbTJIIJm>; Thu, 9 Oct 2003 09:09:42 +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 h9989fNK007257;
	Thu, 9 Oct 2003 10:09:41 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9989evi007256;
	Thu, 9 Oct 2003 10:09:40 +0200
Date: Thu, 9 Oct 2003 10:09:40 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
Cc: linux-mips@linux-mips.org
Subject: Re: kmalloc question
Message-ID: <20031009080940.GC19372@linux-mips.org>
References: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB76D@iris.adtech-inc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB76D@iris.adtech-inc.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: 3393
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 458
Lines: 7

On Wed, Oct 08, 2003 at 03:06:50PM -1000, Finney, Steve wrote:

> Is kmalloc (GFP_KERNEL) on a 32 bit HIGHMEM enabled MIPS kernel (BCM/Sibyte processor) guaranteed to allocate memory from the low, KSEG0/1 addressible region? I'm having trouble sorting through the slab.c code. On this processor, only 256 MB of DRAM is directly addressible; with more than 256 MB of RAM, there is 256 MB in zone 0, and the remainder in zone 2. Zone 1 is empty.

Yes.

  Ralf

From Geert.Uytterhoeven@sonycom.com Thu Oct  9 09:31:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 09:31:07 +0100 (BST)
Received: from [IPv6:::ffff:80.88.36.193] ([IPv6:::ffff:80.88.36.193]:54673
	"EHLO witte.sonytel.be") by linux-mips.org with ESMTP
	id <S8225469AbTJIIbB>; Thu, 9 Oct 2003 09:31:01 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id h998UvQG022398;
	Thu, 9 Oct 2003 10:30:57 +0200 (MEST)
Date: Thu, 9 Oct 2003 10:30:57 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: =?iso-8859-1?Q?J=F8rg_Ulrich_Hansen?= <jh@hansen-telecom.dk>
cc: Linux-Mips <linux-mips@linux-mips.org>
Subject: Re: What toolchain for vr4181
In-Reply-To: <EIEHIDHKGJLNEPLOGOPOAEIGCFAA.jh@hansen-telecom.dk>
Message-ID: <Pine.GSO.4.21.0310091030110.7086-100000@waterleaf.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
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: 3394
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1109
Lines: 34

On Wed, 8 Oct 2003, [iso-8859-1] Jørg Ulrich Hansen wrote:
> I am about to start porting Linux to my hardware with an vr4181 processor.
> The hardware is very close to the osprey architecture. Now my problem is
> what toolchain to use.
> I could do with an up to date opinion.
> 
> ? gcc-2.95.3
> ? gcc-2.95.4
> ? egcs-1.1.2
> ? gcc-3.2
> ? binutils 2.13
> ? glibc 2.2.5
> ? Any patches
> ? http://www.ltc.com/~brad/mips/mips-cross-toolchain/index.html
> ? http://kegel.com/crosstool/
> 
> Where is a good starting point for a toolchain that will build and work?
> I would prefere to build it my self because at a later state I might build
> it under cygwin. But a prebuild does also have interest.

At work we use plain binutils 2.13.2.1 and gcc 3.2.2, which we build ourselves
(host is Solaris/SPARC).

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 AdeelM@avaznet.com Thu Oct  9 11:54:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 11:54:27 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:50930
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225462AbTJIKyV>; Thu, 9 Oct 2003 11:54:21 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <4RT7BKQB>; Thu, 9 Oct 2003 15:46:20 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264F05F@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Subject: YAMON Source code modification 
Date: Thu, 9 Oct 2003 15:46:19 +0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38E52.92A44720"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3395
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1311
Lines: 36

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

------_=_NextPart_001_01C38E52.92A44720
Content-Type: text/plain;
	charset="iso-8859-1"

We want to port and 'run' YAMON to our own MIPS-based Development Board. Can
someone tell me what changes are necessary in the YAMON source code so that
it works on our board ?.
Regards,
ADEEL MALIK,
 


------_=_NextPart_001_01C38E52.92A44720
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial" hb_focus_attach="true">
<DIV><SPAN class=902304110-09102003><FONT size=2>We want to port and 'run' YAMON 
to our own MIPS-based Development Board. Can someone tell me what changes are 
necessary in the YAMON source code so that it works on our board 
?.</FONT></SPAN></DIV>
<DIV><SPAN class=902304110-09102003><FONT size=2>Regards,</FONT></SPAN></DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM>ADEEL MALIK,</EM></FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<P></P></BODY></HTML>

------_=_NextPart_001_01C38E52.92A44720--

From jbglaw@dvmwest.gt.owl.de Thu Oct  9 12:04:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 12:04:27 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:17365 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225466AbTJILEU>; Thu, 9 Oct 2003 12:04:20 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id BAB744B3E4; Thu,  9 Oct 2003 13:04:18 +0200 (CEST)
Date: Thu, 9 Oct 2003 13:04:18 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Linux-Mips <linux-mips@linux-mips.org>
Subject: Re: What toolchain for vr4181
Message-ID: <20031009110418.GO20846@lug-owl.de>
Mail-Followup-To: Linux-Mips <linux-mips@linux-mips.org>
References: <EIEHIDHKGJLNEPLOGOPOAEIGCFAA.jh@hansen-telecom.dk> <Pine.GSO.4.21.0310091030110.7086-100000@waterleaf.sonytel.be>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gWPeGsYce+mZStT1"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0310091030110.7086-100000@waterleaf.sonytel.be>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
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: 3396
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1717
Lines: 52


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

On Thu, 2003-10-09 10:30:57 +0200, Geert Uytterhoeven <geert@linux-m68k.org>
wrote in message <Pine.GSO.4.21.0310091030110.7086-100000@waterleaf.sonytel=
=2Ebe>:
> On Wed, 8 Oct 2003, [iso-8859-1] J=F8rg Ulrich Hansen wrote:
> >=20
> > Where is a good starting point for a toolchain that will build and work?
> > I would prefere to build it my self because at a later state I might bu=
ild
> > it under cygwin. But a prebuild does also have interest.
>=20
> At work we use plain binutils 2.13.2.1 and gcc 3.2.2, which we build ours=
elves
> (host is Solaris/SPARC).

Joined trees? Which configury? Unfortunately, toolchain questions are
quite FAQs, but there doesn't really exist _that_ good HOWTOs which
actually contain exactly helpful hints (eg. which versions and/or which
additional patches are needed).

If companies have some kind of scripts or the like they use, I'd really
love to see them published. That'd really help all those guys out
there:)

MfG, JBG

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

--gWPeGsYce+mZStT1
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/hUCyHb1edYOZ4bsRAoncAJ4hByM37k+Lo+cGoD99tsihz/KiVACfUFKu
6xOvkEANhndGcIastzmt4jE=
=utia
-----END PGP SIGNATURE-----

--gWPeGsYce+mZStT1--

From Geert.Uytterhoeven@sonycom.com Thu Oct  9 12:25:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 12:25:35 +0100 (BST)
Received: from [IPv6:::ffff:80.88.36.193] ([IPv6:::ffff:80.88.36.193]:46753
	"EHLO witte.sonytel.be") by linux-mips.org with ESMTP
	id <S8225549AbTJILZc>; Thu, 9 Oct 2003 12:25:32 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id h99BPUQG009265;
	Thu, 9 Oct 2003 13:25:30 +0200 (MEST)
Date: Thu, 9 Oct 2003 13:25:30 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
cc: Linux-Mips <linux-mips@linux-mips.org>
Subject: Re: What toolchain for vr4181
In-Reply-To: <20031009110418.GO20846@lug-owl.de>
Message-ID: <Pine.GSO.4.21.0310091320000.7430-100000@waterleaf.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
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: 3397
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2034
Lines: 48

On Thu, 9 Oct 2003, Jan-Benedict Glaw wrote:
> On Thu, 2003-10-09 10:30:57 +0200, Geert Uytterhoeven <geert@linux-m68k.org>
> wrote in message <Pine.GSO.4.21.0310091030110.7086-100000@waterleaf.sonytel.be>:
> > On Wed, 8 Oct 2003, [iso-8859-1] Jørg Ulrich Hansen wrote:
> > > 
> > > Where is a good starting point for a toolchain that will build and work?
> > > I would prefere to build it my self because at a later state I might build
> > > it under cygwin. But a prebuild does also have interest.
> > 
> > At work we use plain binutils 2.13.2.1 and gcc 3.2.2, which we build ourselves
> > (host is Solaris/SPARC).
> 
> Joined trees? Which configury? Unfortunately, toolchain questions are
> quite FAQs, but there doesn't really exist _that_ good HOWTOs which
> actually contain exactly helpful hints (eg. which versions and/or which
> additional patches are needed).
> 
> If companies have some kind of scripts or the like they use, I'd really
> love to see them published. That'd really help all those guys out
> there:)

Binutils (binutils-2.13.2.1.tar.bz2):
    configure --target=mips-linux --prefix=/wherever/you/want

Gcc (gcc-core-3.2.2.tar.bz2):
    configure --target=mips-linux --prefix=/wherever/you/want --enable-languages=c --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext

I took the development libraries and includes from Debian:
    libc6-dev_2.2.5-11.2_mips.deb
    libc6_2.2.5-11.2_mips.deb
    zlib1g-dev_1%3a1.1.4-1_mips.deb
    zlib1g_1%3a1.1.4-1_mips.deb

I wrote very simple Perl clones of dpkg and dpkg-deb with just enough
functionality to get `dpkg-cross -i' working on Solaris. I don't know whether I
can share them, though.

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 th@jehova.dsm.dk Thu Oct  9 13:55:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 13:55:21 +0100 (BST)
Received: from [IPv6:::ffff:217.157.19.70] ([IPv6:::ffff:217.157.19.70]:51210
	"EHLO jehova.dsm.dk") by linux-mips.org with ESMTP
	id <S8225497AbTJIMzR>; Thu, 9 Oct 2003 13:55:17 +0100
Received: (qmail 16562 invoked by uid 1000); 9 Oct 2003 12:55:12 -0000
Date: Thu, 9 Oct 2003 13:55:12 +0100 (BST)
From: Thomas Horsten <thomas@horsten.com>
X-X-Sender: thomas@jehova.dsm.dk
To: Ralf Baechle <ralf@linux-mips.org>
cc: "Steven J. Hill" <sjhill@realitydiluted.com>,
	<linux-mips@linux-mips.org>
Subject: Re: [PATCH] Proposed NMI handling interface...
In-Reply-To: <20031008160600.GA19102@linux-mips.org>
Message-ID: <Pine.LNX.4.40.0310091354230.16550-100000@jehova.dsm.dk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <th@jehova.dsm.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3398
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thomas@horsten.com
Precedence: bulk
X-list: linux-mips
Content-Length: 744
Lines: 16

On Wed, 8 Oct 2003, Ralf Baechle wrote:

> That hook you're proposing isn't even necessary in generic code.  NMI
> on MIPS hardware is a fairly odd type of exception - it goes straight to
> 0xbfc00000 which usually is a a firmware address - and lots of firmware
> doesn't even offer an NMI hook.  So for those cases where it's possible,
> you need to do something firmware anyway before jumping to Linux's NMI
> handler.  An additional problem with the NMI design of MIPS is it's using
> ErrorEPC, just like cache errors so you better pray - or simply design
> systems only to rely on NMI for debugging and catastrophic failures.

On Lasat boards NMI is used to reboot into Service Mode. There's no hook
to override this behaviour.

// Thomas


From ralf@linux-mips.org Thu Oct  9 15:03:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 15:03:30 +0100 (BST)
Received: from p508B6267.dip.t-dialin.net ([IPv6:::ffff:80.139.98.103]:58759
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225418AbTJIODX>; Thu, 9 Oct 2003 15:03:23 +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 h99E3LNK029511;
	Thu, 9 Oct 2003 16:03:21 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h99E3Kma029510;
	Thu, 9 Oct 2003 16:03:20 +0200
Date: Thu, 9 Oct 2003 16:03:20 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: exister99@velocitus.net
Cc: linux-mips@linux-mips.org
Subject: Re: mips 32 bit HIGHMEM support
Message-ID: <20031009140319.GA17647@linux-mips.org>
References: <5334.156.153.254.2.1065650433.squirrel@webmail.rmci.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5334.156.153.254.2.1065650433.squirrel@webmail.rmci.net>
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: 3399
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2348
Lines: 52

On Wed, Oct 08, 2003 at 04:00:33PM -0600, exister99@velocitus.net wrote:

> I work for HP in Boise, ID, USA.  For the last six months I have been
> working with Linux in HP Laser jet Printers.  It is running in a formatter
> board that features an ASIC with a MIPS 20Kc core.

Reminds me of the HP Laserjet code in the kernel.  Anybody still using
or testing that?

> The original Linux port was achieved by others working before me.  I began
> working on applications for it when I started here (to make it print
> actually).  As I have tried to milk more performance out of this board the
> recurrent bottleneck has been the fact that the kernel only recognizes
> 512Mb of RAM.  So my current endeavor is fix the kernel so it sees the 1G
> of RAM that is physically present in the system.
> 
> I reconfigured and rebuilt the kernel with HIGHMEM support.  HIGHMEM is
> seen and booting up goes splendidly until init (pid 1) kicks off.  Early
> on in the execution of init the system crashes.  Specifically it crashes
> in do_page_fault().  A couple of strange things I have noticed:
> 
> 1.  All memory pages are divied up between the DMA Zone and the HIGHMEM
> Zone at bootup.  the NORMAL zone gets 0 pages.  Not sure if this is
> normal.
> 
> 2.  The virtual address that do_page_fault() chokes on is 0x00000000. 
> This doesn't seem like a reasonable address for init to be accessing
> especially considering its mem map only contains the chunks
> 0x10000000-0x10001000 and 0x400000-0x40b000 (I got these by traversing
> init's mm->mm_rb tree).
> 
> I decided to contact you about this after digging up this old posting of
> yours:

[... ancient posting deleted ...]

> I think this describes my machine.
> 
> If this is an issue who's solution is old news please point me to the
> solution.  In any case any ideas or guidance regarding this crash would be
> greatly appreciated.

In the meantime there is a highmem implementation for the MIPS kernel.
It's got a limitation - it only works on physically indexed D-caches or
more exactly processors that don't suffer from cache aliases.  On
processors that have such aliases the necessary flushes are rather bad
for performance so this currently simply isn't suported.

Anyway, for a 64-bit processor such as the 20Kc I suggest a 64-bit kernel.
Highmem is a pain and 64-bit is the cure.

  Ralf

From sjhill@realitydiluted.com Thu Oct  9 15:18:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 15:19:00 +0100 (BST)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:15781
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225552AbTJIOS4>; Thu, 9 Oct 2003 15:18:56 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1A7bcT-0004b1-00; Thu, 09 Oct 2003 09:18:21 -0500
Message-ID: <3F856E29.9040007@realitydiluted.com>
Date: Thu, 09 Oct 2003 10:18:17 -0400
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030930 Debian/1.4-5
X-Accept-Language: en
MIME-Version: 1.0
To: Jun Sun <jsun@mvista.com>
CC: linux-mips@linux-mips.org
Subject: Re: [PATCH] Toshiba RBTX4927 NMI handling code....
References: <3F846FA3.6090208@realitydiluted.com> <20031008141808.H3887@mvista.com>
In-Reply-To: <20031008141808.H3887@mvista.com>
Content-Type: multipart/mixed;
 boundary="------------090202090506040008030206"
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3400
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 6380
Lines: 182

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

Hey Jun.

Thanks for your input on this. Updated code has been applied
to CVS. The new patch is also attached just for record.

-Steve

--------------090202090506040008030206
Content-Type: text/plain;
 name="rbtx4927-nmi.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="rbtx4927-nmi.patch"

? big.diff
? rbtx4927-nmi.patch
Index: arch/mips/kernel/traps.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/traps.c,v
retrieving revision 1.99.2.57
diff -u -r1.99.2.57 traps.c
--- arch/mips/kernel/traps.c	10 Sep 2003 10:09:47 -0000	1.99.2.57
+++ arch/mips/kernel/traps.c	9 Oct 2003 14:12:23 -0000
@@ -63,6 +63,7 @@
 
 void (*board_be_init)(void);
 int (*board_be_handler)(struct pt_regs *regs, int is_fixup);
+void (*board_nmi_handler_setup)(void) = NULL;
 
 int kstack_depth_to_print = 24;
 
@@ -1008,6 +1009,9 @@
 		save_fp_context = fpu_emulator_save_context;
 		restore_fp_context = fpu_emulator_restore_context;
 	}
+
+	if (board_nmi_handler_setup)
+		board_nmi_handler_setup();
 
 	flush_icache_range(KSEG0, KSEG0 + 0x400);
 
Index: arch/mips/tx4927/toshiba_rbtx4927/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/tx4927/toshiba_rbtx4927/Makefile,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 Makefile
--- arch/mips/tx4927/toshiba_rbtx4927/Makefile	11 Apr 2003 17:26:20 -0000	1.1.2.1
+++ arch/mips/tx4927/toshiba_rbtx4927/Makefile	9 Oct 2003 14:12:23 -0000
@@ -13,6 +13,7 @@
 obj-y	+= toshiba_rbtx4927_prom.o 
 obj-y	+= toshiba_rbtx4927_setup.o 
 obj-y	+= toshiba_rbtx4927_irq.o 
+obj-y	+= toshiba_rbtx4927_nmi.o 
 
 obj-$(CONFIG_PCI)	+= toshiba_rbtx4927_pci_fixup.o 
 obj-$(CONFIG_PCI)	+= toshiba_rbtx4927_pci_ops.o 
Index: arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S
===================================================================
RCS file: arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S
diff -N arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_nmi.S	9 Oct 2003 14:12:23 -0000
@@ -0,0 +1,46 @@
+/*
+ * linux/arch/mips/tx4927/toshiba_rbtx4927/tx4927_irq_handler.S
+ *
+ * NMI handler for Toshiba RBTX4927 board
+ *
+ * Copyright (C) 2003 TimeSys Corp.
+ *                    S. James Hill (James.Hill@timesys.com)
+ *                                  (sjhill@realitydiluted.com)
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ *
+ *  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
+ *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include <asm/regdef.h>
+#include <asm/stackframe.h>
+
+		.align	5
+		.set noat
+		NESTED(tx4927_nmi_handler, PT_SIZE, sp)
+		SAVE_ALL
+		CLI
+		.set at
+		mfc0	k0, CP0_STATUS
+		lui	k1, 0x50		/* Clear BEV and NMI */
+		nor	k1, zero, k1
+		and	k0, k1
+		mtc0	k0, CP0_STATUS
+		move	a0, sp
+		jal	toshiba_rbtx4927_nmi
+		END(tx4927_nmi_handler)
Index: arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c,v
retrieving revision 1.1.2.5
diff -u -r1.1.2.5 toshiba_rbtx4927_setup.c
--- arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	25 Aug 2003 16:14:53 -0000	1.1.2.5
+++ arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	9 Oct 2003 14:12:23 -0000
@@ -907,8 +907,47 @@
 	/* no return */
 }
 
+void toshiba_rbtx4927_nmi (struct pt_regs *regs)
+{
+	extern void show_code(unsigned int *pc);
+	extern void show_runqueue(void);
+	extern void show_stack(unsigned int *sp);
+	extern void show_state_nolock(void);
+	extern void show_trace(unsigned long *sp, unsigned int *ra,
+			       unsigned int *pc);
+
+	bust_spinlocks(1);
+	printk("\ncurrent = %d:%s\n",current->pid,current->comm);
+	show_regs(regs);
+	printk("Process %s (pid: %d, stackpage=%08lx)\n",
+		current->comm, current->pid, (unsigned long) current);
+	show_stack((unsigned int *)regs->regs[29]);
+	show_trace((unsigned long *)regs->regs[29], 
+	           (unsigned int *)regs->regs[31],
+	           (unsigned int *)regs->cp0_epc);
+	show_code((unsigned int *)regs->cp0_epc);
+	bust_spinlocks(0);
+}
+
+void toshiba_rbtx4927_nmi_handler_setup (void)
+{
+	extern void tx4927_nmi_handler (void);
+	unsigned long vec[2];
+
+	vec[0] = 0x08000000 |
+			(0x03ffffff & ((unsigned long)tx4927_nmi_handler >> 2));
+	vec[1] = 0;
+
+	/*
+	 * Our firmware (PMON in this case) has a NMI hook that
+	 * jumps to 0x80000220. We locate our NMI handler there.
+	 */
+	memcpy((void *)(KSEG0 + 0x220), &vec, 0x8);
+}
+
 void __init toshiba_rbtx4927_setup(void)
 {
+	extern void (*board_nmi_handler_setup)(void);
 	vu32 cp0_config;
 
 	printk("CPU is %s\n", toshiba_name);
@@ -927,6 +966,9 @@
 	cp0_config = read_c0_config();
 	cp0_config = cp0_config & ~(TX49_CONF_IC | TX49_CONF_DC);
 	write_c0_config(cp0_config);
+
+	/* set up the NMI handler */
+	board_nmi_handler_setup = toshiba_rbtx4927_nmi_handler_setup;
 
 #ifdef TOSHIBA_RBTX4927_SETUP_DEBUG
 	{

--------------090202090506040008030206--


From brian@murphy.dk Thu Oct  9 17:04:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 17:04:39 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:19752
	"EHLO valis.localnet") by linux-mips.org with ESMTP
	id <S8225587AbTJIQEd>; Thu, 9 Oct 2003 17:04:33 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id h99G3wst023003;
	Thu, 9 Oct 2003 18:03:58 +0200
Message-ID: <3F8586ED.3060309@murphy.dk>
Date: Thu, 09 Oct 2003 18:03:57 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
CC: Thomas Horsten <thomas@horsten.com>
Subject: Re: [PATCH] Proposed NMI handling interface...
References: <Pine.LNX.4.40.0310091354230.16550-100000@jehova.dsm.dk>
In-Reply-To: <Pine.LNX.4.40.0310091354230.16550-100000@jehova.dsm.dk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3401
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 227
Lines: 19

Thomas Horsten wrote:

>On Wed, 8 Oct 2003, Ralf Baechle wrote:
>
>  
>
>On Lasat boards NMI is used to reboot into Service Mode. There's no hook
>to override this behaviour.
>
>// Thomas
>
>
>
>  
>
There could be...

/Brian


From jsun@mvista.com Thu Oct  9 19:02:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 19:02:06 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:38126 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225616AbTJISCE>;
	Thu, 9 Oct 2003 19:02:04 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h99I1s319204;
	Thu, 9 Oct 2003 11:01:54 -0700
Date: Thu, 9 Oct 2003 11:01:54 -0700
From: Jun Sun <jsun@mvista.com>
To: Adeel Malik <AdeelM@avaznet.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: YAMON Source code modification
Message-ID: <20031009110154.B17781@mvista.com>
References: <10C6C1971DA00C4BB87AC0206E3CA38264F05F@1aurora.enabtech>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <10C6C1971DA00C4BB87AC0206E3CA38264F05F@1aurora.enabtech>; from AdeelM@avaznet.com on Thu, Oct 09, 2003 at 03:46:19PM +0500
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3402
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 458
Lines: 14

On Thu, Oct 09, 2003 at 03:46:19PM +0500, Adeel Malik wrote:
> We want to port and 'run' YAMON to our own MIPS-based Development Board. Can
> someone tell me what changes are necessary in the YAMON source code so that
> it works on our board ?.
> Regards,
> ADEEL MALIK,
>  

Actually is YAMON code freely available?  Can someone from MIPS confirm
that and perhaps point to the downloading place?  

Many people have asked me about this in the past ...

Jun

From earlm@mips.com Thu Oct  9 19:41:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 19:42:29 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:38297 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225618AbTJISl5>;
	Thu, 9 Oct 2003 19:41: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 h99IcndA014839;
	Thu, 9 Oct 2003 11:38:53 -0700 (PDT)
Received: from xchange.mips.com (xchange [192.168.20.31])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA09463;
	Thu, 9 Oct 2003 11:42:56 -0700 (PDT)
Received: by xchange.mips.com with Internet Mail Service (5.5.2653.19)
	id <43ZYK49B>; Thu, 9 Oct 2003 11:38:39 -0700
Message-ID: <0C5F4C7A1E3ED51194E200508B2CE32A02264E57@xchange.mips.com>
From: "Mitchell, Earl" <earlm@mips.com>
To: "'Jun Sun'" <jsun@mvista.com>, Adeel Malik <AdeelM@avaznet.com>
Cc: linux-mips@linux-mips.org
Subject: RE: YAMON Source code modification
Date: Thu, 9 Oct 2003 11:38:34 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Return-Path: <earlm@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3403
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlm@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2542
Lines: 70


The YAMON license agreement is here which
essentially says its GPL but read this anyway ... 

http://www.mips.com/LicenseMapper/Yamon_license

The YAMON source code is here ... 

http://www.mips.com/content/Products/SoftwareTools/yamon

Last time I read it the YAMON porting guide doc included
with this distribution was kinda weak. That is, it does
not explicitly tell you which files to change and so on
compared to something like Wind River's porting guide
for vxworks which is very explicit and detailed. But
hey vxworks is a commercial product and this is free code. ;-) 

If you've ported a boot loader before you know the
usual things you have to change (e.g. exception
handlers, memory map specific stuff, device drivers,
memory initialization, etc). The porting guide is not 
very explicit about which files each
of these items is located in. So last time I ported
YAMON I simply walked thru the code starting from
./yamon/arch/reset/bootvector/reset.S and modified 
what I needed to as I hit code that needed to change.
You'd end up doing this anyway for bringup debugging.
In most cases a LOT of code will be reusable because
YAMON detects what core you have etc. So the amount of 
code you need to add/change is dependent on how close your
target hardware is to what's already supported. 

There are other boot loaders available you can use
like U-boot, Redboot, PMON, etc. The knock on YAMON
is that its much bigger than these other loaders. That's because
guys who originally wrote it chose not to use 'ifdefs' 
and conditional compiles for all the variants. So you get 
code linked in for all the variations (even though that
code is not used) and it jumps to correct routines
depending on your architecture. Makes the maintenance
easier I guess. Not really meant to be used as a production
bootrom in products but is used for eval boards. 

-earlm


-----Original Message-----
From: Jun Sun [mailto:jsun@mvista.com]
Sent: Thursday, October 09, 2003 11:02 AM
To: Adeel Malik
Cc: linux-mips@linux-mips.org; jsun@mvista.com
Subject: Re: YAMON Source code modification


On Thu, Oct 09, 2003 at 03:46:19PM +0500, Adeel Malik wrote:
> We want to port and 'run' YAMON to our own MIPS-based Development Board.
Can
> someone tell me what changes are necessary in the YAMON source code so
that
> it works on our board ?.
> Regards,
> ADEEL MALIK,
>  

Actually is YAMON code freely available?  Can someone from MIPS confirm
that and perhaps point to the downloading place?  

Many people have asked me about this in the past ...

Jun

From wd@denx.de Thu Oct  9 21:15:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 21:16:20 +0100 (BST)
Received: from mailout03.sul.t-online.com ([IPv6:::ffff:194.25.134.81]:52663
	"EHLO mailout03.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225624AbTJIUPs>; Thu, 9 Oct 2003 21:15:48 +0100
Received: from fwd09.aul.t-online.de 
	by mailout03.sul.t-online.com with smtp 
	id 1A7fsd-0003LD-07; Thu, 09 Oct 2003 20:51:19 +0200
Received: from denx.de (rS-VOmZY8eTVJ5Ucz4b55uGdKTsnbwdyxHNbI2jA2pHZ6MDf33VKEf@[217.235.220.36]) by fmrl09.sul.t-online.com
	with esmtp id 1A7fsT-02TiL20; Thu, 9 Oct 2003 20:51:09 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 93E324314F; Thu,  9 Oct 2003 20:51:07 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 6E6FFC59E4; Thu,  9 Oct 2003 20:51:04 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 6B60AC545E; Thu,  9 Oct 2003 20:51:04 +0200 (MEST)
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: YAMON Source code modification 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Thu, 09 Oct 2003 11:01:54 PDT."
             <20031009110154.B17781@mvista.com> 
Date: Thu, 09 Oct 2003 20:50:59 +0200
Message-Id: <20031009185104.6E6FFC59E4@atlas.denx.de>
X-Seen: false
X-ID: rS-VOmZY8eTVJ5Ucz4b55uGdKTsnbwdyxHNbI2jA2pHZ6MDf33VKEf@t-dialin.net
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3404
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips
Content-Length: 882
Lines: 26

In message <20031009110154.B17781@mvista.com> you wrote:
>
> Actually is YAMON code freely available?  Can someone from MIPS confirm
> that and perhaps point to the downloading place?  

It is available for free, but under a special license  that  prevents
you  from  using  it  for any hardware that is not a MIPS "Authorized
Product". See http://www.mips.com/LicenseMapper/Yamon_license


An alternative is to use  U-Boot,  the  universal  boot  loader  that
covers not only MIPS but also PowerPC, ARM, and even x86 systems. See
http://sourceforge.net/projects/u-boot

U-Boot is strictly GPL.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The ultimate barrier is one's viewpoint.
                        - Terry Pratchett, _The Dark Side of the Sun_

From Steve.Finney@SpirentCom.COM Thu Oct  9 22:34:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 22:35:00 +0100 (BST)
Received: from Iris.Adtech-Inc.COM ([IPv6:::ffff:63.165.80.18]:52772 "EHLO
	iris.Adtech-Inc.COM") by linux-mips.org with ESMTP
	id <S8225625AbTJIVe6> convert rfc822-to-8bit; Thu, 9 Oct 2003 22:34:58 +0100
content-class: urn:content-classes:message
Subject: MIPS bootloaders
Date: Thu, 9 Oct 2003 11:34:49 -1000
Message-ID: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB770@iris.adtech-inc.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: YAMON Source code modification 
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcOOomaYLdlEU2UoR2yDmesX26wdFQABvn1A
From: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
To: <linux-mips@linux-mips.org>
Return-Path: <Steve.Finney@SpirentCom.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3405
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Steve.Finney@SpirentCom.COM
Precedence: bulk
X-list: linux-mips
Content-Length: 753
Lines: 11

> 
> In message <20031009110154.B17781@mvista.com> you wrote:
> >
> > Actually is YAMON code freely available?  Can someone from 
> MIPS confirm
> > that and perhaps point to the downloading place?  


Broadcom has a "CFE" bootloader for their chip, and the documentation implies that it was designed to be for general purpose use (e.g., arch/mips/board/... directory hierarchy); it's covered by what I'd call a BSD style license (but IANAL). I don't know if it is publically available, and its current state of support is largely tailored to the peripherals on their eval boards, but (from my limited experience) it looks like  a reasonable and pretty-well written bootloader. Typical size is 400K, but this could be decreased (or increased :-) ).

sf

From ilya@gateway.total-knowledge.com Thu Oct  9 22:47:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 22:47:42 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:65511
	"EHLO alpha.total-knowledge.com") by linux-mips.org with ESMTP
	id <S8225633AbTJIVrK>; Thu, 9 Oct 2003 22:47:10 +0100
Received: (qmail 28610 invoked from network); 9 Oct 2003 21:47:06 -0000
Received: from unknown (HELO gateway.total-knowledge.com) (12.234.207.60)
  by alpha.total-knowledge.com with SMTP; 9 Oct 2003 21:47:06 -0000
Received: (qmail 19927 invoked by uid 502); 9 Oct 2003 21:47:06 -0000
Date: Thu, 9 Oct 2003 14:47:06 -0700
From: ilya@theIlya.com
To: Matthew Dharm <mdharm@momenco.com>
Cc: durai <durai@isofttech.com>, mips <linux-mips@linux-mips.org>
Subject: Re: how to include mips assembly in c code?
Message-ID: <20031009214706.GA19899@gateway.total-knowledge.com>
References: <007801c38e27$a1c81920$6b00a8c0@DURAI> <20031009010539.B3375@momenco.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8"
Content-Disposition: inline
In-Reply-To: <20031009010539.B3375@momenco.com>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3406
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1967
Lines: 68


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

Here we go - whole six lines of code! What a terrible copyright infigement!

On Thu, Oct 09, 2003 at 01:05:39AM -0700, Matthew Dharm wrote:
> I feel compelled to point out that the source file you are quoting looks
> suspiciously like it came from VxWorks, which means it is likely copyright
> Wind River Systems.  Using their code without permission would be illegal.
>=20
> Matt
>=20
> On Thu, Oct 09, 2003 at 11:08:56AM +0530, durai wrote:
> > hello,
> > I am having the following assembly code and i wanted to call this funct=
ion from a c code.
> > can anybody tell me how to include this code in a c program?
> >=20
> > /**********************************************************************=
********
> > *
> > * sysWbFlush - flush the write buffer
> > *
> > * This routine flushes the write buffers, making certain all
> > * subsequent memory writes have occurred.  It is used during critical p=
eriods
> > * only, e.g., after memory-mapped I/O register access.
> > *
> > * RETURNS: N/A
> >=20
> > * sysWbFlush (void)
> >=20
> > */
> >         .ent    sysWbFlush
> > sysWbFlush:
> >         li      t0, K1BASE              /* load uncached address       =
 */
> >         lw      t0, 0(t0)               /* read in order to flush      =
 */
> >         j       ra                      /* return to caller            =
 */
> >         .end    sysWbFlush
> >=20
> >=20
> > regards
> > durai
> --=20
> Matthew Dharm                              Work: mdharm@momenco.com
> Senior Software Designer, Momentum Computer
>=20
>=20

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

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

iD8DBQE/hddZ7sVBmHZT8w8RAu+ZAKCY0ivd8bPsH6WgaZkD0hkPeRESQgCfWFRq
W0O/YquO7eplzj0kIjTO0xM=
=ZHHF
-----END PGP SIGNATURE-----

--MGYHOYXEY6WxJCY8--

From dkesselr@mmc.atmel.com Thu Oct  9 22:50:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 22:50:39 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:20331
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225638AbTJIVuh>; Thu, 9 Oct 2003 22:50:37 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id RAA21815
	for <linux-mips@linux-mips.org>; Thu, 9 Oct 2003 17:50:20 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id RAA04218
	for <linux-mips@linux-mips.org>; Thu, 9 Oct 2003 17:50:19 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Thu, 9 Oct 2003 17:50:19 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: xfree and fbdevhw
Message-ID: <Pine.GSO.4.44.0310091747450.3383-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3407
X-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
Content-Length: 189
Lines: 8

Has anyone written a graphic card driver (w/hw accel) for mips? If you
have any hints or suggestions I would appreciate it.

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


From steve.scott@pioneer-pdt.com Thu Oct  9 23:09:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 23:09:22 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:27348
	"EHLO mail.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225625AbTJIWJU>; Thu, 9 Oct 2003 23:09:20 +0100
Received: from 127.0.0.1 (localhost.pioneer-pdt.com [127.0.0.1])
	by dummy.domain.name (Postfix) with SMTP
	id BB0609D81D; Thu,  9 Oct 2003 15:09:11 -0700 (PDT)
Received: from janelle (unknown [172.30.2.14])
	by mail.pioneer-pdt.com (Postfix) with SMTP
	id 608889D81B; Thu,  9 Oct 2003 15:09:11 -0700 (PDT)
Message-ID: <021e01c38eb2$4e95f840$2256fea9@janelle>
From: "Steve Scott" <steve.scott@pioneer-pdt.com>
To: <linux-mips@linux-mips.org>
Cc: <steve.scott@pioneer-pdt.com>
References: <5334.156.153.254.2.1065650433.squirrel@webmail.rmci.net> <20031009140319.GA17647@linux-mips.org>
Subject: bug in kernel_entry?
Date: Thu, 9 Oct 2003 15:11:36 -0700
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: <steve.scott@pioneer-pdt.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3408
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: steve.scott@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1583
Lines: 52

I ran across what looks like a bug in the 'kernel_entry' function in
linux/arch/mips/kernel/head.S while chasing another problem. Our
version of kernel_entry is for 2.4.17. 2.4.22 seems to have
the same problem.

kernel_entry initializes the kernel stack pointer 'kernelsp'. But then
immediately after this clears the bss, which has the side effect of setting
kernelsp to 0. In our system, on initial entry to cpu_idle(), kernelsp is 0.

The bug "heals" itself the first time schedule() is called. But, if for some
reason CP0_STATUS doesn't have CU0 set at startup (which would be
bad for other reasons), and you get an exception before the first call to
schedule() (e.g., the syscall to create "init"), the exception handler will
try to save registers starting from kernelsp, which is 0.

from head.S:

    NESTED(kernel_entry, 16, sp)
    .
    .
    .
    /*
     * Stack for kernel and init, current variable
     */
    la $28, init_task_union
    addiu t0, $28, KERNEL_STACK_SIZE-32
    subu sp, t0, 4*SZREG

    sw t0, kernelsp                /* <-- this is going to get overwritten below when bss
is cleared... [srs] */

    /* The firmware/bootloader passes argc/argp/envp
     * to us as arguments.  But clear bss first because
     * the romvec and other important info is stored there
     * by prom_init().
     */
    la t0, _edata                    /* <-- here is the code that eventually clears
kernelsp [srs] */
    sw zero, (t0)
    la t1, (_end - 4)
1:
    addiu t0, 4
    bne t0, t1, 1b
    sw zero, (t0)

   jal init_arch
    nop
  END(kernel_entry)

--steve



From wd@denx.de Thu Oct  9 23:10:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 23:10:45 +0100 (BST)
Received: from mailout03.sul.t-online.com ([IPv6:::ffff:194.25.134.81]:48108
	"EHLO mailout03.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225625AbTJIWKN>; Thu, 9 Oct 2003 23:10:13 +0100
Received: from fwd00.aul.t-online.de 
	by mailout03.sul.t-online.com with smtp 
	id 1A7iyt-0007vK-04; Fri, 10 Oct 2003 00:09:59 +0200
Received: from denx.de (V+OrpGZaweLnXTd1P+sxLPm-lCQq+BdWAfiix26zNOTo7MDorTx8Uk@[217.235.220.36]) by fmrl00.sul.t-online.com
	with esmtp id 1A7iym-0s26q00; Fri, 10 Oct 2003 00:09:52 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 333BA43164; Fri, 10 Oct 2003 00:09:51 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 3C8D1C59E4; Fri, 10 Oct 2003 00:09:50 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 3B56EC545E; Fri, 10 Oct 2003 00:09:50 +0200 (MEST)
To: ilya@theIlya.com
Cc: mips <linux-mips@linux-mips.org>
From: Wolfgang Denk <wd@denx.de>
Subject: Re: how to include mips assembly in c code? 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Thu, 09 Oct 2003 14:47:06 PDT."
             <20031009214706.GA19899@gateway.total-knowledge.com> 
Date: Fri, 10 Oct 2003 00:09:45 +0200
Message-Id: <20031009220950.3C8D1C59E4@atlas.denx.de>
X-Seen: false
X-ID: V+OrpGZaweLnXTd1P+sxLPm-lCQq+BdWAfiix26zNOTo7MDorTx8Uk@t-dialin.net
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3409
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips
Content-Length: 683
Lines: 20

In message <20031009214706.GA19899@gateway.total-knowledge.com> you wrote:
> 
> Here we go - whole six lines of code! What a terrible copyright infigement!

Six lines of code, and 12  lines  of  obvious  comments,  and  pretty
obvious  function  names - this is exactly what the Evil Empire (like
SCO et al) is looking for.

Please try and be a little less ignorant.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
In Nature there are neither rewards nor punishments, there are conse-
quences.                                            -- R.G. Ingersoll

From earlm@mips.com Thu Oct  9 23:19:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 23:20:16 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:33694 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225637AbTJIWTn>;
	Thu, 9 Oct 2003 23:19:43 +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 h99MGjdA017746;
	Thu, 9 Oct 2003 15:16:46 -0700 (PDT)
Received: from xchange.mips.com (xchange [192.168.20.31])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id PAA13994;
	Thu, 9 Oct 2003 15:20:53 -0700 (PDT)
Received: by xchange.mips.com with Internet Mail Service (5.5.2653.19)
	id <43ZYKV7W>; Thu, 9 Oct 2003 15:16:35 -0700
Message-ID: <0C5F4C7A1E3ED51194E200508B2CE32A02264E5B@xchange.mips.com>
From: "Mitchell, Earl" <earlm@mips.com>
To: "'David Kesselring'" <dkesselr@mmc.atmel.com>,
	linux-mips@linux-mips.org
Subject: RE: xfree and fbdevhw
Date: Thu, 9 Oct 2003 15:16:34 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Return-Path: <earlm@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3410
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlm@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 546
Lines: 23

Someone told me acceleration worked
with their Matrox card when they tried
it on Debian-mips. I've only used
matrox framebuffer version on malta
(i.e. PCI not AGP). 

-earlm

-----Original Message-----
From: David Kesselring [mailto:dkesselr@mmc.atmel.com]
Sent: Thursday, October 09, 2003 2:50 PM
To: linux-mips@linux-mips.org
Subject: xfree and fbdevhw


Has anyone written a graphic card driver (w/hw accel) for mips? If you
have any hints or suggestions I would appreciate it.

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


From Steve.Finney@SpirentCom.COM Thu Oct  9 23:42:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Oct 2003 23:42:29 +0100 (BST)
Received: from Iris.Adtech-Inc.COM ([IPv6:::ffff:63.165.80.18]:42039 "EHLO
	iris.Adtech-Inc.COM") by linux-mips.org with ESMTP
	id <S8225485AbTJIWmX> convert rfc822-to-8bit; Thu, 9 Oct 2003 23:42:23 +0100
content-class: urn:content-classes:message
Subject: CFE bootloader
Date: Thu, 9 Oct 2003 12:41:51 -1000
Message-ID: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB772@iris.adtech-inc.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: CFE bootloader
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcOOtpZD/LWPIupNSbOPKY8qgTC1kQ==
From: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
To: <linux-mips@linux-mips.org>
Return-Path: <Steve.Finney@SpirentCom.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3411
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Steve.Finney@SpirentCom.COM
Precedence: bulk
X-list: linux-mips
Content-Length: 478
Lines: 15

I have no idea how someone would make a choice 
between MIPS bootloaders (YAMON, U-Boot, CFE, Redboot(?),
and whatever else), but just so all the options are out 
there, here's access and licensing information for the 
Broadcom CFE bootloader: 

1. CFE's license is BSD-style.  It's also considered "GPL
    compatible" so you can take files from CFE and link into GPL'd
    programs.

2. It's available to anyone at
    http://sibyte.broadcom.com  - click on 'Resources.'


sf

From ppopov@mvista.com Fri Oct 10 00:00:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 00:00:59 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:26614 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225643AbTJIXA5>;
	Fri, 10 Oct 2003 00:00:57 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA15576
	for <linux-mips@linux-mips.org>; Thu, 9 Oct 2003 16:00:54 -0700
Subject: Re: CFE bootloader
From: Pete Popov <ppopov@mvista.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB772@iris.adtech-inc.com>
References: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB772@iris.adtech-inc.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1065740466.17498.70.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 09 Oct 2003 16:01:07 -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: 3412
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 721
Lines: 17

On Thu, 2003-10-09 at 15:41, Finney, Steve wrote:
> I have no idea how someone would make a choice 
> between MIPS bootloaders (YAMON, U-Boot, CFE, Redboot(?),
> and whatever else), but just so all the options are out 
> there, here's access and licensing information for the 
> Broadcom CFE bootloader: 

I would take a look at the community that's behind it. I like yamon and
it has worked great on the MIPS boards I've worked with. I haven't
played with uboot on MIPS, but what uboot has going for it is a
community that is improving it, adding features, new boards, etc. It's
also cross-arch so if you find yourself supporting multiple products on
different arches, you only have to deal with one bootloader.

Pete



From yuasa@hh.iij4u.or.jp Fri Oct 10 00:23:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 00:23:49 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:62691 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225405AbTJIXXQ>;
	Fri, 10 Oct 2003 00:23:16 +0100
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id IAA03796;
	Fri, 10 Oct 2003 08:23:12 +0900 (JST)
Received: 4UMDO01 id h99NNCl13420; Fri, 10 Oct 2003 08:23:12 +0900 (JST)
Received: 4UMRO00 id h99NNAO17692; Fri, 10 Oct 2003 08:23:11 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Fri, 10 Oct 2003 08:23:10 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: [patch] VR4133
Message-Id: <20031010082310.4bd1de37.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20031008003402.23a326cb.yuasa@hh.iij4u.or.jp>
References: <20031008003402.23a326cb.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3413
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 289
Lines: 18

Hello Ralf,

Do these patches have any problem?

Yoichi

On Wed, 8 Oct 2003 00:34:02 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hello Ralf,
> 
> I made patches for NEC VR4133.
> These patches add support of new CPU of NEC.
> 
> Please apply this patch to CVS tree.
> 
> Yoichi
> 

From Steve.Finney@SpirentCom.COM Fri Oct 10 00:38:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 00:38:17 +0100 (BST)
Received: from Iris.Adtech-Inc.COM ([IPv6:::ffff:63.165.80.18]:33353 "EHLO
	iris.Adtech-Inc.COM") by linux-mips.org with ESMTP
	id <S8225405AbTJIXiO> convert rfc822-to-8bit; Fri, 10 Oct 2003 00:38:14 +0100
content-class: urn:content-classes:message
Subject: RE: CFE bootloader
Date: Thu, 9 Oct 2003 13:37:46 -1000
Message-ID: <DC1BF43A8FAE654DA6B3FB7836DD3A560180696C@iris.adtech-inc.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: CFE bootloader
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcOOuVj2E806TCi2RBmInJWpVFzVBgABLAXg
From: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
To: "Pete Popov" <ppopov@mvista.com>,
	"Linux MIPS mailing list" <linux-mips@linux-mips.org>
Return-Path: <Steve.Finney@SpirentCom.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3414
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Steve.Finney@SpirentCom.COM
Precedence: bulk
X-list: linux-mips
Content-Length: 311
Lines: 9

> I like  yamon and
> it has worked great on the MIPS boards I've worked with. I haven't
> played with uboot on MIPS, but what uboot has going for it is a
> community that is improving it, adding features, new boards, etc. 

Yamon and U-boot also have the advantage of having much
cooler names than CFE :-)

sf

From jiahanchen@yahoo.com Fri Oct 10 03:27:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 03:28:09 +0100 (BST)
Received: from web40802.mail.yahoo.com ([IPv6:::ffff:66.218.78.179]:18235 "HELO
	web40802.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225457AbTJJC1h>; Fri, 10 Oct 2003 03:27:37 +0100
Message-ID: <20031010022730.66347.qmail@web40802.mail.yahoo.com>
Received: from [216.51.101.144] by web40802.mail.yahoo.com via HTTP; Thu, 09 Oct 2003 19:27:30 PDT
Date: Thu, 9 Oct 2003 19:27:30 -0700 (PDT)
From: Jiahan Chen <jiahanchen@yahoo.com>
Subject: Sign-off
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <jiahanchen@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: 3415
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jiahanchen@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 253
Lines: 12

Mips List Administrator,

Please remove my name from this distribution e-mail
list as soon as possible. Thanks!

Jiahan


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

From ralf@linux-mips.org Fri Oct 10 14:23:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 14:23:19 +0100 (BST)
Received: from p508B6977.dip.t-dialin.net ([IPv6:::ffff:80.139.105.119]:32472
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225420AbTJJNXP>; Fri, 10 Oct 2003 14:23: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 h9ADNENK004278;
	Fri, 10 Oct 2003 15:23:14 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9ADNCiJ004277;
	Fri, 10 Oct 2003 15:23:12 +0200
Date: Fri, 10 Oct 2003 15:23:12 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Steve Scott <steve.scott@pioneer-pdt.com>
Cc: linux-mips@linux-mips.org
Subject: Re: bug in kernel_entry?
Message-ID: <20031010132312.GB27103@linux-mips.org>
References: <5334.156.153.254.2.1065650433.squirrel@webmail.rmci.net> <20031009140319.GA17647@linux-mips.org> <021e01c38eb2$4e95f840$2256fea9@janelle>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <021e01c38eb2$4e95f840$2256fea9@janelle>
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: 3416
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 378
Lines: 9

On Thu, Oct 09, 2003 at 03:11:36PM -0700, Steve Scott wrote:

> kernel_entry initializes the kernel stack pointer 'kernelsp'. But then
> immediately after this clears the bss, which has the side effect of setting
> kernelsp to 0. In our system, on initial entry to cpu_idle(), kernelsp is 0.

Funny this wasn't noticed for so long.  Fix is in CVS, thanks for reporting.

  Ralf

From durai@isofttech.com Fri Oct 10 14:59:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 14:59:43 +0100 (BST)
Received: from [IPv6:::ffff:203.199.202.17] ([IPv6:::ffff:203.199.202.17]:22535
	"EHLO pub.isofttechindia.com") by linux-mips.org with ESMTP
	id <S8225398AbTJJN7i>; Fri, 10 Oct 2003 14:59:38 +0100
Received: from DURAI ([192.168.0.107])
	by pub.isofttechindia.com (8.11.0/8.11.0) with SMTP id h9ADsbj06936
	for <linux-mips@linux-mips.org>; Fri, 10 Oct 2003 19:24:37 +0530
Message-ID: <02d001c38f36$ba4a8e00$6b00a8c0@DURAI>
From: "durai" <durai@isofttech.com>
To: "mips" <linux-mips@linux-mips.org>
Subject: unresolved symbol litodp,dptoli,dpmul - floating point operations in kernel
Date: Fri, 10 Oct 2003 19:29:30 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_02CD_01C38F64.D399F610"
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: <durai@isofttech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3417
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: durai@isofttech.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2368
Lines: 66

This is a multi-part message in MIME format.

------=_NextPart_000_02CD_01C38F64.D399F610
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hello,
I am using a mips cross compiler (mips-linux-gcc, version 2.95.3) to =
build my driver
I am using some floating point operations in a wireless lan driver for a =
mips platform in ucLinux, When i load the driver I am getting unresolved =
symbols

>=20
> insmod: unresolved symbol dptoli
> insmod: unresolved symbol dpmul
> insmod: unresolved symbol litodp

And somebody told me that we cannot use floating point operations in =
kernel code, but i desperately need to use floating point operations.=20
please tell me how to use floating point operations in kernel code.

thanks & regards
durai
------=_NextPart_000_02CD_01C38F64.D399F610
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I am using a mips cross compiler=20
(mips-linux-gcc,&nbsp;version 2.95.3) to build my driver</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I am using&nbsp;some floating point =
operations in a=20
wireless lan driver for a mips platform in ucLinux, When i load the =
driver I am=20
getting unresolved symbols</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&gt;<I> </I><BR>&gt;<I> insmod: unresolved symbol =
dptoli</I><BR>&gt;<I>=20
insmod: unresolved symbol dpmul</I><BR>&gt;<I> insmod: unresolved symbol =

litodp</I><BR></DIV>
<DIV><FONT face=3DArial size=3D2>And somebody told me that we cannot use =
floating=20
point operations in kernel code, but i desperately need to use floating =
point=20
operations. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>please tell me how to use floating =
point operations=20
in kernel code.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanks &amp; regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>durai</FONT></DIV></BODY></HTML>

------=_NextPart_000_02CD_01C38F64.D399F610--


From Geert.Uytterhoeven@sonycom.com Fri Oct 10 15:28:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 15:28:47 +0100 (BST)
Received: from [IPv6:::ffff:80.88.36.193] ([IPv6:::ffff:80.88.36.193]:12726
	"EHLO witte.sonytel.be") by linux-mips.org with ESMTP
	id <S8225401AbTJJO2k>; Fri, 10 Oct 2003 15:28:40 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id h9AESRQG002034;
	Fri, 10 Oct 2003 16:28:27 +0200 (MEST)
Date: Fri, 10 Oct 2003 16:28:27 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: durai <durai@isofttech.com>
cc: mips <linux-mips@linux-mips.org>
Subject: Re: unresolved symbol litodp,dptoli,dpmul - floating point operations
 in kernel
In-Reply-To: <02d001c38f36$ba4a8e00$6b00a8c0@DURAI>
Message-ID: <Pine.GSO.4.21.0310101627400.8302-100000@waterleaf.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: 3418
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1024
Lines: 26

On Fri, 10 Oct 2003, durai wrote:
> I am using a mips cross compiler (mips-linux-gcc, version 2.95.3) to build my driver
> I am using some floating point operations in a wireless lan driver for a mips platform in ucLinux, When i load the driver I am getting unresolved symbols
> 
> > 
> > insmod: unresolved symbol dptoli
> > insmod: unresolved symbol dpmul
> > insmod: unresolved symbol litodp
> 
> And somebody told me that we cannot use floating point operations in kernel code, but i desperately need to use floating point operations. 
> please tell me how to use floating point operations in kernel code.

Do not use floating point operations in kernel code.
Re-implement using fixed point or something like that.

Gr{oetje,eeting}s,

						Geert

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

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


From ralf@linux-mips.org Fri Oct 10 15:59:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 16:00:01 +0100 (BST)
Received: from p508B6977.dip.t-dialin.net ([IPv6:::ffff:80.139.105.119]:23518
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225398AbTJJO7w>; Fri, 10 Oct 2003 15:59:52 +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 h9AExoNK010679;
	Fri, 10 Oct 2003 16:59:50 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9AExnaV010678;
	Fri, 10 Oct 2003 16:59:49 +0200
Date: Fri, 10 Oct 2003 16:59:49 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: exister99@velocitus.net
Cc: linux-mips@linux-mips.org
Subject: Re: mips 32 bit HIGHMEM support
Message-ID: <20031010145948.GB10373@linux-mips.org>
References: <5334.156.153.254.2.1065650433.squirrel@webmail.rmci.net> <20031009140319.GA17647@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031009140319.GA17647@linux-mips.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3419
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 482
Lines: 11

On Thu, Oct 09, 2003 at 04:03:20PM +0200, Ralf Baechle wrote:

> It's got a limitation - it only works on physically indexed D-caches or
> more exactly processors that don't suffer from cache aliases.  On
> processors that have such aliases the necessary flushes are rather bad
> for performance so this currently simply isn't suported.

Small update - I changed the memory managment code to ignore highmem
on cache configuration that are not supported by the highmem code.

  Ralf

From jsun@mvista.com Fri Oct 10 17:58:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 17:58:46 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:36340 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225410AbTJJQ6n>;
	Fri, 10 Oct 2003 17:58:43 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h9AGwOL17215;
	Fri, 10 Oct 2003 09:58:24 -0700
Date: Fri, 10 Oct 2003 09:58:24 -0700
From: Jun Sun <jsun@mvista.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: durai <durai@isofttech.com>, mips <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: unresolved symbol litodp,dptoli,dpmul - floating point operations in kernel
Message-ID: <20031010095824.B4192@mvista.com>
References: <02d001c38f36$ba4a8e00$6b00a8c0@DURAI> <Pine.GSO.4.21.0310101627400.8302-100000@waterleaf.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.21.0310101627400.8302-100000@waterleaf.sonytel.be>; from geert@linux-m68k.org on Fri, Oct 10, 2003 at 04:28:27PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3420
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1290
Lines: 39

On Fri, Oct 10, 2003 at 04:28:27PM +0200, Geert Uytterhoeven wrote:
> On Fri, 10 Oct 2003, durai wrote:
> > I am using a mips cross compiler (mips-linux-gcc, version 2.95.3) to build my driver
> > I am using some floating point operations in a wireless lan driver for a mips platform in ucLinux, When i load the driver I am getting unresolved symbols
> > 
> > > 
> > > insmod: unresolved symbol dptoli
> > > insmod: unresolved symbol dpmul
> > > insmod: unresolved symbol litodp
> > 
> > And somebody told me that we cannot use floating point operations in kernel code, but i desperately need to use floating point operations. 
> > please tell me how to use floating point operations in kernel code.
> 
> Do not use floating point operations in kernel code.
> Re-implement using fixed point or something like that.
>

If you are really really desparate, something like the following
might work.

void use_fpu(void)
{
	if (is_fpu_owner()) {
		save_fp(current);
		loose_fpu();
		enable_fpu();
	}
	local_irq_save(flags);
	
	/* now use fpu and store the results */

	local_irq_restore(flags);
}

I like to emphsize this is just a hack and I am not even sure if it will work
at all.  If compiler complains you might have to change the
CC flag for that file or use fpu with inline assembly.

Jun

From Krishna.Kondaka@MCDATA.com Fri Oct 10 18:44:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 18:44:35 +0100 (BST)
Received: from mcjekyll.mcdata.com ([IPv6:::ffff:144.49.6.25]:7108 "EHLO
	380GATE01out.mcdata.com") by linux-mips.org with ESMTP
	id <S8225410AbTJJRo3> convert rfc822-to-8bit; Fri, 10 Oct 2003 18:44:29 +0100
Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 10 Oct 2003 11:44:21 -0600
Received: from MC4EXCH03.mcdata.com ([172.16.11.123]) by 380GATE01 with InterScan Messaging Security Suite; Fri, 10 Oct 2003 11:44:21 -0600
Received: from SNEXCH01.mcdata.com ([172.19.161.13]) by MC4EXCH03.mcdata.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 10 Oct 2003 11:44:20 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Subject: RE: mips 32 bit HIGHMEM support
Date: Fri, 10 Oct 2003 10:44:19 -0700
Message-ID: <501EA67E9359C645A10C42EB5B52480D2AB2D0@SNEXCH01.mcdata.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: mips 32 bit HIGHMEM support
Thread-Index: AcOObmUOjHI27547Ra+7/Heevg8OnQA5s2qQ
From: "Krishna Kondaka" <Krishna.Kondaka@MCDATA.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
X-OriginalArrivalTime: 10 Oct 2003 17:44:20.0858 (UTC) FILETIME=[22B25DA0:01C38F56]
Return-Path: <Krishna.Kondaka@MCDATA.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3421
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Krishna.Kondaka@MCDATA.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3723
Lines: 88


Ralf,

How safe is it to enable HIGHMEM for sibyte/broadcom's BCM12500 processors?
Do you know if any one is using HIGHMEM enabled linux on BCM12500s?

Thanks
Krishna

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Thursday, October 09, 2003 7:03 AM
To: exister99@velocitus.net
Cc: linux-mips@linux-mips.org
Subject: Re: mips 32 bit HIGHMEM support


On Wed, Oct 08, 2003 at 04:00:33PM -0600, exister99@velocitus.net wrote:

> I work for HP in Boise, ID, USA.  For the last six months I have been
> working with Linux in HP Laser jet Printers.  It is running in a formatter
> board that features an ASIC with a MIPS 20Kc core.

Reminds me of the HP Laserjet code in the kernel.  Anybody still using
or testing that?

> The original Linux port was achieved by others working before me.  I began
> working on applications for it when I started here (to make it print
> actually).  As I have tried to milk more performance out of this board the
> recurrent bottleneck has been the fact that the kernel only recognizes
> 512Mb of RAM.  So my current endeavor is fix the kernel so it sees the 1G
> of RAM that is physically present in the system.
> 
> I reconfigured and rebuilt the kernel with HIGHMEM support.  HIGHMEM is
> seen and booting up goes splendidly until init (pid 1) kicks off.  Early
> on in the execution of init the system crashes.  Specifically it crashes
> in do_page_fault().  A couple of strange things I have noticed:
> 
> 1.  All memory pages are divied up between the DMA Zone and the HIGHMEM
> Zone at bootup.  the NORMAL zone gets 0 pages.  Not sure if this is
> normal.
> 
> 2.  The virtual address that do_page_fault() chokes on is 0x00000000. 
> This doesn't seem like a reasonable address for init to be accessing
> especially considering its mem map only contains the chunks
> 0x10000000-0x10001000 and 0x400000-0x40b000 (I got these by traversing
> init's mm->mm_rb tree).
> 
> I decided to contact you about this after digging up this old posting of
> yours:

[... ancient posting deleted ...]

> I think this describes my machine.
> 
> If this is an issue who's solution is old news please point me to the
> solution.  In any case any ideas or guidance regarding this crash would be
> greatly appreciated.

In the meantime there is a highmem implementation for the MIPS kernel.
It's got a limitation - it only works on physically indexed D-caches or
more exactly processors that don't suffer from cache aliases.  On
processors that have such aliases the necessary flushes are rather bad
for performance so this currently simply isn't suported.

Anyway, for a 64-bit processor such as the 20Kc I suggest a 64-bit kernel.
Highmem is a pain and 64-bit is the cure.

  Ralf


SPECIAL NOTICE 

All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
herby notified that you must not read this transmission and that disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.

Anyone who receives confidential and privileged information in error should
notify us immediately by telephone and mail the original message to us at
the above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions apply to that
information. (gate01)

From ralf@linux-mips.org Fri Oct 10 18:53:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 18:53:46 +0100 (BST)
Received: from p508B6977.dip.t-dialin.net ([IPv6:::ffff:80.139.105.119]:22248
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225429AbTJJRxe>; Fri, 10 Oct 2003 18:53:34 +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 h9AHrWNK016847;
	Fri, 10 Oct 2003 19:53:32 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9AHrV7U016846;
	Fri, 10 Oct 2003 19:53:31 +0200
Date: Fri, 10 Oct 2003 19:53:31 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Krishna Kondaka <Krishna.Kondaka@MCDATA.com>
Cc: linux-mips@linux-mips.org
Subject: Re: mips 32 bit HIGHMEM support
Message-ID: <20031010175331.GA11082@linux-mips.org>
References: <501EA67E9359C645A10C42EB5B52480D2AB2D0@SNEXCH01.mcdata.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <501EA67E9359C645A10C42EB5B52480D2AB2D0@SNEXCH01.mcdata.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: 3422
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 775
Lines: 18

On Fri, Oct 10, 2003 at 10:44:19AM -0700, Krishna Kondaka wrote:

> How safe is it to enable HIGHMEM for sibyte/broadcom's BCM12500 processors?
> Do you know if any one is using HIGHMEM enabled linux on BCM12500s?

Perfectly reliable - in fact highmem for MIPS was written and debugged
on this chip but there are many other that will work just as fine since
they share the technical properties required to run highmem.

Actually with the latest change in CVS enabling CONFIG_HIGHMEM is always
safe; in cases where it's not safe the kernel will simply limit the
memory it's using to just lowmem.

Stil the usual warning applies - highmem is a kludge and for systems
doing heavy I/O it can be a rather slow kludge.  64-bit is the Nirvana
kernel hackers are seeking ;-)

  Ralf

From kwalker@broadcom.com Fri Oct 10 19:56:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 19:57:01 +0100 (BST)
Received: from mms3.broadcom.com ([IPv6:::ffff:63.70.210.38]:22024 "EHLO
	mms3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225428AbTJJS47>; Fri, 10 Oct 2003 19:56:59 +0100
Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.5.3)); Fri, 10 Oct 2003 11:56:59 -0700
Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com
 [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id LAA07228 for <linux-mips@linux-mips.org>; Fri, 10 Oct 2003 11:56:17
 -0700 (PDT)
Received: from broadcom.com (ldt-sj3-158 [10.21.64.158]) by
 mail-sj1-1.sj.broadcom.com (8.12.9/8.12.4/SSM) with ESMTP id
 h9AIujKX002186 for <linux-mips@linux-mips.org>; Fri, 10 Oct 2003 11:56:
 45 -0700 (PDT)
Message-ID: <3F8700ED.4AE74ECE@broadcom.com>
Date: Fri, 10 Oct 2003 11:56:45 -0700
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.20-18.7 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
References: <20031009160717Z8225587-1272+7472@linux-mips.org>
X-WSS-ID: 1399DF713300071-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <kwalker@broadcom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3423
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kwalker@broadcom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 400
Lines: 19

This doesn't compile.  Remove the commas.

Of course, "vt_check" doesn't build anymore either - I'm trying to fix
that one.

Kip

macro@linux-mips.org wrote:
> 
> CVSROOT:        /home/cvs
> Module name:    linux
> Changes by:     macro@ftp.linux-mips.org        03/10/09 17:07:12
> 
> Modified files:
>         arch/mips/kernel: ioctl32.c
> 
> Log message:
>         PIO_FONTX and KDFONTOP ioctls.


From kwalker@broadcom.com Fri Oct 10 20:04:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Oct 2003 20:04:09 +0100 (BST)
Received: from mms3.broadcom.com ([IPv6:::ffff:63.70.210.38]:54027 "EHLO
	mms3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225428AbTJJTED>; Fri, 10 Oct 2003 20:04:03 +0100
Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.5.3)); Fri, 10 Oct 2003 12:04:08 -0700
Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com
 [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id MAA08972; Fri, 10 Oct 2003 12:03:27 -0700 (PDT)
Received: from broadcom.com (ldt-sj3-158 [10.21.64.158]) by
 mail-sj1-1.sj.broadcom.com (8.12.9/8.12.4/SSM) with ESMTP id
 h9AJ3rKX003995; Fri, 10 Oct 2003 12:03:55 -0700 (PDT)
Message-ID: <3F870299.E96FCFE2@broadcom.com>
Date: Fri, 10 Oct 2003 12:03:53 -0700
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.20-18.7 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
References: <20031009160717Z8225587-1272+7472@linux-mips.org>
 <3F8700ED.4AE74ECE@broadcom.com>
X-WSS-ID: 1399DD223300966-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <kwalker@broadcom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3424
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kwalker@broadcom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 550
Lines: 27

Curse the "Reply-To" from CVS commit messages.  This wasn't intended for
the list.

sorry,
Kip

Kip Walker wrote:
> 
> This doesn't compile.  Remove the commas.
> 
> Of course, "vt_check" doesn't build anymore either - I'm trying to fix
> that one.
> 
> Kip
> 
> macro@linux-mips.org wrote:
> >
> > CVSROOT:        /home/cvs
> > Module name:    linux
> > Changes by:     macro@ftp.linux-mips.org        03/10/09 17:07:12
> >
> > Modified files:
> >         arch/mips/kernel: ioctl32.c
> >
> > Log message:
> >         PIO_FONTX and KDFONTOP ioctls.


From ralf@linux-mips.org Sat Oct 11 08:27:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Oct 2003 08:27:32 +0100 (BST)
Received: from p508B6977.dip.t-dialin.net ([IPv6:::ffff:80.139.105.119]:8104
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225310AbTJKH1U>; Sat, 11 Oct 2003 08:27: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 h9B7RENK022226;
	Sat, 11 Oct 2003 09:27:14 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9B7RAsm022164;
	Sat, 11 Oct 2003 09:27:10 +0200
Date: Sat, 11 Oct 2003 09:27:09 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Kip Walker <kwalker@broadcom.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20031011072709.GA16273@linux-mips.org>
References: <20031009160717Z8225587-1272+7472@linux-mips.org> <3F8700ED.4AE74ECE@broadcom.com> <3F870299.E96FCFE2@broadcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F870299.E96FCFE2@broadcom.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: 3425
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 283
Lines: 9

On Fri, Oct 10, 2003 at 12:03:53PM -0700, Kip Walker wrote:

> Curse the "Reply-To" from CVS commit messages.  This wasn't intended for
> the list.

The Reply-To was necessary because linux-cvs isn't a mailing list that
can be posted to, that is mail sent to it will bounce.

  Ralf

From alanliu@trident.com.cn Mon Oct 13 02:53:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Oct 2003 02:53:41 +0100 (BST)
Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:34824
	"EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP
	id <S8225629AbTJMBxj>; Mon, 13 Oct 2003 02:53:39 +0100
Received: by TMTMS with Internet Mail Service (5.5.2653.19)
	id <SK19289B>; Mon, 13 Oct 2003 09:45:39 +0800
Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F6801AC0B85@TMTMS>
From: "Liu Hongming (Alan)" <alanliu@trident.com.cn>
To: linux-mips@linux-mips.org
Subject: need help on unaligned loads,stores!
Date: Mon, 13 Oct 2003 09:44:56 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3912B.9AA742E0"
Return-Path: <alanliu@trident.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: 3426
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alanliu@trident.com.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 2066
Lines: 59

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

------_=_NextPart_001_01C3912B.9AA742E0
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi all,

I am porting linux for a cpu that doesnt support unaligned loads/stores
instructions.

when using memcpy in arch/mips/memcpy.S,it will not work on these
instructions.

Any one could help me to deal with this? Have you ever ported linux for this
kind cpu?

And anyone could tell me which cpu doesnt support these instructions
either,and has

been ported for linux?

 

Best Regards,

Alan


------_=_NextPart_001_01C3912B.9AA742E0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial" hb_focus_attach="true">
<P><SPAN class=979394001-13102003><FONT size=2>Hi all,</FONT></SPAN></P>
<P><SPAN class=979394001-13102003><FONT size=2>I am porting linux&nbsp;for a cpu 
that doesnt support unaligned loads/stores instructions.</FONT></SPAN></P>
<P><SPAN class=979394001-13102003><FONT size=2>when using memcpy in 
arch/mips/memcpy.S,it will not work on these instructions.</FONT></SPAN></P>
<P><SPAN class=979394001-13102003><FONT size=2>Any one could help me to deal 
with this? Have you ever ported linux for this kind cpu?</FONT></SPAN></P>
<P><SPAN class=979394001-13102003><FONT size=2>And anyone could tell&nbsp;me 
which cpu doesnt support these instructions either,and has</FONT></SPAN></P>
<P><SPAN class=979394001-13102003><FONT size=2>been ported for 
linux?</FONT></SPAN></P>
<P><SPAN class=979394001-13102003></SPAN>&nbsp;</P>
<P><SPAN class=979394001-13102003></SPAN><SPAN class=979394001-13102003><FONT 
size=2>Best Regards,</FONT></SPAN></P>
<P><SPAN class=979394001-13102003><FONT 
size=2>Alan</FONT></SPAN></P></BODY></HTML>

------_=_NextPart_001_01C3912B.9AA742E0--

From thomas@horsten.com Mon Oct 13 19:22:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Oct 2003 19:22:35 +0100 (BST)
Received: from [IPv6:::ffff:217.157.19.70] ([IPv6:::ffff:217.157.19.70]:21253
	"EHLO jehova.dsm.dk") by linux-mips.org with ESMTP
	id <S8225428AbTJMSWX>; Mon, 13 Oct 2003 19:22:23 +0100
Received: (qmail 26856 invoked from network); 13 Oct 2003 18:22:20 -0000
Received: from cpc5-cmbg1-3-0-cust166.cmbg.cable.ntl.com (HELO home.horsten.com) (@81.100.89.166)
  by server14.dsm.dk with RC4-MD5 encrypted SMTP; 13 Oct 2003 18:22:20 -0000
From: Thomas Horsten <thomas@horsten.com>
To: "Liu Hongming (Alan)" <alanliu@trident.com.cn>,
	linux-mips@linux-mips.org
Subject: Re: need help on unaligned loads,stores!
Date: Mon, 13 Oct 2003 19:27:07 +0100
User-Agent: KMail/1.5.4
References: <15F9E1AE3207D6119CEA00D0B7DD5F6801AC0B85@TMTMS>
In-Reply-To: <15F9E1AE3207D6119CEA00D0B7DD5F6801AC0B85@TMTMS>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200310131927.07171.thomas@horsten.com>
Return-Path: <thomas@horsten.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3427
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thomas@horsten.com
Precedence: bulk
X-list: linux-mips
Content-Length: 678
Lines: 25

On Monday 13 October 2003 02:44, Liu Hongming (Alan) wrote:

> I am porting linux for a cpu that doesnt support unaligned loads/stores
> instructions.
>
> when using memcpy in arch/mips/memcpy.S,it will not work on these
> instructions.
>
> Any one could help me to deal with this? Have you ever ported linux for
> this kind cpu?
>
> And anyone could tell me which cpu doesnt support these instructions
> either,and has
>
> been ported for linux?

Almost all MIPS CPU's are like this, and don't support unaligned accesses.

The memcpy in arch/mips/lib/memcpy.S already handles this (by copying the end 
and beginning using byte-accesses if not aligned).

Best regards,

Thomas


From Geert.Uytterhoeven@sonycom.com Mon Oct 13 20:34:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Oct 2003 20:34:24 +0100 (BST)
Received: from [IPv6:::ffff:80.88.36.193] ([IPv6:::ffff:80.88.36.193]:27565
	"EHLO witte.sonytel.be") by linux-mips.org with ESMTP
	id <S8225457AbTJMTeM>; Mon, 13 Oct 2003 20:34:12 +0100
Received: from starflower.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id h9DJY7QG001995;
	Mon, 13 Oct 2003 21:34:07 +0200 (MEST)
Date: Mon, 13 Oct 2003 21:34:07 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Thomas Horsten <thomas@horsten.com>
cc: "Liu Hongming (Alan)" <alanliu@trident.com.cn>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: need help on unaligned loads,stores!
In-Reply-To: <200310131927.07171.thomas@horsten.com>
Message-ID: <Pine.GSO.4.21.0310132132550.26520-100000@starflower.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: 3428
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1018
Lines: 32

On Mon, 13 Oct 2003, Thomas Horsten wrote:
> On Monday 13 October 2003 02:44, Liu Hongming (Alan) wrote:
> > I am porting linux for a cpu that doesnt support unaligned loads/stores
> > instructions.
> >
> > when using memcpy in arch/mips/memcpy.S,it will not work on these
> > instructions.
> >
> > Any one could help me to deal with this? Have you ever ported linux for
> > this kind cpu?
> >
> > And anyone could tell me which cpu doesnt support these instructions
> > either,and has
> >
> > been ported for linux?
> 
> Almost all MIPS CPU's are like this, and don't support unaligned accesses.

I guess Liu meant the (patented) instructions to do explicit unaligned
accesses.  Real MIPS CPUs do support these.

Gr{oetje,eeting}s,

						Geert

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

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


From ralf@linux-mips.org Mon Oct 13 21:49:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Oct 2003 21:49:19 +0100 (BST)
Received: from p508B65AB.dip.t-dialin.net ([IPv6:::ffff:80.139.101.171]:57755
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225470AbTJMUtQ>; Mon, 13 Oct 2003 21:49:16 +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 h9DKn9NK025630;
	Mon, 13 Oct 2003 22:49:09 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9DKn7Q7025629;
	Mon, 13 Oct 2003 22:49:07 +0200
Date: Mon, 13 Oct 2003 22:49:06 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Horsten <thomas@horsten.com>,
	"Liu Hongming (Alan)" <alanliu@trident.com.cn>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: need help on unaligned loads,stores!
Message-ID: <20031013204906.GA21100@linux-mips.org>
References: <200310131927.07171.thomas@horsten.com> <Pine.GSO.4.21.0310132132550.26520-100000@starflower.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0310132132550.26520-100000@starflower.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: 3429
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 407
Lines: 10

On Mon, Oct 13, 2003 at 09:34:07PM +0200, Geert Uytterhoeven wrote:

> I guess Liu meant the (patented) instructions to do explicit unaligned
> accesses.  Real MIPS CPUs do support these.

That correct.  Unfortunately emulating of these instructions in exception
handlers would also be covered by the patents, so rewriting which would
be rather easy in all cases I can think of is the way to go ...

  Ralf

From ralf@linux-mips.org Mon Oct 13 21:54:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Oct 2003 21:54:49 +0100 (BST)
Received: from p508B65AB.dip.t-dialin.net ([IPv6:::ffff:80.139.101.171]:14748
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225470AbTJMUyq>; Mon, 13 Oct 2003 21:54:46 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h9DKsbNK025768;
	Mon, 13 Oct 2003 22:54:37 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9DKsZra025767;
	Mon, 13 Oct 2003 22:54:35 +0200
Date: Mon, 13 Oct 2003 22:54:35 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	durai <durai@isofttech.com>, mips <linux-mips@linux-mips.org>
Subject: Re: unresolved symbol litodp,dptoli,dpmul - floating point operations in kernel
Message-ID: <20031013205435.GB21100@linux-mips.org>
References: <02d001c38f36$ba4a8e00$6b00a8c0@DURAI> <Pine.GSO.4.21.0310101627400.8302-100000@waterleaf.sonytel.be> <20031010095824.B4192@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031010095824.B4192@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: 3430
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 880
Lines: 32

On Fri, Oct 10, 2003 at 09:58:24AM -0700, Jun Sun wrote:

> > > > insmod: unresolved symbol dptoli
> > > > insmod: unresolved symbol dpmul
> > > > insmod: unresolved symbol litodp

> If you are really really desparate, something like the following
> might work.
> 
> void use_fpu(void)
> {
> 	if (is_fpu_owner()) {
> 		save_fp(current);
> 		loose_fpu();
> 		enable_fpu();
> 	}
> 	local_irq_save(flags);
> 	
> 	/* now use fpu and store the results */
> 
> 	local_irq_restore(flags);
> }
> 
> I like to emphsize this is just a hack and I am not even sure if it will work
> at all.  If compiler complains you might have to change the
> CC flag for that file or use fpu with inline assembly.

The symbols he was missing are used for software floating point.  Software
floating point in kernel space is perfectly ok since it doesn't use the FPU
so your hack isn't even needed.

  Ralf

From thomas@horsten.com Mon Oct 13 22:11:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Oct 2003 22:11:19 +0100 (BST)
Received: from [IPv6:::ffff:217.157.19.70] ([IPv6:::ffff:217.157.19.70]:61960
	"EHLO jehova.dsm.dk") by linux-mips.org with ESMTP
	id <S8225470AbTJMVLO>; Mon, 13 Oct 2003 22:11:14 +0100
Received: (qmail 28615 invoked from network); 13 Oct 2003 21:11:13 -0000
Received: from cpc5-cmbg1-3-0-cust166.cmbg.cable.ntl.com (HELO home.horsten.com) (@81.100.89.166)
  by server14.dsm.dk with RC4-MD5 encrypted SMTP; 13 Oct 2003 21:11:13 -0000
From: Thomas Horsten <thomas@horsten.com>
To: Ralf Baechle <ralf@linux-mips.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: need help on unaligned loads,stores!
Date: Mon, 13 Oct 2003 22:15:59 +0100
User-Agent: KMail/1.5.4
Cc: "Liu Hongming (Alan)" <alanliu@trident.com.cn>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
References: <200310131927.07171.thomas@horsten.com> <Pine.GSO.4.21.0310132132550.26520-100000@starflower.sonytel.be> <20031013204906.GA21100@linux-mips.org>
In-Reply-To: <20031013204906.GA21100@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200310132215.59826.thomas@horsten.com>
Return-Path: <thomas@horsten.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3431
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thomas@horsten.com
Precedence: bulk
X-list: linux-mips
Content-Length: 320
Lines: 10

On Monday 13 October 2003 21:49, Ralf Baechle wrote:

> That correct.  Unfortunately emulating of these instructions in exception
> handlers would also be covered by the patents, so rewriting which would
> be rather easy in all cases I can think of is the way to go ...

Surely not in Europe (yet), at least?

- Thomas


From ralf@linux-mips.org Mon Oct 13 22:37:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Oct 2003 22:37:33 +0100 (BST)
Received: from p508B65AB.dip.t-dialin.net ([IPv6:::ffff:80.139.101.171]:2207
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225470AbTJMVha>; Mon, 13 Oct 2003 22:37:30 +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 h9DLbQNK026680;
	Mon, 13 Oct 2003 23:37:26 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9DLbQjO026679;
	Mon, 13 Oct 2003 23:37:26 +0200
Date: Mon, 13 Oct 2003 23:37:26 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Thomas Horsten <thomas@horsten.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	"Liu Hongming (Alan)" <alanliu@trident.com.cn>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: need help on unaligned loads,stores!
Message-ID: <20031013213726.GA25414@linux-mips.org>
References: <200310131927.07171.thomas@horsten.com> <Pine.GSO.4.21.0310132132550.26520-100000@starflower.sonytel.be> <20031013204906.GA21100@linux-mips.org> <200310132215.59826.thomas@horsten.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200310132215.59826.thomas@horsten.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: 3432
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 566
Lines: 14

On Mon, Oct 13, 2003 at 10:15:59PM +0100, Thomas Horsten wrote:

> > That correct.  Unfortunately emulating of these instructions in exception
> > handlers would also be covered by the patents, so rewriting which would
> > be rather easy in all cases I can think of is the way to go ...
> 
> Surely not in Europe (yet), at least?

The patent itself is a hardware patent and those also cover software
implementations by interpretation of US, European and various national
European patent offices.  Otoh the patent will expire in like a year or
two anyway :-)

  Ralf

From exister99@velocitus.net Tue Oct 14 00:15:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Oct 2003 00:15:57 +0100 (BST)
Received: from mx20a.rmci.net ([IPv6:::ffff:205.162.184.37]:48014 "HELO
	mx20a.rmci.net") by linux-mips.org with SMTP id <S8225475AbTJMXPZ>;
	Tue, 14 Oct 2003 00:15:25 +0100
Received: (qmail 30812 invoked from network); 13 Oct 2003 23:15:19 -0000
Received: from webmailb.rmci.net (HELO velocitus.net) (205.162.184.93)
  by mx20.rmci.net with SMTP; 13 Oct 2003 23:15:19 -0000
Received: from 156.153.254.10
        (SquirrelMail authenticated user exister99@velocitus.net)
        by webmail.rmci.net with HTTP;
        Mon, 13 Oct 2003 17:15:19 -0600 (MDT)
Message-ID: <38866.156.153.254.10.1066086919.squirrel@webmail.rmci.net>
Date: Mon, 13 Oct 2003 17:15:19 -0600 (MDT)
Subject: 64 bit kernel in the name of HIGHMEM
From: <exister99@velocitus.net>
To: <ralf@linux-mips.org>
In-Reply-To: <20031009140319.GA17647@linux-mips.org>
References: <5334.156.153.254.2.1065650433.squirrel@webmail.rmci.net>
        <20031009140319.GA17647@linux-mips.org>
X-Priority: 3
Importance: Normal
X-MSMail-Priority: Normal
Cc: <linux-mips@linux-mips.org>
X-Mailer: SquirrelMail (version 1.2.7)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <exister99@velocitus.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: 3433
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: exister99@velocitus.net
Precedence: bulk
X-list: linux-mips
Content-Length: 1929
Lines: 50

Hi Ralf,

Thanks for the prompt response.

> Reminds me of the HP Laserjet code in the kernel.  Anybody still using
> or testing that?

Yes, the code I am working with is basically a snapshot of the kernel
source with /arch/mips/hp-lj etc.

> Anyway, for a 64-bit processor such as the 20Kc I suggest a 64-bit
> kernel. Highmem is a pain and 64-bit is the cure.

To that end I have been trying to build a 64 bit kernel.  I think I am
going about it correctly.  Got ahold of

mips64el-linux-binutils-2.14-3.i386.rpm 
mips64el-linux-boot-gcc-2.95.4-9.i386.rpm

and got cranking.  Currently make is dying with the following output:


[root@l51dhcp252 ljlinux]# make ARCH=mips64 CROSS_COMPILE=mips64el-linux-
. scripts/mkversion > .tmpversion
mips64el-linux-gcc -D__KERNEL__ -I/home/astone/cf_burn_64/ljlinux/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -I/usr/lib/gcc-lib/mips64el-linux/2.95.4/include
-fomit-frame-pointer -Dx_unity_x -I
/home/astone/cf_burn_64/ljlinux/include/asm/gcc -mabi=64 -G 0
-mno-abicalls -fno-pic -Wa,--trap -pipe  -DUTS_MACHINE='"mips64"'
-DKBUILD_BASENAME=version -c -o init/version.o init/version.c
mips64el-linux-gcc -D__KERNEL__ -I/home/astone/cf_burn_64/ljlinux/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -I/usr/lib/gcc-lib/mips64el-linux/2.95.4/include
-fomit-frame-pointer -Dx_unity_x -I
/home/astone/cf_burn_64/ljlinux/include/asm/gcc -mabi=64 -G 0
-mno-abicalls -fno-pic -Wa,--trap -pipe   -DKBUILD_BASENAME=do_mounts -c
-o init/do_mounts.o init/do_mounts.c
cpp0: output pipe has been closed
mips64el-linux-gcc: Internal compiler error: program cc1 got fatal signal 11
make: *** [init/do_mounts.o] Error 1


Initial searches claim this is a bug in the compiler.  Could it be due to
something I am doing wrong?  Any guidance on building a 64 bit kernel
would be greatly appreciated.

Best Regards, Andrew Stone



From alanliu@trident.com.cn Tue Oct 14 02:25:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Oct 2003 02:25:08 +0100 (BST)
Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:4106
	"EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP
	id <S8225471AbTJNBZF>; Tue, 14 Oct 2003 02:25:05 +0100
Received: by TMTMS with Internet Mail Service (5.5.2653.19)
	id <SK19JBP2>; Tue, 14 Oct 2003 09:19:17 +0800
Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F6801AC0D67@TMTMS>
From: "Liu Hongming (Alan)" <alanliu@trident.com.cn>
To: Ralf Baechle <ralf@linux-mips.org>,
	Thomas Horsten <thomas@horsten.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	"Liu Hongming (Alan)" <alanliu@trident.com.cn>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: RE: need help on unaligned loads,stores!
Date: Tue, 14 Oct 2003 09:18:20 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C391F1.0DD4EDB0"
Return-Path: <alanliu@trident.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: 3434
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alanliu@trident.com.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 3320
Lines: 99

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

------_=_NextPart_001_01C391F1.0DD4EDB0
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi All,

I have rewritten the codes,and now it really works.
Our cpu is bought from others,it really doesnt support unaligned access.

Thanks for you all.

Best Regards,
Alan

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Tuesday, October 14, 2003 5:37 AM
To: Thomas Horsten
Cc: Geert Uytterhoeven; Liu Hongming (Alan); Linux/MIPS Development
Subject: Re: need help on unaligned loads,stores!


On Mon, Oct 13, 2003 at 10:15:59PM +0100, Thomas Horsten wrote:

> > That correct.  Unfortunately emulating of these instructions in
exception
> > handlers would also be covered by the patents, so rewriting which would
> > be rather easy in all cases I can think of is the way to go ...
> 
> Surely not in Europe (yet), at least?

The patent itself is a hardware patent and those also cover software
implementations by interpretation of US, European and various national
European patent offices.  Otoh the patent will expire in like a year or
two anyway :-)

  Ralf

------_=_NextPart_001_01C391F1.0DD4EDB0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: need help on unaligned loads,stores!</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi All,</FONT>
</P>

<P><FONT SIZE=2>I have rewritten the codes,and now it really works.</FONT>
<BR><FONT SIZE=2>Our cpu is bought from others,it really doesnt support unaligned access.</FONT>
</P>

<P><FONT SIZE=2>Thanks for you all.</FONT>
</P>

<P><FONT SIZE=2>Best Regards,</FONT>
<BR><FONT SIZE=2>Alan</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Ralf Baechle [<A HREF="mailto:ralf@linux-mips.org">mailto:ralf@linux-mips.org</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, October 14, 2003 5:37 AM</FONT>
<BR><FONT SIZE=2>To: Thomas Horsten</FONT>
<BR><FONT SIZE=2>Cc: Geert Uytterhoeven; Liu Hongming (Alan); Linux/MIPS Development</FONT>
<BR><FONT SIZE=2>Subject: Re: need help on unaligned loads,stores!</FONT>
</P>
<BR>

<P><FONT SIZE=2>On Mon, Oct 13, 2003 at 10:15:59PM +0100, Thomas Horsten wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt; &gt; That correct.&nbsp; Unfortunately emulating of these instructions in exception</FONT>
<BR><FONT SIZE=2>&gt; &gt; handlers would also be covered by the patents, so rewriting which would</FONT>
<BR><FONT SIZE=2>&gt; &gt; be rather easy in all cases I can think of is the way to go ...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Surely not in Europe (yet), at least?</FONT>
</P>

<P><FONT SIZE=2>The patent itself is a hardware patent and those also cover software</FONT>
<BR><FONT SIZE=2>implementations by interpretation of US, European and various national</FONT>
<BR><FONT SIZE=2>European patent offices.&nbsp; Otoh the patent will expire in like a year or</FONT>
<BR><FONT SIZE=2>two anyway :-)</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Ralf</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C391F1.0DD4EDB0--

From Syam-Krishna.Babbellapati@infineon.com Tue Oct 14 06:48:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Oct 2003 06:48:48 +0100 (BST)
Received: from mail5.infineon.com ([IPv6:::ffff:203.126.245.197]:23012 "EHLO
	mail5-i.infineon.com") by linux-mips.org with ESMTP
	id <S8225346AbTJNFsp>; Tue, 14 Oct 2003 06:48:45 +0100
Received: from sinse004.ap.infineon.com (sgpk993a.sin.infineon.com [172.17.65.75])
	by mail5-i.infineon.com (8.11.7p1+Sun/8.11.7) with ESMTP id h9E5miT23181
	for <linux-mips@linux-mips.org>; Tue, 14 Oct 2003 13:48:44 +0800 (SGT)
Received: from blrw502w.blr.infineon.com ([172.29.142.21]) by sinse004.ap.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 46XX073R; Tue, 14 Oct 2003 13:48:41 +0800
Received: by blrw502w.blr.infineon.com with Internet Mail Service (5.5.2653.19)
	id <TVHGBNZ2>; Tue, 14 Oct 2003 11:16:23 +0530
Message-ID: <0C674B14EAEBD61196D900B0D03DB49F010C835E@blrw502w.blr.infineon.com>
From: "Babbellapati Syam Krishna (IFIN DC COM)" 
	<Syam-Krishna.Babbellapati@infineon.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: "sel" field in MTC0 instruction?
Date: Tue, 14 Oct 2003 11:16:20 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C39216.7E8A3B30"
Return-Path: <Syam-Krishna.Babbellapati@infineon.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3435
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Syam-Krishna.Babbellapati@infineon.com
Precedence: bulk
X-list: linux-mips
Content-Length: 8410
Lines: 171

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

------_=_NextPart_001_01C39216.7E8A3B30
Content-Type: text/plain

Hi there,
 
I am running linux on a MIPS64 5kc processor. From the Data Sheet and
Software User's manual, I could see that we can access the various MIPS
Performance Counters (Coprocessor 0, Register 25) by using the "sel" field
of the MTC0 or MFC0 registers.
 
Format:   MTC0 rt, rd

        (OR) MTC0 rt, rd, sel

Based on the second format, I have written a new assembly languauge routine:

 
#define write_32bit_cp0_performance_register(register,value) \
__asm__ __volatile__( \
"mtc0\t%0,"STR(register)",sel\n\t" \
"nop" \
: : "r" (value));
 
"sel" in the above assembly instruction is a value of either 0, 1, 2 or 3
based on the register which we would like to write.
"sel" in the above code is newly introduced by us and if there is no sel
then the code compiles properly but I guess we would always be accessing one
register only in that case.
(A similar routine is written using "mfc0" also for reading the values
back.)
 
But this code results in a compilation error:
{standard input}: Assembler messages:
{standard input}:41: Error: illegal operands `mtc0 $3,$25,0'
{standard input}:45: Error: illegal operands `mfc0 $5,$25,1'
where $25 is CP0_PERFORMANCE register.
 
The command used for compilation is:
mipsel-linux-gcc -c -I /home/syam/linux-2.4.20with095LTT/include/ -Wall -O2
-fomit-frame-pointer -fno-common -finline-limit=5000 -G 0 -mno-abicalls
-fno-pic -mcpu=r4600 -mips2 -pipe -DMODULE -mlong-calls tempCache.c
 
 
Could someone help me in making me understand what is wrong here? Is it a
problem with the syntax of the arguments or is there an assembler support
which I am lacking for such an instruction?
 
Any kind of pointers would be of help.
 
Thank you,
Syam

----------------------------------------------------------------------------
------------- 
*Disclaimer*
"This e-mail and any attachments are confidential and may contain trade
secrets or privileged or undisclosed information. They may also be subject
to copyright protection. Please do not copy, distribute or forward this
email to anyone unless authorized. If you are not a named addressee, you
must not use, disclose, retain or reproduce all or any part of the
information contained in this e-mail or any attachments. If you have
received this email by mistake please notify the sender immediately by
return email and destroy/delete all copies of the email." 

 

------_=_NextPart_001_01C39216.7E8A3B30
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 5.50.4926.2500" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=955195704-14102003><FONT face=Arial size=2>Hi 
there,</FONT></SPAN></DIV>
<DIV><SPAN class=955195704-14102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=955195704-14102003><FONT face=Arial size=2>I am running linux 
on a MIPS64 5kc processor. From the Data Sheet and Software User's manual, I 
could see that we can access the various MIPS Performance Counters (Coprocessor 
0, Register 25) by using the "sel" field of the MTC0 or MFC0 
registers.</FONT></SPAN></DIV>
<DIV><SPAN class=955195704-14102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=955195704-14102003>
<P><FONT size=2><STRONG>Format:&nbsp;</STRONG><SPAN 
class=955195704-14102003><FONT face=Courier>&nbsp;&nbsp;</FONT></SPAN><FONT 
face=Courier>MTC0 rt, rd</FONT></FONT></P>
<P><FONT face=Courier><FONT size=2><SPAN 
class=955195704-14102003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(OR) 
</SPAN>MTC0 rt, rd, sel</FONT></FONT></P>
<P><FONT color=#0000ff><FONT face=Arial color=#000000 size=2><SPAN 
class=955195704-14102003>Based on the second format, I have written a new 
assembly languauge routine:</SPAN></FONT></P></DIV>
<DIV><FONT face=Arial color=#000000 size=2><SPAN 
class=955195704-14102003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#000000 size=2>#define 
write_32bit_cp0_performance_register(register,value) \</FONT></DIV>
<DIV><FONT face=Arial color=#000000 size=2>__asm__ __volatile__( \</FONT></DIV>
<DIV><FONT face=Arial color=#000000 
size=2>"mtc0\t%0,"STR(register)",</FONT></FONT><FONT face=Arial 
size=2>sel</FONT><FONT color=#0000ff><FONT face=Arial color=#000000 size=2>\n\t" 
\</FONT></DIV>
<DIV><FONT face=Arial color=#000000 size=2>"nop" \</FONT></DIV>
<DIV><FONT face=Arial color=#000000 size=2>: : "r" (value));</FONT></DIV>
<DIV><FONT face=Arial color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV></FONT><FONT face=Arial size=2>"</FONT><FONT face=Arial><FONT 
size=2>sel"&nbsp;<SPAN class=955195704-14102003>in the above assembly 
instruction is&nbsp;</SPAN>a value of either 0, 1, 2 or 3 based on the register 
which we would like to write.</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2>"sel" in the above code is newly introduced by us 
and if there is no sel then the code compiles properly but I guess we would 
always be accessing one register only in&nbsp;<SPAN 
class=955195704-14102003>that </SPAN>case.</FONT></DIV><FONT color=#0000ff>
<DIV><FONT face=Arial color=#000000 size=2>(A similar routine is written using 
"mfc0" also for reading the values back.)</FONT></DIV>
<DIV><FONT face=Arial color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#000000 size=2>But this code results in a 
compilation error:</FONT></DIV></FONT><FONT face="Courier New" size=2>
<DIV><FONT face=Arial>{standard input}: Assembler messages:</FONT></DIV>
<DIV><FONT face=Arial>{standard input}:41: Error: illegal operands `mtc0 
$3,$25,0'</FONT></DIV>
<DIV><FONT face=Arial>{standard input}:45: Error: illegal operands `mfc0 
$5,$25,1'</FONT></DIV></FONT><FONT color=#0000ff>
<DIV><FONT face=Arial><FONT color=#000000><FONT size=2><SPAN 
class=955195704-14102003>w</SPAN>here $25 is CP0_PERFORMANCE 
register.</FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#000000 size=2>The command used for compilation 
is:</FONT></DIV></FONT><FONT face=Arial size=2>
<DIV>mipsel-linux-gcc -c -I /home/syam/linux-2.4.20with095LTT/include/ -Wall -O2 
-fomit-frame-pointer -fno-common -finline-limit=5000 -G 0 -mno-abicalls -fno-pic 
-mcpu=r4600 -mips2 -pipe -DMODULE -mlong-calls tempCache.c</DIV></FONT></SPAN>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=955195704-14102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=955195704-14102003><FONT face=Arial size=2>Could someone help 
me in making me understand what is wrong here? Is it a problem with the syntax 
of the arguments or is there an assembler support which I am lacking for such an 
instruction?</FONT></SPAN></DIV>
<DIV><SPAN class=955195704-14102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=955195704-14102003><FONT face=Arial size=2>Any kind of pointers 
would be of help.</FONT></SPAN></DIV>
<DIV><SPAN class=955195704-14102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=955195704-14102003><FONT face=Arial size=2>Thank 
you,</FONT></SPAN></DIV>
<DIV><SPAN class=955195704-14102003><FONT face=Arial 
size=2>Syam</FONT></SPAN></DIV><!-- Converted from text/rtf format -->
<P><SPAN lang=en-us><FONT face="Comic Sans MS" 
size=2>-----------------------------------------------------------------------------------------</FONT><FONT 
face="Times New Roman"> </FONT></SPAN><BR><SPAN lang=en-us><FONT 
face="Comic Sans MS" color=#0000ff size=1>*Disclaimer*<BR>"This e-mail and any 
attachments are confidential and may contain trade secrets or privileged or 
undisclosed information. They may also be subject to copyright protection. 
Please do not copy, distribute or forward this email to anyone unless 
authorized. If you are not a named addressee, you must not use, disclose, retain 
or reproduce all or any part of the information contained in this e-mail or any 
attachments. If you have received this email by mistake please notify the sender 
immediately by return email and destroy/delete all copies of the email." 
</FONT></SPAN></P>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C39216.7E8A3B30--

From ralf@linux-mips.org Tue Oct 14 08:13:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Oct 2003 08:13:32 +0100 (BST)
Received: from p508B65AB.dip.t-dialin.net ([IPv6:::ffff:80.139.101.171]:7616
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225346AbTJNHN3>; Tue, 14 Oct 2003 08:13:29 +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 h9E7DONK006103;
	Tue, 14 Oct 2003 09:13:24 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9E7DN7U006102;
	Tue, 14 Oct 2003 09:13:23 +0200
Date: Tue, 14 Oct 2003 09:13:23 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Babbellapati Syam Krishna (IFIN DC COM)" 
	<Syam-Krishna.Babbellapati@infineon.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: "sel" field in MTC0 instruction?
Message-ID: <20031014071323.GB5046@linux-mips.org>
References: <0C674B14EAEBD61196D900B0D03DB49F010C835E@blrw502w.blr.infineon.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0C674B14EAEBD61196D900B0D03DB49F010C835E@blrw502w.blr.infineon.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: 3436
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2217
Lines: 50

On Tue, Oct 14, 2003 at 11:16:20AM +0530, Babbellapati Syam Krishna (IFIN DC COM) wrote:

> #define write_32bit_cp0_performance_register(register,value) \
> __asm__ __volatile__( \
> "mtc0\t%0,"STR(register)",sel\n\t" \
> "nop" \
> : : "r" (value));

Which seems to be dervied from an old function which was eleminated months
ago.  Checkout a current mipsregs.h - which also accesses register with
a non-zero selector value.

> "sel" in the above assembly instruction is a value of either 0, 1, 2 or 3
> based on the register which we would like to write.
> "sel" in the above code is newly introduced by us and if there is no sel
> then the code compiles properly but I guess we would always be accessing one
> register only in that case.
> (A similar routine is written using "mfc0" also for reading the values
> back.)
>  
> But this code results in a compilation error:
> {standard input}: Assembler messages:
> {standard input}:41: Error: illegal operands `mtc0 $3,$25,0'
> {standard input}:45: Error: illegal operands `mfc0 $5,$25,1'
> where $25 is CP0_PERFORMANCE register.
>  
> The command used for compilation is:
> mipsel-linux-gcc -c -I /home/syam/linux-2.4.20with095LTT/include/ -Wall -O2
> -fomit-frame-pointer -fno-common -finline-limit=5000 -G 0 -mno-abicalls
> -fno-pic -mcpu=r4600 -mips2 -pipe -DMODULE -mlong-calls tempCache.c

The mtc/mfc syntax is MIP32, didn't exist in MIPS III.

> *Disclaimer*
> "This e-mail and any attachments are confidential and may contain trade
> secrets or privileged or undisclosed information. They may also be subject
> to copyright protection. Please do not copy, distribute or forward this
> email to anyone unless authorized. If you are not a named addressee, you
> must not use, disclose, retain or reproduce all or any part of the
> information contained in this e-mail or any attachments. If you have
> received this email by mistake please notify the sender immediately by
> return email and destroy/delete all copies of the email." 

Please print a hardcopy of this my answer, then eat it up because it's
confidential ;-)

Any and all email sent to this list will be archived and published
immediately no matter what bullshit disclaimer is attached.

  Ralf

From macro@ds2.pg.gda.pl Tue Oct 14 10:28:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Oct 2003 10:28:11 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:48343 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225369AbTJNJ2J>; Tue, 14 Oct 2003 10:28:09 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA16993;
	Tue, 14 Oct 2003 11:28:01 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 14 Oct 2003 11:28:00 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Kip Walker <kwalker@broadcom.com>
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <3F8700ED.4AE74ECE@broadcom.com>
Message-ID: <Pine.GSO.3.96.1031014112646.16937A-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: 3437
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 434
Lines: 14

On Fri, 10 Oct 2003, Kip Walker wrote:

> This doesn't compile.  Remove the commas.
> 
> Of course, "vt_check" doesn't build anymore either - I'm trying to fix
> that one.

 I can see you have dealt with the problems since.  Thanks.

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


From Syam-Krishna.Babbellapati@infineon.com Tue Oct 14 11:21:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Oct 2003 11:21:19 +0100 (BST)
Received: from mail5.infineon.com ([IPv6:::ffff:203.126.245.197]:18828 "EHLO
	mail5-i.infineon.com") by linux-mips.org with ESMTP
	id <S8225473AbTJNKVR>; Tue, 14 Oct 2003 11:21:17 +0100
Received: from sinse004.ap.infineon.com (sgpk993a.sin.infineon.com [172.17.65.75])
	by mail5-i.infineon.com (8.11.7p1+Sun/8.11.7) with ESMTP id h9EALFT07388;
	Tue, 14 Oct 2003 18:21:15 +0800 (SGT)
Received: from blrw502w.blr.infineon.com ([172.29.142.21]) by sinse004.ap.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 46XYACK8; Tue, 14 Oct 2003 18:21:12 +0800
Received: by blrw502w.blr.infineon.com with Internet Mail Service (5.5.2653.19)
	id <TVHGB3GX>; Tue, 14 Oct 2003 15:48:53 +0530
Message-ID: <0C674B14EAEBD61196D900B0D03DB49F010C8361@blrw502w.blr.infineon.com>
From: "Babbellapati Syam Krishna (IFIN DC COM)" 
	<Syam-Krishna.Babbellapati@infineon.com>
To: "'Ralf Baechle'" <ralf@linux-mips.org>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: RE: "sel" field in MTC0 instruction?
Date: Tue, 14 Oct 2003 15:48:52 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Return-Path: <Syam-Krishna.Babbellapati@infineon.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3439
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Syam-Krishna.Babbellapati@infineon.com
Precedence: bulk
X-list: linux-mips
Content-Length: 392
Lines: 15

>> #define write_32bit_cp0_performance_register(register,value) 
>\ __asm__ 
>> __volatile__( \ "mtc0\t%0,"STR(register)",sel\n\t" \
>> "nop" \
>> : : "r" (value));
>
>Which seems to be dervied from an old function which was 
>eleminated months ago.  Checkout a current mipsregs.h - which 
>also accesses register with a non-zero selector value.
>

Thanks Ralf. I could get out of it.

Syam


From Syam-Krishna.Babbellapati@infineon.com Tue Oct 14 11:40:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Oct 2003 11:40:19 +0100 (BST)
Received: from mail5.infineon.com ([IPv6:::ffff:203.126.245.197]:6799 "EHLO
	mail5-i.infineon.com") by linux-mips.org with ESMTP
	id <S8225467AbTJNKkJ>; Tue, 14 Oct 2003 11:40:09 +0100
Received: from sinse004.ap.infineon.com (sgpk993a.sin.infineon.com [172.17.65.75])
	by mail5-i.infineon.com (8.11.7p1+Sun/8.11.7) with ESMTP id h9EAe7T08310
	for <linux-mips@linux-mips.org>; Tue, 14 Oct 2003 18:40:07 +0800 (SGT)
Received: from blrw502w.blr.infineon.com ([172.29.142.21]) by sinse004.ap.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 46XYACW7; Tue, 14 Oct 2003 18:40:05 +0800
Received: by blrw502w.blr.infineon.com with Internet Mail Service (5.5.2653.19)
	id <TVHGB3HQ>; Tue, 14 Oct 2003 16:07:45 +0530
Message-ID: <0C674B14EAEBD61196D900B0D03DB49F010C8362@blrw502w.blr.infineon.com>
From: "Babbellapati Syam Krishna (IFIN DC COM)" 
	<Syam-Krishna.Babbellapati@infineon.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: performance measurement patches?
Date: Tue, 14 Oct 2003 16:07:45 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3923F.34306E50"
Return-Path: <Syam-Krishna.Babbellapati@infineon.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3440
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Syam-Krishna.Babbellapati@infineon.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1527
Lines: 36

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

------_=_NextPart_001_01C3923F.34306E50
Content-Type: text/plain

Could some one tell me if there are any patches or utilities available to
make use of the performance counters in the MIPS 5K processors? I mean -
some kind of software either as an application or as a kernel module for
Linux (if not then on any other OS) which gives us a facility to show the
various performance counters under a given test.
 
Syam

------_=_NextPart_001_01C3923F.34306E50
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 5.50.4926.2500" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=299152110-14102003><FONT face=Arial size=2>Could some one tell 
me&nbsp;if there are any&nbsp;patches or utilities available to make use of the 
performance counters in the MIPS 5K processors? I mean - some kind of software 
either as an application or as a kernel module for Linux (if not then on any 
other OS) which gives us a facility to show the various performance counters 
under a given test.</FONT></SPAN></DIV>
<DIV><SPAN class=299152110-14102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=299152110-14102003><FONT face=Arial 
size=2>Syam</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C3923F.34306E50--

From ralf@linux-mips.org Tue Oct 14 14:29:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Oct 2003 14:29:30 +0100 (BST)
Received: from p508B780A.dip.t-dialin.net ([IPv6:::ffff:80.139.120.10]:58837
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225479AbTJNN3W>; Tue, 14 Oct 2003 14:29:22 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h9EDSrNK013633;
	Tue, 14 Oct 2003 15:28:53 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9EDSong013632;
	Tue, 14 Oct 2003 15:28:50 +0200
Date: Tue, 14 Oct 2003 15:28:50 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20031014132850.GA12938@linux-mips.org>
References: <20031013142637Z8225419-1272+7775@linux-mips.org> <Pine.GSO.3.96.1031014114452.17028B-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.1031014114452.17028B-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: 3441
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1670
Lines: 35

On Tue, Oct 14, 2003 at 11:47:59AM +0200, Maciej W. Rozycki wrote:

> > Log message:
> > 	Config bits of support for TLB page sizes other than 4k.  So not
> > 	functional yet but this is a fairly large project and everybody should
> > 	finally get rid of the assumption that PAGE_SIZE is always 4k.
> 
>  I've already thought we might unconditionally switch to a larger page
> size, e.g. 16kB, for the 64-bit kernel -- I suppose everything that
> supports 64-bit operation also supports larger page sizes, doesn't it?

True.  At 16k pagesize we can also start harvesting other advantages, for
example we'd then know that cpu_has_dc_aliases is never true which will
make the compiler simply throw away large parts of the cache code.

As the result of living in an alias-free universe we could use the nice
recursive page fault technique from very old Linux kernels again,
something that allowed blindigly fast TLB refill handlers.

An additional bonus is the increased coverage of a pagetables with 16k
page size.  A 16k page has space for 2048 pointers.  So in case of a
two level pagetable tree that makes the total capacity 16k*2k*2k = 64GB.
So that means one level of the pagetable tree less than we currently
have, yet enough capacity for everything but the largest jobs.

Still want more?  A 3 level tree would then cover 128TB of virtual
address space already exceedin the hardware limits of all processors but
the R8000.

64k pagesize stretches the limits even further.   Here a two level
pagetable tree would cover 4TB, 3-level could cover 32PB exceeding
the capacity of every MIPS processor ever made - and probably sufficient
for the coming decade :-)

  Ralf

From drow@crack.them.org Tue Oct 14 17:43:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Oct 2003 17:43:51 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:6054 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225488AbTJNQnk>;
	Tue, 14 Oct 2003 17:43:40 +0100
Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian))
	id 1A9SGh-0003Dl-NA; Tue, 14 Oct 2003 12:43:31 -0400
Date: Tue, 14 Oct 2003 12:43:31 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: 2.6 crashes testcase
Message-ID: <20031014164331.GA12254@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3442
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 686
Lines: 18

Hey Ralf,

Here's a tiny root filesystem and README that show the problem, on the
chance that the different glibc version or such is triggering it.  Follow
the instructions, segfaults guaranteed or no money back.  If you want to
give me a copy of all the same libraries/files from your older working 2.6
root, I'll try them.  Oh, this is mipsel, btw - I hadn't thought about that,
the Indy is big-endian isn't it?  I don't think I have BE firmware for this
board.

root filesystem:
  http://www.false.org/~drow/target-with-crashes.tar.gz
.config:
  http://www.false.org/~drow/config-mips-2.6

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From AdeelM@avaznet.com Wed Oct 15 13:11:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Oct 2003 13:12:01 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:14494
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225475AbTJOML5>; Wed, 15 Oct 2003 13:11:57 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <4RT7BKSL>; Wed, 15 Oct 2003 17:04:01 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264F179@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Subject: How to mount root file system on Flash Device
Date: Wed, 15 Oct 2003 17:03:57 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C39314.6BCC0660"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3443
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2348
Lines: 53

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

------_=_NextPart_001_01C39314.6BCC0660
Content-Type: text/plain;
	charset="iso-8859-1"

Presently I am using Buildroot Toolchain to compile the Linux Kernel and
create the Root File System.The Buildroot generates an EXT2 file system
Image by using a program called "genext2fs". The created file system is then
merged with the Kernel image for downloading to SDRAM where it allocates a
portion of memory for file-access and storage by setting-up a Ramdisk
device.
 
We want to mount the file system on a non-volatile memory such as Flash
Memory. What changes do we need to make in the BuildRoot Toolchain to
generate the flash-mountable root file system.
 
Regards,
ADEEL MALIK,


------_=_NextPart_001_01C39314.6BCC0660
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial" hb_focus_attach="true">
<DIV>
<DIV><SPAN class=870253309-15102003><FONT size=2>Presently&nbsp;<SPAN 
class=650040112-15102003>I am</SPAN>&nbsp;using <STRONG>Buildroot 
Toolchain</STRONG> to compile the Linux Kernel and create the Root File 
System.The <STRONG>Buildroot </STRONG>generates an EXT2 file system Image by 
using a program called <STRONG>"genext2fs". </STRONG>The created file system is 
then merged with the Kernel image for downloading to SDRAM where it allocates a 
portion of memory for file-access and storage by setting-up a Ramdisk 
device.</FONT></SPAN></DIV>
<DIV><SPAN class=870253309-15102003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=870253309-15102003><FONT size=2>We want to mount the file 
system on a non-volatile memory such as Flash Memory. What changes do we need to 
make in the BuildRoot Toolchain to generate the flash-mountable root file 
system.</FONT></SPAN></DIV></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=650040112-15102003><FONT size=2>Regards,</FONT></SPAN></DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM>ADEEL MALIK,</EM></FONT></DIV>
<P></P></BODY></HTML>

------_=_NextPart_001_01C39314.6BCC0660--

From macro@ds2.pg.gda.pl Wed Oct 15 15:23:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Oct 2003 15:23:38 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:42650 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225482AbTJOOX1>; Wed, 15 Oct 2003 15:23:27 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA10659;
	Wed, 15 Oct 2003 16:23:06 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 15 Oct 2003 16:23:06 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20031014132850.GA12938@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1031015161040.9299D-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: 3444
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1353
Lines: 30

On Tue, 14 Oct 2003, Ralf Baechle wrote:

> Still want more?  A 3 level tree would then cover 128TB of virtual
> address space already exceedin the hardware limits of all processors but
> the R8000.

 Well, the MIPS64 ISA spec allows up to 8EB of user memory to be supported
by an implementation, IIRC; probably nothing supports that much yet,
though. ;-)  BTW, is an R8000 spec available online anywhere?

> 64k pagesize stretches the limits even further.   Here a two level
> pagetable tree would cover 4TB, 3-level could cover 32PB exceeding
> the capacity of every MIPS processor ever made - and probably sufficient
> for the coming decade :-)

 Further increasing of the page size should result in better performance
due to fewer TLB misses and reduce the memory footprint of page tables,
but the drawback is more memory is wasted for maps.  Whether the end
result is a gain or a loss depends on the actual application of a system,
so I guess we should either leave the size configurable (with a sane
default for those who might have troubles judging what would suit them
best) or only decide on a given size after lots of benchmarking.

  Maciej

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


From ralf@linux-mips.org Wed Oct 15 15:59:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Oct 2003 16:00:03 +0100 (BST)
Received: from p508B51CB.dip.t-dialin.net ([IPv6:::ffff:80.139.81.203]:63422
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225503AbTJOO7v>; Wed, 15 Oct 2003 15:59: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 h9FExmNK030569;
	Wed, 15 Oct 2003 16:59:48 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9FExmLt030568;
	Wed, 15 Oct 2003 16:59:48 +0200
Date: Wed, 15 Oct 2003 16:59:48 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: MIPS addressing limits, Was: Re: CVS Update@-mips.org: linux
Message-ID: <20031015145948.GB23514@linux-mips.org>
References: <20031014132850.GA12938@linux-mips.org> <Pine.GSO.3.96.1031015161040.9299D-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.1031015161040.9299D-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: 3445
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1754
Lines: 36

On Wed, Oct 15, 2003 at 04:23:06PM +0200, Maciej W. Rozycki wrote:

> > Still want more?  A 3 level tree would then cover 128TB of virtual
> > address space already exceedin the hardware limits of all processors but
> > the R8000.
> 
>  Well, the MIPS64 ISA spec allows up to 8EB of user memory to be supported
> by an implementation, IIRC; probably nothing supports that much yet,
> though. ;-)  BTW, is an R8000 spec available online anywhere?

There used to be a few papers published by SGI online and various other
bits of information I found through google.

(I happen to have a paper copy of the R8000 manual but since the responsible
people still haven't informed me if I can legally use it, this book is
closed and will stay closed until this happens - if ever ...  Pitty, I
still receive mails from various R8000 users ...)

> > 64k pagesize stretches the limits even further.   Here a two level
> > pagetable tree would cover 4TB, 3-level could cover 32PB exceeding
> > the capacity of every MIPS processor ever made - and probably sufficient
> > for the coming decade :-)
> 
>  Further increasing of the page size should result in better performance
> due to fewer TLB misses and reduce the memory footprint of page tables,
> but the drawback is more memory is wasted for maps.  Whether the end
> result is a gain or a loss depends on the actual application of a system,
> so I guess we should either leave the size configurable (with a sane
> default for those who might have troubles judging what would suit them
> best) or only decide on a given size after lots of benchmarking.

Unless somebody yells I almost feel like ditching 3-level pagetable
support; 2-levels with a decent pagesize should suffice for a few years
to come ...

  Ralf

From yuasa@hh.iij4u.or.jp Wed Oct 15 17:05:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Oct 2003 17:06:24 +0100 (BST)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:16340 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225509AbTJOQFw>;
	Wed, 15 Oct 2003 17:05:52 +0100
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id BAA22318;
	Thu, 16 Oct 2003 01:05:37 +0900 (JST)
Received: 4UMDO00 id h9FG5aL14659; Thu, 16 Oct 2003 01:05:36 +0900 (JST)
Received: 4UMRO00 id h9FG5Z103333; Thu, 16 Oct 2003 01:05:35 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Thu, 16 Oct 2003 01:05:33 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: [patch] VR4133
Message-Id: <20031016010533.5a772fef.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20031013020207.5887e42e.yuasa@hh.iij4u.or.jp>
References: <20031008003402.23a326cb.yuasa@hh.iij4u.or.jp>
	<20031012151517.GA20647@linux-mips.org>
	<20031013020207.5887e42e.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart=_Thu__16_Oct_2003_01_05_33_+0900_6o7qDT6gjEp7K/_d"
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: 3446
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 46284
Lines: 1601

This is a multi-part message in MIME format.

--Multipart=_Thu__16_Oct_2003_01_05_33_+0900_6o7qDT6gjEp7K/_d
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I updated the patch about part of GIU for VR4133.
Please apply them to CVS tree.

Yoichi

On Mon, 13 Oct 2003 02:02:07 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hello Ralf,
> 
> On Sun, 12 Oct 2003 17:15:17 +0200
> Ralf Baechle <ralf@linux-mips.org> wrote:
> 
> > On Wed, Oct 08, 2003 at 12:34:02AM +0900, Yoichi Yuasa wrote:
> > 
> > > I made patches for NEC VR4133.
> > > These patches add support of new CPU of NEC.
> > > 
> > > Please apply this patch to CVS tree.
> > 
> > Please keep the 32-bit and 64-bit files in sync - even if you're not
> > using both.  Having them diverse is a huge pain.
> 
> OK, I updated these patches.
> 
> Please apply them to CVS.
> 
> Yoichi
> 
> 

--Multipart=_Thu__16_Oct_2003_01_05_33_+0900_6o7qDT6gjEp7K/_d
Content-Type: text/plain;
 name="vr4133-v24-2.diff"
Content-Disposition: attachment;
 filename="vr4133-v24-2.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux.orig/arch/mips/kernel/cpu-probe.c	Tue Oct 14 11:58:38 2003
+++ linux/arch/mips/kernel/cpu-probe.c	Wed Oct 15 23:54:19 2003
@@ -220,8 +220,11 @@
 			else
 				c->cputype = CPU_VR4181A;
 			break;
-		case PRID_REV_VR4131:
-			c->cputype = CPU_VR4131;
+		case PRID_REV_VR4130:
+			if ((c->processor_id & 0xf) < 0x4)
+				c->cputype = CPU_VR4131;
+			else
+				c->cputype = CPU_VR4133;
 			break;
 		default:
 			printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/proc.c linux/arch/mips/kernel/proc.c
--- linux.orig/arch/mips/kernel/proc.c	Tue Oct 14 11:58:38 2003
+++ linux/arch/mips/kernel/proc.c	Wed Oct 15 23:50:46 2003
@@ -68,6 +68,7 @@
 	[CPU_VR4121]	"NEC VR4121",
 	[CPU_VR4122]	"NEC VR4122",
 	[CPU_VR4131]	"NEC VR4131",
+	[CPU_VR4133]	"NEC VR4133",
 	[CPU_VR4181]	"NEC VR4181",
 	[CPU_VR4181A]	"NEC VR4181A",
 	[CPU_SR71000]	"Sandcraft SR71000"
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux.orig/arch/mips/mm/c-r4k.c	Tue Oct 14 11:58:39 2003
+++ linux/arch/mips/mm/c-r4k.c	Wed Oct 15 23:50:46 2003
@@ -833,6 +833,8 @@
 		c->dcache.waybit = 0;
 		break;
 
+	case CPU_VR4133:
+		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux.orig/arch/mips/vr41xx/casio-e55/setup.c	Wed Jul 30 09:35:37 2003
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Wed Oct 15 23:50:46 2003
@@ -59,7 +59,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux.orig/arch/mips/vr41xx/common/bcu.c	Sat Aug 30 01:32:54 2003
+++ linux/arch/mips/vr41xx/common/bcu.c	Wed Oct 15 23:50:46 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - Calculate mips_hpt_frequency properly on VR4131.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -52,8 +53,8 @@
 
 #define VR4111_CLKSPEEDREG	KSEG1ADDR(0x0b000014)
 #define VR4122_CLKSPEEDREG	KSEG1ADDR(0x0f000014)
-#define VR4131_CLKSPEEDREG	VR4122_CLKSPEEDREG
  #define CLKSP(x)		((x) & 0x001f)
+ #define CLKSP_VR4133(x)	((x) & 0x0007)
 
  #define DIV2B			0x8000
  #define DIV3B			0x4000
@@ -72,8 +73,9 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121: return readw(VR4111_CLKSPEEDREG);
-	case CPU_VR4122: return readw(VR4122_CLKSPEEDREG);
-	case CPU_VR4131: return readw(VR4131_CLKSPEEDREG);
+	case CPU_VR4122:
+	case CPU_VR4131:
+	case CPU_VR4133: return readw(VR4122_CLKSPEEDREG);
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
@@ -90,19 +92,43 @@
 	case CPU_VR4111:
 	case CPU_VR4121:
 		pclock = 18432000 * 64;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4122:
 		pclock = 18432000 * 98;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4131:
 		pclock = 18432000 * 108;
+		pclock /= CLKSP(clkspeed);
+		break;
+	case CPU_VR4133:
+		switch (CLKSP_VR4133(clkspeed)) {
+		case 0:
+			pclock = 133000000;
+			break;
+		case 1:
+			pclock = 149000000;
+			break;
+		case 2:
+			pclock = 165900000;
+			break;
+		case 3:
+			pclock = 199100000;
+			break;
+		case 4:
+			pclock = 265900000;
+			break;
+		default:
+			printk(KERN_INFO "Unknown PClock speed for NEC VR4133\n");
+			break;
+		}
 		break;
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
 	}
 
-	pclock /= CLKSP(clkspeed);
 	printk(KERN_INFO "PClock: %ldHz\n", pclock);
 
 	return pclock;
@@ -135,6 +161,7 @@
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_vtclock = pclock / VTDIVMODE(clkspeed);
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
@@ -165,6 +192,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		tclock = vtclock / TDIVMODE(clkspeed);
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux.orig/arch/mips/vr41xx/common/cmu.c	Mon Apr  7 09:17:06 2003
+++ linux/arch/mips/vr41xx/common/cmu.c	Wed Oct 15 23:50:46 2003
@@ -33,38 +33,174 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
 #include <asm/io.h>
+#include <asm/vr41xx/vr41xx.h>
 
 #define VR4111_CMUCLKMSK	KSEG1ADDR(0x0b000060)
 #define VR4122_CMUCLKMSK	KSEG1ADDR(0x0f000060)
+ #define MSKPIU			0x0001
+ #define MSKSIU			0x0002
+ #define MSKAIU			0x0004
+ #define MSKKIU			0x0008
+ #define MSKFIR			0x0010
+ #define MSKDSIU		0x0820
+ #define MSKCSI			0x0040
+ #define MSKPCIU		0x0080
+ #define MSKSSIU		0x0100
+ #define MSKSHSP		0x0200
+ #define MSKFFIR		0x0400
+ #define MSKSCSI		0x1000
+ #define MSKPPCIU		0x2000
+#define VR4133_CMUCLKMSK2	KSEG1ADDR(0x0f000064)
+ #define MSKCEU			0x0001
+ #define MSKMAC0		0x0002
+ #define MSKMAC1		0x0004
 
 static u32 vr41xx_cmu_base;
-static u16 cmuclkmsk;
+static u16 cmuclkmsk, cmuclkmsk2;
 
-#define write_cmu(mask)	writew((mask), vr41xx_cmu_base)
+#define read_cmuclkmsk()	readw(vr41xx_cmu_base)
+#define read_cmuclkmsk2()	readw(VR4133_CMUCLKMSK2)
+#define write_cmuclkmsk()	writew(cmuclkmsk, vr41xx_cmu_base)
+#define write_cmuclkmsk2()	writew(cmuclkmsk2, VR4133_CMUCLKMSK2)
 
-void vr41xx_clock_supply(u16 mask)
+void vr41xx_clock_supply(unsigned int clock)
 {
-	cmuclkmsk |= mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk |= MSKPIU;
+		break;
+	case SIU_CLOCK:
+		cmuclkmsk |= MSKSIU | MSKSSIU;
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk |= MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk |= MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk |= MSKFIR | MSKFFIR;
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121)
+			cmuclkmsk |= MSKDSIU;
+		else
+			cmuclkmsk |= MSKSIU | MSKDSIU;
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk |= MSKCSI | MSKSCSI;
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk |= MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk |= MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk |= MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 |= MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 |= MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 |= MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void vr41xx_clock_mask(u16 mask)
+void vr41xx_clock_mask(unsigned int clock)
 {
-	cmuclkmsk &= ~mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk &= ~MSKPIU;
+		break;
+	case SIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		} else {
+			if (cmuclkmsk & MSKDSIU)
+				cmuclkmsk &= ~MSKSSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		}
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk &= ~MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk &= ~MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk &= ~(MSKFIR | MSKFFIR);
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~MSKDSIU;
+		} else {
+			if (cmuclkmsk & MSKSIU)
+				cmuclkmsk &= ~MSKDSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKDSIU);
+		}
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk &= ~(MSKCSI | MSKSCSI);
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk &= ~MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk &= ~MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk &= ~MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 &= ~MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void __init vr41xx_cmu_init(u16 mask)
+void __init vr41xx_cmu_init(void)
 {
 	switch (current_cpu_data.cputype) {
         case CPU_VR4111:
@@ -75,10 +211,14 @@
         case CPU_VR4131:
                 vr41xx_cmu_base = VR4122_CMUCLKMSK;
                 break;
+        case CPU_VR4133:
+                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+		cmuclkmsk2 = read_cmuclkmsk2();
+                break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
 		break;
         }
 
-	cmuclkmsk = mask;
+	cmuclkmsk = read_cmuclkmsk();
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux.orig/arch/mips/vr41xx/common/giu.c	Wed Apr 16 21:59:34 2003
+++ linux/arch/mips/vr41xx/common/giu.c	Thu Oct 16 00:17:21 2003
@@ -34,6 +34,9 @@
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
  *  - New creation, NEC VR4111, VR4121, VR4122 and VR4131 are supported.
+ *
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -61,6 +64,10 @@
 #define GIUINTALSELH	0x16
 #define GIUINTHTSELL	0x18
 #define GIUINTHTSELH	0x1a
+#define GIUFEDGEINHL	0x20
+#define GIUFEDGEINHH	0x22
+#define GIUREDGEINHL	0x24
+#define GIUREDGEINHH	0x26
 
 u32 vr41xx_giu_base = 0;
 
@@ -119,24 +126,56 @@
 
 	if (pin < 16) {
 		mask = (u16)1 << pin;
-		if (trigger == TRIGGER_EDGE) {
+		if (trigger != TRIGGER_LEVEL) {
         		set_giuint(GIUINTTYPL, mask);
 			if (hold == SIGNAL_HOLD)
 				set_giuint(GIUINTHTSELL, mask);
 			else
 				clear_giuint(GIUINTHTSELL, mask);
+			if (current_cpu_data.cputype == CPU_VR4133) {
+				switch (trigger) {
+				case TRIGGER_EDGE_FALLING:
+					set_giuint(GIUFEDGEINHL, mask);
+					clear_giuint(GIUREDGEINHL, mask);
+					break;
+				case TRIGGER_EDGE_RISING:
+					clear_giuint(GIUFEDGEINHL, mask);
+					set_giuint(GIUREDGEINHL, mask);
+					break;
+				default:
+					set_giuint(GIUFEDGEINHL, mask);
+					set_giuint(GIUREDGEINHL, mask);
+					break;
+				}
+			}
 		} else {
 			clear_giuint(GIUINTTYPL, mask);
 			clear_giuint(GIUINTHTSELL, mask);
 		}
 	} else {
 		mask = (u16)1 << (pin - 16);
-		if (trigger == TRIGGER_EDGE) {
+		if (trigger != TRIGGER_LEVEL) {
 			set_giuint(GIUINTTYPH, mask);
 			if (hold == SIGNAL_HOLD)
 				set_giuint(GIUINTHTSELH, mask);
 			else
 				clear_giuint(GIUINTHTSELH, mask);
+			if (current_cpu_data.cputype == CPU_VR4133) {
+				switch (trigger) {
+				case TRIGGER_EDGE_FALLING:
+					set_giuint(GIUFEDGEINHH, mask);
+					clear_giuint(GIUREDGEINHH, mask);
+					break;
+				case TRIGGER_EDGE_RISING:
+					clear_giuint(GIUFEDGEINHH, mask);
+					set_giuint(GIUREDGEINHH, mask);
+					break;
+				default:
+					set_giuint(GIUFEDGEINHH, mask);
+					set_giuint(GIUREDGEINHH, mask);
+					break;
+				}
+			}
 		} else {
 			clear_giuint(GIUINTTYPH, mask);
 			clear_giuint(GIUINTHTSELH, mask);
@@ -246,6 +285,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_giu_base = VR4122_GIUIOSELL;
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux.orig/arch/mips/vr41xx/common/icu.c	Wed Apr 16 21:59:34 2003
+++ linux/arch/mips/vr41xx/common/icu.c	Wed Oct 15 23:50:46 2003
@@ -1,6 +1,6 @@
 /*
  * FILE NAME
- *	arch/mips/vr41xx/vr4122/common/icu.c
+ *	arch/mips/vr41xx/common/icu.c
  *
  * BRIEF MODULE DESCRIPTION
  *	Interrupt Control Unit routines for the NEC VR4122 and VR4131.
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - kgdb support.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -290,6 +291,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_icu1_base = VR4122_SYSINT1REG;
 		vr41xx_icu2_base = VR4122_SYSINT2REG;
 		break;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/pciu.c linux/arch/mips/vr41xx/common/pciu.c
--- linux.orig/arch/mips/vr41xx/common/pciu.c	Mon Apr  7 09:17:06 2003
+++ linux/arch/mips/vr41xx/common/pciu.c	Wed Oct 15 23:50:46 2003
@@ -74,7 +74,7 @@
 		/*
 		 * Type 1 configuration
 		 */
-		if (bus > 255 || PCI_SLOT(dev_fn) > 31 || where > 255)
+		if (PCI_SLOT(dev_fn) > 31 || where > 255)
 			return -1;
 
 		writel((bus << 16)	|
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/pciu.h linux/arch/mips/vr41xx/common/pciu.h
--- linux.orig/arch/mips/vr41xx/common/pciu.h	Mon Jul 15 09:02:56 2002
+++ linux/arch/mips/vr41xx/common/pciu.h	Wed Oct 15 23:50:46 2003
@@ -107,9 +107,6 @@
 
 #define MAX_PCI_CLOCK			33333333
 
-#define PCIU_CLOCK			0x0080
-#define PCI_CLOCK			0x2000
-
 static inline int pciu_read_config_byte(int where, u8 *val)
 {
 	u32 data;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux.orig/arch/mips/vr41xx/common/serial.c	Mon Apr  7 09:17:06 2003
+++ linux/arch/mips/vr41xx/common/serial.c	Wed Oct 15 23:50:46 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -66,7 +67,6 @@
  #define TMICMODE		0x20
 
 #define SIU_BASE_BAUD		1152000
-#define SIU_CLOCK		0x0102
 
 /* VR4122 and VR4131 DSIU Registers */
 #define DSIURB			KSEG1ADDR(0x0f000820)
@@ -75,7 +75,6 @@
  #define INTDSIU		0x0800
 
 #define DSIU_BASE_BAUD		1152000
-#define DSIU_CLOCK		0x0802
 
 int vr41xx_serial_ports = 0;
 
@@ -106,6 +105,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		writew(val, VR4122_SIUIRSEL);
 		break;
 	default:
@@ -133,6 +133,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		s.iomem_base = (unsigned char *)VR4122_SIURB;
 		break;
 	default:
@@ -154,7 +155,8 @@
 	struct serial_struct s;
 
 	if (current_cpu_data.cputype != CPU_VR4122 &&
-	    current_cpu_data.cputype != CPU_VR4131)
+	    current_cpu_data.cputype != CPU_VR4131 &&
+	    current_cpu_data.cputype != CPU_VR4133)
 		return;
 
 	memset(&s, 0, sizeof(s));
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/time.c linux/arch/mips/vr41xx/common/time.c
--- linux.orig/arch/mips/vr41xx/common/time.c	Sat Aug 30 01:32:54 2003
+++ linux/arch/mips/vr41xx/common/time.c	Wed Oct 15 23:50:46 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4100 series are supported.
  *  - Added support for NEC VR4100 series RTC Unit.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4100 series are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/config.h>
 #include <linux/interrupt.h>
@@ -69,6 +70,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
                 vr41xx_rtc_base = VR4122_ETIMELREG;
                 break;
         default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Wed Oct 15 23:50:46 2003
@@ -59,7 +59,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Wed Oct 15 23:50:46 2003
@@ -140,7 +140,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	Wed Oct 15 23:50:46 2003
@@ -102,7 +102,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
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 May 22 06:36:53 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Wed Oct 15 23:50:46 2003
@@ -114,7 +114,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Wed Oct 15 23:50:46 2003
@@ -107,7 +107,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Wed Oct 15 23:50:46 2003
@@ -107,7 +107,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0x0102);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips64/kernel/cpu-probe.c linux/arch/mips64/kernel/cpu-probe.c
--- linux.orig/arch/mips64/kernel/cpu-probe.c	Sun Sep 21 01:21:25 2003
+++ linux/arch/mips64/kernel/cpu-probe.c	Wed Oct 15 23:50:46 2003
@@ -544,8 +544,11 @@
 				else
 					c->cputype = CPU_VR4181A;
 				break;
-			case PRID_REV_VR4131:
-				c->cputype = CPU_VR4131;
+			case PRID_REV_VR4130:
+				if ((c->processor_id & 0xf) < 0x4)
+					c->cputype = CPU_VR4131;
+				else
+					c->cputype = CPU_VR4133;
 				break;
 			default:
 				printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips64/kernel/proc.c linux/arch/mips64/kernel/proc.c
--- linux.orig/arch/mips64/kernel/proc.c	Tue Oct 14 11:58:46 2003
+++ linux/arch/mips64/kernel/proc.c	Wed Oct 15 23:50:47 2003
@@ -68,6 +68,7 @@
 	[CPU_VR4121]	"NEC VR4121",
 	[CPU_VR4122]	"NEC VR4122",
 	[CPU_VR4131]	"NEC VR4131",
+	[CPU_VR4133]	"NEC VR4133",
 	[CPU_VR4181]	"NEC VR4181",
 	[CPU_VR4181A]	"NEC VR4181A",
 	[CPU_SR71000]	"Sandcraft SR71000"
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips64/mm/c-r4k.c linux/arch/mips64/mm/c-r4k.c
--- linux.orig/arch/mips64/mm/c-r4k.c	Tue Oct 14 11:58:47 2003
+++ linux/arch/mips64/mm/c-r4k.c	Wed Oct 15 23:50:47 2003
@@ -833,6 +833,8 @@
 		c->dcache.waybit = 0;
 		break;
 
+	case CPU_VR4133:
+		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/cpu.h linux/include/asm-mips/cpu.h
--- linux.orig/include/asm-mips/cpu.h	Tue Oct 14 11:58:58 2003
+++ linux/include/asm-mips/cpu.h	Wed Oct 15 23:52:08 2003
@@ -100,7 +100,7 @@
 #define PRID_REV_VR4121		0x0060
 #define PRID_REV_VR4122		0x0070
 #define PRID_REV_VR4181A	0x0070	/* Same as VR4122 */
-#define PRID_REV_VR4131		0x0080
+#define PRID_REV_VR4130		0x0080
 
 /*
  * FPU implementation/revision register (CP1 control register 0).
@@ -168,7 +168,8 @@
 #define CPU_AU1100		52
 #define CPU_SR71000		53
 #define CPU_RM9000		54
-#define CPU_LAST		54
+#define CPU_VR4133		55
+#define CPU_LAST		55
 
 /*
  * ISA Level encodings
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	Wed Jul 30 09:35:38 2003
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Thu Oct 16 00:32:22 2003
@@ -32,12 +32,15 @@
 #define PRID_VR4181A_REV1_0	0x00000c73
 #define PRID_VR4181A_REV1_1	0x00000c74
 
-/* VR4131 0x00000c80-0x00000c8f */
+/* VR4131 0x00000c80-0x00000c83 */
 #define PRID_VR4131_REV1_2	0x00000c80
 #define PRID_VR4131_REV2_0	0x00000c81
 #define PRID_VR4131_REV2_1	0x00000c82
 #define PRID_VR4131_REV2_2	0x00000c83
 
+/* VR4133 0x00000c84- */
+#define PRID_VR4133		0x00000c84
+
 /*
  * Bus Control Uint
  */
@@ -46,9 +49,25 @@
 /*
  * Clock Mask Unit
  */
-extern void vr41xx_cmu_init(u16 mask);
-extern void vr41xx_clock_supply(u16 mask);
-extern void vr41xx_clock_mask(u16 mask);
+extern void vr41xx_cmu_init(void);
+extern void vr41xx_clock_supply(unsigned int clock);
+extern void vr41xx_clock_mask(unsigned int clock);
+
+enum {
+	PIU_CLOCK,
+	SIU_CLOCK,
+	AIU_CLOCK,
+	KIU_CLOCK,
+	FIR_CLOCK,
+	DSIU_CLOCK,
+	CSI_CLOCK,
+	PCIU_CLOCK,
+	HSP_CLOCK,
+	PCI_CLOCK,
+	CEU_CLOCK,
+	ETHER0_CLOCK,
+	ETHER1_CLOCK
+};
 
 /*
  * Interrupt Control Unit
@@ -110,7 +129,9 @@
 
 enum {
 	TRIGGER_LEVEL,
-	TRIGGER_EDGE
+	TRIGGER_EDGE,
+	TRIGGER_EDGE_FALLING,
+	TRIGGER_EDGE_RISING
 };
 
 enum {
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips64/cpu.h linux/include/asm-mips64/cpu.h
--- linux.orig/include/asm-mips64/cpu.h	Tue Oct 14 11:58:59 2003
+++ linux/include/asm-mips64/cpu.h	Wed Oct 15 23:52:34 2003
@@ -100,7 +100,7 @@
 #define PRID_REV_VR4121		0x0060
 #define PRID_REV_VR4122		0x0070
 #define PRID_REV_VR4181A	0x0070	/* Same as VR4122 */
-#define PRID_REV_VR4131		0x0080
+#define PRID_REV_VR4130		0x0080
 
 /*
  * FPU implementation/revision register (CP1 control register 0).
@@ -168,7 +168,8 @@
 #define CPU_AU1100		52
 #define CPU_SR71000		53
 #define CPU_RM9000		54
-#define CPU_LAST		54
+#define CPU_VR4133		55
+#define CPU_LAST		55
 
 /*
  * ISA Level encodings

--Multipart=_Thu__16_Oct_2003_01_05_33_+0900_6o7qDT6gjEp7K/_d
Content-Type: text/plain;
 name="vr4133-v26-2.diff"
Content-Disposition: attachment;
 filename="vr4133-v26-2.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux.orig/arch/mips/kernel/cpu-probe.c	Tue Oct 14 12:00:55 2003
+++ linux/arch/mips/kernel/cpu-probe.c	Thu Oct 16 00:41:56 2003
@@ -222,8 +222,11 @@
 			else
 				c->cputype = CPU_VR4181A;
 			break;
-		case PRID_REV_VR4131:
-			c->cputype = CPU_VR4131;
+		case PRID_REV_VR4130:
+			if ((c->processor_id & 0xf) < 0x4)
+				c->cputype = CPU_VR4131;
+			else
+				c->cputype = CPU_VR4133;
 			break;
 		default:
 			printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/proc.c linux/arch/mips/kernel/proc.c
--- linux.orig/arch/mips/kernel/proc.c	Tue Oct 14 12:00:55 2003
+++ linux/arch/mips/kernel/proc.c	Thu Oct 16 00:35:25 2003
@@ -69,6 +69,7 @@
 	[CPU_VR4121]	"NEC VR4121",
 	[CPU_VR4122]	"NEC VR4122",
 	[CPU_VR4131]	"NEC VR4131",
+	[CPU_VR4133]	"NEC VR4133",
 	[CPU_VR4181]	"NEC VR4181",
 	[CPU_VR4181A]	"NEC VR4181A",
 	[CPU_SR71000]	"Sandcraft SR71000"
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux.orig/arch/mips/mm/c-r4k.c	Tue Oct 14 12:00:56 2003
+++ linux/arch/mips/mm/c-r4k.c	Thu Oct 16 00:35:26 2003
@@ -831,6 +831,8 @@
 		c->dcache.waybit = 0;
 		break;
 
+	case CPU_VR4133:
+		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/pci/pci-vr41xx.h linux/arch/mips/pci/pci-vr41xx.h
--- linux.orig/arch/mips/pci/pci-vr41xx.h	Fri Jun 13 23:19:56 2003
+++ linux/arch/mips/pci/pci-vr41xx.h	Thu Oct 16 00:35:26 2003
@@ -107,9 +107,6 @@
 
 #define MAX_PCI_CLOCK			33333333
 
-#define PCIU_CLOCK			0x0080
-#define PCI_CLOCK			0x2000
-
 static inline int pciu_read_config_byte(int where, u8 * val)
 {
 	u32 data;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux.orig/arch/mips/vr41xx/casio-e55/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Thu Oct 16 00:35:26 2003
@@ -62,7 +62,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux.orig/arch/mips/vr41xx/common/bcu.c	Sat Aug 30 01:35:41 2003
+++ linux/arch/mips/vr41xx/common/bcu.c	Thu Oct 16 00:35:27 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - Calculate mips_hpt_frequency properly on VR4131.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -52,8 +53,8 @@
 
 #define VR4111_CLKSPEEDREG	KSEG1ADDR(0x0b000014)
 #define VR4122_CLKSPEEDREG	KSEG1ADDR(0x0f000014)
-#define VR4131_CLKSPEEDREG	VR4122_CLKSPEEDREG
  #define CLKSP(x)		((x) & 0x001f)
+ #define CLKSP_VR4133(x)	((x) & 0x0007)
 
  #define DIV2B			0x8000
  #define DIV3B			0x4000
@@ -72,8 +73,9 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121: return readw(VR4111_CLKSPEEDREG);
-	case CPU_VR4122: return readw(VR4122_CLKSPEEDREG);
-	case CPU_VR4131: return readw(VR4131_CLKSPEEDREG);
+	case CPU_VR4122:
+	case CPU_VR4131:
+	case CPU_VR4133: return readw(VR4122_CLKSPEEDREG);
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
@@ -90,19 +92,43 @@
 	case CPU_VR4111:
 	case CPU_VR4121:
 		pclock = 18432000 * 64;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4122:
 		pclock = 18432000 * 98;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4131:
 		pclock = 18432000 * 108;
+		pclock /= CLKSP(clkspeed);
+		break;
+	case CPU_VR4133:
+		switch (CLKSP_VR4133(clkspeed)) {
+		case 0:
+			pclock = 133000000;
+			break;
+		case 1:
+			pclock = 149000000;
+			break;
+		case 2:
+			pclock = 165900000;
+			break;
+		case 3:
+			pclock = 199100000;
+			break;
+		case 4:
+			pclock = 265900000;
+			break;
+		default:
+			printk(KERN_INFO "Unknown PClock speed for NEC VR4133\n");
+			break;
+		}
 		break;
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
 	}
 
-	pclock /= CLKSP(clkspeed);
 	printk(KERN_INFO "PClock: %ldHz\n", pclock);
 
 	return pclock;
@@ -135,6 +161,7 @@
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_vtclock = pclock / VTDIVMODE(clkspeed);
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
@@ -165,6 +192,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		tclock = vtclock / TDIVMODE(clkspeed);
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux.orig/arch/mips/vr41xx/common/cmu.c	Fri Apr 11 00:17:57 2003
+++ linux/arch/mips/vr41xx/common/cmu.c	Thu Oct 16 00:35:27 2003
@@ -33,38 +33,174 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
 #include <asm/io.h>
+#include <asm/vr41xx/vr41xx.h>
 
 #define VR4111_CMUCLKMSK	KSEG1ADDR(0x0b000060)
 #define VR4122_CMUCLKMSK	KSEG1ADDR(0x0f000060)
+ #define MSKPIU			0x0001
+ #define MSKSIU			0x0002
+ #define MSKAIU			0x0004
+ #define MSKKIU			0x0008
+ #define MSKFIR			0x0010
+ #define MSKDSIU		0x0820
+ #define MSKCSI			0x0040
+ #define MSKPCIU		0x0080
+ #define MSKSSIU		0x0100
+ #define MSKSHSP		0x0200
+ #define MSKFFIR		0x0400
+ #define MSKSCSI		0x1000
+ #define MSKPPCIU		0x2000
+#define VR4133_CMUCLKMSK2	KSEG1ADDR(0x0f000064)
+ #define MSKCEU			0x0001
+ #define MSKMAC0		0x0002
+ #define MSKMAC1		0x0004
+
+static u32 vr41xx_cmu_base;
+static u16 cmuclkmsk, cmuclkmsk2;
+
+#define read_cmuclkmsk()	readw(vr41xx_cmu_base)
+#define read_cmuclkmsk2()	readw(VR4133_CMUCLKMSK2)
+#define write_cmuclkmsk()	writew(cmuclkmsk, vr41xx_cmu_base)
+#define write_cmuclkmsk2()	writew(cmuclkmsk2, VR4133_CMUCLKMSK2)
 
-static u32 vr41xx_cmu_base = 0;
-static u16 cmuclkmsk = 0;
-
-#define write_cmu(mask)	writew((mask), vr41xx_cmu_base)
-
-void vr41xx_clock_supply(u16 mask)
+void vr41xx_clock_supply(unsigned int clock)
 {
-	cmuclkmsk |= mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk |= MSKPIU;
+		break;
+	case SIU_CLOCK:
+		cmuclkmsk |= MSKSIU | MSKSSIU;
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk |= MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk |= MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk |= MSKFIR | MSKFFIR;
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121)
+			cmuclkmsk |= MSKDSIU;
+		else
+			cmuclkmsk |= MSKSIU | MSKDSIU;
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk |= MSKCSI | MSKSCSI;
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk |= MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk |= MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk |= MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 |= MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 |= MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 |= MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void vr41xx_clock_mask(u16 mask)
+void vr41xx_clock_mask(unsigned int clock)
 {
-	cmuclkmsk &= ~mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk &= ~MSKPIU;
+		break;
+	case SIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		} else {
+			if (cmuclkmsk & MSKDSIU)
+				cmuclkmsk &= ~MSKSSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		}
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk &= ~MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk &= ~MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk &= ~(MSKFIR | MSKFFIR);
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~MSKDSIU;
+		} else {
+			if (cmuclkmsk & MSKSIU)
+				cmuclkmsk &= ~MSKDSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKDSIU);
+		}
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk &= ~(MSKCSI | MSKSCSI);
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk &= ~MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk &= ~MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk &= ~MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 &= ~MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void __init vr41xx_cmu_init(u16 mask)
+void __init vr41xx_cmu_init(void)
 {
 	switch (current_cpu_data.cputype) {
         case CPU_VR4111:
@@ -75,10 +211,14 @@
         case CPU_VR4131:
                 vr41xx_cmu_base = VR4122_CMUCLKMSK;
                 break;
+        case CPU_VR4133:
+                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+		cmuclkmsk2 = read_cmuclkmsk2();
+                break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
 		break;
         }
 
-	cmuclkmsk = mask;
+	cmuclkmsk = read_cmuclkmsk();
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux.orig/arch/mips/vr41xx/common/giu.c	Sat Apr 19 16:38:35 2003
+++ linux/arch/mips/vr41xx/common/giu.c	Thu Oct 16 00:51:31 2003
@@ -34,6 +34,9 @@
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
  *  - New creation, NEC VR4111, VR4121, VR4122 and VR4131 are supported.
+ *
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -61,6 +64,10 @@
 #define GIUINTALSELH	0x16
 #define GIUINTHTSELL	0x18
 #define GIUINTHTSELH	0x1a
+#define GIUFEDGEINHL	0x20
+#define GIUFEDGEINHH	0x22
+#define GIUREDGEINHL	0x24
+#define GIUREDGEINHH	0x26
 
 u32 vr41xx_giu_base = 0;
 
@@ -119,24 +126,56 @@
 
 	if (pin < 16) {
 		mask = (u16)1 << pin;
-		if (trigger == TRIGGER_EDGE) {
+		if (trigger != TRIGGER_LEVEL) {
         		set_giuint(GIUINTTYPL, mask);
 			if (hold == SIGNAL_HOLD)
 				set_giuint(GIUINTHTSELL, mask);
 			else
 				clear_giuint(GIUINTHTSELL, mask);
+			if (current_cpu_data.cputype == CPU_VR4133) {
+				switch (trigger) {
+				case TRIGGER_EDGE_FALLING:
+					set_giuint(GIUFEDGEINHL, mask);
+					clear_giuint(GIUREDGEINHL, mask);
+					break;
+				case TRIGGER_EDGE_RISING:
+					clear_giuint(GIUFEDGEINHL, mask);
+					set_giuint(GIUREDGEINHL, mask);
+					break;
+				default:
+					set_giuint(GIUFEDGEINHL, mask);
+					set_giuint(GIUREDGEINHL, mask);
+					break;
+				}
+			}
 		} else {
 			clear_giuint(GIUINTTYPL, mask);
 			clear_giuint(GIUINTHTSELL, mask);
 		}
 	} else {
 		mask = (u16)1 << (pin - 16);
-		if (trigger == TRIGGER_EDGE) {
+		if (trigger != TRIGGER_LEVEL) {
 			set_giuint(GIUINTTYPH, mask);
 			if (hold == SIGNAL_HOLD)
 				set_giuint(GIUINTHTSELH, mask);
 			else
 				clear_giuint(GIUINTHTSELH, mask);
+			if (current_cpu_data.cputype == CPU_VR4133) {
+				switch (trigger) {
+				case TRIGGER_EDGE_FALLING:
+					set_giuint(GIUFEDGEINHH, mask);
+					clear_giuint(GIUREDGEINHH, mask);
+					break;
+				case TRIGGER_EDGE_RISING:
+					clear_giuint(GIUFEDGEINHH, mask);
+					set_giuint(GIUREDGEINHH, mask);
+					break;
+				default:
+					set_giuint(GIUFEDGEINHH, mask);
+					set_giuint(GIUREDGEINHH, mask);
+					break;
+				}
+			}
 		} else {
 			clear_giuint(GIUINTTYPH, mask);
 			clear_giuint(GIUINTHTSELH, mask);
@@ -246,6 +285,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_giu_base = VR4122_GIUIOSELL;
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux.orig/arch/mips/vr41xx/common/icu.c	Sat Apr 19 16:38:35 2003
+++ linux/arch/mips/vr41xx/common/icu.c	Thu Oct 16 00:35:27 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - kgdb support.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -290,6 +291,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_icu1_base = VR4122_SYSINT1REG;
 		vr41xx_icu2_base = VR4122_SYSINT2REG;
 		break;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux.orig/arch/mips/vr41xx/common/serial.c	Fri Apr 11 00:18:03 2003
+++ linux/arch/mips/vr41xx/common/serial.c	Thu Oct 16 00:35:27 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -66,7 +67,6 @@
  #define TMICMODE		0x20
 
 #define SIU_BASE_BAUD		1152000
-#define SIU_CLOCK		0x0102
 
 /* VR4122 and VR4131 DSIU Registers */
 #define DSIURB			KSEG1ADDR(0x0f000820)
@@ -75,7 +75,6 @@
  #define INTDSIU		0x0800
 
 #define DSIU_BASE_BAUD		1152000
-#define DSIU_CLOCK		0x0802
 
 int vr41xx_serial_ports = 0;
 
@@ -106,6 +105,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		writew(val, VR4122_SIUIRSEL);
 		break;
 	default:
@@ -133,6 +133,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		s.iomem_base = (unsigned char *)VR4122_SIURB;
 		break;
 	default:
@@ -154,7 +155,8 @@
 	struct serial_struct s;
 
 	if (current_cpu_data.cputype != CPU_VR4122 &&
-	    current_cpu_data.cputype != CPU_VR4131)
+	    current_cpu_data.cputype != CPU_VR4131 &&
+	    current_cpu_data.cputype != CPU_VR4133)
 		return;
 
 	memset(&s, 0, sizeof(s));
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/time.c linux/arch/mips/vr41xx/common/time.c
--- linux.orig/arch/mips/vr41xx/common/time.c	Sat Aug 30 01:35:41 2003
+++ linux/arch/mips/vr41xx/common/time.c	Thu Oct 16 00:35:27 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4100 series are supported.
  *  - Added support for NEC VR4100 series RTC Unit.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4100 series are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/config.h>
 #include <linux/interrupt.h>
@@ -69,6 +70,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
                 vr41xx_rtc_base = VR4122_ETIMELREG;
                 break;
         default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Thu Oct 16 00:35:27 2003
@@ -62,7 +62,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Thu Oct 16 00:35:27 2003
@@ -143,7 +143,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	Thu Oct 16 00:35:28 2003
@@ -110,7 +110,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
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	Tue Jul 29 23:50:25 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Thu Oct 16 00:35:28 2003
@@ -115,7 +115,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Thu Oct 16 00:35:28 2003
@@ -110,7 +110,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/setup.c	Wed Jul 30 22:36:56 2003
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Thu Oct 16 00:35:29 2003
@@ -110,7 +110,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0x0102);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/cpu.h linux/include/asm-mips/cpu.h
--- linux.orig/include/asm-mips/cpu.h	Tue Oct 14 12:01:08 2003
+++ linux/include/asm-mips/cpu.h	Thu Oct 16 00:39:53 2003
@@ -101,7 +101,7 @@
 #define PRID_REV_VR4121		0x0060
 #define PRID_REV_VR4122		0x0070
 #define PRID_REV_VR4181A	0x0070	/* Same as VR4122 */
-#define PRID_REV_VR4131		0x0080
+#define PRID_REV_VR4130		0x0080
 
 /*
  * FPU implementation/revision register (CP1 control register 0).
@@ -170,7 +170,8 @@
 #define CPU_SR71000		53
 #define CPU_RM9000		54
 #define CPU_25KF		55
-#define CPU_LAST		55
+#define CPU_VR4133		56
+#define CPU_LAST		56
 
 /*
  * ISA Level encodings
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	Wed Jul 30 22:36:56 2003
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Thu Oct 16 00:52:04 2003
@@ -32,12 +32,15 @@
 #define PRID_VR4181A_REV1_0	0x00000c73
 #define PRID_VR4181A_REV1_1	0x00000c74
 
-/* VR4131 0x00000c80-0x00000c8f */
+/* VR4131 0x00000c80-0x00000c83 */
 #define PRID_VR4131_REV1_2	0x00000c80
 #define PRID_VR4131_REV2_0	0x00000c81
 #define PRID_VR4131_REV2_1	0x00000c82
 #define PRID_VR4131_REV2_2	0x00000c83
 
+/* VR4131 0x00000c84- */
+#define PRID_VR4133		0x00000c84
+
 /*
  * Bus Control Uint
  */
@@ -46,9 +49,25 @@
 /*
  * Clock Mask Unit
  */
-extern void vr41xx_cmu_init(u16 mask);
-extern void vr41xx_clock_supply(u16 mask);
-extern void vr41xx_clock_mask(u16 mask);
+extern void vr41xx_cmu_init(void);
+extern void vr41xx_clock_supply(unsigned int clock);
+extern void vr41xx_clock_mask(unsigned int clock);
+
+enum {
+	PIU_CLOCK,
+	SIU_CLOCK,
+	AIU_CLOCK,
+	KIU_CLOCK,
+	FIR_CLOCK,
+	DSIU_CLOCK,
+	CSI_CLOCK,
+	PCIU_CLOCK,
+	HSP_CLOCK,
+	PCI_CLOCK,
+	CEU_CLOCK,
+	ETHER0_CLOCK,
+	ETHER1_CLOCK
+};
 
 /*
  * Interrupt Control Unit
@@ -110,7 +129,9 @@
 
 enum {
 	TRIGGER_LEVEL,
-	TRIGGER_EDGE
+	TRIGGER_EDGE,
+	TRIGGER_EDGE_FALLING,
+	TRIGGER_EDGE_RISING
 };
 
 enum {

--Multipart=_Thu__16_Oct_2003_01_05_33_+0900_6o7qDT6gjEp7K/_d--

From jsun@mvista.com Wed Oct 15 18:19:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Oct 2003 18:19:27 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:15869 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225509AbTJORTP>;
	Wed, 15 Oct 2003 18:19:15 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h9FHJ2C08898;
	Wed, 15 Oct 2003 10:19:02 -0700
Date: Wed, 15 Oct 2003 10:19:02 -0700
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: MIPS addressing limits, Was: Re: CVS Update@-mips.org: linux
Message-ID: <20031015101902.C8761@mvista.com>
References: <20031014132850.GA12938@linux-mips.org> <Pine.GSO.3.96.1031015161040.9299D-100000@delta.ds2.pg.gda.pl> <20031015145948.GB23514@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: <20031015145948.GB23514@linux-mips.org>; from ralf@linux-mips.org on Wed, Oct 15, 2003 at 04:59:48PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3447
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2207
Lines: 46

On Wed, Oct 15, 2003 at 04:59:48PM +0200, Ralf Baechle wrote:
> On Wed, Oct 15, 2003 at 04:23:06PM +0200, Maciej W. Rozycki wrote:
> 
> > > Still want more?  A 3 level tree would then cover 128TB of virtual
> > > address space already exceedin the hardware limits of all processors but
> > > the R8000.
> > 
> >  Well, the MIPS64 ISA spec allows up to 8EB of user memory to be supported
> > by an implementation, IIRC; probably nothing supports that much yet,
> > though. ;-)  BTW, is an R8000 spec available online anywhere?
> 
> There used to be a few papers published by SGI online and various other
> bits of information I found through google.
> 
> (I happen to have a paper copy of the R8000 manual but since the responsible
> people still haven't informed me if I can legally use it, this book is
> closed and will stay closed until this happens - if ever ...  Pitty, I
> still receive mails from various R8000 users ...)
> 
> > > 64k pagesize stretches the limits even further.   Here a two level
> > > pagetable tree would cover 4TB, 3-level could cover 32PB exceeding
> > > the capacity of every MIPS processor ever made - and probably sufficient
> > > for the coming decade :-)
> > 
> >  Further increasing of the page size should result in better performance
> > due to fewer TLB misses and reduce the memory footprint of page tables,
> > but the drawback is more memory is wasted for maps.  Whether the end
> > result is a gain or a loss depends on the actual application of a system,
> > so I guess we should either leave the size configurable (with a sane
> > default for those who might have troubles judging what would suit them
> > best) or only decide on a given size after lots of benchmarking.
> 
> Unless somebody yells I almost feel like ditching 3-level pagetable
> support; 2-levels with a decent pagesize should suffice for a few years
> to come ...
> 

Isn't ia64 still using 3-level page tables?  Any performance data we
can infer from theirs?

I feel a little uneasy about ditching 3-level pagetable altogether.
Leaving all the parameters configurable, including the possiblity of
nullifying the second level and changing page size, seems to be a more 
comforting thought.

Jun

From ralf@linux-mips.org Wed Oct 15 18:43:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Oct 2003 18:43:38 +0100 (BST)
Received: from p508B51CB.dip.t-dialin.net ([IPv6:::ffff:80.139.81.203]:33736
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225512AbTJORnc>; Wed, 15 Oct 2003 18:43:32 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h9FHgHNK019163;
	Wed, 15 Oct 2003 19:42:17 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9FHgGpQ019150;
	Wed, 15 Oct 2003 19:42:16 +0200
Date: Wed, 15 Oct 2003 19:42:16 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: MIPS addressing limits, Was: Re: CVS Update@-mips.org: linux
Message-ID: <20031015174216.GD11276@linux-mips.org>
References: <20031014132850.GA12938@linux-mips.org> <Pine.GSO.3.96.1031015161040.9299D-100000@delta.ds2.pg.gda.pl> <20031015145948.GB23514@linux-mips.org> <20031015101902.C8761@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031015101902.C8761@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: 3448
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 835
Lines: 20

On Wed, Oct 15, 2003 at 10:19:02AM -0700, Jun Sun wrote:

> Isn't ia64 still using 3-level page tables?  Any performance data we
> can infer from theirs?

Very different MMU, IA64 data is hardly an indicator.  And anyway, the
result should be MIPS TLB refill handlers suck big chunky rocks through
a straw so should be rewritten ;-)

> I feel a little uneasy about ditching 3-level pagetable altogether.
> Leaving all the parameters configurable, including the possiblity of
> nullifying the second level and changing page size, seems to be a more 
> comforting thought.

3 levels are only needed if you can seriously say you're need more than
64GB of vmalloc space or processes larger than 64GB.  Little need for
that in the current universe though I know one institution which broke
the 1TB process size limit > 5 years ago.

  Ralf

From broadfx@sendsational.net Fri Oct 17 17:29:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Oct 2003 17:29:08 +0100 (BST)
Received: from p508B7A91.dip.t-dialin.net ([IPv6:::ffff:80.139.122.145]:65200
	"EHLO p508B7A91.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225434AbTJQQ3D>; Fri, 17 Oct 2003 17:29:03 +0100
Received: from [IPv6:::ffff:24.84.167.113] ([IPv6:::ffff:24.84.167.113]:7439
	"HELO 24.84.167.113") by linux-mips.net with SMTP
	id <S869828AbTJQQ3C>; Fri, 17 Oct 2003 18:29:02 +0200
From: "BroadFX" <broadfx@sendsational.net>
To: <linux-mips@linux-mips.org>
Subject: October Newsletter issue 10
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="= Multipart Boundary 1017030927"
Date: Fri, 17 Oct 2003 09:27:55 -0700
Reply-To: "BroadFX" <broadfx@sendsational.net>
Message-Id: <20031017162902Z869828-15987+1255@linux-mips.net>
Return-Path: <broadfx@sendsational.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: 3449
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: broadfx@sendsational.net
Precedence: bulk
X-list: linux-mips
Content-Length: 8193
Lines: 136

This is a multipart MIME message.

--= Multipart Boundary 1017030927
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit

Complete Enterprise Fax/Email Solutions Software 
MDX Fax/Email Service send one send tens of thousands 
Incoming Fax to email service or software
Targeted Database customer contact lists
API-XML helps your CRM program link with BroadFax 
 October, 2003
 Toll Free: 1-888-276-2339
 www.broadfax.com


Communications Chronicle
Tips for Successful Faxing
Simple Ways to Shorten Fax Transmission Time (And Save Money)
Avoid excessive use of black. To the greatest extent possible: Avoid large graphics/logos. Stay away from large font size, bold settings and underlining. 
Plan your white space. Faxes are transmitted by horizontal lines. So, even one small bit of black on a horizontal line requires that the whole line be transmitted and printed. So, when finalizing your layout try to: create your document in blocks leaving vertical blank space in between, avoid vertical lines or frames around the text in short, don't just think of blank space, think of vertical blank space. 
BroadFax Enterprise is an innovative solution designed to streamline your business by integrating all your needs in one convenient package. 
The BroadFax Enterprise Suite includes the following: 
BroadFax FastFax – Want it out fast? With the click of your mouse send a fax from your desktop. This one will help improve office productivity. 
BroadFax Pro –If you’re looking to transmit high volumes, the robust Broadfax Pro will get your job done. 
Fax to email solution – It’s all automatic, your received faxes come right to your server then are converted to email and forwarded right to the appropriate individual all automatically. 
DID Receive – On the go? Receive your fax and e-mail documents in one convenient location using a toll-free or local phone number of your choice and forwarded right to your email for pickup anywhere in the world. 
BroadFax API (Application Programming Interface) – Customize BroadFax to meet all your CRM business needs. 
LCR (Least Cost Routing) – save money by sending your time-sensitive documents at the lowest possible costs. 
This feature-packed suite gives your business complete control over all your fax and email communications needs. 
For more information call 1-888-276-2339 or visit www.broadfax.com

--= Multipart Boundary 1017030927
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>October</TITLE>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2800.1106" name=GENERATOR>
<META content=FrontPage.Editor.Document name=ProgId></HEAD>
<BODY>
<TABLE height=127 width="95%" align=center border=0>
  <TBODY>
  <TR>
    <TD width="30%" height=19><IMG height=62 
      src="http://www.broadfax.com/broadcast-fax-images/BroadFx.jpg" width=123 
      border=0></TD>
    <TD vAlign=top width="65%" rowSpan=4 cellspacing="0">
      <P align=right><FONT face="Verdana, Arial, Helvetica, sans-serif" 
      size=1>Complete Enterprise Fax/Email Solutions Software </FONT></P>
      <P align=right><FONT face="Verdana, Arial, Helvetica, sans-serif" 
      size=1>MDX Fax/Email Service send one send tens of thousands </FONT></P>
      <P align=right><FONT face="Verdana, Arial, Helvetica, sans-serif" 
      size=1>Incoming Fax to email service or software</FONT></P>
      <P align=right><FONT face="Verdana, Arial, Helvetica, sans-serif" 
      size=1>Targeted Database customer contact lists</FONT></P>
      <P align=right><FONT face="Verdana, Arial, Helvetica, sans-serif" 
      size=1>API-XML helps your CRM program link with BroadFax</FONT><FONT 
      face="Verdana, Arial, Helvetica, sans-serif" size=2> </FONT></P></TD></TR>
  <TR>
    <TD width=296 height=20><FONT face=Verdana size=2>&nbsp;October, 
      2003</FONT></TD></TR>
  <TR>
    <TD width=296 height=20><B><FONT face=Verdana size=2>&nbsp;Toll 
      Free:</FONT><FONT face=Verdana size=2><SPAN 
      style="mso-fareast-font-family: Times New Roman; mso-bidi-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> 
      1-888-276-2339</SPAN></FONT></B></TD></TR>
  <TR>
    <TD width=296 height=20><B>&nbsp;<A href="http://www.broadfax.com/"><FONT 
      face=Verdana size=2>www.broadfax.com</FONT></A></B></TD></TR></TBODY></TABLE>
<P>&nbsp;</P>
<DIV align=right>
<TABLE height=625 width="95%" align=center border=0>
  <TBODY>
  <TR>
    <TD width=892 height=625>
      <H1 align=center>Communications Chronicle</H1>
      <H2 align=center><FONT face="Verdana, Arial, Helvetica, sans-serif" 
      size=2>Tips for Successful Faxing</FONT></H2>
      <P align=center><FONT face="Verdana, Arial, Helvetica, sans-serif" 
      size=2><B>Simple Ways to Shorten Fax Transmission Time (And Save 
      Money)</B></FONT></P>
      <P>
      <UL>
        <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>Avoid 
        excessive use of black. To the greatest extent possible: Avoid large 
        graphics/logos. Stay away from large font size, bold settings and 
        underlining. </FONT>
        <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>Plan your 
        white space. Faxes are transmitted by horizontal lines. So, even one 
        small bit of black on a horizontal line requires that the whole line be 
        transmitted and printed. So, when finalizing your layout try to: create 
        your document in blocks leaving vertical blank space in between, avoid 
        vertical lines or frames around the text in short, don't just think of 
        blank space, think of vertical blank space. </FONT></LI></UL>
      <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>BroadFax 
      Enterprise is an innovative solution designed to streamline your business 
      by integrating all your needs in one convenient package. </FONT></P>
      <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
      size=2><STRONG><U>The BroadFax Enterprise Suite includes the 
      following:</U></STRONG> </FONT>
      <UL>
        <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>BroadFax 
        FastFax – Want it out fast? With the click of your mouse send a fax from 
        your desktop. This one will help improve office productivity.</FONT> 
        <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>BroadFax 
        Pro –If you’re looking to transmit high volumes, the robust Broadfax Pro 
        will get your job done. </FONT>
        <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>Fax to 
        email solution – It’s all automatic, your received faxes come right to 
        your server then are converted to email and forwarded right to the 
        appropriate individual all automatically.</FONT> 
        <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>DID 
        Receive – On the go? Receive your fax and e-mail documents in one 
        convenient location using a toll-free or local phone number of your 
        choice and forwarded right to your email for pickup anywhere in the 
        world.</FONT> 
        <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>BroadFax 
        API (Application Programming Interface) – Customize BroadFax to meet all 
        your CRM business needs.</FONT> 
        <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>LCR (Least 
        Cost Routing) – save money by sending your time-sensitive documents at 
        the lowest possible costs.</FONT> </LI></UL><FONT 
      face="Verdana, Arial, Helvetica, sans-serif" size=2>
      <DIV align=center>
      <P>This feature-packed suite gives your business complete control over all 
      your fax and email communications needs. </P>
      <P><STRONG><FONT size=3>For more information call 1-888-276-2339 or visit 
      <A 
      href="http://www.broadfax.com/">www.broadfax.com</A></FONT></STRONG></P></DIV></FONT></TD></TR></TBODY></TABLE></DIV></BODY></HTML>

--= Multipart Boundary 1017030927--


From BroadFX@sendsational.net Sat Oct 18 04:09:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Oct 2003 04:09:36 +0100 (BST)
Received: from [IPv6:::ffff:206.116.174.21] ([IPv6:::ffff:206.116.174.21]:6662
	"HELO 206.116.174.21") by linux-mips.org with SMTP
	id <S8224985AbTJRDJd>; Sat, 18 Oct 2003 04:09:33 +0100
From: "BroadFX" <BroadFX@sendsational.net>
To: <linux-mips@linux-mips.org>
Subject: October newsletter Vol 5 issue 10 tips for faxing
Mime-Version: 1.0
Content-Type: multipart/related;
	boundary="= Multipart Boundary 1017032006"
Date: Fri, 17 Oct 2003 20:06:09 -0700
Reply-To: "BroadFX" <broadfx@sendsational.net>
Message-Id: <20031018030933Z8224985-1272+8085@linux-mips.org>
Return-Path: <BroadFX@sendsational.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: 3450
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: BroadFX@sendsational.net
Precedence: bulk
X-list: linux-mips
Content-Length: 42363
Lines: 677

This is a multipart MIME message.

--= Multipart Boundary 1017032006
Content-Type: multipart/alternative;
	boundary="= Multipart Boundary _EXTRA_1017032006"

--= Multipart Boundary _EXTRA_1017032006
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit

Tips for Successful Faxing
Simple Ways to Shorten Fax Transmission Time (And Save Money) 
Avoid excessive use of black. Black does create a bold image but the costs usually exceed the benefits. 
Avoid large graphics/logos Stay away from large font size, bold settings and underlining. 
Plan your white space. Faxes are transmitted by horizontal lines. So, even one small bit of black on a horizontal line requires that the whole line be transmitted and printedon most fax machines. 
If you use two columns for your message, don’t use a gutter in the middle, be very careful about lining up both sets of text in the two columns, if they do not line up the spaces between the lines do not line up and it can slow transmission a lot. It is usually easier to do, two paragraphs instead of two columns.
Don’t convert a color image to gray scale & send, try to find an original black and white of the picture you wish to use, or even better get a line drawing, there is a considerable amount of free clip art available on the internet.
If you have to scan in an image because it is necessary for your message, make sure the image scanned is clean, if necessary convert it to a format that you can blow up to a large size and edit pixel by pixel. If you can create a good image, you can use it again and again. One hours work on the computer could save you $ as many faxing hours over the next year.
When finalizing your layout try to: create your document in blocks leaving vertical blank space in between the areas of text, avoid vertical lines or frames around the text in short, don't just think of blank space, think of vertical blank space. 
BroadFax Flexes It’s Muscles With Broadfax Enterprise Suite
BroadFax Enterprise is a complete solution to streamline your business communication by integrating all your needs in one convenient system. 
The BroadFax Enterprise Suite includes the following:
Ø BroadFax FastFax – Fax from your workstation send your message or quotation directly to the fax server Want it out fast, how about with the click of your mouse send a fax from your desktop. This one will help improve office productivity.
Ø BroadFax Pro –If your looking to transmit high volumes, the robust Broadfax Pro will get your job done. 
Ø Fax to email solution – It’s all automatic, your received faxes come right to your server then are converted to email and forwarded right to the appropriate individual all automatically.
Ø DID Receive – On the go? Receive your fax and e-mail documents in one convenient location using a toll-free or local phone number of your choice and forwarded right to your email for pickup any where in the world.
Ø BroadFax API (Application Programming Interface) – Customize BroadFax to meet all your CRM business needs
Ø LCR or Least Cost Routing – save money by sending your time-sensitive documents at the lowest possible costs
Overall this features packed suite gives your business complete control over critical and time-sensitive inbound and outbound documents and is simple enough anyone can use it.
For more information call 1-888-276-2339 or visit www.broadfax.com
To be removed from this list please send a blank email to unsubscribe@sendsational.net

--= Multipart Boundary _EXTRA_1017032006
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o = "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2800.1226" name=GENERATOR>
<STYLE>BODY {
	FONT-FAMILY: arial
}
</STYLE>
</HEAD>
<BODY>
<DIV><FONT face=Verdana><FONT face="Tw Cen MT">
<DIR><FONT face="Tw Cen MT Condensed">
<P><FONT face=Tahoma></FONT>&nbsp;</P>
<P align=left><A href="http://www.broadfax.com"></A></FONT></FONT></FONT><FONT 
face=Verdana><FONT face="Tw Cen MT" size=1><FONT face="Times New Roman"><SPAN 
style="FONT-SIZE: 24pt; FONT-FAMILY: 'Tw Cen MT'; mso-bidi-font-family: Arial"></SPAN></FONT></FONT></FONT></P>
<P align=left><FONT face=Verdana><FONT face="Tw Cen MT" size=1><FONT 
face="Times New Roman"><SPAN 
style="FONT-SIZE: 24pt; FONT-FAMILY: 'Tw Cen MT'; mso-bidi-font-family: Arial"><IMG 
alt="" hspace=0 src="cid:343115" 
align=baseline border=0></SPAN></FONT></FONT></FONT></P>
<P align=left><FONT face=Verdana><FONT face="Tw Cen MT" size=1><FONT 
face="Times New Roman"><SPAN 
style="FONT-SIZE: 24pt; FONT-FAMILY: 'Tw Cen MT'; mso-bidi-font-family: Arial">Tips 
for Successful Faxing</SPAN></FONT></FONT></FONT></P>
<P align=left><FONT face=Verdana><FONT face="Tw Cen MT" size=1><FONT 
face="Times New Roman"><SPAN 
style="FONT-SIZE: 24pt; FONT-FAMILY: 'Tw Cen MT'; mso-bidi-font-family: Arial"></SPAN></FONT><FONT 
face="Times New Roman"><B><SPAN 
style="FONT-SIZE: 13.5pt; FONT-FAMILY: 'Tw Cen MT'; mso-bidi-font-family: Arial"><FONT 
face="Times New Roman">Simple Ways to Shorten Fax Transmission Time (And Save 
Money)</FONT></SPAN></B><SPAN 
style="FONT-SIZE: 13.5pt; FONT-FAMILY: 'Tw Cen MT'; mso-bidi-font-family: Arial"> 
</SPAN><SPAN style="FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT></P>
<P><FONT size=3><FONT face="Times New Roman"><SPAN 
style="FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Avoid excessive use of 
black.&nbsp;Black does create a bold image but the costs&nbsp;usually exceed the 
</SPAN><SPAN 
style="FONT-FAMILY: Verdana; mso-bidi-font-family: Arial; mso-fareast-font-family: 'Times New Roman'">benefits</SPAN><SPAN 
style="FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">.&nbsp;</SPAN><SPAN 
style="FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT></FONT></P>
<P><FONT face="Times New Roman"><SPAN 
style="FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"><FONT size=3>Avoid 
large graphics/logos Stay away from </FONT></SPAN><SPAN 
style="FONT-SIZE: 13.5pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">large 
font size</SPAN><FONT size=3><SPAN 
style="FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">, <STRONG>bold 
settings</STRONG> and <U>underlining.</U> </SPAN><SPAN 
style="FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT></FONT></P>
<P><FONT size=3><FONT face="Times New Roman"><SPAN 
style="FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Plan your white space. 
Faxes are transmitted by horizontal lines. So, even one small bit of black on a 
horizontal line requires that the whole line be transmitted and printedon most 
fax machines. </SPAN><SPAN 
style="FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT></FONT></P>
<P><FONT size=3><FONT face="Times New Roman"><SPAN 
style="FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">If you use two columns 
for your message, don’t use a gutter in the middle, be very careful about lining 
up both sets of text in the two columns, if they do not line up the spaces 
between the lines do not line up and it can slow transmission a lot. It is 
usually easier to do, two paragraphs&nbsp;instead of two columns.</SPAN><SPAN 
style="FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT></FONT></P>
<P><FONT size=3><FONT face="Times New Roman"><SPAN 
style="FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Don’t convert a color 
image to gray scale &amp; send, try to find an original black and white of the 
picture you wish to use, or even better get a line drawing, there is a 
considerable amount of free clip art available on the internet.</SPAN><SPAN 
style="FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT></FONT></P>
<P><FONT face="Times New Roman"><FONT size=3><SPAN 
style="FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">If you have to scan in 
an image because it is necessary for your message, make sure the image scanned 
is clean, if necessary convert it to a format that you can blow up to a large 
size and edit pixel by pixel. </SPAN></FONT><FONT size=3><SPAN 
style="FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">If you can create a 
good image, you can use it again and again.&nbsp;One hours work on the computer 
could save you $ as many faxing hours over the next year.</SPAN><SPAN 
style="FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT></FONT></P>
<P><SPAN 
style="FONT-SIZE: 12pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">When 
finalizing your layout try to: create your document in blocks leaving vertical 
blank space in between the areas of text,&nbsp;avoid vertical lines or frames 
around the text in short, don't just think of blank space, think of vertical 
blank space. </SPAN></P>
<P><SPAN 
style="FONT-SIZE: 12pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"></SPAN></FONT></FONT><B><FONT 
face="Tw Cen MT" size=5>BroadFax Flexes It’s Muscles With Broadfax Enterprise 
Suite</FONT></B></P>
<P><B><FONT face="Tw Cen MT" size=5></B></FONT><FONT face=Verdana>BroadFax 
Enterprise is a&nbsp;complete solution&nbsp;to streamline your business 
communication by integrating all your needs in one convenient system.</FONT> 
</P>
<P><B><U><FONT face=Verdana>The BroadFax Enterprise Suite includes the 
following:</FONT></P></DIR></B></U>
<DIR>
<DIR>
<P><FONT face=Verdana>Ø <B>BroadFax FastFax</B> – Fax from your workstation send 
your message or quotation directly to the fax server Want it out fast, how about 
with the click of your mouse send a fax from your desktop. This one will help 
improve office productivity.</FONT></P>
<P><FONT face=Verdana>Ø <B><A 
href="http://www.broadfax.com/Corporate-News.htm#BroadFaxPro">BroadFax Pro</A> 
</B>–If your looking to transmit high volumes, the robust Broadfax Pro will get 
your job done. </FONT></P>
<P><FONT face=Verdana>Ø <B>Fax to email solution</B> – It’s all automatic, your 
received faxes come right to your server then are converted to email and 
forwarded right to the appropriate individual all automatically.</FONT></P>
<P><FONT face=Verdana>Ø <B>DID Receive</B> – On the go? Receive your fax and 
e-mail documents in one convenient location using a toll-free or local phone 
number of your choice and forwarded right to your email for pickup any where in 
the world.</FONT></P>
<P><FONT face=Verdana>Ø <B><A 
href="http://www.broadfax.com/api/dev_support.html">BroadFax API (Application 
Programming Interface)</A></B> – Customize BroadFax to meet all your CRM 
business needs</FONT></P>
<P><FONT face=Verdana>Ø <B>LCR or Least Cost Routing</B> – save money by sending 
your time-sensitive documents at the lowest possible costs</FONT></P>
<P><FONT face=Verdana>Overall this features packed suite gives your business 
complete control over critical and time-sensitive inbound and outbound documents 
and is simple enough anyone can use it.</FONT></P>
<P><FONT size=2><B><FONT size=4><FONT face=Verdana>For more information call 
1-888-276-2339 or visit </FONT><A href="http://www.broadfax.com"><FONT 
face=Verdana><A 
href="http://www.broadfax.com">www.broadfax.com</FONT></A></B></FONT></FONT><FONT 
face=Verdana size=1></FONT></A></P>
<P><FONT face=Verdana size=1>To be removed from&nbsp;this list please send a 
blank email to </FONT><A href="mailto:unsubscribe@sendsational.net"><FONT 
face=Verdana size=1>unsubscribe@sendsational.net</FONT></A><FONT face=Verdana 
size=1> </FONT></P></DIR></DIR></DIV></BODY></HTML>

--= Multipart Boundary _EXTRA_1017032006--

--= Multipart Boundary 1017032006
Content-Type: application/octet-stream;
	name="WebsiteTemplate3.jpg"
Content-Transfer-Encoding: base64
Content-ID: <343115>
Content-Disposition: attachment;
	filename="WebsiteTemplate3.jpg"

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAA0JCQoKCg4LCw4UDQsNFBcRDg4R
FxsVFRUVFRsbFRcXFxcVGxoeICEgHhonJyoqJyc1NTU1NTY2NjY2NjY2Njb/
2wBDAQ4NDRERERcRERcXExQTFx0ZGhoZHSYdHR4dHSYsJCAgICAkLCgrJiYm
KygvLywsLy82NjY2NjY2NjY2NjY2Njb/wAARCACmArwDAREAAhEBAxEB/8QA
GwAAAQUBAQAAAAAAAAAAAAAAAgABAwQFBgf/xABSEAABAgMEBQYJBwkIAQQD
AQABAgMABBEFEiExBhNBUWEUInGBkdEVMlJUkqGxwdIWIzNCU5OyByQ0YnJz
4fDxJTU2Q0SCg6J0F2OzwlVko+P/xAAZAQEBAQEBAQAAAAAAAAAAAAAAAQID
BAX/xAAtEQEAAgIBAwIFBAMBAQEAAAAAARECEjEDBCETQSIyUWGBM3GhsSOR
wUJy8P/aAAwDAQACEQMRAD8AyJCRklScutTDS1FtBNUCtaCtTTGPZji4zKxy
CRKaiVZJP/tpp7IsYQm0ibsqTvXTLs8atp7oukFyJdlyANeTs0P6iO6GkFyZ
NnSJVzpeXAw+ojuiaQXJuQWZX6CXp+yjuhoXJuSWRiNTL4fqpr7IaQXJuS2R
j81L8OYnuhpBci5DZlwLTLsXDXn3E09kNILkkSVlf5jMuP8AYmvsi6QXIkSl
ku1DcuzUZ/Np7oRhCbSm8F2dj+asfdp7oT003kIsuzr36MwRu1ae6HpwbSKT
k7MD1VycupBJzaSRTsh6bUZItKLHlZZTb7MqyiXcoOa2kALGw0G0YxJxhtza
peX+yR6IiaNB5Myf8pNP2RDRLGiQ130cte3URDQsnJBLXNWwEHiBWGjSIyzX
2afRENAxl2qfRp7BthohCXa+s2kDbgKxdAxYZ+zA/wBohoguTs+QjjgITgJm
ZRiuLaD/ALRE0JlrSkhJmlZdpXSgH3RYwYnJpN2TIKP6Kx92nui+m57ylVYt
nrp+Zsp6G090PTN5SeBLOUmnI2AMMdWm97IaNbDTYllAfobHW2kn2Q0NiFi2
RlyRj7tNfZDSDYZsWyz/AKKX+6R3Q0hdhCxbJA/QmN/0ST7omkJsLwNZVf0G
Xp+5R3Q0g2LwLZJ/0MuP+FHdE0g2P4DsrzKX+6R3Q0g2OLEsiv6FL9GqR3Qn
BdgTFkWWEAIkJe+rbqUUA3nCEYQmyumwbPVnKsj/AIkd0NIZ3kfgCyvNGvu0
d0NIN5MqwrKrXkbIAp/ljEnZlDSDeRJsGyyMZJgH92D7oaQbyLwDZHmTH3Y7
oaQbyZVhWVgkSbNTmdWnLbshpBvJJsSyyT+YsXdnzSQa9kNINpH4BsrzKX+6
T3Q0g2kvANk+ZMD/AIk90NYN5N4Csu/+hMUTn80nPsiawbyZuwrMxvyUuNw1
Se6GsG8i8BWV5lL/AHSe6GsLtJvAFmeZMfdJ7oapvIDYdmeZMfdJ7oam8hNi
2Z5kx90nuhpBvIfA9meZscPmk90NITeT+CLL8yY+6T3Q0hN5MbHs3zNj7pPd
F0hN5LwRZnmbG+uqT3RNIXeS8D2ZX9CY+6T3Q0g3lJN2fYVlS/KJyRYU6rBm
X1SaqPZ64zTdyzGrBYnXeUzcuywk+LLstpbSBsvED+MNSc18WDZXmrP3YJ9k
a0hn1JMdH7N2SrP3ac+yGkHqSrzFgSg5yZVqm0atPblDSD1JZ6rOkh/pmvQT
3RNGvUkPIZLzZr0E90Sl2PyGRP8ApmvQHdCk2ELPkPNmvQHdCk3kYs+R81a6
dWnuhSbykFm2fT9GZPHVp7oUbyfwXIebND/jT3Qo3khZUj5qz92nui6wu8pU
2RIn/Ss/dp7ozrC7SfwLZ4NeStdGrTT2RaTeUgs+zR/oWD/xJ7otM7yNNmWW
o/oTA/4k90NYT1JSCx7LP+jY+6T3Q1g9STmwbMP+jZ+7T3RKX1JCiwLKKqKl
WuHMT3Qo9SROaPWUk4SrXoJ7oUbyHwFZXmjR/wCNPdCk9SR+BrK8yY+6SfdC
j1JMbIsoeNJy4/4k90KT1JD4MsgnCTYru1Se6FL6kpPk/KUryBgbvmkd0KXe
QLsiRbTz7PY6dSinshRvKDwdZnmbH3Se6FJvJeCbLV/pGR/xpHuhS7y5HS1h
hi0G0y7aWkFkGiEhIreWK0Ecph3w4XZSbd5IwlFEgNoGWJIA2mPRg1OI3pt9
YCSvAHADCLCaor61bSa4HExWqgyshU+2BUGJqaDIbYFQMICsNu+IVB9VdScM
d8Dwj1eNDiRtygeEwVzabBiBs7IM0cODOmeZilJL9PFOW0Z1hBLZZ+dbQTtA
JPtjTlKQJ2btsRKRM5p/pAlpsqamWFyM2m+05zePCh3jYYk4tYZOStiyXrLe
DbuLK8WXdix7iNoiQ6qzU2tknVJTXIKUKkdGyLRQXJqZWMXV1240HUBCikWN
PXU4wU13+sA8SkN74tBiP4woLhvzhMCeXzHGJSS2pbZ6tkWIc5asvQ9ecVha
KhgN8BKttpbedKUKRWmO7CFKjbdS4Rq6FAzV7k++FCwplpKQpIGs2nPD3GsR
aDd/rBBQpTX0A85QBhQZy67dSl0ADGlK4woSJbuEpvlZFASeivrgDTle7OmJ
MAS27txqajIYboUhaldMssznCgKgaYDPADjCgYYXkNm3DOFKPk7lMB7IUAu3
QdwxJhSE3LrVzqeN1YbIUeEmoXu9kKUiytIvEYbTnBUazdHu4xKZmhty67uW
eJPHbCiKHydzdCl8C5O5u9kF8GLJ2jHbE2QBYhsAUx6ogDk8GQ6kgRURluNI
GBYg4lhCn1GlypBOWAqT1CCsORLtrTztoTBK0NYNA4iuzsGMZaybFPXGnM2M
Cz6wwostZ684UWozUuPGpzd+3+MZotnuNU6NhitAgo05QLGIJYx6ognbQpXX
AXmZOsYbXW5HhGVH4PrFsB4ORt7I1bAhKpT4qacYqURla7IFBUytPinLfFER
VQ85OO8ZQDOTGFAnrgyra9fCCWrOqmlq5roCdopjFVbZ1QHOPO2kwRNq21ZA
RFGm+nxVkcMxBTl6Zu0SU474DPcl361IggNS7Stw9OcCnGaYg+EWsP8AJT+N
cccuXp6fCeTP5szXHmJp6Ijrg2I59EdIDJx4ZE9MSQv5rCA+FOJ25QEjZH8Y
Ugs/eYqIlVvYdZiNCH9TnFQ6DdrdFeMAUUlsySqyyOApFcclmtB2+yDKKUHq
EFTq7MjXbWCLKH2Jtgyc8i+2rAE512EHYeMR0jNz1raNzEiC6xWZlDjfT4yB
+sPeIy6MWv8AWKofYMzBC6OuAWPfAL9nPfAKAWG6AsMezIRGZakvWNMS1GCb
u6lK9MVhK1rFbOvOCCmHtUAMycyTTCIDZU4sZXE78zAWk5YbMzFbPXdjviBK
NBjsxJ2QRUcbcdcKm1UpT+sGTtyrt7nOHowxiC+m6lPAZmDSKYdOrqK1HigY
QpLVNe95Jw/nfFplYln3t10DMnKJLUSF1ZaSm7VVMBtNM6wJlHyle5VT0wZS
MzTl7mhVd+MFSqJo5U584jdhl74Lany5X63HODJuXcT64FrEvOqUCE84HAxC
0ilLS184arbTjTyv6QFLwjh43rgg0Wh+t0QVelphSjnGbaaTYW4eG2MXi6rG
pjNwtALMLmSoRqQmHlnWAKajXhnVA4zGrSlNxNI1DnLI0imC1JIZT/nk1P6o
xPrhLpjC5o9LUsZCqeOpRJ66e6MrnCyE+qNW5UArpnmIigvVjTB73qgqOdcQ
zK3lkVOQzV/CC0xTPNb88xlhGW6EFNuirZrvG2AdIMEFjASt4mINOUbBjLbb
lZa8IxdcN0q2zb9nWM2UrUHZr6suk87pJ+qOmN4dKcvMpMhs21m5macZrlWn
VHNto1Qo0TjFtiiLLmynRthZQNSv61abaQspKJeVVs9LOLa6oXbPRQ3VhNMa
GLaasiYZuxpzpSVnGmAYwBQB5QRO2pzYYCdLh+sK8RBUyQFZdkRTtpKDTYYD
z38oKbtrtU83T+NyOUvThwkl5SabkmFltWrU2gpIyIKQRjHfBUawqvAbI0F7
DjSIpAb+zbADgT0ZDZFoG16uyKiXFWGzdlERGfG4DADZEaOiuPCnCKh8geyA
e9h04UijWs5X5vliFEUiuOS0Vm6ajKtOyKyUqnmnspBpItWPuiMyVL2eXrjS
JJeeellZ30DZEpuMgzFlWPaxvJ/NZg4lTeA607eqMOkZMSc0VtRjFpImWc6s
+NTik49kGmQttbS7q0qRT6qqg1gAxr0bIB9h7IBtnT2wCphlAWGc8eyDMtiU
bWvxUkj1RpiWu2gITzuyDKRpRvbhtgi4pLS21XgL5wSaA490RpH7OzCAfPo3
ZRQ4z6MhERAp5h6qSrAUoMr3HoggRKMKqELywIBqabBAWWWUoF0bdpxNIiic
pTLmjADed0BAqVbV4yMdwqPfC0o3IWq5Kw2XlAe2LZR1MtIGargz5yjjuziE
wRlL+N9Y2+MYFG5Hj9IvDiD7oJQuTqTk6vHADm90Fo2qcV82HlVGJwT3QRHy
V+v02WQuiBQeSzFfpB6P8YIkuTDSfGRuAukY9sQIpmLt2qCTnnWArKl3/IbP
b3QQTbD+1pHb/CErDVlGVjNtOHGOUusL9pTE7KSQXISnK3yQLl4AJFPGO/oE
ZxjGZbcROabaQsvrZdbal3EZt3DVParGPd0+hhMMTkUjpFpNaSyGplptIpVS
kJCa7hzVEmJ1On0sDy0nHNLpRvXkMT7YzCAQsDbgLnqrHLGOlkqOS00YmlBt
5HJlnI1qjt5tOvthn20x5SJdEzNIf5p8fYI8901MIZlmNxLlLl7aZK3xeOCU
0A47oS3i6DRV1C7P5Ir6RoqNNpQTWvug1S49LaleXMMS2aVZhpO7OFs6qmrA
7o2zqdporcCes9EGaBaTd887JOATsrxG2DTnH5e85wGFD7YjrA5ZkoXeTns2
xCYajbLzqRdl3VE5hKDTtMW2aOqzZ77HVp/9xaRCyjNyaknnvNCmxJKj6og1
ZNCE/XKuqkZaaymVzcmWGn3JZZ/zG7t7oxCvVQ8YzjOuXlp5PPMrl5x9hxV9
bbikKXmSQSCY+pFTh4csnX6KtJdtR68cqx8qXoXLc0qtKwVrLljXpQLKUTQf
F1QrzSQGzdruMZspjf8Aqyr/APGD7/8A/wAoWU2pfSjSGZb1rVg1TnTlKAr0
SmteFIWlMiY/Ke/LuqZmbH1byMFNrdIUDxBaha6rdmaT+FFNParUaxRTq717
I0rWg9kW2dXRzEmaRtymGeqz1nEUp00jbKLkKwdkVk4k4A0yqU7M4JSQNV6o
FJkMGJbVJeTjb1RLWkbjawn5tWOwnEQJh5xp7rPCrOsUFHk6caU+u5HPLl3w
4ddYppZUlTLUNV3VuCPRgSsuScvMCrzSKGtTSiu0RpFF7R2TdxbKmaZDMevG
CqL2jUyPonUuAYkZH1wFByzJtn6RpSRlWlR2wLRlu7lnu2wLMltXXAOGwDzj
ACdvHMwDY/wg0b3ZmA0bOcohSdx9sahyzhrysi7M/qMn66vcNsLSMWmzZTSE
UqcaknAGJbcYqs1Za0jWNmqBsOfVFZywZ4cobp2Z7DFc6GpSD4uWW/pgIFEp
NU0B9cRYTs2lNM5GtIKt+FpZ/mzjSXeC0g+2I1siVZ+jsz/k6tRzKCpPqyhT
WyM6L2Ks/NvPJ4Xkn2iFGwfkjZQP6U7hn4vdAuEqdF7DR4zjq6frACvUIJcJ
k2fY0r9Ewk02qqrHrgzsBx4nxaJTjwis2iUVUrsgydhalG6OuAuNigzxyJiN
JKnh0QDY7oAEzLX1hiMx/CCWkbTKPXuaBXbxgHbSAOam7XMbeswVNd+oPG2n
3RlRas7BlANq7ucUCa9Fa48N8EK5hlgMid8RRU/jBSw7MKwZoI5xvb8ANtN8
CiCaDARQ13fAN784iA8ZfBOAHHaYIFtm6oqUbyjtipSQpiKdOEBdYVHPJ0hp
S5vRzy9m4eZ6d/4hfG5LY/6CPo9r+nDnmqWWtSGm7pzeVXouojzd5y3g9Qk0
3Wm+KQfVHn9mnnWm1mtyFsr1QuomUh4JGACiSFesVj6Pb5b4fs45x5SWLaji
GmLxxbWWwf1RQj20jy9zjWf7umPDu7usQFeUAe0RxjwlM2dskzCryBlnshPl
YQy9nOyz6C0rnpxvYgA7onhp0mDiKOJxIx3V4GFoquSCFCil4bMhA1VlWbIp
8d09vcItlACrOlvo61yJoSfXFjJmkC7UlweYwVcTQRbKR8pLyryZJoqO0pKj
EtaHrLRHipS1uCUJETZaAuXtJ4c5xdD+sQIeBVVY661Wr3wtBt2YEwRfYlrk
PCxDVkU86MNxHh5Nb1PDM/d84d/GY+r04/xfhwy5dNov/ejvXHy5d23psm9o
tPKpXmpP/wDROMYlYeO2d+nS371H4hEaeq6Guuul2pPNx9caYlZ010aatuzV
vNoHhCWSVsuDAqAxLZ3g7Nx64SuLiNFCAmT/AG1fiERZesKReG8dsdHNX1ND
FtmgKl/XFtmg8nELKDqRCyi1R+qBXjC1o2pmVYVArldjKpdQxKI1sy4KnIqO
PQBtjNtUjbnpZ5YSCChVChQxBByoYsSkw83/ACmJCbbZA82R/wDI5EmW8XTW
P/dUj+4aPDxBHo6aSv8A63QKx0QXviBDAHLogHTzevKKIXJVh6usaSquZyPb
AUX7DlVj5tSm1do7IgoPWFMpHzaw4BsxB9cBnPSc0zXWNKpvzHqgqt0fyYNG
Uq71YwhXRaP2QtSOUzIo0uhbbOBUPKPDhFYp09LoCadGwRlUnHoFYtNBOPQY
Mse2pGjan26XhmOEViYY7D17DaOuKxIlE4+sxURmIpv5PREKLt2xUOlxY8Um
m/jAS65zeeEVnyl1i6eyCeR1OFc89wiCSvuiqn1YWnpjKnbQEA5dEBMnDryg
pY4+swArKiIJapyJBrnU4nEiCLMvKpax5yjsBNRBVrxRe8qoB474KqTDxQvm
BSt5G+IlgE6RneT1GBa8JguthONBQhXu68oLaPllxZyrkdsEtJy7o9UQtKJh
BaVgm+KkbILaJTyaJvYXqEj3dMC0gmGOPE1gWfWMK+uYKJSUBu8F4bdkBA4c
KfWOA74MpG5dV3m0p0iCnMu6Pq++IUAtOD6pioA82IiwyruiSsNWUPOEcc/Z
2h5tp3/iKZ/Zb/AI+j2v6cOealZv0Tf74/hTHm7zlvB6lJYob4JHsjzezTgv
yhzKXrbDaf8AIZSg8FElfsMfR7WKw/dy6rPsaVceDKQDz3SR+yAkV7cI8/dT
ef7OmEeHoU/aUlY8olc45dN2iUZqWQMgPflHHHCckRydqMTEoJtXzTNwOqKs
kgiuJhl05hYhiu6dSGsKWw7cqfnaADppWtPXHeO1mMbS2rITy5w3b1doNaik
eXjKm4gM/a8nJPiVBMxPKoBLtUKqnyjknrMdIwS2fOW0/J0VaNnvS7SsA6lS
HRXcSjAdtY1HSZtck5yzphCHUUebXhXHPcRsPAxznGlarcuhRGrQkbagDKM2
p5tTDDZffcDUu1iVHAfxjURasNWkyXklchIPzbYqS5QITQbU1vE9kdY6Vs2g
ldNJKcUG1JMqrAAKIKfS2dcXPtZhm21LzCJmqR4wzEcOFpZRK3sTlDlaZM3p
NY8mstJWZh4G7q2ReNenL1x1x6EykykkdKJTWhEyhyRv0oZhNxJPBWXbSJPR
WMnnVrKSu0pxSSFJU+4QRiCCs0IMfQxxrpOU8uq0WH9qO9fsj5Uu7oNMxTRS
0K/ZpH/dMYlYeM2Z/eEr++b/ABCI09T0JzmOPfGmJdS7OSssrUuuJDiklYbq
L1ytCaZ0qaViyOUs3RFmXmWzLFRlG1FQKqEmprTAJw2RFasxb7QcdYs2WdtG
ZY5rmpKUISvyS6sgE8BUiCOef/KSuVfVKz9nOyziPGBUFLG0YEJr01iWtOis
a1k2gU3VBSFi8hQ3Rq2aVbR01sOzpt2TmC6l5k3VjVnPeN421hZSn/6g2I5z
ZcPOL2BLZMLKbarWYl7NRaDjbrja6CjKCtQrtKRkIWUyB+UbR9Krvz16uI1Z
rXdSsSzUrTUm3VsTjN9uXKUBK3GVFTKmng4o6miioOAUyI5uOBNI0y7PlZxu
YZbQChAu0QSTkhKCccReUkrocq02RYZli/lLJ8NMV2SqPxuQlYdNYhHguT2/
MM9twR6cEloUrS9XDGmeMbhD4dwiKb3xsFu4VAjARi0AUv8AiYUiJSuMWkUZ
xUyKcnp+te3Vyi0kqs4y283dKRf3jPtiUQGy7Dbcd1jpvNpVWmxR2A8BBq3U
jMcINUlB7j0xFSJx8Y4DE9MFA4ptIONEj+awZZU5aTCkrbSb1cDujTGUsBvm
K9hiMDUrHhFQ17+JiUpr39IUF/JiocZDrgDT/ACCJRmOEGUo/rtxgH2itcMe
uCrDav4CIqQYxRJu9URT+yAq8uSFYg84VoBQjbjU1OBxhSLSFBSQrYcRshQP
+TBRXsBw2RA10HMCpioVxFfFygD5vHDDfjEVXXJNLVeVmcTvrEQPg9Gw03Ym
KUlbltWNqzsriIFIpwO3QGzQg1qcemIikozQ2JV10ioHlDyc2jxIxgLbbjrz
ZbNUIUKEqww4QDTTwbaLlaUoAf1a7YFqotBVMFYRFSJtJ0fWzgJ27WevDnH2
wNkrto6x5pNK36pJ21pWsFXJfE9EZlYa0n4wjll7OuLzjTv/ABFM/st/gEfR
7X9OHPNXsSbkGUXZtdwhwqGBIpQDZ0Rz7jpTl8q45OjmtO5OWYuSKFPPUoCo
USDvO09Hrjlh2s/+mpzcwzZs7aLpm5okIdJcU4ql5ZJ+qPfSkd8+tHSioYxi
3baOSKNU4pPzayClpdAbmFAQDnSPBN5Tbtw43Smzpiz7S1czMqm1uIDgdVUK
oSRQiqqYjZHv7efFOOXK3KTSbTlJezOe3LNJRygigUtwCiUjxubhWOfUj05t
uOGXblnps20HJZJNwAKSVZ0KQfbHo6WeOcbSxOLbYnnLHsZLuKZt9Abl+AoK
q6ge2PLjh6nV+zd1DLsVVHdaokvuquhRxNMCT0k/zjF7mamjpw9QblGJqQ5L
MUcQ4iixgcCPbHk3+O26eWpddsG1HpdRKkNrLbo8pIOChxpiI+hlhGfTjKHH
iXf2NPhbD61KusMglS/1QKk9FI+flEznq7X4cTaekExbc6kK+bkm1FbbGyiB
Wqt5NKcNke70vT6bnGVuw0MQZhtUwvZgBHgt0iHnttJSi1Z1KBdQl90AcL5j
6vT+Rxnl12jEwozqEqNS4gHtSI+Z1fmdY4WtPbcXJMosyWUUOvpvPLGBDVaU
B4kdnTHbt+lv8X0ZzlzWj0tRxCgKvOZHyUcOJ9kb7jqf+TCHoD1ltztnOybo
vX0EA7lUwI4gx5sMuFeQlJSSk5itRxEfWmfH4cfd2+in96Pdfsj4+XLu3dN/
8JT/AOwn/wCRMYluHjNnKSiel1LN1CXUFROQAUKmIr1rR9yRs1tbr8w02k4k
qWkCnbGmXOv26NIdK1qlf0dtjUMHaoBaSVdZOHCJa0j0x0tmw94Es1Zbbao3
MLRgpa9qAdgGR3muyFlNfQyz3EqQ22fmmQK7iraes4xUYn5V2Ut2zLKAxXLC
9xotUSVhV0TtF6Wlm7iiKPkA8ClJpFgl2enOjot2x0z0ugG0JVN8HatABKkc
d449JiSQ8ysJwCb1KlXOUJ1YOy9eBAPSRSBL2DR95DNmnWm4hhJKycgkCpJi
suGs1KZy1HrX1d16edUthO1DZOB4KO/d0xIWXcsSYbTzjic43DlMiuNNqvJH
OO2NQky80/KMq9bLR/8A1k/jcjEumHDq7EH9mSX7hoj0BHowJXtns2Cm+Nwh
/GyMVT7eJiB6erACJYFXNGfXFsQqpv4xWQLz4ZCKio+rDPqhbMoENl1YTvzP
CJZDal0oQAE5JyEHSlrI+6DVjGfTiIimemEsNaxZwyAgzbCnJtyb20RsTs64
05zkoqGJ2nbBkrgHVkMogi9u/OKpYb4BznwEAtnughwOiAkAx6IImy6fXBlM
kY9OMAWr7h3wVIkQVKn1xAWHZlBRZde2AB4tJSVKF5Qoababv4RUS7YB/wCa
RFIg0wpUZbBEGetM00svUxNTsVswCjzcAcoqLku644LziLlaXRiD11gJ9sRS
2eoQQ3sgpe2ARVx6IiANNwMVA0a8kb90Alas4UIHugInmW3U3b2eBBGEEUVW
Mj6t31iIWiVY7oPNKsNxrBrY6bNmkHxldlYIvS0rqjeOKztPugy0pfZGZdIa
8n44jll7OuLzjTv/ABFM/st/gEfR7X9OHPNWsZmTU3emGQ6srKQVE0oAnZWm
Zjl3GeePyrjDrfkrZUyzRTGqUcQtskHuPXHDHuc//TU4OUtBu0tHp3kxcK2s
2r1ShaK7jkd9I9UY4deLhn5XT6NW41MFNOYa0cb3E5EbwY8fV6WWE1DcTbH/
ACif30jjLoP/AGXHs7OPFufU5ZljOKQ5L6vxy4SejAD2R5+6y2mnTB6KqSYn
bmvZQ4sAUKkpJHQSI88ZZRHhZcFpk7W2XGAeZLJS2kcaBavWY+l2+Pw7e7nm
isdnWzcq2k5Cp6yTHh7nL/LTphw9Hl0JSsc7hSOMx4tYlwenkuGbcUoDB5tC
68aXP/rH0e1n/HTl1PErVkvOzej0zKM/TuJLYFaVuKBpU/q4RzyiMOpaxPhm
SdhzjQWp5FxbgCEowJoSCThllSJ3HXvGlxxej2BKps+z6LISAKqJwFKYkx4s
eHSfDye1HkTFoTbzZq2484tJ/VKiQY+x04+B555djoYwlyevq+o0inoiPldX
53eOHMaTTipy25x00wcLaaZXW+YPUI+p0I06bhnPlvaJo/tAoV/lpoOoR8vP
znLvXh30ttjP0SHi08m7OTCdzqxT/cY+vjx+HGeXX6KH+1Hev2R8nLl2bmnC
qaJT/FKB2uJjEtw8ZlGw/MstKNEuLSgngSBEV3tm6HWLarakoStpY+uhZr1h
dRGmWbo9Z6rE0rdlJj/ISaKyCklSClXWDEpbDL6K2i3abk1MBOrS4tSTeBUs
km6oAXt9cYUW9J0Zs/kkmLwotWJio8+/KpOMTNuNMtKClSzIQ7TYsqUu700M
ZlYZ2jg/Nkf+QfwpiwS9ilWxqW+KRh1Rpl43pzYhsa23QgUl5n59g7MTzkjo
V6oy1DYb0j8K2O1ZbRUh9/8AvJylAGk+NQ73DQeqKS3NHJPWOGZIohFAgbAB
gAIsMS33XaRuHKVRx1R7405W8609JNqtV83T+NyOeXL09Ph1tlPNM2RJuOqC
EBhqqlYDxBHowhZD4cl1H5hl2YAyKRRPTUxqJTYfhtoH59h9hOQNApPSbhhB
s0GXm3ka1lYW2cljEf14RVHXcMtu2IKk4o1uDZiYsMSrBRSMNu2LTJa9eO2k
KLV3FFXVUwFmUbupvK8ZWJHDZBV9s0A4xGk6V+rGDQlPJSkrWaJFSTwiUMKY
mzMuXv8AK+oOG8xq3OUa1/wEIZRJzJhIJXinDLbtgIIKWzLPbAL3ZwC92YgD
H8iDKVIoOmKiVPsx6YIlSYKkH9O+Ioq4+oCEBKdpUDthKBDm7Zt2wEqVYV27
IKdoXvnDl9XviAXpm6bqfG2n+dsEtAFnfvNIqWNLyxtpAtKJnDnYkxFsSp1p
KkhVedkcxXcYi2kEy0r6wiljFDlls74FnP8AQRkDXP1GAzJhS3H7yGyblUgK
BADlcFCmdfZFQm7QXgm7rTlUHnXq0xGyufRAWGX1ulfMuoTgDnU7YIlr6oBv
60ihQD5RA4c9UA+sJziCyxGZahsSXjiOWXs6w8407/xFM/st/gEfR7X9OGM1
SzE3mm+DxNf9qI83dct9N6iy38y3+yPZHlbc3+UOUCrMl5n6zToTX9VSTX1i
PT2uXxsZ8ONsF5TVotU+vgR6x6xHq7mPgY6fLV08VetVo75ZH4lxntfkOpyp
WSn52TPT+Mx5e6+d0x4enyY58cJah5VpH/fc/wDvl+2PrdD9Nxy5X9G0/wBo
S5/VT7I+b1/1XXB3zQ+cEcmocb+Ub+85f9wPxqj39n8rl1WNZLrqA2luuLpA
7ExnvPmawekNtyknK8pmylCEJBUtWUeSInLjlqZpicvVpM7qOczZZNEtJNFv
0OayPFRh4oxPVHbx0/8A6Z5cTbMoiStKalm/o2nClIOJpsFY9/TyvCHKeXaa
FpuuOO/VDSa+iI+bnHxy7Rw4FSryireSY+pjx+HH3djov/ejvX7I+PLt7O6l
PrRPovs8btH9Pmv3zn4jH144/DhPLrNFf70d6/ZHysuXdvabpvaJT/7KD2OJ
MYWHjVm/p8t++R+IRlp6joTgp/8AnbGmJT6SWDr7QNptK56mAwUU2hYWFV6B
SkC2rZdloRLoW744FSdkBg2vpbMT7/giwHLqPFmrRpVKBtDW88ezeCuR01sS
WslyT5OFhUw2pTynFFRWsK8Yk7TXHZGZahHo1+jo/wDIP4UxYSXssv8AQt/s
p9kaZc5+UizWZzRx2ZWAHpIhxpW3FQQpPQQe2MysPLdHn0pnNQvATI1YP61a
p7ThEaesaOKTyLU/WRnvjpDlK1MJ4RuHKVBzONQ5y8+07/vVr/x0/jcjnly9
HT4atlsqflJVyZN+60gMt/VCQkAGm09MenEylpfyItOZ606szlFIDKutsv65
lSbhIEy2nxSk/WpsUM67YzLpEttargN7xU4k9EIalWaTeq6vNdSBnhsisBcb
SqLZSu4ymtAYWzSpdq4EHbgeiAuIUK0T0CCrKFeqIqVLmZ6hvgrJtqfVeRKN
5VBePsT74CBs4cYMSI/yYsIdvH3wkJ44cMz0wFegz35CClALI0gFTjhtgDTn
RMGUya9mcVEycj/JgiVFaQUXtiKBSrvfCEQpcvKr1wlEiDePAYmAnHzqqfVG
JHDYIKeaf1KMPGySPfEW2drOd6+uCUK/xwipQ0rH1YFBemNXzR45iCLW4ZxF
OlcVEiXlJyMBImddTtrxiCZM/U84QEom0K9sA4LSjeoNpHTAIJSkUTgBkIBb
YBUihdEEPECr64B0xFXJeMy1DWk/HEcsvZ1h5zp3/iKZ/Zb/AACPo9r+nDGa
pZn0TX75X4Ux5e75dOk9Xl/oW/2R7BHm9m2F+UKgsEcXkU7DHbtf1GM+Hndk
pUufYSnO97ATHv63yOWHLX02QW7SYSrMSyK+kuOfbfIvUV7H+kk+k/jMeXuv
ndMXp0tzVx55ah5dpYyWLenUn6yw4DwUkH2mPrdD9Nxy5XtHSlDss7vFOsKK
PdHg6/6jpg79lNXBHBYcL+UR5K7ZQ2n/ACWUg9JJPsMfR7OP8bn1eQ6J2eZl
1pZNEN1dVXDbTsoKx5u4yvqU6YcK+kFuLtyfTLtkiz2lG4E4XgK3nOmmW4dc
d8MI6ePn5nO7dJoYzrXVTNKITgkbAN0eHKby88uuPhx2k6kqt2fKTUa5Qr0Y
GPp9H5IcMuXVaF4zCk7C0mo/2iPB1Pnl2jhwswjVvuN0pcWpNOgkUj6mHH4c
fd2GivOn1ubFAkHgRHx8uXb2dzKfWifRfZ41aBrPTJ3urP8A2MfXjj8OE8uu
0XH9pOnp9kfKy5d27pp/hKf/AGE//ImMLDxqzf0+W/fI/EIy09Q0Kzf/AJ2x
piXWoTfVSKjhfykaVKZJsOTUUmgM44MMCKhsdINTww3xlqlbQ+SuPS8rTYHH
v21gGh6BhFDflbqJ2z0DxQyo9ZUO6JKwwdHRWXR+/P4Uwgl7BJF3VtjOiR7I
0y5nSW0WrWthqxVc6zpWjloJqUhxxQ+aaJBScPGI7oy08+0osZVh2uthqoYV
R6WVtuHECv6pFK9cQh2eitsJdbbmMr/MeH64z741DMuweSFpqNuUdIc5ZryK
GNw4y8607/vVv9wn8S455cu+HDbswXpGV2DUt4/7RHp6ceGchziZpTATKVvl
WJwBu8Cd5i2Yp7NZVcbTN89f1ycca4dMWVXZlhJcRcABUCkgAZZ1jIlnHMm6
biegRpZkPKkKGV2lABmIUzZ7yFZHAVhABSf4mEird+cvboIQXsyG2AnSobNu
2ANyaRLS7kwoYNpJ6TsHbElpzN5bx1izzlc4njBV5k1AptisrAb39ZhLBV7N
ghABeOzCAiV/QQaNd7BjWKHA/rEkK76tnCIg09gionRTGkVlO3TdASBNf5pE
aMcoCFfi+0xZRTVM6o/OC6nYdkQW2XEqRzOdeygLqE3E07enbBWRNv614n6i
agQAIP8AExAd71QBF0ITe2D2wRUDl6qtqtsRRpXu7YAr/ZvgEFwDhX8TCUFr
P4QgPrIAw9x6BASJmF78oIlRNb+2AmS8hW3KCST8y3LpClmiFYVgQlCgRhkc
oBdUAbYrEkhfl0xzl0hqyqaGscs/Ph1ebad0OkUwQa1S3XpuDCPpdrejlnKG
wm9cgJGbbtSOBAp+GOHeRF8t9N6pKCrSOCR7I8fMcusvPdPbcan5xuSllXmJ
St9QyLhwNN9BhWPo9n0ajbJxzytW0Vsl16YQ8U+PQIP6u1XXkP6Rz7vq3NQu
GKX8oabtstp3SyAfSXHXs618ynUhXsJm+ZZexJUD6Uebuq25a6b0VtQ8ZPbH
mactp9Yy3227UYTeLSbj4GerzCuonHh0R7O16lMZYudsF7At/XbUFp/ZOB7C
I13fTv4jB6XZywpkOrwonEx4YmMvDp4eXWo8q2bbmXWjVDrhorc2nAE9Qj6e
M+n03DL4pdVZrJYsO0XEJpRhaUE480II9keDCdup+XeYqHDSbiGn0KX4mIPQ
QRX1x9LqxeP3cMZeg2FaEpZ9nFEstMxNuA6hhBBUtVMBwG8nIR870Z2+N22c
DaEtOS00tE4gomCStYNDio1qCMD1R9TGY1+Fxl1Wj9oMWZL8udWF1ShCW0kF
SlUAoBvj5+eE7eXTHJlaXWfye0VTbf6LOkuIP6+GsT2msertcoyipYyhd0Zt
BpSkN3giYTQAZXwBs48I8/X6MxPwtY507g2gzIybk1MKCUISVHswA4nKPPj0
5mW9njzi9YtTnlkk9ZrH1a1xcJny7RuelbKVLtpAefmyVqKT4jdK3uNY+b6e
3nJ22XtJZszOhc84rm1uBP3qI8+UezpDyqzf7wlf3zf4hEWXqeijfJ9bfwvZ
dsbiXOYddLUz7Ihi8Ft111+155x3x1PuFXDnEU6soy6O90PtSx0JXPvzTbKk
pGtbWQFJIzoMyN1Kxq2ac1pvOTtqzrdpusKZkHhq5ErwKm0HFRFagkmuNMKZ
5xmWoFofMWegLTOvoYDa9YL5pUEAGm/LKLaTDvk6XSsvYT1qqTq0ArRJIVgX
gDRo0zF7PgMYtpTm7FlXVPo1xvPvOF6Zc8p1w1PUMohLa/KBo+J6xOWN/T2e
C50tU+cHqr/WEkPOtGbTMnN6parrL9AScgoeKfdCGnqNnWstxvUlNXE4AbY3
EuWUDeRMOZkN1zu59sbcsnnGnLKWbVbAqasJJJP6y4xly64cNqy1pMjLJVUO
BlvmHDC6LpA2g749WEpmv/yBFpzGy064oBO3q7YskNFtpDIKq1O1XDhwiOsK
bjl9d7fkOGyK5yAi90dkLQJTQbMMawgKq9hNBCQkG8FXtkFRKVRWWWzZAElz
Z1mAo6RTl1pmVrgr5xfRkke+JLpioy6FOJSlNbxAujvgS3GGEMthOatp4xXO
QO+3ZCWUIcr1YU4QgIqxgGz6OyDQSMNntihU9WZ90SQXTBBjPLLZsjSJhlTr
MRlZRlnwgJMKewRGka1Y09UAF29FlC1YOzPCmeEQPLyrDKrzaKKOdO7ZBUzt
5TarpoSCAcsaQRgAjKowwI21iND2dEQP/NIqI5lznBsfVxI4waBeiB7/AHQC
vYewQD3/AF7IBXoSH1kID6yIh78AV/CCCDnqgJG1Xj0ZxUkLyuVzKJf6oxI2
UEBsbKboMle7oCVv+gjMrDTl6Rzl1hNayJ56TDdmzCZZ4nFahXm0OA3HjGcf
n8tuLc0Gn3VqccnELWokqUoLJJ4mPdHdY4TTOtp5HQ61ZF7XS842leR5qiCN
xG2MZ9fDP2SMGxNSWlEzLmX5cw0hWB1SFBVN1ecR1RyienHs35ZMroS1Lm9M
LMyvYgC6ivHafVGs+58VimjrJKQdYk3Axdbmyk6pShVKTsqBsjyx4m8nSPDk
pzQi1pyYXMTM8268vNZCu7AcI9nT7jDD2cZxTSOjdq2UKJmGnGK1KLiirjdO
FCadHCMdXq4ZezUYtyxBMapev34CPPDTSvChSrFJwIzFIkTUpbkbS0PuPcrs
d3UuglQYV4tdyTsHA1HRHrw69xWTOiCYGlU2xyR8tykuRRxSLtVDaOYVHqwB
hGXRwm5PI7LsJLI1aBgaFxw4FR9w4Rx6nW28NRjTqpdphEuqVI+aWkpVxBFD
HOPh8rduCtDQufl3ymWKX5c4pWSAoDcoHb0Vj39PusYj4uXPVcsWxVyT4PjP
5KUmt0CuQ7483W6m8/ZuIbGkGjaLb1brT2qmG03OdilSa1oaYg4w6PW9PlnL
FiMaJOybl55wOrHiBFboO812xvrdxGXBGLpvBEvOWXyGbGGBCh4yVbCDsMcM
OpOM+GpcjOaE2iw6rUrQ4yMUqJIVTiKZx7cO5ivic9WvYdkkENzv51ShIdqt
IP6oXh1x5er1bn4HSI8My3tFpzwo6qUZSmUcotKqgJTUYinTsAj09PuKj43P
XyuWNo2y2oFXzjw8ZzEDiEj35x5+t1fU+VuMVrSSwLbtZvkjc2w1ZqSChkJU
FGmV841pwoI81W6XTnB+TWeBqJxocaKhRs3ZWz7ckGlpmJlEyDTV3UUUDtJP
Nr64tJbrLLLiZdvW+ORiIUluJ0y0FmpydXaNkpSvX4vMEhJv7VJJoKHM4576
xmmolk2VoVNS7wetEJqjFMukhXO2XiMKcBWsWIJl29paPItqxORuq1TwIcac
pW6sV2biDSLSW4n/ANNLRQ6UvzLKWti0XlEn9khNO2M01OS5MaB2xOIbbdtF
DjLIusoIVRCaAYJGAwEWk2achZVrWepDUw62+2ml1SEkLqCPGJwIpXZWEJLY
0os60LYk0SspPcll1JIfbuVLmVAVVqBw2wkhxavyZTv1ZxrrSoGFLbcsSzbS
kphtqYd1xRhrACOaAKAk5njFYmXSvGOjlk8y/KD/AHu1/wCOn8bkc8uXXp8O
qsllpyy5LWgOAS7RSDvuDLbHpw4JWkyrAoQjoFTSNQidKKc3BI3QVFMuc0JH
1vZFhJVsVYnI0AgwZRr0ZCAAkZdVYtIBWXRFoEyoC8Nt3OIsoHBzscjjSBAU
c5YHQIkKqzsuZy0ntWLxQQ2DsCUimJ6oS1bRlLPEsnO8s5n3dEVlMqtIMq7j
SjnBFB86pwUwrs4RGkyVX8dhpFCVzujIQQ3DthQbHZshQLZ6yYIlTx248YqJ
k4wRaQn1RJaOrm5mu0CCoL1YIJI3xUSCIDFT0YUgoV84eoQFR6TYeHORjleG
Cu2JSWqOWe+j6JesA+qvBXbCltX1mqNHEqbUMRey6jEVCq/evKGCsQYKGsRR
e0QQ3X1QDX4BVgFegHvHq2QCv190AWsgHvwRZSdW1e7TwgixZLfjTK83Mt90
RUlowYP7RAG2qhzhKwuMvRzl0iV1t2sYpq0ySIlNWmT0RKaHhuhQfm7oUHvR
aQNREpbI03QosBps7IrKJQgisu8mJS2rLcG2FNA19MoBhMwB64qzyiUob6U+
KM9sKDiYIOGyFIu6xC0hY259MWmQ6wwos5VezhRZJup8UUhS2dXPFFZQSyQE
o8UQotJnCiz0SM4UlleTuhRYgqFFivwosGrbrepjvhS2kvQpAqUj60KWwazy
R1wos1EnPOFJY7whRZrwiiJSwMhCmVN12NwxlLzrTw1tVr/x0/jcjnly7dPh
11iD+y5Kn2DVa/sD1R3waaFd3QNkahDY9ZzOcBUeVfNTgnIRYYlGTXxYqErx
f59UAFLqcuMLRGrP3xbFaYmuTDW0vUIw2mI1EJbwcF8bcR0bIEwUr+lIT114
19sSBstSqU1CU0riT7YS1qPU8c4LqFcvhUbKDdBKVHwlpBcXkK1MVinPPPCY
XrMk5AcIjVJErrlsiom2e+CF4qYWhJSD0wsGIImRFRZQICwkUHTElpA4ceB2
+6CB2+zZBBD24GKJNgiAs8tkFLZAK7h64lpQdXXvhaEW0K8YBQ3HGCqk7KCY
bCUnV3a0NPVTdBWU9KTcv4ydYgZqR7xEaV0uJVgD0g4GCniKYq/hsgBr27YI
RMA171QU97CAV6ggiVlOscCesmCLL/zikMJ+vQdUGWw0kNoCRkMBFYlJBCgE
ICVDmMRbXWFVjEukLLk5JypuzMw0ysit1a0pVTfQmOcy6RC6ytDqbyTzRiTs
iW0dl9h8AsuJdScQpJBTTgRnCw65mWaDl55CdRQvVUkXK5XscK8YWGQ4h0Xk
G8Dt2RbQ6lIbQXHFBDacVLUQEgbyTlEtaQN2hIPKuszLTqsyG1pUab6A5Qso
cxNycsQmYmGmSrEBxaUmm8VMLKEy6xMpvMrS4g4hSSCmnAiFpSoZ6zHFatub
ZcWcAhLiCrsBrCzUMxLoCC6pQS2kVK1EBIG8k5QsUUtJd+jIXXEEYih2iDSB
T8mhzVcoa1tSkt303rwzFK1rAWOYGi6pQQ0nErUQE9ZMSxCialHlXWn0OkZh
Ckq9hhYNy4yE6xSUX8EBRAKjuG+FlLUrgDUjVZlRwA41i2zQUz0i6vVtTLTq
zsQtKj2Awsob01JyxuvzDTS8wla0pNN9CYWUNt1lxsupcTqQLxcqLt2la1yp
TbCyhoW0tsuhadSE3y5UXbtK3q5UpjWFlH5RLJLY1qauirYqKrTnVO8Y5iFp
Q5iYl5ZIU+8hgK8UuKSmtN1TjCygMzEvMirDiXRvQQR2iFs0lCKwsQKtCQQ5
qlTTOtBulvWIvXq0pSta8IWtLBdaSEXlpTrDRAUQCo7hvMLKByyX1imQ4kuo
peQCCoVFRUbKwtaVZi1ZRtwtKmGW1jApUtIUOomFrS18whrXPPJQjAFxagE1
6ThC0oDUzKPqusPtvUpXVqSqlcq0OGULKC5PSLLmqcmWkug0LZWkKqdlK1rC
ylpKpZIQp1xKA4oIReIF5ZySK5k7oWUd9UulwNaxIWReCKi9drStM6cYllEr
VAXU0rtEbZpQmUMq/VVGoc8nmunWFqtfuE/iXHPLl26fDsLEP9lyW/UNU9AR
2waleHqEbhBDKmVKV3xBXVLYc09Fc4sMoVNlOzPbFRGoj+cYUiKv9Y0iMqNc
BXYTEVnWib7iGd3OV07IjeJpd4tG6MU7OHRBZaEuv59CjvoTBh0zdCIjriK5
3CIqCZdalmy46oJQP5640y5O0rQcnVXUjVy6aEJ2qO890JZZ90pxTgd+cIVM
3MBPj9Z2QRaQ4hfi4wZodf6xUoQzwzzglJEpJz6zFRZZbx5uzblBFlK0J8X5
xW3ye2I0LiegboCNZ9WURFa/6oqJEOe6vTCRMk9u+APCIH/msA3sgp+iAX8m
CGpu7YAVJglKkxISz/0iBXfke2C2znbJdRiwu/uSrvjLWyg5rWjR1BRTbmIN
WYKrlSgp2wU1f6xFo1fXBDXh/GAV6CrskMCuKxK5ZretcW+roTGmJag4dsGD
wDQDxEE3nwgrSkxiOqOecuuEOZ0vLCdJvnpVUyDJtABLYcCDfVzjXIcY88vR
DfemRI6JTsziheoUlJ231jVpp1qgQzNCyuQmF2c4T+auuMpHA0cB/wC8IVFp
2yGbZZbQtKWrZbQica2kyywpJ/3A3BEHVWG1dkGyTVSsSY1CSj0s/wANWn+4
VCSHDSbkt4TZXKSipAolUIWh1AZW6pSwS4lIzTzaXqxlW1pO7Z0vbstMWozy
mUas+8pF0OYl5KAaH9qKD0EamWZDUPJu6ltwFOBxK1L2YZGA52WlWGbKsWbb
aSiZW6sLdSAFKFxZxO2IrrreXf0Xbl7xDloOMSqTt+cWm9T/AGgxWVTQVa1M
pZd8dpJaI3Folv8A+sBz09JS5k7cnS2kzLNrLSh2nOA1qMAd2JgrXtslWgs2
o51ax/5kQkV7Jshs2lyhlIl00CC0kAJwJNcIQkj07V+eyoQSPBbInF0y+ceb
boepKj/WCtqzmlWjYs3JhVHH2nGQs4gFSSgE9sByklJtS87LS7rIkrSkU3H0
pCQHUkAa0KHjA0z2HOEJLc09kpUyVnTRaQt9U4wyXCkEqbuuG4TtTXZCSFmV
ZSjRK0iBQclfAGQADSqACApWO4V6JT4P1bOVT7gwHOyE+6pyyZdw0mJRtwcd
W6ltxo+iqnVAdPpi029P2Al1sOouThU2oXgbjaF+LtygIdC+S655MsTqitZC
CLtCTimlBQDKLDOTtGroXFSHm1r2a3IT78vOspS5MzSpmTnkgG+Cq9qioiqV
Ddt2bK5dKb1rNrf0b1zXOmJBSZ1o8WjVX/WsCmfojrZyfcnFV/Oll5QOYSTR
A9ERLKBpNY7cnPzhtBhJlrTWkys+AKtLCRVtRI5hNMDke2gdXZUjLzljuNzS
EzCTU3HACkEDDA7oqQwPydSbC2EOJSlKggFZAAKzU0vHbSsCWdaBlk6RWmly
TW84ZpNyYDYUlvmJzWfFNcYitXTttxOjtmcn+mM6zq99/VuU9cLGCq2F2hpE
Z5v6DkqW2d90FBV/3UYqS7l54FpB23Qa9UdsXnzZzrylHPKNQ5S4TTZVbTa/
cJ/GuOWXL09Ph2FjH+y5L9w1T0BHowalfx6hhTZGoQfsiQBx6hs2xRCc+jsi
0yruY59eyCKSlrOAyGyFogMxcvqINxvMg4VPCJasxKluuKX1xHRLTPsgiVpw
t9eyKS3JW3WEIuuJUFDDAViJB39JMLsu1zjgCrAdmcVq2U8qYmV6x9RWdgyT
1CKxZakQhLAZbbs2wlbDydBOXVsgllyFB9u6BYxKrpzXThsp3wS0rcu/d8fL
ZSCWnblna+OSRTAUEGVlphNFXudTChxHdBVhKRTLPAb4Kc0ApTEbICnMK/pB
FJbhr0bIiiS/FhFplZMGU6VAnogoxjAFie6Ipx/ACAfGsELYeyAHZAMUjdjB
Eak/0iohcavVChUZU2QLZsxZbCucirZz5uUZbjJnuSU01+ukbdsRuMlbWY4i
h3RGirWAfFUCWhiltDSc1YARWGzLt6psNjZSsacpTbPVBC9pgHgG/mkRDpOP
RsgrQlXLpHDGOeUOuMqdp2Y/NW8meBTydTKGiMb1UqUs1FKUx3xxp1to6QWc
7alkiz5ZSW0KeaL5JIOqSq+blAedUYVw4wmGoll2bo7M2daq3W3VOy7xbUC6
orcvAEKvEjEHZjCIWx6RaOzVpTM9OKW3rrjCLMPOJaDStYoqwwKlbq4RKLbN
i69qVuPYEZCNRDMyktqWctKyJyRZKUuzDZQkrqACd5AJp1QmFiXKt2Bbbs+y
7PmWusMhhHJr+QWF1VrBwOXZGaW2xa9grn59L6ynkvIVya0437ylVqBSlB01
rCizaKyc7ISypaauldy4VpqUkgUBqQk5QotgjRu32JeSk5hcoqVklKUkslwu
kqSoY3wkfW4RKLblsWNMWlK2bL6zVS8qsuvlCil28EEI1RAVtJrUjhFpLQ6O
WPM2TOui/rJdTiltqUSVXFUwWSE86sKLZs/o/bf59LBctyCfnVTqqX1P0Kws
JySn6o74UttKfsp6a0besptSUPO3aFdQnmuJcxoCfq7oTCRLMkJO1kWqJmdU
zS6EXJYruYEmpC9uMIhbHb1hPWpPzs048UpdaQ3KJbWQKJQa64UxF81oNkKL
XbLl5tFkzUkpQQ++wptLoJAC1oKLwOdKmu+FFsdVlW2qYkuWql1iTbLKFslZ
WoUSKrKxiebnhCISZdDpLIPWlZkk0wU3paZaeXeqOa2lQIFAcedw6YTBEpJe
Uc8AzUhUJdmGXW01qBVxCkCtNlTCktTsqyZhqxZuziU656VVLpVjdvFst1rS
tKndWmyFFsx3Rh9E1Zz6SkuS8siXmKVxU2AApOGI2Y0whRbat+RtCZmLLnbO
Wxr7O11UzF+6dalKP8sVwod0KLZ+jshOSUy69M3NY4txxervXauEnCuNMYsQ
mUulZc59TFpIlyFpWBbrmtaU7Luya5ozSaqcLwTfqEiouigwp64zTezck5J5
NlPSyiNY80tAKsqrSQK8MYUmynoxZ79mK+epzEJRhUiqQAaV2YRKatWtyzbd
m12kyw9LLkbQWFgOl3WIACcEgC6MU8YUW6ew5dcvJuNrPOcrQbMRFS1HQ2x5
mx2dVMlJUlIQSmpTUHZUA+qBMs+0LCtxu05yaYMouTm3g7RZcLwTRKTQABNa
DbWJS20rWsuctGzrNQgpS5JTjM05frilsKqE0BqrnbaDjCi2IrRB2UeljLU5
O2ypsg1v31O62tKUpTDOLSW6hyVGrCdyQD2R0iXHKGZMSahlG4cph5/psgpt
NoH7BP41xyy5ejp8OuscgWXJ/uGifQEejCW2gm9SpomtSTthbIs+CRCwxocK
9MLEZ9m3OLa0hdB4dEW2KZ7iFIqaYCuMLTVnznzbISfHXiREtulVs3TdpnSp
2xLaTgKOQyi2g6JSBjU8IWhw3U7tleMLRcQy2lAG04k8YWz5OEHDdjUxbPIg
gngmGyVIlIBw7YbFSZtsV6MBDZKlJd6Me2Gx5MEndlFtKlK0KeNshZUi59/m
qw2iJs1qkT42G3MQ2KTDAU3ZmGy0iUrd/JhslKryTT1ndFtKUXGHSa5A1JO2
JbdAS05uwELSlltSk4HZnC2dVhDgOXRC2alOlzo6IWVKRJiWtCGeJhZQvfnC
yi2+6FlF7d8LNTH2Qs1AfVthaagI6q574WmqFaa9AhbNSgWj+MLb8qb0u2vx
gN1YW1cqLln0+jNOEYbtAGJlCvEvU2wVq2eytbuueTduDmg741bGUNWvrzi2
5VIv5pCypL3QtKk8LKkMS1qTpvdULKlO2pQ6ozMt0somDGWllubjLablfbAL
lFYBa6KCD8A/KIgEzcCw8sEABm6wQuUwC5VFALnk74Ci9aA3xBW5djBo/LYI
ITsAYnYIlbntm+CDM5SCm5bAFysmDIuUGAYvdkVCTMQEwmIhci5RAuQ62Bcg
1t2BcnTOKSc+ndBblOm1KYKgXKyiebXtERu0vKBAIvCAjUuKyiVjGrZp5p+U
YAWyzTzZP43I5y7Y8K8vLS5l2SWUKUUJJJSNwzNI7dNpLySWp9CjpujujVIf
kcr9ij0U90KDcklqE6ps/wC0d0KD8jlfsW8cuanuhRZuRy/2CMMzdT3QoPyS
W+xb9FPdFoLkct9ij0B3RKD8klfsUcOYO6FBcjlvsUdN0Z9kWkIykrsZb9Ed
0KC5HLfYo4c0d0KCMnK/YIr+ynuiUWXI5Wn0Lfop7oUWXI5X7FHop7otFm5J
K4/NN9F1PdCiz8jlfsW8cuanuhRZuRy32CMM+anuhRZcklvsW6/sDuiJZcjl
vsUegO6BZ+SSv2KOHMHdFos3JJXYy303Rn2Qos5lJXYy2f8AanuhRZcklvsU
eiO6FJZGUlh/kIr+ynuiFlyaWp9A36A7otFlyOV+xR6Ke6BZ+RytD8y36Ke6
FFlyOV+xRjlzB3RKNjcjlvsEYfqjuhRsfkkt9i3X9gd0KLPyOVp9CjjzB3Qo
suSSv2CPQHdCiy5HK/Yo6boz7IUlkZSU+xb9Ad0Siy5HK/YI9Ad0KLOZKV+w
RX9gd0FsuRyv2DfoDuhSWXI5X7Bv0B3QosuRyv2DfoDuhRsfkUp9i3jlzB3Q
o2NyKV+wb6bo7oUbH5HK/YN+gnuhS7FyKV+wR6A7olJMlyOU+wR6A7oUbH5F
KfYN+gO6BsRk5T7Bv0B3QTYuRyn2DfoDugbFyKU83R6A7otGxcilPsG/QHdC
jYXI5Tzdv0B3RKLPySTz5O16A7oam0nErJebtegnuiarZ+SSfmzXoJ7oalm5
JJ+btegnuhRsXI5Pzdv0E90KNi5HJebt+gnuhRsfkkl5u16Ce6FGxzKSXm7X
3Y7oapZckk/Nmvu090NTaS5JJebNegnuhRsbkkl5s192O6FGx+SSXmzX3ae6
FFyXJZLzZr7tPdCi5Lksl5s192nuiUbFySS82a+7T3Qo2PySS82a+7T3Q1Ni
5HJebNfdp7oamxcjkvNmvu090KNi5JJebNfdp7oUbSRlJLzZr7tPdCjaS5JJ
ebNfdp7oUbSfkkl5s192nuhqXJuSSfmzX3ae6GpclyOR83a+7T3Qo3NyOS83
a9Ad0KNz8kkvN2vu090DY/JJLzZr7tPdA2Lkcl5s192nuiUbH5HJebNfdp7o
UbFyOR82a+7T3QNjcjkfNmvu090DY5k5HzZr7tPdCiy5JI+bNfdp7oUbSYyc
j5s192nuiUbB5FJ+btegO6LSbSXIJPzdv0B3RaW3P2+y01NpS2lLadWDRIAF
byt0c5h1iWnJ05K1TK4mvTdEdsBPTK8Ths4xuEd1bEi683acvyRplkKlkST2
qCMXHEJVzwOMefGePP1tpgHRGcBV+cyxQjWh1YWq6jU0K73M4x19WPpKUlk9
Gn251tTr0vqGFsEqKlXXA8apSnmY1A2xmc/Hv7lAtCwJh60HS0W0tTD04Wk4
i6JZRvAgJw4Uixl4/aI/koyNG3kpbcdmJcJVqVOIClaxKHyAknmU2w3+0+/8
FJJjRdRmppDE0wiWYdDIU6pXjL8VJIRnvhGfiPE+YKDo1L3bQnGLjbz6Jd0N
XwFt6xKk0UaigGBxMOpPiP3IDpOy8h2VW8w3LqWyAoNFF1agTVYDew1hh/vy
S0LUebdlVCXlmVyM4lpuVfaQkKadF2+l00qDWsZx58zNxyqgrRKcDzbSZiXW
VOLYJCl0SttBdUFVRuEb9SPulBc0XnUpZWl1h5MwptCS2pR+lJSlR5owqkw9
SPv4KF8nlPS8uEKabWOVLemFLVcIl1JBNLmAFcN8Tf8A5/JQU6LzKlrTymXS
lOqCXCpVxRe8QJoivqi+pH0lKCvRebbZU65MS6Ka4BClKClcnUULu8ymacMY
vqR9/b+SmPu7BGmTeyKHvf1iUGrxhQX8mKFsHXAL3wRYkVstT0s4+LzCHUKd
FK1QFAqw24RJ4mlh0lpsu2g43ZyJdhKpl8uSU40lKWlMhKuaVIFa745Y+PPn
xHmPu1P0V5SxTLS82XVszCXpQuMOt1UAdYlFReSCDFnK65jyUjkdF1qng1Nu
oDKZnkrlxRqVXC5zap3CE9Tx4+lpqBNgcobbZl1NF1yYdaExfVdKW0azK5sG
2LvXP0KD8mZnxuUy2qS0Hw9fVcuKVczKN8PUj6Sai+Sk5ecS4/Ltap3k9VqU
Apd0OYG5uVtiepH3NWMeaSN22N0yGvGFB4qFsgF74gW2AKAdFLySvxQamA6q
1VJmhydhhgy0+40mzpppCUhBrRSXCkVBxyjlj48+fHMNz/fDJa0cm3VpQHGk
6xbzdVFVAZfxyebluje8f/vuzqk+TMzU1mJYNpbbe1t9VwpdUUJobm8RN4+6
6iRopOrWpvXMIWHVMJSpSuepAvG7RB2HbE9SPuaFLaNPupZdU+wlDiEPlF5V
8NLVdrS5FnP9zVStmTbkbQelm1hbaFEJoakcFYDEbYuM3FszFSoxpDjKIF74
BbYB4Be6AUB19iIpJWadQythanzOOuoQaISoAG8vpjjlzP8ADpjxDGVYD6pd
U0l1m7q1TIZqq/qgq7Wl2nrje3szqlXorOJeTL6+XU8pYbKApVUkpK6mqMqD
ZE3j7mkoXrAmGm1OpeZcaDJmL7ZUQUhVw0qkY1i7GqZOi84VqQX2EFLiGecp
QvLcQHEhPM3GJvH3NJArRuaQ3fLzF+4HNTeVfulVwHxaZ8Yu8fc1SHRac1iG
UvMLUtxTJKVKolaEFxQVVA2CJvH3NJZ89Z6pJSEl1t4OpvhTRJGZFDUJNcI1
E2kxSrFQ8AoBQDQDwCgjoJCbbkLKln1MNuhc0pL15CVKLYCSQCqOcxc/huJq
PyrpsV2eSZxlxppt8vLYYUSFlLZqoABJGA4xdq8Jrfk6dF5xaUlLzBKg0bl5
V4B8gIJF3jE3hdJMdGpoKQNewUKS6suhSriQxQLqbmysXf8Ac0ONGZorWnXs
AJ1VFlSrqtd4l3mRN/3NAnRyZCXCX2L7IdUtq8q/dZJSs0u02Rd/3NU87o4l
My4hiYaSy00h1xTilc29QY0RtJw4RIzJxZU9JuSM05KvEFxo0JTiMq4VpGom
/LMxSvFQoB4gUA9YBQCgOlYmWkWYy41LtTEu20pucSEJ1qHDeurNRW7xjFeX
S/H9obVsdTqUTDBaSlDEtfaBourlEBRAFMSYRl/0nH/iA6MTetQ2l9hZU4tk
lKlUStCC4QqqNwi7popT9nuSJbvrQ6l5GsQtokppUjaBuixNpMUqRWTxRzOk
n6aj90PxKjjLtjw0pMfmzP7tJHoiO+CpdnTgNgpvjcI2J+2xN21y1CnOR61t
zVHOiLtebeI2RiMKxr3Wxy1ryqbTtB97W8lnhMIAQAVpD5wNCoCtOMJxmoj3
iv4F86RWSVKQpEwWk8lLRSEXjyavjc6mMY1n7e/8rZDSSyyrWLS/rULnVNUC
LtJski9ztkXSft7fwWqTdrWM+hD2reVPtty6EEgBCNSU3yKLxvAUxEaiMvtX
lFpm37Jan5qa/Orsy4FqRdQUrQa321tld2h2HOMzhlUR48LbNs20JCXm55Ty
HEyk426ylDQTeQHFJUMFEDACNZYzMR9YQFtzspNrlRJhYalmEMAvABXMKjXm
kjbDGJjn3klprtyxmkTKpVp9tcyGas3W0sgtFJJSEqzN3dGdMvF14tbTvaUW
eZxuYrNLCXHXChYQEpDjSmwEpC8aFWZ2RPTmq8FsuwLaTZapgvArS4380BjR
1Jq2cSMBjG88bSJTyFuSbUkxKzCXeazNsOqQEk/nJTRSaqFaUxrEnCbv7x/B
aWTtyx5MPMywmWGHNSQtsJKyWwb9by8L1dkJwynmp5LJNvWYJWYZUJlwv68l
pwJcbKnFKLTlVKqlSQRUpGcTSb9vYtzeHWMo6smpTvihsN/GCH28IBfzSAVO
jpgFt6IInlHGWJth19GsabcSpxFAb6QQSKHDERJ4V0jOkFjyimRLImC2ibM0
pKwgBIUhaLrYSr9aOWmU81xTVwrm3bPalhLy6XlITLGXQpxKQbxdDlTRRwi6
Td+ObLWXNJrL16HWUPms6mcdvBGQbU2QmiuO2J6eX24o2j+VeSt2z5RTKQl5
bbMw+6TdTeuPNasfWpUEwnCZ/wBQWGatuz+RrlJcPEclRLtqcCQbyXNZU0Uc
KRYwm7+9pa2jSWyuVzL7iZi5MO3lNXUKbcbuJTcWhS7taitRGfTyqOPC7Q5V
ZSVKpvqBHZg23hAP/NIIVP6wC2xA+R4wD7YBIwUFEVAOIgOm8PWMwXDJtvpD
sww+WiltLaAyu8dWEq2iOWmXvXEw3tCzIWlZ83ONMy4eCUmcecLgTX51BPNu
qOUScZiPNeyxMf2Fqes6Zkpv6YScrLyjJNE603HioG7eu5nfCpiY4uZlLj+g
t6TWZyjlDqHwpuZcmGwkIIIWgIoqqhSGk/bijaGNN2m065ILbvASjDTTgOF4
tqKjShyxjpGPP3lm+EVsTMtN2g9My9/VvEro4ACCc/FJhjFRUpPKl/NI0h4g
W3ogH9sAtsA0AoDdkrbl5diTl3ELU22mZbm0inObfpS7jsptjnOPP4puMuEi
rckzZiZS9MBxEuWLiQkNqVWoUo3r2WyGs3fjk28e62NJLLbcl1pRMOah0KQX
QgrQ3cUkoSu+VHE1xjOk/ZdoVhbVlJZEpSYMsJZUvfuov1U5rMr1Ius8+OU2
jjzwitm25WdZebYS4krmG3kFQA5qGQzjRRxrFxxr/SZZX/s6rUslxmXW628u
blmG2UDAICkKvX6hddu0QqfxMlwszVv2c/MtulU2pCXlOkc1FwFBCblxeYPH
KJGM/ZZyj7sy25+Wn323GAq8lsJdccSlCnF1POIQSMo1jFM5TbN9saQ8Av6Q
DeyAeAUAoDZs60bKRJsy88l5RYfL4DaUKQoc3mqvkYYRiYm/H0aiYrz9Vlm3
LNQ2irbqXGOVapCEouUmMgecKU4CJrP9LtH9opadROW5Z62ryUp1DSgrCpRQ
HInCFVjKXeULLlsWayvktHiylE2y4uiL16YUPFF6lBTfE1nn9l2j+1a0balH
5Z5hhLgqJdLalgD6AEEmijvixik5JJe3pRqzeSnW60y7zKgEpuKW5Wiyb17b
DWb/ACu3j8JE2/IB51wcobL7DbSlJSglKm6eLVWINIms/bk2j7sa05luanHX
2r5bWap1uK8qY0jccMzyqRWSgHiKVIBQQ8AqQG7JWpZMu02vVuomkMLZWG0o
DbhVXFZqCc4xMS3EwS7dlil0BC6ralEDAZy6gpVcdtMIa/8AV2/40ZC1ZGat
BtqXDtXZh+aWXAkUvMKTQXVGJMTX4pYmL/LBtSclpnkzcsF6qWa1VXaBRxJr
RJI2xuIYmWfFQoqOa0k/TUfuh+JUcZdseBsWyw2y22UrJSkDZTAU3x0xyWhe
GpXyHMOCc9+cdNij+HJaviuAdCe+JsUXhyWxolzsT3xdii8OSvkL6aJr7Ymx
ReHJXyXOwfFDYo/hyVA8RzHgnvhsUXh2WzuOdie+GxRvDksc0uU6B8UIyKLw
5K+Q52J74bFH8OSvkOdie+LsUXhyVr4jnYnvhsUXh2W8lzsT3w2KN4clPJc7
Bn6UTYo/h2V8lynQPii7FG8OSoyQ52J74bFH8OSvkOdie+J6iUXh2V8lzsHx
Q9RdTeHJWniOY8E98XZNT+HZbyHOxPfE2NTeHZbalzsHxQjqGpeHJXyHOxPf
F9Q1Lw5K08RzsT3xPUTU/h2VrilzsHxQ9RdS8Oy3kudie+HqJqbw3K+Q52J7
4eoan8OyvkuU6B8UNl1Lw7K40S5wwHxQ2NT+HZUfUc7E98XZNTeHZTyXOwfF
E2XU/h2UA8RzsHxRdjUvD0r5LnYPiibGpeHpXalzsHxQ2TUvD0p5DnYPihsa
l4elPJc7B8UTY1P4elK+I52D4obGpeH5XyHOwfFDY1Lw9KeQ5vyGfpQ2NS8P
ynkuU6B8UNjU/h+UxolzsHxQ2NTeH5TyHOwfFDY0Lw/KeS52D4obGh/lBKeQ
52D4obGhfKCU8lzsHxQ2NC+UEr5LnYPihsaF4flPIc7B8UNjQ/h+U8hzsHxR
NjQvD8n5DnYPihsaF8oZXyHOwfFDY0Lw/J+Q52D4obGhfKCU8lzsHxQ2NC+U
EpsQ52D4obGhfKCT8hzsHxQ2NC+UEp5DnYPihsaF8oZPyHOwfFDY0L5QynkO
dg+KGxof5RSnkudg+KGxoXyhk/Ic7B8UNjQvlDJ+Q52D4obGhfKKT8hzsT8U
NjQ/yik/Ic7E/FDY0N8opPyHOxPxQ2ND/KKT8hzsT8USzQvlFJ+Q52D4oWaF
8opPyHOwfFCzQvlFJ+Q52J+KFmhfKKT8hzsHxQ2TQ/yjk/Ic7E/FDY0N8opP
yHOxPxQtdC+UUn5DnYn4oWaF8opLyHOxPxQs0L5RyfkOdifihZof5RyfkOdi
fihZob5RyfkOdifihZoXyjk/Ic7E/FCzQ/yjk/Ic7E/FC00L5RyfkOdifihs
aF8o5PyHOxPxRNjQvlHJ+Q52J+KJsaH+Ukn5DnYn4obGhvlHJ+Q52J+KGxof
5RyfkOdifihsaG+Ucn5DnYn4obLoXyjk/Ic7E/FDY0P8pJPyHOxPxQ2TQvlJ
J+Q52J+KGxoXyjk/Ic7E/FF2TRkWtPMzswHWwoJCAnnAVzJ2E74xMukQ/9k=

--= Multipart Boundary 1017032006--

From prabhakark@contechsoftware.com Sat Oct 18 14:32:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Oct 2003 14:32:49 +0100 (BST)
Received: from [IPv6:::ffff:203.129.212.34] ([IPv6:::ffff:203.129.212.34]:41484
	"HELO mail.contechsoftware.com") by linux-mips.org with SMTP
	id <S8225447AbTJRNcR>; Sat, 18 Oct 2003 14:32:17 +0100
Received: (from prabhakar [200.1.1.48])
 by mail.contechsoftware.com (SAVSMTP 3.0.0.44) with SMTP id M2003101819102814240
 for <linux-mips@linux-mips.org>; Sat, 18 Oct 2003 19:10:29 +0530
Received: by localhost with Microsoft MAPI; Sat, 18 Oct 2003 19:12:32 -0000
Message-ID: <01C395AB.C7C9C020.prabhakark@contechsoftware.com>
From: Prabhakar <prabhakark@contechsoftware.com>
Reply-To: "prabhakark@contechsoftware.com" <prabhakark@contechsoftware.com>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Root fs with NFS problem...
Date: Sat, 18 Oct 2003 19:12:30 -0000
Organization: Contech Software Limited.
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Encoding: 37 TEXT
Return-Path: <prabhakark@contechsoftware.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3451
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: prabhakark@contechsoftware.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1424
Lines: 38

Hi all,

I'm trying to boot through NFS using rootfs,I'm got struck like...


au1000eth.c:1.4 ppopov@mvista.com
eth0: Au1x Ethernet found at 0xb1500000, irq 28
eth0: AMD 79C874 10/100 BaseT PHY at phy address 0
eth0: Using AMD 79C874 10/100 BaseT PHY as default
eth1: Au1x Ethernet found at 0xb1510000, irq 29
eth1: AMD 79C874 10/100 BaseT PHY at phy address 0
eth1: Using AMD 79C874 10/100 BaseT PHY as default
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
IP-Config: Incomplete network configuration information.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
kmod: failed to exec /sbin/modprobe -s -k block-major-2, errno = 2
VFS: Cannot open root device "nfs" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00


I have created rootfs and configured NFS  from host end and Target but
i don't know where to put my kernel commandline parameters...

I'm doing something wrong in nfs setup, i couldn't find it out.

can anybody help me what are all configurations i have to do from host end and target end to get boot my target using rootfs by NFS.

It could be a great help for me,

Prabhakar


From jbglaw@dvmwest.gt.owl.de Sat Oct 18 14:57:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Oct 2003 14:57:54 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:62941 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225447AbTJRN5w>; Sat, 18 Oct 2003 14:57:52 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 4F4AC4B3B3; Sat, 18 Oct 2003 15:57:50 +0200 (CEST)
Date: Sat, 18 Oct 2003 15:57:50 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: Root fs with NFS problem...
Message-ID: <20031018135750.GW20846@lug-owl.de>
Mail-Followup-To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
References: <01C395AB.C7C9C020.prabhakark@contechsoftware.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="zzcR2VDKFyidiRlc"
Content-Disposition: inline
In-Reply-To: <01C395AB.C7C9C020.prabhakark@contechsoftware.com>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
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: 3452
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2238
Lines: 62


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

On Sat, 2003-10-18 19:12:30 -0000, Prabhakar <prabhakark@contechsoftware.co=
m>
wrote in message <01C395AB.C7C9C020.prabhakark@contechsoftware.com>:
> au1000eth.c:1.4 ppopov@mvista.com
> eth0: Au1x Ethernet found at 0xb1500000, irq 28
> eth0: AMD 79C874 10/100 BaseT PHY at phy address 0
> eth0: Using AMD 79C874 10/100 BaseT PHY as default
> eth1: Au1x Ethernet found at 0xb1510000, irq 29
> eth1: AMD 79C874 10/100 BaseT PHY at phy address 0
> eth1: Using AMD 79C874 10/100 BaseT PHY as default
> mice: PS/2 mouse device common for all mice
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 2048 bind 4096)
> IP-Config: Incomplete network configuration information.
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Root-NFS: No NFS server available, giving up.

It seems you have neither compiled-in bootp or dhcp support, nor have
you given yout IP config at the command line (root=3D/dev/nfs
nfsroot=3Dxx.xx.xx.aa:/path/to/root ip=3Dxx.xx.xx.bb)

> I have created rootfs and configured NFS  from host end and Target but
> i don't know where to put my kernel commandline parameters...

What boot loader do you use? Should be simple, though...

> I'm doing something wrong in nfs setup, i couldn't find it out.

Either you need bootp/dhcp to give an IP address (and boot config) out
to your machine, or you need to supply that data at the command line.

MfG, JBG

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

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

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

iD8DBQE/kUbeHb1edYOZ4bsRAltqAJ4sW76MVnJeRIm5JWWhl+QI/FjRRQCeNyAD
mjT4/ehBnnCUrnXUmIOQoUw=
=0i0b
-----END PGP SIGNATURE-----

--zzcR2VDKFyidiRlc--

From shaun@redcellx.com Sat Oct 18 17:22:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Oct 2003 17:22:41 +0100 (BST)
Received: from savages.net ([IPv6:::ffff:12.154.202.18]:48024 "EHLO
	savages.net") by linux-mips.org with ESMTP id <S8225462AbTJRQWi>;
	Sat, 18 Oct 2003 17:22:38 +0100
Received: from redcellx.com (kerberos [::ffff:192.168.4.27])
  (TLS: TLSv1/SSLv3,256bits,AES256-SHA)
  by server with esmtp; Sat, 18 Oct 2003 02:16:14 -0700
Message-ID: <3F9168C4.7080807@redcellx.com>
Date: Sat, 18 Oct 2003 09:22:28 -0700
From: Shaun <shaun@redcellx.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Troy Melquist <Troy@redcellx.com>,
	'Jerry Wheeler' <jerry@redcellx.com>,
	'Mary Burke' <mburke@redcellx.com>
Subject: HOWTO Cross devel system 
X-Enigmail-Version: 0.76.7.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <shaun@redcellx.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3453
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: shaun@redcellx.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1937
Lines: 61


Hi All

I now can create a cross devel environment for the mipsel-linux 
platform.  This means that every one could have one with not many 
surprises :)
from 
ftp://ftp.mips.com/pub/tools/software/sde-for-linux/sdelinux-5.02.02-1.i386.rpm
or for a newer version
ftp://ftp.ds2.pg.gda.pl/pub/macro/RPMS/i386/ (binutils and gcc)

with that, you need a glibc
from
ftp://ftp.ds2.pg.gda.pl/pub/macro/RPMS/mipsel
get glibc, glibc-libs, glibc-devel and any other packages you want
This packages are mipsel native code
to extract the files you need to convert them to cpio then use cpio
 > rpm2cpio  file >outfile
 > cpio -i --make-directories <outfile

install the files in the directory /usr/local/mipsel-linux/ ( bin, lib, 
include)
edit $()/mipsel-linux/lib/libc.so   yes a text file
add the prefix /usr/local/mipsel-linux to the paths, you will see what I 
mean when you see the file

test compile hello world

I still need to test the execution on the "eb"

This will now allow us to document the tool chain. to create consistent 
development program.


To get NFS working, "portmap" and "mount" need to support nfs. I am 
checking busybox-1.0rc3 to see how to configure it to support nfs.


-- 
Shaun Savage
Linux Engineer,
RedCellX
333 SW 5th Ave
Portland, OR 97204
503-295-9680


  ****CONFIDENTIALITY NOTICE**** This e-mail message is confidential and 
may be privileged.  THIS EMAIL MAY NOT BE SHARED WITH ANY OTHER PERSON 
BUT THE RECEIVER.  If you believe that this e-mail has been sent to you 
in error please:  (1) notify the sender; and (2) delete this e-mail. 
Thank you.  Disclaimer of Electronic Transaction:  This communication 
does not reflect an intention by the sender or the sender's client to 
conduct a transaction or make any agreement by electronic means. 
Nothing contained herein shall constitute an electronic signature or a 
contract under any law, rule or regulation applicable to electronic 
transactions.





From nick@snowman.net Sun Oct 19 21:09:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 19 Oct 2003 21:09:26 +0100 (BST)
Received: from snowman.net ([IPv6:::ffff:66.93.83.236]:21768 "EHLO
	relay.snowman.net") by linux-mips.org with ESMTP
	id <S8225396AbTJSUJW>; Sun, 19 Oct 2003 21:09:22 +0100
Received: from ns.snowman.net (ns.snowman.net [10.10.0.2])
	by relay.snowman.net (8.12.10/8.12.10/Debian-1) with ESMTP id h9JK9Dtg001329;
	Sun, 19 Oct 2003 16:09:13 -0400
Received: from ns.snowman.net (localhost [127.0.0.1])
	by ns.snowman.net (8.12.10/8.12.10/Debian-1) with ESMTP id h9JK9DOu011556;
	Sun, 19 Oct 2003 16:09:13 -0400
Received: from localhost (nick@localhost)
	by ns.snowman.net (8.12.10/8.12.10/Debian-1) with ESMTP id h9JK99ra011552;
	Sun, 19 Oct 2003 16:09:10 -0400
X-Authentication-Warning: ns.snowman.net: nick owned process doing -bs
Date: Sun, 19 Oct 2003 16:09:09 -0400 (EDT)
From: Nick <nick@snowman.net>
To: Ralf Baechle <ralf@linux-mips.org>
cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: MIPS addressing limits, Was: Re: CVS Update@-mips.org: linux
In-Reply-To: <20031015145948.GB23514@linux-mips.org>
Message-ID: <Pine.LNX.4.21.0310191608450.11837-100000@ns.snowman.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <nick@snowman.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: 3454
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nick@snowman.net
Precedence: bulk
X-list: linux-mips
Content-Length: 1977
Lines: 44

If anyone wants to poke said folks into handing in the OK I'll ship
someone an R8k I2 to work on.
	Nick

On Wed, 15 Oct 2003, Ralf Baechle wrote:

> On Wed, Oct 15, 2003 at 04:23:06PM +0200, Maciej W. Rozycki wrote:
> 
> > > Still want more?  A 3 level tree would then cover 128TB of virtual
> > > address space already exceedin the hardware limits of all processors but
> > > the R8000.
> > 
> >  Well, the MIPS64 ISA spec allows up to 8EB of user memory to be supported
> > by an implementation, IIRC; probably nothing supports that much yet,
> > though. ;-)  BTW, is an R8000 spec available online anywhere?
> 
> There used to be a few papers published by SGI online and various other
> bits of information I found through google.
> 
> (I happen to have a paper copy of the R8000 manual but since the responsible
> people still haven't informed me if I can legally use it, this book is
> closed and will stay closed until this happens - if ever ...  Pitty, I
> still receive mails from various R8000 users ...)
> 
> > > 64k pagesize stretches the limits even further.   Here a two level
> > > pagetable tree would cover 4TB, 3-level could cover 32PB exceeding
> > > the capacity of every MIPS processor ever made - and probably sufficient
> > > for the coming decade :-)
> > 
> >  Further increasing of the page size should result in better performance
> > due to fewer TLB misses and reduce the memory footprint of page tables,
> > but the drawback is more memory is wasted for maps.  Whether the end
> > result is a gain or a loss depends on the actual application of a system,
> > so I guess we should either leave the size configurable (with a sane
> > default for those who might have troubles judging what would suit them
> > best) or only decide on a given size after lots of benchmarking.
> 
> Unless somebody yells I almost feel like ditching 3-level pagetable
> support; 2-levels with a decent pagesize should suffice for a few years
> to come ...
> 
>   Ralf
> 


From Krishna.Kondaka@MCDATA.com Mon Oct 20 02:24:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Oct 2003 02:24:10 +0100 (BST)
Received: from mcjekyll.mcdata.com ([IPv6:::ffff:144.49.6.25]:15003 "EHLO
	380GATE01out.mcdata.com") by linux-mips.org with ESMTP
	id <S8225423AbTJTBYH> convert rfc822-to-8bit; Mon, 20 Oct 2003 02:24:07 +0100
Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Sun, 19 Oct 2003 19:23:55 -0600
Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Sun, 19 Oct 2003 19:23:54 -0600
Received: from SNEXCH01.mcdata.com ([172.19.161.13]) by MC4EXCH03.mcdata.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sun, 19 Oct 2003 19:23:54 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Subject: gcov and gprof 
Date: Sun, 19 Oct 2003 18:23:52 -0700
Message-ID: <501EA67E9359C645A10C42EB5B52480D2AB2D9@SNEXCH01.mcdata.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: MIPS addressing limits, Was: Re: CVS Update@-mips.org: linux
Thread-Index: AcOWfafdUl8faX3JTTSh/11qTkakDwAKbkeQ
From: "Krishna Kondaka" <Krishna.Kondaka@MCDATA.com>
To: <linux-mips@linux-mips.org>
X-OriginalArrivalTime: 20 Oct 2003 01:23:54.0361 (UTC) FILETIME=[D380C690:01C396A8]
Return-Path: <Krishna.Kondaka@MCDATA.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3455
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Krishna.Kondaka@MCDATA.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1158
Lines: 27



Hi,

I would like to know if gcov and gprof are available on MIPS Linux. If yes, which version of library/utils are these available?

Thanks in advance
Krishna

SPECIAL NOTICE 

All information transmitted hereby is intended only for the use of the 
addressee(s) named  above and may contain confidential and privileged 
information. Any unauthorized  review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader of
this message is not the intended recipient(s) or the employee or agent 
responsible for delivering the message to the intended recipient, you
are herby notified that you must not read this transmission and that
disclosure, copying, printing, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY 
PROHIBITED.

Anyone who receives confidential and privileged information in error should 
notify us immediately by telephone and mail the original message to us at the
above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions 
apply to that information. (gate01)

From webmaster@noble21.co.kr Mon Oct 20 05:25:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Oct 2003 05:25:16 +0100 (BST)
Received: from [IPv6:::ffff:61.72.80.34] ([IPv6:::ffff:61.72.80.34]:33796 "HELO
	noble21.co.kr") by linux-mips.org with SMTP id <S8225310AbTJTEZO>;
	Mon, 20 Oct 2003 05:25:14 +0100
From: =?ks_c_5601-1987?B?sMewrcDMutK4tsau?= <webmaster@noble21.co.kr>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: =?ks_c_5601-1987?B?W7GksO1dx8e3zsfPvcq0z7HuPyDAzMGoIMbtvsjI9yDB1rmrvcOw7SC788Tox9EgvsbEp8C7ILjC
Message-Id: <20031020042514Z8225310-1272+8144@linux-mips.org>
Date: Mon, 20 Oct 2003 05:25:14 +0100
Return-Path: <webmaster@noble21.co.kr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3456
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: webmaster@noble21.co.kr
Precedence: bulk
X-list: linux-mips
Content-Length: 5002
Lines: 67

wLi8vL/k?=
Date: Mon, 20 Oct 2003 13:25:53 +0900
MIME-Version: 1.0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: 8bit


<html>

<head>
<title>º» ¸ÞÀÏÀº ¹ß½ÅÀü¿ëÀÔ´Ï´Ù. °¢Á¾ ¹®ÀÇ»çÇ×Àº ¹®ÀǸÞÀÏÀ» ÀÌ¿ëÇØ ÁÖ¼¼¿ä. </title>
<meta name="generator" content="ahgh">
</head>

<body text="black" link="blue" vlink="purple" alink="red" leftmargin="0" marginwidth="0" topmargin="0" marginheight="0" bgcolor="#F3F3F3">
<table border="0" cellpadding="0" cellspacing="0" width="1096">
    <tr>
        <td width="7">
            <p>&nbsp;</p>
        </td>
        <td width="1089"><table cellpadding="0" cellspacing="0" width="654" style="border-collapse:collapse;">
    <tr>
        <td width="1092" style="border-top-width:1; border-right-width:1; border-bottom-width:0; border-left-width:1; border-top-color:gray; border-right-color:gray; border-left-color:gray; border-style:solid;">
            <p><img src="http://www.noble21.co.kr/mailling/2003.05.13/img_1.jpg" width="654" height="924" border="0" usemap="#ImageMap1"></p>
        </td>
    </tr>
    <tr>
        <td width="1092" style="border-top-width:0; border-right-width:1; border-bottom-width:1; border-left-width:1; border-right-color:gray; border-bottom-color:gray; border-left-color:gray; border-style:solid;">
            <table style="border-collapse:collapse;" cellpadding="0" cellspacing="0" width="654" bgcolor="#999999" bordercolordark="white" bordercolorlight="white">
                <tr>
                    <td width="644" style="border-width:1; border-color:white; border-top-style:none; border-right-style:solid; border-bottom-style:solid; border-left-style:solid;">
                        <p align="center"><FONT color="white" face="±¼¸²"><span style="font-size:9pt;"><BR></span></FONT><span style="font-size:9pt;"><font face="±¼¸²" color="white">Tel : (ÓÛ) 02-2605-1836&nbsp;&nbsp;&nbsp;&nbsp;Fax : 02-2694-0413&nbsp;&nbsp;&nbsp;&nbsp;E-mail : </font></span><A 
href="mailto:webmaster@noble21.co.kr"><FONT 
color="white" face="±¼¸²"><span style="font-size:9pt;">webmaster@noble21.co.kr</span></FONT></A><span style="font-size:9pt;"><font face="±¼¸²" color="white">&nbsp;&nbsp;&nbsp;&nbsp;<BR>º»»ç : 157-010 ¼­¿ï½Ã °­¼­±¸ È­°îº»µ¿ 24-233 ³ëºí21(ÁÖ) °Ç°­À̺Ҹ¶Æ®&nbsp;&nbsp;&nbsp;&nbsp;<br>»ç¾÷ÀÚµî·Ï¹øÈ£ : 
109-81-76636¤ýÅë½ÅÆǸž÷½Å°í Á¦ 16-299È£<br>Copyright ¨Ï </font></span><FONT 
color="white" face="±¼¸²"><span style="font-size:9pt;">noble21</span></FONT><span style="font-size:9pt;"><font face="±¼¸²" color="white"> All rights reserved.</font><font face="±¼¸²"><BR><BR></font></span></p>
                    </td>
                </tr>
            </table>
        </td>
    </tr>
</table>
        </td>
    </tr>
</table>
<map name="ImageMap1">
<area shape="rect" coords="242, 19, 305, 45" href="http://www.noble21.co.kr/shop/category.php?classid=1" target="_blank">
<area shape="rect" coords="306, 20, 373, 44" href="http://www.noble21.co.kr/shop/category.php?classid=2" target="_blank">
<area shape="rect" coords="375, 19, 452, 44" href="http://www.noble21.co.kr/shop/category.php?classid=3" target="_blank">
<area shape="rect" coords="452, 20, 521, 44" href="http://www.noble21.co.kr/shop/category.php?classid=4" target="_blank">
<area shape="rect" coords="523, 20, 574, 44" href="http://www.noble21.co.kr/shop/category.php?classid=5" target="_blank">
<area shape="rect" coords="573, 19, 652, 46" href="http://www.noble21.co.kr/shop/category.php?classid=9" target="_blank">
<area shape="rect" coords="9, 8, 123, 39" href="http://www.noble21.co.kr/" target="_blank">
<area shape="rect" coords="438, 559, 609, 603" href="http://www.noble21.co.kr/" target="_blank">
<area shape="rect" coords="57, 669, 231, 821" href="http://www.noble21.co.kr/drqueen/drqueen01_1.php" target="_blank">
<area shape="rect" coords="240, 669, 413, 820" href="http://www.noble21.co.kr/drqueen/drqueen02_1.php" target="_blank">
<area shape="rect" coords="423, 669, 595, 820" href="http://www.noble21.co.kr/drqueen/drqueen03_1.php" target="_blank">
</map><br><table width="100%"><td bgcolor="#FFFFFF"><hr>
<font color="#808080" face="±¼¸²"><span style="FONT-SIZE:9pt">±ÍÇÏÀÇ À̸ÞÀÏÁÖ¼Ò´Â ÀÎÅͳÝ<a href="http://cvs.handhelds.org/cgi-bin/viewcvs.cgi/linux/kernel26/maintainers?rev=1.7&content-type=text/vnd.viewcvs-markup">¼­ÇÎÁß</a>¾Ë°ÔµÇ¾úÀ¸¸ç, ¸ÞÀÏÁÖ¼ÒÀÌ¿ÜÀÇ ¾î¶°ÇÑ Á¤º¸µµ °¡Áö°í ÀÖÁö ¾Ê½À´Ï´Ù. ¸ÞÀϼö½ÅÀ» ¿øÇÏÁö ¾ÊÀ»°æ¿ì <a href="mailto:webmaster@noble21.co.kr?subject=REMOVE&body=º»ÀÎÀÇ À̸ÞÀÏÁÖ¼Ò linux-mips@linux-mips.org¸¦ ¸®½ºÆ®¿¡¼­ »èÁ¦ÇØ ÁÖ¼¼¿ä...">[¼ö½Å°ÅºÎ]</a>¸¦ ´­·¯Áֽʽÿä.. °¨»ç ÇÕ´Ï´Ù. 
</span></font><font face="Arial" size="2"><font color="#808000">If you feel that this information is not what you want, please click <a href="mailto:webmaster@noble21.co.kr?subject=REMOVE&body=Pls remove my email linux-mips@linux-mips.org from your list..">[HERE]</a> requesting to be removed. Thank you, and we apologize for any inconvenience.</font><hr></td></table><br></body>

</html>

G7dL>UQ:3>'gM0(9h22 h5



From dkesselr@mmc.atmel.com Mon Oct 20 15:32:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Oct 2003 15:32:29 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:14864
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225417AbTJTOcW>; Mon, 20 Oct 2003 15:32:22 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA29333
	for <linux-mips@linux-mips.org>; Mon, 20 Oct 2003 10:32:11 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA12939
	for <linux-mips@linux-mips.org>; Mon, 20 Oct 2003 10:32:08 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Mon, 20 Oct 2003 10:32:08 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: kernel modules
Message-ID: <Pine.GSO.4.44.0310201029090.12930-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3459
X-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
Content-Length: 387
Lines: 13

Can someone please confirm that loading and unloading of kernel modules is
functioning in the  2.4 release?

When I try to load a wlan module that I compiled (with mipsel-*) I get
relocation errors. I used the same options as I did to compile the kernel
(for MIPS Malta board). If you have any ideas, please let me know.


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


From ddaney@avtrex.com Mon Oct 20 16:48:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Oct 2003 16:48:19 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:11330 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225427AbTJTPsN>;
	Mon, 20 Oct 2003 16:48:13 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 20 Oct 2003 08:48:04 -0700
Message-ID: <3F9403B4.3030207@avtrex.com>
Date: Mon, 20 Oct 2003 08:48:04 -0700
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Kesselring <dkesselr@mmc.atmel.com>
CC: linux-mips@linux-mips.org
Subject: Re: kernel modules
References: <Pine.GSO.4.44.0310201029090.12930-100000@ares.mmc.atmel.com>
In-Reply-To: <Pine.GSO.4.44.0310201029090.12930-100000@ares.mmc.atmel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Oct 2003 15:48:04.0544 (UTC) FILETIME=[8C9ED400:01C39721]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3460
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2135
Lines: 66

David Kesselring wrote:

>Can someone please confirm that loading and unloading of kernel modules is
>functioning in the  2.4 release?
>
>When I try to load a wlan module that I compiled (with mipsel-*) I get
>relocation errors. I used the same options as I did to compile the kernel
>(for MIPS Malta board). If you have any ideas, please let me know.
>
>  
>
Works for me.

Using gcc 3.3.1 to compile modules, I had to upgrade to modutils-2.4.25 
and apply this patch to them:


On Thu, 16 Oct 2003 14:09:24 -0700, 
David Daney <ddaney@avtrex.com> wrote:

>>Anyhow, I encountered a small problem trying to load a module compiled 
>>with gcc-3.3.1.  The module has dwarf debugging info and could not be 
>>loaded by insmod.  This patch causes MIPS_DWARF sections to be treated 
>>in the same manner as MIPS_DEBUG sections.
>>
>>Also there was a fall through in the case statement that caused error 
>>messages to be printed twice for "Unhandled section header type".
>  
>

Thanks.   I already have an equivalent patch in my development tree
(from Alvaro Martinez Echevarria).  It is waiting for me to get some
time to release modutils 2.4.26.

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

David Daney






From ddaney@avtrex.com Mon Oct 20 19:13:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Oct 2003 19:13:21 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:7242 "EHLO avtrex.com")
	by linux-mips.org with ESMTP id <S8225423AbTJTSNR>;
	Mon, 20 Oct 2003 19:13:17 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 20 Oct 2003 11:13:14 -0700
Message-ID: <3F9425BA.3070409@avtrex.com>
Date: Mon, 20 Oct 2003 11:13:14 -0700
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Kesselring <dkesselr@mmc.atmel.com>
CC: linux-mips@linux-mips.org
Subject: Re: kernel modules
References: <Pine.GSO.4.44.0310201029090.12930-100000@ares.mmc.atmel.com>
In-Reply-To: <Pine.GSO.4.44.0310201029090.12930-100000@ares.mmc.atmel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Oct 2003 18:13:14.0636 (UTC) FILETIME=[D43D64C0:01C39735]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3461
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 469
Lines: 16

David Kesselring wrote:

>Can someone please confirm that loading and unloading of kernel modules is
>functioning in the  2.4 release?
>
>When I try to load a wlan module that I compiled (with mipsel-*) I get
>relocation errors. I used the same options as I did to compile the kernel
>(for MIPS Malta board). If you have any ideas, please let me know.
>
>  
>
Modules also require compiling with -mlong-calls in addition to the 
"normal" kernel options.

David Daney.


From ralf@linux-mips.org Mon Oct 20 19:39:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Oct 2003 19:39:31 +0100 (BST)
Received: from p508B6F04.dip.t-dialin.net ([IPv6:::ffff:80.139.111.4]:64168
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225423AbTJTSjY>; Mon, 20 Oct 2003 19:39:24 +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 h9KIdMNK024698;
	Mon, 20 Oct 2003 20:39:22 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9KIdM0w024697;
	Mon, 20 Oct 2003 20:39:22 +0200
Date: Mon, 20 Oct 2003 20:39:22 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: kernel modules
Message-ID: <20031020183922.GD15997@linux-mips.org>
References: <Pine.GSO.4.44.0310201029090.12930-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0310201029090.12930-100000@ares.mmc.atmel.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3462
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 497
Lines: 13

On Mon, Oct 20, 2003 at 10:32:08AM -0400, David Kesselring wrote:

> Can someone please confirm that loading and unloading of kernel modules is
> functioning in the  2.4 release?
> 
> When I try to load a wlan module that I compiled (with mipsel-*) I get
> relocation errors. I used the same options as I did to compile the kernel
> (for MIPS Malta board). If you have any ideas, please let me know.

You're _not_ using the same options as the kernel's Makefile does for
building modules.

  Ralf

From zhanght@netpower.com.cn Mon Oct 20 22:00:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Oct 2003 22:00:02 +0100 (BST)
Received: from [IPv6:::ffff:211.154.175.2] ([IPv6:::ffff:211.154.175.2]:18436
	"EHLO mail.netpower.com.cn") by linux-mips.org with ESMTP
	id <S8225460AbTJTVAA>; Mon, 20 Oct 2003 22:00:00 +0100
Received: from netpower.com.cn [192.168.0.195] by mail.netpower.com.cn with ESMTP
  (SMTPD32-7.07) id AB3D17800FA; Tue, 21 Oct 2003 04:53:17 +0800
Message-ID: <3F944CF1.2010608@netpower.com.cn>
Date: Tue, 21 Oct 2003 05:00:33 +0800
From: Zhang Haitao <zhanght@netpower.com.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.2.1) Gecko/20030225
X-Accept-Language: zh-cn,zh
MIME-Version: 1.0
To: David Kesselring <dkesselr@mmc.atmel.com>
CC: linux-mips@linux-mips.org
Subject: Re: kernel modules
References: <Pine.GSO.4.44.0310201029090.12930-100000@ares.mmc.atmel.com> <20031020183922.GD15997@linux-mips.org>
In-Reply-To: <20031020183922.GD15997@linux-mips.org>
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: 3463
X-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
Content-Length: 513
Lines: 20

On Mon, Oct 20, Ralf Baechle wrote:
>
> 
> You're _not_ using the same options as the kernel's Makefile does for
> building modules.
> 
>   Ralf
> 
Hi, modules compiled using these parameters are working on my 2.4.21 SMP 
kernel:

	CFLAGS="-I .../include/asm/gcc -D__KERNEL__ -I.../include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
-fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mcpu=XX 
-mips2 -Wa,--trap -pipe -DMODULE -mlong-calls"

XX = your chip style

Zhang Haitao


From dkesselr@mmc.atmel.com Tue Oct 21 13:34:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Oct 2003 13:34:35 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:13211
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225497AbTJUMec>; Tue, 21 Oct 2003 13:34:32 +0100
Received: from artemis.mmc.atmel.com (artemis.mmc.atmel.com [10.127.240.40])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id IAA13540;
	Tue, 21 Oct 2003 08:34:20 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by artemis.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id IAA03769;
	Tue, 21 Oct 2003 08:34:20 -0400 (EDT)
X-Authentication-Warning: artemis.mmc.atmel.com: dkesselr owned process doing -bs
Date: Tue, 21 Oct 2003 08:34:20 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: Zhang Haitao <zhanght@netpower.com.cn>
cc: linux-mips@linux-mips.org
Subject: Re: kernel modules
In-Reply-To: <3F944CF1.2010608@netpower.com.cn>
Message-ID: <Pine.GSO.4.44.0310210833250.3586-100000@artemis.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3464
X-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
Content-Length: 122
Lines: 8


Thanks for your responses. I will try your suggestions.

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


From jbglaw@dvmwest.gt.owl.de Tue Oct 21 14:10:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Oct 2003 14:10:37 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:1244 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225507AbTJUNKf>; Tue, 21 Oct 2003 14:10:35 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 5CB494B419; Tue, 21 Oct 2003 15:10:33 +0200 (CEST)
Date: Tue, 21 Oct 2003 15:10:33 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: LK201 keyboard
Message-ID: <20031021131033.GM20846@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="ZwG3HqqAyJLiyW5N"
Content-Disposition: inline
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
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: 3465
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1616
Lines: 48


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

Hi!

I'm currently reworking the LK201 keyboard driver to attach it to the
new Input API, as well as letting it use the serio interface (-> this
way, you're not bound to dz.c/zs.c).

I've got a little problem with it, though. I've got docs (for the VAX)
which describe the LK201 in detail. First of all, the "Set LEDs On"
command is wrong there (advertised as 0x12, but 0x13 actually works;
this is what the current driver uses, too). That may be a typo, though..

However, the "Set Mode" command (to set the repeat mode for a block of
keys) doesn't work for me on a lk201. Using a lk401 instead, these
commands work. Every time I send a set-mode command, I get a Input Error
(from the keyboard) sent back...

I'd like to ask you DECstation users to verify that the set-mode command
actually works for you on a lk201... Or do you all use the newer lk401?

MfG, JBG

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

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

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

iD8DBQE/lTBJHb1edYOZ4bsRAo5lAJ9AJVI9HIbU1SQbHuVtZI0OwrjQqgCghXiV
E1TLby0GwfLSgBWAdftcfKU=
=ArsP
-----END PGP SIGNATURE-----

--ZwG3HqqAyJLiyW5N--

From macro@ds2.pg.gda.pl Tue Oct 21 14:51:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Oct 2003 14:51:32 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:52419 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225510AbTJUNv2>; Tue, 21 Oct 2003 14:51:28 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA25570;
	Tue, 21 Oct 2003 15:51:22 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 21 Oct 2003 15:51:21 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
cc: linux-mips@linux-mips.org
Subject: Re: LK201 keyboard
In-Reply-To: <20031021131033.GM20846@lug-owl.de>
Message-ID: <Pine.GSO.3.96.1031021152207.23366D-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: 3466
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1575
Lines: 37

On Tue, 21 Oct 2003, Jan-Benedict Glaw wrote:

> I'm currently reworking the LK201 keyboard driver to attach it to the
> new Input API, as well as letting it use the serio interface (-> this
> way, you're not bound to dz.c/zs.c).

 Thanks for your effort and please cooperate -- I have some have
half-baked patches for the driver to let it pass native codes for the raw 
mode as appropriate.

> I've got a little problem with it, though. I've got docs (for the VAX)
> which describe the LK201 in detail. First of all, the "Set LEDs On"
> command is wrong there (advertised as 0x12, but 0x13 actually works;
> this is what the current driver uses, too). That may be a typo, though..

 This is definitely a typo -- 0x12 is a Set Mode command (mode: 1, key
group: 2; a repeat register number follows).  The definitions in lk201.h
have been verified to be correct.

> However, the "Set Mode" command (to set the repeat mode for a block of
> keys) doesn't work for me on a lk201. Using a lk401 instead, these
> commands work. Every time I send a set-mode command, I get a Input Error
> (from the keyboard) sent back...

 Strange -- these work for me.

> I'd like to ask you DECstation users to verify that the set-mode command
> actually works for you on a lk201... Or do you all use the newer lk401?

 I have an LK201 and the current code was tested almost exclusively with
it.

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


From jbglaw@dvmwest.gt.owl.de Tue Oct 21 21:23:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Oct 2003 21:23:33 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:28649 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225517AbTJUUXb>; Tue, 21 Oct 2003 21:23:31 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 1B58C4B412; Tue, 21 Oct 2003 22:23:28 +0200 (CEST)
Date: Tue, 21 Oct 2003 22:23:28 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: LK201 keyboard
Message-ID: <20031021202328.GO20846@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20031021131033.GM20846@lug-owl.de> <Pine.GSO.3.96.1031021152207.23366D-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="MTwtopHACupLeWZO"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1031021152207.23366D-100000@delta.ds2.pg.gda.pl>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
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: 3467
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1490
Lines: 44


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

On Tue, 2003-10-21 15:51:21 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
wrote in message <Pine.GSO.3.96.1031021152207.23366D-100000@delta.ds2.pg.gd=
a.pl>:
> > However, the "Set Mode" command (to set the repeat mode for a block of
> > keys) doesn't work for me on a lk201. Using a lk401 instead, these
> > commands work. Every time I send a set-mode command, I get a Input Error
> > (from the keyboard) sent back...
>=20
>  Strange -- these work for me.

What the "old" lk driver uses is more-or-less what could be referred as
power-on configuration. Even if there are set mode commande - if they
were ignored, it would silently work as expected. Could you set all
groups to "DOWN_UP_MODE" and verify that it no longer works?

MfG, JBG

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

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

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

iD8DBQE/lZXAHb1edYOZ4bsRAm1BAJ9HLgOXTRgqssnkz7CRUNendEmMggCeNwp+
OZBsp67WWsNunItm0YuBNew=
=qxdG
-----END PGP SIGNATURE-----

--MTwtopHACupLeWZO--

From dkesselr@mmc.atmel.com Tue Oct 21 22:23:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Oct 2003 22:23:04 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:48433
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225524AbTJUVXC>; Tue, 21 Oct 2003 22:23:02 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id RAA08931
	for <linux-mips@linux-mips.org>; Tue, 21 Oct 2003 17:22:50 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id RAA14456
	for <linux-mips@linux-mips.org>; Tue, 21 Oct 2003 17:22:49 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Tue, 21 Oct 2003 17:22:49 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: module dependency files
Message-ID: <Pine.GSO.4.44.0310211717110.14194-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3468
X-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
Content-Length: 572
Lines: 14

I have now gotten the modules to build but there is one part of the
process that doesn't work. On my pc I want to build all of the files which
are to be installed on the mips board. I am trying to create the files
which can be copied onto (or into) the redhat 7.3 miniport. "make modules"
works fine. It seems like I need to run "make modules_install" but it
complains about the .o files being the wrong architecture. So the basic
question seems to be how can I run depmod on the pc for mips?
Thanks again.

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


From jeff@theptrgroup.com Tue Oct 21 22:28:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Oct 2003 22:28:44 +0100 (BST)
Received: from mail.theptrgroup.com ([IPv6:::ffff:209.183.211.17]:37386 "EHLO
	mail.theptrgroup.com") by linux-mips.org with ESMTP
	id <S8225524AbTJUV2M>; Tue, 21 Oct 2003 22:28:12 +0100
Received: from [192.168.180.201] (stargate-tacsat.nrl.navy.mil [132.250.144.104] (may be forged))
	by mail.theptrgroup.com (8.11.6/linuxconf) with ESMTP id h9LLS6T17767;
	Tue, 21 Oct 2003 17:28:11 -0400
Subject: Re: module dependency files
From: Jeff Angielski <jeff@theptrgroup.com>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <Pine.GSO.4.44.0310211717110.14194-100000@ares.mmc.atmel.com>
References: <Pine.GSO.4.44.0310211717110.14194-100000@ares.mmc.atmel.com>
Content-Type: text/plain
Organization: 
Message-Id: <1066771519.3289.45.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 21 Oct 2003 17:25:20 -0400
Content-Transfer-Encoding: 7bit
Return-Path: <jeff@theptrgroup.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3469
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jeff@theptrgroup.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1092
Lines: 28

>From the Linux kernel Makefile...

#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots.  This is not defined in the
# makefile but the arguement can be passed to make if needed.
#
                                                                                Just set this to the location of your target filesystem when you do the modules_install.

Jeff Angielski
The PTR Group

On Tue, 2003-10-21 at 17:22, David Kesselring wrote:
> I have now gotten the modules to build but there is one part of the
> process that doesn't work. On my pc I want to build all of the files which
> are to be installed on the mips board. I am trying to create the files
> which can be copied onto (or into) the redhat 7.3 miniport. "make modules"
> works fine. It seems like I need to run "make modules_install" but it
> complains about the .o files being the wrong architecture. So the basic
> question seems to be how can I run depmod on the pc for mips?
> Thanks again.
> 
> David Kesselring
> Atmel MMC
> dkesselr@mmc.atmel.com
> 919-462-6587
> 


From dkesselr@mmc.atmel.com Tue Oct 21 23:16:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Oct 2003 23:16:05 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:32568
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225531AbTJUWQD>; Tue, 21 Oct 2003 23:16:03 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id SAA09380;
	Tue, 21 Oct 2003 18:15:56 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id SAA14660;
	Tue, 21 Oct 2003 18:15:56 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Tue, 21 Oct 2003 18:15:56 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: Jeff Angielski <jeff@theptrgroup.com>
cc: linux-mips@linux-mips.org
Subject: Re: module dependency files
In-Reply-To: <1066771519.3289.45.camel@localhost.localdomain>
Message-ID: <Pine.GSO.4.44.0310211814340.14473-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3470
X-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
Content-Length: 1361
Lines: 40

That's what I did. I defined INSTALL_MOD_PATH as $(TOPDIR)/modules. The
modules get put there but depmod fails.

On 21 Oct 2003, Jeff Angielski wrote:

> >From the Linux kernel Makefile...
>
> #
> # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
> # relocations required by build roots.  This is not defined in the
> # makefile but the arguement can be passed to make if needed.
> #
>                                                                                 Just set this to the location of your target filesystem when you do the modules_install.
>
> Jeff Angielski
> The PTR Group
>
> On Tue, 2003-10-21 at 17:22, David Kesselring wrote:
> > I have now gotten the modules to build but there is one part of the
> > process that doesn't work. On my pc I want to build all of the files which
> > are to be installed on the mips board. I am trying to create the files
> > which can be copied onto (or into) the redhat 7.3 miniport. "make modules"
> > works fine. It seems like I need to run "make modules_install" but it
> > complains about the .o files being the wrong architecture. So the basic
> > question seems to be how can I run depmod on the pc for mips?
> > Thanks again.
> >
> > David Kesselring
> > Atmel MMC
> > dkesselr@mmc.atmel.com
> > 919-462-6587
> >
>
>

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


From willy@www.linux.org.uk Wed Oct 22 00:09:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 00:09:39 +0100 (BST)
Received: from parcelfarce.linux.theplanet.co.uk ([IPv6:::ffff:195.92.249.252]:41364
	"EHLO www.linux.org.uk") by linux-mips.org with ESMTP
	id <S8225523AbTJUXJg>; Wed, 22 Oct 2003 00:09:36 +0100
Received: from willy by www.linux.org.uk with local (Exim 4.22)
	id 1AC5d6-0007t7-2Q; Wed, 22 Oct 2003 00:09:32 +0100
Date: Wed, 22 Oct 2003 00:09:32 +0100
From: Matthew Wilcox <willy@debian.org>
To: Ralf Baechle <ralf@linux-mips.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Jeff Dike <jdike@karaya.com>
Cc: linux-mips@linux-mips.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: asm/smplock.h is dead
Message-ID: <20031021230932.GM18370@parcelfarce.linux.theplanet.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <willy@www.linux.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3471
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: willy@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 758
Lines: 19


asm/smplock.h is dead, you're the only three arches that still have it.
Can you delete next time you merge?  Thanks.

$ find -type f |xargs grep smplock.h      
./arch/mips/sibyte/sb1250/bcm1250_tbprof.c:#include <asm/smplock.h>
./include/asm-h8300/smplock.h: * <asm/smplock.h>
./include/asm-um/smplock.h:#include "asm/arch/smplock.h"
$ find -name smplock.h
./include/asm-h8300/smplock.h
./include/asm-mips/smplock.h
./include/asm-um/smplock.h

(the sibyte driver can just lose this line.  it doesn't do any SMP locking)

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

From gherlein@herlein.com Wed Oct 22 00:47:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 00:47:23 +0100 (BST)
Received: from m205-235.dsl.tsoft.com ([IPv6:::ffff:198.144.205.235]:6284 "EHLO
	lists.herlein.com") by linux-mips.org with ESMTP
	id <S8225529AbTJUXrV>; Wed, 22 Oct 2003 00:47:21 +0100
Received: from io.herlein.com (io.herlein.com [192.168.70.244])
	by lists.herlein.com (Postfix) with ESMTP id B5F0FA39
	for <linux-mips@linux-mips.org>; Tue, 21 Oct 2003 16:55:34 -0700 (PDT)
Date: Tue, 21 Oct 2003 14:53:20 -0700 (PDT)
From: Greg Herlein <gherlein@herlein.com>
To: linux-mips@linux-mips.org
Subject: Au1500 kernel?
Message-ID: <Pine.LNX.4.44.0310211348290.3164-200000@io.herlein.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1463749562-694579970-1066773200=:3164"
Return-Path: <gherlein@herlein.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3472
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gherlein@herlein.com
Precedence: bulk
X-list: linux-mips
Content-Length: 21206
Lines: 371

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---1463749562-694579970-1066773200=:3164
Content-Type: TEXT/PLAIN; charset=US-ASCII

I grabbed the latest CVS code from linux-mips.org (2.6.0-test8) 
and tried to compile it with my cross-comiler environment - which 
is the toolchain that came with my Pb1500 development board that 
uses the Au1500 SOC chip.  My gcc is:

[gherlein@io linux]$ 
/usr/local/comp/mips-elf/gcc-3.2/bin/mips-elf-gcc -v
Reading specs from 
/usr/local/comp/mips-elf/gcc-3.2/lib/gcc-lib/mips-elf/3.2/specs
Configured with: ../gcc-3.2/configure --target=mips-elf 
--with-gnu-as --with-gnu-ld --with-newlib 
--prefix=/usr/local/comp/mips-elf/gcc-3.2 
--enable-languages=c,c++
Thread model: single
gcc version 3.2

But the lernel is failing at:

  CC      arch/mips/kernel/offset.s
In file included from include/linux/signal.h:7,
                 from include/linux/sched.h:25,
                 from arch/mips/kernel/offset.c:13:
include/asm/siginfo.h:83: flexible array member not at end of 
struct
make[1]: *** [arch/mips/kernel/offset.s] Error 1
make: *** [arch/mips/kernel/offset.s] Error 2

which smells like some new gcc'ism that is causing the issue.  Is 
anyone else seeing this?  Is there something I am doing wrong? 
Advice?  Suggestions?

Thanks in advance.

Greg

PS - I attached my .config for good measure, in case it matters 
(don't see how it would though)


---1463749562-694579970-1066773200=:3164
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=".config"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.44.0310211453200.3164@io.herlein.com>
Content-Description: 
Content-Disposition: attachment; filename=".config"

Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBtYWtlIGNvbmZpZzogZG9u
J3QgZWRpdA0KIw0KQ09ORklHX01JUFM9eQ0KIyBDT05GSUdfTUlQUzY0IGlz
IG5vdCBzZXQNCiMgQ09ORklHXzY0QklUIGlzIG5vdCBzZXQNCkNPTkZJR19N
SVBTMzI9eQ0KDQojDQojIENvZGUgbWF0dXJpdHkgbGV2ZWwgb3B0aW9ucw0K
Iw0KQ09ORklHX0VYUEVSSU1FTlRBTD15DQpDT05GSUdfQ0xFQU5fQ09NUElM
RT15DQpDT05GSUdfU1RBTkRBTE9ORT15DQpDT05GSUdfQlJPS0VOX09OX1NN
UD15DQoNCiMNCiMgR2VuZXJhbCBzZXR1cA0KIw0KQ09ORklHX1NXQVA9eQ0K
Q09ORklHX1NZU1ZJUEM9eQ0KIyBDT05GSUdfQlNEX1BST0NFU1NfQUNDVCBp
cyBub3Qgc2V0DQpDT05GSUdfU1lTQ1RMPXkNCkNPTkZJR19MT0dfQlVGX1NI
SUZUPTE0DQojIENPTkZJR19JS0NPTkZJRyBpcyBub3Qgc2V0DQpDT05GSUdf
RU1CRURERUQ9eQ0KQ09ORklHX0tBTExTWU1TPXkNCkNPTkZJR19GVVRFWD15
DQpDT05GSUdfRVBPTEw9eQ0KQ09ORklHX0lPU0NIRURfTk9PUD15DQpDT05G
SUdfSU9TQ0hFRF9BUz15DQpDT05GSUdfSU9TQ0hFRF9ERUFETElORT15DQoN
CiMNCiMgTG9hZGFibGUgbW9kdWxlIHN1cHBvcnQNCiMNCkNPTkZJR19NT0RV
TEVTPXkNCkNPTkZJR19NT0RVTEVfVU5MT0FEPXkNCiMgQ09ORklHX01PRFVM
RV9GT1JDRV9VTkxPQUQgaXMgbm90IHNldA0KQ09ORklHX09CU09MRVRFX01P
RFBBUk09eQ0KQ09ORklHX01PRFZFUlNJT05TPXkNCkNPTkZJR19LTU9EPXkN
Cg0KIw0KIyBNYWNoaW5lIHNlbGVjdGlvbg0KIw0KIyBDT05GSUdfQUNFUl9Q
SUNBXzYxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JBR0VUX01JUFMgaXMgbm90
IHNldA0KIyBDT05GSUdfQ0FTSU9fRTU1IGlzIG5vdCBzZXQNCiMgQ09ORklH
X01JUFNfQ09CQUxUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQ1NUQVRJT04g
aXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19FVjY0MTIwIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01JUFNfRVY5NjEwMCBpcyBub3Qgc2V0DQojIENPTkZJR19N
SVBTX0lWUiBpcyBub3Qgc2V0DQojIENPTkZJR19MQVNBVCBpcyBub3Qgc2V0
DQojIENPTkZJR19IUF9MQVNFUkpFVCBpcyBub3Qgc2V0DQojIENPTkZJR19J
Qk1fV09SS1BBRCBpcyBub3Qgc2V0DQojIENPTkZJR19NSVBTX0lURTgxNzIg
aXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19BVExBUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19NSVBTX01BR05VTV80MDAwIGlzIG5vdCBzZXQNCiMgQ09ORklH
X01JUFNfTUFMVEEgaXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19TRUFEIGlz
IG5vdCBzZXQNCiMgQ09ORklHX01PTUVOQ09fT0NFTE9UIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01PTUVOQ09fT0NFTE9UX0cgaXMgbm90IHNldA0KIyBDT05G
SUdfTU9NRU5DT19PQ0VMT1RfQyBpcyBub3Qgc2V0DQojIENPTkZJR19NT01F
TkNPX0pBR1VBUl9BVFggaXMgbm90IHNldA0KIyBDT05GSUdfRERCNTA3NCBp
cyBub3Qgc2V0DQojIENPTkZJR19EREI1NDc2IGlzIG5vdCBzZXQNCiMgQ09O
RklHX0REQjU0NzcgaXMgbm90IHNldA0KIyBDT05GSUdfTkVDX09TUFJFWSBp
cyBub3Qgc2V0DQojIENPTkZJR19ORUNfRUFHTEUgaXMgbm90IHNldA0KIyBD
T05GSUdfT0xJVkVUVElfTTcwMCBpcyBub3Qgc2V0DQojIENPTkZJR19TR0lf
SVAyMiBpcyBub3Qgc2V0DQojIENPTkZJR19TR0lfSVAzMiBpcyBub3Qgc2V0
DQpDT05GSUdfU09DX0FVMVgwMD15DQojIENPTkZJR19TT0NfQVUxMDAwIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1NPQ19BVTExMDAgaXMgbm90IHNldA0KQ09O
RklHX1NPQ19BVTE1MDA9eQ0KIyBDT05GSUdfTUlQU19QQjEwMDAgaXMgbm90
IHNldA0KIyBDT05GSUdfTUlQU19QQjExMDAgaXMgbm90IHNldA0KQ09ORklH
X01JUFNfUEIxNTAwPXkNCiMgQ09ORklHX01JUFNfREIxMDAwIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX01JUFNfREIxMTAwIGlzIG5vdCBzZXQNCiMgQ09ORklH
X01JUFNfREIxNTAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfQk9TUE9S
VVMgaXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19NSVJBR0UgaXMgbm90IHNl
dA0KIyBDT05GSUdfTUlQU19YWFMxNTAwIGlzIG5vdCBzZXQNCiMgQ09ORklH
X01JUFNfTVRYMSBpcyBub3Qgc2V0DQojIENPTkZJR19TSUJZVEVfU0IxeHh4
X1NPQyBpcyBub3Qgc2V0DQojIENPTkZJR19TTklfUk0yMDBfUENJIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1RBTkJBQ19UQjAyMjYgaXMgbm90IHNldA0KIyBD
T05GSUdfVEFOQkFDX1RCMDIyOSBpcyBub3Qgc2V0DQojIENPTkZJR19UT1NI
SUJBX0pNUjM5MjcgaXMgbm90IHNldA0KIyBDT05GSUdfVE9TSElCQV9SQlRY
NDkyNyBpcyBub3Qgc2V0DQojIENPTkZJR19WSUNUT1JfTVBDMzBYIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1pBT19DQVBDRUxMQSBpcyBub3Qgc2V0DQpDT05G
SUdfUEFHRV9TSVpFXzRLQj15DQojIENPTkZJR19QQUdFX1NJWkVfMTZLQiBp
cyBub3Qgc2V0DQojIENPTkZJR19QQUdFX1NJWkVfNjRLQiBpcyBub3Qgc2V0
DQpDT05GSUdfUldTRU1fR0VORVJJQ19TUElOTE9DSz15DQpDT05GSUdfTk9O
Q09IRVJFTlRfSU89eQ0KQ09ORklHX0NQVV9MSVRUTEVfRU5ESUFOPXkNCkNP
TkZJR19ORVdfUENJPXkNCiMgQ09ORklHX0FVMTAwMF9VU0JfREVWSUNFIGlz
IG5vdCBzZXQNCkNPTkZJR19NSVBTX0wxX0NBQ0hFX1NISUZUPTUNCiMgQ09O
RklHX0ZCIGlzIG5vdCBzZXQNCg0KIw0KIyBDUFUgc2VsZWN0aW9uDQojDQpD
T05GSUdfQ1BVX01JUFMzMj15DQojIENPTkZJR19DUFVfTUlQUzY0IGlzIG5v
dCBzZXQNCiMgQ09ORklHX0NQVV9SMzAwMCBpcyBub3Qgc2V0DQojIENPTkZJ
R19DUFVfVFgzOVhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9WUjQxWFgg
aXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1I0MzAwIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0NQVV9SNFgwMCBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfVFg0
OVhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9SNTAwMCBpcyBub3Qgc2V0
DQojIENPTkZJR19DUFVfUjU0MzIgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BV
X1I2MDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9ORVZBREEgaXMgbm90
IHNldA0KIyBDT05GSUdfQ1BVX1I4MDAwIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0NQVV9SMTAwMDAgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1JNNzAwMCBp
cyBub3Qgc2V0DQojIENPTkZJR19DUFVfUk05MDAwIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0NQVV9TQjEgaXMgbm90IHNldA0KQ09ORklHX0NQVV9IQVNfUFJF
RkVUQ0g9eQ0KIyBDT05GSUdfVlRBR19JQ0FDSEUgaXMgbm90IHNldA0KIyBD
T05GSUdfNjRCSVRfUEhZU19BRERSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQ
VV9BRFZBTkNFRCBpcyBub3Qgc2V0DQpDT05GSUdfQ1BVX0hBU19MTFNDPXkN
CkNPTkZJR19DUFVfSEFTX1NZTkM9eQ0KIyBDT05GSUdfUFJFRU1QVCBpcyBu
b3Qgc2V0DQojIENPTkZJR19ERUJVR19TUElOTE9DS19TTEVFUCBpcyBub3Qg
c2V0DQoNCiMNCiMgQnVzIG9wdGlvbnMgKFBDSSwgUENNQ0lBLCBFSVNBLCBJ
U0EsIFRDKQ0KIw0KIyBDT05GSUdfUENJIGlzIG5vdCBzZXQNCkNPTkZJR19N
TVU9eQ0KQ09ORklHX0hPVFBMVUc9eQ0KDQojDQojIFBDTUNJQS9DYXJkQnVz
IHN1cHBvcnQNCiMNCkNPTkZJR19QQ01DSUE9bQ0KIyBDT05GSUdfVENJQyBp
cyBub3Qgc2V0DQoNCiMNCiMgUENJIEhvdHBsdWcgU3VwcG9ydA0KIw0KDQoj
DQojIEV4ZWN1dGFibGUgZmlsZSBmb3JtYXRzDQojDQpDT05GSUdfQklORk1U
X0VMRj15DQojIENPTkZJR19CSU5GTVRfTUlTQyBpcyBub3Qgc2V0DQpDT05G
SUdfVFJBRF9TSUdOQUxTPXkNCiMgQ09ORklHX1BNIGlzIG5vdCBzZXQNCg0K
Iw0KIyBEZXZpY2UgRHJpdmVycw0KIw0KDQojDQojIEdlbmVyaWMgRHJpdmVy
IE9wdGlvbnMNCiMNCiMgQ09ORklHX0ZXX0xPQURFUiBpcyBub3Qgc2V0DQoN
CiMNCiMgTWVtb3J5IFRlY2hub2xvZ3kgRGV2aWNlcyAoTVREKQ0KIw0KIyBD
T05GSUdfTVREIGlzIG5vdCBzZXQNCg0KIw0KIyBQYXJhbGxlbCBwb3J0IHN1
cHBvcnQNCiMNCiMgQ09ORklHX1BBUlBPUlQgaXMgbm90IHNldA0KDQojDQoj
IFBsdWcgYW5kIFBsYXkgc3VwcG9ydA0KIw0KIyBDT05GSUdfUE5QIGlzIG5v
dCBzZXQNCg0KIw0KIyBCbG9jayBkZXZpY2VzDQojDQojIENPTkZJR19CTEtf
REVWX0ZEIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0xPT1A9eQ0KIyBD
T05GSUdfQkxLX0RFVl9DUllQVE9MT09QIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0JMS19ERVZfTkJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfUkFN
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSU5JVFJEIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0xCRCBpcyBub3Qgc2V0DQoNCiMNCiMgQVRBL0FUQVBJ
L01GTS9STEwgc3VwcG9ydA0KIw0KIyBDT05GSUdfSURFIGlzIG5vdCBzZXQN
Cg0KIw0KIyBTQ1NJIGRldmljZSBzdXBwb3J0DQojDQojIENPTkZJR19TQ1NJ
IGlzIG5vdCBzZXQNCg0KIw0KIyBNdWx0aS1kZXZpY2Ugc3VwcG9ydCAoUkFJ
RCBhbmQgTFZNKQ0KIw0KIyBDT05GSUdfTUQgaXMgbm90IHNldA0KDQojDQoj
IEZ1c2lvbiBNUFQgZGV2aWNlIHN1cHBvcnQNCiMNCg0KIw0KIyBJMk8gZGV2
aWNlIHN1cHBvcnQNCiMNCg0KIw0KIyBOZXR3b3JraW5nIHN1cHBvcnQNCiMN
CkNPTkZJR19ORVQ9eQ0KDQojDQojIE5ldHdvcmtpbmcgb3B0aW9ucw0KIw0K
Q09ORklHX1BBQ0tFVD15DQojIENPTkZJR19QQUNLRVRfTU1BUCBpcyBub3Qg
c2V0DQpDT05GSUdfTkVUTElOS19ERVY9eQ0KQ09ORklHX1VOSVg9eQ0KQ09O
RklHX05FVF9LRVk9eQ0KQ09ORklHX0lORVQ9eQ0KQ09ORklHX0lQX01VTFRJ
Q0FTVD15DQojIENPTkZJR19JUF9BRFZBTkNFRF9ST1VURVIgaXMgbm90IHNl
dA0KQ09ORklHX0lQX1BOUD15DQojIENPTkZJR19JUF9QTlBfREhDUCBpcyBu
b3Qgc2V0DQpDT05GSUdfSVBfUE5QX0JPT1RQPXkNCiMgQ09ORklHX0lQX1BO
UF9SQVJQIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9JUElQIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX05FVF9JUEdSRSBpcyBub3Qgc2V0DQojIENPTkZJR19J
UF9NUk9VVEUgaXMgbm90IHNldA0KIyBDT05GSUdfQVJQRCBpcyBub3Qgc2V0
DQojIENPTkZJR19JTkVUX0VDTiBpcyBub3Qgc2V0DQojIENPTkZJR19TWU5f
Q09PS0lFUyBpcyBub3Qgc2V0DQojIENPTkZJR19JTkVUX0FIIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0lORVRfRVNQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lO
RVRfSVBDT01QIGlzIG5vdCBzZXQNCg0KIw0KIyBJUDogVmlydHVhbCBTZXJ2
ZXIgQ29uZmlndXJhdGlvbg0KIw0KIyBDT05GSUdfSVBfVlMgaXMgbm90IHNl
dA0KIyBDT05GSUdfSVBWNiBpcyBub3Qgc2V0DQojIENPTkZJR19ERUNORVQg
aXMgbm90IHNldA0KIyBDT05GSUdfQlJJREdFIGlzIG5vdCBzZXQNCkNPTkZJ
R19ORVRGSUxURVI9eQ0KIyBDT05GSUdfTkVURklMVEVSX0RFQlVHIGlzIG5v
dCBzZXQNCg0KIw0KIyBJUDogTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24NCiMN
CiMgQ09ORklHX0lQX05GX0NPTk5UUkFDSyBpcyBub3Qgc2V0DQojIENPTkZJ
R19JUF9ORl9RVUVVRSBpcyBub3Qgc2V0DQojIENPTkZJR19JUF9ORl9JUFRB
QkxFUyBpcyBub3Qgc2V0DQojIENPTkZJR19JUF9ORl9BUlBUQUJMRVMgaXMg
bm90IHNldA0KIyBDT05GSUdfSVBfTkZfQ09NUEFUX0lQQ0hBSU5TIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0lQX05GX0NPTVBBVF9JUEZXQURNIGlzIG5vdCBz
ZXQNCkNPTkZJR19YRlJNPXkNCiMgQ09ORklHX1hGUk1fVVNFUiBpcyBub3Qg
c2V0DQoNCiMNCiMgU0NUUCBDb25maWd1cmF0aW9uIChFWFBFUklNRU5UQUwp
DQojDQpDT05GSUdfSVBWNl9TQ1RQX189eQ0KIyBDT05GSUdfSVBfU0NUUCBp
cyBub3Qgc2V0DQojIENPTkZJR19BVE0gaXMgbm90IHNldA0KIyBDT05GSUdf
VkxBTl84MDIxUSBpcyBub3Qgc2V0DQojIENPTkZJR19MTEMyIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0lQWCBpcyBub3Qgc2V0DQojIENPTkZJR19BVEFMSyBp
cyBub3Qgc2V0DQojIENPTkZJR19YMjUgaXMgbm90IHNldA0KIyBDT05GSUdf
TEFQQiBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfRElWRVJUIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0VDT05FVCBpcyBub3Qgc2V0DQojIENPTkZJR19XQU5f
Uk9VVEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9GQVNUUk9VVEUgaXMg
bm90IHNldA0KIyBDT05GSUdfTkVUX0hXX0ZMT1dDT05UUk9MIGlzIG5vdCBz
ZXQNCg0KIw0KIyBRb1MgYW5kL29yIGZhaXIgcXVldWVpbmcNCiMNCiMgQ09O
RklHX05FVF9TQ0hFRCBpcyBub3Qgc2V0DQoNCiMNCiMgTmV0d29yayB0ZXN0
aW5nDQojDQojIENPTkZJR19ORVRfUEtUR0VOIGlzIG5vdCBzZXQNCkNPTkZJ
R19ORVRERVZJQ0VTPXkNCiMgQ09ORklHX0RVTU1ZIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0JPTkRJTkcgaXMgbm90IHNldA0KIyBDT05GSUdfRVFVQUxJWkVS
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1RVTiBpcyBub3Qgc2V0DQojIENPTkZJ
R19FVEhFUlRBUCBpcyBub3Qgc2V0DQoNCiMNCiMgRXRoZXJuZXQgKDEwIG9y
IDEwME1iaXQpDQojDQpDT05GSUdfTkVUX0VUSEVSTkVUPXkNCiMgQ09ORklH
X01JSSBpcyBub3Qgc2V0DQpDT05GSUdfTUlQU19BVTFYMDBfRU5FVD15DQoN
CiMNCiMgRXRoZXJuZXQgKDEwMDAgTWJpdCkNCiMNCg0KIw0KIyBFdGhlcm5l
dCAoMTAwMDAgTWJpdCkNCiMNCkNPTkZJR19QUFA9bQ0KQ09ORklHX1BQUF9N
VUxUSUxJTks9eQ0KIyBDT05GSUdfUFBQX0ZJTFRFUiBpcyBub3Qgc2V0DQpD
T05GSUdfUFBQX0FTWU5DPW0NCiMgQ09ORklHX1BQUF9TWU5DX1RUWSBpcyBu
b3Qgc2V0DQpDT05GSUdfUFBQX0RFRkxBVEU9bQ0KIyBDT05GSUdfUFBQX0JT
RENPTVAgaXMgbm90IHNldA0KQ09ORklHX1BQUE9FPW0NCiMgQ09ORklHX1NM
SVAgaXMgbm90IHNldA0KDQojDQojIFdpcmVsZXNzIExBTiAobm9uLWhhbXJh
ZGlvKQ0KIw0KIyBDT05GSUdfTkVUX1JBRElPIGlzIG5vdCBzZXQNCg0KIw0K
IyBUb2tlbiBSaW5nIGRldmljZXMNCiMNCiMgQ09ORklHX1NIQVBFUiBpcyBu
b3Qgc2V0DQoNCiMNCiMgV2FuIGludGVyZmFjZXMNCiMNCiMgQ09ORklHX1dB
TiBpcyBub3Qgc2V0DQoNCiMNCiMgUENNQ0lBIG5ldHdvcmsgZGV2aWNlIHN1
cHBvcnQNCiMNCkNPTkZJR19ORVRfUENNQ0lBPXkNCkNPTkZJR19QQ01DSUFf
M0M1ODk9bQ0KIyBDT05GSUdfUENNQ0lBXzNDNTc0IGlzIG5vdCBzZXQNCiMg
Q09ORklHX1BDTUNJQV9GTVZKMThYIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BD
TUNJQV9QQ05FVCBpcyBub3Qgc2V0DQojIENPTkZJR19QQ01DSUFfTk1DTEFO
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1BDTUNJQV9TTUM5MUM5MiBpcyBub3Qg
c2V0DQojIENPTkZJR19QQ01DSUFfWElSQzJQUyBpcyBub3Qgc2V0DQojIENP
TkZJR19QQ01DSUFfQVhORVQgaXMgbm90IHNldA0KDQojDQojIEFtYXRldXIg
UmFkaW8gc3VwcG9ydA0KIw0KIyBDT05GSUdfSEFNUkFESU8gaXMgbm90IHNl
dA0KDQojDQojIElyREEgKGluZnJhcmVkKSBzdXBwb3J0DQojDQojIENPTkZJ
R19JUkRBIGlzIG5vdCBzZXQNCg0KIw0KIyBCbHVldG9vdGggc3VwcG9ydA0K
Iw0KIyBDT05GSUdfQlQgaXMgbm90IHNldA0KDQojDQojIElTRE4gc3Vic3lz
dGVtDQojDQojIENPTkZJR19JU0ROX0JPT0wgaXMgbm90IHNldA0KDQojDQoj
IFRlbGVwaG9ueSBTdXBwb3J0DQojDQojIENPTkZJR19QSE9ORSBpcyBub3Qg
c2V0DQoNCiMNCiMgSW5wdXQgZGV2aWNlIHN1cHBvcnQNCiMNCkNPTkZJR19J
TlBVVD15DQoNCiMNCiMgVXNlcmxhbmQgaW50ZXJmYWNlcw0KIw0KQ09ORklH
X0lOUFVUX01PVVNFREVWPXkNCkNPTkZJR19JTlBVVF9NT1VTRURFVl9QU0FV
WD15DQpDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1g9MTAyNA0KQ09O
RklHX0lOUFVUX01PVVNFREVWX1NDUkVFTl9ZPTc2OA0KIyBDT05GSUdfSU5Q
VVRfSk9ZREVWIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX1RTREVWIGlz
IG5vdCBzZXQNCkNPTkZJR19JTlBVVF9FVkRFVj15DQojIENPTkZJR19JTlBV
VF9FVkJVRyBpcyBub3Qgc2V0DQoNCiMNCiMgSW5wdXQgSS9PIGRyaXZlcnMN
CiMNCiMgQ09ORklHX0dBTUVQT1JUIGlzIG5vdCBzZXQNCkNPTkZJR19TT1VO
RF9HQU1FUE9SVD15DQpDT05GSUdfU0VSSU89eQ0KIyBDT05GSUdfU0VSSU9f
STgwNDIgaXMgbm90IHNldA0KQ09ORklHX1NFUklPX1NFUlBPUlQ9eQ0KIyBD
T05GSUdfU0VSSU9fQ1Q4MkM3MTAgaXMgbm90IHNldA0KDQojDQojIElucHV0
IERldmljZSBEcml2ZXJzDQojDQojIENPTkZJR19JTlBVVF9LRVlCT0FSRCBp
cyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9NT1VTRSBpcyBub3Qgc2V0DQoj
IENPTkZJR19JTlBVVF9KT1lTVElDSyBpcyBub3Qgc2V0DQojIENPTkZJR19J
TlBVVF9UT1VDSFNDUkVFTiBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9N
SVNDIGlzIG5vdCBzZXQNCg0KIw0KIyBDaGFyYWN0ZXIgZGV2aWNlcw0KIw0K
Q09ORklHX1ZUPXkNCkNPTkZJR19WVF9DT05TT0xFPXkNCkNPTkZJR19IV19D
T05TT0xFPXkNCiMgQ09ORklHX1NFUklBTF9OT05TVEFOREFSRCBpcyBub3Qg
c2V0DQojIENPTkZJR19BVTFYMDBfR1BJTyBpcyBub3Qgc2V0DQojIENPTkZJ
R19UU19BVTFYMDBfQURTNzg0NiBpcyBub3Qgc2V0DQoNCiMNCiMgU2VyaWFs
IGRyaXZlcnMNCiMNCiMgQ09ORklHX1NFUklBTF84MjUwIGlzIG5vdCBzZXQN
Cg0KIw0KIyBOb24tODI1MCBzZXJpYWwgcG9ydCBzdXBwb3J0DQojDQpDT05G
SUdfU0VSSUFMX0FVMVgwMD15DQpDT05GSUdfU0VSSUFMX0FVMVgwMF9DT05T
T0xFPXkNCkNPTkZJR19TRVJJQUxfQ09SRT15DQpDT05GSUdfU0VSSUFMX0NP
UkVfQ09OU09MRT15DQpDT05GSUdfVU5JWDk4X1BUWVM9eQ0KQ09ORklHX1VO
SVg5OF9QVFlfQ09VTlQ9MjU2DQoNCiMNCiMgSTJDIHN1cHBvcnQNCiMNCiMg
Q09ORklHX0kyQyBpcyBub3Qgc2V0DQoNCiMNCiMgSTJDIEFsZ29yaXRobXMN
CiMNCg0KIw0KIyBJMkMgSGFyZHdhcmUgQnVzIHN1cHBvcnQNCiMNCg0KIw0K
IyBJMkMgSGFyZHdhcmUgU2Vuc29ycyBDaGlwIHN1cHBvcnQNCiMNCiMgQ09O
RklHX0kyQ19TRU5TT1IgaXMgbm90IHNldA0KDQojDQojIE1pY2UNCiMNCiMg
Q09ORklHX0JVU01PVVNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1FJQzAyX1RB
UEUgaXMgbm90IHNldA0KDQojDQojIElQTUkNCiMNCiMgQ09ORklHX0lQTUlf
SEFORExFUiBpcyBub3Qgc2V0DQoNCiMNCiMgV2F0Y2hkb2cgQ2FyZHMNCiMN
CiMgQ09ORklHX1dBVENIRE9HIGlzIG5vdCBzZXQNCiMgQ09ORklHX05WUkFN
IGlzIG5vdCBzZXQNCkNPTkZJR19SVEM9eQ0KIyBDT05GSUdfRFRMSyBpcyBu
b3Qgc2V0DQojIENPTkZJR19SMzk2NCBpcyBub3Qgc2V0DQojIENPTkZJR19B
UFBMSUNPTSBpcyBub3Qgc2V0DQoNCiMNCiMgRnRhcGUsIHRoZSBmbG9wcHkg
dGFwZSBkZXZpY2UgZHJpdmVyDQojDQojIENPTkZJR19GVEFQRSBpcyBub3Qg
c2V0DQojIENPTkZJR19BR1AgaXMgbm90IHNldA0KIyBDT05GSUdfRFJNIGlz
IG5vdCBzZXQNCg0KIw0KIyBQQ01DSUEgY2hhcmFjdGVyIGRldmljZXMNCiMN
CiMgQ09ORklHX1NZTkNMSU5LX0NTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JB
V19EUklWRVIgaXMgbm90IHNldA0KDQojDQojIE11bHRpbWVkaWEgZGV2aWNl
cw0KIw0KIyBDT05GSUdfVklERU9fREVWIGlzIG5vdCBzZXQNCg0KIw0KIyBE
aWdpdGFsIFZpZGVvIEJyb2FkY2FzdGluZyBEZXZpY2VzDQojDQojIENPTkZJ
R19EVkIgaXMgbm90IHNldA0KDQojDQojIEdyYXBoaWNzIHN1cHBvcnQNCiMN
Cg0KIw0KIyBDb25zb2xlIGRpc3BsYXkgZHJpdmVyIHN1cHBvcnQNCiMNCiMg
Q09ORklHX1ZHQV9DT05TT0xFIGlzIG5vdCBzZXQNCiMgQ09ORklHX01EQV9D
T05TT0xFIGlzIG5vdCBzZXQNCkNPTkZJR19EVU1NWV9DT05TT0xFPXkNCg0K
Iw0KIyBTb3VuZA0KIw0KIyBDT05GSUdfU09VTkQgaXMgbm90IHNldA0KDQoj
DQojIFVTQiBzdXBwb3J0DQojDQojIENPTkZJR19VU0JfR0FER0VUIGlzIG5v
dCBzZXQNCg0KIw0KIyBGaWxlIHN5c3RlbXMNCiMNCkNPTkZJR19FWFQyX0ZT
PXkNCkNPTkZJR19FWFQyX0ZTX1hBVFRSPXkNCkNPTkZJR19FWFQyX0ZTX1BP
U0lYX0FDTD15DQojIENPTkZJR19FWFQyX0ZTX1NFQ1VSSVRZIGlzIG5vdCBz
ZXQNCkNPTkZJR19FWFQzX0ZTPXkNCkNPTkZJR19FWFQzX0ZTX1hBVFRSPXkN
CkNPTkZJR19FWFQzX0ZTX1BPU0lYX0FDTD15DQpDT05GSUdfRVhUM19GU19T
RUNVUklUWT15DQpDT05GSUdfSkJEPXkNCiMgQ09ORklHX0pCRF9ERUJVRyBp
cyBub3Qgc2V0DQpDT05GSUdfRlNfTUJDQUNIRT15DQpDT05GSUdfUkVJU0VS
RlNfRlM9bQ0KIyBDT05GSUdfUkVJU0VSRlNfQ0hFQ0sgaXMgbm90IHNldA0K
IyBDT05GSUdfUkVJU0VSRlNfUFJPQ19JTkZPIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0pGU19GUyBpcyBub3Qgc2V0DQpDT05GSUdfRlNfUE9TSVhfQUNMPXkN
CiMgQ09ORklHX1hGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19NSU5JWF9G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19ST01GU19GUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19RVU9UQSBpcyBub3Qgc2V0DQpDT05GSUdfQVVUT0ZTX0ZTPW0N
CkNPTkZJR19BVVRPRlM0X0ZTPW0NCg0KIw0KIyBDRC1ST00vRFZEIEZpbGVz
eXN0ZW1zDQojDQojIENPTkZJR19JU085NjYwX0ZTIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1VERl9GUyBpcyBub3Qgc2V0DQoNCiMNCiMgRE9TL0ZBVC9OVCBG
aWxlc3lzdGVtcw0KIw0KIyBDT05GSUdfRkFUX0ZTIGlzIG5vdCBzZXQNCiMg
Q09ORklHX05URlNfRlMgaXMgbm90IHNldA0KDQojDQojIFBzZXVkbyBmaWxl
c3lzdGVtcw0KIw0KQ09ORklHX1BST0NfRlM9eQ0KQ09ORklHX1BST0NfS0NP
UkU9eQ0KIyBDT05GSUdfREVWRlNfRlMgaXMgbm90IHNldA0KQ09ORklHX0RF
VlBUU19GUz15DQpDT05GSUdfREVWUFRTX0ZTX1hBVFRSPXkNCkNPTkZJR19E
RVZQVFNfRlNfU0VDVVJJVFk9eQ0KQ09ORklHX1RNUEZTPXkNCiMgQ09ORklH
X0hVR0VUTEJfUEFHRSBpcyBub3Qgc2V0DQpDT05GSUdfUkFNRlM9eQ0KDQoj
DQojIE1pc2NlbGxhbmVvdXMgZmlsZXN5c3RlbXMNCiMNCiMgQ09ORklHX0FE
RlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQUZGU19GUyBpcyBub3Qgc2V0
DQojIENPTkZJR19IRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQkVGU19G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19CRlNfRlMgaXMgbm90IHNldA0KIyBD
T05GSUdfRUZTX0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19DUkFNRlM9bQ0KIyBD
T05GSUdfVlhGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19IUEZTX0ZTIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1FOWDRGU19GUyBpcyBub3Qgc2V0DQojIENP
TkZJR19TWVNWX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VGU19GUyBpcyBu
b3Qgc2V0DQoNCiMNCiMgTmV0d29yayBGaWxlIFN5c3RlbXMNCiMNCkNPTkZJ
R19ORlNfRlM9eQ0KIyBDT05GSUdfTkZTX1YzIGlzIG5vdCBzZXQNCiMgQ09O
RklHX05GU19WNCBpcyBub3Qgc2V0DQojIENPTkZJR19ORlNfRElSRUNUSU8g
aXMgbm90IHNldA0KQ09ORklHX05GU0Q9bQ0KIyBDT05GSUdfTkZTRF9WMyBp
cyBub3Qgc2V0DQojIENPTkZJR19ORlNEX1RDUCBpcyBub3Qgc2V0DQpDT05G
SUdfUk9PVF9ORlM9eQ0KQ09ORklHX0xPQ0tEPXkNCkNPTkZJR19FWFBPUlRG
Uz1tDQpDT05GSUdfU1VOUlBDPXkNCiMgQ09ORklHX1NVTlJQQ19HU1MgaXMg
bm90IHNldA0KQ09ORklHX1NNQl9GUz1tDQojIENPTkZJR19TTUJfTkxTX0RF
RkFVTFQgaXMgbm90IHNldA0KIyBDT05GSUdfQ0lGUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19OQ1BfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQ09EQV9GUyBp
cyBub3Qgc2V0DQojIENPTkZJR19JTlRFUk1FWlpPX0ZTIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0FGU19GUyBpcyBub3Qgc2V0DQoNCiMNCiMgUGFydGl0aW9u
IFR5cGVzDQojDQojIENPTkZJR19QQVJUSVRJT05fQURWQU5DRUQgaXMgbm90
IHNldA0KQ09ORklHX01TRE9TX1BBUlRJVElPTj15DQpDT05GSUdfU01CX05M
Uz15DQpDT05GSUdfTkxTPXkNCg0KIw0KIyBOYXRpdmUgTGFuZ3VhZ2UgU3Vw
cG9ydA0KIw0KQ09ORklHX05MU19ERUZBVUxUPSJpc284ODU5LTEiDQojIENP
TkZJR19OTFNfQ09ERVBBR0VfNDM3IGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
U19DT0RFUEFHRV83MzcgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ
QUdFXzc3NSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODUw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NTIgaXMgbm90
IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NSBpcyBub3Qgc2V0DQoj
IENPTkZJR19OTFNfQ09ERVBBR0VfODU3IGlzIG5vdCBzZXQNCiMgQ09ORklH
X05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NP
REVQQUdFXzg2MSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0Vf
ODYyIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjMgaXMg
bm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NCBpcyBub3Qgc2V0
DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODY1IGlzIG5vdCBzZXQNCiMgQ09O
RklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNldA0KIyBDT05GSUdfTkxT
X0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBB
R0VfOTM2IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV85NTAg
aXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzkzMiBpcyBub3Qg
c2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfOTQ5IGlzIG5vdCBzZXQNCiMg
Q09ORklHX05MU19DT0RFUEFHRV84NzQgaXMgbm90IHNldA0KIyBDT05GSUdf
TkxTX0lTTzg4NTlfOCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBB
R0VfMTI1MCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfMTI1
MSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV8xIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX05MU19JU084ODU5XzIgaXMgbm90IHNldA0KIyBDT05G
SUdfTkxTX0lTTzg4NTlfMyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNP
ODg1OV80IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzUgaXMg
bm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfNiBpcyBub3Qgc2V0DQoj
IENPTkZJR19OTFNfSVNPODg1OV83IGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
U19JU084ODU5XzkgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlf
MTMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMTQgaXMgbm90
IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMTUgaXMgbm90IHNldA0KIyBD
T05GSUdfTkxTX0tPSThfUiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfS09J
OF9VIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19VVEY4IGlzIG5vdCBzZXQN
Cg0KIw0KIyBLZXJuZWwgaGFja2luZw0KIw0KQ09ORklHX0NST1NTQ09NUElM
RT15DQojIENPTkZJR19ERUJVR19LRVJORUwgaXMgbm90IHNldA0KDQojDQoj
IFNlY3VyaXR5IG9wdGlvbnMNCiMNCiMgQ09ORklHX1NFQ1VSSVRZIGlzIG5v
dCBzZXQNCg0KIw0KIyBDcnlwdG9ncmFwaGljIG9wdGlvbnMNCiMNCkNPTkZJ
R19DUllQVE89eQ0KQ09ORklHX0NSWVBUT19ITUFDPXkNCkNPTkZJR19DUllQ
VE9fTlVMTD15DQojIENPTkZJR19DUllQVE9fTUQ0IGlzIG5vdCBzZXQNCiMg
Q09ORklHX0NSWVBUT19NRDUgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRP
X1NIQTEgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX1NIQTI1NiBpcyBu
b3Qgc2V0DQpDT05GSUdfQ1JZUFRPX1NIQTUxMj15DQojIENPTkZJR19DUllQ
VE9fREVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSWVBUT19CTE9XRklTSCBp
cyBub3Qgc2V0DQpDT05GSUdfQ1JZUFRPX1RXT0ZJU0g9eQ0KIyBDT05GSUdf
Q1JZUFRPX1NFUlBFTlQgaXMgbm90IHNldA0KQ09ORklHX0NSWVBUT19BRVM9
eQ0KIyBDT05GSUdfQ1JZUFRPX0NBU1Q1IGlzIG5vdCBzZXQNCiMgQ09ORklH
X0NSWVBUT19DQVNUNiBpcyBub3Qgc2V0DQpDT05GSUdfQ1JZUFRPX0RFRkxB
VEU9eQ0KIyBDT05GSUdfQ1JZUFRPX1RFU1QgaXMgbm90IHNldA0KDQojDQoj
IExpYnJhcnkgcm91dGluZXMNCiMNCkNPTkZJR19DUkMzMj15DQpDT05GSUdf
WkxJQl9JTkZMQVRFPXkNCkNPTkZJR19aTElCX0RFRkxBVEU9eQ0K
---1463749562-694579970-1066773200=:3164--

From ppopov@mvista.com Wed Oct 22 01:26:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 01:26:20 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:33011 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225531AbTJVA0R>;
	Wed, 22 Oct 2003 01:26:17 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA15707;
	Tue, 21 Oct 2003 17:22:14 -0700
Subject: Re: Au1500 kernel?
From: Pete Popov <ppopov@mvista.com>
To: Greg Herlein <gherlein@herlein.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <Pine.LNX.4.44.0310211348290.3164-200000@io.herlein.com>
References: <Pine.LNX.4.44.0310211348290.3164-200000@io.herlein.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1066782264.21027.164.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 21 Oct 2003 17:24:24 -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: 3473
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1508
Lines: 41

On Tue, 2003-10-21 at 14:53, Greg Herlein wrote:
> I grabbed the latest CVS code from linux-mips.org (2.6.0-test8) 
> and tried to compile it with my cross-comiler environment - which 
> is the toolchain that came with my Pb1500 development board that 
> uses the Au1500 SOC chip.  My gcc is:
> 
> [gherlein@io linux]$ 
> /usr/local/comp/mips-elf/gcc-3.2/bin/mips-elf-gcc -v
> Reading specs from 
> /usr/local/comp/mips-elf/gcc-3.2/lib/gcc-lib/mips-elf/3.2/specs
> Configured with: ../gcc-3.2/configure --target=mips-elf 
> --with-gnu-as --with-gnu-ld --with-newlib 
> --prefix=/usr/local/comp/mips-elf/gcc-3.2 
> --enable-languages=c,c++
> Thread model: single
> gcc version 3.2
> 
> But the lernel is failing at:
> 
>   CC      arch/mips/kernel/offset.s
> In file included from include/linux/signal.h:7,
>                  from include/linux/sched.h:25,
>                  from arch/mips/kernel/offset.c:13:
> include/asm/siginfo.h:83: flexible array member not at end of 
> struct
> make[1]: *** [arch/mips/kernel/offset.s] Error 1
> make: *** [arch/mips/kernel/offset.s] Error 2
> 
> which smells like some new gcc'ism that is causing the issue.  Is 
> anyone else seeing this?  Is there something I am doing wrong? 
> Advice?  Suggestions?

I think I had the same problem, if I remember correctly, so I used the
2.95 compiler on linux-mips.org.

BTW, only serial console, ethernet, and MTD have been updated in 2.6. I
haven't had time for anything else yet, including the 36 bit address
support.

Pete


From ralf@linux-mips.org Wed Oct 22 02:13:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 02:13:39 +0100 (BST)
Received: from p508B7013.dip.t-dialin.net ([IPv6:::ffff:80.139.112.19]:5796
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225531AbTJVBNh>; Wed, 22 Oct 2003 02:13:37 +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 h9M1DSNK005469;
	Wed, 22 Oct 2003 03:13:28 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9M1DOrI005462;
	Wed, 22 Oct 2003 03:13:24 +0200
Date: Wed, 22 Oct 2003 03:13:24 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Matthew Wilcox <willy@debian.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>,
	Jeff Dike <jdike@karaya.com>, linux-mips@linux-mips.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: asm/smplock.h is dead
Message-ID: <20031022011324.GC2609@linux-mips.org>
References: <20031021230932.GM18370@parcelfarce.linux.theplanet.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031021230932.GM18370@parcelfarce.linux.theplanet.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: 3474
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 571
Lines: 18

On Wed, Oct 22, 2003 at 12:09:32AM +0100, Matthew Wilcox wrote:

> Can you delete next time you merge?  Thanks.
> 
> $ find -type f |xargs grep smplock.h      
> ./arch/mips/sibyte/sb1250/bcm1250_tbprof.c:#include <asm/smplock.h>
> ./include/asm-h8300/smplock.h: * <asm/smplock.h>
> ./include/asm-um/smplock.h:#include "asm/arch/smplock.h"
> $ find -name smplock.h
> ./include/asm-h8300/smplock.h
> ./include/asm-mips/smplock.h
> ./include/asm-um/smplock.h
> 
> (the sibyte driver can just lose this line.  it doesn't do any SMP locking)

Thanks, zapped on MIPS.

  Ralf

From gherlein@herlein.com Wed Oct 22 05:19:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 05:19:52 +0100 (BST)
Received: from m205-235.dsl.tsoft.com ([IPv6:::ffff:198.144.205.235]:32908
	"EHLO lists.herlein.com") by linux-mips.org with ESMTP
	id <S8225296AbTJVETu>; Wed, 22 Oct 2003 05:19:50 +0100
Received: from io.herlein.com (io.herlein.com [192.168.70.244])
	by lists.herlein.com (Postfix) with ESMTP
	id 344EFA32; Tue, 21 Oct 2003 21:28:06 -0700 (PDT)
Date: Tue, 21 Oct 2003 19:16:37 -0700 (PDT)
From: Greg Herlein <gherlein@herlein.com>
To: Pete Popov <ppopov@mvista.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Au1500 kernel?
In-Reply-To: <1066782264.21027.164.camel@zeus.mvista.com>
Message-ID: <Pine.LNX.4.44.0310211913380.3164-100000@io.herlein.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <gherlein@herlein.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3475
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gherlein@herlein.com
Precedence: bulk
X-list: linux-mips
Content-Length: 562
Lines: 17

> I think I had the same problem, if I remember correctly, so I used the
> 2.95 compiler on linux-mips.org.

Unfortunately when I try to install that it fails due to rpm hell 
(ie, dependencies).  Sigh.  OK, I can go rebuild it all from 
source.

> BTW, only serial console, ethernet, and MTD have been updated in 2.6. I
> haven't had time for anything else yet, including the 36 bit address
> support.

OK, I don't need the latest 2.6 stuff - where can I grab some 
tarballs of older 2.4 kernels with the mips patches applied - 
does such a thing exist?

Greg


From ppopov@mvista.com Wed Oct 22 06:01:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 06:01:33 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:2549 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225296AbTJVFBa>;
	Wed, 22 Oct 2003 06:01:30 +0100
Received: from [10.2.2.20] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id WAA21338;
	Tue, 21 Oct 2003 22:01:27 -0700
Subject: Re: Au1500 kernel?
From: Pete Popov <ppopov@mvista.com>
To: Greg Herlein <gherlein@herlein.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <Pine.LNX.4.44.0310211913380.3164-100000@io.herlein.com>
References: <Pine.LNX.4.44.0310211913380.3164-100000@io.herlein.com>
Content-Type: text/plain
Organization: 
Message-Id: <1066798906.28777.1.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 21 Oct 2003 22:01: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: 3476
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 917
Lines: 23

On Tue, 2003-10-21 at 19:16, Greg Herlein wrote:
> > I think I had the same problem, if I remember correctly, so I used the
> > 2.95 compiler on linux-mips.org.
> 
> Unfortunately when I try to install that it fails due to rpm hell 
> (ie, dependencies).  Sigh.  OK, I can go rebuild it all from 
> source.
> 
> > BTW, only serial console, ethernet, and MTD have been updated in 2.6. I
> > haven't had time for anything else yet, including the 36 bit address
> > support.
> 
> OK, I don't need the latest 2.6 stuff - where can I grab some 
> tarballs of older 2.4 kernels with the mips patches applied - 
> does such a thing exist?

Just grab the latest 2.4 branch, which is linux_2_4. The branch is at
2.4.22, so it's up to date with the 2.4 kernels. The patches in
/pub/linux/mips/people/ppopov should apply cleanly (there are 2.4.21 and
2.4.22 versions of some of the patches). Everything should work well.

Pete


From taoyong2002cncq@yahoo.com.cn Wed Oct 22 07:13:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 07:13:48 +0100 (BST)
Received: from smtp018.mail.yahoo.com ([IPv6:::ffff:216.136.174.115]:1434 "HELO
	smtp018.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225296AbTJVGNq>; Wed, 22 Oct 2003 07:13:46 +0100
Received: from unknown (HELO ime?ty) (taoyong2002cncq@61.186.188.65 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 22 Oct 2003 06:13:40 -0000
Date: Wed, 22 Oct 2003 14:16:35 +0800
From: "taoyong" <taoyong2002cncq@yahoo.com.cn>
Reply-To: taoyong2002cncq@yahoo.com.cn
To: "Linux MIPS mailing list" <linux-mips@linux-mips.org>
Subject: Is Yamon executed in flash or in RAM? 
Organization: cqu-swcims
X-mailer: Foxmail 5.0 beta2 [cn]
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=====001_Dragon882675286087_====="
Message-Id: <20031022061346Z8225296-1272+8254@linux-mips.org>
Return-Path: <taoyong2002cncq@yahoo.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3477
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: taoyong2002cncq@yahoo.com.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 13397
Lines: 196

This is a multi-part message in MIME format.

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

hi,
   
    Have anyone used the YAMON on PB1000? 
    I wonder whether it is executed in flash or in RAM.



best regards,
taoyong
taoyong2002cncq@yahoo.com.cn
2003-10-22

--=====001_Dragon882675286087_=====
Content-Type: image/gif;
	name="fox.gif"
Content-Transfer-Encoding: base64
Content-Disposition: FoxmailIcon;
	filename="fox.gif"

R0lGODlhIwAfALMLAP///+Dg4OCgAOCAAOAAAMDA4KCgwKBgQIAAAGBggCAgIAAAAAAAAAAAAAAA
AAAAACH/C05FVFNDQVBFMi4wAwHoAwAh+QQJDwALACwAAAAAIwAfAAAE+3DJSem5Na+jux3CxWWi
Zx5DIgiD6Lrgan6FoYZDzuborKGDQKEAXBl1Al/lEgwUjcaeTClhBpDQ6ECypYqwzauAuOhSN8BY
s6AoDBSjczW9atrcibicmQPZ229yS0AGNUEGCkIKghYiBgGQkZIKi4wHBoWSmgEGjHOXBZucnUov
aJeYhUM1pD58fRifCbMJe2Atcy2qBbWlWEdfApmQvD5uMVktFyGhkr0mbllQtCjNxM8dhdJ9CZi8
l5I12BlDyTndw92rNeIUBe6RddyqCQEJfSn1Nu4Tw8TKB9TdQSFAAa19/CRYE0JkRL5aChCAoISg
A6cFC4e0qqBgNlhEBLM0bNI4ToJBbwEofURQkcKjSKs2TlhJoGZNhrMQStjVTkNEmzbD8bLxLFXI
DiqTKl0aAQAh+QQJDwALACwCAAAAIQAfAAAE+3DJSeW5Na+jux3CxWWi1x1DIgiD6Lrgan6FoYZD
zuboXKGDQKEAXBl1At/kEgwUjcaeTMkMIKHRgUTrE12bVgFxwaUCY82CojBQjJSW86ppYyfecGYO
RF+3lQY1BoN6gQZBBgpCCjOBQ48GLgYBlJWWCowZBZaUQ5GDm5yWBhqhokIigaeDpaeVqYOOnqQd
pqJMcQcJuwkmm4+2UC0oB7K9HUKxjwFYTAKqnccVnryyUCIhtgHSFAE2EwmHMSu8KLYF3BMFGeJG
4YF3k5U16TUaewLvoeHAhty0GfDxQ7dtT4oE3tJ1MMivDgoBCqop9CBw1wIFCEBgQgCHL4LBYQqg
YURgseMGFxFBBcA0EgHHjiJaEpg5Uwi6cBNNYKRJ09IQnDk1sBxKtGgEACH5BAkPAAsALAgAAAAb
AB8AAAT7cMl56rz44H2GqBpnbVeXCMIArquHckNhnN9gp3ZHUnZQFB0XCvfaVQaBQHDI1BVFyBuz
OZBURUsUMukBLq4Lg48SdG0LisJAEcKIfUfpdqZOtN0FZdkzT693EgZ5cYIGSAYKPgqAYYMgb0mR
kQqLG4JwBpeSmwYkmnoHn5KZO5qPmYI/Mp2lP3oFEiAJswmMqZKwR6GqtZ6uuEcCnwW9GTcBAkkg
H3mSxTxCWrQdzUnEGzbRAgmZxKG4MxhSQ9ya3KoyMs/ZTOfEAQnZA7MB4RPs5IUJQB4KtPb35JGb
tUABgn4GAcmTV0GBJoMICJJYCMJftwCUICJAYGQahUYCIEH6IMbtGQmDIUPiIjbD5IWMMGPKjAAA
IfkECQ8ACwAsBQAAAB4AHwAABPtwyTmPpbjmvc4Q1rGFXOYlgjCELPulpVcYKDjc6u2VlDcEhYIv
RcQJeBLLLzAkEncwnjJgdD4HEmxM+VIFvh/hQiv1vZYFRWGgECGT5tSStk6431zcXM1+LwwGHT4G
Mz8GCkAKfhIGLAZfkJEBCopvjYAFkpKBSJghhJoBgDyAoJ+lQUGjJZiZTHchCbIJpISuX5yCK7YF
tBu8kblKAqBfvRm2mxUWILdfvhTFwROzMpHHGKA/RSIJmHaPkDPQEzddOd7F3qkz4xjmTjfrvQEJ
5gOyouRj8E7rdB4EKJhFY8O9eLMWKEDwgRICHvcirjigoNhCBLIgRgwxECPTJIcIQpZhcREBgZMn
gfTytq/EQpQor/Wi0TIDpZs4c+KMAAAh+QQJDwALACwCAAAAIQAfAAAE+3DJSeW5Na+jux3CxWWi
1x1DIgiD6Lrgan6FoYZDzuboXKGDQKEAXBl1At/kEgwUjcaeTMkMIKHRgUTrE12bVgFxwaUCY82C
ojBQjJSW86ppYyfecGYORF+34T9ABjVBBgpCCoAULgYBjo+QCokdBhoHBoOQmgGVGpgnF5mbn54F
oJeYg0M1naWgSxcJsgkmql0ol6u0lKYzTAKiQrsVtiYiIQWawxSNvR6zKMmPBcsSos4ZCZjUl5A1
1cHYE9qi2qs138yaQ3s55tQBCe2ynMvBAVgr5nUoAgqzNohJK5BvzqwFChCAkISAl6MYWPZcUCAq
IQJZGVRZ2bNDLuKBf9sCSLKIoCEzNu1STiyJgIBLl0KoaVvmpZ0LhC1fwpxGzQbNF3hGCh1KNAIA
IfkECQ8ACwAsAAAAACMAHwAABPtwyUnpuTWvo7sdwsVlomceQyIIg+i64Gp+haGGQ87m6Kyhg0Ch
AFwZdQJf5RIMFI3GnkwpYQaQ0OhAsqWKsM2rgLjoUjfAWLOgKAwUo3M1vWra3Im4nJkD2dtvcktA
BjVBBgpCCoIWIgYBkJGSCouMBwaFkpoBBoxzlwWbnJ1KL2iXmIVDNaQ+fH0YnwmzCXtgLXMtqgW1
pVhHXwKZkLw+bjFZLRchoZK9Jm5ZULQozcTPHYXSfQmYvJeSNdgZQ8k53cPdqzXiFAXukXXcqgkB
CX0p9TbuE8PEygfU3UEhQAGtffwkWBNCZES+WgoQgKCEoAOnBQuHtKqgYDZYRASzNGzSOE6CQW8B
KH1EUJHCo0irNk5YSaBmTYazEErY1U5DRJs2w/Gy8SxVyA4qkypdGgEAIfkECQ8ACwAsAgAAACEA
HwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i64Gp+haGGQ87m6Fyhg0ChAFwZdQLf5BIMFI3GnkzJ
DCCh0YFE6xNdQTkwh0sFxs7hlpLCRKbTo/XGDA4EDIrCQKE01AyAbX4GQXhCfCZ+Q4sGLgZ2kJEB
CogVBZJCNQeAl5iQBhqdnkQXfp6AoZ6QIoCcjKAdophMFhcJtwkml4uyUC0om4u5HUKtiwFYTAKm
dgXDljW4igVQIiGyAc8Ud88JhDEruCiyzqEZ30befgmbkdGWsBVhAuqd3ryD2vHyOvfO2WlucVMS
MB8REAqkaZsxD9cCBQgQQpQz4c0FBcwgIrhFcSWOiIScJlFCQBIBxY8lCahUmemWjY4QV65058zG
QhOUcurcqTMCACH5BAkPAAsALAgAAAAbAB8AAAT7cMl56rz44H2GqBpnbVeXCMIArquHckNhnN9g
p3ZHUnZQFB0XCvfaVQaBQHDI1BVFyBuzOZBURUuU66ZaXBcGHyW4HdpypLDvKBWeu+mCkuwZ0N47
iUHO3hvsCYEFCXlgfCBqSYqKCgpxawZ7i5MBBo9JiHKUkTuScweRkT8/nJ0/cwUSIIGBhXuaSalH
oKOEcbCxRwKePrYZNwECmBUfuAG+PEJarB24gxtnUwmiCaCLMsheygLTntOjMtgX0UPfg8dvgZXI
5CjfM0AeCqwzGG9CrAsKCPL7efdnKijwtA9BKxL3QMwTFaBRQQQIjKx4SKBiRR+DpmXbsM8OosVr
g2ZsnOCwpMmTEQAAIfkECQ8ACwAsBQAAAB4AHwAABPtwyTmPpbjmvc4Q1rGFXOYlgjCELPulpVcY
KDjc6u2VlDcEhYIvRcQJeBLLLzAkEncwnjJgdD4HEmxM+VLlPquFVup7mW86ZKWcQrvD6k4ZHAgY
FIWBIm4wyG8GMz93QHtxCwYsBnWMjQEKhkiJfQWOjn6SgSGBlnaYHH2cm6FBQX08lJVMIkkWCa8J
qIGqdZ9KB7MFsRu5jbYeApx1uhmzl2sHILR1uxTCvhOwMo3EGJw/RSIJlAm41DQZaE4328LbpTMz
zVlVOee6AQlur3brYuJO5zRCHwqw4OHwtYG1QAGCfgZ5vHljQYEwgwheKWTYsFwlSBARICBDIhkj
gY8fgejaZq+EQZAgqemiUTIDxpcwY0YAACH5BAkPAAsALAIAAAAhAB8AAAT7cMlJ5bk1r6O7HcLF
ZaLXHUMiCIPouuBqfoWhhkPO5uhcoYNAoQBcGXUC3+QSDBSNxp5MyQwgodGBROsTXZtWAXHBpQJj
zYKiMFCMlJbzqmljJ95wZg5EX7fhP0AGNUEGCkIKgBQuBgGOj5AKiR0GGgcGg5CaAZUamCcXmZuf
ngWgl5iDQzWdpaBLFwmyCSaqXSiXq7SUpjNMAqJCuxW2JiIhBZrDFI29HrMoyY8FyxKizhkJmNSX
kDXVwdgT2qLaqzXfzJpDeznm1AEJ7bKcy8EBWCvmdSgCCrM2iEkrkG/OrAUKEICQhICXoxhY9lxQ
ICohAlkZVFnZs0Mu4oF/2wJIsoigITM27VJOLImAgEuXQqhpW+alnQuELV/CnEbNBs0XeEYKHUo0
AgAh+QQJDwALACwAAAAAIwAfAAAE+3DJSee5NVOs9RkD1y1XcYzZZxjh5b6HYaLpUBTrBe7gJ/y0
yqcQMA1+yF8okVgIgpZBIABKWltQ4c56PZ2yEt1xGvhNlV5w+CMtKn4KIlYdbd9AN6qIzp4WFCBx
enQbH36AA4IzhBZ5ZAoKfgWMEmSWl2SThAaYAZxkK1kwCwELK52hUGI7XxIrMjcGamxIPWsmTAmL
QbRdOitERXsdBVVcLQcCjkW7I8VcP7kJB8GZ0ygyxyAJK9PVfgZNzgVX26cB07A3uuEUmhLVSjvc
BQnobNv27RPvMpbFLujZm3ZEQa59/Pj9M/FlgDQFCApC7OBpwbdYHRT4CwARNAETDZhiiatgEBhH
SAg8jnS1EEfGlARi+mFScqU6HCspQIwpkxmRBDVHvvqYEZLRo0iNRgAAIfkECQ8ACwAsAgAAACEA
HwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQAC2DQACE
rLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0Bvek8yKzgffoBDMygyNo44eWIK
CmsFKENilZmbnJYZmJwBBqGjYisaoKGiK6QGI6mhAxKFj5d2kWVHLSZLCYsaRLR5VTkrmCZeFTYG
vY0FSC4CuDbJFKJMEgksRj69CSWbBd+fGdtH2szgmTfYEzcaWuhS387i7BSu8FTa4gHfO0uuPQEo
I4G/HgqatQMSr5cCBEYmIZAjYUcLBTKkPESwhCMijITGAkza2FEOho0EUq5ZAnLhk4cpVd7y19Il
ipE4c+qMAAAh+QQJDwALACwIAAAAGwAfAAAE+3BJeeq8eNp8xtiZdhRH2BnGV63sYZDh0hUFWnm4
1wl8PAekAW/I+yQSC4FpEAh4iFBVjIKDRkslX0fYDPCaRezEABR5mgUFT1Fwgi7k8hZd8NDc2cwL
OAcqPGxuUwt7N2h/A4EwU3skd10KCnSDe12Wl10FIZVxl50BKDGVQCiYoAaMj2WEKDQ1lKpyIwdH
CYt6sXwnlSR5F1sCXk0rAqo0vlRCRLUJI5cFzRhVyyjNbZY1SBdP1HHNL662BtoS0zwJLwkBzTlH
oOQL5gLo0Os7CrXj0jlDzAoIQiIhmJIjRwkFlf4hOBKj4Ap8rQJEUsjQxAoJCgloRHMEEyK8EP80
bgRyJ4HHjxcmqlzJMgIAIfkECQ8ACwAsBQAAAB4AHwAABPtwySmPpTjfPM8YG1cdxSFWg2GAVuse
RnmiRaFaX/55Qj8vnkKgNOgZe6BEYiGYeQKBz3HK+qGk0yMIaMUVoYEeFGky/bzQgqKnEFat13Th
U4uGup+04tO2w1VAT0N7A30ycAsGCSRCYAoKcogSYJSVYAVWKgaWAZtggCeajZqcoCIqdVAGE6I1
q6ExjaodJAdKCYcZsbKdtCkxaXcSsZWvgQcCqUO5rLyzC7eLzgWLGMADYWTQKtKVNksYOVoDCSpQ
i7vU3+FYSOQxCQGLOkqd4BM6U+XU8jwKt4o45DNC7pYCBEUeIZihoyELBcACHESghGHDFv9QSVRI
8R4ehxcSJhIYmUZJRo8zDo4kuUxIgpMoOTyaSbMmzQgAIfkECQ8ACwAsAgAAACEAHwAABPtwyUnX
uTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQAC2DQACErLaeQV3Vejph
c0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0BvenJBH36AQzODc3liCgprBUAGGWKVlmKRGiua
lwEGlZuamZQLK52hok8rMjaTI6xAFyZLCYmpNDkrQ0R7E7AoLgKMdl4Vn6MatAkllgXLxrvIFQkr
y7uYBkwUMpjJpgHLrDa12dvNdzvUzuB0IEue2hLcYlsC6gnsRgq05dvR9QIGKFOAQB/BDvOMbNFx
QcE8ggiWZGA1RcuOFvt0BXAEUSSiv4sXMUAkQHLNkozxSLTj4WIBQZIl7QxJgDIljD0cc+rcGQEA
IfkECQ8ACwAsAAAAACMAHwAABPtwyUnnuadqebdfxyB23lVkn3YNxoi9l4Gm1VoYeCjuQyj8tNqh
EAgUBr/kr5dILARBiy6AvCgPgt4sytkJsN8fuAfiSkdJMDaU2UZXPeWVbD7Hfwlk4kuvg3QCTQlF
Cgp5bnU2RYuLJ34UQ0SLCJSNjxOMRQSbCI0BlwsGmZsEnUYGZjALATiSAZWsogWDKXA7W61FNwuz
AYNOJSJJIxxDB4InCb2+wUhyWiG5RseSsxtHzs8YAgWu3cdGwBpHckmCCUOZJ8fiFQYF5TsJOOiu
uhgf3c8i86K+B++6WRtHwdUSee9+6eDnocCEd4yOYJjXCx0SQ+0KTrD3DUfFgHMKEFwM6YEVr4i7
NiiAGCAkgiYbMhm5kVGCoVyFXMKk4E9XN1QqKZHS1eRmu4A/a9pEQIqATyIJjIrDYWCnypxYs2aN
AAAh+QQJDwALACwCAAAAIQAfAAAE+3DJSde5p2p59z5D2HlXkXnVNRgi5l7GiVJqYdxgqA+g4M+0
QyEQKAx8SB8vkVgIgJxc4HhJHgQ8GdSiE1y9vi/Pso2KkN8rKKMFqnhJ67hshvsSx4R3Tn8LmAlE
Cgp4bR4GNjcxIENEjkQmQIgFlJQxlI8Imo4FM42PmI8BBKQInAEen6IBBqKkpJAGqauiN5+brAaB
qBWqtAMStrELgcUUQ5WqSVkmgAUJz0RNE0WKlQFxKsJF0I3TC5aAkwVWVaFFz97UuhMJLEd3gEKi
zUzHGu9I7rrzoBjHsjR02SftwLhnGwIKDPEHUbEcIb6V2eEuWoIehCROZAgoNIECBEcGIaAzYUcW
BYgEabJH8gUhYYM+ImDZJ4PMV5CYvNQI5eMrApAweXRHs2fMo0iRRgAAIfkECQ8ACwAsCAAAABsA
HwAABPtwSXnqmTivqun4XLcdxdVVgwFabGWY5zEURi1/+CALvFgVgUBhwCvydInEQhD7BIgV40Gg
g51wgmmWp9VtRCNQUTuVXWAG4QSlM0q9mrSQrRUkiIksPA5k25NBCgp3VnwBKEBBikElYAsGfQWJ
QQiVigWOkIuKBJ0IlwEimgFynJ0EjAZgo6Sslq0JQXyTmI+jNAuxuhiQk2o/B0kJBcOxAUoSvZsl
MjWJxJJByBsfAgHWh1HRjNDSHkRGwgkky8FJE1jhNeO+cyES1epy472S0xjpPAmQujcf9/ji6eN3
bMcggOhyFBGnAAERQQjA5MhxQcGohgjOdZhoYSKQswCCMGrUwEICxlOMknhEmKHhKVRCoiVYydJk
yJs4cUYAACH5BAkPAAsALAUAAAAeAB8AAAT7cMkpjz00U6vzGSDXLVaBjdVnhFdrGSdKfoVhf2A+
fEIvz4VAoDDoGXu7RGIhkFlAgaLleBDsYs6coLrtcXek3yxk5FY/GOzouTtSweJxu5coJrZwMVug
TAgVCnVqIzZjQUKIQiZxEjAFh0IIkogFjBKJQgSaCJQBcTYGmJqaigY/oIc2kJMBNn6eGqqQpo0G
hzULfroUsom0QAd9BQnDQkuNj5CtE0+qisSHx7bKyylVj5TD0ciY1X0JB9QmfRO2UQFGYAmu4Zgm
IhNa6QProQHg04/HGvJI9La6cIDYx68fHYD3eAQiWBDEEXp9FCAoAgiBDB0YrygwF0AnIgIlFzFe
COQMkEeQKFxI8DjqWQKSDFFIHEVAEbaX61DKMMmzp88IACH5BAkPAAsALAIAAAAhAB8AAAT7cMlJ
17mnann3PkPYeVeRedU1GCLmXsaJUmph3GCoD6Dgz7RDIRAoDHxIHy+RWAiAnFzgeEkeBDwZ1KIT
XL2+L8+yjYqQ3ysoowWqeEnruGyG+xLHhHdOfwuYCUQKCnhtZTVEiYkmdDQFQ4kIkotQBhqKRASa
CIsBKDcbBpiaBJxFlh4GBR4BN5ABk62iBYEVqluuRDYLtAGBTRKqq25CB4AmCb2+E7fEK6q6xpC0
wY/EV4+LyEXAC7MzgAlCmCbG3dBFKAk34q/RI9WUGuuivgfCj90U9do7A+u9xO3Qt89dnDuqfvUg
RJDZtINKwilAcGQQglSQjhzUcUE0AbqJCJhoEDali7+O9IYMAimyoL+TGUCS0sWEkAF9GGB2mEiK
gK5sCWy2jPKCwsqjSJNGAAAh+QQJDwALACwAAAAAIwAfAAAE+3DJSee5NVOs9RkD1y1XcYzZZxjh
5b6HYaLpUBTrBe7gJ/y0yqcQMA1+yF8okVgIgpZBIABKWltQ4c56PZ2yEt1xGvhNlV5w+CMtKn4K
IlYdbd9AN6qIzp4WFCBxenQbH36AA4IzhBZ5ZAoKfgWMEmSWl2SThAaYAZxkK1kwCwELK52hUGI7
XxIrMjcGamxIPWsmTAmLQbRdOitERXsdBVVcLQcCjkW7I8VcP7kJB8GZ0ygyxyAJK9PVfgZNzgVX
26cB07A3uuEUmhLVSjvcBQnobNv27RPvMpbFLujZm3ZEQa59/Pj9M/FlgDQFCApC7OBpwbdYHRT4
CwARNAETDZhiiatgEBhHSAg8jnS1EEfGlARi+mFScqU6HCspQIwpkxmRBDVHvvqYEZLRo0iNRgAA
IfkECQ8ACwAsAgAAACEAHwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08h
YBr4jr5QIrEQAC2DQACErLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0Bvek8y
KzgffoBDMygyNo44eWIKCmsFKENilZmbnJYZmJwBBqGjYisaoKGiK6QGI6mhAxKFj5d2kWVHLSZL
CYsaRLR5VTkrmCZeFTYGvY0FSC4CuDbJFKJMEgksRj69CSWbBd+fGdtH2szgmTfYEzcaWuhS387i
7BSu8FTa4gHfO0uuPQEoI4G/HgqatQMSr5cCBEYmIZAjYUcLBTKkPESwhCMijITGAkza2FEOho0E
Uq5ZAnLhk4cpVd7y19IlipE4c+qMAAAh+QQJDwALACwIAAAAGwAfAAAE+3BJeeq8eNp8xtiZdhRH
2BnGV63sYZDh0hUFWnm41wl8PAekAW/I+yQSC4FpEAh4iFBVjIKDRkslX0fYDPCaRezEABR5mgUF
T1Fwgi7k8hZd8NDc2cwLOAcqPGxuUwt7N2h/A4EwU3skd10KCnSDe12Wl10FIZVxl50BKDGVQCiY
oAaMj2WEKDQ1lKpyIwdHCYt6sXwnlSR5F1sCXk0rAqo0vlRCRLUJI5cFzRhVyyjNbZY1SBdP1HHN
L662BtoS0zwJLwkBzTlHoOQL5gLo0Os7CrXj0jlDzAoIQiIhmJIjRwkFlf4hOBKj4Ap8rQJEUsjQ
xAoJCgloRHMEEyK8EP80bgRyJ4HHjxcmqlzJMgIAIfkECQ8ACwAsBQAAAB4AHwAABPtwySmPpTjf
PM8YG1cdxSFWg2GAVuseRnmiRaFaX/55Qj8vnkKgNOgZe6BEYiGYeQKBz3HK+qGk0yMIaMUVoYEe
FGky/bzQgqKnEFat13ThU4uGup+04tO2w1VAT0N7A30ycAsGCSRCYAoKcogSYJSVYAVWKgaWAZtg
gCeajZqcoCIqdVAGE6I1q6ExjaodJAdKCYcZsbKdtCkxaXcSsZWvgQcCqUO5rLyzC7eLzgWLGMAD
YWTQKtKVNksYOVoDCSpQi7vU3+FYSOQxCQGLOkqd4BM6U+XU8jwKt4o45DNC7pYCBEUeIZihoyEL
BcACHESghGHDFv9QSVRI8R4ehxcSJhIYmUZJRo8zDo4kuUxIgpMoOTyaSbMmzQgAIfkECQ8ACwAs
AgAAACEAHwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQ
AC2DQACErLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0BvenJBH36AQzODc3li
CgprBUAGGWKVlmKRGiualwEGlZuamZQLK52hok8rMjaTI6xAFyZLCYmpNDkrQ0R7E7AoLgKMdl4V
n6MatAkllgXLxrvIFQkry7uYBkwUMpjJpgHLrDa12dvNdzvUzuB0IEue2hLcYlsC6gnsRgq05dvR
9QIGKFOAQB/BDvOMbNFxQcE8ggiWZGA1RcuOFvt0BXAEUSSiv4sXMUAkQHLNkozxSLTj4WIBQZIl
7QxJgDIljD0cc+rcGQEAIfkECQ8ACwAsAAAAACMAHwAABPtwyUnpuTWvo7sdwsVlomceQyIIg+i6
4Gp+haGGQ87m6Kyhg0ChAFwZdQJf5RIMFI3GnkwpYQaQ0OhAsqWKsM2rgLjoUjfAWLOgKAwUo3M1
vWra3Im4nJkD2dtvcktABjVBBgpCCoIWIgYBkJGSCouMBwaFkpoBBoxzlwWbnJ1KL2iXmIVDNaQ+
fH0YnwmzCXtgLXMtqgW1pVhHXwKZkLw+bjFZLRchoZK9Jm5ZULQozcTPHYXSfQmYvJeSNdgZQ8k5
3cPdqzXiFAXukXXcqgkBCX0p9TbuE8PEygfU3UEhQAGtffwkWBNCZES+WgoQgKCEoAOnBQuHtKqg
YDZYRASzNGzSOE6CQW8BKH1EUJHCo0irNk5YSaBmTYazEErY1U5DRJs2w/Gy8SxVyA4qkypdGgEA
IfkECQ8ACwAsAgAAACEAHwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i64Gp+haGGQ87m6Fyhg0Ch
AFwZdQLf5BIMFI3GnkzJDCCh0YFE6xNdm1YBccGlAmPNgqIwUIyUlvOqaWMn3nBmDkRft5UGNQaD
eoEGQQYKQgozgUOPBi4GAZSVlgqMGQWWlEORg5uclgYaoaJCIoGng6WnlamDjp6kHaaiTHEHCbsJ
JpuPtlAtKAeyvR1CsY8BWEwCqp3HFZ68slAiIbYB0hQBNhMJhzErvCi2BdwTBRniRuGBd5OVNek1
GnsC76HhwIbctBnw8UO3bU+KBN7SdTDIrw4KAQqqKfQgcNcCBQhAYEIAhy+CwWEKoGFEYLHjBhcR
QQXANBIBx44iWhKYOVMIunATTWCkSdPSEJw5NbAcSrRoBAAh+QQJDwALACwIAAAAGwAfAAAE+3DJ
eeq8+OB9hqgaZ21XlwjCAK6rh3JDYZzfYKd2R1J2UBQdFwr32lUGgUBwyNQVRcgbszmQVEVLFDLp
AS6uC4OPEnRtC4rCQBHCiH1H6XamTrTdBWXZM0+vdxIGeXGCBkgGCj4KgGGDIG9JkZEKixuCcAaX
kpsGJJp6B5+SmTuaj5mCPzKdpT96BRIgCbMJjKmSsEehqrWerrhHAp8FvRk3AQJJIB95ksU8Qlq0
Hc1JxBs20QIJmcShuDMYUkPcmtyqMjLP2UznxAEJ2QOzAeET7OSFCUAeCrT29+SRm7VAAYJ+BgHJ
k1dBgSaDCAiSWAjCX7cAlCAiQGBkGoVGAiBB+iDG7RkJgyFD4iI2w+SFjDBjyowAACH5BAkPAAsA
LAUAAAAeAB8AAAT7cMk5j6W45r3OENaxhVzmJYIwhCz7paVXGCg43OrtlZQ3BIWCL0XECXgSyy8w
JBJ3MJ4yYHQ+BxJsTPlSBb4f4UIr9b2WBUVhoBAhk+bUkrZOuN9c3FzNfi8MBh0+BjM/BgpACn4S
BiwGX5CRAQqKb42ABZKSgUiYIYSaAYA8gKCfpUFBoyWYmUx3IQmyCaSErl+cgiu2BbQbvJG5SgKg
X70ZtpsVFiC3X74UxcETszKRxxigP0UiCZh2j5Az0BM3XTnexd6pM+MY5k43670BCeYDsqLkY/BO
63QeBCiYRWPDvXizFihA8IESAh73Iq44oKDYQgSyIEYMMRAj0ySHCEKWYXERAYGTJ4H08ravxEKU
KK/1otEyA6WbOHPijAAAIfkECQ8ACwAsAgAAACEAHwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i6
4Gp+haGGQ87m6Fyhg0ChAFwZdQLf5BIMFI3GnkzJDCCh0YFE6xNdm1YBccGlAmPNgqIwUIyUlvOq
aWMn3nBmDkRft+E/QAY1QQYKQgqAFC4GAY6PkAqJHQYaBwaDkJoBlRqYJxeZm5+eBaCXmINDNZ2l
oEsXCbIJJqpdKJertJSmM0wCokK7FbYmIiEFmsMUjb0esyjJjwXLEqLOGQmY1JeQNdXB2BPaotqr
Nd/MmkN7OebUAQntspzLwQFYK+Z1KAIKszaISSuQb86sBQoQgJCEgJejGFj2XFAgKiECWRlUWdmz
Qy7igX/bAkiyiKAhMzbtUk4siYCAS5dCqGlb5qWdC4QtX8KcRs0GzRd4RgodSjQCACH+PEZJTEUg
SURFTlRJVFkNCkNyZWF0ZWQgb3IgbW9kaWZpZWQgYnkNCkVEIVNPTiAnOTYgW1hmL1VDZl0NCgA7

--=====001_Dragon882675286087_=====--


From ppopov@mvista.com Wed Oct 22 07:18:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 07:18:59 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:45306 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225296AbTJVGS5>;
	Wed, 22 Oct 2003 07:18:57 +0100
Received: from [10.2.2.20] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id XAA22922;
	Tue, 21 Oct 2003 23:18:48 -0700
Subject: Re: Is Yamon executed in flash or in RAM?
From: Pete Popov <ppopov@mvista.com>
To: taoyong2002cncq@yahoo.com.cn
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20031022061346Z8225296-1272+8254@linux-mips.org>
References: <20031022061346Z8225296-1272+8254@linux-mips.org>
Content-Type: text/plain
Organization: 
Message-Id: <1066803540.28777.18.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 21 Oct 2003 23:19:07 -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: 3478
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 220
Lines: 10

On Tue, 2003-10-21 at 23:16, taoyong wrote:
> hi,
>    
>     Have anyone used the YAMON on PB1000? 
>     I wonder whether it is executed in flash or in RAM.

Boots from flash, moves to RAM, and runs out of RAM.

Pete


From jbglaw@dvmwest.gt.owl.de Wed Oct 22 07:57:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 07:57:37 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:3535 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225296AbTJVG5f>; Wed, 22 Oct 2003 07:57:35 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 62B124B412; Wed, 22 Oct 2003 08:57:33 +0200 (CEST)
Date: Wed, 22 Oct 2003 08:57:33 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: module dependency files
Message-ID: <20031022065732.GP20846@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <1066771519.3289.45.camel@localhost.localdomain> <Pine.GSO.4.44.0310211814340.14473-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="VC+1dD9mx8z5dlPH"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0310211814340.14473-100000@ares.mmc.atmel.com>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
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: 3479
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1355
Lines: 43


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

On Tue, 2003-10-21 18:15:56 -0400, David Kesselring <dkesselr@mmc.atmel.com>
wrote in message <Pine.GSO.4.44.0310211814340.14473-100000@ares.mmc.atmel.c=
om>:
> That's what I did. I defined INSTALL_MOD_PATH as $(TOPDIR)/modules. The
> modules get put there but depmod fails.

depmod works on it's own architecture and I don't recall a way that
would make it work on cross-compiled modules. Maybe you should just copy
over the modules (INSTALL_MOD_PATH is a good start here) and execute
depmod on the target system...

Apart from that, insmod (instead of modprobe) should always work,
though...

MfG, JBG

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

--VC+1dD9mx8z5dlPH
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/lipcHb1edYOZ4bsRAul4AJwOqa6JI+ZKcLzgE3pFQqyqGXlGzwCfdn55
/qo86ST6py2ySZLLc2TdxTw=
=ydTk
-----END PGP SIGNATURE-----

--VC+1dD9mx8z5dlPH--

From Colin.Helliwell@Zarlink.Com Wed Oct 22 08:14:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 08:15:05 +0100 (BST)
Received: from semigate.zarlink.com ([IPv6:::ffff:209.226.172.94]:24228 "EHLO
	semigate.zarlink.com") by linux-mips.org with ESMTP
	id <S8225296AbTJVHOd> convert rfc822-to-8bit; Wed, 22 Oct 2003 08:14:33 +0100
Received: from ottmta01.zarlink.com (ottmta01 [134.199.14.110])
	by semigate.zarlink.com (8.11.6+Sun/8.10.2) with ESMTP id h9M7EQC24505
	for <linux-mips@linux-mips.org>; Wed, 22 Oct 2003 03:14:26 -0400 (EDT)
Subject: Re: module dependency files
To: linux-mips@linux-mips.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF86FA85AC.EA0A3B86-ON80256DC7.00270886@zarlink.com>
From: Colin.Helliwell@Zarlink.Com
Date: Wed, 22 Oct 2003 08:14:18 +0100
X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.12  |February 13, 2003) at
 10/22/2003 03:14:26 AM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
Return-Path: <Colin.Helliwell@Zarlink.Com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3480
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Colin.Helliwell@Zarlink.Com
Precedence: bulk
X-list: linux-mips
Content-Length: 2774
Lines: 57


You'd need to do a MIPS cross-compile of modutils, I guess. As an
alternative there is a perl script (depmod.pl) out there that can handle
'foreign' binaries. I haven't had cause to use it on MIPS yet, but have
used it ok PPC. I think it comes with the busybox package.

Col





                                                                                                                                           
                      Jan-Benedict Glaw                                                                                                    
                      <jbglaw@lug-owl.de>          To:       linux-mips@linux-mips.org                                                     
                      Sent by:                     cc:                                                                                     
                      linux-mips-bounce@lin        Subject:  Re: module dependency files                                                   
                      ux-mips.org                                                                                                          
                                                                                                                                           
                                                                                                                                           
                      10/22/03 07:57 AM                                                                                                    
                                                                                                                                           
                                                                                                                                           




On Tue, 2003-10-21 18:15:56 -0400, David Kesselring
<dkesselr@mmc.atmel.com>
wrote in message
<Pine.GSO.4.44.0310211814340.14473-100000@ares.mmc.atmel.com>:
> That's what I did. I defined INSTALL_MOD_PATH as $(TOPDIR)/modules. The
> modules get put there but depmod fails.

depmod works on it's own architecture and I don't recall a way that
would make it work on cross-compiled modules. Maybe you should just copy
over the modules (INSTALL_MOD_PATH is a good start here) and execute
depmod on the target system...

Apart from that, insmod (instead of modprobe) should always work,
though...

MfG, JBG

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


<< Attachment removed : attxmd4r.dat >>




From wd@denx.de Wed Oct 22 09:03:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 09:03:54 +0100 (BST)
Received: from mailout09.sul.t-online.com ([IPv6:::ffff:194.25.134.84]:942
	"EHLO mailout09.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225359AbTJVIDW>; Wed, 22 Oct 2003 09:03:22 +0100
Received: from fwd02.aul.t-online.de 
	by mailout09.sul.t-online.com with smtp 
	id 1ACDxc-0004jF-08; Wed, 22 Oct 2003 10:03:16 +0200
Received: from denx.de (Sav8TuZDZeXqTGZ9C5WkcIu95BPrIqnQm04BFqor1sa9RdCZAU6wZh@[217.235.233.78]) by fmrl02.sul.t-online.com
	with esmtp id 1ACDxU-1ZNVoG0; Wed, 22 Oct 2003 10:03:08 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id BA94B422AB; Wed, 22 Oct 2003 10:03:05 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 124DBC59E4; Wed, 22 Oct 2003 10:03:04 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 0DF1EC545E; Wed, 22 Oct 2003 10:03:04 +0200 (MEST)
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc: linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: module dependency files 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Wed, 22 Oct 2003 08:57:33 +0200."
             <20031022065732.GP20846@lug-owl.de> 
Date: Wed, 22 Oct 2003 10:02:59 +0200
Message-Id: <20031022080304.124DBC59E4@atlas.denx.de>
X-Seen: false
X-ID: Sav8TuZDZeXqTGZ9C5WkcIu95BPrIqnQm04BFqor1sa9RdCZAU6wZh@t-dialin.net
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3481
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips
Content-Length: 678
Lines: 18

In message <20031022065732.GP20846@lug-owl.de> you wrote:
> 
> depmod works on it's own architecture and I don't recall a way that
> would make it work on cross-compiled modules. Maybe you should just copy
> over the modules (INSTALL_MOD_PATH is a good start here) and execute
> depmod on the target system...

Busybox contains a  platform-independend  depmod  perl  script  which
works fine even in a cross development environment.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"A witty saying proves nothing."                           - Voltaire

From anemo@mba.ocn.ne.jp Wed Oct 22 09:08:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 09:09:13 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:6404
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225359AbTJVIIl>; Wed, 22 Oct 2003 09:08:41 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 22 Oct 2003 08:08:58 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h9M88m9X023964;
	Wed, 22 Oct 2003 17:08:49 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Wed, 22 Oct 2003 17:11:18 +0900 (JST)
Message-Id: <20031022.171118.88468465.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Huge dynamically linked program does not run on mips-linux
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 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: 3482
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 1824
Lines: 58

I have a problem that my huge dynamically linked program cause
SIGSEGV or SIGBUS immediately after running from main() on mips-linux.

Digging into this problem, I found that GOT entries are corrupted.

Here are some informations from readelf and objdump:

$ mips-linux-readelf -a myapp
...
Relocation section '.rel.dyn' at offset 0xe3b20 contains 426 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
...
100c47bc  003f7f03 R_MIPS_REL32      004e4990   getrlimit
...
Symbol table '.dynsym' contains 17742 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
...
 16255: 004e4990     0 FUNC    GLOBAL DEFAULT  UND getrlimit
...
Symbol table '.symtab' contains 26849 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
...
  7664: 004e4990     0 FUNC    GLOBAL DEFAULT  UND getrlimit
...

$ mips-linux-objdump -s -j .got myapp
...
Contents of section .got:
...
 100c47b0 100c5cba 00c07c54 100c5c5c 004e4990  ..\...|T..\\.NI.
...


0x004e4990 is "stub" routine to jump into libc's getrlimit.

0x100c47bc must contain 0x004e4990 at run-time, but when the signal
sent the value is 0x009c9320.  It is 0x004e4990+0x004e4990.

The outout from objdump shows 0x004e4990 is already in .got and the
output from readelf shows 0x004e4990 will be added to it by dynamic
loader.  Is my understanding right?

Could anyone tell me why binutils generate such informations?  Or is
this dynamic loader issue?

I'm using binutils 2.14, gcc-3.3.2, glibc-2.2.5.  I tried gcc-3.3.1,
glibc-2.3.2, uClibc-0.9.21, binutils-2.14.90.0.6 and binutils-cvs but
no lock.

My program is huge enough so that older binutils causes "relocation
truncated to fit" error.

The program can work well if statically linked.  Other (relatively
small) dynamically linked programs can work well also.

Thanks.
---
Atsushi Nemoto

From fishbaoz@yahoo.com Wed Oct 22 11:16:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 11:17:01 +0100 (BST)
Received: from smtp017.mail.yahoo.com ([IPv6:::ffff:216.136.174.114]:57527
	"HELO smtp017.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225359AbTJVKQw>; Wed, 22 Oct 2003 11:16:52 +0100
Received: from unknown (HELO BAOZ) (fishbaoz@61.149.147.228 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 22 Oct 2003 10:16:49 -0000
Message-ID: <020c01c39885$994bf470$867ba8c0@BAOZ>
From: "baozheng" <fishbaoz@yahoo.com>
To: <linux-mips@linux-mips.org>
Subject: 
Date: Wed, 22 Oct 2003 18:16:38 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Return-Path: <fishbaoz@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: 3483
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fishbaoz@yahoo.com
Precedence: bulk
X-list: linux-mips
Status: RO
Content-Length: 35
Lines: 3

c3Vic2NyaWJlIGxpbnV4LW1pcHMNCg==



From macro@ds2.pg.gda.pl Wed Oct 22 14:56:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 14:56:11 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:3054 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225366AbTJVN4H>; Wed, 22 Oct 2003 14:56:07 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA12473;
	Wed, 22 Oct 2003 15:56:03 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 22 Oct 2003 15:56:02 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
cc: linux-mips@linux-mips.org
Subject: Re: LK201 keyboard
In-Reply-To: <20031021202328.GO20846@lug-owl.de>
Message-ID: <Pine.GSO.3.96.1031022155154.11598B-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: 3484
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 877
Lines: 18

On Tue, 21 Oct 2003, Jan-Benedict Glaw wrote:

> What the "old" lk driver uses is more-or-less what could be referred as
> power-on configuration. Even if there are set mode commande - if they
> were ignored, it would silently work as expected. Could you set all
> groups to "DOWN_UP_MODE" and verify that it no longer works?

 No problem -- I'll look at it.  We'll need the down/up mode for X11, so
it has to work.  Note: the LK4xx series keyboards start in the LK201
compatibility mode -- they have to be switched to the native mode with a
command if desired, so unless you are reprogramming your LK401 to its
native mode, what works for it should also work for the LK201. 

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


From dkesselr@mmc.atmel.com Wed Oct 22 14:58:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 14:58:23 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:54109
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225366AbTJVN6V>; Wed, 22 Oct 2003 14:58:21 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA19177
	for <linux-mips@linux-mips.org>; Wed, 22 Oct 2003 09:58:14 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA15144
	for <linux-mips@linux-mips.org>; Wed, 22 Oct 2003 09:58:13 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Wed, 22 Oct 2003 09:58:13 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: root login
Message-ID: <Pine.GSO.4.44.0310220952170.15096-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3485
X-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
Content-Length: 675
Lines: 16

I apologize for the many recent questions but I have another trivia
question for all of you. :-)
I have installed the RH7.3 miniport to a harddrive connected to a MIPS
Malta board. The kernel the comes with the port (2.4.18) works fine. I
then took the cvs code (2.4.22) for mips and built it for malta. The first
few builds worked ok (which means I could logon as root). Then I changed
something in the build process so that now the kernels which I build won't
allow me to logon as root. I've changed /etc/passwd to eliminate the root
pw. Does anyone know how a kernel can affect the login like this?
Thanks,

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


From tk@mycable.de Wed Oct 22 15:12:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 15:12:33 +0100 (BST)
Received: from mail.oricom.de ([IPv6:::ffff:62.116.167.108]:8618 "EHLO
	oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8225366AbTJVOMB>; Wed, 22 Oct 2003 15:12:01 +0100
Received: from mycable.de (p5086B9E0.dip.t-dialin.net [80.134.185.224])
	(authenticated bits=0)
	by oricom4.internetx.de (8.12.8/8.12.8) with ESMTP id h9MECB6Z029032;
	Wed, 22 Oct 2003 16:12:12 +0200
Message-ID: <3F969106.5000807@mycable.de>
Date: Wed, 22 Oct 2003 16:15:34 +0200
From: Tiemo Krueger - mycable GmbH <tk@mycable.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Kesselring <dkesselr@mmc.atmel.com>
CC: linux-mips@linux-mips.org
Subject: Re: root login
References: <Pine.GSO.4.44.0310220952170.15096-100000@ares.mmc.atmel.com>
In-Reply-To: <Pine.GSO.4.44.0310220952170.15096-100000@ares.mmc.atmel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <tk@mycable.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3486
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tk@mycable.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1367
Lines: 45

Hmm, I remember that we had once a similar problem, but I can't remember 
the reason
nor the solution. It appeared that we where not able to login as root, 
but user login was possible.
Logged in as user I was allowed to 'su' to root.
Perhaps this may be a hint, perhaps not, perhaps Bruno remembers the 
solution???

Tiemo

David Kesselring wrote:

>I apologize for the many recent questions but I have another trivia
>question for all of you. :-)
>I have installed the RH7.3 miniport to a harddrive connected to a MIPS
>Malta board. The kernel the comes with the port (2.4.18) works fine. I
>then took the cvs code (2.4.22) for mips and built it for malta. The first
>few builds worked ok (which means I could logon as root). Then I changed
>something in the build process so that now the kernels which I build won't
>allow me to logon as root. I've changed /etc/passwd to eliminate the root
>pw. Does anyone know how a kernel can affect the login like this?
>Thanks,
>
>David Kesselring
>Atmel MMC
>dkesselr@mmc.atmel.com
>919-462-6587
>
>
>
>  
>


-- 
-------------------------------------------------------
Tiemo Krueger       Tel:  +49 48 73 90 19 86
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: tk@mycable.de

Public Kryptographic Key is available on request
-------------------------------------------------------



From hjl@lucon.org Wed Oct 22 16:00:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 16:00:46 +0100 (BST)
Received: from sccrmhc13.comcast.net ([IPv6:::ffff:204.127.202.64]:2023 "EHLO
	sccrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8225366AbTJVPAO>; Wed, 22 Oct 2003 16:00:14 +0100
Received: from lucon.org ([12.234.88.5])
          by comcast.net (sccrmhc13) with ESMTP
          id <2003102214595701600k9a72e>; Wed, 22 Oct 2003 14:59:57 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id E7E3F2C828; Wed, 22 Oct 2003 07:59:56 -0700 (PDT)
Date: Wed, 22 Oct 2003 07:59:56 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: Packages for RH 7.3/mips
Message-ID: <20031022145956.GA16117@lucon.org>
References: <3F964D7E.DF3EB883@niisi.msk.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F964D7E.DF3EB883@niisi.msk.ru>
User-Agent: Mutt/1.4.1i
Return-Path: <hjl@lucon.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3487
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hjl@lucon.org
Precedence: bulk
X-list: linux-mips
Content-Length: 8295
Lines: 203

I no longer work on MIPS. I forward your email to the Linux mips
mailing list.


H.J.
---
On Wed, Oct 22, 2003 at 01:27:26PM +0400, Gleb O. Raiko wrote:
> Hello!
> 
> My team is extended your RedHat 7.3 distribution for big-endian mips.
> The work is done for our customer, but I, of course, would like to put
> them for the public access. The best way in my opinion is to merge those
> packages into your disribution for mips. Are you interesting?
> 
> Our goal was to get all packages cross compiled, so we have to patch
> several packages from your disribution. Also, we had to fix a few minor
> bugs.
> 
> We removed python and perl from package dependencies. (I personally hate
> both.) Our pam doesn't require cracklib.
> 
> The list of packages with some comments is below.
> 
> NEW PACKAGES
> 
> bind 9.2.0-8
> 	-Add Patch1000 to compiling gen.c by HOST_CC
> 	-Replace gcc by %{__cc} for compiling dns-keygen (%install section)
> chkfontpath 1.9.5-2
> 	- Add Patch (Makefile patch) to call install without -s option
> 	- Define CC=%{__cc} for cross compiling
> dev 3.3.1-4.1
> 	(SRPM is missed in your distribution. We just rebuild it form 7.3/ix86)
> dhcp 2.0pl5
> 	-Replace gcc by %{__cc} in %build section
> 	-Replace strip by %{__strip} in %install section
> kdebase 1.1.2-36
> 	- Fixed  g++-2.96 SIGSEGV on kdebase/kfm/kiojob.cpp:551 (enum type)
> 	- Fixed some headers problems
> 	- Fixed kdebase/po/ja/kcontrol.po unknown multibyte problem
> kdelibs 1.1.2-15.1
> 	- Removed overlaping msgid (for May ) in zh_CN.GB2312.po.
> 	- Fixed using /usr/bin/kdoc instead $SRC/kdoc/kdoc
> kdesupport 1.1.2-12.1
> 	-Replace strip by %{_strip}
> krb5 1.2.4-2
> 	-Tcl disabled. MIPS specific variables for crosscompiling added.
> lesstif 0.93.18-2
> 	-%define openmotif 0
> 	-Add Patch1000(configure patch) and Patch2000 (mwm/ Makefile.in)
> 	-Replace ./configure by %configure in SPEC file
> 	-Edit %install section to install files from mwm package properly
> libungif 4.1.0-10.2
> 	-Add strings in %build section for cross compiling:  
> 		  export ac_cv_func_setvbuf_reversed=no
> 		  export cross_compiling=yes
> 		  export ac_cv_prog_cc_cross=yes
> 		  export LIBS="-L/export/tools/mips-linux/lib $LIBS"
> openldap 2.0.23-5
> 	-cross compiling for mips added
> 	-removed requiring cyrus-sasl, cyrus-sasl-md5
> qt1x 1.45-3.3
> 	-Change moc architecture in producing rpm package
> qt 2.3.0-3
> 	-Add configuration files as sources and main Makefile for cross
> compiling
> 	-Compile moc for host system to  call it properly during build
> 	-Compile moc for mips architecture too to include in rpm package
> 	-Designer can't be compiled in cross
> 	-Replace strip by %{_strip}
> qt 3.0.3-12
> 	-Add patches for mips-linux cross platform to set correct parameters of
> compiling
> sendmail 8.11.6-15
> 	-Add Patch20000(redhat.config.m4) and Patch30000(header.m4) for cross
> compiling
> 	-Edit SPEC file for using  system makemap
> 	-Replace strip by %{__strip} in SPEC file
> wu-ftpd 2.6.2-5
> 	-Add Patch10 to set result of snprintf() checking to yes if cross
> compiling
> 	-Replace strip by %{__strip} in SPEC file
> X11R6-contrib 3.3.2-11
> 	Add patches (alloc patch and Imakefile patch) for mips cross compiling
> 
> ==============================================================================================
> FIXED PACKAGES
> (The packages below is from your distribution. We had to fix them.)
> 
> at-3.1.8-23.3.niisi.mips.rpm
> 	-Add patch to call install with no -s option in Makefile.in
> bash-2.05a-13.1.niisi.mips.rpm
> 	-Replace strip by %{__strip} in SPEC file
> 	-Add export ac_cv_func_setvbuf_reversed=yes in SPEC file because of
> ./configure call, not %configure
> bdflush-1.5-17.1.niisi.mips.rpm
> 	-Remove -s option in install call for bdflush
> binutils-2.13.90.0.16-1.niisi.mips.rpm
> 	-Replace strip by %{__strip} in SPEC file
> console-tools-19990829-40.1.niisi. mips.rpm
> 	-Replace strip by %{__strip} in SPEC file
> db3-3.3.11-6.2.niisi.mips.rpm
> 	-Rebuild with define '_without_tcl 1'
> 	-Add Patch to call autoheader without -all option in s_config script
> ftp-0.17-13.1.niisi.mips.rpm
> 	- Add patch for calling install with no -s option in ftp/Makefile
> gcc-2.96-113.2.niisi.mips.rpm
> libstdc++-2.96-113.2.niisi.mips.rpm
> cpp-2.96-113.2.niisi.mips.rpm
> 	-Replace %{_target_platform} by %{_target_alias} in SPEC file
> gdb-5.2.90-0.2.mips.rpm
> 	-Rebuild with "--define='_with_cross_compile 1'"
> hdparm-4.6-1.1.niisi.mips.rpm
> 	-Edit SPEC file for call install without -s option
> iproute-2.4.7-1.1.niisi.mips.rpm
> 	-Edit SPEC file for install call with no -s option
> 	-Add Patches to replace ar by mips-linux-ar in files lib/Makefile and
> tc/Makefile
> less-358-24.1.niisi.mips.rpm
> 	-Replace strip by %{__strip}
> libjpeg-6b-19.2.niisi.mips.rpm
> 	-Reconfigure in install section for correct /usr/lib path
> 	-Replace strip by %{__strip}
> libpng-1.0.14-0.7x.3.1.niisi.mips.rpm
> 	-Replace strip by %{__strip}
> libuser-0.50.2-1.1.mips.rpm
> 	-Rebuild with _without_python 1, _without_ldap 1 definitions.
> logrotate-3.6.4-1.1.niisi.mips.rpm
> 	-Add Patch1000 for install without -s option
> man-1.5j-6.1.niisi.mips.rpm
> 	-Replace in spec file strip by %{__strip}  
> mktemp-1.5-14.1.niisi.mips.rpm
> 	-Add Patch to call install without - s option
> modutils-2.4.18-3.7x.1.niisi.mips.rpm
> 	-Add option --disable-strip to all target %configure
> ncurses-5.2-26.1.niisi.mips.rpm
> 	-Replace strip by %{__strip} in SPEC file
> newt-0.50.35-1.1.niisi.mips.rpm
> 	-Edit spec for rebuilding without python
> 	-Add patch for using install without -s option
> pam-0.75-32.3.niisi.mips.rpm
> 	-Add new definiton: %define with_cracklib 0
> 	-Add 3 patches to build pam without cracklib:
> 		pam-configure-cross-mips-niisi.patch
> 		pam-configure-cross-sparc-niisi.patch
> 		pam-0.75-system-auth.patch
> passwd-0.67-1.1.niisi.mips.rpm
> 	- Replace strip by %{__strip}
> portmap-4.0-41.2.niisi.mips.rpm
> 	-Edit SPEC file for call install without -s option
> procps-2.0.7-12.1.niisi.mips.rpm
> 	-Add patches (Patch20000, Patch30000, Patch40000) for using install
> without --script option
> 	- Change some definition about python to rebuild without python
> psmisc-20.2-3.73.1.niisi.mips.rpm
> 	-Comment strings regarding to Patch10000 (gensig.sh-patch)
> rpm-4.0.4-7x.18.3.niisi.mips.rpm
> popt-1.6.4-7x.18.3.niisi.mips.rpm
> 	- Add export db_cv_mutex="Sparc/gcc-assembly" for sparc architecture
> 	-Add Patch20000 to call autoheader without -all option in s_config
> script
> 	- Change some definition about python to build without python
> sh-utils-2.0.11-14.1.mips.rpm
> 	-Replace strip by %{__strip}
> sysklogd-1.4.1-8.1.niisi.mips.rpm
> 	- Add patch (sysklogd-Makefile-cross-niisi.patch) for using install
> without -s option
> tar-1.13.25-4.7.1.niisi.mips.rpm
> 	- Replace strip by %{__strip} in SPEC file
> telnet-0.17-20.1.niisi.mips.rpm
> telnet-server-0.17-20.1.niisi.mips.rpm
> 	-Add Patches for using install without -s option:
> 	telnet-Makefile1-cross-niisi.patch
> 	telnet-Makefile2-cross-niisi.patch
> 	telnet-Makefile3-cross-niisi.patch
> 	telnet-GNUMakefile-cross-niisi.patch
> texinfo-4.1-1.1.niisi.mips.rpm
> info-4.1-1.1.niisi.mips.rpm
> 	-Replace strip by %{__strip}
> 	-Replace /usr/lib/rpm/brp-strip by /usr/lib/rpm/brp-strip-cross
> 	-Replace /usr/lib/rpm/brp-strip-comment-note by
> /usr/lib/rpm/brp-strip-comment-note-cross
> usermode-1.53-2.1.niisi.mips.rpm
> 	-Replace strip by %{__strip}
> XFree86 4.2.0-72.2.niisi
> 	-Replase XFree86-4.2.0-cross-niisi.patch by two patches for mips and
> sparc architectures
> 	-Add patches do define Sparcarchitecture in host.def file like
> XFree86-4.2.0-cross-mips.patch
> 	-Add patches (mips,sparc) for cross-compiling ttmkfdir
> ==============================================================================================
> 
> Also, we created packages for locales and timezones. The only packages
> we have to build on a native mips box.
> 
> Finally, we implement a script that generates packages required for
> cross compilation. It takes .mips.rpm and generates
> mips-linux-.noarch.rpm. For exmaple, zlib-1.1.3-25.7.1.mips.rpm and
> zlib-devel-1.1.3-25.7.1.mips.rpm are repackaged to
> mips-linux-zlib-1.1.3-25.7.1.noarch.rpm. All dependencies are kept.
> 
> Regards,
> Gleb.

From jr@mycable.de Wed Oct 22 16:13:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 16:13:43 +0100 (BST)
Received: from mail.oricom.de ([IPv6:::ffff:62.116.167.108]:33453 "EHLO
	oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8225426AbTJVPNL>; Wed, 22 Oct 2003 16:13:11 +0100
Received: from mycable.de (pD958CF2F.dip.t-dialin.net [217.88.207.47])
	(authenticated bits=0)
	by oricom4.internetx.de (8.12.8/8.12.8) with ESMTP id h9MFDH6Z031113
	for <linux-mips@linux-mips.org>; Wed, 22 Oct 2003 17:13:24 +0200
Message-ID: <3F969E7A.30600@mycable.de>
Date: Wed, 22 Oct 2003 17:12:58 +0200
From: Joerg Ritter <jr@mycable.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: de-de, de-at, de, en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: root login
References: <Pine.GSO.4.44.0310220952170.15096-100000@ares.mmc.atmel.com> <3F969106.5000807@mycable.de>
In-Reply-To: <3F969106.5000807@mycable.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <jr@mycable.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3488
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jr@mycable.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1285
Lines: 45

You have probably enabled secure tty.
Please check /etc/securetty and add /dev/ttys0 or /dev/tts/0 (for devfs).

/Joerg

Tiemo Krueger - mycable GmbH schrieb:
> Hmm, I remember that we had once a similar problem, but I can't remember 
> the reason
> nor the solution. It appeared that we where not able to login as root, 
> but user login was possible.
> Logged in as user I was allowed to 'su' to root.
> Perhaps this may be a hint, perhaps not, perhaps Bruno remembers the 
> solution???
> 
> Tiemo
> 
> David Kesselring wrote:
> 
>> I apologize for the many recent questions but I have another trivia
>> question for all of you. :-)
>> I have installed the RH7.3 miniport to a harddrive connected to a MIPS
>> Malta board. The kernel the comes with the port (2.4.18) works fine. I
>> then took the cvs code (2.4.22) for mips and built it for malta. The 
>> first
>> few builds worked ok (which means I could logon as root). Then I changed
>> something in the build process so that now the kernels which I build 
>> won't
>> allow me to logon as root. I've changed /etc/passwd to eliminate the root
>> pw. Does anyone know how a kernel can affect the login like this?
>> Thanks,
>>
>> David Kesselring
>> Atmel MMC
>> dkesselr@mmc.atmel.com
>> 919-462-6587
>>
>>
>>
>>  
>>
> 
> 




From ysato@users.sourceforge.jp Wed Oct 22 17:11:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 17:11:47 +0100 (BST)
Received: from p060080.ppp.asahi-net.or.jp ([IPv6:::ffff:221.113.60.80]:2295
	"EHLO mitou.ysato.dip.jp") by linux-mips.org with ESMTP
	id <S8225433AbTJVQLo>; Wed, 22 Oct 2003 17:11:44 +0100
Received: from ss3380.ysato.zive.net (ss3380.localdomain [192.168.16.12])
	by mitou.ysato.dip.jp (Postfix) with ESMTP
	id 32B591C194; Thu, 23 Oct 2003 01:11:39 +0900 (JST)
Date: Thu, 23 Oct 2003 01:11:39 +0900
Message-ID: <m2he218d6s.wl%ysato@users.sourceforge.jp>
From: Yoshinori Sato <ysato@users.sourceforge.jp>
To: Matthew Wilcox <willy@debian.org>
Cc: Ralf Baechle <ralf@linux-mips.org>, Jeff Dike <jdike@karaya.com>,
	linux-mips@linux-mips.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: asm/smplock.h is dead
In-Reply-To: <20031021230932.GM18370@parcelfarce.linux.theplanet.co.uk>
References: <20031021230932.GM18370@parcelfarce.linux.theplanet.co.uk>
User-Agent: Wanderlust/2.11.7 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) LIMIT/1.14.7 (Fujiidera) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Return-Path: <ysato@users.sourceforge.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: 3489
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ysato@users.sourceforge.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 689
Lines: 25

At Wed, 22 Oct 2003 00:09:32 +0100,
Matthew Wilcox wrote:
> 
> 
> asm/smplock.h is dead, you're the only three arches that still have it.
> Can you delete next time you merge?  Thanks.
> 
> $ find -type f |xargs grep smplock.h      
> ./arch/mips/sibyte/sb1250/bcm1250_tbprof.c:#include <asm/smplock.h>
> ./include/asm-h8300/smplock.h: * <asm/smplock.h>
> ./include/asm-um/smplock.h:#include "asm/arch/smplock.h"
> $ find -name smplock.h
> ./include/asm-h8300/smplock.h
> ./include/asm-mips/smplock.h
> ./include/asm-um/smplock.h
> 
> (the sibyte driver can just lose this line.  it doesn't do any SMP locking)
> 

I deleted it.
Thank you.

-- 
Yoshinori Sato
<ysato@users.sourceforge.jp>

From jbglaw@dvmwest.gt.owl.de Wed Oct 22 18:34:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 18:34:48 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:11911 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225443AbTJVReq>; Wed, 22 Oct 2003 18:34:46 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 910354B3AB; Wed, 22 Oct 2003 19:34:44 +0200 (CEST)
Date: Wed, 22 Oct 2003 19:34:44 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: LK201 keyboard
Message-ID: <20031022173444.GI20846@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20031021202328.GO20846@lug-owl.de> <Pine.GSO.3.96.1031022155154.11598B-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="iCTk0txUZyshZga1"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1031022155154.11598B-100000@delta.ds2.pg.gda.pl>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
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: 3490
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1215
Lines: 39


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

On Wed, 2003-10-22 15:56:02 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
wrote in message <Pine.GSO.3.96.1031022155154.11598B-100000@delta.ds2.pg.gd=
a.pl>:
> On Tue, 21 Oct 2003, Jan-Benedict Glaw wrote:
>  No problem -- I'll look at it.  We'll need the down/up mode for X11, so
> it has to work.  Note: the LK4xx series keyboards start in the LK201

Erm, is this even correct if this keyboard isn't used "natively" by X11,
but through the Input API?

MfG, JBG

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

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

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

iD8DBQE/lr+0Hb1edYOZ4bsRAgp0AJ9JwS4vc8WA8SxnC8NIjYJBAs2GlwCeIqYV
GQEAunAMuMeQd5D3EC8E1yo=
=FwXO
-----END PGP SIGNATURE-----

--iCTk0txUZyshZga1--

From macro@ds2.pg.gda.pl Wed Oct 22 18:56:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Oct 2003 18:56:04 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:16885 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225443AbTJVR4C>; Wed, 22 Oct 2003 18:56:02 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA15067;
	Wed, 22 Oct 2003 19:55:58 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 22 Oct 2003 19:55:58 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
cc: linux-mips@linux-mips.org
Subject: Re: LK201 keyboard
In-Reply-To: <20031022173444.GI20846@lug-owl.de>
Message-ID: <Pine.GSO.3.96.1031022195223.11598O-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: 3491
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 584
Lines: 16

On Wed, 22 Oct 2003, Jan-Benedict Glaw wrote:

> >  No problem -- I'll look at it.  We'll need the down/up mode for X11, so
> > it has to work.  Note: the LK4xx series keyboards start in the LK201
> 
> Erm, is this even correct if this keyboard isn't used "natively" by X11,
> but through the Input API?

 For the console (or the cooked mode) we already set up the device
correctly.

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


From jbglaw@dvmwest.gt.owl.de Thu Oct 23 09:37:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 09:37:43 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:42477 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225258AbTJWIhl>; Thu, 23 Oct 2003 09:37:41 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 6203B4B3AB; Thu, 23 Oct 2003 10:37:37 +0200 (CEST)
Date: Thu, 23 Oct 2003 10:37:37 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: LK201 keyboard
Message-ID: <20031023083736.GL20846@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20031022173444.GI20846@lug-owl.de> <Pine.GSO.3.96.1031022195223.11598O-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="uv21/83lG8Dd/qOx"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1031022195223.11598O-100000@delta.ds2.pg.gda.pl>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
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: 3492
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1322
Lines: 43


--uv21/83lG8Dd/qOx
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, 2003-10-22 19:55:58 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
wrote in message <Pine.GSO.3.96.1031022195223.11598O-100000@delta.ds2.pg.gd=
a.pl>:
> On Wed, 22 Oct 2003, Jan-Benedict Glaw wrote:
> > Erm, is this even correct if this keyboard isn't used "natively" by X11,
> > but through the Input API?
>=20
>  For the console (or the cooked mode) we already set up the device
> correctly.

That doesn't exactly answer my question, but I think I'll figure it out
at some time:) At least, if I get XFree through the compiler at some
time (on a VAX).

MfG, JBG

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

--uv21/83lG8Dd/qOx
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/l5NQHb1edYOZ4bsRAj3rAJ4yJjJtG0ch82Lsdt/uPTVhaGaCrACeIF7a
FkhpZcMrjb+KOZxkJ+a/fEY=
=lo8n
-----END PGP SIGNATURE-----

--uv21/83lG8Dd/qOx--

From rathann@icm.edu.pl Thu Oct 23 09:52:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 09:52:52 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:52772 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225258AbTJWIwu>;
	Thu, 23 Oct 2003 09:52:50 +0100
Received: from rekin.icm.edu.pl (mail@rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id h9N8q2Hg012204;
	Thu, 23 Oct 2003 10:52:02 +0200 (CEST)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1ACbCN-0000VA-00; Thu, 23 Oct 2003 10:52:03 +0200
Date: Thu, 23 Oct 2003 10:52:03 +0200
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: Packages for RH 7.3/mips
Message-ID: <20031023085203.GA1064@icm.edu.pl>
Mail-Followup-To: "Gleb O. Raiko" <raiko@niisi.msk.ru>,
	linux-mips@linux-mips.org
References: <3F964D7E.DF3EB883@niisi.msk.ru> <20031022145956.GA16117@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031022145956.GA16117@lucon.org>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3493
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 915
Lines: 26

On Wed, Oct 22, 2003 at 07:59:56AM -0700, H. J. Lu wrote:
> I no longer work on MIPS. I forward your email to the Linux mips
> mailing list.
> 
> 
> H.J.
> ---
> On Wed, Oct 22, 2003 at 01:27:26PM +0400, Gleb O. Raiko wrote:
> > Hello!
> > 
> > My team is extended your RedHat 7.3 distribution for big-endian mips.
> > The work is done for our customer, but I, of course, would like to put
> > them for the public access. The best way in my opinion is to merge those
> > packages into your disribution for mips. Are you interesting?
> > 
> > Our goal was to get all packages cross compiled, so we have to patch
> > several packages from your disribution. Also, we had to fix a few minor
> > bugs.
 

Can you make these packages available somewhere? I'd be quite interested
in these. I also _may_ be able to make them available publicly as an apt
repository.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>

From raiko@niisi.msk.ru Thu Oct 23 10:12:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 10:13:31 +0100 (BST)
Received: from [IPv6:::ffff:193.232.173.111] ([IPv6:::ffff:193.232.173.111]:5413
	"EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP
	id <S8225360AbTJWJM7>; Thu, 23 Oct 2003 10:12:59 +0100
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.11.7/8.11.7) with ESMTP id h9NADIv25858
	for <linux-mips@linux-mips.org>; Thu, 23 Oct 2003 13:13:18 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA30883 for linux-mips@linux-mips.org; Thu, 23 Oct 2003 13:15:46 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34])
	by niisi.msk.ru (8.12.5/8.12.5) with ESMTP id h9N8p1nk000439
	for <linux-mips@linux-mips.org>; Thu, 23 Oct 2003 12:51:01 +0400 (MSK)
Message-ID: <3F97983C.57A34617@niisi.msk.ru>
Date: Thu, 23 Oct 2003 12:58:36 +0400
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Packages for RH 7.3/mips
References: <3F964D7E.DF3EB883@niisi.msk.ru> <20031022145956.GA16117@lucon.org>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Return-Path: <raiko@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3494
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: raiko@niisi.msk.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 257
Lines: 10

"H. J. Lu" wrote:
> I no longer work on MIPS. I forward your email to the Linux mips mailing list.

Well, does anybody in the list have an interest in?

Basically, I would like to follow GPL rules and put the packages for the
public access.

Regards,
Gleb.

From ralf.roesch@rw-gmbh.de Thu Oct 23 10:34:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 10:34:31 +0100 (BST)
Received: from [IPv6:::ffff:213.69.156.2] ([IPv6:::ffff:213.69.156.2]:30032
	"EHLO fw01.bwg.de") by linux-mips.org with ESMTP
	id <S8225345AbTJWJeV>; Thu, 23 Oct 2003 10:34:21 +0100
Received: by fw01.bwg.de (8.11.6p2G/8.11.6) id h9N9YH808554
	for linux-mips@linux-mips.org; Thu, 23 Oct 2003 11:34:17 +0200 (CEST)
Received: (from localhost) by fw01.bwg.de (MSCAN) id 3/fw01.bwg.de/smtp-gw/mscan; Thu Oct 23 11:34:17 2003
From: =?iso-8859-1?Q?Ralf_R=F6sch?= <ralf.roesch@rw-gmbh.de>
To: <linux-mips@linux-mips.org>
Subject: Compiler Problems in tlbex-r4k.S
Date: Thu, 23 Oct 2003 11:33:16 +0200
Message-ID: <NHBBLBCCGMJFJIKAMKLHOEIJCBAA.ralf.roesch@rw-gmbh.de>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0000_01C39959.73C38B80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <ralf.roesch@rw-gmbh.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: 3495
X-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.roesch@rw-gmbh.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1890
Lines: 68

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C39959.73C38B80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The latest update in tlbex-r4k.S (tag 2_4) produces
following compiler errors on my machine:

mipsel-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/build/linux-2.4.22-rthal5g-s
trom
boli/include -I /build/linux-2.4.22-rthal5g-stromboli/include/asm/gcc -G
0 -mno-
abicalls -fno-pic -pipe   -mcpu=r4600 -mips2 -Wa,--trap   -c -o tlbex-r4k.o
tlbe
x-r4k.S
tlbex-r4k.S: Assembler messages:
tlbex-r4k.S:179: Error: missing ')'
tlbex-r4k.S:179: Error: missing ')'
tlbex-r4k.S:179: Error: missing ')'
tlbex-r4k.S:179: Error: illegal operands `and'
tlbex-r4k.S:207: Error: missing ')'
tlbex-r4k.S:207: Error: missing ')'
tlbex-r4k.S:207: Error: missing ')'
tlbex-r4k.S:207: Error: illegal operands `and'
tlbex-r4k.S:243: Error: missing ')'
tlbex-r4k.S:243: Error: missing ')'
tlbex-r4k.S:243: Error: missing ')'
...

If I change the line 43 from:
#define PTE_PAGE_SIZE	(1L << PTE_PAGE_SHIFT)
to
#define PTE_PAGE_SIZE	(1 << PTE_PAGE_SHIFT)
the compiling is o.k.

Is that a compiler problem or an programming error ?

  Ralf



------=_NextPart_000_0000_01C39959.73C38B80
Content-Type: text/x-vcard;
	name="Ralf Roesch.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Ralf Roesch.vcf"

BEGIN:VCARD
VERSION:2.1
N:Roesch;Ralf
FN:Ralf Roesch
ORG:Roesch & Walter Industrie-Elektronik GmbH
TITLE:Managing Director
TEL;WORK;VOICE:+49 (7824) 6628-0
TEL;WORK;FAX:+49 (+49) 7824 6628-29
ADR;WORK:;;Im Heidenwinkel 5;Schwanau;;77963;Deutschland
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Im Heidenwinkel =
5=3D0D=3D0ASchwanau 77963=3D0D=3D0ADeutschland
URL;WORK:http://www.rw-gmbh.de
EMAIL;PREF;INTERNET:ralf.roesch@rw-gmbh.de
REV:20010405T072400Z
END:VCARD

------=_NextPart_000_0000_01C39959.73C38B80--


From Geert.Uytterhoeven@sonycom.com Thu Oct 23 10:43:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 10:43:34 +0100 (BST)
Received: from [IPv6:::ffff:80.88.36.193] ([IPv6:::ffff:80.88.36.193]:9903
	"EHLO witte.sonytel.be") by linux-mips.org with ESMTP
	id <S8225365AbTJWJnc>; Thu, 23 Oct 2003 10:43:32 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id h9N9hSQG001587;
	Thu, 23 Oct 2003 11:43:28 +0200 (MEST)
Date: Thu, 23 Oct 2003 11:43:27 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: =?iso-8859-1?Q?Ralf_R=F6sch?= <ralf.roesch@rw-gmbh.de>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Compiler Problems in tlbex-r4k.S
In-Reply-To: <NHBBLBCCGMJFJIKAMKLHOEIJCBAA.ralf.roesch@rw-gmbh.de>
Message-ID: <Pine.GSO.4.21.0310231142250.27218-100000@waterleaf.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
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: 3496
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1603
Lines: 49

On Thu, 23 Oct 2003, [iso-8859-1] Ralf Rösch wrote:
> The latest update in tlbex-r4k.S (tag 2_4) produces
> following compiler errors on my machine:
> 
> mipsel-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/build/linux-2.4.22-rthal5g-s
> trom
> boli/include -I /build/linux-2.4.22-rthal5g-stromboli/include/asm/gcc -G
> 0 -mno-
> abicalls -fno-pic -pipe   -mcpu=r4600 -mips2 -Wa,--trap   -c -o tlbex-r4k.o
> tlbe
> x-r4k.S
> tlbex-r4k.S: Assembler messages:
> tlbex-r4k.S:179: Error: missing ')'
> tlbex-r4k.S:179: Error: missing ')'
> tlbex-r4k.S:179: Error: missing ')'
> tlbex-r4k.S:179: Error: illegal operands `and'
> tlbex-r4k.S:207: Error: missing ')'
> tlbex-r4k.S:207: Error: missing ')'
> tlbex-r4k.S:207: Error: missing ')'
> tlbex-r4k.S:207: Error: illegal operands `and'
> tlbex-r4k.S:243: Error: missing ')'
> tlbex-r4k.S:243: Error: missing ')'
> tlbex-r4k.S:243: Error: missing ')'
> ...
> 
> If I change the line 43 from:
> #define PTE_PAGE_SIZE	(1L << PTE_PAGE_SHIFT)
> to
> #define PTE_PAGE_SIZE	(1 << PTE_PAGE_SHIFT)
> the compiling is o.k.
> 
> Is that a compiler problem or an programming error ?

That's a programming error. The assembler doesn't know 1L, it needs plain 1.

Yes, it makes life hard, if you want to share your definitions between the
C compiler and the assembler.

Gr{oetje,eeting}s,

						Geert

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

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


From ralf@linux-mips.org Thu Oct 23 17:33:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 17:33:54 +0100 (BST)
Received: from p508B6021.dip.t-dialin.net ([IPv6:::ffff:80.139.96.33]:34491
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225365AbTJWQds>; Thu, 23 Oct 2003 17:33: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 h9NGXdNK014277;
	Thu, 23 Oct 2003 18:33:39 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9NGXV1b014276;
	Thu, 23 Oct 2003 18:33:31 +0200
Date: Thu, 23 Oct 2003 18:33:31 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf R?sch <ralf.roesch@rw-gmbh.de>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Compiler Problems in tlbex-r4k.S
Message-ID: <20031023163331.GA27437@linux-mips.org>
References: <NHBBLBCCGMJFJIKAMKLHOEIJCBAA.ralf.roesch@rw-gmbh.de> <Pine.GSO.4.21.0310231142250.27218-100000@waterleaf.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0310231142250.27218-100000@waterleaf.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: 3497
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 708
Lines: 21

On Thu, Oct 23, 2003 at 11:43:27AM +0200, Geert Uytterhoeven wrote:

> > If I change the line 43 from:
> > #define PTE_PAGE_SIZE	(1L << PTE_PAGE_SHIFT)
> > to
> > #define PTE_PAGE_SIZE	(1 << PTE_PAGE_SHIFT)
> > the compiling is o.k.

The fix for this went into CVS yesterday.

> That's a programming error. The assembler doesn't know 1L, it needs plain 1.
> 
> Yes, it makes life hard, if you want to share your definitions between the
> C compiler and the assembler.

It's a PITA that gas doesn't accept constants in the same syntax as C
does.  It means we have to extract many constants into offset.h before
they can be used in assembler code.  One of the small things on my
wishlist for x-mas ;-)

  Ralf

From sjhill@realitydiluted.com Thu Oct 23 18:39:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 18:40:02 +0100 (BST)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:15039
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225365AbTJWRjt>; Thu, 23 Oct 2003 18:39:49 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1ACjQi-0003cT-00; Thu, 23 Oct 2003 12:39:24 -0500
Message-ID: <3F981241.5030703@realitydiluted.com>
Date: Thu, 23 Oct 2003 13:39:13 -0400
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031010 Debian/1.4-6
X-Accept-Language: en
MIME-Version: 1.0
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
CC: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: Packages for RH 7.3/mips
References: <3F964D7E.DF3EB883@niisi.msk.ru> <20031022145956.GA16117@lucon.org> <3F97983C.57A34617@niisi.msk.ru>
In-Reply-To: <3F97983C.57A34617@niisi.msk.ru>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3498
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 339
Lines: 13

Gleb O. Raiko wrote:
> 
> Well, does anybody in the list have an interest in?
> 
> Basically, I would like to follow GPL rules and put the packages for the
> public access.
>
Well, it's good to have the stuff available. I would ask
Ralf if he would be willing to add your packages onto the
main ftp.linux-mips.org FTP site. Ralf?

-Steve


From kwalker@broadcom.com Thu Oct 23 19:41:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 19:41:44 +0100 (BST)
Received: from mms1.broadcom.com ([IPv6:::ffff:63.70.210.58]:24071 "EHLO
	mms1.broadcom.com") by linux-mips.org with ESMTP
	id <S8225377AbTJWSll>; Thu, 23 Oct 2003 19:41:41 +0100
Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.5.3)); Thu, 23 Oct 2003 11:41:29 -0700
Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com
 [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id LAA09842; Thu, 23 Oct 2003 11:41:00 -0700 (PDT)
Received: from broadcom.com (ldt-sj3-158 [10.21.64.158]) by
 mail-sj1-1.sj.broadcom.com (8.12.9/8.12.4/SSM) with ESMTP id
 h9NIfMKX002301; Thu, 23 Oct 2003 11:41:28 -0700 (PDT)
Message-ID: <3F9820D2.528E0C73@broadcom.com>
Date: Thu, 23 Oct 2003 11:41:22 -0700
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.20-18.7 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ralf Baechle" <ralf@linux-mips.org>
cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Ralf R?sch" <ralf.roesch@rw-gmbh.de>,
	"Linux/MIPS Development" <linux-mips@linux-mips.org>
Subject: Re: Compiler Problems in tlbex-r4k.S
References: <NHBBLBCCGMJFJIKAMKLHOEIJCBAA.ralf.roesch@rw-gmbh.de>
 <Pine.GSO.4.21.0310231142250.27218-100000@waterleaf.sonytel.be>
 <20031023163331.GA27437@linux-mips.org>
X-WSS-ID: 1386FF531622908-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <kwalker@broadcom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3499
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kwalker@broadcom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 426
Lines: 19

Ralf Baechle wrote:
> 
> On Thu, Oct 23, 2003 at 11:43:27AM +0200, Geert Uytterhoeven wrote:
> 
> > > If I change the line 43 from:
> > > #define PTE_PAGE_SIZE       (1L << PTE_PAGE_SHIFT)
> > > to
> > > #define PTE_PAGE_SIZE       (1 << PTE_PAGE_SHIFT)
> > > the compiling is o.k.
> 
> The fix for this went into CVS yesterday.

Actually, this is a new problem which was my fault.  I'm checking in the
fix.

Apologies!

Kip


From dkesselr@mmc.atmel.com Thu Oct 23 19:52:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 19:52:19 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:15453
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225377AbTJWSwR>; Thu, 23 Oct 2003 19:52:17 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id OAA09496;
	Thu, 23 Oct 2003 14:51:58 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id OAA16615;
	Thu, 23 Oct 2003 14:51:58 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Thu, 23 Oct 2003 14:51:58 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: Tiemo Krueger - mycable GmbH <tk@mycable.de>
cc: linux-mips@linux-mips.org
Subject: Re: root login
In-Reply-To: <3F969106.5000807@mycable.de>
Message-ID: <Pine.GSO.4.44.0310231449190.15850-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3500
X-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
Content-Length: 1735
Lines: 59

I am able to login as a user and su to root. I still have not found the
reason for the problem. Well, for now I have something that works.
Thanks for the help.
David

On Wed, 22 Oct 2003, Tiemo Krueger - mycable GmbH wrote:

> Hmm, I remember that we had once a similar problem, but I can't remember
> the reason
> nor the solution. It appeared that we where not able to login as root,
> but user login was possible.
> Logged in as user I was allowed to 'su' to root.
> Perhaps this may be a hint, perhaps not, perhaps Bruno remembers the
> solution???
>
> Tiemo
>
> David Kesselring wrote:
>
> >I apologize for the many recent questions but I have another trivia
> >question for all of you. :-)
> >I have installed the RH7.3 miniport to a harddrive connected to a MIPS
> >Malta board. The kernel the comes with the port (2.4.18) works fine. I
> >then took the cvs code (2.4.22) for mips and built it for malta. The first
> >few builds worked ok (which means I could logon as root). Then I changed
> >something in the build process so that now the kernels which I build won't
> >allow me to logon as root. I've changed /etc/passwd to eliminate the root
> >pw. Does anyone know how a kernel can affect the login like this?
> >Thanks,
> >
> >David Kesselring
> >Atmel MMC
> >dkesselr@mmc.atmel.com
> >919-462-6587
> >
> >
> >
> >
> >
>
>
> --
> -------------------------------------------------------
> Tiemo Krueger       Tel:  +49 48 73 90 19 86
> mycable GmbH        Fax: +49 48 73 90 19 76
> Boeker Stieg 43
> D-24613 Aukrug      eMail: tk@mycable.de
>
> Public Kryptographic Key is available on request
> -------------------------------------------------------
>
>
>

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


From lyle@zevion.com Thu Oct 23 19:52:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 19:52:42 +0100 (BST)
Received: from rrcs-central-24-123-115-43.biz.rr.com ([IPv6:::ffff:24.123.115.43]:50181
	"EHLO Radium.intranet") by linux-mips.org with ESMTP
	id <S8225428AbTJWSw0>; Thu, 23 Oct 2003 19:52:26 +0100
Received: from radium ([192.168.1.22])
	by Radium.intranet (8.9.3/8.9.3) with ESMTP id NAA14192;
	Thu, 23 Oct 2003 13:43:51 -0500
From: "Lyle Bainbridge" <lyle@zevion.com>
To: "'Gleb O. Raiko'" <raiko@niisi.msk.ru>, <linux-mips@linux-mips.org>
Subject: RE: Packages for RH 7.3/mips
Date: Thu, 23 Oct 2003 13:52:20 -0500
Message-ID: <000001c39996$c9f5d020$800101df@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: <3F97983C.57A34617@niisi.msk.ru>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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: 3501
X-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
Content-Length: 703
Lines: 31

Hi,

Yes, I'm very interested.  It looks like useful stuff, and it would be a
shame not
not capture it somewhere for public use.

Nice work Gleb!

Lyle

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Gleb O. Raiko
> Sent: Thursday, October 23, 2003 3:59 AM
> To: linux-mips@linux-mips.org
> Subject: Re: Packages for RH 7.3/mips
> 
> 
> "H. J. Lu" wrote:
> > I no longer work on MIPS. I forward your email to the Linux mips 
> > mailing list.
> 
> Well, does anybody in the list have an interest in?
> 
> Basically, I would like to follow GPL rules and put the 
> packages for the public access.
> 
> Regards,
> Gleb.
> 


From ppopov@mvista.com Thu Oct 23 20:05:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 20:05:25 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:32246 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225383AbTJWTFX>;
	Thu, 23 Oct 2003 20:05:23 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA30187;
	Thu, 23 Oct 2003 12:05:01 -0700
Subject: RE: Packages for RH 7.3/mips
From: Pete Popov <ppopov@mvista.com>
To: Lyle Bainbridge <lyle@zevion.com>
Cc: "'Gleb O. Raiko'" <raiko@niisi.msk.ru>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <000001c39996$c9f5d020$800101df@radium>
References: <000001c39996$c9f5d020$800101df@radium>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1066936052.22664.66.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 23 Oct 2003 12:07:33 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3502
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 903
Lines: 40

On Thu, 2003-10-23 at 11:52, Lyle Bainbridge wrote:
> Hi,
> 
> Yes, I'm very interested.  It looks like useful stuff, and it would be a
> shame not
> not capture it somewhere for public use.
> 
> Nice work Gleb!

So did anyone volunteer any disk space for these packages to be
uploaded?

Pete

> Lyle
> 
> > -----Original Message-----
> > From: linux-mips-bounce@linux-mips.org 
> > [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Gleb O. Raiko
> > Sent: Thursday, October 23, 2003 3:59 AM
> > To: linux-mips@linux-mips.org
> > Subject: Re: Packages for RH 7.3/mips
> > 
> > 
> > "H. J. Lu" wrote:
> > > I no longer work on MIPS. I forward your email to the Linux mips 
> > > mailing list.
> > 
> > Well, does anybody in the list have an interest in?
> > 
> > Basically, I would like to follow GPL rules and put the 
> > packages for the public access.
> > 
> > Regards,
> > Gleb.
> > 
> 
> 
> 


From sjhill@realitydiluted.com Thu Oct 23 21:03:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Oct 2003 21:03:11 +0100 (BST)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:27840
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225366AbTJWUDJ>; Thu, 23 Oct 2003 21:03:09 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1AClf1-0003i9-00; Thu, 23 Oct 2003 15:02:19 -0500
Message-ID: <3F9833C9.6070005@realitydiluted.com>
Date: Thu, 23 Oct 2003 16:02:17 -0400
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031010 Debian/1.4-6
X-Accept-Language: en
MIME-Version: 1.0
To: Pete Popov <ppopov@mvista.com>
CC: Lyle Bainbridge <lyle@zevion.com>,
	"'Gleb O. Raiko'" <raiko@niisi.msk.ru>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Packages for RH 7.3/mips
References: <000001c39996$c9f5d020$800101df@radium> <1066936052.22664.66.camel@zeus.mvista.com>
In-Reply-To: <1066936052.22664.66.camel@zeus.mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3503
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 420
Lines: 14

Pete Popov wrote:
> On Thu, 2003-10-23 at 11:52, Lyle Bainbridge wrote:
> 
> So did anyone volunteer any disk space for these packages to be
> uploaded?
>
I'll volunteer disk space for them off of my server, but I
thought it would be nice if they could be put on the main
'linux-mips.org' site. I think Ralf is gone for the evening
though. In the meantime, I would be more than happy to host
them for you Gleb.

-Steve


From raiko@niisi.msk.ru Fri Oct 24 10:04:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Oct 2003 10:04:41 +0100 (BST)
Received: from [IPv6:::ffff:193.232.173.111] ([IPv6:::ffff:193.232.173.111]:26224
	"EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP
	id <S8225368AbTJXJEJ>; Fri, 24 Oct 2003 10:04:09 +0100
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.11.7/8.11.7) with ESMTP id h9OA4Ov21892;
	Fri, 24 Oct 2003 13:04:25 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA11575; Fri, 24 Oct 2003 13:02:45 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34])
	by niisi.msk.ru (8.12.5/8.12.5) with ESMTP id h9O8nXXv001203;
	Fri, 24 Oct 2003 12:49:34 +0400 (MSK)
Message-ID: <3F98E968.76D1BC6B@niisi.msk.ru>
Date: Fri, 24 Oct 2003 12:57:12 +0400
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: David Kesselring <dkesselr@mmc.atmel.com>
CC: Tiemo Krueger - mycable GmbH <tk@mycable.de>,
	linux-mips@linux-mips.org
Subject: Re: root login
References: <Pine.GSO.4.44.0310231449190.15850-100000@ares.mmc.atmel.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Return-Path: <raiko@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3504
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: raiko@niisi.msk.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 262
Lines: 10

David Kesselring wrote:
> 
> I am able to login as a user and su to root. I still have not found the
> reason for the problem. Well, for now I have something that works.

Current date is too far from a file timestamp. Try back to the future.
:-)

Regrads,
Gleb.

From ralf@linux-mips.org Fri Oct 24 13:44:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Oct 2003 13:44:25 +0100 (BST)
Received: from p508B6A58.dip.t-dialin.net ([IPv6:::ffff:80.139.106.88]:42642
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225440AbTJXMoP>; Fri, 24 Oct 2003 13:44: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 h9OCi1NK008012;
	Fri, 24 Oct 2003 14:44:01 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9OChupX007995;
	Fri, 24 Oct 2003 14:43:56 +0200
Date: Fri, 24 Oct 2003 14:43:56 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: Pete Popov <ppopov@mvista.com>, Lyle Bainbridge <lyle@zevion.com>,
	"'Gleb O. Raiko'" <raiko@niisi.msk.ru>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Packages for RH 7.3/mips
Message-ID: <20031024124355.GB27437@linux-mips.org>
References: <000001c39996$c9f5d020$800101df@radium> <1066936052.22664.66.camel@zeus.mvista.com> <3F9833C9.6070005@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F9833C9.6070005@realitydiluted.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: 3505
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 442
Lines: 14

On Thu, Oct 23, 2003 at 04:02:17PM -0400, Steven J. Hill wrote:

> >So did anyone volunteer any disk space for these packages to be
> >uploaded?
> >
> I'll volunteer disk space for them off of my server, but I
> thought it would be nice if they could be put on the main
> 'linux-mips.org' site. I think Ralf is gone for the evening
> though. In the meantime, I would be more than happy to host
> them for you Gleb.

Sure, no problem.

  Ralf

From dkesselr@mmc.atmel.com Fri Oct 24 14:11:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Oct 2003 14:11:39 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:23719
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225442AbTJXNLe>; Fri, 24 Oct 2003 14:11:34 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA18352
	for <linux-mips@linux-mips.org>; Fri, 24 Oct 2003 09:11:27 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA17407
	for <linux-mips@linux-mips.org>; Fri, 24 Oct 2003 09:11:26 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Fri, 24 Oct 2003 09:11:26 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: configuring 2 ethernet ports
Message-ID: <Pine.GSO.4.44.0310240905590.17395-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3506
X-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
Content-Length: 501
Lines: 13

I am trying to setup a pci wlan nic on a Malta board. I've compiled the
driver into the kernel and I have setup
/etc/sysconfig/network-scripts/ifcfg-eth1. After boot, when I look at
/proc/pci it looks like the system detected the card fine but ifconfig
only shows eth0 (the builtin port). How is the pci id linked to a
particular driver? What else do I need to do? I've scoured google but have
not come up with an answer. Thanks again,

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


From jbglaw@dvmwest.gt.owl.de Fri Oct 24 14:18:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Oct 2003 14:18:44 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:19343 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225471AbTJXNSk>; Fri, 24 Oct 2003 14:18:40 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id A7E974A8E5; Fri, 24 Oct 2003 15:18:38 +0200 (CEST)
Date: Fri, 24 Oct 2003 15:18:38 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: configuring 2 ethernet ports
Message-ID: <20031024131838.GE12395@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <Pine.GSO.4.44.0310240905590.17395-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="tMbDGjvJuJijemkf"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0310240905590.17395-100000@ares.mmc.atmel.com>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
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: 3507
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1854
Lines: 52


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

On Fri, 2003-10-24 09:11:26 -0400, David Kesselring <dkesselr@mmc.atmel.com>
wrote in message <Pine.GSO.4.44.0310240905590.17395-100000@ares.mmc.atmel.c=
om>:
> I am trying to setup a pci wlan nic on a Malta board. I've compiled the
> driver into the kernel and I have setup

Which brand of wlan card?

> /etc/sysconfig/network-scripts/ifcfg-eth1. After boot, when I look at
> /proc/pci it looks like the system detected the card fine but ifconfig
> only shows eth0 (the builtin port). How is the pci id linked to a
> particular driver? What else do I need to do? I've scoured google but have

In 2.4.x, drivers tend to only have internal knowledge on which hardware
they work. So you need to give some 'alias eth1 wlanmodulename' in your
/etc/modules.conf file.

For 2.6.x, drivers export this table and (in theory), the hotplug
scripts *can* load a driver just upon the card showing up. However,
normally (for static network cards not handled by the hotplug API),
you'll just use the exactly same line, but in /etc/modprobe.conf.

MfG, JBG

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

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

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

iD8DBQE/mSauHb1edYOZ4bsRAhd3AJ92aagsoSOcmkgXul2TyPhZt0FW4gCgiTsZ
jtpZCZ4GKUYDBEm8Rf3b5D0=
=eznI
-----END PGP SIGNATURE-----

--tMbDGjvJuJijemkf--

From dkesselr@mmc.atmel.com Fri Oct 24 14:41:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Oct 2003 14:41:33 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:31665
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225471AbTJXNla> convert rfc822-to-8bit; Fri, 24 Oct 2003 14:41:30 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA18862;
	Fri, 24 Oct 2003 09:41:23 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id JAA17513;
	Fri, 24 Oct 2003 09:41:23 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Fri, 24 Oct 2003 09:41:23 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
cc: linux-mips@linux-mips.org
Subject: Re: configuring 2 ethernet ports
In-Reply-To: <20031024131838.GE12395@lug-owl.de>
Message-ID: <Pine.GSO.4.44.0310240931350.17395-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8BIT
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: 3508
X-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
Content-Length: 1904
Lines: 49


On Fri, 24 Oct 2003, Jan-Benedict Glaw wrote:

> On Fri, 2003-10-24 09:11:26 -0400, David Kesselring <dkesselr@mmc.atmel.com>
> wrote in message <Pine.GSO.4.44.0310240905590.17395-100000@ares.mmc.atmel.com>:
> > I am trying to setup a pci wlan nic on a Malta board. I've compiled the
> > driver into the kernel and I have setup
>
> Which brand of wlan card?

It's an internal card.

>
> > /etc/sysconfig/network-scripts/ifcfg-eth1. After boot, when I look at
> > /proc/pci it looks like the system detected the card fine but ifconfig
> > only shows eth0 (the builtin port). How is the pci id linked to a
> > particular driver? What else do I need to do? I've scoured google but have
>
> In 2.4.x, drivers tend to only have internal knowledge on which hardware
> they work. So you need to give some 'alias eth1 wlanmodulename' in your
> /etc/modules.conf file.
>
I am using 2.4. Why does eth1 need a modules.conf file and eth0 doesn't. I
do not have loadable modules configured for my kernel. Do I have to? I
don't even have a current modules.conf file.
I also checked /etc/sysconfig/hwconf. This has the pci listing for my card
but does not recognize the vendor or id. I did add an entry in the kernel
source pci_ids.h for my card.


> For 2.6.x, drivers export this table and (in theory), the hotplug
> scripts *can* load a driver just upon the card showing up. However,
> normally (for static network cards not handled by the hotplug API),
> you'll just use the exactly same line, but in /etc/modprobe.conf.
>
> MfG, JBG
>
> --
>    Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
>    "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
>     fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
>    ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
>

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


From jbglaw@dvmwest.gt.owl.de Fri Oct 24 15:40:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Oct 2003 15:40:30 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:59280 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225476AbTJXOkX>; Fri, 24 Oct 2003 15:40:23 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 7353C4A949; Fri, 24 Oct 2003 16:40:12 +0200 (CEST)
Date: Fri, 24 Oct 2003 16:40:12 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: configuring 2 ethernet ports
Message-ID: <20031024144012.GF12395@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20031024131838.GE12395@lug-owl.de> <Pine.GSO.4.44.0310240931350.17395-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="RE3pQJLXZi4fr8Xo"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0310240931350.17395-100000@ares.mmc.atmel.com>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
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: 3509
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 3062
Lines: 77


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

On Fri, 2003-10-24 09:41:23 -0400, David Kesselring <dkesselr@mmc.atmel.com>
wrote in message <Pine.GSO.4.44.0310240931350.17395-100000@ares.mmc.atmel.c=
om>:
> On Fri, 24 Oct 2003, Jan-Benedict Glaw wrote:
> > On Fri, 2003-10-24 09:11:26 -0400, David Kesselring <dkesselr@mmc.atmel=
=2Ecom>
> > wrote in message <Pine.GSO.4.44.0310240905590.17395-100000@ares.mmc.atm=
el.com>:
> > > /etc/sysconfig/network-scripts/ifcfg-eth1. After boot, when I look at
> > > /proc/pci it looks like the system detected the card fine but ifconfig
> > > only shows eth0 (the builtin port). How is the pci id linked to a
> > > particular driver? What else do I need to do? I've scoured google but=
 have
> >
> > In 2.4.x, drivers tend to only have internal knowledge on which hardware
> > they work. So you need to give some 'alias eth1 wlanmodulename' in your
> > /etc/modules.conf file.
> >
> I am using 2.4. Why does eth1 need a modules.conf file and eth0 doesn't. I

This is the case if you've compiled the driver for eth0 directly into
the kernel. Then, it'll automatically be started and userspace got an
interface to configure.

If it isn't directly compiled in, you've to give it a chance to figure
out the correct driver, eg. by a module.conf "alias" line or by a simple
modprobe somewhere...

> do not have loadable modules configured for my kernel. Do I have to? I
> don't even have a current modules.conf file.

You don't *need* to have modules. ...but then, you need to have the
correct driver compiled in. If it's already compiled in, then it
apparently doesn't recognize the card. In this case, the PCI table
inside the module's code is missing the PCI vendor/device ID.

> I also checked /etc/sysconfig/hwconf. This has the pci listing for my card
> but does not recognize the vendor or id. I did add an entry in the kernel
> source pci_ids.h for my card.

That's not enough. By doing this, you tell the *readers* of this header
file that there's a new vendor or device. That doesn't tell the
*drivers* that they've got a new supported device. So if you compiled-in
the correct driver and 'ifconfig -a' doesn't show it, then it seems that
the (correct) driver incorrectly doesn't know your device IDs. Add those
to the driver's PCI ID table.

MfG, JBG

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

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

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

iD8DBQE/mTnMHb1edYOZ4bsRAnXtAJ49GygvMaIXlEH9rggKn08JVaYrjwCfa7X8
5/dUJb3JSh3D9TuyDEWQTaA=
=g3Nk
-----END PGP SIGNATURE-----

--RE3pQJLXZi4fr8Xo--

From js@convergence.de Fri Oct 24 16:13:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Oct 2003 16:13:34 +0100 (BST)
Received: from mail.convergence.de ([IPv6:::ffff:212.84.236.4]:2711 "EHLO
	mail.convergence.de") by linux-mips.org with ESMTP
	id <S8225480AbTJXPNa>; Fri, 24 Oct 2003 16:13:30 +0100
Received: from [10.1.1.146] (helo=heck)
	by mail.convergence.de with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.14)
	id 1AD3aq-0006gz-Cp
	for linux-mips@linux-mips.org; Fri, 24 Oct 2003 17:11:12 +0200
Received: from js by heck with local (Exim 3.35 #1 (Debian))
	id 1AD3d0-0006bZ-00
	for <linux-mips@linux-mips.org>; Fri, 24 Oct 2003 17:13:26 +0200
Date: Fri, 24 Oct 2003 17:13:25 +0200
From: Johannes Stezenbach <js@convergence.de>
To: linux-mips@linux-mips.org
Subject: random kernel panics with 2.4.22 running on VR4120A
Message-ID: <20031024151325.GB22979@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: 3510
X-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
Content-Length: 4639
Lines: 110

Hi,

we've been using a 2.4.21 snapshot from linux-mips.org CVS for
about two months on a set-top-box chip with VR4120A core. This kernel
was rock solid.

After the 2.4.22 merge in linux-mips.org CVS I updated our kernel,
from 2.4.21-2003-07-08 to 2.4.22-2003-09-24, and now we are getting
occational kernel panics at random places, either one of:

  Unhandled kernel unaligned access in unaligned.c::emulate_load_store_insn, line 481:
  Kernel unaligned instruction access in unaligned.c::do_ade, line 550:

It happens about once per day on a box wich continously runs
a test suite, and rather seldom on other boxes.

I searched through the diff from 2.4.21-2003-07-08 to 2.4.22-2003-09-24, but did
not find something obvious (to me, at least ;).
I also checked the post-2003-09-24 CVS logs for possible bug fixes, but there's
no log message that clearly addresses such a problem.
I haven't yet tried to update to a newer kernel, but can do so.

Below is a (slightly censored) example Oops, but the actual place where it
crashes seems random.
I would greatly appreciate any hints. Are other VR41xx users seeing similar problems?

Our kernel is tainted due to proprietary modules being loaded, but the
same modules worked with 2.4.21-2003-07-08.


Unhandled kernel unaligned access in unaligned.c::emulate_load_store_insn, line 481:
$0 : 00000000 80a20000 00000000 0000001b 00005000 809ec000 80a197f4 00000000
$8 : 3d75d353 00000000 10008400 00000000 80a41b16 fffffff8 837f7c92 0000000a
$16: 00000001 00000001 00000000 80a18960 80a09080 fffffffe 00000006 00000001
$24: ffffffff 00000002                   837f6000 837f6160 810b5ec0 8081ca68
epc  : 8081c9a0    Tainted: P
Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
Status: 10008403
Cause : 00000010
Process  (pid: 8, stackpage=837f6000)
Stack:    837f6000 00000001 00000000 8081c8b8 80a34468 80a34468 837f6170
 837f6170 80a18980 80818a38 837f6228 00000007 80a18980 8081cfb4 80818850
 003b1174 003b1174 003b1174 7c354722 80808ad4 00000001 80a090a0 fffffffe
 10008400 80a18960 80a090a0 8081827c 837f6228 80a18964 808010a0 0d5e4000
 00014400 80a080e0 00000007 80a15b80 fffffffb 837f6228 837f7eb8 808013c4
 80801374 ...
Call Trace:   [<8081c8b8>] [<80818a38>] [<8081cfb4>] [<80818850>] [<80808ad4>]
 [<8081827c>] [<808010a0>] [<808013c4>] [<80801374>] [<c01d0340>] [<c01d0340>]
 [<c01cd874>] [<809b980c>] [<80812870>] [<c01cce54>] [<809deca5>] [<c01d0340>]
 [<c01d0340>] [<c01cd874>] [<c01cffc3>] [<c01cc090>] [<c01cc0e0>] [<c01cffc0>]
 [<c01cffc4>] [<c01d0340>] [<c01cc2b8>] [<c01cfffc>] [<c01d0018>] [<c01cd874>]
 [<c01d0340>] [<c01ccc70>] [<c01cffc3>] [<c01d0340>] [<c01cce70>] [<c01cc0e0>]
 [<c01d0340>] [<c01cc114>] [<c01cffc0>] [<c01cffc4>] [<c01d0340>] ...
Warning (Oops_trace_line): garbage '...' at end of trace line ignored
Code: 1062000d  00002021  00402821 <8c620000> 50400006  24840800  8c620000  30420002  50400003


>>$1; 80a20000 <urandom_fops+38/48>
>>$5; 809ec000 <init_task_union+0/2000>
>>$6; 80a197f4 <xtime+4/8>
>>$12; 80a41b16 <printk_buf.916+26/400>
>>$14; 837f7c92 <_end+2d952a2/3f658670>
>>$19; 80a18960 <irq_stat+0/20>
>>$20; 80a09080 <tasklet_hi_vec+0/20>
>>$28; 837f6000 <_end+2d93610/3f658670>
>>$29; 837f6160 <_end+2d93770/3f658670>
>>$30; 810b5ec0 <_end+6534d0/3f658670>
>>$31; 8081ca68 <timer_bh+94/53c>

>>PC;  8081c9a0 <count_active_tasks+1c/50>   <=====

Trace; 8081c8b8 <update_process_times+38/104>
Trace; 80818a38 <bh_action+34/c8>
Trace; 8081cfb4 <do_timer+a4/134>
Trace; 80818850 <tasklet_hi_action+110/190>
Trace; 80808ad4 <timer_interrupt+74/208>
Trace; 8081827c <do_softirq+bc/184>
Trace; 808010a0 <handle_IRQ_event+84/f8>
Trace; 808013c4 <do_IRQ+f4/118>
Trace; 80801374 <do_IRQ+a4/118>
Trace; 809b980c <vr4120_handle_irq+12c/220>
Trace; 80812870 <_call_console_drivers+6c/7c>
[snip]

Code;  8081c994 <count_active_tasks+10/50>
00000000 <_PC>:
Code;  8081c994 <count_active_tasks+10/50>
   0:   1062000d  beq     v1,v0,38 <_PC+0x38>
Code;  8081c998 <count_active_tasks+14/50>
   4:   00002021  move    a0,zero
Code;  8081c99c <count_active_tasks+18/50>
   8:   00402821  move    a1,v0
Code;  8081c9a0 <count_active_tasks+1c/50>   <=====
   c:   8c620000  lw      v0,0(v1)   <=====
Code;  8081c9a4 <count_active_tasks+20/50>
  10:   50400006  0x50400006
Code;  8081c9a8 <count_active_tasks+24/50>
  14:   24840800  addiu   a0,a0,2048
Code;  8081c9ac <count_active_tasks+28/50>
  18:   8c620000  lw      v0,0(v1)
Code;  8081c9b0 <count_active_tasks+2c/50>
  1c:   30420002  andi    v0,v0,0x2
Code;  8081c9b4 <count_active_tasks+30/50>
  20:   50400003  0x50400003

Kernel panic: Aiee, killing interrupt handler!


Regards,
Johannes

From zhanght@netpower.com.cn Sat Oct 25 12:26:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Oct 2003 12:26:38 +0100 (BST)
Received: from [IPv6:::ffff:211.154.175.2] ([IPv6:::ffff:211.154.175.2]:22790
	"EHLO mail.netpower.com.cn") by linux-mips.org with ESMTP
	id <S8225386AbTJYL0g>; Sat, 25 Oct 2003 12:26:36 +0100
Received: from netpower.com.cn [192.168.0.195] by mail.netpower.com.cn with ESMTP
  (SMTPD32-7.07) id AC20B201FC; Sat, 25 Oct 2003 19:18:56 +0800
Message-ID: <3F9A5DE8.5080308@netpower.com.cn>
Date: Sat, 25 Oct 2003 19:26:32 +0800
From: Zhang Haitao <zhanght@netpower.com.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.2.1) Gecko/20030225
X-Accept-Language: zh-cn,zh
MIME-Version: 1.0
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
CC: "'Gleb O. Raiko'" <raiko@niisi.msk.ru>
Subject: Re: Packages for RH 7.3/mips
References: <000001c39996$c9f5d020$800101df@radium> <1066936052.22664.66.camel@zeus.mvista.com> <3F9833C9.6070005@realitydiluted.com> <20031024124355.GB27437@linux-mips.org>
In-Reply-To: <20031024124355.GB27437@linux-mips.org>
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: 3511
X-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
Content-Length: 780
Lines: 34

Hi, Gleb

all your source package can be compiled using mipsel cross compiler and 
running on little endian machine?
would you mind publish your RPMs with src tarballs (or patches) at the 
same time?
or can you rebuild your distribution for mipsel?

thanks in advance!


				Yours
Zhang Haitao

Ralf Baechle wrote:
> On Thu, Oct 23, 2003 at 04:02:17PM -0400, Steven J. Hill wrote:
> 
> 
>>>So did anyone volunteer any disk space for these packages to be
>>>uploaded?
>>>
>>
>>I'll volunteer disk space for them off of my server, but I
>>thought it would be nice if they could be put on the main
>>'linux-mips.org' site. I think Ralf is gone for the evening
>>though. In the meantime, I would be more than happy to host
>>them for you Gleb.
> 
> 
> Sure, no problem.
> 
>   Ralf



From TERESAT@TTI-DM.COM Sat Oct 25 17:44:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Oct 2003 17:44:39 +0100 (BST)
Received: from [IPv6:::ffff:66.121.16.190] ([IPv6:::ffff:66.121.16.190]:185
	"EHLO trid-mail1.tridentmicro.com") by linux-mips.org with ESMTP
	id <S8225407AbTJYQoh> convert rfc822-to-8bit; Sat, 25 Oct 2003 17:44:37 +0100
content-class: urn:content-classes:message
Subject: need help on bus error problem
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 8BIT
Date: Sat, 25 Oct 2003 09:44:35 -0700
Message-ID: <92F2591F460F684C9C309EB0D33256FA01B54329@trid-mail1.tridentmicro.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: need help on bus error problem
Thread-Index: AcObF0X0mItjLbcfQ4OzPzvO8C2f1w==
From: "Teresa Tao" <TERESAT@TTI-DM.COM>
To: <linux-mips@linux-mips.org>
Return-Path: <TERESAT@TTI-DM.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3512
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: TERESAT@TTI-DM.COM
Precedence: bulk
X-list: linux-mips
Content-Length: 727
Lines: 14

Hi there,

I am working on an real time video playback applicaion on a mips cpu. But after my video application play a while like 5 to 10 minutes, a bus error happened.

We add some debug meesage in the kernel, so we know that after the do_ade function inside the unalign.c, the bus error happens for the opcode lw or sw. So my guess is that I have an unaligned memory pointer(not in 4 byte boundary).
But my puzzle is that if I have an unaligned memory pointer, it should happen at the first loop I playback, how come it happens after it plays several loops?
Is there a possibility that my application's stack being trashed after a while? but I don't have recursive calls inside my application.


Thanks in advance!

Teresa



From dkesselr@mmc.atmel.com Mon Oct 27 13:55:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 13:55:38 +0000 (GMT)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:46179
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225344AbTJ0Nzc>; Mon, 27 Oct 2003 13:55:32 +0000
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id IAA17745
	for <linux-mips@linux-mips.org>; Mon, 27 Oct 2003 08:55:20 -0500 (EST)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id IAA19653
	for <linux-mips@linux-mips.org>; Mon, 27 Oct 2003 08:55:19 -0500 (EST)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Mon, 27 Oct 2003 08:55:19 -0500 (EST)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: Relocation errors
Message-ID: <Pine.GSO.4.44.0310270852380.19642-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3513
X-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
Content-Length: 231
Lines: 9

I'm getting the error "Unhandled relocation of type xx" on insmod. Are the
"types" documented somewhere? I am I correct that these "types" are
architecture specific?

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


From drow@crack.them.org Mon Oct 27 14:58:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 14:58:11 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:63195 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225344AbTJ0O6H>;
	Mon, 27 Oct 2003 14:58:07 +0000
Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian))
	id 1AE8ol-00070b-OX; Mon, 27 Oct 2003 09:58:03 -0500
Date: Mon, 27 Oct 2003 09:58:03 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Relocation errors
Message-ID: <20031027145803.GA26911@nevyn.them.org>
References: <Pine.GSO.4.44.0310270852380.19642-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0310270852380.19642-100000@ares.mmc.atmel.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3514
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 445
Lines: 11

On Mon, Oct 27, 2003 at 08:55:19AM -0500, David Kesselring wrote:
> I'm getting the error "Unhandled relocation of type xx" on insmod. Are the
> "types" documented somewhere? I am I correct that these "types" are
> architecture specific?

Yes.  Try an ELF specification - there's a MIPS processor supplement
(psABI) floating around.  What's the "xx"?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From dkesselr@mmc.atmel.com Mon Oct 27 15:07:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 15:07:12 +0000 (GMT)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:16765
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225344AbTJ0PHA>; Mon, 27 Oct 2003 15:07:00 +0000
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA19381;
	Mon, 27 Oct 2003 10:06:53 -0500 (EST)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA19753;
	Mon, 27 Oct 2003 10:06:53 -0500 (EST)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Mon, 27 Oct 2003 10:06:53 -0500 (EST)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: Daniel Jacobowitz <dan@debian.org>
cc: linux-mips@linux-mips.org
Subject: Re: Relocation errors
In-Reply-To: <20031027145803.GA26911@nevyn.them.org>
Message-ID: <Pine.GSO.4.44.0310271002480.19642-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3515
X-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
Content-Length: 834
Lines: 28

It is type 8. Any ideas? This is from an intel driver that I've cross
compiled for mips. I used these options;
-mcpu=r4600 -mips2 -mno-abicalls -fno-pic -mlong-calls -Wa,--trap -DMODULE
-pipe -O3 -fomit-frame-pointer -fno-strict-aliasing

Thanks, David

On Mon, 27 Oct 2003, Daniel Jacobowitz wrote:

> On Mon, Oct 27, 2003 at 08:55:19AM -0500, David Kesselring wrote:
> > I'm getting the error "Unhandled relocation of type xx" on insmod. Are the
> > "types" documented somewhere? I am I correct that these "types" are
> > architecture specific?
>
> Yes.  Try an ELF specification - there's a MIPS processor supplement
> (psABI) floating around.  What's the "xx"?
>
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>
>

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


From drow@crack.them.org Mon Oct 27 15:14:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 15:14:34 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:2268 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225344AbTJ0POW>;
	Mon, 27 Oct 2003 15:14:22 +0000
Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian))
	id 1AE94X-00076w-4N; Mon, 27 Oct 2003 10:14:21 -0500
Date: Mon, 27 Oct 2003 10:14:21 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Relocation errors
Message-ID: <20031027151421.GA27279@nevyn.them.org>
References: <20031027145803.GA26911@nevyn.them.org> <Pine.GSO.4.44.0310271002480.19642-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0310271002480.19642-100000@ares.mmc.atmel.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3516
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1344
Lines: 42

Take a look at /usr/include/elf.h:
#define R_MIPS_LITERAL          8       /* 16 bit literal entry */

In this case it's not very informative.  But the problem is probably
mismatched CFLAGS.  Take another look at the options the kernel is
built with - you lost -G 0.  See if that does it.


On Mon, Oct 27, 2003 at 10:06:53AM -0500, David Kesselring wrote:
> It is type 8. Any ideas? This is from an intel driver that I've cross
> compiled for mips. I used these options;
> -mcpu=r4600 -mips2 -mno-abicalls -fno-pic -mlong-calls -Wa,--trap -DMODULE
> -pipe -O3 -fomit-frame-pointer -fno-strict-aliasing
> 
> Thanks, David
> 
> On Mon, 27 Oct 2003, Daniel Jacobowitz wrote:
> 
> > On Mon, Oct 27, 2003 at 08:55:19AM -0500, David Kesselring wrote:
> > > I'm getting the error "Unhandled relocation of type xx" on insmod. Are the
> > > "types" documented somewhere? I am I correct that these "types" are
> > > architecture specific?
> >
> > Yes.  Try an ELF specification - there's a MIPS processor supplement
> > (psABI) floating around.  What's the "xx"?
> >
> > --
> > Daniel Jacobowitz
> > MontaVista Software                         Debian GNU/Linux Developer
> >
> >
> 
> David Kesselring
> Atmel MMC
> dkesselr@mmc.atmel.com
> 919-462-6587
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ralf@linux-mips.org Mon Oct 27 16:06:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 16:06:12 +0000 (GMT)
Received: from p508B7DF8.dip.t-dialin.net ([IPv6:::ffff:80.139.125.248]:31413
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225344AbTJ0QGJ>; Mon, 27 Oct 2003 16:06:09 +0000
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 h9RG66NK023430;
	Mon, 27 Oct 2003 17:06:06 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9RG6455023429;
	Mon, 27 Oct 2003 17:06:04 +0100
Date: Mon, 27 Oct 2003 17:06:04 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: David Kesselring <dkesselr@mmc.atmel.com>,
	linux-mips@linux-mips.org
Subject: Re: Relocation errors
Message-ID: <20031027160604.GA23292@linux-mips.org>
References: <20031027145803.GA26911@nevyn.them.org> <Pine.GSO.4.44.0310271002480.19642-100000@ares.mmc.atmel.com> <20031027151421.GA27279@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031027151421.GA27279@nevyn.them.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3517
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 755
Lines: 19

On Mon, Oct 27, 2003 at 10:14:21AM -0500, Daniel Jacobowitz wrote:
> Date: Mon, 27 Oct 2003 10:14:21 -0500
> From: Daniel Jacobowitz <dan@debian.org>
> To: David Kesselring <dkesselr@mmc.atmel.com>
> Cc: linux-mips@linux-mips.org
> Subject: Re: Relocation errors
> Content-Type: text/plain; charset=us-ascii
> 
> Take a look at /usr/include/elf.h:
> #define R_MIPS_LITERAL          8       /* 16 bit literal entry */
> 
> In this case it's not very informative.  But the problem is probably
> mismatched CFLAGS.  Take another look at the options the kernel is
> built with - you lost -G 0.  See if that does it.

My gcc patches used to set this to zero because the -G optimization doesn't
work on Linux; I think HJ Lu's (?) gcc patches lost this.

  Ralf

From TERESAT@TTI-DM.COM Mon Oct 27 17:44:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 17:44:13 +0000 (GMT)
Received: from [IPv6:::ffff:66.121.16.190] ([IPv6:::ffff:66.121.16.190]:35307
	"EHLO trid-mail1.tridentmicro.com") by linux-mips.org with ESMTP
	id <S8225344AbTJ0RoK> convert rfc822-to-8bit; Mon, 27 Oct 2003 17:44:10 +0000
content-class: urn:content-classes:message
Subject: question regarding bss section
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 8BIT
Date: Mon, 27 Oct 2003 09:44:05 -0800
Message-ID: <92F2591F460F684C9C309EB0D33256FA01B750B3@trid-mail1.tridentmicro.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: question regarding bss section
Thread-Index: AcOcseq6NSMm2DSSQI6oL2751s5g8g==
From: "Teresa Tao" <TERESAT@TTI-DM.COM>
To: <linux-mips@linux-mips.org>
Return-Path: <TERESAT@TTI-DM.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3518
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: TERESAT@TTI-DM.COM
Precedence: bulk
X-list: linux-mips
Content-Length: 589
Lines: 10

Hi there,

I have several questions and hope somebody could help me with the answers:
1. how to use gcc to compile the user mode program with larger stack size?
2. Inside the user mode program, I have declared some gloabal data which is being put on the bss section and I would like to know whom initialize the bss section? How big is the bss section? Under what kind of situation, the bss section data could be corrupted?
3. What's the difference to compile the program with -G 0 option? That menas I don't use the $gp register, will there be any side effect?

Thanks in advance!

Teresa

From jsun@mvista.com Mon Oct 27 17:50:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 17:50:03 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:17403 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225344AbTJ0RuA>;
	Mon, 27 Oct 2003 17:50:00 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h9RHnss01701;
	Mon, 27 Oct 2003 09:49:54 -0800
Date: Mon, 27 Oct 2003 09:49:54 -0800
From: Jun Sun <jsun@mvista.com>
To: Teresa Tao <TERESAT@TTI-DM.COM>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: need help on bus error problem
Message-ID: <20031027094954.B1678@mvista.com>
References: <92F2591F460F684C9C309EB0D33256FA01B54329@trid-mail1.tridentmicro.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <92F2591F460F684C9C309EB0D33256FA01B54329@trid-mail1.tridentmicro.com>; from TERESAT@TTI-DM.COM on Sat, Oct 25, 2003 at 09:44:35AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3519
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 979
Lines: 18

On Sat, Oct 25, 2003 at 09:44:35AM -0700, Teresa Tao wrote:
> Hi there,
> 
> I am working on an real time video playback applicaion on a mips cpu. But after my video application play a while like 5 to 10 minutes, a bus error happened.
> 
> We add some debug meesage in the kernel, so we know that after the do_ade function inside the unalign.c, the bus error happens for the opcode lw or sw. So my guess is that I have an unaligned memory pointer(not in 4 byte boundary).
> But my puzzle is that if I have an unaligned memory pointer, it should happen at the first loop I playback, how come it happens after it plays several loops?
> 

There are many reasons for having bus error, cache, errant pointers,
unstable hardware, or some tricky kernel bugs which happens when
certain conditions happen together.

> Is there a possibility that my application's stack being trashed after a while? but I don't have recursive calls inside my application.

Everything is possible.  :)

Jun

From ralf@linux-mips.org Mon Oct 27 18:10:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 18:10:03 +0000 (GMT)
Received: from p508B7DF8.dip.t-dialin.net ([IPv6:::ffff:80.139.125.248]:44220
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225344AbTJ0SKA>; Mon, 27 Oct 2003 18:10:00 +0000
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 h9RI9wNK025978;
	Mon, 27 Oct 2003 19:09:58 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9RI9vgT025977;
	Mon, 27 Oct 2003 19:09:57 +0100
Date: Mon, 27 Oct 2003 19:09:57 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Teresa Tao <TERESAT@TTI-DM.COM>
Cc: linux-mips@linux-mips.org
Subject: Re: question regarding bss section
Message-ID: <20031027180957.GA25797@linux-mips.org>
References: <92F2591F460F684C9C309EB0D33256FA01B750B3@trid-mail1.tridentmicro.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <92F2591F460F684C9C309EB0D33256FA01B750B3@trid-mail1.tridentmicro.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: 3520
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1107
Lines: 32

On Mon, Oct 27, 2003 at 09:44:05AM -0800, Teresa Tao wrote:

> I have several questions and hope somebody could help me with the answers:
> 1. how to use gcc to compile the user mode program with larger stack size?

Not at all.  Stack size is a resource limit which is set with can be
manipulated with setrlimit(2) or in bash with the ulimit command.  It
defaults to 8MB.

For pthread applications the stack size is a thead attribute, seem libc
manual.

> 2. Inside the user mode program, I have declared some gloabal data which
> is being put on the bss section and I would like to know whom initialize
> the bss section?

.bss is uninitialized.  Initialized data can't be in .bss.

> How big is the bss section? Under what kind of situation,

As big as needed for everything in it.

> the bss section data could be corrupted?

There's millions of ways of writing broken code.

> 3. What's the difference to compile the program with -G 0 option? That
> menas I don't use the $gp register, will there be any side effect?

-G 0 is the default for userspace.  Iow. passing the option changed nothing.

  Ralf

From wd@denx.de Mon Oct 27 18:16:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 18:17:24 +0000 (GMT)
Received: from mailout07.sul.t-online.com ([IPv6:::ffff:194.25.134.83]:16317
	"EHLO mailout07.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225344AbTJ0SQw>; Mon, 27 Oct 2003 18:16:52 +0000
Received: from fwd08.aul.t-online.de 
	by mailout07.sul.t-online.com with smtp 
	id 1AEBv6-0008Dy-02; Mon, 27 Oct 2003 19:16:48 +0100
Received: from denx.de (Gh9zDoZvYebC6C2rgcyyIl7dt1A6UB7GL16p1a4UJ+l3GWaxl7naEG@[217.235.255.254]) by fmrl08.sul.t-online.com
	with esmtp id 1AEBur-1Qsv9U0; Mon, 27 Oct 2003 19:16:33 +0100
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 64F3D42C67; Mon, 27 Oct 2003 19:16:31 +0100 (MET)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 199CEC59E4; Mon, 27 Oct 2003 19:16:30 +0100 (MET)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 0CAA9C545E; Mon, 27 Oct 2003 19:16:30 +0100 (MET)
To: "Teresa Tao" <TERESAT@TTI-DM.COM>
Cc: linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: question regarding bss section 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Mon, 27 Oct 2003 09:44:05 PST."
             <92F2591F460F684C9C309EB0D33256FA01B750B3@trid-mail1.tridentmicro.com> 
Date: Mon, 27 Oct 2003 19:16:24 +0100
Message-Id: <20031027181630.199CEC59E4@atlas.denx.de>
X-Seen: false
X-ID: Gh9zDoZvYebC6C2rgcyyIl7dt1A6UB7GL16p1a4UJ+l3GWaxl7naEG@t-dialin.net
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3521
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2049
Lines: 50

Dear Teresa,

in message <92F2591F460F684C9C309EB0D33256FA01B750B3@trid-mail1.tridentmicro.com> you wrote:
> 
> I have several questions and hope somebody could help me with the answers:
> 1. how to use gcc to compile the user mode program with larger stack size?

You don't. The Linux kernel will autyomagically grow the stack as needed.

> 2. Inside the user mode program, I have declared some gloabal data
> which is being put on the bss section and I would like to know whom
> initialize the bss section? How big is the bss section? Under what
> kind of situation, the bss section data could be corrupted?

The kernel resp. the C runtime environment will  initialize  the  BSS
for you. The BSS will be initialized with zero values.

The BSS section is as big as needed to put all  objects  of  matching
type into it (this is determined at link time).

The BSS may get corrupted in exactly the  same  situations  when  any
other memroy corruption can happen, i. e. typically writing through a
rogue  pointer,  writing  beyound  the valid index range of an array,
errors using malloc() and free(0, etc.

> 3. What's the difference to compile the program with -G  0  option?
> That  menas  I  don't  use  the  $gp register, will there be any side
> effect?

Quoting the GCC info pages:

`-G NUM'
     Put global and static objects less than or equal to NUM bytes into
     the small data or bss sections instead of the normal data or bss
     sections.  The default value of NUM is 8.  The `-msdata' option
     must be set to one of `sdata' or `use' for this option to have any
     effect.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"I dislike companies that have a we-are-the-high-priests-of-hardware-
so-you'll-like-what-we-give-you attitude. I like commodity markets in
which iron-and-silicon hawkers know that they exist to  provide  fast
toys for software types like me to play with..."    - Eric S. Raymond

From wd@denx.de Mon Oct 27 18:17:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 18:18:16 +0000 (GMT)
Received: from mailout03.sul.t-online.com ([IPv6:::ffff:194.25.134.81]:16359
	"EHLO mailout03.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225389AbTJ0SRd>; Mon, 27 Oct 2003 18:17:33 +0000
Received: from fwd03.aul.t-online.de 
	by mailout03.sul.t-online.com with smtp 
	id 1AEBvn-00012H-00; Mon, 27 Oct 2003 19:17:31 +0100
Received: from denx.de (bNXLnUZAgeUjDyOHZpl2Ll3uOjRm-cy+g9+CTNOu4lR9YWBjHzdmQ9@[217.235.255.254]) by fmrl03.sul.t-online.com
	with esmtp id 1AEBva-1Qptc80; Mon, 27 Oct 2003 19:17:18 +0100
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 3845D42C67; Mon, 27 Oct 2003 19:17:17 +0100 (MET)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 1A2E1C59E4; Mon, 27 Oct 2003 19:17:17 +0100 (MET)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 16DCFC545E; Mon, 27 Oct 2003 19:17:17 +0100 (MET)
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Teresa Tao <TERESAT@TTI-DM.COM>, linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: question regarding bss section 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Mon, 27 Oct 2003 19:09:57 +0100."
             <20031027180957.GA25797@linux-mips.org> 
Date: Mon, 27 Oct 2003 19:17:12 +0100
Message-Id: <20031027181717.1A2E1C59E4@atlas.denx.de>
X-Seen: false
X-ID: bNXLnUZAgeUjDyOHZpl2Ll3uOjRm-cy+g9+CTNOu4lR9YWBjHzdmQ9@t-dialin.net
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3522
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips
Content-Length: 404
Lines: 14

In message <20031027180957.GA25797@linux-mips.org> you wrote:
> 
> .bss is uninitialized.  Initialized data can't be in .bss.

No. BSS is initialized as zero.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Life is a game. Money is how we keep score.              - Ted Turner

From ralf@linux-mips.org Mon Oct 27 19:08:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 19:08:38 +0000 (GMT)
Received: from p508B7DF8.dip.t-dialin.net ([IPv6:::ffff:80.139.125.248]:3776
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225344AbTJ0TIf>; Mon, 27 Oct 2003 19:08:35 +0000
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 h9RJ8VNK027659;
	Mon, 27 Oct 2003 20:08:31 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9RJ8TCm027658;
	Mon, 27 Oct 2003 20:08:30 +0100
Date: Mon, 27 Oct 2003 20:08:29 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Wolfgang Denk <wd@denx.de>
Cc: Teresa Tao <TERESAT@TTI-DM.COM>, linux-mips@linux-mips.org
Subject: Re: question regarding bss section
Message-ID: <20031027190829.GB24946@linux-mips.org>
References: <20031027180957.GA25797@linux-mips.org> <20031027181717.1A2E1C59E4@atlas.denx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031027181717.1A2E1C59E4@atlas.denx.de>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3523
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 236
Lines: 9

On Mon, Oct 27, 2003 at 07:17:12PM +0100, Wolfgang Denk wrote:

> > .bss is uninitialized.  Initialized data can't be in .bss.
> 
> No. BSS is initialized as zero.

RTFM.  It's unitialized because not contained in the binaries.

  Ralf

From wd@denx.de Mon Oct 27 19:49:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 19:50:05 +0000 (GMT)
Received: from mailout08.sul.t-online.com ([IPv6:::ffff:194.25.134.20]:22665
	"EHLO mailout08.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225344AbTJ0Ttd>; Mon, 27 Oct 2003 19:49:33 +0000
Received: from fwd06.aul.t-online.de 
	by mailout08.sul.t-online.com with smtp 
	id 1AEDMp-0000mB-0L; Mon, 27 Oct 2003 20:49:31 +0100
Received: from denx.de (Gh9zDeZAreZ7n2a78InzEhClROio2DUbbhHVCTdVMXQ65HMzsyALkM@[217.235.255.254]) by fmrl06.sul.t-online.com
	with esmtp id 1AEDMh-0vYAca0; Mon, 27 Oct 2003 20:49:23 +0100
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 5D71B42E25; Mon, 27 Oct 2003 20:49:21 +0100 (MET)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 8D301C59E4; Mon, 27 Oct 2003 20:49:20 +0100 (MET)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 89791C545E; Mon, 27 Oct 2003 20:49:20 +0100 (MET)
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: question regarding bss section 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Mon, 27 Oct 2003 20:08:29 +0100."
             <20031027190829.GB24946@linux-mips.org> 
Date: Mon, 27 Oct 2003 20:49:15 +0100
Message-Id: <20031027194920.8D301C59E4@atlas.denx.de>
X-Seen: false
X-ID: Gh9zDeZAreZ7n2a78InzEhClROio2DUbbhHVCTdVMXQ65HMzsyALkM@t-dialin.net
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3524
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1106
Lines: 31

In message <20031027190829.GB24946@linux-mips.org> you wrote:
> 
> > > .bss is uninitialized.  Initialized data can't be in .bss.
> > 
> > No. BSS is initialized as zero.
> 
> RTFM.  It's unitialized because not contained in the binaries.

When an application runs it will see the BSS space as initialized  as
zero.

In most implementations of ANSI C that I am aware of (including GCC /
glibc), the BSS segment will be used for uninitialized variables with
"static" storage  class.  Also,  I've  seen  some  compilers  to  put
variables eplicitly initialized to zero into the BSS segment, too. To
quote the C FAQ:

    Uninitialized variables with "static" duration (that is, those
    declared outside of functions, and those declared with the
    storage class static), are guaranteed to start out as zero, as if
    the programmer had typed "= 0". Therefore, such variables


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Quantum particles: The dreams that stuff is made of.

From ralf@linux-mips.org Mon Oct 27 23:01:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 23:01:45 +0000 (GMT)
Received: from p508B7DF8.dip.t-dialin.net ([IPv6:::ffff:80.139.125.248]:27597
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225391AbTJ0XBl>; Mon, 27 Oct 2003 23:01:41 +0000
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 h9RN1cNK005555;
	Tue, 28 Oct 2003 00:01:38 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9RN1aSr005554;
	Tue, 28 Oct 2003 00:01:36 +0100
Date: Tue, 28 Oct 2003 00:01:36 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Wolfgang Denk <wd@denx.de>
Cc: linux-mips@linux-mips.org
Subject: Re: question regarding bss section
Message-ID: <20031027230136.GA27764@linux-mips.org>
References: <20031027190829.GB24946@linux-mips.org> <20031027194920.8D301C59E4@atlas.denx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031027194920.8D301C59E4@atlas.denx.de>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3525
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1244
Lines: 27

On Mon, Oct 27, 2003 at 08:49:15PM +0100, Wolfgang Denk wrote:

> In most implementations of ANSI C that I am aware of (including GCC /
> glibc), the BSS segment will be used for uninitialized variables with
> "static" storage  class.  Also,  I've  seen  some  compilers  to  put
> variables eplicitly initialized to zero into the BSS segment, too. To
> quote the C FAQ:
> 
>     Uninitialized variables with "static" duration (that is, those
>     declared outside of functions, and those declared with the
>     storage class static), are guaranteed to start out as zero, as if
>     the programmer had typed "= 0". Therefore, such variables

C doesn't know about .bss at all - no single mentioning in the ISO C
standard.  But .bss is a section name used in the ELF binary format which
most Linux systems are using.  The gABI says defines .bss:

.bss	This section holds uninitialized data that contribute to the
	program s memory image. By definition, the system initializes
	the data with zeros when the program begins to run. The section
	occupies no file space, as indicated by the section type,
	SHT_NOBITS.

Certainly the term ``uninitialized'' isn't as precise as desirable but
that's the wording used in the relevant standard.

  Ralf

From gherlein@herlein.com Mon Oct 27 23:11:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Oct 2003 23:11:06 +0000 (GMT)
Received: from m205-235.dsl.tsoft.com ([IPv6:::ffff:198.144.205.235]:18324
	"EHLO lists.herlein.com") by linux-mips.org with ESMTP
	id <S8225405AbTJ0XLE>; Mon, 27 Oct 2003 23:11:04 +0000
Received: from io.herlein.com (io.herlein.com [192.168.70.244])
	by lists.herlein.com (Postfix) with ESMTP id 42135A33
	for <linux-mips@linux-mips.org>; Mon, 27 Oct 2003 15:19:32 -0800 (PST)
Date: Mon, 27 Oct 2003 11:15:30 -0800 (PST)
From: Greg Herlein <gherlein@herlein.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Pb1500 and PCMCIA booting?
Message-ID: <Pine.LNX.4.44.0310271113460.604-100000@io.herlein.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <gherlein@herlein.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3526
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gherlein@herlein.com
Precedence: bulk
X-list: linux-mips
Content-Length: 364
Lines: 12

Does anyone have advice/experience in what's the best way to get 
linux booting from the Pb1500 development board directly off 
PCMCIA?  I'm susepcting that getting a bootable filesystem rigged 
up on a CF card and using my handy CF <-> PCMCIA adapter card to 
get it onto the bus.  

Any advice/gotchas/hints as I start down this path?

Thanks in advance,

Greg


From ppopov@mvista.com Tue Oct 28 00:16:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 00:16:40 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:61687 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225391AbTJ1AQi>;
	Tue, 28 Oct 2003 00:16:38 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA03382;
	Mon, 27 Oct 2003 16:16:30 -0800
Subject: Re: Pb1500 and PCMCIA booting?
From: Pete Popov <ppopov@mvista.com>
To: Greg Herlein <gherlein@herlein.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <Pine.LNX.4.44.0310271113460.604-100000@io.herlein.com>
References: <Pine.LNX.4.44.0310271113460.604-100000@io.herlein.com>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1067300192.22671.254.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 27 Oct 2003 16:16:32 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3527
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1141
Lines: 28

Greg,

On Mon, 2003-10-27 at 11:15, Greg Herlein wrote:
> Does anyone have advice/experience in what's the best way to get 
> linux booting from the Pb1500 development board directly off 
> PCMCIA?  I'm susepcting that getting a bootable filesystem rigged 
> up on a CF card and using my handy CF <-> PCMCIA adapter card to 
> get it onto the bus.  
> 
> Any advice/gotchas/hints as I start down this path?

If you want to boot Linux off pcmcia, you need to add that support to
yamon or whatever boot code you're using.

If you're talking about using a pcmcia for a root file system, then what
you can do is:

- build your root fs and dump it on the pcmcia card
- create a small ramdisk which you'll statically link into your kernel.
Your ramdisk will be your temporary root FS and should contain on it
things like the pcmcia modules and socket driver, a script that loads
them, cardmgr, insmod, mount, and ... I don't remember what else but
that's pretty much it. The kernel mounts the ramdisk root fs, executes
your script which does its magic, then control is passed to the kernel
which mounts the real root fs on the pcmcia card.

Pete


From dan@embeddededge.com Tue Oct 28 00:30:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 00:30:27 +0000 (GMT)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:61569 "EHLO
	tibook.netx4.com") by linux-mips.org with ESMTP id <S8225391AbTJ1AaY>;
	Tue, 28 Oct 2003 00:30:24 +0000
Received: from embeddededge.com (IDENT:dan@localhost.localdomain [127.0.0.1])
	by tibook.netx4.com (8.11.1/8.11.1) with ESMTP id h9S1WA901369;
	Mon, 27 Oct 2003 20:32:10 -0500
Message-ID: <3F9DC719.50700@embeddededge.com>
Date: Mon, 27 Oct 2003 20:32:09 -0500
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Greg Herlein <gherlein@herlein.com>
CC: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Pb1500 and PCMCIA booting?
References: <Pine.LNX.4.44.0310271113460.604-100000@io.herlein.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dan@embeddededge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3528
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@embeddededge.com
Precedence: bulk
X-list: linux-mips
Content-Length: 994
Lines: 30

Greg Herlein wrote:

> Does anyone have advice/experience in what's the best way to get 
> linux booting from the Pb1500 development board directly off 
> PCMCIA?

Yes, but actually getting something to boot is the easy part.
When you look down the road to real products there are various
methods of software update/recovery chosen depending upon
the environment, device and features.

> Any advice/gotchas/hints as I start down this path?

There are various open source boot rom projects that you
can use to find examples of doing this.  If you don't want
to replace yamon on the board, just write some code (from
the boot rom examples) that initializes the PCMCIA, knows
how to peruse the file system of your choice, can read
the kernel into memory and jump to it.  Put this code
someplace in the flash so you can start it from yamon.

Depending upon the tools you have, this is probably
the "best" because it doesn't affect a working boot
rom on the board, just extends it use.


	-- Dan




From gherlein@herlein.com Tue Oct 28 00:40:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 00:40:13 +0000 (GMT)
Received: from m205-235.dsl.tsoft.com ([IPv6:::ffff:198.144.205.235]:38292
	"EHLO lists.herlein.com") by linux-mips.org with ESMTP
	id <S8225391AbTJ1AkL>; Tue, 28 Oct 2003 00:40:11 +0000
Received: from io.herlein.com (io.herlein.com [192.168.70.244])
	by lists.herlein.com (Postfix) with ESMTP id D6E8EA2F
	for <linux-mips@linux-mips.org>; Mon, 27 Oct 2003 16:48:27 -0800 (PST)
Date: Mon, 27 Oct 2003 12:41:39 -0800 (PST)
From: Greg Herlein <gherlein@herlein.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Pb1500 and PCMCIA booting?
In-Reply-To: <3F9DC719.50700@embeddededge.com>
Message-ID: <Pine.LNX.4.44.0310271238070.25452-100000@io.herlein.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <gherlein@herlein.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3529
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gherlein@herlein.com
Precedence: bulk
X-list: linux-mips
Content-Length: 905
Lines: 22

> just write some code (from the boot rom examples) that
> initializes the PCMCIA, knows how to peruse the file system of
> your choice, can read the kernel into memory and jump to it.  
> Put this code someplace in the flash so you can start it from
> yamon.

Sounds good.  Looks like I should be able to create a two 
partition CF card that has the kernel on one partition and the 
root filesystem on another.  Then, do as you suggest and cook up 
some raw code that can put the Au1500 in reset and access the CF 
directly, read the kernel into memory and jump to it.  If the 
kernel is rigged to then mount the root filesystem from the other 
partition, then I have a workable system on one CF.

For the real product, the cooked code that yamon would load 
would replace yamon and get loaded as a bootloader directly.

If anyone has suggestions, references, or comments, I'd love to 
hear them.

Greg


From raiko@niisi.msk.ru Tue Oct 28 09:28:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 09:29:10 +0000 (GMT)
Received: from [IPv6:::ffff:193.232.173.111] ([IPv6:::ffff:193.232.173.111]:40240
	"EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP
	id <S8225356AbTJ1J2i>; Tue, 28 Oct 2003 09:28:38 +0000
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.11.7/8.11.7) with ESMTP id h9SASSv25100;
	Tue, 28 Oct 2003 13:28:28 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA31641; Tue, 28 Oct 2003 13:30:04 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34])
	by niisi.msk.ru (8.12.5/8.12.5) with ESMTP id h9S9IWXv004724;
	Tue, 28 Oct 2003 12:18:32 +0300 (MSK)
Message-ID: <3F9E346A.B57D80EC@niisi.msk.ru>
Date: Tue, 28 Oct 2003 12:18:34 +0300
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Zhang Haitao <zhanght@netpower.com.cn>
CC: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Packages for RH 7.3/mips
References: <000001c39996$c9f5d020$800101df@radium> <1066936052.22664.66.camel@zeus.mvista.com> <3F9833C9.6070005@realitydiluted.com> <20031024124355.GB27437@linux-mips.org> <3F9A5DE8.5080308@netpower.com.cn>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Return-Path: <raiko@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3531
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: raiko@niisi.msk.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 691
Lines: 24

Zhang Haitao wrote:
> all your source package can be compiled using mipsel cross compiler and
> running on little endian machine?
Most of them.

> would you mind publish your RPMs with src tarballs (or patches) at the
> same time?

Yes.

> or can you rebuild your distribution for mipsel?

No, I can't. I haven't a LE mips box to test them.

I'd like to note we solve problems related to BE mips boxes. LE ones
have a better support in HJL's RH 7.3/mips distribution due to the fact
ix86 is LE too.

No wonder, I expect several of our packages can't be compiled for LE,
but it's easy to fix. More importand all  packages but glibc-{locales,
timezones} can be cross-compiled.

Regards,
Gleb.

From anemo@mba.ocn.ne.jp Tue Oct 28 14:32:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 14:32:37 +0000 (GMT)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:52698 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225394AbTJ1OcF>; Tue, 28 Oct 2003 14:32:05 +0000
Received: from localhost (p7054-ipad28funabasi.chiba.ocn.ne.jp [220.107.206.54])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 55E355524
	for <linux-mips@linux-mips.org>; Tue, 28 Oct 2003 23:32:02 +0900 (JST)
Date: Tue, 28 Oct 2003 23:49:49 +0900 (JST)
Message-Id: <20031028.234949.74756121.anemo@mba.ocn.ne.jp>
To: linux-mips@linux-mips.org
Subject: Re: SysV IPC in mips64
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030826.210612.115929945.nemoto@toshiba-tops.co.jp>
References: <20030826.210612.115929945.nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 3536
X-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

Are there any comments about this problem?  glibc does not use this
old-style interfaces but uClibc does.

>>>>> On Tue, 26 Aug 2003 21:06:12 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:

anemo> Some SysV IPC using old-style (without IPC_64 flag) does not
anemo> work on mips64 kernel.

anemo> I think SysV IPC conversion routine should set/clear IPC_64
anemo> flag when calling native system-call routine if the conversion
anemo> routine pass their own data structures.

anemo> * should set IPC_64 for semid64_ds, msqid64_ds, shmid64_ds.
anemo> * should clear IPC_64 for shmid_ds.

Here is a patch against current 2.4 CVS.  Can be applied for 2.6 with
some offsets.

diff -u linux-mips-cvs/arch/mips64/kernel/linux32.c linux.new/arch/mips64/kernel/linux32.c
--- linux-mips-cvs/arch/mips64/kernel/linux32.c	Fri Oct 24 00:01:35 2003
+++ linux.new/arch/mips64/kernel/linux32.c	Tue Oct 28 22:56:54 2003
@@ -1802,7 +1802,7 @@
 		fourth.__pad = &s;
 		old_fs = get_fs ();
 		set_fs (KERNEL_DS);
-		err = sys_semctl (first, second, third, fourth);
+		err = sys_semctl (first, second, third | IPC_64, fourth);
 		set_fs (old_fs);
 
 		if (third & IPC_64) {
@@ -1967,7 +1967,7 @@
 			break;
 		old_fs = get_fs ();
 		set_fs (KERNEL_DS);
-		err = sys_msgctl (first, second, (struct msqid_ds *)&m);
+		err = sys_msgctl (first, second | IPC_64, (struct msqid_ds *)&m);
 		set_fs (old_fs);
 		break;
 
@@ -1975,7 +1975,7 @@
 	case MSG_STAT:
 		old_fs = get_fs ();
 		set_fs (KERNEL_DS);
-		err = sys_msgctl (first, second, (struct msqid_ds *)&m);
+		err = sys_msgctl (first, second | IPC_64, (struct msqid_ds *)&m);
 		set_fs (old_fs);
 		if (second & IPC_64) {
 			if (!access_ok(VERIFY_WRITE, up64, sizeof(*up64))) {
@@ -2082,7 +2082,7 @@
 			break;
 		old_fs = get_fs ();
 		set_fs (KERNEL_DS);
-		err = sys_shmctl (first, second, &s);
+		err = sys_shmctl (first, second & ~IPC_64, &s);
 		set_fs (old_fs);
 		break;
 
@@ -2090,7 +2090,7 @@
 	case SHM_STAT:
 		old_fs = get_fs ();
 		set_fs (KERNEL_DS);
-		err = sys_shmctl (first, second, (void *) &s64);
+		err = sys_shmctl (first, second | IPC_64, (void *) &s64);
 		set_fs (old_fs);
 		if (err < 0)
 			break;
---
Atsushi Nemoto

From dkesselr@mmc.atmel.com Tue Oct 28 18:12:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 18:12:33 +0000 (GMT)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:3446
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225362AbTJ1SM3>; Tue, 28 Oct 2003 18:12:29 +0000
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id NAA09445
	for <linux-mips@linux-mips.org>; Tue, 28 Oct 2003 13:12:19 -0500 (EST)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id NAA20687
	for <linux-mips@linux-mips.org>; Tue, 28 Oct 2003 13:12:18 -0500 (EST)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Tue, 28 Oct 2003 13:12:18 -0500 (EST)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: Unresolved symbols
Message-ID: <Pine.GSO.4.44.0310281308450.20592-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3537
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

I've been unabled to track down these errors. I think it's because I don't
understand how some of the linux h files are used by an independently
compiled kernel module. Why is "extern __inline__" used in a file like
atomic.h.
If any of you have any pointers on the following errors, I'd appreciate
your comments.
/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol
atomic_sub_return
/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol __udelay
/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol atomic_add
/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol strcpy
/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol atomic_sub

Thanks,

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


From ddaney@avtrex.com Tue Oct 28 18:32:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 18:32:05 +0000 (GMT)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:4310 "EHLO avtrex.com")
	by linux-mips.org with ESMTP id <S8225362AbTJ1ScC>;
	Tue, 28 Oct 2003 18:32:02 +0000
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 28 Oct 2003 10:31:59 -0800
Message-ID: <3F9EB61F.8010906@avtrex.com>
Date: Tue, 28 Oct 2003 10:31:59 -0800
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Kesselring <dkesselr@mmc.atmel.com>
CC: linux-mips@linux-mips.org
Subject: Re: Unresolved symbols
References: <Pine.GSO.4.44.0310281308450.20592-100000@ares.mmc.atmel.com>
In-Reply-To: <Pine.GSO.4.44.0310281308450.20592-100000@ares.mmc.atmel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Oct 2003 18:31:59.0608 (UTC) FILETIME=[C6147F80:01C39D81]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3538
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

David Kesselring wrote:

>I've been unabled to track down these errors. I think it's because I don't
>understand how some of the linux h files are used by an independently
>compiled kernel module. Why is "extern __inline__" used in a file like
>atomic.h.
>If any of you have any pointers on the following errors, I'd appreciate
>your comments.
>/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol
>atomic_sub_return
>/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol __udelay
>/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol atomic_add
>/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol strcpy
>/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol atomic_sub
>  
>
Often if you don't compile with optimization turned on you get things 
like this.  You have to compile with optimization set high enough to get 
inlining enabled.

David Daney.


From jbglaw@dvmwest.gt.owl.de Tue Oct 28 18:53:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 18:53:42 +0000 (GMT)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:21124 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225362AbTJ1Sxi>; Tue, 28 Oct 2003 18:53:38 +0000
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id F14444A807; Tue, 28 Oct 2003 19:53:33 +0100 (CET)
Date: Tue, 28 Oct 2003 19:53:33 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: Unresolved symbols
Message-ID: <20031028185333.GV12395@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <Pine.GSO.4.44.0310281308450.20592-100000@ares.mmc.atmel.com> <3F9EB61F.8010906@avtrex.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="oXXuwmZolLKlWh2N"
Content-Disposition: inline
In-Reply-To: <3F9EB61F.8010906@avtrex.com>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
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: 3539
X-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


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

On Tue, 2003-10-28 10:31:59 -0800, David Daney <ddaney@avtrex.com>
wrote in message <3F9EB61F.8010906@avtrex.com>:
> David Kesselring wrote:
>=20
> >I've been unabled to track down these errors. I think it's because I don=
't
> >understand how some of the linux h files are used by an independently
> >compiled kernel module. Why is "extern __inline__" used in a file like
> >atomic.h.
> >If any of you have any pointers on the following errors, I'd appreciate
> >your comments.
> >/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol
> >atomic_sub_return
> >/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol __udelay
> >/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol atomic_add
> >/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol strcpy
> >/lib/modules/2.4.22/kernel/net/pcifvnet.o: unresolved symbol atomic_sub
> Often if you don't compile with optimization turned on you get things=20
> like this.  You have to compile with optimization set high enough to get=
=20
> inlining enabled.

Right. Once again, if you compile modules outside the kernel, please:

	Use exactly the GCC parameters that are used by in-kernel-tree
			compiled modules!

MfG, JBG

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

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

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

iD8DBQE/nrstHb1edYOZ4bsRAsIbAJ9xtaF1pFfUaWghdnQ//c5LdlK/iQCfZhPY
8ocpYF/Om/tOwEIOvQgKrm0=
=VJaG
-----END PGP SIGNATURE-----

--oXXuwmZolLKlWh2N--

From gilad@riverhead.com Tue Oct 28 20:19:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 20:20:02 +0000 (GMT)
Received: from mail.wanwall.com ([IPv6:::ffff:194.90.64.163]:14099 "EHLO
	mail.riverhead.com") by linux-mips.org with ESMTP
	id <S8225369AbTJ1UTx>; Tue, 28 Oct 2003 20:19:53 +0000
Received: from exchange.riverhead.com (exchange.riverhead.com [10.0.0.10])
	by mail.riverhead.com (8.11.0/8.11.0) with ESMTP id h9SKJs300714
	for <linux-mips@linux-mips.org>; Tue, 28 Oct 2003 22:19:54 +0200
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: mail.riverhead.com
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Subject: BCM1250 Current Descriptor
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C39D90.6357E724"
Date: Tue, 28 Oct 2003 22:16:36 +0200
Message-ID: <328392AA673C0A49B54DABA457E37DAA097E62@exchange>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BCM1250 Current Descriptor
Thread-Index: AcOdkGMjX+RMYiGcSQKYE4MQLpBX/g==
From: "Gilad Benjamini" <gilad@riverhead.com>
To: <linux-mips@linux-mips.org>
Return-Path: <gilad@riverhead.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3540
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gilad@riverhead.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C39D90.6357E724
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQpJIGhhdmUgYSBxdWVzdGlvbiB3aGljaCBpcyBzcGVjaWZpYyBmb3IgdGhlIEJDTTEyNTAu
IEkgaG9wZSB0aGlzDQppcyB0aGUgcmlnaHQgZm9ydW0gdG8gYXNrIHRoaXMsIGlmIG5vdCwgbXkg
YXBvbG9naWVzLg0KIA0KSW4gYW4gUlggRE1BIGNoYW5uZWwgdGhlIEJDTTEyNTAgc2lnbmFscyBh
IHJlY2VpdmVkIHBhY2tldA0KYnkgdHVybmluZyBvbiB0aGUgU09QIGJpdC4gV2hlbiBhIHBhY2tl
dCBhcnJpdmVzLCB0aGUgY3VycmVudF9kZXNjcmlwdG9yDQpyZWdpc3RlciBhbHNvIHVwZGF0ZXMg
dG8gdGhlIG5leHQgcGFja2V0Lg0KQ291bGQgdGhlcmUgYmUgYSAobm9uLXRyaXZpYWwpIHRpbWUg
Z2FwIGJldHdlZW4gdGhlIHVwZGF0ZSBvZiB0aG9zZSA/DQpXZSBzZWUgYSBzY2VuYXJpbyB3aGVy
ZSB0aGUgU09QIGJpdCBpcyBvbiwgYnV0IHRoZSBkZXNjcmlwdG9yIGNvdW50IA0Kc2hvd3MgdGhh
dCB0aGUgcGFja2V0IHN0aWxsIGJlbG9uZ3MgdG8gdGhlIERNQS4gSG93IGNhbiB0aGlzIGJlID8N
CiANClRJQQ0KIA0K

------_=_NextPart_001_01C39D90.6357E724
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj48SFRNTD48SEVBRD48TUVUQSBIVFRQLUVRVUlWPSJDb250ZW50LVR5cGUiIENPTlRFTlQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+PC9IRUFEPjxCT0RZPjxESVY+SGksPC9ESVY+CjxE
SVY+SSBoYXZlIGEgcXVlc3Rpb24gd2hpY2ggaXMgc3BlY2lmaWMgZm9yIHRoZSBCQ00xMjUwLiBJ
IGhvcGUgdGhpczwvRElWPgo8RElWPmlzIHRoZSByaWdodCBmb3J1bSB0byBhc2sgdGhpcywgaWYg
bm90LCBteSBhcG9sb2dpZXMuPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SW4gYW4gUlgg
RE1BIGNoYW5uZWwgdGhlIEJDTTEyNTAgc2lnbmFscyBhIHJlY2VpdmVkIHBhY2tldDwvRElWPgo8
RElWPmJ5IHR1cm5pbmcgb24gdGhlIFNPUCBiaXQuIFdoZW4gYSBwYWNrZXQgYXJyaXZlcywgdGhl
IApjdXJyZW50X2Rlc2NyaXB0b3I8L0RJVj4KPERJVj5yZWdpc3RlciBhbHNvIHVwZGF0ZXMgdG8g
dGhlIG5leHQgcGFja2V0LjwvRElWPgo8RElWPkNvdWxkIHRoZXJlIGJlIGEgKG5vbi10cml2aWFs
KSB0aW1lIGdhcCBiZXR3ZWVuIHRoZSB1cGRhdGUgb2YgdGhvc2UgPzwvRElWPgo8RElWPldlIHNl
ZSBhIHNjZW5hcmlvIHdoZXJlIHRoZSBTT1AgYml0IGlzIG9uLCBidXQgdGhlIGRlc2NyaXB0b3Ig
Y291bnQgPC9ESVY+CjxESVY+c2hvd3MgdGhhdCB0aGUgcGFja2V0IHN0aWxsIGJlbG9uZ3MgdG8g
dGhlIERNQS4gSG93IGNhbiB0aGlzIGJlID88L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5U
SUE8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg==

------_=_NextPart_001_01C39D90.6357E724--

From Geert.Uytterhoeven@sonycom.com Tue Oct 28 20:36:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 20:36:10 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:8607 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225395AbTJ1UgI>;
	Tue, 28 Oct 2003 20:36:08 +0000
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id h9SKa5QG003571;
	Tue, 28 Oct 2003 21:36:05 +0100 (MET)
Date: Tue, 28 Oct 2003 21:36:05 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Unresolved symbols
In-Reply-To: <Pine.GSO.4.44.0310281308450.20592-100000@ares.mmc.atmel.com>
Message-ID: <Pine.GSO.4.21.0310282135290.10351-100000@waterleaf.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: 3541
X-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, 28 Oct 2003, David Kesselring wrote:
> I've been unabled to track down these errors. I think it's because I don't
> understand how some of the linux h files are used by an independently
> compiled kernel module. Why is "extern __inline__" used in a file like
> atomic.h.

`extern inline' is wrong, and should be replaced by `static inline', which is
work-in-progress.

Gr{oetje,eeting}s,

						Geert

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

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


From ralf@linux-mips.org Tue Oct 28 21:18:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 21:18:40 +0000 (GMT)
Received: from p508B5FBF.dip.t-dialin.net ([IPv6:::ffff:80.139.95.191]:45737
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225397AbTJ1VSg>; Tue, 28 Oct 2003 21:18:36 +0000
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 h9SLIWNK014115;
	Tue, 28 Oct 2003 22:18:32 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9SLITBN014114;
	Tue, 28 Oct 2003 22:18:29 +0100
Date: Tue, 28 Oct 2003 22:18:29 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: David Kesselring <dkesselr@mmc.atmel.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Unresolved symbols
Message-ID: <20031028211829.GC7649@linux-mips.org>
References: <Pine.GSO.4.44.0310281308450.20592-100000@ares.mmc.atmel.com> <Pine.GSO.4.21.0310282135290.10351-100000@waterleaf.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0310282135290.10351-100000@waterleaf.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: 3542
X-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, Oct 28, 2003 at 09:36:05PM +0100, Geert Uytterhoeven wrote:
> Date: Tue, 28 Oct 2003 21:36:05 +0100 (MET)
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> To: David Kesselring <dkesselr@mmc.atmel.com>
> cc: Linux/MIPS Development <linux-mips@linux-mips.org>
> Subject: Re: Unresolved symbols
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> On Tue, 28 Oct 2003, David Kesselring wrote:
> > I've been unabled to track down these errors. I think it's because I don't
> > understand how some of the linux h files are used by an independently
> > compiled kernel module. Why is "extern __inline__" used in a file like
> > atomic.h.
> 
> `extern inline' is wrong, and should be replaced by `static inline', which is
> work-in-progress.

I've replaced all extern inline in cvs 2.4 / 2.6.

  Ralf

From ddaney@avtrex.com Tue Oct 28 23:46:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Oct 2003 23:46:46 +0000 (GMT)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:24810 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225447AbTJ1Xqn>;
	Tue, 28 Oct 2003 23:46:43 +0000
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 28 Oct 2003 15:46:40 -0800
Message-ID: <3F9EFFDF.7070205@avtrex.com>
Date: Tue, 28 Oct 2003 15:46:39 -0800
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Help needed WRT GDB and multithreaded programs.
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Oct 2003 23:46:40.0137 (UTC) FILETIME=[BBC09790:01C39DAD]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3543
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

A question about debugging user space programs on a mips/linux system:

I'm fairly sure that this problem has been encountered before and hope 
someone can help me solve it.

I am running linux 2.4.18 on a MIPS 4Kc core with all tools configured 
as mipsel-linux, with glibc-2.2.4 and the corresponding version of pthreads.

When using GDB 5.3 I get strange errors and am basically not able to 
debug multi-threaded programs.  For example any java program compiled 
with GCC/GCJ runs in multiple threads and does something like this:

# gdb PR218
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "mipsel-linux"...
(gdb) b main
Breakpoint 1 at 0x400dec: file /tmp/ccr0H72i.i, line 10.
(gdb) c
The program is not being run.
(gdb) run
Starting program: /junk/PR218
[New Thread 1024 (LWP 103)]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1024 (LWP 103)]
0x00000000 in ?? ()
(gdb)


At this point no further debugging is possible.

If I attach to a particular thread after the program is started I can do 
some debugging, but that is inferior to having it work properly.

Q:  Has anyone else seen this type of behavior from GDB?

Q:  What is the solution?

Thanks in advance
David Daney.


From ddaney@avtrex.com Wed Oct 29 02:04:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Oct 2003 02:04:02 +0000 (GMT)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:8691 "EHLO avtrex.com")
	by linux-mips.org with ESMTP id <S8225456AbTJ2CEA>;
	Wed, 29 Oct 2003 02:04:00 +0000
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 28 Oct 2003 18:03:53 -0800
Message-ID: <3F9F2009.9060508@avtrex.com>
Date: Tue, 28 Oct 2003 18:03:53 -0800
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Daney <ddaney@avtrex.com>
CC: linux-mips@linux-mips.org
Subject: Re: Help needed WRT GDB and multithreaded programs.
References: <3F9EFFDF.7070205@avtrex.com>
In-Reply-To: <3F9EFFDF.7070205@avtrex.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Oct 2003 02:03:53.0298 (UTC) FILETIME=[E7194320:01C39DC0]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3544
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

David Daney wrote:

>
> When using GDB 5.3 I get strange errors and am basically not able to 
> debug multi-threaded programs.  For example any java program compiled 
> with GCC/GCJ runs in multiple threads and does something like this:

I just tried it with GDB 6.0 with the same results.

Still looking for answers...

David Daney.


From anemo@mba.ocn.ne.jp Wed Oct 29 02:35:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Oct 2003 02:35:32 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:27410
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225461AbTJ2CfA>; Wed, 29 Oct 2003 02:35:00 +0000
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 29 Oct 2003 02:35:19 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h9T2Z99X042280;
	Wed, 29 Oct 2003 11:35:09 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Wed, 29 Oct 2003 11:37:46 +0900 (JST)
Message-Id: <20031029.113746.108765170.nemoto@toshiba-tops.co.jp>
To: ddaney@avtrex.com
Cc: linux-mips@linux-mips.org
Subject: Re: Help needed WRT GDB and multithreaded programs.
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <3F9EFFDF.7070205@avtrex.com>
References: <3F9EFFDF.7070205@avtrex.com>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 3545
X-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, 28 Oct 2003 15:46:39 -0800, David Daney <ddaney@avtrex.com> said:
ddaney> When using GDB 5.3 I get strange errors and am basically not
ddaney> able to debug multi-threaded programs.  For example any java
ddaney> program compiled with GCC/GCJ runs in multiple threads and
ddaney> does something like this:

Maybe these will help you:

http://www.linux-mips.org/archives/linux-mips/2002-09/msg00127.html
http://lists.debian.org/debian-mips/2003/debian-mips-200303/msg00116.html

---
Atsushi Nemoto

From ddaney@avtrex.com Wed Oct 29 02:56:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Oct 2003 02:56:20 +0000 (GMT)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:11510 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225461AbTJ2C4R>;
	Wed, 29 Oct 2003 02:56:17 +0000
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 28 Oct 2003 18:56:14 -0800
Message-ID: <3F9F2C4E.70302@avtrex.com>
Date: Tue, 28 Oct 2003 18:56:14 -0800
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
CC: linux-mips@linux-mips.org, gdb@sources.redhat.com
Subject: Re: Help needed WRT GDB and multithreaded programs.
References: <3F9EFFDF.7070205@avtrex.com> <20031029.113746.108765170.nemoto@toshiba-tops.co.jp>
In-Reply-To: <20031029.113746.108765170.nemoto@toshiba-tops.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Oct 2003 02:56:14.0202 (UTC) FILETIME=[37392DA0:01C39DC8]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3546
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

Atsushi Nemoto wrote:

>>>>>>On Tue, 28 Oct 2003 15:46:39 -0800, David Daney <ddaney@avtrex.com> said:
>>>>>>            
>>>>>>
>ddaney> When using GDB 5.3 I get strange errors and am basically not
>ddaney> able to debug multi-threaded programs.  For example any java
>ddaney> program compiled with GCC/GCJ runs in multiple threads and
>ddaney> does something like this:
>
>Maybe these will help you:
>
>http://www.linux-mips.org/archives/linux-mips/2002-09/msg00127.html
>http://lists.debian.org/debian-mips/2003/debian-mips-200303/msg00116.html
>
>---
>Atsushi Nemoto
>  
>
Hey, thanks a lot!

That was the problem.

David Daney.


From anemo@mba.ocn.ne.jp Wed Oct 29 07:29:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Oct 2003 07:29:46 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:22308
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225374AbTJ2H3O>; Wed, 29 Oct 2003 07:29:14 +0000
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 29 Oct 2003 07:29:33 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h9T7TO9X042791;
	Wed, 29 Oct 2003 16:29:25 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Wed, 29 Oct 2003 16:32:01 +0900 (JST)
Message-Id: <20031029.163201.39178653.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Huge dynamically linked program does not run on mips-linux
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20031022.171118.88468465.nemoto@toshiba-tops.co.jp>
References: <20031022.171118.88468465.nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 3547
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Wed, 22 Oct 2003 17:11:18 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> I have a problem that my huge dynamically linked program cause
anemo> SIGSEGV or SIGBUS immediately after running from main() on
anemo> mips-linux.

anemo> Digging into this problem, I found that GOT entries are
anemo> corrupted.
...
anemo> My program is huge enough so that older binutils causes
anemo> "relocation truncated to fit" error.

More information.  My program's .got size exceeds 64K.  It seems the
corruption does not happen if .got size is smaller then 64K.

$ mips-linux-readelf -e myapp
...
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
...
  [21] .got              PROGBITS        100b15d0 a075d0 013a04 04 WAp  0   0 16

---
Atsushi Nemoto

From yuasa@hh.iij4u.or.jp Wed Oct 29 15:48:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Oct 2003 15:48:52 +0000 (GMT)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:48854 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225364AbTJ2PsQ>;
	Wed, 29 Oct 2003 15:48:16 +0000
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA01366;
	Thu, 30 Oct 2003 00:48:10 +0900 (JST)
Received: 4UMDO00 id h9TFmA824254; Thu, 30 Oct 2003 00:48:10 +0900 (JST)
Received: 4UMRO00 id h9TFm8r05641; Thu, 30 Oct 2003 00:48:09 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Thu, 30 Oct 2003 00:48:07 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: [patch] VR4133
Message-Id: <20031030004807.05974e01.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20031016010533.5a772fef.yuasa@hh.iij4u.or.jp>
References: <20031008003402.23a326cb.yuasa@hh.iij4u.or.jp>
	<20031012151517.GA20647@linux-mips.org>
	<20031013020207.5887e42e.yuasa@hh.iij4u.or.jp>
	<20031016010533.5a772fef.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart=_Thu__30_Oct_2003_00_48_07_+0900_L.Yj.nakU46kW7Bd"
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: 3548
X-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=_Thu__30_Oct_2003_00_48_07_+0900_L.Yj.nakU46kW7Bd
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I updated these patches for latest CVS tree.
These patches add support of NEC VR4133 CPU.

Please apply these patches.

Yoichi

On Thu, 16 Oct 2003 01:05:33 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hello Ralf,
> 
> I updated the patch about part of GIU for VR4133.
> Please apply them to CVS tree.
> 
> Yoichi
> 
> On Mon, 13 Oct 2003 02:02:07 +0900
> Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:
> 
> > Hello Ralf,
> > 
> > On Sun, 12 Oct 2003 17:15:17 +0200
> > Ralf Baechle <ralf@linux-mips.org> wrote:
> > 
> > > On Wed, Oct 08, 2003 at 12:34:02AM +0900, Yoichi Yuasa wrote:
> > > 
> > > > I made patches for NEC VR4133.
> > > > These patches add support of new CPU of NEC.
> > > > 
> > > > Please apply this patch to CVS tree.
> > > 
> > > Please keep the 32-bit and 64-bit files in sync - even if you're not
> > > using both.  Having them diverse is a huge pain.
> > 
> > OK, I updated these patches.
> > 
> > Please apply them to CVS.
> > 
> > Yoichi
> > 
> > 
> 

--Multipart=_Thu__30_Oct_2003_00_48_07_+0900_L.Yj.nakU46kW7Bd
Content-Type: text/plain;
 name="vr4133-v24-031030.diff"
Content-Disposition: attachment;
 filename="vr4133-v24-031030.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux.orig/arch/mips/kernel/cpu-probe.c	2003-10-13 20:53:15.000000000 +0900
+++ linux/arch/mips/kernel/cpu-probe.c	2003-10-23 16:49:07.000000000 +0900
@@ -220,8 +220,11 @@
 			else
 				c->cputype = CPU_VR4181A;
 			break;
-		case PRID_REV_VR4131:
-			c->cputype = CPU_VR4131;
+		case PRID_REV_VR4130:
+			if ((c->processor_id & 0xf) < 0x4)
+				c->cputype = CPU_VR4131;
+			else
+				c->cputype = CPU_VR4133;
 			break;
 		default:
 			printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/proc.c linux/arch/mips/kernel/proc.c
--- linux.orig/arch/mips/kernel/proc.c	2003-10-13 20:53:15.000000000 +0900
+++ linux/arch/mips/kernel/proc.c	2003-10-23 16:46:59.000000000 +0900
@@ -68,6 +68,7 @@
 	[CPU_VR4121]	"NEC VR4121",
 	[CPU_VR4122]	"NEC VR4122",
 	[CPU_VR4131]	"NEC VR4131",
+	[CPU_VR4133]	"NEC VR4133",
 	[CPU_VR4181]	"NEC VR4181",
 	[CPU_VR4181A]	"NEC VR4181A",
 	[CPU_SR71000]	"Sandcraft SR71000"
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux.orig/arch/mips/mm/c-r4k.c	2003-10-13 20:53:15.000000000 +0900
+++ linux/arch/mips/mm/c-r4k.c	2003-10-23 16:46:59.000000000 +0900
@@ -833,6 +833,8 @@
 		c->dcache.waybit = 0;
 		break;
 
+	case CPU_VR4133:
+		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux.orig/arch/mips/vr41xx/casio-e55/setup.c	2003-07-30 09:35:37.000000000 +0900
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	2003-10-23 16:46:59.000000000 +0900
@@ -59,7 +59,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux.orig/arch/mips/vr41xx/common/bcu.c	2003-08-26 01:14:53.000000000 +0900
+++ linux/arch/mips/vr41xx/common/bcu.c	2003-10-23 16:46:59.000000000 +0900
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - Calculate mips_hpt_frequency properly on VR4131.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -52,8 +53,8 @@
 
 #define VR4111_CLKSPEEDREG	KSEG1ADDR(0x0b000014)
 #define VR4122_CLKSPEEDREG	KSEG1ADDR(0x0f000014)
-#define VR4131_CLKSPEEDREG	VR4122_CLKSPEEDREG
  #define CLKSP(x)		((x) & 0x001f)
+ #define CLKSP_VR4133(x)	((x) & 0x0007)
 
  #define DIV2B			0x8000
  #define DIV3B			0x4000
@@ -72,8 +73,9 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121: return readw(VR4111_CLKSPEEDREG);
-	case CPU_VR4122: return readw(VR4122_CLKSPEEDREG);
-	case CPU_VR4131: return readw(VR4131_CLKSPEEDREG);
+	case CPU_VR4122:
+	case CPU_VR4131:
+	case CPU_VR4133: return readw(VR4122_CLKSPEEDREG);
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
@@ -90,19 +92,43 @@
 	case CPU_VR4111:
 	case CPU_VR4121:
 		pclock = 18432000 * 64;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4122:
 		pclock = 18432000 * 98;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4131:
 		pclock = 18432000 * 108;
+		pclock /= CLKSP(clkspeed);
+		break;
+	case CPU_VR4133:
+		switch (CLKSP_VR4133(clkspeed)) {
+		case 0:
+			pclock = 133000000;
+			break;
+		case 1:
+			pclock = 149000000;
+			break;
+		case 2:
+			pclock = 165900000;
+			break;
+		case 3:
+			pclock = 199100000;
+			break;
+		case 4:
+			pclock = 265900000;
+			break;
+		default:
+			printk(KERN_INFO "Unknown PClock speed for NEC VR4133\n");
+			break;
+		}
 		break;
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
 	}
 
-	pclock /= CLKSP(clkspeed);
 	printk(KERN_INFO "PClock: %ldHz\n", pclock);
 
 	return pclock;
@@ -135,6 +161,7 @@
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_vtclock = pclock / VTDIVMODE(clkspeed);
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
@@ -165,6 +192,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		tclock = vtclock / TDIVMODE(clkspeed);
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux.orig/arch/mips/vr41xx/common/cmu.c	2003-04-07 09:17:06.000000000 +0900
+++ linux/arch/mips/vr41xx/common/cmu.c	2003-10-23 16:46:59.000000000 +0900
@@ -33,38 +33,174 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
 #include <asm/io.h>
+#include <asm/vr41xx/vr41xx.h>
 
 #define VR4111_CMUCLKMSK	KSEG1ADDR(0x0b000060)
 #define VR4122_CMUCLKMSK	KSEG1ADDR(0x0f000060)
+ #define MSKPIU			0x0001
+ #define MSKSIU			0x0002
+ #define MSKAIU			0x0004
+ #define MSKKIU			0x0008
+ #define MSKFIR			0x0010
+ #define MSKDSIU		0x0820
+ #define MSKCSI			0x0040
+ #define MSKPCIU		0x0080
+ #define MSKSSIU		0x0100
+ #define MSKSHSP		0x0200
+ #define MSKFFIR		0x0400
+ #define MSKSCSI		0x1000
+ #define MSKPPCIU		0x2000
+#define VR4133_CMUCLKMSK2	KSEG1ADDR(0x0f000064)
+ #define MSKCEU			0x0001
+ #define MSKMAC0		0x0002
+ #define MSKMAC1		0x0004
 
 static u32 vr41xx_cmu_base;
-static u16 cmuclkmsk;
+static u16 cmuclkmsk, cmuclkmsk2;
 
-#define write_cmu(mask)	writew((mask), vr41xx_cmu_base)
+#define read_cmuclkmsk()	readw(vr41xx_cmu_base)
+#define read_cmuclkmsk2()	readw(VR4133_CMUCLKMSK2)
+#define write_cmuclkmsk()	writew(cmuclkmsk, vr41xx_cmu_base)
+#define write_cmuclkmsk2()	writew(cmuclkmsk2, VR4133_CMUCLKMSK2)
 
-void vr41xx_clock_supply(u16 mask)
+void vr41xx_clock_supply(unsigned int clock)
 {
-	cmuclkmsk |= mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk |= MSKPIU;
+		break;
+	case SIU_CLOCK:
+		cmuclkmsk |= MSKSIU | MSKSSIU;
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk |= MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk |= MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk |= MSKFIR | MSKFFIR;
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121)
+			cmuclkmsk |= MSKDSIU;
+		else
+			cmuclkmsk |= MSKSIU | MSKDSIU;
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk |= MSKCSI | MSKSCSI;
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk |= MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk |= MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk |= MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 |= MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 |= MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 |= MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void vr41xx_clock_mask(u16 mask)
+void vr41xx_clock_mask(unsigned int clock)
 {
-	cmuclkmsk &= ~mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk &= ~MSKPIU;
+		break;
+	case SIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		} else {
+			if (cmuclkmsk & MSKDSIU)
+				cmuclkmsk &= ~MSKSSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		}
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk &= ~MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk &= ~MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk &= ~(MSKFIR | MSKFFIR);
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~MSKDSIU;
+		} else {
+			if (cmuclkmsk & MSKSIU)
+				cmuclkmsk &= ~MSKDSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKDSIU);
+		}
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk &= ~(MSKCSI | MSKSCSI);
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk &= ~MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk &= ~MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk &= ~MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 &= ~MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void __init vr41xx_cmu_init(u16 mask)
+void __init vr41xx_cmu_init(void)
 {
 	switch (current_cpu_data.cputype) {
         case CPU_VR4111:
@@ -75,10 +211,14 @@
         case CPU_VR4131:
                 vr41xx_cmu_base = VR4122_CMUCLKMSK;
                 break;
+        case CPU_VR4133:
+                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+		cmuclkmsk2 = read_cmuclkmsk2();
+                break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
 		break;
         }
 
-	cmuclkmsk = mask;
+	cmuclkmsk = read_cmuclkmsk();
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux.orig/arch/mips/vr41xx/common/giu.c	2003-04-16 21:59:34.000000000 +0900
+++ linux/arch/mips/vr41xx/common/giu.c	2003-10-23 16:46:59.000000000 +0900
@@ -34,6 +34,9 @@
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
  *  - New creation, NEC VR4111, VR4121, VR4122 and VR4131 are supported.
+ *
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -246,6 +249,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_giu_base = VR4122_GIUIOSELL;
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux.orig/arch/mips/vr41xx/common/icu.c	2003-04-16 21:59:34.000000000 +0900
+++ linux/arch/mips/vr41xx/common/icu.c	2003-10-23 16:46:59.000000000 +0900
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - kgdb support.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -290,6 +291,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_icu1_base = VR4122_SYSINT1REG;
 		vr41xx_icu2_base = VR4122_SYSINT2REG;
 		break;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/pciu.c linux/arch/mips/vr41xx/common/pciu.c
--- linux.orig/arch/mips/vr41xx/common/pciu.c	2003-04-07 09:17:06.000000000 +0900
+++ linux/arch/mips/vr41xx/common/pciu.c	2003-10-23 16:46:59.000000000 +0900
@@ -74,7 +74,7 @@
 		/*
 		 * Type 1 configuration
 		 */
-		if (bus > 255 || PCI_SLOT(dev_fn) > 31 || where > 255)
+		if (PCI_SLOT(dev_fn) > 31 || where > 255)
 			return -1;
 
 		writel((bus << 16)	|
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/pciu.h linux/arch/mips/vr41xx/common/pciu.h
--- linux.orig/arch/mips/vr41xx/common/pciu.h	2002-07-15 09:02:56.000000000 +0900
+++ linux/arch/mips/vr41xx/common/pciu.h	2003-10-23 16:46:59.000000000 +0900
@@ -107,9 +107,6 @@
 
 #define MAX_PCI_CLOCK			33333333
 
-#define PCIU_CLOCK			0x0080
-#define PCI_CLOCK			0x2000
-
 static inline int pciu_read_config_byte(int where, u8 *val)
 {
 	u32 data;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux.orig/arch/mips/vr41xx/common/serial.c	2003-04-07 09:17:06.000000000 +0900
+++ linux/arch/mips/vr41xx/common/serial.c	2003-10-23 16:46:59.000000000 +0900
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -66,7 +67,6 @@
  #define TMICMODE		0x20
 
 #define SIU_BASE_BAUD		1152000
-#define SIU_CLOCK		0x0102
 
 /* VR4122 and VR4131 DSIU Registers */
 #define DSIURB			KSEG1ADDR(0x0f000820)
@@ -75,7 +75,6 @@
  #define INTDSIU		0x0800
 
 #define DSIU_BASE_BAUD		1152000
-#define DSIU_CLOCK		0x0802
 
 int vr41xx_serial_ports = 0;
 
@@ -106,6 +105,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		writew(val, VR4122_SIUIRSEL);
 		break;
 	default:
@@ -133,6 +133,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		s.iomem_base = (unsigned char *)VR4122_SIURB;
 		break;
 	default:
@@ -154,7 +155,8 @@
 	struct serial_struct s;
 
 	if (current_cpu_data.cputype != CPU_VR4122 &&
-	    current_cpu_data.cputype != CPU_VR4131)
+	    current_cpu_data.cputype != CPU_VR4131 &&
+	    current_cpu_data.cputype != CPU_VR4133)
 		return;
 
 	memset(&s, 0, sizeof(s));
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/time.c linux/arch/mips/vr41xx/common/time.c
--- linux.orig/arch/mips/vr41xx/common/time.c	2003-08-26 01:14:53.000000000 +0900
+++ linux/arch/mips/vr41xx/common/time.c	2003-10-23 16:46:59.000000000 +0900
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4100 series are supported.
  *  - Added support for NEC VR4100 series RTC Unit.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4100 series are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/config.h>
 #include <linux/interrupt.h>
@@ -69,6 +70,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
                 vr41xx_rtc_base = VR4122_ETIMELREG;
                 break;
         default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c	2003-07-30 09:35:38.000000000 +0900
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	2003-10-23 16:47:00.000000000 +0900
@@ -59,7 +59,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/setup.c	2003-07-30 09:35:38.000000000 +0900
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	2003-10-23 16:47:00.000000000 +0900
@@ -140,7 +140,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	2003-07-30 09:35:38.000000000 +0900
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	2003-10-23 16:47:00.000000000 +0900
@@ -102,7 +102,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
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	2003-05-22 06:36:53.000000000 +0900
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	2003-10-23 16:47:00.000000000 +0900
@@ -114,7 +114,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c	2003-07-30 09:35:38.000000000 +0900
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	2003-10-23 16:47:00.000000000 +0900
@@ -107,7 +107,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/setup.c	2003-07-30 09:35:38.000000000 +0900
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	2003-10-23 16:47:00.000000000 +0900
@@ -107,7 +107,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0x0102);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/cpu.h linux/include/asm-mips/cpu.h
--- linux.orig/include/asm-mips/cpu.h	2003-10-13 20:53:16.000000000 +0900
+++ linux/include/asm-mips/cpu.h	2003-10-23 16:47:37.000000000 +0900
@@ -100,7 +100,7 @@
 #define PRID_REV_VR4121		0x0060
 #define PRID_REV_VR4122		0x0070
 #define PRID_REV_VR4181A	0x0070	/* Same as VR4122 */
-#define PRID_REV_VR4131		0x0080
+#define PRID_REV_VR4130		0x0080
 
 /*
  * FPU implementation/revision register (CP1 control register 0).
@@ -168,7 +168,8 @@
 #define CPU_AU1100		52
 #define CPU_SR71000		53
 #define CPU_RM9000		54
-#define CPU_LAST		54
+#define CPU_VR4133		55
+#define CPU_LAST		55
 
 /*
  * ISA Level encodings
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	2003-07-30 09:35:38.000000000 +0900
+++ linux/include/asm-mips/vr41xx/vr41xx.h	2003-10-23 16:47:00.000000000 +0900
@@ -32,12 +32,15 @@
 #define PRID_VR4181A_REV1_0	0x00000c73
 #define PRID_VR4181A_REV1_1	0x00000c74
 
-/* VR4131 0x00000c80-0x00000c8f */
+/* VR4131 0x00000c80-0x00000c83 */
 #define PRID_VR4131_REV1_2	0x00000c80
 #define PRID_VR4131_REV2_0	0x00000c81
 #define PRID_VR4131_REV2_1	0x00000c82
 #define PRID_VR4131_REV2_2	0x00000c83
 
+/* VR4133 0x00000c84- */
+#define PRID_VR4133		0x00000c84
+
 /*
  * Bus Control Uint
  */
@@ -46,9 +49,25 @@
 /*
  * Clock Mask Unit
  */
-extern void vr41xx_cmu_init(u16 mask);
-extern void vr41xx_clock_supply(u16 mask);
-extern void vr41xx_clock_mask(u16 mask);
+extern void vr41xx_cmu_init(void);
+extern void vr41xx_clock_supply(unsigned int clock);
+extern void vr41xx_clock_mask(unsigned int clock);
+
+enum {
+	PIU_CLOCK,
+	SIU_CLOCK,
+	AIU_CLOCK,
+	KIU_CLOCK,
+	FIR_CLOCK,
+	DSIU_CLOCK,
+	CSI_CLOCK,
+	PCIU_CLOCK,
+	HSP_CLOCK,
+	PCI_CLOCK,
+	CEU_CLOCK,
+	ETHER0_CLOCK,
+	ETHER1_CLOCK
+};
 
 /*
  * Interrupt Control Unit

--Multipart=_Thu__30_Oct_2003_00_48_07_+0900_L.Yj.nakU46kW7Bd
Content-Type: text/plain;
 name="vr4133-v26-031030.diff"
Content-Disposition: attachment;
 filename="vr4133-v26-031030.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux.orig/arch/mips/kernel/cpu-probe.c	Tue Oct 14 12:00:55 2003
+++ linux/arch/mips/kernel/cpu-probe.c	Thu Oct 30 00:14:32 2003
@@ -222,9 +222,11 @@
 			else
 				c->cputype = CPU_VR4181A;
 			break;
-		case PRID_REV_VR4131:
-			c->cputype = CPU_VR4131;
-			break;
+		case PRID_REV_VR4130:
+			if ((c->processor_id & 0xf) < 0x4)
+				c->cputype = CPU_VR4131;
+			else
+				c->cputype = CPU_VR4133;
 		default:
 			printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 				c->cputype = CPU_VR41XX;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/proc.c linux/arch/mips/kernel/proc.c
--- linux.orig/arch/mips/kernel/proc.c	Tue Oct 14 12:00:55 2003
+++ linux/arch/mips/kernel/proc.c	Thu Oct 30 00:11:20 2003
@@ -69,6 +69,7 @@
 	[CPU_VR4121]	"NEC VR4121",
 	[CPU_VR4122]	"NEC VR4122",
 	[CPU_VR4131]	"NEC VR4131",
+	[CPU_VR4133]	"NEC VR4133",
 	[CPU_VR4181]	"NEC VR4181",
 	[CPU_VR4181A]	"NEC VR4181A",
 	[CPU_SR71000]	"Sandcraft SR71000"
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux.orig/arch/mips/mm/c-r4k.c	Tue Oct 14 12:00:56 2003
+++ linux/arch/mips/mm/c-r4k.c	Thu Oct 30 00:11:20 2003
@@ -831,6 +831,8 @@
 		c->dcache.waybit = 0;
 		break;
 
+	case CPU_VR4133:
+		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/pci/pci-vr41xx.h linux/arch/mips/pci/pci-vr41xx.h
--- linux.orig/arch/mips/pci/pci-vr41xx.h	Fri Jun 13 23:19:56 2003
+++ linux/arch/mips/pci/pci-vr41xx.h	Thu Oct 30 00:11:20 2003
@@ -107,9 +107,6 @@
 
 #define MAX_PCI_CLOCK			33333333
 
-#define PCIU_CLOCK			0x0080
-#define PCI_CLOCK			0x2000
-
 static inline int pciu_read_config_byte(int where, u8 * val)
 {
 	u32 data;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux.orig/arch/mips/vr41xx/casio-e55/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Thu Oct 30 00:11:21 2003
@@ -62,7 +62,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux.orig/arch/mips/vr41xx/common/bcu.c	Sat Aug 30 01:35:41 2003
+++ linux/arch/mips/vr41xx/common/bcu.c	Thu Oct 30 00:11:21 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - Calculate mips_hpt_frequency properly on VR4131.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -52,8 +53,8 @@
 
 #define VR4111_CLKSPEEDREG	KSEG1ADDR(0x0b000014)
 #define VR4122_CLKSPEEDREG	KSEG1ADDR(0x0f000014)
-#define VR4131_CLKSPEEDREG	VR4122_CLKSPEEDREG
  #define CLKSP(x)		((x) & 0x001f)
+ #define CLKSP_VR4133(x)	((x) & 0x0007)
 
  #define DIV2B			0x8000
  #define DIV3B			0x4000
@@ -72,8 +73,9 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121: return readw(VR4111_CLKSPEEDREG);
-	case CPU_VR4122: return readw(VR4122_CLKSPEEDREG);
-	case CPU_VR4131: return readw(VR4131_CLKSPEEDREG);
+	case CPU_VR4122:
+	case CPU_VR4131:
+	case CPU_VR4133: return readw(VR4122_CLKSPEEDREG);
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
@@ -90,19 +92,43 @@
 	case CPU_VR4111:
 	case CPU_VR4121:
 		pclock = 18432000 * 64;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4122:
 		pclock = 18432000 * 98;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4131:
 		pclock = 18432000 * 108;
+		pclock /= CLKSP(clkspeed);
+		break;
+	case CPU_VR4133:
+		switch (CLKSP_VR4133(clkspeed)) {
+		case 0:
+			pclock = 133000000;
+			break;
+		case 1:
+			pclock = 149000000;
+			break;
+		case 2:
+			pclock = 165900000;
+			break;
+		case 3:
+			pclock = 199100000;
+			break;
+		case 4:
+			pclock = 265900000;
+			break;
+		default:
+			printk(KERN_INFO "Unknown PClock speed for NEC VR4133\n");
+			break;
+		}
 		break;
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
 	}
 
-	pclock /= CLKSP(clkspeed);
 	printk(KERN_INFO "PClock: %ldHz\n", pclock);
 
 	return pclock;
@@ -135,6 +161,7 @@
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_vtclock = pclock / VTDIVMODE(clkspeed);
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
@@ -165,6 +192,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		tclock = vtclock / TDIVMODE(clkspeed);
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux.orig/arch/mips/vr41xx/common/cmu.c	Fri Apr 11 00:17:57 2003
+++ linux/arch/mips/vr41xx/common/cmu.c	Thu Oct 30 00:11:21 2003
@@ -33,38 +33,174 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
 #include <asm/io.h>
+#include <asm/vr41xx/vr41xx.h>
 
 #define VR4111_CMUCLKMSK	KSEG1ADDR(0x0b000060)
 #define VR4122_CMUCLKMSK	KSEG1ADDR(0x0f000060)
+ #define MSKPIU			0x0001
+ #define MSKSIU			0x0002
+ #define MSKAIU			0x0004
+ #define MSKKIU			0x0008
+ #define MSKFIR			0x0010
+ #define MSKDSIU		0x0820
+ #define MSKCSI			0x0040
+ #define MSKPCIU		0x0080
+ #define MSKSSIU		0x0100
+ #define MSKSHSP		0x0200
+ #define MSKFFIR		0x0400
+ #define MSKSCSI		0x1000
+ #define MSKPPCIU		0x2000
+#define VR4133_CMUCLKMSK2	KSEG1ADDR(0x0f000064)
+ #define MSKCEU			0x0001
+ #define MSKMAC0		0x0002
+ #define MSKMAC1		0x0004
+
+static u32 vr41xx_cmu_base;
+static u16 cmuclkmsk, cmuclkmsk2;
+
+#define read_cmuclkmsk()	readw(vr41xx_cmu_base)
+#define read_cmuclkmsk2()	readw(VR4133_CMUCLKMSK2)
+#define write_cmuclkmsk()	writew(cmuclkmsk, vr41xx_cmu_base)
+#define write_cmuclkmsk2()	writew(cmuclkmsk2, VR4133_CMUCLKMSK2)
 
-static u32 vr41xx_cmu_base = 0;
-static u16 cmuclkmsk = 0;
-
-#define write_cmu(mask)	writew((mask), vr41xx_cmu_base)
-
-void vr41xx_clock_supply(u16 mask)
+void vr41xx_clock_supply(unsigned int clock)
 {
-	cmuclkmsk |= mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk |= MSKPIU;
+		break;
+	case SIU_CLOCK:
+		cmuclkmsk |= MSKSIU | MSKSSIU;
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk |= MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk |= MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk |= MSKFIR | MSKFFIR;
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121)
+			cmuclkmsk |= MSKDSIU;
+		else
+			cmuclkmsk |= MSKSIU | MSKDSIU;
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk |= MSKCSI | MSKSCSI;
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk |= MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk |= MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk |= MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 |= MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 |= MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 |= MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void vr41xx_clock_mask(u16 mask)
+void vr41xx_clock_mask(unsigned int clock)
 {
-	cmuclkmsk &= ~mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk &= ~MSKPIU;
+		break;
+	case SIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		} else {
+			if (cmuclkmsk & MSKDSIU)
+				cmuclkmsk &= ~MSKSSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		}
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk &= ~MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk &= ~MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk &= ~(MSKFIR | MSKFFIR);
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~MSKDSIU;
+		} else {
+			if (cmuclkmsk & MSKSIU)
+				cmuclkmsk &= ~MSKDSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKDSIU);
+		}
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk &= ~(MSKCSI | MSKSCSI);
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk &= ~MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk &= ~MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk &= ~MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 &= ~MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void __init vr41xx_cmu_init(u16 mask)
+void __init vr41xx_cmu_init(void)
 {
 	switch (current_cpu_data.cputype) {
         case CPU_VR4111:
@@ -75,10 +211,14 @@
         case CPU_VR4131:
                 vr41xx_cmu_base = VR4122_CMUCLKMSK;
                 break;
+        case CPU_VR4133:
+                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+		cmuclkmsk2 = read_cmuclkmsk2();
+                break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
 		break;
         }
 
-	cmuclkmsk = mask;
+	cmuclkmsk = read_cmuclkmsk();
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux.orig/arch/mips/vr41xx/common/giu.c	Sat Apr 19 16:38:35 2003
+++ linux/arch/mips/vr41xx/common/giu.c	Thu Oct 30 00:11:21 2003
@@ -34,6 +34,9 @@
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
  *  - New creation, NEC VR4111, VR4121, VR4122 and VR4131 are supported.
+ *
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -246,6 +249,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_giu_base = VR4122_GIUIOSELL;
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux.orig/arch/mips/vr41xx/common/icu.c	Sat Apr 19 16:38:35 2003
+++ linux/arch/mips/vr41xx/common/icu.c	Thu Oct 30 00:11:21 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - kgdb support.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -290,6 +291,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_icu1_base = VR4122_SYSINT1REG;
 		vr41xx_icu2_base = VR4122_SYSINT2REG;
 		break;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux.orig/arch/mips/vr41xx/common/serial.c	Fri Apr 11 00:18:03 2003
+++ linux/arch/mips/vr41xx/common/serial.c	Thu Oct 30 00:11:21 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -66,7 +67,6 @@
  #define TMICMODE		0x20
 
 #define SIU_BASE_BAUD		1152000
-#define SIU_CLOCK		0x0102
 
 /* VR4122 and VR4131 DSIU Registers */
 #define DSIURB			KSEG1ADDR(0x0f000820)
@@ -75,7 +75,6 @@
  #define INTDSIU		0x0800
 
 #define DSIU_BASE_BAUD		1152000
-#define DSIU_CLOCK		0x0802
 
 int vr41xx_serial_ports = 0;
 
@@ -106,6 +105,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		writew(val, VR4122_SIUIRSEL);
 		break;
 	default:
@@ -133,6 +133,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		s.iomem_base = (unsigned char *)VR4122_SIURB;
 		break;
 	default:
@@ -154,7 +155,8 @@
 	struct serial_struct s;
 
 	if (current_cpu_data.cputype != CPU_VR4122 &&
-	    current_cpu_data.cputype != CPU_VR4131)
+	    current_cpu_data.cputype != CPU_VR4131 &&
+	    current_cpu_data.cputype != CPU_VR4133)
 		return;
 
 	memset(&s, 0, sizeof(s));
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/time.c linux/arch/mips/vr41xx/common/time.c
--- linux.orig/arch/mips/vr41xx/common/time.c	Sat Aug 30 01:35:41 2003
+++ linux/arch/mips/vr41xx/common/time.c	Thu Oct 30 00:11:21 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4100 series are supported.
  *  - Added support for NEC VR4100 series RTC Unit.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4100 series are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/config.h>
 #include <linux/interrupt.h>
@@ -69,6 +70,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
                 vr41xx_rtc_base = VR4122_ETIMELREG;
                 break;
         default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Thu Oct 30 00:11:21 2003
@@ -62,7 +62,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/setup.c	Sun Oct 26 11:26:40 2003
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Thu Oct 30 00:11:21 2003
@@ -135,7 +135,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Sun Oct 26 11:26:40 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	Thu Oct 30 00:11:21 2003
@@ -103,7 +103,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
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	Sun Oct 26 11:26:40 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Thu Oct 30 00:11:21 2003
@@ -108,7 +108,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Sun Oct 26 11:26:40 2003
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Thu Oct 30 00:11:21 2003
@@ -111,7 +111,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/setup.c	Sun Oct 26 11:26:40 2003
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Thu Oct 30 00:11:21 2003
@@ -111,7 +111,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0x0102);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/cpu.h linux/include/asm-mips/cpu.h
--- linux.orig/include/asm-mips/cpu.h	Tue Oct 14 12:01:08 2003
+++ linux/include/asm-mips/cpu.h	Thu Oct 30 00:12:34 2003
@@ -101,7 +101,7 @@
 #define PRID_REV_VR4121		0x0060
 #define PRID_REV_VR4122		0x0070
 #define PRID_REV_VR4181A	0x0070	/* Same as VR4122 */
-#define PRID_REV_VR4131		0x0080
+#define PRID_REV_VR4130		0x0080
 
 /*
  * FPU implementation/revision register (CP1 control register 0).
@@ -170,7 +170,8 @@
 #define CPU_SR71000		53
 #define CPU_RM9000		54
 #define CPU_25KF		55
-#define CPU_LAST		55
+#define CPU_VR4133		56
+#define CPU_LAST		56
 
 /*
  * ISA Level encodings
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	Wed Jul 30 22:36:56 2003
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Thu Oct 30 00:11:21 2003
@@ -32,12 +32,15 @@
 #define PRID_VR4181A_REV1_0	0x00000c73
 #define PRID_VR4181A_REV1_1	0x00000c74
 
-/* VR4131 0x00000c80-0x00000c8f */
+/* VR4131 0x00000c80-0x00000c83 */
 #define PRID_VR4131_REV1_2	0x00000c80
 #define PRID_VR4131_REV2_0	0x00000c81
 #define PRID_VR4131_REV2_1	0x00000c82
 #define PRID_VR4131_REV2_2	0x00000c83
 
+/* VR4131 0x00000c84- */
+#define PRID_VR4133		0x00000c84
+
 /*
  * Bus Control Uint
  */
@@ -46,9 +49,25 @@
 /*
  * Clock Mask Unit
  */
-extern void vr41xx_cmu_init(u16 mask);
-extern void vr41xx_clock_supply(u16 mask);
-extern void vr41xx_clock_mask(u16 mask);
+extern void vr41xx_cmu_init(void);
+extern void vr41xx_clock_supply(unsigned int clock);
+extern void vr41xx_clock_mask(unsigned int clock);
+
+enum {
+	PIU_CLOCK,
+	SIU_CLOCK,
+	AIU_CLOCK,
+	KIU_CLOCK,
+	FIR_CLOCK,
+	DSIU_CLOCK,
+	CSI_CLOCK,
+	PCIU_CLOCK,
+	HSP_CLOCK,
+	PCI_CLOCK,
+	CEU_CLOCK,
+	ETHER0_CLOCK,
+	ETHER1_CLOCK
+};
 
 /*
  * Interrupt Control Unit

--Multipart=_Thu__30_Oct_2003_00_48_07_+0900_L.Yj.nakU46kW7Bd--

From macro@ds2.pg.gda.pl Wed Oct 29 17:11:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Oct 2003 17:11:09 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:50139 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225394AbTJ2RLF>; Wed, 29 Oct 2003 17:11:05 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id E268C4C108; Wed, 29 Oct 2003 18:11:03 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id CF2E9478D7; Wed, 29 Oct 2003 18:11:03 +0100 (CET)
Date: Wed, 29 Oct 2003 18:11:03 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc: <linux-mips@linux-mips.org>
Subject: Re: LK201 keyboard
In-Reply-To: <20031023083736.GL20846@lug-owl.de>
Message-ID: <Pine.LNX.4.32.0310291804500.20758-100000@jurand.ds.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3549
X-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, 23 Oct 2003, Jan-Benedict Glaw wrote:

> > > Erm, is this even correct if this keyboard isn't used "natively" by X11,
> > > but through the Input API?
> >
> >  For the console (or the cooked mode) we already set up the device
> > correctly.
>
> That doesn't exactly answer my question, but I think I'll figure it out
> at some time:) At least, if I get XFree through the compiler at some
> time (on a VAX).

 I've just misunderstood the question -- sorry.  For XFree86 the current
state is the "native" support doesn't work as of 3.3.6 (that's what I
have) because of broken mappings both in the kernel and in XFree86 and
that version doesn't support the input API AFAIK.  I'm told the "native"
support doesn't work for newer versions of XFree86, either, and I haven't
seen any reports about the input API.

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


From jsun@mvista.com Wed Oct 29 18:14:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Oct 2003 18:14:07 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:22519 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225371AbTJ2SOE>;
	Wed, 29 Oct 2003 18:14:04 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h9TIE0106288;
	Wed, 29 Oct 2003 10:14:00 -0800
Date: Wed, 29 Oct 2003 10:14:00 -0800
From: Jun Sun <jsun@mvista.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org, binutils@sources.redhat.com,
	jsun@mvista.com
Subject: Re: Huge dynamically linked program does not run on mips-linux
Message-ID: <20031029101400.J30683@mvista.com>
References: <20031022.171118.88468465.nemoto@toshiba-tops.co.jp> <20031029.163201.39178653.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20031029.163201.39178653.nemoto@toshiba-tops.co.jp>; from anemo@mba.ocn.ne.jp on Wed, Oct 29, 2003 at 04:32:01PM +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: 3550
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, Oct 29, 2003 at 04:32:01PM +0900, Atsushi Nemoto wrote:
> >>>>> On Wed, 22 Oct 2003 17:11:18 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
> anemo> I have a problem that my huge dynamically linked program cause
> anemo> SIGSEGV or SIGBUS immediately after running from main() on
> anemo> mips-linux.
> 
> anemo> Digging into this problem, I found that GOT entries are
> anemo> corrupted.
> ...
> anemo> My program is huge enough so that older binutils causes
> anemo> "relocation truncated to fit" error.
> 
> More information.  My program's .got size exceeds 64K.  It seems the
> corruption does not happen if .got size is smaller then 64K.
> 
> $ mips-linux-readelf -e myapp
> ...
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> ...
>   [21] .got              PROGBITS        100b15d0 a075d0 013a04 04 WAp  0   0 16
> 

Isn't this a known problem in binutils?  IIRC, someone is working or has
added "--big-got" support.

Jun

From drow@crack.them.org Wed Oct 29 18:15:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Oct 2003 18:15:56 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:27780 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225394AbTJ2SPy>;
	Wed, 29 Oct 2003 18:15:54 +0000
Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian))
	id 1AEuqj-0003lH-3R; Wed, 29 Oct 2003 13:15:17 -0500
Date: Wed, 29 Oct 2003 13:15:17 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Jun Sun <jsun@mvista.com>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: Huge dynamically linked program does not run on mips-linux
Message-ID: <20031029181516.GA14443@nevyn.them.org>
Mail-Followup-To: Jun Sun <jsun@mvista.com>,
	Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
References: <20031022.171118.88468465.nemoto@toshiba-tops.co.jp> <20031029.163201.39178653.nemoto@toshiba-tops.co.jp> <20031029101400.J30683@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031029101400.J30683@mvista.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3551
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Wed, Oct 29, 2003 at 10:14:00AM -0800, Jun Sun wrote:
> On Wed, Oct 29, 2003 at 04:32:01PM +0900, Atsushi Nemoto wrote:
> > >>>>> On Wed, 22 Oct 2003 17:11:18 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
> > anemo> I have a problem that my huge dynamically linked program cause
> > anemo> SIGSEGV or SIGBUS immediately after running from main() on
> > anemo> mips-linux.
> > 
> > anemo> Digging into this problem, I found that GOT entries are
> > anemo> corrupted.
> > ...
> > anemo> My program is huge enough so that older binutils causes
> > anemo> "relocation truncated to fit" error.
> > 
> > More information.  My program's .got size exceeds 64K.  It seems the
> > corruption does not happen if .got size is smaller then 64K.
> > 
> > $ mips-linux-readelf -e myapp
> > ...
> > Section Headers:
> >   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> > ...
> >   [21] .got              PROGBITS        100b15d0 a075d0 013a04 04 WAp  0   0 16
> > 
> 
> Isn't this a known problem in binutils?  IIRC, someone is working or has
> added "--big-got" support.

Atsushi-san's program would not even link with a binutils that didn't
support multiple GOTs; I guess that something is going wrong with that
support.

I don't suppose you could provide a testcase?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From hjl@lucon.org Wed Oct 29 22:29:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Oct 2003 22:29:35 +0000 (GMT)
Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:52469 "EHLO
	sccrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225398AbTJ2W3C>; Wed, 29 Oct 2003 22:29:02 +0000
Received: from lucon.org ([12.234.88.5]) by comcast.net (sccrmhc11) with ESMTP
          id <2003102922125301100j9qg6e>; Wed, 29 Oct 2003 22:12:53 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 9EA662C828; Wed, 29 Oct 2003 14:12:38 -0800 (PST)
Date: Wed, 29 Oct 2003 14:12:38 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org,
	GNU C Library <libc-alpha@sources.redhat.com>,
	Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	"Steven J. Hill" <sjhill@realitydiluted.com>
Subject: The Linux binutils 2.14.90.0.7 is released
Message-ID: <20031029221238.GA24487@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <hjl@lucon.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3552
X-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.7 for Linux, which is
based on binutils 2003 1029 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.

Please report any bugs related to binutils 2.14.90.0.7 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.6:

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

Changes from binutils 2.14.90.0.5:

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

Changes from binutils 2.14.90.0.4.1:

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

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

Changes from binutils 2.14.90.0.3:

1. Work around the brain dead libtool.

Changes from binutils 2.14.90.0.2:

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

Changes from binutils 2.14.90.0.1:

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

Changes from binutils 2.13.90.0.20:

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

Changes from binutils 2.13.90.0.18:

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

Changes from binutils 2.13.90.0.16:

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

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

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

Changes from binutils 2.13.90.0.10:

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

Changes from binutils 2.13.90.0.4:

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

Changes from binutils 2.13.90.0.3:

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

Changes from binutils 2.13.90.0.2:

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

The file list:

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

There is no separate source rpm. You can do

# rpmbuild -ta binutils-2.14.90.0.7.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
10/29/2003

From ica2_ts@csv.ica.uni-stuttgart.de Thu Oct 30 01:54:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Oct 2003 01:55:03 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:50998
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225450AbTJ3Bya>; Thu, 30 Oct 2003 01:54:30 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1AF20Y-0004lW-00; Thu, 30 Oct 2003 02:53:54 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1AF20X-0004Ut-00; Thu, 30 Oct 2003 02:53:53 +0100
Date: Thu, 30 Oct 2003 02:53:53 +0100
To: Jun Sun <jsun@mvista.com>, Atsushi Nemoto <anemo@mba.ocn.ne.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Huge dynamically linked program does not run on mips-linux
Message-ID: <20031030015353.GE1486@rembrandt.csv.ica.uni-stuttgart.de>
References: <20031022.171118.88468465.nemoto@toshiba-tops.co.jp> <20031029.163201.39178653.nemoto@toshiba-tops.co.jp> <20031029101400.J30683@mvista.com> <20031029181516.GA14443@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031029181516.GA14443@nevyn.them.org>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3553
X-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]
> > > anemo> My program is huge enough so that older binutils causes
> > > anemo> "relocation truncated to fit" error.
> > > 
> > > More information.  My program's .got size exceeds 64K.  It seems the
> > > corruption does not happen if .got size is smaller then 64K.
> > > 
> > > $ mips-linux-readelf -e myapp
> > > ...
> > > Section Headers:
> > >   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> > > ...
> > >   [21] .got              PROGBITS        100b15d0 a075d0 013a04 04 WAp  0   0 16
> > > 
> > 
> > Isn't this a known problem in binutils?  IIRC, someone is working or has
> > added "--big-got" support.
> 
> Atsushi-san's program would not even link with a binutils that didn't
> support multiple GOTs; I guess that something is going wrong with that
> support.

When building python-qt3 on debian unstable I get an oversize GOT and:

/usr/bin/ld: BFD 2.14.90.0.6 20030820 Debian GNU/Linux assertion fail ../../bfd/elfxx-mips.c:2287

Seems like multi-GOT is broken for this case.


Thiemo

From echristo@redhat.com Thu Oct 30 02:25:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Oct 2003 02:25:53 +0000 (GMT)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:31498 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225460AbTJ3CZv>;
	Thu, 30 Oct 2003 02:25:51 +0000
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 h9U26eA29901;
	Wed, 29 Oct 2003 21:06:40 -0500
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 h9U2P5a24668;
	Wed, 29 Oct 2003 21:25:05 -0500
Received: from unused (vpn26-1.sfbay.redhat.com [172.16.26.1])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h9U2P4J16789;
	Wed, 29 Oct 2003 18:25:04 -0800
Subject: Re: Huge dynamically linked program does not run on mips-linux
From: Eric Christopher <echristo@redhat.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Jun Sun <jsun@mvista.com>, Atsushi Nemoto <anemo@mba.ocn.ne.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
In-Reply-To: <20031030015353.GE1486@rembrandt.csv.ica.uni-stuttgart.de>
References: <20031022.171118.88468465.nemoto@toshiba-tops.co.jp>
	 <20031029.163201.39178653.nemoto@toshiba-tops.co.jp>
	 <20031029101400.J30683@mvista.com> <20031029181516.GA14443@nevyn.them.org>
	 <20031030015353.GE1486@rembrandt.csv.ica.uni-stuttgart.de>
Content-Type: text/plain
Message-Id: <1067480704.2542.8.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Wed, 29 Oct 2003 18:25:04 -0800
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: 3554
X-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


> When building python-qt3 on debian unstable I get an oversize GOT and:
> 
> /usr/bin/ld: BFD 2.14.90.0.6 20030820 Debian GNU/Linux assertion fail ../../bfd/elfxx-mips.c:2287
> 
> Seems like multi-GOT is broken for this case.

Judging from the line offset from today's sources to that error message
it might have been fixed with rsandifo's last patch that fixed an
uninitialized variable problem. (global_gotno)

-eric

-- 
Eric Christopher <echristo@redhat.com>


From anemo@mba.ocn.ne.jp Thu Oct 30 12:52:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Oct 2003 12:52:53 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:29973
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225495AbTJ3MwU>; Thu, 30 Oct 2003 12:52:20 +0000
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 30 Oct 2003 12:52:39 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h9UCqE9X046389;
	Thu, 30 Oct 2003 21:52:15 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 30 Oct 2003 21:54:53 +0900 (JST)
Message-Id: <20031030.215453.78703232.nemoto@toshiba-tops.co.jp>
To: dan@debian.org
Cc: jsun@mvista.com, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: Huge dynamically linked program does not run on mips-linux
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20031029181516.GA14443@nevyn.them.org>
References: <20031029.163201.39178653.nemoto@toshiba-tops.co.jp>
	<20031029101400.J30683@mvista.com>
	<20031029181516.GA14443@nevyn.them.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
 boundary="--Next_Part(Thu_Oct_30_21:54:53_2003_617)--"
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: 3555
X-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

----Next_Part(Thu_Oct_30_21:54:53_2003_617)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>>>>> On Wed, 29 Oct 2003 13:15:17 -0500, Daniel Jacobowitz <dan@debian.org> said:
dan> Atsushi-san's program would not even link with a binutils that
dan> didn't support multiple GOTs; I guess that something is going
dan> wrong with that support.

Yes, I guess too.

dan> I don't suppose you could provide a testcase?

I wrote a short script to generate a testcase.  Running attached awk
script create src0.c, src1.c, ..., src3.c.

$ mips-linux-gcc -c src[0-4].c
$ mips-linux-gcc -o bigapp src[0-4].o

This bigapp program compiled with binutils-2.14, gcc-3.3.2, uClibc
0.9.21 is corrupted.

Here is some outputs from readelf:

$ mips-linux-readelf -S bigapp
There are 31 section headers, starting at offset 0x36ad78:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        004000f4 0000f4 00000d 00   A  0   0  1
  [ 2] .reginfo          MIPS_REGINFO    00400104 000104 000018 18   A  0   0  4
  [ 3] .dynamic          DYNAMIC         0040011c 00011c 0000d8 08   A  6   0  4
  [ 4] .hash             HASH            004001f4 0001f4 028784 04   A  5   0  4
  [ 5] .dynsym           DYNSYM          00428978 028978 061c40 10   A  6   1  4
  [ 6] .dynstr           STRTAB          0048a5b8 08a5b8 041da5 00   A  0   0  1
  [ 7] .init             PROGBITS        004cc370 0cc370 0000ac 00  AX  0   0  4
  [ 8] .text             PROGBITS        004cc420 0cc420 1b7d60 00  AX  0   0 16
  [ 9] .fini             PROGBITS        00684180 284180 00005c 00  AX  0   0  4
  [10] .rodata           PROGBITS        006841e0 2841e0 000010 00   A  0   0 16
  [11] .data             PROGBITS        10000000 285000 000010 00  WA  0   0 16
  [12] .rld_map          PROGBITS        10000010 285010 000004 00  WA  0   0  4
  [13] .eh_frame         PROGBITS        10000014 285014 000004 00   A  0   0  4
  [14] .ctors            PROGBITS        10000018 285018 000008 00  WA  0   0  4
  [15] .dtors            PROGBITS        10000020 285020 000008 00  WA  0   0  4
  [16] .jcr              PROGBITS        10000028 285028 000004 00  WA  0   0  4
  [17] .got              PROGBITS        10000030 285030 02245c 04 WAp  0   0 16
  [18] .sbss             NOBITS          1002248c 2a7490 000000 00 WAp  0   0  1
  [19] .bss              NOBITS          10022490 2a7490 000020 00  WA  0   0 16
  [20] .comment          PROGBITS        00000000 2a7490 0000a2 00      0   0  1
  [21] .debug_aranges    MIPS_DWARF      00000000 2a7538 000020 00      0   0  8
  [22] .debug_info       MIPS_DWARF      00000000 2a7558 000069 00      0   0  1
  [23] .debug_abbrev     MIPS_DWARF      00000000 2a75c1 000014 00      0   0  1
  [24] .debug_line       MIPS_DWARF      00000000 2a75d5 000044 00      0   0  1
  [25] .pdr              PROGBITS        00000000 2a761c 0c3660 00      0   0  4
  [26] .rel.dyn          REL             004cc360 0cc360 000010 08   A  5   0 16
  [27] .mdebug.abi32     PROGBITS        00000000 36ac7c 000000 00      0   0  1
  [28] .shstrtab         STRTAB          00000000 36ac7c 0000fb 00      0   0  1
  [29] .symtab           SYMTAB          00000000 36b250 0620a0 10     30  45  4
  [30] .strtab           STRTAB          00000000 3cd2f0 041ee7 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)
$ mips-linux-readelf -r bigapp

Relocation section '.rel.dyn' at offset 0xcc360 contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000000  00000000 R_MIPS_NONE      
1001f4f0  00314703 R_MIPS_REL32      004cc490   getpid
$ mips-linux-readelf -x 17 bigapp | grep 1001f4f0
  0x1001f4f0 004cc490 005ea570 00655ba0 0062c9e0 .L...^.p.e[..b..
$ mips-linux-readelf -s bigapp | grep getpid
 12615: 004cc490     0 FUNC    GLOBAL DEFAULT  UND getpid
  4109: 004cc490     0 FUNC    GLOBAL DEFAULT  UND getpid


Strangely the bigapp works correct if I compiled it with glibc 2.2.5.

Here is some outputs from readelf on bigapp.glibc:

$ mips-linux-readelf -S bigapp.glibc
There are 36 section headers, starting at offset 0x378644:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        00400114 000114 00000d 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            00400130 000130 000020 00   A  0   0 16
  [ 3] .reginfo          MIPS_REGINFO    00400150 000150 000018 18   A  0   0  4
  [ 4] .dynamic          DYNAMIC         00400168 000168 0000f0 08   A  7   0  4
  [ 5] .hash             HASH            00400258 000258 028764 04   A  6   0  4
  [ 6] .dynsym           DYNSYM          004289bc 0289bc 061bc0 10   A  7   1  4
  [ 7] .dynstr           STRTAB          0048a57c 08a57c 041d6d 00   A  0   0  1
  [ 8] .gnu.version      VERSYM          004cc2ea 0cc2ea 00c378 02   A  6   0  2
  [ 9] .gnu.version_r    VERNEED         004d8664 0d8664 000020 00   A  7   1  4
  [10] .init             PROGBITS        004d86a0 0d86a0 0000ac 00  AX  0   0  4
  [11] .text             PROGBITS        004d8750 0d8750 1b7d40 00  AX  0   0 16
  [12] .fini             PROGBITS        00690490 290490 00005c 00  AX  0   0  4
  [13] .rodata           PROGBITS        006904f0 2904f0 000020 00   A  0   0 16
  [14] .data             PROGBITS        10000000 291000 000020 00  WA  0   0 16
  [15] .rld_map          PROGBITS        10000020 291020 000004 00  WA  0   0  4
  [16] .eh_frame         PROGBITS        10000024 291024 000004 00   A  0   0  4
  [17] .ctors            PROGBITS        10000028 291028 000008 00  WA  0   0  4
  [18] .dtors            PROGBITS        10000030 291030 000008 00  WA  0   0  4
  [19] .jcr              PROGBITS        10000038 291038 000004 00  WA  0   0  4
  [20] .got              PROGBITS        10000040 291040 022460 04 WAp  0   0 16
  [21] .sbss             NOBITS          100224a0 2b34a0 000000 00 WAp  0   0  1
  [22] .bss              NOBITS          100224a0 2b34a0 000020 00  WA  0   0 16
  [23] .comment          PROGBITS        00000000 2b34a0 0000b4 00      0   0  1
  [24] .debug_aranges    MIPS_DWARF      00000000 2b3558 000058 00      0   0  8
  [25] .debug_pubnames   MIPS_DWARF      00000000 2b35b0 000025 00      0   0  1
  [26] .debug_info       MIPS_DWARF      00000000 2b35d5 000c55 00      0   0  1
  [27] .debug_abbrev     MIPS_DWARF      00000000 2b422a 00012b 00      0   0  1
  [28] .debug_line       MIPS_DWARF      00000000 2b4355 00028e 00      0   0  1
  [29] .debug_str        MIPS_DWARF      00000000 2b45e3 000960 01  MS  0   0  1
  [30] .pdr              PROGBITS        00000000 2b4f44 0c35c0 00      0   0  4
  [31] .mdebug.abi32     PROGBITS        00000000 378504 000000 00      0   0  1
  [32] .rel.dyn          REL             004d8690 0d8690 000010 08   A  6   0 16
  [33] .shstrtab         STRTAB          00000000 378504 000140 00      0   0  1
  [34] .symtab           SYMTAB          00000000 378be4 062200 10     35  59  4
  [35] .strtab           STRTAB          00000000 3dade4 04204e 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)
$ mips-linux-readelf -r bigapp.glibc

Relocation section '.rel.dyn' at offset 0xd8690 contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000000  00000000 R_MIPS_NONE      
1001c3c0  00340403 R_MIPS_REL32      00000000   getpid
$ mips-linux-readelf -x 20 bigapp.glibc | grep 1001c3c0
  0x1001c3c0 00000000 0060d3e0 0063cd10 00608f70 .....`...c...`.p
$ mips-linux-readelf -s bigapp.glibc | grep getpid
 13316: 00000000     0 FUNC    GLOBAL DEFAULT  UND getpid@GLIBC_2.0 (2)
  2943: 00000000     0 FUNC    GLOBAL DEFAULT  UND getpid@@GLIBC_2.0


Is there other informations I can provide?

---
Atsushi Nemoto

----Next_Part(Thu_Oct_30_21:54:53_2003_617)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename=mkbigapp

#!/bin/awk -f
BEGIN {
	nfile = 5;
	nfunc = 5000;
	for (j = 0; j < nfile; j++) {
		fname = "src" j ".c";
		printf("/* %s */\n", fname) > fname;
		for (i = 0; i < nfunc; i++) {
			printf("void func%d_%d(void) {}\n", j, i, i) >> fname;
		}
		printf("int func%d(void) {\n", j) >> fname;
		for (i = 0; i < nfunc; i++) {
			printf("func%d_%d();\n", j, i) >> fname;
		}
		printf("return getpid();\n") >> fname;
		printf("}\n") >> fname;
		if (j == 0) {
			printf("int main(int argc, char **argv) {\n") > fname;
			for (i = 0; i < nfile; i++) {
				printf("printf(\"%%d\\n\", func%d());\n", i) >> fname;
			}
			printf("return 0;\n") >> fname;
			printf("}\n") >> fname;
		}
		close(fname);
	}
}

----Next_Part(Thu_Oct_30_21:54:53_2003_617)----

From yuasa@hh.iij4u.or.jp Thu Oct 30 15:17:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Oct 2003 15:17:43 +0000 (GMT)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:18683 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225386AbTJ3PRL>;
	Thu, 30 Oct 2003 15:17:11 +0000
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA08380;
	Fri, 31 Oct 2003 00:17:03 +0900 (JST)
Received: 4UMDO01 id h9UFH1m14930; Fri, 31 Oct 2003 00:17:02 +0900 (JST)
Received: 4UMRO01 id h9UFGxd04967; Fri, 31 Oct 2003 00:17:00 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Fri, 31 Oct 2003 00:16:58 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: [patch] VR4133
Message-Id: <20031031001658.23bf544c.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20031030004807.05974e01.yuasa@hh.iij4u.or.jp>
References: <20031008003402.23a326cb.yuasa@hh.iij4u.or.jp>
	<20031012151517.GA20647@linux-mips.org>
	<20031013020207.5887e42e.yuasa@hh.iij4u.or.jp>
	<20031016010533.5a772fef.yuasa@hh.iij4u.or.jp>
	<20031030004807.05974e01.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart=_Fri__31_Oct_2003_00_16_58_+0900_MB_RW/VX.w/mVD7N"
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: 3556
X-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=_Fri__31_Oct_2003_00_16_58_+0900_MB_RW/VX.w/mVD7N
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I updated about VR4133 also for mips64 file of v2.4.

Yoichi

On Thu, 30 Oct 2003 00:48:07 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hello Ralf,
> 
> I updated these patches for latest CVS tree.
> These patches add support of NEC VR4133 CPU.
> 
> Please apply these patches.
> 
> Yoichi
> 
> On Thu, 16 Oct 2003 01:05:33 +0900
> Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:
> 
> > Hello Ralf,
> > 
> > I updated the patch about part of GIU for VR4133.
> > Please apply them to CVS tree.
> > 
> > Yoichi
> > 
> > On Mon, 13 Oct 2003 02:02:07 +0900
> > Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:
> > 
> > > Hello Ralf,
> > > 
> > > On Sun, 12 Oct 2003 17:15:17 +0200
> > > Ralf Baechle <ralf@linux-mips.org> wrote:
> > > 
> > > > On Wed, Oct 08, 2003 at 12:34:02AM +0900, Yoichi Yuasa wrote:
> > > > 
> > > > > I made patches for NEC VR4133.
> > > > > These patches add support of new CPU of NEC.
> > > > > 
> > > > > Please apply this patch to CVS tree.
> > > > 
> > > > Please keep the 32-bit and 64-bit files in sync - even if you're not
> > > > using both.  Having them diverse is a huge pain.
> > > 
> > > OK, I updated these patches.
> > > 
> > > Please apply them to CVS.
> > > 
> > > Yoichi
> > > 
> > > 
> > 
> 

--Multipart=_Fri__31_Oct_2003_00_16_58_+0900_MB_RW/VX.w/mVD7N
Content-Type: text/plain;
 name="vr4133-v24-031031.diff"
Content-Disposition: attachment;
 filename="vr4133-v24-031031.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux.orig/arch/mips/kernel/cpu-probe.c	Tue Oct 14 11:58:38 2003
+++ linux/arch/mips/kernel/cpu-probe.c	Thu Oct 30 23:51:39 2003
@@ -220,8 +220,11 @@
 			else
 				c->cputype = CPU_VR4181A;
 			break;
-		case PRID_REV_VR4131:
-			c->cputype = CPU_VR4131;
+		case PRID_REV_VR4130:
+			if ((c->processor_id & 0xf) < 0x4)
+				c->cputype = CPU_VR4131;
+			else
+				c->cputype = CPU_VR4133;
 			break;
 		default:
 			printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/proc.c linux/arch/mips/kernel/proc.c
--- linux.orig/arch/mips/kernel/proc.c	Tue Oct 14 11:58:38 2003
+++ linux/arch/mips/kernel/proc.c	Thu Oct 30 23:51:39 2003
@@ -68,6 +68,7 @@
 	[CPU_VR4121]	"NEC VR4121",
 	[CPU_VR4122]	"NEC VR4122",
 	[CPU_VR4131]	"NEC VR4131",
+	[CPU_VR4133]	"NEC VR4133",
 	[CPU_VR4181]	"NEC VR4181",
 	[CPU_VR4181A]	"NEC VR4181A",
 	[CPU_SR71000]	"Sandcraft SR71000"
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux.orig/arch/mips/mm/c-r4k.c	Tue Oct 14 11:58:39 2003
+++ linux/arch/mips/mm/c-r4k.c	Thu Oct 30 23:51:40 2003
@@ -833,6 +833,8 @@
 		c->dcache.waybit = 0;
 		break;
 
+	case CPU_VR4133:
+		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux.orig/arch/mips/vr41xx/casio-e55/setup.c	Wed Jul 30 09:35:37 2003
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Thu Oct 30 23:51:40 2003
@@ -59,7 +59,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux.orig/arch/mips/vr41xx/common/bcu.c	Sat Aug 30 01:32:54 2003
+++ linux/arch/mips/vr41xx/common/bcu.c	Thu Oct 30 23:51:40 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - Calculate mips_hpt_frequency properly on VR4131.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -52,8 +53,8 @@
 
 #define VR4111_CLKSPEEDREG	KSEG1ADDR(0x0b000014)
 #define VR4122_CLKSPEEDREG	KSEG1ADDR(0x0f000014)
-#define VR4131_CLKSPEEDREG	VR4122_CLKSPEEDREG
  #define CLKSP(x)		((x) & 0x001f)
+ #define CLKSP_VR4133(x)	((x) & 0x0007)
 
  #define DIV2B			0x8000
  #define DIV3B			0x4000
@@ -72,8 +73,9 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121: return readw(VR4111_CLKSPEEDREG);
-	case CPU_VR4122: return readw(VR4122_CLKSPEEDREG);
-	case CPU_VR4131: return readw(VR4131_CLKSPEEDREG);
+	case CPU_VR4122:
+	case CPU_VR4131:
+	case CPU_VR4133: return readw(VR4122_CLKSPEEDREG);
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
@@ -90,19 +92,43 @@
 	case CPU_VR4111:
 	case CPU_VR4121:
 		pclock = 18432000 * 64;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4122:
 		pclock = 18432000 * 98;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4131:
 		pclock = 18432000 * 108;
+		pclock /= CLKSP(clkspeed);
+		break;
+	case CPU_VR4133:
+		switch (CLKSP_VR4133(clkspeed)) {
+		case 0:
+			pclock = 133000000;
+			break;
+		case 1:
+			pclock = 149000000;
+			break;
+		case 2:
+			pclock = 165900000;
+			break;
+		case 3:
+			pclock = 199100000;
+			break;
+		case 4:
+			pclock = 265900000;
+			break;
+		default:
+			printk(KERN_INFO "Unknown PClock speed for NEC VR4133\n");
+			break;
+		}
 		break;
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
 	}
 
-	pclock /= CLKSP(clkspeed);
 	printk(KERN_INFO "PClock: %ldHz\n", pclock);
 
 	return pclock;
@@ -135,6 +161,7 @@
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_vtclock = pclock / VTDIVMODE(clkspeed);
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
@@ -165,6 +192,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		tclock = vtclock / TDIVMODE(clkspeed);
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux.orig/arch/mips/vr41xx/common/cmu.c	Mon Apr  7 09:17:06 2003
+++ linux/arch/mips/vr41xx/common/cmu.c	Thu Oct 30 23:51:40 2003
@@ -33,38 +33,174 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
 #include <asm/io.h>
+#include <asm/vr41xx/vr41xx.h>
 
 #define VR4111_CMUCLKMSK	KSEG1ADDR(0x0b000060)
 #define VR4122_CMUCLKMSK	KSEG1ADDR(0x0f000060)
+ #define MSKPIU			0x0001
+ #define MSKSIU			0x0002
+ #define MSKAIU			0x0004
+ #define MSKKIU			0x0008
+ #define MSKFIR			0x0010
+ #define MSKDSIU		0x0820
+ #define MSKCSI			0x0040
+ #define MSKPCIU		0x0080
+ #define MSKSSIU		0x0100
+ #define MSKSHSP		0x0200
+ #define MSKFFIR		0x0400
+ #define MSKSCSI		0x1000
+ #define MSKPPCIU		0x2000
+#define VR4133_CMUCLKMSK2	KSEG1ADDR(0x0f000064)
+ #define MSKCEU			0x0001
+ #define MSKMAC0		0x0002
+ #define MSKMAC1		0x0004
 
 static u32 vr41xx_cmu_base;
-static u16 cmuclkmsk;
+static u16 cmuclkmsk, cmuclkmsk2;
 
-#define write_cmu(mask)	writew((mask), vr41xx_cmu_base)
+#define read_cmuclkmsk()	readw(vr41xx_cmu_base)
+#define read_cmuclkmsk2()	readw(VR4133_CMUCLKMSK2)
+#define write_cmuclkmsk()	writew(cmuclkmsk, vr41xx_cmu_base)
+#define write_cmuclkmsk2()	writew(cmuclkmsk2, VR4133_CMUCLKMSK2)
 
-void vr41xx_clock_supply(u16 mask)
+void vr41xx_clock_supply(unsigned int clock)
 {
-	cmuclkmsk |= mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk |= MSKPIU;
+		break;
+	case SIU_CLOCK:
+		cmuclkmsk |= MSKSIU | MSKSSIU;
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk |= MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk |= MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk |= MSKFIR | MSKFFIR;
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121)
+			cmuclkmsk |= MSKDSIU;
+		else
+			cmuclkmsk |= MSKSIU | MSKDSIU;
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk |= MSKCSI | MSKSCSI;
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk |= MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk |= MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk |= MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 |= MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 |= MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 |= MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void vr41xx_clock_mask(u16 mask)
+void vr41xx_clock_mask(unsigned int clock)
 {
-	cmuclkmsk &= ~mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk &= ~MSKPIU;
+		break;
+	case SIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		} else {
+			if (cmuclkmsk & MSKDSIU)
+				cmuclkmsk &= ~MSKSSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		}
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk &= ~MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk &= ~MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk &= ~(MSKFIR | MSKFFIR);
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~MSKDSIU;
+		} else {
+			if (cmuclkmsk & MSKSIU)
+				cmuclkmsk &= ~MSKDSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKDSIU);
+		}
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk &= ~(MSKCSI | MSKSCSI);
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk &= ~MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk &= ~MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk &= ~MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 &= ~MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void __init vr41xx_cmu_init(u16 mask)
+void __init vr41xx_cmu_init(void)
 {
 	switch (current_cpu_data.cputype) {
         case CPU_VR4111:
@@ -75,10 +211,14 @@
         case CPU_VR4131:
                 vr41xx_cmu_base = VR4122_CMUCLKMSK;
                 break;
+        case CPU_VR4133:
+                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+		cmuclkmsk2 = read_cmuclkmsk2();
+                break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
 		break;
         }
 
-	cmuclkmsk = mask;
+	cmuclkmsk = read_cmuclkmsk();
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux.orig/arch/mips/vr41xx/common/giu.c	Wed Apr 16 21:59:34 2003
+++ linux/arch/mips/vr41xx/common/giu.c	Thu Oct 30 23:51:40 2003
@@ -34,6 +34,9 @@
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
  *  - New creation, NEC VR4111, VR4121, VR4122 and VR4131 are supported.
+ *
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -246,6 +249,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_giu_base = VR4122_GIUIOSELL;
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux.orig/arch/mips/vr41xx/common/icu.c	Wed Apr 16 21:59:34 2003
+++ linux/arch/mips/vr41xx/common/icu.c	Thu Oct 30 23:51:40 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - kgdb support.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -290,6 +291,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_icu1_base = VR4122_SYSINT1REG;
 		vr41xx_icu2_base = VR4122_SYSINT2REG;
 		break;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/pciu.c linux/arch/mips/vr41xx/common/pciu.c
--- linux.orig/arch/mips/vr41xx/common/pciu.c	Mon Apr  7 09:17:06 2003
+++ linux/arch/mips/vr41xx/common/pciu.c	Thu Oct 30 23:51:40 2003
@@ -74,7 +74,7 @@
 		/*
 		 * Type 1 configuration
 		 */
-		if (bus > 255 || PCI_SLOT(dev_fn) > 31 || where > 255)
+		if (PCI_SLOT(dev_fn) > 31 || where > 255)
 			return -1;
 
 		writel((bus << 16)	|
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/pciu.h linux/arch/mips/vr41xx/common/pciu.h
--- linux.orig/arch/mips/vr41xx/common/pciu.h	Mon Jul 15 09:02:56 2002
+++ linux/arch/mips/vr41xx/common/pciu.h	Thu Oct 30 23:51:40 2003
@@ -107,9 +107,6 @@
 
 #define MAX_PCI_CLOCK			33333333
 
-#define PCIU_CLOCK			0x0080
-#define PCI_CLOCK			0x2000
-
 static inline int pciu_read_config_byte(int where, u8 *val)
 {
 	u32 data;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux.orig/arch/mips/vr41xx/common/serial.c	Mon Apr  7 09:17:06 2003
+++ linux/arch/mips/vr41xx/common/serial.c	Thu Oct 30 23:51:40 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -66,7 +67,6 @@
  #define TMICMODE		0x20
 
 #define SIU_BASE_BAUD		1152000
-#define SIU_CLOCK		0x0102
 
 /* VR4122 and VR4131 DSIU Registers */
 #define DSIURB			KSEG1ADDR(0x0f000820)
@@ -75,7 +75,6 @@
  #define INTDSIU		0x0800
 
 #define DSIU_BASE_BAUD		1152000
-#define DSIU_CLOCK		0x0802
 
 int vr41xx_serial_ports = 0;
 
@@ -106,6 +105,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		writew(val, VR4122_SIUIRSEL);
 		break;
 	default:
@@ -133,6 +133,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		s.iomem_base = (unsigned char *)VR4122_SIURB;
 		break;
 	default:
@@ -154,7 +155,8 @@
 	struct serial_struct s;
 
 	if (current_cpu_data.cputype != CPU_VR4122 &&
-	    current_cpu_data.cputype != CPU_VR4131)
+	    current_cpu_data.cputype != CPU_VR4131 &&
+	    current_cpu_data.cputype != CPU_VR4133)
 		return;
 
 	memset(&s, 0, sizeof(s));
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/time.c linux/arch/mips/vr41xx/common/time.c
--- linux.orig/arch/mips/vr41xx/common/time.c	Sat Aug 30 01:32:54 2003
+++ linux/arch/mips/vr41xx/common/time.c	Thu Oct 30 23:51:40 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4100 series are supported.
  *  - Added support for NEC VR4100 series RTC Unit.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4100 series are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/config.h>
 #include <linux/interrupt.h>
@@ -69,6 +70,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
                 vr41xx_rtc_base = VR4122_ETIMELREG;
                 break;
         default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Thu Oct 30 23:51:40 2003
@@ -59,7 +59,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Thu Oct 30 23:51:40 2003
@@ -140,7 +140,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	Thu Oct 30 23:51:41 2003
@@ -102,7 +102,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
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 May 22 06:36:53 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Thu Oct 30 23:51:41 2003
@@ -114,7 +114,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Thu Oct 30 23:51:41 2003
@@ -107,7 +107,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/setup.c	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Thu Oct 30 23:51:41 2003
@@ -107,7 +107,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0x0102);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips64/kernel/cpu-probe.c linux/arch/mips64/kernel/cpu-probe.c
--- linux.orig/arch/mips64/kernel/cpu-probe.c	Sun Sep 21 01:21:25 2003
+++ linux/arch/mips64/kernel/cpu-probe.c	Thu Oct 30 23:53:40 2003
@@ -544,8 +544,11 @@
 				else
 					c->cputype = CPU_VR4181A;
 				break;
-			case PRID_REV_VR4131:
-				c->cputype = CPU_VR4131;
+			case PRID_REV_VR4130:
+				if ((c->processor_id & 0xf) < 0x4)
+					c->cputype = CPU_VR4131;
+				else
+					c->cputype = CPU_VR4133;
 				break;
 			default:
 				printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips64/kernel/proc.c linux/arch/mips64/kernel/proc.c
--- linux.orig/arch/mips64/kernel/proc.c	Tue Oct 14 11:58:46 2003
+++ linux/arch/mips64/kernel/proc.c	Thu Oct 30 23:54:10 2003
@@ -68,6 +68,7 @@
 	[CPU_VR4121]	"NEC VR4121",
 	[CPU_VR4122]	"NEC VR4122",
 	[CPU_VR4131]	"NEC VR4131",
+	[CPU_VR4133]	"NEC VR4133",
 	[CPU_VR4181]	"NEC VR4181",
 	[CPU_VR4181A]	"NEC VR4181A",
 	[CPU_SR71000]	"Sandcraft SR71000"
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips64/mm/c-r4k.c linux/arch/mips64/mm/c-r4k.c
--- linux.orig/arch/mips64/mm/c-r4k.c	Tue Oct 14 11:58:47 2003
+++ linux/arch/mips64/mm/c-r4k.c	Thu Oct 30 23:54:51 2003
@@ -833,6 +833,8 @@
 		c->dcache.waybit = 0;
 		break;
 
+	case CPU_VR4133:
+		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/cpu.h linux/include/asm-mips/cpu.h
--- linux.orig/include/asm-mips/cpu.h	Tue Oct 14 11:58:58 2003
+++ linux/include/asm-mips/cpu.h	Thu Oct 30 23:51:41 2003
@@ -100,7 +100,7 @@
 #define PRID_REV_VR4121		0x0060
 #define PRID_REV_VR4122		0x0070
 #define PRID_REV_VR4181A	0x0070	/* Same as VR4122 */
-#define PRID_REV_VR4131		0x0080
+#define PRID_REV_VR4130		0x0080
 
 /*
  * FPU implementation/revision register (CP1 control register 0).
@@ -168,7 +168,8 @@
 #define CPU_AU1100		52
 #define CPU_SR71000		53
 #define CPU_RM9000		54
-#define CPU_LAST		54
+#define CPU_VR4133		55
+#define CPU_LAST		55
 
 /*
  * ISA Level encodings
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	Wed Jul 30 09:35:38 2003
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Thu Oct 30 23:51:41 2003
@@ -32,12 +32,15 @@
 #define PRID_VR4181A_REV1_0	0x00000c73
 #define PRID_VR4181A_REV1_1	0x00000c74
 
-/* VR4131 0x00000c80-0x00000c8f */
+/* VR4131 0x00000c80-0x00000c83 */
 #define PRID_VR4131_REV1_2	0x00000c80
 #define PRID_VR4131_REV2_0	0x00000c81
 #define PRID_VR4131_REV2_1	0x00000c82
 #define PRID_VR4131_REV2_2	0x00000c83
 
+/* VR4133 0x00000c84- */
+#define PRID_VR4133		0x00000c84
+
 /*
  * Bus Control Uint
  */
@@ -46,9 +49,25 @@
 /*
  * Clock Mask Unit
  */
-extern void vr41xx_cmu_init(u16 mask);
-extern void vr41xx_clock_supply(u16 mask);
-extern void vr41xx_clock_mask(u16 mask);
+extern void vr41xx_cmu_init(void);
+extern void vr41xx_clock_supply(unsigned int clock);
+extern void vr41xx_clock_mask(unsigned int clock);
+
+enum {
+	PIU_CLOCK,
+	SIU_CLOCK,
+	AIU_CLOCK,
+	KIU_CLOCK,
+	FIR_CLOCK,
+	DSIU_CLOCK,
+	CSI_CLOCK,
+	PCIU_CLOCK,
+	HSP_CLOCK,
+	PCI_CLOCK,
+	CEU_CLOCK,
+	ETHER0_CLOCK,
+	ETHER1_CLOCK
+};
 
 /*
  * Interrupt Control Unit
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips64/cpu.h linux/include/asm-mips64/cpu.h
--- linux.orig/include/asm-mips64/cpu.h	Tue Oct 14 11:58:59 2003
+++ linux/include/asm-mips64/cpu.h	Thu Oct 30 23:56:07 2003
@@ -100,7 +100,7 @@
 #define PRID_REV_VR4121		0x0060
 #define PRID_REV_VR4122		0x0070
 #define PRID_REV_VR4181A	0x0070	/* Same as VR4122 */
-#define PRID_REV_VR4131		0x0080
+#define PRID_REV_VR4130		0x0080
 
 /*
  * FPU implementation/revision register (CP1 control register 0).
@@ -168,7 +168,8 @@
 #define CPU_AU1100		52
 #define CPU_SR71000		53
 #define CPU_RM9000		54
-#define CPU_LAST		54
+#define CPU_VR4133		55
+#define CPU_LAST		55
 
 /*
  * ISA Level encodings

--Multipart=_Fri__31_Oct_2003_00_16_58_+0900_MB_RW/VX.w/mVD7N
Content-Type: text/plain;
 name="vr4133-v26-031031.diff"
Content-Disposition: attachment;
 filename="vr4133-v26-031031.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux.orig/arch/mips/kernel/cpu-probe.c	Tue Oct 14 12:00:55 2003
+++ linux/arch/mips/kernel/cpu-probe.c	Thu Oct 30 23:50:17 2003
@@ -222,9 +222,11 @@
 			else
 				c->cputype = CPU_VR4181A;
 			break;
-		case PRID_REV_VR4131:
-			c->cputype = CPU_VR4131;
-			break;
+		case PRID_REV_VR4130:
+			if ((c->processor_id & 0xf) < 0x4)
+				c->cputype = CPU_VR4131;
+			else
+				c->cputype = CPU_VR4133;
 		default:
 			printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 				c->cputype = CPU_VR41XX;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/proc.c linux/arch/mips/kernel/proc.c
--- linux.orig/arch/mips/kernel/proc.c	Tue Oct 14 12:00:55 2003
+++ linux/arch/mips/kernel/proc.c	Thu Oct 30 23:50:17 2003
@@ -69,6 +69,7 @@
 	[CPU_VR4121]	"NEC VR4121",
 	[CPU_VR4122]	"NEC VR4122",
 	[CPU_VR4131]	"NEC VR4131",
+	[CPU_VR4133]	"NEC VR4133",
 	[CPU_VR4181]	"NEC VR4181",
 	[CPU_VR4181A]	"NEC VR4181A",
 	[CPU_SR71000]	"Sandcraft SR71000"
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux.orig/arch/mips/mm/c-r4k.c	Tue Oct 14 12:00:56 2003
+++ linux/arch/mips/mm/c-r4k.c	Thu Oct 30 23:50:17 2003
@@ -831,6 +831,8 @@
 		c->dcache.waybit = 0;
 		break;
 
+	case CPU_VR4133:
+		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/pci/pci-vr41xx.h linux/arch/mips/pci/pci-vr41xx.h
--- linux.orig/arch/mips/pci/pci-vr41xx.h	Fri Jun 13 23:19:56 2003
+++ linux/arch/mips/pci/pci-vr41xx.h	Thu Oct 30 23:50:17 2003
@@ -107,9 +107,6 @@
 
 #define MAX_PCI_CLOCK			33333333
 
-#define PCIU_CLOCK			0x0080
-#define PCI_CLOCK			0x2000
-
 static inline int pciu_read_config_byte(int where, u8 * val)
 {
 	u32 data;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux.orig/arch/mips/vr41xx/casio-e55/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Thu Oct 30 23:50:17 2003
@@ -62,7 +62,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux.orig/arch/mips/vr41xx/common/bcu.c	Sat Aug 30 01:35:41 2003
+++ linux/arch/mips/vr41xx/common/bcu.c	Thu Oct 30 23:50:17 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - Calculate mips_hpt_frequency properly on VR4131.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -52,8 +53,8 @@
 
 #define VR4111_CLKSPEEDREG	KSEG1ADDR(0x0b000014)
 #define VR4122_CLKSPEEDREG	KSEG1ADDR(0x0f000014)
-#define VR4131_CLKSPEEDREG	VR4122_CLKSPEEDREG
  #define CLKSP(x)		((x) & 0x001f)
+ #define CLKSP_VR4133(x)	((x) & 0x0007)
 
  #define DIV2B			0x8000
  #define DIV3B			0x4000
@@ -72,8 +73,9 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121: return readw(VR4111_CLKSPEEDREG);
-	case CPU_VR4122: return readw(VR4122_CLKSPEEDREG);
-	case CPU_VR4131: return readw(VR4131_CLKSPEEDREG);
+	case CPU_VR4122:
+	case CPU_VR4131:
+	case CPU_VR4133: return readw(VR4122_CLKSPEEDREG);
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
@@ -90,19 +92,43 @@
 	case CPU_VR4111:
 	case CPU_VR4121:
 		pclock = 18432000 * 64;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4122:
 		pclock = 18432000 * 98;
+		pclock /= CLKSP(clkspeed);
 		break;
 	case CPU_VR4131:
 		pclock = 18432000 * 108;
+		pclock /= CLKSP(clkspeed);
+		break;
+	case CPU_VR4133:
+		switch (CLKSP_VR4133(clkspeed)) {
+		case 0:
+			pclock = 133000000;
+			break;
+		case 1:
+			pclock = 149000000;
+			break;
+		case 2:
+			pclock = 165900000;
+			break;
+		case 3:
+			pclock = 199100000;
+			break;
+		case 4:
+			pclock = 265900000;
+			break;
+		default:
+			printk(KERN_INFO "Unknown PClock speed for NEC VR4133\n");
+			break;
+		}
 		break;
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
 	}
 
-	pclock /= CLKSP(clkspeed);
 	printk(KERN_INFO "PClock: %ldHz\n", pclock);
 
 	return pclock;
@@ -135,6 +161,7 @@
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_vtclock = pclock / VTDIVMODE(clkspeed);
 		printk(KERN_INFO "VTClock: %ldHz\n", vr41xx_vtclock);
 		break;
@@ -165,6 +192,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		tclock = vtclock / TDIVMODE(clkspeed);
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux.orig/arch/mips/vr41xx/common/cmu.c	Fri Apr 11 00:17:57 2003
+++ linux/arch/mips/vr41xx/common/cmu.c	Thu Oct 30 23:50:17 2003
@@ -33,38 +33,174 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
 #include <asm/io.h>
+#include <asm/vr41xx/vr41xx.h>
 
 #define VR4111_CMUCLKMSK	KSEG1ADDR(0x0b000060)
 #define VR4122_CMUCLKMSK	KSEG1ADDR(0x0f000060)
+ #define MSKPIU			0x0001
+ #define MSKSIU			0x0002
+ #define MSKAIU			0x0004
+ #define MSKKIU			0x0008
+ #define MSKFIR			0x0010
+ #define MSKDSIU		0x0820
+ #define MSKCSI			0x0040
+ #define MSKPCIU		0x0080
+ #define MSKSSIU		0x0100
+ #define MSKSHSP		0x0200
+ #define MSKFFIR		0x0400
+ #define MSKSCSI		0x1000
+ #define MSKPPCIU		0x2000
+#define VR4133_CMUCLKMSK2	KSEG1ADDR(0x0f000064)
+ #define MSKCEU			0x0001
+ #define MSKMAC0		0x0002
+ #define MSKMAC1		0x0004
+
+static u32 vr41xx_cmu_base;
+static u16 cmuclkmsk, cmuclkmsk2;
+
+#define read_cmuclkmsk()	readw(vr41xx_cmu_base)
+#define read_cmuclkmsk2()	readw(VR4133_CMUCLKMSK2)
+#define write_cmuclkmsk()	writew(cmuclkmsk, vr41xx_cmu_base)
+#define write_cmuclkmsk2()	writew(cmuclkmsk2, VR4133_CMUCLKMSK2)
 
-static u32 vr41xx_cmu_base = 0;
-static u16 cmuclkmsk = 0;
-
-#define write_cmu(mask)	writew((mask), vr41xx_cmu_base)
-
-void vr41xx_clock_supply(u16 mask)
+void vr41xx_clock_supply(unsigned int clock)
 {
-	cmuclkmsk |= mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk |= MSKPIU;
+		break;
+	case SIU_CLOCK:
+		cmuclkmsk |= MSKSIU | MSKSSIU;
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk |= MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk |= MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk |= MSKFIR | MSKFFIR;
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121)
+			cmuclkmsk |= MSKDSIU;
+		else
+			cmuclkmsk |= MSKSIU | MSKDSIU;
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk |= MSKCSI | MSKSCSI;
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk |= MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk |= MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk |= MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 |= MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 |= MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 |= MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void vr41xx_clock_mask(u16 mask)
+void vr41xx_clock_mask(unsigned int clock)
 {
-	cmuclkmsk &= ~mask;
-	write_cmu(cmuclkmsk);
+	switch (clock) {
+	case PIU_CLOCK:
+		cmuclkmsk &= ~MSKPIU;
+		break;
+	case SIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		} else {
+			if (cmuclkmsk & MSKDSIU)
+				cmuclkmsk &= ~MSKSSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKSSIU);
+		}
+		break;
+	case AIU_CLOCK:
+		cmuclkmsk &= ~MSKAIU;
+		break;
+	case KIU_CLOCK:
+		cmuclkmsk &= ~MSKKIU;
+		break;
+	case FIR_CLOCK:
+		cmuclkmsk &= ~(MSKFIR | MSKFFIR);
+		break;
+	case DSIU_CLOCK:
+		if (current_cpu_data.cputype == CPU_VR4111 ||
+		    current_cpu_data.cputype == CPU_VR4121) {
+			cmuclkmsk &= ~MSKDSIU;
+		} else {
+			if (cmuclkmsk & MSKSIU)
+				cmuclkmsk &= ~MSKDSIU;
+			else
+				cmuclkmsk &= ~(MSKSIU | MSKDSIU);
+		}
+		break;
+	case CSI_CLOCK:
+		cmuclkmsk &= ~(MSKCSI | MSKSCSI);
+		break;
+	case PCIU_CLOCK:
+		cmuclkmsk &= ~MSKPCIU;
+		break;
+	case HSP_CLOCK:
+		cmuclkmsk &= ~MSKSHSP;
+		break;
+	case PCI_CLOCK:
+		cmuclkmsk &= ~MSKPPCIU;
+		break;
+	case CEU_CLOCK:
+		cmuclkmsk2 &= ~MSKCEU;
+		break;
+	case ETHER0_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC0;
+		break;
+	case ETHER1_CLOCK:
+		cmuclkmsk2 &= ~MSKMAC1;
+		break;
+	default:
+		break;
+	}
+
+	if (clock == CEU_CLOCK || clock == ETHER0_CLOCK ||
+	    clock == ETHER1_CLOCK)
+		write_cmuclkmsk2();
+	else
+		write_cmuclkmsk();
 }
 
-void __init vr41xx_cmu_init(u16 mask)
+void __init vr41xx_cmu_init(void)
 {
 	switch (current_cpu_data.cputype) {
         case CPU_VR4111:
@@ -75,10 +211,14 @@
         case CPU_VR4131:
                 vr41xx_cmu_base = VR4122_CMUCLKMSK;
                 break;
+        case CPU_VR4133:
+                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+		cmuclkmsk2 = read_cmuclkmsk2();
+                break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
 		break;
         }
 
-	cmuclkmsk = mask;
+	cmuclkmsk = read_cmuclkmsk();
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux.orig/arch/mips/vr41xx/common/giu.c	Sat Apr 19 16:38:35 2003
+++ linux/arch/mips/vr41xx/common/giu.c	Thu Oct 30 23:50:17 2003
@@ -34,6 +34,9 @@
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
  *  - New creation, NEC VR4111, VR4121, VR4122 and VR4131 are supported.
+ *
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -246,6 +249,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_giu_base = VR4122_GIUIOSELL;
 		break;
 	default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux.orig/arch/mips/vr41xx/common/icu.c	Sat Apr 19 16:38:35 2003
+++ linux/arch/mips/vr41xx/common/icu.c	Thu Oct 30 23:50:17 2003
@@ -33,13 +33,14 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
  *  Paul Mundt <lethal@chaoticdreams.org>
  *  - kgdb support.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -290,6 +291,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		vr41xx_icu1_base = VR4122_SYSINT1REG;
 		vr41xx_icu2_base = VR4122_SYSINT2REG;
 		break;
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux.orig/arch/mips/vr41xx/common/serial.c	Fri Apr 11 00:18:03 2003
+++ linux/arch/mips/vr41xx/common/serial.c	Thu Oct 30 23:50:17 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4122 and VR4131 are supported.
  *  - Added support for NEC VR4111 and VR4121.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
 #include <linux/types.h>
@@ -66,7 +67,6 @@
  #define TMICMODE		0x20
 
 #define SIU_BASE_BAUD		1152000
-#define SIU_CLOCK		0x0102
 
 /* VR4122 and VR4131 DSIU Registers */
 #define DSIURB			KSEG1ADDR(0x0f000820)
@@ -75,7 +75,6 @@
  #define INTDSIU		0x0800
 
 #define DSIU_BASE_BAUD		1152000
-#define DSIU_CLOCK		0x0802
 
 int vr41xx_serial_ports = 0;
 
@@ -106,6 +105,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		writew(val, VR4122_SIUIRSEL);
 		break;
 	default:
@@ -133,6 +133,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
 		s.iomem_base = (unsigned char *)VR4122_SIURB;
 		break;
 	default:
@@ -154,7 +155,8 @@
 	struct serial_struct s;
 
 	if (current_cpu_data.cputype != CPU_VR4122 &&
-	    current_cpu_data.cputype != CPU_VR4131)
+	    current_cpu_data.cputype != CPU_VR4131 &&
+	    current_cpu_data.cputype != CPU_VR4133)
 		return;
 
 	memset(&s, 0, sizeof(s));
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/time.c linux/arch/mips/vr41xx/common/time.c
--- linux.orig/arch/mips/vr41xx/common/time.c	Sat Aug 30 01:35:41 2003
+++ linux/arch/mips/vr41xx/common/time.c	Thu Oct 30 23:50:17 2003
@@ -33,10 +33,11 @@
 /*
  * Changes:
  *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
+ *  - New creation, NEC VR4100 series are supported.
  *  - Added support for NEC VR4100 series RTC Unit.
  *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4100 series are supported.
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  - Added support for NEC VR4133.
  */
 #include <linux/config.h>
 #include <linux/interrupt.h>
@@ -69,6 +70,7 @@
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
+	case CPU_VR4133:
                 vr41xx_rtc_base = VR4122_ETIMELREG;
                 break;
         default:
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c	Wed Jul 30 22:36:55 2003
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Thu Oct 30 23:50:17 2003
@@ -62,7 +62,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/setup.c	Sun Oct 26 11:26:40 2003
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Thu Oct 30 23:50:17 2003
@@ -135,7 +135,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Sun Oct 26 11:26:40 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	Thu Oct 30 23:50:17 2003
@@ -103,7 +103,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 
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	Sun Oct 26 11:26:40 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c	Thu Oct 30 23:50:18 2003
@@ -108,7 +108,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Sun Oct 26 11:26:40 2003
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Thu Oct 30 23:50:18 2003
@@ -111,7 +111,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/setup.c	Sun Oct 26 11:26:40 2003
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Thu Oct 30 23:50:18 2003
@@ -111,7 +111,7 @@
 
 	vr41xx_bcu_init();
 
-	vr41xx_cmu_init(0x0102);
+	vr41xx_cmu_init();
 
 #ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/cpu.h linux/include/asm-mips/cpu.h
--- linux.orig/include/asm-mips/cpu.h	Tue Oct 14 12:01:08 2003
+++ linux/include/asm-mips/cpu.h	Thu Oct 30 23:50:18 2003
@@ -101,7 +101,7 @@
 #define PRID_REV_VR4121		0x0060
 #define PRID_REV_VR4122		0x0070
 #define PRID_REV_VR4181A	0x0070	/* Same as VR4122 */
-#define PRID_REV_VR4131		0x0080
+#define PRID_REV_VR4130		0x0080
 
 /*
  * FPU implementation/revision register (CP1 control register 0).
@@ -170,7 +170,8 @@
 #define CPU_SR71000		53
 #define CPU_RM9000		54
 #define CPU_25KF		55
-#define CPU_LAST		55
+#define CPU_VR4133		56
+#define CPU_LAST		56
 
 /*
  * ISA Level encodings
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	Wed Jul 30 22:36:56 2003
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Thu Oct 30 23:50:18 2003
@@ -32,12 +32,15 @@
 #define PRID_VR4181A_REV1_0	0x00000c73
 #define PRID_VR4181A_REV1_1	0x00000c74
 
-/* VR4131 0x00000c80-0x00000c8f */
+/* VR4131 0x00000c80-0x00000c83 */
 #define PRID_VR4131_REV1_2	0x00000c80
 #define PRID_VR4131_REV2_0	0x00000c81
 #define PRID_VR4131_REV2_1	0x00000c82
 #define PRID_VR4131_REV2_2	0x00000c83
 
+/* VR4131 0x00000c84- */
+#define PRID_VR4133		0x00000c84
+
 /*
  * Bus Control Uint
  */
@@ -46,9 +49,25 @@
 /*
  * Clock Mask Unit
  */
-extern void vr41xx_cmu_init(u16 mask);
-extern void vr41xx_clock_supply(u16 mask);
-extern void vr41xx_clock_mask(u16 mask);
+extern void vr41xx_cmu_init(void);
+extern void vr41xx_clock_supply(unsigned int clock);
+extern void vr41xx_clock_mask(unsigned int clock);
+
+enum {
+	PIU_CLOCK,
+	SIU_CLOCK,
+	AIU_CLOCK,
+	KIU_CLOCK,
+	FIR_CLOCK,
+	DSIU_CLOCK,
+	CSI_CLOCK,
+	PCIU_CLOCK,
+	HSP_CLOCK,
+	PCI_CLOCK,
+	CEU_CLOCK,
+	ETHER0_CLOCK,
+	ETHER1_CLOCK
+};
 
 /*
  * Interrupt Control Unit

--Multipart=_Fri__31_Oct_2003_00_16_58_+0900_MB_RW/VX.w/mVD7N--

From raiko@niisi.msk.ru Thu Oct 30 15:32:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Oct 2003 15:33:23 +0000 (GMT)
Received: from [IPv6:::ffff:193.232.173.111] ([IPv6:::ffff:193.232.173.111]:17778
	"EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP
	id <S8225386AbTJ3Pcv>; Thu, 30 Oct 2003 15:32:51 +0000
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.11.7/8.11.7) with ESMTP id h9UGWvv10274
	for <linux-mips@linux-mips.org>; Thu, 30 Oct 2003 19:32:57 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id TAA13558 for linux-mips@linux-mips.org; Thu, 30 Oct 2003 19:33:33 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34])
	by niisi.msk.ru (8.12.5/8.12.5) with ESMTP id h9UEuRXv024057
	for <linux-mips@linux-mips.org>; Thu, 30 Oct 2003 17:56:28 +0300 (MSK)
Message-ID: <3FA12696.9451C832@niisi.msk.ru>
Date: Thu, 30 Oct 2003 17:56:22 +0300
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Packages for RH 7.3/mips
References: <3F9E3315.73155663@niisi.msk.ru> <20031028120311.GA26611@linux-mips.org> <3F9FCD65.B3631FF8@niisi.msk.ru> <20031029143610.GA32317@linux-mips.org> <3FA1121B.CB4A0754@niisi.msk.ru> <20031030143817.GB28106@linux-mips.org>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Return-Path: <raiko@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3557
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: raiko@niisi.msk.ru
Precedence: bulk
X-list: linux-mips

Hello all,

I've uploaded all packages to
ftp.linux-mips.org/pub/linux/mips/redhat/7.3/NIISI/

Regards,
Gleb.

From dkesselr@mmc.atmel.com Thu Oct 30 17:29:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Oct 2003 17:29:23 +0000 (GMT)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:38590
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225458AbTJ3R3V>; Thu, 30 Oct 2003 17:29:21 +0000
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id MAA11104
	for <linux-mips@linux-mips.org>; Thu, 30 Oct 2003 12:29:13 -0500 (EST)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id MAA22126
	for <linux-mips@linux-mips.org>; Thu, 30 Oct 2003 12:29:13 -0500 (EST)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Thu, 30 Oct 2003 12:29:13 -0500 (EST)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: new build failed
Message-ID: <Pine.GSO.4.44.0310301223570.22021-200000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-1067534953=:22021"
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: 3558
X-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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-758783491-1067534953=:22021
Content-Type: TEXT/PLAIN; charset=US-ASCII

I just checked out the latest source from linux-mips and if failed to
compile. Specifically this was a CVS update to a full build I checked out
last month. It shouldn't matter, should it?
Anyway here is the error and the .config file.

mipsel-linux-gcc -D__ASSEMBLY__ -D__KERNEL__
-I/home/dkesselr/stbsw/linux/linux-malta2/include -I
/home/dkesselr/stbsw/linux/linux-malta2/include/asm/gcc -G 0 -mno-abicalls
-fno-pic -pipe   -finline-limit=100000 -mcpu=r4600 -mips2 -Wa,--trap   -c
-o tlbex-mips32.o tlbex-mips32.S
tlbex-mips32.S: Assembler messages:
tlbex-mips32.S:105: Error: Instruction srl requires absolute expression
tlbex-mips32.S:251: Error: Instruction srl requires absolute expression
tlbex-mips32.S:278: Error: Instruction srl requires absolute expression
tlbex-mips32.S:304: Error: Instruction srl requires absolute expression
make[2]: *** [tlbex-mips32.o] Error 1
make[2]: Leaving directory
`/home/dkesselr/stbsw/linux/linux-malta2/arch/mips/mm'
make[1]: *** [first_rule] Error 2


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

---559023410-758783491-1067534953=:22021
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="malta.config"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.44.0310301229130.22021@ares.mmc.atmel.com>
Content-Description: 
Content-Disposition: attachment; filename="malta.config"

Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBieSBtYWtlIG1lbnVjb25m
aWc6IGRvbid0IGVkaXQNCiMNCkNPTkZJR19NSVBTPXkNCkNPTkZJR19NSVBT
MzI9eQ0KIyBDT05GSUdfTUlQUzY0IGlzIG5vdCBzZXQNCg0KIw0KIyBDb2Rl
IG1hdHVyaXR5IGxldmVsIG9wdGlvbnMNCiMNCkNPTkZJR19FWFBFUklNRU5U
QUw9eQ0KDQojDQojIExvYWRhYmxlIG1vZHVsZSBzdXBwb3J0DQojDQpDT05G
SUdfTU9EVUxFUz15DQojIENPTkZJR19NT0RWRVJTSU9OUyBpcyBub3Qgc2V0
DQpDT05GSUdfS01PRD15DQoNCiMNCiMgTWFjaGluZSBzZWxlY3Rpb24NCiMN
CiMgQ09ORklHX0FDRVJfUElDQV82MSBpcyBub3Qgc2V0DQojIENPTkZJR19N
SVBTX0JPU1BPUlVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfTUlSQUdF
IGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfREIxMDAwIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01JUFNfREIxMTAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01J
UFNfREIxNTAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfUEIxMDAwIGlz
IG5vdCBzZXQNCiMgQ09ORklHX01JUFNfUEIxMTAwIGlzIG5vdCBzZXQNCiMg
Q09ORklHX01JUFNfUEIxNTAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNf
SFlEUk9HRU4zIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfWFhTMTUwMCBp
cyBub3Qgc2V0DQojIENPTkZJR19NSVBTX01UWDEgaXMgbm90IHNldA0KIyBD
T05GSUdfQ09HRU5UX0NTQjI1MCBpcyBub3Qgc2V0DQojIENPTkZJR19CQUdF
VF9NSVBTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NBU0lPX0U1NSBpcyBub3Qg
c2V0DQojIENPTkZJR19NSVBTX0NPQkFMVCBpcyBub3Qgc2V0DQojIENPTkZJ
R19ERUNTVEFUSU9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfRVY2NDEy
MCBpcyBub3Qgc2V0DQojIENPTkZJR19NSVBTX0VWOTYxMDAgaXMgbm90IHNl
dA0KIyBDT05GSUdfTUlQU19JVlIgaXMgbm90IHNldA0KIyBDT05GSUdfSFBf
TEFTRVJKRVQgaXMgbm90IHNldA0KIyBDT05GSUdfSUJNX1dPUktQQUQgaXMg
bm90IHNldA0KIyBDT05GSUdfTEFTQVQgaXMgbm90IHNldA0KIyBDT05GSUdf
TUlQU19JVEU4MTcyIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfQVRMQVMg
aXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19NQUdOVU1fNDAwMCBpcyBub3Qg
c2V0DQpDT05GSUdfTUlQU19NQUxUQT15DQojIENPTkZJR19NSVBTX1NFQUQg
aXMgbm90IHNldA0KIyBDT05GSUdfTU9NRU5DT19PQ0VMT1QgaXMgbm90IHNl
dA0KIyBDT05GSUdfTU9NRU5DT19PQ0VMT1RfRyBpcyBub3Qgc2V0DQojIENP
TkZJR19NT01FTkNPX09DRUxPVF9DIGlzIG5vdCBzZXQNCiMgQ09ORklHX01P
TUVOQ09fSkFHVUFSX0FUWCBpcyBub3Qgc2V0DQojIENPTkZJR19EREI1MDc0
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0REQjU0NzYgaXMgbm90IHNldA0KIyBD
T05GSUdfRERCNTQ3NyBpcyBub3Qgc2V0DQojIENPTkZJR19ORUNfT1NQUkVZ
IGlzIG5vdCBzZXQNCiMgQ09ORklHX05FQ19FQUdMRSBpcyBub3Qgc2V0DQoj
IENPTkZJR19PTElWRVRUSV9NNzAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05J
Tk8gaXMgbm90IHNldA0KIyBDT05GSUdfU0dJX0lQMjIgaXMgbm90IHNldA0K
IyBDT05GSUdfU0dJX0lQMjcgaXMgbm90IHNldA0KIyBDT05GSUdfU0lCWVRF
X1NCMXh4eF9TT0MgaXMgbm90IHNldA0KIyBDT05GSUdfU05JX1JNMjAwX1BD
SSBpcyBub3Qgc2V0DQojIENPTkZJR19UQU5CQUNfVEIwMjI2IGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1RBTkJBQ19UQjAyMjkgaXMgbm90IHNldA0KIyBDT05G
SUdfVE9TSElCQV9KTVIzOTI3IGlzIG5vdCBzZXQNCiMgQ09ORklHX1RPU0hJ
QkFfUkJUWDQ5MjcgaXMgbm90IHNldA0KIyBDT05GSUdfVklDVE9SX01QQzMw
WCBpcyBub3Qgc2V0DQojIENPTkZJR19aQU9fQ0FQQ0VMTEEgaXMgbm90IHNl
dA0KIyBDT05GSUdfSElHSE1FTSBpcyBub3Qgc2V0DQpDT05GSUdfUEFHRV9T
SVpFXzRLQj15DQojIENPTkZJR19QQUdFX1NJWkVfMTZLQiBpcyBub3Qgc2V0
DQojIENPTkZJR19QQUdFX1NJWkVfNjRLQiBpcyBub3Qgc2V0DQpDT05GSUdf
UldTRU1fR0VORVJJQ19TUElOTE9DSz15DQojIENPTkZJR19SV1NFTV9YQ0hH
QUREX0FMR09SSVRITSBpcyBub3Qgc2V0DQpDT05GSUdfQk9PVF9FTEYzMj15
DQpDT05GSUdfSEFWRV9TVERfUENfU0VSSUFMX1BPUlQ9eQ0KQ09ORklHX0k4
MjU5PXkNCkNPTkZJR19NSVBTX0JPTklUTzY0PXkNCkNPTkZJR19NSVBTX0dU
NjQxMjA9eQ0KQ09ORklHX01JUFNfTVNDPXkNCkNPTkZJR19MMV9DQUNIRV9T
SElGVD01DQpDT05GSUdfTkVXX1RJTUVfQz15DQpDT05GSUdfTk9OQ09IRVJF
TlRfSU89eQ0KQ09ORklHX1NXQVBfSU9fU1BBQ0VfVz15DQpDT05GSUdfU1dB
UF9JT19TUEFDRV9MPXkNCkNPTkZJR19QQ19LRVlCPXkNCkNPTkZJR19QQ0k9
eQ0KIyBDT05GSUdfTUlQU19BVTEwMDAgaXMgbm90IHNldA0KDQojDQojIENQ
VSBzZWxlY3Rpb24NCiMNCkNPTkZJR19DUFVfTUlQUzMyPXkNCiMgQ09ORklH
X0NQVV9NSVBTNjQgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1IzMDAwIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0NQVV9UWDM5WFggaXMgbm90IHNldA0KIyBD
T05GSUdfQ1BVX1ZSNDFYWCBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfUjQz
MDAgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1I0WDAwIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0NQVV9UWDQ5WFggaXMgbm90IHNldA0KIyBDT05GSUdfQ1BV
X1I1MDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9SNTQzMiBpcyBub3Qg
c2V0DQojIENPTkZJR19DUFVfUjYwMDAgaXMgbm90IHNldA0KIyBDT05GSUdf
Q1BVX05FVkFEQSBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfUjgwMDAgaXMg
bm90IHNldA0KIyBDT05GSUdfQ1BVX1IxMDAwMCBpcyBub3Qgc2V0DQojIENP
TkZJR19DUFVfUk03MDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9STTkw
MDAgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1NCMSBpcyBub3Qgc2V0DQpD
T05GSUdfQ1BVX0hBU19QUkVGRVRDSD15DQojIENPTkZJR19WVEFHX0lDQUNI
RSBpcyBub3Qgc2V0DQojIENPTkZJR182NEJJVF9QSFlTX0FERFIgaXMgbm90
IHNldA0KIyBDT05GSUdfQ1BVX0FEVkFOQ0VEIGlzIG5vdCBzZXQNCkNPTkZJ
R19DUFVfSEFTX0xMU0M9eQ0KIyBDT05GSUdfQ1BVX0hBU19MTERTQ0QgaXMg
bm90IHNldA0KIyBDT05GSUdfQ1BVX0hBU19XQiBpcyBub3Qgc2V0DQpDT05G
SUdfQ1BVX0hBU19TWU5DPXkNCg0KIw0KIyBHZW5lcmFsIHNldHVwDQojDQpD
T05GSUdfQ1BVX0xJVFRMRV9FTkRJQU49eQ0KIyBDT05GSUdfQVJDX0NPTlNP
TEUgaXMgbm90IHNldA0KQ09ORklHX05FVD15DQpDT05GSUdfUENJX05BTUVT
PXkNCiMgQ09ORklHX0lTQSBpcyBub3Qgc2V0DQojIENPTkZJR19UQyBpcyBu
b3Qgc2V0DQojIENPTkZJR19NQ0EgaXMgbm90IHNldA0KIyBDT05GSUdfU0JV
UyBpcyBub3Qgc2V0DQojIENPTkZJR19IT1RQTFVHIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1BDTUNJQSBpcyBub3Qgc2V0DQojIENPTkZJR19IT1RQTFVHX1BD
SSBpcyBub3Qgc2V0DQpDT05GSUdfU1lTVklQQz15DQojIENPTkZJR19CU0Rf
UFJPQ0VTU19BQ0NUIGlzIG5vdCBzZXQNCkNPTkZJR19TWVNDVEw9eQ0KQ09O
RklHX0tDT1JFX0VMRj15DQojIENPTkZJR19LQ09SRV9BT1VUIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0JJTkZNVF9BT1VUIGlzIG5vdCBzZXQNCkNPTkZJR19C
SU5GTVRfRUxGPXkNCiMgQ09ORklHX01JUFMzMl9DT01QQVQgaXMgbm90IHNl
dA0KIyBDT05GSUdfTUlQUzMyX08zMiBpcyBub3Qgc2V0DQojIENPTkZJR19N
SVBTMzJfTjMyIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JJTkZNVF9FTEYzMiBp
cyBub3Qgc2V0DQpDT05GSUdfQklORk1UX01JU0M9eQ0KDQojDQojIE1lbW9y
eSBUZWNobm9sb2d5IERldmljZXMgKE1URCkNCiMNCiMgQ09ORklHX01URCBp
cyBub3Qgc2V0DQoNCiMNCiMgUGFyYWxsZWwgcG9ydCBzdXBwb3J0DQojDQoj
IENPTkZJR19QQVJQT1JUIGlzIG5vdCBzZXQNCg0KIw0KIyBQbHVnIGFuZCBQ
bGF5IGNvbmZpZ3VyYXRpb24NCiMNCiMgQ09ORklHX1BOUCBpcyBub3Qgc2V0
DQojIENPTkZJR19JU0FQTlAgaXMgbm90IHNldA0KDQojDQojIEJsb2NrIGRl
dmljZXMNCiMNCkNPTkZJR19CTEtfREVWX0ZEPXkNCiMgQ09ORklHX0JMS19E
RVZfWEQgaXMgbm90IHNldA0KIyBDT05GSUdfUEFSSURFIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0JMS19DUFFfREEgaXMgbm90IHNldA0KIyBDT05GSUdfQkxL
X0NQUV9DSVNTX0RBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NJU1NfU0NTSV9U
QVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfREFDOTYwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfVU1FTSBpcyBub3Qgc2V0DQojIENP
TkZJR19CTEtfREVWX0xPT1AgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RF
Vl9OQkQgaXMgbm90IHNldA0KQ09ORklHX0JMS19ERVZfUkFNPXkNCkNPTkZJ
R19CTEtfREVWX1JBTV9TSVpFPTQwOTYNCiMgQ09ORklHX0JMS19ERVZfSU5J
VFJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19TVEFUUyBpcyBub3Qgc2V0
DQoNCiMNCiMgTXVsdGktZGV2aWNlIHN1cHBvcnQgKFJBSUQgYW5kIExWTSkN
CiMNCiMgQ09ORklHX01EIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf
TUQgaXMgbm90IHNldA0KIyBDT05GSUdfTURfTElORUFSIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01EX1JBSUQwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01EX1JB
SUQxIGlzIG5vdCBzZXQNCiMgQ09ORklHX01EX1JBSUQ1IGlzIG5vdCBzZXQN
CiMgQ09ORklHX01EX01VTFRJUEFUSCBpcyBub3Qgc2V0DQojIENPTkZJR19C
TEtfREVWX0xWTSBpcyBub3Qgc2V0DQoNCiMNCiMgTmV0d29ya2luZyBvcHRp
b25zDQojDQpDT05GSUdfUEFDS0VUPXkNCkNPTkZJR19QQUNLRVRfTU1BUD15
DQojIENPTkZJR19ORVRMSU5LX0RFViBpcyBub3Qgc2V0DQojIENPTkZJR19O
RVRGSUxURVIgaXMgbm90IHNldA0KIyBDT05GSUdfRklMVEVSIGlzIG5vdCBz
ZXQNCkNPTkZJR19VTklYPXkNCkNPTkZJR19JTkVUPXkNCiMgQ09ORklHX0lQ
X01VTFRJQ0FTVCBpcyBub3Qgc2V0DQojIENPTkZJR19JUF9BRFZBTkNFRF9S
T1VURVIgaXMgbm90IHNldA0KQ09ORklHX0lQX1BOUD15DQpDT05GSUdfSVBf
UE5QX0RIQ1A9eQ0KQ09ORklHX0lQX1BOUF9CT09UUD15DQojIENPTkZJR19J
UF9QTlBfUkFSUCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfSVBJUCBpcyBu
b3Qgc2V0DQojIENPTkZJR19ORVRfSVBHUkUgaXMgbm90IHNldA0KIyBDT05G
SUdfQVJQRCBpcyBub3Qgc2V0DQojIENPTkZJR19JTkVUX0VDTiBpcyBub3Qg
c2V0DQojIENPTkZJR19TWU5fQ09PS0lFUyBpcyBub3Qgc2V0DQojIENPTkZJ
R19JUFY2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0tIVFRQRCBpcyBub3Qgc2V0
DQojIENPTkZJR19BVE0gaXMgbm90IHNldA0KIyBDT05GSUdfVkxBTl84MDIx
USBpcyBub3Qgc2V0DQojIENPTkZJR19JUFggaXMgbm90IHNldA0KIyBDT05G
SUdfQVRBTEsgaXMgbm90IHNldA0KDQojDQojIEFwcGxldGFsayBkZXZpY2Vz
DQojDQojIENPTkZJR19ERVZfQVBQTEVUQUxLIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0RFQ05FVCBpcyBub3Qgc2V0DQojIENPTkZJR19CUklER0UgaXMgbm90
IHNldA0KIyBDT05GSUdfWDI1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0xBUEIg
aXMgbm90IHNldA0KIyBDT05GSUdfTExDIGlzIG5vdCBzZXQNCiMgQ09ORklH
X05FVF9ESVZFUlQgaXMgbm90IHNldA0KIyBDT05GSUdfRUNPTkVUIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1dBTl9ST1VURVIgaXMgbm90IHNldA0KIyBDT05G
SUdfTkVUX0ZBU1RST1VURSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfSFdf
RkxPV0NPTlRST0wgaXMgbm90IHNldA0KDQojDQojIFFvUyBhbmQvb3IgZmFp
ciBxdWV1ZWluZw0KIw0KIyBDT05GSUdfTkVUX1NDSEVEIGlzIG5vdCBzZXQN
Cg0KIw0KIyBOZXR3b3JrIHRlc3RpbmcNCiMNCiMgQ09ORklHX05FVF9QS1RH
RU4gaXMgbm90IHNldA0KDQojDQojIFRlbGVwaG9ueSBTdXBwb3J0DQojDQoj
IENPTkZJR19QSE9ORSBpcyBub3Qgc2V0DQojIENPTkZJR19QSE9ORV9JWEog
aXMgbm90IHNldA0KIyBDT05GSUdfUEhPTkVfSVhKX1BDTUNJQSBpcyBub3Qg
c2V0DQoNCiMNCiMgQVRBL0lERS9NRk0vUkxMIHN1cHBvcnQNCiMNCkNPTkZJ
R19JREU9eQ0KDQojDQojIElERSwgQVRBIGFuZCBBVEFQSSBCbG9jayBkZXZp
Y2VzDQojDQpDT05GSUdfQkxLX0RFVl9JREU9eQ0KIyBDT05GSUdfQkxLX0RF
Vl9IRF9JREUgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9IRCBpcyBu
b3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9JREVESVNLPXkNCiMgQ09ORklHX0lE
RURJU0tfTVVMVElfTU9ERSBpcyBub3Qgc2V0DQojIENPTkZJR19JREVESVNL
X1NUUk9LRSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0lERUNTIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSURFQ0QgaXMgbm90IHNldA0K
IyBDT05GSUdfQkxLX0RFVl9JREVUQVBFIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0JMS19ERVZfSURFRkxPUFBZIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19E
RVZfSURFU0NTSSBpcyBub3Qgc2V0DQojIENPTkZJR19JREVfVEFTS19JT0NU
TCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0NNRDY0MCBpcyBub3Qg
c2V0DQojIENPTkZJR19CTEtfREVWX0NNRDY0MF9FTkhBTkNFRCBpcyBub3Qg
c2V0DQojIENPTkZJR19CTEtfREVWX0lTQVBOUCBpcyBub3Qgc2V0DQpDT05G
SUdfQkxLX0RFVl9JREVQQ0k9eQ0KQ09ORklHX0JMS19ERVZfR0VORVJJQz15
DQpDT05GSUdfSURFUENJX1NIQVJFX0lSUT15DQpDT05GSUdfQkxLX0RFVl9J
REVETUFfUENJPXkNCiMgQ09ORklHX0JMS19ERVZfT0ZGQk9BUkQgaXMgbm90
IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JREVETUFfRk9SQ0VEIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0lERURNQV9QQ0lfQVVUTyBpcyBub3Qgc2V0DQojIENP
TkZJR19JREVETUFfT05MWURJU0sgaXMgbm90IHNldA0KQ09ORklHX0JMS19E
RVZfSURFRE1BPXkNCiMgQ09ORklHX0lERURNQV9QQ0lfV0lQIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0JMS19ERVZfQURNQTEwMCBpcyBub3Qgc2V0DQojIENP
TkZJR19CTEtfREVWX0FFQzYyWFggaXMgbm90IHNldA0KIyBDT05GSUdfQkxL
X0RFVl9BTEkxNVgzIGlzIG5vdCBzZXQNCiMgQ09ORklHX1dEQ19BTEkxNVgz
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQU1ENzRYWCBpcyBub3Qg
c2V0DQojIENPTkZJR19BTUQ3NFhYX09WRVJSSURFIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0JMS19ERVZfQ01ENjRYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM
S19ERVZfVFJJRkxFWCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0NZ
ODJDNjkzIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQ1M1NTMwIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSFBUMzRYIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0hQVDM0WF9BVVRPRE1BIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0JMS19ERVZfSFBUMzY2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf
UElJWCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX05TODc0MTUgaXMg
bm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9PUFRJNjIxIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0JMS19ERVZfUERDMjAyWFhfT0xEIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1BEQzIwMlhYX0JVUlNUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM
S19ERVZfUERDMjAyWFhfTkVXIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19E
RVZfUloxMDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfU0MxMjAw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfU1ZXS1MgaXMgbm90IHNl
dA0KIyBDT05GSUdfQkxLX0RFVl9TSUlNQUdFIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0JMS19ERVZfU0lTNTUxMyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf
REVWX1NMQzkwRTY2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfVFJN
MjkwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfVklBODJDWFhYIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0lERV9DSElQU0VUUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19JREVETUFfQVVUTyBpcyBub3Qgc2V0DQojIENPTkZJR19JREVE
TUFfSVZCIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RNQV9OT05QQ0kgaXMgbm90
IHNldA0KQ09ORklHX0JMS19ERVZfSURFX01PREVTPXkNCiMgQ09ORklHX0JM
S19ERVZfQVRBUkFJRCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0FU
QVJBSURfUERDIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQVRBUkFJ
RF9IUFQgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9BVEFSQUlEX1NJ
SSBpcyBub3Qgc2V0DQoNCiMNCiMgU0NTSSBzdXBwb3J0DQojDQojIENPTkZJ
R19TQ1NJIGlzIG5vdCBzZXQNCg0KIw0KIyBJMk8gZGV2aWNlIHN1cHBvcnQN
CiMNCiMgQ09ORklHX0kyTyBpcyBub3Qgc2V0DQojIENPTkZJR19JMk9fUENJ
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0kyT19CTE9DSyBpcyBub3Qgc2V0DQoj
IENPTkZJR19JMk9fTEFOIGlzIG5vdCBzZXQNCiMgQ09ORklHX0kyT19TQ1NJ
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0kyT19QUk9DIGlzIG5vdCBzZXQNCg0K
Iw0KIyBOZXR3b3JrIGRldmljZSBzdXBwb3J0DQojDQpDT05GSUdfTkVUREVW
SUNFUz15DQoNCiMNCiMgQVJDbmV0IGRldmljZXMNCiMNCiMgQ09ORklHX0FS
Q05FVCBpcyBub3Qgc2V0DQojIENPTkZJR19EVU1NWSBpcyBub3Qgc2V0DQoj
IENPTkZJR19CT05ESU5HIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VRVUFMSVpF
UiBpcyBub3Qgc2V0DQojIENPTkZJR19UVU4gaXMgbm90IHNldA0KIyBDT05G
SUdfRVRIRVJUQVAgaXMgbm90IHNldA0KDQojDQojIEV0aGVybmV0ICgxMCBv
ciAxMDBNYml0KQ0KIw0KQ09ORklHX05FVF9FVEhFUk5FVD15DQojIENPTkZJ
R19TVU5MQU5DRSBpcyBub3Qgc2V0DQojIENPTkZJR19IQVBQWU1FQUwgaXMg
bm90IHNldA0KIyBDT05GSUdfU1VOQk1BQyBpcyBub3Qgc2V0DQojIENPTkZJ
R19TVU5RRSBpcyBub3Qgc2V0DQojIENPTkZJR19TVU5HRU0gaXMgbm90IHNl
dA0KIyBDT05GSUdfTkVUX1ZFTkRPUl8zQ09NIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0xBTkNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9WRU5ET1JfU01D
IGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9WRU5ET1JfUkFDQUwgaXMgbm90
IHNldA0KIyBDT05GSUdfSFAxMDAgaXMgbm90IHNldA0KIyBDT05GSUdfTkVU
X0lTQSBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX1BDST15DQpDT05GSUdfUENO
RVQzMj15DQojIENPTkZJR19BTUQ4MTExX0VUSCBpcyBub3Qgc2V0DQojIENP
TkZJR19BREFQVEVDX1NUQVJGSVJFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FQ
UklDT1QgaXMgbm90IHNldA0KIyBDT05GSUdfQjQ0IGlzIG5vdCBzZXQNCiMg
Q09ORklHX0NTODl4MCBpcyBub3Qgc2V0DQojIENPTkZJR19UVUxJUCBpcyBu
b3Qgc2V0DQojIENPTkZJR19ERTRYNSBpcyBub3Qgc2V0DQojIENPTkZJR19E
R1JTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RNOTEwMiBpcyBub3Qgc2V0DQoj
IENPTkZJR19FRVBSTzEwMCBpcyBub3Qgc2V0DQojIENPTkZJR19FRVBSTzEw
MF9QSU8gaXMgbm90IHNldA0KIyBDT05GSUdfRTEwMCBpcyBub3Qgc2V0DQoj
IENPTkZJR19MTkUzOTAgaXMgbm90IHNldA0KIyBDT05GSUdfRkVBTE5YIGlz
IG5vdCBzZXQNCiMgQ09ORklHX05BVFNFTUkgaXMgbm90IHNldA0KIyBDT05G
SUdfTkUyS19QQ0kgaXMgbm90IHNldA0KIyBDT05GSUdfTkUzMjEwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0VTMzIxMCBpcyBub3Qgc2V0DQojIENPTkZJR184
MTM5Q1AgaXMgbm90IHNldA0KIyBDT05GSUdfODEzOVRPTyBpcyBub3Qgc2V0
DQojIENPTkZJR184MTM5VE9PX1BJTyBpcyBub3Qgc2V0DQojIENPTkZJR184
MTM5VE9PX1RVTkVfVFdJU1RFUiBpcyBub3Qgc2V0DQojIENPTkZJR184MTM5
VE9PXzgxMjkgaXMgbm90IHNldA0KIyBDT05GSUdfODEzOV9PTERfUlhfUkVT
RVQgaXMgbm90IHNldA0KIyBDT05GSUdfU0lTOTAwIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0VQSUMxMDAgaXMgbm90IHNldA0KIyBDT05GSUdfU1VOREFOQ0Ug
aXMgbm90IHNldA0KIyBDT05GSUdfU1VOREFOQ0VfTU1JTyBpcyBub3Qgc2V0
DQojIENPTkZJR19UTEFOIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJQV9SSElO
RSBpcyBub3Qgc2V0DQojIENPTkZJR19WSUFfUkhJTkVfTU1JTyBpcyBub3Qg
c2V0DQojIENPTkZJR19XSU5CT05EXzg0MCBpcyBub3Qgc2V0DQojIENPTkZJ
R19MQU5fU0FBOTczMCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfUE9DS0VU
IGlzIG5vdCBzZXQNCg0KIw0KIyBFdGhlcm5ldCAoMTAwMCBNYml0KQ0KIw0K
IyBDT05GSUdfQUNFTklDIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RMMksgaXMg
bm90IHNldA0KIyBDT05GSUdfRTEwMDAgaXMgbm90IHNldA0KIyBDT05GSUdf
TVlSSV9TQlVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX05TODM4MjAgaXMgbm90
IHNldA0KIyBDT05GSUdfSEFNQUNISSBpcyBub3Qgc2V0DQojIENPTkZJR19Z
RUxMT1dGSU4gaXMgbm90IHNldA0KIyBDT05GSUdfUjgxNjkgaXMgbm90IHNl
dA0KIyBDT05GSUdfU0s5OExJTiBpcyBub3Qgc2V0DQojIENPTkZJR19USUdP
TjMgaXMgbm90IHNldA0KIyBDT05GSUdfRkRESSBpcyBub3Qgc2V0DQojIENP
TkZJR19ISVBQSSBpcyBub3Qgc2V0DQojIENPTkZJR19QTElQIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1BQUCBpcyBub3Qgc2V0DQojIENPTkZJR19TTElQIGlz
IG5vdCBzZXQNCg0KIw0KIyBXaXJlbGVzcyBMQU4gKG5vbi1oYW1yYWRpbykN
CiMNCkNPTkZJR19ORVRfUkFESU89eQ0KIyBDT05GSUdfU1RSSVAgaXMgbm90
IHNldA0KIyBDT05GSUdfV0FWRUxBTiBpcyBub3Qgc2V0DQojIENPTkZJR19B
UkxBTiBpcyBub3Qgc2V0DQojIENPTkZJR19BSVJPTkVUNDUwMCBpcyBub3Qg
c2V0DQojIENPTkZJR19BSVJPTkVUNDUwMF9OT05DUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19BSVJPTkVUNDUwMF9QUk9DIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0FJUk8gaXMgbm90IHNldA0KIyBDT05GSUdfSEVSTUVTIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1BMWF9IRVJNRVMgaXMgbm90IHNldA0KIyBDT05GSUdfUENJ
X0hFUk1FUyBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX1dJUkVMRVNTPXkNCg0K
Iw0KIyBUb2tlbiBSaW5nIGRldmljZXMNCiMNCiMgQ09ORklHX1RSIGlzIG5v
dCBzZXQNCiMgQ09ORklHX05FVF9GQyBpcyBub3Qgc2V0DQojIENPTkZJR19S
Q1BDSSBpcyBub3Qgc2V0DQojIENPTkZJR19TSEFQRVIgaXMgbm90IHNldA0K
DQojDQojIFdhbiBpbnRlcmZhY2VzDQojDQojIENPTkZJR19XQU4gaXMgbm90
IHNldA0KDQojDQojIEFtYXRldXIgUmFkaW8gc3VwcG9ydA0KIw0KIyBDT05G
SUdfSEFNUkFESU8gaXMgbm90IHNldA0KDQojDQojIElyREEgKGluZnJhcmVk
KSBzdXBwb3J0DQojDQojIENPTkZJR19JUkRBIGlzIG5vdCBzZXQNCg0KIw0K
IyBJU0ROIHN1YnN5c3RlbQ0KIw0KIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0
DQoNCiMNCiMgSW5wdXQgY29yZSBzdXBwb3J0DQojDQojIENPTkZJR19JTlBV
VCBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9LRVlCREVWIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0lOUFVUX01PVVNFREVWIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0lOUFVUX0pPWURFViBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9F
VkRFViBpcyBub3Qgc2V0DQoNCiMNCiMgQ2hhcmFjdGVyIGRldmljZXMNCiMN
CiMgQ09ORklHX1ZUIGlzIG5vdCBzZXQNCkNPTkZJR19TRVJJQUw9eQ0KQ09O
RklHX1NFUklBTF9DT05TT0xFPXkNCiMgQ09ORklHX1NFUklBTF9FWFRFTkRF
RCBpcyBub3Qgc2V0DQojIENPTkZJR19TRVJJQUxfTk9OU1RBTkRBUkQgaXMg
bm90IHNldA0KQ09ORklHX1VOSVg5OF9QVFlTPXkNCkNPTkZJR19VTklYOThf
UFRZX0NPVU5UPTI1Ng0KDQojDQojIEkyQyBzdXBwb3J0DQojDQojIENPTkZJ
R19JMkMgaXMgbm90IHNldA0KDQojDQojIE1pY2UNCiMNCiMgQ09ORklHX0JV
U01PVVNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX01PVVNFIGlzIG5vdCBzZXQN
Cg0KIw0KIyBKb3lzdGlja3MNCiMNCiMgQ09ORklHX0lOUFVUX0dBTUVQT1JU
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1FJQzAyX1RBUEUgaXMgbm90IHNldA0K
IyBDT05GSUdfSVBNSV9IQU5ETEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQ
TUlfUEFOSUNfRVZFTlQgaXMgbm90IHNldA0KIyBDT05GSUdfSVBNSV9ERVZJ
Q0VfSU5URVJGQUNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQTUlfS0NTIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0lQTUlfV0FUQ0hET0cgaXMgbm90IHNldA0K
DQojDQojIFdhdGNoZG9nIENhcmRzDQojDQojIENPTkZJR19XQVRDSERPRyBp
cyBub3Qgc2V0DQojIENPTkZJR19TQ3gyMDBfR1BJTyBpcyBub3Qgc2V0DQoj
IENPTkZJR19BTURfUE03NjggaXMgbm90IHNldA0KIyBDT05GSUdfTlZSQU0g
aXMgbm90IHNldA0KQ09ORklHX1JUQz15DQojIENPTkZJR19NSVBTX1JUQyBp
cyBub3Qgc2V0DQojIENPTkZJR19EUzE3NDIgaXMgbm90IHNldA0KIyBDT05G
SUdfRFRMSyBpcyBub3Qgc2V0DQojIENPTkZJR19SMzk2NCBpcyBub3Qgc2V0
DQojIENPTkZJR19BUFBMSUNPTSBpcyBub3Qgc2V0DQoNCiMNCiMgRnRhcGUs
IHRoZSBmbG9wcHkgdGFwZSBkZXZpY2UgZHJpdmVyDQojDQojIENPTkZJR19G
VEFQRSBpcyBub3Qgc2V0DQojIENPTkZJR19BR1AgaXMgbm90IHNldA0KIyBD
T05GSUdfRFJNIGlzIG5vdCBzZXQNCg0KIw0KIyBGaWxlIHN5c3RlbXMNCiMN
CiMgQ09ORklHX1FVT1RBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1FGTVRfVjIg
aXMgbm90IHNldA0KQ09ORklHX0FVVE9GU19GUz15DQojIENPTkZJR19BVVRP
RlM0X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFSVNFUkZTX0ZTIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1JFSVNFUkZTX0NIRUNLIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1JFSVNFUkZTX1BST0NfSU5GTyBpcyBub3Qgc2V0DQojIENPTkZJ
R19BREZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FERlNfRlNfUlcgaXMg
bm90IHNldA0KIyBDT05GSUdfQUZGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJ
R19IRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfSEZTUExVU19GUyBpcyBu
b3Qgc2V0DQojIENPTkZJR19CRUZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0JFRlNfREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfQkZTX0ZTIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0VYVDNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdf
SkJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0pCRF9ERUJVRyBpcyBub3Qgc2V0
DQojIENPTkZJR19GQVRfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfTVNET1Nf
RlMgaXMgbm90IHNldA0KIyBDT05GSUdfVU1TRE9TX0ZTIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1ZGQVRfRlMgaXMgbm90IHNldA0KQ09ORklHX0VGU19GUz15
DQojIENPTkZJR19KRkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0pGRlMy
X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSQU1GUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19UTVBGUyBpcyBub3Qgc2V0DQpDT05GSUdfUkFNRlM9eQ0KIyBD
T05GSUdfSVNPOTY2MF9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19KT0xJRVQg
aXMgbm90IHNldA0KIyBDT05GSUdfWklTT0ZTIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0pGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19KRlNfREVCVUcgaXMg
bm90IHNldA0KIyBDT05GSUdfSkZTX1NUQVRJU1RJQ1MgaXMgbm90IHNldA0K
IyBDT05GSUdfTUlOSVhfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfVlhGU19G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19OVEZTX0ZTIGlzIG5vdCBzZXQNCiMg
Q09ORklHX05URlNfUlcgaXMgbm90IHNldA0KIyBDT05GSUdfSFBGU19GUyBp
cyBub3Qgc2V0DQpDT05GSUdfUFJPQ19GUz15DQojIENPTkZJR19ERVZGU19G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19ERVZGU19NT1VOVCBpcyBub3Qgc2V0
DQojIENPTkZJR19ERVZGU19ERUJVRyBpcyBub3Qgc2V0DQpDT05GSUdfREVW
UFRTX0ZTPXkNCiMgQ09ORklHX1FOWDRGU19GUyBpcyBub3Qgc2V0DQojIENP
TkZJR19RTlg0RlNfUlcgaXMgbm90IHNldA0KIyBDT05GSUdfUk9NRlNfRlMg
aXMgbm90IHNldA0KQ09ORklHX0VYVDJfRlM9eQ0KIyBDT05GSUdfU1lTVl9G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19VREZfRlMgaXMgbm90IHNldA0KIyBD
T05GSUdfVURGX1JXIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VGU19GUyBpcyBu
b3Qgc2V0DQojIENPTkZJR19VRlNfRlNfV1JJVEUgaXMgbm90IHNldA0KDQoj
DQojIE5ldHdvcmsgRmlsZSBTeXN0ZW1zDQojDQojIENPTkZJR19DT0RBX0ZT
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOVEVSTUVaWk9fRlMgaXMgbm90IHNl
dA0KQ09ORklHX05GU19GUz15DQpDT05GSUdfTkZTX1YzPXkNCiMgQ09ORklH
X05GU19ESVJFQ1RJTyBpcyBub3Qgc2V0DQpDT05GSUdfUk9PVF9ORlM9eQ0K
Q09ORklHX05GU0Q9eQ0KQ09ORklHX05GU0RfVjM9eQ0KIyBDT05GSUdfTkZT
RF9UQ1AgaXMgbm90IHNldA0KQ09ORklHX1NVTlJQQz15DQpDT05GSUdfTE9D
S0Q9eQ0KQ09ORklHX0xPQ0tEX1Y0PXkNCiMgQ09ORklHX1NNQl9GUyBpcyBu
b3Qgc2V0DQojIENPTkZJR19OQ1BfRlMgaXMgbm90IHNldA0KIyBDT05GSUdf
TkNQRlNfUEFDS0VUX1NJR05JTkcgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQ
RlNfSU9DVExfTE9DS0lORyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BGU19T
VFJPTkcgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQRlNfTkZTX05TIGlzIG5v
dCBzZXQNCiMgQ09ORklHX05DUEZTX09TMl9OUyBpcyBub3Qgc2V0DQojIENP
TkZJR19OQ1BGU19TTUFMTERPUyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BG
U19OTFMgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQRlNfRVhUUkFTIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1pJU09GU19GUyBpcyBub3Qgc2V0DQoNCiMNCiMg
UGFydGl0aW9uIFR5cGVzDQojDQojIENPTkZJR19QQVJUSVRJT05fQURWQU5D
RUQgaXMgbm90IHNldA0KQ09ORklHX01TRE9TX1BBUlRJVElPTj15DQojIENP
TkZJR19TTUJfTkxTIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MUyBpcyBub3Qg
c2V0DQoNCiMNCiMgTXVsdGltZWRpYSBkZXZpY2VzDQojDQojIENPTkZJR19W
SURFT19ERVYgaXMgbm90IHNldA0KDQojDQojIFNvdW5kDQojDQojIENPTkZJ
R19TT1VORCBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIHN1cHBvcnQNCiMNCiMg
Q09ORklHX1VTQiBpcyBub3Qgc2V0DQoNCiMNCiMgQmx1ZXRvb3RoIHN1cHBv
cnQNCiMNCiMgQ09ORklHX0JMVUVaIGlzIG5vdCBzZXQNCg0KIw0KIyBLZXJu
ZWwgaGFja2luZw0KIw0KQ09ORklHX0NST1NTQ09NUElMRT15DQpDT05GSUdf
UlVOVElNRV9ERUJVRz15DQojIENPTkZJR19LR0RCIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0dEQl9DT05TT0xFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQlVH
X0lORk8gaXMgbm90IHNldA0KIyBDT05GSUdfTUFHSUNfU1lTUlEgaXMgbm90
IHNldA0KIyBDT05GSUdfTUlQU19VTkNBQ0hFRCBpcyBub3Qgc2V0DQoNCiMN
CiMgQ3J5cHRvZ3JhcGhpYyBvcHRpb25zDQojDQojIENPTkZJR19DUllQVE8g
aXMgbm90IHNldA0KDQojDQojIExpYnJhcnkgcm91dGluZXMNCiMNCkNPTkZJ
R19DUkMzMj15DQpDT05GSUdfWkxJQl9JTkZMQVRFPXkNCkNPTkZJR19aTElC
X0RFRkxBVEU9eQ0K
---559023410-758783491-1067534953=:22021--

From ralf@linux-mips.org Fri Oct 31 00:51:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Oct 2003 00:51:27 +0000 (GMT)
Received: from p508B4F8C.dip.t-dialin.net ([IPv6:::ffff:80.139.79.140]:7552
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225460AbTJaAvZ>; Fri, 31 Oct 2003 00:51:25 +0000
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 h9V0pONK011613;
	Fri, 31 Oct 2003 01:51:24 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h9V0pMev011612;
	Fri, 31 Oct 2003 01:51:22 +0100
Date: Fri, 31 Oct 2003 01:51:22 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: new build failed
Message-ID: <20031031005122.GE803@linux-mips.org>
References: <Pine.GSO.4.44.0310301223570.22021-200000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0310301223570.22021-200000@ares.mmc.atmel.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3559
X-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, Oct 30, 2003 at 12:29:13PM -0500, David Kesselring wrote:

> I just checked out the latest source from linux-mips and if failed to
> compile. Specifically this was a CVS update to a full build I checked out
> last month. It shouldn't matter, should it?
> Anyway here is the error and the .config file.

Ah, the one configuration I missed to test ...  Fix below,

  Ralf

Index: arch/mips/mm/tlbex-mips32.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/Attic/tlbex-mips32.S,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 tlbex-mips32.S
--- arch/mips/mm/tlbex-mips32.S	28 Mar 2003 19:29:53 -0000	1.1.2.1
+++ arch/mips/mm/tlbex-mips32.S	31 Oct 2003 00:51:06 -0000
@@ -102,7 +102,7 @@
 #endif	
 	nop
 	mfc0	k0, CP0_BADVADDR		# Get faulting address
-	srl	k0, k0, PGDIR_SHIFT		# get pgd only bits
+	srl	k0, k0, _PGDIR_SHIFT		# get pgd only bits
 
 	sll	k0, k0, 2
 	addu	k1, k1, k0			# add in pgd offset
@@ -168,7 +168,7 @@
 #define LOAD_PTE(pte, ptr) \
 	GET_PGD(pte, ptr)          \
 	mfc0	pte, CP0_BADVADDR; \
-	srl	pte, pte, PGDIR_SHIFT; \
+	srl	pte, pte, _PGDIR_SHIFT; \
 	sll	pte, pte, 2; \
 	addu	ptr, ptr, pte; \
 	mfc0	pte, CP0_BADVADDR; \

From dkesselr@mmc.atmel.com Fri Oct 31 19:25:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Oct 2003 19:25:38 +0000 (GMT)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:3448
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225309AbTJaTZg>; Fri, 31 Oct 2003 19:25:36 +0000
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id OAA28225
	for <linux-mips@linux-mips.org>; Fri, 31 Oct 2003 14:25:18 -0500 (EST)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id OAA22918
	for <linux-mips@linux-mips.org>; Fri, 31 Oct 2003 14:25:16 -0500 (EST)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Fri, 31 Oct 2003 14:25:16 -0500 (EST)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: latest build - xconfig
Message-ID: <Pine.GSO.4.44.0310311420480.22698-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3560
X-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

It seems like xconfig is broken on the code currently in cvs.
./tkparse < ../arch/mips/config.in >> kconfig.tk
arch/mips/config-shared.in: 894: can't handle
dep_bool/dep_mbool/dep_tristate condition
make[1]: *** [kconfig.tk] Error 1

Hope this helps somebody.

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


From sjhill@realitydiluted.com Fri Oct 31 19:49:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Oct 2003 19:49:26 +0000 (GMT)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:61853
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225352AbTJaTtO>; Fri, 31 Oct 2003 19:49:14 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1AFfGX-0007l7-00; Fri, 31 Oct 2003 13:49:01 -0600
Message-ID: <3FA2BCA5.6070604@realitydiluted.com>
Date: Fri, 31 Oct 2003 14:48:53 -0500
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031024 Debian/1.5-2
X-Accept-Language: en
MIME-Version: 1.0
To: David Kesselring <dkesselr@mmc.atmel.com>
CC: linux-mips@linux-mips.org
Subject: Re: latest build - xconfig
References: <Pine.GSO.4.44.0310311420480.22698-100000@ares.mmc.atmel.com>
In-Reply-To: <Pine.GSO.4.44.0310311420480.22698-100000@ares.mmc.atmel.com>
Content-Type: multipart/mixed;
 boundary="------------030003030004090309030609"
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3561
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips

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

David Kesselring wrote:
> It seems like xconfig is broken on the code currently in cvs.
> ./tkparse < ../arch/mips/config.in >> kconfig.tk
> arch/mips/config-shared.in: 894: can't handle
> dep_bool/dep_mbool/dep_tristate condition
> make[1]: *** [kconfig.tk] Error 1
> 
I just checked in the fix. Here's the patch too for reference.

-Steve

--------------030003030004090309030609
Content-Type: text/plain;
 name="eisa-xconfig.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="eisa-xconfig.patch"

Index: config-shared.in
===================================================================
RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v
retrieving revision 1.1.2.91
diff -u -r1.1.2.91 config-shared.in
--- config-shared.in	22 Oct 2003 06:58:37 -0000	1.1.2.91
+++ config-shared.in	31 Oct 2003 19:47:28 -0000
@@ -891,7 +891,7 @@
 
 if [ "$CONFIG_SGI_IP22" = "y" -o "$CONFIG_MIPS_MAGNUM_4000" = "y" -o \
      "$CONFIG_OLIVETTI_M700" = "y" -o "$CONFIG_SNI_RM200_PCI" = "y" ]; then
-   dep_bool 'EISA bus support' CONFIG_EISA
+   bool 'EISA bus support' CONFIG_EISA
 fi
 
 if [ "$CONFIG_PCI" != "y" ]; then

--------------030003030004090309030609--