From lyle@zevion.com Sat Nov  1 01:38:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Nov 2003 01:38:44 +0000 (GMT)
Received: from rrcs-central-24-123-115-44.biz.rr.com ([IPv6:::ffff:24.123.115.44]:13184
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225426AbTKABim>; Sat, 1 Nov 2003 01:38:42 +0000
Received: from radium ([192.168.0.20])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hA11brmv028438
	for <linux-mips@linux-mips.org>; Fri, 31 Oct 2003 19:37:56 -0600
From: "Lyle Bainbridge" <lyle@zevion.com>
To: <linux-mips@linux-mips.org>
Subject: 
Date: Fri, 31 Oct 2003 19:38:58 -0600
Message-ID: <000001c3a018$ed5efb30$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
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: 3562
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lyle@zevion.com
Precedence: bulk
X-list: linux-mips

Hi,

I am porting the linux-mips 2.4.22 kernel to a custom Au1500 board and I
am seeing strange output when the kernel starts.  Some lines feed ok,
but some don't, and in that case the error level is displayed (ie, <4>).
Also numerous characters are dropped. 

Does anybody have any clue about what might be happening?  See kernel
output below.

Thanks,
Lyle

CPU revision is: 01030200<4>Primary instruction cache 16kB, physically
tagged, 4
-way, linesize 32 bytes.<4>Primary data cache 16kB 4-way, linesize 32
bytes.
Linux version 2.4.22 (root@localhost.localdomain) (gcc version 3.3.1) #9
Fri Oct
 31 18:57:53 CST 2003<4>Determined physical RAM map:<4> memory:
0(usable)
On node zone(0): 8192 pages..e4>zone1o): 0 pages.
ss
zone(2): 0 pages.
Kernel command line:  panic=2 ethaddr=00:30:23:50:00:00 root=/dev/hda2
console=t
tyS0,115200
 0ST 2003<4>calculating r4koff... 00493e00(4800000)
CPU frequency 480.00 MHz
set_au1x00_lcd_clock: warning: LCD clock too high (60000
KHz)<4>Calibrating dela
y loop... 478.41 BogoMIPS
Memory:8r9804k/32768k available (1257k kernel code, 2964k reserved, 84k
data, 76
k init, 0k highmem)<6>Dentry cache hash table entries: 4096 (order: 3,
32768 byt
es)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)<4>Checking
for 'wait
' instruction... unavailable.
POSIX conformance testing by UNIFIX
Autoconfig PCI channel 0x80267b18
X1Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x50000000
 04k data, 76k init, 0k highmem)
00:0c.0 Class 0104: 1103:0007 (rev 01)
        I/O at 0x00000300 [size=0x8]
        I/O at 0x00000308 [size=0x4]
        I/O at 0x00000310 [size=0x8]
        I/O at 0x00000318 [size=0x4]
        I/O at 0x00000400 [size=0x100]
Non-coherent PCI accesses enabled<6>Linux NET4.0 for Linux 2.4<6>Based
upon Swan
sea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapda6>Journalled Block Device driver loaded
pty: 256 Unix98 ptys configured<6>Serial driver version 1.01
(2001-02-08) with n
o serial options enabled
 eata, 76k init, 0k highmem)<6>ttyS00 at 0xb1100000 (irq = 0) is a 16550
ttyS01 at 0xb1200000 (irq = 1) is a 16550<6>ttyS02 at 0xb1300000 (irq =
2) is a
16550
ttyS03 at 0xb1400000 (irq = 3) is a 1655056>loop: loaded (max 8 devices)
)(is a 16550<4>au1000eth.c:1.4 ppopov@mvista.com
eth0: Au1x Ethernet found at 0xb1500000, irq 28<4>ethaddr not set in
boot prom<6
>eth0: Broadcom BCM5222 10/100 BaseT PHY at phy address 3<6>eth0: Using
Broadcom
 BCM5222 10/100 BaseT PHY as default<6>Uniform Multi-Platform E-IDE
driver Revis
ion: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx<6>HP
T371: IDE controller at PCI slot 07:0c.0<6>HPT371: chipset revision
1<6>HPT371:
not 100% native mode: will probe irqs later
HPT37X: using 33MHz PCI clock<6>    ide0: BM-DMA at 0x0408-0x040, BIOS
settings:
 hd:pio, hd:pio
HPT371: port 0x0310 already claimed by ide0
NET4: Linux TCP/IP 1.0 for NET4.0<6>IP Protocols: ICMP, UDP, TCP, IGMP
6>IP: routing cache hash table of 512 buckets, 4Kbytes
verride with idebus=xx=6>TCP: Hash tables configured (established 2048
bind 4096
)


From embedlf@citiz.net Mon Nov  3 02:43:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Nov 2003 02:43:41 +0000 (GMT)
Received: from [IPv6:::ffff:218.1.66.82] ([IPv6:::ffff:218.1.66.82]:17831 "HELO
	mail.citiz.net") by linux-mips.org with SMTP id <S8225486AbTKCCn3> convert rfc822-to-8bit;
	Mon, 3 Nov 2003 02:43:29 +0000
Received: (umta 3169 invoked by uid 1820); 3 Nov 2003 02:43:16 -0000
X-Lasthop: 10.1.1.5
Received: from unknown (HELO app5) (unknown@10.1.1.5)
  by localhost with SMTP; 3 Nov 2003 02:43:16 -0000
Message-ID: <1067827683782.2146.app5.Naesasoft.WBRHE1TU>
Date: Mon, 3 Nov 2003 10:48:03 +0800 (CST)
From: embedlf@citiz.net
To: linux-mips@linux-mips.org
Subject: problem during compile glibc
Mime-Version: 1.0
Content-Type: text/plain; charset="GBK"
Content-Transfer-Encoding: 8BIT
X-Priority: 3
X-Mailer: Naesasoft Ares Mailer
Return-Path: <embedlf@citiz.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3563
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: embedlf@citiz.net
Precedence: bulk
X-list: linux-mips

when I compiled the glibc2.2.3 that download from gnu.org,I meet the problem.
message as follow:

make  -C misc subdir_lib
make[2]: Entering directory `/home/lf/libc/glibc-2.2.3/misc'
rm -f /home/lf/libc/mipsglibc2.3/misc/syscall-list.d-t
{ \
 echo '/* Generated at libc build time from kernel syscall list.  */';\
 echo ''; \
 echo '#ifndef _SYSCALL_H'; \
 echo '# error "Never use <bits/syscall.h> directly; include <sys/syscall.h> instead."'; \
 echo '#endif'; \
 echo ''; \
 SUNPRO_DEPENDENCIES='/home/lf/libc/mipsglibc2.3/misc/syscall-list.d-t /home/lf/libc/mipsglibc2.3/misc/syscall-list.d' \
 mips-linux-gcc -E -x c  ../sysdeps/unix/sysv/linux/sys/syscall.h -D_LIBC -dM | \
 sed -n 's@^#define __NR_\([^ ]*\) .*$@#define SYS_\1 __NR_\1@p'; \
} > /home/lf/libc/mipsglibc2.3/misc/syscall-list.h.new
../sysdeps/unix/sysv/linux/sys/syscall.h:25:23: asm/unistd.h: ?????????
mv -f /home/lf/libc/mipsglibc2.3/misc/syscall-list.h.new /home/lf/libc/mipsglibc2.3/misc/syscall-list.h
sed < /home/lf/libc/mipsglibc2.3/misc/syscall-list.d-t > /home/lf/libc/mipsglibc2.3/misc/syscall-list.d-t2 \
    -e 's,/home/lf/libc/mipsglibc2\.3/misc/syscall-list\.d,$(objpfx)syscall-list.h $(objpfx)syscall-list.d,'
/bin/sh: line 1: /home/lf/libc/mipsglibc2.3/misc/syscall-list.d-t: cann't find this file or folder
make[2]: *** [/home/lf/libc/mipsglibc2.3/misc/syscall-list.d] Error 1
make[2]: Leaving directory `/home/lf/libc/glibc-2.2.3/misc'
make[1]: *** [misc/subdir_lib] Error 2
make[1]: Leaving directory `/home/lf/libc/glibc-2.2.3'
make: *** [all] Error 2

--------------------------------------------------
多发多彩----上海热线彩信开通！
http://mms.online.sh.cn/mms/index.jsp
花一元去环艺看天地英雄http://sms.online.sh.cn/zhuanti/movie_tickets/top.html
发短信赢取秋季嘉年华门票http://sms.online.sh.cn/zhuanti/world_carnival/world_carnival.html

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

From embedlf@citiz.net Mon Nov  3 02:44:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Nov 2003 02:44:16 +0000 (GMT)
Received: from [IPv6:::ffff:218.1.66.80] ([IPv6:::ffff:218.1.66.80]:45994 "HELO
	mail.citiz.net") by linux-mips.org with SMTP id <S8225489AbTKCCoC> convert rfc822-to-8bit;
	Mon, 3 Nov 2003 02:44:02 +0000
Received: (umta 4025 invoked by uid 1820); 3 Nov 2003 02:43:50 -0000
X-Lasthop: 10.1.1.5
Received: from unknown (HELO app5) (unknown@10.1.1.5)
  by localhost with SMTP; 3 Nov 2003 02:43:50 -0000
Message-ID: <1067827721345.2149.app5.Naesasoft.WBRHE1TU>
Date: Mon, 3 Nov 2003 10:48:41 +0800 (CST)
From: embedlf@citiz.net
To: linux-mips@linux-mips.org
Subject: problem during compile glibc
Mime-Version: 1.0
Content-Type: text/plain; charset="GBK"
Content-Transfer-Encoding: 8BIT
X-Priority: 3
X-Mailer: Naesasoft Ares Mailer
Return-Path: <embedlf@citiz.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3564
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: embedlf@citiz.net
Precedence: bulk
X-list: linux-mips

when I compiled the glibc2.2.3 that download from gnu.org,I meet the problem.
message as follow:

make  -C misc subdir_lib
make[2]: Entering directory `/home/lf/libc/glibc-2.2.3/misc'
rm -f /home/lf/libc/mipsglibc2.3/misc/syscall-list.d-t
{ \
 echo '/* Generated at libc build time from kernel syscall list.  */';\
 echo ''; \
 echo '#ifndef _SYSCALL_H'; \
 echo '# error "Never use <bits/syscall.h> directly; include <sys/syscall.h> instead."'; \
 echo '#endif'; \
 echo ''; \
 SUNPRO_DEPENDENCIES='/home/lf/libc/mipsglibc2.3/misc/syscall-list.d-t /home/lf/libc/mipsglibc2.3/misc/syscall-list.d' \
 mips-linux-gcc -E -x c  ../sysdeps/unix/sysv/linux/sys/syscall.h -D_LIBC -dM | \
 sed -n 's@^#define __NR_\([^ ]*\) .*$@#define SYS_\1 __NR_\1@p'; \
} > /home/lf/libc/mipsglibc2.3/misc/syscall-list.h.new
../sysdeps/unix/sysv/linux/sys/syscall.h:25:23: asm/unistd.h: ?????????
mv -f /home/lf/libc/mipsglibc2.3/misc/syscall-list.h.new /home/lf/libc/mipsglibc2.3/misc/syscall-list.h
sed < /home/lf/libc/mipsglibc2.3/misc/syscall-list.d-t > /home/lf/libc/mipsglibc2.3/misc/syscall-list.d-t2 \
    -e 's,/home/lf/libc/mipsglibc2\.3/misc/syscall-list\.d,$(objpfx)syscall-list.h $(objpfx)syscall-list.d,'
/bin/sh: line 1: /home/lf/libc/mipsglibc2.3/misc/syscall-list.d-t: cann't find this file or folder
make[2]: *** [/home/lf/libc/mipsglibc2.3/misc/syscall-list.d] Error 1
make[2]: Leaving directory `/home/lf/libc/glibc-2.2.3/misc'
make[1]: *** [misc/subdir_lib] Error 2
make[1]: Leaving directory `/home/lf/libc/glibc-2.2.3'
make: *** [all] Error 2

--------------------------------------------------
多发多彩----上海热线彩信开通！
http://mms.online.sh.cn/mms/index.jsp
花一元去环艺看天地英雄http://sms.online.sh.cn/zhuanti/movie_tickets/top.html
发短信赢取秋季嘉年华门票http://sms.online.sh.cn/zhuanti/world_carnival/world_carnival.html

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

From ppopov@mvista.com Mon Nov  3 18:13:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Nov 2003 18:13:57 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:10481 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225382AbTKCSNp>;
	Mon, 3 Nov 2003 18:13:45 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA12987;
	Mon, 3 Nov 2003 10:13:06 -0800
Subject: Re:
From: Pete Popov <ppopov@mvista.com>
To: Lyle Bainbridge <lyle@zevion.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <000001c3a018$ed5efb30$800101df@radium>
References: <000001c3a018$ed5efb30$800101df@radium>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1067883270.19090.41.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 03 Nov 2003 10:14:30 -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: 3565
X-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


Lyle,

>  0ST 2003<4>calculating r4koff... 00493e00(4800000)
> CPU frequency 480.00 MHz


This doesn't look right. Please do another pull of the linux-mips tree.
A few days ago I fixed a masking problem (0x7f vs 0x3f) that resulted in
a bogus CPU frequency reading. The serial baud rate value is calculated
based on the CPU frequency so if the CPU frequency we calculate is
wrong, the uart baud rate will be off too. 

Do a cvs update and if that doesn't fix the problem, let me know.

Pete

> set_au1x00_lcd_clock: warning: LCD clock too high (60000
> KHz)<4>Calibrating dela
> y loop... 478.41 BogoMIPS
> Memory:8r9804k/32768k available (1257k kernel code, 2964k reserved, 84k
> data, 76
> k init, 0k highmem)<6>Dentry cache hash table entries: 4096 (order: 3,
> 32768 byt
> es)
> Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
> Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
> Page-cache hash table entries: 8192 (order: 3, 32768 bytes)<4>Checking
> for 'wait
> ' instruction... unavailable.
> POSIX conformance testing by UNIFIX
> Autoconfig PCI channel 0x80267b18
> X1Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x50000000
>  04k data, 76k init, 0k highmem)
> 00:0c.0 Class 0104: 1103:0007 (rev 01)
>         I/O at 0x00000300 [size=0x8]
>         I/O at 0x00000308 [size=0x4]
>         I/O at 0x00000310 [size=0x8]
>         I/O at 0x00000318 [size=0x4]
>         I/O at 0x00000400 [size=0x100]
> Non-coherent PCI accesses enabled<6>Linux NET4.0 for Linux 2.4<6>Based
> upon Swan
> sea University Computer Society NET3.039
> Initializing RT netlink socket
> Starting kswapda6>Journalled Block Device driver loaded
> pty: 256 Unix98 ptys configured<6>Serial driver version 1.01
> (2001-02-08) with n
> o serial options enabled
>  eata, 76k init, 0k highmem)<6>ttyS00 at 0xb1100000 (irq = 0) is a 16550
> ttyS01 at 0xb1200000 (irq = 1) is a 16550<6>ttyS02 at 0xb1300000 (irq =
> 2) is a
> 16550
> ttyS03 at 0xb1400000 (irq = 3) is a 1655056>loop: loaded (max 8 devices)
> )(is a 16550<4>au1000eth.c:1.4 ppopov@mvista.com
> eth0: Au1x Ethernet found at 0xb1500000, irq 28<4>ethaddr not set in
> boot prom<6
> >eth0: Broadcom BCM5222 10/100 BaseT PHY at phy address 3<6>eth0: Using
> Broadcom
>  BCM5222 10/100 BaseT PHY as default<6>Uniform Multi-Platform E-IDE
> driver Revis
> ion: 7.00beta4-2.4
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx<6>HP
> T371: IDE controller at PCI slot 07:0c.0<6>HPT371: chipset revision
> 1<6>HPT371:
> not 100% native mode: will probe irqs later
> HPT37X: using 33MHz PCI clock<6>    ide0: BM-DMA at 0x0408-0x040, BIOS
> settings:
>  hd:pio, hd:pio
> HPT371: port 0x0310 already claimed by ide0
> NET4: Linux TCP/IP 1.0 for NET4.0<6>IP Protocols: ICMP, UDP, TCP, IGMP
> 6>IP: routing cache hash table of 512 buckets, 4Kbytes
> verride with idebus=xx=6>TCP: Hash tables configured (established 2048
> bind 4096
> )
> 
> 
> 


From dkesselr@mmc.atmel.com Mon Nov  3 18:53:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Nov 2003 18:53:46 +0000 (GMT)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:29773
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225382AbTKCSxe>; Mon, 3 Nov 2003 18:53:34 +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 NAA26809
	for <linux-mips@linux-mips.org>; Mon, 3 Nov 2003 13:53:27 -0500 (EST)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id NAA24901
	for <linux-mips@linux-mips.org>; Mon, 3 Nov 2003 13:53:21 -0500 (EST)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Mon, 3 Nov 2003 13:53:21 -0500 (EST)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: lib.a
Message-ID: <Pine.GSO.4.44.0311031349360.24745-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: 3566
X-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

For the mips architecture, it seems like arch/mips/lib/lib.a is linked in
and not lib/lib.a. For example on menuconfig when zlib* is selected, it is
not included in the final link. Is my understanding correct? Specifically,
2.4.23 has a firmware library (from lib/) that I would like to use with a
driver but regardless of my .config it is not being linked.
Thanks for your help.

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


From Dennis.Castleman@zoran.com Mon Nov  3 21:59:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Nov 2003 22:00:10 +0000 (GMT)
Received: from mx1.teralogic.tv ([IPv6:::ffff:207.16.148.27]:21225 "EHLO
	mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8225382AbTKCV7h>; Mon, 3 Nov 2003 21:59:37 +0000
Received: from tlexmail.teralogic.tv (uugate-2.oaktech.com [207.16.148.1])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id hA3LsDG10042
	for <linux-mips@linux-mips.org>; Mon, 3 Nov 2003 13:54:13 -0800 (PST)
Received: by tlexmail.teralogic-inc.com with Internet Mail Service (5.5.2653.19)
	id <VR64H5AP>; Mon, 3 Nov 2003 13:56:57 -0800
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E263410313F@tlexmail.teralogic-inc.com>
From: Dennis Castleman <Dennis.Castleman@zoran.com>
To: linux-mips@linux-mips.org
Subject: MIPS 4KCE Core
Date: Mon, 3 Nov 2003 13:56:54 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3A255.651BDAB0"
Return-Path: <Dennis.Castleman@zoran.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3567
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Dennis.Castleman@zoran.com
Precedence: bulk
X-list: linux-mips

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

------_=_NextPart_001_01C3A255.651BDAB0
Content-Type: text/plain

Any body know if MIPS 4KEm is supported.

The 4KEm provides a simpler scheme (less expansive) for virtual to physical
address translation. It is based on FMT (Fixed map translation) that
provides a direct address translation that is not configurable.

Question is whether a 16 dual entries FMT as described above would be
sufficient in order to run linux.   

Dennis Castleman
Systems Software Engineering Manager
DTV Group, Zoran Corp. 
1-408-523-4214


------_=_NextPart_001_01C3A255.651BDAB0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>MIPS 4KCE Core</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Any body know if MIPS 4KEm is supported.</FONT>
</P>

<P><FONT SIZE=3D2>The 4KEm provides a simpler scheme (less expansive) =
for virtual to physical address translation. It is based on FMT (Fixed =
map translation) that provides a direct address translation that is not =
configurable.</FONT></P>

<P><FONT SIZE=3D2>Question is whether a 16 dual entries FMT as =
described above would be sufficient in order to run linux.&nbsp;&nbsp; =
</FONT>
</P>

<P><FONT SIZE=3D2>Dennis Castleman</FONT>
<BR><FONT SIZE=3D2>Systems Software Engineering Manager</FONT>
<BR><FONT SIZE=3D2>DTV Group, Zoran Corp. </FONT>
<BR><FONT SIZE=3D2>1-408-523-4214</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3A255.651BDAB0--

From dkesselr@mmc.atmel.com Mon Nov  3 22:22:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Nov 2003 22:23:07 +0000 (GMT)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:3967
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225382AbTKCWW4>; Mon, 3 Nov 2003 22:22:56 +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 RAA29528
	for <linux-mips@linux-mips.org>; Mon, 3 Nov 2003 17:22:49 -0500 (EST)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id RAA25000
	for <linux-mips@linux-mips.org>; Mon, 3 Nov 2003 17:22:42 -0500 (EST)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Mon, 3 Nov 2003 17:22:42 -0500 (EST)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: Re:lib.a
Message-ID: <Pine.GSO.4.44.0311031717560.24745-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: 3568
X-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

The function that I am missing (release_firmware) is compiled into
lib/lib.a. and shows up in lib.a.flags. But it does not show up in vmlinux
binary or the symbol table. I couldn't see that the generic Malta make
file has any garbage collection on but I can't see where it is lost.
What I get is unresolved symbols when I insmod my driver.
Any ideas from the experts?

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


From ralf@linux-mips.org Tue Nov  4 00:50:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 00:50:57 +0000 (GMT)
Received: from p508B62C3.dip.t-dialin.net ([IPv6:::ffff:80.139.98.195]:44746
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225400AbTKDAup>; Tue, 4 Nov 2003 00:50:45 +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 hA40oisY031706;
	Tue, 4 Nov 2003 01:50:44 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hA40oeKd031705;
	Tue, 4 Nov 2003 01:50:40 +0100
Date: Tue, 4 Nov 2003 01:50:39 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: lib.a
Message-ID: <20031104005039.GA27415@linux-mips.org>
References: <Pine.GSO.4.44.0311031717560.24745-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.0311031717560.24745-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: 3569
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Nov 03, 2003 at 05:22:42PM -0500, David Kesselring wrote:

> The function that I am missing (release_firmware) is compiled into
> lib/lib.a. and shows up in lib.a.flags. But it does not show up in vmlinux
> binary or the symbol table. I couldn't see that the generic Malta make
> file has any garbage collection on but I can't see where it is lost.
> What I get is unresolved symbols when I insmod my driver.
> Any ideas from the experts?

It's a library so if no reference is preceeding the library that member
won't be linked in.

  Ralf

From ralf@linux-mips.org Tue Nov  4 00:59:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 00:59:45 +0000 (GMT)
Received: from p508B62C3.dip.t-dialin.net ([IPv6:::ffff:80.139.98.195]:12491
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225402AbTKDA7d>; Tue, 4 Nov 2003 00:59:33 +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 hA40xWsY031897;
	Tue, 4 Nov 2003 01:59:32 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hA40xVIW031896;
	Tue, 4 Nov 2003 01:59:31 +0100
Date: Tue, 4 Nov 2003 01:59:31 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Dennis Castleman <Dennis.Castleman@zoran.com>
Cc: linux-mips@linux-mips.org
Subject: Re: MIPS 4KCE Core
Message-ID: <20031104005931.GB27415@linux-mips.org>
References: <56BEF0DBC8B9D611BFDB00508B5E263410313F@tlexmail.teralogic-inc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56BEF0DBC8B9D611BFDB00508B5E263410313F@tlexmail.teralogic-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: 3570
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Nov 03, 2003 at 01:56:54PM -0800, Dennis Castleman wrote:

> Any body know if MIPS 4KEm is supported.
> 
> The 4KEm provides a simpler scheme (less expansive) for virtual to physical
> address translation. It is based on FMT (Fixed map translation) that
> provides a direct address translation that is not configurable.
> 
> Question is whether a 16 dual entries FMT as described above would be
> sufficient in order to run linux.   

Linux 2.6 supports something like if CONFIG_MMU is disabled which looks
like it could suit your particular type of application.  So far nobody
has made any attempt to get this to run on MIPS but doesn't look too hard.
This of course will have serious impact on userspace applications -
the ABI necessarily has to change if the MMU is gone.

  Ralf

From yikok9@yahoo.com.cn Tue Nov  4 02:13:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 02:13:54 +0000 (GMT)
Received: from smtp016.mail.yahoo.com ([IPv6:::ffff:216.136.174.113]:32875
	"HELO smtp016.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225402AbTKDCNn>; Tue, 4 Nov 2003 02:13:43 +0000
Received: from unknown (HELO wzf) (yikok9@61.149.150.135 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 4 Nov 2003 02:12:55 -0000
Date: Tue, 4 Nov 2003 10:13:09 +0800
From: "Wang Zaifang" <yikok9@yahoo.com.cn>
Reply-To: yikok9@yahoo.com.cn
To: "linux-mips" <linux-mips@linux-mips.org>
Subject: boot pb1500 from flash through 16-bit data bus?
X-mailer: Foxmail 5.0 beta1 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64
Message-Id: <20031104021343Z8225402-1272+8745@linux-mips.org>
Return-Path: <yikok9@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: 3572
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yikok9@yahoo.com.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 1988
Lines: 28

aGksIA0KICBEb2VzIGFueW9uZSBoYXZlIGV4cGVyaWVuY2Ugb24gd3JpdGluZyAxNi1iaXQgYm9v
dGluZyBjb2RlIGZvciBQQjE1MDA/DQogIEknbSB3b3JraW5nIG9uIGEgY3VzdG9taXplZCBhdTE1
MDAgYm9hcmQgdGhhdCBoYXMgcHV6emxlZCB1cyBmb3Igc2VydmVyYWwgZGF5cywgOi0oIFRoZSBi
b2FyZCBpcyBkZXNpZ25lZCB0byBib290IGZyb20gZmxhc2ggdXNpbmcgMTYtYml0IGRhdGEgYnVz
LCBob3dldmVyIGl0IHNlZW1lZCB0aGF0IHRoZSBjb2RlIHdlIHN0b3JlZCBpbiB0aGUgZmxhc2gg
ZG9lcyBub3QgcnVuIGF0IGFsbC4gVGhlcmUgbWlnaHQgYmUgc29tZSBlcnJvcnMgaW4gb3VyIGRl
c2lnbiwgc28gd2UgdHVybiB0byB0aGUgUEIxNTAwIGV2YWwtYm9hcmQuDQogIEkgd3JvdGUgYSBw
aWVjZSBvZiB0ZXN0aW5nIGNvZGUgdGhhdCBzZW5kcyAwMTAxMDEuLi4gc2VyaWVzIHRvIEdQSU9b
MF0gY29udGludW91c2VseSBhZnRlciByZXNldC4gVGhlIGNvZGUgcnVucyB3ZWxsIHdoZW4gdGhl
IFNSQU0gZGF0YSBidXMgaXMgc2V0IHRvIDMyLWJpdCB3aWR0aCwgaS5lLiBhIHNxdWFyZSB3YXZl
Zm9ybSBhcHBlYXJzIG9uIEdQSU9bMF0uIFRoZW4gSSBidXJuIHRoZSBjb2RlIGludG8gZmxhc2gg
dGhyb3VnaCBZQU1PTiwgYXNzdXJpbmcgdGhlIGNvZGUgb25seSByZXNpZGUgaW4gb25lIGZsYXNo
IGNoaXAgb2YgdGhlIHR3by4gQ29udGVudCBvZiB0aGUgZmxhc2ggbG9va3MgbGlrZSB0aGlzIGlu
IFlBTU9OOg0KDQpZQU1PTj4gZHVtcCBiZGMwMDAwMA0KDQpCREMwMDAwMDogOTAgQjEgMDAgMDAg
MDggM0MgMDAgMDAgODAgODAgMDAgMDAgMDkgMzQgMDAgMDAgIC6hwC4uLjwuLi4uLi4uNC4uDQpC
REMwMDAxMDogMkMgMDAgMDAgMDAgMDkgQUQgMDAgMDAgRkYgRkYgMDAgMDAgMDkgMzQgMDAgMDAg
ICwuLi4uLS4uLi4uLi40Li4NCkJEQzAwMDIwOiAwMCAwMSAwMCAwMCAwOSBBRCAwMCAwMCAwMCAw
MCAwMCAwMCAwOSAyNCAwMCAwMCAgLi4uLi4tLi4uLi4uLiQuLg0KLi4uDQoNCiAgRWFjaCBpbnN0
cnVjdGlvbiB3b3JkIGlzIHNwbGl0IGludG8gdHdvIGhhbGYtd29yZHMsIGFuZCBwdXQgaW50byBs
b3dlciAxNi1iaXRzIG9mIHR3byB3b3Jkcy4gVGhlbiBJIHJlc2V0IHRoZSBQQjE1MDAgYm9hcmQs
IHN3aXRjaCBTMTUgdG8gc2V0IHRoZSBTUkFNIGRhdGEgYnVzIHRvIDE2LWJpdCBtb2RlLCBzd2l0
Y2ggUzEzIHRvIGJvb3QgZnJvbSB0aGUgc3BlY2lmaWVkIGZsYXNoIGNoaXAuIEJ1dCB0aGUgY29k
ZSB3aWxsIG5vdCBydW4sIGV2ZW4gYWZ0ZXIgSSBzd2FwIHRoZSBieXRlLW9yZGVyIGFuZCB0aGUg
aGFsZndvcmQtb3JkZXIuDQoNCiAgQW55IGFkdmljZSB3aWxsIGJlIGFwcHJlY2lhdGVkLCA6LSkN
Cg0KoaGhoaGhoaGhoaGhoaGhoVdhbmcgWmFpZmFuZw0KoaGhoaGhoaGhoaGhoaGhoXlpa29rOUB5
YWhvby5jb20uY24NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwMy0xMS0wNA0K



From anemo@mba.ocn.ne.jp Tue Nov  4 05:18:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 05:18:58 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:23327
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225316AbTKDFS0>; Tue, 4 Nov 2003 05:18:26 +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; 4 Nov 2003 05:18:47 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id hA45IS9X058079;
	Tue, 4 Nov 2003 14:18:28 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Tue, 04 Nov 2003 14:21:11 +0900 (JST)
Message-Id: <20031104.142111.41626869.nemoto@toshiba-tops.co.jp>
To: echristo@redhat.com
Cc: ica2_ts@csv.ica.uni-stuttgart.de, 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: <1067480704.2542.8.camel@ghostwheel.sfbay.redhat.com>
References: <20031029181516.GA14443@nevyn.them.org>
	<20031030015353.GE1486@rembrandt.csv.ica.uni-stuttgart.de>
	<1067480704.2542.8.camel@ghostwheel.sfbay.redhat.com>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3575
X-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: 682
Lines: 18

>>>>> On Wed, 29 Oct 2003 18:25:04 -0800, Eric Christopher <echristo@redhat.com> said:
>> 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.

eric> Judging from the line offset from today's sources to that error
eric> message it might have been fixed with rsandifo's last patch that
eric> fixed an uninitialized variable problem. (global_gotno)

I tried binutils-2.14.90.0.7 (based on binutils 2003 1029 in CVS) but
my problem did no solved.  It seems something is still wrong.

---
Atsushi Nemoto

From lyle@zevion.com Tue Nov  4 05:41:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 05:41:18 +0000 (GMT)
Received: from rrcs-central-24-123-115-44.biz.rr.com ([IPv6:::ffff:24.123.115.44]:14720
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225316AbTKDFlH>; Tue, 4 Nov 2003 05:41:07 +0000
Received: from radium ([192.168.0.20])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hA45eHmv004750;
	Mon, 3 Nov 2003 23:40:18 -0600
From: "Lyle Bainbridge" <lyle@zevion.com>
To: <yikok9@yahoo.com.cn>, "'linux-mips'" <linux-mips@linux-mips.org>
Subject: RE: boot pb1500 from flash through 16-bit data bus?
Date: Mon, 3 Nov 2003 23:41:26 -0600
Message-ID: <000001c3a296$4d51b3a0$1400a8c0@radium>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
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: <20031104021343Z8225402-1272+8745@linux-mips.org>
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: 3576
X-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: 3321
Lines: 85

Hi,

If you are building as little endian and booting from a 16bit ROM then
simply load your boot code into the 16 bit flash. You shouldn't need to
swap bytes and half words yourself. Here's why:

The Au1500 starts in big endian mode but the static bus controller
starts in little endian mode and will actually read the little endian
boot code correctly.  The very first thing you need to do in your boot
code is switch the Au1500 to little endian mode. Then you need to do the
other initial activities such as establishing the status register,
config0, cause register and initializing the caches and TLB.

If you are building as big endian it is a little more difficult. Place
the following block at the reset vector:

    .long 0xb4003c08 # lui t0,0xb400
    .long 0x10003508 # ori t0,t0,0x1000
    .long 0x00008d09 # lw t1,0(t0)
    .long 0x02003529 # ori t1,t1,0x200
    .long 0x0000ad09 # sw t1,0(t0)
    .long 0x00000000 # nop
    .long 0x00000000 # nop
    .long 0x00000000 # nop
    .long 0x00000000 # nop 

This is a small fragement of little endian code that switches the static
bus controller to big endian mode.  That way when the processor boots
and reads the big endian boot code as little endian, the first part will
be little endian and it will work.  Of course the code fragement above
immediately switches the static bus to BE and everything will continue
correctly.  I know it seems a little strange.

Hope this helps.  Email if you have any questions.

Cheers
Lyle


> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Wang Zaifang
> Sent: Monday, November 03, 2003 8:13 PM
> To: linux-mips
> Subject: boot pb1500 from flash through 16-bit data bus?
> 
> 
> hi, 
>   Does anyone have experience on writing 16-bit booting code 
> for PB1500?
>   I'm working on a customized au1500 board that has puzzled 
> us for serveral days, :-( The board is designed to boot from 
> flash using 16-bit data bus, however it seemed that the code 
> we stored in the flash does not run at all. There might be 
> some errors in our design, so we turn to the PB1500 eval-board.
>   I wrote a piece of testing code that sends 010101... series 
> to GPIO[0] continuousely after reset. The code runs well when 
> the SRAM data bus is set to 32-bit width, i.e. a square 
> waveform appears on GPIO[0]. Then I burn the code into flash 
> through YAMON, assuring the code only reside in one flash 
> chip of the two. Content of the flash looks like this in YAMON:
> 
> YAMON> dump bdc00000
> 
> BDC00000: 90 B1 00 00 08 3C 00 00 80 80 00 00 09 34 00 00  
> .$B!^(B...<.......4..
> BDC00010: 2C 00 00 00 09 AD 00 00 FF FF 00 00 09 34 00 00  
> ,....-.......4..
> BDC00020: 00 01 00 00 09 AD 00 00 00 00 00 00 09 24 00 00  
> .....-.......$.. ...
> 
>   Each instruction word is split into two half-words, and put 
> into lower 16-bits of two words. Then I reset the PB1500 
> board, switch S15 to set the SRAM data bus to 16-bit mode, 
> switch S13 to boot from the specified flash chip. But the 
> code will not run, even after I swap the byte-order and the 
> halfword-order.
> 
>   Any advice will be appreciated, :-)
> 
> $B!!!!!!!!!!!!!!!!(BWang Zaifang
> $B!!!!!!!!!!!!!!!!(Byikok9@yahoo.com.cn
> $B!!!!!!!!!!!!!!!!!!!!(B2003-11-04
> 


From rdkehn@yahoo.com Tue Nov  4 05:41:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 05:42:10 +0000 (GMT)
Received: from web12008.mail.yahoo.com ([IPv6:::ffff:216.136.172.216]:60268
	"HELO web12008.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225378AbTKDFld>; Tue, 4 Nov 2003 05:41:33 +0000
Message-ID: <20031104054130.12392.qmail@web12008.mail.yahoo.com>
Received: from [65.67.102.146] by web12008.mail.yahoo.com via HTTP; Mon, 03 Nov 2003 21:41:30 PST
Date: Mon, 3 Nov 2003 21:41:30 -0800 (PST)
From: Doug Kehn <rdkehn@yahoo.com>
Subject: Kernel compiler error : flexible array member not at end of struct
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rdkehn@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: 3577
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rdkehn@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1243
Lines: 39

I am receiving the following kernel compile error:

make[3]: Entering directory
`/usr/src/x/kernel/linux-2.4.21/fs/partitions'
mips-uclibc-gcc -D__KERNEL__
-I/usr/src/x/kernel/linux-2.4.21/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2
-fno-strict-aliasing -fno-common -fomit-frame-pointer
-I /usr/src/x/linux-2.4.21/include/asm/gcc -G 0
-mno-abicalls -fno-pic -pipe  -mcpu=r5000 -mips2
-Wa,--trap   -nostdinc -iwithprefix include
-DKBUILD_BASENAME=check  -DEXPORT_SYMTAB -c check.c
In file included from
/usr/src/x/kernel/linux-2.4.21/include/linux/raid/md.h:50,
                 from check.c:21:
/usr/src/x/kernel/linux-2.4.21/include/linux/raid/md_p.h:157:
flexible array member not at end of struct
make[3]: *** [check.o] Error 1

I am using gcc version 2.96-mips3264-000710 (from
sdelinux-5.01-4eb.i386.rpm).  The kernel is,
obviously, 2.4.21 (from linux-mips.org).  uclibc is
version 0.9.21.

I have seen one or two other posting related to this
same error.  However, I was unable to find any
suggested resoltions.  Does anyone know of a solution
to this compile error?

Thanks...
doug




__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

From echristo@redhat.com Tue Nov  4 08:07:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 08:07:29 +0000 (GMT)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:10245 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225480AbTKDIHR>;
	Tue, 4 Nov 2003 08:07:17 +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 hA47m1A05322;
	Tue, 4 Nov 2003 02:48:01 -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 hA486da30064;
	Tue, 4 Nov 2003 03:06:39 -0500
Received: from ghostwheel.sfbay.redhat.com (vpn50-45.rdu.redhat.com [172.16.50.45])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hA486aJ01301;
	Tue, 4 Nov 2003 00:06:36 -0800
Subject: Re: Huge dynamically linked program does not run on mips-linux
From: Eric Christopher <echristo@redhat.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>, jsun@mvista.com,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
In-Reply-To: <20031104.142111.41626869.nemoto@toshiba-tops.co.jp>
References: <20031029181516.GA14443@nevyn.them.org>
	 <20031030015353.GE1486@rembrandt.csv.ica.uni-stuttgart.de>
	 <1067480704.2542.8.camel@ghostwheel.sfbay.redhat.com>
	 <20031104.142111.41626869.nemoto@toshiba-tops.co.jp>
Content-Type: text/plain
Message-Id: <1067933156.3491.5.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Tue, 04 Nov 2003 00:05:56 -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: 3578
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 484
Lines: 17


> eric> Judging from the line offset from today's sources to that error
> eric> message it might have been fixed with rsandifo's last patch that
> eric> fixed an uninitialized variable problem. (global_gotno)
> 
> I tried binutils-2.14.90.0.7 (based on binutils 2003 1029 in CVS) but
> my problem did no solved.  It seems something is still wrong.

This was plain mips-linux? Not mips64-linux?

And where would I find the sources?

-eric

-- 
Eric Christopher <echristo@redhat.com>


From Geert.Uytterhoeven@sonycom.com Tue Nov  4 09:34:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 09:34:40 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:61326 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225316AbTKDJe3>;
	Tue, 4 Nov 2003 09:34:29 +0000
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id hA49YPQG018219;
	Tue, 4 Nov 2003 10:34:26 +0100 (MET)
Date: Tue, 4 Nov 2003 10:34:25 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: David Kesselring <dkesselr@mmc.atmel.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: lib.a
In-Reply-To: <20031104005039.GA27415@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0311041033030.2050-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: 3579
X-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: 1017
Lines: 26

On Tue, 4 Nov 2003, Ralf Baechle wrote:
> On Mon, Nov 03, 2003 at 05:22:42PM -0500, David Kesselring wrote:
> > The function that I am missing (release_firmware) is compiled into
> > lib/lib.a. and shows up in lib.a.flags. But it does not show up in vmlinux
> > binary or the symbol table. I couldn't see that the generic Malta make
> > file has any garbage collection on but I can't see where it is lost.
> > What I get is unresolved symbols when I insmod my driver.
> > Any ideas from the experts?
> 
> It's a library so if no reference is preceeding the library that member
> won't be linked in.

And to be usable by a module, you have to make sure the symbol is exported by
the kernel using EXPORT_SYMBOL().

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 chris@mips.com Tue Nov  4 10:40:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 10:41:10 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:22027 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225316AbTKDKki>;
	Tue, 4 Nov 2003 10:40:38 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1AGyZl-0007Ek-00; Tue, 04 Nov 2003 10:38:17 +0000
Received: from holborn.algor.co.uk ([192.168.192.237] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1AGyba-0004EL-00; Tue, 04 Nov 2003 10:40:10 +0000
Message-ID: <3FA7820A.2010701@mips.com>
Date: Tue, 04 Nov 2003 10:40:10 +0000
From: Chris Dearman <chris@mips.com>
Organization: MIPS Technologies (UK) Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Doug Kehn <rdkehn@yahoo.com>
CC: linux-mips@linux-mips.org
Subject: Re: Kernel compiler error : flexible array member not at end of struct
References: <20031104054130.12392.qmail@web12008.mail.yahoo.com>
In-Reply-To: <20031104054130.12392.qmail@web12008.mail.yahoo.com>
Content-Type: multipart/mixed;
 boundary="------------030907060805090900090207"
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-3.606, required 4, AWL,
	BAYES_00, USER_AGENT_MOZILLA_UA)
Return-Path: <chris@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3580
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chris@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1606
Lines: 59

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

Doug Kehn wrote:
> I am using gcc version 2.96-mips3264-000710 (from
> sdelinux-5.01-4eb.i386.rpm).  The kernel is,
> obviously, 2.4.21 (from linux-mips.org).  uclibc is
> version 0.9.21.
> 
> I have seen one or two other posting related to this
> same error.  However, I was unable to find any
> suggested resoltions.  Does anyone know of a solution
> to this compile error?

   There is an updated version of the compiler that handles zero-length 
arrays in structures correctly.  See 
ftp://ftp.mips.com/pub/tools/software/sde-for-linux/

   Alternatively you could apply the attached patch

	Chris

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

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

Index: md_p.h
===================================================================
RCS file: linux-2.4.18/include/linux/raid/md_p.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- md_p.h	4 Mar 2002 11:13:33 -0000	1.1
+++ md_p.h	8 Nov 2002 13:09:02 -0000	1.2
@@ -151,10 +151,12 @@
 	 */
 	mdp_disk_t disks[MD_SB_DISKS];
 
+#if MD_SB_RESERVED_WORDS
 	/*
 	 * Reserved
 	 */
 	__u32 reserved[MD_SB_RESERVED_WORDS];
+#endif
 
 	/*
 	 * Active descriptor

--------------030907060805090900090207--


From anemo@mba.ocn.ne.jp Tue Nov  4 10:59:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 11:00:05 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:23332
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225385AbTKDK7c>; Tue, 4 Nov 2003 10:59:32 +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; 4 Nov 2003 10:59:52 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id hA4Axc9X058857;
	Tue, 4 Nov 2003 19:59:39 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Tue, 04 Nov 2003 20:02:22 +0900 (JST)
Message-Id: <20031104.200222.70226623.nemoto@toshiba-tops.co.jp>
To: echristo@redhat.com
Cc: ica2_ts@csv.ica.uni-stuttgart.de, 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: <1067933156.3491.5.camel@ghostwheel.sfbay.redhat.com>
References: <1067480704.2542.8.camel@ghostwheel.sfbay.redhat.com>
	<20031104.142111.41626869.nemoto@toshiba-tops.co.jp>
	<1067933156.3491.5.camel@ghostwheel.sfbay.redhat.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: 3581
X-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: 598
Lines: 17

>>>>> On Tue, 04 Nov 2003 00:05:56 -0800, Eric Christopher <echristo@redhat.com> said:
>> I tried binutils-2.14.90.0.7 (based on binutils 2003 1029 in CVS)
>> but my problem did no solved.  It seems something is still wrong.

eric> This was plain mips-linux? Not mips64-linux?

Yes.  mips-linux and mipsel-linux target (host is i386).  Both target
generate broken binary for my test program.

eric> And where would I find the sources?

I'm using plain binutils 2.14 and gcc 3.3.2 from gnu.org FTP site,
binutils 2.14.90.0.7 from
http://www.kernel.org/pub/linux/devel/binutils/.

---
Atsushi Nemoto

From AdeelM@quartics.com Tue Nov  4 11:56:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 11:56:34 +0000 (GMT)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:47575
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225316AbTKDL4W>; Tue, 4 Nov 2003 11:56:22 +0000
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <WHAQ22B4>; Tue, 4 Nov 2003 16:56:09 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264F542@1aurora.enabtech>
From: Adeel Malik <AdeelM@quartics.com>
To: linux-mips@linux-mips.org
Subject: How to request an IRQ for NMI on MIPS Processor
Date: Tue, 4 Nov 2003 16:56:08 +0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3A2CA.A25A8C70"
Return-Path: <AdeelM@quartics.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3582
X-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@quartics.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2390
Lines: 51

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_01C3A2CA.A25A8C70
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
          In my embedded design, I intend to use NMI of MIPS 4Kc processor
(rather than IRQ0 or IRQ1 .....) for an external Interrupt Source. The
external Interrupt source is a video capture device which interrupts the
MIPS 4Kc CPU via its NMI (Non-Maskable Interrupt) line, whenever it has one
complete frame. I need to write the driver for that device in Linux-2.4.20.
The request_irq function provided by Linux takes a digit value from 0 to 5
to map external interrupt sources to any one of CPUs Interrupt pins. How can
I request and implement my interrupt handler routine for the NMI of MIPS
processor ?.
 
Regards,
ADEEL MALIK,


------_=_NextPart_001_01C3A2CA.A25A8C70
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=276362111-04112003><FONT size=2>Hi All,</FONT></SPAN></DIV>
<DIV><SPAN class=276362111-04112003><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In my 
embedded&nbsp;design, I&nbsp;intend to use NMI of MIPS 4Kc processor (rather 
than IRQ0 or IRQ1 .....) for an external Interrupt Source. The external 
Interrupt source is a video capture device which interrupts the MIPS 4Kc CPU via 
its NMI (Non-Maskable Interrupt) line,&nbsp;whenever it has one complete frame. 
I need to write the driver for that device in Linux-2.4.20. The 
<STRONG>request_irq</STRONG> function provided by Linux takes&nbsp;a 
digit&nbsp;value from 0 to 5 to map external interrupt sources to any one of 
CPUs Interrupt pins. How can I request and implement my interrupt handler 
routine for the NMI of MIPS processor ?.</FONT></SPAN></DIV>
<DIV><SPAN class=276362111-04112003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=276362111-04112003><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_01C3A2CA.A25A8C70--

From ralf@linux-mips.org Tue Nov  4 12:30:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 12:30:48 +0000 (GMT)
Received: from p508B62C3.dip.t-dialin.net ([IPv6:::ffff:80.139.98.195]:45955
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225316AbTKDMah>; Tue, 4 Nov 2003 12:30:37 +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 hA4CUZsY004802;
	Tue, 4 Nov 2003 13:30:35 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hA4CUYrH004801;
	Tue, 4 Nov 2003 13:30:34 +0100
Date: Tue, 4 Nov 2003 13:30:34 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Adeel Malik <AdeelM@quartics.com>
Cc: linux-mips@linux-mips.org
Subject: Re: How to request an IRQ for NMI on MIPS Processor
Message-ID: <20031104123034.GA4048@linux-mips.org>
References: <10C6C1971DA00C4BB87AC0206E3CA38264F542@1aurora.enabtech>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <10C6C1971DA00C4BB87AC0206E3CA38264F542@1aurora.enabtech>
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: 3583
X-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: 1747
Lines: 33

On Tue, Nov 04, 2003 at 04:56:08PM +0500, Adeel Malik wrote:

>           In my embedded design, I intend to use NMI of MIPS 4Kc processor
> (rather than IRQ0 or IRQ1 .....) for an external Interrupt Source. The
> external Interrupt source is a video capture device which interrupts the
> MIPS 4Kc CPU via its NMI (Non-Maskable Interrupt) line, whenever it has one
> complete frame. I need to write the driver for that device in Linux-2.4.20.
> The request_irq function provided by Linux takes a digit value from 0 to 5
> to map external interrupt sources to any one of CPUs Interrupt pins. How can
> I request and implement my interrupt handler routine for the NMI of MIPS
> processor ?.

Is there any particular reason for using the NMI?

NMI on MIPS is pretty much miss-designed for use in application code; it's
use should be limited to debugging and recovery from catastrophical
failure.  The reason for this is the way this exception is handled:

  - the BEV, TS, SR, NMI and ERL bits in c0_status are overwritten - that is
    their old state is lost.
  - c0_errorepc is overwritten - again that means the old value is lost so
    in case the NMI interrupts an exception handler that uses this register
    such as the cache error handler you can not resume execution.
  - the program counter is set to 0xbfc00000.  Most likely a slow flash
    memory is mapped at this address but in any case it's an uncached
    segment of the address space so execution will be even slower.
  - execution will pass through the firmware.  That means you can only
    use the NMI at all if firmware provides some kind of hook.

It seems pretty clear to me that the MIPS designers never intended the
NMI for anything else than catastrophic events.

  Ralf

From AdeelM@quartics.com Tue Nov  4 12:58:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 12:58:54 +0000 (GMT)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:28377
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225316AbTKDM6m>; Tue, 4 Nov 2003 12:58:42 +0000
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <WHAQ22BV>; Tue, 4 Nov 2003 17:58:32 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264F543@1aurora.enabtech>
From: Adeel Malik <AdeelM@quartics.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: RE: How to request an IRQ for NMI on MIPS Processor
Date: Tue, 4 Nov 2003 17:58:32 +0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Return-Path: <AdeelM@quartics.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3584
X-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@quartics.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2546
Lines: 60

Hi Ralph,
	   Thanks for the reply. Yes you are right that NMI isn't meant to
be used as a regular IRQ of MIPS Processor. But somehow the board designer
connected the External Interrupt from video capture device to the NMI and
now I am thinking as how to how implement the Interrupt handler routine for
the NMI of MIPS processor. Do you think that we need to re-route the Board
or there may be some patch available describing the implementation of
Interrupt handler for NMI of MIPS 4Kc.

Regards, 	

ADEEL MALIK,


-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Ralf Baechle
Sent: Tuesday, November 04, 2003 5:31 PM
To: Adeel Malik
Cc: linux-mips@linux-mips.org
Subject: Re: How to request an IRQ for NMI on MIPS Processor


On Tue, Nov 04, 2003 at 04:56:08PM +0500, Adeel Malik wrote:

>           In my embedded design, I intend to use NMI of MIPS 4Kc processor
> (rather than IRQ0 or IRQ1 .....) for an external Interrupt Source. The
> external Interrupt source is a video capture device which interrupts the
> MIPS 4Kc CPU via its NMI (Non-Maskable Interrupt) line, whenever it has
one
> complete frame. I need to write the driver for that device in
Linux-2.4.20.
> The request_irq function provided by Linux takes a digit value from 0 to 5
> to map external interrupt sources to any one of CPUs Interrupt pins. How
can
> I request and implement my interrupt handler routine for the NMI of MIPS
> processor ?.

Is there any particular reason for using the NMI?

NMI on MIPS is pretty much miss-designed for use in application code; it's
use should be limited to debugging and recovery from catastrophical
failure.  The reason for this is the way this exception is handled:

  - the BEV, TS, SR, NMI and ERL bits in c0_status are overwritten - that is
    their old state is lost.
  - c0_errorepc is overwritten - again that means the old value is lost so
    in case the NMI interrupts an exception handler that uses this register
    such as the cache error handler you can not resume execution.
  - the program counter is set to 0xbfc00000.  Most likely a slow flash
    memory is mapped at this address but in any case it's an uncached
    segment of the address space so execution will be even slower.
  - execution will pass through the firmware.  That means you can only
    use the NMI at all if firmware provides some kind of hook.

It seems pretty clear to me that the MIPS designers never intended the
NMI for anything else than catastrophic events.

  Ralf


From ralf@linux-mips.org Tue Nov  4 13:28:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 13:28:14 +0000 (GMT)
Received: from p508B62C3.dip.t-dialin.net ([IPv6:::ffff:80.139.98.195]:135
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225316AbTKDN2C>; Tue, 4 Nov 2003 13:28:02 +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 hA4DS1sY005961;
	Tue, 4 Nov 2003 14:28:01 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hA4DS1Mr005960;
	Tue, 4 Nov 2003 14:28:01 +0100
Date: Tue, 4 Nov 2003 14:28:01 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Adeel Malik <AdeelM@quartics.com>
Cc: linux-mips@linux-mips.org
Subject: Re: How to request an IRQ for NMI on MIPS Processor
Message-ID: <20031104132801.GA5297@linux-mips.org>
References: <10C6C1971DA00C4BB87AC0206E3CA38264F543@1aurora.enabtech>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <10C6C1971DA00C4BB87AC0206E3CA38264F543@1aurora.enabtech>
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: 3585
X-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: 1477
Lines: 34

On Tue, Nov 04, 2003 at 05:58:32PM +0500, Adeel Malik wrote:

> Hi Ralph,
        ^^

Who is that guy? ;-)

> 	   Thanks for the reply. Yes you are right that NMI isn't meant to
> be used as a regular IRQ of MIPS Processor. But somehow the board designer
> connected the External Interrupt from video capture device to the NMI and
> now I am thinking as how to how implement the Interrupt handler routine for
> the NMI of MIPS processor. Do you think that we need to re-route the Board
> or there may be some patch available describing the implementation of
> Interrupt handler for NMI of MIPS 4Kc.

As I said the NMI goes through the firmware so the way how to handle the
NMI on your specific board is entirely upto the firmware.  This is also
why you don't find much code related to NMIs in Linux.

I think it's highly desirable to fix this little hardware problem even
though that is going to involve some cost.  To look at things a bit more
from the Linux side:

 - NMI may even interrupt a previous NMI.  Again that means you'll lose your
   previous state, dead.
 - NMI means you have to paranoidly check the interrupt code.

Hmm...  Here's a little idea.  Bits 8 and 9 in the status and cause
registers are for the MIPS sofware interrupt bits which Linux doesn't use
at all.  NMI could use those so on return from NMI a normal maskable
interrupt would be triggered.  That would minimize the NMI path and
complications that could arise from it's not-maskability.

  Ralf

From drow@crack.them.org Tue Nov  4 16:17:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 16:18:01 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:46794 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225316AbTKDQRt>;
	Tue, 4 Nov 2003 16:17:49 +0000
Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian))
	id 1AH3sD-0000N7-Sk; Tue, 04 Nov 2003 11:17:41 -0500
Date: Tue, 4 Nov 2003 11:17:41 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: jsun@mvista.com, linux-mips@linux-mips.org,
	binutils@sources.redhat.com, aoliva@redhat.com
Subject: Re: Huge dynamically linked program does not run on mips-linux
Message-ID: <20031104161741.GA302@nevyn.them.org>
Mail-Followup-To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, jsun@mvista.com,
	linux-mips@linux-mips.org, binutils@sources.redhat.com,
	aoliva@redhat.com
References: <20031029.163201.39178653.nemoto@toshiba-tops.co.jp> <20031029101400.J30683@mvista.com> <20031029181516.GA14443@nevyn.them.org> <20031030.215453.78703232.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031030.215453.78703232.nemoto@toshiba-tops.co.jp>
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: 3586
X-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: 7362
Lines: 139

On Thu, Oct 30, 2003 at 09:54:53PM +0900, Atsushi Nemoto wrote:
> >>>>> 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

Now this is very strange.  Please bear with me; I have the bad habit of
starting my email before I've fully figured out the problem...


MIPS, at least MIPS/Linux, has a very odd ELF ABI.  The following isn't
based on documentation, just on my reading of the glibc loader.  The
.got section is relocated implicitly; dynamic relocations aren't even
_used_ normally, in the single-GOT case.

First we have reserved entres; two of them.  Then local got entries;
DT_MIPS_LOCAL_GOTNO of them.  They get the library base added.  Then
global entries.  We start in the dynsym table at DT_MIPS_GOTSYM, and
count up to just under DT_MIPS_SYMTABNO; GOT entries are set to the
address of the referenced symbol.

The loader does not require or expect any dynamic relocations to refer
to the .got section.  It also doesn't seem to care what's there, at
least not for external functions - defined functions and sections are
another matter.  So it doesn't expect the relocation to be there. 


Now, here's the peculiar thing:
drow@nevyn:~/mips-got% readelf -Ds app | sort -n | grep UND
   55 3777: 00000000     0  NOTYPE   WEAK DEFAULT UND __gmon_start__
  768 1005: 00000000     0  NOTYPE   WEAK DEFAULT UND _Jv_RegisterClasses
  5231 8511: 00000000     0    FUNC GLOBAL DEFAULT UND __libc_start_main
  13350 4887: 00000000     0    FUNC GLOBAL DEFAULT UND getpid
  22116 8185: 00000000     0    FUNC GLOBAL DEFAULT UND printf
drow@nevyn:~/mips-got% readelf -Dr app                     

'REL' relocation section at offset 0x4d8700 contains 24 bytes:
 Offset     Info    Type            Sym.Value  Sym. Name
00000000  00000000 R_MIPS_NONE      
1001c53c  00342603 R_MIPS_REL32      00000000   getpid
100196c4  00566403 R_MIPS_REL32      00000000   printf


i.e. there are five undefined symbols, and I'm guessing that the ones
in the first created GOT don't get REL32 relocations emitted.

A little poking in binutils reveals that this is deliberate.  This
comment, from the multigot patch in January:
  /* A pointer to the primary got, i.e., the one that's going to get
     the implicit relocations from DT_MIPS_LOCAL_GOTNO and
     DT_MIPS_GOTSYM.  */
  struct mips_got_info *primary;

There's only one problem - it doesn't work the way that comment
suggests.  got[2] through got[DT_MIPS_LOCAL_GOTNO - 1] are relocated
by l_addr, as local GOT entries.  Then got[DT_MIPS_LOCAL_GOTNO] through
got[DT_MIPS_SYMTABNO - 1] are relocated as global GOT entries.  So
DT_MIPS_SYMTABNO is probably intended to be the number of symbols _used
by the primary GOT_.  Not the total size of .dynsym.


Reading the comments in elfxx-mips.c it looks like this shouldn't
even be happening; the global symbols should end up in the "master
GOT".  And there should be stubs.  But in my tests the stubs don't get
built, and the value in the GOT for getpid points to func0_4663.  And I
can't find code that ought to create them.  So I'm going to have to
punt to Alexandre for details.  A quick potential fix might be changing
DT_MIPS_SYMTABNO.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From echristo@redhat.com Tue Nov  4 17:55:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 17:55:52 +0000 (GMT)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:19 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225316AbTKDRzk>;
	Tue, 4 Nov 2003 17:55:40 +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 hA4HaFA30587;
	Tue, 4 Nov 2003 12:36:15 -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 hA4Hsoa30313;
	Tue, 4 Nov 2003 12:54:50 -0500
Received: from ghostwheel.sfbay.redhat.com (vpn50-45.rdu.redhat.com [172.16.50.45])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hA4HsjJ22142;
	Tue, 4 Nov 2003 09:54:45 -0800
Subject: Re: Huge dynamically linked program does not run on mips-linux
From: Eric Christopher <echristo@redhat.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>, jsun@mvista.com,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
In-Reply-To: <20031104.200222.70226623.nemoto@toshiba-tops.co.jp>
References: <1067480704.2542.8.camel@ghostwheel.sfbay.redhat.com>
	 <20031104.142111.41626869.nemoto@toshiba-tops.co.jp>
	 <1067933156.3491.5.camel@ghostwheel.sfbay.redhat.com>
	 <20031104.200222.70226623.nemoto@toshiba-tops.co.jp>
Content-Type: text/plain
Message-Id: <1067968386.3491.7.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Tue, 04 Nov 2003 09:53:06 -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: 3587
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 788
Lines: 24

On Tue, 2003-11-04 at 03:02, Atsushi Nemoto wrote:
> >>>>> On Tue, 04 Nov 2003 00:05:56 -0800, Eric Christopher <echristo@redhat.com> said:
> >> I tried binutils-2.14.90.0.7 (based on binutils 2003 1029 in CVS)
> >> but my problem did no solved.  It seems something is still wrong.
> 
> eric> This was plain mips-linux? Not mips64-linux?
> 
> Yes.  mips-linux and mipsel-linux target (host is i386).  Both target
> generate broken binary for my test program.
> 
> eric> And where would I find the sources?
> 
> I'm using plain binutils 2.14 and gcc 3.3.2 from gnu.org FTP site,
> binutils 2.14.90.0.7 from
> http://www.kernel.org/pub/linux/devel/binutils/.

I'm using mainline gcc, but I meant the python-qt sources you were
compiling.

-eric

-- 
Eric Christopher <echristo@redhat.com>


From macro@ds2.pg.gda.pl Tue Nov  4 18:48:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 18:48:23 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:62888 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225316AbTKDSsL>; Tue, 4 Nov 2003 18:48:11 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 7D4164C0CB; Tue,  4 Nov 2003 19:48:09 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 7111B4BFF3; Tue,  4 Nov 2003 19:48:09 +0100 (CET)
Date: Tue, 4 Nov 2003 19:48:09 +0100 (CET)
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: <20031103231010Z8225443-1272+8723@linux-mips.org>
Message-ID: <Pine.LNX.4.32.0311041939110.31563-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: 3588
X-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: 867
Lines: 21

On Mon, 3 Nov 2003 ralf@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: i8259.h
>
> Log message:
> 	Declare i8259A_lock spinlock.  New inline function i8259_irq to poll
> 	interrupts in a PC-style daisy-chained i8259 configuration where no
> 	better method to execute an interrupt acknowledge cycle is available.

 This is broken -- you do want to check bit #7 for spurious interrupts
instead of doing awkward PIC poking.  Alternatively, just skip the check
-- the condition is rare and handlers need to be able to deal with it
anyway.  It was discussed a few months ago and I proposed a correct patch
similar to your one, but it was rejected, sigh...

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


From chenli@nortelnetworks.com Tue Nov  4 23:39:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 23:40:04 +0000 (GMT)
Received: from zcars04f.nortelnetworks.com ([IPv6:::ffff:47.129.242.57]:23008
	"EHLO zcars04f.nortelnetworks.com") by linux-mips.org with ESMTP
	id <S8225402AbTKDXjc>; Tue, 4 Nov 2003 23:39:32 +0000
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA4NdOt01506
	for <linux-mips@linux-mips.org>; Tue, 4 Nov 2003 18:39:24 -0500 (EST)
Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id VRTPF5YL; Tue, 4 Nov 2003 18:39:25 -0500
Received: from americasm01.nt.com (wcary3hh.ca.nortel.com [47.129.112.118]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id V8PGYY3X; Tue, 4 Nov 2003 18:39:24 -0500
Message-ID: <3FA838AC.4040807@americasm01.nt.com>
Date: Tue, 04 Nov 2003 18:39:24 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: "Lijun Chen" <chenli@nortelnetworks.com>
Organization: Nortel Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: MIPS64 cross compiling errors: cpu-probe.c:167: error: unknown register
 name `accum' in `asm'
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <chenli@nortelnetworks.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3589
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chenli@nortelnetworks.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1855
Lines: 43

Hi,

I am cross compiling a 64-bit MIPS kernel for BCM1250. The cross 
compiler is
from Broadcom sbtools: mips64-linux-gcc. Now I got the following errors:

gcc -D__KERNEL__ -I/src/kernel/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer 
-I /src/kernel/include/asm/gcc -mabi=64 -G 0 -mno-abicalls -fno-pic 
-Wa,--trap -pipe -  -nostdinc -iwithprefix include 
-DKBUILD_BASENAME=cpu_probe  -c -o cpu-probe.o cpu-probe.c
cpu-probe.c: In function `align_mod':

cpu-probe.c:118: warning: asm operand 0 probably doesn't match constraints
cpu-probe.c:118: warning: asm operand 1 probably doesn't match constraints
cpu-probe.c: In function `mult_sh_align_mod':

cpu-probe.c:118: warning: asm operand 0 probably doesn't match constraints
cpu-probe.c:118: warning: asm operand 1 probably doesn't match constraints
cpu-probe.c:167: error: unknown register name `accum' in `asm'
cpu-probe.c:118: warning: asm operand 0 probably doesn't match constraints
cpu-probe.c:118: warning: asm operand 1 probably doesn't match constraints
cpu-probe.c: In function `check_mult_sh':

cpu-probe.c:167: error: unknown register name `accum' in `asm'
cpu-probe.c:167: error: unknown register name `accum' in `asm'
cpu-probe.c:167: error: unknown register name `accum' in `asm'
cpu-probe.c:167: error: unknown register name `accum' in `asm'
cpu-probe.c:167: error: unknown register name `accum' in `asm'
cpu-probe.c:167: error: unknown register name `accum' in `asm'
cpu-probe.c:167: error: unknown register name `accum' in `asm'
cpu-probe.c:167: error: unknown register name `accum' in `asm'

The gcc is a wrapper that is actually:
/usr/local/sbtools/x86-linux-rh6.0/mips64-linux-2.8.24/bin/mips64-linux-gcc 
-msb1-pass2-workarounds "$@"

The kernel is 2.4.22.

Any suggestions what is the cause? Thanks in advance.

Lijun


From anemo@mba.ocn.ne.jp Wed Nov  5 08:14:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Nov 2003 08:14:36 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:59921
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224985AbTKEIOE>; Wed, 5 Nov 2003 08:14:04 +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; 5 Nov 2003 08:14:25 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id hA58EG9X061126;
	Wed, 5 Nov 2003 17:14:17 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Wed, 05 Nov 2003 17:17:01 +0900 (JST)
Message-Id: <20031105.171701.42767326.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: define check_gcc before used (Re: CVS Update@-mips.org: linux)
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20031021232555Z8225529-1272+8229@linux-mips.org>
References: <20031021232555Z8225529-1272+8229@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
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: 3590
X-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: 1261
Lines: 38

>>>>> On Wed, 22 Oct 2003 00:25:50 +0100, ralf@linux-mips.org said:
ralf> CVSROOT:	/home/cvs
ralf> Module name:	linux
ralf> Changes by:	ralf@ftp.linux-mips.org	03/10/22 00:25:50

ralf> Modified files:
ralf> 	arch/mips      : Tag: linux_2_4 Makefile 
ralf> 	arch/mips64    : Tag: linux_2_4 Makefile 

ralf> Log message:
ralf> 	Make gcc try inlining functions really hard.

It seems mips64 Makefile does not pass "-finline-limit=100000" to gcc.
The "check_gcc" must be defined before used ?

diff -u linux-mips-cvs/arch/mips64/Makefile linux/arch/mips64/Makefile
--- linux-mips-cvs/arch/mips64/Makefile	Tue Nov  4 16:57:37 2003
+++ linux/arch/mips64/Makefile	Wed Nov  5 16:50:40 2003
@@ -24,6 +24,8 @@
 CROSS_COMPILE	= $(tool-prefix)
 endif
 
+check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
+
 #
 # The ELF GCC uses -G 0 -mabicalls -fpic as default.  We don't need PIC
 # code in the kernel since it only slows down the whole thing.  For the
@@ -47,8 +49,6 @@
 endif
 endif
 
-check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
-
 #
 # CPU-dependent compiler/assembler options for optimization.
 #
---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Thu Nov  6 16:53:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Nov 2003 16:54:18 +0000 (GMT)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:45769 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225492AbTKFQxo>; Thu, 6 Nov 2003 16:53:44 +0000
Received: from localhost (p7175-ipad30funabasi.chiba.ocn.ne.jp [221.184.82.175])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id D87D450D9; Fri,  7 Nov 2003 01:53:31 +0900 (JST)
Date: Fri, 07 Nov 2003 01:54:21 +0900 (JST)
Message-Id: <20031107.015421.55515336.anemo@mba.ocn.ne.jp>
To: echristo@redhat.com
Cc: ica2_ts@csv.ica.uni-stuttgart.de, 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: <1067968386.3491.7.camel@ghostwheel.sfbay.redhat.com>
References: <1067933156.3491.5.camel@ghostwheel.sfbay.redhat.com>
	<20031104.200222.70226623.nemoto@toshiba-tops.co.jp>
	<1067968386.3491.7.camel@ghostwheel.sfbay.redhat.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 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: 3591
X-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: 371
Lines: 13

>>>>> On Tue, 04 Nov 2003 09:53:06 -0800, Eric Christopher <echristo@redhat.com> said:

echristo> I'm using mainline gcc, but I meant the python-qt sources
echristo> you were compiling.

The link error of phyton-qt was reported by Thiemo Seufer.  I have not
tried it.

My problem is runtime failure, not link error.  So it may be a
different problem.

---
Atsushi Nemoto

From ica2_ts@csv.ica.uni-stuttgart.de Fri Nov  7 16:41:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Nov 2003 16:42:00 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:38267
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225310AbTKGQl2>; Fri, 7 Nov 2003 16:41:28 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1AI9f9-0005XZ-00; Fri, 07 Nov 2003 17:40:43 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1AI9f9-0008Iz-00; Fri, 07 Nov 2003 17:40:43 +0100
Date: Fri, 7 Nov 2003 17:40:43 +0100
To: Eric Christopher <echristo@redhat.com>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, jsun@mvista.com,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Huge dynamically linked program does not run on mips-linux
Message-ID: <20031107164043.GA24269@rembrandt.csv.ica.uni-stuttgart.de>
References: <1067480704.2542.8.camel@ghostwheel.sfbay.redhat.com> <20031104.142111.41626869.nemoto@toshiba-tops.co.jp> <1067933156.3491.5.camel@ghostwheel.sfbay.redhat.com> <20031104.200222.70226623.nemoto@toshiba-tops.co.jp> <1067968386.3491.7.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1067968386.3491.7.camel@ghostwheel.sfbay.redhat.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: 3592
X-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: 657
Lines: 22

Eric Christopher wrote:
[snip]
> > Yes.  mips-linux and mipsel-linux target (host is i386).  Both target
> > generate broken binary for my test program.
> > 
> > eric> And where would I find the sources?
> > 
> > I'm using plain binutils 2.14 and gcc 3.3.2 from gnu.org FTP site,
> > binutils 2.14.90.0.7 from
> > http://www.kernel.org/pub/linux/devel/binutils/.
> 
> I'm using mainline gcc, but I meant the python-qt sources you were
> compiling.

It was python-qt-3.8 from debian unstable, compiled with
"gcc (GCC) 3.3.2 (Debian)" and binutils
"2.14.90.0.7 20031029 Debian GNU/Linux"

An attempt to link with CVS ld shows the same BFD assertion.


Thiemo

From echristo@redhat.com Fri Nov  7 20:52:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Nov 2003 20:52:46 +0000 (GMT)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:14852 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225310AbTKGUwe>;
	Fri, 7 Nov 2003 20:52:34 +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 hA7KX6A07898;
	Fri, 7 Nov 2003 15:33:06 -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 hA7Kpqa30043;
	Fri, 7 Nov 2003 15:51:52 -0500
Received: from ghostwheel.sfbay.redhat.com (vpn26-5.sfbay.redhat.com [172.16.26.5])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hA7KpoJ19291;
	Fri, 7 Nov 2003 12:51:50 -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: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, jsun@mvista.com,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
In-Reply-To: <20031107164043.GA24269@rembrandt.csv.ica.uni-stuttgart.de>
References: <1067480704.2542.8.camel@ghostwheel.sfbay.redhat.com>
	 <20031104.142111.41626869.nemoto@toshiba-tops.co.jp>
	 <1067933156.3491.5.camel@ghostwheel.sfbay.redhat.com>
	 <20031104.200222.70226623.nemoto@toshiba-tops.co.jp>
	 <1067968386.3491.7.camel@ghostwheel.sfbay.redhat.com>
	 <20031107164043.GA24269@rembrandt.csv.ica.uni-stuttgart.de>
Content-Type: text/plain
Message-Id: <1068238309.5943.0.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Fri, 07 Nov 2003 12:51:49 -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: 3593
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 492
Lines: 20


> > I'm using mainline gcc, but I meant the python-qt sources you were
> > compiling.
> 
> It was python-qt-3.8 from debian unstable, compiled with
> "gcc (GCC) 3.3.2 (Debian)" and binutils
> "2.14.90.0.7 20031029 Debian GNU/Linux"
> 
> An attempt to link with CVS ld shows the same BFD assertion.

OK. Well, the one machine I have has current sources for gcc and
binutils so I'll be trying that :)

Pointer to a tarball with the sources?

-eric

-- 
Eric Christopher <echristo@redhat.com>


From ashish_ibm@rediffmail.com Fri Nov  7 20:55:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Nov 2003 20:56:21 +0000 (GMT)
Received: from webmail30.rediffmail.com ([IPv6:::ffff:202.54.124.145]:29595
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225310AbTKGUzt>; Fri, 7 Nov 2003 20:55:49 +0000
Received: (qmail 4969 invoked by uid 510); 7 Nov 2003 20:53:46 -0000
Date: 7 Nov 2003 20:53:46 -0000
Message-ID: <20031107205346.4968.qmail@webmail30.rediffmail.com>
Received: from unknown (210.210.7.195) by rediffmail.com via HTTP; 07 nov 2003 20:53:46 -0000
MIME-Version: 1.0
From: "ashish  anand" <ashish_ibm@rediffmail.com>
Reply-To: "ashish  anand" <ashish_ibm@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: printing kernelsp causing crash..
Content-type: multipart/alternative;
	boundary="Next_1068238426---0-202.54.124.145-4966"
Return-Path: <ashish_ibm@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3594
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish_ibm@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1444
Lines: 31

 This is a multipart mime message


--Next_1068238426---0-202.54.124.145-4966
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0AHello,<BR>=0Awhile I am yet to debug , I observed that printing kerne=
lsp<BR>=0Amakes kernel crashing .<BR>=0A<BR>=0AI inserted print statement a=
fter loadmmu() / before start_kernel and due to this print my kernel crashe=
s exactly after printing<BR>=0A&quot;POSIX conformance testing by UNIFIX&qu=
ot; .<BR>=0A<BR>=0Athis happens only if I print kernelsp.<BR>=0A<BR>=0ABest=
 Regards,<BR>=0AAshish Anand=0A</P>=0A<br><br>=0A<A target=3D"_blank" HREF=
=3D"http://clients.rediff.com/signature/track_sig.asp"><IMG SRC=3D"http://a=
ds.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bo=
ttom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0 HEIGHT=3D74 WIDTH=3D496></a>=0A
--Next_1068238426---0-202.54.124.145-4966
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,=0Awhile I am yet to debug , I observed that printing kernelsp=0Amake=
s kernel crashing .=0A=0AI inserted print statement after loadmmu() / befor=
e start_kernel and due to this print my kernel crashes exactly after printi=
ng=0A"POSIX conformance testing by UNIFIX" .=0A=0Athis happens only if I pr=
int kernelsp.=0A=0ABest Regards,=0AAshish Anand
--Next_1068238426---0-202.54.124.145-4966--


From alanliu@trident.com.cn Tue Nov 11 02:59:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 02:59:48 +0000 (GMT)
Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:5903
	"EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP
	id <S8225379AbTKKC7h>; Tue, 11 Nov 2003 02:59:37 +0000
Received: by TMTMS with Internet Mail Service (5.5.2653.19)
	id <WT9PV48W>; Tue, 11 Nov 2003 10:52:29 +0800
Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F6801C99461@TMTMS>
From: "Liu Hongming (Alan)" <alanliu@trident.com.cn>
To: Adeel Malik <AdeelM@quartics.com>, linux-mips@linux-mips.org
Subject: RE: How to request an IRQ for NMI on MIPS Processor
Date: Tue, 11 Nov 2003 10:51:50 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3A7FE.C148C790"
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: 3595
X-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: 5945
Lines: 117

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_01C3A7FE.C148C790
Content-Type: text/plain;
	charset="ISO-8859-1"

hi Malik,

when using request_irq(...),the parameter irq is a value specified by you,
of course,when porting linux for your board,you should have specified value
for every IRQ. 0--5 only means CPU pin for interrupt,unless that only one
interrupt
may occur on this pin,you will use other value in request_irq,instead of
0-5.
 
all in all, when we touch request_irq,it is board specific.When your board
has
been made out,all interrupts have specific route to cpu(unless you have IRQ
router,since embedded,need this??).If you have more external interrupts than
cpu pins,maybe you have cascaded many interrupt using one cpu pin.So,
the parameter irq in request_irq is determined by your board and your
porting
for interrupt handling.Just ask that guy that ported linux.He will tell
you.If you
are using linux ported by others,have a look at BSP codes.
 
Regards,
Alan Liu
 
-----Original Message-----
From: Adeel Malik [mailto:AdeelM@quartics.com]
Sent: Tuesday, November 04, 2003 7:56 PM
To: linux-mips@linux-mips.org
Subject: How to request an IRQ for NMI on MIPS Processor


Hi All,
          In my embedded design, I intend to use NMI of MIPS 4Kc processor
(rather than IRQ0 or IRQ1 .....) for an external Interrupt Source. The
external Interrupt source is a video capture device which interrupts the
MIPS 4Kc CPU via its NMI (Non-Maskable Interrupt) line, whenever it has one
complete frame. I need to write the driver for that device in Linux-2.4.20.
The request_irq function provided by Linux takes a digit value from 0 to 5
to map external interrupt sources to any one of CPUs Interrupt pins. How can
I request and implement my interrupt handler routine for the NMI of MIPS
processor ?.
 
Regards,
ADEEL MALIK,


------_=_NextPart_001_01C3A7FE.C148C790
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>hi<SPAN class=592214802-11112003> Malik</SPAN>,</FONT></DIV>
<DIV><FONT size=2><BR>when using request_irq<SPAN 
class=592214802-11112003>(...),the parameter irq is a value specified by 
you,</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>of course,when porting linux 
for your board,you should have specified value</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>for every IRQ. 0--5 only means 
CPU pin for interrupt,unless that only one interrupt</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>may occur on this pin,you 
will&nbsp;use&nbsp;other value&nbsp;in request_irq,instead of 
0-5.</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>all in all, when we touch 
request_irq,it is board specific.When your board has</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>been made out,all interrupts 
have specific route to cpu(unless you have IRQ</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>router,since embedded,need 
this??).If you have&nbsp;more external interrupts than</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>cpu pins,maybe you have 
cascaded many interrupt using one cpu pin.So,</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>the parameter irq in 
request_irq is determined by your board and your porting</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>for interrupt handling.Just ask 
that guy that ported linux.He will tell you.If you</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>are using linux ported by 
others,have a look at BSP codes.</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>Regards,</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003>Alan Liu</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=592214802-11112003></SPAN></FONT><FONT 
size=2><SPAN class=592214802-11112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman" size=2>-----Original 
Message-----<BR><B>From:</B> Adeel Malik 
[mailto:AdeelM@quartics.com]<BR><B>Sent:</B> Tuesday, November 04, 2003 7:56 
PM<BR><B>To:</B> linux-mips@linux-mips.org<BR><B>Subject:</B> How to request an 
IRQ for NMI on MIPS Processor<BR><BR></FONT></DIV>
<DIV><SPAN class=276362111-04112003><FONT size=2>Hi All,</FONT></SPAN></DIV>
<DIV><SPAN class=276362111-04112003><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In my 
embedded&nbsp;design, I&nbsp;intend to use NMI of MIPS 4Kc processor (rather 
than IRQ0 or IRQ1 .....) for an external Interrupt Source. The external 
Interrupt source is a video capture device which interrupts the MIPS 4Kc CPU via 
its NMI (Non-Maskable Interrupt) line,&nbsp;whenever it has one complete frame. 
I need to write the driver for that device in Linux-2.4.20. The 
<STRONG>request_irq</STRONG> function provided by Linux takes&nbsp;a 
digit&nbsp;value from 0 to 5 to map external interrupt sources to any one of 
CPUs Interrupt pins. How can I request and implement my interrupt handler 
routine for the NMI of MIPS processor ?.</FONT></SPAN></DIV>
<DIV><SPAN class=276362111-04112003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=276362111-04112003><FONT size=2>Regards,</FONT></SPAN></DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM>ADEEL MALIK,</EM></FONT></DIV>
<P><FONT size=2></FONT></P></BODY></HTML>

------_=_NextPart_001_01C3A7FE.C148C790--

From ralf@linux-mips.org Tue Nov 11 03:40:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 03:40:42 +0000 (GMT)
Received: from p508B68E7.dip.t-dialin.net ([IPv6:::ffff:80.139.104.231]:743
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225379AbTKKDka>; Tue, 11 Nov 2003 03:40:30 +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 hAB3eJsY023467;
	Tue, 11 Nov 2003 04:40:19 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAB3eCT0023466;
	Tue, 11 Nov 2003 04:40:12 +0100
Date: Tue, 11 Nov 2003 04:40:12 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Liu Hongming (Alan)" <alanliu@trident.com.cn>
Cc: Adeel Malik <AdeelM@quartics.com>, linux-mips@linux-mips.org
Subject: Re: How to request an IRQ for NMI on MIPS Processor
Message-ID: <20031111034012.GA23100@linux-mips.org>
References: <15F9E1AE3207D6119CEA00D0B7DD5F6801C99461@TMTMS>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15F9E1AE3207D6119CEA00D0B7DD5F6801C99461@TMTMS>
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: 3596
X-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: 2385
Lines: 46

Liu,

On Tue, Nov 11, 2003 at 10:51:50AM +0800, Liu Hongming (Alan) wrote:

> when using request_irq(...),the parameter irq is a value specified by you,
> of course,when porting linux for your board,you should have specified value
> for every IRQ. 0--5 only means CPU pin for interrupt,unless that only one
> interrupt
> may occur on this pin,you will use other value in request_irq,instead of
> 0-5.
>  
> all in all, when we touch request_irq,it is board specific.When your board
> has
> been made out,all interrupts have specific route to cpu(unless you have IRQ
> router,since embedded,need this??).If you have more external interrupts than
> cpu pins,maybe you have cascaded many interrupt using one cpu pin.So,
> the parameter irq in request_irq is determined by your board and your
> porting
> for interrupt handling.Just ask that guy that ported linux.He will tell
> you.If you
> are using linux ported by others,have a look at BSP codes.

your answer is correct for normal interrupts, not the NMI.  The NMI goes
through the firmware and none of the board support code so far bothered
to make it available via request_irq as it has several severe limitations.
To repeat one of my prior postings about the NMI:

NMI on MIPS is pretty much miss-designed for use in application code; it's
use should be limited to debugging and recovery from catastrophical
failure.  The reason for this is the way this exception is handled:
                                                                                
  - the BEV, TS, SR, NMI and ERL bits in c0_status are overwritten - that is
    their old state is lost.
  - c0_errorepc is overwritten - again that means the old value is lost so
    in case the NMI interrupts an exception handler that uses this register
    such as the cache error handler you can not resume execution.
  - the program counter is set to 0xbfc00000.  Most likely a slow flash
    memory is mapped at this address but in any case it's an uncached
    segment of the address space so execution will be even slower.
  - execution will pass through the firmware.  That means you can only
    use the NMI at all if firmware provides some kind of hook.
                                                                                
It seems pretty clear to me that the MIPS designers never intended the
NMI for anything else than catastrophic events.

  Ralf

From alanliu@trident.com.cn Tue Nov 11 04:46:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 04:47:04 +0000 (GMT)
Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:40964
	"EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP
	id <S8225361AbTKKEqw>; Tue, 11 Nov 2003 04:46:52 +0000
Received: by TMTMS with Internet Mail Service (5.5.2653.19)
	id <WT9PVVJL>; Tue, 11 Nov 2003 12:39:48 +0800
Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F6801C99492@TMTMS>
From: "Liu Hongming (Alan)" <alanliu@trident.com.cn>
To: Ralf Baechle <ralf@linux-mips.org>,
	"Liu Hongming (Alan)" <alanliu@trident.com.cn>
Cc: Adeel Malik <AdeelM@quartics.com>, linux-mips@linux-mips.org
Subject: RE: How to request an IRQ for NMI on MIPS Processor
Date: Tue, 11 Nov 2003 12:39:04 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3A80D.BC891ED0"
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: 3597
X-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: 9391
Lines: 233

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_01C3A80D.BC891ED0
Content-Type: text/plain;
	charset="ISO-8859-1"


Hi Ralf,

I have never used these kind of boards.It seems to me 
NMI is implemented by interrupt controller,to cpu,it is a 
normal interrupt source.If 'NMI' in Adeel's board is like 
what you repeated,request_irq could just use cpu's pin number
as the 'irq' parameter. I think NMI has been used in many
boards that only means 'non-maskable' to interrupt controller,
not cpu. If it is this case, NMI interrupt is a normal case.

Regards,
Alan Liu

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Tuesday, November 11, 2003 11:40 AM
To: Liu Hongming (Alan)
Cc: Adeel Malik; linux-mips@linux-mips.org
Subject: Re: How to request an IRQ for NMI on MIPS Processor


Liu,

On Tue, Nov 11, 2003 at 10:51:50AM +0800, Liu Hongming (Alan) wrote:

> when using request_irq(...),the parameter irq is a value specified by you,
> of course,when porting linux for your board,you should have specified
value
> for every IRQ. 0--5 only means CPU pin for interrupt,unless that only one
> interrupt
> may occur on this pin,you will use other value in request_irq,instead of
> 0-5.
>  
> all in all, when we touch request_irq,it is board specific.When your board
> has
> been made out,all interrupts have specific route to cpu(unless you have
IRQ
> router,since embedded,need this??).If you have more external interrupts
than
> cpu pins,maybe you have cascaded many interrupt using one cpu pin.So,
> the parameter irq in request_irq is determined by your board and your
> porting
> for interrupt handling.Just ask that guy that ported linux.He will tell
> you.If you
> are using linux ported by others,have a look at BSP codes.

your answer is correct for normal interrupts, not the NMI.  The NMI goes
through the firmware and none of the board support code so far bothered
to make it available via request_irq as it has several severe limitations.
To repeat one of my prior postings about the NMI:

NMI on MIPS is pretty much miss-designed for use in application code; it's
use should be limited to debugging and recovery from catastrophical
failure.  The reason for this is the way this exception is handled:
 

  - the BEV, TS, SR, NMI and ERL bits in c0_status are overwritten - that is
    their old state is lost.
  - c0_errorepc is overwritten - again that means the old value is lost so
    in case the NMI interrupts an exception handler that uses this register
    such as the cache error handler you can not resume execution.
  - the program counter is set to 0xbfc00000.  Most likely a slow flash
    memory is mapped at this address but in any case it's an uncached
    segment of the address space so execution will be even slower.
  - execution will pass through the firmware.  That means you can only
    use the NMI at all if firmware provides some kind of hook.
 

It seems pretty clear to me that the MIPS designers never intended the
NMI for anything else than catastrophic events.

  Ralf

------_=_NextPart_001_01C3A80D.BC891ED0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: How to request an IRQ for NMI on MIPS Processor</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Hi Ralf,</FONT>
</P>

<P><FONT SIZE=3D2>I have never used these kind of boards.It seems to me =
</FONT>
<BR><FONT SIZE=3D2>NMI is implemented by interrupt controller,to cpu,it =
is a </FONT>
<BR><FONT SIZE=3D2>normal interrupt source.If 'NMI' in Adeel's board is =
like </FONT>
<BR><FONT SIZE=3D2>what you repeated,request_irq could just use cpu's =
pin number</FONT>
<BR><FONT SIZE=3D2>as the 'irq' parameter. I think NMI has been used in =
many</FONT>
<BR><FONT SIZE=3D2>boards that only means 'non-maskable' to interrupt =
controller,</FONT>
<BR><FONT SIZE=3D2>not cpu. If it is this case, NMI interrupt is a =
normal case.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Alan Liu</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ralf Baechle [<A =
HREF=3D"mailto:ralf@linux-mips.org">mailto:ralf@linux-mips.org</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 11, 2003 11:40 AM</FONT>
<BR><FONT SIZE=3D2>To: Liu Hongming (Alan)</FONT>
<BR><FONT SIZE=3D2>Cc: Adeel Malik; linux-mips@linux-mips.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: How to request an IRQ for NMI on MIPS =
Processor</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Liu,</FONT>
</P>

<P><FONT SIZE=3D2>On Tue, Nov 11, 2003 at 10:51:50AM +0800, Liu =
Hongming (Alan) wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; when using request_irq(...),the parameter irq is =
a value specified by you,</FONT>
<BR><FONT SIZE=3D2>&gt; of course,when porting linux for your board,you =
should have specified value</FONT>
<BR><FONT SIZE=3D2>&gt; for every IRQ. 0--5 only means CPU pin for =
interrupt,unless that only one</FONT>
<BR><FONT SIZE=3D2>&gt; interrupt</FONT>
<BR><FONT SIZE=3D2>&gt; may occur on this pin,you will use other value =
in request_irq,instead of</FONT>
<BR><FONT SIZE=3D2>&gt; 0-5.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; all in all, when we touch request_irq,it is =
board specific.When your board</FONT>
<BR><FONT SIZE=3D2>&gt; has</FONT>
<BR><FONT SIZE=3D2>&gt; been made out,all interrupts have specific =
route to cpu(unless you have IRQ</FONT>
<BR><FONT SIZE=3D2>&gt; router,since embedded,need this??).If you have =
more external interrupts than</FONT>
<BR><FONT SIZE=3D2>&gt; cpu pins,maybe you have cascaded many interrupt =
using one cpu pin.So,</FONT>
<BR><FONT SIZE=3D2>&gt; the parameter irq in request_irq is determined =
by your board and your</FONT>
<BR><FONT SIZE=3D2>&gt; porting</FONT>
<BR><FONT SIZE=3D2>&gt; for interrupt handling.Just ask that guy that =
ported linux.He will tell</FONT>
<BR><FONT SIZE=3D2>&gt; you.If you</FONT>
<BR><FONT SIZE=3D2>&gt; are using linux ported by others,have a look at =
BSP codes.</FONT>
</P>

<P><FONT SIZE=3D2>your answer is correct for normal interrupts, not the =
NMI.&nbsp; The NMI goes</FONT>
<BR><FONT SIZE=3D2>through the firmware and none of the board support =
code so far bothered</FONT>
<BR><FONT SIZE=3D2>to make it available via request_irq as it has =
several severe limitations.</FONT>
<BR><FONT SIZE=3D2>To repeat one of my prior postings about the =
NMI:</FONT>
</P>

<P><FONT SIZE=3D2>NMI on MIPS is pretty much miss-designed for use in =
application code; it's</FONT>
<BR><FONT SIZE=3D2>use should be limited to debugging and recovery from =
catastrophical</FONT>
<BR><FONT SIZE=3D2>failure.&nbsp; The reason for this is the way this =
exception is handled:</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp; - the BEV, TS, SR, NMI and ERL bits in =
c0_status are overwritten - that is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; their old state is lost.</FONT>
<BR><FONT SIZE=3D2>&nbsp; - c0_errorepc is overwritten - again that =
means the old value is lost so</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; in case the NMI interrupts an =
exception handler that uses this register</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; such as the cache error handler =
you can not resume execution.</FONT>
<BR><FONT SIZE=3D2>&nbsp; - the program counter is set to =
0xbfc00000.&nbsp; Most likely a slow flash</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; memory is mapped at this address =
but in any case it's an uncached</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; segment of the address space so =
execution will be even slower.</FONT>
<BR><FONT SIZE=3D2>&nbsp; - execution will pass through the =
firmware.&nbsp; That means you can only</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; use the NMI at all if firmware =
provides some kind of hook.</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>It seems pretty clear to me that the MIPS designers =
never intended the</FONT>
<BR><FONT SIZE=3D2>NMI for anything else than catastrophic =
events.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; Ralf</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3A80D.BC891ED0--

From AdeelM@quartics.com Tue Nov 11 05:22:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 05:22:48 +0000 (GMT)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:3552
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225361AbTKKFWg>; Tue, 11 Nov 2003 05:22:36 +0000
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <WHAQ22D7>; Tue, 11 Nov 2003 10:21:56 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264F662@1aurora.enabtech>
From: Adeel Malik <AdeelM@quartics.com>
To: "Liu Hongming (Alan)" <alanliu@trident.com.cn>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: RE: How to request an IRQ for NMI on MIPS Processor
Date: Tue, 11 Nov 2003 10:21:52 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3A813.B8F095B0"
Return-Path: <AdeelM@quartics.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3598
X-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@quartics.com
Precedence: bulk
X-list: linux-mips
Content-Length: 13451
Lines: 244

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_01C3A813.B8F095B0
Content-Type: text/plain;
	charset="iso-8859-1"

Liu,
      In my board the interrupt was routed directly to an NMI line of MIPS
CPU rather than regular IRQs 0 - 5.   I went through the MIPS Architecture
Programming Guide Document, describing Interrupt and Exception Handling for
MIPS Processor. It is written there that although a Non-Maskable Interrupt
(NMI) includes "interrupt" in its name, it is more correctly described as an
NMI exception because it does not affect, nor is it controlled by the
processor interrupt system. 
 
Secondly, Linux Kernel especially the Embedded Linux Versions for various
Processors doesn't support the use of NMI as a regular IRQ.
 
The Interrupt Vector Address of all the Hardware Interrupt from IRQ0 - IRQ5
for MIPS Processor have the same vector location that is 0x80000180 or
0x80000380 which is a cached access, but the vector Location of NMI is
0xbfc00000 which is an un-cached access. So one needs to modify the
boot-code which is error-prone if it is possible at all.
 
Thatswhy we don't find much code related to NMIs in Linux.
 
ADEEL MALIK,

-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Liu Hongming (Alan)
Sent: Tuesday, November 11, 2003 9:39 AM
To: Ralf Baechle; Liu Hongming (Alan)
Cc: Adeel Malik; linux-mips@linux-mips.org
Subject: RE: How to request an IRQ for NMI on MIPS Processor




Hi Ralf, 

I have never used these kind of boards.It seems to me 
NMI is implemented by interrupt controller,to cpu,it is a 
normal interrupt source.If 'NMI' in Adeel's board is like 
what you repeated,request_irq could just use cpu's pin number 
as the 'irq' parameter. I think NMI has been used in many 
boards that only means 'non-maskable' to interrupt controller, 
not cpu. If it is this case, NMI interrupt is a normal case. 

Regards, 
Alan Liu 

-----Original Message----- 
From: Ralf Baechle [ mailto:ralf@linux-mips.org <mailto:ralf@linux-mips.org>
] 
Sent: Tuesday, November 11, 2003 11:40 AM 
To: Liu Hongming (Alan) 
Cc: Adeel Malik; linux-mips@linux-mips.org 
Subject: Re: How to request an IRQ for NMI on MIPS Processor 


Liu, 

On Tue, Nov 11, 2003 at 10:51:50AM +0800, Liu Hongming (Alan) wrote: 

> when using request_irq(...),the parameter irq is a value specified by you,

> of course,when porting linux for your board,you should have specified
value 
> for every IRQ. 0--5 only means CPU pin for interrupt,unless that only one 
> interrupt 
> may occur on this pin,you will use other value in request_irq,instead of 
> 0-5. 
>  
> all in all, when we touch request_irq,it is board specific.When your board

> has 
> been made out,all interrupts have specific route to cpu(unless you have
IRQ 
> router,since embedded,need this??).If you have more external interrupts
than 
> cpu pins,maybe you have cascaded many interrupt using one cpu pin.So, 
> the parameter irq in request_irq is determined by your board and your 
> porting 
> for interrupt handling.Just ask that guy that ported linux.He will tell 
> you.If you 
> are using linux ported by others,have a look at BSP codes. 

your answer is correct for normal interrupts, not the NMI.  The NMI goes 
through the firmware and none of the board support code so far bothered 
to make it available via request_irq as it has several severe limitations. 
To repeat one of my prior postings about the NMI: 

NMI on MIPS is pretty much miss-designed for use in application code; it's 
use should be limited to debugging and recovery from catastrophical 
failure.  The reason for this is the way this exception is handled: 
 

  - the BEV, TS, SR, NMI and ERL bits in c0_status are overwritten - that is

    their old state is lost. 
  - c0_errorepc is overwritten - again that means the old value is lost so 
    in case the NMI interrupts an exception handler that uses this register 
    such as the cache error handler you can not resume execution. 
  - the program counter is set to 0xbfc00000.  Most likely a slow flash 
    memory is mapped at this address but in any case it's an uncached 
    segment of the address space so execution will be even slower. 
  - execution will pass through the firmware.  That means you can only 
    use the NMI at all if firmware provides some kind of hook. 
 

It seems pretty clear to me that the MIPS designers never intended the 
NMI for anything else than catastrophic events. 

  Ralf 


------_=_NextPart_001_01C3A813.B8F095B0
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">
<TITLE>RE: How to request an IRQ for NMI on MIPS Processor</TITLE>

<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY hb_focus_attach="true">
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=118040205-11112003>Liu,</SPAN></FONT></DIV>
<DIV><FONT size=2><FONT face=Arial color=#0000ff><SPAN 
class=118040205-11112003>&nbsp;&nbsp;&nbsp;<FONT face="Times New Roman" 
color=#000000>&nbsp;&nbsp; In my board the interrupt 
was&nbsp;routed&nbsp;directly&nbsp;to an NMI line of MIPS&nbsp;CPU rather than 
regular IRQs 0 - 5.&nbsp;&nbsp;&nbsp;I&nbsp;went through 
the</FONT></SPAN></FONT> MIPS Architecture Programming Guide Document<SPAN 
class=118040205-11112003>,&nbsp;describing Interrupt and Exception Handling for 
MIPS Processor. It is written there</SPAN>&nbsp;that&nbsp;<U><SPAN 
class=118040205-11112003>a</SPAN>lthough a Non-Maskable Interrupt (NMI) 
includes<SPAN class=118040205-11112003> </SPAN>"interrupt" in its name, it is 
more correctly described as an NMI exception because it does not affect, nor is 
it controlled<SPAN class=118040205-11112003> </SPAN>by the processor interrupt 
system.</U> </FONT></DIV>
<DIV><U><FONT size=2></FONT></U>&nbsp;</DIV>
<DIV><SPAN class=118040205-11112003><FONT size=2>Secondly, Linux Kernel 
especially the Embedded Linux Versions for various Processors doesn't support 
the use of NMI as a regular IRQ.</FONT></SPAN></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=118040205-11112003>The</SPAN>&nbsp;Interrupt 
Vector Address of all the Hardware Interrupt from IRQ0 - IRQ5<SPAN 
class=118040205-11112003> for MIPS Processor</SPAN>&nbsp;have the same vector 
location that is 0x80000180&nbsp;<SPAN class=118040205-11112003>or 0x80000380 
</SPAN>which is a cached access, but the vector Location of NMI is 0xbfc00000 
which is an un-cached access. So&nbsp;<SPAN class=118040205-11112003>one</SPAN> 
need<SPAN class=118040205-11112003>s</SPAN> to modify the boot-code 
which&nbsp;<SPAN class=118040205-11112003>is </SPAN>error-prone if it is 
possible at all.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Thatswhy we don't find much code related to NMIs in 
Linux.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM>ADEEL MALIK,</EM></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> 
  linux-mips-bounce@linux-mips.org 
  [mailto:linux-mips-bounce@linux-mips.org]<B>On Behalf Of </B>Liu Hongming 
  (Alan)<BR><B>Sent:</B> Tuesday, November 11, 2003 9:39 AM<BR><B>To:</B> Ralf 
  Baechle; Liu Hongming (Alan)<BR><B>Cc:</B> Adeel Malik; 
  linux-mips@linux-mips.org<BR><B>Subject:</B> RE: How to request an IRQ for NMI 
  on MIPS Processor<BR><BR></FONT></DIV><BR>
  <P><FONT size=2>Hi Ralf,</FONT> </P>
  <P><FONT size=2>I have never used these kind of boards.It seems to me 
  </FONT><BR><FONT size=2>NMI is implemented by interrupt controller,to cpu,it 
  is a </FONT><BR><FONT size=2>normal interrupt source.If 'NMI' in Adeel's board 
  is like </FONT><BR><FONT size=2>what you repeated,request_irq could just use 
  cpu's pin number</FONT> <BR><FONT size=2>as the 'irq' parameter. I think NMI 
  has been used in many</FONT> <BR><FONT size=2>boards that only means 
  'non-maskable' to interrupt controller,</FONT> <BR><FONT size=2>not cpu. If it 
  is this case, NMI interrupt is a normal case.</FONT> </P>
  <P><FONT size=2>Regards,</FONT> <BR><FONT size=2>Alan Liu</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, November 11, 2003 11:40 AM</FONT> <BR><FONT 
  size=2>To: Liu Hongming (Alan)</FONT> <BR><FONT size=2>Cc: Adeel Malik; 
  linux-mips@linux-mips.org</FONT> <BR><FONT size=2>Subject: Re: How to request 
  an IRQ for NMI on MIPS Processor</FONT> </P><BR>
  <P><FONT size=2>Liu,</FONT> </P>
  <P><FONT size=2>On Tue, Nov 11, 2003 at 10:51:50AM +0800, Liu Hongming (Alan) 
  wrote:</FONT> </P>
  <P><FONT size=2>&gt; when using request_irq(...),the parameter irq is a value 
  specified by you,</FONT> <BR><FONT size=2>&gt; of course,when porting linux 
  for your board,you should have specified value</FONT> <BR><FONT size=2>&gt; 
  for every IRQ. 0--5 only means CPU pin for interrupt,unless that only 
  one</FONT> <BR><FONT size=2>&gt; interrupt</FONT> <BR><FONT size=2>&gt; may 
  occur on this pin,you will use other value in request_irq,instead of</FONT> 
  <BR><FONT size=2>&gt; 0-5.</FONT> <BR><FONT size=2>&gt;&nbsp; </FONT><BR><FONT 
  size=2>&gt; all in all, when we touch request_irq,it is board specific.When 
  your board</FONT> <BR><FONT size=2>&gt; has</FONT> <BR><FONT size=2>&gt; been 
  made out,all interrupts have specific route to cpu(unless you have IRQ</FONT> 
  <BR><FONT size=2>&gt; router,since embedded,need this??).If you have more 
  external interrupts than</FONT> <BR><FONT size=2>&gt; cpu pins,maybe you have 
  cascaded many interrupt using one cpu pin.So,</FONT> <BR><FONT size=2>&gt; the 
  parameter irq in request_irq is determined by your board and your</FONT> 
  <BR><FONT size=2>&gt; porting</FONT> <BR><FONT size=2>&gt; for interrupt 
  handling.Just ask that guy that ported linux.He will tell</FONT> <BR><FONT 
  size=2>&gt; you.If you</FONT> <BR><FONT size=2>&gt; are using linux ported by 
  others,have a look at BSP codes.</FONT> </P>
  <P><FONT size=2>your answer is correct for normal interrupts, not the 
  NMI.&nbsp; The NMI goes</FONT> <BR><FONT size=2>through the firmware and none 
  of the board support code so far bothered</FONT> <BR><FONT size=2>to make it 
  available via request_irq as it has several severe limitations.</FONT> 
  <BR><FONT size=2>To repeat one of my prior postings about the NMI:</FONT> </P>
  <P><FONT size=2>NMI on MIPS is pretty much miss-designed for use in 
  application code; it's</FONT> <BR><FONT size=2>use should be limited to 
  debugging and recovery from catastrophical</FONT> <BR><FONT 
  size=2>failure.&nbsp; The reason for this is the way this exception is 
  handled:</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT size=2>&nbsp; - the BEV, TS, SR, NMI and ERL bits in 
  c0_status are overwritten - that is</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; 
  their old state is lost.</FONT> <BR><FONT size=2>&nbsp; - c0_errorepc is 
  overwritten - again that means the old value is lost so</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp; in case the NMI interrupts an exception handler that 
  uses this register</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; such as the 
  cache error handler you can not resume execution.</FONT> <BR><FONT 
  size=2>&nbsp; - the program counter is set to 0xbfc00000.&nbsp; Most likely a 
  slow flash</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; memory is mapped at this 
  address but in any case it's an uncached</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp; segment of the address space so execution will be 
  even slower.</FONT> <BR><FONT size=2>&nbsp; - execution will pass through the 
  firmware.&nbsp; That means you can only</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp; use the NMI at all if firmware provides some kind of 
  hook.</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT size=2>It seems pretty clear to me that the MIPS designers 
  never intended the</FONT> <BR><FONT size=2>NMI for anything else than 
  catastrophic events.</FONT> </P>
  <P><FONT size=2>&nbsp; Ralf</FONT> </P></BLOCKQUOTE>
<P></P></BODY></HTML>

------_=_NextPart_001_01C3A813.B8F095B0--

From alanliu@trident.com.cn Tue Nov 11 05:34:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 05:35:03 +0000 (GMT)
Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:60936
	"EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP
	id <S8225361AbTKKFev>; Tue, 11 Nov 2003 05:34:51 +0000
Received: by TMTMS with Internet Mail Service (5.5.2653.19)
	id <WT9PVVPG>; Tue, 11 Nov 2003 13:27:48 +0800
Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F6801C9949F@TMTMS>
From: "Liu Hongming (Alan)" <alanliu@trident.com.cn>
To: Adeel Malik <AdeelM@quartics.com>,
	"Liu Hongming (Alan)" <alanliu@trident.com.cn>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: RE: How to request an IRQ for NMI on MIPS Processor
Date: Tue, 11 Nov 2003 13:26:53 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3A814.6A4B7C10"
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: 3599
X-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: 16466
Lines: 302

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_01C3A814.6A4B7C10
Content-Type: text/plain;
	charset="ISO-8859-1"

 
Hi Adeel,
 
I have understood your situation.
 
Under this situation,I think you need not use request_irq.
Just keep your 'interrupt' handler in BIOS or bootloader,
of course,it is different with Rest Exception,since 
many registers' status are not the same as hardware-reseting.
You could detect the difference.Right?
 
 
Alan Liu
 
-----Original Message-----
From: Adeel Malik [mailto:AdeelM@quartics.com]
Sent: Tuesday, November 11, 2003 1:22 PM
To: Liu Hongming (Alan)
Cc: Ralf Baechle; linux-mips@linux-mips.org
Subject: RE: How to request an IRQ for NMI on MIPS Processor


Liu,
      In my board the interrupt was routed directly to an NMI line of MIPS
CPU rather than regular IRQs 0 - 5.   I went through the MIPS Architecture
Programming Guide Document, describing Interrupt and Exception Handling for
MIPS Processor. It is written there that although a Non-Maskable Interrupt
(NMI) includes "interrupt" in its name, it is more correctly described as an
NMI exception because it does not affect, nor is it controlled by the
processor interrupt system. 
 
Secondly, Linux Kernel especially the Embedded Linux Versions for various
Processors doesn't support the use of NMI as a regular IRQ.
 
The Interrupt Vector Address of all the Hardware Interrupt from IRQ0 - IRQ5
for MIPS Processor have the same vector location that is 0x80000180 or
0x80000380 which is a cached access, but the vector Location of NMI is
0xbfc00000 which is an un-cached access. So one needs to modify the
boot-code which is error-prone if it is possible at all.
 
Thatswhy we don't find much code related to NMIs in Linux.
 
ADEEL MALIK,

-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Liu Hongming (Alan)
Sent: Tuesday, November 11, 2003 9:39 AM
To: Ralf Baechle; Liu Hongming (Alan)
Cc: Adeel Malik; linux-mips@linux-mips.org
Subject: RE: How to request an IRQ for NMI on MIPS Processor




Hi Ralf, 

I have never used these kind of boards.It seems to me 
NMI is implemented by interrupt controller,to cpu,it is a 
normal interrupt source.If 'NMI' in Adeel's board is like 
what you repeated,request_irq could just use cpu's pin number 
as the 'irq' parameter. I think NMI has been used in many 
boards that only means 'non-maskable' to interrupt controller, 
not cpu. If it is this case, NMI interrupt is a normal case. 

Regards, 
Alan Liu 

-----Original Message----- 
From: Ralf Baechle [ mailto:ralf@linux-mips.org <mailto:ralf@linux-mips.org>
] 
Sent: Tuesday, November 11, 2003 11:40 AM 
To: Liu Hongming (Alan) 
Cc: Adeel Malik; linux-mips@linux-mips.org 
Subject: Re: How to request an IRQ for NMI on MIPS Processor 


Liu, 

On Tue, Nov 11, 2003 at 10:51:50AM +0800, Liu Hongming (Alan) wrote: 

> when using request_irq(...),the parameter irq is a value specified by you,

> of course,when porting linux for your board,you should have specified
value 
> for every IRQ. 0--5 only means CPU pin for interrupt,unless that only one 
> interrupt 
> may occur on this pin,you will use other value in request_irq,instead of 
> 0-5. 
>  
> all in all, when we touch request_irq,it is board specific.When your board

> has 
> been made out,all interrupts have specific route to cpu(unless you have
IRQ 
> router,since embedded,need this??).If you have more external interrupts
than 
> cpu pins,maybe you have cascaded many interrupt using one cpu pin.So, 
> the parameter irq in request_irq is determined by your board and your 
> porting 
> for interrupt handling.Just ask that guy that ported linux.He will tell 
> you.If you 
> are using linux ported by others,have a look at BSP codes. 

your answer is correct for normal interrupts, not the NMI.  The NMI goes 
through the firmware and none of the board support code so far bothered 
to make it available via request_irq as it has several severe limitations. 
To repeat one of my prior postings about the NMI: 

NMI on MIPS is pretty much miss-designed for use in application code; it's 
use should be limited to debugging and recovery from catastrophical 
failure.  The reason for this is the way this exception is handled: 
 

  - the BEV, TS, SR, NMI and ERL bits in c0_status are overwritten - that is

    their old state is lost. 
  - c0_errorepc is overwritten - again that means the old value is lost so 
    in case the NMI interrupts an exception handler that uses this register 
    such as the cache error handler you can not resume execution. 
  - the program counter is set to 0xbfc00000.  Most likely a slow flash 
    memory is mapped at this address but in any case it's an uncached 
    segment of the address space so execution will be even slower. 
  - execution will pass through the firmware.  That means you can only 
    use the NMI at all if firmware provides some kind of hook. 
 

It seems pretty clear to me that the MIPS designers never intended the 
NMI for anything else than catastrophic events. 

  Ralf 


------_=_NextPart_001_01C3A814.6A4B7C10
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">
<TITLE>RE: How to request an IRQ for NMI on MIPS Processor</TITLE>

<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY hb_focus_attach="true">
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff size=2>Hi 
Adeel,</FONT></SPAN></DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff size=2>I have 
understood your situation.</FONT></SPAN></DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff size=2>Under 
this situation,I think you need not use request_irq.</FONT></SPAN></DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff size=2>Just 
</FONT></SPAN><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff 
size=2>keep your 'interrupt' handler in BIOS or bootloader,</FONT></SPAN></DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff size=2>of 
course,it is different with Rest Exception,since </FONT></SPAN></DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff size=2>many 
registers' status&nbsp;are not the same as 
hardware-reseting.</FONT></SPAN></DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff size=2>You could 
detect the difference.</FONT></SPAN><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; 
color=#0000ff size=2>Right?</FONT></SPAN></DIV>
<DIV><SPAN class=495232905-11112003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff size=2>Alan 
Liu</FONT></SPAN></DIV>
<DIV><SPAN class=495232905-11112003><FONT face=&#23435;&#20307; color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Adeel Malik 
[mailto:AdeelM@quartics.com]<BR><B>Sent:</B> Tuesday, November 11, 2003 1:22 
PM<BR><B>To:</B> Liu Hongming (Alan)<BR><B>Cc:</B> Ralf Baechle; 
linux-mips@linux-mips.org<BR><B>Subject:</B> RE: How to request an IRQ for NMI 
on MIPS Processor<BR><BR></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=118040205-11112003>Liu,</SPAN></FONT></DIV>
<DIV><FONT size=2><FONT face=Arial color=#0000ff><SPAN 
class=118040205-11112003>&nbsp;&nbsp;&nbsp;<FONT face="Times New Roman" 
color=#000000>&nbsp;&nbsp; In my board the interrupt 
was&nbsp;routed&nbsp;directly&nbsp;to an NMI line of MIPS&nbsp;CPU rather than 
regular IRQs 0 - 5.&nbsp;&nbsp;&nbsp;I&nbsp;went through 
the</FONT></SPAN></FONT> MIPS Architecture Programming Guide Document<SPAN 
class=118040205-11112003>,&nbsp;describing Interrupt and Exception Handling for 
MIPS Processor. It is written there</SPAN>&nbsp;that&nbsp;<U><SPAN 
class=118040205-11112003>a</SPAN>lthough a Non-Maskable Interrupt (NMI) 
includes<SPAN class=118040205-11112003> </SPAN>"interrupt" in its name, it is 
more correctly described as an NMI exception because it does not affect, nor is 
it controlled<SPAN class=118040205-11112003> </SPAN>by the processor interrupt 
system.</U> </FONT></DIV>
<DIV><U><FONT size=2></FONT></U>&nbsp;</DIV>
<DIV><SPAN class=118040205-11112003><FONT size=2>Secondly, Linux Kernel 
especially the Embedded Linux Versions for various Processors doesn't support 
the use of NMI as a regular IRQ.</FONT></SPAN></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=118040205-11112003>The</SPAN>&nbsp;Interrupt 
Vector Address of all the Hardware Interrupt from IRQ0 - IRQ5<SPAN 
class=118040205-11112003> for MIPS Processor</SPAN>&nbsp;have the same vector 
location that is 0x80000180&nbsp;<SPAN class=118040205-11112003>or 0x80000380 
</SPAN>which is a cached access, but the vector Location of NMI is 0xbfc00000 
which is an un-cached access. So&nbsp;<SPAN class=118040205-11112003>one</SPAN> 
need<SPAN class=118040205-11112003>s</SPAN> to modify the boot-code 
which&nbsp;<SPAN class=118040205-11112003>is </SPAN>error-prone if it is 
possible at all.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Thatswhy we don't find much code related to NMIs in 
Linux.</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM>ADEEL MALIK,</EM></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> 
  linux-mips-bounce@linux-mips.org 
  [mailto:linux-mips-bounce@linux-mips.org]<B>On Behalf Of </B>Liu Hongming 
  (Alan)<BR><B>Sent:</B> Tuesday, November 11, 2003 9:39 AM<BR><B>To:</B> Ralf 
  Baechle; Liu Hongming (Alan)<BR><B>Cc:</B> Adeel Malik; 
  linux-mips@linux-mips.org<BR><B>Subject:</B> RE: How to request an IRQ for NMI 
  on MIPS Processor<BR><BR></FONT></DIV><BR>
  <P><FONT size=2>Hi Ralf,</FONT> </P>
  <P><FONT size=2>I have never used these kind of boards.It seems to me 
  </FONT><BR><FONT size=2>NMI is implemented by interrupt controller,to cpu,it 
  is a </FONT><BR><FONT size=2>normal interrupt source.If 'NMI' in Adeel's board 
  is like </FONT><BR><FONT size=2>what you repeated,request_irq could just use 
  cpu's pin number</FONT> <BR><FONT size=2>as the 'irq' parameter. I think NMI 
  has been used in many</FONT> <BR><FONT size=2>boards that only means 
  'non-maskable' to interrupt controller,</FONT> <BR><FONT size=2>not cpu. If it 
  is this case, NMI interrupt is a normal case.</FONT> </P>
  <P><FONT size=2>Regards,</FONT> <BR><FONT size=2>Alan Liu</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, November 11, 2003 11:40 AM</FONT> <BR><FONT 
  size=2>To: Liu Hongming (Alan)</FONT> <BR><FONT size=2>Cc: Adeel Malik; 
  linux-mips@linux-mips.org</FONT> <BR><FONT size=2>Subject: Re: How to request 
  an IRQ for NMI on MIPS Processor</FONT> </P><BR>
  <P><FONT size=2>Liu,</FONT> </P>
  <P><FONT size=2>On Tue, Nov 11, 2003 at 10:51:50AM +0800, Liu Hongming (Alan) 
  wrote:</FONT> </P>
  <P><FONT size=2>&gt; when using request_irq(...),the parameter irq is a value 
  specified by you,</FONT> <BR><FONT size=2>&gt; of course,when porting linux 
  for your board,you should have specified value</FONT> <BR><FONT size=2>&gt; 
  for every IRQ. 0--5 only means CPU pin for interrupt,unless that only 
  one</FONT> <BR><FONT size=2>&gt; interrupt</FONT> <BR><FONT size=2>&gt; may 
  occur on this pin,you will use other value in request_irq,instead of</FONT> 
  <BR><FONT size=2>&gt; 0-5.</FONT> <BR><FONT size=2>&gt;&nbsp; </FONT><BR><FONT 
  size=2>&gt; all in all, when we touch request_irq,it is board specific.When 
  your board</FONT> <BR><FONT size=2>&gt; has</FONT> <BR><FONT size=2>&gt; been 
  made out,all interrupts have specific route to cpu(unless you have IRQ</FONT> 
  <BR><FONT size=2>&gt; router,since embedded,need this??).If you have more 
  external interrupts than</FONT> <BR><FONT size=2>&gt; cpu pins,maybe you have 
  cascaded many interrupt using one cpu pin.So,</FONT> <BR><FONT size=2>&gt; the 
  parameter irq in request_irq is determined by your board and your</FONT> 
  <BR><FONT size=2>&gt; porting</FONT> <BR><FONT size=2>&gt; for interrupt 
  handling.Just ask that guy that ported linux.He will tell</FONT> <BR><FONT 
  size=2>&gt; you.If you</FONT> <BR><FONT size=2>&gt; are using linux ported by 
  others,have a look at BSP codes.</FONT> </P>
  <P><FONT size=2>your answer is correct for normal interrupts, not the 
  NMI.&nbsp; The NMI goes</FONT> <BR><FONT size=2>through the firmware and none 
  of the board support code so far bothered</FONT> <BR><FONT size=2>to make it 
  available via request_irq as it has several severe limitations.</FONT> 
  <BR><FONT size=2>To repeat one of my prior postings about the NMI:</FONT> </P>
  <P><FONT size=2>NMI on MIPS is pretty much miss-designed for use in 
  application code; it's</FONT> <BR><FONT size=2>use should be limited to 
  debugging and recovery from catastrophical</FONT> <BR><FONT 
  size=2>failure.&nbsp; The reason for this is the way this exception is 
  handled:</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT size=2>&nbsp; - the BEV, TS, SR, NMI and ERL bits in 
  c0_status are overwritten - that is</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; 
  their old state is lost.</FONT> <BR><FONT size=2>&nbsp; - c0_errorepc is 
  overwritten - again that means the old value is lost so</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp; in case the NMI interrupts an exception handler that 
  uses this register</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; such as the 
  cache error handler you can not resume execution.</FONT> <BR><FONT 
  size=2>&nbsp; - the program counter is set to 0xbfc00000.&nbsp; Most likely a 
  slow flash</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; memory is mapped at this 
  address but in any case it's an uncached</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp; segment of the address space so execution will be 
  even slower.</FONT> <BR><FONT size=2>&nbsp; - execution will pass through the 
  firmware.&nbsp; That means you can only</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp; use the NMI at all if firmware provides some kind of 
  hook.</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT size=2>It seems pretty clear to me that the MIPS designers 
  never intended the</FONT> <BR><FONT size=2>NMI for anything else than 
  catastrophic events.</FONT> </P>
  <P><FONT size=2>&nbsp; Ralf</FONT> </P></BLOCKQUOTE>
<P></P></BODY></HTML>

------_=_NextPart_001_01C3A814.6A4B7C10--

From ralf@linux-mips.org Tue Nov 11 05:45:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 05:45:43 +0000 (GMT)
Received: from p508B68E7.dip.t-dialin.net ([IPv6:::ffff:80.139.104.231]:7296
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225361AbTKKFpc>; Tue, 11 Nov 2003 05:45:32 +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 hAB5jVJH026396;
	Tue, 11 Nov 2003 06:45:31 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAB5jTA6026395;
	Tue, 11 Nov 2003 06:45:29 +0100
Date: Tue, 11 Nov 2003 06:45:29 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Liu Hongming (Alan)" <alanliu@trident.com.cn>
Cc: Adeel Malik <AdeelM@quartics.com>, linux-mips@linux-mips.org
Subject: Re: How to request an IRQ for NMI on MIPS Processor
Message-ID: <20031111054529.GA26238@linux-mips.org>
References: <15F9E1AE3207D6119CEA00D0B7DD5F6801C9949F@TMTMS>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15F9E1AE3207D6119CEA00D0B7DD5F6801C9949F@TMTMS>
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: 3600
X-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: 790
Lines: 21

On Tue, Nov 11, 2003 at 01:26:53PM +0800, Liu Hongming (Alan) wrote:

> I have understood your situation.
>  
> Under this situation,I think you need not use request_irq.

Request_irq is just the software interface; it could be used to drive
any kind of interrupt mechanism, even NMI or the two MIPS software
interrupts.  The actual problem here is the underlying hardware
mechanism and firmware.

> Just keep your 'interrupt' handler in BIOS or bootloader,
> of course,it is different with Rest Exception,since 
> many registers' status are not the same as hardware-reseting.
> You could detect the difference.Right?

Note the firmware is usually in some kind of PROM (sloooow) and also
running uncached.  One reasons of many why the MIPS NMI is only a good
idea for fatal events.

  Ralf

From js@convergence.de Tue Nov 11 15:45:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 15:45:45 +0000 (GMT)
Received: from mail.convergence.de ([IPv6:::ffff:212.84.236.4]:30700 "EHLO
	mail.convergence.de") by linux-mips.org with ESMTP
	id <S8225419AbTKKPpd>; Tue, 11 Nov 2003 15:45:33 +0000
Received: from [10.1.1.146] (helo=heck)
	by mail.convergence.de with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.14)
	id 1AJaeo-0005NY-7r
	for linux-mips@linux-mips.org; Tue, 11 Nov 2003 16:42:18 +0100
Received: from js by heck with local (Exim 3.35 #1 (Debian))
	id 1AJahm-0003Y0-00
	for <linux-mips@linux-mips.org>; Tue, 11 Nov 2003 16:45:22 +0100
Date: Tue, 11 Nov 2003 16:45:21 +0100
From: Johannes Stezenbach <js@convergence.de>
To: linux-mips@linux-mips.org
Subject: Re: random kernel panics with 2.4.22 running on VR4120A
Message-ID: <20031111154521.GA11931@convergence.de>
Mail-Followup-To: Johannes Stezenbach <js@convergence.de>,
	linux-mips@linux-mips.org
References: <20031024151325.GB22979@convergence.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031024151325.GB22979@convergence.de>
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: 3601
X-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: 616
Lines: 16

I wrote:
> 
> 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've updated to 2.4.22-2003-10-27, and the test suite ran
for about a week now: The problem seems to be solved.

Johannes

From ralf@linux-mips.org Wed Nov 12 12:45:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Nov 2003 12:45:43 +0000 (GMT)
Received: from p508B5A9E.dip.t-dialin.net ([IPv6:::ffff:80.139.90.158]:35049
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225376AbTKLMpc>; Wed, 12 Nov 2003 12:45:32 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hACCjKA0006516
	for <linux-mips@linux-mips.org>; Wed, 12 Nov 2003 13:45:20 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hACCjKZt006515
	for linux-mips@linux-mips.org; Wed, 12 Nov 2003 13:45:20 +0100
Date: Wed, 12 Nov 2003 13:45:19 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: SNI RM200
Message-ID: <20031112124519.GA6403@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3602
X-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: 341
Lines: 9

For those of you having a dusty RM200 in their cellar, I've resurrected
the RM200 port in 2.6.  Only the RM200 C aka RM200 PCI is supported;
older revisions of the machine are technically different and I can't test
on them.

I'm interested in feedback and reports and oh yes, I'd not mind a few
memory modules for the box either :-)

  Ralf

From e.bettler@ibcp.fr Wed Nov 12 13:02:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Nov 2003 13:03:11 +0000 (GMT)
Received: from audi.ibcp.fr ([IPv6:::ffff:193.51.160.127]:31448 "EHLO
	audi.ibcp.fr") by linux-mips.org with ESMTP id <S8225376AbTKLNCj> convert rfc822-to-8bit;
	Wed, 12 Nov 2003 13:02:39 +0000
Received: from gdeleage6.ibcp.fr (pc-bioinfo1.ibcp.fr [193.51.160.63])
	by audi.ibcp.fr (Postfix) with ESMTP id 94D3C7B391
	for <linux-mips@linux-mips.org>; Wed, 12 Nov 2003 14:02:38 +0100 (CET)
From: BETTLER Emmanuel <e.bettler@ibcp.fr>
Reply-To: e.bettler@ibcp.fr
Organization: IBCP - UCBL
To: linux-mips@linux-mips.org
Subject: O2 and Linux boot problem
Date: Wed, 12 Nov 2003 14:02:38 +0100
User-Agent: KMail/1.5
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Message-Id: <200311121402.38460.e.bettler@ibcp.fr>
Return-Path: <e.bettler@ibcp.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3603
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: e.bettler@ibcp.fr
Precedence: bulk
X-list: linux-mips
Content-Length: 2073
Lines: 59

Hi,
i'm trying to install linux on a O2 (IP32, 300 Mhz R5000 with FPU, 128 M 
Memory) but until now without a lot of success.
With NetBSD, from the Boot CDRom 
(ftp://ftp.ayamura.org/people/ayamura/NetBSD/sgimipscd-1.6.1.iso.gz), i've an 
error message:
Cannot load scsi(0)disk(4)rdisk(0)partition(8)/boot.
Range check failure: section start 0x88002000, size 0xc460
Section would overwrite an already loaded program
Unable to execute scsi(0)disk(4)rdisk(0)partition(8)/boot: not enough space
etc...
parameters in the PROM were:
setenv SystemPartition scsi(0)disk(4)rdisk(0)partition(8)
setenv OSLoadPartition scsi(0)disk(4)rdisk(0)partition(0)
setenv OSLoader boot
setenv OSLoadFilename netbsd
setenv OSLoadOptions auto
boot

hum.. may be the wrong kernel, so with a boot -f boot.ip3
kernel was loaded and a kernel panic occured:
...
Exception: <vector=Normal>
Status register: 0x34010082<CU1,CU0,FR,DE,IPL=8,KX,MODE=KERNEL>
cause register: 0x8000801c<BD,CE=0,IP8,EXC=DBE>
Exception PC: 0x800094c0, Exception RA: 0x80003a68
Instruction Bus error
Saved user regs in hex (&gpda 0x810617d8, &_regs 0x810619d8):
arg: 81070000 0 1000 0
tmp: 81070000 1000 8000e610 59b1f0 8806a000 0 8000e3e0 a13fa538
sve: 81070000 c10696f4 0 461052d2 0 c11eb9a8 0 bf8ee226
t8 81070000 t9 0 at 0 v0 c108dbfe v1 0 k1 4
gp 81070000 fp 0 sp 0 ra 0

PANIC: Unexpected exception

i've tried also gentoo and debian but problem with the kernel was the same 
(not enough space or kernel panic with an automatic reboot so no error 
message available !!)
i'm waiting for any suggestion, kernel to boot etc..
the only kernel that seems to be ok is here:
http://www.linux-mips.org/~glaurung/
(2.5.47) but i don't know how to connect this kernel with an install process 
like with netbsd or debian.

help is welcome,

Manu


-- 
Dr. Emmanuel BETTLER
http://pbil.ibcp.fr/~bettler
Tel +33 (0)4 72 72 26 47 Fax +33 (0)4 72 72 26 04

P鬺e BioInformatique Lyonnais Lyon Gerland (http://pbil.ibcp.fr)
Institut de Biologie et Chimie des Prot閕nes (http://www.ibcp.fr)
7 passage du Vercors 69367 LYON cedex 7
FRANCE 

From ralf@linux-mips.org Wed Nov 12 13:53:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Nov 2003 13:53:58 +0000 (GMT)
Received: from p508B5A9E.dip.t-dialin.net ([IPv6:::ffff:80.139.90.158]:25325
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225376AbTKLNxq>; Wed, 12 Nov 2003 13:53:46 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hACDrYA0008788;
	Wed, 12 Nov 2003 14:53:34 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hACDrYbf008787;
	Wed, 12 Nov 2003 14:53:34 +0100
Date: Wed, 12 Nov 2003 14:53:33 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: BETTLER Emmanuel <e.bettler@ibcp.fr>
Cc: linux-mips@linux-mips.org
Subject: Re: O2 and Linux boot problem
Message-ID: <20031112135333.GA8146@linux-mips.org>
References: <200311121402.38460.e.bettler@ibcp.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200311121402.38460.e.bettler@ibcp.fr>
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: 3604
X-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: 622
Lines: 15

On Wed, Nov 12, 2003 at 02:02:38PM +0100, BETTLER Emmanuel wrote:

> i've tried also gentoo and debian but problem with the kernel was the same 
> (not enough space or kernel panic with an automatic reboot so no error 
> message available !!)
> i'm waiting for any suggestion, kernel to boot etc..
> the only kernel that seems to be ok is here:
> http://www.linux-mips.org/~glaurung/
> (2.5.47) but i don't know how to connect this kernel with an install process 
> like with netbsd or debian.

Linux for O2 is still in it's very early stages, don't expect much
success with it for the moment.  Hackers welcome :)

  Ralf

From ashish_ibm@rediffmail.com Wed Nov 12 15:02:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Nov 2003 15:02:53 +0000 (GMT)
Received: from webmail27.rediffmail.com ([IPv6:::ffff:203.199.83.37]:18131
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225376AbTKLPCV>; Wed, 12 Nov 2003 15:02:21 +0000
Received: (qmail 13189 invoked by uid 510); 12 Nov 2003 14:59:37 -0000
Date: 12 Nov 2003 14:59:37 -0000
Message-ID: <20031112145937.13188.qmail@webmail27.rediffmail.com>
Received: from unknown (210.210.7.195) by rediffmail.com via HTTP; 12 nov 2003 14:59:37 -0000
MIME-Version: 1.0
From: "ashish  anand" <ashish_ibm@rediffmail.com>
Reply-To: "ashish  anand" <ashish_ibm@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: is cli/sti pair interruptible..?
Content-type: multipart/alternative;
	boundary="Next_1068649177---0-203.199.83.37-13183"
Return-Path: <ashish_ibm@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3605
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish_ibm@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 904
Lines: 25

 This is a multipart mime message


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

<P>=0Awhat prevents cli/sti pair not to be interrupted during their operati=
on..?<BR>=0A<BR>=0ABest Regards,<BR>=0AAshish=0A</P>=0A<br><br>=0A<A target=
=3D"_blank" HREF=3D"http://clients.rediff.com/signature/track_sig.asp"><IMG=
 SRC=3D"http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.=
com/inbox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0 HEIGHT=3D74 WIDTH=3D=
496></a>=0A
--Next_1068649177---0-203.199.83.37-13183
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

what prevents cli/sti pair not to be interrupted during their operation..?=
=0A=0ABest Regards,=0AAshish
--Next_1068649177---0-203.199.83.37-13183--


From ralf@linux-mips.org Wed Nov 12 15:50:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Nov 2003 15:50:51 +0000 (GMT)
Received: from p508B5A9E.dip.t-dialin.net ([IPv6:::ffff:80.139.90.158]:58245
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225514AbTKLPuj>; Wed, 12 Nov 2003 15:50:39 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hACFobA0011500;
	Wed, 12 Nov 2003 16:50:37 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hACFoYc3011499;
	Wed, 12 Nov 2003 16:50:34 +0100
Date: Wed, 12 Nov 2003 16:50:34 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: ashish anand <ashish_ibm@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: is cli/sti pair interruptible..?
Message-ID: <20031112155034.GA11440@linux-mips.org>
References: <20031112145937.13188.qmail@webmail27.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031112145937.13188.qmail@webmail27.rediffmail.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: 3606
X-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: 159
Lines: 7

On Wed, Nov 12, 2003 at 02:59:37PM -0000, ashish  anand wrote:

> what prevents cli/sti pair not to be interrupted during their operation..?

Nothing.

  Ralf

From dkesselr@mmc.atmel.com Wed Nov 12 16:36:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Nov 2003 16:36:37 +0000 (GMT)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:38587
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225446AbTKLQgZ>; Wed, 12 Nov 2003 16:36:25 +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 LAA25938
	for <linux-mips@linux-mips.org>; Wed, 12 Nov 2003 11:36:15 -0500 (EST)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id LAA07171
	for <linux-mips@linux-mips.org>; Wed, 12 Nov 2003 11:36:14 -0500 (EST)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Wed, 12 Nov 2003 11:36:14 -0500 (EST)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: snapgear and uClinux
Message-ID: <Pine.GSO.4.44.0311121132480.5676-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: 3607
X-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: 285
Lines: 10

Has anyone out there used uClinux or snapgear's distro with a mips
processor? Did you have any unexpected suprises? Do these tools help get
the footprint smaller or is it easier to do something with the linux-mips
tree?

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


From wd@denx.de Wed Nov 12 16:49:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Nov 2003 16:49:56 +0000 (GMT)
Received: from mailout05.sul.t-online.com ([IPv6:::ffff:194.25.134.82]:24720
	"EHLO mailout05.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225446AbTKLQtY>; Wed, 12 Nov 2003 16:49:24 +0000
Received: from fwd03.aul.t-online.de 
	by mailout05.sul.t-online.com with smtp 
	id 1AJyBG-0004Yh-01; Wed, 12 Nov 2003 17:49:22 +0100
Received: from denx.de (rA1f6TZrweG7Og87rFMH3DH4zFkNPq+OLjzNCimfi0gmbACxB96Xr5@[217.235.231.185]) by fmrl03.sul.t-online.com
	with esmtp id 1AJyAD-16xyVc0; Wed, 12 Nov 2003 17:48:17 +0100
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 2D5F842ACF; Wed, 12 Nov 2003 17:48:16 +0100 (MET)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 355ECC5F59; Wed, 12 Nov 2003 17:48:10 +0100 (MET)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 303F3C5F58; Wed, 12 Nov 2003 17:48:10 +0100 (MET)
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: snapgear and uClinux 
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, 12 Nov 2003 11:36:14 EST."
             <Pine.GSO.4.44.0311121132480.5676-100000@ares.mmc.atmel.com> 
Date: Wed, 12 Nov 2003 17:48:05 +0100
Message-Id: <20031112164810.355ECC5F59@atlas.denx.de>
X-Seen: false
X-ID: rA1f6TZrweG7Og87rFMH3DH4zFkNPq+OLjzNCimfi0gmbACxB96Xr5@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: 3608
X-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: 887
Lines: 24

In message <Pine.GSO.4.44.0311121132480.5676-100000@ares.mmc.atmel.com> you wrote:
> Has anyone out there used uClinux or snapgear's distro with a mips
> processor? Did you have any unexpected suprises? Do these tools help get
> the footprint smaller or is it easier to do something with the linux-mips
> tree?

I have seen uCLinux running on the Purple board (MIPS 5Kc CPU core).

If you have a MMU on your chip you should always go for the "real" Linux.

Reducing the memory footprint is not so much a kernel issue  but  one
of  the application level - using standard tools linked against glibc
vs. busybox with uClibc for example.


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
It is easier to change the specification to fit the program than vice
versa.

From jvmiller@earthlink.net Wed Nov 12 18:43:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Nov 2003 18:44:02 +0000 (GMT)
Received: from stork.mail.pas.earthlink.net ([IPv6:::ffff:207.217.120.188]:18591
	"EHLO stork.mail.pas.earthlink.net") by linux-mips.org with ESMTP
	id <S8225455AbTKLSna>; Wed, 12 Nov 2003 18:43:30 +0000
Received: from [207.215.131.7] (helo=jaco)
	by stork.mail.pas.earthlink.net with asmtp (Exim 3.33 #1)
	id 1AJzxf-0000Uz-00; Wed, 12 Nov 2003 10:43:28 -0800
Subject: Patch for ALI15x3 - Linux-MIPS kernel 2.4.22-rc3
From: Jack Miller <jvmiller@earthlink.net>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Content-Type: multipart/mixed; boundary="=-XMwbFPDN0Ikw4P9BYAnN"
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-9.7x.1) 
Date: 12 Nov 2003 10:43:03 -0800
Message-Id: <1068662598.2185.2.camel@jaco>
Mime-Version: 1.0
X-ELNK-Trace: 00c7b4e377e67b8a1aa676d7e74259b7b3291a7d08dfec79a2dd1171d5a8c90bc7f803517eebc3bf350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Return-Path: <jvmiller@earthlink.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: 3609
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jvmiller@earthlink.net
Precedence: bulk
X-list: linux-mips
Content-Length: 878
Lines: 34


--=-XMwbFPDN0Ikw4P9BYAnN
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

  Ralf,
    Please apply this patch for the file drivers/ide/pci/alim15x3.c.  It
fixes the LBA addressing mode for chip revisions <= 0xC4.  Thank-You.

  Regards,
    Jack




--=-XMwbFPDN0Ikw4P9BYAnN
Content-Disposition: attachment; filename=patch
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; name=patch; charset=ISO-8859-15

--- alim15x3.c.orig	2003-11-12 10:32:04.000000000 -0800
+++ alim15x3.c	2003-11-12 08:18:08.000000000 -0800
@@ -760,7 +760,7 @@
 	hwif->speedproc =3D &ali15x3_tune_chipset;
=20
 	/* Don't use LBA48 on ALi devices before rev 0xC5 */
-	hwif->addressing =3D (m5229_revision <=3D 0xC4) ? 1 : 0;
+	hwif->addressing =3D (m5229_revision <=3D 0xC4) ? 0 : 1;
=20
 	if (!hwif->dma_base) {
 		hwif->drives[0].autotune =3D 1;

--=-XMwbFPDN0Ikw4P9BYAnN--


From flo@paradigm.rfc822.org Wed Nov 12 19:51:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Nov 2003 19:51:18 +0000 (GMT)
Received: from noose.gt.owl.de ([IPv6:::ffff:62.52.19.4]:8715 "EHLO
	noose.gt.owl.de") by linux-mips.org with ESMTP id <S8225458AbTKLTvH>;
	Wed, 12 Nov 2003 19:51:07 +0000
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 9E5F425E42; Wed, 12 Nov 2003 20:51:05 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id B994F13806A; Wed, 12 Nov 2003 19:29:56 +0100 (CET)
Date: Wed, 12 Nov 2003 19:29:56 +0100
From: Florian Lohoff <flo@rfc822.org>
To: linux-mips@linux-mips.org
Subject: lasat mqpro reboots on "heavy" disk i/o
Message-ID: <20031112182956.GA6456@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU"
Content-Disposition: inline
Organization: rfc822 - pure communication
User-Agent: Mutt/1.5.4i
Return-Path: <flo@paradigm.rfc822.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3610
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1056
Lines: 38


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


Hi,
i just updated one of the Lasat mqpro to the latest CVS version as it
was reported that the current kernel (a bit older) reboots on diskio.

I am now running todays CVS version (2.4.22) which still reboots under
heavy disk i/o. I would guess that this is a hardware problem=20
as the machine moved to a different location before the problem seemed
to have appeared first.

Does anyone have a clue ?

Flo
PS: heavy disk i/o caused by a scp of some kernel modules into the
machine
--=20
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

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

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

iD8DBQE/snwkUaz2rXW+gJcRArQlAKChe5pVR0JyIu5w4TNyVhjdp6QslQCglSGi
GDvn3gbkyNYnSt6oa0+GpHo=
=1DB1
-----END PGP SIGNATURE-----

--EeQfGwPcQSOJBaQU--

From ralf@linux-mips.org Wed Nov 12 20:37:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Nov 2003 20:38:19 +0000 (GMT)
Received: from p508B5A9E.dip.t-dialin.net ([IPv6:::ffff:80.139.90.158]:15510
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225467AbTKLUh5>; Wed, 12 Nov 2003 20:37:57 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hACKbrA0018468;
	Wed, 12 Nov 2003 21:37:53 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hACKboxF018467;
	Wed, 12 Nov 2003 21:37:50 +0100
Date: Wed, 12 Nov 2003 21:37:50 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Wolfgang Denk <wd@denx.de>
Cc: David Kesselring <dkesselr@mmc.atmel.com>,
	linux-mips@linux-mips.org
Subject: Re: snapgear and uClinux
Message-ID: <20031112203750.GD18124@linux-mips.org>
References: <Pine.GSO.4.44.0311121132480.5676-100000@ares.mmc.atmel.com> <20031112164810.355ECC5F59@atlas.denx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031112164810.355ECC5F59@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: 3611
X-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: 745
Lines: 18

On Wed, Nov 12, 2003 at 05:48:05PM +0100, Wolfgang Denk wrote:

> > processor? Did you have any unexpected suprises? Do these tools help get
> > the footprint smaller or is it easier to do something with the linux-mips
> > tree?

> If you have a MMU on your chip you should always go for the "real" Linux.
> 
> Reducing the memory footprint is not so much a kernel issue  but  one
> of  the application level - using standard tools linked against glibc
> vs. busybox with uClibc for example.

Certain mechanism such as copy on write are only possible with an MMU and
can achieve dramatic memory savings.  The common believe that memory
protection results in significant overhead isn't true anymore, so
Wolfgang ist certainly right here.

  Ralf

From alan@lxorguk.ukuu.org.uk Thu Nov 13 01:00:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Nov 2003 01:00:35 +0000 (GMT)
Received: from crosslink-village-512-1.bc.nu ([IPv6:::ffff:81.2.110.254]:33928
	"EHLO dhcp23.swansea.linux.org.uk") by linux-mips.org with ESMTP
	id <S8225483AbTKMBAY>; Thu, 13 Nov 2003 01:00:24 +0000
Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1])
	by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10) with ESMTP id hAD0uZPr013435;
	Thu, 13 Nov 2003 00:56:35 GMT
Received: (from alan@localhost)
	by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10/Submit) id hAD0uYnG013433;
	Thu, 13 Nov 2003 00:56:34 GMT
X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Patch for ALI15x3 - Linux-MIPS kernel 2.4.22-rc3
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jack Miller <jvmiller@earthlink.net>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux-MIPS <linux-mips@linux-mips.org>
In-Reply-To: <1068662598.2185.2.camel@jaco>
References: <1068662598.2185.2.camel@jaco>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1068684992.13276.17.camel@dhcp23.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Thu, 13 Nov 2003 00:56:33 +0000
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3612
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips
Content-Length: 304
Lines: 12

On Mer, 2003-11-12 at 18:43, Jack Miller wrote:
>   Ralf,
>     Please apply this patch for the file drivers/ide/pci/alim15x3.c.  It
> fixes the LBA addressing mode for chip revisions <= 0xC4.  Thank-You.

It seems to break it not fix it.

addressing = 1 means no LBA48
addressing = 0 means LBA48

Alan


From jack.miller@pioneer-pdt.com Thu Nov 13 01:14:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Nov 2003 01:14:16 +0000 (GMT)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:25801
	"EHLO mail.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225471AbTKMBOE>; Thu, 13 Nov 2003 01:14:04 +0000
Received: from 127.0.0.1 (localhost.pioneer-pdt.com [127.0.0.1])
	by dummy.domain.name (Postfix) with SMTP
	id 2DE189D81E; Wed, 12 Nov 2003 17:13:54 -0800 (PST)
Received: from LEDA (leda.V4000.pioneer-pdt.com [172.30.2.15])
	by mail.pioneer-pdt.com (Postfix) with SMTP
	id 261FB9D816; Wed, 12 Nov 2003 17:13:53 -0800 (PST)
From: "Jack Miller" <jack.miller@pioneer-pdt.com>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>,
	"Jack Miller" <jvmiller@earthlink.net>
Cc: "Ralf Baechle" <ralf@linux-mips.org>,
	"Linux-MIPS" <linux-mips@linux-mips.org>
Subject: RE: Patch for ALI15x3 - Linux-MIPS kernel 2.4.22-rc3
Date: Wed, 12 Nov 2003 17:13:53 -0800
Message-ID: <JCELLCFDJLFKPOBFKGFNEENFCHAA.jack.miller@pioneer-pdt.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <1068684992.13276.17.camel@dhcp23.swansea.linux.org.uk>
Return-Path: <jack.miller@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: 3613
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jack.miller@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips
Content-Length: 869
Lines: 36

  Alan,
    I am not so sure of that.  If you look at ide-disk.c:__ide_do_rw_disk(),
there is a local variable assignment statement:

  u8 lba48 = (drive->addressing = 1) ? 1 : 0;

  So it would seem that the problem is elswhere ?

  -Jack


> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Alan Cox
> Sent: Wednesday, November 12, 2003 4:57 PM
> To: Jack Miller
> Cc: Ralf Baechle; Linux-MIPS
> Subject: Re: Patch for ALI15x3 - Linux-MIPS kernel 2.4.22-rc3
>
>
> On Mer, 2003-11-12 at 18:43, Jack Miller wrote:
> >   Ralf,
> >     Please apply this patch for the file drivers/ide/pci/alim15x3.c.  It
> > fixes the LBA addressing mode for chip revisions <= 0xC4.  Thank-You.
>
> It seems to break it not fix it.
>
> addressing = 1 means no LBA48
> addressing = 0 means LBA48
>
> Alan
>
>
>



From jbglaw@dvmwest.gt.owl.de Thu Nov 13 08:59:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Nov 2003 08:59:25 +0000 (GMT)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:50354 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225373AbTKMI7N>; Thu, 13 Nov 2003 08:59:13 +0000
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 6579E4B456; Thu, 13 Nov 2003 09:59:09 +0100 (CET)
Date: Thu, 13 Nov 2003 09:59:08 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: Patch for ALI15x3 - Linux-MIPS kernel 2.4.22-rc3
Message-ID: <20031113085908.GV17497@lug-owl.de>
Mail-Followup-To: Linux-MIPS <linux-mips@linux-mips.org>
References: <1068684992.13276.17.camel@dhcp23.swansea.linux.org.uk> <JCELLCFDJLFKPOBFKGFNEENFCHAA.jack.miller@pioneer-pdt.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="32KBALpRDK42x9o9"
Content-Disposition: inline
In-Reply-To: <JCELLCFDJLFKPOBFKGFNEENFCHAA.jack.miller@pioneer-pdt.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: 3614
X-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: 1253
Lines: 42


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

On Wed, 2003-11-12 17:13:53 -0800, Jack Miller <jack.miller@pioneer-pdt.com>
wrote in message <JCELLCFDJLFKPOBFKGFNEENFCHAA.jack.miller@pioneer-pdt.com>:
>   Alan,
>     I am not so sure of that.  If you look at ide-disk.c:__ide_do_rw_disk=
(),
> there is a local variable assignment statement:
>=20
>   u8 lba48 =3D (drive->addressing =3D 1) ? 1 : 0;
                                 ^^^

Explode. Now, lba48 would _always_ be 1.

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));

--32KBALpRDK42x9o9
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/s0fcHb1edYOZ4bsRAgVcAJ9NKlBambfYInuCATuRKSVs6/J5oQCcD1ll
vSOzicsoASnk2gLBmn+w6TM=
=dEC5
-----END PGP SIGNATURE-----

--32KBALpRDK42x9o9--

From ralf@linux-mips.org Thu Nov 13 17:33:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Nov 2003 17:33:38 +0000 (GMT)
Received: from p508B57E5.dip.t-dialin.net ([IPv6:::ffff:80.139.87.229]:49883
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225412AbTKMRd1>; Thu, 13 Nov 2003 17:33:27 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hADH3HA0032719
	for <linux-mips@linux-mips.org>; Thu, 13 Nov 2003 18:03:18 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hADH3G22032718
	for linux-mips@linux-mips.org; Thu, 13 Nov 2003 18:03:16 +0100
Date: Thu, 13 Nov 2003 18:03:15 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Cobalt kernel for 2.6
Message-ID: <20031113170315.GA32644@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3615
X-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: 433
Lines: 10

the Cobalt kernel, in particular the 2.6 port needs somebody to look after.
In 2.4 problems with the ethernet driver were reported and in 2.6 the
kernel builds but would need somebody with actual hardware to debug it.
An additional problem with 2.6 on Cobalt hardware are the size limits
for the booted kernel which would need to be worked around; various
solutions such as a two stage bootloader are thinkable.

Volunteers?

  Ralf

From jack.miller@pioneer-pdt.com Thu Nov 13 17:49:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Nov 2003 17:50:06 +0000 (GMT)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:18906
	"EHLO mail.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225412AbTKMRty> convert rfc822-to-8bit; Thu, 13 Nov 2003 17:49:54 +0000
Received: from 127.0.0.1 (localhost.pioneer-pdt.com [127.0.0.1])
	by dummy.domain.name (Postfix) with SMTP
	id 4B03C9D813; Thu, 13 Nov 2003 09:49:40 -0800 (PST)
Received: from LEDA (leda.V4000.pioneer-pdt.com [172.30.2.15])
	by mail.pioneer-pdt.com (Postfix) with SMTP
	id 733589D816; Thu, 13 Nov 2003 09:49:34 -0800 (PST)
From: "Jack Miller" <jack.miller@pioneer-pdt.com>
To: "Jan-Benedict Glaw" <jbglaw@lug-owl.de>,
	"Linux-MIPS" <linux-mips@linux-mips.org>
Subject: RE: Patch for ALI15x3 - Linux-MIPS kernel 2.4.22-rc3
Date: Thu, 13 Nov 2003 09:49:34 -0800
Message-ID: <JCELLCFDJLFKPOBFKGFNKENHCHAA.jack.miller@pioneer-pdt.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <20031113085908.GV17497@lug-owl.de>
Content-Transfer-Encoding: 8BIT
Return-Path: <jack.miller@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: 3616
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jack.miller@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1162
Lines: 38

  Sorry for the typo in the transcription, the source code is correct
regarding the test and assignment.

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jan-Benedict Glaw
> Sent: Thursday, November 13, 2003 12:59 AM
> To: Linux-MIPS
> Subject: Re: Patch for ALI15x3 - Linux-MIPS kernel 2.4.22-rc3
>
>
> On Wed, 2003-11-12 17:13:53 -0800, Jack Miller
> <jack.miller@pioneer-pdt.com>
> wrote in message
> <JCELLCFDJLFKPOBFKGFNEENFCHAA.jack.miller@pioneer-pdt.com>:
> >   Alan,
> >     I am not so sure of that.  If you look at
> ide-disk.c:__ide_do_rw_disk(),
> > there is a local variable assignment statement:
> >
> >   u8 lba48 = (drive->addressing = 1) ? 1 : 0;
>                                  ^^^
>
> Explode. Now, lba48 would _always_ be 1.
>
> 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黵ger" | im Internet! |
>  im Irak!
>    ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW |
> DRM | TCPA));
>



From alan@lxorguk.ukuu.org.uk Thu Nov 13 22:41:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Nov 2003 22:41:30 +0000 (GMT)
Received: from crosslink-village-512-1.bc.nu ([IPv6:::ffff:81.2.110.254]:3978
	"EHLO dhcp23.swansea.linux.org.uk") by linux-mips.org with ESMTP
	id <S8225443AbTKMWlP>; Thu, 13 Nov 2003 22:41:15 +0000
Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1])
	by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10) with ESMTP id hADMbSPr016340;
	Thu, 13 Nov 2003 22:37:28 GMT
Received: (from alan@localhost)
	by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10/Submit) id hADMbQGa016338;
	Thu, 13 Nov 2003 22:37:26 GMT
X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: RE: Patch for ALI15x3 - Linux-MIPS kernel 2.4.22-rc3
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jack Miller <jack.miller@pioneer-pdt.com>
Cc: Jack Miller <jvmiller@earthlink.net>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linux-MIPS <linux-mips@linux-mips.org>
In-Reply-To: <JCELLCFDJLFKPOBFKGFNEENFCHAA.jack.miller@pioneer-pdt.com>
References: <JCELLCFDJLFKPOBFKGFNEENFCHAA.jack.miller@pioneer-pdt.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1068762590.16231.4.camel@dhcp23.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Thu, 13 Nov 2003 22:37:25 +0000
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3617
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips
Content-Length: 496
Lines: 14

On Iau, 2003-11-13 at 01:13, Jack Miller wrote:
>   Alan,
>     I am not so sure of that.  If you look at ide-disk.c:__ide_do_rw_disk(),
> there is a local variable assignment statement:
> 
>   u8 lba48 = (drive->addressing = 1) ? 1 : 0;
> 
>   So it would seem that the problem is elswhere ?

drive and hwif->addressing are different. (Not my idea don't blame me!)

In the last code I did before going on sabattical its all become a bit
irrelevant as I implemented the notion of lba48 pio-only


From ashish_ibm@rediffmail.com Fri Nov 14 08:49:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Nov 2003 08:49:51 +0000 (GMT)
Received: from webmail29.rediffmail.com ([IPv6:::ffff:203.199.83.39]:55955
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225347AbTKNItT>; Fri, 14 Nov 2003 08:49:19 +0000
Received: (qmail 23063 invoked by uid 510); 14 Nov 2003 08:46:06 -0000
Date: 14 Nov 2003 08:46:06 -0000
Message-ID: <20031114084606.23062.qmail@webmail29.rediffmail.com>
Received: from unknown (210.210.7.195) by rediffmail.com via HTTP; 14 nov 2003 08:46:06 -0000
MIME-Version: 1.0
From: "ashish  anand" <ashish_ibm@rediffmail.com>
Reply-To: "ashish  anand" <ashish_ibm@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: does CP0_CAUSE gets set by spurious interrupts..?.
Content-type: multipart/alternative;
	boundary="Next_1068799566---0-203.199.83.39-23059"
Return-Path: <ashish_ibm@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3618
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish_ibm@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1014
Lines: 26

 This is a multipart mime message


--Next_1068799566---0-203.199.83.39-23059
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0AHello,<BR>=0A<BR>=0Awould a spurious interrupt ( edge vs. level trigg=
er mismatching) cause CP0_CAUSE to show any pending interupts.?<BR>=0A<BR>=
=0ABest Regards,<BR>=0AAshish=0A</P>=0A<br><br>=0A<A target=3D"_blank" HREF=
=3D"http://clients.rediff.com/signature/track_sig.asp"><IMG SRC=3D"http://a=
ds.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bo=
ttom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0 HEIGHT=3D74 WIDTH=3D496></a>=0A
--Next_1068799566---0-203.199.83.39-23059
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,=0A=0Awould a spurious interrupt ( edge vs. level trigger mismatching=
) cause CP0_CAUSE to show any pending interupts.?=0A=0ABest Regards,=0AAshi=
sh
--Next_1068799566---0-203.199.83.39-23059--


From dom@mips.com Fri Nov 14 11:22:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Nov 2003 11:22:37 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:64780 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225358AbTKNLWD>;
	Fri, 14 Nov 2003 11:22:03 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1AKbz8-00047Q-00; Fri, 14 Nov 2003 11:19:30 +0000
Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir.mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1AKc1K-0003bj-00; Fri, 14 Nov 2003 11:21:46 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16308.47817.319852.989830@gladsmuir.mips.com>
Date: Fri, 14 Nov 2003 11:21:45 +0000
To: "ashish  anand" <ashish_ibm@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: does CP0_CAUSE gets set by spurious interrupts..?.
In-Reply-To: <20031114084606.23062.qmail@webmail29.rediffmail.com>
References: <20031114084606.23062.qmail@webmail29.rediffmail.com>
X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.858, required 4, AWL,
	BAYES_00)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3619
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 515
Lines: 19


Ashish,

> would a spurious interrupt ( edge vs. level trigger mismatching)
> cause CP0_CAUSE to show any pending interupts.?

CP0_CAUSE reflects the real-time inputs to the CPU, not the state of
those inputs at the time the interrupt was detected, nor is it
sensitive to the "mask" bits in the status register.

So it's perfectly possible to find no active bits in CP0_CAUSE which
account for your interrupt.  But it does all depend how your interrupt
controller works...

--
Dominic Sweetman
MIPS Technologies



From TERESAT@TTI-DM.COM Fri Nov 14 17:42:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Nov 2003 17:43:00 +0000 (GMT)
Received: from [IPv6:::ffff:66.121.16.190] ([IPv6:::ffff:66.121.16.190]:33509
	"EHLO trid-mail1.tridentmicro.com") by linux-mips.org with ESMTP
	id <S8225358AbTKNRms> convert rfc822-to-8bit; Fri, 14 Nov 2003 17:42:48 +0000
Subject: question regarding put data in the specified section
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 8BIT
Date: Fri, 14 Nov 2003 09:42:34 -0800
Message-ID: <92F2591F460F684C9C309EB0D33256FA01B750B8@trid-mail1.tridentmicro.com>
content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-TNEF-Correlator: 
Thread-Topic: question regarding put data in the specified section
Thread-Index: AcOq1q+oMjzWNX5USweAKSWtAcTo6A==
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: 3620
X-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: 454
Lines: 10

Hi there,

Does anyone know how to put my userland program's data in a specified section?

I know there is an attribute "section" to put my data inside a specified section, for example, int data __attribute__ ((section("INITDAT"));
But how do I initialize/setup the INITDAT section? We use the commercial toolchain, and we don't have the source code for it, is there still a way to specify the postion of the INITDAT section?

Thanks in advance!

Teresa

From ralf@linux-mips.org Sat Nov 15 12:53:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 Nov 2003 12:53:47 +0000 (GMT)
Received: from p508B61C4.dip.t-dialin.net ([IPv6:::ffff:80.139.97.196]:31378
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225367AbTKOMxf>; Sat, 15 Nov 2003 12:53:35 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAFCrUA0001444;
	Sat, 15 Nov 2003 13:53:30 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAFCrToG001443;
	Sat, 15 Nov 2003 13:53:29 +0100
Date: Sat, 15 Nov 2003 13:53:29 +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 put data in the specified section
Message-ID: <20031115125329.GA324@linux-mips.org>
References: <92F2591F460F684C9C309EB0D33256FA01B750B8@trid-mail1.tridentmicro.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <92F2591F460F684C9C309EB0D33256FA01B750B8@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: 3623
X-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: 981
Lines: 20

On Fri, Nov 14, 2003 at 09:42:34AM -0800, Teresa Tao wrote:

> Does anyone know how to put my userland program's data in a specified section?
> 
> I know there is an attribute "section" to put my data inside a specified section, for example, int data __attribute__ ((section("INITDAT"));
> But how do I initialize/setup the INITDAT section? We use the
> commercial toolchain, and we don't have the source code for it, is
> there still a way to specify the postion of the INITDAT section?

If your commercial toolchain understands the __attribute__ syntax then
I suspect it's based on gcc which would mean you have a right to the
sourcecode.

No initialization needed;  Ld will use the flags of the first instance
of an input section for the output section which usually is right.  In
the rare case this isn't suitable you can use a .section pseudo-op
in inline assembler or assembler to setup the section with the right
flags.  Just make sure this section is linked first.

  Ralf

From durai@isofttech.com Sun Nov 16 09:00:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 Nov 2003 09:00:48 +0000 (GMT)
Received: from [IPv6:::ffff:203.199.202.17] ([IPv6:::ffff:203.199.202.17]:10756
	"EHLO pub.isofttechindia.com") by linux-mips.org with ESMTP
	id <S8225310AbTKPJAh>; Sun, 16 Nov 2003 09:00:37 +0000
Received: from DURAI ([192.168.0.180])
	by pub.isofttechindia.com (8.11.0/8.11.0) with SMTP id hAG8xbn26374
	for <linux-mips@linux-mips.org>; Sun, 16 Nov 2003 14:29:37 +0530
Message-ID: <007801c3ac20$070adff0$0205a8c0@DURAI>
From: "durai" <durai@isofttech.com>
To: <linux-mips@linux-mips.org>
References: <92F2591F460F684C9C309EB0D33256FA01B750B8@trid-mail1.tridentmicro.com> <20031115125329.GA324@linux-mips.org>
Subject: file handling in kernel mode
Date: Sun, 16 Nov 2003 14:30:05 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0075_01C3AC4E.20B73510"
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: 3624
X-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: 6628
Lines: 189

This is a multi-part message in MIME format.

------=_NextPart_000_0075_01C3AC4E.20B73510
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
I need to read a file from a device driver and i wrote a sample driver =
like this

This kernel mode code which try to read the file until end of file is =
reached. This code had been is working without any problems in RedHat =
linux and uClinux.
But the same code causes a General Protection Fault in my mips linux. I =
tested the same code in mips running on uClinux which runs well.
what is wrong with mips linux?

#define __KERNEL_SYSCALLS__

#include <linux/version.h>
#ifdef MODULE
#ifdef MODVERSIONS
#include <linux/modversions.h>
#endif
#include <linux/module.h>
#else
#define MOD_INC_USE_COUNT
#define MOD_DEC_USE_COUNT
#endif

#include <linux/types.h>
#include <linux/unistd.h>
#include <linux/delay.h>
#include <asm/uaccess.h>
#include <asm/io.h>
int test_open(void );
int init_module(void)
{
        printk("\n init_module ");
        test_open();
        return 0;
}
void cleanup_module(void)
{
        printk("\n cleanup module");
}

int test_open(void )
{
    int ifp,bcount;
    mm_segment_t fs;
    char buffer[0x1000];

    // for file opening temporarily tell the kernel I am not a user for
    // memory management segment access
    fs =3D get_fs();
    set_fs(KERNEL_DS);
    // open the file with the firmware for uploading
    if (ifp =3D open( "/etc/hotplug/isl3890.arm", O_RDONLY, 0 ), ifp < =
0)
    {
        // error opening the file
        printk( "ERROR: File opening did not success \n");
        set_fs(fs);
        return -1;
    }
    // enter a loop which reads data blocks from the file and writes =
them
    // to the Direct Memory Windows
    do
    {
            bcount =3D read(ifp, &buffer, sizeof(buffer));
            printk("\n bcount %x ",bcount);
    }
    while (bcount !=3D 0);
    close(ifp);
    // switch back the segment setting
    set_fs(fs);

    return 0;
}



thanks & regards
durai
------=_NextPart_000_0075_01C3AC4E.20B73510
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>
<DIV>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I need to read a file from a device =
driver and i=20
wrote a sample driver like this</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>This kernel mode code which try to read =
the file=20
until end of file is reached. This code had been is working without any =
problems=20
in RedHat linux and uClinux.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>But the same code causes a General =
Protection Fault=20
in my mips linux. I tested the same code in mips running on uClinux =
which runs=20
well.</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2>what is wrong with mips =
linux?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>#define=20
__KERNEL_SYSCALLS__</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>#include=20
&lt;linux/version.h&gt;<BR>#ifdef MODULE<BR>#ifdef =
MODVERSIONS<BR>#include=20
&lt;linux/modversions.h&gt;<BR>#endif<BR>#include=20
&lt;linux/module.h&gt;<BR>#else<BR>#define MOD_INC_USE_COUNT<BR>#define=20
MOD_DEC_USE_COUNT<BR>#endif</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>#include=20
&lt;linux/types.h&gt;<BR>#include &lt;linux/unistd.h&gt;<BR>#include=20
&lt;linux/delay.h&gt;<BR>#include &lt;asm/uaccess.h&gt;<BR>#include=20
&lt;asm/io.h&gt;<BR>int test_open(void );<BR>int=20
init_module(void)<BR>{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
printk("\n=20
init_module ");<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
test_open();<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return=20
0;<BR>}<BR>void=20
cleanup_module(void)<BR>{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
printk("\n cleanup module");<BR>}<BR></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>int test_open(void=20
)<BR>{<BR>&nbsp;&nbsp;&nbsp; int ifp,bcount;<BR>&nbsp;&nbsp;&nbsp; =
mm_segment_t=20
fs;<BR>&nbsp;&nbsp;&nbsp; char buffer[0x1000];</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp; // =
for file=20
opening temporarily tell the kernel I am not a user =
for<BR>&nbsp;&nbsp;&nbsp; //=20
memory management segment access<BR>&nbsp;&nbsp;&nbsp; fs =3D=20
get_fs();<BR>&nbsp;&nbsp;&nbsp; set_fs(KERNEL_DS);<BR>&nbsp;&nbsp;&nbsp; =
// open=20
the file with the firmware for uploading<BR>&nbsp;&nbsp;&nbsp; if (ifp =
=3D open(=20
"/etc/hotplug/isl3890.arm", O_RDONLY, 0 ), ifp &lt; =
0)<BR>&nbsp;&nbsp;&nbsp;=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // error opening the=20
file<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; printk( "ERROR: File =
opening=20
did not success \n");<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
set_fs(fs);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return=20
-1;<BR>&nbsp;&nbsp;&nbsp; }<BR>&nbsp;&nbsp;&nbsp;<FONT color=3D#ff0000> =
// enter a=20
loop which reads data blocks from the file and writes =
them<BR>&nbsp;&nbsp;&nbsp;=20
// to the Direct Memory Windows<BR>&nbsp;&nbsp;&nbsp; =
do<BR>&nbsp;&nbsp;&nbsp;=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
bcount =3D=20
read(ifp, &amp;buffer,=20
sizeof(buffer));<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
printk("\n bcount %x ",bcount);<BR>&nbsp;&nbsp;&nbsp;=20
}<BR></FONT>&nbsp;&nbsp;&nbsp; while (bcount !=3D =
0);<BR>&nbsp;&nbsp;&nbsp;=20
close(ifp);<BR>&nbsp;&nbsp;&nbsp; // switch back the segment=20
setting<BR>&nbsp;&nbsp;&nbsp; set_fs(fs);</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp; =
return=20
0;<BR>}<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</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></DIV></BODY></HTML>

------=_NextPart_000_0075_01C3AC4E.20B73510--


From tbm@cyrius.com Sun Nov 16 12:44:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 Nov 2003 12:44:33 +0000 (GMT)
Received: from bangpath.uucico.de ([IPv6:::ffff:195.71.9.197]:30225 "EHLO
	bangpath.uucico.de") by linux-mips.org with ESMTP
	id <S8225310AbTKPMoV>; Sun, 16 Nov 2003 12:44:21 +0000
Received: by bangpath.uucico.de (Postfix, from userid 10)
	id E531326B2F; Sun, 16 Nov 2003 13:44:19 +0100 (CET)
Received: by deprecation.cyrius.com (Postfix, from userid 1000)
	id B89DEFEB6; Sun, 16 Nov 2003 23:44:00 +1100 (EST)
Date: Sun, 16 Nov 2003 23:44:00 +1100
From: Martin Michlmayr <tbm@cyrius.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: SNI RM200
Message-ID: <20031116124400.GA1263@deprecation.cyrius.com>
References: <20031112124519.GA6403@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031112124519.GA6403@linux-mips.org>
User-Agent: Mutt/1.5.4i
Return-Path: <tbm@cyrius.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3625
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tbm@cyrius.com
Precedence: bulk
X-list: linux-mips
Content-Length: 366
Lines: 11

* Ralf Baechle <ralf@linux-mips.org> [2003-11-12 13:45]:
> For those of you having a dusty RM200 in their cellar, I've
> resurrected the RM200 port in 2.6.  Only the RM200 C aka RM200 PCI

Since you're currently cleaning up stuff, do you know the status of
Origin 200 and 2000 support?  Will a 4 or 8 way Origin 2000 run
stable?

-- 
Martin Michlmayr
tbm@cyrius.com

From ralf@linux-mips.org Sun Nov 16 22:52:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 Nov 2003 22:52:24 +0000 (GMT)
Received: from p508B6365.dip.t-dialin.net ([IPv6:::ffff:80.139.99.101]:12182
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225346AbTKPWwM>; Sun, 16 Nov 2003 22:52:12 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAGMpZA0013174;
	Sun, 16 Nov 2003 23:51:36 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAGMpXkR013173;
	Sun, 16 Nov 2003 23:51:33 +0100
Date: Sun, 16 Nov 2003 23:51:33 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: durai <durai@isofttech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: file handling in kernel mode
Message-ID: <20031116225133.GA7808@linux-mips.org>
References: <92F2591F460F684C9C309EB0D33256FA01B750B8@trid-mail1.tridentmicro.com> <20031115125329.GA324@linux-mips.org> <007801c3ac20$070adff0$0205a8c0@DURAI>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <007801c3ac20$070adff0$0205a8c0@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: 3626
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sun, Nov 16, 2003 at 02:30:05PM +0530, durai wrote:

> Hello,
> I need to read a file from a device driver and i wrote a sample driver
> like this
> 
> This kernel mode code which try to read the file until end of file is
> reached. This code had been is working without any problems in RedHat
> linux and uClinux.
> But the same code causes a General Protection Fault in my mips linux.
> I tested the same code in mips running on uClinux which runs well.
> what is wrong with mips linux?

If the screen says general protection fault it's wasn't a MIPS box :-)

> #define __KERNEL_SYSCALLS__
> 
> #include <linux/version.h>
> #ifdef MODULE
> #ifdef MODVERSIONS
> #include <linux/modversions.h>
> #endif
> #include <linux/module.h>
> #else
> #define MOD_INC_USE_COUNT
> #define MOD_DEC_USE_COUNT
> #endif

Ouch.  You can replace that all with a single line:

#include <linux/module.h>

> int init_module(void)

[...]

> void cleanup_module(void)

[...]

The use of init_module and cleanup_module is deprecated, use something
like this instead:

#include <linux/init.h>

static int __init foo_init_module(void)
{
	return 0;
}

static void __exit foo_cleanup_module(void)
{
}

module_init(foo_init_module);
module_exit(foo_cleanup_module);


> int test_open(void )
> {
>     int ifp,bcount;
>     mm_segment_t fs;
>     char buffer[0x1000];
                  ^^^^^^

And this is the BIG no-no.  Never allocate large amounts of data on the
kernel stack which is only 8k which are used for various other stuff
also..

> 
>     // for file opening temporarily tell the kernel I am not a user for
>     // memory management segment access
>     fs = get_fs();
>     set_fs(KERNEL_DS);
>     // open the file with the firmware for uploading
>     if (ifp = open( "/etc/hotplug/isl3890.arm", O_RDONLY, 0 ), ifp < 0)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^

Hard coding file names is generally considered bad design; this topic has
been discussed to death numerous times on linux-kernel.  The general
recommendation is to use a special such as /dev/foodevice; the firmware
would then simply be loader by cat bar > //dev/foodevice or similar.

For 2.4.23 (I'm going to merge with 2.4.23-rc1 tonight) and 2.6 the
recommendation is to use CONFIG_FW_LOADER, the new standard interface
for loading firmware.

  Ralf

From ralf@linux-mips.org Sun Nov 16 22:56:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 Nov 2003 22:56:15 +0000 (GMT)
Received: from p508B6365.dip.t-dialin.net ([IPv6:::ffff:80.139.99.101]:27542
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225346AbTKPW4E>; Sun, 16 Nov 2003 22:56:04 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAGMtaA0013263;
	Sun, 16 Nov 2003 23:55:36 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAGMtZ43013262;
	Sun, 16 Nov 2003 23:55:35 +0100
Date: Sun, 16 Nov 2003 23:55:35 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Martin Michlmayr <tbm@cyrius.com>
Cc: linux-mips@linux-mips.org
Subject: Re: SNI RM200
Message-ID: <20031116225535.GB7808@linux-mips.org>
References: <20031112124519.GA6403@linux-mips.org> <20031116124400.GA1263@deprecation.cyrius.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031116124400.GA1263@deprecation.cyrius.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: 3627
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sun, Nov 16, 2003 at 11:44:00PM +1100, Martin Michlmayr wrote:

> * Ralf Baechle <ralf@linux-mips.org> [2003-11-12 13:45]:
> > For those of you having a dusty RM200 in their cellar, I've
> > resurrected the RM200 port in 2.6.  Only the RM200 C aka RM200 PCI
> 
> Since you're currently cleaning up stuff, do you know the status of
> Origin 200 and 2000 support?  Will a 4 or 8 way Origin 2000 run
> stable?

IP27 doesn't even build in 2.6.  It's by far the most complex supported
machine and getting it to work takes some non-trivial changes - also
to get rid of the various hacks we used to have in device drivers to
get the Origin working.  I'll announce once I have IP27 working again -
not last because I'll also need an Origin 2000 system for testing; I only
have an Origin 200 for testing.

  Ralf

From brad@parker.boston.ma.us Mon Nov 17 00:47:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Nov 2003 00:47:51 +0000 (GMT)
Received: from [IPv6:::ffff:24.34.109.122] ([IPv6:::ffff:24.34.109.122]:19976
	"EHLO compaq.parker.boston.ma.us") by linux-mips.org with ESMTP
	id <S8225203AbTKQArT>; Mon, 17 Nov 2003 00:47:19 +0000
Received: from p2.parker.boston.ma.us (p2 [192.245.5.16])
	by compaq.parker.boston.ma.us (8.11.6/8.11.6) with ESMTP id hAH0kZ426174;
	Sun, 16 Nov 2003 19:46:36 -0500
Received: from p2 (brad@localhost)
	by p2.parker.boston.ma.us (8.11.6/8.11.6) with ESMTP id hAH0kZX16327;
	Sun, 16 Nov 2003 19:46:35 -0500
Message-Id: <200311170046.hAH0kZX16327@p2.parker.boston.ma.us>
To: Ralf Baechle <ralf@linux-mips.org>
cc: durai <durai@isofttech.com>, linux-mips@linux-mips.org
Subject: Re: file handling in kernel mode 
In-Reply-To: Message from Ralf Baechle <ralf@linux-mips.org> 
   of "Sun, 16 Nov 2003 23:51:33 +0100." <20031116225133.GA7808@linux-mips.org> 
X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 20.7.1
Date: Sun, 16 Nov 2003 19:46:35 -0500
From: Brad Parker <brad@parker.boston.ma.us>
Return-Path: <brad@parker.boston.ma.us>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3628
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brad@parker.boston.ma.us
Precedence: bulk
X-list: linux-mips


>On Sun, Nov 16, 2003 at 02:30:05PM +0530, durai wrote:
>
>> Hello,
>> I need to read a file from a device driver and i wrote a sample driver
>> like this
>> 
>> This kernel mode code which try to read the file until end of file is
>> reached. This code had been is working without any problems in RedHat
>> linux and uClinux.
>> But the same code causes a General Protection Fault in my mips linux.
>> I tested the same code in mips running on uClinux which runs well.
>> what is wrong with mips linux?

Shouldn't someone point out that having a driver read a file is 
very, very wrong and a classic FAQ question?

Perhaps I'm mistaken but this seems to come up once a year on every port
list I'm on.

The "unix way" is to have something in userland feed the data to the
driver.  Things in the kernel should never reach back up into the file
system. It's just not done.

Drivers are passive objects which do the bidding of "managers" which
live in userland.  Add an ioctl to the driver which allows a userland
daemon to feed the microcode/firmware/fpga-data/whatever to the driver
in pieces.

Resist the temptation to put code in the driver to access the file
system.

ps: isn't hotplug already setup to notice when a device comes up and to
have a shell script run?  it's bad enough that the hotplug code runs a
shell script from the kernel.  I can't believe that got through...

(and if you have time, go read the plan 9 design docs.  then ask yourself
what those guys would do :-)

-brad


From ralf@linux-mips.org Mon Nov 17 01:08:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Nov 2003 01:08:12 +0000 (GMT)
Received: from p508B6365.dip.t-dialin.net ([IPv6:::ffff:80.139.99.101]:9630
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225373AbTKQBIA>; Mon, 17 Nov 2003 01:08:00 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAH176A0021130;
	Mon, 17 Nov 2003 02:07:06 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAH16WQV021123;
	Mon, 17 Nov 2003 02:06:32 +0100
Date: Mon, 17 Nov 2003 02:06:32 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Brad Parker <brad@parker.boston.ma.us>
Cc: durai <durai@isofttech.com>, linux-mips@linux-mips.org
Subject: Re: file handling in kernel mode
Message-ID: <20031117010631.GA20737@linux-mips.org>
References: <20031116225133.GA7808@linux-mips.org> <200311170046.hAH0kZX16327@p2.parker.boston.ma.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200311170046.hAH0kZX16327@p2.parker.boston.ma.us>
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: 3629
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sun, Nov 16, 2003 at 07:46:35PM -0500, Brad Parker wrote:

> Shouldn't someone point out that having a driver read a file is 
> very, very wrong and a classic FAQ question?

It is.

> Perhaps I'm mistaken but this seems to come up once a year on every port
> list I'm on.

I think it's the first time on this list.  In my previous posting I suggested
request_firmware for 2.4.23 / 2.6.  For kernels older than this I suggest
arch/i386/kernel/microcode.c as an example for how to easily implement
a character special file.

> Resist the temptation to put code in the driver to access the file
> system.

Amen.

> ps: isn't hotplug already setup to notice when a device comes up and to
> have a shell script run?  it's bad enough that the hotplug code runs a
> shell script from the kernel.  I can't believe that got through...
> 
> (and if you have time, go read the plan 9 design docs.  then ask yourself
> what those guys would do :-)

2.6 certainly is quite a bit more plan 9-ish.  What would you expect from
Al Viro :-)

  Ralf

From ashish_ibm@rediffmail.com Mon Nov 17 11:40:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Nov 2003 11:41:23 +0000 (GMT)
Received: from webmail27.rediffmail.com ([IPv6:::ffff:203.199.83.37]:39119
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225381AbTKQLkv>; Mon, 17 Nov 2003 11:40:51 +0000
Received: (qmail 22353 invoked by uid 510); 17 Nov 2003 11:40:11 -0000
Date: 17 Nov 2003 11:40:11 -0000
Message-ID: <20031117114011.22352.qmail@webmail27.rediffmail.com>
Received: from unknown (210.210.7.195) by rediffmail.com via HTTP; 17 nov 2003 11:40:11 -0000
MIME-Version: 1.0
From: "ashish  anand" <ashish_ibm@rediffmail.com>
Reply-To: "ashish  anand" <ashish_ibm@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: is cp0 interrupt infrastructure sufficient..?
Content-type: multipart/alternative;
	boundary="Next_1069069211---0-203.199.83.37-22293"
Return-Path: <ashish_ibm@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3630
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish_ibm@rediffmail.com
Precedence: bulk
X-list: linux-mips

 This is a multipart mime message


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

<P>=0AI have a generic question regarding interrupt controler functionality=
 <BR>=0Aintegrated in CP0 on mips architecture.<BR>=0AI don't see any inter=
face to configure the edge/level triggering settings.<BR>=0A<BR>=0Athough i=
n our BSP we take care of handling spurious interrupts , but is<BR>=0Athis =
designed to be like that..?<BR>=0A<BR>=0AI mean to ask , suppose I want to =
add a edge triggering peripheral <BR>=0A, to the extent of my understanding=
 this will certainly generate the<BR>=0Aspurious interrupts when coupled wi=
th a level triggering configuration <BR>=0Ain CP0 (by default..?).<BR>=0A<B=
R>=0Aif i am handling through CP0_CAUSE or any other register inspection<BR=
>=0Athat can work but I am loosing so many valid interupts which would have=
 been really valid with edge trigger pin of interrupt controller&nbsp; .<BR=
>=0Afurther this type of handling is valid for actual spurious interrupts <=
BR>=0Anot for those who are certain to be fired because of edge/level misma=
tching.<BR>=0A<BR>=0ABest Regards,<BR>=0AAshish Anand<BR>=0A<BR>=0A<BR>=0A<=
BR>=0A<BR>=0A=0A</P>=0A<br><br>=0A<A target=3D"_blank" HREF=3D"http://clien=
ts.rediff.com/signature/track_sig.asp"><IMG SRC=3D"http://ads.rediff.com/Re=
alMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=3D0=
 VSPACE=3D0 HSPACE=3D0 HEIGHT=3D74 WIDTH=3D496></a>=0A
--Next_1069069211---0-203.199.83.37-22293
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I have a generic question regarding interrupt controler functionality =0Ain=
tegrated in CP0 on mips architecture.=0AI don't see any interface to config=
ure the edge/level triggering settings.=0A=0Athough in our BSP we take care=
 of handling spurious interrupts , but is=0Athis designed to be like that..=
?=0A=0AI mean to ask , suppose I want to add a edge triggering peripheral =
=0A, to the extent of my understanding this will certainly generate the=0As=
purious interrupts when coupled with a level triggering configuration =0Ain=
 CP0 (by default..?).=0A=0Aif i am handling through CP0_CAUSE or any other =
register inspection=0Athat can work but I am loosing so many valid interupt=
s which would have been really valid with edge trigger pin of interrupt con=
troller  .=0Afurther this type of handling is valid for actual spurious int=
errupts =0Anot for those who are certain to be fired because of edge/level =
mismatching.=0A=0ABest Regards,=0AAshish Anand=0A=0A=0A=0A=0A
--Next_1069069211---0-203.199.83.37-22293--


From ralf@linux-mips.org Mon Nov 17 13:19:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Nov 2003 13:19:19 +0000 (GMT)
Received: from p508B6BAF.dip.t-dialin.net ([IPv6:::ffff:80.139.107.175]:23495
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225383AbTKQNTH>; Mon, 17 Nov 2003 13:19:07 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAHDJ5A0006432;
	Mon, 17 Nov 2003 14:19:05 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAHDJ4kp006423;
	Mon, 17 Nov 2003 14:19:04 +0100
Date: Mon, 17 Nov 2003 14:19:04 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: ashish anand <ashish_ibm@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: is cp0 interrupt infrastructure sufficient..?
Message-ID: <20031117131904.GC5221@linux-mips.org>
References: <20031117114011.22352.qmail@webmail27.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031117114011.22352.qmail@webmail27.rediffmail.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: 3631
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Nov 17, 2003 at 11:40:11AM -0000, ashish  anand wrote:

> I have a generic question regarding interrupt controler functionality 
> integrated in CP0 on mips architecture.
> I don't see any interface to configure the edge/level triggering settings.

MIPS only supports level triggered interrupts in coprocessor 0.

> though in our BSP we take care of handling spurious interrupts , but is
> this designed to be like that..?

There is no handling needed.  If the processor takes an interrupt but none
of the interrupt bits in c0_status is set, just return.  That's a legal
condition.

> I mean to ask , suppose I want to add a edge triggering peripheral.
> to the extent of my understanding this will certainly generate the
> spurious interrupts when coupled with a level triggering configuration 
> in CP0 (by default..?).

You can directly sample the level of the edge irq in the interrupt bits in
the cause register.  But that seems a fragile approach.

> if i am handling through CP0_CAUSE or any other register inspection
> that can work but I am loosing so many valid interupts which would have
> been really valid with edge trigger pin of interrupt controller  .
> further this type of handling is valid for actual spurious interrupts 
> not for those who are certain to be fired because of edge/level mismatching.

If you really need to use an edge triggered interrupt on a MIPS then you
probably want to use some circuit interrupt controller that converts the
edge to a level triggered interrupt.  

  Ralf

From baitisj@evolution.com Mon Nov 17 20:01:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Nov 2003 20:01:35 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:61082 "EHLO
	powerpuff.evo1.pas.lab") by linux-mips.org with ESMTP
	id <S8225346AbTKQUBX>; Mon, 17 Nov 2003 20:01:23 +0000
Received: from powerpuff.evo1.pas.lab (localhost.localdomain [127.0.0.1])
	by powerpuff.evo1.pas.lab (8.12.8/8.12.8) with ESMTP id hAHK1Kcg016682
	for <linux-mips@linux-mips.org>; Mon, 17 Nov 2003 12:01:20 -0800
Received: (from baitisj@localhost)
	by powerpuff.evo1.pas.lab (8.12.8/8.12.8/Submit) id hAHK1JoV016678
	for linux-mips@linux-mips.org; Mon, 17 Nov 2003 12:01:19 -0800
X-Authentication-Warning: powerpuff.evo1.pas.lab: baitisj set sender to baitisj@evolution.com using -f
Subject: Patch against drivers/ide/pci/it8172.c branch linux_2_4
From: Jeffrey Baitis <baitisj@evolution.com>
Reply-To: baitisj@evolution.com
To: linux-mips@linux-mips.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1069099279.1830.109.camel@powerpuff.evo1.pas.lab>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 17 Nov 2003 12:01:19 -0800
Return-Path: <baitisj@evolution.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3632
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

Here's a patch to make this compile...
-Jeff


Index: drivers/ide/pci/it8172.c
===================================================================
RCS file: /home/cvs/linux/drivers/ide/pci/it8172.c,v
retrieving revision 1.4.2.2
diff -u -r1.4.2.2 it8172.c
--- drivers/ide/pci/it8172.c    5 Jul 2003 03:23:36 -0000       1.4.2.2
+++ drivers/ide/pci/it8172.c    17 Nov 2003 19:58:32 -0000
@@ -57,7 +57,7 @@
 {
        ide_hwif_t *hwif        = HWIF(drive);
        struct pci_dev *dev     = hwif->pci_dev;
-       int is_slave            = (hwif->drives[1] == drive);
+       int is_slave            = (&HWIF(drive)->drives[1] == drive);
        unsigned long flags;
        u16 drive_enables;
        u32 drive_timing;
@@ -95,7 +95,7 @@
        }
 
        pci_write_config_word(dev, 0x40, drive_enables);
-       spin_unlock_irqrestore(&ide_lock, flags)
+       spin_unlock_irqrestore(&ide_lock, flags);
 }



-- 
Jeffrey Baitis <baitisj@evolution.com>

From Steve.Finney@SpirentCom.COM Mon Nov 17 21:22:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Nov 2003 21:22:22 +0000 (GMT)
Received: from Iris.Adtech-Inc.COM ([IPv6:::ffff:63.165.80.18]:1540 "EHLO
	iris.Adtech-Inc.COM") by linux-mips.org with ESMTP
	id <S8225346AbTKQVWK> convert rfc822-to-8bit; Mon, 17 Nov 2003 21:22:10 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Subject: Sibyte/Broadcom 1250 documentation
Date: Mon, 17 Nov 2003 11:22:01 -1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Message-ID: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB7BE@iris.adtech-inc.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Sibyte/Broadcom 1250 documentation
Thread-Index: AcOtUMr5WWjVuNKdSGm0G6lA1eqm7Q==
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: 3633
X-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

A little while ago, I believe someone on this list stated that documentation for the SB1250 chip wasn't publicly available. I just noticed that the user manual (a primary source of chip documentation) is available on Broadcom's public-access web site (sibyte.broadcom.com). I couldn't find the documentation for the actual SB-1  core there, though...

sf

From baitisj@evolution.com Mon Nov 17 22:05:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Nov 2003 22:05:40 +0000 (GMT)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:9883 "EHLO
	powerpuff.evo1.pas.lab") by linux-mips.org with ESMTP
	id <S8225346AbTKQWF2>; Mon, 17 Nov 2003 22:05:28 +0000
Received: from powerpuff.evo1.pas.lab (localhost.localdomain [127.0.0.1])
	by powerpuff.evo1.pas.lab (8.12.8/8.12.8) with ESMTP id hAHM4Vcg016761;
	Mon, 17 Nov 2003 14:04:31 -0800
Received: (from baitisj@localhost)
	by powerpuff.evo1.pas.lab (8.12.8/8.12.8/Submit) id hAHM4RdA016757;
	Mon, 17 Nov 2003 14:04:27 -0800
X-Authentication-Warning: powerpuff.evo1.pas.lab: baitisj set sender to baitisj@evolution.com using -f
Subject: Newbie R5K questions -- -mips2 vs -mips4; is n32 ABI supported by
	Linux?
From: Jeffrey Baitis <baitisj@evolution.com>
Reply-To: baitisj@evolution.com
To: linux-mips@linux-mips.org
Cc: Adam_Kiepul@pmc-sierra.com,
	"Mr. Brian R. Gunnison" <brian@evolution.com>,
	Francis Yu <francisyu@synergyrep.com>,
	Johnny Lam <Johnny_Lam@pmc-sierra.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1069106666.1829.323.camel@powerpuff.evo1.pas.lab>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 17 Nov 2003 14:04:26 -0800
Return-Path: <baitisj@evolution.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3634
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips

Hi all:

I'm currently trying to increase performance on our PMC-Sierra RM5231
system by taking advantage of the MIPS IV ISA. This processor has a
32-bit address bus interface with 64-bit GPRs, so I guess that the
choice of -mabi=n32 is ideal for this processor.

Why is it that the Linux kernel defaults to -mcpu=r5000 -mips2 for the
52XX? Wouldn't there be good reasons to use the enhancements present in
the MIPS IV instruction set?

I've tried modifying the mips Makefile so that the Nevada adds the
cflags -mabi=n32 -mcpu=r5000 -mips4. I also modified asm/unistd.h so
that __NR_sigreturn is defined for the case where _MIPS_SIM ==
_MIPS_SIM_NABI32. Unfortunately, I get link errors: (gcc 3.2.3)

        arch/mips/kernel/kernel.o(.data+0x4240): undefined reference to
        `sys_stat64'
        arch/mips/kernel/kernel.o(.data+0x4244): undefined reference to
        `sys_lstat64'
        arch/mips/kernel/kernel.o(.data+0x4248): undefined reference to
        `sys_fstat64'
        drivers/ide/idedriver.o(.data.init+0x8): undefined reference to
        `init_setup_it8172'
        

The goal is that I want to be able to execute MIPS IV or MIPS III
instructions in user mode, since the profiling program that I'm using is
based in userspace and does not measure kernel performance. I already
have measured performance using MIPS I binaries. Under a -mips1-compiled
uClibc/busybox root filesystem, I tried executing -mips2, -mips3, and
-mips4 binaries -- but it seemed that the ELF interpreter was unable to
recognize them as valid ELF files (resulting in a shell 'Syntax Error').

After doing some digging, I found some documentation on SGI's website
about different ABI levels:

http://www.parallab.uib.no/SGI_bookshelves/SGI_Developer/books/MproCplrDbx_TG/sgi_html/ch06.html#Z70233

Here, I read that the OS, my libraries, and, of course, the application
must support the ABI of my choice. So, this takes me to my second
question: does Linux support the n32 ABI? How do I enable this support,
so that it is possible to take advantage of MIPS IV instructions?

Is there a book or FAQ that can answer questions such as these?

Thank you very much for any help.

Regards,

Jeff


-- 
Jeffrey Baitis <baitisj@evolution.com>

From drow@crack.them.org Mon Nov 17 22:29:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Nov 2003 22:30:04 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:47246 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225391AbTKQW3w>;
	Mon, 17 Nov 2003 22:29:52 +0000
Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian))
	id 1ALrsK-0002i1-8d; Mon, 17 Nov 2003 17:29:40 -0500
Date: Mon, 17 Nov 2003 17:29:40 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Jeffrey Baitis <baitisj@evolution.com>
Cc: linux-mips@linux-mips.org, Adam_Kiepul@pmc-sierra.com,
	"Mr. Brian R. Gunnison" <brian@evolution.com>,
	Francis Yu <francisyu@synergyrep.com>,
	Johnny Lam <Johnny_Lam@pmc-sierra.com>
Subject: Re: Newbie R5K questions -- -mips2 vs -mips4; is n32 ABI supported by Linux?
Message-ID: <20031117222940.GA10372@nevyn.them.org>
References: <1069106666.1829.323.camel@powerpuff.evo1.pas.lab>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1069106666.1829.323.camel@powerpuff.evo1.pas.lab>
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: 3635
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Mon, Nov 17, 2003 at 02:04:26PM -0800, Jeffrey Baitis wrote:
> Hi all:
> 
> I'm currently trying to increase performance on our PMC-Sierra RM5231
> system by taking advantage of the MIPS IV ISA. This processor has a
> 32-bit address bus interface with 64-bit GPRs, so I guess that the
> choice of -mabi=n32 is ideal for this processor.
> 
> Why is it that the Linux kernel defaults to -mcpu=r5000 -mips2 for the
> 52XX? Wouldn't there be good reasons to use the enhancements present in
> the MIPS IV instruction set?
> 
> I've tried modifying the mips Makefile so that the Nevada adds the
> cflags -mabi=n32 -mcpu=r5000 -mips4. I also modified asm/unistd.h so
> that __NR_sigreturn is defined for the case where _MIPS_SIM ==
> _MIPS_SIM_NABI32. Unfortunately, I get link errors: (gcc 3.2.3)
> 
>         arch/mips/kernel/kernel.o(.data+0x4240): undefined reference to
>         `sys_stat64'
>         arch/mips/kernel/kernel.o(.data+0x4244): undefined reference to
>         `sys_lstat64'
>         arch/mips/kernel/kernel.o(.data+0x4248): undefined reference to
>         `sys_fstat64'
>         drivers/ide/idedriver.o(.data.init+0x8): undefined reference to
>         `init_setup_it8172'

Do not even attempt to run an n32 kernel.  Use a 64-bit kernel (you
can't just say -mabi=n64, of course!  See ARCH=mips64 in 2.4 or
CONFIG_MIPS64 in 2.6).

> The goal is that I want to be able to execute MIPS IV or MIPS III
> instructions in user mode, since the profiling program that I'm using is
> based in userspace and does not measure kernel performance. I already
> have measured performance using MIPS I binaries. Under a -mips1-compiled
> uClibc/busybox root filesystem, I tried executing -mips2, -mips3, and
> -mips4 binaries -- but it seemed that the ELF interpreter was unable to
> recognize them as valid ELF files (resulting in a shell 'Syntax Error').
> 
> After doing some digging, I found some documentation on SGI's website
> about different ABI levels:
> 
> http://www.parallab.uib.no/SGI_bookshelves/SGI_Developer/books/MproCplrDbx_TG/sgi_html/ch06.html#Z70233
> 
> Here, I read that the OS, my libraries, and, of course, the application
> must support the ABI of my choice. So, this takes me to my second
> question: does Linux support the n32 ABI? How do I enable this support,
> so that it is possible to take advantage of MIPS IV instructions?

Currently, the tools are just beginning to support n32 and n64 user
programs.  No released version of binutils, gcc, or glibc contains the
support.  Current CVS versions may or may not.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ralf@linux-mips.org Mon Nov 17 22:53:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Nov 2003 22:53:49 +0000 (GMT)
Received: from p508B6BAF.dip.t-dialin.net ([IPv6:::ffff:80.139.107.175]:9960
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225346AbTKQWxh>; Mon, 17 Nov 2003 22:53:37 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAHMqvA0016385;
	Mon, 17 Nov 2003 23:52:57 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAHMqmX3016381;
	Mon, 17 Nov 2003 23:52:48 +0100
Date: Mon, 17 Nov 2003 23:52:48 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jeffrey Baitis <baitisj@evolution.com>
Cc: linux-mips@linux-mips.org, Adam_Kiepul@pmc-sierra.com,
	"Mr. Brian R. Gunnison" <brian@evolution.com>,
	Francis Yu <francisyu@synergyrep.com>,
	Johnny Lam <Johnny_Lam@pmc-sierra.com>
Subject: Re: Newbie R5K questions -- -mips2 vs -mips4; is n32 ABI supported by Linux?
Message-ID: <20031117225248.GA15868@linux-mips.org>
References: <1069106666.1829.323.camel@powerpuff.evo1.pas.lab>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1069106666.1829.323.camel@powerpuff.evo1.pas.lab>
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: 3636
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Nov 17, 2003 at 02:04:26PM -0800, Jeffrey Baitis wrote:

> I'm currently trying to increase performance on our PMC-Sierra RM5231
> system by taking advantage of the MIPS IV ISA. This processor has a
> 32-bit address bus interface with 64-bit GPRs, so I guess that the
> choice of -mabi=n32 is ideal for this processor.

In addition to what Daniel just said ...

N32 requires a 64-bit kernel to run on which is significantly larger
thereby causing more cache misses so a 64-bit kernel is often slower.
On the kernel side a 64-bit kernel is drastically better at handling
large amounts of memory, so once a 32-bit kernel needs highmem the
64-bit kernel will win the race.  Often these effects influence
performance more than what you might gain from exploiting a new ISA.

  Ralf

From ashish_ibm@rediffmail.com Tue Nov 18 07:01:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Nov 2003 07:01:54 +0000 (GMT)
Received: from webmail29.rediffmail.com ([IPv6:::ffff:203.199.83.39]:38286
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225501AbTKRHBW>; Tue, 18 Nov 2003 07:01:22 +0000
Received: (qmail 27153 invoked by uid 510); 18 Nov 2003 06:57:41 -0000
Date: 18 Nov 2003 06:57:41 -0000
Message-ID: <20031118065741.27152.qmail@webmail29.rediffmail.com>
Received: from unknown (210.210.7.195) by rediffmail.com via HTTP; 18 nov 2003 06:57:41 -0000
MIME-Version: 1.0
From: "ashish  anand" <ashish_ibm@rediffmail.com>
Reply-To: "ashish  anand" <ashish_ibm@rediffmail.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Assertion duration of edge interrupts can decrease spurious interrupts ..?
Content-type: multipart/alternative;
	boundary="Next_1069138661---0-203.199.83.39-27131"
Return-Path: <ashish_ibm@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3637
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish_ibm@rediffmail.com
Precedence: bulk
X-list: linux-mips

 This is a multipart mime message


--Next_1069138661---0-203.199.83.39-27131
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0A1.If i have a compulsion to use egde triggering peripheral on MIPS CP=
0,<BR>=0Awould it be useful if i can increase the assertion duration of edg=
e<BR>=0Ainterupts (this I can do) ..I mean to say probablity of loosing edg=
e interrupts will decrasse.<BR>=0A<BR>=0A2.does CP0 interrupt logic samples=
 interrupts after each instruction or at some multiplication(..or division.=
?) of system clock.<BR>=0A<BR>=0ARegards,<BR>=0AAshish<BR>=0A<BR>=0AOn Mon,=
 17 Nov 2003 Ralf Baechle wrote :<BR>=0A&gt;On Mon, Nov 17, 2003 at 11:40:1=
1AM -0000, ashish&nbsp; anand wrote:<BR>=0A&gt;<BR>=0A&gt; &gt; I have a ge=
neric question regarding interrupt controler functionality<BR>=0A&gt; &gt; =
integrated in CP0 on mips architecture.<BR>=0A&gt; &gt; I don't see any int=
erface to configure the edge/level triggering settings.<BR>=0A&gt;<BR>=0A&g=
t;MIPS only supports level triggered interrupts in coprocessor 0.<BR>=0A&gt=
;<BR>=0A&gt; &gt; though in our BSP we take care of handling spurious inter=
rupts , but is<BR>=0A&gt; &gt; this designed to be like that..?<BR>=0A&gt;<=
BR>=0A&gt;There is no handling needed.&nbsp; If the processor takes an inte=
rrupt but none<BR>=0A&gt;of the interrupt bits in c0_status is set, just re=
turn.&nbsp; That's a legal<BR>=0A&gt;condition.<BR>=0A&gt;<BR>=0A&gt; &gt; =
I mean to ask , suppose I want to add a edge triggering peripheral.<BR>=0A&=
gt; &gt; to the extent of my understanding this will certainly generate the=
<BR>=0A&gt; &gt; spurious interrupts when coupled with a level triggering c=
onfiguration<BR>=0A&gt; &gt; in CP0 (by default..?).<BR>=0A&gt;<BR>=0A&gt;Y=
ou can directly sample the level of the edge irq in the interrupt bits in<B=
R>=0A&gt;the cause register.&nbsp; But that seems a fragile approach.<BR>=
=0A&gt;<BR>=0A&gt; &gt; if i am handling through CP0_CAUSE or any other reg=
ister inspection<BR>=0A&gt; &gt; that can work but I am loosing so many val=
id interupts which would have<BR>=0A&gt; &gt; been really valid with edge t=
rigger pin of interrupt controller&nbsp; .<BR>=0A&gt; &gt; further this typ=
e of handling is valid for actual spurious interrupts<BR>=0A&gt; &gt; not f=
or those who are certain to be fired because of edge/level mismatching.<BR>=
=0A&gt;<BR>=0A&gt;If you really need to use an edge triggered interrupt on =
a MIPS then you<BR>=0A&gt;probably want to use some circuit interrupt contr=
oller that converts the<BR>=0A&gt;edge to a level triggered interrupt.<BR>=
=0A&gt;<BR>=0A&gt;&nbsp;  Ralf<BR>=0A=0A</P>=0A<br><br>=0A<A target=3D"_bla=
nk" HREF=3D"http://clients.rediff.com/signature/track_sig.asp"><IMG SRC=3D"=
http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbo=
x.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0 HEIGHT=3D74 WIDTH=3D496></a>=
=0A
--Next_1069138661---0-203.199.83.39-27131
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

1.If i have a compulsion to use egde triggering peripheral on MIPS CP0,=0Aw=
ould it be useful if i can increase the assertion duration of edge=0Ainteru=
pts (this I can do) ..I mean to say probablity of loosing edge interrupts w=
ill decrasse.=0A=0A2.does CP0 interrupt logic samples interrupts after each=
 instruction or at some multiplication(..or division.?) of system clock.=0A=
=0ARegards,=0AAshish=0A=0AOn Mon, 17 Nov 2003 Ralf Baechle wrote :=0A>On Mo=
n, Nov 17, 2003 at 11:40:11AM -0000, ashish  anand wrote:=0A>=0A> > I have =
a generic question regarding interrupt controler functionality=0A> > integr=
ated in CP0 on mips architecture.=0A> > I don't see any interface to config=
ure the edge/level triggering settings.=0A>=0A>MIPS only supports level tri=
ggered interrupts in coprocessor 0.=0A>=0A> > though in our BSP we take car=
e of handling spurious interrupts , but is=0A> > this designed to be like t=
hat..?=0A>=0A>There is no handling needed.  If the processor takes an inter=
rupt but none=0A>of the interrupt bits in c0_status is set, just return.  T=
hat's a legal=0A>condition.=0A>=0A> > I mean to ask , suppose I want to add=
 a edge triggering peripheral.=0A> > to the extent of my understanding this=
 will certainly generate the=0A> > spurious interrupts when coupled with a =
level triggering configuration=0A> > in CP0 (by default..?).=0A>=0A>You can=
 directly sample the level of the edge irq in the interrupt bits in=0A>the =
cause register.  But that seems a fragile approach.=0A>=0A> > if i am handl=
ing through CP0_CAUSE or any other register inspection=0A> > that can work =
but I am loosing so many valid interupts which would have=0A> > been really=
 valid with edge trigger pin of interrupt controller  .=0A> > further this =
type of handling is valid for actual spurious interrupts=0A> > not for thos=
e who are certain to be fired because of edge/level mismatching.=0A>=0A>If =
you really need to use an edge triggered interrupt on a MIPS then you=0A>pr=
obably want to use some circuit interrupt controller that converts the=0A>e=
dge to a level triggered interrupt.=0A>=0A>   Ralf=0A
--Next_1069138661---0-203.199.83.39-27131--


From ralf@linux-mips.org Tue Nov 18 13:13:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Nov 2003 13:13:47 +0000 (GMT)
Received: from p508B5E38.dip.t-dialin.net ([IPv6:::ffff:80.139.94.56]:27050
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225380AbTKRNNf>; Tue, 18 Nov 2003 13:13:35 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAIDDXA0018708;
	Tue, 18 Nov 2003 14:13:34 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAIDDXaU018699;
	Tue, 18 Nov 2003 14:13:33 +0100
Date: Tue, 18 Nov 2003 14:13:33 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: ashish anand <ashish_ibm@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Assertion duration of edge interrupts can decrease spurious interrupts ..?
Message-ID: <20031118131333.GC17503@linux-mips.org>
References: <20031118065741.27152.qmail@webmail29.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031118065741.27152.qmail@webmail29.rediffmail.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: 3638
X-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, Nov 18, 2003 at 06:57:41AM -0000, ashish  anand wrote:

> 1.If i have a compulsion to use egde triggering peripheral on MIPS CP0,
> would it be useful if i can increase the assertion duration of edge
> interupts (this I can do) ..I mean to say probablity of loosing edge
> interrupts will decrasse.

That would help but still not be a safe mechanism.  Not only the processor
may be missing the edge - Linux may also disable interrupts for quite a
long time.  You'd have to use a hard realtime variant of Linux or you will
loose interrupts ...

> 2.does CP0 interrupt logic samples interrupts after each instruction or
> at some multiplication(..or division.?) of system clock.

This is a very processor specific detail.  R4000 for example will sample
interrupts on pipe stage 3; something along that lines is probably done
in most in-order processors.

  Ralf

From macro@ds2.pg.gda.pl Tue Nov 18 23:03:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Nov 2003 23:03:18 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:40324 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225500AbTKRXDG>; Tue, 18 Nov 2003 23:03:06 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id DC2474AD81; Wed, 19 Nov 2003 00:02:56 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP id B7B3347A4D
	for <linux-mips@linux-mips.org>; Wed, 19 Nov 2003 00:02:56 +0100 (CET)
Date: Wed, 19 Nov 2003 00:02:56 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: linux-mips@linux-mips.org
Subject: [announce] 64-bit toolchain available for the R4000/R4400
Message-ID: <Pine.LNX.4.55.0311182243470.25195@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: 3640
X-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: 5129
Lines: 103

Hello,

 As you might already know the R4000 and revision 1.0 of the R4400
processor suffer from a few errata that make 64-bit operation problematic
with standard code.  Under certain conditions, doubleword addition and
extended shift instructions can produce incorrect results.

 There is no hardware workaround available for these problems, but by
carefully selecting instruction sequences and avoiding certain operations
reliable code can be generated that does not trigger these problems.  The
current version of Linux as present in our CVS executes specific tests for
these errata early during bootstrap and if found, then code is checked for
having been generated by tools that are aware of the respective problem.  
If the code fails such a check then the kernel refuses to boot.

 I'm pleased to announce a toolchain that supports software workarounds
for these errata is available at my site.  The stable versions are:  

1. binutils 2.14:

- mips64el-linux-binutils-2.14-3.src.rpm -- a source package,

- mips64el-linux-binutils-2.14-3.i386.rpm -- an i386 binary package,

2. gcc 2.95.4:

- mips64el-linux-boot-gcc-2.95.4-15.src.rpm -- a source package,

- mips64el-linux-boot-gcc-2.95.4-15.i386.rpm -- an i386 binary package.

3. glibc 2.2.5 (headers needed to rebuild gcc):

- mips64el-linux-boot-glibc-headers-2.2.5-6.src.rpm -- a source package,

- mips64el-linux-boot-glibc-headers-2.2.5-6.noarch.rpm -- an
architecture-independent binary package.

As implied by the names, all these are tools for a cross-compilation.  
Binary packages are provided for convenience only -- a cross-binutils
binary package may be generated for any architecture with a native gcc
compiler from the source package which is self-contained and with the aid
of the supplied glibc headers, the cross-gcc package can be regenerated as
well.

 Due to the lack of support for mips64 in glibc 2.2.x, the gcc package is 
provided in a minimal configuration (hence the -boot- infix) with the 
plain C compiler and libgcc only.  It is sufficient to build Linux 
kernels.

 The toolchain enables workarounds in code generators whenever a 64-bit
output is requested (e.g. "-mabi=64") and either an R4000 or an R4400 CPU
is selected (e.g. "-march=r4000"), as appropriate for the workaround.  

 For the extended shift errata a workaround is activated for the R4000
CPU.  There is no further control of the setting.  When active,
problematic sequences of a multiplication or division and an extended
shift are avoided in the generated code.

 For the doubleword addition errata a workaround is activated for both the
R4000 and the R4400 CPU.  Additionally, there is a new option "-mdaddi"  
and its negation -- "-mno-daddi", recognized by both gcc and gas, which
activate and deactivate the workaround respectively.  There is a pair of
assembly directives, ".set daddi" and ".set nodaddi", as well, which
operate just like respective command line options.  The workaround makes
gcc avoid emitting certain macro instructions that expand to sequences
containing problematic doubleword additions.  For gas it makes problematic
doubleword additions, that would normally be machine instructions, be
expanded as macros using safe replacements.  As a side effect certain
macros have a more strict requirement on their arguments as otherwise two
temporary registers would be needed.  This is the reason gcc needs to
avoid such macros and also why code emitted by `gcc -mdaddi' could not
necessarily be successfully assembled by `as -mno-daddi'.

 You are welcome to use the tools and I'll appreciate feedback.  As a few
assembly bits of the kernel cannot be compiled with "-mno-daddi", I have
prepared appropriate patches, which are available upon request (version
2.4 only).  If you have a processor which has its PRId in the range from
0x0400 to 0x044f inclusive and would like to use a 64-bit kernel, then the
tools are for you.  I've been using 64-bit kernels built with these tools
with my R4400-based DECstation for some time now and they appear no less
stable than their 32-bit counterparts.

 If there are problem reports with the tools I'm going to maintain them
for the time being, but in the long run I'm going to work on merging
appropriate bits into the mainline.  Therefore I do not expect to put much
more work into these particular versions of tools and I'm focusing on
upgrading the changes to apply against current versions of software.  In
particular I'm not going to write any more decent documentation than this
notice before I get the upgrade done (sorry).  My goal is to get gcc
patches upgraded to 3.4 and attempt to merge them into 3.5.  With respect
to binutils, I've already upgraded to 2.14.90 and I suppose to try a merge
attempt for 2.16.

 The address of my site is the same as always:  
'ftp://ftp.ds2.pg.gda.pl/pub/macro/' -- see the "SRPMS" and "RPMS"  
directories for source and binary packages, respectively.

  Maciej

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

From ddaney@avtrex.com Wed Nov 19 01:40:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Nov 2003 01:40:48 +0000 (GMT)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:62797 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225397AbTKSBkg>;
	Wed, 19 Nov 2003 01:40:36 +0000
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 18 Nov 2003 17:40:31 -0800
Message-ID: <3FBACA0F.7070207@avtrex.com>
Date: Tue, 18 Nov 2003 17:40:31 -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: How reliable is GCC-3.3.1 wrt building mipsel-linux kernel?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Nov 2003 01:40:31.0858 (UTC) FILETIME=[1E733D20:01C3AE3E]
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: 3641
X-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: 999
Lines: 27

The subject line kind of says it all.

We are running linux 2.4.18 on a mips4Kc core (ATI Xilleon 225) and find 
it to be quite stable when compiled with gcc 2.96/binutils 2.11.92.0.10

When the kernel is compiled with gcc 3.3.1/binutils 2.14.90.0.5 it also 
seems to be quite stable, except for when one certian driver is used 
(basically an mpeg decoder driver).  Under certian conditions the system 
seems to "freeze" (no messages printed anywhere and only a hard reset 
will recover).

Yeah that is a good bug report...

But my main question is this:  Have other people experienced 
miscompilation (ie bad code generation) with gcc 3.3.1?

One thing I am aware of is that if -fno-common is not used, bad code is 
generated for accessing some large structures.  But I we use -fno-common 
for all compilation.

I am trying to figrue out if I should be looking more at bugs in the 
driver, or if I should give up on gcc 3.3.1 and be done with it.

Thanks in advance for any insight.

David Daney.


From drow@crack.them.org Wed Nov 19 01:49:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Nov 2003 01:49:49 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:63900 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225397AbTKSBth>;
	Wed, 19 Nov 2003 01:49:37 +0000
Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian))
	id 1AMHTG-0001Ft-1z; Tue, 18 Nov 2003 20:49:30 -0500
Date: Tue, 18 Nov 2003 20:49:29 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: David Daney <ddaney@avtrex.com>
Cc: linux-mips@linux-mips.org
Subject: Re: How reliable is GCC-3.3.1 wrt building mipsel-linux kernel?
Message-ID: <20031119014929.GA4811@nevyn.them.org>
References: <3FBACA0F.7070207@avtrex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3FBACA0F.7070207@avtrex.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: 3642
X-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: 1218
Lines: 31

On Tue, Nov 18, 2003 at 05:40:31PM -0800, David Daney wrote:
> The subject line kind of says it all.
> 
> We are running linux 2.4.18 on a mips4Kc core (ATI Xilleon 225) and find 
> it to be quite stable when compiled with gcc 2.96/binutils 2.11.92.0.10
> 
> When the kernel is compiled with gcc 3.3.1/binutils 2.14.90.0.5 it also 
> seems to be quite stable, except for when one certian driver is used 
> (basically an mpeg decoder driver).  Under certian conditions the system 
> seems to "freeze" (no messages printed anywhere and only a hard reset 
> will recover).
> 
> Yeah that is a good bug report...
> 
> But my main question is this:  Have other people experienced 
> miscompilation (ie bad code generation) with gcc 3.3.1?
> 
> One thing I am aware of is that if -fno-common is not used, bad code is 
> generated for accessing some large structures.  But I we use -fno-common 
> for all compilation.
> 
> I am trying to figrue out if I should be looking more at bugs in the 
> driver, or if I should give up on gcc 3.3.1 and be done with it.
> 
> Thanks in advance for any insight.

We haven't had problems here.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ralf@linux-mips.org Wed Nov 19 23:30:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Nov 2003 23:30:43 +0000 (GMT)
Received: from p508B60B3.dip.t-dialin.net ([IPv6:::ffff:80.139.96.179]:8882
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225199AbTKSXab>; Wed, 19 Nov 2003 23:30:31 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAJNUPA0008094;
	Thu, 20 Nov 2003 00:30:25 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAJNUOhC008093;
	Thu, 20 Nov 2003 00:30:24 +0100
Date: Thu, 20 Nov 2003 00:30:23 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: David Daney <ddaney@avtrex.com>
Cc: linux-mips@linux-mips.org
Subject: Re: How reliable is GCC-3.3.1 wrt building mipsel-linux kernel?
Message-ID: <20031119233023.GA30962@linux-mips.org>
References: <3FBACA0F.7070207@avtrex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3FBACA0F.7070207@avtrex.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3643
X-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: 844
Lines: 22

On Tue, Nov 18, 2003 at 05:40:31PM -0800, David Daney wrote:

> The subject line kind of says it all.
> 
> We are running linux 2.4.18 on a mips4Kc core (ATI Xilleon 225) and find 
> it to be quite stable when compiled with gcc 2.96/binutils 2.11.92.0.10
> 
> When the kernel is compiled with gcc 3.3.1/binutils 2.14.90.0.5 it also 
> seems to be quite stable, except for when one certian driver is used 
> (basically an mpeg decoder driver).  Under certian conditions the system 
> seems to "freeze" (no messages printed anywhere and only a hard reset 
> will recover).
> 
> Yeah that is a good bug report...
> 
> But my main question is this:  Have other people experienced 
> miscompilation (ie bad code generation) with gcc 3.3.1?

Quite frequently using a new, possibly more agressive compiler triggers
bugs in the kernel code ...

  Ralf

From ddaney@avtrex.com Thu Nov 20 00:29:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Nov 2003 00:29:58 +0000 (GMT)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:20889 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225354AbTKTA3q>;
	Thu, 20 Nov 2003 00:29:46 +0000
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 19 Nov 2003 16:29:44 -0800
Message-ID: <3FBC0AF7.90600@avtrex.com>
Date: Wed, 19 Nov 2003 16:29:43 -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: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Subject: Re: How reliable is GCC-3.3.1 wrt building mipsel-linux kernel?
References: <3FBACA0F.7070207@avtrex.com> <20031119233023.GA30962@linux-mips.org>
In-Reply-To: <20031119233023.GA30962@linux-mips.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2003 00:29:44.0132 (UTC) FILETIME=[65057040:01C3AEFD]
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: 3644
X-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: 475
Lines: 23

Ralf Baechle wrote:

>On Tue, Nov 18, 2003 at 05:40:31PM -0800, David Daney wrote:
>  
>
>><...>
>>But my main question is this:  Have other people experienced 
>>miscompilation (ie bad code generation) with gcc 3.3.1?
>>    
>>
>
>Quite frequently using a new, possibly more agressive compiler triggers
>bugs in the kernel code ...
>
>  Ralf
>  
>
That's the whole point of my question.

Which options have other people used with gcc 3.3.1 with good results?

David Daney.


From anemo@mba.ocn.ne.jp Thu Nov 20 01:13:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Nov 2003 01:13:46 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:28705
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225374AbTKTBNO>; Thu, 20 Nov 2003 01:13: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; 20 Nov 2003 01:13:41 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id hAK1DS9X099294;
	Thu, 20 Nov 2003 10:13:31 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 20 Nov 2003 10:16:11 +0900 (JST)
Message-Id: <20031120.101611.112629972.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, sjhill@realitydiluted.com
Subject: rtc_ds1742_wait
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: 3645
X-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: 640
Lines: 20

The rtc_ds1742_wait() waits beginning of a next ODD second, though
users of this function expect that it will wait beginning of a next
second.  Here is a patch.

diff -u drivers/char/ds1742.c.org drivers/char/ds1742.c
--- drivers/char/ds1742.c.org	Tue Nov  4 16:57:38 2003
+++ drivers/char/ds1742.c	Thu Nov 20 10:06:05 2003
@@ -251,8 +251,8 @@
 
 void rtc_ds1742_wait(void)
 {
-	while (CMOS_READ(RTC_SECONDS) & 1);
-	while (!(CMOS_READ(RTC_SECONDS) & 1));
+	unsigned char sec = CMOS_READ(RTC_SECONDS);
+	while (!((sec ^ CMOS_READ(RTC_SECONDS)) & 1));
 }
 
 static int ds1742_ioctl(struct inode *inode, struct file *file,
---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Thu Nov 20 07:47:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Nov 2003 07:48:01 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:63763
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225541AbTKTHr2>; Thu, 20 Nov 2003 07:47:28 +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; 20 Nov 2003 07:47:53 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id hAK7ljnd000782;
	Thu, 20 Nov 2003 16:47:46 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 20 Nov 2003 16:50:28 +0900 (JST)
Message-Id: <20031120.165028.59648656.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: frame_info_init in 2.6 kernel
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 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: 3646
X-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: 1940
Lines: 55

I suppose everybody running 2.6 mips kernel see this error message:

> Can't analyze prologue code at XXXXXXXX

XXXXXXXX is an address of schedule_timeout function.

This is because schedule_timeout was moved to timer.c from sched.c and
therefore compiled without -fno-omit-frame-pointer.

If the error is detected, get_wchan does not work so the "ps lw"
command can not print WCHAN field correctly.

How about this patch?

--- arch/mips/kernel/process.c.org	Thu Nov 20 16:34:45 2003
+++ arch/mips/kernel/process.c	Thu Nov 20 16:38:39 2003
@@ -251,12 +251,20 @@
 
 static int __init frame_info_init(void)
 {
-	mips_frame_info_initialized =
-		!get_frame_info(&schedule_frame, schedule) &&
-		!get_frame_info(&schedule_timeout_frame, schedule_timeout) &&
-		!get_frame_info(&sleep_on_frame, sleep_on) &&
-		!get_frame_info(&sleep_on_timeout_frame, sleep_on_timeout) &&
-		!get_frame_info(&wait_for_completion_frame, wait_for_completion);
+	/* in 2.6 kernel, schedule_timout is out of [first_sched,last_sched] */
+	if ((unsigned long)schedule_timeout < first_sched ||
+	    (unsigned long)schedule_timeout >= last_sched)
+		mips_frame_info_initialized =
+			!get_frame_info(&schedule_frame, schedule) &&
+			!get_frame_info(&sleep_on_frame, sleep_on) &&
+			!get_frame_info(&wait_for_completion_frame, wait_for_completion);
+	else
+		mips_frame_info_initialized =
+			!get_frame_info(&schedule_frame, schedule) &&
+			!get_frame_info(&schedule_timeout_frame, schedule_timeout) &&
+			!get_frame_info(&sleep_on_frame, sleep_on) &&
+			!get_frame_info(&sleep_on_timeout_frame, sleep_on_timeout) &&
+			!get_frame_info(&wait_for_completion_frame, wait_for_completion);
 
 	return 0;
 }
@@ -323,6 +331,9 @@
 	goto out;
 
 schedule_timeout_caller:
+	if ((unsigned long)schedule_timeout < first_sched ||
+	    (unsigned long)schedule_timeout >= last_sched)
+		return pc;	/* failsafe */
 	/*
 	 * The schedule_timeout frame
 	 */
---
Atsushi Nemoto

From Colin.Helliwell@Zarlink.Com Thu Nov 20 09:10:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Nov 2003 09:11:26 +0000 (GMT)
Received: from semigate.zarlink.com ([IPv6:::ffff:209.226.172.94]:48565 "EHLO
	semigate.zarlink.com") by linux-mips.org with ESMTP
	id <S8225541AbTKTJKx>; Thu, 20 Nov 2003 09:10:53 +0000
Received: from ottmta01.zarlink.com (ottmta01 [134.199.14.110])
	by semigate.zarlink.com (8.11.6+Sun/8.10.2) with ESMTP id hAK9Ako27332
	for <linux-mips@linux-mips.org>; Thu, 20 Nov 2003 04:10:46 -0500 (EST)
Subject: Compressed kernels
To: linux-mips@linux-mips.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF86946D75.0D269E58-ON80256DE4.0031F58D@zarlink.com>
From: Colin.Helliwell@Zarlink.Com
Date: Thu, 20 Nov 2003 09:10:41 +0000
X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.12  |February 13, 2003) at
 11/20/2003 04:10:46 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
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: 3647
X-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: 207
Lines: 8

I'm running a 2.4.21 kernel tree, and would like to have kernel
compression. I wondered if this has gone back into the latest versions yet?
Or is the old EV64120 code worth adapting to my needs?

Thanks.




From jbglaw@dvmwest.gt.owl.de Thu Nov 20 09:25:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Nov 2003 09:26:00 +0000 (GMT)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:14819 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225541AbTKTJZs>; Thu, 20 Nov 2003 09:25:48 +0000
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 44BA04B46C; Thu, 20 Nov 2003 10:25:44 +0100 (CET)
Date: Thu, 20 Nov 2003 10:25:43 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: How reliable is GCC-3.3.1 wrt building mipsel-linux kernel?
Message-ID: <20031120092543.GH1037@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <3FBACA0F.7070207@avtrex.com> <20031119233023.GA30962@linux-mips.org> <3FBC0AF7.90600@avtrex.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="cjXvCArabh/jFWdZ"
Content-Disposition: inline
In-Reply-To: <3FBC0AF7.90600@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: 3648
X-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: 1538
Lines: 46


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

On Wed, 2003-11-19 16:29:43 -0800, David Daney <ddaney@avtrex.com>
wrote in message <3FBC0AF7.90600@avtrex.com>:
> Ralf Baechle wrote:
> >On Tue, Nov 18, 2003 at 05:40:31PM -0800, David Daney wrote:

> Which options have other people used with gcc 3.3.1 with good results?

It's a question of what you call "good results". If there are bugs in
the kernel sources which only show up with a really aggressive HEAD
compiler, then IMHO it's a good result to see the compiled kernel crash,
just because there actually *is* a bug.

Companies however tend to accept a slower/more bloated/whatever software
(produced by an older compiler) in order not to start hunting down the
remaining (and possibly hard to find) bugs...

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));

--cjXvCArabh/jFWdZ
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/vIiXHb1edYOZ4bsRAhWFAJoDReLOswoENweswqijTl7qASjt6wCgkfXA
+4Yo1RZ7uQISG/L/vxPGQA0=
=wwMt
-----END PGP SIGNATURE-----

--cjXvCArabh/jFWdZ--

From dan@embeddededge.com Thu Nov 20 15:18:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Nov 2003 15:18:50 +0000 (GMT)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:7296 "EHLO
	tibook.netx4.com") by linux-mips.org with ESMTP id <S8225321AbTKTPSj>;
	Thu, 20 Nov 2003 15:18:39 +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 hAKFLRt00738;
	Thu, 20 Nov 2003 10:21:27 -0500
Message-ID: <3FBCDBF7.7000307@embeddededge.com>
Date: Thu, 20 Nov 2003 10:21:27 -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: Colin.Helliwell@Zarlink.Com
CC: linux-mips@linux-mips.org
Subject: Re: Compressed kernels
References: <OF86946D75.0D269E58-ON80256DE4.0031F58D@zarlink.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: 3649
X-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: 569
Lines: 18

Colin.Helliwell@Zarlink.Com wrote:

> I'm running a 2.4.21 kernel tree, and would like to have kernel
> compression. I wondered if this has gone back into the latest versions yet?

If you apply the 'zImage' patch from Pete's ftp directory (look in past
e-mails for this discussion) you will see what I have done for a few of
the boards I'm using.  It's quite trivial to add new boards to get
this feature.  I'm still working on the method of attaching the
compressed initrd to the same image, which I find quite useful for
embedded applications.

Have fun!


	-- Dan



From ralf@linux-mips.org Thu Nov 20 21:03:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Nov 2003 21:03:21 +0000 (GMT)
Received: from p508B56E7.dip.t-dialin.net ([IPv6:::ffff:80.139.86.231]:14477
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225320AbTKTVDK>; Thu, 20 Nov 2003 21:03:10 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAKL33A0003787;
	Thu, 20 Nov 2003 22:03:03 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAKL2v4F003780;
	Thu, 20 Nov 2003 22:02:57 +0100
Date: Thu, 20 Nov 2003 22:02:57 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Dan Malek <dan@embeddededge.com>
Cc: Colin.Helliwell@Zarlink.Com, linux-mips@linux-mips.org
Subject: Re: Compressed kernels
Message-ID: <20031120210257.GA758@linux-mips.org>
References: <OF86946D75.0D269E58-ON80256DE4.0031F58D@zarlink.com> <3FBCDBF7.7000307@embeddededge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3FBCDBF7.7000307@embeddededge.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: 3650
X-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: 1099
Lines: 26

On Thu, Nov 20, 2003 at 10:21:27AM -0500, Dan Malek wrote:
> Date: Thu, 20 Nov 2003 10:21:27 -0500
> From: Dan Malek <dan@embeddededge.com>
> To: Colin.Helliwell@Zarlink.Com
> CC: linux-mips@linux-mips.org
> Subject: Re: Compressed kernels
> Content-Type: text/plain; charset=us-ascii; format=flowed
> 
> Colin.Helliwell@Zarlink.Com wrote:
> 
> >I'm running a 2.4.21 kernel tree, and would like to have kernel
> >compression. I wondered if this has gone back into the latest versions yet?
> 
> If you apply the 'zImage' patch from Pete's ftp directory (look in past
> e-mails for this discussion) you will see what I have done for a few of
> the boards I'm using.  It's quite trivial to add new boards to get
> this feature.  I'm still working on the method of attaching the
> compressed initrd to the same image, which I find quite useful for
> embedded applications.

Compressed kernels seem to be fairly high on everybody's list.  Due to
size limits of some boatloaders and flash memory being always too small
and too expensive I guess there would also be some interest in bzip2
support.

  Ralf

From dan@embeddededge.com Thu Nov 20 21:39:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Nov 2003 21:39:27 +0000 (GMT)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:25472 "EHLO
	tibook.netx4.com") by linux-mips.org with ESMTP id <S8225320AbTKTVjP>;
	Thu, 20 Nov 2003 21:39:15 +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 hAKLg7t00974;
	Thu, 20 Nov 2003 16:42:07 -0500
Message-ID: <3FBD352F.6020103@embeddededge.com>
Date: Thu, 20 Nov 2003 16:42:07 -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: Ralf Baechle <ralf@linux-mips.org>
CC: Colin.Helliwell@Zarlink.Com, linux-mips@linux-mips.org
Subject: Re: Compressed kernels
References: <OF86946D75.0D269E58-ON80256DE4.0031F58D@zarlink.com> <3FBCDBF7.7000307@embeddededge.com> <20031120210257.GA758@linux-mips.org>
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: 3651
X-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: 1103
Lines: 27

Ralf Baechle wrote:

> Compressed kernels seem to be fairly high on everybody's list.  Due to
> size limits of some boatloaders and flash memory being always too small
> and too expensive I guess there would also be some interest in bzip2
> support.

Interesting thought.  I compressed the binary image using bzip2 instead
of gzip, found it was only about 7% smaller (approximately 60K bytes).
To this, we have to add the trade off that the kernel already contains
too many versions of a readily available zlib, and the attached initrd
is also a gzip file.  Five years ago we used to be concerned about a
few bytes here and there, which prompted the interest in compressed
kernels, but today the embedded systems I'm working with have lots of
flash memory.  It seems product development cost to add a little more
flash is winning over spending the engineering time to squeeze those
last few bytes.

I don't think I'll spend my time doing it, but the process of creating
the compressed image and the calls to the uncompress functions are very
clear if someone else wants to do it :-)

Thanks.


	-- Dan


From wd@denx.de Thu Nov 20 22:34:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Nov 2003 22:34:36 +0000 (GMT)
Received: from mailout04.sul.t-online.com ([IPv6:::ffff:194.25.134.18]:22729
	"EHLO mailout04.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225320AbTKTWeE>; Thu, 20 Nov 2003 22:34:04 +0000
Received: from fwd05.aul.t-online.de 
	by mailout04.sul.t-online.com with smtp 
	id 1AMxN3-00015H-01; Thu, 20 Nov 2003 23:33:53 +0100
Received: from denx.de (E2tQDaZAZe9fDI9msO0tGD7od4PmCBGXVPHE3CeMAZpZEOlMPslIEH@[217.235.221.72]) by fmrl05.sul.t-online.com
	with esmtp id 1AMxMp-1PNhZY0; Thu, 20 Nov 2003 23:33:39 +0100
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 03CE742D86; Thu, 20 Nov 2003 23:33:36 +0100 (MET)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 03BFFC5F5F; Thu, 20 Nov 2003 23:33:35 +0100 (MET)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 0085BC5F5E; Thu, 20 Nov 2003 23:33:35 +0100 (MET)
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dan Malek <dan@embeddededge.com>, Colin.Helliwell@Zarlink.Com,
	linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: Compressed kernels 
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, 20 Nov 2003 22:02:57 +0100."
             <20031120210257.GA758@linux-mips.org> 
Date: Thu, 20 Nov 2003 23:33:30 +0100
Message-Id: <20031120223335.03BFFC5F5F@atlas.denx.de>
X-Seen: false
X-ID: E2tQDaZAZe9fDI9msO0tGD7od4PmCBGXVPHE3CeMAZpZEOlMPslIEH@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: 3652
X-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: 780
Lines: 20

In message <20031120210257.GA758@linux-mips.org> you wrote:
>
> Compressed kernels seem to be fairly high on everybody's list.  Due to
> size limits of some boatloaders and flash memory being always too small
> and too expensive I guess there would also be some interest in bzip2
> support.

Well, instead of doing this in the Linux kernel, you could also do
it in the boot loader.  U-Boot supports both gzip and bzip2 decom-
pression.


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
                       - L. Wall & R. L. Schwartz, _Programming Perl_

From dan@embeddededge.com Thu Nov 20 22:47:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Nov 2003 22:47:39 +0000 (GMT)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:33408 "EHLO
	tibook.netx4.com") by linux-mips.org with ESMTP id <S8225320AbTKTWr1>;
	Thu, 20 Nov 2003 22:47:27 +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 hAKMoHt01035;
	Thu, 20 Nov 2003 17:50:17 -0500
Message-ID: <3FBD4529.3070201@embeddededge.com>
Date: Thu, 20 Nov 2003 17:50:17 -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: Wolfgang Denk <wd@denx.de>
CC: Ralf Baechle <ralf@linux-mips.org>, Colin.Helliwell@Zarlink.Com,
	linux-mips@linux-mips.org
Subject: Re: Compressed kernels
References: <20031120223335.03BFFC5F5F@atlas.denx.de>
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: 3653
X-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: 554
Lines: 16

Wolfgang Denk wrote:

> Well, instead of doing this in the Linux kernel, you could also do
> it in the boot loader.  U-Boot supports both gzip and bzip2 decom-
> pression.

Just to keep us busy, there are people that chose options
other than u-boot :-)  For embedded systems that are really sensitive
to boot time and amount of flash used, they may only have minimal
instructions for processor initialization and then jump to the
compressed kernel image.  I'm not going to discuss boot roms any
further (yes, I use u-boot every chance I get).


	-- Dan


From macro@ds2.pg.gda.pl Fri Nov 21 17:33:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Nov 2003 17:33:55 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:23267 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225418AbTKURdn>; Fri, 21 Nov 2003 17:33:43 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id A4CCB49BFE; Fri, 21 Nov 2003 18:33:37 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 9334347485; Fri, 21 Nov 2003 18:33:37 +0100 (CET)
Date: Fri, 21 Nov 2003 18:33:37 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: [patch] 2.4, head: PAGE_SHIFT changes break glibc
Message-ID: <Pine.LNX.4.55.0311211550270.32551@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: 3654
X-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: 2535
Lines: 71

Ralf,

 Recent changes made to <asm/page.h> break a build of glibc 2.2.5 for me.  
Compilation bails out due to PAGE_SHIFT being undeclared -- glibc pulls it
as it uses PAGE_SIZE in linuxthreads/internals.h.  The PAGE_SHIFT macro
depends on configuration now (I use an empty cofinguration for glibc
headers, hence the error) and thus it'd better be simply private to the
kernel.  Glibc will then use sysconf(_SC_PAGE_SIZE) which now better
reflects actual configuration of the system it's run on.

 Here's a patch that limits PAGE_SIZE to the kernel scope.  If there's any
other program that needs PAGE_SIZE, it should be converted to
sysconf(_SC_PAGE_SIZE) as well.

 OK to apply?

 Additionally, I think we should also implement the getpagesize syscall to
benefit statically linked programs (and make glibc use it like for other
platforms that use variable page sizes).  Finally, I'm not sure such a
noticeable change was a good move in these late days of 2.4...

  Maciej

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

linux-include-mips-2.4.22-20031115-mips-page_size.patch
diff -up --recursive --new-file linux-include-mips-2.4.22-20031115.macro/include/asm-mips/page.h linux-include-mips-2.4.22-20031115/include/asm-mips/page.h
--- linux-include-mips-2.4.22-20031115.macro/include/asm-mips/page.h	2003-10-17 02:57:33.000000000 +0000
+++ linux-include-mips-2.4.22-20031115/include/asm-mips/page.h	2003-11-21 09:29:52.000000000 +0000
@@ -12,6 +12,8 @@
 
 #include <linux/config.h>
 
+#ifdef __KERNEL__
+
 /*
  * PAGE_SHIFT determines the page size
  */
@@ -27,8 +29,6 @@
 #define PAGE_SIZE	(1L << PAGE_SHIFT)
 #define PAGE_MASK	(~(PAGE_SIZE-1))
 
-#ifdef __KERNEL__
-
 #ifndef __ASSEMBLY__
 
 #include <asm/cacheflush.h>
diff -up --recursive --new-file linux-include-mips-2.4.22-20031115.macro/include/asm-mips64/page.h linux-include-mips-2.4.22-20031115/include/asm-mips64/page.h
--- linux-include-mips-2.4.22-20031115.macro/include/asm-mips64/page.h	2003-10-17 02:57:34.000000000 +0000
+++ linux-include-mips-2.4.22-20031115/include/asm-mips64/page.h	2003-11-21 09:30:10.000000000 +0000
@@ -11,6 +11,8 @@
 
 #include <linux/config.h>
 
+#ifdef __KERNEL__
+
 /*
  * PAGE_SHIFT determines the page size
  */
@@ -26,8 +28,6 @@
 #define PAGE_SIZE	(1UL << PAGE_SHIFT)
 #define PAGE_MASK	(~(PAGE_SIZE-1))
 
-#ifdef __KERNEL__
-
 #ifndef __ASSEMBLY__
 
 #include <asm/cacheflush.h>

From ralf@linux-mips.org Fri Nov 21 18:56:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Nov 2003 18:56:37 +0000 (GMT)
Received: from p508B5C7D.dip.t-dialin.net ([IPv6:::ffff:80.139.92.125]:38359
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225330AbTKUS4Z>; Fri, 21 Nov 2003 18:56:25 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hALIoZA0029125;
	Fri, 21 Nov 2003 19:50:35 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hALIoZpp029124;
	Fri, 21 Nov 2003 19:50:35 +0100
Date: Fri, 21 Nov 2003 19:50:35 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] 2.4, head: PAGE_SHIFT changes break glibc
Message-ID: <20031121185035.GC8318@linux-mips.org>
References: <Pine.LNX.4.55.0311211550270.32551@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0311211550270.32551@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3655
X-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: 2145
Lines: 46

On Fri, Nov 21, 2003 at 06:33:37PM +0100, Maciej W. Rozycki wrote:

>  Recent changes made to <asm/page.h> break a build of glibc 2.2.5 for me.  
> Compilation bails out due to PAGE_SHIFT being undeclared -- glibc pulls it
> as it uses PAGE_SIZE in linuxthreads/internals.h.  The PAGE_SHIFT macro
> depends on configuration now (I use an empty cofinguration for glibc
> headers, hence the error) and thus it'd better be simply private to the
> kernel.  Glibc will then use sysconf(_SC_PAGE_SIZE) which now better
> reflects actual configuration of the system it's run on.

Interesting.  IA-64 does the same thing, for example.  Wonder why they
seem to be able to get away with that.  At the very least including the
kernel header file may pick up a wrong value for PAGE_SHIFT.

>  Here's a patch that limits PAGE_SIZE to the kernel scope.  If there's any
> other program that needs PAGE_SIZE, it should be converted to
> sysconf(_SC_PAGE_SIZE) as well.
> 
>  OK to apply?

Yes, please go ahead.

>  Additionally, I think we should also implement the getpagesize syscall to
> benefit statically linked programs (and make glibc use it like for other
> platforms that use variable page sizes).

The kernel is already passing AT_PAGESZ to ELF binaries.  Wouldn't that
be sufficient?  Currently it's passing the largest supported page size,
that is 64k.  However this constant is always passed even when a smaller
page size is configured.

>  Finally, I'm not sure such a
> noticeable change was a good move in these late days of 2.4...

TLB reloads have been shown to be a major performance problem; this is an
not yet completed attempt to improve the situation so people don't need
to go for crude hacks such as wired TLB entires and similar.

Other parts of improvments such as hugetlbfs are available in 2.6 only
anyway.  I'm also thinking of changing the pagetable structure back to
the aggressivly optmized thing we were using before Linux 2.0.14 - but
certainly not for 2.4 - too intrusive, as you say.  With most MIPS users
being embedded users I still expect 2.4 to live for quite a while -
certainly longer than I'd like to see ...

  Ralf

From macro@ds2.pg.gda.pl Fri Nov 21 20:08:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Nov 2003 20:08:16 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:13477 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225330AbTKUUIE>; Fri, 21 Nov 2003 20:08:04 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id A593C49BFE; Fri, 21 Nov 2003 21:07:58 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 94B7A46A83; Fri, 21 Nov 2003 21:07:58 +0100 (CET)
Date: Fri, 21 Nov 2003 21:07:58 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] 2.4, head: PAGE_SHIFT changes break glibc
In-Reply-To: <20031121185035.GC8318@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0311212021420.32551@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0311211550270.32551@jurand.ds.pg.gda.pl>
 <20031121185035.GC8318@linux-mips.org>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3656
X-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: 4531
Lines: 91

On Fri, 21 Nov 2003, Ralf Baechle wrote:

> >  Recent changes made to <asm/page.h> break a build of glibc 2.2.5 for me.  
> > Compilation bails out due to PAGE_SHIFT being undeclared -- glibc pulls it
> > as it uses PAGE_SIZE in linuxthreads/internals.h.  The PAGE_SHIFT macro
> > depends on configuration now (I use an empty cofinguration for glibc
> > headers, hence the error) and thus it'd better be simply private to the
> > kernel.  Glibc will then use sysconf(_SC_PAGE_SIZE) which now better
> > reflects actual configuration of the system it's run on.
> 
> Interesting.  IA-64 does the same thing, for example.  Wonder why they
> seem to be able to get away with that.  At the very least including the
> kernel header file may pick up a wrong value for PAGE_SHIFT.

 I think people (this may include distributors as well) build glibc with
Linux headers fully configured or, worse yet, with whatever happens to be
grabbed by gcc as <linux/...> and <asm/...> (i.e. usually headers from the
previous installation).  So in this case PAGE_SHIFT gets defined somehow,
although not necessarily reflecting what will be true for the host system.

 The question is which one is the *right* full configuration.  I think all
are valid, so none is the single right, so I chose not to define kernel
configuration macros for the userland -- the userland ABI shouldn't depend
on a particular kernel configuration.  I hope this issue will disappear
automatically once the kernel header space gets divided into an internal
part and one forming the ABI.

 If you look at my spec file for glibc, you'll see it only does:

echo "#define AUTOCONF_INCLUDED" > linux/include/linux/autoconf.h

to get kernel headers working.

> >  Additionally, I think we should also implement the getpagesize syscall to
> > benefit statically linked programs (and make glibc use it like for other
> > platforms that use variable page sizes).
> 
> The kernel is already passing AT_PAGESZ to ELF binaries.  Wouldn't that
> be sufficient?  Currently it's passing the largest supported page size,

 Well, AFAICS in glibc it's ld.so that is responsible for interpreting the
auxiliary vector -- see _dl_aux_init() in elf/dl-support.c.  If the
dynamic linker isn't run (which is the usual case for static binaries,
although calling dlopen() from them might complicate things), the
dl_pagesize variable remains set to zero.  Please prove me wrong if I am
missing anything.

> that is 64k.  However this constant is always passed even when a smaller
> page size is configured.

 Are you sure?  I can see create_elf_tables() in fs/binfmt_elf.c sets 
AT_PAGESZ to ELF_EXEC_PAGESIZE, which, in turn, is set in 
include/asm-mips/elf.h to PAGE_SIZE.  Which is the currently used page 
size and probably the optimal solution.

> >  Finally, I'm not sure such a
> > noticeable change was a good move in these late days of 2.4...
> 
> TLB reloads have been shown to be a major performance problem; this is an
> not yet completed attempt to improve the situation so people don't need
> to go for crude hacks such as wired TLB entires and similar.

 OK, but the safe (and practiced in the mainline) procedure is to test
with the development version and do a backport if necessary.  Well, it
might not work that well this time, as apparently I'm the only one to come
upon such oddities ;-) and, as you probably know, I haven't switched to
2.6, yet.

> Other parts of improvments such as hugetlbfs are available in 2.6 only
> anyway.  I'm also thinking of changing the pagetable structure back to
> the aggressivly optmized thing we were using before Linux 2.0.14 - but
> certainly not for 2.4 - too intrusive, as you say.  With most MIPS users
> being embedded users I still expect 2.4 to live for quite a while -
> certainly longer than I'd like to see ...

 As I wrote, such changes may get backported if there's a need and a
volunteer to do the task.  I won't support 2.4 for a long time, yet -- I
just want to upgrade the toolchain before I upgrade the kernel.  After
then I may only backport some DECstation driver fixes.

 BTW, can you imagine how huge gcc 3.4 is? -- for the i386 it needs 1GB of 
disk space and plenty of hours to be built on a reasonable system.  For 
MIPS I suppose the disk space needed will be yet larger and building may 
require a few days...

  Maciej

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

From ralf@linux-mips.org Sat Nov 22 02:41:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 22 Nov 2003 02:42:06 +0000 (GMT)
Received: from p508B5C7D.dip.t-dialin.net ([IPv6:::ffff:80.139.92.125]:62339
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225425AbTKVClz>; Sat, 22 Nov 2003 02:41:55 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAM2fiA0005458;
	Sat, 22 Nov 2003 03:41:44 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAM2fhks005457;
	Sat, 22 Nov 2003 03:41:43 +0100
Date: Sat, 22 Nov 2003 03:41:43 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Colin.Helliwell@Zarlink.Com
Cc: linux-mips@linux-mips.org
Subject: Re: Compressed kernels
Message-ID: <20031122024143.GA25296@linux-mips.org>
References: <OF86946D75.0D269E58-ON80256DE4.0031F58D@zarlink.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OF86946D75.0D269E58-ON80256DE4.0031F58D@zarlink.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: 3657
X-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: 419
Lines: 10

On Thu, Nov 20, 2003 at 09:10:41AM +0000, Colin.Helliwell@Zarlink.Com wrote:

> I'm running a 2.4.21 kernel tree, and would like to have kernel
> compression. I wondered if this has gone back into the latest versions yet?
> Or is the old EV64120 code worth adapting to my needs?

The old code apparently was functioning but replicating code from zlib and
generally was carrying half a firmware as it's baggage.

  Ralf

From jrc@skylon.demon.co.uk Sat Nov 22 17:54:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 22 Nov 2003 17:55:24 +0000 (GMT)
Received: from anchor-post-34.mail.demon.net ([IPv6:::ffff:194.217.242.92]:35596
	"EHLO anchor-post-34.mail.demon.net") by linux-mips.org with ESMTP
	id <S8225428AbTKVRyv>; Sat, 22 Nov 2003 17:54:51 +0000
Received: from skylon.demon.co.uk ([158.152.3.173])
	by anchor-post-34.mail.demon.net with esmtp (Exim 3.35 #1)
	id 1ANby5-000KTU-0Y
	for linux-mips@linux-mips.org; Sat, 22 Nov 2003 17:54:49 +0000
Received: from skylon.demon.co.uk (skylon.demon.co.uk [158.152.3.173]) by skylon.demon.co.uk (8.8.7/UW7.0.1) with ESMTP id QAA10882; Sat, 22 Nov 2003 16:56:59 GMT
Message-ID: <3FBF955A.5C2CC00C@skylon.demon.co.uk>
Date: Sat, 22 Nov 2003 16:56:58 +0000
From: John Connett <jrc@skylon.demon.co.uk>
X-Mailer: Mozilla 4.04 [en] (X11; I; UnixWare 5 i386)
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: MIPS64 + HyperTransport + nForce3?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <jrc@skylon.demon.co.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3658
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jrc@skylon.demon.co.uk
Precedence: bulk
X-list: linux-mips
Content-Length: 822
Lines: 16

There are now a number of MIPS64 processor chips with HyperTransport
support.  NVIDIA produce a range of nForce3 system controller chips
which also use HyperTransport.  Does anyone produce a board that
combines the two and, to make my question relevant to this list, runs
Linux?

The low power requirements of the MIPS64 processors would make them an
ideal choice for small form factor boards such as those used in the
Shuttle XPC systems.  The recent Shuttle SN85G4 combines an AMD
Athlon64 and an nForce3 150.  This supports a good selection of
on-board peripherals together with 1 x AGP 8X/4X slot and 1 x PCI
slot.  Something similar using a single or dual MIPS64 processor chip
would make an attractive desktop system.  For the power crazy, a board
with the quad processor BCM-1400 should suffice ...
--
John Connett

From sjhill@realitydiluted.com Mon Nov 24 13:00:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Nov 2003 13:00:40 +0000 (GMT)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:48345
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8224985AbTKXNA3>; Mon, 24 Nov 2003 13:00:29 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1AOGKF-0000ZW-00
	for <linux-mips@linux-mips.org>; Mon, 24 Nov 2003 07:00:23 -0600
Message-ID: <3FC200DF.8000804@realitydiluted.com>
Date: Mon, 24 Nov 2003 08:00:15 -0500
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Kernel interface for MIPS timers....
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: 3659
X-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: 729
Lines: 17

Hello.

This could be an embarassing question, but I seem to be good at
asking those anyway. A lot more MIPS processors lately seem to
come with multiple timers. In addition to the main HPT timer on
R4K variants and above, usually there are 2 or 3 additional 16
or 32-bit timers with prescalars and other features. Some drivers
may decide to use one of these timers exclusively and I am sure
there are many other uses as well. There does not seem to be any
type of API or reservation system to cleanly utilize the timers
present in the system. Actually, on a lot of my boards the added
timers do not get any usage, but perhaps that could change. Has
anyone given thought to this, or does it just seem pointless?
Thanks.

-Steve


From jbglaw@dvmwest.gt.owl.de Mon Nov 24 15:23:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Nov 2003 15:23:19 +0000 (GMT)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:24994 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225433AbTKXPXI>; Mon, 24 Nov 2003 15:23:08 +0000
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 0F8574B47E; Mon, 24 Nov 2003 16:23:06 +0100 (CET)
Date: Mon, 24 Nov 2003 16:23:05 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20031124152305.GZ1037@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20031124151816Z8225418-16706+435@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="PXAMHHr3Crq3TzKX"
Content-Disposition: inline
In-Reply-To: <20031124151816Z8225418-16706+435@linux-mips.org>
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: 3660
X-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: 1050
Lines: 39


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

On Mon, 2003-11-24 15:18:11 +0000, ralf@linux-mips.org <ralf@linux-mips.org>
wrote in message <20031124151816Z8225418-16706+435@linux-mips.org>:

> Log message:
> 	Merge with Linux "Stoned Beaver" 2.6.0-test10.
>=20

Jehova!

Hiding, 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));

--PXAMHHr3Crq3TzKX
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/wiJZHb1edYOZ4bsRAuChAJwIHJgpy8UawAGD92N4dMbXRseNIACaA15L
WGdUAUN+KS6H5ZHM2lrtryg=
=FkOE
-----END PGP SIGNATURE-----

--PXAMHHr3Crq3TzKX--

From jsun@mvista.com Mon Nov 24 18:31:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 Nov 2003 18:31:18 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:29943 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225370AbTKXSbG>;
	Mon, 24 Nov 2003 18:31:06 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id hAOIV1923470;
	Mon, 24 Nov 2003 10:31:01 -0800
Date: Mon, 24 Nov 2003 10:31:01 -0800
From: Jun Sun <jsun@mvista.com>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Kernel interface for MIPS timers....
Message-ID: <20031124103101.I14650@mvista.com>
References: <3FC200DF.8000804@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: <3FC200DF.8000804@realitydiluted.com>; from sjhill@realitydiluted.com on Mon, Nov 24, 2003 at 08:00:15AM -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: 3661
X-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: 1705
Lines: 37

On Mon, Nov 24, 2003 at 08:00:15AM -0500, Steven J. Hill wrote:
> Hello.
> 
> This could be an embarassing question, but I seem to be good at
> asking those anyway. A lot more MIPS processors lately seem to
> come with multiple timers. In addition to the main HPT timer on
> R4K variants and above, usually there are 2 or 3 additional 16
> or 32-bit timers with prescalars and other features. Some drivers
> may decide to use one of these timers exclusively and I am sure
> there are many other uses as well. There does not seem to be any
> type of API or reservation system to cleanly utilize the timers
> present in the system. Actually, on a lot of my boards the added
> timers do not get any usage, but perhaps that could change. Has
> anyone given thought to this, or does it just seem pointless?

I afraid it might be later. :)

Kernel needs one timer, i.e., the system or jiffy timer.  All
other time or timer services are provided based on it.

Individual drivers or application may use the other timers, but
that does not mean kernel needs to explicitly manage them.

Given that said, Monta Vista recently has implemented high resolution
posix timer, in which case we do abstract out two system timers,
one for jiffy, and other is for high resolution stuff.  (Individual
board, however, is free to multiplex the same hw timer for both 
purposes in its implementation)

Personally I don't think this approach is perfect.  The ultimate right 
solution is to have a single high resolution timer interface native to
the kernel, and we emulate jiffy timer on top to provide continuing support
for existing (or legacy) jiffy timer services.

This is something which should be interesting for 2.7.

Jun

From macro@ds2.pg.gda.pl Tue Nov 25 15:27:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Nov 2003 15:28:10 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:33719 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225521AbTKYP16>; Tue, 25 Nov 2003 15:27:58 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id DA5BA47B41; Tue, 25 Nov 2003 16:27:49 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id CC1B647607; Tue, 25 Nov 2003 16:27:49 +0100 (CET)
Date: Tue, 25 Nov 2003 16:27:49 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] 2.4, head: PAGE_SHIFT changes break glibc
In-Reply-To: <Pine.LNX.4.55.0311212021420.32551@jurand.ds.pg.gda.pl>
Message-ID: <Pine.LNX.4.55.0311251623180.6716@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0311211550270.32551@jurand.ds.pg.gda.pl>
 <20031121185035.GC8318@linux-mips.org> <Pine.LNX.4.55.0311212021420.32551@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: 3665
X-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: 1427
Lines: 39

On Fri, 21 Nov 2003, Maciej W. Rozycki wrote:

> > The kernel is already passing AT_PAGESZ to ELF binaries.  Wouldn't that
> > be sufficient?  Currently it's passing the largest supported page size,
> 
>  Well, AFAICS in glibc it's ld.so that is responsible for interpreting the
> auxiliary vector -- see _dl_aux_init() in elf/dl-support.c.  If the
> dynamic linker isn't run (which is the usual case for static binaries,
> although calling dlopen() from them might complicate things), the
> dl_pagesize variable remains set to zero.  Please prove me wrong if I am
> missing anything.
> 
> > that is 64k.  However this constant is always passed even when a smaller
> > page size is configured.
> 
>  Are you sure?  I can see create_elf_tables() in fs/binfmt_elf.c sets 
> AT_PAGESZ to ELF_EXEC_PAGESIZE, which, in turn, is set in 
> include/asm-mips/elf.h to PAGE_SIZE.  Which is the currently used page 
> size and probably the optimal solution.

 After rebuilding glibc (2.2.5) with the patch applied, the following
program:

#include <stdio.h>
#include <unistd.h>

int main(void)
{
	printf("%u\n", getpagesize());
	return 0;
}

prints "4096" if dynamically linked and "65536" if statically linked on my
system, as expected.

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

From pkapoor@telogy.com Tue Nov 25 21:53:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Nov 2003 21:53:12 +0000 (GMT)
Received: from [IPv6:::ffff:209.116.120.7] ([IPv6:::ffff:209.116.120.7]:40967
	"EHLO tnint11.telogy.design.ti.com") by linux-mips.org with ESMTP
	id <S8225197AbTKYVxA>; Tue, 25 Nov 2003 21:53:00 +0000
Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19)
	id <W5NHJGXP>; Tue, 25 Nov 2003 16:52:21 -0500
Message-ID: <37A3C2F21006D611995100B0D0F9B73C02C8FCAE@tnint11.telogy.design.ti.com>
From: "Kapoor, Pankaj" <pkapoor@telogy.com>
To: linux-mips@linux-mips.org
Subject: MIPS Interrupts.
Date: Tue, 25 Nov 2003 16:52:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <pkapoor@telogy.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3666
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pkapoor@telogy.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2097
Lines: 54

All,

While studying the implementation of tasklets and softirq processing I came 
across certain issues which I have outlined below. 

The function mipsIRQ in the file mipsIRQ.s is the registered interrupt 
handler for all general purpose interrupts. 

The first thing that the function does is that it saves all registers. It 
then checks the CAUSE register to check the source of the interrupt.
Currently 
all we are interested in is INT5 (Timer) and INT0 (i.e. all other devices) 

Consider a timer interrupt which would cause the code to jump to 0x8000:0180

and cause all the registers to be saved (SAVE_ALL). It would then jump to
the 
mips_timer_interrupt function in the file time.c 

The function services the timer interrupt. At the end of the function there 
is an irq_exit and a check to see if there are any SOFT IRQ pending. 
If there are any the function jumps to the do_softirq function defined in 
the softirq.c. The function gets the softirq pending list, enables
interrupts 
and cycles through all pending soft irq's calling the appropriate handlers. 

Remember that the interrupts are enabled while executing the various bottom 
half handlers. 

Now there are 2 cases that can happen 

1. Since we have not exited the ISR and the exception level has still not 
   been restored there can be no more interrupts that are generated in the 
   system. In such a case does that mean that the all bottom half handlers 
   pending execution will run with interrupts disabled. 
   NOTE: This does not seem likely because the local_irq_enable routine
calls 
   _sti which clears the exception level in the status register and also 
   sets the IE bit. 

2. If we have large number of tasklets or if the bottom half handlers take
time 
   to execute, then we could get another timer interrupt or other device 
   interrupts causing context saves which would cause the stack to grow and 
   CRASH the system. 
  
Context is restored only when the code returns from do_softirq and uses the 
ret_from_irq. 

Is there anything that I am missing in this whole picture ? 

Thanks.
- Pankaj 


From jsun@mvista.com Tue Nov 25 23:06:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Nov 2003 23:06:17 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:24571 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8226025AbTKYXGF>;
	Tue, 25 Nov 2003 23:06:05 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id hAPN62M32126;
	Tue, 25 Nov 2003 15:06:02 -0800
Date: Tue, 25 Nov 2003 15:06:02 -0800
From: Jun Sun <jsun@mvista.com>
To: "Kapoor, Pankaj" <pkapoor@telogy.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: MIPS Interrupts.
Message-ID: <20031125150602.E28822@mvista.com>
References: <37A3C2F21006D611995100B0D0F9B73C02C8FCAE@tnint11.telogy.design.ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <37A3C2F21006D611995100B0D0F9B73C02C8FCAE@tnint11.telogy.design.ti.com>; from pkapoor@telogy.com on Tue, Nov 25, 2003 at 04:52:20PM -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: 3667
X-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: 2445
Lines: 59

On Tue, Nov 25, 2003 at 04:52:20PM -0500, Kapoor, Pankaj wrote:
> All,
> 
> While studying the implementation of tasklets and softirq processing I came 
> across certain issues which I have outlined below. 
> 
> The function mipsIRQ in the file mipsIRQ.s is the registered interrupt 
> handler for all general purpose interrupts. 
> 
> The first thing that the function does is that it saves all registers. It 
> then checks the CAUSE register to check the source of the interrupt.
> Currently 
> all we are interested in is INT5 (Timer) and INT0 (i.e. all other devices) 
> 
> Consider a timer interrupt which would cause the code to jump to 0x8000:0180
> 
> and cause all the registers to be saved (SAVE_ALL). It would then jump to
> the 
> mips_timer_interrupt function in the file time.c 
> 
> The function services the timer interrupt. At the end of the function there 
> is an irq_exit and a check to see if there are any SOFT IRQ pending. 
> If there are any the function jumps to the do_softirq function defined in 
> the softirq.c. The function gets the softirq pending list, enables
> interrupts 
> and cycles through all pending soft irq's calling the appropriate handlers. 
> 
> Remember that the interrupts are enabled while executing the various bottom 
> half handlers. 
> 
> Now there are 2 cases that can happen 
> 
> 1. Since we have not exited the ISR and the exception level has still not 
>    been restored there can be no more interrupts that are generated in the 
>    system. In such a case does that mean that the all bottom half handlers 
>    pending execution will run with interrupts disabled. 
>    NOTE: This does not seem likely because the local_irq_enable routine
> calls 
>    _sti which clears the exception level in the status register and also 
>    sets the IE bit. 
>

Refer to your own note.  It is more correct.  :)
 
> 2. If we have large number of tasklets or if the bottom half handlers take
> time 
>    to execute, then we could get another timer interrupt or other device 
>    interrupts causing context saves which would cause the stack to grow and 
>    CRASH the system. 
>   
> Context is restored only when the code returns from do_softirq and uses the 
> ret_from_irq. 
> 

The nested interrupt call, do_IRQ(), may still try to call do_softirq() but
that it will return immediately as it discovers another instance of do_softirq()
is running.  No further nesting occurs as a result. 

Jun

From ralf@linux-mips.org Tue Nov 25 23:27:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Nov 2003 23:27:57 +0000 (GMT)
Received: from p508B60ED.dip.t-dialin.net ([IPv6:::ffff:80.139.96.237]:7131
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226025AbTKYX1p>; Tue, 25 Nov 2003 23:27:45 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAPNRhA0013143
	for <linux-mips@linux-mips.org>; Wed, 26 Nov 2003 00:27:43 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAPNRh4V013142
	for linux-mips@linux-mips.org; Wed, 26 Nov 2003 00:27:43 +0100
Resent-Message-Id: <200311252327.hAPNRh4V013142@dea.linux-mips.net>
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAPNLAA0012986
	for <linux-mips@linux-mips.org>; Wed, 26 Nov 2003 00:21:10 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAPN9kms012751;
	Wed, 26 Nov 2003 00:09:46 +0100
Date: Wed, 26 Nov 2003 00:09:46 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Kapoor, Pankaj" <pkapoor@telogy.com>
Cc: linux-mips@linux-mips.org
Subject: Re: MIPS Interrupts.
Message-ID: <20031125230946.GA12422@linux-mips.org>
References: <37A3C2F21006D611995100B0D0F9B73C02C8FCAE@tnint11.telogy.design.ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <37A3C2F21006D611995100B0D0F9B73C02C8FCAE@tnint11.telogy.design.ti.com>
User-Agent: Mutt/1.4.1i
Resent-From: ralf@linux-mips.org
Resent-Date: Wed, 26 Nov 2003 00:27:43 +0100
Resent-To: linux-mips@linux-mips.org
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: 3668
X-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: 925
Lines: 20

On Tue, Nov 25, 2003 at 04:52:20PM -0500, Kapoor, Pankaj wrote:

> Now there are 2 cases that can happen 
> 
> 1. Since we have not exited the ISR and the exception level has still not 
>    been restored there can be no more interrupts that are generated in the 
>    system. In such a case does that mean that the all bottom half handlers 
>    pending execution will run with interrupts disabled. 
>    NOTE: This does not seem likely because the local_irq_enable routine
>    calls _sti which clears the exception level in the status register and
>    also sets the IE bit. 
> 
> 2. If we have large number of tasklets or if the bottom half handlers take
>    time to execute, then we could get another timer interrupt or other
>    device interrupts causing context saves which would cause the stack to
>    grow and CRASH the system. 

Interrupts are disabled while the respective interrupt handler is running.

  Ralf

From ralf@linux-mips.org Tue Nov 25 23:28:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Nov 2003 23:28:29 +0000 (GMT)
Received: from p508B60ED.dip.t-dialin.net ([IPv6:::ffff:80.139.96.237]:9691
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226052AbTKYX2E>; Tue, 25 Nov 2003 23:28:04 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAPNS3A0013172
	for <linux-mips@linux-mips.org>; Wed, 26 Nov 2003 00:28:03 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAPNS3eu013162
	for linux-mips@linux-mips.org; Wed, 26 Nov 2003 00:28:03 +0100
Resent-Message-Id: <200311252328.hAPNS3eu013162@dea.linux-mips.net>
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAPNOdA0013060;
	Wed, 26 Nov 2003 00:24:39 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAPNOd54013059;
	Wed, 26 Nov 2003 00:24:39 +0100
Date: Wed, 26 Nov 2003 00:24:39 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] 2.4, head: PAGE_SHIFT changes break glibc
Message-ID: <20031125232439.GE11047@linux-mips.org>
References: <Pine.LNX.4.55.0311211550270.32551@jurand.ds.pg.gda.pl> <20031121185035.GC8318@linux-mips.org> <Pine.LNX.4.55.0311212021420.32551@jurand.ds.pg.gda.pl> <Pine.LNX.4.55.0311251623180.6716@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0311251623180.6716@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Resent-From: ralf@linux-mips.org
Resent-Date: Wed, 26 Nov 2003 00:28:03 +0100
Resent-To: linux-mips@linux-mips.org
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: 3669
X-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: 484
Lines: 21

On Tue, Nov 25, 2003 at 04:27:49PM +0100, Maciej W. Rozycki wrote:

>  After rebuilding glibc (2.2.5) with the patch applied, the following
> program:
> 
> #include <stdio.h>
> #include <unistd.h>
> 
> int main(void)
> {
> 	printf("%u\n", getpagesize());
> 	return 0;
> }
> 
> prints "4096" if dynamically linked and "65536" if statically linked on my
> system, as expected.

Guess we'll need a solution along the lines of
unix/sysv/linux/sparc/sparc32/getpagesize.c then ...

  Ralf

From ralf@linux-mips.org Tue Nov 25 23:44:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Nov 2003 23:44:23 +0000 (GMT)
Received: from p508B60ED.dip.t-dialin.net ([IPv6:::ffff:80.139.96.237]:5852
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226077AbTKYXoL>; Tue, 25 Nov 2003 23:44:11 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAPNi5A0013504;
	Wed, 26 Nov 2003 00:44:05 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAPNi42Z013503;
	Wed, 26 Nov 2003 00:44:04 +0100
Date: Wed, 26 Nov 2003 00:44:04 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Dan Malek <dan@embeddededge.com>
Cc: Wolfgang Denk <wd@denx.de>, Colin.Helliwell@Zarlink.Com,
	linux-mips@linux-mips.org
Subject: Re: Compressed kernels
Message-ID: <20031125234404.GG11047@linux-mips.org>
References: <20031120223335.03BFFC5F5F@atlas.denx.de> <3FBD4529.3070201@embeddededge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3FBD4529.3070201@embeddededge.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: 3670
X-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: 639
Lines: 14

On Thu, Nov 20, 2003 at 05:50:17PM -0500, Dan Malek wrote:

> Just to keep us busy, there are people that chose options
> other than u-boot :-)  For embedded systems that are really sensitive
> to boot time and amount of flash used, they may only have minimal
> instructions for processor initialization and then jump to the
> compressed kernel image.  I'm not going to discuss boot roms any
> further (yes, I use u-boot every chance I get).

... the lesson I learned about firmware is it's usually not very well
tested because there are only few applications (that is usually
operating systems) running it.  Phear da firmware ...

  Ralf

From macro@ds2.pg.gda.pl Wed Nov 26 00:09:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 00:09:32 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:4031 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226077AbTKZAJU>; Wed, 26 Nov 2003 00:09:20 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 06F654C136; Wed, 26 Nov 2003 01:09:16 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id ECC6647882; Wed, 26 Nov 2003 01:09:16 +0100 (CET)
Date: Wed, 26 Nov 2003 01:09:16 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] 2.4, head: PAGE_SHIFT changes break glibc
In-Reply-To: <20031125232439.GE11047@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0311260103320.6716@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0311211550270.32551@jurand.ds.pg.gda.pl>
 <20031121185035.GC8318@linux-mips.org> <Pine.LNX.4.55.0311212021420.32551@jurand.ds.pg.gda.pl>
 <Pine.LNX.4.55.0311251623180.6716@jurand.ds.pg.gda.pl>
 <20031125232439.GE11047@linux-mips.org>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3671
X-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: 549
Lines: 13

On Wed, 26 Nov 2003, Ralf Baechle wrote:

> Guess we'll need a solution along the lines of
> unix/sysv/linux/sparc/sparc32/getpagesize.c then ...

 I suppose so, although being not that fond of insane numbers of syscalls
I wonder how sysdeps/unix/sysv/linux/ia64/getpagesize.c gets away with
static binaries...  Perhaps we should ask glibc hackers?

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

From pkapoor@telogy.com Wed Nov 26 00:24:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 00:25:05 +0000 (GMT)
Received: from [IPv6:::ffff:209.116.120.7] ([IPv6:::ffff:209.116.120.7]:51975
	"EHLO tnint11.telogy.design.ti.com") by linux-mips.org with ESMTP
	id <S8226077AbTKZAYx>; Wed, 26 Nov 2003 00:24:53 +0000
Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19)
	id <W5NHJHL8>; Tue, 25 Nov 2003 19:24:18 -0500
Message-ID: <37A3C2F21006D611995100B0D0F9B73C02C8FCAF@tnint11.telogy.design.ti.com>
From: "Kapoor, Pankaj" <pkapoor@telogy.com>
To: 'Jun Sun' <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: RE: MIPS Interrupts.
Date: Tue, 25 Nov 2003 19:24:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <pkapoor@telogy.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3672
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pkapoor@telogy.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1174
Lines: 40

> The nested interrupt call, do_IRQ(), may still try to call do_softirq()
but
> that it will return immediately as it discovers another instance of
do_softirq()
> is running.  No further nesting occurs as a result. 

How is this detected ? Is this the check of "softirq_pending(cpu)" in the
do_softirq() ?

Can we have a case as shown below :

1. Interrupt 1 is generated : Jump to general exception handler
(0x8000:0180)
2. Save the current context
3. Interrupt 1 is processed which schedules tasklet1 for execution.
	softirq_pending(cpu) = TASKLET_SOFTIRQ
4. Interrupts are reenabled.
5. do_softirq : Tasklet1 is executing & softirq_pending(cpu) = 0.
6. -------> Interrupt 2 is generated : Jump to general exception handler
(0x8000:0180)
		6a) Save the current context
		6b) Interrupt2 is processed which schedules tasklet2 for
execution. 
			softirq_pending(cpu) = TASKLET_SOFTIRQ
		6c) Interrupts are reenabled.
		6d) do_softirq : Tasklet2 is executing &
softirq_pending(cpu) = 0.
		6e) ----> Interrupt3 is generated
			.... and so on.
		.
		.
		.
		6f) Context is restored. Return from exception.
.
.
.
7. Context is restored. Return from exception.

Thanks. 
- Pankaj

From jsun@mvista.com Wed Nov 26 00:31:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 00:31:17 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:63736 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225310AbTKZAbF>;
	Wed, 26 Nov 2003 00:31:05 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id hAQ0V4501881;
	Tue, 25 Nov 2003 16:31:04 -0800
Date: Tue, 25 Nov 2003 16:31:04 -0800
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Kapoor, Pankaj" <pkapoor@telogy.com>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: MIPS Interrupts.
Message-ID: <20031125163104.I28822@mvista.com>
References: <37A3C2F21006D611995100B0D0F9B73C02C8FCAE@tnint11.telogy.design.ti.com> <20031125230946.GA12422@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: <20031125230946.GA12422@linux-mips.org>; from ralf@linux-mips.org on Wed, Nov 26, 2003 at 12:09:46AM +0100
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3673
X-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: 1139
Lines: 25

On Wed, Nov 26, 2003 at 12:09:46AM +0100, Ralf Baechle wrote:
> On Tue, Nov 25, 2003 at 04:52:20PM -0500, Kapoor, Pankaj wrote:
> 
> > Now there are 2 cases that can happen 
> > 
> > 1. Since we have not exited the ISR and the exception level has still not 
> >    been restored there can be no more interrupts that are generated in the 
> >    system. In such a case does that mean that the all bottom half handlers 
> >    pending execution will run with interrupts disabled. 
> >    NOTE: This does not seem likely because the local_irq_enable routine
> >    calls _sti which clears the exception level in the status register and
> >    also sets the IE bit. 
> > 
> > 2. If we have large number of tasklets or if the bottom half handlers take
> >    time to execute, then we could get another timer interrupt or other
> >    device interrupts causing context saves which would cause the stack to
> >    grow and CRASH the system. 
> 
> Interrupts are disabled while the respective interrupt handler is running.
>

They are re-enabled for "bottom halves", i.e., in do_softirq().  I think
that is what the sender is worrying about.

Jun

From jsun@mvista.com Wed Nov 26 00:34:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 00:34:34 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:43002 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225310AbTKZAeW>;
	Wed, 26 Nov 2003 00:34:22 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id hAQ0YK601895;
	Tue, 25 Nov 2003 16:34:20 -0800
Date: Tue, 25 Nov 2003 16:34:20 -0800
From: Jun Sun <jsun@mvista.com>
To: "Kapoor, Pankaj" <pkapoor@telogy.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: MIPS Interrupts.
Message-ID: <20031125163420.J28822@mvista.com>
References: <37A3C2F21006D611995100B0D0F9B73C02C8FCAF@tnint11.telogy.design.ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <37A3C2F21006D611995100B0D0F9B73C02C8FCAF@tnint11.telogy.design.ti.com>; from pkapoor@telogy.com on Tue, Nov 25, 2003 at 07:24:18PM -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: 3674
X-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: 1294
Lines: 40

On Tue, Nov 25, 2003 at 07:24:18PM -0500, Kapoor, Pankaj wrote:
> > The nested interrupt call, do_IRQ(), may still try to call do_softirq()
> but
> > that it will return immediately as it discovers another instance of
> do_softirq()
> > is running.  No further nesting occurs as a result. 
> 
> How is this detected ? Is this the check of "softirq_pending(cpu)" in the
> do_softirq() ?
> 

No.  It is 

        if (in_interrupt())
                return;


> Can we have a case as shown below :
> 
> 1. Interrupt 1 is generated : Jump to general exception handler
> (0x8000:0180)
> 2. Save the current context
> 3. Interrupt 1 is processed which schedules tasklet1 for execution.
> 	softirq_pending(cpu) = TASKLET_SOFTIRQ
> 4. Interrupts are reenabled.
> 5. do_softirq : Tasklet1 is executing & softirq_pending(cpu) = 0.
> 6. -------> Interrupt 2 is generated : Jump to general exception handler
> (0x8000:0180)
> 		6a) Save the current context
> 		6b) Interrupt2 is processed which schedules tasklet2 for
> execution. 
> 			softirq_pending(cpu) = TASKLET_SOFTIRQ
> 		6c) Interrupts are reenabled.
> 		6d) do_softirq : Tasklet2 is executing &
> softirq_pending(cpu) = 0.

Impossible here, due to the above checking code.  Instead,
Tasklet2 will run by 5) once this interrupt trap returns.

Jun

From nemoto@toshiba-tops.co.jp Wed Nov 26 06:04:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 06:04:25 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:45080
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225205AbTKZGEN>; Wed, 26 Nov 2003 06:04:13 +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; 26 Nov 2003 06:04:41 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id hAQ64Tnd015570;
	Wed, 26 Nov 2003 15:04:32 +0900 (JST)
	(envelope-from nemoto@toshiba-tops.co.jp)
Date: Wed, 26 Nov 2003 15:07:19 +0900 (JST)
Message-Id: <20031126.150719.104026850.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: [PATCH] TX49Lx support
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <nemoto@toshiba-tops.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3675
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nemoto@toshiba-tops.co.jp
Precedence: bulk
X-list: linux-mips

Some TX49 do not have FPU.  We can tell such CPUs by bit3 of PrID.
Here is a patch for 2.4 tree.  The first hunk can also be used for 2.6
tree.  Please apply.  Thank you.

diff -ur linux-mips/arch/mips/kernel/cpu-probe.c linux/arch/mips/kernel/cpu-probe.c
--- linux-mips/arch/mips/kernel/cpu-probe.c	Tue Nov  4 16:57:34 2003
+++ linux/arch/mips/kernel/cpu-probe.c	Wed Nov 26 10:35:47 2003
@@ -297,6 +297,8 @@
 		c->isa_level = MIPS_CPU_ISA_III;
 		c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR |
 		             MIPS_CPU_LLSC;
+		if (c->processor_id & 0x08)	/* TX49Lx: no FPU */
+			c->options &= ~(MIPS_CPU_FPU | MIPS_CPU_32FPR);
 		c->tlbsize = 48;
 		break;
 	case PRID_IMP_R5000:
diff -ur linux-mips/arch/mips64/kernel/cpu-probe.c linux/arch/mips64/kernel/cpu-probe.c
--- linux-mips/arch/mips64/kernel/cpu-probe.c	Tue Nov  4 16:57:37 2003
+++ linux/arch/mips64/kernel/cpu-probe.c	Wed Nov 26 10:35:50 2003
@@ -622,6 +622,8 @@
 			c->isa_level = MIPS_CPU_ISA_III;
 			c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR |
 			             MIPS_CPU_LLSC;
+			if (c->processor_id & 0x08)	/* TX49Lx: no FPU */
+				c->options &= ~(MIPS_CPU_FPU | MIPS_CPU_32FPR);
 			c->tlbsize = 48;
 			break;
 		case PRID_IMP_R5000:
---
Atsushi Nemoto

From Dirk.Behme@de.bosch.com Wed Nov 26 08:20:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 08:20:48 +0000 (GMT)
Received: from gwa2.fe.bosch.de ([IPv6:::ffff:194.39.218.2]:18307 "EHLO
	gwa2.fe.bosch.de") by linux-mips.org with ESMTP id <S8225205AbTKZIUg>;
	Wed, 26 Nov 2003 08:20:36 +0000
Received: by gwa2.fe.bosch.de (Postfix, from userid 5)
	id 4F718C5210; Wed, 26 Nov 2003 09:20:04 +0100 (MET)
Received: from fez8020.de.bosch.com(unknown 10.4.4.19) by gwa2.fe.bosch.de via smap (V2.1)
	id xma017362; Wed, 26 Nov 03 09:19:42 +0100
Received: from 10.3.5.83 by fez8020.de.bosch.com (InterScan E-Mail VirusWall NT); Wed, 26 Nov 2003 09:19:32 +0100
Received: from hi-mail02.de.bosch.com ([10.34.16.71]) by si-imc02.de.bosch.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 26 Nov 2003 09:19:33 +0100
Received: from de.bosch.com ([10.34.211.138]) by hi-mail02.de.bosch.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 26 Nov 2003 09:19:28 +0100
Message-ID: <3FC461C5.6060303@de.bosch.com>
Date: Wed, 26 Nov 2003 09:18:13 +0100
From: Dirk Behme <dirk.behme@de.bosch.com>
Organization: Blaupunkt GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Missing #ifdef in asm/pci.h?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Nov 2003 08:19:28.0723 (UTC) FILETIME=[02D33A30:01C3B3F6]
Return-Path: <Dirk.Behme@de.bosch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3676
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dirk.behme@de.bosch.com
Precedence: bulk
X-list: linux-mips

Hello,

with linux_2_6_0_test9 include/asm-mips/pci.h I get these warnings:

include/asm/pci.h: In function `pci_dac_page_to_dma':
include/asm/pci.h:84: warning: implicit declaration of function 
`dev_to_baddr'
include/asm/pci.h: In function `pci_dac_dma_to_page':
include/asm/pci.h:90: warning: implicit declaration of function 
`baddr_to_dev'

dev_to_baddr and baddr_to_dev are defined in arch/mips/mm/dma-ip27.c and 
therefore can't be included in pci.h.

Is it possible that in pci.h there is missing an appropriate #ifdef 
around the pci_dac_* functions?

If I disable all pci_dac_* functions with #if 0, everything compiles 
without problems.

Dirk



From bruno.randolf@4g-systems.biz Wed Nov 26 12:09:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 12:09:58 +0000 (GMT)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.185]:57319
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225301AbTKZMJp>; Wed, 26 Nov 2003 12:09:45 +0000
Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1AOyUK-0005V8-00
	for linux-mips@linux-mips.org; Wed, 26 Nov 2003 13:09:44 +0100
Received: from [80.129.142.67] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1AOyUJ-0002O0-00
	for linux-mips@linux-mips.org; Wed, 26 Nov 2003 13:09:43 +0100
From: Bruno Randolf <bruno.randolf@4g-systems.biz>
Organization: 4G Mobile Systeme
To: linux-mips@linux-mips.org
Subject: au1000/mtx-1 patch
Date: Wed, 26 Nov 2003 13:09:42 +0100
User-Agent: KMail/1.5.3
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_GgJx/seF1gblmUl"
Message-Id: <200311261309.42281.bruno.randolf@4g-systems.biz>
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:d41044fba7cf33548d8f98fdbdd6d515
Return-Path: <bruno.randolf@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3677
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.biz
Precedence: bulk
X-list: linux-mips


--Boundary-00=_GgJx/seF1gblmUl
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: clearsigned data
Content-Disposition: inline

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello!

could someone please apply the attached patch to the linux_2_4 branch. it=20
fixes the board initialization for the mtx-1 board, makes the naming more=20
consistent and changes my e-mail address.

thanks a lot!

bruno

=2D --=20
4G Systeme GmbH
Am Sandtorkai 71
20457 Hamburg
fon: +49 (0)40 / 48 40 33 28
fax: +49 (0)40 / 48 40 33 30
mail: bruno.randolf@4g-systems.biz
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/xJgGfg2jtUL97G4RAof/AJ4zxhZ0xL+D1PbZbEGrBeurU/tsAwCgmsJV
CwQcZDW9ZBfLnK79nONmzOk=3D
=3DTnOy
=2D----END PGP SIGNATURE-----

--Boundary-00=_GgJx/seF1gblmUl
Content-Type: text/x-diff;
  charset="us-ascii";
  name="2.4.23-rc5-mtx.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="2.4.23-rc5-mtx.diff"

diff -Nurb mips-2.4.23-rc5/arch/mips/au1000/mtx-1/Makefile mips-2.4.23-rc5-mtx/arch/mips/au1000/mtx-1/Makefile
--- mips-2.4.23-rc5/arch/mips/au1000/mtx-1/Makefile	2003-11-26 10:51:39.000000000 +0100
+++ mips-2.4.23-rc5-mtx/arch/mips/au1000/mtx-1/Makefile	2003-11-26 11:37:13.000000000 +0100
@@ -2,7 +2,7 @@
 #  Copyright 2003 MontaVista Software Inc.
 #  Author: MontaVista Software, Inc.
 #     	ppopov@mvista.com or source@mvista.com
-#       Bruno Randolf <bruno.randolf@4g-systems.de>
+#       Bruno Randolf <bruno.randolf@4g-systems.biz>
 #
 # Makefile for 4G Systems MTX-1 board.
 #
diff -Nurb mips-2.4.23-rc5/arch/mips/au1000/mtx-1/board_setup.c mips-2.4.23-rc5-mtx/arch/mips/au1000/mtx-1/board_setup.c
--- mips-2.4.23-rc5/arch/mips/au1000/mtx-1/board_setup.c	2003-11-26 10:51:39.000000000 +0100
+++ mips-2.4.23-rc5-mtx/arch/mips/au1000/mtx-1/board_setup.c	2003-11-26 11:38:11.000000000 +0100
@@ -1,12 +1,12 @@
 /*
  *
  * BRIEF MODULE DESCRIPTION
- *	MTX-1 board setup.
+ *	4G Systems MTX-1 board setup.
  *
  * Copyright 2003 MontaVista Software Inc.
  * Author: MontaVista Software, Inc.
  *         	ppopov@mvista.com or source@mvista.com
- *         Bruno Randolf <bruno.randolf@4g-systems.de>
+ *         Bruno Randolf <bruno.randolf@4g-systems.biz>
  *
  *  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
@@ -50,12 +50,9 @@
 
 void __init board_setup(void)
 {
-	u32 pin_func;
-
 	rtc_ops = &no_rtc_ops;
 
 #if defined (CONFIG_USB_OHCI) || defined (CONFIG_AU1X00_USB_DEVICE)
-
 #ifdef CONFIG_AU1X00_USB_DEVICE
 	// 2nd USB port is USB device
 	au_writel(au_readl(SYS_PINFUNC) & (u32)(~0x8000), SYS_PINFUNC);
@@ -63,10 +60,8 @@
 	// enable USB power switch
 	au_writel( au_readl(GPIO2_DIR) | 0x10, GPIO2_DIR );
 	au_writel( 0x100000, GPIO2_OUTPUT );
-
 #endif // defined (CONFIG_USB_OHCI) || defined (CONFIG_AU1000_USB_DEVICE)
 
-
 #ifdef CONFIG_PCI
 #if defined(__MIPSEB__)
 	au_writel(0xf | (2<<6) | (1<<4), Au1500_PCI_CFG);
@@ -80,8 +75,11 @@
 	// set U3/GPIO23 to GPIO23 (SYS_PF_U3)
 	au_writel( SYS_PF_NI2 | SYS_PF_U3, SYS_PINFUNC );
 
-	// initialize GPIO: none used ATM
+	// initialize GPIO
 	au_writel( 0xFFFFFFFF, SYS_TRIOUTCLR );
+	au_writel( 0x00000001, SYS_OUTPUTCLR ); // set M66EN (PCI 66MHz) to OFF
+	au_writel( 0x00000008, SYS_OUTPUTSET ); // set PCI CLKRUN# to OFF
+	au_writel( 0x00000020, SYS_OUTPUTCLR ); // set eth PHY TX_ER to OFF
 
 	// enable LED and set it to green
 	au_writel( au_readl(GPIO2_DIR) | 0x1800, GPIO2_DIR );
diff -Nurb mips-2.4.23-rc5/arch/mips/au1000/mtx-1/init.c mips-2.4.23-rc5-mtx/arch/mips/au1000/mtx-1/init.c
--- mips-2.4.23-rc5/arch/mips/au1000/mtx-1/init.c	2003-11-26 10:51:39.000000000 +0100
+++ mips-2.4.23-rc5-mtx/arch/mips/au1000/mtx-1/init.c	2003-11-26 11:38:36.000000000 +0100
@@ -1,12 +1,12 @@
 /*
  *
  * BRIEF MODULE DESCRIPTION
- *	MTX-1 board setup
+ *	4G Systems MTX-1 board setup
  *
  * Copyright 2003 MontaVista Software Inc.
  * Author: MontaVista Software, Inc.
  *         	ppopov@mvista.com or source@mvista.com
- *         Bruno Randolf <bruno.randolf@4g-systems.de>
+ *         Bruno Randolf <bruno.randolf@4g-systems.biz>
  *
  *  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
diff -Nurb mips-2.4.23-rc5/arch/mips/defconfig-mtx-1 mips-2.4.23-rc5-mtx/arch/mips/defconfig-mtx-1
--- mips-2.4.23-rc5/arch/mips/defconfig-mtx-1	2003-11-26 10:51:39.000000000 +0100
+++ mips-2.4.23-rc5-mtx/arch/mips/defconfig-mtx-1	2003-11-26 12:38:46.000000000 +0100
@@ -1,5 +1,5 @@
 #
-# Automatically generated make config: don't edit
+# Automatically generated by make menuconfig: don't edit
 #
 CONFIG_MIPS=y
 CONFIG_MIPS32=y
@@ -138,7 +138,7 @@
 # CONFIG_MIPS32_N32 is not set
 # CONFIG_BINFMT_ELF32 is not set
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_PM is not set
+CONFIG_PM=y
 
 #
 # Memory Technology Devices (MTD)
@@ -149,10 +149,6 @@
 # CONFIG_MTD_CONCAT is not set
 # CONFIG_MTD_REDBOOT_PARTS is not set
 # CONFIG_MTD_CMDLINE_PARTS is not set
-
-#
-# User Modules And Translation Layers
-#
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
 # CONFIG_FTL is not set
@@ -200,10 +196,6 @@
 # CONFIG_MTD_SLRAM is not set
 # CONFIG_MTD_MTDRAM is not set
 # CONFIG_MTD_BLKMTD is not set
-
-#
-# Disk-On-Chip Device Drivers
-#
 # CONFIG_MTD_DOC1000 is not set
 # CONFIG_MTD_DOC2000 is not set
 # CONFIG_MTD_DOC2001 is not set
@@ -239,7 +231,8 @@
 # CONFIG_BLK_DEV_UMEM is not set
 CONFIG_BLK_DEV_LOOP=y
 # CONFIG_BLK_DEV_NBD is not set
-# CONFIG_BLK_DEV_RAM is not set
+CONFIG_BLK_DEV_RAM=m
+CONFIG_BLK_DEV_RAM_SIZE=4096
 # CONFIG_BLK_DEV_INITRD is not set
 # CONFIG_BLK_STATS is not set
 
@@ -259,33 +252,85 @@
 # Networking options
 #
 CONFIG_PACKET=y
-# CONFIG_PACKET_MMAP is not set
-# CONFIG_NETLINK_DEV is not set
+CONFIG_PACKET_MMAP=y
+CONFIG_NETLINK_DEV=m
 CONFIG_NETFILTER=y
 # CONFIG_NETFILTER_DEBUG is not set
-# CONFIG_FILTER is not set
+CONFIG_FILTER=y
 CONFIG_UNIX=y
 CONFIG_INET=y
 CONFIG_IP_MULTICAST=y
-# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_FWMARK=y
+CONFIG_IP_ROUTE_NAT=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_TOS=y
+CONFIG_IP_ROUTE_VERBOSE=y
 CONFIG_IP_PNP=y
-# CONFIG_IP_PNP_DHCP is not set
-CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_IP_PNP_BOOTP is not set
 # CONFIG_IP_PNP_RARP is not set
-# CONFIG_NET_IPIP is not set
-# CONFIG_NET_IPGRE is not set
-# CONFIG_IP_MROUTE is not set
+CONFIG_NET_IPIP=m
+CONFIG_NET_IPGRE=m
+CONFIG_NET_IPGRE_BROADCAST=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_PIMSM_V1=y
+CONFIG_IP_PIMSM_V2=y
 # CONFIG_ARPD is not set
 # CONFIG_INET_ECN is not set
-# CONFIG_SYN_COOKIES is not set
+CONFIG_SYN_COOKIES=y
 
 #
 #   IP: Netfilter Configuration
 #
-# CONFIG_IP_NF_CONNTRACK is not set
-# CONFIG_IP_NF_QUEUE is not set
-# CONFIG_IP_NF_IPTABLES is not set
-# CONFIG_IP_NF_ARPTABLES is not set
+CONFIG_IP_NF_CONNTRACK=m
+CONFIG_IP_NF_FTP=m
+# CONFIG_IP_NF_AMANDA is not set
+# CONFIG_IP_NF_TFTP is not set
+CONFIG_IP_NF_IRC=m
+CONFIG_IP_NF_QUEUE=m
+CONFIG_IP_NF_IPTABLES=m
+CONFIG_IP_NF_MATCH_LIMIT=m
+CONFIG_IP_NF_MATCH_MAC=m
+CONFIG_IP_NF_MATCH_PKTTYPE=m
+CONFIG_IP_NF_MATCH_MARK=m
+CONFIG_IP_NF_MATCH_MULTIPORT=m
+CONFIG_IP_NF_MATCH_TOS=m
+# CONFIG_IP_NF_MATCH_RECENT is not set
+CONFIG_IP_NF_MATCH_ECN=m
+CONFIG_IP_NF_MATCH_DSCP=m
+CONFIG_IP_NF_MATCH_AH_ESP=m
+CONFIG_IP_NF_MATCH_LENGTH=m
+CONFIG_IP_NF_MATCH_TTL=m
+CONFIG_IP_NF_MATCH_TCPMSS=m
+CONFIG_IP_NF_MATCH_HELPER=m
+CONFIG_IP_NF_MATCH_STATE=m
+CONFIG_IP_NF_MATCH_CONNTRACK=m
+# CONFIG_IP_NF_MATCH_UNCLEAN is not set
+# CONFIG_IP_NF_MATCH_OWNER is not set
+CONFIG_IP_NF_FILTER=m
+CONFIG_IP_NF_TARGET_REJECT=m
+# CONFIG_IP_NF_TARGET_MIRROR is not set
+CONFIG_IP_NF_NAT=m
+CONFIG_IP_NF_NAT_NEEDED=y
+CONFIG_IP_NF_TARGET_MASQUERADE=m
+CONFIG_IP_NF_TARGET_REDIRECT=m
+# CONFIG_IP_NF_NAT_LOCAL is not set
+# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
+CONFIG_IP_NF_NAT_IRC=m
+CONFIG_IP_NF_NAT_FTP=m
+CONFIG_IP_NF_MANGLE=m
+CONFIG_IP_NF_TARGET_TOS=m
+CONFIG_IP_NF_TARGET_ECN=m
+CONFIG_IP_NF_TARGET_DSCP=m
+CONFIG_IP_NF_TARGET_MARK=m
+CONFIG_IP_NF_TARGET_LOG=m
+CONFIG_IP_NF_TARGET_ULOG=m
+CONFIG_IP_NF_TARGET_TCPMSS=m
+CONFIG_IP_NF_ARPTABLES=m
+CONFIG_IP_NF_ARPFILTER=m
+# CONFIG_IP_NF_ARP_MANGLE is not set
 # CONFIG_IP_NF_COMPAT_IPCHAINS is not set
 # CONFIG_IP_NF_COMPAT_IPFWADM is not set
 
@@ -302,11 +347,7 @@
 CONFIG_IPV6_SCTP__=y
 # CONFIG_IP_SCTP is not set
 # CONFIG_ATM is not set
-# CONFIG_VLAN_8021Q is not set
-
-#
-#  
-#
+CONFIG_VLAN_8021Q=m
 # CONFIG_IPX is not set
 # CONFIG_ATALK is not set
 
@@ -315,7 +356,7 @@
 #
 # CONFIG_DEV_APPLETALK is not set
 # CONFIG_DECNET is not set
-# CONFIG_BRIDGE is not set
+CONFIG_BRIDGE=m
 # CONFIG_X25 is not set
 # CONFIG_LAPB is not set
 # CONFIG_LLC is not set
@@ -328,12 +369,34 @@
 #
 # QoS and/or fair queueing
 #
-# CONFIG_NET_SCHED is not set
+CONFIG_NET_SCHED=y
+CONFIG_NET_SCH_CBQ=m
+CONFIG_NET_SCH_HTB=m
+# CONFIG_NET_SCH_CSZ is not set
+CONFIG_NET_SCH_PRIO=m
+CONFIG_NET_SCH_RED=m
+CONFIG_NET_SCH_SFQ=m
+CONFIG_NET_SCH_TEQL=m
+CONFIG_NET_SCH_TBF=m
+CONFIG_NET_SCH_GRED=m
+CONFIG_NET_SCH_DSMARK=m
+CONFIG_NET_SCH_INGRESS=m
+CONFIG_NET_QOS=y
+CONFIG_NET_ESTIMATOR=y
+CONFIG_NET_CLS=y
+CONFIG_NET_CLS_TCINDEX=m
+CONFIG_NET_CLS_ROUTE4=m
+CONFIG_NET_CLS_ROUTE=y
+CONFIG_NET_CLS_FW=m
+CONFIG_NET_CLS_U32=m
+CONFIG_NET_CLS_RSVP=m
+# CONFIG_NET_CLS_RSVP6 is not set
+CONFIG_NET_CLS_POLICE=y
 
 #
 # Network testing
 #
-# CONFIG_NET_PKTGEN is not set
+CONFIG_NET_PKTGEN=m
 
 #
 # Telephony Support
@@ -352,7 +415,71 @@
 #
 # SCSI support
 #
-# CONFIG_SCSI is not set
+CONFIG_SCSI=m
+CONFIG_BLK_DEV_SD=m
+CONFIG_SD_EXTRA_DEVS=40
+# CONFIG_CHR_DEV_ST is not set
+# CONFIG_CHR_DEV_OSST is not set
+CONFIG_BLK_DEV_SR=m
+# CONFIG_BLK_DEV_SR_VENDOR is not set
+CONFIG_SR_EXTRA_DEVS=2
+# CONFIG_CHR_DEV_SG is not set
+# CONFIG_SCSI_DEBUG_QUEUES is not set
+# CONFIG_SCSI_MULTI_LUN is not set
+# CONFIG_SCSI_CONSTANTS is not set
+# CONFIG_SCSI_LOGGING is not set
+
+#
+# SCSI low-level drivers
+#
+# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
+# CONFIG_SCSI_7000FASST is not set
+# CONFIG_SCSI_ACARD is not set
+# CONFIG_SCSI_AHA152X is not set
+# CONFIG_SCSI_AHA1542 is not set
+# CONFIG_SCSI_AHA1740 is not set
+# CONFIG_SCSI_AACRAID is not set
+# CONFIG_SCSI_AIC7XXX is not set
+# CONFIG_SCSI_AIC79XX is not set
+# CONFIG_SCSI_AIC7XXX_OLD is not set
+# CONFIG_SCSI_DPT_I2O is not set
+# CONFIG_SCSI_ADVANSYS is not set
+# CONFIG_SCSI_IN2000 is not set
+# CONFIG_SCSI_AM53C974 is not set
+# CONFIG_SCSI_MEGARAID is not set
+# CONFIG_SCSI_MEGARAID2 is not set
+# CONFIG_SCSI_BUSLOGIC is not set
+# CONFIG_SCSI_CPQFCTS is not set
+# CONFIG_SCSI_DMX3191D is not set
+# CONFIG_SCSI_DTC3280 is not set
+# CONFIG_SCSI_EATA is not set
+# CONFIG_SCSI_EATA_DMA is not set
+# CONFIG_SCSI_EATA_PIO is not set
+# CONFIG_SCSI_FUTURE_DOMAIN is not set
+# CONFIG_SCSI_GDTH is not set
+# CONFIG_SCSI_GENERIC_NCR5380 is not set
+# CONFIG_SCSI_INITIO is not set
+# CONFIG_SCSI_INIA100 is not set
+# CONFIG_SCSI_NCR53C406A is not set
+# CONFIG_SCSI_NCR53C7xx is not set
+# CONFIG_SCSI_SYM53C8XX_2 is not set
+# CONFIG_SCSI_NCR53C8XX is not set
+# CONFIG_SCSI_SYM53C8XX is not set
+# CONFIG_SCSI_PAS16 is not set
+# CONFIG_SCSI_PCI2000 is not set
+# CONFIG_SCSI_PCI2220I is not set
+# CONFIG_SCSI_PSI240I is not set
+# CONFIG_SCSI_QLOGIC_FAS is not set
+# CONFIG_SCSI_QLOGIC_ISP is not set
+# CONFIG_SCSI_QLOGIC_FC is not set
+# CONFIG_SCSI_QLOGIC_1280 is not set
+# CONFIG_SCSI_SIM710 is not set
+# CONFIG_SCSI_SYM53C416 is not set
+# CONFIG_SCSI_DC390T is not set
+# CONFIG_SCSI_T128 is not set
+# CONFIG_SCSI_U14_34F is not set
+# CONFIG_SCSI_NSP32 is not set
+# CONFIG_SCSI_DEBUG is not set
 
 #
 # I2O device support
@@ -373,10 +500,10 @@
 # ARCnet devices
 #
 # CONFIG_ARCNET is not set
-# CONFIG_DUMMY is not set
-# CONFIG_BONDING is not set
+CONFIG_DUMMY=m
+CONFIG_BONDING=m
 # CONFIG_EQUALIZER is not set
-# CONFIG_TUN is not set
+CONFIG_TUN=m
 # CONFIG_ETHERTAP is not set
 
 #
@@ -415,13 +542,32 @@
 # CONFIG_FDDI is not set
 # CONFIG_HIPPI is not set
 # CONFIG_PLIP is not set
-# CONFIG_PPP is not set
+CONFIG_PPP=m
+CONFIG_PPP_MULTILINK=y
+# CONFIG_PPP_FILTER is not set
+CONFIG_PPP_ASYNC=m
+CONFIG_PPP_SYNC_TTY=m
+CONFIG_PPP_DEFLATE=m
+CONFIG_PPP_BSDCOMP=m
+CONFIG_PPPOE=m
 # CONFIG_SLIP is not set
 
 #
 # Wireless LAN (non-hamradio)
 #
-# CONFIG_NET_RADIO is not set
+CONFIG_NET_RADIO=y
+# CONFIG_STRIP is not set
+# CONFIG_WAVELAN is not set
+# CONFIG_ARLAN is not set
+# CONFIG_AIRONET4500 is not set
+# CONFIG_AIRONET4500_NONCS is not set
+# CONFIG_AIRONET4500_PROC is not set
+# CONFIG_AIRO is not set
+# CONFIG_HERMES is not set
+# CONFIG_PLX_HERMES is not set
+# CONFIG_TMD_HERMES is not set
+# CONFIG_PCI_HERMES is not set
+CONFIG_NET_WIRELESS=y
 
 #
 # Token Ring devices
@@ -511,14 +657,6 @@
 # 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
@@ -550,7 +688,7 @@
 # Direct Rendering Manager (XFree86 DRI support)
 #
 # CONFIG_DRM is not set
-# CONFIG_AU1X00_GPIO is not set
+CONFIG_AU1X00_GPIO=m
 # CONFIG_TS_AU1X00_ADS7846 is not set
 
 #
@@ -560,7 +698,7 @@
 # CONFIG_QFMT_V2 is not set
 # CONFIG_AUTOFS_FS is not set
 # CONFIG_AUTOFS4_FS is not set
-# CONFIG_REISERFS_FS is not set
+CONFIG_REISERFS_FS=m
 # CONFIG_REISERFS_CHECK is not set
 # CONFIG_REISERFS_PROC_INFO is not set
 # CONFIG_ADFS_FS is not set
@@ -571,28 +709,29 @@
 # CONFIG_BEFS_FS is not set
 # CONFIG_BEFS_DEBUG is not set
 # CONFIG_BFS_FS is not set
-CONFIG_EXT3_FS=y
-CONFIG_JBD=y
+CONFIG_EXT3_FS=m
+CONFIG_JBD=m
 # CONFIG_JBD_DEBUG is not set
-# CONFIG_FAT_FS is not set
-# CONFIG_MSDOS_FS is not set
+CONFIG_FAT_FS=m
+CONFIG_MSDOS_FS=m
 # CONFIG_UMSDOS_FS is not set
-# CONFIG_VFAT_FS is not set
+CONFIG_VFAT_FS=m
 # CONFIG_EFS_FS is not set
 # CONFIG_JFFS_FS is not set
-# CONFIG_JFFS2_FS is not set
+CONFIG_JFFS2_FS=y
+CONFIG_JFFS2_FS_DEBUG=0
 # CONFIG_CRAMFS is not set
 CONFIG_TMPFS=y
 CONFIG_RAMFS=y
-# CONFIG_ISO9660_FS is not set
-# CONFIG_JOLIET is not set
-# CONFIG_ZISOFS is not set
+CONFIG_ISO9660_FS=m
+CONFIG_JOLIET=y
+CONFIG_ZISOFS=y
 # CONFIG_JFS_FS is not set
 # CONFIG_JFS_DEBUG is not set
 # CONFIG_JFS_STATISTICS is not set
 # CONFIG_MINIX_FS is not set
 # CONFIG_VXFS_FS is not set
-# CONFIG_NTFS_FS is not set
+CONFIG_NTFS_FS=m
 # CONFIG_NTFS_RW is not set
 # CONFIG_HPFS_FS is not set
 CONFIG_PROC_FS=y
@@ -603,9 +742,9 @@
 # CONFIG_QNX4FS_FS is not set
 # CONFIG_QNX4FS_RW is not set
 # CONFIG_ROMFS_FS is not set
-CONFIG_EXT2_FS=y
+CONFIG_EXT2_FS=m
 # CONFIG_SYSV_FS is not set
-# CONFIG_UDF_FS is not set
+CONFIG_UDF_FS=m
 # CONFIG_UDF_RW is not set
 # CONFIG_UFS_FS is not set
 # CONFIG_UFS_FS_WRITE is not set
@@ -625,7 +764,8 @@
 CONFIG_SUNRPC=y
 CONFIG_LOCKD=y
 CONFIG_LOCKD_V4=y
-# CONFIG_SMB_FS is not set
+CONFIG_SMB_FS=m
+# CONFIG_SMB_NLS_DEFAULT is not set
 # CONFIG_NCP_FS is not set
 # CONFIG_NCPFS_PACKET_SIGNING is not set
 # CONFIG_NCPFS_IOCTL_LOCKING is not set
@@ -635,30 +775,252 @@
 # CONFIG_NCPFS_SMALLDOS is not set
 # CONFIG_NCPFS_NLS is not set
 # CONFIG_NCPFS_EXTRAS is not set
-# CONFIG_ZISOFS_FS is not set
+CONFIG_ZISOFS_FS=m
 
 #
 # Partition Types
 #
 # CONFIG_PARTITION_ADVANCED is not set
 CONFIG_MSDOS_PARTITION=y
-# CONFIG_SMB_NLS is not set
-# CONFIG_NLS is not set
+CONFIG_SMB_NLS=y
+CONFIG_NLS=y
+
+#
+# Native Language Support
+#
+CONFIG_NLS_DEFAULT="iso8859-15"
+CONFIG_NLS_CODEPAGE_437=m
+# CONFIG_NLS_CODEPAGE_737 is not set
+# CONFIG_NLS_CODEPAGE_775 is not set
+CONFIG_NLS_CODEPAGE_850=m
+# CONFIG_NLS_CODEPAGE_852 is not set
+# CONFIG_NLS_CODEPAGE_855 is not set
+# CONFIG_NLS_CODEPAGE_857 is not set
+# CONFIG_NLS_CODEPAGE_860 is not set
+# CONFIG_NLS_CODEPAGE_861 is not set
+# CONFIG_NLS_CODEPAGE_862 is not set
+# CONFIG_NLS_CODEPAGE_863 is not set
+# CONFIG_NLS_CODEPAGE_864 is not set
+# CONFIG_NLS_CODEPAGE_865 is not set
+# CONFIG_NLS_CODEPAGE_866 is not set
+# CONFIG_NLS_CODEPAGE_869 is not set
+# CONFIG_NLS_CODEPAGE_936 is not set
+# CONFIG_NLS_CODEPAGE_950 is not set
+# CONFIG_NLS_CODEPAGE_932 is not set
+# CONFIG_NLS_CODEPAGE_949 is not set
+# CONFIG_NLS_CODEPAGE_874 is not set
+# CONFIG_NLS_ISO8859_8 is not set
+# CONFIG_NLS_CODEPAGE_1250 is not set
+# CONFIG_NLS_CODEPAGE_1251 is not set
+CONFIG_NLS_ISO8859_1=m
+# CONFIG_NLS_ISO8859_2 is not set
+# CONFIG_NLS_ISO8859_3 is not set
+# CONFIG_NLS_ISO8859_4 is not set
+# CONFIG_NLS_ISO8859_5 is not set
+# CONFIG_NLS_ISO8859_6 is not set
+# CONFIG_NLS_ISO8859_7 is not set
+# CONFIG_NLS_ISO8859_9 is not set
+# CONFIG_NLS_ISO8859_13 is not set
+# CONFIG_NLS_ISO8859_14 is not set
+CONFIG_NLS_ISO8859_15=m
+# CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
+CONFIG_NLS_UTF8=m
 
 #
 # Multimedia devices
 #
-# CONFIG_VIDEO_DEV is not set
+CONFIG_VIDEO_DEV=m
+
+#
+# Video For Linux
+#
+# CONFIG_VIDEO_PROC_FS is not set
+# CONFIG_I2C_PARPORT is not set
+# CONFIG_VIDEO_BT848 is not set
+# CONFIG_VIDEO_PMS is not set
+# CONFIG_VIDEO_CPIA is not set
+# CONFIG_VIDEO_SAA5249 is not set
+# CONFIG_TUNER_3036 is not set
+# CONFIG_VIDEO_STRADIS is not set
+# CONFIG_VIDEO_ZORAN is not set
+# CONFIG_VIDEO_ZORAN_BUZ is not set
+# CONFIG_VIDEO_ZORAN_DC10 is not set
+# CONFIG_VIDEO_ZORAN_LML33 is not set
+# CONFIG_VIDEO_ZR36120 is not set
+# CONFIG_VIDEO_MEYE is not set
+
+#
+# Radio Adapters
+#
+# CONFIG_RADIO_GEMTEK_PCI is not set
+# CONFIG_RADIO_MAXIRADIO is not set
+# CONFIG_RADIO_MAESTRO is not set
+# CONFIG_RADIO_MIROPCM20 is not set
 
 #
 # Sound
 #
-# CONFIG_SOUND is not set
+CONFIG_SOUND=m
+# CONFIG_SOUND_ALI5455 is not set
+# CONFIG_SOUND_BT878 is not set
+# CONFIG_SOUND_CMPCI is not set
+# CONFIG_SOUND_EMU10K1 is not set
+# CONFIG_MIDI_EMU10K1 is not set
+# CONFIG_SOUND_FUSION is not set
+# CONFIG_SOUND_CS4281 is not set
+# CONFIG_SOUND_ES1370 is not set
+# CONFIG_SOUND_ES1371 is not set
+# CONFIG_SOUND_ESSSOLO1 is not set
+# CONFIG_SOUND_MAESTRO is not set
+# CONFIG_SOUND_MAESTRO3 is not set
+# CONFIG_SOUND_FORTE is not set
+# CONFIG_SOUND_ICH is not set
+# CONFIG_SOUND_RME96XX is not set
+# CONFIG_SOUND_SONICVIBES is not set
+# CONFIG_SOUND_AU1X00 is not set
+# CONFIG_SOUND_TRIDENT is not set
+# CONFIG_SOUND_MSNDCLAS is not set
+# CONFIG_SOUND_MSNDPIN is not set
+# CONFIG_SOUND_VIA82CXXX is not set
+# CONFIG_MIDI_VIA82CXXX is not set
+CONFIG_SOUND_OSS=m
+# CONFIG_SOUND_TRACEINIT is not set
+# CONFIG_SOUND_DMAP is not set
+# CONFIG_SOUND_AD1816 is not set
+# CONFIG_SOUND_AD1889 is not set
+# CONFIG_SOUND_SGALAXY is not set
+# CONFIG_SOUND_ADLIB is not set
+# CONFIG_SOUND_ACI_MIXER is not set
+# CONFIG_SOUND_CS4232 is not set
+# CONFIG_SOUND_SSCAPE is not set
+# CONFIG_SOUND_GUS is not set
+# CONFIG_SOUND_VMIDI is not set
+# CONFIG_SOUND_TRIX is not set
+# CONFIG_SOUND_MSS is not set
+# CONFIG_SOUND_MPU401 is not set
+# CONFIG_SOUND_NM256 is not set
+# CONFIG_SOUND_MAD16 is not set
+# CONFIG_SOUND_PAS is not set
+# CONFIG_PAS_JOYSTICK is not set
+# CONFIG_SOUND_PSS is not set
+# CONFIG_SOUND_SB is not set
+# CONFIG_SOUND_AWE32_SYNTH is not set
+# CONFIG_SOUND_KAHLUA is not set
+# CONFIG_SOUND_WAVEFRONT is not set
+# CONFIG_SOUND_MAUI is not set
+# CONFIG_SOUND_YM3812 is not set
+# CONFIG_SOUND_OPL3SA1 is not set
+# CONFIG_SOUND_OPL3SA2 is not set
+# CONFIG_SOUND_YMFPCI is not set
+# CONFIG_SOUND_YMFPCI_LEGACY is not set
+# CONFIG_SOUND_UART6850 is not set
+# CONFIG_SOUND_AEDSP16 is not set
+# CONFIG_SOUND_TVMIXER is not set
+# CONFIG_SOUND_AD1980 is not set
+# CONFIG_SOUND_WM97XX is not set
 
 #
 # USB support
 #
-# CONFIG_USB is not set
+CONFIG_USB=y
+# CONFIG_USB_DEBUG is not set
+CONFIG_USB_DEVICEFS=y
+# CONFIG_USB_BANDWIDTH is not set
+# CONFIG_USB_EHCI_HCD is not set
+# CONFIG_USB_UHCI is not set
+# CONFIG_USB_UHCI_ALT is not set
+CONFIG_USB_OHCI=y
+CONFIG_USB_AUDIO=m
+CONFIG_USB_EMI26=m
+CONFIG_USB_MIDI=m
+CONFIG_USB_STORAGE=m
+CONFIG_USB_STORAGE_DEBUG=y
+CONFIG_USB_STORAGE_DATAFAB=y
+CONFIG_USB_STORAGE_FREECOM=y
+# CONFIG_USB_STORAGE_ISD200 is not set
+CONFIG_USB_STORAGE_DPCM=y
+CONFIG_USB_STORAGE_HP8200e=y
+CONFIG_USB_STORAGE_SDDR09=y
+CONFIG_USB_STORAGE_SDDR55=y
+CONFIG_USB_STORAGE_JUMPSHOT=y
+CONFIG_USB_ACM=m
+CONFIG_USB_PRINTER=m
+# CONFIG_USB_HID is not set
+# CONFIG_USB_HIDINPUT is not set
+# CONFIG_USB_HIDDEV is not set
+# CONFIG_USB_KBD is not set
+# CONFIG_USB_MOUSE is not set
+# CONFIG_USB_AIPTEK is not set
+# CONFIG_USB_WACOM is not set
+# CONFIG_USB_KBTAB is not set
+# CONFIG_USB_POWERMATE is not set
+CONFIG_USB_DC2XX=m
+CONFIG_USB_MDC800=m
+CONFIG_USB_SCANNER=m
+CONFIG_USB_MICROTEK=m
+CONFIG_USB_HPUSBSCSI=m
+CONFIG_USB_IBMCAM=m
+CONFIG_USB_KONICAWC=m
+CONFIG_USB_OV511=m
+CONFIG_USB_PWC=m
+CONFIG_USB_SE401=m
+CONFIG_USB_STV680=m
+# CONFIG_USB_W9968CF is not set
+CONFIG_USB_VICAM=m
+CONFIG_USB_DSBR=m
+CONFIG_USB_DABUSB=m
+CONFIG_USB_PEGASUS=m
+CONFIG_USB_RTL8150=m
+CONFIG_USB_KAWETH=m
+CONFIG_USB_CATC=m
+# CONFIG_USB_AX8817X is not set
+CONFIG_USB_CDCETHER=m
+CONFIG_USB_USBNET=m
+# CONFIG_USB_USS720 is not set
+
+#
+# USB Serial Converter support
+#
+CONFIG_USB_SERIAL=m
+# CONFIG_USB_SERIAL_DEBUG is not set
+CONFIG_USB_SERIAL_GENERIC=y
+CONFIG_USB_SERIAL_BELKIN=m
+CONFIG_USB_SERIAL_WHITEHEAT=m
+CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
+CONFIG_USB_SERIAL_EMPEG=m
+CONFIG_USB_SERIAL_FTDI_SIO=m
+CONFIG_USB_SERIAL_VISOR=m
+CONFIG_USB_SERIAL_IPAQ=m
+CONFIG_USB_SERIAL_IR=m
+CONFIG_USB_SERIAL_EDGEPORT=m
+CONFIG_USB_SERIAL_EDGEPORT_TI=m
+CONFIG_USB_SERIAL_KEYSPAN_PDA=m
+CONFIG_USB_SERIAL_KEYSPAN=m
+CONFIG_USB_SERIAL_KEYSPAN_USA28=y
+CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
+CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
+CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
+CONFIG_USB_SERIAL_KEYSPAN_USA19=y
+CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
+CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
+CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
+CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
+CONFIG_USB_SERIAL_KEYSPAN_MPR=y
+CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
+CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
+CONFIG_USB_SERIAL_MCT_U232=m
+CONFIG_USB_SERIAL_KLSI=m
+CONFIG_USB_SERIAL_KOBIL_SCT=m
+CONFIG_USB_SERIAL_PL2303=m
+CONFIG_USB_SERIAL_CYBERJACK=m
+CONFIG_USB_SERIAL_XIRCOM=m
+CONFIG_USB_SERIAL_OMNINET=m
+CONFIG_USB_RIO500=m
+CONFIG_USB_AUERSWALD=m
+CONFIG_USB_TIGL=m
+CONFIG_USB_BRLVGER=m
+CONFIG_USB_LCD=m
 
 #
 # Support for USB gadgets
@@ -668,7 +1030,30 @@
 #
 # Bluetooth support
 #
-# CONFIG_BLUEZ is not set
+CONFIG_BLUEZ=m
+CONFIG_BLUEZ_L2CAP=m
+CONFIG_BLUEZ_SCO=m
+CONFIG_BLUEZ_RFCOMM=m
+CONFIG_BLUEZ_RFCOMM_TTY=y
+CONFIG_BLUEZ_BNEP=m
+CONFIG_BLUEZ_BNEP_MC_FILTER=y
+CONFIG_BLUEZ_BNEP_PROTO_FILTER=y
+
+#
+# Bluetooth device drivers
+#
+CONFIG_BLUEZ_HCIUSB=m
+CONFIG_BLUEZ_USB_SCO=y
+CONFIG_BLUEZ_HCIUART=m
+CONFIG_BLUEZ_HCIUART_H4=y
+CONFIG_BLUEZ_HCIUART_BCSP=y
+CONFIG_BLUEZ_HCIUART_BCSP_TXCRC=y
+# CONFIG_BLUEZ_HCIBFUSB is not set
+# CONFIG_BLUEZ_HCIDTL1 is not set
+# CONFIG_BLUEZ_HCIBT3C is not set
+# CONFIG_BLUEZ_HCIBLUECARD is not set
+# CONFIG_BLUEZ_HCIBTUART is not set
+CONFIG_BLUEZ_HCIVHCI=m
 
 #
 # Kernel hacking
@@ -691,5 +1076,5 @@
 # Library routines
 #
 # CONFIG_CRC32 is not set
-# CONFIG_ZLIB_INFLATE is not set
-# CONFIG_ZLIB_DEFLATE is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_ZLIB_DEFLATE=y


--Boundary-00=_GgJx/seF1gblmUl--


From bruno.randolf@4g-systems.biz Wed Nov 26 12:28:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 12:28:25 +0000 (GMT)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.186]:37325
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225339AbTKZM2N>; Wed, 26 Nov 2003 12:28:13 +0000
Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1AOymB-0007NM-00
	for linux-mips@linux-mips.org; Wed, 26 Nov 2003 13:28:11 +0100
Received: from [80.129.142.67] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1AOymB-0004ZP-00
	for linux-mips@linux-mips.org; Wed, 26 Nov 2003 13:28:11 +0100
From: Bruno Randolf <bruno.randolf@4g-systems.biz>
Organization: 4G Mobile Systeme
To: linux-mips@linux-mips.org
Subject: au1000_eth LEDs for mtx-1
Date: Wed, 26 Nov 2003 13:28:10 +0100
User-Agent: KMail/1.5.3
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_axJx/6DN8y7sQyC"
Message-Id: <200311261328.10840.bruno.randolf@4g-systems.biz>
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:d41044fba7cf33548d8f98fdbdd6d515
Return-Path: <bruno.randolf@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3678
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.biz
Precedence: bulk
X-list: linux-mips


--Boundary-00=_axJx/6DN8y7sQyC
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: clearsigned data
Content-Disposition: inline

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi again!

please also consider this small patch for enabling the traffic indication L=
EDs=20
of au1000_eth for the mtx-1 board.

thanks!

bruno

=2D --=20
4G Systeme GmbH
Am Sandtorkai 71
20457 Hamburg
fon: +49 (0)40 / 48 40 33 28
fax: +49 (0)40 / 48 40 33 30
mail: bruno.randolf@4g-systems.biz
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/xJxafg2jtUL97G4RAuBTAJ9eujYeu4T8Vuo5sAmRTx6ARg6W4QCfQYbo
LhHUKTKuMQwfgkJu62nTsF0=3D
=3DauPq
=2D----END PGP SIGNATURE-----

--Boundary-00=_axJx/6DN8y7sQyC
Content-Type: text/x-diff;
  charset="us-ascii";
  name="au1000_mtx_led.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="au1000_mtx_led.diff"

--- /data/kernel/mips-2.4.23-rc5/drivers/net/au1000_eth.c	2003-11-26 10:51:55.000000000 +0100
+++ drivers/net/au1000_eth.c	2003-11-26 13:16:26.000000000 +0100
@@ -241,7 +241,11 @@
 	mdelay(1);
 
 	/* set up LEDs to correct display */
+#ifdef CONFIG_MIPS_MTX1
+	mdio_write(dev, phy_addr, 17, 0xff80);
+#else
 	mdio_write(dev, phy_addr, 17, 0xffc0);
+#endif
 
 	if (au1000_debug > 4)
 		dump_mii(dev, phy_addr);

--Boundary-00=_axJx/6DN8y7sQyC--


From rathann@icm.edu.pl Wed Nov 26 16:06:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 16:06:56 +0000 (GMT)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:40711 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225339AbTKZMpB>;
	Wed, 26 Nov 2003 12:45:01 +0000
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 hAQCiGTq003784
	for <linux-mips@linux-mips.org>; Wed, 26 Nov 2003 13:44:32 +0100 (CET)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1AOz1l-00084P-00
	for <linux-mips@linux-mips.org>; Wed, 26 Nov 2003 13:44:17 +0100
Date: Wed, 26 Nov 2003 13:44:17 +0100
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: ftp.linux-mips.org down?
Message-ID: <20031126124416.GA30744@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
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: 3679
X-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

Hi.
I'm currently (12:40:14 UTC) getting connection refused while
trying to connect to ftp.linux-mips.org, although traceroute
shows no problems. Any clues?

Regards,
-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>
LAN ICM UW Geologia, tel. (22) 5540810

From ralf@linux-mips.org Wed Nov 26 16:07:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 16:07:28 +0000 (GMT)
Received: from p508B60ED.dip.t-dialin.net ([IPv6:::ffff:80.139.96.237]:25259
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225346AbTKZPx4>; Wed, 26 Nov 2003 15:53:56 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAQFrsA0010941;
	Wed, 26 Nov 2003 16:53:55 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAQFrk6M010929;
	Wed, 26 Nov 2003 16:53:46 +0100
Date: Wed, 26 Nov 2003 16:53:45 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] TX49Lx support
Message-ID: <20031126155345.GA10842@linux-mips.org>
References: <20031126.150719.104026850.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031126.150719.104026850.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3680
X-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, Nov 26, 2003 at 03:07:19PM +0900, Atsushi Nemoto wrote:

> Some TX49 do not have FPU.  We can tell such CPUs by bit3 of PrID.
> Here is a patch for 2.4 tree.  The first hunk can also be used for 2.6
> tree.  Please apply.  Thank you.

In general I'd like to ask people to send patches for 2.4 and 2.6 in
separate email.

I applied your patch with a little change for clarity; I also
restructured the 64-bit cpu-probe.c the same way as it's 32-bit
counterpart to keep the two files more similar.

  Ralf

From ppopov@mvista.com Wed Nov 26 16:26:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 16:26:50 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:29940 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225297AbTKZQ0i>;
	Wed, 26 Nov 2003 16:26: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 IAA26535;
	Wed, 26 Nov 2003 08:26:14 -0800
Subject: Re: au1000_eth LEDs for mtx-1
From: Pete Popov <ppopov@mvista.com>
To: Bruno Randolf <bruno.randolf@4g-systems.biz>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <200311261328.10840.bruno.randolf@4g-systems.biz>
References: <200311261328.10840.bruno.randolf@4g-systems.biz>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1069864151.26623.13.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 26 Nov 2003 08:29:11 -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: 3681
X-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

Bruno,

I'll take a look at both patches this weekend.

Pete

On Wed, 2003-11-26 at 04:28, Bruno Randolf wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> hi again!
> 
> please also consider this small patch for enabling the traffic indication LEDs 
> of au1000_eth for the mtx-1 board.
> 
> thanks!
> 
> bruno
> 
> - -- 
> 4G Systeme GmbH
> Am Sandtorkai 71
> 20457 Hamburg
> fon: +49 (0)40 / 48 40 33 28
> fax: +49 (0)40 / 48 40 33 30
> mail: bruno.randolf@4g-systems.biz
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD8DBQE/xJxafg2jtUL97G4RAuBTAJ9eujYeu4T8Vuo5sAmRTx6ARg6W4QCfQYbo
> LhHUKTKuMQwfgkJu62nTsF0=
> =auPq
> -----END PGP SIGNATURE-----


From drow@crack.them.org Wed Nov 26 17:02:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Nov 2003 17:02:50 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:38543 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225340AbTKZRCi>;
	Wed, 26 Nov 2003 17:02:38 +0000
Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian))
	id 1AP33c-0003QK-LP; Wed, 26 Nov 2003 12:02:28 -0500
Date: Wed, 26 Nov 2003 12:02:28 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] 2.4, head: PAGE_SHIFT changes break glibc
Message-ID: <20031126170228.GA13116@nevyn.them.org>
References: <Pine.LNX.4.55.0311211550270.32551@jurand.ds.pg.gda.pl> <20031121185035.GC8318@linux-mips.org> <Pine.LNX.4.55.0311212021420.32551@jurand.ds.pg.gda.pl> <Pine.LNX.4.55.0311251623180.6716@jurand.ds.pg.gda.pl> <20031125232439.GE11047@linux-mips.org> <Pine.LNX.4.55.0311260103320.6716@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0311260103320.6716@jurand.ds.pg.gda.pl>
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: 3682
X-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, Nov 26, 2003 at 01:09:16AM +0100, Maciej W. Rozycki wrote:
> On Wed, 26 Nov 2003, Ralf Baechle wrote:
> 
> > Guess we'll need a solution along the lines of
> > unix/sysv/linux/sparc/sparc32/getpagesize.c then ...
> 
>  I suppose so, although being not that fond of insane numbers of syscalls
> I wonder how sysdeps/unix/sysv/linux/ia64/getpagesize.c gets away with
> static binaries...  Perhaps we should ask glibc hackers?

Look at elf/dl-support.c:_dl_aux_init? dl_pagesize should end up
initialized for static binaries too.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From nemoto@toshiba-tops.co.jp Thu Nov 27 01:10:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Nov 2003 01:10:26 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:27146
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225383AbTK0BKN>; Thu, 27 Nov 2003 01:10:13 +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; 27 Nov 2003 01:10:42 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id hAR1AOnd017384;
	Thu, 27 Nov 2003 10:10:24 +0900 (JST)
	(envelope-from nemoto@toshiba-tops.co.jp)
Date: Thu, 27 Nov 2003 10:13:15 +0900 (JST)
Message-Id: <20031127.101315.74756138.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] TX49Lx support
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
In-Reply-To: <20031126155345.GA10842@linux-mips.org>
References: <20031126.150719.104026850.nemoto@toshiba-tops.co.jp>
	<20031126155345.GA10842@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <nemoto@toshiba-tops.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3683
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nemoto@toshiba-tops.co.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Wed, 26 Nov 2003 16:53:45 +0100, Ralf Baechle <ralf@linux-mips.org> said:
ralf> In general I'd like to ask people to send patches for 2.4 and
ralf> 2.6 in separate email.

Please forgive my laziness.  I will do so next time.

ralf> I applied your patch with a little change for clarity; I also
ralf> restructured the 64-bit cpu-probe.c the same way as it's 32-bit
ralf> counterpart to keep the two files more similar.

Thanks for your quick response.

---
Atsushi Nemoto

From macro@ds2.pg.gda.pl Fri Nov 28 14:44:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Nov 2003 14:45:09 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:62098 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225317AbTK0MpD>; Thu, 27 Nov 2003 12:45:03 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 8797A4BFF3; Thu, 27 Nov 2003 13:45:00 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 7340847B6B; Thu, 27 Nov 2003 13:45:00 +0100 (CET)
Date: Thu, 27 Nov 2003 13:45:00 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Daniel Jacobowitz <dan@debian.org>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] 2.4, head: PAGE_SHIFT changes break glibc
In-Reply-To: <20031126170228.GA13116@nevyn.them.org>
Message-ID: <Pine.LNX.4.55.0311271319470.22529@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0311211550270.32551@jurand.ds.pg.gda.pl>
 <20031121185035.GC8318@linux-mips.org> <Pine.LNX.4.55.0311212021420.32551@jurand.ds.pg.gda.pl>
 <Pine.LNX.4.55.0311251623180.6716@jurand.ds.pg.gda.pl>
 <20031125232439.GE11047@linux-mips.org> <Pine.LNX.4.55.0311260103320.6716@jurand.ds.pg.gda.pl>
 <20031126170228.GA13116@nevyn.them.org>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3684
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 26 Nov 2003, Daniel Jacobowitz wrote:

> >  I suppose so, although being not that fond of insane numbers of syscalls
> > I wonder how sysdeps/unix/sysv/linux/ia64/getpagesize.c gets away with
> > static binaries...  Perhaps we should ask glibc hackers?
> 
> Look at elf/dl-support.c:_dl_aux_init? dl_pagesize should end up
> initialized for static binaries too.

 Thanks for the hint.  I can see _dl_aux_init() gets indeed called from
__libc_start_main() in my i386/Linux libc-start.o binary (in libc.a), but
it does not in my MIPSel/Linux one.  So there must be a bug somewhere in
2.2.5, perhaps fixed later.  I'll have a look at it.  Once fixed, I
guess we should choose the IA64 way.

 After a brief look at the sources I suspect sysdeps/mips/elf/ldsodefs.h
overrides sysdeps/unix/sysv/linux/ldsodefs.h -- if that's the case, the
bug still exists in the trunk.  I'll work on a fix later, probably
tonight.

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

From vbridgers@bandspeed.com Fri Nov 28 14:45:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Nov 2003 14:45:41 +0000 (GMT)
Received: from mail.bandspeed.com ([IPv6:::ffff:64.132.226.131]:1195 "EHLO
	mars.bandspeed.com") by linux-mips.org with ESMTP
	id <S8225400AbTK0N1Q> convert rfc822-to-8bit; Thu, 27 Nov 2003 13:27:16 +0000
content-class: urn:content-classes:message
Subject: backtrace issues on GDB 5.3
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 8BIT
Date: Thu, 27 Nov 2003 07:26:59 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Message-ID: <F2DE90354F0ED94EB7061060D9396547B98C49@mars.bandspeed.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: backtrace issues on GDB 5.3
Thread-Index: AcO06iLglOKw2qswQWuRtPF/fvsCnw==
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: 3685
X-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

I'm using GDB 5.3 for mipsel cross-compiled on an x86 box running RedHat
7.3. When I try to use the backtrace capability from GDB most of the
time I do not get a full stack context - I usually just get the function
I'm in at the time. I'm using GCC 3.2 to compile the kernel,
cross-compiled the same way. I've tried making sure the
omit-frame-pointer option and the "no instruction schedule" options are
on for when we do source level debugging with no joy.  

Does backtrace work for GCC and GDB cross compiled for mipsel? If so,
can someone briefly outline the "known good" configuration (GCC/GDB
versions, + relevant configuration options)?

TIA

From drow@crack.them.org Fri Nov 28 14:46:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Nov 2003 14:46:27 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:34713 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225425AbTK0RhW>;
	Thu, 27 Nov 2003 17:37:22 +0000
Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian))
	id 1APQ4o-0006oJ-8V; Thu, 27 Nov 2003 12:37:14 -0500
Date: Thu, 27 Nov 2003 12:37:14 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] 2.4, head: PAGE_SHIFT changes break glibc
Message-ID: <20031127173714.GA26143@nevyn.them.org>
References: <Pine.LNX.4.55.0311211550270.32551@jurand.ds.pg.gda.pl> <20031121185035.GC8318@linux-mips.org> <Pine.LNX.4.55.0311212021420.32551@jurand.ds.pg.gda.pl> <Pine.LNX.4.55.0311251623180.6716@jurand.ds.pg.gda.pl> <20031125232439.GE11047@linux-mips.org> <Pine.LNX.4.55.0311260103320.6716@jurand.ds.pg.gda.pl> <20031126170228.GA13116@nevyn.them.org> <Pine.LNX.4.55.0311271319470.22529@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0311271319470.22529@jurand.ds.pg.gda.pl>
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: 3686
X-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 Thu, Nov 27, 2003 at 01:45:00PM +0100, Maciej W. Rozycki wrote:
> On Wed, 26 Nov 2003, Daniel Jacobowitz wrote:
> 
> > >  I suppose so, although being not that fond of insane numbers of syscalls
> > > I wonder how sysdeps/unix/sysv/linux/ia64/getpagesize.c gets away with
> > > static binaries...  Perhaps we should ask glibc hackers?
> > 
> > Look at elf/dl-support.c:_dl_aux_init? dl_pagesize should end up
> > initialized for static binaries too.
> 
>  Thanks for the hint.  I can see _dl_aux_init() gets indeed called from
> __libc_start_main() in my i386/Linux libc-start.o binary (in libc.a), but
> it does not in my MIPSel/Linux one.  So there must be a bug somewhere in
> 2.2.5, perhaps fixed later.  I'll have a look at it.  Once fixed, I
> guess we should choose the IA64 way.
> 
>  After a brief look at the sources I suspect sysdeps/mips/elf/ldsodefs.h
> overrides sysdeps/unix/sysv/linux/ldsodefs.h -- if that's the case, the
> bug still exists in the trunk.  I'll work on a fix later, probably
> tonight.

_dl_aux_init ought to be called from __libc_start_main in
sysdeps/generic/libc-start.c.  In current sources I can't see any way
for that to go wrong on MIPS (but my MIPS board is off right now so I
haven't tried it)...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From macro@ds2.pg.gda.pl Fri Nov 28 14:46:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Nov 2003 14:46:59 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:39588 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225444AbTK0Tbb>; Thu, 27 Nov 2003 19:31:31 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id D7B964AD81; Thu, 27 Nov 2003 20:31:18 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id B445147B41; Thu, 27 Nov 2003 20:31:18 +0100 (CET)
Date: Thu, 27 Nov 2003 20:31:18 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Daniel Jacobowitz <dan@debian.org>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] 2.4, head: PAGE_SHIFT changes break glibc
In-Reply-To: <20031127173714.GA26143@nevyn.them.org>
Message-ID: <Pine.LNX.4.55.0311272019070.9902@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0311211550270.32551@jurand.ds.pg.gda.pl>
 <20031121185035.GC8318@linux-mips.org> <Pine.LNX.4.55.0311212021420.32551@jurand.ds.pg.gda.pl>
 <Pine.LNX.4.55.0311251623180.6716@jurand.ds.pg.gda.pl>
 <20031125232439.GE11047@linux-mips.org> <Pine.LNX.4.55.0311260103320.6716@jurand.ds.pg.gda.pl>
 <20031126170228.GA13116@nevyn.them.org> <Pine.LNX.4.55.0311271319470.22529@jurand.ds.pg.gda.pl>
 <20031127173714.GA26143@nevyn.them.org>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3687
X-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, 27 Nov 2003, Daniel Jacobowitz wrote:

> >  After a brief look at the sources I suspect sysdeps/mips/elf/ldsodefs.h
> > overrides sysdeps/unix/sysv/linux/ldsodefs.h -- if that's the case, the
> > bug still exists in the trunk.  I'll work on a fix later, probably
> > tonight.
> 
> _dl_aux_init ought to be called from __libc_start_main in
> sysdeps/generic/libc-start.c.  In current sources I can't see any way
> for that to go wrong on MIPS (but my MIPS board is off right now so I
> haven't tried it)...

 I did a build of 2.2.5 and my suspicion got confirmed -- the exact 
command line to build libc-start.o is as follows:

mipsel-linux-gcc ../sysdeps/generic/libc-start.c -c -O2 -Wall -Winline
-Wstrict-prototypes -Wwrite-strings -pipe -fomit-frame-pointer -g0 -O99
-fomit-frame-pointer -D__USE_STRING_INLINES -I../include -I. -I..
-I../libio -I../sysdeps/mips/elf -I../linuxthreads/sysdeps/unix/sysv/linux
-I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../linuxthreads/sysdeps/mips -I../sysdeps/unix/sysv/linux/mips
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix/mips -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/mips/mipsel -I../sysdeps/mips/fpu -I../sysdeps/mips
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf
-I../sysdeps/generic -nostdinc -isystem
/usr/lib/gcc-lib/mipsel-linux/2.95.4/include -isystem
/home/macro/src/redhat/BUILD/glibc-2.2.5/linux/include -D_LIBC_REENTRANT
-include ../include/libc-symbols.h -DPIC -DHAVE_INITFINI -o libc-start.o

i.e. it's sysdeps/mips/elf/ldsodefs.h that gets included as a result of
"#include <ldsodefs.h>", not sysdeps/unix/sysv/linux/ldsodefs.h.  Then
sysdeps/mips/elf/ldsodefs.h uses "#include <sysdeps/generic/ldsodefs.h>"  
in 2.2.5, and "#include_next <ldsodefs.h>" in the trunk, so I'll just 
rebuild 2.2.5 with this change and consider the trunk fixed.

  Maciej

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

From anemo@mba.ocn.ne.jp Fri Nov 28 14:47:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Nov 2003 14:47:32 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:1546
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225466AbTK1Bhx>; Fri, 28 Nov 2003 01:37:53 +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; 28 Nov 2003 01:38:22 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id hAS1c9nd020200;
	Fri, 28 Nov 2003 10:38:10 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 28 Nov 2003 10:41:01 +0900 (JST)
Message-Id: <20031128.104101.48536414.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: please give ieee1394 a chance
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030517.215806.92590717.anemo@mba.ocn.ne.jp>
References: <20030517.215806.92590717.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: 3688
X-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

It's been a long time since I posted this request.  I believe there is
no reason to omit ieee1394 on mips.  Please add the line to 2.4 tree.
Thank you.

>>>>> On Sat, 17 May 2003 21:58:06 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
> Now ieee1394 drivers (at least ohci1394 and sbp2) will work on mips.
> Please give them a chance.
> 
> diff -u linux-mips-cvs/arch/mips/config-shared.in linux.new/arch/mips/
> --- linux-mips-cvs/arch/mips/config-shared.in	Mon May  5 21:31:50 2003
> +++ linux.new/arch/mips/config-shared.in	Sat May 17 21:50:35 2003
> @@ -876,6 +876,8 @@
>  fi
>  endmenu
> 
> +source drivers/ieee1394/Config.in
> +
>  if [ "$CONFIG_PCI" = "y" ]; then
>     source drivers/message/i2o/Config.in
>  fi
---
Atsushi Nemoto

From drow@crack.them.org Fri Nov 28 16:31:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Nov 2003 16:31:38 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:65439 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225258AbTK1Pep>;
	Fri, 28 Nov 2003 15:34:45 +0000
Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian))
	id 1APkdm-0001jC-Me; Fri, 28 Nov 2003 10:34:42 -0500
Date: Fri, 28 Nov 2003 10:34:42 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Vince Bridgers <vbridgers@bandspeed.com>
Cc: linux-mips@linux-mips.org
Subject: Re: backtrace issues on GDB 5.3
Message-ID: <20031128153442.GA6624@nevyn.them.org>
References: <F2DE90354F0ED94EB7061060D9396547B98C49@mars.bandspeed.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F2DE90354F0ED94EB7061060D9396547B98C49@mars.bandspeed.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: 3689
X-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 Thu, Nov 27, 2003 at 07:26:59AM -0600, Vince Bridgers wrote:
> I'm using GDB 5.3 for mipsel cross-compiled on an x86 box running RedHat
> 7.3. When I try to use the backtrace capability from GDB most of the
> time I do not get a full stack context - I usually just get the function
> I'm in at the time. I'm using GCC 3.2 to compile the kernel,
> cross-compiled the same way. I've tried making sure the
> omit-frame-pointer option and the "no instruction schedule" options are
> on for when we do source level debugging with no joy.  
> 
> Does backtrace work for GCC and GDB cross compiled for mipsel? If so,
> can someone briefly outline the "known good" configuration (GCC/GDB
> versions, + relevant configuration options)?

Not excellently, but definitely better - try the most recent GDB
release.

I have a number of ugly local patches that I hope to clean up for 6.1,
if I have time.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ralf@linux-mips.org Fri Nov 28 19:28:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Nov 2003 19:28:47 +0000 (GMT)
Received: from p508B6A2F.dip.t-dialin.net ([IPv6:::ffff:80.139.106.47]:20364
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225489AbTK1T2q>; Fri, 28 Nov 2003 19:28:46 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id hASJShA0022475;
	Fri, 28 Nov 2003 20:28:43 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hASJSdAA022471;
	Fri, 28 Nov 2003 20:28:39 +0100
Date: Fri, 28 Nov 2003 20:28:39 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: please give ieee1394 a chance
Message-ID: <20031128192839.GB3637@linux-mips.org>
References: <20030517.215806.92590717.anemo@mba.ocn.ne.jp> <20031128.104101.48536414.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031128.104101.48536414.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3690
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Nov 28, 2003 at 10:41:01AM +0900, Atsushi Nemoto wrote:

> It's been a long time since I posted this request.  I believe there is
> no reason to omit ieee1394 on mips.  Please add the line to 2.4 tree.
> Thank you.

Done,

  Ralf