From redhatter@gentoo.org Sat Oct 1 03:56:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Oct 2005 03:56:28 +0100 (BST) Received: from 202-47-55-78.adsl.gil.com.au ([202.47.55.78]:49590 "EHLO longlandclan.hopto.org") by ftp.linux-mips.org with ESMTP id S3465602AbVJAC4L (ORCPT ); Sat, 1 Oct 2005 03:56:11 +0100 Received: (qmail 4278 invoked by uid 210); 1 Oct 2005 12:55:14 +1000 Received: from 10.0.0.251 by www (envelope-from , uid 201) with qmail-scanner-1.25st (spamassassin: 3.0.4. perlscan: 1.25st. Clear:RC:1(10.0.0.251):. Processed in 0.138133 secs); 01 Oct 2005 02:55:14 -0000 Received: from beast.redhatters.home (HELO ?10.0.0.251?) (10.0.0.251) by 192.168.5.1 with SMTP; 1 Oct 2005 12:55:13 +1000 Message-ID: <433DFA95.70705@gentoo.org> Date: Sat, 01 Oct 2005 12:55:17 +1000 From: Stuart Longland Organization: Gentoo Foundation User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: oski CC: linux-mips@linux-mips.org Subject: Re: Compiling a kernel for ibm z50 References: <20050928183731.GA18480@linux-mips.org> <433CD36E.7040807@gentoo.org> In-Reply-To: X-Enigmail-Version: 0.91.0.0 OpenPGP: id=63264AB9; url=http://dev.gentoo.org/~redhatter/gpgkey.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB2DE53FAECC018A762F91AC" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: redhatter@gentoo.org Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB2DE53FAECC018A762F91AC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit oski wrote: > Hi, > > I realised something was not OK when trying to make zImage or make stripped > i gor the warning that not rule were available. I need an small kernel able > to boot from the msdos partition of my microdrive using hpcboot. A big > kernel will be a waste of space in the microdrive. > > Anyway after make clean I can not find vmlinux anywhere, I was expecting it > to be in arch/mips/boot but nothing there. Any ideas? > > many thanks > > oski Look in the linux/ directory, not the linux/arch/mips/boot/ directory. :-) You know -- the one you ran `make vmlinux` in. ;-) The latter directory is an x86-ism -- we don't do things that way on MIPS. :-) -- ____ _ Stuart Longland (a.k.a Redhatter) / _ \ ___ ___ __| |__ __ __ Gentoo Linux/MIPS Cobalt and Docs - (_) \ / \ ; \(__ __)/ \ / \ Developer \ // O _| / /\ \ | | | /\ | /\ | / / \ /__| / \ \ | | | \/ | \/ | (___/ \____/|_; |_| \_/ \__/ \__/ http://dev.gentoo.org/~redhatter --------------enigEB2DE53FAECC018A762F91AC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDPfqYuarJ1mMmSrkRAnwgAJ9i+XmXTeIcncfW4j8UzyGmv/aDpACdExBm 0ZkxIc3s6NYXpT8TTdzwmOg= =PXib -----END PGP SIGNATURE----- --------------enigEB2DE53FAECC018A762F91AC-- From ravdberg@inter.NL.net Sat Oct 1 14:45:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Oct 2005 14:45:49 +0100 (BST) Received: from vmx15.multikabel.net ([212.127.254.144]:4030 "EHLO vmx15.multikabel.net") by ftp.linux-mips.org with ESMTP id S3465581AbVJANpb (ORCPT ); Sat, 1 Oct 2005 14:45:31 +0100 Received: from vmx20.multikabel.net ([212.127.254.137]) by vmx15.multikabel.net with esmtp (Exim 4.44) id 1ELhg8-0001Ac-Jv for linux-mips@linux-mips.org; Sat, 01 Oct 2005 15:45:28 +0200 Received: from whale.dutch.mountain (82-217-198-100.cable.quicknet.nl [82.217.198.100]) by vmx20.multikabel.net (8.13.3/8.13.3) with ESMTP id j91DjL6N031835 for ; Sat, 1 Oct 2005 15:45:27 +0200 Received: from (locally authorised broken client using invalid hostname!) localhost (really [127.0.0.1]) by inter.NL.net via in.smtpd with esmtp (ident ravdberg using rfc1413) id (Debian Smail3.2.0.114) Sat, 1 Oct 2005 15:45:22 +0200 (CEST) Date: Sat, 1 Oct 2005 15:45:21 +0200 (CEST) From: Richard van den Berg X-X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@linux-mips.org Subject: 3 DECstations for free pickup in The Netherlands Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MultiKabel-MailScanner-Information: Please contact helpdesk@quicknet.nl for more information X-MultiKabel-MailScanner: Found to be clean X-MultiKabel-MailScanner-SpamCheck: not spam X-MultiKabel-MX-MailScanner-Information: Please contact helpdesk@quicknet.nl for more information X-MultiKabel-MX-MailScanner: Found to be clean X-MultiKabel-MX-MailScanner-SpamCheck: X-MailScanner-From: ravdberg@inter.nl.net Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9106 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ravdberg@inter.NL.net Precedence: bulk X-list: linux-mips L.S. I have 3 DECstations to give away: 1 DECstation 5000/133 2 DECstations 5000/25 Located near Alkmaar. Contact me for details if you're interested. Regards, Richard From ppopov@embeddedalley.com Sat Oct 1 14:51:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Oct 2005 14:52:01 +0100 (BST) Received: from smtp103.biz.mail.mud.yahoo.com ([68.142.200.238]:3254 "HELO smtp103.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S3465578AbVJANvq (ORCPT ); Sat, 1 Oct 2005 14:51:46 +0100 Received: (qmail 81420 invoked from network); 1 Oct 2005 13:51:39 -0000 Received: from unknown (HELO ?192.168.1.111?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp103.biz.mail.mud.yahoo.com with SMTP; 1 Oct 2005 13:51:39 -0000 Subject: free O2 From: Pete Popov Reply-To: ppopov@embeddedalley.com To: "'linux-mips@linux-mips.org'" Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Sat, 01 Oct 2005 06:51:24 -0700 Message-Id: <1128174684.25046.31.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9107 X-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@embeddedalley.com Precedence: bulk X-list: linux-mips I have one O2 to give away, including keyboard and mouse, no monitor. Located in Santa Clara, CA, USA. Contact me if you're interested. Pete From yuasa@hh.iij4u.or.jp Sat Oct 1 18:32:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Oct 2005 18:32:45 +0100 (BST) Received: from mo01.iij4u.or.jp ([210.130.0.20]:5830 "EHLO mo01.iij4u.or.jp") by ftp.linux-mips.org with ESMTP id S3465605AbVJARcV (ORCPT ); Sat, 1 Oct 2005 18:32:21 +0100 Received: MO(mo01)id j91HWHX6022661; Sun, 2 Oct 2005 02:32:17 +0900 (JST) Received: MDO(mdo00) id j91HWGxI007258; Sun, 2 Oct 2005 02:32:16 +0900 (JST) Received: from stratos (h195.p501.iij4u.or.jp [210.149.245.195]) by mbox.iij4u.or.jp (4U-MR/mbox01) id j91HWEDZ013635 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 2 Oct 2005 02:32:15 +0900 (JST) Date: Sun, 2 Oct 2005 02:32:13 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH] vr41xx: update defconfig Message-Id: <20051002023213.61de0f26.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9108 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, I had updated vr41xx machine's defconfig. Please apply. Yoichi Signed-off-by: Yoichi Yuasa diff -urN -X dontdiff a-orig/arch/mips/configs/capcella_defconfig a/arch/mips/configs/capcella_defconfig --- a-orig/arch/mips/configs/capcella_defconfig 2005-10-01 00:31:06.000000000 +0900 +++ a/arch/mips/configs/capcella_defconfig 2005-10-02 01:10:01.000000000 +0900 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.14-rc2 -# Thu Sep 22 02:15:28 2005 +# Sun Oct 2 00:59:18 2005 # CONFIG_MIPS=y @@ -119,7 +119,7 @@ # CONFIG_VICTOR_MPC30X is not set CONFIG_ZAO_CAPCELLA=y CONFIG_PCI_VR41XX=y -CONFIG_VRC4173=y +# CONFIG_VRC4173 is not set CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_DMA_NONCOHERENT=y @@ -327,9 +327,7 @@ # CONFIG_BLK_DEV_RAM is not set CONFIG_BLK_DEV_RAM_COUNT=16 # CONFIG_LBD is not set -CONFIG_CDROM_PKTCDVD=m -CONFIG_CDROM_PKTCDVD_BUFFERS=8 -# CONFIG_CDROM_PKTCDVD_WCACHE is not set +# CONFIG_CDROM_PKTCDVD is not set # # IO Schedulers @@ -370,7 +368,7 @@ # # SCSI device support # -CONFIG_RAID_ATTRS=m +# CONFIG_RAID_ATTRS is not set # CONFIG_SCSI is not set # @@ -426,7 +424,7 @@ # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y -# CONFIG_MII is not set +CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set @@ -436,7 +434,30 @@ # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set -# CONFIG_NET_PCI is not set +CONFIG_NET_PCI=y +# CONFIG_PCNET32 is not set +# CONFIG_AMD8111_ETH is not set +# CONFIG_ADAPTEC_STARFIRE is not set +# CONFIG_B44 is not set +# CONFIG_FORCEDETH is not set +# CONFIG_DGRS is not set +# CONFIG_EEPRO100 is not set +# CONFIG_E100 is not set +# CONFIG_FEALNX is not set +# CONFIG_NATSEMI is not set +# CONFIG_NE2K_PCI is not set +# CONFIG_8139CP is not set +CONFIG_8139TOO=y +CONFIG_8139TOO_PIO=y +# CONFIG_8139TOO_TUNE_TWISTER is not set +# CONFIG_8139TOO_8129 is not set +# CONFIG_8139_OLD_RX_RESET is not set +# CONFIG_SIS900 is not set +# CONFIG_EPIC100 is not set +# CONFIG_SUNDANCE is not set +# CONFIG_TLAN is not set +# CONFIG_VIA_RHINE is not set +# CONFIG_LAN_SAA9730 is not set # # Ethernet (1000 Mbit) @@ -451,6 +472,7 @@ # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SK98LIN is not set +# CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set @@ -504,10 +526,7 @@ # # Userland interfaces # -CONFIG_INPUT_MOUSEDEV=y -CONFIG_INPUT_MOUSEDEV_PSAUX=y -CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 -CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 +# CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set @@ -525,12 +544,7 @@ # # Hardware I/O ports # -CONFIG_SERIO=y -CONFIG_SERIO_I8042=y -CONFIG_SERIO_SERPORT=y -# CONFIG_SERIO_PCIPS2 is not set -CONFIG_SERIO_LIBPS2=m -CONFIG_SERIO_RAW=m +# CONFIG_SERIO is not set # CONFIG_GAMEPORT is not set # @@ -544,17 +558,15 @@ # # Serial drivers # -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y -CONFIG_SERIAL_8250_NR_UARTS=4 -# CONFIG_SERIAL_8250_EXTENDED is not set +# CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y -# CONFIG_SERIAL_VR41XX is not set +CONFIG_SERIAL_VR41XX=y +CONFIG_SERIAL_VR41XX_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y @@ -568,19 +580,7 @@ # # Watchdog Cards # -CONFIG_WATCHDOG=y -# CONFIG_WATCHDOG_NOWAYOUT is not set - -# -# Watchdog Device Drivers -# -# CONFIG_SOFT_WATCHDOG is not set - -# -# PCI-based Watchdog Cards -# -# CONFIG_PCIPCWATCHDOG is not set -# CONFIG_WDTPCI is not set +# CONFIG_WATCHDOG is not set # CONFIG_RTC is not set # CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set @@ -591,7 +591,7 @@ # Ftape, the floppy tape device driver # # CONFIG_DRM is not set -# CONFIG_GPIO_VR41XX is not set +CONFIG_GPIO_VR41XX=y # CONFIG_RAW_DRIVER is not set # @@ -784,7 +784,7 @@ # CONFIG_DEBUG_KERNEL is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_CROSSCOMPILE=y -CONFIG_CMDLINE="" +CONFIG_CMDLINE="mem=32M console=ttyVR0,38400" # # Security options @@ -831,7 +831,7 @@ # # CONFIG_CRC_CCITT is not set CONFIG_CRC16=m -CONFIG_CRC32=m +CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m diff -urN -X dontdiff a-orig/arch/mips/configs/e55_defconfig a/arch/mips/configs/e55_defconfig --- a-orig/arch/mips/configs/e55_defconfig 2005-10-01 00:31:16.000000000 +0900 +++ a/arch/mips/configs/e55_defconfig 2005-10-02 00:48:50.000000000 +0900 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.14-rc2 -# Thu Sep 22 02:16:01 2005 +# Sun Oct 2 00:48:30 2005 # CONFIG_MIPS=y @@ -315,9 +315,7 @@ # CONFIG_BLK_DEV_RAM is not set CONFIG_BLK_DEV_RAM_COUNT=16 # CONFIG_LBD is not set -CONFIG_CDROM_PKTCDVD=m -CONFIG_CDROM_PKTCDVD_BUFFERS=8 -# CONFIG_CDROM_PKTCDVD_WCACHE is not set +# CONFIG_CDROM_PKTCDVD is not set # # IO Schedulers @@ -326,7 +324,7 @@ CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y -CONFIG_ATA_OVER_ETH=m +# CONFIG_ATA_OVER_ETH is not set # # ATA/ATAPI/MFM/RLL support @@ -358,7 +356,7 @@ # # SCSI device support # -CONFIG_RAID_ATTRS=m +# CONFIG_RAID_ATTRS is not set # CONFIG_SCSI is not set # @@ -477,8 +475,8 @@ # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y -CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 -CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 +CONFIG_INPUT_MOUSEDEV_SCREEN_X=320 +CONFIG_INPUT_MOUSEDEV_SCREEN_Y=240 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set @@ -497,7 +495,7 @@ # Hardware I/O ports # CONFIG_SERIO=y -CONFIG_SERIO_I8042=y +# CONFIG_SERIO_I8042 is not set CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_LIBPS2 is not set CONFIG_SERIO_RAW=m @@ -514,17 +512,15 @@ # # Serial drivers # -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y -CONFIG_SERIAL_8250_NR_UARTS=4 -# CONFIG_SERIAL_8250_EXTENDED is not set +# CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y -# CONFIG_SERIAL_VR41XX is not set +CONFIG_SERIAL_VR41XX=y +CONFIG_SERIAL_VR41XX_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 @@ -559,7 +555,7 @@ # # Ftape, the floppy tape device driver # -# CONFIG_GPIO_VR41XX is not set +CONFIG_GPIO_VR41XX=y # CONFIG_RAW_DRIVER is not set # @@ -706,17 +702,17 @@ # # Network File Systems # -CONFIG_NFS_FS=y +CONFIG_NFS_FS=m # CONFIG_NFS_V3 is not set # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set -CONFIG_NFSD=y +CONFIG_NFSD=m # CONFIG_NFSD_V3 is not set # CONFIG_NFSD_TCP is not set -CONFIG_LOCKD=y -CONFIG_EXPORTFS=y +CONFIG_LOCKD=m +CONFIG_EXPORTFS=m CONFIG_NFS_COMMON=y -CONFIG_SUNRPC=y +CONFIG_SUNRPC=m # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set # CONFIG_SMB_FS is not set @@ -749,7 +745,7 @@ # CONFIG_DEBUG_KERNEL is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_CROSSCOMPILE=y -CONFIG_CMDLINE="" +CONFIG_CMDLINE="console=ttyVR0,19200 mem=8M" # # Security options diff -urN -X dontdiff a-orig/arch/mips/configs/mpc30x_defconfig a/arch/mips/configs/mpc30x_defconfig --- a-orig/arch/mips/configs/mpc30x_defconfig 2005-10-01 00:31:23.000000000 +0900 +++ a/arch/mips/configs/mpc30x_defconfig 2005-10-02 01:17:36.000000000 +0900 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.14-rc2 -# Thu Sep 22 02:16:38 2005 +# Sun Oct 2 01:17:03 2005 # CONFIG_MIPS=y @@ -194,7 +194,21 @@ # # PCCARD (PCMCIA/CardBus) support # -# CONFIG_PCCARD is not set +CONFIG_PCCARD=y +# CONFIG_PCMCIA_DEBUG is not set +CONFIG_PCMCIA=y +CONFIG_PCMCIA_LOAD_CIS=y +CONFIG_PCMCIA_IOCTL=y +# CONFIG_CARDBUS is not set + +# +# PC-card bridges +# +# CONFIG_YENTA is not set +# CONFIG_PD6729 is not set +# CONFIG_I82092 is not set +# CONFIG_TCIC is not set +CONFIG_PCMCIA_VRC4173=y # # PCI Hotplug Support @@ -226,10 +240,7 @@ CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y -CONFIG_IP_PNP=y -# CONFIG_IP_PNP_DHCP is not set -CONFIG_IP_PNP_BOOTP=y -# CONFIG_IP_PNP_RARP is not set +# CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set @@ -292,7 +303,7 @@ # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y -CONFIG_FW_LOADER=m +CONFIG_FW_LOADER=y # # Connector - unified userspace <-> kernelspace linker @@ -324,12 +335,11 @@ # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set CONFIG_BLK_DEV_RAM_COUNT=16 # CONFIG_LBD is not set -CONFIG_CDROM_PKTCDVD=m -CONFIG_CDROM_PKTCDVD_BUFFERS=8 -# CONFIG_CDROM_PKTCDVD_WCACHE is not set +# CONFIG_CDROM_PKTCDVD is not set # # IO Schedulers @@ -343,12 +353,35 @@ # # ATA/ATAPI/MFM/RLL support # -# CONFIG_IDE is not set +CONFIG_IDE=y +CONFIG_BLK_DEV_IDE=y + +# +# Please see Documentation/ide.txt for help/info on IDE drives +# +# CONFIG_BLK_DEV_IDE_SATA is not set +CONFIG_BLK_DEV_IDEDISK=y +# CONFIG_IDEDISK_MULTI_MODE is not set +CONFIG_BLK_DEV_IDECS=m +# CONFIG_BLK_DEV_IDECD is not set +# CONFIG_BLK_DEV_IDETAPE is not set +# CONFIG_BLK_DEV_IDEFLOPPY is not set +# CONFIG_IDE_TASK_IOCTL is not set + +# +# IDE chipset support/bugfixes +# +CONFIG_IDE_GENERIC=y +# CONFIG_BLK_DEV_IDEPCI is not set +# CONFIG_IDE_ARM is not set +# CONFIG_BLK_DEV_IDEDMA is not set +# CONFIG_IDEDMA_AUTO is not set +# CONFIG_BLK_DEV_HD is not set # # SCSI device support # -CONFIG_RAID_ATTRS=m +# CONFIG_RAID_ATTRS is not set # CONFIG_SCSI is not set # @@ -388,33 +421,12 @@ # # PHY device support # -CONFIG_PHYLIB=m -CONFIG_PHYCONTROL=y - -# -# MII PHY device drivers -# -CONFIG_MARVELL_PHY=m -CONFIG_DAVICOM_PHY=m -CONFIG_QSEMI_PHY=m -CONFIG_LXT_PHY=m -CONFIG_CICADA_PHY=m # # Ethernet (10 or 100Mbit) # -CONFIG_NET_ETHERNET=y -# CONFIG_MII is not set -# CONFIG_HAPPYMEAL is not set -# CONFIG_SUNGEM is not set -# CONFIG_NET_VENDOR_3COM is not set - -# -# Tulip family network device support -# -# CONFIG_NET_TULIP is not set -# CONFIG_HP100 is not set -# CONFIG_NET_PCI is not set +# CONFIG_NET_ETHERNET is not set +CONFIG_MII=m # # Ethernet (1000 Mbit) @@ -447,9 +459,59 @@ # # Wireless LAN (non-hamradio) # -# CONFIG_NET_RADIO is not set -# CONFIG_IPW_DEBUG is not set -CONFIG_IPW2200=m +CONFIG_NET_RADIO=y + +# +# Obsolete Wireless cards support (pre-802.11) +# +# CONFIG_STRIP is not set +# CONFIG_PCMCIA_WAVELAN is not set +# CONFIG_PCMCIA_NETWAVE is not set + +# +# Wireless 802.11 Frequency Hopping cards support +# +# CONFIG_PCMCIA_RAYCS is not set + +# +# Wireless 802.11b ISA/PCI cards support +# +# CONFIG_IPW2100 is not set +# CONFIG_IPW2200 is not set +CONFIG_HERMES=m +# CONFIG_PLX_HERMES is not set +# CONFIG_TMD_HERMES is not set +# CONFIG_NORTEL_HERMES is not set +# CONFIG_PCI_HERMES is not set +# CONFIG_ATMEL is not set + +# +# Wireless 802.11b Pcmcia/Cardbus cards support +# +CONFIG_PCMCIA_HERMES=m +# CONFIG_PCMCIA_SPECTRUM is not set +# CONFIG_AIRO_CS is not set +# CONFIG_PCMCIA_WL3501 is not set + +# +# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support +# +# CONFIG_PRISM54 is not set +# CONFIG_HOSTAP is not set +CONFIG_NET_WIRELESS=y + +# +# PCMCIA network device support +# +CONFIG_NET_PCMCIA=y +CONFIG_PCMCIA_3C589=m +CONFIG_PCMCIA_3C574=m +CONFIG_PCMCIA_FMVJ18X=m +CONFIG_PCMCIA_PCNET=m +CONFIG_PCMCIA_NMCLAN=m +CONFIG_PCMCIA_SMC91C92=m +CONFIG_PCMCIA_XIRC2PS=m +CONFIG_PCMCIA_AXNET=m # # Wan interfaces @@ -504,7 +566,7 @@ # Hardware I/O ports # CONFIG_SERIO=y -CONFIG_SERIO_I8042=y +# CONFIG_SERIO_I8042 is not set CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_PCIPS2 is not set # CONFIG_SERIO_LIBPS2 is not set @@ -522,17 +584,15 @@ # # Serial drivers # -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y -CONFIG_SERIAL_8250_NR_UARTS=4 -# CONFIG_SERIAL_8250_EXTENDED is not set +# CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y -# CONFIG_SERIAL_VR41XX is not set +CONFIG_SERIAL_VR41XX=y +CONFIG_SERIAL_VR41XX_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y @@ -557,7 +617,12 @@ # Ftape, the floppy tape device driver # # CONFIG_DRM is not set -# CONFIG_GPIO_VR41XX is not set + +# +# PCMCIA character devices +# +# CONFIG_SYNCLINK_CS is not set +CONFIG_GPIO_VR41XX=y # CONFIG_RAW_DRIVER is not set # @@ -620,7 +685,118 @@ # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y -# CONFIG_USB is not set +CONFIG_USB=m +# CONFIG_USB_DEBUG is not set + +# +# Miscellaneous USB options +# +CONFIG_USB_DEVICEFS=y +# CONFIG_USB_BANDWIDTH is not set +# CONFIG_USB_DYNAMIC_MINORS is not set +# CONFIG_USB_OTG is not set + +# +# USB Host Controller Drivers +# +# CONFIG_USB_EHCI_HCD is not set +# CONFIG_USB_ISP116X_HCD is not set +CONFIG_USB_OHCI_HCD=m +# CONFIG_USB_OHCI_BIG_ENDIAN is not set +CONFIG_USB_OHCI_LITTLE_ENDIAN=y +# CONFIG_USB_UHCI_HCD is not set +# CONFIG_USB_SL811_HCD is not set + +# +# USB Device Class drivers +# +# CONFIG_USB_BLUETOOTH_TTY is not set +# CONFIG_USB_ACM is not set +# CONFIG_USB_PRINTER is not set + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information +# +# CONFIG_USB_STORAGE is not set + +# +# USB Input Devices +# +# CONFIG_USB_HID is not set + +# +# USB HID Boot Protocol drivers +# +# 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_ACECAD is not set +# CONFIG_USB_KBTAB is not set +# CONFIG_USB_POWERMATE is not set +# CONFIG_USB_MTOUCH is not set +# CONFIG_USB_ITMTOUCH is not set +# CONFIG_USB_EGALAX is not set +# CONFIG_USB_YEALINK is not set +# CONFIG_USB_XPAD is not set +# CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_KEYSPAN_REMOTE is not set +# CONFIG_USB_APPLETOUCH is not set + +# +# USB Imaging devices +# +# CONFIG_USB_MDC800 is not set + +# +# USB Multimedia devices +# +# CONFIG_USB_DABUSB is not set + +# +# Video4Linux support is needed for USB Multimedia device support +# + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +CONFIG_USB_PEGASUS=m +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET is not set +# CONFIG_USB_ZD1201 is not set +# CONFIG_USB_MON is not set + +# +# USB port drivers +# + +# +# USB Serial Converter support +# +# CONFIG_USB_SERIAL is not set + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_EMI62 is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_AUERSWALD is not set +# CONFIG_USB_RIO500 is not set +# CONFIG_USB_LEGOTOWER is not set +# CONFIG_USB_LCD is not set +# CONFIG_USB_LED is not set +# CONFIG_USB_CYTHERM is not set +# CONFIG_USB_PHIDGETKIT is not set +# CONFIG_USB_PHIDGETSERVO is not set +# CONFIG_USB_IDMOUSE is not set +# CONFIG_USB_LD is not set +# CONFIG_USB_TEST is not set + +# +# USB DSL modem support +# # # USB Gadget Support @@ -711,7 +887,6 @@ # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set # CONFIG_NFSD is not set -CONFIG_ROOT_NFS=y CONFIG_LOCKD=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y @@ -747,7 +922,7 @@ # CONFIG_DEBUG_KERNEL is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_CROSSCOMPILE=y -CONFIG_CMDLINE="" +CONFIG_CMDLINE="mem=32M console=ttyVR0,19200" # # Security options @@ -794,7 +969,7 @@ # # CONFIG_CRC_CCITT is not set CONFIG_CRC16=m -CONFIG_CRC32=m +CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m diff -urN -X dontdiff a-orig/arch/mips/configs/tb0226_defconfig a/arch/mips/configs/tb0226_defconfig --- a-orig/arch/mips/configs/tb0226_defconfig 2005-10-01 00:31:35.000000000 +0900 +++ a/arch/mips/configs/tb0226_defconfig 2005-10-02 01:40:41.000000000 +0900 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.14-rc2 -# Thu Sep 22 02:17:33 2005 +# Sun Oct 2 01:23:35 2005 # CONFIG_MIPS=y @@ -115,13 +115,20 @@ # CONFIG_NEC_CMBVR4133 is not set # CONFIG_CASIO_E55 is not set # CONFIG_IBM_WORKPAD is not set -# CONFIG_TANBAC_TB022X is not set +CONFIG_TANBAC_TB022X=y +CONFIG_TANBAC_TB0226=y # CONFIG_VICTOR_MPC30X is not set # CONFIG_ZAO_CAPCELLA is not set +CONFIG_PCI_VR41XX=y +# CONFIG_VRC4173 is not set CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_DMA_NONCOHERENT=y +CONFIG_DMA_NEED_PCI_MAP_STATE=y # CONFIG_CPU_BIG_ENDIAN is not set -# CONFIG_CPU_LITTLE_ENDIAN is not set +CONFIG_CPU_LITTLE_ENDIAN=y +CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y +CONFIG_IRQ_CPU=y CONFIG_MIPS_L1_CACHE_SHIFT=5 # @@ -146,19 +153,22 @@ # CONFIG_CPU_RM7000 is not set # CONFIG_CPU_RM9000 is not set # CONFIG_CPU_SB1 is not set +CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y +CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y # # Kernel type # -# CONFIG_32BIT is not set +CONFIG_32BIT=y # CONFIG_64BIT is not set CONFIG_PAGE_SIZE_4KB=y # CONFIG_PAGE_SIZE_8KB is not set # CONFIG_PAGE_SIZE_16KB is not set # CONFIG_PAGE_SIZE_64KB is not set # CONFIG_MIPS_MT is not set +# CONFIG_CPU_ADVANCED is not set CONFIG_CPU_HAS_SYNC=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y @@ -177,6 +187,9 @@ # # Bus options (PCI, PCMCIA, EISA, ISA, TC) # +CONFIG_HW_HAS_PCI=y +CONFIG_PCI=y +# CONFIG_PCI_LEGACY_PROC is not set CONFIG_MMU=y # @@ -187,12 +200,14 @@ # # PCI Hotplug Support # +# CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set +CONFIG_TRAD_SIGNALS=y # # Networking @@ -308,16 +323,21 @@ # # Block devices # +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_NBD=m +# CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 -CONFIG_CDROM_PKTCDVD=m -CONFIG_CDROM_PKTCDVD_BUFFERS=8 -# CONFIG_CDROM_PKTCDVD_WCACHE is not set +# CONFIG_LBD is not set +# CONFIG_CDROM_PKTCDVD is not set # # IO Schedulers @@ -331,34 +351,12 @@ # # ATA/ATAPI/MFM/RLL support # -CONFIG_IDE=y -CONFIG_BLK_DEV_IDE=y - -# -# Please see Documentation/ide.txt for help/info on IDE drives -# -# CONFIG_BLK_DEV_IDE_SATA is not set -CONFIG_BLK_DEV_IDEDISK=y -CONFIG_IDEDISK_MULTI_MODE=y -# CONFIG_BLK_DEV_IDECD is not set -# CONFIG_BLK_DEV_IDETAPE is not set -# CONFIG_BLK_DEV_IDEFLOPPY is not set -CONFIG_BLK_DEV_IDESCSI=y -# CONFIG_IDE_TASK_IOCTL is not set - -# -# IDE chipset support/bugfixes -# -CONFIG_IDE_GENERIC=y -# CONFIG_IDE_ARM is not set -# CONFIG_BLK_DEV_IDEDMA is not set -# CONFIG_IDEDMA_AUTO is not set -# CONFIG_BLK_DEV_HD is not set +# CONFIG_IDE is not set # # SCSI device support # -CONFIG_RAID_ATTRS=m +# CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y @@ -368,16 +366,15 @@ CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set -CONFIG_BLK_DEV_SR=y -# CONFIG_BLK_DEV_SR_VENDOR is not set -CONFIG_CHR_DEV_SG=y +# CONFIG_BLK_DEV_SR is not set +# CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y -CONFIG_SCSI_CONSTANTS=y +# CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # @@ -386,12 +383,42 @@ # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set -CONFIG_SCSI_SAS_ATTRS=m +# CONFIG_SCSI_SAS_ATTRS is not set # # SCSI low-level drivers # +# CONFIG_BLK_DEV_3W_XXXX_RAID is not set +# CONFIG_SCSI_3W_9XXX is not set +# CONFIG_SCSI_ACARD is not set +# CONFIG_SCSI_AACRAID is not set +# CONFIG_SCSI_AIC7XXX is not set +# CONFIG_SCSI_AIC7XXX_OLD is not set +# CONFIG_SCSI_AIC79XX is not set +# CONFIG_SCSI_DPT_I2O is not set +# CONFIG_MEGARAID_NEWGEN is not set +# CONFIG_MEGARAID_LEGACY is not set # CONFIG_SCSI_SATA is not set +# CONFIG_SCSI_DMX3191D is not set +# CONFIG_SCSI_FUTURE_DOMAIN is not set +# CONFIG_SCSI_IPS is not set +# CONFIG_SCSI_INITIO is not set +# CONFIG_SCSI_INIA100 is not set +# CONFIG_SCSI_SYM53C8XX_2 is not set +# CONFIG_SCSI_IPR is not set +# CONFIG_SCSI_QLOGIC_FC is not set +# CONFIG_SCSI_QLOGIC_1280 is not set +CONFIG_SCSI_QLA2XXX=y +# CONFIG_SCSI_QLA21XX is not set +# CONFIG_SCSI_QLA22XX is not set +# CONFIG_SCSI_QLA2300 is not set +# CONFIG_SCSI_QLA2322 is not set +# CONFIG_SCSI_QLA6312 is not set +# CONFIG_SCSI_QLA24XX is not set +# CONFIG_SCSI_LPFC is not set +# CONFIG_SCSI_DC395x is not set +# CONFIG_SCSI_DC390T is not set +# CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # @@ -403,14 +430,18 @@ # Fusion MPT device support # # CONFIG_FUSION is not set +# CONFIG_FUSION_SPI is not set +# CONFIG_FUSION_FC is not set # # IEEE 1394 (FireWire) support # +# CONFIG_IEEE1394 is not set # # I2O device support # +# CONFIG_I2O is not set # # Network device support @@ -422,6 +453,11 @@ # CONFIG_TUN is not set # +# ARCnet devices +# +# CONFIG_ARCNET is not set + +# # PHY device support # CONFIG_PHYLIB=m @@ -440,38 +476,81 @@ # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y -# CONFIG_MII is not set +CONFIG_MII=y +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNGEM is not set +# CONFIG_NET_VENDOR_3COM is not set + +# +# Tulip family network device support +# +# CONFIG_NET_TULIP is not set +# CONFIG_HP100 is not set +CONFIG_NET_PCI=y +# CONFIG_PCNET32 is not set +# CONFIG_AMD8111_ETH is not set +# CONFIG_ADAPTEC_STARFIRE is not set +# CONFIG_B44 is not set +# CONFIG_FORCEDETH is not set +# CONFIG_DGRS is not set +CONFIG_EEPRO100=y +# CONFIG_E100 is not set +# CONFIG_FEALNX is not set +# CONFIG_NATSEMI is not set +# CONFIG_NE2K_PCI is not set +# CONFIG_8139CP is not set +# CONFIG_8139TOO is not set +# CONFIG_SIS900 is not set +# CONFIG_EPIC100 is not set +# CONFIG_SUNDANCE is not set +# CONFIG_TLAN is not set +# CONFIG_VIA_RHINE is not set +# CONFIG_LAN_SAA9730 is not set # # Ethernet (1000 Mbit) # +# CONFIG_ACENIC is not set +# CONFIG_DL2K is not set +# CONFIG_E1000 is not set +# CONFIG_NS83820 is not set +# CONFIG_HAMACHI is not set +# CONFIG_YELLOWFIN is not set +# CONFIG_R8169 is not set +# CONFIG_SIS190 is not set +# CONFIG_SKGE is not set +# CONFIG_SK98LIN is not set +# CONFIG_VIA_VELOCITY is not set +# CONFIG_TIGON3 is not set +# CONFIG_BNX2 is not set # # Ethernet (10000 Mbit) # +# CONFIG_CHELSIO_T1 is not set +# CONFIG_IXGB is not set +# CONFIG_S2IO is not set # # Token Ring devices # +# CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set +# CONFIG_IPW2200 is not set # # Wan interfaces # # CONFIG_WAN 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_FDDI is not set +# CONFIG_HIPPI is not set +# CONFIG_PPP is not set # CONFIG_SLIP is not set +# CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # CONFIG_NETPOLL is not set @@ -495,10 +574,7 @@ # # Userland interfaces # -CONFIG_INPUT_MOUSEDEV=y -CONFIG_INPUT_MOUSEDEV_PSAUX=y -CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 -CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 +# CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set @@ -516,11 +592,7 @@ # # Hardware I/O ports # -CONFIG_SERIO=y -CONFIG_SERIO_I8042=y -CONFIG_SERIO_SERPORT=y -# CONFIG_SERIO_LIBPS2 is not set -CONFIG_SERIO_RAW=m +# CONFIG_SERIO is not set # CONFIG_GAMEPORT is not set # @@ -534,17 +606,16 @@ # # Serial drivers # -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y -CONFIG_SERIAL_8250_NR_UARTS=4 -# CONFIG_SERIAL_8250_EXTENDED is not set +# CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y -# CONFIG_SERIAL_VR41XX is not set +CONFIG_SERIAL_VR41XX=y +CONFIG_SERIAL_VR41XX_CONSOLE=y +# CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 @@ -562,16 +633,20 @@ # CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set +# CONFIG_APPLICOM is not set +# CONFIG_TANBAC_TB0219 is not set # # Ftape, the floppy tape device driver # -# CONFIG_GPIO_VR41XX is not set +# CONFIG_DRM is not set +CONFIG_GPIO_VR41XX=y # CONFIG_RAW_DRIVER is not set # # TPM devices # +# CONFIG_TCG_TPM is not set # # I2C support @@ -610,50 +685,147 @@ # # Graphics support # -CONFIG_FB=y -# CONFIG_FB_CFB_FILLRECT is not set -# CONFIG_FB_CFB_COPYAREA is not set -# CONFIG_FB_CFB_IMAGEBLIT is not set -# CONFIG_FB_SOFT_CURSOR is not set -# CONFIG_FB_MACMODES is not set -# CONFIG_FB_MODE_HELPERS is not set -# CONFIG_FB_TILEBLITTING is not set -# CONFIG_FB_S1D13XXX is not set -# CONFIG_FB_VIRTUAL is not set +# CONFIG_FB is not set # # Console display driver support # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y -# CONFIG_FRAMEBUFFER_CONSOLE is not set # -# Logo configuration +# Sound # -# CONFIG_LOGO is not set -# CONFIG_BACKLIGHT_LCD_SUPPORT is not set +# CONFIG_SOUND is not set # -# Sound +# USB support # -CONFIG_SOUND=y +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +CONFIG_USB=y +# CONFIG_USB_DEBUG is not set # -# Advanced Linux Sound Architecture +# Miscellaneous USB options # -# CONFIG_SND is not set +CONFIG_USB_DEVICEFS=y +# CONFIG_USB_BANDWIDTH is not set +# CONFIG_USB_DYNAMIC_MINORS is not set +# CONFIG_USB_OTG is not set # -# Open Sound System +# USB Host Controller Drivers # -# CONFIG_SOUND_PRIME is not set +CONFIG_USB_EHCI_HCD=y +# CONFIG_USB_EHCI_SPLIT_ISO is not set +# CONFIG_USB_EHCI_ROOT_HUB_TT is not set +# CONFIG_USB_ISP116X_HCD is not set +CONFIG_USB_OHCI_HCD=y +# CONFIG_USB_OHCI_BIG_ENDIAN is not set +CONFIG_USB_OHCI_LITTLE_ENDIAN=y +# CONFIG_USB_UHCI_HCD is not set +# CONFIG_USB_SL811_HCD is not set # -# USB support +# USB Device Class drivers +# +# CONFIG_USB_BLUETOOTH_TTY is not set +# CONFIG_USB_ACM is not set +# CONFIG_USB_PRINTER is not set + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information +# +CONFIG_USB_STORAGE=m +# CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_DATAFAB is not set +# CONFIG_USB_STORAGE_FREECOM is not set +# CONFIG_USB_STORAGE_DPCM is not set +# CONFIG_USB_STORAGE_USBAT is not set +# CONFIG_USB_STORAGE_SDDR09 is not set +# CONFIG_USB_STORAGE_SDDR55 is not set +# CONFIG_USB_STORAGE_JUMPSHOT is not set + +# +# USB Input Devices +# +# CONFIG_USB_HID is not set + +# +# USB HID Boot Protocol drivers +# +# 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_ACECAD is not set +# CONFIG_USB_KBTAB is not set +# CONFIG_USB_POWERMATE is not set +# CONFIG_USB_MTOUCH is not set +# CONFIG_USB_ITMTOUCH is not set +# CONFIG_USB_EGALAX is not set +# CONFIG_USB_YEALINK is not set +# CONFIG_USB_XPAD is not set +# CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_KEYSPAN_REMOTE is not set +# CONFIG_USB_APPLETOUCH is not set + +# +# USB Imaging devices +# +# CONFIG_USB_MDC800 is not set +# CONFIG_USB_MICROTEK is not set + +# +# USB Multimedia devices +# +# CONFIG_USB_DABUSB is not set + +# +# Video4Linux support is needed for USB Multimedia device support +# + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET is not set +CONFIG_USB_MON=y + +# +# USB port drivers +# + +# +# USB Serial Converter support +# +# CONFIG_USB_SERIAL is not set + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_EMI62 is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_AUERSWALD is not set +# CONFIG_USB_RIO500 is not set +# CONFIG_USB_LEGOTOWER is not set +# CONFIG_USB_LCD is not set +# CONFIG_USB_LED is not set +# CONFIG_USB_CYTHERM is not set +# CONFIG_USB_PHIDGETKIT is not set +# CONFIG_USB_PHIDGETSERVO is not set +# CONFIG_USB_IDMOUSE is not set +# CONFIG_USB_SISUSBVGA is not set +# CONFIG_USB_LD is not set +# CONFIG_USB_TEST is not set + +# +# USB DSL modem support # -# CONFIG_USB_ARCH_HAS_HCD is not set -# CONFIG_USB_ARCH_HAS_OHCI is not set # # USB Gadget Support @@ -668,6 +840,7 @@ # # InfiniBand support # +# CONFIG_INFINIBAND is not set # # SN Devices @@ -697,20 +870,14 @@ # # CD-ROM/DVD Filesystems # -CONFIG_ISO9660_FS=y -CONFIG_JOLIET=y -CONFIG_ZISOFS=y -CONFIG_ZISOFS_FS=y +# CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # -CONFIG_FAT_FS=m -CONFIG_MSDOS_FS=m -CONFIG_VFAT_FS=m -CONFIG_FAT_DEFAULT_CODEPAGE=437 -CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" +# CONFIG_MSDOS_FS is not set +# CONFIG_VFAT_FS is not set # CONFIG_NTFS_FS is not set # @@ -833,7 +1000,7 @@ # CONFIG_DEBUG_KERNEL is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_CROSSCOMPILE=y -CONFIG_CMDLINE="" +CONFIG_CMDLINE="mem=32M console=ttyVR0,115200" # # Security options @@ -882,5 +1049,5 @@ CONFIG_CRC16=m CONFIG_CRC32=m CONFIG_LIBCRC32C=m -CONFIG_ZLIB_INFLATE=y +CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m diff -urN -X dontdiff a-orig/arch/mips/configs/tb0229_defconfig a/arch/mips/configs/tb0229_defconfig --- a-orig/arch/mips/configs/tb0229_defconfig 2005-10-01 00:31:36.000000000 +0900 +++ a/arch/mips/configs/tb0229_defconfig 2005-10-02 01:55:33.000000000 +0900 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.14-rc2 -# Thu Sep 22 02:17:36 2005 +# Sun Oct 2 01:45:15 2005 # CONFIG_MIPS=y @@ -116,7 +116,7 @@ # CONFIG_CASIO_E55 is not set # CONFIG_IBM_WORKPAD is not set CONFIG_TANBAC_TB022X=y -CONFIG_TANBAC_TB0226=y +# CONFIG_TANBAC_TB0226 is not set # CONFIG_VICTOR_MPC30X is not set # CONFIG_ZAO_CAPCELLA is not set CONFIG_PCI_VR41XX=y @@ -333,6 +333,7 @@ # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 @@ -359,7 +360,7 @@ # # SCSI device support # -CONFIG_RAID_ATTRS=m +# CONFIG_RAID_ATTRS is not set # CONFIG_SCSI is not set # @@ -425,7 +426,30 @@ # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set -# CONFIG_NET_PCI is not set +CONFIG_NET_PCI=y +# CONFIG_PCNET32 is not set +# CONFIG_AMD8111_ETH is not set +# CONFIG_ADAPTEC_STARFIRE is not set +# CONFIG_B44 is not set +# CONFIG_FORCEDETH is not set +# CONFIG_DGRS is not set +CONFIG_EEPRO100=y +# CONFIG_E100 is not set +# CONFIG_FEALNX is not set +# CONFIG_NATSEMI is not set +# CONFIG_NE2K_PCI is not set +# CONFIG_8139CP is not set +CONFIG_8139TOO=y +CONFIG_8139TOO_PIO=y +# CONFIG_8139TOO_TUNE_TWISTER is not set +# CONFIG_8139TOO_8129 is not set +# CONFIG_8139_OLD_RX_RESET is not set +# CONFIG_SIS900 is not set +# CONFIG_EPIC100 is not set +# CONFIG_SUNDANCE is not set +# CONFIG_TLAN is not set +# CONFIG_VIA_RHINE is not set +# CONFIG_LAN_SAA9730 is not set # # Ethernet (1000 Mbit) @@ -436,10 +460,12 @@ # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set -# CONFIG_R8169 is not set +CONFIG_R8169=y +# CONFIG_R8169_NAPI is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SK98LIN is not set +# CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set @@ -503,10 +529,7 @@ # # Userland interfaces # -CONFIG_INPUT_MOUSEDEV=y -CONFIG_INPUT_MOUSEDEV_PSAUX=y -CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 -CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 +# CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set @@ -524,12 +547,7 @@ # # Hardware I/O ports # -CONFIG_SERIO=y -CONFIG_SERIO_I8042=y -CONFIG_SERIO_SERPORT=y -# CONFIG_SERIO_PCIPS2 is not set -# CONFIG_SERIO_LIBPS2 is not set -CONFIG_SERIO_RAW=m +# CONFIG_SERIO is not set # CONFIG_GAMEPORT is not set # @@ -543,17 +561,15 @@ # # Serial drivers # -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y -CONFIG_SERIAL_8250_NR_UARTS=4 -# CONFIG_SERIAL_8250_EXTENDED is not set +# CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y -# CONFIG_SERIAL_VR41XX is not set +CONFIG_SERIAL_VR41XX=y +CONFIG_SERIAL_VR41XX_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y @@ -573,7 +589,7 @@ # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set -# CONFIG_TANBAC_TB0219 is not set +CONFIG_TANBAC_TB0219=y # # Ftape, the floppy tape device driver @@ -642,7 +658,120 @@ # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y -# CONFIG_USB is not set +CONFIG_USB=m +# CONFIG_USB_DEBUG is not set + +# +# Miscellaneous USB options +# +CONFIG_USB_DEVICEFS=y +# CONFIG_USB_BANDWIDTH is not set +# CONFIG_USB_DYNAMIC_MINORS is not set +# CONFIG_USB_OTG is not set + +# +# USB Host Controller Drivers +# +CONFIG_USB_EHCI_HCD=m +# CONFIG_USB_EHCI_SPLIT_ISO is not set +# CONFIG_USB_EHCI_ROOT_HUB_TT is not set +# CONFIG_USB_ISP116X_HCD is not set +CONFIG_USB_OHCI_HCD=m +# CONFIG_USB_OHCI_BIG_ENDIAN is not set +CONFIG_USB_OHCI_LITTLE_ENDIAN=y +# CONFIG_USB_UHCI_HCD is not set +# CONFIG_USB_SL811_HCD is not set + +# +# USB Device Class drivers +# +# CONFIG_USB_BLUETOOTH_TTY is not set +# CONFIG_USB_ACM is not set +# CONFIG_USB_PRINTER is not set + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information +# +# CONFIG_USB_STORAGE is not set + +# +# USB Input Devices +# +# CONFIG_USB_HID is not set + +# +# USB HID Boot Protocol drivers +# +# 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_ACECAD is not set +# CONFIG_USB_KBTAB is not set +# CONFIG_USB_POWERMATE is not set +# CONFIG_USB_MTOUCH is not set +# CONFIG_USB_ITMTOUCH is not set +# CONFIG_USB_EGALAX is not set +# CONFIG_USB_YEALINK is not set +# CONFIG_USB_XPAD is not set +# CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_KEYSPAN_REMOTE is not set +# CONFIG_USB_APPLETOUCH is not set + +# +# USB Imaging devices +# +# CONFIG_USB_MDC800 is not set + +# +# USB Multimedia devices +# +# CONFIG_USB_DABUSB is not set + +# +# Video4Linux support is needed for USB Multimedia device support +# + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET is not set +CONFIG_USB_MON=y + +# +# USB port drivers +# + +# +# USB Serial Converter support +# +# CONFIG_USB_SERIAL is not set + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_EMI62 is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_AUERSWALD is not set +# CONFIG_USB_RIO500 is not set +# CONFIG_USB_LEGOTOWER is not set +# CONFIG_USB_LCD is not set +# CONFIG_USB_LED is not set +# CONFIG_USB_CYTHERM is not set +# CONFIG_USB_PHIDGETKIT is not set +# CONFIG_USB_PHIDGETSERVO is not set +# CONFIG_USB_IDMOUSE is not set +# CONFIG_USB_SISUSBVGA is not set +# CONFIG_USB_LD is not set +# CONFIG_USB_TEST is not set + +# +# USB DSL modem support +# # # USB Gadget Support @@ -838,7 +967,7 @@ # CONFIG_DEBUG_KERNEL is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_CROSSCOMPILE=y -CONFIG_CMDLINE="mem=64M console=ttyS0,38400 ip=bootp root=/dev/nfs" +CONFIG_CMDLINE="mem=64M console=ttyVR0,115200 ip=any root=/dev/nfs" # # Security options diff -urN -X dontdiff a-orig/arch/mips/configs/workpad_defconfig a/arch/mips/configs/workpad_defconfig --- a-orig/arch/mips/configs/workpad_defconfig 2005-10-01 00:31:37.000000000 +0900 +++ a/arch/mips/configs/workpad_defconfig 2005-10-02 02:04:49.000000000 +0900 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.14-rc2 -# Thu Sep 22 02:17:39 2005 +# Sun Oct 2 01:59:15 2005 # CONFIG_MIPS=y @@ -24,7 +24,7 @@ # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set -# CONFIG_HOTPLUG is not set +CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_INITRAMFS_SOURCE="" @@ -190,7 +190,18 @@ # # PCCARD (PCMCIA/CardBus) support # -# CONFIG_PCCARD is not set +CONFIG_PCCARD=y +# CONFIG_PCMCIA_DEBUG is not set +CONFIG_PCMCIA=y +CONFIG_PCMCIA_LOAD_CIS=y +CONFIG_PCMCIA_IOCTL=y + +# +# PC-card bridges +# +# CONFIG_I82365 is not set +# CONFIG_TCIC is not set +CONFIG_PCMCIA_PROBE=y # # PCI Hotplug Support @@ -284,7 +295,7 @@ # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y -# CONFIG_FW_LOADER is not set +CONFIG_FW_LOADER=y # # Connector - unified userspace <-> kernelspace linker @@ -315,9 +326,7 @@ # CONFIG_BLK_DEV_RAM is not set CONFIG_BLK_DEV_RAM_COUNT=16 # CONFIG_LBD is not set -CONFIG_CDROM_PKTCDVD=m -CONFIG_CDROM_PKTCDVD_BUFFERS=8 -# CONFIG_CDROM_PKTCDVD_WCACHE is not set +# CONFIG_CDROM_PKTCDVD is not set # # IO Schedulers @@ -340,6 +349,7 @@ # CONFIG_BLK_DEV_IDE_SATA is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set +CONFIG_BLK_DEV_IDECS=m # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set @@ -358,7 +368,7 @@ # # SCSI device support # -CONFIG_RAID_ATTRS=m +# CONFIG_RAID_ATTRS is not set # CONFIG_SCSI is not set # @@ -417,7 +427,7 @@ # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y -# CONFIG_MII is not set +CONFIG_MII=m # CONFIG_NET_VENDOR_3COM is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set @@ -447,6 +457,19 @@ # CONFIG_NET_RADIO is not set # +# PCMCIA network device support +# +CONFIG_NET_PCMCIA=y +CONFIG_PCMCIA_3C589=m +CONFIG_PCMCIA_3C574=m +CONFIG_PCMCIA_FMVJ18X=m +CONFIG_PCMCIA_PCNET=m +CONFIG_PCMCIA_NMCLAN=m +CONFIG_PCMCIA_SMC91C92=m +CONFIG_PCMCIA_XIRC2PS=m +CONFIG_PCMCIA_AXNET=m + +# # Wan interfaces # # CONFIG_WAN is not set @@ -497,7 +520,7 @@ # Hardware I/O ports # CONFIG_SERIO=y -CONFIG_SERIO_I8042=y +# CONFIG_SERIO_I8042 is not set CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_LIBPS2 is not set CONFIG_SERIO_RAW=m @@ -514,17 +537,15 @@ # # Serial drivers # -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y -CONFIG_SERIAL_8250_NR_UARTS=4 -# CONFIG_SERIAL_8250_EXTENDED is not set +# CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y -# CONFIG_SERIAL_VR41XX is not set +CONFIG_SERIAL_VR41XX=y +CONFIG_SERIAL_VR41XX_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 @@ -559,6 +580,11 @@ # # Ftape, the floppy tape device driver # + +# +# PCMCIA character devices +# +# CONFIG_SYNCLINK_CS is not set # CONFIG_GPIO_VR41XX is not set # CONFIG_RAW_DRIVER is not set @@ -752,7 +778,7 @@ # CONFIG_DEBUG_KERNEL is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_CROSSCOMPILE=y -CONFIG_CMDLINE="" +CONFIG_CMDLINE="console=ttyVR0,19200 mem=16M" # # Security options @@ -799,7 +825,7 @@ # # CONFIG_CRC_CCITT is not set CONFIG_CRC16=m -CONFIG_CRC32=m +CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m From anemo@mba.ocn.ne.jp Sun Oct 2 17:18:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Oct 2005 17:18:21 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:30921 "EHLO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with ESMTP id S8133406AbVJBQSB (ORCPT ); Sun, 2 Oct 2005 17:18:01 +0100 Received: from localhost (p7129-ipad210funabasi.chiba.ocn.ne.jp [58.88.126.129]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 35F748D00; Mon, 3 Oct 2005 01:17:56 +0900 (JST) Date: Mon, 03 Oct 2005 01:16:37 +0900 (JST) Message-Id: <20051003.011637.41198806.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Fix some sparse warnings From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9109 X-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 Make memcpy_fromio etc. more sparse-friendly. Remove duplicate __user annotation from __copy_to_user. Signed-off-by: Atsushi Nemoto diff --git a/include/asm-mips/io.h b/include/asm-mips/io.h --- a/include/asm-mips/io.h +++ b/include/asm-mips/io.h @@ -25,6 +25,7 @@ #include #include #include +#include #include #include @@ -521,9 +522,18 @@ BUILDSTRING(q, u64) /* Depends on MIPS II instruction set */ #define mmiowb() asm volatile ("sync" ::: "memory") -#define memset_io(a,b,c) memset((void *)(a),(b),(c)) -#define memcpy_fromio(a,b,c) memcpy((a),(void *)(b),(c)) -#define memcpy_toio(a,b,c) memcpy((void *)(a),(b),(c)) +static inline void memset_io(volatile void __iomem *addr, unsigned char val, int count) +{ + memset((void __force *) addr, val, count); +} +static inline void memcpy_fromio(void *dst, const volatile void __iomem *src, int count) +{ + memcpy(dst, (void __force *) src, count); +} +static inline void memcpy_toio(volatile void __iomem *dst, const void *src, int count) +{ + memcpy((void __force *) dst, src, count); +} /* * ISA space is 'always mapped' on currently supported MIPS systems, no need diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h --- a/include/asm-mips/uaccess.h +++ b/include/asm-mips/uaccess.h @@ -417,7 +417,7 @@ extern size_t __copy_user(void *__to, co */ #define __copy_to_user(to,from,n) \ ({ \ - void __user __user *__cu_to; \ + void __user *__cu_to; \ const void *__cu_from; \ long __cu_len; \ \ From ralf@linux-mips.org Mon Oct 3 11:10:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 11:10:28 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:22548 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133440AbVJCKKL (ORCPT ); Mon, 3 Oct 2005 11:10:11 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93AA4MO001842; Mon, 3 Oct 2005 11:10:06 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j91C7wrY017012; Sat, 1 Oct 2005 13:07:58 +0100 Date: Sat, 1 Oct 2005 13:07:58 +0100 From: Ralf Baechle To: Andrew Isaacson Cc: linux-mips@linux-mips.org Subject: Re: [patch 5/5] SiByte fixes for 2.6.12 Message-ID: <20051001120758.GH14463@linux-mips.org> References: <20050622230003.GA17725@broadcom.com> <20050622230203.GA17984@broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050622230203.GA17984@broadcom.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9110 X-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, Jun 22, 2005 at 04:02:03PM -0700, Andrew Isaacson wrote: > Fix a stale comment in c-sb1.c. Applied, Ralf From ralf@linux-mips.org Mon Oct 3 11:10:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 11:11:19 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:34322 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133442AbVJCKKM (ORCPT ); Mon, 3 Oct 2005 11:10:12 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93AA4MU001842; Mon, 3 Oct 2005 11:10:07 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j91AF4pC023424; Sat, 1 Oct 2005 11:15:04 +0100 Date: Sat, 1 Oct 2005 11:15:03 +0100 From: Ralf Baechle To: Andrew Isaacson Cc: linux-mips@linux-mips.org Subject: Re: [patch 1/5] SiByte fixes for 2.6.12 Message-ID: <20051001101503.GE14463@linux-mips.org> References: <20050622230003.GA17725@broadcom.com> <20050622230042.GA17919@broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050622230042.GA17919@broadcom.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9111 X-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, Jun 22, 2005 at 04:00:42PM -0700, Andrew Isaacson wrote: > SB1 does not use the R4K TLB code. Now it does :-) Ralf From ralf@linux-mips.org Mon Oct 3 11:11:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 11:12:10 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:54025 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133444AbVJCKKM (ORCPT ); Mon, 3 Oct 2005 11:10:12 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93AA4MW001842; Mon, 3 Oct 2005 11:10:07 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j919S78l009207; Sat, 1 Oct 2005 10:28:07 +0100 Date: Sat, 1 Oct 2005 10:28:07 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Andrew Isaacson , linux-mips@linux-mips.org Subject: Re: [patch 1/5] SiByte fixes for 2.6.12 Message-ID: <20051001092807.GD14463@linux-mips.org> References: <20050622230042.GA17919@broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9112 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Jun 23, 2005 at 12:01:57PM +0100, Maciej W. Rozycki wrote: > Well, the flag is not really to specify whether the common code is to be > used or not. It's about whether the TLB is like that of the R4k. > Actually it's always been a mystery for me why the common code cannot be > used for the SB1, but perhaps there is something specific that I could > only discover in that "SB-1 Core User Manual" that I yet have to see, > sigh... > > Of course if your TLB is indeed different from that of the R4k, then you > shouldn't be setting cp0.config.mt to 1 in the first place... The reason was primarily the tiny bit of extra performance because the SB1 doesn't need the hazard handling overhead. Also tlb-sb1 has a few changes that are needed to initialize a TLB in undefined state after powerup. That was needed to run Linux on firmware-less SB1 cores. Ralf From ralf@linux-mips.org Mon Oct 3 11:12:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 11:13:02 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:61707 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133445AbVJCKKM (ORCPT ); Mon, 3 Oct 2005 11:10:12 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93AA4MQ001842; Mon, 3 Oct 2005 11:10:06 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j91BvQf5014346; Sat, 1 Oct 2005 12:57:26 +0100 Date: Sat, 1 Oct 2005 12:57:26 +0100 From: Ralf Baechle To: Andy Isaacson Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [patch 4/5] SiByte fixes for 2.6.12 Message-ID: <20051001115725.GG14463@linux-mips.org> References: <20050622230151.GA17970@broadcom.com> <20050623144926.GA10216@hexapodia.org> <20050623222709.GC26427@hexapodia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050623222709.GC26427@hexapodia.org> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9113 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Jun 23, 2005 at 03:27:09PM -0700, Andy Isaacson wrote: > > Well, I've had a look at the code and it's such a mess. Obviously > > calling ld_mmu_r4xx0() (or any of the other variants) should not be > > compiled conditionally and more specific cases, i.e. based on PRId values > > should take precedence. I'll see if I can make it better. > > I certainly won't argue with a cleanup of arch/mips/mm/cache.c, that > code has annoyed me from first laying eyes on it... So just did that, cpu_cache_init is looking bearable now. Ralf From ralf@linux-mips.org Mon Oct 3 11:13:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 11:13:45 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:48916 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133446AbVJCKKT (ORCPT ); Mon, 3 Oct 2005 11:10:19 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93AA4Ma001842; Mon, 3 Oct 2005 11:10:09 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8UMnEYM014586; Fri, 30 Sep 2005 23:49:14 +0100 Date: Fri, 30 Sep 2005 23:49:14 +0100 From: Ralf Baechle To: Jan Pedersen Cc: "'Ilya A. Volynets-Evenbakh'" , linux-mips@linux-mips.org Subject: Re: support for NS DP83847 Message-ID: <20050930224914.GC14463@linux-mips.org> References: <43307CA9.1070506@total-knowledge.com> <20050920212703.0709137646C@rocket.glaze.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920212703.0709137646C@rocket.glaze.se> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9114 X-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, Sep 20, 2005 at 11:27:04PM +0200, Jan Pedersen wrote: > Sorry, patches now included. The filename of the tarballs you sent suggest the patches inside are meant for 2.4. Linux 2.4 by now is in deep-freeze; nothing that isn't strictly a bug fix will be accepted anymore. 2.6 Patches of course would be gladly considered. Ralf From ralf@linux-mips.org Mon Oct 3 11:14:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 11:14:37 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:274 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133447AbVJCKKT (ORCPT ); Mon, 3 Oct 2005 11:10:19 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93AA4Mc001842; Mon, 3 Oct 2005 11:10:14 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8UMk81c014583; Fri, 30 Sep 2005 23:46:08 +0100 Date: Fri, 30 Sep 2005 23:46:08 +0100 From: Ralf Baechle To: "Ilya A. Volynets-Evenbakh" Cc: Jan Pedersen , linux-mips@linux-mips.org Subject: Re: support for NS DP83847 Message-ID: <20050930224608.GB14463@linux-mips.org> References: <20050920211245.730CF376471@rocket.glaze.se> <43307CA9.1070506@total-knowledge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43307CA9.1070506@total-knowledge.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9115 X-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, Sep 20, 2005 at 02:18:33PM -0700, Ilya A. Volynets-Evenbakh wrote: > If you are interested in any patches being accepted into LMO CVS tree, > you should email patches in question, not URLs. Noone will bother looking > up your stuff on the web. Or simply see Documentation/SubmittingPatches: [...] 6) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel developer to be able to "quote" your changes, using standard e-mail tools, so that they may comment on specific portions of your code. For this reason, all patches should be submitting e-mail "inline". WARNING: Be wary of your editor's word-wrap corrupting your patch, if you choose to cut-n-paste your patch. Do not attach the patch as a MIME attachment, compressed or not. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. A MIME attachment also takes Linus a bit more time to process, decreasing the likelihood of your MIME-attached change being accepted. Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME. [...] I'm doing plenty of the MIPS maintenance work offline, so URLs really don't fly. Ralf From ralf@linux-mips.org Mon Oct 3 11:15:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 11:15:29 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:32266 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133449AbVJCKKl (ORCPT ); Mon, 3 Oct 2005 11:10:41 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93AA4MY001842; Mon, 3 Oct 2005 11:10:08 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8UMJ9dV014514; Fri, 30 Sep 2005 23:19:09 +0100 Date: Fri, 30 Sep 2005 23:19:09 +0100 From: Ralf Baechle To: kbaidarov Cc: linux-mips@linux-mips.org Subject: Re: [patch] db1550: useless memset() call Message-ID: <20050930221909.GA14463@linux-mips.org> References: <43329632.8070400@dev.rtsoft.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43329632.8070400@dev.rtsoft.ru> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9116 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Sep 22, 2005 at 03:32:02PM +0400, kbaidarov wrote: > I've try kernel without memset() on the board - is ok, board boot. > All drivers works fine. Than I grep the kernel sources: > > [root@windmill linux]# grep -nri "memset(irq_desc" arch/ > arch/mips/au1000/common/irq.c:449: memset(irq_desc, 0, > sizeof(irq_desc)); > arch/mips/ite-boards/generic/irq.c:184: memset(irq_desc, 0, > sizeof(irq_desc)); > [root@windmill linux]# > > Only 2 matches! Does we needs memset() at all? > And if some one try to initialize irq_desc from start_kernel() before > arch_init_irq() call, then following arch_init_irq() call discard all that > initialization. Exactly, so the initialization is wrong, so I'm removing both calls. Thanks, Ralf From ralf@linux-mips.org Mon Oct 3 11:34:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 11:34:24 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:6684 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133447AbVJCKeI (ORCPT ); Mon, 3 Oct 2005 11:34:08 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93AXxwX005574; Mon, 3 Oct 2005 11:33:59 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j93AXwC0005573; Mon, 3 Oct 2005 11:33:58 +0100 Date: Mon, 3 Oct 2005 11:33:58 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH] vr41xx: update defconfig Message-ID: <20051003103358.GA2624@linux-mips.org> References: <20051002023213.61de0f26.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051002023213.61de0f26.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9117 X-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, Oct 02, 2005 at 02:32:13AM +0900, Yoichi Yuasa wrote: > I had updated vr41xx machine's defconfig. > Please apply. Your patch had rejects on the date header of the defconfig files; I dropped those segments and applied the remainder. Ralf From ralf@linux-mips.org Mon Oct 3 11:40:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 11:41:15 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:23065 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133451AbVJCKkz (ORCPT ); Mon, 3 Oct 2005 11:40:55 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93AenFS009984; Mon, 3 Oct 2005 11:40:49 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j93Ael1O009983; Mon, 3 Oct 2005 11:40:47 +0100 Date: Mon, 3 Oct 2005 11:40:47 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix some sparse warnings Message-ID: <20051003104047.GB2624@linux-mips.org> References: <20051003.011637.41198806.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051003.011637.41198806.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9118 X-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, Oct 03, 2005 at 01:16:37AM +0900, Atsushi Nemoto wrote: > Make memcpy_fromio etc. more sparse-friendly. > Remove duplicate __user annotation from __copy_to_user. > > Signed-off-by: Atsushi Nemoto Thanks, applied. Ralf From macro@linux-mips.org Mon Oct 3 12:56:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 12:56:35 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:54790 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S3465607AbVJCL4R (ORCPT ); Mon, 3 Oct 2005 12:56:17 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 5255BF59AE; Mon, 3 Oct 2005 13:56:12 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18870-03; Mon, 3 Oct 2005 13:56:12 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 1EF7FF5991; Mon, 3 Oct 2005 13:56:12 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j93BuD6B013495; Mon, 3 Oct 2005 13:56:13 +0200 Date: Mon, 3 Oct 2005 12:56:20 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: Andrew Isaacson , linux-mips@linux-mips.org Subject: Re: [patch 1/5] SiByte fixes for 2.6.12 In-Reply-To: <20051001092807.GD14463@linux-mips.org> Message-ID: References: <20050622230042.GA17919@broadcom.com> <20051001092807.GD14463@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.86.2/1107/Sun Oct 2 10:09:39 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9119 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, 1 Oct 2005, Ralf Baechle wrote: > > Of course if your TLB is indeed different from that of the R4k, then you > > shouldn't be setting cp0.config.mt to 1 in the first place... > > The reason was primarily the tiny bit of extra performance because the > SB1 doesn't need the hazard handling overhead. Also tlb-sb1 has a few That's hardly a justification for duplicating all the code; I've thought the reason was actually historical -- hadn't it been simply written separately initially and never got merged properly afterwards? > changes that are needed to initialize a TLB in undefined state after > powerup. That was needed to run Linux on firmware-less SB1 cores. But that's true about the power-up state of the TLB on any MIPS CPU, isn't it? Maciej From ralf@linux-mips.org Mon Oct 3 13:50:39 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 13:50:56 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:3344 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3465646AbVJCMuj (ORCPT ); Mon, 3 Oct 2005 13:50:39 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93CoGma018656; Mon, 3 Oct 2005 13:50:16 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j93CoG44018655; Mon, 3 Oct 2005 13:50:16 +0100 Date: Mon, 3 Oct 2005 13:50:16 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Andrew Isaacson , linux-mips@linux-mips.org Subject: Re: [patch 1/5] SiByte fixes for 2.6.12 Message-ID: <20051003125016.GE2624@linux-mips.org> References: <20050622230042.GA17919@broadcom.com> <20051001092807.GD14463@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9120 X-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, Oct 03, 2005 at 12:56:20PM +0100, Maciej W. Rozycki wrote: > > > Of course if your TLB is indeed different from that of the R4k, then you > > > shouldn't be setting cp0.config.mt to 1 in the first place... > > > > The reason was primarily the tiny bit of extra performance because the > > SB1 doesn't need the hazard handling overhead. Also tlb-sb1 has a few > > That's hardly a justification for duplicating all the code; I've thought > the reason was actually historical -- hadn't it been simply written > separately initially and never got merged properly afterwards? Historically even the R10000 had it's own copy of the TLB code - with the sole reason of existence being it having neither hazards nor suffering from potencial duplicate TLB entries. Well, maybe also the very first stages of MIPS SMP support. Anyway, as you said that's little reason for an extra copy to exist and so I both got axed. > > changes that are needed to initialize a TLB in undefined state after > > powerup. That was needed to run Linux on firmware-less SB1 cores. > > But that's true about the power-up state of the TLB on any MIPS CPU, > isn't it? Some come out of powerup with a cleared TLB but anyway, since normally some piece of firmware takes care of these issues it's not something Linux normally should need to worry about. Ralf From drow@nevyn.them.org Mon Oct 3 14:15:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 14:16:10 +0100 (BST) Received: from nevyn.them.org ([66.93.172.17]:683 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S3465648AbVJCNPy (ORCPT ); Mon, 3 Oct 2005 14:15:54 +0100 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EMQAa-0004y2-EJ; Mon, 03 Oct 2005 09:15:52 -0400 Date: Mon, 3 Oct 2005 09:15:52 -0400 From: Daniel Jacobowitz To: Ralf Baechle Cc: "Maciej W. Rozycki" , Andrew Isaacson , linux-mips@linux-mips.org Subject: Re: [patch 1/5] SiByte fixes for 2.6.12 Message-ID: <20051003131551.GA19075@nevyn.them.org> References: <20050622230042.GA17919@broadcom.com> <20051001092807.GD14463@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051001092807.GD14463@linux-mips.org> User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9121 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Sat, Oct 01, 2005 at 10:28:07AM +0100, Ralf Baechle wrote: > On Thu, Jun 23, 2005 at 12:01:57PM +0100, Maciej W. Rozycki wrote: > > > Well, the flag is not really to specify whether the common code is to be > > used or not. It's about whether the TLB is like that of the R4k. > > Actually it's always been a mystery for me why the common code cannot be > > used for the SB1, but perhaps there is something specific that I could > > only discover in that "SB-1 Core User Manual" that I yet have to see, > > sigh... > > > > Of course if your TLB is indeed different from that of the R4k, then you > > shouldn't be setting cp0.config.mt to 1 in the first place... > > The reason was primarily the tiny bit of extra performance because the > SB1 doesn't need the hazard handling overhead. Also tlb-sb1 has a few > changes that are needed to initialize a TLB in undefined state after > powerup. That was needed to run Linux on firmware-less SB1 cores. FYI, all I have is a piece of hard evidence: this patch was the difference between not booting and booting for a Sentosa with CFE. Which isn't firmwareless and isn't a tiny bit of extra performance issue. I'll try to give CVS HEAD a shot this week sometime. -- Daniel Jacobowitz CodeSourcery, LLC From ralf@linux-mips.org Mon Oct 3 14:24:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 14:24:57 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:20997 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3465651AbVJCNYl (ORCPT ); Mon, 3 Oct 2005 14:24:41 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93DOAcg019890; Mon, 3 Oct 2005 14:24:10 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j93DO889019889; Mon, 3 Oct 2005 14:24:08 +0100 Date: Mon, 3 Oct 2005 14:24:08 +0100 From: Ralf Baechle To: Daniel Jacobowitz Cc: "Maciej W. Rozycki" , Andrew Isaacson , linux-mips@linux-mips.org Subject: Re: [patch 1/5] SiByte fixes for 2.6.12 Message-ID: <20051003132408.GG2624@linux-mips.org> References: <20050622230042.GA17919@broadcom.com> <20051001092807.GD14463@linux-mips.org> <20051003131551.GA19075@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051003131551.GA19075@nevyn.them.org> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9122 X-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, Oct 03, 2005 at 09:15:52AM -0400, Daniel Jacobowitz wrote: > > > Well, the flag is not really to specify whether the common code is to be > > > used or not. It's about whether the TLB is like that of the R4k. > > > Actually it's always been a mystery for me why the common code cannot be > > > used for the SB1, but perhaps there is something specific that I could > > > only discover in that "SB-1 Core User Manual" that I yet have to see, > > > sigh... > > > > > > Of course if your TLB is indeed different from that of the R4k, then you > > > shouldn't be setting cp0.config.mt to 1 in the first place... > > > > The reason was primarily the tiny bit of extra performance because the > > SB1 doesn't need the hazard handling overhead. Also tlb-sb1 has a few > > changes that are needed to initialize a TLB in undefined state after > > powerup. That was needed to run Linux on firmware-less SB1 cores. > > FYI, all I have is a piece of hard evidence: this patch was the > difference between not booting and booting for a Sentosa with CFE. > Which isn't firmwareless and isn't a tiny bit of extra performance > issue. > > I'll try to give CVS HEAD a shot this week sometime. Just as reminder for everybody - CVS is dead and frozen, the action is playing on git now ... Ralf From macro@linux-mips.org Mon Oct 3 14:35:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 14:35:19 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:32274 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S3465651AbVJCNfA (ORCPT ); Mon, 3 Oct 2005 14:35:00 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 45D4EF5991; Mon, 3 Oct 2005 15:34:55 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24570-04; Mon, 3 Oct 2005 15:34:55 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id D27A8F597F; Mon, 3 Oct 2005 15:34:54 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j93DYvVE018436; Mon, 3 Oct 2005 15:34:57 +0200 Date: Mon, 3 Oct 2005 14:35:04 +0100 (BST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz Cc: Ralf Baechle , Andrew Isaacson , linux-mips@linux-mips.org Subject: Re: [patch 1/5] SiByte fixes for 2.6.12 In-Reply-To: <20051003131551.GA19075@nevyn.them.org> Message-ID: References: <20050622230042.GA17919@broadcom.com> <20051001092807.GD14463@linux-mips.org> <20051003131551.GA19075@nevyn.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.86.2/1107/Sun Oct 2 10:09:39 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9123 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 3 Oct 2005, Daniel Jacobowitz wrote: > FYI, all I have is a piece of hard evidence: this patch was the > difference between not booting and booting for a Sentosa with CFE. > Which isn't firmwareless and isn't a tiny bit of extra performance > issue. Actually workarounds have been floating around for some time. ;-) But I'm glad this has now been fixed properly. Maciej From ralf@linux-mips.org Mon Oct 3 14:37:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Oct 2005 14:37:23 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:19732 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3465652AbVJCNhB (ORCPT ); Mon, 3 Oct 2005 14:37:01 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j93DarfV020332; Mon, 3 Oct 2005 14:36:53 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j93Daqqt020331; Mon, 3 Oct 2005 14:36:52 +0100 Date: Mon, 3 Oct 2005 14:36:52 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips@linux-mips.org Subject: Re: linux-mips Vs kernel.org Message-ID: <20051003133652.GI2624@linux-mips.org> References: <20050927093922.GA3793@linux-mips.org> <20050928005432.7d45b2f9.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050928005432.7d45b2f9.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9124 X-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, Sep 28, 2005 at 12:54:32AM +0900, Yoichi Yuasa wrote: > > > We currently working with the 2.6.12 kernel, and wondering which from > > > linux-mips or kernel.org version we should use, > > > in a more general manner, what are the differences between linux-mips and > > > kernel.org kernel source code, is one the > > > mirror of the other, or is there one that frequently merge with the other > > > ? > > > > At this stage the kernel.org tree is quite unusable for MIPS. > > I have no problem kernel.org GIT with VR41xx. See RFC 1925, section 2 (3): With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. Ralf From unixe@comcast.net Tue Oct 4 01:00:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 01:01:16 +0100 (BST) Received: from rwcrmhc13.comcast.net ([216.148.227.118]:13051 "EHLO rwcrmhc12.comcast.net") by ftp.linux-mips.org with ESMTP id S3465664AbVJDAAu convert rfc822-to-8bit (ORCPT ); Tue, 4 Oct 2005 01:00:50 +0100 Received: from buzz (c-67-171-115-157.hsd1.ut.comcast.net[67.171.115.157]) by comcast.net (rwcrmhc13) with SMTP id <2005100400003901500b6fere>; Tue, 4 Oct 2005 00:00:40 +0000 From: "Kyle Unice" To: Subject: Au1550 Serial port - linux-2.6.13.2 Date: Mon, 3 Oct 2005 18:00:30 -0600 Message-ID: <000f01c5c876$a2b78740$0400a8c0@buzz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9125 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: unixe@comcast.net Precedence: bulk X-list: linux-mips I have configured linux-2.6.13.2 for a db1550_defconfig build. When I compile it, I get this error when compiling au1x00_uart.c: LD usr/built-in.o HOSTCC drivers/pci/gen-devlist DEVLIST drivers/pci/devlist.h CC drivers/pci/names.o In file included from include/linux/mm.h:36, from include/asm/pci.h:10, from include/linux/pci.h:919, from drivers/pci/names.c:11: include/asm/pgtable.h: In function `io_remap_pfn_range': include/asm/pgtable.h:377: warning: unused variable `phys_addr_high' LD drivers/pci/built-in.o CC drivers/serial/au1x00_uart.o drivers/serial/au1x00_uart.c:72: error: `AU1000_UART0_INT' undeclared here (not in a function) drivers/serial/au1x00_uart.c:72: error: initializer element is not constant drivers/serial/au1x00_uart.c:72: error: (near initialization for `old_serial_por t[0].irq') drivers/serial/au1x00_uart.c:75: error: initializer element is not constant drivers/serial/au1x00_uart.c:75: error: (near initialization for `old_serial_por t[0]') drivers/serial/au1x00_uart.c:78: error: `AU1000_UART1_INT' undeclared here (not in a function) drivers/serial/au1x00_uart.c:78: error: initializer element is not constant drivers/serial/au1x00_uart.c:78: error: (near initialization for `old_serial_por t[1].irq') drivers/serial/au1x00_uart.c:81: error: initializer element is not constant drivers/serial/au1x00_uart.c:81: error: (near initialization for `old_serial_por t[1]') drivers/serial/au1x00_uart.c:84: error: `UART2_ADDR' undeclared here (not in a f unction) drivers/serial/au1x00_uart.c:84: error: initializer element is not constant drivers/serial/au1x00_uart.c:84: error: (near initialization for `old_serial_por t[2].iomem_base') drivers/serial/au1x00_uart.c:85: error: `AU1000_UART2_INT' undeclared here (not in a function) drivers/serial/au1x00_uart.c:85: error: initializer element is not constant drivers/serial/au1x00_uart.c:85: error: (near initialization for `old_serial_por t[2].irq') drivers/serial/au1x00_uart.c:88: error: initializer element is not constant drivers/serial/au1x00_uart.c:88: error: (near initialization for `old_serial_por t[2]') drivers/serial/au1x00_uart.c:92: error: `AU1000_UART3_INT' undeclared here (not in a function) drivers/serial/au1x00_uart.c:92: error: initializer element is not constant drivers/serial/au1x00_uart.c:92: error: (near initialization for `old_serial_por t[3].irq') drivers/serial/au1x00_uart.c:95: error: initializer element is not constant drivers/serial/au1x00_uart.c:95: error: (near initialization for `old_serial_por t[3]') make[2]: *** [drivers/serial/au1x00_uart.o] Error 1 make[1]: *** [drivers/serial] Error 2 make: *** [drivers] Error 2 Kyle@buzz /usr/src/linux-2.6.13.2 $ From dan@embeddedalley.com Tue Oct 4 01:44:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 01:44:44 +0100 (BST) Received: from smtp101.biz.mail.mud.yahoo.com ([68.142.200.236]:54391 "HELO smtp101.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S3465666AbVJDAo0 (ORCPT ); Tue, 4 Oct 2005 01:44:26 +0100 Received: (qmail 55784 invoked from network); 4 Oct 2005 00:44:18 -0000 Received: from unknown (HELO ?192.168.1.107?) (dan@embeddedalley.com@71.128.175.242 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 4 Oct 2005 00:44:18 -0000 In-Reply-To: <000f01c5c876$a2b78740$0400a8c0@buzz> References: <000f01c5c876$a2b78740$0400a8c0@buzz> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2e5c8ef0628b1886bde6e6ca6d76b79e@embeddedalley.com> Content-Transfer-Encoding: 7bit Cc: From: Dan Malek Subject: Re: Au1550 Serial port - linux-2.6.13.2 Date: Mon, 3 Oct 2005 17:43:56 -0700 To: "Kyle Unice" X-Mailer: Apple Mail (2.623) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9126 X-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@embeddedalley.com Precedence: bulk X-list: linux-mips On Oct 3, 2005, at 5:00 PM, Kyle Unice wrote: > I have configured linux-2.6.13.2 for a db1550_defconfig build. When I > compile it, I get this error when compiling au1x00_uart.c: You need to use the linux-mips.org CVS tree. Current top of tree is 2.6.14-rc2, which builds and boots fine on the db1550. Thanks. -- Dan From vagabon.xyz@gmail.com Tue Oct 4 09:49:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 09:50:13 +0100 (BST) Received: from zproxy.gmail.com ([64.233.162.193]:26540 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133458AbVJDItz (ORCPT ); Tue, 4 Oct 2005 09:49:55 +0100 Received: by zproxy.gmail.com with SMTP id j2so136222nzf for ; Tue, 04 Oct 2005 01:49:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type; b=bLUshBcCyd0By1bKl40tGMD8JKyJnw85xGvdc4kUCH+0VehghgjquPFLUuNbyqNgixnSuXPtAxG3/rTfbglA8EuZgpUYtIJpCa5gyT8hXLNJF/eEyecj980kwiDHpKzmkdSSOGy5kevNm3Qc6j3I1dWB83IxHelaGoVDKhCDPzQ= Received: by 10.36.224.78 with SMTP id w78mr48850nzg; Tue, 04 Oct 2005 01:49:44 -0700 (PDT) Received: by 10.36.49.3 with HTTP; Tue, 4 Oct 2005 01:49:44 -0700 (PDT) Message-ID: Date: Tue, 4 Oct 2005 10:49:44 +0200 From: Franck Reply-To: Franck To: Ralf Baechle Subject: [PATCH] Add support for 4KS cpu. Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3451_12254408.1128415784694" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9127 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_3451_12254408.1128415784694 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This patch adds support for both 4ksc and 4ksd cpus. These cpu are mainly used in embedded system such as smartcard or point of sell devices as they provide some extra security features. Signed-off-by: Franck ------=_Part_3451_12254408.1128415784694 Content-Type: text/x-patch; name="4ksx-support.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="4ksx-support.patch" ZGlmZiAtTnVycCBsaW51eC0yLjYuMTQtcmMyLW1pcHNjdnMvYXJjaC9taXBzL0tjb25maWcgbGlu dXgtMi42LjE0LXJjMi1taXBzY3ZzLTRLU3gvYXJjaC9taXBzL0tjb25maWcKLS0tIGxpbnV4LTIu Ni4xNC1yYzItbWlwc2N2cy9hcmNoL21pcHMvS2NvbmZpZwkyMDA1LTA5LTIzIDIyOjAyOjQ0LjAw MDAwMDAwMCArMDIwMAorKysgbGludXgtMi42LjE0LXJjMi1taXBzY3ZzLTRLU3gvYXJjaC9taXBz L0tjb25maWcJMjAwNS0xMC0wNCAwOTo1Mjo0My4wMDAwMDAwMDAgKzAyMDAKQEAgLTExMjMsNiAr MTEyMywyMCBAQCBjb25maWcgQ1BVX1NCMQogCXNlbGVjdCBDUFVfU1VQUE9SVFNfNjRCSVRfS0VS TkVMCiAJc2VsZWN0IENQVV9TVVBQT1JUU19ISUdITUVNCiAKK2NvbmZpZyBDUFVfNEtTQworCWJv b2wgIjRLU0MiCisJc2VsZWN0IENQVV9TVVBQT1JUU18zMkJJVF9LRVJORUwKKwlzZWxlY3QgQ1BV X0hBU19QUkVGRVRDSAorCWhlbHAKKwkgIE1JUFMgVGVjaG5vbG9naWVzIDRLU2Mtc2VyaWVzIHBy b2Nlc3NvcnMuCisKK2NvbmZpZyBDUFVfNEtTRAorCWJvb2wgIjRLU0QiCisJc2VsZWN0IENQVV9T VVBQT1JUU18zMkJJVF9LRVJORUwKKwlzZWxlY3QgQ1BVX0hBU19QUkVGRVRDSAorCWhlbHAKKwkg IE1JUFMgVGVjaG5vbG9naWVzIDRLU2Qtc2VyaWVzIHByb2Nlc3NvcnMuCisKIGVuZGNob2ljZQog CiBlbmRtZW51CmRpZmYgLU51cnAgbGludXgtMi42LjE0LXJjMi1taXBzY3ZzL2FyY2gvbWlwcy9r ZXJuZWwvY3B1LXByb2JlLmMgbGludXgtMi42LjE0LXJjMi1taXBzY3ZzLTRLU3gvYXJjaC9taXBz L2tlcm5lbC9jcHUtcHJvYmUuYwotLS0gbGludXgtMi42LjE0LXJjMi1taXBzY3ZzL2FyY2gvbWlw cy9rZXJuZWwvY3B1LXByb2JlLmMJMjAwNS0wOC0xNiAxOTo1MDo0My4wMDAwMDAwMDAgKzAyMDAK KysrIGxpbnV4LTIuNi4xNC1yYzItbWlwc2N2cy00S1N4L2FyY2gvbWlwcy9rZXJuZWwvY3B1LXBy b2JlLmMJMjAwNS0xMC0wNCAwOTo0MTo0Mi4wMDAwMDAwMDAgKzAyMDAKQEAgLTU1Miw2ICs1NTIs NyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgY3B1X3Byb2JlX21pcHMoc3RydWN0CiAJCWMtPmNwdXR5 cGUgPSBDUFVfNEtFQzsKIAkJYnJlYWs7CiAJY2FzZSBQUklEX0lNUF80S1NDOgorCWNhc2UgUFJJ RF9JTVBfNEtTRDoKIAkJYy0+Y3B1dHlwZSA9IENQVV80S1NDOwogCQlicmVhazsKIAljYXNlIFBS SURfSU1QXzVLQzoKZGlmZiAtTnVycCBsaW51eC0yLjYuMTQtcmMyLW1pcHNjdnMvYXJjaC9taXBz L2tlcm5lbC9NYWtlZmlsZSBsaW51eC0yLjYuMTQtcmMyLW1pcHNjdnMtNEtTeC9hcmNoL21pcHMv a2VybmVsL01ha2VmaWxlCi0tLSBsaW51eC0yLjYuMTQtcmMyLW1pcHNjdnMvYXJjaC9taXBzL2tl cm5lbC9NYWtlZmlsZQkyMDA1LTA5LTAxIDIyOjQyOjQ2LjAwMDAwMDAwMCArMDIwMAorKysgbGlu dXgtMi42LjE0LXJjMi1taXBzY3ZzLTRLU3gvYXJjaC9taXBzL2tlcm5lbC9NYWtlZmlsZQkyMDA1 LTEwLTA0IDA5OjMwOjI5LjAwMDAwMDAwMCArMDIwMApAQCAtMzEsNiArMzEsOCBAQCBvYmotJChD T05GSUdfQ1BVX1NCMSkJCSs9IHI0a19mcHUubyByNGtfCiBvYmotJChDT05GSUdfQ1BVX01JUFMz Ml9SMSkJKz0gcjRrX2ZwdS5vIHI0a19zd2l0Y2gubwogb2JqLSQoQ09ORklHX0NQVV9NSVBTNjRf UjEpCSs9IHI0a19mcHUubyByNGtfc3dpdGNoLm8KIG9iai0kKENPTkZJR19DUFVfUjYwMDApCQkr PSByNjAwMF9mcHUubyByNGtfc3dpdGNoLm8KK29iai0kKENPTkZJR19DUFVfNEtTQykJCSs9IHI0 a19zd2l0Y2gubworb2JqLSQoQ09ORklHX0NQVV80S1NEKQkJKz0gcjRrX3N3aXRjaC5vCiAKIG9i ai0kKENPTkZJR19TTVApCQkrPSBzbXAubwogCmRpZmYgLU51cnAgbGludXgtMi42LjE0LXJjMi1t aXBzY3ZzL2FyY2gvbWlwcy9saWItMzIvTWFrZWZpbGUgbGludXgtMi42LjE0LXJjMi1taXBzY3Zz LTRLU3gvYXJjaC9taXBzL2xpYi0zMi9NYWtlZmlsZQotLS0gbGludXgtMi42LjE0LXJjMi1taXBz Y3ZzL2FyY2gvbWlwcy9saWItMzIvTWFrZWZpbGUJMjAwNS0wNy0xMSAxMjowMzoyNy4wMDAwMDAw MDAgKzAyMDAKKysrIGxpbnV4LTIuNi4xNC1yYzItbWlwc2N2cy00S1N4L2FyY2gvbWlwcy9saWIt MzIvTWFrZWZpbGUJMjAwNS0xMC0wNCAwOTo0NDowOS4wMDAwMDAwMDAgKzAyMDAKQEAgLTIxLDUg KzIxLDcgQEAgb2JqLSQoQ09ORklHX0NQVV9TQjEpCQkrPSBkdW1wX3RsYi5vCiBvYmotJChDT05G SUdfQ1BVX1RYMzlYWCkJKz0gcjNrX2R1bXBfdGxiLm8KIG9iai0kKENPTkZJR19DUFVfVFg0OVhY KQkrPSBkdW1wX3RsYi5vCiBvYmotJChDT05GSUdfQ1BVX1ZSNDFYWCkJKz0gZHVtcF90bGIubwor b2JqLSQoQ09ORklHX0NQVV80S1NDKQkJKz0gZHVtcF90bGIubworb2JqLSQoQ09ORklHX0NQVV80 S1NEKQkJKz0gZHVtcF90bGIubwogCiBFWFRSQV9BRkxBR1MgOj0gJChDRkxBR1MpCmRpZmYgLU51 cnAgbGludXgtMi42LjE0LXJjMi1taXBzY3ZzL2FyY2gvbWlwcy9NYWtlZmlsZSBsaW51eC0yLjYu MTQtcmMyLW1pcHNjdnMtNEtTeC9hcmNoL21pcHMvTWFrZWZpbGUKLS0tIGxpbnV4LTIuNi4xNC1y YzItbWlwc2N2cy9hcmNoL21pcHMvTWFrZWZpbGUJMjAwNS0wOS0xNSAxMDo1MzoxMC4wMDAwMDAw MDAgKzAyMDAKKysrIGxpbnV4LTIuNi4xNC1yYzItbWlwc2N2cy00S1N4L2FyY2gvbWlwcy9NYWtl ZmlsZQkyMDA1LTEwLTA0IDA5OjI1OjIxLjAwMDAwMDAwMCArMDIwMApAQCAtMjM3LDYgKzIzNywx NCBAQCBjZmxhZ3MtJChDT05GSUdfQ1BVX1IxMDAwMCkJKz0gXAogCQkJJChjYWxsIHNldF9nY2Nm bGFncyxyMTAwMDAsbWlwczQscjgwMDAsbWlwczQsbWlwczIpIFwKIAkJCS1XYSwtLXRyYXAKIAor Y2ZsYWdzLSQoQ09ORklHX0NQVV80S1NDKQkrPSBcCisJCQkkKGNhbGwgc2V0X2djY2ZsYWdzLDRr ZWMsbWlwczMycjIscjQ2MDAsbWlwczMsbWlwczIpIFwKKwkJCS1tc21hcnRtaXBzIC1XYSwtLXRy YXAKKworY2ZsYWdzLSQoQ09ORklHX0NQVV80S1NEKQkrPSBcCisJCQkkKGNhbGwgc2V0X2djY2Zs YWdzLDRrZWMsbWlwczMycjIscjQ2MDAsbWlwczMsbWlwczIpIFwKKwkJCS1tc21hcnRtaXBzIC1X YSwtLXRyYXAKKwogaWZkZWYgQ09ORklHX0NQVV9TQjEKIGlmZGVmIENPTkZJR19TQjFfUEFTU18x X1dPUktBUk9VTkRTCiBNT0RGTEFHUwkrPSAtbXNiMS1wYXNzMS13b3JrYXJvdW5kcwpkaWZmIC1O dXJwIGxpbnV4LTIuNi4xNC1yYzItbWlwc2N2cy9hcmNoL21pcHMvbW0vY2FjaGUuYyBsaW51eC0y LjYuMTQtcmMyLW1pcHNjdnMtNEtTeC9hcmNoL21pcHMvbW0vY2FjaGUuYwotLS0gbGludXgtMi42 LjE0LXJjMi1taXBzY3ZzL2FyY2gvbWlwcy9tbS9jYWNoZS5jCTIwMDUtMDctMDYgMTQ6MDg6MTQu MDAwMDAwMDAwICswMjAwCisrKyBsaW51eC0yLjYuMTQtcmMyLW1pcHNjdnMtNEtTeC9hcmNoL21p cHMvbW0vY2FjaGUuYwkyMDA1LTEwLTA0IDA5OjQ2OjU2LjAwMDAwMDAwMCArMDIwMApAQCAtMTIw LDcgKzEyMCw4IEBAIHZvaWQgX19pbml0IGNwdV9jYWNoZV9pbml0KHZvaWQpCiAgICAgZGVmaW5l ZChDT05GSUdfQ1BVX05FVkFEQSkgfHwgZGVmaW5lZChDT05GSUdfQ1BVX1I1NDMyKSAgfHwgXAog ICAgIGRlZmluZWQoQ09ORklHX0NQVV9SNTUwMCkgIHx8IGRlZmluZWQoQ09ORklHX0NQVV9NSVBT MzJfUjEpIHx8IFwKICAgICBkZWZpbmVkKENPTkZJR19DUFVfTUlQUzY0X1IxKSB8fCBkZWZpbmVk KENPTkZJR19DUFVfVFg0OVhYKSB8fCBcCi0gICAgZGVmaW5lZChDT05GSUdfQ1BVX1JNNzAwMCkg fHwgZGVmaW5lZChDT05GSUdfQ1BVX1JNOTAwMCkKKyAgICBkZWZpbmVkKENPTkZJR19DUFVfUk03 MDAwKSB8fCBkZWZpbmVkKENPTkZJR19DUFVfUk05MDAwKSB8fCBcCisgICAgZGVmaW5lZChDT05G SUdfQ1BVXzRLU0MpICAgfHwgZGVmaW5lZChDT05GSUdfQ1BVXzRLU0QpCiAJCWxkX21tdV9yNHh4 MCgpOwogI2VuZGlmCiAJfSBlbHNlIHN3aXRjaCAoY3VycmVudF9jcHVfZGF0YS5jcHV0eXBlKSB7 CmRpZmYgLU51cnAgbGludXgtMi42LjE0LXJjMi1taXBzY3ZzL2FyY2gvbWlwcy9tbS9NYWtlZmls ZSBsaW51eC0yLjYuMTQtcmMyLW1pcHNjdnMtNEtTeC9hcmNoL21pcHMvbW0vTWFrZWZpbGUKLS0t IGxpbnV4LTIuNi4xNC1yYzItbWlwc2N2cy9hcmNoL21pcHMvbW0vTWFrZWZpbGUJMjAwNS0wNy0x NCAxNDowNTowNi4wMDAwMDAwMDAgKzAyMDAKKysrIGxpbnV4LTIuNi4xNC1yYzItbWlwc2N2cy00 S1N4L2FyY2gvbWlwcy9tbS9NYWtlZmlsZQkyMDA1LTEwLTA0IDA5OjQ1OjE3LjAwMDAwMDAwMCAr MDIwMApAQCAtMjYsNiArMjYsOCBAQCBvYmotJChDT05GSUdfQ1BVX1NCMSkJCSs9IGMtc2IxLm8g Y2Vyci1zCiBvYmotJChDT05GSUdfQ1BVX1RYMzlYWCkJKz0gYy10eDM5Lm8gcGctcjRrLm8gdGxi LXIzay5vCiBvYmotJChDT05GSUdfQ1BVX1RYNDlYWCkJKz0gYy1yNGsubyBjZXgtZ2VuLm8gcGct cjRrLm8gdGxiLXI0ay5vCiBvYmotJChDT05GSUdfQ1BVX1ZSNDFYWCkJKz0gYy1yNGsubyBjZXgt Z2VuLm8gcGctcjRrLm8gdGxiLXI0ay5vCitvYmotJChDT05GSUdfQ1BVXzRLU0MpCQkrPSBjLXI0 ay5vIGNleC1nZW4ubyBwZy1yNGsubyB0bGItcjRrLm8KK29iai0kKENPTkZJR19DUFVfNEtTRCkJ CSs9IGMtcjRrLm8gY2V4LWdlbi5vIHBnLXI0ay5vIHRsYi1yNGsubwogCiBvYmotJChDT05GSUdf SVAyMl9DUFVfU0NBQ0hFKQkrPSBzYy1pcDIyLm8KIG9iai0kKENPTkZJR19SNTAwMF9DUFVfU0NB Q0hFKSAgKz0gc2MtcjVrLm8KZGlmZiAtTnVycCBsaW51eC0yLjYuMTQtcmMyLW1pcHNjdnMvaW5j bHVkZS9hc20tbWlwcy9tb2R1bGUuaCBsaW51eC0yLjYuMTQtcmMyLW1pcHNjdnMtNEtTeC9pbmNs dWRlL2FzbS1taXBzL21vZHVsZS5oCi0tLSBsaW51eC0yLjYuMTQtcmMyLW1pcHNjdnMvaW5jbHVk ZS9hc20tbWlwcy9tb2R1bGUuaAkyMDA1LTA5LTE0IDEyOjM1OjM3LjAwMDAwMDAwMCArMDIwMAor KysgbGludXgtMi42LjE0LXJjMi1taXBzY3ZzLTRLU3gvaW5jbHVkZS9hc20tbWlwcy9tb2R1bGUu aAkyMDA1LTEwLTA0IDA5OjU1OjM0LjAwMDAwMDAwMCArMDIwMApAQCAtMTEzLDcgKzExMywxMSBA QCBzZWFyY2hfbW9kdWxlX2RiZXRhYmxlcyh1bnNpZ25lZCBsb25nIGFkCiAjZGVmaW5lIE1PRFVM RV9QUk9DX0ZBTUlMWSAiUk05MDAwIgogI2VsaWYgZGVmaW5lZCBDT05GSUdfQ1BVX1NCMQogI2Rl ZmluZSBNT0RVTEVfUFJPQ19GQU1JTFkgIlNCMSIKLSNlbGlmCisjZWxpZiBkZWZpbmVkIENPTkZJ R19DUFVfNEtTQworI2RlZmluZSBNT0RVTEVfUFJPQ19GQU1JTFkgIjRLU0MiCisjZWxpZiBkZWZp bmVkIENPTkZJR19DUFVfNEtTRAorI2RlZmluZSBNT0RVTEVfUFJPQ19GQU1JTFkgIjRLU0QiCisj ZWxzZQogI2Vycm9yIE1PRFVMRV9QUk9DX0ZBTUlMWSB1bmRlZmluZWQgZm9yIHlvdXIgcHJvY2Vz c29yIGNvbmZpZ3VyYXRpb24KICNlbmRpZgogCg== ------=_Part_3451_12254408.1128415784694-- From macro@linux-mips.org Tue Oct 4 12:34:09 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 12:34:26 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:25361 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S8133464AbVJDLeJ (ORCPT ); Tue, 4 Oct 2005 12:34:09 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 2B80CF59BA; Tue, 4 Oct 2005 13:34:04 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27403-05; Tue, 4 Oct 2005 13:34:04 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id E2C5FF5995; Tue, 4 Oct 2005 13:34:03 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j94BY6hX029176; Tue, 4 Oct 2005 13:34:07 +0200 Date: Tue, 4 Oct 2005 12:34:12 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.86.2/1109/Tue Oct 4 00:06:28 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9128 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 4 Oct 2005, Franck wrote: > This patch adds support for both 4ksc and 4ksd cpus. These cpu are > mainly used in embedded system such as smartcard or point of sell > devices as they provide some extra security features. Please send patches inline. Apart from the change to "arch/mips/kernel/cpu-probe.c", which is useful, what's the benefit of the changes? Specifically how is selecting e.g. "CPU_4KSC" meant to be different from "CPU_MIPS32_R2"? Do you want to make GCC tune your code according to a specific's CPU pipeline description? If so, then it should probably be done a bit differently and there is actually no need to differentiate between specific members of the 4K family. > Signed-off-by: Franck You should rather use your real name here. [Hmm, why am I responding to an anonym in the first place?...] Maciej From kevink@mips.com Tue Oct 4 13:37:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 13:37:50 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:44786 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133467AbVJDMhd (ORCPT ); Tue, 4 Oct 2005 13:37:33 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id j94CbMSQ029661; Tue, 4 Oct 2005 05:37:23 -0700 (PDT) Received: from [192.168.236.16] (grendel [192.168.236.16]) by mercury.mips.com (8.12.9/8.12.11) with ESMTP id j94CbK17028946; Tue, 4 Oct 2005 05:37:21 -0700 (PDT) Message-ID: <434277D5.1090603@mips.com> Date: Tue, 04 Oct 2005 14:38:45 +0200 From: "Kevin D. Kissell" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Franck , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9129 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips FWIW, the 4KSc is a strict superset of the 4Kc (anticipating *some* of the Release 2 features, but not requiring them to be used) and the 4KSd is a strict superset of the 4KE. I would not recommend configuring CPU_MIPS32_R2 for the 4KSc. Both of these cores have "SmartMIPS" MMUs, which allow for orthogonal control of Read/Write/Execute permissions on pages, using a couple of additional bits at the top of the EntryLo registers - which in turn limit the maximum usable physical address space. They also allow for variable granularity of the PageMask register, to support 1K pages. But these features are all done in a way that's backward-compatible with MIPS32, and the default reset behavior makes them look like 4Kc/4KEc. They also have some physical security and cryptography accelleration features, some of which use extended CPU state that would require some kernel context management support if anyone wanted to actually use them in Linux applications. The real point of having a CPU_4KSC config flag would be to enable building-in such support. I'm being a teeny bit vague about this, because I'm not 100% certain that all the details of "SmartMIPS" have been published. Regards, Kevin K. Maciej W. Rozycki wrote: > On Tue, 4 Oct 2005, Franck wrote: > > >>This patch adds support for both 4ksc and 4ksd cpus. These cpu are >>mainly used in embedded system such as smartcard or point of sell >>devices as they provide some extra security features. > > > Please send patches inline. > > Apart from the change to "arch/mips/kernel/cpu-probe.c", which is useful, > what's the benefit of the changes? Specifically how is selecting e.g. > "CPU_4KSC" meant to be different from "CPU_MIPS32_R2"? Do you want to > make GCC tune your code according to a specific's CPU pipeline > description? If so, then it should probably be done a bit differently and > there is actually no need to differentiate between specific members of the > 4K family. > > >>Signed-off-by: Franck > > > You should rather use your real name here. [Hmm, why am I responding to > an anonym in the first place?...] > > Maciej > From vagabon.xyz@gmail.com Tue Oct 4 14:10:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 14:10:52 +0100 (BST) Received: from zproxy.gmail.com ([64.233.162.205]:51419 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133472AbVJDNKf convert rfc822-to-8bit (ORCPT ); Tue, 4 Oct 2005 14:10:35 +0100 Received: by zproxy.gmail.com with SMTP id j2so162845nzf for ; Tue, 04 Oct 2005 06:10:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NjtO6zC9RRvKLp69D0QSG+uwYuPchrTdI4etYzQ0Zg6a/OQEcUxiCrWE+bq6vigIBAvvbgjR6DoILyE8Ch8f2vRQa4Lb2oY6eGDrtgT7f61lsfom2nioqTYd9GVGiQkHFMwI7BxaYpo4JGP29UucgF2M+VId6nIXJaGyxoGQsvI= Received: by 10.36.97.9 with SMTP id u9mr200135nzb; Tue, 04 Oct 2005 06:10:28 -0700 (PDT) Received: by 10.36.49.3 with HTTP; Tue, 4 Oct 2005 06:10:28 -0700 (PDT) Message-ID: Date: Tue, 4 Oct 2005 15:10:28 +0200 From: Franck Reply-To: Franck To: "Maciej W. Rozycki" Subject: Re: [PATCH] Add support for 4KS cpu. Cc: Ralf Baechle , linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9130 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/10/4, Maciej W. Rozycki : > On Tue, 4 Oct 2005, Franck wrote: > > > This patch adds support for both 4ksc and 4ksd cpus. These cpu are > > mainly used in embedded system such as smartcard or point of sell > > devices as they provide some extra security features. > > Please send patches inline. I can see it inlined...what email viewer are you using ? > > Apart from the change to "arch/mips/kernel/cpu-probe.c", which is useful, > what's the benefit of the changes? Specifically how is selecting e.g. > "CPU_4KSC" meant to be different from "CPU_MIPS32_R2"? Do you want to > make GCC tune your code according to a specific's CPU pipeline > description? If so, then it should probably be done a bit differently and > there is actually no need to differentiate between specific members of the > 4K family. > True, but we may have some differences in future. For example, they both implements smart mips instructions. See options passed to GCC in mips Makefile, they're different from CPU_MIPS32_R2 ones. They also have a couple of instructions very useful for cryptographic algorithms. And have some extra bits in TLB to protect pages from being execute for example. These are the main differences that I can remember. Big fat warning: I sent all support I have done for these cpu, _not_ more, _not_ less. I agree it's almost nothing but it's a start... > > Signed-off-by: Franck > Ok I'll change it. Thanks -- Franck From macro@linux-mips.org Tue Oct 4 14:29:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 14:29:48 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:54536 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S8133463AbVJDN3d (ORCPT ); Tue, 4 Oct 2005 14:29:33 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id DF498F59BA; Tue, 4 Oct 2005 15:29:27 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31526-05; Tue, 4 Oct 2005 15:29:27 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id A8404E1CA1; Tue, 4 Oct 2005 15:29:27 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j94DTVAF003188; Tue, 4 Oct 2005 15:29:31 +0200 Date: Tue, 4 Oct 2005 14:29:38 +0100 (BST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" Cc: Franck , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. In-Reply-To: <434277D5.1090603@mips.com> Message-ID: References: <434277D5.1090603@mips.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.86.2/1109/Tue Oct 4 00:06:28 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9131 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 4 Oct 2005, Kevin D. Kissell wrote: > FWIW, the 4KSc is a strict superset of the 4Kc (anticipating > *some* of the Release 2 features, but not requiring them to be > used) and the 4KSd is a strict superset of the 4KE. I would > not recommend configuring CPU_MIPS32_R2 for the 4KSc. Well, the patch asked GCC to use the instruction set of the "4kec" CPU for both (and also the "mips32r2" ISA, but that's overridden by the former), so it must have been incorrect in the first place -- I have only referred to this. > They also have some physical security and cryptography accelleration > features, some of which use extended CPU state that would > require some kernel context management support if anyone wanted > to actually use them in Linux applications. The real point of > having a CPU_4KSC config flag would be to enable building-in > such support. This would make sense, but I'm afraid the proposal was far from that... Maciej From kevink@mips.com Tue Oct 4 14:53:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 14:53:51 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:2291 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133472AbVJDNxf (ORCPT ); Tue, 4 Oct 2005 14:53:35 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id j94DrOLM029928; Tue, 4 Oct 2005 06:53:24 -0700 (PDT) Received: from [192.168.236.16] (grendel [192.168.236.16]) by mercury.mips.com (8.12.9/8.12.11) with ESMTP id j94DrO17000018; Tue, 4 Oct 2005 06:53:25 -0700 (PDT) Message-ID: <434289A7.50007@mips.com> Date: Tue, 04 Oct 2005 15:54:47 +0200 From: "Kevin D. Kissell" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Franck , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. References: <434277D5.1090603@mips.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9132 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > On Tue, 4 Oct 2005, Kevin D. Kissell wrote: > > >>FWIW, the 4KSc is a strict superset of the 4Kc (anticipating >>*some* of the Release 2 features, but not requiring them to be >>used) and the 4KSd is a strict superset of the 4KE. I would >>not recommend configuring CPU_MIPS32_R2 for the 4KSc. > > > Well, the patch asked GCC to use the instruction set of the "4kec" CPU > for both (and also the "mips32r2" ISA, but that's overridden by the > former), so it must have been incorrect in the first place Which was sort-of why I replied. In particular, the MIPS32R2 bitfield instructions will probably cause a reserved instruction fault on a 4KSc. Regards, Kevin K. From macro@linux-mips.org Tue Oct 4 14:54:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 14:54:36 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:8206 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S3458576AbVJDNyN (ORCPT ); Tue, 4 Oct 2005 14:54:13 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id EBC7EF5A24; Tue, 4 Oct 2005 15:54:08 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08045-10; Tue, 4 Oct 2005 15:54:08 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id ABAF6F5A22; Tue, 4 Oct 2005 15:54:08 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j94DsCKg004509; Tue, 4 Oct 2005 15:54:12 +0200 Date: Tue, 4 Oct 2005 14:54:20 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.86.2/1109/Tue Oct 4 00:06:28 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9133 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 4 Oct 2005, Franck wrote: > > Please send patches inline. > > I can see it inlined...what email viewer are you using ? Well, inlined means straight in the body rather than as a MIME attachment -- even if you use "Content-Disposition: inline", it's still one. > True, but we may have some differences in future. For example, they > both implements smart mips instructions. See options passed to GCC in > mips Makefile, they're different from CPU_MIPS32_R2 ones. They also > have a couple of instructions very useful for cryptographic See my other comment in this thread. As to the SmartMIPS/crypto instructions -- unless they are going to be emitted by GCC for the kernel build (which I seriously doubt), there is no point in enabling them. > algorithms. And have some extra bits in TLB to protect pages from > being execute for example. These are the main differences that I can Now that may be of potential interest of the kernel, but again, that's in principle probably not specific to these processors, so that should be a separate option; if possible one selected at the run time only (hint, hint!). > remember. Big fat warning: I sent all support I have done for these > cpu, _not_ more, _not_ less. I agree it's almost nothing but it's a > start... Well, it's probably a bit too early for inclusion, but it's certainly not for a review. By sending changes here for discussion early you may avoid a lot of hassle later when you may discover a major update is required for them to be accepted. Good luck! Maciej From ralf@linux-mips.org Tue Oct 4 15:07:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 15:07:22 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:7446 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133473AbVJDOHD (ORCPT ); Tue, 4 Oct 2005 15:07:03 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j94E6tdP014120; Tue, 4 Oct 2005 15:06:55 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j94E6s3v014112; Tue, 4 Oct 2005 15:06:54 +0100 Date: Tue, 4 Oct 2005 15:06:54 +0100 From: Ralf Baechle To: Franck Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. Message-ID: <20051004140654.GC2725@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9134 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 04, 2005 at 10:49:44AM +0200, Franck wrote: > This patch adds support for both 4ksc and 4ksd cpus. These cpu are > mainly used in embedded system such as smartcard or point of sell > devices as they provide some extra security features. So I've applied the cpu-probe.c part. Thanks, Ralf From ralf@linux-mips.org Tue Oct 4 15:17:27 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 15:17:43 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:18450 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133473AbVJDOR1 (ORCPT ); Tue, 4 Oct 2005 15:17:27 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j94EHKvj014452; Tue, 4 Oct 2005 15:17:20 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j94EHKas014451; Tue, 4 Oct 2005 15:17:20 +0100 Date: Tue, 4 Oct 2005 15:17:20 +0100 From: Ralf Baechle To: Franck Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. Message-ID: <20051004141720.GD2725@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9135 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 04, 2005 at 03:10:28PM +0200, Franck wrote: > > > This patch adds support for both 4ksc and 4ksd cpus. These cpu are > > > mainly used in embedded system such as smartcard or point of sell > > > devices as they provide some extra security features. > > > > Please send patches inline. > > I can see it inlined...what email viewer are you using ? The primary reason is that patches will be quoted and commented in email just like text. The attachment handling in most mail clients makes this unnecessarily painful. Ralf From vagabon.xyz@gmail.com Tue Oct 4 16:10:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 16:11:25 +0100 (BST) Received: from zproxy.gmail.com ([64.233.162.205]:64899 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133466AbVJDPK6 convert rfc822-to-8bit (ORCPT ); Tue, 4 Oct 2005 16:10:58 +0100 Received: by zproxy.gmail.com with SMTP id j2so184197nzf for ; Tue, 04 Oct 2005 08:10:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=azPCltp/P86HLYt955oXYKpYS2gMtU3tF3sn5UsK/rB0kubopNBGCI090+g1X89ADFw5/OjED87zcx+8nv1wHCu7xJtqw2+JTaT6noTT2zXjXi43bLtZnBOvCFEly0B/lnjnuF97Qm6tt2GufutVReg2WxtTRQradnkVYk91Z00= Received: by 10.37.18.46 with SMTP id v46mr305945nzi; Tue, 04 Oct 2005 08:10:52 -0700 (PDT) Received: by 10.36.49.3 with HTTP; Tue, 4 Oct 2005 08:10:52 -0700 (PDT) Message-ID: Date: Tue, 4 Oct 2005 17:10:52 +0200 From: Franck Reply-To: Franck To: "Maciej W. Rozycki" Subject: Re: [PATCH] Add support for 4KS cpu. Cc: Ralf Baechle , linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9136 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/10/4, Maciej W. Rozycki : > See my other comment in this thread. As to the SmartMIPS/crypto > instructions -- unless they are going to be emitted by GCC for the kernel > build (which I seriously doubt), there is no point in enabling them. > some assembly code could... > > algorithms. And have some extra bits in TLB to protect pages from > > being execute for example. These are the main differences that I can > > Now that may be of potential interest of the kernel, but again, that's in > principle probably not specific to these processors, > hmm, I'm not an expert in MIPS cpu as you guys, so can you give me an example of others processors that have such TLB features ? > > remember. Big fat warning: I sent all support I have done for these > > cpu, _not_ more, _not_ less. I agree it's almost nothing but it's a > > start... > > Well, it's probably a bit too early for inclusion, but it's certainly not > for a review. By sending changes here for discussion early you may avoid > a lot of hassle later when you may discover a major update is required for > them to be accepted. Good luck! Actually Ralf asked for it in a previous thread. Thanks -- Franck From vagabon.xyz@gmail.com Tue Oct 4 16:18:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 16:18:55 +0100 (BST) Received: from zproxy.gmail.com ([64.233.162.192]:49796 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133474AbVJDPSi convert rfc822-to-8bit (ORCPT ); Tue, 4 Oct 2005 16:18:38 +0100 Received: by zproxy.gmail.com with SMTP id j2so185772nzf for ; Tue, 04 Oct 2005 08:18:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dYStpcyIUwIWUsQTElWd8e+TncQNQmdpKN9VuLdj/q9EfLiUmXiyjRt3x/0HPa3SiLVWsIdNpYKc2tog7EscYXfdE7byLy1WzVBGMzEcMDdf7WZzqQa2uWws2mMZQCC0WRl8sdqnBROiPrm1r/hX/qU5ZvzvdzEQ6nWn40ASlyY= Received: by 10.36.224.42 with SMTP id w42mr309975nzg; Tue, 04 Oct 2005 08:18:26 -0700 (PDT) Received: by 10.36.49.3 with HTTP; Tue, 4 Oct 2005 08:18:26 -0700 (PDT) Message-ID: Date: Tue, 4 Oct 2005 17:18:26 +0200 From: Franck Reply-To: Franck To: "Kevin D. Kissell" Subject: Re: [PATCH] Add support for 4KS cpu. Cc: "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org In-Reply-To: <434289A7.50007@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <434277D5.1090603@mips.com> <434289A7.50007@mips.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9137 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/10/4, Kevin D. Kissell : > > Well, the patch asked GCC to use the instruction set of the "4kec" CPU > > for both (and also the "mips32r2" ISA, but that's overridden by the > > former), so it must have been incorrect in the first place > > Which was sort-of why I replied. In particular, the MIPS32R2 bitfield > instructions will probably cause a reserved instruction fault on a 4KSc. > should I pass these options to GCC for 4KSc ? cflags-$(CONFIG_CPU_4KSC) += \ $(call set_gccflags,4kc,mips32r1,r4600,mips3,mips2) \ -msmartmips -Wa,--trap Thanks -- Franck From macro@linux-mips.org Tue Oct 4 17:01:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 17:01:51 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:7949 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S8133470AbVJDQBb (ORCPT ); Tue, 4 Oct 2005 17:01:31 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 8ABCAF59C8; Tue, 4 Oct 2005 18:01:24 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23821-01; Tue, 4 Oct 2005 18:01:24 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 49F69E1CD3; Tue, 4 Oct 2005 18:01:24 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j94G1ST0012171; Tue, 4 Oct 2005 18:01:28 +0200 Date: Tue, 4 Oct 2005 17:01:37 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Cc: "Kevin D. Kissell" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. In-Reply-To: Message-ID: References: <434277D5.1090603@mips.com> <434289A7.50007@mips.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.86.2/1109/Tue Oct 4 00:06:28 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9138 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 4 Oct 2005, Franck wrote: > should I pass these options to GCC for 4KSc ? > > cflags-$(CONFIG_CPU_4KSC) += \ > $(call set_gccflags,4kc,mips32r1,r4600,mips3,mips2) \ > -msmartmips -Wa,--trap s/mips32r1/mips32/, otherwise OK. But since you seem to use SDE, you may as well just use "4ksc" (and possibly skip "-msmartmips" as it's implied); similarly for "4ksd". Unfortunately documentation on what CPU types are accepted seems to be incomplete -- use `gcc -v --help' to see which ones are actually available. Maciej From macro@linux-mips.org Tue Oct 4 18:11:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 18:11:38 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:18955 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S8133474AbVJDRLV (ORCPT ); Tue, 4 Oct 2005 18:11:21 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id D3000F5A0A; Tue, 4 Oct 2005 19:11:11 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12281-05; Tue, 4 Oct 2005 19:11:11 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 8E92CE1C7D; Tue, 4 Oct 2005 19:11:11 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j94HBG22016592; Tue, 4 Oct 2005 19:11:16 +0200 Date: Tue, 4 Oct 2005 18:11:26 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.86.2/1109/Tue Oct 4 00:06:28 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9139 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 4 Oct 2005, Franck wrote: > > See my other comment in this thread. As to the SmartMIPS/crypto > > instructions -- unless they are going to be emitted by GCC for the kernel > > build (which I seriously doubt), there is no point in enabling them. > > some assembly code could... In which case it has to be specific to the configuration used anyway and may just locally enable whatever instructions are needed (".set smartmips", etc.) and be enabled itself based on configuration, either at the run time, if possible and reasonable, or using a CONFIG_* option. > hmm, I'm not an expert in MIPS cpu as you guys, so can you give me an > example of others processors that have such TLB features ? Well, the extensions are a part of the SmartMIPS ASE, so they are certainly not bound to any particular CPU type. Maciej From vagabon.xyz@gmail.com Tue Oct 4 18:33:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Oct 2005 18:33:35 +0100 (BST) Received: from zproxy.gmail.com ([64.233.162.206]:54191 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133479AbVJDRdT convert rfc822-to-8bit (ORCPT ); Tue, 4 Oct 2005 18:33:19 +0100 Received: by zproxy.gmail.com with SMTP id j2so212696nzf for ; Tue, 04 Oct 2005 10:33:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YTCE7NtIAtCUlUAX/vxctv2AshU52Bl2yi4+eppALyhlYD0ojQnDKX5N007+S9HhTGIpnppSNNoie0Qfy2r7IVfDHEPDK6MDrMBrJmHFx4UOM/4tqzJ6xlV1prMJz5WDesW2Az2m/oDgtpxl8X0FfvPD7d9mHxqQuqGxP+lP1b4= Received: by 10.36.97.9 with SMTP id u9mr459211nzb; Tue, 04 Oct 2005 10:33:13 -0700 (PDT) Received: by 10.36.49.3 with HTTP; Tue, 4 Oct 2005 10:33:13 -0700 (PDT) Message-ID: Date: Tue, 4 Oct 2005 19:33:13 +0200 From: Franck Reply-To: Franck To: "Maciej W. Rozycki" Subject: Re: [PATCH] Add support for 4KS cpu. Cc: "Kevin D. Kissell" , Ralf Baechle , linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <434277D5.1090603@mips.com> <434289A7.50007@mips.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9140 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/10/4, Maciej W. Rozycki : > On Tue, 4 Oct 2005, Franck wrote: > > > should I pass these options to GCC for 4KSc ? > > > > cflags-$(CONFIG_CPU_4KSC) += \ > > $(call set_gccflags,4kc,mips32r1,r4600,mips3,mips2) \ > > -msmartmips -Wa,--trap > > s/mips32r1/mips32/, otherwise OK. > > But since you seem to use SDE, you may as well just use "4ksc" (and > possibly skip "-msmartmips" as it's implied); similarly for "4ksd". > Unfortunately documentation on what CPU types are accepted seems to be > incomplete -- use `gcc -v --help' to see which ones are actually > available. > maybe something like these are better (I removed last parameter since it's no more used) ? cflags-$(CONFIG_CPU_4KSC) += \ $(call set_gccflags,4ksc,mips32,4kc,mips32) \ -Wa,--trap cflags-$(CONFIG_CPU_4KSD) += \ $(call set_gccflags,4ksd,mips32r2,4kec,mips32r2) \ -Wa,--trap Thanks -- Franck From ddaney@avtrex.com Wed Oct 5 05:11:09 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 05:11:26 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:38686 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133500AbVJEELJ (ORCPT ); Wed, 5 Oct 2005 05:11:09 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Oct 2005 21:11:07 -0700 Message-ID: <4343525A.6080605@avtrex.com> Date: Tue, 04 Oct 2005 21:11:06 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Where is op_model_mipsxx.c ? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2005 04:11:07.0021 (UTC) FILETIME=[CF3433D0:01C5C962] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9141 X-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 I noticed this in the Makefile for the OProfile directory for mips: oprofile-$(CONFIG_CPU_MIPS32_R1) += op_model_mipsxx.o The file op_model_mipsxx.c does not seem to exist. Which implies to me that someone was working on making it work for MIPS32, but didn't quite finish. I want to start hacking on OProfile for a MIPS32 based system and thought it might make a nice starting point. If the missing file exists would its author mind making it available to me? Thanks, David Daney From ddaney@avtrex.com Wed Oct 5 05:37:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 05:37:24 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:33555 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133498AbVJEEhE (ORCPT ); Wed, 5 Oct 2005 05:37:04 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Oct 2005 21:37:02 -0700 Message-ID: <4343586E.4030703@avtrex.com> Date: Tue, 04 Oct 2005 21:37:02 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: [PATCH] fix warning in tlbex.c for CONFIG_32BIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2005 04:37:02.0413 (UTC) FILETIME=[6E4A2FD0:01C5C966] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9142 X-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 For 32 bit builds CONFIG_64BIT is not defined. Should be doing #ifdef not #if. Signed-off-by: David Daney diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c --- a/arch/mips/mm/tlbex.c +++ b/arch/mips/mm/tlbex.c @@ -513,7 +513,7 @@ static __init int rel_lo(long val) static __init void i_LA_mostly(u32 **buf, unsigned int rs, long addr) { -#if CONFIG_64BIT +#ifdef CONFIG_64BIT if (!in_compat_space_p(addr)) { i_lui(buf, rs, rel_highest(addr)); if (rel_higher(addr)) From ddaney@avtrex.com Wed Oct 5 06:06:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 06:06:28 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:33043 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133498AbVJEFGM (ORCPT ); Wed, 5 Oct 2005 06:06:12 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Oct 2005 22:06:10 -0700 Message-ID: <43435F42.9050500@avtrex.com> Date: Tue, 04 Oct 2005 22:06:10 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: [PATCH] Fix oprofile compilation error. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2005 05:06:10.0278 (UTC) FILETIME=[80193860:01C5C96A] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9143 X-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 Looks like oprofile_arch_init() was changed so that we have to fill in the caller's oprofile_operations instead of setting a pointer to ours. We can now make the prototype oprofile_operations be __initdata as a copy is being made. Signed-off-by: David Daney diff --git a/arch/mips/oprofile/common.c b/arch/mips/oprofile/common.c --- a/arch/mips/oprofile/common.c +++ b/arch/mips/oprofile/common.c @@ -68,7 +68,7 @@ static void op_mips_stop(void) on_each_cpu(model->cpu_stop, NULL, 0, 1); } -static struct oprofile_operations oprof_mips_ops = { +static struct oprofile_operations oprof_mips_ops __initdata = { .create_files = op_mips_create_files, .setup = op_mips_setup, .start = op_mips_start, @@ -76,7 +76,7 @@ static struct oprofile_operations oprof_ .cpu_type = NULL }; -int __init oprofile_arch_init(struct oprofile_operations **ops) +int __init oprofile_arch_init(struct oprofile_operations *ops) { struct op_mips_model *lmodel = NULL; int res; @@ -101,7 +101,7 @@ int __init oprofile_arch_init(struct opr model = lmodel; oprof_mips_ops.cpu_type = lmodel->cpu_type; - *ops = &oprof_mips_ops; + *ops = oprof_mips_ops; printk(KERN_INFO "oprofile: using %s performance monitoring.\n", lmodel->cpu_type); From vagabon.xyz@gmail.com Wed Oct 5 07:55:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 07:55:42 +0100 (BST) Received: from zproxy.gmail.com ([64.233.162.195]:42725 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133512AbVJEGzW convert rfc822-to-8bit (ORCPT ); Wed, 5 Oct 2005 07:55:22 +0100 Received: by zproxy.gmail.com with SMTP id j2so54320nzf for ; Tue, 04 Oct 2005 23:55:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bCa3nNpPS3nMPWhU19IEwggS/VVcOd2ErptiVMF+8mB//10eD4H7pwXMKDVpMGQjnu2ql2+/Sx6mv6QEY1Ker0h4C29vIb5OBB2MNqVWDBgSC2wWrbeP6R7/KHaAb8zPlI+ynCf3q153UzT7NsNjewr6VcZoFILgSACOdFVfxWE= Received: by 10.36.138.5 with SMTP id l5mr219646nzd; Tue, 04 Oct 2005 23:55:16 -0700 (PDT) Received: by 10.36.49.3 with HTTP; Tue, 4 Oct 2005 23:55:15 -0700 (PDT) Message-ID: Date: Wed, 5 Oct 2005 08:55:15 +0200 From: Franck Reply-To: Franck To: "Maciej W. Rozycki" Subject: Re: [PATCH] Add support for 4KS cpu. Cc: "Kevin D. Kissell" , Ralf Baechle , linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <434277D5.1090603@mips.com> <434289A7.50007@mips.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9144 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/10/4, Franck : > > But since you seem to use SDE, you may as well just use "4ksc" (and > > possibly skip "-msmartmips" as it's implied); similarly for "4ksd". > > Unfortunately documentation on what CPU types are accepted seems to be > > incomplete -- use `gcc -v --help' to see which ones are actually > > available. > > > > maybe something like these are better (I removed last parameter since > it's no more used) ? > > cflags-$(CONFIG_CPU_4KSC) += \ > $(call set_gccflags,4ksc,mips32,4kc,mips32) \ > -Wa,--trap > > cflags-$(CONFIG_CPU_4KSD) += \ > $(call set_gccflags,4ksd,mips32r2,4kec,mips32r2) \ > -Wa,--trap > Actually it would be better to let smartmips options in case we use fallback options: Thanks -- Franck From vagabon.xyz@gmail.com Wed Oct 5 08:00:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 08:00:52 +0100 (BST) Received: from zproxy.gmail.com ([64.233.162.195]:34320 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133513AbVJEHAg convert rfc822-to-8bit (ORCPT ); Wed, 5 Oct 2005 08:00:36 +0100 Received: by zproxy.gmail.com with SMTP id j2so54729nzf for ; Wed, 05 Oct 2005 00:00:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QMpT7+4jXabXDYaB8mUzIMiuCUHFy1Jvc/yQQN4eJiTFqInwxBm8ngZyX+fVTj3qqtnjZYGTA3vFL/o/uSZRh+dMSnychnOh6bJXq+2mX/xYzczYSDRTQOC1pFkHaTirGpCZ7mRa2kSIsxleymChLJ1hotWRTio1+OqoDYwzNzQ= Received: by 10.36.43.8 with SMTP id q8mr214417nzq; Wed, 05 Oct 2005 00:00:30 -0700 (PDT) Received: by 10.36.49.3 with HTTP; Wed, 5 Oct 2005 00:00:30 -0700 (PDT) Message-ID: Date: Wed, 5 Oct 2005 09:00:30 +0200 From: Franck Reply-To: Franck To: "Kevin D. Kissell" Subject: Re: [PATCH] Add support for 4KS cpu. Cc: "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org In-Reply-To: <434277D5.1090603@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <434277D5.1090603@mips.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9145 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/10/4, Kevin D. Kissell : > They also have some physical security and cryptography accelleration > features, some of which use extended CPU state that would > require some kernel context management support if anyone wanted > to actually use them in Linux applications. The real point of > having a CPU_4KSC config flag would be to enable building-in > such support. > what is extended CPU state that you're talking about ? > I'm being a teeny bit vague about this, because I'm not 100% > certain that all the details of "SmartMIPS" have been published. > hmm, does that mean that smart mips extension couldn't be supported in Linux in case that this extension have not been published ? Thanks -- Franck From kevink@mips.com Wed Oct 5 10:45:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 10:45:45 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:19706 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S3465565AbVJEJp0 (ORCPT ); Wed, 5 Oct 2005 10:45:26 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id j959jFgs004784; Wed, 5 Oct 2005 02:45:15 -0700 (PDT) Received: from [192.168.236.16] (grendel [192.168.236.16]) by mercury.mips.com (8.12.9/8.12.11) with ESMTP id j959jD17024114; Wed, 5 Oct 2005 02:45:14 -0700 (PDT) Message-ID: <4343A0FE.9080808@mips.com> Date: Wed, 05 Oct 2005 11:46:38 +0200 From: "Kevin D. Kissell" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Franck CC: "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. References: <434277D5.1090603@mips.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9146 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips Franck wrote: > 2005/10/4, Kevin D. Kissell : > >>They also have some physical security and cryptography accelleration >>features, some of which use extended CPU state that would >>require some kernel context management support if anyone wanted >>to actually use them in Linux applications. The real point of >>having a CPU_4KSC config flag would be to enable building-in >>such support. >> > what is extended CPU state that you're talking about ? That would be telling. ;o) Seriously, see below. >>I'm being a teeny bit vague about this, because I'm not 100% >>certain that all the details of "SmartMIPS" have been published. >> > > hmm, does that mean that smart mips extension couldn't be supported in > Linux in case that this extension have not been published ? I'm personally not a big believer in security-through-obscurity, but there are those, both inside and outside MIPS, who felt that the security of SmartMIPS cores would be enhanced if we didn't give away all of the details. As a consequence, we put off publishing the nitty-gritty details of SmartMIPS for quite a while. I note that we now have the programmers' manual on-line at www.mips.com, so I guess I'm implicitly cleared to discuss it in at least that level of detail. A key element of SmartMIPS that allows for a ~2x speedup for crypto codes that rely on extended precision math (RSA, ECC) is the combination of an extension to the Hi/Lo accumulator (called "ACX") with a special extract-and-reduce instruction ("MFLHXU"). If one wants to use that in Linux - or at least, if one wants to allow more than one thread to be able to use it at a time - one needs to save/restore ACX on the kernel stackframe, along with Hi and Lo. Regards, Kevin K. From ralf@linux-mips.org Wed Oct 5 11:44:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 11:44:59 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:29210 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3465659AbVJEKoo (ORCPT ); Wed, 5 Oct 2005 11:44:44 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j95AicIq009380; Wed, 5 Oct 2005 11:44:38 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j95AicYx009379; Wed, 5 Oct 2005 11:44:38 +0100 Date: Wed, 5 Oct 2005 11:44:38 +0100 From: Ralf Baechle To: David Daney Cc: linux-mips@linux-mips.org Subject: Re: Where is op_model_mipsxx.c ? Message-ID: <20051005104437.GG2699@linux-mips.org> References: <4343525A.6080605@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4343525A.6080605@avtrex.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9147 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 04, 2005 at 09:11:06PM -0700, David Daney wrote: > I noticed this in the Makefile for the OProfile directory for mips: > > oprofile-$(CONFIG_CPU_MIPS32_R1) += op_model_mipsxx.o > > The file op_model_mipsxx.c does not seem to exist. Which implies to me > that someone was working on making it work for MIPS32, but didn't quite > finish. > > I want to start hacking on OProfile for a MIPS32 based system and > thought it might make a nice starting point. > > If the missing file exists would its author mind making it available to me? I've got oprofile support for MIPS32 / MIPS64 style counters in the queue. It still needs some debugging to become actually useful but anyway, I'm going to check those patches into git in a few minutes. Ralf From ralf@linux-mips.org Wed Oct 5 11:53:42 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 11:53:58 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:2589 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3465659AbVJEKxm (ORCPT ); Wed, 5 Oct 2005 11:53:42 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j95Arar3009777; Wed, 5 Oct 2005 11:53:36 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j95Ara7Z009776; Wed, 5 Oct 2005 11:53:36 +0100 Date: Wed, 5 Oct 2005 11:53:36 +0100 From: Ralf Baechle To: David Daney Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix warning in tlbex.c for CONFIG_32BIT Message-ID: <20051005105336.GH2699@linux-mips.org> References: <4343586E.4030703@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4343586E.4030703@avtrex.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9148 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 04, 2005 at 09:37:02PM -0700, David Daney wrote: > Date: Tue, 04 Oct 2005 21:37:02 -0700 > From: David Daney > To: linux-mips@linux-mips.org > Subject: [PATCH] fix warning in tlbex.c for CONFIG_32BIT > Content-Type: text/plain; charset=ISO-8859-1; format=flowed ^^^^^^^^^^^^^ Applied - BUT: your mailer garbles patches ... Ralf From vagabon.xyz@gmail.com Wed Oct 5 14:21:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 14:21:27 +0100 (BST) Received: from zproxy.gmail.com ([64.233.162.199]:52012 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S3465666AbVJENVK convert rfc822-to-8bit (ORCPT ); Wed, 5 Oct 2005 14:21:10 +0100 Received: by zproxy.gmail.com with SMTP id j2so95318nzf for ; Wed, 05 Oct 2005 06:20:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WTCNu1jze6HvHhxT1/om2R18JfKQ2CdOQX3kunIVPlgUYFW1+q+v/d/tixasiwIMfXsSTUnMBk7f1BU04PXVjaZdetDX/hxOaYTeDGOx8BxsnalBuaIjDu/x1ghQ8wk5whX2evUqP1ZySf6jM4fnAUSOepW0BLUH+uJ20aqowHs= Received: by 10.36.252.78 with SMTP id z78mr520494nzh; Wed, 05 Oct 2005 06:20:59 -0700 (PDT) Received: by 10.36.49.3 with HTTP; Wed, 5 Oct 2005 06:20:59 -0700 (PDT) Message-ID: Date: Wed, 5 Oct 2005 15:20:59 +0200 From: Franck Reply-To: Franck To: "Kevin D. Kissell" Subject: Re: [PATCH] Add support for 4KS cpu. Cc: "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org In-Reply-To: <4343A0FE.9080808@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <434277D5.1090603@mips.com> <4343A0FE.9080808@mips.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9149 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/10/5, Kevin D. Kissell : > I'm personally not a big believer in security-through-obscurity, > but there are those, both inside and outside MIPS, who felt that > the security of SmartMIPS cores would be enhanced if we didn't > give away all of the details. As a consequence, we put off > publishing the nitty-gritty details of SmartMIPS for quite a while. > I note that we now have the programmers' manual on-line at www.mips.com, > so I guess I'm implicitly cleared to discuss it in at least that level > of detail. > well, I agree with you on "security-through-obscurity" point. From outside, I feel like MIPS has a lot of things to _hide_ athough that's not a good feeling for security systems. Anyways... > A key element of SmartMIPS that allows for a ~2x speedup for > crypto codes that rely on extended precision math (RSA, ECC) > is the combination of an extension to the Hi/Lo accumulator > (called "ACX") with a special extract-and-reduce instruction > ("MFLHXU"). If one wants to use that in Linux - or at least, > if one wants to allow more than one thread to be able to use > it at a time - one needs to save/restore ACX on the kernel > stackframe, along with Hi and Lo. > Correct. I must at least add this in the patch. I'll do it soon. Thanks for enlight this. -- Franck From macro@linux-mips.org Wed Oct 5 14:22:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 14:23:01 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:24079 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S3465667AbVJENWq (ORCPT ); Wed, 5 Oct 2005 14:22:46 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id D2752F596E; Wed, 5 Oct 2005 15:22:41 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21731-02; Wed, 5 Oct 2005 15:22:41 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 988DBE1D01; Wed, 5 Oct 2005 15:22:41 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j95DMhVJ003740; Wed, 5 Oct 2005 15:22:43 +0200 Date: Wed, 5 Oct 2005 14:22:51 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Cc: "Kevin D. Kissell" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Add support for 4KS cpu. In-Reply-To: Message-ID: References: <434277D5.1090603@mips.com> <434289A7.50007@mips.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.86.2/1112/Wed Oct 5 11:04:38 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9150 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 5 Oct 2005, Franck wrote: > Actually it would be better to let smartmips options in case we use > fallback options: In which case the toolchain is not going to support the "-msmartmips" option anyway... Perhaps you should just use the same options throughout as there is probably no sensible set of legacy options to fall back to. Maciej From ddaney@avtrex.com Wed Oct 5 16:48:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 16:48:24 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:29968 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S3465672AbVJEPsF (ORCPT ); Wed, 5 Oct 2005 16:48:05 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Oct 2005 08:48:02 -0700 Message-ID: <4343F5B2.3020509@avtrex.com> Date: Wed, 05 Oct 2005 08:48:02 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: [PATCH] fix warning in tlbex.c for CONFIG_32BIT References: <4343586E.4030703@avtrex.com> <20051005105336.GH2699@linux-mips.org> In-Reply-To: <20051005105336.GH2699@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2005 15:48:02.0848 (UTC) FILETIME=[2B610A00:01C5C9C4] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9151 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Tue, Oct 04, 2005 at 09:37:02PM -0700, David Daney wrote: > >>Date: Tue, 04 Oct 2005 21:37:02 -0700 >>From: David Daney >>To: linux-mips@linux-mips.org >>Subject: [PATCH] fix warning in tlbex.c for CONFIG_32BIT >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > ^^^^^^^^^^^^^ > > Applied - BUT: your mailer garbles patches ... > Some people on this list are quite adamant that patches be in-line. I was trying to see how my mailer (Thunderbird) handled this. Obviously (in hindsight) it screws things up. Sending as an attachment works well except some mailers (Not Thunderbird) cannot quote attached patches with out jumping through hoops. I don't really want to change the mailer that I am using, so I am in a bit of a bind WRT submitting patches here. FWIW other mailing lists (binutils, gcc) don't seem to have the same trouble with attached patches. David Daney From ddaney@avtrex.com Wed Oct 5 17:39:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 17:40:18 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:6688 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S3465669AbVJEQjx (ORCPT ); Wed, 5 Oct 2005 17:39:53 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Oct 2005 09:39:51 -0700 Message-ID: <434401D6.3050602@avtrex.com> Date: Wed, 05 Oct 2005 09:39:50 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: Dominic Sweetman Subject: The NUBI ... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2005 16:39:51.0100 (UTC) FILETIME=[680AA7C0:01C5C9CB] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9152 X-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 I see that there are now some interesting pages in the Wiki about the NUBI: http://www.linux-mips.org/wiki/NUBI Unfortunately there is no good way to navigate to them from the home page. You can follow the links to see a preliminary version of the specification, but I see no indication about how one would go about commenting on it. David Daney. From ralf@linux-mips.org Wed Oct 5 18:17:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 18:17:38 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:54810 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3465669AbVJERRT (ORCPT ); Wed, 5 Oct 2005 18:17:19 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j95HHDeA022959; Wed, 5 Oct 2005 18:17:13 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j95HHCPp022958; Wed, 5 Oct 2005 18:17:12 +0100 Date: Wed, 5 Oct 2005 18:17:12 +0100 From: Ralf Baechle To: David Daney Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix warning in tlbex.c for CONFIG_32BIT Message-ID: <20051005171712.GJ2699@linux-mips.org> References: <4343586E.4030703@avtrex.com> <20051005105336.GH2699@linux-mips.org> <4343F5B2.3020509@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4343F5B2.3020509@avtrex.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9153 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Oct 05, 2005 at 08:48:02AM -0700, David Daney wrote: > Some people on this list are quite adamant that patches be in-line. > > I was trying to see how my mailer (Thunderbird) handled this. Obviously > (in hindsight) it screws things up. > > Sending as an attachment works well except some mailers (Not > Thunderbird) cannot quote attached patches with out jumping through hoops. > > I don't really want to change the mailer that I am using, so I am in a > bit of a bind WRT submitting patches here. > > FWIW other mailing lists (binutils, gcc) don't seem to have the same > trouble with attached patches. Maybe a different style of work there. The submission style we're asking people to follow here is exactly the same as on linux-kernel, netdev or other kernel-related lists. I just asked somebody; this is the answer I got: I have never had any luck getting mailers to send patches in a way that no one complained about. In the end, I used this http://www.speakeasy.org/~pj99/sgi/sendpatchset I found the best way is to have a directory with patches like 001_part1.patch, 002_part2.patch etc with matching explainations in 001_part1.mail 002_part2.mail . I have a script that generates the final mails and feeds them to sendpatchset The script may not be what you want but I guess I'll be something like it to deal with the huge patchsets I'm sometimes fiddling with - like the 452 patch monster right now ... Ralf From ralf@linux-mips.org Wed Oct 5 18:31:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 18:31:45 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:46598 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3465679AbVJERb0 (ORCPT ); Wed, 5 Oct 2005 18:31:26 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j95HVK8q023452; Wed, 5 Oct 2005 18:31:20 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j95HVHf2023451; Wed, 5 Oct 2005 18:31:17 +0100 Date: Wed, 5 Oct 2005 18:31:17 +0100 From: Ralf Baechle To: David Daney Cc: linux-mips@linux-mips.org, Dominic Sweetman Subject: Re: The NUBI ... Message-ID: <20051005173117.GL2699@linux-mips.org> References: <434401D6.3050602@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <434401D6.3050602@avtrex.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9154 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Oct 05, 2005 at 09:39:50AM -0700, David Daney wrote: > I see that there are now some interesting pages in the Wiki about the NUBI: > > http://www.linux-mips.org/wiki/NUBI > > Unfortunately there is no good way to navigate to them from the home page. > > You can follow the links to see a preliminary version of the > specification, but I see no indication about how one would go about > commenting on it. You can either use the "discussion" tab at the top of every page to comment on it or alternatively if you're interested in participating in the discussion use the nubi@linux-mips.org mailing list. Ralf From vagabon.xyz@gmail.com Wed Oct 5 19:05:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Oct 2005 19:05:20 +0100 (BST) Received: from zproxy.gmail.com ([64.233.162.198]:46020 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S3465679AbVJESFE convert rfc822-to-8bit (ORCPT ); Wed, 5 Oct 2005 19:05:04 +0100 Received: by zproxy.gmail.com with SMTP id q3so155346nzb for ; Wed, 05 Oct 2005 11:04:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sHCtSOUbx2HgjLHJZ1SZ3ghj4c6kJfw3UUE2zeCV52xHdWUVAmbUy5ZYoTVEsvca7AOFUm70XXxgVBV/j8sLdN0UrKTus/OFzRyluKFWB+s9zZDDCsKX1ho0KALeXHExEiyE7FSST1RYgn0ki70PkRVZITsLZic8CKQZ5kJQbDE= Received: by 10.36.49.12 with SMTP id w12mr851105nzw; Wed, 05 Oct 2005 11:04:56 -0700 (PDT) Received: by 10.36.49.3 with HTTP; Wed, 5 Oct 2005 11:04:56 -0700 (PDT) Message-ID: Date: Wed, 5 Oct 2005 20:04:56 +0200 From: Franck Reply-To: Franck To: "Maciej W. Rozycki" Subject: Re: [PATCH] Add support for 4KS cpu. Cc: "Kevin D. Kissell" , Ralf Baechle , linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <434277D5.1090603@mips.com> <434289A7.50007@mips.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9155 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/10/5, Maciej W. Rozycki : > On Wed, 5 Oct 2005, Franck wrote: > > > Actually it would be better to let smartmips options in case we use > > fallback options: > > In which case the toolchain is not going to support the "-msmartmips" > option anyway... toolchain could support smartmips extension without supporting 4ksd specific instructions... Thanks -- Franck From aravindforl@yahoo.co.in Thu Oct 6 07:53:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 07:54:14 +0100 (BST) Received: from web8604.mail.in.yahoo.com ([202.43.219.79]:29600 "HELO web8604.mail.in.yahoo.com") by ftp.linux-mips.org with SMTP id S8133531AbVJFGx5 (ORCPT ); Thu, 6 Oct 2005 07:53:57 +0100 Received: (qmail 6980 invoked by uid 60001); 6 Oct 2005 06:53:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eVsnq4XcUIF0n3vlFv4DM0+0ICK2c26nh7/9And7ACYVOsxJBRaTGjbJP8veO4LivIHuOA+t6BTLpl825XXQb0bpa7nBVnN8mJONfDYR4PclnOKSDy10dz/8Ax2y+yGXFy41/hZrdv3H5VN0lT0dGpoyyvgBbGYO+16QZARoUyg= ; Message-ID: <20051006065332.6978.qmail@web8604.mail.in.yahoo.com> Received: from [147.243.216.4] by web8604.mail.in.yahoo.com via HTTP; Thu, 06 Oct 2005 07:53:32 BST Date: Thu, 6 Oct 2005 07:53:32 +0100 (BST) From: Arravind babu Subject: Basic question w.r.t bootloader To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9156 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: aravindforl@yahoo.co.in Precedence: bulk X-list: linux-mips Hi all, Generally how bootloader/bootflash code detects the size of RAM on the board? Is it hardcoded some where in the bootflash code or is it detected using memory chips ? Thanks in advance, Aravind. __________________________________________________________ Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com From wd@denx.de Thu Oct 6 08:29:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 08:29:51 +0100 (BST) Received: from mailout01.sul.t-online.com ([194.25.134.80]:3205 "EHLO mailout01.sul.t-online.com") by ftp.linux-mips.org with ESMTP id S8133532AbVJFH3g (ORCPT ); Thu, 6 Oct 2005 08:29:36 +0100 Received: from fwd31.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1ENQC7-0005M2-02; Thu, 06 Oct 2005 09:29:35 +0200 Received: from denx.de (SOkMwmZVre8yPsLo7eQDPyoPWdgo6abFTP+ER70FSaoInTW0cZK+46@[84.150.104.90]) by fwd31.sul.t-online.de with esmtp id 1ENQC2-0FuMQi0; Thu, 6 Oct 2005 09:29:30 +0200 Received: from atlas.denx.de (atlas.denx.de [10.0.0.14]) by denx.de (Postfix) with ESMTP id D36DD42EED; Thu, 6 Oct 2005 09:29:29 +0200 (MEST) Received: from atlas.denx.de (localhost.localdomain [127.0.0.1]) by atlas.denx.de (Postfix) with ESMTP id 068D3353D93; Thu, 6 Oct 2005 09:29:24 +0200 (MEST) To: Arravind babu Cc: linux-mips@linux-mips.org From: Wolfgang Denk Subject: Re: Basic question w.r.t bootloader Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit In-reply-to: Your message of "Thu, 06 Oct 2005 07:53:32 BST." <20051006065332.6978.qmail@web8604.mail.in.yahoo.com> Date: Thu, 06 Oct 2005 09:29:24 +0200 Message-Id: <20051006072924.068D3353D93@atlas.denx.de> X-ID: SOkMwmZVre8yPsLo7eQDPyoPWdgo6abFTP+ER70FSaoInTW0cZK+46@t-dialin.net X-TOI-MSGID: 27b933b6-027c-49bd-aef5-d132cf33b1b1 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9157 X-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 In message <20051006065332.6978.qmail@web8604.mail.in.yahoo.com> you wrote: > > Generally how bootloader/bootflash code detects > the size of RAM on the board? Is it hardcoded some > where in the bootflash code or is it detected using > memory chips ? One method is to probe addresses (at N, 2*N, 4*N etc. starting with a resonable value of N like 1 MB) until probing fails. See for example common/memsize.c in the U-Boot sources. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de The IQ of the group is the lowest IQ of a member of the group divided by the number of people in the group. From giometti@enneenne.com Thu Oct 6 08:33:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 08:34:10 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:57745 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133532AbVJFHdr (ORCPT ); Thu, 6 Oct 2005 08:33:47 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1ENQG9-0006c3-00 for ; Thu, 06 Oct 2005 09:33:45 +0200 Date: Thu, 6 Oct 2005 09:33:45 +0200 From: Rodolfo Giometti To: linux-mips@linux-mips.org Subject: au1x00 usb device status Message-ID: <20051006073345.GB17583@gundam.enneenne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Programmi e soluzioni GNU/Linux X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9158 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips I'm trying to enable usb device support on an au1x00 based board, but I notice that such support is still not ported to 2.6 nor to usb gadget. Does someone working on it in order to coordinate the job? :) Thanks in advance, Rodolfo -- GNU/Linux Solutions e-mail: giometti@linux.it Linux Device Driver giometti@enneenne.com Embedded Systems home page: giometti.enneenne.com UNIX programming phone: +39 349 2432127 From swamim@sankhya.com Thu Oct 6 11:22:14 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 11:22:35 +0100 (BST) Received: from [210.212.208.205] ([210.212.208.205]:51072 "EHLO pdns.sankhya.co.in") by ftp.linux-mips.org with ESMTP id S8133538AbVJFKWO (ORCPT ); Thu, 6 Oct 2005 11:22:14 +0100 Received: from sankhya.com (sankhya-external [192.168.1.2]) by pdns.sankhya.co.in (8.12.11/8.12.10) with ESMTP id j96AOFx1017978 for ; Thu, 6 Oct 2005 15:54:17 +0530 Received: from sankhya.com (localhost [127.0.0.1]) by sankhya.com (8.12.8/8.12.5) with ESMTP id j96ArSeb005998 for ; Thu, 6 Oct 2005 16:23:28 +0530 Received: from localhost (swamim@localhost) by sankhya.com (8.12.8/8.12.5/Submit) with ESMTP id j96ArOXc005990 for ; Thu, 6 Oct 2005 16:23:28 +0530 Date: Thu, 6 Oct 2005 16:23:24 +0530 (IST) From: M Ranga Swami Reddy To: linux-mips@linux-mips.org Subject: kernel build and test info for mips malta board Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9159 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: swamim@sankhya.com Precedence: bulk X-list: linux-mips Hello, What is the latest kernel version tested with MIPS MALTA board? Your reply highly appreciated. Many Thanks, Swami From ppopov@embeddedalley.com Thu Oct 6 16:33:14 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 16:33:32 +0100 (BST) Received: from smtp102.biz.mail.mud.yahoo.com ([68.142.200.237]:15009 "HELO smtp102.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133541AbVJFPdO (ORCPT ); Thu, 6 Oct 2005 16:33:14 +0100 Received: (qmail 61886 invoked from network); 6 Oct 2005 15:33:06 -0000 Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp102.biz.mail.mud.yahoo.com with SMTP; 6 Oct 2005 15:33:06 -0000 Subject: Re: au1x00 usb device status From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Rodolfo Giometti Cc: "'linux-mips@linux-mips.org'" In-Reply-To: <20051006073345.GB17583@gundam.enneenne.com> References: <20051006073345.GB17583@gundam.enneenne.com> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Thu, 06 Oct 2005 08:32:52 -0700 Message-Id: <1128612772.9971.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9160 X-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@embeddedalley.com Precedence: bulk X-list: linux-mips On Thu, 2005-10-06 at 09:33 +0200, Rodolfo Giometti wrote: > I'm trying to enable usb device support on an au1x00 based board, but > I notice that such support is still not ported to 2.6 nor to usb > gadget. USB Host should be working fine. USB Gadget on the Au1000,1100,1500,1550 just won't happen due to hw limitations. USB host and gadget on the 1200 are on hold at the moment. I'll let you know if that moves forward. We already split out the pci bus dependencies from the echi driver and sent David the patches. They'll be going upstream soon. Adding ehci host support for the 1200 will be much easier then. Pete From anemo@mba.ocn.ne.jp Thu Oct 6 16:45:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 16:45:38 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:47066 "EHLO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with ESMTP id S8133547AbVJFPpR (ORCPT ); Thu, 6 Oct 2005 16:45:17 +0100 Received: from localhost (p6235-ipad201funabasi.chiba.ocn.ne.jp [222.146.69.235]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 532848A98; Fri, 7 Oct 2005 00:45:15 +0900 (JST) Date: Fri, 07 Oct 2005 00:43:59 +0900 (JST) Message-Id: <20051007.004359.25909892.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] protect CU1 bit manipulation from preempt From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9161 X-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 The ptrace temporarily enable CP1 without fpu-ownership. These regions should be protected from preempt. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -126,10 +126,12 @@ int ptrace_getfpregs (struct task_struct __put_user (child->thread.fpu.hard.fcr31, data + 64); + preempt_disable(); flags = read_c0_status(); __enable_fpu(); __asm__ __volatile__("cfc1\t%0,$0" : "=r" (tmp)); write_c0_status(flags); + preempt_enable(); __put_user (tmp, data + 65); } else { __put_user (child->thread.fpu.soft.fcr31, data + 64); @@ -284,10 +286,12 @@ asmlinkage int sys_ptrace(long request, if (!cpu_has_fpu) break; + preempt_disable(); flags = read_c0_status(); __enable_fpu(); __asm__ __volatile__("cfc1\t%0,$0": "=r" (tmp)); write_c0_status(flags); + preempt_enable(); break; } case DSP_BASE ... DSP_BASE + 5: { diff --git a/arch/mips/kernel/ptrace32.c b/arch/mips/kernel/ptrace32.c --- a/arch/mips/kernel/ptrace32.c +++ b/arch/mips/kernel/ptrace32.c @@ -191,10 +191,12 @@ asmlinkage int sys32_ptrace(int request, if (!cpu_has_fpu) break; + preempt_disable(); flags = read_c0_status(); __enable_fpu(); __asm__ __volatile__("cfc1\t%0,$0": "=r" (tmp)); write_c0_status(flags); + preempt_enable(); break; } case DSP_BASE ... DSP_BASE + 5: From giometti@enneenne.com Thu Oct 6 16:47:09 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 16:47:28 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:3225 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133547AbVJFPrJ (ORCPT ); Thu, 6 Oct 2005 16:47:09 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1ENXxW-0006d4-00; Thu, 06 Oct 2005 17:47:02 +0200 Date: Thu, 6 Oct 2005 17:47:02 +0200 From: Rodolfo Giometti To: Pete Popov Cc: "'linux-mips@linux-mips.org'" Subject: Re: au1x00 usb device status Message-ID: <20051006154702.GA11086@gundam.enneenne.com> References: <20051006073345.GB17583@gundam.enneenne.com> <1128612772.9971.34.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <1128612772.9971.34.camel@localhost.localdomain> Organization: Programmi e soluzioni GNU/Linux X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9162 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 06, 2005 at 08:32:52AM -0700, Pete Popov wrote: > USB Host should be working fine. USB Gadget on the Au1000,1100,1500,1550 > just won't happen due to hw limitations. USB host and gadget on the 1200 Thanks for your answer! Can you please explain to me (in brief :) which hw limitations are you talking about? Do you mean that usb device support in Linux cannot be implemented, or just that this can be done but with some restriction? Thanks for your help, Rodolfo --=20 GNU/Linux Solutions e-mail: giometti@linux.it Linux Device Driver giometti@enneenne.com Embedded Systems home page: giometti.enneenne.com UNIX programming phone: +39 349 2432127 --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDRUb2QaTCYNJaVjMRAsZiAJ9oqksI9ASCkVwErXgFzeR+hAm6YgCgsHiw jNYFtD7mVWmAmgAMFNA5re4= =Dt0k -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From ralf@linux-mips.org Thu Oct 6 17:41:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 17:41:15 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:64014 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133533AbVJFQlA (ORCPT ); Thu, 6 Oct 2005 17:41:00 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j96Getud002174; Thu, 6 Oct 2005 17:40:55 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j96Geq7f002173; Thu, 6 Oct 2005 17:40:52 +0100 Date: Thu, 6 Oct 2005 17:40:52 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] protect CU1 bit manipulation from preempt Message-ID: <20051006164052.GB15275@linux-mips.org> References: <20051007.004359.25909892.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051007.004359.25909892.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9163 X-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, Oct 07, 2005 at 12:43:59AM +0900, Atsushi Nemoto wrote: > The ptrace temporarily enable CP1 without fpu-ownership. These > regions should be protected from preempt. Applied with quite some additions to take care of the MT ASE as well. Ralf From ppopov@embeddedalley.com Thu Oct 6 17:42:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 17:43:00 +0100 (BST) Received: from smtp102.biz.mail.mud.yahoo.com ([68.142.200.237]:39017 "HELO smtp102.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133533AbVJFQmi (ORCPT ); Thu, 6 Oct 2005 17:42:38 +0100 Received: (qmail 87433 invoked from network); 6 Oct 2005 16:41:27 -0000 Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain) by smtp102.biz.mail.mud.yahoo.com with SMTP; 6 Oct 2005 16:41:27 -0000 Subject: Re: au1x00 usb device status From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Rodolfo Giometti Cc: "'linux-mips@linux-mips.org'" In-Reply-To: <20051006154702.GA11086@gundam.enneenne.com> References: <20051006073345.GB17583@gundam.enneenne.com> <1128612772.9971.34.camel@localhost.localdomain> <20051006154702.GA11086@gundam.enneenne.com> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Thu, 06 Oct 2005 09:41:14 -0700 Message-Id: <1128616874.9971.47.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9164 X-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@embeddedalley.com Precedence: bulk X-list: linux-mips On Thu, 2005-10-06 at 17:47 +0200, Rodolfo Giometti wrote: > On Thu, Oct 06, 2005 at 08:32:52AM -0700, Pete Popov wrote: > > USB Host should be working fine. USB Gadget on the Au1000,1100,1500,1550 > > just won't happen due to hw limitations. USB host and gadget on the 1200 > > Thanks for your answer! > > Can you please explain to me (in brief :) which hw limitations are you > talking about? Do you mean that usb device support in Linux cannot be > implemented, or just that this can be done but with some restriction? Timing issues with the Au1x00 (not the au1200) make the Linux gadget implementation extremely difficult to support. If you don't service the usb interrupt within a certain amount of time, you lose the status and the gadget loses its state. Pete From raiko@niisi.msk.ru Thu Oct 6 18:24:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 18:24:31 +0100 (BST) Received: from t111.niisi.ras.ru ([193.232.173.111]:42929 "EHLO t111.niisi.ras.ru") by ftp.linux-mips.org with ESMTP id S8133550AbVJFRYH (ORCPT ); Thu, 6 Oct 2005 18:24:07 +0100 Received: from t111.niisi.ras.ru (localhost [127.0.0.1]) by t111.niisi.ras.ru (8.13.4/8.12.11) with ESMTP id j96HO6UB032192 for ; Thu, 6 Oct 2005 21:24:06 +0400 Received: (from uucp@localhost) by t111.niisi.ras.ru (8.13.4/8.13.4/Submit) with UUCP id j96HO6QF032189 for linux-mips@linux-mips.org; Thu, 6 Oct 2005 21:24:06 +0400 Received: from [192.168.173.2] (t34 [193.232.173.34]) by aa19.niisi.msk.ru (8.12.8/8.12.8) with ESMTP id j96HNp3t021489 for ; Thu, 6 Oct 2005 21:23:51 +0400 Message-ID: <43455D2D.1010901@niisi.msk.ru> Date: Thu, 06 Oct 2005 21:21:49 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Bug in the syscall tracing code Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9165 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: raiko@niisi.msk.ru Precedence: bulk X-list: linux-mips Hello, The story continues. The last fix of the syscall tracing code was wrong, unfortunately. (The bug was a user could invoke any function in the kernel. The fix was not to use t2 as pointer to a syscall, s0 was chosen for it.) The problem we discovered is a few syscalls do SAVE_STATIC (those declared as save_static_function), so s0 (which holds pointer to the syscall at the time the syscall is invoked) is saved on the stack overwriting a value saved from the process being traced. No wonder, s0 that restored on syscall exit differs from s0 saved on syscall enter. See, arch/mips/kernel/scall32-o32.S, syscall_trace_entry, for example. The rest of ABIs are the same. There are several ways to fix this: 1. Make syscall handling code to be close to other arches. I mean, check for the trace flag first, then parse arguments and invoke a syscall. 2. Remove save_static_functions and do SAVE_STATIC early for several syscalls (yes, one big switch or its asm equivalent). 3. Store t2 in pt_regs (it means we have to expand this structure). 4. I know there should be yet another way. Any ideas ? Regards, Gleb. From earlm@mips.com Thu Oct 6 18:59:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 18:59:44 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:52097 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133554AbVJFR70 convert rfc822-to-8bit (ORCPT ); Thu, 6 Oct 2005 18:59:26 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id j96HxItW012648; Thu, 6 Oct 2005 10:59:18 -0700 (PDT) Received: from exchange.MIPS.COM (exchange [192.168.20.29]) by mercury.mips.com (8.12.9/8.12.11) with ESMTP id j96HxH17003741; Thu, 6 Oct 2005 10:59:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: Basic question w.r.t bootloader Date: Thu, 6 Oct 2005 10:59:16 -0700 Message-ID: <3CB54817FDF733459B230DD27C690CEC010493E5@Exchange.MIPS.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Basic question w.r.t bootloader Thread-Index: AcXKR9IIYLZO+At/QcS2ik0hx9cfSwAVkVaA From: "Mitchell, Earl" To: "Arravind babu" Cc: X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9166 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: earlm@mips.com Precedence: bulk X-list: linux-mips If its a DRAM DIMM module then SW reads info about that RAM via the SPD interface. SPD = Serial Presence Detect This is typically an I2C interface so SW can bit bang it. SPD provides more info than just size. For example on some systems you need to know the RAS/CAS params and various wait state settings in order to program your memory controller for optimal performance. This is how PCs are able to configure themselves to work with standard modules. For more info checkout this site ... http://www.pcguide.com/art/sdram.htm For SRAMs the HW guys usually provide some set of registers for SW to read info its needs like size. And sometimes they don't so you have to use address probing tricks as Wolfgang described. -earlm > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Wolfgang Denk > Sent: Thursday, October 06, 2005 12:29 AM > To: Arravind babu > Cc: linux-mips@linux-mips.org > Subject: Re: Basic question w.r.t bootloader > > > In message > <20051006065332.6978.qmail@web8604.mail.in.yahoo.com> you wrote: > > > > Generally how bootloader/bootflash code detects > > the size of RAM on the board? Is it hardcoded some > > where in the bootflash code or is it detected using > > memory chips ? > > One method is to probe addresses (at N, 2*N, 4*N etc. starting with a > resonable value of N like 1 MB) until probing fails. See for example > common/memsize.c in the U-Boot sources. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de > The IQ of the group is the lowest IQ of a member of the group divided > by the number of people in the group. > > From greg.weeks@timesys.com Thu Oct 6 19:36:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 19:36:44 +0100 (BST) Received: from mail.timesys.com ([65.117.135.102]:26571 "EHLO exchange.timesys.com") by ftp.linux-mips.org with ESMTP id S8133554AbVJFSg2 (ORCPT ); Thu, 6 Oct 2005 19:36:28 +0100 Received: from [192.168.2.27] ([192.168.2.27]) by exchange.timesys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Oct 2005 14:33:52 -0400 Message-ID: <43456EA9.8020209@timesys.com> Date: Thu, 06 Oct 2005 14:36:25 -0400 From: Greg Weeks User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: "Cooper, John" Subject: PREEMPT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 18:33:52.0500 (UTC) FILETIME=[803F3340:01C5CAA4] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9167 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: greg.weeks@timesys.com Precedence: bulk X-list: linux-mips Does anyone know of any current problems with CONFIG_PREEMPT on a 4kc malta board? We're seeing some oddness in the floating point emulator with PREEMPT_RT and wondered if it was in our RT code, or if it's from the base kernel code. Greg W From ralf@linux-mips.org Thu Oct 6 19:47:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 19:47:19 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:27154 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133554AbVJFSrC (ORCPT ); Thu, 6 Oct 2005 19:47:02 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j96IkufU012201; Thu, 6 Oct 2005 19:46:56 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j96IkuB9012200; Thu, 6 Oct 2005 19:46:56 +0100 Date: Thu, 6 Oct 2005 19:46:56 +0100 From: Ralf Baechle To: Greg Weeks Cc: linux-mips@linux-mips.org, "Cooper, John" Subject: Re: PREEMPT Message-ID: <20051006184656.GA12173@linux-mips.org> References: <43456EA9.8020209@timesys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43456EA9.8020209@timesys.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9168 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 06, 2005 at 02:36:25PM -0400, Greg Weeks wrote: > Does anyone know of any current problems with CONFIG_PREEMPT on a 4kc > malta board? We're seeing some oddness in the floating point emulator > with PREEMPT_RT and wondered if it was in our RT code, or if it's from > the base kernel code. No known problem in current problems in that area. Ralf From greg.weeks@timesys.com Thu Oct 6 19:52:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 19:52:46 +0100 (BST) Received: from mail.timesys.com ([65.117.135.102]:7491 "EHLO exchange.timesys.com") by ftp.linux-mips.org with ESMTP id S8133558AbVJFSw3 (ORCPT ); Thu, 6 Oct 2005 19:52:29 +0100 Received: from [192.168.2.27] ([192.168.2.27]) by exchange.timesys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Oct 2005 14:49:49 -0400 Message-ID: <43457266.3090208@timesys.com> Date: Thu, 06 Oct 2005 14:52:22 -0400 From: Greg Weeks User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org, "Cooper, John" Subject: Re: PREEMPT References: <43456EA9.8020209@timesys.com> <20051006184656.GA12173@linux-mips.org> In-Reply-To: <20051006184656.GA12173@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 18:49:49.0953 (UTC) FILETIME=[BAEEEF10:01C5CAA6] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9169 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: greg.weeks@timesys.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: >On Thu, Oct 06, 2005 at 02:36:25PM -0400, Greg Weeks wrote: > > > >>Does anyone know of any current problems with CONFIG_PREEMPT on a 4kc >>malta board? We're seeing some oddness in the floating point emulator >>with PREEMPT_RT and wondered if it was in our RT code, or if it's from >>the base kernel code. >> >> > >No known problem in current problems in that area. > > > I'd remembered some problems ages ago, but had thought they'd been fixed. John was just picking my brain about it so I thought I'd ask to be sure. Greg W From ralf@linux-mips.org Thu Oct 6 19:55:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 19:55:27 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:46095 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133558AbVJFSzK (ORCPT ); Thu, 6 Oct 2005 19:55:10 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j96It4pu017418; Thu, 6 Oct 2005 19:55:04 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j96It4MF017417; Thu, 6 Oct 2005 19:55:04 +0100 Date: Thu, 6 Oct 2005 19:55:04 +0100 From: Ralf Baechle To: Greg Weeks Cc: linux-mips@linux-mips.org, "Cooper, John" Subject: Re: PREEMPT Message-ID: <20051006185504.GD15275@linux-mips.org> References: <43456EA9.8020209@timesys.com> <20051006184656.GA12173@linux-mips.org> <43457266.3090208@timesys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43457266.3090208@timesys.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9170 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 06, 2005 at 02:52:22PM -0400, Greg Weeks wrote: > I'd remembered some problems ages ago, but had thought they'd been > fixed. John was just picking my brain about it so I thought I'd ask to > be sure. The problems I recall were all related to being preempted just while fiddling with the hardware FPU - can't happen on the fpu-less 4Kc. Another issue fixesd recently even though more cosmetic were a bunch of global variables. Ralf From john.cooper@timesys.com Thu Oct 6 20:11:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 20:11:19 +0100 (BST) Received: from mail.timesys.com ([65.117.135.102]:55964 "EHLO exchange.timesys.com") by ftp.linux-mips.org with ESMTP id S8133558AbVJFTLE (ORCPT ); Thu, 6 Oct 2005 20:11:04 +0100 Received: from [127.0.0.1] ([192.168.2.230]) by exchange.timesys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Oct 2005 15:08:27 -0400 Message-ID: <43457563.60505@timesys.com> Date: Thu, 06 Oct 2005 15:05:07 -0400 From: john cooper User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: Greg Weeks , linux-mips@linux-mips.org, john cooper Subject: Re: PREEMPT References: <43456EA9.8020209@timesys.com> <20051006184656.GA12173@linux-mips.org> <43457266.3090208@timesys.com> <20051006185504.GD15275@linux-mips.org> In-Reply-To: <20051006185504.GD15275@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 19:08:28.0890 (UTC) FILETIME=[55DF2BA0:01C5CAA9] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9171 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: john.cooper@timesys.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Thu, Oct 06, 2005 at 02:52:22PM -0400, Greg Weeks wrote: > > >>I'd remembered some problems ages ago, but had thought they'd been >>fixed. John was just picking my brain about it so I thought I'd ask to >>be sure. > > > The problems I recall were all related to being preempted just while > fiddling with the hardware FPU - can't happen on the fpu-less 4Kc. > Another issue fixesd recently even though more cosmetic were a bunch > of global variables. The code base I'm dealing with is a 2.6.13 derivative with PREEMPT_RT support. Looks like the problem was due to PREEMPT_RT confusing fpu_emulator_cop1Handler() resulting in a SIGBUS nailing the associated task. I have it sort of working for soft FPU but expect it requires some attention to safely access a HW FPU where emulation assistance is needed. -john -- john.cooper@timesys.com From sjhill@realitydiluted.com Thu Oct 6 20:45:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 20:45:58 +0100 (BST) Received: from eth13.com-link.com ([208.242.241.164]:21389 "EHLO real.realitydiluted.com") by ftp.linux-mips.org with ESMTP id S8133563AbVJFTpl (ORCPT ); Thu, 6 Oct 2005 20:45:41 +0100 Received: from sjhill by real.realitydiluted.com with local (Exim 4.52 #1 (Debian)) id 1ENakd-0005up-Pl; Thu, 06 Oct 2005 13:45:55 -0500 Subject: Re: PREEMPT In-Reply-To: <43457563.60505@timesys.com> To: john cooper Date: Thu, 6 Oct 2005 13:45:55 -0500 (CDT) CC: Ralf Baechle , Greg Weeks , linux-mips@linux-mips.org X-Mailer: ELM [version 2.4ME+ PL100 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: From: sjhill@realitydiluted.com Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9172 X-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 > The code base I'm dealing with is a 2.6.13 derivative > with PREEMPT_RT support. Looks like the problem was > due to PREEMPT_RT confusing fpu_emulator_cop1Handler() > resulting in a SIGBUS nailing the associated task. > > I have it sort of working for soft FPU but expect it > requires some attention to safely access a HW FPU where > emulation assistance is needed. > Um, did no one have a look at Atsushi Nemoto's patch earlier today that addressed pre-emption and CPU1, or am I missing something? -Steve From ths@networkno.de Thu Oct 6 21:53:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 21:53:35 +0100 (BST) Received: from mx02.qsc.de ([213.148.130.14]:8590 "EHLO mx02.qsc.de") by ftp.linux-mips.org with ESMTP id S3465660AbVJFUxU (ORCPT ); Thu, 6 Oct 2005 21:53:20 +0100 Received: from port-195-158-179-121.dynamic.qsc.de ([195.158.179.121] helo=hattusa.textio) by mx02.qsc.de with esmtp (Exim 3.35 #1) id 1ENcjl-00005f-00; Thu, 06 Oct 2005 22:53:09 +0200 Received: from ths by hattusa.textio with local (Exim 4.54) id 1ENcjk-0007b8-ST; Thu, 06 Oct 2005 22:53:08 +0200 Date: Thu, 6 Oct 2005 22:53:08 +0200 To: "Gleb O. Raiko" Cc: linux-mips@linux-mips.org Subject: Re: Bug in the syscall tracing code Message-ID: <20051006205308.GB31717@hattusa.textio> References: <43455D2D.1010901@niisi.msk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43455D2D.1010901@niisi.msk.ru> User-Agent: Mutt/1.5.11 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9173 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Gleb O. Raiko wrote: > Hello, > > The story continues. The last fix of the syscall tracing code was wrong, > unfortunately. (The bug was a user could invoke any function in the > kernel. The fix was not to use t2 as pointer to a syscall, s0 was chosen > for it.) The problem we discovered is a few syscalls do SAVE_STATIC > (those declared as save_static_function), so s0 (which holds pointer to > the syscall at the time the syscall is invoked) is saved on the stack > overwriting a value saved from the process being traced. No wonder, s0 > that restored on syscall exit differs from s0 saved on syscall enter. > > See, arch/mips/kernel/scall32-o32.S, syscall_trace_entry, for example. > The rest of ABIs are the same. > > There are several ways to fix this: > > 1. Make syscall handling code to be close to other arches. I mean, check > for the trace flag first, then parse arguments and invoke a syscall. > > 2. Remove save_static_functions and do SAVE_STATIC early for several > syscalls (yes, one big switch or its asm equivalent). > > 3. Store t2 in pt_regs (it means we have to expand this structure). > > 4. I know there should be yet another way. - Use the k1 slot instead of s0 to save the function pointer. Thiemo From ddaney@avtrex.com Thu Oct 6 22:13:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Oct 2005 22:13:43 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:29444 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S3465664AbVJFVN0 (ORCPT ); Thu, 6 Oct 2005 22:13:26 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Oct 2005 14:13:24 -0700 Message-ID: <43459374.5080802@avtrex.com> Date: Thu, 06 Oct 2005 14:13:24 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thiemo Seufer CC: "Gleb O. Raiko" , linux-mips@linux-mips.org Subject: Re: Bug in the syscall tracing code References: <43455D2D.1010901@niisi.msk.ru> <20051006205308.GB31717@hattusa.textio> In-Reply-To: <20051006205308.GB31717@hattusa.textio> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 21:13:24.0497 (UTC) FILETIME=[C99A0810:01C5CABA] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9174 X-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 Thiemo Seufer wrote: > Gleb O. Raiko wrote: > >>Hello, >> >>The story continues. The last fix of the syscall tracing code was wrong, >>unfortunately. (The bug was a user could invoke any function in the >>kernel. The fix was not to use t2 as pointer to a syscall, s0 was chosen >>for it.) The problem we discovered is a few syscalls do SAVE_STATIC >>(those declared as save_static_function), so s0 (which holds pointer to >>the syscall at the time the syscall is invoked) is saved on the stack >>overwriting a value saved from the process being traced. No wonder, s0 >>that restored on syscall exit differs from s0 saved on syscall enter. >> >>See, arch/mips/kernel/scall32-o32.S, syscall_trace_entry, for example. >>The rest of ABIs are the same. >> >>There are several ways to fix this: >> >>1. Make syscall handling code to be close to other arches. I mean, check >>for the trace flag first, then parse arguments and invoke a syscall. >> >>2. Remove save_static_functions and do SAVE_STATIC early for several >>syscalls (yes, one big switch or its asm equivalent). >> >>3. Store t2 in pt_regs (it means we have to expand this structure). >> >>4. I know there should be yet another way. > > > - Use the k1 slot instead of s0 to save the function pointer. > That is the conclusion I came to in: http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=4207C3E0.7070405%40avtrex.com IIRC, k0 is already used for something. David daney. From colin@realtek.com.tw Fri Oct 7 07:32:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 07:32:20 +0100 (BST) Received: from mf2.realtek.com.tw ([220.128.56.22]:24079 "EHLO mf2.realtek.com.tw") by ftp.linux-mips.org with ESMTP id S8133569AbVJGGcD (ORCPT ); Fri, 7 Oct 2005 07:32:03 +0100 Received: from msx.realtek.com.tw (unverified [172.21.1.77]) by mf2.realtek.com.tw (Clearswift SMTPRS 5.1.4) with ESMTP id for ; Fri, 7 Oct 2005 14:33:59 +0800 Received: from rtpdii3098 ([172.21.98.16]) by msx.realtek.com.tw (Lotus Domino Release 6.5.3) with ESMTP id 2005100714314478-331927 ; Fri, 7 Oct 2005 14:31:44 +0800 Message-ID: <002701c5cb08$c9682630$106215ac@realtek.com.tw> From: "colin" To: Subject: gcc of SDE6 cannot compile C++ applications Date: Fri, 7 Oct 2005 14:31:44 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-MIMETrack: Itemize by SMTP Server on msx/Realtek(Release 6.5.3|September 14, 2004) at 2005/10/07 =?Bog5?B?pFWkyCAwMjozMTo0NQ==?=, Serialize by Router on msx/Realtek(Release 6.5.3|September 14, 2004) at 2005/10/07 =?Bog5?B?pFWkyCAwMjozMTo0NQ==?=, Serialize complete at 2005/10/07 =?Bog5?B?pFWkyCAwMjozMTo0NQ==?= Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9175 X-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@realtek.com.tw Precedence: bulk X-list: linux-mips Hi there, I upgrade my SDE from 5 to 6. Before upgrading, we can compile C++ applications. After doing that, C++ cannot be compiled by the gcc of SDE6. The warning message is like this: mipsel-linux-gcc: main.cpp: C++ compiler not installed on this system I found that MIPS offers C++ compiler running on MIPS. Does MIPS want us to compile C++ on MIPS, not on X86? Regards, Colin From raiko@niisi.msk.ru Fri Oct 7 08:48:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 08:48:48 +0100 (BST) Received: from t111.niisi.ras.ru ([193.232.173.111]:36816 "EHLO t111.niisi.ras.ru") by ftp.linux-mips.org with ESMTP id S8133556AbVJGHsP (ORCPT ); Fri, 7 Oct 2005 08:48:15 +0100 Received: from t111.niisi.ras.ru (localhost [127.0.0.1]) by t111.niisi.ras.ru (8.13.4/8.12.11) with ESMTP id j977m5Ti008827; Fri, 7 Oct 2005 11:48:08 +0400 Received: (from uucp@localhost) by t111.niisi.ras.ru (8.13.4/8.13.4/Submit) with UUCP id j977m5Hn008824; Fri, 7 Oct 2005 11:48:05 +0400 Received: from [192.168.173.2] (t34 [193.232.173.34]) by aa19.niisi.msk.ru (8.12.8/8.12.8) with ESMTP id j977je3t031962; Fri, 7 Oct 2005 11:45:40 +0400 Message-ID: <4346272B.4010100@niisi.msk.ru> Date: Fri, 07 Oct 2005 11:43:39 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thiemo Seufer CC: linux-mips@linux-mips.org Subject: Re: Bug in the syscall tracing code References: <43455D2D.1010901@niisi.msk.ru> <20051006205308.GB31717@hattusa.textio> In-Reply-To: <20051006205308.GB31717@hattusa.textio> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9176 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: raiko@niisi.msk.ru Precedence: bulk X-list: linux-mips Thiemo Seufer wrote: > - Use the k1 slot instead of s0 to save the function pointer. Unfortunately, k0, k1 cannot be used. We shall withstand do_syscall_trace. It implies going to the user mode and back. Regards, Gleb. From raiko@niisi.msk.ru Fri Oct 7 08:54:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 08:54:25 +0100 (BST) Received: from t111.niisi.ras.ru ([193.232.173.111]:29890 "EHLO t111.niisi.ras.ru") by ftp.linux-mips.org with ESMTP id S8133556AbVJGHyH (ORCPT ); Fri, 7 Oct 2005 08:54:07 +0100 Received: from t111.niisi.ras.ru (localhost [127.0.0.1]) by t111.niisi.ras.ru (8.13.4/8.12.11) with ESMTP id j977s4kM009745; Fri, 7 Oct 2005 11:54:04 +0400 Received: (from uucp@localhost) by t111.niisi.ras.ru (8.13.4/8.13.4/Submit) with UUCP id j977s4Ox009742; Fri, 7 Oct 2005 11:54:04 +0400 Received: from [192.168.173.2] (t34 [193.232.173.34]) by aa19.niisi.msk.ru (8.12.8/8.12.8) with ESMTP id j977qi3t032161; Fri, 7 Oct 2005 11:52:44 +0400 Message-ID: <434628D3.9050307@niisi.msk.ru> Date: Fri, 07 Oct 2005 11:50:43 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Daney CC: Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: Bug in the syscall tracing code References: <43455D2D.1010901@niisi.msk.ru> <20051006205308.GB31717@hattusa.textio> <43459374.5080802@avtrex.com> In-Reply-To: <43459374.5080802@avtrex.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9177 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: raiko@niisi.msk.ru Precedence: bulk X-list: linux-mips David Daney wrote: > That is the conclusion I came to in: > > http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=4207C3E0.7070405%40avtrex.com Saving in the PT_SCRATCH area (pad0 in C) was a solution for 2.4. Unfortunately, syscall arguments are stored there (and that's why pad0 exists in pt_regs after all). So, using PT_SCRATCH as a temporary storage for t2 will break tracing syscalls with more than 4 args for o32 ABI. Regards, Gleb. From colin@realtek.com.tw Fri Oct 7 09:21:52 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 09:22:12 +0100 (BST) Received: from mf2.realtek.com.tw ([220.128.56.22]:26895 "EHLO mf2.realtek.com.tw") by ftp.linux-mips.org with ESMTP id S8133560AbVJGIVw (ORCPT ); Fri, 7 Oct 2005 09:21:52 +0100 Received: from msx.realtek.com.tw (unverified [172.21.1.77]) by mf2.realtek.com.tw (Clearswift SMTPRS 5.1.4) with ESMTP id for ; Fri, 7 Oct 2005 16:23:44 +0800 Received: from rtpdii3098 ([172.21.98.16]) by msx.realtek.com.tw (Lotus Domino Release 6.5.3) with ESMTP id 2005100716212942-333928 ; Fri, 7 Oct 2005 16:21:29 +0800 Message-ID: <005a01c5cb18$1e2df870$106215ac@realtek.com.tw> From: "colin" To: Subject: Is CONFIG_CPU_MIPS32_R2 workable? Date: Fri, 7 Oct 2005 16:21:29 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-MIMETrack: Itemize by SMTP Server on msx/Realtek(Release 6.5.3|September 14, 2004) at 2005/10/07 =?Bog5?B?pFWkyCAwNDoyMToyOQ==?=, Serialize by Router on msx/Realtek(Release 6.5.3|September 14, 2004) at 2005/10/07 =?Bog5?B?pFWkyCAwNDoyMTozMA==?=, Serialize complete at 2005/10/07 =?Bog5?B?pFWkyCAwNDoyMTozMA==?= Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9178 X-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@realtek.com.tw Precedence: bulk X-list: linux-mips Hi all, Has anyone successfully run 2.6.13 with this option on? I backported this option to 2.6.12, and failed running on our platform. Regards, Colin From nigel@mips.com Fri Oct 7 09:38:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 09:39:06 +0100 (BST) Received: from alg145.algor.co.uk ([62.254.210.145]:63244 "EHLO dmz.algor.co.uk") by ftp.linux-mips.org with ESMTP id S8133560AbVJGIiu (ORCPT ); Fri, 7 Oct 2005 09:38:50 +0100 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1ENni8-00012U-00; Fri, 07 Oct 2005 09:36:12 +0100 Received: from wapping.algor.co.uk ([172.20.192.98]) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1ENnkE-0000oc-00; Fri, 07 Oct 2005 09:38:22 +0100 Message-ID: <43463403.8080407@mips.com> Date: Fri, 07 Oct 2005 09:38:27 +0100 From: Nigel Stephens Organization: MIPS Technologies User-Agent: Debian Thunderbird 1.0.2 (X11/20050817) X-Accept-Language: en-us, en MIME-Version: 1.0 To: colin CC: linux-mips@linux-mips.org Subject: Re: gcc of SDE6 cannot compile C++ applications References: <002701c5cb08$c9682630$106215ac@realtek.com.tw> In-Reply-To: <002701c5cb08$c9682630$106215ac@realtek.com.tw> Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-3.766, required 4, AWL, BAYES_00, XENO_CONTENT) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9179 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nigel@mips.com Precedence: bulk X-list: linux-mips colin wrote: >Hi there, >I upgrade my SDE from 5 to 6. >Before upgrading, we can compile C++ applications. After doing that, C++ >cannot be compiled by the gcc of SDE6. >The warning message is like this: > mipsel-linux-gcc: main.cpp: C++ compiler not installed on this system > >I found that MIPS offers C++ compiler running on MIPS. >Does MIPS want us to compile C++ on MIPS, not on X86? > > I recommend that you contact sde@mips.com with questions about SDE. The linux-mips community probably isn't very interested in these issues ;-( As to your question: the SDE cross-compiler is intended only for cross-compiling kernels, and not applications, so we don't currently build the C++ compiler for x86 (until Linus does a rewrite in C++, I suppose). So yes, the current expectation is that you would compile applications, including C++, on a MIPS platform. Nigel From raiko@niisi.msk.ru Fri Oct 7 13:48:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 13:48:24 +0100 (BST) Received: from t111.niisi.ras.ru ([193.232.173.111]:46251 "EHLO t111.niisi.ras.ru") by ftp.linux-mips.org with ESMTP id S8133570AbVJGMsI (ORCPT ); Fri, 7 Oct 2005 13:48:08 +0100 Received: from t111.niisi.ras.ru (localhost [127.0.0.1]) by t111.niisi.ras.ru (8.13.4/8.12.11) with ESMTP id j97Cm62L004920 for ; Fri, 7 Oct 2005 16:48:07 +0400 Received: (from uucp@localhost) by t111.niisi.ras.ru (8.13.4/8.13.4/Submit) with UUCP id j97Cm6I9004916 for linux-mips@linux-mips.org; Fri, 7 Oct 2005 16:48:06 +0400 Received: from [192.168.173.2] (t34 [193.232.173.34]) by aa19.niisi.msk.ru (8.12.8/8.12.8) with ESMTP id j97Cl03t008378; Fri, 7 Oct 2005 16:47:00 +0400 Message-ID: <43466DCB.7070103@niisi.msk.ru> Date: Fri, 07 Oct 2005 16:44:59 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gleb O. Raiko" CC: linux-mips@linux-mips.org Subject: Re: Bug in the syscall tracing code References: <43455D2D.1010901@niisi.msk.ru> In-Reply-To: <43455D2D.1010901@niisi.msk.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9180 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: raiko@niisi.msk.ru Precedence: bulk X-list: linux-mips Hello, > 4. I know there should be yet another way. The way is to load a saved register in the delay slot of jalr. The saved register shall not be s0, of course, because it's saved by the first instruction in save_static_function. So the proposed patch is arch/mips/kernel/scall32-o32.S: syscall_trace_entry: SAVE_STATIC - move s0, t2 + move s1, t2 move a0, sp li a1, 0 jal do_syscall_trace lw a0, PT_R4(sp) # Restore argument registers lw a1, PT_R5(sp) lw a2, PT_R6(sp) lw a3, PT_R7(sp) - jalr s0 + .set push + .set noreorder + jalr s1 + lw s1, PT_R17(sp) + .set pop The rest of ABIs shall be implemented in the same way. Regards, Gleb. From anemo@mba.ocn.ne.jp Fri Oct 7 14:57:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 14:57:22 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:28125 "EHLO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with ESMTP id S8133576AbVJGN5D (ORCPT ); Fri, 7 Oct 2005 14:57:03 +0100 Received: from localhost (p8236-ipad203funabasi.chiba.ocn.ne.jp [222.146.87.236]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id C162620E1; Fri, 7 Oct 2005 22:56:59 +0900 (JST) Date: Fri, 07 Oct 2005 22:55:44 +0900 (JST) Message-Id: <20051007.225544.41197582.anemo@mba.ocn.ne.jp> To: sjhill@realitydiluted.com Cc: john.cooper@timesys.com, ralf@linux-mips.org, greg.weeks@timesys.com, linux-mips@linux-mips.org Subject: Re: PREEMPT From: Atsushi Nemoto In-Reply-To: References: <43457563.60505@timesys.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 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9181 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Thu, 6 Oct 2005 13:45:55 -0500 (CDT), sjhill@realitydiluted.com said: sjhill> Um, did no one have a look at Atsushi Nemoto's patch earlier sjhill> today that addressed pre-emption and CPU1, or am I missing sjhill> something? The patch I posted yesterday affects just for ptrace. I suppose this is not irrelevant. Also, though it might irrelevant too, I think there are still possible bug related signal and fpu_context. I'll post a patch again. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Fri Oct 7 15:53:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 15:53:33 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:34263 "EHLO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with ESMTP id S8133576AbVJGOxK (ORCPT ); Fri, 7 Oct 2005 15:53:10 +0100 Received: from localhost (p8236-ipad203funabasi.chiba.ocn.ne.jp [222.146.87.236]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id A37B37BA5; Fri, 7 Oct 2005 23:53:07 +0900 (JST) Date: Fri, 07 Oct 2005 23:51:52 +0900 (JST) Message-Id: <20051007.235152.75184664.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] fix possible sleeping in atomic on setup/restore sigcontext From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9182 X-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 The setup_sigcontect/restore_sigcontext might sleep on put_user/get_user with preemption disabled (i.e. atomic context). Sleeping in atomic context is not allowed. This patch fixes this problem using temporary variable (struct sigcontext tmpsc). Another possible fix might be rewriting restore_fp_context/save_fp_context to copy to/from current thread_struct and use them with restore_fp/save_fp. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -14,6 +14,7 @@ static inline int setup_sigcontext(struct pt_regs *regs, struct sigcontext *sc) { int err = 0; + struct sigcontext tmpsc; err |= __put_user(regs->cp0_epc, &sc->sc_pc); @@ -73,10 +74,15 @@ setup_sigcontext(struct pt_regs *regs, s own_fpu(); restore_fp(current); } - err |= save_fp_context(sc); + /* make sure save_fp_context not sleep */ + err |= save_fp_context(&tmpsc); preempt_enable(); + err |= __copy_to_user(&sc->sc_fpregs, &tmpsc.sc_fpregs, + sizeof(tmpsc.sc_fpregs)); + err |= __put_user(tmpsc.sc_fpc_csr, &sc->sc_fpc_csr); + out: return err; } @@ -138,14 +144,18 @@ restore_sigcontext(struct pt_regs *regs, err |= __get_user(used_math, &sc->sc_used_math); conditional_used_math(used_math); - preempt_disable(); - if (used_math()) { + /* make sure restore_fp_context not sleep */ + struct sigcontext tmpsc; + err |= __copy_from_user(&tmpsc.sc_fpregs, &sc->sc_fpregs, sizeof(tmpsc.sc_fpregs)); + err |= __get_user(tmpsc.sc_fpc_csr, &sc->sc_fpc_csr); + preempt_disable(); /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context(sc); + err |= restore_fp_context(&tmpsc); } else { /* signal handler may have used FPU. Give it up. */ + preempt_disable(); lose_fpu(); } diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -376,14 +376,18 @@ static int restore_sigcontext32(struct p err |= __get_user(used_math, &sc->sc_used_math); conditional_used_math(used_math); - preempt_disable(); - if (used_math()) { + struct sigcontext32 tmpsc; + /* make sure restore_fp_context32 not sleep */ + err |= __copy_from_user(&tmpsc.sc_fpregs, &sc->sc_fpregs, sizeof(tmpsc.sc_fpregs)); + err |= __get_user(tmpsc.sc_fpc_csr, &sc->sc_fpc_csr); + preempt_disable(); /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context32(sc); + err |= restore_fp_context32(&tmpsc); } else { /* signal handler may have used FPU. Give it up. */ + preempt_disable(); lose_fpu(); } @@ -569,6 +573,7 @@ static inline int setup_sigcontext32(str struct sigcontext32 *sc) { int err = 0; + struct sigcontext32 tmpsc; err |= __put_user(regs->cp0_epc, &sc->sc_pc); err |= __put_user(regs->cp0_status, &sc->sc_status); @@ -614,10 +619,15 @@ static inline int setup_sigcontext32(str own_fpu(); restore_fp(current); } - err |= save_fp_context32(sc); + /* make sure save_fp_context32 not sleep */ + err |= save_fp_context32(&tmpsc); preempt_enable(); + err |= __copy_to_user(&sc->sc_fpregs, &tmpsc.sc_fpregs, + sizeof(tmpsc.sc_fpregs)); + err |= __put_user(tmpsc.sc_fpc_csr, &sc->sc_fpc_csr); + out: return err; } From ddaney@avtrex.com Fri Oct 7 16:26:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 16:26:33 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:21515 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133556AbVJGP0L (ORCPT ); Fri, 7 Oct 2005 16:26:11 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Oct 2005 08:26:09 -0700 Message-ID: <43469391.3050307@avtrex.com> Date: Fri, 07 Oct 2005 08:26:09 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gleb O. Raiko" CC: linux-mips@linux-mips.org Subject: Re: Bug in the syscall tracing code References: <43455D2D.1010901@niisi.msk.ru> <20051006205308.GB31717@hattusa.textio> <43459374.5080802@avtrex.com> <434628D3.9050307@niisi.msk.ru> In-Reply-To: <434628D3.9050307@niisi.msk.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2005 15:26:09.0505 (UTC) FILETIME=[71644D10:01C5CB53] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9183 X-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 Gleb O. Raiko wrote: > David Daney wrote: > >> That is the conclusion I came to in: >> >> http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=4207C3E0.7070405%40avtrex.com > > > > Saving in the PT_SCRATCH area (pad0 in C) was a solution for 2.4. > Unfortunately, syscall arguments are stored there (and that's why pad0 > exists in pt_regs after all). So, using PT_SCRATCH as a temporary > storage for t2 will break tracing syscalls with more than 4 args for o32 > ABI. I know. I meant for you to look at the very end of the message (The part where I said to store it in the slots for k0 or k1). David Daney. From unixe@comcast.net Fri Oct 7 16:34:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 16:34:42 +0100 (BST) Received: from sccrmhc13.comcast.net ([63.240.76.28]:16815 "EHLO sccrmhc13.comcast.net") by ftp.linux-mips.org with ESMTP id S8133556AbVJGPeO convert rfc822-to-8bit (ORCPT ); Fri, 7 Oct 2005 16:34:14 +0100 Received: from buzz (c-67-171-115-157.hsd1.ut.comcast.net[67.171.115.157]) by comcast.net (sccrmhc13) with SMTP id <2005100715340701300bies9e>; Fri, 7 Oct 2005 15:34:07 +0000 From: "Kyle Unice" To: Subject: Cygwin Cross-compile of linux release Date: Fri, 7 Oct 2005 09:34:05 -0600 Message-ID: <001901c5cb54$8dfc70f0$0400a8c0@buzz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9184 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: unixe@comcast.net Precedence: bulk X-list: linux-mips I checked out the source for mips linux and tried cross-compiling this on cygwin. This is the result: HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o scripts/mod/sumversion.c: In function `md4_final_ascii': scripts/mod/sumversion.c:221: warning: unsigned int format, long unsigned int ar g (arg 4) scripts/mod/sumversion.c:221: warning: unsigned int format, long unsigned int ar g (arg 5) scripts/mod/sumversion.c:221: warning: unsigned int format, long unsigned int ar g (arg 6) scripts/mod/sumversion.c:221: warning: unsigned int format, long unsigned int ar g (arg 7) HOSTLD scripts/mod/modpost HOSTCC scripts/kallsyms scripts/kallsyms.c: In function `compress_symbols': scripts/kallsyms.c:366: warning: implicit declaration of function `memmem' scripts/kallsyms.c:366: warning: assignment makes pointer from integer without a cast scripts/kallsyms.c:385: warning: assignment makes pointer from integer without a cast /cygdrive/c/DOCUME~1/KYLE~1.BUZ/LOCALS~1/Temp/ccLMGC3l.o:kallsyms.c:(.text+0 x6cb ): undefined reference to `_memmem' /cygdrive/c/DOCUME~1/KYLE~1.BUZ/LOCALS~1/Temp/ccLMGC3l.o:kallsyms.c:(.text+0 x72d ): undefined reference to `_memmem' collect2: ld returned 1 exit status make[1]: *** [scripts/kallsyms] Error 1 make: *** [scripts] Error 2 Kyle@buzz /usr/src/linux $ From ralf@linux-mips.org Fri Oct 7 16:44:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 16:44:25 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:37391 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133556AbVJGPoI (ORCPT ); Fri, 7 Oct 2005 16:44:08 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j97Fi0nW023829; Fri, 7 Oct 2005 16:44:01 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j97Fi0MM023828; Fri, 7 Oct 2005 16:44:00 +0100 Date: Fri, 7 Oct 2005 16:44:00 +0100 From: Ralf Baechle To: Kyle Unice Cc: linux-mips@linux-mips.org Subject: Re: Cygwin Cross-compile of linux release Message-ID: <20051007154400.GF2616@linux-mips.org> References: <001901c5cb54$8dfc70f0$0400a8c0@buzz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001901c5cb54$8dfc70f0$0400a8c0@buzz> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9185 X-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, Oct 07, 2005 at 09:34:05AM -0600, Kyle Unice wrote: > I checked out the source for mips linux and tried cross-compiling this on > cygwin. > This is the result: > HOSTCC scripts/mod/modpost.o > HOSTCC scripts/mod/sumversion.o > scripts/mod/sumversion.c: In function `md4_final_ascii': > scripts/mod/sumversion.c:221: warning: unsigned int format, long unsigned > int ar > g (arg 4) > scripts/mod/sumversion.c:221: warning: unsigned int format, long unsigned > int ar > g (arg 5) > scripts/mod/sumversion.c:221: warning: unsigned int format, long unsigned > int ar > g (arg 6) > scripts/mod/sumversion.c:221: warning: unsigned int format, long unsigned > int ar > g (arg 7) > HOSTLD scripts/mod/modpost > HOSTCC scripts/kallsyms > scripts/kallsyms.c: In function `compress_symbols': > scripts/kallsyms.c:366: warning: implicit declaration of function `memmem' > scripts/kallsyms.c:366: warning: assignment makes pointer from integer > without a > cast > scripts/kallsyms.c:385: warning: assignment makes pointer from integer > without a > cast > /cygdrive/c/DOCUME~1/KYLE~1.BUZ/LOCALS~1/Temp/ccLMGC3l.o:kallsyms.c:(.text+0 > x6cb > ): undefined reference to `_memmem' > /cygdrive/c/DOCUME~1/KYLE~1.BUZ/LOCALS~1/Temp/ccLMGC3l.o:kallsyms.c:(.text+0 > x72d > ): undefined reference to `_memmem' _memmem must be some symbol of the Cygwin libraries. Honestly, get rid of Cygwin. You'll be glad you did, the birds will fly, the butterflies will be singing ... Ralf From macro@linux-mips.org Fri Oct 7 16:48:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 16:48:27 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:21519 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S8133557AbVJGPsL (ORCPT ); Fri, 7 Oct 2005 16:48:11 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 4CC65F5996; Fri, 7 Oct 2005 17:48:05 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14302-03; Fri, 7 Oct 2005 17:48:05 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 0B158E1C9B; Fri, 7 Oct 2005 17:48:05 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j97Fm8XV017429; Fri, 7 Oct 2005 17:48:09 +0200 Date: Fri, 7 Oct 2005 16:48:17 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: Cygwin Cross-compile of linux release In-Reply-To: <20051007154400.GF2616@linux-mips.org> Message-ID: References: <001901c5cb54$8dfc70f0$0400a8c0@buzz> <20051007154400.GF2616@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87/1120/Fri Oct 7 13:06:49 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, 7 Oct 2005, Ralf Baechle wrote: > Honestly, get rid of Cygwin. You'll be glad you did, the birds will > fly, the butterflies will be singing ... And most importantly pigs will do neither! Maciej From jsun@junsun.net Fri Oct 7 17:35:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 17:35:41 +0100 (BST) Received: from [66.29.16.26] ([66.29.16.26]:42514 "EHLO junsun.net") by ftp.linux-mips.org with ESMTP id S8133562AbVJGQfY (ORCPT ); Fri, 7 Oct 2005 17:35:24 +0100 Received: from gw.junsun.net (adsl-69-226-216-78.dsl.pltn13.pacbell.net [69.226.216.78]) by junsun.net (8.13.1/8.13.1) with ESMTP id j97GQJnG026114 for ; Fri, 7 Oct 2005 09:26:20 -0700 Received: from gw.junsun.net (gw.junsun.net [127.0.0.1]) by gw.junsun.net (8.13.1/8.13.1) with ESMTP id j97GZFvm011742 for ; Fri, 7 Oct 2005 09:35:15 -0700 Received: (from jsun@localhost) by gw.junsun.net (8.13.1/8.13.1/Submit) id j97GZEsK011739 for linux-mips@linux-mips.org; Fri, 7 Oct 2005 09:35:14 -0700 Date: Fri, 7 Oct 2005 09:35:14 -0700 From: Jun Sun To: linux-mips@linux-mips.org Subject: open source embedded software competition Message-ID: <20051007163514.GA11686@gw.junsun.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9187 X-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@junsun.net Precedence: bulk X-list: linux-mips Sorry for the spamming here, I thought someone might be interested in $20K reward. :) http://iosesc.openfoundry.org/ Everybody can participate. However, people using MIPS will get extra bonus scores. :) Jun From mward@pioneer-pra.com Fri Oct 7 19:13:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 19:13:40 +0100 (BST) Received: from ns1.pioneer-pra.com ([65.205.244.70]:19409 "EHLO mail1.dmz.sj.pioneer-pra.com") by ftp.linux-mips.org with ESMTP id S8133575AbVJGSNR (ORCPT ); Fri, 7 Oct 2005 19:13:17 +0100 Received: from localhost (localhost [127.0.0.1]) by mail1.dmz.sj.pioneer-pra.com (Postfix) with ESMTP id B35DB39002D; Fri, 7 Oct 2005 11:13:10 -0700 (PDT) Received: from mail1.dmz.sj.pioneer-pra.com ([127.0.0.1]) by localhost (neo1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26197-07; Fri, 7 Oct 2005 11:13:09 -0700 (PDT) Received: from eo (unknown [65.244.224.162]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail1.dmz.sj.pioneer-pra.com (Postfix) with ESMTP id 2F5D0390028; Fri, 7 Oct 2005 11:13:09 -0700 (PDT) From: "Mike C. Ward" To: "'David Daney'" , Subject: RE: Where is op_model_mipsxx.c ? Date: Fri, 7 Oct 2005 11:13:02 -0700 Message-ID: <020b01c5cb6a$c2251830$5502020a@eo> 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.6626 In-Reply-To: <4343525A.6080605@avtrex.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9188 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mward@pioneer-pra.com Precedence: bulk X-list: linux-mips I created an op_model file for the r5K core in a MIPS32 kernel. details are at http://oss.pioneer-pra.com/oprofile/ I have not had a chance to test it on a real 2.6 kernel yet, it was back-ported from 2.6.11 into 2.4.25. Mike > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of David Daney > Sent: Tuesday, October 04, 2005 9:11 PM > To: linux-mips@linux-mips.org > Subject: Where is op_model_mipsxx.c ? > > > I noticed this in the Makefile for the OProfile directory for mips: > > oprofile-$(CONFIG_CPU_MIPS32_R1) += op_model_mipsxx.o > > The file op_model_mipsxx.c does not seem to exist. Which > implies to me > that someone was working on making it work for MIPS32, but > didn't quite > finish. > > I want to start hacking on OProfile for a MIPS32 based system and > thought it might make a nice starting point. > > If the missing file exists would its author mind making it > available to me? > > Thanks, > David Daney > > From unixe@comcast.net Fri Oct 7 21:18:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 21:18:52 +0100 (BST) Received: from sccrmhc11.comcast.net ([204.127.202.55]:1209 "EHLO sccrmhc11.comcast.net") by ftp.linux-mips.org with ESMTP id S8133577AbVJGUSe (ORCPT ); Fri, 7 Oct 2005 21:18:34 +0100 Received: from buzz (c-67-171-115-157.hsd1.ut.comcast.net[67.171.115.157]) by comcast.net (sccrmhc11) with SMTP id <20051007201826011009fu6ue>; Fri, 7 Oct 2005 20:18:26 +0000 From: "Kyle Unice" To: Subject: Cross-compiling Linux problem Date: Fri, 7 Oct 2005 14:18:24 -0600 Message-ID: <002b01c5cb7c$45c181e0$0400a8c0@buzz> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9189 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: unixe@comcast.net Precedence: bulk X-list: linux-mips LD arch/mips/au1000/common/built-in.o CC arch/mips/kernel/cpu-probe.o CC arch/mips/kernel/branch.o AS arch/mips/kernel/entry.o AS arch/mips/kernel/genex.o CC arch/mips/kernel/irq.o CC arch/mips/kernel/process.o CC arch/mips/kernel/ptrace.o CC arch/mips/kernel/reset.o CC arch/mips/kernel/semaphore.o CC arch/mips/kernel/setup.o CC arch/mips/kernel/signal.o CC arch/mips/kernel/syscall.o CC arch/mips/kernel/time.o CC arch/mips/kernel/traps.o CC arch/mips/kernel/unaligned.o CC arch/mips/kernel/mips_ksyms.o CC arch/mips/kernel/module.o AS arch/mips/kernel/r4k_fpu.o AS arch/mips/kernel/r4k_switch.o AS arch/mips/kernel/scall32-o32.o CC arch/mips/kernel/proc.o LD arch/mips/kernel/built-in.o AS arch/mips/kernel/head.o CC arch/mips/kernel/init_task.o LDS arch/mips/kernel/vmlinux.lds CC arch/mips/mm/cache.o CC arch/mips/mm/extable.o CC arch/mips/mm/fault.o CC arch/mips/mm/init.o CC arch/mips/mm/pgtable.o CC arch/mips/mm/tlbex.o arch/mips/mm/tlbex.c:516:5: warning: "CONFIG_64BIT" is not defined AS arch/mips/mm/tlbex-fault.o CC arch/mips/mm/ioremap.o arch/mips/mm/ioremap.c: In function `__ioremap': include/asm-mips/mach-au1x00/ioremap.h:15: sorry, unimplemented: inlining failed in call to '__fixup_bigphys_addr': function body not available arch/mips/mm/ioremap.c:28: sorry, unimplemented: called from here make[1]: *** [arch/mips/mm/ioremap.o] Error 1 make: *** [arch/mips/mm] Error 2 From fosterb@uoguelph.ca Fri Oct 7 21:41:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 21:42:19 +0100 (BST) Received: from dragonboat.cs.uoguelph.ca ([131.104.96.108]:26042 "EHLO dragonboat.cs.uoguelph.ca") by ftp.linux-mips.org with ESMTP id S8133582AbVJGUl7 (ORCPT ); Fri, 7 Oct 2005 21:41:59 +0100 Received: from beddie.cis.uoguelph.ca (marvin.cis.uoguelph.ca [131.104.48.131]) by dragonboat.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id j97KfucQ016403; Fri, 7 Oct 2005 16:41:56 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by beddie.cis.uoguelph.ca (Postfix) with ESMTP id E1EBF1DF03; Fri, 7 Oct 2005 16:41:46 -0400 (EDT) Received: from beddie.cis.uoguelph.ca ([127.0.0.1]) by localhost (beddie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29786-02; Fri, 7 Oct 2005 16:41:46 -0400 (EDT) Received: from [131.104.49.198] (unknown [131.104.49.198]) by beddie.cis.uoguelph.ca (Postfix) with ESMTP id 2C3808A6E; Fri, 7 Oct 2005 16:41:46 -0400 (EDT) Message-ID: <4346DD97.40106@uoguelph.ca> Date: Fri, 07 Oct 2005 16:41:59 -0400 From: Brett Foster User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kyle Unice CC: linux-mips@linux-mips.org Subject: Re: Cross-compiling Linux problem References: <002b01c5cb7c$45c181e0$0400a8c0@buzz> In-Reply-To: <002b01c5cb7c$45c181e0$0400a8c0@buzz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cs-club.org X-Scanned-By: MIMEDefang 2.52 on 131.104.96.108 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9190 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fosterb@uoguelph.ca Precedence: bulk X-list: linux-mips Kyle Unice wrote: >arch/mips/mm/tlbex.c:516:5: warning: "CONFIG_64BIT" is not defined > AS arch/mips/mm/tlbex-fault.o > CC arch/mips/mm/ioremap.o >arch/mips/mm/ioremap.c: In function `__ioremap': >include/asm-mips/mach-au1x00/ioremap.h:15: sorry, unimplemented: inlining >failed > in call to '__fixup_bigphys_addr': function body not available >arch/mips/mm/ioremap.c:28: sorry, unimplemented: called from here >make[1]: *** [arch/mips/mm/ioremap.o] Error 1 >make: *** [arch/mips/mm] Error 2 > > I once had this sort of problem when I forgot to specify the cross compiler while invoking make and tried to compile a MIPS kernel on X86 gcc. Brett From macro@linux-mips.org Fri Oct 7 21:54:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 21:55:06 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:6161 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S8133582AbVJGUyr (ORCPT ); Fri, 7 Oct 2005 21:54:47 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 57BEBF5996; Fri, 7 Oct 2005 22:54:40 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10178-04; Fri, 7 Oct 2005 22:54:40 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 0E642F5969; Fri, 7 Oct 2005 22:54:40 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j97KsjF5002496; Fri, 7 Oct 2005 22:54:45 +0200 Date: Fri, 7 Oct 2005 21:54:57 +0100 (BST) From: "Maciej W. Rozycki" To: Brett Foster Cc: linux-mips@linux-mips.org Subject: Re: Cross-compiling Linux problem In-Reply-To: <4346DD97.40106@uoguelph.ca> Message-ID: References: <002b01c5cb7c$45c181e0$0400a8c0@buzz> <4346DD97.40106@uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87/1121/Fri Oct 7 19:38:02 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9191 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, 7 Oct 2005, Brett Foster wrote: > > include/asm-mips/mach-au1x00/ioremap.h:15: sorry, unimplemented: inlining > > failed > > in call to '__fixup_bigphys_addr': function body not available > > arch/mips/mm/ioremap.c:28: sorry, unimplemented: called from here > > make[1]: *** [arch/mips/mm/ioremap.o] Error 1 > > make: *** [arch/mips/mm] Error 2 > > > > > I once had this sort of problem when I forgot to specify the cross compiler > while invoking make and tried to compile a MIPS kernel on X86 gcc. In this case the header is truly broken -- "extern inline __attribute__((always_inline))" is self-contradicting. Maciej From unixe@comcast.net Fri Oct 7 22:26:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 22:27:18 +0100 (BST) Received: from sccrmhc12.comcast.net ([63.240.76.22]:2452 "EHLO sccrmhc12.comcast.net") by ftp.linux-mips.org with ESMTP id S8133588AbVJGV06 (ORCPT ); Fri, 7 Oct 2005 22:26:58 +0100 Received: from buzz (c-67-171-115-157.hsd1.ut.comcast.net[67.171.115.157]) by comcast.net (sccrmhc12) with SMTP id <2005100721265101200p4g7pe>; Fri, 7 Oct 2005 21:26:51 +0000 From: "Kyle Unice" To: "'Brett Foster'" Cc: Subject: RE: Cross-compiling Linux problem Date: Fri, 7 Oct 2005 15:26:49 -0600 Message-ID: <002c01c5cb85$d42c5050$0400a8c0@buzz> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4346DD97.40106@uoguelph.ca> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9192 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: unixe@comcast.net Precedence: bulk X-list: linux-mips I am compiling the db1550_defconfig which does define CONFIG_64BIT_PHYS_ADDR. The cross compiler is mipsel generated from crosstool.sh Kyle -----Original Message----- From: Brett Foster [mailto:fosterb@uoguelph.ca] Sent: Friday, October 07, 2005 2:42 PM To: Kyle Unice Cc: linux-mips@linux-mips.org Subject: Re: Cross-compiling Linux problem Kyle Unice wrote: >arch/mips/mm/tlbex.c:516:5: warning: "CONFIG_64BIT" is not defined > AS arch/mips/mm/tlbex-fault.o > CC arch/mips/mm/ioremap.o >arch/mips/mm/ioremap.c: In function `__ioremap': >include/asm-mips/mach-au1x00/ioremap.h:15: sorry, unimplemented: inlining >failed > in call to '__fixup_bigphys_addr': function body not available >arch/mips/mm/ioremap.c:28: sorry, unimplemented: called from here >make[1]: *** [arch/mips/mm/ioremap.o] Error 1 >make: *** [arch/mips/mm] Error 2 > > I once had this sort of problem when I forgot to specify the cross compiler while invoking make and tried to compile a MIPS kernel on X86 gcc. Brett From ppopov@embeddedalley.com Fri Oct 7 22:47:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 22:48:01 +0100 (BST) Received: from smtp101.biz.mail.mud.yahoo.com ([68.142.200.236]:46697 "HELO smtp101.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133588AbVJGVrl (ORCPT ); Fri, 7 Oct 2005 22:47:41 +0100 Received: (qmail 90019 invoked from network); 7 Oct 2005 21:47:31 -0000 Received: from unknown (HELO ?192.168.1.110?) (ppopov@embeddedalley.com@71.128.175.242 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 7 Oct 2005 21:47:31 -0000 Subject: RE: Cross-compiling Linux problem From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Kyle Unice Cc: 'Brett Foster' , "'linux-mips@linux-mips.org'" In-Reply-To: <002c01c5cb85$d42c5050$0400a8c0@buzz> References: <002c01c5cb85$d42c5050$0400a8c0@buzz> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Fri, 07 Oct 2005 14:47:15 -0700 Message-Id: <1128721636.9971.166.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9193 X-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@embeddedalley.com Precedence: bulk X-list: linux-mips On Fri, 2005-10-07 at 15:26 -0600, Kyle Unice wrote: > I am compiling the db1550_defconfig which does define > CONFIG_64BIT_PHYS_ADDR. > The cross compiler is mipsel generated from crosstool.sh Which gcc version? And I assume you are using the linux-mips.org tree, not kernel.org? Pete > Kyle > > -----Original Message----- > From: Brett Foster [mailto:fosterb@uoguelph.ca] > Sent: Friday, October 07, 2005 2:42 PM > To: Kyle Unice > Cc: linux-mips@linux-mips.org > Subject: Re: Cross-compiling Linux problem > > Kyle Unice wrote: > > >arch/mips/mm/tlbex.c:516:5: warning: "CONFIG_64BIT" is not defined > > AS arch/mips/mm/tlbex-fault.o > > CC arch/mips/mm/ioremap.o > >arch/mips/mm/ioremap.c: In function `__ioremap': > >include/asm-mips/mach-au1x00/ioremap.h:15: sorry, unimplemented: inlining > >failed > > in call to '__fixup_bigphys_addr': function body not available > >arch/mips/mm/ioremap.c:28: sorry, unimplemented: called from here > >make[1]: *** [arch/mips/mm/ioremap.o] Error 1 > >make: *** [arch/mips/mm] Error 2 > > > > > I once had this sort of problem when I forgot to specify the cross > compiler while invoking make and tried to compile a MIPS kernel on X86 gcc. > > Brett > > From unixe@comcast.net Fri Oct 7 22:54:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 22:54:48 +0100 (BST) Received: from sccrmhc13.comcast.net ([204.127.202.64]:48627 "EHLO sccrmhc13.comcast.net") by ftp.linux-mips.org with ESMTP id S8133591AbVJGVyQ convert rfc822-to-8bit (ORCPT ); Fri, 7 Oct 2005 22:54:16 +0100 Received: from buzz (c-67-171-115-157.hsd1.ut.comcast.net[67.171.115.157]) by comcast.net (sccrmhc13) with SMTP id <2005100721540901300bc1r8e>; Fri, 7 Oct 2005 21:54:10 +0000 From: "Kyle Unice" To: Cc: "'Brett Foster'" , Subject: RE: Cross-compiling Linux problem Date: Fri, 7 Oct 2005 15:54:08 -0600 Message-ID: <002d01c5cb89$a4f1b830$0400a8c0@buzz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1128721636.9971.166.camel@localhost.localdomain> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9194 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: unixe@comcast.net Precedence: bulk X-list: linux-mips I am using gcc-3.4.4 and the cvs checkout of linux-mips.org tree. Kyle -----Original Message----- From: Pete Popov [mailto:ppopov@embeddedalley.com] Sent: Friday, October 07, 2005 3:47 PM To: Kyle Unice Cc: 'Brett Foster'; 'linux-mips@linux-mips.org' Subject: RE: Cross-compiling Linux problem On Fri, 2005-10-07 at 15:26 -0600, Kyle Unice wrote: > I am compiling the db1550_defconfig which does define > CONFIG_64BIT_PHYS_ADDR. > The cross compiler is mipsel generated from crosstool.sh Which gcc version? And I assume you are using the linux-mips.org tree, not kernel.org? Pete > Kyle > > -----Original Message----- > From: Brett Foster [mailto:fosterb@uoguelph.ca] > Sent: Friday, October 07, 2005 2:42 PM > To: Kyle Unice > Cc: linux-mips@linux-mips.org > Subject: Re: Cross-compiling Linux problem > > Kyle Unice wrote: > > >arch/mips/mm/tlbex.c:516:5: warning: "CONFIG_64BIT" is not defined > > AS arch/mips/mm/tlbex-fault.o > > CC arch/mips/mm/ioremap.o > >arch/mips/mm/ioremap.c: In function `__ioremap': > >include/asm-mips/mach-au1x00/ioremap.h:15: sorry, unimplemented: inlining > >failed > > in call to '__fixup_bigphys_addr': function body not available > >arch/mips/mm/ioremap.c:28: sorry, unimplemented: called from here > >make[1]: *** [arch/mips/mm/ioremap.o] Error 1 > >make: *** [arch/mips/mm] Error 2 > > > > > I once had this sort of problem when I forgot to specify the cross > compiler while invoking make and tried to compile a MIPS kernel on X86 gcc. > > Brett > > From ddaney@avtrex.com Fri Oct 7 23:27:43 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 23:27:59 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:49677 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133589AbVJGW1n (ORCPT ); Fri, 7 Oct 2005 23:27:43 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Oct 2005 15:27:40 -0700 Message-ID: <4346F65B.6050800@avtrex.com> Date: Fri, 07 Oct 2005 15:27:39 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kyle Unice CC: ppopov@embeddedalley.com, 'Brett Foster' , linux-mips@linux-mips.org Subject: Re: Cross-compiling Linux problem References: <002d01c5cb89$a4f1b830$0400a8c0@buzz> In-Reply-To: <002d01c5cb89$a4f1b830$0400a8c0@buzz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2005 22:27:40.0152 (UTC) FILETIME=[53CAC780:01C5CB8E] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9195 X-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 Kyle Unice wrote: > I am using gcc-3.4.4 and the cvs checkout of linux-mips.org tree. > Kyle Not withstanding Maciej's comment about the real problem being the broken header file, I give you a quote from http://www.linux-mips.org/wiki/Git : "At this time only the linux.git repository is in production use.... all other archives are only historical." You might consider getting your code from the git repository as the CVS repository is no longer being maintained. David Daney From ilya@total-knowledge.com Fri Oct 7 23:56:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Oct 2005 23:57:11 +0100 (BST) Received: from alpha.total-knowledge.com ([205.217.158.170]:10138 "EHLO total-knowledge.com") by ftp.linux-mips.org with ESMTP id S8133583AbVJGW4y (ORCPT ); Fri, 7 Oct 2005 23:56:54 +0100 Received: (qmail 28499 invoked from network); 7 Oct 2005 15:56:50 -0700 Received: from c-24-6-216-150.hsd1.ca.comcast.net (HELO ?192.168.0.211?) (ilya@24.6.216.150) by alpha.total-knowledge.com with ESMTPA; 7 Oct 2005 15:56:50 -0700 Message-ID: <4346FD34.8000100@total-knowledge.com> Date: Fri, 07 Oct 2005 15:56:52 -0700 From: "Ilya A. Volynets-Evenbakh" Organization: Total Knowledge User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050723) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Daney CC: Kyle Unice , ppopov@embeddedalley.com, 'Brett Foster' , linux-mips@linux-mips.org Subject: Re: Cross-compiling Linux problem References: <002d01c5cb89$a4f1b830$0400a8c0@buzz> <4346F65B.6050800@avtrex.com> In-Reply-To: <4346F65B.6050800@avtrex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9196 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ilya@total-knowledge.com Precedence: bulk X-list: linux-mips CVS is not where development happens, but it is still updated, according to Ralf. David Daney wrote: > Kyle Unice wrote: > >> I am using gcc-3.4.4 and the cvs checkout of linux-mips.org tree. >> Kyle > > > Not withstanding Maciej's comment about the real problem being the > broken header file, I give you a quote from > http://www.linux-mips.org/wiki/Git : "At this time only the linux.git > repository is in production use.... all other archives are only > historical." > > You might consider getting your code from the git repository as the > CVS repository is no longer being maintained. > > David Daney > > -- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com From ddaney@avtrex.com Sat Oct 8 00:15:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Oct 2005 00:15:38 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:1309 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133583AbVJGXPV (ORCPT ); Sat, 8 Oct 2005 00:15:21 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Oct 2005 16:15:19 -0700 Message-ID: <43470187.3070104@avtrex.com> Date: Fri, 07 Oct 2005 16:15:19 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ilya A. Volynets-Evenbakh" CC: linux-mips@linux-mips.org Subject: Re: Cross-compiling Linux problem References: <002d01c5cb89$a4f1b830$0400a8c0@buzz> <4346F65B.6050800@avtrex.com> <4346FD34.8000100@total-knowledge.com> In-Reply-To: <4346FD34.8000100@total-knowledge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2005 23:15:19.0694 (UTC) FILETIME=[FC3642E0:01C5CB94] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9197 X-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 Ilya A. Volynets-Evenbakh wrote: > CVS is not where development happens, but it is still updated, according > to Ralf. > Perhaps, but the reason I mentioned this is that I saw this warning: arch/mips/mm/tlbex.c:516:5: warning: "CONFIG_64BIT" is not defined Which is fixed in the git repository, but not CVS David Daney > David Daney wrote: > >> Kyle Unice wrote: >> >>> I am using gcc-3.4.4 and the cvs checkout of linux-mips.org tree. >>> Kyle >> >> >> >> Not withstanding Maciej's comment about the real problem being the >> broken header file, I give you a quote from >> http://www.linux-mips.org/wiki/Git : "At this time only the linux.git >> repository is in production use.... all other archives are only >> historical." >> >> You might consider getting your code from the git repository as the >> CVS repository is no longer being maintained. >> >> David Daney >> >> > From ddaney@avtrex.com Sat Oct 8 00:59:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Oct 2005 00:59:31 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:54021 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133590AbVJGX7N (ORCPT ); Sat, 8 Oct 2005 00:59:13 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Oct 2005 16:59:11 -0700 Message-ID: <43470BCF.1070709@avtrex.com> Date: Fri, 07 Oct 2005 16:59:11 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: OProfile cannot be loaded as module... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2005 23:59:11.0563 (UTC) FILETIME=[1CED99B0:01C5CB9B] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9198 X-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 arch/mips/oprofile/common.c defines several symbols (op_model_mipsxx and op_model_rm9000) with __attribute__((weak)). It then assumes that ELF linking conventions will prevail and there will be no problems if they are undefined. The problem is if you try to load oprofile as a module. The kernel module linker evidentially does not understand weak symbols and refuses to load the module because they are undefined. Perhaps a single extern struct op_mips_model plat_op_model; That must be defined by each different implementation. Deciding one which implementation would then be done at compile time instead of runtime. I don't have a patch for this yet, but that is what I am thinking of doing. David Daney. From ddaney@avtrex.com Sat Oct 8 01:25:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Oct 2005 01:26:05 +0100 (BST) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:49183 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133590AbVJHAZq (ORCPT ); Sat, 8 Oct 2005 01:25:46 +0100 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Oct 2005 17:25:44 -0700 Message-ID: <43471208.3060405@avtrex.com> Date: Fri, 07 Oct 2005 17:25:44 -0700 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: OProfile cannot be loaded as module... References: <43470BCF.1070709@avtrex.com> In-Reply-To: <43470BCF.1070709@avtrex.com> Content-Type: multipart/mixed; boundary="------------030309090201040107050005" X-OriginalArrivalTime: 08 Oct 2005 00:25:44.0251 (UTC) FILETIME=[D23E80B0:01C5CB9E] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9199 X-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 This is a multi-part message in MIME format. --------------030309090201040107050005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Daney wrote: > arch/mips/oprofile/common.c defines several symbols (op_model_mipsxx and > op_model_rm9000) with __attribute__((weak)). It then assumes that ELF > linking conventions will prevail and there will be no problems if they > are undefined. > > The problem is if you try to load oprofile as a module. The kernel > module linker evidentially does not understand weak symbols and refuses > to load the module because they are undefined. > > Perhaps a single > > extern struct op_mips_model plat_op_model; > > That must be defined by each different implementation. Deciding one > which implementation would then be done at compile time instead of runtime. > > I don't have a patch for this yet, but that is what I am thinking of doing. > Ok, attached is my untested (but it compiles for some architectures) patch. David Daney --------------030309090201040107050005 Content-Type: text/plain; name="op.d" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="op.d" diff --git a/arch/mips/oprofile/common.c b/arch/mips/oprofile/common.c --- a/arch/mips/oprofile/common.c +++ b/arch/mips/oprofile/common.c @@ -14,20 +14,17 @@ #include "op_impl.h" -extern struct op_mips_model op_model_mipsxx __attribute__((weak)); -extern struct op_mips_model op_model_rm9000 __attribute__((weak)); - -static struct op_mips_model *model; +extern struct op_mips_model *plat_op_model; static struct op_counter_config ctr[20]; static int op_mips_setup(void) { /* Pre-compute the values to stuff in the hardware registers. */ - model->reg_setup(ctr); + plat_op_model->reg_setup(ctr); /* Configure the registers on all cpus. */ - on_each_cpu(model->cpu_setup, 0, 0, 1); + on_each_cpu(plat_op_model->cpu_setup, 0, 0, 1); return 0; } @@ -36,7 +33,7 @@ static int op_mips_create_files(struct s { int i; - for (i = 0; i < model->num_counters; ++i) { + for (i = 0; i < plat_op_model->num_counters; ++i) { struct dentry *dir; char buf[3]; @@ -58,7 +55,7 @@ static int op_mips_create_files(struct s static int op_mips_start(void) { - on_each_cpu(model->cpu_start, NULL, 0, 1); + on_each_cpu(plat_op_model->cpu_start, NULL, 0, 1); return 0; } @@ -66,49 +63,33 @@ static int op_mips_start(void) static void op_mips_stop(void) { /* Disable performance monitoring for all counters. */ - on_each_cpu(model->cpu_stop, NULL, 0, 1); + on_each_cpu(plat_op_model->cpu_stop, NULL, 0, 1); } int __init oprofile_arch_init(struct oprofile_operations *ops) { - struct op_mips_model *lmodel = NULL; int res; printk(KERN_INFO "oprofile: In oprofile_arch_init.\n"); - switch (current_cpu_data.cputype) { - case CPU_24K: - lmodel = &op_model_mipsxx; - break; - - case CPU_RM9000: - lmodel = &op_model_rm9000; - break; - }; - - if (!lmodel) - return -ENODEV; - - res = lmodel->init(); + res = plat_op_model->init(); if (res) return res; - model = lmodel; - ops->create_files = op_mips_create_files; ops->setup = op_mips_setup; //ops->shutdown = op_mips_shutdown; ops->start = op_mips_start; ops->stop = op_mips_stop; - ops->cpu_type = lmodel->cpu_type; + ops->cpu_type = plat_op_model->cpu_type; printk(KERN_INFO "oprofile: using %s performance monitoring.\n", - lmodel->cpu_type); + plat_op_model->cpu_type); return 0; } void oprofile_arch_exit(void) { - model->exit(); + plat_op_model->exit(); } diff --git a/arch/mips/oprofile/op_model_mipsxx.c b/arch/mips/oprofile/op_model_mipsxx.c --- a/arch/mips/oprofile/op_model_mipsxx.c +++ b/arch/mips/oprofile/op_model_mipsxx.c @@ -23,7 +23,7 @@ #define M_COUNTER_OVERFLOW (1UL << 31) -struct op_mips_model op_model_mipsxx; +static struct op_mips_model op_model_mipsxx; static struct mipsxx_register_config { unsigned int control[4]; @@ -205,7 +205,7 @@ static void mipsxx_exit(void) perf_irq = null_perf_irq; } -struct op_mips_model op_model_mipsxx = { +static struct op_mips_model op_model_mipsxx = { .reg_setup = mipsxx_reg_setup, .cpu_setup = mipsxx_cpu_setup, .init = mipsxx_init, @@ -213,3 +213,5 @@ struct op_mips_model op_model_mipsxx = { .cpu_start = mipsxx_cpu_start, .cpu_stop = mipsxx_cpu_stop, }; + +struct op_mips_model *plat_op_model = &op_model_mipsxx; diff --git a/arch/mips/oprofile/op_model_rm9000.c b/arch/mips/oprofile/op_model_rm9000.c --- a/arch/mips/oprofile/op_model_rm9000.c +++ b/arch/mips/oprofile/op_model_rm9000.c @@ -126,7 +126,7 @@ static void rm9000_exit(void) free_irq(rm9000_perfcount_irq, NULL); } -struct op_mips_model op_model_rm9000 = { +static struct op_mips_model op_model_rm9000 = { .reg_setup = rm9000_reg_setup, .cpu_setup = rm9000_cpu_setup, .init = rm9000_init, @@ -136,3 +136,5 @@ struct op_mips_model op_model_rm9000 = { .cpu_type = "mips/rm9000", .num_counters = 2 }; + +struct op_mips_model *plat_op_model = &op_model_rm9000; --------------030309090201040107050005-- From unixe@comcast.net Sat Oct 8 04:33:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Oct 2005 04:33:55 +0100 (BST) Received: from sccrmhc14.comcast.net ([63.240.76.49]:12163 "EHLO sccrmhc14.comcast.net") by ftp.linux-mips.org with ESMTP id S8133433AbVJHDdh convert rfc822-to-8bit (ORCPT ); Sat, 8 Oct 2005 04:33:37 +0100 Received: from buzz (c-67-171-115-157.hsd1.ut.comcast.net[67.171.115.157]) by comcast.net (sccrmhc14) with SMTP id <2005100803332901400ol4mle>; Sat, 8 Oct 2005 03:33:30 +0000 From: "Kyle Unice" To: "'David Daney'" Cc: , "'Brett Foster'" , Subject: RE: Cross-compiling Linux problem Date: Fri, 7 Oct 2005 21:33:27 -0600 Message-ID: <003701c5cbb9$0c4a9590$0400a8c0@buzz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4346F65B.6050800@avtrex.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9200 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: unixe@comcast.net Precedence: bulk X-list: linux-mips David, Thanks I downloaded and installed git. Used git to get the linux source And did a build and got: CC arch/mips/au1000/common/prom.o AS arch/mips/au1000/common/int-handler.o CC arch/mips/au1000/common/irq.o CC arch/mips/au1000/common/puts.o CC arch/mips/au1000/common/time.o CC arch/mips/au1000/common/reset.o CC arch/mips/au1000/common/au1xxx_irqmap.o CC arch/mips/au1000/common/clocks.o CC arch/mips/au1000/common/platform.o CC arch/mips/au1000/common/power.o CC arch/mips/au1000/common/setup.o AS arch/mips/au1000/common/sleeper.o CC arch/mips/au1000/common/cputable.o CC arch/mips/au1000/common/dma.o CC arch/mips/au1000/common/dbdma.o CC arch/mips/au1000/common/gpio.o CC arch/mips/au1000/common/pci.o arch/mips/au1000/common/pci.c: In function `au1x_pci_setup': include/asm-mips/mach-au1x00/ioremap.h:15: sorry, unimplemented: inlining failed in call to '__fixup_bigphys_addr': function body not available arch/mips/au1000/common/pci.c:28: sorry, unimplemented: called from here make[1]: *** [arch/mips/au1000/common/pci.o] Error 1 make: *** [arch/mips/au1000/common] Error 2 Kyle -----Original Message----- From: David Daney [mailto:ddaney@avtrex.com] Sent: Friday, October 07, 2005 4:28 PM To: Kyle Unice Cc: ppopov@embeddedalley.com; 'Brett Foster'; linux-mips@linux-mips.org Subject: Re: Cross-compiling Linux problem Kyle Unice wrote: > I am using gcc-3.4.4 and the cvs checkout of linux-mips.org tree. > Kyle Not withstanding Maciej's comment about the real problem being the broken header file, I give you a quote from http://www.linux-mips.org/wiki/Git : "At this time only the linux.git repository is in production use.... all other archives are only historical." You might consider getting your code from the git repository as the CVS repository is no longer being maintained. David Daney From unixe@comcast.net Sat Oct 8 14:52:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Oct 2005 14:52:51 +0100 (BST) Received: from sccrmhc14.comcast.net ([63.240.76.49]:64486 "EHLO sccrmhc14.comcast.net") by ftp.linux-mips.org with ESMTP id S8133616AbVJHNwf (ORCPT ); Sat, 8 Oct 2005 14:52:35 +0100 Received: from buzz (c-67-171-115-157.hsd1.ut.comcast.net[67.171.115.157]) by comcast.net (sccrmhc14) with SMTP id <2005100813522701400ok6bde>; Sat, 8 Oct 2005 13:52:27 +0000 From: "Kyle Unice" To: "'Ilya A. Volynets-Evenbakh'" , "'David Daney'" Cc: , "'Brett Foster'" , Subject: RE: Cross-compiling Linux problem Date: Sat, 8 Oct 2005 07:52:24 -0600 Message-ID: <003c01c5cc0f$83a19e30$0400a8c0@buzz> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4346FD34.8000100@total-knowledge.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9201 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: unixe@comcast.net Precedence: bulk X-list: linux-mips It appears that the function __fixup_bigphys_addr is not inline anymore but A callable function. I removed the "inline " qualifier from the extern declaration in Ioremap.h (if CONFIG_64BIT_PHYS_ADDR is declared) and linux built ok. Kyle -----Original Message----- From: Ilya A. Volynets-Evenbakh [mailto:ilya@total-knowledge.com] Sent: Friday, October 07, 2005 4:57 PM To: David Daney Cc: Kyle Unice; ppopov@embeddedalley.com; 'Brett Foster'; linux-mips@linux-mips.org Subject: Re: Cross-compiling Linux problem CVS is not where development happens, but it is still updated, according to Ralf. David Daney wrote: > Kyle Unice wrote: > >> I am using gcc-3.4.4 and the cvs checkout of linux-mips.org tree. >> Kyle > > > Not withstanding Maciej's comment about the real problem being the > broken header file, I give you a quote from > http://www.linux-mips.org/wiki/Git : "At this time only the linux.git > repository is in production use.... all other archives are only > historical." > > You might consider getting your code from the git repository as the > CVS repository is no longer being maintained. > > David Daney > > -- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com From carlo@linux.it Sun Oct 9 14:41:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Oct 2005 14:41:30 +0100 (BST) Received: from mp1-smtp-3.eutelia.it ([62.94.10.163]:8870 "EHLO smtp.eutelia.it") by ftp.linux-mips.org with ESMTP id S8133653AbVJINlI (ORCPT ); Sun, 9 Oct 2005 14:41:08 +0100 Received: from voyager (ip-96-162.sn2.eutelia.it [83.211.96.162]) by smtp.eutelia.it (Eutelia) with ESMTP id 53D0517F749 for ; Sun, 9 Oct 2005 15:41:07 +0200 (CEST) Received: by voyager (Postfix, from userid 1000) id E09331A5E6A; Sun, 9 Oct 2005 15:41:06 +0200 (CEST) Date: Sun, 9 Oct 2005 15:41:06 +0200 From: Carlo Perassi To: linux-mips@linux-mips.org Subject: rfc about an uncommented string Message-ID: <20051009134106.GB9091@voyager> Reply-To: carlo@linux.it MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: carlo@linux.it Precedence: bulk X-list: linux-mips Content-Length: 1081 Lines: 34 Hi. As suggested (*) by Arthur Othieno on the kernel-janitors mailing list, I bounce here this email for collecting comments. The old email refers to 2.6.13-rc6 but the code is still the same on 2.6.14-rc3. Thank you. Hi. I'd like to collect some comments about the following code segment I found in linux-2.6.13-rc6/arch/mips/ite-boards/generic/it8172_setup.c (the "^^^" sequence is not mine, it's in the code) #ifdef CONFIG_SERIO_I8042 /* * According to the ITE Special BIOS Note for waking up the * keyboard controller... */ static int init_8712_keyboard(void) { unsigned int cmd_port = 0x14000064; unsigned int data_port = 0x14000060; ^^^^^^^^^^^ Somebody here doesn't grok the concept of io ports. (*) http://lists.osdl.org/pipermail/kernel-janitors/2005-August/004704.html http://lists.osdl.org/pipermail/kernel-janitors/2005-August/004705.html http://lists.osdl.org/pipermail/kernel-janitors/2005-August/004707.html http://lists.osdl.org/pipermail/kernel-janitors/2005-October/004955.html -- Carlo Perassi - http://www.linux.it/~carlo/ From ralf@linux-mips.org Mon Oct 10 12:11:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Oct 2005 12:12:13 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:7697 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133471AbVJJLL5 (ORCPT ); Mon, 10 Oct 2005 12:11:57 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j9ABBoOk007817; Mon, 10 Oct 2005 12:11:50 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j9ABBo8Y007816; Mon, 10 Oct 2005 12:11:50 +0100 Date: Mon, 10 Oct 2005 12:11:49 +0100 From: Ralf Baechle To: Carlo Perassi Cc: linux-mips@linux-mips.org Subject: Re: rfc about an uncommented string Message-ID: <20051010111149.GC2661@linux-mips.org> References: <20051009134106.GB9091@voyager> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051009134106.GB9091@voyager> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9204 X-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: 818 Lines: 23 On Sun, Oct 09, 2005 at 03:41:06PM +0200, Carlo Perassi wrote: > Hi. > As suggested (*) by Arthur Othieno on the kernel-janitors mailing list, > I bounce here this email for collecting comments. > The old email refers to 2.6.13-rc6 but the code is still the same on > 2.6.14-rc3. > Thank you. > > Hi. > > I'd like to collect some comments about the following code > segment I found in > linux-2.6.13-rc6/arch/mips/ite-boards/generic/it8172_setup.c > (the "^^^" sequence is not mine, it's in the code) I know, I put it there. The code was obviously broken, so I place this hard to miss not right into the middle of it. It's there since ages and nobody did complain. So unless somebody complains - and that complaint better include some patches - I will delete support for the IT8172 and it's eval board. Ralf From fxzhang@ict.ac.cn Mon Oct 10 12:23:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Oct 2005 12:23:59 +0100 (BST) Received: from webmail.ict.ac.cn ([159.226.39.7]:21482 "HELO ict.ac.cn") by ftp.linux-mips.org with SMTP id S8133471AbVJJLXk (ORCPT ); Mon, 10 Oct 2005 12:23:40 +0100 Received: (qmail 5612 invoked by uid 507); 10 Oct 2005 11:15:33 -0000 Received: from unknown (HELO ?192.168.2.202?) (fxzhang@222.92.8.142) by ict.ac.cn with SMTP; 10 Oct 2005 11:15:33 -0000 Message-ID: <434A4F27.6010301@ict.ac.cn> Date: Mon, 10 Oct 2005 19:23:19 +0800 From: Fuxin Zhang User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: Carlo Perassi , linux-mips@linux-mips.org Subject: Re: rfc about an uncommented string References: <20051009134106.GB9091@voyager> <20051010111149.GC2661@linux-mips.org> In-Reply-To: <20051010111149.GC2661@linux-mips.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=gb18030 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fxzhang@ict.ac.cn Precedence: bulk X-list: linux-mips Content-Length: 1251 Lines: 38 We are using 8172 for 2.4 kernels presently,although may drop it sometime later. I don't read the 2.6 code,but it seems it remains the same as the copy in 2.4(except that #ifdef changes).I can't see why the code is broken? In case you mean the ioport address,mips_io_port_base for that board is 0xa0000000, inb(0x14000060) is reading from 0xb4000060, which is correct for it. Ralf Baechle wrote: > On Sun, Oct 09, 2005 at 03:41:06PM +0200, Carlo Perassi wrote: > > >>Hi. >>As suggested (*) by Arthur Othieno on the kernel-janitors mailing list, >>I bounce here this email for collecting comments. >>The old email refers to 2.6.13-rc6 but the code is still the same on >>2.6.14-rc3. >>Thank you. >> >>Hi. >> >>I'd like to collect some comments about the following code >>segment I found in >>linux-2.6.13-rc6/arch/mips/ite-boards/generic/it8172_setup.c >>(the "^^^" sequence is not mine, it's in the code) > > > I know, I put it there. The code was obviously broken, so I place this > hard to miss not right into the middle of it. It's there since ages and > nobody did complain. So unless somebody complains - and that complaint > better include some patches - I will delete support for the IT8172 and > it's eval board. > > Ralf > > > From geert@linux-m68k.org Mon Oct 10 12:29:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Oct 2005 12:29:24 +0100 (BST) Received: from witte.sonytel.be ([80.88.33.193]:5082 "EHLO witte.sonytel.be") by ftp.linux-mips.org with ESMTP id S8133471AbVJJL3B (ORCPT ); Mon, 10 Oct 2005 12:29:01 +0100 Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j9ABStva028230; Mon, 10 Oct 2005 13:28:55 +0200 (MEST) Date: Mon, 10 Oct 2005 13:28:43 +0200 (CEST) From: Geert Uytterhoeven To: Fuxin Zhang cc: Ralf Baechle , Carlo Perassi , Linux/MIPS Development Subject: Re: rfc about an uncommented string In-Reply-To: <434A4F27.6010301@ict.ac.cn> Message-ID: References: <20051009134106.GB9091@voyager> <20051010111149.GC2661@linux-mips.org> <434A4F27.6010301@ict.ac.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9206 X-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: 1747 Lines: 45 On Mon, 10 Oct 2005, Fuxin Zhang wrote: > We are using 8172 for 2.4 kernels presently,although may drop it > sometime later. > > I don't read the 2.6 code,but it seems it remains the same as the copy > in 2.4(except that #ifdef changes).I can't see why the code is broken? > In case you mean the ioport address,mips_io_port_base for that board is > 0xa0000000, inb(0x14000060) is reading from 0xb4000060, which is correct > for it. Shouldn't mips_io_port_base be 0xb4000000 for your board, so inb(0x60) looks more like a PC-style keyboard controller access? > Ralf Baechle wrote: > > On Sun, Oct 09, 2005 at 03:41:06PM +0200, Carlo Perassi wrote: > >>As suggested (*) by Arthur Othieno on the kernel-janitors mailing list, > >>I bounce here this email for collecting comments. > >>The old email refers to 2.6.13-rc6 but the code is still the same on > >>2.6.14-rc3. > >>Thank you. > >> > >>Hi. > >> > >>I'd like to collect some comments about the following code > >>segment I found in > >>linux-2.6.13-rc6/arch/mips/ite-boards/generic/it8172_setup.c > >>(the "^^^" sequence is not mine, it's in the code) > > > > > > I know, I put it there. The code was obviously broken, so I place this > > hard to miss not right into the middle of it. It's there since ages and > > nobody did complain. So unless somebody complains - and that complaint > > better include some patches - I will delete support for the IT8172 and > > it's eval board. 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 fxzhang@ict.ac.cn Mon Oct 10 12:43:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Oct 2005 12:43:55 +0100 (BST) Received: from webmail.ict.ac.cn ([159.226.39.7]:48875 "HELO ict.ac.cn") by ftp.linux-mips.org with SMTP id S8133681AbVJJLnh (ORCPT ); Mon, 10 Oct 2005 12:43:37 +0100 Received: (qmail 7691 invoked by uid 507); 10 Oct 2005 11:35:32 -0000 Received: from unknown (HELO ?192.168.2.202?) (fxzhang@222.92.8.142) by ict.ac.cn with SMTP; 10 Oct 2005 11:35:32 -0000 Message-ID: <434A53D3.1080106@ict.ac.cn> Date: Mon, 10 Oct 2005 19:43:15 +0800 From: Fuxin Zhang User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geert Uytterhoeven CC: Ralf Baechle , Carlo Perassi , Linux/MIPS Development Subject: Re: rfc about an uncommented string References: <20051009134106.GB9091@voyager> <20051010111149.GC2661@linux-mips.org> <434A4F27.6010301@ict.ac.cn> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=gb18030 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9207 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fxzhang@ict.ac.cn Precedence: bulk X-list: linux-mips Content-Length: 2059 Lines: 61 Geert Uytterhoeven wrote: > On Mon, 10 Oct 2005, Fuxin Zhang wrote: > >>We are using 8172 for 2.4 kernels presently,although may drop it >>sometime later. >> >>I don't read the 2.6 code,but it seems it remains the same as the copy >>in 2.4(except that #ifdef changes).I can't see why the code is broken? >>In case you mean the ioport address,mips_io_port_base for that board is >>0xa0000000, inb(0x14000060) is reading from 0xb4000060, which is correct >>for it. > > > Shouldn't mips_io_port_base be 0xb4000000 for your board, so inb(0x60) looks > more like a PC-style keyboard controller access? It is not my code. But anyway the board has more than one discontinuous io ranges(0xb4000000 is in fact for it8712 superio and legacy ios, it8172's system registers are located around 0xb8000000, while others begins at 0xb4010000). > > >>Ralf Baechle wrote: >> >>>On Sun, Oct 09, 2005 at 03:41:06PM +0200, Carlo Perassi wrote: >>> >>>>As suggested (*) by Arthur Othieno on the kernel-janitors mailing list, >>>>I bounce here this email for collecting comments. >>>>The old email refers to 2.6.13-rc6 but the code is still the same on >>>>2.6.14-rc3. >>>>Thank you. >>>> >>>>Hi. >>>> >>>>I'd like to collect some comments about the following code >>>>segment I found in >>>>linux-2.6.13-rc6/arch/mips/ite-boards/generic/it8172_setup.c >>>>(the "^^^" sequence is not mine, it's in the code) >>> >>> >>>I know, I put it there. The code was obviously broken, so I place this >>>hard to miss not right into the middle of it. It's there since ages and >>>nobody did complain. So unless somebody complains - and that complaint >>>better include some patches - I will delete support for the IT8172 and >>>it's eval board. > > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds > > > From geert@linux-m68k.org Mon Oct 10 12:46:39 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Oct 2005 12:46:55 +0100 (BST) Received: from witte.sonytel.be ([80.88.33.193]:20445 "EHLO witte.sonytel.be") by ftp.linux-mips.org with ESMTP id S8133681AbVJJLqj (ORCPT ); Mon, 10 Oct 2005 12:46:39 +0100 Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j9ABkava028769; Mon, 10 Oct 2005 13:46:36 +0200 (MEST) Date: Mon, 10 Oct 2005 13:46:25 +0200 (CEST) From: Geert Uytterhoeven To: Fuxin Zhang cc: Ralf Baechle , Carlo Perassi , Linux/MIPS Development Subject: Re: rfc about an uncommented string In-Reply-To: <434A53D3.1080106@ict.ac.cn> Message-ID: References: <20051009134106.GB9091@voyager> <20051010111149.GC2661@linux-mips.org> <434A4F27.6010301@ict.ac.cn> <434A53D3.1080106@ict.ac.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9208 X-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: 1450 Lines: 36 On Mon, 10 Oct 2005, Fuxin Zhang wrote: > Geert Uytterhoeven wrote: > > On Mon, 10 Oct 2005, Fuxin Zhang wrote: > >>We are using 8172 for 2.4 kernels presently,although may drop it > >>sometime later. > >> > >>I don't read the 2.6 code,but it seems it remains the same as the copy > >>in 2.4(except that #ifdef changes).I can't see why the code is broken? > >>In case you mean the ioport address,mips_io_port_base for that board is > >>0xa0000000, inb(0x14000060) is reading from 0xb4000060, which is correct > >>for it. > > > > Shouldn't mips_io_port_base be 0xb4000000 for your board, so inb(0x60) looks > > more like a PC-style keyboard controller access? > It is not my code. But anyway the board has more than one discontinuous > io ranges(0xb4000000 is in fact for it8712 superio and legacy ios, So 0xb4000000 is the base for ISA and PCI I/O port accesses, right? Hence if mips_io_port_base is 0xb4000000, all drivers for PCI (and ISA) expansion cards that use inb() and friends will work. > it8172's system registers are located around 0xb8000000, while others > begins at 0xb4010000). So these can use ITE8172-specific access macros. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ralf@linux-mips.org Mon Oct 10 12:51:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Oct 2005 12:51:54 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:50461 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133681AbVJJLvg (ORCPT ); Mon, 10 Oct 2005 12:51:36 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j9ABpHpx025975; Mon, 10 Oct 2005 12:51:17 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j9ABpF6n025974; Mon, 10 Oct 2005 12:51:15 +0100 Date: Mon, 10 Oct 2005 12:51:15 +0100 From: Ralf Baechle To: Geert Uytterhoeven Cc: Fuxin Zhang , Carlo Perassi , Linux/MIPS Development Subject: Re: rfc about an uncommented string Message-ID: <20051010115115.GD2661@linux-mips.org> References: <20051009134106.GB9091@voyager> <20051010111149.GC2661@linux-mips.org> <434A4F27.6010301@ict.ac.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9209 X-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: 632 Lines: 17 On Mon, Oct 10, 2005 at 01:28:43PM +0200, Geert Uytterhoeven wrote: > > I don't read the 2.6 code,but it seems it remains the same as the copy > > in 2.4(except that #ifdef changes).I can't see why the code is broken? > > In case you mean the ioport address,mips_io_port_base for that board is > > 0xa0000000, inb(0x14000060) is reading from 0xb4000060, which is correct > > for it. > > Shouldn't mips_io_port_base be 0xb4000000 for your board, so inb(0x60) looks > more like a PC-style keyboard controller access? Exactly. Anyway - what this did actually demonstrate is that at least there's no 2.6 user of the IT8172. Ralf From macro@linux-mips.org Mon Oct 10 14:18:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Oct 2005 14:19:11 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:49170 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S3465557AbVJJNSv (ORCPT ); Mon, 10 Oct 2005 14:18:51 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 39EBCE1C9C; Mon, 10 Oct 2005 15:18:42 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13447-02; Mon, 10 Oct 2005 15:18:42 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 011C8E1C93; Mon, 10 Oct 2005 15:18:42 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j9ADIjrb031088; Mon, 10 Oct 2005 15:18:45 +0200 Date: Mon, 10 Oct 2005 14:18:52 +0100 (BST) From: "Maciej W. Rozycki" To: Geert Uytterhoeven Cc: Fuxin Zhang , Ralf Baechle , Carlo Perassi , Linux/MIPS Development Subject: Re: rfc about an uncommented string In-Reply-To: Message-ID: References: <20051009134106.GB9091@voyager> <20051010111149.GC2661@linux-mips.org> <434A4F27.6010301@ict.ac.cn> <434A53D3.1080106@ict.ac.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87/1125/Mon Oct 10 11:16:52 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9210 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1165 Lines: 25 On Mon, 10 Oct 2005, Geert Uytterhoeven wrote: > > It is not my code. But anyway the board has more than one discontinuous > > io ranges(0xb4000000 is in fact for it8712 superio and legacy ios, > > So 0xb4000000 is the base for ISA and PCI I/O port accesses, right? Hence if > mips_io_port_base is 0xb4000000, all drivers for PCI (and ISA) expansion cards > that use inb() and friends will work. > > > it8172's system registers are located around 0xb8000000, while others > > begins at 0xb4010000). > > So these can use ITE8172-specific access macros. IOW, MIPS has no concept of I/O space in the CPU, so whatever is decoded as I/O cycles to PCI/EISA/ISA is I/O and everything else is MMIO. In particular I/O spaces are private to their respective buses -- if there are more than one disjoint PCI/EISA/ISA buses in a given system, then each of them can have its private 4GB or 16MB (or whatever) space reserved for I/O cycles. If there is only one PCI/EISA/ISA bus, then mips_io_port_base should refer to the base address where decoding as I/O cycles for that bus starts, holding an appropriate virtual mapping, typically obtained with ioremap(). Maciej From Don_Hiatt@pmc-sierra.com Tue Oct 11 19:21:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Oct 2005 19:21:57 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:32195 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133411AbVJKSVl (ORCPT ); Tue, 11 Oct 2005 19:21:41 +0100 Received: (qmail 27104 invoked by uid 101); 11 Oct 2005 18:21:34 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 11 Oct 2005 18:21:34 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id j9BILPLr027837 for ; Tue, 11 Oct 2005 11:21:34 -0700 Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Oct 2005 11:21:36 -0700 Message-ID: <5C1FD43E5F1B824E83985A74F396286E5E9528@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Don Hiatt To: "'linux-mips@linux-mips.org'" Subject: git, rsync, and firewalls... Date: Tue, 11 Oct 2005 11:23:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Don_Hiatt@pmc-sierra.com Precedence: bulk X-list: linux-mips Content-Length: 245 Lines: 8 Any ideas on how you would go about doing the initial git clone if rsync is blocked? Of course I could do it at home and then carry it back but all those bits get awful heavy.. :) Is it possible to use wget to grab the repository? Cheers, don From ilya@total-knowledge.com Tue Oct 11 20:06:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Oct 2005 20:07:04 +0100 (BST) Received: from alpha.total-knowledge.com ([205.217.158.170]:60582 "EHLO total-knowledge.com") by ftp.linux-mips.org with ESMTP id S8133421AbVJKTGp (ORCPT ); Tue, 11 Oct 2005 20:06:45 +0100 Received: (qmail 23858 invoked from network); 11 Oct 2005 12:06:43 -0700 Received: from users.sonicwall.com (HELO ?10.0.15.99?) (ilya@216.217.36.130) by alpha.total-knowledge.com with ESMTPA; 11 Oct 2005 12:06:43 -0700 Message-ID: <434C0D3E.7010408@total-knowledge.com> Date: Tue, 11 Oct 2005 12:06:38 -0700 From: "Ilya A. Volynets-Evenbakh" Organization: Total Knowledge User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050723) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Hiatt CC: "'linux-mips@linux-mips.org'" Subject: Re: git, rsync, and firewalls... References: <5C1FD43E5F1B824E83985A74F396286E5E9528@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <5C1FD43E5F1B824E83985A74F396286E5E9528@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9212 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ilya@total-knowledge.com Precedence: bulk X-list: linux-mips Content-Length: 420 Lines: 23 git clone http://www.linux-mips.org/pub/scm/linux.git Don Hiatt wrote: >Any ideas on how you would go about doing the initial git clone if >rsync is blocked? Of course I could do it at home and then carry >it back but all those bits get awful heavy.. :) Is it possible to >use wget to grab the repository? > >Cheers, > >don > > > -- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com From djd20@kent.ac.uk Tue Oct 11 21:50:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Oct 2005 21:51:03 +0100 (BST) Received: from mx5.kent.ac.uk ([129.12.21.36]:50830 "EHLO mx5.kent.ac.uk") by ftp.linux-mips.org with ESMTP id S8133539AbVJKUuc (ORCPT ); Tue, 11 Oct 2005 21:50:32 +0100 Received: from hathor.ukc.ac.uk ([129.12.4.12]) by mx5.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1EPR3y-0006Yi-No; Tue, 11 Oct 2005 21:49:30 +0100 Received: from myrtle.ukc.ac.uk ([129.12.3.176] ident=exim) by hathor.ukc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50) id 1EPR3y-0006m9-KM; Tue, 11 Oct 2005 21:49:30 +0100 Received: from myrtle.ukc.ac.uk ([129.12.3.176] ident=djd20) by myrtle.ukc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50) id 1EPR3y-0007YR-Cb; Tue, 11 Oct 2005 21:49:30 +0100 Date: Tue, 11 Oct 2005 21:49:30 +0100 (BST) From: "D.J.Dimmich" X-X-Sender: djd20@myrtle.ukc.ac.uk To: "Ilya A. Volynets-Evenbakh" cc: Don Hiatt , "'linux-mips@linux-mips.org'" Subject: Re: git, rsync, and firewalls... In-Reply-To: <434C0D3E.7010408@total-knowledge.com> Message-ID: References: <5C1FD43E5F1B824E83985A74F396286E5E9528@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> <434C0D3E.7010408@total-knowledge.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: X-UKC-MailScanner-From: djd20@kent.ac.uk Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: djd20@kent.ac.uk Precedence: bulk X-list: linux-mips Content-Length: 1258 Lines: 48 Hmm, This is no good: cg-clone http://www.linux-mips.org/pub/scm/linux.git linux-mips.git defaulting to local storage area 21:41:28 URL:http://www.linux-mips.org/pub/scm/linux.git/refs/heads/master [41/41] -> "refs/heads/origin" [1] progress: 2 objects, 1003 bytes error: File 658dc2bb726238c6eb05edf3eb2d35050c8beb1d (http://www.linux-mips.org/pub/scm/linux.git/objects/65/8dc2bb726238c6eb05edf3eb2d35050c8beb1d) corrupt Cannot obtain needed blob 658dc2bb726238c6eb05edf3eb2d35050c8beb1d while processing commit 0000000000000000000000000000000000000000. error: cannot map sha1 file 658dc2bb726238c6eb05edf3eb2d35050c8beb1d cg-pull: objects pull failed cg-init: pull failed cg (cogito) are wrapper scripts around git... Something's no good... the rsync method bombs out at 97% - just hangs.... Any suggestions? Thanks, Damian On Tue, 11 Oct 2005, Ilya A. Volynets-Evenbakh wrote: > git clone http://www.linux-mips.org/pub/scm/linux.git > > > > Don Hiatt wrote: > > >Any ideas on how you would go about doing the initial git clone if > >rsync is blocked? Of course I could do it at home and then carry > >it back but all those bits get awful heavy.. :) Is it possible to > >use wget to grab the repository? > > > >Cheers, > > > >don > > > > > > > > From ths@networkno.de Tue Oct 11 23:34:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Oct 2005 23:34:33 +0100 (BST) Received: from mx01.qsc.de ([213.148.129.14]:60647 "EHLO mx01.qsc.de") by ftp.linux-mips.org with ESMTP id S8133545AbVJKWeM (ORCPT ); Tue, 11 Oct 2005 23:34:12 +0100 Received: from port-195-158-179-121.dynamic.qsc.de ([195.158.179.121] helo=hattusa.textio) by mx01.qsc.de with esmtp (Exim 3.35 #1) id 1EPSh9-0001Bx-00; Wed, 12 Oct 2005 00:34:03 +0200 Received: from ths by hattusa.textio with local (Exim 4.54) id 1EPSh7-0004YU-A5; Wed, 12 Oct 2005 00:34:01 +0200 Date: Wed, 12 Oct 2005 00:34:01 +0200 To: "D.J.Dimmich" Cc: linux-mips@linux-mips.org Subject: Re: git, rsync, and firewalls... Message-ID: <20051011223401.GH21761@hattusa.textio> References: <5C1FD43E5F1B824E83985A74F396286E5E9528@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> <434C0D3E.7010408@total-knowledge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9214 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Content-Length: 1034 Lines: 30 D.J.Dimmich wrote: > Hmm, > > This is no good: > > cg-clone http://www.linux-mips.org/pub/scm/linux.git linux-mips.git > defaulting to local storage area > 21:41:28 URL:http://www.linux-mips.org/pub/scm/linux.git/refs/heads/master > [41/41] -> "refs/heads/origin" [1] > progress: 2 objects, 1003 bytes > error: File 658dc2bb726238c6eb05edf3eb2d35050c8beb1d > (http://www.linux-mips.org/pub/scm/linux.git/objects/65/8dc2bb726238c6eb05edf3eb2d35050c8beb1d) > corrupt > > Cannot obtain needed blob 658dc2bb726238c6eb05edf3eb2d35050c8beb1d > while processing commit 0000000000000000000000000000000000000000. > error: cannot map sha1 file 658dc2bb726238c6eb05edf3eb2d35050c8beb1d > cg-pull: objects pull failed > cg-init: pull failed > > cg (cogito) are wrapper scripts around git... Something's no good... the > rsync method bombs out at 97% - just hangs.... > > Any suggestions? Use a sufficiently new git, and raw git instead of cogito (as described in the wiki page at www.linux-mips.org). At least this works for me. Thiemo From imipak@yahoo.com Tue Oct 11 23:40:22 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Oct 2005 23:40:41 +0100 (BST) Received: from web31502.mail.mud.yahoo.com ([68.142.198.131]:1190 "HELO web31502.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S3465584AbVJKWkW (ORCPT ); Tue, 11 Oct 2005 23:40:22 +0100 Received: (qmail 60211 invoked by uid 60001); 11 Oct 2005 22:40:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fzIa6VklEEodefr+/wYUCMuTZT40M2nhDC+7XDXPQczwiYv350c68p+Bdaffll+bPRO1Cm024+Wm01OrBqdgMakLiwIoWMAk3G62gE2RIs1DiVA3Bjd6V5G3ZyZY5RquVq3Oolg1iCooMnkEv5UhxYpWkxWJJlM3Er3Blk8dlmU= ; Message-ID: <20051011224009.60209.qmail@web31502.mail.mud.yahoo.com> Received: from [208.187.37.98] by web31502.mail.mud.yahoo.com via HTTP; Tue, 11 Oct 2005 15:40:09 PDT Date: Tue, 11 Oct 2005 15:40:09 -0700 (PDT) From: Jonathan Day Subject: Run into another Linux kernel compile problem To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: imipak@yahoo.com Precedence: bulk X-list: linux-mips Content-Length: 2967 Lines: 90 I've got a working system for a Broadcom SB1, thanks to the considerable help (and patches) from here, and the helpful step-through on Linux From Scratch. However, I've subsequently run into a problem when upgrading the kernel, using the version in CVS on the Linux-MIPS site. (I'm applying the same set of patches, am using the same .config file, and have not changed the toolchain. That's next on my list.) The version in CVS on September 22nd (linux-2.6.14-rc1-mipscvs-20050922) compiles fine. The version currently in CVS (linux-2.6.14-rc1-mipscvs-20051011) crashes out with the following errors: make CHK include/linux/version.h HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/split-include HOSTCC scripts/basic/docproc SPLIT include/linux/autoconf.h -> include/config/* CC arch/mips/kernel/asm-offsets.s In file included from include/asm/pgtable.h:19, from include/linux/mm.h:36, from arch/mips/kernel/asm-offsets.c:15: include/asm/io.h: In function 'outq': include/asm/io.h:440: error: size of array 'type name' is negative include/asm/io.h: In function 'inq': include/asm/io.h:440: error: size of array 'type name' is negative include/asm/io.h: In function 'outq_p': include/asm/io.h:440: error: size of array 'type name' is negative include/asm/io.h: In function 'inq_p': include/asm/io.h:440: error: size of array 'type name' is negative include/asm/io.h: In function 'mem_outq': include/asm/io.h:440: error: size of array 'type name' is negative include/asm/io.h: In function 'mem_inq': include/asm/io.h:440: error: size of array 'type name' is negative include/asm/io.h: In function 'mem_outq_p': include/asm/io.h:440: error: size of array 'type name' is negative include/asm/io.h: In function 'mem_inq_p': include/asm/io.h:440: error: size of array 'type name' is negative make[1]: *** [arch/mips/kernel/asm-offsets.s] Error 1 make: *** [prepare0] Error 2 If I delete lines 339-441 - which do a BUILDIO_IOPORT(q, u64), conditional on it being a 64-bit compile - then the kernel will compile. I do, however, get the following warnings: include/asm/io.h: In function 'outsq': include/asm/io.h:517: warning: implicit declaration of function 'mem_outq' include/asm/io.h: In function 'insq': include/asm/io.h:517: warning: implicit declaration of function 'mem_inq' I'm guessing that the BUILDIO_IOPORT() is setting up these calls, but it's not quite clear to me as to where. The only obvious difference in the macro call from any of the other macros in that group is the use of u64. Declaring a dummy variable at the start of the header file of this type does not produce any warnings or errors, so I'm satisfied that the type definition exists. An inspection of the .config file verifies that the CPU is declared as an SB1, and that it is a 64-bit kernel build. Any ideas? __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From ralf@linux-mips.org Wed Oct 12 14:09:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Oct 2005 14:10:07 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:54547 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133549AbVJLNJr (ORCPT ); Wed, 12 Oct 2005 14:09:47 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j9CD9gdQ008774; Wed, 12 Oct 2005 14:09:42 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j9CD9fkj008773; Wed, 12 Oct 2005 14:09:41 +0100 Date: Wed, 12 Oct 2005 14:09:41 +0100 From: Ralf Baechle To: Jonathan Day Cc: linux-mips@linux-mips.org Subject: Re: Run into another Linux kernel compile problem Message-ID: <20051012130941.GA6955@linux-mips.org> References: <20051011224009.60209.qmail@web31502.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051011224009.60209.qmail@web31502.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9216 X-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: 326 Lines: 10 On Tue, Oct 11, 2005 at 03:40:09PM -0700, Jonathan Day wrote: > The version currently in CVS > (linux-2.6.14-rc1-mipscvs-20051011) crashes out with > the following errors: Use the version in git. There will be _no_ checkins into the linux module of the CVS archive anymore. And yes, your problem is already fixed. Ralf From ralf@linux-mips.org Wed Oct 12 14:29:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Oct 2005 14:30:22 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:23565 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133455AbVJLN34 (ORCPT ); Wed, 12 Oct 2005 14:29:56 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j9CDTesQ010098; Wed, 12 Oct 2005 14:29:41 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j9CDTaKu010097; Wed, 12 Oct 2005 14:29:36 +0100 Date: Wed, 12 Oct 2005 14:29:36 +0100 From: Ralf Baechle To: "D.J.Dimmich" Cc: "Ilya A. Volynets-Evenbakh" , Don Hiatt , "'linux-mips@linux-mips.org'" Subject: Re: git, rsync, and firewalls... Message-ID: <20051012132935.GB6955@linux-mips.org> References: <5C1FD43E5F1B824E83985A74F396286E5E9528@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> <434C0D3E.7010408@total-knowledge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9217 X-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: 717 Lines: 18 On Tue, Oct 11, 2005 at 09:49:30PM +0100, D.J.Dimmich wrote: > Cannot obtain needed blob 658dc2bb726238c6eb05edf3eb2d35050c8beb1d > while processing commit 0000000000000000000000000000000000000000. > error: cannot map sha1 file 658dc2bb726238c6eb05edf3eb2d35050c8beb1d > cg-pull: objects pull failed > cg-init: pull failed > > cg (cogito) are wrapper scripts around git... Something's no good... the > rsync method bombs out at 97% - just hangs.... I've seen rsync hanging like this frequently when certain types of firewall configurations were involved. The #1 troublemaker have been certain older Cisco PIX versions but there are others. Anyway, cloning via http works fine, I've just verified that. Ralf From ralf@linux-mips.org Thu Oct 13 12:59:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Oct 2005 13:00:12 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:35334 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3458542AbVJML75 (ORCPT ); Thu, 13 Oct 2005 12:59:57 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j9DBxjPn005185; Thu, 13 Oct 2005 12:59:45 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j9DBwAt5005092; Thu, 13 Oct 2005 12:58:10 +0100 Date: Thu, 13 Oct 2005 12:58:09 +0100 From: Ralf Baechle To: Kyle Unice Cc: "'Ilya A. Volynets-Evenbakh'" , "'David Daney'" , ppopov@embeddedalley.com, "'Brett Foster'" , linux-mips@linux-mips.org Subject: Re: Cross-compiling Linux problem Message-ID: <20051013115809.GA2654@linux-mips.org> References: <4346FD34.8000100@total-knowledge.com> <003c01c5cc0f$83a19e30$0400a8c0@buzz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003c01c5cc0f$83a19e30$0400a8c0@buzz> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9218 X-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: 350 Lines: 10 On Sat, Oct 08, 2005 at 07:52:24AM -0600, Kyle Unice wrote: > It appears that the function __fixup_bigphys_addr is not inline anymore but > A callable function. I removed the "inline " qualifier from the extern > declaration in > Ioremap.h (if CONFIG_64BIT_PHYS_ADDR is declared) and linux built ok. Thanks for noting; fixed that in git. Ralf From ralf@linux-mips.org Thu Oct 13 13:08:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Oct 2005 13:08:26 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:60679 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3458542AbVJMMIK (ORCPT ); Thu, 13 Oct 2005 13:08:10 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j9DC7xmI005486; Thu, 13 Oct 2005 13:07:59 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j9DC7xhX005485; Thu, 13 Oct 2005 13:07:59 +0100 Date: Thu, 13 Oct 2005 13:07:59 +0100 From: Ralf Baechle To: "Ilya A. Volynets-Evenbakh" Cc: David Daney , Kyle Unice , ppopov@embeddedalley.com, "'Brett Foster'" , linux-mips@linux-mips.org Subject: Re: Cross-compiling Linux problem Message-ID: <20051013120759.GB2654@linux-mips.org> References: <002d01c5cb89$a4f1b830$0400a8c0@buzz> <4346F65B.6050800@avtrex.com> <4346FD34.8000100@total-knowledge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4346FD34.8000100@total-knowledge.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9219 X-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: 299 Lines: 9 On Fri, Oct 07, 2005 at 03:56:52PM -0700, Ilya A. Volynets-Evenbakh wrote: > CVS is not where development happens, but it is still updated, according > to Ralf. I was considering to do that but haven't cooked the necessary scripts yet. Fortunately there doesn't seem to be too much need. Ralf From ralf@linux-mips.org Thu Oct 13 15:04:22 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Oct 2005 15:06:30 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:53268 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133482AbVJMOEW (ORCPT ); Thu, 13 Oct 2005 15:04:22 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j9DE4G8L009770; Thu, 13 Oct 2005 15:04:17 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j9DE4FWj009769; Thu, 13 Oct 2005 15:04:15 +0100 Date: Thu, 13 Oct 2005 15:04:15 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix possible sleeping in atomic on setup/restore sigcontext Message-ID: <20051013140415.GC2654@linux-mips.org> References: <20051007.235152.75184664.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051007.235152.75184664.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9220 X-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: 728 Lines: 19 On Fri, Oct 07, 2005 at 11:51:52PM +0900, Atsushi Nemoto wrote: > The setup_sigcontect/restore_sigcontext might sleep on > put_user/get_user with preemption disabled (i.e. atomic context). > Sleeping in atomic context is not allowed. This patch fixes this > problem using temporary variable (struct sigcontext tmpsc). > > Another possible fix might be rewriting > restore_fp_context/save_fp_context to copy to/from current > thread_struct and use them with restore_fp/save_fp. I think much of the 87d54649f67d8ffe0a8d8176de8c210a6c4bb4a7 preemption patch is flawed and the problem you were trying to fix are in part just caused by it. Rule of thumb - if there's a preempt_disable anywhere, it's probably wrong ... Ralf From ralf@linux-mips.org Thu Oct 13 20:32:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Oct 2005 20:32:46 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:54047 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3465602AbVJMTca (ORCPT ); Thu, 13 Oct 2005 20:32:30 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j9DJWP8i003908 for ; Thu, 13 Oct 2005 20:32:25 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j9DJWPsL003907 for linux-mips@linux-mips.org; Thu, 13 Oct 2005 20:32:25 +0100 Date: Thu, 13 Oct 2005 20:32:25 +0100 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Tftp problems with ARC firmware Message-ID: <20051013193225.GA3137@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9221 X-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: 637 Lines: 14 I'd like to point those who you need to use these crude workarounds: echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc echo 4096 32767 > /proc/sys/net/ipv4/ip_local_port_range at a new version of tftp-hpa which solves the PMTU problem by disabling it only for the tftp client and introduces a new -R begin:end option which allows to limit the port number range. The changes are about to become available in the tftp-hpa git repository at http://www.kernel.org/pub/scm/network/tftp/tftp-hpa.git; see also http://www.linux-mips.org/wiki/ARC#tftp-hpa. Please send test reports to syslinux@zytor.com and linux-mips@linux-mips.org. Ralf From flo@rfc822.org Thu Oct 13 23:09:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Oct 2005 23:10:08 +0100 (BST) Received: from hydra.gt.owl.de ([195.71.99.218]:20105 "EHLO hydra.gt.owl.de") by ftp.linux-mips.org with ESMTP id S3465606AbVJMWJr (ORCPT ); Thu, 13 Oct 2005 23:09:47 +0100 Received: by hydra.gt.owl.de (Postfix, from userid 104) id EFE48199429; Fri, 14 Oct 2005 00:09:44 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 67755138014; Fri, 14 Oct 2005 00:09:36 +0200 (CEST) Date: Fri, 14 Oct 2005 00:09:36 +0200 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: Tftp problems with ARC firmware Message-ID: <20051013220936.GA15668@paradigm.rfc822.org> References: <20051013193225.GA3137@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <20051013193225.GA3137@linux-mips.org> Organization: rfc822 - pure communication X-SpiderMe: mh-200510132349@listme.rfc822.org User-Agent: Mutt/1.5.9i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9222 X-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: 1578 Lines: 46 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2005 at 08:32:25PM +0100, Ralf Baechle wrote: > I'd like to point those who you need to use these crude workarounds: >=20 > echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc > echo 4096 32767 > /proc/sys/net/ipv4/ip_local_port_range >=20 > at a new version of tftp-hpa which solves the PMTU problem by disabling it > only for the tftp client and introduces a new -R begin:end option which > allows to limit the port number range. The changes are about to become > available in the tftp-hpa git repository at > http://www.kernel.org/pub/scm/network/tftp/tftp-hpa.git; see also > http://www.linux-mips.org/wiki/ARC#tftp-hpa. Please send test reports to > syslinux@zytor.com and linux-mips@linux-mips.org. I made a patch against tftpd-hpa for disabling path MTU discovery - Its in the Debian BTS:=20 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D316616 It should already be merged upstream. User "-F" to disable PMTUd. Flo --=20 Florian Lohoff flo@rfc822.org +49-171-2280134 Heisenberg may have been here. --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDTtsgUaz2rXW+gJcRAof2AJ4jhJukStNBxI0+wqfyXYw949AmDACeLnjO nvVgEBMw4ShjPVyjiSb/dgQ= =NWdP -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From anemo@mba.ocn.ne.jp Fri Oct 14 03:22:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Oct 2005 03:22:23 +0100 (BST) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:48137 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S3465614AbVJNCWF (ORCPT ); Fri, 14 Oct 2005 03:22:05 +0100 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 14 Oct 2005 02:22:35 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id E2E0F1FE9C; Fri, 14 Oct 2005 11:22:31 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id CF6591FE9A; Fri, 14 Oct 2005 11:22:31 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j9E2MUA9019109; Fri, 14 Oct 2005 11:22:31 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 14 Oct 2005 11:22:30 +0900 (JST) Message-Id: <20051014.112230.59032886.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix possible sleeping in atomic on setup/restore sigcontext From: Atsushi Nemoto In-Reply-To: <20051013140415.GC2654@linux-mips.org> References: <20051007.235152.75184664.anemo@mba.ocn.ne.jp> <20051013140415.GC2654@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 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9223 X-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: 9918 Lines: 381 >>>>> On Thu, 13 Oct 2005 15:04:15 +0100, Ralf Baechle said: ralf> I think much of the 87d54649f67d8ffe0a8d8176de8c210a6c4bb4a7 ralf> preemption patch is flawed and the problem you were trying to ralf> fix are in part just caused by it. Well... the patch fixed some problem because preempt_disable/enable is actually needed for lazy fpu switch, but some of the fixes was wrong (as I wrote at that time ;-)). Anyway, I create an another patch by rewriting restore_fp_context/save_fp_context. While thread.fpu.hard and thread.fpu.soft are completely same, things are quite simple. Description: The setup_sigcontect/restore_sigcontext might sleep on put_user/get_user with preemption disabled (i.e. atomic context). Sleeping in atomic context is not allowed. This patch fixes this problem rewriting restore_fp_context/save_fp_context. fp context saving path is: BEFORE: (thread.fpu -> ) real FPU -> sigcontext AFTER: (real FPU -> ) thread.fpu -> sigcontext arch/mips/kernel/signal-common.h | 56 +++++++++++++++++++++------ arch/mips/kernel/signal32.c | 54 ++++++++++++++++++++------ arch/mips/kernel/traps.c | 54 -------------------------- arch/mips/math-emu/kernel_linkage.c | 73 ------------------------------------ include/asm-mips/fpu.h | 9 ---- 5 files changed, 86 insertions(+), 160 deletions(-) Then we can remove all arch/mips/kernel/*_fpu.S and some (all?) SC_ symbols from asm-offset.c file. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -10,6 +10,42 @@ #include +/* + * Emulator context save/restore to/from a signal context + * presumed to be on the user stack, and therefore accessed + * with appropriate macros from uaccess.h + */ + +static inline int save_fp_context(struct sigcontext *sc) +{ + int i; + int err = 0; + + for (i = 0; i < 32; i++) { + err |= + __put_user(current->thread.fpu.soft.fpr[i], + &sc->sc_fpregs[i]); + } + err |= __put_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); + + return err; +} + +static inline int restore_fp_context(struct sigcontext *sc) +{ + int i; + int err = 0; + + for (i = 0; i < 32; i++) { + err |= + __get_user(current->thread.fpu.soft.fpr[i], + &sc->sc_fpregs[i]); + } + err |= __get_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); + + return err; +} + static inline int setup_sigcontext(struct pt_regs *regs, struct sigcontext *sc) { @@ -68,15 +104,14 @@ setup_sigcontext(struct pt_regs *regs, s * current FPU state. */ preempt_disable(); - - if (!is_fpu_owner()) { - own_fpu(); - restore_fp(current); + if (is_fpu_owner()) { + /* save current context to task_struct */ + save_fp(current); + /* no need to call lose_fpu here. */ } - err |= save_fp_context(sc); - preempt_enable(); + err |= save_fp_context(sc); out: return err; } @@ -138,19 +173,16 @@ restore_sigcontext(struct pt_regs *regs, err |= __get_user(used_math, &sc->sc_used_math); conditional_used_math(used_math); + /* signal handler may have used FPU. Give it up. */ preempt_disable(); + lose_fpu(); + preempt_enable(); if (used_math()) { /* restore fpu context if we have used it before */ - own_fpu(); err |= restore_fp_context(sc); - } else { - /* signal handler may have used FPU. Give it up. */ - lose_fpu(); } - preempt_enable(); - return err; } diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -335,6 +335,40 @@ asmlinkage int sys32_sigaltstack(nabi_no return ret; } +/* + * This is the o32 version + */ + +static inline int save_fp_context32(struct sigcontext32 *sc) +{ + int i; + int err = 0; + + for (i = 0; i < 32; i+=2) { + err |= + __put_user(current->thread.fpu.soft.fpr[i], + &sc->sc_fpregs[i]); + } + err |= __put_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); + + return err; +} + +static inline int restore_fp_context32(struct sigcontext32 *sc) +{ + int i; + int err = 0; + + for (i = 0; i < 32; i+=2) { + err |= + __get_user(current->thread.fpu.soft.fpr[i], + &sc->sc_fpregs[i]); + } + err |= __get_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); + + return err; +} + static int restore_sigcontext32(struct pt_regs *regs, struct sigcontext32 *sc) { u32 used_math; @@ -376,19 +410,16 @@ static int restore_sigcontext32(struct p err |= __get_user(used_math, &sc->sc_used_math); conditional_used_math(used_math); + /* signal handler may have used FPU. Give it up. */ preempt_disable(); + lose_fpu(); + preempt_enable(); if (used_math()) { /* restore fpu context if we have used it before */ - own_fpu(); err |= restore_fp_context32(sc); - } else { - /* signal handler may have used FPU. Give it up. */ - lose_fpu(); } - preempt_enable(); - return err; } @@ -609,15 +640,14 @@ static inline int setup_sigcontext32(str * current FPU state. */ preempt_disable(); - - if (!is_fpu_owner()) { - own_fpu(); - restore_fp(current); + if (is_fpu_owner()) { + /* save current context to task_struct */ + save_fp(current); + /* no need to call lose_fpu here. */ } - err |= save_fp_context32(sc); - preempt_enable(); + err |= save_fp_context32(sc); out: return err; } diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -1098,55 +1098,6 @@ void *set_vi_handler (int n, void *addr) } #endif -/* - * This is used by native signal handling - */ -asmlinkage int (*save_fp_context)(struct sigcontext *sc); -asmlinkage int (*restore_fp_context)(struct sigcontext *sc); - -extern asmlinkage int _save_fp_context(struct sigcontext *sc); -extern asmlinkage int _restore_fp_context(struct sigcontext *sc); - -extern asmlinkage int fpu_emulator_save_context(struct sigcontext *sc); -extern asmlinkage int fpu_emulator_restore_context(struct sigcontext *sc); - -static inline void signal_init(void) -{ - if (cpu_has_fpu) { - save_fp_context = _save_fp_context; - restore_fp_context = _restore_fp_context; - } else { - save_fp_context = fpu_emulator_save_context; - restore_fp_context = fpu_emulator_restore_context; - } -} - -#ifdef CONFIG_MIPS32_COMPAT - -/* - * This is used by 32-bit signal stuff on the 64-bit kernel - */ -asmlinkage int (*save_fp_context32)(struct sigcontext32 *sc); -asmlinkage int (*restore_fp_context32)(struct sigcontext32 *sc); - -extern asmlinkage int _save_fp_context32(struct sigcontext32 *sc); -extern asmlinkage int _restore_fp_context32(struct sigcontext32 *sc); - -extern asmlinkage int fpu_emulator_save_context32(struct sigcontext32 *sc); -extern asmlinkage int fpu_emulator_restore_context32(struct sigcontext32 *sc); - -static inline void signal32_init(void) -{ - if (cpu_has_fpu) { - save_fp_context32 = _save_fp_context32; - restore_fp_context32 = _restore_fp_context32; - } else { - save_fp_context32 = fpu_emulator_save_context32; - restore_fp_context32 = fpu_emulator_restore_context32; - } -} -#endif - extern void cpu_cache_init(void); extern void tlb_init(void); @@ -1350,10 +1301,5 @@ void __init trap_init(void) else memcpy((void *)(CAC_BASE + 0x080), &except_vec3_generic, 0x80); - signal_init(); -#ifdef CONFIG_MIPS32_COMPAT - signal32_init(); -#endif - flush_icache_range(ebase, ebase + 0x400); } diff --git a/arch/mips/math-emu/kernel_linkage.c b/arch/mips/math-emu/kernel_linkage.c --- a/arch/mips/math-emu/kernel_linkage.c +++ b/arch/mips/math-emu/kernel_linkage.c @@ -44,76 +44,3 @@ void fpu_emulator_init_fpu(void) current->thread.fpu.soft.fpr[i] = SIGNALLING_NAN; } } - - -/* - * Emulator context save/restore to/from a signal context - * presumed to be on the user stack, and therefore accessed - * with appropriate macros from uaccess.h - */ - -int fpu_emulator_save_context(struct sigcontext *sc) -{ - int i; - int err = 0; - - for (i = 0; i < 32; i++) { - err |= - __put_user(current->thread.fpu.soft.fpr[i], - &sc->sc_fpregs[i]); - } - err |= __put_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); - - return err; -} - -int fpu_emulator_restore_context(struct sigcontext *sc) -{ - int i; - int err = 0; - - for (i = 0; i < 32; i++) { - err |= - __get_user(current->thread.fpu.soft.fpr[i], - &sc->sc_fpregs[i]); - } - err |= __get_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); - - return err; -} - -#ifdef CONFIG_64BIT -/* - * This is the o32 version - */ - -int fpu_emulator_save_context32(struct sigcontext32 *sc) -{ - int i; - int err = 0; - - for (i = 0; i < 32; i+=2) { - err |= - __put_user(current->thread.fpu.soft.fpr[i], - &sc->sc_fpregs[i]); - } - err |= __put_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); - - return err; -} - -int fpu_emulator_restore_context32(struct sigcontext32 *sc) -{ - int i; - int err = 0; - - for (i = 0; i < 32; i+=2) { - err |= - __get_user(current->thread.fpu.soft.fpr[i], - &sc->sc_fpregs[i]); - } - err |= __get_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); - - return err; -} -#endif diff --git a/include/asm-mips/fpu.h b/include/asm-mips/fpu.h --- a/include/asm-mips/fpu.h +++ b/include/asm-mips/fpu.h @@ -21,15 +21,6 @@ #include #include -struct sigcontext; -struct sigcontext32; - -extern asmlinkage int (*save_fp_context)(struct sigcontext *sc); -extern asmlinkage int (*restore_fp_context)(struct sigcontext *sc); - -extern asmlinkage int (*save_fp_context32)(struct sigcontext32 *sc); -extern asmlinkage int (*restore_fp_context32)(struct sigcontext32 *sc); - extern void fpu_emulator_init_fpu(void); extern void _init_fpu(void); extern void _save_fp(struct task_struct *); From ralf@linux-mips.org Fri Oct 14 11:51:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Oct 2005 11:51:36 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:4105 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133494AbVJNKvS (ORCPT ); Fri, 14 Oct 2005 11:51:18 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j9EAp9iA001842; Fri, 14 Oct 2005 11:51:09 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j9DMtLSp006759; Thu, 13 Oct 2005 23:55:21 +0100 Date: Thu, 13 Oct 2005 23:55:21 +0100 From: Ralf Baechle To: David Daney , linux-mips@linux-mips.org Subject: Re: OProfile cannot be loaded as module... Message-ID: <20051013225520.GA3234@linux-mips.org> References: <43470BCF.1070709@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43470BCF.1070709@avtrex.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9224 X-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: 869 Lines: 21 On Fri, Oct 07, 2005 at 04:59:11PM -0700, David Daney wrote: > arch/mips/oprofile/common.c defines several symbols (op_model_mipsxx and > op_model_rm9000) with __attribute__((weak)). It then assumes that ELF > linking conventions will prevail and there will be no problems if they > are undefined. > > The problem is if you try to load oprofile as a module. The kernel > module linker evidentially does not understand weak symbols and refuses > to load the module because they are undefined. Actually it contains code to handle weak symbols so this is a bit surprising not last because STB_WEAK handling happen in the generic module loader code and is being used by other architectures as well. So if there's a problem with the module loader I'd prefer to solve that instead of starting to kludge around it. What compiler exactly are you using btw? Ralf From ralf@linux-mips.org Fri Oct 14 12:11:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Oct 2005 12:11:23 +0100 (BST) Received: from extgw-uk.mips.com ([62.254.210.129]:17684 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133494AbVJNLLD (ORCPT ); Fri, 14 Oct 2005 12:11:03 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j9EBAx2H003957; Fri, 14 Oct 2005 12:10:59 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j9EBAwAw003956; Fri, 14 Oct 2005 12:10:58 +0100 Date: Fri, 14 Oct 2005 12:10:58 +0100 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@linux-mips.org Subject: Re: Tftp problems with ARC firmware Message-ID: <20051014111058.GA2608@linux-mips.org> References: <20051013193225.GA3137@linux-mips.org> <20051013220936.GA15668@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051013220936.GA15668@paradigm.rfc822.org> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9225 X-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: 1458 Lines: 31 On Fri, Oct 14, 2005 at 12:09:36AM +0200, Florian Lohoff wrote: > > echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc > > echo 4096 32767 > /proc/sys/net/ipv4/ip_local_port_range > > > > at a new version of tftp-hpa which solves the PMTU problem by disabling it > > only for the tftp client and introduces a new -R begin:end option which > > allows to limit the port number range. The changes are about to become > > available in the tftp-hpa git repository at > > http://www.kernel.org/pub/scm/network/tftp/tftp-hpa.git; see also > > http://www.linux-mips.org/wiki/ARC#tftp-hpa. Please send test reports to > > syslinux@zytor.com and linux-mips@linux-mips.org. > > I made a patch against tftpd-hpa for disabling path MTU discovery - Its > in the Debian BTS: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316616 > > It should already be merged upstream. User "-F" to disable PMTUd. Never made it to HPA - HPA wrote the patches for these two bugs himself yesterday when I mentioned the problem to him. His patches are different in the he disables PMTU discovery entirely - it's not useful for TFTP. And your patch doesn't work around the other firmware bug which requires restricting the port range. We had to get rid of the currently recommended workaround - it seriously restricts the IP stack; cripples is probably the right expression for busy servers. Patch rotting in the Debian bugtracking system seems to become a classic ;-) Ralf From ivy.mips@gmail.com Fri Oct 14 14:31:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Oct 2005 14:31:36 +0100 (BST) Received: from wproxy.gmail.com ([64.233.184.194]:8375 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133505AbVJNNbT convert rfc822-to-8bit (ORCPT ); Fri, 14 Oct 2005 14:31:19 +0100 Received: by wproxy.gmail.com with SMTP id i7so280621wra for ; Fri, 14 Oct 2005 06:31:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ciT5bu0zvXpbKzA2AG8Itgn8Yn27RcHKXpOgM5o/HH22VH6ke1NiXDbTIZiXqFn1e3F5TduzYTQzURPkMaAkG34uSrkVMh8fkBisd6VtwfSFKW/HLk0F3XTl6zQzLt8WFVVMauJI5u20FniILHwkdK2IyY5kZuOkD+ivK5RQiZs= Received: by 10.54.89.7 with SMTP id m7mr962559wrb; Fri, 14 Oct 2005 06:31:17 -0700 (PDT) Received: by 10.54.79.15 with HTTP; Fri, 14 Oct 2005 06:31:17 -0700 (PDT) Message-ID: <8a58e1120510140631yd33f85dg3e3e9c993555726@mail.gmail.com> Date: Fri, 14 Oct 2005 19:01:17 +0530 From: Ivy green To: linux-mips@linux-mips.org Subject: Linux on BCM7038 ?. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9226 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ivy.mips@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 203 Lines: 11 Hi folks, I am very newbie to MIPS Architecure. I would like to use Linux on BCM7038. Is there any Patches already available to apply on kernel (>= 2.4.29) ?. Thanks Ivy From giometti@enneenne.com Fri Oct 14 15:16:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Oct 2005 15:17:16 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:55952 "EHLO zaigor.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133505AbVJNOQ4 (ORCPT ); Fri, 14 Oct 2005 15:16:56 +0100 Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1EQQMS-0003LC-00 for ; Fri, 14 Oct 2005 16:16:40 +0200 Date: Fri, 14 Oct 2005 16:16:40 +0200 From: Rodolfo Giometti To: linux-mips@linux-mips.org Subject: about au_sleep for au1x00 Message-ID: <20051014141640.GS6808@enneenne.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sSWUSaCcagxd8grv" Content-Disposition: inline Organization: Programmi e soluzioni GNU/Linux X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633 User-Agent: Mutt/1.5.6+20040722i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9227 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips Content-Length: 13090 Lines: 426 --sSWUSaCcagxd8grv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, attached is my proposal for a new (and better? :) implementation of au_sleep() function (patch is against vanilla MIPS 2.6.12). My patch adds two board specific functions whose are called before and after CPU sleeping. This can be useful to setup hardware for sleeping and also to ask to the board which should be the wake up reason (GPIO, TOY). Patch also fixes data reading from files /proc/sys/pm/{sleep,freq}. What is still obscure to me is how I can use the au_sleep() in order to ibernate the system... or better... how I can resume form ibarnation. In fact the system reboots correctly but it start from the beginning! What I have to do in order to have the system restart from ibarnation? My boot loader is u-boot 1.1.3. Thanks in advance, Rodolfo -- GNU/Linux Solutions e-mail: giometti@linux.it Linux Device Driver giometti@enneenne.com Embedded Systems home page: giometti.enneenne.com UNIX programming phone: +39 349 2432127 --sSWUSaCcagxd8grv Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ausleep.patch" Index: arch/mips/au1000/common/power.c =================================================================== RCS file: /home/develop/cvs_private/linux-mips-exadron/arch/mips/au1000/common/power.c,v retrieving revision 1.1.1.1 retrieving revision 1.4 diff -u -r1.1.1.1 -r1.4 --- a/arch/mips/au1000/common/power.c 2 Jul 2005 06:45:44 -0000 1.1.1.1 +++ b/arch/mips/au1000/common/power.c 14 Oct 2005 13:39:43 -0000 1.4 @@ -34,12 +34,18 @@ #include #include #include +#include #include #include #include #include +#include #include +#include + +static int sleep_ticks; +static unsigned long cpu_freq; #ifdef CONFIG_PM @@ -50,7 +56,7 @@ # define DPRINTK(fmt, args...) #endif -static void calibrate_delay(void); +static void au1000_calibrate_delay(void); extern void set_au1x00_speed(unsigned int new_freq); extern unsigned int get_au1x00_speed(void); @@ -89,17 +95,6 @@ static uint sleep_usbdev_enable; static uint sleep_static_memctlr[4][3]; -/* Define this to cause the value you write to /proc/sys/pm/sleep to - * set the TOY timer for the amount of time you want to sleep. - * This is done mainly for testing, but may be useful in other cases. - * The value is number of 32KHz ticks to sleep. - */ -#define SLEEP_TEST_TIMEOUT 1 -#ifdef SLEEP_TEST_TIMEOUT -static int sleep_ticks; -void wakeup_counter0_set(int ticks); -#endif - static void save_core_regs(void) { @@ -210,10 +205,23 @@ suspend_mode = 0; } -int au_sleep(void) +void wakeup_counter0_set(int ticks); +int (*board_before_sleep)(void); +void (*board_after_sleep)(int reason); + +int au_sleep(int reason, int force) { + int ticks; unsigned long wakeup, flags; - extern void save_and_sleep(void); + int board_reason = 0; + + /* We need to configure the GPIO or timer interrupts that will bring + * us out of sleep, so we use the specific board wake up source + * (if present) */ + if (board_before_sleep) + board_reason = board_before_sleep(); + if (!force) + reason = board_reason; spin_lock_irqsave(&pm_lock,flags); @@ -221,29 +229,22 @@ flush_cache_all(); - /** The code below is all system dependent and we should probably - ** have a function call out of here to set this up. You need - ** to configure the GPIO or timer interrupts that will bring - ** you out of sleep. - ** For testing, the TOY counter wakeup is useful. - **/ - -#if 0 - au_writel(au_readl(SYS_PINSTATERD) & ~(1 << 11), SYS_PINSTATERD); - - /* gpio 6 can cause a wake up event */ - wakeup = au_readl(SYS_WAKEMSK); - wakeup &= ~(1 << 8); /* turn off match20 wakeup */ - wakeup |= 1 << 6; /* turn on gpio 6 wakeup */ -#else - /* For testing, allow match20 to wake us up. - */ -#ifdef SLEEP_TEST_TIMEOUT - wakeup_counter0_set(sleep_ticks); -#endif - wakeup = 1 << 8; /* turn on match20 wakeup */ - wakeup = 0; -#endif + if (reason == 0) /* machine_halt() */ + wakeup = 0; + else if (reason < 0) { /* TOY wake up */ + ticks = -reason*HZ; + wakeup_counter0_set(ticks); + wakeup = 1<<8; /* turn on match20 as wake up */ + } + else { /* GPIO[0-7] wake up */ + /* We force pin GPIO[6]/SMROMCKE as gpio6 */ + au_writel(au_readl(SYS_PINSTATERD)&~(1<<11), SYS_PINSTATERD); + + wakeup = reason&0x0ff; /* turn on selected gpio as wake up */ + } + printk("%s - reason %x force %x wakeup %x ticks %x\n", + __FUNCTION__, reason, force, wakeup, ticks); + au_writel(1, SYS_WAKESRC); /* clear cause */ au_sync(); au_writel(wakeup, SYS_WAKEMSK); @@ -251,50 +252,50 @@ save_and_sleep(); - /* after a wakeup, the cpu vectors back to 0x1fc00000 so + /* after a wake up, the cpu vectors back to 0x1fc00000 so * it's up to the boot code to get us back here. */ restore_core_regs(); + spin_unlock_irqrestore(&pm_lock, flags); + + /* Get wake up source */ + reason = au_readl(SYS_WAKESRC)>>18; + if (reason&(1<<8)) /* Wake up thanks to TOY */ + reason = -ticks*HZ; + + /* Call specific board routine */ + if (board_after_sleep) + board_after_sleep(reason); + return 0; } -static int pm_do_sleep(ctl_table * ctl, int write, struct file *file, - void *buffer, size_t * len) +static int pm_do_sleep(ctl_table *ctl, int write, struct file *file, + void __user *buffer, size_t *len, loff_t *ppos) { int retval = 0; -#ifdef SLEEP_TEST_TIMEOUT -#define TMPBUFLEN2 16 - char buf[TMPBUFLEN2], *p; -#endif + int *valp = (int *) ctl->data; - if (!write) { + if (!write) *len = 0; - } else { -#ifdef SLEEP_TEST_TIMEOUT - if (*len > TMPBUFLEN2 - 1) { - return -EFAULT; - } - if (copy_from_user(buf, buffer, *len)) { - return -EFAULT; - } - buf[*len] = 0; - p = buf; - sleep_ticks = simple_strtoul(p, &p, 0); -#endif - retval = pm_send_all(PM_SUSPEND, (void *) 2); + retval = proc_dointvec(ctl, write, file, buffer, len, ppos); + + if (write) { + retval = pm_send_all(PM_SUSPEND, (void *) 2); if (retval) return retval; - au_sleep(); + au_sleep(*valp > 0 ? -*valp : 0, 1); + retval = pm_send_all(PM_RESUME, (void *) 0); } return retval; } static int pm_do_suspend(ctl_table * ctl, int write, struct file *file, - void *buffer, size_t * len) + void __user *buffer, size_t * len, loff_t *ppos) { int retval = 0; @@ -313,40 +314,32 @@ static int pm_do_freq(ctl_table * ctl, int write, struct file *file, - void *buffer, size_t * len) + void __user *buffer, size_t * len, loff_t *ppos) { int retval = 0, i; - unsigned long val, pll; -#define TMPBUFLEN 64 -#define MAX_CPU_FREQ 396 - char buf[TMPBUFLEN], *p; + unsigned long *valp = (unsigned long *) ctl->data; + unsigned long pll; unsigned long flags, intc0_mask, intc1_mask; unsigned long old_baud_base, old_cpu_freq, baud_rate, old_clk, old_refresh; unsigned long new_baud_base, new_cpu_freq, new_clk, new_refresh; spin_lock_irqsave(&pm_lock, flags); - if (!write) { + + if (!write) *len = 0; - } else { - /* Parse the new frequency */ - if (*len > TMPBUFLEN - 1) { - spin_unlock_irqrestore(&pm_lock, flags); - return -EFAULT; - } - if (copy_from_user(buf, buffer, *len)) { - spin_unlock_irqrestore(&pm_lock, flags); - return -EFAULT; - } - buf[*len] = 0; - p = buf; - val = simple_strtoul(p, &p, 0); - if (val > MAX_CPU_FREQ) { + + retval = proc_dointvec(ctl, write, file, buffer, len, ppos); + +#define MAX_CPU_FREQ 396 + if (write) { + /* Check the new frequency */ + if (*valp > MAX_CPU_FREQ) { spin_unlock_irqrestore(&pm_lock, flags); return -EFAULT; } - pll = val / 12; + pll = *valp / 12; if ((pll > 33) || (pll < 7)) { /* 396 MHz max, 84 MHz min */ /* revisit this for higher speed cpus */ spin_unlock_irqrestore(&pm_lock, flags); @@ -408,14 +401,14 @@ /* We don't want _any_ interrupts other than - * match20. Otherwise our calibrate_delay() + * match20. Otherwise our au1000_calibrate_delay() * calculation will be off, potentially a lot. */ intc0_mask = save_local_and_disable(0); intc1_mask = save_local_and_disable(1); local_enable_irq(AU1000_TOY_MATCH2_INT); spin_unlock_irqrestore(&pm_lock, flags); - calibrate_delay(); + au1000_calibrate_delay(); restore_local_and_enable(0, intc0_mask); restore_local_and_enable(1, intc1_mask); return retval; @@ -424,8 +417,8 @@ static struct ctl_table pm_table[] = { {ACPI_S1_SLP_TYP, "suspend", NULL, 0, 0600, NULL, &pm_do_suspend}, - {ACPI_SLEEP, "sleep", NULL, 0, 0600, NULL, &pm_do_sleep}, - {CTL_ACPI, "freq", NULL, 0, 0600, NULL, &pm_do_freq}, + {ACPI_SLEEP, "sleep", &sleep_ticks, sizeof(int), 0600, NULL, &pm_do_sleep}, + {CTL_ACPI, "freq", &cpu_freq, sizeof(int), 0600, NULL, &pm_do_freq}, {0} }; @@ -455,7 +448,7 @@ better than 1% */ #define LPS_PREC 8 -static void calibrate_delay(void) +static void au1000_calibrate_delay(void) { unsigned long ticks, loopbit; int lps_precision = LPS_PREC; Index: arch/mips/au1000/common/reset.c =================================================================== RCS file: /home/develop/cvs_private/linux-mips-exadron/arch/mips/au1000/common/reset.c,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- a/arch/mips/au1000/common/reset.c 2 Jul 2005 06:45:44 -0000 1.1.1.1 +++ b/arch/mips/au1000/common/reset.c 14 Oct 2005 13:40:27 -0000 1.3 @@ -36,8 +36,8 @@ #include #include #include +#include -extern int au_sleep(void); extern void (*flush_cache_all)(void); void au1000_restart(char *command) @@ -176,7 +176,7 @@ au_writel((1 << 26) | (1 << 10), GPIO2_OUTPUT); #endif #ifdef CONFIG_PM - au_sleep(); + au_sleep(0, 0); /* should not get here */ printk(KERN_ERR "Unable to put cpu in sleep mode\n"); Index: include/asm-mips/mach-au1x00/power.h =================================================================== RCS file: include/asm-mips/mach-au1x00/power.h diff -N include/asm-mips/mach-au1x00/power.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ b/include/asm-mips/mach-au1x00/power.h 14 Oct 2005 13:41:29 -0000 1.2 @@ -0,0 +1,61 @@ +/* + * + * BRIEF MODULE DESCRIPTION + * Include file for power management of Alchemy Semiconductor's + * Au1k CPU. + * + * Copyright 2005 Rodolfo Giometti + * Author: Rodolfo Giometti + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#ifndef _AU1X00_POWER_H_ +#define _AU1X00_POWER_H_ + +/* Save CPU state and go to sleep */ +extern void save_and_sleep(void); + +/* Do system settings before sleeping. + * + * If "reason" + * > 0 then we use GPIO[0-7] as wakeup source according to + * bits set to "1" (ex. reason==5 set up as wake up sorces + * GPIOs 0 and 2). + * < 0 then we use "-reason" as sleeping seconds before wakeup. + * == 0 then we consider machine_halt(). + * + * If "force" != 0 then the "reason" value cannot be changed by + * function board_before_sleep() */ +extern int au_sleep(int reason, int force); + +/* These functions are called by au_sleep() before, and after, + * sleeping mode. + * + * These functions are defaulted to NULL and can remain so. + * + * Function "board_before_sleep()" returns an interger (called "reason") + * and function "board_after_sleep" takes "reason" as argument. Such + * parameter point the cause of sleeping mode as defined for au_sleep(). */ +extern int (*board_before_sleep)(void); +extern void (*board_after_sleep)(int reason); + +#endif /* _AU1X00_POWER_H_ */ --sSWUSaCcagxd8grv-- From redhatter@gentoo.org Sat Oct 15 06:13:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 Oct 2005 06:13:53 +0100 (BST) Received: from 202-47-55-78.adsl.gil.com.au ([202.47.55.78]:42986 "EHLO longlandclan.hopto.org") by ftp.linux-mips.org with ESMTP id S8133499AbVJOFNe (ORCPT ); Sat, 15 Oct 2005 06:13:34 +0100 Received: (qmail 17547 invoked from network); 15 Oct 2005 15:13:21 +1000 Received: from beast.redhatters.home (HELO ?10.0.0.251?) (10.0.0.251) by 192.168.5.1 with SMTP; 15 Oct 2005 15:13:21 +1000 Message-ID: <43508FF5.7030306@gentoo.org> Date: Sat, 15 Oct 2005 15:13:25 +1000 From: Stuart Longland Organization: Gentoo Foundation User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivy green CC: linux-mips@linux-mips.org Subject: Re: Linux on BCM7038 ?. References: <8a58e1120510140631yd33f85dg3e3e9c993555726@mail.gmail.com> In-Reply-To: <8a58e1120510140631yd33f85dg3e3e9c993555726@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 OpenPGP: id=63264AB9; url=http://dev.gentoo.org/~redhatter/gpgkey.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E6FA871DBEE477DB6DA88C7" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: redhatter@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 1120 Lines: 34 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E6FA871DBEE477DB6DA88C7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Ivy green wrote: > Hi folks, > Is there any Patches already available to apply on > kernel (>= 2.4.29) ?. kernel 2.4.29 from kernel.org?? Or kernel 2.4.29 from Linux/MIPS.org? There's a difference... a _big_ difference. -- Stuart Longland (aka Redhatter) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' --------------enig5E6FA871DBEE477DB6DA88C7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDUI/4uarJ1mMmSrkRAkU/AJ9D8st5VtUpVh329IgdVRsvTzJTowCeIjR/ qHjumfXhvelRE5epR6NAVTc= =dV4f -----END PGP SIGNATURE----- --------------enig5E6FA871DBEE477DB6DA88C7-- From shuveb@gmail.com Sat Oct 15 09:33:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 Oct 2005 09:33:31 +0100 (BST) Received: from wproxy.gmail.com ([64.233.184.201]:61668 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133519AbVJOIdQ convert rfc822-to-8bit (ORCPT ); Sat, 15 Oct 2005 09:33:16 +0100 Received: by wproxy.gmail.com with SMTP id i7so354042wra for ; Sat, 15 Oct 2005 01:33:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=d6VxmD0MkbmSFQo+G829DRJvwM2T1wPJfAuZtbE3Bh26ngXZPLVbaItfQ1iHd/REGGu9oUxuMfOhELM95MeSJNSk527Ja35m7YRCm91mXqNIKPyHA47gV+8nPuYZmgEYrVIbZh2Ej9Ar5u0g/N8Dcv4WlqSqjrYGzebcR3KPbZU= Received: by 10.54.80.8 with SMTP id d8mr1290511wrb; Sat, 15 Oct 2005 01:33:13 -0700 (PDT) Received: by 10.54.132.12 with HTTP; Sat, 15 Oct 2005 01:33:13 -0700 (PDT) Message-ID: Date: Sat, 15 Oct 2005 14:03:13 +0530 From: Shuveb Hussain To: linux-mips@linux-mips.org Subject: mem_in? and mem_out? functions MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: shuveb@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 797 Lines: 28 Hi, I am compiling the source from git. There are definitions of macros in include/asm/io.h for the following: mem_inb mem_outb mem_inl mem_outl ... ... The issue is that the driver : drivers/char/ipmi/ - have redeclared these macros as functions statically, in the file - ipmi_si_intf.c I do not know if this driver is used on MIPS at all, but it does get into the way of proper compilation. If compilation of the IPMI driver in any form is disabled (by default it gets compiled as a module), then the compilation goes on smoothly. I changed the names of these functions slightly and made other modifications as to compile properly and now everything is OK, but I do not know if this is the best way to do it, though it works for me now. What is the best solution for this issue? --shuveb From bprasad@CS.Arizona.EDU Sat Oct 15 10:20:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 Oct 2005 10:20:23 +0100 (BST) Received: from optima.cs.arizona.edu ([192.12.69.5]:16652 "EHLO optima.cs.arizona.edu") by ftp.linux-mips.org with ESMTP id S8133522AbVJOJUH (ORCPT ); Sat, 15 Oct 2005 10:20:07 +0100 Received: from lectura.CS.Arizona.EDU (lectura.cs.arizona.edu [192.12.69.186]) by optima.cs.arizona.edu (8.13.4/8.13.4) with ESMTP id j9F9JwTP075865 for ; Sat, 15 Oct 2005 02:19:58 -0700 (MST) (envelope-from bprasad@CS.Arizona.EDU) Date: Sat, 15 Oct 2005 02:19:58 -0700 (MST) From: Prasad Venkata Boddupalli To: linux-mips@linux-mips.org Subject: Reg Hardware context and Signal Handlers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: bprasad@CS.Arizona.EDU Precedence: bulk X-list: linux-mips Content-Length: 1676 Lines: 59 I am reading the program counter value from the hardware context passed as the third argument to the signal handler. It doesn't seem to the same value being set in setup_sigcontext() function in arch/mips/kernel/signal.c. I am using kernel version 2.6.6-rc3 and, I printed out the PC twice, once in the kernel (signal.c) #include setup_rt_frame(struct k_sigaction * ka, struct pt_regs *regs, ...) { ... regs->regs[ 5] = (unsigned long) &frame->rs_info; regs->regs[ 6] = (unsigned long) &frame->rs_uc; printk("SIG deliver pc=0x%llx\n", ((((struct ucontext *)regs->regs[6])->uc_mcontext).sc_pc)); regs->regs[29] = (unsigned long) frame; ... force_sig(SIGSEGV, current) } Then I get the value 0x414830 repeatedly. I print the same in my signal handler as #include void dispatch_timer(int signal, siginfo_t * si, void *context) { ... printf ("pc value: 0x%llx\n", ((struct ucontext *)context)->uc_mcontext).sc_pc); ... } and I see a different value '0x7ff8000000000000'. The values (addresses) of the third argument 'context' in my signal handler is the same (as it must be) as 'regs->regs[6]' assigned just above the print statement in setup_rt_frame(). I saw a few comments in the file sys/ucontext.h that read /* Don't rely on this, the interface is currently messed up and may need to be broken to be fixed. */ So, I am not sure if those comments still hold good. I am anyway including the header asm/ucontext.h and 'struct ucontext' seems to be different in the two header files. Does this problem sound familiar or am I screwing up something ? regards, Prasad. From karsten@excalibur.cologne.de Sun Oct 16 19:03:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 Oct 2005 19:04:03 +0100 (BST) Received: from natfrord.rzone.de ([81.169.145.161]:33987 "EHLO natfrord.rzone.de") by ftp.linux-mips.org with ESMTP id S8133554AbVJPSDb (ORCPT ); Sun, 16 Oct 2005 19:03:31 +0100 Received: from excalibur.cologne.de (cable-84-44-248-18.netcologne.de [84.44.248.18]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j9GI3S7C002632 for ; Sun, 16 Oct 2005 20:03:28 +0200 (MEST) Received: from karsten by excalibur.cologne.de with local (Exim 3.36 #1 (Debian)) id 1ERCqv-0002bh-00 for ; Sun, 16 Oct 2005 20:03:21 +0200 Date: Sun, 16 Oct 2005 20:03:21 +0200 From: Karsten Merker To: linux-mips@linux-mips.org Subject: I2-R10k patchset - help needed Message-ID: <20051016180321.GA9993@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-No-Archive: yes User-Agent: Mutt/1.5.9i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: karsten@excalibur.cologne.de Precedence: bulk X-list: linux-mips Content-Length: 99716 Lines: 3090 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hallo everybody, I am trying to get the current git tree running on an I2 R10k, so I applied Peter Fürsts patches from http://home.alphastar.de/fuerst/download.html to it. As these are against 2.6.12-rc2, I got a bunch of rejects, which I have resolved manually, but I am stuck with the patch for include/asm-mips/stackframe.h. I would be very grateful if somebody could take a look into this and provide an updated patch against the current kernel sources. Attached to this mail is both my version of Peter Fürsts "collected.diff" (applies cleanly against current git but without the stackframe.h-patch) as well as the original stackframe.h patch. Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. --AhhlLboLdkugWU4S Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="R10k-changes-without-stackframe.h.diff" Content-Transfer-Encoding: 8bit diff -Nur linux-git/arch/mips/Kconfig linux-git-mit-R10k-patches/arch/mips/Kconfig --- linux-git/arch/mips/Kconfig 2005-10-15 16:01:06.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/Kconfig 2005-10-16 13:21:56.000000000 +0200 @@ -527,6 +527,25 @@ workstations. To compile a Linux kernel that runs on these, say Y here. +config SGI_IP28 + bool "Support for SGI IP28 (Indigo2 R10k) (EXPERIMENTAL)" + depends EXPERIMENTAL + select ARC + select ARC64 + select DMA_NONCOHERENT + select IRQ_CPU + select SWAP_IO_SPACE + select HW_HAS_EISA + select CPU_R10000 + select XKPHYS_KERNEL + select BUILD_ELF64 + select BOOT_ELF64 + select SYS_SUPPORTS_64BIT_KERNEL + select SYS_SUPPORTS_BIG_ENDIAN + help + This is the SGI Indigo2 with R10000 processor. To compile a Linux + kernel that runs on these, say Y here. + config SGI_IP32 bool "Support for SGI IP32 (O2) (EXPERIMENTAL)" depends on EXPERIMENTAL @@ -942,7 +961,7 @@ config ARC_CONSOLE bool "ARC console support" - depends on SGI_IP22 || SNI_RM200_PCI + depends on SGI_IP22 || SNI_RM200_PCI || SGI_IP28 config ARC_MEMORY bool @@ -951,7 +970,7 @@ config ARC_PROMLIB bool - depends on MACH_JAZZ || SNI_RM200_PCI || SGI_IP22 || SGI_IP32 + depends on MACH_JAZZ || SNI_RM200_PCI || SGI_IP22 || SGI_IP28 || SGI_IP32 default y config ARC64 @@ -1319,6 +1338,14 @@ bool "Support for 64-bit physical address space" depends on (CPU_R4X00 || CPU_R5000 || CPU_RM7000 || CPU_RM9000 || CPU_R10000 || CPU_SB1 || CPU_MIPS32_R1 || CPU_MIPS64_R1) && 32BIT +config XKPHYS_KERNEL + bool "Allow kernel to run from 64-bit segments" + depends on MIPS64 + help + This option allows to locate the kernel in 64-bit unmapped memory + space (xkphys). This is required for Octane (IP30) or Indigo2 R10k + (IP28) machines. + config CPU_ADVANCED bool "Override CPU Options" depends on 32BIT @@ -1643,6 +1670,9 @@ and the task is only allowed to execute a few safe syscalls defined by each seccomp mode. +# Revision 1.145, Tue Apr 19 00:00:45 2005 +# Jun/Dec 2004 - IP28 + If unsure, say Y. Only embedded should say N here. config PM diff -Nur linux-git/arch/mips/kernel/gdb-low.S linux-git-mit-R10k-patches/arch/mips/kernel/gdb-low.S --- linux-git/arch/mips/kernel/gdb-low.S 2005-10-15 16:01:06.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/kernel/gdb-low.S 2005-10-16 13:21:56.000000000 +0200 @@ -52,7 +52,11 @@ /* * Called from user mode, go somewhere else. */ +#ifdef CONFIG_XKPHYS_KERNEL + dla k1, saved_vectors +#else lui k1, %hi(saved_vectors) +#endif mfc0 k0, CP0_CAUSE andi k0, k0, 0x7c add k1, k1, k0 @@ -61,7 +65,11 @@ nop 1: move k0, sp +#ifdef CONFIG_MIPS64 + dsubu sp, k1, GDB_FR_SIZE*2 # see comment above +#else subu sp, k1, GDB_FR_SIZE*2 # see comment above +#endif LONG_S k0, GDB_FR_REG29(sp) LONG_S $2, GDB_FR_REG2(sp) @@ -368,3 +376,7 @@ kgdbfault: li v0, -EFAULT jr ra .end kgdbfault +/* + * Revision 1.17, Mon Nov 17 17:19:39 2003 + * Wed May 12 21:21:49 2004 xkphys kernel addresses + */ diff -Nur linux-git/arch/mips/kernel/setup.c linux-git-mit-R10k-patches/arch/mips/kernel/setup.c --- linux-git/arch/mips/kernel/setup.c 2005-10-15 16:01:06.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/kernel/setup.c 2005-10-16 13:25:04.000000000 +0200 @@ -302,7 +302,7 @@ * Partially used pages are not usable - thus * we are rounding upwards. */ - start_pfn = PFN_UP(CPHYSADDR(reserved_end)); + start_pfn = PFN_UP(kernel_physaddr(reserved_end)); #ifndef CONFIG_SGI_IP27 /* Find the highest page frame number we have available. */ @@ -426,11 +426,11 @@ printk("Initial ramdisk at: 0x%p (%lu bytes)\n", (void *)initrd_start, initrd_size); - if (CPHYSADDR(initrd_end) > PFN_PHYS(max_low_pfn)) { + if (kernel_physaddr(initrd_end) > PFN_PHYS(max_low_pfn)) { printk("initrd extends beyond end of memory " "(0x%0*Lx > 0x%0*Lx)\ndisabling initrd\n", sizeof(long) * 2, - (unsigned long long)CPHYSADDR(initrd_end), + (unsigned long long)kernel_physaddr(initrd_end), sizeof(long) * 2, (unsigned long long)PFN_PHYS(max_low_pfn)); initrd_start = initrd_end = 0; @@ -438,7 +438,7 @@ } if (initrd_reserve_bootmem) - reserve_bootmem(CPHYSADDR(initrd_start), initrd_size); + reserve_bootmem(kernel_physaddr(initrd_start), initrd_size); } #endif /* CONFIG_BLK_DEV_INITRD */ } @@ -452,10 +452,10 @@ * The 64bit code in 32bit object format trick can't represent * 64bit wide relocations for linker script symbols. */ - code_resource.start = CPHYSADDR(&_text); - code_resource.end = CPHYSADDR(&_etext) - 1; - data_resource.start = CPHYSADDR(&_etext); - data_resource.end = CPHYSADDR(&_edata) - 1; + code_resource.start = kernel_physaddr(&_text); + code_resource.end = kernel_physaddr(&_etext) - 1; + data_resource.start = kernel_physaddr(&_etext); + data_resource.end = kernel_physaddr(&_edata) - 1; #else code_resource.start = virt_to_phys(&_text); code_resource.end = virt_to_phys(&_etext) - 1; @@ -559,3 +559,9 @@ } __setup("nodsp", dsp_disable); + +/* + * Revision 1.179, Tue Apr 19 00:06:09 2005 + * Apr 2004/2005 pf - xkphys kernel addresses + */ + diff -Nur linux-git/arch/mips/lib/memcpy.S linux-git-mit-R10k-patches/arch/mips/lib/memcpy.S --- linux-git/arch/mips/lib/memcpy.S 2005-10-15 16:01:06.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/lib/memcpy.S 2005-10-16 13:21:56.000000000 +0200 @@ -17,6 +17,14 @@ #include #include +#ifdef CONFIG_SGI_IP28 +/* Inhibit speculative stores to volatile (e.g.DMA) or invalid addresses. */ +# include +# define R10KCBARRIER(addr) cache Cache_Barrier, addr; +#else +# define R10KCBARRIER(addr) +#endif + #define dst a0 #define src a1 #define len a2 @@ -180,6 +188,7 @@ */ #define rem t8 + R10KCBARRIER(0(ra)) /* hopefully inhibits speculative store prefetch */ /* * The "issue break"s below are very approximate. * Issue delays for dcache fills will perturb the schedule, as will @@ -212,6 +221,7 @@ PREF( 1, 3*32(dst) ) .align 4 1: + R10KCBARRIER(0(ra)) /* ra must be valid anyway */ EXC( LOAD t0, UNIT(0)(src), l_exc) EXC( LOAD t1, UNIT(1)(src), l_exc_copy) EXC( LOAD t2, UNIT(2)(src), l_exc_copy) @@ -253,6 +263,7 @@ EXC( LOAD t3, UNIT(3)(src), l_exc_copy) SUB len, len, 4*NBYTES ADD src, src, 4*NBYTES + R10KCBARRIER(0(ra)) EXC( STORE t0, UNIT(0)(dst), s_exc_p4u) EXC( STORE t1, UNIT(1)(dst), s_exc_p3u) EXC( STORE t2, UNIT(2)(dst), s_exc_p2u) @@ -266,6 +277,7 @@ beq rem, len, copy_bytes nop 1: + R10KCBARRIER(0(ra)) EXC( LOAD t0, 0(src), l_exc) ADD src, src, NBYTES SUB len, len, NBYTES @@ -311,6 +323,7 @@ EXC( LDREST t3, REST(0)(src), l_exc_copy) SUB t2, t2, t1 # t2 = number of bytes copied xor match, t0, t1 + R10KCBARRIER(0(ra)) EXC( STFIRST t3, FIRST(0)(dst), s_exc) beq len, t2, done SUB len, len, t2 @@ -331,6 +344,7 @@ * It's OK to load FIRST(N+1) before REST(N) because the two addresses * are to the same unit (unless src is aligned, but it's not). */ + R10KCBARRIER(0(ra)) EXC( LDFIRST t0, FIRST(0)(src), l_exc) EXC( LDFIRST t1, FIRST(1)(src), l_exc_copy) SUB len, len, 4*NBYTES @@ -359,6 +373,7 @@ beq rem, len, copy_bytes nop 1: + R10KCBARRIER(0(ra)) EXC( LDFIRST t0, FIRST(0)(src), l_exc) EXC( LDREST t0, REST(0)(src), l_exc_copy) ADD src, src, NBYTES @@ -372,6 +387,7 @@ nop copy_bytes: /* 0 < len < NBYTES */ + R10KCBARRIER(0(ra)) #define COPY_BYTE(N) \ EXC( lb t0, N(src), l_exc); \ SUB len, len, 1; \ @@ -484,6 +500,7 @@ ADD a1, a2 # src = src + len r_end_bytes: + R10KCBARRIER(0(ra)) lb t0, -1(a1) SUB a2, a2, 0x1 sb t0, -1(a0) @@ -496,6 +513,7 @@ move a2, zero r_end_bytes_up: + R10KCBARRIER(0(ra)) lb t0, (a1) SUB a2, a2, 0x1 sb t0, (a0) @@ -506,3 +524,7 @@ jr ra move a2, zero END(__rmemcpy) +/* + * Revision 1.18, Sat Jul 26 12:00:12 2003 + * Sat Aug 7 01:11:52 2004 pf - r10k cache barrier + */ diff -Nur linux-git/arch/mips/lib/strncpy_user.S linux-git-mit-R10k-patches/arch/mips/lib/strncpy_user.S --- linux-git/arch/mips/lib/strncpy_user.S 2005-10-15 16:01:06.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/lib/strncpy_user.S 2005-10-16 13:30:49.000000000 +0200 @@ -5,11 +5,20 @@ * * Copyright (c) 1996, 1999 by Ralf Baechle */ +#include #include #include #include #include +#ifdef CONFIG_SGI_IP28 +/* Inhibit speculative stores to volatile (e.g.DMA) or invalid addresses. */ +# include +# define R10KCBARRIER(addr) cache Cache_Barrier, addr; +#else +# define R10KCBARRIER(addr) +#endif + #define EX(insn,reg,addr,handler) \ 9: insn reg, addr; \ .section __ex_table,"a"; \ @@ -38,6 +47,7 @@ .set noreorder 1: EX(lbu, t0, (v1), fault) PTR_ADDIU v1, 1 + R10KCBARRIER(0(ra)) beqz t0, 2f sb t0, (a0) PTR_ADDIU v0, 1 @@ -56,3 +66,7 @@ .section __ex_table,"a" PTR 1b, fault .previous +/* + * Revision 1.9, Wed Nov 19 14:03:13 2003 + * Wed Aug 11 02:21:01 2004 pf - r10k cache barrier + */ diff -Nur linux-git/arch/mips/lib-64/memset.S linux-git-mit-R10k-patches/arch/mips/lib-64/memset.S --- linux-git/arch/mips/lib-64/memset.S 2005-10-15 16:01:06.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/lib-64/memset.S 2005-10-16 13:29:04.000000000 +0200 @@ -6,10 +6,19 @@ * Copyright (C) 1998, 1999, 2000 by Ralf Baechle * Copyright (C) 1999, 2000 Silicon Graphics, Inc. */ +#include #include #include #include +#ifdef CONFIG_SGI_IP28 +/* Inhibit speculative stores to volatile (e.g.DMA) or invalid addresses. */ +# include +# define R10KCBARRIER(addr) cache Cache_Barrier, addr; +#else +# define R10KCBARRIER(addr) +#endif + #define EX(insn,reg,addr,handler) \ 9: insn reg, addr; \ .section __ex_table,"a"; \ @@ -57,6 +66,7 @@ beqz t0, 1f PTR_SUBU t0, LONGSIZE /* alignment in bytes */ + R10KCBARRIER(0(ra)) #ifdef __MIPSEB__ EX(sdl, a1, (a0), first_fixup) /* make dword aligned */ #endif @@ -74,11 +84,13 @@ PTR_ADDU t1, a0 /* end address */ .set reorder 1: PTR_ADDIU a0, 64 + R10KCBARRIER(0(ra)) f_fill64 a0, -64, a1, fwd_fixup bne t1, a0, 1b .set noreorder memset_partial: + R10KCBARRIER(0(ra)) PTR_LA t1, 2f /* where to start */ .set noat dsrl AT, t0, 1 @@ -96,6 +108,7 @@ beqz a2, 1f PTR_ADDU a0, a2 /* What's left */ + R10KCBARRIER(0(ra)) #ifdef __MIPSEB__ EX(sdr, a1, -1(a0), last_fixup) #endif @@ -110,6 +123,7 @@ PTR_ADDU t1, a0, a2 1: PTR_ADDIU a0, 1 /* fill bytewise */ + R10KCBARRIER(0(ra)) bne t1, a0, 1b sb a1, -1(a0) @@ -140,3 +154,7 @@ last_fixup: jr ra andi v1, a2, LONGMASK +/* + * Revision 1.1, Mon Jul 21 00:11:39 2003 + * Wed Aug 11 01:52:59 2004 pf - r10k cache barrier + */ diff -Nur linux-git/arch/mips/Makefile linux-git-mit-R10k-patches/arch/mips/Makefile --- linux-git/arch/mips/Makefile 2005-10-15 16:01:06.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/Makefile 2005-10-16 13:21:56.000000000 +0200 @@ -628,6 +628,19 @@ endif # +# SGI IP28 (Indigo2 R10k) +# +# Set the load address to >= 0xa800000020080000 if you want to leave space for +# symmon, 0xa800000020004000 for production kernels ? Note that the value must +# be 16kb aligned or the handling of the current variable will break. +# Simplified: what IP22 does at 128MB+ in ksegN, IP28 does at 512MB+ in xkphys +# +#core-$(CONFIG_SGI_IP28) += arch/mips/sgi-ip22/ arch/mips/arc/arc_con.o +core-$(CONFIG_SGI_IP28) += arch/mips/sgi-ip22/ +cflags-$(CONFIG_SGI_IP28) += -mip28-cache-barrier -Iinclude/asm-mips/mach-ip28 +load-$(CONFIG_SGI_IP28) += 0xa800000020004000 + +# # SGI-IP32 (O2) # # Set the load address to >= 80069000 if you want to leave space for symmon, @@ -814,3 +827,6 @@ CLEAN_FILES += vmlinux.32 \ vmlinux.64 \ vmlinux.ecoff + +# Revision 1.193, Tue Apr 19 00:00:49 2005 +# Jun/Dec 2004 - IP28 diff -Nur linux-git/arch/mips/mm/c-r4k.c linux-git-mit-R10k-patches/arch/mips/mm/c-r4k.c --- linux-git/arch/mips/mm/c-r4k.c 2005-10-15 16:01:07.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/mm/c-r4k.c 2005-10-16 13:21:56.000000000 +0200 @@ -712,6 +712,27 @@ bc_inv(addr, size); } + +#ifdef CONFIG_CPU_R10000 +static void r10k_dma_cache_inv(unsigned long addr, unsigned long size) +{ + unsigned long sc_lsize = current_cpu_data.scache.linesz; + unsigned long end, a; + + /* Catch bad driver code */ + BUG_ON(size == 0); + //BUG_ON(!cpu_has_subset_pcaches); + + a = addr & ~(sc_lsize - 1); + end = (addr + size - 1) & ~(sc_lsize - 1); + while (1) { + invalidate_scache_line(a); /* Hit_Invalidate_SD/S */ + if (a == end) + break; + a += sc_lsize; + } +} +#endif /* CONFIG_CPU_R10000 */ #endif /* CONFIG_DMA_NONCOHERENT */ /* @@ -1269,7 +1290,16 @@ #ifdef CONFIG_DMA_NONCOHERENT _dma_cache_wback_inv = r4k_dma_cache_wback_inv; _dma_cache_wback = r4k_dma_cache_wback_inv; - _dma_cache_inv = r4k_dma_cache_inv; + switch (current_cpu_data.cputype) { +#ifdef CONFIG_CPU_R10000 + case CPU_R10000: + case CPU_R12000: + _dma_cache_inv = r10k_dma_cache_inv; + break; +#endif + default: + _dma_cache_inv = r4k_dma_cache_inv; + } #endif build_clear_page(); @@ -1277,3 +1307,7 @@ local_r4k___flush_cache_all(NULL); coherency_setup(); } +/* + * Revision 1.107, Tue Apr 19 00:06:40 2005 + * Sat Apr 9 00:06:16 2005 pf - r10k_dma_cache_inv (really dma invalidate) + */ diff -Nur linux-git/arch/mips/mm/init.c linux-git-mit-R10k-patches/arch/mips/mm/init.c --- linux-git/arch/mips/mm/init.c 2005-10-15 16:01:07.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/mm/init.c 2005-10-16 13:33:09.000000000 +0200 @@ -225,6 +225,7 @@ if (PageReserved(mem_map+tmp)) reservedpages++; } + num_physpages = ram; #ifdef CONFIG_HIGHMEM for (tmp = highstart_pfn; tmp < highend_pfn; tmp++) { @@ -241,6 +242,7 @@ set_page_count(page, 1); __free_page(page); totalhigh_pages++; + ++num_physpages; } totalram_pages += totalhigh_pages; #endif @@ -266,8 +268,8 @@ { #ifdef CONFIG_64BIT /* Switch from KSEG0 to XKPHYS addresses */ - start = (unsigned long)phys_to_virt(CPHYSADDR(start)); - end = (unsigned long)phys_to_virt(CPHYSADDR(end)); + start = (unsigned long)phys_to_virt(kernel_physaddr(start)); + end = (unsigned long)phys_to_virt(kernel_physaddr(end)); #endif if (start < end) printk(KERN_INFO "Freeing initrd memory: %ldk freed\n", @@ -293,7 +295,7 @@ addr = (unsigned long) &__init_begin; while (addr < (unsigned long) &__init_end) { #ifdef CONFIG_64BIT - page = PAGE_OFFSET | CPHYSADDR(addr); + page = PAGE_OFFSET | kernel_physaddr(addr); #else page = addr; #endif @@ -307,3 +309,7 @@ printk(KERN_INFO "Freeing unused kernel memory: %ldk freed\n", freed >> 10); } +/* + * Revision 1.75, Tue Apr 19 00:06:47 2005 + * Jun 2004 pf - XKPHYS + */ diff -Nur linux-git/arch/mips/sgi-ip22/ip22-mc.c linux-git-mit-R10k-patches/arch/mips/sgi-ip22/ip22-mc.c --- linux-git/arch/mips/sgi-ip22/ip22-mc.c 2005-10-15 16:01:07.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/sgi-ip22/ip22-mc.c 2005-10-16 13:21:56.000000000 +0200 @@ -4,6 +4,7 @@ * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) * Copyright (C) 1999 Andrew R. Baker (andrewb@uab.edu) - Indigo2 changes * Copyright (C) 2003 Ladislav Michl (ladis@linux-mips.org) + * Copyright (C) 2004 Peter Fuerst (pf@net.alphadv.de) - IP28 */ #include @@ -16,6 +17,8 @@ #include #include #include +#include +#include struct sgimc_regs *sgimc; @@ -112,6 +115,10 @@ sgimc = (struct sgimc_regs *) ioremap(SGIMC_BASE, sizeof(struct sgimc_regs)); +#ifdef CONFIG_SGI_IP28 + printk(KERN_INFO "Silicon Graphics Indigo2 R10k (IP28)" + " support: (c) 2004 peter fuerst.\n"); +#endif printk(KERN_INFO "MC: SGI memory controller Revision %d\n", (int) sgimc->systemid & SGIMC_SYSID_MASKREV); @@ -138,8 +145,21 @@ * zero. */ tmp = sgimc->cpuctrl0; - tmp |= (SGIMC_CCTRL0_EPERRGIO | SGIMC_CCTRL0_EPERRMEM | - SGIMC_CCTRL0_R4KNOCHKPARR); + tmp |= SGIMC_CCTRL0_R4KNOCHKPARR; +#ifdef CONFIG_SGI_IP28 + /* IP28 prom left us cpuctrl0 set to 3d802412: + * SGIMC_CCTRL0_GIOBTOB, SGIMC_CCTRL0_R4KNOCHKPARR, + * SGIMC_CCTRL0_GFXRESET, SGIMC_CCTRL0_EREFRESH, 31800002 + * FIXME: + * We do not attempt to override IP28-prom's parity checking, + * since SGIMC_CCTRL0_EPERRGIO will trigger a CPU parity error + * (IP[6]) on reading sgioc->sysid below, while ..EPERRMEM will + * trigger the same somewhere in prom-code (ffffffff9fc431cc) + * when ArcGetEnvironmentVariable() is called :-( + */ +#else + tmp |= (SGIMC_CCTRL0_EPERRGIO | SGIMC_CCTRL0_EPERRMEM); +#endif sgimc->cpuctrl0 = tmp; /* Step 3: Setup the MC write buffer depth, this is controlled @@ -147,7 +167,14 @@ */ tmp = sgimc->cpuctrl1; tmp &= ~0xf; +#ifdef CONFIG_SGI_IP28 + /* IP28 prom left us cpuctrl1 set to 00000016: + * SGIMC_CCTRL1_EGIOTIMEO | 00000006 + */ + tmp |= 0xd; /* ? 0x6:0xd */ +#else tmp |= 0xd; +#endif sgimc->cpuctrl1 = tmp; /* Step 4: Initialize the RPSS divider register to run as fast @@ -164,7 +191,12 @@ * registers value increases at each 'tick'. Thus, * for IP22 we get INCREMENT=1, DIVIDER=1 == 0x101 */ +#ifdef CONFIG_SGI_IP28 + /* IP28 prom left us divider set to 00000104 */ + sgimc->divider = 0x101; /* ? 0x104:0x101 */ +#else sgimc->divider = 0x101; +#endif /* Step 5: Initialize GIO64 arbitrator configuration register. * @@ -177,6 +209,20 @@ tmp = SGIMC_GIOPAR_HPC64; /* All 1st HPC's interface at 64bits */ tmp |= SGIMC_GIOPAR_ONEBUS; /* Only one physical GIO bus exists */ +#ifdef CONFIG_SGI_IP28 + /* IP28 prom left us giopar set to 0000ce23: + * SGIMC_GIOPAR_PLINEEXP0, SGIMC_GIOPAR_PLINEEXP1, + * SGIMC_GIOPAR_MASTERGFX, SGIMC_GIOPAR_MASTEREISA, + * SGIMC_GIOPAR_ONEBUS, SGIMC_GIOPAR_GFX64, + * SGIMC_GIOPAR_HPC264, SGIMC_GIOPAR_HPC64 + */ + tmp |= SGIMC_GIOPAR_HPC264; /* 2nd HPC at 64bits */ + tmp |= SGIMC_GIOPAR_PLINEEXP0; /* exp0 pipelines */ + tmp |= SGIMC_GIOPAR_PLINEEXP1; /* exp1 pipelines */ + tmp |= SGIMC_GIOPAR_MASTERGFX; /* GFX can act as a bus master */ + tmp |= SGIMC_GIOPAR_MASTEREISA; /* EISA bus can act as bus master */ + tmp |= SGIMC_GIOPAR_GFX64; /* GFX talks to GIO using 64-bits */ +#else if (ip22_is_fullhouse()) { /* Fullhouse specific settings. */ if (SGIOC_SYSID_BOARDREV(sgioc->sysid) < 2) { @@ -196,9 +242,14 @@ tmp |= SGIMC_GIOPAR_EISA64; /* MC talks to EISA at 64bits */ tmp |= SGIMC_GIOPAR_MASTEREISA; /* EISA bus can act as master */ } +#endif sgimc->giopar = tmp; /* poof */ + printk(KERN_INFO "MC: Boardrev. %d, Chiprev. %d\n", + SGIOC_SYSID_BOARDREV(sgioc->sysid), + SGIOC_SYSID_CHIPREV(sgioc->sysid)); probe_memory(); + ip2628_return_ucmem(0); /* see below. */ } void __init prom_meminit(void) {} @@ -206,3 +257,99 @@ { return 0; } + +#if defined(CONFIG_SGI_IP28) || defined(CONFIG_SGI_IP26) +/* + * Handling uncached writes on IP26/IP28, see IRIX man-page ip26_ucmem(D3) + * and Device Driver Programmer's Guide (007-0911-210), Chapter I.1. + */ + +static inline int _r10k_real_sync ( volatile struct sgimc_regs *sgimc ) +{ + /* See MIPS R10000 User's Manual (SGI 007-2490-001), Chapter 4.5 */ + int dummy = sgimc->cstat; + __asm__ __volatile__ ("sync"); + return dummy; +} + +static unsigned long +ip28_set_ucmem ( volatile struct sgimc_regs *sgimc, unsigned short enable ) +{ /* + * Reading `modereg' only provides random values, so we start with + * guessing (from WR_COL), which state the machine is initially in + * and do our own bookkeeping from then on. + */ + const unsigned long modereg = PHYS_TO_XKSEG_UNCACHED(0x60000000); + static unsigned oldstate = -1; + unsigned long flags; + unsigned tmp; + spinlock_t lock; + u32 mconfig1, cmacc, oldcmacc; + + if (enable == oldstate) + return (long)enable; + + /* This has to be done as early as possible ! */ + spin_lock_irqsave(&lock, flags); + + oldcmacc = sgimc->cmacc; + cmacc = (enable ? 6:4) | (oldcmacc & ~0xf); + + /* increase WR_COL before (if at all) */ + sgimc->cmacc = cmacc | 7; + + /* enable memory bank 3 at 0x60000000 */ + mconfig1 = sgimc->mconfig1; + sgimc->mconfig1 = mconfig1 & 0xffff0000 | 0x2060; + _r10k_real_sync(sgimc); + + /* set mode to "slow" or "normal" */ + *(volatile unsigned long*)modereg = enable ? 0x10000:0; + _r10k_real_sync(sgimc); + + /* restore memory bank configuration */ + sgimc->mconfig1 = mconfig1; + + /* decrease WR_COL only after */ + sgimc->cmacc = cmacc; + _r10k_real_sync(sgimc); + + if (-1 == oldstate) + oldstate = (oldcmacc & 0xf) > 4; + + tmp = oldstate; + oldstate = enable; + _r10k_real_sync(sgimc); + + spin_unlock_irqrestore(&lock, flags); + return tmp; +} +#endif + +unsigned long ip2628_enable_ucmem (void) +{ +#if defined(CONFIG_SGI_IP28) || defined(CONFIG_SGI_IP26) + if (!sgimc) + sgimc = (struct sgimc_regs *) + ioremap(SGIMC_BASE, sizeof(struct sgimc_regs)); + return ip28_set_ucmem(sgimc,1); +#else + return 0; +#endif +} + +void ip2628_return_ucmem ( unsigned long oldstate ) +{ +#if defined(CONFIG_SGI_IP28) || defined(CONFIG_SGI_IP26) + if (!sgimc) + sgimc = (struct sgimc_regs *) + ioremap(SGIMC_BASE, sizeof(struct sgimc_regs)); + ip28_set_ucmem(sgimc,!!oldstate); +#else + (void)oldstate; +#endif +} +/* + * Revision 1.12, Tue Nov 18 05:15:20 2003 + * Jun 2004/2005 pf - IP28 + */ diff -Nur linux-git/arch/mips/sgi-ip22/ip22-setup.c linux-git-mit-R10k-patches/arch/mips/sgi-ip22/ip22-setup.c --- linux-git/arch/mips/sgi-ip22/ip22-setup.c 2005-10-15 16:01:07.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/sgi-ip22/ip22-setup.c 2005-10-16 13:21:56.000000000 +0200 @@ -119,6 +119,34 @@ } } #endif +#if defined(CONFIG_FB_IMPACT) || defined(CONFIG_SGI_IP28) + { + /* Get graphics info before it is overwritten... + * E.g. @ 9000000020f02f78: ffffffff9fc6d770,900000001f000000 + */ + ULONG* (*__vec)(void) = (typeof(__vec)) +#ifdef CONFIG_ARC64 + ((ULONG*)PROMBLOCK->pvector)[8]; +#else + (long) ((int*)PROMBLOCK->pvector)[8]; +#endif + ULONG *gfxinfo = (*__vec)(); + ULONG a = gfxinfo[1]; + + if ((a & 0xffffffff80000000L) == 0xffffffff80000000L) + sgi_gfxaddr = a & (6L<<28) ? 0:CPHYSADDR(a); /* CKSEG[01] */ + else if ((a & (1L<<63)) && (a & 0xb80000001fffffffL) == a) + sgi_gfxaddr = XPHYSADDR(a); /* lower 512MB of XKPHYS */ + else /* rubbish... */ + sgi_gfxaddr = 0; + if (sgi_gfxaddr < 0x1f000000) + sgi_gfxaddr = 0; + + printk(KERN_DEBUG "ARCS gfx info @ %08lx: %08lx,%08lx\n", + gfxinfo, gfxinfo[0], gfxinfo[1]); + printk(KERN_INFO "SGI graphics system @ 0x%08lx\n", sgi_gfxaddr); + } +#endif #if defined(CONFIG_VT) && defined(CONFIG_SGI_NEWPORT_CONSOLE) { diff -Nur linux-git/arch/mips/sgi-ip22/ip28-berr.c linux-git-mit-R10k-patches/arch/mips/sgi-ip22/ip28-berr.c --- linux-git/arch/mips/sgi-ip22/ip28-berr.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-git-mit-R10k-patches/arch/mips/sgi-ip22/ip28-berr.c 2005-10-16 13:22:04.000000000 +0200 @@ -0,0 +1,600 @@ +/* + * ip28-berr.c: Bus error handling. + * + * Copyright (C) 2002, 2003 Ladislav Michl (ladis@linux-mips.org) + * Copyright (C) 2005 Peter Fuerst (pf@net.alphadv.de) - IP28 + */ + +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static unsigned int cpu_err_stat; /* Status reg for CPU */ +static unsigned int gio_err_stat; /* Status reg for GIO */ +static unsigned int cpu_err_addr; /* Error address reg for CPU */ +static unsigned int gio_err_addr; /* Error address reg for GIO */ +static unsigned int extio_stat; +static unsigned int hpc3_berr_stat; /* Bus error interrupt status */ + +struct hpc3_stat { + unsigned int addr; + unsigned int ctrl; + unsigned int cbp; + unsigned int ndptr; +}; + +static struct { + struct hpc3_stat pbdma[8]; + struct hpc3_stat scsi[2]; + struct hpc3_stat ethrx, ethtx; +} hpc3; + +static struct { + unsigned long err_addr; + struct { unsigned lo; unsigned hi; } /* Cache tag High/Low */ + tags[1][2], tagd[4][2], tagi[4][2]; /* Way 0/1 */ +} cache_tags; + +static inline void save_cache_tags(unsigned busaddr) +{ + unsigned long addr = CAC_BASE | busaddr; + unsigned i; + cache_tags.err_addr = addr; + + /* + * Starting with a bus-address, save secondary cache (indexed by + * PA[23..18:7..6]) tags first. + */ + addr &= ~1L; + #define tag cache_tags.tags[0] + cache_op(Index_Load_Tag_S, addr); + tag[0].lo = read_c0_taglo(); /* PA[35:18], VA[13:12] */ + tag[0].hi = read_c0_taghi(); /* PA[39:36] */ + cache_op(Index_Load_Tag_S, addr | 1L); + tag[1].lo = read_c0_taglo(); /* PA[35:18], VA[13:12] */ + tag[1].hi = read_c0_taghi(); /* PA[39:36] */ + #undef tag + + /* + * Save all primary data cache (indexed by VA[13:5]) tags which + * might fit to this bus-address, knowing that VA[11:0] == PA[11:0]. + * Saving all tags and evaluating them later is easier and safer + * than relying on VA[13:12] from the secondary cache tags to pick + * matching primary tags here already. + */ + addr &= (0xffL << 56) | ((1 << 12) - 1); + #define tag cache_tags.tagd[i] + for (i = 0; i < 4; ++i, addr += (1 << 12)) + { cache_op(Index_Load_Tag_D, addr); + tag[0].lo = read_c0_taglo(); /* PA[35:12] */ + tag[0].hi = read_c0_taghi(); /* PA[39:36] */ + cache_op(Index_Load_Tag_D, addr | 1L); + tag[1].lo = read_c0_taglo(); /* PA[35:12] */ + tag[1].hi = read_c0_taghi(); /* PA[39:36] */ + } + #undef tag + + /* + * Save primary instruction cache (indexed by VA[13:6]) tags + * the same way. + */ + addr &= (0xffL << 56) | ((1 << 12) - 1); + #define tag cache_tags.tagi[i] + for (i = 0; i < 4; ++i, addr += (1 << 12)) + { cache_op(Index_Load_Tag_I, addr); + tag[0].lo = read_c0_taglo(); /* PA[35:12] */ + tag[0].hi = read_c0_taghi(); /* PA[39:36] */ + cache_op(Index_Load_Tag_I, addr | 1L); + tag[1].lo = read_c0_taglo(); /* PA[35:12] */ + tag[1].hi = read_c0_taghi(); /* PA[39:36] */ + } + #undef tag +} + +#define GIO_ERRMASK 0xff00 +#define CPU_ERRMASK 0x3f00 + +static void save_and_clear_buserr(void) +{ + unsigned i; + + /* save status registers */ + cpu_err_addr = sgimc->cerr; + cpu_err_stat = sgimc->cstat; + gio_err_addr = sgimc->gerr; + gio_err_stat = sgimc->gstat; + //BUG_ON(!ip22_is_fullhouse()); + extio_stat = sgioc->extio; + hpc3_berr_stat = hpc3c0->bestat; + + hpc3.scsi[0].addr = &hpc3c0->scsi_chan0; + hpc3.scsi[0].ctrl = hpc3c0->scsi_chan0.ctrl; /* HPC3_SCTRL_ACTIVE ? */ + hpc3.scsi[0].cbp = hpc3c0->scsi_chan0.cbptr; + hpc3.scsi[0].ndptr = hpc3c0->scsi_chan0.ndptr; + + hpc3.scsi[1].addr = &hpc3c0->scsi_chan1; + hpc3.scsi[1].ctrl = hpc3c0->scsi_chan1.ctrl; /* HPC3_SCTRL_ACTIVE ? */ + hpc3.scsi[1].cbp = hpc3c0->scsi_chan1.cbptr; + hpc3.scsi[1].ndptr = hpc3c0->scsi_chan1.ndptr; + + hpc3.ethrx.addr = &hpc3c0->ethregs.rx_cbptr; + hpc3.ethrx.ctrl = hpc3c0->ethregs.rx_ctrl; /* HPC3_ERXCTRL_ACTIVE ? */ + hpc3.ethrx.cbp = hpc3c0->ethregs.rx_cbptr; + hpc3.ethrx.ndptr = hpc3c0->ethregs.rx_ndptr; + + hpc3.ethtx.addr = &hpc3c0->ethregs.tx_cbptr; + hpc3.ethtx.ctrl = hpc3c0->ethregs.tx_ctrl; /* HPC3_ETXCTRL_ACTIVE ? */ + hpc3.ethtx.cbp = hpc3c0->ethregs.tx_cbptr; + hpc3.ethtx.ndptr = hpc3c0->ethregs.tx_ndptr; + + for (i = 0; i < 8; ++i) { + /* HPC3_PDMACTRL_ISACT ? */ + hpc3.pbdma[i].addr = &hpc3c0->pbdma[i]; + hpc3.pbdma[i].ctrl = hpc3c0->pbdma[i].pbdma_ctrl; + hpc3.pbdma[i].cbp = hpc3c0->pbdma[i].pbdma_bptr; + hpc3.pbdma[i].ndptr = hpc3c0->pbdma[i].pbdma_dptr; + } + i = 0; + if (gio_err_stat & CPU_ERRMASK) + i = gio_err_addr; + if (cpu_err_stat & CPU_ERRMASK) + i = cpu_err_addr; + save_cache_tags(i); + + sgimc->cstat = sgimc->gstat = 0; +} + +static void print_cache_tags(void) +{ + unsigned i, scb, scw; + + printk(KERN_ERR "Cache tags @ %08x:\n", (unsigned)cache_tags.err_addr); + + /* PA[31:12] shifted to PTag0 (PA[35:12]) format */ + scw = (cache_tags.err_addr >> 4) & 0x0fffff00; + + scb = cache_tags.err_addr & ((1 << 12) - 1) & ~((1 << 5) - 1); + for (i = 0; i < 4; ++i) { /* for each possible VA[13:12] value */ + if ((cache_tags.tagd[i][0].lo & 0x0fffff00) != scw && + (cache_tags.tagd[i][1].lo & 0x0fffff00) != scw) + continue; + printk(KERN_ERR "D: 0: %08x %08x, 1: %08x %08x (VA[13:5] %04x)\n", + cache_tags.tagd[i][0].hi, cache_tags.tagd[i][0].lo, + cache_tags.tagd[i][1].hi, cache_tags.tagd[i][1].lo, + scb | (1 << 12)*i); + } + scb = cache_tags.err_addr & ((1 << 12) - 1) & ~((1 << 6) - 1); + for (i = 0; i < 4; ++i) { /* for each possible VA[13:12] value */ + if ((cache_tags.tagi[i][0].lo & 0x0fffff00) != scw && + (cache_tags.tagi[i][1].lo & 0x0fffff00) != scw) + continue; + printk(KERN_ERR "I: 0: %08x %08x, 1: %08x %08x (VA[13:6] %04x)\n", + cache_tags.tagi[i][0].hi, cache_tags.tagi[i][0].lo, + cache_tags.tagi[i][1].hi, cache_tags.tagi[i][1].lo, + scb | (1 << 12)*i); + } + i = read_c0_config(); + scb = i & (1 << 13) ? 7:6; /* scblksize = 2^[7..6] */ + scw = ((i >> 16) & 7) + 19 - 1; /* scwaysize = 2^[24..19] / 2 */ + + i = ((1 << scw) - 1) & ~((1 << scb) - 1); + printk(KERN_ERR "S: 0: %08x %08x, 1: %08x %08x (PA[%u:%u] %05x)\n", + cache_tags.tags[0][0].hi, cache_tags.tags[0][0].lo, + cache_tags.tags[0][1].hi, cache_tags.tags[0][1].lo, + scw-1, scb, i & (unsigned)cache_tags.err_addr); +} + +static void print_buserr(void) +{ + int error = 0; + + if (extio_stat & EXTIO_MC_BUSERR) { + printk(KERN_ERR "MC Bus Error\n"); + error |= 1; + } + if (extio_stat & EXTIO_HPC3_BUSERR) { + printk(KERN_ERR "HPC3 Bus Error 0x%x:\n", + hpc3_berr_stat, + (hpc3_berr_stat & HPC3_BESTAT_PIDMASK) >> + HPC3_BESTAT_PIDSHIFT, + (hpc3_berr_stat & HPC3_BESTAT_CTYPE) ? "PIO" : "DMA", + hpc3_berr_stat & HPC3_BESTAT_BLMASK); + error |= 2; + } + if (extio_stat & EXTIO_EISA_BUSERR) { + printk(KERN_ERR "EISA Bus Error\n"); + error |= 4; + } + if (cpu_err_stat & CPU_ERRMASK) { + printk(KERN_ERR "CPU error 0x%x<%s%s%s%s%s%s> @ 0x%08x\n", + cpu_err_stat, + cpu_err_stat & SGIMC_CSTAT_RD ? "RD " : "", + cpu_err_stat & SGIMC_CSTAT_PAR ? "PAR " : "", + cpu_err_stat & SGIMC_CSTAT_ADDR ? "ADDR " : "", + cpu_err_stat & SGIMC_CSTAT_SYSAD_PAR ? "SYSAD " : "", + cpu_err_stat & SGIMC_CSTAT_SYSCMD_PAR ? "SYSCMD " : "", + cpu_err_stat & SGIMC_CSTAT_BAD_DATA ? "BAD_DATA " : "", + cpu_err_addr); + error |= 8; + } + if (gio_err_stat & GIO_ERRMASK) { + printk(KERN_ERR "GIO error 0x%x:<%s%s%s%s%s%s%s%s> @ 0x%08x\n", + gio_err_stat, + gio_err_stat & SGIMC_GSTAT_RD ? "RD " : "", + gio_err_stat & SGIMC_GSTAT_WR ? "WR " : "", + gio_err_stat & SGIMC_GSTAT_TIME ? "TIME " : "", + gio_err_stat & SGIMC_GSTAT_PROM ? "PROM " : "", + gio_err_stat & SGIMC_GSTAT_ADDR ? "ADDR " : "", + gio_err_stat & SGIMC_GSTAT_BC ? "BC " : "", + gio_err_stat & SGIMC_GSTAT_PIO_RD ? "PIO_RD " : "", + gio_err_stat & SGIMC_GSTAT_PIO_WR ? "PIO_WR " : "", + gio_err_addr); + error |= 16; + } + if (!error) + printk(KERN_ERR "MC: Hmm, didn't find any error condition.\n"); + else { + printk(KERN_ERR "CP0: config %08x, " + "MC: cpuctrl0/1: %08x/%05x, giopar: %04x\n" + "MC: cpu/gio_memacc: %08x/%05x, memcfg0/1: %08x/%08x\n", + read_c0_config(), + sgimc->cpuctrl0, sgimc->cpuctrl0, sgimc->giopar, + sgimc->cmacc, sgimc->gmacc, + sgimc->mconfig0, sgimc->mconfig1); + print_cache_tags(); + } +} + +/* + * Try to find out, whether the bus error is caused by the instruction + * at EPC, otherwise we have an asynchronous error. + * + * Doc1: "MIPS IV Instruction Set", Rev 3.2 (SGI 007-2597-001) + * Doc2: "MIPS R10000 Microporcessor User's Manual", Ver 2.0 (SGI 007-2490-001) + * Doc3: "MIPS R4000 Microporcessor User's Manual", 2nd Ed. (SGI 007-2489-001) + */ + +#define JMP_INDEX26_OP 1 +#define JMP_REGISTER_OP 2 +#define JMP_PCREL16_OP 3 +#define BASE_OFFSET_OP 4 +#define BASE_IDXREG_OP 5 + +/* Match virtual address in an insn with physical error address */ + +static int match_addr(unsigned paddr, unsigned long vaddr) +{ + unsigned uaddr; + + if ((vaddr & 0xffffffff80000000L) == 0xffffffff80000000L) + uaddr = (unsigned) CPHYSADDR(vaddr); + else if ((vaddr >> 62) == 2) + uaddr = (unsigned) XPHYSADDR(vaddr); + else + { unsigned long eh = vaddr & ~0x1fffL; + eh |= read_c0_entryhi() & 0xff; + write_c0_entryhi(eh); + tlb_probe(); + if (read_c0_index() & 0x80000000) + return 0; + tlb_read(); + if (vaddr & (1L << PAGE_SHIFT)) + uaddr = (unsigned) read_c0_entrylo1(); + else + uaddr = (unsigned) read_c0_entrylo0(); + uaddr <<= 6; + uaddr &= ~PAGE_MASK; + uaddr |= vaddr & PAGE_MASK; + } + return ((uaddr & ~0x7f) == (paddr & ~0x7f)); +} + +/* Check, which kind of memory reference is triggered by `insn' */ + +static int check_special(unsigned insn) +{ + /* See Doc1, page A-180 */ + unsigned func = insn & 0x3f; + + if (8 == func || 8+1 == func) /* JR, JALR */ + return JMP_REGISTER_OP; + + return 0; +} + +static int check_regimm(unsigned insn) +{ + /* See Doc1, page A-180 */ + unsigned rt = (insn >> 19) & 3; /* bits 20..19[..16] */ + + /* BLTZ, BGEZ, BLTZL, BBGEZL || BLTZAL, BGEZAL, BLTZALL, BBGEZALL */ + if (!rt || 2 == rt) + return JMP_PCREL16_OP; + + return 0; +} + +static int check_cop0(unsigned insn) +{ + /* See Doc2, pages 287 ff., 187 ff. */ + if ((insn >> 26) == 5*8+7) /* CACHE */ + switch ((insn >> 16) & 0x1f) { + case Index_Writeback_Inv_D: + case Hit_Writeback_Inv_D: + case Index_Writeback_Inv_S: + case Hit_Writeback_Inv_S: + return BASE_OFFSET_OP; + } + return 0; +} + +static int check_cop1(unsigned insn) +{ + /* See Doc1, pages B-108 ff. */ + unsigned fmt = (insn >> 21) & 0x1f; /* bits 25..21 */ + + if (8 == fmt) /* BC1* */ + return JMP_PCREL16_OP; + + return 0; +} + +static int check_cop1x(unsigned insn) +{ + /* See Doc1, pages B-108 ff. */ + switch (insn & 0x3f) { + case 0: /* LWXC1 */ + case 1: /* LDXC1 */ + case 8: /* SWXC1 */ + case 8+1: /* SDXC1 */ + return BASE_IDXREG_OP; + } + return 0; +} + +static int check_plain(unsigned insn) +{ + /* See Doc1, page A-180 */ + unsigned opcode = insn >> 26; + + if (2 == opcode || 3 == opcode) /* J, JAL */ + return JMP_INDEX26_OP; + + if (4 <= opcode && opcode <= 7 || /* BEQ, BNE, BLEZ, BGTZ */ + 4+2*8 <= opcode && opcode <= 7+2*8) /* BEQL, BNEL, BLEZL, BGTZL */ + return JMP_PCREL16_OP; + + if (6*8+3 == opcode) /* PREF */ + return 0; + + if (3*8+2 == opcode || 3*8+3 == opcode || /* LDL, LDR */ + 4*8 <= opcode) /* misc. LOAD, STORE */ + return BASE_OFFSET_OP; + + return 0; +} + +/* Check, whether the insn at EPC causes a memory access at `paddr' */ + +static int check_addr_in_insn(unsigned paddr, struct pt_regs *regs) +{ + unsigned long epc; + unsigned insn; + int typ; + + epc = regs->cp0_cause & CAUSEF_BD ? regs->cp0_epc:regs->cp0_epc+4; + + /* show_code() from kernel/traps.c */ + if (__get_user(insn, (unsigned*) epc)) + return 1; + + /* See Doc1, pages A-180, B-108 ff. */ + switch (insn >> 26) + { case 0: + typ = check_special(insn); + break; + case 1: + typ = check_regimm(insn); + break; + case 2*8: /* COP0 */ + case 5*8+7: /* CACHE */ + typ = check_cop0(insn); + break; + case 2*8+1: + typ = check_cop1(insn); + break; + case 2*8+3: + typ = check_cop1x(insn); + break; + default: + typ = check_plain(insn); + } + switch (typ) + { unsigned long a; + case JMP_INDEX26_OP: + a = (regs->cp0_epc + 4) & ~0xfffffff; + a |= (insn & 0x3ffffff) << 2; + return match_addr(paddr, a); + case JMP_REGISTER_OP: + a = regs->regs[(insn >> 21) & 0x1f]; + return match_addr(paddr, a); + case JMP_PCREL16_OP: + a = regs->cp0_epc + 4 + ((insn & 0xffff) << 2); + return match_addr(paddr, a); + case BASE_OFFSET_OP: + a = regs->regs[(insn >> 21) & 0x1f] + (insn & 0xffff); + return match_addr(paddr, a); + case BASE_IDXREG_OP: + a = regs->regs[(insn >> 21) & 0x1f]; + a += regs->regs[(insn >> 16) & 0x1f]; + return match_addr(paddr, a); + case 0: + return 0; + } + /* Assume it would be too dangerous to continue ... */ + return 1; +} + +/* Check, whether MC's (virtual) DMA address caused the bus error. */ + +static int check_vdma_memaddr (void) +{ + /* Deferred until needed. */ + return 0; +} + +static int check_vdma_gioaddr (void) +{ + /* Deferred until needed. */ + return 0; +} + +static inline const char *cause_excode_text(int cause) +{ + static const char *txt[32] = + { "Interrupt", + "TLB modification", + "TLB (load or instruction fetch)", + "TLB (store)", + "Address error (load or instruction fetch)", + "Address error (store)", + "Bus error (instruction fetch)", + "Bus error (data: load or store)", + "Syscall", + "Breakpoint", + "Reserved instruction", + "Coprocessor unusable", + "Arithmetic Overflow", + "Trap", + "14", + "Floating-Point", + "16", "17", "18", "19", "20", "21", "22", + "Watch Hi/Lo", + "24", "25", "26", "27", "28", "29", "30", "31", + }; + return txt[(cause & 0x7c) >> 2]; +} + +/* + * MC sends an interrupt whenever bus or parity errors occur. In addition, + * if the error happened during a CPU read, it also asserts the bus error + * pin on the R4K. Code in bus error handler save the MC bus error registers + * and then clear the interrupt when this happens. + */ + +static int ip28_be_interrupt(struct pt_regs *regs) +{ + const int field = 2 * sizeof(unsigned long); + unsigned i; + + save_and_clear_buserr(); + print_buserr(); + printk(KERN_ALERT "%s, epc == %0*lx, ra == %0*lx\n", + cause_excode_text(regs->cp0_cause), + field, regs->cp0_epc, field, regs->regs[31]); + /* + * Try to find out, whether we got here by a mispredicted speculative + * load/store operation. If so, it's not fatal, we can go on. + */ + /* Any cause other than "Interrupt" (ExcCode 0) is fatal. */ + if (regs->cp0_cause & CAUSEF_EXCCODE) + return MIPS_BE_FATAL; + + /* Any cause other than "Bus error interrupt" (IP6) is weird. */ + if ((regs->cp0_cause & CAUSEF_IP6) != CAUSEF_IP6) + return MIPS_BE_FATAL; + + if (extio_stat & (EXTIO_HPC3_BUSERR | EXTIO_EISA_BUSERR)) + return MIPS_BE_FATAL; + + /* Any state other than "Memory bus error" is fatal. */ + if (cpu_err_stat & CPU_ERRMASK & ~SGIMC_CSTAT_ADDR) + return MIPS_BE_FATAL; + + /* Any state other than "GIO transaction bus timed out" is fatal. */ + if (gio_err_stat & GIO_ERRMASK & ~SGIMC_GSTAT_TIME) + return MIPS_BE_FATAL; + + /* Finding `cpu_err_addr' in the insn at EPC is fatal. */ + if ((cpu_err_stat & CPU_ERRMASK) && check_addr_in_insn(cpu_err_addr,regs)) + return MIPS_BE_FATAL; + + /* Finding `gio_err_addr' in the insn at EPC is fatal. */ + if ((gio_err_stat & GIO_ERRMASK) && check_addr_in_insn(gio_err_addr,regs)) + return MIPS_BE_FATAL; + /* + * Now we have an asynchronous bus error, speculatively or DMA caused. + * Need to search all DMA descriptors for the error address. + */ + for (i = 0; i < sizeof(hpc3)/sizeof(struct hpc3_stat); ++i) { + struct hpc3_stat *hp = (struct hpc3_stat *)&hpc3 + i; + if ((cpu_err_stat & CPU_ERRMASK) && + (cpu_err_addr == hp->ndptr || cpu_err_addr == hp->cbp)) + break; + if ((gio_err_stat & GIO_ERRMASK) && + (gio_err_addr == hp->ndptr || gio_err_addr == hp->cbp)) + break; + } + if (i < sizeof(hpc3)/sizeof(struct hpc3_stat)) { + struct hpc3_stat *hp = (struct hpc3_stat *)&hpc3 + i; + printk(KERN_ERR "at DMA addresses: HPC3 @ %08lx:" + " ctl %08x, ndp %08x, cbp %08x\n", + CPHYSADDR(hp->addr), hp->ctrl, hp->ndptr, hp->cbp); + return MIPS_BE_FATAL; + } + /* Check MC's virtual DMA stuff. */ + if ( check_vdma_memaddr() ) { + printk(KERN_ERR "at GIO DMA: mem address 0x%08x.\n", + sgimc->maddronly); + return MIPS_BE_FATAL; + } + if ( check_vdma_gioaddr() ) { + printk(KERN_ERR "at GIO DMA: gio address 0x%08x.\n", + sgimc->gmaddronly); + return MIPS_BE_FATAL; + } + /* A speculative bus error... */ + printk(KERN_ERR "discarded!\n"); + return MIPS_BE_DISCARD; +} + +void ip22_be_interrupt(int irq, struct pt_regs *regs) +{ + if (ip28_be_interrupt(regs) != MIPS_BE_DISCARD) { + /* Assume it would be too dangerous to continue ... */ + die_if_kernel("Oops", regs); + force_sig(SIGBUS, current); + } else { + show_regs(regs); + show_code((unsigned int *) regs->cp0_epc); + } +} + +static int ip28_be_handler(struct pt_regs *regs, int is_fixup) +{ + /* + * We arrive here only in the unusual case of do_be() invocation, + * i.e. by a bus error exception without a bus error interrupt. + */ + if (is_fixup) { + save_and_clear_buserr(); + return MIPS_BE_FIXUP; + } + return ip28_be_interrupt(regs); +} + +void __init ip22_be_init(void) +{ + board_be_handler = ip28_be_handler; +} diff -Nur linux-git/arch/mips/sgi-ip22/Makefile linux-git-mit-R10k-patches/arch/mips/sgi-ip22/Makefile --- linux-git/arch/mips/sgi-ip22/Makefile 2005-10-15 16:01:07.000000000 +0200 +++ linux-git-mit-R10k-patches/arch/mips/sgi-ip22/Makefile 2005-10-16 13:21:56.000000000 +0200 @@ -3,9 +3,13 @@ # under Linux. # -obj-y += ip22-mc.o ip22-hpc.o ip22-int.o ip22-irq.o ip22-berr.o \ +obj-y += ip22-mc.o ip22-hpc.o ip22-int.o ip22-irq.o \ ip22-time.o ip22-nvram.o ip22-reset.o ip22-setup.o +obj-$(CONFIG_SGI_IP28) += ip28-berr.o +obj-$(CONFIG_SGI_IP22) += ip22-berr.o obj-$(CONFIG_EISA) += ip22-eisa.o EXTRA_AFLAGS := $(CFLAGS) + +# Revision 1.19, Tue Nov 18 05:15:20 2003 diff -Nur linux-git/drivers/char/Kconfig linux-git-mit-R10k-patches/drivers/char/Kconfig --- linux-git/drivers/char/Kconfig 2005-10-15 16:01:11.000000000 +0200 +++ linux-git-mit-R10k-patches/drivers/char/Kconfig 2005-10-16 13:21:56.000000000 +0200 @@ -762,7 +762,7 @@ config SGI_DS1286 tristate "SGI DS1286 RTC support" - depends on SGI_IP22 + depends on (SGI_IP22 || SGI_IP28) help If you say Y here and create a character special file /dev/rtc with major number 10 and minor number 135 using mknod ("man mknod"), you diff -Nur linux-git/drivers/char/tty_io.c linux-git-mit-R10k-patches/drivers/char/tty_io.c --- linux-git/drivers/char/tty_io.c 2005-10-15 16:01:12.000000000 +0200 +++ linux-git-mit-R10k-patches/drivers/char/tty_io.c 2005-10-16 13:21:56.000000000 +0200 @@ -744,6 +744,7 @@ void tty_wakeup(struct tty_struct *tty) { + if (tty) { struct tty_ldisc *ld; if (test_bit(TTY_DO_WRITE_WAKEUP, &tty->flags)) { @@ -755,6 +756,7 @@ } } wake_up_interruptible(&tty->write_wait); + } } EXPORT_SYMBOL_GPL(tty_wakeup); @@ -3014,3 +3016,7 @@ return 0; } module_init(tty_init); +/* + * Revision 1.133, Tue Apr 19 00:39:02 2005 + * Wed Jan 5 02:16:41 2005 + */ diff -Nur linux-git/drivers/char/watchdog/Kconfig linux-git-mit-R10k-patches/drivers/char/watchdog/Kconfig --- linux-git/drivers/char/watchdog/Kconfig 2005-10-15 16:01:12.000000000 +0200 +++ linux-git-mit-R10k-patches/drivers/char/watchdog/Kconfig 2005-10-16 13:21:56.000000000 +0200 @@ -427,7 +427,7 @@ config INDYDOG tristate "Indy/I2 Hardware Watchdog" - depends on WATCHDOG && SGI_IP22 + depends on WATCHDOG && (SGI_IP22 || SGI_IP28) help Hardwaredriver for the Indy's/I2's watchdog. This is a watchdog timer that will reboot the machine after a 60 second diff -Nur linux-git/drivers/input/serio/i8042.c linux-git-mit-R10k-patches/drivers/input/serio/i8042.c --- linux-git/drivers/input/serio/i8042.c 2005-10-15 16:01:13.000000000 +0200 +++ linux-git-mit-R10k-patches/drivers/input/serio/i8042.c 2005-10-16 13:21:56.000000000 +0200 @@ -656,7 +656,13 @@ if (i8042_command(¶m, I8042_CMD_AUX_ENABLE)) return -1; if (i8042_command(¶m, I8042_CMD_CTL_RCTR) || (param & I8042_CTR_AUXDIS)) +#ifdef CONFIG_SGI_IP28 + /* Seems we need to invert the CTR_AUXDIS-test on this machine: + * CMD_AUX_DISABLE -> rctr 0xcf, CMD_AUX_ENABLE -> rctr 0xef */ + printk(KERN_WARNING "Failed to enable AUX port, but continuing anyway... ;)\n"); +#else return -1; +#endif /* * Disable the interface. diff -Nur linux-git/drivers/input/serio/i8042.h linux-git-mit-R10k-patches/drivers/input/serio/i8042.h --- linux-git/drivers/input/serio/i8042.h 2005-10-15 16:01:13.000000000 +0200 +++ linux-git-mit-R10k-patches/drivers/input/serio/i8042.h 2005-10-16 13:21:56.000000000 +0200 @@ -17,7 +17,7 @@ #if defined(CONFIG_MACH_JAZZ) #include "i8042-jazzio.h" -#elif defined(CONFIG_SGI_IP22) +#elif defined(CONFIG_SGI_IP22) || defined(CONFIG_SGI_IP28) #include "i8042-ip22io.h" #elif defined(CONFIG_PPC) #include "i8042-ppcio.h" @@ -131,3 +131,7 @@ #endif #endif /* _I8042_H */ +/* + * Revision 1.10, Tue Apr 19 00:50:01 2005 + * Tue Dec 7 19:43:43 2004 - IP28 + */ diff -Nur linux-git/drivers/net/Kconfig linux-git-mit-R10k-patches/drivers/net/Kconfig --- linux-git/drivers/net/Kconfig 2005-10-15 16:01:16.000000000 +0200 +++ linux-git-mit-R10k-patches/drivers/net/Kconfig 2005-10-16 13:21:56.000000000 +0200 @@ -1728,7 +1728,7 @@ config SGISEEQ tristate "SGI Seeq ethernet controller support" - depends on NET_ETHERNET && SGI_IP22 + depends on NET_ETHERNET && (SGI_IP22 || SGI_IP26 || SGI_IP28) help Say Y here if you have an Seeq based Ethernet network card. This is used in many Silicon Graphics machines. diff -Nur linux-git/drivers/scsi/Kconfig linux-git-mit-R10k-patches/drivers/scsi/Kconfig --- linux-git/drivers/scsi/Kconfig 2005-10-15 16:01:20.000000000 +0200 +++ linux-git-mit-R10k-patches/drivers/scsi/Kconfig 2005-10-16 13:21:56.000000000 +0200 @@ -249,7 +249,7 @@ config SGIWD93_SCSI tristate "SGI WD93C93 SCSI Driver" - depends on SGI_IP22 && SCSI + depends on (SGI_IP22 || SGI_IP26 || SGI_IP28) && SCSI help If you have a Western Digital WD93 SCSI controller on an SGI MIPS system, say Y. Otherwise, say N. diff -Nur linux-git/drivers/scsi/wd33c93.c linux-git-mit-R10k-patches/drivers/scsi/wd33c93.c --- linux-git/drivers/scsi/wd33c93.c 2005-10-15 16:01:23.000000000 +0200 +++ linux-git-mit-R10k-patches/drivers/scsi/wd33c93.c 2005-10-16 13:21:56.000000000 +0200 @@ -1460,7 +1460,7 @@ const wd33c93_regs regs = hostdata->regs; uchar sr; -#ifdef CONFIG_SGI_IP22 +#if defined(CONFIG_SGI_IP22) || defined(CONFIG_SGI_IP28) { int busycount = 0; extern void sgiwd93_reset(unsigned long); diff -Nur linux-git/drivers/serial/ip22zilog.c linux-git-mit-R10k-patches/drivers/serial/ip22zilog.c --- linux-git/drivers/serial/ip22zilog.c 2005-10-15 16:01:24.000000000 +0200 +++ linux-git-mit-R10k-patches/drivers/serial/ip22zilog.c 2005-10-16 13:44:41.000000000 +0200 @@ -1015,9 +1015,9 @@ spin_lock_irqsave(&up->port.lock, flags); for (i = 0; i < count; i++, s++) { - ip22zilog_put_char(channel, *s); if (*s == 10) ip22zilog_put_char(channel, 13); + ip22zilog_put_char(channel, *s); } udelay(2); spin_unlock_irqrestore(&up->port.lock, flags); diff -Nur linux-git/drivers/serial/Kconfig linux-git-mit-R10k-patches/drivers/serial/Kconfig --- linux-git/drivers/serial/Kconfig 2005-10-15 16:01:24.000000000 +0200 +++ linux-git-mit-R10k-patches/drivers/serial/Kconfig 2005-10-16 13:21:56.000000000 +0200 @@ -555,16 +555,18 @@ config SERIAL_IP22_ZILOG tristate "IP22 Zilog8530 serial support" - depends on SGI_IP22 + depends on (SGI_IP22 || SGI_IP28) select SERIAL_CORE + default y if SGI_IP28 help - This driver supports the Zilog8530 serial ports found on SGI IP22 + This driver supports the Zilog8530 serial ports found on SGI IP22-IP28 systems. Say Y or M if you want to be able to these serial ports. config SERIAL_IP22_ZILOG_CONSOLE - bool "Console on IP22 Zilog8530 serial port" + bool "Console on IP22/28 Zilog8530 serial port" depends on SERIAL_IP22_ZILOG=y select SERIAL_CORE_CONSOLE + default y if SGI_IP28 config V850E_UART bool "NEC V850E on-chip UART support" diff -Nur linux-git/drivers/video/impact.c linux-git-mit-R10k-patches/drivers/video/impact.c --- linux-git/drivers/video/impact.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-git-mit-R10k-patches/drivers/video/impact.c 2005-10-16 13:22:04.000000000 +0200 @@ -0,0 +1,906 @@ +/* + * linux/drivers/video/impactsr.c -- SGI Octane MardiGras (IMPACTSR) graphics + * linux/drivers/video/impact.c -- SGI Indigo2 MardiGras (IMPACT) graphics + * + * Copyright (c) 2004 by Stanislaw Skowronek + * Adapted to Indigo2 by pf, 2005 + * + * Based on linux/drivers/video/skeletonfb.c + * + * This driver, as most of the IP30 (SGI Octane) port, is a result of massive + * amounts of reverse engineering and trial-and-error. If anyone is interested + * in helping with it, please contact me: . + * + * The basic functions of this driver are filling and blitting rectangles. + * To achieve the latter, two DMA operations are used on Impact. It is unclear + * to me, why is it so, but even Xsgi (the IRIX X11 server) does it this way. + * It seems that fb->fb operations are not operational on these cards. + * + * For this purpose, a kernel DMA pool is allocated (pool number 0). This pool + * is (by default) 64kB in size. An ioctl could be used to set the value at + * run-time. Applications can use this pool, however proper locking has to be + * guaranteed. Kernel should be locked out from this pool by an ioctl. + * + * The IMPACTSR is quite well worked-out currently, except for the Geometry + * Engines (GE11). Any information about use of those devices would be very + * useful. It would enable a Linux OpenGL driver, as most of OpenGL calls are + * supported directly by the hardware. So far, I can't initialize the GE11. + * Verification of microcode crashes the graphics. + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file COPYING in the main directory of this archive for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include